T Rec Q.1238.6 2000

INTERNATIONAL TELECOMMUNICATION UNION
ITU-T
TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU
Q.1238.6
(06/00)
SERIES Q: SWITCHING AND SIGNALLING INTELLIGENT NETWORK
Interface recommendation for intelligent network capability set 3: SCF-SCF interface
CAUTION ! PREPUBLISHED RECOMMENDATION

This text is a non-edited version of a recently approved Recommendation. It shall be replaced by the final version after edition. Consequently, some discrepancies may appear between this text and its final edited form.
FOREWORD ITU (International Telecommunication Union) is the United Nations Specialized Agency in the field of telecommunications. The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of the ITU. The ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The World Telecommunication Standardization Conference (WTSC), which meets every four years, establishes the topics for study by the ITU-T Study Groups which, in their turn, produce Recommendations on these topics. The approval of Recommendations by the Members of the ITU-T is covered by the procedure laid down in WTSC Resolution No. 1. In some areas of information technology which fall within ITU-Ts purview, the necessary standards are prepared on a collaborative basis with ISO and IEC.
NOTE In this Recommendation, the expression "Administration" is used for conciseness to indicate both a telecommunication administration and a recognized operating agency.
INTELLECTUAL PROPERTY RIGHTS The ITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. The ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of the Recommendation development process. As of the date of approval of this Recommendation, the ITU had/had not received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementors are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database.
ITU All rights reserved. No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from the ITU.
TSB NOTE: 1) The ASN.1 text [Sections 10 to 12] will be available in electronic form for the final publication. 2) For this COM 11 Report, the ASN.1 text is available electronically from the SG 11 web page http://www.itu.int/itudoc/itu-t/com11/reports.
Recommendation Q.1238.6 (06/00) Prepublished version
ITU-T RECOMMENDATION Q.1238.6 INTERFACE RECOMMENDATION FOR INTELLIGENT NETWORK CAPABILITY SET 3: SCF-SCF INTERFACE Summary Recommendation series Q.1238.x defines the Intelligent Network (IN) Application Protocol (INAP) for IN Capability Set 3 (IN CS-3). Series Q.1238.x defines the INAP for IN CS-3 based upon IN CS-2 Q.1224 and Q.1228 specifications (1997), and the general rules for INAP provided in Q.1208, and is consistent with the scope of IN CS-3 as defined in Q.1231. Within the Q.123.x Recommendation series, series Q.1238.x describes the protocol realizing the Q.1231 Distributed Functional Plane in a service and vendor implementation 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. Q.1238.6 belongs to ITU-T Recommendation series Q.1238.x 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. Keywords: Intelligent Networks, INAP
CONTENTS Page 1 2 3 4 5 6 6.1 6.1.1 6.1.2 6.2 6.2.1 6.2.2 6.2.3 6.2.4 6.2.5 6.2.6 6.3 6.3.1 6.3.2 6.3.3 6.3.4 6.4 6.4.1 6.4.2 6.4.3 6.4.4 6.5 6.5.1 6.5.2 6.5.3 7 7.1 7.1.1 7.1.2 7.1.3 7.2 7.2.1 7.2.2 7.2.3 7.3 7.3.1 7.3.2 7.3.3 7.4 7.4.1 7.4.2 7.4.3 Scope ........................................................................................................................... References ................................................................................................................... Abbreviations and acronyms....................................................................................... SCF-SCF relationship ................................................................................................. SCF FE Model............................................................................................................. SCF FSM..................................................................................................................... SCME FSM................................................................................................................. State transition model for TFC Initiator related states ................................................ State transition model for TFC Responder related states............................................ Controlling SCF FSM (SCSM-Con)........................................................................... State 1: Idle ................................................................................................................. State 2: Preparing Handling Information Request ...................................................... State 3: Waiting for Bind Result ................................................................................. State 4: Assisted Mode................................................................................................ State 5: Preparing Additional Information.................................................................. State 7: Preparing Unbind request............................................................................... Supporting SCF FSM (SCSM-Sup)............................................................................ State 1: Idle ................................................................................................................. State 2: Processing SCF Bind ..................................................................................... State 3: Assisting mode............................................................................................... State 4: Waiting for Additional Information............................................................... SCF state transition models for chaining initiation (SCSM-ChI) ............................... State 1: "Idle" .............................................................................................................. State 2: "Prepare Chained HIreq'"............................................................................... State 3: "Wait for Bind Result" ................................................................................... State 4: "SCF Bound".................................................................................................. SCF state transition models for chaining termination (SCSM-ChT) .......................... State 1: "Idle" .............................................................................................................. State 2: "Bind Pending" .............................................................................................. State 3: "SCF Bound".................................................................................................. Detailed Operation Procedures ................................................................................... ActivityTest procedure................................................................................................ General description ..................................................................................................... Invoking entity (SCF) ................................................................................................. Responding entity (controlling SCF or supporting SCF)............................................ ChainedConfirmedNotificationProvided procedure ................................................... General description ..................................................................................................... Invoking entity (chaining initiator supporting SCF)................................................... Responding entity (chaining terminator supporting SCF) .......................................... ChainedConfirmedReportChargingInformation procedure ........................................ General description ..................................................................................................... Invoking entity (chaining initiator supporting SCF)................................................... Responding entity (chaining terminator supporting SCF) .......................................... ChainedEstablishChargingRecord procedure ............................................................. General description ..................................................................................................... Invoking entity (chaining terminator supporting SCF)............................................... Responding entity (chaining initiator supporting SCF) .............................................. 9 9 9 9 10 10 11 12 13 14 14 15 15 15 17 17 18 18 19 19 21 22 23 23 24 24 25 25 25 26 26 26 26 27 27 27 27 28 28 29 29 29 29 30 30 30 30
Page 7.5 7.5.1 7.5.2 7.5.3 7.6 7.6.1 7.6.2 7.6.3 7.7 7.7.1 7.7.2 7.7.3 7.8 7.8.1 7.8.2 7.8.3 7.9 7.9.1 7.9.2 7.9.3 7.10 7.10.1 7.10.2 7.10.3 7.11 7.11.1 7.11.2 7.11.3 7.12 7.12.1 7.12.2 7.12.3 7.13 7.13.1 7.13.2 7.13.3 7.13.4 7.14 7.14.1 7.14.2 7.14.3 7.14.4 7.15 7.15.1 7.15.2 7.15.3 7.15.4 7.16 7.16.1 ChainedHandlingInformationRequest procedure........................................................ General description ..................................................................................................... Invoking entity (chaining initiator supporting SCF)................................................... Responding entity (chaining terminator supporting SCF) .......................................... ChainedHandlingInformationResult procedure .......................................................... General description ..................................................................................................... Invoking entity (chaining terminator supporting SCF)............................................... Responding entity (chaining initiator supporting SCF) .............................................. ChainedNetworkCapability procedure........................................................................ General description ..................................................................................................... Invoking entity (chaining terminator supporting SCF)............................................... Responding entity (chaining initiator supporting SCF) .............................................. ChainedNotificationProvided procedure..................................................................... General description ..................................................................................................... Invoking entity (chaining initiator supporting SCF)................................................... Responding entity (chaining terminator supporting SCF) .......................................... ChainedReportChargingInformation procedure.......................................................... General description ..................................................................................................... Invoking entity (chaining initiator supporting SCF)................................................... Responding entity (chaining terminator supporting SCF) .......................................... ChainedProvideUserInformation procedure ............................................................... General description ..................................................................................................... Invoking entity (chaining terminator supporting SCF)............................................... Responding entity (chaining initiator supporting SCF) .............................................. ChainedRequestNotification procedure ...................................................................... General description ..................................................................................................... Invoking entity (chaining terminator supporting SCF)............................................... Responding entity (chaining initiator supporting SCF) .............................................. ChainedRunUserScript procedure............................................................................... General description ..................................................................................................... Invoking entity (chaining terminator supporting SCF)............................................... Responding entity (chaining initiator supporting SCF) .............................................. ConfirmedNotificationProvided procedure................................................................. General description ..................................................................................................... Parameters ................................................................................................................... Invoking entity (controlling SCF)............................................................................... Responding entity (supporting SCF)........................................................................... ConfirmedReportChargingInformation procedure...................................................... General description ..................................................................................................... Parameters ................................................................................................................... Invoking entity (controlling SCF)............................................................................... Responding entity (supporting SCF)........................................................................... EstablishChargingRecord procedure........................................................................... General description ..................................................................................................... Parameters ................................................................................................................... Invoking entity (supporting SCF) ............................................................................... Responding entity (controlling SCF) .......................................................................... HandlingInformationRequest procedure..................................................................... General description ..................................................................................................... 31 31 31 32 32 32 32 33 33 33 33 34 34 34 34 35 35 35 35 36 36 36 36 37 37 37 37 38 38 38 38 39 39 39 39 39 40 40 40 40 41 41 42 42 42 42 43 43 43
Page 7.16.2 7.16.3 7.16.4 7.17 7.17.1 7.17.2 7.17.3 7.17.4 7.18 7.18.1 7.18.2 7.18.3 7.19 7.19.1 7.19.2 7.19.3 7.20 7.20.1 7.20.2 7.20.3 7.21 7.21.1 7.21.2 7.21.3 7.21.4 7.22 7.22.1 7.22.2 7.22.3 7.22.4 7.23 7.23.1 7.23.2 7.23.3 7.23.4 7.24 7.24.1 7.24.2 7.24.3 7.24.4 7.25 7.25.1 7.25.2 7.25.3 7.25.4 7.26 7.26.1 7.26.2 Parameters ................................................................................................................... Invoking entity (controlling SCF)............................................................................... Responding entity (supporting SCF)........................................................................... HandlingInformationResult procedure........................................................................ General description ..................................................................................................... Parameters ................................................................................................................... Invoking entity (supporting SCF) ............................................................................... Responding entity (controlling SCF) .......................................................................... IN-Unbind procedure .................................................................................................. General description ..................................................................................................... Invoking entity ............................................................................................................ Responding entity........................................................................................................ IN-Unbind procedure (in the chaining case)............................................................... General description ..................................................................................................... Invoking entity (chaining initiator supporting SCF)................................................... Responding entity (chaining terminator supporting SCF) .......................................... NetworkCapability procedure ..................................................................................... General description ..................................................................................................... Parameters ................................................................................................................... Invoking entity (supporting SCF) ............................................................................... NotificationProvided procedure .................................................................................. General description ..................................................................................................... Parameters ................................................................................................................... Invoking entity (controlling SCF)............................................................................... Responding entity (supporting SCF)........................................................................... ProvideUserInformation procedure............................................................................. General description ..................................................................................................... Parameters ................................................................................................................... Invoking entity (supporting SCF) ............................................................................... Responding entity (controlling SCF) .......................................................................... ReportChargingInformation procedure....................................................................... General description ..................................................................................................... Parameters ................................................................................................................... Invoking entity (controlling SCF)............................................................................... Responding entity (supporting SCF)........................................................................... RequestNotification procedure.................................................................................... General description ..................................................................................................... Parameters ................................................................................................................... Invoking entity (supporting SCF) ............................................................................... Responding entity (controlling SCF) .......................................................................... RunUserScript procedure ............................................................................................ General description ..................................................................................................... Parameters ................................................................................................................... Invoking entity (supporting SCF) ............................................................................... Responding entity (controlling SCF) .......................................................................... SCFBind procedure..................................................................................................... General description ..................................................................................................... Parameters ................................................................................................................... 43 44 45 45 45 45 46 46 47 47 47 47 47 47 47 48 48 48 48 48 49 49 49 49 50 50 50 50 51 51 52 52 52 52 53 53 53 53 54 54 54 54 54 55 55 56 56 56
Page 7.26.3 7.26.4 7.27 7.27.1 7.27.2 7.27.3 7.28 7.28.1 7.28.2 7.28.3 7.28.4 7.29 7.29.1 7.29.2 7.29.3 7.29.4 7.30 7.30.1 7.30.2 7.30.3 7.30.4 7.30.5 7.30.6 8 8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 8.9 8.10 8.11 8.12 8.13 8.14 8.15 8.16 8.17 8.18 8.19 8.20 8.21 8.22 8.23 8.24 Invoking entity (Controlling SCF) .............................................................................. Responding entity (supporting SCF)........................................................................... SCFBind procedure (in the chaining case).................................................................. General description ..................................................................................................... Invoking entity (chaining initiator supporting SCF)................................................... Responding entity (chaining terminator supporting SCF) .......................................... TFCBind procedure..................................................................................................... General description ..................................................................................................... Parameters ................................................................................................................... Invoking entity ............................................................................................................ Responding entity (responding SCF) .......................................................................... TrafficFlowControl procedure .................................................................................... General description ..................................................................................................... Parameters ................................................................................................................... Invoking entity (Initiating SCF).................................................................................. Responding entity (Responding SCF)......................................................................... TransferSTSI procedure .............................................................................................. General description ..................................................................................................... Parameters ................................................................................................................... Invoking entity (controlling SCF)............................................................................... Invoking entity (supporting SCF) ............................................................................... Responding entity (supporting SCF)........................................................................... Responding entity (controlling SCF) .......................................................................... Parameters ................................................................................................................... AccountNumber .......................................................................................................... Acksequence ............................................................................................................... Actions ........................................................................................................................ ActiveSupplementaryServices .................................................................................... AgreementID............................................................................................................... BearerCapabilities ....................................................................................................... BearerCapability ......................................................................................................... CalledPartyNumber..................................................................................................... CallingPartyBusinessGroupID.................................................................................... CallingPartysCategory ................................................................................................ CallingPartyNumber ................................................................................................... CallRecord................................................................................................................... Carrier ......................................................................................................................... CauseOfLastCallFailure.............................................................................................. ChargingParameters .................................................................................................... Constraints .................................................................................................................. ConsumedCreditAction............................................................................................... Container ..................................................................................................................... ControlType ................................................................................................................ CounterValues............................................................................................................. CorrelationID .............................................................................................................. Credentials................................................................................................................... DialledDigits ............................................................................................................... Duration....................................................................................................................... 56 57 57 57 57 58 58 58 58 58 59 59 59 59 60 60 61 61 61 61 62 62 62 63 63 63 63 63 63 63 63 63 63 63 64 64 64 64 64 64 64 64 64 64 64 65 65 65
Page 8.25 8.26 8.27 8.28 8.29 8.30 8.31 8.32 8.33 8.34 8.35 8.36 8.37 8.38 8.39 8.40 8.41 8.42 8.43 8.44 8.45 8.46 8.47 8.48 8.49 8.50 8.51 8.52 8.53 8.54 8.55 8.56 8.57 8.58 8.59 8.60 8.61 8.62 8.63 8.64 8.65 8.66 8.67 8.68 9 9.1.1 9.1.2 9.1.3 ErrorInfo...................................................................................................................... Extensions ................................................................................................................... HighLayerCompatibilities........................................................................................... HighLayerCompatibility ............................................................................................. InfoToSend.................................................................................................................. InvokedSupplementaryService ................................................................................... LocationNumber ......................................................................................................... Notification ................................................................................................................. NotificationInformation .............................................................................................. NumberOfAllowedRetries .......................................................................................... NumberOfCallAttempts .............................................................................................. OriginalCalledPartyID ................................................................................................ OriginatingScf ............................................................................................................. OriginatingScfAddress................................................................................................ PreferredLanguage ...................................................................................................... RedirectionInformation ............................................................................................... RedirectingPartyID ..................................................................................................... RemainingUserCredit.................................................................................................. ReportAddress............................................................................................................. ReportCondition.......................................................................................................... ReportExpected ........................................................................................................... RequestedType............................................................................................................ ResetOfTransmisttedCounters .................................................................................... RespondingScfAddress ............................................................................................... RoutingAddress........................................................................................................... SecurityParameters...................................................................................................... ScfAuthenticationLevel............................................................................................... ScfID ........................................................................................................................... Splitcharge................................................................................................................... SrfAddress................................................................................................................... SSIInfo ........................................................................................................................ SupplementaryServices ............................................................................................... Target .......................................................................................................................... Timelimit..................................................................................................................... TfcCriteria ................................................................................................................... TraceInformation......................................................................................................... TypeOfRequestedInfo ................................................................................................. UltimateResponder...................................................................................................... UniqueCallID .............................................................................................................. UserCredit ................................................................................................................... UserInformation .......................................................................................................... UserInteractionModes ................................................................................................. UserToConnect ........................................................................................................... WasChained ................................................................................................................ Error Procedures.......................................................................................................... ChainingRefused ......................................................................................................... ImproperCallerResponse............................................................................................. MissingCustomerRecord............................................................................................. 65 65 65 65 65 65 65 66 66 66 66 66 66 66 66 66 66 66 67 67 67 67 67 67 67 67 67 67 68 68 68 68 68 68 68 68 69 69 69 69 69 69 69 69 69 71 72 73
Page 9.1.4 9.1.5 9.1.6 9.1.7 9.1.8 9.1.9 9.1.10 9.1.11 9.1.12 9.1.13 9.1.14 10 10.1 10.2 11 12 12.1 13 13.1 13.2 13.3 13.4 MissingParameter........................................................................................................ ParameterOutOfRange ................................................................................................ ScfReferral .................................................................................................................. Security ....................................................................................................................... SystemFailure.............................................................................................................. UnexpectedComponentSequence................................................................................ UnexpectedDataValue................................................................................................. UnexpectedParameter ................................................................................................. ScfBindFailure ............................................................................................................ ScfTaskRefused........................................................................................................... TFCBindError ............................................................................................................. ASN.1 definitions........................................................................................................ Data types.................................................................................................................... Information object classes........................................................................................... Operations and Arguments.......................................................................................... Packages, Contracts..................................................................................................... ASN.1 modules ........................................................................................................... Services assumed from TCAP .................................................................................... Normal Procedures...................................................................................................... Abnormal Procedures.................................................................................................. Dialogue Handling ...................................................................................................... Component Handling .................................................................................................. 73 74 74 75 75 75 76 76 76 77 77 78 79 86 88 100 100 106 106 106 107 110
ITU-T Recommendation Q.1238.6 INTERFACE RECOMMENDATION FOR INTELLIGENT NETWORK CAPABILITY SET 3: SCF-SCF INTERFACE 1 Scope
Recommendation Q.1238.6 belongs to series Q.1238.x for IN Capability Set-3. It specifies the protocol on the SCF-SCF interface and provides a description of the aspects of the SCF Functional Entity which are involved in the realization of this interface. 2 References
All ITU-T Recommendations and other documents referred to in this text are identified in Recommendation Q.1238.1. 3 Abbreviations and acronyms
All abbreviations and acronyms used in this text are defined in Recommendation Q.1238.1. 4 SCF-SCF relationship
This SCF-SCF relationship is used for information exchange between two SCFs in the public network. The relationship supports call-related operations, which can be for intranetwork or internetwork purposes. The SCF-SCF relationship supports the exchange of information between services during call processing. The SCF-SCF relationship is also one of a limited set of relationships to support internetworking. As such, it provides a point of interconnection to the network, effectively hiding the specific structure of the network and providing access security to the network from other public networks. The SCF-SCF relationship is used for various purposes. Each of these purposes can apply to the intranetwork, or internetwork cases. Specifically, the relationship is used for the following: a) Distribution of Service Logic between SCFs. It is possible that a given SCF may only contain a service logic program to complete part of a service, such as Customized Call Routing. Service completion may rely on the outcome of service logic in another SCF to be performed. This will require coordination and synchronization between the SCFs and may be provided by explicit, solicited notifications. In case of error situations, generic error indications returned locally (within the same network) to the SCF by its associated SDF may be interpreted to service specific denial causes by the SCF of that network and can be sent as such to the SCF of the interconnecting network. b) Unsolicited Notifications of events taking place within the domain of a given SCF are provided to other SCFs in an unsolicited manner. For example, after an internetwork handover when the initial network provides the anchor point, subsequent handovers may require notifications to the initial network to optimize internetwork connections.
SCF FE Model
The SCF Function Entity overall model is described in Recommendation Q.1238.1. Figure 1/Q.1238.6 highlights the main components of this model.
SLP library SLP manager Service logic execution manager Service logic selection/ interaction manager Interwork manager Service logic processing program instances Resource manager Operational data Service logic execution environment (SLEE) Functional routine library Functional routine manager SCF data access manager
Functional routine Service data object directory IN network-wide resource data
Security Manager Functional entity access manager SCF SMF SSF SRF SDF IAF SCF CUSF
T11108130-00 (102349)
FIGURE 1/Q.1238.6 SCF FE Model
SCF FSM
The SCF FSM overall model is described in Recommendation Q.1238.1. Figure 2/Q.1238.6 highlights the main components of this model which are involved in the SCF-SCF relationship. These are: the Functional Entity Access Manager (FEAM), as defined in Recommendation Q.1238.1; the SCME-Control, as defined in Recommendation Q.1238.1; the SCME-FSM which handles the traffic flow control procedures; the SCSM-SCF, which supports the procedures that are specific to this relationship.
10
SSF
SRF
SDF
SMF
CUSF
SCF
FEAM
SCME-Control
SCSM-SSF/SRF SCSM-SDF
SCSM-SCF
SCME-FSM
SCSM-CUSF SCF
T11108140-00 (102349)
FIGURE 2/Q1238.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 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 supporting 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 SCME FSM
The SCME-FSM is either a TFC Initiator finite state model or a TFC Responder finite state model.
11
6.1.1
State transition model for TFC Initiator related states
The TFC Initiator finite state model (FSM) which is located in SCME-FSM is depicted in Figure 3.
(e1) Bind (e6) Unbind
2. Wait for TFC
(e2) TFC (e3) delimiter 3. Wait for BindResult
1. Idle (E4) TFCBindError (e6) Unbind
(e2) TFC
(E5) TFCBindResult
4. Active (e6) Unbind

