Microsoft Word - 6. OEA000201 LTE Protocols and Procedures ISSUE 1

LTE Protocols and Procedures Contents

Issue 06 (2006-03-01) Huawei Proprietary and Confidential

Copyright © Huawei Technologies Co., Ltd

i

Contents

1 EPS Architecture .................................................................................................................... 1-2

1.1 EPS Network Elements ................................................................................................................................. 1-3

1.1.1 User Equipment ................................................................................................................................... 1-3

1.1.2 Evolved Node B ................................................................................................................................... 1-5

1.1.3 Mobility Management Entity ............................................................................................................... 1-6

1.1.4 Serving Gateway .................................................................................................................................. 1-7

1.1.5 Packet Data Network - Gateway .......................................................................................................... 1-8

1.2 EPS Interfaces ............................................................................................................................................... 1-9

1.2.1 E-UTRAN Interfaces ........................................................................................................................... 1-9

1.2.2 EPC Interfaces ..................................................................................................................................... 1-9

1.2.3 Additional Network Elements and Interfaces ..................................................................................... 1-10

2 EPS Protocols ....................................................................................................................... 2-13

2.1 EPS Signaling.............................................................................................................................................. 2-14

2.2 EPS Protocols .............................................................................................................................................. 2-15

2.2.1 NAS Functionality ............................................................................................................................. 2-15

2.2.2 NAS Concepts and Identities ............................................................................................................. 2-16

2.2.3 EMM and ESM .................................................................................................................................. 2-18

2.2.4 NAS States and State Transitions ....................................................................................................... 2-20

2.2.5 Uu Interface ....................................................................................................................................... 2-22

2.2.6 Uu Interface - RRC ............................................................................................................................ 2-23

2.2.7 Uu Interface - PDCP .......................................................................................................................... 2-23

2.2.8 Uu Interface - RLC ............................................................................................................................ 2-24

2.2.9 Uu Interface - MAC ........................................................................................................................... 2-25

2.2.10 Uu Interface - Physical ..................................................................................................................... 2-25

2.2.11 X2 Interface ...................................................................................................................................... 2-26

2.2.12 X2 Interface - X2 Application Protocol ........................................................................................... 2-26

2.2.13 X2 Interface - Stream Control Transmission Protocol ..................................................................... 2-27

2.2.14 X2 Interface - GPRS Tunneling Protocol - User .............................................................................. 2-27

2.2.15 S1 Interface ...................................................................................................................................... 2-27

2.2.16 S1 Interface - S1 Application Protocol ............................................................................................. 2-28

2.2.17 S1 Interface - SCTP and GTP-U ...................................................................................................... 2-28

2.2.18 S11 Interface .................................................................................................................................... 2-29

Contents LTE Protocols and Procedures

ii Huawei Proprietary and Confidential


Issue 06 (2006-03-01)

2.2.19 GPRS Tunneling Protocol version 2 - Control ................................................................................. 2-29

2.2.20 S5/S8 Interface ................................................................................................................................. 2-29

2.2.21 Proxy Mobile IP ............................................................................................................................... 2-30

2.2.22 S10 Interface .................................................................................................................................... 2-30

2.2.23 SGi Interface .................................................................................................................................... 2-31

3 LTE/SAE Quality of Service ............................................................................................... 3-32

3.1 EPS Bearer Services and E-UTRA Radio Bearers ...................................................................................... 3-33

3.1.1 QoS in Packet Switched Networks .................................................................................................... 3-33

3.1.2 LTE Bearers ....................................................................................................................................... 3-33

3.1.3 The Default EPS Bearer ..................................................................................................................... 3-35

3.1.4 Dedicated EPS Bearers ...................................................................................................................... 3-35

3.1.5 EPS QoS Parameters .......................................................................................................................... 3-35

3.2 E-UTRA Radio Bearers ............................................................................................................................... 3-37

3.2.1 Signaling Radio Bearers ..................................................................................................................... 3-37

3.2.2 Data Radio Bearers ............................................................................................................................ 3-37

3.2.3 Radio Bearer QoS .............................................................................................................................. 3-38

4 Radio Resource Control ...................................................................................................... 4-40

4.1 The RRC Layer ........................................................................................................................................... 4-41

4.1.2 Services Provided To Upper Layers ................................................................................................... 4-41

4.1.3 Services Expected From Lower Layers ............................................................................................. 4-41

4.2 RRC Structure ............................................................................................................................................. 4-42

4.3 RRC States .................................................................................................................................................. 4-42

4.3.2 Functions ............................................................................................................................................ 4-43

4.4 RRC Services .............................................................................................................................................. 4-45

4.4.1 System Information ............................................................................................................................ 4-45

4.4.2 Paging ................................................................................................................................................ 4-46

4.4.3 RRC Connection Establishment ......................................................................................................... 4-47

4.4.4 Initial Security Activation .................................................................................................................. 4-48

4.4.5 RRC Connection Reconfiguration ..................................................................................................... 4-48

4.4.6 RRC Connection Re-establishment .................................................................................................... 4-49

4.4.7 RRC Connection Release ................................................................................................................... 4-50

4.4.8 Radio Link Failure ............................................................................................................................. 4-50

4.4.9 Information Transfer .......................................................................................................................... 4-51

4.4.10 Measurement Configuration ............................................................................................................ 4-51

4.4.11 Handover Configuration ................................................................................................................... 4-56

4.4.12 Cell Selection ................................................................................................................................... 4-56

4.4.13 Cell Reselection ............................................................................................................................... 4-56

5 Packet Data Convergence Protocol ................................................................................... 5-58

5.1 PDCP Operation .......................................................................................................................................... 5-59

5.1.1 Functions ............................................................................................................................................ 5-59

5.1.2 PDCP Header Compression Profiles .................................................................................................. 5-60

LTE Protocols and Procedures Contents



iii

5.1.3 PDCP Headers .................................................................................................................................... 5-61

5.1.4 PDCP ROHC ...................................................................................................................................... 5-62

5.1.5 PDCP Integrity ................................................................................................................................... 5-63

5.1.6 PDCP Ciphering ................................................................................................................................. 5-64

6 Radio Link Control and Medium Access Control .......................................................... 6-66

6.1 RLC Functions ............................................................................................................................................ 6-67

6.1.1 Services Provided to Upper Layers .................................................................................................... 6-67

6.1.2 Services Expected from Lower Layers .............................................................................................. 6-67

6.1.3 Functions ............................................................................................................................................ 6-67

6.2 RLC Modes and Formatting ........................................................................................................................ 6-68

6.2.1 Transparent Mode .............................................................................................................................. 6-68

6.2.2 Unacknowledged Mode ..................................................................................................................... 6-68

6.2.3 Acknowledged Mode ......................................................................................................................... 6-69

6.2.4 TMD PDU .......................................................................................................................................... 6-70

6.2.5 UMD PDU ......................................................................................................................................... 6-71

6.2.6 AMD PDU ......................................................................................................................................... 6-72

6.2.7 RLC Timers ........................................................................................................................................ 6-75

6.2.8 Configurable Parameters .................................................................................................................... 6-75

6.3 MAC Functions ........................................................................................................................................... 6-75

6.4 MAC Architecture ....................................................................................................................................... 6-76

6.5 MAC Formatting ......................................................................................................................................... 6-77

6.5.1 MAC Headers .................................................................................................................................... 6-77

6.5.2 MAC Subheaders ............................................................................................................................... 6-78

6.5.3 Random Access Process ..................................................................................................................... 6-81

7 X2/S1 Interface and Protocols ............................................................................................ 7-84

7.1 X2AP Functions and Procedures ................................................................................................................. 7-85

7.1.2 Functions of the X2 Application Protocol .......................................................................................... 7-85

7.1.3 X2 Elementary Procedures ................................................................................................................. 7-86

7.1.4 Message Formatting ........................................................................................................................... 7-87

7.1.5 X2 Basic Mobility Procedures - Handover Preparation ..................................................................... 7-88

7.1.6 X2 Load Indication ............................................................................................................................ 7-92

7.1.7 X2 Resource Status Reporting ........................................................................................................... 7-94

7.1.8 X2 Setup ............................................................................................................................................ 7-95

7.1.9 X2 eNB Configuration ....................................................................................................................... 7-96

7.2 S1AP Functions and Procedures ................................................................................................................. 7-97

7.2.1 S1AP Functions .................................................................................................................................. 7-98

7.2.2 S1AP Elementary Procedures ............................................................................................................ 7-99

7.2.3 S1 Setup ........................................................................................................................................... 7-101

7.2.4 eNB and MME Configuration Update ............................................................................................. 7-103

7.2.5 NAS Transport ................................................................................................................................. 7-103

7.2.6 Initial Context Setup ........................................................................................................................ 7-105

Contents LTE Protocols and Procedures

iv Huawei Proprietary and Confidential


Issue 06 (2006-03-01)

7.2.7 E-RAB Establishment ...................................................................................................................... 7-107

7.2.8 S1 Handover..................................................................................................................................... 7-109

7.2.9 Path Switch ...................................................................................................................................... 7-114

7.2.10 Handover Cancel ............................................................................................................................ 7-116

7.2.11 Status Transfer ................................................................................................................................ 7-117

7.2.12 UE Context Release ....................................................................................................................... 7-117

7.2.13 Reset ............................................................................................................................................... 7-118

7.2.14 Location Reporting Control ........................................................................................................... 7-118

7.2.15 Overload ......................................................................................................................................... 7-119

7.2.16 Direct Information Transfer ........................................................................................................... 7-119

7.2.17 Paging ............................................................................................................................................ 7-120

7.3 User Plane GTP Functions and Procedures ............................................................................................... 7-120

7.3.1 GTP Tunnels .................................................................................................................................... 7-120

7.3.2 GTPv1-U Header ............................................................................................................................. 7-121

7.3.3 Extension Header ............................................................................................................................. 7-122

7.3.4 Handling of Sequence Numbers ....................................................................................................... 7-123

7.3.5 GTPv1-U Procedures ....................................................................................................................... 7-123

7.3.6 Path Management ............................................................................................................................. 7-123

7.3.7 UDP header and Port Numbers ........................................................................................................ 7-126

8 Mobility in LTE ................................................................................................................. 8-127

8.1 X2 Handover ............................................................................................................................................. 8-128

8.1.1 Handover Phases .............................................................................................................................. 8-128

8.1.2 X2 Based Handover with Lossless PDCP ........................................................................................ 8-128

8.1.3 Data Forwarding .............................................................................................................................. 8-132

8.2 S1 Handover .............................................................................................................................................. 8-133

8.2.1 Inter MME and S-GW Handover ..................................................................................................... 8-133

8.2.2 S1 Status Transfer ............................................................................................................................ 8-135

8.3 Inter RAT Handover .................................................................................................................................. 8-136

8.3.1 E-UTRAN to UTRAN Handover..................................................................................................... 8-136

8.3.2 UTRAN to E-UTRAN Handover..................................................................................................... 8-137

9 Glossary .............................................................................................................................. 9-138

LTE Protocols and Procedures Figures



v

Figures

Figure 1-1 LTE Reference Architecture ............................................................................................................. 1-3

Figure 1-2 User Equipment Functional Elements .............................................................................................. 1-4

Figure 1-3 Evolved Node B Functional Elements .............................................................................................. 1-5

Figure 1-4 MME Functional Elements ............................................................................................................... 1-7

Figure 1-5 S-GW Functional Elements .............................................................................................................. 1-8

Figure 1-6 PDN-GW Functional Elements......................................................................................................... 1-8

Figure 1-7 E-UTRAN Interfaces ........................................................................................................................ 1-9

Figure 1-8 EPC Architecture and Interfaces ..................................................................................................... 1-10

Figure 1-9 Additional Network Elements and Interfaces ................................................................................. 1-11

Figure 2-1 NAS and AS Control Plane ............................................................................................................. 2-14

Figure 2-2 NAS and AS User Plane ................................................................................................................. 2-15

Figure 2-3 NAS Protocol stack......................................................................................................................... 2-16

Figure 2-4 NAS Identities ................................................................................................................................ 2-17

Figure 2-5 TA and TA List ................................................................................................................................ 2-18

Figure 2-6 NAS States and State Transtions..................................................................................................... 2-21

Figure 2-7 Network Attach ............................................................................................................................... 2-22

Figure 2-8 Uu Interface Protocols .................................................................................................................... 2-23

Figure 2-9 Main RRC Functions ...................................................................................................................... 2-23

Figure 2-10 PDCP Functions ............................................................................................................................ 2-24

Figure 2-11 RLC Modes and Functions ........................................................................................................... 2-25

Figure 2-12 Medium Access Control Functions ............................................................................................... 2-25

Figure 2-13 Physical Layer Functions .............................................................................................................. 2-26

Figure 2-14 X2 Interface Protocols .................................................................................................................. 2-26

Figure 2-15 S1 Interface Protocols ................................................................................................................... 2-28

Figure 2-16 S11 Interface Protocols ................................................................................................................. 2-29

Figure 2-17 S5/S8 Interface Protocols .............................................................................................................. 2-30

Figures LTE Protocols and Procedures

vi Huawei Proprietary and Confidential


Issue 06 (2006-03-01)

Figure 2-18 S10 Interface Protocols ................................................................................................................. 2-31

Figure 2-19 SGi Interface Protocols ................................................................................................................. 2-31

Figure 3-1 QoS Packet Scheduling ................................................................................................................... 3-33

Figure 3-2 LTE Bearers .................................................................................................................................... 3-34

Figure 3-3 Service Data Flows ......................................................................................................................... 3-34

Figure 3-4 Default and Dedicated EPS Bearers ............................................................................................... 3-35

Figure 3-5 Signaling Radio Bearers ................................................................................................................. 3-37

Figure 3-6 Data Radio Bearers ......................................................................................................................... 3-38

Figure 3-7 E-RAB QoS Parameters to the eNB ............................................................................................... 3-38

Figure 3-8 E-UTRA E-RAB QoS ..................................................................................................................... 3-39

Figure 4-1 RRC Interaction with Lower Layers ............................................................................................... 4-41

Figure 4-2 eNB Structure ................................................................................................................................. 4-42

Figure 4-3 RRC States ...................................................................................................................................... 4-43

Figure 4-4 E-UTRA RRC State Interaction ...................................................................................................... 4-44

Figure 4-5 Mobility Procedures between E-UTRA and CDMA2000 .............................................................. 4-45

Figure 4-6 MIB and SIB1 Parameters .............................................................................................................. 4-45

Figure 4-7 LTE SIBs ........................................................................................................................................ 4-46

Figure 4-8 RRC Paging .................................................................................................................................... 4-47

Figure 4-9 RRC Connection ............................................................................................................................. 4-47

Figure 4-10 RRC Security Mode Command .................................................................................................... 4-48

Figure 4-11 RRC Connection Reconfiguration ................................................................................................ 4-49

Figure 4-12 RRC Connection Reestablishment ................................................................................................ 4-50

Figure 4-13 RRC Connection Release.............................................................................................................. 4-50

Figure 4-14 Information Transfer ..................................................................................................................... 4-51

Figure 4-15 Measurement Configuration ......................................................................................................... 4-52

Figure 4-16 Measurement Object ..................................................................................................................... 4-53

Figure 4-17 Report Configuration .................................................................................................................... 4-53

Figure 4-18 Periodical Reporting ..................................................................................................................... 4-54

Figure 4-19 Event Based Trigger (Event A3) ................................................................................................... 4-54

Figure 4-20 Event A3 Example ........................................................................................................................ 4-56

Figure 5-1 PDCP Functions .............................................................................................................................. 5-59

Figure 5-2 PDCP Data PDU for SRB ............................................................................................................... 5-61

Figure 5-3 User Plane PDCP Data PDU with Long PDCP SN (12 bits) .......................................................... 5-61




vii

Figure 5-4 User Plane PDCP Data PDU with Short PDCP SN (7 bits) ............................................................ 5-62

Figure 5-5 PDCP Control PDU for PDCP Status Report ................................................................................. 5-62

Figure 5-6 PDCP Control PDU for Interspersed ROHC Feedback Packet ...................................................... 5-62

Figure 5-7 ROHC Feedback ............................................................................................................................. 5-63

Figure 5-8 Derivation of MAC-I ...................................................................................................................... 5-64

Figure 5-9 Count Value .................................................................................................................................... 5-64

Figure 5-10 PDCP Ciphering ........................................................................................................................... 5-64

Figure 6-1 RLC Modes ..................................................................................................................................... 6-67

Figure 6-2 Transparent Mode RLC .................................................................................................................. 6-68

Figure 6-3 Unacknowledged Mode RLC ......................................................................................................... 6-68

Figure 6-4 Acknowledged Mode RLC ............................................................................................................. 6-70

Figure 6-5 RLC UMD 5bit SN (No Length Indicators) ................................................................................... 6-71

Figure 6-6 RLC UMD 10bit SN (No Length Indicators) ................................................................................. 6-71

Figure 6-7 RLC UMD with 2 Length Indicators .............................................................................................. 6-72

Figure 6-8 RLC AMD with no Length Indicators ............................................................................................ 6-73

Figure 6-9 RLC AMD with Odd Number of Length Indicators ....................................................................... 6-73

Figure 6-10 RLC AMD PDU Segment............................................................................................................. 6-74

Figure 6-11 AMD Segmentation ...................................................................................................................... 6-74

Figure 6-12 RLC Status PDU ........................................................................................................................... 6-75

Figure 6-13 MAC Structure (UE Side)............................................................................................................. 6-76

Figure 6-14 MAC Header ................................................................................................................................. 6-77

Figure 6-15 MAC Subheaders .......................................................................................................................... 6-78

Figure 6-16 Timing Advance Parameter ........................................................................................................... 6-79

Figure 6-17 Short BSR and Truncated BSR MAC Control Element ................................................................ 6-79

Figure 6-18 Long BSR MAC Control Element ................................................................................................ 6-79

Figure 6-19 Power Control Headroom ............................................................................................................. 6-80

Figure 6-20 Power Headroom Control Element ............................................................................................... 6-80

Figure 6-21 Random Access RRC Signaling Procedure .................................................................................. 6-81

Figure 6-22 Random Access Response ............................................................................................................ 6-82

Figure 6-23 Backoff Indicator .......................................................................................................................... 6-83

Figure 7-1 X2 Control and User Plane ............................................................................................................. 7-85

Figure 7-2 X2 Handover Request ..................................................................................................................... 7-89

Figure 7-3 X2 Handover Preparation Failure ................................................................................................... 7-90

Figures LTE Protocols and Procedures

viii Huawei Proprietary and Confidential


Issue 06 (2006-03-01)

Figure 7-4 X2 SN Status Transfer .................................................................................................................... 7-91

Figure 7-5 X2 UE Context Release .................................................................................................................. 7-92

Figure 7-6 X2 Handover Cancel ....................................................................................................................... 7-92

Figure 7-7 X2 Load Indication ......................................................................................................................... 7-93

Figure 7-8 X2 Uplink Interference ................................................................................................................... 7-93

Figure 7-9 Downlink RNTP ............................................................................................................................. 7-93

Figure 7-10 X2 Resource Status Request ......................................................................................................... 7-94

Figure 7-11 X2 Resource Status Update........................................................................................................... 7-95

Figure 7-12 X2 Setup Request ......................................................................................................................... 7-96

Figure 7-13 eNB Configuration Update ........................................................................................................... 7-97

Figure 7-14 S1 Control and User Plane ............................................................................................................ 7-98

Figure 7-15 S1 Setup Request ........................................................................................................................ 7-102

Figure 7-16 S1 Setup Response ...................................................................................................................... 7-102

Figure 7-17 S1 Initial UE Message ................................................................................................................ 7-104

Figure 7-18 S1 Downlink and Uplink NAS Transport ................................................................................... 7-104

Figure 7-19 S1 Initial Context Setup Request ................................................................................................ 7-106

Figure 7-20 Initial Context Setup Response ................................................................................................... 7-107

Figure 7-21 S1 E-RAB Setup Request ........................................................................................................... 7-108

Figure 7-22 S1 E-RAB Setup Response ......................................................................................................... 7-108

Figure 7-23 E-RAB Release Indication .......................................................................................................... 7-109

Figure 7-24 Requirement for S1 Handover Procedures.................................................................................. 7-110

Figure 7-25 S1 Handover Required ................................................................................................................ 7-111

Figure 7-26 S1 Handover Command .............................................................................................................. 7-112

Figure 7-27 S1 Handover Request ................................................................................................................. 7-113

Figure 7-28 Handover Request Acknowledge ................................................................................................ 7-114

Figure 7-29 Handover Notify ......................................................................................................................... 7-114

Figure 7-30 S1 Path Switch Request .............................................................................................................. 7-115

Figure 7-31 Path Switch Request Acknowledge ............................................................................................ 7-116

Figure 7-32 Handover Cancel ........................................................................................................................ 7-116

Figure 7-33 UE Context Release .................................................................................................................... 7-117

Figure 7-34 UE Context Release Request ...................................................................................................... 7-118

Figure 7-35 S1 Reset ...................................................................................................................................... 7-118

Figure 7-36 S1 Trace Start .................................................................................... Error! Bookmark not defined.




ix

Figure 7-37 Location Report Control ............................................................................................................. 7-119

Figure 7-38 Overload Start ............................................................................................................................. 7-119

Figure 7-39 Paging ......................................................................................................................................... 7-120

Figure 7-40 GTP Tunnel ................................................................................................................................. 7-121

Figure 7-41 GTPv1-U Header ........................................................................................................................ 7-121

Figure 7-42 GTP Extension Header ............................................................................................................... 7-122

Figure 7-43 GTP Echo Procedure................................................................................................................... 7-124

Figure 7-44 Supported Extension Headers Notification ................................................................................. 7-125

Figure 7-45 End Marker Procedure ................................................................................................................ 7-125

Figure 8-1 Handover Phases ........................................................................................................................... 8-128

Figure 8-2 X2 Based Handover with Lossless PDCP..................................................................................... 8-129

Figure 8-3 Mobility Control Information ....................................................................................................... 8-130

Figure 8-4 X2AP SN Status Transfer ............................................................................................................. 8-131

Figure 8-5 S1 Based Inter MME/S-GW Handover ........................................................................................ 8-133

Figure 8-6 S1 Based Inter MME/S-GW Handover Continued ....................................................................... 8-134

Figure 8-7 S1 Based Inter MME/S-GW Handover Continued ....................................................................... 8-135

Figure 8-8 E-UTRAN to UTRAN Handover ................................................................................................. 8-136

Figure 8-9 E-UTRAN to UTRAN Handover Continued ................................................................................ 8-137

LTE Protocols and Procedures 1 EPS Architecture



1-1

Tables

Table 1-1 UE Categories ..................................................................................................................................... 1-4

Table 2-1 NAS EMM and ESM Procedures ..................................................................................................... 2-19

Table 3-1 QCI Attributes .................................................................................................................................. 3-36

Table 5-1 Supported Header Compression Protocols and Profiles ................................................................... 5-60

Table 6-1 RLC PDU Formats ........................................................................................................................... 6-70

Table 6-2 FI Field Interpretation ....................................................................................................................... 6-72

Table 6-3 LCID Coding for DL-SCH ............................................................................................................... 6-77

Table 6-4 LCID Coding for UL-SCH ............................................................................................................... 6-78

Table 6-5 Power Headroom Report Mapping ................................................................................................... 6-80

Table 6-6 Uplink Grant ..................................................................................................................................... 6-82

Table 7-1 Mapping between X2AP Functions and X2AP EPs ......................................................................... 7-86

Table 7-2 Class 1 Elementary Procedures ........................................................................................................ 7-86

Table 7-3 S1AP Class 1 Elementary Procedures .............................................................................................. 7-99

Table 7-4 S1AP Class 2 Elementary Procedures ............................................................................................ 7-100

Table 7-5 Messages in GTP-U ........................................................................................................................ 7-123

