4.6.1 Overall SDL Architecture

23.2783GPPCustomised Applications for Mobile network Enhanced Logic (CAMEL) Phase 4IM CN InterworkingRelease 17Stage 2TS

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

Figure 4.6: SIP Registration into IM‑SSF

Figure 4.7: Originating Case

Figure 4.8: Terminating Case

4.6.1.1 Handling of Registration and De-registration in the IM‑SSF

During the UE registration, the HSS shall send the filter criteria for the IM‑SSF to the S‑CSCF if the subscriber is provisioned with IP Multimedia CAMEL Subscription Information data at the HSS.

– The HSS shall include the IMSI data for the subscriber within the Service Information element of the filter criteria for IM‑SSF. The IMSI shall be used for querying the HSS for CAMEL Subscription Information data via a MAP interface.

The CAMEL service provider determines the actual format of the data sent within the Service Information element of the filter criteria (e.g. IMSI). The actual format is transparent to the S‑CSCF i.e. CAMEL service information is not processed, analysed, or evaluated by the S‑CSCF. It is, however, known to the IM‑SSF, gsmSCF, and the HSS (for provisioning of the service information data).

If a registration/de-registration request matches the filter criteria of the IM‑SSF, the S‑CSCF informs the IM‑SSF of the request by performing a third party registration/de-registration i.e. a SIP REGISTER message is sent from the S‑CSCF to the IM‑SSF.

General handling of IP Multimedia registration, re-registration, de-registration and receipt of initial filter criteria at the S‑CSCF is specified in 3GPP TS 23.228 [6] and 23.218 [5].

The process and the procedures specific to CAMEL are specified in this clause:

– Process Register_IM_SSF;

– Procedure CAMEL_IMCN_Register;

– Procedure CAMEL_IMCN_DeRegister.

4.6.1.1.1 Procedure CAMEL_IMCN_Register

When querying the HSS for the subscriber’s IM CSI data, the IM‑SSF does not have to wait for the HSS’s response on the first query before the subsequent queries are done. i.e Sending of multiple Any Time Interrogation operations can be done in parallel. However, the IM‑SSF shall wait for all the responses from the HSS before it shall send a SIP response message to the S‑CSCF.

Figure 4.9: Process Register_IM_SSF (sheet 1)

Figure 4.10: Procedure CAMEL_IMCN_Register (sheet 1)

Figure 4.11: Procedure CAMEL_IMCN_DeRegister (sheet 1)

4.6.1.2 Handling of Notify Subscriber Data Change

When the HSS updates the CSI for a subscriber in the IP Multimedia CN subsystem, the HSS shall send a Notify Subscriber Data Change to the IM‑SSF if all of the following conditions are true:

– The IM CSI data is marked with the Notification Flag

– The IM‑SSF address is included in the gsmSCF address list

The IM‑SSF address shall be added in the gsmSCF address list at the HSS for notification of IM‑CSI updates if one of the following conditions occurs:

a. The HSS is notified of the subscriber’s registration at the S‑CSCF (via Cx interface), and the subscriber is provisioned with IM CSI data.

b. Operator provisions HSS subscriber data with IMS CAMEL service while the subscriber is currently registered in the IMS network i.e. one or more IM CSI data is added to the subscriber’s profile in the HSS.

c. The HSS is notified of mobile termination for an unregistered subscriber (via Cx interface), and the subscriber is provisioned with IM CSI data

The IM‑SSF address shall be deleted from the gsmSCF address list when the HSS initiates, or is notified of, the UE’s deregistration.

The IM‑SSF address in the gsmSCF address list may be changed when the HSS receives a notification of a registration for a UE with a S‑CSCF name different from the previously assigned S‑CSCF name (i.e. re-registration from HSS point of view). The HSS shall overwrite the existing IM‑SSF address with the IM‑SSF address associated with the new S‑CSCF name.