T11108150-00 (102349)
(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, 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 management. 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 State 2: "Wait for TFC"
In this state, a Bind request has been received from the Application and a TFCBind operation has been constructed, but not sent. Three events are considered in this state: (e2) TFC: This event causes a TrafficFlowControl 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 state to State 3, Wait for BindResult; (e3) delimiter: This event causes the constructed 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 BindResult; and (e6) Unbind: This event causes the constructed TFCBind operation to be discarded and causes a transition out of this state to State 1, Idle.
12
6.1.1.3
State 3: "Wait for BindResult"
In this state, the following events are considered: (e2) TFC: This event causes the FSM to saves the event to be processed after a transition to another state occurs. The FSM remains in the same state; (E4) TFCBindError: This event causes the FSM to notify the Application that the association establishment failed and causes a transition out of this state to State 1, Idle; (E5) TFCBindResult: This event causes the FSM to 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.1.1.4 State 4: "Active"
In this state, The following events are considered in this state: (e2) TFC: This event causes a TrafficFlowControl 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 IN-Unbind to the remote TFC Responder FSM and causes a transition out of this state to State 1, Idle. 6.1.2 State transition model for TFC Responder related states
The TFC Responder finite state model (FSM) is depicted in Figure 4.
(E1) TFCBind
1. Idle (e3) BindError (E5) TFCUnbind
2. Bind Pending
(E2) TFC
(e4) BindResult
3. Active (E5) TFCUnbind

T11108160-00 (102349)
(E2) TFC
FIGURE 4/Q.1238.6 State model for TFC responder
Each state is discussed in one of the following subclauses. General rules applicable to more than one state are as follows: In any state, if the dialogue with the Responder is terminated, then the TFC Responder FSM returns to Idle state after ensuring that any resources allocated to the dialogue have been de-allocated.
13
6.1.2.1
State 1: "Idle"
This state is the initial state for the FSM after it has been created by the FE message management. The only event accepted in this state is: (E1) TFCBind: This event causes the FSM to notify the Application that a TFC association has been requested by a remote TFC Initiator FSM and causes a transition out of this state to State 2, Bind Pending. 6.1.2.2 State 2: "Bind Pending"
In this state, The following events are considered in this state: (E2) TFC: This event causes the FSM to saves the event to be processed after a transition to another state occurs. The FSM remains in the same state; (e3) BindError: This event causes the FSM 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 of this state to State 3, Active; (E5) TFCUnbind: This event causes the FSM to notify 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. State 3: "Active"
6.1.2.3
In this state, The following events are considered in this state: (E2) TFC: This event causes the FSM to notify 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 notify 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.2 Controlling SCF FSM (SCSM-Con)
The Finite State Machine for an SCF interacting with another SCF when acting as a controlling SCF is depicted in Figure 5/Q.1238.6. 6.2.1 State 1: Idle
The following event is considered in this state: (e1) 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 from it, to further proceed with a call. This event causes a transition to state 2, "Preparing Handling Information Request". It causes SCFBind operation to be issued to the supporting SCF.
14
6.2.2
State 2: Preparing Handling Information Request
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 considered 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 error: 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". 6.2.3 State 3: Waiting for Bind Result
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 previously 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 an internal event caused by the expiration of a guard timer. It causes a transition back to state "Preparing SCF Unbind Request". 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 of the call. A relationship has been created between the two SCFs. They are cooperating to provide functionalities 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 operation. 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 Unbind request"; unless there is a result pending, in which case it stays in state 4, pending the receipt of the requested result. This event is caused by a reception of the following operation: HandlingInformationResult. (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 a transition to the state 7, "Preparing Unbind request". (E7) Additional_Information_Required_from_SCF: This is an external event caused by the reception of a operation from the supporting SCF requesting additional information to be able to assist the controlling SCF. This event causes a transition out of this state to state 5 , "Preparing Additional Information". This event is caused by a reception of a following operation: ProvideUserInformation. NetworkCapabilityRequest. RunUserScript.
15
(e8) Notification_Provided_to_Supporting_SCF_without_Confirmation_Request: This is an internal event caused by 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. ReportChargingInformation. (e21) Notification_Provided_to_Supporting_SCF_with_Confirmation: This is an internal event caused by the need of the service logic to provide notification for the supporting SCF with the confirmation request. The controlling SCF waits the confirmation from the supporting SCF and this event causes a transition out of this state to state 6, "Waiting for Response from Supporting SCF". It causes one of the following operations to be issued to the supporting SCF: ConfirmedReportChargingInformation. ConfirmedNotificationProvided. (e22) Handling Information Request sent: This is an internal event caused by the need of the service logic, having received the previously requested HandlingInformationResult, to request additional information to the supporting SCF. It causes the following operation to be issued to the supporting SCF: HandlingInformationRequest. The controlling SCF waits the response from the supporting SCF, and this event does not cause any transition out of this state. (E23) Confirmation Provided: This is an external event caused by the reception of one of the following operation results: Result of ConfirmedReportChargingInformation. Result of ConfirmedNotificationProvided. It does not cause any transition out of this state. (E19) Charging Information: This is an external event caused by the reception of the EstablishChargingRecord operation. It does not cause any transition out of this state. (E20) Request Notification: This is an external event caused by the reception of the RequestNotification operation. It does not cause any transition out of this state. (E30) Referral from Supporting SCF: This is an external event cause by the reception of a Referral error as the response to the HandlingInformationRequest operation. This event is communicated to the internal service logic and does not cause a state transition out of this state. (e27) STSI send request: This is an internal event caused by the need of the service logic to request additional service information from the supporting SCF or respond the requested additional service information to the Supporting SCF. It causes the following operation to be sent to the Supporting SCF: TransferSTSI. This internal event will not cause any transition out of this state.
16
6.2.5
(E28) STSI received: This is an external event caused by the reception of the TransferSTSI operation. It does not cause any transition out of this state. (E31) UnbindReceived: This is an external event caused by the reception of an Unbind operation from the Supporting SCF. It causes a transition to the Idle state. State 5: Preparing Additional Information
In this state, the SCF is preparing additional information for the supporting SCF so that it can be assisted in the processing of the call. Three events are considered in this state: (e11) Additional_Information_Provided_to_Supporting_SCF: This is an internal event. The SCF has collected all the information needed from the supporting SCF and sends the result to the previously issued operation requesting additional information. This event causes a transition to state 4, Assisted Mode. It causes the return result of the following operation to be issued to the supporting SCF: result of ProvideUserInformation; result of NetworkCapability; result of RunUserScript; or the sending of a TransferSTSI operation. (e12) End_Assist: This is an internal event caused by the need of the service logic to stop its cooperation with the supporting service logic. This event causes a transition back to the state 7, Preparing Unbind request. (E29) UnbindReceived: This is an external event caused by the reception of an Unbind operation from the Supporting SCF. It causes a transition to the Idle state. 6.2.6 State 7: Preparing Unbind request
In this state, the SCF is preparing to send a IN-Unbind operation, to terminate the relationship with the supporting SCF. It causes the following event: (e17) SCF Unbind request: This is an internal event that occurs when IN-Unbind operation is sent. This closes the relationship and causes a transition back to the state 1, "Idle".
17
(e1) Send SCF Bind Request 1. Idle (E24) SCFBind Error, (e25) SCFUnbind (E3) SCFBind error (e17) SCFUnbind Request (e26) Timer Expiration (E5) Assist Completed, (e6) End Assist 7. Preparing SCF Unbind Request (E4) SCF Bind Successful 3. Assisted Mode (E7) Additional Information Required from SCF 2. Preparing Handling Information Request
(e2) Send Handling Information Request
3. Waiting for Bind Result
(E29) Unbind Received
5. Preparing Additional Information
(e11) Additional Information Provided to Supporting SCF (E31) UnbindReceived (e8) Notification Provided to Controlling SCF without Confirmation Request, (E19) Charging Information, (E20) Request Notification, (e21) Notification Provided by Controlling SCF without Confirmation (E23) Confirmation Provided, (e22) Handling Information Request Sent, (E30) Referral from Supporting SCF, (e27) STSI Send Request, (E28) STSI Received
(e12) End Assist
T11108740-00
FIGURE 5/Q.1238.6 SCSM-Con (Controlling SCF FSM) 6.3 Supporting SCF FSM (SCSM-Sup)
The Finite State Machine for an SCF interacting with another SCF when acting as a Supporting SCF is depicted in Figure 6/Q.1238.6. 6.3.1 State 1: Idle
In this state the SCF is waiting for request from other SCFs. No SLPI is started yet. Only the following event is accepted in this state: (E1) "SCF Bind Request Received" this is an external event caused by the reception of a SCFBind request operation from the controlling SCF for providing assistance in the processing of the call. This event causes a transition out of this state to state 2, "Processing SCFBind".
18
6.3.2
State 2: Processing SCF Bind
In this state, the SCF is processing SCFBind operation. The following events are considered in this state: (e2) Send positive SCFBind result. This is an internal event causing the sending of a positive SCFBind result. It does not cause a state transition. (e3) SCF Bind refused: This is an internal that occurs when the supporting SCF does not establish a relationship with the controlling SCF. It causes an SCFBind error to be sent to the controlling SCF. This event causes a transition out of this state to state 1, "Idle". (e24) Timer expiration: This is an internal event caused by guard timer expiration. It does cause a transition back to state 1, "Idle". (E4) Request from controlling SCF: This is an external event caused by the reception of HandlingInformationRequest operation. The HandlingInformationRequest operation is queued since the supporting SCF service logic is involved in the SCFBind processing (it will be processed as soon as the supporting SCF FSM moves to Assisting Mode state). It does not cause a transition out of the state. (e28) SCFBindAccepted & Handling Information Request Received. This is an internal event caused by the fact that the SCFBind operation is accepted and that a HandlingInformationRequest operation has been received. It does not cause any operation to be sent. It causes a transition to Assisting Mode state. (E11) SCF Unbind Request: This is an external event caused by the reception of a request from controlling SCF to end the relationship through IN-Unbind operation. This event causes a transition back to state 1, "Idle". 6.3.3 State 3: Assisting mode
In this state, the SCF is sending operations to provide assistance to the controlling SCF and receives indications from the controlling SCF. The following events are considered in this state. (e5) Assist_Provided: This is an internal event caused by the sending of a response to the assistance request previously received from the controlling SCF, provided that the SCF has not foreseen any further assistance. There is no state transition. It causes the following operation to be issued to the controlling SCF: HandlingInformationResult. (E6) SCF Unbind request received: This is an external event caused by the reception of an SCFUnbind request from controlling SCF. It gives an indication from the controlling SCF that the SCF-SCF relationship needs to be ended. This event causes a transition back to state 1, "Idle". (e7) Additional_Information_Needed: This is an internal event caused by the need of the service logic to receive additional information from the controlling SCF to provide assistance. This event causes a transition out of this state to state 4 "Waiting for Additional Information". It causes the following operation to be issued to the controlling SCF: ProvideUserInformation. NetworkCapability. RunUserScript.
19
(E8) Notification_Provided_without_Confirmation: This is an external event caused by the receipt of the notification which was requested to the controlling SCF. This event causes a transition to the same state, state 3 , "Assisting Mode". This event is caused by a reception of the following operations: ReportChargingInformation. NotificationProvided. (E20) Notification_Provided_with_Confirmation: This is an external event caused by the reception of one of the following operations: ConfirmedReportChargingInformation. ConfirmedNotificationProvided. This event does not cause a transition out of this state (e12) Request Notification: This is an internal event caused by the sending of a RequestNotification operation to the controlling SCF. This event causes a transition to the same state, state 3, "Assisting Mode". (e13) Charging Information: This is an internal event caused by the sending of a EstablishChargingRecord operation to the controlling SCF. This event causes a transition to the same state, state 3, "Assisting Mode". (e21) ConfirmationProvided: This is an internal event caused by the need of the service logic to respond the confirmation previously received request. It causes one of the following operations to be issued to the controlling SCF: ReportChargingInformationConfirmation. NotificationProvidedConfirmation. This event does not cause a transition out of "Assisting mode" state. (e17) Additional_Information_Result: This is an internal event caused by the sending of a response to the previously received request from the controlling SCF." It causes the following operation to be issued to the controlling SCF: HandlingInformationResult. This event does not cause a transition out of this state 3 "Assisting Mode". (e22) Timer expiration: This is an internal that occurs when no operation has been received from the controlling SCF for an appropriate period of time. The supporting SCF determines that the relation is no longer in existence and moves back to "Idle" state. (E25) Received Handling Information Request: This is an external event caused by the reception of a new HandlingInformationRequest operation. It can be accepted only if there is no previous HandlingInformationResult operation pending. This event does not cause a state transition out of this state. (e31) Referral to controlling SCF: This is an internal event caused by the decision to instruct the controlling SCF to send the pending HandlingInformationRequest to another SCF for processing. A Referral error for the HandlingInformationRequest operation is sent to controlling SCF. It does not cause a transition out of "Assisting Mode state" (e32) STSI send request: This is an internal event caused by the need of the service logic to request additional service information from the Controlling SCF or respond the requested additional service information to the Controlling SCF. It causes the following operation to be sent to the Controlling SCF: TransferSTSI.
20
6.3.4
This internal event will not cause any transition out of this state. (E33) STSI received: This is an external event caused by the reception of the TransferSTSI operation. It does not cause any transition out of this state. (e34) Unbind Request: This is an internal event that occurs when an Unbind operation is sent. State 4: Waiting for Additional Information
In this state, the SCF waits for information to be provided by the controlling SCF. This information should help the SCF to provide assistance to the controlling SCF. The following two events are considered in this state: (E14) Additional_Information_Provided: This is an external event caused by the reception of the response to a previously issued operation requesting further information. This event causes a transition out of this state to state 3, "Assisting mode". This event is caused by a reception of the following operation's return result: Result of ProvideUserInformation. Result of NetworkCapability. Result of RunUserScript. (E15) SCF Unbind request received: This is an external event caused by the reception of an SCFUnbind request from controlling SCF. It gives an indication from the controlling SCF that the SCF-SCF relationship needs to be ended. This event causes a transition back to state 1, "Idle". (e22) Timer expiration: This is an internal that occurs when no operation has been received from the controlling SCF for an appropriate period of time. The supporting SCF determines that the relation is no longer in existence and moves back to "Idle state. (e35) Unbind Request: This is an internal event that occurs when an Unbind operation is sent.
21
(E1) SCF Bind Request Received 2. Processing SCF Bind (e3) SCFBind Refused (E11) SCFUnbindRequest (e24) Timer Expiration (e28) SCFBind Accepted & Handling Information Request Received (E4) Request From controlling SCF (e2) Send positive SCF Bind result
1. Idle
(e7) Additional Information needed (e34) SCF Unbind request (E6) SCF Unbind request received (e22) Timer Expiration (E14) Add. Information provided 4. Waiting for Additional Information
3. Assisting Mode
(e5) Assist Provided (E8) Notification Provided without confirmation (e13) ChargingInformation (e12) Request Notification (E20) Notification provided with confirmation (e17) Additional Information Result (e21) Confirmation Provided (E25) Received Handling Information Request (e31) Referral to controlling SCF
(e35) SCF Unbind request (E15) SCFUnbind Request Received (e22) Timer expiration
(e32) STSI send request (E33) STSI received
T11108170-00 (102349)
FIGURE 6/Q.1238.6 SCSM-Sup (Supporting SCF FSM)
6.4
SCF state transition models for chaining initiation (SCSM-ChI)
The Finite State Machine for an SCF interacting with another SCF when acting as a chaining initiator is depicted in Figure 7/Q.1238.6.
22
(e1) SCFBind 2. Prepare Chained HIreq
(e2) SCF Unbind e11 (Timer expiration) 1. Idle (e13) SCFUnbind (E4) SCFBindError (e8) Response to terminator SCF (e10) Request to Terminator SCF
(e3) Chained HIReq
3. Wait for bind result
(e6) SCFUnbind
4. SCF Bound (E5) SCFBind Successful

T11108750-00
(E7) Response from terminator SCF (E9) Request from Terminator SCF (E12) Referral
FIGURE 7/Q.1238.6 SCSM-ChI (Chaining Initiator SCF FSM)
6.4.1
State 1: "Idle"
The only event accepted in this state is: (e1) Send SCFBind: This is an internal event caused by the need to send a SCFBind operation to the SCSM-ChT. The scfBind operations is prepared and saved. This event causes a transition out of this state to State 2 "Wait for Chained Handling Information Request". 6.4.2 State 2: "Prepare Chained HIreq'"
In this state, a scfBind operation has been prepared for sending and the FSM is waiting to see if a ChainedHandlingInformationRequest operation is to be sent with the scfBind operation. The following events can occur: (e3) Send Bind with Requests: This is an internal event caused by either the receiving of HandlingInformationRequest operation to be chained or an internal delimiter indicating no HandlingInformationRequest operation is present. It causes the scfBind operations (and ChainedHandlingInformationRequest operation) to be sent to the SCSM-ChT. It causes a transition to state 3 "Wait for Bind Result". (e2) SCFUnbind: This is an internal event, caused by the receiving of a IN-Unbind operation which requires chaining - to the SCSM-ChT. This event causes a transition out of this state to State 1 "Idle".
23
6.4.3
State 3: "Wait for Bind Result"
In this state, a SCFBind operation and an additional ChainedHandlingInformationRequest operation has been sent to the SCSM-ChT. The SCSM-ChT is performing the processing associated with the SCFBind operation (e.g. access authentication). Four events are considered in this state: (E4) SCFBind_Error: This is an external event caused by the failure of the SCFBind operation previously issued to the SCSM-ChT. This event causes a transition out of this state to State 1 "Idle". (E5) SCFBind_Successful: This is an external event caused by the reception of the SCFBind confirmation for the SCFBind operation previously issued to the SCSM-ChT. This event causes a transition out of this state to State 4 "SCF Bound". (e12) SCFUnbind: This is an internal event, caused by the receiving of a SCFUnbind operation which requires chaining to the SCSM-ChT. The scfUnbind operation is sent to the SCSM-ChT, the SCF-SCF association is ended and all associated resources are released. This event causes a transition out of this state to State 1 "Idle". (e11) Timer expiration: This is an internal event caused by the expiration of a guard timer. It causes a transition back to state "Prepare Chained Hireq". 6.4.4 State 4: "SCF Bound"
In this state, the access of the SCSM-ChI to the SCSM-ChT was authorized, chained operations can be sent to the SCSM-ChT, and results of chained operations coming from the SCSM-ChT are accepted. Thus, the SCSM-ChT will not further chain outgoing chained requests (except where the chaining initiator SCF is in another network). The following events are considered in this state: (e6) SCFUnbind: This is an internal event, caused by the receiving of a SCFUnbind operation which requires chaining to the SCSM-ChT and causes the sending of the SCFUnbind operation to the SCSM-ChT. The SCF/SCF association is ended and all associated resources are released. This event causes a transition out of this state to State 1 "Idle". (E7) Response_from_terminator_SCF: This is an external event, caused by the reception of results of the operations previously issued by the SCSM-ChI. The SCSM-ChI remains in the same state. (e8) Request_to_terminator_SCF: This is an internal event, caused by the sending of a chained operation to the SCSM-ChT. The SCSM-ChI remains in the same state. (E9) Request_from_Terminator_SCF: This is an external event caused by the reception of a chained operation from the SCSM-ChT. The SCSM-ChI remains in the same state. (e10) Response_to_terminator_SCF: This is an internal event caused by the sending of a result to a previously chained operation from the SCSM-ChT. The SCSM-ChT remains in the same state. (E11) Referral: This is an external event caused by a the reception of a referral error to a ChainedHandlingInformationRequest. It does not cause a transition out from "SCF Bound".
24
6.5
SCF state transition models for chaining termination (SCSM-ChT)
The Finite State Machine for an SCF interacting with another SCF when acting as a chaining terminator is depicted in Figure 8/Q.1238.6
(E1) SCFBind 2. Bind pending
(e2) SCFBind error (E3) Chained HIReq
1. Idle
(e9) Request to Initiator SCF (e6) Response to Initiator SCF (e10) Referral to Initiator SCF
3. SCF Bound (E15) SCFUnbind from initiator SCF (e12) Timer Expiration (e4) Send SCFBind Successful (E7) Request from initiator SCF (E8) Response from initiator SCF
T1188390-97 (102349)
FIGURE 8/Q.1238.6 SCSM-ChT (Chaining Terminator SCF FSM)
6.5.1
State 1: "Idle"
The only event accepted in this state is: (E1) SCFBind: This is an external event caused by the reception of a SCFBind operation from an SDSM-ChI. This event causes a transition out of this state to State 2 "Bind Pending". 6.5.2 State 2: "Bind Pending"
In this state, a SCFBind request has been received from the SCSM-ChI. The SCSM-ChT is performing the SCF access control procedures associated with the SCFBind operation (e.g. access authentication). The following events are considered in this state: (e2) SCFBind_Error: This is an internal event caused by the failure of the SCFBind operation previously issued from the SCSM-ChI. This event causes a transition out of this state to State 1 "Idle", and a Bind error is returned to the SCSM-ChI.
25
(E3) ChainedHandlingInformationRequest: This is an external event caused by the reception of a ChainedHandlingInformationRequest from the chaining initiator supporting SCF. The SCSM-ChT remains in the same state. (e4) SCFBind_Successful: This is an internal event caused by the successful completion of the SCFBind operation previously issued from the SCSM-ChI. This event causes a transition out of this state to State 3 "SCF Bound". State 3: "SCF Bound"
6.5.3
In this state, the access of the SCSM-ChI to the SCSM-ChT was authorized and chained operations coming from the SCSM-ChI are accepted. Besides waiting for requests from the SCSM-ChI, the SCSM-ChT can send in this state operations as responses to previously received operations, if any. The following events are considered in this state: (E5) SCFUnbind_from_SCF: This is an external event, caused by the reception of the IN-Unbind operation from the SCSM-ChI. The SCF/SCF association is ended and all associated resources are released. This event causes a transition out of this state to State 1 "Idle". (e6) Response_to_initiator SCF: This is an internal event, caused by the sending of an operation to SCSM-ChI. The SCSM-ChT remains in the same state. (E7) Request_from_initiator SCF: This is an external event, caused by the reception of a request from the SCSM-ChI. The SCSM-ChT remains in the same state. (e8) Response_from_initiator_SCF: This is an external event caused by the reception of an operation as a result to a previously chained operation sent to the SCSM-ChI. The SCSM-ChT remains in the same state. (e9) Request_to_initiator_SCF: This is an internal event caused by the sending of a operation to the SCSM-ChI in order to request some type of processing in the SCSM-ChI. The SCSM-ChT remains in the same state. (e12) Timer Expiration: This is an internal event caused by a timer expiration. It cause a transition from state "SCFBound" back to state 1 "Idle". (e10) Referral to initiator SCF: This is a internal event caused by the sending of a Referral error as a response to the pending ChainedHandlingInformationRequest to the chaining initiator supporting SCF. SCSM-ChT stays in the same state. 7 Detailed Operation Procedures
The following subclauses describe the procedures for executing the operations which are invoked on the SCF-SCF interface. 7.1 7.1.1 ActivityTest procedure General description
This operation is used to check for the continued existence of a relationship between SCFs. If the relationship is still in existence, then the receiving entity will respond. If no reply is received within a given time period, then the SCF which sent this operation will assume that the receiving entity has failed in some way and will take the appropriate action. 7.1.1.1 None. Parameters
26
7.1.2 7.1.2.1
Invoking entity (SCF) Normal procedure
SCF Preconditions: 1) A relationship exists between SCFs. 2) The activity test timer(Tati) expires, after which the "ActivityTest" operation is sent to the remote entity. 3) The SCME is in state "Activity Test Idle". SCF Postcondition: 1) The SCME is in the state "Waiting for Activity Test Response". If a Return Result "ActivityTest" is received, the SCME resets the activity test timer, returns to state "Activity Test Idle", and takes no further action. 7.1.2.2 Error Handling
If a time out on the "ActivityTest" operation or a P-Abort is received from TCAP, this is an indication that the relationship with the remote entity was somehow lost. If a time-out is received, SCF aborts the dialogue. The SLPI that was the user of this dialogue will be informed, the corresponding SCSM-FSM will move to the state "idle". 7.1.3 7.1.3.1 Responding entity (controlling SCF or supporting SCF) Normal procedure
SCF Precondition: 1) A dialogue between the two SCFs has been established. SCF Postconditions: 1) The SCME-FSM stays in the same state. 2) If the Dialogue ID is active and if there is a SCF-FSM using the dialogue, the SCME sends a Return Result to the other SCF. If the Dialogue ID is not active, the TCAP in the other SCF will issue a P-Abort, the SCME will in that case never receive the "ActivityTest" req.ind and thus will not be able to reply. 7.1.3.2 Error Handling
Operation related error handling is not applicable, due to class 3 operation. 7.2 7.2.1 ChainedConfirmedNotificationProvided procedure General description
This operation is used to report to the chaining terminator supporting SCF that a call condition previously specified by the supporting SCF or prearranged between two network operators was met and at the same time to request for confirmation. This is achieved by chaining the ConfirmedNotificationProvided operation received from the controlling SCF to the chaining terminator supporting SCF.
27
7.2.1.1
Parameters
The parameters of this operation are the ConfirmedNotificationProvided parameters and the following chaining parameters. It is to be noted that these parameters are common to all SCF chained operations except ultimateResponder present only in operations with result. These parameters are defined in clause 8. originatingSCF; target; traceInformation; scfAuthenticationLevel; timelimit; ultimateResponder; securityParameters. 7.2.2 7.2.2.1 Invoking entity (chaining initiator supporting SCF) Normal procedure
SCF Preconditions: 1) the chaining initiator supporting SCF has received a "chainedRequestNotification" operation from the chaining terminator supporting SCF; 2) the chaining initiator supporting SCF has received a "confirmedNotificationProvided" operation from the controlling SCF; 3) the SCSM-ChI his in the state "SCF Bound". SCF Post conditions: 1) The SCSM-ChI remains in the state SCF Bound. 7.2.2.2 Error Handling
Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.2.3 7.2.3.1 Responding entity (chaining terminator supporting SCF) Normal procedure
SCF Preconditions: 1) The SCSM-ChT is in the state SCF Bound. SCF Post conditions: 1) The SCSM-ChT remains in the state SCF Bound. 7.2.3.2 Error Handling
Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1.
28
7.3 7.3.1
ChainedConfirmedReportChargingInformation procedure General description
The operation is used by the chaining initiator supporting SCF to report to the chaining terminator supporting SCF the outcome of the call in terms of charging information sent by the controlling SCF and at the same time requests for confirmation. It may be a response to a previously issued "ChainedEstablishChargingRecord" operation or the first operation relating to the charge to the supporting SCF. In the latter case, the call by call charging related information exchange by ChainedEstablishChargingRecord operation is not necessary, because the charging rate, etc. is predefined and is properly applied to the call in the controlling SCF. 7.3.1.1 Parameters
The parameters of this operation are the ConfirmedReportChargingInformation parameters and the following chaining parameters. It is to be noted that these parameters are common to all SCF chained operations except ultimateResponder present only in operations with result. These parameters are defined in clause 8. originatingSCF; target; traceInformation; scfAuthenticationLevel; timelimit; ultimateResponder; securityParameters. 7.3.2 7.3.2.1 Invoking entity (chaining initiator supporting SCF) Normal procedure
SCF Precondition: 1) The SCSM-ChI is in state SCF Bound. SCF Postcondition: 1) The SCSM-ChI remains in the state SCF Bound. 7.3.2.2 Error Handling
Generic error handling for the operation related errors is described in subclause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.3.3 7.3.3.1 Responding entity (chaining terminator supporting SCF) Normal procedure
SCF Precondition: 1) The SCSM-ChT is in the state SCF Bound. SCF Postcondition: 1) The SCSM-ChT is in the state SCF Bound.
29
7.3.3.2
Error Handling
Generic error handling for the operation related errors is described in subclause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.4 7.4.1 ChainedEstablishChargingRecord procedure General description
This operation is used by chaining terminator supporting SCF to give charging information to the chaining initiator supporting SCF. This operation is used by the chaining initiator supporting SCF to prepare and to send a establishChargingRecord operation to the controlling SCF. 7.4.1.1 Parameters
The parameters of this operation are the EstablishChargingRecord parameters and the following chaining parameters. It is to be noted that these parameters are common to all SCF chained operations except ultimateResponder present only in operations with result. These parameters are defined in clause 8. originatingSCF; target; traceInformation; scfAuthenticationLevel; timelimit; ultimateResponder; securityParameters. 7.4.2 7.4.2.1 Invoking entity (chaining terminator supporting SCF) Normal procedure
SCF Preconditions: 1) The SCSM-ChT is in the state "SCF Bound". SCF Post conditions: 1) The SCSM-ChT remains in the state SCF Bound. 7.4.2.2 Error Handling
Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.4.3 7.4.3.1 Responding entity (chaining initiator supporting SCF) Normal procedure
SCF Preconditions: 1) The SCSM-ChI is in the state SCF Bound. SCF Post conditions: 1) The SCSM-ChI remains in the state SCF Bound.
30
7.4.3.2
Error Handling
If chaining initiator supporting SCF receives a "chainedEstablishedChargingInformation" operation without "charging parameters and without "user credit" parameters it replies with a "missing parameter" error. Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.5 7.5.1 ChainedHandlingInformationRequest procedure General description
This operation requests to chaining terminator supporting SCF assistance on how to proceed. This is achieved by chaining the HandlingInformationRequest Information operation received from the controlling SCF to the chaining terminator supporting SCF. The chainedHandlingInformationRequest operation can be sent to the chaining terminator SCF in the same message as the SCFBind operation. 7.5.1.1 Parameters
The parameters of this operation are the HandlingInformationRequest parameters and the following chaining parameters. It is to be noted that these parameters are common to all SCF chained operations except ultimateResponder present only in operations with result. These parameters are defined in clause 8: originatingSCF; target; traceInformation; scfAuthenticationLevel; timelimit; ultimateResponder; securityParameters. 7.5.2 7.5.2.1 Invoking entity (chaining initiator supporting SCF) Normal procedure
SCF Preconditions: 1) The chaining initiator supporting SCF has received a "HandlingInformationRequest "operation from the controlling SCF. 2) The SCSM-ChI is in the state "Prepare Chained HandlingInformationRequest". SCF Post conditions: 1) The SCSM-ChI moves to the state Wait for Bound Result. 7.5.2.2 Error Handling
If the chaining terminator supporting SCF is not accessible, the supporting SCF FSM (SCSM-sup) is informed. Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1.
31
7.5.3 7.5.3.1
Responding entity (chaining terminator supporting SCF) Normal procedure
SCF Preconditions: 1) The SCSM-ChT is in the state BindPending. SCF Post conditions: 1) The SCSM-ChT remains in the state BindPending. 7.5.3.2 Error Handling
If the chaining terminator supporting SCF receives a chainedHandlingInformationRequest operation while a ChainedHandlingInformationResult operation is still pending, taskrefused error is returned to chaining initiator supporting SCF. If the chaining terminator supporting SCF receives a chainedHandlingInformationRequest operation that it is not able to handle, it can return a "referral" error to chaining initiator supporting SCF. Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.6 7.6.1 ChainedHandlingInformationResult procedure General description
This operation is used by chaining terminator supporting SCF to give the response to the chainedHandlingInformationRequest operation, received from the chaining initiator supporting SCF. 7.6.1.1 Parameters
The parameters of this operation are the HandlingInformationResult parameters and the following chaining parameters. It is to be noted that these parameters are common to all SCF chained operations except ultimateResponder present only in operations with result. These parameters are defined in clause 8. originatingSCF; target; traceInformation; scfAuthenticationLevel; timelimit; ultimateResponder; securityParameters. 7.6.2 7.6.2.1 Invoking entity (chaining terminator supporting SCF) Normal procedure
SCF Preconditions: 1) The SCSM-ChI is in the state SCF Bound. SCF Post conditions: 1) The SCSM-ChI remains in the state SCF Bound.
32
7.6.2.2
Error Handling
SCF Preconditions: 1) The SCSM-ChI is in the state SCF Bound. SCF Post conditions: 1) The SCSM-ChI remains in the state SCF Bound. 7.6.3.2 Error Handling
Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.7 7.7.1 ChainedNetworkCapability procedure General description
This operation is used by chaining terminator supporting SCF to request the chaining initiator supporting SCF the type of services that are supported for the user and in the context of the call, if not already specified in the agreement and to agree with. 7.7.1.1 Parameters
The parameters of this operation are the NetworkCapability parameters and the following chaining parameters. It is to be noted that these parameters are common to all SCF chained operations except ultimateResponder present only in operations with result. These parameters are defined in clause 8. originatingSCF; target; traceInformation; scfAuthenticationLevel; timelimit; ultimateResponder; securityParameters. 7.7.2 7.7.2.1 Invoking entity (chaining terminator supporting SCF) Normal procedure
SCF Preconditions: 1) The SCSM-ChT is in the state "SCF Bound". SCF Post conditions: 1) The SCSM-ChT remains in the state SCF Bound.
33
7.7.2.2
Error Handling
SCF Preconditions: 1) The SCSM-ChI is in the state SCF Bound. SCF Post conditions: 1) The SCSM-ChI remains in the state SCF Bound. 7.7.3.2 Error Handling
Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.8 7.8.1 ChainedNotificationProvided procedure General description
This operation is used to report that a call condition previously specified by the "chaining terminator supporting SCF was met. This is achieved by chaining the notification Provided operation received from the controlling SCF to the chaining terminator supporting SCF". 7.8.1.1 Parameters
The parameters of this operation are the NotificationProvided parameters and the following chaining parameters. It is to be noted that these parameters are common to all SCF chained operations except ultimateResponder present only in operations with result. These parameters are defined in clause 8. originatingSCF; target; traceInformation; scfAuthenticationLevel; timelimit; ultimateResponder; securityParameters; 7.8.2 7.8.2.1 Invoking entity (chaining initiator supporting SCF) Normal procedure
SCF Preconditions: 1) The chaining initiator supporting SCF has received a "notificationProvided" operation from the controlling SCF. 2) The SCSM-ChI is in the state "SCF Bound". SCF Post conditions: 1) The SCSM-ChI remains in the state SCF Bound.
34
7.8.2.2
Error Handling
Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.8.3 7.8.3.1 Responding entity (chaining terminator supporting SCF) Normal procedure
Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.9 7.9.1 ChainedReportChargingInformation procedure General description
The operation reports to chaining terminator supporting SCF the outcome of the call in terms of charging information. This is achieved by chaining the reportChargingInformation operation received from the controlling SCF to the chaining terminator supporting SCF. 7.9.1.1 Parameters
The parameters of this operation are the ReportChargingInformation parameters and the following chaining parameters. It is to be noted that these parameters are common to all SCF chained operations except ultimateResponder present only in operations with result. These parameters are defined in clause 8. originatingSCF; target; traceInformation; scfAuthenticationLevel; timelimit; ultimateResponder; securityParameters. 7.9.2 7.9.2.1 Invoking entity (chaining initiator supporting SCF) Normal procedure
SCF Preconditions: 1) The chaining initiator supporting SCF has received a "reportChargingInformation" operation from the controlling SCF. 2) The SCSM-ChI is in the state "SCF Bound". SCF Post conditions: 1) The SCSM-ChI remains in the state SCF Bound.
35
7.9.2.2
Error Handling
Generic error handling for the operation related errors is described in clause 9, and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.9.3 7.9.3.1 Responding entity (chaining terminator supporting SCF) Normal procedure
Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.10 ChainedProvideUserInformation procedure
7.10.1 General description This operation is used by chaining terminator supporting SCF to request the chaining initiator supporting SCF to send a provideUserInformation operation to the controlling SCF, in order to request the user information. The received user information will be used in the chaining terminator supporting SCF to determine the way the call should be treated. 7.10.1.1 Parameters The parameters of this operation are the ProvideUserInformation parameters and the following chaining parameters. It is to be noted that these parameters are common to all SCF chained operations except ultimateResponder present only in operations with result. These parameters are defined in clause 8. originatingSCF; target; traceInformation; scfAuthenticationLevel; timelimit; ultimateResponder; securityParameters. 7.10.2 Invoking entity (chaining terminator supporting SCF) 7.10.2.1 Normal procedure SCF Preconditions: 1) The SCSM-ChT is in the state "SCF Bound". SCF Post conditions: 1) The SCSM-ChT remains in the state SCF Bound.
36
7.10.2.2 Error Handling Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.10.3 Responding entity (chaining initiator supporting SCF) 7.10.3.1 Normal procedure 1) The SCSM-ChI is in the state SCF Bound. SCF Post conditions: 1) The SCSM-ChI remains in the state SCF Bound. 7.10.3.2 Error Handling Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.11 ChainedRequestNotification procedure
7.11.1 General description This operation is used by chaining terminator supporting SCF to request an event notification to the controlling SCF through the chaining initiator SCF; in fact it causes the chaining initiator supporting SCF to send a requestNotification operation to the controlling SCF. 7.11.1.1 Parameters The parameters of this operation are the RequestNotification parameters and the following chaining parameters. It is to be noted that these parameters are common to all SCF chained operations except ultimateResponder present only in operations with result. These parameters are defined in clause 8. originatingSCF; target; traceInformation; scfAuthenticationLevel; timelimit; ultimateResponder; securityParameters. 7.11.2 Invoking entity (chaining terminator supporting SCF) 7.11.2.1 Normal Procedure SCF Preconditions: 1) The SCSM-ChI is in the state SCF Bound. SCF Post conditions: 1) The SCSM-ChI remains in the state SCF Bound. 7.11.2.2 Error Handling Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1.
37
7.11.3 Responding entity (chaining initiator supporting SCF) 7.11.3.1 Normal Procedure SCF Preconditions: 1) The SCSM-ChI is in the state SCF Bound. SCF Post conditions: 1) The SCSM-ChI remains in the state SCF Bound. 7.11.3.2 Error Handling Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.12 ChainedRunUserScript procedure
7.12.1 General description This operation is used by chaining terminator supporting SCF to request the chaining initiator supporting SCF to send a RunUserScript operation to the controlling SCF, in order to request the user information. The received user information will be used in the chaining terminator supporting SCF to determine the way the call should be treated. 7.12.1.1 Parameters The parameters of this operation are the RunUserScript parameters and the following chaining parameters. It is to be noted that these parameters are common to all SCF chained operations except ultimateResponder present only in operations with result. These parameters are defined in clause 8. originatingSCF; target; traceInformation; scfAuthenticationLevel; timelimit; ultimateResponder; securityParameters. 7.12.2 Invoking entity (chaining terminator supporting SCF) 7.12.2.1 Normal procedure SCF Preconditions: 1) The SCSM-ChT is in the state "SCF Bound". SCF Post conditions: 1) The SCSM-ChT remains in the state SCF Bound. 7.12.2.2 Error Handling Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1.
38
7.12.3 Responding entity (chaining initiator supporting SCF) 7.12.3.1 Normal procedure 1) The SCSM-ChI is in the state SCF Bound. SCF Post conditions: 1) The SCSM-ChI remains in the state SCF Bound. 7.12.3.2 Error Handling Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.13 ConfirmedNotificationProvided procedure
7.13.1 General description This operation is used to report that a call condition previously specified by the supporting SCF or prearranged between two network operators was met and at the same time to request for confirmation. 7.13.2 Parameters notification; notificationInformation; securityParameters; extensions.
7.13.3 Invoking entity (controlling SCF) 7.13.3.1 Normal procedure SCF Precondition: 1) The controlling SCF has received a "Request Notification" operation if call conditions at which this operation is sent has not been prearranged between two network operators. 2) A call condition specified earlier by the supporting SCF or prearranged between two network operators has been met. 3) The SCF FSM is in the state "Assisted Mode". 4) The need to request for confirmation has been realized from the service logic. SCF Postcondition: 1) SCF FSM remains in Assisted mode state. If several call conditions as specified by the supporting SCF or as prearranged between two network operators have been met, they are reported in sequence to the supporting SCF, which takes the appropriate actions. 7.13.3.2 Error Handling Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1.
39
7.13.4 Responding entity (supporting SCF) 7.13.4.1 Normal procedure SCF Precondition: 1) A dialogue between the two SCFs has been previously established. 2) The SCF FSM is in the state "Assisting Mode". SCF Postcondition: 1) SCF FSM remains in the state "Assisting Mode". 2) A Return Result is sent for confirmation. On receipt of the "ConfirmedNotificationProvided" operation the SLPI determines whether the call configuration should be modified as a consequence of the received notification information. If the call configuration in the invoking network needs to be modified, the SCF prepares instructions to assist the controlling SCF and sends them with a "handlingInformationResult" operation. Otherwise the SCF does not undertake any actions towards the controlling SCF, but the notification can be used in the SLPI (e.g. for charging purposes). 7.13.4.2 Error Handling Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.14 ConfirmedReportChargingInformation procedure
7.14.1 General description The operation reports to an supporting SCF the outcome of the call in terms of charging information, the call being controlled by the controlling SCF and at the same time requests for confirmation. It may be a response to a previously issued "EstablishChargingRecord" operation or the first operation relating to the charge to the supporting SCF. In the latter case, the call by call charging related information exchange by EstablishChargingRecord operation is not necessary, because the charging rate, etc. is predefined and is properly applied to the call in the controlling SCF. 7.14.2 Parameters The parameters conveyed in the operation argument are identical to those included in the ReportChargingInformation operation argument. callRecord; remainingUserCredit; uniqueCallID; accountNumber; securityParameter; counterValues; resetOfTransmittedCounters; container; correlationId; ackSequence; extensions.
40
7.14.3 Invoking entity (controlling SCF) 7.14.3.1 Normal procedure SCF Precondition: 1) An "establishChargingRecord" operation has been received with the "expectedReport" parameter positioned to TRUE or it has been prearranged. 2) A call has taken place. 3) SCF FSM is in the "Assisted Mode" state. 4) SLP realizes the need to request for confirmation. SCF Postcondition: 1) SCF FSM remains in the state "Assisted Mode". After a call has taken place and either if a "EstablishChargingRecord" operation has been sent by the supporting SCF with the "reportExpected" parameter set to TRUE, requesting the charging information to be reported, or if it has been prearranged, the controlling SCF sends a "confirmedReportChargingInformation" operation in order to report the outcome of the charging procedure that took place for the call and in order to request for further confirmation from the supporting SCF. It contains the call identity to know the call it refers to and the user credit after the call. 7.14.3.2 Error Handling Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.14.4 Responding entity (supporting SCF) 7.14.4.1 Normal procedure SCF Precondition: 1) The SCF has sent an "establishChargingRecord" operation with the "reportExpected" parameter set to TRUE, or it has been prearranged. 2) SCF FSM is in the "Assisting Mode" state. SCF Postcondition: 1) SCF FSM remains in "Assisted Mode". 2) A Return Result is sent for confirmation On receipt of the "confirmedChargingInformation" operation, the SCF uses the information to update the user's data and it could also report the information to the management functions for security and billing purposes. 7.14.4.2 Error Handling Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1.
41
7.15
EstablishChargingRecord procedure
7.15.1 General description This operation is used by the supporting SCF to give charging information to another SCF controlling a call, so that it can charge the user (online charging included). The sent information is used to parameterize a charging function. This charging function is generic and can be used to charge any kind of calls. (This option might be used not used if the needed charging information has been prearranged.) 7.15.2 Parameters userCredit; chargingParameters; reportExpected; securityParameter; extensions; consumedCreditAction; reportAddress; container; correlationId; ackSequence; splitCharge; reportCondition.
7.15.3 Invoking entity (supporting SCF) 7.15.3.1 Normal procedure SCF Precondition: 1) "handlingInformationRequest" operation has been received. 2) The need for providing the controlling SCF with charging information has been identified by the SLPI. 3) The SCF FSM is in the "Assisting mode" state. SCF Postcondition: 1) The SCF waits for the result of the ReportChargingInformation operation or none. Before sending the "establishChargingRecord" operation, the SCF has received a "handlingInformationRequest" operation containing information about the call, the controlling network and the user. According to the agreementID contained in the received SCFBind operation, the supporting SCF knows if it (or the controlling SCF) can perform the charging of the call. When charging is delegated to the controlling SCF, the supporting SCF has to send the parameters of the charging function, unless all the needed charging information has been prearranged. The supporting SCF then sends the "establishChargingInformation" operation containing either the charging parameters or the remaining user credit. Once the operation has been sent, depending on the contents of the "expectedReport" parameter, the SCF waits for a reply (either a "confirmedReportChargingInformation" or "reportChargingInformation" operation.
42
7.15.3.2 Error Handling Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.15.4 Responding entity (controlling SCF) 7.15.4.1 Normal procedure SCF Precondition: 1) A relationship between two SCFs has been established. A "handlingInformationRequest" operation has been sent. 2) The SCF FSM is in the "Assisted Mode" state. SCF Postcondition: 1) The SCSM is able to charge the call. The charging function is parameterized and ready to be used. 2) The SCF FSM remains in the same state. On receipt of the "establishChargingInformation" operation, the charging function is parameterized. Depending on the type of call and the invoked services, the SCF decides where charging can take place (i.e. in which functional entity), but charging will be done according to the charging function. Depending of the value of the "expectedReport" parameter, the SCF is ready to send the reply or not (the type of reply is determined autonomously by the SLPI in the controlling SCF, i.e. a "reportChargingInformation operation" or a "confirmedChargingInformation" operation if further confirmation from the supporting SCF is expected) to the supporting SCF. 7.15.4.2 Error Handling If the controlling SCF receives an establishChargingInformation operation without the "chargingParameter" and without the "userCredit" parameter, it replies with a "missingParameter". Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.16 HandlingInformationRequest procedure
7.16.1 General description This operation is used when a SCF controlling a "call" has not sufficient information to process the call (e.g. routing, announcement) and request assistance from another SCF having knowledge on how to proceed with the call. The call could be a user request with only one user involved. The operation initiates the dialogue between two SCFs and to provide the supporting SCF with the context of the call so that it can help the controlling SCF in the processing of the call. 7.16.2 Parameters callingPartyNumber; locationNumber; calledPartyNumber; dialledDigits; redirectingPartyID; redirectionInformation;
43
callingPartyBusinessGroupID; originalCalledPartyID; numberOfCallAttempts; highLayerCompatibility; bearerCapability; invokedSupplementaryService; activeSupplementaryServices; causeOfLastCallFailure; userInteractionModes; callingPartysCategory; requestedType; securityParameters; extensions.
7.16.3 Invoking entity (controlling SCF) 7.16.3.1 Normal procedure SCF Precondition: 1) A relationship has been requested by controlling SCF if it is the first occurrence of the operation, otherwise the relationship has been already established between the two SCFs. 2) In the first case, the SCF FSM is in state "Preparing Handling Information Request", in the second case it is in state "Assisted Mode". SCF Postcondition: 1) The SCF FSM moves to the state "Waiting for Bind Result" from the state "Preparing Handling Information Request" or it remains in the "Assisted Mode" state, if it was already there. 2) If SCF FSM has moved to the state "Waiting for Binds result"state, it moves to "Assisted mode" state as soon as a positive result to SCF Bind operation is received, or to "Idle" state in case of a negative result. The SCF provides parameters, that depend on the service logic invoked. The list of parameters that are needed depends on the agreement - referred with SCF Bind operation previously issued. When mandatory information for a given service logic is missing, the controlling SCF is responsible to conduct the necessary actions to get the information before sending of the "handlingInformationRequest" operation. 7.16.3.2 Error Handling If the supporting SCF is not accessible, the call is given final treatment which is service logic dependent. If the calling user abandons after the sending of the "handlingInformationRequest" operation, then the SCF FSM moves the state "Preparing SCFUnbind request" and the SCF aborts the SCF-SCF relationship by means of an abort to TCAP. Note that TCAP will wait until the first response message from the SCF has been received before it sends an abort to the SCF. Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1.
44
7.16.4 Responding entity (supporting SCF) 7.16.4.1 Normal procedure SCF Precondition: 1) The SCF FSM is in the state "Processing SCF Bind" or in the state "Assisting Mode" or it has already successfully processed a previous "HandlingInformationRequest". SCF Postcondition: 1) The SCSM remains in the state "Assisting Mode". The actions to be performed in the SLPI depend on the parameters conveyed via this operation and the agreement, i.e. the requested IN service, itself. 7.16.4.2 Error Handling If the supporting SCF receives a "handlingInformationRequest" operation while it is in the Assisting mode and a "handlingInformationResult" is already pending for a previous "handlingInformationRequest" operation, then a "taskRefused" error is returned to the controlling SCF. If the "handlingInformationRequest" operation is rejected the SCSM remains in the state "Idle", the maintenance function is informed and no SLPI is invoked. Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.17 HandlingInformationResult procedure
7.17.1 General description This operation is used by the supporting SCF to answer operations previously issued by the controlling SCF. Information contained in the "handlingInformationResult" operation can either be used to process the call (e.g. routing, announcement) that has initiated the SCF-SCF relationship, or to indicate to controlling SCF when it should contact the supporting SCF to receive instructions. 7.17.2 Parameters routingAddress; highLayerCompatibility; supplementaryServices; preferredLanguage; carrier; callingPartyNumber; originalCalledPartyID; redirectingPartyID; redirectionInformation; callingPartysCategory; securityParameters; extensions.
45
7.17.3 Invoking entity (supporting SCF) 7.17.3.1 Normal procedure SCF Precondition: 1) A dialogue with the controlling SCF has been established. 2) The supporting SCF has previously received a "handlingInformationRequest" operation. 3) The SCF FSM is in the state "Assisted Mode". SCF Postcondition: 1) The SLPI waits for operations coming from the controlling SCF or the SLPI can be ended. 2) The SCF FSM remains in the state "Assisting Mode". This operation is invoked by the supporting SCF when the service logic is able to provide instructions to the controlling SCF on how to process the call. Information contained in the "handlingInformationResult" operation can be used by the controlling SCF to build the operations needed to set up the call and/or to control it. 7.17.3.2 Error Handling Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.17.4 Responding entity (controlling SCF) 7.17.4.1 Normal procedure SCF Precondition: 1) A "handlingInformationRequest" operation has been sent. 2) The SCF FSM is in the state "Assisted Mode". SCF Postcondition: 1) According to the information received, the SCF performs call processing actions and/or starts call monitoring functions. 2) The SCF FSM moves to the state "Preparing SCF Unbind request" from the state "Assisted Mode" if no more assistance is needed or it remains in the state "Assisted Mode", if a further "Handling Information Result" reception is still pending. If the "routingAddress" parameter is present, it is used to handle the call. If the call has to be routed the other parameters contained in the operation can be used to set up the call. The contents of the parameter can be memorized by the SCF and/or store in the SDF. The contents of the parameter can be kept for a longer time than the relationship duration. 7.17.4.2 Error Handling Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1.
46
7.18
IN-Unbind procedure
7.18.1 General description The IN-SCF Unbind procedure uses the inUnbind operation defined in Recommendation Q.1238.1. It is used by either the controlling SCF or the supporting SCF to close the relationship with the peer SCF. 7.18.1.1 Parameters None. 7.18.2 Invoking entity 7.18.2.1 Normal procedure SCF Precondition: 1) For the Controlling SCF, the SCF FSM is in state "Preparing SCF Unbind Request". For the Supporting SCF, the SCF FSM is in any state except "Idle".
SCF Postconditions: 1) The SCF FSM moves back to state 1 "Idle". 7.18.2.2 Error Handling The IN-Unbind operation does not return operation-related errors. 7.18.3 Responding entity 7.18.3.1 Normal procedure SCF Precondition: 1) The SCF FSM is in any the state except 1 "Idle". SCF Postcondition: 1) The SCSM moves back to state 1, "Idle". 7.18.3.2 Error Handling The IN-Unbind operation does not return operation-related errors. 7.19 IN-Unbind procedure (in the chaining case)
7.19.1 General description This procedure uses the inUnbind operation defined in Recommendation Q.1238.1. It is used to close a relationship between the chaining initiator and chaining terminator SCFs. 7.19.1.1 Parameters None. 7.19.2 Invoking entity (chaining initiator supporting SCF) 7.19.2.1 Normal procedure SCF Preconditions: 1) The SCSM-ChI is any state except "Idle".
47
2)
The chaining initiator supporting SCF has realized the need to close the relationship, either autonomously or because of the reception of a IN- SCFUnbind operation from the controlling SCF.
SCF Postconditions: 1) The SCSM-ChI moves to the state "Idle". 7.19.2.2 Error Handling The IN-Unbind operation does not return operation-related errors. 7.19.3 Responding entity (chaining terminator supporting SCF) 7.19.3.1 Normal procedure SCF Preconditions: 1) The SCSM-ChT is in the state "SCF Bound". SCF Postconditions: 1) The SCSM-ChT moves to the state "Idle". 2) If the SCF Bind operation is accepted and chainedHandlingInformationRequest operation has been received, SCSM-ChT moves to state "SCFBound" and a positive result is sent to chaining initiator supporting SCF; if SCFBind is not accepted SCSM-ChT moves back to state Idle and a negative result is sent to chaining initiator supporting SCF. 7.19.3.2 Error Handling The IN-Unbind operation does not return operation-related errors. 7.20 NetworkCapability procedure
7.20.1 General description This operation provides the different types of services that are supported for the user involved in the call and in the context of that call, if not already specified in the agreement. It is used by the two interworking networks to agree on a level of service that can be expected for the call. 7.20.2 Parameters bearerCapabilities; highLayerCompatibilities; supplementaryServices; securityParameter.
7.20.3 Invoking entity (supporting SCF) 7.20.3.1 Normal procedure SCF Precondition: 1) A "handlingInformationRequest" operation has been received and the preparation of a "handlingInformationResult" parameter is pending. 2) The need for knowing the level of service to be available to the user has been identified by the SLPI. 3) The SCF FSM is in the state "Assisting Mode".
48
SCF Postcondition: 1) The SCF moves to the state "Waiting for Additional Information". Before sending the "networkCapability" operation, the supporting SCF has received a "handlingInformationRequest" operation containing information about the call, the controlling network and the user. If the information received is not enough, the supporting SCF can build the "networkCapability" operation, by sending the types of services that it expects can be available in the controlling network for the call conditions specified in the earlier operation, and for the given user. The "networkCapability" operation can take into account the agreements between the network operators, the user's service profile and the call context. Once the operation has been sent, the SCF FSM moves to the state "Waiting for additional Information". The SCF waits for the answer from the other SCF. 7.21 NotificationProvided procedure
7.21.1 General description This operation is used to report that a call condition previously specified by the supporting SCF or prearranged between two network operators was met. 7.21.2 Parameters notification; notificationInformation; securityParameters; extensions.
7.21.3 Invoking entity (controlling SCF) 7.21.3.1 Normal procedure SCF Precondition: 1) The SCF has received a "Request Notification" operation if call conditions at which this operation is sent has not been prearranged between two network operators. 2) A call condition specified earlier by the supporting SCF or prearranged between two network operators has been met. 3) The SCF-SCF relationship has been maintained since the "SCF Bind handlingInformationRequest" operation has been sent. 4) The SCF FSM is in the state "Assisted Mode". SCF Postcondition: 1) SCF FSM remains in the same state. If several call conditions as specified by the supporting SCF or as prearranged between two network operators have been met, they are reported in sequence to the supporting SCF, which takes the appropriate actions. 7.21.3.2 Error Handling Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1.
49
7.21.4 Responding entity (supporting SCF) 7.21.4.1 Normal procedure SCF Precondition: 1) A dialogue between the two SCFs has been previously established. 2) The SCF FSM is in the state "Assisting Mode". SCF Postcondition: 1) SCF FSM remains is in the same state. On receipt of the "notificationProvided" operation the SLPI determines whether the call configuration should be modified as a consequence of the received notification information. If the call configuration in the controlling SCF needs to be modified, the supporting SCF prepares instructions to assist the controlling SCF and sends them with a "handlingInformationResult" operation. Otherwise the supporting SCF does not undertake any actions towards the controlling SCF, but the notification can be used in the SLPI (e.g. for charging purposes). 7.21.4.2 Error Handling Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.22 ProvideUserInformation procedure
7.22.1 General description This operation is used by a supporting SCF to request user information through the help of the SCF controlling the call. The received user information will be used in the supporting SCF to determine the way the call should be handled. The operation provides the means for the controlling SCF to build the operations to prompt the user and collect information from him/her. The operation result sends back user information to an SCF that has requested it in order to assist the controlling SCF. It can also sent back indication that a user interaction has failed and the user information could not be collected from the user. 7.22.2 Parameters infoToSend; errorInfo; constraints; actions; preferredLanguage; numberOfAllowedRetries; typeOfRequestedInfo; securityParameters; userInformation; srfAddress; userToConnect; extensions.
50
7.22.3 Invoking entity (supporting SCF) 7.22.3.1 Normal procedure SCF Precondition: 1) A "handlingInformationRequest" operation has been received. 2) The SLPI has identified the need for more information than what is already available. 3) The SCF FSM is in state "Assisting Mode". SCF Postcondition: 1) The SCSM moves to the state "WaitingForAdditionalInformation". After receiving a "handlingInformationRequest", the supporting SCF was not able to provide call instructions to the controlling SCF, because information known from the user is not available. The supporting SCF then sends a "provideUserInformationRequest" operation. One operation can be used to request several pieces of information. Once the operation is sent, the supporting SCF moves to the state "Waiting for Additional Information" and awaits from the user information to be sent by the controlling SCF. On receipt of the "provideUserInformationResult", the SCSM moves from the state "Waiting for Information" to the state "Assisting Mode". The user information received in the operation is used to provide assistance to the controlling SCF so that it can correctly handle the call. Only the supporting SCF knows how to use and to interpret the received information. When the SCF receives an indication that a user interaction has failed, the SLPI decides upon the follow-up actions and especially, which kind of call instructions should be provided to the controlling SCF. In particular, the SCF can provided a specific user announcement in case of error if not already provided in the "provideUserInformation" operation. 7.22.3.2 Error Handling Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.22.4 Responding entity (controlling SCF) 7.22.4.1 Normal procedure SCF Precondition: 1) A "handlingInformationRequest" operation has been sent. 2) The SCf FSM is in state "AssistedMode". SCF Postcondition: 1) The SCF FSM moves to the state "Preparing Additional Information". On receipt of the "provideUserInformationRequest" operation the SCSM moves from "Assisted Mode" to the state "Preparing Additional Information". The SCF uses user interaction procedures to receive the requested information from the user (connection of an IP, STUI...). The information received from the user can be challenged against the constraints provided in the parameters. If a user gives an improper response, a retry of the error message can occur (if allowed). If several pieces of information are requested from the user, a failure to obtain one of them leads to the end of the user interaction phase or to the request of the next piece of information depending on
51
the user interaction strategy adopted. In the first case only responded pieces are reported back to the supporting SCF, in the second case the failure is reported to the supporting SCF through a "taskRefused" error. In the state "Preparing Additional Information", the SCF collects information from the user. When all the user interactions have been performed successful or not, the SCSM moves to the state "Assisted Mode". It sends the "provideUserInformationResult" operation to the supporting SCF. The operation containing information provided by the user and/or indications that the procedures to get information from the user has failed. When a user fails to correctly provide a piece of information even after the number of retries specified in the "provideUserInformationRequest" operation, it is the user interaction strategy parameter that determines the actions to be performed. 7.22.4.2 Error Handling Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.23 ReportChargingInformation procedure
7.23.1 General description The operation reports to an supporting SCF the outcome of the call in terms of charging information, the call being controlled by the controlling SCF. It may be a response to a previously issued "establishChargingRecord" with the "expectedReport" parameter positioned to TRUE or the first operation relating to the charge to the supporting SCF, if it has been prearranged. In the latter case, the call by call charging related information exchange by establishChargingRecord operation is not necessary, because the charging rate, etc. is predefined and is properly applied to the call in the controlling SCF. 7.23.2 Parameters uniqueCallID; remainingUserCredit; callRecord; accountNumber; securityParameters; countersValues; resetOfTransmittedCounters; container; correlationId; ackSequence; extensions.
7.23.3 Invoking entity (controlling SCF) 7.23.3.1 Normal procedure SCF Precondition: 1) A "establishChargingRecord" operation has been received with the "reportExpected" parameter positioned to TRUE or it has been prearranged.
52
2) 3)
A call has taken place. SCF FSM is in the "Assisted Mode" state.
SCF Postcondition: 1) SCF FSM remains in the "Assisted Mode" state. After a call has taken place and either if a "establishChargingRecord" operation has been sent, requesting the charging information to be reported or it has been prearranged, the SCF sends a "reportChargingInformation" operation to report the outcome of the charging procedure that took place for the call. It contains the call identity to know the call it refers to and the user credit after the call. 7.23.3.2 Error Handling Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.23.4 Responding entity (supporting SCF) 7.23.4.1 Normal procedure SCF Precondition: 1) The SCF has sent an "establishChargingRecord" operation or it has been prearranged. 2) SCF FSM is in the "Assisting Mode" state. SCF Postcondition: 1) SCF FSM remains in the "Assisting Mode" state. On receipt of the "reportChargingInformation" operation, the SCF uses the information to update the user's data and it could also report the information to the management functions for security and billing purposes. 7.23.4.2 Error Handling Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.24 RequestNotification procedure
7.24.1 General description This operation is used by the supporting SCF to request an event notification to the controlling SCF. 7.24.2 Parameters requested Notifications; securityParameters; extensions.
53
7.24.3 Invoking entity (supporting SCF) 7.24.3.1 Normal Procedure SCF Precondition: 1) A relationship with the controlling SCF has been established. 2) The supporting SCF has previously received a "handlingInformationRequest" operation. 3) The SCF FSM is in the state "Assisting Mode". SCF Postcondition: 1) The SCF FSM remains in the same state. 7.24.3.2 Error Handling Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.24.4 Responding entity (controlling SCF) 7.24.4.1 Normal Procedure SCF Precondition: 1) A "handlingInformationRequest" operation has been sent. 2) The SCF FSM is in the state "Assisted Mode". SCF Postcondition: 1) According to the information received, the controlling SCF starts call monitoring functions. 2) The SCF FSM remains in the same state. 7.24.4.2 Error Handling Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.25 RunUserScript procedure
7.25.1 General description This operation is used by a supporting SCF to request user information through the help of the SCF controlling the call. The received user information will be used in the supporting SCF to determine the way the call should be handled. The operation provides the means for the controlling SCF to build the operations to prompt the user and collect information from him/her. The operation result sends back user information to an SCF that has requested it in order to assist the controlling SCF. It can also sent back indication that a user interaction has failed and the user information could not be collected from the user. 7.25.2 _ Parameters srfAddress; userToConnect; correlationID;
54
scfID; securityParameters; extensions.
7.25.3 Invoking entity (supporting SCF) 7.25.3.1 Normal procedure SCF Precondition: 1) A "handlingInformationRequest" operation has been received. 2) The SLPI has identified the need for more information than what is already available. 3) The SCF FSM is in state "Assisting Mode". SCF Postondition: 1) The SCSM moves to the state "Waiting For Additional Information". After receiving a "handlingInformationRequest", the supporting SCF was not able to provide call instructions to the controlling SCF, because information known from the user is not available. The supporting SCF then sends a "RunUserScriptRequest" operation. One operation can be used to request several pieces of information. Once the operation is sent, the supporting SCF moves to the state "Waiting for Additional Information" and awaits from the user information to be sent by the controlling SCF. On receipt of the "RunUserScriptResult", the SCSM moves from the state "Waiting for Information" to the state "Assisting Mode". The user information received in the operation is used to provide assistance to the controlling SCF so that it can correctly handle the call. Only the supporting SCF knows how to use and to interpret the received information. When the SCF receives an indication that a user interaction has failed, the SLPI decides upon the follow-up actions and especially, which kind of call instructions should be provided to the controlling SCF. In particular, the SCF can provided a specific user announcement in case of error if not already provided in the "RunUserScript" operation. 7.25.3.2 Error Handling Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.25.4 Responding entity (controlling SCF) 7.25.4.1 Normal procedure SCF Precondition: 1) A "handlingInformationRequest" operation has been sent. 2) The SCF FSM is in the "Assisted Mode" state SCF Postcondition: 1) The SCF moves to the state "Preparing Additional Information". On receipt of the "RunUserScriptRequest" operation the SCSM moves from "Assisted Mode" to the state "Preparing Additional Information". The SCF uses user interaction procedures to receive the requested information from the user (connection of an IP, STUI...).
55
The information received from the user can be challenged against the constraints provided in the parameters. If a user gives an improper response, a retry of the error message can occur (if allowed). If several pieces of information are requested from the user, a failure to obtain one of them leads to the end of the user interaction phase or to the request of the next piece of information depending on the user interaction strategy adopted. In the first case only responded pieces are reported back to the supporting SCF, in the second case the failure is reported to the supporting SCF through a "taskRefused" error. In the state "Preparing Additional Information", the SCF collects information from the user. When all the user interactions have been performed successful or not, the SCSM moves to the state "Assisted Mode". It sends the "RunUserScriptResult" operation to the supporting SCF. The operation containing information provided by the user and/or indications that the procedures to get information from the user has failed. When a user fails to correctly provide a piece of information even after the number of retries specified in the "RunUserScriptRequest" operation, it is the user interaction strategy parameter that determines the actions to be performed. 7.25.4.2 Error Handling Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.26 SCFBind procedure
7.26.1 General description The SCF Bind operation is used to establish relationship between two SCFs. This operation is mandatory and it is sent by a controlling SCF each time it needs to initiate communications with another (supporting) SCF; in order to ensure that the called entity has all facilities to operate on messages to be sent. 7.26.2 Parameters agreementID; originatingScfAddress; credentials; respondingScfAddress; returnedCredentials.
7.26.3 Invoking entity (Controlling SCF) 7.26.3.1 Normal procedure SCF Precondition: 1) The SCF FSM is in the state 1 "Idle". 2) The SCF has received a user request that it is not able to handle, or the SCF has recognized a call condition previously registered as a call condition for which assistance from another SCF is needed. 3) The SCF knows the address of the SCF being able to provide assistance. SCF Postconditions: 1) The SCF FSM moves to state 2 "Preparing Handling Information Request".
56
The address of the SCF the "SCF Bind" operation has to be sent to is determined on the base of user related information. 7.26.3.2 Error Handling If the destination SCF is not accessible, the call is given final treatment which is service logic dependent. Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.26.4 Responding entity (supporting SCF) 7.26.4.1 Normal procedure SCF Precondition: 1) The SCF FSM is in the state 1 "Idle". SCF Postcondition: 1) An SLPI has been invoked. 2) The SCSM moves to state 2, "Processing SCF Bind", from state 1 "Idle". 3) If the Bind request is accepted, a positive result is sent to the controlling SCF; if not, it moves back to state 1 "Idle" and a negative result is sent to the controlling SCF. In the first case when the first "handlingInformationRequest" operation is received, SCSM moves to state 3 "Assisting Mode". 7.26.4.2 Error Handling If the "SCF Bind" operation is rejected the SCSM remains in the state "Idle". The maintenance function is informed and no SLPI is invoked. Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.27 SCFBind procedure (in the chaining case)
7.27.1 General description This operation is used to establish a relationship between the two SCFs involved in the chaining. This is achieved by forwarding the SCFBind operation received from the controlling SCF to the chaining terminator supporting SCF. 7.27.1.1. Parameters See SCFBind. 7.27.2 Invoking entity (chaining initiator supporting SCF) 7.27.2.1 Normal procedure 1) The SCSM-ChI is in the state "Idle". 2) The chaining initiator supporting SCF has received a "SCFBind" operation from the controlling SCF. SCF Postconditions: 1) The SCSM-ChI moves to the state "Prepare Chained Handling Information Request".
57
7.27.2.2 Error Handling If the destination SCF is not accessible, the call is given final treatment which is service logic dependent. Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.27.3 Responding entity (chaining terminator supporting SCF) 7.27.3.1 Normal procedure SCF Precondition: 1) The SCF FSM is in the state 1 "Idle". SCF Postcondition: 1) An SLPI has been invoked. 2) The SCSM moves to state "Bind Pending". 3) If the Bind request is accepted, a positive result is sent to the controlling SCF; if not, it moves back to state 1 "Idle" and a negative result is sent to the controlling SCF. 7.27.3.2 Error Handling If the "SCF Bind" operation is rejected the SCSM remains in the state "Idle". The maintenance function is informed and no SLPI is invoked. Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.28 TFCBind procedure
7.28.1 General description The "TFCBind" operation is used by an SCF to create an association between itself and a responding SCF. It carries the authentication information of the initiating SCF if any. It is syntactically identical to the DirectoryBind operation. For a full description of the DirectoryBind operation, refer to 8.1/X.511. 7.28.2 Parameters Refer to the IN-DirectoryBind procedure because all the parameters of this operation are equivalent to those of the IN-DirectoryBind operation. 7.28.3 Invoking entity 7.28.3.1 Normal procedure Initiating SCF Preconditions: Initiating SCME-FSM: "Idle". Initiating SCF Postconditions: 1) Initiating SCME-FSM: "Active" in case of success. 2) Initiating SCME-FSM: "Idle" in case of failure. The initiating SCME-FSM is created when the SCF detects the need to apply traffic flow control (TFC) to a responding SCF and there is no existing SCME-FSM associated with the responding SCF.
58
Once created, and the initiating SCME-FSM is in the state "Idle", a TFCBind operation can be sent. This causes a transition to the state "Wait for TFC" and other operations are awaited. The initiating SCME-FSM remains in the state "Wait for TFC" until either a sending of the first TFC operation is requested or a delimiter is indicated. Either event causes a transition to the state "Wait for BindResult". The TFCBind operation (and first TFC operation if present) is sent to the responding SCF. The initiating SCME-FSM waits for the response from the responding SCF. The reception of the result to the TFCBind operation causes a transition of the initiating SCME-FSM to the state "Active". Otherwise the reception of an error moves the initiating SCME-FSM back to the state "Idle". 7.28.3.2 Error Handling No additional error handling is required for this operation. 7.28.4 Responding entity (responding SCF) 7.28.4.1 Normal procedure Responding SCF Preconditions: Responding SCME-FSM: "Idle". Responding SCF Postconditions: (1) Responding SCME-FSM: "SCF Active" (success). (2) Responding SCME-FSM: "Idle" (failure). The reception of a "TFCBind" operation from a initiating SCF causes the creation of a responding SCME-FSM within the responding SCF. Once the responding SCME-FSM is in the initial state "Idle", it receives the external event (E1) TFCBind and a transition to state "Wait for BindResult" occurs. The responding SCF performs the TFCBind operation according to the contents of the TFCBind argument. Once the responding SCF has completed the "TFCBind" operation, the result or error indication is returned to the initiating SCF. The responding SCF returns to the state "Idle" if the TFCBind fails or to the state "Active" if the TFCBind is successful. 7.28.4.2 Error Handling No additional error handling is required for this operation. 7.29 TrafficFlowControl procedure
7.29.1 General description This operation is used to request the responding SCF to reduce the rate at which specific service requests are sent to the initiating SCF. 7.29.2 Parameters 7.29.2.1 Argument Parameters The operation argument consists of the following parameters, which are defined in clause 7. tfcCriteria; duration; controlType; security; wasChained.
59
7.29.2.2 Result Parameters None. 7.29.3 Invoking entity (Initiating SCF) 7.29.3.1 Normal procedure Initiating SCF Preconditions: 1) a) Initiating SCME-FSM: "Wait for TFC". b) Initiating SCME-FSM: "Wait for BindResult"; or Initiating SCME-FSM: "Active". 2) The initiating SCME-FSM detects an overload condition persists and traffic flow control has to be initiated at the responding SCF; or the initiating SCF receives a manually initiated traffic flow control request. Initiating SCF Postcondition: 1) a) Initiating SCME-FSM: "Wait for BindResult". b) Initiating SCME-FSM: remains in the same state. A congestion detection and control algorithm monitors the load of initiating SCF resources. After detection of a congestion situation the parameters for the "TrafficFlowControl" operation are provided. If the congestion level changes new "TrafficFlowControl" operations may be sent for active traffic flow controls but with new control values. If no congestion is detected traffic flow control may be removed. A manual initiated traffic flow control will take prevail over an automatic initiated traffic flow control. 7.29.3.2 Error Handling Operation related error handling is not applicable, due to class 4 operation. 7.29.4 Responding entity (Responding SCF) 7.29.4.1 Normal procedure Responding SCF Preconditions: 1) Responding SCME-FSM: "Wait for BindResult"; or Responding SCME-FSM: "Active". Responding SCF Postconditions: 1) Responding SCME-FSM: "Active". 2) Traffic flow control for tfcCriteria is activated; or Traffic flow control for tfcCriteria is renewed; or Traffic flow control for tfcCriteria is removed. If the responding SCME-FSM is in state "Wait for BindResult" then the incoming "TrafficFlowControl" operation is stored until the bind process is resolved. If the "TFCBind" operation succeeds then the "TrafficFlowControl" operation is processed otherwise it is discarded. If the responding SCME-FSM is in state "Active" then the incoming "TrafficFlowControl" operation is processed.
60
In general, the manuallyInitiated traffic flow control will prevail over automatically initiated. The traffic flow control process is stopped if the indicated duration equals ZERO. 7.29.4.2 Error Handling Operation related error handling is not applicable, due to class 4 operation. 7.30 TransferSTSI procedure
7.30.1 General description This operation may be used from the controlling SCF to the supporting SCF - and vice versa to exchange service information. The received service information will be used in the SCF to determine how the service is to be proceeded. The type of service information is used to assist the service logic execution and may consists of e.g. call unrelated as well as call related data. The operation may be used to request service data and report service data results. It may be sent during establishment of a relationship after an HandlingInformationRequest operation has been issued or it may be sent during an established relationship. If a result is requested the correlation between send service data request and reported service data result is to be made on the service application level. 7.30.2 Parameters sSIInfo; securityParameters; extensions.
7.30.3 Invoking entity (controlling SCF) 7.30.3.1 Normal procedure SCF Precondition: 1) A relationship has been requested by the controlling SCF and a handlingInformationRequest operation has been issued, otherwise the relationship has been already established between the two SCFs. 2) The SLPI has identified the need for sending service information from the controlling SCF. 3) The SCF FSM is in the state WaitingForBindResult (controlling SCF) or Assisted Mode (controlling SCF). SCF Postcondition: 1) SLPI execution continues. 2) The SCF FSM remains in the same state. 7.30.3.2 Error Handling Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1.
61
7.30.4 Invoking entity (supporting SCF) 7.30.4.1 Normal procedure SCF Precondition: 1) A relationship has been established between the two SCFs. 2) The SLPI has identified the need for sending service information from the supporting SCF. 3) The SCF FSM is in the state Assisting Mode (supporting SCF). SCF Postcondition: 1) SLPI execution continues. 2) The SCF FSM remains in the same state. 7.30.4.2 Error Handling Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.30.5 Responding entity (supporting SCF) 7.30.5.1 Normal procedure SCF Precondition: 1) A relationship has been established between the two SCFs. 2) The SCF FSM is in the Assisting Mode (supporting SCF). SCF Postcondition: 1) SLPI execution continues. 2) The SCF FSM remains in the same state. 7.30.5.2 Error Handling Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. 7.30.6 Responding entity (controlling SCF) 7.30.6.1 Normal procedure SCF Precondition: 1) A relationship has been established between the two SCFs. 2) The SCF FSM is in the Assisted Mode (controlling SCF). SCF Postcondition: 1) SLPI execution continues. 2) The SCF FSM remains in the same state. 7.30.6.2 Error Handling Generic error handling for the operation related errors is described in clause 9 and the TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1.
62
Parameters
This clause defines the parameters used in the operation procedures as specified in clause 7. 8.1 AccountNumber
This parameter provides the unique identification of the account to which the cost of a call is registered. 8.2 Acksequence
This parameter contains a reference which is used to correlate several charging related operations. 8.3 Actions
The parameter provides the type of action to be performed during a user interaction procedure (i.e. sending of an announcement or sending of an announcement followed by digit collection). 8.4 ActiveSupplementaryServices
This parameter contains the list of supplementary services that have been activated by the user. These activated supplementary services can have an impact on the call. Only information available to the SCF can be provided. 8.5 AgreementID
This parameter identifies the service logic type which will be supported across the SCF-SCF interface during the lifetime of the association. An agreement may correspond to a service logic type which is standardized at the ITU level or by any regional standard organization. It may also correspond to a service logic bilaterally defined by two cooperation operators. In order to allow the exchange of this information across networks, each agreement should be assigned an object identifier. The AgreementID value is the object identifier value. 8.6 BearerCapabilities
This parameter (either in the invoke or in the result) contains the list of the bearer services that are available to the user in the context of the call. The list is specific of the user and of the call context. 8.7 BearerCapability
This parameter is defined in Recommendation Q.1238.2. 8.8 CalledPartyNumber
This parameter is defined in Recommendation Q.1238.2. 8.9 CallingPartyBusinessGroupID
This parameter defined in Recommendation Q.1238.2. 8.10 CallingPartysCategory
This parameter is defined in Recommendation Q.1238.2.
63
8.11
CallingPartyNumber
This parameter defined in Recommendation Q.1238.2. It may be used for applications such as customized routing service, where the supporting SCF needs to know the identity of the calling party to give routing information to the controlling SCF. 8.12 CallRecord
This parameter contains the call record related to the call. This information consists (at least) of call duration, calling party and called party number. It is network specific and defined by bilateral agreements between network operators. 8.13 Carrier
This parameter is defined in Recommendation Q.1238.1. 8.14 CauseOfLastCallFailure
This parameter gives the reason of the failure of the last call, if any. This last call is considered within the same service logic program instance. 8.15 ChargingParameters
This parameter contains the different parameters that are used to parameterize the generic charging function. 8.16 Constraints
This parameter defines what information should be expected from the user. It indicates the type and the size of the input to be dialled by the user. It also contains the number of times an announcement can be played to a user without getting a correct user input, before being considered as failed. 8.17 ConsumedCreditAction
This parameter identifies an action to be performed in case the actual cost of a call reaches the available user credit. 8.18 Container
This parameter contains free format data to be included in a call record. 8.19 ControlType
This parameter is defined in Recommendation Q.1238.2. 8.20 CounterValues
This parameter contains the current value of one or more meters. 8.21 CorrelationID
This parameter identifies a Service Logic Program instance.
64
8.22
Credentials
This is an optional parameter, placed either in the request or in the response, that conveys security credentials for requiring an authentication process on a per-association basis, with the authentication being done for a user or a invoking entity (controlling SCF). 8.23 DialledDigits
This parameter is used to convey information collected from the user through user interaction procedure or in the set-up phase and that have not been recognized as information to be included in another parameter. 8.24 Duration
This parameter specifies the total time interval during which traffic flow control will be active. It is identical to the Duration parameter defined in Recommendation Q.1238.2. 8.25 ErrorInfo
This parameter contains the information to be passed to the user if the latter has failed to provide correct inputs to a previous interaction. To verify its correctness, the user input is only challenged against the information provided in the "constraints" parameter. 8.26 Extensions
This parameter is defined in Recommendation Q.1238.1. 8.27 HighLayerCompatibilities
This parameter (either in the invoke or in the result) contains the list of the teleservices that are available to the user in the context of the call. The list is specific of the user and of the call context. 8.28 HighLayerCompatibility
This parameter is defined in Recommendation Q.1238.2. 8.29 InfoToSend
This parameter is used to convey the contents of the information passed to the user to request inputs from him/her. This information could be provided to the user with an IP, a display or a simple tone, but the mode of user interaction should be in line with the available modes that might have been provided in the "handlingInformationRequest" operation. 8.30 InvokedSupplementaryService
This parameter contains the supplementary service that has been invoked by the user. Only information available to the controlling SCF can be provided. 8.31 LocationNumber
This parameter is defined in Recommendation Q.1238.2. It is used when the "callingPartyNumber" does not contain any information about the location of the calling party. It may be used by the supporting SCF in case of a location dependent routing.
65
8.32
Notification
This parameter contains an indication that a call condition previously expressed by the supporting SCF or prearranged between the two operators has been met. It links together call condition met and some information related to call conditions (if any). 8.33 NotificationInformation
This parameter contains information that might be needed to be notified by a specific kind of service logic, in addition to the contents of the notification parameter. Information that can be conveyed has been agreed between network operators when defining the service logic object. 8.34 NumberOfAllowedRetries
The parameter provides the number of retries the user is allowed to make during a user interaction procedure. 8.35 NumberOfCallAttempts
This parameter gives the number of previous call attempts before the one that is currently handled. The number of call attempts is considered within the same service logic program instance. 8.36 OriginalCalledPartyID
See Q.762 Original Called Party Number signalling information. 8.37 OriginatingScf
This parameter is used in the context of chaining procedures, to convey the SCF identity (the encoding of this parameter required bilateral agreement between the involved operators) of the (ultimate) originator of the request when similar information is not already conveyed in the security parameter. 8.38 OriginatingScfAddress
This parameter is the address of the SCF that requests the agreement. The parameter should be absent in a chained operation request which crosses an international internetwork boundary. 8.39 PreferredLanguage
The parameter gives the language that should preferably used in user interactions. 8.40 RedirectionInformation
See Q.763 Redirection Information signalling information. 8.41 RedirectingPartyID
This parameter is defined in Recommendation Q.1238.2. 8.42 RemainingUserCredit
This parameter contains a user's credit after a call. It is expressed in terms of telecommunication units.
66
8.43
ReportAddress
This parameter contains the address of the entity to which call records have to be sent. It also includes information on the protocol to be used to communicate with this entity. 8.44 ReportCondition
This parameter indicates the conditions on which a charging report shall be issued by the controlling SCF. 8.45 ReportExpected
This parameter contains a Boolean indicating if the charging information should be passed back to the supporting SCF at the end of the call. 8.46 RequestedType
This parameter is used to identify the context in which handling information is requested. The list of allowed values (and the associated semantic) is part of the definition of each service logic type. The scope of the RequestedType IE is local to an AgreementID. 8.47 ResetOfTransmisttedCounters
This parameter indicates whether charging meters are reset when a call report is issued. 8.48 RespondingScfAddress
This parameter (in the response) contains the address of the supporting SCF. The parameter should be absent in a chained operation request which crosses an international internetwork boundary. 8.49 RoutingAddress
This parameter contains indications on how the call should be handled. These indications can be a request to forbid the call or the list of called party numbers (see Q.762) towards which the call is to be routed. The encoding of the list is defined in Q.763. If no other agreements exist, the numbers from the list shall be used sequentially. 8.50 SecurityParameters
This parameter conveys security related information in an operation argument and result. Its structure is defined in Recommendation X.511. 8.51 ScfAuthenticationLevel
This parameter is optionally supplied in the context of chaining procedures when it is required to indicate the manner in which authentication has been carried out on during a bind operation. The type of the parameter is an AuthenticationLevel described in ITU-T Recommendation X.501 | ISO/IEC 9594-2. 8.52 ScfID
This parameter identifies a physical entity which contains an SCF.
67
8.53
Splitcharge
This parameter indicates how to split the charging between "called party" and "calling party" based on the same rule. 8.54 SrfAddress
This optional parameter contains the address of the IP to be connected to the user during a user interaction procedure. 8.55 SSIInfo
This parameter identifies a service application (e.g. a service feature) within the service logic type supported across the SCF-SCF interface which is indicated in the Agreement ID in the SCF Bind operation. This parameter also contains associated service information. The Agreement Feature Indicator may correspond to a service application which is standardized at the ITU level or by any regional standardization body (i.e. Global). It may also correspond to a service application which is significant only within one network or group of cooperating networks in which the service application identified is significant (i.e. Local). AgreementFeatureIndicator: This parameter indicates the service application for which the associated service information within the Agreement ID is to be provided. The scope of the agrrementFeatureIndicator is local to an AgreementID and applicable within the context of an Requested Type. STSIInformation: This parameter conveys service information provided by the Service Logic of the invoking SCF to the Service Logic of the responding SCF. 8.56 SupplementaryServices
This parameter (either in the invoke or in the result) contains the list of the supplementary services that are available to the user in the context of the call. The list is specific of the user and of the call context. 8.57 Target
This parameter is used in the context of chaining procedures to indicate the identity of the subscriber involved in an operation. 8.58 Timelimit
This parameter is used in the context of chaining procedures to indicate the time by which an operation is to be completed. 8.59 TfcCriteria
This parameter identifies the criteria for a service to be subject to traffic flow control. It is defined in Recommendation Q1238.4. 8.60 TraceInformation
This parameter is used in the context of chaining procedures to provide information to prevent looping among SCFs when chaining an operation, this information is similar to that defined for the X.518 chaining mechanism (See ITU-T Recommendation X.518). This parameter is present in the operation argument and in the result parameter (if any).
68
8.61
TypeOfRequestedInfo
The parameter provides the type information to be requested to the user during a user interaction procedure. 8.62 UltimateResponder
This parameter is used in the context of chaining procedures to convey back the ISDN address of the (ultimate) SCF responder. 8.63 UniqueCallID
This parameter contains a reference which uniquely identifies a call. There is a one-to-one relationship between this identity, the identity of the service logic program instance that treats the call and the identity of the assisting service logic program instance. This information can be further used to address a specific logic program instance. 8.64 UserCredit
This parameter contains a user's credit. It is expressed in terms of telecommunication units. 8.65 UserInformation
The parameter contains the information collected from the user during a user interaction procedure. 8.66 UserInteractionModes
This parameter conveys the type of user interaction modes that are available in the invoking network. 8.67 UserToConnect
This parameter indicates with which party(ies) an SRF has to be connected. The parties involved are listed from the first involved in the call to the last. There are four possibilities: the first party connected (left referential); all the other but the first (complementary of the previous); the last connected (right referential); all the other but the last (complementary of the previous). 8.68 WasChained
This parameter is defined in Recommendation Q.1238.4. 9 Error Procedures
The following subclauses define the generic error handling for the operation related error procedures on the SCF-SCF interface. The errors are defined as operation errors in the related operations ASN.1 descriptions. The TCAP services which are used for reporting operation errors are described in Recommendation Q.1238.1. Errors which have a specific procedure for an operation are described with the detailed procedure of the related operation.
69
Table 1/Q.1238.6 provides the list of operations which may return each of the errors used on the SCF-SCF interface.
TABLE 1/Q.1238.6 Applicability of errors

