lt3600 lte-sae engineering overview - v3.3

8/12/2019 LT3600 LTE-SAE Engineering Overview - V3.3

http://slidepdf.com/reader/full/lt3600-lte-sae-engineering-overview-v33 1/244

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



LTE/SAE ENGINEERING OVERVIEW

First published 2009

Last updated February 2012

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




II © Wray Castle Limited



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

Appendix LTE Advanced

Glossary


CONTENTS

III© Wray Castle Limited




IV © Wray Castle Limited



SECTION 1

INTRODUCTION TO LTE


I© Wray Castle Limited



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 (E-UTRAN 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




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




VI © Wray Castle Limited



GSM/GPRS

GSM/EGPRS

50 kbit/s

150 kbit/s

UMTS

UMTS/HSPA

EDGEEvolution

UMTS/HSPA+

1 Mbit/s

10 Mbit/s

40 Mbit/s

400 kbit/s

LTE(4G)

100+ Mbit/s

LTE-Advanced

1+ Gbit/s

LT3600/v3.2 1.1© Wray Castle Limited

LTE Overview

LTE (Long Term Evolution) represents the next developmental step for the 3GPP (3rd Generation

Partnership Project) standards group. It provides for a continued evolutionary path from 2G GSM/GPRS

(General Packet Radio Services), beyond 3G UMTS/HSPA and ultimately towards a 4G solution.

UMTS (Universal Mobile Telecommunications System) has continued to build on the success of GSM

(Global System for Mobile Communications) and momentum is gathering behind its significantlyincreased capability with the introduction of HSPA (High Speed Packet Access). The classic fixed and

mobile telecommunications business models are undergoing enormous change with the move towards

all-IP (Internet Protocol) switching and a total-communications service profile. Meanwhile, the last

decade has seen the Internet develop into a serious business tool and fixed broadband access is fast

becoming a basic commodity.

This market landscape is ready for a technology that combines broadband capabilities with an efficient,

scalable switching infrastructure and a flexible service delivery mechanism. LTE provides just such a

solution and is designed to address growing global demand for anywhere, anytime broadband access

while maintaining efficient provision of more traditional telecommunications services and maximizing

compatibility and synergies with other communications systems.

Although LTE most obviously represents an evolutionary path for UMTS networks it has also been

designed to allow cost-effective upgrade paths from other technology starting points. For example, GSM

operators now have the possibility to access 3G-like performance through EDGE (Enhanced Data rates

for Global Evolution), and this in turn can be used as a direct pathway to LTE. Similarly, the interworking

capabilities of the EPC (Evolved Packet Core) make it possible for CDMA (Code Division Multiple

Access) to migrate radio access from 1x or 1xEV-DO (1x Evolution – Data Only) to LTE.

Evolution beyond LTE has been mapped out by 3GPP with the specification of LTE-Advanced, which

offers the possibility of downlink data rates (to stationary or low mobility users) of 1GBit/s or more.

Further Reading: 3GPP TS36.300 (LTE Radio Access), 23.401 (LTE Core Network)

Introduction to LTE



LTE RadioAccess

Former ‘Mobile’Operator

Former ‘Fixed’Operator

Broadcastcontentprovider

New market

opportunities

New marketopportunities

LTE RadioAccess

LT3600/v3.21.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.




E-UTRAN EPCE-UTRA

UE

LTE SAE

EPS


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



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


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.




GSM900 GSM1800

GSM1900

GPRS

EGPRS

UMTS HSDPA

IMS

HSUPA HSPA+

GERAN enhancements

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-Advanced

Rel 10 Rel 11 Rel 12

GSM

GPRS

EDGE

Rel 99 Rel 4 Rel 5 Rel 6 Rel 7 Rel 8 Rel 9 Rel 10 Rel 11 Rel 12

Rel 8 Rel 9 Rel 10 Rel 11 Rel 12

UTRAN enhancements


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. Releases 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, was completed in Release 9. Specification of LTE-

Advanced, a full 4G solution, is detailed in Release 10.

Further Reading: 3GPP Release Descriptions – www.3gpp.org/ftp/Information/WORK_PLAN/Description_Releases/

Introduction to LTE



E-UTRAN EPC

E-UTRA

LTE Signalling LTE Traffic

SCTP

All-IP


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. SC-FDMA is also sometimes known as DFT-FDMA.

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.




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


Access Networks and the eNB (E-UTRAN 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 main backhaul link to the core network, it has also assumed responsibility for managing the

PDCP (Packet Data Convergence Protocol) service, which provides header compression and cipheringfacilities 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. An eNB may be associated with MMEs

belonging to different PLMNs (Public Land Mobile Networks), allowing for the easy creation of multi-

operator networks.

The eNB also receives, schedules and transmits control channel information in its cells, including paging

messages and broadcast system information, both of which are received from the MMEs. It retains many

of the traditional roles associated with base stations, such as bearer management. It 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

The broadening of the range of services offered by the LTE EPS over time has led to the development of

several specialised sub-types of eNB. Femtocell services, for example, are provided via HeNBs (HomeeNBs), whilst LTE Relay facilities are offered by Relay Nodes and controlled by DeNBs (Donor eNBs).

Further Reading: 3GPP TS36.300

Introduction to LTE



X2

IPData link layer

X2–AP

Physical layer

X2-C

SCTP

X2-U

UDP

IP

Data link layer

User planePDUs

Physical layer

GTP-U


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.




E-UTRAN IPTransport Network

eNode B

eNode B

eNode B

eNode B

eNode B

X2 Interface


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



EPC IPBackbone

eNB

eNB

eNB

eNB

X2 routedvia EPC

X2 connecteddirectly

Logical S1

Logical X2

Physical eNBTransmission

EPC AccessRouter

MME


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




Internet

EPC

MME

S-GW PDN-GW

PCRF

HSS

NAS Security

Idle State Mobility Handling

EPS bearer control

Mobility

Anchoring

IP network


The EPC (Evolved Packet Core)

The reduced complexity in the RAN is mirrored by a similar reduction in the core network, where the EPC

(Evolved Packet Core) 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-GW (Packet 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) is an optional network element. If deployed, it handles

QoS (Quality of Service) and bearer policy enforcement and also provides charging and rating facilities. If

a PCRF is not deployed then some of its functions can instead be performed by the PDN-GW.

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-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.

Introduction to LTE



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


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.




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


Evolved Packet Core ‘S’ Interfaces

In addition to the S1 interface connecting the E-UTRAN to the EPC, a broader range of ‘S’ interfaces

have 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/Gx interface provides access from the PCRF to the PDN-GW.

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.

WLANs (Wireless Local Area Networks) 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.

Further Reading: 3GPP TS23.401:4.2

Introduction to LTE



PDN-GW

PDNConnectivity

Service

Evolved PacketSystem

EPS Bearer

Packet DataNetwork


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), sometimes known

as just a PDN Connection.

This consists of one or more EPS bearer that connect(s) the UE to an Access Point in a PDN-GW andtraverses both the E-UTRAN and the EPC. The PDN-GW routes traffic between the EPS bearer and the

external PDN.

The EPS bearers, in turn, carry a Traffic Flow Aggregate that consists of one or more SDF (Service Data

Flow) connections between the UE and external data services.

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




MCC MNC MMEI

24 bits

GUTIM-TMSI

32 bits

M-TMSI

32 bits

M-TMSI

M-TMSI

32 bits

MMEC

8 bits

S-TMSI


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



PLMN – MCC+MNC

MME Group ID (MMEGI)

Tracking Area ID (TAI)

Evolved Cell ID (ECGI) = eNB ID + Cell ID


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




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


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



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


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.




SECTION 2

LTE OFDM PHYSICAL LAYER





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





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





5 kHz

Spacing to next allocatedcarrier needs to be large

f 1

f 1 f 2


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.




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


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.




High-bit-rate serial stream

S to P

Low bit rate parallel streams

Guardperiod

Useful symbolperiod

Multipath 1

Multipath 1

Multipath 1


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.





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.




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


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.




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


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.




Data subcarriersReference/pilotsubcarriers

Upper

unused/guard

Subcarriers

DCsubcarrier

Lower

unused/guard

Subcarriers


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.




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


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.




Modulation (QPSK/16QAM/64QAM)

Error protection coding rate

Adaptive fast scheduling

Node BPoor Radio Path

Interference


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.




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


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.




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


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.




SU-MIMO MU-MIMO

Multi-Cell MU-MIMO


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.




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


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.




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


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




Channel bandwidths

(bandwidth/subcarriers)

1.4 MHz/72

3 MHz/180

5 MHz/300

10 MHz/600

15 MHz/900

20 MHz/1200


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




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


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




Channel bandwidth (MHz)

Transmission bandwidth configuration (n x RB)

Transmission

bandwidth (n x RB)

12 subcarriers

EARFCN(100 kHz raster)


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




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


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




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


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.





c. 32.5 nsTs =

130,720,000

115,000 x 2048

Ts =

Ts (Time unit) =


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 = 32.5 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




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


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.





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


0 1 2 3 4 5 6

or

00 1 2 3 4 5 0 1 2 3 4 5


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


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




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


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




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


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




Frame

Subframe

Slot

0 1 2 DRS 4 5 6 0 1 2 DRS 4 5 6

0 1 2 DRS 4 5 6 0 1 2 DRS 4 5 6

0 1 2 DRS 4 5 6 0 1 2 DRS 4 5 6

0 1 2 DRS 4 5 6 0 1 2 DRS 4 5 6

0 1 2 DRS 4 5 6 0 1 2 DRS 4 5 6

0 1 2 DRS 4 5 6 0 1 2 DRS 4 5 6

0 1 2 DRS 4 5 6 0 1 2 DRS 4 5 6

0 1 2 DRS 4 5 6 0 1 2 DRS 4 5 6

0 1 2 DRS 4 5 6 0 1 2 DRS 4 5 6

0 1 2 DRS 4 5 6 0 1 2 DRS 4 5 6

0 1 2 DRS 4 5 6 0 1 2 DRS 4 5 6

0 1 2 DRS 4 5 6 0 1 2 DRS 4 5 6


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.




SECTION 3

LTE HIGHER-LAYER PROTOCOLS





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





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





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


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.





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


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.





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


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.





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


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




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


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.





Logical channels

eNB

Scheduling

Multiplexing andprioritization


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).





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


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.





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


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.





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


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




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


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.





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


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.





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)


PDCP Functional Architecture

A PDCP ent ity is created for each SRB and/or DRB on a per-UE bas is. Al l 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.





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


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.





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


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.





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


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.





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


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.





Serviceapplication

Serviceapplication

External PDN

S1-APconnection

EPS bearer

RRCconnection

PDN-GW

S1-APRRC

NAS

MME

eNB

Traffic

S1-APRRC

NAS

Traffic

DRBs

SRBs

NAS


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.





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


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




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


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




eNB

DLInformationTransfer [NAS message]

DCCH/DL-SCH

ULInformationTransfer [NAS message]

DCCH/UL-SCH SRB 2

SRB 2

NAS

MME

RRCRRC

NAS


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.




SECTION 4

MAJOR PROTOCOLS





EPS

IETF 3GPP


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



IETF

SDP

SIP

RTCP

RTP

Diameter

UDP SCTP TCP

Mobile IPDiffServ

Underlying Transport

IPv4/IPv6


IETF Dependence

Many IETF protocols are employed within the EPS and the IMS.

These include:

IP – support for IPv4 and IPv6

UDP – employed at the transport layer in many protocol stacks

TCP – generally only employed on the SGi interface

SCTP – employed on signalling interfaces

Mobile IP – MIPv4, PMIPv6 and DSMIPv6 are variously employed

SIP – employed by the IMS to establish user sessions

SDP – employed within SIP to describe session parameters

RTP – transports user session media flows

RTCP – provides control and feedback for RTP sessions

DiffServ – provides IP QoS services

Diameter – provides secure connections between signalling nodes

Further Reading: 3GPP TS 23.401; 36.300; www.ietf.org




IPv6 EPS

IPv4 EPS

IPv4 Internet

Access Network


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



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


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.


Major Protocols



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


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



S1 -MME

MME Pool

eNB

MME

S1 over SCTP Association

eNB and MME act asSCTP endpoints

MME

MME

MME


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




IP

SCTP

X2-CP (Control Plane)

Data link layer

X2-AP

Physical layer X2

X2AP


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



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


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




SECTION 5

EVOLVED PACKET CORE





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





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




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


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.


Evolved Packet Core



Non-AccessStratum (NAS)

Non-AccessStratum (NAS)

Access Stratum(AS)

Access Stratum(AS)

User Equipment eNode B Evolved Packet CoreUu S1


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.





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)


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.


Evolved Packet Core



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)


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.





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)


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.


Evolved Packet Core



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)


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.





Serving Gateway

(S-GW)

PDN Gateway

(PDN-GW)

Functions could

be combined within

same device

Mobility

Management Entity

(MME)

S5


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.


Evolved Packet Core



PDN-GW

Co-ordinated MME Pool

and S-GW Service Area

E-UTRAN Tracking Areas served by Pools and Areas


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.





RRC

ECM

RRC

EMM

State machines store UEand bearer context data

MME eNB UE

ECM

EMM


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).


Evolved Packet Core



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


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.





MME

UE

ECM-Connected

ECM-Connected

ECM-Idle

ECM-Idle

S1 connection released

S1 connection established

RRC connection released

RRC connection established


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.


Evolved Packet Core



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


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.





S1-MME

MME

eNB

S-GW

S1-U

IP

L2

S1AP

SCTP

L1

L1

UDP

IPL2

User PDU

GTPv1-U


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



L1

UDP

IP

L2

User PDU

GTPv1-U

S1-U

S-GW

EPS IP Transport

Non-guaranteed

PDU delivery via

GTP-U


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)




S-GW 1

MME 1

S-GW 2

MME 2

S-GW 3

MME 3

S1-MME

S1-U

S1-Flex


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.


Evolved Packet Core



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


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




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


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.


Evolved Packet Core



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


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)




Home or

Visited Network

SGSN

MMES3

S10

MME

S-GW

SGSN

S11

S16

PDN-GW

S5

S8

Home Network

PDN-GW

IP

Services

L1

UDP

IP

L2

GTPv2-C


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



MME

HSS

SGSN

EIR

S6a

S13

S6d

L1

TCP/SCTP

IP

L2

Diameter


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.




PDN–GW

Visited PCRF

IMS

Home PCRF

S7/Gx Rx

S9

L1

TCP/SCTP

IP

L2

Diameter


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



MME

MSC/VLR orMSC Server

SGs/Sv

L1

SCTP

IP

L2

SGsAP


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)




UE

MME

PDN-GWS-GW

eNB

EPS Bearer

Radio Bearer

External Bearer

S5/S8 Bearer E-RAB

S1 Bearer

Uu S1 S5/S8


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 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.


Evolved Packet Core



PDN-GWS-GWeNBUE

Internet

IMS

Initial orDefault EPS

Bearer

Subsequent orDedicated EPS

Bearer

Both Bearersrouted viasame APN

Both Bearersshare sameIP address


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 (Access Point Name), 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 could be modified to accommodate the requirements of application

traffic flows when a connection is established. In reality, however, a separate EPS Bearer is established

to carry LTE call media traffic, so the Default EPS Bearer would only need to be adjusted if the level of

SIP traffic exceeded the capacity provided by the original QoS settings.

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 EPS Bearer are

termed Dedicated EPS 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 optional

number of Dedicated Bearers created for each PCS. The 4-bit EPS Bearer ID and the set of reserved IDs

limit the total number of bearers that can be established for one UE to eleven (numbered 5 to 16).


Evolved Packet Core



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


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




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


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.


Evolved Packet Core



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


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.