1 EPS Architecture LTE Protocols and Procedures

1-2 Huawei Proprietary and Confidential


Issue 06 (2006-03-01)

1 EPS Architecture About This Chapter

The following table lists the contents of this chapter.

Section

1.1 EPS Network Elements

1.2 EPS Interfaces




1-3

1.1 EPS Network Elements

The term EPS (Evolved Packet System) relates to the Evolved 3GPP Packet Switched

Domain. In contrast to the 2G and 3G networks defined by the 3GPP, LTE can be simply

divided into a flat IP based bearer network and a service enabling network. The former can be

further subdivided into the E-UTRAN (Evolved - Universal Terrestrial Radio Access

Network) and the EPC (Evolved Packet Core) where as support for service delivery lies in the

IMS (IP Multimedia Subsystem). This reference architecture can be seen in Figure 1-1

Figure 1-1 LTE Reference Architecture

Whilst UMTS is based upon WCDMA technology, the 3GPP developed new specifications

for the LTE air interface based upon OFDMA (Orthogonal Frequency Division Multiple

Access) in the downlink and SC-FDMA (Single Carrier - Frequency Division Multiple

Access) in the uplink. This new air interface is termed the E-UTRA (Evolved - Universal

Terrestrial Radio Access).

1.1.1 User Equipment

Like that of UMTS, the mobile device in LTE is termed the UE (User Equipment) and is

comprised of two distinct elements; the USIM (Universal Subscriber Identity Module) and the

ME (Mobile Equipment).

The ME supports a number of functional entities including:

� RR (Radio Resource) - this supports both the Control Plane and User Plane and in so

doing, is responsible for all low level protocols including RRC (Radio Resource

Control), PDCP (Packet Data Convergence Protocol), RLC (Radio Link Control), MAC

(Medium Access Control) and the PHY (Physical) Layer.

� EMM (EPS Mobility Management) - is a Control Plane entity which manages the

mobility management states the UE can exist in; LTE Idle, LTE Active and LTE

Detached. Transactions within these states include procedures such as TAU (Tracking

Area Update) and handovers.




Issue 06 (2006-03-01)

� ESM (EPS Session Management) - is a Control Plane activity which manages the

activation, modification and deactivation of EPS bearer contexts. These can either be

default EPS bearer contexts or dedicated EPS bearer contexts.

Figure 1-2 User Equipment Functional Elements

In terms of the Physical Layer, the capabilities of the UE may be defined in terms of the

frequencies and data rates supported. Devices may also be capable of supporting adaptive

modulation including QPSK (Quadrature Phase Shift Keying), 16QAM (16 Quadrature

Amplitude Modulation) and 64QAM (Quadrature Amplitude Modulation).

In terms of the radio spectrum, the UE is able to support several scalable channels including;

1.4MHz, 3MHz, 5MHz, 10MHz, 15MHz and 20MHz whilst operating in FDD (Frequency

Division Duplex) and/or TDD (Time Division Duplex). Furthermore, the UE may also

support advanced antenna features such as MIMO (Multiple Input Multiple Output).

Table 1-1 UE Categories

UE Category Maximum Downlink Data Rate

Number of Downlink Data Streams

Maximum Uplink Data Rate

Support for Uplink 64QAM

1 10.3Mbit/s 1 5.2Mbit/s No




5 302.8Mbit/s 4 75.4Mbit/s Yes




1-5

1.1.2 Evolved Node B

In addition to the new air interface, a new base station has also been specified by the 3GPP

and is referred to as an eNB (Evolved Node B). These, along with their associated interfaces

form the E-UTRAN and in so doing, are responsible for:

� RRM (Radio Resource Management) - this involves the allocation to the UE of the

physical resources on the uplink and downlink, access control and mobility control.

� Date Compression - is performed in both the eNB and the UE in order to maximize the

amount of user data that can be transferred on the allocated resource. This process is

undertaken by PDCP.

� Data Protection - is performed at the eNB and the UE in order to encrypt and integrity

protect RRC signaling and encrypt user data on the air interface.

� Routing - this involves the forwarding of Control Plane signaling to the MME and User

Plane traffic to the S-GW (Serving - Gateway).

� Packet Classification and QoS Policy Enforcement - this involves the “marking” of

uplink packets based upon subscription information or local service provider policy. QoS

(Quality of Service) policy enforcement is then responsible for ensuring such policy is

enforced at the network edge.

Figure 1-3 Evolved Node B Functional Elements

Security in LTE is not solely limited to encryption and integrity protection of information passing across

the air interface but instead, NAS encryption and integrity protection between the UE and MME also

takes place. In addition, IPSec may also be used to protect user data within both the E-UTRAN and

EPC.

eNB Identities

In addition to the UE identities already discussed, there are a number of specific identities

associated with the eNB. These include:

� TAI (Tracking Area Identity) - is a logical group of neighboring cells defined by the

service provider in which UEs in LTE Idle mode are able to move within without

needing to update the network. As such, it is similar to a RAI (Routing Area Identity)

used in 2G and 3G packet switched networks.

� ECGI (E-UTRAN Cell Global Identifier) - is comprised of the MCC, MNC and ECI

(Evolved Cell Identity), the later being coded by each service provider.




Issue 06 (2006-03-01)

Femto Cells

In order to improve both network coverage and capacity, the 3GPP have developed a new type

of base station to operate within the home or small business environment. Termed the HeNB

(Home Evolved Node B), this network element forms part of the E-UTRAN and in so doing

supports the standard E-UTRAN interfaces. However, it must be stated that HeNBs do not

support the X2 interface.

The architecture may include an HeNB-GW (Home Evolved Node B - Gateway) which

resides between the HeNB in the E-UTRAN and the MME / S-GW in the EPC in order to

scale and support large numbers of base station deployments.

1.1.3 Mobility Management Entity

The MME is the Control Plane entity within the EPC and as such is responsible for the

following functions:

� NAS Signaling and Security - this incorporates both EMM (EPS Mobility Management)

and ESM (EPS Session Management) and thus includes procedures such as Tracking

Area Updates and EPS Bearer Management. The MME is also responsible for NAS

security.

� S-GW and PDN-GW Selection - upon receipt of a request from the UE to allocate a

bearer resource, the MME will select the most appropriate S-GW and PDN-GW. This

selection criterion is based on the location of the UE in addition to current load

conditions within the network.

� Tracking Area List Management and Paging - whilst in the LTE Idle state, the UE is

tracked by the MME to the granularity of a Tracking Area. Whilst UEs remain within the

Tracking Areas provided to them in the form of a Tracking Area List, there is no

requirement for them to notify the MME. The MME is also responsible for initiating the

paging procedure.

� Inter MME Mobility - if a handover involves changing the point of attachment within the

EPC, it may be necessary to involve an inter MME handover. In this situation, the

serving MME will select a target MME with which to conduct this process.

� Authentication - this involves interworking with the subscriber’s HSS (Home Subscriber

Server) in order to obtain AAA (Access Authorization and Accounting) information with

which to authenticate the subscriber. Like that of other 3GPP system, authentication is

based on AKA (Authentication and Key Agreement).




1-7

Figure 1-4 MME Functional Elements

1.1.4 Serving Gateway

The S-GW terminates the S1-U Interface from the E-UTRAN and in so doing, provides the

following functions:

� Mobility Anchor - for inter eNB handovers, the S-GW acts as an anchor point for the

User Plane. Furthermore, it also acts as an anchor for inter 3GPP handovers to legacy

networks - GPRS and UMTS.

� Downlink Packet Buffering - when traffic arrives for a UE at the S-GW, it may need to

be buffered in order to allow time for the MME to page the UE and for it to enter the

LTE Active state.

� Packet Routing and Forwarding - traffic must be routed to the correct eNB on the

downlink and the specified PDN-GW on the uplink.

� GTP/PMIP Support - if PMIP (Proxy Mobile IP) is used on the S5/S8 Interfaces, the

S-GW must support MAG (Mobile Access Gateway) functionality. Furthermore, support

for GTP/PMIP chaining may also be required.




Issue 06 (2006-03-01)

Figure 1-5 S-GW Functional Elements

1.1.5 Packet Data Network - Gateway

The PDN-GW is the network element which terminates the SGi Interface towards the PDN

(Packet Data Network). If a UE is accessing multiple PDNs, there may be a requirement for

multiple PDN-GWs to be involved. Functions associated with the PDN-GW include:

� Packet Filtering - this incorporates the deep packet inspection of IP datagrams arriving

from the PDN in order to determine which TFT (Traffic Flow Template) they are to be

associated with.

� IP Address Allocation - IP addresses may be allocated to the UE by the PDN-GW. This is

included as part of the initial bearer establishment phase or when UEs roam between

different access technologies.

� Transport Level Packet Marking - this involves the marking of uplink and downlink

packets with the appropriate tag e.g. DSCP (Differentiated Services Code Point) based

on the QCI (QoS Class Identifier) of the associated EPS bearer.

� Accounting - through interaction with a PCRF (Policy Rules and Charging Function), the

PDN-GW will monitor traffic volumes and types.

Figure 1-6 PDN-GW Functional Elements




1-9

1.2 EPS Interfaces

1.2.1 E-UTRAN Interfaces

As with all 3GPP technologies, it is the actual interfaces which are defined in terms of the

protocols they support and the associated signaling messages and user traffic that traverse

them. Figure 1-7 illustrates the main interfaces in the E-UTRAN.

Figure 1-7 E-UTRAN Interfaces

Uu Interface

The Uu Interface supports both a Control Plane and a User plane and spans the link between

the UE and the eNB / HeNB. The principle Control Plane protocol is RRC (Radio Resource

Control) while the User Plane is designed to carry IP datagrams.

X2 Interface

The X2 interface interconnects two eNBs and in so doing supports both a Control Plane and

User Plane. The principle Control Plane protocol is X2AP (X2 Application Protocol).

S1 Interface

The S1 interface can be subdivided into the S1-MME interface supporting Control Plane

signaling between the eNB and the MME and the S1-U Interface supporting User Plane traffic

between the eNB and the S-GW. The principle Control Plane protocol is S1AP (S1

Application Protocol).

1.2.2 EPC Interfaces

Figure 1-8 illustrates the fundamental architecture of the EPC and in so doing identifies the

key interfaces which exist between the network elements. It should be stated however that

there exists additional interfaces which link the EPC with the IMS and legacy 3GPP / Non

3GPP architectures.




Issue 06 (2006-03-01)

Figure 1-8 EPC Architecture and Interfaces

1.2.3 Additional Network Elements and Interfaces

In addition to the network elements, interfaces and associated protocols discussed so far, the

EPC connects with numerous other nodes and networks. These are illustrated in Figure 1-9.




1-11

Figure 1-9 Additional Network Elements and Interfaces

These include, but are not limited to the:

� HSS (Home Subscriber Server) - this can be considered a “master” database within the

PLMN. Although logically it is considered as one entity, the HSS in practice is made up

of several physical databases depending upon subscriber numbers and redundancy

requirements. The HSS holds variables and identities for the support, establishment and

maintenance of calls and sessions made by subscribers. It is connected to the MME via

the S6a Interface which uses the protocol Diameter.

� PCRF (Policy and Charging Rules Function) - this supports functionality for policy

control through the PDF (Policy Decision Function) and charging control through the

CRF (Charging Rules Function). As such, it provides bearer network control in terms of

QoS and the allocation of the associated charging vectors. The PCRF downloads this

information over the Gx Interface using the Diameter protocol.

� ePDG (evolved Packet Data Gateway) - which is used when connecting to Untrusted

Non 3GPP IP Access networks. It provides functionality to allocate IP addresses in

addition to encapsulating / de-encapsulating IPSec (IP Security) and PMIP tunnels. It

connects to the PDN-GW via the S2b Interface.

� RNC (Radio Network Controller) - which forms part of the 3GPPs UTRAN (Universal

Terrestrial Radio Access Network), the RNC connects to the S-GW to support the

tunneling of User Plane traffic using GTP-U. The interface linking these network

elements is the S12 Interface.

� SGSN (Serving GPRS Support Node) - this forms part of the 3GPPs 2G and 3G packet

switched core domain. It connects to both the MME and S-GW in order to support




Issue 06 (2006-03-01)

packet switched mobility and uses the GTPv2-C and GTP-U protocols respectively. The

SGSN connects to the MME via the S3 Interface and the S-GW via the S4 Interface.

� EIR (Equipment Identity Register) - this database enables service providers to validate a

particular IMEI (International Mobile Equipment Identity) against stored lists. It

connects to the MME via the S13 Interface and uses the Diameter protocol for message

transfer.

LTE Protocols and Procedures 2 EPS Protocols



2-13

2 EPS Protocols About This Chapter


Section

2.1 EPS Signaling

2.2 EPS Protocols

2 EPS Protocols LTE Protocols and Procedures



Issue 06 (2006-03-01)

2.1 EPS Signaling

The connectivity between the UE and the EPS can be split into a Control Plane and a User

Plane. Both of these can further split into the NAS (Non Access Stratum) and AS (Access

Stratum). The Access Stratum consist of the protocols and signaling involved with the

E-UTRAN, i.e. maintain both the air interface and S1 interfaces. In contrast, the Non Access

Stratum, as its name suggests, is not part of the Access Stratum and is defined as higher layer

signaling and traffic (IP datagrams).

Control Plane

Figure 2-1 illustrates the concept of NAS and AS signaling, i.e. the Control Plane. It is worth

noting that the NAS signaling is effectively transparent to the E-UTRAN. Access Stratum

signaling provides a mechanism to deliver NAS signaling, as well as the lower layer signaling

required to setup, maintain and manage the connections. The X2 interfaces are also part of

this methodology and as such it also is part of Access Stratum signaling.

Figure 2-1 NAS and AS Control Plane

User Plane

The User Plane focuses on the delivery of IP datagrams to and from the EPC, namely the

S-GW and PDN-GW. Figure 2-2 illustrates this concept.




2-15

Figure 2-2 NAS and AS User Plane

In the case of the User Plane the higher layer NAS is an IP datagram. This effectively is

delivered between the UE and the PDN-GW, with the eNB and S-GW acting as lower layer

relaying devices.

2.2 EPS Protocols

2.2.1 NAS Functionality

The Non Access Stratum (NAS) protocols are used for signaling exchange between the UE

and the Mobility Management Entity (MME).

NAS sits on top of RRC layer in the UE and S1AP of the MME. All NAS messages are

carried by RRC and SIAP messages in radio interface and S1-MME interface respectively.

The NAS signaling is identified as EPS Mobility Management (EMM) and EPS Session

Management (ESM).

The EMM Protocol signaling is related to UE mobility and security procedures. The ESM

protocol handles signaling related to the default and dedicated user plane bearers.




Issue 06 (2006-03-01)

Figure 2-3 NAS Protocol stack

2.2.2 NAS Concepts and Identities

Tracking Area

The NAS layer makes use of Tracking Area (TA) for mobility management. The Tracking

Area is the same concept as GSM/UMTS concept of Routing Area, it is an operator defined

group of cells. The MME is aware of the location of an attached UE at the TA or TA list level

through the TA Update procedure. The TA is typically the area within which the UE is paged

for incoming calls.

Tracking Area Identity (TAI) is a cell configuration.

TAI = MCC + MNC + TAC, where

� TAI : Tracking area identity

� MCC : Mobile Country Code

� MNC : Mobile Network Code

� TAC : Tracking Area Code

As an operator option, there may also be MME Pool (MME Group) 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 in parallel. MME pool

Areas are a collection of complete Tracking Areas. MME Pool Areas may overlap each other,

as seen in Figure 2-4




2-17

Figure 2-4 NAS Identities

MME1

TA3

TA4

TA1

TA2

TA5

TA6

TA7

MME2

MME1

MME1

MME2

MME Group A

MME Group B

MME Group C

PLMN

GUTI

S-TMSI

UE Context




Issue 06 (2006-03-01)

GUTI

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 PTIMSI

(PS domain) numbers. There is a difference however: the GUTI explicitly links with the

MME pool Area concept.

� GUTI = MCC + MNC + MMEGI + MMEC + M-TMSI, where

� MMEGI: MME Group Identifier (16 bit)

� MMEC: MME Code (8 bit)

� M-TIMSI : M- Temporary Mobile Subscriber Identity（32 bit）

