LTE Signaling Overview

LTE Signalling 1 EPS Overview

2 NAS Protocols (EMM & ESM)

3 S1 and S11 Interface (S1AP & GTP)

4 Uu Interface I (RRC)

5 Uu Interface II (PDCP & RLC)

6 Uu Interface III (MAC)

7 Uu Interface IV (Layer 1)

8 X2 Interface (X2AP)

9 EPS Interworking

10 Signalling Flows

11

12

13

14 Apis Technical Training AB Tjrhovsgatan 21, 5th floor SE-116 28 Stockholm Sweden Tel +46-8-555 105 00 Fax +46-8-555 105 99 E-mail [email protected] www.apistraining.com

15 Foldouts

The use of a term in this document should not be interpreted in a manner that would affect the validity or legal status of any proprietary rights that may be attached to that term. This is a training document and as such simplifies what are often highly complex technological issues. The system or systems described here should therefore be seen in that light, i. E. as simplifications rather than generalizations. Due to ongoing progress in methodology, design, its contents are furthermore subject to revision without prior notice. Apis Technical Training AB assumes no legal responsibility for any error or damage resulting from the use of this document. Copyright Apis Technical Training AB 2008. All rights are reserved. This training material is the confidential and proprietary property of Apis Technical Training AB. It is to be used solely for the purpose for which it was produced and is not to be copied or otherwise reproduced without the prior written permission of Apis Technical Training AB. To our best knowledge, the information in this document is accurate as per the date of publication. Other than by prior written agreement, Apis Technical Training AB will not update or otherwise advise of errors in the document which may be brought to our attention. All trademarks are trademarks of their respective owners. Apis Technical Training AB. welcomes customer feedback as part of a process of ongoing development of our documentation in order to better meet our customers' needs. Please submit your comments to our Head Office in Stockholm. Apis Technical Training AB Tjrhovsgatan 21, 5th floor SE-116 28 Stockholm Sweden E-mail: [email protected]

Apis Technical Training AB LSIG - Overview Copyright Apis Technical Training AB 2008. All rights reserved. 1-1

1 EPS Overview

1.1 BACKGROUND ..................................................................................1-2

1.2 EVOLVED UTRA & UTRAN..............................................................1-4

1.2.1 Network Architecture................................................................1-4

1.2.2 Requirements on E-UTRA/E-UTRAN ......................................1-4

1.2.3 Overview of Technical Solutions..............................................1-5

1.2.4 Evolved HSPA (eHSPA) ..........................................................1-8

1.3 EVOLVED PACKET CORE...................................................................1-9

1.3.1 Network Architecture................................................................1-9

1.3.2 Requirements on the EPC .....................................................1-10

1.4 REFERENCES .................................................................................1-11


1.1 Background 3GPP Long Term Evolution (LTE) is the name given to a project within the Third Generation Partnership Project (3GPP) to improve the UMTS 3G mobile system standard to cope with future requirements. Goals include improving efficiency, lowering costs, reducing complexity, improving services, making use of new spectrum opportunities and better integration with other open standards (such as WLAN and WiMAX). Thus, the term LTE really means a standardisation project. The final outcome from this project will be a new set of standards defining the functionality and requirements of an evolved, packet based, radio access network and a new radio access. The new radio access network is referred to as the Evolved UTRAN (E-UTRAN) and the new radio access is referred to as the Evolved UTRA (E-UTRA). The LTE project is part of 3GPP Release 8. The term LTE has become more or less synonymous to the (proper) terms Evolved UTRA (the new radio access) and Evolved UTRAN (the new radio access network). With this in mind, the author has taken the freedom to use the terms LTE and E-UTRA interchangeably for the new OFDM-based radio interface. The work on LTE started with a workshop in Nov 2004 in Toronto, Canada. The workshop was open to members and non-members of 3GPP. Operators, vendors and research institutes presented contributions with views and proposals on the future evolution of 3G. A set of high level requirements were initially identified:

Reduced cost per transmitted bit More services at lower cost with better user experience Flexibility of use of existing and new frequency bands Simplified architecture, open interfaces Reasonable terminal power consumption.

It was also agreed that the E-UTRA/E-UTRAN standard should bring significant improvements to justify the standardization effort and that it should avoid unnecessary options (i.e. reduced overall complexity as compared to UMTS). A feasibility study on the UTRA & UTRAN Long Term Evolution was then started in December 2004. The objective was "to develop a framework for the evolution of the 3GPP radio access technology towards a high data rate, low latency and packet optimized radio access technology". The study focused on supporting services exclusively from the Packet Switched (PS) domain.

In parallel to, and coordinated with, the LTE project there is also a 3GPP standardisation project relating to the core network. This project is called System Architecture Evolution (SAE) and aims at standardising the Evolved Packet Core (EPC). The SAE project was started in December 2004, with the objective to develop a framework for an evolution or migration of the 3GPP system to a higher data rate, lower latency, packet optimized system that supports multiple RATs. The EPC is a fully IP-based core network (all-IP) supporting access not only via GERAN, UTRAN and E-UTRAN but also via WiFi, WiMAX and wired technologies such as xDSL. The SAE project is also a part of 3GPP Release 8. A short introduction to the Evolved UTRA/N can be found in section 1.2 in this chapter, and an introduction to the EPC in section 1.3. The combination of the E-UTRAN and the EPC is referred to as the Evolved Packet System (EPS).

Stage 1: March 2008Stage 2: June 2008Stage 3: December 2008 ?

E-UTRAN and EPCRelease 8

2010 ?LTE Advanced (LTE-A)Release 9 or 10

Stage 1: September 2005Stage 2: September 2006Stage 3: December 2007

IMS for NGNEvolved HSPA

Release 7

2005IMS with IP-CAN accessHSUPA

Release 6

2002IMS with GERAN/UTRAN accessHSDPA

Release 5

2001Split ArchitectureRelease 4

2000EDGE, UTRANRelease 99

1999AMRRelease 98

1998GPRSRelease 97

199714.4 kb/s, HSCSDRelease 96

1995GSM (basic configuration)Phase 2

1992GSM (interim configuration)Phase 1

Freeze yearCommentRelease/Phase

Stage 1: March 2008Stage 2: June 2008Stage 3: December 2008 ?

E-UTRAN and EPCRelease 8

2010 ?LTE Advanced (LTE-A)Release 9 or 10

Stage 1: September 2005Stage 2: September 2006Stage 3: December 2007

IMS for NGNEvolved HSPA

Release 7

2005IMS with IP-CAN accessHSUPA

Release 6

2002IMS with GERAN/UTRAN accessHSDPA

Release 5

2001Split ArchitectureRelease 4

2000EDGE, UTRANRelease 99

1999AMRRelease 98

1998GPRSRelease 97

199714.4 kb/s, HSCSDRelease 96

1995GSM (basic configuration)Phase 2

1992GSM (interim configuration)Phase 1

Freeze yearCommentRelease/Phase

Figure 1-1: 3GPP phases and releases

The Stage 2 set (general architecture, protocol structure and key concepts) of LTE/SAE standardisation documents where, according to 3GPP, completed in June 2008- though several key features where actually delayed until autumn 2008. The Stage 3 work (i.e. detailed protocol specifications) is, at the time of writing, expected for completion in December 2008. One should be aware that updates/changes/additions to the E-UTRAN/EPC specs are expected throughout 2008-09. Real-life deployment of LTE/SAE-based networks should therefore not be expected until 2009-10. The reader is strongly encouraged to regularly check the 3GPP website (www.3gpp.org) for new versions of the standardisation documents referenced at the end of each chapter in the current document.


1.2 Evolved UTRA & UTRAN 1.2.1 Network Architecture

eNB

eNB

PCRF

PGW

HSS

SGW

MME

IMS/Internet/S1-U

S1-MME

X2-C S11

Gx Rx

SGiS5Uu

Uu

X2-U

S6a

E-UTRA E-UTRAN EPC

eNB

eNB

PCRF

PGW

HSS

SGW

MME

IMS/Internet/S1-U

S1-MME

X2-C S11

Gx Rx

SGiS5Uu

Uu

X2-U

S6aeNB

eNB

PCRF

PGW

HSS

SGW

MME

IMS/Internet/IMS/Internet/S1-U

S1-MME

X2-C S11

Gx Rx

SGiS5Uu

Uu

X2-U

S6a

E-UTRA E-UTRAN EPC

Figure 1-2: The Evolved Packet System (EPS), simplified

The Evolved UTRAN consists of the evolved NodeB (eNB), providing the E-UTRA User Plane (UP) and Control Plane (CP) protocol terminations towards the UE. The eNB can be seen as a combination of the UMTS NodeB and Radio Network Controller, hosting functions like dynamic resource allocation (through packet scheduling) and radio resource management. The eNBs are interconnected with each other by means of the X2-interface, e.g. for support of handovers without data loss. The X2-interface consists of a UP instance (X2-U) and a CP instance (CP) and is described in more detail in chapter 8. The eNBs are connected by means of the S1-interface to the EPC. The S1-interface supports a many-to-many relation between eNBs and MME/SGWs and is (logically) divided into a UP instance (S1-U) and a CP instance (S1-MME). The S11-interface allows exchange of control signalling between the MME and the SGW and is a part of the EPC rather than the E-UTRAN. The S1- and S11-interfaces are described in chapter 3.

