What is LTE?

LTEi (Long Term Evolution) is initiated by 3GPPi to improve the mobile

phone standard to cope
with future technology evolutions and needs.

What is goal of LTE?

The goals for LTE include improving spectral efficiency, lowering
costs, improving services,
making use of new spectrum and reformed spectrum opportunities, and
better integration with
other open standards.

What speed LTE offers?

LTE provides downlink peak rates of at least 100Mbit/s, 50 Mbit/s in
the uplink and RAN (Radio
Access Network) round-trip times of less than 10 ms.

What is LTE Advanced?

LTE standards are in matured state now with release 8 frozen. While
LTE Advanced is still under
works. Often the LTE standard is seen as 4G standard which is not
true. 3.9G is more
acceptable for LTE. So why it is not 4G? Answer is quite simple - LTE
does not fulfill all
requirements of ITU 4G definition.
Brief History of LTE Advanced: The ITU has introduced the term IMT
Advanced to identify mobile
systems whose capabilities go beyond those of IMT 2000. The IMT
Advanced systems shall
provide best-in-class performance attributes such as peak and
sustained data rates and
corresponding spectral efficiencies, capacity, latency, overall
network complexity and qualityof-service management. The new capabilities of these IMT-Advanced
systems are envisaged to
handle a wide range of supported data rates with target peak data
rates of up to approximately
100 Mbit/s for high mobility and up to approximately 1 Gbit/s for low
mobility.
See LTE Advanced: Evolution of LTE for more details.

What is LTE architecture?

The evolved architecture comprises E-UTRAN (Evolved UTRAN) on the
access side and EPC
(Evolved Packet Core) on the core side.
The figure below shows the evolved system architecture

What is EUTRAN?
The E-UTRAN (Evolved UTRAN) consists of eNBs, providing the E-UTRA
user plane
(PDCP/RLC/MAC/PHY) and control plane (RRC) protocol terminations
towards the UE. The eNBs
are interconnected with each other by means of the X2 interface. The
eNBs are also connected
by means of the S1 interface to the EPC (Evolved Packet Core), more
specifically to the MME
(Mobility Management Entity) by means of the S1-MME and to the Serving
Gateway (S-GW) by
means of the S1-U.

What are LTE Interfaces?

The following are LTE Interfaces : (Ref: TS 23.401 v 841)
S1-MME :- Reference point for the control plane protocol between EUTRAN and MME.
S1-U:- Reference point between E-UTRAN and Serving GW for the per
bearer user plane tunnelling and
inter eNodeB path switching during handover.
S3:- It enables user and bearer information exchange for inter 3GPP
access network mobility in idle
and/or active state.
S4:- It provides related control and mobility support between GPRS
Core and the 3GPP Anchor function of
Serving GW. In addition, if Direct Tunnel is not established, it
provides the user plane tunnelling.
S5:- It provides user plane tunnelling and tunnel management between
Serving GW and PDN GW. It is used
for Serving GW relocation due to UE mobility and if the Serving GW
needs to connect to a non-collocated
PDN GW for the required PDN connectivity.
S6a:- It enables transfer of subscription and authentication data
for authenticating/authorizing user
access to the evolved system (AAA interface) between MME and HSS.
Gx:- It provides transfer of (QoS) policy and charging rules from
PCRF to Policy and Charging Enforcement
Function (PCEF) in the PDN GW.
S8:- Inter-PLMN reference point providing user and control plane
between the Serving GW in the VPLMN
and the PDN GW in the HPLMN. S8 is the inter PLMN variant of S5.
S9:- It provides transfer of (QoS) policy and charging control
information between the Home PCRF and the
Visited PCRF in order to support local breakout function.
S10:- Reference point between MMEs for MME relocation and MME to MME
information transfer.
S11:- Reference point between MME and Serving GW.

 S12:- Reference point between UTRAN and Serving GW for user plane
tunnelling when Direct Tunnel is
established. It is based on the Iu-u/Gn-u reference point using the
GTP-U protocol as defined between
SGSN and UTRAN or respectively between SGSN and GGSN. Usage of S12 is
an operator configuration
option.
S13:- It enables UE identity check procedure between MME and EIR.
SGi:- It is the reference point between the PDN GW and the packet
data network. Packet data network may
be an operator external public or private packet data network or an
intra operator packet data network,
e.g. for provision of IMS services. This reference point corresponds
to Gi for 3GPP accesses.
Rx:- The Rx reference point resides between the AF and the PCRF in
the TS 23.203.
SBc:- Reference point between CBC and MME for warning message
delivery and control functions.

