LTE RAN

LTE Radio Access Network Course Code: LT3603

Duration: 2 days

Technical Level: 3

... delivering knowledge, maximizing performance...

LTE courses include: n

LTE/SAE Engineering Overview

n

LTE Air Interface

n

LTE Radio Access Network

n

Cell Planning for LTE Networks

n

LTE Evolved Packet Core Network

n

4G Air Interface Technologies

n

LTE Technologies, Services and Markets

Wray Castle – leading the way in LTE training

www.wraycastle.com

LTE Radio Access Network

LTE RADIO ACCESS NETWORK

First published 2010 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.

© Wray Castle Limited

LTE Radio Access Network

ii

LT3603/v1

LTE and E-UTRAN Overview

LTE RADIO ACCESS NETWORK

Contents Section 1

LTE and E-UTRAN Overview

Section 2

Non-Access Stratum Processes

Section 3

S1 Interface Messages and Procedures

Section 4

X2 Interface Messages and Procedures

Section 5

Supporting Protocols and Technologies

Section 6

E-UTRAN Support for LTE Procedures

Glossary

LT3603/v1

© Wray Castle Limited

iii

LTE Radio Access Network

iv

LT3603/v1

LTE and E-UTRAN Overview

Section 1

LTE and E-UTRAN Overview

LT3603/v1

© Wray Castle Limited

v

LTE Radio Access Network

vi

LT3603/v1

LTE and E-UTRAN Overview

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 The EPC (Evolved Packet Core) ......................................................................................................... 1.9 S1 Interface ........................................................................................................................................... 10 Resilience Through Pooling ............................................................................................................... 1.11 Evolved Packet Core ‘S’ Interfaces.................................................................................................... 1.12 Data Rates and Services ................................................................................................................... 1.13 E-UTRA Protocols .............................................................................................................................. 1.14 PDN Connectivity Services ................................................................................................................ 1.15 Connection Hierarchies ...................................................................................................................... 1.16 EPS Bearers and E-RABs.................................................................................................................. 1.17 Connection Identifiers ........................................................................................................................ 1.18 Transport Identities ............................................................................................................................ 1.19 Default and Dedicated EPS Bearers.................................................................................................. 1.20

LT3603/v1

© Wray Castle Limited

vii

LTE Radio Access Network

viii

LT3603/v1

LTE and E-UTRAN Overview

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 toward converged 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 (Evolved Packet Core) including the eNB (evolved Node B), 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

ƒ

identify the role and extent of the PDN Connectivity Service, the EPS Bearer and the E-RAB

ƒ

outline the structure and use of the EPS Bearer ID, E-RAB ID and the UE identities employed on the S1 and X2 interfaces

LT3603/v1

© Wray Castle Limited

ix

LTE Radio Access Network

x

LT3603/v1

LTE and E-UTRAN Overview

100+ Mbit/s

40 Mbit/s 10 Mbit/s 400 kbit/s

LTE (4G)

UMTS/HSPA+

UMTS/HSPA

UMTS EDGE Evolution 1 Mbit/s GSM/EGPRS GSM/GPRS

150 kbit/s

50 kbit/s

LTE Overview

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, 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 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 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 can now access 3G-like performance through EDGE (Enhanced Data rates for Global Evolution) 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.

LT3603/v1

© Wray Castle Limited

1.1

LTE Radio Access Network

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

Broadband Access with LTE Wide-area LTE radio access combined with the EPC represents a complete adoption of an all-IP (Internet Protocol) 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 realtime operation of high-quality 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

LT3603/v1

LTE and E-UTRAN Overview

LTE

SAE

EPS UE E-UTRA E-UTRAN

EPC

Architecture Terminology

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.

LT3603/v1

© Wray Castle Limited

1.3

LTE Radio Access Network

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 latencey ƒ scalable bandwidth up to 20 MHz ƒ interworking with 3G systems

LTE Development and Design Goals

LTE Development and Design Goals The debate about the structure and composition of LTE has been ongoing since at least 2004, with many organizations promoting their preferred technological solutions. 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 (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

LT3603/v1

LTE and E-UTRAN Overview

Phase 1

Phase 2

GSM900

GSM1800 GSM1900

Phase 2+

Rel 96-98

Rel 99

Rel 4

Rel 5

Rel 6

Rel 7

Rel 8

Rel 9

EDGE Evolution

GPRS EGPRS Rel 99 UMTS

Rel 4

Rel 5

Rel 6

Rel 7

HSDPA IMS

HSUPA

HSPA+

Rel 8

Rel 9

UMTS/SAE

Rel 8

Rel 9

LTE/SAE

LTE-A

LTE Standards Development

LTE Standards Development Since the publication of the first GSM specifications in the late 1980s, the technologies and techniques employed by GSM networks have continued to evolve and develop. 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. 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. Releases 5 and 6 introduced HSPA – HSDPA (High Speed Downlink Packet Access) in Release 5 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. Some have termed LTE ‘3.9G’, while others have queried whether it should be regarded as a 4G technology.

LT3603/v1

© Wray Castle Limited

1.5

LTE Radio Access Network

LTE Signalling

LTE Traffic

SCTP E-UTRA E-UTRAN

All-IP

EPC

LTE Key Technologies

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

LT3603/v1

LTE and E-UTRAN Overview

• • • • • • •

inter-cell RRM radio bearer control connection mobility control radio admission control measurement control cell configuration dynamic resource allocation

eNB

eNB (Evolved Node B)

Uu S1

X2

RRC PDCP

S1

RLC MAC PHY

Evolved Packet Core

E-UTRAN

LTE UE

Access Networks and the eNB

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. It retains many of the traditional roles associated with base stations, such as bearer management. It is responsible for routing U-plane traffic between each UE and its S-GW (Serving Gateway). The complexity of the eNB and of the decisions it is required to make are therefore much greater than for an R99 Node B.

LT3603/v1

© Wray Castle Limited

1.7

LTE Radio Access Network

X2-C X2-AP X2AP

SCTP IP Data Link Layer Physical Lyer

X2

X2-U User Plane PDUs

GTP-U UDP IP Data Link Layer Physical Layer

X2 Interface

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

LT3603/v1

LTE and E-UTRAN Overview

HSS

• NAS Security • Idle state mobility handling • EPS bearer control

MME PCRF

IP network

Internet • mobility • anchoring

S-GW

PDN-GW EPC

The Evolved Packet Core

The EPC (Evolved Packet Core) The reduced complexity in the RAN is mirrored by a similar reduction in the core network, where the EPC (Evolved Packet Core) structure consists of five main nodes, although others may be required for backwards-compatibility purposes. The MME handles control plane functions related to mobility management (authentication and security) and idle mode handling (location updates and paging), in which sense it is broadly analogous to the VLR (Visitor Location Register) or GMM (GPRS Mobility Management) functions found in legacy networks. The MME is also responsible for EPC bearer control, and so handles connection control signalling. The S-GW and PDN (Packet Data Network) Gateway are broadly analogous to the SGSN (Serving GPRS Support Node) and GGSN (Gateway GPRS Support Node) found in R99 networks and perform user plane handling, switching/routing and interfacing functions. Unlike legacy systems, however, bearer control has been removed from these devices and resides with the MME. The PCRF (Policy and Charging Rules Function) 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-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. LT3603/v1

© Wray Castle Limited

1.9

LTE Radio Access Network

S12AP S1-AP MME SCTP IP Data Link Layer Physical Layer

S1-MME

User Plane PDUs

S1-U

GTP–U UDP

S-GW

IP Data Link Layer Physical Layer

S1 Interface

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 (S1 Application Protocol) 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.10

© Wray Castle Limited

LT3603/v1

LTE and E-UTRAN Overview PDN-GW

Co-ordinated MME Pool and S-GW Service Area

E-UTRAN Tracking Areas served by Pools and Areas

Resilience Through Pooling

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 LT3603/v1

© Wray Castle Limited

1.11

LTE Radio Access Network 2G/3G SGSN

HSS

UMTS/ GPRS

S6a

S3

UTRAN/ GERAN

S4

PCRF

MME

S12

LTE

S7

S11

S1-MME

Rx+

IMS E-UTRAN

S5

S1-U

IP Services

PDN-GW

S-GW Interworking to MME

SGi

S2

WLAN or WiMAX

Evolved Packet Core ‘S’ Interfaces

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

1.12

© Wray Castle Limited

LT3603/v1

LTE and E-UTRAN Overview

Channel bandwidth Modulation and 1.4 MHz MIMO coding rate 1x1 0.9 QPSK 1/2

3 MHz

5 MHz

10 MHz

20 MHz

2.2

3.6

7.2

14.4

16QAM 1/2

1x1

1.7

4.3

7.2

14.4

28.8

16QAM 3/4

1x1

2.6

6.5

10.8

21.6

43.2

64QAM 3/4

1x1

3.9

9.7

16.2

32.4

64.8

64QAM 4/4

1x1

5.2

13.0

21.6

43.2

86.4

64QAM 3/4

2x2

7.8

19.4

32.4

64.8

129.6

64QAM 4/4

2x2

10.4

25.9

43.2

86.4

172.8

QPSK 1/2

1x1

0.9

2.2

3.6

7.2

14.4

16QAM 1/2

1x1

1.7

4.3

7.2

14.4

28.8

16QAM 3/4

1x1

2.6

6.5

10.8

21.6

43.2

16QAM 4/4

1x1

3.5

8.6

14.4

28.8

57.6

64QAM 3/4

1x1

3.9

9.7

16.2

32.4

64.8

64QAM 4/4

1x1

5.2

13.0

21.6

43.2

86.4

Source: WCDMA for UMTS: 4th Edition – Holma & Toskala (Ed)

Data Rates and Services

Data Rates and Services The potential peak data rates of 100 Mbit/s and more are only available when employing channel bandwidths of 20 MHz, which are difficult to find in most countries’ crowded radio environments. Even then, the fastest data rates will only be achievable on links that use advanced antenna techniques such as MIMO (Multiple Input Multiple Output). 2x2 MIMO, where both transmitter and receiver use two separate antennas to carry parallel streams of data over the same channel, is required for data rates of up to 170 Mbit/s, while future versions of E-UTRA that promise data rates of up to 360 Mbit/s would require 4x4 MIMO. The data rates for E-UTRA variants up to 2x2 MIMO in a 20 MHz channel are shown in the diagram. These data rates assume error coding rates of 1/2, 3/4 and 4/4, which are not currently defined in the specifications and so should only be considered to be an example of what is generically achievable with the technology. Data rates of 100 Mbit/s or more will provide users with access to almost any Internet or communications service currently available, from movie downloads and database access down to simpler communications activities such as making a telephone call or sending a text message. The capacity allocation method employed by E-UTRA has more in common with HSPA than R99 UMTS. There is no dedicated channel in LTE, meaning that bandwidth is shared between users in a flexible, on-demand way. This flexibility, coupled with the high data rates, makes E-UTRA very attractive. Although E-UTRA’s theoretical ability to provide one user in a cell with a 100 Mbit/s connection has been much discussed, network operators are more excited about the possibility of providing 1 Mbit/s connections to 100 simultaneous users in one cell.

LT3603/v1

© Wray Castle Limited

1.13

LTE Radio Access Network

User Equipment Non-Access Stratum (NAS)

eNB

RRC

RRC

PDCP

PDCP

RLC

RLC

MAC

MAC

Physical Layer

Physical Layer

Evolved Packet Core Non-Access Stratum (NAS)

E-UTRA Protocols

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

© Wray Castle Limited

LT3603/v1

LTE and E-UTRAN Overview

PDN Connectivity Service (PCS)

Evolved Packet System

EPS Bearer PDN-GW

Packet Data Network

PDN Connectivity Services

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 (PDN Gateway) 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 SDF (Service Data Flow) between the UE (User Equipment) and external data services. If a UE requires additional connectivity that is only available via a different PDN-GW Access Point, then additional PDN Connectivity Services may be established in parallel.

Further Reading: 3GPP TS 23.401:4.7.1 LT3603/v1

© Wray Castle Limited

1.15

LTE Radio Access Network PDN Connectivity Service (PCS)

EPS Bearer ID (EBI)

Radio Bearer ID

GTP TEID

GTP TEID

C-RNTI LCID

eNB UE

SGi

S5/S8

S1-U

S-GW

PDN-GW

Application Server

Connection Hierarchies

Connection Hierarchies To quote 3GPP TS 23.401 (4.7.1), ‘The Evolved Packet System provides IP connectivity between a UE and a PLMN external packet data network. This is referred to as a PDN Connectivity Service. The PDN Connectivity Service supports the transport of one or more Service Data Flows’. Within the EPS, user connectivity is provided via the EPS Bearer, which is analogous to the PDP Context provided by legacy 3GPP PS networks. The EPS Bearer tunnels user traffic between the PDN-GW APN and the UE via the S-GW and eNB and is, in reality, a concatenation of connections over three successive interfaces: ƒ a GTP-U tunnel over the S5 interface (PDN-GW to S-GW), identified by a GTP TEID ƒ a GTP-U tunnel over the S1-U interface (S-GW to eNB), also identified by a GTP TEID ƒ an E-UTRAN RB (Radio Bearer) on the LTE Uu interface (eNB to UE) LTE Radio Bearers are identified by the C-RNTI (Cell-specific Radio Network Temporary Identifier) and LCID (Logical Channel ID). There is a one-to-one mapping between an RB and an EPS Bearer. Each EPS Bearer can support multiple SDF, although as QoS in the EPC is applied on a ‘per bearer’ level, all SDFs sharing the same EPS Bearer will also share the same QoS (Quality of Service). UEs can be assigned multiple EPS Bearers with different QoS levels to support a varied service set.

Further Reading: 23.401:4.7; 36.300 1.16

© Wray Castle Limited

LT3603/v1

LTE and E-UTRAN Overview PDN Connectivity Service (PCS)

EPS Bearer ID

EPS Bearer ID

Radio Bearer ID

E-RAB ID

eNB UE

SGi

S5/S8

S1-U

S-GW

PDN-GW

Application Server

EPS Bearers and E-RABs

EPS Bearers and E-RABs An EPS Bearer (and the LTE RB that it maps to) carries traffic across the E-UTRAN and the EPC between the UE and the PDN-GW. An E-RAB (and the RB that it maps to) carries traffic between the UE and the S-GW over the E-UTRAN, which may involve journeys across both X2 and S1 interfaces. The E-RAB therefore travels over a subsection of the route traversed by the EPS Bearer and there is a one-to-one mapping between one pair of connections. To simplify the identification of connections, a paired EPS Bearer and E-RAB share the same 8-bit identifier; although only the least significant 4 bits of the ID are active.

Further Reading: 23.401:4.7; 36.300:8.2; 36.413:9.2.23 (E-RAB ID); 29.274:8.8 (EPS Bearer ID) LT3603/v1

© Wray Castle Limited

1.17

LTE Radio Access Network

MME

Data Radio Bearer

S-GW UE

PDN-GW

EPS Bearer

Connection Identifiers

Connection Identifiers The EPS Bearer ID is assigned by the MME upon bearer establishment. It uniquely identifies an EPS Bearer for one UE accessing via the E-UTRAN. 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 (E-UTRAN Radio Access Bearer) and between the identities assigned to each of those entities.

Further Reading: 3GPP TS 23.401:5.2.1 1.18

© Wray Castle Limited

LT3603/v1

LTE and E-UTRAN Overview eNB UE S1AP ID

MME UE S1AP ID

S1-MME S1-AP Context MME

S1-U GTP Tunnel

X2-U (GTP TE-Ids) X2-C (eNB UE X2AP ID)

S-GW

Tunnel Endpoint IDs (TE-ID)

Transport Identities

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 S1AP ID and MME S1AP 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 X2AP 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 X2AP 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 (Tunnel Endpoint ID) 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 S1AP 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) LT3603/v1

© Wray Castle Limited

1.19

LTE Radio Access Network

Both Bearers share same IP address

Initial or Default EPS Bearer

eNB

IMS

PDN-GW

S-GW

Subsequent or Dedicated EPS Bearer

UE

Both Bearers routed via same APN

Internet

Default and Dedicated Bearers

Default and Dedicated EPS Bearers Each UE will establish an initial or default EPS Bearer as part of the attach process. This will provide the required ‘always on’ IP connectivity to the UE and may be to a default APN (Access Point Name), if one is stored in the user’s subscriber profile, or to an APN selected by the network. In networks that interconnect to an IMS, the default bearer allows the UE to perform SIP registration and thereafter to provide a path for session initiation messaging. In these circumstances, the data rate and QoS assigned initially to the default bearer is commensurate with the expected low level of SIPbased 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 4-bit EPS Bearer ID limits the total number of bearers established for one UE to sixteen (numbered 0 to 15).

Further Reading: 3GPP TS 23.401:4.7.2 1.20

© Wray Castle Limited

LT3603/v1

LTE and E-UTRAN Overview

Section 1 Glossary 1xEV-DO 3GPP

1x Evolution – Data Only 3rd Generation Partnership Project

A1AP APN CDMA C-RNTI

A1 Application Protocol Access Point Name, Code Division Multiple Access Cell-specific Radio Network Temporary Identifier

EDGE eNB EPC E-RAB E-UTRA E-UTRAN

Enhanced Data rates for Global Evolution Evolved Node B Evolved Packet Core E-UTRAN Radio Access Bearer Evolved Universal Terrestrial Radio Access. Evolved Universal Terrestrial Radio Access Network

GGSN GMM GSM GTP-C GTP-U

Gateway GPRS Support Node GPRS Mobility Management Global System for Mobile Communications GPRS Tunnelling Protocol – Control plane GPRS Tunnelling Protocol – User plane

HLR HSDPA HSPA HSS HSUPA

Home Location Register High Speed Downlink Packet Access High Speed Packet Access. Home Subscriber Server High Speed Uplink Packet Access

IMS

IP Multimedia Subsystem

LCID LTE

Logical Channel ID Long Term Evolution

MAC MIMO MME

Medium Access Control Multiple Input Multiple Output Mobility Management Entity

OFDMA

Orthogonal Frequency Division Multiple Access

LT3603/v1

© Wray Castle Limited

1.21

LTE Radio Access Network

PCRF PCS PDCP PDN PDN-GW PDU QoS

Policy and Charging Rules Function PDN Connectivity Service Packet Data Convergence Protocol Packet Data Network. Packet Data Network Gateway Protocol Data Unit Quality of Service

RAN RANAP RB RLC RNC RNSAP RRC RRM

Radio Access Network Radio Access Network Application Part Radio Bearer Radio Link Control Radio Network Controller Radio Network Subsystem Application Protocol Radio Resource Control Radio Resource Management

S1AP SAE SC-FDMA SCTP SDF SGSN S-GW

S1 Application Protocol System Architecture Evolution Single Carrier FDMA Stream Control Transmission Protocol Service Data Flow Serving GPRS Support Node Serving Gateway

TCP TEID

Transmission Control Protocol Tunnel Endpoint ID

UDP UE UMTS

User Datagram Protocol User Equipment Universal Mobile Telecommunications System

VLR

Visitor Location Register

WiMAX WLAN

Worldwide Interoperability for Microwave Access Wireless Local Area Network

X2AP

X2 Application Protocol

1.22

© Wray Castle Limited

LT3603/v1

LTE Radio Access Network

Section 2

Non-Access Stratum Processes

© Wray Castle Limited

LTE Radio Access Network

ii

© Wray Castle Limited

LT3603/v1

Non-Access Stratum Processes

Contents LTE AS and NAS ................................................................................................................................. 2.1 NAS Identities ...................................................................................................................................... 2.2 UE State Machines .............................................................................................................................. 2.3 EMM States .......................................................................................................................................... 2.4 ECM (EPS Connection Management) States ...................................................................................... 2.5 NAS Functions and Procedures ........................................................................................................... 2.6 Active EPS Bearers and Bearer Contexts ........................................................................................... 2.7 Inactive EPS Bearers and Bearer Contexts ......................................................................................... 2.8 NAS Message Structure....................................................................................................................... 2.9 Message Types .................................................................................................................................. 2.10 EMM Messages ................................................................................................................................. 2.11 EMM Common Procedures ................................................................................................................ 2.12 GUTI Reallocation .............................................................................................................................. 2.13 Authentication .................................................................................................................................... 2.14 Security Mode Control........................................................................................................................ 2.15 Identification ....................................................................................................................................... 2.16 EMM Information ................................................................................................................................ 2.17 CS Service Notification ...................................................................................................................... 2.18 EMM Specific Procedures .................................................................................................................. 2.19 Attach ................................................................................................................................................. 2.20

LT3603/v1

© Wray Castle Limited

iii

LTE Radio Access Network

Combined Attach................................................................................................................................ 2.22 Detach ................................................................................................................................................ 2.23 Network-initiated Detach .................................................................................................................... 2.24 Tracking Area Update (TAU) Process ............................................................................................... 2.25 TAU Message .................................................................................................................................... 2.26 EMM Connection Management Messages ........................................................................................ 2.27 Service Request and Extended Service Request .............................................................................. 2.28 Service Request Process ................................................................................................................... 2.29 Paging ................................................................................................................................................ 2.30 Transport of NAS Messages .............................................................................................................. 2.31 EPS Session Management (ESM) Messages ................................................................................... 2.32 Default EPS Bearer Context Activation.............................................................................................. 2.33 Default EPS Bearer Context Activation Message .............................................................................. 2.34 Dedicated EPS Bearer Context Activation ......................................................................................... 2.35 EPS Bearer Context Modification ...................................................................................................... 2.36 EPS Bearer Context Deactivation ...................................................................................................... 2.37 PDN Connectivity ............................................................................................................................... 2.38 PDN Disconnect ................................................................................................................................. 2.39 Bearer Resource Allocation ............................................................................................................... 2.40 Bearer Resource Modification ............................................................................................................ 2.41 ESM Information Request/Response................................................................................................. 2.42 ESM Status ........................................................................................................................................ 2.43 NAS Security ...................................................................................................................................... 2.44 Security Header Types....................................................................................................................... 2.45 Integrity Protection ............................................................................................................................. 2.46 Ciphering ............................................................................................................................................ 2.47

iv

© Wray Castle Limited

LT3603/v1

Non-Access Stratum Processes

Objectives

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

outline the roles of the LTE Access Stratum (AS) and Non-Access Stratum

ƒ

list the set of identifiers employed by the NAS

ƒ

describe the set of mobility and connection management state machines employed

ƒ

discuss the differences between active and inactive EPS Bearer Contexts

ƒ

outline the basic set of functions performed by NAS message types

ƒ

describe the basic structure of a NAS message

ƒ

discuss the functions of the NAS EMM message types

ƒ

discuss the functions of the NAS ESM message types

ƒ

outline the functions employed to provide NAS security

LT3603/v1

© Wray Castle Limited

v

LTE Radio Access Network

vi

© Wray Castle Limited

LT3603/v1

Non-Access Stratum Processes

User Equipment

Uu

eNode B

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

S1

Evolved Packet Core

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

LTE AS and NAS

LTE AS and NAS As with UMTS R99, the services provided to UEs by the EPS are divided into those handled by the AS (Access Stratum) and those provided by the NAS (Non-Access Stratum). 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 (S1 Application Protocol) 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 (E-UTRAN) and 24.301 (NAS) LT3603/v1

© Wray Castle Limited

2.1

LTE Radio Access Network

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

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 (Temporary Mobile Subscriber Identity), 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, MNC 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 (MME Code) to the M-TMSI. The MMEC is the MME’s index within its pool.

Further Reading: 3GPP TS 36.300 (E-UTRAN) and 24.301 (NAS) 2.2

© Wray Castle Limited

LT3603/v1

Non-Access Stratum Processes

MME

eNB

RRC

UE

RRC

ECM

ECM

EMM

EMM

State machines store UE and bearer context data

UE State Machines

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 LT3603/v1

© Wray Castle Limited

2.3

LTE Radio Access Network

Detach, Attach Reject

MME

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

© Wray Castle Limited

LT3603/v1

Non-Access Stratum Processes

MME

S1 connection released ECM-Idle

ECM-Connected S1 connection established

RCC connection released ECM-Idle

ECM-Connected RCC connection established

UE

ECM States

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 LT3603/v1

© Wray Castle Limited

2.5

LTE Radio Access Network

To support UE mobility To support the session management procedures that establish and maintain IP connectivity between the UE and a PDN-GW. NAS – Non Access Stratum

EMM – EPS Mobility Management ESM – EPS Session Management

NAS Functions and Procedures

NAS Functions and Procedures The EPS NAS offers the highest stratum of signalling and control between a UE and an MME. The main functions performed by the NAS are support of UE mobility and support of the session management procedures that establish and maintain IP connectivity between the UE and a PDN-GW. Integrity Protection and Ciphering are offered by the EPS NAS as a means of securing signalling transaction between the UE and an MME. NAS functions are performed by invoking a specific EP (Elementary Procedure). EPs exist to perform functions that support mobility and session management. Sets of EPs have been defined that relate to EMM, which perform Attach, security and location update functions, and others have been defined that relate to ESM (EPS Session Management), which perform bearer management and resource allocation functions.

2.6

© Wray Castle Limited

LT3603/v1

Non-Access Stratum Processes

Bearer Context – Active Bearer Attributes

MME

UE

eNB

RRC

S-GW

S1 Tunnel

PDN-GW

S5/S8 Tunnel

Radio Bearer/E-RAB/EPS Bearer Active Active EPS Bearers and Bearer Contexts

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 LT3603/v1

© Wray Castle Limited

2.7

LTE Radio Access Network

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

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 [EPS Session Management] BEARER CONTEXT INACTIVE state.

Further Reading: 3GPP TS 23.401:4.7.2 2.8

© Wray Castle Limited

LT3603/v1

Non-Access Stratum Processes

7 6 5 4 3 2 1 EPS Bearer ID (ESM) or Protocol Discriminator Security Header Type (EMM) Procedure Transaction Identity Message Type 8

1 1a (ESM only) 2 3

Message Information Elements n Protocol Discriminator = 0010 for ESM, 0111 for EMM PTI (Procedure Transaction Identity) only required for ESM

NAS Message Structure

NAS Message Structure EPS NAS messages are constructed following the standard Layer 3 message structure employed in legacy ETSI/3GPP network types such as GPRS (detailed in 3GPP TS24.007). The message formats are based on industry-standard CSN.1 syntax and coding rules. Most NAS messages are constructed following one of the two main format options: Plain NAS messages and Security Protected NAS messages. Plain NAS transactions consist of messages sent in clear with no integrity protection. Security Protected NAS messages can be integrity protected (using a MAC) only or can have integrity protection and a ciphered payload. The payload of a Security Protected message is a Plain NAS message. EPS Bearer Identities are only required in ESM messages which deal with resource management for individual bearers. In the absence of an EPS Bearer ID the Security Header of a plain NAS message is always set to 0000. The Protocol Discriminator field will take the value 0010 for ESM messages and 0111 for EMM functions. A Procedure Transaction Identity is only required for ESM message types and acts as a unique identifier for a transaction in progress between an individual UE and the MME. The ECM SERVICE REQUEST message employs a simpler but non-standard Layer 3 format which is slightly different to those shown in the diagram.

Further Reading: 3GPP TS24.301:9.1 (message formats) LT3603/v1

© Wray Castle Limited

2.9

LTE Radio Access Network

8 7 6 5 4 3 2 1 0 1 -

-

-

-

-

-

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0

0 0 0 0 0 0 1 1 1 1 1 1 0 0 0 0 0 1 0 0 1 1 1 0 0 0 0 0

0 0 0 1 1 1 0 0 0 0 1 1 0 0 0 0 1 1 1 1 1 1 1 0 0 0 0 1

0 1 1 0 0 1 0 0 1 1 0 1 0 0 1 1 0 0 0 1 0 1 1 0 0 1 1 0

1 0 1 0 1 0 0 1 0 1 0 0 0 1 0 1 0 0 1 0 1 0 1 0 1 0 1 0

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1

8 7 6 5 4 3 2 1 EMM – EPS Mobility Management Attach Request Attach Accept Attach Complete Attach Reject Detach Request Detach Accept TAU Request TAU Accept TAU Complete TAU Reject Extended Service Request Service Request GUTI Reallocation Command GUTI Reallocation Complete Authentication Request Authentication Response Authentication Reject Authentication Failure Identity Request Identity Response Security Mode Command Security Mode Complete Security Mode Reject EMM Status EMM Information Downlink NAS Transport Uplink NAS Transport CS Service Notification

1 1 -

-

-

-

-

-

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0

0 0 0 0 0 0 1 1 1 1 1 0 0 0 0 0 0 0 0 1 1 1

0 0 0 1 1 1 0 0 0 1 1 0 0 0 0 1 1 1 1 0 0 0

0 1 1 0 1 1 0 1 1 0 1 0 0 1 1 0 0 1 1 0 1 0

1 0 1 1 0 1 1 0 1 1 0 0 1 0 1 0 1 0 1 1 0 0

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1

ESM – EPS Session Management Activate Default EPS Bearer Context Request Activate Default EPS Bearer Context Accept Activate Default EPS Bearer Context Reject Activate Dedicated EPS Bearer Context Request Activate Dedicated EPS Bearer Context Accept Activate Dedicated EPS Bearer Context Reject Modify EPS Bearer Context Request Modify EPS Bearer Context Accept Modify EPS Bearer Context Reject Deactivate EPS Bearer Context Request Deactivate EPS Bearer Context Accept PDN Connectivity Request PDN Connectivity Reject PDN Disconnect Request PDN Disconnect Reject Bearer Resource Allocation Request Bearer Resource Allocation Reject Bearer Resource Modification Request Bearer Resource Modification Reject ESM Information Request ESM Information Response ESM Status

Message Types

Message Types Message Type codes are used to identify the type of transaction being performed by a NAS message. Message Type codes starting with 01 relate to EMM functions whilst codes starting 11 relate to ESM messages.

Further Reading: 3GPP TS24.301:9.8 2.10

© Wray Castle Limited

LT3603/v1

Non-Access Stratum Processes

EMM – EPS Mobility Management EMM Common procedures EMM Specific procedures EMM Connection Management procedures

EPS Mobility Management (EMM) Messages

EMM Messages Three types of EMM procedure are defined for NAS messaging purposes: EMM Common procedures, EMM Specific procedures and EMM Connection Management procedures. EMM Common Procedures are initiated by the network and can only be performed when a NAS signalling connection already exists between the MME and the target UE. EMM Specific procedures handle Attach, Detach and TAU functions; some procedures can only be performed by the UE, others can be performed by the UE or the network. Only one EMM Specific procedure can be in progress per UE at any one time. EMM Connection Management (which is a subset of EMM functionality and is distinct from ECM – EPS Connection Management) procedures are used to handle connection establishment functions such as UE-initiated SERVICE REQUEST and network-initiated PAGING messages. The transport of NAS messages is also handled by this subset of message types. A set of EMM Specific and Connection Management procedures (ATTACH REQUEST, TRACKING AREA UPDATE REQUEST, DETACH REQUEST, SERVICE REQUEST and EXTENDED SERVICE REQUEST) are grouped and classed as ‘initial NAS messages’. The EMM Specific TAU functions and all of the EMM Connection Management functions are only applicable to a UE that is in ‘S1 mode’, which means that the UE is Attached to the EPS and communicating via an eNB that has an S1 connection to an MME. Alternative UE connection modes are A/Gb (via GSM/GPRS), Iu (via UMTS) and S101 (via CDMA2000) access networks.

Further Reading: 3GPP TS24.301:5.1.2 LT3603/v1

© Wray Castle Limited

2.11

LTE Radio Access Network

EMM Common Elementary Procedures 0 0 0 0 0 0 0 0 0 0 0 0

1 1 1 1 1 1 1 1 1 1 1 1

0 0 0 0 0 0 0 0 0 0 0 1

1 1 1 1 1 1 1 1 1 1 1 0

0 0 0 0 0 1 0 0 1 1 1 0

0 0 0 0 1 1 1 1 1 1 1 0

0 0 1 1 0 0 0 1 0 1 1 0

0 1 0 1 0 0 1 0 1 0 1 0

GUTI Reallocation Command GUTI Reallocation Complete Authentication Request Authentication Response Authentication Reject Authentication Failure Identity Request Identity Response Security Mode Command Security Mode Complete Security Mode Reject EMM Status

All network-initiated

EMM Common Procedures

EMM Common Procedures EMM Common Procedures are all network-initiated and provide the means to manage UE identification and authentication processes. This set of procedures also controls the implementation of NAS connection security. The subset of EPs belonging to the Common Procedures type consists of: ƒ GUTI Reallocation ƒ Authentication ƒ Security Mode Control ƒ Identification ƒ EMM Information An existing signalling connection must be in place between the initiating MME and the target UE before any of these function types can be performed.

Further Reading: 3GPP TS24.301:5.1.2 2.12

© Wray Castle Limited

LT3603/v1

Non-Access Stratum Processes

EMM Common EP GUTI Reallocation Network Initiated UE

MME

GUTI REALLOCATION COMMAND Start T3450

GUTI REALLOCATION COMPLETE Stop T3450

GUTI REALLOCATION COMMAND Information Element

Required

Length

Protocol Discriminator

Mand

1/2

Security Header Type

Mand

1/2

Message Type

Mand

1

New GUTI New TAI List

Mand Opt

12 8-98

GUTI Reallocation

GUTI Reallocation The GUTI (Globally Unique Temporary Identity) is created as the concatenation of the GUMMEI (Globally Unique MME ID), which identifies the MME, and the M-TMSI (MME Temporary Mobile Subscriber Identity), which 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 allocation of a new MTMSI results in a GUTI Reallocation procedure. In addition to a new GUTI, the MME may also elect to issue the UE an new or updated TAI List. This list shows the TAI (Tracking Area Identity) of all TAs within which the UE can roam without performing a TAU. GUTI Reallocation usually takes place in ciphered mode. When the MME issues the GUTI REALLOCATION message it starts timer T3450, which provides a maximum period within which the Reallocation should be completed. If the UE receives and processes the GUTI REALLOCATION COMMAND messages correctly it responds with GUTI REALLOCATION COMPLETE. The MME then stops timer T3450. If T3450 expires without a response from the UE the MME may retransmit the GUTI REALLOCATION COMMAND. This process can be repeated up to four times and if the UE continues to fail to respond it will be forced to re-Attach to receive network service. If a UE receives a new TAI List that does not include the identity of the current TA it will perform a TAU.

