ITU-T Q 86 7-1995 Stage 2 Description for Charging Supplementary Services Clause 7 - International Telecommunication Charge Card (ITCC) - General Recommendations on Telephone Switc Flo.pdf

《ITU-T Q 86 7-1995 Stage 2 Description for Charging Supplementary Services Clause 7 - International Telecommunication Charge Card (ITCC) - General Recommendations on Telephone Switc Flo.pdf》由会员分享，可在线阅读，更多相关《ITU-T Q 86 7-1995 Stage 2 Description for Charging Supplementary Services Clause 7 - International Telecommunication Charge Card (ITCC) - General Recommendations on Telephone Switc Flo.pdf（34页珍藏版）》请在麦多课文档分享上搜索。

1、INTERNATIONAL TELECOMMUNICATION UNION)45G134 1 TELECOMMUNICATION (10/95)STANDARDIZATION SECTOROF ITU%.%2!,G0G02%#/-%.$!4)/.3/.G0G04%,%0(/.%G0G037)4#().G0G0!.$G0G03).!,).b) accesses the service-providing capabilities of the Call Control Function (CCF), using service requests(e.g. set-up, transfer, ho

2、ld, etc.) for the establishment, manipulation and release of a call or instance ofservice;c) receives indications relating to the call or service from the CCF and relays them to the user as required;d) maintains call/service state information as perceived by this functional entity.The CC Function (C

3、CF)The CCF is the Call Control (CC) Function in the network that provides call/connection processing and control. It:a) establishes, manipulates and releases call/connection as “requested” by the CCAF;b) provides the capability to associate and relate CCAF functional entities that are involved in a

4、particularcall and/or connection instance (that may be due to SSF requests);c) manages the relationship between CCAF functional entities involved in a call (e.g. supervises the overallperspective of the call and/or connection instance);d) provides trigger mechanisms to access IN functionality (e.g.

5、passes events to the SSF).The SS Function (SSF)The SSF is the Service Switching (SS) Function, which associated with the CCF, provides the set of functions requiredfor interaction between the CCF and a Service Control Function (SCF). It:a) extends the logic of the CCF to include recognition of the s

6、ervice (service control triggers) and to interactwith the SCF;b) manages signalling between the CCF and the SCF;c) modifies call/connection processing functions (in the CCF) as required to process requests for IN andnon-IN provided service usage under the control of the SCF.Recommendation Q.86 (10/9

7、5) 5The SC Function (SCF)The SCF is a function that commands call control functions in the processing of IN provided and/or custom servicerequests. The SCF may interact with other functional entities to access additional logic or to obtain information (serviceor user data) required to process a call

8、/service logic instance. It:a) interfaces and interacts with Service Switching Function/Call Control Function, Specialized ResourceFunction (SRF) and Service Data Function (SDF) functional entities;b) contains the logic and processing capability required to handle IN-provided service attempts.The SD

9、 Function (SDF)The SDF contains customer and network data for real time access by the SCF in the execution of an IN provided service.It interfaces and interacts with SCFs as required.NOTE The SDF contains data relating directly to the provision or operation of IN provided services. Thus it does notn

10、ecessarily encompass data provided by third party such as credit information, but may provide access to these data.The SR Function (SRF)The SRF provides the specialized resources required for the execution of IN and non-IN provided services (e.g. digitreceivers, announcements, conference bridges, et

11、c.). It:a) interfaces and interacts with SCF and SSF (and with the CCF);b) may contain the logic and processing capability to receive/send and convert information received fromusers;c) may contain functionality similar to the CCF to manage bearer connections to the specialized resources.For the purp

12、oses of this Recommendation, the CCAF is identical with the CCA of Recommendation Q.71. The CCF isbased on the corresponding Q.71 ISDN definitions but modified for the use in IN. The enhanced Basic Call Model of INdefines standard Detection Points (DPs) at which IN service feature logic instances ca

13、n be invoked. These DPscorrespond to the Q.71 “hooks” where an ISDN supplementary service interfaces to the Basic Call Model. For thepurposes of this Recommendation, relationships Rj, Rn, Rm are outside the scope of this Recommendation and areidentical with those defined in Recommendation Q.71. For

14、the purposes of this Recommendation, Rs is identical withrelationship r2 in Recommendation Q.71, since it involves the control of a connection between CCF and SRF in order toprovide specialized resources such as tones and announcements. Network capabilities common to a number ofsupplementary service

15、s for user interaction and their switching and signalling requirements are also outside the scope ofthis Recommendation. Finally, as the Rp and Rr relationships are nationally dependent, only the relation Rq is in thescope of this Recommendation.This Recommendation treats the case where there is no

