LTE SAE Engineering Overview

LTE/SAE Engineering Overview Course Code: LT3600

Duration: 2 days

Technical Level: 2

... delivering knowledge, maximizing performance...

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

Wray Castle – leading the way in LTE training

www.wraycastle.com

LTE/SAE ENGINEERING OVERVIEW

First published 2009 Last updated October 2011 WRAY CASTLE LIMITED BRIDGE 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 and Patents 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

LTE/SAE Engineering Overview

II

© Wray Castle Limited

LTE/SAE ENGINEERING OVERVIEW

CONTENTS Section 1

Introduction to LTE

Section 2

LTE OFDM Physical Layer

Section 3

LTE Higher-Layer Protocols

Section 4

Major Protocols

Section 5

Evolved Packet Core

Section 6

LTE Operation

Glossary

© Wray Castle Limited

III

LTE/SAE Engineering Overview

IV

© Wray Castle Limited

LTE/SAE Engineering Overview

SECTION 1

INTRODUCTION TO LTE

© Wray Castle Limited

I

LTE/SAE Engineering Overview

II

© Wray Castle Limited

Introduction to LTE

CONTENTS LTE Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.1 Broadband Access with LTE

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.2

Architecture Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.3 LTE Development and Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.4 LTE Standards Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.5 LTE Key Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.6 Access Networks and the eNB (Evolved Node B) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.7 X2 Interface

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.8

X2 Interface Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.9 X2 Deployment and Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.10 The EPC (Evolved Packet Core) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.11 S1 Interface

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.12

Evolved Packet Core ‘S’ Interfaces

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.13

PDN Connectivity Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.14 NAS Identities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.15 EPS Area Identities Node Identifiers

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.16

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.17

E-UTRA Protocols

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.18

© Wray Castle Limited

III

LTE/SAE Engineering Overview

IV

© Wray Castle Limited

Introduction to LTE

OBJECTIVES 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

© Wray Castle Limited

V

LTE/SAE Engineering Overview

VI

© Wray Castle Limited

Introduction to LTE 100+ Mbit/s

LTE(4G) 40 Mbit/s UMTS/HSPA+ 10 Mbit/s UMTS/HSPA 400 kbit/s UMTS EDGE 1 Mbit/s GSM/EGPRS 150 kbit/s GSM/GPRS 50 kbit/s 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 significantly increased 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.

LT3600/v3.1

© Wray Castle Limited

1.1

LTE/SAE Engineering Overview Broadcast content provider

Former ‘Fixed’ Operator

Former ‘Mobile’ Operator

New market opportunities

LTE Radio Access

LTE Radio Access

New market opportunities

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 highquality voice and video telephony. LTE has a very important role in the overall telecommunications service convergence concept. LTE could provide 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.

1.2

© Wray Castle Limited

LT3600/v3.1

Introduction to LTE

LTE

SAE

EPS

UE E-UTRA

E-UTRAN

EPC

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 refers to the combined E-UTRAN and EPC.

LT3600/v3.1

© Wray Castle Limited

1.3

LTE/SAE Engineering Overview

LTE/SAE Design Aims 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 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.

1.4

© Wray Castle Limited

LT3600/v3.1

Introduction to LTE

Phase 1

Phase 2

Phase 2+

GSM900 GSM1800 GSM1900 Rel 96-98

Rel 99

Rel 4

Rel 5

Rel 6

GPRS EGPRS

Rel 7

Rel 8

Rel 9

Rel 10

Rel 8

Rel 9

Rel 10

Rel 8

Rel 9

Rel 10

EDGE

Rel 99 UMTS

Rel 4

Rel 5

Rel 6

HSDPA HSUPA IMS

Rel 7 HSPA+

LTE/SAE

LTE-A (Advanced)

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 network technology has also been undergoing a process of evolution. The evolutions that particularly affect the air interface are mainly contained in Releases 5, 6, 7 and 8. Release 5 and 6 introduced HSPA – HSDPA (High Speed Downlink Packet Access) in R5 and (HSUPA) High Speed Uplink Packet Access, or Enhanced Uplink, in R6. Release 7 outlines the changes necessary to deliver HSPA+ and Release 8 specifications begin to describe LTE – the Long Term Evolution of UMTS. Specification of LTE, generally described as 3.9G, is completed in Release 9. Specification of LTE-Advanced, a full 4G solution, is detailed in Release 10.

Further Reading: www.3gpp.org/releases LT3600/v3.1

© Wray Castle Limited

1.5

LTE/SAE Engineering Overview

LTE Signalling

LTE Traffic

SCTP

E-UTRA E-UTRAN

All-IP

EPC

LTE Key Technologies Tests and evaluations carried out during 2007 led to the publication of the Release 8 36-series of specifications, which began to detail the technological basis for LTE. Of the original four candidate air interface technologies, two were chosen for the final version: OFDMA (Orthogonal Frequency Division Multiple Access) and SC-FDMA (Single Carrier FDMA). OFDMA is employed on the LTE downlink and is expected eventually to provide peak data rates approaching 360 Mbit/s in a 20 MHz channel. SC-FDMA is employed on the LTE uplink and may deliver up to 86 Mbit/s. In addition to the air interface technologies, LTE simplifies the range of technologies employed in other parts of the network. LTE is an ‘all-IP’ environment, meaning that all air interface, backhaul and core network interfaces will carry only IP-based traffic. The need to support different protocols for different traffic types, as was the case with R99, is therefore avoided. In this all-IP environment, layer 4 transport layer functions for signalling connections are performed using an 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.

1.6

© Wray Castle Limited

LT3600/v3.1

Introduction to LTE

Inter-cell RRM Radio bearer control Connection mobility control Radio admission control Measurement control Cell configuration Dynamic resource allocation

eNB

eNB (Evolved Node B)

S1

Uu X2 RRC PDCP

S1

Evolved Packet Core

RLC MAC LTE UE

E-UTRAN

PHY

Access Networks and the eNB (Evolved Node B) The basic building blocks of the E-UTRA access network are the eNB (Evolved Node B) plus backhaul – and nothing else. All layers of the air interface protocol stack, including the elements that previously resided in the RNC (Radio Network Controller) – RRC (Radio Resource Control), RLC (Radio Link Control) and MAC (Medium Access Control) – have been moved out to the base station. As the eNB now anchors the 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 ciphering facilities over the air interface. HSDPA began the process of moving RRM (Radio Resource Management) functions, such as packet scheduling, from the RNC to the Node B. In LTE, all remaining RRC functions are devolved to the eNB, meaning that there is no longer a role for a device such as the RNC. Among the RRM functions now devolved to the eNB are radio bearer control, radio admission control, connection mobility control and the dynamic allocation (via scheduling) of resources to UEs (User Equipments) in both uplink and downlink directions. Following on from innovations in R4 and R5 networks, LTE also supports the concept of flexible associations between access and core network elements, meaning that each eNB has a choice of MME (Mobility Management Entity) nodes to which to pass control of each UE. Dynamic selection of an MME for each UE as it attaches is therefore also an eNB responsibility. The eNB also receives, schedules and transmits control channel information in its cell, including paging messages and broadcast system information, both of which are received from the MMEs. The eNB also retains many of the more traditional roles associated with base stations, such as bearer management. The eNB is responsible for routing U-plane traffic between each UE and its S-GW (Serving Gateway). The complexity of the eNB and of the decisions it is required to make are therefore much greater than for an R99 Node B.

LT3600/v3.1

© Wray Castle Limited

1.7

LTE/SAE Engineering Overview X2-C X2–AP

SCTP IP Data link layer Physical layer

X2

X2-U User plane PDUs

GTP-U UDP IP Data link layer Physical layer

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.

1.8

© Wray Castle Limited

LT3600/v3.1

Introduction to LTE X2 Interface eNode B

eNode B

eNode B

eNode B

E-UTRAN IP Transport Network

eNode B

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

© Wray Castle Limited

1.9

LTE/SAE Engineering Overview

eNB eNB X2 connected directly

eNB

eNB

X2 routed via EPC

EPC Access Router

EPC IP Backbone

Logical S1 Logical X2 Physical eNB Transmission

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 has disadvantages 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. X2 traffic 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

1.10

© Wray Castle Limited

LT3600/v3.1

Introduction to LTE HSS

NAS Security Idle State Mobility Handling

MME PCRF

EPS bearer control

IP network

Internet Mobility Anchoring

S-GW

PDN-GW

EPC

The EPC (Evolved Packet Core) The reduced complexity in the RAN is mirrored by a similar reduction in the core network, where the EPC structure consists of five main nodes, although others may be required for backwards-compatibility purposes. The MME handles control plane functions related to mobility management (authentication and security) and idle mode handling (location updates and paging), in which sense it is broadly analogous to the VLR (Visitor Location Register) or GMM (GPRS Mobility Management) functions found in legacy networks. The MME is also responsible for EPC bearer control, and so handles connection control signalling. The S-GW and PDN (Public Data Network) Gateway are broadly analogous to the SGSN (Serving GPRS Support Node) and GGSN (Gateway GPRS Support Node) found in R99 networks and perform user plane handling, switching/routing and interfacing functions. Unlike legacy systems, however, bearer control has been removed from these devices and resides with the MME. The PCRF (Policy and Charging Rules Function) handles QoS and bearer policy enforcement and also provides charging and rating facilities. Subscriber management and security functions are handled by the HSS (Home Subscriber Server), which incorporates the functions of the legacy HLR (Home Location Register) and which is already familiar from R5 elements such as the IMS (IP Multimedia Subsystem). For backwards-compatibility purposes, SGSNs deployed to legacy parts of an operator’s network can be interfaced to both the MME (for mobility management) and the S-GW (for user plane flows). The MME then provides legacy systems with an interface to the HSS, and the S-GW and PDN EPC GW assume the role previously performed by the GGSN. The packet data services of legacy (GSM/GPRS, R99 and HSPA) networks and LTE/SAE systems can therefore interwork via a unified set of core network elements if required. The gateway elements form the EPC.

LT3600/v3.1

© Wray Castle Limited

1.11

LTE/SAE Engineering Overview S1–AP

MME SCTP IP Data link layer

S1-MME

Physical layer

User plane PDUs

S1-U

GTP–U UDP IP

S-GW

Data link layer Physical layer

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.

1.12

© Wray Castle Limited

LT3600/v3.1

Introduction to LTE 2G/3G SGSN

HSS

UMTS/ GPRS

S6a

S3

UTRAN/ GERAN

PCRF

S4

MME S12 Rx+

LTE

S7 S11

S1-MME

IMS E-UTRAN

S5

S1-U

S–GW

SGi

IP Services

PDN–GW

Interworking to MME

S2

WLAN or WiMAX

Evolved Packet Core ‘S’ Interfaces In addition to the S1 interface connecting the E-UTRAN to the EPC, a broader range of ‘S’ interfaces has been defined to identify interconnections between EPC nodes and external nodes. The gateways and the MME are the main new nodes in the EPC. They are interconnected via the S5 and S11 interfaces. The SGi interface provides a connection to the operator’s IP-based services. It is likely that this will include services managed through the IMS. In this respect the S6a interface connects the MME to the HSS, and the S7 interface provides access from the PCRF to the PDN-GW (Public Data Network Gateway). The S3 and S4 interfaces provide connectivity into the EPC from legacy 2G/3G SGSNs. However, the UTRAN may be connected directly to the EPC via the S12 interface. WLAN (Wireless Local Area Network) or WiMAX (Worldwide Interoperability for Microwave Access) can be supported through the EPC via the S2 interface. This would require connectivity to the MME, which is provided by interfaces and interworking functions not shown in this diagram.

LT3600/v3.1

© Wray Castle Limited

1.13

LTE/SAE Engineering Overview

PDN Connectivity Service

Evolved Packet System EPS Bearer

PDN-GW Packet Data Network

PDN Connectivity Services The EPS is designed to provide IP connectivity between a UE and a PDN (Packet Data Network). The connection provided to a UE is referred to as a PCS (PDN Connectivity Service). This consists of an EPS Bearer that connects the UE to an Access Point in a PDN-GW and traverses both the E-UTRAN and the EPC. The PDN-GW routes traffic between the EPS Bearer and the external PDN. The EPS Bearer, in turn, carries one or more TFA (Traffic Flow Aggregate), which themselves carry one or more SDF (Service Data Flow) between the UE and an external data network. If a UE requires additional connectivity that is only available via a different PDN-GW Access Point, then additional PDN Connectivity Services may be established in parallel.

Further Reading: 3GPP TS 23.401:4.7.1

1.14

© Wray Castle Limited

LT3600/v3.1

Introduction to LTE

MCC

MNC

MMEI

M-TMSI

24 bits

32 bits

M-TMSI

GUTI

M-TMSI

32 bits

MMEC

M-TMSI

8 bits

32 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 the MME’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) LT3600/v3.1

© Wray Castle Limited

1.15

LTE/SAE Engineering Overview 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

1.16

© Wray Castle Limited

LT3600/v3.1

Introduction to LTE Gateway names/IP addresses Access Point Name (APN)

MCC

MNC

MMEI

GUMMEI

24 bits

MMEGI

16 bits

MCC

MNC

eNB ID 20 bits

MMEC

MMEI

8 bits

Cell ID

eCGI

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 belongs and 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 scope to 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 LT3600/v3.1

© Wray Castle Limited

1.17

LTE/SAE Engineering Overview

User Equipment

eNB

Evolved Packet Core

Non-Access Stratum (NAS)

Non-Access Stratum (NAS) RRC

RRC

PDCP

PDCP

RLC

RLC

MAC

MAC

Physical Layer

Physical Layer

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.

1.18

© Wray Castle Limited

LT3600/v3.1

LTE/SAE Engineering Overview

SECTION 2

LTE OFDM PHYSICAL LAYER

© Wray Castle Limited

I

LTE/SAE Engineering Overview

II

© Wray Castle Limited

LTE OFDM Physical Layer

CONTENTS 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

© Wray Castle Limited

III

LTE/SAE Engineering Overview

IV

© Wray Castle Limited

LTE OFDM Physical Layer

OBJECTIVES At the end of this section you will be able to:



describe an OFDM transmission system as a set of closely spaced orthogonal radio subcarriers



illustrate the potential performance benefit for the use of OFDM as opposed to single carrier schemes



identify typical performance characteristics of OFDM signals in multipath fading channels



describe how channel adaptation can be used to enhance the performance of OFDM systems



describe how scalability is achieved in OFDM systems



describe the basic principles of MIMO operation



identify the key benefits that can be gained from MIMO implementation



outline the general structure of the E-UTRA physical layer



define the term ‘bandwidth agnostic’ in the context of E-UTRA



define the term ‘basic timing unit’ and its relevance in E-UTRA



describe the configuration of downlink and uplink frames and list the range of frame types employed



describe the resource allocation models employed by E-UTRA including the role of the resource block, resource grid and resource element



list the modulation and error coding options made available in E-UTRA



outline the function of the reference signal



describe the functions of the E-UTRA physical channels on both uplink and downlink



outline how control and traffic channels are mapped into the physical layer structure

© Wray Castle Limited

V

LTE/SAE Engineering Overview

VI

© Wray Castle Limited