What are LTE Network elements?

eNB
eNB interfaces with the UE and hosts the PHYsical (PHY), Medium Access
Control (MAC), Radio Link Control (RLC), and Packet Data Control
Protocol (PDCP) layers. It also hosts Radio Resource Control (RRC)
functionality corresponding to the control plane. It performs many
functions including radio resource management, admission control,
scheduling, enforcement of negotiated UL QoS, cell information
broadcast, ciphering/deciphering of user and control plane data, and
compression/decompression of DL/UL user plane packet headers.
Mobility Management Entity
manages and stores UE context (for idle state: UE/user identities, UE
mobility state, user
security parameters). It generates temporary identities and allocates
them to UEs. It checks the
authorization whether the UE may camp on the TA or on the PLMN. It
also authenticates the
user.
Serving Gateway
The SGW routes and forwards user data packets, while also acting as
the mobility anchor for the
user plane during inter-eNB handovers and as the anchor for mobility
between LTE and other
3GPP technologies (terminating S4 interface and relaying the traffic
between 2G/3G systems
and PDN GW).
Packet Data Network Gateway
The PDN GW provides connectivity to the UE to external packet data
networks by being the
point of exit and entry of traffic for the UE. A UE may have

simultaneous connectivity with more

than one PDN GW for accessing multiple PDNs. The PDN GW performs
policy enforcement,
packet filtering for each user, charging support, lawful Interception
and packet screening.

What are LTE protocols & specifications?

In LTE architecture, core network includes Mobility Management Entity
(MME), Serving Gateway
(SGW), Packet Data Network Gateway (PDN GW) where as E-UTRAN has EUTRAN NodeB (eNB).
See LTE protocols & specifications for specification mappings.
Protocol links are as below
Air Interface Physical Layer
GPRS Tunnelling Protocol User Plane (GTP-U)
GTP-U Transport
Medium Access Control (MAC)
Non-Access-Stratum (NAS) Protocol
Packet Data Convergence Protocol (PDCP)
Radio Link Control (RLC)
Radio Resource Control (RRC)
S1 Application Protocol (S1AP)
S1 layer 1
S1 Signalling Transport
X2 Application Protocol (X2AP)
X2 layer 1
X2 Signalling Transport

What is VoLGA?
VoLGA stands for "Voice over LTE via Generic Access". The VoLGA
service resembles the 3GPP
Generic Access Network (GAN). GAN provides a controller node - the GAN
controller (GANC) inserted between the IP access network (i.e., the EPS) and the 3GPP
core network.
The GAN provides an overlay access between the terminal and the CS
core without requiring
specific enhancements or support in the network it traverses. This
provides a terminal with a
'virtual' connection to the core network already deployed by an
operator. The terminal and
network thus reuse most of the existing mechanisms, deployment and
operational aspects.
see VoLGA - Voice over LTE via Generic Access for more details.

What is CS Fallback in LTE?

LTE technology supports packet based services only, however 3GPP does
specifies fallback for
circuit switched services as well. To achieve this LTE architecture
and network nodes require
additional functionality, this blog is an attempt to provide overview
for same.
In LTE architecture, the circuit switched (CS) fallback in EPS enables
the provisioning of voice
and traditional CS-domain services (e.g. CS UDI video/ SMS/ LCS/
USSD). To provide these
services LTE reuses CS infrastructure when the UE is served by E
UTRAN.
See Understanding CS Fallback in LTE for more details.

How does LTE Security works?

The following are some of the principles of 3GPP E-UTRAN security
based on 3GPP Release 8
specifications:
The keys used for NAS and AS protection shall be dependent on the
algorithm with which they are used.
The eNB keys are cryptographically separated from the EPC keys used
for NAS protection (making it
impossible to use the eNB key to figure out an EPC key).
The AS (RRC and UP) and NAS keys are derived in the EPC/UE from key
material that was generated by a
NAS (EPC/UE) level AKA procedure (KASME) and identified with a key
identifier (KSIASME).
The eNB key (KeNB) is sent from the EPC to the eNB when the UE is
entering ECM-CONNECTED state (i.e.
during RRC connection or S1 context setup).
See LTE Security Principles for more details.

How does measurements work in LTE?

