Circuit Switched Fallback (CSFB)

CS domain services are the services that can be offered today in GSM-UMTS networks. Examples of such services are: voice and its supplementary services (e.g. call waiting, call forwarding), USSD, LCS, SMS, E911, LI, and even CS DUI video, etc. This rich set of CS domain features and capabilities are the result of years of standardization works in 3GPP and operators investments to their GSM-UMTS network.

In EPS, richer features/services can be offered to the end-user together with voice via IMS. While this is the case for EPS, it is challenging for some operators to launch EPS with data and voice/IMS from day one. Hence, these operators need a migration path to allow them to start from EPS with data only and allow the reuse of CS domain services until they get to the point where IMS voice can be added to the EPS.

Such migration path is possible with CS Fallback (CSFB) feature. CSFB is introduced in 3GPP Rel-8 to allow an UE in EPS to reuse CS domain services by defining how the UE can switch its radio from EUTRAN access to other RAT (e.g. GERAN/UTRAN/1xRTT access) that can support CS domain services. In addition, CSFB specification TS 23.272 also defines how the SMS is transferred to the UE natively via EPS from the MSC. It should be noted that this type of SMS delivery mechanism is defined in CSFB specification but the UE is not falling back to GERAN/UTRAN/1xRTT access.

With CSFB, UE under EPS can enjoy the fast PS data access and can switch over to GERAN/UTRAN/1xRTT access for CS domain services when needed. In addition, UE can also utilize the SMS feature supported by CSFB architecture.

UE, which wants to use CSFB, must first register itself to the CS domain via EPS. For GSM-UMTS CSFB feature, UE performs a combined EPS/IMSI Attach/TAU procedure. In the EPS Attach/TAU response message, the network indicates back to the UE whether CSFB (including SMS) is supported, “SMS-only”, “CSFB Not Preferred”, or none of these features are supported. “CSFB Not Preferred” is an indication to allow data centric devices to continue reside in EPS and to allow CSFB (including SMS) features to be used. On the other hand, a voice centric device receiving “CSFB Not Preferred” or “SMS-only” will assume CSFB is not supported in this network and will try to reselect to other networks (i.e. 2G or 3G) to obtain voice services. In 1xRTT CSFB features, the UE is aware that the network supports 1xCSFB by examining the system information broadcast information over E-UTRAN access and performs the 1xCS registration to the 1xRTT MSC via the CDMA2000 signaling tunnel between the UE (via EPS) and 1xCS IWS. This 1xCS registration request and response is transparent to the EPS.

After the UE has successfully registered itself to the CS domain (and has received positive response from MME that CSFB is possible in GERAN/UTRAN case), it can then request the MME to perform CSFB procedures whenever it wants to use CS domain services (e.g. originating a voice call or answer to a terminating voice call). Besides voice call, USSD, MO-LR, MT-LR, NI-LR, and call-independent Supplementary Services procedures (e.g. activates CFB) can also trigger CSFB procedures. In the CS terminating scenario, an active UE has the ability to reject terminating call request while it still resides in EPS. This is particularly useful when the end-user is watching a streaming video under EPS and does not want to answer a call from an unknown number to avoid any streaming disruption in the streaming video due to unwanted CSFB procedures.

For the GSM-UMTS CSFB feature, EPS can perform the CSFB procedure with PS handover procedure, RRC connection release with redirection information, or cell change order with NACC (for GERAN only). This is based on network configuration and deployment option. For 1xRTT CSFB feature, CSFB can be done with RRC connection release with redirection information or 1xSRVCC based signaling (known as enhanced 1xCSFB). 1xRTT CSFB UE may also have dual-Rx/dual-Tx or Dual-Rx/Single-Tx capability. Dual-Rx/dual-Tx 1xRTT CSFB UE can simultaneously transmit and receive on both EPS and 1x at the same time. This allows the UE to obtain 1x voice service from 1xRTT system while maintaining the data stream over EPS at the same time. This is also based on network configuration and deployment option, and UE capability. Dual-Rx/Single-Tx 1xRTT CSFB UE allows simplification in EPS network deployment because there is no coordination is required between the E UTRAN and 1xRTT network (i.e. S102 is not required).