Co Errors P I C R Rq Re I I N R C I I C P U C Co E H H N N P R R N C C N P C C R C I ImproperCallerResponse MissingCustomerRecord MissingParameter ParameterOutOfRange ScfReferral SecurityError SystemFailure UnexpectedComponent Sequence UnexpectedDataValue UnexpectedParameter ChainingRefused TfcBindError ScfBindFailure ScfTaskRefused X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X C E C R C H I Rq C H I Re
70
CoNP ConfirmedNotificationProvided CoRCI ConfirmedReportChargingInformation ECR EstablishChargingRecord HIRq HandlingInformationRequest HIRe HandlingInformationResult NC NP PUI RCI RN NetworkCapability NotificationProvided ProvideUserInformation ReportChargingInformation RequestNotification
CCNP ChainedConfirmedNotificationProvided CCRCI ChainedConfirmedReportChargingInformation CECR ChainedEstablishChargingRecord CHIRq ChainedHandlingInformationRequest CHIRe ChainedHandlingInformationResult CNC CNP ChainedNetworkCapability ChainedNotificationProvided
CPUI ChainedProvideUserInformation CRCI ChainedReportChargingInformation CRN ChainedRequestNotification SCFB SCFBind TFCB TFCBind 9.1.1 ChainingRefused
The Chaining RefusedUnexpectedParameter error is defined in Recommendation Q.1238.1. 9.1.1.1 Procedures at invoking entity (SCF) A) Sending operation: Precondition: refer to relevant "Operation procedures - SCF precondition" clause. Postcondition: refer to the relevant "Operation procedures - SCF postcondition" clause. B) Receiving Error: Precondition: refer to the relevant "Operation procedures - SCF postcondition" clause. Postcondition: Remains in the same state. Error treatments in chaining Initiator SCF depend on service logic. No further error treatment is performed in supporting SCF of chaining terminator SCF. 9.1.1.2 Procedures at responding entity (SCF) A) Receiving operation:
71
B)
Precondition: refer to relevant "Operation procedures - SCF precondition" clause. Postcondition: refer to the relevant "Operation procedures - SCF postcondition" clause. Returning Error: Precondition: refer to the relevant "Operation procedures - SCF postcondition" clause. Postcondition: remains in the same state.
Error treatments in the chaining Initiator SCF depend on service logic. No further error treatment is performed in supporting SCF of chaining terminator SCF. 9.1.2 ImproperCallerResponse
The ImproperCallerResponse error is defined in Recommendation Q.1238.1. 9.1.2.1 Procedures at invoking entity (SCF) A) Sending operation: Precondition: refer to relevant "Operation procedures - SCF precondition" clause. Postcondition: refer to the relevant "Operation procedures - SCF postcondition" clause. B) Receiving Error: Precondition: refer to the relevant "Operation procedures - SCF postcondition" clause. Postcondition: remains in the same state. Once the supporting SCF or chaining terminator supporting SCF receives this type of error, it is waiting the reception of an IN-Unbind operation. A guard timer is armed. 9.1.2.2 Procedures at responding entity (SCF) A) Receiving operation: Precondition: refer to the relevant "Operation procedures SCF - precondition" clause. Postcondition: refer to the relevant "Operation procedures SCF - postcondition" clause.
72
B)
Returning Error: Precondition: refer to the relevant "Operation procedures SCF- postcondition" clause. Postcondition: remains in the same state.
Once the controlling SCF issues this type of error, internal event (e12) SCFUnbind in SCSM-Con or event (e6) SCFUnbind in SCMS-ChI occurs. 9.1.3 MissingCustomerRecord
The MissingCustomerRecord error is defined in Recommendation Q.1238.1. 9.1.3.1 Procedures at invoking entity (SCF) A) Sending operation: Precondition: refer to relevant "Operation procedures - SCF precondition" clause Postcondition: refer to the relevant "Operation procedures - SCF postcondition" clause. B) Receiving Error: Precondition: refer to the relevant "Operation procedures - SCF postcondition" clause. Postcondition: remains in the same state. Error treatments in controlling SCF or chaining Initiator SCF depend on service logic. No further error treatment is performed in supporting SCF of chaining terminator SCF. 9.1.3.2 Procedures at responding entity (SCF) A) Receiving operation: Precondition: refer to relevant "Operation procedures - SCF precondition" clause. Postcondition: refer to the relevant "Operation procedures - SCF postcondition" clause. B) Returning Error: Precondition: refer to the relevant "Operation procedures SCF- postcondition" clause. Postcondition: remains in the same state. Error treatments in controlling SCF or chaining Initiator SCF depend on service logic. No further error treatment is performed in supporting SCF of chaining terminator SCF. 9.1.4 MissingParameter
The MissingParameter error is defined in Recommendation Q.1238.1. 9.1.4.1 Procedures at invoking entity (SCF) A) Sending operation: Precondition: refer to relevant "Operation procedures - SCF precondition" clause. Postcondition: refer to the relevant "Operation procedures - SCF postcondition" clause. B) Receiving Error: Precondition: refer to the relevant "Operation procedures - SCF postcondition" clause. Postcondition: remains in the same state. Error treatments in controlling SCF or chaining Initiator SCF depend on service logic. No further error treatment is performed in supporting SCF of chaining terminator SCF.
73
9.1.4.2 Procedures at responding entity (SCF) A) Receiving operation: Precondition: refer to relevant "Operation procedures - SCF precondition" clause Postcondition: refer to the relevant "Operation procedures - SCF postcondition" clause. B) Returning Error Precondition: refer to the relevant "Operation procedures - SCF postcondition" clause. Postcondition: remains in the same state. Error treatments in controlling SCF or chaining Initiator SCF depend on service logic. No further error treatment is performed in supporting SCF of chaining terminator SCF. 9.1.5 ParameterOutOfRange
The ParameterOutOfRange error is defined in Recommendation Q.1238.1. 9.1.5.1 Procedures at invoking entity (SCF)
Error procedures for the MissingParameter error are applicable. 9.1.5.2 Procedures at responding entity (SCF)
Error procedures for the MissingParameter error are applicable. 9.1.6 ScfReferral
The ScfReferral error is defined in Recommendation Q.1238.1. 9.1.6.1 A) Procedures at invoking entity (controlling SCF or supporting chaining initiator SCF) Sending operation: Precondition: refer to relevant "Operation procedures - SCF precondition" clause Postcondition: refer to the relevant "Operation procedures - SCF postcondition" clause. Receiving Error Precondition: refer to the relevant "Operation procedures - SCF postcondition" clause. Postcondition: remains in the same state.
B)
After receiving the SCFreferral error, the SCF can request assistance to another SCF. 9.1.6.2 Procedures at responding entity (SCF) A) Receiving operation: Precondition: refer to relevant "Operation procedures - SCF precondition" clause. Postcondition: refer to the relevant "Operation procedures - SCF postcondition" clause. B) Returning Error: Precondition: refer to the relevant "Operation procedures - SCF postcondition" clause. Postcondition: remains in the same state. After returning the error, the assisting SCF is waiting for IN-Unbind operation. No further error treatments take place. If a guard timer expires event in SCSM-Sup or in SCSM-ChT will occur.
74
9.1.7
Security
The Security error is defined in Recommendation Q.1238.1. 9.1.7.1 Procedures at invoking entity (SCF) A) Sending operation: Precondition: refer to relevant "Operation procedures - SCF precondition" clause. Postcondition: refer to the relevant "Operation procedures - SCF postcondition" clause. B) Receiving Error: Precondition: refer to the relevant "Operation procedures - SCF postcondition" clause. Postcondition: remains in the same state. Once the security error is reported to the controlling SCF or chaining initiator internal logic, the need to send a IN-Unbind operation is determined. Once the supporting SCF or the chaining terminator SCF receives a security error, it expects to receive an IN-Unbind operation. This event is guarded by a expiration timer. 9.1.7.2 Procedures at responding entity (SCF) A) Receiving operation: Precondition: refer to relevant "Operation procedures - SCF precondition" clause. Postcondition: refer to the relevant "Operation procedures - SCF postcondition" clause. B) Returning Error Precondition: refer to the relevant "Operation procedures - SCF postcondition" clause. Postcondition: remains in the same state. The security error is reported to the controlling SCF internal logic and the need to send a IN-Unbind operation is determined. Once the supporting SCF or the chaining terminator SCF receives a security error, if this event does not causes a transition to idle, it expects to receive an IN-Unbind operation. This event is guarded by a expiration timer. 9.1.8 SystemFailure
The SystemFailure error is defined in Recommendation Q.1238.1. 9.1.8.1 Procedures at invoking entity (SCF)
Error procedures for the MissingParameter error are applicable. 9.1.8.2 Procedures at responding entity (SCF)
Error procedures for the MissingParameter error are applicable. 9.1.9 UnexpectedComponentSequence
The UnexpectedComponentSequence error is defined in Recommendation Q.1238.1. 9.1.9.1 Procedures at invoking entity (SCF)
Error procedures for the MissingParameter error are applicable.
75
9.1.9.2
Procedures at responding entity (SCF)
Error procedures for the MissingParameter error are applicable. 9.1.10 UnexpectedDataValue The UnexpectedDataValue error is defined in Recommendation Q.1238.1. 9.1.10.1 Procedures at invoking entity (SCF) Error procedures for the MissingParameter error are applicable. 9.1.10.2 Procedures at responding entity (SCF) Error procedures for the MissingParameter error are applicable. 9.1.11 UnexpectedParameter The UnexpectedParameter error is defined in Recommendation Q.1238.1. 9.1.11.1 Procedures at invoking entity (SCF) Error procedures for the MissingParameter error are applicable. 9.1.11.2 Procedures at responding entity (SCF) Error procedures for the MissingParameter error are applicable. 9.1.12 ScfBindFailure The ScfBindFailure error is defined in Recommendation Q.1238.1. 9.1.12.1 Controlling SCF-> Supporting SCF 9.1.12.1.1 Procedure at Invoking Entity (Controlling SCF) A) Sending Operation: Precondition: SCSM-Con state 1 Idle Postcondition: SCSM-Con state 3 Wait for Bind result B) Receiving Error: Precondition: SCSM-Con state 3 Wait for Bind result Postcondition: SCSM-Con state 1 Idle Error procedure is independent of the Service Logic. The service processing should be terminated. 9.1.12.1.2 Procedure at Responding Entity (Supporting SCF) A) Receiving Operation: Precondition: SCSM-Sup state 1 Idle Postcondition: SCSM-Sup state 2 Bind Pending B) Returning Error: Precondition: SCF FSM state 2 Bind Pending (in case of Bind) Postcondition: SCF FSM state 1 Idle (in case of Bind) The SCF could not perform the operation and therefore sends a Security error to the SCF. After returning the error, no further error treatment is performed.
76
9.1.12.2 Chaining Initiator Supporting SCF-> Terminator Supporting SCF 9.1.12.2.1 Procedure at Invoking Entity (Initiator Supporting SCF) A) Sending Operation: Precondition: SCSM-ChI state 1 Idle Postcondition: SCSM-ChI state 3 Wait for Bind result B) Receiving Error: Precondition: SCSM-ChI state 3 Wait for Bind result Postcondition: SCSM-ChI state 1 Idle Error procedure is independent of the Service Logic. The service processing should be terminated. 9.1.12.2.2 Procedure at Responding Entity (Terminator Supporting SCF) A) Receiving Operation: Precondition: SCSM-ChT state 1 Idle Postcondition: SCSM-ChT state 2 Bind Pending B) Returning Error: Precondition: SCSM-ChT state 2 Bind Pending (in case of Bind) Postcondition: SCSM-ChT state 1 Idle (in case of Bind) 9.1.13 ScfTaskRefused The ScfTaskRefused error is defined in Recommendation Q.1238.1. 9.1.13.1 Procedures at invoking entity (SCF) Error procedures for the MissingParameter error are applicable. 9.1.13.2 Procedures at responding entity (SCF) Error procedures for the MissingParameter error are applicable. 9.1.14 TFCBindError The "TFCBindError" error is defined in Recommendation Q.1238.1. 9.1.14.1.1 Procedures at invoking entity (Initiating SCF) A) Sending Operation: Precondition: refer to the relevant "Operation procedures SCF - precondition" clause. Postcondition: refer to the relevant "Operation procedures SCF - postcondition" clause. B) Receiving Error: Precondition: refer to the relevant "Operation procedures SCF - postcondition" clause. Postcondition: Idle. The traffic flow control association should be terminated. 9.1.14.1.2 Procedures at responding entity (Responding SCF) A) Receiving operation: Precondition: refer to the relevant "Operation procedures SCF - precondition" clause. Postcondition: refer to the relevant "Operation procedures SCF - postcondition" clause.
77
B)
Returning Error: Precondition: refer to the relevant "Operation procedures SCF - precondition" clause. Postcondition: SCME FSM state 1: Idle.
The responding SCF could not perform the operation and therefore sends a TFCBindError to the initiating SCF. After returning the error, no further error treatment is performed. 10 ASN.1 definitions
ASN.1 text is available in electronic form electronically from the SG 11 web page http://www.itu.int/itudoc/itu-t/com11/reports. 10.1 Data types
The following ASN.1 module defines the data types used in the specification of the arguments and results of the operations invoked on the SCF-SCF interface.
IN-CS3-SCF-SCF-datatypes {ccitt recommendation q 1238 modules(1) in-cs3-scf-scf-datatypes (20) version1(0)} DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS Code FROM Remote-Operations-Information-Objects ros-InformationObjects Integer4 FROM IN-CS3-common-datatypes common-datatypes COMMON-BOUNDS FROM IN-CS3-Common-Classes common-classes SCF-SSF-BOUNDS FROM IN-CS3-SSF-SCF-Classes ssf-scfssf-scf-classes SCF-SCF-BOUNDS FROM IN-CS3-SCF-SCF-Classes scf-scf-classes CalledPartyNumber{}, CallingPartyNumber{}, Cause{}, DateAndTime, DestinationRoutingAddress{}, DisplayInformation{}, Duration, GenericNumber{} FROM IN-CS3-SSF-SCF-datatypes Tone FROM IN-CS3-SCF-SRF-datatypes
ssf-scf-datatypes
scf-srf-datatypes
DistinguishedName FROM DirectoryInformationFramework information-framework ros-InformationObjects, ds-UsefulDefinitions, operationcodes, guls-Notation,
78
guls-SecurityTransformations, errortypes, errorcodes, scf-scf-Protocol, ssf-scf-Operations, ssf-scf-datatypes, spkmGssTokens, common-datatypes, ssf-scf-classes, scf-scf-classes, common-classes, scf-srf-datatypes FROM IN-CS3-object-identifiers {ccitt recommendation q 1238 modules(1) in-cs3-object-identifiers(0) version1(0)} directoryAbstractService, enhancedSecurity, information-framework, selectedAttributeTypes, distributedOperations, basicAccessControl FROM UsefulDefinitions ds-UsefulDefinitions PresentationAddress FROM SelectedAttributeTypes selectedAttributeTypes ; -- The following short-hand notation is used to refer to ASN.1 Information Object Classes -- representing parameters bounds. B1 ::= COMMON-BOUNDS B2 ::= SCF-SSF-BOUNDS B6 ::= SCF-SCF-BOUNDS -- defined in Recommendation Q.1238.1 -- defined in Recommendation Q.1238.2 -- defined in this Recommendation Q.1238.6
AccountNumber ::= NumericString (SIZE (1..151))
Actions ::= ENUMERATED { play (0) , playandcollect (1) } AgreementFeatureIndicator ::= Code --This AgreementFeatureIndicator indicates the service application for which the service data is to be provided. AgreementID ::= OBJECT IDENTIFIER BasicChargingParameters {B6 : b6} ::= SEQUENCE { unitsPerInterval [0] INTEGER (0..b6.&maxUnitsPerInterval), timePerInterval [1] INTEGER (0..b6.&maxTimePerInterval), scalingFactor [2] INTEGER (0..b6.&maxScalingFactor), initialUnitIncrement [3] INTEGER (0..b6.&maxInitialUnitIncrement) OPTIONAL, unitsPerDataInterval [4] INTEGER (0..b6.&maxUnitsPerDataInterval) OPTIONAL, segmentsPerDataInterval [5] INTEGER (0..b6.&maxSegmentsPerDataInterval) OPTIONAL, initialTimeInterval [6] INTEGER (0..b6.&maxInitialTimeInterval) OPTIONAL } BearerCapabilities ::= BIT STRING {
79
speech (0), bc64kbits (1), bc2x64kbits (2), bc384kbits (3), bc1536kbits (4), bc1920kbits (5), multirate (6), restrictedDigitalInfo (7), bc3-1khzAudio (8), bc7khzAudio (9), video (10) }
CallConditions {B2:b2} ::= CHOICE { userAbandon callFailure noReply callRelease ss-invocation creditLimitReached callDuration calledNumber answeredCall } CallIdentifier ::= Integer4
[0] NULL, [1] CauseValue, [2] INTEGER, -- time expressed in seconds [3] NULL, [4] InvokableService, [5] INTEGER, [6] INTEGER, [7] NumberMatch {b2}, [8] NULL
CallRecord {B2 :b2} ::= SEQUENCE { callDuration callingPartyNumber calledPartyNumber }
[0] Duration, [1] CallingPartyNumber {b2}, [2] CalledPartyNumber {b2}
ChargingParameters {B6 :b6}::= CHOICE { basic [1] BasicChargingParameters {b6}, tariffs [20] Tariffs {b6}, mutual [21] Code --indicated an indexed charging rule -- agreed between operator-} ChargingSignallingInformation ::= SEQUENCE{ partyToBeCharged PartyToBeCharged, percentage INTEGER (0..100)}
CollectedInfo ::= CHOICE { collectedDigits iA5Information CollectedDigits ::= SEQUENCE { minimumNbOfDigits maximumNbOfDigits endOfReplyDigit cancelDigit startDigit firstDigitTimeOut
[0] CollectedDigits, [1] BOOLEAN }
[0] INTEGER (1.. 127) [1] INTEGER (1.. 127) , [2] IA5String (SIZE (1) ) [3] IA5String (SIZE (1) ) [4] IA5String (SIZE (1) ) [5] INTEGER (1.. 127)
DEFAULT 1, OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL,
80
interDigitTimeOut errorTreatment interruptableAnnInd voiceInformation voiceBack }
[6] INTEGER (1.. 127) OPTIONAL, [7] ErrorTreatment DEFAULT reportErrorToScf, [8] BOOLEAN DEFAULT TRUE, [9] BOOLEAN DEFAULT FALSE, [10] BOOLEAN DEFAULT FALSE
ConsumedCreditAction ::= ENUMERATED {disconnect(0), message(1), tone (2)}
Credit {B6 : b6} ::= CHOICE { currency units }
CurrencyValue {b6}, CreditUnit
CreditUnit ::= INTEGER (0..maxCreditUnit) maxCreditUnit INTEGER ::= 65536 CurrencyID ::= PrintableString (SIZE (3) ) -- ISO 639 code CurrencyValue {B6 : b6} ::= SEQUENCE { currency CurrencyID, amount INTEGER (0..b6.&maxAmount) } Destination {B2 : b2} ::= SEQUENCE { type genadd presadd
[1] ENUMERATED{e164 (0), x121 (1) }, [2] GenericNumber {b2}OPTIONAL, [3] PresentationAddress OPTIONAL}
ErrorTreatment ::= ENUMERATED { reportErrorToScf(0), help(1), repeatPrompt(2) } Event ::= CHOICE { duration event } maxTimeInterval INTEGER ::= 65536
[1] INTEGER(0..maxTimeInterval), [2] ENUMERATED {now (0), answer (1), user-interaction (2),failure(3)}
FreeContainer {B6 :b6 }::= OCTET STRING (SIZE(1..b6.&maxFreeContainer)) HighLayerCompatibilities ::= BIT STRING { telephony (0), facsimileGroup2-3 (1), facsimileGroup4classeI (2), teletexMixedMode (3), teletexProcessableMode (4), teletexBasicMode (5), syntaxBasedVideotex (6), internationalVideotex (7),
81
telexService (8), messageHandlingSystem (9), osiApplication (10), audioVisual (11) }
InbandInfo ::= SEQUENCE { messageId numberOfRepetitions duration interval }
[0] MessageID, [1] INTEGER (1..127) [2] INTEGER (1..32767) [3] INTEGER (1..32767)
OPTIONAL, OPTIONAL, OPTIONAL
InformationToSend {B2 :b2} ::= CHOICE { inbandInfo [0] InbandInfo, tone [1] Tone, displayInformation [2] DisplayInformation{b2} }
InfoType ::= ENUMERATED { numericString (0), characterString (1), iA5String (2) }
InvokableService ::= ENUMERATED { callingLineIdentificationRestriction (1), connectedLineIdentificationRestriction (2), callWaiting (3), callHold (4), reverseCharging (5), explicitCallTransfer (6), callCompletionOnBusySubscriber (7) } MessageID ::= OBJECT IDENTIFIER Meters ::= SEQUENCE OF Meter Meter ::= SEQUENCE { meternum metervalue nbrOfMeters INTEGER ::= 128 Notification ::= ENUMERATED { userAbandon (0), callFailure (1), noReply (2), callRelease (3), ssInvocation (4), creditLimitReached (5), callDuration (6), calledNumber (7), answeredCall (8) }
[1] INTEGER(0..nbrOfMeters) OPTIONAL, [2] INTEGER}
82
NotificationInformation {B2 : b2} ::= CHOICE { userAbandonSpecificInfo [0] SEQUENCE {...}, callFailureSpecificInfo [1] SEQUENCE { failureCause [0] Cause {b2} OPTIONAL, ...}, noReplySpecificInfo [2] SEQUENCE {...}, callReleaseSpecificInfo [3] SEQUENCE { releaseCause [0] Cause {b2} OPTIONAL, timeStamp [1] DateAndTime OPTIONAL, ...}, ssInvocationSpecificInfo [4] SEQUENCE { invokedService [0] InvokableService, ...}, creditLimitReachedSpecificInfo [5] SEQUENCE { timeStamp [0] DateAndTime OPTIONAL, ...}, callDurationSpecificInfo [6] SEQUENCE { timeStamp [0] DateAndTime OPTIONAL, ...}, calledNumberSpecificInfo [7] SEQUENCE { calledNumber [0] CalledPartyNumber {b2} OPTIONAL, ...}, answeredCallSpecificInfo [8] SEQUENCE { timeStamp [0] DateAndTime OPTIONAL, ...} } NumberMatch {B2:b2} ::= CHOICE { initialMatch [0] CalledPartyNumber {b2}, totalMatch [1] CalledPartyNumber {b2} } PartyToBeCharged ::= ENUMERATED {orignating (0),terminating(1)}
ProtocolInfo ::= CHOICE { sdf [1] SDFProtocolInfo, scf [2] SCFProtocolInfo} ReceivedInformation {B6 : b6} ::= SEQUENCE SIZE (b6.&minReceivedInfo..b6.&maxReceivedInfo) OF IA5String
ReportConditionEvent {B6 :b6}::= SEQUENCE { now [1] NULL OPTIONAL, endofCall [2] NULL OPTIONAL, period [3] INTEGER(0..maxPeriodTime), remainingthreshold [5] UserCredit {b6} OPTIONAL, eachNumOfUnit [6] INTEGER OPTIONAL } maxPeriodTime INTEGER ::= 32767
ReportDestinationInformation {B2 : b2} ::= SEQUENCE { destination [1] Destination {b2}, protocolInfo [2] ProtocolInfo} RequestedNotifications {B2:b2} ::= SET OF CallConditions {b2}
83
RequestedType ::= INTEGER (0 .. 127)
RoutingAddress {B2 : b2} ::= CHOICE { routingProhibited [0] NULL, destinationRoutingAddress [1] DestinationRoutingAddress {b2} } Rule{B6 :b6} ::= BasicChargingParameters {b6} ScfAddress {B6 : b6} ::= OCTET STRING (SIZE (b6.&minScfAddress..b6.&maxScfAddress)) SCFProtocolInfo ::= AgreementID SDFProtocolInfo ::= SEQUENCE { entryname attribute SSIInfo{B6 : b6}::= SEQUENCE { agreementFeatureIndicator sTSIInformation }
DistinguishedName, OBJECT IDENTIFIER}
[0]AgreementFeatureIndicator OPTIONAL, [1] STSIInformation { b6}
STSIInformation {B6 : b6} ::= OCTET STRING (SIZE (b6.&minSSIInfoLength..b6.&maxSSIInfoLength)) -- The STSIInformation contains the service information associated with the agreementFeatureIndicator. -- provided by the Service Logic of the invoking SCF to be transferred to the Service Logic -- of the responding SCF.s SupplementaryServices ::= BIT STRING { callingLineIdentificationPresentation (1), callingLineIdentificationRestriction (2), connectedLineIdentificationPresentation (3), connectedLineIdentificationRestriction (4), callForwardingOnNoReply (5), callForwardingUnconditional (6), callForwardingOnBusy (7), callForwardingOnNotReachable (8), callWaiting (9), callHold (10), reverseCharging (11), explicitCallTransfer (12), callCompletionOnBusySubscriber (13), adviceOfChargeOnStart (14), adviceOfChargeAtEnd (15), adviceOfChargeDuringCall (16), timeDependentRouting (17), callingPartingDependentRouting (18), outgoingCallBarring (19), incomingCallBarring (20) }
Tariff {B6 :b6} ::= SEQUENCE { condition meternum rule resetAfterRCI
[1] Event, [2] INTEGER(0..nbrOfMeters) OPTIONAL, [3] Rule {b6} OPTIONAL, [4] BOOLEAN DEFAULT FALSE}
Tariffs {B6 :b6} ::= SEQUENCE OF Tariff {b6}
84
UserInteractionModes ::= BIT STRING { voiceMessage (0), tone (1), display (2) }
UserCredit{B6 : b6} ::= Credit {b6} UserToConnect END ::= ENUMERATED {first(0), nofirst(1), newone(2), previous(3)}
10.2
Information object classes
The following ASN.1 module specifies the Information Object Classes used in the definition of the operations invoked on the SCF-SCF interface.
IN-CS3-SCF-SCF-Classes {ccitt recommendation q 1238 modules(1) in-cs3-scf-scf-classes (21) version1(0)} DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS guls-Notation, common-classes, ssf-scf-classes, scf-srf-classes FROM IN-CS3-object-identifiers {ccitt recommendation q 1238 modules(1) in-cs3-object-identifiers(0) version1(0)} COMMON-BOUNDS FROM IN-CS3-Common-Classes common-classes SCF-SSF-BOUNDS FROM IN-CS3-SSF-SCF-Classes ssf-scf-classes SCF-SRF-BOUNDS FROM IN-CS3-SCF-SRF-Classes scf-srf-classes PROTECTION-MAPPING FROM Notation guls-Notation ; -- The SCF-SCF-BOUNDS object class provides a tool for the specification of the upper and lower bounds -- for parameters used on the SCF-SCF interface. SCF-SCF-BOUNDS ::= CLASS { &maxAmount &maxUnitsPerInterval &timePerInterval &scalingFactor &initialUnitIncrement &unitsPerDataInterval &segmentsPerDataInterval &initialTimeInterval &ub-nbCall &minReceivedInfo &maxReceivedInfo
INTEGER OPTIONAL, INTEGER OPTIONAL, INTEGER OPTIONAL, INTEGER OPTIONAL, INTEGER OPTIONAL, INTEGER OPTIONAL, INTEGER OPTIONAL, INTEGER OPTIONAL, INTEGER OPTIONAL, INTEGER OPTIONAL, INTEGER OPTIONAL,
85
&minScfAddress &maxScfAddress } WITH SYNTAX { [MAX-AMOUNT [MAX-UNITS-PER-INTERVAL [TIME-PER-INTERVAL [SCALING-FACTOR [INITIAL-UNIT-INCREMENT [UNITS-PER-INTERVAL [SEGMENTS-PER-INTERVAL [INITIAL-TIME-INTERVAL [UB-NB-CALL [MIN-RECEIVE-INFO [MAX-RECEIVE-INFO [MIN-SCF-ADDRESS [MAX-SCF-ADDRESS }
INTEGER OPTIONAL, INTEGER OPTIONAL
&maxAmount ] &maxUnitsPerInterval ] &timePerInterval ] &scalingFactor ] &initialUnitIncrement ] &unitsPerDataInterval ] &segmentsPerDataInterval] &initialTimeInterval ] &ub-nbCall ] &minReceivedInfo ] &maxReceivedInfo ] &minScfAddress ] &maxScfAddress ]
nsb6 SCF-SCF-BOUNDS ::= -- All values have been assigned for the purpose of ASN.1 checking only -- They should be replaced by appropriate values depending on -- network operators requirements and agreements { MAX-AMOUNT MAX-UNITS-PER-INTERVAL TIME-PER-INTERVAL SCALING-FACTOR INITIAL-UNIT-INCREMENT UNITS-PER-INTERVAL SEGMENTS-PER-INTERVAL INITIAL-TIME-INTERVAL UB-NB-CALL MIN-RECEIVE-INFO MAX-RECEIVE-INFO MIN-SCF-ADDRESS MAX-SCF-ADDRESS } 1 1 1 1 1 1 1 1 1 1 1 1 1
nsb1 COMMON-BOUNDS ::= { NUM-OF-EXTENSIONS
1}
nsb2 SCF-SSF-BOUNDS ::= { MAXIMUM-FOR-BEARER-CAPABILITY MINIMUM-FOR-CALLED-PARTY-NUMBER MAXIMUM-FOR-CALLED-PARTY-NUMBER MINIMUM-FOR-CALLING-PARTY-NUMBER MAXIMUM-FOR-CALLING-PARTY-NUMBER MINIMUM-FOR-CALLING-PARTY-SUBADDRESS
5 1 5 1 5 1
-- example value -- example value -- example value -- example value -- example value --
86
example value MINIMUM-FOR-CARRIER MAXIMUM-FOR-CARRIER MAXIMUM-FOR-CAUSE MINIMUM-FOR-DIGITS MAXIMUM-FOR-DIGITS MINIMUM-FOR-DISPLAY MAXIMUM-FOR-DISPLAY MINIMUM-FOR-GENERIC-NUMBER MAXIMUM-FOR-GENERIC-NUMBER MINIMUM-FOR-LOCATION-NUMBER MAXIMUM-FOR-LOCATION-NUMBER MINIMUM-FOR-ORIGINAL-CALLED-PARTY-ID MAXIMUM-FOR-ORIGINAL-CALLED-PARTY-ID MINIMUM-FOR-REDIRECTING-ID MAXIMUM-FOR-REDIRECTING-ID MINIMUM-FOR-SCF-ID MAXIMUM-FOR-SCF-ID } nsb3 SCF-SRF-BOUNDS ::= { MINIMUM-FOR-ATTRIBUTES MAXIMUM-FOR-ATTRIBUTES MINIMUM-FOR-MAIL-BOX-ID MAXIMUM-FOR-MAIL-BOX-ID MINIMUM-FOR-MESSAGE-CONTENT MAXIMUM-FOR-MESSAGE-CONTENT MINIMUM-FOR-RECEIVED-INFORMATION MAXIMUM-FOR-RECEIVED-INFORMATION MAXIMUM-FOR-RECORDED-MESSAGE-UNITS MAXIMUM-FOR-RECORDING-TIME NUM-OF-MESSAGE-IDS NUM-OF-VARIABLE-PARTS }
3 10 4 1 5 1 5 1 5 1 5 1 5 1 5 1 5
-- example value -- example value -- example value -- example value -- example value -- example value -- example value -- example value -- example value -- example value -- example value -- example value -- example value -- example value -- example value -- example value -- example value
1 5 1 5 1 5 1 5 5 5 2 5
-- The SCFQOP object class provides a tool for the specification of a protection policy -- on the SCF-SCF interface. SCFQOP ::= CLASS { &scfqop-id &scfBindErrorQOP &scfErrorsQOP &scfArgumentQOP &scfResultQOP } WITH SYNTAX { SCFQOP-ID SCFBINDERROR-QOP SCFERRORS-QOP SCFOPARG-QOP SCFOPRES-QOP }
OBJECT IDENTIFIER UNIQUE, PROTECTION-MAPPING, PROTECTION-MAPPING, PROTECTION-MAPPING, PROTECTION-MAPPING
&scfqop-id, &scfBindErrorQOP, &scfErrorsQOP, &scfArgumentQOP, &scfResultQOP
END
87
11
Operations and Arguments
The following ASN.1 module defines the operations used on the SCF-SCF interface and the type of their arguments.
IN-CS3-SCF-SCF-ops-args {ccitt recommendation q 1238 modules(1) in-cs3-scf-scf-ops-args (22) version1(0)} DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS
OPERATION, Code, ERROR FROM Remote-Operations-Information-Objects ros-InformationObjects SecurityParameters, Credentials, SecurityProblem, securityError FROM DirectoryAbstractService directoryAbstractService OPTIONALLY-PROTECTED{} FROM EnhancedSecurity enhancedSecurity
AccessPointInformation FROM DistributedOperations distributedOperations opcode-establishChargingRecord, opcode-handlingInformationRequest, opcode-handlingInformationResult, opcode-networkCapability, opcode-notificationProvided, opcode-confirmedNotificationProvided, opcode-provideUserInformation, opcode-confirmedReportChargingInformation, opcode-reportChargingInformation, opcode-requestNotification, opcode-runUserScript FROM IN-CS3-operationcodes operationcodes EXTENSION, COMMON-BOUNDS, SupportedExtensions {} FROM IN-CS3-Common-Classes common-classes ActivableServices, BearerCapability {}, CalledPartyNumber {}, CallingPartyNumber {}, CallingPartyBusinessGroupID, CallingPartysCategory, Carrier, Cause {}, CorrelationID{}, Digits {}, DisplayInformation {}, HighLayerCompatibility,
88
LocationNumber {}, OriginalCalledPartyID {}, RedirectingPartyID {}, RedirectionInformation, ScfID {}, TraceInformation{}, TraceItem{} FROM IN-CS3-SSF-SCF-datatypes ssf-scf-datatypes
AccountNumber, Actions, AgreementID, BearerCapabilities , CallConditions {}, CallIdentifier, CallRecord {}, ChargingParameters{}, ChargingSignallingInformation, CollectedInfo, ConsumedCreditAction{}, ErrorTreatment, FreeContainer{}, HighLayerCompatibilities, InfoType, InvokableService, Meters, Notification, NotificationInformation {}, ReceivedInformation {}, ReportConditionEvent{}, ReportDestinationInformation{}, RequestedNotifications {}, RequestedType, RoutingAddress {}, ScfAddress {}, SSIInfo {}, SupplementaryServices, UserCredit {}, UserInteractionModes, UserToConnect FROM IN-CS3-SCF-SCF-datatypes scf-scf-datatypes Extensions {}, Integer4 FROM IN-CS3-common-datatypes common-datatypes Language FROM IN-CS3-SCF-SRF-datatype improperCallerResponse, missingCustomerRecord, missingParameter, parameterOutOfRange, systemFailure, unexpectedComponentSequence, unexpectedDataValue, unexpectedParameter, chainingRefused
scf-srf-datatypes
scfBindFailure
89
FROM IN-CS3-errortypes errortypes errcode-scfReferral, errcode-scfTaskRefused FROM IN-CS3-errorcodes errorcodes AuthenticationLevel FROM BasicAccessControl basicAccessControl SPKM-ERROR FROM SpkmGssTokens spkmGssTokens activityTest FROM IN-CS3-SSF-SCF-ops-args ssf-scf-Operations ros-InformationObjects, ds-UsefulDefinitions, operationcodes, common-classes, guls-Notation, guls-SecurityTransformations, errortypes, errorcodes, scf-scf-Protocol, ssf-scf-Operations, spkmGssTokens, ssf-scf-classes, scf-srf-datatypes, scf-scf-classes, common-datatypes, ssf-scf-datatypes, scf-scf-datatypes, scf-srf-classes FROM IN-CS3-object-identifiers {ccitt recommendation q 1238 modules(1) in-cs3-object-identifiers(0) version1(0)} directoryAbstractService, enhancedSecurity, distributedOperations, basicAccessControl FROM UsefulDefinitions ds-UsefulDefinitions SCF-SCF-BOUNDS FROM IN-CS3-SCF-SCF-Classes scf-scf-classes SCF-SSF-BOUNDS FROM IN-CS3-SCF-SSF-Classes ssf-scf-classes SCF-SRF-BOUNDS FROM IN-CS3-SCF-SRF-Classes scf-srf-classes ;
-- The following short-hand notation is used to refer to ASN.1 Information Object Classes -- representing parameters bounds. B1 ::= COMMON-BOUNDS B2 ::= SCF-SSF-BOUNDS B3 ::= SCF-SRF-BOUNDS B6 ::= SCF-SCF-BOUNDS -- defined in Recommendation Q.1238.1 -- defined in Recommendation Q.1238.2 -- defined in Recommendation Q.1238.3 -- defined in this Recommendation Q.1238.6
establishChargingRecord {B1 : b1, B2 : b2, B6 : b6} OPERATION ::= { ARGUMENT EstablishChargingRecordArg {b1,b2,b6} RETURN RESULT FALSE ERRORS {missingCustomerRecord | missingParameter | systemFailure | scfTaskRefused | unexpectedComponentSequence | unexpectedDataValue | unexpectedParameter | parameterOutOfRange| securityError } ALWAYS RESPONDS FALSE
90
CODE opcode-establishChargingRecord } -- Direction: supporting SCF -> controlling SCF, Timer Tecr -- This operation is used by the supporting SCF to give charging information to the controlling -- SCF so that it can charge the user (on-line charging included). EstablishChargingRecordArg {B1 :b1, B2 : b2, B6 :b6} ::= OPTIONALLY-PROTECTED { SEQUENCE { userCredit [0] UserCredit {b6} OPTIONAL, chargingParameters ChargingParameters {b6} OPTIONAL, reportExpected [2] BOOLEAN DEFAULT TRUE, securityParameters [3] SecurityParameters OPTIONAL, extensions [4] Extensions {b1} OPTIONAL, consumedCreditAction [10] ConsumedCreditAction {b6} OPTIONAL, newChargingParameters [11] ChargingParameters {b6} OPTIONAL, reportAddress [12] ReportDestinationInformation {b2} OPTIONAL, container [13] FreeContainer {b6} OPTIONAL, correlationId [14] CorrelationID {b2} OPTIONAL, acksequence [15] INTEGER (SIZE(1..127) OPTIONAL, splitcharge [16] ChargingSignallingInformation OPTIONAL, reportCondition [22] ReportConditionEvent {b6} OPTIONAL, ... }, SCFQOP.&scfArgumentQOP{@scfqop} }
handlingInformationRequest {B1 :b1,B2 :b2,B6 :b6} OPERATION ::= { ARGUMENT HandlingInformationRequestArg {b1,b2,b6} RETURN RESULT FALSE ERRORS {missingCustomerRecord | missingParameter | parameterOutOfRange | systemFailure | scfTaskRefused | unexpectedComponentSequence | unexpectedDataValue | unexpectedParameter | securityError | scfReferral } LINKED {handlingInformationResult {b1,b2}} ALWAYS RESPONDS FALSE CODE opcode-handlingInformationRequest } -- Direction: controlling SCF -> supporting SCF , Timer Thi -- This operation may be used to request the execution of an SLP -- in the assisting SCF and to provide to the assisting -- SCF the context of the call so that it can help the controlling SCF in the processing of the call.
HandlingInformationRequestArg {B1 :b1, B2 : b2, B6 :b6} ::= OPTIONALLY-PROTECTED {SEQUENCE { requestedType [0] RequestedType OPTIONAL, callingPartyNumber [1] CallingPartyNumber {b2} OPTIONAL, locationNumber [2] LocationNumber {b2} OPTIONAL, calledPartyNumber [3] CalledPartyNumber {b2} OPTIONAL, dialledDigits [4] Digits {b2} OPTIONAL, redirectingPartyID [5] RedirectingPartyID {b2} OPTIONAL, redirectionInformation [6] RedirectionInformation OPTIONAL,
91
originalCalledPartyID [7] OriginalCalledPartyID {b2} numberOfCallAttempts [8] INTEGER (1..b6.&ub-nbCall) highLayerCompatibility [9] HighLayerCompatibility bearerCapability [10] BearerCapability {b2} invokedSupplementaryService [11] InvokableService activeSupplementaryServices [12] ActivableServices causeOfLastCallFailure [13] Cause {b2} userInteractionModes [14] UserInteractionModes callingPartysCategory [15] CallingPartysCategory callingPartyBusinessGroupID [16] CallingPartyBusinessGroupID securityParameters [17] SecurityParameters extensions [18] Extensions {b1} ... }, SCFQOP.&scfArgumentQOP{@scfqop} }
OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL,
handlingInformationResult {B1 :b1, B2 :b2} OPERATION ::= { ARGUMENT HandlingInformationResultArg {b1,b2} RETURN RESULT FALSE ERRORS {missingParameter | systemFailure | parameterOutOfRange | unexpectedComponentSequence | unexpectedDataValue | unexpectedParameter | securityError } ALWAYS RESPONDS FALSE CODE opcode-handlingInformationResult } -- Direction: supporting SCF ->controlling SCF, Timer Thir -- This operation is used by the assisting SCF to send information to the controlling SCF on how -- to process the call and to give conditions under which it should be involved in the call -- processing.
HandlingInformationResultArg {B1 :b1, B2 :b2} ::= OPTIONALLY-PROTECTED {SEQUENCE { routingAddress [0] RoutingAddress {b2} OPTIONAL, highLayerCompatibility [1] HighLayerCompatibility OPTIONAL, supplementaryServices [2] SupplementaryServices OPTIONAL, preferredLanguage [3] Language OPTIONAL, carrier [4] Carrier OPTIONAL, callingPartyNumber [5] CallingPartyNumber {b2} OPTIONAL, originalCalledPartyID [6] OriginalCalledPartyID {b2} OPTIONAL, redirectingPartyID [7] RedirectingPartyID {b2} OPTIONAL, redirectionInformation [8] RedirectionInformation OPTIONAL, callingPartysCategory [9] CallingPartysCategory OPTIONAL, securityParameters [10] SecurityParameters OPTIONAL, extensions [11] Extensions {b1} OPTIONAL, ... }, SCFQOP.&scfArgumentQOP{@scfqop} }
92
networkCapability {B1 : b1} OPERATION ::= { ARGUMENT NetworkCapabilityArg {b1} RESULT NetworkCapabilityResultArg {b1} ERRORS {missingCustomerRecord | missingParameter | systemFailure | scfTaskRefused | unexpectedComponentSequence | unexpectedDataValue | unexpectedParameter | securityError } CODE opcode-networkCapability } -- Direction: supporting SCF ->controlling SCF, Timer Tnc -- This operation is used by the supporting SCF to request from the controlling SCF which type of -- service it supports.
NetworkCapabilityArg {B1 :b1} ::= OPTIONALLY-PROTECTED { SEQUENCE { bearerCapabilities [0] BearerCapabilities OPTIONAL, highLayerCompatibilities [1] HighLayerCompatibilities OPTIONAL, supplementaryServices [2] SupplementaryServices OPTIONAL, securityParameters [3] SecurityParameters OPTIONAL, extensions [4] Extensions {b1} OPTIONAL, ... }, SCFQOP.&scfArgumentQOP{@scfqop} } NetworkCapabilityResultArg {B1 : b1} ::= OPTIONALLY-PROTECTED { SEQUENCE { bearerCapabilities [0] BearerCapabilities OPTIONAL, highLayerCompatibilities [1] HighLayerCompatibilities OPTIONAL, supplementaryServices [2] SupplementaryServices OPTIONAL, securityParameters [3] SecurityParameters OPTIONAL, extensions [4] Extensions {b1} OPTIONAL, ... }, SCFQOP.&scfArgumentQOP{@scfqop} } notificationProvided {B1 :b1, B2 :b2} OPERATION ::= { ARGUMENT NotificationProvidedArg {b1,b2} RETURN RESULT FALSE ERRORS {missingParameter | systemFailure | scfTaskRefused | unexpectedComponentSequence | unexpectedDataValue | unexpectedParameter| missingCustomerRecord | parameterOutOfRange | securityError } ALWAYS RESPONDS FALSE CODE }
opcode-notificationProvided
93
-- Direction: controlling SCF -> supporting SCF, Timer Tnp -- This operation is used by the controlling SCF to request assistance from the assisting SCF -- under specific call conditions specified prior to the sending of the operation or to notify the -- outcome of a previous intervention of the assisting SCF. NotificationProvidedArg {B1 : b1, B2 :b2} ::= OPTIONALLY-PROTECTED { SEQUENCE { notification [0] Notification, notificationInformation [1] NotificationInformation {b2} OPTIONAL, securityParameters [2] SecurityParameters OPTIONAL, extensions [3] Extensions {b1} OPTIONAL, ... }, SCFQOP.&scfArgumentQOP{@scfqop} } confirmedNotificationProvided {B1 :b1, B2 :b2} OPERATION ::= makeConfirm { notificationProvided{b1,b2}, opcode-confirmedNotificationProvided} --Direction: controlling SCF ->supporting SCF , Timer Thinc
provideUserInformation {B1 :b1, B2 : b2, B3 :b3} OPERATION ::= { ARGUMENT ProvideUserInformationArg {b1,b2,b3} RESULT ProvideUserInformationResultArg {b1,b2} ERRORS {missingCustomerRecord | missingParameter | systemFailure | scfTaskRefused | unexpectedComponentSequence | unexpectedDataValue | unexpectedParameter | improperCallerResponse | parameterOutOfRange | securityError } CODE opcode-provideUserInformation } -- Direction: supporting SCF -> controlling SCF, Timer Tpui -- This operation is used by the supporting SCF to request information from the user that can be -- interrogated by the controlling SCF.
ProvideUserInformationArg {B1 : b1, B2 :b2, B3 :b3 } ::= OPTIONALLY-PROTECTED { SEQUENCE { constraints [0] CollectedInfo, infoToSend [1] InformationToSend {b1, b2, b3}, errorInfo [2] InformationToSend {b2} OPTIONAL, typeOfRequestedInfo [3] InfoType DEFAULT numericString, numberOfAllowedRetries [4] INTEGER (0.. 127) DEFAULT 0, actions [5] Actions OPTIONAL, preferredLanguage [6] Language OPTIONAL, securityParameters [7] SecurityParameters OPTIONAL, extensions [8] Extensions {b1} OPTIONAL, srfAddress [10] CalledPartyNumber {b2} OPTIONAL, userToConnect [11] UserToConnect OPTIONAL, ... }, SCFQOP.&scfArgumentQOP{@scfqop} }
94
ProvideUserInformationResultArg {B1 :b1, B6 :b6} ::= OPTIONALLY-PROTECTED { SEQUENCE { userInformation [0] ReceivedInformation {b6}, securityParameters [1] SecurityParameters OPTIONAL, extensions [2] Extensions {b1} OPTIONAL }, SCFQOP.&scfArgumentQOP{@scfqop} }
reportChargingInformation {B1 : b1, B2 : b2, B6 : b6} OPERATION ::= { ARGUMENT ReportChargingInformationArg {b1,b2,b6} RETURN RESULT FALSE ERRORS {missingCustomerRecord | missingParameter | systemFailure | scfTaskRefused | unexpectedComponentSequence | unexpectedDataValue | unexpectedParameter | parameterOutOfRange | securityError } ALWAYS RESPONDS FALSE CODE opcode-reportChargingInformation } -- Direction: controlling SCF -> supporting SCF, Timer Trci -- This operation is used to give to the assisting network charging information collected by the -- controlling network.
ReportChargingInformationArg {B1 :b1, B2 :b2, B6 :b6} ::= OPTIONALLY-PROTECTED { SEQUENCE { callRecord [0] CallRecord {b2} OPTIONAL, remainingUserCredit [1] UserCredit {b6} OPTIONAL, uniqueCallID [2] CallIdentifier OPTIONAL, accountNumber [3] AccountNumber OPTIONAL, securityParameters [4] SecurityParameters OPTIONAL, countersValues [5] Meters OPTIONAL, resetOfTransmittedCounters [6] BOOLEAN DEFAULT FALSE, container [13] FreeContainer OPTIONAL, correlationId [14] CorrelationID {b2} OPTIONAL, acksequence [15] INTEGER OPTIONAL, ..., ..., extensions [31] Extensionsd {b1} OPTIONAL }, SCFQOP.&scfArgumentQOP{@scfqop} }
confirmedReportChargingInformation {B1 :b1, B2 :b2, B6 :b6} OPERATION ::= makeConfirm { reportChargingInformation{b1,b2,b6}, opcode-confirmedReportChargingInformation } --Direction: controlling SCF -> supporting SCF , Timer Trcic
95
requestNotification {B1 :b1, B6 : b6} OPERATION ::= { ARGUMENT RequestNotificationArg {b1,b6} RETURN RESULT FALSE ERRORS {missingParameter| systemFailure| scfTakRefused| unexpectedComponentSequence| unexpectedDataValue| unexpectedParameter| parameterOutOfRange| missingCustomerRecord| securityError } ALWAYS RESPONDS FALSE CODE opcode-requestNotification } -- Direction: supporting SCF -> controlling SCF, Timer Trn -- This operation is used by the supporting SCF to request notification from the controlling SCF -- under specific call conditions specified by this operation.
RequestNotificationArg {B1 : b1, B6 :b6} ::= OPTIONALLY-PROTECTED {SEQUENCE { requestedNotifications [0] RequestedNotifications {b6}, securityParameters [1] SecurityParameters OPTIONAL ..., ..., extensions [30] Extensions {b1} OPTIONAL }, SCFQOP.&scfArgumentQOP{@scfqop} } runUserScript{B1 : b1, B2 : b2, B6 : b6} OPERATION ::= { ARGUMENT RunUserScriptArg {b1, b2} RESULT RunUserScriptResultArg {b1, b6} ERRORS {missingCustomerRecord | missingParameter | systemFailure | scfTaskRefused | unexpectedComponentSequence | unexpectedDataValue | unexpectedParameter | improperCallerResponse | parameterOutOfRange | securityError } CODE opcode-runUserScript } -- Direction: supporting SCF -> controlling SCF, Timer Trus -- This operation is used by the supporting SCF to request the controlling SCF -- to run a user interaction script.
RunUserScriptArg {B1 : b1, B2 :b2} ::= OPTIONALLY-PROTECTED { SEQUENCE { srfAddress [0] CalledPartyNumber {b2}, correlationID [1] CorrelationID {b2}, scfID [2] ScfID { b2}, userToConnect [3] UserToConnect OPTIONAL, securityParameters [7] SecurityParameters OPTIONAL, ...,
96
..., extensions [30] Extensions {b1} OPTIONAL }, SCFQOP.&scfArgumentQOP{@scfqop} } RunUserScriptResultArg {B1 : b1 , B6 :b6} ::= ProvideUserInformationResultArg {b1,b6} scfBind {B6 :b6} OPERATION ::= { ARGUMENT RESULT ERRORS }
SCFBindArgument{b6} OPTIONAL TRUE SCFBindResult {b6} { scfBindFailure}
-- Direction: controlling SCF -> supporting SCF , Timer Tbi -- This operation is used to establish a relationship between two SCFs. It is sent by the controlling SCF each time it -- needs to initiate communications with another (supporting) SCF. SCFBindArgument {B2 : b2} ::= SEQUENCE { agreementID [0] AgreementID, originatingScfAddress [1] ScfAddress {b2} OPTIONAL, -- absent in a chained operation request which crosses -- an international internetworking boundary credentials [2] Credentials OPTIONAL } SCFBindResult {B2 : b2} ::= SEQUENCE { respondingScfAddress [0] ScfAddress {b2} OPTIONAL, -- absent in a chained operation request which crosses -- an international internetworking boundary returnedCredentials [1] Credentials OPTIONAL } transferSTSI {B1: b1, B6 : b6} OPERATION ::= { ARGUMENT TransferSTSIArg {b1,b6} RETURN RESULT FALSE ERRORS {missingParameter | systemFailure | scfTaskRefused | unexpectedDataValue | unexpectedParameter | parameterOutOfRange | securityError } ALWAYS RESPONDS FALSE CODE opcode-transferSTSI } -- Direction: controlling SCF -> supporting SCF, or supporting SCF -> controlling SCF, Timer Ttstsi -- This operation is used by the invoking SCF to request or report service information from/to the responding SCF TransferSTSIArg {B1 :b1, B6 : b6} ::= OPTIONALLY-PROTECTED {SEQUENCE { sSIInfo SSIInfo {B6 :b6}, securityParameters [2] SecurityParameters OPTIONAL, ..., ..., extensions [3] Extensions {b1} OPTIONAL, }, SCFQOP.&scfArgumentQOP{@scfqop} }
97
scfChained {OPERATION : operation, B1 :b1, B6 :b6} OPERATION ::= { ARGUMENT OPTIONALLY-PROTECTED {SEQUENCE { chainedArgument ChainingArgument {b1,b6}, argument [0] operation.&ArgumentType OPTIONAL }, SCFQOP.&scfArgumentQOP{@scfqop} } RESULT OPTIONALLY-PROTECTED {SEQUENCE { chainedResult ChainingResult {b1,b6}, result [0] operation.&ResultType OPTIONAL }, SCFQOP.&scfArgumentQOP{@scfqop} } ERRORS {operation.&Errors | chainingRefused | securityError | scfReferral } CODE operation.&operationCode } ChainingArgument {B1 : b1, B6: b6} ::= SEQUENCE { originatingSCF [0] ScfID {b6}, target [1] SubscriberId {b6} OPTIONAL, traceInformation [2] TraceInformation{b6}, scfAuthenticationLevel [3] AuthenticationLevel DEFAULT basicLevels : {level none} , timeLimit [4] UTCTime OPTIONAL, securityParameters [5] SecurityParameters OPTIONAL, extensions [6] Extensions {b1} OPTIONAL, ... }
ChainingResult {B1: b1, B6 : b6} ::= SEQUENCE { ultimateResponder [0] ScfAddress {b6} traceInformation [1] TraceInformation{b6}, securityParameters [2] SecurityParameters extensions [3] Extensions {b1} ... } makeConfirm {OPERATION:operation, Code:code} OPERATION ::= { ARGUMENT operation.&ArgumentType OPTIONAL operation.&argumentTypeOptional RESULT NULL ERRORS {operation.&Errors} ALWAYS RESPONDS TRUE CODE code} chainedEstablishChargingRecord {B1 :b1, B2 :b2, B6 :b6} OPERATION ::= scfChained{establishChargingRecord{b1,b2,b6},b1,b6}
OPTIONAL, OPTIONAL, OPTIONAL,
chainedHandlingInformationRequest {B1 : b1, B2 : b2, B6 :b6} OPERATION ::= scfChained {handlingInformationRequest{b1,b2, b6},b1,b6} chainedHandlingInformationResult {B1 :b1, B2 :b2} OPERATION ::= scfChained{handlingInformationResult{b1,b2},b1,b2}
98
chainedNetworkCapability {B1 : b1, B6 : b6} OPERATION ::= scfChained {networkCapability{b1},b1,b6} chainedNotificationProvided {B1 :b1, B2 :b2, B6 :b6} OPERATION ::= scfChained {notificationProvided{b1,b2},b1,b6} chainedConfirmedNotificationProvided {B1 : b1, B2 :b2,B6 :b6} OPERATION ::= scfChained {confirmedNotificationProvided {b1,b2},b1,b6} chainedProvideUserInformation {B1 :b1, B2 : b2, B3: b3,B6 :b6} OPERATION ::= scfChained {provideUserInformation{b1,b2,b3},b1,b6} chainedReportChargingInformation {B1 : b1, B2 : b2, B6 :b6} OPERATION ::= scfChained {reportChargingInformation{b1,b2, b6},b1,b6} chainedConfirmedReportChargingInformation {B1 :b1, B2 :b2,B6 :b6} OPERATION ::= scfChained{confirmedReportChargingInformation{b1,b2, b6}, b1,b6} chainedRequestNotification {B1 : b1, B6 : b6} OPERATION ::= scfChained{requestNotification{b1,b6}, b1,b6} chainedRunUserScript{B1 : b1, B2 : b2, B6 : b6} OPERATION ::= scfChained {runUserScript{b1,b2, b6},b1,b6}
END
The following value ranges do apply for operation specific timers in INAP: short: 1 - 10 seconds medium: 1 - 60 seconds long: 1 second - 30 minutes Table 2 lists all operationTC timers and the value range for each timer. The definitive value for each operation timer may be network specific and has to be defined by the network operator.
TABLE 2/Q.1238.6 Operation timers and their value range

Operation Name EstablishChargingRecord HandlingInformationRequest HandlingInformationResult NetworkCapability NotificationProvided ConfirmedNotificationProvided ProvideUserInformation ReportChargingInformation ConfirmedReportChargingInformatio RequestNotification RunUserScript Timer Tecr Thi Thir Tnc Tnp Tcnp Tpui Trci Tcrci Trn Trui value range short long short short short short long short short short long
99
12 12.1
Packages, Contracts ASN.1 modules
IN-CS3-SCF-SCF-pkgs-contracts-acs {ccitt recommendation q 1238 modules(1) in-cs3-scf-scf-pkgs-contracts-acs (23) version1(0)} DEFINITIONS ::= BEGIN -- This module describes the operation-packages, contracts and application-contexts used -- over the SCF-SCF interface. IMPORTS NetworkSpecificBoundSet, COMMON-BOUNDS FROM IN-CS3-Common-Classes common-classes ROS-OBJECT-CLASS, CONTRACT, OPERATION-PACKAGE, CONNECTION-PACKAGE, OPERATION FROM Remote-Operations-Information-Objects ros-InformationObjects
Bind{}, Unbind{} FROM Remote-Operations-Generic-ROS-PDUs ros-genericPDUs TCMessage {} FROM TCAPMessages tc-Messages APPLICATION-CONTEXT, dialogue-abstract-syntax FROM TC-Notation-Extensions tc-NotationExtensions establishChargingRecord {}, confirmedReportChargingInformation{}, confirmedNotificationProvided {}, handlingInformationRequest {}, handlingInformationResult {}, networkCapability {}, notificationProvided {}, provideUserInformation {}, reportChargingInformation {}, requestNotification {}, runUserScript {}, transferSTSI {}, chainedHandlingInformationRequest {}, chainedNotificationProvided {}, chainedConfirmedNotificationProvided {}, chainedReportChargingInformation {}, chainedConfirmedReportChargingInformation{}, chainedEstablishChargingRecord {}, chainedHandlingInformationResult {}, chainedNetworkCapability {}, chainedProvideUserInformation {}, chainedRequestNotification {}, chainedRunUserScript {}, scfBind{} FROM IN-CS3-SCF-SCF-ops-args scf-scf-Operations
100
id-ac, id-rosObject, id-contract, id-package, id-as, id-ac-scf-scfOperationsAC, id-ac-distributedSCFSystemAC, id-ac-scf-scfOperationsWith3seAC, id-ac-distributedSCFSystemWith3seAC, id-contract-scf-scf, id-contract-dssp, id-package-dsspConnection, id-package-scf-scfConnection, id-package-handlingInformation, id-package-notification, id-package-chargingInformation, id-package-userInformation, id-package-networkCapability, id-package-chainedSCFOperations, id-as-scf-scfOperationsAS, id-as-distributedSCFSystemAS, id-as-scf-scfBindingAS, ds-UsefulDefinitions, scf-scf-classes, ssf-scf-classes, common-classes, tc-Messages, tc-NotationExtensions, ros-InformationObjects, ros-genericPDUs, scf-scf-Operations, scf-sdf-Protocol, ssf-scf-Operations, ssf-scf-Protocol, scf-srf-classes FROM IN-CS3-object-identifiers {ccitt recommendation q 1238 modules(1) in-cs3-object-identifiers (0) version1(0)} activityTest FROM IN-CS3-SSF-SCF-ops-args ssf-scf-Operations activityTestPackage FROM IN-CS3-SSF-SCF-pkgs-contracts-acs ssf-scf-Protocol inSESEAbstractSyntax FROM IN-CS3-SCF-SDF-Protocol scf-sdf-Protocol id-se-threewayse FROM ProtocolObjectIdentifiers protocolObjectIdentifiers protocolObjectIdentifiers FROM UsefulDefinitions ds-UsefulDefinitions inUnbind FROM IN-CS3-common-classes common-classes SCF-SSF-BOUNDS FROM IN-CS3-SCF-SSF-Classes ssf-scf-classes nsb1,nsb2,nsb3,nsb6, SCF-SCF-BOUNDS FROM IN-CS3-SCF-SCF-Classes scf-scf-classes SCF-SRF-BOUNDS FROM IN-CS3-SCF-SRF-Classes scf-srf-classes
101
-- The following short-hand notation is used to refer to ASN.1 Information Object Classes -- representing parameters bounds. B1 ::= COMMON-BOUNDS B2 ::= SCF-SSF-BOUNDS B3 ::= SCF-SRF-BOUNDS B6 ::= SCF-SCF-BOUNDS -- defined in Recommendation Q.1238.1 -- defined in Recommendation Q.1238.2 -- defined in Recommendation Q.1238.3 -- defined in Recommendation Q.1238.6
-- Application Contexts -scf-scfOperationsAC APPLICATION-CONTEXT ::= { CONTRACT scf-scfContract DIALOGUE MODE structured TERMINATION basic ABSTRACT SYNTAXES {dialogue-abstract-syntax | distributedSCFBindingAbstractSyntax | scf-scfOperationsAbstractSyntax } APPLICATION CONTEXT NAME id-ac-scf-scfOperationsAC } distributedSCFSystemAC APPLICATION-CONTEXT ::= { CONTRACT dsspContract DIALOGUE MODE structured TERMINATION basic ABSTRACT SYNTAXES {dialogue-abstract-syntax | distributedSCFSystemAbstractSyntax | distributedSCFBindingAbstractSyntax} APPLICATION CONTEXT NAME id-acdistributedSCFSystemAC } scf-scfOperationsWith3seAC APPLICATION-CONTEXT ::= { CONTRACT scf-scfContract DIALOGUE MODE structured TERMINATION basic ADDITIONAL ASES {id-se-threewayse} ABSTRACT SYNTAXES {dialogue-abstract-syntax | distributedSCFBindingAbstractSyntax | scf-scfOperationsAbstractSyntax | inSESEAbstractSyntax} APPLICATION CONTEXT NAME id-ac-scfscfOperationsWith3seAC } distributedSCFSystemWith3seAC APPLICATION-CONTEXT ::= { CONTRACT dsspContract DIALOGUE MODE structured TERMINATION basic ADDITIONAL ASES {id-se-threewayse} ABSTRACT SYNTAXES {dialogue-abstract-syntax | distributedSCFSystemAbstractSyntax | distributedSCFBindingAbstractSyntax | inSESEAbstractSyntax } APPLICATION CONTEXT NAME id-acdistributedSCFSystemWith3seAC
102
-- trafficFlowControlAC APPLICATION-CONTEXT -- defined in Recommendation Q.1238.4 -- Contracts -scf-scfContract CONTRACT ::= { CONNECTION INITIATOR CONSUMER OF
RESPONDER CONSUMER OF
ID } dsspContract CONTRACT ::= { CONNECTION INITIATOR CONSUMER OF ID } -- Connection Package --
scf-scfConnectionPackage{nsb6} { activityTestPackage | handlingInformationPackage{nsb1,nsb2,nsb6} | transferStsiPackage{nsb1,nsb6} } { activityTestPackage | chargingInformationPackage{nsb1,nsb2,nsb6}| networkCapabilityPackage{nsb1}| notificationPackage{nsb1,nsb2,nsb6}| userInformationPackage{nsb1,nsb6}| transferStsiPackage{nsb1,nsb6 } } id-contract-scf-scf
dsspConnectionPackage {nsb6} {chainedSCFOperationPackage{nsb1,nsb2,nsb6}} id-contract-dssp
scf-scfConnectionPackage {B6: b6} CONNECTION-PACKAGE ::= { BIND scfBind{b6} UNBIND in-unbind RESPONDER UNBIND TRUE ID id-package-scf-scfConnection } dsspConnectionPackage {B6: b6} CONNECTION-PACKAGE ::= { BIND scfBind{b6} UNBIND in-unbind RESPONDER UNBIND FALSE ID id-package-dsspConnection } -- handlingInformation package -handlingInformationPackage {B1:b1, B2:b2, B6: b6} OPERATION-PACKAGE ::= { CONSUMER INVOKES {handlingInformationRequest {b1,b2,b6}} SUPPLIER INVOKES {handlingInformationResult {b1,b2}} ID id-package-handlingInformation } -- notification package --
103
notificationPackage {B1:b1,B2:b2,B6:b6} OPERATION-PACKAGE ::= { CONSUMER INVOKES { requestNotification {b1,b6}} SUPPLIER INVOKES { notificationProvided {b1,b2}| confirmedNotificationProvided {b1,b2,}} ID id-package-notification } -- chargingInformation package -chargingInformationPackage {B1:b1,B2:b2,B6:b6} OPERATION-PACKAGE ::= { CONSUMER INVOKES { establishChargingRecord {b1,b2,b6} } SUPPLIER INVOKES { confirmedReportChargingInformation{b1,b2,b6} | reportChargingInformation {b1,b2,b6} } ID id-package-chargingInformation} -- userInformation package -userInformationPackage {B1: b1, B6:b6} OPERATION-PACKAGE ::= { CONSUMER INVOKES {provideUserInformation {b1,b2,b3}| runUserScript {b1,b2,b6} } ID id-package-userInformation } -- networkCapability package -networkCapabilityPackage {B1: b1} OPERATION-PACKAGE ::= { CONSUMER INVOKES { networkCapability {b1}} ID id-package-networkCapability } -- transferSTSI package transferStsiPackage{B1:b1, B6:b6} OPERATION-PACKAGE ::= { OPERATIONS {transferSTSI{b1,b6}} ID id-package-transferStsi }
-- chainedSCFOperation package -chainedSCFOperationPackage {B1:b1, B2:b2, B6:b6} OPERATION-PACKAGE ::= { CONSUMER INVOKES { chainedHandlingInformationRequest {b1,b2,b6} | chainedNotificationProvided { b1,b2,b6}| chainedConfirmedNotificationProvided {b1,b2,b6}| chainedReportChargingInformation { b1,b2,b6}| chainedConfirmedReportChargingInformation{b1,b2,b6} } SUPPLIER INVOKES { chainedEstablishChargingRecord { b1,b2,b6}| chainedHandlingInformationResult { b1,b2}| chainedNetworkCapability { b1,b6}| chainedProvideUserInformation { b1,b2,b3,b6}| chainedRunUserScript {b1,b2,b6}| chainedRequestNotification { b1,b6} } ID id-package-chainedSCFOperations }
104
-- abstract syntaxes -scf-scfOperationsAbstractSyntax ABSTRACT-SYNTAX ::= { BasicSCF-SCF-PDUs IDENTIFIED BY id-as-scf-scfOperationsAS} BasicSCF-SCF-PDUs ::= TCMessage {{SCF-SCF-Invokable}, {SCF-SCF-Returnable}} SCF-SCF-Invokable OPERATION ::= { activityTest | establishChargingRecord {nsb1,nsb2,nsb6}| confirmedNotificationProvided {nsb1,nsb2,nsb6}| confirmedReportChargingInformation {nsb1,nsb2,nsb6} | handlingInformationRequest {nsb1,nsb2,nsb6}| handlingInformationResult {nsb1,nsb2}| networkCapability {nsb1}| notificationProvided {nsb1, nsb2}| provideUserInformation {nsb1,nsb2,nsb3}| reportChargingInformation {nsb1,nsb2,nsb6}| requestNotification {nsb1,nsb6}| runUserScript {nsb1,nsb2,nsb6}| transferSTSI {nsb1,nsb6} } SCF-SCF-Returnable OPERATION ::= { activityTest | establishChargingRecord {nsb1,nsb2,nsb6}| confirmedNotificationProvided {nsb1,nsb2,nsb6}| confirmedReportChargingInformation {nsb1,nsb2,nsb6}| handlingInformationRequest {nsb1,nsb2,nsb6}| handlingInformationResult {nsb1,nsb2}| networkCapability {nsb1}| provideUserInformation {nsb1, nsb2,nsb3}| requestNotification {nsb1, nsb6}| runUserScript {nsb1,nsb2,nsb6}| transferSTSI {nsb1,nsb6} } distributedSCFSystemAbstractSyntax ABSTRACT-SYNTAX ::= { BasicDSSP-PDUs IDENTIFIED BY id-as-distributedSCFSystemAS} BasicDSSP-PDUs ::= TCMessage {{DSSP-Invokable}, {DSSP-Returnable}} DSSP-Invokable OPERATION ::= { chainedHandlingInformationRequest {nsb1,nsb2,nsb6}| chainedNotificationProvided {nsb1,nsb2,nsb6}| chainedConfirmedNotificationProvided{nsb1,nsb2,nsb6} | chainedReportChargingInformation {nsb1,nsb2,nsb6}| chainedConfirmedReportChargingInformation {nsb1,nsb2,nsb6}| chainedRunUserScript{nsb1,nsb2,nsb6} }
105
DSSP-Returnable OPERATION ::= { chainedHandlingInformationRequest {nsb1,nsb2,nsb6}| chainedConfirmedNotificationProvided{nsb1,nsb2,nsb6} | chainedConfirmedReportChargingInformation {nsb1,nsb2,nsb6}| chainedRunUserScript{nsb1,nsb2,nsb6} }
distributedSCFBindingAbstractSyntax ABSTRACT-SYNTAX ::= { SCF-SCFBinding-PDUs IDENTIFIED BY id-as-scf-scfBindingAS} SCF-SCFBinding-PDUs ::= CHOICE { bind unbind } END
Bind {scfBind{nsb6}}, Unbind {in-unbind}
13 13.1
Services assumed from TCAP Normal Procedures
Dialogue handling services are used to support the invocation of bind (i.e. scfBind and tfcBind) and unbind (i.e. in-unbind) operations, and to trigger the sending of the APDUs associated with the operations involved in the INAP packages. Component grouping is performed under the control of the application-process through an appropriate usage of the TC-BEGIN and TC-CONTINUE service. On receipt of an empty TC-CONTINUE.ind primitive, the application process should ignore the primitive. The prearranged end can be used. It is an application-process responsibility to provide in the TC-BEGIN-req primitive a destination address which can be used by the underlying SCCP to route the message to the proper FE if this FE is addressed through the SS No. 7 network. 13.2 Abnormal Procedures
On receipt of a TC-U-REJECT.ind in the FE, this primitive should be ignored. It is up to the application process to abort, continue or terminate the dialogue, if not already terminated by the sending application process according to the rules as stated in Recommendation Q.1238.1. This is also applicable for invoke problems related to a class 4 linked operation. On receipt of a TC-L-REJECT indication primitive (i.e. when a protocol error has been detected by the local TC entity) which cannot be related to an active operation, it is up to the application process to continue or to terminate the dialogue and implicitly trigger the transmission of the reject component or to abort the dialogue. On receipt of a TC-NOTICE indication the SACF is informed that a message cannot be delivered by the Network Layer. It occurs if the Return Option has been set (see Recommendation Q.1238.1). It is for the application process to decide whether to terminate the dialogue or retry.
106
The receipt of a TC-U-ABORT-Ind or TC-P-ABORT-Ind on a dialogue terminates all request processing. 13.3 Dialogue Handling
13.3.1.1 Dialogue Establishment See Recommendation Q.1238.1 for common procedures. 13.3.1.2 Dialogue Continuation See Recommendation Q.1238.1 for common procedures. 13.3.1.3 Dialogue Termination See Recommendation Q.1238.1 for common procedures. 13.3.1.4 User Abort See Recommendation Q.1238.1 for common procedures. 13.3.1.5 Provider Abort If the SESE is included in the application context, and an SE-P-ABORT is required, then the SE-P-ABORT is mapped to the TC-U-ABORT primitive. 13.3.1.6 Mapping to TC Dialogue Primitives 13.3.1.7 SCSM related messages This subclause defines the mapping of the SCSM related procedures onto the TC dialogue handling services defined in ITU-T Recommendation Q.771. a) The TC-BEGIN service is used to invoke the scfBind operation and, if SESE is included in the application context, the SETransfer operation. b) The TC-CONTINUE service is used to report the success of the operations invoked in a TC-BEGIN service. If the SESE is included in the application context, the TC-CONTINUE service is used for the second and third exchanges. c) The TC-U-ABORT service is used to report the failure of operations invoked in a TC-BEGIN service. d) The TC-END service is used to invoke the inUnbind operation. The mapping of the parameters onto the TC-service is as follows: The use of the parameters of the TC-BEGIN service is as defined in Recommendation Q.1238.1 with the following qualifications: The Application Context Name parameter of the TC-BEGIN service shall correspond to one of the following contexts: scf-scfOperationsAC; distributedSCFSystemAC; scf-scfOperationsWith3seAC; distributedSCFSystemWith3seAC. The User Information parameter of the TC-BEGIN service shall contain an EXTERNAL ASN.1 Type with the direct-reference field, if present, set to id-as-scf-scfBindingAS and
107
the value to be encoded shall be of the type identified in the abstract syntax definition. If the SESE is included in the application context, the User Information parameter of the TC-BEGIN service shall also contain a value of type seItem. The use of the parameters of the TC-CONTINUE service is as defined in Recommendation Q.1238.1 with the following qualifications: The User Information parameter of the first TC-CONTINUE service shall contain an EXTERNAL ASN.1 Type with the direct-reference field, if present, set to to id-as-scfscfBindingAS and the value to be encoded shall be of the type identified in the abstract syntax definition. If the SESE is included in the application context, the User Information parameter of the TC-CONTINUE service shall also contain a value of type seItem. In subsequent TC-CONTINUE services the contents of the User Information field is network operator specific.
The use of the parameters of the TC-U-ABORT service is as defined in Recommendation Q.1238.1 with the following qualifications: The Application-Context-Name parameter of the TC-U-ABORT service shall be used as specified in ITU-T Recommendation Q.771. When the SCF refuses a dialogue because the application-context-name it receives is not supported, the value of the application-contextname it returns is selected as follows: if the value has the same root as the scf-scfOperationsAC, the scf-scfOperationsAC is used; if the value has the same root as the distributedSCFSystemWith3seAC, the distributedSCFSystemWith3seAC is used; if the value has the same root as the distributedSCFSystemAC, the distributedSCFSystemAC is used; if the value has the same root as the scf-scfOperationsWith3seAC, the scfscfOperationsWith3seAC is used; otherwise the received value is returned.
The use of the parameters of the TC-END service is as defined in Recommendation Q.1238.1. 13.3.1.8 SCME related messages This subclause defines the mapping of the SCME related procedures onto the TC dialogue handling services defined in ITU-T Recommendation Q.771. a) The TC-BEGIN service is used to invoke the tfcBind operation. b) The TC-CONTINUE service is used to report the success of the tfcBind operation. c) The TC-U-ABORT service is used to report the failure of tfcBind operation. d) The TC-END service is used to invoke the inUnbind operation. The mapping of the parameters onto the TC-service is as follows: The use of the parameters of the TC-BEGIN service is as defined in Recommendation Q.1238.1 with the following qualifications: The Application Context Name parameter of the TC-BEGIN service shall correspond to one of the trafficFlowControlAC context. The User Information parameter of the TC-BEGIN service shall contain an EXTERNAL ASN.1 Type with the direct-reference field, if present, set to id-as-tfcBindingAS and the
108
value to be encoded shall be of the type identified in the abstract syntax definition (see Recommendation Q.1238.4). The use of the parameters of the TC-CONTINUE service is as defined in Recommendation Q.1238.1 with the following qualifications: The User Information parameter of the first TC-CONTINUE service shall contain an EXTERNAL ASN.1 Type with the direct-reference field, if present, set to id-astfcBindingAS and the value to be encoded shall be of the type identified in the abstract syntax definition (See Recommendation Q.1238.4). In subsequent TC-CONTINUE services the contents of the User Information field is network operator specific.
The use of the parameters of the TC-U-ABORT service is as defined in Recommendation Q.1238.1 with the following qualifications: The Application-Context-Name parameter of the TC-U-ABORT service shall be used as specified in ITU-T Recommendation Q.771. When the SCF refuses a dialogue because the application-context-name it receives is not supported, the value of the application-contextname it returns is selected as follows: if the value has the same root as the trafficFlowControlAC, the trafficFlowControlAC is used; otherwise the received value is returned.
The use of the parameters of the TC-END service is as defined in Recommendation Q.1238.1. 13.4 Component Handling
13.4.1.1 Procedures for INAP Operations The INAP ASEs are users of the TC component handling services except for the TC-L-REJECT and TC-L-CANCEL services which are used by the application-process. Receipt of a TC-L-REJECT-Ind leads the application-process to abandon the dialogue (i.e. it issues a TC-U-ABORT-Request primitive). The TC-U-CANCEL service is never used. 13.4.1.2 Mapping to TC Component Parameters The SCF-SCF IN ASE services are mapped onto the TC component handling services. The mapping of operations and errors onto TC services is defined in Recommendation Q.1238.1 with the following qualification: The timeout parameter of the TC-INVOKE-Req primitives is set according to Table 2/Q.1238.6.
___________
109

