6.2.2 Call flows for (v)SRVCC from E-UTRAN

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 (v)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 (v)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 (v)SRVCC".

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

6.2.2.1 SRVCC from E-UTRAN to GERAN without DTM support

Depicted in figure 6.2.2.1-1 is a call flow for SRVCC from E-UTRAN to GERAN without DTM support. The flow requires that eNB can determine that the target is GERAN without DTM support or that the UE is without DTM support.

Figure 6.2.2.1-1: SRVCC from E-UTRAN to GERAN without DTM support

1. UE sends measurement reports to E-UTRAN.

2. Based on UE measurement reports the source E‑UTRAN decides to trigger an SRVCC handover to GERAN.

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

4. Based on the QCI associated with the voice bearer (QCI 1) and the SRVCC HO indication, the source MME 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. The MME sends a SRVCC PS to CS Request (IMSI, Target ID, STN-SR, C‑MSISDN, generic Source to Target Transparent Container, MM Context, Emergency Indication) message to the MSC Server. If SRVCC with priority is supported, the MME also includes priority indication in SRVCC PS to CS Request if it detects the SRVCC requires priority handling. The detection is based on the ARP associated with the EPS bearer used for IMS signalling. The priority indication corresponds to the ARP information element. The Emergency Indication and the equipment identifier are included if the ongoing session is emergency session. Authenticated IMSI and C‑MSISDN shall also be included, if available. The MME received STN-SR and C‑MSISDN from the HSS as part of the subscription profile downloaded during the E‑UTRAN attach procedure. The MM Context contains security related information. CS security key is derived by the MME from the E‑UTRAN/EPS domain key as defined in TS 33.401 [22]. The CS Security key is sent in the MM Context.

6. The MSC Server interworks the PS-CS handover request with a CS inter‑MSC handover request by sending a Prepare Handover Request message to the target MSC. If SRVCC with priority is supported, and the MSC Server receives the priority indication (i.e. ARP) in the SRVCC PS to CS Request, the MSC server/MGW sends Prepare Handover Request message to the Target MSC with priority indication mapped from the ARP. The MSC Server maps the ARP to the priority level, pre-emption capability/vulnerability for CS services based on local regulation or operator settings. The priority indication indicates the CS call priority during handover as specified in TS 48.008 [23] for GSM/EDGE. The MSC Server assigns a default SAI as Source ID on the interface to the target BSS and uses BSSMAP encapsulated for the Prepare Handover Request.

NOTE 1: The value of the default SAI is configured in the MSC and allows a release 8 and later BSC to identify that the source for the SRVCC Handover is E-UTRAN. To ensure correct statistics in the target BSS the default SAI should be different from the SAIs used in UTRAN.

7. Target MSC performs resource allocation with the target BSS by exchanging Handover Request/ Acknowledge messages. If the MSC Server indicated priority, the target BSS allocates the radio resource based on the existing procedures with priority indication, as specified in TS 23.009 [18] and in TS 48.008 [23] for GSM/EDGE.

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. If this is a priority session, the MSC Server includes priority indication to the IMS and the IMS entity handles the session transfer procedure with priority. The priority indication in the Session Transfer is mapped by the MSC Server from the priority indication (i.e. ARP) in the SRVCC PS to CS Request received in step 5. The mapping of the priority level is based on operator policy and/or local configuration, and the IMS priority indicator should be the same as for the original IMS created over PS. For emergency session, the MSC Server initiates the Session Transfer by using the locally configured E-STN-SR and by including the equipment identifier. 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 8.

NOTE 3: 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 in 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 as per TS 23.237 [14].

NOTE 4: 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 MME.

14. Source MME sends a Handover Command (Target to Source Transparent Container) message to the source E-UTRAN. The message includes information about the voice component only.

15. Source E-UTRAN sends a Handover from E-UTRAN Command message to the UE.

15a. If the PLMN has configured Secondary RAT usage data reporting and the source eNodeB has Secondary RAT usage data to report, the reporting is performed as specified in TS 23.401 [2].

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 BSS to the target MSC. If the target MSC is not the MSC Server, then the Target MSC sends an SES (Handover Complete) message to the MSC Server.

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 Notification message to the Source MME. The MME returns a Suspend Acknowledge to the Target SGSN.

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

