11 Detailed operation procedures for circuit switched call control

29.0783GPPCAMEL Application Part (CAP) specificationCustomised Applications for Mobile network Enhanced Logic (CAMEL) Phase XRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

NOTE: The detailed operation procedures in the present clause which cross reference the gsmSCF FSMs for the pre‑ and postconditions are for information only.

NOTE: Where a parameter for a circuit switched call control Operation is marked OPTIONAL in ASN.1, the reader is referred to the conditions for presence for this parameter, specified in the respective Information Flow in 3GPP TS 23.078 [7].

11.1 ActivityTest procedure

11.1.1 General description

The gsmSCF uses this operation to check for the continued existence of a relationship between the gsmSCF and the gsmSSF, between the gsmSCF and the gsmSRF or between the gsmSCF and the assist gsmSSF. If the relationship is still in existence, then the receiving entity will respond If the ActivityTest operation timer expires, then the gsmSCF will assume that the receiving entity has failed in some way and will take appropriate action.

11.1.1.1 Parameters

None.

11.1.2 Responding entity (gsmSSF, gsmSRF or assist gsmSSF)

11.1.2.1 Normal procedure

gsmSSF preconditions:

(1) A relationship exists between the gsmSCF and the gsmSSF.

(2) The gsmSSME FSM is in the state "Idle Management" or in the state "Non-call Associated Treatment".

gsmSRF or assist gsmSSF preconditions:

(1) A relationship exists between the gsmSCF and the gsmSRF or assist gsmSSF.

(2) The gsmSSME FSM is in the state "Idle Management".

gsmSSF postconditions:

(1) The gsmSSME FSM stays in, or transits to the state "Non-call Associated Treatment".

(2) If the TC Dialogue ID is active and there is a gsmSSF using the dialogue, then the gsmSSME FSM shall send a Return Result "ActivityTest" to the gsmSCF. If there are no other management activities (e.g. Call Gapping), then the gsmSSME FSM shall transit to the state "Idle Management". Otherwise, the gsmSSME FSM remains in the state "Non-call Associated Treatment".

If the TC Dialogue ID is not active, then the TC in the gsmSSF will issue a P‑Abort. The gsmSSME FSM will in that case not receive the "ActivityTest" indication and thus will not be able to reply.

gsmSRF or assist gsmSSF postconditions:

(1) The gsmSSME FSM transits to the state "Non-call Associated Treatment".

(2) If the TC Dialogue ID is active and there is a gsmSRF or assist gsmSSF using the dialogue, then the gsmSSME FSM shall send a Return Result "ActivityTest" to the gsmSCF. The gsmSSME FSM then returns to the state "Idle Management".

If the TC Dialogue ID is not active, then the TC in the gsmSRF or assist gsmSSF will issue a P-Abort. The gsmSSME FSM will in that case not receive the ActivityTest indication and thus will not be able to reply.

11.1.2.2 Error handling

Operation related error handling is not applicable, due to class 3 operation.

11.2 ApplyCharging procedure

11.2.1 General description

The gsmSCF uses this operation for interacting with the gsmSSF function: "CSE control of call duration". The ApplyChargingReport operation provides the feedback from the gsmSSF to the gsmSCF.

The charging scenarios supported by this operation are those given in 3GPP TS 22.078 [3] for "CSE control of call duration".

11.2.1.1 Parameters

– aChBillingChargingCharacteristics:
This parameter specifies a list of parameters required for "CSE control of call duration":

The list may contain the following parameters:

– timeDurationCharging:
This list contains the following parameters:

– maxCallPeriodDuration:
This parameter specifies the period of time for which a call may progress before an ApplyChargingReport shall be sent to the gsmSCF.

– releaseIfdurationExceeded:
This parameter specifies the action to be taken at the gsmSSF when the duration specified above has been reached.

– audibleIndicator:
This parameter indicates to the gsmSSF that an audible indicator may be played to the served subscriber. This audible indicator may either be a predefined sequence of tones or a sequence defined by the gsmSCF. This parameter shall consist of either tone or burstlist as described below:

– tone:
This parameter indicates that a warning tone shall be played when the pre-defined warning tone timer expires.

– burstlist:
This parameter indicates that a variable sequence of tones shall be played when the gsmSCF-defined warning tone timer expires. This parameter may consist of the following parameters:

– warningPeriod:
This parameter indicates the time, before the Max Call Period Duration timer expires when the playing of the burstlist shall start.

– burst:
This parameter indicates the number of bursts that form the burstlist.

– burstInterval:
This parameter indicates the time interval between the successive burst in the burstlist.

– toneInBurst:
This parameter indicates the number of tones to be played in each burst.

– toneDuration:
This parameter indicates the time duration that the tone shall be played for.

– toneInterval:
This parameter indicates the time interval between successive tones in a burst

– tariffSwitchInterval (for the CSE control of call duration):
This parameter indicates the time duration until the next tariff switch for the CSE control of call duration. The measurement of the elapsed tariff switch period shall start immediately after successful execution of this operation.

– partyToCharge:
This parameter indicates the party in the call.

– aChChargingAddress:
This parameter identifies the call party to which the ApplyCharging operation applies. That is the leg or srfConnection.

This parameter is a choice of one of the following parameters:

– legID:
This parameter indicates that the "CSE control of call duration" is associated to the specified leg.

– srfConnection:
This parameter indicates that the "CSE control of call duration" is associated to the Temporary Connection or to the connection to a gsmSRF.

11.2.2 Responding entity (gsmSSF)

11.2.2.1 Normal procedure

gsmSSF preconditions:

(1) A control relationship exists between the gsmSCF and the gsmSSF.

(2) The gsmSSF FSM is in one of the following states:

"Waiting_for_Instructions"; or
"Waiting_for_end_of_User_Interaction"; or
"Waiting_for_end_of_Temporary_Connection"; or
"Monitoring".

gsmSSF postconditions:

(1) No gsmSSF FSM state transition.

On receipt of this operation, the gsmSSF sets the charging data using the information elements included in the operation and acts accordingly.

If the aChChargingAddress indicates a legID, then:

The "CSE control of call duration" is associated to the specified leg. If Answer has not already been received on the incoming or outgoing connection (leg) to the Call Party, then the gsmSSF shall start monitoring for the Answer event upon receipt of the ApplyCharging operation. Upon subsequent detection of the Answer event on the outgoing connection charging is started. If the Answer event has occurred on the incoming or outgoing connection already when the ApplyCharging operation is received, then charging starts immediately.

A precautionary started DELTA measurement shall be taken into account when charging is started.

For a change in the connection configuration of the legs – on CPH – the particular point in time when the new connection configuration is established shall be taken as Answer time.

Upon release of the incoming or outgoing connection to the Call Party any indication of Answer event occurred on the incoming or outgoing connection shall be cleared, i.e. set to "Answer event not occurred".

If the aChChargingAddress indicates a srfConnection, then:

The "CSE control of call duration" is associated to the Temporary Connection or to the connection to a gsmSRF. If Answer has not already been received on the Temporary Connection, then the gsmSSF will start monitoring for the Answer event upon receipt of the ApplyCharging operation; or, if the gsmSRF is not yet connected, then the gsmSSF will start monitoring for a connection to a gsmSRF. Upon subsequent detection of the Answer event on the Temporary Connection or the subsequent connection to a gsmSRF, charging shall be started. If the Answer event has been received from a Temporary Connection already or if the gsmSRF is already connected when the ApplyCharging operation is received, then charging shall start immediately.

Upon release of the Temporary Connection any indication of Answer event receipt on the outgoing connection shall be cleared i.e. set to "Answer event not received". Upon end of the connection to a gsmSRF, any indication of the connection to the gsmSRF shall be cleared.

11.2.2.2 Error handling

"TaskRefused": In addition to the generic error handling noted below, this error shall be indicated when:

– a previously received call period duration is pending for this leg or srfConnection;

– a tariffSwitchInterval for the "CSE control of call duration" is indicated when a previously received tariffSwitchInterval for the "CSE control of call duration" is pending for the Called Party, the Temporary Connection or the connection to a gsmSRF.

Generic error handling for the operation related errors is described in clause 10 and the TC services used for reporting operation errors are described in clause 14.

11.3 ApplyChargingReport procedure

11.3.1 General description

The gsmSSF uses this operation to report charging related information to the gsmSCF as requested by the gsmSCF using the "ApplyCharging" operation.

For a change in a connection configuration of the legs – on CPH – this operation shall be sent as an indication towards the gsmSCF that the supervision of that part of the connection is finished; i.e.
(i) the gsmSCF shall settle the account using the reported duration and
(ii) the durations reported for subsequent AC/ACR cycles will not be accumulated to the reported duration.

If Answer is detected by the gsmSSF, then timing of duration shall be started as requested by the ApplyCharging operation. It shall be started independently for a connection to a Called Party, a Temporary Connection and a gsmSRF connection.

The charging report shall be generated as specified in the 3GPP TS 23.078 [7].

The tariff switch mentioned in the following subclause is the tariff switch for "CSE control of call duration" for the connection to which the ApplyChargingReport procedure applies.

11.3.1.1 Parameters

– callResult:
This parameter provides the gsmSCF with the charging related information previously requested using the ApplyCharging operation. The "CallResult" is a list and may contain the following parameters:

– timeDurationChargingResult:
This parameter is a list, and can contain the following parameters:

– timeInformation:
This parameter is a choice of the following parameters:

– timeIfNoTariffSwitch:
This parameter shall be present if no tariff switch has occurred since the reception of the first ApplyCharging operation for the connection to the Called Party, Temporary Connection or gsmSRF connection, otherwise it shall be absent.
If Answer was detected for the connection to the Called Party, the Temporary Connection or the gsmSRF connection, then the elapsed time since detection of Answer shall be reported. If answer was not detected, then it shall be set to "0".
For a change in the connection configuration of the legs – on CPH – the particular point in time when the new connection configuration is established shall be taken as Answer time.

– timeIfTariffSwitch:
This parameter shall be present if a tariff switch has occurred since the reception of the first ApplyCharging operation for the connection to the Called Party, Temporary Connection or gsmSRF connection, otherwise it shall be absent.
The parameter may contain the following information:

– timeSinceLastTariffSwitch:
If Answer was detected for the connection to the Called Party, the Temporary Connection or the gsmSRF connection, then the elapsed time since detection of Answer or the last tariff switch (whichever of these events was last detected) shall be reported. If Answer was not detected, then it shall be set to "0".
For a change in the connection configuration of the legs – on CPH – the particular point in time when the new connection configuration is established shall be taken as Answer time.

– TariffSwitchInterval (for the "CSE control of call duration"):
This parameter is present only if a tariff switch has occurred since the detection of Answer for the connection to the Called Party, the temporary connection or the gsmSRF connection in the reported call period.
The time interval between either the detection of the Answer event or the previous tariff switch (whichever of these events was last detected) and the last tariff switch is reported.
For a change in the connection configuration of the legs – on CPH – the particular point in time when the new connection configuration is established shall be taken as Answer time.

– partyToCharge:
The "partyToCharge" parameter as received in the related ApplyCharging operation or deduced from the default value. This parameter is used by the gsmSCF, to correlate the result to the request.

– aChChargingAddress:
The "aChChargingAddress" parameter as received in the related ApplyCharging operation or deduced from the default value. This parameter is used by the gsmSCF, to correlate the result to the request.

– legActive:
This parameter indicates whether the leg, the Temporary Connection or the connection to a gsmSRF is still active or has been released.

– callLegReleasedAtTcpExpiry:
This parameter indicates that the gsmSSF has released the call leg or the Temporary Connection or SRF connection

11.3.2 Invoking entity (gsmSSF)

11.3.2.1 Normal procedure

gsmSSF preconditions:

(1) A relationship exists between the gsmSSF and the gsmSCF.

(2) A charging event has been detected that was requested by the gsmSCF via an ApplyCharging operation or a Called Party, Temporary Connection or gsmSRF disconnection event has occurred.

gsmSSF postconditions:

(1) If release of the call has occurred because the allowed call duration has been reached, then:

– All armed EDPs shall be disarmed;

– ApplyChargingReport shall be sent to gsmSCF followed by any pending CallInformationReports;

– The gsmSSF FSM shall transit to the state "Idle".

(2) If release of the call has occurred but not because the allowed call duration has been reached, then:

– If there are any armed EDPs or pending reports, then the gsmSSF FSM shall remain in the same state, else;

– The gsmSSF FSM shall transit to the state "Idle".

(3) else:

– no gsmSSF FSM state transition.

11.3.2.2 Error handling

Generic error handling for the operation related errors are described in clause 10 and the TC services used for reporting operation errors are described in clause 14.

11.4 AssistRequestInstructions procedure

11.4.1 General description

This operation may be used by an assist gsmSSF or by a gsmSRF. The operation is sent to the gsmSCF when the assisting gsmSSF or gsmSRF receives an indication from an initiating gsmSSF indicating an assist procedure.

11.4.1.1 Parameters

– correlationID:
This parameter is used by the gsmSCF to associate the "AssistRequestInstructions" from the assisting gsmSSF or by a gsmSRF with the request from the initiating gsmSSF. The value of the "correlationID" may be extracted from the digits received from the initiating gsmSSF.

– iPSSPCapabilities:
Indicates which gsmSRF resources are attached, available and supported within:

– the MSC where the assisting gsmSSF resides; or

– the IP where the gsmSRF resides.

11.4.2 Invoking entity (gsmSSF/gsmSRF)

11.4.2.1 Normal procedure

assisting gsmSSF or gsmSRF preconditions:

(1) An assist indication is detected by the assisting gsmSSF or gsmSRF.

assisting gsmSSF or gsmSRF postconditions:

(1) The assisting gsmSSF FSM is in the state "Waiting_for_Instructions" or the gsmSRF FSM is in the state "Connected".

On receipt of an assist indication from the initiating gsmSSF, the assisting gsmSSF or gsmSRF shall ensure that the required resources are available to invoke an "AssistRequestInstructions" operation in the assist gsmSSF or gsmSRF and shall indicate to the initiating gsmSSF that the call is accepted. The "AssistRequestInstructions" operation is invoked by the assist gsmSSF or gsmSRF after the call, which initiated the assist indication, is accepted.

11.4.2.2 Error handling

Generic error handling for the operation related errors are described in clause 10 and the TC services which are used for reporting operation errors are described in clause 14.

11.5 CallGap procedure

11.5.1 General description

The gsmSCF uses this operation to request the gsmSSF to reduce the rate at which specific service requests are sent to the gsmSCF. This operation may be sent only within a dialogue that has been opened by the gsmSSF by an InitialDP operation.

11.5.1.1 Parameters

– gapCriteria:
This parameter identifies the criteria for a call to be subject to call gapping. It is a choice of the following parameters: "basicGapCriteria" or "compoundGapCrteria":

– basicGapCriteria:
This parameter consists of the following parameters:

– calledAddressValue:
This parameter indicates that call gapping shall be applied when the leading digits of the dialled number of a call attempt match those specified in "calledAddressValue". The called address is the one received from the current call control.

– gapOnService:
This parameter indicates that call gapping shall be applied when the Service Key of a Service initiation attempt matches the Service Key specified in "gapOnService".

– calledAddressAndService:
This parameter indicates that call gapping shall be applied when the Service Key of a Service initiation attempt matches the Service Key defined in "calledAddressAndService" and the leading digits of the dialled number of a that call attempt match the dialled digits defined in "calledAddressAndService". The called address is the one received from the current call control.

– callingAddressAndService:
This parameter indicates that call gapping shall be applied when the Service Key of a Service initiation attempt matches the Service Key defined in "callingAddressAndService" and the leading digits of the calling party number of that call attempt match the calling party number defined in "callingAddressAndService". In the case of call forwarding the calling address to be gapped shall the redirecting number which is placed in the Initial DP operation.

– compoundGapCriteria:
This parameter consists of the folllowing parameters:

– basicGapCriteria:
This parameter is as described above.

– scfID:
This parameter identifies a gsmSCF. The scfID shall convey the necessary gsmSCF address information (e.g. Global Title) in the network to the requesting gsmSSF. Refer to ITU-T Recommendation Q.713 [42] "calling party address" parameter. The network operator shall decide about the actual mapping of this parameter on the used signalling system.
This parameter indicates the address of the gsmSCF which requests the call gapping.
If scfID is used in an operation that crosses an inter-network boundary, then its encoding must be understood in both networks and if the length is extended beyond 10 bytes this must be supported by both entities; this requires bilateral agreement on the encoding. If this parameter is not available, then the call gapping is not dedicated to a specific gsmSCF.
This parameter is restricted to include a fixed GT address string.

NOTE: In the case where the GT addresses more than one SCP (e.g. a mated pair), then if one of these physical SCPs enters an overload conditions and issues a CallGap instruction, then the CallGap is applied to all these SCPs.

– gapIndicators:
This parameter indicates the call gapping characteristics.

– duration:
This parameter specifies the total time interval during which call gapping for the specified gap criteria will be active.

A duration of 0 indicates that call gapping shall be removed.

A duration of ‑2 indicates a network specific duration.

Other values indicate duration in seconds. A duration of -1 shall not be used.

– gapInterval:
This parameter specifies the minimum time between calls being allowed through.

An interval of 0 indicates that calls meeting the gap criteria shall not be rejected.

An interval of ‑1 indicates that all calls meeting the gap criteria shall be rejected.

Other values indicate the gap interval in milliseconds.

– controlType:
This parameter indicates the reason for activating call gapping.

The "controlType" value "sCPOverloaded" indicates that an automatic congestion detection and control mechanism in the SCP has detected a congestion situation.

The "controlType" value "manuallyInitiated" indicates that the service, the network managent centre or service management centre, or both has detected a congestion situation, or any other situation that requires manually initiated controls.

NOTE: The controlType "manuallyInitiated" shall have priority over "sCPOverloaded" call gap. Also non-CAMEL controlled traffic control mechanism may apply to an exchange with the gsmSSF functionality. The non-CAMEL controlled traffic control may also have some influence to the CAMEL call. It is therefore recommended to take measures to co-ordinate several traffic control mechanisms. The non-CAMEL controlled traffic control and co-ordination of several traffic control mechanisms are out of the scope of CAP.

– gapTreatment:
This parameter indicates how calls that were stopped by the call gapping mechanism shall be treated.

– informationToSend:

This parameter indicates an announcement or a tone to be sent to the calling party. At the end of information sending, the call shall be released.

– inbandInfo:
This parameter specifies the inband information to be sent.

– messageID:
This parameter indicates the message(s) to be sent, it can be one of the following:

– elementaryMessageID:
This parameter indicates a single announcement.

– duration:
This parameter indicates the maximum time duration in seconds that the message shall be played or repeated. A value of "0" indicates endless repetition.

– tone:
This parameter specifies a tone to be sent to the end‑user.

– toneID:
This parameter indicates the tone to be sent.

– duration:
This parameter indicates the time duration in seconds of the tone. A value of "0" indicates infinite duration.

– releaseCause:
If the call shall be released, then this parameter indicates a specific cause value to be sent in the release message. See ETSI EN 300 356‑1 [23].

11.5.2 Responding entity (gsmSSF)

11.5.2.1 Normal procedure

gsmSSF preconditions:

(1) Call gapping for gapCriteria is not active; or
Call gapping for gapCriteria is active.

(2) The gsmSSF FSM is in any state except "Idle" and except "Wait_For_Request".

gsmSSF postconditions:

(1) The gsmSSME FSM is in the state "Active".

(2) Call gapping for gapCriteria is activated; or
Call gapping for gapCriteria is renewed; or
Call gapping for gapCriteria is removed.

(3) No gsmSSF FSM state transition.

If there is not already an existing gsmSSME FSM for the gap criteria and gsmSCFAddress provided, then a new gsmSSME FSM shall be created. If no gsmSCFAddress is provided, then this refers in general to the gsmSSME FSM without a gsmSCFAddress. This gsmSSME FSM enters the state "Active" and initialises call gapping for the specified CAMEL calls. The parameters "gapIndicators", "controlType", "gapTreatment" and "gsmSCFAddress" for the indicated gap criteria shall be set as provided by the "CallGap" operation.

In the case that both "manuallyInitiated" and "sCPOverloaded" call gapping are active for the same "gapCriteria", the manuallyInitiated call gapping shall prevail over the "sCPOverloaded" call gapping. More specifically, the following rules shall be applied in the gsmSSF to manage the priority of different control Types associated with the same "gapCriteria":

– If a gsmSSME FSM already exists for the "gapCriteria" and the gsmSCFAddress provided, then:

(1) If the (new) "controlType" equals an existing "controlType", then the new parameters (i.e.,"gapIndicators" and "gapTreatment") shall overwrite the existing parameters.

(2) If the (new) "controlType" is different from the existing "controlType", then the new parameters (i.e., "controlType", "gapIndicators" and "gapTreatment") shall be appended to the appropriate gsmSSME FSM (in addition to the existing parameters). The gsmSSME FSM remains in the state "Active".

If the gsmSSF meets a TDP, then it shall check if call gapping was initiated for the same gsmSCF as the one currently assigned to this TDP or if call gapping exists with no provided gsmSCFAddress. If neither call gapping was initiated nor exists, then an "InitialDP" operation may be sent.

The gsmSSF shall check if call gapping was initiated either for the "serviceKey" or for the "calledAddressValue" assigned to this TDP. If this is not the case, then an "InitialDP" operation may be sent. If call gapping was initiated for "calledAddressAndService" or "callingAddressAndService" and the "serviceKey" matches, then a check on the "calledAddressValue" and "callingAddressValue" for active call gapping shall be performed. Otherwise, an "InitialDP" operation may be sent.

If a call to a controlled number matches one "gapCriteria" only, then the corresponding control is applied. If both "manuallyInitiated" call gapping and "sCPOverload" call gapping controls are active, then only the "manuallyInitiated" call gapping shall be applied.

If a call matches several active "basicGapCriteria", then the treatment as specified in the CallGap associated with the gapCriteria with the highest priority shall be applied, with the priority being from high to low:

1. calledAddressAndService or calledAddressValue;

2. callingAddressAndService;

3. gapOnService.

For example, a call with called number 123456 and ServiceKey = NP matches two CallGaps, one with gapCriteria "CalledAdressValue=123" and another one with gapCriteria "gapOnService=NP". Then the call shall be subject to the control of the service request CallGap with "CalledAdressValue=123".

In the case that multiple call gapping procedures are active with the same gap criteria, the "manuallyInitiated" call gapping shall prevail over the "sCPOverloaded" call gapping.

If a call to a controlled called number or from a controlled calling number matches several active "basicGapCriteria " of the same type (in this context "calledAddressAndService" and "calledAddressValue" are seen as one type), then only the "gapCriteria" associated with the longest called party number shall be used, and the corresponding control shall be applied. For example, the codes 1234 and 12345 are under control. Then the call with 123456 is subject to the control on 12345.

If a call to a controlled called number matches calledAddressAndService and calledAddressValue with the same number length, then calledAddressAndService has priority. Furthermore, if both "manuallyInitiated" and "sCPOverloaded" "controlTypes" are active for this "gapCriteria", then the "manuallyInitiated" control shall be applied.

If call gapping is performed on a call for a particular service and triggering of this service is allowed, then no other gap criteria shall be applied this service instance.

Active GapCriteria with assigned scfID shall have higher priority than the other GapCriteria. In the case that an entry with scfID matching the current call exists, all other criteria without scfID shall not be evaluated.

The matching entries with scfID shall be evaluated in accordance with the priority rules for the basic criteria listed above.

If call gapping shall be applied and there is no gap interval active, then an "InitialDP" operation may be sent including the "cGEncountered" parameter in accordance with the specified controlType. A new gap interval shall be initiated as indicated by "gapInterval".

If a gap interval is active, then no "InitialDP" operation shall be sent and the call shall be treated as defined by Default Call Handling of the valid CSI and "gapTreatment".

If the indicated duration equals "0", then the call gap process shall be stopped.

If call gapping proceeds, then the gsmSSME FSM remains in the state "Active". Otherwise, the gsmSSME FSM transits to the state "idle".

11.5.2.2 Error handling

Operation related error handling is not applicable, due to class 4 operation.

11.6 CallInformationReport procedure

11.6.1 General description

The gsmSSF uses this operation to send specific call information for a single call party to the gsmSCF as requested by the gsmSCF in previous "CallInformationRequest" operation. The report shall be sent at the end of a call party connection which is indicated by one of the events specified below.

11.6.1.1 Parameters

– requestedInformationList:
The gsmSSF sends the appropriate types and values to the gsmSCF in accordance with the requested information.

– legID:
This parameter indicates the party in the call for which the information has been collected.

11.6.2 Invoking entity (gsmSSF)

11.6.2.1 Normal procedure

gsmSSF preconditions:

(1) The indicated or default party is released from the call or call setup towards the indicated or default party is terminated prematurely.

(2) Requested call information has been collected.

(3) "CallInformationReport" is pending due to a previously received "CallInformationRequest" operation.

(4) A control or a monitor relationship exists between the gsmSCF and the gsmSSF.

gsmSSF postconditions:

(1) If there are no armed EDPs or pending reports, then the gsmSSF FSM shall transit to the state "Idle"; otherwise, the gsmSSF FSM shall remain in the same state.

If the gsmSSF FSM executes a state transition caused by one of the following events:

– release for the indicated or default leg;

– abandon for the indicated or default leg;

– Called party Busy or Not Reachable for the indicated or default leg;

– gsmSSF No_Answer timer expiration for the indicated or default leg;

– route select failure for the indicated or default leg;

– release of call initiated by the gsmSCF (ReleaseCall),

and "CallInformationRequest" is pending for the indicated or default leg, then one "CallInformationReport" operation shall be sent to the gsmSCF, containing all information requested for that leg.

If a "CallInformationReport" has been sent to the gsmSCF, then no "CallInformationReport" is pending on that leg, i.e. if a further "CallInformationReport" on that leg is required, for example in the case of follow‑on call, then this has to be explicitly requested by the gsmSCF.

11.6.2.2 Error handling

Operation related error handling is not applicable, due to class 4 operation.

11.7 CallInformationRequest procedure

11.7.1 General description

The gsmSCF uses this operation to request the gsmSSF to record specific information about a single call party and report it to the gsmSCF using the "CallInformationReport" operation.

11.7.1.1 Parameters

– requestedInformationTypeList:
This parameter specifies a list of specific items of information which is requested. The list may contain the following parameters:

– callAttemptElapsedTime:
This parameter indicates the duration between the end of CAP processing of operations initiating call setup ("Connect","Continue" or "ContinueWithArgument") and the received answer indication from the called party. If the callAttemptElapsedTime is requested for the calling party, then a value of "0" shall be reported by the gsmSSF.

In the case of unsuccessful call setup, the network event indicating the unsuccessful call setup stops the measurement of "callAttemptElapsedTime".

– callStopTime:
This parameter indicates the time stamp when the connection is released.

– callConnectedElapsedTime:
This parameter indicates the duration between the received answer indication from the called party and the release of that connection. For the calling party it indicates the duration between the sending of InitialDP and the release of that party.

– releaseCause:
This parameter indicates the release cause for the call.

– legID:
This parameter indicates the party in the call for which the information shall be collected.

11.7.2 Responding entity (gsmSSF)

11.7.2.1 Normal procedure

gsmSSF preconditions:

(1) A control relationship exists between gsmSSF and gsmSCF.

(2) The gsmSSF FSM is in the state "Waiting_for_Instructions".

gsmSSF postconditions:

(1) Requested call information is retained by the gsmSSF.

(2) No gsmSSF FSM state transition.

The gsmSSF allocates a record for the indicated or default party and stores the requested information if already available and prepares the recording of information items, that will become available later like for example "callStopTimeValue".

Call information may be requested for any call party (identified by a legID).

11.7.2.2 Error handling

Generic error handling for the operation related errors are described in clause 10 and the TC services which are used for reporting operation errors are described in clause 14.

11.8 Cancel procedure

11.8.1 General description

The gsmSCF uses this operation to request the gsmSRF or gsmSSF to cancel a correlated previous operation.

The Cancel operation may be used for the following purposes:

(1) Cancel may be sent to the gsmSRF to cancel the "PlayAnnouncement" or the "PromptAndCollectUserInformation" operation. The cancellation of the operation is indicated via a respective error indication, "Canceled", to the invoking entity of the cancelled "PlayAnnouncement" or "PromptAndCollectUserInformation" operation.

(2) Cancel may be sent to the gsmSSF to disarm all armed EDPs and cancel all pending reports. This enables the gsmSSF FSM to transit to the state "Idle". If Cancel is used for this purpose, then the Cancel operation does not specify any specific operation to be cancelled.

11.8.1.1 Parameters

– invokeID:
This parameter specifies which operation invocation shall be cancelled, i.e. PromptAndCollectUserInformation or PlayAnnouncement.

– callSegmentID:
This parameter specifies the Call Segment to which the cancellation of the user interaction operation shall apply.

– allRequests:
This parameter indicates that all armed EDP shall be disarmed and that any pending "ApplyChargingReport" and "CallInformationReport" shall be cancelled.

11.8.2 Responding entity (gsmSRF)

In the case of Cancel(invokeID), the gsmSRF is the responding entity. In this case, the Cancel operation may also contain the callSegmentID parameter.

11.8.2.1 Normal procedure

gsmSRF preconditions:

(1) A PlayAnnouncement or PromptAndCollectUserInformation operation has been received and the gsmSRF FSM is in the state "User Interaction".

gsmSRF postconditions:

(1) The execution of the PlayAnnouncement or PromptAndCollectUserInformation operation has been aborted and the gsmSRF remains in the state "User Interaction".

11.8.2.2 Error handling

Generic error handling for the operation related errors are described in clause 10 and the TC services which are used for reporting operation errors are described in clause 14.

11.8.3 Responding entity (gsmSSF)

In the case of Cancel(allRequests), the gsmSSF is the responding entity.

11.8.3.1 Normal procedure

gsmSSF preconditions:

(1) The gsmSSF FSM is in the state "Waiting_for_Instructions" or in the state "Monitoring".

gsmSSF postconditions:

(1) All armed EDPs are disarmed and all pending reports are cancelled.

(2) If the gsmSSF FSM was in the state "Monitoring", then it shall transit to the state "Idle"; or
If the gsmSSF FSM was in the state "Waiting_for_Instructions", then it shall remain in that state.
A subsequent call‑processing operation will result in a gsmSSF FSM state transition to the state "Idle". If the call is in the active state, then the gsmSSF shall treat it autonomously as a normal (non‑CAMEL) call.

11.8.3.2 Error handling

Sending of return error on cancel is not applicable in the cancel "allRequests" case. Generic error handling for the operation related errors are described in clause 10 and the TC services which are used for reporting operation errors are described in clause 14.

11.8A CollectInformation Procedure

11.8A.1 General description

The gsmSCF uses this operation to request the gsmSSF to perform the call processing actions to collect additional digits from the calling party and report it to the gsmSCF. The CollectInformation operation may be used for TO calls in the gsmSSF. The gsmSCF shall arm the Collected_Info DP as EDP-R before sending this operation.

11.8A.1.1 Parameters

None

Note: An operation argument is supported for future extensibility.

11.8A.2 Responding entity (gsmSSF)

11.8A.2.1 Normal procedure

gsmSSF preconditions:

(1) A control relationship exists between the gsmSCF and the gsmSSF;

(2) Basic call processing has been suspended at CollectedInfo DP or AnalysedInfo DP;

(3) CollectedInfo DP has been armed as EDP-R;

(4) The gsmSSF FSM is in the state "Waiting_for_Instructions".

gsmSSF postconditions:

(1) The gsmSSF performs the call processing actions to collect additional dialled digits from the calling party;

(2) The gsmSSF FSM transits to the state "Monitoring";

(3) In the O-BCSM, call processing resumes at PIC Collect_Info or PIC Analyze_Information.

11.8A.2.2 Error handling

Generic error handling for the operation related errors are described in clause 10 and the TC services which are used for reporting operation errors are described in clause 14.

11.9 Connect procedure

11.9.1 General description

The gsmSCF uses this operation to request the gsmSSF to perform the call processing actions to route a call to a specific destination.

In general all parameters which are provided in a Connect operation to the gsmSSF shall replace the corresponding signalling parameter in the CCF in O-BCSM, in accordance with ETSI ES 201 296 [21] and shall be used for subsequent call processing. The CCF of the T-BCSM shall send corresponding signalling parameters to new call leg without using them in subsequent call processing. Parameters which are not provided by the Connect operation shall retain their value (if already assigned) in the CCF for subsequent call processing.

11.9.1.1 Parameters

– destinationRoutingAddress:
This parameter contains the called party numbers towards which the call shall be routed.

– alertingPattern:
This parameter indicates the type of alerting to be applied. It is defined in 3GPP TS 29.002 [11].

– serviceInteractionIndicatorsTwo:
This parameter contains indicators to resolve interactions between CAMEL based services and network based services.

– callingPartysCategory:
This parameter indicates the type of calling party (e.g., operator, pay phone, ordinary subscriber).

– originalCalledPartyID:
If the call is forwarded by the gsmSCF, then this parameter carries the dialled digits.

– redirectingPartyID:
This parameter indicates the last directory number the call was redirected from.

– redirectionInformation:
This parameter contains forwarding related information, such as redirecting counter.

– genericNumbers:
This parameter allows the gsmSCF to set the Generic Number parameter used in the network. It is used for transfer of Additional Calling Party Number.

– suppressionOfAnnouncement:
This parameter indicates that announcements and tones which are played in the exchange at non‑successful call set‑up attempts shall be suppressed.

– oCSIApplicable:
This parameter indicates to the GMSC/gsmSSF or VMSC/gsmSSF that the Originating CAMEL Subscription Information, if present, shall be applied on the outgoing call leg created with the Connect operation. For the use of this parameter see 3GPP TS 23.078 [7].

– Carrier:
This parameter indicates carrier information. It consists of the carrier selection field followed by the Carrier ID information to be used by gsmSSF for routeing a call to a carrier.

It contains the following embedded parameters:

– carrierSelectionField:
This parameter indicates how the selected carrier is provided (e.g. pre-subscribed).

– carrierID:
This parameter indicates the carrier to use for the call. It contains the digits of the carrier identification code.

– naOliInfo:
This parameter contains originating line information which identifies the charged party number type to the carrier.

– ChargeNumber:
This parameter contains the number that identifies the entity to be charged for the call. It identifies the chargeable number for the usage of a carrier (applicable on a call sent into a North American long distance carrier). For a definition of this parameter refer to ANSI T1.113-1995 [92].

– cug-Interlock:
This parameter uniquely identifies a CUG within a network.

– cug-OutgoingAccess:
This parameter indicates if the calling user has subscribed to the outgoing access inter-CUG accessibility subscription option.

– bor-InterrogationRequested:
This parameter indicates that Basic Optimal Routeing is requested for the call.

– legToBeConnected:
This parameter indicates the leg to be connected.

– suppress-N-CSI:
This parameter indicates that N-CSI shall be suppressed

11.9.2 Responding entity (gsmSSF)

11.9.2.1 Normal procedure

gsmSSF preconditions:

(1) A control relationship exists between the gsmSSF and the gsmSCF.

(2) Basic call processing has been suspended at a DP.

(3) The gsmSSF FSM is in the state "Waiting_for_Instructions".

gsmSSF postconditions:

(1) The gsmSSF performs the call processing actions to route the call to the specified destination.

(2) In the O‑BCSM, call processing resumes at PIC Analyze_Information.

On receipt of this operation, the gsmSSF performs the following actions:

– If no EDPs have been armed and neither a CallInformationReport nor an ApplyChargingReport has been requested, then the gsmSSF FSM transits to the state "Idle". Otherwise, the gsmSSF FSM transits to the state "Monitoring".

The gsmSSF shall not perform any implicit arming or disarming of DPs.

Statistic counter(s) are not affected.

11.9.2.2 Error handling

Generic error handling for the operation related errors are described in clause 10 and the TC services which are used for reporting operation errors are described in clause 14.

11.10 ConnectToResource procedure

11.10.1 General description

The gsmSCF uses this operation to connect a call segment from the gsmSSF to a specialized resource. After successful connection to the gsmSRF, the interaction with the parties in the call segment can take place. The gsmSSF relays all operations for the gsmSRF and all responses from the gsmSRF.

11.10.1.1 Parameters

– resourceAddress:
This parameter identifies the physical location of the gsmSRF. It may be one of the following parameters.

– iPRoutingAddress:
This parameter indicates the routeing address to set up a connection towards the gsmSRF.

– none:
This parameter indicates that the call segment shall be connected to a predefined gsmSRF.

– serviceInteractionIndicatorsTwo:
This parameter contains an indicator that is used for the control of the through connection to the Calling Party.

NOTE The call segment to which the ConnectToResource applies does not have to contain a leg to the calling party.

The assisting gsmSSF shall always assume that Bothway Throughconnection is required, and hence will ignore this parameter if received.

– callSegmentId:
This parameter indicates the call segment to which the Connect To Resource procedure applies.

11.10.2 Responding entity (gsmSSF)

11.10.2.1 Normal procedure

gsmSSF preconditions:

(1) A control relationship exists between the gsmSCF and the gsmSSF.

(2) The gsmSSF FSM is in the state "Waiting_for_Instructions".

gsmSSF postconditions:

(1) The call segment is connected to the gsmSRF.

(2) A control relationship between the gsmSCF and the gsmSRF is established.

(3) The gsmSSF FSM transits to the state "Waiting_for_end_of_User_Interaction".

NOTE: The successful connection to the gsmSRF causes a gsmSRF FSM state transition from the state "Idle" to the state "Connected".

11.10.2.2 Error handling

Generic error handling for the operation related errors are described in clause 10 and the TC services which are used for reporting operation errors are described in clause 14.

11.11 Continue procedure

11.11.1 General description

The gsmSCF uses this operation to request the gsmSSF to proceed with call processing at the DP at which it previously suspended call processing to await gsmSCF instructions. The gsmSSF continues call processing without substituting new data from the gsmSCF.

11.11.1.1 Parameters

None.

11.11.2 Responding entity (gsmSSF)

11.11.2.1 Normal procedure

gsmSSF preconditions:

(1) A control relationship exists between the gsmSSF and the gsmSCF.

(2) Basic call processing has been suspended at any DP.

(3) The gsmSSF FSM is in the state "Waiting_for_Instructions".

gsmSSF postconditions:

(1) BCSM: If the Call Segment has received all the required resumptions then basic call processing continues.

(2) The gsmSSF FSM remains in the same state unless all resumptions have been received.

If all resumptions have been received, then:

– If there are armed EDPs or pending reports and no user interaction is ongoing, then the gsmSSF FSM transits to the state "Monitoring"; or

– If there are no armed EDPs neither pending reports, then the gsmSSF FSM transits to the state "Idle".

11.11.2.2 Error handling

Operation related error handling is not applicable, due to class 4 operation.

11.12 ContinueWithArgument Procedure

11.12.1 General description

The gsmSCF uses this operation to request the gsmSSF to proceed with call processing at the DP at which it previously suspended call processing to await gsmSCF instructions. It is also used to provide additional service related information to a User (Called Party or Calling Party) whilst the call processing proceeds.

In general all parameters which are provided in a ContinueWithArgument operation to the gsmSSF shall replace the corresponding signalling parameter in the CCF, in accordance with ETSI ES 201 296 [21], and shall be used for subsequent call processing. Parameters which are not provided by the ContinueWithArgument operation shall retain their value (if already assigned) in the CCF for subsequent call processing.