Bearer Context – Inactive

S5/S8 EPS

Bearer Active

S5/S8 Tunnel

UE eNB S-GW PDN-GW

MME

Bearer Attributes

Radio Bearer/

E-RAB Released


Inactive EPS Bearers and Bearer Contexts

When an EPS Bearer is inactive, either as a result of an instruction from the UE or MME or of an

inactivity timer expiring, Uu and S1-U resources are released, although the S5/S8 tunnel is retained and

details of the bearer context are retained by the UE and the MME for future reactivation when required.

The separation of the bearer resources from the bearer context means that details of each bearer can be

retained by the network even when the physical resources associated with it have been released duringperiods of inactivity.

An inactive bearer context can be reactivated by either the UE or the network using the Service Request

procedure.

The S-GW may invoke the Downlink Data Notification procedure if data arrives for an inactive bearer.

The Bearer Context data held in the UE and the MME may become unsynchronized during periods of

inactivity; both devices will attempt to re-synchronize this data when a signalling connection is

re-established.

An inactive Bearer Context is deemed to be in the ESM BEARER CONTEXT INACTIVE state.

Evolved Packet Core



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

IMS

UE using

E-UTRAN

access

PS traffic

CS traffic


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.




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


CS Fallback

3GPP developed LTE in release 8 as an evolution of previous network models. Given that the IMS was

developed as part of Release 5 it is reasonable to assume that the intention was for LTE to provide CS

(Circuit Switched)-type services via an IMS. An IMS is an extremely complex and expensive network

upgrade, however, and many operators have been resistant to the idea of deploying one.

Arguably, the simplest solution to the problem of providing CS services without necessarily deploying anIMS is to use 3GPP’s CS Fallback service.

CS Fallback allows an LTE 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 may elect or be directed to 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. Those that can’t be handed over will be suspended or released.

CS Fallback can operate in conjunction with IMS-based services or could be used as an interim measure

by an operator that is not yet ready to deploy one.

Further Reading: 3GPP TS 23.272 (CS Fallback)

Evolved Packet Core



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


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)




MME

PDN–GW

SGi

S5

A/Iu

S–GWS1

E-UTRAN

Access

GERAN/UTRAN

Access

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


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.

Although ful ly specif ied, the VoLGA concept failed to att ract significant interest among network

equipment vendors or operators. Although the VoLGA Forum website is (as of early 2012) still

operational no significant additions to the specifications have been made since mid-2010 and theconcept can be assumed to have been discontinued.

Further Reading: 3GPP TS 43.318, 44.318 (GAN); www.volga-forum.com

Evolved Packet Core



Mutual authentication

Authorization

User confidentiality

Ciphering

Integrity protection


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.





MME

UE/USIM

HSS

eNB

XRES

Quintuplet

RAND

AUTN

CK

IK


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



MME

UE/USIM

EPC & E-UTRAN

ISMT-M

IMSI


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.




SECTION 6

LTE OPERATION





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

E-UTRAN KPIs (Key Performance Indicators) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.27

EPC KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.28

CONTENTS

LTE Operation





define the idle mode state for an LTE UE

identify all the key functions and procedures associated with idle mode operation

describe the cell reselection process

define the key radio measurements that are applicable to E-UTRA

describe how measurements are configured for the UE in connected mode

explain the need for and configuration of measurement gaps

describe timing advance adjustment for LTE

describe the process and application of CQI reporting

list and explain the MIMO options for LTE

discuss the reasoning behind the decision to make this a stage in the attach process

describe the activities related to IMS registration

discuss the roles played by various devices involved in EPS device selection outline the set of functions a UE will perform when in idle mode

describe the functions performed by the EPC in support of UEs in Idle Mode

outline the set of activities related to the TAU process

discuss the activities performed to allow UEs to be paged

outline the functions related to ISR (Idle-mode Signalling Reduction)

describe the actions performed by the MME and HSS in support of UE Reachability

discuss the use of the Service Request process and its relationship to the modify and create

bearer functions

list the stages through which the IMS connection establishment process must proceed

outline the processes used to establish CS services for EPS attached subscribers

describe how IMS signalling and media flows are routed and handled

outline the EPC’s support for charging

describe the functions that enable connected mode mobility management to operate

outline the processes employed to support various handover scenarios including intra-E-UTRAN

and inter-RAT HO

describe the procedures employed to detach a UE from the EPS

OBJECTIVES

LTE Operation




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


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).


LTE Operation



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


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.





(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


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 N xRSRP/(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.


LTE Operation



UE

RRC Connected

eNBServing cell

Gap configuration

Quantity configuration

Measurement identities

Reporting configuration

Measurement objects

Measurement Parameters

Neighbour

cells


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.





eNBServing cell

Transmission gap(6 ms)

Transmission gap repetitionperiod (N x 10 ms)

Neighbour cell Neighbour cellNeighbour cell


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.


LTE Operation



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)


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.





Efficiency

(bits/symbol)

0 No TX ... ...

1 QPSK 0.076 0.1523

2 QPSK 0.12 0.2344

3 QPSK 0.19 0.377

4 QPSK 0.3 0.6016

5 QPSK 0.44 0.877

6 QPSK 0.59 1.1758

7 16QAM 0.37 1.47668 16QAM 0.48 1.9141

9 16QAM 0.6 2.4063

10 64QAM 0.45 2.7305

11 64QAM 0.55 3.3223

12 64QAM 0.65 3.9023

13 64QAM 0.75 4.5234

14 64QAM 0.85 5.1152

15 64QAM 0.93 5.5547

CQI Index ModulationApprox. code

rate

Downlink channel

adaptation based on

UE CQI reporting

Uplink channel adaptation based on

eNB measurements of UL data

transmissions and SRS if requested


CQI Reporting

Link adaptation is a crucial part of the LTE air interface and involves the variation of modulation and

coding schemes to maximize throughput on the air interface.

Link adaptation for scheduled uplink resources can be can be calculated by the eNB from a number of

different inputs based on measurements of a UE’s uplink transmissions. Additionally the eNB may

request that UEs transmit sounding reference signals, the measurement results of which can also beused for link adaptation.

For downlink transmissions the eNB needs information about the success or otherwise of the UE in

receiving its downlink transmissions. The UE assesses the quality of the downlink signal through

measurements of the received signal and consideration of the error correction scheme. It then calculates

the maximum modulation and coding scheme that it estimates will maintain an error rate better than 10%.

This is indicated to the eNB as a CQI (Channel Quality Indicator) value. The table in the diagram (taken

from the 3GPP standards) shows how the CQI values are interpreted as modulation and coding

schemes. The table is also useful for estimating the likely physical layer throughput in a given radio

configuration.


LTE Operation



Transmit Diversity Beamforming

Closed loop with PMI feedback

SU-MIMO (ranks up to 4)MU-MIMO (virtual MIMO)


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




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


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.


LTE Operation



UE eNB MME S-GW PDN-GW HSSPCRF

6. Create SessionRequest

7. PCC

Lookup

Optional Stage

8. Create SessionResponse

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


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.





ECM StateEPS Bearer ID

QoS

TA 9

TA 12

MME Pool A

UE TA List UE Default Bearer

Context – Inactive

TA 9TA 12


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.


LTE Operation



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


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



S1 Pagingmessages

TA 9

TA 12

UE TA List

TA 9TA 12


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




S-CSCF

UE EPS

Re-registration causes:

Change of IP Address

Change of PDN-GW

Expiry of Registration Timer


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.


LTE Operation



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


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.






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


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).


LTE Operation




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


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.






1. Trigger event

2. Request Bearer

Resource Modification 3. Request Bearer

Resource Modification

4. PCC Lookup

Optional Stage

5. Create Dedicated

Bearer Request

6. E-RAB Setup Request/

EPS Bearer Activation Request7. RRC Conn

Reconfig

7. RRC Conn

Reconfig

Complete8. Bearer Setup

Response

9. Direct Transfer

10. Activate

EPS Bearer Response11. Create Dedicated

Bearer Response 12. IP-CAN Session

Modified

Data Flow


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.


LTE Operation



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


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).





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


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.


LTE Operation



Intra-E-UTRAN Inter-S-GW Inter-MMEInter-system Non-3GPP


Connected Mode Procedures

Mobility management functions related to UEs in the ECM-CONNECTED state with active EPS Bearers

and service data flows can be summarized as follows:

intra-E-UTRAN handover

intra-E-UTRAN handover with S-GW relocation

intra-E-UTRAN handover with MME relocationInter-RAT handover

E-UTRAN-Non-3GPP Access Handover





UE SourceeNB

MME S-GW PDN-GWTargeteNB

1. Uplink and downlink data flow

Optional Stage

2. Handover Preparation

2. Handover Execution including new S1 tunnel creation

3. X2 Direct Forwarding

3. Uplink Data

4. Path Switch

Request 5. User Plane

Update Request

6. UE locationinformation updated

7. User Plane

Update Response

8. Downlink Data

9a. End Markers

9b. End Markers forwarded,

X2 data forwarding ends 10. Path Switch

Request Ack11. Release

Resources


Intra-E-UTRAN Handover (X2-based)

In this scenario a UE with active EPS bearers initiates the inter-eNB cell handover procedure when both

source and target eNBs are associated with the serving MME and S-GW and an X2 path can be

established between them.

At the start of the process the UE is connected to the E-UTRAN and is taking neighbour cell

measurements (1). Traffic may or may not be flowing over the connected EPS Bearers. A neighbour cellachieves the criteria necessary for the UE to initiate handover, which is effected by the source and target

eNBs without core network involvement beyond the establishment of S1 resources towards the target

eNB (2).

Once the handover is complete the source eNB forwards any further downlink traffic received for the UE

to the target eNB either directly via the X2 interface (3); this is termed Direct Forwarding. Uplink traffic

travels from the target eNB to the S-GW via the newly established tunnel. The target eNB sends a Path

Switch Request to the MME informing it of the handover (4).

The MME determines that the existing S-GW is still capable of serving the UE and instructs it to switch

the Downlink user plane over to the tunnel created towards the new cell using a User Plane Update

Request message (5). If the PDN-GW has indicated that needs to be kept informed of the UE’s location(for variable charging purposes), the S-GW informs it using an Update Bearer Request (6).

The S-GW realigns the tunnel carrying the EPS bearer(s) to point to the target eNB and sends

confirmation to the MME that the path has been switched successfully (7); both uplink and downlink

traffic now travels over the new S1 tunnels (8). The S-GW sends ‘end marker’ packets to the source eNB

to confirm that the path has been switched, which are forwarded to the target eNB to indicate that X2

forwarding will cease (9).

The MME confirms the procedure to the new eNB with the Path Switch Request Ack message (10) and it

in turn confirms the handover to the old eNB using the Release Resource message (11).


LTE Operation



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


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).





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


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



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


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.




E-RAB Accessibility

E-RAB Retainability

E-UTRAN IP Throughput

E-UTRAN IP Latency

E-UTRAN Cell Availability

E-UTRAN Mobility

E-UTRAN Key

Performance

Indicators (KPIs)

Further reading:3GPP TS 32.450


E-UTRAN KPIs (Key Performance Indicators)

E-RAB Accessibility

This KPI shows the probability for an end-user to be provided with an E-RAB at request. It is calculated

by comparing successful attempts with the total number of attempts for the different parts of the E-RAB

establishment.

E-RAB RetainabilityThis is a measurement that shows how often an end-user abnormally looses an E-RAB during the time

the E-RAB is used.

E-UTRAN IP Throughput

This KPI indicates how the E-UTRAN impacts the service quality provided to an end-user. It is a measure

of the payload data volume at the IP level per elapsed time unit on the Uu interface. To achieve a

throughput measurement that is independent of file size, it is important to remove the samples where one

TTI on the radio interface is not utilized.

E-UTRAN IP Latency

This is a measurement that indicates how the E-UTRAN impacts on the delay experienced by an end-

user.

E-UTRAN Cell Availability

This indicates the availability of an E-UTRAN Cell. It is the percentage of the time that the cell is

considered available.

E-UTRAN Mobility

This KPI indicates how the E-UTRAN Mobility functionality is working and defines the success rate of E-

UTRAN handovers. The measurement includes both Intra E-UTRAN and Inter RAT handovers. Both the

preparation and execution phase of the handover is included.

LTE Operation



Inter-RAT Incoming Handover Success Rate(UMTS ->EPS)

Inter-RAT Incoming Handover Success Rate(CDMA2000->EPS)

Tracking Area Update Success Rate

Mean Active Dedicated EPS Bearer Utilization

Inter-RAT Incoming Handover Success Rate(GSM->EPS)

EPC Key

Performance

Indicators

(KPIs)

Further reading:3GPP TS 32.455


KPIs (continued)

Inter-RAT Incoming Handover Success Rate (GSM EPS)

This KPI describes the ratio of the number of successfully performed incoming handover procedures to

the number of attempted incoming handover procedures to evaluate inter RAT incoming handover

performance from a GSM network.

Inter-RAT Incoming Handover Success Rate (UMTS EPS)This KPI describes the ratio of the number of successfully performed incoming handover procedures to

the number of attempted incoming handover procedures to evaluate inter RAT incoming handover

performance from a UMTS network to the EPS.

Inter-RAT Incoming Handover Success Rate (CDMA2000 EPS)

This describes the ratio of the number of successfully performed incoming handover procedures to the

number of attempted incoming handover procedures to evaluate inter RAT incoming handover

performance from a CDMA2000 network.

Tracking Area Update Success Rate

This KPI describes the ratio of the number of successfully performed tracking area update procedures to

the number of attempted tracking area update procedures and is used to evaluate mobility provided bythe EPS and network performance.

Mean Active Dedicated EPS Bearer Utilization

This KPI describes the ratio of the mean number of active dedicated EPS bearer to the maximum

number of active dedicated EPS bearers provided by EPC network, and it is used to evaluate utilization

performance of the EPC network.

LTE Operation



APPENDIX

LTE ADVANCED





IMT-Advanced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.1

Evolution to LTE-A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.2

LTE-Advanced Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.3

LTE Frequency Bands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.4

Carrier Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.5

Carrier Aggregation Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.6

CA Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.7

UE Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.8

UE Bandwidth Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.9

CA Operating Bands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.10

PCells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.11

SCells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.12

Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.13

Handovers with CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.14

MIMO Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.15

User Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.16

Relaying for LTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.17

R10/R11 Data Handling Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.18

Co-ordinated Multipoint (CoMP) Transmission/Reception . . . . . . . . . . . . . . . . . . . . . . . . . . .A.19

SON Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.20

CONTENTS

LTE Advanced





describe the requirements for 4G networks specified by the ITU IMT-Advanced guidelines

identify where LTE-Advanced sits within the progression of 3GPP specification Releases

outline the basic functionalities that were added to LTE in releases 10 and 11 to create LTE-

Advanced

identify some of the more important frequency bands in which LTE use has been specified

describe the basic functionality of LTE-Advanced Carrier Aggregation

outline the differences between Inter- and Intra-Band Carrier Aggregation and describe the

various types of symmetrical/asymmetrical configuration that are possible

describe the meaning of CA-related terms such as Carrier Aggregate, Aggregated Channel

Bandwidth, Transmission Bandwidth and Aggregate DC Subcarrier

outline the roles played by configuration descriptors such as the CA Bandwidth Class, UE

Categories, CA Operating Bands and Supported Bandwidths identify the key functions and main differences between PCells and SCells as employed in

Carrier Aggregation

describe the enhancements made to LTE’s spatial multiplexing or MIMO functionalities in

Release 10

outline the purpose of the LTE Relay and describe the basic elements of this concept

outline the functionality of some of the other key Release 10 LTE features such as LIPA, SIPTO,