Further Reading: 3GPP TS24.301:5.4.1 and 8.2.12/13 LT3603/v1

© Wray Castle Limited

2.13

LTE Radio Access Network

EMM Common EP Authentication Network Initiated UE

MME

AUTHENTICATION REQUEST Start T3460

AUTHENTICATION RESPONSE

Stop T3460

AUTHENTICATION REJECT

AUTHENTICATION REQUEST Information Element

Required

Length

Protocol Discriminator

Mand

1/2

Security Header Type

Mand

1/2

Message Type

Mand

1

NAS Key Set Identifier

Mand

1/2

Spare

Mand

1/2

RAND

Mand

16

AUTN

Mand

17

Authentication

Authentication Authentication is usually performed as part of the Attach procedure and also during Tracking Area Updates. It is controlled by the EPS AKA (Authentication and Key Agreement) process and allows a UE and the network mutually authenticate each other. A successful Authentication procedure results in a Security Context being established in the UE and the MME which stores, amongst other data, the computed value of KASME used as the root for EPS Integrity Protection and Ciphering procedures. Authentication is always initiated by the network. The UE can elect to accept or reject the authentication challenge issued by the network. Rejection would occur if, for example, the UE had no valid USIM installed or could not recover the required security information from the USIM. The MME initiates the process by issuing an AUTHENTICATION REQUEST to the UE, which contains the vectors (including RAND and AUTN) required to allow the UE/USIM to calculate a response. Timer T3460 is started in the MME at this point. If the UE is required to authenticate the network it will check the AUTN details provided before computing a response (RES) to the RAND challenge. If the process completes successfully the UE returns an AUTHENTICATION RESPONSE containing the computed RES challenge response to the MME. If the process fails, for example if the AUTN authentication vectors provided by the network are deemed to be invalid, the UE will respond with an AUTHENTICATION FAILURE message to the MME. On receipt of either response type the MME stops timer T3460. In the event of a positive response from the UE, the MME processes the supplied challenge response and determines whether the authentication process has been successful. If the authentication is accepted it is implicitly acknowledged to the UE by sending no confirmation; if the authentication is not accepted by the MME is is explicitly rejected by sending an AUTHENTICATION REJECT message to the UE.

Further Reading: 3GPP TS24.301:5.4.2 and 8.2.5-8 and 33.401 (EPS AKA) 2.14

© Wray Castle Limited

LT3603/v1

Non-Access Stratum Processes

EMM Common EP Security Mode Network Initiated UE

MME

SECURITY MODE COMMAND

Start T3460

SECURITY MODE COMPLETE

Stop T3460

OR

SECURITY MODE REJECT

Stop T3460

SECURITY MODE COMMAND Information Element

Required

Length

Protocol Discriminator

Mand

1/2

Security Header Type

Mand

1/2 1

Message Type

Mand

Selected NAS Security algorithms

Mand

1

NAS Key Set Identifier

Mand

1/2

Spare

Mand

1/2

Replayed UE Capabilities

Mand

3-6

IMSISV Request

Opt

1

Replayed NonceUE

Opt

5

NonceMME

Opt

5

Security Mode Control

Security Mode Control The Authentication process leads to the computation of KASME and the creation of a shared EPS Security Context between the UE and the MME; the Security Mode Control process is employed to invoke the Security Context when required. Security Mode is also employed when a change to the current set of security vectors is required. Security mode control is initiated by the MME, which issues a SECURITY MODE COMMAND and starts timer T3460. The command is sent in clear in a Plain NAS message but it employs Integrity Protection by adding a NAS integrity key computed from the current KASME value. If security mode is being invoked immediately after a successful EPS authentication procedure the MME will also reset the downlink NAS COUNT at this point. Upon receipt of the command, the UE checks the integrity of the message and if it determines that it is unaltered and therefore valid it takes the EPS Security Context referenced in the command into use. The UE uses the cipher and integrity keys related to the EPS Security Context to encrypt and integrity protect a response. The response is carried in a SECURITY MODE COMPLETE message to the MME, with the security header indicator set to ‘Integrity protected and ciphered with new EPS security context’. The MME deciphers the message and checks the validity of the Integrity Protection; if all is as expected it stops timer T3460 and invokes security mode at the network end of the connection. All further communications between the MME and the UE will be ciphered and integrity protected until such time as security mode is cancelled or the security vectors are refreshed. The UE refuses to implement security mode if the command received from the MME fails its integrity check or if the details contained in it are incorrect. In this case a SECURITY MODE REJECT message is returned to the MME. Further Reading: 3GPP TS24.301:5.4.3 and 8.2.20-22 and 33.401 (EPS AKA) LT3603/v1

© Wray Castle Limited

2.15

LTE Radio Access Network

EMM Common EP Identity Network Initiated UE

MME

IDENTITY REQUEST Start T3470

IDENTITY RESPONSE

Stop T3470

IDENTITY REQUEST

001 IMSI 010 IMEI 011 IMEISV 100 TMSI

Information Element

Required

Length

Protocol Discriminator

Mand

1/2

Security Header Type

Mand

1/2

Message Type

Mand

1

Identity Type

Mand

1/2

Spare

Mand

1/2

Identification

Identification The Identification procedure allows the MME to request IMSI, IMEI, IMEISV or TMSI details from a UE. The process is initiated with an IDENTITY REQUEST issued from the MME. Timer T3470 is started when the message is first transmitted. The Identity Type information element allows the UE to determine the type of information being requested. On receipt of the request, the UE encodes the required information into an IDENTITY RESPONSE message. The MME receives it and stops timer T3470. If the UE cannot transmit a response, possibly due to network failure or lack of coverage, it will perform a Tracking Update at the next opportunity. If timer T3470 expires before a response is received the message can be retransmitted a maximum of four further times. Other failure types, such as the collision of an IDENITY REQUEST with an ATTACH REQUEST issued by the UE will generally result in the UE being detached and forced to reattach to the network.

Further Reading: 3GPP TS24.301:5.4.4, and 8.2.18/19 and 24.008:10.5.5.9 (Identity Type values) 2.16

© Wray Castle Limited

LT3603/v1

Non-Access Stratum Processes

EMM Common EP EMM Information Network Initiated UE

MME

EMM INFORMATION

EMM INFORMATION Information Element

Required

Length

Protocol Discriminator

Mand

1/2

Security Header Type

Mand

1/2

Message Type

Mand

1

Full Network Name

Opt

3-n

Short Network Name

Opt

3-n

Local Timezone

Opt

2

Universal Time and local timezone

Opt

8

Daylight Saving Time

Opt

3

EMM Information

EMM Information EMM Information is an optional message type which is designed to allow the network to ‘provide information to the UE’. The types of information that can be carried in EMM Information messages currently include: ƒ full name for network ƒ short name for network ƒ local time zone ƒ universal time and local time zone ƒ network daylight saving time An EMM INFORMATION message is issued by the MME, there is no corresponding response message from the UE for messages successfully received. Support for the EMM Information message type is optional for UEs. A non-supporting UE that receives such a message responds with an EMM STATUS message indicating ‘message type nonexistent or not implemented’.

Further Reading: 3GPP TS24.301:5.4.5 and 8.2.13 LT3603/v1

© Wray Castle Limited

2.17

LTE Radio Access Network

EMM EP CS Service Notification Network Initiated UE

MME

CS SERVICE NOTIFICATION

CS SERVICE NOTIFICATION Information Element

Required

Length

Protocol Discriminator

Mand

1/2

Security Header Type

Mand

1/2 1

Message Type

Mand

Paging ID Type

Mand

1

Calling Line ID

Opt

3-14

Supplementary Services Code

Opt

2

LCS Indicator

Opt

2

LCS Client ID

Opt

3-257

0 IMSI 1 TMSI

CS Service Notification

CS Service Notification The CS Notification message is used to alert a UE that is Combined Attached to the EPS and to a CS-capable non-EPS network that an inbound call is waiting for it in the CS domain. The relevant 3GPP specification does not make it clear which, if any, NAS EMM message category this message type belongs to, it is simply shown as grouped with the other EMM-related procedures. This message type is only used to alert a UE that is in ECM-CONNECTED mode and which already has an active NAS signalling connection; notification of UEs in Idle Mode is handled by the Paging process. The message must contain a Paging Identity related to the CS domain that issued the page; this will take the form of either an IMSI or a TMSI. If the EPC connects to a peer CS domain node via an SGs interface the message may optionally also contain one or more additional fields, including details of the calling party’s CLI, details of any Supplementary Services invoked for the call and also details of any Location-based Service (LCS) identifiers related to the call.

Further Reading: 3GPP TS24.301:8.2.9 2.18

© Wray Castle Limited

LT3603/v1

Non-Access Stratum Processes

EMM Specific Elementary Procedures 0 0 0 0 0 0 0 0 0 0

1 1 1 1 1 1 1 1 1 1

0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 1 1 1 1

0 0 0 1 1 1 0 0 0 0

0 1 1 0 0 1 0 0 1 1

1 0 1 0 1 0 0 1 0 1

Attach Request Attach Accept Attach Complete Attach Reject Detach Request Detach Accept TAU Request TAU Accept TAU Complete TAU Reject

Mix of UE and network-initiated

EMM Specific Procedures

EMM Specific Procedures EMM Specific procedures handle Attach, Detach and TAU functions; some procedures can only be performed by the UE, others can be performed by the UE or the network. UEs are able to use EMM Specific messages to initiate Attach and Combined Attach (to an MME and an SGSN simultaneously, for example) to EPS and non-EPS networks. There are also message types that allow UEs in S1 mode to perform Tracking Area Updates (of normal, combined and periodic types). UEs have the option of piggybacking resource reservation requests onto TAU messages if necessary, which can help to reduce the overall number of individual signalling transactions required. The network or the UE can use EMM Specific messages to perform Detach or Combined Detach functions. Only one EMM Specific procedure can be in progress per UE at any one time.

Further Reading: 3GPP TS24.301:5.5 LT3603/v1

© Wray Castle Limited

2.19

LTE Radio Access Network

EMM Specific EP Attach UE Initiated

ATTACH REQUEST

Start T3410

Stop T3410

ATTACH ACCEPT

MME optionally invokes EMM Common procedures e.g. Authentication

UE

MME

ATTACH COMPLETE

Start T3450

Stop T3450

OR Start T3410

Stop T3410

ATTACH REQUEST

ATTACH REJECT

MME optionally invokes EMM Common procedures e.g. Authentication

Attach

Attach The EPS Attach procedure is UE initiated and allows a UE to register with an EPC ready to receive packet data services; it is substantially the same as the Attach procedure employed in legacy 3GPP networks. The main difference with the EPS Attach however is the automatic establishment of at least one Default Bearer (and possibly other Default and dedicated Bearers) as a consequence of a successful Attach. In the most common scenario a UE will initiate an Attach after being powered on or after returning to network coverage, in which case it will be starting the process from the EMM-DEREGISTERED state. The UE initiates the Attach by transmitting an ATTACH REQUEST to the MME and starting timer T3410. The ATTACH REQUEST message must contain either an ‘old’ GUTI, for a UE that has recently been Attached to the requested network, or an IMSI to identify the subscriber. The ESM Message Container field of the ATTCH REQUEST will include a PDN Connectivity Request, which initiates the establishment of a Default Bearer. On receipt of the ATTACH REQUEST the MME may decide to invoke EMM Common Procedures, such as Authentication or Security Mode Control, depending upon the information received from the UE. If the Attach is accepted the MME responds to the UE with ATTACH ACCEPT and starts timer T3450. The ACCEPT message contains a valid TAI List and an ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message encapsulated in the ESM Message Container field, it may also contain a new GUTI and values for various timers and other parameters. The network’s default value for timer T3412, which controls the periodic TAU process, is also included in the MME’s response.

Further Reading: 3GPP TS24.301:5.5.1 and 8.2.1-4 2.20

© Wray Castle Limited

LT3603/v1

Non-Access Stratum Processes

EMM Specific EP Attach UE Initiated

ATTACH REQUEST Information Element

Required

Length

Protocol Discriminator

Mand

1/2

Security Header Type

Mand

1/2

Message Type

Mand

1

EPS Attach Type

Mand

1/2

NAS Key Set Identifier

Mand

1/2

Old GUTI or IMSI

Mand

5-12

UE Network Capability

Mand

3-14

ESM Message Container

Mand

2-n

Old P-TMSI Signature

Opt

4

Additional GUTI

Opt

13

Last Visited Regsitered TAI

Opt

6

DRX Parameter

Opt

3

MS Network Capability

Opt

4-10

Old LAI

Opt

6 1

TMSI Status

Opt

MS Classmark 2

Opt

5

MS Classmark 3

Opt

2-34

Supported Codecs

Opt

5-n

Additional Update Type

Opt

1

Attach (continued)

Attach (continued) The UE stops timer T3410, processes the ACCEPT message and passes the contents of the ESM Message Container to the Connection Management layer, which activates the indicated Default EPS Bearer and any additional bearers. Once the Default EPS Bearer context is in place, the UE responds with ATTACH COMPLETE, which also encapsulates an ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT to confirm that the bearer context has been successfully created. If the Attach is not accepted, possibly because the UE failed to complete one or more of the Common Procedures, the MME responds with ATTACH REJECT, which includes a rejection cause code. If the UE fails to receive a response to the initial ATTACH REQUEST before timer T3410 expires it aborts the Attach process. In both of the failure cases mentioned above the UE increments its Attach Attempt Counter by 1; certain reject cause codes instruct the UE to increment the counter straight to 5 and may also be instructed to add the current TA or PLMN to its ‘forbidden’ lists. If the counter value is less than 5 the UE reattempts the Attach, if the counter reaches 5 the UE returns to Cell Search or even PLMN Search mode and begins the process from the start. The Attach Attempt Counter is reset to zero after a successful Attach.

Further Reading: 3GPP TS24.301:5.5.1 and :8.2.1-4 LT3603/v1

© Wray Castle Limited

2.21

LTE Radio Access Network

EMM Specific EP Attach UE Initiated

001 EPS Attach 010 Combined EPS/IMSI Attach

Additional optional data for Combined Attach

ATTACH REQUEST Information Element

Required

Length

Protocol Discriminator

Mand

1/2

Security Header Type

Mand

1/2

Message Type

Mand

1

EPS Attach Type

Mand

1/2

NAS Key Set Identifier

Mand

1/2

Old GUTI or IMSI

Mand

5-12

UE Network Capability

Mand

3-14

ESM Message Container

Mand

2-n

Old P-TMSI Signature

Opt

4

Additional GUTI

Opt

13

Last Visited Regsitered TAI

Opt

6

DRX Parameter

Opt

3

MS Network Capability

Opt

4-10

Old LAI

Opt

6 1

TMSI Status

Opt

MS Classmark 2

Opt

5

MS Classmark 3

Opt

2-34

Supported Codecs

Opt

5-n

Additional Update Type

Opt

1

Combined Attach

Combined Attach A Combined Attach allows a UE to register for both EPS and non-EPS services simultaneously. This would be desirable for UEs operating in CS/PS Modes 1 or 2 that wish to receive both EPS packet data services and Circuit Switched services from a legacy CS network type such as GSM or UMTS; UEs registered for CS Fallback voice and SMS services would require a Combined Attach, for example. The Combined Attach process is substantially the same as that followed for an EPS-only Attach, however additional functions are performed by the MME and additional information is required in the ATTACH REQUEST and ATTACH ACCEPT messages. A UE signals its requirement for a Combined Attach in the EPS Attach Type field of the ATTACH REQUEST – code 001 indicates EPS Attach, 010 indicates Combined EPS/IMSI Attach. The same codes are used to indicate the EPS Attach Result in ATTACH ACCEPT messages. The ATTACH ACCEPT message may also carry the LAI (Location Area Identifier) related to the UE’s current location in the non-EPS network. Other optional values can be used to specify the set of available or preferred services offered by the non-EPS network such as ‘SMS Only’ or ‘CS Fallback not preferred’. LTE supports a function known as ISR (Idle Mode Signalling Reduction), which allows UEs attached to more than one access network type (EPS, UMTS, GSM) to move freely between available RATs without necessarily performing location or tracking updates after each reselection. A Combined Attach is a prerequisite for this mode of operation.

Further Reading: 3GPP TS24.301:5.5.1 and 23.401:Annex J (ISR) 2.22

© Wray Castle Limited

LT3603/v1

Non-Access Stratum Processes

EMM Specific EP Detach UE or Network Initiated UE

Start T3421 Stop T3421

MME

DETACH REQUEST DETACH ACCEPT OR for Cause Code ‘Switch Off’

DETACH REQUEST

DETACH REQUEST

001 EPS Detach 010 IMSI Detach 011 Combined EPS/IMSI Detach

Information Element

Required

Length

Protocol Discriminator

Mand

1/2

Security Header Type

Mand

1/2

Message Type

Mand

1 1/2

Detach Type

Mand

NAS Key Set Identifier

Mand

1/2

GUTI or IMSI

Mand

5-12

Detach

Detach The Detach procedure can be initiated by either the UE or the network. There are three distinct scenarios in which a Detach would be initiated: ƒ by a UE or the network to Detach from EPS services only (Explicitly or Implicitly) ƒ by a UE in combined CS/PS Mode or the network to Detach from both EPS and non-EPS services or from non-EPS services only ƒ by a UE or the network to Detach from the last PDN the UE is connected to (the Detach being required as this would release the UE’s last Default Bearer) Following a Detach the UE may store the current GUTI, TAI List and last used PDN details for future re-Attach purposes. Any Default or Dedicated Bearers associated with the UE will be deactivated as part of the Detach process. UE-initiated Detach is triggered when the UE issues a DETACH REQUEST to the MME. The Detach Type field indicates both the type of Detach (EPS, IMSI or combined) and also the reason (normal or switch off). If the Detach is for ‘normal’ rather than ‘switch off’ reasons the UE starts timer T3421 when it transmits the DETACH REQUEST. Upon receipt of a DETACH REQUEST the MME performs the required functions to change the UE’s EMM and ECM states. If the UE has a Combined Attach, the MME may also be required to pass the Detach indication on to its peer non-EPS network node to enable an IMSI Detach to also take place. If the Detach cause was not ‘switch off’, the MME returns a DETACH ACCEPT message to the UE, which stops timer T3412 and moves to the EMM-DEREGISTERED state. If the Detach cause was ‘switch off’ the MME is not required to respond to the UE.

Further Reading: 3GPP TS24.301:5.5.2 and 8.2.10/11 LT3603/v1

© Wray Castle Limited

2.23

LTE Radio Access Network

EMM Specific EP Detach UE or Network Initiated UE

MME

DETACH REQUEST

Start T3422

DETACH ACCEPT

Stop T3422

DETACH REQUEST

001 Re-Attach Required 010 Re-Attach Not Required 011 IMSI Detach

Information Element

Required

Length

Protocol Discriminator

Mand

1/2

Security Header Type

Mand

1/2

Message Type

Mand

1 1/2

Detach Type

Mand

NAS Key Set Identifier

Mand

1/2

GUTI or IMSI

Mand

5-12

Network-initiated Detach

Network-initiated Detach Network-initiated Detach messages operate in the reverse direction and are employed for explicit detach functions only as no S1 NAS messages are sent for implicit detaches. The network may elect to implicitly Detach a UE after it fails to perform an expected Periodic TAU; for UEs that have maintained contact with the MME there are numerous reasons for triggering an explicit detach, including: ƒ IMSI unknown in HSS ƒ EPS services not allowed ƒ PLMN, Tracking Area or Roaming not allowed ƒ No suitable cells in Tracking Area UEs may also be instructed to Detach for administrative reasons, such as when its serving MME declares an overload state. The MME in this case would issue DETACH REQUEST messages to a set of UEs. The Detach Type field in DETACH REQUEST messages travelling in the ‘network to UE’ direction indicates whether a re-attach is required or not. In the case of a detach triggered by network failure or MME overload, the Type field will instruct the UE to re-attach. The subsequent ATTACH REQUEST will be passed by the serving eNB to an MME that is not in the overload state. Network-initiated Detach is controlled by timer T3422 in the MME, which starts when the DETACH REQUEST is issued. If the timer expires before the UE has responded the message can be retransmitted. If after a maximum of four retransmission the UE still has not responded, the MME implicitly detaches it by changing its stored state to EMM-DEREGISTERED. Further Reading: 3GPP TS24.301:5.5.2 and 8.2.10/11 2.24

© Wray Castle Limited

LT3603/v1

Non-Access Stratum Processes

EMM Specific EP Tracking Area Update UE Initiated

TRACKING AREA UPDATE REQUEST

Start T3430

Stop T3430 If GUTI allocated

MME optionally invokes EMM Common procedures e.g. Authentication TRACKING AREA UPDATE ACCEPT UE

MME

TRACKING AREA UPDATE COMPLETE

If GUTI allocated start T3450 Stop T3450

OR Start T3430

TRACKING AREA UPDATE REQUEST MME optionally invokes EMM Common procedures e.g. Authentication

Stop T3430

TRACKING AREA UPDATE REJECT

Tracking Area Update (TAU)

Tracking Area Update (TAU) Process The TAU process is initiated by the UE in the EMM-REGISTERED state and is applicable only to UEs in S1 Mode. A TAU is initiated when an Idle Mode UE roams into a TA which is not a member of its current TAI List; after a UE has performed an inter-system reselection from a different RAT to an EUTRAN cell; periodically on the expiry of timer T3412; for administrative reasons such as MME Load Balancing or for a number of error response reasons. When a UE recognises a trigger condition for TAU it issues a TRACKING AREA UPDATE REQUEST message to the MME and starts timer T3430. The message contains the UE’s current GUTI plus details of the EPS Update Type – this field indicates whether the messages carries TA Update, a combined TA/LA Update or whether it was triggered as a Periodic Update. The Request may also contain the UE’s current or last registered TAI plus a number of other optional elements and will be Integrity Protected using the current Security Context.

Further Reading: 3GPP TS24.301:5.5.3 and 8.2.26-29 LT3603/v1

© Wray Castle Limited

2.25

LTE Radio Access Network

EMM Specific EP Tracking Area Update UE Initiated

TRACKING AREA UPDATE REQUEST Information Element

Required

Length

Protocol Discriminator

Mand

1/2

Security Header Type

Mand

1/2

Message Type

Mand

1

EPS Update Type

Mand

1/2

NAS Key Set Identifier

Mand

1/2

Old GUTI

Mand

12

Plus 17 optional parameters

TAU (continued)

TAU Message If the MME accepts the TAU it returns a TRACKING AREA UPDATE ACCEPT message to the UE. Not all TAU operations result in GUTI reallocation, but if a new GUTI is generated as a result of the TAU then the MME will expect confirmation from the UE; it starts timer T3450 to manage this process. A TRACKING AREA UPDATE ACCEPT message will contain an EPS Update Result field that indicates the actions performed by the MME (values include TA Update, Combined TA/LA Update and TA or Combined Updates with ISR Activated) and may optionally contain a new GUTI, a new or updated TAI List, a new T3412 value and a host of other information types. If the UE receives the TRACKING AREA UPDATE ACCEPT correctly it stops timer T3430 and processes the contents of the message. If a new GUTI was allocated the UE responds with a TRACKING AREA UPDATE COMPLETE message, which in turn stops timer T3450 in the MME. The MME may reject a TAU if, for example, the UE had been previously implicitly detached or if roaming in the new TA is not allowed for that UE. In such cases the MME returns a TRACKING AREA UPDATE REJECT message, which causes the UE to enter cell or PLMN search mode.

Further Reading: 3GPP TS24.301:5.5.3 and 8.2.26-29 2.26

© Wray Castle Limited

LT3603/v1

Non-Access Stratum Processes

EMM Connection Management Elementary Procedures 0 0 0 0

1 1 1 1

0 0 1 1

0 0 0 0

1 1 0 0

1 1 0 0

0 1 1 1

0 0 0 1

Extended Service Request Service Request Downlink NAS Transport Uplink NAS Transport Paging (via S1AP)

Mix of UE and network-initiated

EMM Connection Management Messages

EMM Connection Management Messages EMM Connection Management messages are used to signal the requirement to establish or activate EPS Bearer resources. Once a Default Bearer has been created for a UE during the Attach process, all subsequent EPS Bearer connections are established based on resource requests made by UE. If a UE requests resources that are incompatible with the existing set of bearers or are only available via a different PDN-GW then the network can decide to assign additional PCS or Bearer resources, but the initial impetus for the change comes from the UE, there is no mechanism that allows the MME to request the establishment or reactivation of a bearer. The network can, however, page the UE and cause it to request the establishment or reactivation of a bearer. The two main EMM Connection Management processes are therefore SERVICE REQUEST/EXTENDED SERVICE REQUEST from the UE and PAGING from the network. This class of Elementary Procedure also includes the capability to transport NAS messages that encapsulate SMS traffic between the UE and the MME.

Further Reading: 3GPP TS24.301:5.6 LT3603/v1

© Wray Castle Limited

2.27

LTE Radio Access Network

MME

EMM/ECM State information stored

EMM/ECM State information stored NAS connection only required for TAU S11 S5 Tunnel

EPS Bearer Context Stored

S-GW

EPS Bearer Context Stored

Service Request and Extended Service Request

Service Request and Extended Service Request The Service Request process allows a UE to signal its requirement to move from ECM-IDLE to ECMCONNECTED so that data can be transferred over an EPS Bearer. EPS-Attached UEs are allocated a Default Bearer when they first register and may be allocated further Default or Dedicated Bearers over time as the nature and number of connections and services they consume changes. When an EMM-REGISTERED UE drops into Idle Mode (ECM-IDLE state) any bearers allocated to it, including the Default Bearer, will be placed into an inactive state. This means that the Bearer Contexts are stored in the UE, the MME and the S-GW but that no air interface or S1 resources are assigned to carry traffic. In response to pending uplink data, a user request or a page from the network, the UE can issue a SERVICE REQUEST to the MME which will result in the stored Bearer Contexts being reactivated. Further signalling messages requesting the assignment of new bearer resources can be transmitted once the Default Bearer has been reactivated. The EXTENDED SERVICE REQUEST is used only by the CS Fallback function and is used to indicate that a handover to CS resources is required to allow a Mobile-Originated or a MobileTerminated CS Fallback session to take place.

Further Reading: 3GPP TS24.301:5.6.1 and 8.2.24/25 2.28

© Wray Castle Limited

LT3603/v1

Non-Access Stratum Processes

EMM Connection Management EP Extended/Service Request UE Initiated UE

MME

SERVICE REQUEST

Start T3417

AS indication re bearer establishment

Stop T3417

OR

SERVICE REQUEST Start T3417

SERVICE REJECT

Stop T3417

This process is essentially the same for EXTENDED SERVICE REQUEST messages

SERVICE REQUEST

EXTENDED SERVICE REQUEST

Information Element

Required

Length

Information Element

Required

Length

Protocol Discriminator

Mand

1/2

Protocol Discriminator

Mand

1/2

Security Header Type

Mand

1/2

Security Header Type

Mand

1/2

KSI and Sequence Number

Mand

1

Message Type

Mand

1

Message Authentication Code

Mand

2

Service Type

Mand

1/2

NAS Key Set Identifier

Mand

1/2

M-TMSI

Mand

6

CSFB Response

Opt

1

Service Request Process

Service Request Process When a UE requires bearer reactivation it issues a SERVICE REQUEST, which contains details of the current Key Set Identifier in use by the UE and MAC (Message Authentication Code) code to provide integrity protection; no additional information is contained in the SERVICE REQUEST, its meaning is limited ‘reactivate my bearers’. The UE starts timer T3417 on transmission of the message. The MME processes the request and changes the stored state of the UE to ECM-CONNECTED, it then signals to the Access Stratum (e.g. the S-GW) that the inactivate UE’s Bearer Contexts should be reactivated. The MME sends no explicit response to the UE but rather assumes that the notification the UE receives from the Access Stratum regarding the reactivated bearers will act as an implicit indication of message acceptance. The UE stops timer T3417 when it receives notification of bearer reactivation from the AS. The MME may reject a SERVICE REQUEST for a number of reasons, including ‘TA/PLMN not allowed’, ‘no suitable cells’ or (in the case of the EXTENDED SERVICE REQUEST) ‘CS domain not available’. In these circumstances the MME will explicitly respond to the UE by issuing a SERVICE REJECT message which details the reason for the rejection. The EXTENDED SERVICE REQUEST message contains additional fields which specify the required CS Fallback Service Type and also shows the subscriber’s current M-TMSI. The process associated with this message type results in an inter-system handover to a CS-capable cell to allow the UE to engage in a CS session (e.g. a standard telephone call).

Further Reading: 3GPP TS24.301:5.6.1 and 8.2.25 LT3603/v1

© Wray Castle Limited

2.29

LTE Radio Access Network

EMM Connection Management Paging (via S1AP) Network Initiated

eNB

NAS

UE

PAGING (S1AP) PAGING (LTE-Uu)

S1AP

SERVICE REQUEST

MME

Start T3413

Stop T3413

Paging

Paging The Paging process allows the MME to contact Idle Mode UEs to require them to establish a NAS signalling connection. Paging is usually performed to alert a UE to a waiting inbound session or of stored downlink data but it can also be used in certain error recovery situations to require a UE to reattach to the network. Unlike other NAS message flows the PAGING message does not travel directly between the MME and the UE, it is instead an instruction issued by the MME to one or more eNBs which then take the information provided and broadcast it across their paging channels. Although Paging is a NAS function, the PAGING message is actually an S1AP entity rather than a NAS entity. The S1AP PAGING message issued by the MME contains a UE Paging Identity, which will usually be the subscriber’s current S-TMSI but may in certain failure conditions be the IMSI instead. The PAGING message also contains the UE’s current TAI List to allow the eNB the opportunity to tailor the set of cells in which the page is propagated if necessary and optionally carries details the UE’s DRX cycle, so the eNB can determine the paging group to which it belongs. One further field is the CN Domain field which indicates the type of core network that initiated the page; EPS-initiated paging messages will indicate a PS core, whilst pages issued for CS Fallback purposes would indicate CS. The MME starts timer T3413 when it issues the page. The expected response from the paged UE in normal circumstances will be a SERVICE REQUEST, at which point the MME stops timer T3413. If the timer expires before a response to page has been received the network may invoke any ‘call forwarding unreachable’ settings configured for the subscriber.

Further Reading: 3GPP TS24.301:5.6.2 and 36.413:9.1.6 (S1AP Paging) 2.30

© Wray Castle Limited

LT3603/v1

Non-Access Stratum Processes

EMM Connection Management EP NAS Transport UE or Network Initiated MME

UE

UPLINK NAS TRANSPORT DOWNLINK NAS TRANSPORT

UPLINK/DOWNLINK NAS TRANSPORT Information Element

Required

Length

Protocol Discriminator

Mand

1/2

Security Header Type

Mand

1/2

Message Type

Mand

1

NAS Message Container

Mand

3-252

Transport of NAS Messages

Transport of NAS Messages The ‘transport of NAS messages’ function was developed to provide a means of transporting encapsulated SMS traffic between a UE and the MME and has both Uplink and Downlink message variants. The DOWNLINK NAS TRANSPORT and UPLINK NAS TRANSPORT message types only contain a Message Type identifier and the encapsulated SMS message and can therefore be considered to be transparent containers for that traffic type. Several methods exist by which SMS traffic can be delivered to LTE UEs and the use of the NAS Transport method is not necessarily guaranteed in all network configurations. In any event, delivery of traffic via this method is only possible for UEs in EMM-CONNECTED mode and so would require a Paging process to occur before a message could be delivered to an Idle Mode UE.

Further Reading: 3GPP TS24.301:5.6.3 and 8.2.12 & 30 LT3603/v1

© Wray Castle Limited

2.31

LTE Radio Access Network

EPS Session Management Elementary Procedures

UE initiated Transaction-related Procedures

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1

0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0

0 0 0 0 0 0 1 1 1 1 1 0 0 0 0 0 0 0 0 1 1 1

0 0 0 1 1 1 0 0 0 1 1 0 0 0 0 1 1 1 1 0 0 0

0 1 1 0 1 1 0 1 1 0 1 0 0 1 1 0 0 1 1 0 1 0

1 0 1 1 0 1 1 0 1 1 0 0 1 0 1 0 1 0 1 1 0 0

Activate Default EPS Bearer Context Request Activate Default EPS Bearer Context Accept Activate Default EPS Bearer Context Reject Activate Dedicated EPS Bearer Context Request Activate Dedicated EPS Bearer Context Accept Activate Dedicated EPS Bearer Context Reject Modify EPS Bearer Context Request Modify EPS Bearer Context Accept Modify EPS Bearer Context Reject Deactivate EPS Bearer Context Request Deactivate EPS Bearer Context Accept PDN Connectivity Request PDN Connectivity Reject PDN Disconnect Request PDN Disconnect Reject Bearer Resource Allocation Request Bearer Resource Allocation Reject Bearer Resource Modification Request Bearer Resource Modification Reject ESM Information Request ESM Information Response ESM Status

Network initiated EPS Bearer-related Procedures

Mix of UE and network-initiated

EPS Session Management (ESM) Messages

