6.2 Origination and Termination
23.2373GPPIP Multimedia Subsystem (IMS) Service ContinuityRelease 17Stage 2TS
6.2.1 Origination
6.2.1.1 Origination Procedures
UE initiated multimedia sessions are anchored at the SCC AS in order to enable IMS Service Continuity. Originating iFC for the SC subscriber results in routing of the session to the SCC AS in the home IMS network, where the SCC AS uses 3rd party call control as per TS 23.228 [4] to initiate a session to the remote party on behalf of the subscriber.
The SCC AS shall be the first Application Server of any Application Servers that need to remain in the path of the call after Session Origination.
6.2.1.2 Originating sessions that use CS media
The UE originates sessions that use CS media by following the procedures specified in TS 23.292 [5], clause 7.3.2 Originating sessions that use CS media.
Figure 6.2.1.2-1: Originating session that uses CS media
1. UE‑1 initiates a multimedia session to UE‑2 and makes use of CS media. UE‑1 sends the request to the SCC AS following the procedures specified in TS 23.292 [5], clause 7.3.2 Originating sessions that use CS media, for setting up CS bearer, anchoring the session at the SCC AS, merging multiples legs if necessary, and forwarding the combined session request to UE‑2.
2. The SCC AS anchors the session. A dynamic STI is assigned for the anchored session.
3. The SCC AS completes session setup to UE‑2 and sends a response to UE‑1 based on the procedures specified in TS 23.292 [5]. The dynamic STI is communicated between the SCC AS and UE-1 if possible.
The session is set up with CS media. The session may also include PS media flow(s).
6.2.1.3 Originating sessions that use only PS media flow(s)
Existing Mobile Origination procedures described in TS 23.228 [4] are used to establish a session.
Figure 6.2.1.3-1: Originating session that uses only PS media
1. UE-1 initiates an IMS multimedia session to UE-2 and uses only PS media flow(s). The request is forwarded to S-CSCF following normal IMS session set up procedures.
2~3. The service logic with iFC causes the request to be forwarded to the SCC AS for anchoring the sessions to enable Session Transfer.
4. The SCC AS anchors the session. An STI is assigned for the anchored session.
5. The SCC AS completes the session setup to UE-2 and sends a response to UE-1. For Dual Radio scenario, the SCC AS may provide an update STN to the UE as part of the response.
6.2.1.3a Originating sessions that use only PS media flow(s) – fallback to CS domain in pre-alerting phase
The procedure is to be used if SRVCC in pre-alerting state or alerting phase for originating sessions is not supported.
Figure 6.2.1.3a-1: Originating session that uses only PS media – fallback to CS domain in pre-alerting phase
1~6. UE-1 initiates an IMS multimedia session to UE-2 and uses only PS media flow(s). The request is forwarded to S-CSCF, SCC AS, UE-2 and a response is sent back following normal IMS session set up procedures, wherein 180 (Ringing) response has not been received yet and originating session is in pre-alerting phase.
7. The multimedia PS bearer setup fails.
NOTE 1: When and how many times (only once or twice) the PCRF is invoked by the P-CSCF is specified in TS 29.213 [33], Annex B, clause B.2.
8~9. The P-CSCF sends a response to UE and sends a Cancel message to SCC AS to release the mobile originating session.
NOTE 2: The response should uniquely indentify a QoS Resources Authorization failure.
NOTE 3: The UE can trigger the establishment of voice call on the CS domain as defined in TS 24.229 [26] clause L.5.
10. The UE initiates CS call.
6.2.1.4 Originating sessions for (v)SRVCC that use ATCF enhancements
Figure 6.2.1.4-1 shows an originating session when the ATCF has previously been included in the signalling path (see clause 6.1.2). If the ATCF was not included in the signalling path then existing Mobile Origination procedures described in previous clauses and TS 23.228 [4] are used.
Figure 6.2.1.4-1: Originating session that uses only PS media (ATCF in signalling path).
1. UE-1 initiates an IMS multimedia session to UE-2 and uses only PS media flow(s). The initial SIP INVITE request goes through the ATCF in the serving network. The ATCF may decide whether to anchor the session and allocate if needed ATGW resources to it.
2~5. ATCF forwards the initial SIP INVITE request, which is routed towards the UE-2.
6. Completion of originating session setup. As part of this step, the following is done:
– If not already done, the ATCF may decide, based on information not available earlier in the procedure, to anchor the session and allocate ATGW resources for voice media or voice and video media and anchor the voice media or voice and video media in the ATGW. The ATCF will in such case update the far end with the media information of the ATGW in another offer/answer exchange (this may be done as part of other required session update).
NOTE 1: The ATCF is not modifying the dynamic STI that is exchanged between the UE and SCC AS.
NOTE 2: The Access Leg for the control has now been established between the UE and the SCC AS.
6.2.1.5 Originating sessions for CS to PS – Single Radio
The CS origination is done according to TS 23.292 [5], clause 7.3, with the addition that the call is routed through the ATCF.
Once the session is established, the ATCF will act as the access transfer function in the call.
Figure 6.3.3.5.3-1: Originating call setup over CS through ATCF
1. The MSC Server receives the CS setup message.
2. The MSC Server initiates an INVITE origination according to TS 23.292 [5] clause 7.3, with the addition that it includes the ATCF in the path during the origination (based on the retrieved ATCF management URI). The INVITE shall include the C-MSISDN to the ATCF for further correlation purposes.
3. The ATCF may decide whether to anchor the media session and allocate if needed ATGW resources to it. Media anchoring criteria used for ATCF enhancements apply.
4-5. The call setup proceeds and is routed to the remote UE-2.
6. The call setup is completed.
6.2.2 Termination
6.2.2.1 Termination Procedures
IMS multimedia sessions towards SC subscribers in the PS or in the CS domain are anchored at the SCC AS to enable IMS Service Continuity. The execution of terminating iFC results in routing of the sessions to the SCC AS in the home IMS network, where the SCC AS uses 3rd party call control as per TS 23.228 [4] to terminate the session to the SC subscriber. The sessions may be delivered to the UE via the PS or CS access.
The SCC AS shall be the last Application Server of any Application Servers that need to remain in the path of the call after Session Termination.
6.2.2.2 Terminating sessions that use CS media
The procedures specified in TS 23.292 [5], clause 7.4.2 Terminating sessions that use CS media shall be followed to terminate sessions that use CS media to the SC subscriber.
Figure 6.2.2.2-1: Terminating session that uses CS media
1. A request is received at S‑CSCF serving UE‑1 following standard IMS session set up procedures.
2 ~ 3. The service logic with iFC causes the request to be forwarded to the SCC AS so that the session is anchored for enabling Session Transfer.
4. The SCC AS anchors the incoming session. A dynamic STI is assigned for the anchored session.
5. The SCC AS forwards the request to UE-1 based on the procedures specified in TS 23.292 [5] for setting up CS bearer and splitting the media flow(s) if necessary. The dynamic STI is communicated between the SCC AS and the UE if possible. If the SCC AS decided to split the non‑speech media and speech media for a certain UE, the T‑ADS in the SCC AS delivers the split session only to this particular UE. The SCC AS uses the C‑MSISDN for correlation.
The session is set up with CS media. The session may also include PS media flow(s).
6.2.2.3 Terminating sessions that use only PS media flow(s)
Existing Mobile Termination procedures described in TS 23.228 [4] are used to establish a session towards a SC subscriber.
Figure 6.2.2.3-1: Terminating session that uses only PS media
1. The request is received at S‑CSCF following normal IMS session set up procedures.
2 ~ 3. The service logic with iFC causes the request to be forwarded to the SCC AS so that the session can be anchored for potential session transfer.
4. The SCC AS anchors the session. An STI is assigned for the anchored session.
5. The SCC AS determines that the session is terminated to UE‑1 with PS media flow(s) only and routes the request to UE‑1. For Dual Radio scenario, the SCC AS may provide an update STN to the UE as part of the INVITE sent to the UE.
6.2.2.3a Terminating sessions that use only PS media flow(s) – fallback to CS domain in pre-alerting phase
The procedure is to be used if SRVCC in alerting phase for terminating sessions is not supported.
Figure 6.2.2.3a-1: Terminating session that uses only PS media – fallback to 2/3G in pre-alerting phase
1~ 5. The request is received from UE-2 following normal IMS session set up procedures and UE-1 sends a 183 response.
6. The multimedia PS bearer setup fails.
NOTE: When and how many times (only once or twice) the PCRF is invoked by the P-CSCF is specified in TS 29.213 [33], Annex B, clause B.2.
7~8. The P-CSCF sends a response to S-CSCF indicating the failure of the delivery of the terminating call on the PS domain.
9~13. The S-CSCF forwards the response to SCC AS that attempts to deliver the terminating call on the CS domain if possible, according to clause 7.4.3 (steps 8 through 12) in TS 23.292 [5].
6.2.2.4 Terminating sessions over Gm where speech media is not accepted by the UE
If the SCC AS includes only bi-directional speech media, the procedures specified in TS 23.292 [5], clause 7.4.3 shall be followed.
If the SCC AS includes non-speech media in the request, in addition to bi-directional speech or CS media and if the UE decides to only accept the non-speech media, the UE returns a response to IMS that only bi-directional speech or CS media is rejected. The SCC AS, upon reception of the response, splits the non speech media from the bi-directional speech or CS media for this UE. The T‑ADS in the SCC AS re-attempts the terminating call setup directly towards the same UE over CS domain if possible. The SCC AS uses the C‑MSISDN for correlation.
6.2.2.5 Terminating sessions for (v)SRVCC that use ATCF enhancements
Figure 6.2.2.5-1 shows a terminating session when the ATCF has previously been included in the signalling path (see clause 6.1.2). If the ATCF was not included in the signalling path then existing Mobile Termination procedures described in previous clauses and TS 23.228 [4] are used.
Figure 6.2.2.5-1: Terminating session that uses only PS media (ATCF in signalling path)
1-2. A Terminating session is sent towards UE-1 from UE-2. The initial SIP INVITE request is routed via the I/S-CSCF to the SCC AS.
3. The SCC AS performs necessary T-ADS procedures according to clause 5.3.1, and routes the request towards the UE-1.
4. The INVITE is routed towards the ATCF. When receiving the INVITE, the ATCF may decide whether to anchor the media for the session and allocate ATGW resources for it if needed.
5. The SIP INVITE is forwarded to UE-1 (P-CSCF not shown in flow).
NOTE 1: In case the UE-1 returns a response to IMS that bi-directional speech is rejected as specified in clause 6.2.2.4, the ATCF will release the ATGW resources allocated if any. The ATCF can then remove itself from the session path.
6. Session setup is completed. As part of this step, if not already done, the ATCF may decide, based on information not available earlier in the procedure, to anchor the session and allocate ATGW resources for voice media or voice and video media and anchor the voice media or voice and video media in the ATGW. The ATCF will in such case update the remote end with the media information of the ATGW in another offer/answer exchange (this may be done as part of other required session update).
NOTE 2: The ATCF is not modifying the dynamic STI that is exchanged between the UE and SCC AS.
NOTE 3: The Access Leg for the control has now been established between the UE and the SCC AS.
6.2.2.6 Terminating sessions for CS to PS – Single Radio
The CS termination is done according to TS 23.292 [5] clause 7.4, with the addition that the call is routed through the ATCF.
Once the session is established, the ATCF will act as the access transfer function in the call.
Figure 6.2.2.6-1: Terminating call setup over CS through ATCF
1-2. UE-2 sends an INVITE towards UE-1. The call is routed towards MSC Server using procedure according to TS 23.292 [5], clause 7.4.
3. The MSC Server routes the INVITE via ATCF using the ATCF management URI that it has received from SCC AS (see clause 6.1.3.2). The INVITE shall include the C-MSISDN to the ATCF for further correlation purposes.
4. The ATCF may decide whether to anchor the media session and allocate if needed ATGW resources to it. Media anchoring criteria used for ATCF enhancements apply.
5-6. The call setup proceeds and is routed toward UE-1.
7. The call setup is completed.