MRA and IP Flow Mobility

describe the basic concept that underpins the Release 11 CoMP (Co-ordinated Multi-Point)

feature

outline some of the enhancements made in Release 10 to the SON (Self Optimising Network)

concept

OBJECTIVES

LTE Advanced




a high degree of commonality of functionality worldwide while retaining

the flexibility to support a wide range of services and applications in a

cost-efficient manner

compatibility of services within IMT and with fixed networks

capability of interworking with other radio access systems

high quality mobile services

user equipment suitable for worldwide use

user-friendly applications, services and equipment

worldwide roaming capabilityenhanced peak data rates to support advanced services and applications

(targets of 100 Mbit/s for high mobility and 1 Gbit/s for low mobility)

Key features of IMT-Advanced:

International

Mobile

Telephony

LT3600/v3.2 A.1© Wray Castle Limited

IMT-Advanced

The ongoing design and implementation of cellular systems is pushed forward by equipment vendors,

network operators and, in most cases, international specifications bodies such as 3GPP. A degree of

central guidance to this process is provided by the ITU, a branch of the United Nations responsible for

attempting to harmonize the standards and techniques employed in worldwide telecoms systems.

The ITU set out its vision for 3G cellular systems at the end of the 1990s by devising a framework knownas IMT-2000, although the 3G market ended up consisting of several competing technological platforms

all of them ultimately adhered to the guidelines espoused by the ITU.

The ITU created a similar framework of expectations for emerging 4G technologies in 2007 with the initial

publication of the IMT-Advanced guidance.

Instead of specifying a particular technology or mandating the functionality of a 4G system, the IMT-

Advanced guidelines proposed the basic set of capabilities that a system should be able to support for it

to be regarded as being a true ‘4G’ system.

In addition to the aspirations outlined in the diagram, the ITU (in ITU-R report M.2134) also provided

some more definite technical requirements for 4G systems, including: that an IMT-Advanced systemshould be able to accommodate radio channels of at least 40MHz in bandwidth; that their peak spectral

efficiency should meet or exceed 15bits/Hz in the downlink and 6.75bits/Hz in the uplink; that it should

support latencies of less than 100ms for control-plane connections and less than 10ms for the user-

plane.

It should be noted that the original (Release 8) version of LTE did not meet the full set of IMT-Advanced

requirements, mainly due to its inability to support 1 Gbit/s data connections. To date only Release 10

LTE-Advanced and the updated version of Mobile WiMax (IEEE 802.16m) have been accepted as fully

compliant with IMT-Advanced.

Further Reading: www.IMT-2000.org (ITU website), ITU-Report M.2134

LTE Advanced



GSM900 GSM1800

GSM1900

GPRS

EGPRS

UMTS HSDPAIMS

HSUPA HSPA+

EDGE Evolution

LTE/SAE

Phase 1 Phase 2 Phase 2+

Rel 96-98



Rel 8 Rel 9


GSMGPRS

GERAN enhancements

UMTS/SAE UTRAN enhancements



LTE-A

LT3600/v3.2 A.2 © Wray Castle Limited

Evolution to LTE-A

LTE-Advanced constitutes 3GPP's response to IMT-Advanced and was first described in 3GPP Release

10 documents, with additional functionality specified in Releases 11 and 12.

Basic LTE functionality was described in Releases 8 and 9 and most of the techniques developed to

support that first version of LTE are still employed in LTE-Advanced.

The main features of LTE-Advanced are Carrier Aggregation, enhanced MIMO features and the use of

LTE Relays, all of which are firmly based on Release 8 foundations.

LTE and LTE-Advanced were not the only topics covered by Releases 8, 9, 10 and 11 – both GSM and

UMTS continue to be provided with updates and enhancements that enable them to remain relevant and

up-to-date in a 4G world.

Further Reading: www.3GPP.org/releases




extension of LTE into new radio bands

Carrier Aggregation

enhanced Uplink and Downlink MIMO capabilities

relays for LTE

enhanced Self Optimizing Network (SON) capabilities

additional interference control techniques

evolved data handling options for Femtocell and WiFi interworking:

local IP Access (LIPA)

selected IP Traffic Offload (SIPTO)

managed Remote Access

IP Flow Mobility

Access Network Discovery and Selection Function (ANDSF)

Release 10 LTE Features:

extension of Carrier Aggregation to more radio bands

extension of LTE to additional radio bands

additional carrier types for Carrier Aggregation

support for Diverse Data Applications

enhancements to interference control techniques

enhanced techniques for LTE Relays

enhanced techniques for MBMS

study into Co-ordinated Multi Point (CoMP) Operation



LTE-Advanced Features

Basic LTE-Advanced functionality was first described in 3GPP Release 10 specifications, with the more

detailed and enhanced functionality held over to Release 11.

Release 10 functions include: Carrier Aggregation, which allows a UE to be scheduled with data-carrying

capacity on up to five parallel cells simultaneously; enhanced MIMO techniques that allow a UE to make

use of up to 8 MIMO layers on a downlink and up to 4 layers on an uplink; additional types of MIMO for uplink connections; the extension of LTE into a variety of new radio bands; enhancements to the SON

concept; and a range of data-handling improvements such as LIPA (Local IP Access) and SIPTO

(Selective IP Traffic Offload).

Release 11 introduced only one significant new feature, known as CoMP, and mainly concentrated on

adding more depth and complexity to existing R10 services.

Detailed information about the work and study items scheduled for each release are contained in the

relevant 3GPP Release Description documents, which provide a regularly-updated view of the work

being undertaken, or that has been completed, for each release.

Further Reading: http://www.3gpp.org/ftp/Information/WORK_PLAN/Description_Releases/

LTE Advanced



FDD


1 1920 – 1980 2110 – 2170

2 1850 – 1910 1930 – 1990

3 1710 – 1785 1805 – 1880

4 1710 – 1755 2110 – 2155

5 824 – 849 869 – 894

6 830 – 840 875 – 885

7 2500 – 2570 2620 – 2690

8 880 – 915 925 – 960

9 1749.9 – 1784.9 1844.9 – 1879.9

10 1710 – 1770 2110 – 2170

11 1427.9 – 1447.9 1475.9 – 1495.9

12 698 – 716 728 – 746

13 777 – 787 746 – 756

14 788 – 798 758 – 768

... ... ...

17 704 – 716 734 – 746

18 815 – 830 860 – 875

19 830 – 845 875 – 890

20 832 – 862 791 – 821

21 1447.9 – 1462.9 1495.9 – 1510.9

2223

24

25

3410 – 34902000 – 2020

1626.5 – 1660.5

1850 – 1915

3510 – 35902180 – 2200

1525 – 1559

1930 – 1995

TDD


33 1900 – 1920

34 2010 – 2025

35 1850 – 1910

36 1930 – 1990

37 1910 – 1930

38 2570 – 2620

39 1880 – 1920

40 2300 – 2400

41 2496 – 2690

42 3400 – 3600

43 3600 – 3800


LTE Frequency Bands

LTE was originally allocated the previously little-used 2600MHz band (now known as Band VII) but as

additional frequency bands were proposed, 3GPP devised a band numbering system to regulate and

regularize frequency allocations.

Most of the bands defined for LTE use have previously been used to support 2G and/or 3G network

services, this includes Band I (used for UMTS2100), Band VIII (used for GSM900) and Band XX(terrestrial analogue TV).

Separate band definitions have been made for LTE’s FDD and TDD variants, although many of these

bands overlap or employ the same frequency ranges.

3GPP accepts proposals to extend LTE into new frequency bands at each plenary session, so the list

shown in the diagram is subject to being updated. The full list of defined bands is shown in 3GPP

Technical Specification TS36.101, which can be downloaded from the 3GPP website. The list shown in

the diagram is current up to the version of TS shown.





Cell A

Cell B

Cell C

Cell D

Cell E

Secondary Component Carrier

Primary Component Carrier




Component Carriers are classified as DL CCs or UL CCs

A PCell is always carried by paired DL CC and UL CC

An SCell is always carried by a DL CC which may or

may not be paired with an UL CC

SCell–PCell– Primary Serving Cell – there will be

one PCell per UE per carrier

aggregate. The PCell is bidirectional.

Secondary Serving Cell – a carrier

aggregate may consist of between one and

four SCells, the number allocated to a UE

may vary over time. An SCell may be

bidirectional or unidirectional (Downlink only)

The term ‘Component Carrier’ is used to describe either case in this text


Carrier Aggregation

CA (Carrier Aggregation) is the most prominent feature of Release 10 LTE-Advanced. It offers an inverse

multiplexing facility that allows a UE to substantially increase the overall data rate it can achieve by

allowing an eNB to schedule capacity for it on multiple cells (or 'carriers') simultaneously.

Each carrier (either downlink or uplink) assigned for use by a UE is known as a CC (Component Carrier)

and the set of CCs allocated to a UE at any one time forms a Carrier Aggregate. R10 CA permits up tofive CCs to be bound into a Carrier Aggregate, potentially providing a suitably-equipped UE with up to

100MHz of bandwidth and an aggregate downlink data rate of over 3Gbit/s.

The lowest level of carrier aggregation allows a UE to connect via just one cell. The radio connectivity of

this cell is described as the PCC (Primary Carrier Component) and the cellular service it offers is known

as the PCell (Primary Serving Cell). The PCell carries NAS and RRC services for a UE and is also the

carrier measured by the UE to support functions like quality feedback and handover measurements.

A Release 8/9 UE (or an R10 UE that didn’t require CA services) would just connect via the PCell and

would not be assigned any additional carriers. An R10, CA-capable UE that did require a CA service

would be scheduled with capacity on between one and four SCells (Secondary Serving Cells), each of

which would be carried by an SCC (Secondary Component Carrier).

The PCC and any SCCs aggregated to provide a CA service for a UE must all be under the control of the

same eNB, but the terms ‘primary’ and ‘secondary’ used in relation to CA carriers are determined from

the point of view of each UE – different UEs in the same area may have selected different cells to be

their PCell and may therefore regard an assigned cell as an SCC which may be employed by another UE

as a PCC.

A PCell is always used in a bidirectional manner, as befits the cell that carries NAS and RRC traffic, but

an SCell may be used in either a bidirectional or unidirectional manner depending upon local

configuration and current requirements. If an SCell is used unidirectionally then it is only able to operate

in 'downlink-only' mode, there is no provision for cells to operate in 'uplink-only' mode.

LTE Advanced



Band A Band BUplink Downlink Uplink Downlink

PCell

Symmetrical CC, Asymmetric Bandwidth

Configuration SCell1

Inter-Band


Symmetrical CC andBandwidth ConfigurationPCell

PCell

No CA

PCells must always besymmetrical with both

an uplink and downlinkScell 1

Scell 2

Inter-Band -Contiguous

Asymmetrical CCConfiguration

PCell

SCell

2

SCell

1

Band A Band BUplink Downlink Uplink Downlink Inter-Band -

Non-Contiguous


Carrier Aggregation Options

Carrier Aggregation in LTE-Advanced has been designed to operate with as much configurational

flexibility as is practical; there is flexibility in the way in which channel aggregates can be spread across

frequency bands and there is also flexibility in the symmetry that can be employed by SCCs.

Frequency band options are classified as:

Inter-Band – where the component carriers in an aggregate can belong to two or even three differentfrequency bands

Intra-Band Contiguous – where the CCs must belong to the same frequency band and must be

contiguous (i.e., adjacent to each other) within that band

Intra-Band Non-contiguous – where the CCs must belong to the same frequency band but are not

required to be contiguous within that band (i.e., they may be spread out across the band)

The symmetry applied to a channel aggregate can vary in terms of the numbers of uplinks and downlinks

and also in terms of the bandwidths of those uplinks and downlinks.

A PCell must always be symmetrical in terms of its uplink and downlink, but the bandwidth allocated to

each may vary. UEs that do not support or that do not require CA connections only make use of a PCell

and will therefore always receive a service that is symmetrical in terms of CC configuration.

An SCell can be configured with symmetrical or asymmetrical Component Carriers; symmetrical CC

configuration means that the SCell employs both an uplink and a downlink, whilst asymmetrical CC

configuration would employ just a downlink, it is not possible to configure an SCell to operate in an ‘uplink

only’ manner.

Asymmetrical bandwidth al locations are possible for both PCells and SCells and are typically

characterized by configuring the cell’s downlink channel to occupy a larger bandwidth than its uplink. An

example of this might be a cell with a 20MHz downlink but only a 5MHz uplink. Such configurations are

used to reflect the asymmetric nature of typical user demand, in which more data is downloaded than is

uploaded.

Further Reading: 3GPP TS36.300:Annex J, 36.807:Annex A




Lower guard

subcarriers

Aggregated Channel

Bandwidth (25 MHz)

Upper guard

subcarriers

Aggregated Channel

Transmission Bandwidth (25 MHz – guard bands)

Lowest CC Highest CC

10 MHz Carrier

Transmission Bandwidth

5 MHz Carrier


DC Subcarrier

Must be a multiple of 300kHz

10 MHz Carrier Bandwidth

5 MHz Carrier

Bandwidth 10 MHz Carrier Bandwidth

DC Subcarrier DC Subcarrier

10 MHz Carrier



CA Terminology

Carrier Aggregation operates by allowing an eNB to schedule uplink and downlink capacity for a UE

across a set of component carriers that have been combined to form an Aggregated Channel.

The total bandwidth occupied by the Aggregated Channel is termed the Aggregated Channel Bandwidth

and includes all used and unused subcarriers; unused subcarriers are generally those set aside to act as

guard bands at the upper and lower end of each CC. The net usable bandwidth of the AggregatedChannel (which is total bandwidth less all guard subcarriers) is termed the Aggregated Transmission

Bandwidth.

Due to the requirements imposed by OFDMA, each CC will still need to have its centre-frequency left

unused to act as a DC Subcarrier. To ensure that orthogonality is maintained between subcarriers across

an entire aggregated channel, the DC Subcarriers of all CCs within the aggregate must be spaced at

multiples of 300kHz from each other. The number of guard subcarriers employed at the top and bottom

ends of each CC may be adjusted to accommodate this spacing requirement if necessary.

In a contiguous aggregated channel (i.e., one in which all CCs are adjacent to each other) the DC

subcarrier of the central CC will be used as the baseband transmission DC Subcarrier for the entire

aggregate. For this reason, it is recommended that aggregate channels are created in a ‘balanced’manner, as shown in the diagram. The total 25MHz aggregated channel bandwidth in the diagram has

been created by aggregating 2x10Mhz and 1x5MHz CCs, but to balance this aggregate the 5MHz CC

has been placed in the centre and its DC Subcarrier will be used for the entire aggregated channel.

Un-balanced configurations are also possible – a 25MHz channel aggregate could be created by

combining CCs in a 10+10+5 pattern, for example – but in these cases the aggregate DC Subcarrier

must be created by using whichever ‘transmission’ subcarrier happens to be at the centre frequency of

the aggregate.

In non-contiguous aggregates (like those employed in inter-band configurations), each contiguous

section of the aggregate will require its own aggregate DC subcarrier.

Further Reading: 3GPP TS36.807:5.6A & 5.7, 36.104:5.7.1A

LTE Advanced



UE Category

Feature

Peak DL data rate (Mbit/s)

Peak UL data rate (Mbit/s)

Highest DL modulation scheme

Highest UL modulation scheme

Max DL MIMO layers

Release 8/9

1 2 3 4 5

10 50 100 150 300

5 25 50 50 75

64QAM 64QAM 64QAM 64QAM 64QAM


1 2 2 2 4

Transmission Parameter

UE Category Release 10

6 7 8

300 300 3000

50 100 1500

64QAM 64QAM 64QAM

16QAM 16QAM 64QAM