After the UE is redirected to GERAN/UTRAN/1xRTT access via one of the above procedures, the existing CS setup procedure is taken over for the remaining of the call.

In Rel-9, IDLE mode camping mechanism is enhanced in the EPS and GPRS to allow the network to influence the UE’s RAT camping policy so that a CSFB UE will select GERAN/UTRAN access when it is in IDLE condition. The intention is to minimize the occurrence of CSFB procedure from EPS to allow the UE to invoke the CS domain services directly from GERAN/UTRAN as much as possible. On the other hand, this requires additional intelligence in the cell reselection policy in the GERAN/UTRAN access in order to move the UE in active state to EPS to enjoy the fast PS access when appropriate. There are also optimization enhancements to Rel-9 for speeding up the overall CSFB procedure.

As indicated earlier, SMS delivery via CS Domain is also defined as part of the CSFB feature. UE can utilize this feature after it has successfully attached itself to the CS domain. It should be noted that EPS has the option to support only the SMS feature and not the CSFB feature which redirect the UE to another RAT. For GERAN/UTRAN CSFB, MME can indicate this condition by having an SMS-only indicator to the UE during their combined EPS/IMSI Attach/TAU procedure. For 1xRTT CSFB, this indication is not specified, as the 1xCS registration procedure is transparent to the EPS. UE receiving the “SMS-only” indicator will not invoke the CSFB request and should not expect any CS paging coming from EPS.

When interworking with a 3GPP MSC, SMS is delivered via the SGs interface. For MO-SMS, UE first establishes a NAS tunnel to transfer the SMS PDU to MME. MME then transfer these SMS PDU over to MSC via the SGs. MT-SMS works the same way by having the MME establish a NAS tunnel to UE over E-UTRAN access.

When interworking with 1xMSC, the UE establishes a CDMA2000 tunnel with the 1xCS IWS via EPS and SMS is delivered via that tunnel. EPS is transparent to this process.

3GPP also defines the CSFB UE in voice-centric and data-centric mode of operation in TS 23.221. Voicecentric CSFB UE will always attempt to find a RAT where voice services can be supported. In the example of UE receiving an SMS-only or “CSFB Not Preferred” indication from the network during combined EPS/IMSI attach procedure, the voice-centric UE will autonomously switch to UTRAN/GERAN access if coverage is available so voice service is possible to this user. With a data-centric mode of operation, the CSFB UE will not switch to UTRAN/GERAN given the same scenario with the SMS-only indication from the network and will forgo the voice services or CS domain services altogether. This is because the data-centric mode UE wants the best possible PS access and voice is not the determining factor to move away from EPS.

Article from "4G Broadband Evolution: 3GPP Release 10 and beyond"

UE Positioning In LTE

UE positioning is an access network function (e.g. GERAN, UTRAN, E-UTRAN). An access network may support one or more UE positioning methods, which may be same or different from another access network. In E-UTRAN the following UE positioning methods are supported:

•  Cell ID positioning method
•  Enhanced Cell ID based positioning method
•  OTDOA positioning method
•  Network assisted GNSS (A-GNSS) positioning methods

Determining the position of a UE involves two main steps:

1. Radio signal measurements
2. Position estimate computation and optional velocity computation based on the measurements

The signal measurements may be made by the UE or the E-UTRAN. Both TDD and FDD radio interface will be supported in E-UTRAN. The basic signals measured for terrestrial position methods are typically the E-UTRA radio transmissions. Also other transmissions such as general radio navigation signals including those from Global Navigation Satellites Systems can also be measured. The position estimate computation may be made in the UE or in the E-SMLC. In UE-assisted positioning the UE perform the downlink radio measurements and the E-SMLC estimates the UE position while in UE-based positioning the UE performs both the downlink radio measurements and also the position estimation. The UE may require some assistance from the network in the form of assistance data in order to perform the downlink measurements and these are provided by the network either autonomously or upon UE requesting it.

The E-UTRAN positioning capabilities are intended to be forward compatible to other access types and other position methods, in an effort to reduce the amount of additional positioning support needed in the future.

CELL ID METHOD