The HSS procedure for sending the Notify Subscriber Data Change to the IM‑SSF is the same procedure used for notifying the gsmSCFs in the Circuit Switched CN. This procedure is described in Procedure CAMEL_NSDC_HLR specified in 3GPP TS 23.078 Rel‑99[4].

The process specific to IM‑SSF’s handling of the Notify Subscriber Data Change is specified in this clause:

– Process Update_CSI

Figure 4.12: Process Update_CSI (sheet 1)

4.6.1.3 Handling of Mobile Originated Calls in the IM‑SSF

The functional behaviour of the S‑CSCF is specified in 3GPP TS 23.218 [5]. The process and the procedures specific to CAMEL are specified in this clause:

– Process MO_IM_SSF;

– Procedure CAMEL_IMCN_MO_O_IM_CSI_INIT;

– Procedure CAMEL_IMCN_MO_D_IM_CSI_INIT;

– Procedure CAMEL_IMCN_MO_CANCEL;

– Procedure CAMEL_IMCN_MO_ANSWER;

– Procedure CAMEL_IMCN_MO_UNSUCCESSFUL;

– Procedure CAMEL_IMCN_MO_DISC1;

– Procedure CAMEL_IMCN_MO_DISC2;

– Procedure CAMEL_OCH_CTR.

Internal interface indicated with the "Int_SRF_" prefix within this clause indicates internal interface with the MRFC.

4.6.1.3.1 Actions of the IM‑SSF on receipt of Int_Error

The IM‑SSF checks the default Call Handling parameter in the relevant CSI.

If the default call handling is release, a BYE indication is sent to the MS. The IM‑SSF then releases all resources and the invoked CAMEL procedure ends.

If the call handling is continue, the IM‑SSF continues processing without CAMEL support.

4.6.1.3.2 Actions of the IM‑SSF on receipt of Int_Continue

The IM‑SSF continues processing without any modification of call parameters.

4.6.1.3.3 Actions of the IM‑SSF on receipt of Int_Continue_With_Argument

The IM‑SSF continues processing with modified call parameters. The IM‑SSF shall modify the call parameters by the information received in the Int_Continue_With_Argument message. Call parameters that are not included in the Int_Continue_With_Argument_Message are unchanged.

4.6.1.3.4 Actions of the IM‑SSF on receipt of Int_Connect

The IM-SSF continues processing with modified call parameters. The IM‑SSF shall transparently modify the call parameters with the received information. Call parameters, which are not included in the Int_Connect message, are unchanged.

4.6.1.3.5 Actions of the IM‑SSF on receipt of Int_Release_Call

A BYE is sent to the MS, and a BYE is sent to the destination CSCF. The release cause received in the Int_Release_Call is used. The IM‑SSF then releases all call resources and all CAMEL processing ends.

4.6.1.3.6 Handling of procedure CAMEL_OCH_CTR, sheet 1

The IM‑SSF behaves as a B2BUA (Back‑2‑Back User Agent) when a SIP INVITE is received for an outgoing call and SIP INVITE is sent to the MRFC (via S‑CSCF) as a result of a CAP ConnectToResource request received from the SCF.

A SIP response 100 Trying is sent after each INVITE but is not shown in the SDLs.

The IM‑SSF shall handle the 200 OK response from the MRFC as specified in 3GPP TS 23.218 [5].

4.6.1.3.7 Handling of procedure CAMEL_OCH_CTR, sheet 5

The specifics on transporting information between the MRFC and the Application Server such as the IM-SSF, has not been standardised in 3GPP Rel‑5 specifications for IMS. i.e. the SIP method to return the Prompt_and_Collect result from the MRFC to the IM‑SSF, the SIP method for sending notification of play announcement completion to the IM‑SSF when a request for a Specialised Resource Report was received, the SIP method to request the MRFC to play announcement and the SIP method to request the MRFC to prompt and collect user information, are not standardised.

