6.3.2 Call flows for SRVCC from UTRAN (HSPA)

23.2163GPPRelease 16Single Radio Voice Call Continuity (SRVCC)Stage 2TS

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

NOTE 1: If the MSC Server enhanced for SRVCC controls the target BSS/RNS, the steps depicted with dot-dashed arrows representing the MSC-MSC handover procedure defined in TS 23.009 [18] are not executed and the functions of the MSC Server enhanced for SRVCC are merged with those of the target MSC.

NOTE 2: For the sake of brevity the call flow descriptions use "MSC Server" instead of "MSC Server enhanced for SRVCC".

NOTE 3: The target MSC need not be enhanced for SRVCC.

6.3.2.1 SRVCC from UTRAN (HSPA) to GERAN without DTM support

Depicted in figure 6.3.2.1-1 is a call flow for SRVCC from HSPA to GERAN without DTM support. The flow requires that NB can determine that the target is GERAN without DTM support or that the UE is without DTM support.

Figure 6.3.2.1-1: SRVCC from UTRAN (HSPA) to GERAN without DTM support

1. UE sends measurement reports to Source UTRAN (HSPA).

2. Based on UE measurement reports the source UTRAN (HPSA) decides to trigger a handover to GERAN.

3. Source UTRAN (HSPA) sends Relocation Required (Target ID, Source to Target Transparent Container, SRVCC Handover Indication) message to the source SGSN. The UTRAN (HSPA) includes the "old BSS to new BSS information IE" for the CS domain. The SRVCC Handover Indication indicates to the SGSN that this is a SRVCC handover operation only towards the CS domain. The message includes an indication that the UE is not available for PS service in the target cell.

4. Based on the Traffic Class associated with conversational and Source Statistic Descriptor = speech, and the SRVCC Handover Indication the source SGSN splits the voice bearer from the non-voice bearers and initiates the PS-CS handover procedure for the voice bearer only towards MSC server.

5. Source SGSN sends a SRVCC PS to CS Request (IMSI, Target ID, STN-SR, C‑MSISDN, Source to Target Transparent Container, MM Context, Emergency Indication, Source SAI) message to the MSC Server. The Emergency Indication and the equipment identifier are included if an ongoing session is an emergency session. Authenticated IMSI and C‑MSISDN shall also be included if available. SGSN received the STN-SR and C‑MSISDN from the HSS as part of the subscription profile downloaded during the UTRAN (HSPA) attach procedure. The MM Context contains security related information. The CS Security key is derived by SGSN from the UTRAN (HSPA)/EPS domain key as defined in TS 33.102 [25]. The Source SAI shall be set to the Serving Area Identifier received from the source RNC.

6. The MSC Server interworks the PS handover request with a CS inter-MSC handover request by sending a Prepare Handover Request message to the target MSC. The MSC Server uses BSSMAP encapsulated for the Prepare Handover Request.

7. Target MSC performs resource allocation with the target BSS by exchanging Handover Request/ Acknowledge messages.

8. Target MSC sends a Prepare Handover Response message to the MSC Server.

9. Establishment of circuit connection between the target MSC and the MGW associated with the MSC Server e.g. using ISUP IAM and ACM messages.

10. For non-emergency session, the MSC Server initiates the Session Transfer by using the STN-SR e.g. by sending an ISUP IAM (STN-SR) message towards the IMS. For emergency session, the MSC Server initiates the Session Transfer by using the locally configured E-STN-SR and by including the equipment identifier. Standard IMS Service Continuity or Emergency IMS Service Continuity procedures are applied for execution of the Session Transfer, see TS 23.237 [14].

NOTE 1: This step can be started after step 8.

NOTE 2: If the MSC Server is using an ISUP interface, then the initiation of the session transfer for non-emergency session may fail if the subscriber profile including CAMEL triggers is not available prior handover (see clause 7.3.2.1.3 of TS 23.292 [13]), and can also fail if CAMEL triggers are available and local anchor transfer function is used (see TS 23.237 [14]). If the subscriber profile is available prior handover then CAMEL triggers others than those used in clause 7.3.2.1.3 of TS 23.292 [13] are not used during the transfer.

11. During the execution of the Session Transfer procedure the remote end is updated with the SDP of the CS access leg. The downlink flow of VoIP packets is switched towards the CS access leg at this point.