11.12.1.1 Parameters

– legOrCallSegment:
This parameter indicates the leg or Call Segment to which the ContinueWithArgument operation shall apply.

– alertingPattern:
This parameter indicates the type of alerting to be applied. It is defined in 3GPP TS 29.002 [11].

– serviceInteractionIndicatorsTwo:
This parameter contains indicators that are used to resolve interactions between CAMEL based services and network based services.

– callingPartysCategory:
This parameter indicates the type of calling party (e.g., operator, pay phone, ordinary subscriber).

– genericNumbers:
This parameter allows the gsmSCF to set the Generic Number parameter used in the network. It is used for transfer of Additional Calling Party Number.

– suppressionOfAnnouncement:
This parameter indicates that announcements and tones which are played in the exchange at non‑successful call set‑up attempts shall be suppressed.

– carrier:
This parameter indicates carrier information. It consists of the carrier selection field followed by the Carrier ID information to be used by gsmSSF for routeing a call to a carrier.

It contains the following embedded parameter:

– carrierSelectionField:
This parameter indicates how the selected carrier is provided (e.g. pre-subscribed).

– carrierID:
This parameter indicates the carrier to use for the call. It contains the digits of the carrier identification code.

– naOliInfo:
This parameter contains originating line information which identifies the charged party number type to the carrier.

– chargeNumber:
This parameter contains the number that identifies the entity to be charged for the call. It identifies the chargeable number for the usage of a carrier (applicable on a call sent into a North American long distance carrier). For a definition of this parameter refer to ANSI T1.113-1995 [92].

– cug-Interlock:
This parameter uniquely identifies a CUG within a network.

– cug-OutgoingAccess:
This parameter indicates if the calling user has subscribed to the outgoing access inter-CUG accessibility subscription option.

– bor-InterrogationRequested:
This parameter indicates that Basic Optimal Routeing is requested for the call.

– suppress-O-CSI:
This parameter indicates that O-CSI shall be suppressed for the forwarding leg or deflecting leg.

– suppress-D-CSI:
This parameter indicates that D-CSI shall be suppressed for the leg.

– suppress-N-CSI:
This parameter indicates that N-CSI shall be suppressed for the leg or trunk originated call.

– suppressOutgoingCallBarring:
This parameter indicates that outgoing call barrings shall be suppressed for the leg.

11.12.2 Responding entity (gsmSSF)

11.12.2.1 Normal procedure

gsmSSF preconditions:

(1) A control relationship exists between the gsmSSF and the gsmSCF.

(2) Basic call processing has been suspended at a DP.

(3) The gsmSSF FSM is in the state "Waiting_for_Instructions".

gsmSSF postconditions:

(1) BCSM: If the Call Segment has received all the required resumptions then basic call processing continues with modified information,

(2) The gsmSSF FSM remains in the same state unless all resumptions have been received.

If all resumptions have been received, then:

– If there are armed EDPs or pending reports and no user interaction is ongoing, then the gsmSSF FSM transits to the state "Monitoring"; or

– If there are no armed EDPs neither pending reports, then the gsmSSF FSM transits to the state "Idle".

11.12.2.2 Error handling

Generic error handling for the operation related errors are described in clause 10 and the TC services which are used for reporting operation errors are described in clause 14.

11.13 DisconnectForwardConnection procedure

11.13.1 General Description

The gsmSCF uses this operation for the following two purposes:

(1) To clear a connection to a gsmSRF:

The operation is used to explicitly disconnect a connection to a resource (gsmSRF) established previously with a "ConnectToResource" or an "EstablishTemporaryConnection" operation. It is used for a forward disconnection from the gsmSSF.
An alternative solution is the backward disconnect from the gsmSRF, controlled by the "DisconnectFromIPForbidden" parameter in the "PlayAnnouncement" and "PromptAndCollectUserInformation" operations.

(2) To clear a connection to an assisting gsmSSF:

The operation is sent to the non‑assisting gsmSSF of a pair of gsmSSFs involved in an assist procedure. It is used to disconnect the temporary connection between the initiating gsmSSF and the assisting gsmSSF and the connection between the assisting gsmSSF and its associated gsmSRF.

The DisconnectForwardConnection operation shall not be used when the CallSegmentID is required.

11.13.1.1 Parameters

None.

11.13.2 Responding entity (gsmSSF)

11.13.2.1 Normal procedure

gsmSSF preconditions:

(1) The basic call processing has been suspended at a DP. The gsmSSF FSM in the initiating gsmSSF is in the state "Waiting_for_end_of_User_Interaction" or in the state "Waiting_for_end_of_Temporary_Connection".

gsmSSF postconditions:

(1) The connection to the gsmSRF or assisting gsmSSF is released.

(2) The gsmSSF FSM is in the state "Waiting_for_Instructions".

The receipt of "DisconnectForwardConnection" results in a disconnection of the assisting gsmSSF or the PE containing the gsmSRF from the call. It does not result in a release of the connection between the gsmSSF and the end-user.

On receipt of this operation, the gsmSSF shall perform the following actions:

– The initiating gsmSSF releases the connection to the assisting gsmSSF or the gsmSRF.

– The gsmSSF FSM transits to the state "Waiting_for_Instructions".

NOTE: The successful disconnection to the gsmSRF causes a gsmSRF FSM state transition to the state "Idle". A current order (e.g. "PlayAnnouncement" or "PromptAndCollectUserInformation") is cancelled and any queued order (e.g. "PlayAnnouncement" or "PromptAndCollectUserInformation") is discarded.

11.13.2.2 Error handling

Generic error handling for the operation related errors are described in clause 10 and the TC services which are used for reporting operation errors are described in clause 14.

11.14 DisconnectForwardConnectionWithArgument procedure

11.14.1 General Description

The gsmSCF uses this operation to disconnect a connection to a resource (gsmSRF) established previously with a "ConnectToResource" or an "EstablishTemporaryConnection" operation.

11.14.1.1 Parameters

– callSegmentID:
This parameter indicates the Call Segment to be disconnected from the resource.

11.14.2 Responding entity (gsmSSF)

11.14.2.1 Normal procedure

gsmSSF preconditions:

(1) The basic call processing has been suspended at a DP. The CS_gsmSSF FSM in the initiating gsmSSF is in the state "Waiting_for_end_of_User_Interaction" or in the state "Waiting_for_end_of_Temporary_Connection".

gsmSSF postconditions:

(1) The connection to the gsmSRF or assisting gsmSSF is released.

(2) The CS_gsmSSF FSM transits to the state "Waiting_for_Instructions".

The receipt of "DisconnectForwardConnectionWithArgument" results in disconnecting the PE containing the gsmSRF from the specified Call Segment. It does not result in a release of the connection between the gsmSSF and the end-user.

On receipt of this operation, the gsmSSF shall perform the following actions:

– The gsmSSF releases the connection to the assisting gsmSSF or the gsmSRF.

– The gsmSSF FSM transits to the state "Waiting_for_Instructions".

NOTE: The successful disconnection from the gsmSRF causes the gsmSRF to transit to the state "Idle". A current order (e.g. "PlayAnnouncement" or "PromptAndCollectUserInformation") is cancelled and any queued order (e.g. "PlayAnnouncement" or "PromptAndCollectUserInformation") is discarded.

11.14.2.2 Error handling

Generic error handling for the operation related errors is described in clause 10 and the TC services which are used for reporting operation errors are described in clause 14.

11.15 DisconnectLeg procedure

11.15.1 General Description

The gsmSCF uses this operation to request the gsmSSF to release a specific leg associated with the call. Any other leg(s) not specified in the Disconnect Leg operation are retained.

11.15.1.1 Parameters

– legToBeReleased:
This parameter indicates the call leg to be released.

– releaseCause:
This parameter may be used by the MSC for generating specific tones to the party to be released or to fill in the "cause" parameter in the release message.

11.15.2 Responding entity (gsmSSF)

11.15.2.1 Normal procedure

gsmSSF preconditions:

A control relationship exists between the gsmSCF and the gsmSSF;
User interaction is not in progress in the Call Segment containing the leg to be disconnected.

gsmSSF postconditions:

The gsmSSF performs the call processing actions to release the indicated party.
Any armed EDPs on that leg shall be disarmed; any pending reports for that leg shall be sent to the gsmSCF.
If the released leg was the last leg within the Call Segment, then the CS_gsmSSF FSM for that Call Segment returns to the state "Idle".
If the leg was the last leg within the call, then the CSA_gsmSSF FSM returns to the state "Idle".
If the CS_gsmSSF FSM for the Call Segment concerned has not returned to the state "Idle", then it transits to the state "Waiting_for_Instructions". The remaining BCSM instances within the Call Segment shall transit to the O_Mid_Call DP or to the T_Mid_Call DP, unless already suspended at a DP. The Mid_Call EDP shall not be reported for this case.
A Return Result shall be sent to the gsmSCF immediately after successful execution of this operation.

11.15.2.2 Error handling

Generic error handling for the operation related errors is describer in clause 10, and the TC services which are used for reporting operation errors are described in clause 14.

11.16 EntityReleased procedure

11.16.1 General Description

The CSA uses this operation to inform the gsmSCF about the release of a logical entity (Call Segment or BCSM) caused by exception or errors. The CSA shall use this operation if this information can not be conveyed in a TC_ABORT or TC_END TC message because the TC dialogue has to be maintained for other logical entities (Call Segment or BCSM) in this CSA which are not affected by this error or exception. The CSA shall not use this operation if the last Call Segment in the CSA was released.

11.16.1.1 Parameters

This operation consists of a choice of the following parameters:

– CSFailure:
Indicates that a Call Segment was released. It contains of the following parameters:

– callSegmentID:
This parameter identifies the released Call Segment.

– cause:
This parameter indicates the cause for releasing this Call Segment. The cause may be used by the gsmSCF to decide the further handling of the call.

– BCSMFailure:
This parameter indicates that a leg was released. It consists of the following parameters:

– legID:
This parameter identifies the released leg.

– cause:
This parameter indicates the cause for releasing this BCSM. The cause may be used by the gsmSCF to decide the further handling of the call.

11.16.2 Invoking entity (gsmSSF)

11.16.2.1 Normal procedure

CSA_gsmSSF preconditions:

(1) Any CSA_gsmSSF FSM state except "Idle".

CSA_gsmSSF postconditions:

–

gsmSSF postconditions:

(1) If the released entity was a BCSM (leg), then only the appropriate resources are released. If the released entity was a Call Segment, then the related CS_gsmSSF FSM returns to the state "Idle".

11.16.2.2 Error handling

Generic error handling for the operation related errors is described in clause 10, and the TC services which are used for reporting operation errors are described in clause 14.

11.17 EstablishTemporaryConnection procedure

11.17.1 General Description

The gsmSCF uses this operation to create a connection between an initiating gsmSSF and an assisting gsmSSF as part of a service assist procedure. It can also be used to create a connection between a gsmSSF and a gsmSRF, for the case where the gsmSRF exists in a separately addressable PE.

The assistingSSPIPRoutingAddress shall contain routeing digits, a correlationID and a scfID when a temporary connection shall be established between PLMNs and no bilateral agreement exists between the involved network operators to transfer correlationID and SCFiD as separate parameters.

11.17.1.1 Parameters

– assistingSSPIPRoutingAddress:
This parameter indicates the destination address of the gsmSRF for assist procedure. The "assistingSSPIPRoutingAddress" may contain embedded within it, a "correlationID" and "scfID", but only if "correlationID" and "scfID" are not specified separately.

– correlationID:
This parameter is used by the gsmSCF to associate the "AssistRequestInstructions" from the assisting gsmSSF (or the gsmSRF) with the Request from the initiating gsmSSF. The "correlationID" shall be used only if the correlation id is not embedded in the "assistingSSPIPRoutingAddress". The network operator has to decide about the actual mapping of this parameter on the used signalling system.

– scfID:
This parameter contains the gsmSCF identifier and enables the assisting gsmSSF to identify which gsmSCF the AssistRequestInstructions shall be sent to.
The "scfID" shall be used only if the gsmSCF id is not embedded in the "assistingSSPIPRoutingAddress". The network operator has to decide about the actual mapping of this parameter on the used signalling system.
When ScfID is used in an operation which crosses an internetwork boundary, its encoding must be understood in both networks and if the length is extended beyond 10 bytes this must be supported by both entities; this requires bilateral agreement on the encoding.

– serviceInteractionIndicatorsTwo:
This parameter contains an indicator that is used for the control of the through connection to the Calling Party.

– Carrier:
This parameter contains carrier information. It consists of the carrier selection field followed by the Carrier ID information to be used by gsmSSF for routeing a call to a carrier.

It contains the following embedded parameter:

– carrierSelectionField:
This parameter indicates how the selected carrier is provided (e.g. pre-subscribed).

– carrierID:
This parameter indicates the carrier to use for the call. It contains the digits of the carrier identification code.

– naOliInfo:
This parameter contains originating line information which identifies the charged party number type to the carrier.

– callSegmentID:
This parameter indicates the Call Segment to which the temporary connection shall be established.

– originalCalledPartyID:
This parameter identifies the original called party.

– callingPartyNumber:
This parameter identifies the calling party.

11.17.2 Responding entity (gsmSSF)

