6c Procedures and flows for SRVCC Emergency Session

23.2373GPPIP Multimedia Subsystem (IMS) Service ContinuityRelease 17Stage 2TS

6c.1 IMS Emergency origination flow for PS to CS SRVCC

Figure 6c.1-1 provides flow for an emergency session established in IMS, illustrating how the emergency session is anchored in the EATF.

Figure 6c.1-1: UE initiating an emergency session in IMS

1. The UE initiates an IMS emergency session over NG-RAN (see TS 23.501 [37]), EPS or GPRS and the procedures defined in TS 23.167 [23]. This involves the UE generating a SIP INVITE containing the UE’s location information and the equipment identifier.

For IMS emergency call over EPS (e.g. after transfer from NG-RAN, see TS 23.501 [37]) or GPRS, if the UE supports the UE procedures for the SRVCC session transfer of an IMS emergency session in early dialogue phase for PS to CS as described in the clause 6c.2.2, the UE includes in the SIP INVITE an indication of support of the UE procedures for the SRVCC session transfer of an IMS emergency session in early dialogue phase for PS to CS.

2. The P-CSCF selects an E-CSCF and forwards the INVITE to the E-CSCF.

3. The E-CSCF sends the INVITE to the EATF.

4. The EATF (acting as a routing B2BUA) anchors the emergency session, i.e. the EATF is inserted in the signalling path which invokes a 3pcc for enablement of Access Transfers for the call as specified in clause 6.3.1.3.

5. The EATF creates a new INVITE and sends it back to E-CSCF.

6. For this optional procedure, refer to TS 23.167 [23].

7. The E-CSCF uses the routing information to format the INVITE message, and it sends it directly to the PSAP, or to the PSAP via the MGCF.

8. The E-CSCF receives a response to the INVITE.

9. The E-CSCF forwards to the EATF the response to the INVITE.

10. The EATF forwards to the E-CSCF the response to the INVITE. If the network supports the network procedures for the SRVCC session transfer of an IMS emergency session in early dialogue phase for PS to CS as described in the clause 6c.2.2, and the INVITE request received in step 3 included an indication of support of the UE procedures for the SRVCC session transfer of an IMS emergency session in early dialogue phase for PS to CS, then the EATF includes in the response to the INVITE an indication of support of the network procedures for the SRVCC session transfer of an IMS emergency session in early dialogue phase for PS to CS.

11. The E-CSCF forwards to the P-CSCF the response to the INVITE.

12. The P-CSCF forwards to the UE the response to the INVITE.

6c.2 SRVCC session transfer of IMS emergency session for PS to CS

6c.2.1 SRVCC session transfer of an active IMS emergency session for PS to CS (single EATF instance)

Figure 6c.2.1-1 provides flow for SRVCC for IMS emergency session, when the IMS emergency session is active session. This applies when a single EATF instance is deployed (see clause 6c.2.3 for multiple EATF instances).

Figure 6c.2.1-1: IMS level Call flow for SRVCC for IMS emergency session with E-STN-SR with a single EATF instance

1. MSC Server initiates the session transfer with the E-STN-SR and it includes the equipment identifier.

2. The I-CSCF routes the INVITE directly to the EATF via I5 by using similar procedures to that defined in TS 23.228 [4] for PSI based Application Server termination.

NOTE 1: The use of indirect routeing for PSI based Application Server Termination as described in TS 23.228 [4] in clause 5.7.6 cannot be used for routing the INVITE to the EATF.

3 – 4. The EATF uses the E-STN-SR to determine that Access Transfer is requested. The EATF proceeds with the Access Transfer of the active session with bi-directional speech for the UE by updating the Remote Leg with the media description and other information using the Remote Leg Update procedure as specified in clause 6.3.1.5. For SRVCC session transfer of an eCall over IMS, the EATF indicates in the reINVITE that the EATF shall exclude INFO requests for any Info Packages related to eCall over IMS as defined in RFC 6086 [34] clause 5.2.2.

NOTE: Indicating an unwillingness to receive INFO requests will prevent an emergency centre/PSAP from sending an INFO message to request an updated MSD from the UE.

5. The E-CSCF forwards the Re-INVITE to the MGCF associated with the PSAP if the PSAP is located in the PSTN or CS Domain (the u-plane path is switched between the UE and the MGW) or the Re-INVITE is sent directly to an IP-capable PSAP (the u-plane path between the UE and the PSAP is switched end-to-end).

6. When session modification procedures complete, the source access leg (i.e. the access leg previously established over IMS) is released as specified in clause 6.3.1.6.

NOTE 2: If non-voice media was part of the original Multimedia emergency call session, the non-voice media will be released.