EPS Session Management (ESM) Messages The ECM state machine describes the overall connectedness of a EMM-REGISTERED UE; if the UE is Idle it is regarded as being in the ECM-IDLE state, if it has a NAS signalling connection established and one or more bearers active it is regarded as being in the ECM-CONNECTED state. The ECM state machine provides a high-level overview. Below the ECM level the ESM sublayer defines the state of individual bearers and provides processes to manage the creation and use of EPS Bearer Contexts and the allocation of resources to those bearers. ESM recognizes individual bearer contexts as being in either the BEARER CONTEXT ACTIVE or BEARER CONTEXT INACTIVE state and there are a number of substates designed to show when various actions are pending. ESM procedures are grouped into two main types: those that relate to EPS Bearer Contexts and those that relate to resource management transactions. If successful, a Transaction-related procedure (a bearer resource allocation request, for example) should result in an EPS Bearer Context-related procedure (e.g. an EPC Bearer Context modification) being performed. The UE views the start of an EPS Bearer Context-related procedure as the implicit conclusion of a Transaction-related procedure it initiated. There are also a set of Miscellaneous ECM procedures. ESM tracks the state of transactions using the PROCEDURE TRANSACTION INACTIVE and PROCEDURE TRANSACTION PENDING classifications. Each new Transaction initiated by the UE or network will be assigned a PTI (Procedure Transaction Identity) to allow messages relating to the same procedure to be identified and grouped.

Further Reading: 3GPP TS24.301:6 2.32

© Wray Castle Limited

LT3603/v1

Non-Access Stratum Processes

EPS Session Management EP Activate Default EPS Bearer Network Initiated

UE

ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT

MME

Start T3485 Stop T3485

OR

ACTIVATE DEFAULT EPS BEARER CONTEXT REJECT

Stop T3485

Default EPS Bearer Context Activation

Default EPS Bearer Context Activation A Default EPS Bearer must exist between the UE and each PDN to which it establishes a PDN Connectivity Service. In simple terms this means that each time a UE requests a service that requires a connection to a new PDN-GW, a new Default EPS Bearer to that PDN-GW is created to carry the PCS. UEs can run connections to multiple PCSs concurrently and can therefore have multiple Default EPS Bearers established. In general it may be seen as desirable to limit the number of PDN connections for each UE and most will usually only require one Default EPS Bearer to be established. The initial Default EPS Bearer is established automatically as part of the EPS Attach process and the bearer setup is initiated by the network. The establishment of any additional Default EPS Bearers is also initiated by the network but only in response to a Transaction-related PDN CONNECTIVITY REQUEST message from a UE. The procedure is similar for both scenarios. The MME initiates a Default Bearer creation process by issuing an ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST (usually encapsulated in an ATTACH ACCEPT message) towards the UE. Timer T3485 is only used for standalone Default Bearer activations which are not piggybacked onto an Attach process.

Further Reading: 3GPP TS24.301:6.4.1 and 8.3.6 LT3603/v1

© Wray Castle Limited

2.33

LTE Radio Access Network

EPS Session Management EP Activate Default EPS Bearer Network Initiated

ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST Information Element

Required

Length

Protocol Discriminator

Mand

1/2

EPS Bearer ID

Mand

1/2

Procedure Transaction ID

Mand

1

Message Type

Mand

1

EPS QoS

Mand

2-10

Access Point Name

Mand

2-101 6-14

PDN Address

Mand

Transaction Identifier

Opt

3-4

Negotiated QoS

Opt

14-18

Negotiated LLC SAPI

Opt

2

Radio Priority

Opt

1

Packet Flow ID

Opt

3 4-8

APN-AMBR

Opt

ESM Cause

Opt

2

Protocol Configuration Options

Opt

3-253

Default EPS Bearer Context Activation (continued)

Default EPS Bearer Context Activation Message The ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message will include an EPS Bearer ID for the new bearer and details of the APN to which it connects as well as details of the EPS Bearer QoS and the PDN Address (IP Address) assigned to the UE’s end of the bearer. For standalone transactions that were initiated by the UE, the message will also include the PTI of the original transaction request. If the UE can create the Bearer Context it returns an ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT (which may be encapsulated in an ATTACH COMPLETE message). If the bearer context cannot be created the UE responds with ACTIVATE DEFAULT EPS BEARER CONTEXT REJECT.

Further Reading: 3GPP TS24.301:6.4.1 and 8.3.6 2.34

© Wray Castle Limited

LT3603/v1

Non-Access Stratum Processes

EPS Session Management EP Activate Dedicated EPS Bearer Network Initiated UE

ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST ACTIVATE DEDICATED EPS BEARER CONTEXT ACCEPT

MME

Start T3485 Stop T3485

OR

ACTIVATE DEDICATED EPS BEARER CONTEXT REJECT

Stop T3485

ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST Information Element

Required

Length

Protocol Discriminator

Mand

1/2

EPS Bearer ID

Mand

1/2

Procedure Transaction ID

Mand

1

Message Type

Mand

1

Linked EPS Bearer ID & Spare ½

Mand

1

EPS QoS

Mand

2-10

TFT

Mand

2-256

Transaction Identifier

Opt

3-4

Negotiated QoS

Opt

14-18

Negotiated LLC SAPI

Opt

2

Radio Priority

Opt

1

Packet Flow ID

Opt

3

Protocol Configuration Options

Opt

3-253

Dedicated EPS Bearer Context Activation

Dedicated EPS Bearer Context Activation A Dedicated EPS Bearer is generally only required if a traffic connection requested by the UE has QoS or TFT (Traffic Flow Template) requirements that are incompatible with those that exist on the Default EPS Bearer. A Dedicated Bearer may be created in a standalone process or be created along with a Default Bearer as part of the Attach or PDN Connectivity processes. In a standalone process the Dedicated Bearer would be created in response to a bearer resource allocation or modification request issued by a UE. This would not specifically request a new bearer; the decision to establish a new Dedicated Bearer would be made by the network (PDN-GW and PCRF) after determining that the required or requested bearer parameters would not be compatible with existing bearers. Once the decision to establish a new Dedicated EPS Bearer has been made, the process followed to activate it is essentially the same as that employed for Default EPS Bearers. The MME issues an ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST towards the target UE and starts timer T3485. As with the Default Bearer establishment message, the Dedicated Bearer message contains the new bearer’s EPS Bearer ID and also the PTI of the original request issued by the UE to allow it link the bearer to that transaction. Unlike a Default EPS Bearer, which is established with no TFT and minimal QoS, a Dedicated EPS Bearer requires specific QoS and TFT values to be defined; the activation request therefore contains details of the Uplink versions of these parameters. The Dedicated EPS Bearer Activation request must also contain a Linked EPS Bearer Identity to indicate the new connection’s parent Default Bearer. As with the Default Bearer process, if the UE is able to create the new Context it responds with an ACTIVATE DEDICATED EPS BEARER CONTEXT ACCEPT, if not it issues an ACTIVATE DEDICATED EPS BEARER CONTEXT REJECT. In common with most NAS functions, expiry of T3485 will lead to a maximum of four retries before the procedure is aborted.

Further Reading: 3GPP TS24.301:6.4.2 and 8.3.1-3 LT3603/v1

© Wray Castle Limited

2.35

LTE Radio Access Network

EPS Session Management EP Modify EPS Bearer Network Initiated UE

MODIFY EPS BEARER CONTEXT REQUEST MODIFY EPS BEARER CONTEXT ACCEPT

MME

Start T3486 Stop T3486

OR

MODIFY EPS BEARER CONTEXT REJECT

Stop T3486

MODIFY EPS BEARER CONTEXT REQUEST Information Element

Required

Length

Protocol Discriminator

Mand

1/2

EPS Bearer ID

Mand

1/2

Procedure Transaction ID

Mand

1

Message Type

Mand

1

New EPS QoS

Opt

3-11

TFT

Opt

3-257

New QoS

Opt

14-18

Negotiated LLC SAPI

Opt

2 1

Radio Priority

Opt

Packet Flow ID

Opt

3

APN-AMBR

Opt

4-8

Protocol Configuration Options

Opt

3-253

EPS Bearer Context Modification

EPS Bearer Context Modification EPS Bearer Context Modification is used to modify the parameters (QoS or TFT) of an existing bearer. It is initiated by the network but this may be in response to a bearer resource allocation or modification request issued by the UE. The procedure begins with the MME changing the bearer’s ESM state to BEARER CONTEXT MODIFY PENDING, issuing a MODIFY EPS BEARER CONTEXT REQUEST towards the UE and starting timer T3486. The Request message contains the EPS Bearer ID of the connection be modified and the PTI of the transaction. It may also optionally contain new QoS, TFT and other values. If the modification was triggered by a change in the AMBR (Aggregate Maximum Bit Rate) applicable for the APN to which the bearer is connected then the message will specify the new APNAMBR. If the UE is able to implement the bearer modification it returns a MODIFY EPS BEARER CONTEXT ACCEPT to the MME, which stops timer T3486 and sets the bearer context ESM state to BEARER CONTEXT ACTIVE. The UE may not be able to implement the request for a number for reasons, including: invalid EBI; semantic or syntactical errors in modified TFT or insufficient resources. If the bearer modification cannot be implemented, the UE returns MODIFY EPS BEARER CONTEXT REJECT. If T3486 expires the MME has a maximum for four retries before it must abort the procedure and reactivate the bearer with the original parameters.

Further Reading: 3GPP TS24.301:6.4.3 and 8.3.16-18 2.36

© Wray Castle Limited

LT3603/v1

Non-Access Stratum Processes

EPS Session Management EP Deactivate EPS Bearer Network Initiated

UE

DEACTIVATE EPS BEARER CONTEXT REQUEST DEACTIVATE EPS BEARER CONTEXT ACCEPT

MME

Start T3495 Stop T3495

DEACTIVATE EPS BEARER CONTEXT REQUEST Information Element

Required

Length

Protocol Discriminator

Mand

1/2

EPS Bearer ID

Mand

1/2

Procedure Transaction ID

Mand

1

Message Type

Mand

1

ESM Cause

Opt

1

Protocol Configuration Options

Opt

3-253

EPS Bearer Context Deactivation

EPS Bearer Context Deactivation The EPS Bearer Context Deactivation procedure can be used to disconnect an individual EPS Bearer or to disconnect all of a UE’s EPS Bearers connected to a particular PDN. It is a network-initiated process but may be undertaken in response to a request issued by a UE. If the MME intends to deactivate an individual bearer it includes that bearer’s EBI in the request; if it requires that all bearers connected between the UE and a particular PDN are deactivated then it uses the EBI of the PDN’s Default EPS Bearer in the request, as a PCS cannot operate without a default bearer this has the effect of also deactivating any linked Dedicated Bearers. If the request was issued in response to a UE-initiated deactivation transaction then the message will also contain the PTI of the original transaction. The MME initiates a bearer deactivation by transmitting a DEACTIVATE EPS BEARER CONTEXT REQUEST to the UE and starting timer T3495. The reason for the deactivation will be signalled in the message’s ESM Cause field and will generally take the value ‘regular deactivation’ unless a fault has occurred. Upon receipt of a DEACTIVATE EPS BEARER CONTEXT REQUEST the UE will delete the specified context (or contexts in the case that connectivity to a whole PDN is being deactivated). If a PTI was included in the request then the UE accepts it as confirmation that the linked transaction has been actioned. The UE returns a DEACTIVATE EPS BEARER CONTEXT ACCEPT to the MME, which stops timer T3495. There is no ‘reject’ message related to this procedure and therefore no opportunity for the UE to refuse to comply with the request. If timer T3495 expires, the MME can retry a maximum of four times; if the UE has not Accepted the deactivation command after five attempts the MME deletes the Bearer Context(s) locally without further reference to the UE. Local deactivation of bearer contexts by the MME is also an option in the event of no NAS connection being available to the UE when the procedure is initiated.

Further Reading: 3GPP TS24.301:6.4.4 and 8.3.11/12 LT3603/v1

© Wray Castle Limited

2.37

LTE Radio Access Network

EPS Session Management EP PDN Connectivity UE Initiated

Start T3482

PDN CONNECTIVITY REQUEST

UE

Stop T3482

MME

ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST OR

Stop T3482

PDN CONNECTIVITY REJECT

PDN CONNECTIVITY REQUEST

001 Initial Request 010 Handover

Information Element

Required

Length

Protocol Discriminator

Mand

1/2

EPS Bearer ID

Mand

1/2

Procedure Transaction ID

Mand

1

Message Type

Mand

1

Request Type

Mand

1/2

PDN Type

Mand

1/2

ESM Information Transfer Flag

Opt

1

Access Point Name

Opt

3-102

Protocol Configuration Options

Opt

3-253

001 IPv4 010 IPv6 011 IPv4v6

PDN Connectivity

PDN Connectivity The UE requested PDN Connectivity procedure allows a UE to implicitly request the activation of a Default EPS Bearer to a PDN (via a PDN-GW) by explicitly requesting the creation of a PCS (PDN Connectivity Service) to that PDN. This process can be bundled with the Attach procedure to create the initial Default EPS Bearer or can be initiated in a standalone fashion to create a connection to an additional PCS. The UE initiates the process by sending a PDN CONNECTIVITY REQUEST to the MME and starting timer T3482. Timer expiry can be followed by four retries before the procedure is aborted. If the Request is to be encapsulated in an ATTACH REQUEST the UE is not required to include a requested APN; if the procedure is initiated to establish an additional PCS then the UE may elect to include an APN in the request. The message will also include an EBI, a PTI, the Request Type and the PDN Type (IPv4, IPv6 or IPv4v6 depending on the capabilities of the UE’s IP protocol stack); it may also include optional elements such as an APN and any additional external protocol (such as PPP or a PDP Context) configuration options. The Request Type field has two valid values; an ‘initial’ value is used when the UE is requesting the establishment of a new PCS and the ‘handover’ value is used to signal a that a PCS is required so that an existing non-EPS connection can be handed over to the EPS. There is no explicit response for a successful PDN Connectivity request, the UE will instead receive implicit confirmation in the form of an ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST from the MME with a PTI that ties it to the original request. The UE will then stop T3482 and begin creating the signalled Bearer Context. If the requested PCS cannot be established by the network the UE will receive a PDN CONNECTIVITY REJECT message containing an ESM Cause field detailing the reason for the rejection.

Further Reading: 3GPP TS24.301:6.5.1 and 8.3.20 2.38

© Wray Castle Limited

LT3603/v1

Non-Access Stratum Processes

EPS Session Management EP PDN Disconnect UE Initiated

Start T3492

UE

Stop T3492

PDN DISCONNECT REQUEST

MME

DEACTIVATE EPS BEARER CONTEXT REQUEST OR

Stop T3492

PDN DISCONNECT REJECT

PDN DISCONNECT REQUEST Information Element

Required

Length

Protocol Discriminator

Mand

1/2

EPS Bearer ID

Mand

1/2

Procedure Transaction ID

Mand

1

Message Type

Mand

1

Linked EPS Bearer ID

Mand

1/2

Spare ½ Octet

Mand

1/2

Protocol Configuration Options

Opt

3-253

PDN Disconnect

PDN Disconnect The PDN Disconnect procedure allows a UE to request the release of all active connections to a particular PDN; this is only allowed if the UE has more than one active PCS. If the UE has only one active PCS that it wishes to release it would instead invoke the Detach process. To initiate the PDN Disconnect procedure the UE issue a PDN DISCONNECT REQUEST towards the MME and starts timer T3492. The request contains the EBI of the Bearer to which the message relates plus a transaction identifying PTI. It also contains a Linked Bearer ID, which specifies the EBI of the Default EPS Bearer for the PCS to be disconnected, and an optional field that allows protocol configuration options for external network protocols to be flagged. As with other ECM procedures, there is no explicit confirmatory response to this request, the MME instead implicitly responds with a DEACTIVATE EPS BEARER CONTEXT REQUEST deactivating the Default EPS Bearer leading to the selected PCS and echoing back the PTI of the original request. If the request cannot be actioned the MME will respond explicitly with a PDN DISCONNECT REJECT containing the appropriate ESM cause code. If timer T3492 expires before a response (explicit or otherwise) is received, the UE may retry up to four times before aborting the procedure.

Further Reading: 3GPP TS24.301:6.5.2 and 8.3.22 LT3603/v1

© Wray Castle Limited

2.39

LTE Radio Access Network

EPS Session Management EP Bearer Resource Allocation UE Initiated

Start T3480 Stop T3480

UE

BEARER RESOURCE ALLOCATION REQUEST

MME

ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST OR

Stop T3480

MODIFY EPS BEARER CONTEXT REQUEST OR

Stop T3480

BEARER RESOURCE ALLOCATION REJECT BEARER RESOURCE ALLOCATION REQUEST Information Element

Required

Length

Protocol Discriminator

Mand

1/2

EPS Bearer ID

Mand

1/2

Procedure Transaction ID

Mand

1

Message Type

Mand

1

Linked EPS Bearer ID

Mand

1/2

Spare ½ Octet

Mand

1/2

Traffic Flow Aggregate

Mand

2-256

Required Traffic Flow QoS

Mand

2-10

Protocol Configuration Options

Opt

3-253

Bearer Resource Allocation

Bearer Resource Allocation EPS-Attached UEs have no mechanism that allows them to explicitly request the establishment of an EPS Bearer; in fact, the UE is not even equipped to make the decision that a new bearer is actually required. Instead the UE has the ability to request that resources are assigned to carry a new traffic flow aggregate or that resources assigned to an existing traffic flow aggregate require modification. It is the network’s responsibility to decide how to handle such requests. If a UE requires resources to carry a new traffic flow aggregate – for example, if the user has initiated a new browser instance or if a connection to carry new voice call is needed – it will issue a BEARER RESOURCE ALLOCATION REQUEST towards the MME and start timer T3480. The request carries the EBI of the Default EPS Bearer of the affected required PCS and a transaction-related PTI value. The UE will also flag the required QoS and TFT attributes for the new flow and may optionally also include protocol configuration information for connections that involve external network protocols. The MME performs some basic checks on the received message – checking for example that the signalled Linked EPS Bearer ID relates to an active Default EPS Bearer – before passing the request on through the network. The network (in the form of the PDN-GW/PCRF) makes a resource allocation decision that will result in one of three responses being sent back to the UE. If the request is accepted and the network decides that a new EPS Bearer is required to carry it then the MME returns an ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST to the UE. If the request is accepted but the network decides that the new flow can travel in an existing bearer the MME issues a MODIFY EPS BEARER CONTEXT REQUEST to the UE. If the network decides that the request cannot be accepted the MME issues a BEARER RESOURCE ALLOCATION REJECT message to the UE containing an ESM Cause detailing the reasons for the rejection. Initial expiry of T3480 can lead to four retries before the transaction is aborted by the UE.

Further Reading: 3GPP TS24.301:6.5.3 and 8.3.8 2.40

© Wray Castle Limited

LT3603/v1

Non-Access Stratum Processes

EPS Session Management EP Bearer Resource Modification UE Initiated

Start T3481 Stop T3481

UE

BEARER RESOURCE MODIFICATION REQUEST

MME

ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST OR

Stop T3481

MODIFY EPS BEARER CONTEXT REQUEST OR

Stop T3481

DEACTIVATE EPS BEARER CONTEXT REQUEST OR

Stop T3481

BEARER RESOURCE MODIFICATION REJECT BEARER RESOURCE MODIFICATION REQUEST Information Element

Required

Length

Protocol Discriminator

Mand

1/2

EPS Bearer ID

Mand

1/2

Procedure Transaction ID

Mand

1

Message Type

Mand

1

Linked EPS Bearer ID

Mand

1/2

Spare ½ Octet

Mand

1/2

Traffic Flow Aggregate

Mand

2-256

Required Traffic Flow QoS

Mand

3-11

ESM Cause

Opt

2

Protocol Configuration Options

Opt

3-253

Bearer Resource Modification

Bearer Resource Modification If a UE requires alterations to the resource allocation for an existing traffic flow aggregate it signals the requirement using the Bearer Resource Modification procedure. Alteration to an existing resource allocation includes situations where the resource is no longer required, so this procedure handles both the modification and the release of flow resources. The UE initiates this transaction-related procedure by transmitting a BEARER RESOURCE MODIFICATION REQUEST to the network and starting timer T3481. The request contains similar information elements as are found in the Bearer Resource Allocation Request, including EBI and PTI values. If the request is intended to modify the resources for an ongoing traffic flow, the message will contain details of the updated QoS and TFT requirements; this will occur whether the request is being to increase or decrease the assigned resources. If the request is being made in order to release the resources assigned to a no-longer-needed traffic flow aggregate then the QoS will be set to zero values, the TFT operation code will be set to ‘Delete’ and an ESM Cause code will be included to indicate the reason for the release. The network, after considering the request, may respond in one of four ways: If the modified resource requirements are incompatible with the current EPS Bearer the network will issue an ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST and move the traffic flow aggregate to a new bearer If the modified resource requirements are compatible with the current bearer the network will issue a MODIFY EPS BEARER CONTEXT REQUEST. This will also be used to delete the resources from a Dedicated Bearer that will continue to be needed for other flows. If the request called for the release of traffic flow resources and the flow was the only one being carried by a Dedicated EPS Bearer then the network will issue a DEACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST If the request cannot be actioned, the MME will issue a BEARER RESOURCE MODIFICATION REJECT message containing the appropriate ESM Cause code Further Reading: 3GPP TS24.301:6.5.4 and 8.3.10 LT3603/v1

© Wray Castle Limited

2.41

LTE Radio Access Network

EPS Session Management EP ESM Information Network Initiated UE

MME

ESM INFORMATION REQUEST

Start T3489

ESM INFORMATION RESPONSE

ESM INFORMATION REQUEST

Stop T3489

ESM INFORMATION RESPONSE

Information Element

Required

Length

Information Element

Required

Length

Protocol Discriminator

Mand

1/2

Protocol Discriminator

Mand

1/2

EPS Bearer ID

Mand

1/2

EPS Bearer ID

Mand

1/2

Procedure Transaction ID

Mand

1

Procedure Transaction ID

Mand

1

Message Type

Mand

1

Message Type

Mand

1

Access Point Name

Opt

3-102

Protocol Configuration Options

Opt

3-253

ESM Information Request/Response

ESM Information Request/Response The ESM Information transfer process is included as an optional part of the PDN Connectivity procedure and allows APN and protocol configuration details to be passed to the network by the UE. The ESM Information Request/Response is a Miscellaneous ESM process that allows the same information types to be exchanged in a standalone procedure. The ESM Information Transfer Flag carried in PDN CONNECTIVITY REQUEST messages can have two values; 0 for ‘security protected ESM information transfer not required’ or 1 for ‘security protected ESM information transfer required’. If the PDN Connectivity process was taking place over an unciphered connection, if for example it was piggybacking on the Attach process, and the ‘secure transfer’ option was flagged then a separate standalone ESM Information transfer process would be initiated by the MME to securely carry the required information from the UE. The ESM INFORMATION REQUEST message is sent by the MME. It carries no substantive information and is simply an indication that the pending ESM Information signalled by the UE can now be sent securely. The UE transmits the required information in an ESM INFORMATION RESPONSE message, which can optionally carry APN details and/or protocol configuration option information.

Further Reading: 3GPP TS24.301:6.6.1 and 8.3.13/14 2.42

© Wray Castle Limited

LT3603/v1

Non-Access Stratum Processes

EPS Session Management EP ESM Status UE or Network Initiated UE

MME

ESM STATUS OR

ESM STATUS

ESM STATUS Information Element

Required

Length

Protocol Discriminator

Mand

1/2

EPS Bearer ID

Mand

1/2

Procedure Transaction ID

Mand

1

Message Type

Mand

1

ESM Cause

Mand

1

ESM Status

ESM Status ESM Status messages can be sent in either direction (UE–MME or MME–UE) and are used to indicate a limited range of errors that may be encountered after the establishment of ESM connections or resources. Error conditions are specified using ESM Cause codes. The set of error conditions that can be reported in this fashion is: ƒ Invalid EPS Bearer ID ƒ Invalid PTI ƒ Message Type non-existent or not implemented An Invalid EPS Bearer ID status message will result in the specified bearer being deactivated locally without further signalling. The ‘Invalid PTI’ and ‘Message Type non-existent…’ status reports result in the specified transaction being aborted.

Further Reading: 3GPP TS24.301:6.7 and 23.401:8.3.15 LT3603/v1

© Wray Castle Limited

2.43

LTE Radio Access Network

8

7 6 5 Security Header Type

4

3 2 1 Protocol Discriminator

1 2

Message Authentication Code

3 4 5

NAS COUNT Sequence Number Encrypted Plain NAS Message

6 7 n

Protocol Discriminator = 0010 for ESM, 0111 for EMM Message format used by both ‘native’ and ‘mapped’ Security Contexts

NAS Security

NAS Security The E-UTRAN Non-Access Stratum has the capability to securely transfer user-related signalling between the UE and the network. The functions that are invoked to allow this to happen are grouped under the heading NAS Security. The security functions are controlled using EPS Security Contexts, usually established as part of the Attach process, and optionally provide Integrity Protection of NAS message headers and full ciphering of NAS message content. EPS Security Contexts are been created between a UE and its serving MME; ‘native’ contexts are employed to secure EPS connections created wholly within the EPS environment, whilst ‘mapped’ contexts are created during inter-system handovers and are based on security vectors created by a non-EPS node such as an SGSN. Once created, each EPS Security Context is identified by a NAS eKSI (E-UTRAN Key Set Identifier), although this is often abbreviated to just KSI. The KSI is quoted in NAS Security Mode messages to ensure that both parties unequivocally understand the key to be used in the secure connection being established. NAS peers (UE and MME) initialize a NAS COUNT parameter at the start of a new secure connection. The NAS COUNT is formed of an 8-bit Sequence Number and a 16-bit Overflow Counter; separate NAS COUNTs are compiled for uplink and downlink message streams. The Sequence Number increments for each message sent in a particular direction; each time the Sequence Number reaches 255 it wraps round to 0 again and the Overflow Counter increments by 1. The NAS Sequence number is included in the Security Protected NAS message header and is used as an input to both the MAC Integrity Protection and Cipher key creation processes. New security keys can be created during reauthentication processes and are assigned a new KSI value. The UE and MME must be able to store two instances of security key, a ‘current’ key that is in use and a ‘partial’ key that is waiting to be used. An exchange of SECURITY MODE messages is used to change the value of the current key.

Further Reading: 3GPP TS24.301:4.4 and 33:401:8 2.44

© Wray Castle Limited

LT3603/v1

Non-Access Stratum Processes

8 7 6 5 0 0 0 0

Plain NAS message, no security protection

0 0 0 0

Security Protected NAS messages Integrity Protected Integrity Protected and Ciphered Integrity Protected with new EPS Security Context Integrity Protected and Ciphered with new EPS Security Context

0 0 0 1

0 1 1 0

1 0 1 0

1 1 0 0

8

Non-standard L3 messages Security Header for SERVICE REQUEST

7 6 5 Security Header Type

4

3 2 1 Protocol Discriminator

1 2

Message Authentication Code

3 4 5

NAS COUNT Sequence Number Encrypted Plain NAS Message

6 7 n

Security Header Types

Security Header Types Both Plain and Security Protected NAS message headers reserve space for a Security Header Type field, the values of which indicate the type of protection employed in the parent message. Plain NAS messages carrying EMM transactions set the value of the Security Header Type to 0000 to indicate that no security is employed (ESM messages use this field instead to carry an EPS Bearer Identity). Security Protected messages are able signal a range of values: ƒ Integrity Protected only, no ciphering employed ƒ Integrity Protected and Ciphered ƒ Integrity Protected with new EPS Security Context in use (only applicable to SECURITY MODE COMMAND messages, would signal a new KSI value in the body of the command) ƒ Integrity Protected and ciphered with new EPS Security Context in use (only applicable to SECURITY MODE COMMAND messages, would signal a new KSI value in the body of the command) The non-standard format of the SERVICE REQUEST message requires bespoke handling and a specific Security Header Type (1100) is employed to flag messages of this kind.

Further Reading: 3GPP TS24.301:9.3.1 LT3603/v1

© Wray Castle Limited

2.45

LTE Radio Access Network

UE

MME

MAC Created

8

7 6 5 Security Header Type

4

3 2 1 Protocol Discriminator

1 2

Message Authentication Code

MAC Validated

3 4

MAC Validated

5

NAS COUNT Sequence Number Encrypted Plain NAS Message

6 7

MAC Created

n

EMM Messages that don’t always require Integrity Protection ATTACH REQUEST IDENTITY RESPONSE AUTHENTICATION RESPONSE AUTHENTICATION FAILURE SECURITY MODE REJECT DETACH REQUEST DETACH ACCEPT TRACKING AREA UPDATE REQUEST All ESM messages require Integrity Protection

Integrity Protection

Integrity Protection Integrity Protection is employed for most EMM and for all ESM message types: in fact, apart from a few message types in a limited set of circumstances, communication between a UE and an MME cannot take place unless a Security Context has been invoked between them. The only EMM message flows that are not required to employ security protection are those that are used to establish or manage new registrations; some messages related to the Attach, Detach, Identification, Authentication and TAU procedures, for example, may not require security protection. Once an EPS Security Context has been created and brought into use by the SECURITY MODE COMMAND, all messages must be at least Integrity Protected. E-UTRAN NAS Integrity Protection is provided using the MAC (Message Authentication Code) method. MAC codes are 32-bits long and are calculated on a ‘per message’ basis by an EPS Integrity Algorithm (EIA) using the following inputs: ƒ A 128-bit integrity KEYNASint generated as part of the EPS Security Context ƒ The current NAS COUNT value for the direction in which the message will be travelling (uplink or downlink) ƒ The Bearer ID ƒ The Direction in which the message will be travelling ƒ The key stream length Two EIAs have been defined, EIA1 (SNOW 3G) and EIA2 (128-bit AES CMAC). The MAC is calculated and inserted at the transmitting node and removed and checked by the receiving node. The value of the MAC is partly determined by the content of some of the header fields (NAS COUNT, Bearer ID), so if an eavesdropper captured the message ‘in flight’ and changed any of its header content the value of the MAC would no longer match the value of its inputs. Invalid messages are discarded.

Further Reading: 3GPP TS24.301:4.4.4 and 33.401:Annex B 2.46

© Wray Castle Limited

LT3603/v1

Non-Access Stratum Processes

NAS COUNT (32 bits) EPS Bearer ID (5 bits) Direction (1 bit) Length (n bits) Key (128 bits)

EIA / EEA Keystream Block

Plaintext Block

Ciphertext Block

EEA0 Null Encryption EIA1/EEA1 SNOW 3G EIA2/EEA2 128-bit AES encryption Ciphering

Ciphering The use of ciphering on user connections is optional for operators. To ensure consistent and simple operation on network interfaces, however, security functions and security protected message flows are mandatory for certain types of transaction. Operators must employ the EPS security architecture, but if they do not wish to actually invoke the ciphering options that are available they may elect to set the MME default security algorithm to EEA0 (EPS Encryption Algorithm 0), which offers a ‘null encryption’ service. Two other EPS Encryption Algorithms have been defined: EEA1, based on the SNOW 3G method and EEA2, based on 128-bit AES encryption. The inputs for NAS ciphering are the same as for Integrity Protection, although a different key (KEYNASenc) is selected from the current EPS Security Context.

Further Reading: 3GPP TS24.301:4.4.5 and 33.401:8 LT3603/v1

© Wray Castle Limited

2.47

LTE Radio Access Network

2.48

© Wray Castle Limited

LT3603/v1

Non-Access Stratum Processes

Section 2 Glossary 3GPP

3rd Generation Partnership Project

AKA AMBR APN AUTN

Authentication and Key Agreement Aggregate Maximum Bit Rate Access Point Name Authentication Token

CDMA CLI CS

Code Division Multiple Access Calling Line Identity Circuit Switched

EBI ECM EIA eKSI EMM eNB EP EPS E-RAB ESM ETSI E-UTRAN

EPS Connection Management EPS Integrity Algorithm E-UTRAN Key Set Identifier, EPS Mobility Management Evolved Node B Elementary Procedure Evolved Packet System E-UTRAN Radio Access Bearer EPS Session Management European Telecommunication Standards Institute Evolved Universal Terrestrial Radio Access Network

GPRS GSM GUMMEI GUTI

General Packet Radio Service Global System for Mobile communications Globally Unique MME Identifier, Globally Unique Temporary Identity,

HSS

Home Subscriber Server

IMEISV IMSI ISR KASME KSI

International Mobile Equipment Identity Software Version International Mobile Subscriber Identity, Idle Mode Signalling Reduction Key Access Security Management Entries Key Set Identifier

LA LCS LTE

Location Area Location-based Service Long Term Evolution

LT3603/v1

© Wray Castle Limited

2.49

LTE Radio Access Network

MAC MCC MME MMEC MNC M-TMSI

Message Authentication Code Mobile Country Code Mobility Management Entity Mobility Management Entity Code Mobile Network Code MME Temporary Mobile Subscriber Identity.

NAS

Non Access Stratum

PCRF PCS PDN PDN-GW PLMN PPP PS PTI

Policy and Charging Rules Function PDN Connectivity Service Packet Data Network Packet Data Network Gateway Public Land Mobile Network Point-to-Point Protocol Packet Switched Procedure Transaction Identity

QoS

Quality of Service

RAND RAT RES RRC

Random Number Radio Access Technology Response Radio Resource Control

S1AP SGSN S-GW SMS S-TMSI

S1 Application Protocol Serving GPRS Support Node Serving Gateway Short Message Service SAE TMSI

TA TAI TAU TEID TFT TMSI

Tracking Area Tracking Area Identity Tracking Area Update Tunnel Endpoint ID Traffic Flow Template Temporary Mobile Subscriber Identity,

UE UMTS USIM

User Equipment Universal Mobile Telecommunications System Universal Subscriber Identity Module

2.50

© Wray Castle Limited

LT3603/v1

LTE Radio Access Network

Section 3

S1 Interface Messages and Procedures

© Wray Castle Limited

LTE Radio Access Network

ii

© Wray Castle Limited

LT3603/v1

S1 Interface Messages and Procedures