11.17.2.1 Normal procedure

gsmSSF preconditions:

(1) The gsmSSF FSM is in the state "Waiting_for_Instructions".

(2) The gsmSSF is not an assisting gsmSSF.

gsmSSF postconditions:

(1) The gsmSSF performs the call processing actions to route the call to the assisting gsmSSF or gsmSRF in accordance with the "assistingSSPIPRoutingAddress" requested by the gsmSCF.

(2) The gsmSSF FSM transits to the state "Waiting_for_end_of_Temporary_Connection".

On receipt of this operation, the gsmSSF shall perform the following actions:

– Route the call to assisting gsmSSF or gsmSRF using "assistingSSPIPRoutingAddress";

11.17.2.2 Error handling

Until the connection setup has been accepted (refer to ITU‑T Recommendation Q.71 [41]) by the assisting gsmSSF or the gsmSRF, all received failure indications from the network on the ETC establishment shall be reported to the gsmSCF as EstablishTemporaryConnection error ETCFailed (e.g., busy, congestion).

NOTE The operation timer for EstablishTemporaryConnection shall be longer than the maximum allowed time for the signalling procedures to accept the connection.

Generic error handling for the operation related errors are described in clause 10 and the TC services which are used for reporting operation errors are described in clause 14.

11.18 EventReportBCSM procedure

11.18.1 General description

The gsmSSF uses this operation to notify the gsmSCF of a call related event previously requested by the gsmSCF in a "RequestReportBCSMEvent" operation.

11.18.1.1 Parameters

– eventTypeBCSM:
This parameter specifies the type of event that is reported.

– eventSpecificInformationBCSM:
This parameter indicates the call related information specific to the event.

For Collected_Info it shall contain the CalledPartyNumber parameter.

For Route_Select_Failure it shall contain the "FailureCause", if available.

For O_Busy it shall contain the "BusyCause", if available.

If the busy event is triggered by an ISUP release message, then the BusyCause is a copy of the ISUP release cause, for example: Subscriber absent, 20 or User busy, 17.
If the busy event is trigerred by a MAP error, for example: Absent subscriber, received from the HLR, then the MAP cause is mapped to the corresponding ISUP release cause.

NOTE 1: If no BusyCause is received, then the gsmSCF shall assume busy.

For T_Busy it may contain the following parameters, if available.

– CallForwarded:
This parameter indicates that the busy event is triggered by call forwarding at the GMSC or VMSC.

– ForwardingDestinationNumber:
This parameter indicates the forwarding destination.

– RouteNotPermitted:
This parameter indicates that the busy event is triggered because call forwarding was not invoked in this GMSC due to the rules of Basic Optimal Routeing.

– BusyCause:

If the busy event is triggered by an ISUP release message, then the BusyCause is a copy of the ISUP release cause, for example: Subscriber absent, 20 or User busy, 17.
If the busy event is triggered by a MAP error, for example: Absent subscriber, received from the HLR, then the MAP cause is mapped to the corresponding ISUP release cause.
If the busy event is triggered by call forwarding or call deflection invocation in the GMSC or VMSC, then the BusyCause will refer to the release cause in accordance with the mapping table in 3GPP TS 23.078 [7].
If the busy event is triggered by call forwarding at the GMSC, then the BusyCause reflects the forwarding reason (Subscriber Absent, 20 or User busy, 17). The eventSpecificInformationBCSM shall in that case also contain the CallForwarded indication.

NOTE 2: If no BusyCause is received, then the gsmSCF shall assume busy.

For O_No_Answer it shall be empty.

For T_No_Answer it may contain the CallForwarded indication and the ForwardingDestinationNumber.

If the No_Answer event is triggered by an ISUP release message or expiry of the CAMEL timer TNRy, then the eventSpecificInformationBCSM shall be empty.
If the No_Answer event is triggered by call forwarding at the GMSC or VMSC, then the eventSpecificInformationBCSM shall contain the CallForwarded indication and the ForwardingDestinationNumber.

For O_Answer or T_Answer it shall contain the following information, if available:

– The destination address for the call;

– The OR indicator, in the case that the call was subject to Basic Optimal Routeing, as specified in 3GPP TS 23.079 [8];

– The forwarding indicator, in the case that the Call Forwarding Supplementary Service was invoked;

– The charge indicator;

– The Extended Basic Service Code, for SCUDIF calls (see 3GPP TS 23.172 [16]);

– The Extended Basic Service Code 2, for SCUDIF calls (see 3GPP TS 23.172 [16]).

For O_Mid_Call and T_Mid_Call it shall contain the detected digit string, in accordance with the criterion defined in the RequestReportBCSMEvent operation.

For Call_Accepted, O_Term_Seized, O_Change_Of_Position and T_Change_Of_Position it shall contain the following information:

– locationInformation:
This parameter indicates the location of the MS.

For O_Disconnect and T_Disconnect it shall contain the "releaseCause", if available.

For O_Abandon" it may contain the following parameter, if available.

– routeNotPermitted:
This parameter indicates that the O-Abondon event is triggered because call set up shall not be invoked in this MSC due to the rules of Basic Optimal Routeing.

For O_Service_Change or T_Service_Change it may contain the following information:

– The Extended Basic Service Code, for SCUDIF calls (see 3GPP TS 23.172 [16]) ;

– The initiator of the Service Change;

– The nature of Service Change.

– legID:
This parameter indicates the party in the call for which the event is reported. The gsmSSF shall use the option "receivingSideID" only.

– receivingSideID:
If not included, then the default values for LegID are assumed according to the tables 11-1 and 11-2.

The "legID" parameter shall always be included for the events O_Disconnect and T_Disconnect.

– miscCallInfo:
This parameter indicates Detection Point (DP) related information.

– messageType:
This parameter indicates whether the message is a request, i.e. resulting from a "RequestReportBCSMEvent" with monitorMode = interrupted, or a notification, i.e. resulting from a "RequestReportBCSMEvent" with "monitorMode" = "notifyAndContinue".

11.18.2 Invoking entity (gsmSSF)

11.18.2.1 Normal procedure

gsmSSF preconditions:

(1) A control relationship or a monitoring relationship exists between the gsmSSF and the gsmSCF.

(2) For the O_Abandon DP and T_Abandon DP, the gsmSSF FSM is in any state, except "Idle". For other DPs, refer to 3GPP TS 23.078 [7].

(3) The BCSM proceeds to an EDP that is armed.

gsmSSF postconditions:

(1) If the message type was notification and there are still armed EDPs or pending reports, then the gsmSSF FSM stays in the state "Monitoring".

(2) If the message type was notification and there are neither any armed EDPs nor pending reports, then the gsmSSF FSM transits to the state "Idle".

(3) If the message type was request, then the gsmSSF FSM transits to the state "Waiting_for_Instructions". Call processing is interrupted.

11.18.2.2 Error handling

If the message type is "request" and the Tssf timer expires, then the gsmSSF shall abort the TC dialogue and shall instruct the MSC to treat the call in accordance with the Default Call Handling, valid for this CAMEL dialogue.

Operation related error handling is not applicable, due to class 4 operation.

11.19 FurnishChargingInformation procedure

11.19.1 General description

The gsmSCF uses this operation to send charging related information to a logical call record. This logical call record is CAMEL specific. The first FurnishChargingInformation operation of a call leg leads to the generation of a logical call record. The handling of subsequent FurnishChargingInformation operations for a call leg depends on the presence and value of the append free format data parameter in the FurnishChargingInformation operation. For details see 3GPP TS 23.078 [7].

If a FurnishChargingInformation operation is received for the called party when the gsmSSF FSM is in the state "Monitoring", or is suspended in one of the following DPs, then the charging information shall be included in the logical call record for the leg that has been or is to be established:

– Collected_Info;

– Analysed_Information;

– O_Answer;

– Terminating_Attempt_Authorised; or

– T_Answer.

If a FurnishChargingInformation operation is received for the called party when the gsmSSF is suspended in any other DP, then the charging information shall be included in the logical call record created for the last failed or disconnected called party.

11.19.1.1 Parameters

– fCIBillingChargingCharacteristics:
This parameter contains the following parameters;

– fCIBCCCAMELsequence1:
This parameter contains the following parameters;

– freeFormatData:
This parameter contains free-format billing and/or charging characteristics;

– partyToCharge:
This parameter indicates the party to bill and/or charge;

– appendFreeFormatData:
This parameter indicates whether previous FurnishChargingInformation free format data is appended or overwritten. Refer to 3GPP TS 23.078 [7] for details on the usage of this parameter.

11.19.2 Responding entity (gsmSSF)

11.19.2.1 Normal procedure

gsmSSF preconditions:

(1) The gsmSSF FSM is in the state

"Waiting_for_Instructions"; or
"Waiting_for_end_of_User_Interaction"; or
"Waiting_for_end_of_Temporary_Connection"; or
"Monitoring".

gsmSSF postconditions:

(1) No gsmSSF FSM state transition.

On receipt of this operation the gsmSSF performs actions to create the Logical call record if necessary, and writes the free-format information carried in the operation into the Logical call record. A FurnishChargingInformation operation will create a Logical Call Data Record (CDR) if such a record does not already exist for the indicated leg. Refer to sect. 11.26.1 for the handling in the case of successive FurnishChargingInformation operations for a call leg.

The Logical CDRs will be associated for a given call into one or more physical CDRs, as specified in 3GPP TS 32.250 [13].

A logical call record is output to a physical CDR when a disconnection event is propagated to the call leg associated with it, or when a Connect operation to create a connection to a Follow-on Called Party is received. Successive FurnishChargingInformation operationsindicating the calling leg (leg1) may overwrite data from previously received FurnishChargingInformation operation(s) indicating that leg during the entire call or call attempt. Successive FurnishChargingInformation operations indicating a called leg (leg2 or higher) may overwrite any previously received data from FurnishChargingInformation operation(s) indicating that called leg until the called leg representing that particular called party number is released from the call. When a new called party is created as a result of a follow-on call, and a FurnishChargingInformation operation indicating the called leg is received, then a new Logical call record shall be created for that call leg, for that portion of the call. From then on, any subsequent FurnishChargingInformation operations for that called party may overwrite the data from any previous FurnishChargingInformation operation(s) for the called leg presenting that particular called party number. Logical call records that have been output already are not affected.

No Logical call record is output at the end of a user interaction.

11.19.2.2 Error handling

Generic error handling for the operation related errors are described in clause 10 and the TC services which are used for reporting operation errors are described in clause 14.

11.20 InitialDP procedure

11.20.1 General description

The gsmSSF uses this operation after detection of a TDP‑R in the BCSM, to request the gsmSCF for instructions to complete the call.

11.20.1.1 Parameters

– serviceKey:
This parameter indicates to the gsmSCF the requested IN service. It is used to address the required application/SLP within the gsmSCF; this parameter is not for SCP addressing.

– calledPartyNumber:
This parameter contains the number used to identify the called party in the forward direction, i.e. see ETSI EN 300 356-1 [23]. This parameter shall be sent only in the Mobile Terminating, Mobile Forwarding, mobile originating on unsuccessful TDP and trunk originating cases. For the trunk originating case the end of pulsing signal (ST) is included in the calledPartyNumber address signals if it has been received or the MSC has determined that the called number information is complete.

– callingPartyNumber:
This parameter carries the calling party number to identify the calling party or the origin of the call. See ETSI EN 300 356-1 [23] Calling Party Number signalling information.

– callingPartysCategory:
Indicates the type of calling party (e.g. operator, pay phone, ordinary subscriber). See ETSI EN 300 356-1 [23] Calling Party Category signalling information.

– locationNumber:
This parameter is used to convey the geographical area address for mobility services, see ITU‑T Recommendation Q.762 [44]. It is used when "callingPartyNumber" does not contain any information about the geographical location of the calling party (e.g., origin dependent routeing when the calling party is a mobile subscriber).

– originalCalledPartyID:
If the call has met call forwarding on the route to the gsmSSF, then this parameter carries the dialled digits. Refer to EN 300 356-1[23] Original Called Number signalling information.

– highLayerCompatibility:
This parameter indicates the type of the high layer compatibility, which will be used to determine the ISDN ‑ teleservice of a connected ISDN terminal. The highlayerCompatibility can also be transported by ISUP (e.g. within the ATP (see ITU‑T Recommendation Q.763 [45]) parameter).

– additionalCallingPartyNumber:
The calling party number provided by the access signalling system of the calling user, e.g. provided by a PBX.

– bearerCapability:
This parameter indicates the type of the bearer capability connection or the transmission medium requirements to the user. It is a network option to select which of the two parameters to be used:

– bearerCap:
This parameter contains the value of the ISUP User Service Information parameter.

The parameter "bearerCapability" shall be included in the "InitialDP" operation only in the case the ISUP User Service Information parameter is available at the gsmSSF.

If User Service Information and User Service Information Prime are available at the gsmSSF, then the "bearerCap" shall contain the value of the User Service Information Prime parameter.

– eventTypeBCSM:
This parameter indicates the armed BCSM DP event, resulting in the "InitialDP" operation.

– redirectingPartyID:
This parameter indicates the last directory number the call was redirected from.

– redirectionInformation:
This parameter contains forwarding related information, such as redirecting counter.
See ITU‑T Recommendation Q.763 [45] Redirection Information signalling information.