The GUTI is allocated when the UE performs initial registration (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 with

an MME Group. The S-TMIS ,rather than the complete GUTI, is used within most NAS

messages.

Tracking Area List

In order to avoid frequent TA updating, the MME may order the UE to keep multiple TAs

which is called TA List of a UE.

UE only updates the TA information to MME when it moves to a TA not in its TA list.

Figure 2-5 TA and TA List

2.2.3 EMM and ESM

The NAS signaling between the UE and the EPC is identified as EMM or ESM. Table 2-1

illustrates the main EMM and ESM signaling procedures.




2-19

Table 2-1 NAS EMM and ESM Procedures

EMM Procedures ESM Procedures

Attach Default EPS Bearer Context Activation

Detach Dedicated EPS Bearer Context Activation

Tracking Area Update EPS Bearer Context Modification

Service Request EPS Bearer Context Deactivation

Extended Service Request UE Requested PDN Connectivity

GUTI Reallocation UE Requested PDN Disconnect

Authentication UE Requested Bearer Resource Allocation

Identification UE Requested Bearer Resource Modification

Security Mode Control ESM Information Request

EMM Status ESM Status

EMM Information

NAS Transport

Paging

EMM Procedures

The key EMM procedures include:

� Attach - this is used by the UE to attach to an EPC (Evolved Packet Core) for packet

services in the EPS (Evolved Packet System). Note that it can be also used to attach to

non-EPS services.

� Detach - this is used by the UE to detach from EPS services. In addition, it can also be

used for other procedures such as disconnecting from non-EPS services.

� Tracking Area Updating - this procedure is always initiated by the UE and is used for the

various purposes. The most common include normal and periodic tracking area updating.

� Service Request - this is used by the UE to get connected and establish the radio and S1

bearers when uplink user data or signaling is to be sent.

� Extended Service Request - this is used by the UE to initiate a Circuit Switched fallback

call or respond to a mobile terminated Circuit Switched fallback request from the

network.

� GUTI Reallocation - this is used to allocate a GUTI (Globally Unique Temporary

Identifier) and optionally to provide a new TAI (Tracking Area Identity) list to a

particular UE.

� Authentication - this is used for AKA (Authentication and Key Agreement) between the

user and the network.

� Identification - this is used by the network to request a particular UE to provide specific

identification parameters, e.g. the IMSI (International Mobile Subscriber Identity) or the

IMEI (International Mobile Equipment Identity).




Issue 06 (2006-03-01)

� Security Mode Control - this is used to take an EPS security context into use, and

initialize and start NAS signaling security between the UE and the MME with the

corresponding NAS keys and security algorithms.

� EMM Status - this is sent by the UE or by the network at any time to report certain error

conditions.

� EMM Information - this allows the network to provide information to the UE.

� Transport of NAS messages - this is to carry SMS (Short Message Service) messages in

an encapsulated form between the MME and the UE.

� Paging - this is used by the network to request the establishment of a NAS signaling

connection to the UE. Is also includes the Circuit Switched Service Notification

ESM Procedures

The key ESM procedures include:

� Default EPS Bearer Context Activation - this is used to establish a default EPS bearer

context between the UE and the EPC.

� Dedicated EPS Bearer Context Activation - this is to establish an EPS bearer context

with specific QoS (Quality of Service) and TFT (Traffic Flow Template) between the UE

and the EPC. The dedicated EPS bearer context activation procedure is initiated by the

network, but may be requested by the UE by means of the UE requested bearer resource

allocation procedure.

� EPS Bearer Context Modification - this is used to modify an EPS bearer context with a

specific QoS and TFT.

� EPS Bearer Context Deactivation - this is used to deactivate an EPS bearer context or

disconnect from a PDN by deactivating all EPS bearer contexts to the PDN.

� UE Requested PDN Connectivity - this is used by the UE to request the setup of a

default EPS bearer to a PDN.

� UE Requested PDN Disconnect - this is used by the UE to request disconnection from

one PDN. The UE can initiate this procedure to disconnect from any PDN as long as it is

connected to at least one other PDN.

� UE Requested Bearer Resource Allocation - this is used by the UE to request an

allocation of bearer resources for a traffic flow aggregate.

� UE Requested Bearer Resource Modification - this is used by the UE to request a

modification or release of bearer resources for a traffic flow aggregate or modification of

a traffic flow aggregate by replacing a packet filter.

� ESM Information Request - this is used by the network to retrieve ESM information, i.e.

protocol configuration options, APN (Access Point Name), or both from the UE during

the attach procedure.

� ESM Status - this is used to report at any time certain error conditions detected upon

receipt of ESM protocol data.

2.2.4 NAS States and State Transitions

There are separate protocol state machines for the EMM protocol and ESM protocol.

EMM protocol state machine relates to whether the UE is properly registered in the network

or not and whether there exists an active NAS Signaling Connection between the UE and

MME or not. The ESM protocol state machine deals exclusively with the existence or not of

EPS bearers.




2-21

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 Signaling Connection

established (ECM Connected) or not (ECM Idle).

The NAS signaling Connection is required for any exchange of NAS message with the

exception of the very messages that triggers the establishment of the NAS Signaling

Connection itself (e.g. Attach Request or Paging).

Figure 2-6 NAS States and State Transitions

ESM ACTIVE

PDN Contents:

IP Adress， APN, QoS ParamtersS5 IP address & TEID

S11 IP address & TEID(S1-U IP address & TEID)

Data Transfer Possible when ECM

connected

One Default BearerZero, one or more Dedicated Bearer

EMM REGISTERED

MME context:IMSI, GUTI, TalistIP address, Security association

ECM IDLENo NAS Signaling Connection

Tracking Area Updates

ECM CONNECTEDNAS Signaling Connection

Data transfer possible

NAS Connection

Release

NAS Connection

Establishment

ESM INACTIVENo PDN context

EMM DEREGISTEREDNo MME context

EPS Bearer

Establishment

Last EPS Bearer

ReleasedAttach Detach

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

signaling 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 Signaling connection present during the ESM

signaling phase when a bearer is being established, i.e. the UE is then ECM connected.

However, there is no requirement to keep the NAS Signaling Connection active for the

lifetime of the 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

the end.




Issue 06 (2006-03-01)

The NAS states (MME related states) are aligned with the RRC states (eNodeB related states).

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

Figure 2-7 Network Attach

2.2.5 Uu Interface

The Uu Interface supports both a Control Plane and a User plane and spans the link between

the UE and the eNB / HeNB. The principle Control Plane protocol is RRC in the Access

Stratum and EMM (EPS Mobility Management)/ ESM (EPS Session Management) in the

Non Access Stratum. In contrast, the User Plane is designed to carry IP datagrams. However,

both Control and User Planes utilize the services of the lower layers, namely PDCP (Packet

Data Convergence Protocol), RLC (Radio Link Control) and MAC (Medium Access Control),

as well as the PHY (Physical Layer).




2-23

Figure 2-8 Uu Interface Protocols

2.2.6 Uu Interface - RRC

The main air interface control protocol is RRC (Radio Resource Control). For RRC messages

to be transferred between the UE and the eNB it uses the services of PDCP, RLC, MAC and

PHY. Figure 2-9 identifies the main RRC functions. In summary, RRC handles all the

signaling between the UE and the E-UTRAN, with signaling between the UE and Core

Network, i.e. NAS (Non Access Stratum) signaling, being carried by dedicated RRC

messages. When carrying NAS signaling, RRC does not alter the information but instead,

provides the delivery mechanism.

Figure 2-9 Main RRC Functions

2.2.7 Uu Interface - PDCP

LTE implements PDCP in both the User Plane and Control Plane. This is unlike UMTS,

where PDCP was only found in the User Plane. The main reason for the difference is that

PDCP in LTE takes on the role of security, i.e. encryption and integrity. In addition, Figure

2-10 illustrates some of the other functions performed by PDCP.




Issue 06 (2006-03-01)

Figure 2-10 PDCP Functions

In the Control Plane, PDCP facilitates encryption and integrity checking of signaling

messages, i.e. RRC and NAS. The User Plane is slightly different since only encryption is

performed. In addition, the User Plane IP datagrams can also be subjected to IP header

compression techniques in order to improve the system’s performance and efficiency. Finally,

PDCP also facilitates sequencing and duplication detection.

2.2.8 Uu Interface - RLC

The RLC (Radio Link Control) protocol exists in the UE and the eNB. As its name suggests it

provides “radio link” control, if required. In essence, RLC supports three delivery services to

the higher layers:

� TM (Transparent Mode) - this is utilized for some of the air interface channels, e.g.

broadcast and paging. It provides a connectionless service for signaling.

� UM (Unacknowledged Mode) - this is like Transparent Mode, in that it is a

connectionless service; however it has the additional features of sequencing,

segmentation and concatenation.

� AM (Acknowledged Mode) - this offers an ARQ (Automatic Repeat Request) service.

As such, retransmissions can be used.

These modes, as well as the other RLC features are illustrated in Figure 2-11. In addition to

ARQ, RLC offers segmentation, re-assembly and concatenation of information.




2-25

Figure 2-11 RLC Modes and Functions

2.2.9 Uu Interface - MAC

MAC (Medium Access Control) provides the interface between the E-UTRA protocols and

the E-UTRA Physical Layer. In doing this it provides the following services:

� Mapping - MAC maps the information received on the LTE Logical Channels into the

LTE transport channels.

� Multiplexing - the information provided to MAC will come from a RB (Radio Bearer) or

multiple Radio Bearers. The MAC layer is able to multiplex different bearers into the

same TB (Transport Block), thus increasing efficiency.

� HARQ (Hybrid Automatic Repeat Request) - MAC utilizes HARQ to provide error

correction services across the air. HARQ is a feature which requires the MAC and

Physical Layers to work closely together.

� Radio Resource Allocation - QoS (Quality of Service) based scheduling of traffic and

signaling to users is provided by MAC.

In order to support these features the MAC and Physical Layers need to pass various

indications on the radio link quality, as well as the feedback from HARQ operation.

Figure 2-12 Medium Access Control Functions

2.2.10 Uu Interface - Physical

The PHY (Physical Layer) in LTE provides a new and flexible channel. It does however

utilize features and mechanisms defined in earlier systems, i.e. UMTS. Figure 2-13 illustrates

the main functions provided by the Physical Layer.




Issue 06 (2006-03-01)

Figure 2-13 Physical Layer Functions

2.2.11 X2 Interface

As previously mentioned, the X2 interface interconnects two eNBs and in so doing supports

both a Control Plane and User Plane. The principle Control Plane protocol is X2AP (X2

Application Protocol). This resides on SCTP (Stream Control Transmission Protocol) where

as the User Plane IP is transferred using the services of GTP-U (GPRS Tunneling Protocol -

User) and UDP (User Datagram Protocol).

Figure 2-14 illustrates the X2 User Plane and Control Plane protocols.

Figure 2-14 X2 Interface Protocols

2.2.12 X2 Interface - X2 Application Protocol

The X2AP is responsible for the following functions:

� Mobility Management - this enables the serving eNB to move the responsibility of a

specified UE to a target eNB. This includes Forwarding the User Plane, Status Transfer

and UE Context Release functions.




2-27

� Load Management - this function enables eNBs to communicate with each other in order

to report resource status, overload indications and current traffic loading.

� Error Reporting - this allows for the reporting of general error situations for which

specific error reporting mechanism have not been defined.

� Setting / Resetting X2 - this provides a means by which the X2 interface can be setup /

reset by exchanging the necessary information between the eNBs.

� Configuration Update - this allows the updating of application level data which is needed

for two eNBs to interoperate over the X2 interface.

2.2.13 X2 Interface - Stream Control Transmission Protocol

Defined by the IETF (Internet Engineering Task Force) rather than the 3GPP, SCTP was

developed to overcome the shortfalls in TCP (Transmission Control Protocol) and UDP when

transferring signaling information over an IP bearer. Functions provided by SCTP include:

� Reliable Delivery of Higher Layer Payloads.

� Sequential Delivery of Higher Layer Payloads.

� Improved resilience through Multihoming.

� Flow Control.

� Improved Security.

SCTP is also found on the S1-MME Interface which links the eNB to the MME.

2.2.14 X2 Interface - GPRS Tunneling Protocol - User

GTP-U tunnels are used to carry encapsulated PDU (Protocol Data Unit) and signaling

messages between endpoints or in the case of the X2 interface. Numerous GTP-U tunnels may

exist in order to differentiate between EPS bearer contexts and these are identified through a

TEID (Tunnel Endpoint Identifier).

GTP-U is also found on the S1-U Interface which links the eNB to the S-GW and may also be used on

the S5 Interface linking the S-GW to the PDN-GW.

2.2.15 S1 Interface

The S1 interface can be subdivided into the S1-MME interface supporting Control Plane

signaling between the eNB and the MME and the S1-U Interface supporting User Plane traffic

between the eNB and the S-GW.




Issue 06 (2006-03-01)

Figure 2-15 S1 Interface Protocols

2.2.16 S1 Interface - S1 Application Protocol

The S1AP spans the S1-MME Interface and in so doing, supports the following functions:

� E-RAB (E-UTRAN - Radio Access Bearer) Management - this incorporates the setting

up, modifying and releasing of the E-RABs by the MME.

� Initial Context Transfer - this is used to establish an S1UE context in the eNB, setup the

default IP connectivity and transfer NAS related signaling.

� UE Capability Information Indication - this is used to inform the MME of the UE

Capability Information.

� Mobility - this incorporates mobility features to support a change in eNB or change in

RAT.

� Paging.

� S1 Interface Management - this incorporates a number of sub functions dealing with

resets, load balancing and system setup etc.

� NAS Signaling Transport - this is used for the transport of NAS related signaling over

the S1-MME Interface.

� UE Context Modification and Release - this allows for the modification and release of

the established UE Context in the eNB and MME respectively.

� Location Reporting - this enables the MME to be made aware of the UEs current

location within the network.

2.2.17 S1 Interface - SCTP and GTP-U

The S1-MME and S1-U lower layer protocols are similar to the X2 interface. As such, they

also utilize the services of SCTP (discussed in Section 2.2.13 ) and GTP-U (discussed in

Section 2.2.14 ).




2-29

2.2.18 S11 Interface

The S11 Interface links the MME with the S-GW in order to support Control Plane signaling.

In so doing, it utilizes GTPv2-C (GPRS Tunneling Protocol version 2 - Control) which, like

all other interfaces which use variants of GTP, uses the services of UDP and IP.


GTPv2-C is also found on the S5/S8 Interface between the S-GW and PDN-GW and the S10 Interface

between MMEs. Furthermore, it can also be found on the S3 and S4 interfaces when interconnecting

with an SGSN (Serving GPRS Support Node).

2.2.19 GPRS Tunneling Protocol version 2 - Control

GTPv2-C supports the transfer of signaling messages between the MME and the S-GW and as

such is responsible for the exchange of the following message types:

� Path Management - this incorporates Echo Request and Echo Response messages to

ensure ongoing connectivity across the link.

� Tunnel Management - these messages are used to activate, modify and delete the EPS

bearers and sessions spanning the network.

� Mobility Management - these messages ensure mobility is supported through a

combination of relocation and notification procedures.

� CS (Circuit Switched) Fallback - this incorporates suspend and resume procedures

during fallback to circuit switched operation.

� Non 3GPP Access - these messages support the establishment of tunnels to forward

packet data between the 3GPP and Non 3GPP networks.

2.2.20 S5/S8 Interface

The S5/S8 Interface links the S-GW with the PDN-GW and supports both a Control Plane and

User Plane. The term S5 is used when these elements reside within the same PLMN (Public

Land Mobile Network) and S8 when the interface spans a HPLMN (Home Public Land

Mobile Network) / VPLMN (Visited Public Land Mobile Network).

The GTPv2-C protocol operates on the Control Plane for both of these interfaces whereas

GTP-U or PMIP is used on the User Plane.




Issue 06 (2006-03-01)

2.2.21 Proxy Mobile IP

Defined by the IETF, PMIP supports mobility when a UE moves from one S-GW to another

during a handover procedure. Data is tunneled between the PDN-GW, which supports HA

(Home Agent) functionality and the S-GW, which acts as the FA (Foreign Agent).

It is anticipated that PMIP will be used by 3GPP2 based networks migrating to LTE as they

already utilize PMIP within their 3G architectures. 3GPP based networks however are

expected to use GTP-U instead.

Figure 2-17 S5/S8 Interface Protocols

2.2.22 S10 Interface

The S10 Interface links two MMEs in order to pass Control Plane signaling. In so doing, it

uses the services of GTPv2-C.




2-31


2.2.23 SGi Interface

The SGi Interface connects the PDN-GW to an external PDN. This could be the public

Internet, Corporate Intranets or a service provider’s network supporting services such as the

IMS. Although defined by the 3GPP, the protocols which operate over the SGi Interface are

defined by the IETF and include TCP, UDP in addition to a host of application specific

protocols.

Figure 2-19 SGi Interface Protocols

3 LTE/SAE Quality of Service LTE Protocols and Procedures



Issue 06 (2006-03-01)

3 LTE/SAE Quality of Service About This Chapter


Section

3.1 EPS Bearer Services and

E-UTRA Radio Bearers

3.2 E-UTRA Radio Bearers

LTE Protocols and Procedures 3 LTE/SAE Quality of Service



3-33

3.1 EPS Bearer Services and E-UTRA Radio Bearers

3.1.1 QoS in Packet Switched Networks

In order to support a mixture on non-real time and real time applications such as voice and

multimedia, the issues associated with radio access based contention means that delay and

jitter may become excessive if the flows of traffic are not coordinated. Modern packet

switches are now termed “QoS aware”, in that they are able to classify, schedule and forward

traffic based on the destination address, as well as the type of media being transported. Figure

3-1 illustrates how the concept of packet classification and scheduling is part of the eNB,

S-GW and PDN-GW responsibilities.

Figure 3-1 QoS Packet Scheduling

The main functions associated with QoS in a packet switch (router) are the:

� Packet Classifier - this function analyses packets and based on a set of filters classifies

the packet. As such, it receives the correct packet forwarding treatment and scheduling.

� Packet Scheduler - this schedules packets based on priority. In so doing various methods

are used to ensure low latency data, e.g. voice, is optimally scheduled.

3.1.2 LTE Bearers

The LTE system utilizes the concept of bearers. In so doing, a bearer has been defined to be

the aggregate of one or more IP flows related to one or more services.

Figure 3-2 illustrates the main bearer terminology in LTE. Note that if the system employs

PMIP (Proxy MIP) on the S5/S8 interfaces then the EPS Bearers effectively terminate on the

S-GW.




Issue 06 (2006-03-01)

Figure 3-2 LTE Bearers

End to End Bearer Service

The end to end service runs between the UE and the peer entity, such as a call server, web

server etc. This is supported by an EPS Bearer plus external bearers that may support the

equivalent QoS across the external networks, i.e. beyond the SGi Interface.

EPS Bearer Service

The EPS Bearer extends between the UE and the PDN-GW. It is defined as a logical

aggregate of one or more SDF (Service Data Flow). The EPS Bearer QoS is managed and

controlled in the EPC / E-UTRAN. Figure 3-3 illustrates the concept of Service Data Flows

mapping into the same EPS bearer. Note that the S-GW and eNB are both unaware of the

mapping.

Figure 3-3 Service Data Flows

EPS Radio and Access Bearer

The EPS Bearer consist of two parts the EPS Radio Bearer and the EPS Access Bearer. The

EPS Radio Bearer facilitates the transport of the EPS Bearer traffic between the UE and the

eNB. Note that the eNB manages the QoS. The EPS Access Bearer service provides the




3-35

transport between the S-GW / PDN-GW and eNB according to the EPS QoS profile

associated with each EPS Bearer.

3.1.3 The Default EPS Bearer

LTE enables the UE to operate as “always on”. This is achieved by establishing a default EPS

bearer during the LTE Attach process. The default EPS bearer is configured as non-GBR (non

- Guaranteed Bit Rate) and carries all traffic which is not associated with a dedicated bearer.

Figure 3-4 Default and Dedicated EPS Bearers

It is possible for the UE to establish more than one default EPS bearer, however this is via a different

APN (Access Point Name).

3.1.4 Dedicated EPS Bearers

Dedicated EPS bearers carry traffic for IP flows that have been identified to require a specific

QoS. This classification is achieved using a TFT (Traffic Flow Template) at the PDN-GW and

UE. The TFT, i.e. filters, for the UE to utilize for each dedicated EPS bearer are passed to the

UE in NAS ESM signaling.

Dedicated EPS bearers may be established during the Attach. For example, in the case of

services that require “always-on” connectivity and higher QoS than that provided by the

default bearer. Dedicated bearers can be either GBR (Guaranteed Bit Rate) or non-GBR.

3.1.5 EPS QoS Parameters

EPS Bearers may support Guaranteed or Non Guaranteed Bit Rate services. As such various

parameters are used to control and identify the QoS.

GBR QoS Information

The GBR QoS Information parameter provides the eNB with information on the uplink and

downlink rates. It can include:

� E-RAB Maximum Downlink Bit Rate.

� E-RAB Maximum Uplink Bit Rate.

� E-RAB Guaranteed Downlink Bit Rate.

� E-RAB Guaranteed Uplink Bit Rate.




Issue 06 (2006-03-01)

AMBR (Aggregate Maximum Bit Rate)

Non Guaranteed EPS Bearers are subject to control through an AMBR (Aggregate Maximum

Bit Rate). The AMBR applies to both the subscriber and APN (Access Point Name) associated

with the subscriber.

� UE AMBR (User Equipment Aggregate Maximum Bit Rate) - this value applies to the

total bit rate that can be allocated to a subscriber for all its non-GBR services.

� APN AMBR (Access Point Name Aggregate Maximum Bit Rate) - this value applies to

the total bit rate that can be allocated to the subset of a subscriber’s services associated

with a particular APN.

QoS Class Indicator

QCI (QoS Class Indicator) provides a simple mapping from an integer value to specific QoS

parameters that controls bearer level packet forwarding treatment. Currently eight label types

have been defined, these are illustrated in Table 3-1.

Table 3-1 QCI Attributes

QCI Type Priority Packet Delay Budget (ms)

Packet Error Rate

Example Service

1 GBR 2 100 10-2

Conversational Voice

2 GBR 4 150 10-3

Conversational Video

3 GBR 3 50 10-3

Real Time Gaming

4 GBR 5 300 10-6

Non-Conversational Voice

5 Non-GBR 1 100 10-6

IMS Signaling

6 Non-GBR 6 300 10-6

Video, TCP Based

7 Non-GBR 7 100 10-3

Voice, Video, Interactive

Gaming

8 Non-GBR 8 300 10-6

Video, TCP Based

9 Non-GBR 9 300 10-6

Video, TCP Based

ARP (Allocation and Retention Priority)

The ARP (Allocation and Retention Priority) indicates if a bearer establishment or

modification request can be accepted. In addition, it may be used to indicate which bearers are

dropped when there is congestion in the network. The main parameters include:

� Priority Level (0 to 15) - Value 15 means "no priority", whereas values between 1 and 14

are ordered in decreasing order of priority, i.e. 1 is the highest and 14 the lowest, with

value 0 being reserved.




3-37

� Pre-emption Capability - this indicates the pre-emption capability on other E-RABs. In

so doing, it indicates whether the E-RAB will not pre-empt other E-RABs or, the E-RAB

may pre-empt other E-RABs.

� Pre-emption Vulnerability - this indicates the vulnerability of the E-RAB to preemption

of other E-RABs.

3.2 E-UTRA Radio Bearers

The LTE air interface has two types of radio bearers, namely Signaling Radio Bearers and

Data Radio Bearers.

3.2.1 Signaling Radio Bearers

A SRB (Signaling Radio Bearer) is a RB (Radio Bearer) that is only used for the transmission

of RRC and NAS messages. More specifically, the following three SRBs are defined:

� SRB0 - this is for RRC messages using a CCCH logical channel, e.g. RRC Connection

Request, Setup and Re-establishment.

� SRB1 - this is mainly for RRC messages using a DCCH logical channel. It can also be

used for NAS messages prior to the establishment of SRB2.

� SRB2 - this is for NAS messages using a DCCH logical channel. Note that SRB2 has a

lower-priority than SRB1 and is always configured by the E-UTRAN after security

activation.

Figure 3-5 Signaling Radio Bearers

3.2.2 Data Radio Bearers

In addition to Signaling Radio Bearers, at least one DRB (Data Radio Bearer) needs to be

established for the Default EPS bearer. There are various identities used in LTE at different

layers to identify the EPS bearers. The main higher layer identifier is the EPS Bearer Identity,

this has a value between 0 to 15. In a UMTS network this is referred to as a NSAPI (Network

layer Service Access Point Identifier). When the EPS bearer is established an associated DRB

Identity is assigned. These have values between 1 and 32. Finally, the lower layers, i.e. MAC,

allocate the LCID (Logical Channel Identity). There are only 10 available for Radio Bearers,

with the values 1 and 2 mapping to SRB1 and SRB2 respectively. In so doing, the remaining

eight LCID are available for Data Radio Bearers (1 Default EPS Bearer and 7 Dedicated EPS

Bearers).

Figure 3-6 illustrates how the Data Radio Bearer relates to an EPS bearer. In this case the

Default EPS Bearer.




Issue 06 (2006-03-01)

Figure 3-6 Data Radio Bearers

3.2.3 Radio Bearer QoS

The QoS for Data Radio Bearers is provided to the eNB by the MME using the standard QoS

attributes such as QCI and ARP, as well as maximum and guaranteed bit rates in the uplink

and downlink direction. Based on these the eNB configures the UE E-UTRA layers and

manages the ongoing scheduling of uplink and downlink traffic.

Figure 3-7 E-RAB QoS Parameters to the eNB




3-39

E-UTRA Configuration

In order to achieve the QoS for the E-RAB the eNB configures the lower layer protocols,

namely PDCP, RLC, MAC and the Physical Layers.

Figure 3-8 E-UTRA E-RAB QoS

There are various parameters that could be configured/modified to influence the performance

of the E-UTRA and thus aid the eNB QoS scheduling requirements. These include:

� PDCP Compression.

� RLC AM or UM.

� RLC AM Polling Configuration.

� Uplink MAC Priority.

� Uplink MAC Prioritized Bit Rate.

� Uplink MAC Bucket Size Duration.

� HARQ Configuration and re-transmissions.

� BSR (Buffer Status Report) Configuration.

� SPS (Semi Persistent Scheduling) Configuration.

� Physical Channel and Power Configuration.

4 Radio Resource Control LTE Protocols and Procedures



Issue 06 (2006-03-01)

4 Radio Resource Control About This Chapter


Section

4.1 The RRC Layer

4.2 RRC Structure

4.3 RRC States

4.4 RRC Services

LTE Protocols and Procedures 4 Radio Resource Control



4-41

4.1 The RRC Layer

RRC (Radio Resource Control) is the main control protocol between the UE and the eNB. Its

key functions include: radio resource management, admission control and security functions,

handover control and E-UTRAN mobility management. The RRC protocol utilizes the lower

layer services of PDCP, RLC and MAC. In addition, it also handles NAS signaling between

the UE and MME. Note that when RRC is carrying NAS signaling, it does not alter the

information but instead, provides the delivery mechanism. Even though RRC uses the

services of the lower layers, it is also responsible for the ongoing configuration of these

layers. This is illustrated in Figure 4-1, with the control lines illustrating the interaction and

management with lower layers.

Figure 4-1 RRC Interaction with Lower Layers

The layers below RRC also include generic configuration options, e.g. defined mapping rules

for SI (System Information) messages. This enables the UE to acquire the eNB and ultimately

gain access to the network.

4.1.2 Services Provided To Upper Layers

The RRC protocol offers the following services to upper layers:

� Broadcast of common control information.

� Notification of UEs in RRC Idle mode, e.g. about a terminating call.

� Transfer of dedicated control information, i.e. information for one specific UE.

4.1.3 Services Expected From Lower Layers

The main services that RRC expects from lower layers include:

� PDCP - integrity protection and ciphering.

� RLC - a reliable and in-sequence transfer of information, without introducing duplicates

and with support for segmentation and concatenation.




Issue 06 (2006-03-01)

4.2 RRC Structure

Compared to UMTS, RRC has been simplified in terms of the number of messages and the

configuration of the SRB (Signaling Radio Bearer). However, there are still a large number of

parameters and options available to ensure the system can be optimized.

Figure 4-2 illustrates the general structure of the air interface protocols at the eNB. Note that

higher layer NAS signaling and IP datagrams are relayed by the eNB. In addition, RRC also

forms a key part of RRM (Radio Resource Management).

Figure 4-2 eNB Structure

4.3 RRC States

There are three LTE mobility states, namely: LTE Idle, LTE Active and LTE Detached. The

initial EMM Attach procedure enables a UE to transition into the LTE Active State from the

LTE Detached State.

In LTE, RRC has two main states, namely:

� RRC Idle - this provides services to support DRX (Discontinuous Reception), broadcast

of SI (System Information) to enable access, cell reselection and paging information.

� RRC Connected - in this state the UE has state information stored in the eNB and has an

RRC connection, i.e. SRB (Signaling Radio Bearer). The eNB can track the UE to the

cell level and RRC provides services to support cell measurements in order to facilitate

network controlled handovers.

Figure 4-3 illustrates the different LTE states, as well as some of the key functions performed

by RRC in these states.

In addition to having a GUTI (Globally Unique Temporary Identity) and S-TMSI (Serving -

Temporary Mobile Subscriber Identity), whilst in the RRC Connected mode, the UE is also

allocated an E-UTRAN identifier(s). The most common is the C-RNTI (Cell - Radio Network

Temporary Identity), however other forms of RNTI (Radio Network Temporary Identity) also

exist.




4-43

Figure 4-3 RRC States

4.3.2 Functions

The RRC protocol includes the following main functions:

� Broadcast of SI (System Information):

− Including NAS common information.

− Information applicable for UEs in RRC Idle mode, e.g. cell (re-)selection parameters,

neighboring cell information and information applicable for UEs in RRC Connected

mode, e.g. common channel configuration information.

− Including ETWS (Earthquake and Tsunami Warning System) notification.

� RRC Connection control:

− Paging.

− Establishment/modification/release of RRC connection, including e.g. assignment/

modification of UE identity (C-RNTI), establishment/modification/release of SRB1

and SRB2, AC (Access Class) barring.

− Initial security activation, i.e. initial configuration of Access Stratum integrity

protection (SRBs) and Access Stratum ciphering (SRBs, DRBs).

− RRC connection mobility including e.g. intra-frequency and inter-frequency

handover, associated security handling, i.e. key/algorithm change, specification of

RRC context information transferred between network nodes.

− Establishment/modification/release of RBs carrying user data (DRBs).

− Radio configuration control including e.g. assignment/modification of ARQ

(Automatic Repeat Request) configuration, HARQ (Hybrid ARQ) configuration,

DRX (Discontinuous Reception) configuration.




Issue 06 (2006-03-01)

− QoS control including assignment/modification of SPS (Semi-Persistent Scheduling)

configuration information for downlink and uplink, assignment/modification of

parameters for uplink rate control in the UE, i.e. allocation of a priority and a PBR

(Prioritized Bit Rate) for each RB (Radio Bearer).

− Recovery from Radio Link failure.

� Inter-RAT mobility including e.g. security activation, transfer of RRC context

information.

� Measurement configuration and reporting:

− Establishment/modification/release of measurements (e.g. intra-frequency,

inter-frequency and inter-RAT measurements).

− Setup and release of measurement gaps.

− Measurement reporting.

� Other functions including e.g. transfer of dedicated NAS information and non-3GPP

dedicated information, transfer of UE radio access capability information, support for

E-UTRAN sharing (multiple PLMN identities).

� Generic protocol error handling.

� Support of self-configuration and self-optimization.

RRC State Interaction

In addition to RRC Idle and RRC Connected there are various transitions to and from UTRA

(Universal Terrestrial Radio Access) and GERAN (GSM/EDGE Radio Access Network)

States. Figure 4-4 illustrates the main states and inter-RAT mobility procedures.

Figure 4-4 E-UTRA RRC State Interaction

In contrast to the GERAN and UTRA states, the E-UTRA (Evolved - Universal Terrestrial

Radio Access) state is simplified. This is mainly due to the fact that it is an optimized packet

system.




4-45

Interaction with CDMA2000 States

In addition to interworking with UMTS and GERAN, the LTE system is also able to

interwork with CDMA2000 1xRTT CS (Circuit Switched) and HRPD (High Rate Packet Data)

based systems. Figure 4-5 illustrates the main mobility transitions for CDMA2000

interworking.

Figure 4-5 Mobility Procedures between E-UTRA and CDMA2000

4.4 RRC Services

There are various procedures performed by RRC. This section includes many of them.

4.4.1 System Information

SI (System Information) in LTE is usually broken down into the MIB (Master Information

Block), SIB 1 (System Information Block 1) and other System Information messages. Figure

4-6 illustrates the main MIB and SIB1 parameters.

Figure 4-6 MIB and SIB1 Parameters




Issue 06 (2006-03-01)

MIB and SIB repeat regularly on the cell. The Scheduling Information List and SIB Window

Length parameters enable the UE to determine the occurrence of the other SI messages.

Figure 4-7 illustrates the different SIBs, as well as some of the key parameters, which may be

scheduled by the eNB. Further information on parameters can be found in the RRC

Specification 36.331.

Figure 4-7 LTE SIBs

SIB2

Access Class Information

Radio Resource Configuration Common

UE-Timers And Constants

Uplink Frequency Information

MBSFN Configuration Information

Time Alignment Timer Common

SIB3

Cell Reselection Information

Q-Hyst

Speed State Reselection Parameters

Cell Reselection Serving Freq Info

S-Non-Intra Search Info

Threshold Serving Low Value

Cell Reselection Priority

Intra Freq Cell Reselection Info

q-RxLevMin

p-Max

s-IntraSearch

Allowed Measurement Bandwidth

Presence Antenna Port 1

Neighbor Cell Config

t-ReselectionEUTRA

t-ReselectionEUTRA-SF

SIB4

Intra Freq Neighbour Cell List

Physical Cell ID

q-OffsetCell

Intra Freq Black Cell List

CSG Physical Cell Id Range

SIB5

Inter Frequency Carrier Freq List

Inter Frequency Carrier Freq Info

Inter Frequency Neighbour Cell List

Inter Frequency Neighbour Cell Info

Inter Frequency Black Cell List

SIB6

Carrier Frequency List UTRA (FDD/TDD)

t-Reselection UTRA

SIB7

t-Reselection GERAN

Carrier Frequency Info List

SIB8

CDMA2000 Reselection Information

SIB9

Home eNB Name

SIB10

ETWS Primary Notification

SIB11

ETWS Secondary Notification

4.4.2 Paging

Whilst the UE is in the RRC Idle mode it is monitoring the PCH (Paging Channel) based on a

DRX (Discontinuous Reception) cycle.

The eNB is instructed to send a Paging message to a given UE (IMSI or S-TMSI) within a

Tracking Area (one or more). It is also provided a UE Identity Index parameter from the

MME which enables the eNB and the UE to synchronize the paging occurrence.

Figure 4-8 illustrates the Paging message. This includes the UE identity, as well as an

indication from the domain it came from, namely CS (Circuit Switched) or PS (Packet




4-47

Switched). The Paging message is also able to carry an indication of SI modification, as well

as an indication of an ETWS primary notification and/or ETWS secondary notification.

Figure 4-8 RRC Paging

4.4.3 RRC Connection Establishment

The process of establishing an RRC Connection moves the UE from RRC Idle mode into

RRC Connected mode. Prior to sending the initial RRC Connection Request message the UE

must have preformed a Random Access procedure for uplink resources and has been allocated

these on the UL-SCH, i.e. the RRC Connection procedure is performed on the uplink and

downlink shared channels. Figure 4-9 illustrates the basic RRC Connection establishment

procedure, as well as key parameters.

Figure 4-9 RRC Connection




Issue 06 (2006-03-01)

It must be noted that some of the parameters are optional. This is especially the case with the

initial RRC Connection Setup message which can be used as part of the re-establishment

procedures.

Initial SRB

SRB 1 is the main bearer established as part of the initial RRC Connection. Typically the eNB

configures this along with other key features such as:

� MAC Main Configuration - this includes UL-SCH parameters configuring HARQ

(Hybrid ARQ), BSR (Buffer Status Report) timers and PHR (Power Head Room)

reporting.

� Physical Configuration Dedicated - configures some of the initial parameters for the

PDSCH, PUCCH and PUSCH. It also includes initial attributes to configure power

control.

It is worth noting that quite a lot of the RRC Connection Setup parameters are not used

initially, e.g. configuration of DRB (Data Radio Bearer), TPC (Transmit Power Control), SRS

(Sounding Reference Signal) etc.

RRC Connection Reject

Upon receiving a RRC Connection Request the eNB is able to send a RRC Connection Reject.

This includes the Wait Time which the UE will use as the T302 timer. Once the UE is in the

RRC Connected mode or has performed a cell re-selection the T302 timer is stopped.

However, if T302 expires the higher layers are informed about barring alleviation.

4.4.4 Initial Security Activation

The activation of security by RRC is relatively simple. The eNB initiates the procedure by

identifying which ciphering and integrity algorithms to use. Additional information on

integrity and ciphering is discussed in Sections 5.1.5 and 5.1.6 respectively.

Figure 4-10 RRC Security Mode Command

4.4.5 RRC Connection Reconfiguration

The purpose of the RRC Connection Reconfiguration procedure is to modify an RRC

connection, e.g. to establish/modify release RBs, to perform handover, to

setup/modify/release measurements. In addition, as part of the procedure, NAS dedicated

information may be transferred from E-UTRAN to the UE.




4-49

Figure 4-11 illustrates the RRC Connection Reconfiguration message and some of the key

parameters. Since the messages can be used in a multitude of scenarios it contains a lot of

optional parameters.

Figure 4-11 RRC Connection Reconfiguration

Default EPS Bearer

As part of the EMM Initial Attach procedure the network (MME) initiates the establishment

of the Default EPS Bearer. This triggers the sending of a RRC Connection Reconfiguration

Request message which is able to configure a DRB (Data Radio Bearer) for the Default EPS

Bearer, as well as establishing SRB2. In this example, the RRC Connection Reconfiguration

Request message also configures MAC DRX and additional physical features such as power

control, SRS and CQI (Channel Quality Indication) reporting.

4.4.6 RRC Connection Re-establishment

The RRC Connection Re-establishment message is used to resolve contention, to re-establish

SRB1 and to re-activate security.

The UE initiates the procedure when AS security has been activated and one of the following

conditions is met:

� Upon detecting RLF (Radio Link Failure).

� Upon handover failure.

� Upon mobility from E-UTRA failure.

� Upon integrity check failure indication from lower layers.

� Upon an RRC Connection Reconfiguration failure.

Figure 4-12 illustrates the RRC Connection Reestablishment procedure. The RRC Connection

Reestablishment Request message includes a cause value:

� Reconfiguration Failure.

� Handover Failure.

� Other Failure.




Issue 06 (2006-03-01)

Figure 4-12 RRC Connection Reestablishment

The RRC Connection Reestablishment message includes the Radio Resource Config

Dedicated parameter which is able to reestablish the RBs, as well as the MAC and Physical

configuration. In addition, the message also includes the Next Hop Chaining Count parameter

to update the KeNB key.

4.4.7 RRC Connection Release

The purpose of this procedure is to release the RRC connection, which includes the release of

the established radio bearers as well as all radio resources.

Figure 4-13 illustrates the RRC Connection Release message. If the Idle Mode Mobility

Control Info parameter is included, intra-frequency, inter-frequency and inter-RAT priority

information can be included. In addition, a T320 timer indicates to the UE how long this

dedicated priority is valid. In so doing, on the expiry of the T320 timer the UE removes the

priority given in the Idle Mode Mobility Control Info parameter and relies on the information

in the System Information messages.

Figure 4-13 RRC Connection Release

4.4.8 Radio Link Failure

The Radio Link Failure procedure is triggered on the expiry of a timer “T310”. This is started

when RRC receives N310 consecutive "out-of-sync" indications from lower layers. The

UE-TimersAndConstants parameter in SIB2 is used to pass the T310 and N310 values to the

UEs.




4-51

4.4.9 Information Transfer

The purpose of the Downlink and Uplink Information Transfer procedures is to transfer NAS

or (tunneled) non-3GPP dedicated information between the E-UTRAN and the UE.

Figure 4-14 illustrates the Information Transfer messages, as well as the main parameters,

namely dedicated NAS signaling.

Figure 4-14 Information Transfer

4.4.10 Measurement Configuration

The UE in RRC Connected mode reports measurement information in accordance with the

Measurement Configuration parameter provided by the eNB in a RRC Connection

Reconfiguration message. In so doing, the UE can be requested to perform the following

types of measurements:

� Intra-frequency measurements: measurements at the downlink carrier frequency of the

serving cell.

� Inter-frequency measurements: measurements at frequencies that differ from the

downlink carrier frequency of the serving cell.

� Inter-RAT measurements of UTRA frequencies.

� Inter-RAT measurements of GERAN frequencies.

� Inter-RAT measurements of CDMA2000 HRPD or CDMA2000 1xRTT frequencies.

Key Parameters of Measurement Configuration

The measurement configuration includes the following parameters:

� Measurement objects - these are the objects on which the UE is configured to perform

the measurements.

� Reporting configurations - this is a list of reporting attributes. It includes the reporting

type, namely Periodical or Event Based, as well as the associated attributes.

� Measurement identities - this is a list of measurement identities where each measurement

identity links one measurement object with one reporting configuration. By configuring

multiple measurement identities it is possible to link more than one measurement object

to the same reporting configuration, as well as to link more than one reporting

configuration to the same measurement object. The measurement identity is used as a

reference number in the measurement report.

� Quantity configurations - this is configured per RAT type and defines the associated

filtering used for all event evaluation and related reporting of that measurement type.




Issue 06 (2006-03-01)

� Measurement gaps - this defines the periods that the UE may use to perform

measurements, i.e. no downlink or uplink transmissions are scheduled.

� S-Measure - this optional parameter is a serving cell quality threshold controlling

whether or not the UE is required to perform measurements of intra frequency, inter

frequency and inter RAT neighboring cells.

Figure 4-15 illustrates the main measurement configuration parameters in the RRC

Connection Reconfiguration Request message.

Figure 4-15 Measurement Configuration

Measurement Objects

Figure 4-16 illustrates some of the key parameters for an E-UTRA measurement object. It

includes:

� measObjectId - this is the identifier for the measurement object.

� carrierFreq - this is the carrier frequency to measure.

� allowedMeasBandwidth - is used to indicate the maximum allowed measurement

bandwidth on a carrier frequency.

� presenceAntennaPort1 - this is used to indicate whether all the neighboring cells use

Antenna Port 1. When set to TRUE, the UE may assume that at least two cell-specific

antenna ports are used in all neighboring cells.

� neighCellConfig - is used to provide the information related to MBSFN (MBMS over a

Single Frequency Network) and TDD UL/DL configuration of neighbor cells.

� offsetFreq - this defines the offset value applicable to the carrier frequency.

� cellsToAddModList - this defines the neighboring cell(s) in terms of:

− cellIndex - this is the entry index in the neighboring cell list. It is used for future

modification or deletion.

− physCellId - this is the Physical Cell ID for the neighboring cell.

− cellIndividualOffset - this is the cell individual offset applicable to a specific

neighboring cell.

Details of these parameters, as well as other not shown, can be found in the RRC

Specification, namely TS 36.331.




4-53

Figure 4-16 Measurement Object

Report Configuration

The Report Configuration parameter is an important aspect of the measurement process and is

very similar to the methods employed in UMTS. Figure 4-17 illustrates an example of the

Report Configuration parameter. Note that not all options are shown.

Figure 4-17 Report Configuration

Broadly there are two types of reporting methods: periodical and event based. Figure 4-18

illustrates the periodical reporting concept with a configured Report Interval. In addition to

the reporting interval the eNB also configures the Report Amount which indicates how may

reports to send (r1, r2, r4, r8, r16, r32, r64 or infinity).




Issue 06 (2006-03-01)

Figure 4-18 Periodical Reporting

LTE, like UMTS, includes a number of measurement based triggering events, these include:

� Event A1 - serving cell becomes better than the threshold.

� Event A2 - serving cell becomes worse than the threshold.

� Event A3 - neighbor cell becomes (including offset) better than the serving cell.

� Event A4 - neighbor cell becomes better than the threshold.

� Event A5 - serving cell becomes worse than Thresh1 (Threshold1) and the neighbor cell

becomes better than Thresh2 (Threshold2).

� Event B1 - Inter RAT neighbor cell becomes better than threshold.

� Event B2 - serving cell becomes worse than threshold1 and inter RAT neighbor cell

becomes better than threshold2.

Figure 4-19 illustrates the basic concept of event based reporting using Event A3 as an

example. Note this has been simplified.

Figure 4-19 Event Based Trigger (Event A3)

Event Reporting

A3 Offset

(-30 to 30dB)

TTT (Time to Trigger)

Report Interval and Report Amount




4-55

The event based mechanisms also configure a TTT (Time To Trigger) parameter. This

validates criteria before the measurement report is sent. Values for TTT include: ms0, ms40,

ms64, ms80, ms100, ms128, ms160, ms256, ms320, ms480, ms512, ms640, ms1024, ms1280,

ms2560 and ms5120 (in milliseconds).

Event Conditions

It is worth noting that the actual triggering mechanisms for each event are different (detailed

in the RRC Specification). As an example, Event A3 criteria is shown.

For Event A3, the TTT timer starts and stops based on the following criteria.

� Entering condition: Mn+ Ofn + Ocn− Hys > Ms + Ofs + Ocs + Off

� Leaving condition: Mn+ Ofn + Ocn+ Hys < Ms + Ofs + Ocs + Off

The variables in the formula are defined as follows:

� Mn - this is the measurement result of the neighboring cell, not taking into account any

offsets.

� Ofn - this is the frequency specific offset of the frequency of the neighbor cell (i.e.

offsetFreq as defined within measObjectEUTRA corresponding to the frequency of the

neighbor cell).

� Ocn - this is the cell specific offset of the neighbor cell (i.e. cellIndividualOffset as

defined within measObjectEUTRA corresponding to the frequency of the neighbor cell),

and set to zero if not configured for the neighbor cell.

� Ms - this is the measurement result of the serving cell, not taking into account any

offsets.

� Ofs - this is the frequency specific offset of the serving frequency (i.e. offsetFreq as

defined within measObjectEUTRA corresponding to the serving frequency).

� Ocs - this is the cell specific offset of the serving cell (i.e. cellIndividualOffset as defined

within measObjectEUTRA corresponding to the serving frequency), and is set to zero if

not configured for the serving cell.

� Hys - this is the hysteresis parameter for this event (i.e. hysteresis as defined within

reportConfigEUTRA for this event).

� Off - this is the offset parameter for this event (i.e. a3-Offset as defined within

reportConfigEUTRA for this event).

Mn and Ms are expressed in dBm in case of RSRP (Reference Signal Received Power), or in

dB in case of RSRQ (Reference Signal Received Quality). Ofn, Ocn, Ofs, Ocs, Hys, Off are

expressed in dB (Decibels).

Figure 4-20 illustrates an example of Event 3A. The various offset have been applied to the

serving and neighboring cells and the hysteresis value is illustrated by the dotted lines above

and below the neighboring cell level.




Issue 06 (2006-03-01)

Figure 4-20 Event A3 Example

It can be seen that the entering and leaving conditions are based on the interaction with

hysteresis value (which could be set to 0).

4.4.11 Handover Configuration

The RRC handover procedures are discussed as part of X2 Handover in Section 8.1 .

4.4.12 Cell Selection

LTE has two cell selection procedures known as “Initial Cell Selection”, in which the UE

requires no prior knowledge, and “Stored Information Cell Selection” in which stored

information is used to optimize the selection process.

After a UE has synchronized with the cell and decoded the necessary SI messages, it attempts

to camp on a cell. This is achieved through the cell selection process whereby the UE is

aiming to select the cell which will provide the best quality radio link. The process for cell

selection is as follows:

� In terms of the radio channel, the UE measures the RSRP (Reference Signal Received

Power). The LTE downlink and uplink physical frames contain RS (Reference Signal)

which are used as pilot information to aid equalization of the channel. The received

power of these signals may be used as the criteria for cell selection.

� It calculates the received level average power for each cell based on one of the above.

This term is defined as Qrxlevmeas for LTE cells and is expressed in dBm .

� It assesses the minimum signal level that is acceptable within the cell. The Qrxlevmin

and other parameters are provided to the UE through RRC SI messages.

4.4.13 Cell Reselection

Whilst in the RRC Idle mode the UE will regularly search for a better cell. This change of cell

may also imply a change of RAT (Radio Access Technology).

The cell reselection process can be summarized thus:




4-57

� If the serving cell is bad (“bad” as defined by broadcasted quality and/or signal strength

criteria), the UE will start monitoring cells belonging to other RATs, as well as cells

belonging to the currently used RAT.

� The UE should exclude neighboring cells that do not fulfill broadcasted minimum

quality/signal level requirements.

� The UE should rank the non-excluded cells by also taking into consideration broadcasted

(positive or negative) offset values.

� Finally, the UE should reselect the best cell, from the same RAT or some other RAT, if it

fulfills the cell reselection criteria for a given duration of time.

5 Packet Data Convergence Protocol LTE Protocols and Procedures



Issue 06 (2006-03-01)

5 Packet Data Convergence Protocol About This Chapter


Section

5.1 PDCP Operation

LTE Protocols and Procedures 5 Packet Data Convergence Protocol



5-59

5.1 PDCP Operation

5.1.1 Functions

PDCP (Packet Data Convergence Protocol) provides services to both the Control Plane and

User Plane. The main PDCP functions include:

� Header compression and decompression of IP datagrams using the ROHC (Robust

Header Compression) protocol.

� Maintenance of PDCP SN (Sequence Number) for radio bearers operating in RLC AM

(Acknowledged Mode).

� In-sequence delivery of upper layer PDU (Protocol Data Units) at handover.

� Duplicate elimination of lower layer SDUs at handover for RLC AM radio bearers.

� Ciphering and deciphering of User and Control Plane data.

� Integrity protection and integrity verification of the Control Plane data.

� Discarding of data on a timeout basis.

� Discarding of data on a duplicate basis.

Figure 5-1 illustrates the various functions performed by the transmitting and receiving PDCP

entity. The PDCP SDU (Service Data Unit) identifies a packet from higher layers, i.e. RRC or

IP. In contrast, packets not associated to a PDCP SDU are part of PDCP control signaling.

Typical examples include PDCP Status Report and Header Compression Feedback

Information.

Figure 5-1 PDCP Functions




Issue 06 (2006-03-01)

5.1.2 PDCP Header Compression Profiles

PDCP includes a number of ROHC (Robust Header Compression) profiles. Table 5-1

illustrates the available profiles and associated usage. Note that profile 0x0000, which

indicates ROHC uncompressed, must always be supported when the use of ROHC is

configured.

Table 5-1 Supported Header Compression Protocols and Profiles

Profile Identifier Usage: Reference

0x0000 No compression RFC 4995

0x0001 RTP/UDP/IP RFC 4815

0x0002 UDP/IP RFC RFC 3095, RFC 4815

0x0003 ESP/IP RFC RFC 3095, RFC 4815

0x0004 IP RFC 3843, RFC 4815

0x0006 TCP/IP RFC 4996

0x0101 RTP/UDP/IP RFC 5225

0x0102 UDP/IP RFC 5225

0x0103 ESP/IP RFC 5225

0x0104 IP RFC 5225

The main references include:

� RFC4995 - this defines the ROHC Framework, defining an efficient and future-proof

header compression concept.

� RFC 3095 - this extends the ROHC framework and includes four profiles. These are:

− RTP/UDP/IP.

− UDP/IP.

− ESP/IP (Encapsulating Security Payload form of IPSec).

− Uncompressed.

� RFC 4815- this provides corrections and clarifications.

� RFC 4996 - this defines a profile for TCP/IP (Transmission Control Protocol, Internet

Protocol) compression.

� RFC 5225 - this defined ROHCv2 (Robust Header Compression Version 2) and

identifies profiles for RTP, UDP, IP, ESP and UDP-Lite compression.

IMS Profiles

IMS (IP Multimedia Subsystem) capable UEs supporting VoIP (Voice over IP) are required to

support ROHC profiles 0x0000, 0x0001, 0x0002 and 0x0004.




5-61

5.1.3 PDCP Headers

The PDCP layer identifies two types of PDUs, namely data and control. The PDCP Data PDU

is used to convey:

� Control Plane data, i.e. the Signaling Radio Bearer.

� User Plane data (compressed or uncompressed).

� PDCP SDU SN (Sequence Number).

In contrast, the Control PDUs are used for ROHC feedback and PDCP status reporting.

Control Plane PDCP Data PDU for SRBs

Figure 5-2 defines the format of the PDCP Data PDU for SRB transfer. It includes a 5bit SN

(Sequence Number) and a MAC-I (Message Authentication Code - Integrity) check.

Figure 5-2 PDCP Data PDU for SRB

User Plane PDCP Data PDU - 12bit SN

In the User Plane there are two Data PDUs defined, each with a different length sequence

number. Figure 5-3 illustrates the long SN PDU which includes a 12bit SN.

Figure 5-3 User Plane PDCP Data PDU with Long PDCP SN (12 bits)

The first bit is assigned to a D/C (Data/Control) bit, where 0 = Control PDU and 1 = Data

PDU. Note that the 12bit SN format is available to both RLC AM or UM.

User Plane PDCP Data PDU - 7bit SN

Figure 5-4 illustrates the PDCP Data PDU with a 7bit SN. Note that this format is only

available when operating in RLC UM.




Issue 06 (2006-03-01)

Figure 5-4 User Plane PDCP Data PDU with Short PDCP SN (7 bits)

Higher layer signaling, i.e. RRC, is used to configure the PDCP options.

PDCP Control PDU - Status Report

Figure 5-5 illustrates a PDCP Control PDU providing PDCP Status Report information. It

includes the FMS (First Missing PDCP Sequence Number), as well as an optional bitmap. The

bitmap includes 0s and 1s, where a zero indicates a PDCP SDU is missing in the receiver.

Figure 5-5 PDCP Control PDU for PDCP Status Report

PDCP Control PDU - Feedback

Figure 5-6 illustrates the Control PDU for ROHC feedback. This is sent uncompressed and

includes a ROHC feedback packet.

Figure 5-6 PDCP Control PDU for Interspersed ROHC Feedback Packet

5.1.4 PDCP ROHC

ROHC works by enabling the sender and the receiver to store the static parts of the header, for

example the IP addresses, whilst only updating the dynamic part. The sender is typically

referred to as the compressor and the receiver the decompressor.

VoIP (Voice over IP) is one of the most important usages for ROHC. This is due to the

potentially high ratio between header and payload. For example, AMR 12.2Kbps packets are

just over 30octets and typically 32octets with framing. The RTP/UDP/IPv4 header is 40 octets




5-63

and is therefore bigger that the payload. In contrast, the RTP/UDP/IPv6 header is 60 octets.

The addition of ROHC enables the RTP/UDP/IPv4 and RTP/UDP/IPv6 to be reduced to 4 or 6

octets.

ROHC States

A ROHC compressor is in one of 3 main states:

� IR (Initialization and Refresh) - In this state the compressor has just been created or reset,

and full packet headers are sent.

� FO (First-Order) - In this state, the compressor has detected and stored the static fields

on both sides of the connection. The compressor is also sending dynamic packet field

differences.

� SO (Second-Order) - In this state the compressor is suppressing all dynamic fields such

as RTP sequence numbers and sending only a logical sequence number and partial

checksum to enable the other side to predict, generate and verify the headers of the next

expected packet.

Figure 5-7 ROHC Feedback

5.1.5 PDCP Integrity

LTE uses the EEA (EPS Encryption Algorithm) for ciphering and the EIA (EPS Integrity

Algorithm) for message integrity.

PDCP provides integrity of the SRBs. Figure 5-8 illustrates how the MAC-I (Message

Authentication Code - Integrity) value is generated. The input parameters to the integrity

algorithm are a 128bit integrity key (derived from the authentication process), a 32bit Count,

a 5bit bearer identity (equal to the RB identity -1), the 1bit direction of the transmission and

the message itself. The direction bit is set to 0 for uplink and 1 for downlink.




Issue 06 (2006-03-01)

Figure 5-8 Derivation of MAC-I

The 32bit count value consists of the PDCP SN and part of the HFN. This is illustrated in

Figure 5-9.

Figure 5-9 Count Value

5.1.6 PDCP Ciphering

There are two encryption algorithms, namely 128-EEA1 and 128-EEA2.

� 128-EEA1 is based on the SNOW 3G algorithm and is identical to UEA2.

� 128-EEA2 is based on the 128-bit AES (Advanced Encryption Standard).

Figure 5-10 illustrates the ciphering process. The inputs are nearly identical to the integrity

process, however the message input has been replaced with a length parameter. This ensures

that the keystream block generated is of the correct length to cipher the plaintext block.

Figure 5-10 PDCP Ciphering

EEAKey

Count

Bearer

Direction

Length

EEAKey

Count

Bearer

Direction

Length

Keystream

Block

Keystream

Block

Plaintext

Block

Plaintext

Block

Ciphertext

Block




5-65

6 Radio Link Control and Medium Access Control LTE Protocols and Procedures



Issue 06 (2006-03-01)

6 Radio Link Control and Medium Access Control

About This Chapter


Section

6.1 RLC Functions

6.2 RLC Modes and

Formatting

6.3 MAC Functions

6.4 MAC Architecture

6.5 MAC Formatting

LTE Protocols and Procedures 6 Radio Link Control and Medium Access Control



6-67

6.1 RLC Functions

6.1.1 Services Provided to Upper Layers

The following services are provided by RLC to RRC or PDCP:

� TM (Transparent Mode) - this provides a connectionless service and is utilized for some

of the air interface channels e.g. broadcast and paging.

� UM (Unacknowledged Mode) - like that of TM, this also provides a connectionless

service but with additional functionality incorporating sequencing, segmentation and

concatenation.

� AM (Acknowledged Mode) - this supports ARQ (Automatic Repeat Request) thereby

operating in a connection orientated mode.

Figure 6-1 RLC Modes

6.1.2 Services Expected from Lower Layers

The following services are expected by RLC from MAC:

� Data transfer.

� Notification of a transmission opportunity, together with the total size of the RLC PDU

(Protocol Data Units) to be transmitted in the transmission opportunity.

6.1.3 Functions

The following functions are supported by the RLC sub layer:

� Transfer of upper layer PDUs.

� Error correction through ARQ.

� Concatenation, segmentation and reassembly of RLC SDU (Service Data Units).

� Re-segmentation of RLC data PDUs.

� Reordering of RLC data PDUs.

� Duplicate detection.

� RLC SDU discard.

� RLC re-establishment.




Issue 06 (2006-03-01)

� Protocol error detection.

6.2 RLC Modes and Formatting

6.2.1 Transparent Mode

A TM (Transparent Mode) RLC entity can be configured to deliver/receive RLC PDUs

through the BCCH, DL/UL CCCH and PCCH logical channels. When a transmitting TM RLC

entity forms TMD (Transparent Mode Data) PDUs from RLC SDUs, it does not segment or

concatenate the RLC SDUs and it does not include any RLC headers in the TMD PDUs.

Figure 6-2 Transparent Mode RLC

6.2.2 Unacknowledged Mode

An UM RLC entity can be configured to deliver/receive RLC PDUs through the DTCH

logical channel.

Figure 6-3 Unacknowledged Mode RLC




6-69

The UM RLC entity forms UMD (Unacknowledged Mode Data) PDUs from RLC SDUs.

These may be a segment and/or concatenate the RLC SDUs so that the UMD PDUs fit

efficiently within the RLC PDU(s). This is based on the transmission opportunity indicated by

MAC. Finally, it includes the relevant RLC headers in the UMD PDU.

Receiving Entity

When a receiving UM RLC entity receives UMD PDUs, it:

� Detects whether or not the UMD PDUs have been received in duplication. If so, it

discards the duplicated UMD PDUs.

� Reorders the UMD PDUs if they are received out of sequence.

� Detects the loss of UMD PDUs at lower layers and avoid excessive reordering delays.

� Reassembles RLC SDUs from the reordered UMD PDUs (not accounting for RLC PDUs

for which losses have been detected) and deliver the RLC SDUs to upper layer in

ascending order of the RLC SN.

� Discards received UMD PDUs that cannot be re-assembled into a RLC SDU due to loss

at lower layers of an UMD PDU which belonged to the particular RLC SDU.

RLC Re-establishment

At the time of RLC re-establishment, the receiving UM RLC entity, if possible, reassembles

RLC SDUs from the UMD PDUs that are received out of sequence and delivers them to upper

layer. In addition, it discards any remaining UMD PDUs that could not be reassembled into

RLC SDUs.

6.2.3 Acknowledged Mode

The AM (Acknowledged Mode) of RLC, as its name suggests, provides functions that are

needed to support acknowledged data transfer. These include:

� Segmentation and reassembly.

� Concatenation.

� Error correction.

� In-sequence delivery of higher layer data.

� Duplicate detection.

Reliability in Acknowledged Mode is achieved through the use of selective retransmission.

This involves the transmitter sending a number of AMD (Acknowledged Mode Data) PDUs

and then the receiving entity positively acknowledging all or some of them.

Figure 6-4 illustrates the AM-RLC entity in the UE and eNB. The process begins with the

RLC data PDUs being formatted and then being sent from the transmitter buffer. On receipt of

a number of PDUs, the receiving entity will send a status report back to the transmitter. This

indicates whether the previous PDUs have been received correctly or not. The sender, based

on this information, retransmits the erroneous PDUs. The transmitting side may also include a

polling request in the RLC header which forces a status report from the receiving side.

An AM RLC entity can be configured to deliver/receive RLC PDUs through the DCCH and

DTCH logical channel.




Issue 06 (2006-03-01)

Figure 6-4 Acknowledged Mode RLC

Transmission Buffer

AM-RLC Entity

Retransmission Buffer

Add RLC Header

SDU Reassembly

Remove RLC Header

Reception Buffer &

HARQ Reordering

Routing

RLC Control

Segmentation and

Concatenation

DCCH/DTCH DCCH/DTCH

RLC PDUs

The RLC protocol defines two main categories of PDU, these are:

� Data.

� Control.

Table 6-1 identifies the different PDU types that are available.

Table 6-1 RLC PDU Formats

Data Transfer Mode PDU Name

Transparent TMD

Unacknowledged UMD

Acknowledged AMD

AMD Segment

Status

6.2.4 TMD PDU

The TMD (Transparent Mode Data) PDU carries user data when RLC is operating in

Transparent Mode. In this mode, no overhead (i.e. no header) is added.




6-71

6.2.5 UMD PDU

The UMD (Unacknowledged Mode Data) PDUs are used for unacknowledged data transfer,

conveying sequentially numbered PDUs. Unlike UMTS, there are a number of UMD PDU

formats. These are typically in two categories:

� 5bit RLC sequence number.

� 10bit RLC sequence number.

With each of these categories there are three PDU formats defined, making a total of six

different formats. These include:

� No LI (Length Indicator).

� Odd number of Length Indicators.

� Even number of Length Indicators.

5bit and 10bit UMD PDU with No Length Indicator

The RLC specification details the different PDU formats. Figure 6-5 illustrates the 5bit SN

(Sequence Number) format when no length indicators are present.

Figure 6-5 RLC UMD 5bit SN (No Length Indicators)

Figure 6-6 illustrates the 10bit SN UMD format with no length indicators.

Figure 6-6 RLC UMD 10bit SN (No Length Indicators)

The FI (Frame Information) field has four possible values and is used for various

permutations of segmentation and concatenation. The different permutations are illustrated in

Table 6-2.




Issue 06 (2006-03-01)

Table 6-2 FI Field Interpretation

Value Description

00 First byte of the Data field corresponds to the first byte of a RLC SDU.

Last byte of the Data field corresponds to the last byte of a RLC SDU.

01 First byte of the Data field corresponds to the first byte of a RLC SDU.

Last byte of the Data field does not correspond to the last byte of a RLC SDU.

10 First byte of the Data field does not correspond to the first byte of a RLC SDU.

Last byte of the Data field corresponds to the last byte of a RLC SDU.

11 First byte of the Data field does not correspond to the first byte of a RLC SDU.

Last byte of the Data field does not correspond to the last byte of a RLC SDU.

UMD PDU with Length Indicators

Depending on the PDU frame format, there are one or more E (Extension) bits. These are

used to indicate if the header has been extended. If it is set to “1”, it indicates a set of E and LI

(Length Indicator) fields follow. Figure 6-7 illustrates the example of a UMD data PDU with

a 5bit SN and two extensions, i.e. two E/LI sets.

Figure 6-7 RLC UMD with 2 Length Indicators

6.2.6 AMD PDU

The AMD (Acknowledged Mode Data) PDU is used for acknowledged mode data transfer. It

also has different formats for zero, odd or even numbers of E/LI sets. Figure 6-8 illustrates an

AMD PDU with an odd number of length indicators and as such, four padding bits are added.

In addition, AMD used a 10bit sequence number.




6-73

Figure 6-8 RLC AMD with no Length Indicators

The RF bit is used to indicate whether this PDU is an AMD PDU or AMD PDU Segment.

Each AMD PDU also includes a P (Polling) flag, allowing the UE or eNB to request a Status

PDU.

Figure 6-9 RLC AMD with Odd Number of Length Indicators

AMD PDU Segment

The AMD PDU Segment is used to transfer upper layer PDUs by the AM RLC entity. It is

used when the AM RLC entity needs to re-segment an AMD PDU, e.g. when insufficient

resources are available for retransmission.

The RF parameter indicates that it is an AMD PDU Segment. As such, an additional two

octets are added to the header, enabling a LSF (Last Segment Flag) and SO (Segment Offset)

parameters to be added. The latter provides an offset in octets within the original AMD PDU.

This can be used in conjunction with the FI (Frame Information) parameter to identify the first

octet.

Figure 6-10 illustrates an example of the AMD PDU segment header. Like the UMD PDU and

AMD PDU, it also has the ability to include zero, odd or even number of E and LI sets.




Issue 06 (2006-03-01)

Figure 6-10 RLC AMD PDU Segment

The concept of AMD segmentation is illustrated in Figure 6-11. Note that the two segments in

this example will both carry the original RLC SN. In addition, if the AMD Segment is

unsuccessfully received, they system may re-segment the data again, i.e. AMD segment and

be re-segmented may times.

Figure 6-11 AMD Segmentation

Data AMD

AMD Segment

DataDataAMD

Segment

Segment Offset x

Segment Offset xLSF=1

Segment Offset 0LSF=0

Status PDU

An AM RLC entity sends Status PDUs to its peer AM RLC entity in order to provide positive

and/or negative acknowledgements of RLC PDUs (or portions of them). It is the

responsibility of RRC to invoke the status prohibit in the AM RLC entity when necessary.

This takes the form of a timer to prevent the receiver from sending Status PDUs.

The transmitting side of an AM RLC entity can receive a negative acknowledgement

(notification of reception failure by its peer AM RLC entity) for an AMD PDU or a portion of

an AMD PDU by the following:

� Status PDU from its peer AM RLC entity.

� HARQ delivery failure from the transmitting MAC entity.

Triggers to initiate STATUS reporting include:

� Polling from its peer AM RLC entity.

� Detection of reception failure of an RLC data PDU.




6-75

Figure 6-12 RLC Status PDU

6.2.7 RLC Timers

The following timers are configured by RRC:

� t-PollRetransmit - this timer is used by the transmitting side of an AM RLC entity in

order to retransmit a poll.

� t-Reordering - this timer is used by the receiving side of an AM RLC entity and receiving

UM RLC entity in order to detect loss of RLC PDUs at lower layer.

� t-StatusProhibit - this timer is used by the receiving side of an AM RLC entity in order to

prohibit transmission of a STATUS PDU.

6.2.8 Configurable Parameters

The following parameters are configured by RRC:

� maxRetxThreshold - this parameter is used by the transmitting side of each AM RLC

entity to limit the number of retransmissions of an AMD PDU.

� pollPDU - this parameter is used by the transmitting side of each AM RLC entity to

trigger a poll for every pollPDU PDUs.

� pollByte - this parameter is used by the transmitting side of each AM RLC entity to

trigger a poll for every pollByte bytes.

� sn-FieldLength - this parameter gives the UM SN field size in bits.

6.3 MAC Functions

As mentioned in Section 2.2.9 MAC (Medium Access Control) provides the interface between

the E-UTRA protocols and the E-UTRA Physical Layer. In so doing, it provides the following

services:

� Mapping - MAC maps the information received on the LTE logical channels into the

LTE transport channels.




Issue 06 (2006-03-01)

� Multiplexing - RLC frames belonging to a Radio Bearer or different bearers may be

multiplexed in the same TB (Transport Block).

� HARQ (Hybrid Automatic Repeat Request) - MAC may invoke HARQ in order to

provide error correction services across the air.

� Radio Resource Allocation - QoS (Quality of Service) based scheduling of traffic to

multiple users, or multiple flows to the same user, is invoked at the MAC layer.

� Formatting - transport formatting and padding is invoked to optimize the radio link

within the cell.

Services Expected from the Physical Layer

The Physical Layer provides the following services to MAC:

� Data transfer services.

� Signaling of HARQ feedback.

� Signaling of Scheduling Request.

� Measurements, e.g. CQI (Channel Quality Indication).

The access to the data transfer services is through the use of transport channels. The

characteristics of a transport channel are defined by its transport format (or format set),

specifying the Physical Layer processing to be applied to the transport channel in question,

such as channel coding and interleaving, and any service-specific rate matching as needed

6.4 MAC Architecture

Compared to UMTS, which includes various MAC structures for different channel

configurations, the LTE structure is quite simple. Figure 6-13 illustrates where some of the

MAC functions reside.

Figure 6-13 MAC Structure (UE Side)




6-77

6.5 MAC Formatting

6.5.1 MAC Headers

There are various MAC headers depending on whether it is being used for shared channel

operation or RAR (Random Access Response).

MAC PDU for DL-SCH and UL-SCH

Figure 6-14 illustrates the different MAC subheaders which can be used for the DL-SCH and

UL-SCH. Note that the 15bit format is used if the payload is greater the 127 octets.

Figure 6-14 MAC Header

The main parameter is the LCID (Logical Channel Identifier), which is coded differently for

the DL-SCH and UL-SCH. Table 6-3 illustrates the DL-SCH coding.

Table 6-3 LCID Coding for DL-SCH

LCID Index Description

00000 CCCH

00001-01010 Identity of the logical channel

01011-11011 Reserved

11100 UE Contention Resolution Identity

11101 Timing Advance Command

11110 DRX Command

11111 Padding




Issue 06 (2006-03-01)

The LCID coding for the UL-SCH is illustrates in Table 6-4.

Table 6-4 LCID Coding for UL-SCH

LCID Index Description

00000 CCCH

00001-01010 Identity of the logical channel

01011-11001 Reserved

11010 Power Headroom Report

11011 C-RNTI

11100 Truncated BSR

11101 Short BSR

11110 Long BSR

11111 Padding

6.5.2 MAC Subheaders

Multiplexing Subheaders

A number of LCIDs can be multiplexed into a single transmission. Figure 6-15 illustrates how

multiple MAC headers, i.e. subheaders are concatenated together. This enables the

multiplexing of different LCIDs, such as multiple Radio Bearers, as well as MAC control

LCIDs like TA (Timing Advance).

Figure 6-15 MAC Subheaders

Timing Advance

Section 6.5.3 examines the RA (Random Access) process and the RAR (Random Access

Response). This provides the UE with an initial 11bit TA (Timing Advance) command.




6-79

In other cases, a 6bit Timing Advance command is used. The LCID indicating Timing

Advance relates to this 6bit variant. Figure 6-16 illustrates this fixed length TA parameter i.e.

there is no length indicator in the MAC subheader.

Figure 6-16 Timing Advance Parameter

Since this field is not 11bits it does not indicate the absolute TA value, instead it indicates

adjustment of the current NTA value, NTA,old, to the new NTA value, NTA,new, by index values of

TA = 0, 1, 2,..., 63, where NTA,new = NTA,old + (TA −31)×16. Here, adjustment of the NTA value

by a positive or a negative amount indicates advancing or delaying the uplink transmission

timing the indicated amount. A TA=31 would result in no change to the timing.

Buffer Status Report

BSR (Buffer Status Report) MAC control elements consist of either:

� Short BSR and Truncated BSR format - this indicates one LCG ID (Logical Channel

Group Identity) field and the corresponding Buffer Size field.

� Long BSR format - this indicates four Buffer Size fields, corresponding to LCG IDs #0

through #3.

The BSR formats are identified by MAC PDU subheaders. The fields LCG ID and Buffer

Size are defined as :

� LCG ID - this is the Logical Channel Group Identity of a group of logical channel(s)

whose buffer status is being reported. The length of the field is 2 bits, i.e. 4 groups are

possible.

� Buffer Size - the Buffer Size field identifies the total amount of data available across all

logical channels of a logical channel group after the MAC PDU has been built. The

amount of data is indicated in bytes. It also includes all data that is available for

transmission in the RLC and PDCP layers.

The Short BSR and Truncated BSR control element is illustrates in Figure 6-17. The

Truncated BSR indicates the buffer size for the highest priority LCG ID, however it implies

that other LCG IDs also have data in the buffer.

Figure 6-17 Short BSR and Truncated BSR MAC Control Element

The Long BSR control element is able to provide the status of all four LCG IDs.

Figure 6-18 Long BSR MAC Control Element




Issue 06 (2006-03-01)

DRX Command

The DRX (Discontinuous Reception) Command LCID has no payload, i.e. only the subheader

is sent. Upon receiving the DRX command in the downlink the UE activates either a Short

DRX Cycle or a Long DRX cycle (depending on RRC based configuration).

Power Headroom Report

The PHR (Power Headroom Report) is configured by RRC, indicating timers and PL

(Pathloss) thresholds to use. For example, if a periodic timer expires or the pathloss changes

by 3dBs the UE is required to inform the eNB.

Figure 6-19 Power Control Headroom

If the criteria to send a PHR have been met, the UE includes the appropriate LCID subheader.

Figure 6-20 illustrates the PH (Power Headroom) control element.

Figure 6-20 Power Headroom Control Element

Table 6-5 illustrates part of the mapping from the PH value to the actual measured value.

Table 6-5 Power Headroom Report Mapping

PH Reported value Measured Quantity Value (dB)

0 POWER_HEADROOM_0 -23 ≤ PH < -22




…. …. ….

62 POWER_HEADROOM_62 39 ≤ PH < 40

63 POWER_HEADROOM_63 PH ≥ 40




6-81

6.5.3 Random Access Process

The SRB is also termed the “RRC Connection”, i.e. the UE has moved into the

RRC-Connected State. In order to achieve this state signaling between the eNB and the UE is

required. Figure 6-21 illustrates the main signaling messages to establish a SRB. It is initiated

by the UE sending a Random Access Preamble on the RACH.

Figure 6-21 Random Access RRC Signaling Procedure

Random Access Response

On receiving the preamble, the eNB sends a RAR (Random Access Response) on the

DL-SCH. This is addressed to the RA-RNTI on the PDCCH (Physical Downlink Control

Channel). It includes the RAPID (Random Access Preamble Identifier), TA (Timing

Alignment) information, initial UL grant and assignment of a Temporary C-RNTI.




Issue 06 (2006-03-01)

Figure 6-22 Random Access Response

The contents of the 20bit UL (Uplink) Grant is illustrates in Table 6-6.

Table 6-6 Uplink Grant

Parameter Size (bits)

Description

Hopping Flag 1 Indicates whether the allocation should be

using uplink hopping.

Fixed Size Resource Block

Assignment

10 The assigned uplink resources.

Truncated Modulation and Coding

Scheme

4 Indication of modulation and coding

scheme to use.

TPC Command for Scheduled

PUSCH

3 Initial power control feedback, e.g. -4dB.

UL Delay 1 Indicates whether uplink assignment is

delayed until the next subframe, e.g.

K+4+1.

CQI Request 1 Indicates whether the UE has been

requested to multiplex the CQI (Channel

Quality Indicator) into the scheduled

PUSCH transmission.

Backoff Indicator

The eNB may also include a BI (Backoff Indicator) in the first MAC subheader. This indicates

a backoff time (0 to 960ms) for non confirmed UEs to implement before trying to re-attempt

access. Figure 6-23 illustrates the location of the Backoff Indicator in the MAC frame.




6-83

Figure 6-23 Backoff Indicator

7 X2/S1 Interface and Protocols LTE Protocols and Procedures



Issue 06 (2006-03-01)

7 X2/S1 Interface and Protocols About This Chapter


Section

7.1 X2AP Functions and

Procedures

7.2 S1AP Functions and

Procedures

7.3 User Plane GTP Functions

and Procedures

LTE Protocols and Procedures 7 X2/S1 Interface and Protocols



7-85

7.1 X2AP Functions and Procedures

The X2 interface links an eNB to its neighbors. It is sub-divided into a Control Plane and User

Plane, these are illustrated in Figure 7-1. The messages required to invoke the X2 interface

services are carried by X2AP (X2 Application Part) in the Control Plane. The User Plane

utilizes the services of GTPv1-U (GPRS Tunneling Protocol Version 1 - User Plane). The

E-UTRAN interfaces use similar terminology to that of UMTS, in that the interfaces are

divided into a RNL (Radio Network Layer) and a TNL (Transport Network Layer). The Radio

Network Layer supports the higher layer functions, incorporating X2AP and the user’s IP

streams.

Figure 7-1 X2 Control and User Plane

The Transport Network Layer Control Plane and User Plane both use the service of IP;

however a reliable robust delivery protocol in the form of SCTP (Stream Control

Transmission Protocol) exists within the Control Plane. In contrast, the User Plane utilizes

GTP-U and the services of the UDP (User Datagram Protocol). Note that an eNB may have

one or multiple IP addresses at the Transport Network Layer for both the Control and User

Planes.

7.1.2 Functions of the X2 Application Protocol

The X2AP has the following functions:

� Mobility Management - this function allows the eNB to move the responsibility of a

certain UE to another eNB. Forwarding of User Plane data, Status Transfer and UE

Context Release function are parts of the mobility management.

� Load Management - this function is used by eNBs to indicate resource status, overload

and traffic load to each other.

� Reporting of General Error Situations - this function allows reporting of general error

situations, for which function specific error messages have not been defined.

� Resetting the X2 - this function is used to reset the X2 interface.

� Setting up the X2 - this function is used to exchange necessary data for the eNB for setup

the X2 interface and implicitly perform an X2 Reset.

� eNB Configuration Update - this function allows updating of application level data

needed for two eNBs to interoperate correctly over the X2 interface.




Issue 06 (2006-03-01)

The X2AP consists of various EP (Elementary Procedures). Table 7-1illustrates the mapping

between the functions provided by the X2 interface and the actual Elementary Procedure(s)

that are used to support this functionality.

Table 7-1 Mapping between X2AP Functions and X2AP EPs

Function Elementary Procedure(s)

Mobility Management a) Handover Preparation.

