SRVCC between LTE and 3GPP2 1xCS

Basics:

• 1xCS: The 3GPP2 legacy circuit switched signalling system as defined in 3GPP2 X.S0042-0
• 3GPP SRVCC UE: A 3GPP SRVCC UE is a UE enhanced for IMS Service Continuity with the additional UE capabilities such as SRVCC between E-UTRAN and 3GPP UTRAN and / or between E-UTRAN and 3GPP GERAN and / or between UTRAN (HSPA) and 3GPP UTRAN and 3GPP GERAN.

Concept:

For SRVCC-capable UEs, the call is always anchored at the VCC AS in the 3GPP2's IMS. The 3GPP2 1xCS IWS enables a single radio UE to communicate in parallel both with the source system and the target system. From VCC perspective, this mechanism minimizes the voice gap by supporting the transport of signalling for establishment of the target CS access leg while the terminal is connected to the source PS access network.

Transport of 3GPP2 1xCS signalling messages for preparation of the CS access leg in the target system

The S102 reference point is used to convey 3GPP2 1xCS signalling messages between the MME and 3GPP2 1xCS IWS. These 1x CS signalling messages are actually exchanged between the UE and the 3GPP2 1xCS IWS, and S102 is only one link in the overall UE 1xCS IWS tunnelling path. On the remaining portion of the tunnelling path, the 3GPP2 1xCS signalling messages are encapsulated in E UTRAN/EPS tunnelling messages (UE MME).

E-UTRAN and 3GPP2 1xCS SRVCC architecture

SRVCC architecture for E-UTRAN to 3GPP2 1xCS

Call flows for SRVCC from E-UTRAN

LTE VoIP-to-1x CS voice service continuity

1. Ongoing VoIP session over the IMS access leg established over EPS/E UTRAN access.

2. 1xCS SRVCC UE sends measurement reports to eNodeB.

3. The E UTRAN (e.g., based on some trigger, measurement reports) makes a determination to initiate an inter technology handover to cdma2000 1xRTT.

4. The E UTRAN signals the UE to perform an inter technology handover by sending a Handover from EUTRA Preparation Request message.

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 in the case of UE operating in Limited Service Mode the MEID (e.g. IMEI) is included.

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.

7. Upon reception of the Uplink S1 cdma2000 Tunnelling message, the MME selects a 3GPP2 1xCS IWS based on Reference CellID and encapsulates the 1x Origination Message along with the MEID and RAND in a S102 Direct Transfer message (as "1x Air Interface Signalling").

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].

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.

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.

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.

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).

13. The UE sends a 1xRTT handoff completion message to the 1xRTT CS access (e.g., 1xRTT BSS).

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.

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.

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.

17. The MME exchanges Suspend Request/ Acknowledge messages with the S GW / P GW. The S1-U bearers are released for all EPS bearers and the GBR bearers are deactivated by the MME. The non-GBR bearers are preserved and are marked as suspended in the S GW / P GW. Upon receipt of downlink data the S GW should not send a downlink data notification message to the MME.

18. S1 UE Context in the eNodeB is released as specified in TS 23.401 [2].

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 an indication of the 1xRTT MSC (e.g. reference cell ID) to the GMLC associated with the source side 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.

Single Radio Voice Call Continuity (SRVCC)

SRVCC is an LTE functionality that allows a VoIP/IMS call in the LTE packet domain to be moved to a legacy voice domain (GSM/UMTS or CDMA 1x).

Consider a case where a new LTE network operator wants to move voice services to VoIP over IMS in conjunction with the deployment of an LTE access network. In the absence of other options, this operator would need to provide ubiquitous LTE coverage on day 1 to have a competitive VoIP service. However SRVCC enabled LTE may not require complete LTE coverage.

SRVCC provides the ability to transition a voice call from the VoIP/IMS packet domain to the legacy circuit domain. Variations of SRVCC are being standardized to support both GSM/UMTS and CDMA 1x circuit domains. For an operator with a legacy cellular network who wishes to deploy IMS/VoIP-based voice services in conjunction with the rollout of an LTE network, SRVCC offers VoIP subscribers with coverage over a much larger area than would typically be available during the rollout of a new network.