In LTE E-UTRAN measurements to be performed by a UE for mobility are
classified as below
Intra-frequency E-UTRAN measurements
Inter-frequency E-UTRAN measurements
Inter-RAT measurements for UTRAN and GERAN
Inter-RAT measurements of CDMA2000 HRPD or 1xRTT frequencies
See Measurements in LTE E-UTRAN for details.

What is Automatic Neighbour Relation?

According to 3GPP specifications, the purpose of the Automatic
Neighbour Relation (ANR)
functionality is to relieve the operator from the burden of manually
managing Neighbor

Relations (NRs). This feature would operators effort to provision.

Read Automatic Neighbour Relation in LTE for more details.

How does Intra E-UTRAN Handover is performed?

Intra E-UTRAN Handover is used to hand over a UE from a source eNodeB
to a target eNodeB
using X2 when the MME is unchanged. In the scenario described here
Serving GW is also
unchanged. The presence of IP connectivity between the Serving GW and
the source eNodeB, as
well as between the Serving GW and the target eNodeB is assumed.
The intra E-UTRAN HO in RRC_CONNECTED state is UE assisted NW
controlled HO, with HO
preparation signalling in E-UTRAN.
Read LTE Handovers - Intra E-UTRAN Handover for more details.

What is SON & how does it work in LTE?

Self-configuring, self-optimizing wireless networks is not a new
concept but as the mobile
networks are evolving towards 4G LTE networks, introduction of self
configuring and self
optimizing mechanisms is needed to minimize operational efforts. A
self optimizing function
would increase network performance and quality reacting to dynamic
processes in the network.
This would minimize the life cycle cost of running a network by
eliminating manual
configuration of equipment at the time of deployment, right through to
dynamically optimizing
radio network performance during operation. Ultimately it will reduce
the unit cost and retail
price of wireless data services.
See Self-configuring and self-optimizing Networks in LTE for details.

How does Timing Advance (TA) works in LTE?

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.
See Timing Advance (TA) in LTE for further details.


How does LTE UE positioning works in E-UTRAN?
UE Positioning function is required to provide the mechanisms to
support or assist the
calculation of the geographical position of a UE. UE position
knowledge can be used, for
example, in support of Radio Resource Management functions, as well as
location-based
services for operators, subscribers, and third-party service
providers.
See LTE UE positioning in E-UTRAN for more details.

How many operators have committed for LTE?

List of operators committed for LTE has been compiled by 3GAmericas
from Informa Telecoms
& Media and public announcements. It includes a variety of commitment
levels including
intentions to trial, deploy, migrate, etc.
For latest info visit http://ltemaps.org/

How does Location Service (LCS) work in LTE network?

In the LCS architecture, an Evolved SMLC is directly attached to the
MME. The objectives of this
evolution is to support location of an IMS emergency call, avoid
impacts to a location session
due to an inter-eNodeB handover, make use of an Evolved and support
Mobile originated
location request (MO-LR) and mobile terminated location request MT-LR
services.
Release 9 LCS solution introduces new interfaces in the EPC:
SLg between the GMLC and the MME
SLs between the E-SMLC and the MME
Diameter-based SLh between the HSS and the HGMLC
For details read LCS Architecture for LTE EPS and LTE UE positioning
in E-UTRAN

How does Lawful Interception works in LTE Evolved Packet System?

3GPP Evolved Packet System (EPS) provides IP based services. Hence,
EPS is responsible only for
IP layer interception of Content of Communication (CC) data. In
addition to CC data, the Lawful
Interception (LI) solution for EPS offers generation of Intercept
Related Information (IRI) records
from respective control plane (signalling) messages as well.
See Lawful Interception Architecture for LTE Evolved Packet System for
more details.


