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

NAS Elementary procedures for EPS session management

EPS session management procedures are used at the radio interface "LTE-Uu". The main function of the ESM sublayer is to support the EPS bearer context handling in the UE and in the MME.

The ESM comprises procedures for:

- the activation, deactivation and modification of EPS bearer contexts; and

- the request for resources (IP connectivity to a PDN or dedicated bearer resources) by the UE.

Each EPS bearer context represents an EPS bearer between the UE and a PDN. EPS bearer contexts can remain activated even if the radio and S1 bearers constituting the corresponding EPS bearers between UE and MME are temporarily released.

An EPS bearer context can be either a default bearer context or a dedicated bearer context. A default EPS bearer context is activated when the UE requests a connection to a PDN. Generally, ESM procedures can be performed only if an EMM context has been established between the UE and the MME, and the secure exchange of NAS messages has been initiated by the MME by use of the EMM procedures. The first default EPS bearer context, however, is activated during the EPS attach procedure. Once the UE is successfully attached, the UE can request the MME to set up connections to additional PDNs. For each additional connection, the MME will activate a separate default EPS bearer context. A default EPS bearer context remains activated throughout the lifetime of the connection to the PDN.

A dedicated EPS bearer context is always linked to a default EPS bearer context and represents additional EPS bearer resources between the UE and the PDN. The network can initiate the activation of dedicated EPS bearer contexts together with the activation of the default EPS bearer context or at any time later, as long as the default EPS bearer context remains activated.

Default and dedicated EPS bearer contexts can be modified. Dedicated EPS bearer contexts can be released without affecting the default EPS bearer context. When the default EPS bearer context is released, then all dedicated EPS bearer contexts linked to it are released, too.

The UE can request the network to allocate, modify or release additional EPS bearer resources. The network decides whether to fulfil a request for additional resources by activating a new dedicated EPS bearer context or modifying an existing dedicated or default EPS bearer context.

Types of ESM procedures

1) Procedures related to EPS bearer contexts:

These procedures are initiated by the network and are used for the manipulation of EPS bearer contexts:

• Default EPS bearer context activation;
• Dedicated EPS bearer context activation;
• EPS bearer context modification;
• EPS bearer context deactivation.

2) Transaction related procedures:

These procedures are initiated by the UE to request for resources, i.e. a new PDN connection or dedicated bearer resources, or to release these resources:

• PDN connectivity procedure;
• PDN disconnect procedure;
• Bearer resource allocation procedure;
• Bearer resource modification procedure.

When combined with the attach procedure, the PDN connectivity procedure can trigger the network to execute the following transaction related procedure:

• ESM information request procedure.