b) SN Status Transfer.

c) UE Context Release.

d) Handover Cancel.

Load Management a) Load Indication.

b) Resource Status Reporting Initiation.

c) Resource Status Reporting.

Reporting of General Error Situations Error Indication.

Resetting the X2 Reset.

Setting up the X2 X2 Setup.

eNB Configuration Update eNB Configuration Update.

7.1.3 X2 Elementary Procedures

The X2AP consists of various Elementary Procedures. Class 1 procedures, i.e. EPs including

a request and response, are illustrated in Table 7-2.

Table 7-2 Class 1 Elementary Procedures

Elementary Procedure

Initiating Message

Successful Outcome Unsuccessful Outcome

Response message Response message

Handover

Preparation

HANDOVER

REQUEST

HANDOVER

REQUEST

ACKNOWLEDGE

HANDOVER

PREPARATION

FAILURE

Reset RESET REQUEST RESET 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




7-87

The X2AP also supports various Class 2 procedures, i.e. EPs without a response message.

Elementary Procedure 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

The role of the X2 interface may be divided into two main groups. These are:

� X2AP Basic Mobility Procedures - these relate to procedures used to handle the UE

mobility within E-UTRAN.

� X2AP Global Procedures - these relate to procedures that are not related to a specific

UE.

7.1.4 Message Formatting