T Rec Q.1238.6 2000

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

T Rec Q.1238.6 2000

Uploaded by

Copyright:

Available Formats

INTERNATIONAL TELECOMMUNICATION UNION

SERIES Q: SWITCHING AND SIGNALLING INTELLIGENT NETWORK

Interface recommendation for intelligent network capability set 3: SCF-SCF interface

CAUTION ! PREPUBLISHED RECOMMENDATION

Recommendation Q.1238.6 (06/00) Prepublished version

Recommendation Q.1238.6 (06/00) Prepublished version

Recommendation Q.1238.6 (06/00) Prepublished version

Recommendation Q.1238.6 (06/00) Prepublished version

Recommendation Q.1238.6 (06/00) Prepublished version

Recommendation Q.1238.6 (06/00) Prepublished version

Recommendation Q.1238.6 (06/00) Prepublished version

Recommendation Q.1238.6 (06/00) Prepublished version

Recommendation Q.1238.6 (06/00) Prepublished version

Functional routine Service data object directory IN network-wide resource data

FIGURE 1/Q.1238.6 SCF FE Model

Recommendation Q.1238.6 (06/00) Prepublished version

FIGURE 2/Q1238.6 SCF FSM model

Recommendation Q.1238.6 (06/00) Prepublished version

State transition model for TFC Initiator related states