6c.2.2 SRVCC session transfer of an IMS emergency session in early dialogue phase for PS to CS (single EATF instance)

Figure 6c.2.2-1 provides flow for SRVCC for IMS emergency session, when the IMS emergency session is in early dialogue phase. This applies when a single EATF instance is deployed (see clause 6c.2.4 for multiple EATF instances).

This flow assumes that the UE indicated to the EATF the support of the UE procedures for the SRVCC session transfer of an IMS emergency session in early dialogue phase for PS to CS and that the EATF indicated to the UE the support of the network procedures for the SRVCC session transfer of an IMS emergency session in early dialogue phase for PS to CS, as described in clause 6c.1.

Figure 6c.2.2-1: IMS level Call flow for SRVCC for IMS emergency session in early dialogue phase (i.e. pre-alerting or alerting) with E-STN-SR with a single EATF instance

1. MSC Server initiates the session transfer with the E-STN-SR and it includes the equipment identifier.

2. The I-CSCF routes the INVITE directly to the EATF via I5 by using similar procedures to that defined in TS 23.228 [4] for PSI based Application Server termination.

NOTE 1: The use of indirect routeing for PSI based Application Server Termination as described in TS 23.228 [4] in clause 5.7.6 cannot be used for routing the INVITE to the EATF.

3. The EATF uses the E-STN-SR to determine that Access Transfer is requested. The EATF proceeds with the Access Transfer of the session in early dialogue phase (i.e. pre-alerting or alerting) with bi-directional speech for the UE by updating the Remote Leg with the media description and other information using the Remote Leg Update procedure as specified in clause 6.3.1.5.

4. The E-CSCF forwards the UPDATE to the MGCF associated with the PSAP if the PSAP is located in the PSTN or CS Domain (the u-plane path is switched between the UE and the MGW) or the UPDATE is sent directly to an IP-capable PSAP (the u-plane path between the UE and the PSAP is switched end-to-end).

5. The EATF provides Session State Information on the outgoing speech call in early dialogue phase (e.g., pre-alerting or alerting state).

6. The E-CSCF forwards the Session State Information to the MSC Server.

7. The MSC moves to the corresponding CS call state, e.g. Call Delivered or Mobile Originating Call Proceeding state as specified in TS 24.008 [24].

8. The UE has received the HO command as described in TS 23.216 [10]. The UE determines the local call state in the SIP session, and creates the corresponding CS call state, e.g. Call Delivered in TS 24.008 [24] for the alerting state, or Mobile Originating Call Proceeding for the pre-alerting state. The UE ensures that the same ring back tone or announcement if any is played to the end user. If the voice+video media is played to the UE in PS domain, and the CS domain does not support video media, only the voice media shall be played to the UE after the call is transferred to CS domain from PS domain, regardless of whether the media is locally generated by the UE or is network-generated to the UE.

9. When session modification procedures complete and after delivering the Session State Information, the source access leg (i.e. the access leg previously established over IMS) is released as specified in clause 6.3.1.6.

NOTE 2: If non-voice media was part of the original Multimedia emergency call session, the non-voice media will be released.

6c.2.3 SRVCC session transfer of an active IMS emergency session for PS to CS when multiple EATF instances are deployed

6c.2.3.1 Alternative procedure based on forking

Figure 6c.2.3.1-1 provides flow for SRVCC for IMS emergency session, when the IMS emergency session is active session and multiple EATF instances are deployed.

Figure 6c.2.3.1-1: IMS level Call flow for SRVCC for IMS emergency session with E-STN-SR with support of multiple EATF instances by forking

1. Same as step 1 of Figure 6c.2.1-1: the MSC Server initiates the session transfer with the E-STN-SR and it includes the equipment identifier.

2. The I-CSCF creates multiple INVITE transactions: one INVITE per configured EATF instance.

3. Each EATF instance checks whether the equipment identifier matches with any transferable session:

3a: if no dialog was associated with the domain transfer request, the EATF rejects it (step 3a).

3b, 3c: if there is a match, the EATF proceeds with the Access Transfer (steps 3 to 5 of Figure 6c.2.1-1) and sends a 200 OK response to the I-CSCF.

4. The I-CSCF forwards the 200 OK response towards the MSC Server.

6. Same as step 6 of Figure 6c.2.1-1.

6c.2.3.2 Alternative procedure based on redirection

The solution is based on the I-CSCF using existing procedures defined in TS 24.229 [26] related to SIP response results to redirect a session to a backup EATF when an EATF has failed.

Figure 6c.2.3.2-1 provides flow for SRVCC for IMS emergency session, when the IMS emergency session is active session and multiple EATF instances are deployed.

Figure 6c.2.3.2-1: IMS level Call flow for SRVCC for IMS emergency session with E-STN-SR with support of multiple EATF instances by redirection