12. Source IMS access leg is released according to TS 23.237 [14].

NOTE 3: Steps 11 and 12 are independent of step 13.

13. MSC Server sends a SRVCC PS to CS Response (Target to Source Transparent Container) message to the source SGSN.

14. Source SGSN sends a Relocation Command (Target to Source Transparent Container) message to the source UTRAN (HSPA). The message includes information about the voice component only.

15. Source UTRAN (HSPA) sends a Handover Command message to the UE.

16. UE tunes to GERAN.

17. Handover Detection at the target BSS occurs, then the target BSS sends Handover Detection message to the target MSC. At this stage, the target MSC can send/receive voice data. The UE sends a Handover Complete message via the target RNS/BSS to the target MSC.

18. The UE starts the Suspend procedure specified in TS 23.060 [10], clause 16.2.1.1.2. The TLLI and RAI pair are derived from the GUTI as described in TS 23.003 [27]. This triggers the Target SGSN to send a Suspend Request (Gn/Gp SGSN) or Suspend Notification (S4-SGSN) message to the Source SGSN. The Source SGSN returns a Suspend Response or Suspend Acknowledge message to the Target SGSN.

NOTE 4: This step may take place in parallel with steps 19-22.

19. Target BSS sends a Handover Complete message to the target MSC.

NOTE 5: This step may take place immediately after Handover Detection at the target BSS occurs in step 17, before the BSS has received a Suspend message from the UE.

20. Target MSC sends an SES (Handover Complete) message to the MSC Server. The speech circuit is through connected in the MSC Server/MGW according to TS 23.009 [18].

21. Completion of the establishment procedure with ISUP Answer message to the MSC Server according to TS 23.009 [18].

22. MSC Server sends a SRVCC PS to CS Complete Notification message to the source SGSN, informing it that the UE has arrived on the target side. Source SGSN acknowledges the information by sending a SRVCC PS to CS Complete Acknowledge message to the MSC Server.

22a. After the SGSN received a Suspend Request/Notification in step 18, the SGSN behaves as follows:

If the SGSN uses Gn/Gp based interaction with GGSN, then:

– The SGSN deactivates PDP Contexts used for voice and it suspends PDP Contexts using background or interactive class.

– For a PDP Context using streaming or conversational traffic class not used for voice, the PDP Context is preserved and the maximum bitrate is downgraded to 0 Kbit/s.

If the SGSN uses S4 based interaction with S-GW and P-GW, then:

– The SGSN deactivates bearers used for voice and other GBR bearers towards S-GW and P-GW by initiating MS-and SGSN Initiated Bearer Deactivation procedure as specified in TS 23.060 [10]. PS-to-CS handover indicator is notified to P‑GW for voice bearer during the bearer deactivation procedure.

– If dynamic PCC is deployed, the P‑GW may interact with PCRF as defined in TS 23.203 [32].

– The SGSN starts preservation and suspension of non-GBR bearers by sending Suspend Notification message towards S-GW. The S-GW releases all RNC related information (address and TEIDs) for the UE if Direct Tunnel is established, and sends Suspend Notification message to the P-GW(s).

The SGSN stores in the UE context that UE is in suspended status. All the preserved non-GBR bearers are marked as suspended status in the S-GW and P-GW. The P-GW should discard packets if received for the suspended UE.

22b) The source SGSN sends a Iu Release Command to the Source RNC. The Source RNC releases its resources related to the UE and responds with an Iu Release Complete message.

23a. For non-emergency sessions and if the HLR is to be updated, i.e. if the IMSI is authenticated but unknown in the VLR, the MSC Server performs a TMSI reallocation towards the UE using its own non-broadcast LAI and, if the MSC Server and other MSC/VLRs serve the same (target) LAI, with its own Network Resource Identifier (NRI).

NOTE 6: The TMSI reallocation is performed by the MSC Server towards the UE via target MSC.

NOTE 7: For emergency services sessions the HLR will not be updated. TMSI reallocation may be performed based on IMSI presence.

23b. For non-emergency sessions if the MSC Server performed a TMSI reallocation in step 23a, and if this TMSI reallocation was completed successfully, the MSC Server performs a MAP Update Location to the HSS/HLR.

