7.3.2 Originating sessions that use CS media

23.2923GPPIP Multimedia Subsystem (IMS) centralized servicesRelease 17Stage 2TS

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

7.3.2.1 Non ICS UE originating sessions that use CS media

7.3.2.1.1 Overview

Originating sessions that use CS media made by non ICS UEs that have been successfully registered in IMS by the MSC Server can utilize IMS service control. The non ICS UE initiates a standard CS originating session toward the MSC Server enhanced for ICS, which in turn can initiate an IMS originating session using the I2 reference point.

For these sessions, the MSC Server shall perform interworking between the I2 reference point and CS signalling (e.g. as described in TS 24.008 [6]). The MSC Server shall also control a CS-MGW using the Mc reference point to perform interworking between CS access bearers and RTP bearers on the Mb reference point. For emergency sessions, the MSC Server may perform existing MSC Server emergency call handling procedures or interworking with IMS as specified in clause 7.3.2.3.

For video call originating sessions that use CS media, the MSC Server enhanced for ICS shall also, after the multimedia connection is established, perform the video codec negotiation for the non ICS UE and set up the video media bearer based upon the procedures defined in TS 29.163 [11] for 3GPP systems and based on procedures defined in 3GPP2 C.S0042 [38] for 3GPP2 systems.

The SCC AS shall be inserted in the IMS session path using the iFC.

7.3.2.1.2 Origination using I2 reference point

Figure 7.3.2.1.2-1 describes how IMS originations are performed via CS access for non ICS UE. This call flow also applies for an ICS UE CS origination with CS media without use of I1 and with use of an MSC server enhanced for ICS, as specified in clause 7.3.2.2.3.

Figure 7.3.2.1.2-1: IMS Origination via CS Access for non ICS UE

1. The UE A sends a CS call setup message containing the B-party number to the MSC Server enhanced for ICS according to standard CS originating procedures.

2. The MSC Server sends an INVITE to the S‑CSCF with the Request-URI set to the B-party number. If a GRUU is to be included as described in TS 23.228 [2], then include a temporary-GRUU as the contact address if privacy has been requested or a public-GRUU if privacy has not been requested. The INVITE also contains SDP received from the CS-MGW. The MSC Server adds the User Location Information (e.g. CGI or SAI) and/or UE Time Zone Information to the INVITE. For a roaming user, when the Roaming Architecture for Voice over IMS with Local Breakout is supported according to clause 4.15a of TS 23.228 [2], the MSC Server may, based on operator policy, add a reference to the preferred Transit and Roaming Function.

3. The S‑CSCF performs standard service control execution procedures. Filter criteria direct the S‑CSCF to send the INVITE to the SCC AS.

4. The SCC AS invokes a B2BUA, terminating the UE A Leg and originating the Remote Leg for presentation of an IMS session towards the B-party on behalf of UE A. The SCC AS creates an INVITE containing the SDP received in the CS Bearer Control Signalling Path, indicating CS voice or voice and video media. The INVITE request is routed from the SCC AS to the S‑CSCF.

5. The S‑CSCF continues with standard IMS originated session processing and routes the request onwards to the B-party.

6. Completion of the session and bearer control setup procedures. For video call, to complete the session and bearer setup, the specific handling as described in clause 7.3.2.1.1 applies.

7.3.2.1.3 Origination when using an MSC Server

Figure 7.3.2.1.3-1 describes how IMS originations are performed via CS access for non ICS UE attached to a legacy MSC or MSC-Server which has not been enhanced for ICS. This call flow also applies for an ICS UE CS origination with CS media without use of I1 and with use of an MSC server, as specified in clause 7.3.2.2.3.

Figure 7.3.2.1.3-1: IMS Origination via CS Access for non ICS UE

1. The UE A originates a call in the CS domain to party-B according to standard origination procedures.

2. The MSC Server responds with a Call Proceeding message and begins to set up the CS Bearer Control Signalling Path.

3. The MSC-Server fetches an IP Multimedia Routing Number (IMRN) via IN (e.g. CAMEL) and routes the call towards the user’s home IMS network using the IMRN via an MGCF.

4. The MGCF initiates an INVITE towards the I‑CSCF in the home IMS of the originating ICS user.