(e1) Bind (e6) Unbind

2. Wait for TFC

(e2) TFC (e3) delimiter 3. Wait for BindResult

1. Idle (E4) TFCBindError (e6) Unbind

4. Active (e6) Unbind

FIGURE 3/Q.1238.6 State model for TFC initiator

Recommendation Q.1238.6 (06/00) Prepublished version

State 3: "Wait for BindResult"

The TFC Responder finite state model (FSM) is depicted in Figure 4.

1. Idle (e3) BindError (E5) TFCUnbind

3. Active (E5) TFCUnbind

FIGURE 4/Q.1238.6 State model for TFC responder

Recommendation Q.1238.6 (06/00) Prepublished version

Recommendation Q.1238.6 (06/00) Prepublished version

State 2: Preparing Handling Information Request

Recommendation Q.1238.6 (06/00) Prepublished version

Recommendation Q.1238.6 (06/00) Prepublished version

Recommendation Q.1238.6 (06/00) Prepublished version

(e2) Send Handling Information Request

3. Waiting for Bind Result

(E29) Unbind Received

5. Preparing Additional Information

(e12) End Assist

Recommendation Q.1238.6 (06/00) Prepublished version

State 2: Processing SCF Bind

Recommendation Q.1238.6 (06/00) Prepublished version

Recommendation Q.1238.6 (06/00) Prepublished version

Recommendation Q.1238.6 (06/00) Prepublished version

(e32) STSI send request (E33) STSI received

FIGURE 6/Q.1238.6 SCSM-Sup (Supporting SCF FSM)

SCF state transition models for chaining initiation (SCSM-ChI)

Recommendation Q.1238.6 (06/00) Prepublished version

(e1) SCFBind 2. Prepare Chained HIreq

(e3) Chained HIReq

3. Wait for bind result

4. SCF Bound (E5) SCFBind Successful

FIGURE 7/Q.1238.6 SCSM-ChI (Chaining Initiator SCF FSM)

Recommendation Q.1238.6 (06/00) Prepublished version

State 3: "Wait for Bind Result"

Recommendation Q.1238.6 (06/00) Prepublished version

SCF state transition models for chaining termination (SCSM-ChT)

(e2) SCFBind error (E3) Chained HIReq

FIGURE 8/Q.1238.6 SCSM-ChT (Chaining Terminator SCF FSM)

Recommendation Q.1238.6 (06/00) Prepublished version