NOTE 8: This Update Location is not initiated by the UE.

24. For an emergency services session after handover is complete, the source SGSN or the MSC Server may send a Subscriber Location Report carrying the identity of the MSC Server to a GMLC associated with the source or target side, respectively, as defined in TS 23.271 [29] to support location continuity.

NOTE 9: Any configuration of the choice between a source SGSN versus MSC Server update to a GMLC needs to ensure that a single update occurs from one of these entities when the control plane location solution is used on the source and/or target sides.

After the CS voice call is terminated and if the UE is still in GERAN or UTRAN (or for any other reason according to TS 24.008 [44]), then the UE shall resume PS services (as specified in TS 23.060 [10]). A Gn/Gp SGSN will follow TS 23.060 [10] to resume the PDP Context(s). An S4-SGSN will also follow TS 23.060 [10] to resume the bearers, and will in addition inform S-GW and P-GW(s) to resume the suspended bearers. Resuming the suspended bearers in the S-GW and in the P-GW should be done by implicit resume using the Modify Bearer request message if it is triggered by the procedure in operation, e.g. RAU, TAU or Service Request. The S-GW is aware of the suspend state of the bearers and will forward the Modify Bearer request to the P-GW. Explicit resume using the Resume Notification message should be used in cases when Modify Bearer Request is not triggered by the procedure in operation.

6.3.2.1A SRVCC from UTRAN (HSPA) to GERAN with DTM but without DTM HO support and from UTRAN (HSPA) to UTRAN without PS HO

The call flow for this scenario is similar to the call flow depicted in figure 6.3.2.1‑1, with the exceptions that the Suspend procedure (step 18 and step 22a in figure 6.3.2.1‑1) is not performed and that the source SGSN only deactivates bearers used for voice and sets the PS-to-CS handover indicator. The scenario requires that NB can determine that the target is either GERAN with DTM but without DTM HO support and that the UE is supporting DTM or that the target is UTRAN (HSPA) without PS HO support. The message in step 3 in figure 6.3.2.1 1 includes an indication to the SGSN that the UE is available for PS service in the target cell. At the end of the procedure described in figure 6.3.2.1‑1, the remaining PS resources are re-established when the UE performs the Routeing Area update procedure. Triggers for performing Routeing Area update procedure are described in TS 23.060 [10]. The target SGSN may deactivate the PDP contexts that cannot be established as described in TS 23.060 [10].

6.3.2.2 SRVCC from UTRAN (HSPA) to UTRAN or GERAN with DTM HO support

Depicted in figure 6.3.2.2-1 is a call flow for SRVCC from UTRAN (HSPA) to UTRAN or GERAN with DTM HO support, including the handling of the non-voice component.

Figure 6.3.2.2-1: SRVCC from UTRAN (HSPA) to UTRAN or GERAN with DTM HO support

1. UE sends measurement reports to Source UTRAN (HSPA).

2. Based on UE measurement reports the source UTRAN (HSPA) decides to trigger a handover to UTRAN/GERAN.

2a. In the case of SRVCC to UTRAN the RNC shall initiate the SRVCC Preparation procedure by sending an SRVCC CS KEYS REQUEST message to the source SGSN.

2b. The SGSN shall respond to the RNC with SRVCC CS KEYS RESPONSE message containing the Integrity Protection Key IE, the Encryption Key IE and the SRVCC Information IE.

3. If target is UTRAN, the source UTRAN (HSPA) sends a Relocation Required (Target ID, Source RNC to Target RNC Transparent Container, SRVCC Handover Indication) message to the source SGSN. UTRAN (HSPA) also indicates to SGSN that this is for CS+PS HO.

NOTE 1: When the source UTRAN (HSPA) indicates that this is a CS+PS HO request, the source SGSN sends the single received transparent container to both the target CS domain and the target PS domain.

If target is GERAN, the source UTRAN (HSPA) sends a Relocation Required (Target ID, Old BSS to New BSS Information IE for the CS domain and Source BSS to Target BSS Transparent Container for the PS Domain, SRVCC Handover Indication) message to the source SGSN. The differentiation between CS and PS containers is described in TS 25.413 [11]. In this case, the SGSN identifies from the SRVCC Handover Indication that this is a request for a CS+PS handover.