NOTE 6: The MME might not be able to derive the GUTI from the received P-TMSI and RAI pair and therefore it might not be able to identify which UE context is associated with the Suspend Notification message. Also in this case the bearers are deactivated and/or suspended as in step 22a.

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

NOTE 7: 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 MME, informing it that the UE has arrived on the target side. Source MME acknowledges the information by sending a SRVCC PS to CS Complete Acknowledge message to the MSC Server.

22a. The MME deactivates bearers used for voice and other GBR bearers. All GBR bearers are deactivated towards S-GW and P-GW by initiating MME-initiated Dedicated Bearer Deactivation procedure as specified in TS 23.401 [2]. PS-to-CS handover indicator is notified to P-GW for voice bearer during the bearer deactivation procedure. For GTP-based S5/S8, the S-GW requests the P-GW to delete all GBR bearer contexts by sending a Delete Bearer Command message. If dynamic PCC is deployed, the P‑GW may interact with PCRF as defined in TS 23.203 [32]. For PMIP-based S5/S8, S-GW interacts with the PCRF which in turn updates PCC rules for GBR traffic in the P-GW.

The MME starts preservation and suspension of non-GBR bearers by sending Suspend Notification message towards S-GW. For these non-GBR bearers, the S-GW releases S1-U bearers for the UE and sends Suspend Notification message to the P-GW(s). The MME 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 MME requests the release of the resources, including release of the S1 signalling connection, to the Source eNodeB. The Source eNodeB releases its resources related to the UE and responds back to the MME.

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 8: The TMSI reallocation is performed by the MSC Server towards the UE via target MSC.

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

23b. For non-emergency sessions and 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 10: This Update Location is not initiated by the UE.

24. For an emergency services session after handover is complete, the source MME 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 11: Any configuration of the choice between a source MME 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 for any other reason specified in TS 24.008 [44]), then the UE shall resume PS services as specified in TS 23.060 [10]. A Gn SGSN will follow TS 23.060 [10] to resume the PDP Context(s). An S4-SGSN will 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. If the UE has returned to E-UTRAN after the CS voice call was terminated, then the UE shall resume PS service by sending TAU to MME. The MME 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.2.2.1A SRVCC from E-UTRAN to GERAN with DTM but without DTM HO support and from E-UTRAN to UTRAN without PS HO

The call flow for this scenario is similar to the call flow depicted in figure 6.2.2.1‑1, with the exceptions that the Suspend procedure (step 18 and step 22a in figure 6.2.2.1-1) is not performed and that the MME only deactivates bearers used for voice (step 22a in figure 6.2.2.1-1) and sets the PS-to-CS handover indicator. The scenario requires that eNB 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.

NOTE: The eNB can be configured to use this procedure according to operator’s policy when 5GS is deployed.

The message in step 3 in figure 6.2.2.1-1 includes an indication to the MME that the UE is available for PS service in the target cell. Furthermore, if the target is GERAN, the E‑UTRAN places in the generic Source to Target Transparent Container the "old BSS to new BSS information IE", while if the target is UTRAN, the generic Source to Target Transparent container is encoded according to the Source RNC to Target RNC Transparent Container IE definition. At the end of the procedure described in figure 6.2.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.2.2.2 SRVCC from E-UTRAN to UTRAN with PS HO or GERAN with DTM HO support

Depicted in figure 6.2.2.2-1 is a call flow for SRVCC from E‑UTRAN to UTRAN or GERAN with DTM HO support, including the handling of the non‑voice component. The flow requires that eNB can determine that either the target is UTRAN with PS HO or the target is GERAN with DTM support and the UE is supporting DTM.

Figure 6.2.2.2-1: SRVCC from E-UTRAN to UTRAN with PS HO or GERAN with DTM HO support

1. UE sends measurement reports to E-UTRAN.

2. Based on UE measurement reports the source E‑UTRAN decides to trigger an SRVCC handover to UTRAN/GERAN.

3. If target is UTRAN, the source E‑UTRAN sends a Handover Required (Target ID, generic Source to Target Transparent Container, SRVCC HO indication) message to the source MME. SRVCC HO indication indicates to MME that this is for CS+PS HO.