This is the simplest of all positioning methods but the UE position is very coarse in that only the serving cell where the UE is located is provided. As E-UTRAN and MME are involved in the mobility management (e.g. tracking area update or paging) of UEs the serving base station and serving cell of the UE is always known especially when there is signaling between the E-SMLC and the UE to query the UE position.

ENHANCED CELL ID‐BASED METHOD

In this method the position obtained by the Cell ID method is enhanced through means of use of other UE or E-UTRAN measurements to estimate the UE position with better accuracy than the Cell ID method. The measurements used may be radio resource measurements or other measurements. The E-SMLC does not configure these measurements in the UE/E-UTRAN but only queries the UE/E-UTRAN for these measurements and obtains them if available in the UE/E-UTRAN.

NETWORK ASSISTED GNSS METHODS

In network assisted GNSS methods the network provides various assistance data to the UE that are equipped with radio receivers capable of receiving GNSS signals. The UEs use the assistance data provided by the network to help perform measurements. Examples of GNSS include: GPS, Modernized GPS, Galileo, GLONASS, Space Based Augmentation Systems (SBAS) and Quasi Zenith Satellite System (QZSS). Different GNSS can be used separately or in combination to determine the position of a UE. 

OTDOA METHOD

The OTDOA method is a downlink terrestrial positioning method. In this method the UE performs measurements of downlink signals of neighbor E-UTRAN cells. This is a good backup method for positioning the UE when satellite signals are not strong enough (e.g. indoors or bad atmospheric conditions etc). The UE receives the downlink radio transmission of four or more neighbor cells, aided by downlink reference signal transmissions from those cells and measures the time difference of arrival of the radio frames of the measured neighbor cells relative to the serving cell. These UE measurements are then used either by the UE or by the E-SMLC to estimate the UE position using a trilateration technique.

The E-UTRAN may combine two or more of the supported UE positioning methods and perform a hybrid positioning estimation to achieve a better positioning accuracy.

The UE positioning protocol is an end-to-end protocol with terminations in the UE and the E-SMLC(Enhanced Serving Mobile Location Center). This protocol is called the LTE Positioning Protocol (LPP). This is a transaction-oriented protocol with exchange of LPP messages between UE and E-SMLC where one or more messages realize each transaction. A transaction results in one activity or operation such as assistance data transfer, UE positioning capability transfer or position measurement/estimate exchange. There is a second UE positioning protocol, LPPa, with terminations in the E-UTRAN and E-SMLC that allows the exchange of information and measurements, which are useful for some specific positioning methods. Currently, the LPPa is used for the delivery of timing information that is resident only to the E-UTRAN and/or is semidynamically changing, which is required for the OTDOA positioning method. Apart from this the LPPa also supports the exchange of E-UTRAN assisted measurements that are used for the Enhanced Cell ID positioning method.

What is Evolved Packet Core ( EPC )

Evolved Packet Core (EPC) is the IP-based core network defined by 3GPP in Rel-8 for use by LTE and other access technologies. The goal of EPC is to provide simplified all-IP core network architecture to efficiently give access to various services such as the ones provided in IMS.

EPC consists essentially of a Mobility Management Entity (MME), a Serving Gateway (S-GW) that interfaces with the E-UTRAN and a PDN Gateway (P-GW) that interfaces to external packet data networks. EPC for LTE networks were announced by numerous vendors beginning in February 2009, allowing operators to modernize their core data networks to support a wide variety of access types using a common core network.

EPC solutions typically include backhaul, network management solutions, video solutions that monetize LTE investment and a complete portfolio of professional services.

4G Mobile Broadband Evolution: 3GPP Release-10 and Beyond

View more documents from Zahid Ghadialy.

LTE – the Future of IMS

View more presentations from RADVISION Ltd..

LTE - Long Term Evolution - Presentation

View more presentations from Arief Gunawan.

LTE Femtocell Roadmap- From Concept to Reality

View more presentations from Continuous Computing.

3GPP LTE-MAC

View more presentations from praveenkmr78.

RAT/Frequency Selection Priority Index - RFSP Index

Radio resource management functions are concerned with the allocation and maintenance of radio communication paths, and are performed by the radio access network. The RRM strategy in E-UTRAN may be based on user specific information.