LTE OFDM Physical Layer Spacing to next allocated carrier needs to be large

f1

f1

5 kHz

f2

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

LT3600/v3.1

© Wray Castle Limited

2.1

LTE/SAE Engineering Overview Centre frequency 2 QPSK subcarriers 10 kbit/s per subcarrier 15 kHz total bandwidth

f1

f2

15 kHz Centre frequency 1 QPSK carrier 20 kbit/s 20 kHz total bandwidth

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

2.2

© Wray Castle Limited

LT3600/v3.1

LTE OFDM Physical Layer

Low bit rate parallel streams

High-bit-rate serial stream S to P

Guard period

Useful symbol period 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 counteract multipath 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.

LT3600/v3.1

© Wray Castle Limited

2.3

LTE/SAE Engineering Overview

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 the coherence 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 channel affected 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.

2.4

© Wray Castle Limited

LT3600/v3.1

LTE OFDM Physical Layer

OFDM signal with N subcarriers {b 0 , b1 , b2 …bn }

Serial data

S

P

M-ary M-ary symbol symbol N bit parallel mapping grouping streams

I (real) N complex N N-point samples in one sine cosine complex IFFT symbol period symbols Q (imaginary)

Up-conversion

D/A

fc

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 in the 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 signal during 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.

LT3600/v3.1

© Wray Castle Limited

2.5

LTE/SAE Engineering Overview

OFDM signal with N subcarriers {b 0 , b1 , b2 …bn }

Down-conversion

A/D

fc

I (real) N complex sine samples in one N-point cosine symbol period FFT Q (imaginary)

Integration and N symbol complex symbols decisions

Serial data N parallel streams

P

S

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.

2.6

© Wray Castle Limited

LT3600/v3.1

LTE OFDM Physical Layer

Data subcarriers

Reference/pilot subcarriers

Upper unused/guard Subcarriers

Lower unused/guard Subcarriers

DC subcarrier

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

LT3600/v3.1

© Wray Castle Limited

2.7

LTE/SAE Engineering Overview Symbol periods (time) 0

OFDM with time multiplexing

1

2

User 1

3

4

5

6

7

8

User 2

9

User 4

Symbol periods (time) 0

1

2

3

4

5

6

7

8

9

User 7

User 1 User 3

OFDM with time and frequency multiplexing (OFDMA)

User 8 User 2

User 4 User 9

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

2.8

© Wray Castle Limited

LT3600/v3.1

LTE OFDM Physical Layer

Poor Radio Path

Node B

Interference

Modulation (QPSK/16QAM/64QAM) Error protection coding rate Adaptive fast scheduling

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 time frames, 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.

LT3600/v3.1

© Wray Castle Limited

2.9

LTE/SAE Engineering Overview

Stream 1

Data stream Stream 2 mapping

Layer 1

Precoding matrix

Signal generation

MIMO decoding and channel estimation

Layer 2 Feedback

Power weightings and beamforming

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 the transmitter 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 at the 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.

2.10

© Wray Castle Limited

LT3600/v3.1

LTE OFDM Physical Layer 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 created by 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.

LT3600/v3.1

© Wray Castle Limited

2.11

LTE/SAE Engineering Overview 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 2x2 MIMO 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 mapped to 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.

2.12

© Wray Castle Limited

LT3600/v3.1

LTE OFDM Physical Layer OFDM and SC-FDMA Bandwidth agnostic TDD and FDD SFN for MBMS MIMO operation Physical channel structure Reference signals Modulation and coding Synchronization and timing Error coding and HARQ

RRC Logical channels

MAC

Random access Power control Reporting and feedback Measurements Handover

Transport channels

Physical Layer Physical channels

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.

LT3600/v3.1

© Wray Castle Limited

2.13

LTE/SAE Engineering Overview OFDM and SC-FDMA Bandwidth agnostic TDD and FDD SFN for MBMS MIMO operation Physical channel structure Reference signals Modulation and coding Synchronization and timing Error coding and HARQ

RRC Logical channels

MAC

Random access Power control Reporting and feedback Measurements Handover

Transport channels

Physical Layer Physical channels

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

2.14

© Wray Castle Limited

LT3600/v3.1

LTE OFDM Physical Layer

20 MHz/1200 15 MHz/900 10 MHz/600 5 MHz/300 3 MHz/180 1.4 MHz/72

Channel bandwidths (bandwidth/subcarriers)

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, but with 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 LT3600/v3.1

© Wray Castle Limited

2.15

LTE/SAE Engineering Overview

FDD

TDD

Band

UL Range (MHz)

DL Range (MHz)

Band

UL/DL Range (MHz)

1 2 3 ... 7 8 ... 13 ... 20 ... 24

1920 – 1980 1850 – 1910 1710 – 1785 ... 2500 – 2570 880 – 915 ... 777 – 787 ... 832 – 862 ... 1626.5 – 1660.5

2110 – 2170 1930 – 1990 1805 – 1880 ... 2620 – 2690 925 – 960 ... 746 – 756 ... 791 – 821 ... 1525 – 1559

33 34 35 36 37 38 39 40

1900 – 1920 2010 – 2025 1850 – 1910 1930 – 1990 1910 – 1930 2570 – 2620 1880 – 1920 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 approximately 700 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

2.16

© Wray Castle Limited

LT3600/v3.1

LTE OFDM Physical Layer 12 subcarriers

Channel bandwidth (MHz) Transmission bandwidth configuration (n x RB) Transmission bandwidth (n x RB)

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 spectral bandwidth 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 LT3600/v3.1

© Wray Castle Limited

2.17

LTE/SAE Engineering Overview

Modulation Schemes

BPSK

Signalling functions only

QPSK 16QAM 64QAM

Error Coding Schemes

1/3 Turbo Coding 1/3 CC

CRC

Optional on uplink

Traffic and most control channels 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

2.18

© Wray Castle Limited

LT3600/v3.1

LTE OFDM Physical Layer

MAC

BCCH

PCCH

CCCH

DCCH

DTCH

MAC Control

Physical layer

BCH

PBCH

PDCCH

PCH

RACH

PUCCH

PHICH

PCFICH

DL-SCH

PRACH

UL-SCH

PDSCH

PUSCH

Physical signals PSS/SSS Reference signals

Physical Channels The physical layer involves the transmission and reception of a series of physical channels and physical signals. The physical signals relate to the transmission of reference signals, the PSS (Primary Synchronization Signal) and the SSS (Secondary Synchronization Signal). The PBCH (Physical Broadcast Channel) carries the periodic downlink broadcast of the RRC MasterInformationBlock message. Note that system information from BCCH (Broadcast Control Channel) is scheduled for transmission in the PDSCH (Physical Downlink Shared Channel). The PDCCH (Physical Downlink Control Channel) carries no higher layer information and is used for scheduling uplink and downlink resources. Scheduling decisions, however, are the responsibility of the MAC layer, therefore the scheduling information carried in the PDCCH is provided by MAC. Similarly the PUCCH (Physical Uplink Control Channel) is used to carry resource requests from UEs that will need to be processed by MAC. The PHICH (Physical Hybrid ARQ Indicator Channel) is used for downlink ACK/NACK of uplink transmissions from UEs in the PUSCH (Physical Uplink Shared Channel). It is a shared channel and uses a form of code multiplexing to provide multiple ACK/NACK responses. The PCFICH (Physical Control Format Indicator Channel) is used to indicate how much resource in a subframe is reserved for the downlink control channels. It may be either one, two or three of the first symbols in the first slot in the subframe. The PRACH (Physical Random Access Channel) is used for the uplink transmission of preambles as part of the random access procedure. The PDSCH and the PUSCH are the main scheduled resource on the cell. They are used for the transport of all higher-layer information including RRC signalling, service-related signalling and user traffic. The only exception is the system information in PBCH.

Further Reading: 3GPP TS 36.213, 36.211, 36.300 LT3600/v3.1

© Wray Castle Limited

2.19

LTE/SAE Engineering Overview

Ts (Time unit) =

Ts =

1 15,000 x 2048 1 30,720,000

Ts = c. 32.5 ns

The Physical Layer Timing Unit Almost all numbers, durations and calculations related to E-UTRA are derived from a fundamental parameter known as Ts or the basic ‘time unit’. Ts represents the ‘sampling time’ of the overall channel and is itself derived from basic channel parameters. The definition of Ts is based on a 20 MHz channel bandwidth with 15 kHz subcarrier spacing and an FFT size of 2048. Ts is calculated to be the reciprocal of the subcarrier spacing multiplied by the total number of subcarriers in the FFT, or: Ts = 1/(15,000 x 2048) seconds = 3.25 nsec Frame, subframe and slot lengths, cyclic prefix durations and many other key parameters are defined as multiples of Ts. Crucially, the value of Ts does not vary between E-UTRA physical layer configurations. As Ts stays constant, all of the key parameters used to define the E-UTRA structure also stay constant. This consistency reduces the overall complexity of E-UTRA and enables system manufacturers to scale their devices more easily to a variety of channel bandwidths and frequency bands.

Further Reading: 3GPP TS 36.211:4

2.20

© Wray Castle Limited

LT3600/v3.1

LTE OFDM Physical Layer Frame – 10 ms (307200T s)

0

1

2

3

4

5

6

7

8

9 10 11 12 13 14 15 16 17 18 19 Slot – 0.5 ms (15360T s)

Subframe – 1 ms (30720T s)

0 1 2 3 4 5 6 0 1 2 3 4 5 6

CP

OFDM Symbol

Normal cyclic prefix (total per subframe 2048T s)

CP (160/144T s) 2048Ts

0 01 2 3 4 5 0 1 2 3 4 5

CP

OFDM Symbol

Extended cyclic prefix (total per subframe 6144T s)

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.

Further Reading: 3GPP TS 36.211 LT3600/v3.1

© Wray Castle Limited

2.21

LTE/SAE Engineering Overview Frame – 10 ms (307200T s) Half-frame – 5 ms (153600T s)

0

1

2

3

4

5

6

7

Slot – 0.5 ms (15360T s)

8

9 10 11 12 13 14 15 16 17 18 19

Subframe

0

2

3

4

5

7

8

9

Subframe – 1 ms (30720T s)

DwPTS

Subframe – 1 ms (30720T s)

0 1 2 3 4 5 6 0 1 2 3 4 5 6 or 0 01 2 3 4 5 0 1 2 3 4 5

GP

UpPTS

UL/DL Switching Options UL/DL Config. D 0 D 1

5 ms (half-frame) switching U

U

U

D

U

U

U

U

U

D

D

U

U

D

2

D

U

D

D

D

U

D

D

6

D

U

U

U

D

U

U

D

10 ms (full-frame) switching 3

D

U

U

U

D

D

D

D

D

4

D

U

U

D

D

D

D

D

D

5

D

U

D

D

D

D

D

D

D

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 1 and 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

2.22

© Wray Castle Limited

LT3600/v3.1

LTE OFDM Physical Layer Resource block

Resource element 1 ms subframe (2 slots)

Subcarrier 1

Subcarrier 12

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

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

© Wray Castle Limited

2.23

LTE/SAE Engineering Overview Frame

Subframe Slot 0 1 2 3 4 5 6 0 1 2 3 4 5 6 0 1 2 3 4 5 1 2 3 R0 5 0 1 2 3 4 5 0 1 2 3 4 5

6 0 1 2 3 4 5 6 1 2 3 R0 5 6 0 1 2 3 4 5 6 0 1 2 3 4 5

6 6 6 6

R0 1 2 3 5 6 R0 1 2 3 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 1 2 3 R0 5 6 1 2 3 R0 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 R0 1 2 3 5 6 R0 1 2 3 5 6

Antenna port 0 0 1 2 3 4 5 6 0 1 2 3 4 5 6 0 1 2 3 4 5 6 0 5 6 R1 R1 1 2 3 0 1 2 3 4 5 6 0 0 1 2 3 4 5 6 0

1 2 3 4 5 6 1 2 3 5 6 1 2 3 4 5 6 1 2 3 4 5 6

Antenna port 0

1 2 3 R1 5 6 1 2 3 R1 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 5 6 R1 1 2 3 5 6 R1 1 2 3 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 1 2 3 R1 5 6 1 2 3 R1 5 6

Antenna port 1

Antenna port 1

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 single subframe 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

2.24

© Wray Castle Limited

LT3600/v3.1

LTE OFDM Physical Layer

Frame Subframe Slot 0 1 2

DRS

4 5 6 0 1 2

DRS

4 5 6

0 1 2 0 1 2

DRS

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

DRS

4 5 6 4 5 6

0 1 2 0 1 2

DRS

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

DRS

0 1 2 0 1 2

DRS

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

DRS

0 1 2 0 1 2

DRS

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

DRS

0 1 2 0 1 2

DRS

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

DRS

DRS

DRS

4 5 6 4 5 6

0 1 2

DRS

4 5 6 0 1 2

DRS

4 5 6

DRS

DRS

DRS

DRS

DRS

DRS

DRS

DRS

4 5 6 4 5 6 4 5 6 4 5 6 4 5 6 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.

LT3600/v3.1

© Wray Castle Limited

2.25

LTE/SAE Engineering Overview

2.26

© Wray Castle Limited

LT3600/v3.1

LTE/SAE Engineering Overview

SECTION 3

LTE HIGHER-LAYER PROTOCOLS

© Wray Castle Limited

I

LTE/SAE Engineering Overview

II

© Wray Castle Limited

LTE Higher-Layer Protocols

CONTENTS 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

© Wray Castle Limited

III

LTE/SAE Engineering Overview

IV

© Wray Castle Limited

LTE Higher-Layer Protocols

OBJECTIVES At the end of this section you will be able to:



identify the functions of the RRC protocol



define the RRC protocol connected mode and idle mode states for a UE



explain the use of signalling radio bearers for the transfer of RRC signalling



describe the procedures for the broadcasting of system information by RRC



explain the relationship between signalling radio bearers, data radio bearers and EPS bearers



describe the operation of RRC connection establishment



describe how data radio bearers and EPS bearers are established, modified or removed



explain the measurement configuration and reporting procedures



explain how RRC carries NAS signalling over the air interface



identify the three sublayers: PDCP, RLC and MAC within layer 2 for E-UTRA



explain the key functions of each sublayer within layer 2



list the logical and transport channels defined for information interchange in layers 2 and 1



explain the function and multiplexing options for logical and transport channels



describe the functional architecture of PDCP



describe the functional architecture of RLC



list and explain the three modes of operation for RLC: transparent mode, unacknowledged mode and acknowledged mode



describe the MAC functional architecture



explain MAC functions in respect of logical channel prioritization and scheduling



explain the general operation of the random access process



describe how HARQ is implemented between the MAC layer and the physical layer

© Wray Castle Limited

V

LTE/SAE Engineering Overview

VI

© Wray Castle Limited

LTE Higher-Layer Protocols Control plane

System information Paging

User plane

RRC dedicated control and NAS direct transfer SRB0

SRB1

Service signalling traffic

SRB2

NRT data traffic

DRB1

RT data traffic

DRB2

DRB3

PDCP SAPs PDCP

ROHC Integrity and Integrity and ciphering ciphering

RLC SAPs

TM

TM

TM