1. MSC Server initiates the session transfer with the E-STN-SR and it includes the equipment identifier.

2. The I-CSCF forwards te SIP INVITE to the target EATF instance EATF-1.

3. The target instance EATF-1 returns a 3xx response and incudes the contact address(es) for redundant instance(s) of EATF(s) that may have anchored the IMS session.

4. The I-CSCF forwards the SIP INVITE to (one of) the contact(s) in the returned 3xx, EATF-2.

5. The EATF returns a SIP 200 OK to the I-CSCF.

6. I-CSCF returns SIP 200 OK response towards the MSC Server.

7. MSC server returns SIP 200 OK to the UE.

8. Same as step 6 of Figure 6c.2.1-1.

NOTE 1: The contact(s) to be returned by an EATF depends on operator configuration for number of geo-redundant EATFs.

NOTE 2: Timeouts in the I-CSCF need to be set to ensure that in case of a complete EATF node failure, SRVCC procedure can successfully conclude.

6c.2.4 SRVCC session transfer of an IMS emergency session in early dialogue phase for PS to CS when multiple EATF instances are deployed

6c.2.4.1 Alternative procedure based on forking

Figure 6c.2.4.1-1 provides flow for SRVCC for IMS emergency session, when the IMS emergency session is in early dialogue phase.

Figure 6c.2.4.1-1: IMS level Call flow for SRVCC for IMS emergency session in early dialogue phase (i.e. pre-alerting or alerting) with support of multiple EATF instances by forking

1. Same as step 1 of Figure 6c.2.2-1: the MSC Server initiates the session transfer with the E-STN-SR and it includes the equipment identifier.

2. The I-CSCF creates multiple INVITE transactions: one INVITE per configured EATF instance.

2.2. If no dialog is associated with the domain transfer request, the EATF rejects it.

3 – 9. Same as corresponding steps in Figure 6c.2.2-1.

6c.2.4.2 Alternative procedure based on redirection

Figure 6c.2.4.2-1 provides flow for SRVCC for IMS emergency session, when the IMS emergency session is in early dialogue phase.

Figure 6c.2.4.2-1: IMS level Call flow for SRVCC for IMS emergency session in early dialogue phase (i.e. pre-alerting or alerting) with support of multiple EATF instances by redirection

1. MSC Server initiates the session transfer with the E-STN-SR and it includes the equipment identifier.

2.1. The I-CSCF forwards the SIP INVITE to target instance EATF-1.

2.2 The target instance EATF-1 returns a 3xx response and incudes the contact address(es) for a redundant instance(s) EATF(s) that may have anchored the IMS session.

2.3 The I-CSCF forwards the SIP INVITE to (one of) the contact(s) in the returned 3xx, EATF-2.

3 – 9. Same as corresponding steps in Figure 6c.2.2-1.

NOTE 1: The contact(s) to be returned by an EATF depends on operator configuration for number of geo-redundant EATFs.

NOTE 2: Timeouts in the I-CSCF need to be set to ensure that in case of a complete EATF node failure, SRVCC procedure can successfully conclude.

6c.3 SRVCC Support for UEs in Normal Mode

If the MSC enhanced for PS to CS SRVCC has a SIP interface, it shall use the mechanism specified in TS 24.229 [26] additionally to carry the equipment identifier to the EATF.

If the MSC Server is enhanced for ICS as defined in TS 23.292 [5], then it performs IMS registration after the transfer of the session is completed successfully.

If the MSC enhanced for PS to CS SRVCC does not have a SIP interface, it shall convey the equipment identifier by using the IAM message to the MGCF. The MGCF shall use the mechanism specified in TS 24.229 [26] additionally to carry the equipment identifier to the EATF.

The EATF can then correlate the call legs according to the equipment identifier.

NOTE: The method for correlation of the call legs at the EATF if SIP or ISUP does not provide this information is implementation and configuration dependant.

6c.4 SRVCC Support for UEs in Limited Service Mode

To support SRVCC procedure for UEs in Limited Service Mode for PS to CS, the MSC enhanced for SRVCC will setup the call leg towards the EATF with the UE’s equipment identifier.

If the MSC enhanced for PS to CS SRVCC has a SIP interface, it shall use the mechanism specified in TS 24.229 [26] to carry equipment identifier to the EATF.

If the MSC enhanced for PS to CS SRVCC does not have a SIP interface, it shall convey the equipment identifier by using the IAM message to the MGCF. The MGCF shall use the mechanism specified in TS 24.229 [26] to carry equipment identifier to the EATF.

NOTE: The method for correlation of the call legs at the EATF if SIP or ISUP does not provide this information is implementation dependant.