GPRS attach procedure for 3GPP SRVCC UE is performed as defined in TS 23.060 with the following additions:
SRVCC UE includes the SRVCC capability indication as part of the "MS Network Capability" in the Attach Request message and in Routeing Area Updates. SGSN stores this information for SRVCC operation.
SRVCC UE includes the GERAN MS Classmark 3 (if GERAN access is supported), MS Classmark 2 and Supported Codecs IE in the Attach Request message and in the non-periodic Routeing Area Update messages.
HSS includes STN-SR and C-MSISDN as part of the subscription data sent to the SGSN. If the STN-SR is present, it indicates the UE is SRVCC subscribed. If a roaming subscriber is determined by the HPLMN not allowed to have SRVCC in the VPLMN then HSS does not include STN-SR and C-MSISDN as part of the subscription data sent to the SGSN.
SGSN includes a "SRVCC operation possible" indication in the RANAP Common ID message, meaning that both UE and SGSN are SRVCC-capable.
GPRS emergency attach procedure for 3GPP SRVCC UE is performed as defined in TS 23.060 and above with the following clarifications:
SRVCC UE shall include the SRVCC capability indication as part of the "MS Network Capability" in the Emergency Attach Request message and maintained during Routeing Area Updates. SGSN stores this information for SRVCC operation.
Intra-UTRAN (HSPA) SRNS Relocation procedure for 3GPP SRVCC UE are performed as defined in TS 23.060 and UTRAN (HSPA) Iu mode to E-UTRAN Inter RAT handover are performed as defined in TS 23.401, with the following additions:
MS Classmark 2, MS Classmark 3, STN-SR, C-MSISDN, ICS Indicator and the Supported Codec IE shall be sent from the source SGSN to the target SGSN/MME if available.
The target SGSN includes a "SRVCC operation possible" indication in the RANAP Common ID message, meaning that both UE and the target SGSN are SRVCC-capable.
The target MME includes a "SRVCC operation possible" indication in the S1-AP Handover Request message, meaning that both UE and the target MME are SRVCC-capable.
Depicted in Figure 220.127.116.11-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.
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.
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.
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. The Source SAI shall be set to the Serving Area Identifier received from the source RNC.
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.
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.
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.
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.
The UE starts the Suspend procedure specified in clause 18.104.22.168.2 of TS 23.060. The TLLI and RAI pair are derived from the GUTI as described in TS 23.003. 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.
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.
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. 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.
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.
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).
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.
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 to support location continuity.
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), then the UE shall resume PS services (as specified in TS 23.060). A Gn/Gp SGSN will follow TS 23.060 to resume the PDP Context(s). An S4-SGSN will also follow TS 23.060 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.
The call flow for this scenario is similar to the call flow depicted in Figure 22.214.171.124-1, with the exceptions that the Suspend procedure (step 18 and step 22a in Figure 126.96.36.199-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 188.8.131.52-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 184.108.40.206-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. The target SGSN may deactivate the PDP contexts that cannot be established as described in TS 23.060.