RLC Logical channels

AM RLC PDU and ARQ

BCCH

MAC

PCCH

CCCH

AM RLC PDU and ARQ

DCCH1

ROHC

Ciphering Ciphering

AM

ROHC Ciphering

AM

UM

RLC PDU RLC PDU RLC PDU and ARQ and ARQ

DCCH2

DTCH1

DTCH2

DTCH3

Scheduling and priority handling

Multiplexing and HARQ control

Transport Channels Physical layer

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. At the 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 multiplexing logical channels to transport channels at the physical layer. MAC also controls scheduling for resource allocation at the physical layer as well and control for a number of physical layer processes.

Further Reading: 3GPP TS 36.300 LT3600/v3.1

© Wray Castle Limited

3.1

LTE/SAE Engineering Overview

Logical PCCH channels

BCCH

CCCH

DCCH

DTCH

MAC control

MAC Logical channel prioritization (UL only)

Control

Multiplexing/demultiplexing

Random access control

HARQ

Transport channels

PCH

BCH

DL-SCH

UL-SCH

RACH

Grant and HARQ signalling

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 flows into the physical layer through transport channels. The mapping of logical channels to transport channels is a key function of the MAC layer. In addition to channel mapping, the MAC layer has important control functionality including management of multiple HARQ processes for each information flow and the random access process. Most significantly, the MAC layer is responsible for channel prioritization and scheduling of resources on the physical layer. The MAC layer has a null function for paging and for system information that will be transmitted in the BCH (Broadcast Channel) transport channel.

Further Reading: 3GPP TS 36.321:4.2.1

3.2

© Wray Castle Limited

LT3600/v3.1

LTE Higher-Layer Protocols Bursty data

VoIP or other conversational services

Dynamic scheduling

Persistent scheduling

MAC (PDCCH)

MAC (PDCCH) RRC (DL-SCH)

Semi-Persistent scheduling

MAC Uplink Grant(PDCCH) Data

Data

Data

Data

Data

MAC Downlink Assignment (PDCCH) 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 meet more demanding QoS requirements, LTE offers persistent scheduling. This is achieved through a combination of RRC signalling in the DL-SCH (Downlink Shared Channel), for the initial specification of the resource allocation interval, and MAC signalling in the PDCCH for more specific PRB and MCS information. The result is a lower overhead in the PDCCH for these regular resource allocations. The third scheduling option, known as semi-persistent scheduling, is used specifically for the purpose of resource allocation for the establishment or reconfiguration of a persistent scheduled resource, i.e. for the transport of RRC messages relating to the persistent scheduled resource. In this case an SPS-C-RNTI (Semi Persistent Scheduling) will be used to address the UE, which is different from the UE’s C-RNTI.

Further Reading: 3GPP TS 36.321, 36.331 LT3600/v3.1

© Wray Castle Limited

3.3

LTE/SAE Engineering Overview MAC Entity

Physical Radio link Physical layer layer

MAC Entity

L2/L3 Message CCCH

RACH and preamble instructions PRACH

CRC scrambled with RA-RNTI

Resource allocation for RAR PDCCH RAR DL-SCH/PDSCH

RACH indication RAR (Random Access Response) DL-SCH • Timing Advance • UL Grant • Temporary C-RNTI

L2/L3 Message

MAC PDU [L2/L3 Message] UL-SCH/PUSCH

CCCH

Contention check. Temporary C-RNTI becomes the allocated C-RNTI

Resource allocation for CRI PDCCH

CRI (Contention Resolution Identity) DL-SCH

CRI DL-SCH/PDSCH

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 and timing 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

3.4

© Wray Castle Limited

LT3600/v3.1

LTE Higher-Layer Protocols

RNTI

Usage

RA-RNTI

MAC random access response

Temporary C-RNTI

C-RNTI

Logical channel ---

Transport channel

Value range

DL-SCH

0001–003C

Contention resolution when no C-RNTI is available

CCCH

DL-SCH

0001–FFF3

Initial L3 message transmission

CCCH/DCCH/DTCH UL-SCH

0001–FFF3

Dynamically scheduled unicast transmission

DCCH/DTCH

0001–FFF3

Triggering of PDCCH ordered random access

UL-SCH/DL-SCH

---

---

0001–FFF3

Semi-Persistent Scheduling C-RNTI

Semi-persistent scheduled unicast transmission

SI-RNTI

Broadcast of system information

BCCH

DL-SCH

FFFF

P-RNTI

Paging and system information change notification

PCCH

PCH

FFFE

TPC-PUCCH-RNTI

Uplink power control

---

---

0001–FFF3

TPC-PUSCH-RNTI

Uplink power control

---

---

0001–FFF3

DCCH/DTCH

Deactivation of semi-persistent scheduled unicast transmission

UL-SCH/DL-SCH

---

---

0001–FFF3 0001–FFF3

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 Types The table summarizes the RNTI types defined for E-UTRA. In all cases they have a length of 2 octets and for some RNTI types there is a limited number range or specific reserved values. Outside of these reserved values there is no structure to the RNTI. A SPS-C-RNTI is allocated to a UE when Semi-Persistent scheduling is used and indicates resources for higher-layer signalling that relates the UE's current persistently scheduled resource. The range of potential values will therefore be dependent on the PRACH configuration used in a cell. Any number in this range cannot be allocated for use as any other RNTI type. An Temporary C-RNTI is allocated to a UE on initial access as part of the random access procedure. On successful completion of the random access procedure the Temporary C-RNTI becomes the C-RNTI. This is cell specific and is the main identity for the UE within the cell. A SPS-C-RNTI is allocated to a UE when persistent scheduling is used and indicates resources for higher-layer signalling that relates the UE’s current persistently scheduled resource. The fixed SI-RNTI (System Information RNTI) and P-RNTI (Paging RNTI) are used to indicate the allocation of resources in the PDSCH containing system information or paging respectively. TPC-PUCCH-RNTI (Transmit Power Control PUCCH RNTI) and TPC-PUSCH-RNTI are used to indicate power control information for the PUCCH and PUSCH respectively.

Further Reading: 3GPP TS 36.321:7.1 LT3600/v3.1

© Wray Castle Limited

3.5

LTE/SAE Engineering Overview

Logical channels Scheduling

eNB

Multiplexing and prioritization

Transmission Requirement Indications The UE will neither receive nor transmit information unless it is scheduled to do so because there is no dedicated radio resource in E-UTRA. Therefore, for every signalling message or data packet some signalling activity must be performed and this must be preceded by a resource request. Downlink resource allocation is triggered by need in the eNB. All resource allocations are indicated in the PDCCH. For uplink transmission the UE must first indicate its need to the eNB. There are a number of mechanisms that can result in a scheduled resource being indicated for a UE in the PDCCH. For initial access, or where the UE has not been active for some time, the random access procedure can be used for resource requests. When a mobile is continuously active it may be allocated a resource in the PUCCH to use for resource requests needed for further data or signalling transfer. Additionally, the eNB can request buffer status reports from UE that are currently active. Based on this information the eNB makes scheduling decisions. In the uplink direction it is the MAC layer within the UE that determines how an allocated transmission resource should be demarcated between a number of different logical channels. This is based on channel priority and channel PBR (Prioritized Bit Rate).

Further Reading: 3GPP TS 36.321, 36.331

3.6

© Wray Castle Limited

LT3600/v3.1

LTE Higher-Layer Protocols

BCCH

PCCH

CCCH

DCCH

DTCH

BCH

PCH

RACH

DL-SCH

UL-SCH

PRACH

PDSCH

PUSCH

Logical channels

RRC PDCP RLC MAC Physical layer

PBCH

Transport channels

Physical channels

L2/L1 Channel Mapping Logical channels are mapped by the MAC layer to transport channels on entry to the physical layer, and then ultimately to physical channels within the physical layer. The BCCH is used for system information broadcasting and carries three RRC message types. The MasterInformationBlock message is mapped to the BCH transport channel and then to the PBCH. All other system information messages are mapped to the DL-SCH and PDSCH. The PCCH (Paging Control Channel) carries paging messages and is mapped to the PCH (Paging Channel) and PDSCH. The CCCH (Common Control Channel), DCCH (Dedicated Control Channel) and DTCH (Dedicated Traffic Channel) are all bidirectional channels and will be mapped to the DL-SCH and PDSCH for downlink flows and UL-SCH (Uplink Shared Channel) and PUSCH for uplink flows. The PRACH and RACH are used only in the uplink for initiating RRC connectivity. The random access process involves an interaction at the physical layer under the control of MAC. There is no higher layer information in the random access channels but the process will result in the allocation of resources for higher-layer message exchange.

Further Reading: 3GPP TS 36.300, 36.212, 36.321 LT3600/v3.1

© Wray Castle Limited

3.7

LTE/SAE Engineering Overview

Transmit side

Receive side

RLC Transmit transparent mode entity

Transmit unacknowledged mode entity

Acknowledged mode entity

Receive unacknowledged mode entity

Receive transparent mode entity

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 and receive functionality for one side of the link. This configuration facilitates retransmission of failed RLC PDUs.

Further Reading: 3GPP TS 36.322:4.2.1

3.8

© Wray Castle Limited

LT3600/v3.1

LTE Higher-Layer Protocols

PDCP PDUs

PDCP PDUs

TM-SAP

TM-SAP

RLC SDUs Receiving TM-RLC entity

Transmitting TM-RLC entity Transmission buffer

RLC PDUs BCCH/PCCH/CCCH

BCCH/PCCH/CCCH

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

© Wray Castle Limited

3.9

LTE/SAE Engineering Overview PDCP PDUs

PDCP PDUs

UM-SAP

UM-SAP

RLC SDUs Transmitting UM-RLC entity

Transmission buffer

SDU SDU

SDU

Segmentation and concatenation Add RLC header

SDU reassembly

Receiving UM-RLC entity

Remove RLC header

H

H

Reception buffer and HARQ reordering

RLC PDUs DTCH

DTCH

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 in the diagram, higher-layer SDUs can be fragmented and reassembled into the RLC PDU payload area to produce a packet size suitable for scheduling by the MAC layer for transmission over the air interface. The RLC header enables the receiving entity to reassemble the higher-layer SDU in the correct order. The application of unacknowledged mode is limited to the user plane, where it would be utilized for packet traffic flows with low tolerance to delay. The most common example would be VoIP connections.

Further Reading: 3GPP TS 36.322:4.2.1.2

3.10

© Wray Castle Limited

LT3600/v3.1

LTE Higher-Layer Protocols PDCP PDUs AM-SAP RLC SDUs Transmitting part of the AM-RLC entity

RLC SDUs

Transmission buffer

Segmentation and concatenation

RLC Control

Retransmission buffer

SDU reassembly

Receiving part of the AM-RLC entity

Remove RLC header

Reception buffer and HARQ reordering Add RLC header Routing

RLC PDUs

RLC PDUs DCCH/DTCH

DCCH/DTCH

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 provides retransmission of failed RLC PDUs. In this respect a number of enhancements in functional architecture are provided. Firstly, a single entity for transmission and reception is required for interaction between the transmitting and receiving side. Secondly a retransmission buffer is required in the transmit side. All transmitted RLC PDUs are retained in the transmission buffer until acknowledgement is received. Additionally, control (status) PDUs are required in addition to data PDUs in order to manage the retransmission process. These must be multiplexed with data PDUs at the transmission end and demultiplexed (routed) from data PDUs at the reception end.

Further Reading: 3GPP TS 36.322:4.2.1.3 LT3600/v3.1

© Wray Castle Limited

3.11

LTE/SAE Engineering Overview

Radio bearers (SRB/DRB) PDCP-SAP

Sequence numbering

PDCP-SAP

PDCP-SAP

Header compression (U-plane only)

PDCP PDCP entity

PDCP entity

Packets from RBs

PDCP entity

Integrity protection (C-plane only) UM-SAP

UM-SAP

AM-SAP

PDCP control packets

Ciphering RLC Add PDCP header

PDCP Functional Architecture A PDCP entity is created for each SRB and/or DRB on a per-UE basis. All PDCP entities are bidirectional, thus when the AM mode of RLC is being used there is a one-to-one mapping between a PDCP entity and AM SAP in RLC. However, for the UM mode of RLC one PDCP entity will be associated with two UM SAPs, one configured for transmit functions and the other configured for receive functions. Within a PDCP entity sequence numbering is applied for higher layer PDUs. This ensures in-order delivery at the receiving end. In the user plane PDCP control PDUs can be used to indicate missing PDUs. In the user plane, only IETF-defined ROHC (Robust Header Compression) is provided. Support for this is only mandatory for UEs that have VoIP (Voice over IP) capability. In the control plane, integrity protection is provided for RRC signalling messages. Ciphering is then applied in both control and user planes, although separate cipher keys are applied for a given UE in the two planes.

Further Reading: 3GPP TS 36.323:4.2.2

3.12

© Wray Castle Limited

LT3600/v3.1

LTE Higher-Layer Protocols RRC System information broadcasting Paging Connection management Temporary identity management Handover management QoS management NAS signalling direct transfer UE NAS EMM ECM

eNB Data Traffic

RRC

EPC NAS EMM ECM

Data Traffic

RRC

AS (Access Stratum)

AS (Access Stratum)

L2

L2

L1

L1

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; and direct 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 up to six sharing PLMNs. Each eNB is responsible for managing inter-cell handovers between all the cells it controls. When handover to another cell site is required the eNB will pass details of the current UE context to its neighbour. This includes details of identities used, historical measurements taken and active EPS bearers.

Further Reading: 3GPP TS 36.300, 36.331 LT3600/v3.1

© Wray Castle Limited

3.13

LTE/SAE Engineering Overview 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

RRC CONNECTED

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

Further Reading: 3GPP TS 36.300, 36.331

3.14

© Wray Castle Limited

LT3600/v3.1

LTE Higher-Layer Protocols

Control Plane

User Plane Traffic data including service related signalling (e.g. IMS signalling)

NAS

RRC System Information and paging

BCCH/PCCH

RRC Connection establishment

RRC dedicated control

NAS direct transfer

SRB 0

SRB 1

SRB 2

CCCH

DCCH

DCCH

DRB 0

DRB 1

DRB n

DTCHs

Layer 2 Logical Channels

Signalling Radio Bearers RRC exists only in the control plane of the air interface AS protocol stack. RRC receives information from functional entities in the NAS (Non Access Stratum) in the form of complete messages for direct transfer, and also in the form of requests, information elements and parameters that will trigger RRC activity and be used in RRC messages. For broadcast functions over the air interface RRC messages are mapped directly to logical channels. This includes paging and system information broadcasting using the PCCH and BCCH logical channels respectively. For dedicated signalling functions between a UE and an eNB signalling flows are mapped into an SRB. When a UE transitions to the RRC connected state a set of SRB instances is created. SRB 0 is used only for the initial establishment of the RRC connection and is mapped to the CCCH. Once the RRC connection is established the UE will be issued with a C-RNTI and SRB 1 and optionally SRB 2 will be created. SRB 1 is used for all RRC specific signalling functions. SRB 2 is used for RRC direct transfer of NAS signalling messages. However, NAS messages may also be piggybacked with RRC signalling in SRB 1. Both SRB 1 and SRB 2 are mapped to DCCH logical channels. If required, one or more DRB may be created during or subsequent to an RRC connection establishment. These exist in the user plane and carry traffic. However, ‘traffic’ in this context includes service-related signalling between service applications in higher layers, for example VoIP connection establishment using the IMS. DRBs are mapped to DTCH logical channels.