4.6.1.3.8 Receipt of 100 Trying Provisional Response (Process MO_IM_SSF)

The IM-SSF (acting as B2BUA) uses the S-CSCF as the next-hop server when sending the SIP INVITE to the destination S-CSCF. The 100 Trying provisional response received in the IM-SSF is actually generated and sent from the S-CSCF to indicate that the INVITE request has been received by the next-hop server (i.e. the S-CSCF) and is currently being processed.

4.6.1.3.9 Handling of internal timers in Process MO_IM_SSF

The SIP B timer defined in 3GPP TS 24.229 [8] is used for IM-SSF handling of no response condition for an INVITE request, similar to the Circuit Switched handling of TNRy Timer for No Reply. The use of B timer in the IM-SSF is indicated in the SDL Process MO_IM_SSF. There are other SIP timers defined in 3GPP TS 24.229 [8] that are not specified in the SDLs for IM-SSF processing. The usage of these timers is based on the network’s implementation of the IM-SSF (e.g. choice of UDP or TCP for transport of SIP, and how IM-SSF operates as both a UAS and a UAC – i.e. back-to-back UA).

The following clauses provide additional information on Process MO_IM_SSF’s handling of the internal timers:

Sheets 1-2: The inclusion of Expires header field in the INVITE method is optional and is used to indicate the duration of the invitation in seconds. When the timer fires before a final response is generated by the IM-SSF, the INVITE message is considered to be "expired". The IM-SSF shall report a call abandon event to the gsmSCF if requested and return a 487 Request Terminated to the originating S-CSCF.

When the IM-SSF (taking the role of a UAC) sends out the INVITE request, the B timer (i.e. Tb timer) shall be used for the INVITE transaction timeout timer. Refer to 3GPP TS 24.229 [8] for the recommended B timer value.

Sheet 3: When the IM-SSF (taking the role of a UAS) sends the 200 OK final response to the S-CSCF that sent the INVITE request, the IM-SSF shall start the Tack timer to monitor the receipt of the ACK request. Refer to 3GPP TS 24.229 [8] for the recommended ACK timer value.

Sheet 4: The expiration of Tb timer shall be reported as a no answer event to the gsmSCF if requested. If the Tinvite timer expires, the IM-SSF shall report a call abandon event to the gsmSCF if requested.

Sheet 5: The expiration of the Tack shall be reported to the gsmSCF as a call disconnect from the originating party if requested.

Figure 4.13-1: Process MO_IM_SSF (sheet 1)

Figure 4.13-2: Process MO_IM_SSF (sheet 2)

Figure 4.13-3: Process MO_IM_SSF (sheet 3)

Figure 4.13-4: Process MO_IM_SSF (sheet 4)

Figure 4.13-5: Process MO_IM_SSF (sheet 5)

Figure 4.13-6: Process MO_IM_SSF (sheet 6)

Figure 4.14-1: Procedure CAMEL_IMCN_MO_ O_IM_CSI_INIT (sheet 1)

Figure 4.14-2: Procedure CAMEL_IMCN_MO_O_IM_CSI_INIT (sheet 2)

Figure 4.14-3: Procedure CAMEL_IMCN_MO_O_IM_CSI_INIT (sheet 3)

Figure 4.15-1: Procedure CAMEL_IMCN_MO_D_IM_CSI_INIT (sheet 1)

Figure 4.15-2: Procedure CAMEL_IMCN_MO_D_IM_CSI_INIT (sheet 2)

Figure 4.15-3: Procedure CAMEL_IMCN_MO_D_IM_CSI_INIT (sheet 3)

Figure 4.16: Procedure CAMEL_IMCN_MO_CANCEL (sheet 1)

Figure 4.17‑1: Procedure CAMEL_IMCN_MO_ANSWER (sheet 1)

Figure 4.17‑2: Procedure CAMEL_IMCN_MO_ANSWER (sheet 2)