5. The I‑CSCF routes the INVITE based on one of the following standard procedures specified in "PSI based Application Server termination – direct and PSI based Application Server termination – indirect" procedures in TS 23.228 [2] either directly to the SCC AS or via the S‑CSCF.

6. When the INVITE arrives at the SCC AS, it invokes a B2BUA, terminating the UE A leg and originating the Remote Leg for presenting an IMS session towards the B-party on behalf of UE A. The SCC AS creates an INVITE containing the SDP received from MGCF, indicating CS voice or voice and video media. The original called number and the calling party number are used to setup the outgoing call leg to party-B in accordance with the AS origination procedure defined in clause 5.6.5 of TS 23.228 [2]. If required the SCC AS adds User Location Information (e.g. CGI or SAI) and/or UE Time Zone Information to the INVITE. The SCC AS sends the INVITE back to S‑CSCF.

NOTE 1: The method for discovery of original called number and calling party number at the SCC AS if ISUP does not provide this information is implementation dependant. This can be realized by interactions between the SCC AS and the SCF (e.g. gsmSCF); however this interaction is outside the scope of this specification.

NOTE 2: The method for determining User Location Information (e.g. CGI or SAI) and/or UE Time Zone Information at the SCC AS is implementation dependant. This can be realized by interactions between the SCC AS and the SCF (e.g. gsmSCF). The SCC AS can also retrieve the User Location Information (e.g. CGI or SAI) and/or UE Time Zone Information from the MSC via the HSS as specified in TS 29.328 [48] and as described in clause 4.2.4a of TS 23.228 [2].

7-8. The S‑CSCF sends the INVITE further for completion of the call toward the remote end. For video call, to complete the session and bearer setup, the specific handling as described in clause 7.3.2.1.1 applies.

7.3.2.2 ICS UE Originating sessions that use CS media

7.3.2.2.1 Overview

IMS service control is used for ICS UE originated sessions that use a CS media bearer.

When using the Gm reference point, the ICS UE initiates a standard IMS originating session indicating use of CS media bearer for the session. The SCC AS is inserted in the IMS session path using originating iFC. The ICS UE also sets up a standard CS originated session addressing a PSI DN associated with the SCC AS to establish the CS bearer if a CS bearer is not available for the ICS UE. The CS bearer shall be reused if already established using the Gm reference point. The service control signalling is combined with the description of the CS bearer at the SCC AS for presentation of the IMS originating session to the S‑CSCF over the Remote Leg.

When a subsequent session origination with different CS bearer requirement occurs (i.e. CS audio bearer is changed to CS video bearer, or vice versa), the CS bearer shall be updated if possible through SCUDIF or redial (refer to clause 7.9.2).

The ICS UE should be able to detect an emergency session establishment request. If the ICS UE using a CS access detects the request for the establishment of an emergency session, the ICS UE shall attempt to initiate a CS emergency call.

If the ICS UE could not detect an emergency call and originates the session with CS media using Gm reference point, it will forward an IMS session establishment request to the P‑CSCF. If the P‑CSCF detects such an emergency call, it rejects the request with an indication that this is for an emergency session as described in TS 23.167 [25].

NOTE: If the P‑CSCF is not ICS aware, it is assumed that some other node in the emergency session path will detect the unsupported media and reject it or the call will be delivered to the PSAP without voice media component. Normal error handling applies in this case.

As described in TS 23.167 [25], an ICS UE that initiated a non UE detectable emergency session will receive an indication in responses from which it can deduce that the session is for emergency. Upon receiving an emergency session rejection or session rejection with this indication, the ICS UE shall fall back to CS according to TS 23.167 [25].

When not using the Gm reference point, the following apply:

– For sessions originated using a B party’s SIP URI (not using user = phone), the ICS UE initiates a dialogue with the SCC AS over the I1 reference point indicating session origination. The ICS UE also sets up a CS originated session addressing a PSI DN associated with the SCC AS to establish the CS bearer. The service control signalling is combined with the description of the CS bearer at the SCC AS for presentation of the IMS originating session to the S‑CSCF over the Remote Leg.

– For all other cases, the ICS UE initiates a standard CS originating call using B party’s E.164 number. The call is routed to IMS via a standard MSC Server using IN (e.g. CAMEL) based redirection or an MSC Server enhanced with ICS. If the B party number is detected by the MSC Server as an emergency number then it will be handled as per existing MSC Server call handling procedures. Additionally, the ICS UE may use the I1 reference point for communication of additional parameters.