2 or 4 2 or 4 8


UE Categories

The cost of LTE UEs is partly determined by the sophistication of the set of functions that each can

perform. Only a limited subset of UEs will be designed to take advantage of the maximum possible

capabilities of an LTE network. It is therefore necessary to allow each UE to signal its capabilities to the

network to allow the services offered to be tailored to its abilities.

UE capabilities are signalled in RRC message IEs and are classified into UE Categories.

Release 8/9 UEs have capabilities – those that relate to ‘standard’ LTE access – that place them in UE

Categories 1-5, these are signalled in the UE-EUTRA_Capability IE.

Release 10 UEs may have capabilities that relate to LTE-Advanced access which place them in UE

Categories 6-8, these are signalled in the UE-EUTRA-Capability-v10 IE.

A Release 8/9 UE with UE Category 5 can, in theory, achieve data rates of up to 300MBit/s in the

downlink and 150MBit/s in the uplink using 64QAM modulation in both directions and up to 4 layers of

downlink MIMO.

A Release 10 UE with a UE Category of 8 can, in theory, achieve data rates of 3000MBit/s downlink and1500MBit/s uplink using 64QAM in both directions, up to 8 MIMO layers in the downlink and up to 4 in the

uplink. The use of CA with 4 SCells to achieve these data rates is implicitly indicated as they wouldn’t be

possible otherwise.

Both UE-EUTRA-Capabilities signal a large number of other parameters in addition to UE Category and

other IEs are also employed to carry UE configuration and capability information.

Further Reading: 3GPP TS36.306:4.1 (UE-Category IE), 36.331:6.3.6 (UE-EUTRA-Capability)




Carrier Aggregation

Bandwidth Class

Aggregated

Transmission

Bandwidth (in RBs)

Maximum number of

Component Carriers

Maximum possible

aggregate channel

bandwidth:

A 1 20 MHz

B 20 MHz

C 40 MHz

D 60 MHz

E 80 MHz

F 100 MHz

Correct as per TS36.101 v10.2.1

Classes D-F are classed by 3GPP as ‘for further study’ so the

values shown here are provisional and may be subject to change

1 x PCell

N RB_agg = Number of Resource Blocks in Aggregated Channel

2

2

3

4

5

1 x PCell

1 x SCell

1 x PCell

1 x SCell

1 x PCell

2 x SCell

1 x PCell

3 x SCell

1 x PCell

4 x SCell

NRB_agg = 100

NRB_agg = 100

100 =NRB_agg = 200

200 =NRB_agg = 300

300 =NRB_agg = 400

400 =NRB_agg = 500


UE Bandwidth Classes

The level of Carrier Aggregation that is supported by a UE is determined by its Bandwidth Class.

Each Bandwidth Class describes the level of CA capabilities supported by a UE, it includes descriptions

of the maximum number of Resource Blocks that a UE can use simultaneously and the maximum

number of Component Carriers (with each CC classed as an uplink/downlink pair whether the uplink is

actually used or not) the UE can access simultaneously. The largest channel bandwidth available in R10is 20MHz, so the maximum number of CCs parameter implicitly identifies the maximum operational

bandwidth a UE could be assigned.

Bandwidth Class A devices do not support CA, so this classification would be used to describe all

Release 8/9 UEs and any Release 10 devices that do not require CA capabilities. Class A devices are

able to access up to 100 Resource Blocks on a 20MHz channel in a PCell only and will not be able to

access any SCells. Examples of Bandwidth Class A devices might include voice-only LTE terminals and

devices designed to support low-bandwidth data applications such as smart utilities meters.

Bandwidth Classes B and upwards support increasing levels of aggregation capability. Class B devices

are also limited to using up to 100 RBs but may be assigned one SCell in addition to the PCell. The 100

RB limit means that although a Class B device is able to access two CCs it would not be able to accesstwo 20MHz CCs, as that would entail processing 200 RBs.

Bandwidth Class C devices are able to handle up to 200 RBs and two CCs and would therefore be able

to be assigned to, for example, a 20MHz PCell and a 20MHz SCell, although other channel

configurations are also possible.

As of v10.2.1 of TS36.101, the 3GPP specification that describes Bandwidth Classes, classes D-F had

parameters assigned to them but were described as being FFS (For Further Study), so the parameters

shown in the diagram are only provisional and may be subject to change by later versions of the

document. However, the maximum capability for a Class F device is likely to be up to five CCs covering a

maximum of 100MHz and using up to 500 RBs.

Further Reading: 3GPP TS36.101:5.6A

LTE Advanced



Intra-Band

Supported CC

Bandwidths

Intra-Band operating

bands are designated

using a prefix of ‘CA’ and

a suffix that shows the

LTE EUTRA band number

Supported Bandwidths show

which size(s) of CC have so far

been specified for CA use within

each Operating Band

Band

E-UTRA

Band

UL Operating Band DL Operating Band Duplex

ModeStart End Start End

CA_1 1 1920 MHz 1980 MHz 2110 MHz 2170 MHz FDD

CA_40 40 2300 MHz 2400 MHz 2300 MHz 2400 MHz TDD

Y Y

Y Y Y

E-UTRA CA

5 824 MHz 849 MHz 869 MHz 894 MHz

Intra-Band

Supported CC

Bandwidths

Band

E-UTRA

Band



CA_1-51 1920 MHz 1980 MHz 2110 MHz 2170 MHz

FDDY

Y

E-UTRA CA

Inter-Band operating

bands are designatedusing a prefix of ‘CA’ anda suffix that shows the

numbers of the LTEEUTRA bands employed Details correct for TS36.101 v10.2.1


CA Operating Bands

The use of Carrier Aggregation in a given frequency band requires a number of parameters to be agreed

and specified to ensure interoperability between operators and vendors.

In Release 10, 3GPP concentrated on ensuring that a minimum level of functionality was available by

specifying CA services for just three Operating Bands. Intra-Band operation in Band 1 (2100MHz FDD)

and Band 40 (2.3GHz TDD) was specified as was Inter-Band operation across a combination of Band 1(2100MHz FDD) and Band 5 (upper 800MHz FDD).

Further to this, parameters for only a limited set of CC bandwidths were developed in each operating

band. Intra-Band operation was initially only specified for Bandwidth Class C devices (so the supported

bandwidths shown in the diagram would be described as CA_1C and CA_40C) and Inter-Band operation

was only described for Bandwidth Class A devices (giving a designation of CA_1A-5A).

Expansion of the set of operating bands and supported bandwidths to encompass a wider range of

bands and channel sizes was agreed as a major focus of Release 11 and Release 12 activities.

Further Reading: 3GPP TS36.101:5.5A & 5.6A.1




Cell A

PCell

The PCell assigned to a UE is a

standard LTE serving cell – all signalling

traffic travels via the PCell and all UE

signal quality measurements are made

on the PCell

A UE’s current PCell is

assigned Serving Cell Index 0

During handover or reselection a newPCell is selected for the UE


PCells

A PCell, or Primary Serving Cell, is essentially the same as a standard R8/9 LTE cell.

A UE, whether it supports R8/9 or R10, will undertake the same Idle Mode and cell selection procedures

when active and will camp on a serving cell from the set locally-available based on signal quality and

strength indicators. Once a cell has been selected and the UE has camped on it, it becomes that UE’s

PCell. The current PCell is always assigned Serving Cell Index 0 by the UE.

A UE will only monitor the BCCH of a PCell, any system information required to access an SCell will be

provided to the UE using dedicated RRC signalling during SCell Addition or Modification.

An Idle Mode UE will monitor the PCell’s paging channel and will use measurements taken of the PCC

as the basis for idle mode reselection actions. If necessary, the UE will use PCell’s RACH to transmit

Service Requests to initiate a move to Connected Mode (moving from ECM-Idle to ECM-Connected).

A UE in Connected Mode will initially use the resources of the PCell; all RRC and NAS transactions take

place via the PCell and any ciphering applied to established traffic and control channels will be based on

the ciphering calculated for the PCell. The UE will send Uplink Capacity requests via the PCell PUCCH

(Physical Uplink Control Channel) and will monitor the PCell PDCCH (Physical Downlink ControlChannel) for downlink capacity notifications and uplink scheduling grants.


LTE Advanced



DL/UL-SCH

Transmitted Data

DL/UL-SCH

Transmitted Data

DL/UL-SCH

Transmitted Data

DL/UL-SCH

Transmitted Data

DL/UL-SCH

Transmitted Data

PUCCH

Scheduling

Requests

PDCCHDownlink Assignments

Uplink Grants(Cross-Carrier

Scheduling enabled)

With ‘cross-carrier scheduling’activated all downlink/uplinkcapacity notifications are carriedby the PCell PDCCH

If ‘cross-carrier scheduling’ is not

activated each SCell’s PDCCHwill carry cell-specific capacitynotifications

SCell 4

SCell 3

SCell 2

SCell 1

PCell


Scheduling

Scheduling for all forms of LTE is managed via the PDCCH.

For R8/9 UEs and for R10 UEs that either don't support CA or that do not currently have CA activated,

only the PCell's PDCCH will carry relevant scheduling information.

For R10 UE’s with CA activated and SCells assigned, there are two scheduling information options,depending upon whether cross-carrier scheduling has been enabled.

Cross-carrier scheduling allows scheduling notifications for one or more SCells to be carried by the

PDCCH of another active cell, typically the PCell. In such cases the capacity notification will indicate

details of the capacity granted plus the index of the intended CC. The typical benefit of cross-carrier

scheduling is that it allows a UE to monitor just one PDCCH to get access to all of its capacity

notifications. Cross-carrier scheduling is not an option for the PCell, whose capacity notifications are

always carried on its own PDCCH.

If cross-carrier scheduling is not enabled for an SCell then capacity notifications for that cell will be

carried on its own PDCCH.

Cross-carrier scheduling can be enabled or disabled on an SCell by SCell basis, based on an option in

the RRC SCell Addition and Modification messages, meaning that a UE could in theory have it enabled

for some cells in its CA set but not for others.

Whatever its complexities, LTE-Advanced Carrier Aggregation can ultimately be seen as an exercise in

multi-carrier scheduling and its success or otherwise in an individual vendor's equipment will be

determined by the efficiency of the scheduling algorithm they have developed.


LTE Advanced



PCell

The target eNB may not support CA or

may have fewer available SCells. In

either case the UE may not be able to

achieve the same data rates as were

available before the handover

SCell 1

SCell 2

Source eNB

CA enabled

Target eNBCA not enabled

PCell

Details of current SCell allocations for

the UE and the availability of SCells at

the target eNB may or may not be

exchanged during handover preparation

During a handover or reselection a new

PCell is selected to serve the UE


Handovers with CA

When in ECM-Connected, a UE will take neighbour measurements in an attempt to find a handover

candidate to use as a new Pcell, if the measurements of the current serving cell fall below a set

threshold.

If the handover process is invoked, the source eNB will hand PCell responsibilities over to the target cell.

The target cell may or not belong to the same eNB as the source cell and there is no reason why a new

PCell could not have previously have been one of the UE’s assigned set of SCells. The cells available to

be aggregated for a UE all need to belong to the same eNB but do not necessarily need to cover exactly

the same area. It is possible, for example, that the cells in an aggregate may be a mixture of macro cells

and LTE relay cells, or the cells involved may be designed to cover pratically overlapping areas. In both

of these cases a UE may well determine that a cell currently being used as an SCell might offer better

service than the current PCell, in which case a handover and a reassignment of SCells may be triggered.

When the handover process is invoked for a UE the number of SCells assigned by the source eNB may

or may not be replicated in the target eNB, depending upon local configuration and capacity limitations.

Further Reading: 3GPP TS36.300:10.1 & Annex J




Rel 10

eNB

Rel 10

UE

Downlink – up to 8 layers of spatial multiplexing or MIMO are allowed

Uplink MIMO is

supported in two

options – SU

(single user) and

MU (multi user)

MIMO

Uplink – up to 4 layers of spatial multiplexing or MIMO are allowed

Rel 10 UE

capabilities

include support

for up to 8x

MIMO in the

downlink and up

to 4x MIMO in

the uplink


MIMO Enhancements

LTE supports capacity expansion methods based on spatial multiplexing or multi-antenna techniques.

These techniques employ multiple, spatially diverse antennas to create separate streams of transmitted

signal that all occupy the same frequency domain or radio channel. There are several ways in which

these techniques may be configured, but the method employed in LTE is known as Multiple Input,

Multiple Output or MIMO.

Release 8/9 LTE supported Downlink MIMO that could create up to four separate streams in a way that

is referred to as 4x4 or ‘4-layer’ MIMO. Downlink MIMO could be configured to operate in SU (Single

User) mode, in which all streams would be carrying traffic to the same UE at any one time, and MU (Multi

User) mode, in which separate streams could be scheduled to carry traffic for different users. SU MIMO

can therefore be seen as a way of improving the throughput or quality of the connection supplied to one

user, whereas MU MIMO can be seen as a way of increasing the number of users that can be served

simultaneously. R8/9 LTE supported only 2 layer MU MIMO on the uplink.

R10 LTE introduced a number of MIMO enhancements, including increasing the number of downlink

layers to 8, increasinglthe number of uplink layers to 4 and introducing SU MIMO for uplinks.

Further Reading: 3GPP TS36.300:5.1.5 & 5.2.6

LTE Advanced



SCell 4

SCell 3

SCell 2

SCell 1

PCell

RLCRLC

PDCPPDCP

Data connections between Rel 10/11

LTE-A UEs and eNBs can consist of up

to 5 aggregated carriers, each of which

could carry up to 8 DL MIMO and 4 UL

MIMO layers per UE

MAC

MAC

MAC

MAC

MAC

MAC

MAC

MAC

MAC

MAC

UL/DL-SCH &MIMO

UL/DL-SCH &MIMO

UL/DL-SCH &MIMO

UL/DL-SCH &MIMO

UL/DL-SCH &MIMO

UL/DL-SCH &MIMO

UL/DL-SCH &MIMO

UL/DL-SCH &MIMO

UL/DL-SCH &

MIMO

UL/DL-SCH &

MIMO

PHY PHY

There are separate MAC HARQprocesses for each UL/DL-SCH

Each MIMO stream is generated to aseparate logical port at the LTE Physical

layer (PHY) and carries separate instancesof UL-SCH and DL-SCH


User Connections

R10 LTE-Advanced shares the same air interface protocol stack as standard R8/9 LTE, namely PDCP

over RLC over MAC over the OFDMA-based PHY (Physical Layer).

Carrier Aggregation is mainly accommodated by making changes to the MAC layer. Each UE-specific

MAC instance in an eNB and the corresponding MAC layer in each UE perform a set of functions that are

common for all active serving cells (such as MAC PDU creation and scheduling), but there is also a set of cell-specific functions performed separately for the PCell and each Scell. These functions mainly relate to

the establishment of separate HARQ sessions for each UL or DL SCH (Shared Channel) that is active.

At the Physical layer, the eNB and UE will establish separate instances of UL-SCH and DL-SCH for each

CC and for each MIMO layer on each CC that is active for the UE connection. Traffic travelling over each

of these separate physical layer connections will be scheduled capacity by the MAC layer as required to

meet the QoS agreed for each E-RAB.

The upper reaches of LTE-Advanced capability, as evidenced by the parameters associated with UE

Category 8, can in theory allow a UE to achieve 3000MBit/s on the downlink and up to 1500MBit/s on the

uplink. To enable this to take place, the UE is likely to be operating with a full set of serving cells (one

PCell and four SCells), to be using the highest available modulation scheme (64QAM on both the uplinkand the downlink) and to be using the full set of available MIMO streams. This would equate to 8 streams