– iPSSPCapabilities:
This parameter indicates which gsmSRF resources supported within the VMSC or GMSC the gsmSSF resides in are attached and available.

– serviceInteractionIndicatorsTwo:
This parameter contains indicators that are used to resolve interactions between CAMEL based services and network based services.

– iMSI:
This parameter contains the IMSI of the mobile subscriber for which the service is invoked.

– subscriberState:
This parameter indicates the state of the mobile subscriber for which the service is invoked. The possible states are "busy", "idle" and "not reachable".

– locationInformation:
This parameter indicates the location of the MS and the age of the information defining the location.

– ext‑BasicServiceCode:
This parameter indicates the Basic Service Code.

– callReferenceNumber:
This parameter contains the call reference number assigned to the call by the CCF.

– mscAddress:
This parameter contains the mscId assigned to the MSC.

– gmscAddress:
This parameter contains the gmscId assigned to the GMSC.

– calledPartyBCDNumber:
This parameter contains the number used to identify the called party in the forward direction. It may also include service selection information, including * and # characters.

– time&Timezone:
This parameter contains the time that the gsmSSF was triggered, and the time zone that the invoking gsmSSF resides in.

– callForwardingSS-Pending:
This parameter indicates that a forwarded-to-number was received and that the call will be forwarded due to the Call Forwarding supplementary service in the GMSC or in the VMSC, unless otherwise instructed by the gsmSCF.

– carrier:
This parameter contains carrier information. It consists of the carrier selection field followed by the Carrier ID information associated with the calling subscriber of a mobile originating call or trunk originating call, the called subscriber of a mobile terminating call or the forwarding subscriber of a mobile fowarded call.

It contains the following embedded parameter:

– carrierSelectionField:
This parameter indicates how the selected carrier is provided (e.g. pre-subscribed).

– carrierID:
This parameter indicates the carrier to use for the call. It contains the digits of the carrier identification code.

– cug-Index:
This parameter is used to select a CUG for an outgoing call at the user, or to indicate an incoming CUG call to the user.

– cug-Interlock:
This parameter uniquely identifies a CUG within a network.

– cug-OutgoingAccess:
This parameter indicates if the calling user has subscribed to the outgoing access inter-CUG accessibility subscription option.

– cGEncountered:
This parameter indicates the type of call gapping the related call has been subjected to, if any.

cause:
This parameter indicates the release cause which triggered the event:

For Route_Select_Failure" it shall contain the "FailureCause", if available.

For T_Busy it may contain the following parameters, if available.

If the busy event is triggered by an ISUP release message, then the BusyCause shall a copy of the ISUP release cause, for example: Subscriber absent, 20 or User busy, 17.
If the busy event is triggered by a MAP error, for example: Absent subscriber, received from the HLR, then the MAP cause is mapped to the corresponding ISUP release cause.
If the busy event is triggered by call forwarding invocation in the GMSC or VMSC, then the BusyCause shall refer to the type of the call forwarding service in accordance with the mapping table in 3GPP TS 23.078 [7].

– forwardingDestinationNumber:
This parameter contains the forwarding destination.

– ms-Classmark2:
This parameter contains the MS Classmark 2 of the mobile subscriber for which the service is invoked.

– iMEI:
This parameter contains the IMEI (with software version) of the mobile subscriber for which the service is invoked.

– supportedCamelPhases:
This parameter indicates the CAMEL Phases supported in the GMSC or VMSC which sends this operation.

– offeredCamel4Functionalities:
This parameter contains the offered CAMEL phase 4 functionalities.

– bearerCapability2:
This parameter indicates the type of the bearer capability connection or the transmission medium requirements to the user.

– ext‑BasicServiceCode2:
This parameter indicates the Basic Service Code2.

– highLayerCompatibility2:
This parameter indicates the high layer compatibility2 for a SCUDIF call.

– lowLayerCompatibility:
This parameter indicates the low layer compatibility.

– lowLayerCompatibility2:
This parameter indicates the low layer compatibility2 for a SCUDIF call.

– enhancedDialledServicesAllowed:
This parameter indicates that the gsmSCF may use the Enhanced Dialled Services (EDS) for this call.

UU-Data:
This parameter contains user-to-user signalling service related information.
collectInformationAllowed:
This parameter indicates that the gsmSCF may use Collect Information for this call.
releaseCallArgExtensionAllowed:
This parameter indicates that the gsmSCF may use Extensions in Release Call operation for this call.

11.20.2 Invoking entity (gsmSSF)

11.20.2.1 Normal procedure

gsmSSF preconditions:

(1) An event fulfilling the criteria for the DP being executed has been detected.

(2) Call gapping and SS7 overload are not in effect for the call.

gsmSSF postconditions:

(1) If the DP was armed as a TDP‑R and trigger conditions, if present, are fulfilled, then a control relationship between the gsmSCF and the gsmSSF is established. The gsmSSF FSM transits to the state "Waiting_for_Instructions".

The address of the gsmSCF shall be fetched from the valid CSI. The gsmSSF shall provide all available parameters to the gsmSCF.

If no triggering takes place, because trigger conditions were not fulfilled, then the gsmSSF shall proceed with call handling without CAMEL Service.

The gsmSSF application timer Tssf is loaded and started when the gsmSSF sends "InitialDP" for requesting instructions from the gsmSCF. It is used to prevent excessive call suspension time.

11.20.2.2 Error handling

If the gsmSCF is not accessible, then the call proceeds in accordance with the Default Call Handling parameter in the CSI.

When Tssf expires, then the gsmSSF shall abort the interaction with the gsmSCF by means of an abort to TC and shall call continue the call in accordance with the Default Call Handling parameter in the valid CSI.

If the calling party abandons after the sending of "InitialDP" and before the TC dialogue is established, then the gsmSSF shall abort the interaction with the gsmSCF by means of an abort to TC.

Generic error handling for the operation related errors are described in clause 10 and the TC services which are used for reporting operation errors are described in clause 14.

11.21 InitiateCallAttempt procedure

11.21.1 General Description

The gsmSCF uses this operation to request the gsmSSF to create a new call leg to one call party using the address information provided by the gsmSCF (e.g. wake-up call). InitiateCallAttempt can also be used to create an additional call party in a new Call Segment within an existing Call Segment Association. In both use cases the gsmSCF shall subsequently arm O_Answer as an EDP-R and the call failure events (Route_Select_Failure, O_Busy and O_No_Answer) as EDP-Rs and/or EDP-Ns, in order to enable the gsmSCF to treat this call appropriately when any of these events is encountered.

11.21.1.1 Parameters

11.21.1.1.1 Argument Parameters

– destinationRouteingAddress:
This parameter contains the called party number towards which the call shall be routed.

– callingPartyNumber:
This parameter identifies which number shall be regarded as the calling party for the created call.

– legToBeCreated:
This parameter indicates the LegID to be assigned to the newly created party.

– newCallSegment:
This parameter indicates the Call Segment ID to be assigned to the newly created Call Segment.

– callReferenceNumber:
This parameter contains the call reference number assigned to the call by the gsmSCF.

– gsmSCFAddress:
This parameter indicates the address of the gsmSCF initiating the operation.

– suppress-T-CSI:
This parameter indicates that the T-CSI for the served subscriber shall be suppressed for this call leg.

11.21.1.1.2 Result Parameters

– supportedCamelPhases:
This parameter indicates the CAMEL Phases supported in the gsmSSF which receives this operation.

– offeredCamel4Functionalities:
This parameter contains the offered CAMEL phase 4 functionalities.

– releaseCallArgExtensionAllowed:
This parameter indicates that the gsmSCF may use Extensions in Release Call operation for this call.

11.21.2 Responding entity (gsmSSF)

11.21.2.1 Normal procedure

gsmSSF preconditions:

None.

gsmSSF postconditions:

A new O-BCSM has been created; call processing is suspended.
A Return Result is sent to the gsmSCF.
The CS_gsmSSF FSM transits from the state "Idle" to the state "Waiting_for_Instructions".

All subsequent operations are treated in accordance with their normal procedures.

11.21.2.2 Error handling

Generic error handling for the operation related errors is described in clause 10, and the TC services which are used for reporting operation errors are described in clause 14.

11.22 MoveLeg procedure

11.22.1 General Description

The gsmSCF uses this operation to request the gsmSSF to move the leg from its current Call Segment to CSID1.

11.22.1.1 Parameters

– legIDToMove:
This parameter indicates the leg that shall be moved.

11.22.2 Responding entity (gsmSSF)

11.22.2.1 Normal procedure

gsmSSF preconditions:

A control relationship exists between the gsmSCF and the gsmSSF.
The source BCSM is in the alerting phase or in the active phase.
The target Call Segment fulfills the following preconditions:

At least one leg in the target Call Segment has reached the active phase, or
The original BCSM in the target Call Segment is at Terminating_Attempt_Authorised, Analysed_Information (for EDS only) or Collected_Info detection point, and the outgoing leg of that BCSM has been disconnected by the gsmSCF, or
The call was created by the gsmSCF.

The CS_gsmSSF FSM for each Call Segment involved is in the state "Waiting_for_Instructions" or in the state "Monitoring".
User Interaction is not in progress in either Call Segment.

gsmSSF postconditions:

The gsmSSF performs the appropriate call processing actions.
The CS_gsmSSF FSM for CSID1 transits to the state "Waiting_for_Instructions". The BCSM instances within CSID1transit to the O_Mid_Call DP or to the T_Mid_Call DP, if not already suspended. The Mid_Call EDP shall not be reported for this case.
The CS_gsmSSF process for the source Call Segment is terminated.
A Return Result is sent to the gsmSCF immediately after successful execution of this operation.
A Pending ApplyChargingReport for the source call segment shall be sent to the gsmSCF.

11.22.2.2 Error handling

Generic error handling for the operation related errors is described in clause 10, and the TC services which are used for reporting operation errors are described in clause 14.

11.23 PlayAnnouncement procedure

11.23.1 General description

The gsmSCF uses this operation for inband interaction with a CS user.

11.23.1.1 Parameters

– informationToSend:
This parameter indicates an announcement a tone to be sent to the end-user by the gsmSRF.

– inbandInfo:
This parameter specifies the inband information to be sent.

– messageID:
This parameter indicates the message(s) to be sen; this may be one of the following:

– elementaryMessageID:
This parameter indicates a single announcement.

– text:
This parameter indicates a text to be sent. The text shall be transformed to inband information (speech) by the gsmSRF. This parameter consists of two parameters; messageContent and attributes. The attributes of the text parameter may consist of items such as language.

– elementaryMessageIDs:
This parameter specifies a sequence of announcements.

– variableMessage:
This parameter specifies an announcement with one or more variable parts.

– numberOfRepetitions:
This parameter indicates the maximum number of times the message shall be sent to the end‑user.

– duration:
This parameter indicates the maximum time duration in seconds that the message shall be played or repeated. A value of "0" indicates endless repetition.

– interval:
This parameter indicates the time interval in seconds between successive messages, i.e. the time between the end of the announcement and the start of the repetition of this announcement. This parameter may be used only when "numberOfRepetitions" is > 1.

– tone:
This parameter specifies a tone to be sent to the end‑user.

– toneID:
This parameter indicates the tone to be sent.

– duration:
This parameter indicates the time duration in seconds of the tone to be sent. A value of "0" indicates infinite duration.

– disconnectFromIPForbidden:
This parameter indicates whether the gsmSRF may initiate a disconnection from the gsmSSF after the interaction has been completed.

If this parameter is TRUE, then the gsmSRF shall not initiate a disconnection. If this parameter is FALSE, then the gsmSRF may initiate a disconnection.

– requestAnnouncementCompleteNotification:
This parameter indicates whether or not a "SpecializedResourceReport" shall be sent to the gsmSCF when all information has been sent.

– requestAnnouncementStartedNotification:
This parameter indicates whether or not a "SpecializedResourceReport" shall be sent to the gsmSCF when the first announcement or tone has started.

– callSegmentID:
This parameter indicates the Call Segment to which the user interaction shall apply.

11.23.2 Responding entity (gsmSRF)

11.23.2.1 Normal procedure

gsmSRF preconditions:

(1) The SRSM‑FSM is in the state "Connected"; if the gsmSRF received previously an operation from the gsmSCF, then the SRSM-FSM is in the state "User Interaction".

(2) When the first announcement or tone has started and "RequestAnnouncementStartedNotification" is TRUE, then the SRSM shall send a "SpecializedResourceReport" operation, containing the "FirstAnnouncementStarted" parameter, to the gsmSCF.

gsmSRF postconditions:

(1) The gsmSRF sends the information to the user as indicated by "informationToSend".

(2) The SRSM‑FSM transits to the state "User Interaction", or remains in the same state.

(3) If all information has been sent and "RequestAnnouncementCompleteNotification" is TRUE, then the SRSM shall send a "SpecializedResourceReport" operation, containing the "AllAnnouncementsComplete" parameter, to the gsmSCF.

(4) If all information has been sent and "disconnectFromIPForbidden" is FALSE, then the SRSM disconnects the gsmSRF from the user.

The announcement sent to the end‑user is ended in the following conditions:

– if neither "duration" nor "numberOfRepetitions" is specified, then the network specific announcement ending conditions shall apply; or

– if "numberOfRepetitions" is specified, when all repetitions have been sent; or

– if duration is specified, when the duration has expired. The announcement is repeated until this condition is met; or