For video call originating sessions that use CS media, the following apply:

– When the ICS UE is attached to the MSC Server enhanced for ICS, after the multimedia connection is established, the MSC Server enhanced for ICS shall perform the video codec negotiation for the ICS UE and set up the video media bearer based upon the procedures defined in TS 29.163 [11] for 3GPP systems and based on the procedures defined in 3GPP2 C.S0042 [38] for 3GPP2 systems;

– When the ICS UE is attached to the MSC Server not enhanced for ICS, the MGCF/IMS-MGW shall perform the video codec negotiation for the ICS UE and set up the video media bearer as specified in TS 29.163 [11] for 3GPP systems and as specified in 3GPP2 C.S0042 [38] for 3GPP2 systems.

The following clauses show pairs of flows, one for an ICS UE when using an MSC Server and the other for an MSC Server enhanced for ICS. They are for the most part identical except that in the case of an MSC Server enhanced for ICS the INVITE towards the SCC AS is sent directly from the MSC Server whereas an MSC Server sends an ISUP IAM and the MGCF interworks this to an INVITE towards the SCC AS.

A "Gm origination with CS media" policy may be provisioned by the operator and communicated to the ICS UE during initial provisioning or via OMA Device Management [24].

NOTE 1: Operators who choose to make use of ICS UEs may update this policy in order to optimize the user experience depending on knowledge of the capabilities of the Home PLMN and Visited PLMN (if roaming), in particular whether the MSC Server is enhanced for ICS, whether IN re-routing is possible and whether the ICS UE may be handed over to a non DTM-enabled GERAN.

For originating sessions that use CS media, when the use of the Gm reference point is possible, the ICS UE shall behave as follows, depending on the "Gm origination with CS media" policy:

– if this policy is set to "Gm disabled", then the ICS UE shall not use the procedure specified in clause 7.3.2.2.4.

– if this policy is set to "Gm enabled but not preferred", then:

– if the destination is a Tel URI or a SIP-URI representing a telephone number, and the exchange of additional SIP parameters is not required, then the ICS UE shall not use the procedure specified in clause 7.3.2.2.4;

– otherwise, the ICS UE shall use the procedure specified in clause 7.3.2.2.4.

– if this policy is set to "Gm enabled", then the ICS UE shall use the procedure specified in clause 7.3.2.2.4.

NOTE 2: When setting the "Gm origination with CS media" policy to the ICS UE, the home operator is able to consider whether the MSC in VPLMN has been enhanced for ICS or not, and in the latter case the operator can enable the Gm reference point for ICS service control. When roaming, the Home operator can update this policy depending on the VPLMN, e.g. based on roaming agreements.

7.3.2.2.2 Originations with CS media when using I1

7.3.2.2.2.1 Originations to a SIP URI

Figure 7.3.2.2.2.1-1 provides an example flow for a session origination by an ICS UE when a SIP-URI is used to address the called party and when the ICS UE is attached to an MSC Server enhanced for ICS and the user is identified as an ICS user.

Figure 7.3.2.2.2.1-1: ICS UE Origination with CS media addressing a SIP-URI when using an MSC Server enhanced for ICS

NOTE 1: 4, 5, 6 and 7 are related to the CS Bearer Control Signalling Path. The other steps are related to the CS Service Control Signalling Path.

1. The ICS UE A initiates a call by sending an ICS Call Initiation Request over the I1 reference point containing the UE B address.

2. The SCC AS performs the necessary adaptation of the signalling received over the I1 reference point. The SCC AS allocates a PSI DN and sends it to the ICS UE A.

3. The SCC AS sends the SCC AS PSI DN to the UE over the I1 reference point.

4. The ICS UE A uses standard CS originating procedures to establish a CS Bearer Control Signalling Path with the SCC AS by sending a SETUP message to the MSC Server containing the SCC AS PSI DN.

5. The MSC Server responds with a Call Proceeding message and begins to set up the CS Bearer Control Signalling Path.