1.2.2 Requirements on E-UTRA/E-UTRAN At the onset of the LTE project a series of requirement targets relating to performance, complexity and interworking were defined. Some of these are listed below:

Peak data rate: at least 100 Mb/s DL and 50 Mb/s UL (assuming 20 MHz system bandwidth). Benchmarking targets for data rates is set to 3-4 times those of HSPA as of R6 (5 MHz bandwidth).

Control Plane (CP) latency: transition time less than 100 ms from an idle state to an active state, and less than 50 ms between a dormant state (such as R6 CELL_PCH) and an active state.



User Plane (UP) latency: less than 5 ms in unloaded condition (single user with single data stream) for small IP packet.

CP capacity: at least 200 users per cell should be supported in the active state (5 MHz system bandwidth).

Mobility: E-UTRAN should be optimized for low mobile speed (0-15 km/h) and higher speeds (15-120 km/h) should be supported with high performance. Mobility shall be maintained between 120-350 km/h (up to 500 km/h depending on the frequency band).

Coverage: the throughput and mobility targets above should be met for 5 km cells with a slight degradation for 30 km cells. Cells range up to 100 km should be possible.

Spectrum flexibility: E-UTRA shall operate in different spectrum allocations of different sizes, including 1.4, 3, 5, 10, 15 and 20 MHz in both UL and DL. Operation in paired (FDD) and unpaired (TDD) spectrum shall be supported.

Interworking: co-existence in the same geographical area and co-location with GERAN/UTRAN on adjacent channels. E-UTRAN terminals supporting also UTRAN/GERAN operation should be able to support measurement of, and handover from/to, both UTRAN and GERAN. The interruption time during a handover of real-time services between E-UTRAN and UTRAN/GERAN should be less than 300ms.

Architecture: the E-UTRAN architecture shall be packet based, supporting real-time and conversational class traffic. The architecture shall minimize the presence of "single points of failure".

Complexity: minimised number of options and avoidance of redundant mandatory features.

1.2.3 Overview of Technical Solutions The E-UTRA radio interface makes exclusive use of shared channels for both data and signalling transfer. In this respect the E-UTRA is similar to the 3GPP R5/R6 High Speed Packet Access, HSPA. The selected radio access technology, however, is very different to HSPA. Where HSPA uses WCDMA, the E-UTRA uses Orthogonal Frequency Division Multiplexing (OFDM). OFDM splits the available system bandwidth into hundreds, or even thousands, of narrow-band so-called sub-carriers. This means that a high bitrate data stream to a given UE is split by the eNB into a large number of narrow-band, low bitrate, data streams. The received parallel data streams (sub-carriers) are then de-multiplexed by the UE in order to re-create the original high bitrate data stream. This has several advantages over WCDMA:

Better spectral efficieny. More information can be sent using the same system bandwidth as compared to a single-carrier system.

Flexible/scalable spectrum allocation. The system bandwidth can be expanded in increments (by adding more sub-carriers) as more spectrum becomes available to the operator. For example, the initial system roll-out may use a system bandwidth of 1.4 MHz and at a later stage this may be increased to, say, 5 MHz.

Better performance under multipath fading conditions. Multipath

effects leads to so-called frequency selective fading, which is much more damaging to a wideband signal than to a narrowband signal (the sub-carrier).

There are, of course, drawbacks with OFDM as well. One such drawback is that an OFDM signal exhibits a very high peak-to-average power ratio (PAPR). This is not really a problem on the network side, but leads to very inefficient use of power amplifiers, and hence high power consumption, in a mobile terminal. The E-UTRA system therefore uses a variant of OFDM for uplink transmission that reduces PAPR. This variant of OFDM is called Single-Carrier Frequency Division Multiple Access (SC-FDMA). Despite the name, there is very little that differentiates SC-FDMA from classic OFDM.

TDD2300 MHz 2400 MHz2300 MHz 2400 MHz40






TDD2010 MHz 2025 MHz 2010 MHz 2025 MHz 34


...

FDD758 MHz 768 MHz788 MHz 798 MHz14


FDD[TBD] [TBD][TBD] [TBD]12

FDD1475.9 MHz 1500.9 MHz1427.9 MHz 1452.9 MHz11






FDD869 MHz 894MHz824 MHz 849 MHz5

FDD2110 MHz 2155 MHz1710 MHz 1755 MHz 4




DuplexMode

DownlinkFlow - Fhigh

UplinkFlow - Fhigh

E-UTRABand







TDD2010 MHz 2025 MHz 2010 MHz 2025 MHz 34


...



FDD[TBD] [TBD][TBD] [TBD]12







FDD869 MHz 894MHz824 MHz 849 MHz5

FDD2110 MHz 2155 MHz1710 MHz 1755 MHz 4




DuplexMode

DownlinkFlow - Fhigh

UplinkFlow - Fhigh

E-UTRABand

Figure 1-3: E-UTRA frequency bands

The LTE physical layer specifications are written in such a way that it does not really matter on what physical carrier frequency the system is deployed. The table above shows the (currently) supported frequency bands, FDD and TDD, for LTE.


The use of Multiple Input Multiple Output antenna arrays (MIMO) is an integral part of the E-UTRA standard. The standard supports up to four transmit/receive antennas while the expected baseline configuration is two transmit antennas at the eNB and two receive antennas at the UE. In short, MIMO can be used in two different ways:

To transmit more information over the radio interface without using more bandwidth than a single antenna system. The number of antennas used increases the system capacity in a linear manner, i.e. two antennas allows twice the amount of information to be transmitted (or, equivalently, the bitrate is doubled).

To transmit the same information, with the same bitrate as a single

antenna system, but with less output power (or higher reliability).

The E-UTRA physical layer channel processing chain (channel coding and modulation) is very similar to what is used today for HSPA. It was agreed at an early stage in the standardisation process that Turbo coding should be used for error correction purposes and that the supported data modulation schemes should be QPSK, 16QAM, and 64QAM for downlink and uplink. The mapping of modulation symbols onto physical channel resources is very different compared to HSPA though. The nature of OFDM gives rise to the concept of 2-dimensional radio resources. The information to be transmitted over the radio interface is mapped onto a 2-dimensional time-frequency resource grid. The OFDM-based E-UTRA physical layer is described in all its glorious detail in chapter 7. (A common misunderstanding is that OFDM, by itself, makes very high bit rates possible. This is not true. Rather, the very high bit rates mentioned for E-UTRA are made possible first and foremost by a higher transmission bandwidth (up to 20MHz), higher order modulation (64QAM) and the support for MIMO with up to four antennas).

75 376

51 024

51 024

25 456

5 160

UplinkMax TB bits

transmitted per TTI

Yes

No

No

No

No

Uplink Support for

64QAM

4

2

2

2

1

DownlinkMax. spatial mux. layers

3 667 200

1 827 072

1 237 248

1 237 248

250 368

DownlinkTotal number of soft channel bits

[ 3434 ]151 376302 7525

[ 1832 ]75 376150 752 4

[ 1373 ]75 376102 0483

[ 687 ]51 02451 0242

[ 138 ]10 29610 2961

Total L2 buffer size

(kbyte)

DownlinkMax TB bits

received per TTI

DownlinkTotal DL-SCH bits received per TTI

UECategory

75 376

51 024

51 024

25 456

5 160

UplinkMax TB bits

transmitted per TTI

Yes

No

No

No

No

Uplink Support for

64QAM

4

2

2

2

1

DownlinkMax. spatial mux. layers

3 667 200

1 827 072

1 237 248

1 237 248

250 368

DownlinkTotal number of soft channel bits

[ 3434 ]151 376302 7525

[ 1832 ]75 376150 752 4

[ 1373 ]75 376102 0483

[ 687 ]51 02451 0242

[ 138 ]10 29610 2961

Total L2 buffer size

(kbyte)

DownlinkMax TB bits

received per TTI

DownlinkTotal DL-SCH bits received per TTI

UECategory

Figure 1-4: UE categories

There are 5 different UE categories defined for LTE operation. Each LTE UE category combines both downlink and uplink characteristics. This is in stark contrast to HSPA where terminal categories are defined separately for the downlink and for the uplink, giving rise to a large number of possible combinations- each of which must be included in the terminal test specifications.


The channel and protocol architecture for E-UTRAN layer 2 and layer 3 is quite similar to the one used in UTRAN today. For example, the UE protocol stack is close to identical and the channel hierarchy is still divided into logical, transport and physical channels. The E-UTRA/E-UTRAN layer 3 and layer 2 protocols are described in chapters 2-6 and chapter 8.

1.2.4 Evolved HSPA (eHSPA)

SGSN

Iur

IMS / Internet /GGSNIu/Gn Gi

RNC

NB