Further Reading: 3GPP TS 36.331:4.2.2 LT3600/v3.1

© Wray Castle Limited

3.15

LTE/SAE Engineering Overview

eNB

Essential and basic frequently transmitted parameters

All other parameters with flexible scheduling indicated in SIB 1

SIB 1

MIB

SIB 2-11

SystemInformation message

IE BCCH MasterInformationBlock (40 ms periodicity)

BCH

DL-SCH

SystemInformationBlockType1 (80 ms periodicity)

SystemInformation (Other SIBs)

System Information Broadcasting A ‘bootstrap’ approach is adopted for system information broadcasting on the E-UTRA air interface. The physical layer is primarily a dynamically scheduled resource with very little permanently defined capacity. Therefore, although a BCH transport channel and corresponding physical layer resource exist, this is only used to carry the MIB (Master Information Block). The position of the MIB can be determined by the UE as it performs initial synchronization with the cell. The MIB contains only basic information enabling the UE to find and read the RRC message SystemInformatioBlockType1. This message in turn provides the scheduling information for the RRC SystemInformation messages being transmitted on the cell. SystemInformation messages contain one or more information elements, each of which will be a SIB (System Information Block). It is the SIBs that provide the complete set of system information for a UE. The operator determines which SIBs are transmitted, and how frequently, dependent on configurations, capabilities and services supported.

Further Reading: 3GPP TS 36.331:5.2

3.16

© Wray Castle Limited

LT3600/v3.1

LTE Higher-Layer Protocols

eNB MME

Service application

NAS

SRBs

NAS

NAS

RRC

RRC

DRBs

S1-AP

S1-AP

RRC connection

Service application

S1-AP connection Traffic

EPS bearer

External PDN

Traffic

PDN-GW

RRC Connection Structure The overall function of RRC is to create, maintain and clear DRBs as required to provide the radio link segment of one or more EPS bearer relating to one or more EPS connectivity service. RRC receives instructions on what EPS bearers are required from the NAS. The NAS activity in turn is driven by instructions from service applications (via the PCRF on the EPC side). In order to manage DRBs, RRC must exchange signalling with its peer entity and provide direct transfer for NAS signalling exchange. Connectivity for this comes from SRBs. However, signalling relating to service applications, which are always external to the LTE/EPS, are treated as traffic flows and as such are carried in DRBs within an EPS bearer. Note that an EPS bearer has only one set of associated QoS characteristics, so if application signalling were to require different QoS treatment to the traffic that it facilitates then a second EPS bearer would have to be defined. Multiple EPS bearers may or may not be part of the same EPS connectivity service dependent on their respective connectivity requirements.

Further Reading: 3GPP TS 36.300, 36.331 LT3600/v3.1

© Wray Castle Limited

3.17

LTE/SAE Engineering Overview

eNB

RRCConnectionRequest CCCH/UL-SCH (RACH/C-RNTI established)

UE Initial Identity (S-TMSI or 40-bit random value) cause value (Emergency, high-priority access, MO signalling, MO data, MT access)

SRB 0 RRC Transaction Identifier dedicated radio resource configuration for SRB 1

RRCConnectionSetup CCCH/DL-SCH

RRCConnectionSetupComplete DCCH/UL-SCH

SRB 1

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

3.18

© Wray Castle Limited

LT3600/v3.1

LTE Higher-Layer Protocols

eNB

RRCConnectionReconfiguration

SRB 1

DCCH/DL-SCH RRCConnectionReconfigurationComplete

DCCH/UL-SCH

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 any SRBs 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 LT3600/v3.1

© Wray Castle Limited

3.19

LTE/SAE Engineering Overview

MME

NAS

NAS

eNB

RRC

DLInformationTransfer [NAS message]

DCCH/DL-SCH

SRB 2

RRC

ULInformationTransfer [NAS message]

DCCH/UL-SCH

SRB 2

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.

3.20

© Wray Castle Limited

LT3600/v3.1

LTE/SAE Engineering Overview

SECTION 4

MAJOR PROTOCOLS

© Wray Castle Limited

I

LTE/SAE Engineering Overview

II

© Wray Castle Limited

Major Protocols

CONTENTS EPS Major Protocols IETF Dependence

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.1

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.2

IP in the EPS/IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.3 3GPP Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.4 Legacy GTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.5 GTP in the EPS

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.6

S1AP (S1 Application Protocol) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.7 S1AP and SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.8 X2AP (X2 Application Protocol) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.9 X2AP and SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.10

© Wray Castle Limited

III

LTE/SAE Engineering Overview

IV

© Wray Castle Limited

Major Protocols

OBJECTIVES At the end of this section you will be able to:



discuss the derivation of the major protocols employed by the EPC and highlight the organizations responsible for specifying them



list the set of major protocols defined by the IETF



outline the support the EPC provides for deployment of different versions of IP



describe the IP mobility concept and provide an outline of the functions of MIP, PMIP and DSMIP



discuss the transport layer protocols that are available for use in the EPC



describe the specific features of SCTP that make it suitable for transporting signalling flows over the EPC



outline the basic concepts employed by SCTP



discuss the role of SIP within the EPC and IMS and the supplementary functions performed by SDP and RTP



describe the functions performed by DiffServ within the EPC



outline the role of the Diameter protocol and discuss its use within the EPC



list the set of 3GPP-specific protocols developed or adapted for use in the EPC



describe the role performed by GTP in legacy 3GPP networks and highlight the differences between those versions and GTPv1-U and GTPv2-C



outline the functions performed by the S1 Application Protocol and the X2 Application Protocol



describe the message types and formats employed by the S1 and X2 protocols

© Wray Castle Limited

V

LTE/SAE Engineering Overview

VI

© Wray Castle Limited

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

© Wray Castle Limited

4.1

LTE/SAE Engineering Overview

IETF

SDP

RTCP SIP

Diameter

RTP

UDP

SCTP IPv4/IPv6

TCP DiffServ

Mobile IP

Underlying Transport

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

4.2

© Wray Castle Limited

LT3600/v3.1

Major Protocols

Access Network

IPv4 Internet

IPv6 EPS

IPv4 EPS

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 to operate 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 managed automatically (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 LT3600/v3.1

© Wray Castle Limited

4.3

LTE/SAE Engineering Overview

3GPP

GTPv2

X2AP S1AP

3GPP Protocols The Evolved Packet Core employs a number of protocols designed by 3GPP and ETSI (European Telecommunications Standards Institute). These include GTP (the GPRS Tunnelling Protocol), S1AP (S1 Application Protocol) and X2AP (X2 Application Protocol).

Further Reading: 3GPP TS 29.274 (GTPv2-C), 36.41x (S1), 36.42x (X2)

4.4

© Wray Castle Limited

LT3600/v3.1

Major Protocols GTPv0 Tunnels GGSN

R97 2G PS core User traffic flow

SGSNs

RNC

GTPv1 Tunnels

R99

GTP-C and GTP-U tunnels

GGSN

3G PS core GTP-U direct tunnel

User traffic flow

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 GTPv0 placed tunnel control and administrative information in fields in the headers of packets that also encapsulated user data. This meant packets that carried user data but no control information had a greater amount of header overhead than necessary, leading to a potentially inefficient service. GTPv1 was developed to offer an evolved service to 3G packet core networks. The most obvious difference with GTPv0 was the extension of the service beyond the SGSN and down to the RNC. Another major difference was the separation of the protocol into parts that dealt with control plane (GTP-C) and user plane (GTP-U) traffic. GTP-U packet headers could therefore be smaller and offer a more efficient service, as all control data was carried in its own logical stream.

Further Reading: 3GPP TS 23.060 LT3600/v3.1

© Wray Castle Limited

4.5

LTE/SAE Engineering Overview RNC

GTP-U GTP-U and GTP-C GTP-U and RANAP GTP-C

SGSN

Iu

S3 S10

MME

S12

MME

S4 S11

Roaming EPS

X2

S5

S1-U

S-GW

S8

PDN-GW

GTP in the EPS GTPv2 (GTP version 2) was developed to allow the control of the tunnelling service offered by the protocol to adapt to the specific needs of the EPS environment. C-plane functions on GTP-based interfaces are handled by GTPv2-C, while U-plane traffic tunnelling continues to be handled by GTPv1, now known as GTPv1-U. In v1, GTP-C was used to carry tunnel creation and management messages between the GSNs and between the RNC and SGSN. To reflect the separation of bearer management and routing functions into the MME and S-GW respectively, in GTPv2-C the protocol is also used to carry bearer creation and management directives over the S11 interface between those nodes. The main functional evolution that GTPv2-C needs to support is the creation of default and dedicated EPS bearers on the S5 and S8 interfaces between S-GW and PDN-GW. GTPv2-C is also employed on the S3 interface that connects the MME to legacy SGSNs and on the S10 interface that interconnects MMEs. SGSNs that support the S4 interface to the EPC may also be upgraded to support the S16 interface in place of the legacy Gn; the S16 is also based on GTPv2-C. GTP-C is not employed on the S1-MME and X2 interfaces, where bearer creation and management is instead handled by interface specific Application Protocols (S1AP and X2AP), although GTPv2-C does carry instructions to the S-GW regarding the establishment of GTP tunnels that will then run over the S1U interface. GTPv1-U is employed to encapsulate and route user plane traffic on all traffic-carrying interfaces, including S1, X2, S4, S5, S8, S12 and S16.

Further Reading: 3GPP TS 23.401, 29.274 (GTPv2-C); 29.281 (GTPv1-U)

4.6

© Wray Castle Limited

LT3600/v3.1

Major Protocols

S1–AP

MME

SCTP IP

S1-MME

L2 L1

E-RAB management Initial context transfer

eNB

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

© Wray Castle Limited

4.7

LTE/SAE Engineering Overview

MME Pool MME

MME S1 -MME

MME eNB S1 over SCTP Association eNB and MME act as SCTP endpoints

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

4.8

© Wray Castle Limited

LT3600/v3.1

Major Protocols

X2-CP (Control Plane) X2-AP

SCTP IP Data link layer X2

Physical layer 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 LT3600/v3.1

© Wray Castle Limited

4.9

LTE/SAE Engineering Overview

X2

E-UTRAN IP transport X2 eNB Z

eNB A X2 over SCTP Association

X2

Neighbouring eNBs act as SCTP endpoints

X2 interfaces are only required between eNBs that are likely to be required to hand traffic over between the cells they control.

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

4.10

© Wray Castle Limited

LT3600/v3.1

LTE/SAE Engineering Overview

SECTION 5

EVOLVED PACKET CORE

© Wray Castle Limited

I

LTE/SAE Engineering Overview

II

© Wray Castle Limited

Evolved Packet Core

CONTENTS 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.9 EMM 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 CS Fallback

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.30

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

© Wray Castle Limited

III

LTE/SAE Engineering Overview

IV

© Wray Castle Limited

Evolved Packet Core

OBJECTIVES At the end of this section you will be able to:



outline the functions performed by EPC elements



discuss options for interworking the EPC with legacy packet core networks



describe the main points of interest related to EPC topics such as pooling



list the set of S interfaces described for the EPC and outline their basic functions and protocols



discuss options for User Plane connectivity between a UE and a PDN-GW



outline how combinations of redundant S interfaces can provide for EPC resilience



list the basic set of identifiers used to describe EPC areas



outline the set of node identifiers that have been defined for the EPC



discuss the impact of the evolved device/subscriber identifiers employed by the EPC



outline the fundamental properties of an EPS Bearer and describe the structure of an EPS Bearer ID



describe the relationship that exists between an EPS Bearer and an E-RAB



outline the role of the APN (Access Point Name) in the handling of a PCS



describe the interaction between the EPC and the GTP



outline the interaction between the EPC, GTP and IP



discuss the concept of the PCS and its relevance within the EPC



outline the functions of the default EPS Bearer



describe the differences between the default and dedicated bearer types and outline their relationship with the Service Data Flow



describe the EPC connection hierarchy and list the set of parameter types that define them



outline the QoS concepts employed by the EPC and define the roles of the QCI and the ARP



outline the methods that are available for providing CS services to EPS attached UEs, including Generic Access Network functions, CS Fallback and Voice Call Continuity



outline the security functions employed by the EPC

© Wray Castle Limited

V

LTE/SAE Engineering Overview

VI

© Wray Castle Limited

Evolved Packet Core 2G/3G SGSN

HSS

Network Access UMTS/ GPRS

IP Functions S3

UTRAN/ GERAN

S4

S6a

PCRF

MME

S12

LTE

S1-MME

S7/Gx

S11

Rx+

IMS S5

S1-U

SGi

E-UTRAN Interworking to MME

S–GW

PDN–GW

S2

WLAN or WiMAX

IP Services Mobility Management Anchoring Network Management

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 new EPS 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 from becoming overloaded.

Further Reading: 3GPP TS 23.401:4.3 LT3600/v3.1

© Wray Castle Limited

5.1

LTE/SAE Engineering Overview

User Equipment

Uu

eNode B

S1

Non-Access Stratum (NAS) Access Stratum (AS)

Evolved Packet Core

Non-Access Stratum (NAS) Access Stratum (AS)

Network Logical Structure As with UMTS R99, the services provided to UEs by the EPS are divided into those handled by the AS and those provided by the NAS. The AS comprises all of the functions performed by the E-UTRAN. The NAS consists of the Bearers and bearer control signalling functions that support them. The S1AP includes provision for the direct transfer of NAS signalling between UE and MME via the eNB. Compared to the core network architecture of previous generations of mobile system such as GSM or R99 UMTS, the EPC has been provided with a much ‘flatter’ network design, which limits the number of node types deployed.

Further Reading: 3GPP TS 36.300

5.2

© Wray Castle Limited

LT3600/v3.1

Evolved Packet Core Mobility Management Entity (MME)

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

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 UEs and issues appropriate instructions to the S-GW that will handle each user plane connection. The EMM functions also include responsibility tracking UEs that are in idle mode and the MME ensures ‘UE Reachability’ by receiving TAU messages, maintaining the tracking area lists and performing paging of individual UEs when required. To assist with service resilience, MMEs can be grouped into ‘pools’. eNBs are able to contact any MME within the pool(s) with which they are associated when passing on UE Attach requests. The MME then has flexibility as to the S-GW chosen to establish the user plane connection for each UE. The MME is also in charge of roaming and handover functions to 2G/3G SGSNs.

Further Reading: 3GPP TS 23.401:4.4.2 LT3600/v3.1

© Wray Castle Limited

5.3

LTE/SAE Engineering Overview

Serving Gateway (S-GW)

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

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) access networks. As all EPS user traffic must pass through an S-GW it is a logical node within which, in concert with the PDN-GW, to base the EPS Lawful Interception interface and also the charging functions. The standard S5 and S8 interfaces that link the S-GW and PDN-GW are based on the 3GPP GTP; many non-3GPP systems obtain similar IP mobility functionality by employing the MIPv4 (Mobile IPv4) or PMIPv6 (Proxy Mobile IPv6) protocols developed by the IETF (Internet Engineering Task Force). Adapted versions of the S5 and S8 interfaces are available that support the PMIP protocol for IP mobility. In such cases, the S-GW will also act as the FA (Foreign Agent) to anchor mobile IP tunnels. To provide some legacy perspective, taken together the MME and S-GW provide the EPC with functionality similar to that previously provided by the SGSN, with the MME handling the signalling and session control aspects and the S-GW dealing with the user traffic. Early in its development, the S-GW was also known as the UPE (User Plane Entity), although this terminology has now been dropped.