To support radio resource management in E-UTRAN the MME provides the parameter 'Index to RAT/Frequency Selection Priority' (RFSP Index) to an eNodeB across S1. The RFSP Index is mapped by the eNodeB to locally defined configuration in order to apply specific RRM strategies. The RFSP Index is UE specific and applies to all the Radio Bearers.

Examples of how this parameter may be used by the E-UTRAN:
- to derive UE specific cell reselection priorities to control idle mode camping.
- to decide on redirecting active mode UEs to different frequency layers or RATs.
The MME receives the subscribed RFSP Index from the HSS (e.g., during the Attach procedure). For non-roaming subscribers the MME chooses the RFSP Index in use according to one of the following procedures, depending on operator's configuration:
- the RFSP Index in use is identical to the subscribed RFSP Index, or
- the MME chooses the RFSP Index in use based on the subscribed RFSP Index, the locally configured operator's policies and the UE related context information available at the MME, including UE's usage setting and voice domain preference for E-UTRAN, if received during Attach and Tracking Area Update procedures.

One example of how the MME can use the "UE voice capabilities and settings" is to select an RFSP value that enforces idle mode camping on 2G/3G for a UE acting in a "Voice centric" way and provisioned with "CS Voice preferred, IMS Voice as secondary", in order to minimize the occurrancy of RAT changes. Another example is the selection of an RFSP value that prevents idle mode camping on 2G for a UE provisioned with "IMS PS voice preferred, CS Voice as secondary" if other RATs supporting IMS Voice are available, as the UE would in such case always select the CS domain for its voice calls.

For roaming subscribers the MME may alternatively choose the RFSP Index in use based on the visited network policy, but can take input from the HPLMN into account (e.g., an RFSP Index value pre-configured per HPLMN, or a single RFSP Index value to be used for all roamers independent of the HPLMN).

The MME forwards the RFSP Index in use to the eNodeB across S1. The RFSP Index in use is also forwarded from source eNodeB to target eNodeB when X2 is used for intra-E UTRAN handover.

The MME stores the subscribed RFSP Index value received from the HSS and the RFSP Index value in use. During the Tracking Area Update procedure, the MME may update the RFSP Index value in use (e.g. the MME may need to update the RFSP Index value in use if the UE related context information in the MME has changed). When the RFSP Index value in use is changed, the MME immediately provides the updated RFSP Index value in use to eNodeB by modifying an existing UE context or by establishing an new UE context in the eNodeB. During inter-MME mobility procedures, the source MME forwards both RFSP Index values to the target MME. The target MME may replace the received RFSP Index value in use with a new RFSP Index value in use that is based on the operator's policies and the UE related context information available at the target MME.

The S1 messages that transfer the RFSP Index to the eNodeB are specified in TS 36.413 [36].

NAS Service request procedure

This procedure is one of the EMM connection management procedures. The purpose of the service request procedure is to transfer the EMM mode from EMM-IDLE to EMM-CONNECTED mode and establish the radio and S1 bearers when uplink user data or signalling is to be sent. Another purpose of this procedure is to invoke MO(mobile Originated/MT(Mobile Terminated) CS fallback procedures.

This procedure is used when:

- the network has downlink signalling pending;

- the UE has uplink signalling pending;

- the UE or the network has user data pending and the UE is in EMM-IDLE mode;

- the UE in EMM-IDLE or EMM-CONNECTED mode has requested to perform mobile originating/terminating CS fallback;

- the network has downlink cdma2000® signalling pending; or

- the UE has uplink cdma2000® signalling pending.

The service request procedure is initiated by the UE, however, for the downlink transfer of signalling, cdma2000® signalling or user data in EMM-IDLE mode, the trigger is given by the network by means of the paging procedure.

The UE invokes the service request procedure when:

a) the UE in EMM-IDLE mode receives a paging request with CN domain indicator set to "PS" from the network;

b) the UE, in EMM-IDLE mode, has pending user data to be sent;

c) the UE, in EMM-IDLE mode, has uplink signalling pending;

d) the UE in EMM-IDLE or EMM-CONNECTED mode is configured to use CS fallback and has a mobile originating CS fallback request from the upper layer;