6. The MSC Server sends an INVITE to the S‑CSCF with the Request-URI set to the SCC AS PSI. If a GRUU is to be included as described in TS 23.228 [2], then include a temporary-GRUU as the contact address if privacy has been requested or public-GRUU if privacy has not been requested. The MSC Server adds the User Location Information (e.g. CGI or SAI) and/or UE Time Zone Information to the INVITE.

7. The S‑CSCF carries out standard processing of originating initial filter criteria and sends the INVITE to the SCC AS. The SCC AS is the first AS inserted in the session path.

8. The SCC AS invokes a B2BUA, terminating the UE Leg and originating the Remote Leg for presentation of an IMS session towards the B-party on behalf of ICS UE A. The SCC AS correlates the CS bearer control signalling session with the service control signalling session using the SCC AS PSI and creates a SIP INVITE containing the SDP received in the CS Bearer Control Signalling Path, indicating CS voice or voice and video media. The INVITE request is routed from the SCC AS to the S‑CSCF.

9. The S‑CSCF continues with standard IMS originated session processing and routes the request onwards to the B-party.

10. Completion of the Service Control Signalling Path and the CS Bearer Control Signalling Path setup procedures. For video call, to complete the session and bearer setup, the specific handling as described in clause 7.3.2.2.1 applies.

Figure 7.3.2.2.2.1-2 provides an example flow for a session origination by an ICS UE when a SIP-URI is used to address the called party and when the ICS UE is attached to an MSC Server.

Figure 7.3.2.2.2.1-2: ICS UE Origination with CS media addressing a SIP-URI when using an MSC Server

NOTE 2: Steps 4, 5, 6, 7 and 8 are related to the CS Bearer Control Signalling Path. The other steps are related to the setup of the Service Control Signalling Path.

Steps 1-5 in Figure 7.3.2.2.2.1-2 are identical to steps 1-5 in Figure 7.3.2.2.2.1-1.

At Steps 6 and 7, the MSC Server sends the IAM using the SCC AS PSI DN to an MGCF which is subsequently inter-worked to an INVITE.

Steps 8-11 in Figure 7.3.2.2.2.1-2 are identical to steps 7-10 in Figure 7.3.2.2.2.1-1.

7.3.2.2.2.2 Originations to a B-party number other than SIP-URI

Figure 7.3.2.2.2.2-1 provides an example flow for a session origination by an ICS UE where the I1 reference point is used to set up the session and the user dials a E.164 number, Tel-URI or SIP-URI user=phone, and when the ICS UE is attached to an MSC Server enhanced for ICS and the user is identified as an ICS user.

Figure 7.3.2.2.2.2-1: ICS UE Origination with CS media using a E.164 number, Tel-URI or SIP-URI user=phone and an MSC Server enhanced for ICS

NOTE 1: Steps 4, 5, 6 and 7 are related to the CS Bearer Control Signalling Path. The other steps are related to the setup of the Service Control Signalling Path.

1. The ICS UE A initiates a call by sending an ICS Call Initiation Request over the I1 reference point containing the UE B address. The ICS UE A also indicates in the I1 message that an SCC AS PSI DN is not needed for this session.

2. The SCC AS performs the necessary adaptation of the signalling received over the I1 reference point. The SCC AS notes the SCC AS PSI DN is not used for this session.

3. The SCC AS returns an ICS Call Initiation Result to ICS UE A over the I1 reference point.

4. The ICS UE A uses standard CS originating procedures to establish a CS Bearer Control Signalling Path with the IUA of the SCC AS by sending a SETUP message to the MSC Server containing the B-party-number. If the B party number is detected by the MSC Server as an emergency number then it will be handled as per existing MSC Server call handling procedures.

When the user dials a Non-UE detectable Emergency DN or Emergency URI but I1 has been established, or if the CS origination fails to be routed into IMS, a timer running at the SCC AS will expire as the CS Bearer Control Signalling Path was not established towards the SCC AS and an appropriate indication is returned to the UE The UE shall not release the CS bearer on receipt of this indication and the UE shall not use the Service Control Signalling Path further for the call.

5. The MSC Server responds with a Call Proceeding message and begins to set up the CS Bearer Control Signalling Path.

6. The MSC Server sends an INVITE to the S‑CSCF with the destination set to the called party number and the source to the calling party. If a GRUU is to be included as described in TS 23.228 [2], then include a temporary-GRUU as the contact address if privacy has been requested or public-GRUU if privacy has not been requested. The MSC Server adds the User Location Information (e.g. CGI or SAI) and/or UE Time Zone Information to the INVITE.