Further Reading: 3GPP TS 23.401:4.4.3.2

5.4

© Wray Castle Limited

LT3600/v3.1

Evolved Packet Core

PDN Gateway (PDN-GW)

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-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 the network’s packet filtering and classification functions are based. These include the ‘deep packet inspection’ techniques that are used to classify packets into particular SDFs before routing them over an EPS Bearer or the SGi interface, which in turn allows the PDN-GW to act as the network’s PCEF Under direction from the PCRF (Policy and Charging Rules Function) the PDN-GW will apply ‘per SDF’ charging, service level and rate enforcement and QoS-related traffic shaping functions that control the ‘gating’ of user traffic flows. Each PDN-GW contains a number of logical access points (each identified by an APN which act as the GTP tunnel endpoints and mobility anchors of the EPS Bearers that extend service out to mobile UEs. As in the legacy GGSN, the APNs are responsible for the allocation of IP addresses to UEs during the establishment of each EPS Bearer and for routing traffic between the Bearers and particular external networks.

Further Reading: 3GPP TS 23.401:4.4.3.3 LT3600/v3.1

© Wray Castle Limited

5.5

LTE/SAE Engineering Overview

Policy and Charging Rules Function (PCRF)

Decides whether and when to create additional EPS bearers Provides PCC data such as service data flow detection, gating, QoS, ARP and flow-based charging information to traffic handling entities Terminates the S7/Gx and Rx interfaces for home network service and the S9 interface point for roaming with local breakout

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 charging information to traffic handling entities within the network. This includes rules that allow the PDN-GW to provide the correct level of service to user data flows once the type of traffic being carried has been determined. For example, if the PDN-GW determines that the SDF to a user is carrying real-time traffic it may ‘gate’ up to the data rate and QoS level indicated by the PCRF and the user’s subscription profile. The PCRF’s charging rules allow the operator to apply the appropriate rating to CDRs (Call Data Records) generated for each SDF so that, for instance, real-time connections can be differentiated from an Internet browsing session. In the case of EPS roaming, when users use their terminals abroad, 3GPP has developed an extended PCRF architecture, based on the S9 interface, that defines Home Policy and Charging Rules Function (H-PCRF) and Visited Policy and Charging Rules Function (V-PCRF) logical functions.

Further Reading: 3GPP TS 23.401:4.4.7

5.6

© Wray Castle Limited

LT3600/v3.1

Evolved Packet Core Mobility Management Entity (MME)

Functions could be combined within same device S5 Serving Gateway (S-GW)

PDN Gateway (PDN-GW)

Combined Functionality 3GPP has deliberately designed the EPC network elements and interfaces to give vendors the greatest possible flexibility when developing their solutions. Although the MME, S-GW, PDN-GW and PCRF all have a set of rigidly defined functions and open interfaces, the specifications make it explicit that equipment vendors are free to deploy these logical functions to physical devices in whatever way suits them best. For example, the MME and SGW functions can both be located in one device, such as an upgrade to an existing 3G SGSN platform. The S11 interface would then be internal to that combined device. In the same way it is conceivable that a vendor may decide to combine the functions of the S-GW and PDN-GW into one combined EPS gateway, rendering the S5 an internal interface.

Further Reading: 3GPP TS 23.401:4.4 LT3600/v3.1

© Wray Castle Limited

5.7

LTE/SAE Engineering Overview

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.

Further Reading: 3GPP TS 23.401:3.1

5.8

© Wray Castle Limited

LT3600/v3.1

Evolved Packet Core

MME

eNB

UE

RRC

RRC

ECM

ECM

EMM

EMM

State machines store UE and bearer context data

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 can be either RRC-IDLE (which relates to a UE in idle mode) or RRC-CONNECTED (which relates to a UE with an active traffic bearer).

Further Reading: 3GPP TS 23.401:4.6 LT3600/v3.1

© Wray Castle Limited

5.9

LTE/SAE Engineering Overview MME

Detach, Attach Reject TAU Reject All Bearers deactivated EMM-Deregistered

EMM-Registered Attach accept, TAU accept

Detach, Attach Reject TAU Reject E-UTRAN interface switched off due to Non-3GPP handover All Bearers deactivated EMM-Deregistered EMM-Registered Attach accept, TAU accept UE

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 location is 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 to EMM-Deregistered, it must first move to ECM-Connected state to ensure that a signalling bearer is available to carry the Detach message.

Further Reading: 3GPP TS 23.401:4.6.2

5.10

© Wray Castle Limited

LT3600/v3.1

Evolved Packet Core MME

S1 connection released ECM-Idle

ECM-Connected S1 connection established

RRC connection released ECM-Idle

ECM-Connected RRC connection established

UE

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 be stored in the serving MME, and no NAS signalling is passing between those elements. A UE in this state will perform network and cell selection/reselection and will send TAU messages, but has no RRC or S1 traffic bearers established. In ECM-IDLE the location of the UE is known by the MME only to the level of the current TA or TA List. In the ECM-CONNECTED state a UE has established a signalling relationship with an MME, which will know the UE’s location to the eNB level, not the current cell level. The UE’s Bearer Contexts will be activated and RRC and S1 transport resources will have been assigned to it. A UE will move to the ECM-CONNECTED state during functions such as Attach, TAU and Detach and when an EPS bearer is active for traffic transfer. A UE moves from ECM-IDLE to ECM-CONNECTED by sending a Service Request to the MME.

Further Reading: 3GPP TS 23.401:4.6.3 LT3600/v3.1

© Wray Castle Limited

5.11

LTE/SAE Engineering Overview 2G/3G SGSN

HSS

UMTS/ GPRS

Roaming PCRF

S4

EIR

S6a

S3

UTRAN/ GERAN

PCRF

MME

S12

S9

S13

E-UTRA

Rx+

S7/Gx S11

S1-MME

IMS E-UTRAN

S5

S1-U S–GW Interworking to MME

SGi

IP Services

PDN–GW S2

WLAN or WiMAX

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.

Further Reading: 3GPP TS 23.401:4.2

5.12

© Wray Castle Limited

LT3600/v3.1

Evolved Packet Core

MME

S1-MME

S1AP

SCTP IP L2 L1

User PDU eNB S1-U

S-GW

GTPv1-U UDP IP L2 L1

S1 to E-UTRAN Interface The S1 interface can be seen as the evolved equivalent of the 3G Iu interfaces and interconnects the EUTRAN 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) LT3600/v3.1

© Wray Castle Limited

5.13

LTE/SAE Engineering Overview

Non-guaranteed PDU delivery via GTP-U EPS IP Transport

User PDU

GTPv1-U UDP IP L2 L1

S1-U

S-GW

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 traffic 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) 5.14

© Wray Castle Limited

LT3600/v3.1

Evolved Packet Core MME 2 MME 1

MME 3

S1-MME

S1-Flex

S1-U S-GW 3 S-GW 2 S-GW 1

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 connectivity request 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 benefits 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 are forwarded by the eNB to an MME belonging to one or other of the core networks that are sharing the same E-UTRAN.

Further Reading: 3GPP TS36.401 LT3600/v3.1

© Wray Castle Limited

5.15

LTE/SAE Engineering Overview MME S1-AP

SCTP IP L2 L1

Home eNB Gateway (HeNB GW)

User PDU

S1-MME

Broadband S1-U

Home eNB (HeNB)

S-GW

GTPv1-U UDP IP L2 L1

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-Fi access 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 cells and other cells via the MME/S-GW is possible.

Further Reading: 3GPP TS 36.300:4.6, TR 25.820

5.16

© Wray Castle Limited

LT3600/v3.1

Evolved Packet Core

E-RAB Context Management Management E-RAB setup/modify/ release

Initial Context Setup UE Context release/ notification

Handover Signalling

Paging

NAS Transport

Management Procedures

CDMA2000 Tunnelling

Paging

Direct Transfer

Reset Error Indication

CDMA2000 Tunnelling Procedures

HO preparation/ notification/ cancellation

S1 Setup eNB/MME Configuration Update

HO Resource Allocation Path Switch

Overload start/stop

eNB/MME Status Transfer UE Capability

Information

UE Capability Information

Trace

Trace start/ deactivate/ failure

Location Reporting

Warning Messages

eNB Direct Information

MME Direct Information

Location Report

Warning Message Transmission

eNB Direct Information Transfer

MME Direct Information Transfer

Cell Traffic Trace

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 UEs Paging S1 interface management Reset Error Indication Overload Load balancing S1 Setup eNB and MME Configuration Update NAS Signalling transport S1 UE context Release UE Context Modification Status Transfer Trace Location Reporting S1 CDMA2000 Tunnelling Warning message transmission RIM (RAN Information Management) Configuration Transfer The functions are performed by employing the various EP message types shown in the diagram.

Further Reading: 3GPP TS 36.413:8.1 LT3600/v3.1

© Wray Castle Limited

5.17

LTE/SAE Engineering Overview SGSN

RNC

S16

SGSN Home Network

S12

PDN-GW SGi S4 S8

S5

S-GW

IP Services

SGi

GTPv1-U UDP IP L2 L1

Home or PDN-GW Visited Network

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)

5.18

© Wray Castle Limited

LT3600/v3.1

Evolved Packet Core SGSN

GTPv2-C UDP IP L2 L1

S16

SGSN MME

MME

S3

S10

Home Network

S11

PDN-GW

S8

SGi S5 SGi

S-GW

IP Services

Home or PDN-GW Visited Network

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 controlled by 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) LT3600/v3.1

© Wray Castle Limited

5.19

LTE/SAE Engineering Overview HSS SGSN S6d

S6a

Diameter TCP/SCTP IP L2 L1

MME EIR S13

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.

5.20

© Wray Castle Limited

LT3600/v3.1

Evolved Packet Core

Visited PCRF

S9

Home PCRF

S7/Gx

Diameter TCP/SCTP IP L2 L1

Rx

IMS PDN–GW

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

© Wray Castle Limited

5.21

LTE/SAE Engineering Overview MSC/VLR or MSC Server

SGs/SV

SGsAP SCTP IP L2 L1

MME

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

5.22

© Wray Castle Limited

LT3600/v3.1

Evolved Packet Core MME eNB

UE S-GW

PDN-GW

External Bearer

EPS Bearer

E-RAB Radio Bearer

S5/S8 Bearer

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 to dedicated bearers. In UMTS networks the equivalent of an EBI is the NSAPI (Network Layer Service Access Point Identifier) which is used to identify a PDP context. When the UE moves from LTE to UMTS, the EBI is mapped to an NSAPI – this mapping is not complex as both NSAPI and EBI are 4 bit values. The EPS Bearer ID is a one-octet string, which in theory means that each UE can have up to 256 EPS Bearers associated with it per MME. However, the relevant specifications currently indicate that the most significant 4 bits of the ID should be set to 0, which limits the number of EPS Bearers per UE to 16. The EPS Bearer travels between the UE and the PDN-GW; during handovers it may also extend over the X2 interface between source and target eNBs. When travelling over the S1 and X2 interfaces, there is a one-to-one mapping between the EPS Bearer and the E-RAB and between the identities assigned to each of those entities.

Further Reading: 3GPP TS 23.401:5.2.1 LT3600/v3.1

© Wray Castle Limited

5.23

LTE/SAE Engineering Overview UE S1-AP ID

MME S1-AP ID

MME

S1-MME S1-AP Context

S1-U GTP Tunnel

UE

X2-U (GTP TE-IDs) X2-C (UE X2-AP IDs)

S-GW

Tunnel Endpoint IDs (TE-ID)

Transport Identities To allow the S1 and X2 protocols to identify the UEs that form the endpoint of each transport tunnel, terminals are assigned identities that are unique within the eNBs or MMEs that support those endpoints. The UE S1-AP ID and MME S1-AP ID are unique within the eNB and MME respectively that are handling the E-RAB/EPS Bearer to an Attached UE. The IDs are simple numerical identifiers (24-bits in the eNB and 32-bits in the MME) and are not associated with a specific instance of the S1 interface in each device. An eNB can therefore support a maximum of 224 (16.7 million) UE S1 connections and an MME 232 (4.3 billion). The UE X2-AP ID performs the same basic function as the S1-related identities, but for the X2 interface. The X2 is optional and is only used to pass handover-related traffic between source and target eNBs, so the X2-AP ID will only be created as required when a handover is initiated. The ID is 12 bits long and provides a maximum of 4096 UE X2 handover identities per eNB. The 4-byte GTP TEID is used in the EPS the same way as it is in legacy networks. Each device that supports a GTP tunnel refers to it in terms of the TEID assigned to the tunnel plus the IP address and UDP port number of the interface that handles it. TEIDs are assigned by the receiving side of each connection and are exchanged using S1-AP during tunnel establishment.

Further Reading: 3GPP TS 23.401:5.2; 36.413:9.2.3; 29.274 (GTPv2-C); 36.41x (S1); 36.42x (X2)

5.24

© Wray Castle Limited

LT3600/v3.1

Evolved Packet Core

Both Bearers share same IP address

UE

Initial or Default EPS Bearer

eNB

S-GW

Both Bearers routed via same APN

IMS

PDN-GW

Subsequent or Dedicated EPS Bearer

Internet

Default and Dedicated EPS Bearers Each UE will establish an initial or default EPS Bearer as part of the attach process. This will provide the required ‘always on’ IP connectivity to the UE and may be to a ‘default APN’, if one is stored in the user’s subscriber profile, or to an APN selected by the network. In networks that interconnect to an IMS, the default bearer allows the UE to perform SIP registration and thereafter to provide a path for session initiation messaging. In these circumstances, the data rate and QoS assigned initially to the default bearer is commensurate with the expected low level of SIP-based traffic flow, but these parameters can be modified to accommodate the requirements of application traffic flows when a connection is established. If a UE has a requirement to establish an application connection whose QoS or data rate demands are incompatible with those currently assigned to the default bearer (but which can still be routed through the current APN), the PDN-GW or PCRF may initiate the establishment of an additional EPS Bearer to carry the new traffic flow. Any additional bearers assigned to a UE in addition to the default bearer are termed dedicated bearers and will be identified by different EPS Bearer/E-RAB and radio bearer IDs. A UE may have more than one PDN Connectivity Service running if it has connections established through more than one APN/PDN-GW. In that case, there will be one Default Bearer and an optional number of Dedicated Bearers created for each PCS. The EPS Bearer ID value limits the total number of bearers established for one UE to 11.

Further Reading: 3GPP TS 23.401:4.7.2 LT3600/v3.1

© Wray Castle Limited