per DL CC and 4 streams per UL CC – or a combined 40 separate logical downlink physical layer

connections and 20 in the uplink.

The possibility of a UE (or a network) achieving commercial support for such extreme data rates and

operating parameters in the near term is exceedingly remote and far more modest data rates of a few

hundred megabits per second is a much more achievable target for most LTE-Advanced operators.





Planned ornotional coverage

area of eNB

Typical actual

coverage areaof eNB

Area not

served by

eNB due to

shadow of

large building

LTE Relaynode

Additional

coverage

provided by

LTE Relay

node

Donor eNB

Area not served

by eNB due to

competition from a

neighbouring eNB

Area not

served by

eNB due to

geography


Relaying for LTE

Apart from carrier Aggregation, the most important other new service introduced in the Release 10

specification set was the concept of the LTE RN (Relay Node).

LTE RNs are able to relay or repeat the signal from an eNB into areas that might previously have been

difficult to penetrate, including areas where signals from an eNB were blocked by large buildings, hills or

other obstructions. An RN, positioned in the optimum location, can repeat the signal from the eNB intosuch a poorly-served area.

LTE Relays operate using two LTE air interface instances: one instance is projected towards UEs and

provides standard LTE coverage; the other instances maintains a link back to the controlling, or ‘donor’,

eNB and is used for backhaul.

The controlling eNB is known as a ‘donor’ device as it provides or donates the radio channels that will be

used by the RN. The backhaul connection between the RN and the eNB uses the resources of one or

more of the eNB’s cells and shares that resource with UEs operating within that cell’s coverage area by

defining an RN-specific scheduling channel (the R-PDCCH) and carrying traffic in subframes reserved for

RN traffic. Any traffic received by the RN will be repeated out to its set of UEs. Uplink capacity is

scheduled in the same way, with some subframes dedicated to carrying UE-RN traffic which is thenforwarded to the DeNB (Donor eNB).

The air interface connection between an RN and its DeNB operates in two modes. When an RN is

initialising it acts like a UE and requests a standard Uu data connection to allow it contact the network’s

configuration server. Once configured and operational, the RN maintains a Un interface with its DeNB

that carries adapted versions of the S1 and X2 interfaces which are proxied through the DeNB before

being forwarded to the core network. The DeNB proxies provide the RN with adapted versions of the

functions traditionally performed by the MME and S-GW.

The Relay concept adds to the configurational complexity of the LTE EUTRAN. An eNB may be

configured to support a mixture of traditional macro-cells, micro and pico cells that are propagated by a

series of remote radio antennas (or ‘powered heads’) plus a set of Relay Nodes repeating coverage into

traditionally hard-to-reach areas.

LTE Advanced



LIPA

SIPTO

Managed Remote Access

IP Flow Mobility ANDSF

Multi-Access PDNConnectivity

Local IP Access techniquesallow a registered UE to access

the resources of a home oroffice LAN (such as printers,

media servers) via the femtocellcreated by an LTE HeNB

(Home eNB)

Selective IP Traffic Offloadtechniques allow a UE and

network to negotiate to divertselected traffic flows (data orstreaming connections, for

example) on an APN-by-APNbasis to use S-GW/PDN-GW

resources that aregeographically local to the UE

These techniques allow a userto remotely access resourcesconnected to a home or officeLAN via a cellular data service

using the connectionestablished to support their

home or office HeNB femtocell

Access Network Discovery &Selection Function techniques

allow an LTE EPC to guideroaming UEs to non-3GPP

access networks (WiFi, WiMax,CDMA2000, etc) that should beable to provide connectivity and

service

Allows UEs to establishseparate but simultaneous

PDN Connectivity Services viadifferent available RATs – e.g. a

UE could have one or moreEPS Bearers established via

LTE cells and others connectedvia HSPA or EDGE at the same

time

These techniques allowoperators to more easily

integrate their cellular and WiFiaccess networks to allow UEsto more simply and effectively

hand over between themwithout losing connectivity or

service


R10/R11 Data Handling Improvements

3GPP Release 10 and 11 specifications also introduce a number of techniques designed to enhance theways in which mobile data is handled, especially when users have access to femtocells or wifi hotspots.

LIPA is designed to allow a UE to make use of the resources of a home or office LAN (to which the user has access) via LTE; the intention is that a UE could access a network printer, or send content to an

Internet-enabled TV, or stream music from a home content server, all via a LAN-connected femtocell.Managed Remote Access aims to provide the same kind of home/office LAN access service but workswhile the user is roaming away from their home femtocell; remote access to local resources is providedfrom anywhere on the LTE network via the secure connection created to serve the user’s homefemtocell.

SIPTO is designed to detect and make use of geographically local EPS Gateways (S-GW and PDN-GW)for certain PDN connections. A roaming UE may, for example, have one PDN connection (connected toan application server that only exists in the home network) directed back to an APN in a home networkPDN-GW, whilst a PDN connection to the general Internet could be directed to a local, visited network APN. SIPTO works in both roaming and non-roaming cases and an APN’s applicability for SIPTO issignalled in the user’s HSS profile.

IP Flow Mobility aims to enable better interworking between LTE and WiFi, in this case by providing themeans to seamlessly hand active connections over between LTE and Wi-Fi access devices, but only if the Wi-Fi access is controlled by the LTE network operator. A UE that, for example, has an active voicecall and is also in the process of downloading a large file from an Internet-based server, could use IPFlow Mobility to divert the data download to an active (operator-controlled) Wi-Fi connection, thusoffloading traffic from the LTE network and preventing the user from consuming unnecessary amounts of their data bundle.

Multi-Access PDN Connectivity allows an operator to make efficient use of their portfolio of cellular access systems by allowing UEs to setup simultaneous connections via more than one of them at a time.Traditionally, a multi-RAN capable UE (e.g. one that could connect to 2G, 3G and 4G access networks)would only ever be connected to one RAT at a time, and all connections would be established via theactive RAT. Multi-access PDN Connectivity allows a UE to maintain, for example, a low-bit rate VoLTE

(Voice over LTE) connection via an enhanced 2G GERAN connection whilst also maintaining a high-bitrate data streaming connection via LTE-Advanced. ANDSF (Access Network Discovery & SelectionFunction) is also designed to improve multi-RAT operations by providing a means for a UE to availableinterrogate non-3GPP access types (e.g. WiFi, WiMax, CDMA2000 cells) and negotiate with their homecore network about which of the available options is best, thus ensuring optimal roaming connectivity.




S-GW

eNB 2eNB 1

TransmissionPoint

Serving

Cell

CoMPCo-operating Set

IndirectParticipation

DirectParticipation

EPC

RRH 1.2

RRH 1.1

RRH 1.3

RRH 1.4

UL-CoMP:

Joint Reception(JR) – traffic receivedby multiple points simultaneously andpassed to serving eNB for processing

Co-ordinated Scheduling/Co-ordinatedBeamforming (CS/CB) – reception at asingle point but uplink scheduling isbased on input from multiple points

DL-CoMP:Joint Processing (JP)

Joint Transmission (JT) – traffictransmitted by multiple pointssimultaneouslyCo-ordinated Scheduling/Co-ordinated Beamforming (CS/CB) –single transmitting point withscheduling input from multiplepoints

Dynamic Point Selection (DPS) –traffic transmitted by single point buttransmitting point can vary on asubframe or RB basis


CoMP Transmission/Reception

CoMP transmission/reception was proposed as part of Release 10 LTE-Advanced as a means of

improving cell-edge coverage and of therefore boosting overall connection quality and data throughput

levels. It provides, in effect, a macro diversity facility for LTE in a manner that has also been described as

‘network MIMO’. Detailed specification of CoMP was held over the R11 and R12 work schedules.

The CoMP concept is simple; UEs located at cell edges or in other poor coverage areas may be offereda more consistent connection by either using multiple ‘points’ (eNBs, Relays, Remote Radio Heads, etc.)

to serve them or, by collating feedback from several neighbouring nodes, adjusting the scheduling

applied to them to minimize interference and improve reception quality.

CoMP operation is based on intra-site and inter-site co-ordination between eNBs; intra-site co-ordination

operates between different cells, relays and remote head units controlled by the same eNB and is

relatively simple to achieve, inter-site co-ordination operates between neighbouring eNBs and is more

complex to implement. The group of ‘points’ currently serving a UE are classed as its CoMP Co-

operating Set. Points in a set may be either ‘directly participating’, in which case they will be actively

handling traffic for the UE, or ‘indirectly participating’ in which case they will supplying measurements and

other information to assist with co-operative scheduling. CoMP can operate in both downlink (DL-CoMP)

and uplink (UL-CoMP) directions.

The two main forms of DL-CoMP are JP (Joint Processing) and DPS (Dynamic Point Selection). JP can

operate on the basis of JT (Joint Transmission), where multiple points transmit copies of the same data

in the same subframe simultaneously to improve reception of that data at the UE, or CS/CB (Co-

ordinated Scheduling/Co-ordinated Beamforming), where only the serving cell transmits data to the UE.

During CS/CB however, the serving cell and its co-operating neighbours manage scheduling to ensure

that interference to and by all UEs is minimized. In DPS only one point out of a Co-operating Set will

transmit to a UE at any one time, but the choice of which point to transmit from can vary on a subframe,

or even a Resource Block, basis.

UL-CoMP consists of JR (Joint Reception), where transmissions from a UE are received by multiple

points and are passed to the serving cell for processing, and uplink CS/CB scheduling management.


LTE Advanced



X2 interfaceeNB

eNB

ICIC

COO

MRO

MLB


SON Enhancements

Cellular networks operate in a complex, mutable environment in which new buildings are erected and old

ones are demolished, in which business and housing areas are created and abandoned, in which the

locations of potential users and their communications requirements change every day. Cellular operators

must therefore continually seek to optimize their networks to keep pace with these changes, if they want

to continue to effectively serve the needs of their subscribers.

The optimization of cellular networks involves adjusting cell parameters to adapt to new sources of

interference and adding or removing capacity to ensure that current requirements are efficiently met.

Traditionally these functions would be performed by optimization engineers working from a set of key

performance indicators derived from network equipment. Since Release 8 however, 3GPP has been

gradually increasing the range of optimization functions that can be performed automatically by the LTE

network itself; functions which are grouped under the heading of SON, or the Self-Optimizing Network.

For Release 10 and LTE-Advanced, 3GPP introduced a number of new SON facilities, including:

ICIC, which allows eNBs to exchange interference and other measurement data to co-ordinate

scheduling and other activities and is regarded as providing a subset of the functions required to support

CoMP.

COO (Capacity & Coverage Optimization) allows neighbouring eNBs to negotiate adjustments to

adjacent cells to ensure the best possible coverage and capacity is provided.

MLB (Mobility Load Balancing) allows neighbouring eNBs to co-ordinate their load balancing activities by,

for example, exchanging current load data and negotiating the handover of cell-edge users from busy

cells to less busy neighbouring cells. MRO (Mobility Robustness Optimization) allows neighbouring eNBs

to capture data related to handover failures and to investigate and solve issues such as misconfigured or

out-of-date neighbour lists that might contribute to those failures.

Further Reading: 3GPP Release Description:10.9




APPENDIX

LTE ADVANCED





IMT-Advanced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.1

Evolution to LTE-A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.2

LTE-Advanced Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.3

LTE Frequency Bands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.4

Carrier Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.5

Carrier Aggregation Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.6

CA Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.7

UE Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.8

UE Bandwidth Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.9

CA Operating Bands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.10

PCells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.11

SCells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.12

Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.13

Handovers with CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.14

MIMO Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.15

User Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.16

Relaying for LTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.17

R10/R11 Data Handling Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.18

Co-ordinated Multipoint (CoMP) Transmission/Reception . . . . . . . . . . . . . . . . . . . . . . . . . . .A.19

SON Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A.20

CONTENTS

LTE Advanced





describe the requirements for 4G networks specified by the ITU IMT-Advanced guidelines

identify where LTE-Advanced sits within the progression of 3GPP specification Releases

outline the basic functionalities that were added to LTE in releases 10 and 11 to create LTE-

Advanced

identify some of the more important frequency bands in which LTE use has been specified

describe the basic functionality of LTE-Advanced Carrier Aggregation

outline the differences between Inter- and Intra-Band Carrier Aggregation and describe the

various types of symmetrical/asymmetrical configuration that are possible

describe the meaning of CA-related terms such as Carrier Aggregate, Aggregated Channel

Bandwidth, Transmission Bandwidth and Aggregate DC Subcarrier

outline the roles played by configuration descriptors such as the CA Bandwidth Class, UE

Categories, CA Operating Bands and Supported Bandwidths identify the key functions and main differences between PCells and SCells as employed in

Carrier Aggregation

describe the enhancements made to LTE’s spatial multiplexing or MIMO functionalities in

Release 10

outline the purpose of the LTE Relay and describe the basic elements of this concept

outline the functionality of some of the other key Release 10 LTE features such as LIPA, SIPTO,

MRA and IP Flow Mobility

describe the basic concept that underpins the Release 11 CoMP (Co-ordinated Multi-Point)

feature

outline some of the enhancements made in Release 10 to the SON (Self Optimising Network)

concept

OBJECTIVES

LTE Advanced




a high degree of commonality of functionality worldwide while retaining

the flexibility to support a wide range of services and applications in a

cost-efficient manner

compatibility of services within IMT and with fixed networks

capability of interworking with other radio access systems

high quality mobile services

user equipment suitable for worldwide use

user-friendly applications, services and equipment

worldwide roaming capabilityenhanced peak data rates to support advanced services and applications

(targets of 100 Mbit/s for high mobility and 1 Gbit/s for low mobility)

Key features of IMT-Advanced:

International

Mobile

Telephony


IMT-Advanced

The ongoing design and implementation of cellular systems is pushed forward by equipment vendors,

network operators and, in most cases, international specifications bodies such as 3GPP. A degree of

central guidance to this process is provided by the ITU, a branch of the United Nations responsible for

attempting to harmonize the standards and techniques employed in worldwide telecoms systems.

The ITU set out its vision for 3G cellular systems at the end of the 1990s by devising a framework knownas IMT-2000, although the 3G market ended up consisting of several competing technological platforms

all of them ultimately adhered to the guidelines espoused by the ITU.

The ITU created a similar framework of expectations for emerging 4G technologies in 2007 with the initial

publication of the IMT-Advanced guidance.

Instead of specifying a particular technology or mandating the functionality of a 4G system, the IMT-

Advanced guidelines proposed the basic set of capabilities that a system should be able to support for it

to be regarded as being a true ‘4G’ system.

In addition to the aspirations outlined in the diagram, the ITU (in ITU-R report M.2134) also provided

some more definite technical requirements for 4G systems, including: that an IMT-Advanced systemshould be able to accommodate radio channels of at least 40MHz in bandwidth; that their peak spectral

efficiency should meet or exceed 15bits/Hz in the downlink and 6.75bits/Hz in the uplink; that it should

support latencies of less than 100ms for control-plane connections and less than 10ms for the user-

plane.

It should be noted that the original (Release 8) version of LTE did not meet the full set of IMT-Advanced

requirements, mainly due to its inability to support 1 Gbit/s data connections. To date only Release 10

LTE-Advanced and the updated version of Mobile WiMax (IEEE 802.16m) have been accepted as fully

compliant with IMT-Advanced.

Further Reading: www.IMT-2000.org (ITU website), ITU-Report M.2134

LTE Advanced



extension of LTE into new radio bands

Carrier Aggregation

enhanced Uplink and Downlink MIMO capabilities

relays for LTE

enhanced Self Optimizing Network (SON) capabilities

additional interference control techniques

evolved data handling options for Femtocell and WiFi interworking:

local IP Access (LIPA)

