1、INTERNATIONAL TELECOMMUNICATION UNION ITU=T TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU Q.1238.6 SERIES Q: SWITCHING AND SIGNALLING Intelligent Network (06/2000) I n terface Recom men dation for i n te I I i g e n t network capability set 3: SCF-SCF interface ITU-T Recommendation Q. 1238.6 (Form
2、erly CCITT Recommendation) ITU-T Q-SERIES RECOMMENDATIONS SWITCHING AND SIGNALLING SIGNALLING IN THE INTERNATIONAL MANUAL SERVICE FUNCTIONS AND INFORMATION FLOWS FOR SERVICES IN THE ISDN SPECIFICATIONS OF SIGNALLING SYSTEMS No. 4 AND No. 5 SPECIFICATIONS OF SIGNALLING SYSTEM No. 6 SPECIFICATIONS OF
3、SIGNALLING SYSTEM R1 SPECIFICATIONS OF SIGNALLING SYSTEM i22 DIGITAL EXCHANGES INTERWORKING OF SIGNALLING SYSTEMS SPECIFICATIONS OF SIGNALLING SYSTEM No. 7 43 INTERFACE DIGITAL SUBSCRIBER SIGNALLING SYSTEM No. 1 PUBLIC LAND MOBILE NETWORK INTERWORKING WITH SATELLITE MOBILE SYSTEMS INTELLIGENT NETWOR
4、K SPECIFICATIONS OF SIGNALLING RELATED TO BEARER INDEPENDENT CALL CONTROL (BICC) BROADBAND ISDN INTERNATIONAL AUTOMATIC AND SEMI-AUTOMATIC WORKING CLAUSES APPLICABLE TO ITU-T STANDARD SYSTEMS SIGNALLING REQUIREMENTS AND PROTOCOLS FOR IMT-2000 4.14.3 4.44.59 4.60-4.99 Q.lOO-Q.119 Q.12O-Q.249 4.2504.3
5、09 4.3 10-Q.399 4.400-4.499 Q.50O-Q.599 4.600-4.699 Q.70O-Q.799 Q.80O-Q.849 Q.85O-Q.999 Q. 1 OOO-Q. 1099 Q. 1 10O-Q. 1 199 Q.120-Q.1699 Q.170O-Q.1799 Q. 19004.1999 Q.200O-Q.2999 Forfurther details, please refer to the list of ITU-T Recommendations. ITU-T Recommendation Q.1238.6 Interface Recommendat
6、ion for intelligent network capability set 3: SCF-SCF interface Summary The Q.1238.x series of ITU-T Recommendations defines the Intelligent Network (IN) Application Protocol (INAP) for IN Capability Set 3 (IN CS-3), the INAP for IN CS-3 based upon IN CS-2 Q. 1224 and Q. 1228 specifications (1997),
7、and the general rules for INAP provided in ITU-T Q. 1208, and is consistent with the scope of IN CS-3 as defined in ITU-T 4.1231. Within the 4.1230 series of ITU-T Recommendations, the Q.1238.x series describes the protocol realizing the 4.1231 Distributed Functional Plane in a service and vendor im
8、plementation independent manner, as constrained by the capabilities of the embedded base of network technology. This provides the flexibility to allocate distributed functionality into multiple physical network configurations and to evolve IN from IN CS-3 to some future CS-N. This Recommendation bel
9、ongs to the Q.1238.x series of ITU-T Recommendations for IN Capability Set 3. It covers the SCF-SCF interface including the description of the aspects of the SCF Functional Entity which are relevant to this interface. This Recommendation includes an electronic attachment containing ASN.l description
10、s of clauses 10,ll and 12. Source IT-T Recommendation 4.1238.6 was prepared by ITU-T Study Group 11 (1997-2000) and approved under the WTSC Resolution 1 procedure on 15 June 2000. Keywords Intelligent Networks, INN. ITU-T 4.1238.6 (06/2000) i FOREWORD The International Telecommunication Union 0 is t
11、he United Nations specialized agency in the field of telecommunications. The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing
12、telecommunications on a worldwide basis. The World Telecommunication Standardization Conference (WTSC), which meets every four years, estabiishes the topics for study by the IT-T study groups which, in turn, produce Recommendations on these topics. The approval of ITU-T Recommendations is covered by
13、 the procedure laid down in WTSC Resolution 1. In some areas of information technology which fall within IT-Ts purview, the necessary standards are prepared on a collaborative basis with IS0 and IEC. NOTE In this Recommendation, the expression “Administration“ is used for conciseness to indicate bot
14、h a telecommunication administration and a recognized operating agency. INTELLECTUAL PROPERTY RIGHTS ITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the ev
15、idence, validity or applicability of claimed Intellectual Property Rights, whether asserted by members or others outside of the Recommendation development process. As of the date of approval of this Recommendation, ITU had not received notice of intellectual property, protected by patents, which may
16、 be required to implement this Recommendation. However, impiementors are cautioned that this may not represent the latest information and are therefore strongly urged to consuit the TSB patent database. o ITU 2001 All rights reserved. No part of this publication may be reproduced or utilized in any
17、form or by any means, electronic or mechanical, including photocopying and microflm, without permission in writing the SCME-Control, as defined in ITU-T 4.1238.1; the SCME-FSM which handles the traffic flow control procedures; the SCSM-SCF, which supports the procedures that are specific to this rel
18、ationship. 2 ITU-T 4.1238.6 (06/2000) SSF SRF SDF SMF CUSF I I SCF I TI 110814ooo Figure 2lQ.1238.6 - SCF FSM model The interaction with another SCF is possible from any state of the invoking SCF. In the following subclauses, the SCF related states are specified. The models describe the relationship
19、 of one SCF with another SCF on both sides of the relationship. If an SCF needs to access another SCF a new FSM of type SCSM-SCF, should be instantiated. There are four different types of SCSM-SCF instances. - Instances of type SCSM-Sup and SCSM-Con handle the interactions between SCFs, for the supp
20、orting and controlling role respectively. Instances of type SCSM-ChI and SCSM-ChT handle the interactions between SCFs, for chaining initiation and termination. - In what follows, the states and events associated with each of these types of FSMs are described. 6.1 SCMEFSM The SCME-FSM is either a TF
21、C Initiator finite state model or a TFC Responder finite state model. 6.1.1 The TFC Initiator finite state model (FSM) which is located in SCME-FSM is depicted in Figure 3. State transition model for TFC Initiator related states ITU-T Q.1238.6 (06/2000) 3 b (el) Bind I - I 2. Wait for TFC I (e6)Unbi
22、nd e I I I 4 3. Wait for 1. Idle BindRemit (e2) TFC (E4) TFCBindEmr (e6) Unbind I T111l5MW) (e6) Unbind (e2) TFC Figure 3/Q.1238.6 - State model for TFC initiator Each state is discussed in one of the following subclauses. General rules applicable to more than one state are as follows: In any state,
23、 if the dialogue with the Responder is terminated, then the TFC Initiator FSM returns to “Idle“ state after ensuring that any resources allocated to the dialogue have been de-allocated. 6.1.1.1 State 1: “Idle“ This state is the initial state for the FSM after it has been created by the FE message ma
24、nagement. The only event accepted in this state is: - (e1)Bind: On receipt of this event the FSM constructs a TFCBind operation. This event causes a transition out of this state to State 2, “Wait for TFC“. 6.1.1.2 In this state, a Bind request has been received fiom the Application and a TFCBind ope
25、ration has been constructed, but not sent. Three events are considered in this state: - (e2)TFC: This event causes a TrafficFiowControl operation to be constructed. The TFCBind and TrafficFlowControl operations are sent to the remote TFC Responder FSM and the event causes a transition out of this st
26、ate to State 3, “Wait for BindResult“; (e3)delhiter: This event causes the cons-ucted TFCBind operation to be sent to the remote TFC Responder FSM and the event causes a transition out of this state to State 3, “Wait for BinResult“; and (e6)Unbind: This event causes the constructed TFCBind operation
27、 to be discarded and causes a transition out of this state to State 1, “Idle“. State 2: “Wait for TFC“ - - 6.1.13 The following events are considered in this state: - State 3: “Wait for BindResult“ (e2) TFC: This event causes the FSM to saves the event to be processed after a transition to another s
28、tate occurs. The FSM remains in the same state; (E4)TFCBindError: This event causes the FSM to notie the Application that the association establishment failed and causes a transition out of this state to State 1 , “Idle“; - 4 ITU-T 4.1238.6 (06/2000) - (E5)TFCBindResult: This event causes the FSM to
29、 notify the Application that the association establishment succeeded and transitions out of this state to State 4, “Active“; and (e6) Unbind: This event causes the FSM to construct and send an IN-Unbind to the remote TFC Responder FSM and causes a transition out of this state to State 1, “Idle“. - 6
30、.1.1.4 State 4: “Active“ The following events are considered in this state: - (e2) TFC: This event causes a TraffcFlowControl operation to be constructed and sent to the remote TFC Responder FSM. The FSM remains in the same state; and (e6) Unbind: This event causes the FSM to construct and send an I
31、N-Unbind to the remote TFC Responder FSM and causes a transition out of this state to State 1, “Idle“. State transition model for TFC Responder related states - 6.1.2 The TFC Responder finite state model (FSM) is depicted in Figure 4. T (El) TFCBind T111081 (e3) BindError: This event causes the FSM
32、to construct a tfcBindError error message and sends it to the remote TFC Initiator FSM and causes a transition out of this state to State 1, “Idle“; (e4)BindResult: This event causes the FSM to construct a tfcBindResult message and sends it to the remote TFC Initiator FSM and causes a transition out
33、 of this state to State 3, “Active“; (E5) TFCUnbind: This event causes the FSM to notifj the Application that the association has been terminated by an IN-Unbind operation from the remote TFC Initiator FSM and causes a transition out of this state to State 1, “Idle“. - - - 6.1.2.3 State 3: “Active“
34、The following events are considered in this state: - (E2) TFC: This event causes the FSM to noti the Application of the need to process a new traffic flow control request from the remote TFC Initiator FSM. The FSM remains in the same state; and (E5) TFCUnbind: This event causes the FSM to noti the A
35、pplication that the association has been terminated by an IN-Unbind operation from the remote TFC Initiator FSM and causes a transition out of this state to State 1, “Idle“. - 6.2 Cutrlhg SCF FSM (SCSM-COU) The Finite State Machine for an SCF interacting with another SCF when acting as a controlling
36、 SCF is depicted in Figure 5. 6.2.1 State 1: “Ide The following event is considered in this state: - (el) SCF Bind-request: This is an internal event, caused by the need of the service logic to establish a relationship with another SCF and to receive cooperation fiom it, to further proceed with a ca
37、ll. This event causes a transition to State 2, “Preparing Handling Information Request“. It causes SCFBind operation to be issued to the supporting SCF. 6.2.2 In this state, the SCF is preparing a request to the supporting SCF to be assisted in the processing of the call. The following events are co
38、nsidered in this state: - (e2) Send Handling Information Request sent: It causes a Handling Information request operation to be sent the supporting SCF. A TransferSTSI operation may also be sent simultaneously. This event causes a transition to State 3: “Waiting for Bind Result“; (E24) SCF Bind erro
39、r: This is an external event caused by SCFBind operation error reception. It causes a transition back to State 1, “Idle“. (e25) SCFUnbind This is an internal event causing sending of IN-Unbind (e.g. because the SCFBind result timer is expired). It causes a transition back to State 1, “Idle“. State 2
40、: “Preparing Handling Information Request“ - - 6 ITU-T 4.1238.6 (06/2000) 6.2.3 In this state, the SCF is waiting the result to Bind request. The following events are considered in this state: - (E3) SCF Bind error: This is an external event caused by the reception of the error result of the previou
41、sly issued Bind operation. It causes a transition back to State 1, “Idle“. (E4) SCF Bind successful: This is an external event caused by the reception of the successful result of the previously issued Bind operation. It causes a transition to State 4, “Assisted Mode“. (e26) Timer expiration: This is
42、 an internal event caused by the expiration of a guard timer. It causes a transition back to State 7, “Preparing SCF Unbind Request“. State 3: “Waiting for Bind Result“ - - 6.2.4 State 4: “Assisted Mode“ In this state, the SCF has sent a request to the supporting SCF to be assisted in the processing
43、 of the call. A relationship has been created between the two SCFs. They are cooperating to provide fnctionalities needed to process a call. The following events can occur in this state: - (E5) Assist-Completed This is an external event caused by the reception of the result of a previously issued op
44、eration. The result indicates that the SCF can continue with the processing of the call and that the assistance of an assisting SCF is not further required. This event causes a transition to the State 7, “Preparing SCF Unbind request“; unless there is a result pending, in which case it stays in Stat
45、e 4, pending the receipt of the requested result. This event is caused by a reception of the following operation: HandlingMormationResult. (e6) End-Assist: This is an internal event caused by the need of the service logic to stop its relationship with the supporting service logic. This event causes
46、a transition to the State 7, “Preparing SCF Unbind request“. (E7) Additional-Information-Required-fiom-SCF: This is an external event caused by the reception of a operation om the supporting SCF requesting additional information to be able to assist the controlling SCF. This event causes a transitio
47、n out of this state to State 5 , “Preparing Additional Information“. This event is caused by a reception of a following operation: ProvideUserInformation. NetworkCapabilityRequest. Runuserscript. (es) Notification_Provided-to-Supporting-SCF-without-Conation-Ruest: This is an internal event caused by
48、 the need of the service logic to provide notification for the supporting SCF without the confirmation request. This event causes a transition to the same state, State 4 , “Assisted Mode“. It causes one of the following operations to be issued to the supporting SCF: NotificationProvided. ReportCharg
49、ingInformation. (e2 1) Notification-Provided-to-Supporting-SCF-with-Conhnation: This is an internal event caused by the need of the service logic to provide notification for the supporting SCF with the cobation request. It causes one of the following operations to be issued to the supporting SCF: ConfrmedReportChargingInformation. ConfrmedNotificationProvided. - - - - ITU-T 4.1238.6 (06/2000) 7 (e22) Handling Information Request sent: This is an internal event caused by the need of the service logic, having received the previously requested HandlingInformationResu