5.25

LTE/SAE Engineering Overview

EPS QoS Characteristics

PCEF (Policy and Charging Enforcement Function) in PDN-GW

EPS

QCI (QoS Class Identifier) ARP (Allocation and Retention Priority) GBR (Guaranteed Bit Rate) MBR (Maximum Bit Rate)

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

5.26

© Wray Castle Limited

LT3600/v3.1

Evolved Packet Core

EPS bearer with GBR QoS

APN-AMBR for non-GBR EPS bearers to PDN-GW 1

S-GW

PDN-GW1

UE UE-AMBR for all non-GBR EPS Bearers from UE

PDN-GW2 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 network may 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, due to the probable need to adjust their bandwidth after the initial Attach has taken place, must be non-GBR.

Further Reading: 3GPP TS 23.401:4.7.3 LT3600/v3.1

© Wray Castle Limited

5.27

LTE/SAE Engineering Overview Bearer Context – Active Bearer Attributes

MME

UE

eNB

DRB

S-GW

S1 Tunnel

PDN-GW

S5/S8 Tunnel

Radio Bearer/E-RAB/EPS Bearer Active

Active EPS Bearers and Bearer Contexts An EPS bearer provides a data path between a UE and an APN located in a PDN-GW. Once created, an EPS bearer can be in one of two states – active or inactive. When active, the EPS bearer is assigned bearer resources that amount to a radio bearer and GTP tunnels, with assigned TEIDs (Tunnel Endpoint IDs) that will carry the E-RAB (E-UTRAN Radio Access Bearer) and EPS Bearer over the Uu, S1-U and S5/S8 interfaces. Each PDN connection and default and dedicated EPS bearer is described by a Bearer Context stored in the UE and MME and in other devices required to serve each bearer. Default and dedicated bearer contexts describe the UE’s current ECM state (idle or connected) plus the bearer’s EPS bearer ID and QoS parameters, and can be either active or inactive. An active Bearer Context is deemed to be in the ESM BEARER CONTEXT ACTIVE state.

Further Reading: 3GPP TS 23.401:4.7.2

5.28

© Wray Castle Limited

LT3600/v3.1

Evolved Packet Core Bearer Context – Inactive Bearer Attributes

MME

UE

eNB

S-GW

PDN-GW

S5/S8 Tunnel

Radio Bearer/ E-RAB Released

S5/S8 EPS Bearer Active

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

LT3600/v3.1

© Wray Castle Limited

5.29

LTE/SAE Engineering Overview

MGW GERAN/UTRAN Access

A/Iu Gb/Iu

Mc

SGSN

S3

MSC-S

Sv

S4

CS traffic IMS

GERAN/UTRAN EPS PS traffic

MME S11 UE using E-UTRAN access

SGi E-UTRAN Access

S1

S–GW

S5

PDN–GW

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

5.30

© Wray Castle Limited

LT3600/v3.1

Evolved Packet Core

MGW GERAN/UTRAN Access

A/Iu Gb/Iu

Mc

SGSN EPS Attached UE Paged via E-UTRAN Falls back to GERAN/UTRAN for connection Returns to E-UTRAN when Idle

S3

MSC-S

SGs

S4 GERAN/UTRAN

IMS not required CS traffic

EPS CS signalling

MME S11 SGi E-UTRAN Access

S1

S–GW

S5

PDN–GW

CS Fallback Arguably, the simplest solution to the problem of providing CS services without necessarily deploying an IMS is to use 3GPP’s CS Fallback service. CS Fallback allows an EPS UE to perform combined Attach/Location Update functions with the EPS and the legacy CS core. Mobile-Terminated CS transactions, such as inbound calls or SMS, are directed to the legacy CS core as usual. The MSC or MSC Server that receives the inbound transaction alerts the UE’s serving MME via the SGs interface and the MME pages the UE. When it responds, the UE is directed to drop down to a ‘CS capable cell’ in the GERAN/UTRAN to receive the inbound service. Mobile-Originated CS services are handled in the same way, with the UE requesting the service via the EPS but being directed to GERAN/UTRAN access resources to complete the transaction. Once the CS transaction is over, the UE will return to idle mode and will camp onto an E-UTRAN cell. Any EPS Bearers carrying PS traffic will be handed over to the GERAN/UTRAN via an SGSN, if possible, when the CS Fallback is initiated. CS Fallback can operate in conjunction with IMS-based services or could be used as an interim measure by an operator that is not yet ready to deploy one.

Further Reading: 3GPP TS 23.272 (CS Fallback) LT3600/v3.1

© Wray Castle Limited

5.31

LTE/SAE Engineering Overview

MGW GERAN/UTRAN Access

A/Iu Gb/Iu

Mc

SGSN UE HO to GERAN/UTRAN access CS call employs S4 SRVCC GERAN/UTRAN PS uses standard HO techniques EPS

S3

MSC-S

Sv

IMS

CS traffic

PS traffic

MME S11 SGi E-UTRAN Access

S1

S–GW

S5

PDN–GW

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 a time; 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)

5.32

© Wray Castle Limited

LT3600/v3.1

Evolved Packet Core MSC-S MGW GERAN/UTRAN Access

A/Iu

CS traffic A/Iu EPS-GERAN/UTRAN CS HO negotiated via SGs or Sv interfaces

EPS Attached UE

SGs/Sv

IMS not required GANC

CS traffic forwarded GERAN/UTRAN to EPS via GANC EPS MME S11

E-UTRAN Access

S1

S–GW

SGi

S5

PDN–GW

CS Service Provision via a GANC One further proposal for offering CS services via the EPS, put forward by the VoLGA (Voice over LTE Generic Access) Forum, is to reuse the framework developed to provide connectivity to 3GPP services via a GAN (Generic Access Network). A GAN can be essentially any kind of network that can support the flow of IP traffic, although the GAN specifications produced by organizations like 3GPP are mainly aimed at Wi-Fi based systems. This option involves causing the least disruption to the CS core and the EPS by installing a GANC (Generic Access Network Controller) between the two network environments. Handover and control signalling between the EPS and CS core would travel over the SGs or Sv interfaces, which were developed to support CS Fallback and SRVCC services respectively. The scheme does involve some administrative extensions to EPS operation, which would allow a suitably equipped UE to register for VoLGA services and for CS handovers between the EPS and 2G/3G networks.

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

© Wray Castle Limited

5.33

LTE/SAE Engineering Overview

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.

Further Reading: 3GPP TS 33.301

5.34

© Wray Castle Limited

LT3600/v3.1

Evolved Packet Core Quintuplet

HSS

RAND XRES AUTN CK IK MME

eNB

UE/USIM

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 by subscription 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 LT3600/v3.1

© Wray Castle Limited

5.35

LTE/SAE Engineering Overview MME

M-TMSI

EPC & E-UTRAN

IMSI

UE/USIM

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

5.36

© Wray Castle Limited

LT3600/v3.1

LTE/SAE Engineering Overview

SECTION 6

LTE OPERATION

© Wray Castle Limited

I

LTE/SAE Engineering Overview

II

© Wray Castle Limited

LTE Operation

CONTENTS 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

© Wray Castle Limited

III

LTE/SAE Engineering Overview

IV

© Wray Castle Limited

LTE Operation

OBJECTIVES At the end of this section you will be able to:



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

© Wray Castle Limited

V

LTE/SAE Engineering Overview

VI

© Wray Castle Limited

LTE Operation

Manual mode

Indication to user

Automatic mode

PLMN selection and reselection Available PLMNs Selected PLMN

Location registration response Service requests

CSG ID selected

Location registration response

Location registration

Support for manual CSG ID selection Available CSG IDs to NAS

Cell selection and reselection

NAS control

Registration area changes

Radio measurements

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 performance and signalling information. The radio performance measurements are done on the basis of a quality measure. This is an assessment of radio signal strength and interference level, and it can be made for both the serving cell and its neighbours. The aim will be to ensure that the UE is always served by the cell most likely to give the most reliable service should information transfer of any kind be required. The UE will also be monitoring two key types of signalling from the serving cell system information messages and paging or notification messages. System information messages convey all the cell and system parameters. The UE will record changes in these parameters that may affect the service level provided by the cell, or access rights to the cell. Changes in these parameters could provoke a cell reselection, or a PLMN reselection. Paging or notification messages will result in connection establishment. All of these procedures are performed through communication between the AS and the NAS. In general, instructions are sent from the NAS to the AS; the AS then performs the requested procedure and returns a result to the NAS. If CSG (Closed Subscriber Group) is supported then these procedures are modified such that a cell’s broadcast CSG ID forms another level of differentiation between cells. CSG is intended for use with HeNBs (femtocells).

Further Reading: 3GPP TS 36.304:4.1 LT3600/v3.1

© Wray Castle Limited

6.1

LTE/SAE Engineering Overview E-UTRA Inter-frequency

E-UTRA Intra-frequency

Measurement rules Based on priority of RAT/Frequency layers and thresholds

Evaluation Based on priority of RAT/Frequency layers and thresholds

I-RAT Inter-frequency

Ranking Based on measurements, offsets, parameters and mobility status

High

Medium

Low

Reselection 1 sec since last reselection Cell is suitable

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 be considered 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 will only select a cell on a lower priority frequency when the Srxlev of the serving cell falls below Threshserving,low and Srxlev of the neighbour is above Threshx,low for TreselectionRAT and there is no other alternative. For neighbour cells on intra-frequencies or on equal priority E-UTRA inter-frequencies, the UE uses a ranking criterion ‘Rs’ for the serving cell and ‘Rn’ for the neighbour cell. Ranking is based on a comparison of the respective Srxlev values with a hysteresis added to the serving cell value and an offset added to the neighbour cell value. The UE will select the highest ranked cell if the condition is maintained for TresectionRAT. In addition to all of this, the UE will apply scaling to Treselection, hysteresis values and offset values dependent on an assessment of its mobility state, which may be high, medium or low. This is based on an analysis of resent reselection frequency.

Further Reading: 3GPP TS 36.304:5.2.4

6.2

© Wray Castle Limited

LT3600/v3.1

LTE Operation RSRP

RSSI

(Reference Signal Received Power)

(Received Signal Strength Indicator) Serving cell

Serving cell

Total received power in RS OFDM symbol periods including the serving cell, all co-channel and adjacent channel interference and thermal noise

Linear average power of the reference signal resource elements

RSRQ (Reference Signal Received Quality) The ratio of the reference signal power, calculated as N x RSRP, to the RSSI, where N is the number of RBs in the RSSI measurement bandwidth

E-UTRA Radio Measurements There are three key measurement values used in E-UTRA, the RSRP (Reference Signal Received Power), the RSSI (Received Signal Strength Indicator) and the RSRQ (Reference Signal Received Quality). The standards define RSRP as: ‘The linear average over the power contributions of the resource elements that carry cell-specific reference signals within the considered measurement frequency bandwidth’. The standards define RSSI as: ‘The linear average of the total received power observed only in OFDM symbols containing reference symbols for antenna port 0, in the measurement bandwidth, over N number of resource blocks by the UE from all sources, including serving and non-serving cells, adjacent channel interference, thermal noise, etc.’ The standards define RSRQ as: ‘The ratio NxRSRP/(E-UTRA carrier RSSI), where N is the number of RBs of the E-UTRA carrier RSSI measurement bandwidth’. Note that the measurement of RSRP is based on reference signals from antenna port 0, but where antenna port 1 can be received reliably, reference signals from that port may also be included. Additionally, the values of RSRP and RSSI used to calculate RSRQ must have the same measurement bandwidth.

Further Reading: 3GPP TS 36.214:5.1 LT3600/v3.1

© Wray Castle Limited

6.3

LTE/SAE Engineering Overview Measurement Parameters Measurement objects Reporting configuration Measurement identities Quantity configuration Gap configuration

eNB Serving cell

Neighbour cells

UE RRC Connected

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 then they 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 triggerbased, periodic or triggered periodic. This field also defines the other contents of the measurement report message. Measurement identities provides a reference number such that some part of this identified measurement can be modified or removed in future. The Quantity configuration sets the filtering to be used on the measurements that are taken. The gap configuration defines periods when the UE can take measurements of neighbour cells.

Further Reading: 3GPP TS 36.331:5.5

6.4

© Wray Castle Limited

LT3600/v3.1

LTE Operation eNB Serving cell

Transmission gap (6 ms)

Transmission gap repetition period (N x 10 ms)

Neighbour cell

Neighbour cell

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

Further Reading: 3GPP TS 36.133:8.1 LT3600/v3.1

© Wray Castle Limited

6.5

LTE/SAE Engineering Overview