Figure 4.18‑1: Procedure CAMEL_IMCN_MO_UNSUCCESSFUL (sheet 1)

Figure 4.18‑2: Procedure CAMEL_IMCN_MO_UNSUCCESSFUL (sheet 2)

Figure 4.18‑3: Procedure CAMEL_IMCN_MO_UNSUCCESSFUL (sheet 3)

Figure 4.18‑4: Procedure CAMEL_IMCN_MO_UNSUCCESSFUL (sheet 4)

Figure 4.18‑5: Procedure CAMEL_IMCN_MO_UNSUCCESSFUL (sheet 5)

Figure 4.18‑6: Procedure CAMEL_IMCN_MO_UNSUCCESSFUL (sheet 6)

Figure 4.19: Procedure CAMEL_IMCN_MO_DISC1 (sheet 1)

Figure 4.20‑1: Procedure CAMEL_IMCN_MO_DISC2 (sheet 1)

Figure 4.20‑2: Procedure CAMEL_IMCN_MO_DISC2 (sheet 2)

Figure 4.21-1: Procedure CAMEL_OCH_CTR (sheet 1)

Figure 4.21-2: Procedure CAMEL_OCH_CTR (sheet 2)

Figure 4.21-3: Procedure CAMEL_OCH_CTR (sheet 3)

Figure 4.21-4: Procedure CAMEL_OCH_CTR (sheet 4)

Figure 4.21-5: Procedure CAMEL_OCH_CTR (sheet 5)

4.6.1.4 Handling of Mobile Terminated IP Multimedia sessions in the IM‑SSF

The functional behaviour of the S‑CSCF for handling terminating calls is specified in 3GPP TS 23.218[5].The process and the procedures specific to CAMEL are specified in this clause:

– Process MT_IM_SSF;

– Procedure Check_Registration;

– Procedure CAMEL_IMCN_MT_VT_IM_CSI_INIT;

– Procedure CAMEL_IMCN_MT_RECONNECT;

– Procedure CAMEL_IMCN_MT_CANCEL;

– Procedure CAMEL_IMCN_MT_ANSWER;

– Procedure CAMEL_IMCN_MT_UNSUCCESSFUL;

– Procedure CAMEL_IMCN_MT_DISC1;

– Procedure CAMEL_IMCN_MT_DISC2;

– Procedure CAMEL_CAMEL_MT_CTR.

Internal interface indicated with the "Int_SRF_" prefix within this clause indicates internal interface with the MRFC.

4.6.1.4.1 Actions of the IM‑SSF on receipt of Int_Error

The IM‑SSF checks the default Call Handling parameter in the relevant CSI.

If the default call handling is release, a BYE indication is sent to the originating CSCF. The IM‑SSF then releases all resources and the invoked CAMEL procedure ends.

If the call handling is continue, the IM‑SSF continues processing without CAMEL support.

4.6.1.4.2 Actions of the IM‑SSF on receipt of Int_Release_Call

The IM‑SSF BYE message is sent to the originating CSCF and resources are released.

4.6.1.4.3 Actions of the IM‑SSF on receipt of Int_Continue_With_Argument

The IM‑SSF shall replace the call parameters by the information received in the Int_Continue_With_Argument message. Call parameters that are not included in the Int_Continue_With_Argument_Message are unchanged.

4.6.1.4.4 Actions of IM‑SSF in procedure CAMEL_IMCN_MT_INVITE for Unregistered Subscriber

When querying the HSS for the subscriber’s IM CSI data, the IM^‑SSF does not have to wait for the HSS’s response on the first query before the subsequent queries are done. i.e. Sending of multiple Any Time Interrogation operations can be done in parallel. However, the IM‑SSF shall wait for all the responses from the HSS before it shall continue with the handling of the terminating IP multimedia session.

4.6.1.4.5 Handling of procedure CAMEL_MT_CTR, sheet 1