X2AP messages and S1AP messages consist of individual IE (Information Elements) and

groups of Information Elements that are nested together. Each message must start with the

element defining the “Message Type”. This will be followed by a series of Information

Elements.

Presence

The presence of Information Elements within a message depends on a number of factors

including the scenario in which the message has been invoked. Consequently, Information

Elements may be:

� M (Mandatory) - these IE are always included in the message.

� O (Optional) - these IE may or may not be included in the message.

� C (Conditional) - these IE are included in the message only if the condition is satisfied.

Range

The Range indicates the number of copies of repetitive Information Elements that are allowed

in the message. E.g. there may be three cells configured and each has its associated

parameters.

Criticality

In each protocol message, there is criticality information set for individual and/or groups of IE

that comprise it. This criticality information instructs the receiver how to act when receiving

an IE that is in error or not comprehended. This criticality information may be applied as

follows:

� Null - no criticality information is applied explicitly.




Issue 06 (2006-03-01)

� Yes - criticality information is applied only for non-repeatable IE.

� Global - the Information Element and all its repetitions have common criticality

information.

� Each - each repetition of the Information Element has its own criticality information.

Based on the criticality information, the receiver may take the following action if errors are

encountered in the Information Element:

� Reject.

� Ignore.

� Ignore and Notify.