What is carrier aggregation in LTE-Advanced?
To meet LTE-Advanced requirements, support of wider transmission
bandwidths is required
than the 20 MHz bandwidth specified in 3GPP Release 8/9. The preferred
solution to this is
carrier aggregation.
It is of the most distinct features of 4G LTE-Advanced. Carrier
aggregation allows expansion of
effective bandwidth delivered to a user terminal through concurrent
utilization of radio
resources across multiple carriers. Multiple component carriers are
aggregated to form a larger
overall transmission bandwidth.
LTE Handovers - Intra E-UTRAN Handover
By LteWorld - Posted on 10 April 2010
Intra E-UTRAN Handover is used to hand over a UE from a source eNodeB
to a target eNodeB
using X2 when the MME is unchanged. In the scenario described here
Serving GW is also
unchanged. The presence of IP connectivity between the Serving GW and
the source eNodeB, as
well as between the Serving GW and the target eNodeB is assumed.
The intra E-UTRAN HO in RRC_CONNECTED state is UE assisted NW
controlled HO, with HO
preparation signalling in E-UTRAN.
To prepare the HO, the source eNB passes all necessary information to
the target eNB (e.g. ERAB attributes and RRC context) and UE accesses the target cell via
RACH following a
contention-free procedure using a dedicated RACH preamble.
The HO procedure is performed without EPC involvement, i.e.
preparation messages are directly
exchanged between the eNBs. The figure below shows the basic handover
scenario where
neither MME nor Serving Gateway changes:
Detailed explanation of above scenario is below.
The source eNB configures the UE measurement procedures according to
the area
restriction information. UE sends MEASUREMENT REPORT by the rules set
by i.e. system
information, specification etc.
Source eNB makes decision based on MEASUREMENT REPORT and RRM
information to hand
off UE and issues a HANDOVER REQUEST message to the target eNB passing
necessary
information to prepare the HO at the target side.
Admission Control may be performed by the target eNB dependent on
the received E-RAB

QoS information to increase the likelihood of a successful HO. The

target eNB configures
the required resources according to the received E-RAB QoS
information.
Target eNB prepares HO with L1/L2 and sends the HANDOVER REQUEST
ACKNOWLEDGE to
the source eNB. The HANDOVER REQUEST ACKNOWLEDGE message includes a
transparent
container to be sent to the UE as an RRC message to perform the
handover.
The UE receives the RRCConnectionReconfiguration message with
necessary parameters (i.e.
new C-RNTI, target eNB security algorithm identifiers, and optionally
dedicated RACH
preamble, target eNB SIBs, etc.) and is commanded by the source eNB to
perform the HO.
The source eNB sends the SN STATUS TRANSFER message to the target
eNB to convey the
uplink PDCP SN receiver status and the downlink PDCP SN transmitter
status of E-RABs for
which PDCP status preservation applies (i.e. for RLC AM).
After receiving the RRCConnectionReconfiguration message including
the
mobilityControlInformation , UE performs synchronisation to target eNB
and accesses the
target cell via RACH.
The target eNB responds with UL allocation and timing advance.
UE sends the RRCConnectionReconfigurationComplete message (C-RNTI)
to confirm the
handover to the target eNB to indicate that the handover procedure is
completed for the UE.
The target eNB verifies the C-RNTI sent in the
RRCConnectionReconfigurationComplete
message. The target eNB can now begin sending data to the UE.
The target eNB sends a PATH SWITCH message to MME to inform that the
UE has changed
cell.
The MME sends an UPDATE USER PLANE REQUEST message to the Serving
Gateway.
The Serving Gateway switches the downlink data path to the target
side. The Serving
gateway sends one or more "end marker" packets on the old path to the
source eNB and
then can release any U-plane/TNL resources towards the source eNB.
Serving Gateway sends an UPDATE USER PLANE RESPONSE message to MME.
The MME confirms the PATH SWITCH message with the PATH SWITCH
ACKNOWLEDGE
message.
By sending UE CONTEXT RELEASE, the target eNB informs success of HO
to source eNB and
triggers the release of resources by the source eNB. The target eNB

sends this message

after the PATH SWITCH ACKNOWLEDGE message is received from the MME.
Upon reception of the UE CONTEXT RELEASE message, the source eNB can
release radio and
C-plane related resources associated to the UE context. Any ongoing
data forwarding may
continue.

Self-configuring and self-optimizing Networks in

