The LTE Network Architecture: A Comprehensive Tutorial
The LTE Network Architecture: A Comprehensive Tutorial
The LTE Network Architecture: A Comprehensive Tutorial
Long Term Evolution (LTE) is the latest buzzword on everyone’s lips, but are you as
conversant with the LTE architecture as you would like to be, or — more importantly —
need to be? Would you like to find out more about LTE, but have little time to devote
to it? If so, this paper will help get you up to speed in no time. Originally published as a
chapter in the most comprehensive LTE reference book available, LTE — The UMTS Long
Term Evolution: From Theory to Practice (Wiley 2009), this paper provides a short, but
comprehensive, overview of the 3GPP Release 8 LTE network architecture and interfaces,
showing how it can be deployed in an optimized and efficient manner. Engineers involved
in the design of LTE interfaces and network equipment, as well as those involved in the
first deployments of this new technology, should find this paper invaluable.
Table of contents
1 1. Executive summary
1 2. Introduction
7 4. Protocol architecture
7 4.1 User plane
8 4.2 Control plane
22 8. Summary
22 9. Abbreviations
23 10. Contacts
23 11. References
1. Executive summary
This paper provides a comprehensive overview of the network architecture of a Long Term Evolution
(LTE) system according to the Release 8 version of the specifications. It is designed to enable the reader
to become conversant rapidly with the main principles of the LTE network architecture. Engineers
involved in the design of LTE interfaces and network equipment, as well as those involved in the first
deployments of this new technology, should find this paper invaluable.
Not only does this paper provide a straightforward introduction to the definitive but complex speci-
fications defined by the Third-Generation Partnership Project (3GPP), but it also particularly high-
lights aspects of the network architecture and interfaces that enable LTE networks to be deployed in
an optimized and efficient manner. References are provided throughout so that the interested reader
can readily access more detailed material.
The content of this paper, authored by Sudeep Palat and Philippe Godin, was originally published
as an invited chapter in the book LTE — The UMTS Long Term Evolution: From Theory to Practice
(Wiley 2009), edited by Stefania Sesia, Issam Toufik and Matthew Baker, which is widely recognized
as the most comprehensive reference book available on LTE. Sudeep Palat, Philippe Godin and
Matthew Baker are all lead representatives in Alcatel-Lucent’s 3GPP standardization team.
2. Introduction
In contrast to the circuit-switched model of previous cellular systems, Long Term Evolution (LTE)
has been designed to support only packet-switched services. It aims to provide seamless Internet
Protocol (IP) connectivity between user equipment (UE) and the packet data network (PDN),
without any disruption to the end users’ applications during mobility.
While the term “LTE” encompasses the evolution of the Universal Mobile Telecommunications
System (UMTS) radio access through the Evolved UTRAN (E-UTRAN), it is accompanied by an
evolution of the non-radio aspects under the term “System Architecture Evolution” (SAE), which
includes the Evolved Packet Core (EPC) network. Together LTE and SAE comprise the Evolved
Packet System (EPS).
EPS uses the concept of EPS bearers to route IP traffic from a gateway in the PDN to the UE.
A bearer is an IP packet flow with a defined quality of service (QoS) between the gateway and the UE.
The E-UTRAN and EPC together set up and release bearers as required by applications.
This paper provides a comprehensive tutorial of the overall EPS network architecture, giving an
overview of the functions provided by the core network (CN) and E-UTRAN. The protocol stack
across the different interfaces is explained, along with an overview of the functions provided by the
different protocol layers. The end-to-end bearer path along with QoS aspects are also discussed,
including a typical procedure for establishing a bearer. The remainder of this paper presents the
network interfaces in detail, with particular focus on the E-UTRAN interfaces and the procedures
used across these interfaces, including those for the support of user mobility.
S6a
HSS
MME PCRF
S1-MME S11 Gx Rx
Operator’s
UE eNodeB S-GW P-GW IP services (for example,
LTE-Uu SI-U S5/S8 SGi IMS, PSS)
This is achieved by means of several EPS network elements that have different roles. Figure 1 shows
the overall network architecture, including the network elements and the standardized interfaces.
At a high level, the network is comprised of the CN (EPC) and the access network E-UTRAN.
While the CN consists of many logical nodes, the access network is made up of essentially just one
node, the evolved NodeB (eNodeB), which connects to the UEs. Each of these network elements
is interconnected by means of interfaces that are standardized in order to allow multi-vendor
interoperability. This gives network operators the possibility to source different network elements
from different vendors. In fact, network operators may choose in their physical implementations
to split or merge these logical network elements depending on commercial considerations. The
functional split between the EPC and E-UTRAN is shown in Figure 2. The EPC and E-UTRAN
network elements are described in more detail below.
eNodeB
Inter-cell RRM
RB control
PDCP
S-GW P-GW
RLC
UE IP
Mobile anchoring address allocation
MAC
S1
PHY Packet filtering
E-UTRAN EPC
Internet
In addition to these nodes, EPC also includes other logical nodes and functions such as the Home
Subscriber Server (HSS) and the Policy Control and Charging Rules Function (PCRF). Since the
EPS only provides a bearer path of a certain QoS, control of multimedia applications such as VoIP
is provided by the IP Multimedia Subsystem (IMS), which is considered to be outside the EPS itself.
The logical CN nodes are shown in Figure 1 and discussed in more detail below:
• PCRF – The Policy Control and Charging Rules Function is responsible for policy control
decision-making, as well as for controlling the flow-based charging functionalities in the Policy
Control Enforcement Function (PCEF), which resides in the P-GW. The PCRF provides the
QoS authorization (QoS class identifier [QCI] and bit rates) that decides how a certain data flow
will be treated in the PCEF and ensures that this is in accordance with the user’s subscription
profile.
• HSS – The Home Subscriber Server contains users’ SAE subscription data such as the EPS-subscribed
QoS profile and any access restrictions for roaming. It also holds information about the PDNs to
which the user can connect. This could be in the form of an access point name (APN) (which
is a label according to DNS naming conventions describing the access point to the PDN) or a PDN
address (indicating subscribed IP address(es)). In addition the HSS holds dynamic information
such as the identity of the MME to which the user is currently attached or registered. The HSS may
also integrate the authentication center (AUC), which generates the vectors for authentication and
security keys.
• P-GW – The PDN Gateway is responsible for IP address allocation for the UE, as well as QoS
enforcement and flow-based charging according to rules from the PCRF. It is responsible for the
filtering of downlink user IP packets into the different QoS-based bearers. This is performed based
on Traffic Flow Templates (TFTs). The P-GW performs QoS enforcement for guaranteed bit rate
(GBR) bearers. It also serves as the mobility anchor for interworking with non-3GPP technologies
such as CDMA2000 and WiMAX® networks.
• S-GW – All user IP packets are transferred through the Serving Gateway, which serves as the
local mobility anchor for the data bearers when the UE moves between eNodeBs. It also retains
the information about the bearers when the UE is in the idle state (known as “EPS Connection
Management — IDLE” [ECM-IDLE]) and temporarily buffers downlink data while the MME
initiates paging of the UE to reestablish the bearers. In addition, the S-GW performs some
administrative functions in the visited network such as collecting information for charging (for
example, the volume of data sent to or received from the user) and lawful interception. It also
serves as the mobility anchor for interworking with other 3GPP technologies such as general
packet radio service (GPRS) and UMTS.
• MME – The Mobility Management Entity (MME) is the control node that processes the signaling
between the UE and the CN. The protocols running between the UE and the CN are known as
the Non Access Stratum (NAS) protocols.
NAS control procedures are specified in [1] and are discussed in more detail in the following section.
The MME creates a UE context when a UE is turned on and attaches to the network. It assigns a unique
short temporary identity termed the SAE Temporary Mobile Subscriber Identity (S-TMSI) to the UE that
identifies the UE context in the MME. This UE context holds user subscription information downloaded
from the HSS. The local storage of subscription data in the MME allows faster execution of procedures
such as bearer establishment since it removes the need to consult the HSS every time. In addition, the UE
context also holds dynamic information such as the list of bearers that are established and the terminal
capabilities.
To reduce the overhead in the E-UTRAN and processing in the UE, all UE-related information in
the access network, including the radio bearers, can be released during long periods of data inactivity.
This is the ECM-IDLE state. The MME retains the UE context and the information about the
established bearers during these idle periods.
To allow the network to contact an ECM-IDLE UE, the UE updates the network as to its new location
whenever it moves out of its current tracking area (TA); this procedure is called a tracking area
update. The MME is responsible for keeping track of the user location while the UE is in ECM-IDLE.
When there is a need to deliver downlink data to an ECM-IDLE UE, the MME sends a paging message
to all the eNodeBs in its current TA, and the eNodeBs page the UE over the radio interface. On
receipt of a paging message, the UE performs a Service Request procedure, which results in moving
the UE to the ECM-CONNECTED state. UE-related information is thereby created in the E-UTRAN,
and the radio bearers are reestablished. The MME is responsible for the reestablishment of the
radio bearers and updating the UE context in the eNodeB. This transition between the UE states is
called an idle-to-active transition. To speed up the idle-to-active transition and bearer establishment,
EPS supports concatenation of the NAS and Access Stratum (AS) procedures for bearer activation.
Some interrelationship between the NAS and AS protocols is intentionally used to allow procedures
to run simultaneously rather than sequentially, as in UMTS. For example, the bearer establishment
procedure can be executed by the network without waiting for the completion of the security procedure.
Security functions are the responsibility of the MME for both signaling and user data. When a UE
attaches with the network, a mutual authentication of the UE and the network is performed between
the UE and the MME/HSS. This authentication function also establishes the security keys that are
used for encryption of the bearers.
The E-UTRAN is responsible for all radio-related functions, which can be summarized briefly as:
• Radio resource management (RRM) – This covers all functions related to the radio bearers, such
as radio bearer control, radio admission control, radio mobility control, scheduling and dynamic
allocation of resources to UEs in both uplink and downlink.
• Header Compression – This helps to ensure efficient use of the radio interface by compressing
the IP packet headers that could otherwise represent a significant overhead, especially for small
packets such as VoIP.
• Security – All data sent over the radio interface is encrypted.
• Connectivity to the EPC – This consists of the signaling toward MME and the bearer path
toward the S-GW.
On the network side, all of these functions reside in the eNodeBs, each of which can be responsible for
managing multiple cells. Unlike some of the previous second- and third-generation technologies,
LTE integrates the radio controller function into the eNodeB. This allows tight interaction between the
different protocol layers of the radio access network (RAN), thus reducing latency and improving
efficiency. Such distributed control eliminates the need for a high-availability, processing-intensive
controller, which in turn has the potential to reduce costs and avoid “single points of failure.” Fur-
thermore, as LTE does not support soft handover there is no need for a centralized data-combining
function in the network.
One consequence of the lack of a centralized controller node is that, as the UE moves, the network
must transfer all information related to a UE, that is, the UE context, together with any buffered data,
from one eNodeB to another. Mechanisms are therefore needed to avoid data loss during handover.
The operation of the X2 interface for this purpose is explained in more detail in Section 7.
Figure 4. Roaming architecture for 3GPP accesses with P-GW in home network
HSS PCRF
Gx Rx
SGi Operator’s
P-GW IP services (for example,
IMS, PSS)
HPMN
VPLMN
MME
S1-MME S11 S8
LTE-Uu S1-U
UE E-UTRAN S-GW
UTRAN 3G-SGSN
S3
S4
MME
S1-MME S11
4. Protocol architecture
We outline here the radio protocol architecture of E-UTRAN.
The E-UTRAN user plane protocol stack is shown in blue in Figure 6, consisting of the Packet
Data Convergence Protocol (PDCP), Radio Link Control (RLC) and Medium Access Control
(MAC) sublayers that are terminated in the eNodeB on the network side. The respective roles of
each of these layers are explained in detail in Chapter 4 of [8].
Application
IP IP
Relay Relay
PDCP GTP-U
PDCP GTP-U GTP-U GTP-U
MAC MAC L2 L2 L2 L2
L1 L1 L1 L1 L1 L1
1
SAE also provides an option to use PMIP on S5/S8. More details on the MIP-based S5/S8 interface can be found in [3].
NAS NAS
Relay
RRC S1-AP
RRC S1-AP
RLC RLC IP IP
MAC MAC L2 L2
L1 L1 L1 L1
LTE-Uu S1-MME
UE eNodeB MME
The Radio Resource Control (RRC) protocol is known as “layer 3” in the AS protocol stack. It is
the main controlling function in the AS, being responsible for establishing the radio bearers and
configuring all the lower layers using RRC signaling between the eNodeB and the UE.
Broadly, bearers can be classified into two categories based on the nature of the QoS they provide:
• Minimum guaranteed bit rate (GBR) bearers that can be used for applications such as VoIP.
These have an associated GBR value for which dedicated transmission resources are permanently
allocated (for example, by an admission control function in the eNodeB) at bearer establishment
or modification. Bit rates higher than the GBR may be allowed for a GBR bearer if resources are
available. In such cases, a maximum bit rate (MBR) parameter, which can also be associated
with a GBR bearer, sets an upper limit on the bit rate that can be expected from a GBR bearer.
• Non-GBR bearers that do not guarantee any particular bit rate. These can be used for applications
such as web browsing or FTP transfer. For these bearers, no bandwidth resources are allocated
permanently to the bearer.
Each QCI is characterized by priority, packet delay budget and acceptable packet loss rate. The QCI
label for a bearer determines how it is handled in the eNodeB. Only a dozen such QCIs have been
standardized so that vendors can all have the same understanding of the underlying service char-
acteristics and thus provide corresponding treatment, including queue management, conditioning
and policing strategy.
This ensures that an LTE operator can expect uniform traffic-handling behavior throughout the
network regardless of the manufacturers of the eNodeB equipment. The set of standardized QCIs
and their characteristics (from which the PCRF in an EPS can select) is provided in Table 1 (from
Section 6.1.7 in [5]). The QCI table specifies values for the priority handling, acceptable delay budget
and packet loss rate for each QCI label.
The priority and packet delay budget (and to some extent the acceptable packet loss rate) from the
QCI label determine the RLC mode configuration (see Section 4.3.1 of [8]) and how the scheduler
in the MAC handles packets sent over the bearer (for example, in terms of scheduling policy, queue
management policy and rate-shaping policy). For example, a packet with higher priority can be
expected to be scheduled before a packet with lower priority. For bearers with a low acceptable loss
rate, an acknowledged mode (AM) can be used within the RLC protocol layer to ensure that
packets are delivered successfully across the radio interface.
The ARP of a bearer is used for call admission control — that is, to decide whether or not the
requested bearer should be established in case of radio congestion. It also governs the prioritization
of the bearer for pre-emption with respect to a new bearer establishment request. Once successfully
established, a bearer’s ARP does not have any impact on the bearer-level packet forwarding treatment
(for example, for scheduling and rate control). Such packet forwarding treatment should be solely
determined by the other bearer level QoS parameters such as QCI, GBR and MBR.
An S5/S8 bearer transports the packets of an EPS bearer between a P-GW and an S-GW. The S-GW
stores a one-to-one mapping between an S1 bearer and an S5/S8 bearer. The bearer is identified by
the GTP tunnel ID across both interfaces.
Application/service layer
The packets of an EPS bearer are transported by an S1 bearer between an S-GW and an eNodeB,
and by a radio bearer [6] between a UE and an eNodeB. An eNodeB stores a one-to-one mapping
between a radio bearer ID and an S1 bearer to create the mapping between the two.
IP packets mapped to the same EPS bearer receive the same bearer-level packet forwarding treatment
(for example, scheduling policy, queue management policy, rate shaping policy, RLC configuration).
In order to provide different bearer-level QoS, a separate EPS bearer must therefore be established
for each QoS flow. User IP packets must then be filtered into the appropriate EPS bearers.
Packet filtering into different bearers is based on TFTs. The TFTs use IP header information such as
source and destination IP addresses and Transmission Control Protocol (TCP) port numbers to filter
packets such as VoIP from web-browsing traffic, so that each can be sent down the respective bearers
with appropriate QoS. An Uplink TFT (UL TFT) associated with each bearer in the UE filters IP
packets to EPS bearers in the uplink direction. A Downlink TFT (DL TFT) in the P-GW is a similar
set of downlink packet filters.
As part of the procedure by which a UE attaches to the network, the UE is assigned an IP address
by the P-GW and at least one bearer is established. This is called the default bearer, and it remains
established throughout the lifetime of the PDN connection in order to provide the UE with always-on
IP connectivity to that PDN. The initial bearer-level QoS parameter values of the default bearer are
assigned by the MME, based on subscription data retrieved from the HSS. The PCEF may change
these values in interaction with the PCRF or according to local configuration. Additional bearers
called dedicated bearers can also be established at any time during or after completion of the attach
procedure. A dedicated bearer can be either a GBR or a non-GBR bearer (the default bearer always
The bearer-level QoS parameter values for dedicated bearers are received by the P-GW from the
PCRF and forwarded to the S-GW. The MME only transparently forwards those values received
from the S-GW over the S11 reference point (see Figure 5) to the E-UTRAN.
The PCRF sends a Policy Control and Charging (PCC) Decision Provision message indicating the
required QoS for the bearer to the P-GW. The P-GW uses this QoS policy to assign the bearer-level
QoS parameters. The P-GW then sends a Create Dedicated Bearer Request message including the
QoS and UL TFT to be used in the UE to the S-GW. After the S-GW receives the Create Dedi-
cated Bearer Request message, including bearer QoS, UL TFT and S1-bearer ID, it forwards it to
the MME (message 3 in Figure 9).
The MME then builds a set of session management configuration information including the UL TFT
and the EPS bearer identity and includes it in the Bearer Setup Request message that it sends to the
eNodeB (message 4 in Figure 9). Since the session management configuration is NAS information,
it is sent transparently by the eNodeB to the UE.
Messages 6 to 10 are the corresponding response messages to confirm that the bearers have been
correctly set up.
The S1 interface connects the eNodeB to the EPC. It is split into two interfaces, one for the control
plane and the other for the user plane. The protocol structure for the S1 and the functionality provided
over S1 are discussed in more detail below.
The SCTP protocol is well known for its advanced Figure 10. S1 control plane protocol stack
features inherited from TCP that ensure the required Radio
reliable delivery of the signaling messages. In addition it network S1-AP
layer
makes it possible to benefit from improved features such
as the handling of multi-streams to implement transport
network redundancy easily and avoid head-of-line blocking
SCTP
or multi-homing. (See IETF RFC 4960 [7].)
Transport IP
Network
An area of simplification in LTE (as compared to the Layer
Data link layer
UMTS Iu interface, for example) is the direct mapping of
S1 Application Protocol (S1-AP) on top of SCTP. This Physical layer
2
S ignaling System #7 (SS7) is a communications protocol defined by the International Telecommunication Union Telecommunication
Standardization Sector with a main purpose of setting up and tearing down telephone calls. Other uses include Short Message
Service, number translation, prepaid billing mechanisms and many other services.
One of the advantages of using GPRS Tunneling Protocol- Figure 11. S1-U user plane protocol stack
User plane (GTP-U) is its inherent facility to identify
tunnels and to facilitate intra-3GPP mobility. GTP-U
UDP
The IP version number and the data link layer have been
IPv6 (IETF RFC 2460)
left fully optional, as for the control plane stack. and/or
IPv4 (IETF RFC 791)
A transport bearer is identified by the GTP tunnel endpoints Data link layer
and the IP address (source Tunneling End ID [TEID]),
destination TEID, source IP address, destination IP Physical layer
Vendor-specific traffic categories (for example, real-time traffic) can be mapped onto Differentiated
Services (DiffServ) code points (for example, expedited forwarding) by network operations and
maintenance (O&M) configuration to manage QoS differentiation between the bearers.
With the support of the S1-flex function in LTE, an eNodeB must initiate an S1 interface toward
each MME node of the pool area to which it belongs. The list of MME nodes of the pool together with
an initial corresponding remote IP address can be directly configured in the eNodeB at deployment
(although other means may also be used). The eNodeB then initiates the TNL establishment with
that IP address. Only one SCTP association is established between one eNodeB and one MME.
During the establishment of the SCTP association, the two nodes negotiate the maximum number
of streams that will be used over that association. However, multiple pairs of streams are typically used
in order to avoid the head-of-line blocking issue mentioned above. (Note that a stream is unidirec-
tional and therefore pairs must be used.) Among these pairs of streams, one must be reserved by the
two nodes for the signaling of the common procedures (that is, those that are not specific to one UE).
The other streams are used for the sole purpose of the dedicated procedures (that is, those that are
specific to one UE).
Once the TNL has been established, some basic application-level configuration data for the system
operation is automatically exchanged between the eNodeB and the MME through an S1 Setup proce-
dure initiated by the eNodeB. This procedure constitutes one example of a network self-configuration
process provided in LTE to reduce the configuration effort for network operators compared to the
more usual manual configuration procedures of earlier systems.
Once the S1 Setup procedure has been completed, the S1 interface is operational.
At the next transition back to idle mode following a UE Context Release Command message sent from
the MME, the UE context in the eNodeB is erased and only the UE context in the MME remains.
For intra-LTE mobility, that is, mobility within the LTE system, the X2-handover procedure is normally
used for inter-eNodeB handover (described in Section 7.3). However, when there is no X2 interface
between the two eNodeBs, or if the source eNodeB has been configured to initiate handover towards
a particular target eNodeB through the S1 interface, then an S1-handover will be triggered.
The S1-handover procedure, shown in Figure 13, has been designed in a similar way to the UMTS
Serving Radio Network Subsystem (SRNS) relocation procedure: it consists of a preparation phase,
where the CN resources are prepared at the target side (steps 2 to 8), followed by an execution phase
(steps 8 to 12) and a completion phase (after step 13).
2. Handover Required
4. Handover Request
5. Resource setup
8. Handover command
9. Handover command
10. eNodeB Status Transfer
The Status Transfer procedure is assumed to be triggered in parallel with the start of data forward-
ing after the source eNodeB has received the handover command message from the source MME.
This data forwarding can be either direct or indirect, depending on the availability of a direct path
for the user plane data between the source eNodeB and the target eNodeB.
The Handover Notify message (step 13), which is sent later by the target eNodeB when the arrival
of the UE at the target side is confirmed, is forwarded by the MME to trigger the update of the path
switch in the S-GW toward the target eNodeB. In contrast to the X2-handover, the message is not
acknowledged and the resources at the source side are released later upon reception of a Release Resource
message directly triggered from the source MME (step 17 in Figure 13).
For mobility from LTE toward UMTS, the handover process can reuse the S1-handover procedures
described above, with the exception of the Status Transfer message, which is not needed at steps 10
and 11 since no PDCP context is continued.
For mobility toward CDMA2000, Figure 14. Uplink S1 CDMA2000 tunneling procedure
dedicated uplink and downlink
procedures have been introduced in eNodeB MME
LTE. They essentially aim at tunneling
the CDMA2000 signaling between Uplink S1 CDMA2000 Tunneling
the UE and the CDMA2000 system
over the S1 interface, without being
interpreted by the eNodeB on the
way. The Uplink S1 CDMA2000
Tunneling message shown in Figure 14 also includes the Radio Access Technology (RAT) type in
order to identify the CDMA2000 RAT with which the tunneled CDMA2000 message is associated
in order for the message to be routed to the correct node within the CDMA2000 system.
The MME load balancing procedure aims to distribute the traffic to the MMEs in the pool evenly
according to their respective capacities. To achieve this goal, the procedure relies on the normal
NNSF present in each eNodeB as part of the S1-flex function. (See Section 6.3.) Provided that suit-
able weight factors corresponding to the capacity of each MME node are available in the eNodeBs
The use of the same protocol structure over both interfaces provides advantages such as simplifying
the data forwarding operation.
Figure 15. X2 signaling bearer protocol stack Figure 16. Transport Network Layer for data streams over X2
Radio
Network X2-AP GTP-U
Layer
UDP
The initialization of the X2 interface starts with the identification of a suitable neighbor followed by
the setting up of the TNL.
Once a suitable neighbor has been identified, the initiating eNodeB can set up the TNL using the
X2 IP address of this neighbor, either as retrieved from the network or locally configured. In particular,
a SON-configuration dedicated procedure over S1 termed the eNB Configuration Transfer procedure
has been designed to enable the initiating eNodeB to directly request over the S1 interface the X2
IP address of a discovered neighbor eNodeB to be used for X2 establishment. This network solution
through the S1 interface may avoid the need for an operator to use other more complex network
solutions such as the deployment of DNS servers.
After the TNL has been set up, the initiating eNodeB must trigger the X2 Setup procedure. This
procedure enables an automatic exchange of application level configuration data relevant to the
X2 interface, similar to the S1 Setup procedure already described in Section 6.2. For example, each
eNodeB reports to a neighbor eNodeB, using the X2 Setup Request message, information about each
cell it manages, such as the cell’s physical identity, the frequency band, the tracking area identity
and/or the associated PLMNs.
This automatic data exchange in the X2 Setup procedure is also the core of another SON feature:
the automatic self-configuration of the PCIs. Under this new SON feature, the O&M system can
provide the eNodeBs with either a list of possible PCI values to use or a specific PCI value. In the
first case, in order to avoid collisions, the eNodeB should use a PCI that is not already used in its
neighborhood. Because the PCI information is included in the LTE X2 Setup procedure, while de-
tecting a neighbor cell by the ANR function, an eNodeB can also discover all the PCI values used
in the neighborhood of that cell and consequently eliminate those values from the list of suitable
PCIs to start with.
Once the X2 Setup procedure has been completed, the X2 interface is operational.
For those bearers requiring in-sequence delivery of packets, the Status Transfer message (step 8)
provides the sequence number (SN) and the Hyper Frame Number (HFN) that the target eNodeB
should assign to the first packet with no SN yet assigned that it must deliver. This first packet can
either be one received over the target S1 path or one received over X2, if data forwarding over X2
is used. (See below.) When the source eNodeB sends the Status Transfer message, it freezes its trans-
mitter/receiver status, that is, it stops assigning PDCP SNs to downlink packets and stops delivering
uplink packets to the EPC.
Mobility over X2 can be categorized according to its resilience to packet loss: the handover can be
termed “seamless” if it minimizes the interruption time during the move of the UE or “lossless” if
it tolerates no loss of packets at all. These two modes use data forwarding of user plane downlink
packets. The source eNodeB may decide to operate one of these two modes on a per-EPS-bearer
basis, based on the QoS received over S1 for this bearer (see Section 6.4) and the service at stake.
2. Measurement control
3. Handover decision
4. Handover Request
5. Resource setup
7. Handover Command
Data
8. Status Transfer forwarding
over X2
9. Handover Complete interface
to avoid
data loss
10. Path Switch Request
When forwarding is in operation and in-sequence delivery of packets is required, the target eNodeB
is assumed to first deliver the packets forwarded over X2 before delivering the ones received over the
target S1 path, once the S1 path switch has been done. The end of the forwarding is signaled over
X2 to the target eNodeB by the reception of “special GTP packets” that the S-GW has inserted
over the source S1 path just before switching this S1 path; these are then forwarded by the source
eNodeB over X2 like any other regular packets.
A new feature in LTE is the optimization of the radio by selective retransmission. When lossless
handover is used, the target eNodeB may not deliver over the radio interface some of the forwarded
downlink packets received over X2 if it is informed by the UE that these packets have already been
received at the source side. This is called downlink selective retransmission.
Similarly in the uplink, the target eNodeB may not wish the UE to retransmit packets already received
earlier at the source side by the source eNodeB, for example, to avoid wasting radio resources. To use
uplink selective retransmission, the source eNodeB forwards the user plane uplink packets that it has
received out of sequence to the target eNodeB, over a new GTP tunnel. The target eNodeB must first
request the source eNodeB to establish the new forwarding tunnel by including a GTP tunnel end-
point where it expects the forwarded uplink packets to be received in the Handover Request ACK
message. If possible, the source eNodeB then indicates in the Status Transfer message for this bearer,
the list of SNs corresponding to the expected forwarded packets. This list helps the target eNodeB
inform the UE earlier of the packets that are not to be retransmitted, making the overall uplink
selective retransmission scheme faster .
In order to detect an imbalance, itis necessary to compare the load of the cells and therefore to
exchange information about them between neighboring eNodeBs. The cell load information
exchanged can be of different types: radio measurements corresponding to the usage of physical
resource blocks, possibly partitioned into real-time and non-real-time traffic; or generic measure-
ments representing non-radio-related resource usage such as processing or hardware occupancy.
A client-server mechanism is used for the load information exchange: the Resource Status Response
and Update messages are used to report the load information over the X2 interface between a request-
ing eNodeB (client) and the eNodeBs that have subscribed to this request (servers). The reporting
of the load is periodic and according to the periodicity expressed in the Resource Status Request
message that triggered the procedure.
More generally, the historical UE information consists of some RRM information that is passed
from the source eNodeB to the target eNodeB within the Handover Request message to assist the
RRM management of a UE or of a cell. The information can be partitioned into two types:
• UE RRM-related information, passed over X2 within the RRC transparent container
• Cell RRM-related information, passed over X2 directly as an information element of the X2-AP
Handover Request message itself
8. Summary
In this paper the mechanisms by which the Evolved Packet System provides user equipment with
IP connectivity to the packet data network have been outlined.
It has been shown how the EPS supports multiple data flows with different quality of service per UE
for applications that need guaranteed delay and bit rate such as VoIP as well as best effort applications
such as web browsing.
Further, an overview of the EPS network architecture has been presented, including the functions
provided by the E-UTRAN access network and the evolved packet CN. It can be seen that the concept
of EPS bearers, together with their associated QoS attributes, provide a powerful tool for the provi-
sion of a variety of simultaneous services to the end user.
From the perspective of the network operator, the LTE system breaks new ground in terms of its
degree of support for self-optimization and self-configuration of the network through the X2, S1
and Uu interfaces, to facilitate deployment.
9. Abbreviations
3GPP Third-Generation Partnership Project GPRS general packet radio service
AM acknowledged mode GSM Global System for Mobile
ANRF automatic neighbor relation function Communications
The list above covers the abbreviations used in this paper. A comprehensive list of abbreviations relevant to LTE, together with concise
explanations of each, can be found in [9].
10. Contacts
For more information on Alcatel-Lucent’s LTE solution, please visit www.alcatel-lucent.com or
contact your Customer Team representative.
11. References
[1] 3GPP Technical Specification 24.301, Non-Access-Stratum (NAS) protocol for Evolved Packet
System (EPS); Stage 3 (Release 8), www.3gpp.org.
[2] 3GPP Technical Specification 33.401, System Architecture Evolution (SAE): Security
Architecture (Release 8) , www.3gpp.org.
[3] 3GPP Technical Specification 23.402, Architecture enhancements for non-3GPP accesses
(Release 8), www.3gpp.org.
[4] 3GPP Technical Specification 29.060, General Packet Radio Service (GPRS);
GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface (Release 8), www.3gpp.org.
[5] 3GPP Technical Specification 23.203, Policy and charging control architecture (Release 8),
www.3gpp.org.
[6] 3GPP Technical Specification 36.300, Evolved Universal Terrestrial Radio Access (E-UTRA)
and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description;
Stage 2 (Release 8), www.3gpp.org.
[7] Request for Comments 4960, The Internet Engineering Task Force (IETF), Network Working
Group, Stream Control Transmission Protocol, http://www.ietf.org.
[8] S. Sesia, I. Toufik, M. Baker (eds), LTE – The UMTS Long Term Evolution: From Theory to
Practice, Wiley, 2009
[9] S. Sesia. I. Toufik, M. Baker, LTE – The UMTS Long Term Evolution: A Pocket Dictionary of
Acronyms, Wiley, 2009, www.wiley.com/go/sesia_theumts.