Contents S1 Interface .......................................................................................................................................... 3.1 S1AP (S1 Application Protocol) ........................................................................................................... 3.2 S1-U ..................................................................................................................................................... 3.3 S1-Flex Operation ................................................................................................................................ 3.4 S1 Identities ......................................................................................................................................... 3.5 S1 Message Structure.......................................................................................................................... 3.6 S1AP Functions and Procedures ......................................................................................................... 3.7 S1AP Class 1 Elementary Procedures ................................................................................................ 3.8 S1AP Class 2 Elementary Procedures ................................................................................................ 3.9 E-RAB Management .......................................................................................................................... 3.10 Context Management ......................................................................................................................... 3.11 Initial Context Setup Request ............................................................................................................ 3.12 S1-based Handover Signalling .......................................................................................................... 3.13 S1-based Handover ........................................................................................................................... 3.14 S1 Support for X2-based Handover ................................................................................................... 3.15 Paging ................................................................................................................................................ 3.16 NAS Transport – Initial UE Message ................................................................................................. 3.17 NAS Transport ................................................................................................................................... 3.18 Reset .................................................................................................................................................. 3.19 Error Indication ................................................................................................................................... 3.20 S1 Setup............................................................................................................................................. 3.21

LT3603/v1

© Wray Castle Limited

iii

LTE Radio Access Network

Configuration Update ......................................................................................................................... 3.22 Overload ............................................................................................................................................. 3.23 S1 CDMA2000 Tunnelling Procedures .............................................................................................. 3.24 UE Capability Info Indication .............................................................................................................. 3.25 Trace .................................................................................................................................................. 3.26 Location Reporting ............................................................................................................................. 3.27 Warning Message Transmission ........................................................................................................ 3.28 Direct Information Transfer ................................................................................................................ 3.29 Configuration Transfer ....................................................................................................................... 3.30

iv

© Wray Castle Limited

LT3603/v1

S1 Interface Messages and Procedures

Objectives

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

outline the functions performed by the S1 interface and the functional split between the S1-MME and S1-U interfaces

ƒ

describe the role played by the S1-Flex facility

ƒ

outline the basic structure of an S1AP message

ƒ

discuss the set of procedures performed by S1AP and describe the differences between Class 1 and Class 2 Elementary Procedures

ƒ

describe the functions of the S1AP message types

LT3603/v1

© Wray Castle Limited

v

LTE Radio Access Network

vi

© Wray Castle Limited

LT3603/v1

S1 Interface Messages and Procedures

S1AP MME

SCTP S1-MME

IP Data Link Layer Physical Layer

User Plane PDUs S1-U

GTP-U S-GW

UDP IP Data Link Layer Physical Layer

S1 Interface

S1 Interface The S1 interface can be seen as the evolved equivalent of the 3G Iu interfaces and interconnects the E-UTRAN with the EPC. Individual S1 interfaces run logically between each eNB and the set of MMEs and S-GWs to which it is associated. Traffic over the S1 is logically split into two types: S1-MME flows carry mobility management 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 (S1 Application Protocol). S1AP performs duties that combine those performed by the legacy RANAP (Radio Access Network Application Part) 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. U-plane data transfer (DT) traffic flows over the S1-U interfaced encapsulated in GTP (GPRS Tunnelling protocol) messages. EPS traffic connections employ the legacy GTPv1 (known as GTPv1U) protocol.

Further Reading: 3GPP TS 23.401:5.1, 36.413 (S1AP) LT3603/v1

© Wray Castle Limited

3.1

LTE Radio Access Network

MME

S1AP SCTP IP S1-MME

L2 L1

eNB

ƒ

E-RAB management

ƒ

initial context transfer

ƒ

UE context management

ƒ

additional E-RAB creation

ƒ

mobility functions

ƒ

paging

ƒ

direct transfer of NAS signalling

S1 Application Protocol (S1AP)

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

© Wray Castle Limited

LT3603/v1

S1 Interface Messages and Procedures

Non-guaranteed PDU delivery via GTP-U User PDU

EPS IP Transport

GTPv1-U UDP IP

S1-U

L2 L1

S-GW

S1-U

S1-U A logical S1-U interface is created between an eNB and each S-GW with which it is associated and provides AS (Access Stratum) connectivity for E-UTRAN users. User traffic, transmitted in the form of a PDU (Protocol Data Unit), 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. 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 and is identified at the GTP level by TEIDs (Tunnel Endpoint IDs).

Further Reading: 3GPP TS36.414 (S1 Data Transport) and 29.281 (GTPv1-U) LT3603/v1

© Wray Castle Limited

3.3

LTE Radio Access Network

MME 2

MME 1

MME 3

S1-MME

S1-Flex

S1-U S-GW 3

S-GW 1

S-GW 2

S1-Flex Operation

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 3.4

© Wray Castle Limited

LT3603/v1

S1 Interface Messages and Procedures

eNB UE S1AP ID

MME UE S1AP ID

S1-MME S1AP Context MME

S1-U GTP Tunnel

S-GW

Tunnel Endpoint IDs (TE-ID)

S1 Identities

S1 Identities To allow S1AP 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 eNB UE S1AP ID and MME UE S1AP ID uniquely identify a UE within the eNB and MME. 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) UEs and an MME 232 (4.3 billion). The 4-byte GTP TEID (Tunnel Endpoint ID) is used in the EPS 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 S1AP during tunnel establishment.

Further Reading: 3GPP TS 36.413:9.2.3 LT3603/v1

© Wray Castle Limited

3.5

LTE Radio Access Network

S1AP Message

S1AP

SCTP

IP

Typical S1AP Message Format Information Element

Required

Message Type

Mand

MME UE S1AP ID

Mand

eNB UE S1AP ID

Mand Opt Opt Cond Cond

Mandatory fields

Optional fields Conditional fields, presence determined by optional fields

S1 Message Structure

S1 Message Structure S1AP messages are encapsulated within an SCTP/IP packet for transport through the E-UTRAN IP environment. SCTP manages the association between peer nodes and IP is responsible for delivering packets. All S1AP messages begin with a Message Type field, which carries a Procedure Code to specify the function being performed by the message and a Type of Message field to indicate the stage of the process being signalled by the message (Initiating Message, Successful Outcome, Unsuccessful Outcome). Messages that relate to user connections also usually carry the eNB UE S1AP ID and/or MME UE S1AP ID that uniquely identify a particular UE and the E-RAB ID(s) that identify any referenced connections. Each specific message type has its own defined format; message fields are classed as being Mandatory, Optional and Conditional. The presence of Conditional fields is usually determined by the presence or content of one of the Optional fields and may differ from instance to instance of each message type. As is common in 3GPP-defined systems, many of the fields specified for a message type are regarded as Information Elements rather than simple Information Items. Information Elements often have their own defined structure of sub-fields and could be of variable length; Information Items are generally fixed-length fields containing just one piece of data.

Further Reading: 3GPP TS36.413:9.1 3.6

© Wray Castle Limited

LT3603/v1

S1 Interface Messages and Procedures

E-RAB Management

Context Management

E-RAB setup/modify/ release

Initial Context Setup UE Context release/ notification

Handover Signalling

HO preparation/ notification/ cancellation

Paging

Paging

NAS Transport

Direct Transfer

Trace start/deactivate/ failure

CDMA2000 Tunnelling Procedures

eNB/MME Configuration Update

eNB/MME Status Transfer

UE Capability Information

CDMA2000 Tunnelling

S1 Setup

HO Resource Allocation

Location Reporting

Trace

Reset Error Indication

Path Switch

UE Capability Information

Management Procedures

Location Report

Overload start/stop

Warning Messages

eNB Direct Information

Warning Message eNB Direct Transmission Information Transfer

MME Direct Information

MME Direct Information Transfer

Cell Traffic Trace

S1AP Functions and Procedures

S1AP Functions and Procedures S1AP protocol has been designed to perform the following functions: ƒ ƒ ƒ ƒ ƒ ƒ

ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ

E-RAB management Initial Context Transfer UE Capability Info Indication Mobility Functions for 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 (Elementary Procedure) message types shown in the diagram.

Further Reading: 3GPP TS36.413:7 LT3603/v1

© Wray Castle Limited

3.7

LTE Radio Access Network

Elementary Procedure

Initiating Message

Successful Outcome

Unsuccessful Outcome

Response message

Response message

Handover Preparation

HANDOVER REQUIRED

HANDOVER COMMAND

HANDOVER PREPARATION FAILURE

Handover Resource Allocation

HANDOVER REQUEST

HANDOVER REQUEST ACKNOWLEDGE

HANDOVER FAILURE

Path Switch Request

PATH SWITCH REQUEST

PATH SWITCH REQUEST ACKNOWLEDGE

PATH SWITCH REQUEST FAILURE

Handover Cancellation

HANDOVER CANCEL

HANDOVER CANCEL ACKNOWLEDGE

E-RAB Setup

E-RAB SETUP REQUEST

E-RAB SETUP RESPONSE

E-RAB Modify

E-RAB MODIFY REQUEST

E-RAB MODIFY RESPONSE

E-RAB Release

E-RAB RELEASE COMMAND

E-RAB RELEASE RESPONSE

Initial Context Setup

INITIAL CONTEXT SETUP REQUEST

INITIAL CONTEXT SETUP RESPONSE

Reset

RESET

RESET ACKNOWLEDGE

S1 Setup

S1 SETUP REQUEST

S1 SETUP RESPONSE

UE Context Release

UE CONTEXT RELEASE COMMAND

UE CONTEXT RELEASE COMPLETE

UE Context Modification

UE CONTEXT MODIFICATION REQUEST

UE CONTEXT MODIFICATION RESPONSE

UE CONTEXT MODIFICATION FAILURE

eNB Configuration Update

ENB CONFIGURATION UPDATE

ENB CONFIGURATION UPDATE ACKNOWLEDGE

ENB CONFIGURATION UPDATE FAILURE

MME Configuration Update

MME CONFIGURATION UPDATE

MME CONFIGURAION UPDATE ACKNOWLEDGE

MME CONFIGURATION UPDATE FAILURE

Write-Replace Warning

WRITE-REPLACE WARNING REQUEST

WRITE-REPLACE WARNING RESPONSE

INITIAL CONTEXT SETUP FAILURE

S1 SETUP FAILURE

S1AP Class 1 Elementary Procedures

S1AP Class 1 Elementary Procedures An EP is classed as a ‘unit of interaction’ between an eNB and the EPC; in others it represents the sending or receiving of a message or the exchange of a message and a response. Class 1 EPs are messages that require a response – either a ‘success’ or a ‘failure’ notification. Class 2 EPs are messages that do not require a response. The Class 1 EPs shown in the diagram are mostly related to E-RAB management, Context management and Handover functions. In terms of S1 Management procedural hierarchy, the Reset procedure has precedence over all other functions; an S1 Reset instruction will therefore be acted upon immediately even if this is to the detriment of other ongoing processes. In terms of UE Context management, the UE Context Release procedure takes precedence, meaning that a Release will be actioned immediately and all other procedures related to the specific context will cease.

Further Reading: 3GPP TS 36.413:8.1 3.8

© Wray Castle Limited

LT3603/v1

S1 Interface Messages and Procedures

Elementary Procedure

Elementary Procedure

Message

Message

Handover Notification

HANDOVER NOTIFY

Deactivate Trace

DEACTIVATE TRACE

E-RAB Release Indication

E-RAB RELEASE INDICATION

Trace Start

TRACE START

Paging

PAGING

Trace Failure Indication

TRACE FAILURE INDICATION

Initial UE Message

INITIAL UE MESSAGE

Location Reporting Control

Downlink NAS Transport

DOWNLINK NAS TRANSPORT

LOCATION REPORTING CONTROL

Uplink NAS Transport

UPLINK NAS TRANSPORT

Location Reporting Failure Indication

LOCATION REPORTING FAILURE INDICATION

NAS non delivery indication

NAS NON DELIVERY INDICATION

Location Report

LOCATION REPORT

Error Indication

ERROR INDICATION

UE Context Release Request

UE CONTEXT RELEASE REQUEST

Downlink S1 CDMA2000 Tunnelling

DOWNLINK S1 CDMA2000 TUNNELLING

Uplink S1 CDMA2000 Tunnelling

UPLINK S1 CDMA2000 TUNNELLING

eNB Status Transfer

eNB STATUS TRANSFER

MME Status Transfer

MME STATUS TRANSFER

UE Capability Info Indication

UE CAPABILITY INFO INDICATION

Overload Start

OVERLOAD START

Overload Stop

OVERLOAD STOP

eNB Direct Information Transfer

eNB DIRECT INFORMATION TRANSFER

MME Direct Information Transfer

MME DIRECT INFORMATION TRANSFER

eNB Configuration Transfer

eNB CONFIGURATION TRANSFER

MME Configuration Transfer

MME CONFIGURATION TRANSFER

Cell Traffic Trace

CELL TRAFFIC TRACE

S1AP Class 2 Elementary Procedures

S1AP Class 2 Elementary Procedures The set of Class 2 S1AP EPs is shown in the diagram. They mostly provide notifications or indications of events or conditions, although some message types are used for the one-way transfer of configuration and status information.

Further Reading: 3GPP TS36.413:8.1 LT3603/v1

© Wray Castle Limited

3.9

LTE Radio Access Network

E-RAB Management eNB and Network Initiated

eNB

E-RAB SETUP REQUEST E-RAB MODIFY REQUEST E-RAB RELEASE COMMAND

MME

E-RAB SETUP RESPONSE E-RAB MODIFY RESPONSE E-RAB RELEASE RESPONSE E-RAB RELEASE INDICATION E-RAB SETUP REQUEST

Required per E-RAB to be set up. Between 1 and 256 E-RABs

Information Element

Required

Length

Message Type

Mand

Variable

MME UE S1AP ID

Mand

4

eNB UE S1AP ID

Mand

3

UE AMBR

Opt

Variable

E-RAB to be setup list

Mand

Variable

E-RAB ID

Mand

4 bits

E-RAB QoS

Mand

Variable

Transport Layer Address

Mand

1-160 bits

GTP TEID

Mand

4

NAS PDU

Mand

Variable

E-RAB Management

E-RAB Management An E-RAB exists to carry an EPS Bearer associated with a UE Context across the E-UTRAN S1 interface and maps onto the Data Radio Bearer assigned to carry the connection across the LTE-Uu interface in the serving cell. Most of the procedures that Set up, Modify and Release E-RABs are initiated by the network using messages that can carry instructions relating to multiple bearers (between 1 and 256 E-RABs, as long as they all relate to the same UE Context). The E-RAB SETUP REQUEST message is used to establish new bearers. As with most S1AP messages, the Setup Request unambiguously identifies the UE to which the procedure relates by inserting the MME UE S1AP ID and eNB UE S1AP ID into the message header. The message may also signal the AMBR (Aggregate Maximum Bit Rate) QoS level assigned to the UE. Each E-RAB being established in the current procedure has a separate section within the setup message, which details the 4-bit E-RAB ID assigned to the connection, its specific QoS level and the IP address and GTP TEID associated with it. The message will also carry a NAS PDU, which transports a message between the MME and the UE. As E-RABs are mapped in a one-to-one fashion with Data Radio Bearers, the E-RAB setup request implicitly instructs the eNB to assign radio resources with equivalent characteristics to carry the connections to the UE. The E-RAB MODIFY REQUEST message allows the QoS values assigned to E-RABs to be altered and the E-RAB RELEASE COMMAND allows the MME to direct the eNB to clear selected E-RABs. The eNB responds with E-RAB SETUP RESPONSE, E-RAB MODIFY RESPONSE or E-RAB RELEASE RESPONSE accordingly, all of which message formats include fields to specify the ERABs for which the requested action was completed successfully and others showing the E-RABs for which the procedure failed. The eNB is able to initiate the release of E-RAB resources by transmitting a Class 2 EP E-RAB RELEASE INDICATION to the MME, which may contain details of one or more E-RABs to be cleared.

Further Reading: 3GPP TS36.413:8.2, 9.1.3 and 36.300:19.2 3.10

© Wray Castle Limited

LT3603/v1

S1 Interface Messages and Procedures

Context Management Network Initiated

INITIAL CONTEXT SETUP REQUEST eNB

INITIAL CONTEXT SETUP RESPONSE INITIAL CONTEXT SETUP FAILURE

MME

UE CONTEXT MODIFICATION REQUEST UE CONTEXT MODIFICATION RESPONSE UE CONTEXT MODIFICATION FAILURE UE CONTEXT RELEASE COMMAND UE CONTEXT RELEASE COMPLETE UE CONTEXT RELEASE REQUEST

Context Management

Context Management A UE Context provides a set of identifiers and parameter values shared between an eNB and an MME which uniquely relate to one UE. Context establishment is initiated by the network and may occur in response to an event such as an Attach Request or Service Request which causes a UE to become active in a cell controlled by an eNB with which it has no current association. The INITIAL CONTEXT SETUP REQUEST issued by the MME instructs the eNB to create a Context for the UE and to populate it with identification, security, E-RAB configuration and other service details, it will also carry establishment details for at least a Default E-RAB (to carry a Default EPS Bearer) and optionally for additional Dedicated E-RABs. If the eNB is able to at least partly comply with the MME’s request it returns an INITIAL CONTEXT SETUP RESPONSE, which contains details of the E-RABs that were and were not successfully created. If the eNB is totally unable to comply with the request it returns an INITIAL CONTEXT SETUP FAILURE message detailing the failure cause. The UE CONTEXT MODIFICATION REQUEST allows aspects of the UE Context to be changed during its lifetime: these include the assignment of new security key parameters; alterations to the UE’s overall AMBR value; the addition or modification of a RAT/Frequency profile and the addition or modification of a CS Fallback indicator. Context Modification messages do not provide instructions that change the parameters of individual E-RABs, so the UE CONTEXT MODIFICATION RESPONSE and UE CONTEXT MODIFICATION FAILURE messages returned by the eNB deal only with total success or total failure conditions. The UE CONTEXT RELEASE COMMAND issued by the MME is used to clear details of the UE from the eNB in the event, for example, of the UE entering Idle Mode and releasing its S1 connections or following a successful Handover of a UE to a different eNB. The eNB is able to initiate the release of UE Contexts using the Class 2 EP UE CONTEXT RELEASE INDICATION message type.

Further Reading: 3GPP TS36.413:8.3, 9.1.4 and 36.300:19.2 LT3603/v1

© Wray Castle Limited

3.11

LTE Radio Access Network

Context Management Network Initiated

INITIAL CONTEXT SETUP REQUEST Information Element

Required

Length

Message Type

Mand

Variable

MME UE S1AP ID

Mand

4

eNB UE S1AP ID

Mand

3

UE AMBR

Mand

Variable

E-RAB to be setup list

Mand

Variable

Per E-RAB fields as in E-RAB SETUP REQUEST UE Security Capabilities

Mand

Variable

Security Key

Mand

1

Trace Activation

Opt

Variable

Handover Restriction List

Opt

Variable

UE Radio Capability

Opt

Variable

Subscriber Profile ID (for RAT/Frequency Priority)

Opt

1

CS Fallback Indicator

Opt

Variable

SRVCC Operation Possible

Opt

Variable

Initial Context Setup Request

Initial Context Setup Request The INITIAL CONTEXT SETUP REQUEST carries the MME UE S1AP ID assigned to the UE by the MME and leaves the eNB UE S1AP ID field blank. The INITIAL CONTEXT SETUP RESPONSE returned by the eNB echoes the supplied MME UE S1AP ID and provides the eNB UE S1AP ID that it has assigned to the UE at its end of the S1 link. The Request must also specify an AMBR value for the UE and will include set-up instructions for at least a Default E-RAB (E-RAB ID, E-RAB QoS, IP address, GTP TEID and NAS PDU). Security details relating to the UE are signalled using the mandatory UE Security Capabilities and Security Key information elements. The Request may also optionally carry IEs that active the Trace function, specify any Handover Restrictions related to the UE or detail the UE’s radio capabilities. The MME may provide a Subscriber Profile ID for RAT/Frequency Priority. This allows the UE’s Idle Mode reselection behaviour to be managed by the eNB by specifying priority the UE should assigned to the various radio access types (2G, 3G, 4G) or frequency bands that it may find available for use. Additional optional elements are used to flag the ability of the UE or its active subscription to make use of ‘voice over LTE’ variants such as CS Fallback (where the UE falls back to a 2G/3G CS-capable cell when required to establish a CS connection) or SRVCC (Single Radio Voice Call Continuity, which is another method of employing legacy resources to connect CS services).

Further Reading: 3GPP TS36.413:9.1.4.1 3.12

© Wray Castle Limited

LT3603/v1

S1 Interface Messages and Procedures

Handover Signalling eNB Initiated

Source eNB

Target eNB

HANDOVER REQUIRED HANDOVER REQUEST

MME

HANDOVER COMMAND HANDOVER PREPARATION FAILURE

HANDOVER REQUEST ACKNOWLEDGE HANDOVER FAILURE

eNB STATUS TRANSFER

MME STATUS TRANSFER

HANDOVER NOTIFY HANDOVER CANCEL HANDOVER CANCEL ACKNOWLEDGE

S1-based Handover Signalling

S1-based Handover Signalling As the E-UTRAN has no equivalent node to the BSC/RNC employed in legacy networks, handover procedures are initiated by individual eNBs. If a logical X2 interface exists between source and target eNBs, in the case of intra-E-UTRAN handovers, S1 signalling is only required once the Handover has been effected. If no X2 exists then an S1-based Handover is required. Once a UE and its serving eNB have made the decision that an S1-based Handover is required, the eNB initiates the Handover Preparation process by transmitting a HANDOVER REQUIRED message to the current MME. In this example it is assumed that source and target eNBs are associated with the same MME. The MME issues a HANDOVER REQUEST to the target eNB to begin the process of resource reservation and allocation. The MME also begins the process of switching the UE’s EPS Bearers to the new cell. If resources are available in the target cell the target eNB responds with HANDOVER REQUEST ACKNOWLEDGE detailing the resource reservation that has been made for the UE in the target cell. The MME forwards these details in a HANDOVER COMMAND message to the source eNB, which in turn informs the UE. At the point that the source eNB decides to cease downlink transmission and uplink reception for the UE it issues an eNB STATUS TRANSFER towards the MME containing the current PDCP SN (Sequence Number) and the HFN (Hyper Frame Number) applicable to the UE Context. The MME forwards these details to the target eNB in an MME STATUS TRANSFER message. Once the UE successfully synchronizes with the reserved resources in the new cell it contacts the target eNB which forwards a HANDOVER NOTIFY message to the MME. The source eNB can abort the handover process at any time by issuing a HANDOVER CANCEL message.

Further Reading: 3GPP TS36.413:8.4, 23.401:5.5.1.2 (S1-based Handover) LT3603/v1

© Wray Castle Limited

3.13

LTE Radio Access Network

Handover Signalling eNB Initiated

HANDOVER REQUIRED Information Element

Required

Length

Message Type

Mand

Variable

MME UE S1AP ID

Mand

4

eNB UE S1AP ID

Mand

3

Handover Type

Mand

Variable

Cause

Mand

Variable

Target ID

Mand

Variable

Direct Forwarding Path Availability

Opt

Variable

SRVCC HO Indication

Opt

Variable

Source-Target Transparent Container

Mand

Variable

Source-Target Transparent Container secondary

Opt

MS Classmark 2 MS Classmark 3

Source eNB to Target eNB Transparent Container Information Element

Required

RRC Container

Mand

Target Cell ID

Mand

Subscriber Profile ID for RAT/Frequency Priority

Opt

E-RAB Information List

Opt

E-RAB ID

Mand

Downlink Forwarding

Opt

Variable

UE History Information

Mand

Cond

Variable

Cond

Variable

Other Transparent Container formats exists for HO between E-UTRAN and GERAN (via BSS) and E-UTRAN and UTRAN (via RNC)

S1-based Handover

S1-based Handover The HANDOVER REQUIRED message relates to a specific UE Context and therefore carries both eNB UE S1AP ID and MME UE S1AP ID details. The Handover Type field can take the values IntraLTE, LTEtoUTRAN, LTEtoGERAN, UTRANtoLTE or GERANtoLTE. There are multiple Cause values that could be applied to a Handover message including S1 intra-system handover triggered and S1 inter-system handover triggered. The Target ID takes the form of the target cell’s Global eNB-ID (for intra-system HO), the target RNC’s RNC-ID (for HO with UTRAN) or the target cell’s CGI (for HO with GERAN). Direct Forwarding allows the source and target base stations or controllers to forward session data between themselves directly without requiring a path to be established via the S-GW. For example, if a routable IP path exists between a source eNB and a target RNC then those devices may elect to forward traffic directly. The optional Direct Forwarding Path Availability IE has the value Direct Forwarding Available. SRVCC (Single Radio Voice Call Continuity) allows EPS connections to be handed over to 2G or 3G networks to allow CS calls to be handled. Options exist to allow any ongoing PS connections also to be either handed over to the legacy network too or simply parked for the duration for the CS session. The SRVCC HO Indication IE can take the values PS and CS or CS only to reflect these options. The Source to Target Transparent Container carries details of the UE’s current connections and resource requirements plus other RF and UE specific data. Different formats of Container exist to serve the needs of Intra-E-UTRAN, E-UTRAN-UTRAN and E-UTRAN-GERAN handover types. The MS Classmark fields are optional and would only be required in the event of SRVCC handover being invoked.

Further Reading: 3GPP TS36.413:9.1.5.1 3.14

© Wray Castle Limited

LT3603/v1

S1 Interface Messages and Procedures

Handover Signalling eNB Initiated

Target eNB MME

PATH SWITCH REQUEST PATH SWITCH REQUEST ACKNOWLEDGE PATH SWITCH REQUEST FAILURE

PATH SWITCH REQUEST Information Element

Required

Length

Message Type

Mand

Variable

eNB UE S1AP ID

Mand

3

E-RAB to be switched in DL list

Mand

Variable

E-RAB ID

Mand

4 bits

Transport Layer Address

Mand

1-160 bits

GTP TEID

Mand

4

Source MME UE S1AP ID

Mand

4

E-UTRAN CGI

Mand

Variable

TAI

Mand

Variable

UE Security Capabilities

Mand

Variable

S1 Support for X2-based Handover

S1 Support for X2-based Handover If an Intra-E-UTRAN Handover is to be managed directly between source and target eNBs via the X2 interface there is little requirement for S1 involvement, except at the very end of the process. The PATH SWITCH REQUEST procedure allows the target eNB to request that the path of the UE’s bearers be switched so that they travel to the new cell. The message format allows the eNB to provide the MME with the UE’s new eNB UE S1AP ID and also identifies the source MME UE S1AP ID to allow the MME to determine which UE is involved. Details of the E-RABs to be switched are provided, as are details of the new cell in which the UE is active. If the Path switch is successful the MME responses with PATH SWITCH REQUEST ACKNOWLEDGEMENT, if the procedure cannot be completed it responds with PATH SWITCH REQUEST FAILURE detailing the reason for the failure with a cause code.

Further Reading: 3GPP TS36.413:8.4 and 23.401:5.5.1.1 (X2-based HO) LT3603/v1

© Wray Castle Limited

3.15

LTE Radio Access Network

Paging Network Initiated

MME

eNB

PAGING

PAGING

IMSI or S-TMSI

Closed Subscriber Groups

Information Element

Required

Length

Message Type

Mand

Variable

UE Paging Identity Index Value

Mand

10 bits

UE Paging Identity

Mand

Variable

Paging DRX

Opt

Variable

CN Domain

Mand

Variable

List of TAIs

Mand

Variable

TAI

Mand

Variable

CSG ID List

Mand

CSG ID

Mand

27 bits ea

Paging

Paging Paging is undertaken to require an Idle Mode UE to establish contact with the MME. Paging messages are sent to all eNBs belonging to the Tracking Areas in the UE’s current TAI List. The eNB is responsible for determining in which of its cells it propagates the page. Paging is handled by the PAGING message, which contains a Paging Identity (S-TMSI or IMSI). The message may optionally also indicate the DRX (Discontinuous Reception) periodicity assigned to the UE and will contain details of the Core Network Domain (PS or CS) which issued the page. The TAI fields list the set of Tracking Areas within which the UE is currently registered and the CSG fields carry information pertaining to any Closed User Groups to which the UE may belong. Paging is a Class 2 Elementary Procedure and there is no explicit response required.

Further Reading: 3GPP TS36.413:8.5 and 9.1.6 3.16

© Wray Castle Limited

LT3603/v1

S1 Interface Messages and Procedures

NAS Transport eNB Initiated

MME

eNB

INITIAL UE MESSAGE

INITIAL UE MESSAGE

e.g. ATTACH, SERVICE REQUEST

Information Element

Required

Length

Message Type

Mand

Variable

eNB UE S1AP ID

Mand

3

NAS PDU

Mand

Variable

TAI

Mand

Variable

E-UTRAN CGI

Mand

Variable

S-TMSI

Opt

Variable

CSG ID

Opt

27 bits

RRC Establishment Cause

Mand

Variable

GUMMEI

Opt

Variable

NAS Transport – Initial UE Message

NAS Transport – Initial UE Message NAS Transport procedures allow S1AP to carry NAS messages transparently between a UE and an MME. There are a variety of circumstances in which this facility would be required, but they can all be served using just two subtypes of the NAS Transport procedure. NAS messages transmitted by a UE that has no currently active UE Context are carried inside the S1AP INITIAL UE MESSAGE format, whilst NAS messages exchanged between a UE and an MME in all other situations are carried in standalone UPLINK NAS TRANSPORT or DOWNLINK NAS TRANSPORT messages. The INITIAL UE MESSAGE would be used to carry NAS transactions such as Attach and Service Request, which are transmitted when a UE has no existing S1 connection or UE Context to invoke. After receiving the initial contact from the UE but prior to transmitting the Initial message an eNB will generate an eNB UE S1AP ID for the user and will insert this into the message along with the NAS PDU. Other required information elements in the Initial message include the serving cell’s eCGI and TAI and also the RRC Establishment Cause signalled by the radio layers. Cause codes of emergency, highPriorityAccess, mt-Access, mo-Signalling and mo-Data are recognized. The message may also optionally contain details of any S-TMSI, CSG ID or GUMMEI supplied by the UE. INITIAL UE MESSAGE is a Class 2 EP and does not therefore require an explicit response.

Further Reading: 3GPP TS36.413:8.6 and 9.1.7.1 LT3603/v1

© Wray Castle Limited

3.17

LTE Radio Access Network

NAS Transport eNB or Network Initiated

UPLINK NAS TRANSPORT

eNB

MME

DOWNLINK NAS TRANSPORT NAS NON DELIVERY MESSAGE

DOWNLINK NAS TRANSPORT

UPLINK NAS TRANSPORT Information Element

Information Element

Required

Length

Variable

Message Type

Mand

Variable

4

MME UE S1AP ID

Mand

4

Required

Length

Message Type

Mand

MME UE S1AP ID

Mand

eNB UE S1AP ID

Mand

3

eNB UE S1AP ID

Mand

3

NAS PDU

Mand

Variable

NAS PDU

Mand

Variable

E-UTRAN CGI

Mand

Variable

Handover Restriction List

Opt

Variable

TAI

Mand

Variable

NAS Transport

NAS Transport Standalone NAS Transport messages carry information for UEs that have existing S1 connections. The UPLINK NAS TRANSPORT message format carries both the eNB UE S1AP ID and the MME UES1AP ID along with details of the current serving cell, all of which encapsulates a NAS message. DOWNLINK NAS TRANSPORT messages also carry both UE Context identifiers along with an optional Handover Restriction List relevant to the UE. NAS Transport messages are Class 2 Elementary Procedures and do not require an explicit response, however if an eNB receives a DOWNLINK NAS TRANSPORT message that it is unable to deliver (or that it has attempt to deliver but has not received a response from the UE) then it returns a NAS NON DELIVERY MESSAGE to the MME to signal message delivery failure.

Further Reading: 3GPP TS36.413:8.6 and 9.1.7 3.18

© Wray Castle Limited

LT3603/v1

S1 Interface Messages and Procedures

Management Procedures Reset eNB or Network Initiated

RESET

eNB

MME

RESET ACKNOWLEDGE RESET RESET ACKNOWLEDGE

RESET

S1 Interface or part of S1 Interface

Details of specific connections to be reset

Information Element

Required

Length

Message Type

Mand

Variable

Cause

Mand

Variable

Reset Type

Mand

Variable

S1 Interface – Reset All

Mand

Variable

Part of S1 Interface

Mand

Variable

UE-associated logical S1 connection list MME UE S1AP ID

Opt

4 each

eNB UE S1AP ID

Opt

3 each

Reset

Reset The RESET command is a Management Procedure that can be used to reset all S1 and Uu connections active in an eNB or can be used to reset only selected connections. The command is used in response to failure situations in which some or all of the UE Context and connection-related data associated with an instance of the S1 interface has been lost or corrupted. If the failure occurred in the MME then it will initiate the Reset towards all eNBs whose connections were affected by the problem. If the failure occurred in an eNB it will initiate the Reset towards the MME. The Cause IE indicates the reason for the reset; of the many cause values supported common causes for resets could include Hardware Failure or O&M Intervention. Depending upon the scope of the reset signalled in the Reset Type field (S1 Interface or Part of S1 Interface) an eNB will release all of just some of its current S1 and Uu resources without waiting for any kind of orderly shutdown process to take effect. This essentially means that the UEs served by the effected eNB immediately lose connectivity and will be required to perform the Service Request procedure to re-establish their lost bearers. If the S1 connections for only certain UE Contexts are to be reset then the message will specify the S1AP IDs associated with the affected UEs. Reset is a Class 1 EP and requires a RESET ACKNOWLEDGE to be returned by the receiving device. In the event of a reset of the entire S1 interface the Acknowledge message need only contain the Message Type IE.

Further Reading: 3GPP TS36.413:8.7.1 and 9.1.8 LT3603/v1

© Wray Castle Limited

3.19

LTE Radio Access Network

Management Procedures Error Indication eNB or Network Initiated

eNB

ERROR INDICATION

MME

ERROR INDICATION

ERROR INDICATION Information Element