– if "duration" and "numberOfRepetitions" is specified, when one of both conditions is satisfied (whichever comes first).

11.23.2.2 Error handling

If a Cancel operation is received before or during the processing of the operation, then that operation shall be cancelled immediately and the error "Canceled" shall be reported to the gsmSCF.

Generic error handling for the operation related errors are described in clause 10 and the TC services which are used for reporting operation errors are described in clause 14.

11.24 PlayTone procedure

11.24.1 General description

The gsmSCF uses this operation to instruct the gsmSSF to play tones to a leg or a Call Segment using the MSC’s tone generator.

If a Call Segment is indicated, then the tones shall be played to all active legs in that Call Segment. If a leg is indicated, then the tones shall be played to that leg only.

11.24.1.1 Parameters

legOrCallSegment:
This parameter indicates the leg or Call Segment to which the PlayTone operation shall apply.

– bursts:
This parameter indicates the variable sequence of tones to be played and consists of the following parameters:

– numberOfBursts:
This parameter indicates the number of bursts that form the burstlist.

– burstInterval:
This parameter indicates the time interval between successive bursts in a sequence of bursts.

– numberOfTonesInBurst:
This parameter indicates the number of tones to be played in each burst.

– toneDuration:
This parameter indicates the time durationof a single tone in a burst.

– toneInterval:
This parameter indicates the time interval between successive tones in a burst.

11.24.2 Responding entity (gsmSSF)

11.24.2.1 Normal procedure

gsmSSF preconditions:

The gsmSSF FSM is in one of the following states:

"Monitoring"; or
"Waiting_for_Instructions".

If a Call Segment is indicated, then at least one of the legs in that Call Segment is in the active phase.

gsmSSF postconditions:

No gsmSSF FSM state transition.

11.24.2.2 Error handling

Generic error handling for the operation related errors is described in clause 10 and the TC services used for reporting operation errors are described in clause 14.

11.25 PromptAndCollectUserInformation procedure

11.25.1 General description

The gsmSCF uses this operation to interact with a call party in order to collect information.

11.25.1.1 Parameters

– collectedInfo:

– collectedDigits:

– minimumNbOfDigits:
This parameter specifies the minimum number of valid digits to be collected.

– maximumNbOfDigits:
This parameter specifies the maximum number of valid digits to be collected. The following applies:
"maximumNbOfDigits" ≥ "minimumNbOfDigits".

– endOfReplyDigit:
This parameter indicates the digit string used to signal the end of input.

In the case that the "maximumNbOfDigits" > "minimumNbOfDigits" the following applies:

If "endOfReplyDigit" is not present, then the end of input is indicated:

– when the inter-digit timer expires; or

– when the number of valid digits received equals the "maximumNbOfDigits".

If "endOfReplyDigit" is present, then the end of input is indicated:

– when the inter-digit timer expires; or

– when the end of reply digit is received; or

– when the number of valid digits received equals the "maximumNbOfDigits".

When the end of input is reached, the collected digits are sent from gsmSRF to the gsmSCF, including the "endOfReplyDigit" if received by the gsmSRF. In the case the number of valid digits received is less than the "minimumNbOfDigits" when the inter-digit timer expires or when the end of reply digit is received, the input is considered to be erroneous.

– cancelDigit:
This parameter indicates the cancel digit string that may be entered by the user to request a retry. All digits already received by the gsmSRF are discarded and the PromptAndCollectUserInformation procedure is performed again, thus e.g. the same announcement to request user information is given to the user and information is collected. If this parameter is not present, then the user is not able to request a retry.

– startDigit:
This parameter indicates the start digit string that indicates the start of the valid digits to be collected. The digits that are received by the gsmSRF before this start digit is received, are discarded and are not considered to be valid. The start digit string itself is considered to be valid digits.

If this parameter is not present, then all received digits are considered to be valid.

When the end of input is reached, the collected digits are sent from gsmSRF to the gsmSCF, including the "startDigit" if received by the gsmSRF.

– firstDigitTimeOut:
If this parameter is present, then the first digit shall be received by the gsmSRF before first‑digit timer expiration. If the first digit is not received before first-digit timer expiration, then the input is considered to be erroneous.

If this parameter is not present, then the gsmSRF shall use a default value for the first-digit timer.

If "startDigit" is present, then the first-digit timer shall be stopped after the start digit is received. If "startDigit" is not present, then the first-digit timer shall be stopped when any digit is received, except when the digit matches the "cancelDigit", if present.

– interDigitTimeOut:
If this parameter is present, then any subsequent valid or invalid digit shall be received by the gsmSRF before the inter-digit timer expires. As a result of receiving a digit, the inter-digit timer is reset and restarted.

If a subsequent valid or invalid digit is not received before the inter-digit timer expires and the number of received valid digits is less than "minimumNbOfDigits", then the input is considered to be unsuccessful.

If a subsequent valid or invalid digit is not received before the inter-digit timer expires and the number of received valid digits is greater than "minimumNbOfDigits" and smaller than or equal to "maximumNbOfDigits", then the input is considered to be successful.

If the "interDigitTimeOut" is not present, then the gsmSRF shall use a default value for the inter-digit timer.

– errorTreatment:
This parameter defines what specific action shall be taken by the gsmSRF in the event of error conditions occurring.

– interruptableAnnInd:

If this parameter is TRUE, then the announcement shall interrupted after the first valid or invalid digit is received by the gsmSRF. If the announcement is interrupted, then a first‑digit timer shall not apply anymore. However, if the announcement has not been interrupted, then the first-digit timer shall be started after the announcement has been finished.

If this parameter is FALSE, then the announcement shall not be interrupted after the first digit is received by the gsmSRF. The received digits during the announcement are discarded and considered to be invalid. All other specified parameters ("minimumNbOfDigits", "maximumNbOfDigits", "endOfReplyDigit", etc.) do not apply before the announcement has been finished. The first-digit timer shall be started after the announcement has been finished.

– voiceInformation:
If this parameter is FALSE, then all valid or invalid digits shall be entered by DTMF.

If this parameter is TRUE, then the calling user is required to provide all valid or invalid information by speech. The gsmSRF shall perform voice recognition and shall translate the provided information into digits. The end of reply digit(s), if required, shall be provided by speech.

– voiceBack:
If this parameter is FALSE, then no voice back information shall be given by the gsmSRF.

If this parameter is TRUE, then the valid input digits received by the gsmSRF shall be announced back to the calling user immediately after the end of input is received. The invalid input digits will not be announced back to the calling user. The end of reply digit(s) shall not be voiced back to the calling user.

– disconnectFromIPForbidden:
This parameter indicates whether the gsmSRF may initiate a disconnection from the gsmSSF after the interaction has been completed.

If this parameter is TRUE, then the gsmSRF shall not initiate a disconnection. If this parameter is FALSE, then the gsmSRF may initiate a disconnection.

– informationToSend:
This parameter indicates an announcement or tone to be sent to the end-user by the gsmSRF.

– inbandInfo:
This parameter specifies the inband information to be sent.

– messageID:
This parameter indicates the message(s) to be sent;, this may be one of the following:

– elementaryMessageID:
This parameter indicates a single announcement.

– text:
This parameter indicates a text to be sent. The text shall be transformed to inband information (speech) by the gsmSRF. The attributes of text may consist of items such as language.

– elementaryMessageIDs:
This parameter specifies a sequence of announcements.

– variableMessage:
This parameter specifies an announcement with one or more variable parts.

– numberOfRepetitions:
This parameter indicates the maximum number of times the message shall be sent to the end-user.

– duration:
This parameter indicates the maximum time duration in seconds that the message shall be played or repeated. A value of "0" indicates endless repetition.

– interval:
This parameter indicates the time interval between successive messages, i.e. the time between the end of the announcement and the start of the repetition of this announcement. This parameter may be used only when "numberOfRepetitions " > 1.

– tone:
This parameter specifies a tone to be sent to the end-user.

– toneID:
This parameter indicates the tone to be sent.

– duration:
This parameter indicates the time duration in seconds of the tone. A value of "0" indicates infinite duration.

– requestAnnouncementStartedNotification:
This parameter indicatewhether or not a "SpecializedResourceReport" shall be sent to the gsmSCF when the first announcement or tone has started.

– callSegmentID:
This parameter indicates the Call Segment to which the user interaction shall apply.

Result Parameter:

– digitsResponse:
This parameter contains the information collected from the end-user.

11.25.2 Responding entity (gsmSRF)

11.25.2.1 Normal procedure

gsmSRF preconditions:

(1) The SRSM‑FSM is in the state "Connected"; if the gsmSRF received previously an operation from the gsmSCF, then the SRSM-FSM is in the state "User Interaction".

(2) If the first announcement or tone has started and "RequestAnnouncementStartedNotification" is TRUE, then the SRSM sends a "SpecializedResourceReport" operation, containing the "FirstAnnouncementStarted" parameter, to the gsmSCF.

gsmSRF postconditions:

(1) The gsmSRF has sent the information to the end‑user as indicated by "informationToSend".

(2) The collected information from the end‑user is sent to the gsmSCF as RETURN RESULT of the "PromptAndCollectUserInformation".

(3) If the "disconnectFromIPForbidden" is FALSE, then the gsmSRF initiates a bearer channel disconnect to the gsmSSF and the SRSM FSM transits to the state "Idle".

(4) Otherwise, the SRSM FSM transits to the state "User Interaction" or remains in the same state.

The announcement sent to the end‑user is ended in the following conditions:

– if neither "duration" nor "numberOfRepetitions" is specified, then the network specific announcement ending conditions shall apply; or

– if "numberOfRepetitions" is specified, when all repetitions have been sent; or

– if duration is specified, when the duration has expired. The announcement is repeated until this condition is met; or

– if "duration" and "numberOfRepetitions" is specified, when one of both conditions is satisfied (whichever comes first).

If the parameter "interruptableAnnInd" is not FALSE and the end‑user has responded with a digit during the sending of the announcement, then the above conditions are overruled. In that case, the announcement shall be ended immediately.

The parameter "errorTreatment" specifies how the gsmSRF shall treat an error. The value "reportErrorToSCF" means that the error shall be reported to the gsmSCF by means of Return Error with "ImproperCallerResponse". The value "help" indicates that no error shall be reported to gsmSCF but assistance shall be given to the end‑user in the form of a network dependent default announcement (which may be dependent on the context, i.e. the sent message). The value "repeatPrompt" indicates that no error shall be reported to the gsmSCF but the prompt shall be repeated to the end‑user. The error handling procedures related to "help" and " repeatPrompt" shall be done only once per "PromptAndCollectUserInformation" operation.

NOTE Note on processing "endOfInput"

The receipt of any "endOfInput" condition (e.g endOfReplyDigit, cancelDigit, firstDigitTimeout, interDigitTimeout) terminates immediately the ongoing input. In other words when e.g an endOfReplyDigit is received, then the receipt of a subsequent cancelDigit will not be processed anymore.

11.25.2.2 Error handling

If a Cancel operation is received before or during the processing of the operation, then the operation shall be cancelled immediately and the error "Canceled" shall be reported to the gsmSCF.

Generic error handling for the operation related errors are described in clause 10, the TC services which are used for reporting operation errors are described in clause 14.

If any of the parameter restrictions are violated (e.g. "minimumNbOfDigits" > "maximumNbOfDigits"), then an operation error has occured.

11.26 ReleaseCall procedure

11.26.1 General description

The gsmSCF uses this operation to tear down a call at any phase.

11.26.1.1 Parameters

– allCallSegments:
This parameter gives an indication to the gsmSSF about the reason of releasing this specific call. This may be used by gsmSSF for generating specific tones to the different parties in the call or to fill in the "cause" in the release message.

– allCallSegmentsWithExtension:
This parameter gives an indication to the gsmSSF about the reason of releasing this specific call. This may be used by gsmSSF for generating specific tones to the different parties in the call or to fill in the "cause" in the release message. It additionally allows for the sending of the extensions parameter to the gsmSSF.

11.26.2 Responding entity (gsmSSF)

11.26.2.1 Normal procedure

gsmSSF preconditions:

(1) A control relationship exists between gsmSCF and gsmSSF.

(2) The gsmSSF FSM is in the state "Waiting_for_Instructions" or in the state "Monitoring".

gsmSSF postconditions:

(1) The gsmSSF FSM transits to the state "Idle" after sending any pending "CallInformationReport" or "ApplyChargingReport". All armed EDPs shall be disarmed. All connections and resources related to the call shall be released.

11.26.2.2 Error handling

Operation related error handling is not applicable, due to class 4 operation.

11.27 RequestReportBCSMEvent procedure

11.27.1 General description

The gsmSCF uses this operation to request the gsmSSF to monitor for a call‑related event (e.g., BCSM events such as O_Busy or O_No_Answer) and to send a notification to the gsmSCF when the event is detected.

The monitoring of more than one event may be requested with a single "RequestReportBCSMEvent" operation, but each of these requested events will be reported in a separate "EventReportBCSM" operation.

NOTE: If the RequestReportBCSMEvent requests arming of the current DP from which the call processing was suspended, then the next occurrance of the DP encountered during BCSM processing will be detected (i.e. not the current one from which the call was suspended).

The DP arming principle is as follows:

– The DPs O_Disconnect and T_Disconnect can be armed for any or all legs depending on the direction for which events have to be captured. As an example, the O_Disconnect DP can be armed for leg1 and leg2; in this case, if a release request is received from the A-party, then it will be detected by the O_Disconnect DP armed for leg1, while a release request from the B-party will be detected by the O_Disconnect DP armed for leg2.

– The O_Abandon DP can be armed only for leg1 in the O-BCSM and the T_Abandon DP can be armed only for leg1 in the T-BCSM.

– The Collected_Info DP can be armed only for leg1 in the O-BCSM for TO calls.

Table 11-1: DP Arming Table for O‑BCSM:

O-BCSM	leg1	Not leg 1	Default leg ID
O_Term_Seized DP	–	X	2
Route_Select_Failure DP	‑	X	2
O_Busy DP	‑	X	2
O_No_Answer DP	‑	X	2
O_Answer DP	‑	X	2
O_Disconnect DP	X	X	‑ (^{note 1)}
O_Abandon DP	X	‑	1
O_Mid_Call	X	–	1
O_Change_Of_Position	X	–	1
O_Service_Change	X	–	1
Collected_Info DP	X	–	1
Note 1: The "legID" parameter shall be included Nomenclature: X = Arming Applicable ‑ = Arming not Applicable

Table 11-2: DP Arming Table for T‑BCSM:

T-BCSM	leg2	leg1	Default Leg ID
Call_Accepted DP	X	–	2
T_Busy DP	X	‑	2
T_No_Answer DP	X	‑	2
T_Answer DP	X	‑	2
T_Disconnect DP	X	X	‑ (note 1)
T_Abandon DP	‑	X (note 2)	1
T_Mid_Call	X	–	2
T_Change_Of_Position	X	–	2
T_Service_Change	X	–	2
Note 1: The "legID" parameter shall be included Note 2: T_Abandon can be armed for leg1 only. Nomenclature: X = Arming Applicable ‑ = Arming not Applicable

11.27.1.1 Parameters

– bcsmEvents:
This parameter specifies the event or events of which a report is requested.

– eventTypeBCSM:
This parameter specifies the type of event of which a report is requested.

– monitorMode:
This parameter indicates how the event shall be reported. If the "monitorMode" is "interrupted", then the event shall be reported as a request; if the "monitorMode" is "notifyAndContinue", then the event shall be reported as a notification; if the "monitorMode" is "transparent", then the event shall not be reported.

– legID:
This parameter indicates the party in the call for which the event shall be reported. The gsmSCF shall use the option "sendingSideID" only.

– sendingSideID:

If not included, then the default values for LegID are assumed according to the tables 11-1 and 11-2.

The "legID" parameter shall always be included for the events O_Disconnect and T_Disconnect.

– dPSpecificCriteria:
This parameter contains information specific to the EDP that shall be armed.

– numberOfDigits:
This parameter indicates the number of digits requested for the CollectedInfo event.

– interDigitTimeout:
This parameter indicates the inter-digit timer value for the CollectedInfo event.

– applicationTimer:
This parameter indicates the No_Answer timer value for the No_Answer event. If the called party does not answer the call within the allotted time, then the gsmSSF shall report the event to the gsmSCF. This timer shall be shorter than the network No_Answer timer.

– midCallControlInfo:
This parameter defines the criterion for the detection and reporting of mid-call digits. If this parameter is absent, then the first digit entered shall be reported.

– changeOfPositionControlInfo:
This parameter defines the criterion for the reporting of change of location. If this parameter is absent, then any change of position shall be reported.

– automaticRearm:
This parameter indicates that the gsmSSF shall rearm the DP whenever it is encountered.

11.27.2 Responding entity (gsmSSF)

11.27.2.1 Normal procedure

gsmSSF preconditions:

(1) A control relationship exists between the gsmSSF and the gsmSCF.

(2) The gsmSSF FSM is in the state "Waiting_for_Instructions" or in the state "Monitoring".

NOTE: In the state "monitoring" only requests to disarm detection points (with MonitorMode set to "Transparent") or to send notifications of events (with MonitorMode set to "NotifyAndContinue") shall be accepted by the gsmSSF.

gsmSSF postconditions:

(1) The requested EDPs are armed or disarmed as indicated.

(2) Previously requested events are monitored until ended by a transparent monitor mode, until the end of the call, until the EDPs are detected or until the corresponding leg is released.

(3) The gsmSSF FSM remains in the same state, unless all EDPs have been disarmed and no CallInformationReport or ApplyChargingReport has been requested; in the latter case, the gsmSSF FSM transits to the state "Idle".

11.27.2.2 Error handling

Generic error handling for the operation related errors are described in clause 10 and the TC services which are used for reporting operation errors are described in clause 14.

11.28 ResetTimer procedure

11.28.1 General description

The gsmSCF uses this operation to refresh the Tssf application timer, in order to avoid the Tssf time‑out at the gsmSSF.

11.28.1.1 Parameters

– timerID:
This parameter indicates which timer shall be reset. The only permissible value of this parameter is "tssf".

– timerValue:
This parameter specifies the value to which the timer shall be set.

– callSegmentID:
This parameter indicates the Call Segment in the gsmSSF for which the timer shall be reset.

11.28.2 Responding entity (gsmSSF)

11.28.2.1 Normal procedure

gsmSSF preconditions:

(1) Basic call processing has been suspended at a DP.

(2) The gsmSSF FSM is in the state "Waiting_for_Instructions", the state "Waiting_for_end_of_User_Interaction" or in the state "Waiting_for_end_of_Temporary_Connection".

gsmSSF postconditions:

(1) The Tssf timer is loaded with the value received from the gsmSCF and is restarted.

(2) No gsmSSF FSM state transition.

11.28.2.2 Error handling

Generic error handling for the operation related errors are described in clause 10 and the TC services which are used for reporting operation errors are described in clause 14.

11.29 SendChargingInformation procedure

11.29.1 General description

The gsmSCF uses this operation to instruct the gsmSSF on the Advice of Charge information to be sent by the gsmSSF. The SendChargingInformation operation may be invoked on multiple occasions.

The SendChargingInformation operation may be used for MO and MT calls in the VMSC. In the case of an MT call, the CSE provided e-parameters are not used by Mobile Station if a call forwarding or follow-on call occurs.

11.29.1.1 Parameters

– sCIBillingChargingCharacteristics:
This parameter is a choice between two lists of information.

The first list shall be sent only if there is neither an active call leg, nor a Temporary Connection, nor a connection to a gsmSRF. It contains the following parameters:

– aOCBeforeAnswer:
This is a list of the following information:

– aOCInitial:
This is a set of Charge Advice Information (CAI) elements, as defined in 3GPP TS 22.024 [2] These CAI elements shall be sent by the gsmSSF to the MS when Answer is detected and a tariff switch for the "CSE control of e-parameters" has not yet occurred.

– aOCSubsequent:
This list may contain the following information:

– cAIElements:
This is a set of Charge Advice Information (CAI) elements, as defined in 3GPP TS 22.024 [2]. These CAI elements shall be sent to the MS when Answer is detected and a tariff switch for the "CSE control of e-parameters" has occurred previously, or when Answer has previously been detected and a tariff switch for the "CSE control of e-parameters" occurs.

– tariffSwitchInterval (for the "CSE control of e-parameters"):
This parameter indicates the time duration until the next tariff switch for the "CSE control of e-parameters". The measurement of the elapsed tariff switch period shall start immediately after successful execution of this operation.

The second list in the choice shall be sent only if there is an active call leg or a Temporary Connection or a connection to a gsmSRF. It contains the following parameters:

– aOCAfterAnswer:
This list may contain the following information:

– cAIElements:
This is a set of Charge Advice Information (CAI) elements, as defined in 3GPP TS 22.024 [2]. These CAI elements shall be sent to the MS by the gsmSSF when Answer is detected and a tariff switch for the "CSE control of e-parameters" has occurred previously, or when Answer has previously been detected and a tariff switch for the "CSE control of e-parameters" occurs.

– legID:
This parameter indicates where the charging information shall be sent. For Mobile Originated calls, only leg 1 shall be used. For Mobile Terminated calls in the VMSC, only the leg of the CAMEL subscriber shall be used.

11.29.2 Responding entity (gsmSSF)

11.29.2.1 Normal procedure

gsmSSF preconditions:

(1) The gsmSSF FSM is in one of the following states:

"Waiting_for_Instructions"; or
"Waiting_for_end_of_User_Interaction"; or
"Waiting_for_end_of_Temporary_Connection"; or
"Monitoring".

gsmSSF postconditions:

(1) No gsmSSF FSM state transition.

On receipt of this operation the gsmSSF performs actions to send the Advice of Charge information to the indicated Call Partys MS.

If Advice of Charge shall be provided to a MS in conjunction with "CSE control of call duration", then the following sequence of operations may be sent by the gsmSCF to the gsmSSF in the following order, in the same TC-CONTINUE TC message:

one or more ApplyCharging operations; SendChargingInformation operation.

These operations shall be processed sequentially by the gsmSSF, in the order that they are sent by the gsmSCF. In this case, the parameters TariffSwitchInterval (for the "CSE control of call duration") may be present in any of the ApplyCharging operations and the parameter TariffSwitchInterval (for the "CSE control of e-parameters") may be present in the SendChargingInformation operation.

The TariffSwitchInterval information received with the ApplyCharging operation shall set or overwrite the tariff switch timer for the "CSE control of call duration" in the gsmSSF and this duration timer shall run from the time of successful operation execution.

The TariffSwitchInterval information received in the SendChargingInformation operation shall set or overwrite the tariff switch timer for the "CSE control of e‑parameters" in the gsmSSF and this duration timer shall run from the time of successful operation execution.

11.29.2.2 Error handling

Generic error handling for the operation related errors are described in clause 10 and the TC services which are used for reporting operation errors are described in clause 14.

11.30 SpecializedResourceReport procedure

11.30.1 General description

The gsmSRF uses this operation as a response to a "PlayAnnouncement" operation or a "PromptAndCollectUserInformation" operation. This operation shall be used only when the "requestAnnouncementCompleteNotification" parameter is TRUE or the "requestAnnouncementStartedNotification" parameter is TRUE in the "PlayAnnouncement" operation or the "PromptAndCollectUserInformation".

11.30.1.1 Parameters

– allAnnouncementsComplete:
This parameter indicates that all the announcements and tones are complete.

– firstAnnouncementStarted:
This parameter indicates that the first announcement or tone has started.

11.30.2 Invoking entity (gsmSRF)

11.30.2.1 Normal procedure

gsmSRF preconditions:

(1) The gsmSRF FSM is in the state "User_Interaction".

(2) Either:

(i) The sending of announcments and tones as defined in the "PlayAnnouncement" operation or the "PromptAndCollectUserInformation" operation has started and the parameter "RequestAnnouncementStartedNotification" in the "PlayAnnouncement" or "PromptAndCollectUserInformation" operation is TRUE; or

(ii) A "PlayAnnouncement" operation has been executed, all announcements and tones have been sent and the parameter "RequestAnnouncementCompleteNotification" in the PlayAnnouncement" operation is TRUE.

gsmSRF postconditions:

(1) No gsmSRF FSM state transition.

(2) If the "DisconnectFromIPForbidden" parameter is FALSE, then the gsmSRF initiates a bearer channel disconnect sequence to the gsmSSF using the applicable bearer channel signalling system after sending the "SpecializedResourceReport" operation to the gsmSCF. The gsmSRF transits to the state "Idle".

11.30.2.2 Error handling

Operation related error handling is not applicable, due to class 4 operation.

11.31 SplitLeg Procedure

11.31.1 General Description

The gsmSCF uses this operation to request the gsmSSF to separate one party from the source Call Segment and place it in a new target Call Segment.

11.31.1.1 Parameters

– legToBeSplit:
This parameter indicates the party in the call to be split from the source Call Segment.

– newCallSegment:
This parameter indicates the CSID to be assigned to the newly-created Call Segment.

11.31.2 Responding entity (gsmSSF)

11.31.2.1 Normal procedure

gsmSSF preconditions:

A control relationship exists between the gsmSCF and the gsmSSF.
The CSID1 is either the source Call Segment or the target Call Segment.
When SplitLeg is used to move a leg into CSID1 (when CSID1 does not exist), then the BCSM for the leg to be split shall be in the alerting phase or in the active phase.

When SplitLeg is used to split a leg off from CSID1 into a new Call Segment, then the BCSM for the leg to be split shall be in the active phase.

User interaction is not in progress in the source Call Segment.

gsmSSF postconditions:

The gsmSSF performs the necessary actions to separate the specified leg from its original Call Segment and place it in a new target Call Segment.
The CS_gsmSSF FSM for the new Call Segment transits to the state "Waiting_for_Instructions".
The CS_gsmSSF FSM for the source Call Segment transits to the state "Waiting_for_Instructions".
The remaining BCSM instances within the source Call Segment transit to the O_Mid_Call DP or to the T_Mid_Call DP, unless already suspended at a DP. The Mid_Call EDP shall not be reported for this case.
A Return Result shall be sent to the gsmSCF immediately after successful execution of this operation.
A pending ApplyChargingReport for the source call segment shall be sent to the gsmSCF.

11.31.2.2 Error handling

Generic error handling for the operation related errors is described in clause 10, and the TC services which are used for reporting operation errors are described in clause 14.