4.5.7 Handling of mobile calls in the gsmSSF
23.0783GPPCustomised Applications for Mobile network Enhanced Logic (CAMEL) Phase 4Release 17Stage 2TS
Handling of mobile calls in the gsmSSF involves the following processes and procedures:
– Process CS_gsmSSF;
– Procedures and process Check_Criteria;
– Procedure Connect_To_Resource;
– Procedure Handle_AC;
– Procedure Handle_ACR;
– Procedure Handle_CIR;
– Procedure Handle_CIR_leg;
– Procedure Complete_FCI_record;
– Procedure Complete_all_FCI_records;
– Procedure Handle_SCI;
– Process CSA_gsmSSF;
– Procedure Handle_O_Answer;
– Procedure Handle_T_Answer.
The detailed error handling for the process CS_gsmSSF and the associated procedures is specified in 3GPP TS 29.078 ([36]).
4.5.7.1 Call duration control
4.5.7.1.1 Information flow for call duration control
The following diagram shows the handling of the different timers that are used in the process CS_gsmSSF and in the procedures Handle_AC, Handle_ACR, Handle_CIR. Timers Tssf, Tcp, Tsw, Tw and DELTA are defined in the process CS_gsmSSF.
Figure 4.96: Information flow for call control duration
The following diagram shows an example of the handling of call duration control for CPH configurations.
Figure 4.96a: Information flow for call control duration in CPH configurations
4.5.7.1.2 Audible indicators for call duration control
The gsmSCF may instruct the gsmSSF to play either a fixed sequence of tones or a variable sequence of tones with the Apply Charging information flow. The gsmSCF may also instruct the gsmSSF to play a variable sequence of tones with the Play Tone information flow.
For the case of the fixed sequence of tones, the gsmSSF shall play a single sequence of three tones. The duration of each of the tones shall be 200 milliseconds with an intertone interval of 200 milliseconds. This shall be played 30 seconds before the end of a call period. For the case of a variable sequence of tones, or a burst list, the gsmSCF shall indicate the number of tones per burst, the number of bursts to be played, the tone duration, interval between the tones and the interval between the bursts. In addition, the gsmSCF shall indicate in the Apply Charging information flow, the warning time before call period expiry at which the playing of the burst list shall start. Figure 4.97 provides a graphical representation of the variable burst list in the case where there are three tones per burst and three bursts in the burst list. The Warning Period in figure 4.97 applies to the Apply Charging information flow only.
Figure 4.97: Representation of burst list
4.5.7.2 The gsmSCF control of e‑values
4.5.7.2.1 Procedure Handle_SCI
There are independent Tariff Switch Timers for the control of the call duration Tsw(pty) and for the gsmSCF control of e‑values Tsw(SCI). The gsmSCF control of e‑values is via the Send Charging Information information flow.
The following terminology has been used for e‑parameters:
– Applicable and in use. The set of e‑parameters is currently applicable in the MSC and the set has been sent to the MS.
– Applicable but waiting. The set of e‑parameters is currently applicable in the MSC but the set has not yet been sent to the MS.
– Applicable but not in use. The set of e‑parameters is currently applicable in the MSC but it cannot be sent to the MS, e.g. because the Advice of Charge supplementary service is not subscribed.
– Stored. The set of e‑parameters is not yet applicable. The stored set of e‑parameters becomes applicable when a tariff switch occurs.
The table below defines the actions of the Procedure Handle_SCI.
Table 4.6: Handling of SCI in the gsmSSF
received Tsw(SCI) and set of e‑parameters in the SCI information flow |
Primary dialogue (note 1) |
Secondary dialogue (note 2, 8) |
||||
---|---|---|---|---|---|---|
no active call / SRF connection |
active call / SRF connection |
|||||
Tsw(SCI) not running and no e‑parameters stored |
Tsw(SCI) running and e‑parameters stored |
Tsw(SCI) not running and no e‑parameters stored |
Tsw(SCI) running and e‑parameters stored |
|||
Tsw(SCI) not received |
1 set |
send 1st set to MSC |
stop Tsw(SCI); discard stored set; |
send 1st set to MSC |
stop Tsw(SCI); discard stored set; |
send 1st set to MSC |
Tsw(SCI) not received |
2 sets |
error |
error |
error |
error |
error |
Tsw(SCI) received |
1 set |
error |
error |
store 1st set; |
stop Tsw(SCI); discard stored set; |
error |
Tsw(SCI) received |
2 sets |
send 1st set to MSC, |
stop Tsw(SCI); discard stored set; |
error |
error |
send 1st set to MSC; |
NOTE 1: Primary dialogue: The primary dialogue is initiated due to TDP Collected_Info, TDP Analysed_Information, or TDP Route_Select_Failure, TDP Terminating_Attempt_Authorised, TDP T_Busy or TDP T_No_Answer. A dialogue initiated due to TDP Analysed_Information is only the primary dialogue, if there is no ongoing dialogue due to TDP Collected_Info. NOTE 2: Secondary dialogue: The secondary dialogue is initiated due to TDP Analysed_Information. NOTE 3: The condition "active call / SRF connection" is true if there is at least one active leg in this call (CSA) or if an SRF is connected to a Call Segment in this CSA. Incoming legs are active after an answer is sent and before the leg begins to release. Outgoing legs are active after an answer is received and before the leg is begins to release. NOTE 4: If the gsmSSF sends a set of e‑parameters to the MSC this will overwrite the current set of e‑parameters in the MSC, if e‑parameters are applicable in the MSC. NOTE 5: The MSC shall store the received e‑parameters to be sent subsequently to the MS. The MSC shall send these e‑parameters to the MS in a Connect message or in a Facility message. NOTE 6: Secondary dialogue gsmSCF can only give e‑parameter(s)/Tsw(SCI) when they have not previously been provided by the primary dialogue gsmSCF. After secondary dialogue gsmSCF gives e‑parameter(s) / Tsw(SCI), Primary dialogue gsmSCF shall not give further on-line charging instructions (i.e. Send Charging Information). For D‑CSI, this is ensured by service subscription restriction by a home network operator. For N‑CSI, this is ensured by a roaming agreement between the home network operator and the visited network operator or is only applicable within a home network. NOTE 7: When a gsmSCF relationship is closed then the stored e‑parameters given by that dialogue are discarded. Any Tariff Switch timer (Tsw(SCI)) is also stopped when the gsmSCF relationship is closed. If the gsmSCF has given any e‑parameters which are not stored but which are applicable (regardless of whether they are applicable and in use, applicable but waiting, or applicable but not in use) when the gsmSCF relationship is closed, those e‑parameters are also valid after the gsmSCF relationship is closed. If any subsequent CAP dialogues give e‑parameters those new e‑parameters shall overwrite the applicable e‑parameters given by the preceding CAP dialogues. NOTE 8: The secondary dialogue is not applicable to VT calls. NOTE 9: Service Logic designers shall take care when using SCI in both primary dialogue and secondary dialogue, if these dialogues use different versions of CAMEL. In such a case it is e.g. possible that a Tariff Switch timer (Tsw(SCI)) information received in the primary dialogue is overwritten by a Tariff Switch timer (Tsw(SCI)) information received in the secondary dialogue. |
4.5.7.2.2 Process Tsw_For_SCI
The process Tsw_For_SCI exists per call. That is there is one process instance per CSA. The Tariff Switch Timers for the gsmSCF control of e‑values Tsw(SCI).
Figure 4.98-1: Process Tsw_For_SCI (sheet 1)
Figure 4.98-2: Process Tsw_For_SCI (sheet 2)
4.5.7.3 Behaviour of the gsmSSF in the process CS_gsmSSF
The following paragraphs give details on the behaviour of the gsmSSF in the process CS_gsmSSF.
4.5.7.3.1 Actions of the gsmSSF on receipt of CAP_Request_Report_BCSM_Event (in the state Waiting_For_Instructions)
The process CS_gsmSSF arms the requested EDP, if the arming rules are fulfilled and returns to the state Waiting_For_Instructions.
The gsmSCF may request EDPs for any one or more of Answer, Busy, No Answer, Abandon, Route Select Failure and Disconnect event for a party in the call.
4.5.7.3.2 Actions of the gsmSSF on receipt of CAP_Continue (in the state Waiting_For_Instructions)
An Int_Continue signal is sent to instruct the GMSC or MSC to continue the call set-up with the original call parameters.
4.5.7.3.3 Actions of the gsmSSF on receipt of CAP_Release_Call (in the state Monitoring)
When a control relationship exists between the gsmSCF and gsmSSF (at least one EDP‑R is armed), the gsmSCF may spontaneously instruct the gsmSSF to release the call at any time using the Release Call information flow. The Release Call information flow shall not be sent from the gsmSCF if only monitor relationship exists between the gsmSSF and the gsmSCF.
4.5.7.3.4 Actions of the gsmSSF on receipt of Int_DP_T_Busy or Int_DP_T_No_Answer including the parameter Call Forwarded (in the state Monitoring)
If the handling of Int_DP_T_Busy signal or Int_DP_T_No_Answer signal including the parameter Call Forwarded leads to the gsmSSF sending a CAP_Event_Report_BCSM to the gsmSCF, the gsmSSF shall include the parameter Call Forwarded in the Event Specific Information BCSM.
4.5.7.4 Outstanding Request Counter and Rules for CAMEL
In the following the rules on handling of the ‘outstanding requests’ variables in the process CS_gsmSSF are given. They are storing the number of required resumptions.
1) There shall be one outstanding requests variable ORC_Leg (legID) per leg to handle TDP‑R and EDP‑R reports and ICA.
2) In addition there shall be one outstanding requests variable ORC_CS (CSID) per call segment to handle the CPH IFs.
3) A leg will only be resumed if the ORC_Leg (legID) variable for this leg and the ORC_CS (CSID) for the call segment containing the leg are 0.
4) Events that cause the suspension of the call processing are signalling events armed as TDP‑Rs or EDP‑Rs, or the processing of a CPH IF (Disconnect Leg, Split Leg or Move Leg) or Initiate Call Attempt sent by the gsmSCF.
a) For TDP‑R or EDP‑R events the number of required resumptions relative to the associated leg will be incremented by 1. For TDP-R, the associated leg is always leg 2.
b) For CPH IFs the number of required resumptions per call segment will be set to one if it is still 0. Otherwise the number of resumptions remains unchanged. For Split Leg the number of required resumptions for each of the source call segment and the target call segment will be set to one if it is still 0
c) For ICA the number of required resumptions relative to the associated leg will be set to 1.
5) In addition the CS_gsmSSF stores information about the events (DP with the associated leg, CPH) that require resumption and keep track of the order of events for TDP‑Rs and EDP‑Rs for each leg . The order of resumptions for a leg shall be the order in which the suspension events occured for that leg.
6) For DP event resumption Continue with Argument with legID or Continue are valid. If not otherwise stated below, for each received resumption the number of required resumption for that leg will be decremented by 1 if it was a valid resumption for the event that has to be handled first. Decrementing of the outstanding requests variables does not go below 0.
7) For CPH resumption Continue with Argument with CSID is valid. On receipt of the resumption the number of required resumptions for that call segment will be set to 0.
8) For ICA resumption Continue with Argument with LegId is valid. On receipt of the resumption the number of required resumptions for that Leg will be set to 0.
9) If Continue with Argument with neither LegID nor CSID is received, then the number of resumptions required for the leg that was reported will be decremented by 1. If reporting is performed on more than one leg, then the related leg will be selected following the sequence of the reporting.
10) If Continue is received, then the number of resumptions required for the leg that was reported will be decremented by 1. If reporting is performed on more than one leg, then the related leg will be selected following the sequence of the reporting.
11) The processing of a Connect with a LegID causes the number of required resumptions for that leg to be decremented by 1. The processing of a Connect without a LegID causes the number of resumptions for the LegID = 2 to be set to 0.
12) The processing of Tssf expiry and of TC Abort causes the number of resumptions required to be set to 0 and the call processing to be resumed. All stored resumption events are discarded.
13) On receipt of a Disconnect Leg the number of resumptions required for the corresponding leg is set to 0.
14) If Release Call is used, nothing needs to be resumed.
4.5.7.5 Process CS_gsmSSF and procedures
Figure 4.99-1: Process CS_gsmSSF (sheet 1)
Figure 4.99-2: Process CS_gsmSSF (sheet 2)
Figure 4.99-3: Process CS_gsmSSF (sheet 3)
Figure 4.99-4: Process CS_gsmSSF (sheet 4)
Figure 4.99-5: Process CS_gsmSSF (sheet 5)
Figure 4.99-6: Process CS_gsmSSF (sheet 6)
Figure 4.99-7: Process CS_gsmSSF (sheet 7)
Figure 4.99-8: Process CS_gsmSSF (sheet 8)
Figure 4.99-9: Process CS_gsmSSF (sheet 9)
Figure 4.99-10: Process CS_gsmSSF (sheet 10)
Figure 4.99-11: Process CS_gsmSSF (sheet 11)
Figure 4.99-12: Process CS_gsmSSF (sheet 12)
Figure 4.99-13: Process CS_gsmSSF (sheet 13)
Figure 4.99-14: Process CS_gsmSSF (sheet 14)
Figure 4.99-15: Process CS_gsmSSF (sheet 15)
Figure 4.99-16: Process CS_gsmSSF (sheet 16)
Figure 4.99-17: Process CS_gsmSSF (sheet 17)
Figure 4.99-18: Process CS_gsmSSF (sheet 18)
Figure 4.99-19: Process CS_gsmSSF (sheet 19)
Figure 4.99-20: Process CS_gsmSSF (sheet 20)
Figure 4.99-21: Process CS_gsmSSF (sheet 21)
Figure 4.99-21A: Process CS_gsmSSF (sheet 21A)
Figure 4.99-22: Process CS_gsmSSF (sheet 22)
Figure 4.99-23: Process CS_gsmSSF (sheet 23)
Figure 4.99-24: Process CS_gsmSSF (sheet 24)
Figure 4.99-25: Process CS_gsmSSF (sheet 25)
Figure 4.99-26: Process CS_gsmSSF (sheet 26)
Figure 4.99-27: Process CS_gsmSSF (sheet 27)
Figure 4.99-28: Process CS_gsmSSF (sheet 28)
Figure 4.99-29: Process CS_gsmSSF (sheet 29)
Figure 4.99-29a: Process CS_gsmSSF (sheet 29a)
Figure 4.99-30: Process CS_gsmSSF (sheet 30)
Figure 4.99-31: Process CS_gsmSSF (sheet 31)
Figure 4.99-32: Process CS_gsmSSF (sheet 32)
Figure 4.99-33: Process CS_gsmSSF (sheet 33)
Figure 4.99-34: Process CS_gsmSSF (sheet 34)
Figure 4.99-35: Process CS_gsmSSF (sheet 35)
Figure 4.99-36: Process CS_gsmSSF (sheet 36)
Figure 4.99-37: Process CS_gsmSSF (sheet 37)
Figure 4.99-38: Process CS_gsmSSF (sheet 38)
Figure 4.99-39: Process CS_gsmSSF (sheet 39)
Figure 4.99-40: Process CS_gsmSSF (sheet 40)
Figure 4.99-41: Process CS_gsmSSF (sheet 41)
Figure 4.99-42: Process CS_gsmSSF (sheet 42)
Figure 4.99-43: Process CS_gsmSSF (sheet 43)
Figure 4.99-44: Process CS_gsmSSF (sheet 44)
Figure 4.99-45: Process CS_gsmSSF (sheet 45)
Figure 4.99-46: Process CS_gsmSSF (sheet 46)
Figure 4.99-47: Process CS_gsmSSF (sheet 47)
Figure 4.99-48: Process CS_gsmSSF (sheet 48)
Figure 4.99-49: Process CS_gsmSSF (sheet 49)
Figure 4.99-50: Process CS_gsmSSF (sheet 50)
Figure 4.99-51: Process CS_gsmSSF (sheet 51)
Figure 4.99-52: Process CS_gsmSSF (sheet 52)
Figure 4.99-53: Process CS_gsmSSF (sheet 53)
Figure 4.99-54: Process CS_gsmSSF (sheet 54)
Figure 4.99-55: Process CS_gsmSSF (sheet 55)
Figure 4.99-56: Process CS_gsmSSF (sheet 56)
Figure 4.99-57: Process CS_gsmSSF (sheet 57)
Figure 4.99-58: Process CS_gsmSSF (sheet 58)
Figure 4.99-59: Process CS_gsmSSF (sheet 59)
Figure 4.99-60: Process CS_gsmSSF (sheet 60)
Figure 4.99-61: Process CS_gsmSSF (sheet 61)
Figure 4.99-62: Process CS_gsmSSF (sheet 62)
Figure 4.100-1: Procedure Check_Criteria_Collected_Info (sheet 1)
Figure 4.101-1: Procedure Check_Criteria_Analysed_Info (sheet 1)
Figure 4.102-1: Procedure Check_Criteria_Unsuccessful (sheet 1)
Figure 4.103-1: Procedure Connect_To_Resource (sheet 1)
Figure 4.104-1: Procedure Handle_AC (sheet 1)
Figure 4.105-1: Procedure Handle_ACR (sheet 1)
Figure 4.106-1: Procedure Handle_CIR (sheet 1)
Figure 4.107-1: Procedure Handle_CIR_leg (sheet 1)
Figure 4.108-1: Procedure Complete_FCI_record (sheet 1)
Figure 4.109-1: Procedure Complete_all_FCI_records (sheet 1)
Figure 4.110-1: Procedure Handle_O_Answer (sheet 1)
Figure 4.111-1: Procedure Handle_T_Answer (sheet 1)
Figure 4.112-1: Procedure UpdateSignalling (sheet 1)
4.5.7.6 Process gsmSSF_SSME_FSM and procedures
One process is instantiated for each Call Gap information flow received from a gsmSCF.
Figure 4.113-1: Process gsm_SSME_SSF (sheet 1)
Figure 4.113-2: Process gsm_SSME_SSF (sheet 2)
NOTE: CG Int and CG Reject internal variables are initiated with False value.
Figure 4.114-1: Procedure Store_Call_Gap_Criteria (sheet 1)
Figure 4.115-1: Procedure Check_Gap_Criteria (sheet 1)
Figure 4.115A-1: Procedure Check_Criteria_for_TOC (sheet 1)
4.5.7.7 Process CSA_gsmSSF and procedures
The call gap information flow can only be received for an opened transaction between the CSA_gsmSSF and the gsmSCF.
Figure 4.116-1: Process CSA_gsmSSF (sheet 1)
Figure 4.116-2: Process CSA_gsmSSF (sheet 2)
Figure 4.116-3: Process CSA_gsmSSF (sheet 3)
Figure 4.116-4: Process CSA_gsmSSF (sheet 4)
Figure 4.116-5: Process CSA_gsmSSF (sheet 5)
Figure 4.116-6: Process CSA_gsmSSF (sheet 6)
Figure 4.116-7: Process CSA_gsmSSF (sheet 7)
Figure 4.116-8: Process CSA_gsmSSF (sheet 8)
Figure 4.116-9: Process CSA_gsmSSF (sheet 9)
Figure 4.116-10: Process CSA_gsmSSF (sheet 10)
Figure 4.116-11: Process CSA_gsmSSF (sheet 11)
Figure 4.116-12: Process CSA_gsmSSF (sheet 12)
Figure 4.116-13: Process CSA_gsmSSF (sheet 13)
Figure 4.116-14: Process CSA_gsmSSF (sheet 14)
Figure 4.116-15: Process CSA_gsmSSF (sheet 15)
Figure 4.116-16: Process CSA_gsmSSF (sheet 16)
Figure 4.116-17: Process CSA_gsmSSF (sheet 17)
Figure 4.116-18: Process CSA_gsmSSF (sheet 18)
Figure 4.116-19: Process CSA_gsmSSF (sheet 19)
Figure 4.116-20: Process CSA_gsmSSF (sheet 20)
Figure 4.116-21: Process CSA_gsmSSF (sheet 21)
Figure 4.116-22: Process CSA_gsmSSF (sheet 22)
Figure 4.116-23: Process CSA_gsmSSF (sheet 23)