Iu

Gn

SGSN

Iur

IMS / Internet /GGSNIu/Gn Gi

RNC

NB

Iu

Gn

SGSN

Iur

IMS / Internet /IMS / Internet /GGSNIu/GnIu/Gn GiGi

RNC

NBNB

IuIu

Gn

Figure 1-5: eHSPA network architecture

A parallel 3GPP R8 project to LTE and SAE is the Evolved High Speed Packet Access, eHSPA, project (also referred to as HSPA+). The eHSPA features represent a logical evolution from todays HSDPA and HSUPA systems. Roughly speaking, the eHSPA project focuses on three areas:

Optimising HSPA for real-time packet data services, like VoIP. A large part of achieving this goal relates to a more efficient use of the HSPA control channels.

Increasing the system and user throughput. This is achieved by the

introduction of higher order modulation (64QAM) and MIMO for HSPA. The theoretical maximum bit rate is around 40Mb/s for the DL and around 12Mb/s for the UL.

Simplifying the network architecture. The eHSPA NodeB will take

on parts of, or all of, the functionality of the RNC. In addition, the SGSN will be removed from the User Plane path (the so-called direct tunnel solution) allowing IP packets to be routed directly between eHSPA NodeB and GGSN.

Thus, E-UTRA/E-UTRAN and Evolved HSPA have many concepts in common (collapsed architecture, 64QAM, MIMO). As a matter of fact, the performance (bit rates, spectral efficiency etc) of eHSPA R8 is very close to the performance of E-UTRA with 5MHz channel bandwidth. This has led to some level of debate whether to refer to eHSPA as a migration path or a complement or a competing technology.


1.3 Evolved Packet Core 1.3.1 Network Architecture

Iu-PS

S1-MME

S1-U

SWnNon-trustedIP access

GERAN

UTRAN

TrustedIP access

Gb/Iu

HSS

S6a

IMS / Internet /SGW

MME

S5 SGi

S11

S4S3

SGSN

S12 SPR

Gr

PCRF

Sp

Gx Rx

S2a

E-UTRANX2-C

X2-U

ePDG HSS/ AAASWm

S2b

PGW

S6b

OFCS

OCS

Gy

Gz

S10

Iu-PS

S1-MME

S1-U

SWnNon-trustedIP access

GERAN

UTRAN

TrustedIP access

Gb/Iu

HSS

S6a

IMS / Internet /SGW

MME

S5 SGi

S11

S4S3

SGSN

S12 SPR

Gr

PCRF

Sp

Gx Rx

S2a

E-UTRANX2-C

X2-U

ePDG HSS/ AAASWm

S2b

PGW

S6b

OFCS

OCS

Gy

Gz

S10

Iu-PS

S1-MME

S1-U

SWnSWnNon-trustedIP access

Non-trustedIP access

GERANGERAN

UTRANUTRAN

TrustedIP accessTrusted

IP access

Gb/Iu

HSS

S6a

IMS / Internet /IMS / Internet /SGW

MME

S5 SGiSGi

S11

S4S3

SGSN

S12S12 SPR

Gr

PCRF

Sp

Gx RxRx

S2aS2a

E-UTRANX2-C

X2-UE-UTRAN

X2-C

X2-U

X2-C

X2-U

ePDG HSS/ AAASWm

S2bS2b

PGW

S6bS6b

OFCS

OCS

GyGy

Gz

S10S10

Figure 1-6: The Evolved Packet System (EPS), detailed

Figure 1-6 shows the network architecture of the Evolved Packet Core (EPC). The EPC consists of three main nodes: the Mobility Management Entity (MME), the Serving Gateway (SGW) and the Packet Data Network Gateway (PGW). The MME may be co-located with the SGW, and the SGW may be co-located with the PGW. Hence, the standard allows a completely collapsed one-node core network or a distributed (easily scalable) core network, or any possible combination in-between. The MME connects to the E-UTRAN via the S1-MME interface and is present solely in the CP. It is responsible for handling mobility and security procedures such as network attach, tracking area updates (similar to location/routing area updates) and authentication. The MME also connects to the SGSN via the S3-interface and to the SGW via the S11-interface. These interfaces are used for signalling related to UP bearer management. The SGW connects to the E-UTRAN via the S1-U interface and is present solely in the UP. Its prime responsibility is routing and forwarding of user IP-packets. It acts as a UP anchor when the UE moves between 3GPP radio access technologies (S4-interface). The S12-interface is used for data transfer if the direct tunnel solution is supported in UTRAN. The PGW connects to the SGW via the S5-interface and to external packet data networks (or IMS) via the SGi-interface. It is responsible for the enforcing of QoS and charging policies. It also acts as a UP anchor when the UE moves between 3GPP and non-3GPP radio access (S2-interfaces).



Additional network nodes/functions, some shown in figure 1-6, may be present as well. For example, an evolved Packet Data Gateway (ePDG) is needed for non-trusted IP access and a Policy and Charging Rules Function (PCRF) is required for IMS controlled QoS and charging mechanisms. For the purpose of charging there may also be an Online Charging System (OCS) and/or an Offline Charging System (OFCS) present. The Home Subscriber Server (HSS) holds subscription profiles and security related parameters. Additional subscription/security databases may also be present, such as the Subscription Profile Repository (SPR) and the 'triple-A' server (AAA, short for Authentication, Authorization and Accounting).

1.3.2 Requirements on the EPC A (rather long) list of general requirements has been set up as guidelines for the standardisation work related to the EPC. Some of those are:

3GPP and non-3GPP access systems shall be supported. Scalable system architecture and solutions without compromising

the system capacity (e.g. by separating CP from UP). CP response time shall be such that the UE can move from an idle

state to one where it is sending/receiving data in less than 200 ms. Basic IP connectivity is established during the initial access phase

(hence, the UE is always-on). The Mobility Management (MM) solution shall be able to

accommodate terminals with different mobility requirements (fixed, nomadic and mobile terminals).

The MM functionality shall allow the network operator to control the type of access system being used by a subscriber.

MM procedures shall provide seamless operation of both real-time (e.g. VoIP) and non real-time applications.

In order to maximise users' access opportunities, the architecture should allow a UE that is roaming to use a non-3GPP access (e.g. WLAN. For example, it should be possible for a user to use a WLAN access network with which only the visited operator has a direct relationship (not the home operator).

The evolved system shall support Ipv4 and Ipv6 connectivity. Access to the evolved system shall be possible with R99 USIM.

(Please note that this also dis-allows access using SIM) The authentication framework should be independent from the used

access network technology. The SAE/LTE system shall support network-sharing functionality. It shall be possible to support service continuity between IMS over

SAE/LTE access and the Circuit Switched (CS) domain. It shall be possible for the operator to provide the UE with access

network information pertaining to locally supported 3GPP and non-3GPP access technologies.


1.4 References 23.401 GPRS enhancements for E-UTRAN access 23.402 Architecture enhancements for non-3GPP accesses 25.999 High Speed Packet Access (HSPA) evolution, FDD 36.300 E-UTRA/E-UTRAN; overall description; Stage 2

Apis Technical Training AB LSIG - NAS Copyright Apis Technical Training AB 2008. All rights reserved. 2-1

2 NAS Protocols

2.1 INTRODUCTION .................................................................................2-2

2.1.1 NAS Functionality.....................................................................2-2

2.1.2 NAS Area Concepts and Identities ..........................................2-3

2.2 NAS SIGNALLING PROCEDURES .......................................................2-4

2.2.1 EMM Procedures .....................................................................2-4

2.2.2 ESM Procedures ......................................................................2-5

2.2.3 NAS States and State Transitions ...........................................2-6

2.3 NAS MESSAGE FORMATS.................................................................2-8

2.4 NAS SECURITY FUNCTIONS..............................................................2-9

2.4.1 Authentication and Key Agreement .........................................2-9

2.4.2 Ciphering and Integrity Protection..........................................2-11

2.5 REFERENCES .................................................................................2-12

2.1 Introduction

NAS

RRC

PDCP

RLC

MAC

PHY

RRC

PDCP

RLC

MAC

PHY

S1AP

SCTP

IP

L1/L2

S1AP

SCTP

IP

L1/L2

NAS

UE

eNB

MME

Uu S1-MME

NAS

RRC

PDCP

RLC

MAC

PHY

RRC

PDCP

RLC

MAC

PHY

S1AP

SCTP

IP

L1/L2

S1AP

SCTP

IP

L1/L2

NAS

UE

eNB

MME

Uu S1-MME

NAS

RRC

PDCP

RLC

MAC

PHY

RRC

PDCP

RLC

MAC

PHY

S1AP

SCTP

IP

L1/L2

S1AP

SCTP

IP

L1/L2

NAS

UE

eNB

MME

Uu S1-MME

Figure 2-1: NAS protocol stack