SRVCC functions as follows. As an SRVCC-capable UEe engaged in a voice call determines that it is moving away from LTE coverage, it notifies the LTE network. The LTE network determines that the voice call needs to be moved to the legacy circuit domain. It notifies the MSC server of the need to switch the voice call from the packet to the circuit domain and initiates a handover of the LTE voice bearer to the circuit network. The MSC server establishes a bearer path for the mobile in the legacy network and notifies the IMS core that the mobile’s call leg is moving from the packet to the circuit domain. The circuit-packet function in the IMS core then performs the necessary inter-working functions. When the mobile arrives on-channel in the legacy network, it switches its internal voice processing from VoIP to legacy-circuit voice, and the call continues.

If the legacy circuit network also has an associated packet capability and is capable of supporting concurrent circuit/packet operations, the subscriber’s data sessions can be handed over to the legacy network in conjunction with switching the voice call from the packet to the circuit domain. In this case when the voice call finishes and the mobile re-enters LTE coverage, these packet sessions can be handed back to the LTE.

If operators look to limit LTE deployments to high traffic areas and at the same time wish to transition voice service in those areas to VoIP, then SRVCC is exactly what they need.

If on the other hand operators do not plan to migrate their voice service to VoIP, then SRVCC is not for them. If an operator does plan to migrate to VoIP and also plans to roll out ubiquitous LTE coverage, then the question of whether or not to adopt SRVCC is more complicated. While SRVCC does not require modifications to what is certainly the operator’s largest legacy investment, the RAN, it does require a significant modification of the operator’s legacy core and also requires full deployment of IMS circuit-packet continuity services. Given the cost of these changes, deployment of SRVCC purely as an interim measure to allow early rollout of VoIP-based services may not make financial sense.

Source: Motorola's WhitePaper on "LTE Inter-technology Mobility"

Timing Advance(TA) in LTE

In GSM system MS sends its data three time slots after it received the data from the BTS. This is ok as long as MS-BTS distance is small but increasing distance requires consideration of propagation delay as well. To handle it Timing advance (TA) is conveyed by network to MS and current value is sent to the MS within the layer 1 header of each SACCH. BTS calculates the first TA when it receives RACH and reports it to the BSC and BSC/BTS passes it to UE during Immediate Assignment.

In UMTS Timing Advance parameter was not used but in LTE Timing Advance is back.

In LTE, when UE wish to establish RRC connection with eNB, it transmits a Random Access Preamble, eNB estimates the transmission timing of the terminal based on this. Now eNB transmits a Random Access Response which consists of timing advance command, based on that UE adjusts the terminal transmit timing.

The timing advance is initiated from E-UTRAN with MAC message that implies and adjustment of the timing advance.

3GPP TA Requirements

• Timing Advance adjustment delay

UE shall adjust the timing of its uplink transmission timing at sub-frame n+6 for a timing advancement command received in sub-frame n.

• Timing Advance adjustment accuracy

The UE shall adjust the timing of its transmissions with a relative accuracy better than or equal to ±4* TS seconds to the signalled timing advance value compared to the timing of preceding uplink transmission. The timing advance command is expressed in multiples of 16* TS and is relative to the current uplink timing.

Maintenance of Uplink Time Alignment

The UE has a configurable timer timeAlignmentTimer which is used to control how long the UE is considered uplink time aligned

• when a Timing Advance Command MAC control element is received then UE applies the Timing Advance Command and start or restart timeAlignmentTimer.
• when a Timing Advance Command is received in a Random Access Response message then one of following action is performed by UE.
  - if the Random Access Preamble was not selected by UE MAC then UE applies the Timing Advance Command and starts or restarts timeAlignmentTimer.
  - else if the timeAlignmentTimer is not running then UE applies the Timing Advance Command starts timeAlignmentTimer; when the contention resolution is considered not successful then UE stops timeAlignmentTimer.
  - else ignore the received Timing Advance Command.
• when timeAlignmentTimer expires UE flushes all HARQ buffers, notifies RRC to release PUCCH/SRS and clears any configured downlink assignments and uplink grants.

Source: LteWorld.org