The IM‑SSF behaves as a B2BUA (Back‑2‑Back User Agent) when a SIP INVITE is received for an terminating call and SIP INVITE is sent to the MRFC (via S‑CSCF) as a result of a CAP ConnectToResource request received from the SCF.

A SIP response 100 Trying is sent after each INVITE but is not shown in the SDLs.

The IM‑SSF shall handle the 200 OK response from the MRFC as specified in 3GPP TS 23.218 [5].

4.6.1.4.6 Handling of procedure CAMEL_MT_CTR, sheet 5

The specifics on transporting information between the MRFC and the Application Server such as the IM‑SSF, has not been standardised in 3GPP Rel‑5 specifications for IMS. i.e. the SIP method to return Prompt_And_Collect result from the MRFC to the IM‑SSF, the SIP method for sending notification of play announcement completion to the IM‑SSF when a request for a Specialised Resource Report was received, the SIP method to request the MRFC to play announcement and the SIP method to request the MRFC to prompt and collect user information, are not standardised.

4.6.1.4.7 Receipt of 100 Trying Provisional Response (Process MT_IM_SSF)

The IM-SSF (acting as a B2BUA) uses the S-CSCF as a next-hop server when sending the SIP INVITE to the terminating subscriber. The 100 Trying provisional response received in the IM-SSF is actually generated and sent from the S-CSCF to indicate that the INVITE request has been received by the next-hop server (i.e. the S-CSCF) and is currently being processed.

4.6.1.4.8 Handling of internal timers in Process MT_IM_SSF

For additional description on usage of internal timers in Process MT_IM_SSF, please refer to the description in clause 4.6.1.3.9.

Figure 4.22-1: Process MT_IM_SSF (sheet 1)

Figure 4.22-2: Process MT_IM_SSF (sheet 2)

Figure 4.22-3: Process MT_IM_SSF (sheet 3)

Figure 4.22-4: Process MT_IM_SSF (sheet 4)

Figure 4.22-5: Process MT_IM_SSF (sheet 5)

Figure 4.22-6: Process MT_IM_SSF (sheet 6)

Figure 4.23: Procedure Check_Registration (sheet 1)

Figure 4.24-1: Procedure CAMEL_IMCN_MT_VT_IM_CSI_INIT (sheet 1)

Figure 4.24-2: Procedure CAMEL_IMCN_MT_VT_IM_CSI_INIT (sheet 2)

Figure 4.24-3: Procedure CAMEL_IMCN_MT_VT_IM_CSI_INIT (sheet 3)

Figure 4.25: Procedure CAMEL_IMCN_MT_RECONNECT (sheet 1)

Figure 4.26: Procedure CAMEL_IMCN_MT_CANCEL (sheet 1)

Figure 4.27-1: Procedure CAMEL_IMCN_MT_ANSWER (sheet 1)

Figure 4.27-2: Procedure CAMEL_IMCN_MT_ANSWER (sheet 2)

Figure 4.28-1: Procedure CAMEL_IMCN_MT_UNSUCCESSFUL (sheet 1)

Figure 4.28-2: Procedure CAMEL_IMCN_MT_UNSUCCESSFUL (sheet 2)

Figure 4.28-3: Procedure CAMEL_IMCN_MT_UNSUCCESSFUL (sheet 3)

Figure 4.28-4: Procedure CAMEL_IMCN_MT_UNSUCCESSFUL (sheet 4)

Figure 4.28-5: Procedure CAMEL_IMCN_MT_UNSUCCESSFUL (sheet 5)

Figure 4.29: Procedure CAMEL_IMCN_MT_DISC1 (sheet 1)

Figure 4.30-1: Procedure CAMEL_IMCN_MT_DISC2 (sheet 1)

Figure 4.30-2: Procedure CAMEL_IMCN_MT_DISC2 (sheet 2)

Figure 4.31: Procedure CAMEL_Start_TNRy (sheet 1)