Required

Length

Message Type

Mand

Variable

MME UE S1AP ID

Opt

4

eNB UE S1AP ID

Opt

3

Cause

Opt

Variable

Criticality Diagnosis

Opt

Variable

Procedure Code Triggering Message Procedure Criticality IE Criticality IE ID Type of Error

Error Indication

Error Indication The set of S1 Management Procedures include standalone Error Indications which allow errors in received messages to be reported but are only required if the errored message type has no failure indication of its own; for example, an error in a received HANDOVER REQUIRED message can be reported in a returned HANDOVER PREPARATION FAILURE, whereas an error in a Class 2 PAGING message would require a standalone ERROR INDICATION to be returned. The only mandatory field in the ERROR INDICATION message is Message Type; optional extra details such as S1AP IDs and Cause and Criticality Diagnosis fields may be added. Criticality Diagnosis information is used to provide further details regarding an error or failure. It can, for example, indicate the Procedure Code of the errored message by flagging its Message Type or the exact IE that caused a failure. ERROR INDICATION is a Class 2 EP and has no required response.

Further Reading: 3GPP TS36.413:8.7.2 and 9.1.8.3 3.20

© Wray Castle Limited

LT3603/v1

S1 Interface Messages and Procedures

Management Procedures S1 Setup eNB Initiated

S1 SETUP REQUEST

eNB

MME

S1 SETUP RESPONSE S1 SETUP FAILURE

S1 SETUP REQUEST

S1 SETUP RESPONSE

Information Element

Required

Length

Information Element

Required

Message Type

Mand

Variable

Message Type

Mand

Variable

Global eNB ID

Mand

Variable

MME Name

Opt

Variable

Mand

3 each

Mand

2 each

Mand

1 each

Opt

Variable

eNB Name

Opt

Variable

Served GUMMEI List

Supported TA List

Opt

Variable

Served PLMN List

TAC

Mand

2 each

PLMN ID

Broadcast PLMN IDs

Mand

3 each

Served Group ID List

CSG ID List

Mand

MME Group IDs

CSG ID

Mand

27 bits ea

Default Paging DRX

Mand

Variable

Length

Served MMEC List MME Code Relative MME Capacity Criticality Diagnostics

S1 Setup

S1 Setup The S1 Setup process is used to initially establish (or to re-establish) the S1 relationship between an eNB and an MME. The process would be followed for an eNB that had recently been commissioned, for example, or for an eNB that had been re-homed to a new MME Pool. The S1 SETUP REQUEST contains relevant information to allow the MME to determine the identity of the eNB and the set of PLMNs and Tracking Areas to which it offers service. The fact that the eNB is configured with PLMN and TAI information independently of the MME (or to put it another way, that the eNB is not informed by the MME of the PLMN or TAs to which it offers service) lies at the heart of both the S1-Flex and Multi Operator RAN concepts. Space is optionally provided in the Setup message to carry a text-based ‘human readable’ eNB Name and the eNB is also able to signal its Default Paging DRX periodicity to the MME. Following the initial connection or the reset of the eNB’s SCTP/IP transport layer, the eNB will initiate an S1 Setup procedure with each MME with which it is required to establish an association. If an MME receives an S1 Setup request from an eNB with which it has an existing association the details of the existing association will be deleted and a new instance of the S1 interface will be created. If the MME is able to establish an association with the eNB it returns an S1 SETUP RESPONSE, which details the MME’s configured PLMNs and MME Groups as well as its Relative Capacity. If the MME cannot establish an association with the eNB, if for example it does not serve any of the PLMNs that the UE signalled that it offered service to, it will return an S1 SETUP FAILURE message containing a Cause code.

Further Reading: 3GPP TS36.413:8.7.3 and 9.1.8.4-6 LT3603/v1

© Wray Castle Limited

3.21

LTE Radio Access Network

Management Procedures Configuration Update eNB or Network Initiated

eNB

ENB CONFIGURATION UPDATE ENB CONFIGURATION UPDATE ACKNOWLEDGE ENB CONFIGURATION UPDATE FAILURE

MME

MME CONFIGURATION UPDATE MME CONFIGURATION UPDATE ACKNOWLEDGE MME CONFIGURATION UPDATE FAILURE MME CONFIGURATION UPDATE

ENB CONFIGURATION UPDATE Information Element

Required

Length

Information Element

Required

Length

Message Type

Mand

Variable

Message Type

Mand

Variable

eNB Name

Opt

Variable

MME Name

Opt

Variable

Supported TA List

Opt

Variable

Served GUMMEI List

TAC

Mand

2 each

Served PLMN IDs

Mand

3 each

Broadcast PLMN IDs

Mand

3 each

Served Group ID List Mand

2 each

Served MMEC List

MME Group IDs

CSG ID List

Mand

CSG ID

Mand

27 bits ea

Default Paging DRX

Opt

Variable

MME Codes

Mand

1 each

Relative MME Capacity

Opt

Variable

Configuration Update

Configuration Update The Configuration Update messages carry essentially the same information as is exchanged in the S1 SETUP REQUEST/RESPONSE procedure and are designed to carry updates from eNB to MME or vice versa if any of the high-level configuration details change. If an eNB is reconfigured to support an additional TAI, for instance, it would update its set of associated MMEs by transmitting an eNB CONFIGURATION UPDATE including an updated list of TAIs. Other usage scenarios might include situations where an MME was assigned an additional PLMN to serve; it would issue an MME CONFIGURATION UPDATE to all of the eNBs with which it was associated. If the information contained in the update is acceptable to the receiving node it returns the appropriate CONFIGURATION UPDATE ACKNOWLEDGE message. If the information is not acceptable the receiving node returns a CONFIGURATION UPDATE FAILURE message instead.

Further Reading: 3GPP TS36.413:8.74 and 9.1.8.7-12 3.22

© Wray Castle Limited

LT3603/v1

S1 Interface Messages and Procedures

Management Procedures Overload Network Initiated

eNB

OVERLOAD START

MME

OVERLOAD STOP

OVERLOAD START Information Element

Required

Length

Message Type

Mand

Variable

Overload Response

Mand

Variable

Reject all RRC connection establishments for non-emergency MO data transfer Reject all RRC connection establishments for Signalling Permit Emergency Sessions only

Overload

Overload An MME enters Overload state when it has too high a level of signalling traffic for the transmission or processing resources at its disposal. When this occurs the MME’s first step is to reduce the signalling load imposed by new connection attempts by flagging the Overload state to some or all of its associated eNBs. The OVERLOAD START message is used for this purpose. The Overload response field indicates the actions that the eNB is being asked to perform, these include rejecting all UE-initiated RRC requests for non-emergency sessions, rejecting all RRC requests for signalling purposes and finally rejecting all but emergency sessions. When signalling levels are back below the overload threshold the MME will signal a return to normal operation by issuing the OVERLOAD STOP message. Both OVERLOAD START and OVERLOAD STOP are Class 2 EPs and have no required explicit response.

Further Reading: 3GPP TS36.413:8.7.6 and 9.1.8.13/14 LT3603/v1

© Wray Castle Limited

3.23

LTE Radio Access Network

S1 CDMA2000 Tunnelling eNB or Network Initiated

eNB

UPLINK S1 CDMA2000 TUNNELING

MME

DOWNLINK S1 CDMA2000 TUNNELING

DOWNLINK S1 CDMA2000 TUNNELING Information Element

Required

Information Element Message Type

Length

Required Variable Length Mand

MME UE S1AP ID

Mand

4

eNB UE S1AP ID

Mand

3

E-RABs subject to forwarding list

Opt

Variable

E-RAB ID

Mand

4 bits each

DL Transport Layer Address

Mand

1-160 bits each

DL GTP TEID

Mand

4 each

CDMA2000 HO Status

Mand

Variable

CDMA2000 RAT Type

Mand

Variable

CDMA2000 PDU

Mand

Variable

S1 CDMA2000 Tunnelling Procedures

S1 CDMA2000 Tunnelling Procedures The S1 CDMA2000 Tunnelling procedures exist to allow a standard E-UTRAN to be used to provide access an EPC based on non-3GPP core network protocols, specifically those employed by 3GPP2 CDMA2000 networks. As well as listing the E-RABs that are to subject to tunnelling, the messages also provide additional CDMA2000-related information relating to aspects such as Handover Type and RAT type. The messages also encapsulate a CDMA2000 PDU for transmission between the UE and the core network.

Further Reading: 3GPP TS36.413:8.8 and 9.1.8 3.24

© Wray Castle Limited

LT3603/v1

S1 Interface Messages and Procedures

UE Capability Info eNB Initiated

MME

eNB

UE CAPABILITY INFO INDICATION

UE CAPABILITY INFO INDICATION Information Element

Required

Length

Message Type

Mand

Variable

MME UE S1AP ID

Mand

4

eNB UE S1AP ID

Mand

3

UE Radio Capability

Mand

Variable

UE Capability Info Indication

UE Capability Info Indication The Class 2 UE Capability Info Indication EP allows an eNB to provide an MME with details regarding a UE’s Radio Capability. The capabilities indicated include the UE’s ability to access particular RAT (Radio Access Technology) types – E-UTRA, GERAN and CDMA2000-1xRTT – and the band classes supported within each RAT type. UE Radio Capability may also be signalled in the INITIAL UE MESSAGE, so this message type simply offers a standalone method of transferring that information.

Further Reading: 3GPP TS36.413:8.9 and 9.1.10 LT3603/v1

© Wray Castle Limited

3.25

LTE Radio Access Network

Trace Network Initiated

eNB

MME

TRACE START TRACE FAILURE INDICATION CELL TRAFFIC TRACE DEACTIVATE TRACE TRACE START Information Element

Required

Length

Message Type

Mand

Variable

MME UE S1AP ID

Mand

4

eNB UE S1AP ID

Mand

3

Trace Activation

Mand

Variable

E-UTRAN Trace ID Interfaces to be Traced Trace Depth Trace Collection Entity IP Address

Trace

Trace As with similar functions in legacy networks, the EPS Trace facility allows network engineers to request that copies of some or all signalling transactions relating to a particular UE be captured and forwarded to a central point in the network. Generally this process is invoked for diagnostic and troubleshooting purposes and it allows engineers to gather transaction-related data without being required to deploy sniffers or other diagnostics tools in the network. The TRACE START message is sent from the MME to a given eNB and instructs it to begin the Trace procedure for the specified UE. The Trace Activation IE provides details of the type and depth of trace to be performed, the ID to be used for any Trace reports returned and the IP address of the device to which the reports should be sent. If the eNB is unable to initiate the Trace process for a UE – if for example the UE is in the process of being handed over to another cell – it will return a TRACE FAILURE INDICATION specifying the reason for the failure. The Trace session wil continue until either the UE is no longer within the service area of the eNB or the MME signals the end of the Trace session using the DEACTIVATE TRACE message. The Trace procedure outlined above is limited to enabling Trace for one UE per TRACE START message; a separate procedure is employed to initiate Trace for an entire cell. This process is initiated outside of the S1 management environment by an EM (Element Manager). Once initiated, the eNB will transmit a CELL TRAFFIC TRACE message to the MME containing reference number details for each active session and for any new sessions activated after that time. The transmission of Trace Records from the eNB to the Trace Collection Entity occurs outside of the S1AP protocol.

Further Reading: 3GPP TS36.413:8.10 and 32.422 (Trace Procedures) 3.26

© Wray Castle Limited

LT3603/v1

S1 Interface Messages and Procedures

Location Reporting Network Initiated

eNB

MME

LOCATION REPORTING CONTROL LOCATION REPORT LOCATION REPORT FAILURE INDICATION

LOCATION REPORT Information Element

Required

Length

Message Type

Mand

Variable

MME UE S1AP ID

Mand

4

eNB UE S1AP ID

Mand

3

E-UTRAN CGI

Mand

Variable

TAI

Mand

Variable

Request Type

Mand

Variable

Location Reporting

Location Reporting The Location Reporting procedure allows an MME to request a UE’s current location from an eNB. This only works for UEs in ECM-CONNECTED state as they must have an active UE Context for their cell location to be known to an eNB. The procedure is initiated when the MME sends a LOCATION REPORTING CONTROL message to the eNB. As the procedure is related to a specific UE the message includes the eNB UE S1AP ID and MME UE S1AP ID. This initiating message also contains a Request Type, which specifies the type of report the eNB is being asked to send. The options of the this IE are: ƒ Direct – meaning that the eNB reports back the UEs current position immediately ƒ Change of Service Cell – which instructs the eNB to report only when the UE hands over to a new serving cell within those controlled by the eNB ƒ Stop Change of Service Cell – which instructs the eNB to report the UEs location regularly but to stop when it hands over to another cell The level of location detail provided is limited to TAI and Cell ID and is carried back to the MME in a LOCATION REPORT message. If the eNB is unable to perform the required Location Reporting function, for example if the UE is in the process of handing over or is no longer active within a cell controlled by the eNB, it will return a LOCATION REPORT FAILURE INDICATION.

Further Reading: 3GPP TS36.413:8.11 AND 9.1.12 LT3603/v1

© Wray Castle Limited

3.27

LTE Radio Access Network

Warning Messages Network Initiated

eNB

WRITE-REPLACE WARNING REQUEST

MME

WRITE-REPLACE WARNING RESPONSE

WRITE-REPLACE WARNING REQUEST Information Element Information Element Message Type

Required Length Required Length Mand Variable

Message Identifier

Mand

4

Serial Number

Mand

3

Warning Area List

Opt

Variable

Repetition Period

Mand

Variable

No. of Broadcasts Requested

Mand

2

Warning Type

Opt

2

Warning Security Information

Opt

50

Data Coding Scheme

Opt

1

Warning Message Contents

Opt

Variable

Warning Message Transmission

Warning Message Transmission The E-UTRAN supports an extension to the legacy Cell Broadcast system designed to propagate Warning Messages to all UEs in selected cells. This functionality integrates with the E-UTRANs support for the ETWS (Earthquake and Tsunami Warning System) aspects of LTE. If the MME has a new warning message to pass to an eNB is issues it in a WRITE-REPLACE WARNING REQUEST message. As the name suggests, this message type is used to overwrite any warning message that may currently be being broadcast in the target cells; warning message are carried on the air interface in System Information Block Types 10 and 11. When an eNB receives a new warning message it is responsible for paging UEs to inform them that a new warning is being broadcast. The message specifies the period during which the message should be broadcast along with the total number broadcasts that are required. Other information, such as the Warning Type and the area within which it is to be propagated, are optional elements. Once an eNB has written the new warning message to the appropriate System Information Blocks it returns a WRITE-REPLACE WARNING RESPONSE to the MME as confirmation.

Further Reading: 3GPP TS36.413:8.12, 9.1.13 and 22.168 (ETWS Stage 1) 3.28

© Wray Castle Limited

LT3603/v1

S1 Interface Messages and Procedures

Direct Information Transfer eNB or Network Initiated

eNB

MME DIRECT INFORMATION TRANSFER

MME

ENB DIRECT INFORMATION TRANSFER

MME/ENB DIRECT INFORMATION TRANSFER Information Element

Required

Length

Message Type

Mand

Variable

Inter-system Information Transfer Type

Mand

Variable

Direct Information Transfer

Direct Information Transfer The Class 2 Direct Information Transfer procedure allows inter-system information to be conveyed between an E-UTRAN eNB and BSS nodes in a legacy GERAN network via the MME. When initiated by an eNB the message type is ENB DIRECT INFORMATION TRANSFER and when initiated by an MME it is MME DIRECT INFORMATION TRANSFER. In either case the message contains RIM (RAN Information Management) details such as LAI, RAI or CGI which uniquely identify the destination node in the legacy network towards which a function is being performed. It also contains a BSSGP RIM PDU, which carries additional information.

Further Reading: 3GPP TS36.413:8.14, 9.1.14/15 and 36.300:19.2.2.14/15 LT3603/v1

© Wray Castle Limited

3.29

LTE Radio Access Network

Configuration Transfer eNB or Network Initiated

eNB

MME CONFIGURATION TRANSFER

MME

ENB CONFIGURATION TRANSFER

MME/ENB CONFIGURATION TRANSFER Information Element

Required

Length

Message Type

Mand

Variable

SON Configuration Transfer

Opt

Variable

Target eNB-ID Global eNB ID

Mand

Selected TAI

Mand

Source eNB-ID Global eNB ID

Mand

Selected TAI

Mand

SON Information

Mand

SON Information Request SON Information Response

X2 TNL Configuration Info IP address for X2 SCTP End-point

Configuration Transfer

Configuration Transfer The size and complexity of mobile network architecture increases with each new generation. Whereas most first-generation networks launched with a few tens of base stations, modern systems require tens of thousands. The advent of home base station ‘femtocell’ technologies has added to this density and complexity and bringing networks to the brink of unmanagability. The SON (Self Organizing Network) concept aims to reduce the need for overt human intervention in the configuration of basic network organizational activities such as establishing and maintaining neighbour adjacencies between sites. E-UTRAN eNBs can optionally support a function known as ANR (Automatic Neighbour Relation), which allows them to automatically discover new neighbours and establish X2 associations with them. In ANR, if a served UE provides a handover candidates measurement report that contains a Cell ID that was previously unknown to the eNB it can request the UE to gather further details about the site, particularly its full eCGI, its TAC and its list of supported PLMNs. Armed with this information the eNB can send an ENB CONFIGURATION TRANSFER message to the MME including details of the unknown cell and requesting SON details. These take the form of X2 tunnel configuration data, such as the IP address of the unknown site’s X2 SCTP interface. The MME will respond with the required information carried in an MME CONFIGURATION TRANSFER message which contains the requested X2 transport network layer information, namely the IP address of the target eNB’s X2 interface SCTP End-point. With the destination IP address known, the source eNB is able to make contact with the target eNB to begin the X2 establishment process.

Further Reading: 3GPP TS36.413:8.15/16 and 9.1.16/17 3.30

© Wray Castle Limited

LT3603/v1

S1 Interface Messages and Procedures

Section 3 Glossary 3G 3GPP

Third Generation 3rd Generation Partnership Project

AMBR ANR AS

Aggregate Maximum Bit Rate Automatic Neighbour Relation, Access Stratum

BSC BSSGP

Base Station Controller Base Station System GPRS Protocol

CDMA CGI CS CSG

Code Division Multiple Access Cell Global Identity Circuit Switched Closed Subscriber Group

DRX DT

Discontinuous Reception Data Transfer

eCGI EM eNB EPC EPS E-RAB ETWS E-UTRAN

Evolved Cell Global identity Element Manager. Evolved Node B Evolved Packet Core Evolved Packet System E-UTRAN Radio Access Bearer Earthquake and Tsunami Warning System Evolved Universal Terrestrial Radio Access Network

GERAN GSM GTP GTP-C GUMMEI

GSM/EDGE Radio Access Network Global System for Mobile communications GPRS Tunnelling protocol GPRS Tunnelling Protocol – Control plane Globally Unique MME Identifier,

HFN HO

Hyper Frame Number Handover

IE IMSI IP

Information Element International Mobile Subscriber Identity Internet Protocol

LA LAI LTE

Location Area Location Area Identity Long Term Evolution

LT3603/v1

© Wray Castle Limited

3.31

LTE Radio Access Network

MME MS

Mobility Management Entity Mobile Station

NAS

Non Access Stratum

O&M

Operations and Maintenance

PDCP PDU PLMN PS

Packet Data Convergence Protocol Protocol Data Unit, Public Land Mobile Network Packet Switched

QoS

Quality of Service

RAI RAN RANAP RAT RF RIM RNC RRC

Routing Area Identity Radio Access Network Radio Access Network Application Part Radio Access Technology Radio Frequency RAN Information Management Radio Network Controller Radio Resource Control

S1AP SCTP S-GW SN SON SRVCC S-TMSI

S1 Application Protocol. Stream Control Transmission Protocol Serving Gateway Sequence Number Self-Organizing Network Single Radio Voice Call Continuity, SAE TMSI

TAC TAI TEID

Tracking Area Code Tracking Area Identity Tunnel Endpoint ID

UDP UE UTRAN

User Datagram Protocol User Equipment Universal Terrestrial Radio Access Network

3.32

© Wray Castle Limited

LT3603/v1

LTE Radio Access Network

Section 4

X2 Interface Messages and Procedures

© Wray Castle Limited

LTE Radio Access Network

ii

© Wray Castle Limited

LT3603/v1

X2 Interface Messages and Procedures

Contents

X2 Interface Architecture...................................................................................................................... 4.1 X2 Deployment and Routing ................................................................................................................ 4.2 X2 Functional Split ............................................................................................................................... 4.3 X2AP Identities ..................................................................................................................................... 4.4 X2AP Message Structure ..................................................................................................................... 4.5 X2 Functions and Procedures .............................................................................................................. 4.6 X2 Elementary Procedures .................................................................................................................. 4.7 X2 Procedure Modules......................................................................................................................... 4.8 Handover Preparation .......................................................................................................................... 4.9 Handover Preparation Messages ...................................................................................................... 4.10 Handover Preparation Messages (continued) ................................................................................... 4.11 SN Status Transfer............................................................................................................................. 4.12 UE Context Release........................................................................................................................... 4.13 Handover Cancel ............................................................................................................................... 4.14 Load Indication ................................................................................................................................... 4.15 Error Indication ................................................................................................................................... 4.16 X2 Setup............................................................................................................................................. 4.17 Reset .................................................................................................................................................. 4.18 eNB Configuration Update ................................................................................................................. 4.19 Resource Status Reporting Initiation ................................................................................................. 4.20 Resource Status Updates .................................................................................................................. 4.21 LT3603/v1

© Wray Castle Limited

iii

LTE Radio Access Network

iv

© Wray Castle Limited

LT3603/v1

X2 Interface Messages and Procedures

Objectives

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

outline the functions performed by the X2 interface and the protocols it employs

ƒ

discuss the options available for deploying and routing the X2 interface

ƒ

describe the functional spilt that exists between the X2-U and X2-C interface variants

ƒ

describe the basic message structure employed by X2AP messages

ƒ

list the identities employed on X2 interfaces

ƒ

outline the functions and procedures performed by X2AP and list the set of elementary procedures and procedure modules

ƒ

describe the functions of the X2AP message types

LT3603/v1

© Wray Castle Limited

v

LTE Radio Access Network

vi

© Wray Castle Limited

LT3603/v1

X2 Interface Messages and Procedures

X2 Interface eNode B eNode B eNode B

eNode B eNode B

E-UTRAN IP Transport Network

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 LT3603/v1

© Wray Castle Limited

4.1

LTE Radio Access Network

eNB eNB X2 connected directly eNB

eNB

X2 routed via EPC

EPC IP Backbone

EPC Access Router

Logical S1 Logical X2 Physical eNB Transmission

MME

X2 Deployment and Routing

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 EUTRAN 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 4.2

© Wray Castle Limited

LT3603/v1

X2 Interface Messages and Procedures

X2 U-Plane

User PDU GTPv1-U UDP

Each X2-U connection logically exists as a GTP tunnel

IP L2 L1

X2 C-Plane

X2AP E-UTRAN IP Transport Network

SCTP

X2

IP

Each X2-C connection logically exists as an SCTP association

L2 L1

X2 Functional Split

X2 Functional Split As with the S1 interface, the X2 is logically and functionally split into two sub-interfaces; U-plane traffic travels via the X2-U interface, whilst C-plane signalling traffic is carried on the X2-C. The X2-U employs legacy GTPv1-U to encapsulate and transport user data PDUs across GTP tunnels between eNBs. GTPv1-U traffic travels over a UDP/IP connection that does not offer guaranteed delivery; it is assumed that sensitive traffic will be protected by upper layer protocols that do offer retransmission services. Control Plane traffic is handled by X2AP (X2 Application Protocol), which manages handover between eNBs, load and error reporting and other management functions as well carrying E-RAB and GTP tunnel establishment messages. X2AP can be regarded as an evolution of the RNSAP (Radio Network Subsystem Application Part) signalling protocol employed between UMTS RNCs and is carried over SCTP/IP between eNBs. The logical connection between neighbour eNBs is provided via an SCTP Association, with each node’s assigned physical transmission interface acting as the endpoint for those logical links. SCTP can provide guaranteed and sequenced delivery of messages and was specially designed with the needs of signalling transport in mind. IP provides the packet delivery service that operates between E-UTRAN and EPC nodes. For X2 services to work effectively, each eNB needs to be assigned an IP address that is routable from the core network and also from neighbouring eNBs. E-UTRAN and EPC transport network routers then ensure that where possible traffic is routed between communicating nodes.

Further Reading: 3GPP TS36.423 (X2AP), 36.412 (X2 Signalling Transport) LT3603/v1

© Wray Castle Limited

4.3

LTE Radio Access Network

X2-C Target eNB

New eNB UE X2AP ID

Transport Layer Address (IP Address of X2 SCTP Association Endpoint) X2-U

UE identification in X2 messages

Transport Layer Address (IP Address of X2 interface) GTP Tunnel Endpoint ID

Old eNB UE X2AP ID Source eNB

X2 Interface

EPC IP Backbone

X2-C Transport Layer Address (IP Address of X2 SCTP Association Endpoint) X2-U Transport Layer Address (IP Address of X2 interface) GTP Tunnel Endpoint ID

X2AP Identities

X2AP Identities UEs referenced in X2AP messages are explicitly identified by an eNB UE X2AP ID assigned separately by each eNB. This identifier is 12 bits long and is unique within the logical eNB that assigned it, which implies that each eNB can manage a maximum of 4096 UEs that are engaged in X2-related activities. As one eNB will be assigned an ID by both of the eNBs managing its X2-related activity, some X2 message formats specifically identify the ‘old’ and the ‘new’ eNB UE X2AP ID; the ‘old’ is assigned by the source eNB, the ‘new’ by the target. X2 connections themselves are implicitly identified by referencing the connection endpoints and the Global eNB ID of the sites being connected. An X2 Control Plane connection is identified by reference to the Transport Layer Address (i.e. the IP address) of the SCTP Association Endpoint at either end of the link. An X2-U connection is identified by a combination of the Transport Layer Address of the eNB interface and the GTP TEID (Tunnel Endpoint ID) in use at either end. There is no explicit ‘X2 interface’ identifier assigned to each link.

Further Reading: 3GPP TS36.423 (X2AP), 36.401:6.2.1 (eNB UE X2AP ID) 4.4

© Wray Castle Limited

LT3603/v1

X2 Interface Messages and Procedures

X2AP Message

X2AP

SCTP

IP

Typical X2AP Message Format Information Element

Required

Message Type

Mand

Old eNB UE X2AP ID

Mand

New eNB UE X2AP ID

Mand Opt

Mandatory fields

Optional fields

Opt Members of the same conditional group

Cond Cond

Conditional fields, presence determined by optional fields

X2AP Message Structure

X2AP Message Structure X2AP messages are encapsulated within an SCTP/IP packet for transport through the E-UTRAN IP environment. SCTP manages the association between peer nodes and IP is responsible for delivering packets. All X2AP messages begin with a Message Type field, which carries a Procedure Code to specify the function being performed by the message and a Type of Message field to indicate the stage of the process being signalled by the message (Initiating Message, Successful Outcome, Unsuccessful Outcome). Messages that relate to user connections also usually carry the eNB UE X2AP IDs that uniquely identify a particular UE and the E-RAB ID(s) that identify any referenced connections. Each specific message type has its own defined format; message fields are classed as being Mandatory, Optional and Conditional. The presence of Conditional fields is usually determined by the presence or content of one of the Optional fields and may differ from instance to instance of each message type. As is common in 3GPP-defined systems, many of the fields specified for a message type are regarded as Information Elements rather than simple Information Items. Information Elements often have their own defined structure of sub-fields and could be of variable length, Information Items are generally fixed-length fields containing just one piece of data.

Further Reading: 3GPP TS36.423:9 LT3603/v1

© Wray Castle Limited

4.5

LTE Radio Access Network

Mobility Management

Load Management

Error Reporting Source eNB

Target eNB

X2 Reset

X2 Establishment

Configuration Reporting

X2 Functions and Procedures

X2 Functions and Procedures The main functions performed by the X2AP can be summarized as follows: ƒ Mobility Management, which allows neighbouring eNBs to directly manage the process of handing over UEs and their connections directly without intervention from the network. Sequence Number status transfer and the release of old UE Contexts are also handled by this set of functions ƒ Error Reporting, which allows peer eNBs to report message errors to each other ƒ X2 Reset, which allows an eNB to request that the X2 interface to a peer node be reset ƒ X2 Establishment, which allows an eNB to request the establishment or re-establishment of an X2 interface to a neighbour node ƒ Configuration Updating, which allows eNBs with established X2 associations to update their peer nodes when their configuration changes In many case the functions performed by X2 procedures mirror those performed by similar procedures on the S1 interface.

Further Reading: 3GPP TS36.423:7 4.6

© Wray Castle Limited

LT3603/v1

X2 Interface Messages and Procedures

Class 1 EP

Initiating Message

Successful Outcome

Unsuccessful Outcome

Handover Preparation

HANDOVER REQUEST

HANDOVER REQUEST ACKNOWLEDGE

HANDOVER PREPARATION FAILURE

Reset

RESET REQUEST

RESEST RESPONSE

X2 Setup

X2 SETUP REQUEST

X2 SETUP RESPONSE

X2 SETUP FAILURE

eNB Configuration Update

ENB CONFIGURATION UPDATE

ENB CONFIGURATION UPDATE ACKNOWLEDGE

ENB CONFIGURATION UPDATE FAILURE

Resource Status Reporting Initiation

RESOURCE STATUS REQUEST

RESOURCE STATUS RESPONSE

RESOURCE STATUS FAILURE

Class 2 EP

Initiating Message

Load Indication

LOAD INFORMATION

Handover Cancel

HANDOVER CANCEL

SN Status Transfer

SN STATUS TRANSFER

UE Context Release

UE CONTEXT RELEASE

Resource Status Reporting

RESOURCE STATUS UPDATE

Error Indication

ERROR INDICATION

X2 Elementary Procedures

X2 Elementary Procedures As with other 3GPP-specifed signalling protocols, X2AP operates through the use of EPs (Elementary Procedures). An EP is classed as a ‘unit of interaction’ between peer eNBs and it represents the sending or receiving of a message or the exchange of a message and a response. Class 1 EPs are messages that require a response – either a ‘success’ or a ‘failure’ notification. Class 1 message types start with an Initiating Message and require a response that unambiguously indicates either a Successful Outcome or an Unsuccessful Outcome. Class 2 EPs are messages that do not require an explicit response, although they may trigger another procedure which in turn provides an implicit response to the original message.

Further Reading: 3GPP TS36.423:8 LT3603/v1

© Wray Castle Limited

4.7

LTE Radio Access Network

X2 Procedures Handover Preparation SN Status Transfer

Basic Mobility UE Context Release Handover Cancel Load Management Error Indication

Global Procedures Reset X2 Setup eNB Configuration Update

X2 Procedure Modules

X2 Procedure Modules X2 Procedures are categorized according to the module to which they belong: the modules are Basic Mobility and Global Procedures. Basic Mobility EPs manage the function related to UE mobility and E-RAB handover. Global Procedures EPs are concerned with the overall management of entire X2 interfaces rather than with the management of individual UEs and their E-RABs. In most cases only one X2AP EP per UE is permitted to be in progress at a time, there are few opportunities for parallel transactions to take place.

Further Reading: 3GPP TS36.423:5.1 4.8

© Wray Castle Limited

LT3603/v1

X2 Interface Messages and Procedures

Basic Mobility Handover Preparation Source eNB Initiated

Source eNB

HANDOVER REQUEST HANDOVER REQUEST ACKNOWLDGE

Target eNB

HANDOVER PREPARATION FAILURE

Handover Preparation

Handover Preparation As the E-UTRAN has no equivalent node to the BSC/RNC employed in legacy networks, handover procedures are initiated by individual eNBs. If a logical X2 interface exists between source and target eNBs, in the case of intra-E-UTRAN handovers, the Handover process can be managed directly by the eNBs involved and S1 signalling is only required once the Handover has been effected. Once a UE and its serving eNB have decided that a Handover is required the eNB determines whether an X2 interface exists to the eNB that controls the Target Cell. If an X2 interface exists, the source eNB initiates the Handover Preparation process by transmitting a HANDOVER REQUEST message to the target eNB. The target eNB begins the process of resource reservation and allocation for the UEs current set of E-RABs. If resources are available in the target cell the target eNB responds with HANDOVER REQUEST ACKNOWLEDGE detailing the resource reservation that has been made for the UE in the target cell. The source eNB forwards the RRC-related data to the UE. At the point that the source eNB decides to cease downlink transmission and uplink reception for the UE it issues an SN STATUS TRANSFER towards the target eNB containing the current Uplink and Downlink PDCP SN (Sequence Number) and the HFN (Hyper Frame Number) applicable to the UE Context. Once the UE successfully synchronizes with the reserved resources in the new cell it contacts the target eNB which forwards a UE CONTEXT RELEASE message to the MME. The source eNB can abort the handover process at any time by issuing a HANDOVER CANCEL message.

Further Reading: 3GPP TS36.423:8.2.1, 91.1.1.-3 and 23.401:5.5.1.1 (X2-based Handover) LT3603/v1

© Wray Castle Limited

4.9

LTE Radio Access Network

Basic Mobility Handover Preparation Source eNB Initiated

Assigned by Source eNB

HANDOVER REQUEST Information Element

Required

Length

Message Type

Mand

Variable

Old eNB UE X2AP ID

Mand

12 bits

Cause

Mand

Variable

Target Cell ID

Mand

28 bits

GUMMEI

Mand

6

UE Context Information

Mand

MME UE S1AP ID

Mand

4

UE Security Capabilities

Mand

1

AS Security Information

Mand

12 bits

UE AMBR

Mand

Variable

Subs Profile for RAT/Frequency Priority

Opt

1

Message Type = 0 Handover Preparation

E-RABs to be setup list

Last Visited Cells Information