16、transfer of the users service profile information and SDF(ci) willbe accessed for any query (e.g. validation request) on or update (e.g. threshold update) of the ITCC users data. Note thatthe SDF(ci) does not belong to the card acceptor and it is usually located outside the national boundary.The SDF

17、 associated with the card acceptor network may contain some data related to the provision of ITCC service tothe visiting user. For example, SDF(ca) may contain information on agreements with other ITCC service providers. Noadditional security for interworking is provided other than such knowledge of

18、 existence of service agreements betweenservice providers. SDF(ca) may also contain data on security measures, e.g. the number of retries allowed by theoriginating network to an ITCC user attempting to access ITCC service. It is also assumed that SDF(ci) will also be ableto check that a service agre

19、ement exists with the service provider of the invoking SCF.6 Recommendation Q.86 (10/95)7.7 Information Flows for ITCCThe Information Flows (IFs) and their contents (Information Elements, IEs) are based on those developed by StudyGroup 11 for the IN architecture, as described in clause 6/Q.1214. The

20、 individual IFs are described in 7.7.2 of thisRecommendation. Whether IFs are confirmed or unconfirmed and of type req. ind. or resp. conf. is described here.Information flows and information elements for non-IN can be considered to be equivalent.In the information flow diagrams the CS-1 IF names ar

21、e shown in mixed case lettering, without the req. ind. or resp.conf. descriptors. The full descriptions of these IFs are in 7.7.2 (The individual IFs). IFs derived from Recommen-dation Q.71 are shown in upper case italic letters, with type descriptors.The IFs do not show any IFs relating to timer co

22、ntrol of interaction between FEs. Not all error paths are considered.7.7.1 ITCC proceduresThe ITCC user invokes access to ITCC service by setting up a call to an ITCC card acceptor network. The user is thenconnected to an SRF which provides the mechanism of interaction between the ITCC user and the

23、ITCC card acceptornetwork for the collection of information to enable access to the service.The interactions between the ITCC user and the SRF are assumed to be by DTMF in-band signalling. The SRF alsoprovides voice prompts but specific content of the announcements is beyond the scope of this Recomm

24、endation.The sequence (e.g. PAN, PIN, Called Number) in which the information is sent from the ITCC user to the network is anational matter, and is also beyond the scope of this Recommendation.An outline of the sequence in which the procedures are invoked is shown in Figure 2, exit and error paths a

25、re notincluded.The main body of text of this Recommendation contains the description of the validation and call disposition proceduresfor the ITCC service as defined in Recommendation E.113. Other procedures that are out of the scope of standardization(national dependent) are reported in the appendi

26、xes.7.7.1.1 Validation procedureThe ITCC service is based on an automatic validation procedure that implies that the call handling Administration willquery the database of the card issuing Administration to validate telephone charge cards used by customers who aremaking a call in a country other tha

27、n their own.Recommendation E.113 “Validation procedures for the international telecommunications charge card service” definesthe procedures for the validation process between Administrations. The validation process foresees the followingmessages: Authorization Request (M): is a message from the card

28、 acceptor network to the card issuer networkwhich provides details of an attempt to use a telephone charge card (i.e. card validation). Request Response (M): is a message from the card issuer network to the card acceptor network toprovide either a positive or negative response to the authorization r

29、equest.The following is a high-level description of the network actions required in order to validate the ITCC service.According to Recommendation E.118 describing the card format, the identity of the ITCC card issuer can be deducedfrom the Primary Account Number. Moreover, if there is a service agr

30、eement between the card acceptor and the cardissuer, then the SDF associated with the card acceptor network may contain some data related to the agreements withother ITCC service providers.Recommendation Q.86 (10/95) 7T1166200-94/d02StartAccess and UserIdentification (Figure I.1)OKFollow-onProcedure

31、(Figure VII.1)Follow-on RequestCalled PartyDisconnection(Figure VI.2)Calling PartyDisconnection(Figure VI.1)Max. retries reached andService Logic InitiatedDisconnection(Figure III.1)Limit exceededValidation rejection andRetry (Figure II.1)NOK limitnot reac hedA partyAbandon(Figure V.1)Outgoing Call(

32、Figure IV.1)OKNOKOKEndFIGURE 2/Q.86Outline of sequencing of ITCC proceduresCall Disposition(Figure 4)ValidationProcedureFIGURE 2/Q.86.D02 = 3 CM (118%)Procedures for the SRF to the interface with the calling user in order to collect his information or to provideannouncements is national in nature an

33、d beyond the scope of this Recommendation.Outline1) The originating network requires the card issuer network to validate (Authorization Request) the card.2) The card issuer network undertakes authentication checks and sends back the result (Request Response).8 Recommendation Q.86 (10/95)3) Decision:

34、 if successful, continue the ITCC procedures; if unsuccessful and subsequent attempts allowed, advise user of failure and restart the uservalidation; if unsuccessful and no subsequent attempts allowed, advise user and release the call.7.7.1.1.1 Information flow diagramThe following diagram (Figure 3

35、) shows the validation procedure.T1166210-94/d03SearchSearch ResultScreenSIBFIGURE 3/Q.86Validation procedure623670900FE2SSF/CCFFE6SCFFE8SRFFE7SDF(ca)FE9SDF(ci)RpRqRrRqFIGURE 3/Q.86.D03 = 3 CM (118%)The validation is undertaken by the ITCC card issuer using the information received by the SCF(ca) in

36、cluding PAN, PINand eventually the Called Number1). If authentication is successful, the ITCC service logic in the originating networkcan continue. If authentication fails, action could proceed to “Authentication rejection and retry” (see Figure II.1) orterminate the call to “Maximum retries reached

37、” (see Figure III.1).7.7.1.2 Call disposition procedureRecommendation E.113 “Validation procedures for the international telecommunications charge card service” foresees,based on bilateral agreement, the procedure for the transmission of call details to the card issuing Administration at theend of e

38、ach ITCC call. This procedure, uses the following message: Call Disposition (O): is a message from the card acceptor network to the card issuer network to trackusage of the card against the credit limit of the customer and gather other statistics. The main purpose ofthis additional message is to pro

39、vide, on a timely basis, better control against potential fraudulent use ofthe charge card._1)PAN (max. 19 digits) PIN (Max. 4 digits)MII = 89CC CLD No. (Recommendation E.164)Issuer ID CLG No. (Recommendation E.164)ACT No.Recommendation Q.86 (10/95) 9The following is a high-level description of the

40、network actions required in order to update the threshold in SDF(ci).Outline1) The originating network sends to the card issuer network the call details including the estimated charge assoon as the call is completed.2) The card issuing network updates the usage value of the card and sends back a res

41、ponse.3) If follow-on is foreseen, a trigger condition was met during the called party initiated disconnection; theaction proceeds to “Follow-on” (see Figure VII.1).It is assumed that the appropriate points of control for detecting call abandon of the Calling party and the call disconnectof Calling/

42、Called party will always be appropriately armed.Call details information to be sent in a Call Disposition message must be obtained from the SSF upon completion of acall. Procedures to provide this information by SSF to SCF are national in nature and beyond the scope of thisRecommendation (see Figure

43、 IV.1).7.7.1.2.1 Information flow diagramThe following diagram (Figure 4) shows the Call Disposition procedure.T1166220-94/d04901Update DataService DataManagement SIBUpdateConfirmationFIGURE 4/Q.86Call Disposition procedureNOTE If follow-on is foreseen, a trigger condition was met during the called

44、party initiated disconnection (see Figure VI.2, FEA 603), the action now proceeds to “Follow-on Recognition” (see Figure VII.1).(Note)FE2SSF/CCFRpFE6SCFFE8SRFFE7SDF(ca)FE9SDF(ci)RqRqRrFIGURE 4/Q.86.D04 = 3 CM (118%)The Call Disposition procedure updates the ITCC service profile adding details relate

45、d to the call documentationincluding the estimated call charge. Note that the confirmation response from the SDF(ci) to SCF(ca) could be notrequested.7.7.2 Definition of individual information flowsThe Information Flows (IFs) contained in this subclause are those described in clauses 5 and 6/Q.1214.

46、 The informationelements (IEs) shown as those which are either mandatory (M) or Optional but needed for ITCC service (O). All of themare related to the SCF-SDF interface.10 Recommendation Q.86 (10/95)NOTE 1 As far as the SCF-SDF interface is concerned, Study Group XI/4 decided to use the X.500 proto

47、col for theSCF-SDF interface. After the September 1994 meeting, this Recommendation will be updated in order to consider the necessarymodifications.The IFs are also cross-referenced to the Service Independent Building Block (SIB) in which the IF is described inclause 5/Q.1214.NOTE 2 Based on the SG

48、4/11 final decision, also the Service Independent Building Block (SIB) description inclause 5/Q.1214 has to be updated accordingly.The IFs related to the SSF-SCF and SRF-SSF interfaces, as stated in 7.7.1, are outside the scope of thisRecommendation as they refer to a part of the architecture that m

49、ay be implemented both using IN/non-IN model. Forsimplicity, these IFs are shown in Appendix I.7.7.2.1 Relationship Rq (SCF-SDF)The abbreviations for the SIBs and the relevant subclause numbers in Recommendation Q.1214 are: Screen Screen 5.2.8/Q.1214 Service Data Management SDM 5.2.9/Q.1214The Screen SIB provides the capability for the SCF to perform a comparison of an identifier against a list located in aspecified storage space in the SDF.The Service Data Management SIB provides the capability for the SCF to: retrieve, replace, increme