4. Based on the Traffic Class associated with conversational and Source Statistic Descriptor = speech, and the SRVCC Handover Indication the Source SGSN splits the voice bearer from all other PS bearers and initiates their relocation towards MSC Server and SGSN, respectively.

5a) Source SGSN initiates the PS-CS handover procedure for the voice bearer by sending a SRVCC PS to CS Request (IMSI, Target ID, STN-SR, C‑MSISDN, Source to Target Transparent Container, MM Context, Emergency Indication, Source SAI) message to the MSC Server. The Emergency Indication and the equipment identifier are included if the ongoing session is emergency session. Authenticated IMSI and C‑MSISDN shall be included if available. The message includes information relevant to the CS domain only. SGSN received STN-SR and C‑MSISDN from the HSS as part of the subscription profile downloaded during the UTRAN (HSPA) attach procedure. MM Context contains security related information. The CS Security key is derived by the SGSN from the UTRAN (HSPA)/EPS domain key as defined in TS 33.102 [25]. If the target system is GERAN, the Source SAI shall be set to the Serving Area Identifier received from the source RNC.

5b) MSC Server interworks the PS handover request with a CS inter-MSC handover request by sending a Prepare Handover Request message to the target MSC. If the target system is GERAN, MSC Server uses BSSMAP encapsulated for the Prepare Handover Request. If the target system is UTRAN, MSC Server uses RANAP encapsulated for the Prepare Handover Request.

5c) Target MSC requests resource allocation for the CS relocation by sending the Relocation Request/Handover Request (Source to Target Transparent Container) message to the target RNS/BSS.

6. In parallel to the previous step the source SGSN initiates relocation of the PS bearers. The following steps are performed (for details see TS 23.060 [10]):

a) If the target SGSN uses S4 based interaction with S‑GW and P‑GW, the source SGSN sends a Forward Relocation Request (Source to Target Transparent Container, MM Context, PDP Context) message to the target SGSN. The PDP Context includes bearer information for all bearers except the voice bearer. The handling of security keys for PS handover of the remaining non-voice PS bearers is specified in TS 33.401 [22].

If the target SGSN uses Gn/Gp based interaction with GGSN, the Source SGSN sends a Forward Relocation Request (Source to Target Transparent Container, MM Context and PDP Context) message to the target SGSN. The PDP Context includes bearer information for all bearers except the voice bearer. The handling of security keys for PS handover of the remaining non-voice PS bearers is specified in TS 33.102 [25].

b) Target SGSN requests resource allocation for the PS relocation by sending the Relocation Request/Handover Request (Source to Target Transparent Container) message to the target RNS/BSS.

7. Target RNS/BSS coordinates the CS relocation request with the PS relocation request and assigns resources. The following steps are performed:

a) Target RNS/BSS acknowledges the prepared PS relocation by sending the Relocation Request Acknowledge/Handover Request Acknowledge (Target to Source Transparent Container) message to the target SGSN.

b) Target SGSN sends a Forward Relocation Response (Target to Source Transparent Container) message to the source SGSN.

8. In parallel to the previous step the following steps are performed:

a) Target RNS/BSS acknowledges the prepared CS relocation by sending the Relocation Request Acknowledge/Handover Request Acknowledge (Target to Source Transparent Container) message to the target MSC.

b) Target MSC sends a Prepare Handover Response (Target to Source Transparent Container) message to the MSC Server.

c) Establishment of circuit connection between the target MSC and the MGW associated with the MSC Server e.g. using ISUP IAM and ACM messages.

9. For non-emergency session, the MSC Server initiates the Session Transfer by using the STN-SR e.g. by sending an ISUP IAM (STN-SR) message towards the IMS. For emergency session, the MSC Server initiates the Session Transfer by using the locally-configured E-STN-SR and by including the equipment identifier. Standard IMS Service Continuity or Emergency IMS Service Continuity procedures are applied for execution of the Session Transfer, see TS 23.237 [14].

NOTE 2: This step can be started after step 8b.

NOTE 3: If the MSC Server is using an ISUP interface, then the initiation of the session transfer for non-emergency sessions may fail if the subscriber profile including CAMEL triggers is not available prior handover (see clause 7.3.2.1.3 of TS 23.292 [13]), and can also fail if CAMEL triggers are available and local anchor transfer function is used (see TS 23.237 [14]). If the subscriber profile is available prior handover then CAMEL triggers others than those used in clause 7.3.2.1.3 of TS 23.292 [13] are not used during the transfer.