7.1.5 X2 Basic Mobility Procedures - Handover Preparation

Based on radio resource requirements the source eNB will decide to initiate a handover

procedure with the target eNB. The source eNB initiates the procedure by sending the

Handover Request message to the target eNB. Note that the following messages are also

included in mobility scenarios in Section 8.1 .

Handover Request

The Handover Request message includes the following information:

� Old eNB UE X2AP ID - this provides the X2 signaling association for future messages

between the source and target eNBs.

� Cause - this element indicates to the MME the reason for the handover including reasons

such as the radio network layer, transport network layer etc.

� ECGI - this is the global id of the eNB and is expressed as a PLMN identity plus the

entire 28bit cell identity.

� GUMMEI (Globally Unique MME Identifier) - this is the identity of the MME that is

currently serving the UE.

� UE Context Information - this contains the following information:

− MME UE S1AP ID - this provides the target eNB with the signaling association

reference with the MME across the S1-MME interface for specific UE.

− UE Security Capabilities - this information element defines the UE capabilities in

terms of its RF, E-RAB formats etc. These are typically defined by referencing the

category of the LTE device.

− AS Security Information - the purpose of the Security Context IE is to provide

security related parameters to the eNB. These are used to derive security keys for

User Plane traffic and RRC signaling messages and for security parameter generation

for subsequent X2 or intra eNB handovers.

− UE Aggregate Maximum Bit Rate - this element is used to define the total bandwidth

in Mbit/s that can be allocated to the UE for all E-RABs that are established.

− E-RABs to be Setup List - this identifies the E-RAB ID, E-RAB QoS, GTP

information and RRC Context for each EPS Bearer. The latter provides details on the

current configuration and the implementation of the air interface protocols.

� UE History Information -this is information about cells that a UE has been served by in

the active state prior to the target cell.

� Trace Activation - this O (Optional) parameter is able to start trace procedures on the

Target eNB. In so doing, it indicates which interfaces to trace and where to send the

information.




7-89

� SRVCC Operation Possible - this indicates to the target eNB whether SRVCC (Single

Radio Voice Call Continuity) is available, i.e. the UE can be handed over from the

E-UTRAN to CS (Circuit Switched) 2G/3G systems.

Figure 7-2 X2 Handover Request

Handover Request Acknowledge

The allocation of E-RAB resources will be based on those received in the Handover Request

procedure. Note that if conflicts occur the target eNB can utilize the ARP (Allocation and

Retention Priority) parameter (part of the E-RAB QoS) to help resolve the issue. In so doing,

the target eNB admits the E-RABs and sends the Handover Request Acknowledge message

back to the source eNB. The message contains the following information:

� Old eNB UE X2AP ID - this is the X2 signaling association of the source eNB.

� New eNB UE X2AP ID - this is the X2 signaling association of the target eNB.

� E-RABs Admitted List - this details the list of E-RAB(s) that have been admitted based

on the resources available in the target eNB.




Issue 06 (2006-03-01)

� E-RABs Not Admitted List - this identifies the E-RAB(s) which are not admitted.

� Target eNB To Source eNB Transparent Container- this includes handover information

for the UE. This, in essence, is an RRC Connection Reconfiguration message defining

the lower layer configuration on the new cell.

� Criticality Diagnostics - this is sent by the eNB when parts of a received message have

not been comprehended or were missing, or if the message contained logical errors.

When applicable, it contains information about which parameters were not

comprehended or were missing.

Handover Preparation Failure

There are a number of reasons why the Handover Preparation Failure message may be sent,

typical examples include:

� If the target eNB does not admit at least one non-GBR E-RAB.

� The target eNB receives a Handover Request message and the RRC Context parameter

does not include required information.

� A failure occurs during the Handover Preparation.

In these instances, the target eNB sends the Handover Preparation Failure message to the

source eNB with the appropriate cause parameter indicated.

Figure 7-3 X2 Handover Preparation Failure

SN Status Transfer

The SN Status Transfer procedure is used to transfer the uplink and downlink PDCP (Packet

Data Convergence Protocol) SN (Sequence Number) and HFN (Hyper Frame Number) status

from the source eNB to the target eNB during an X2 handover for each respective E-RAB for

which PDCP SN and HFN status preservation applies. These E-RAB(s) are identified in the

handover preparation phase based on the RRC Context parameters in the Handover Request.




7-91

Figure 7-4 X2 SN Status Transfer

The source eNB initiates the SN Status Transfer procedure. In so doing, it stops the

assignment of PDCP SNs to downlink SDUs and stops delivering uplink SDUs towards the

EPC (Evolved Packet Core). Finally it sends the SN Status Transfer message to the target

eNB.

For E-RAB that have had forwarding preservation agreed the source eNB forwards the uplink

packets to the target eNB and routes downlink packets to the target eNB that will assign its

own sequence numbers to the packets based on the value of the PDCP DL Count received

from the target eNB.

The information in the SN Status Transfer message includes:

� Old eNB UE X2AP ID - this is the X2 signaling association of the source eNB.

� New eNB UE X2AP ID - this is the X2 signaling association of the target eNB.

� E-RABs Subject to Transfer - this lists the E-RAB that have been identified to have

forwarding applied based on their QoS. Each E-RAB will have the following parameters

detailed for them:

− Receive Status of UL PDCP SDUs - this optional parameter provides a bit map of

missing PDCP Sequence Numbers.

− UL Count Value - this is the PDCP-SN and HFN of the next uplink SDU (Service

Data Unit) to be forwarded to the EPC.

− DL Count Value - this is the PDCP-SN and HFN of the first downlink SDU to be

formatted into a PDCP SU for delivery to the UE.

UE Context Release

The UE Context Release message is sent once a handover has been successfully completed

and enables the source eNB to release all resources associated with the UE.




Issue 06 (2006-03-01)

Figure 7-5 X2 UE Context Release

Handover Cancel

The Handover Cancel message is sent from the source eNB to the target eNB to cancel a

handover that is currently in progress.

Figure 7-6 X2 Handover Cancel

7.1.6 X2 Load Indication

The Load Indication message transfers load and interference coordination information

between neighboring eNBs that are operating on the same carrier frequency. It enables an

eNB to indicate the interference it is experiencing on particular PRB (Physical Resource

Block) and the sensitivity to interference for each PRB.

The message contains the following information:

� Cell ID - this indicates the cell to which the report relates.

� UL Interference Load Indication - this is used to report to a neighbor eNB that specific

PRBs are experiencing interference. This may be defined as high, medium or low. PRB

are listed with PRB 0 being the first in the list, PRB 1 is the second and so on.

� UL High Interference Indication - this message indicates the sensitivity of PRB to

interference. A bit map is used, with a 0 indicating low sensitivity and 1 indicating high

sensitivity.

� RNTP (Relative Narrowband Tx Power) - this indicates, per PRB, whether downlink

transmission power is lower than the value indicated by the RNTP threshold. The

receiving eNB may take such information into account when setting its scheduling policy

and can consider the received RNTP value valid until reception of a new Load

Information message carrying an update.




7-93

Figure 7-7 X2 Load Indication

Figure 7-8 illustrates how two of the Load Indication message parameters can be set to

indicate the uplink overload and interference requirements on an eNB.

Figure 7-8 X2 Uplink Interference

Medium Medium Medium High High

PRB 0 PRB 1 PRB 2 PRB 3 PRB 4

Low

PRB 5

0 1 1 0 0 0

UL High Interference Information (bitmap)

UL Interference Overload Indication

The Load Indication message also provides the Relative Narrowband Tx Power bitmap and

associated parameters. This effectively indicates to neighboring cells the power levels

transmitted per PRB.

Figure 7-9 Downlink RNTP




Issue 06 (2006-03-01)

7.1.7 X2 Resource Status Reporting

Closely associated with load reporting is resource status reporting, this is used by an eNB to

request updated information regarding load information etc from its neighbors.

Resource Status Request

The Resource Status Request message is sent from one eNB to its neighbor. It is used to

register (start) measurement reports or to deregister (stop) these reports. It is also used to

request the periodicy of reports and to specify the specific cells on which reports are required.

Figure 7-10 X2 Resource Status Request

Resource Status Request

Resource Status Response

eNB1 Measurement ID

eNB2 Measurement IDCriticality Diagnostics (O)

eNB1 Measurement IDeNB2 Measurement ID (C) - If Registration Stop

Registration Request - Start or StopReport Characteristics (O)

Cell To ReportReporting Periodicity (O)

The Reported Characteristics parameter is used to indicate: PRB Periodic, TNL load

Indication Periodic or HW Load Indication Periodic.

Resource Status Response

The Resource Status Response message indicates if the request can be performed. Subsequent

messages are then sent in Resource Status Update messages.

Resource Status Failure

The Resource Status Failure message is sent when requested measurements cannot be

initiated.

Resource Status Update

The Resource Status Update message is used to send the requested results. It includes the

requested report.




7-95

Figure 7-11 X2 Resource Status Update

7.1.8 X2 Setup

The purpose of the X2 Setup procedure is to exchange application level configuration data

needed for two eNBs to interoperate correctly over the X2 interface. This procedure erases

any existing application level configuration data in the two nodes and replaces it by the one

received. This procedure also resets the X2 interface in a similar fashion to a Reset procedure.

X2 Setup Request

The X2 Setup Request message includes:

� Global eNB ID - this is the global id of the eNB and is expressed as the first 20bits of the

cell ID in the case of a macro eNB and for a home eNB it is the entire 28bit cell identity.

� Served Cells - this contains a list of the cells supported by the eNB. For each cell the

following information is provided:

− ECGI (E-UTRAN Cell Global Identifier).

− PCI (Physical Cell Identifier).

− EARFCN (E-UTRA Absolute Radio Frequency Channel Number).

− TAC (Tracking Area Code).

− Broadcast PLMNs - including FDD and TDD configuration.

− Neighbor Cells - including ECGI, PCI and EARFCN.

� GU Group ID (Globally Unique Group Identifier) - this is all the pools to which the eNB

belongs to.




Issue 06 (2006-03-01)

Figure 7-12 X2 Setup Request

X2 Setup Request

X2 Setup Response

Global eNB IDServed Cells- Served Cell Information

- Neighbor Information-- ECGI-- PCI-- EARFCN

GU Group Id List (C)Criticality Diagnostics

Global eNB IDServed Cells- Served Cell Information

- Neighbor Information-- ECGI-- PCI

-- EARFCNGU Group Id List (C)

X2 Setup Response

The X2 Setup Response message simply reflects the information included in the request but

this time the values are associated with the neighbor that received the request message.

7.1.9 X2 eNB Configuration

The purpose of the eNB Configuration Update procedure is to update application level

configuration data needed for two eNBs to interoperate correctly over the X2 interface.

eNB Configuration Update

The eNB Configuration Update includes updates and modification to the eNB configuration.

eNB Configuration Update Acknowledge

The eNB Configuration Update Acknowledge message is returned to indicate to the sending

eNB that the necessary updates have been completed in the target eNB.




7-97

Figure 7-13 eNB Configuration Update

eNB Configuration Update Failure

If the eNB cannot accept the update it responds with an eNB Configuration Update Failure

message and the appropriate cause value. If the message includes the Time To Wait parameter

the eNB waits at least for the indicated time before reinitiating the eNB Configuration Update

procedure towards the same eNB. Both eNBs continue to communicate on the X2 interface

with their existing configuration data.

7.2 S1AP Functions and Procedures

The S1AP, which resides on the S1-MME interface within the E-UTRAN, uses the concept of

an EP (Elementary Procedure). These interactions comprise of a series of protocol messages

which in turn consist of one or more IE (Information Element). Like the X2 interface, the S1

interface can be split into a RNL (Radio Network Layer) and TNL (Transport network Layer).

Figure 7-14 illustrates this split, as well as the associated protocols.




Issue 06 (2006-03-01)

Figure 7-14 S1 Control and User Plane

7.2.1 S1AP Functions

S1AP is defined as being able to perform the following functions:

� E-RAB Management - this overall functionality is responsible for setting up, modifying

and releasing E-RABs, which are triggered by the MME. Note that the release of

E-RABs may be triggered by the eNB as well.

� Initial Context Transfer - this is used to establish an S1 UE context in the eNB, to setup

the default IP connectivity, to setup one or more E-RAB(s) if requested by the MME, as

well as to transfer NAS (Non Access Stratum) signaling related information to the eNB if

needed.

� UE Capability Information Indication - this functionality is used to provide the UE

Capability Information when received from the UE to the MME.

� Mobility - this function is for UEs in LTE_ACTIVE in order to enable:

− a change of eNBs within the SAE/LTE (Inter MME/Serving SAE-GW Handovers)

via the S1 interface (within EPC involvement).

− a change of RAN nodes between different RATs (Inter-3GPP-RAT Handovers) via

the S1 interface (with EPC involvement).

� Paging - this functionality provides the EPC with the capability to page the UE.

� S1 Interface Management - this function comprise of the:

− Reset functionality - this ensures a well defined initialization on the S1 interface.

− Error Indication - this is to allow proper error reporting/handling in cases where no

failure messages are defined.

− Overload - this is used to indicate the load situation in the Control Plane of the S1

interface.

− Load balancing -this is used to ensure equally loaded MMEs within an MME pool

area.

− S1 Setup - this is used for initial S1 interface setup for providing configuration

information.

− eNB and MME Configuration Update - these are used to update application level

configuration data needed for the eNB and MME to interoperate correctly on the S1

interface.

� NAS Signaling Transport - this is between the UE and the MME and is used to:




7-99

− transfer NAS signaling related information and to establish the S1 UE context in the

eNB.

− transfer NAS signaling related information when the S1 UE context in the eNB is

already established.

� S1 UE Context Release - this functionality manages the release of UE specific contexts

in the eNB and the MME.

� UE Context Modification - this functionality allows the partial modification of the

established UE Context.

� Status Transfer - this functionality transfers PDCP SN Status information from the

source eNB to target eNB in support of in-sequence delivery and duplication avoidance

for intra LTE handover.

� Trace - this functionality is to control a trace recording for a UE in

ECM_CONNECTED.

� Location Reporting - this functionality allows MME to be aware of the UEs current

location.

� S1 CDMA2000 Tunneling - this functionality is to carry CDMA2000 signaling between

the UE and CDMA2000 RAT over the S1 interface.

� Warning Message Transmission - this functionality provides the means to start and

overwrite the broadcasting of warning messages.

� RIM (RAN Information Management) - this functionality allows the request and transfer

of RAN system information (e.g. GERAN system information) between two RAN nodes

via the core network.

� Configuration Transfer - this functionality allows the request and transfer of RAN

configuration information (e.g. SON information) between two RAN nodes via the core

network.

7.2.2 S1AP Elementary Procedures

The S1AP, like X2AP, consists of different classes of procedures, namely Class 1 (with

response) and Class 2 (without response). Table 7-3 illustrates the Class 1 S1AP Procedures

and associated messages.

Table 7-3 S1AP Class 1 Elementary Procedures

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




Issue 06 (2006-03-01)

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

INITIAL

CONTEXT SETUP

FAILURE

Reset RESET RESET

ACKNOWLEDGE

S1 Setup S1 SETUP

REQUEST

S1 SETUP

RESPONSE

S1 SETUP

FAILURE

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

CONFIGURATION

UPDATE

ACKNOWLEDGE

MME

CONFIGURATION

UPDATE FAILURE

Write-Replace

Warning

WRITE-REPLACE

WARNING

REQUEST

WRITE-REPLACE

WARNING

RESPONSE

The S1AP also include various Class 2 procedures which are always considered to be

successful and therefore do not require a response.

Table 7-4 S1AP Class 2 Elementary Procedures

Elementary Procedure Message

Handover Notification HANDOVER NOTIFY

E-RAB Release Indication E-RAB RELEASE INDICATION




7-101

Paging PAGING

Initial UE Message INITIAL UE MESSAGE

Downlink NAS Transport DOWNLINK NAS TRANSPORT

Uplink NAS Transport UPLINK NAS TRANSPORT

NAS non delivery indication NAS NON DELIVERY INDICATION

Error Indication ERROR INDICATION

UE Context Release Request UE CONTEXT RELEASE REQUEST

DownlinkS1 CDMA2000 Tunneling DOWNLINK S1 CDMA2000 TUNNELING

Uplink S1 CDMA2000 Tunneling UPLINK S1 CDMA2000 TUNNELING

UE Capability Info Indication UE CAPABILITY INFO INDICATION

eNB Status Transfer eNB STATUS TRANSFER

MME Status Transfer MME STATUS TRANSFER

Deactivate Trace DEACTIVATE TRACE

Trace Start TRACE START

Trace Failure Indication TRACE FAILURE INDICATION

Location Reporting Control LOCATION REPORTING CONTROL

Location Reporting Failure

Indication

LOCATION REPORTING FAILURE

INDICATION

Location Report LOCATION REPORT

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

7.2.3 S1 Setup

The S1 Setup procedure is used to exchange configured data which is required in the MME

and in the eNB respectively to ensure a proper interoperation. The S1 Setup procedure is

triggered by the eNB and is the first S1AP procedure which will be executed. Figure 7-15

illustrates the S1 Setup Request parameters.




Issue 06 (2006-03-01)

Figure 7-15 S1 Setup Request

The eNB informs the MME of its Global eNB Identity, supported TA (Tracking Areas),

Broadcasted PLMN(s) and CSG information, as well as Default Paging DRX information.

In response to the S1 Setup Request messages the MME sends a S1 Setup Response. This

includes the served GUMMEI(s) and relative MME capacity. In addition, this message can

also include a MME name, e.g. “Primary MME”.

Figure 7-16 S1 Setup Response




7-103

7.2.4 eNB and MME Configuration Update

Both the eNB and MME can also send a configuration update message to update information

previously sent in the S1 Setup procedure. These messages carry similar information to the S1

Setup Request and S1 Setup Response messages.

7.2.5 NAS Transport

The role of NAS transport is to transparently move messages between the UE and the MME

that have no relevance to the eNB. The procedures providing this functionality are the Initial

UE Message, Uplink NAS Transport, Downlink NAS Transport, Downlink NAS Non

Delivery Indication.

Initial UE Message

When the eNB has received, from the radio interface, the first Uplink NAS message

transmitted on an RRC connection to be forwarded to an MME, the eNB invokes the NAS

Transport procedure and sends the Initial UE Message to the MME including the NAS

message as a NAS-PDU. Note that the first Uplink NAS message is always received in the

RRC Connection Setup Complete message.

The Initial UE Message contains the following information:

� eNB - UE S1AP ID - the eNB allocates a unique eNB UE S1AP ID to be used for the UE

and this identifies the UE association over the S1 interface.

� NAS PDU - this contains the NAS message, e.g. EMM Attach with PDN Connectivity

Request.

� TAI - this contains the PLMN Code and TA Code of the TA in which the UE has sent the

NAS message.

� E-UTRAN CGI - contains the cell identify from which the UE has sent the NAS

message.

� S-TMSI - this is the identity of the UE and is sent to the MME if it was received on the

air interface.

� CSG ID - this identifies the CSG (Closed Subscriber Group).

� RRC Establishment Cause - indicates to the MME the reason for RRC connection

establishment.

� GUMMEI - conveys the Globally Unique MME Identity.




Issue 06 (2006-03-01)

Figure 7-17 S1 Initial UE Message

Downlink and Uplink NAS Transport

Subsequent NAS signaling between the UE and MME can be carried by various S1 signaling

messages, such as Downlink NAS Transport and Uplink NAS Transport. However, other

S1AP messages can also carry NAS signaling, these include the Initial Context Setup

Request, E-RAB Setup, E-RAB Modification and E-RAB Release messages. Figure 7-18

illustrates the Downlink and Uplink NAS transport messages, as well as their contents. It is

worth noting that these messages are independent of each other.

Figure 7-18 S1 Downlink and Uplink NAS Transport

The Downlink NAS Transport message contains the identifiers referencing the UE, the

NAS-PDU and a possible Handover Restriction List. The latter is used to update the eNB on

roaming area or access restrictions.

The Uplink NAS Transport message is similar, however the current E-UTRAN CGI and TAI

are added.




7-105

NAS Non Delivery Indication

If a eNB decides not to start the delivery of a NAS message or the eNB is unable to ensure

that the message has been received by the UE, it sends a NAS Non Delivery Indication

message to the MME. This includes the non-delivered NAS message and an appropriate cause

value e.g. "S1 intra system Handover Triggered", "S1 inter system Handover Triggered" or

"X2 Handover Triggered". Note that the X2 interface cannot carry or forward NAS PDUs as

part of the handover.