2.1.1 NAS Functionality The Non Access Stratum (NAS) protocols are used for signalling exchange between the UE and the Mobility Management Entity (MME) in the EPC. As can be seen in figure 2-1, all NAS signalling exchange takes place transparently through the radio access network (i.e. the eNodeB will never interpret these messages). The NAS layer sits on top of the RRC layer in the UE and the S1AP layer in the MME. All NAS messages are therefore carried inside, or sent concatenated with, RRC and S1AP messages when transmitted over the radio interface and S1-interface respectively. As of EPS R8 there are only two NAS protocols defined: the EPS Mobility Management protocol (EMM) and the EPS Session Management protocol (ESM). The EMM protocol handles signalling related to UE mobility and signalling related to various security procedures. The ESM protocol handles signalling related to management of default and dedicated user plane bearers. The functionality of both protocols is very similar to the corresponding GSM/UMTS NAS protocols. The EMM protocol is modelled on the GPRS Mobility Management protocol (GMM) and the ESM protocol is modelled on the Session Management protocol (SM).


2.1.2 NAS Area Concepts and Identities The NAS layer makes use of so-called Tracking Areas (TA) for mobility management purposes. The concept of a Tracking Area is in all respects the same as the GSM/UMTS concept of a Routing Area (or Location Area). Hence, the TA is an operator defined group of cells that all belong to the area served by one MME. One or more TA may be defined for each MME. The MME is aware of the location of an attached UE at the TA level through the TA Update procedure. The TA is typically, but not necessarily, the area within which the UE is paged for incoming calls. TAI = MCC + MNC + TAC, where

TAI = Tracking Area Identity MCC = Mobile Country Code (3 digits) MNC = Mobile Network Code (3 digits) TAC = Tracking Area Code (not defined, Sept-08)

As an operator option, there may also be MME Pool Areas defined. An MME Pool Area is defined as an area within which a UE may be served without need to change the serving MME. An MME Pool Area is served by one or more MMEs ("pool of MMEs") in parallel. MME Pool Areas are a collection of complete Tracking Areas. MME Pool Areas may overlap each other, as seen in figure 2-2.

TA 1 TA 2 TA 3 TA 6 TA 7

MME 2MME 1

TA 4 TA 5

MME 1 MME 2 MME 3

MCC (3) MNC (3) MMEGI (16) MMEC (8) M-TMSI (32)

PLMN X

MME Group 1 MME Group 2

MMEI

Pool BPool A

GUMMEI

UE

UE CTX

S-TMSI

Pool C

TA 5

MME 2MME 1 MME 1 MME 2 MME 3

GUTI:

GUTIS-TMSI

TA 1 TA 2 TA 3 TA 6 TA 7

MME 2MME 1

TA 4 TA 5

MME 1 MME 2 MME 3

MCC (3) MNC (3) MMEGI (16) MMEC (8) M-TMSI (32)

PLMN X

MME Group 1 MME Group 2

MMEI

Pool BPool A

GUMMEI

UE

UE CTX

S-TMSI

Pool C

TA 5

MME 2MME 1 MME 1 MME 2 MME 3

GUTI:

GUTIS-TMSI

TA 1 TA 2 TA 3TA 1 TA 2 TA 3 TA 6 TA 7TA 6 TA 7

MME 2MME 2MME 1MME 1

TA 4 TA 5

MME 1 MME 2

TA 4 TA 5

MME 1 MME 2 MME 3MME 3MME 3

MCC (3) MNC (3)MCC (3) MNC (3) MMEGI (16) MMEC (8) M-TMSI (32)

PLMN XPLMN X

MME Group 1MME Group 1 MME Group 2MME Group 2

MMEIMMEI

Pool BPool BPool APool A

GUMMEIGUMMEI

UEUE

UE CTX

S-TMSIS-TMSI

Pool C

TA 5

Pool CPool C

TA 5

MME 2MME 1 MME 1 MME 2 MME 3MME 2MME 1 MME 1 MME 2 MME 3

GUTI:

GUTIS-TMSI

GUTI:

GUTIS-TMSIGUTI

S-TMSI

Figure 2-2: MME pool areas The EPC uses the IMSI number as the permanent user identifier (or rather, USIM identifier). As in the legacy Core Network a temporary identifier is also used, for subscriber identity confidentiality reasons, in place of the IMSI whenever possible. The temporary identifier in the EPS is called the Globally Unique Temporary Identity (GUTI).



The use of the GUTI is very similar to the use of the legacy TMSI (CS domain) and PTMSI (PS domain) numbers. There is a difference however: the GUTI explicitly links with the MME Pool Area concept. The relationship can be seen in figure 2-2. Please note that the length of MCC and MNC is in digits, while the other fields are given in bits. GUTI = MCC + MNC + MMEGI + MMEC + M-TMSI, where

MMEGI = MME Group Identifier (16 bits) MMEC = MME Code (8) M-TMSI = M- Temporary Mobile Subscriber Identity (32)

The MMEGI uniquely identifies a group ('pool') of MMEs within one network. The MMEC uniquely identifies an MME within one such group and the M-TMSI uniquely identifies one UE within one MME (the 'M' is just a label and is not an abbreviation for anything). The MMEGI together with the MMEC combines to the MME Identifier (MMEI). Thus, the MMEI uniquely identifies an MME within one core network. The MMEI together with MCC and MNC combines to the Globally Unique MME Identifier (GUMMEI). Thus, the GUMMEI uniquely identifies an MME on planet Earth. The GUTI is allocated when the UE performs initial registration (i.e. Attach) with an MME. The GUTI is then typically changed whenever the UE performs some EMM-procedure, such as TA Update. The S-TMSI is a shortened version of the GUTI that uniquely identifies the user within an MME Group (the 'S' is just a label and is not an abbreviation for anything). The shorter S-TMSI, rather than the complete GUTI, is used within most NAS messages.

2.2 NAS Signalling Procedures 2.2.1 EMM Procedures

The EMM procedures are divided into three groups: Common, Specific and Connection Management procedures. The Common procedures relate to security functions and are listed below.

Authentication: user (USIM) authentication and NAS key agreement. The procedure uses EPS Authentication Vectors (a variant of the UMTS quintets).

Security Mode Control (SMC): initiation of and control of the

NAS ciphering and integrity protection functions.

GUTI Re-allocation: provision of a new GUTI to the UE.

Identification: allows the MME to request either IMSI or IMEI from the UE when needed.


The Specific procedures relate to registration/de-registration functions.

Attach: initial registration of the UE in one MME for EPS services. The attach procedure is always combined with ESM signalling to establish basic IP-connectivity ('default bearer'). The attach procedure may also be combined with IMSI Attach, whereby the UE also becomes registered in the legacy MSC Server (this is to support the 'CS Fallback' feature).

Detach: de-registration from the network. May be performed

as a combined detach, whereby the UE becomes de-registered for EPS services and/or non-EPS services (i.e. IMSI Detach).

Tracking Area Update (TAU): performed when the UE enters

a TA not currently in its stored list of TAIs (normal TAU) or at timer expiry (periodic TAU). May also be a combined update, whereby the UE also performs a Location Area Update towards the MSC Server.

The Connection Management procedures are used for mobile terminating or mobile originating connection management and will always trigger ESM protocol procedures (for the actual call/session setup signalling).

Paging: used when the UE is in Idle mode and the network has downlink data or signalling pending. The UE responds by initiating the Service Request procedure (there is no explicit 'paging response' message defined).

Service Request (SR): used when the UE is in Idle or

Connected mode and has uplink data or signalling pending. The network responds by initiating the Authentication and/or SMC procedure.

2.2.2 ESM Procedures The ESM procedures are divided into two groups: Network Initated procedures and UE Initiated procedures. The Network Initiated procedures are used for establishment, modification or release of default or dedicated EPS bearers and are listed below.

Default EPS Bearer Context Activation: provides the UE

with basic IP-connectivity (a default bearer) to a given external Packet Data Network (PDN). The first default bearer is always established in conjunction with the Attach procedure. Subsequent default bearers, to other PDNs, are established when needed.

Dedicated EPS Bearer Context Activation: provides the UE

with a bearer associated with a certain QoS and packet filter (Traffic Flow Template, TFT).


EPS Bearer Context Modification: used by the network to modify the QoS and/or TFT for a given dedicated bearer.

EPS Bearer Context Deactivation: used by the network to

release a given dedicated or default bearer. To release a default bearer is the same as to disconnect from the associated PDN. When the last default bearer is released the UE enters the detached state.

The UE Initiated procedures are used for establishment, modification or release of default or dedicated EPS bearers.

UE Requested PDN Connection: request for basic IP-

connectivity (a default bearer) to a given external Packet Data Network (PDN). The first default bearer is always requested in conjunction with the Attach procedure. Subsequent default bearers, to other PDNs, are requested when needed. This procedure always triggers the network initiated Default EPS Bearer Context Activation procedure:

UE Requested PDN Disconnection: used by the UE to

disconnect from a given PDN.

UE Requested Bearer Resource Allocation: used by the UE to request a dedicated bearer associated with a certain QoS and TFT. This procedure triggers either the Default EPS Bearer Context Activation procedure or the EPS Bearer Context Modification procedure.