e) the UE in EMM-IDLE mode is configured to use CS fallback and receives a paging request with CN domain indicator set to "CS", or the UE in EMM-CONNECTED mode is configured to use CS fallback and receives a CS SERVICE NOTIFICATION message;

f) the UE in EMM-IDLE or EMM-CONNECTED mode is configured to use 1xCS fallback and has a mobile originating 1xCS fallback request from the upper layer;

g) the UE in EMM-CONNECTED mode is configured to use 1xCS fallback and accepts cdma2000® signalling messages containing a 1xCS paging request; or

h) the UE, in EMM-IDLE mode, has uplink cdma2000® signalling pending.

If one of the above criteria to invoke the service request procedure is fulfilled, then the service request procedure may only be initiated by the UE when the following conditions are fulfilled:

- its EPS update status is EU1 UPDATED, and the TAI of the current serving cell is included in the TAI list; and

- no EMM specific procedure is ongoing.

If the UE has pending uplink data or uplink signalling in EMM-IDLE mode to be transmitted or it responds to paging with CN domain indicator set to "PS", the UE initiates the service request procedure by sending a SERVICE REQUEST message to the MME, and enters the state EMM-SERVICE-REQUEST-INITIATED.

For case d, the UE shall send an EXTENDED SERVICE REQUEST message, start T3417ext and enter the state EMM-SERVICE-REQUEST-INITIATED.

For case e:

- if the UE is in EMM-IDLE mode, the UE shall send an EXTENDED SERVICE REQUEST message, and enter the state EMM-SERVICE-REQUEST-INITIATED;

- if the UE is in EMM-CONNECTED mode and if the UE accepts the paging, the UE shall send an EXTENDED SERVICE REQUEST message with the CSFB response IE indicating "CS fallback accepted by the UE", and enter the state EMM-SERVICE-REQUEST-INITIATED;

- if the UE is in EMM-CONNECTED mode and if the UE rejects the paging, the UE shall send an EXTENDED SERVICE REQUEST message with the CSFB response IE indicating "CS fallback rejected by the UE" and enter the state EMM-REGISTERED.NORMAL-SERVICE. The network should not initiate CS fallback procedures.

For cases f and g, the UE shall send an EXTENDED SERVICE REQUEST message, and enter the state EMM-SERVICE-REQUEST-INITIATED.

LTE Layer 1 Services

Multiple Access

The multiple access scheme for the LTE physical layer is based on Orthogonal Frequency Division Multiplexing (OFDM) with a cyclic prefix (CP) in the downlink, and on Single-Carrier Frequency Division Multiple Access (SC-FDMA) with a cyclic prefix in the uplink. To support transmission in paired and unpaired spectrum, two duplex modes are supported: Frequency Division Duplex (FDD), supporting full duplex and half duplex operation, and Time Division Duplex (TDD).

The Layer 1 is defined in a bandwidth agnostic way based on resource blocks, allowing the LTE Layer 1 to adapt to various spectrum allocations. A resource block spans either 12 sub-carriers with a sub-carrier bandwidth of 15kHz or 24 sub-carriers with a sub-carrier bandwidth of 7.5kHz each over a slot duration of 0.5ms.

The radio frame structure type 1 is used for FDD (for both full duplex and half duplex operation) and has a duration of 10ms and consists of 20 slots with a slot duration of 0.5ms. Two adjacent slots form one sub-frame of length 1ms. The radio frame structure type 2 is used for TDD and consists of two half-frames with a duration of 5ms each and containing each 8 slots of length 0.5ms and three special fields (DwPTS, GP and UpPTS) which have configurable individual lengths and a total length of 1ms.

A sub-frame consists of two adjacent slots, except for sub-frames 1 and 6, which consist of DwPTS, GP and UpPTS. Both 5ms and 10ms switch-point periodicity are supported.

To support a Multimedia Broadcast and Multicast Service (MBMS), LTE offers the possibility to transmit Multicast/Broadcast over a Single Frequency Network (MBSFN), where a time-synchronized common waveform is transmitted from multiple cells for a given duration. MBSFN transmission enables highly efficient MBMS, allowing for over-the-air combining of multi-cell transmissions in the UE, where the cyclic prefix is utilized to cover the difference in the propagation delays, which makes the MBSFN transmission appear to the UE as a transmission from a single large cell. Transmission on a dedicated carrier for MBSFN with the possibility to use a longer CP with a sub-carrier bandwidth of 7.5kHz is supported as well as transmission of MBSFN on a carrier with both MBMS transmissions and point-to-point transmissions using time division multiplexing.