LTE
By LteWorld - Posted on 11 October 2009
Self-configuring, self-optimizing wireless networks is not a new
concept but as the mobile
networks are evolving towards 4G LTE networks, introduction of self
configuring and self
optimizing mechanisms is needed to minimize operational efforts. A
self optimizing function
would increase network performance and quality reacting to dynamic
processes in the network.
This would minimize the life cycle cost of running a network by
eliminating manual
configuration of equipment at the time of deployment, right through to
dynamically optimizing
radio network performance during operation. Ultimately it will reduce
the unit cost and retail
price of wireless data services.
As per 3GPP standards, a typical operational objective is to optimize
the network according to
coverage and capacity.
Providing optimal coverage requires that in the area, where LTE system
is offered, users can
establish and maintain connections with acceptable or default service
quality, according to
operators requirements. Coverage and capacity are linked, a tradeoff between the two of
them may also be a subject of optimization.
To achieve these objectives, 3GPP suggests to implement following
functions
Detection of unintended holes in the coverage (planned by the
operator)
Perform coverage optimization, including DL/UL channel coverage a
Ability to balance the trade-off between coverage and capacity
Once solution is implemented, it would result in
Continuous, optimized and matched UL and DL coverage
Optimized DL and UL capacity of the system
Balanced tradeoff between coverage and capacity
Interference reduction
Controlled cell edge performance
Minimized human intervention in network management and optimization

tasks
Energy savings
More details about solution and use cases are available in 3GPP
technical report "Evolved
Universal Terrestrial Radio Access Network (E-UTRAN); Self-configuring
and self-optimizing
network (SON) use cases and solutions".
Implementing self configuration and self optimization under multi
vendor environment is
challenging task. For this purpose, It is of importance that
measurements and performance data
of different vendors follow same standard. Especially when the
interaction between self
configuring/optimizing networks and O&M has to be considered.
Timing Advance (TA) in LTE
By agaur - Posted on 01 September 2010
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 subframe 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.
Timing Advance Command MAC Control Element
The Timing Advance Command MAC control element is identified by MAC
PDU subheader with
LCID value = 11101 (Timing Advance Command) .
It has a fixed size and it consists of a single octet as show below.
Timing Advance Command MAC control element has following fields.
R: reserved bit, set to "0"
Timing Advance Command: This field indicates the index value TA (0,
1, 2 63) used to
control the amount of timing adjustment that UE has to. The length of
the field is 6 bits.
LTE UE positioning in E-UTRAN
By LteWorld - Posted on 03 January 2010
UE Positioning function is required to provide the mechanisms to
support or assist the
calculation of the geographical position of a UE. UE position
knowledge can be used, for
example, in support of Radio Resource Management functions, as well as
location-based
services for operators, subscribers, and third-party service
providers.
Positioning functionality provides a means to determine the geographic
position and/or velocity

of the UE based on measuring radio signals. The position information

may be requested by and
reported to a client (e.g., an application) associated with the UE, or
by a client within or
attached to the core network. The position information is reported in
standard formats, such as
those for cell-based or geographical co-ordinates, together with the
estimated errors
(uncertainty) of the position and velocity of the UE and, if
available, the positioning method (or
the list of the methods) used to obtain the position estimate.
Several design options of the LTE E-UTRAN system (e.g., size of cell,
adaptive antenna
technique, pathloss estimation, timing accuracy, eNode B surveys)
would allow the network
operator to choose a suitable and cost-effective UE positioning method
for their market.
Positioning the UE involves two main steps:
- signal measurements
- Position estimate and optional velocity computation based on the
measurements.
The signal measurements may be made by the UE or the eNode B.
The standard positioning methods supported for E-UTRAN access are:
- network-assisted GNSS (Global Navigation Satellites Systems)
methods
- downlink positioning
- enhanced cell ID method.
Hybrid positioning using multiple methods from the list of positioning
methods above is also
supported.
E-UTRAN UE Positioning Architecture
Above figure shows the architecture in EPS applicable to positioning
of a UE with E-UTRAN
access.
The MME receives a request for some location service associated with a
particular target UE
from another entity (e.g., GMLC, eNB, or UE) or the MME itself decides
to initiate some location
service on behalf of a particular target UE (e.g., for an IMS
emergency call from the UE). The
MME then sends a location services request to an E-SMLC. The E-SMLC
processes the location
services request which may include transferring assistance data to the
target UE to assist with
UE-based and/or UE-assisted positioning and/or may include positioning
of the target UE. The
E-SMLC then returns the result of the location service back to the MME
(e.g., a position estimate
for the UE and/or an indication of any assistance data transferred to

the UE). In the case of a