7. The S‑CSCF carries out standard processing of originating initial filter criteria and sends the INVITE to the SCC AS.

8. The SCC AS invokes a B2BUA, terminating the UE Leg and originating the Remote Leg for presentation of an IMS session towards the B-party on behalf of ICS UE A. The IUA correlates the CS bearer control signalling session with the service control signalling session and creates a SIP INVITE containing the SDP received in the CS Bearer Control Signalling Path, indicating CS voice or voice and video media and routes the INVITE request to the S‑CSCF. If the SCC AS obtains the calling party identify from step 1, then the SCC AS shall use this identity from step 1 as the calling party identity. Otherwise, then the SCC AS shall use the calling party identity received in step 6.

9. The S‑CSCF continues with standard IMS originated session processing and routes the request onwards to the B-party.

Figure 7.3.2.2.2.2-2 provides an example flow for a session origination by an ICS UE where the I1 reference point is used to set up the session and the user dials a E.164 number, Tel-URI or SIP-URI user=phone and when the ICS UE is attached to an MSC Server.

Figure 7.3.2.2.2.2-2: ICS UE Origination with CS media using a E.164 number, Tel-URI or SIP-URI user=phone and an MSC Server

NOTE 2: Steps 4, 5, 6, 7 and 8 are related to the CS Bearer Control Signalling Path. The other steps are related to the setup of the Service Control Signalling Path.

Steps 1-5 in Figure 7.3.2.2.2.2-2 are identical to steps 1-5 in Figure 7.3.2.2.2.2-1.

In Steps 6 and 7, IN (e.g. CAMEL) origination triggers are used at the MSC Server for fetching of an IP Multimedia Routing Number (IMRN). The MSC Server sends an IAM to an MGCF using the IMRN which is subsequently inter-worked to an INVITE.

In Step 8, the S‑CSCF carries out standard processing of originating initial filter criteria and sends the INVITE to the SCC AS. This step is skipped if the I‑CSCF routes the INVITE request directly to the SCC AS.

Steps 9-11 in Figure 7.3.2.2.2.2-2 are identical to steps 8-10 in Figure 7.3.2.2.2.2-1.

NOTE 3: The method for discovery of original called number and calling party number at the SCC AS if ISUP does not provide this information is implementation dependant. This can be realized by interactions between the SCC AS and the SCF (e.g. gsmSCF); however this interaction is outside the scope of this specification.

7.3.2.2.3 Originations with CS media when not using I1

This procedure may be used when the ICS User dials an E.164 number, a Tel URI or a SIP-URI user=phone, and the exchange of additional SIP parameters is not required. The ICS UE initiates a standard CS originating using the B-party’s E.164 number or a number derived from the Tel-URI. The call is routed to IMS via an MSC Server which is enhanced to support ICS or a standard MSC Server using IN (e.g. CAMEL) based re-direction.

Figure 7.3.2.1.2-1 provides an example flow for a session origination by an ICS UE where the I1 reference point is not required to set up the session and a MSC Server enhanced for ICS is used to set-up the CS Bearer Control Signalling Path and the user is identified as an ICS user.

For a session origination by an ICS UE where the I1 reference point is not required to set up the session and a MSC Server enhanced for ICS is not used to set-up the CS bearer control signalling, an example call flow is shown in Figure 7.3.2.1.3-1.

7.3.2.2.4 Originations with CS media using the Gm reference point

Figure 7.3.2.2.4-1 provides an example flow for a session origination by an ICS UE attached to an MSC Server enhanced for ICS where the Gm reference point is used to set up the session with the CS media bearer.

Figure 7.3.2.2.4-1: ICS UE Origination with CS media using Gm reference point when using an MSC Server enhanced for ICS

NOTE 1: Steps 6, 7, 8 and 9 are related to the CS Bearer Control Signalling Path. The other steps are related to the setup of the Service Control Signalling Path.

1. The ICS UE A sets up a Service Control Signalling Path by initiating a standard IMS origination session towards the UE B. A SIP INVITE request (indicating the use of CS media for the session) is sent to the S‑CSCF serving the UE A in the home IMS network.