eNB measures propagation delay from PRACH preamble TA step size is 16Ts (0.52 μs) Correction is included in the RAR as a value of steps in the range 0 to 1282 (0 to 0.67 ms

TA adjustments are made using MAC control messages in the PDSCH Correction is a value in the range 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 and 0.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 in MAC PDUs carrying data for the UE on the PDSCH. The command itself is a six-bit value giving a number range from 0–63. Values less than 31 will reduce timing advance and values greater than 31 will increase timing advance.

Further Reading: 3GPP TS 36.213:4.2.3

6.6

© Wray Castle Limited

LT3600/v3.1

LTE Operation Efficiency

CQI Index

Modulation

Approx. code rate

(bits/symbol)

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

No TX QPSK QPSK QPSK QPSK QPSK QPSK 16QAM 16QAM 16QAM 64QAM 64QAM 64QAM 64QAM 64QAM 64QAM

... 0.076 0.12 0.19 0.3 0.44 0.59 0.37 0.48 0.6 0.45 0.55 0.65 0.75 0.85 0.93

... 0.1523 0.2344 0.377 0.6016 0.877 1.1758 1.4766 1.9141 2.4063 2.7305 3.3223 3.9023 4.5234 5.1152 5.5547

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

Further Reading: 3GPP TS 36.213:7.2 LT3600/v3.1

© Wray Castle Limited

6.7

LTE/SAE Engineering Overview 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 that cross-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

6.8

© Wray Castle Limited

LT3600/v3.1

LTE Operation UE

eNB

1. Attach Request

MME

S-GW

PDN-GW

EIR

HSS

2. Attach Request 3. AKA/Security

4. Identity Request/Response

4. ME Identity Check

4. Ciphered Options Request 4. Ciphered Options Response 5. Update Location 5. Insert Subscriber Data 5. Insert Subscriber Data Ack 5. Update Location Ack Optional Stage

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 a recent previous context for a UE using its H-PLMN (Home PLMN) and accessing via the Home E-UTRAN – is shown, and the stages of the process are described below. Once a suitable cell has been selected the UE employs the Random Access procedure to request an RRC connection with the chosen eNB. With that in place an Attach Request message (1) can be transmitted. If the UE has previously been registered with the PLMN, it may include a previously assigned GUTI in the message, otherwise the Attach Request message contains the subscriber’s IMSI and some other parameters. On receipt of the Attach Request the eNB either derives the identity of the previously used MME from the supplied GUTI or selects an MME from the pool available and forwards the message (2). The MME contacts the HSS indicated by the subscriber’s IMSI and in response receives the relevant elements of the ‘quintuplet’ that allows the EPS-AKA process to take place (3). Optionally, at this point the MME may be required to check the identity and status of the UE via the EIR (4) using the ME Identity Check process. Ciphering may then be invoked over the air interface. Once the AKA procedures have successfully concluded the MME transmits an Update Location message to the HSS and receives the Insert Subscriber Data message in response containing the user’s service profile (5). An Insert Subscriber Data Ack from the MME is followed by an Update Location Ack from the HSS. The UE is now Attached to the EPC.

Further Reading: 3GPP TS 23.401:5.3.2 LT3600/v3.1

© Wray Castle Limited

6.9

LTE/SAE Engineering Overview UE

eNB

MME

S-GW

PDN-GW

PCRF

HSS

6. Create Default Bearer Request

8. Create Default Bearer Response

7. PCC Lookup

9. Initial Context Setup Request/ Attach Accept 10. RRC Conn Reconfig 11. RRC Conn Reconfig Complete

12. Initial Context Setup Response

13. Direct Transfer

14. Attach Complete

Data flow

Optional Stage

Default Bearer Establishment A default bearer must then be established and the MME selects the S-GW that will handle and a PDN-GW that supports the requested APN. The MME issues a Create Default Bearer Request to the selected S-GW, which assigns a GTP TEID to the EPS bearer and passes the request to the indicated PDN-GW (6). If the network employs dynamic PCC the PDN-GW will query a PRCF for bearer parameters, otherwise the bearer will be established using local QoS parameters stored in the PDN-GW (7). A Create Default Bearer Response message passes from the PDN-GW to the S-GW, which contains relevant parameters such as the EPS bearer’s IP address and possibly the IP address or DNS name of a local IMS P-CSCF. The S-GW creates the bearer as specified and passes the Create Default Bearer Response message to the MME (8). The details that define the S1-U service will also have been defined during this stage. The MME sends an Initial Context Setup Request/Attach Accept message, which contains the assigned parameters for the EPS bearer context, to the eNB (9). That element in turn sends an RRC Connection Reconfiguration message to the UE (10) to inform it of the bearer details and the changed air interface parameters. The UE returns an RRC Connection Reconfiguration Complete message (11) to verify that the radio bearer, which was initially established just to carry the attach message, has been reconfigured to support the new parameters. The eNB forwards an Attach Complete message to the MME (12). The UE then sends a Direct Transfer message to the eNB (13), which confirms the details of the EPS Bearer. Finally, the eNB sends an Attach Complete message to the MME to confirm that both the Attach and the Default EPS Bearer processes have completed successfully. Uplink and downlink data can now flow if required.

Further Reading: 3GPP TS 23.401:5.3.2

6.10

© Wray Castle Limited

LT3600/v3.1

LTE Operation UE TA List

UE Default Bearer Context – Inactive

TA 9 TA 12

ECM State EPS Bearer ID QoS

MME Pool A

TA 9

TA 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 UE connection request. The MME reflects this extended mobility by maintaining a TA list for each registered UE within which the list shows the set of TAs the UE is currently registered. During a TAU, and periodically in the event that a TAU does not occur within a set time-frame, the MME is responsible for reauthenticating each registered UE and for reissuing the M-TMSI used to confidentially identify it. When a UE drops into the ECM-IDLE state its existing default bearer can be ‘parked’ and any dedicated bearers can either be parked or released. To support this, the MME stores details of the UE’s current ‘bearer contexts’ ready to reactivate them in the event of a UE or network-triggered Service Request. A TAU may result in the need to change the S-GW assigned to handle an idle UE’s bearer contexts or of the MME with which the UE is registered, if the reselected cell is associated with a different S-GW Service Area or MME Pool. If ISR (Idle-mode Signalling Reduction) is active for a UE, the MME may be required to pass location updates and other pertinent information to the SGSN with which the UE is co-registered.

Further Reading: 3GPP TS 23.401:4.3.5 LT3600/v3.1

© Wray Castle Limited

6.11

LTE/SAE Engineering Overview UE

eNB

MME

HSS

TAU trigger event 1. TAU Request 2. TAU Request+ TAI and ECGI

3. Authentication/Security 4. TAU Accept

5. TAU Complete

Optional Stage

TAU (Tracking Area Update) A TAU takes place between a UE and the MME with which it is registered and is triggered by the UE detecting a change in TAI after a cell reselection. A TAU is also be used as part of the Initial Attach process and may additionally be triggered by events such as the expiry of the periodic TAU timer or as part of MME load balancing or rebalancing. In the example message flow it is assumed that the UE is connected to its HPLMN and that an S-GW change and MME relocation are not required. After detecting a change in TAI, the UE transmits a TAU Request message to the eNB (1). The TAU Request contains data such as the old GUTI, old TAI, EPS bearer status and a NAS MAC (Message Authentication Code) for integrity protection purposes. The eNB forwards the TAU Request (plus the new TAI and ECGI) to the MME indicated by the supplied GUTI (2). If the MME indicated by the GUTI is not associated with the new eNB, an MME relocation will be triggered and the base station will select a new MME to pass the TAU Request to. If the integrity check of the MAC carried in the TAU Request is successful, the MME may elect not to reauthenticate the UE. If the MME is configured to always reauthenticate, or if the integrity check fails, then the EPS-AKA process must be followed and a new GUTI (which includes the new M-TMSI) will be issued (3). Once the MME is satisfied that the UE/USIM is authentic and assuming that the UE is allowed to roam in the new TA, it transmits a TAU Accept message to the eNB, which relays it to the UE (4). The TAU Accept message contains the new GUTI, if one was assigned, plus the current TA List associated with the UE. The TA List enables the UE to determine the set of TAs within which it can roam without being required to perform another TAU. The UE responds with a TAU Complete message (5), which finishes the process.

Further Reading: 3GPP TS 23.401:5.3.3

6.12

© Wray Castle Limited

LT3600/v3.1

LTE Operation GERAN/UTRAN

SGSN

UE and Bearer Contexts stored

RA

UE can reselect to any registered RAT without sending an update

S3

UE paged across all registered areas

S-GW

PDN-GW

UE and Bearer Contexts stored

TA

MME

E-UTRAN

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 is able 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 LT3600/v3.1

© Wray Castle Limited

6.13

LTE/SAE Engineering Overview UE TA List TA 9 TA 12 S1 Paging messages

TA 9

TA 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), the MME 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

6.14

© Wray Castle Limited

LT3600/v3.1

LTE Operation

Re-registration causes: Change of IP Address Change of PDN-GW

S-CSCF

Expiry of Registration Timer

UE

EPS

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 reregistration. The periodicity of the re-registration is determined by the registration expiry value included in the initial Registration message and the process ensures that the S-CSCF is kept informed of the reachability of each registered UE. Re-registration is also required if the UE’s IP address changes – either as a result of a change of PDN-GW or as part of a network’s DHCP IP address allocation processes (which may seek to reduce the possibilities of fraud or connection hijack by periodically refreshing the IP addresses assigned to terminals). An additional trigger for re-registration would be if the UE or IMS capabilities changed, for example if the client supporting a new IMS application was loaded to the terminal.

Further Reading: 3GPP TS 23.228:5.2 LT3600/v3.1

© Wray Castle Limited

6.15

LTE/SAE Engineering Overview

Modify/Create Dedicated Bearer

Service Request

To carry new SDFs

Reactivate ‘parked’ EPS Bearers

Inactive Default EPS Bearer

IMS

UE

eNB

S–GW

PDN–GW

Internet

Inactive Dedicated EPS Bearer

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 PDNGW/PCRF may decide that an additional dedicated bearer is established. When a UE enters idle mode the physical S1 and radio resources assigned to the default EPS bearer will be released and the bearer context details will be stored. Any existing dedicated bearers may be released or stored also. When the UE moves from ECM-IDLE to ECM-CONNECTED the stored bearer contexts will be reactivated using the Service Request procedure.

Further Reading: 3GPP TS 23.401:5.3.4

6.16

© Wray Castle Limited

LT3600/v3.1

LTE Operation UE

eNB

MME

S-GW

PDN-GW

PCRF

HSS

Trigger event 1. NAS Service Request

2. NAS Service Request

3. Authentication/Security

4.S1 AP Initial Context 5. Radio Bearer

Setup Request

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

Optional Stage

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 current S-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 reestablish physical resources for the stored bearer contexts on the S1 interface between the UE and the S-GW (4). The eNB allocates radio resources (5) on the air interface and informs the UE. Uplink traffic is then able to flow (6). The eNB confirms these actions with an S1AP: Initial Context Setup Complete message (7). The MME instructs the S-GW to establish its end of the S1-U tunnels using the Update Bearer Request message (8). If the PDN-GW has requested updates regarding the UE’s location, the S-GW will pass this on in an Update Bearer Request (9). After the PDN-GW and S-GW return Update Bearer Responses, data can begin to flow on the downlink (9, 10 and 11).

Further Reading: 3GPP TS 23.401:5.3.4 LT3600/v3.1

© Wray Castle Limited

6.17

LTE/SAE Engineering Overview UE

eNB

MME

S-GW

PDN-GW

PCRF

HSS

Trigger event 1. Request Bearer Resource Modification 2. Request Bearer Resource Modification

3. PCC Lookup

4. Existing TFT modified, new TFT or Bearer activated or existing TFT or Bearer deactivated

Optional Stage

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 an additional packet filter to the TFT (Traffic Flow Template) related to the bearer over which the flow will travel. If the addition of the new flow alters the bearers QoS requirements the adjustment will be communicated to other elements using the Update Bearer Request process. In addition to UE-initiated Bearer Modification the EPC also supports PDN-GW-initiated Bearer Modification; HSS-initiated Bearer QoS Modification and MME and PDN-GW initiated Bearer Deactivation.

Further Reading: 3GPP TS 23.401:5.4

6.18

© Wray Castle Limited

LT3600/v3.1

LTE Operation UE

eNB

MME

S-GW

PDN-GW

PCRF

HSS

1. Trigger event 2. Request Bearer Resource Modification

3. Request Bearer Resource Modification 4. PCC Lookup 5. Create Dedicated Bearer Request

7. RRC Conn Reconfig 7. RRC Conn Reconfig Complete

6. Bearer Setup Request/ Session Management Request

8. Bearer Setup Response

9. Direct Transfer 10. Session Management Response 11. Create Dedicated Bearer Response

12. IP-CAN Session Modified

Data Flow

Optional Stage

Dedicated Bearer Creation If PCC decides that a new traffic flow is incompatible with any of the UE’s existing bearers it may decide that a new Dedicated Bearer is required, in which case it will instruct the PDN-GW to issue a Create Dedicated Bearer Request. The stages of this process are outlined in the diagram.

Further Reading: 3GPP TS 23.401:5.4.1 LT3600/v3.1

© Wray Castle Limited

6.19

LTE/SAE Engineering Overview Home S-CSCF

Home Home P-CSCF PDN-GW

UE

Destination IMS/UE

Trigger event 1. Invite 2. Invite 3. Invite 4. Session Progress

Edit 4. Session Progress

Edit 4. Session Progress 5. Provisional Acknowledgement

5. PRACK

5. PRACK

6. 200 OK

Resource Allocation

6. 200 OK 6. 200 OK

Optional Stage

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 process have 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 the type of service and QoS parameters specified. A Session Progress message is returned to the originating UE containing the IP address of the distant terminal and a response to the SDP parameters (4). Each CSCF in the return path is able to approve or edit the SDP response so that the eventual media session’s parameters match the capabilities of the busiest link in the chain. The originating UE returns a PRACK (Provisional Acknowledgement), which confirms the parameters of the media session (5). This triggers the reservation of resources for the distant UE, which it confirms with a 200 OK message (6).

Further Reading: 3GPP TS 23.228:5.4

6.20

© Wray Castle Limited

LT3600/v3.1

LTE Operation UE

Visited MME

Home P-CSCF

Home PDN-GW

Home S-CSCF

Destination IMS/UE

7. Resource Bearer Resource Modification 8. Update 8. Update 8. Update 9. Ringing 9. Ringing 9. Ringing Exchange of PRACK & 200 OK

Answer 11. 200 OK

11. 200 OK

Resources Committed 11. 200 OK Media Flow Optional Stage

IMS Connection Establishment (continued) Once confirmed, the originating UE may issue a Request Bearer Resource Modification to the MME to trigger a modification of the default bearer, or possibly the establishment of a new dedicated bearer (7). An Update message is sent to the distant network to confirm that a bearer with the required QoS is reserved (8). At this point the distant UE informs its user of the requested session and returns the Ringing indication to the originating end (9). When the called party answers, the distant UE sends a 200 OK message (11) (which, technically, is issued in response to the original Invite message); the I-CSCFs instruct the PDN-GWs to release the resources previously reserved for the session and data begins flowing directly between the UEs without travelling through the IMS. The mobile-terminated scenario follows the same procedure as mobile-originated procedure except it begins with a SIP Invite message being sent to the terminating UE, which may result in the UE being paged and a network-triggered Service Request to reactivate its default bearer from idle mode. From that point onwards it can exchange SIP messages with the originating UE via its current I-CSCF.

Further Reading: 3GPP TS 23.228:5.4 LT3600/v3.1

© Wray Castle Limited

6.21

LTE/SAE Engineering Overview

Intra-E-UTRAN

Inter-S-GW

Inter-system

Inter-MME

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 relocation Inter-RAT handover E-UTRAN-Non-3GPP Access Handover

Further Reading: 3GPP TS 23.401:5.5

6.22

© Wray Castle Limited

LT3600/v3.1

LTE Operation UE

Source eNB

MME

Target eNB

S-GW

PDN-GW

1. Uplink and downlink data flow 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 location information updated

7. User Plane Update Response 8. Downlink Data 9a. End Markers 9b. End Markers forwarded, X2 data forwarding ends Optional Stage

10. Path Switch Request Ack

11. 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 cell achieves 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).

Further Reading: 3GPP TS 23.401:5.5.1 LT3600/v3.1

© Wray Castle Limited

6.23

LTE/SAE Engineering Overview UE

Source eNB

Target RNC

MME

Source S-GW

Target

SGSN

PDN-GW

Data Flow

1. Handover decision 2. Handover Required 3. Forward Relocation Required 4. Create Bearer Request/Response 5. Relocation Request 6. Relocation Request Ack 7. Forward Relocation Response 8. Create Bearer Request/Response

Optional Stage

Inter-RAT HO Preparation The example provided below is for handover of active traffic connections between a home-network E-UTRAN cell and a home-network 3G UTRAN cell without an S-GW change and with no S12 Direct Tunnel support. Following a UE’s decision to request a handover (1), but before that handover can be initiated, a certain amount of preparation must take place. The source eNB determines that the indicated handover candidate is an inter-RAT neighbour and informs the source MME using the Handover Required S1AP message (2). The source MME selects a target SGSN and issues a Forward Relocation Request via the S3 interface (3). If the target SGSN has an S4 interface to the existing S-GW it issues a Create Bearer Request to that S-GW (4). If the target SGSN has no S4 interface to the serving S-GW (if they are in different PLMNs for example) then the target SGSN must select a local target S-GW, establish a bearer to it and then initiate an S-GW Relocation between the source and target nodes. Inter-PLMN traffic travels from visited S-GW to home PDN-GW, not visited SGSN to home PDN-GW. The target SGSN instructs the target BSC/RNC to reserve radio resources for the UE in the target cell using the Relocation Request message (5), and the target RNC responds with Relocation Request Ack once this is complete (6). Once the GERAN/UTRAN RAB and PDP context are in place, the target SGSN sends the Forward Relocation Response to the source MME (7).