selected IP Traffic Offload (SIPTO)

managed Remote Access

IP Flow Mobility

Access Network Discovery and Selection Function (ANDSF)


extension of Carrier Aggregation to more radio bands

extension of LTE to additional radio bands

additional carrier types for Carrier Aggregation

support for Diverse Data Applications

enhancements to interference control techniques

enhanced techniques for LTE Relays

enhanced techniques for MBMS

study into Co-ordinated Multi Point (CoMP) Operation



LTE-Advanced Features

Basic LTE-Advanced functionality was first described in 3GPP Release 10 specifications, with the more

detailed and enhanced functionality held over to Release 11.

Release 10 functions include: Carrier Aggregation, which allows a UE to be scheduled with data-carrying

capacity on up to five parallel cells simultaneously; enhanced MIMO techniques that allow a UE to make

use of up to 8 MIMO layers on a downlink and up to 4 layers on an uplink; additional types of MIMO for uplink connections; the extension of LTE into a variety of new radio bands; enhancements to the SON

concept; and a range of data-handling improvements such as LIPA (Local IP Access) and SIPTO

(Selective IP Traffic Offload).

Release 11 introduced only one significant new feature, known as CoMP, and mainly concentrated on

adding more depth and complexity to existing R10 services.

Detailed information about the work and study items scheduled for each release are contained in the

relevant 3GPP Release Description documents, which provide a regularly-updated view of the work

being undertaken, or that has been completed, for each release.

Further Reading: http://www.3gpp.org/ftp/Information/WORK_PLAN/Description_Releases/

LTE Advanced



FDD


1 1920 – 1980 2110 – 2170

2 1850 – 1910 1930 – 1990

3 1710 – 1785 1805 – 1880

4 1710 – 1755 2110 – 2155

5 824 – 849 869 – 894

6 830 – 840 875 – 885

7 2500 – 2570 2620 – 2690

8 880 – 915 925 – 960

9 1749.9 – 1784.9 1844.9 – 1879.9

10 1710 – 1770 2110 – 2170

11 1427.9 – 1447.9 1475.9 – 1495.9

12 698 – 716 728 – 746

13 777 – 787 746 – 756

14 788 – 798 758 – 768

... ... ...

17 704 – 716 734 – 746

18 815 – 830 860 – 875

19 830 – 845 875 – 890

20 832 – 862 791 – 821

21 1447.9 – 1462.9 1495.9 – 1510.9

2223

24

25

3410 – 34902000 – 2020

1626.5 – 1660.5

1850 – 1915

3510 – 35902180 – 2200

1525 – 1559

1930 – 1995

TDD


33 1900 – 1920

34 2010 – 2025

35 1850 – 1910

36 1930 – 1990

37 1910 – 1930

38 2570 – 2620

39 1880 – 1920

40 2300 – 2400

41 2496 – 2690

42 3400 – 3600

43 3600 – 3800


LTE Frequency Bands

LTE was originally allocated the previously little-used 2600MHz band (now known as Band VII) but as

additional frequency bands were proposed, 3GPP devised a band numbering system to regulate and

regularize frequency allocations.

Most of the bands defined for LTE use have previously been used to support 2G and/or 3G network

services, this includes Band I (used for UMTS2100), Band VIII (used for GSM900) and Band XX(terrestrial analogue TV).

Separate band definitions have been made for LTE’s FDD and TDD variants, although many of these

bands overlap or employ the same frequency ranges.

3GPP accepts proposals to extend LTE into new frequency bands at each plenary session, so the list

shown in the diagram is subject to being updated. The full list of defined bands is shown in 3GPP

Technical Specification TS36.101, which can be downloaded from the 3GPP website. The list shown in

the diagram is current up to the version of TS shown.





Cell A

Cell B

Cell C

Cell D

Cell E


Primary Component Carrier




Component Carriers are classified as DL CCs or UL CCs

A PCell is always carried by paired DL CC and UL CC

An SCell is always carried by a DL CC which may or

may not be paired with an UL CC

SCell–PCell– Primary Serving Cell – there will be

one PCell per UE per carrier

aggregate. The PCell is bidirectional.

Secondary Serving Cell – a carrier

aggregate may consist of between one and

four SCells, the number allocated to a UE

may vary over time. An SCell may be

bidirectional or unidirectional (Downlink only)

The term ‘Component Carrier’ is used to describe either case in this text


Carrier Aggregation

CA (Carrier Aggregation) is the most prominent feature of Release 10 LTE-Advanced. It offers an inverse

multiplexing facility that allows a UE to substantially increase the overall data rate it can achieve by

allowing an eNB to schedule capacity for it on multiple cells (or 'carriers') simultaneously.

Each carrier (either downlink or uplink) assigned for use by a UE is known as a CC (Component Carrier)

and the set of CCs allocated to a UE at any one time forms a Carrier Aggregate. R10 CA permits up tofive CCs to be bound into a Carrier Aggregate, potentially providing a suitably-equipped UE with up to

100MHz of bandwidth and an aggregate downlink data rate of over 3Gbit/s.

The lowest level of carrier aggregation allows a UE to connect via just one cell. The radio connectivity of

this cell is described as the PCC (Primary Carrier Component) and the cellular service it offers is known

as the PCell (Primary Serving Cell). The PCell carries NAS and RRC services for a UE and is also the

carrier measured by the UE to support functions like quality feedback and handover measurements.

A Release 8/9 UE (or an R10 UE that didn’t require CA services) would just connect via the PCell and

would not be assigned any additional carriers. An R10, CA-capable UE that did require a CA service

would be scheduled with capacity on between one and four SCells (Secondary Serving Cells), each of

which would be carried by an SCC (Secondary Component Carrier).

The PCC and any SCCs aggregated to provide a CA service for a UE must all be under the control of the

same eNB, but the terms ‘primary’ and ‘secondary’ used in relation to CA carriers are determined from

the point of view of each UE – different UEs in the same area may have selected different cells to be

their PCell and may therefore regard an assigned cell as an SCC which may be employed by another UE

as a PCC.

A PCell is always used in a bidirectional manner, as befits the cell that carries NAS and RRC traffic, but

an SCell may be used in either a bidirectional or unidirectional manner depending upon local

configuration and current requirements. If an SCell is used unidirectionally then it is only able to operate

in 'downlink-only' mode, there is no provision for cells to operate in 'uplink-only' mode.

LTE Advanced




PCell

Symmetrical CC, Asymmetric Bandwidth

Configuration SCell1

Inter-Band


Symmetrical CC andBandwidth ConfigurationPCell

PCell

No CA

PCells must always besymmetrical with both

an uplink and downlinkScell 1

Scell 2

Inter-Band -Contiguous

Asymmetrical CCConfiguration

PCell

SCell

2

SCell

1

Band A Band BUplink Downlink Uplink Downlink Inter-Band -

Non-Contiguous


Carrier Aggregation Options

Carrier Aggregation in LTE-Advanced has been designed to operate with as much configurational

flexibility as is practical; there is flexibility in the way in which channel aggregates can be spread across

frequency bands and there is also flexibility in the symmetry that can be employed by SCCs.

Frequency band options are classified as:

Inter-Band – where the component carriers in an aggregate can belong to two or even three differentfrequency bands

Intra-Band Contiguous – where the CCs must belong to the same frequency band and must be

contiguous (i.e., adjacent to each other) within that band

Intra-Band Non-contiguous – where the CCs must belong to the same frequency band but are not

required to be contiguous within that band (i.e., they may be spread out across the band)

The symmetry applied to a channel aggregate can vary in terms of the numbers of uplinks and downlinks

and also in terms of the bandwidths of those uplinks and downlinks.

A PCell must always be symmetrical in terms of its uplink and downlink, but the bandwidth allocated to

each may vary. UEs that do not support or that do not require CA connections only make use of a PCell

and will therefore always receive a service that is symmetrical in terms of CC configuration.

An SCell can be configured with symmetrical or asymmetrical Component Carriers; symmetrical CC

configuration means that the SCell employs both an uplink and a downlink, whilst asymmetrical CC

configuration would employ just a downlink, it is not possible to configure an SCell to operate in an ‘uplink

only’ manner.

Asymmetrical bandwidth al locations are possible for both PCells and SCells and are typically

characterized by configuring the cell’s downlink channel to occupy a larger bandwidth than its uplink. An

example of this might be a cell with a 20MHz downlink but only a 5MHz uplink. Such configurations are

used to reflect the asymmetric nature of typical user demand, in which more data is downloaded than is

uploaded.

Further Reading: 3GPP TS36.300:Annex J, 36.807:Annex A




Lower guard

subcarriers

Aggregated Channel

Bandwidth (25 MHz)

Upper guard

subcarriers

Aggregated Channel

Transmission Bandwidth (25 MHz – guard bands)

Lowest CC Highest CC

10 MHz Carrier


5 MHz Carrier


DC Subcarrier

Must be a multiple of 300kHz

10 MHz Carrier Bandwidth

5 MHz Carrier

Bandwidth 10 MHz Carrier Bandwidth

DC Subcarrier DC Subcarrier

10 MHz Carrier



CA Terminology

Carrier Aggregation operates by allowing an eNB to schedule uplink and downlink capacity for a UE

across a set of component carriers that have been combined to form an Aggregated Channel.

The total bandwidth occupied by the Aggregated Channel is termed the Aggregated Channel Bandwidth

and includes all used and unused subcarriers; unused subcarriers are generally those set aside to act as

guard bands at the upper and lower end of each CC. The net usable bandwidth of the AggregatedChannel (which is total bandwidth less all guard subcarriers) is termed the Aggregated Transmission

Bandwidth.

Due to the requirements imposed by OFDMA, each CC will still need to have its centre-frequency left

unused to act as a DC Subcarrier. To ensure that orthogonality is maintained between subcarriers across

an entire aggregated channel, the DC Subcarriers of all CCs within the aggregate must be spaced at

multiples of 300kHz from each other. The number of guard subcarriers employed at the top and bottom

ends of each CC may be adjusted to accommodate this spacing requirement if necessary.

In a contiguous aggregated channel (i.e., one in which all CCs are adjacent to each other) the DC

subcarrier of the central CC will be used as the baseband transmission DC Subcarrier for the entire

aggregate. For this reason, it is recommended that aggregate channels are created in a ‘balanced’manner, as shown in the diagram. The total 25MHz aggregated channel bandwidth in the diagram has

been created by aggregating 2x10Mhz and 1x5MHz CCs, but to balance this aggregate the 5MHz CC

has been placed in the centre and its DC Subcarrier will be used for the entire aggregated channel.

Un-balanced configurations are also possible – a 25MHz channel aggregate could be created by

combining CCs in a 10+10+5 pattern, for example – but in these cases the aggregate DC Subcarrier

must be created by using whichever ‘transmission’ subcarrier happens to be at the centre frequency of

the aggregate.

In non-contiguous aggregates (like those employed in inter-band configurations), each contiguous

section of the aggregate will require its own aggregate DC subcarrier.

Further Reading: 3GPP TS36.807:5.6A & 5.7, 36.104:5.7.1A

LTE Advanced



UE Category

Feature

Peak DL data rate (Mbit/s)

Peak UL data rate (Mbit/s)

Highest DL modulation scheme

Highest UL modulation scheme

Max DL MIMO layers

Release 8/9

1 2 3 4 5

10 50 100 150 300

5 25 50 50 75



1 2 2 2 4

Transmission Parameter

UE Category Release 10

6 7 8

300 300 3000

50 100 1500

64QAM 64QAM 64QAM

16QAM 16QAM 64QAM

2 or 4 2 or 4 8


UE Categories

The cost of LTE UEs is partly determined by the sophistication of the set of functions that each can

perform. Only a limited subset of UEs will be designed to take advantage of the maximum possible

capabilities of an LTE network. It is therefore necessary to allow each UE to signal its capabilities to the

network to allow the services offered to be tailored to its abilities.

UE capabilities are signalled in RRC message IEs and are classified into UE Categories.

Release 8/9 UEs have capabilities – those that relate to ‘standard’ LTE access – that place them in UE

Categories 1-5, these are signalled in the UE-EUTRA_Capability IE.

Release 10 UEs may have capabilities that relate to LTE-Advanced access which place them in UE

Categories 6-8, these are signalled in the UE-EUTRA-Capability-v10 IE.

A Release 8/9 UE with UE Category 5 can, in theory, achieve data rates of up to 300MBit/s in the

downlink and 150MBit/s in the uplink using 64QAM modulation in both directions and up to 4 layers of

downlink MIMO.

A Release 10 UE with a UE Category of 8 can, in theory, achieve data rates of 3000MBit/s downlink and1500MBit/s uplink using 64QAM in both directions, up to 8 MIMO layers in the downlink and up to 4 in the

uplink. The use of CA with 4 SCells to achieve these data rates is implicitly indicated as they wouldn’t be

possible otherwise.

Both UE-EUTRA-Capabilities signal a large number of other parameters in addition to UE Category and

other IEs are also employed to carry UE configuration and capability information.

Further Reading: 3GPP TS36.306:4.1 (UE-Category IE), 36.331:6.3.6 (UE-EUTRA-Capability)




Carrier Aggregation

Bandwidth Class

Aggregated

Transmission

Bandwidth (in RBs)

Maximum number of

Component Carriers

Maximum possible

aggregate channel

bandwidth:

A 1 20 MHz

B 20 MHz

C 40 MHz

D 60 MHz

E 80 MHz

F 100 MHz

Correct as per TS36.101 v10.2.1

Classes D-F are classed by 3GPP as ‘for further study’ so the

values shown here are provisional and may be subject to change

1 x PCell

N RB_agg = Number of Resource Blocks in Aggregated Channel

2

2

3

4

5

1 x PCell

1 x SCell

1 x PCell

1 x SCell

1 x PCell

2 x SCell

1 x PCell

3 x SCell

1 x PCell

4 x SCell

NRB_agg = 100

NRB_agg = 100

100 =NRB_agg = 200

200 =NRB_agg = 300

300 =NRB_agg = 400

400 =NRB_agg = 500


UE Bandwidth Classes

The level of Carrier Aggregation that is supported by a UE is determined by its Bandwidth Class.

Each Bandwidth Class describes the level of CA capabilities supported by a UE, it includes descriptions

of the maximum number of Resource Blocks that a UE can use simultaneously and the maximum

number of Component Carriers (with each CC classed as an uplink/downlink pair whether the uplink is

actually used or not) the UE can access simultaneously. The largest channel bandwidth available in R10is 20MHz, so the maximum number of CCs parameter implicitly identifies the maximum operational

bandwidth a UE could be assigned.

Bandwidth Class A devices do not support CA, so this classification would be used to describe all

Release 8/9 UEs and any Release 10 devices that do not require CA capabilities. Class A devices are

able to access up to 100 Resource Blocks on a 20MHz channel in a PCell only and will not be able to

access any SCells. Examples of Bandwidth Class A devices might include voice-only LTE terminals and

devices designed to support low-bandwidth data applications such as smart utilities meters.

Bandwidth Classes B and upwards support increasing levels of aggregation capability. Class B devices

are also limited to using up to 100 RBs but may be assigned one SCell in addition to the PCell. The 100

RB limit means that although a Class B device is able to access two CCs it would not be able to accesstwo 20MHz CCs, as that would entail processing 200 RBs.

Bandwidth Class C devices are able to handle up to 200 RBs and two CCs and would therefore be able

to be assigned to, for example, a 20MHz PCell and a 20MHz SCell, although other channel

configurations are also possible.

As of v10.2.1 of TS36.101, the 3GPP specification that describes Bandwidth Classes, classes D-F had

parameters assigned to them but were described as being FFS (For Further Study), so the parameters