2. The SCC AS is inserted in the IMS session path using originating initial filter criteria at the S‑CSCF. The SCC AS is the first AS inserted in the session path.

3. The SCC AS allocates a PSI DN and sends it to the ICS UE A.

4. The SCC AS returns the SCC AS PSI DN in a reliable provisional response to the S‑CSCF

5. The S‑CSCF forwards the provisional response (containing the SCC AS PSI DN) to ICS UE A.

6. The ICS UE uses standard CS originating procedures to establish the CS Bearer Control Signalling Path with the SCC AS by sending a CS call setup message to the MSC Server containing the SCC AS PSI DN.

NOTE 2: The UE waits for the SIP response (step 5) before the UE generates the CS call setup.

7. The MSC Server responds with a Call Proceeding message and begins to set up the CS Bearer Control Signalling Path.

8. The MSC Server sends an INVITE to the S‑CSCF with the Request-URI set to the SCC AS PSI. If a GRUU is to be included as described in TS 23.228 [2], then include a temporary-GRUU as the contact address if privacy has been requested or public-GRUU if privacy has not been requested. The MSC Server adds the User Location Information (e.g. CGI or SAI) and/or UE Time Zone Information to the INVITE.

9. The S‑CSCF carries out standard processing of originating initial filter criteria and sends the INVITE to the SCC AS.

10. The SCC AS invokes a B2BUA, terminating the Access Leg and originating the Remote Leg for presentation of an IMS session towards the B-party on behalf of ICS UE A. The SCC AS correlates the CS bearer control signalling with the service control signalling and combines both the SDP offers into one offer towards the UE B. The SCC AS inserts the SDP received on the CS Bearer Control Signalling Path into the INVITE indicating CS media towards the B-party. The INVITE request is routed from the SCC AS to the S‑CSCF.

11. The S‑CSCF continues with standard IMS originated session processing and routes the request onwards to the B-party

12. Completion of the Service Control Signalling Path and the CS Bearer Control Signalling Path setup procedures. For video call, to complete the session and bearer setup, the specific handling as described in clause 7.3.2.2.1 applies.

Figure 7.3.2.2.4-2 provides an example flow for a session origination by an ICS UE attached to an MSC Server where the Gm reference point is used to set up the session with the CS media bearer.

Figure 7.3.2.2.4-2: ICS UE Origination with CS media using Gm reference point when using an MSC Server

NOTE 3: Steps 6, 7, 8, 9 and 10 are related to the CS Bearer Control Signalling Path. The other steps are related to the setup of the Service Control Signalling Path.

Steps 1-7 in Figure 7.3.2.2.4-2 are identical to steps 1-7 in Figure 7.3.2.2.4-1.

At Steps 8 and 9, the MSC server sends the IAM using the SCC AS PSI DN to an MGCF which is subsequently inter-worked to an INVITE.

Steps 10-13 in Figure 7.3.2.2.4-2 are identical to steps 9-12 in Figure 7.3.2.2.4-1.

7.3.2.3 CS Emergency call interworking with IMS

If the MSC Server enhanced with ICS supports I6, it may perform the following procedure to interwork with IMS for handling CS emergency call to PSAP.

If the MSC Server detects a CS emergency call (i.e, due to CS setup with emergency indication or detection of locally defined emergency number) from an UE that has already been registered in this MSC Server using I2 registration procedure, then MSC Server shall perform a registration for the support of emergency services (emergency registration) to IMS via I2. The MSC Server then proceeds with emergency session establishment request to E-CSCF via I6.

If MSC Server is required to handle anonymous emergency call (i.e., based on local regulation), MSC Server shall not perform any registration procedure to IMS and shall directly proceed with anonymous emergency requests toward E-CSCF via I6.

If the MSC Server detects that the CS emergency call is tagged with eCall indication from the UE, MSC Server shall include the IMS eCall indication in the emergency session establishment request to E-CSCF via I6. The UE transfers the MSD using in-band modem as defined for CS eCall. The MSC Server and IMS shall transfer the MSD data in an end to end fashion, UE to PSAP, in the form generated by the UE.

For UE that has been registered to this MSC Server but IMS registration using I2 has not been performed then MSC Server shall fall back to the behaviour of an MSC Server that is not enhanced for ICS in handling CS emergency call.