UE Requested Bearer Resource Release: used by the UE to

release a dedicated bearer.

2.2.3 NAS States and State Transitions There are separate (but mutually dependent) protocol state machines for the EMM protocol and the ESM protocol. The EMM protocol state machine relates to whether the UE is properly registered in the network or not and whether there exists an active NAS Signalling Connection between the UE and MME or not. The ESM protocol state machine deals exclusively with the existence or not of EPS bearers. The EMM protocol state machine contains two sets of states: EMM states and ECM states (EPS Connection Management). The UE is either EMM Registered or EMM Deregistered, i.e. attached or not. The ECM states are only relevant in the EMM Registered state and reflect whether there is an active NAS Signalling Connection established (ECM Connected) or not (ECM Idle).

A NAS Signalling Connection is required for any exchange of NAS messages, with the exception of the very messages that triggers the establishment of the NAS Signalling Connection itself (e.g. Attach Request or Paging).

EMM DEREGISTERED

No MME context

EMM REGISTERED

MME context: IMSI, GUTI, TA list

IP-address, Security association

ECM CONNECTED

NAS Signalling ConnectionData transfer possible

ECM IDLE

No NAS Signalling ConnectionTracking Area Updates

Attach Detach

NAS ConnectionEstablishment

NAS ConnectionRelease

ESM INACTIVE

No PDN context

ESM ACTIVE

PDN Context(s):IP-address, APN, QoS Parameters

S5 IP-address & TEIDS11 IP-address & TEID

(S1-U IP-address & TEID)

Data Transfer Possible when ECM Connected

One Default BearerZero, one or more Dedicated Bearer

EPS BearerEstablishment

Last EPS BearerReleased

EMM DEREGISTERED

No MME context

EMM REGISTERED

MME context: IMSI, GUTI, TA list

IP-address, Security association

ECM CONNECTED

NAS Signalling ConnectionData transfer possible

ECM IDLE

No NAS Signalling ConnectionTracking Area Updates

Attach Detach

NAS ConnectionEstablishment

NAS ConnectionRelease

ESM INACTIVE

No PDN context

ESM ACTIVE








ESM INACTIVE

No PDN context

ESM ACTIVE










Figure 2-3: NAS states

The ESM states are quite straightforward: when at least one (default) bearer is established the UE is in the ESM Active state, otherwise it is in the ESM Inactive state. The ESM signalling needed to establish a bearer requires that the UE is properly registered in the network. It therefore naturally follows that the UE must be in the EMM Registered state whenever it is ESM Active. It also follows that there must be a NAS Signalling Connection present during the ESM signalling phase when a bearer is being established, i.e. the UE is then ECM Connected. However, there is no requirement to keep the NAS Signalling Connection active for the lifetime of an EPS bearer. Hence, the UE may very well be ECM Idle while being ESM Active. This makes sense, since the UE may be attached for days, weeks or even months on end (all the time having a default bearer active). The NAS states (MME related states) are aligned with the RRC states (eNodeB related states, see chapter 4). A UE in RRC Idle state is, from the MMEs point of view, in the NAS state ECM Idle. Paging or a request from higher layers to transmit uplink data or signalling will cause a transition from RRC Idle to RRC Connected, causing also a transition from ECM Idle to ECM Connected. This is not shown in figure 2-3 above.


2.3 NAS Message Formats The NAS messages have different format depending on if it is an EMM message or an ESM message and also on whether the message is security protected or not. All NAS messages are octet-aligned. All EMM messages except Service Request, which has a special format, consist of a Protocol Discriminator, a Security Header Type field, a Message Type field and zero, one or more additional Information Elements (IEs, or payload 'parameters'). All ESM messages consist of a Protocol Discriminator, an EPS Bearer Id field, a Procedure Transaction Id, Message Type field and zero, one or more additional IE. Any security protected NAS message also contains a security header appended at the beginning of the message. The security header consists of a Protocol Discriminator, a Security Header Type field, a NAS Sequence Number field and a Message Authentication Code field.

EPS Bearer Id

Procedure Transaction Id

Protocol Discriminator

Other Information Elements(Mand/Opt/Cond)

Message Type

12345678

Security Header Type

Message Type



12345678

EMM Message ESM Message


MessageAuthentication

Code (4 oct)


NAS Sequence Number

12345678

Security Header

EPS Bearer Id




Message Type

12345678

EPS Bearer Id




Message Type

EPS Bearer Id




Message Type

12345678 12345678


Message Type



12345678


Message Type




Message Type



12345678 12345678

EMM Message ESM Message



Code (4 oct)


NAS Sequence Number

12345678

Security Header



Code (4 oct)


NAS Sequence Number

12345678



Code (4 oct)


NAS Sequence Number



Code (4 oct)


NAS Sequence Number

12345678 12345678

Security Header

Figure 2-4: NAS message format Protocol Discriminator (PD). The PD identifies the NAS protocol (EMM or ESM) to which the message belongs. The PD is defined in TS 24.007 and shares the same value space as the GSM/UMTS NAS protocols. Security Header Type (SHT). The SHT indicates the presence or not of a security header, i.e. whether the message is security protected or not. Message Type (MT). The MT identifies a message (e.g. 'Attach Request').



EPS Bearer Id (EBI). The EBI field specifies the EPS bearer to which the message pertains. Implicitly it also specifies the specific ESM protocol instance to which the message is addressed (there is one ESM protocol entity active per EPS bearer). Procedure Transaction Id (PTI). The PTI allows distinguishing between different parallel bi-directional ESM message flows (or 'transactions'). The PTI also links a 'request' message with its 'response' message for a given transaction. Message Authentication Code (MAC). The MAC field is the output from the NAS integrity protection algorithm (see next section) and is used in the receiver for checking the integrity of the message. NAS Sequence Number (SN). The SN field is used as input to the NAS ciphering and integrity protection algorithms.

2.4 NAS Security Functions 2.4.1 Authentication and Key Agreement