NOTE 1: When the source E-UTRAN indicates using SRVCC HO Indication that target is both CS and PS capable and this is a CS+PS HO request, the source MME sends the single received transparent container to both the target CS domain and the target PS domain.

If target is GERAN, the source E UTRAN sends a Handover Required (Target ID, generic Source to Target Transparent Container, additional Source to Target Transparent Container, SRVCC HO Indication) message to the source MME. The E‑UTRAN places the "old BSS to new BSS information IE" for the CS domain in the additional Source to Target Transparent Container. The differentiation between CS and PS containers is described in TS 36.413 [30]. In this case, the MME identifies from SRVCC HO Indication that this is a request for a CS+PS handover.

4. Based on the QCI associated with the voice bearer (QCI 1) and the SRVCC HO Indication, the source MME splits the voice bearer from all other PS bearers and initiates their relocation towards MSC Server and SGSN, respectively.

5a) Source MME 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) message to the MSC Server. If SRVCC with priority is supported, the MME also includes priority indication in SRVCC PS to CS Request if it detects the SRVCC requires priority handling. The detection is based on the ARP associated with the EPS bearer used for IMS signalling. The priority indication corresponds to the ARP information element. The Emergency Indication and the equipment identifier are included if the ongoing session is emergency session. Authenticated IMSI and C‑MSISDN shall also be included if available. The message includes information relevant to the CS domain only. MME received STN-SR and C‑MSISDN from the HSS as part of the subscription profile downloaded during the E‑UTRAN attach procedure. MM Context contains security related information. CS security key is derived by the MME from the E‑UTRAN/EPS domain key as defined in TS 33.401 [22]. The CS Security key is sent in the MM Context.

5b) MSC Server interworks the PS-CS handover request with a CS inter‑MSC handover request by sending a Prepare Handover Request message to the target MSC. If SRVCC with priority is supported and the MSC Server receives the priority indication (i.e. ARP) in the SRVCC PS to CS Request, the MSC server/MGW sends Prepare Handover Request message to the Target MSC with priority indication mapped from the ARP. The MSC Server maps the ARP to the priority level, pre-emption capability/vulnerability for CS services based on local regulation or operator settings. The priority indication indicates the CS call priority during handover as specified in TS 25.413 [11] for UMTS and TS 48.008 [23] for GSM/EDGE. If the target system is GERAN, the MSC Server assigns a default SAI as Source ID on the interface to the target BSS and uses BSSMAP encapsulated for the Prepare Handover Request. If the target system is UTRAN, the MSC Server uses RANAP encapsulated for the Prepare Handover Request.

NOTE 2: The value of the default SAI is configured in the MSC and allows a release 8 and later BSC to identify that the source for the SRVCC Handover is E-UTRAN. To ensure correct statistics in the target BSS the default SAI should be different from the SAIs used in UTRAN.

5c) Target MSC requests resource allocation for the CS relocation by sending the Relocation Request/Handover Request message to the target RNS/BSS. If the MSC Server indicated priority, the RNC/BSS allocates the radio resource based on the existing procedures with priority indication, as specified in TS 23.009 [18] and in TS 25.413 [11] for UMTS and TS 48.008 [23] for GSM/EDGE. If the target RAT is UTRAN, Relocation Request/Handover Request message contains the generic Source to Target Transparent Container. If the target RAT is GERAN, Relocation Request/Handover Request message contains the additional Source to Target Transparent Container.

6. In parallel to the previous step the source MME initiates relocation of the PS bearers. The following steps are performed (for details see TS 23.401 [2] clauses 5.5.2.1 and 5.5.2.3):

a) Source MME sends a Forward Relocation Request (generic Source to Target Transparent Container, MM Context, PDN Connections IE) message to the target SGSN. If the target SGSN uses S4 based interaction with S-GW and P-GW, the PDN Connections IE 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].

NOTE 3: If the target SGSN uses Gn/Gp based interaction with GGSN the Forward Relocation Request will contain PDP Contexts, instead of PDN Connections IE, including bearer information for all bearers except the voice bearer.

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. After the target RNS/BSS receives both the CS relocation/handover request with the PS relocation/handover request, it assigns the appropriate CS and PS resources. The following steps are performed:

a) Target RNS/BSS acknowledges the prepared PS relocation/handover 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 MME.

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

a) Target RNS/BSS acknowledges the prepared CS relocation/handover 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.

NOTE 4: The Target to Source Transparent Container sent to the target SGSN is step 7a and the Target to Source Transparent Container sent to the target MSC in step 8a, include the same allocation of CS and PS resources (e.g. the target BSS includes the same DTM Handover Command in both containers).

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. If this is a priority session, the MSC Server sends the SIP Session Transfer message with the priority indication to the IMS and the IMS entity handles the session transfer procedure with priority. The priority indication in the SIP Session Transfer message is mapped by the MSC Server from the priority indication (i.e. ARP) in the SRVCC PS to CS Request received in step 5. The mapping of the priority level is based on operator policy and/or local configuration, and the IMS priority indicator should be the same as for the original IMS created over PS. For emergency session, the MSC Server initiates the Session Transfer by using the locally configured E-STN-SR and by including the equipment identifier. IMS Service Continuity or Emergency IMS Service Continuity procedures are applied for execution of the Session Transfer, TS 23.237 [14].

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

NOTE 6: 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 7: 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 MME.

13. Source MME synchronises the two prepared relocations and sends a Handover Command (Target to Source Transparent Container) message to the source E‑UTRAN.

NOTE 8: When the target cell is GERAN, the MME may receive different Target to Source Transparent Containers from the MSC Server and from the SGSN, i.e. a "New BSS to Old BSS Information" (see TS 48.008 [23]) may be received from the MSC Server and a "Target BSS to Source BSS Transparent Container" (see TS 48.018 [24]) may be received from the SGSN.

14. E‑UTRAN sends a Handover from E‑UTRAN Command message to the UE.

14a. If the PLMN has configured Secondary RAT usage data reporting and the source eNodeB has Secondary RAT usage data to report, the reporting is performed as specified in TS 23.401 [2].

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

16. Handover Detection at the target RNS/BSS occurs, 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. If the target MSC is not the MSC Server, then the Target MSC sends an SES (Handover Complete) message to the MSC Server. At this stage, the UE re-establishes the connection with the network.

17. The CS relocation/handover 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 MME. Source MME acknowledges the information by sending a SRVCC PS to CS Complete Acknowledge message to the MSC Server.

e) The source MME deactivates the voice bearer towards S-GW/P-GW and sets the PS-to-CS handover indicator to Delete Bearer Command message. This triggers MME-initiated Dedicated Bearer Deactivation procedure as specified in TS 23.401 [2]. The MME does not send deactivation request toward the eNodeB on receiving PS-to-CS Complete Notification in step 17d. If dynamic PCC is deployed, the PGW may interact with PCRF as defined in TS 23.203 [32].

f) 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 9: The TMSI reallocation is performed by the MSC Server towards the UE via target MSC.

NOTE 10: 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 11: This Update Location is not initiated by the UE.

18. In parallel to the previous step, the PS relocation/handover is completed. 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 MME. After having completed step 17e, the source MME acknowledges the information by sending a Forward Relocation Complete Acknowledge message to the target SGSN.

c) When Target SGSN has received the Forward Relocation Complete Ack message from the MME in step 18b, it updates the bearer with S‑GW/P‑GW/GGSN as specified in TS 23.401 [2].

d) The MME sends Delete Session Request to the SGW as defined in TS 23.401 [2].

e) The source MME sends a Release Resources message to the Source eNodeB as defined in TS 23.401 [2]. The Source eNodeB releases its resources related to the UE and responds back to the MME.

NOTE 12: Routing Area Update procedures by the UE are done in accordance with TS 23.401 [2].

19. For an emergency services session after handover is complete, the source MME 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 13: Any configuration of the choice between a source MME 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.

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

6.2.2.3 vSRVCC from E-UTRAN to UTRAN with PS HO support

Depicted in figure 6.2.2.3-1 is the call flow for vSRVCC from E‑UTRAN to UTRAN with PS HO support.

Figure 6.2.2.3-1: vSRVCC handover procedure

1. UE sends measurement reports to E-UTRAN.