7.2.6 Initial Context Setup

The Initial Context Setup message is used to pass the relevant information in order to

establish the UEs context. Figure 7-19 illustrates the parameters in the Initial Context Setup

Request message. In addition to the MME UE S1AP ID and eNB UE S1AP ID association

identifiers, the other parameters include:

� UE Aggregate Maximum Bit Rate - this indicates to the eNB the total aggregate data rate

assigned to the UE.

� RAB to be Setup List - this includes the E-RAB context information. Each E-RAB

includes an E-RAB ID, QoS parameters and User Plane tunnel information, i.e. an IP

address and TEID (Tunnel Endpoint Identifier).

� UE Security Capabilities - this indicates the security algorithms supported by the UE.

� Security Key - the purpose of the Security Key IE is to provide security related

parameters to the eNB.

� Trace Activation - this optional parameter is able to setup RRC, X2 and S1AP tracing for

a UE.

� Handover Restriction List - this optional parameter is used to update the eNB on roaming

area or access restrictions.

� UE Radio Capability - this optional parameter provides the eNB with initial UE radio

capability.

� Subscriber Profile ID for RAT/Frequency Priority - this optional parameter is used to

define camp priorities in Idle Mode and to control inter-RAT/inter-frequency handover in

Active Mode.

� CS Fallback Indicator - this optional parameter indicates that a fallback to the CS domain

is needed.

� SRVCC Operation Possible - this optional parameter indicates if SRVCC is possible.




Issue 06 (2006-03-01)

Figure 7-19 S1 Initial Context Setup Request

Initial Context Setup Response

The eNB sends the Initial Context Setup Response message back to the MME indicating the

E-RABs setup or failed. In addition, for each E-RAB established the eNB provides User Plane

tunnel information in the form of a Transport Layer Address and TEID.

Finally, a Criticality Diagnostics parameter may be included if parts of a received message

have not been comprehended or were missing.




7-107

Figure 7-20 Initial Context Setup Response

Initial Context Setup Failure

If the eNB is not able to establish an S1 UE context, or cannot even establish one non GBR

bearer it considers the procedure to have failed and replies with the Initial Context Setup

Failure message. This includes a cause and optionally the criticality diagnostics parameter.

UE Context Modification

The purpose of the UE Context Modification procedure is to modify the established UE

Context. It enables the MME to modify the:

� Security Key.

� Subscriber Profile ID for RAT/Frequency priority.

� UE Aggregate Maximum Bit Rate.

� CS Fallback Indicator.

7.2.7 E-RAB Establishment

The E-RAB Setup procedure is used to setup UE resources, i.e. additional EPS Bearers.

Figure 7-21 illustrates the key parameters. Note that these are identical to the ones used in the

Initial Context Setup Request and Response messages, i.e. involves interaction between MME

and S-GW.




Issue 06 (2006-03-01)

Figure 7-21 S1 E-RAB Setup Request

Figure 7-22 illustrates the E-RAB Setup Response message and the eNB E-RAB address

parameters for downlink data delivery.

Figure 7-22 S1 E-RAB Setup Response

E-RAB Modification Request and Response

This message is sent due to the requirement to modify the E-RAB, i.e. a change to the QoS or

the TFT (Traffic Flow Template) filters. The E-RAB modification message is almost identical

to the E-RAB Setup however it does not include the User Plane Tunnel information (since it

already exists). The main parameters are the E-RAB QoS and the associated NAS signaling.




7-109

E-RAB Release Command and Response

Assuming that one or more EPS Bearer needs to be released (not all) the MME can sent a

E-RAB Release Command message to the eNB. This includes the E-RAB ID and optionally

associated NAS signaling.

E-RAB Release Indication

The eNB is able to trigger the releasing of one or more E-RAB(s) belonging to a UE. This is

achieved using the E-RAB Release Indication message which includes the E-RAB ID(s).

Figure 7-23 E-RAB Release Indication

If the eNB wants to remove all remaining E-RABs e.g. for user inactivity, the UE Context Release

Request procedure is used instead.

7.2.8 S1 Handover

The E-UTRAN supports multiple scenarios for handover, for example intra MME, inter

MME, inter S-GW, inter RAT, etc. For these different scenarios typically the same message

set is used, however the information elements within the messages may be different. A

handover involves three phases:

� Handover preparation.

� Handover resource allocation.

� Handover notification.

Correlation of S1AP handover messages is examined in Section 8.2 .

Figure 7-24 illustrates a scenario resulting in an intra MME handover with possible S-GW

change.




Issue 06 (2006-03-01)

Figure 7-24 Requirement for S1 Handover Procedures

Handover Preparation Phase - Handover Request

The purpose of the Handover Preparation procedure is to request the preparation of resources

at the target side via the EPC. The source eNB initiates the handover preparation by sending

the Handover Required message to the serving MME. Figure 7-25 illustrates the S1AP

Handover Required message.




7-111

Figure 7-25 S1 Handover Required

The message contains the following information elements:

� MME UE S1AP ID - this is used to associate signaling relating to a specific UE on the

S1 interface at the MME.

� eNB UE S1AP ID - this is used to associate signaling relating to a specific UE on the S1

interface at the eNB.

� Handover Type - this defines the type of handover that is required. These include:

− Intra LTE.

− LTE to UTRAN.

− LTE to GERAN.

� Cause - this element indicates to the MME the reason for the handover including reasons

with the radio network layer, transport network layer, NAS and protocol.

� Target ID - for intra LTE mobility this is the Global eNB ID and is expressed as the first

20bits of the cell ID in the case of macro eNB and for Home eNB it is the entire 28bit

cell identity. For inter-RAT mobility this parameter relates to the target cell, e.g. the CGI

(Cell Global Identifier).

� Direct Forwarding Path Availability - this indicates to the MME if traffic can be

forwarded directly from the source to the target eNB or if it must be routed through the

EPC.

� SRVCC HO Indication - this indicates that SRVCC (Single Radio Voice Call Continuity)

procedures need to be supported as part of this handover. SRVCC is the architecture

defined to ensure call continuity between IMS, over PS access, and CS access for calls

that are anchored in the IMS when the UE is capable of transmitting/receiving on only

one of those access networks at a given time.




Issue 06 (2006-03-01)

� Source to Target Transparent Container - this element contains the transparent container

which includes radio related information that must be passed between the source and

target eNB through the EPC. Note that depending on the mobility scenarios it could

include inter-RAT containers. In addition, when SRVCC is used and the handover is to

GERAN with DTM (Dual Transfer Mode) HO support a “secondary” Source to Target

Transparent Container is sent.

� MS (Mobile Station) Classmark 2 and 3 - these are included as part of a SRVCC

handover to GERAN.

Handover Preparation Phase - Handover Command

The Handover Command message is sent by the MME to indicate to the source eNB that the

handover has been prepared by the target.

Figure 7-26 S1 Handover Command

The Handover Command message includes similar parameters to other S1 messages. In

addition, it includes NAS security parameters when handing over from E-UTRAN to a 3G/2G

system. It also indicates if any of the E-RAB need to be released.

Handover Preparation Phase - Handover Preparation Failure

The Handover Preparation failure message is sent by the MME to inform the source eNB that

the Handover Preparation has failed.




7-113

Handover Resource Allocation Phase - Handover Request

The purpose of Handover Resource Allocation Phase is to identify and reserve resources for

the handover at the target eNB. Figure 7-27 illustrates the Handover Request message. The

parameters are similar to the Initial Context Setup Request message however additional

handover security parameters for interworking are included.

Figure 7-27 S1 Handover Request

The Request Type parameter is part of Location Reporting and is detailed in Section 7.2.14

Handover Resource Allocation Phase - Handover Request Acknowledge

On receiving the Handover Request message from the MME the eNB sends a Handover

Request Acknowledge message.

Figure 7-28 illustrates the Handover Request Acknowledge message. This includes the

admitted E-RAB(s) and associated parameters for handling the User Plane tunnels, namely

eNB Transport Layer Address and GTP-TEID. In addition, it can also include:

� DL Transport Layer Address and DL GTP-TEID - these parameters (optionally) are

passed to the source to indicate where to deliver forwarded downlink PDCP SDUs.

� UL Transport Layer Address and UL GTP-TEID - these parameters (optionally) are

passed to the source to indicate where to deliver forwarded uplink PDCP SDUs.




Issue 06 (2006-03-01)

Figure 7-28 Handover Request Acknowledge

Handover Resource Allocation Phase - Handover Failure

The Handover Failure message is sent by the target eNB to inform the MME that the

preparation of resources has failed. It includes an appropriate cause value.

Handover Notification Phase

The purpose of notification is to inform the MME that the UE has successfully been handed

over to the target eNB. Figure 7-29 illustrates the Handover Notify message and associate

parameters.

Figure 7-29 Handover Notify

7.2.9 Path Switch

The Path Switch Request message is sent by the eNB to request the MME to switch downlink

GTP tunnel termination point(s) from one end-point to another. Note it is also discussed in

Section 8.1 .




7-115

Path Switch Request

Figure 7-30 illustrates an example whereby the handover has taken place between two eNBs.

On completion of the handover the target eNB sends the Path Switch Request message to the

MME indicating a new eNB UE S1AP ID, as well as the original MME UE S1AP ID. The

MME on receiving this message triggers a GTPv2-C Modify Bearer procedure towards the

S-GW.

Figure 7-30 S1 Path Switch Request

Path Switch Request Acknowledge

The MME, on successfully updating the S-GW, forwards the Path Switch Request

Acknowledge message to the target eNB.

Figure 7-31illustrates the Path Switch Request Acknowledge message and its parameters. The

MME has assigned a new MME UE S1AP ID and other parameters are similar to previous

S1AP messages.

It is worth noting that if multiple EPS Bearers (multiple E-RABs) were active, each would be

assigned a new Transport Layer Address and GTP-TEID.




Issue 06 (2006-03-01)

Figure 7-31 Path Switch Request Acknowledge

7.2.10 Handover Cancel

The purpose of the Handover Cancel procedure is to enable a source eNB to cancel an

ongoing handover preparation or an already prepared handover. Figure 7-32 illustrates the

Handover Cancel procedure.

Figure 7-32 Handover Cancel




7-117

7.2.11 Status Transfer

The purpose of the eNB Status Transfer procedure and MME Status Transfer procedure is to

transfer the uplink PDCP-SN and HFN receiver status and the downlink PDCP-SN and HFN

transmitter status from the source eNB to the target eNB via the MME during an intra LTE S1

handover for each respective E-RAB for which PDCP-SN and HFN status preservation

applies. These messages carry a container which includes similar parameters to the X2 Status

Transfer message discussed in Section 7.1.5 .

7.2.12 UE Context Release

The UE Context Release procedure enables the MME to release of the UE associated logical

connection due to various reasons, for example:

� Completion of a transaction between the UE and the EPC.

� Completion of successful handover.

� Completion of handover cancellation.

� Release of the old UE associated logical S1-connection when two UE-associated logical

S1-connections toward the same UE are detected after the UE has initiated the

establishment of a new UE associated logical S1-connection.

The procedure uses UE-associated S1 connection.

Figure 7-33 illustrates the UE Context Release Command message towards the MME. This

contain the UE S1AP ID pair parameter (if available), otherwise it contain the MME UE

S1AP ID.

Figure 7-33 UE Context Release

UE Context Release Request - eNB Initiated

The purpose of the UE Context Release Request procedure is to enable the eNB to request the

MME to release the UE associated logical S1 connection due to E-UTRAN generated reason.




Issue 06 (2006-03-01)

Figure 7-34 UE Context Release Request

7.2.13 Reset

The purpose of the Reset procedure is to initialize or re-initialize the E-UTRAN, or part of

E-UTRAN S1AP UE-related contexts, in the event of a failure in the EPC or vice versa.

Figure 7-35 S1 Reset

7.2.14 Location Reporting Control

The purpose of Location Reporting Control procedure is to allow the MME to request the

eNB to report where the UE is currently located.

The Request Type contains two parameters:

� Event - this can indicate Direct, Change of service cell, Stop Change of service cell.

� Report Area - this has only one option, i.e. ECGI.




7-119

Figure 7-36 Location Report Control

Location Report Control

MME UE S1AP IDeNB UE S1AP IDRequest Type- Event- Report Area

7.2.15 Overload

The purpose of the Overload Start procedure is to inform an eNB to reduce the signaling load

towards the concerned MME.

Figure 7-37 Overload Start

The Overload Start message indicates the Overload Action to be performed. This is either:

� Reject all RRC connection establishments for non-emergency Mobile Originated Direct

Transfer.

� Reject all RRC connection establishments for Signaling.

� Permit Emergency Sessions only.

Overload Stop

The purpose of the Overload Stop procedure is to signal to an eNB the MME is connected to

that the overload situation at the MME has ended and normal operation can resume.

7.2.16 Direct Information Transfer

The purpose of the eNB Direct Information Transfer procedure and MME Direct Information

Transfer procedure is to transfer RAN (Radio Access Network) information to and from the

eNB. Note that the MME does not interpret the transferred RAN information. The payload

includes RIM (RAN Information Management) to and from a GERAN BSS (Base Station

Subsystem).




Issue 06 (2006-03-01)

7.2.17 Paging

The paging of UEs in Idle Mode is facilitated by the MME to send a Paging message to all

eNBs managing the UEs TAI (Tracking Area Identity) or TAIs. Figure 7-38 illustrates the

Paging message and its parameter.

Figure 7-38 Paging

Paging

UE Identity Index ValueUE Paging IdentityPaging DRX (O)CN DomainList of TAIs

- TAICSG Id List (O)- CSG Id

The key parameters include:

� UE Identity Index Value - this is used by the eNB for calculating the paging occurrence.

The value relates to the IMSI mod 1024.

� UE Paging Identity - this is the S-TMSI for the UE.

� Paging DRX (O) - this indicates the default Paging DRX value.

� CN Domain - this indicates whether this is a PS (Packet Switched) or CS (Circuit

Switched) paging request.

� List of TAIs - this indicates to the eNB which TAI(s) the paging message should be send.

� CSG Id List - this indicates which CSG (Closed Subscriber Group) Identity cells should

be paged.

7.3 User Plane GTP Functions and Procedures

There are various types and version of GTP (GPRS Tunneling Protocol). The E-UTRAN

specifically uses GTPv1-U (GPRS Tunneling Protocol Version 1 - User) on the X2 and S1-U

interfaces. It is worth noting that GTPv1-U is also in the User Plane tunnel in the EPC.

7.3.1 GTP Tunnels

Many UE PDN (Packet Data Network) sessions, termed GTP Tunnels, may be multiplexed

across the GTP Path using the TEID (Tunnel Endpoint Identifier). The receiving side of a

GTP tunnel locally assigns the TEID value the transmitting side has to use. The TEID values

are exchanged between tunnel endpoints using S1AP messages on the S1-MME interface and

GTPv2-C (GPRS Tunneling Protocol Version 2 - Control) messages on the S11 interface.

Figure 7-39 illustrates the concept of a GTP tunnel and the associated endpoints.




7-121

Figure 7-39 GTP Tunnel

Each GTP Tunnel supports one EPS Bearer, i.e. E-RAB. Thus multiple tunnels exist for multiple UEs.

7.3.2 GTPv1-U Header

It is worth noting the headers for GTPv1-U are different to GTPv2-C. Figure 7-40 illustrates

the GTPv1-U header, highlighting the TEID field.

Figure 7-40 GTPv1-U Header

The parameters in the header include:

� Version - this field is used to determine the version of the GTP-U protocol, i.e. version 1.

� PT (Protocol Type) - this bit is used as a protocol discriminator between GTP (when PT

is '1') and GTP’ (when PT is '0'). Note GTP’ is not used in the E-UTRAN.

� E (Extension) - this flag indicates the presence of a meaningful value of the Next

Extension Header Type field. When it is set to '1', the Next Extension Header field is

present and interpreted.




Issue 06 (2006-03-01)

� S (Sequence) - this flag indicates the presence of a meaningful value of the Sequence

Number field. For the Echo Request, Echo Response, Error Indication and Supported

Extension Headers Notification messages, the S flag is be set to '1'. Since the use of

Sequence Numbers is optional for G-PDUs, the PDN-GW, S-GW and eNB should set the

flag to '0'. However, when a G-PDU is being relayed by the Indirect Data Forwarding for

Inter RAT HO procedure, then if the received G-PDU has the S flag set to '1', then the

relaying entity shall set S flag to '1' and forward the G-PDU.

� PN (N-PDU Number) - this flag indicates the presence of a meaningful value of the

N-PDU Number field. When it is set to '1', the N-PDU Number field is present and

interpreted.

� Message Type - this field indicates the type of GTP-U message.

� Length - this field indicates the length in octets of the payload, i.e. the rest of the packet

following the mandatory part of the GTP header (that is the first 8 octets).

� TEID (Tunnel Endpoint Identifier) - this field unambiguously identifies a tunnel

endpoint in the receiving GTP-U protocol entity. The receiving end side of a GTP tunnel

locally assigns the TEID value the transmitting side has to use. The TEID is used by the

receiving entity to find the EPS Bearer, except for the following cases:

− The Echo Request/Response and Supported Extension Headers notification messages,

where the Tunnel Endpoint Identifier is set to all zeroes.

− The Error Indication message where the Tunnel Endpoint Identifier is set to all zeros.

Optional Fields � Sequence Number - this is used for G-PDUs, an increasing sequence number for the

original IP packets transmitted via GTP-U tunnels, when transmission order must be

preserved.

� N-PDU Number - this is used at the Inter SGSN Routing Area Update procedure and

some inter-system handover procedures (e.g. between 2G and 3G radio access networks).

It coordinates the data transmission for acknowledged mode of communication between

the 2G MS (Mobile Station) and the SGSN (Serving GPRS Support Node).

� Next Extension Header Type - this defines the type of Extension Header that follows this

field in the GTP-PDU, e.g. PDCP PDU number.

7.3.3 Extension Header

Figure 7-41 illustrates the GTP extension header. This includes the content and its length, i.e.

the type field in the GTP header indicated what was included.

Figure 7-41 GTP Extension Header

Following the Extension Header Content a “Next Extension Header Content” is added. This

indicates if an additional extension header is added, if not, it is set to zero.

Currently there are two defined extension headers, namely UDP Port and PDCP PDU number.




7-123

Extension Header - UDP Port

This extension header is usually transmitted in Error Indication messages to provide the UDP

Source Port of the G-PDU that triggered the Error Indication.

Extension Header - PDCP PDU Number

This extension header is transmitted between eNBs when PDCP PDU packets are forwarded

between the source and target eNBs. The use of this extension header is discussed in Section

8.1 .

7.3.4 Handling of Sequence Numbers

For PDN-GW, S-GW and eNB the usage of sequence numbers in G-PDUs is optional, but if

present GTP-U protocol entities in these nodes are relaying G-PDUs to other nodes, then they

relay the sequence numbers.

7.3.5 GTPv1-U Procedures

Table 7-5 lists the various GTPv1-U messages. The G-PDU is used to tunnel IP datagrams to

and from the eNB.

Table 7-5 Messages in GTP-U

Message Type Value Message

1 Echo Request

2 Echo Response

3-25 Reserved

26 Error Indication

27-30 Reserved

31 Supported Extension Headers Notification

32-253 Reserved

254 End Marker

255 G-PDU

7.3.6 Path Management

Echo Procedure

GTP-U peer entities can send an Echo Request on a path to find out if it is alive. The Echo

Request messages can also be sent for each path in use, i.e. for each EPS Bearer. The

procedure can be repeated periodically and whilst the timing is implementation specific it is

not sent more often than every 60s on each path. Note that this does not prevent resending an

Echo Request with the same sequence number based on response timers.




Issue 06 (2006-03-01)

Figure 7-42 GTP Echo Procedure

For the GTP-U tunnel setup between two nodes for forwarding user traffic, e.g. between eNBs

for direct forwarding over X2, Echo Request path maintenance message are not sent except if

the forwarded data and the normal data are sent over the same path.

Path Failure

A path counter is used to manage each path. This is used in conjunction with a T3-Response

Timer and N3-Requests parameter. The path counter is reset each time an Echo Response is

received on the path and incremented when the T3-Response Timer expires for any Echo

Request message sent on the path. The path is classed as down if the counter exceeds

N3-Requests. In this case, the GTP-U peer may notify the Operation and Maintenance

network element. In addition, the GTP-U peer will also notify the upper layer of the path

failure, so that EPS contexts associated with the path may be deleted. The recommended

value for the N3-Requests parameter is 5 and the T3-Response Timer is usually 20 seconds.

Supported Extension Headers Notification Procedure

The Supported Extension Headers Notification message indicates a list of supported

Extension Headers that the GTP entity on the identified IP address can support.




7-125

Figure 7-43 Supported Extension Headers Notification

This message is sent only in case a GTP entity was required to interpret a mandatory

Extension Header but the GTP entity was not yet upgraded to support that extension header.

The peer GTP entity may retry to use all the extension headers with that node, in an attempt to

verify it has been upgraded.

Error Indication Procedure

When a GTP-U node receives a GTP-U PDU for which no EPS Bearer context exists the

GTP-U node discards it and returns a GTP error indication to the originating node. Note that

the GTP entities may include the "UDP Port" extension header (Type 0x40), in order to

simplify the implementation of mechanisms that can mitigate the risk of Denial-of-Service

attacks in some scenarios.

End Marker Procedure

The End Marker procedure is one of the key procedures performed by GTPv1-U. Figure 7-44

illustrates a handover scenario whereby the End Maker message is sent following the last

packet to the source eNB. Note that multiple End Marker messages may be sent, for example

one for each EPS Bearer.

Figure 7-44 End Marker Procedure




Issue 06 (2006-03-01)

7.3.7 UDP header and Port Numbers

The registered port for GTP-U is 2152 and depending on the actual GTP message or

procedure this value, or a different value, may be used. The different

� Echo Request Message - the UDP Destination Port number for GTP-U request messages

is 2152. The UDP Source Port is a locally allocated port number at the sending GTP-U

entity.

� Echo Response Message - the UDP Destination Port value is the UDP Source Port of the

corresponding request message. The UDP Source Port is the value from the UDP

Destination Port of the corresponding request message.

� Encapsulated T-PDUs - the UDP Destination Port number is 2152. The UDP Source Port

is a locally allocated port number at the sending GTP-U entity.

� Error Indication - the UDP destination port for the Error Indication is the User Plane

UDP port (2152). The UDP source port is locally assigned at the sending node.

NOTE: In network deployments including non-GTP-aware stateful firewalls, those firewalls

must be configured to allow response messages coming from a different UDP port and IP

address than the triggering message.

Supported Extension Headers Notification - the UDP destination port for the Supported

Extension Headers Notification is the User Plane UDP port (2152). The UDP source port is

locally assigned at the sending node.

LTE Protocols and Procedures 8 Mobility in LTE



8-127

8 Mobility in LTE About This Chapter


Section

8.1 X2 Handover

8.2 S1 Handover

8.3 Inter RAT Handover

8 Mobility in LTE LTE Protocols and Procedures



Issue 06 (2006-03-01)

8.1 X2 Handover

8.1.1 Handover Phases

In the RRC Connected mode the system performs network controlled UE assisted handovers.

Broadly, this process may be divided into three distinct phases. These are:

� Measurement and Reporting - the UE takes measurements of neighbor cells and reports

these to the serving eNB. The periodicity and radio characteristics of these reports are

indicated to the UE through dedicated signaling.

� Handover Preparation Phase - based on the UE measurements, the most suitable

candidate, i.e. target eNB, is identified. Interaction across the X2 interface takes place to

allocate resources on the target eNB and to transfer context information. The target eNB

provides information, via the source eNB, to access the new cell.

� Conduct Handover - once the UE has accessed information for the target cell, it conducts

the Random Access procedure to gain access and acquire timing information. Once on