Transmission with multiple input and multiple output antennas (MIMO) are supported with configurations in the downlink with two or four transmit antennas and two or four receive antennas, which allow for multi-layer transmissions with up to four streams. Multi-user MIMO i.e. allocation of different streams to different users is supported in both UL and DL.

Physical channels and modulation

The physical channels defined in the downlink are:
• the Physical Downlink Shared Channel (PDSCH),
• the Physical Multicast Channel (PMCH),
• the Physical Downlink Control Channel (PDCCH),
• the Physical Broadcast Channel (PBCH),
• the Physical Control Format Indicator Channel (PCFICH)
• and the Physical Hybrid ARQ Indicator Channel (PHICH).

The physical channels defined in the uplink are:
• the Physical Random Access Channel (PRACH),
• the Physical Uplink Shared Channel (PUSCH),
• and the Physical Uplink Control Channel (PUCCH).

In addition, signals are defined as reference signals, primary and secondary synchronization signals. The modulation schemes supported in the downlink and uplink are QPSK, 16QAM and 64QAM.

Channel coding and interleaving

The channel coding scheme for transport blocks in LTE is Turbo Coding with a coding rate of R=1/3, two 8-state constituent encoders and a contention-free quadratic permutation polynomial (QPP) turbo code internal interleaver. Trellis termination is used for the turbo coding. Before the turbo coding, transport blocks are segmented into byte aligned segments with a maximum information block size of 6144 bits. Error detection is supported by the use of 24 bit CRC. 

Physical layer procedures

There are several Physical layer procedures involved with LTE operation. Such procedures covered by the physical layer are;

- Cell search
- Power control
- Uplink synchronisation and Uplink timing control
- Random access related procedures
- HARQ related procedures

Through the control of physical layer resources in the frequency domain as well as in the time and power domain, implicit support of interference coordination is provided in LTE.

Physical layer measurements
Radio characteristics are measured by the UE and the eNode-B and reported to higher layers in the network. These include, e.g. measurements for intra- and inter-frequency handover, inter RAT handover, timing measurements and measurements for RRM and in support for positioning. Measurements for inter-RAT handover are defined in support of handover to GSM, UTRA FDD, UTRA TDD, CDMA2000 1x RTT and CDMA2000 HRPD.

LTE Layer 1

The radio interface is composed of the Layer 1, 2 and 3. Below figure shows the E-UTRA radio interface protocol architecture around the physical layer (Layer 1). The physical layer interfaces the Medium Access Control (MAC) sub-layer of Layer 2 and the Radio Resource Control (RRC) Layer of Layer 3. The circles between different layer/sub-layers indicate Service Access Points (SAPs). The physical layer offers a transport channel to MAC. The transport channel is characterized by how the information is transferred over the radio interface. MAC offers different logical channels to the Radio Link Control (RLC) sub-layer of Layer 2. A logical channel is characterized by the type of information transferred.

Service provided to higher layers

The physical layer offers data transport services to higher layers. The access to these services is through the use of a transport channel via the MAC sub-layer. The physical layer is expected to perform the following functions in order to provide the data transport service:

- Error detection on the transport channel and indication to higher layers
- FEC encoding/decoding of the transport channel
- Hybrid ARQ soft-combining
- Rate matching of the coded transport channel to physical channels
- Mapping of the coded transport channel onto physical channels
- Power weighting of physical channels
- Modulation and demodulation of physical channels
- Frequency and time synchronisation
- Radio characteristics measurements and indication to higher layers
- Multiple Input Multiple Output (MIMO) antenna processing
- Transmit Diversity (TX diversity)
- Beamforming
- RF processing.

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

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.

Voice over LTE to have 3G support and emergency calls