2. Based on UE measurement reports and QCI=1 indications, the source E-UTRAN decides to trigger a SRVCC handover to UTRAN.

3. The source E-UTRAN sends a Handover Required (Target ID, generic Source to Target Transparent Container, SRVCC HO indication) message to the source MME. SRVCC HO indication indicates to MME that this is for CS+PS HO.

NOTE 1: When the SRVCC HO Indication indicates that target is both CS and PS capable and this is a CS+PS HO request, the source MME sends the single received transparent container to both the target CS domain and the target PS domain.

4. If the target is UTRAN, and based on the QCI associated with at least one voice bearer (QCI=1) and at least one vSRVCC marked video bearer, the source MME splits the QCI=1 and vSRVCC marked PS bearer from all other PS bearers and initiates their relocation towards MSC Server and SGSN, respectively.

If the target SGSN uses S4 based interaction with S-GW and P-GW, the PDN Connections IE includes bearer information for the all bearer(s) but the QCI=1 and vSRVCC marked PS bearer. If the target SGSN uses Gn/Gp based interaction with P-GW the Forward Relocation Request will contain PDP Contexts, instead of PDN Connections IE, including bearer information for all bearers but the QCI=1 and vSRVCC marked PS bearers.

5a) Source MME initiates the PS-CS handover procedure for the QCI=1 and vSRVCC marked PS bearer by sending a SRVCC PS to CS Request (IMSI, Target ID, STN-SR, C‑MSISDN, Source to Target Transparent Container, MM Context, vSRVCC indicator) message to the MSC Server. If SRVCC with priority is supported, the MME also includes priority indication in SRVCC PS to CS Request if it detects the SRVCC requires priority handling. The detection is based on the ARP associated with the EPS bearer used for IMS signalling. The priority indication corresponds to the ARP information element. MME received STN-SR, vSRVCC flag and C‑MSISDN from the HSS as part of the subscription profile downloaded during the E-UTRAN attach procedure. MM Context contains security related information. CS security key is derived by the MME from the E‑UTRAN/EPS domain key as defined in TS 33.401 [22]. The CS Security key is sent in the MM Context.

5b1) When MSC Server receives from the Sv that this is for vSRVCC, it negotiates with the SCC AS to determine if the last active session is voice or voice and video, and execute the CS HO procedure with the appropriate CS resource request with UTRAN. In this call flow, SCC AS indicates voice and video.

5b2) MSC Server interworks the PS-CS handover request with a CS inter MSC handover request by sending a Prepare Handover Request message to the target MSC. If SRVCC with priority is supported and the MSC Server receives the priority indication (i.e. ARP) in the SRVCC PS to CS Request, the MSC server/MGW sends Prepare Handover Request message to the Target MSC with priority indication mapped from the ARP. The MSC Server maps the ARP to the priority level, pre-emption capability/vulnerability for CS services based on local regulation or operator settings. The priority indication indicates the CS call priority during handover as specified in TS 25.413 [11] for UMTS.

5c) Target MSC requests BS30 resource allocation for the CS relocation by sending the Relocation Request/Handover Request (additional Source to Target Transparent Container) message to the target RNS. If the MSC Server indicated priority, the RNC/BSS allocates the radio resource based on the existing procedures with priority indication, as specified in TS 23.009 [18] and in TS 25.413 [11] for UMTS.

6. In parallel to the previous step the source MME initiates relocation of the PS bearers. The following steps are performed (for details see TS 23.401 [2] clauses 5.5.2.1 and 5.5.2.3):

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

NOTE 2: If the target SGSN uses Gn/Gp based interaction with P-GW the Forward Relocation Request will contain PDP Contexts, instead of PDN Connections IE, including bearer information for all bearers except the QCI=1 and vSRVCC marked PS bearers.

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.

7. After the target RNS receives both the CS relocation/handover request with the PS relocation/handover request, it assigns the appropriate CS and PS resources. The following steps are performed:

a) Target RNS acknowledges the prepared PS relocation/handover 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 MME.

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

a) Target RNS acknowledges the prepared CS relocation/handover 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.

NOTE 3: The Target to Source Transparent Container sent to the target SGSN is step 7a and the Target to Source Transparent Container sent to the target MSC in step 8a, include the same allocation of CS and PS resources.