location service requested by an entity other than the MME (e.g., UE,
eNB, or E-SMLC), the MME
returns the location service result to this entity.
The SLP is the SUPL entity responsible for positioning over the user
plane.
source : 3GPP 3605-900
LTE Protocols & Specifications
In LTE architecture, core network includes Mobility Management Entity
(MME), Serving Gateway
(SGW), Packet Data Network Gateway (PDN GW) where as E-UTRAN has EUTRAN NodeB (eNB).
The figures shown below provide mapping of protocols to corresponding
specifications. To
find 3GPP LTE specification, click at the corresponding protocol in
the images below.
Protocol structure of control plane in between UE & MME is shown
below.
This figure below shows protocol structure in between UE & P-GW user
plane. GPRS Tunnelling
Protocol for the user plane (GTP-U) tunnels user data between eNodeB
and the S-GW as well as
between the S-GW and the P-GW in the backbone
network.
The X2 interface is defined between two neighbour eNBs. This figure
below shows the control &
user plane protocol stack of the X2 interface.

Understanding CS Fallback in LTE

By LteWorld - Posted on 27 September 2009
LTE technology supports packet based services only, however 3GPP does
specifies fallback for
circuit switched services as well. To achieve this LTE architecture
and network nodes require
additional functionality, this blog is an attempt to provide overview
for same.
In LTE architecture, the circuit switched (CS) fallback in EPS enables
the provisioning of voice
and traditional CS-domain services (e.g. CS UDI video/ SMS/ LCS/
USSD). To provide these
services LTE reuses CS infrastructure when the UE is served by E
UTRAN.
A CS fallback enabled terminal, connected to E UTRAN may use GERAN or
UTRAN to connect to
the CS domain. This function is only available in case E UTRAN

coverage is overlapped by either

GERAN coverage or UTRAN coverage.
The figure above provides architecture for CS fallback in EPS.
CS Fallback and IMS based services can co-exist in the same
operators network. Although
its not very straight forward to support CS fallback, all
participating elements i.e UE, MME, MSC
& E-UTRAN needs to support additional functionalities.
The support CS fallback in EPS a new interface SGs is added in LTE
architecture. SGs interface is
the reference point between the MME and MSC server. SGs interface is
used for the mobility
management and paging procedures between EPS and CS domain, and is
based on the Gs
interface procedures.
The SGs reference point is also used for the delivery of both mobile
originating and mobile
terminating SMS.
The CS fallback enabled network elements need to support the
following additional functions:
UE
supports access to E-UTRAN/EPC as well as access to the CS domain
over GERAN and/or
UTRAN.
Combined procedures for EPS/IMSI attach, update and detach.
CS fallback and SMS procedures for using CS domain services.
MME
Deriving a VLR number and LAI from the GUTI received from the UE or
from a default LAI.
Maintaining of SGs association towards MSC/VLR for EPS/IMSI attached
UE.
Initiating IMSI detach at EPS detach.
Initiating paging procedure towards eNodeB when MSC pages the UE for
CS services.
Support of SMS procedures
Rejecting CS Fallback call request (e.g. due to O&M reasons)
Use of the LAI and a hash value from the IMSI to determine the VLR
number when multiple
MSC/VLRs serve the same LAI.
MSC
Maintaining SGs association towards MME for EPS/IMSI attached UE.
Support of SMS procedures as provided in 3GPP specification
E-UTRAN
Forwarding paging request and SMS to the UE.
Directing the UE to the target CS capable cell.
At MME - MSC Server interface a new protcol SGsAP is being added to
support CS fallback.
SGsAP protocol is based on the BSSAP+. Stream Control Transmission
Protocol (SCTP) is used to

transport SGsAP signaling messages.

A CS Fallback and IMS capable UE would follow the procedures for
domain selection for UE
originating session/calls according to 3GPP specification 23.221.
If a UE is configured to use SMS over IP services and it is registered
to IMS then it would send
SMS over IMS, even if it is EPS/IMSI attached.
The home operator has option to activate/deactivate the UE
configuration to use SMS over IP by
means of device management in order to allow alignment with HPLMN
support of SMS over IP.
When UE is performing CS fallback procedure for Mobile Originating
Call for the purpose of
emergency call, it needs to indicate to the MME that this CS fallback
request is for emergency
purpose. MME also indicates to the E-UTRAN via the appropriate S1-AP
message that this CS
fallback procedure is for emergency purpose.
Contents of this blog are mostly derived from 3GPP specification
23.272, for better and detailed
understanding, same should be referred.
Although there had been talks about another approach for CS Fallback
by VoLGA which does
not require any enhancement in existing CS elements like MSC but for
VoLGA another set of
additional nodes are needed. to know more about VoLGA refer one of our
earlier blog LTE
needs VoLGA.