shown in the diagram are only provisional and may be subject to change by later versions of the

document. However, the maximum capability for a Class F device is likely to be up to five CCs covering a

maximum of 100MHz and using up to 500 RBs.

Further Reading: 3GPP TS36.101:5.6A

LTE Advanced



Intra-Band

Supported CC

Bandwidths

Intra-Band operating

bands are designated

using a prefix of ‘CA’ and

a suffix that shows the

LTE EUTRA band number

Supported Bandwidths show

which size(s) of CC have so far

been specified for CA use within

each Operating Band

Band

E-UTRA

Band



CA_1 1 1920 MHz 1980 MHz 2110 MHz 2170 MHz FDD

CA_40 40 2300 MHz 2400 MHz 2300 MHz 2400 MHz TDD

Y Y

Y Y Y

E-UTRA CA

5 824 MHz 849 MHz 869 MHz 894 MHz

Intra-Band

Supported CC

Bandwidths

Band

E-UTRA

Band



CA_1-51 1920 MHz 1980 MHz 2110 MHz 2170 MHz

FDDY

Y

E-UTRA CA

Inter-Band operating

bands are designatedusing a prefix of ‘CA’ anda suffix that shows the

numbers of the LTEEUTRA bands employed Details correct for TS36.101 v10.2.1


CA Operating Bands

The use of Carrier Aggregation in a given frequency band requires a number of parameters to be agreed

and specified to ensure interoperability between operators and vendors.

In Release 10, 3GPP concentrated on ensuring that a minimum level of functionality was available by

specifying CA services for just three Operating Bands. Intra-Band operation in Band 1 (2100MHz FDD)

and Band 40 (2.3GHz TDD) was specified as was Inter-Band operation across a combination of Band 1(2100MHz FDD) and Band 5 (upper 800MHz FDD).

Further to this, parameters for only a limited set of CC bandwidths were developed in each operating

band. Intra-Band operation was initially only specified for Bandwidth Class C devices (so the supported

bandwidths shown in the diagram would be described as CA_1C and CA_40C) and Inter-Band operation

was only described for Bandwidth Class A devices (giving a designation of CA_1A-5A).

Expansion of the set of operating bands and supported bandwidths to encompass a wider range of

bands and channel sizes was agreed as a major focus of Release 11 and Release 12 activities.

Further Reading: 3GPP TS36.101:5.5A & 5.6A.1




Cell A

PCell

The PCell assigned to a UE is a

standard LTE serving cell – all signalling

traffic travels via the PCell and all UE

signal quality measurements are made

on the PCell

A UE’s current PCell is

assigned Serving Cell Index 0

During handover or reselection a newPCell is selected for the UE


PCells

A PCell, or Primary Serving Cell, is essentially the same as a standard R8/9 LTE cell.

A UE, whether it supports R8/9 or R10, will undertake the same Idle Mode and cell selection procedures

when active and will camp on a serving cell from the set locally-available based on signal quality and

strength indicators. Once a cell has been selected and the UE has camped on it, it becomes that UE’s

PCell. The current PCell is always assigned Serving Cell Index 0 by the UE.

A UE will only monitor the BCCH of a PCell, any system information required to access an SCell will be

provided to the UE using dedicated RRC signalling during SCell Addition or Modification.

An Idle Mode UE will monitor the PCell’s paging channel and will use measurements taken of the PCC

as the basis for idle mode reselection actions. If necessary, the UE will use PCell’s RACH to transmit

Service Requests to initiate a move to Connected Mode (moving from ECM-Idle to ECM-Connected).

A UE in Connected Mode will initially use the resources of the PCell; all RRC and NAS transactions take

place via the PCell and any ciphering applied to established traffic and control channels will be based on

the ciphering calculated for the PCell. The UE will send Uplink Capacity requests via the PCell PUCCH

(Physical Uplink Control Channel) and will monitor the PCell PDCCH (Physical Downlink ControlChannel) for downlink capacity notifications and uplink scheduling grants.


LTE Advanced



Cell A

PCell (Serving Cell Index 0)

SCells assigned to a UE may be

deactivated when there is no data

scheduled for them. Activation/deactivation is signalled via

the MAC layer

SCells are added, modified or released

from a UE’s aggregation set using RRC

commands via the PCell

SCells may be bidirectional or

downlink-only but are never uplink-only

Cell B

SCell Index 1 (Serving Cell Index 1)

Cell C

SCell Index 2 (Serving Cell Index 2)

Each SCell activated for a UE

is assigned an SCell Index, the

Serving Cell Index for eachSCell matches the SCell Index

The number of SCells that may be

activated for a given UE depends upon

its CA Bandwidth Class, local availability

of SCells, current network load and UE

application demand


SCells

If a UE in ECM-Connected mode supports CA (e.g. if it has a Bandwidth Class greater than Class A), if

the serving eNB supports CA, if the traffic flow demanded by the UE’s currently-active applications is

sufficiently high, and if there is enough capacity available to support it, then the UE may be assigned one

or more SCells and could have capacity scheduled on them.

SCells are assigned by a controlling eNB for UE traffic capacity expansion purposes only and are notused for signalling or administrative purposes. SCells will be assigned UE-specific SCell Index values of

between 1 and 7 by the eNB, the UE will use this index as the basis for the Serving Cell Index that it

stores for each SCell.

The assignment of an SCell by an eNB will be signalled to the UE using the RRC SCell Addition

message, which will also specify the SCell Index, its Physical Cell ID and EARFCN channel number, its

bandwidth, mode (bidirectional or downlink-only), whether cross-carrier scheduling is to be employed,

and other parameters. SCell Modification messages are used to change the configuration of an existing

SCell and the SCell Release message is used to deassign them.

Once an SCell has been added to a UE's CA set it can be activated and deactivated as traffic flow and

capacity availability dictate – on initial assignment all SCells are deactivated. SCell status is signalled bythe eNB using the SCell Activation/ Deactivation MAC control element, which can optionally be appended

to a downlink MAC PDU header to signal any changes to the status of the set of SCells. SCell

deactivation is usually triggered by the expiry of an SCell inactivity timer in the eNB and SCell activation

is usually triggered by an increase in uplink or downlink traffic flow. The PCell cannot be deactivated at

any time.

When an SCell is active, a UE will be required to monitor its PDCCH for scheduling notifications (unless

cross-carrier scheduling is enabled) and will be expected to provide quality feedback in relation to the

SCell CCs. When an SCell is deactivated a UE Is not required to perform any actions in relation to it.

Further Reading: 3GPP TS36.300:7.5, 36.331:5.3.10.3a, 5.3.10.3b (RRC aspects), 36.321:5.13 (MAC aspects)




DL/UL-SCH

Transmitted Data

DL/UL-SCH

Transmitted Data

DL/UL-SCH

Transmitted Data

DL/UL-SCH

Transmitted Data

DL/UL-SCH

Transmitted Data

PUCCH

Scheduling

Requests

PDCCHDownlink Assignments

Uplink Grants(Cross-Carrier

Scheduling enabled)

With ‘cross-carrier scheduling’activated all downlink/uplinkcapacity notifications are carriedby the PCell PDCCH

If ‘cross-carrier scheduling’ is not

activated each SCell’s PDCCHwill carry cell-specific capacitynotifications

SCell 4

SCell 3

SCell 2

SCell 1

PCell


Scheduling

Scheduling for all forms of LTE is managed via the PDCCH.

For R8/9 UEs and for R10 UEs that either don't support CA or that do not currently have CA activated,

only the PCell's PDCCH will carry relevant scheduling information.

For R10 UE’s with CA activated and SCells assigned, there are two scheduling information options,depending upon whether cross-carrier scheduling has been enabled.

Cross-carrier scheduling allows scheduling notifications for one or more SCells to be carried by the

PDCCH of another active cell, typically the PCell. In such cases the capacity notification will indicate

details of the capacity granted plus the index of the intended CC. The typical benefit of cross-carrier

scheduling is that it allows a UE to monitor just one PDCCH to get access to all of its capacity

notifications. Cross-carrier scheduling is not an option for the PCell, whose capacity notifications are

always carried on its own PDCCH.

If cross-carrier scheduling is not enabled for an SCell then capacity notifications for that cell will be

carried on its own PDCCH.

Cross-carrier scheduling can be enabled or disabled on an SCell by SCell basis, based on an option in

the RRC SCell Addition and Modification messages, meaning that a UE could in theory have it enabled

for some cells in its CA set but not for others.

Whatever its complexities, LTE-Advanced Carrier Aggregation can ultimately be seen as an exercise in

multi-carrier scheduling and its success or otherwise in an individual vendor's equipment will be

determined by the efficiency of the scheduling algorithm they have developed.


LTE Advanced



Rel 10

eNB

Rel 10

UE

Downlink – up to 8 layers of spatial multiplexing or MIMO are allowed

Uplink MIMO is

supported in two

options – SU

(single user) and

MU (multi user)

MIMO

Uplink – up to 4 layers of spatial multiplexing or MIMO are allowed

Rel 10 UE

capabilities

include support

for up to 8x

MIMO in the

downlink and up

to 4x MIMO in

the uplink


MIMO Enhancements

LTE supports capacity expansion methods based on spatial multiplexing or multi-antenna techniques.

These techniques employ multiple, spatially diverse antennas to create separate streams of transmitted

signal that all occupy the same frequency domain or radio channel. There are several ways in which

these techniques may be configured, but the method employed in LTE is known as Multiple Input,

Multiple Output or MIMO.

Release 8/9 LTE supported Downlink MIMO that could create up to four separate streams in a way that

is referred to as 4x4 or ‘4-layer’ MIMO. Downlink MIMO could be configured to operate in SU (Single

User) mode, in which all streams would be carrying traffic to the same UE at any one time, and MU (Multi

User) mode, in which separate streams could be scheduled to carry traffic for different users. SU MIMO

can therefore be seen as a way of improving the throughput or quality of the connection supplied to one

user, whereas MU MIMO can be seen as a way of increasing the number of users that can be served

simultaneously. R8/9 LTE supported only 2 layer MU MIMO on the uplink.

R10 LTE introduced a number of MIMO enhancements, including increasing the number of downlink

layers to 8, increasinglthe number of uplink layers to 4 and introducing SU MIMO for uplinks.

Further Reading: 3GPP TS36.300:5.1.5 & 5.2.6

LTE Advanced



SCell 4

SCell 3

SCell 2

SCell 1

PCell

RLCRLC

PDCPPDCP

Data connections between Rel 10/11

LTE-A UEs and eNBs can consist of up

to 5 aggregated carriers, each of which

could carry up to 8 DL MIMO and 4 UL

MIMO layers per UE

MAC

MAC

MAC

MAC

MAC

MAC

MAC

MAC

MAC

MAC

UL/DL-SCH &MIMO

UL/DL-SCH &MIMO

UL/DL-SCH &MIMO

UL/DL-SCH &MIMO

UL/DL-SCH &MIMO

UL/DL-SCH &MIMO

UL/DL-SCH &MIMO

UL/DL-SCH &MIMO

UL/DL-SCH &

MIMO

UL/DL-SCH &

MIMO

PHY PHY

There are separate MAC HARQprocesses for each UL/DL-SCH

Each MIMO stream is generated to aseparate logical port at the LTE Physical

layer (PHY) and carries separate instancesof UL-SCH and DL-SCH


User Connections

R10 LTE-Advanced shares the same air interface protocol stack as standard R8/9 LTE, namely PDCP

over RLC over MAC over the OFDMA-based PHY (Physical Layer).

Carrier Aggregation is mainly accommodated by making changes to the MAC layer. Each UE-specific

MAC instance in an eNB and the corresponding MAC layer in each UE perform a set of functions that are

common for all active serving cells (such as MAC PDU creation and scheduling), but there is also a set of cell-specific functions performed separately for the PCell and each Scell. These functions mainly relate to

the establishment of separate HARQ sessions for each UL or DL SCH (Shared Channel) that is active.

At the Physical layer, the eNB and UE will establish separate instances of UL-SCH and DL-SCH for each

CC and for each MIMO layer on each CC that is active for the UE connection. Traffic travelling over each

of these separate physical layer connections will be scheduled capacity by the MAC layer as required to

meet the QoS agreed for each E-RAB.

The upper reaches of LTE-Advanced capability, as evidenced by the parameters associated with UE

Category 8, can in theory allow a UE to achieve 3000MBit/s on the downlink and up to 1500MBit/s on the

uplink. To enable this to take place, the UE is likely to be operating with a full set of serving cells (one

PCell and four SCells), to be using the highest available modulation scheme (64QAM on both the uplinkand the downlink) and to be using the full set of available MIMO streams. This would equate to 8 streams

per DL CC and 4 streams per UL CC – or a combined 40 separate logical downlink physical layer

connections and 20 in the uplink.

The possibility of a UE (or a network) achieving commercial support for such extreme data rates and

operating parameters in the near term is exceedingly remote and far more modest data rates of a few

hundred megabits per second is a much more achievable target for most LTE-Advanced operators.





Planned ornotional coverage

area of eNB

Typical actual

coverage areaof eNB

Area not

served by

eNB due to

shadow of

large building

LTE Relaynode

Additional

coverage

provided by

LTE Relay

node

Donor eNB

Area not served

by eNB due to

competition from a

neighbouring eNB

Area not

served by

eNB due to

geography


Relaying for LTE

Apart from carrier Aggregation, the most important other new service introduced in the Release 10

specification set was the concept of the LTE RN (Relay Node).

LTE RNs are able to relay or repeat the signal from an eNB into areas that might previously have been

difficult to penetrate, including areas where signals from an eNB were blocked by large buildings, hills or

other obstructions. An RN, positioned in the optimum location, can repeat the signal from the eNB intosuch a poorly-served area.

LTE Relays operate using two LTE air interface instances: one instance is projected towards UEs and

provides standard LTE coverage; the other instances maintains a link back to the controlling, or ‘donor’,

eNB and is used for backhaul.

The controlling eNB is known as a ‘donor’ device as it provides or donates the radio channels that will be

used by the RN. The backhaul connection between the RN and the eNB uses the resources of one or

more of the eNB’s cells and shares that resource with UEs operating within that cell’s coverage area by

defining an RN-specific scheduling channel (the R-PDCCH) and carrying traffic in subframes reserved for

RN traffic. Any traffic received by the RN will be repeated out to its set of UEs. Uplink capacity is

scheduled in the same way, with some subframes dedicated to carrying UE-RN traffic which is thenforwarded to the DeNB (Donor eNB).

The air interface connection between an RN and its DeNB operates in two modes. When an RN is

initialising it acts like a UE and requests a standard Uu data connection to allow it contact the network’s

configuration server. Once configured and operational, the RN maintains a Un interface with its DeNB

that carries adapted versions of the S1 and X2 interfaces which are proxied through the DeNB before

being forwarded to the core network. The DeNB proxies provide the RN with adapted versions of the

functions traditionally performed by the MME and S-GW.

The Relay concept adds to the configurational complexity of the LTE EUTRAN. An eNB may be

configured to support a mixture of traditional macro-cells, micro and pico cells that are propagated by a

series of remote radio antennas (or ‘powered heads’) plus a set of Relay Nodes repeating coverage into

traditionally hard-to-reach areas.

LTE Advanced



LIPA

SIPTO

Managed Remote Access

IP Flow Mobility ANDSF

Multi-Access PDNConnectivity

Local IP Access techniquesallow a registered UE to access

the resources of a home oroffice LAN (such as printers,

media servers) via the femtocellcreated by an LTE HeNB

(Home eNB)

Selective IP Traffic Offloadtechniques allow a UE and

network to negotiate to divertselected traffic flows (data orstreaming connections, for

example) on an APN-by-APNbasis to use S-GW/PDN-GW