Figure 4.32: Procedure CAMEL_Stop_TNRy (sheet 1)

Figure 4.33-1: Procedure CAMEL_MT_CTR (sheet 1)

Figure 4.33-2: Procedure CAMEL_MT_CTR (sheet 2)

Figure 4.33-3: Procedure CAMEL_MT_CTR (sheet 3)

Figure 4.33-4: Procedure CAMEL_MT_CTR (sheet 4)

Figure 4.33-5: Procedure CAMEL_MT_CTR (sheet 5)

4.6.1.5 Handling of call in the imcnSSF

Handling of mobile calls in the imcnSSF may involve the following process and procedures:

– Process imcnSSF;

Note that the following procedures are specified in 3GPP TS 23.078 Rel-99 [4]. For these procedures, the imcnSSF shall take the role of the gsmSSF.

– Procedure Check_Criteria_Collected_Info;

– Procedure Check_Criteria_Analysed_Info;

– Procedure Check_Criteria_Unsuccessful;

– 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_O_Answer;

– Procedure Handle_T_Answer.

The detailed error handling for the process imcnSSF and the associated procedures is specified in 3GPP TS 29.278 [11].

4.6.1.5.1 Process imcnSSF

Figure 4.34-1: Process imcnSSF (sheet 1)

Figure 4.34-2: Process imcnSSF (sheet 2)

Figure 4.34-3: Process imcnSSF (sheet 3)

Figure 4.34-4: Process imcnSSF (sheet 4)

Figure 4.34-5: Process imcnSSF (sheet 5)

Figure 4.34-6: Process imcnSSF (sheet 6)

Figure 4.34-7: Process imcnSSF (sheet 7)

Figure 4.34-8: Process imcnSSF (sheet 8)

Figure 4.34-9: Process imcnSSF (sheet 9)

Figure 4.34-10: Process imcnSSF (sheet 10)

Figure 4.34-11: Process imcnSSF (sheet 11)

Figure 4.34-12: Process imcnSSF (sheet 12)

Figure 4.34-13: Process imcnSSF (sheet 13)

Figure 4.34-14: Process imcnSSF (sheet 14)

Figure 4.34-15: Process imcnSSF (sheet 15)

Figure 4.34-16: Process imcnSSF (sheet 16)

Figure 4.34-17: Process imcnSSF (sheet 17)

Figure 4.34-18: Process imcnSSF (sheet 18)

Figure 4.34-19: Process imcnSSF (sheet 19)

Figure 4.34-20: Process imcnSSF (sheet 20)

Figure 4.34-21: Process imcnSSF (sheet 21)

Figure 4.34-22: Process imcnSSF (sheet 22)

Figure 4.34-23: Process imcnSSF (sheet 23)

Figure 4.34-24: Process imcnSSF (sheet 24)

Figure 4.34-25: Process imcnSSF (sheet 25)

Figure 4.34-26: Process imcnSSF (sheet 26)

Figure 4.34-27: Process imcnSSF (sheet 27)

Figure 4.34-28: Process imcnSSF (sheet 28)

Figure 4.34-29: Process imcnSSF (sheet 29)

Figure 4.34-30: Process imcnSSF (sheet 30)

4.6.1.6 Process imcn_SSME_SSF and procedures

One process is instantiated at the IM-SSF for each Call Gap message received from a gsmSCF.

This clause contains the SDL process for IM‑SSF handling of the CallGap operation received from a gsmSCF.

The following Call Gap procedures specified in 3GPP TS 23.078 Rel‑99 [4] shall also be applicable for IM‑SSF. The IM‑SSF shall take the role of the gsmSSF in the following:

– Procedure Store_Call_Gap_Criteria;

– Procedure Check_Gap_Criteria.

Figure 4.35-1: Process imcn_SSME_SSF (sheet 1)

Figure 4.35-2: Process imcn_SSME_SSF (sheet 2)