Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 23.216  Word version:  17.1.0

Top   Top   Up   Prev   Next
1…   4…   4.2…   4.2.4…   4.2.6…   5…   5.2.4…   5.3…   6…   6.2…   6.2.2.2…   6.3…   6.3.2.2   6.4…   6.5…   7…   A…

 

6  Procedures and flowsp. 36

6.1  SRVCC from E-UTRAN to 3GPP2 1xCSp. 36

6.1.1  E-UTRAN Attach procedure for SRVCCp. 36

E-UTRAN attach, emergency attach, or tracking area update procedure for 3GPP2 SRVCC UE is performed as defined in TS 23.401 with the following additions:
  • SRVCC UE includes the SRVCC capability indication as part of the "UE Network Capability" in the Attach Request message or Tracking Area Update Request message. MME stores this information for SRVCC operation.
  • SRVCC UE capable for IMS emergency calls shall include the SRVCC capability indication as part of the UE network capability in the Emergency Attach Request message. MME stores this information for emergency SRVCC operation.
  • MME includes a "SRVCC operation possible" indication in the S1 AP Initial Context Setup Request, meaning that both UE and MME are SRVCC-capable.
Up

6.1.2  Service Request procedures for SRVCCp. 36

Service Request procedures for 3GPP2 SRVCC UE are performed as defined in TS 23.401 with the following additions:
  • MME includes a "SRVCC operation possible" indication in the S1 AP Initial Context Setup Request, meaning that both UE and MME are SRVCC-capable.

6.1.2A  PS Handover procedures for SRVCC |R9|p. 37

Intra-E-UTRAN S1-based handover procedures for 3GPP2 SRVCC UE are performed as defined in TS 23.401 with the following additions:
  • 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.
For X2-based handover, the source eNodeB includes a "SRVCC operation possible" indication in the X2-AP Handover Request message to the target eNodeB as specified in TS 36.423.
Up

6.1.3  Call flows for SRVCC from E-UTRANp. 37

Figure 6.1.3-1 illustrates a high-level call flow for the E-UTRAN-to-1x voice service continuity procedure.
Copy of original 3GPP image for 3GPP TS 23.216, Fig. 6.1.3-1: LTE VoIP-to-1x CS voice service continuity
Up
Step 1.
Ongoing VoIP session over the IMS access leg established over EPS/E-UTRAN access.
Step 2.
1xCS SRVCC UE sends measurement reports to eNodeB.
Step 3.
The E-UTRAN (e.g., based on some trigger, measurement reports) makes a determination to initiate an inter technology handover to cdma2000 1xRTT.
Step 4.
The E-UTRAN signals the UE to perform an inter technology handover by sending a Handover from EUTRA Preparation Request (3G1x Overhead Parameters, RAND value) message.
Step 5.
The UE initiates signalling for establishment of the CS access leg by sending a UL handover preparation Transfer message containing the 1xRTT Origination message. For the case of emergency voice service continuity, the request includes a Request-Type = "emergency handover" and the MEID (e.g. IMEI) is included.
Step 6.
The E-UTRAN sends an Uplink S1 cdma2000 Tunnelling (MEID, RAND, 1x Origination, Reference CellID) message to the MME. The eNodeB will also include CDMA2000 HO Required Indication IE to Uplink S1 CDMA2000 Tunnelling message, which indicates to the MME that the handover preparation has started.
Step 7.
Upon reception of the Uplink S1 cdma2000 Tunnelling message, the MME selects a 3GPP2 1xCS IWS as specified in clause 5.3.3.1.2 and encapsulates the 1x Origination Message along with the MEID and RAND in a S102 Direct Transfer message (as "1x Air Interface Signalling").
Step 8.
The traffic channel resources are established in the 1x RTT system and 3GPP2 1xCS procedures for initiation of Session Transfer are performed as per 3GPP2 X.S0042 [4].
Step 9.
The 3GPP2 1xCS IWS creates a 1x message and encapsulates it in a S102 Direct Transfer message (1x message, Handover indicator). If the 3GPP2 access was able to allocate resources successfully, the 1x message is a 1x Handover Direction message and the handover indicator indicates successful resource allocation. Otherwise, the handover indicator indicates to the MME that handover preparation failed and the embedded 1x message indicates the failure to the UE.
Step 10.
The MME sends the 1x message and CDMA2000 HO Status IE in a Downlink S1 cdma2000 Tunnelling message to the E-UTRAN. The CDMA2000 HO Status IE is set according to the handover indicator received over the S102 tunnel.
Step 11.
If the CDMA2000 HO Status IE indicates successful handover preparation, the E-UTRAN forwards the 1x Handoff Direction message embedded in a Mobility from EUTRA Command message to the UE. This is perceived by the UE as a Handover Command message. If handover preparation failed, DL Information transfer message will be sent instead, with the embedded 1xRTT message that indicates the failure to the UE.
Step 12.
Once the UE receives the traffic channel information from the cdma2000 1xRTT system, the UE retunes to the 1xRTT radio access network and performs traffic channel acquisition with the 1xRTT CS access (e.g., 1xRTT BSS).
Step 13.
The UE sends a 1xRTT handoff completion message to the 1xRTT CS access (e.g., 1xRTT BSS).
Step 14.
The 1xRTT CS Access sends message to 1xRTT MSC to indicate of handoff done. The resources between 1x CS IWS and 1xRTT MSC may be released at this step.
Step 15.
Ongoing voice call over the CS access leg established over 1xRTT access. The E-UTRAN/EPS context may be released based on the normal E-UTRAN/EPS procedure.
Step 16.
The eNodeB sends an S1 UE Context Release Request (Cause) message to the MME. Cause indicates the S1 release procedure is caused by handover from E-UTRAN to 1xRTT.
Step 17.
The MME deactivates GBR bearers towards S-GW and P-GW(s) by initiating MME-initiated Dedicated Bearer Deactivation procedure as specified in TS 23.401. PS-to-CS handover indicator is notified to P-GW for voice bearer during the bearer deactivation procedure. The MME starts preservation and suspension of non-GBR bearers by sending Suspend Notification message towards S-GW. 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 the 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.
Step 18.
S1 UE Context in the eNodeB is released as specified in TS 23.401.
Step 19.
For an emergency services session after handover is complete, if the control plane location solution is used on the source side, the source MME shall send a Subscriber Location Report carrying the reference cell ID to the GMLC associated with the source side as defined in TS 23.271 to support location continuity. This enables location continuity for the 1xRTT side. Alternatively, if the control plane solution is not used on the source side, location continuity procedures shall be instigated on the 1xRTT side.
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. 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.
Up

Up   Top   ToC