E-RAB ID

Mand

4 bits each

E-RAB level QoS

Mand

Variable

DL Forwarding

Opt

Variable

UL GTP Tunnel Endpoint

Mand

Variable

RRC Context

Mand

Variable

Handover Restriction List

Opt

Variable Variable

Location Reporting Information

Opt

For E-UTRAN, UTRAN, GERAN cells

UE History Information

Mand

Variable

Cell ID, Cell Type, Time Spent in Cell

Trace Activation

Opt

Variable

SRVCC Operation Possible

Opt

Variable

Handover Preparation Messages

Handover Preparation Messages The HANDOVER REQUEST message issued by the source eNB and all other Handover Preparation messages share the same Message Type (0). As the Request deals with the handover of the UE Context and active E-RABs belonging to one specific UE, the message must contain the source eNB’s current eNB UE X2AP ID for the terminal. This is classed as the ‘old’ UE ID. A Cause code specifies the reason for the procedure; relevant causes for Handovers include Handover Desirable for Radio Reasons and Resource Optimization Handover. The Target Cell ID element indentifies the cell within the set controlled by the target eNB towards which the handover is being initiated, and the GUMMEI element identifies the MME that is currently serving the UE. Information relating to the source cell’s UE Context also needs to be transferred, this specifies the MME UE S1AP ID used to identify the UE to the MME on the S1 interface, the UE’s security capabilities and security information relative to the Access Stratum. The UE’s assigned QoS Aggregate Maximum Bit rate is also flagged. The source eNB transmits a list of the set of E-RABs currently active for the UE, which includes the ERAB ID, its QoS level and details of the GTP TEID at the S-GW to which user traffic is being sent. The source eNB may optionally also propose the invocation of Downlink Forwarding of traffic between the source and target eNBs; this allows traffic to continue to flow on the ‘old’ Downlink path to the source eNB after the handover has been completed but while the target eNB is arranging a Path Switch. Any traffic received at the source eNB during this period is then forwarded via the X2 for delivery to the UE by the ‘new’ cell. The RRC Context IE contains details of the UE’s radio capabilities (e.g. the RAT types it can access) and the current radio resource configuration assigned to the UE. An optional Handover Restriction List carries details of any RAT types, PLMNs, TAs or LAs into which the UE is forbidden to roam.

Further Reading: 3GPP TS36.423:8.2.1 and 9.1.1.1-3 4.10

© Wray Castle Limited

LT3603/v1

X2 Interface Messages and Procedures

Basic Mobility Handover Preparation Source eNB Initiated

HANDOVER REQUEST ACKNOWLEDGE Information Element

Required

Length

Message Type

Mand

Variable

Assigned by Source eNB

Old eNB UE X2AP ID

Mand

12 bits

Assigned by Target eNB

New eNB UE X2AP ID

Mand

12 bits

E-RABs Admitted List

Mand

Transport Layer Address and GTP TEID

E-RAB ID

Mand

4 bits each

UL GTP Tunnel Endpoint

Mand

Variable

DL GTP Tunnel Endpoint

Mand

Variable

E-RABs Not Admitted List

Mand

E-RAB ID

Mand

Variable

Target eNB to Source eNB Transparent Container

Mand

Variable

Criticality Diagnosis

Opt

Variable

Message Type = 0 Handover Preparation

Handover Preparation Messages (continued)

Handover Preparation Messages (continued) The HANDOVER REQUEST Location Reporting Information field allows any existing reporting instructions to be passed to the new cell and the UE History Information field allows details of the UE’s lasted visited E-UTRAN/GERAN/UTRAN cells to be passed on. The optional Trace Activation field provides details of whether any Trace conditions have been set for the UE and the SRVCC Operation Possible field indicates the UE’s capability to use the handover capabilities of SRVCC. In response the target eNB will send either a HANDOVER REQUEST ACKNOWLDGE message, if the Handover Request is accepted, or a HANDOVER PREPARATION FAILURE message if the Handover cannot proceed. A Cause code will identify the reason for the Failure. The HANDOVER REQUEST ACKNOWLEDGE message provides details of the identifiers and resources assigned to the UE in the target cell, starting with the New eNB UE X2AP ID, which will have been generated by the target eNB and uniquely identifies the UE within that node. Details of each current E-RAB that has been ‘admitted’ (accepted for Handover) are provided along with the GTP TEIDs they will use. If the target eNB determines that specific existing E-RABs cannot be admitted it will flag the E-RAB IDs of these too. A Transparent Container carries details of the radio resources assigned to the UE in the new cell, as the name suggests these details pass transparently through the source eNB and are delivered to the UE to allow it t prepare to make the jump to the new cell. Finally, a Criticality Diagnosis field is used to provide feedback on any errored message elements or on anomalous events.

Further Reading: 3GPP TS36.413:8.2.1 and 9.1.1.1-3 LT3603/v1

© Wray Castle Limited

4.11

LTE Radio Access Network

Basic Mobility SN Status Transfer Source eNB Initiated

Source eNB

SN STATUS TRANSFER

Target eNB

SN STATUS TRANSFER Information Element

Required

Length

Message Type

Mand

Variable

Old eNB UE X2AP ID

Mand

12 bits

New eNB UE X2AP ID

Mand

12 bits

E-RABs Subject to Status Transfer List

Mand

E-RAB ID

Mand

4 bits each

Receive Status of UL PDCP SDUs

Opt

12 bits each

UL Count value

Mand

4 each

DL Count value

Mand

4 each

Message Type = 4 SN Status Transfer

SN Status Transfer

SN Status Transfer The SN STATUS TRANSFER message is employed to carry PDCP (Packet Data Control Protocol) sequence number information from the source eNB to the target node. The message is initiated when the source node stops assigning PDCP Sequence Numbers for Downlink SDUs and stops passing received Uplink SDU on to the core network and contains details of the RX/TX parameters and states frozen at that point in time. For each E-RAB to be transferred to the new cell the message carries details that can be used to restart the flow of PDCP SDUs in the new cell from the point at which transmission was frozen. The target eNB can begin transmission of E-RAB traffic to the UE following one of two triggers; either the source and target eNBs agreed to implement X2 forwarding to carry traffic delivered via the ‘old’ S1 path or the target eNB has completed the Path Switch procedure with the MME and traffic is being delivered via the ‘new’ S1 path.

Further Reading: 3GPP TS36.423:8.2.2 and 9.1.1.4 4.12

© Wray Castle Limited

LT3603/v1

X2 Interface Messages and Procedures

Basic Mobility UE Context Release Target eNB Initiated

Source eNB

UE CONTEXT RELEASE

Target eNB

UE CONTEXT RELEASE Information Element

Required

Length

Message Type

Mand

Variable

Old eNB UE X21AP ID

Mand

12 bits

New eNB UE X2AP ID

Mand

12 bits

Message Type = 5 UE Context Release

UE Context Release

UE Context Release The Class 2 UE Context Release EP is used to provide implicit confirmation that the handover process has completed successfully and instructs the source eNB to release any radio and S1 C-plane resources reserved for the handover UE. This process does not, however, necessarily trigger the immediate purging of UE Context data in the source eNB. Once the handover UE has notified the target eNB that it has successfully activated the new radio resources, the target eNB informs the source node to release UE Context resources. If Downlink Forwarding was invoked for the handover then the source eNB may still be receiving DL traffic destined for the UE for the period of time it takes the target eNB to arrange a Path Switch with the network. DL Downlink Forwarding can be maintained even if the S1-MME relationship for the UE has been released as the DL data stream contains its own Marker packets to indicate when the end of the stream has been reached; reception of the Marker packets indicates to the source eNB that DL Forwarding can be discontinued and any remaining X2 resources are released. During and immediately after a handover, the source eNB retains a copy of the UE Context to allow the UE to hand back if services in the new cell are unusable. After UE Context Release and the end of any DL Forwarding the UE and the source eNB may purge any remaining ‘old’ UE Context details. It is suggested that at least some UE Context data (the C-RNTI that identifies the UE within the source eNB, for example) is retained for a short period after the context release in case the UE signals a need to hand back to old cell.

Further Reading: 3GPP TS36.300:10.1.2.1, 36.423:8.2.3 and 9.1.1.5 LT3603/v1

© Wray Castle Limited

4.13

LTE Radio Access Network

Basic Mobility Handover Cancel Source eNB Initiated

Source eNB

HANDOVER CANCEL

Target eNB

HANDOVER CANCEL Information Element

Required

Length

Message Type

Mand

Variable

Old eNB UE X21AP ID

Mand

12 bits

New eNB UE X2AP ID

Opt

12 bits

Cause

Mand

Variable

Message Type = 1 Handover Cancel

Handover Cancel

Handover Cancel When a source eNB initiates the Handover process by transmitting a HANDOVER REQUEST to an X2 neighbour, it starts timer TRELOCprep. If the timer expires before a HANDOVER REQUEST ACKNOWLEDGE or HANDOVER PREPARATION FAILURE response is received from the target eNB the process is cancelled and the source node sends HANDOVER CANCEL to its peer. Other reasons for cancelling a Handover exist and the exact cause will be flagged in the appropriate message field. If the Handover is being cancelled after the target eNB has responded to the original Request, the source device will know the New UE X2AP ID assigned by the target cell and can insert this into the Handover Cancel message; if the Handover is cancelled before the target node responds then this information will not be known and is not required in the Cancel message. If a Handover Cancel is required the source eNB (and the target node, if the process has commenced at the destination end) will purge all details related to the Handover and release any resources assigned to support the Handover.

Further Reading: 3GPP TS36.423:8.2.4 and 9.1.1.6 4.14

© Wray Castle Limited

LT3603/v1

X2 Interface Messages and Procedures

Global Procedures Load Indication eNB to Neighbour eNB

eNB 1

LOAD INFORMATION

eNB 2

LOAD INFORMATION

eCGI of source cell sending the indication

HII for each cell in the target eNB that is to be notified DL TX Power per Physical Resource Block in source cell

Information Element

Required

Length

Message Type

Mand

Variable

Cell Information

Mand

Cell ID

Mand

6½

UL Interference Overload Indication

Opt

Variable

Message Type = 2 Load Indication

UL High Interference Information List Target Cell ID

Mand

6½ each

UL High Interference Indication

Mand

110 bits each

Relative Narrowband TX Power

Opt

Variable

Load Indication

Load Indication The Class 2 Load Indication EP allows an eNB to provide load and interference feedback to local eNBs that control intra-frequency neighbouring cells. As this is applicable only to intra-frequency neighbours it is a process that will generally only be invoked in Single Frequency Networks. The Indication is carried in the LOAD INDICATION message detailing the levels of uplink interference detected by the source eNB but generated by traffic in the target eNB’s cells. The Indication contains a separate section for each source eNB cell that is reporting its load state. The optional UL Interference Overload Indication IE provides details of the general level of interference experienced by each of the source cell’s Uplink PRBs (Physical Resource Blocks); the indication is given in the form of an enumerated list related to values of high interference, medium interference and low interference. The message may also optionally include an UL HII (High Interference Information) list, which allows HII indications to be directed at particular cells within the target eNB. The UL High Interference Indication IE, which is the information directed at the target cell, carries a simple bit map. Each bit position relates to a PRB in the source cell; bit positions set to 1 indicate PRBs that are experiencing high interference levels, whilst bit positions set to 0 indicate PRBs experiencing low interference levels. An eNB that receives a Load indication message would be expected to take the information into account when scheduling uplink resources, especially to UEs in edge-of-cell areas adjacent to the cell that reported the overload or HII conditions. The Indication message may also optionally carry an RNTP (Relative Narrowband TX Power) IE, which provides a simple bit map that indicates whether each PRB is being transmitted at below the advertised RNTP Threshold value or whether ‘no promises’ are made regarding the PRB’s adherence to the RNTP value. This again helps the target eNB with edge-of-cell scheduling. Further Reading: 3GPP TS36.423:8.3.1 and 9.1.2.1 LT3603/v1

© Wray Castle Limited

4.15

LTE Radio Access Network

Global Procedures Error Indication eNB to Neighbour eNB

eNB 1

ERROR INDICATION

eNB 2

ERROR INDICATION Information Element

Required

Length

Message Type

Mand

Variable

Old eNB UE X2AP ID

Opt

12 bits

New eNB UE X2AP ID

Opt

12 bits

Cause

Opt

Varible

Criticality Diagnosis

Opt

Variable

Message Type = 3 Error Indication

Error Indication

Error Indication The set of X2AP EPs includes standalone Error Indications which allow errors in received messages to be reported but are only required if the errored message type has no failure indication of its own; for example, a error in a received HANDOVER REQUEST message can be reported in a returned HANDOVER PREPARATION FAILURE, whereas an error in a Class 2 UE CONTEXT RELEASE message would require a standalone ERROR INDICATION to be returned. The only mandatory field in the ERROR INDICATION message is Message Type; optional extra details such as X2AP IDs and Cause and Criticality Diagnosis fields may be added. Criticality Diagnosis information is used to provide further details regarding an error or failure. It can, for example, indicate the Procedure Code of the errored message by flagging its Message Type or the exact IE that caused a failure. ERROR INDICATION is a Class 2 EP and has no required response.

Further Reading: 3GPP TS36.423:8.3.2 and 9.1.2.2 4.16

© Wray Castle Limited

LT3603/v1

X2 Interface Messages and Procedures

Global Procedures X2 Setup eNB to Neighbour eNB

X2 SETUP REQUEST

eNB 1

eNB 2

X2 SETUP RESPONSE X2 SETUP FAILURE

X2 SETUP REQUEST

eNB ID of source eNB

Information Element

Required

Length

Message Type

Mand

Variable 5½

Global eNB ID

Mand

Served Cells List

Mand

source eNB cell info

Served Cell Information

Mand

source eNB neighbour info

Neighbour Information

Opt

Variable

eCGI

Mand

6½ each

Identifies MME Groups with which eNB is associated

Message Type = 6 Setup

X2

PCI (Physical Cell ID) Cell ID

Variable

PCI

Mand

9 bits each

EARFCN

Mand

Variable

GU Group ID List

Mand

GU Group ID

Mand

TAC Broadcast PLMNs UL/DL EUARFCN UL/DL Transmission Bandwidth Subframe details UL/DL Cyclic Prefix Number of Antenna Ports (MIMO)

5

X2 Setup

X2 Setup The X2 Setup process is used to initially establish (or to re-establish) the X2 relationship between neighbouring eNBs. The process is followed when an eNB is made aware of the presence of a new neighbour. In networks that support the SON concept, notification of new neighbours can be handled automatically by Automatic Neighbour Relation processes or can alternatively be handled by O&M or commissioning procedures. The X2 SETUP REQUEST contains relevant information to allow the target eNB to determine the identity of the source eNB and the configuration of the cells that it supports. RF layer information such as each cell’s PCI (Physical Cell ID), its UL and DL EARFCN (Evolved Absolute Radio Frequency Channel Number) assignments and its channel bandwidth are signalled as are higher layer administrative details such as the cell’s Cell ID, TAC and the PLMNs it serves. The Request may optionally also include details of the E-UTRAN neighbour list (only containing details of direct neighbours not ‘neighbours of neighbours’) compiled by the source eNB and must include details of the GU (Globally Uniqiue) MME Groups with which it is associated. If an eNB receives an X2 Setup Request from a neighbour with which it has an existing association the details of the interface will be reset, the existing association will be deleted and a new instance of the X2 interface will be created. If the target eNB is able to establish an association with the source node it returns an X2 SETUP RESPONSE, which provides the same types of information as that supplied by the source eNB in the original Request plus a Criticality Diagnosis IE which will detail any incompatibilities between the cell configurations. If the target eNB cannot establish an association with the source eNB it will return an X2 SETUP FAILURE message containing a Cause code and optionally also a Time to Wait IE, which specifies how long the source eNB must wait before reattempting the X2 Setup process. Further Reading: 3GPP TS36.423:8.3.3 and 9.1.2.3-5 LT3603/v1

© Wray Castle Limited

4.17

LTE Radio Access Network

Global Procedures Reset eNB to Neighbour eNB eNB 1

RESET REQUEST

eNB 2

RESET RESPONSE

RESET REQUEST Information Element

Required

Length

Message Type

Mand

Variable

Cause

Mand

Variable

Message Type = 7 Reset

Reset

Reset The RESET command is a Global Procedure that is be used to reset the X2 interface between two eNBs. The command is used in response to abnormal failure situations in the initiating eNB. The Cause IE indicates the reason for the reset; of the many cause values supported common causes for resets could include Hardware Failure or O&M Intervention. Reset is a Class 1 EP and requires a RESET RESPONSE to be returned by the receiving device which can optionally contain a Criticality Diagnosis IE.

Further Reading: 3GPP TS36.423:8.3.4 and 9.1.2.6/7 4.18

© Wray Castle Limited

LT3603/v1

X2 Interface Messages and Procedures

Global Procedures eNB Configuration Update eNB to Neighbour eNB

ENB CONFIGURATION UPDATE

eNB 1

eNB 2

ENB CONFIGURATION UPDATE ACKNOWLEDGE ENB CONFIGURATION UPDATE FAILURE ENB CONFIGURATION UPDATE Information Element

Required

Length

Message Type

Mand

Variable

Served Cell Information

Mand

Variable

Neighbour Information

Mand

Variable

Served Cells to Add List Source and Neighbour cell info as in X2 Setup Request

Message Type = 8 eNB Configuration Update

Served Cells to Modify List

Source and Neighbour cell info as in X2 Setup Request

Old eCGI

Mand

6½ each

Served Cell Information

Mand

Variable

Neighbour Information

Mand

Variable

Mand

6½ each

Mand

5 each

Mand

5 each

Served Cells to Delete List Old eCGI New MME Groups joined

GU Group to Add List GU Group ID

Old MME Groups left

GU Group ID to Delete List GU Group ID

eNB Configuration Update

eNB Configuration Update The eNB Configuration Update message carries essentially the same information as is exchanged in the X2 SETUP REQUEST/RESPONSE procedure and is designed to carry updates between peer eNBs if any of their application-level configuration details change. If an eNB is reconfigured to support an additional cell, for instance, it would update its set of X2 peers by transmitting ENB CONFIGURATION UPDATEs to each of them. Other usage scenarios might include situations where an eNB detected a new directly connected neighbour or if it become associated with a new MME GU Group. The Update process is also invoked for Modifications to existing configurations or for deletions of cells or MME GU Groups. If the information contained in the update is acceptable to the receiving node it returns an ENB CONFIGURATION UPDATE ACKNOWLEDGE message. If the information is not acceptable the receiving node returns an ENB CONFIGURATION UPDATE FAILURE message instead.

Further Reading: 3GPP TS36.423:8.3.5 and 9.1.2.8-10 LT3603/v1

© Wray Castle Limited

4.19

LTE Radio Access Network

Global Procedures Resource Status Reporting eNB to Neighbour eNB

RESOURCE STATUS REQUEST eNB 1

eNB 2

RESOURCE STATUS RESPONSE RESOURCE STATUS FAILURE

RESOURCE STATUS REQUEST Information Element

Required

Length

Message Type

Mand

Variable

eNB 1 Measurement ID

Mand

12 bits

eNB 2 Measurement ID

Cond

12 bits

Start or Stop

Registration Request

Mand

Variable

Only required for ‘start’ requests

Report Characteristics

Cond

4

Cell to Report List

Mand

Cell ID

Mand

6½ each

Reporting Periodicity

Opt

Variable

Only required for ‘stop’ requests

Message Type = 9 Resource Status Reporting Initiation

Resource Status Reporting Initiation

Resource Status Reporting Initiation This procedure allows an eNB to control the reporting of resource status by an X2 peer. Reporting is initiated by sending a RESOURCE STATUS REQUEST message. The source eNB (eNB 1) will generate an eNB Measurement ID (with possible values between 1 and 4095) for the relationship to allow it keep track of multiple measurement processes; after receiving a Request from a peer eNB a target eNB (eNB 2) will generate its own Measurement ID. The Registration Request IE can be set to either Start or Stop. The conditional Report Characteristics IE is only required for ‘Start’ requests and provides details of the specific types of measurement report that eNB1 wishes to receive from eNB2. These include radio Resource Status and S1 TNL (Transport Network Layer) Load and Hardware Load indicators. eNB1 must also specify which of the target site’s cells are required to report. The purpose of gathering neighbour measurement reports of this kind is to aid the handover decision-making process; knowing the current load levels of neighbour cells allows a source eNB to determine whether a Handover Request is likely to be successful or not. The Cells to Report list is therefore necessary as a source eNB will only require information related to direct neighbour cells that may be handover candidates for active UEs. The Reporting Periodicity IE determines how often the reports are generated which options of 1s, 2s, 5s and 10s. If eNB2 is able to initiate measurement reporting it generates an eNB2 Measurement ID and returns it to eNB1 in a RESOURCE STATUS RESPONSE message. If eNB2 is unable to initiate measurement reporting it returns a RESOURCE STATUS FAILURE message containing a Cause code of ‘Measurements Temporarily not Available’. The Request is a one way process and initiates reporting from eNB2 to eNB1; if the target eNB also requires reports it must initiate a reporting cycle of its own from its peer.

Further Reading: 3GPP TS36.423:8.3.6 and 9.1.2.11-13 4.20

© Wray Castle Limited

LT3603/v1

X2 Interface Messages and Procedures

Global Procedures Resource Status Reporting eNB to Neighbour eNB

RESOURCE STATUS UPDATE eNB 1

eNB 2

RESOURCE STATUS UPDATE Information Element

Required

Length

Message Type

Mand

Variable

eNB 1 Measurement ID

Mand

12 bits

eNB 2 Measurement ID

Mand

12 bits

Mand

6½ each

Message Type = 10 Resource Status Reporting

Cell Measurement Result List Cell ID LowLoad, MediumLoad, HighLoad, Overload UL/DL GBR/non-GBR PRB usage

Hardware Load Indicator

Opt

Variable

S1 TNL Load Indicator

Opt

Variable

Radio Resource Status

Opt

Variable

Resource Status Updates

Resource Status Updates RESOURCE STATUS UPDATE messages carry measurement reports from eNB2 to eNB1 once a reporting cycle has been established. Measurement reports are tagged with the Measurement IDs relevant to both peer eNBs and contain one Cell Measurement Result report per requested cell. The Cell Measurement Result report identifies the Cell ID of the reported cell along with three optional fields. Hardware Load Indicator provides an enumerated result with four possible values – LowLoad, MediumLoad, HighLoad and Overload. The same values are signalled for the S1 TNL Load Indicator field. The Radio Resource Status IE carries bit maps that indicate the utilization of Uplink and Downlink PRBs: UL and DL GBR (Guaranteed Bit Rate) PRB usage, UL and DL non-GBR PRB usage and UL and DL Total PRB Usage. If a PRB is in use carrying a connection with a GBR QoS assignment the PRB’s position in the appropriate bit map will be set to 1, it will also be set in the Total usage bit map. The Resource Status Update provides a receiving eNB with a snapshot of the type, level and distribution of UL and DL traffic in the neighbour cell, which is used to help it evaluate its own resource scheduling and handover management activities.

Further Reading: 3GPP TS36.423:8.3.7 and 9.1.2.14 LT3603/v1

© Wray Castle Limited

4.21

LTE Radio Access Network

4.22

© Wray Castle Limited

LT3603/v1

X2 Interface Messages and Procedures

Section 4 Glossary 3G 3GPP

Third Generation Third Generation Partnership Project

BSC

Base Station Controller

C-RNTI CS

Controlling Radio Network Temporary Identifier Circuit Switched

DL

Downlink

EARFCN eNB EP EPC E-RAB E-UTRAN

Evolved Absolute Radio Frequency Channel Number Evolved Node B Elementary Procedure Evolved Packet Core E-UTRAN Radio Access Bearer Evolved Universal Terrestrial Radio Access Network

GBR GTP GU GUMMEI

Guaranteed Bit Rate GPRS Tunnelling Protocol Globally Unique Globally Unique MME Identifier,

HFN HII IE

Hyper Frame Number) High Interference Information Information Element

IP

Internet Protocol

LA LTE

Location Area Long Term Evolution

MME

Mobility Management Entity

PCI PDCP PDU PLMN PRB PS

Physical Cell ID Packet Data Control Protocol Protocol Data Unit Public Land Mobile Network Physical Resource Block Packet Switched

QoS

Quality of Service

LT3603/v1

© Wray Castle Limited

4.23

LTE Radio Access Network

RAT RNC RNSAP RNTP RRC

Radio Access Technology Radio Network Controller Radio Network Subsystem Application Part Relative Narrowband Radio Resource Control

S1AP SCTP SDU S-GW SN SON SRVCC

S1 Application Protocol Stream Control Transmission Protocol Service Data Unit Signalling Gateway Sequence Number Self-Organizing Network Single Radio Voice Call Continuity

TA TAC TEID TNL

Tracking Area Tracking Area Code Tunnel Endpoint S1 TNL Load Indicator

UDP UE UL UMTS

User Datagram Protocol User Equipment Uplink Universal Mobile Telecommunications System

X2AP

X2 Application Protocol

4.24

© Wray Castle Limited

LT3603/v1

LTE Radio Access Network

Section 5

Supporting Protocols and Technologies

© Wray Castle Limited

LTE Radio Access Network

ii

© Wray Castle Limited

LT3603/v1

Supporting Protocols and Technologies

Contents EPS Major Protocols ............................................................................................................................ 5.1 IETF Dependencies ............................................................................................................................. 5.2 Transport Layer Options ...................................................................................................................... 5.3 Disadvantages of TCP ......................................................................................................................... 5.4 SCTP (Stream Control Transmission Protocol) ................................................................................... 5.5 SCTP Functions ................................................................................................................................... 5.6 SCTP Concepts ................................................................................................................................... 5.7 3GPP Protocols .................................................................................................................................... 5.8 Legacy GTP ......................................................................................................................................... 5.9 GTP in the EPS .................................................................................................................................. 5.10 GTPv2-C Packet Header ................................................................................................................... 5.11 GTPv2-C Message Types .................................................................................................................. 5.12 GTPv2-C Messages Related to E-UTRAN Connections ................................................................... 5.13 GTPv2-C Create Session Procedure ................................................................................................. 5.14 GTPv2-C Create Bearer Procedure ................................................................................................... 5.15 GTPv2-C Release Access Bearers Procedure .................................................................................. 5.16 GTPv2-C Downlink Data Notification Procedure ............................................................................... 5.17 GTPv1-U Packet Header ................................................................................................................... 5.18 GTPv1-U Message Types .................................................................................................................. 5.19 LT3603/v1

© Wray Castle Limited

iii

LTE Radio Access Network

iv

© Wray Castle Limited

LT3603/v1

Supporting Protocols and Technologies

Objectives

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

list some of the important protocols that support the operation of the main E-UTRAN protocols

ƒ

outline the split between IETF and 3GPP protocols employed in the E-UTRAN

ƒ

describe the need for a Layer 4 protocol other than TCP to protect signalling traffic

ƒ

outline the functions performed by SCTP and its relevance to E-UTRAN operations

ƒ

describe the functions of legacy GTP versions 0 and 1

ƒ

outline the basic structure of a GTPv2-C message

ƒ

discuss the set of GTPv2-C Mobility Management messages used to support E-UTRAN functions

ƒ

describe the functions of a subset of GTPv2-C procedures

ƒ

outline the structure of GTPv1-U messages

ƒ

list the basic set of GTPv1-U procedures

LT3603/v1

© Wray Castle Limited

v

LTE Radio Access Network

vi

© Wray Castle Limited

LT3603/v1

Supporting Protocols and Technologies

EPS

IETF

3GPP

EPS Major Protocols

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 LT3603/v1

© Wray Castle Limited

5.1

LTE Radio Access Network

IETF

SDP

RTCP RTP

SIP

UDP

Diameter

SCTP IPv4/IPv6

TCP DiffServ

Mobile IP

Underlying Transport

IETF Dependencies

IETF Dependencies 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 5.2

© Wray Castle Limited

LT3603/v1

Supporting Protocols and Technologies

Real time, delay intolerant but loss tolerant traffic

Non-real time, delay tolerant but loss intolerant traffic

Connection-oriented reliable retransmissions

Connectionless unreliable no retransmissions

UDP

TCP IPv4/IPv6

Transport Layer Options

Transport Layer Options In the layered architecture employed by IP-based systems, IP itself operates at the network layer (layer 3) and performs packet creation, addressing and routing functions. IP is classed as an unreliable protocol as it has no mechanism for ensuring that packets are delivered and no means of requesting a retransmission if a packet is lost. Packet sequencing and delivery guarantees are the responsibility of the transport layer (layer 4). Traditionally, the IP protocol suite offered two options for use at the Transport Layer: UDP and TCP. UDP was designed to operate in a ‘connectionless’ manner, which sees no correspondence between successive packets transmitted by a host. Instead of an ongoing stream of data travelling over a connection, UDP only recognizes individual packets and has no mechanism for tracking their delivery. UDP is sometimes referred to as a ‘fire and forget’ protocol. Conversely, TCP was designed to operate in a complex, ‘connection-oriented’ manner. It employs a sophisticated feedback mechanism between transmitting and receiving nodes which ensures that outof-sequence data can be reordered and that missing packets can be retransmitted. UDP is employed on connections where there is either no opportunity to retransmit missing data (such as a connection carrying a real-time voice service) or where retransmission is handled by an upper layer protocol. In both cases UDP provides a fast and simple transport layer service. TCP is employed on connections where speed of delivery is less important than guaranteed delivery and is usually employed to carry non-real-time traffic for web browsing and e-mail applications. UDP is employed on most user plane interfaces in the EPS. TCP is an option for some signalling and control interfaces in the EPS, but the preferred layer 4 protocol for these is SCTP.

LT3603/v1

© Wray Castle Limited

5.3

LTE Radio Access Network

M3UA

M3UA

Message 3

Streamed

Message 2 Message 1

Streamed

TCP

Message 3

Message 2

Message 1

TCP

ƒ single connection ƒ streamed data

X

ƒ head-of-line blocking ƒ adaptive transmission timers ƒ MTU (Maximum Transmission Unit)

push

Corrupted

Disadvantages of TCP

Disadvantages of TCP Although it has proved enormously resilient in carrying most types of IP traffic, TCP has demonstrated some distinct disadvantages when carrying signalling and control traffic. TCP employs a ‘byte-oriented’ stream interface which ignores the message structure of the data it is carrying and treats all data as a stream of bytes to be transferred. TCP does not segment data based on the length or structure of the individual messages being passed to it by the higher-layer applications it is serving. In order to reconstitute messages, higher-layer applications must insert control markings to delineate messages for the peer higher layer before passing the data to TCP, which adds to the complexity of the application and the ratio of overhead to data being carried. Additionally, the single session that is generally established between TCP peers and the strictly controlled sequencing and acknowledgement mechanism for data exchange can cause a problem known as ‘head-of-line blocking’. Head-of-line blocking means that, in the event of a retransmission being required, no further data can be sent until a valid copy of a data segment that requires retransmission has been successfully received and acknowledged. This means that data that requires retransmission, but that may not itself be part of a time-critical message, will hold back all following data, some of which may be time-critical This situation is exacerbated if the application only requires TCP’s byte sequencing functionality but not its reliable delivery mechanism. The SS7 (Signalling System no. 7) messages used in PSTN networks are typical of data types that have been seen to suffer from transmission over TCP for the reasons stated above. To overcome these issues, SCTP has been proposed as an alternative layer 4 system that could more reliably transfer signalling and control data across IP-based connections.

Further Reading: IETF RFC768 (UDP), RFC793 (TCP); 3GPP TS 23.401 5.4

© Wray Castle Limited

LT3603/v1

Supporting Protocols and Technologies

M3UA

M3UA

Message 3

Message by Message

Message 2 Message 1 Message by Message Streamed Sequenced delivery within streams User data fragmentation

SCTP

SCTP Acknowledgement

Chunk bundling

Corrupted block

Stream 2 (call 2) Stream 1 (call 1)

Message 3 Message 3

Message 2 Message 2

X

Message 1 Message 1

Association

SCTP (Stream Control Transmission Protocol)

SCTP (Stream Control Transmission Protocol) SCTP, like TCP, is a connection-oriented layer 4 protocol that runs over the connectionless network layer service of IP. However, unlike TCP, which allows only a single session between two hosted applications (described by an IP address and port number), SCTP can provide multiple simultaneous sessions (known as ‘streams’) which can be multiplexed over the ‘association’ that is established between two hosts. Multiple streams operating within the same association allow signalling flows to be separated, perhaps sending time-critical information over one stream and non-time-critical information over another, which can help to alleviate head-of-line blocking problems. Each SCTP session is initiated through a graceful start-up process in which the parameters that describe the association between the two hosts (security information, transport addresses, number of streams and port addresses to be used) are agreed. The SCTP start-up process is also designed to overcome some of the security and service continuity problems associated with TCP, such as connection hijacking and denial of service attacks. An SCTP association is torn down using a graceful take-down process.

Further Reading: IETF RFC3286, RFC4960 LT3603/v1

© Wray Castle Limited

5.5

LTE Radio Access Network

M3UA

M3UA

Message 3

Message by Message

Message 2 Message 1 Message by Message Streamed Sequenced delivery within streams User data fragmentation

SCTP

SCTP Acknowledgement

Chunk bundling

Corrupted block

Stream 2 (call 2) Stream 1 (call 1)

Message 3 Message 3

Message 2 Message 2

X

Message 1 Message 1

Association

SCTP Functions