Updated specifications of VoLGA Forum for its standard for Voice Over LTE have been released. The new specifications include mobile voice as well as SMS services over 4G and is different from the current standard which supports only data. The changes in the standard will bring VoLGA (Voice over LTE via Generic Access) which uses 3G, HSPA-based networks. Users also get an option for emergency calls even in the absence of a SIM card.

The just released standard will optimize voice-bearer routing. The forum has also issued host APIs for LTE devices.

Nineteen companies are members of the VoLGA Forum. Among them, LG, Motorola, Samsung, Cisco and HTC are the most important.

Many efforts are being made in order to standardize both calls and SMS on the LTE data network. They include the One Voice initiative of Verizon, AT&T, Alcatel-Lucent, Ericsson, Nokia, Siemens and Samsung.

NAS Elementary procedures for EPS Mobility Management

The main function of the mobility management sublayer is to support the mobility of a user equipment, such as informing the network of its present location and providing user identity confidentiality

A further function of the mobility management sublayer is to provide connection management services to the session management (SM) sublayer and the short message services (SMS) entity of the connection management (CM) sublayer.

All the EMM procedures can only be performed if a NAS signalling connection has been established between the UE and the network. Else, the EMM sublayer has to initiate the establishment of a NAS signalling connection.

Types of EMM procedures

• EMM common procedures
  
• GUTI reallocation
• Authentication
• Security mode control
• Identification
• EMM information
  
  
• EMM specific procedures
  
• Attach and combined attach.
• Attach.
• Detach and combined detach.
• Normal tracking area updating and combined tracking area updating (S1 mode only).
• Periodic tracking area updating (S1 mode only).
  
  
• EMM connection management procedures (S1 mode only)
  
• Service request.
• Paging procedure.
• Transport of NAS messages;
• Generic transport of NAS messages.

About NAS (Non-Access Stratum)

The non-access stratum (NAS)forms the highest stratum of the control plane between UE and MME at the radio interface ("LTE-Uu interface")

Main functions of the protocols that are part of the NAS are:

• the support of mobility of the user equipment (UE).
• the support of session management procedures to establish and maintain IP connectivity between the UE and a packet data network gateway (PDN GW).

NAS security is an additional function of the NAS providing services to the NAS protocols, e.g. integrity protection and ciphering of NAS signalling messages.

For the support of the above functions, the following procedures are supplied within 3GPP 24301 specification:

• elementary procedures for EPS mobility management
• elementary procedures for EPS session management.

Authentication procedure

The purpose of the EPS authentication and key agreement (AKA) procedure is to provide mutual authentication between the user and the network and to agree on a key KASME. The EPS AKA procedure is always initiated and controlled by the network. However, the UE can reject the EPS authentication challenge sent by the network.

A partial native EPS security context is established in the UE and the network when an EPS authentication is successfully performed. During a successful EPS authentication procedure, the CK and IK are computed by the USIM. CK and IK are then used by the ME as key material to compute a new key, KASME. KASME is stored in the EPS security contexts of both the network and in the volatile memory of the ME while attached to the nework, and is the root for the EPS integrity protection and ciphering key hierarchy.

• Authentication initiation by the network

When a NAS signalling connection exists, the network can initiate an authentication procedure at any time. The network initiates the authentication procedure by sending an AUTHENTICATION REQUEST message to the UE.

The AUTHENTICATION REQUEST message contains the parameters necessary to calculate the authentication response.

• Authentication response by the UE

The UE responds to an AUTHENTICATION REQUEST message. The UE processes the authentication challenge data and respond with an AUTHENTICATION RESPONSE message to the network. Upon a successful EPS authentication challenge, the UE determines the PLMN identity to be used for the calculation of the new KASME from the authentication challenge data.

Upon a successful EPS authentication challenge, the new KASME calculated from the authentication challenge data is stored in a new EPS security context in the volatile memory of the ME.

The USIM computes the authentication response (RES) using the authentication challenge data received from the ME, and pass RES to the ME.

• Authentication completion by the network

Upon receipt of an AUTHENTICATION RESPONSE message, the network checks the correctness of RES. If the authentication procedure has been completed successfully and the related eKSI is stored in the EPS security context of the network.

When the network initiates a new authentication procedure, it includes a different eKSI value in the AUTHENTICATION REQUEST message.