9. The MSC Server initiates the Session Transfer by using the STN-SR and includes the SDP of the voice and video SDP of the predefined Codecs, which are the default Codecs specified in TS 26.111 [34]. If this is a priority session, the MSC Server sends the SIP Session Transfer message with the priority indication to the IMS and the IMS entity handles the session transfer procedure with priority. The priority indication in the SIP Session Transfer message is mapped by the MSC Server from the priority indication (i.e. ARP) in the SRVCC PS to CS Request received in step 5. The mapping of the priority level is based on operator policy and/or local configuration, and the IMS priority indicator should be the same as for the original IMS created over PS.

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

10. SCC AS detects based on the presence of the video SDP that it needs to perform a vSRVCC HO. The SCC AS performs a remote leg update with the SDP of the CS access leg for the voice and video session. If the video SDP is missing, the SCC AS assumes a SRVCC HO for voice and initiates the release of the video bearer from the remote leg and the access leg.

NOTE 5: If the remote end does not support the predefined Codecs, then the MGW performs the appropriate transcoding.

11. SCC AS releases only the source IMS access leg of the voice session according to TS 23.237 [14].

NOTE 6: 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 MME. The transparent container contains information about the CS bearer reservation.

13. Source MME synchronises the two prepared relocations and sends a Handover Command (Target to Source Transparent Container) message to the source E-UTRAN.

14. E‑UTRAN sends a Handover from E‑UTRAN Command message to the UE. The UE detects the vSRVCC handover.

14a. If the PLMN has configured Secondary RAT usage data reporting and the source eNodeB has Secondary RAT usage data to report, the reporting is performed as specified in TS 23.401 [2].

15. UE tunes to the target UTRAN cell.

16. Handover Detection at the target RNS occurs, then the target RNS 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 to the target MSC. If the target MSC is not the MSC Server, then the Target MSC sends an SES (Handover Complete) message to the MSC Server.

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

a) Target RNS 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].

c1) Predefined Codecs for voice and video as specified in TS 26.111 [34] are initially used by the UE after it has established the circuit bearer to the target MSC. After that, the UE may start the 3G-324M codec negotiation for video (refer to TR 26.911 [35] and ITU T Recommendation H.324 [33], Annex K for H.245 signalling optimizations) if needed.

d1) The source MME deactivates the QCI=1 and vSRVCC marked PS bearers towards S-GW/P-GW and sets the PS-to-CS handover indicator to Delete Bearer Command message. If dynamic PCC is deployed, the PGW may interact with PCRF as defined in TS 23.203 [32].

e) If IMSI is unknown in the VLR, the MSC Server performs a MAP Update Location to the HSS/HLR.

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

f) If the MSC Server performed a MAP Update location in step 17e and if multiple MSC/VLRs serve the same LAI, the MSC Server performs a TMSI reallocation towards the UE using a non-broadcast LAI with its own Network Resource Identifier (NRI).

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

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

b) Target SGSN sends a Forward Relocation Complete message to the source MME. Source MME acknowledges the information by sending a Forward Relocation Complete Acknowledge message to the target SGSN.

c) Target SGSN updates the bearer with S‑GW/P‑GW as specified in TS 23.401 [2].

d) The source MME sends Delete Session Request to the SGW as defined in TS 23.401 [2].

e) The source MME requests the release of the resources, including release of the S1 signalling connection, to the Source eNodeB as defined in TS 23.401 [2]. The Source eNodeB releases its resources related to the UE and responds back to the MME.

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

6.2.2.4 vSRVCC from E-UTRAN to UTRAN without PS HO support

The call flow for this scenario is similar to the call flow depicted in figure 6.2.2.3 1, with the exceptions that the PS HO procedure (step 6 and 7) is not performed. The scenario requires that E-UTRAN can determine that the target is UTRAN (HSPA) without PS HO support. The message in step 3 in figure 6.2.2.1-1 includes an indication to the MME that the UE is available for PS service in the target cell. At the end of the procedure, the UE re-establishes the PS resources by performing the Routeing Area Update procedure as described in TS 23.060 [10] and in TS 23.401 [2].