10. During the execution of the Session Transfer procedure the remote end is updated with the SDP of the CS access leg according to TS 23.237 [14]. The downlink flow of VoIP packets is switched towards the CS access leg at this point.

11. The source IMS access leg is released according to TS 23.237 [14].

NOTE 4: Steps 10 and 11 are independent of step 12.

12. The MSC Server sends a SRVCC PS to CS Response (Target to Source Transparent Container) message to the source SGSN.

13. Source SGSN synchronises the two prepared relocations and sends a Relocation Command (Target to Source Transparent Container) message to the source UTRAN (HSPA). If the target is GERAN, the source RNC shall receive the SRVCC Information IE containing the NONCE IE.

14. UE tunes to the target UTRAN/GERAN cell.

15. UTRAN (HSPA) sends a Handover Command message to the UE.

16. Handover Detection at the target RNS/BSS, then the target RNS/BSS sends Handover Detection message to the target MSC. At this stage, the target MSC can send/receive voice data. The UE sends a Handover Complete message via the target RNS/BSS to the target MSC.

17. The CS relocation is complete. The following steps are performed:

a) Target RNS/BSS sends Relocation Complete/Handover Complete message to the target MSC.

b) Target MSC sends an SES (Handover Complete) message to the MSC Server. The speech circuit is through connected in the MSC Server/MGW according to TS 23.009 [18].

c) Completion of the establishment procedure with ISUP Answer message to the MSC Server according to TS 23.009 [18].

d) MSC Server sends a SRVCC PS to CS Complete Notification message to the source SGSN. Source SGSN acknowledges the information by sending a SRVCC PS to CS Complete Acknowledge message to the MSC Server.

e) The source SGSN deletes the voice bearer towards GGSN/S-GW/P-GW and sets the PS-to-CS handover indicator. If dynamic PCC is deployed, the PGW may interact with PCRF as defined in TS 23.203 [32].

f) For non-emergency sessions if the HLR is to be updated, i.e. if the IMSI is authenticated but unknown in the VLR, the MSC Server performs a TMSI reallocation towards the UE using its own non-broadcast LAI and, if the MSC Server and other MSC/VLRs serve the same (target) LAI, with its own Network Resource Identifier (NRI).

NOTE 5: The TMSI reallocation is performed by the MSC Server towards the UE via target MSC.

NOTE 6: For emergency services sessions the HLR will not be updated. TMSI reallocation may be performed based on IMSI presence.

g) For non-emergency sessions if the MSC Server performed a TMSI reallocation in step 17f, and if this TMSI reallocation was completed successfully, the MSC Server performs a MAP Update Location to the HSS/HLR.

NOTE 7: this Update Location is not initiated by the UE.

18. In parallel to the previous step, the PS relocation is complete. The following steps are performed:

a) Target RNS/BSS sends Relocation Complete/Handover Complete message to target SGSN.

b) Target SGSN sends a Forward Relocation Complete message to the source SGSN. After having completed step 17e, source SGSN acknowledges the information by sending a Forward Relocation Complete Acknowledge message to the target SGSN.

c) Target SGSN updates the bearer with GGSN/S‑GW/P‑GW.

d) The Source S4-SGSN sends delete Session Request to the SGW as defined in TS 23.401 [2].

e) The source SGSN sends a Iu Release Command to the Source RNC. The Source RNC releases its resources related to the UE and responds with an Iu Release Complete message.

NOTE 8: Routing Area Update procedures by the UE are done in accordance with TS 23.060 [10].

19. For an emergency services session after handover is complete, the source SGSN or the MSC Server may send a Subscriber Location Report carrying the identity of the MSC Server to a GMLC associated with the source or target side, respectively, as defined in TS 23.271 [29] to support location continuity.

If the SGSN determines that only the relocation of the voice bearer but not the relocation of one or more PS bearers succeeds, then the SGSN proceeds step13 after receiving SRVCC PS to CS Response from the MSC Server in step 12 and both UE and SGSN continue the procedure described in clause 6.3.2.1A.