the new eNB, the packet flow from the S-GW can be switched from the source eNB to

the target eNB. Finally, resources on the old eNB are released and context information

within the EPC is updated.

Figure 8-1 Handover Phases

When handovers are conducted, the eNB must make sure that the eNB cells that are

candidates for handover comply with roaming and mobility restrictions for the specific UE.

Consequently, the UE Context within the source eNB contains information regarding roaming

restrictions which were provided either at connection establishment or during the last

Tracking Area Update. The source eNB configures the UE’s measurement procedures

according to this area restriction information.

8.1.2 X2 Based Handover with Lossless PDCP

The UE is configured to send Measurement Reports based on the Measurement Configuration

information in RRC signaling, as discussed in Section 4.4.10 . Using these Measurement

Reports, the source eNB makes decisions regarding the handover. Note that the handover

could be triggered through other mechanisms, such as cell loading, time advance,

pre-emption, O&M, etc.




8-129

Figure 8-2 illustrates the main type of handover, namely an X2 based handover whilst

maintaining PDCP sequencing, i.e. providing a lossless service.

Figure 8-2 X2 Based Handover with Lossless PDCP

Measurement

Report Handover Request

Handover

Request AckRRC Connection

Reconfiguration Request

SN Status

Transfer

RRC Connection Reconfiguration Complete Path Switch

Request Modify Bearer

Request

Modify Bearer ResponsePath Switch

Request Ack

End Marker

(GTP-U Message)

End Marker(GTP-U Message)

PDCP Status Report

PDCP Status Report

Source Target

PRACH Preamble

Random Access Response

UE Context

Release

Measurement Report

The information in the Measurement Report messages from the UE will include serving cell

information, as well as the Physical Cell ID for the handover candidates. It will also include

the requested measurement, e.g. RSRP (Reference Signal Received Power) or RSRQ

(Reference Signal Received Quality). This enables the serving eNB to rank the candidates and

identify the most suitable one with which to conduct the handover. Note that various offsets

could be used to encourage or discourage handovers from certain cells. Section 4.4.10

discusses the configuration of measurement results.

X2 Handover Request and Response

The actual handover process starts when the source eNB issues a X2AP Handover Request

message to the target eNB passing the necessary information to prepare the handover at the

target eNB. This includes the identity of the MME serving the UE, target cell ID, security

keys, UE and RRC Context information, including the E-RAB (E-UTRAN - Radio Access




Issue 06 (2006-03-01)

Bearer) information, and associated QoS. Full details of the message are discussed in Section

7.1.5 .

Admission Control is performed by the target eNB dependent on the received EPS Bearer

QoS information. Assuming resources are available, the target eNB reserves the required

resources and allocates a C-RNTI and optionally a RACH preamble.

The target eNB sends the Handover Request Acknowledge message to the source eNB. This

message includes a transparent container to be sent to the UE, i.e. a RRC Connection

Reconfiguration Request message. This includes a new C-RNTI, target eNB security

algorithm identifiers for the selected security algorithms and dedicated RACH preamble

information.

RRC Connection Reconfiguration

The source eNB triggers the handover by sending an RRC Connection Reconfiguration

message to the UE. Figure 8-3 illustrates the key information included in the Mobility Control

Information parameter.

Figure 8-3 Mobility Control Information

The Mobility Control Information parameters include:

� Target Physical Cell ID - this indicates the Physical Cell ID (0-503).

� Carrier Frequency - this indicates the target cell downlink and uplink E-ARFCN.

� Carrier Bandwidth - this indicates the target cell downlink and uplink bandwidth.

� Additional Spectrum Emission - this indicates additional emission information, i.e.

indicates that the UE should not exceed a specified level for the specified channel

bandwidth.

� T304 - this is the handover timer. If the handover has not been finished and on

completion of this timer the handover failure procedure is initiated. Values include:

ms50, ms100, ms150, ms200, ms500, ms1000 and ms2000.

� New UE Identity - this is the UEs C-RNTI on the new cell.

� Radio Resource Config Common - this provides information about common parameters,

i.e. information which is broadcast from the target cell.




8-131

� Rach-Config Dedicated - this can assign a dedicated preamble index (0-63) and a

PRACH Mask Index.

Random Access

Using the assigned information (from the RRC Connection Reconfiguration Request

message) the UE is able to access the target cell and obtain an initial uplink allocation, as well

as timing information. Following this, the UE is able to send the RRC Connection

Reconfiguration Complete message to the target eNB (stopping T304).

SN Status Transfer and Status Report

The EPS Bearer may define PDCP preservation status, i.e. lossless PDCP. If so, the source

eNB sends the X2AP SN (Sequence Number) Status Transfer message to the target eNB to

convey the uplink PDCP SN receiver status and the downlink PDCP SN transmitter status of

the specific EPS bearers. Figure 8-4 illustrates the X2AP SN Status Transfer message and the

concept of forwarding packets.

Figure 8-4 X2AP SN Status Transfer

In addition, the UE upon completing the handover to the target eNB exchanges PDCP Status

Report PDUs. These are discussed in Section 5.1.3 and indicate the UEs PDCP Status to the

target eNB. In so doing, the target eNB is able to identify missing PDCP packets from the

downlink perspective, as well as indicate to the UE missing uplink PDCP packets. As a result,

the UE and eNB are able to re-send the packets.

Path Switch

The forwarding of downlink user data from the source to the target eNB now takes place. The

target eNB sends a S1AP Path Switch message (discussed in Section 7.2.9 ) to the MME to

inform it that the UE has changed cell and identifies the new eNB supporting the cell. The




Issue 06 (2006-03-01)

MME sends a GTPv2-C Modify Bearer Request message to the S-GW which switches the

downlink data path to the target side and releases any User Plane resources towards the source

eNB. Once this has been completed, the S-GW sends a Modify Bearer Response message to

the MME which confirms the path switch with the Path Switch Ack message. Finally, the

target eNB is able to send a x2AP UE Context Release message to the old eNB.

End Marker

To indicate that the S-GW has stopped sending data to the source eNB, it sends a GTP End

Marker message (discussed in Section 7.3.6 ) on GTP-U to the source eNB, which in turn

forwards it to the target eNB.

8.1.3 Data Forwarding

Various rules exist for the forwarding of data between the source eNB and target eNB.

RLC-AM DRBs

Upon handover, the source eNB may forward, in order, to the target eNB all downlink PDCP

SDUs with an SN that has not been acknowledged by the UE. In addition, the source eNB

may also forward without a PDCP SN fresh data arriving over S1 to the target eNB. It is

worth noting that the target eNB does not have to wait for the completion of forwarding from

the source eNB before it begins transmitting packets to the UE.

Upon handover, the source eNB forwards to the Serving Gateway the uplink PDCP SDUs

successfully received in-sequence until the sending of the Status Transfer message to the

target eNB. Then, at that point in time, the source eNB stops delivering uplink PDCP SDUs to

the S-GW.

Following this, the source eNB can either:

� Discard the uplink PDCP SDUs received out of sequence - this assumes that the source

or target eNB has not accepted the forwarding of uplink SDUs.

� Forward to the target eNB the uplink PDCP SDUs received out of sequence - this

assumes that the source eNB and target eNB have agreed to do this as part of the

handover preparation phase.

For RLC-UM DRBs

Upon handover, the source eNB does not forward to the target eNB downlink PDCP SDUs for

which transmission had been completed in the source cell. PDCP SDUs that have not been

transmitted may be forwarded. In addition, the source eNB may forward fresh downlink data

arriving over S1 to the target eNB.

Upon handover, the source eNB forwards all uplink PDCP SDUs successfully received to the

Serving Gateway (i.e. including the ones received out of sequence).

SRB Handling

With respect to SRBs, the following principles apply at HO:

� No forwarding or retransmissions of RRC messages in the target.

� The PDCP SN and HFN are reset in the target.




8-133

8.2 S1 Handover

Fundamentally, an S1 based handover is triggered when the source eNB wants to handover to

another cell and the X2 interface (with associated X2AP) is not configured. There are a

number of different S1 based handovers, with most utilizing the same set of messages.

8.2.1 Inter MME and S-GW Handover

Preparation Phase

Figure 8-5 illustrates an S1 based handover supporting indirect data forwarding between two

S-GWs. The procedure begins with the Source eNB indicating that an S1 handover is required

by sending the S1AP Handover Required message to the Source MME indicating the Target

eNB etc. Details of this message can be found in Section 7.2.8 The Source MME selects the

appropriate Target MME and sends the GTPv2-C Forward Relocation Request message which

includes amongst other things EPS Bearer information and MME UE Context. The latter

contains information defining the mobility and security attributes. Once this message is

received the Target MME is able to establish an uplink tunnel between the Target S-GW and

PDN-GW through the Create Session Request / Response signaling exchange.

Figure 8-5 S1 Based Inter MME/S-GW Handover

The Target MME then sends the S1AP Handover Request message to the Target eNB

including a list of the EPS bearers to transfer. Furthermore, the message also includes the




Issue 06 (2006-03-01)

necessary parameters to establish an uplink tunnel between the Target eNB and the Target

S-GW for uplink traffic. The Target eNB responds with the Handover Request Acknowledge

message which included the various TEIDs to support downlink traffic. The MME then passes

this information to the Target S-GW enabling the bi-directional tunnel between the Target

eNB and Target S-GW to become operational. It should be noted however at this stage, data is

still passing through the existing equipment: Source eNB, Source S-GW and PDN-GW.

Upon receiving the Create Indirect Data Forwarding Tunnel Response message, the MME

sends the Source MME the Forward Relocation Response message containing a transparent

container with the Handover Command message from the Target eNB. It also contains

addressing information enabling the Source S-GW to be able to start forwarding data to the

Target S-GW. This information is then passed to the Source S-GW through the Create Indirect

Data Forwarding Tunnel signaling exchange. A uni-directional tunnel now exists between the

Source S-GW and the Target S-GW.

Conduct Handover Phase

This phase begins with the Source MME sending the Handover Command message to the UE

via the Source eNB. The Handover Command also contains a list of bearers subject to

forwarding enabling downlink data at the Source eNB to be forwarded to the Target S-GW via

the Source S-GW. The RRC Connection Reconfiguration Request message is sent to the UE.

This includes the Mobility Control Information which indicates to the UE how to access the

new cell, as well as key common and dedicated parameters.

Figure 8-6 S1 Based Inter MME/S-GW Handover Continued

The UE then detaches from the old cell and synchronizes with the Target eNB before sending

the RRC Connection Reconfiguration Complete message. This triggers the Target eNB to




8-135

send the Target MME the S1AP Handover Notify message which in turn informs the Source

MME that the Forward Relocation procedure is complete. Finally, the Target MME sends the

Modify Bearer Request message to the Target S-GW which in turn sends it to the PDN-GW,

triggering it to direct downlink data for the EPS bearers to the Target S-GW. This phase

culminates with the sending of the Modify Bearer Response messages between the PDN-GW,

Target S-GW and Target MME.

Tracking Area Update and Clearing Resources

The final procedure is the clearing down of the old sessions and tunnels. This is achieved

through a series of Context Release and Delete tunnel messages which begins immediately

following the Tracking Area Update procedure.

Figure 8-7 S1 Based Inter MME/S-GW Handover Continued

8.2.2 S1 Status Transfer

During the previous handover procedure the Source eNB and Target eNB may exchange

status information, i.e. PDCP Sequence Number information, using the eNB Status Transfer

and MME Status Transfer messages. If sent, these immediately follow the S1AP Handover

Command message. More information on these messages can be found in Section 7.2.11 .




Issue 06 (2006-03-01)

8.3 Inter RAT Handover

After intra-LTE handovers the next most common handovers will be to and from

UTRAN/GERAN systems.

8.3.1 E-UTRAN to UTRAN Handover

Assuming that the UE has been configured to measure Inter RAT cells, i.e. the measurement

and reporting mechanisms have been configured, the eNB may get a Measurement Report

indicating that the UTRAN cell is better. The handover procedure to the UTRAN begins when

the Source eNB determines that a handover to UTRAN is required. As such, it sends the S1AP

Handover Required message to the Source MME which includes the Target Identifier, either a

RNC identity or a CGI (Cell Global Identity). The Source MME uses this information to

determine the Target SGSN (Serving GPRS Support Node) and sends the GTPv2-C Forward

Relocation Request message.

The Target SGSN then maps the EPS bearers to PDP Contexts, including QoS parameters. It

then requests the Target RNC to establish the radio network resources, i.e. RABs, by sending

the RANAP (Radio Access Network Application Protocol) Relocation Request message. The

RNC allocates the necessary resources and returns the RANAP Relocation Request

Acknowledge message. At this stage, the GTP tunnel is established between the Target RNC

and the Target SGSN. The preparation phase culminates with the Target SGSN sending the

Source MME the GTPv2-C Forward Relocation Response message. This contains the

transparent container generated in the Target RNC containing the handover parameters.

Finally, the Source MME exchanges signaling information with the Source S-GW to enable a

tunnel to be established between the Source S-GW and the Target SGSN.

Figure 8-8 E-UTRAN to UTRAN Handover

Handover RequiredForward Relocation Request

Relocation Request

Relocation Request Ack

Forward Relocation Response

Create Indirect Data

Forwarding Tunnel Response

Create Indirect Data

Forwarding Tunnel Request

The remaining elements of the procedure follow standard UTRAN Relocation mechanisms

with the exception of the Target SGSN sending the Forward Relocation Complete Notification

message to the MME. Finally, the Source S-GW informs the PDN-GW of a modification to




8-137

the bearer using the Modify Bearer Request / Response messages. In addition, the MME is

able to release the S1 resources.

Figure 8-9 E-UTRAN to UTRAN Handover Continued

Handover Command

Forward Relocation

Complete Notification

Forward Relocation Complete Ack

Modify Bearer Request

Handover

from

E-UTRAN

Handover to

UTRAN CommandRelocation Complete

Modify Bearer Response

UE Context Release Command

UE Context Release

Complete

It should be noted that this is only one example of how this procedure may take place and in

reality, there may be a number of additional elements which may become involved if

necessary. These include additional S-GWs, as well as the establishment of various direct

tunnels in the EPC.

8.3.2 UTRAN to E-UTRAN Handover

The process of handing over from UTRAN to E-UTRAN is similar to the previous procedure,

in that there is a Relocation procedure performed. The decision to handover to the E-UTRAN

system is performed by the SRNC (Serving RNC). This also identifies the target cell to which

the session is to be routed. The SRNC triggers a Relocation Required message to initiate the

procedure. The SGSN (Serving GPRS Support Node) will then signal to the target MME and

effectively relay information from the SRNC towards the target eNB.

9 Glossary LTE Protocols and Procedures



Issue 06 (2006-03-01)

9 Glossary Numerics

16 QAM (Quadrature Amplitude

Modulation)

64QAM (Quadrature Amplitude

Modulation) 2G (Second Generation)

3G (Third Generation)

3GPP (Third Generation

Partnership Project)

4G (Fourth Generation)

A

AAA (Access Authorization and

Accounting)

AC (Access Class)

AES (Advanced Encryption

Standard)

AKA (Authentication and Key

Agreement)

AM (Acknowledged Mode)

AMBR (Aggregate Maximum Bit

Rate)

AMD (Acknowledged Mode

Data)

APN (Access Point Name)

APN AMBR (Access Point Name

Aggregate Maximum Bit Rate)

ARP (Allocation and Retention

Priority)

AS (Access Stratum)

B

BCCH (Broadcast Control

Channel)

BCH (Broadcast Channel)

BI (Backoff Indicator)

BSR (Buffer Status Report)

C

C (Conditional)

CCCH (Common Control

Channel)

CGI (Cell Global Identifier)

CQI (Channel Quality Indication)

CRF (Charging Rules Function)

CS (Circuit Switched)

CSG (Closed Subscriber Group)

D

D/C (Data/Control)

dB (Decibels)

DCCH (Dedicated Control

Channel)

DL-SCH (Downlink - Shared

Channel)

DRB (Data Radio Bearer)

DRX (Discontinuous Reception)

DSCP (Differentiated Services

Code Point)

DTCH (Dedicated Traffic

Channel)

DTM (Dual Transfer Mode)

E

E (Extension)

EARFCN (E-UTRA Absolute

Radio Frequency Channel

Number)

ECGI (E-UTRAN Cell Global

Identifier)

ECI (Evolved Cell Identity)

EIR (Equipment Identity

Register)

EMM (EPS Mobility

Management)

eNB (Evolved Node B)

EP (Elementary Procedures)

EPC (Evolved Packet Core)

ePDG (evolved Packet Data

Gateway)

EPS (Evolved Packet System)

E-RAB (E-UTRAN - Radio

Access Bearer)

ESM (EPS Session Management)

ESM (Evolved Session

Management)

LTE Protocols and Procedures 9 Glossary



9-139

E-UTRA (Evolved - Universal

Terrestrial Radio Access)

E-UTRAN (Evolved - Universal

Terrestrial Radio Access

Network)

F

FAC (Final Assembly Code)

FDD (Frequency Division

Duplex)

FI (Frame Information)

FO (First-Order)

G

GBR (Guaranteed Bit Rate)

GERAN (GSM/EDGE Radio

Access Network)

GTP (GPRS Tunneling Protocol)

GTP-U (GPRS Tunneling

Protocol - User)

GTPv1-U (GPRS Tunneling

Protocol Version 1 - User Plane)

GTPv2-C (GPRS Tunneling

Protocol Version 2 - Control)

GU Group ID (Globally Unique

Group Identifier)

GUMMEI (Globally Unique

MME Identifier)

GUTI (Globally Unique

Temporary Identity)

H

HA (Home Agent)

HARQ (Hybrid Automatic Repeat

Request)

HeNB (Home Evolved Node B)

HeNB-GW (Home Evolved Node

B - Gateway)

HFN (Hyper Frame Number)

HPLMN (Home Public Land

Mobile Network)

HRPD (High Rate Packet Data)

HSS (Home Subscriber Server)

I

IE (Information Elements)

IETF (Internet Engineering Task

Force)

IMEI (International Mobile

Equipment Identity)

IMS (IP Multimedia Subsystem)

IMSI (International Mobile

Subscriber Identity)

IR (Initialization and Refresh)

L

LCG ID (Logical Channel Group

Identity)

LCID (Logical Channel

Identifier)

LI (Length Indicator)

LSF (Last Segment Flag)

LTE (Long Term Evolution)

M

M (Mandatory)

MAC (Medium Access Control)

MAC-I (Message Authentication

Code - Integrity)

MAG (Mobile Access Gateway)

MCC (Mobile Country Code)

ME (Mobile Equipment)

MIB (Master Information Block)

MIMO (Multiple Input Multiple

Output)

MME (Mobility Management

Entity)

MMEC (MME Code)

MNC (Mobile Network Code)

MS (Mobile Station)

MSB (Most Significant Bits)

MSIN (Mobile Subscriber

Identity Number)

M-TMSI (MME - Temporary

Mobile Subscriber Identity)

N

NAS (Non Access Stratum)

non-GBR (non - Guaranteed Bit

Rate)

NSAPI (Network layer Service

Access Point Identifier)

O

O (Optional)

O&M (Operations and

Maintenance)

OFDMA (Orthogonal Frequency

Division Multiple Access)

P

P (Polling)

9 Glossary LTE Protocols and Procedures



Issue 06 (2006-03-01)

PBCH (Physical Broadcast

Channel)

PBR (Prioritized Bit Rate)

PCCH (Paging Control Channel)

PCFICH (Physical Control

Format Indicator Channel)

PCH (Paging Channel)

PCI (Physical Cell Identifier)

PCRF (Policy and Charging Rules

Function)

PDCCH (Physical Downlink

Control Channel)

PDCP (Packet Data Convergence

Protocol)

PDF (Policy Decision Function)

PDN (Packet Data Network)

PDSCH (Physical Downlink

Shared Channel)

PDU (Protocol Data Unit)

PH (Power Headroom)

PHICH (Physical Hybrid ARQ

Indicator Channel)

PHR (Power Headroom Report)

PHY (Physical Layer)

PL (Pathloss)

PLMN (Public Land Mobile

Network)

PMIP (Proxy Mobile IP)

PN (N-PDU Number)

PRACH (Physical Random

Access Channel)

PRB (Physical Resource Block)

PS (Packet Switched)

PT (Protocol Type)

PUCCH (Physical Uplink Control

Channel)

PUSCH (Physical Uplink Shared

Channel)

Q

QCI (QoS Class Identifier)

QoS (Quality of Service)

QPSK (Quadrature Phase Shift

Keying)

R

RA (Random Access)

RACH (Random Access Channel)

RAI (Routing Area Identity)

RAN (Radio Access Network)

RAPID (Random Access

Preamble Identifier)

RAR (Random Access Response)

RAT (Radio Access Technology)

RB (Radio Bearer)

RLC (Radio Link Control)

RLF (Radio Link Failure)

RNC (Radio Network Controller)

RNL (Radio Network Layer)

RNTP (Relative Narrowband Tx

Power)

ROHC (Robust Header

Compression)

RR (Radio Resource)

RRC (Radio Resource Control)

RRM (Radio Resource

Management)

RSRP (Reference Signal Received

Power)

RSRQ (Reference Signal

Received Quality)

S

S (Sequence)

S1AP (S1 Application Protocol)

SC-FDMA (Single Carrier -

Frequency Division Multiple

Access)

SCTP (Stream Control

Transmission Protocol)

SDF (Service Data Flow)

SDU (Service Data Unit)

SGSN (Serving GPRS Support

Node)

S-GW (Serving - Gateway)

SI (System Information)

SIB 1 (System Information Block

1)

SMS (Short Message Service)

SN (Sequence Number)

SNR (Serial Number)

SO (Second-Order)

SO (Segment Offset)

SPS (Semi-Persistent Scheduling)

SRB (Signaling Radio Bearer)

SRNC (Serving RNC)

SRS (Sounding Reference Signal)

SRVCC (Single Radio Voice Call

Continuity)

S-TMSI (Serving - Temporary

Mobile Subscriber Identity)

T

TA (Timing Advance)

TA (Tracking Areas)

TAC (Tracking Area Code)

LTE Protocols and Procedures 9 Glossary



9-141

TAC (Type Approval Code)

TAI (Tracking Area Identity)

TAU (Tracking Area Update)

TB (Transport Block)

TCP (Transmission Control

Protocol)

TCP/IP (Transmission Control

Protocol, Internet Protocol)

TDD (Time Division Duplex)

TEID (Tunnel Endpoint

Identifier)

TFT (Traffic Flow Template)

Thresh1 (Threshold1)

Thresh2 (Threshold2)

TM (Transparent Mode)

TMD (Transparent Mode Data)

TNL (Transport network Layer)

TPC (Transmit Power Control)

TTT (Time To Trigger)

U

UDP (User Datagram Protocol)

UE (User Equipment)

UE AMBR (User Equipment

Aggregate Maximum Bit Rate)

UL (Uplink)

UL-SCH (Uplink Shared

Channel)

UM (Unacknowledged Mode)

UMD (Unacknowledged Mode

Data)

USIM (Universal Subscriber

Identity Module)

UTRA (Universal Terrestrial

Radio Access)

UTRAN (Universal Terrestrial

Radio Access Network)

V

VoIP (Voice over IP)

VPLMN (Visited Public Land

Mobile Network)

W

WCDMA (Wideband CDMA)

X

X2AP (X2 Application Part)

X2AP (X2 Application Protocol)

OptiX Metro 6100

Configuration Guide 9 Glossary



9-1

Cautioned WordsCautioned WordsCautioned WordsCautioned Words 1 IMSI/IMEI/IP Address The privacy-related information may be anonymity for user's privacy protection

Microsoft Word - 6. OEA000201 LTE Protocols and Procedures ISSUE 1

Documents

Transcript of Microsoft Word - 6. OEA000201 LTE Protocols and Procedures ISSUE 1