SCTP Functions The term ‘stream’ is used in SCTP to refer to a sequence of individual user messages, referenced by an SSN (Stream Sequence Number), which are to be delivered to the upper layer. This has the advantage of reducing the effects of head-of-line blocking of all messages by concentrating retransmission activities, when needed, on the messages travelling over only the affected stream; other streams can continue to transmit new messages. Additionally, a ‘blocked’ stream will only block messages marked as ‘ordered’, i.e. they are part of a sequence. Messages marked as ‘unordered’ may bypass the blockage and be delivered without delay to the upper-layer adaptation layer. When necessary, SCTP fragments user messages to ensure that the SCTP packet passed to the lower layer conforms to the underlying network’s MTU (Maximum Transmission Unit). On receipt, fragments are reassembled into complete messages before being passed to the SCTP user. SCTP assigns a TSN (Transmission Sequence Number) to each user message or message fragment that it transmits. The TSN is independent of any stream sequence number assigned at the stream level. In this way, reliable delivery of all messages is kept functionally separate from the sequenced delivery within individual streams. The SCTP packet as delivered to the IP layer consists of ‘chunks’. Each chunk may contain either user data – a message or message fragment – or SCTP control information. SCTP may bundle more than one chunk into a single SCTP packet if the MTU allows. This ‘chunk bundling’ function is responsible for assembly of the complete SCTP packet and its disassembly at the receiving end.

Further Reading: IETF RFC3286, RFC4960 5.6

© Wray Castle Limited

LT3603/v1

Supporting Protocols and Technologies

Endpoint A

Endpoint B

Link 1

SS7

IP

Link 2

Signalling Links

Message Message

Transport Address (IP address + port no.)

AL Stream 1

IP + port no

Stream 2

SCTP

IP

AL IP + port no

SCTP Association TCB: ƒ TA – list ƒ Number of streams ƒ VTs ƒ TSNs ƒ etc.

IP

L2 + L1

IP L2 + L1

AL – Application Layer IP +port number is known as a 'transport address'

SCTP Concepts

SCTP Concepts SCTP provides layer 4, end-to-end transport functions for signalling and control messages. The SCTP protocol sits on top of a standard IP protocol stack. SCTP uses the concept of the TA (Transport Address), which is defined by an IP address and port number. In the context of SIGTRAN (Signalling Transport) the port number identifies the adaptation layer that is using SCTP’s transport services. An SCTP endpoint can be defined as a logical sender or receiver of SCTP PDUs – an instance of S1AP or of SGsAP, for example. On the protocol stack this relates to a combination of IP address and port number. A single SCTP endpoint can have one or more transport addresses associated with it. When an endpoint has more than one transport address, it is said to be ‘multihomed’. Multihoming is useful as it assists with fault tolerance. It is convenient to consider an endpoint as a list of one or more transport addresses. A transport address may be considered as a ‘path’ to an endpoint. An association may be defined as a protocol relationship between a defined pair of endpoints. Only one association can exist between a pair of endpoints at any given time. However, any endpoint may be used simultaneously in any number of associations. A stream is a unidirectional logical channel between associated SCTP endpoints. An association may be configured to contain a number of incoming and outgoing streams, the maximum number of which is negotiated during the association’s initialization procedure. The use of multiple streams helps to reduce the impact of head-of-line blocking experienced by other connection-oriented protocols such as TCP. Each stream is allocated an SI (Stream Identifier) and may be considered as a unique information flow within the context of an association. One application of a stream may be to transfer signalling messages received on a particular signalling link connecting endpoint A to endpoint B. In the example shown in the diagram, link 1 may be mapped to stream 1 and link 2 to stream 2. Further Reading: IETF RFC3286, RFC4960 LT3603/v1

© Wray Castle Limited

5.7

LTE Radio Access Network

3GPP

GTPv2

X2AP

S1AP

3GPP Protocols

3GPP Protocols The Evolved Packet Core employs a number of protocols designed by 3GPP and ETSI. 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) 5.8

© Wray Castle Limited

LT3603/v1

Supporting Protocols and Technologies

GTPv0 Tunnels

User traffic flows

2G PS core SGSNs

GGSN

GTPv1 Tunnels

RNC

3G PS core

GTP-C and GTP-U tunnels

User traffic flow

Legacy GTP

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 LT3603/v1

© Wray Castle Limited

5.9

LTE Radio Access Network

GTP-U RNC

GTP-U and GTP-C GTP-C

Iu SGSN S3

S10

S12 S4

MME

MME

S11 Roaming EPS X2 S5 S8 S1-U

S-GW

PDN-GW

GTP in the EPS

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 S1-U interface. GTPv1-U is employed to encapsulate and route user plane traffic on all traffic-carrying interfaces, including S1, X2, S4, S5, S8, S12 and S16.

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

© Wray Castle Limited

LT3603/v1

Supporting Protocols and Technologies

Bits Octets

1

1

Optional Fields

2

3

Version

4

5

P

T

6

2

Message Type

3

Message Length

4

Message Length

5

Tunnel ID (TEID)

6

Tunnel ID (TEID)

7

Tunnel ID (TEID)

8

Tunnel ID (TEID)

9

Sequence Number

10

Sequence Number

11

Spare

12

Spare

7

8

P

Piggybacking flag shows if ‘piggybacking’ is taking place

T

TEID flag shows if a TEID field is included in this packet

13…

Zero or more Information Elements

GTPv2-C Packet Header

GTPv2-C Packet Header The format of the GTPv2-C packet header is shown in the diagram. The ‘P’ and ‘T’ fields relate to optional functions and operate as boolean flags (‘1’ equals ‘true’ and ‘0’ equals ‘false’). The ‘P’ field shows whether this message contains instructions related to the ‘piggybacking’ of EPS Bearers. Piggybacking, which is described in Annex F of TS 23.401, is the process whereby one or more dedicated bearers can be established on Attach during the creation of the default bearer. The ‘T’ field indicates whether the TEID (Tunnel ID) field is present in the header. A TEID may not be present for all message types; it is only required for messages that impact directly on tunnel management, handover and some other U-plane related functions.

Further Reading: 3GPP TS 23.401, 29.274 (GTPv2-C) LT3603/v1

© Wray Castle Limited

5.11

LTE Radio Access Network

GTPv2-C Message Types

Path Management

Echo request/response

Tunnel Management

Mobility Management

Session create/delete

Context request/response

Bearer create/modify/ update/delete

Forward Relocation request/response / complete

Indirect Data Forwarding Bearer Resource Release Access Bearers Stop Paging

CS Fallback

Suspend Resume CS Paging

Non-3GPP Access

Create Forwarding Tunnel request/response

Relocation Cancel Identity request/response Detach Notification

Downlink Data Notification

GTPv2-C Message Types

GTPv2-C Message Types GTPv2-C supports message types that perform five main functions: ƒ Path Management ƒ Tunnel Management ƒ Mobility Management ƒ CS Fallback ƒ Non-3GPP Access

Further Reading: 3GPP TS 23.401, 29.274 (GTPv2-C) 5.12

© Wray Castle Limited

LT3603/v1

Supporting Protocols and Technologies

MME GTPv2-C Tunnel Management Messages

eNB

UE

S1-MME S1-U

Create Session Request/Response Delete Session Request/Response Create Bearer Request/Response Modify Bearer Command/Failure Indication Modify Bearer Request/Response Bearer Resource Command/Failure Indication Update Bearer Request/Response S11 Delete Bearer Command/Failure Indication Delete Bearer Request/Response Release Access Bearers Request/Response Create Indirect Data Forwarding Tunnel Request/Response Delete Indirect Data Forwarding Tunnel Request/Response Downlink Data Notification/Acknowledge/Failure Indication Stop Paging Indication

S-GW

GTPv2-C Messages Related to E-UTRAN Connections

GTPv2-C Messages Related to E-UTRAN Connections GTPv2-C is not used directly on either of the E-UTRAN interfaces – S1 or X2 – but it is used indirectly to control the use of GTPv1-U resources on the S1-U interface. GTP Tunnel Management session and bearer control messages are exchanged between the MME and the S-GW over the S11 interface to the S-GW. The set of session and bearer control messages employed to manage S1-U resources is as follows: ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ

Create Session Request/Response Delete Session Request/Response Create Bearer Request/Response Modify Bearer Command/Failure Indication Modify Bearer Request/Response Bearer Resource Command/Failure Indication Update Bearer Request/Response Delete Bearer Command/Failure Indication Delete Bearer Request/Response Release Access Bearers Request/Response Create Indirect Data Forwarding Tunnel Request/Response Delete Indirect Data Forwarding Tunnel Request/Response Downlink Data Notification/Acknowledge/Failure Indication Stop Paging Indication

Selected examples of some of the more commonly encountered GTPv2-C procedures are outlined in the following pages. Further Reading: 3GPP TS29.274 (GTPv2-C) and 23.401 (EPC Procedures) LT3603/v1

© Wray Castle Limited

5.13

LTE Radio Access Network

GTPv2-C Tunnel Management Create Session MME to S-GW via S11

CREATE SESSION REQUEST

Fully Qualified TEID – Endpoint Address plus details of type of interface

Information Element

Required

IMSI

Mand

MS-ISDN

Cond

MEI (ME Identity)

Cond

ULI (User Location Information)

Cond

Serving Network

Cond

RAT

Mand

Sender F-TEID for C-Plane

Mand

PDN-GW C-Plane Address

Cond

APN

Mand

PDN Type

Cond

PDN Address Allocation

Cond

Maximum APN Restriction

Cond

APN-AMBR

Cond

Protocol Configuration Options

Cond

Bearer Contexts to be Created

Mand

MME FQ-CSID

Cond

UE Time Zone

Opt

Charging Characteristics

Cond

Private Extension

Opt

MME

S11

S-GW

Bearer Context to be Created EPS Bearer ID

Mand

TFT

Opt

S1-U eNB F-TEID

Cond

Bearer Level QoS

Mand

GTPv2-C Create Session Procedure

GTPv2-C Create Session Procedure The Create Session procedure is employed to create a session for a UE with an S-GW where no session currently exists. Typically this procedure would be employed as part of the Attach procedure but can also be invoked for functions such as creating a new PDN Connectivity Service, Handover with S-GW change and inter-system Handover from a legacy network. The set of fields shown in the diagram represent those that would be commonly found in a message related to an EPS initial Attach. The Create Session Request will contain at least one Bearer Context to be Created field (for the EPS Default Bearer) and may contain details of further contexts if any Dedicated Bearers are to be established. The GTPv2-C procedure is used by the MME to instruct the S-GW to establish a session for the UE and the network end of the required E-RABs; the MME will also signal similar instructions to the eNB using the S1AP Initial Context Setup procedure.

Further Reading: 3GPP TS29.274:7.2.1 5.14

© Wray Castle Limited

LT3603/v1

Supporting Protocols and Technologies

GTPv2-C Tunnel Management Create Bearer S-GW to MME via S11

MME

S11 CREATE BEARER REQUEST The Procedure Transaction ID generated by the UE is included if this process is in response to a UE-initiated NAS Bearer Resource Allocation transaction

Information Element

Required

PTI

Cond

Linked Bearer ID

Mand

Protocol Configuration Options

Opt

Bearer Contexts

Mand

S-GW

Bearer Context to be Created EPS Bearer ID

Mand

TFT

Mand

S1-U SGW F-TEID

Cond

Bearer Level QoS

Mand

Bearer Flags

Opt

GTPv2-C Create Bearer Procedure

GTPv2-C Create Bearer Procedure The Create Bearer procedure is employed to add new bearers to an existing session and is typically initiated when a UE sends a NAS BEARER RESOURCE ALLOCATION REQUEST. The responsibility for determining the best way to handle the resource request lies with the PDNGW/PCRF. If it decides to establish a new bearer to accommodate the UE’s requirement it will send a CREATE BEARER REQUEST to the S-GW to establish the bearer over the S5 interface. The S-GW creates the network end of the required S1 bearer and forwards a modified version of the Request over the S11 to the MME. The MME then signals the bearer requirement to the eNB using S1AP procedures. If the procedure is undertaken as a result of an initial request from a UE the PTI (Procedure Transaction ID) of the original request is carried in the GTPv2-C message as implicit confirmation that the transaction has been actioned.

Further Reading: 3GPP TS29.274:7.2.3 LT3603/v1

© Wray Castle Limited

5.15

LTE Radio Access Network

GTPv2-C Tunnel Management Release Access Bearers MME to S-GW via S11

MME

S11 RELEASE ACCESS BEARERS REQUEST Information Element

Required

List of Bearers EPS Bearer ID

S-GW Cond

GTPv2-C Release Access Bearers Procedure

GTPv2-C Release Access Bearers Procedure When a UE moves from ECM-CONNECTED to ECM-IDLE any S1 and air interface resources assigned to it are released. As part of this process the MME will instruct the S-GW to release the network end of the S1 tunnels created for the UE. The S-GW UE session will be maintained as will the S5/S8 connection to the PDN-GW. The RELEASE ACCESS BEARERS REQUEST message is carried within a GTPv2-C packet, which identifies the TEID of the UE’s S1 connection in the packet header fields. The Release Access Bearers Request message then only needs to list the EPS Bearer IDs of the connections that require releasing. The EPS Bearers are placed in the Bearer Inactive state and the S1 GTP tunnel resources will be released by the S-GW allowing the UE to drop into Idle Mode.

Further Reading: 3GPP TS29.274:7.2.21 5.16

© Wray Castle Limited

LT3603/v1

Supporting Protocols and Technologies

GTPv2-C Tunnel Management Downlink Data Notification S-GW to MME via S11

MME

S11 DOWNLINK DATA NOTIFICATION Information Element

Required

Cause

Opt

S-GW

GPTv2-C Downlink Data Notification Procedure

GTPv2-C Downlink Data Notification Procedure A UE that is in the ECM-IDLE state will still have EPS Bearers assigned to it with IP addresses that are available to receive traffic from external sources. The S5/S8 part of the EPS Bearer between the PDN-GW and the S-GW will still be active and user traffic is able to be routed to the S-GW from elsewhere. If traffic arrives at the S-GW on a tunnel associated with an Idle UE it will transmit a DOWNLINK DATA NOTIFICATION to the UE’s serving MME. The MME may respond with an instruction to the S-GW to delay further action, in which case the SGW will buffer the received downlink traffic (and any subsequent packets that arrive for UE) until the specified wait period timer expires. If no wait period is required the MME will initiate the Networktriggered Service Request function by Paging the UE. If the UE responds the MME initiates the reactivation of the ‘parked’ EPS Bearer Contexts by sending a MODIFY BEARER REQUEST to the S-GW which contains the TEID of the eNB (in the S1 eNB F-TEID field) in the Bearer Context to be Created field. The bearers are re-established to the UE’s new location and the buffered downlink data can be delivered.

Further Reading: 3GPP TS29.274:7.2.11 LT3603/v1

© Wray Castle Limited

5.17

LTE Radio Access Network

Bits Octets

1

1

Optional Fields

2

3

Version

4

5

PT

6

7

8

E

S

PN

2

Message Type

3

Message Length

4

Message Length

5

Tunnel ID (TEID)

6

Tunnel ID (TEID)

7

Tunnel ID (TEID)

8

Tunnel ID (TEID)

9

Sequence Number

10

Sequence Number

11

N-PDU Number

12

Next Extension Header Type

13…

Zero or more Extension Headers Zero or more T-PDUs

PT

Protocol Type 1 = GTP 0 = GTP’ (GTP Prime)

E

Extension Headers 1 = Present 0 = Not present

S

Sequence Number 1 = Meaningful 0 = Not meaningful

PN

N-PDU Number 1 = Present 0 = Not present or present but not meaningful

GTPv1-U Packet Header

GTPv1-U Packet Header The format of the GTPv1-U packet header is shown in the diagram. The ‘PT’ field indicates the Protocol Type as either GTP (as used in PS core networks) or GTP’ (pronounced ‘GTP Prime’, as used on Charging interfaces). The ‘E’ field shows whether this message contains any additional Extension Headers, which will occupy the first part of the payload section if they exist. Only two Extension Header type are currently supported. The UDP Port header can be appended to an Error Indication and carries the UDP Port Number of the G-PDU that triggered the error. The other extension header type carries the PDCP Sequence Number assigned to the unit of user data on the air interface; this may be sent during handovers. The ‘S’ field shows how to handle the Sequence Number field. If the S bit equals 0 then the field is either not present, or is present but does not contain a meaningful value. If the S bit equals 1 then the field is present and does contain a meaningful value. The Sequence Number is only required for connections that need to preserve transmission order. The ‘PN’ bit indicates the presence or otherwise of an N-PDU Number field. The N-PDU Number is used to indicate the order of packets transferred between SGSNs during ‘Inter SGSN routing’ activities. A T-PDU (Transport Protocol Data Unit) is an encapsulated user data packet which is being transferred along the GTP tunnel between a UE and a PDN-GW.

Further Reading: 3GPP TS 23.401; 29.281 (GTPv1-U) 5.18

© Wray Castle Limited

LT3603/v1

Supporting Protocols and Technologies

GTPv1-U Message Types

GTP-U Signalling

Echo request/response

User Traffic

G-PDU

Error Indication Supported Extension Headers Notification

GTPv1-U Message Types

GTPv1-U Message Types GTPv1-U supports a limited set of message types. GTP-U Signalling message types are: ƒ Echo Request ƒ Echo Response ƒ Error Indication ƒ Supported Extension Headers Notification User traffic, encapsulated into a T-PDU, is carried in a G-PDU (GTP Protocol Data Unit) packet. If no additional information is being carried along with the T-PDU, the G-PDU message header may only contain eight bytes of data (version, flags, message type, length, TEID).

Further Reading: 3GPP TS 23.401; 29.281 (GTPv1-U) LT3603/v1

© Wray Castle Limited

5.19

LTE Radio Access Network

5.20

© Wray Castle Limited

LT3603/v1

Supporting Protocols and Technologies

Section 5 Glossary 3GPP

3rd Generation Partnership Project

DiffServ DSMIPv6

Differentiated Services Dual Stack Mobile IP version 6

ECM eNB EPC EPS E-RAB ETSI E-UTRAN

EPS Connection Management Evolved Node B Evolved Packet Core Evolved Packet System E-UTRAN Radio Access Bearer European Telecommunications Standards Institute Evolved Universal Terrestrial Radio Access Network

GGSN G-PDU GPRS GTP GTP’ GTP-C GTP-U GTPv1-U GTPv2 GTPv2-C

Gateway GPRS Support Node GTP Protocol Data Unit General Packet Radio Service GPRS Tunnelling Protocol GPRS Tunnelling Protocol Prime GPRS Tunnelling Protocol – Control Plane GPRS Tunnelling Protocol – User Plane GPRS Tunnelling Protocol version 2 – User Plane GPRS Tunnelling Protocol version 2 GPRS Tunnelling Protocol version 2 – Control Plane

IETF IMS IP MIPv4 MME MTU

Internet Engineering Task Force IP Multimedia Subsystem Internet Protocol Mobile IP version 4 Mobility Management Entity Maximum Transmission Unit

NAS

Non-Access Stratum

PDCP PDN PDN-GW PDU PMIPv6 PS PSTN PTI

Packet Data Control Protocol Packet Data Network Packet Data Network Gateway Protocol Data Unit Proxy Mobile IP version 6 Packet Switched Public Switched Telephone Networks Procedure Transaction ID

QoS

Quality of Service

LT3603/v1

© Wray Castle Limited

5.21

LTE Radio Access Network

RFC RNC RTCP RTP

Requests For Comment Radio Network Controller Real Time Control Protocol Real Time Protocol

S1AP SCTP SDP SGsAP SGSN S-GW SI SIGTRAN SIP SS7 SSN

S1 Application Protocol Stream Control Transmission Protocol Session Description Protocol SGs Application Part Serving GPRS Support Node Signalling Gateway Stream Identifier Signalling Transport Session Initiation Protocol Signalling System no. 7 Stream Sequence Number

TA TCP TEID T-PDU TSN

Transport Address Transmission Control Protocol Tunnel ID) Transport Protocol Data Unit Transmission Sequence Number

UDP UE

User Datagram Protocol User Equipment

X2AP

X2 Application Protocol

5.22

© Wray Castle Limited

LT3603/v1

LTE Radio Access Network

Section 6

E-UTRAN Support for LTE Procedures

© Wray Castle Limited

LTE Radio Access Network

ii

© Wray Castle Limited

LT3603/v1

E-UTRAN Support for LTE Procedures

Contents LTE Procedures ................................................................................................................................... 6.1 eNB Self-Configuration ........................................................................................................................ 6.2 Attach ................................................................................................................................................... 6.3 Default Bearer Establishment .............................................................................................................. 6.4 TAU (Tracking Area Update)................................................................................................................ 6.5 Bearer Resource Allocation or Modification ......................................................................................... 6.6 Dedicated Bearer Establishment ......................................................................................................... 6.7 Additional PCS Establishment ............................................................................................................. 6.8 S1 Release ........................................................................................................................................... 6.9 UE-initiated Service Request ............................................................................................................. 6.10 Paging and Network Initiated Service Request.................................................................................. 6.11 Inter-eNB Resource Management ..................................................................................................... 6.12 Creating Inter-eNB X2 Adjacencies ................................................................................................... 6.13 Connected Mode Procedures ............................................................................................................ 6.14 Inter-eNB Handover with X2 .............................................................................................................. 6.15 Inter-eNB Handover with X2 (continued) ........................................................................................... 6.16 S1-based Handover ........................................................................................................................... 6.17 Traffic Routing Options for Inter-System Handover ........................................................................... 6.20 Inter-RAT HO Preparation.................................................................................................................. 6.21

LT3603/v1

© Wray Castle Limited

iii

LTE Radio Access Network

Inter-RAT HO Execution .................................................................................................................... 6.22 Inter-RAT HO Execution (continued) ................................................................................................. 6.23 Bearer Deactivation............................................................................................................................ 6.24 Detach ................................................................................................................................................ 6.25

iv

© Wray Castle Limited

LT3603/v1

E-UTRAN Support for LTE Procedures

Objectives

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

describe the role played by E-UTRAN protocols in wider LTE Procedures

ƒ

outline the SON (Self-Organizing Network) concept and its applicability to E-UTRAN configuration functions

ƒ

cutline the role played by NAS, S1AP, X2AP and GTP messaging procedures in a variety of common LTE functions

LT3603/v1

© Wray Castle Limited

v

LTE Radio Access Network

vi

© Wray Castle Limited

LT3603/v1

E-UTRAN Support for LTE Procedures

NAS Messages S1AP Messages X2AP Messages E-UTRAN EPC

GTPv2-C Messages Diameter Messages

LTE Procedures

LTE Procedures The individual signalling protocols employed within the E-UTRAN – NAS, S1AP, X2AP and, indirectly, GTPv2-C – each provide a part of the overall protocol messaging structure. The following pages present detailed message flows describing the major functions performed via the E-UTRAN and show the interaction between the various signalling protocols.

Further Reading: 3GPP TS23.401 (EPC), 36.401 (E-UTRAN) LT3603/v1

© Wray Castle Limited

6.1

LTE Radio Access Network

eNB power on (or cable connected)

(A) Basic Setup

a-1 : configuration of IP address and detection of OAM a-2 : authentication of eNB/NW

a-3 : association to aGW

Self-Configuration (pre-operational state)

a-4 : downloading of eNB software (and operational parameters)

(B) Initial Radio Configuration

b-1 : neighbour list configuration b-2 : coverage/capacity related parameter configuration

Self-Optimization (operational state) (C) Optimization/ Adaptation

C-1 : neighbour list optimization

C-2 : coverage and capacity control

eNB Self-Configuration

eNB Self-Configuration The SON (Self-Organizing Network) concept provides for the auto-configuration of eNBs. If an eNB supports self-configuration it is able to establish primary IP communications with the network and download any required software and operational parameters automatically. This removes the requirement for highly trained engineers to commission new eNB sites and instead allows networks to use less expensive installation personnel to perform these duties. 3GPP have outlined a basic functional flow for SON activities, with Basic Setup and Initial Radio Configuration providing the self-configuration aspects. Self-Optimization activities are then employed to allow the eNB to auto-configure X2 relationships with its neighbours. The scope of the SON concept extends beyond initial setup functions, however, and will eventually also encompass self-adaptation functions. This extension will allow eNBs to automatically configure and adapt the coverage and capacity of their cells based on feedback from UEs and from neighbour sites. Functions such as the auto-discovery and elimination of coverage ‘holes’ are possible, which would allow eNBs to alter the orientation or output power of their antennas to improve the coverage offered to UEs. Extensions to the S1 and X2 application protocols and the definition of SON OAM (Operations, Administration and Maintenance) interfaces will be required to fully realize the potential of SON within the access network.

Further Reading: 3GPP TS36.300:22, 35.521 (SON OAM Requirements) and 36.902 (SON Use Cases) 6.2

© Wray Castle Limited

LT3603/v1

E-UTRAN Support for LTE Procedures

UE

eNB

1. RRC (Attach Request)

MME

PDN-GW

EIR

HSS

2 Initial UE Context (Attach Request and PDN Connectivity Request)

3. Authentication Request/Response

Uplink/Downlink NAS Transfer

S-GW

4. Identity Request/Response

3. AKA/Security 4. ME Identity Check

4. Security Mode Command 4. Security Mode Complete 5. Update Location 5. Insert Subscriber Data 5. Insert Subscriber Data Ack

NAS S1AP X2AP GTPv2-C Diameter

5. Update Location Ack

Attach

Attach The EPS Attach procedure allows a UE to register with an EPC ready to receive packet data services and is substantially the same as the Attach procedure employed in legacy 3GPP networks. The main difference with the EPS Attach, however, is the automatic establishment of at least one Default Bearer (and possibly other Default and Dedicated Bearers) as a consequence of a successful Attach. The exact nature of the Attach process performed depends in part on the UE’s operation mode. There are four defined modes: ƒ PS Mode 1: EPC Attached, voice-centric usage setting ƒ PS Mode 2: EPC Attached, data-centric usage setting ƒ CS/PS Mode 1: EPC and non-EPC Attached, voice-centric setting ƒ CS/PS Mode 2: EPC and non-EPC Attached, data-centric setting 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 EUTRAN – 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 Attach Request and PDN Connectivity Request messages encapsulated in an S1AP Initial UE Context message(2). The MME uses the Diameter-based S6a interface to communicate with the HSS and may optionally invoke security functions towards the UE. Further Reading: 3GPP TS 23.401:5.3.2 LT3603/v1

© Wray Castle Limited

6.3

LTE Radio Access Network

UE

eNB

MME

S-GW PDN-GW

PCRF

HSS

6. Create Session Request 8. Create Session Response

7. PCC Lookup

10. RRC Conn 9. Initial Context Setup Request Reconfig (Attach Accept and Activate Default EPS Bearer Context Request) 11. RRC Conn 12. Initial Context Setup Response Reconfig Complete (Attach Complete and Activate Default EPS Bearer Context Accept) 13. Modify Bearer Request/Response NAS S1AP X2AP GTPv2-C Diameter

Data flow

Default Bearer Establishment

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 GTPv2-C Create Session Request to the selected S-GW, which creates the EPS bearer using the indicated parameters and passes the request to the indicated PDN-GW (6). If the network employs dynamic PCC the PDN-GW will query the PCRF assigned to serve the UE for bearer parameters, otherwise the bearer will be established using local QoS parameters stored in the PDN-GW (7). A Create Session Response message passes from the PDN-GW to the S-GW, which contains relevant parameters such as the IP address assigned to the UE for use with the EPS Bearer. The SGW creates the bearer as specified and passes the Create Session 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 S1AP Initial Context Setup Request message with encapsulated NAS Attach Accept and Activate Default EPS Bearer Context Request messages, 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. This encapsulates Attach Complete and Activate Default EPS Bearer Context Accept NAS messages destined for the MME. The eNB forwards an S1AP Initial Context Setup Response message to the MME (12) which also encapsulates the NAS messages generated by the UE. The MME issues a GTPv2-C Modify Bearer Request to the S-GW and on to the PDN-GW to confirm that the bearer context has changed state to Active. When the PDN-G responds uplink and downlink data can begin to flow. Further Reading: 3GPP TS 23.401:5.3.2 (NB the diagrams in the latest version of this spec are out of date) 6.4

© Wray Castle Limited

LT3603/v1

E-UTRAN Support for LTE Procedures

UE

eNB

MME

HSS

TAU trigger event 1. RRC (TAU Request) 2. Uplink NAS Transport (TAU Request) 3. Authentication/Security Uplink/ Downlink NAS Transfer and RRC

4. TAU Accept 5. TAU Complete

NAS S1AP X2AP GTPv2-C Diameter

Tracking Area Update (TAU)

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 can 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 encapsulated in an Uplink NAS Transfer message (which includes the new TAI and ECGI) to the MME indicated by the supplied GUTI (2). If the ‘old’ 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 LT3603/v1

© Wray Castle Limited

6.5

LTE Radio Access Network

UE

eNB

MME

S-GW

PDN-GW

PCRF

HSS

Trigger Event 1. Bearer Resource Modification Request

2.Bearer Resource Command

3. PCC Lookup

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

NAS S1AP X2AP GTPv2-C Diameter

The same process is followed for Bearer Resource Allocation Request

Bearer Resource Allocation or Modification

Bearer Resource Allocation or Modification If a UE determines that there is a requirement to modify a traffic flow aggregate (which may contain one or more Service Data Flows) – in response to a user interface request, for example – it will transmit a Bearer Resource Modification Request to the MME. If the UE was 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) using a GTPv2-C Bearer Resource Command, which in turn forwards it to the appropriate PDN-GW. If dynamic PCC (Policy and Charging Control) 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. The process that allows a UE to request resources for a new traffic flow aggregate is essentially the same as that described above and employs the NAS Bearer Resource Allocation request message format. Further Reading: 3GPP TS 23.401:5.4 6.6

© Wray Castle Limited

LT3603/v1

E-UTRAN Support for LTE Procedures

UE

eNB

MME

S-GW

PDN-GW

PCRF

HSS

1. Trigger Event 2. Bearer Resource Modification Request

3. Bearer Resource Command

4. PCC Lookup 5. Create Bearer Request 7. RRC Conn 6. E-RAB Setup Request Reconfig (Activate Dedicated EPS Bearer Context Request) 9. E-RAB Setup 8. RRC Conn Response Reconfig Complete (Activate Dedicated EPS Bearer Context Accept) 10. Create Bearer Response 11. IP-CAN Session Modified Data Flow

NAS S1AP X2AP GTPv2-C Diameter

Dedicated Bearer Establishment

Dedicated Bearer Establishment Following a Bearer Resource Modification (or Allocation) Request from a UE, 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 Bearer Request (5). This establishes the S5/S8 path between the PDN-GW and the S-GW and is forwarded to the MME so that S1 resources can be created at the eNB. The MME forwards an E-RAB Setup Request (6) to the eNB with instructions regarding the S1 and air interface resources to be created. The message encapsulates as NAS PDU containing an Activate Dedicated EPS Bearer Context Request, which travels to the UE via RRC (7 and 8). The UE reserves the indicated resources and transmits an RRC Connection Reconfiguration Complete message to the eNB that encapsulates a NAS Activate Dedicated EPS Bearer Context Accept (8). The eNB issues an E-RAB Setup Response confirming that the required S1 resources are in place (9) and encapsulating the UE’s NAS message. The MME issues a GTPv2-C Create Bearer Response to the S-GW and on to the PDN-GW (10), which updates the PCRF (11).

Further Reading: 3GPP TS 23.401:5.4.1 LT3603/v1

© Wray Castle Limited

6.7

LTE Radio Access Network

UE

eNB

MME

S-GW

PDN-GW

PCRF

HSS

1. Trigger Event 2. PDN Connectivity Request 3. Create Session Request

4. PCC Lookup 5. Create Session Response 6. E-RAB Setup Request 7. RRC Conn Reconfig (Activate Default EPS Bearer Context Request) 9. E-RAB Setup 8. RRC Conn Response Reconfig Complete (Activate Default EPS Bearer Context Accept) 10. Modify Bearer Request/Response Data Flow

11. IP-CAN Session Modified

NAS S1AP X2AP GTPv2-C Diameter

Additional PCS Establishment

Additional PCS Establishment The establishment of a PDN Connectivity Service to a new or additional PDN-GW is shown in the diagram. The process begins with the UE issuing a NAS PDN Connectivity Request to the MME, which in turn issues a GTPv2-C Create Session request towards the PDN-GW indicated by the required APN. From that point onwards the message flow matches that employed for the creation of a Default EPS Bearer.

Further Reading: 3GPP TS23.401 6.8

© Wray Castle Limited

LT3603/v1

E-UTRAN Support for LTE Procedures

UE

eNB

MME

S-GW

PDN-GW

PCRF

HSS

1. Trigger Event 2. UE Context Release Request

3. Release Access Bearers Request 4. Release Access Bearers Request

6. RRC Conn Release

5. UE Context Release Command

7. RRC Conn Release Ack 8. UE Context Release Complete NAS S1AP X2AP GTPv2-C Diameter

S1 Release

S1 Release S1 Resources may be released between an eNB and the network for a number of reasons, with user inactivity and O&M intervention being two of them. The process can be initiated by either the network or the eNB and the eNB-initiated procedure is detailed in the diagram. After a trigger event (e.g. too many RRC signalling integrity check failures) (1) the eNB issues an S1AP UE Context Release Request towards the MME (2). The MME instructs the S-GW to release S1 access bearer resources towards the eNB (3/4). This does not release the Bearer Contexts, it simply places them in an Inactive state and this procedure does not affect the S5/S8 bearer towards the PDN-GW. Once a response has been received from the S-GW the MME issues an S1AP UE Context Release Command towards the eNB (5). The eNB instructs the UE to release its EPS Bearer and E-RAB resources via an RRC Connection release message, which implicitly places the UE in Idle Mode (6). The RRC message is sent in Acknowledged Mode, so although there is no explicit response to the message the acknowledgement that it was correctly received is taken as confirmation that it will be acted upon (7). The eNB confirms S1 Release by sending the UE Context Release Complete (8) message back to the MME.

Further Reading: 3GPP TS23.401:5.3.5 LT3603/v1

© Wray Castle Limited

6.9

LTE Radio Access Network

UE

eNB

MME

S-GW

PDN-GW

PCRF

HSS

Trigger Event 1. RRC (Service Request)

2. Initial UE Context (Service Request)