Further Reading: 3GPP TS 23.401:5.5.2

6.24

© Wray Castle Limited

LT3600/v3.1

LTE Operation UE

Source eNB

Target RNC

MME

Source S-GW

Target

SGSN

PDN-GW

Data Flow 9. Handover Command 10a . HO from E-UTRAN Command Release and reconnect 10b. HO to UTRAN Complete

11a. Downlink Data via Direct Forwarding (eNB-RNC) 11b. Downlink Data via Indirect Forwarding

11a/b. Downlink Data 11c. Uplink Data Indirect Forwarding Direct Forwarding Optional Stage

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 Relocation Complete 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 LT3600/v3.1

© Wray Castle Limited

6.25

LTE/SAE Engineering Overview UE

Source eNB

Target RNC

MME

Source S-GW

Target

SGSN

PDN-GW

14. Update Bearer Request/Response

15. Data Flow

16. Routing Area Update

17. Release Resources

Indirect Forwarding

17. Delete Bearer Request/Response

18. Delete Bearer Request/Response (if Indirect Forwarding used)

Direct Forwarding Optional Stage

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

6.26

© Wray Castle Limited

LT3600/v3.1

LTE/SAE Engineering Overview

LTE/SAE ENGINEERING OVERVIEW

GLOSSARY OF TERMS

© Wray Castle Limited

I

LTE/SAE Engineering Overview

II

© Wray Castle Limited

LTE/SAE Engineering Overview

16QAM 1xEV-DO 3G 3GPP 64QAM

16-state Quadrature Amplitude Modulation 1x Evolution – Data Only Third Generation 3rd Generation Partnership Project 64-state Quadrature Amplitude Modulation

A1AP AAA AAL ACLR AF AKA AM AMBR ANR APN ARP ARQ AS AS ATM AUTN AV

A1 Application Protocol Authentication, Authorization and Accounting ATM Adaptation Layer Adjacent Channel Leakage Ratio Application Function Authentication and Key Agreement Acknowledged Mode Aggregate Maximum Bit Rate Automatic Neighbour Relation Access Point Name Allocation and Retention Priority Automatic Repeat Request Access Stratum Application Server Asynchronous Transfer Mode Authentication Token Authentication Vector

BCCH BCH BER BI BLER BPSK BSC BSIC BSS BSSAP+ BSSGP

Broadcast Control Channel Broadcast Channel Bit Error Rate Backoff Indicator Block Error Rate Binary Phase Shift Keying Base Station Controller Base Station Identity Code Base Station System Base Station System Application Part + Base Station System GPRS Protocol

CCCH CCE CCO CDMA CDRs CE CFI CGI CK CLI CMAC CMC CP CPT CQI CRC C-RNTI C-RNTI CS CSCF CSG

Common Control Channel Control Channel Element Cell Change Order Code Division Multiple Access Call Data Records Control Element Control Format Indicator Cell Global Identity Cipher Key Calling Line Identity Cipher-based MAC Connection Mobility Control Cyclic Prefix Control PDU Type Channel Quality Indication Cyclic Redundancy Check Cell Radio Network Temporary Identifier Controlling Radio Network Temporary Identifier Circuit Switched Call Session Control Function Closed Subscriber Group

LT3600/v3.1

© Wray Castle Limited

G.1

LTE/SAE Engineering Overview

D/C DAB DCCH DCI DFT DFT DHCP DiffServ DL DL-SCH DMT DNS DRA DRB DRS DRX DSCP DSMIPv6 DSP DT DTAP DTCH DVB DVB-T/H/S DVRB DwPTS DwPTS

Data/Control Digital Audio Broadcasting Dedicated Control Channel Downlink Control Information Discrete Fourier Transform Discrete Fourier Transform Dynamic Host Configuration Protocol Differentiated Services Downlink Downlink Shared Channel Discrete Multi-Tone modulation Domain Name Server Dynamic Resource Allocation Data Radio Bearer Demodulation Reference Signals Discontinuous Reception DiffServ Code Point Dual Stack Mobile IP version 6 Digital Signal Processor Data Transfer Direct Transfer Application Part Dedicated Traffic Channel Digital Video Broadcasting Digital Video Broadcasting for Terrestrial Handheld and Satellite Distributed Virtual Resource Block Downlink Pilot Time Slot Downlink Pilot Time Slot

E E1 EARFCN EARFCN EARFCN EBI ECGI eCGI ECM EDGE E-GPRS2 EIA EIR eKSI EM EMM eNB EP EPC EPRE EPS E-RAB E-RAB ESM ETSI ETWS E-UTRA E-UTRAN

Extension Extension E-UTRA Absolute Radio Frequency Channel Number E-UTRAN Absolute Radio Frequency Channel Number Evolved Absolute Radio Frequency Channel Number EPS Bearer Identity E-UTRAN Cell Global Identity Evolved Cell Global identity EPS Connection Management Enhanced Data rates for Global Evolution Enhanced GPRS 2 EPS Integrity Algorithm Equipment Identity Register E-UTRAN Key Set Identifier Element Manager EPS Mobility Management Evolved Node B Elementary Procedure Evolved Packet Core Energy Per Resource Element Evolved Packet System E-UTRAN Radio Access Bearer Evolved Radio Access Bearer EPS Session Management European Telecommunication Standards Institute Earthquake and Tsunami Warning System Evolved Universal Terrestrial Radio Access Evolved Universal Terrestrial Radio Access Network

G.2

© Wray Castle Limited

LT3600/v3.1

LTE/SAE Engineering Overview

FA FDD FDM FFT FI FMS

Foreign Agent Frequency Division Duplex Frequency Division Multiplexing Fast Fourier Transform Framing Information First Missing PDCP SN

GAN GANC GBR GERAN GGSN GMM GMSC G-PDU GPRS GPS GSM GT GTP GTP-C GTP-U GTPv1-U GTPv2 GTPv2-C GU GUMMEI GUTI

Generic Access Network Generic Access Network Controller Guaranteed Bit Rate GSM EDGE Radio Access Network Gateway GPRS Support Node GPRS Mobility Management Gateway MSC GTP Protocol Data Unit General Packet Radio Service Global Positioning System Global System for Mobile communications Guard Time GPRS Tunnelling Protocol GPRS Tunnelling Protocol – Control plane GPRS Tunnelling Protocol – User plane GPRS Tunnelling Protocol version 1 – User Plane GTP version 2 GPRS Tunnelling Protocol version 2 – Control Plane Globally Unique Globally Unique MME Identity Globally Unique Temporary Identity

HARQ HeNB HeNB GW HFN HII HLR HNB HO H-PCRF H-PLMN HSDPA HSPA HSS HSUPA

Hybrid ARQ Home eNode B Home eNB Gateway Hyper Frame Number High Interference Information Home Location Register Home Node B Handover Home Policy and Charging Rules Function Home PLMN High Speed Downlink Packet Access High Speed Packet Access Home Subscriber Server High Speed Uplink Packet Access

IAM ICIC I-CSCF IDFT IE IETF IFFT IK I-MAC IMEISV IMS IMSI IMT-2000 IP IP-CAN

Initial Address Message Inter-Cell Interference Coordination Interrogating Call State Control Function Inverse Discrete Fourier Transform Information Element Internet Engineering Task Force Inverse Fast Fourier Transform Integrity Key Integrity Message Authentication Code International Mobile Equipment Identity Software Version IP Multimedia Subsystem International Mobile Subscriber Identity International Mobile Telecommunications 2000 Internet Protocol IP Connectivity Access Network

LT3600/v3.1

© Wray Castle Limited

G.3

LTE/SAE Engineering Overview

IPsec IPv4 IPv6 I-RAT ISI ISR

IP security IP version 4 IP version 6 Inter-Radio Access Technology Inter Symbol Interference Idle Mode Signalling Reduction

KASME KSI

Key Access Security Management Entries Key Set Identifier

LA LB LCID LCR LI LSF LTE

Location Area Load Balancing Logical Channel ID Low Chip Rate Length Indicator Last Segment Flag Long Term Evolution

MAC MAC MBMS MBR MBSFN MC MCC MCS MGW MIB MIMO MIPv4 MME MMEC MMEGI MMEI MNC MS MSC MSISDN M-TMSI MTU MU-MIMO

Medium Access Control Message Authentication Code Multicast and Broadcast Multimedia Services Maximum Bit Rate Multicast/Broadcast Single Frequency Network Mobile Country Code Mobile Country Code Modulation and Coding Scheme Media Gateway Master Information Block Multiple Input Multiple Output Mobile IP version 4 Mobility Management Entity MME Code MME Group Identifier MME Identifier Mobile Network Code Mobile Station Mobile-services Switching Centre Mobile Subscriber ISDN Number MME Temporary Mobile Subscriber Identity Maximum Transmission Unit Multi-User MIMO

NACC NAS NCL

Network Assisted Cell Change Non Access Stratum Neighbour Cell List

O&M OAM OFDM OFDMA

Operations and Maintenance Operations, Administration and Maintenance Orthogonal Frequency Division Multiplexing Orthogonal Frequency Division Multiple Access

P P/S-SCH PAPR PBCH PBR PCC PCCH PCEF

Polling Primary/Secondary Synchronization Channel Peak to Average Power Ratio Physical Broadcast Channel Prioritized Bit Rate Policy Control and Charging Paging Control Channel Policy and Charging Enforcement Function

G.4

© Wray Castle Limited

LT3600/v3.1

LTE/SAE Engineering Overview

PCFICH PCH PCI PCRF PCRF PCS PDCCH PDCP PDN PDN-GW PDP PDSCH PDU PF PHICH PLMN PMCH PMI PMIPv6 PO PPP PR PRACH PRACK PRB P-RNTI PS PS PSS PSTN PTI PUSCH

Physical Control Format Indicator Channel Paging Channel Physical Cell ID Packet Control Resource Function Policy and Charging Rules Function PDN Connectivity Service Physical Downlink Control Channel Packet Data Convergence Protocol Packet Data Network Packet Data Network Gateway Packet Data Protocol Physical Downlink Shared Channel Protocol Data Unit Paging Frame Physical H-ARQ Indicator Channel Public Land Mobile Network Physical Multicast Channel Pre-coding Matrix Indicators Proxy Mobile IPv6 Paging Occasion Point-to-Point Protocol Paging Record Physical Random Access Channel Provisional Acknowledgement Physical Resource Block Paging RNTI Packet Scheduling Packet Switched Primary Synchronization Signal Public Switched Telephone Networks Procedure Transaction Identity Physical Uplink Shared Channel

QAM QCI QoS QPSK

Quaderature Amplitude Modulation QoS Class Identifier Quality of Service Quadrature Phase Shift Keying

R8 R99 RA RAC RACH RADIUS RAI RAN RANAP RAND RAR RAT RAU RB RB RBC RBG RES RF RF RFC

Release 8 Release 99 Routing Area Radio Admission Control Random Access Channel Remote Access Dial-In User Service Routing Area Identity Radio Access Network Radio Access Network Application Part Random Number Random Access Response Radio Access Technology Routing Area Update Radio Bearer Resource Block Radio Bearer Control Radio Block Group Response Radio Frequency Resegmentation Flag Request For Comment

LT3600/v3.1

© Wray Castle Limited

G.5

LTE/SAE Engineering Overview

RFSP RFSP Index RI RIM RLC RLP RNC RNS RNSAP RNSAP RNTI RNTP ROCH RoHC RRC RRM RSRP RSRQ RSSI RTCP RTP

RAT/Frequency Selection Priority Index to RAT/Frequency Selection Priority Rank Indicators RAN Information Management Radio Link Control Radio Link Protocol Radio Network Controller Radio Network Subsystem Radio Network Subsystem Application Part Radio Network Subsystem Application Protocol Radio Network Temporary Identifier Relative Narrowband Robust Header Compression Robust Header Compression Radio Resource Control Radio Resource Management Reference Signal Received Power Reference Signal Received Quality Received Signal Strength Indicator Real Time Control Protocol Real Time Protocol

S1AP SAE SAP SC-FDMA S-CSCF SCTP SDF SDP SDU SFN SG SGsAP SGSN S-GW S-GW SI SIB SIGTRAN SIM SIP SI-RNTI SISO SMS SN SO SON SPS SRB SRI SRS SRVCC SS7 SSN SSS S-TMSI SU-MIMO

S1 Application Protocol System Architecture Evolution Service Access Point Single Carrier FDMA Serving Call State Control Function Stream Control Transmission Protocol Service Data Flow Session Description Protocol Service Data Unit Single Frequency Network Signalling Gateway SGs Application Part Serving GPRS Support Node Serving Gateway Signalling Gateway Stream Identifier System Information Block Signalling Transport Subscriber Identity Module Session Initiation Protocol System Information RNTI Single Input Single Output Short Message Service Sequence Number Segment Offset Self-Organising Network Semi Persistent Scheduling Signalling Radio Bearer Send Routing Information Sounding reference Signals Single Radio VCC Signalling System No 7 Stream Sequence Number Secondary Synchronization Signal SAE TMSI Single-User MIMO

G.6

© Wray Castle Limited

LT3600/v3.1

LTE/SAE Engineering Overview

TA TA TA TAC TAD TAI TAU TB TCP TDD TDM TD-SCDMA TEID TFT TIN TM TMSI TNL TPC TPC-PUCCH-RNTI T-PDU TSN TTI

Timing Advance Transport Address Tracking Area Tracking Area Code Traffic Aggregate Descriptor Tracking Area ID Tracking Area Update Transport Block Transmission Control Protocol Time Division Duplex Time Division Multiplexing Time Division Synchronous Code Division Multiple Access Tunnel Endpoint ID Traffic Flow Template Temporary Identity used in Next update Transparent Mode Temporary Mobile Subscriber Identity Transport Network Layer Transmit Power Control Transmit Power Control PUCCH RNTI Transport Protocol Data Unit Transmission Sequence Number Transmission Time Interval

UDP UE UL UL-SCH UM UMTS UPE UpPTS USIM UTRAN

User Datagram Protocol User Equipment Uplink Uplink Shared Channel Unacknowledged Mode Universal Mobile Telecommunications System User Plane Entity Uplink PTS Universal Subscriber identity Module UMTS Terrestrial Radio Access Network

VCC VLR VoIP VoLGA V-PCRF VRB

Voice Call Continuity Visitor Location Register Voice over IP Voice over LTE Generic Access Visited Policy and Charging Rules Function Virtual Resource Block

WCDMA WiMAX WLAN

Wideband Code Division Multiple Access Worldwide Interoperability for Microwave Access Wireless Local Area Network

X2AP XRES

X2 Application Protocol Expected Response

LT3600/v3.1

© Wray Castle Limited

G.7

LTE/SAE Engineering Overview

G.8

© Wray Castle Limited

LT3600/v3.1