lte sae engineering overview
TRANSCRIPT
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 1/188
LTE/SAEEngineering OverviewCourse Code: LT3600 Duration: 2 days Technical Level: 2
LTE courses include
LTE/SAE Engineering Overview
LTE Air Interface
LTE Radio Access Network
Cell Planning for LTE Networks
LTE Evolved Packet Core Network
4G Air Interface Awareness
Understanding Next Generation LTE
...delivering knowledge,
maximizing performance...
www.wraycastle.comWray Castle – leading the way in LTE training www.wraycastle.com
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 2/188
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 3/188
LTE/SAE ENGINEERING OVERVIEW
First published 2009
Last updated October 2011
WRAY CASTLE LIMITEDBRIDGE MILLS
STRAMONGATE KENDAL
LA9 4UB UK
Yours to have and to hold but not to copy
The manual you are reading is protected by copyright law. This means that Wray Castle Limited could take you and
your employer to court and claim heavy legal damages.
Apart from fair dealing for the purposes of research or private study, as permitted under the Copyright, Designs andPatents Act 1988, this manual may only be reproduced or transmitted in any form or by any means with the prior
permission in writing of Wray Castle Limited.
All of our paper is sourced from FSC (Forest Stewardship Council) approved suppliers.
© Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 4/188
LTE/SAE Engineering Overview
II © Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 5/188
Section 1 Introduction to LTE
Section 2 LTE OFDM Physical Layer
Section 3 LTE Higher-Layer Protocols
Section 4 Major Protocols
Section 5 Evolved Packet Core
Section 6 LTE Operation
Glossary
LTE/SAE ENGINEERING OVERVIEW
CONTENTS
III© Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 6/188
LTE/SAE Engineering Overview
IV © Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 7/188
SECTION 1
INTRODUCTION TO LTE
LTE/SAE Engineering Overview
I© Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 8/188
LTE/SAE Engineering Overview
II © Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 9/188
LTE Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.1
Broadband Access with LTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.2
Architecture Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.3
LTE Development and Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.4
LTE Standards Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.5
LTE Key Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.6
Access Networks and the eNB (Evolved Node B) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.7
X2 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.8
X2 Interface Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.9
X2 Deployment and Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.10
The EPC (Evolved Packet Core) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.11
S1 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.12
Evolved Packet Core ‘S’ Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.13
PDN Connectivity Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.14
NAS Identities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.15
EPS Area Identities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.16
Node Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.17
E-UTRA Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.18
CONTENTS
Introduction to LTE
III© Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 10/188
LTE/SAE Engineering Overview
IV © Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 11/188
At the end of this section you will be able to:
outline the evolutionary process prescribed for GSM and UMTS networks and show where
LTE/SAE fits in
explain the significance of LTE in the continued progression towards converging
telecommunications and entertainment markets
outline the overall performance aims for LTE
identify the key air interface, radio access and core network technologies chosen for E-UTRA
outline the basic architecture of the E-UTRAN and EPC including the eNB, the E-UTRAN
interfaces and the EPC elements
explain the role of the X2 interface in the E-UTRAN
explain the role of the S1 interface and other possible S interfaces within the EPC
outline the peak and average data rates that E-UTRA promises to supply and the range of
services that could be carried
describe the E-UTRA protocol stack and assign layer functions to the correct network entities
describe the functional split between X2-U and X2-C interface variants
OBJECTIVES
Introduction to LTE
V© Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 12/188
LTE/SAE Engineering Overview
VI © Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 13/188
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 14/188
LTE RadioAccess
Former ‘Mobile’Operator
Former ‘Fixed’Operator
Broadcastcontentprovider
New market
opportunities
New marketopportunities
LTE RadioAccess
LT3600/v3.11.2 © Wray Castle Limited
Broadband Access with LTE
Wide-area LTE radio access combined with the EPC represents a complete adoption of an all-IP
architecture, offering broadband delivery capability with the potential for bit rates of several hundred
megabits per second and QoS (Quality of Service) management suitable for real-time operation of high-
quality voice and video telephony.
LTE has a very important role in the overall telecommunications service convergence concept. LTE couldprovide a key to unlocking a truly converged fixed/mobile network for the delivery of quadruple play
services. Its potential bandwidth capabilities are sufficient for the support of services ranging from
managed QoS real-time voice or video telephony to high-quality streamed TV. Its flat all-IP architecture
means that it can act as a universal access network for a wide range of core network types.
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 15/188
E-UTRAN EPCE-UTRA
UE
LTE SAE
EPS
LT3600/v3.1 1.3© Wray Castle Limited
Architecture Terminology
LTE is the term used to describe collectively the evolution of the RAN (Radio Access Network) into the
E-UTRAN (Evolved Universal Terrestrial Radio Access Network) and the RAT (Radio Access Technology)
into E-UTRA (Evolved Universal Terrestrial Radio Access).
SAE (System Architecture Evolution) is the term used to describe the evolution of the core network into the
EPC (Evolved Packet Core). There is also a collective term, EPS (Evolved Packet System), which refersto the combined E-UTRAN and EPC.
Introduction to LTE
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 16/188
100 Mbit/s (downlink) and 50 Mbit/s (uplink)
Increased cell edge bit rate
2-4 times better spectral efficiency
Reduced radio access network latency
Scalable bandwidth up to 20 MHz
Interworking with 3G systems
LTE/SAE Design Aims
LT3600/v3.11.4 © Wray Castle Limited
LTE Development and Design Goals
The debate about the structure and composition of LTE has been ongoing since at least 2004, with
many different organizations promoting their preferred technological solutions for the systems.
3GPP brought some focus to the debate in June 2005 by publishing Technical Report TR 25.913 –
Requirements for Evolved UTRA and UTRAN.
TR 25.913 stated several objectives for the evolution of the radio interface and radio access network
architecture. Targets included a significantly increased peak data rate, e.g. 100 Mbit/s (downlink) and
50 Mbit/s (uplink), and an increased ‘cell edge bit rate’ while maintaining the same site locations as are
deployed for R99 (Release 99) and HSPA.
Other objectives include significantly improved spectrum efficiency (e.g. two to four times that provided
by Release 6 HSPA), the possibility for a significantly reduced radio access network latency for both
C-plane and U-plane traffic, scaleable bandwidth with support for channel bandwidths up to 20 MHz,
and support for interworking with existing 3G systems and non-3GPP-specified systems.
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 17/188
GSM900 GSM1800GSM1900
GPRS
EGPRS
UMTS HSDPA
IMS
HSUPA HSPA+
EDGE
LTE/SAE
Phase 1 Phase 2 Phase 2+
Rel 96-98 Rel 99 Rel 4 Rel 5 Rel 6 Rel 7 Rel 8 Rel 9
LTE-A
(Advanced)
Rel 10
Rel 99 Rel 4 Rel 5 Rel 6 Rel 7 Rel 8 Rel 9 Rel 10
Rel 8 Rel 9 Rel 10
LT3600/v3.1 1.5© Wray Castle Limited
LTE Standards Development
Since the publication of the first GSM specifications in the late 1980s, the technologies and techniques
employed by GSM networks have continually evolved and developed. GSM itself underwent a series of
changes, from Phase 1 to Phase 2 and eventually to Phase 2+. Phase 2+ progressed with a series of
yearly releases, starting with Release 96.
The UMTS was introduced as part of Release 99 and from then onwards the 3GPP 3G networktechnology has also been undergoing a process of evolution. The evolutions that particularly affect the air
interface are mainly contained in Releases 5, 6, 7 and 8. Release 5 and 6 introduced HSPA – HSDPA
(High Speed Downlink Packet Access) in R5 and (HSUPA) High Speed Uplink Packet Access, or
Enhanced Uplink, in R6. Release 7 outlines the changes necessary to deliver HSPA+ and Release 8
specifications begin to describe LTE – the Long Term Evolution of UMTS. Specification of LTE, generally
described as 3.9G, is completed in Release 9. Specification of LTE-Advanced, a full 4G solution, is
detailed in Release 10.
Further Reading: www.3gpp.org/releases
Introduction to LTE
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 18/188
E-UTRAN EPC
E-UTRA
LTE Signalling LTE Traffic
SCTP
All-IP
LT3600/v3.11.6 © Wray Castle Limited
LTE Key Technologies
Tests and evaluations carried out during 2007 led to the publication of the Release 8 36-series of
specifications, which began to detail the technological basis for LTE.
Of the original four candidate air interface technologies, two were chosen for the final version: OFDMA
(Orthogonal Frequency Division Multiple Access) and SC-FDMA (Single Carrier FDMA).
OFDMA is employed on the LTE downlink and is expected eventually to provide peak data rates
approaching 360 Mbit/s in a 20 MHz channel. SC-FDMA is employed on the LTE uplink and may deliver
up to 86 Mbit/s.
In addition to the air interface technologies, LTE simplifies the range of technologies employed in other
parts of the network.
LTE is an ‘all-IP’ environment, meaning that all air interface, backhaul and core network interfaces will
carry only IP-based traffic. The need to support different protocols for different traffic types, as was the
case with R99, is therefore avoided.
In this all-IP environment, layer 4 transport layer functions for signalling connections are performed usingan alternative to the traditional choices, TCP (Transmission Control Protocol) or UDP (User Datagram
Protocol).
SCTP (Stream Control Transmission Protocol) was developed with the needs of IP-based signalling in
mind and is used to manage and protect all LTE signalling services.
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 19/188
S1Evolved
Packet Core
S1
X2
eNB
(Evolved Node B)
eNB
E-UTRAN
LTE UE
PDCP
RLC
MACPHY
RRC
Uu
Inter-cell RRM
Radio bearer control
Connection mobility control
Radio admission control
Measurement control
Cell configuration
Dynamic resource allocation
LT3600/v3.1 1.7© Wray Castle Limited
Access Networks and the eNB (Evolved Node B)
The basic building blocks of the E-UTRA access network are the eNB (Evolved Node B) plus backhaul –
and nothing else.
All layers of the air interface protocol stack, including the elements that previously resided in the RNC
(Radio Network Controller) – RRC (Radio Resource Control), RLC (Radio Link Control) and MAC
(Medium Access Control) – have been moved out to the base station. As the eNB now anchors the mainbackhaul link to the core network, it has also assumed responsibility for managing the PDCP (Packet
Data Convergence Protocol) service, which provides header compression and ciphering facilities over
the air interface.
HSDPA began the process of moving RRM (Radio Resource Management) functions, such as packet
scheduling, from the RNC to the Node B. In LTE, all remaining RRC functions are devolved to the eNB,
meaning that there is no longer a role for a device such as the RNC.
Among the RRM functions now devolved to the eNB are radio bearer control, radio admission control,
connection mobility control and the dynamic allocation (via scheduling) of resources to UEs (User
Equipments) in both uplink and downlink directions.
Following on from innovations in R4 and R5 networks, LTE also supports the concept of flexible
associations between access and core network elements, meaning that each eNB has a choice of MME
(Mobility Management Entity) nodes to which to pass control of each UE. Dynamic selection of an MME
for each UE as it attaches is therefore also an eNB responsibility.
The eNB also receives, schedules and transmits control channel information in its cell, including paging
messages and broadcast system information, both of which are received from the MMEs.
The eNB also retains many of the more traditional roles associated with base stations, such as bearer
management. The eNB is responsible for routing U-plane traffic between each UE and its S-GW (Serving
Gateway).
The complexity of the eNB and of the decisions it is required to make are therefore much greater than for an R99 Node B.
Introduction to LTE
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 20/188
X2
IPData link layer
X2–AP
Physical layer
X2-C
SCTP
X2-U
UDP
IP
Data link layer
User planePDUs
Physical layer
GTP-U
LT3600/v3.11.8 © Wray Castle Limited
X2 Interface
With the removal of the RNC from the access network architecture, inter-eNB handover is negotiated and
managed directly between eNBs using the X2-C interface. In LTE implementations that need to support
macro diversity, the X2-U interface will carry handover traffic PDUs (Protocol Data Units) between eNBs.
X2-C (control plane) signalling is carried by the X2AP (X2 Application Protocol), which travels over an
SCTP association established between neighbouring eNBs.
X2AP performs duties similar to those performed by RNSAP (Radio Network Subsystem Application
Protocol), which operates between neighbouring RNCs over the Iur interface in UMTS R99 networks.
X2-U (user plane) traffic is carried by the existing GTP-U (GPRS Tunnelling Protocol – User plane), as
employed in UMTS R99 networks. The facilities provided by the X2-U interface are only expected to be
required if macro-diversity handover is supported.
Both sub-types of the X2 interface travel over IP: SCTP/IP for the X2-C and UDP/IP for the X2-U.
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 21/188
E-UTRAN IPTransport Network
eNode B
eNode B
eNode B
eNode B
eNode B
X2 Interface
LT3600/v3.1 1.9© Wray Castle Limited
X2 Interface Architecture
The X2 interface is designed to provide a logical signalling and traffic path between neighbouring eNBs.
The term ‘neighbouring’ in this sense refers to eNBs that generate adjacent cells between which UEs
would be expected to request handovers. The X2 interface is the functional successor to the UMTS Iur
interface, which interconnects neighbouring RNCs.
An eNB is only expected to support X2 interfaces to neighbouring sites with which there is a realistic
possibility of handover events occurring; an individual eNB would not be required to support X2
interfaces to all eNBs in the network. Indeed, the X2 is an optional interface and all of its functions can be
performed indirectly via the S1 and the MME/S-GW if direct connections are not supported.
Further Reading: 3GPP TS36.423, 36.300
Introduction to LTE
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 22/188
EPC IPBackbone
eNB
eNB
eNB
eNB
X2 routedvia EPC
X2 connecteddirectly
Logical S1
Logical X2
Physical eNBTransmission
EPC AccessRouter
MME
LT3600/v3.11.10 © Wray Castle Limited
X2 Deployment and Routing
If supported, logical X2 interfaces can be physically transported along either direct or indirect
connections.
A direct connection would require a point-to-point broadband connection to exist between the two related
eNB sites. This option offers advantages in terms of resilience, in the sense that if multiple physical
connections are supported the loss of one transmission link would not be catastrophic, but hasdisadvantages in terms of cost. If each eNB was expected to host connections to five or six neighbouring
sites, for example, the costs associated with the additional transmission requirements could be
unsustainably high.
Another disadvantage of using direct connections to support X2 interfaces is lack of flexibility. The LTE
E-UTRAN is designed to take advantage of a concept known as the SON (Self-Organizing Network). The
optional SON functionality supported by the eNB allows it to attempt to establish an X2 interface
connection automatically to any previously unknown local cells reported in UE measurements. Such
automatic discovery and connection is only possible when all local eNBs are connected to the same
common routing environment.
Most X2 connections can be expected to share the eNBs core transmission link with the S1 interface. X2traffic would then simply be routed back out towards the target eNB after arriving at a suitable E-UTRAN or
EPC IP router. The benefit of this approach, which was the preferred method of carrying Iu-CS and Iu-PS
connections between remote RNCs and the core network site in 3G networks, is that only one
transmission link per eNB is required. The disadvantage is that only one transmission link per eNB is
available, which introduces the potential for a lack of access network resilience.
Operators may decide to deploy a combination of direct and indirect X2 routing, with some heavily used
links between eNBs being provided with their own direct connections whilst other, less heavily used,
connections are routed via the core.
Further Reading: 3GPP TS36.423, 36.300
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 23/188
Internet
EPC
MME
S-GW PDN-GW
PCRF
HSS
NAS Security
Idle State Mobility Handling
EPS bearer control
Mobility
Anchoring
IP network
LT3600/v3.1 1.11© Wray Castle Limited
The EPC (Evolved Packet Core)
The reduced complexity in the RAN is mirrored by a similar reduction in the core network, where the EPC
structure consists of five main nodes, although others may be required for backwards-compatibility
purposes.
The MME handles control plane functions related to mobility management (authentication and security)
and idle mode handling (location updates and paging), in which sense it is broadly analogous to the VLR(Visitor Location Register) or GMM (GPRS Mobility Management) functions found in legacy networks.
The MME is also responsible for EPC bearer control, and so handles connection control signalling.
The S-GW and PDN (Public Data Network) Gateway are broadly analogous to the SGSN (Serving GPRS
Support Node) and GGSN (Gateway GPRS Support Node) found in R99 networks and perform user
plane handling, switching/routing and interfacing functions. Unlike legacy systems, however, bearer
control has been removed from these devices and resides with the MME.
The PCRF (Policy and Charging Rules Function) handles QoS and bearer policy enforcement and also
provides charging and rating facilities.
Subscriber management and security functions are handled by the HSS (Home Subscriber Server),which incorporates the functions of the legacy HLR (Home Location Register) and which is already
familiar from R5 elements such as the IMS (IP Multimedia Subsystem).
For backwards-compatibility purposes, SGSNs deployed to legacy parts of an operator’s network can be
interfaced to both the MME (for mobility management) and the S-GW (for user plane flows).
The MME then provides legacy systems with an interface to the HSS, and the S-GW and PDN EPC GW
assume the role previously performed by the GGSN.
The packet data services of legacy (GSM/GPRS, R99 and HSPA) networks and LTE/SAE systems can
therefore interwork via a unified set of core network elements if required. The gateway elements form the
EPC.
Introduction to LTE
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 24/188
MME
S-GW
IP
Data link layer
S1–AP
SCTP
Physical layer S1-MME
Physical layer
UDP
IPData link layer
User planePDUs
GTP–U
S1-U
LT3600/v3.11.12 © Wray Castle Limited
S1 Interface
Backhaul links to the core network are carried by the S1 interface. Following the general structure of the
Iub interface which it replaces, traffic over the S1 is logically split into two types.
S1-U flows carry user plane traffic and S1-MME flows carry mobility management, bearer control and
direct transfer control plane traffic.
Message structures for the S1-MME interface that operate between the eNB and the MME are defined by
S1AP (S1 Application Protocol). The S1AP performs duties that can be seen as a combination of those
performed by R99 RANAP (Radio Access Network Application Part) and GTP-C (GPRS Tunnelling
Protocol – Control plane).
To provide additional redundancy, traffic differentiation and load balancing, the S1- flex concept allows
each eNB to maintain logical connections to multiple S-GWs and MMEs – there may therefore be
multiple instances of the S1 interface per node.
The S1-U interface employs GTP-U to create and manage user-plane data contexts between the eNB
and the S-GW.
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 25/188
MME
PDN–GW
PCRF
HSS2G/3G SGSN
SGiS5
S3
S4
S6a
S7
S–GW
IP Services
IMS
WLAN or
WiMAX
S2
S1-UE-UTRAN
LTE
UTRAN/
GERAN
UMTS/
GPRS
S1-MME
S12
S11
Interworkingto MME
Rx+
LT3600/v3.1 1.13© Wray Castle Limited
Evolved Packet Core ‘S’ Interfaces
In addition to the S1 interface connecting the E-UTRAN to the EPC, a broader range of ‘S’ interfaces has
been defined to identify interconnections between EPC nodes and external nodes.
The gateways and the MME are the main new nodes in the EPC. They are interconnected via the S5 and
S11 interfaces.
The SGi interface provides a connection to the operator’s IP-based services. It is likely that this will
include services managed through the IMS. In this respect the S6a interface connects the MME to the
HSS, and the S7 interface provides access from the PCRF to the PDN-GW (Public Data Network
Gateway).
The S3 and S4 interfaces provide connectivity into the EPC from legacy 2G/3G SGSNs. However, the
UTRAN may be connected directly to the EPC via the S12 interface.
WLAN (Wireless Local Area Network) or WiMAX (Worldwide Interoperability for Microwave Access) can
be supported through the EPC via the S2 interface. This would require connectivity to the MME, which is
provided by interfaces and interworking functions not shown in this diagram.
Introduction to LTE
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 26/188
PDN-GW
PDNConnectivity
Service
Evolved PacketSystem
EPS Bearer
Packet DataNetwork
LT3600/v3.11.14 © Wray Castle Limited
PDN Connectivity Services
The EPS is designed to provide IP connectivity between a UE and a PDN (Packet Data Network).
The connection provided to a UE is referred to as a PCS (PDN Connectivity Service).
This consists of an EPS Bearer that connects the UE to an Access Point in a PDN-GW and traverses
both the E-UTRAN and the EPC. The PDN-GW routes traffic between the EPS Bearer and the externalPDN.
The EPS Bearer, in turn, carries one or more TFA (Traffic Flow Aggregate), which themselves carry one
or more SDF (Service Data Flow) between the UE and an external data network.
If a UE requires additional connectivity that is only available via a different PDN-GW Access Point, then
additional PDN Connectivity Services may be established in parallel.
Further Reading: 3GPP TS 23.401:4.7.1
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 27/188
MCC MNC MMEI
24 bits
GUTIM-TMSI
32 bits
M-TMSI
32 bits
M-TMSI
M-TMSI
32 bits
MMEC
8 bits
S-TMSI
LT3600/v3.1 1.15© Wray Castle Limited
NAS Identities
The main means of identifying EPS subscribers remains the IMSI (International Mobile Subscriber
Identity), which is permanently assigned to a subscriber account.
Temporary and anonymous identification of subscribers is provided by the GUTI (Globally Unique
Temporary Identity), which is assigned by the serving MME when a UE has successfully attached and is
reassigned if the UE moves to the control of a new MME.
The GUTI is analogous to the legacy TMSI, but with the additional feature that its structure uniquely
identifies not only the subscriber within the MME but also the MME that assigned it.
The GUTI is constructed from the GUMMEI (Globally Unique MME Identifier), which identifies the MME,
and the M-TMSI (MME Temporary Mobile Subscriber Identity). The M-TMSI is used to provide
anonymous identification of a subscriber within an MME once that subscriber has been authenticated
and attached. As with legacy TMSI use, the MME may elect to reissue the M-TMSI at periodic intervals
and it will be reissued in any case if the UE passes to the control of a different MME.
The GUMMEI is constructed from the MCC (Mobile Country Code), MNC (Mobile Network Code) and
MME ID. The MME ID is subdivided into an MME Group ID and MMEC (MME Code). The MMEC is theMME’s index within its pool.
The M-TMSI allows a subscriber to be uniquely identified within an individual MME, whereas the S-TMSI
(SAE TMSI) allows subscribers to be identified within an MME group or pool.
To achieve this, the S-TMSI simply adds the one-octet MMEC to the M-TMSI.
Further Reading: 3GPP TS 36.300 (E-UTRAN) and 24.301 (NAS)
Introduction to LTE
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 28/188
PLMN – MCC+MNC
MME Group ID (MMEGI)
Tracking Area ID (TAI)
Evolved Cell ID (ECGI) = eNB ID + Cell ID
LT3600/v3.11.16 © Wray Castle Limited
EPS Area Identities
The EPS continues to use the PLMN identifier employed by legacy 3GPP systems, which consists of the
MCC and the MNC.
The MMEGI is a 16-bit identifier assigned to an individual MME Pool. The MMEGI only has to be unique
within a PLMN.
The TAI (Tracking Area Identifier) is analogous to the LA (Location Area) or RA (Routing Area) identifiers
employed by the GERAN/UTRAN in that it is used to identify a group of cells in the access network. In
the E-UTRAN the TA is the granularity with which each UE’s location is tracked. It is also the area within
which a UE will be paged. The TAI consists of the network’s MCC and MNC followed by a TAC (Tracking
Area Code).
As in legacy systems it is necessary to be able to identify uniquely each cell in the network for call
establishment, paging, handover and billing purposes. 3GPP has devised an updated Cell ID known as
an ECGI (E-UTRAN Cell Global Identifier).
The ECGI incorporates a unique eNB Identifier, which allows the S1 and X2 interface protocols to
discover and identify the target nodes for functions such as EPS Bearer handover.
Further Reading: 3GPP TS 29.803, 23.401:5.2, 36.300:8.2
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 29/188
Gateway names/IP addresses
Access Point Name (APN)
GUMMEIMCC MNC MMEI
24 bits
MMEIMMEGI MMEC
8 bits16 bits
MCC MNC Cell IDeNB ID eCGI
20 bits 8 bits
LT3600/v3.1 1.17© Wray Castle Limited
Node Identifiers
The MME is primarily a signalling node and each MME has to be accessible to and exchange control
data with MMEs and other devices within its own network and in other networks elsewhere in the world.
For this reason, each MME is assigned a unique and globally significant identifier known as a GUMMEI.
The GUMMEI consists of the network’s MCC and MNC followed by a MMEI (MME Identifier), which in
turn consists of the MMEGI and the MMEC. The MMEGI identifies the pool to which the MME belongsand the MMEC is its index within that pool.
The addressing of S-GW and PDN-GW nodes follows the model for addressing legacy PS (Packet
Switched) core network nodes – ultimately, each node will be identified by an IP address, which may or
may not be backed up with a DNS-resolvable device name. The termination and anchor point for an EPS
Bearer is an access point in a PDN-GW, which is analogous to a PDP Context terminating on GGSN
APN in 2G/3G networks. Each PDN-GW AP is assigned an IP address associated with a DNS-resolvable
name – the APN.
The EPS ECGI is globally unique and allows individual cells to be separately identified. The ECGI is a
28-bit identifier which consists of the PLMN ID (MCC + MNC), a 20-bit eNB ID (which will be unique
within a PLMN) and an 8-bit Cell ID (which will be unique within one eNB). This gives each PLMN scopeto identify up to 1 million eNBs and for each eNB to control up to 256 cells.
Further Reading: 3GPP TS 23.401:5.2, 36.300
Introduction to LTE
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 30/188
Non-Access
Stratum (NAS)
Non-Access
Stratum (NAS)
RRC RRC
PDCP PDCP
RLC RLC
MAC MAC
Physical Layer Physical Layer
User Equipment eNB Evolved Packet Core
LT3600/v3.11.18 © Wray Castle Limited
E-UTRA Protocols
In line with other aspects of E-UTRA, the air interface protocol stack has been designed to reduce
complexity.
Whereas an R99/HSPA-enabled Node B employs a protocol stack with a variety of RLC and MAC
instances, an E-UTRA eNB employs a protocol stack with just one instance of each layer.
The extent of the air interface protocol stack has also been reduced. In previous incarnations of UMTS
some layers operated between the UE and the Node B, while most extended all the way to the RNC.
With the elimination of the RNC, all air interface protocols in E-UTRA operate between the UE and the
eNB.
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 31/188
SECTION 2
LTE OFDM PHYSICAL LAYER
LTE/SAE Engineering Overview
I© Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 32/188
LTE/SAE Engineering Overview
II © Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 33/188
Radio Carrier Orthogonality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.1
Spectral Efficiency in OFDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.2
Resilience to Time Dispersion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.3
Resilience to Multipath Fading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.4
The OFDM Transmitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.5
The OFDM Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.6
Subcarrier Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.7
OFDMA Resource Allocation Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.8
Channel Adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.9
MIMO Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.10
The Benefits of MIMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.11
Multi-User MIMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.12
Physical Layer Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.13
Channel Bandwidths and Subcarriers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.15
Frequency Bands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.16
Radio Channel Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.17
Modulation and Error Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.18
Physical Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.19
The Physical Layer Timing Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.20
Type 1 Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.21
Type 2 Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.22
Resource Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.23
Summary of the Downlink Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.24
Summary of the Uplink Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.25
CONTENTS
LTE OFDM Physical Layer
III© Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 34/188
LTE/SAE Engineering Overview
IV © Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 35/188
At the end of this section you will be able to:
describe an OFDM transmission system as a set of closely spaced orthogonal radio subcarriers
illustrate the potential performance benefit for the use of OFDM as opposed to single carrier
schemes
identify typical performance characteristics of OFDM signals in multipath fading channels
describe how channel adaptation can be used to enhance the performance of OFDM systems
describe how scalability is achieved in OFDM systems
describe the basic principles of MIMO operation
identify the key benefits that can be gained from MIMO implementation
outline the general structure of the E-UTRA physical layer
define the term ‘bandwidth agnostic’ in the context of E-UTRA
define the term ‘basic timing unit’ and its relevance in E-UTRA
describe the configuration of downlink and uplink frames and list the range of frame types
employed
describe the resource allocation models employed by E-UTRA including the role of the
resource block, resource grid and resource element
list the modulation and error coding options made available in E-UTRA
outline the function of the reference signal
describe the functions of the E-UTRA physical channels on both uplink and downlink
outline how control and traffic channels are mapped into the physical layer structure
OBJECTIVES
LTE OFDM Physical Layer
V© Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 36/188
LTE/SAE Engineering Overview
VI © Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 37/188
5 kHz
Spacing to next allocatedcarrier needs to be large
f 1
f 1 f 2
LT3600/v3.1 2.1© Wray Castle Limited
Radio Carrier Orthogonality
Consider a radio carrier being modulated by a 10 kbit/s bit steam using QPSK (Quadrature Phase Shift
Keying). It could be expected to see a spectral envelope following a (sin x)/ x function, as shown in the
diagram, with the first null located 5 kHz from the centre frequency.
In a classic FDM (Frequency Division Multiplexing) system, other radio carriers would be allocated and
spaced far enough away from the first to ensure minimal adjacent channel interference. The size of theguard band required would depend on the transmitter and receiver characteristics as well as the relative
powers.
However, in such a system it is assumed that there is no synchronization between the potential
interferers. It is this that leads to the need for large frequency spacing between adjacent carriers. In fact,
if there was synchronization between adjacent channels, a much smaller frequency spacing could be
used. The key is to be able to make use of the complex nature of the instantaneously transmitted
spectrum. The modulation envelope is only an artificial way of indicating all possibilities over time; a
snapshot at an instant in time would look different.
Consider a second radio carrier allocated such that its centre frequency coincides exactly with the null
in the first carrier’s envelope. It is using the same modulation scheme and carrying the same data rate.The result is as shown. Note that the carrier spacing of 5 kHz is the same magnitude as the symbol rate
of 5 ksps. The spectra of the two carriers now overlaps, but as long as the carrier frequencies and the
baseband data remain accurately synchronized, both can be demodulated successfully. The reason is
that this relationship between centre frequency offset and symbol rate maintains a high level of
orthogonality between the two radio carriers.
LTE OFDM Physical Layer
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 38/188
f 1 f 2
15 kHz
2 QPSK subcarriers
10 kbit/s per subcarrier
15 kHz total bandwidth
Centre frequency
f 1
Centre frequency
1 QPSK carrier
20 kbit/s
20 kHz total bandwidth
20 kHz
LT3600/v3.12.2 © Wray Castle Limited
Spectral Efficiency in OFDM
Considering again the two overlapping QPSK radio carriers, it can be seen that there is a relatively large
spectral efficiency gain. If the effective bandwidth of the transmitted signal is considered to be the
frequency separation of the first nulls then a single QPSK carrier modulated with 10 kbit/s would have a
null-to-null bandwidth of 10 kHz.
However, here there are two subcarriers, each of which is carrying 10 kbit/s using QPSK. Their respective null-to-null spectra overlap by 5 kHz. This gives a collective null-to-null bandwidth for the pair
of subcarriers of 15 kHz. Thus QPSK is being used to carry 20 kbit/s in a radio bandwidth of 15 kHz.
Note that a single QPSK modulated carrier carrying 20 kbit/s would result in a null-to-null bandwidth of
20 kHz.
The principle of independent reception of orthogonal radio carriers with overlapping spectrum can be
extended by using a large number of narrowband radio carriers within one wideband channel allocation.
This results in a very spectrally efficient channel that can carry high bit rates.
For example, if 1000 orthogonal radio carriers were modulated using QPSK, each carrying 10 kbit/s, the
net throughput for the channel would be 10 Mbit/s. This would require a total channel bandwidth of
slightly more than 5 MHz. Carrying the same bit rate with QPSK modulation onto a single radio carrier would require a null-to-null bandwidth of 10 MHz. Thus OFDM (Orthogonal Frequency Division
Multiplexing) almost doubles the spectral efficiency. Moreover, the resulting OFDM transmission is more
resilient to multipath effects in the channel.
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 39/188
High-bit-rate serial stream
S to P
Low bit rate parallel streams
Guardperiod
Useful symbolperiod
Multipath 1
Multipath 1
Multipath 1
LT3600/v3.1 2.3© Wray Castle Limited
Resilience to Time Dispersion
Spectral efficiency is not the only benefit associated with using OFDM. It also exhibits good tolerance to
the effects of multipath propagation in the channel; both fading and time dispersion.
Because the data rate on individual subcarriers with the channel is very low, the symbol period is
correspondingly long. The resulting symbol period is typically significantly longer than the time dispersion
that occurs in the channel. This means that relatively simple equalization can be used to counteractmultipath even though the net rate in the whole channel is very high.
Furthermore, a guard period can be inserted in every symbol period that covers the expected time
dispersion for the channel. This removes most of the time dispersion distortion from the useful symbol
period.
This guard period is usually created by repeating a copy of the last part of the symbol at the start. In this
case it is referred to as the cyclic prefix.
LTE OFDM Physical Layer
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 40/188
LT3600/v3.12.4 © Wray Castle Limited
Resilience to Multipath Fading
Tolerance to multipath fading effects comes from the overall wideband characteristic in the channel. A
narrowband channel tends to exhibit flat fading characteristics; that is to say, the fading characteristics
are coherent across the whole channel bandwidth. The effects of this can be seen in the diagram.
OFDM channels, on the other hand, are usually used to carry very high data rates and therefore require
many subcarriers occupying a relatively large bandwidth. In most cases the bandwidth will exceed thecoherence bandwidth by a large factor, so differing fading characteristics will be seen in different parts of
the channel. In effect, the wide channel provides a degree of frequency diversity with a resulting
improvement in performance.
However, it would be wrong to assume that this benefit for OFDM results solely because the channel
bandwidth is wide. A single carrier system with the same bit rate would also result in a wide radio
channel. Therefore, a single carrier system also benefits from this form of frequency diversity to some
extent.
In the single channel system, energy from each symbol will be spread across the whole radio channel
and each symbol will therefore suffer some distortion from any fading that may occur in any one part of
the channel. In an OFDM system only those symbols transmitted on subcarriers in the part of the channelaffected by a fade will be distorted. Symbols transmitted on other subcarriers will remain unaffected. It is
then possible to adapt the subcarriers in use according to the varying fading characteristics. This means
that only non-fading carriers will be used.
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 41/188
Serial
data
S P
M-ary
symbolbit
grouping
{b0, b
1, b
2…b }
M-arysymbol
mappingN
parallel
streams
N
complex
symbols
N -pointIFFT
I (real)
Q (imaginary)
N complexsamples in onesymbol period
sinecosine
Up-conversion
D/A
f c
OFDM signal with
N subcarriers
n
LT3600/v3.1 2.5© Wray Castle Limited
The OFDM Transmitter
The diagram shows a block representation of the transmitter that brings together the elements of symbol
mapping for QAM (Quaderature Amplitude Modulation) and the application of the IFFT (Inverse Fast
Fourier Transform) in order to produce an OFDM signal.
The serial data to be carried on the radio link is first passed through a serial-to-parallel conversion
process. The number of parallel streams will be equivalent to the number of data-carrying subcarriers inthe system. This number will usually be a power of two since this makes best use of the efficiencies
offered by the IFFT.
Bits on the parallel data streams will also be grouped as appropriate for the symbol constellation of M-ary
QAM scheme in use. For example, for QPSK bits are grouped in pairs; for 16QAM they are grouped in
fours and for 64QAM they are grouped in sixes.
The next process is symbol point mapping for the bit groups on each parallel data stream. The resulting
complex number symbols then form the input to an N-point IFFT where N will be a power of two
equivalent to the number of subcarriers in use.
The output of the IFFT will be a series of complex number digital samples representing the OFDM signalduring each symbol period. At this point the cyclic prefix is added by copying the last samples onto the
beginning of the symbol period. These complex real and imaginary sample values are used to form the I
and Q symbol streams. Next, the I and Q branches are subsequently multiplied onto sine and cosine
representations of the radio carrier. This generates a digital representation of the required multicarrier
M-ary QAM modulated transmit signal.
After digital-to-analogue conversion the resulting signal can be up-converted to the required channel
centre frequency before amplification and transmission.
LTE OFDM Physical Layer
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 42/188
Serial
data
P S
{b0, b
1, b
2…b }
N
parallel
streams
N
complex
symbols
N -point
FFT
I (real)
Q (imaginary)
N complex
samples in onesymbol period
sinecosine
Down-conversion
A/D
f c
OFDM signal with
N subcarriers
n
Integration
and
symbol
decisions
LT3600/v3.12.6 © Wray Castle Limited
The OFDM Receiver
The filtered OFDM signal is down-converted and then sampled for analogue to digital conversion. The
sampling rate at this point will be factored to allow for the inclusion of the cyclic prefix.
The cyclic prefix is removed and the sampled signal is separated into I and Q components. The result is a
series of complex samples that are used as the input to the FFT.
The FFT deconstructs the complex waveform in the symbol period to N complex values, each
representing a modulation symbol on one of the subcarriers. M-ary demodulation by integration and
reverse symbol mapping is performed to recover groups of bits represented by each of the received M-ary
modulation symbols.
Finally, parallel-to-serial conversion reconstructs that original serial bit stream.
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 43/188
Data subcarriersReference/pilotsubcarriers
Upper
unused/guard
Subcarriers
DCsubcarrier
Lower
unused/guard
Subcarriers
LT3600/v3.1 2.7© Wray Castle Limited
Subcarrier Assignment
Different subcarriers from across the population of subcarriers created by an OFDM channel are
assigned to different functions. Most subcarriers will be assigned to carry modulated user data signals.
Each data subcarrier will be modulated to carry one part of the entire parallel signal being transmitted
across the multi-tone channel. The data rate of each data subcarrier is determined by a combination of
the symbol rate and the modulation scheme employed.
In some variants of OFDM (such as that employed by WiMAX), entire subcarriers are given over to
carrying ‘pilot signals’. Pilot subcarriers allow channel quality and signal strength estimates to be made
and allow other control functions, such as frequency calibration, to operate. Pilots are generally
transmitted at a higher power level than data subcarriers – typically 2.5 dB higher – which serves to
make them more easily acquired by receiving stations.
In LTE and other systems, including DVB (Digital Video Broadcasting), the same function is performed by
‘reference signals’. A reference signal, like a pilot, allows a receiving station to recalibrate its receiver and
make channel estimates, but instead of occupying an entire subcarrier it is periodically embedded in the
stream of data being carried on a ‘normal’ subcarrier.
There are also two types of ‘null’ subcarrier – guards and the DC carrier. Nothing is transmitted on nullsubcarriers.
Guard subcarriers separate the top and bottom data subcarriers from any adjacent channel interference
that may be leaking in from neighbouring channels and, in turn, serves to limit the amount of interference
caused by the OFDM channel. The more guard subcarriers that are assigned, the lower the amount of
adjacent channel interference that will be caused or detected, but this also has an impact on the data
throughput of the channel.
The centre subcarrier of each OFDM channel – the one that has a 0 Hz offset from the channel’s centre
frequency – is known as the ‘DC carrier’ and is also null.
LTE OFDM Physical Layer
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 44/188
0 1 2 3 4 5 6 7 8 9
Symbol periods (time)
OFDM with
time
multiplexing
User 1 User 2 User 4
0 1 2 3 4 5 6 7 8 9Symbol periods (time)
User 2User 4
OFDM with time
and frequency
multiplexing
(OFDMA)
User 9
User 8
User 1User 3
User 7
LT3600/v3.12.8 © Wray Castle Limited
OFDMA Resource Allocation Strategies
The simplest option for multiple access in an OFDM system is to use a form of time multiplexing on the
OFDM radio bearer. This is illustrated in the top part of the diagram. Each user is allocated the full
channel bandwidth and all data subcarriers exclusively for a defined number of symbol periods.
The greatest efficiency can be achieved if dynamic time allocation is applied so that users with higher bit
rate requirements are allocated a greater proportion of time. However, in such a system the minimumresource allocation is one OFDM symbol. Even with dynamic time allocation, such an arrangement can
still become very inefficient when there is strong demand for multiple lower bit rate connections, for
example when multiple voice circuits are active. Consider an OFDM system operating in a 10 MHz
bandwidth, with a 512-point FFT and using 16QAM. Allowing for null and reference subcarriers, such a
system could transfer in the order of 1,600 bits in a single OFDM symbol period. This may seem a
modest resource unit, but delay requirements must also be accounted for. For a real-time service such
as voice it is essential to avoid excessive round-trip delay. To meet the delay requirement for a voice
service, resources may need to be allocated, for example once every 20 ms. This would mean in a
minimum bandwidth allocation to one user of 80 kbit/s (or 120 kbit/s if 64QAM is in use). Even allowing
for the error protection overhead this minimum resource will significantly reduce system efficiency and its
ability to benefit from optimal techniques such as discontinuous transmission and channel adaptation.
Greater efficiency in resource allocation can be gained from the use of subchannelization. This involves
division of resource by time and by frequency. Thus a user may be allocated a subset of the subcarriers
available in the system, as illustrated in the lower part of the diagram. This approach allows much finer
granulation in resource allocation and therefore greater efficiency. OFDM systems that support this are
usually described as OFDMA systems.
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 45/188
Modulation (QPSK/16QAM/64QAM)
Error protection coding rate
Adaptive fast scheduling
Node BPoor Radio Path
Interference
LT3600/v3.1 2.9© Wray Castle Limited
Channel Adaptation
The quality of the radio link is affected by many factors including fading, interference and time dispersion.
Terrestrial mobile radio channels, which are usually assumed to be non-line of site, can be very poor.
Therefore most terrestrial cellular radio systems are designed with robust modulation schemes and large
error protection overheads.
However, close examination of real channel conditions shows them to be very variable in short timeframes, and much of the time any given channel will show good performance. Thus the standard
approach engineers the channel to deal with the worst case, which only occurs for a small amount of
time.
It is clear that if the channel could be adapted at a rate fast enough to track changing channel conditions
then the average performance of a channel could be significantly improved. This is the principle of
channel adaptation. Channel adaptation is a common approach in many broadband radio systems and in
most cases involves the adaptation of the modulation scheme and the error protection overhead applied.
Adaptive scheduling can also be very effective, enabling the cell to make the best use of the pool of
channels allocated to different mobiles, each of which will be varying independently.
LTE OFDM Physical Layer
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 46/188
Data
stream
mapping
Pre-
coding
matrix
Signal
generation
MIMOdecoding
and channelestimation
Stream 1
Stream 2
Layer 1
Layer 2
Powerweightings and
beamforming
Feedback
2x2 MIMO or Rank 2 4x4 MIMO or Rank 4
LT3600/v3.12.10 © Wray Castle Limited
MIMO Concept
MIMO (Multiple Input Multiple Output) antenna arrays offer significant performance improvements over
conventional single antenna configurations.
The technique involves placing several uncorrelated antennas at both the receiving and transmitting ends
of the communication link. If there are four uncorrelated antennas at the transmitter and a further four
uncorrelated antennas at the receiver, then there will be 16 possible direct radio paths between thetransmitter and the receiver. Each of these is open to multipath effects, creating even more radio paths
between the transmitter and the receiver. These radio paths can then be constructively combined, thus
producing micro diversity gain at the receiver.
Since the receiver can distinguish between the various uncorrelated antennas, it is possible to transmit
different data streams in different paths. The stream applied to each antenna can be referred to as a
‘layer’ and the number of antennas available at the transmitter and receiver can be referred to as ‘rank’.
For example, a system operating with a 4x4 MIMO antenna array can be described as having four layers
and being of rank four. The way in which data streams are mapped to layers will change the specific
benefits offered by a particular MIMO implementation, and the specification of this is an important part of
system design. Pre-coding may also be used to improve the MIMO system performance. Pre-coding may
be adaptive and as such would be based on some source of channel estimation. This could be derived atthe transmission or the reception end of the link.
It is relatively easy to mount antennas on the base station in an uncorrelated manner. For a 2x2 MIMO
array a single cross-polar panel could be used. A 4x4 MIMO array would require two cross-polar polar
panels with suitable space separation. This is harder to achieve in a mobile. However, as for the base
station, 2x2 MIMO could be achieved with cross polarization, but this could result in some undesirable
directivity in the antenna.
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 47/188
MIMO brings
Diversity gain Array gain Spatial multiplexing gain
Decorrelates fading
through different
transmission paths
Provides a beamforming
effect that focuses
radiated energy in the
direction of the receiver
Enables multiple data
streams to be transmitted
on the same
frequency/time resource
LT3600/v3.1 2.11© Wray Castle Limited
The Benefits of MIMO
MIMO is potentially a complex technology but it can provide very significant benefits in system capability.
There are three key ways in which MIMO improves system performance. Any given MIMO
implementation may make use of all these benefits or may be configured to take particular advantage of
one of them. Ideally, a system should be designed with sufficient flexibility in MIMO implementation to
allow a system operator to choose the most suitable implementation for different environments or system
goals.
Diversity gain arises out of the provision of multiple antennas at the transmitting and/or receiving end of
the radio link. This creates multiple transmission paths with decorrelated fading characteristics. The
result is an overall improvement in channel signal-to-noise ratio leading to increased channel throughput
and reliability.
Array gain refers to the beamforming capability of a multiple antenna array. With suitable signalling of
feedback from the receiver, or with measurements made on a return link, it is possible to direct radiated
energy toward the receiver in a steered beam. The result is improved channel performance and
increased throughput.
Spatial multiplexing gain arises out of the orthogonality between the multiple transmission paths createdby the multiple antenna array. Since the receiver can resolve independent transmission paths it is
possible to map different information streams into the transmission paths, identifiable by their spatial
signature. This results in a direct increase in the channel throughput in proportion to the number of
separate transmission streams used.
LTE OFDM Physical Layer
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 48/188
SU-MIMO MU-MIMO
Multi-Cell MU-MIMO
LT3600/v3.12.12 © Wray Castle Limited
Multi-User MIMO
The basic implementation of MIMO is generally referred to as SU-MIMO (Single-User MIMO).
The SU-MIMO concept can be developed into MU-MIMO (Multi-User MIMO). In this case the spatial
multiplexing capability of MIMO is used to multiplex a link to more than one mobile using the same
time/frequency resource. The order of multiplexing available depends on the number of antennas (or
rank) available at the transmitter and receiver ends of the link. For example, the diagram shows a 2x2MIMO arrangement being used for MU-MIMO with two mobiles. In this case, the rate available to each
mobile would be lower than that potentially available to a single mobile with an SU-MIMO configuration,
but both mobiles are allocated the same time/frequency resource and still have the potential for diversity
and array gain. Thus cell capacity is increased, but the resource can be shared between a larger number
of users. The use of more than one transmitting or receiving station in this way is sometimes called
virtual MIMO.
It is also possible to implement MU-MIMO in one direction only with just single antennas on each of the
mobiles. In this case, array and diversity gain would be reduced, but time/frequency resources can still
be reused in the cell.
MU-MIMO can be further developed into multi-cell MU-MIMO. In this case the data streams are mappedto the combined antenna resources of two or more base stations that provide a combined connection to
multiple mobiles in multiple cells. The scenario in the diagram is in effect 4x4 MIMO but shared between
two connections. Note that spatial diversity will be significant in such a scenario because of the
geographical separation of the base station and of the mobiles.
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 49/188
RRC
MAC
Physical Layer
Transportchannels
Logical
channels
Physical channels
OFDM and SC-FDMABandwidth agnostic
TDD and FDDSFN for MBMSMIMO operation
Physical channel structure
Reference signalsModulation and coding
Synchronization and timingError coding and HARQ
Random accessPower control
Reporting and feedbackMeasurements
Handover
LT3600/v3.1 2.13© Wray Castle Limited
Physical Layer Functions
To support asymmetric services and to promote longer battery life for mobile terminals, the E-UTRA
physical layer employs different technologies on the uplink and downlink: OFDMA and SC-FDMA
respectively. The functions of the E-UTRA physical layer can be summarized as follows:
creation and management of the uplink and downlink physical channels
modulation (BPSK (Binary Phase Shift Keying), QPSK, QAM) and error coding
creation of reference signals in both uplink and downlink
management of the RACH (Random Access Channel)
OFDMA signal generation in the downlink and SC-FDMA signal generation in the uplink
modulation and up conversion
synchronization procedures, including cell search procedure and timing synchronization
power control procedures
management of CQI (Channel Quality Indication) reporting and MIMO feedback
physical uplink shared channel-related procedures, including UE sounding and HARQ (Hybrid
Automatic Repeat Request) ACK/NACK detection
reporting of measurement results to higher layers and the network
handover measurements, idle-mode measurements, etc.
LTE OFDM Physical Layer
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 50/188
RRC
MAC
Physical Layer
Transportchannels
Logical
channels
Physical channels
OFDM and SC-FDMABandwidth agnostic
TDD and FDDSFN for MBMSMIMO operation
Physical channel structure
Reference signalsModulation and coding
Synchronization and timingError coding and HARQ
Random accessPower control
Reporting and feedbackMeasurements
Handover
LT3600/v3.12.14 © Wray Castle Limited
Physical Layer Functions (continued)
E-UTRA supports services in a variety of channel bandwidths. In fact, the specification explicitly labels
E-UTRA as ‘bandwidth agnostic’, meaning that it has no rigidly defined or preferred channel bandwidth
and can be scaled to channels of almost any size. Both FDD and TDD modes are supported, as is a
‘half duplex’ mode.
E-UTRA has also been designed to work as the bearer for Multicast and Broadcast Multimedia Services(MBMS) and as such includes support for SFN (Single Frequency Network) operation.
Support for advanced antenna configurations has also been designed into the specification with MIMO
and beam-forming adaptive antennas both being referenced.
Further Reading: 3GPP TS 36.211
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 51/188
Channel bandwidths
(bandwidth/subcarriers)
1.4 MHz/72
3 MHz/180
5 MHz/300
10 MHz/600
15 MHz/900
20 MHz/1200
LT3600/v3.1 2.15© Wray Castle Limited
Channel Bandwidths and Subcarriers
E-UTRA/LTE is designed to work in a variety of bandwidths ranging initially from 1.4 MHz to 20 MHz. As
E-UTRA is described as being ‘bandwidth agnostic’, other bandwidths, ones that allow E-UTRA to be
backwards compatible with channel allocations from legacy network types, for example, could be
incorporated in the future.
The version of OFDMA employed by E-UTRA is similar to the versions employed by WiMAX or DVB, butwith a few key differences. In systems such as WiMAX, OFDMA schemes occupying different channel
bandwidths employ different subcarrier spacing, meaning that there is a different set of physical layer
parameters for each version of the system.
The E-UTRA scheme allows for two fixed subcarrier spacing options, 15 kHz in most cases, with an
optional 7.5 kHz spacing scheme, only applicable for TDD (Time Division Duplex) operation and intended
for in very large cells in an SFN. Fixing the subcarrier spacing reduces the complexity of a system that
can support multiple channel bandwidths.
Further Reading: 3GPP TS 36.211, 36.101:5.5, 36.104:5.5
LTE OFDM Physical Layer
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 52/188
FDD
Band UL Range (MHz) DL Range (MHz)
1 1920 – 1980 2110 – 2170
2 1850 – 1910 1930 – 1990
3 1710 – 1785 1805 – 1880
7 2500 – 2570 2620 – 2690
8 880 – 915 925 – 960
13 777 – 787 746 – 756
... ... ...
20 832 – 862 791 – 821
24 1626.5 – 1660.5 1525 – 1559
... ... ...
... ... ...
... ... ...
TDD
Band UL/DL Range (MHz)
33 1900 – 1920
34 2010 – 2025
35 1850 – 1910
36 1930 – 1990
37 1910 – 1930
38 2570 – 2620
39 1880 – 1920
40 2300 – 2400
LT3600/v3.12.16 © Wray Castle Limited
Frequency Bands
There is considerable regional variation in the availability of spectrum for LTE operation and this is
reflected in the standards. Along with flexibility in bandwidth there is considerable flexibility for spectrum
allocation. There are no requirements for minimum band support nor for band combinations. It is
assumed that this is determined by regional requirements.
The standards identify a range of bands for FDD operation, ranging from frequencies of approximately700 MHz through to frequencies in the range 2.7 GHz+. There also eight bands identified for TDD
operation ranging from approximately 1900 MHz to 2.6 GHz. Considerable scope has been left in the
standards to add more frequency bands as global requirements evolve.
Further Reading: 3GPP TS 36.101; 5.5, TS 36.104; 5.5
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 53/188
Channel bandwidth (MHz)
Transmission bandwidth configuration (n x RB)
Transmission
bandwidth (n x RB)
12 subcarriers
EARFCN(100 kHz raster)
LT3600/v3.1 2.17© Wray Castle Limited
Radio Channel Organization
For both uplink and downlink operation subcarriers are bundled together into groups of 12. This grouping
is referred to as an RB (Resource Block). The RB also has a dimension in time and when this is
combined with the frequency definition it forms the basic unit of resource allocation.
The number of resource blocks available in the system is dependent on channel bandwidth, varying
between 100 for 20 MHz bandwidth to just six for 1.4 MHz channel bandwidth. The nominal spectralbandwidth of an RB is 180 kHz for the standard 15 kHz subcarrier spacing. Note that this means there is
a difference between the stated channel bandwidth and the transmission bandwidth configuration, which
is expressed as n x RB. For example, in a 5 MHz channel bandwidth the transmission bandwidth would
be approximately 4.5 MHz. This difference acts as a guard band.
OFDMA channels are allocated within an operator’s licensed spectrum allocation. The centre frequency
is identified by an EARFCN (E-UTRA Absolute Radio Frequency Channel Number). The precise location
of the EARFCN is an operator decision, but it must be placed on a 100 kHz raster and the transmission
bandwidth must not exceed the operator’s licensed spectrum.
Further Reading: 3GPP TS 36.101:5.6, 5.7; 36.104:5.6, 5.7
LTE OFDM Physical Layer
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 54/188
Modulation
Schemes
Error Coding
Schemes
CRC
BPSK
QPSK
16QAM
64QAM
Signalling functions only
Optional on uplink
1/3 Turbo CodingTraffic and mostcontrol channels
1/3 CC BCH only
Transport Block 24 bit CRC
LT3600/v3.12.18 © Wray Castle Limited
Modulation and Error Protection
The range of modulation schemes used in E-UTRA comprises BPSK, QPSK, 16QAM (16-state
Quadrature Amplitude Modulation) and 64QAM (64-state Quadrature Amplitude Modulation). BPSK is
only employed for a limited set of signalling and reference functions, while 64QAM is optional on the
uplink.
The range of error coding options used in E-UTRA devices is far more limited than those available to, for example, a UMTS device. For most channels the only option is one-third rate turbo coding based on
convolutional coding.
Broadcast traffic channels are only permitted to use 1/3 Tail Biting convolutional coding. Various control
channels have been assigned either convolutional coding, block coding or simple repetition as their error
coding options.
In addition to error coding, transport blocks containing user and control traffic may also optionally have a
CRC (Cyclic Redundancy Check) block attached. Transport blocks on connections that have CRC
selected have a 24-bit CRC block appended to the end of the data container.
The familiar UMTS error monitoring levels of Bit Error Rate (BER), derived from the error coding service,and BLER (Block Error Rate), derived from CRC, continue to be available in E-UTRA.
Further Reading: 3GPP TS 36.211, 36.212, 36.300
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 55/188
Physical signalsPSS/SSS
Reference signals
Physical
layer
MACBCCH PCCH CCCH DCCH DTCH
BCH PCH RACH DL-SCH UL-SCH
PBCH PDCCH PHICH PCFICH PRACHPUCCH PDSCH PUSCH
MAC
Control
LT3600/v3.1 2.19© Wray Castle Limited
Physical Channels
The physical layer involves the transmission and reception of a series of physical channels and physical
signals. The physical signals relate to the transmission of reference signals, the PSS (Primary
Synchronization Signal) and the SSS (Secondary Synchronization Signal).
The PBCH (Physical Broadcast Channel) carries the periodic downlink broadcast of the RRC
MasterInformationBlock message. Note that system information from BCCH (Broadcast Control Channel)is scheduled for transmission in the PDSCH (Physical Downlink Shared Channel).
The PDCCH (Physical Downlink Control Channel) carries no higher layer information and is used for
scheduling uplink and downlink resources. Scheduling decisions, however, are the responsibility of the
MAC layer, therefore the scheduling information carried in the PDCCH is provided by MAC. Similarly the
PUCCH (Physical Uplink Control Channel) is used to carry resource requests from UEs that will need to
be processed by MAC.
The PHICH (Physical Hybrid ARQ Indicator Channel) is used for downlink ACK/NACK of uplink
transmissions from UEs in the PUSCH (Physical Uplink Shared Channel). It is a shared channel and
uses a form of code multiplexing to provide multiple ACK/NACK responses.
The PCFICH (Physical Control Format Indicator Channel) is used to indicate how much resource in a
subframe is reserved for the downlink control channels. It may be either one, two or three of the first
symbols in the first slot in the subframe.
The PRACH (Physical Random Access Channel) is used for the uplink transmission of preambles as part
of the random access procedure.
The PDSCH and the PUSCH are the main scheduled resource on the cell. They are used for the
transport of all higher-layer information including RRC signalling, service-related signalling and user
traffic. The only exception is the system information in PBCH.
Further Reading: 3GPP TS 36.213, 36.211, 36.300
LTE OFDM Physical Layer
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 56/188
c. 32.5 nsTs =
130,720,000
115,000 x 2048
Ts =
Ts (Time unit) =
LT3600/v3.12.20 © Wray Castle Limited
The Physical Layer Timing Unit
Almost all numbers, durations and calculations related to E-UTRA are derived from a fundamental
parameter known as Ts or the basic ‘time unit’. Ts represents the ‘sampling time’ of the overall channel
and is itself derived from basic channel parameters. The definition of Ts is based on a 20 MHz channel
bandwidth with 15 kHz subcarrier spacing and an FFT size of 2048.
Ts is calculated to be the reciprocal of the subcarrier spacing multiplied by the total number of subcarriers in the FFT, or:
Ts = 1/(15,000 x 2048) seconds = 3.25 nsec
Frame, subframe and slot lengths, cyclic prefix durations and many other key parameters are defined as
multiples of Ts.
Crucially, the value of Ts does not vary between E-UTRA physical layer configurations. As Ts stays
constant, all of the key parameters used to define the E-UTRA structure also stay constant. This
consistency reduces the overall complexity of E-UTRA and enables system manufacturers to scale their
devices more easily to a variety of channel bandwidths and frequency bands.
Further Reading: 3GPP TS 36.211:4
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 57/188
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 190
Frame – 10 ms (307200T s)
Slot – 0.5 ms (15360T s)
0 1 2 3 4 5 6
Subframe – 1 ms (30720Ts)
Normal cyclic prefix(total per subframe 2048T s)
0 1 2 3 4 5 6
OFDMSymbol
CP
CP (160/144Ts)
2048Ts
00 1 2 3 4 5 0 1 2 3 4 5
Extended cyclic prefix(total per subframe 6144T s)
OFDMSymbol
CP
CP (512Ts)
2048Ts
LT3600/v3.1 2.21© Wray Castle Limited
Type 1 Frame Structure
There are two basic frame types employed in E-UTRA, which are common to both uplink and downlink.
Type 1 frames are employed for FDD full- and half-duplex systems, while Type 2 frames are reserved for
TDD operation only.
The Type 1 frame duration is 10 ms and it is divided into 20 slots, each of 0.5 ms duration. More
significantly, however, for most information transmission, two slots are combined to form a subframe.Thus subframe duration is 1 ms, which corresponds to the TTI (Transmission Time Interval) for
E-UTRA.
Type 1 slots contain either 7 or 6 symbols, depending upon which CP (cyclic prefix) type is in use.
Additionally, the length of the CP prefixed applied in a particular symbol within a slot varies, also
dependent on which CP length is in use. With the normal CP, symbol 0 in each slot has a CP equal to
160 x Ts or 5.2 µsec, while the remaining symbols in the slot have slightly shorter CPs of just 144 x Ts or
4.7 µsec. When using the extended CP, all symbols are prefixed with a CP of 512 x Ts or 16.7 µsec.
Scheduling occurs across a subframe period. Up to the first three symbols in the first slot of each
subframe can be defined as a ‘control region’ carrying control and scheduling messages. The remaining
symbols of the first and all symbols in the second slot within the subframe are then available for user traffic.
Further Reading: 3GPP TS 36.211
LTE OFDM Physical Layer
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 58/188
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 190
Frame – 10 ms (307200T s)
Slot – 0.5 ms (15360T s)Half-frame – 5 ms (153600T s)
2 3 4 5 7 8 90
Subframe
0 1 2 3 4 5 6
Subframe – 1 ms (30720Ts)
0 1 2 3 4 5 6
or
00 1 2 3 4 5 0 1 2 3 4 5
Subframe – 1 ms (30720Ts)
DwPTS GP UpPTS
UL/DL
Config.5 ms (half-frame) switching
0 D U
1 D U
2 D U
6 D U
10 ms (full-frame) switching
3 U
4 D U
5 D U
UL/DL Switching Options
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
U
D
U
D
U
U
U
U
U
U
U
U
U
U
U
U
U
U
LT3600/v3.12.22 © Wray Castle Limited
Type 2 Frame Structure
Type 2 frames are used in TDD configured systems. They have a structure that is generally similar to
UMTS TDD LCR (Low Chip Rate), sometimes known as TD-CSCDMA. They share the 10 ms frame
structure and 1 ms subframe, but an additional demarcation known as a half-frame is also defined.
Each half-frame carries five subframes, the second of which contains three specialized fields. DwPTS
(Downlink Pilot Time Slot), UpPTS (Uplink Pilot Time Slot) and GP (Guard Period) appear in subframe 1and optionally also in subframe 6 within a frame.
GP provides the downlink to uplink switching point for TDD operation, thus the system is configurable for
either 5 ms switching or 10 ms switching. The uplink to downlink switching points are variable within
either the 5 ms half-frame or the 10 ms frame, dependent on the configuration selected. Subframes 0
and 5, along with DwPTS, are always used for downlink transmission. UpPTS and the following frame
are always used for uplink transmission, the aim being to provide backward compatibility with UMTS TDD
mode and potentially also with WiMAX.
The terms DwPTS and UpPTS are inherited from UMTS, but in E-UTRA they can be used for normal
uplink or downlink symbol transmission carrying some control functions. Thus they really represent
fractional slot use leading into and out of a guard period.
Further Reading: 3GPP TS 36.211:4
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 59/188
Subcarrier 1
Subcarrier 12
Resource block
1 ms subframe (2 slots)
Resource element
0 1 2 3 4 5 6 0 1 2 3 4 5 6
0 1 2 3 4 5 6 0 1 2 3 4 5 6
0 1 2 3 4 5 6 0 1 2 3 4 5 60 1 2 3 4 5 6 0 1 2 3 4 5 6
0 1 2 3 4 5 6 0 1 2 3 4 5 6
0 1 2 3 4 5 6 0 1 2 3 4 5 6
0 1 2 3 4 5 6 0 1 2 3 4 5 6
0 1 2 3 4 5 6 0 1 2 3 4 5 6
0 1 2 3 4 5 6 0 1 2 3 4 5 6
0 1 2 3 4 5 6 0 1 2 3 4 5 6
0 1 2 3 4 5 6 0 1 2 3 4 5 6
0 1 2 3 4 5 6 0 1 2 3 4 5 6
LT3600/v3.1 2.23© Wray Castle Limited
Resource Blocks
A resource block consists of 12 subcarriers (in the frequency domain) for one slot period (in the time
domain). On both the uplink and downlink directions, 12 subcarriers correspond to 180 kHz of bandwidth.
The minimum possible capacity allocation period is the TTI of 1 ms. This equates to the allocation of two
consecutive resource blocks. Additionally, the sum of all the resource blocks in a single slot period is
known as the resource grid.
The theoretical minimum definable capacity allocation unit is the resource element, which is defined as
one subcarrier during one symbol period. Within each resource grid the resource elements that will be
carrying reference signals are assigned first; the remaining elements are then available to have user data
or control mapped to them.
In data transfer terms, one resource element is the equivalent of one modulation symbol on a subcarrier,
so if QPSK modulation was being employed, one resource element would be equal to 2 bits, with 16QAM
4 bits and with 64QAM 6 bits of transferred data.
If MIMO is employed on the downlink then separate resource grids are created for each antenna port –
each port maps to a different MIMO stream.
Further Reading: 3GPP TS 36.211:5.2
LTE OFDM Physical Layer
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 60/188
0 1 2 4 5 6 0 1 2 4 5 6
0 1 2 4 5 6 0 1 2 4 5 6
1 2 5 6 1 2 5 6
0 1 2 4 5 6 0 1 2 4 5 6
0 1 2 4 5 6 0 1 2 4 5 6
1 2 5 6 1 2 5 6
0 1 2 4 5 6 0 1 2 4 5 6
0 1 2 4 5 6 0 1 2 4 5 6
1 2 5 6 1 2 5 6
0 1 2 4 5 6 0 1 2 4 5 6
0 1 2 4 5 6 0 1 2 4 5 6
1 2 5 6 1 2 5 6
R1
R1
R1
R1
3 3
3 3
3 3
3 3
3 3
3 3
3 3
3 3
3 3
3 3
3 3
3 3
Antenna port 1 Antenna port 1
R1
R1
R1
R1
FrameSubframe
Slot
0 1 2 4 5 6 0 1 2 4 5 6
0 1 2 4 5 6 0 1 2 4 5 6
1 2 5 6 1 2 5 6
0 1 2 4 5 6 0 1 2 4 5 6
0 1 2 4 5 6 0 1 2 4 5 6
1 2 5 6 1 2 5 6
0 1 2 4 5 6 0 1 2 4 5 6
0 1 2 4 5 6 0 1 2 4 5 6
1 2 5 6 1 2 5 6
0 1 2 4 5 6 0 1 2 4 5 6
0 1 2 4 5 6 0 1 2 4 5 6
1 2R0 5 6 1 2 5 6
R0
R0
R0
R0
R0
R0
R0
3 3
3 3
3 3
3 3
3 3
3 3
3 3
3 3
3 3
3 3
3 3
3 3
Antenna port 0
Antenna port 0
LT3600/v3.12.24 © Wray Castle Limited
Summary of the Downlink Structure
The diagram shows an example of a populated downlink FDD frame using the normal CP, 2x2 MIMO
and implemented in a 5 MHz bandwidth channel.
The PBCH is transmitted during subframe 0 of each 10 ms frame and occupies the centremost six
resource blocks. Alongside this and also in the sixth subframe in the frame are the primary and
secondary synchronization signals. Reference signal position for two resource blocks within a singlesubframe are shown for both antenna ports in the 2x2 MIMO system.
The diagram also shows the space allocated for downlink control channels, which includes PDCCH,
PCFICH and PHICH resources. A UE will be required to monitor some proportion of this dependent on
the connectivity state and the cell configuration.
The remainder of the allocation space will be used for scheduled downlink transmission in the PDSCH.
This includes common control signalling (system information and paging), dedicated control signalling
and traffic packets.
Further Reading: 3GPP TS 36.211, 36.300
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 61/188
Frame
Subframe
Slot
0 1 2 DRS4 5 6 0 1 2 DRS 4 5 6
0 1 2 DRS4 5 6 0 1 2 DRS 4 5 6
0 1 2 DRS4 5 6 0 1 2 DRS 4 5 6
0 1 2 DRS4 5 6 0 1 2 DRS 4 5 6
0 1 2 DRS4 5 6 0 1 2 DRS 4 5 6
0 1 2 DRS4 5 6 0 1 2 DRS 4 5 6
0 1 2 DRS4 5 6 0 1 2 DRS 4 5 6
0 1 2 DRS4 5 6 0 1 2 DRS 4 5 6
0 1 2 DRS4 5 6 0 1 2 DRS 4 5 6
0 1 2 DRS4 5 6 0 1 2 DRS 4 5 6
0 1 2 DRS4 5 6 0 1 2 DRS 4 5 6
0 1 2 DRS4 5 6 0 1 2 DRS 4 5 6
LT3600/v3.1 2.25© Wray Castle Limited
Summary of the Uplink Structure
The diagram shows an example of a populated uplink FDD frame using the normal CP and implemented
in a 5 MHz bandwidth channel. The overall uplink frame structure is simpler than that employed by the
downlink.
Symbol 3 in each slot carries the uplink demodulation reference signal, leaving the other six symbols
available to carry traffic.
A configurable number of outer resource blocks can be set aside to carry PUCCH messages. PRACH
resources are indicated in some of the remaining resource block as indicated to the UE in system
information.
LTE OFDM Physical Layer
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 62/188
LT3600/v3.12.26 © Wray Castle Limited
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 63/188
SECTION 3
LTE HIGHER-LAYER PROTOCOLS
LTE/SAE Engineering Overview
I© Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 64/188
LTE/SAE Engineering Overview
II © Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 65/188
Layer 2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.1
MAC General Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.2
MAC Scheduling Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.3
RACH Procedure for MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.4
RNTI Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.5
Transmission Requirement Indications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.6
L2/L1 Channel Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.7
RLC General Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.8
RLC Transparent Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.9
RLC Unacknowledged Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.10
RLC Acknowledged Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.11
PDCP Functional Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.12
RRC Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.13
RRC States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.14
Signalling Radio Bearers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.15
System Information Broadcasting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.16
RRC Connection Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.17
RRC Connection Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.18
Data Radio Bearer Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.19
NAS Information Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.20
CONTENTS
LTE Higher-Layer Protocols
III© Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 66/188
LTE/SAE Engineering Overview
IV © Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 67/188
At the end of this section you will be able to:
identify the functions of the RRC protocol
define the RRC protocol connected mode and idle mode states for a UE
explain the use of signalling radio bearers for the transfer of RRC signalling
describe the procedures for the broadcasting of system information by RRC
explain the relationship between signalling radio bearers, data radio bearers and EPS bearers
describe the operation of RRC connection establishment
describe how data radio bearers and EPS bearers are established, modified or removed
explain the measurement configuration and reporting procedures
explain how RRC carries NAS signalling over the air interface
identify the three sublayers: PDCP, RLC and MAC within layer 2 for E-UTRA
explain the key functions of each sublayer within layer 2
list the logical and transport channels defined for information interchange in layers 2 and 1
explain the function and multiplexing options for logical and transport channels
describe the functional architecture of PDCP
describe the functional architecture of RLC
list and explain the three modes of operation for RLC: transparent mode, unacknowledged
mode and acknowledged mode
describe the MAC functional architecture
explain MAC functions in respect of logical channel prioritization and scheduling
explain the general operation of the random access process
describe how HARQ is implemented between the MAC layer and the physical layer
OBJECTIVES
LTE Higher-Layer Protocols
V© Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 68/188
LTE/SAE Engineering Overview
VI © Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 69/188
PDCP
PDCP SAPs
RLC SAPs
System
information Paging
RRC dedicated control andNAS direct transfer
Servicesignalling
traffic
NRT data
traffic
RT data
traffic
TM TM TM AM AM AM AM UM
SRB0 SRB1 SRB2 DRB1 DRB2 DRB3
Integrity and
ciphering
Integrity and
ciphering
ROHCROHCROHC
Ciphering Ciphering Ciphering
Control plane User plane
RLC
MAC
Logicalchannels
TransportChannels
BCCH PCCH CCCH DCCH1 DTCH1 DTCH2 DTCH3DCCH2
RLC PDU
and ARQ
RLC PDU
and ARQ
RLC PDU
and ARQRLC PDU
RLC PDU
and ARQ
Scheduling and priority handling
Physical layer
Multiplexing and HARQ control
LT3600/v3.1 3.1© Wray Castle Limited
Layer 2 Overview
There are three sublayers within the E-UTRA layer 2, PDCP, RLC and MAC (Medium Access Control).
All the sublayers, including PDCP, span both the control and user planes of the protocol stack, although
in most cases the functions provided in each plane differ.
PDCP provides SAP (Service Access Point) access to protocol functionality through SRB (Signalling
Radio Bearer) provision in the control plane and DRB (Data Radio Bearer) provision in the user plane. Atthe eNB end a set of SRBs and DRBs is created on a per-UE basis as required. For system information
and paging, PDCP has a null function. PDCP provides sequencing of higher-layer PDUs and implements
the integrity and ciphering security functions as required.
RLC provides three levels of service through three SAP types, TM (Transparent Mode), UM
(Unacknowledged Mode) and AM (Acknowledged Mode). TM is only applicable to system information
broadcasting, paging and RRC connection establishment in SRB 0. AM is used for all dedicated
signalling functions and packet traffic transfer, providing retransmission and sequencing. For real-time
traffic, when AM would not be desirable in achieving the delay requirements UM can be used for
sequencing only.
MAC SAPs are known as logical channels. The MAC layer is responsible for mapping and multiplexinglogical channels to transport channels at the physical layer. MAC also controls scheduling for resource
allocation at the physical layer as well and control for a number of physical layer processes.
Further Reading: 3GPP TS 36.300
LTE Higher-Layer Protocols
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 70/188
PCCH DTCH
BCHPCH RACHDL-SCH UL-SCH
Logical
channels
Transport
channels
Logical channel prioritization (UL only)
Multiplexing/demultiplexing
HARQRandom
access control
Control
BCCH CCCH DCCH
MAC
control
Grant and HARQ
signalling
MAC
LT3600/v3.13.2 © Wray Castle Limited
MAC General Architecture
The MAC layer is defined as part of layer 2. However, many of its functions are closely related to physical
layer behaviour, so the architecture indicated in the standards should be treated as informative.
Manufacturers are left to determine an efficient implementation for the realization of MAC and physical
layer interaction.
The MAC layer is accessed through logical channels as well as a control SAP. It maps information flowsinto the physical layer through transport channels. The mapping of logical channels to transport channels
is a key function of the MAC layer.
In addition to channel mapping, the MAC layer has important control functionality including management
of multiple HARQ processes for each information flow and the random access process.
Most significantly, the MAC layer is responsible for channel prioritization and scheduling of resources on
the physical layer.
The MAC layer has a null function for paging and for system information that will be transmitted in the
BCH (Broadcast Channel) transport channel.
Further Reading: 3GPP TS 36.321:4.2.1
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 71/188
MAC Downlink Assignment (PDCCH)
MAC Uplink Grant(PDCCH)
VoIP or otherconversational services
Bursty data
Dynamicscheduling
MAC (PDCCH)
Persistentscheduling
MAC (PDCCH)
RRC (DL-SCH)
Semi-Persistent
scheduling
Data
Data
Data
Data
Data
Data
Data
Data
Data
Data
LT3600/v3.1 3.3© Wray Castle Limited
MAC Scheduling Functions
The main function of the MAC is to manage the shared access to a common transmission medium by
multiple devices. This is achieved through the eNB’s scheduling function. Resource allocation will be
performed on the basis of a scheduling algorithm, the specifics of which are not defined by the standards.
However, channel performance, data buffer fill, UE power capability and traffic priority are likely to be
considered.
When a UE establishes an RRC relationship with an eNB it is assigned a C-RNTI (Cell Radio Network
Temporary Identifier), which will uniquely identify that UE in that cell. The C-RNTI will be used to address
any control and scheduling messages to or from the UE. Each UE is capable of establishing multiple EPS
bearers, which are the NAS traffic and signalling connections that travel from the UE to the core network.
Resource allocations are defined in terms of one or more PRB (Physical Resource Block), which will be
populated using a specified MCS (Modulation and Coding Scheme). The allocations can be made for one
or more TTI periods. LTE offers three scheduling modes. The first, known as dynamic scheduling ,
involves the use of MAC downlink assignment messages and uplink grant messages in the PDCCH to
allocate resources as required. Dynamic scheduling is intended for typical bursty packet data traffic.
For VoIP (Voice over IP) traffic where regular and reliable allocation of resources is required to meetmore demanding QoS requirements, LTE offers persistent scheduling . This is achieved through a
combination of RRC signalling in the DL-SCH (Downlink Shared Channel), for the initial specification of
the resource allocation interval, and MAC signalling in the PDCCH for more specific PRB and MCS
information. The result is a lower overhead in the PDCCH for these regular resource allocations. The
third scheduling option, known as semi-persistent scheduling , is used specifically for the purpose of
resource allocation for the establishment or reconfiguration of a persistent scheduled resource, i.e. for the
transport of RRC messages relating to the persistent scheduled resource. In this case an SPS-C-RNTI
(Semi Persistent Scheduling) will be used to address the UE, which is different from the UE’s C-RNTI.
Further Reading: 3GPP TS 36.321, 36.331
LTE Higher-Layer Protocols
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 72/188
MACEntity
MACEntity
Physicallayer
Physicallayer
RACH and preamble
instructions
L2/L3 Message
CCCH
Radio link
PRACH RACH indication
RAR (Random Access
Response)
DL-SCH
• Timing Advance
• UL Grant
• Temporary C-RNTI
RAR
DL-SCH/PDSCH
Resource allocation
for RAR
PDCCH
CRC scrambled
with RA-RNTI
MAC PDU [L2/L3 Message]
UL-SCH/PUSCH
CRI (Contention
Resolution Identity)
DL-SCH
L2/L3 Message
CCCH
Resource allocationfor CRI
PDCCH
CRI
DL-SCH/PDSCH
Contention check.
Temporary C-RNTIbecomes the allocated
C-RNTI
LT3600/v3.13.4 © Wray Castle Limited
RACH Procedure for MAC
The random access procedure is handled by the MAC and the physical layer and operates using a
combination of the PRACH on the uplink and the PDCCH on the downlink. UEs are informed of the range
of random access preambles available in system information, as are the contention management
parameters. When a random access event is required, the UE will perform the following functions:
review and randomly select a preamble
check the BCCH for the current PRACH configuration; this will indicate the location and periodicity
of PRACH resources in uplink subframes
calculate open loop power control parameters – initial transmit power, maximum transmit power
and power step
discover contention management parameters
Once the UE transmits an initial preamble it will wait a specified period of time for a response before
backing off and retrying. Open loop power control ensures that each successive retry will be at a higher
power level.
Upon receipt of a successful uplink PRACH preamble, the eNB will calculate power adjustment andtiming advance parameters for the UE based on the strength and delay of the received signal and
schedule an uplink capacity grant to enable the UE to send further details of its request. This will take the
form of the initial layer 3 message. If necessary, the eNB will also assign a Temporary C-RNTI for the UE
to use for ongoing communication.
Once received, the eNB reflects the initial layer 3 message back to the UE in a subsequent downlink
scheduled resource to enable unambiguous contention resolution. After this point further resource
allocations may be required for signalling or traffic exchange and these will be addressed to the
C-RNTI.
Further Reading: 3GPP TS 36.321:5.1, 36.213:6
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 73/188
Note: RNTI values falling in the RA-RNTI number range corresponding to a cell’s PRACH configuration
cannot be reused for other RNTI types.
RNTI Usage Logical channel Transport channel Value range
RA-RNTI MAC random access response --- DL-SCH 0001–003C
Contention resolution when
no C-RNTI is availableCCCH DL-SCH 0001–FFF3
Initial L3 message transmission CCCH/DCCH/DTCH UL-SCH 0001–FFF3
Dynamically scheduled unicasttransmission
DCCH/DTCH UL-SCH/DL-SCH 0001–FFF3
Triggering of PDCCH ordered
random access--- --- 0001–FFF3
Semi-persistent scheduled
unicast transmissionDCCH/DTCH UL-SCH/DL-SCH 0001–FFF3
Deactivation of semi-persistent
scheduled unicast transmission --- --- 0001–FFF3
SI-RNTI Broadcast of system information BCCH DL-SCH FFFF
P-RNTIPaging and system information
change notificationPCCH PCH FFFE
TPC-PUCCH-RNTI Uplink power control --- --- 0001–FFF3
TPC-PUSCH-RNTI Uplink power control --- --- 0001–FFF3
Temporary
C-RNTI
C-RNTI
Semi-Persistent
Scheduling
C-RNTI
LT3600/v3.1 3.5© Wray Castle Limited
RNTI Types
The table summarizes the RNTI types defined for E-UTRA. In all cases they have a length of 2 octets
and for some RNTI types there is a limited number range or specific reserved values. Outside of these
reserved values there is no structure to the RNTI.
A SPS-C-RNTI is allocated to a UE when Semi-Persistent scheduling is used and indicates resources for
higher-layer signalling that relates the UE's current persistently scheduled resource. The range of potential values will therefore be dependent on the PRACH configuration used in a cell. Any number in
this range cannot be allocated for use as any other RNTI type.
An Temporary C-RNTI is allocated to a UE on initial access as part of the random access procedure. On
successful completion of the random access procedure the Temporary C-RNTI becomes the
C-RNTI. This is cell specific and is the main identity for the UE within the cell.
A SPS-C-RNTI is allocated to a UE when persistent scheduling is used and indicates resources for
higher-layer signalling that relates the UE’s current persistently scheduled resource.
The fixed SI-RNTI (System Information RNTI) and P-RNTI (Paging RNTI) are used to indicate the
allocation of resources in the PDSCH containing system information or paging respectively.
TPC-PUCCH-RNTI (Transmit Power Control PUCCH RNTI) and TPC-PUSCH-RNTI are used to indicate
power control information for the PUCCH and PUSCH respectively.
Further Reading: 3GPP TS 36.321:7.1
LTE Higher-Layer Protocols
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 74/188
Logical channels
eNB
Scheduling
Multiplexing andprioritization
LT3600/v3.13.6 © Wray Castle Limited
Transmission Requirement Indications
The UE will neither receive nor transmit information unless it is scheduled to do so because there is no
dedicated radio resource in E-UTRA. Therefore, for every signalling message or data packet some
signalling activity must be performed and this must be preceded by a resource request.
Downlink resource allocation is triggered by need in the eNB. All resource allocations are indicated in the
PDCCH.
For uplink transmission the UE must first indicate its need to the eNB. There are a number of
mechanisms that can result in a scheduled resource being indicated for a UE in the PDCCH. For initial
access, or where the UE has not been active for some time, the random access procedure can be used
for resource requests. When a mobile is continuously active it may be allocated a resource in the
PUCCH to use for resource requests needed for further data or signalling transfer. Additionally, the eNB
can request buffer status reports from UE that are currently active. Based on this information the eNB
makes scheduling decisions.
In the uplink direction it is the MAC layer within the UE that determines how an allocated transmission
resource should be demarcated between a number of different logical channels. This is based on
channel priority and channel PBR (Prioritized Bit Rate).
Further Reading: 3GPP TS 36.321, 36.331
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 75/188
RRC
PDCP
RLC
MAC
Physical layer
BCCH PCCH CCCH DCCH DTCH
BCH PCH RACH DL-SCH UL-SCH
PBCH PRACH PDSCH PUSCH
Logical
channels
Transport
channels
Physicalchannels
LT3600/v3.1 3.7© Wray Castle Limited
L2/L1 Channel Mapping
Logical channels are mapped by the MAC layer to transport channels on entry to the physical layer, and
then ultimately to physical channels within the physical layer.
The BCCH is used for system information broadcasting and carries three RRC message types. The
MasterInformationBlock message is mapped to the BCH transport channel and then to the PBCH. All
other system information messages are mapped to the DL-SCH and PDSCH.
The PCCH (Paging Control Channel) carries paging messages and is mapped to the PCH (Paging
Channel) and PDSCH.
The CCCH (Common Control Channel), DCCH (Dedicated Control Channel) and DTCH (Dedicated
Traffic Channel) are all bidirectional channels and will be mapped to the DL-SCH and PDSCH for
downlink flows and UL-SCH (Uplink Shared Channel) and PUSCH for uplink flows.
The PRACH and RACH are used only in the uplink for initiating RRC connectivity. The random access
process involves an interaction at the physical layer under the control of MAC. There is no higher layer
information in the random access channels but the process will result in the allocation of resources for
higher-layer message exchange.
Further Reading: 3GPP TS 36.300, 36.212, 36.321
LTE Higher-Layer Protocols
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 76/188
RLC
Transmit
transparent
mode entity
Transmit
unacknowledged
mode entity
Receive
transparent
mode entity
Receive
unacknowledged
mode entity
Acknowledged
mode entity
Transmit side Receive side
Logical channels in MAC
LT3600/v3.13.8 © Wray Castle Limited
RLC General Functions
RLC provides three levels of service: acknowledged mode, unacknowledged mode and transparent
mode. Radio bearers are mapped through RLC to logical channels and an RLC entity is created for each
active radio bearer.
For the transparent mode and the unacknowledged mode RLC entities are configured as either
transmitting or receiving entities. For acknowledged mode a single entity provides both transmit andreceive functionality for one side of the link. This configuration facilitates retransmission of failed RLC
PDUs.
Further Reading: 3GPP TS 36.322:4.2.1
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 77/188
Transmitting
TM-RLC entity
PDCP PDUs
TM-SAP
PDCP PDUs
BCCH/PCCH/CCCH BCCH/PCCH/CCCH
RLC SDUs
RLC PDUs
Transmission
buffer
TM-SAP
TM-RLC entity
Receiving
LT3600/v3.1 3.9© Wray Castle Limited
RLC Transparent Mode
The transparent mode has no functions, only providing a buffer for higher-layer packets that are to be
transmitted over the air interface. Transparent mode entities are accessed via a TM-SAP.
The application of transparent mode is limited to the downlink transmission of system information and
paging messages as well as the exchange of RRC connection establishment messages associated with
the CCCH (Broadcast Control Channel).
Further Reading: 3GPP TS 36.322:4.2.1.1
LTE Higher-Layer Protocols
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 78/188
Transmitting
UM-RLC entity
PDCP PDUs
UM-SAP
PDCP PDUs
DTCH DTCH
RLC SDUs
RLC PDUs
Transmission
buffer
UM-SAP
UM-RLC entity
Receiving
Segmentationand
concatenation
Add RLCheader
SDU
reassembly
Remove RLCheader
Reception bufferand HARQreordering
SDU SDU SDU
H H
LT3600/v3.13.10 © Wray Castle Limited
RLC Unacknowledged Mode
Unacknowledged mode entities are accessed through a UM-SAP. Unacknowledged mode reorganizes
RLC SDUs into a size requested by the MAC layer. Unacknowledged mode also provides sequence
numbering for in-order delivery to higher layers at the receiving end. Reordering in the RLC layer is used
in support of the HARQ functions provided by the MAC layer.
Reorganization of RLC SDUs is provided by the segmentation and concatenation function. As shown inthe diagram, higher-layer SDUs can be fragmented and reassembled into the RLC PDU payload area to
produce a packet size suitable for scheduling by the MAC layer for transmission over the air interface.
The RLC header enables the receiving entity to reassemble the higher-layer SDU in the correct order.
The application of unacknowledged mode is limited to the user plane, where it would be utilized for
packet traffic flows with low tolerance to delay. The most common example would be VoIP connections.
Further Reading: 3GPP TS 36.322:4.2.1.2
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 79/188
Transmission
buffer
DCCH/DTCH
RLC SDUs
RLC PDUs
Segmentation
and
concatenation
Add RLC
header
RLC Control
Retransmission
buffer
SDU
reassembly
Reception buffer
and HARQ
reordering
Remove RLC
header
Routing
DCCH/DTCH
PDCP PDUs
RLC SDUs
RLC PDUs
Transmitting
part of the
AM-RLC entity
Receiving
part of the
AM-RLC entity
AM-SAP
LT3600/v3.1 3.11© Wray Castle Limited
RLC Acknowledged Mode
The acknowledged mode of RLC is applicable in the control plane for RRC signalling messages carried
in DCCH and for user plane traffic carried in DTCH. Acknowledged mode entities are accessed through
an AM-SAP.
General transmission and reception functionality in terms of segmentation, concatenation, buffering and
HARQ reordering for AM mode are similar to those for UM mode. However, AM mode also providesretransmission of failed RLC PDUs. In this respect a number of enhancements in functional architecture
are provided. Firstly, a single entity for transmission and reception is required for interaction between the
transmitting and receiving side. Secondly a retransmission buffer is required in the transmit side. All
transmitted RLC PDUs are retained in the transmission buffer until acknowledgement is received.
Additionally, control (status) PDUs are required in addition to data PDUs in order to manage the
retransmission process. These must be multiplexed with data PDUs at the transmission end and
demultiplexed (routed) from data PDUs at the reception end.
Further Reading: 3GPP TS 36.322:4.2.1.3
LTE Higher-Layer Protocols
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 80/188
PDCP
PDCP
entity
PDCP
entity
PDCP
entity
RLC
UM-SAP UM-SAP AM-SAP
PDCP-SAP PDCP-SAP
Radio bearers
(SRB/DRB)
PDCP-SAP
Integrity protection
Ciphering
Add PDCP header
Sequence numbering
Header compression
Packets
from RBs
PDCP
control
packets
(U-plane only)
(C-plane only)
LT3600/v3.13.12 © Wray Castle Limited
PDCP Functional Architecture
A PDCP ent ity is created for each SRB and/or DRB on a per-UE bas is. All PDCP ent it ies are
bidirectional, thus when the AM mode of RLC is being used there is a one-to-one mapping between a
PDCP entity and AM SAP in RLC. However, for the UM mode of RLC one PDCP entity will be associated
with two UM SAPs, one configured for transmit functions and the other configured for receive functions.
Within a PDCP entity sequence numbering is applied for higher layer PDUs. This ensures in-order delivery at the receiving end. In the user plane PDCP control PDUs can be used to indicate missing
PDUs.
In the user plane, only IETF-defined ROHC (Robust Header Compression) is provided. Support for this is
only mandatory for UEs that have VoIP (Voice over IP) capability.
In the control plane, integrity protection is provided for RRC signalling messages.
Ciphering is then applied in both control and user planes, although separate cipher keys are applied for a
given UE in the two planes.
Further Reading: 3GPP TS 36.323:4.2.2
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 81/188
RRC
System information broadcasting
Paging
Connection management
Temporary identity management
Handover management
QoS management
NAS signalling direct transfer
DataTraffic
AS(Access Stratum)
NAS NASDataTraffic
AS(Access Stratum)
UE eNB EPC
RRC
EMM ECM
L1
L2
L1
L2
RRC
EMM ECM
LT3600/v3.1 3.13© Wray Castle Limited
RRC Functions
As with other E-UTRA protocols, the RRC layer, which previously resided in the RNC, has been relocated
to the eNB. In addition, the functionality and complexity of RRC has been significantly reduced relative to
that in UMTS. The main RRC functions for LTE include creation of BCH system information; creation and
management of the PCH (Paging Channel); RRC connection management between eNB and UEs,
including generating temporary identifiers such as the C-RNTI; mobility-related functions such as
measurement reporting, inter-cell handover and inter-eNB UE context handover; QoS management; anddirect transfer of messages from the NAS to the UE.
The RRC is in overall control of radio resources in each cell and is responsible for collating and managing
all relevant information related to the active UEs in its area.
System information provides the main means of advertising the services available in a cell and the means
by which those services can be accessed. For E-UTRA the BCH carries only basic information and acts
as a pointer for broader system information related to the NAS, such as PLMN (Public Land Mobile
Network) identity (network code and country code) and AS (Access Stratum) details such as cell ID and
tracking area identity; all of which is carried in the downlink dynamically scheduled resource (DL-SCH).
E-UTRA has been designed with network sharing in mind and system information can carry details of upto six sharing PLMNs.
Each eNB is responsible for managing inter-cell handovers between all the cells it controls. When
handover to another cell site is required the eNB will pass details of the current UE context to its
neighbour. This includes details of identities used, historical measurements taken and active EPS
bearers.
Further Reading: 3GPP TS 36.300, 36.331
LTE Higher-Layer Protocols
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 82/188
RRC CONNECTED
RRC IDLE
UE has an E-UTRAN RRC connection
eNB stores an RRC context
E-UTRAN knows which cell the UE is in
EPS can transmit and/or receive data to/from the UE
Neighbour cell measurements and reporting
Network-controlled mobility
Monitors BCH system information
Monitors paging channel
Performs cell reselection Assigned TAID by MME
Performs tracking area updates
No stored RRC context in the eNB
LT3600/v3.13.14 © Wray Castle Limited
RRC States
The RRC idle state refers to terminals that are powered on and have performed network access, but are
currently not supporting any active connections. RRC idle terminals will monitor the paging channel in the
camped-on cell and will perform cell reselection as required. Idle UEs have no RRC context with any
eNB and therefore have no C-RNTI assigned. The only transitory identity they have will be the TMSI
(Temporary Mobile Subscriber Identity) used for paging purposes by the MME.
A connected UE will have an active RRC context in place with an eNB. Its location will therefore be
known down to the serving-cell level and it will have a C-RNTI assigned.
As part of the RRC context establishment process the eNB will have contacted the HSS (via the MME)
and received security and authentication vectors for the UE. Ciphering and integrity keys will therefore
also be in place. RRC connected does not necessarily imply that the UE has any active EPS bearers,
only that it has made contact with an eNB.
Further Reading: 3GPP TS 36.300, 36.331
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 83/188
RRCSystem
Information
and paging
RRC
Connection
establishment
RRC
dedicated
control
NAS
direct
transfer
NAS
Layer 2
Logical Channels
Traffic data including
service related signalling
(e.g. IMS signalling)
Control Plane User Plane
SRB 0 SRB 1 SRB 2 DRB 0 DRB 1 DRB n
BCCH/PCCH CCCH DCCH DCCHDTCHs
LT3600/v3.1 3.15© Wray Castle Limited
Signalling Radio Bearers
RRC exists only in the control plane of the air interface AS protocol stack. RRC receives information from
functional entities in the NAS (Non Access Stratum) in the form of complete messages for direct transfer,
and also in the form of requests, information elements and parameters that will trigger RRC activity and
be used in RRC messages.
For broadcast functions over the air interface RRC messages are mapped directly to logical channels.This includes paging and system information broadcasting using the PCCH and BCCH logical channels
respectively.
For dedicated signalling functions between a UE and an eNB signalling flows are mapped into an SRB.
When a UE transitions to the RRC connected state a set of SRB instances is created. SRB 0 is used only
for the initial establishment of the RRC connection and is mapped to the CCCH. Once the RRC
connection is established the UE will be issued with a C-RNTI and SRB 1 and optionally SRB 2 will be
created. SRB 1 is used for all RRC specific signalling functions. SRB 2 is used for RRC direct transfer of
NAS signalling messages. However, NAS messages may also be piggybacked with RRC signalling in
SRB 1. Both SRB 1 and SRB 2 are mapped to DCCH logical channels.
If required, one or more DRB may be created during or subsequent to an RRC connection establishment.These exist in the user plane and carry traffic. However, ‘traffic’ in this context includes service-related
signalling between service applications in higher layers, for example VoIP connection establishment
using the IMS. DRBs are mapped to DTCH logical channels.
Further Reading: 3GPP TS 36.331:4.2.2
LTE Higher-Layer Protocols
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 84/188
MIB
BCCH
BCH
SIB 2-11
DL-SCH
SystemInformation message
Essential and
basic frequently
transmitted
parameters
All other parameters
with flexible scheduling
indicated in SIB 1
MasterInformationBlock
(40 ms periodicity)
SystemInformationBlockType1
(80 ms periodicity)
SystemInformation (Other SIBs)
eNB
SIB 1
IE
LT3600/v3.13.16 © Wray Castle Limited
System Information Broadcasting
A ‘bootstrap’ approach is adopted for system information broadcasting on the E-UTRA air interface. The
physical layer is primarily a dynamically scheduled resource with very little permanently defined capacity.
Therefore, although a BCH transport channel and corresponding physical layer resource exist, this is
only used to carry the MIB (Master Information Block). The position of the MIB can be determined by the
UE as it performs initial synchronization with the cell.
The MIB contains only basic information enabling the UE to find and read the RRC message
SystemInformatioBlockType1. This message in turn provides the scheduling information for the RRC
SystemInformation messages being transmitted on the cell. SystemInformation messages contain one or
more information elements, each of which will be a SIB (System Information Block). It is the SIBs that
provide the complete set of system information for a UE. The operator determines which SIBs are
transmitted, and how frequently, dependent on configurations, capabilities and services supported.
Further Reading: 3GPP TS 36.331:5.2
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 85/188
Serviceapplication
Serviceapplication
External PDN
S1-APconnection
EPS bearer
RRCconnection
PDN-GW
S1-APRRC
NAS
MME
eNB
Traffic
S1-APRRC
NAS
Traffic
DRBs
SRBs
NAS
LT3600/v3.1 3.17© Wray Castle Limited
RRC Connection Structure
The overall function of RRC is to create, maintain and clear DRBs as required to provide the radio link
segment of one or more EPS bearer relating to one or more EPS connectivity service. RRC receives
instructions on what EPS bearers are required from the NAS. The NAS activity in turn is driven by
instructions from service applications (via the PCRF on the EPC side).
In order to manage DRBs, RRC must exchange signalling with its peer entity and provide direct transfer for NAS signalling exchange. Connectivity for this comes from SRBs. However, signalling relating to
service applications, which are always external to the LTE/EPS, are treated as traffic flows and as such
are carried in DRBs within an EPS bearer. Note that an EPS bearer has only one set of associated QoS
characteristics, so if application signalling were to require different QoS treatment to the traffic that it
facilitates then a second EPS bearer would have to be defined. Multiple EPS bearers may or may not be
part of the same EPS connectivity service dependent on their respective connectivity requirements.
Further Reading: 3GPP TS 36.300, 36.331
LTE Higher-Layer Protocols
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 86/188
eNB
UE Initial Identity (S-TMSI or 40-bit random value)
cause value (Emergency, high-priority access, MO
signalling, MO data, MT access)RRCConnectionRequest
CCCH/UL-SCH
(RACH/C-RNTI established)SRB 0
RRCConnectionSetup
CCCH/DL-SCH
RRC Transaction Identifier
dedicated radio resource configuration for SRB 1
SRB 1RRCConnectionSetupComplete
DCCH/UL-SCH
RRC Transaction Identifier
selected PLMN
registered MME (if applicable)
NAS signalling message
LT3600/v3.13.18 © Wray Castle Limited
RRC Connection Establishment
The RRC connection establishment procedure is always initiated from the UE. It begins with the
transmission of the RRCConnectionRequest message containing an identity and a cause value. If the UE
has already registered with the network then it will use the S-TMSI (SAE-TMSI) as its identity. If this is a
new mobile needing to perform an initial registration then it will generate and use a 40-bit random value.
The message is carried in the CCCH/UL-SCH channel combination. This requires a scheduled resource
allocation, which is secured using the lower-layer random access procedure and the RACH. The lower-layer random access procedure also facilitates the allocation of a C-RNTI at this stage.
The eNB responds with an RRCConnectionSetup message containing a transaction identifier, used to
relate future messages as part of this signalling sequence, and the radio resource configuration for SRB
1. Note that the exchange of the two messages to this point has involved the use of the implicitly
configured SRB 0.
The final part of this three-way handshake is the confirmation from the UE in the form of the
RRCConnectionSetupComplete message now using the defined SRB 1 and DCCH/UL-SCH
combination. For registered UEs this message contains identities of the PLMN and MME with which it is
registered. In any case the message will also piggyback the initial NAS message that triggered the RRC
establishment procedure, for example, a service request or registration message.
Further Reading: 3GPP TS 36.331:5.3.3, TS36.321:5.1
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 87/188
eNB
RRCConnectionReconfiguration
DCCH/DL-SCH
RRCConnectionReconfigurationComplete
DCCH/UL-SCHSRB 1
SRB 1
Information Element Comment
Measurement
configuration
Intra- and inter-frequency as
well as IRAT
Mobility control
information
Target cell configuration and
H/O parameters
NAS message(s) E.g. relating to an NAS
procedure that requires DRB
Dedicated radio resource
configuration
SRB or DRB add, modify or
remove
H/O security information Information regarding security
keys to be used after H/O
Future extension
LT3600/v3.1 3.19© Wray Castle Limited
Data Radio Bearer Establishment
A default EPS bearer and corresponding DRBs will be established as part of the RRC connection
establishment procedure. For some services this may be sufficient, but if new services, or different levels
of QoS, are subsequently required then new DRBs and/or new EPS bearers may be needed to support
them. Additionally, existing DRBs may require reconfiguration because of service change or addition, or
because a handover is required. All of these things can be performed using the
RRCConnectionReconfiguration message. In this respect the RRC message contains details of anySRBs or DRBs that are to be added, modified or removed.
The RRCConnectionReconfiguration message is also a key part of the RRC handover control,
procedures. It is used as an intra-E-UTRA handover command and it is used to configure the
measurement processes used by active RRC connected UEs.
Further Reading: 3GPP TS 36.331:5.3.5, 6.2.2
LTE Higher-Layer Protocols
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 88/188
eNB
DLInformationTransfer [NAS message]
DCCH/DL-SCH
ULInformationTransfer [NAS message]
DCCH/UL-SCH SRB 2
SRB 2
NAS
MME
RRCRRC
NAS
LT3600/v3.13.20 © Wray Castle Limited
NAS Information Transfer
RRC provides tunnelled transport for NAS signalling or non-3GPP dedicated information enabling the UE
to communicate with the MME. This is primarily done using DL/ULInformationTransfer messages, which
are carried in SRB 2. Generally these messages have a lower priority than RRC messages in SRB 1.
However, in some cases NAS signalling can be piggybacked as an information element in RRC
signalling messages in SRB 1.
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 89/188
SECTION 4
MAJOR PROTOCOLS
LTE/SAE Engineering Overview
I© Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 90/188
LTE/SAE Engineering Overview
II © Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 91/188
EPS Major Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.1
IETF Dependence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.2
IP in the EPS/IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.3
3GPP Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.4
Legacy GTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.5
GTP in the EPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.6
S1AP (S1 Application Protocol) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.7
S1AP and SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.8
X2AP (X2 Application Protocol) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.9
X2AP and SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.10
CONTENTS
Major Protocols
III© Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 92/188
LTE/SAE Engineering Overview
IV © Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 93/188
At the end of this section you will be able to:
discuss the derivation of the major protocols employed by the EPC and highlight the
organizations responsible for specifying them
list the set of major protocols defined by the IETF
outline the support the EPC provides for deployment of different versions of IP
describe the IP mobility concept and provide an outline of the functions of MIP, PMIP and DSMIP
discuss the transport layer protocols that are available for use in the EPC
describe the specific features of SCTP that make it suitable for transporting signalling flows over
the EPC
outline the basic concepts employed by SCTP
discuss the role of SIP within the EPC and IMS and the supplementary functions performed by
SDP and RTP
describe the functions performed by DiffServ within the EPC
outline the role of the Diameter protocol and discuss its use within the EPC
list the set of 3GPP-specific protocols developed or adapted for use in the EPC
describe the role performed by GTP in legacy 3GPP networks and highlight the differences
between those versions and GTPv1-U and GTPv2-C
outline the functions performed by the S1 Application Protocol and the X2 Application Protocol
describe the message types and formats employed by the S1 and X2 protocols
OBJECTIVES
Major Protocols
V© Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 94/188
LTE/SAE Engineering Overview
VI © Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 95/188
EPS
IETF 3GPP
LT3600/v3.1 4.1© Wray Castle Limited
EPS Major Protocols
The Evolved Packet System is designed to be an 'all-IP' environment. This means that all protocols,
whatever their function, will travel between network nodes via an IP transport network.
IP is an open standards Network Layer/Layer 3 packet delivery system specified by the loose
community of IT academics and professionals that comprise the IETF.
IETF specifications exist in the form of RFCs (Requests For Comment), which are freely available for
download and comment from their website – www.ietf.org.
Most major protocols employed within the EPS were developed by the IETF, which means that the EPS
can be regarded as a (mostly) open-standards networking environment.
Where relevant IETF-based specifications do not exist or where a legacy protocol can be employed,
3GPP has developed protocols or reused protocols of its own. These protocols are mainly related to
inter-node signalling functions and are either evolutions or combinations of existing 3GPP systems.
Further Reading: 3GPP TS 23.401, 36.300; www.ietf.org
Major Protocols
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 96/188
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 97/188
IPv6 EPS
IPv4 EPS
IPv4 Internet
Access Network
LT3600/v3.1 4.3© Wray Castle Limited
IP in the EPS/IMS
IP is the only packet transport mechanism employed by the EPS transport network. It does not support
the layer 2 transmission protocols employed in legacy systems such as TDM (Time Division Multiplexing)
and ATM (Asynchronous Transfer Mode).
An IP 'cloud' provides logical and physical interconnections between EPS network nodes. The design of
the cloud is intended to ensure that redundant paths exist between all nodes to allow the network tooperate in a resilient and fault-tolerant manner.
Equipment vendors and network operators have the option of deploying systems that support IPv4 (IP
version 4) or IPv6 (IP version 6) or a combination of both (functionality which is referred to by EPS nodes
as 'IPv4v6').
Compared to legacy IPv4, which has been in use since the early 1980s, IPv6 has a flatter protocol
structure – with many functions that required additional protocols in IPv4 being performed within the IP
layer itself in IPv6.
These additional features include functions such as dynamic IP address allocation, which required an
additional protocol such as DHCP (the Dynamic Host Configuration Protocol) in IPv4, but is managedautomatically (by means of router prefixes and host link local addresses) in IPv6. Support for security
mechanisms such as IPsec (IP security) are also incorporated into the IP layer in IPv6.
IPv6 is a backwards-compatible system, however, so network operators have the opportunity interface a
new IPv6-based EPS with existing IPv4-based legacy packet core networks.
Further Reading: IETF RFCs at www.ietf.org
Major Protocols
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 98/188
3GPP
GTPv2 X2AP
S1AP
LT3600/v3.14.4 © Wray Castle Limited
3GPP Protocols
The Evolved Packet Core employs a number of protocols designed by 3GPP and ETSI (European
Telecommunications Standards Institute). These include GTP (the GPRS Tunnelling Protocol), S1AP (S1
Application Protocol) and X2AP (X2 Application Protocol).
Further Reading: 3GPP TS 29.274 (GTPv2-C), 36.41x (S1), 36.42x (X2)
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 99/188
SGSNs
GGSN
2G PS core
GTPv0 Tunnels
R97
User trafficflow
RNC
3G PS core
GGSN
User trafficflow
GTPv1 TunnelsGTP-C and GTP-U
tunnels
R99
GTP-U direct tunnel
LT3600/v3.1 4.5© Wray Castle Limited
Legacy GTP
GTP was originally designed as part of the 2.5G GPRS packet core network and was employed to route
encapsulated traffic packets between GPRS Support Nodes (SGSNs and GGSNs).
The initial 2.5G version of GTP became known as GTPv0.
As it matured, a number of basic problems were discovered. Chief amongst these was the fact that GTPv0placed tunnel control and administrative information in fields in the headers of packets that also
encapsulated user data. This meant packets that carried user data but no control information had a greater
amount of header overhead than necessary, leading to a potentially inefficient service.
GTPv1 was developed to offer an evolved service to 3G packet core networks. The most obvious
difference with GTPv0 was the extension of the service beyond the SGSN and down to the RNC.
Another major difference was the separation of the protocol into parts that dealt with control plane (GTP-C)
and user plane (GTP-U) traffic. GTP-U packet headers could therefore be smaller and offer a more
efficient service, as all control data was carried in its own logical stream.
Further Reading: 3GPP TS 23.060
Major Protocols
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 100/188
GTP-U
X2
S1-U
S4
S12
GTP-U and GTP-C
S5 S8
Iu
GTP-U and RANAP
GTP-C
S3
S11
S10
PDN-GWS-GW
MMEMME
RoamingEPS
SGSN
RNC
LT3600/v3.14.6 © Wray Castle Limited
GTP in the EPS
GTPv2 (GTP version 2) was developed to allow the control of the tunnelling service offered by the
protocol to adapt to the specific needs of the EPS environment.
C-plane functions on GTP-based interfaces are handled by GTPv2-C, while U-plane traffic tunnelling
continues to be handled by GTPv1, now known as GTPv1-U.
In v1, GTP-C was used to carry tunnel creation and management messages between the GSNs and
between the RNC and SGSN.
To reflect the separation of bearer management and routing functions into the MME and S-GW
respectively, in GTPv2-C the protocol is also used to carry bearer creation and management directives
over the S11 interface between those nodes.
The main functional evolution that GTPv2-C needs to support is the creation of default and dedicated
EPS bearers on the S5 and S8 interfaces between S-GW and PDN-GW.
GTPv2-C is also employed on the S3 interface that connects the MME to legacy SGSNs and on the S10
interface that interconnects MMEs. SGSNs that support the S4 interface to the EPC may also beupgraded to support the S16 interface in place of the legacy Gn; the S16 is also based on GTPv2-C.
GTP-C is not employed on the S1-MME and X2 interfaces, where bearer creation and management is
instead handled by interface specific Application Protocols (S1AP and X2AP), although GTPv2-C does
carry instructions to the S-GW regarding the establishment of GTP tunnels that will then run over the S1-
U interface.
GTPv1-U is employed to encapsulate and route user plane traffic on all traffic-carrying interfaces,
including S1, X2, S4, S5, S8, S12 and S16.
Further Reading: 3GPP TS 23.401, 29.274 (GTPv2-C); 29.281 (GTPv1-U)
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 101/188
S1-MME
MME
eNB
IP
L2
S1–AP
SCTP
L1
E-RAB management
Initial context transfer
UE context management
Additional E-RAB creation
Mobility functions
Paging
Direct transfer of NAS signalling
LT3600/v3.1 4.7© Wray Castle Limited
S1AP (S1 Application Protocol)
S1AP is designed to provide a control plane connection on the S1-MME interface between an eNB and
an associated MME.
The S1-flex concept means that each base station may be associated with multiple MMEs, which in turn
means that each eNB could host multiple instances of the S1AP.
S1AP is responsible for E-RAB (E-UTRAN Radio Access Bearer) management i.e. setting up, modifying
and releasing bearers under instruction from an MME. It also performs initial context transfer to establish
an S1UE context in the eNB on initial attach including collating details of the UE's capabilities and the
creation of a default bearer. It undertakes UE context management; transferring UE context data
between eNBs and MMEs in the event of handovers or relocations.
S1AP is also responsible for the creation of additional E-RABs (for carrying further Default or Dedicated
EPS Bearers) and for mobility functions for UEs in ECM-Connected state. It also performs paging and
the Direct Transfer of NAS signalling between the UE and the MME.
S1AP takes the place of GTP-C on the S1 interface, carrying bearer-specific control information between
the MME and the eNB, including details such as TEIDs and UE S1 identities.
S1AP is also responsible for carrying the messaging that enables the E-RAB 'path switch' function to
take place after an inter-eNB handover. Additionally, it provides support for MME relocation and S-GW
change functions.
S1AP is an evolution of the RANAP protocol employed in 3G networks.
Further Reading: 3GPP TS 36.41x series, 36.413 (S1AP)
Major Protocols
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 102/188
S1 -MME
MME Pool
eNB
MME
S1 over SCTP Association
eNB and MME act asSCTP endpoints
MME
MME
MME
LT3600/v3.14.8 © Wray Castle Limited
S1AP and SCTP
S1AP connections are logical and are designed to operate over SCTP/IP links to multiple MMEs.
The redundancy and resilience built into the 'S1 Flex' concept should ensure that the administrative load
(and therefore also the risk) associated with the UEs served by one eNB is shared evenly between a
group of MMEs.
Each S1-MME interface is carried by an SCTP Association established between an eNB and an MME.
One or more streams may then be established to carry S1AP message flows.
Further Reading: 3GPP TS 36.413; 23.401
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 103/188
IP
SCTP
X2-CP (Control Plane)
Data link layer
X2-AP
Physical layer X2
X2AP
LT3600/v3.1 4.9© Wray Castle Limited
X2AP (X2 Application Protocol)
The X2 interface is used to forward buffered traffic between eNBs during handovers and to provide a
service management message path between neighbouring base stations.
The X2 interface is optional but recommended as it has the potential to reduce significantly the amount of
S1 signalling and handover traffic that the MMEs and S-GWs in a network are required to support.
The X2 interface can be viewed as being broadly analogous in function to the Iur interface employed
between 3G RNCs, although with no requirement to support macro diversity functions the scope of the
X2 interface is greatly reduced. X2AP can therefore be viewed as analogous to the RNSAP signalling
protocol employed on the Iur.
Further Reading: 3GPP TS 36.423 and 36.42x series in general
Major Protocols
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 104/188
X2 interfaces are only
required between eNBs
that are likely to be
required to hand traffic
over between the cells
they control.
X2
eNB A
E-UTRAN
IP transport
X2
eNB Z
X2 over SCTP
Association
Neighbouring eNBs act as
SCTP endpoints
X2
LT3600/v3.14.10 © Wray Castle Limited
X2AP and SCTP
X2AP connections can be logical (in which case they exist as routes travelling through the E-UTRAN IP
transport network) or physical (carried between eNBs by a dedicated link or virtual path) and are
designed to operate over SCTP/IP links between neighbouring eNBs.
The X2 interface is optional but recommended.
An X2 interface is only required between eNBs if there is a chance of handover traffic passing between
the cells that they control; if eNB 'A' does not have an adjacency formed with eNB 'Z' there is no
requirement for an X2 to exist between them.
Each X2 interface is carried by an SCTP association established between eNBs. One or more streams
may then be established to carry X2AP message flows.
Further Reading: 3GPP TS 36.423; 23.401
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 105/188
SECTION 5
EVOLVED PACKET CORE
LTE/SAE Engineering Overview
I© Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 106/188
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 107/188
EPS Network Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.1
Network Logical Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.2
MME (Mobility Management Entity) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.3
S-GW (Serving Gateway) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.4
PDN-GW (Packet Data Network Gateway) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.5
PCRF (Policy and Charging Rules Function) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.6
Combined Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.7
Resilience Through Pooling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.8
UE State Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.9EMM States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.10
ECM (EPS Connection Management) States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.11
Interface Naming Convention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.12
S1 to E-UTRAN Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.13
S1-U . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.14
S1-Flex Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.15
S1 Interfaces for Home eNBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.16
S1AP Functions and Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.17
GTPv1-U Traffic Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.18
GTPv2-C C-plane Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.19
Diameter-based Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.20
PCRF Diameter Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.21
Interface to CS Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.22
Connection Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.23
Transport Identities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.24
Default and Dedicated EPS Bearers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.25
EPS Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.26
QoS Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.27
Active EPS Bearers and Bearer Contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.28
Inactive EPS Bearers and Bearer Contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.29
Providing CS Services via LTE/EPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.30
CS Fallback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.31
VCC (Voice Call Continuity) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.32
CS Service Provision via a GANC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.33
EPC Security Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.34
AKA (Authentication and Key Agreement) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.35
User Confidentiality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.36
CONTENTS
Evolved Packet Core
III© Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 108/188
LTE/SAE Engineering Overview
IV © Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 109/188
At the end of this section you will be able to:
outline the functions performed by EPC elements
discuss options for interworking the EPC with legacy packet core networks
describe the main points of interest related to EPC topics such as pooling
list the set of S interfaces described for the EPC and outline their basic functions and protocols
discuss options for User Plane connectivity between a UE and a PDN-GW
outline how combinations of redundant S interfaces can provide for EPC resilience
list the basic set of identifiers used to describe EPC areas
outline the set of node identifiers that have been defined for the EPC
discuss the impact of the evolved device/subscriber identifiers employed by the EPC
outline the fundamental properties of an EPS Bearer and describe the structure of an EPS Bearer ID
describe the relationship that exists between an EPS Bearer and an E-RAB
outline the role of the APN (Access Point Name) in the handling of a PCS
describe the interaction between the EPC and the GTP
outline the interaction between the EPC, GTP and IP
discuss the concept of the PCS and its relevance within the EPC
outline the functions of the default EPS Bearer
describe the differences between the default and dedicated bearer types and outline their
relationship with the Service Data Flow
describe the EPC connection hierarchy and list the set of parameter types that define them
outline the QoS concepts employed by the EPC and define the roles of the QCI and the ARP
outline the methods that are available for providing CS services to EPS attached UEs, includingGeneric Access Network functions, CS Fallback and Voice Call Continuity
outline the security functions employed by the EPC
OBJECTIVES
Evolved Packet Core
V© Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 110/188
LTE/SAE Engineering Overview
VI © Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 111/188
MME
PDN–GW
PCRF
HSS2G/3G SGSN
S–GW
IP Services
IMS
WLAN or
WiMAX
E-UTRAN
LTE
UTRAN/GERAN
UMTS/GPRS
Interworkingto MME
SGiS5
S3
S4
S6a
S7/Gx
S2
S1-U
S1-MME
S12
S11
Rx+
Network Access
IP Functions
MobilityManagement
Anchoring
NetworkManagement
LT3600/v3.1 5.1© Wray Castle Limited
EPS Network Functions
Network Access functions include providing information to assist terminals with network selection and
performing admission control, authentication and authorization, charging and policy control.
EPC gateway nodes are essentially IP routers with an extended capability set, and as such are primarily
dedicated to performing IP packet routing functions for user traffic, signalling and network management
data flows. The EPC (via the PDN-GW) is also responsible for allocating valid IP addresses to each newEPS Bearer.
Regarding mobility management, the EPC has responsibility for idle mode mobility management of
attached UEs and for managing the relocation of user traffic connections when a UE roams from one
network area to another or to another network.
The EPC is responsible for selecting the PDN-GW node that will anchor each user traffic connection (or
EPS Bearer); this is achieved by selecting the appropriate PDN-GW access point for the type of service
being requested by a UE.
Basic network management functions performed by the EPC include load balancing and rebalancing
between MMEs. The objective of these balancing functions is to prevent an MME or pool of MMEs frombecoming overloaded.
Further Reading: 3GPP TS 23.401:4.3
Evolved Packet Core
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 112/188
Non-AccessStratum (NAS)
Non-AccessStratum (NAS)
Access Stratum(AS)
Access Stratum(AS)
User Equipment eNode B Evolved Packet CoreUu S1
LT3600/v3.15.2 © Wray Castle Limited
Network Logical Structure
As with UMTS R99, the services provided to UEs by the EPS are divided into those handled by the AS
and those provided by the NAS.
The AS comprises all of the functions performed by the E-UTRAN.
The NAS consists of the Bearers and bearer control signalling functions that support them.
The S1AP includes provision for the direct transfer of NAS signalling between UE and MME via the eNB.
Compared to the core network architecture of previous generations of mobile system such as GSM or
R99 UMTS, the EPC has been provided with a much ‘flatter’ network design, which limits the number of
node types deployed.
Further Reading: 3GPP TS 36.300
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 113/188
NAS signalling and signalling security
Inter CN node signalling for mobility between 3GPP access networks
UE reachability in idle mode
Tracking Area list management
PDN GW and serving GW selection
MME selection for handovers with MME change
SGSN selection
Roaming connection towards home HSS
Authentication
Bearer management and establishment
MobilityManagement Entity
(MME)
LT3600/v3.1 5.3© Wray Castle Limited
MME (Mobility Management Entity)
The MME assumes many of the functions that would previously have been performed by the VLR or
SGSN and which in the evolved network are termed EMM functions.
The MME’s main responsibility is to terminate the Control Plane NAS signalling flows from individual UEs
and to manage the authentication and security functions for each attached UE. Unlike the legacy VLR,
however, the MME is also responsible for bearer establishment. It receives Service Requests from UEsand issues appropriate instructions to the S-GW that will handle each user plane connection.
The EMM functions also include responsibility tracking UEs that are in idle mode and the MME ensures
‘UE Reachability’ by receiving TAU messages, maintaining the tracking area lists and performing paging
of individual UEs when required.
To assist with service resilience, MMEs can be grouped into ‘pools’. eNBs are able to contact any MME
within the pool(s) with which they are associated when passing on UE Attach requests. The MME then
has flexibility as to the S-GW chosen to establish the user plane connection for each UE.
The MME is also in charge of roaming and handover functions to 2G/3G SGSNs.
Further Reading: 3GPP TS 23.401:4.4.2
Evolved Packet Core
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 114/188
Local mobility anchor point for inter-eNB handover
Mobility anchoring for inter-3GPP mobility
Idle mode downlink packet buffering
Lawful interception
Packet routing and forwarding
Transport level DiffServ packet marking
Charging
Serving Gateway(S-GW)
LT3600/v3.15.4 © Wray Castle Limited
S-GW (Serving Gateway)
The S-GW handles user plane connectivity between UEs and the EPC and acts as the EPC mobility
anchor for UEs roaming within part of a PLMN. This entails performing IP packet routing and buffering
functions and also managing QoS by inserting DSCP (DiffServ Code Point) data into IP packet headers.
The S-GW also provides mobility anchoring for connections that roam onto legacy 3GPP GERAN (GSM
EDGE Radio Access Network) (2G) and UTRAN (UMTS Terrestrial Radio Access Network) (3G) accessnetworks. As all EPS user traffic must pass through an S-GW it is a logical node within which, in concert
with the PDN-GW, to base the EPS Lawful Interception interface and also the charging functions.
The standard S5 and S8 interfaces that link the S-GW and PDN-GW are based on the 3GPP GTP; many
non-3GPP systems obtain similar IP mobility functionality by employing the MIPv4 (Mobile IPv4) or
PMIPv6 (Proxy Mobile IPv6) protocols developed by the IETF (Internet Engineering Task Force).
Adapted versions of the S5 and S8 interfaces are available that support the PMIP protocol for IP mobility.
In such cases, the S-GW will also act as the FA (Foreign Agent) to anchor mobile IP tunnels.
To provide some legacy perspective, taken together the MME and S-GW provide the EPC with
functionality similar to that previously provided by the SGSN, with the MME handling the signalling and
session control aspects and the S-GW dealing with the user traffic.
Early in its development, the S-GW was also known as the UPE (User Plane Entity), although this
terminology has now been dropped.
Further Reading: 3GPP TS 23.401:4.4.3.2
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 115/188
Per-user-based packet filtering
Lawful interception
UE IP address allocation
DiffServ packet marking
SDF level charging
SDF gating control and data rate enforcement
Contains APN (Access Point Name)
DHCPv4 (server and client) and DHCPv6 (client,
relay and server) functions
PDN Gateway(PDN-GW)
LT3600/v3.1 5.5© Wray Castle Limited
PDN-GW (Packet Data Network Gateway)
If the functionality of the MME/S-GW can be thought of as analogous to that of the legacy SGSN, then
the PDN-GW can be thought of as similar in function to the legacy GGSN. The PDN-GW (also known in
some versions of the specifications as the P-GW) routes traffic between EPS Bearers and the SGi
interface, which leads to external data networks such as the IMS and the Internet.
As all inbound and outbound EPS traffic must pass through a PDN-GW it is the logical node in which thenetwork’s packet filtering and classification functions are based. These include the ‘deep packet
inspection’ techniques that are used to classify packets into particular SDFs before routing them over an
EPS Bearer or the SGi interface, which in turn allows the PDN-GW to act as the network’s PCEF Under
direction from the PCRF (Policy and Charging Rules Function) the PDN-GW will apply ‘per SDF’
charging, service level and rate enforcement and QoS-related traffic shaping functions that control the
‘gating’ of user traffic flows.
Each PDN-GW contains a number of logical access points (each identified by an APN which act as the
GTP tunnel endpoints and mobility anchors of the EPS Bearers that extend service out to mobile UEs. As
in the legacy GGSN, the APNs are responsible for the allocation of IP addresses to UEs during the
establishment of each EPS Bearer and for routing traffic between the Bearers and particular external
networks.
Further Reading: 3GPP TS 23.401:4.4.3.3
Evolved Packet Core
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 116/188
Decides whether and when to create additional EPS bearers
Terminates the S7/Gx and Rx interfaces for
home network service and the S9 interface
point for roaming with local breakout
Provides PCC data such as service data flow detection,
gating, QoS, ARP and flow-based charging information to
traffic handling entities
Policy andCharging Rules
Function (PCRF)
LT3600/v3.15.6 © Wray Castle Limited
PCRF (Policy and Charging Rules Function)
The PCRF is responsible for propagating the network’s connection policies and charging rules to the
PDN-GW via the S7/Gx interface and to traffic gateway elements within the IMS via the Rx interface. It is
the element that decides if new connections are to be allowed and, if so, whether they will be carried by
an existing EPS Bearer or whether a new one is required.
The PCRF is responsible for providing service data flow detection, gating, QoS and flow-based charginginformation to traffic handling entities within the network. This includes rules that allow the PDN-GW to
provide the correct level of service to user data flows once the type of traffic being carried has been
determined. For example, if the PDN-GW determines that the SDF to a user is carrying real-time traffic it
may ‘gate’ up to the data rate and QoS level indicated by the PCRF and the user’s subscription profile.
The PCRF’s charging rules allow the operator to apply the appropriate rating to CDRs (Call Data
Records) generated for each SDF so that, for instance, real-time connections can be differentiated from
an Internet browsing session.
In the case of EPS roaming, when users use their terminals abroad, 3GPP has developed an extended
PCRF architecture, based on the S9 interface, that defines Home Policy and Charging Rules Function
(H-PCRF) and Visited Policy and Charging Rules Function (V-PCRF) logical functions.
Further Reading: 3GPP TS 23.401:4.4.7
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 117/188
Serving Gateway
(S-GW)
PDN Gateway
(PDN-GW)
Functions could
be combined within
same device
Mobility
Management Entity
(MME)
S5
LT3600/v3.1 5.7© Wray Castle Limited
Combined Functionality
3GPP has deliberately designed the EPC network elements and interfaces to give vendors the greatest
possible flexibility when developing their solutions.
Although the MME, S-GW, PDN-GW and PCRF all have a set of rigidly defined functions and open
interfaces, the specifications make it explicit that equipment vendors are free to deploy these logical
functions to physical devices in whatever way suits them best.
For example, the MME and SGW functions can both be located in one device, such as an upgrade to an
existing 3G SGSN platform. The S11 interface would then be internal to that combined device.
In the same way it is conceivable that a vendor may decide to combine the functions of the S-GW and
PDN-GW into one combined EPS gateway, rendering the S5 an internal interface.
Further Reading: 3GPP TS 23.401:4.4
Evolved Packet Core
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 118/188
PDN-GW
Co-ordinated MME Pool
and S-GW Service Area
E-UTRAN Tracking Areas served by Pools and Areas
LT3600/v3.15.8 © Wray Castle Limited
Resilience Through Pooling
In common with ongoing developments within many existing 3G core networks, the EPC is designed to
take advantage of the concept of ‘pooling’, specifically of MME and S-GW nodes.
The ‘S1-flex’ facility that allows each eNB in the E-UTRAN to be associated with multiple MMEs in the
EPC allows those MMEs to be grouped into ‘pools’. Each pool will be responsible for the eNBs in one or
more complete tracking areas.
This means that when an eNB selects the MME that will handle the Attach process for a UE, that MME
can continue to serve that UE as long as it remains within the tracking areas associated with the MME’s
pool. This reduces the requirement for MME relocation and consequently reduces the network’s
signalling load. Pooling also provides a measure of resilience for network services to the extent that, if
one MME falls over, eNBs have a number of alternative devices to select. As with current
implementations of the pooling concept, however, MME pooling does not protect the connections to
UEs being served by a failed MME – when the MME fails all ongoing services supported by it fail too.
In the same way as an MME pool area comprises a set of cells within which a UE does not need to
change the serving MME, an S-GW service area is a set of cells within which a UE does not need to
change S-GW.
MME pools may overlap, and each MME pool area is identified by an MMEGI (MME Group Identifier).
S-GW Areas are also permitted to overlap.
Further Reading: 3GPP TS 23.401:3.1
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 119/188
RRC
ECM
RRC
EMM
State machines store UEand bearer context data
MME eNB UE
ECM
EMM
LT3600/v3.1 5.9© Wray Castle Limited
UE State Machines
In order to offer effective service to UEs, the EPS needs to be able to define and keep track of the
availability and reachability of each terminal. It achieves this by maintaining two sets of ‘contexts’ for
each UE – an EMM (EPS Mobility Management) context and an ECM (EPS Connection Management)
context – each of which is handled by ‘state machines’ located in the UE and the MME.
A further state machine operates in the UE and serving eNB to track the terminal’s RRC state, which canbe either RRC-IDLE (which relates to a UE in idle mode) or RRC-CONNECTED (which relates to a UE
with an active traffic bearer).
Further Reading: 3GPP TS 23.401:4.6
Evolved Packet Core
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 120/188
MME
UE
EMM-Registered
EMM-Registered
EMM-Deregistered
EMM-Deregistered
Detach,
Attach Reject
TAU Reject
All Bearers deactivated
Attach accept,
TAU accept
Detach,
Attach Reject
TAU Reject
E-UTRAN interface switched off due to
Non-3GPP handover
All Bearers deactivated
Attach accept,TAU accept
LT3600/v3.15.10 © Wray Castle Limited
EMM States
EMM is analogous to the MM processes undertaken in legacy networks and seeks to ensure that the
MME maintains enough location data to be able to offer service to each UE when required.
The two EMM states maintained by the MME are EMM-DEREGISTERED and EMM-REGISTERED.
A UE in the EMM-DEREGISTERED state has no valid context stored in an MME, so its current locationis unknown and paging and traffic routing cannot take place. This is generally consistent with a UE that
is either powered off or is out of EPC-connected network coverage.
The EMM-REGISTERED state relates to UEs that have performed either an attach or a TAU (Tracking
Area Update) and for which the MME maintains a valid context. In this state the UE will have been
assigned an M-TMSI and will be performing TAU functions when necessary. This means that the MME
knows the UE’s location (at least to the current TA level) and can page and route traffic for it.
A UE in the EMM-REGISTERED state will have at least one active EPS bearer (the ‘always-on’ initial or
default bearer).
In order for a UE in ECM-Idle state to perform an Explicit Detach and move from EMM-Registered toEMM-Deregistered, it must first move to ECM-Connected state to ensure that a signalling bearer is
available to carry the Detach message.
Further Reading: 3GPP TS 23.401:4.6.2
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 121/188
MME
UE
ECM-Connected
ECM-Connected
ECM-Idle
ECM-Idle
S1 connection released
S1 connection established
RRC connection released
RRC connection established
LT3600/v3.1 5.11© Wray Castle Limited
ECM (EPS Connection Management) States
The ECM states describe a UE’s current connectivity status with the EPC, e.g. whether an S1
connection exists between the UE and EPC or not.
There are two ECM states, ECM-IDLE and ECM-CONNECTED.
A UE in ECM-IDLE has no S1 active relationship with an MME, although UE and Bearer Contexts will bestored in the serving MME, and no NAS signalling is passing between those elements.
A UE in this state will perform network and cell selection/reselection and will send TAU messages, but
has no RRC or S1 traffic bearers established. In ECM-IDLE the location of the UE is known by the MME
only to the level of the current TA or TA List.
In the ECM-CONNECTED state a UE has established a signalling relationship with an MME, which will
know the UE’s location to the eNB level, not the current cell level. The UE’s Bearer Contexts will be
activated and RRC and S1 transport resources will have been assigned to it.
A UE will move to the ECM-CONNECTED state during functions such as Attach, TAU and Detach and
when an EPS bearer is active for traffic transfer.
A UE moves from ECM-IDLE to ECM-CONNECTED by sending a Service Request to the MME.
Further Reading: 3GPP TS 23.401:4.6.3
Evolved Packet Core
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 122/188
MME
PDN–GW
PCRF
HSS2G/3G SGSN
SGiS5
S3
S4
S6a
S7/Gx
S–GW
IP Services
IMS
WLAN or
WiMAX
S2
S1-UE-UTRAN
E-UTRA
UTRAN/
GERAN
UMTS/
GPRS
S1-MME
S12
S11
Interworkingto MME
Rx+
EIR
S13
Roaming
PCRF
S9
S8
EPS
Roaming
LT3600/v3.15.12 © Wray Castle Limited
Interface Naming Convention
There are numerous interfaces defined for the EPC, most of which share the reference letter ‘S’.
They are functionally separated into those that carry control (C-plane) and those that carry user (U-plane)
traffic. Support of most S interfaces in the EPC is mandatory, although some are optional.
An overview of the interfaces is given in the diagram.
Further Reading: 3GPP TS 23.401:4.2
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 123/188
S1-MME
MME
eNB
S-GW
S1-U
IP
L2
S1AP
SCTP
L1
L1
UDP
IPL2
User PDU
GTPv1-U
LT3600/v3.1 5.13© Wray Castle Limited
S1 to E-UTRAN Interface
The S1 interface can be seen as the evolved equivalent of the 3G Iu interfaces and interconnects the E-
UTRAN with the EPC. Individual S1 interfaces run logically between each eNB and the set of MMEs and
S-GWs to which it is associated.
Messages and other control plane traffic and S1-U flows carry user plane and call control traffic.
Message structures for the S1-MME interface, which operates between the eNB and the MME, are
defined by the S1AP. S1AP performs duties that combine those performed by the legacy RANAP and
GTP-C protocols with additional elements to support traffic flows in an all-IP environment.
Data flow over the S1-MME is protected from loss and network failure by the use of SCTP (Stream
Control Transmission Protocol) at the transport layer (layer 4). SCTP was specifically designed by the
IETF to handle the flow of signalling and control traffic over an IP network. Retransmission of failed or
missing data packets, and therefore guaranteed delivery of signalling data, is one of the facilities
provided by SCTP.
Further Reading: 3GPP TS 23.401:5.1, 36.413 (S1AP)
Evolved Packet Core
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 124/188
L1
UDP
IP
L2
User PDU
GTPv1-U
S1-U
S-GW
EPS IP Transport
Non-guaranteed
PDU delivery via
GTP-U
LT3600/v3.15.14 © Wray Castle Limited
S1-U
A logical S1-U interface is created between an eNB and each S-GW with which it is associated and
provides AS connectivity for E-UTRAN users.
User traffic, transmitted in the form of a PDU, is encapsulated in GTPv1-U and carried across the S1-U.
GTPv1-U operates across UDP/IP and offers a non-guaranteed delivery service; user connections that
require guaranteed delivery must employ a connection-oriented protocol above the GTP transport layer to manage retransmissions.
GTPv1-U is simply a relabelled version of the GTPv1 protocol employed in 3G packet core and UTRAN
environments, although only the U-plane element is employed. An evolved version of GTP – GTPv2 – is
employed to provide C-plane services on some other EPS interfaces but is not required on the S1-U.
Connection establishment and control functions for S1-U connections are managed by the S1 Application
Protocol via the S1-MME interface.
An Evolved Radio Access Bearer (E-RAB) is a service provided by the Access Stratum to the Non
Access Stratum for transfer of data of between the UE and the S-GW. Individual E-RAB traff ic
connections are established to carry an end user’s EPS Bearer; the E-RAB is itself carried within a
GTPv1-U Tunnel over the S1 interface and is identified at the GTP level by TEIDs.
Further Reading: 3GPP TS36.414 (S1 Data Transport) and 29.281 (GTPv1-U)
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 125/188
S-GW 1
MME 1
S-GW 2
MME 2
S-GW 3
MME 3
S1-MME
S1-U
S1-Flex
LT3600/v3.1 5.15© Wray Castle Limited
S1-Flex Operation
Each eNB is able to establish associations with multiple MME and S-GW devices following a principle
known as S1-Flex.
The main benefit of Flex capability is that it provides redundant core network services for each eNB and
the set of UEs they serve. When a new UE requests service in a cell, whether due to an initial Attach or
following a Handover, the eNB is able to select the MME to which it forwards the NAS connectivityrequest from one or more MME Groups. If an individual MME fails or becomes overloaded, the Flex
concept ensures that only a subset of each cell’s users will be affected. Similar redundancies are
provided for EPS Bearer connections through S-GWs.
Associated with the benefi ts of service redundancy are those of load balancing. If eNBs tailor the
numbers of UEs they introduce to each MME to the advertised ‘relative capacity’ of each of those devices
then the chances of individual MMEs becoming overloaded is minimized.
A further, but less obvious, benefit of the S1-Flex process is the ability it offers to allow each eNB to
connect to and offer services for more than one PLMN. In theory, a physical network of base stations can
advertise the services of, and connect traffic to, multiple PLMNs; this is a key enabler of LTE’s ability to
support shared or Multi-Operator network environments. In this model, user connection requests areforwarded by the eNB to an MME belonging to one or other of the core networks that are sharing the
same E-UTRAN.
Further Reading: 3GPP TS36.401
Evolved Packet Core
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 126/188
S1-MME
MME
Home eNB
(HeNB)S-GW
S1-U
Home eNB Gateway
(HeNB GW)
Broadband
IP
L2
S1-AP
SCTP
L1
L1
UDP
IPL2
User PDU
GTPv1-U
LT3600/v3.15.16 © Wray Castle Limited
S1 Interfaces for Home eNBs
The HeNB (Home eNode B) concept provides a standardized method for creating and connecting LTE
‘femtocells’. Similar methods have been developed for the 3G HNB (Home Node B).
A femtocell provides limited-area radio coverage to residential or business premises; connections are
passed back to the operator’s core network via a broadband Internet connection. Indeed, femtocell
devices are often incorporated into broadband routers along with the broadband modem and Wi-Fiaccess point.
The HeNB provides the same set of services as a ‘full’ eNB and is logically connected to the EPC via the
same S1-MME and S1-U interfaces.
Operators may optionally deploy an HeNB GW (Home eNB Gateway) to concentrate S1-MME traffic
towards the MMEs, although the HeNBs will work even without a Gateway.
The HeNB presents itself to the HeNB GW as an eNB; the Gateway presents itself to the HeNB as an
MME. The HeNB GW presents itself to the MME as an eNB.
An X2 interface between neighbouring HeNBs is not supported, although mobility between HeNB cellsand other cells via the MME/S-GW is possible.
Further Reading: 3GPP TS 36.300:4.6, TR 25.820
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 127/188
UE Capability
Information
UE CapabilityInformation
Trace
Tracestart/
deactivate/failure
Cell TrafficTrace
Location
Reporting
LocationReport
Warning
Messages
WarningMessage
Transmission
eNB Direct
Information
eNB DirectInformation
Transfer
MME Direct
Information
MME DirectInformation
Transfer
Reset
Error Indication
S1 Setup
eNB/MMEConfiguration
Update
Overloadstart/stop
CDMA2000
Tunnelling
CDMA2000TunnellingProcedures
Context
Management
Initial ContextSetup
UE Contextrelease/
notification
Handover
Signalling
HOpreparation/notification/cancellation
HO Resource Allocation
Path Switch
eNB/MMEStatus Transfer
Paging
Paging
NAS
Transport
Direct Transfer
E-RAB
Management
E-RABsetup/modify/
release
Management
Procedures
LT3600/v3.1 5.17© Wray Castle Limited
S1AP Functions and Procedures
S1AP protocol has been designed to perform the following functions:
E-RAB management
Initial Context Transfer
UE Capability Info Indication
Mobility Functions for UEsPaging
S1 interface management
Reset
Error Indication
Overload
Load balancing
S1 Setup
eNB and MME Configuration Update
NAS Signalling transport
S1 UE context Release
UE Context Modification
Status Transfer Trace
Location Reporting
S1 CDMA2000 Tunnelling
Warning message transmission
RIM (RAN Information Management)
Configuration Transfer
The functions are performed by employing the various EP message types shown in the diagram.
Further Reading: 3GPP TS 36.413:8.1
Evolved Packet Core
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 128/188
Home or
Visited Network
SGSN
S-GW
SGSN
S4
S16
PDN-GW
IP
Services
S5SGi
RNC
S12
S8
Home Network
SGi
PDN-GW
L1
UDP
IP
L2
GTPv1-U
LT3600/v3.15.18 © Wray Castle Limited
GTPv1-U Traffic Interfaces
Most EPC interfaces are based on a combination of GTPv1-U and GTPv2-C.
The S4 interface carries U-plane traffic between an S-GW and an SGSN for EPC-attached UEs that have
roamed onto GERAN (GSM EDGE Radio Access Network)/UTRAN access. SGSNs that support the S4
can also be upgraded to use the S16 interface, which allows the evolved combination of GTPv1-U and
GTPv2-C to be used between SGSNs.
The S5 interface interconnects an S-GW to a PDN-GW within the same PLMN. The S8 Interface
provides roaming connectivity between a visited S-GW and a home PDN-GW. The S5 interface is based
on the 2G/3G Gn interface, whilst the S8 is analogous to the Gp interface.
The S12 interface is used to provide a U-plane only ‘direct tunnel’ between an S-GW and a 3G RNC,
which allows the user plane to bypass the SGSN and thus avoids any traffic bottlenecks that may occur.
Further Reading: 3GPP TS 23.401:5.1, 23.281 (GTPv1-U), 23.060 (GPRS)
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 129/188
Home or
Visited Network
SGSN
MMES3
S10
MME
S-GW
SGSN
S11
S16
PDN-GW
S5
SGi
S8
Home Network
SGi
PDN-GW
IP
Services
L1
UDP
IP
L2
GTPv2-C
LT3600/v3.1 5.19© Wray Castle Limited
GTPv2-C C-plane Interfaces
The S3 interface provides control plane connectivity between an MME and an SGSN and is used to carry
handover and other control signalling between EPS and GERAN/UTRAN PS environments. The S16
interface carries control messaging between evolved SGSNs.
The S16 interface carries control messaging between evolved SGSNs. If an S16 interface exists it can be
used to handle the relocation of bearers between SGSNs without requiring the operation to be controlledby an S-GW.
In addition to carrying user traffic, the S5 and S8 interfaces also carry GTPv2-C based control
messaging. Networks based on non-3GPP protocols may elect to use variants of the S5 and S8
interfaces based on IETF ‘mobile IP’ protocols instead.
The S10 interface carries inter-MME signalling traffic and is employed during functions such as MME
relocation. This may occur, for example, when a Connected Mode UE roams out of one MME pool area
into another, or when MME load balancing or rebalancing is taking place. The S10 is analogous to the
Gn interface and is based on GTPv2-C running over UDP/IP.
Further Reading: 3GPP TS 23.401:5.1, 29.274 (GTPv2-C), 23.060 (GPRS)
Evolved Packet Core
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 130/188
MME
HSS
SGSN
EIR
S6a
S13
S6d
L1
TCP/SCTP
IP
L2
Diameter
LT3600/v3.15.20 © Wray Castle Limited
Diameter-based Interfaces
The Diameter protocol was designed by the IETF as a more standardized successor to the venerable
RADIUS (Remote Access Dial-In User Service) protocol, which provides a method of transporting AAA
(Authentication, Authorization and Accounting) data over an IP network. Various proprietary adaptations
of RADIUS have been developed, which were largely non-interoperable, making it a de facto closed
standard.
The S6a interface connects the MME to the HSS and allows the secure transfer of subscriber and other
data between those nodes. The Diameter Base Protocol and the applications that enable communication
between the MME and HSS run over an IP link and can be protected at the transport layer by either TCP
or SCTP.
The S13 interface optionally interconnects the MME and the Equipment Identity Register (EIR) and is
therefore analogous to the GPRS Gf interface. Unlike the Gf, however, the S13 interface is based on the
Diameter protocol.
The S6d interface allows 2G/3G SGSNs that also support the S4 interface to the S-GW to connect
directly to the EPS HSS for mobility management and subscriber data access purposes.
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 131/188
PDN–GW
Visited PCRF
IMS
Home PCRF
S7/Gx Rx
S9
L1
TCP/SCTP
IP
L2
Diameter
LT3600/v3.1 5.21© Wray Castle Limited
PCRF Diameter Interfaces
The S7 interface connects the PDN-GW to the PCRF. It carries policy lookups sent by the PDN-GW in
response to connection requests and the replies generated by the PCRF that determine how or if those
requests will be fulfilled.
The S7 interface is based on the existing Gx interface and 3GPP specifications and diagrams use the
reference names interchangeably.
The Rx interface connects the PCRF to the IMS and carries a similar range of message types as the Gx.
The S9 interface carries policy and charging rules data between home and visited PCRFs to allow home
network policies to be applied to roaming UE connections.
Visited PCRFs may have the facility to request PCC (Policy and Charging Control) details from a user’s
home network but they are under no obligation to enforce them if they contradict local policies.
Further Reading: 3GPP TS 23.401:4.7.4; 23.203
Evolved Packet Core
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 132/188
MME
MSC/VLR orMSC Server
SGs/SV
L1
SCTP
IP
L2
SGsAP
LT3600/v3.15.22 © Wray Castle Limited
Interface to CS Networks
The EPC was designed as an ‘all IP’ environment and as such carries all traffic, even voice, in IP
streams but interfaces have been developed that allow for backwards compatibility with and handover of
CS (Circuit Switched) traffic to legacy networks, if required.
The SGs interface is based on the GERAN/UTRAN Gs interface and carries mobility management and
handover signalling between an MME and a legacy MSC (Mobile-services Switching Centre) or MSCServer. It was created to serve the interfacing requirements of the CS Fallback service, which allows
EPC-Attached UEs to drop back to 2G/3G networks to handle CS calls.
The SGsAP (SGs Application Part) message format employed on the interface is an adaptation of the
BSSAP+ (Base Station System Application Part +) protocol employed on the legacy Gs interface, and
provides much the same set of services.
Other interfaces have been developed to support other forms of EPC-CS Core interaction; the SGs
interface, for example, carries MME-MSC/MSC-S signalling to support the SRVCC (Single Radio VCC),
which allows IMS-anchored real time sessions to be seamlessly handed over between EPS Bearers and
GERAN/UTRAN CS Bearers.
Further Reading: 3GPP TS 23.216 (SRVCC), 23.272 (CS Fallback)
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 133/188
UE
MME
PDN-GWS-GW
eNB
EPS Bearer
Radio Bearer
External Bearer
S5/S8 Bearer E-RAB
S1 Bearer
Uu S1 S5/S8
LT3600/v3.1 5.23© Wray Castle Limited
Connection Identifiers
The EPS Bearer ID (EBI) is assigned by the MME upon bearer establishment.
The EBI consists of 4 bits which in theory allows a maximum of 16 EPS bearers to be created for each
UE. However, the relevant specification indicates that 5 values are reserved which limits the number of
EPS Bearers per UE to 11. EBI values are always assigned by the MME which sets the EBI value for the
default bearer and sends it to the S-GW. In the same way, the MME also assigns the EBI value todedicated bearers. In UMTS networks the equivalent of an EBI is the NSAPI (Network Layer Service
Access Point Identifier) which is used to identify a PDP context. When the UE moves from LTE to UMTS,
the EBI is mapped to an NSAPI – this mapping is not complex as both NSAPI and EBI are 4 bit values.
The EPS Bearer ID is a one-octet string, which in theory means that each UE can have up to 256 EPS
Bearers associated with it per MME. However, the relevant specifications currently indicate that the most
significant 4 bits of the ID should be set to 0, which limits the number of EPS Bearers per UE to 16.
The EPS Bearer travels between the UE and the PDN-GW; during handovers it may also extend over the
X2 interface between source and target eNBs.
When travelling over the S1 and X2 interfaces, there is a one-to-one mapping between the EPS Bearer and the E-RAB and between the identities assigned to each of those entities.
Further Reading: 3GPP TS 23.401:5.2.1
Evolved Packet Core
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 134/188
UE S1-AP ID
S1-MME S1-AP Context
MME S1-AP ID
Tunnel
Endpoint IDs
(TE-ID)
S1-U GTP Tunnel
X2-C (UE X2-AP IDs)
X2-U (GTP TE-IDs)
UE
MME
S-GW
LT3600/v3.15.24 © Wray Castle Limited
Transport Identities
To allow the S1 and X2 protocols to identify the UEs that form the endpoint of each transport tunnel,
terminals are assigned identities that are unique within the eNBs or MMEs that support those endpoints.
The UE S1-AP ID and MME S1-AP ID are unique within the eNB and MME respectively that are handling
the E-RAB/EPS Bearer to an Attached UE. The IDs are simple numerical identifiers (24-bits in the eNB
and 32-bits in the MME) and are not associated with a specific instance of the S1 interface in eachdevice. An eNB can therefore support a maximum of 224 (16.7 million) UE S1 connections and an MME
232 (4.3 billion).
The UE X2-AP ID performs the same basic function as the S1-related identities, but for the X2 interface.
The X2 is optional and is only used to pass handover-related traffic between source and target eNBs, so
the X2-AP ID will only be created as required when a handover is initiated. The ID is 12 bits long and
provides a maximum of 4096 UE X2 handover identities per eNB.
The 4-byte GTP TEID is used in the EPS the same way as it is in legacy networks. Each device that
supports a GTP tunnel refers to it in terms of the TEID assigned to the tunnel plus the IP address and
UDP port number of the interface that handles it. TEIDs are assigned by the receiving side of each
connection and are exchanged using S1-AP during tunnel establishment.
Further Reading: 3GPP TS 23.401:5.2; 36.413:9.2.3; 29.274 (GTPv2-C); 36.41x (S1); 36.42x (X2)
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 135/188
PDN-GWS-GWeNBUE
Internet
IMS
Initial orDefault EPS
Bearer
Subsequent orDedicated EPS
Bearer
Both Bearersrouted viasame APN
Both Bearersshare sameIP address
LT3600/v3.1 5.25© Wray Castle Limited
Default and Dedicated EPS Bearers
Each UE will establish an initial or default EPS Bearer as part of the attach process. This will provide the
required ‘always on’ IP connectivity to the UE and may be to a ‘default APN’, if one is stored in the user’s
subscriber profile, or to an APN selected by the network.
In networks that interconnect to an IMS, the default bearer allows the UE to perform SIP registration and
thereafter to provide a path for session initiation messaging. In these circumstances, the data rate andQoS assigned initially to the default bearer is commensurate with the expected low level of SIP-based
traffic flow, but these parameters can be modified to accommodate the requirements of application traffic
flows when a connection is established.
If a UE has a requirement to establish an application connection whose QoS or data rate demands are
incompatible with those currently assigned to the default bearer (but which can still be routed through the
current APN), the PDN-GW or PCRF may initiate the establishment of an additional EPS Bearer to carry
the new traffic flow. Any additional bearers assigned to a UE in addition to the default bearer are termed
dedicated bearers and will be identified by different EPS Bearer/E-RAB and radio bearer IDs.
A UE may have more than one PDN Connectivity Service running if it has connections established
through more than one APN/PDN-GW. In that case, there will be one Default Bearer and an optionalnumber of Dedicated Bearers created for each PCS. The EPS Bearer ID value limits the total number of
bearers established for one UE to 11.
Further Reading: 3GPP TS 23.401:4.7.2
Evolved Packet Core
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 136/188
PCEF (Policy and
Charging EnforcementFunction) in PDN-GW
QCI (QoS Class Identifier)
ARP (Allocation and Retention Priority)
GBR (Guaranteed Bit Rate)
MBR (Maximum Bit Rate)
EPS
EPS QoS Characteristics
LT3600/v3.15.26 © Wray Castle Limited
EPS Quality of Service
QoS in the EPS is defined by a combination of four parameters:
QCI (QoS Class Identifier)
ARP (Allocation and Retention Priority)
GBR (Guaranteed Bit Rate) MBR (Maximum Bit Rate)
EPS QoS is applied between the UE and the PDN-GW.
Further Reading: 3GPP TS 23
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 137/188
PDN-GW1S-GW
UE
PDN-GW2
EPS bearer withGBR QoS
APN-AMBR for non-GBREPS bearers to PDN-GW 1
UE-AMBR for all non-GBREPS Bearers from UE
APN-AMBR for non-GBR
EPS bearers to PDN-GW 2
LT3600/v3.1 5.27© Wray Castle Limited
QoS Levels
QoS in the EPC is currently defined by three levels: GBR, MBR and AMBR (Aggregate Maximum Bit
Rate).
GBR connections are assigned a guaranteed data rate and are therefore useful for carrying certain types
of real-time and delay-sensitive traffic. MBR connections are non-guaranteed, variable-bit-rate services
with a defined maximum data rate. If a connection’s data rate goes beyond the set maximum the networkmay decide to begin discarding the excess traffic.
GBR and MBR parameters are applied on a ‘per bearer’ basis, whereas AMBR is applied to a group of
bearers; specifically, a group of non-GBR bearers that terminate on the same UE. AMBR allows the EPS
to set a maximum aggregate bit rate for the whole group of bearers that can then be shared between
them.
The APN-AMBR parameter sets the shared bit rate available to a group of non-GBR bearers that
terminate on the same APN and can therefore be seen to be applied on a ‘per PCS’ basis; the UE-AMBR
parameter aggregates all non-GBR bearers associated with one UE.
Dedicated bearers can be established as GBR or non-GBR (i.e. MBR) as required. Default bearers, dueto the probable need to adjust their bandwidth after the initial Attach has taken place, must be non-GBR.
Further Reading: 3GPP TS 23.401:4.7.3
Evolved Packet Core
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 138/188
Bearer Context – Active
Radio Bearer/E-RAB/EPS Bearer Active
DRB S1 Tunnel S5/S8 Tunnel
UE eNB S-GW PDN-GW
MME
Bearer Attributes
LT3600/v3.15.28 © Wray Castle Limited
Active EPS Bearers and Bearer Contexts
An EPS bearer provides a data path between a UE and an APN located in a PDN-GW. Once created, an
EPS bearer can be in one of two states – active or inactive.
When active, the EPS bearer is assigned bearer resources that amount to a radio bearer and GTP
tunnels, with assigned TEIDs (Tunnel Endpoint IDs) that will carry the E-RAB (E-UTRAN Radio Access
Bearer) and EPS Bearer over the Uu, S1-U and S5/S8 interfaces.
Each PDN connection and default and dedicated EPS bearer is described by a Bearer Context stored in
the UE and MME and in other devices required to serve each bearer.
Default and dedicated bearer contexts describe the UE’s current ECM state (idle or connected) plus the
bearer’s EPS bearer ID and QoS parameters, and can be either active or inactive.
An active Bearer Context is deemed to be in the ESM BEARER CONTEXT ACTIVE state.
Further Reading: 3GPP TS 23.401:4.7.2
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 139/188
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 140/188
MME
PDN–GW
SGSN
SGi
S5
S3
S4
A/Iu
S–GWS1
E-UTRAN
Access
GERAN/UTRAN
Access
S11
MSC-S
MGW
Sv
McGb/Iu
GERAN/UTRAN
EPS
IMS
UE using
E-UTRAN
access
PS traffic
CS traffic
LT3600/v3.15.30 © Wray Castle Limited
Providing CS Services via LTE/EPS
The EPC was designed to handle a wide range of IP-based PS applications and to provide and
appropriate Quality of Service (QoS) to these applications. This is enabled by establishing an EPS
Bearer between a UE and the access point to an external network.
3GPP’s intention was that real-time and more traditional services, especially those that were handled by
CS networks – voice, fax, SMS, dial-up data, supplementary services, emergency calls, etc – would behandled in conjunction with an IMS.
It was always accepted that some network operators may wish to continue to make use of their legacy
CS core networks, either in place of an IMS or alongside one, and 3GPP and a number of industry
bodies have proposed methods of achieving this.
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 141/188
MME
PDN–GW
SGSN
SGi
S5
S3
S4
A/Iu
S–GWS1
E-UTRANAccess
GERAN/UTRANAccess
S11
MSC-S
MGW
SGs
McGb/Iu
GERAN/UTRAN
EPSCS
signalling
CS traffic
IMS not
required
EPS Attached UE
Paged via E-UTRAN
Falls back to
GERAN/UTRAN for
connection
Returns to E-UTRAN
when Idle
LT3600/v3.1 5.31© Wray Castle Limited
CS Fallback
Arguably, the simplest solution to the problem of providing CS services without necessarily deploying an
IMS is to use 3GPP’s CS Fallback service.
CS Fallback allows an EPS UE to perform combined Attach/Location Update functions with the EPS and
the legacy CS core.
Mobile-Terminated CS transactions, such as inbound calls or SMS, are directed to the legacy CS core as
usual. The MSC or MSC Server that receives the inbound transaction alerts the UE’s serving MME via
the SGs interface and the MME pages the UE. When it responds, the UE is directed to drop down to a
‘CS capable cell’ in the GERAN/UTRAN to receive the inbound service. Mobile-Originated CS services
are handled in the same way, with the UE requesting the service via the EPS but being directed to
GERAN/UTRAN access resources to complete the transaction. Once the CS transaction is over, the UE
will return to idle mode and will camp onto an E-UTRAN cell.
Any EPS Bearers carrying PS traffic will be handed over to the GERAN/UTRAN via an SGSN, if possible,
when the CS Fallback is initiated.
CS Fallback can operate in conjunction with IMS-based services or could be used as an interim measureby an operator that is not yet ready to deploy one.
Further Reading: 3GPP TS 23.272 (CS Fallback)
Evolved Packet Core
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 142/188
MME
PDN–GW
SGSN
SGi
S5
S3
S4
A/Iu
S–GWS1
E-UTRANAccess
GERAN/UTRANAccess
S11
MSC-S
MGW
Sv
McGb/Iu
GERAN/UTRAN
EPS
CS traffic
UE HO to
GERAN/UTRAN
access
CS call employs
SRVCC
PS uses standard HO
techniques
IMS
PS traffic
LT3600/v3.15.32 © Wray Castle Limited
VCC (Voice Call Continuity)
VCC (Voice Call Continuity) is designed to make use of the combined resources of the IMS and legacy
CS core network by allowing IMS-anchored real-time or CS calls to be handed over from the E-UTRAN
and the GERAN/UTRAN.
The specific variant of this concept outlined in the diagram is SRVCC (Single Radio VCC), which
supports UEs that only contain one radio and can therefore only connect to one air interface method at atime; in this scenario, the UE is capable of connecting to E-UTRAN, UTRAN or GERAN cells but only
one at a time.
Call- and handover-related signalling is passed between the MME and MSC-MSC Server via the Sv
interface. Handover or hand back of calls from UTRAN/GERAN to E-UTRAN is not supported; once a
call drops down to 2G/3G it stays there.
Any active PS sessions will be split from the CS sessions and handed over to a 2G/3G SGSN at the
same time as the CS sessions are transferred.
The SRVCC specification also provides options for handing over IMS-anchored real-time sessions from
UTRAN (HSPA) and 3GPP2 1xRTT CDMA2000 access networks to GERAN/UTRAN resources.
Further Reading: 3GPP TS 23.216 (SRVCC)
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 143/188
MME
PDN–GW
SGi
S5
A/Iu
S–GWS1
E-UTRAN
Access
GERAN/UTRANAccess
MSC-S
MGW
S11
GANC
GERAN/UTRAN
EPS
SGs/Sv
A/Iu
EPS Attached UE
CS traffic forwardedto EPS via GANC
CS traffic
IMS notrequiredEPS-GERAN/UTRAN CS
HO negotiated via SGs or Sv interfaces
LT3600/v3.1 5.33© Wray Castle Limited
CS Service Provision via a GANC
One further proposal for offering CS services via the EPS, put forward by the VoLGA (Voice over LTE
Generic Access) Forum, is to reuse the framework developed to provide connectivity to 3GPP services
via a GAN (Generic Access Network). A GAN can be essentially any kind of network that can support the
flow of IP traffic, although the GAN specifications produced by organizations like 3GPP are mainly aimed
at Wi-Fi based systems.
This option involves causing the least disruption to the CS core and the EPS by installing a GANC
(Generic Access Network Controller) between the two network environments. Handover and control
signalling between the EPS and CS core would travel over the SGs or Sv interfaces, which were
developed to support CS Fallback and SRVCC services respectively.
The scheme does involve some administrative extensions to EPS operation, which would allow a suitably
equipped UE to register for VoLGA services and for CS handovers between the EPS and 2G/3G
networks.
Further Reading: 3GPP TS 43.318, 44.318 (GAN); www.volga-forum.com
Evolved Packet Core
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 144/188
Mutual authentication
Authorization
User confidentiality
Ciphering
Integrity protection
LT3600/v3.15.34 © Wray Castle Limited
EPC Security Functions
The EPC is responsible for maintaining user subscription and security data and for using that data to
ensure that unauthorized users cannot gain access to network services. UEs must also be given the
means to ensure that the network they are connecting to is valid and authentic.
The EPC must also ensure that users’ identities remain confidential. The same applies to the traffic that
users send over the network.
Finally, the integrity of the flow of signalling and control traffic around and across the network must be
protected to ensure that it is not intercepted and altered by unauthorized persons.
Further Reading: 3GPP TS 33.301
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 145/188
MME
UE/USIM
HSS
eNB
XRES
Quintuplet
RAND
AUTN
CK
IK
LT3600/v3.1 5.35© Wray Castle Limited
AKA (Authentication and Key Agreement)
EPS employs the same AKA (Authentication and Key Agreement) mechanism as is used by 3G UMTS
networks.
The EPS AKA mechanism aims to ensure that the network can authenticate users and vice versa, and
that once authenticated, users and network can agree on a set of encryption mechanisms to employ to
protect user and control traffic. EPS AKA operates between the UE and the MME and is facilitated bysubscription data stored in the USIM (Universal Subscriber Identity Module) and the HSS.
As in 3G UMTS, when a user is required to authenticate, the HSS will generate a quintet of AVs
(Authentication Vectors): a random 128-bit number (RAND), an XRES (Expected Response), a CK
(Cipher Key), an IK (Integrity Key) and an AUTN (Authentication Token) – which are passed to the
serving MME.
RAND is used as a challenge and is transmitted to the UE. The USIM processes RAND through its copy
of the ‘shared secret’ K authentication key and generates a response, which is transmitted back to the
MME. If the USIM response matches XRES then the USIM is deemed to be genuine and the UE is
allowed to access network services.
The CK is passed to the serving eNB to allow user plane encryption to and from the UE to take place,
while the IK is employed between the UE and the MME to protect the integrity of signalling messages.
Finally, the AUTN is passed to the UE to allow it to authenticate the network.
Further Reading: 3GPP TS 33.102; 33.401; 23.401
Evolved Packet Core
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 146/188
MME
UE/USIM
EPC & E-UTRAN
ISMT-M
IMSI
LT3600/v3.15.36 © Wray Castle Limited
User Confidentiality
As with legacy 3GPP systems, the EPS uses the IMSI to absolutely and uniquely identify each user. The
user confidentiality mechanism provides subscriber anonymity by ensuring that the IMSI is transmitted
across the network as little as possible.
A UE accessing a network for the first time or after a long period of inactivity has no option but to transmit
its user’s IMSI to the network to allow identification and authentication to take place. Once the user hasbeen authenticated, however, the MME generates an ‘alias’ that may then be used in place of the IMSI to
identify the subscriber.
Generically in 3GPP networks this alias is known as a TMSI. The specific variety employed in the EPS is
the M-TMSI. The correspondence between M-TMSI and a user’s true IMSI is known only to the MME and
user’s UE. An M-TMSI will be unique within the MME that issued it. When combined with an MMEC to
make an S-TMSI it becomes unique within an MME pool. When the M-TMSI is combined with a GUMMEI
to form a GUTI it becomes unique within all EPS networks.
The MME may elect to request UEs to reauthenticate periodically and will issue a new M-TMSI at this
time. A UE may be issued a new M-TMSI when it moves to the control of a new MME.
The EPS user confidentiality mechanism is essentially the same as that employed in the GERAN and
UTRAN, although the identities of the relevant network elements have changed.
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 147/188
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 148/188
LTE/SAE Engineering Overview
II © Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 149/188
Idle Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.1
Cell Reselection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.2
E-UTRA Radio Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.3
Measurements for RRC Connected Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.4
Measurement Gaps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.5
Timing Advance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.6
CQI Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.7
MIMO Options for LTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.8
EPS Initial Attach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.9
Default Bearer Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.10
EPC Support for Idle Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.11
TAU (Tracking Area Update) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.12
Idle-mode Signalling Reduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.13
Paging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.14
IMS Functions in Idle Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.15
Levels of Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.16
UE-Triggered Service Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.17
Handling Additional Traffic Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.18
Dedicated Bearer Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.19
IMS Connection Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.20
Connected Mode Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.22
Intra-E-UTRAN Handover (X2-based) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.23
Inter-RAT HO Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.24
Inter-RAT Handover Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.25
CONTENTS
LTE Operation
III© Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 150/188
LTE/SAE Engineering Overview
IV © Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 151/188
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 152/188
LTE/SAE Engineering Overview
VI © Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 153/188
PLMN selectionand reselection
Cell selectionand reselection
Location
registration
Support for
manual CSG IDselection
Locationregistrationresponse
Servicerequests
Indicationto user Manual
mode
Automaticmode
AvailablePLMNs
SelectedPLMN
Registrationarea changes
Locationregistrationresponse
NAS
control
Radio measurements
CSG IDselected
Available CSGIDs to NAS
LT3600/v3.1 6.1© Wray Castle Limited
Idle Mode
Idle mode represents a state of operation for the UE where it has successfully performed the following:
PLMN selection, cell selection and location registration (by tracking area).
Once in idle mode, the UE will continue to reassess the suitability of its serving cell and, in some
circumstances, its serving network. In order to do this it will implement cell and PLMN reselection
procedures. A UE in idle mode will be monitoring its current serving cell in terms of radio performanceand signalling information. The radio performance measurements are done on the basis of a quality
measure. This is an assessment of radio signal strength and interference level, and it can be made for
both the serving cell and its neighbours. The aim will be to ensure that the UE is always served by the
cell most likely to give the most reliable service should information transfer of any kind be required.
The UE will also be monitoring two key types of signalling from the serving cell system information
messages and paging or notification messages. System information messages convey all the cell and
system parameters. The UE will record changes in these parameters that may affect the service level
provided by the cell, or access rights to the cell. Changes in these parameters could provoke a cell
reselection, or a PLMN reselection. Paging or notification messages will result in connection
establishment.
All of these procedures are performed through communication between the AS and the NAS. In general,
instructions are sent from the NAS to the AS; the AS then performs the requested procedure and returns
a result to the NAS.
If CSG (Closed Subscriber Group) is supported then these procedures are modified such that a cell’s
broadcast CSG ID forms another level of differentiation between cells. CSG is intended for use with
HeNBs (femtocells).
Further Reading: 3GPP TS 36.304:4.1
LTE Operation
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 154/188
Based on priority ofRAT/Frequency layers
and thresholds
Based on priority ofRAT/Frequency layers
and thresholds
Based on measurements,offsets, parameters and
mobility status
1 sec since last reselectionCell is suitable
I-RATInter-frequency
E-UTRAInter-frequency E-UTRA
Intra-frequency
Low
Medium
High
Measurement rules
Evaluation
Ranking
Reselection
LT3600/v3.16.2 © Wray Castle Limited
Cell Reselection
Cell reselection in LTE both reuses many principles that were are well established in legacy technologies
and introduces new strategies. A key addition for LTE is the use of RAT/frequency prioritization. Each
frequency layer that the UE may be required to measure, either E-UTRA or any other RAT, is assigned a
priority. The cell-specific priority information is conveyed to UEs via system information messages.
Additionally, UE-specific values can be supplied in dedicated signalling, in which case they take priority
over the system information values. Any indicated frequency layers that do not have a priority will not beconsidered by the UE for reselection.
In general, the measurement rules are used to reduce unnecessary neighbour cell measurements. The
UE always measures cells on a higher priority E-UTRA inter-frequency or I-RAT frequency. The UE will
only measure E-UTRA intra-frequency cells if the Srexlev value for the current selected cell falls below
an indicated threshold (Sintersearch). Similarly, the UE only measures E-UTRA inter-frequency or I-RAT
frequency cells on equal or lower priority layers if the Srexlev value for the current selected cell falls
below an indicated threshold (Snonintrasearch).
Measurements are then evaluated for potential reselection. Again, the frequency/RAT priority level is
used along with system-defined threshold for this assessment. A UE will always reselect a cell on a
higher priority frequency if its value of Srxlex exceeds Threshx,high for longer than TreselectionRAT. It willonly select a cell on a lower priority frequency when the Srxlev of the serving cell falls below
Threshserving,low and Srxlev of the neighbour is above Threshx,low for TreselectionRAT and there is no other
alternative. For neighbour cells on intra-frequencies or on equal priority E-UTRA inter-frequencies, the
UE uses a ranking criterion ‘Rs’ for the serving cell and ‘Rn’ for the neighbour cell. Ranking is based on a
comparison of the respective Srxlev values with a hysteresis added to the serving cell value and an offset
added to the neighbour cell value. The UE will select the highest ranked cell if the condition is maintained
for TresectionRAT.
In addition to all of this, the UE will apply scaling to Treselection, hysteresis values and offset values
dependent on an assessment of its mobility state, which may be high, medium or low. This is based on
an analysis of resent reselection frequency.
Further Reading: 3GPP TS 36.304:5.2.4
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 155/188
(Reference Signal Received Power) (Received Signal Strength Indicator)
Total received power in RS OFDMsymbol periods including the serving
cell, all co-channel and adjacent channelinterference and thermal noise
Linear average power ofthe reference signalresource elements
The ratio of the reference signal power,calculated as N x RSRP, to the RSSI, where
N is the number of RBs in the RSSImeasurement bandwidth
(Reference Signal Received Quality)
RSRP RSSI
RSRQ
Serving cellServing cell
LT3600/v3.1 6.3© Wray Castle Limited
E-UTRA Radio Measurements
There are three key measurement values used in E-UTRA, the RSRP (Reference Signal Received
Power), the RSSI (Received Signal Strength Indicator) and the RSRQ (Reference Signal Received
Quality).
The standards define RSRP as:
‘The linear average over the power contributions of the resource elements that carry cell-specific
reference signals within the considered measurement frequency bandwidth’.
The standards define RSSI as:
‘The linear average of the total received power observed only in OFDM symbols containing
reference symbols for antenna port 0, in the measurement bandwidth, over N number of resource
blocks by the UE from all sources, including serving and non-serving cells, adjacent channel
interference, thermal noise, etc.’
The standards define RSRQ as:
‘The ratio NxRSRP/(E-UTRA carrier RSSI), where N is the number of RBs of the E-UTRA carrier
RSSI measurement bandwidth’.
Note that the measurement of RSRP is based on reference signals from antenna port 0, but where
antenna port 1 can be received reliably, reference signals from that port may also be included.
Additionally, the values of RSRP and RSSI used to calculate RSRQ must have the same measurement
bandwidth.
Further Reading: 3GPP TS 36.214:5.1
LTE Operation
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 156/188
UE
RRC Connected
eNBServing cell
Gap configuration
Quantity configuration
Measurement identities
Reporting configuration
Measurement objects
Measurement Parameters
Neighbour
cells
LT3600/v3.16.4 © Wray Castle Limited
Measurements for RRC Connected Mode
When the UE becomes RRC connected, the measurement and reporting process as well as mobility
decisions becomes the responsibility of the eNB. The required measurement and reporting settings are
signalled to the UE in the RRCConnectionReconfiguration message.
The measurement object defines what the UE is to measure. This is defined as a frequency and
measurement bandwidth; optionally it may also contain a list of cells. If it does contain a list of cells thenthey will be indicated as either white list or black list. The UE will measure any cells it detects but will not
report black list cells. Frequency- or cell-specific offsets will also be included in this field.
The reporting configuration sets what quantities the UE is to measure, what quantities the UE is to report
and under what circumstances a measurement report is to be set. Reporting may be set as either trigger-
based, periodic or triggered periodic. This field also defines the other contents of the measurement report
message.
Measurement identities provides a reference number such that some part of this identified measurement
can be modified or removed in future.
The Quantity configuration sets the filtering to be used on the measurements that are taken.
The gap configuration defines periods when the UE can take measurements of neighbour cells.
Further Reading: 3GPP TS 36.331:5.5
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 157/188
eNBServing cell
Transmission gap(6 ms)
Transmission gap repetitionperiod (N x 10 ms)
Neighbour cell Neighbour cellNeighbour cell
LT3600/v3.1 6.5© Wray Castle Limited
Measurement Gaps
When the UE is in RRC connected mode it will be engaged in data transfer in the uplink or downlink
directions or both. In order to simplify the design of the UE it is not required to be able to take neighbour
cell measurements and transfer data with the serving cell at the same time. This requires defined periods
where the UE is able to take neighbour cell measurements and is not required to communicate with the
serving cell.
Transmission gaps perform this function and are very similar in concept to compressed mode for UMTS.
The transmission gaps have a duration of 6 ms since this allows sufficient time to take measurements
and gain basic synchronization with most RATs in a single transmission gap. For GSM, however, 6 ms
remains a sufficient gap, but multiple transmission gaps are required to take measurements and
determine a cell’s BSIC (Base Station Identity Code).
The transmission gap period is variable, but will be a multiple of 10 ms.
The transmission gap pattern to be used by a UE is included in the measurement parameters.
Further Reading: 3GPP TS 36.133:8.1
LTE Operation
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 158/188
eNB measures propagationdelay from PRACH preamble
TA step size is 16Ts (0.52 μs)
Correction is included in theRAR as a value of steps in the
range 0 to 1282 (0 to 0.67 ms
TA adjustments are madeusing MAC controlmessages in the PDSCH
Correction is a value in therange 0 to 63 interpreted as+/– 31 steps (+/– 16 μs)
LT3600/v3.16.6 © Wray Castle Limited
Timing Advance
In order to maintain orthogonality between uplink transmissions from multiples UEs in a cell, timing
adjustment must be applied to compensate for variations in propagation delay.
Initial timing advance is calculated at the eNB from a UE’s preamble transmission on the PRACH. The
timing advance correction is given as an 11-bit value although the range is limited to 0–1282 timing
advance steps. Granularity is in steps of 16Ts (0.52 μs) so timing advance can be varied between 0 and0.67 ms. One timing advance step corresponds to a distance change of c.78 m and is significantly
smaller than the normal CP. The maximum timing advance value corresponds to a range of c.100 km.
The maximum specified speed for a UE relative to an eNB is 500 km/h (139 m/s), which would require
slightly more than one timing advance change every two seconds. Consideration also needs to be given
to the possibility of more extreme changes in the multipath characteristics of a channel, for example the
sudden appearance or disappearance of a strong reflected path from a distant object or delay through a
repeater. However, these are extreme examples and, in any case, timing advance update commands
can indicate up to +/– 16 μs in a single step. Thus the rate at which timing advance commands need to
be sent in practice is typically much less than one every two seconds.
Timing update commands are transmitted to UEs as MAC control messages and as such are included inMAC PDUs carrying data for the UE on the PDSCH. The command itself is a six-bit value giving a
number range from 0–63. Values less than 31 will reduce timing advance and values greater than 31 will
increase timing advance.
Further Reading: 3GPP TS 36.213:4.2.3
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 159/188
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 160/188
Transmit Diversity Beamforming
Closed loop with PMI feedback
SU-MIMO (ranks up to 4)MU-MIMO (virtual MIMO)
LT3600/v3.16.8 © Wray Castle Limited
MIMO Options for LTE
In its first release, LTE is specified with several options for SU-MIMO implementation and a more limited
option for MU-MIMO operation. The specification include descriptions of operation up to rank 4 (4x4
MIMO).
The simplest option is not MIMO, as such, but uses the multi antenna array at an eNB to provide transmit
diversity. The standards allow configuration with up to four antennas at the base station. It is likely thatcross-polar antennas would be used as part of the antenna array, so a two-antenna array could be
implemented using a single cross-polar panel, with a four-antenna array requiring two cross-polar panels.
Transmit diversity involves the transmission of a single data stream to a single UE, but makes use of the
spatial diversity offered by the antenna array. This can increase channel throughput or increase cell
range.
There are also two beamforming options available. These are based on the use of a single layer with rank
one pre-coding but make use of a multi antenna array for beamforming to a single UE. The two options for
this are a closed loop mode, which involves feedback of PMI (Pre-coding Matrix Indicators) from the UE,
and an open loop mode, which involves the transmission of UE-specific reference signals and the eNB
basing the pre-coding for beamforming on uplink measurements.
Full SU-MIMO configurations are available in LTE in the downlink direction with ranks up to four. However,
a maximum of two data streams is used, even when four antenna ports are available. In SU-MIMO the UE
can be configure to provide PMI feedback as well as RI (Rank Indicators), which indicates the rank that
the UE calculates will give the best performance.
In the first release of the LTE specification there is only a limited implementation of MU-MIMO specified. It
is applicable in the uplink direction and allows two UEs to use the same time frequency resource within
one cell.
Further Reading: 3GPP TS 36.211:6.3.3, 6.3.4, 36.213:7.1
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 161/188
UE eNB MME S-GW PDN-GW HSSEIR
1. AttachRequest
2. AttachRequest
3. AKA/Security
Optional Stage
4. IdentityRequest/Response
4. ME Identity Check
4. CipheredOptions Request
4. CipheredOptions Response
5. Update Location
5. Insert Subscriber Data
5. Insert Subscriber Data Ack
5. Update Location Ack
LT3600/v3.1 6.9© Wray Castle Limited
EPS Initial Attach
The UE’s objective when performing an attach is to register the subscriber’s identity and location with the
network to enable services to be accessed. During the attach procedure the UE will be assigned a default
EPS bearer to enable always-on connectivity with a PDN. The UE may be provided with details of a local
P-CSCF to enable it to register with the IMS.
A simplified view of the attach process – assuming that it is an initial attach with stored details from arecent previous context for a UE using its H-PLMN (Home PLMN) and accessing via the Home E-UTRAN
– is shown, and the stages of the process are described below.
Once a suitable cell has been selected the UE employs the Random Access procedure to request an
RRC connection with the chosen eNB. With that in place an Attach Request message (1) can be
transmitted. If the UE has previously been registered with the PLMN, it may include a previously assigned
GUTI in the message, otherwise the Attach Request message contains the subscriber’s IMSI and some
other parameters.
On receipt of the Attach Request the eNB either derives the identity of the previously used MME from the
supplied GUTI or selects an MME from the pool available and forwards the message (2).
The MME contacts the HSS indicated by the subscriber’s IMSI and in response receives the relevant
elements of the ‘quintuplet’ that allows the EPS-AKA process to take place (3).
Optionally, at this point the MME may be required to check the identity and status of the UE via the EIR
(4) using the ME Identity Check process. Ciphering may then be invoked over the air interface.
Once the AKA procedures have successfully concluded the MME transmits an Update Location message
to the HSS and receives the Insert Subscriber Data message in response containing the user’s service
profile (5). An Insert Subscriber Data Ack from the MME is followed by an Update Location Ack from the
HSS. The UE is now Attached to the EPC.
Further Reading: 3GPP TS 23.401:5.3.2
LTE Operation
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 162/188
UE eNB MME S-GW PDN-GW HSSPCRF
6. Create DefaultBearer Request
7. PCC
Lookup
Optional Stage
8. Create DefaultBearer Response
9. Initial Context SetupRequest/ Attach Accept
10. RRC Conn
Reconfig
11. RRC Conn
Reconfig
Complete 12. Initial Context
Setup Response13. Direct
Transfer 14. Attach
CompleteData flow
LT3600/v3.16.10 © Wray Castle Limited
Default Bearer Establishment
A default bearer must then be established and the MME selects the S-GW that will handle and a PDN-GW
that supports the requested APN. The MME issues a Create Default Bearer Request to the selected S-GW,
which assigns a GTP TEID to the EPS bearer and passes the request to the indicated PDN-GW (6).
If the network employs dynamic PCC the PDN-GW will query a PRCF for bearer parameters, otherwise the
bearer will be established using local QoS parameters stored in the PDN-GW (7).
A Create Default Bearer Response message passes from the PDN-GW to the S-GW, which contains
relevant parameters such as the EPS bearer’s IP address and possibly the IP address or DNS name of a
local IMS P-CSCF. The S-GW creates the bearer as specified and passes the Create Default Bearer
Response message to the MME (8). The details that define the S1-U service will also have been defined
during this stage.
The MME sends an Initial Context Setup Request/Attach Accept message, which contains the assigned
parameters for the EPS bearer context, to the eNB (9). That element in turn sends an RRC Connection
Reconfiguration message to the UE (10) to inform it of the bearer details and the changed air interface
parameters.
The UE returns an RRC Connection Reconfiguration Complete message (11) to verify that the radio bearer,
which was initially established just to carry the attach message, has been reconfigured to support the new
parameters. The eNB forwards an Attach Complete message to the MME (12).
The UE then sends a Direct Transfer message to the eNB (13), which confirms the details of the EPS
Bearer. Finally, the eNB sends an Attach Complete message to the MME to confirm that both the Attach
and the Default EPS Bearer processes have completed successfully.
Uplink and downlink data can now flow if required.
Further Reading: 3GPP TS 23.401:5.3.2
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 163/188
ECM StateEPS Bearer ID
QoS
TA 9
TA 12
MME Pool A
UE TA List UE Default Bearer
Context – Inactive
TA 9TA 12
LT3600/v3.1 6.11© Wray Castle Limited
EPC Support for Idle Mode
The MME currently serving each UE is responsible for ensuring its ‘reachability’. It achieves this by
monitoring the current TA in which the terminal is located.
The EPS allows a cell to be a member of more than one TA. This allows a UE to roam within a set of
contiguous TAs without being required to perform a TAU, which reduces the amount of location-related
signalling that is required, although it may conversely increase the amount of paging required per UEconnection request.
The MME reflects this extended mobility by maintaining a TA list for each registered UE within which the
list shows the set of TAs the UE is currently registered.
During a TAU, and periodically in the event that a TAU does not occur within a set time-frame, the MME
is responsible for reauthenticating each registered UE and for reissuing the M-TMSI used to
confidentially identify it.
When a UE drops into the ECM-IDLE state its existing default bearer can be ‘parked’ and any dedicated
bearers can either be parked or released. To support this, the MME stores details of the UE’s current
‘bearer contexts’ ready to reactivate them in the event of a UE or network-triggered Service Request.
A TAU may result in the need to change the S-GW assigned to handle an idle UE’s bearer contexts or of
the MME with which the UE is registered, if the reselected cell is associated with a different S-GW
Service Area or MME Pool.
If ISR (Idle-mode Signalling Reduction) is active for a UE, the MME may be required to pass location
updates and other pertinent information to the SGSN with which the UE is co-registered.
Further Reading: 3GPP TS 23.401:4.3.5
LTE Operation
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 164/188
UE eNB MME HSS
TAU trigger event
1. TAU Request
2. TAU Request+ TAI and ECGI
3. Authentication/Security
Optional Stage
4. TAU Accept
5. TAU Complete
LT3600/v3.16.12 © Wray Castle Limited
TAU (Tracking Area Update)
A TAU takes place between a UE and the MME with which it is registered and is triggered by the UE
detecting a change in TAI after a cell reselection. A TAU is also be used as part of the Initial Attach
process and may additionally be triggered by events such as the expiry of the periodic TAU timer or as
part of MME load balancing or rebalancing.
In the example message flow it is assumed that the UE is connected to its HPLMN and that an S-GWchange and MME relocation are not required.
After detecting a change in TAI, the UE transmits a TAU Request message to the eNB (1). The TAU
Request contains data such as the old GUTI, old TAI, EPS bearer status and a NAS MAC (Message
Authentication Code) for integrity protection purposes.
The eNB forwards the TAU Request (plus the new TAI and ECGI) to the MME indicated by the supplied
GUTI (2). If the MME indicated by the GUTI is not associated with the new eNB, an MME relocation will
be triggered and the base station will select a new MME to pass the TAU Request to.
If the integrity check of the MAC carried in the TAU Request is successful, the MME may elect not to
reauthenticate the UE. If the MME is configured to always reauthenticate, or if the integrity check fails,then the EPS-AKA process must be followed and a new GUTI (which includes the new M-TMSI) will be
issued (3).
Once the MME is satisfied that the UE/USIM is authentic and assuming that the UE is allowed to roam in
the new TA, it transmits a TAU Accept message to the eNB, which relays it to the UE (4). The TAU
Accept message contains the new GUTI, if one was assigned, plus the current TA List associated with
the UE. The TA List enables the UE to determine the set of TAs within which it can roam without being
required to perform another TAU. The UE responds with a TAU Complete message (5), which finishes
the process.
Further Reading: 3GPP TS 23.401:5.3.3
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 165/188
S-GW
MME
GERAN/UTRAN
SGSN
PDN-GW
E-UTRAN
TA
RA
S3UE can reselect to any
registered RAT without
sending an update
UE and Bearer
Contexts stored
UE and Bearer
Contexts stored
UE paged across
all registered
areas
LT3600/v3.1 6.13© Wray Castle Limited
Idle-mode Signalling Reduction
ISR is designed, as the name suggests, to reduce the amount of UE-network and MME-SGSN signalling
required to manage idle mode terminals. ISR is a feature of the S3 and S16 interfaces and is not
available to legacy SGSNs that do not support them.
When an Idle UE activates (or is instructed to activate) ISR, copies of UE Context and Bearer Contexts
are stored in both an MME (for E-UTRAN access) and SGSN (for GERAN/UTRAN access). The UE isable to reselect freely between registered RATs without transmitting location updates, unless a change in
RAI or TAI is detected. Any location updates that are sent need only be transmitted via the RAT currently
in use; the receiving core network element will forward the update to its peer over the S3 interface.
The MME and SGSN both store copies of the UE’s bearer contexts and will both page for the UE. When
the UE needs to move to connected mode, whether in response to a page or to a user-initiated event, it
can do so by sending a Service Request via whichever RAT it is currently camped on. The receiving
device will then instruct the S-GW to re-establish the parked bearers.
A UE with ISR activated maintains details of the RAT and therefore the RAT-specific temporary identifier
that is in use using the TIN (Temporary Identity used in Next update) parameter.
The TIN can be set to P-TMSI (for GERAN/UTRAN access), GUTI (for E-UTRAN access) or RAT-related
TMSI. This last option means that the UE will use the P-TMSI or GUTI depending upon which RAT is
currently in use.
A UE will deactivate ISR if it loses contact with one of the registered access networks. For example, a UE
might be within the coverage of both an E-UTRAN and a GERAN cell when ISR is activated but may
roam out of coverage of the E-UTRAN cell; in such circumstances it would revert to being attached to just
an SGSN.
Further Reading: 3GPP TS 23.401:Annex J
LTE Operation
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 166/188
S1 Pagingmessages
TA 9
TA 12
UE TA List
TA 9TA 12
LT3600/v3.16.14 © Wray Castle Limited
Paging
The main purpose of the TAU process is to ensure that the MME knows roughly where each UE is in the
event that there is inbound traffic to deliver. Paging will usually be triggered by the receipt of an S-GW
Downlink Data Notification at the MME, indicating that data has arrived at the S-GW on the S5/S8 portion
of a parked EPS Bearer.
If it becomes necessary to contact an idle UE (that is, a UE that has entered the ECM-IDLE state), theMME will employ the paging process.
With no equivalent node to the RNC, EPS paging is managed directly between the MME and eNBs.
When a Paging message is to be sent, the MME checks the current TA list stored for the target UE and
inserts the paging data into the S1 paging messages sent to all eNBs in the indicated TAs.
Each eNB inserts the UE’s NAS paging ID (IMSI or S-TMSI can be used) into the appropriate repetitions
of its PCH. Paging groups may be established to reduce the number of repetitions of the PCH that each
UE is required to monitor; the operation of the paging reduction scheme is controlled via cell-specific
DRX (Discontinuous Reception) functions.
When a UE receives its paging ID on the PCH it initiates the service request process, which ensures that
any ‘parked’ EPS bearers are reactivated ready to carry traffic.
If a UE has ISR activated the paging notification will be forwarded to the peer core network node; either
MME or SGSN.
Further Reading: 3GPP TS 23.401:5.3.4; 36.300
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 167/188
S-CSCF
UE EPS
Re-registration causes:
Change of IP Address
Change of PDN-GW
Expiry of Registration Timer
LT3600/v3.1 6.15© Wray Castle Limited
IMS Functions in Idle Mode
There is no specific equivalent of idle mode in the IMS – a UE is either registered or deregistered.
The main function that an idle mode UE performs in relation to the IMS is to perform periodic re-
registration. The periodicity of the re-registration is determined by the registration expiry value included in
the initial Registration message and the process ensures that the S-CSCF is kept informed of the
reachability of each registered UE.
Re-registration is also required if the UE’s IP address changes – either as a result of a change of PDN-GW
or as part of a network’s DHCP IP address allocation processes (which may seek to reduce the
possibilities of fraud or connection hijack by periodically refreshing the IP addresses assigned to
terminals).
An additional trigger for re-registration would be if the UE or IMS capabilities changed, for example if the
client supporting a new IMS application was loaded to the terminal.
Further Reading: 3GPP TS 23.228:5.2
LTE Operation
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 168/188
PDN–GWS–GWeNBUE
IMS
Internet
Inactive Default
EPS Bearer
Inactive Dedicated
EPS Bearer
Reactivate ‘parked’
EPS Bearers
ServiceRequest
Modify/CreateDedicated
Bearer
To carry new SDFs
LT3600/v3.16.16 © Wray Castle Limited
Levels of Connectivity
User connectivity in a combined EPS/IMS network requires two levels of connection to be established:
firstly, the radio and EPS bearers that will carry traffic through the E-UTRAN and EPC, and secondly the
IMS SIP and media connections that will carry call-related signalling and end-to-end user traffic.
A UE’s default bearer may be an operator’s first choice for carrying application traffic, but if the QoS
demanded by a new service data flow is incompatible with that of the default bearer, then the PDN-GW/PCRF may decide that an additional dedicated bearer is established.
When a UE enters idle mode the physical S1 and radio resources assigned to the default EPS bearer will
be released and the bearer context details will be stored. Any existing dedicated bearers may be
released or stored also.
When the UE moves from ECM-IDLE to ECM-CONNECTED the stored bearer contexts will be
reactivated using the Service Request procedure.
Further Reading: 3GPP TS 23.401:5.3.4
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 169/188
UE eNB MME S-GW PDN-GW HSSPCRF
Trigger event
1. NAS Service
Request2. NAS Service
Request3. Authentication/Security
Optional Stage
4.S1 AP Initial Context
Setup Request5. Radio Bearer
Establishment
6. Uplink Data Flow
7. S1 AP Initial Context
Setup Complete
8. Update Bearer
Request
9. Update Bearer
Request/Response
10. Update Bearer
Response
11. Downlink Data Flow
LT3600/v3.1 6.17© Wray Castle Limited
UE-Triggered Service Request
A UE will trigger a Service Request to reactivate its parked bearer contexts in response to a command
from an application client, the terminal management software or the user interface. A response to a
network initiated paging message will also trigger a Service Request.
The process begins with the transmission of a NAS: Service Request either following the random access
procedure or carried in scheduled uplink capacity. The NAS: Service Request contains the UE’s currentS-TMSI and the service type (data or paging response). The request is initially forwarded to the eNB
encapsulated in an RRC message (1).
Direct Transfer NAS messages were transparent to the UMTS Node B and were only accessible to the
RNC. In the E-UTRAN, NAS messages are switched from the RRC bearer used on the air interface to an
S1AP bearer for forwarding to the MME (2) and in some cases are interpreted by the eNB.
Depending upon configuration, the MME may initiate a reauthentication of the UE/USIM before
processing the Service Request (3).
The MME sends the eNB an S1AP: Initial Context Setup Request, which issues the commands that re-
establish physical resources for the stored bearer contexts on the S1 interface between the UE and theS-GW (4). The eNB allocates radio resources (5) on the air interface and informs the UE. Uplink traffic is
then able to flow (6). The eNB confirms these actions with an S1AP: Initial Context Setup Complete
message (7).
The MME instructs the S-GW to establish its end of the S1-U tunnels using the Update Bearer Request
message (8). If the PDN-GW has requested updates regarding the UE’s location, the S-GW will pass this
on in an Update Bearer Request (9). After the PDN-GW and S-GW return Update Bearer Responses,
data can begin to flow on the downlink (9, 10 and 11).
Further Reading: 3GPP TS 23.401:5.3.4
LTE Operation
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 170/188
UE eNB MME S-GW PDN-GW HSSPCRF
Trigger event
1. Request Bearer Resource
Modification
2. Request Bearer Resource
Modification
3. PCC Lookup
Optional Stage
4. Existing TFT modified, new TFT or Bearer activated or existing TFT or Bearer deactivated
LT3600/v3.16.18 © Wray Castle Limited
Handling Additional Traffic Flows
If a UE determines that there is a requirement to establish a traffic flow aggregate (which may contain
one or more SDFs) to a new AF (Application Function) destination – in response to a user interface
request, for example – it will transmit a Request Bearer Resource Modification to the MME. If the UE had
been in Idle Mode when it made this determination it will first send a Service Request to reactivate the
existing bearers.
The MME forwards the request to the S-GW currently dealing with the UE’s EPS Bearer(s), which in turn
forwards it to the appropriate PDN-GW. If dynamic PCC is in use, the PDN-GW interacts with the PCRF
to determine how best to deal with the request: if static PCC is in use then the PDN-GW makes the
determination itself.
The Modification request includes the required QoS, the EPS Bearer ID and a TAD (Traffic Aggregate
Descriptor), which describes the modification function to be performed (add, modify or delete) and the
SDF 5-tuple details that enable the PCRF to build a packet filter for the flow. The PCC function will
evaluate the request and either accept or reject it. Accepted requests result in new or updated packet
filters.
In the case of a new traffic flow that is to be added to an existing bearer, the PCC function will add anadditional packet filter to the TFT (Traffic Flow Template) related to the bearer over which the flow will
travel. If the addition of the new flow alters the bearers QoS requirements the adjustment will be
communicated to other elements using the Update Bearer Request process.
In addition to UE-initiated Bearer Modification the EPC also supports PDN-GW-initiated Bearer
Modification; HSS-initiated Bearer QoS Modification and MME and PDN-GW initiated Bearer
Deactivation.
Further Reading: 3GPP TS 23.401:5.4
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 171/188
UE eNB MME S-GW PDN-GW HSSPCRF
1. Trigger event
2. Request Bearer
Resource Modification 3. Request Bearer
Resource Modification
4. PCC Lookup
Optional Stage
5. Create Dedicated
Bearer Request
6. Bearer Setup Request/
Session Management Request7. RRC Conn
Reconfig
7. RRC Conn
Reconfig
Complete8. Bearer Setup
Response
9. Direct Transfer
10. Session Management
Response11. Create Dedicated
Bearer Response 12. IP-CAN Session
Modified
Data Flow
LT3600/v3.1 6.19© Wray Castle Limited
Dedicated Bearer Creation
If PCC decides that a new traffic flow is incompatible with any of the UE’s existing bearers it may decide
that a new Dedicated Bearer is required, in which case it will instruct the PDN-GW to issue a Create
Dedicated Bearer Request.
The stages of this process are outlined in the diagram.
Further Reading: 3GPP TS 23.401:5.4.1
LTE Operation
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 172/188
UE HomeP-CSCF
HomeS-CSCF Destination IMS/UEHome
PDN-GW
Optional Stage
Trigger event
1. Invite
2. Invite3. Invite
4. Session Progress
Edit4. Session Progress
Edit4. Session Progress
5. Provisional
Acknowledgement5. PRACK
5. PRACK
Resource
Allocation
6. 200 OK
6. 200 OK
6. 200 OK
LT3600/v3.16.20 © Wray Castle Limited
IMS Connection Establishment
IMS connection establishment is the responsibility of SIP. The EPS default bearer is established to a
home network PDN-GW and maintained mainly to provide a path for SIP messaging between a UE and
its serving I-CSCF.
Consider an example SIP flow between a roaming UE and its home S-CSCF during which a media
session to a distant IMS-connected UE is initiated. Not all network elements involved in the processhave been shown.
In response to an instruction received via the user interface, the originating UE initiates the session by
transmitting a Service Request to reactivate its bearers followed by a SIP Invite message to the current
I-CSCF (1). The Invite message contains an SDP payload, which describes the type of connection the
originating UE wishes to establish with the destination UE.
The I-CSCF passes the message on to the assigned S-CSCF for authorization (2). The S-CSCF
discovers the called party’s home network and passes the Invite to an I-CSCF in that network for
forwarding to the S-CSCF and the destination UE (3).
Once discovered, the destination UE inspects the SDP payload and determines if it can support thetype of service and QoS parameters specified. A Session Progress message is returned to the
originating UE containing the IP address of the distant terminal and a response to the SDP parameters
(4).
Each CSCF in the return path is able to approve or edit the SDP response so that the eventual media
session’s parameters match the capabilities of the busiest link in the chain.
The originating UE returns a PRACK (Provisional Acknowledgement), which confirms the parameters of
the media session (5). This triggers the reservation of resources for the distant UE, which it confirms
with a 200 OK message (6).
Further Reading: 3GPP TS 23.228:5.4
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 173/188
UE HomeP-CSCF
HomeS-CSCF Destination IMS/UEHome
PDN-GW
VisitedMME
Optional Stage
7. Resource Bearer
Resource Modification
8. Update8. Update
8. Update
9. Ringing
9. Ringing9. Ringing
Exchange of PRACK & 200 OK
Answer
11. 200 OK11. 200 OK
Resources
Committed
11. 200 OK
Media Flow
LT3600/v3.1 6.21© Wray Castle Limited
IMS Connection Establishment (continued)
Once confirmed, the originating UE may issue a Request Bearer Resource Modification to the MME to
trigger a modification of the default bearer, or possibly the establishment of a new dedicated bearer (7).
An Update message is sent to the distant network to confirm that a bearer with the required QoS is
reserved (8).
At this point the distant UE informs its user of the requested session and returns the Ringing indication to
the originating end (9).
When the called party answers, the distant UE sends a 200 OK message (11) (which, technically, is
issued in response to the original Invite message); the I-CSCFs instruct the PDN-GWs to release the
resources previously reserved for the session and data begins flowing directly between the UEs without
travelling through the IMS.
The mobile-terminated scenario follows the same procedure as mobile-originated procedure except it
begins with a SIP Invite message being sent to the terminating UE, which may result in the UE being
paged and a network-triggered Service Request to reactivate its default bearer from idle mode.
From that point onwards it can exchange SIP messages with the originating UE via its current
I-CSCF.
Further Reading: 3GPP TS 23.228:5.4
LTE Operation
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 174/188
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 175/188
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 176/188
UE SourceeNB
SourceS-GW
PDN-GWTargetRNC
TargetMMESGSN
Data Flow
Optional Stage
1. Handover decision
2. Handover Required
3. Forward Relocation
Required
4. Create BearerRequest/Response
5. Relocation Request
6. Relocation Request Ack
7. Forward Relocation
Response
8. Create BearerRequest/Response
LT3600/v3.16.24 © Wray Castle Limited
Inter-RAT HO Preparation
The example provided below is for handover of active traffic connections between a home-network
E-UTRAN cell and a home-network 3G UTRAN cell without an S-GW change and with no S12 Direct
Tunnel support.
Following a UE’s decision to request a handover (1), but before that handover can be initiated, a certain
amount of preparation must take place.
The source eNB determines that the indicated handover candidate is an inter-RAT neighbour and
informs the source MME using the Handover Required S1AP message (2).
The source MME selects a target SGSN and issues a Forward Relocation Request via the S3 interface
(3).
If the target SGSN has an S4 interface to the existing S-GW it issues a Create Bearer Request to that
S-GW (4). If the target SGSN has no S4 interface to the serving S-GW (if they are in different PLMNs for
example) then the target SGSN must select a local target S-GW, establish a bearer to it and then initiate
an S-GW Relocation between the source and target nodes. Inter-PLMN traffic travels from visited S-GW
to home PDN-GW, not visited SGSN to home PDN-GW.
The target SGSN instructs the target BSC/RNC to reserve radio resources for the UE in the target cell
using the Relocation Request message (5), and the target RNC responds with Relocation Request Ack
once this is complete (6).
Once the GERAN/UTRAN RAB and PDP context are in place, the target SGSN sends the Forward
Relocation Response to the source MME (7).
Further Reading: 3GPP TS 23.401:5.5.2
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 177/188
UE SourceeNB
SourceS-GW
PDN-GWTargetRNC
TargetMMESGSN
Data Flow
Optional Stage
9. Handover Command
10a . HO from E-UTRAN
Command
Release and reconnect
10b. HO to UTRAN
Complete11a. Downlink Data via Direct Forwarding (eNB-RNC)
Direct Forwarding
11b. Downlink Data via Indirect Forwarding
Indirect Forwarding
11a/b. Downlink Data
11c. Uplink Data
12. Relocation Complete
13. Forward Relocation Complete
LT3600/v3.1 6.25© Wray Castle Limited
Inter-RAT Handover Execution
The UE remains connected to the source E-UTRAN cell during the preparation phase, but once
alternative resources are in place the source MME issues a Handover Command to the source eNB (9),
which in turn sends a HO from E-UTRAN Command to the UE (10a). This message encapsulates a
‘transparent container’ that travels between the target RNC and the UE, which contains details of the
resources that have been reserved for the UE in the target cell.
The UE releases its E-UTRAN resources and performs the access activities required to establish
connectivity in the target UTRAN cell and sends the Handover to UTRAN Complete message (10b) in the
new cell to confirm the connection.
As the tunnel from the PDN-GW has not yet been realigned, Downlink packet traffic destined for the UE
is still being sent to the source eNB and must be forwarded to the target RNC. Direct forwarding between
the source eNB and target RNC (11a) uses an unnamed forwarding interface. Indirect Forwarding travels
between source eNB, source S-GW, target SGSN and target UTRAN (11b). Once the handover is
complete, the UE can send traffic on the uplink via the PDP Context that has been created towards the
SGSN, from where it will be forwarded to the S-GW and on to the PDN-GW (11c).
Once the UE has successfully connected to the UTRAN cell the target RNC sends a RelocationComplete message (12) to the target SGSN, which in turn informs the source MME using the Forward
Relocation Complete message (13).
Further Reading: 3GPP TS23.401:5.5.2
LTE Operation
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 178/188
UE SourceeNB
SourceS-GW
PDN-GWTargetRNC
TargetMMESGSN
14. Update Bearer Request/Response
Optional Stage
15. Data Flow
16. Routing Area Update
17. Release Resources 17. Delete Bearer
Request/Response
18. Delete Bearer
Request/Response(if Indirect
Forwarding used)
Direct Forwarding
Indirect Forwarding
LT3600/v3.16.26 © Wray Castle Limited
Inter-RAT HO Execution (continued)
The target SGSN issues an Update Bearer Request to the S-GW (14), which initiates the path switch.
Any indirect forwarding will cease and downlink traffic will travel from the S-GW directly to the target
SGSN (15). If the relocation involved a change in S-GW the PDN-GW would also need to be informed so
that it could realign its end of the EPS bearer tunnel.
The UE performs a RAU (Routing Area Update) (16) and the target SGSN may decide to instruct the UEto reauthenticate.
The MME started a timer when the handover initiated; when it expires it instructs the source S-GW and
source eNB to release any resources and contexts stored for the UE (17).
If indirect forwarding was employed, the source S-GW and SGSN will release any tunnel resources that
were created (18).
Traffic is now flowing to the UE from the PDN-GW, via an S-GW to an SGSN and onwards via the
UTRAN.
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 179/188
LTE/SAE ENGINEERING OVERVIEW
GLOSSARY OF TERMS
LTE/SAE Engineering Overview
I© Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 180/188
LTE/SAE Engineering Overview
II © Wray Castle Limited
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 181/188
LT3600/v3.1 G.1© Wray Castle Limited
16QAM 16-state Quadrature Amplitude Modulation
1xEV-DO 1x Evolution – Data Only
3G Third Generation
3GPP 3rd Generation Partnership Project
64QAM 64-state Quadrature Amplitude Modulation
A1AP A1 Application Protocol
AAA Authentication, Authorization and Accounting
AAL ATM Adaptation Layer
ACLR Adjacent Channel Leakage Ratio
AF Application Function
AKA Authentication and Key Agreement
AM Acknowledged Mode
AMBR Aggregate Maximum Bit Rate
ANR Automatic Neighbour Relation
APN Access Point Name
ARP Allocation and Retention Priority
ARQ Automatic Repeat Request
AS Access Stratum AS Application Server
ATM Asynchronous Transfer Mode
AUTN Authentication Token
AV Authentication Vector
BCCH Broadcast Control Channel
BCH Broadcast Channel
BER Bit Error Rate
BI Backoff Indicator
BLER Block Error Rate
BPSK Binary Phase Shift Keying
BSC Base Station Controller BSIC Base Station Identity Code
BSS Base Station System
BSSAP+ Base Station System Application Part +
BSSGP Base Station System GPRS Protocol
CCCH Common Control Channel
CCE Control Channel Element
CCO Cell Change Order
CDMA Code Division Multiple Access
CDRs Call Data Records
CE Control Element
CFI Control Format Indicator
CGI Cell Global Identity
CK Cipher Key
CLI Calling Line Identity
CMAC Cipher-based MAC
CMC Connection Mobility Control
CP Cyclic Prefix
CPT Control PDU Type
CQI Channel Quality Indication
CRC Cyclic Redundancy Check
C-RNTI Cell Radio Network Temporary Identifier
C-RNTI Controlling Radio Network Temporary Identifier
CS Circuit Switched
CSCF Call Session Control FunctionCSG Closed Subscriber Group
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 182/188
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 183/188
LT3600/v3.1 G.3© Wray Castle Limited
FA Foreign Agent
FDD Frequency Division Duplex
FDM Frequency Division Multiplexing
FFT Fast Fourier Transform
FI Framing Information
FMS First Missing PDCP SN
GAN Generic Access Network
GANC Generic Access Network Controller
GBR Guaranteed Bit Rate
GERAN GSM EDGE Radio Access Network
GGSN Gateway GPRS Support Node
GMM GPRS Mobility Management
GMSC Gateway MSC
G-PDU GTP Protocol Data Unit
GPRS General Packet Radio Service
GPS Global Positioning System
GSM Global System for Mobile communications
GT Guard TimeGTP GPRS Tunnelling Protocol
GTP-C GPRS Tunnelling Protocol – Control plane
GTP-U GPRS Tunnelling Protocol – User plane
GTPv1-U GPRS Tunnelling Protocol version 1 – User Plane
GTPv2 GTP version 2
GTPv2-C GPRS Tunnelling Protocol version 2 – Control Plane
GU Globally Unique
GUMMEI Globally Unique MME Identity
GUTI Globally Unique Temporary Identity
HARQ Hybrid ARQ
HeNB Home eNode BHeNB GW Home eNB Gateway
HFN Hyper Frame Number
HII High Interference Information
HLR Home Location Register
HNB Home Node B
HO Handover
H-PCRF Home Policy and Charging Rules Function
H-PLMN Home PLMN
HSDPA High Speed Downlink Packet Access
HSPA High Speed Packet Access
HSS Home Subscriber Server
HSUPA High Speed Uplink Packet Access
IAM Initial Address Message
ICIC Inter-Cell Interference Coordination
I-CSCF Interrogating Call State Control Function
IDFT Inverse Discrete Fourier Transform
IE Information Element
IETF Internet Engineering Task Force
IFFT Inverse Fast Fourier Transform
IK Integrity Key
I-MAC Integrity Message Authentication Code
IMEISV International Mobile Equipment Identity Software Version
IMS IP Multimedia Subsystem
IMSI International Mobile Subscriber IdentityIMT-2000 International Mobile Telecommunications 2000
IP Internet Protocol
IP-CAN IP Connectivity Access Network
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 184/188
LT3600/v3.1G.4 © Wray Castle Limited
IPsec IP security
IPv4 IP version 4
IPv6 IP version 6
I-RAT Inter-Radio Access Technology
ISI Inter Symbol Interference
ISR Idle Mode Signalling Reduction
KASME Key Access Security Management Entries
KSI Key Set Identifier
LA Location Area
LB Load Balancing
LCID Logical Channel ID
LCR Low Chip Rate
LI Length Indicator
LSF Last Segment Flag
LTE Long Term Evolution
MAC Medium Access ControlMAC Message Authentication Code
MBMS Multicast and Broadcast Multimedia Services
MBR Maximum Bit Rate
MBSFN Multicast/Broadcast Single Frequency Network
MC Mobile Country Code
MCC Mobile Country Code
MCS Modulation and Coding Scheme
MGW Media Gateway
MIB Master Information Block
MIMO Multiple Input Multiple Output
MIPv4 Mobile IP version 4
MME Mobility Management EntityMMEC MME Code
MMEGI MME Group Identifier
MMEI MME Identifier
MNC Mobile Network Code
MS Mobile Station
MSC Mobile-services Switching Centre
MSISDN Mobile Subscriber ISDN Number
M-TMSI MME Temporary Mobile Subscriber Identity
MTU Maximum Transmission Unit
MU-MIMO Multi-User MIMO
NACC Network Assisted Cell Change
NAS Non Access Stratum
NCL Neighbour Cell List
O&M Operations and Maintenance
OAM Operations, Administration and Maintenance
OFDM Orthogonal Frequency Division Multiplexing
OFDMA Orthogonal Frequency Division Multiple Access
P Polling
P/S-SCH Primary/Secondary Synchronization Channel
PAPR Peak to Average Power Ratio
PBCH Physical Broadcast Channel
PBR Prioritized Bit RatePCC Policy Control and Charging
PCCH Paging Control Channel
PCEF Policy and Charging Enforcement Function
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 185/188
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 186/188
LT3600/v3.1G.6 © Wray Castle Limited
RFSP RAT/Frequency Selection Priority
RFSP Index Index to RAT/Frequency Selection Priority
RI Rank Indicators
RIM RAN Information Management
RLC Radio Link Control
RLP Radio Link Protocol
RNC Radio Network Controller
RNS Radio Network Subsystem
RNSAP Radio Network Subsystem Application Part
RNSAP Radio Network Subsystem Application Protocol
RNTI Radio Network Temporary Identifier
RNTP Relative Narrowband
ROCH Robust Header Compression
RoHC Robust Header Compression
RRC Radio Resource Control
RRM Radio Resource Management
RSRP Reference Signal Received Power
RSRQ Reference Signal Received Quality
RSSI Received Signal Strength Indicator RTCP Real Time Control Protocol
RTP Real Time Protocol
S1AP S1 Application Protocol
SAE System Architecture Evolution
SAP Service Access Point
SC-FDMA Single Carrier FDMA
S-CSCF Serving Call State Control Function
SCTP Stream Control Transmission Protocol
SDF Service Data Flow
SDP Session Description Protocol
SDU Service Data UnitSFN Single Frequency Network
SG Signalling Gateway
SGsAP SGs Application Part
SGSN Serving GPRS Support Node
S-GW Serving Gateway
S-GW Signalling Gateway
SI Stream Identifier
SIB System Information Block
SIGTRAN Signalling Transport
SIM Subscriber Identity Module
SIP Session Initiation Protocol
SI-RNTI System Information RNTI
SISO Single Input Single Output
SMS Short Message Service
SN Sequence Number
SO Segment Offset
SON Self-Organising Network
SPS Semi Persistent Scheduling
SRB Signalling Radio Bearer
SRI Send Routing Information
SRS Sounding reference Signals
SRVCC Single Radio VCC
SS7 Signalling System No 7
SSN Stream Sequence Number
SSS Secondary Synchronization SignalS-TMSI SAE TMSI
SU-MIMO Single-User MIMO
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 187/188
LT3600/v3.1 G.7© Wray Castle Limited
TA Timing Advance
TA Transport Address
TA Tracking Area
TAC Tracking Area Code
TAD Traffic Aggregate Descriptor
TAI Tracking Area IDTAU Tracking Area Update
TB Transport Block
TCP Transmission Control Protocol
TDD Time Division Duplex
TDM Time Division Multiplexing
TD-SCDMA Time Division Synchronous Code Division Multiple Access
TEID Tunnel Endpoint ID
TFT Traffic Flow Template
TIN Temporary Identity used in Next update
TM Transparent Mode
TMSI Temporary Mobile Subscriber Identity
TNL Transport Network Layer
TPC Transmit Power ControlTPC-PUCCH-RNTI Transmit Power Control PUCCH RNTI
T-PDU Transport Protocol Data Unit
TSN Transmission Sequence Number
TTI Transmission Time Interval
UDP User Datagram Protocol
UE User Equipment
UL Uplink
UL-SCH Uplink Shared Channel
UM Unacknowledged Mode
UMTS Universal Mobile Telecommunications System
UPE User Plane EntityUpPTS Uplink PTS
USIM Universal Subscriber identity Module
UTRAN UMTS Terrestrial Radio Access Network
VCC Voice Call Continuity
VLR Visitor Location Register
VoIP Voice over IP
VoLGA Voice over LTE Generic Access
V-PCRF Visited Policy and Charging Rules Function
VRB Virtual Resource Block
WCDMA Wideband Code Division Multiple Access
WiMAX Worldwide Interoperability for Microwave Access
WLAN Wireless Local Area Network
X2AP X2 Application Protocol
XRES Expected Response
LTE/SAE Engineering Overview
8/12/2019 LTE SAE Engineering Overview
http://slidepdf.com/reader/full/lte-sae-engineering-overview 188/188
LTE/SAE Engineering Overview