3. Authentication/Security

4. Initial Context Setup Request 5. Radio Bearer Establishment 6. Uplink Data Flow 7. Initial Context Setup Complete 8. Modify Bearer Request 9. Modify Bearer Request/Response 10. Modify Bearer Response 11. Downlink Data Flow

NAS S1AP X2AP GTPv2-C Diameter

UE-Initiated Service Request

UE-initiated 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 in scheduled uplink capacity. The request is initially forwarded to the eNB encapsulated in an RRC message (1). RRC will also provide the eNB with the UE’s current S-TMSI if available and the establishment cause for the connection (mt-Access or mo-signalling). 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) encapsulated in an S1AP Initial UE Context message. 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) to the MME. With the UE and eNB contexts re-established the MME instructs the S-GW to establish its end of the S1-U tunnels using the Modify 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 Modify Bearer Request (9). After the PDN-GW and S-GW return Modify Bearer Responses, data can begin to flow on the downlink (9, 10 and 11). Further Reading: 3GPP TS 23.401:5.3.4, 36.331 (RRC) 6.10

© Wray Castle Limited

LT3603/v1

E-UTRAN Support for LTE Procedures

UE

eNB

MME

S-GW

PDN-GW

PCRF

HSS

1. Downlink Data 2. Downlink Data Notification 3. Downlink Data Notification Ack 4. Paging 5. Paging 6. Service Request Procedure

7. Downlink Data Flow

NAS S1AP X2AP GTPv2-C Diameter

Paging and Network-Initiated Service Request

Paging and Network Initiated Service Request The Paging process allows the MME to contact Idle Mode UEs to require them to establish a NAS signalling connection. Paging is usually performed to alert a UE to a waiting inbound session or of stored downlink data but it can also be used in certain error recovery situations to require a UE to reattach to the network. In the case that paging is initiated due to downlink data being received at the S-GW (1) for a UE in Idle Mode that has previously been subject to S1 Release, the S-GW alerts the MME using the GTPv2-C Downlink Data Notification message (2). The MME responds with Downlink Data Notification Acknowledge (3). Unlike other NAS message flows the PAGING message does not travel directly between the MME and the UE, it is instead an instruction issued by the MME to one or more eNBs which then take the information provided and broadcast it across their paging channels. Although Paging is a NAS function, the PAGING message is actually an S1AP entity rather than a NAS entity. The S1AP Paging (4) message issued by the MME contains a UE Paging Identity, which will usually be the subscriber’s current S-TMSI but may in certain failure conditions be the IMSI instead. The PAGING message also contains the UE’s current TAI List to allow the eNB the opportunity to tailor the set of cells in which the page is propagated if necessary and optionally carries details the UE’s DRX cycle, so the eNB can determine the paging group to which it belongs. One further field is the CN Domain field which indicates the type of core network that initiated the page; EPS-initiated paging messages will indicate a PS core, whilst pages issued for CS Fallback purposes would indicate CS. The eNB propagates the page in each of its cells that is associated with the UE’s current TAI List (5). If the UE is camped on to one othe eNB’s cells and detects the Paging message it responds with a Service Request message and the relevant procedure is then initiated (6) at the end of which the stored downlink data can be delivered to the UE (7).

Further Reading: 3GPP TS24.301:5.6.2 and 36.413:9.1.6 (S1AP Paging) LT3603/v1

© Wray Castle Limited

6.11

LTE Radio Access Network

eNB1

eNB2

1. Resource Status Request (Start) 2. Resource Status Response

3. Resource Status Updates

4. Resource Status Request (Stop) 5. Resource Status Response

Inter-eNB Resource Management

Inter-eNB Resource Management One of the basic X2 interface functionalities is the transfer of Resource Status information between neighbouring eNBs; this information is then used as the basis for handover and cell-edge scheduling decisions. The evolving SON concept aims to increase dramatically the scope of the automatic resource management functions that operate between eNBs. This would involve eNBs co-operating to decide on the best utilization of shared cell-edge boundary areas and in the control of inter-cell handover functions. It is envisaged that SON auto-optimization functions will allow eNBs to alter the power output, resource configuration and even physical orientation of cells based on feedback supplied by neighbours; all of this activity would be performed with little or no human intervention.

Further Reading: 3GPP TS36.423:8.3.6 and 9.1.2.11-13, 35.521 (SON OAM Requirements) and 36.902 (SON Use Cases) 6.12

© Wray Castle Limited

LT3603/v1

E-UTRAN Support for LTE Procedures

eNB1

UE

eNB2

MME

1. RRC Measurement Reports 2. Previously unknown neighbour PCI detailed in report 3. RRC (Report eCGI) 4. RRC (eCGI) 5. eNB Configuration Transfer (Request Target eNB X2 TNL address) 6. MME Configuration Transfer (Target eNB X2) TNL address supplied) 7. SCTP Association setup 8. X2 Setup Request 9. X2 Setup Response

Creating e-NB X2 Adjacencies

Creating Inter-eNB X2 Adjacencies The optional auto-configuration of X2 adjacencies is managed by the ANR (Automatic Neighbour Relation) function in the eNB. If the ANR process is not employed, Neighbour Relationships can be created manually via O&M. The ANR process is aided by the measurement reports sent to the eNB by UEs (1); the initiation of measurement report sending and the type and periodicity of the reports is controlled by broadcast parameters. In normal circumstances a UE will report neighbour cell information using the target cell’s PCI (Physical Cell ID). The PCI is an abbreviated form of cell ID employed simply to allow local cells to be quickly differentiated. If a report from a UE contains a PCI (2) with which the eNB is unfamiliar it triggers the auto-configuration of an X2 interface towards the eNB controlling the cell. The eNB instructs the UE that reported the ‘new’ PCI to broaden the scope of its reporting (3) by determining the target cell’s Global-CGI. This is achieved by synchronizing with the cell’s BCCH and waiting for the appropriate SIB (System Information Block) to cycle past. If necessary the eNB will schedule transmission gaps for the UE to allow it to recover the required information. If the UE is able to recover the target cell’s Global-CGI it returns it to the serving eNB in its next measurement report (4). Armed with a Global-CGI to identify the target cell, the source eNB is able to interrogate the MME to discover details of the eNB that hosts the cell using the S1AP eNB Configuration Transfer message (5). If the SON Information field contains a SON Information Request IE the MME will look up the TNL (Transport Network Layer) address of the target eNB’s X2 interface and pass it back to the source eNB (6). The source eNB is then able to initiate the establishment of a new SCTP Association with the target eNB (7) over which it can then initiate the X2 Setup procedure (8 and 9). Further Reading: 3GPP TS36.300:22 LT3603/v1

© Wray Castle Limited

6.13

LTE Radio Access Network

Intra-E-UTRAN

Inter-S-GW

Inter-RAT

Inter-MME

Non-3GPP

Connected Mode Procedures

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

© Wray Castle Limited

LT3603/v1

E-UTRAN Support for LTE Procedures

UE

Source eNB

Target eNB

MME

S-GW

PDN-GW

1. Uplink and downlink data flow 2. RRC Measurement Reports 3. Handover Decision 4. Handover Request 5. Handover Request Ack 6. RRC Connection Reconfiguration 7. Detach from source cell and synchronize to target cell 8. SN Status Transfer 9. Forwarding of Downlink data to target cell via X2

NAS S1AP X2AP GTPv2-C Diameter

10. RRC Connection Reconfiguration Complete 11. Deliver buffered DL data

Inter-eNB Handover with X2

Inter-eNB Handover with X2 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 same 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 (1) and has previously started taking neighbour cell measurements. Traffic may or may not be flowing over the connected EPS Bearers. A measurement report (2) indicates that a neighbour cell has achieved the criteria necessary for the eNB to initiate handover (3). An X2 interface exists between the source and target eNBs allowing the source device to assign X2-U resources and send an X2AP Handover Request (4). The target eNB evaluates the handover and decides to reserve resources for the UE, the target end X2-U resources are created and a Handover Request Acknowledge message (5) is sent back to the source end. The source eNB forwards the RRC resource information to the UE (6). The UE releases the ‘old’ air interface resources and synchronizes with the ‘new’ cell (7). The source eNB releases radio resources and sends an X2 SN Status Transfer to the target end detailing the frozen PDCP states (8). Any further downlink traffic received for the UE at the source eNB is forwarded to the target eNB directly via the X2 interface (9) where it is buffered waiting for the UE to synchronize. The UE uses the assigned resources in the new cell to send an RRC Connection Reconfiguration Complete message (10), triggering the delivery of any buffered downlink to the UE (11).

Further Reading: 3GPP TS 23.401:5.5.1 LT3603/v1

© Wray Castle Limited

6.15

LTE Radio Access Network

UE

Source eNB

Target eNB

MME

S-GW

PDN-GW

12. X2-U Direct Forwarding

13. Path Switch Request

14. Modify Bearer Request 15. UE location information updated

16a. End Markers 16b. End Markers forwarded, X2-U data forwarding ends 17. Modify Bearer Response 18. Path Switch Request Ack 19. Session Data

NAS S1AP X2AP GTPv2-C Diameter

20. UE Context Release

Inter-eNB Handover with X2 (continued)

Inter-eNB Handover with X2 (continued) Uplink and downlink traffic may now flow via the X2-U tunnel (12). The target eNB sends a Path Switch Request to the MME informing it of the handover (13). The MME determines that the existing S-GW is still capable of serving the UE (as the S-GW is associated with the cell’s TA) and instructs it to switch the Downlink user plane over to the tunnel created towards the new cell using a Modify Bearer Request message (14). If the PDN-GW has indicated that needs to be kept informed of the UE’s location (for variable charging purposes), the SGW informs it using an Modify Bearer Request (15). 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 (16). The S-GW then realigns the tunnel carrying the EPS bearer(s) to point to the target eNB andsends confirmation to the MME that the path has been switched successfully (17). The MME confirms the procedure to the new eNB with the Path Switch Request Ack message (18), which contains details of the new S1 tunnel. With the new S1 tunnel in place user session traffic begins to flow between the target eNB and the S-GW (19). The target eNB confirms the handover to the old eNB using the X2 UE Context Release message (20).

Further Reading: 3GPP TS 23.401:5.5.1 6.16

© Wray Castle Limited

LT3603/v1

E-UTRAN Support for LTE Procedures

UE

Source eNB

Target eNB

MME

S-GW

PDN-GW

1. Uplink and downlink data flow 2. RRC Measurement Reports 3. Handover Decision 4. Handover Required 5. Handover Request 6. Handover Request Acknowledge 7. Create Indirect Data Forwarding Tunnel Request 9. Handover Command

8. Create Indirect Data Forwarding Tunnel Response

10. RRC Connection Reconfiguration 11. Detach from source cell and synchronize to target cell 12. eNB Status Transfer 13. MME Status Transfer NAS S1AP X2AP GTPv2-C Diameter

14. Forwarding of Downlink data to target cell via X2

S1-based Handover

S1-based Handover In the event that the X2 interface is not implemented in a network (it is classed as an optional interface) or that an X2 connection is not possible between source and target eNBs, handover can still be achieved via the S1 interface. This is almost exactly the same as the method employed to forward traffic directly via an X2 interface, except that Handover messaging travels via the MME and any session data traffic is tunnelled between the source and target cells over the S1 via the S-GW. 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 same serving MME and S-GW and an X2 path cannot be established between them. At the start of the process the UE is connected to the E-UTRAN (1) and has previously started taking neighbour cell measurements (1). Traffic may or may not be flowing over the connected EPS Bearers. A measurement report (2) indicates that a neighbour cell has achieved the criteria necessary for the eNB to initiate handover (3). As no X2 interface exists between the source and target eNBs the source device must send an S1AP Handover Required (4) message to the MME. The MME issues a Handover Request to target eNB (5) including details of the bearers to be set up. The target eNB evaluates the handover and decides to reserve resources for the UE, the target end S1-U resources are created and a Handover Request Acknowledge message (6) is sent back to the MME. This message includes details of the indirect forwarding bearers to be setup. The MME uses the GTPv2-C Create Indirect Data Forwarding Tunnel Request (7) to instruct the SGW to establish indirect forwarding bearers – one set the old eNB, one set to the new with a route linking them together. The S-GW responds (8) to confirm that the tunnels have been created. The MME sends a Handover Command (9) to the source eNB. This includes details of the radio resources assigned to the UE In the target cell and also of the forwarding bearers that need to be established. The source eNB forwards the RRC resource information to the UE (10) and creates the required indirect forwarding bearers.

LT3603/v1

© Wray Castle Limited

6.17

LTE Radio Access Network

UE

Source eNB

Target eNB

MME

S-GW

PDN-GW

1. Uplink and downlink data flow 2. RRC Measurement Reports 3. Handover Decision 4. Handover Required 5. Handover Request 6. Handover Request Acknowledge 7. Create Indirect Data Forwarding Tunnel Request 9. Handover Command

8. Create Indirect Data Forwarding Tunnel Response

10. RRC Connection Reconfiguration 11. Detach from source cell and synchronize to target cell 12. eNB Status Transfer 13. MME Status Transfer NAS S1AP X2AP GTPv2-C Diameter

14. Forwarding of Downlink data to target cell via X2

S1-based Handover

S1-based Handover (continued) The UE releases the ‘old’ air interface resources and synchronizes with the ‘new’ cell (11). The source eNB releases radio resources and sends an S1AP eNB Status Transfer to the MME detailing the frozen PDCP states (12), the MME forwards this information to the target eNB in an MME Status Transfer message (13). Any further downlink traffic received for the UE at the source eNB is forwarded to the target eNB via the S1 interface indirect tunnels (14) where it is buffered waiting for the UE to synchronize.

Further Reading: 3GPP TS 23.401:5.5.1.2 6.18

© Wray Castle Limited

LT3603/v1

E-UTRAN Support for LTE Procedures

UE

Source eNB

Target eNB

MME

S-GW

PDN-GW

15. RRC Connection Reconfiguration Complete 16. Deliver buffered DL data 17. Uplink Session Data 18. Handover Notify

19. Modify Bearer Request 20. UE location information updated

21a. End Markers

21b. End Markers forwarded, S1data forwarding ends

22. Modify Bearer Response 23. Downlink Session Data 24. UE Context Release Command 25. UE Context Release Complete 26. Delete Indirect Data Forwarding Tunnel Request 27. Delete Indirect Data Forwarding Tunnel Response

NAS S1AP X2AP GTPv2-C Diameter

S1-based Handover (continued)

S1-based Handover (continued) The UE uses the assigned resources in the new cell to send an RRC Connection Reconfiguration Complete message (15), triggering the delivery of any buffered downlink to the UE (16). Uplink data received at the target eNB can begin flow up to the S-GW (17). The target eNB sends a Handover Notify to the MME confirming that the handover has completed (18). The MME instructs the S-GW to switch the Downlink user plane over to the tunnel created towards the new cell using a Modify Bearer Request message (19). 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 Modify Bearer Request (20). 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 S1 forwarding will cease (21). The S-GW then activates the tunnel carrying the EPS bearer(s) to the target eNB and sends confirmation to the MME that the path has been switched successfully (22). Downlink data is now able to flow to the target cell (23). The MME confirms the handover to the old eNB using the S1AP UE Context Release Command (24) and receives a response (25). Finally the MME instructs the S-GW to delete the additional S1 resources created to carry the indirect tunnel (26 and 27).

Further Reading: 3GPP TS 23.401:5.5.1.2 LT3603/v1

© Wray Castle Limited

6.19

LTE Radio Access Network

RNC SGSN

Indirect Forwarding S-GW-RNC via S12

BTS/ Node B

Direct Forwarding eNB-SGSN Indirect Forwarding

Handover UE

Direct Forwarding eNB-RNC

S-GW-SGSN via S4

S-GW

Direct Forwarding connections not assigned interface names

eNB

Traffic Routing Options for Inter-System Handover

Traffic Routing Options for Inter-System Handover Direct Forwarding takes places when a source eNB establishes a traffic tunnel to the handover target via a direct IP connection over an interface such as the X2; Indirect Forwarding occurs when the forwarding tunnel is created via the S-GW/SGSN. The routes available for direct and indirect forwarding have not been given explicit reference point names; they can therefore be classed as ‘informal’ interfaces that are established on an ad hoc basis between devices that are able to establish IP routes between each other. The scenarios in which direct forwarding may be required include eNB-RNC forwarding (for E-UTRAN to UTRAN HO) and eNB-SGSN forwarding (for E-UTRAN to GERAN HO). Indirect Forwarding takes place when the source and target radio access nodes are not able or not permitted to communicate with each other directly; the forwarding route then travels via the S-GWs or S-GW and SGSN. In the case of networks that employ the S12 interface, traffic may also be indirectly forwarded between an S-GW and an RNC. Traffic forwarded between S-GWs during indirect forwarding also travels over an un-named interface. Network operators may decide that the use of Direct Forwarding introduces too great a degree of variability or uncertainty to their operations and its use is therefore optional.

Further Reading: 3GPP TS23.401:4.2.3 6.20

© Wray Castle Limited

LT3603/v1

E-UTRAN Support for LTE Procedures

UE

Source Target eNB RNC

MME

Source S-GW

Target SGSN

PDN-GW

Data flow 1. Handover decision 2. Handover Required 3. Forward Relocation Request 4. Create Session Request 5. Create Session Response 6. RANAP Relocation Request 7. RANAP Relocation Request Ack 8. Create Indirect Data Forwarding Tunnel Request 9. Create Indirect Data Forwarding Tunnel Response 10. Forward Relocation Response NAS S1AP X2AP GTPv2-C Diameter

11. Create Indirect Data Forwarding Tunnel Request 12. Create Indirect Data Forwarding Tunnel Response

Inter-RAT HO Preparation

Inter-RAT HO Preparation The example provided below is for handover of active traffic connections between a home-network EUTRAN cell and a home-network 3G UTRAN cell without an S-GW change and with no S12 Direct Tunnel support. Following an eNB’s decision that a handover is required (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), which contains a Transparent Container detailling the bearer configurations in use by and radio resources assigned to the handover UE. The source MME selects a target SGSN and issues a GTPv2-C Forward Relocation Request via the S3 interface (3). In this example the target SGSN has an S4 interface to the existing S-GW that allows it to issue a GTPv2-C Create Session 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 S-GW responds with Create Session Response (5). The target SGSN instructs the target BSC/RNC to reserve radio resources for the UE in the target cell using the RANAP Relocation Request message (6) – which includes the Source-Target Transparent Container – and the target RNC responds with Relocation Request Ack once this is complete (7). If S1 Indirect Forwarding (rather than eNB-RNC Direct Forwarding) is to take place the a forwarding tunnel must be created. If required the SGSN sends a GTPv2-C Create Indirect Data Forwarding Tunnel Request (8) to the S-GW, which responds to confirm creation (9). Once the GERAN/UTRAN Radio Access Bearer (RAB) and PDP context are in place, the target SGSN sends the Forward Relocation Response to the source MME (10), which in turn requests the creation of direct forwarding tunnels if required (11/12). Further Reading: 3GPP TS 23.401:5.5.2 LT3603/v1

© Wray Castle Limited

6.21

LTE Radio Access Network

UE

Source Target eNB RNC

MME

Source S-GW

Target SGSN

PDN-GW

13. Data flow 14. Handover Command 15. RRC HO from EUTRAN Command

16. Release and reconnect 17. RRC HO to UTRAN Complete

18a. Downlink Data via Direct Forwarding (eNB-RNC) 18b. Downlink Data via Indirect Forwarding 18a/b. Downlink Data 18c. Uplink Data

19. RANAP Relocation Complete 20. Forward Relocation Complete NAS S1AP X2AP GTPv2-C Diameter

21. Forward Relocation Complete Ack

Inter-RAT HO Execution

Inter-RAT HO 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 (14), which in turn sends a HO from E-UTRAN Command to the UE (15). This message encapsulates the ‘Target-Source 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 (16) and sends the Handover to UTRAN Complete message (17) 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 (18a) uses an unnamed forwarding interface. Indirect Forwarding travels between source eNB, source S-GW, target SGSN and target UTRAN (18b). Once the handover is complete, the Target RNC/Node B can deliver any buffered downlink traffic to the UE (18a/b) and 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 (18c). Once the UE has successfully connected to the UTRAN cell the target RNC sends a Relocation Complete message (19) to the target SGSN, which in turn informs the source MME using the Forward Relocation Complete message (20). The MME responds with a conformation (21).

Further Reading: 3GPP TS23.401:5.5.2 6.22

© Wray Castle Limited

LT3603/v1

E-UTRAN Support for LTE Procedures

UE

Source Target eNB RNC

MME

Source S-GW

Target SGSN

PDN-GW

22. Modify Bearer Request 23. Modify Bearer Response 24. Data Flow

25. UE Context Release Command 26. Delete Indirect Data Forwarding Tunnel Request 27. Delete Indirect Data Forwarding Tunnel Response 28. Delete Indirect Data Forwarding Tunnel Request 29. Delete Indirect Data Forwarding Tunnel Response

NAS S1AP X2AP GTPv2-C Diameter

Inter-RAT HO Execution (continued)

Inter-RAT HO Execution (continued) The target SGSN issues an Modify Bearer Request to the S-GW (22), which initiates the path switch and returns a confirmation message (23). Any indirect forwarding will cease and downlink traffic will travel from the S-GW directly to the target SGSN (24). 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) 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 using the S1AP UE Context Release Command (25). If indirect forwarding was employed, the source S-GW and SGSN will release any tunnel resources that were created (26-29). Traffic is now flowing to the UE from the PDN-GW, via an S-GW to an SGSN and onwards via the UTRAN.

Further Reading: 3GPP TS23.401:5.5.2 LT3603/v1

© Wray Castle Limited

6.23

LTE Radio Access Network

UE

eNB

MME

S-GW

PDN-GW

HSS

1. Delete Bearer Request 2. Delete Bearer Request 3. E-RAB Release 4. RRC Connection

Request Reconfiguration (Deactivate EPS Bearer Context Request)

5. RRC Connection Reconfiguration Complete 6. E-RAB Release Response (Deactivate EPS Bearer Context Accept) 7. Delete Bearer Response 8. Delete Bearer Response

NAS S1AP X2AP GTPv2-C Diameter

Bearer Deactivation

Bearer Deactivation EPS Bearers and the E-RABs that carry them may be released for a number of reasons and the release may be initiated by a number of devices. The example in the diagram shows an EPS Bearer release initiated by the PDN-GW; this may be in response to a UE-initiated bearer modification or release, if so then the commands travelling back to the UE will carry the PTI of the UE’s original request. When the PDN-GW determines that an existing EPS Bearer is to be released it issues the GTPv2-C Delete Bearer Request (1) to the S-GW indicating the EPS Bearer ID and GTP Tunnel details. The SGW notes the request and passes it on to the MME (2). The MME creates a NAS Deactivate EPS Bearer Context Request message, which contains details of the bearer to be released, the cause and possibly the PTI of the UE request and encapsulates it in an S1AP E-RAB Release message (3), which is sent to the current eNB. The eNB creates an RRC Connection Reconfiguration message (4), which encapsulates the NAS message and carries it to the UE. The UE makes the necessary changes and creates a NAS Deactivate EPS Bearer Context Accept message which it places inside an uplink RRC Connection Reconfiguration Complete message (5) to send o the eNB. The eNB releases its end of the specified E-RAB and places the UE’s NAS message inside an E-RAB Release Response (6), which it sends to the MME. The MME releases the bearer context and confirms the release to the S-GW with a Delete Bearer Response (7), which is forwarded to the PDN-GW (8). This procedure is followed to release both types of EPS Bearer – Default and Dedicated. If the UE has two or more PCSs connected and the bearer being released is the last one linked to a particular PCS then the Delete Session and PDN Disconnect procedures would also be triggered to delete the PCS. If the bearer being released is the last bearer of the only connected PCS then the bearer release would also trigger the Detach process. Further Reading: 3GPP TS24.301:5.4.4 6.24

© Wray Castle Limited

LT3603/v1

E-UTRAN Support for LTE Procedures

UE

eNB

MME

S-GW PDN-GW

SGSN

HSS

1. Detach Request 2. Delete Bearer Request 3. Delete Bearer Response 4a. Detach Indication (if ISR active) 4b. Delete PDP Context Request 5. Delete Bearer Request 6. Delete Bearer Response 4c. Delete PDP Context Response 4d. Detach Indication Ack 7. Detach Accept 8. Release Resources NAS S1AP X2AP GTPv2-C Diameter

9. Notify/Request, Notify Response

Detach

Detach A UE will detach from the network either when service is no longer required by the user or when the network decides that service is no longer to be offered to the UE. There are currently four EPS-related detach procedures: ƒ UE-initiated detach ƒ MME-initiated detach ƒ SGSN-initiated detach ƒ HSS-initiated detach A UE will explicitly detach from the EPS under instruction from the user interface, usually in response to a power-down command. The process is initiated by the UE sending a Detach Request NAS message to the MME containing its current GUTI and a cause (e.g ‘switch off’) (1). The MME forwards a Delete Bearer Request to the S-GW (2), which responds to confirm (3). The SGW forwards the Delete Bearer Request to the PDN-GW, which releases S5/S8 resources and confirms to the S-GW using a Delete Bearer Response (5 and 6). If the UE has ISR activated, while the functions related to the S-GW and PDN-GW are taking place, the MME will inform its peer SGSN of the detach and will receive a response (4a and 4b). The S-GW and SGSN will delete the S4 bearer context and the SGSN confirms the detach to the MME (4c and 4d). The MME transmits a NAS Detach Accept message to the UE (7) and in response the UE and eNB release air interface and S1 physical and logical resources (8). The UE is now detached and the HSS is informed of the change in its availability (9). Further Reading: 3GPP TS 23.401:5.3.8 LT3603/v1

© Wray Castle Limited

6.25

LTE Radio Access Network

6.26

© Wray Castle Limited

LT3603/v1

E-UTRAN Support for LTE Procedures

Section 6 Glossary 3GPP ANR APN

3rd Generation Partnership Project Automatic Neighbour Relation, Access Point Name

BCCH BSC CGI CS

Broadcast Control Channel Base Station Controller Cell Global Identity Circuit Switched

eCGI ECM eNB EPC EPS E-RAB E-UTRAN

Evolved Cell Global identity EPS Connection Management Evolved Node B Evolved Packet Core Evolved Packet System Evolved Radio Access Bearer Evolved Universal Terrestrial Radio Access Network

GERAN GTPv2-C GUTI

GSM EDGE Radio Access Network GPRS Tunnelling Protocol version 2 – Control Plane Globally Unique Temporary Identity

HO H-PLMN HSS

Handover Home PLMN Home Subscriber Server

IMSI IP ISR

International Mobile Subscriber Identity Internet Protocol Idle Mode Signalling Reduction

LTE

Long Term Evolution

MAC M-TMSI

Message Authentication Code MME Temporary Mobile Subscriber Identity

NAS

Non Access Stratum

OAM

Operations, Administration and Maintenance

PCC PCI PCRF PDN-GW PDP

Policy and Charging Control Physical Cell ID Policy and Charging Rules Function PDN Connectivity Service Gateway Packet Data Protocol

LT3603/v1

© Wray Castle Limited

6.27

LTE Radio Access Network

PDU PLMN PS

Protocol Data Unit Public Land Mobile Network Packet Switched

QoS

Quality of Service

RANAP RAT RAU RNC RRC

Radio Access Network Application Part Radio Access Technology Routing Area Update Radio Network Controller Radio Resource Control

S1AP SCTP SGSN S-GW SIB SON S-TMSI

S1 Application Protocol Stream Control Transmission Protocol Serving GPRS Support Node Signalling Gateway System Information Block Self-Organizing Network SAE TMSI

TAD TAI TAU TFT TNL

Traffic Aggregate Descriptor Tracking Area Identity Tracking Area Update Traffic Flow Template Transport Network Layer

UE USIM UTRAN

User Equipment Universal Subscriber identity Module Universal Terrestrial Radio Access Network

X2AP

X2 Application Protocol

6.28

© Wray Castle Limited

LT3603/v1

LTE Radio Access Network

LTE Radio Access Network

Glossary of Terms

© Wray Castle Limited

LTE Radio Access Network

G.2

© Wray Castle Limited

LT3603/v1

Glossary of Terms 1xEV-DO 3G 3GPP

1x Evolution – Data Only Third Generation 3rd Generation Partnership Project

A1AP AKA AMBR ANR APN AS

A1 Application Protocol Authentication and Key Agreement Aggregate Maximum Bit Rate Automatic Neighbour Relation, Access Point Name Access Stratum

BCCH BSC BSSGP

Broadcast Control Channel Base Station Controller Base Station System GPRS Protocol

CDMA CGI CLI C-RNTI CS CSG

Code Division Multiple Access Cell Global Identity Calling Line Identity Controlling Radio Network Temporary Identifier Circuit Switched Closed Subscriber Group

DiffServ DL DRX DSMIPv6 DT

Differentiated Services Downlink Discontinuous Reception Dual Stack Mobile IP version 6 Data Transfer

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

Evolved Absolute Radio Frequency Channel Number EPS Bearer Identity Evolved Cell Global identity EPS Connection Management Enhanced Data rates for Global Evolution EPS Integrity Algorithm E-UTRAN Key Set Identifier, Element Manager. EPS Mobility Management Evolved Node B Elementary Procedure Evolved Packet Core Evolved Packet System 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

GBR GERAN GGSN GMM G-PDU GPRS GSM GTP GTP’ GTP-C GTP-U GTPv1-U GTPv2 GTPv2-C

Guaranteed Bit Rate GSM EDGE Radio Access Network Gateway GPRS Support Node GPRS Mobility Management GTP Protocol Data Unit General Packet Radio Service Global System for Mobile communications GPRS Tunnelling Protocol GPRS Tunnelling Protocol Prime GPRS Tunnelling Protocol – Control plane GPRS Tunnelling Protocol – User Plane GPRS Tunnelling Protocol version 2 – User Plane GPRS Tunnelling Protocol version 2 GPRS Tunnelling Protocol version 2 – Control Plane

LT3603/v1

© Wray Castle Limited

G.3

LTE Radio Access Network GU GUMMEI GUTI GUTI

Globally Unique Globally Unique MME Identifier, Globally Unique Temporary Identity Globally Unique Temporary Identity

HFN HII HLR HO H-PLMN HSDPA HSPA HSS HSUPA

Hyper Frame Number High Interference Information Home Location Register Handover Home PLMN High Speed Downlink Packet Access High Speed Packet Access. Home Subscriber Server High Speed Uplink Packet Access

IE IETF IMEISV IMSI IP ISR

Information Element Internet Engineering Task Force International Mobile Equipment Identity Software Version International Mobile Subscriber Identity Internet Protocol Idle Mode Signalling Reduction

KASME KSI LA LCID LTE

Key Access Security Management Entries Key Set Identifier Location Area Logical Channel ID Long Term Evolution

MAC MC MIMO MIPv4 MME MMEC MNC MS M-TMSI MTU

Message Authentication Code Mobile Country Code Multiple Input Multiple Output Mobile IP version 4 Mobility Management Entity Mobility Management Entity Code Mobile Network Code Mobile Station MME Temporary Mobile Subscriber Identity. Maximum Transmission Unit

NAS

Non Access Stratum

O&M OAM OFDMA

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

PCC PCI PCRF PCS PDCP PDN PDN-GW PDP PDU PLMN PMIPv6 PPP PRB PS PSTN PTI

Policy and Charging Control Physical Cell ID Policy and Charging Rules Function PDN Connectivity Service Packet Data Convergence Protocol Packet Data Network Packet Data Network Gateway Packet Data Protocol Protocol Data Unit Public Land Mobile Network Proxy Mobile IP version 6 Point-to-Point Protocol Physical Resource Block Packet Switched Public Switched Telephone Networks Procedure Transaction Identity

G.4

© Wray Castle Limited

LT3603/v1

Glossary of Terms QoS

Quality of Service

RAI RAN RANAP RAND RAT RAU RB RES RF RFC RIM RLC RNC RNSAP RNTP RRC RRM RTCP RTP

Routing Area Identity Radio Access Network Radio Access Network Application Part Random Number Radio Access Technology Routing Area Update Radio Bearer Response Radio Frequency Requests For Comment RAN Information Management Radio Link Control Radio Network Controller Radio Network Subsystem Application Protocol Relative Narrowband Radio Resource Control Radio Resource Management Real Time Control Protocol Real Time Protocol

S1AP SAE SC-FDMA SCTP SDF SDP SDU SGsAP SGSN S-GW SI SIB SIGTRAN SIP SMS SN SON SRVCC SS7 SSN S-TMSI

S1 Application Protocol System Architecture Evolution Single Carrier FDMA Stream Control Transmission Protocol Service Data Flow Session Description Protocol Service Data Unit SGs Application Part Serving GPRS Support Node Signalling Gateway Stream Identifier System Information Block Signalling Transport Session Initiation Protocol Short Message Service Sequence Number Self-Organising Network Single Radio Voice Call Continuity Signalling System no. 7 Stream Sequence Number SAE TMSI

TA TA TAC TAD TAI TAU TCP TEID TFT TMSI TNL T-PDU TSN

Transport Address Tracking Area Tracking Area Code Traffic Aggregate Descriptor Tracking Area Identity Tracking Area Update Transmission Control Protocol Tunnel Endpoint Identifier Traffic Flow Template Temporary Mobile Subscriber Identity, Transport Network Layer Transport Protocol Data Unit Transmission Sequence Number

UDP UE UL UMTS

User Datagram Protocol User Equipment Uplink Universal Mobile Telecommunications System

LT3603/v1

© Wray Castle Limited

G.5

LTE Radio Access Network USIM UTRAN

Universal Subscriber identity Module Universal Terrestrial Radio Access Network

VLR

Visitor Location Register

WiMAX WLAN

Worldwide Interoperability for Microwave Access Wireless Local Area Network

X2AP

X2 Application Protocol

G.6

© Wray Castle Limited

LT3603/v1