The purpose of the authentication mechanism is to protect the network against unauthorized use. It also protects the subscribers, by denying the possibility for intruders to impersonate valid users (i.e. making calls on someone else's bill). This is achieved by executing an authentication procedure (authentication challenge) whenever a subscriber requests some kind of service from the network (or initiates a signalling procedure). NAS signalling for authentication takes place between the UE and the MME but involves also the Home Subscriber Server (HSS), where the Authentication Vectors are stored/produced. The authentication procedure also includes network authentication. This process makes sure the UE knows that it is connected to a serving network that is authorised by the user's service provider. Authentication and Key Agreement (AKA) is the combined process of authenticating the user (and network) and calculating keys for NAS ciphering and integrity protection. A so-called security context is established in the UE and in the MME after a successful AKA run. The AKA procedure must, according to the specifications, be performed at least during initial attach. After that it is up to the MME node involved when to perform a new AKA run. It may be performed whenever the UE wishes to execute some signalling procedure (e.g. tracking area update) or when the UE requests some form of service (e.g. establishment of dedicated bearers speech call) or both.


An EPS Authentication Vector (AV) is produced in the HSS (or in a co-located Authentication Centre, AuC) and consists of four parameters:

RAND (128 bits) is input to a set of algorithms, together with the secret authentication key K, for calculation of RES, AUTN and KASME. The authentication key, K, is uniquely linked to one, and only one, IMSI number in the HSS/AuC. The RAND parameter from a selected AV is sent to the UE in an Authentication Request message whenever the MME wishes to perform an AKA run. This parameter is sometimes referred to as the authentication challenge or random challenge.

RES/XRES (length not defined, Sept-08) is the signed response

used for authentication. This parameter is sent in the Authentication Response message from the UE to the MME. The UE is regarded as authenticated if the RES provided by the UE matches the one stored in the selected AV in the MME. The term XRES is short for expected RES and is just an indication that the RES (i.e. XRES) stored in the MME will be compared to another version of itself (i.e. the RES sent back from the UE).

AUTN (112) is the authentication token used by the UE to validate

that the network is authorised. The AUTN is sent to the UE along with the RAND in the Authentication Request message. The AUTN is calculated in the HSS/AuC based on the Anonymity Key (AK) and the Message Authentication Code (MAC) in the same manner as in a GSM/UMTS HSS. Note: do not confuse this 'MAC' parameter with the 'MAC' present in a security protected NAS message, they are not the same!

KASME (256) is the Access Security Management Entity key, where

'ASME' is to be understood as the MME in the EPS case. KASME is derived from an HSS/AuC produced Ciphering Key (CK) and integrity Key (IK), both 128 bits long. The CK and IK keys are, in turn, calculated in the same manner as in a GSM/UMTS HSS.

The EPS system uses a security key hierarchy (figure 2-5) with multiple levels. The base keys on the top level (CK and IK) are only visible to the UE and the home network domain databases (HSS/AuC). On the next level there is KASME, which is only visible to the UE and the visited MME. KASME is, in turn, used for derivation of the ciphering and integrity keys needed to protect NAS signalling messages (i.e. signalling between UE and MME). KASME is also used for derivation of an eNodeB key, KeNB. Finally, KeNB is used for derivation of keys for ciphering and integrity protection of RRC signalling messages and a key for the ciphering of user data over the radio interface (i.e. between UE and eNodeB).

KCK, IK

KASME

IKNASCKNAS

KeNB

CKUP CKCP IKCP

Never leaves Home Domain

Never leaves EPC(KASME is vPLMN specific)

Only used in access NW(KeNB is cell specific)

K

CK, IK

KASME

IKNASCKNAS

KeNB

CKUP CKCP IKCP

Never leaves Home Domain

Never leaves EPC(KASME is vPLMN specific)

Only used in access NW(KeNB is cell specific)

K

CK, IKCK, IK

KASMEKASME

IKNASCKNAS IKNASCKNAS

KeNBKeNB

CKUP CKCP IKCPCKUP CKCP IKCP

Never leaves Home DomainNever leaves Home Domain

Never leaves EPC(KASME is vPLMN specific)Never leaves EPC(KASME is vPLMN specific)

Only used in access NW(KeNB is cell specific)Only used in access NW(KeNB is cell specific)

Figure 2-5: EPS security key hierarchy

This hierarchy allows the keys in the Home domain, the (visited) EPC domain and the Access domain to be cryptographically separate, while still being produced by the same set of Home domain controlled base keys.

2.4.2 Ciphering and Integrity Protection

Other IEs (one or more message)Standard Header

ProtocolDiscriminator

SecurityHeader Type

Encryption

Integrity

NAS SN

Other inputCKNAS

IKNASOther input

NAS SN

NAS SN

Security Header

MAC



SecurityHeader Type

Encryption

Integrity

NAS SN

Other inputCKNAS

IKNASOther input

NAS SN

NAS SN

Security Header

MAC



SecurityHeader Type


SecurityHeader Type

EncryptionEncryption

IntegrityIntegrity

NAS SNNAS SN

Other inputOther inputCKNASCKNAS

IKNASIKNASOther inputOther inputOther input

NAS SNNAS SN

NAS SNNAS SN

Security HeaderSecurity Header

MACMAC

Figure 2-6: Ciphering and integrity protection of NAS messages

A simplified version of the processing sequence for ciphering and integrity protection of NAS messages can be seen in figure 2-6 above. The message to be encrypted is fed to the encryption algorithm together with the NAS Ciphering Key, the NAS Sequence Number and additional input parameters. The output is an encrypted message (the NAS SN is not encrypted). The encrypted message is then fed to the integrity algorithm together with the NAS Integrity Key, the NAS SN and additional input parameters. The output is the calculated MAC, which is placed in the security header appended to the message.



2.5 References 24.007 Mobile radio interface layer 3; general aspects 24.301 Non-Access Stratum (NAS) protocol for EPS; stage 3 33.401 3GPP System Architecture Evolution: security architecture 33.821 Rationale and track of security decisions in LTE/SAE

Apis Technical Training AB LSIG - S1 and S11 Copyright Apis Technical Training AB 2008. All rights reserved. 3-1

3 S1 and S11-interface (S1AP & GTP)

3.1 INTRODUCTION .................................................................................3-2

3.2 S1-INTERFACE .................................................................................3-3

3.2.1 S1-MME: S1AP Procedures ....................................................3-3

3.2.2 S1-MME: SCTP and Transport Protocols ................................3-4

3.2.3 S1-U: GTP-U Procedures ........................................................3-5

3.3 S11-INTERFACE ...............................................................................3-6

3.3.1 GTP-C Procedures...................................................................3-6

3.3.2 GTP Header Format.................................................................3-7

3.4 EPS QOS CONCEPTS ......................................................................3-8

3.4.1 User Plane Bearer Establishment............................................3-8

3.4.2 QoS Parameters ....................................................................3-10

3.5 REFERENCES .................................................................................3-12

3.1 Introduction

S1AP

SCTP

IP

L1/L2

S1AP

SCTP

IP

L1/L2

eNB MME

S1-MME

GTP-C

UDP

IP

L1/L2

GTP-C

UDP

IP

L1/L2

S11

SGW

GTP-U

UDP

IP

L1/L2

eNB

S1-U

GTP-U

UDP

IP

L1/L2

SGW

S1AP

SCTP

IP

L1/L2

S1AP

SCTP

IP

L1/L2

eNB MME

S1-MME

GTP-C

UDP

IP

L1/L2

GTP-C

UDP

IP

L1/L2

S11

SGW

S1AP

SCTP

IP

L1/L2

S1AP

SCTP

IP

L1/L2

eNB MME

S1-MMES1-MME

GTP-C

UDP

IP

L1/L2

GTP-C

UDP

IP

L1/L2

S11S11

SGW

GTP-U

UDP

IP

L1/L2

eNB

S1-U

GTP-U

UDP

IP

L1/L2

SGW

GTP-U

UDP

IP

L1/L2

eNB

S1-US1-U

GTP-U

UDP

IP

L1/L2

SGW

Figure 3-1: S1/S11 protocol stacks

The S1-interface connects E-UTRAN (eNBs) with the EPC. The S1-interface is an IP-based interface and can therefore be seen as a point to multi-point interface. The Control Plane (CP) instance of the S1-interface (S1-MME) uses the S1 Application Protocol (S1AP) for control signalling purposes between the eNB and the MME. The S1AP protocol runs on top of the Stream Control Transmission Protocol (SCTP). The User Plane (UP) instance of the S1-interface (S1-U) uses the GPRS Tunnelling Protocol- User plane (GTP-U) for user data tunnelling. The termination point on the EPC side for S1-U is the Serving Gateway, SGW. The S11-interface is, like the S1-interface, an IP-based point to multi-point interface. The S11-interface is used for signalling between the MME and the SGW (upper right in figure 3-1) and does not have a UP instance. The S11-interface uses the GPRS Tunnelling Protocol- Control plane (GTP-C) for control signalling purposes. Please see figure 1-2 for the network architecture corresponding to the protocol stacks above.



3.2 S1-Interface 3.2.1 S1-MME: S1AP Procedures

The S1AP protocol is used for control signalling exchange between eNB and MME. The S1 procedures are divided into Context management, EPS Bearer management, Handover, Location Reporting, Node management and 'Other' procedures. All UE associated signalling takes place over a logical S1 Connection. The UE-specific S1 Connection is identified in each node with an S1AP UE Identifier. Thus, all S1AP messages pertaining to a specific UE will carry two reference numbers: the S1AP UE Id selected by the eNB and the S1AP UE Id selected by the MME. One such pair of reference numbers uniquely identifies a UE context in a node.

Context Management Procedures Initial Context Setup. This procedure supports the establishment of the necessary overall initial UE Context in the eNB to enable fast Idle-to-Active transition. The UE Context includes: EPS Bearer context, security context, roaming restriction, UE capability info, subscriber type info etc. The procedure is always initiated from the MME, typically in combination with network registration (Attach or TA Update). The logical S1 Connection is established after successful execution of this procedure. UE Context Modification. The purpose of this procedure is to modify an already established UE context in the eNB (e.g. change the eNB security key). The procedure is always initiated from the MME. UE Context Release. The purpose of this procedure is to release the logical S1 Connection related to a specific UE (thus also releasing the associated UE context). The procedure may be initiated from the MME (e.g. due to completed NAS signalling transaction) or from the eNB (due to handover, timer expiry or other radio related reason).

EPS Bearer Management Procedures The EPS Bearer management procedures are responsible for establishing, modifying and releasing E-UTRAN resources for user data transport with a given QoS (once an initial UE context is available in the eNB). The procedures are always initiated from the MME, with the exception of EPS Bearer Release that may be initiated from the eNB.

Handover Procedures Handover preparation and execution signalling over the S1-interface is only needed during inter-RAT handover or when there is no X2-interface present between the Source eNB and the Target eNB. For a normal X2-interface initiated inter-eNB handover a S1AP Handover Notification message is sent from the Target eNB to the MME after the UE has been successfully transferred to the new cell.


Location Reporting Procedures These procedures allow the MME to request the current location (i.e. cell) of the UE. The eNB can be asked to report immediately or when the UE leavers the current cell.

Node Management Procedures S1 Setup. The purpose of the S1 Setup procedure is to exchange application level data needed for the eNB and MME to interoperate correctly on the S1-interface. This procedure shall be the first S1AP procedure triggered after the SCTP association (see below) has become operational. The eNB informs the MME about its eNB Identity number and which TAs it supports. The MME informs the eNB about its MME Identity number (GUMMEI) and which PLMNs it supports. Configuration Update. The purpose of this procedure is to exchange application level data that have changed since the last S1 setup procedure was executed. The procedure may be initiated from the eNB or the MME. Reset. The purpose of the Reset procedure is to initialise or re-initialise the S1AP UE contexts, in the event of a failure in the MME or eNB. This procedure does not affect the application level configuration data exchanged during the S1 Setup procedure.

Other Procedures Paging. Enables the MME to page the UE in a specific eNB. The MME initiates the paging procedure by sending a Paging message to each eNB with cells belonging to the Tracking Area(s) in which the UE is registered. The paging response back to the MME is initiated on the NAS layer and is forwarded to MME by the eNB as part of the NAS Signalling Transport procedure.

NAS Signalling Transport. This procedure provides means to transport NAS messages to/from a given UE over the S1-interface. (This procedure is in all respects the same as the RRC Information Transfer procedure described in chapter 4).

3.2.2 S1-MME: SCTP and Transport Protocols The Stream Control Transmission Protocol (SCTP) is used to support the exchange of S1AP signalling messages between eNB and MME. SCTP is a session-oriented protocol providing connection-oriented, error-free, flow-controlled, in-sequence transfer of signalling messages over IP. It is in many respects similar to TCP, but there are some differences. One such difference is that SCTP is message oriented while TCP is byte oriented. Another difference is that the in-sequence delivery is optional for SCTP (i.e. it can be turned off) while it is always mandatory for TCP.

SCTP makes use of so-called Stream Identifiers to identify a logical signalling connection (stream) between two network nodes. A single SCTP association per S1-MME interface instance is used, with different pairs of Stream Identifiers for S1-MME non-UE associated and UE associated procedures. An SCTP PDU consists of a header and one or more 'chunk' fields. The payload is either higher layer information (an S1AP message in this case) or SCTP layer control information. The chunk type 'DATA' is used for transport of higher layer information.

Common Header(12 bytes)

Set per association

at Initialisation

Registeredwith IANA

0 1 2 3 4 5 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 16 73210

Source Port Destination Port

Verification Tag

Checksum

Chunk LengthChunk FlagsChunk TypeChunk Header

(4 bytes)

Transport Sequence Number

Payload Protocol Id

Chunk Values(variable)

Stream Identifier Stream Sequence Number (opt)

Payload or Control

Chunk LengthReservedType = DATA U B E

DATA, possibly segmented(e.g. X2AP or S1AP message)

General SCTP PDU Format

0 1 2 3 4 5 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 16 73210

The DATA Chunk

Common Header(12 bytes)

Set per association

at Initialisation

Registeredwith IANA

0 1 2 3 4 5 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 16 73210

0 1 2 3 4 5 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 16 73210


Verification Tag

Checksum


Verification Tag

Checksum

Chunk LengthChunk FlagsChunk Type Chunk LengthChunk FlagsChunk TypeChunk Header

(4 bytes)

Transport Sequence Number

Payload Protocol Id

Chunk Values(variable)

Stream Identifier Stream Sequence Number (opt)

Payload or Control

Chunk LengthReservedType = DATA U B E

DATA, possibly segmented(e.g. X2AP or S1AP message)

General SCTP PDU Format

0 1 2 3 4 5 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 16 73210

0 1 2 3 4 5 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 16 73210

The DATA Chunk

Figure 3-2: SCTP PDU format

The transport layer uses standard Internet Engineering Task Force (IETF) defined protocols, i.e. IP running over the selected data link and physical layer protocols. These transport layer protocols are not discussed further in this document.

3.2.3 S1-U: GTP-U Procedures The main task of the GTP-U protocol is encapsulation and tunnelling of user data packets between network nodes. It is used on the S1-interface, the X2-interface (between eNBs) and on a number of additional EPC User Plane interfaces. Each user data IP-packet is encapsulated by adding a GTP header. The header contains, among other things, a Tunnel Endpoint Identifier (TEID). The TEID is a locally allocated reference number that uniquely identifies a GTP tunnel in the node that allocated it. Thus, a GTP tunnel has two TEIDs associated with it (one in each end). Please see section 3.3.2 for a more detailed description of the GTP header.



3.3 S11-Interface The GTP protocol defined for EPS is very similar to the legacy GTP protocol in use already since the introduction of GPRS in Release 97. Some 3GPP standardisation documents refer to the 'EPS GTP' as Evolved GTP (eGTP). However, one could as well simply refer to the 'EPS GTP' as 'GTP version 2' (GTP version 1 was introduced in R99). The GTP Control Plane (GTP-C) protocol is used on a number of EPC interfaces. The exact set of GTP-C procedures in use is therefore interface-dependent. In the following, only those GTP-C procedures that are relevant for the S11-interface are described.

3.3.1 GTP-C Procedures The GTP version 2 specification does not divide GTP functions so much into 'procedures' as into 'scenarios'. For example, the specific GTP-C message (and thus also procedure) to use for releasing an EPS bearer in the SGW will be different depending on whether the release was UE initiated or eNB/MME initiated. A consequence of this is that there are several GTP-C messages/procedures that achieve, more or less, the same thing. For ease of reading the following descriptions do therefore not include all scenarios that will trigger a given GTP procedure. Instead, the reader is encouraged to consult the GTP version 2 specification: TS 29.274. Create Session. This procedure is initiated from the MME towards the SGW when the UE requests activation of a default EPS bearer due to initial Attach or when the SGW changes due to the UE performing a TA Update. Create Bearer. This procedure is initiated from the MME towards the SGW due to network initiated establishment of a dedicated EPS bearer. Allocate Bearer Resource. This procedure is initiated from the MME towards the SGW due to UE initiated establishment of a dedicated EPS bearer. Modify Bearer. This procedure is initiated from the MME towards the SGW when a dedicated bearer needs to be released due to network initiated S1 Release, or modified due to the UE performing TA Update that does not trigger change of SGW. Delete Session. This procedure is initiated from the MME towards the SGW due to UE initiated release of a default bearer. Release TFT Filter. This procedure is initiated from the MME towards the SGW due to UE initiated release of a dedicated EPS bearer.

Update User Plane. This procedure is initiated from the MME towards the SGW when a GTP tunnel needs to be modified (moved from one eNB to another) as a result of handover. Downlink Data Notification. This procedure is initiated from the SGW towards the MME in order to trigger paging for an incoming call/session. Echo. A GTP-C entity (within eNB, SGW, MME or other node) may send an Echo Request to find out if the peer GTP entity is 'alive'. The peer entity shall respond with an Echo Response message. This procedure is relevant for both GTP-C and GTP-U. Version Not Supported. This procedure is used to inform a peer GTP entity that the GTP version used in received message is not supported. The sending entity also includes an indication of the 'highest' version of the GTP protocol that it supports. This procedure is relevant for both GTP-C and GTP-U.

3.3.2 GTP Header Format A GTP PDU consists of a GTP header, zero one or more extension headers and a GTP message. The GTP message is either a GTP-C or a GTP-U message. Thus, GTP-C and GTP-U use the same header format but the use of a given header field is not necessarily the same for GTP-C and GTP-U.

Tunnel EndpointIdentifier, TEID

(4 oct)

12345678

Sequence Number(2 oct)

Spare Octets(2 oct)

Message Type

TFFSVersion SE FFS

Message Length excl mandatory header (2 oct)

CR Extension Header Type NEH

Mandatory Header(GTP-C and GTP-U)

All messages, exceptEcho Req/Resp and

Version Not Supported

All GTP-C messages

R8 extension: PDCPsequence number

Spare Extension Header Length

Extension Value(s)Padding if needed

(n x 4 oct)

Tunnel EndpointIdentifier, TEID

(4 oct)

12345678 12345678


Spare Octets(2 oct)


Spare Octets(2 oct)

Message Type

TFFSVersion SE FFS


Message Type

TFFSVersion SE FFS


CR Extension Header Type NEH

Mandatory Header(GTP-C and GTP-U)

All messages, exceptEcho Req/Resp and

Version Not Supported

All GTP-C messages

R8 extension: PDCPsequence number

Spare Extension Header Length

Extension Value(s)Padding if needed

(n x 4 oct)

Figure 3-3: GTP header format

The length of a GTP version 2 header is always a multiple of 4 octets, containing at least the mandatory part shown in the figure above. The usage of the different fields is described below:



Version: specifies the GTP protocol version (version 2 in this case). FFS: For Further Study (currently not standardised). T flag: signals the presence or not of the TEID field. E flag: signals the presence or not of the first extension header. S flag: signals the presence or not of the sequence number field. Message Type: specifies the GTP message (e.g. 'Echo Request'). Message Length: specifies the length in octets of the GTP message, excluding the mandatory 4-octet header. Tunnel Endpoint Identifier (TEID): together with an IP-address and a UDP port number, the TEID uniquely identifies a GTP tunnel. The TEID is unique per EPS bearer for GTP-U and per PDN connection for GTP-C. Sequence Number: allows in-order delivery of user plane PDUs (and re-ordering of forwarded user plane PDUs during handover) in the case of GTP-U. For GTP-C the sequence number links a 'request' message with its 'response', thus acting as a transaction identifier. Extension Header Type: specifies the type of extension header. The current R8 GTP standard only defines one extension header: the PDCP sequence number (passed between nodes during handover). Comprehension Required (CR): specifies to the receiving entity if the extension header must be understood or whether it can be skipped in case the receiver does not recognise it. Next Extension Header flag (NEH): indicates the presence or not of yet another extension header, immediately following the current one.

3.4 EPS QoS Concepts 3.4.1 User Plane Bearer Establishment

The EPS specifications separate between default bearers and dedicated bearers. With a default bearer is meant basic IP-connectivity between the UE and some external Packet Data Network (PDN). Such a bearer does not guarantee any level of QoS and is typically used for signalling purposes only (or service with very low requirements). With a dedicated bearer is meant any other bearer, besides the default bearer, that is established between the UE and the same PDN. There may be zero, one or more dedicated bearers active for each PDN (but only one default bearer).

There are different ways of establishing dedicated bearers: UE initiated, EPC initiated and IMS/PCC initiated bearer establishment. These different mechanisms can all be realised with a limited number of signalling procedures or, rather, blocks of procedures as seen (in microscopic text) in figure 3-4 below.

E: DedicatedBearerActivation

PCCProvisionCREATE BEARER REQ

CREATE B. REQESM: ACT DED EPS BEARER CTX REQ ESM: ACTIVATE DEDICATED

EPS BEARER CTX REQ

ESM: ACTIVATE DEFAULTEPS BEARER CTX ACC

ESM: ACT DED EPS BEARER CTX ACCPCC

Prov Ack

CREATE BEARER RESP CREATE B. RESP

D: UE InitiatedBearerResourceAllocation

ESM: BEARER RESOURCEALLOCATION REQ

ESM: BEARER RESOURCE ALLOC REQPull PCCProvision

REQUEST BEARERRESOURCE ALLOCATION

REQ BEARERRES. ALLOC.

C: IMS-basedSessionNegotiation

SIP/SDP

A: Paging GTP-U: DATAPAGING

DL DATA NOTIFICATIONPAGINGDATA

B: ServiceRequest EMM: SERVICE REQUEST EMM: SERVICE REQUEST

NAS/AS AUTHENTICATION & SMC

PGWSGWMMEeNB

S5: GTP-CS11: GTP-CS1-MME: S1APUu: RRC/NAS

PCRF

Gx: Diameter




EPS BEARER CTX REQ



Prov Ack








SIP/SDP


DL DATA NOTIFICATIONPAGINGDATA



PGWSGWMMEeNB

S5: GTP-CS11: GTP-CS1-MME: S1APUu: RRC/NAS

PCRF

Gx: Diameter




EPS BEARER CTX REQ



Prov Ack





EPS BEARER CTX REQ



Prov Ack













SIP/SDPC: IMS-basedSessionNegotiation

SIP/SDP


DL DATA NOTIFICATIONPAGINGDATAA: Paging GTP-U: DATA

PAGINGDL DATA NOTIFICATIONPAGING

DATA




NAS/AS AUTHENTICATION & SMCNAS/AS AUTHENTICATION & SMC

PGWSGWMMEeNBeNB

S5: GTP-CS11: GTP-CS1-MME: S1APUu: RRC/NAS S5: GTP-CS11: GTP-CS1-MME: S1APUu: RRC/NAS

PCRF

Gx: DiameterGx: Diameter

Figure 3-4: Procedures for EPS bearer establishment

The UE initiated establishment case is, perhaps, the mechanism most similar to how QoS is handled in legacy networks: the UE requests a certain QoS and the network responds either 'OK' or 'forget it'. For a connected mode UE this corresponds to step D in the figure followed by step E. In case the UE is in idle mode this must be preceded by step B, in order to establish a security protected NAS Signalling Connection first. The EPC initiated establishment case can be realised in a number of ways. Assuming that the UE is in idle mode we must start with paging (step A), to which the UE responds with a Service Request message (step B). The network will then push QoS parameters to the UE using the procedures in step E again (there is some GTP signalling required between steps B and E that is not visible in the figure). If the UE is already connected we can simply skip the paging and go straight for step E. The IMS/PCC initiated establishment case requires support for the IMS-based Policy and Charging Control framework (PCC), the details of which is far outside the scope of this course. In short though, neither the UE nor the EPC will in such a case be the entity selecting QoS parameters. Instead there will be a form of end-to-end 'negotiation' between the UE and whatever other entity is involved (e.g. another UE or a web server). This negotiation is done using the Session Initiation Protocol (SIP), step C in the figure above. This signalling is, from the point of view of the EPC, seen as just any other user plane IP packets being routed through the network.



However, control nodes within the IMS infrastructure will be perfectly aware of what those SIP messages contain and can then push down QoS policies to the PDN Gateway via the Policy and Charging Rules Function (PCRF). Several IMS/PCC-based scenarios can be foreseen depending on whether the UE is the entity initiating the SIP signalling or not and whether the UE is in idle or connected mode. Assume that the UE is not the entity that initiates the SIP signalling ('MT case'). If the UE is in idle mode we need to page the UE in order to deliver the first incoming SIP packet. This would then result in the sequence A, B, C and E. If the UE is already connected we skip steps A and B. Assume that the UE is the entity that initiates the SIP signalling ('MO case'). If the UE is in idle mode it must start with a Service Request, so that we can send the first outgoing SIP packet over a security-protected connection. The sequence then becomes B, C and E. There are more cases possible but the point here is that we can, with a limited number of carefully defined procedures, allow a large number of scenarios to be realised.

3.4.2 QoS Parameters The EPS QoS architecture has, from a parameter point of view, been substantially simplified as compared to legacy networks. As already mentioned, there are only two types of bearers: default bearers and dedicated bearers. Furthermore, an EPS bearer either has a guaranteed bit rate (GBR) or it has not. A default bearer is always a non-GBR bearer. Subscription data in the HSS sets a maximum limit, for each PDN, on the bit rate that the network should provide for a default bearer. This parameter is called the Aggregate Maximum Bit Rate (AMBR) and cannot be changed or overridden by the EPC. A dedicated bearer can be a GBR or a non-GBR bearer. The EPC, or the PCC framework, may also assign a (variable) Maximum Bit Rate (MBR) for each dedicated bearer. The MBR may, or may not, be part of the subscription profile stored in the HSS. Both default and dedicated bearers are, besides the above mentioned bit rates, also associated with a Traffic Flow Template (TFT) and a QoS Class identifier (QCI). The TFT is a specification of a packet filter to be applied to all IP packets sent over a given bearer. A TFT could, for example, only allow TCP/IP packets or UDP/IP packets or only packets with a certain port number or destination address (or any specific combination of port, address and protocol).

The QCI is a number that, in turn, links to the acceptable/allowed packet delay budget and packet loss rate. Some of the lower QCI-values are standardised while the rest are open for operator specific definitions. The (current) QCI table can be seen in the figure below.

Best effort TCP bulk datan.a.High (~500ms)9 (non-GBR)

Killer ApplicationOperator definedOperator definedUp to 256

Preferred TCP bulk datae.g. 10-6Medium (~250ms)8 (non-GBR)

TCP interactivee.g. 10-4Medium (~250ms)7 (non-GBR)

Interactive Gaminge.g. 10-3Low (~50ms)6 (non-GBR)

IMS signallinge.g. 10-6Low (~50 ms)5 (non-GBR)

StreamingLow (e.g.10-3)250 ms4 (GBR)

Conversational PS VideoMedium (e.g. 10-2)90ms3 (GBR)

VoIPMedium (e.g.10-2)50 ms2 (GBR)

Realtime GamingHigh (e.g.10-1)< 50 ms1 (GBR)

Example ServicesPacket Loss RatePacket Delay BudgetQoS Class Identifier

Best effort TCP bulk datan.a.High (~500ms)9 (non-GBR)

Killer ApplicationOperator definedOperator definedUp to 256

Preferred TCP bulk datae.g. 10-6Medium (~250ms)8 (non-GBR)

TCP interactivee.g. 10-4Medium (~250ms)7 (non-GBR)

Interactive Gaminge.g. 10-3Low (~50ms)6 (non-GBR)

IMS signallinge.g. 10-6Low (~50 ms)5 (non-GBR)

StreamingLow (e.g.10-3)250 ms4 (GBR)

Conversational PS VideoMedium (e.g. 10-2)90ms3 (GBR)

VoIPMedium (e.g.10-2)50 ms2 (GBR)

Realtime GamingHigh (e.g.10-1)< 50 ms1 (GBR)

Example ServicesPacket Loss RatePacket Delay BudgetQoS Class Identifier

Figure 3-5: QoS Class Identifiers (QCI)

The QoS parameters mentioned in this section are translated, in an implementation dependent way, into radio interface parameters that are passed to the eNB packet scheduler (MAC protocol), allowing realisation of Data Radio Bearers that fulfil the established QoS context.



3.5 References 23.203 Policy and Charging Control architecture 23.401 GPRS enhancements for E-UTRAN access (stage 2) 29.274 GPRS; evolved GPRS Tunnelling Protocol (eGTP) for EPS 36.413 E-UTRA S1 Application Protocol (S1AP) specification

Apis Techni

LTE Signaling Overview

Documents

training document

training material

uu interface

eps overview

x2 interface x2ap

proprietary rights

stockholm sweden email

s11 interface s1ap gtp