resources that aregeographically local to the UE

These techniques allow a userto remotely access resourcesconnected to a home or officeLAN via a cellular data service

using the connectionestablished to support their

home or office HeNB femtocell

Access Network Discovery &Selection Function techniques

allow an LTE EPC to guideroaming UEs to non-3GPP

access networks (WiFi, WiMax,CDMA2000, etc) that should beable to provide connectivity and

service

Allows UEs to establishseparate but simultaneous

PDN Connectivity Services viadifferent available RATs – e.g. a

UE could have one or moreEPS Bearers established via

LTE cells and others connectedvia HSPA or EDGE at the same

time

These techniques allowoperators to more easily

integrate their cellular and WiFiaccess networks to allow UEsto more simply and effectively

hand over between themwithout losing connectivity or

service


R10/R11 Data Handling Improvements

3GPP Release 10 and 11 specifications also introduce a number of techniques designed to enhance theways in which mobile data is handled, especially when users have access to femtocells or wifi hotspots.

LIPA is designed to allow a UE to make use of the resources of a home or office LAN (to which the user has access) via LTE; the intention is that a UE could access a network printer, or send content to an

Internet-enabled TV, or stream music from a home content server, all via a LAN-connected femtocell.Managed Remote Access aims to provide the same kind of home/office LAN access service but workswhile the user is roaming away from their home femtocell; remote access to local resources is providedfrom anywhere on the LTE network via the secure connection created to serve the user’s homefemtocell.

SIPTO is designed to detect and make use of geographically local EPS Gateways (S-GW and PDN-GW)for certain PDN connections. A roaming UE may, for example, have one PDN connection (connected toan application server that only exists in the home network) directed back to an APN in a home networkPDN-GW, whilst a PDN connection to the general Internet could be directed to a local, visited network APN. SIPTO works in both roaming and non-roaming cases and an APN’s applicability for SIPTO issignalled in the user’s HSS profile.

IP Flow Mobility aims to enable better interworking between LTE and WiFi, in this case by providing themeans to seamlessly hand active connections over between LTE and Wi-Fi access devices, but only if the Wi-Fi access is controlled by the LTE network operator. A UE that, for example, has an active voicecall and is also in the process of downloading a large file from an Internet-based server, could use IPFlow Mobility to divert the data download to an active (operator-controlled) Wi-Fi connection, thusoffloading traffic from the LTE network and preventing the user from consuming unnecessary amounts of their data bundle.

Multi-Access PDN Connectivity allows an operator to make efficient use of their portfolio of cellular access systems by allowing UEs to setup simultaneous connections via more than one of them at a time.Traditionally, a multi-RAN capable UE (e.g. one that could connect to 2G, 3G and 4G access networks)would only ever be connected to one RAT at a time, and all connections would be established via theactive RAT. Multi-access PDN Connectivity allows a UE to maintain, for example, a low-bit rate VoLTE

(Voice over LTE) connection via an enhanced 2G GERAN connection whilst also maintaining a high-bitrate data streaming connection via LTE-Advanced. ANDSF (Access Network Discovery & SelectionFunction) is also designed to improve multi-RAT operations by providing a means for a UE to availableinterrogate non-3GPP access types (e.g. WiFi, WiMax, CDMA2000 cells) and negotiate with their homecore network about which of the available options is best, thus ensuring optimal roaming connectivity.




S-GW

eNB 2eNB 1

TransmissionPoint

Serving

Cell

CoMPCo-operating Set

IndirectParticipation

DirectParticipation

EPC

RRH 1.2

RRH 1.1

RRH 1.3

RRH 1.4

UL-CoMP:

Joint Reception(JR) – traffic receivedby multiple points simultaneously andpassed to serving eNB for processing

Co-ordinated Scheduling/Co-ordinatedBeamforming (CS/CB) – reception at asingle point but uplink scheduling isbased on input from multiple points

DL-CoMP:Joint Processing (JP)

Joint Transmission (JT) – traffictransmitted by multiple pointssimultaneouslyCo-ordinated Scheduling/Co-ordinated Beamforming (CS/CB) –single transmitting point withscheduling input from multiplepoints

Dynamic Point Selection (DPS) –traffic transmitted by single point buttransmitting point can vary on asubframe or RB basis


CoMP Transmission/Reception

CoMP transmission/reception was proposed as part of Release 10 LTE-Advanced as a means of

improving cell-edge coverage and of therefore boosting overall connection quality and data throughput

levels. It provides, in effect, a macro diversity facility for LTE in a manner that has also been described as

‘network MIMO’. Detailed specification of CoMP was held over the R11 and R12 work schedules.

The CoMP concept is simple; UEs located at cell edges or in other poor coverage areas may be offereda more consistent connection by either using multiple ‘points’ (eNBs, Relays, Remote Radio Heads, etc.)

to serve them or, by collating feedback from several neighbouring nodes, adjusting the scheduling

applied to them to minimize interference and improve reception quality.

CoMP operation is based on intra-site and inter-site co-ordination between eNBs; intra-site co-ordination

operates between different cells, relays and remote head units controlled by the same eNB and is

relatively simple to achieve, inter-site co-ordination operates between neighbouring eNBs and is more

complex to implement. The group of ‘points’ currently serving a UE are classed as its CoMP Co-

operating Set. Points in a set may be either ‘directly participating’, in which case they will be actively

handling traffic for the UE, or ‘indirectly participating’ in which case they will supplying measurements and

other information to assist with co-operative scheduling. CoMP can operate in both downlink (DL-CoMP)

and uplink (UL-CoMP) directions.

The two main forms of DL-CoMP are JP (Joint Processing) and DPS (Dynamic Point Selection). JP can

operate on the basis of JT (Joint Transmission), where multiple points transmit copies of the same data

in the same subframe simultaneously to improve reception of that data at the UE, or CS/CB (Co-

ordinated Scheduling/Co-ordinated Beamforming), where only the serving cell transmits data to the UE.

During CS/CB however, the serving cell and its co-operating neighbours manage scheduling to ensure

that interference to and by all UEs is minimized. In DPS only one point out of a Co-operating Set will

transmit to a UE at any one time, but the choice of which point to transmit from can vary on a subframe,

or even a Resource Block, basis.

UL-CoMP consists of JR (Joint Reception), where transmissions from a UE are received by multiple

points and are passed to the serving cell for processing, and uplink CS/CB scheduling management.


LTE Advanced



X2 interfaceeNB

eNB

ICIC

COO

MRO

MLB


SON Enhancements

Cellular networks operate in a complex, mutable environment in which new buildings are erected and old

ones are demolished, in which business and housing areas are created and abandoned, in which the

locations of potential users and their communications requirements change every day. Cellular operators

must therefore continually seek to optimize their networks to keep pace with these changes, if they want

to continue to effectively serve the needs of their subscribers.

The optimization of cellular networks involves adjusting cell parameters to adapt to new sources of

interference and adding or removing capacity to ensure that current requirements are efficiently met.

Traditionally these functions would be performed by optimization engineers working from a set of key

performance indicators derived from network equipment. Since Release 8 however, 3GPP has been

gradually increasing the range of optimization functions that can be performed automatically by the LTE

network itself; functions which are grouped under the heading of SON, or the Self-Optimizing Network.

For Release 10 and LTE-Advanced, 3GPP introduced a number of new SON facilities, including:

ICIC, which allows eNBs to exchange interference and other measurement data to co-ordinate

scheduling and other activities and is regarded as providing a subset of the functions required to support

CoMP.

COO (Capacity & Coverage Optimization) allows neighbouring eNBs to negotiate adjustments to

adjacent cells to ensure the best possible coverage and capacity is provided.

MLB (Mobility Load Balancing) allows neighbouring eNBs to co-ordinate their load balancing activities by,

for example, exchanging current load data and negotiating the handover of cell-edge users from busy

cells to less busy neighbouring cells. MRO (Mobility Robustness Optimization) allows neighbouring eNBs

to capture data related to handover failures and to investigate and solve issues such as misconfigured or

out-of-date neighbour lists that might contribute to those failures.

Further Reading: 3GPP Release Description:10.9





GLOSSARY OF TERMS





LT3600/v3.3 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

ANDSF Access Network Discovery & Selection Function

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 KeyingBSC Base Station Controller

BSIC Base Station Identity Code

BSS Base Station System

BSSAP+ Base Station System Application Part +

BSSGP Base Station System GPRS Protocol

CA Carrier Aggregation

CC Component Carrier

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

COO Capacity & Coverage Optimization

CoMP Co-ordinated Multi-Point

CP Cyclic Prefix

CPT Control PDU Type

CQI Channel Quality IndicationCRC Cyclic Redundancy Check

C-RNTI Cell Radio Network Temporary Identifier




LT3600/v3.3G.2 © Wray Castle Limited

C-RNTI Controlling Radio Network Temporary Identifier

CS Circuit Switched

CS/CB Co-ordinated Scheduling/Co-ordinated Beamforming

CSCF Call Session Control Function

CSG Closed Subscriber Group

D/C Data/Control

DAB Digital Audio Broadcasting

DCCH Dedicated Control Channel

DCI Downlink Control Information

DeNB Donor eNB

DFT Discrete Fourier Transform

DFT Discrete Fourier Transform

DHCP Dynamic Host Configuration Protocol

DiffServ Differentiated Services

DL Downlink

DL-SCH Downlink Shared Channel

DMT Discrete Multi-Tone modulation

DNS Domain Name Server DPS Dynamic Point Selection

DRA Dynamic Resource Allocation

DRB Data Radio Bearer

DRS Demodulation Reference Signals

DRX Discontinuous Reception

DSCP DiffServ Code Point

DSMIPv6 Dual Stack Mobile IP version 6

DSP Digital Signal Processor

DT Data Transfer

DTAP Direct Transfer Application Part

DTCH Dedicated Traffic Channel

DVB Digital Video BroadcastingDVB-T/H/S Digital Video Broadcasting for Terrestrial Handheld and Satellite

DVRB Distributed Virtual Resource Block

DwPTS Downlink Pilot Time Slot

DwPTS Downlink Pilot Time Slot

E Extension

E1 Extension

EARFCN E-UTRA Absolute Radio Frequency Channel Number

EARFCN E-UTRAN Absolute Radio Frequency Channel Number

EARFCN Evolved Absolute Radio Frequency Channel Number

EBI EPS Bearer Identity

ECGI E-UTRAN Cell Global Identity

eCGI Evolved Cell Global identity

ECM EPS Connection Management

EDGE Enhanced Data rates for Global Evolution

E-GPRS2 Enhanced GPRS 2

EIA EPS Integrity Algorithm

EIR Equipment Identity Register

eKSI E-UTRAN Key Set Identifier

EM Element Manager

EMM EPS Mobility Management

eNB E-UTRAN Node B

EP Elementary Procedure

EPC Evolved Packet Core

EPRE Energy Per Resource ElementEPS Evolved Packet System

E-RAB E-UTRAN Radio Access Bearer

E-RAB Evolved Radio Access Bearer





ESM EPS Session Management

ETSI European Telecommunication Standards Institute

ETWS Earthquake and Tsunami Warning System

E-UTRA Evolved Universal Terrestrial Radio Access

E-UTRAN Evolved Universal Terrestrial Radio Access Network

FA Foreign Agent

FDD Frequency Division Duplex

FDM Frequency Division Multiplexing

FFS For Further Study

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 NodeGMM 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 Time

GTP 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 2GTPv2-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 B

HeNB 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 ElementIETF 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 Identity

IMT-2000 International Mobile Telecommunications 2000

IP Internet Protocol

IP-CAN IP Connectivity Access Network

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

JP Joint Processing

JR Joint Reception

JT Joint Transmission

KASME Key Access Security Management Entries

KPI Key Performance Indicator

KSI Key Set Identifier

LA Location Area

LB Load Balancing

LCID Logical Channel ID

LCR Low Chip Rate

LI Length Indicator

LIPA Local IP Access

LSF Last Segment Flag

LTE Long Term Evolution

MAC Medium Access Control

MAC 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

MLB Mobility Load Balancing

MME Mobility Management Entity

MMEC MME Code

MMEGI MME Group Identifier

MMEI MME Identifier

MNC Mobile Network Code

MRO Mobility Robustness Optimization

MS Mobile Station

MSC Mobile-services Switching Centre

MSISDN Mobile Subscriber ISDN Number

M-TMSI MME Temporary Mobile Subscriber Identity

MTU Maximum Transmission UnitMU Multi User

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 MaintenanceOFDM 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 Rate

PCell Primary Serving Cell

PCC Policy Control and Charging

PCC Primary Carrier Component

PCCH Paging Control Channel

PCEF Policy and Charging Enforcement FunctionPCFICH Physical Control Format Indicator Channel

PCH Paging Channel

PCI Physical Cell ID

PCRF Packet Control Resource Function

PCRF Policy and Charging Rules Function

PCS PDN Connectivity Service

PDCCH Physical Downlink Control Channel

PDCP Packet Data Convergence Protocol

PDN Packet Data Network

PDN-GW Packet Data Network Gateway

PDP Packet Data Protocol

PDSCH Physical Downlink Shared ChannelPDU Protocol Data Unit

PF Paging Frame

PHICH Physical H-ARQ Indicator Channel

PHY Physical Layer

PLMN Public Land Mobile Network

PMCH Physical Multicast Channel

PMI Pre-coding Matrix Indicators

PMIPv6 Proxy Mobile IPv6

PO Paging Occasion

PPP Point-to-Point Protocol

PR Paging Record

PRACH Physical Random Access Channel

PRACK Provisional Acknowledgement

PRB Physical Resource Block

P-RNTI Paging RNTI

PS Packet Scheduling

PS Packet Switched

PSS Primary Synchronization Signal

PSTN Public Switched Telephone Networks

PTI Procedure Transaction Identity

PUCCH Physical Uplink Control Channel

PUSCH Physical Uplink Shared Channel

QAM Quaderature Amplitude Modulation

QCI QoS Class Identifier QoS Quality of Service

QPSK Quadrature Phase Shift Keying





R8 Release 8

R99 Release 99

RA Routing Area

RAC Radio Admission Control

RACH Random Access Channel

RADIUS Remote Access Dial-In User Service

RAI Routing Area Identity

RAN Radio Access Network

RANAP Radio Access Network Application Part

RAND Random Number

RAR Random Access Response

RAT Radio Access Technology/Type

RAU Routing Area Update

RB Radio Bearer

RB Resource Block

RBC Radio Bearer Control

RBG Radio Block Group

RES ResponseRF Radio Frequency

RF Resegmentation Flag

RFC Request For Comment

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

RN Relay Node

RNC Radio Network Controller

RNS Radio Network SubsystemRNSAP 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

SCC Secondary Component Carrier

SCell Secondary Serving Cells

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 BlockSIGTRAN Signalling Transport

SIM Subscriber Identity Module

SIP Session Initiation Protocol

SIPTO Selective IP Traffic Offload

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 InformationSRS Sounding reference Signals

SRVCC Single Radio VCC

SS7 Signalling System No 7

SSN Stream Sequence Number

SSS Secondary Synchronization Signal

S-TMSI SAE TMSI

SU Single User

SU-MIMO Single-User MIMO

TA Timing Advance

TA Transport Address

TA Tracking AreaTAC Tracking Area Code

TAD Traffic Aggregate Descriptor

TAI Tracking Area ID

TAU 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 Control

TPC-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 ChannelUM Unacknowledged Mode

UMTS Universal Mobile Telecommunications System




UPE User Plane Entity

UpPTS 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

VoLTE Voice over LTE

V-PCRF Visited Policy and Charging Rules Function


lt3600 lte-sae engineering overview - v3.3

Documents