LTE Protocols and Procedures - ST3 Telkomalfin.dosen.st3telkom.ac.id/.../12/LTE-Protocols-and-Procedures.pdf · LTE Protocols and Procedures ... the HSS provides support to the call

LTE Protocols and Procedures

LZT 123 8958 R1A © Ericsson 2009 - 1 -


STUDENT BOOK LZT 123 8958 R1A


- 2 - © Ericsson 2009 LZT 123 8958 R1A

DISCLAIMER This book is a training document and contains simplifications. Therefore, it must not be considered as a specification of the system. The contents of this document are subject to revision without notice due to ongoing progress in methodology, design and manufacturing. Ericsson assumes no legal responsibility for any error or damage resulting from the usage of this document. This document is not intended to replace the technical documentation that was shipped with your system. Always refer to that technical documentation during operation and maintenance.

© Ericsson 2009 This document was produced by Ericsson. • It is used for training purposes only and may not be copied or

reproduced in any manner without the express written consent of Ericsson.

This Student Book, LZT 123 8958, R1A supports course number LZU 108 7261 .


LZT 123 8958 R1A © Ericsson 2009 - 3 -

Table of Contents

1 EPS ARCHITECTURE...................................................................9 OBJECTIVES....................................................................................................9

INTRODUCTION..................................................................................11 SERVICE DOMAIN .........................................................................................12 CORE NETWORK DOMAIN ...........................................................................12 RADIO ACCESS DOMAIN..............................................................................15 USER EQUIPMENT (UE) ...............................................................................17 UU INTERFACE..............................................................................................17

GENERAL PROTOCOL MODEL.........................................................18 CONTROL PLANE/ USER PLANE .................................................................18 RADIO NETWORK LAYER /TRANSPORT NETWORK LAYER ....................19 X2 INTERFACE ..............................................................................................20 S1 INTERFACE ..............................................................................................21

RAN INTERFACES..............................................................................23 TN INTERFACES............................................................................................24

2 EPS PROTOCOL WALKTHROUGH...........................................27 OBJECTIVES..................................................................................................27

INTRODUCTION..................................................................................29 TRAFFIC CASE EXAMPLE: TRACKING AREA UPDATE .............................30 NON-ACCESS STRATUM (NAS) ...................................................................33 RADIO RESOURCE CONTROL (RRC)..........................................................33 PACKET DATA CONVERGENCE PROTOCOL (PDCP) ...............................34 RADIO LINK CONTROL (RLC).......................................................................35 MEDIUM ACCESS CONTROL (MAC)............................................................35 PROTOCOL INTERACTION...........................................................................36 L1- PHYSICAL LAYER ...................................................................................37

3 QUALITY OF SERVICE...............................................................39 OBJECTIVES..................................................................................................39

QOS (QUALITY OF SERVICE) IN GENERAL TERMS .......................41 QUALITY OF SERVICE CLASS IDENTIFIER ................................................47


- 4 - © Ericsson 2009 LZT 123 8958 R1A

LTE QOS HANDLING ..........................................................................51

4 RADIO RESOURCE CONTROL PROTOCOL ............................55 OBJECTIVES..................................................................................................55

RADIO RESOURCE CONTROL PROTOCOL.....................................57 ECM/EMM AND RRC STATE.........................................................................58 RRC FUNCTIONS AND SERVICES PROVIDED TO UPPER LAYERS ........61 RRC MESSAGES ...........................................................................................62

RRC FUNCTIONS AND PROCEDURES.............................................63 BROADCAST OF SYSTEM INFORMATION..................................................63 IDLE MODE TASKS........................................................................................67 CELL SELECTION..........................................................................................69 CELL RESELECTION PROCESS ..................................................................70 PAGING ..........................................................................................................71 ESTABLISHMENT, MAINTENANCE AND RELEASE OF RRC CONNECTION ................................................................................................74

TRAFFIC CASES:................................................................................81 ATTACH REQUEST .......................................................................................81 CONNECTION REACTIVATION ....................................................................84 RRC MOBILITY MANAGEMENT....................................................................86 MEASUREMENT CONFIGURATION .............................................................87 MEASUREMENT REPORTING......................................................................89

5 PACKET DATA CONVERGANCE PROTOCOL.........................91 OBJECTIVES..................................................................................................91

PACKET DATA CONVERGENCE PROTOCOL (PDCP) .....................93 SEQUENCE NUMBERING .............................................................................96 HEADER COMPRESSION AND DECOPMPRESSION .................................96 SECURITY HANDLING ..................................................................................98 PDCP PDU FORMATS .................................................................................102

6 RADIO LINK CONTROL (RLC) AND MEDIUM ACCESS CONTROL (MAC) PROTOCOLS ..............................................105

OBJECTIVES................................................................................................105

RADIO LINK CONTROL PROTOCOL...............................................107 RLC TM ENTITY ...........................................................................................109


LZT 123 8958 R1A © Ericsson 2009 - 5 -

RLC UM ENTITY...........................................................................................110 RLC AM ENTITY...........................................................................................111 RLC PDU ......................................................................................................113

MEDIUM ACCESS CONTROL PROTOCOL .....................................124 MAPPING BETWEEN LOGICAL CHANNELS AND TRANSPORT CHANNELS...................................................................................................126 MULTIPLEXING AND ASSEMBLY...............................................................130 MAC PDU......................................................................................................131

MAC PROCEDURES.........................................................................135 RANDOM ACCESS ......................................................................................135 UPLINK TIMING ALLIGNMENT MAINTENANCE ........................................137 DL/UL SCH DATA TRANSFER USING HARQ OPERATION ......................138 PCH RECEPTION.........................................................................................139 BCH RECEPTION.........................................................................................139 DATA FLOW AND MULTIPLEXING .............................................................140

7 S1 APPLICATION PROTOCOL – S1 AP..................................141 OBJECTIVES................................................................................................141

S1 INTERFACE..................................................................................143 S1 CONTROL PLANE ..................................................................................143 S1 USER PLANE ..........................................................................................144 S1 PROTOCOL MODEL...............................................................................145

FUNCTIONS OF S1AP ......................................................................149

S1AP ELEMENTARY PROCEDURES...............................................152

E-RAB MANAGEMENT PROCEDURES...........................................154 E-RAB SETUP ..............................................................................................154 E-RAB MODIFY ............................................................................................157 E-RAB RELEASE..........................................................................................160

CONTEXT MANAGEMENT PROCEDURES .....................................163 INITIAL CONTEXT SETUP...........................................................................163 UE CONTEXT RELEASE REQUEST ...........................................................166 UE CONTEXT MODIFICATION....................................................................168

HANDOVER SIGNALING ..................................................................170


- 6 - © Ericsson 2009 LZT 123 8958 R1A

HANDOVER PREPARATION .......................................................................170 HANDOVER RESOURCE ALLOCATION.....................................................174 HANDOVER NOTIFICATION .......................................................................177 PATH SWITCH REQUEST ...........................................................................178 HANDOVER CANCELLATION .....................................................................180 ENODE B STATUS TRANSFER ..................................................................181 MME STATUS TRANSFER ..........................................................................182

PAGING .............................................................................................183

NAS TRANSPORT.............................................................................184 DL/UL NAS TRANSPORT ............................................................................185 NAS NON DELIVERY INDICATION .............................................................186

MANAGEMENT PROCEDURES .......................................................187 RESET ..........................................................................................................187 ERROR INDICATION ...................................................................................189 S1 SETUP.....................................................................................................190 ENODE B CONFIGURATION UPDATE .......................................................192 MME CONFIGURATION UPDATE ...............................................................194

OVERLOAD START/STOP................................................................196

S1 CDMA2000 TUNNELING PROCEDURES ...................................197

UE CAPABILITY INFO INDICATION .................................................199

TRACE PROCEDURES.....................................................................200 TRACE START/TRACE FAILURE INDICATION/DEACTIVATE TRACE .....200

LOCATION REPORTING PROCEDURES.........................................202 LOCATION REPORTING CONTROL/LOCATION REPORT FAILURE .......202

WARNING MESSAGE TRANSMISSION PROCEDURES.................204 WRITE REPLACE WARNING ......................................................................204

ENODE B DIRECT INFORMATION TRANSFER ..............................206

MME DIRECT INFORMATION TRANSFER ......................................207

ENODE B CONFIGURATION TRANSFER........................................208

MME CONFIGURATION TRANSFER................................................209


LZT 123 8958 R1A © Ericsson 2009 - 7 -

8 X2 APPLICATION PROTOCOL – X2 AP..................................211 OBJECTIVES................................................................................................211

X2 INTERFACE..................................................................................213 X2 PROTOCOL MODEL...............................................................................214 X2 USER PLANE ..........................................................................................215 X2 CONTROL PLANE ..................................................................................216

FUNCTIONS OF X2 AP .....................................................................219 INTRA LTE-ACCESS-SYSTEM MOBILITY SUPPORT FOR ECM-CONNECTED UE .........................................................................................219 LOAD MANAGEMENT..................................................................................220 INTER-CELL INTERFERENCE COORDINATION .......................................220 GENERAL X2 MANAGEMENT AND ERROR HANDLING FUNCTIONS.....220 TRACE FUNCTIONS ....................................................................................221 APPLICATION LEVEL DATA EXCHANGE BETWEEN ENBS.....................221

X2AP ELEMENTARY PROCEDURES...............................................222

BASIC MOBILITY PROCEDURES ....................................................223 HANDOVER PREPARATION .......................................................................223 SN STATUS TRANSFER..............................................................................226 UE CONTEXT RELEASE .............................................................................228 HANDOVER CANCEL ..................................................................................229

GLOBAL PROCEDURES ..................................................................230 LOAD INDICATION.......................................................................................230 X2 SETUP.....................................................................................................231 RESET ..........................................................................................................233 ENODE B CONFIGURATION UPDATE .......................................................234

RESOURCE STATUS REPORTING ..................................................237 INITIATION ...................................................................................................237 RESOURCE STATUS REPORTING ............................................................239

9 AUTO CONFIGURATION OF THE ENODEB ...........................241 OBJECTIVES................................................................................................241

AUTOCONFIGURATION OF THE E NODEB ....................................243

10 MOBILITY..................................................................................245


- 8 - © Ericsson 2009 LZT 123 8958 R1A

OBJECTIVES................................................................................................245

MOBILITY ..........................................................................................247 X2 HANDOVER ............................................................................................248 S1 HANDOVER ............................................................................................261

INTERWORKING WITH 2G/3G .........................................................266

11 APPENDIX.................................................................................271

S1 BASED HANDOVER ....................................................................274

E-UTRAN TO UTRAN IU MODE INTER RAT HO, ............................275 PREPARATION PHASE ...............................................................................275 EXECUTION PHASE ....................................................................................276

E-UTRAN TO GERAN A/GB MODE INTER RAT HANDOVER.........277 PREPARATION PHASE ...............................................................................277 EXECUTION PHASE ....................................................................................278

RNTI ...................................................................................................279

SECURITY .........................................................................................280

12 ABBREVIATIONS .....................................................................283


LZT 123 8958 R1A © Ericsson 2009 - 9 -

1 EPS Architecture

OBJECTIVES

After this chapter the participants will be able to:1. Explain the EPS architecture.

2. State the main functions of the network elements.

3. List the interfaces.

Figure 1-1: Objectives


- 10 - © Ericsson 2009 LZT 123 8958 R1A

Intentionally Blank


LZT 123 8958 R1A © Ericsson 2009 - 11 -

INTRODUCTION In order to be able to understand signaling lets look first into the Evolved Packet System (EPS) architecture.

Any telecom system consists of a number of logical network elements where each element has well defined functionality. These logical network elements are connected through a number of open interfaces. In order to be defined as an open interface requirements have to be defined in such a detail that enables two network elements from different vendors to operate.

Functionality of the network elements is grouped in several domains:

UE Domain

Radio Access Network Domain (LTE)

Core Network Domain (SAE)

Service Domain (IMS)

PCRF

X2-UP

S1-UP

EPC

S1-CP

E-UTRAN

eNodeBeNodeBeNodeBeNodeB

S11MME

S-GW

P-GW

S5/S8

X2-CP

P-CSCF

S7/Gx

Network & Service management

OSS-RC EMA

MM DNS/ENUM

HSS

S-CSCF

I-CSCFIMS Control layer

Platforms / Concepts

TSP/NSP or TSP/IS

DNS/ENUM

MGC

MGW

SUN

IS

A-SBG

CPP /RBS6000

Juniper/Redback

WPP

GERAN UTRAN

Broadband Wired Access

GPRS Packet Core

SGSN

GGSN

CDMA2000HRPD

(EV-DO)

WLAN

N-SBG

Internet

S6a

CS Core

MSC

GWMSC

PSTN

PDSN

S1-AP, X2-APH.248

ISUP

Diameter

S3

S4

GTP-C

Gxa

S103

S2a

RNCOther

SIP/UDP or SIP/TCP

Rx+

User dataRTP/UDP GTP/UDP

S101

IMS Connectivitylayer

Service LayerAS AS ASApplication ServersMTAS

S6d

Uu

Figure 1-2: Overall Architecture


- 12 - © Ericsson 2009 LZT 123 8958 R1A

Figure 1-2 Overall Architecture illustrates listed domains and their relationship.

SERVICE DOMAIN

IP Multimedia Subsystem (IMS) is defined by 3GPP/3GPP2 as a core and service 'domain' that enables the convergence of data, speech and network technology over an IP-based infrastructure.

It is the operator choice of control and service logic for primarily IP/packet-based person-to-person communication but also for person-to-content communication.

For users, IMS-based services will enable communications in a variety of modes – including voice, text, pictures and video, or any combination of these – in a highly personalized and secure way.

IMS is designed to fill the gap between the existing traditional telecommunications technology and internet technology that increased bandwidth alone does not provide. This allows operators to offer new, innovative.

CORE NETWORK DOMAIN

Core Network Domain is referred as Evolved Packet Core (EPC) and consists of following network elements:

The Home Subscriber Server (HSS)

The HSS is the master database for an operator. It is the entity containing the subscription-related information to support the network entities actually handling calls/sessions.

A Home Network may contain one or several HSSs: it depends on the number of mobile subscribers, on the capacity of the equipment and on the organisation of the network.

As an example, the HSS provides support to the call control servers in order to complete the routing/roaming procedures by solving authentication, authorisation, naming/addressing resolution, location dependencies, etc.


LZT 123 8958 R1A © Ericsson 2009 - 13 -

The HSS is responsible for holding the following user related information: • User identification, numbering and addressing information

• User security information: Network access control information for authentication and authorization

• User Location information at inter-system level: the HSS supports the user registration, and stores inter-system location information, etc.

• User profile information.

The HSS also generates User Security information for mutual authentication, communication integrity check and ciphering.

Based on this information, the HSS also is responsible to support the call control and session management entities of the different domains and subsystems of the operator.

Mobility Management Entity MME

MME is the control plane entity within EPS supporting following functions:

Mobility Management: • NAS signalling and security

• Inter CN node signalling for mobility between 3GPP access networks

• Tracking Area list management

• PDN GW and Serving GW selection

• SGSN selection for handovers to 2G or 3G 3GPP access networks

• Roaming

• Authentication

• Bearer management functions including dedicated bearer establishment

• Lawful interception of signalling traffic

• Initiating IMSI detach at EPS detach

• Initiating paging procedure towards eNodeB when MSC pages the UE for CS services

• Supporting SMS procedures for CS fallback.


- 14 - © Ericsson 2009 LZT 123 8958 R1A

• Support CS fallback interface and related functions for CDMA access.

Serving GW

The Serving GW is the gateway which terminates the interface towards E-UTRAN.

For each UE associated with the EPS, at a given point of time, there is a single Serving GW. Some functions of the Serving GW are listed: • the local Mobility Anchor point for inter-eNodeB handover

• Mobility anchoring for inter-3GPP mobility

• ECM-IDLE mode downlink packet buffering and initiation of network triggered service request procedure

• Lawful interception

• Packet routing and forwarding

• Transport level packet marking in the uplink and the downlink

• Accounting on user and QCI granularity for inter-operator charging

• A local non-3GPP anchor for the case of roaming when the non-3GPP IP accesses connected to the VPLMN

• Event reporting (change of RAT, etc.) to the PCRF

• Uplink and downlink bearer binding towards 3GPP accesses

• Uplink bearer binding verification with packet dropping of "misbehaving UL traffic"

Packet Data Network Gateway PDN GW

The PDN GW is the gateway which terminates the SGi interface towards the PDN.

The P GW provides PDN connectivity to both GERAN/UTRAN only UEs and E UTRAN capable UEs using any of E UTRAN, GERAN or UTRAN. The P GW provides PDN connectivity to E UTRAN capable UEs using E UTRAN only over the S5/S8 interface.


LZT 123 8958 R1A © Ericsson 2009 - 15 -

Some of PDN GW functions include:

• Per-user based packet filtering (by e.g. deep packet inspection)

• Lawful interception

• UE IP address allocation

• Transport level packet marking in the uplink and downlink, e.g. setting the DiffServ Code Point, based on the QCI of the associated EPS bearer

• UL and DL service level charging, gating control, rate enforcement

• UL and DL rate enforcement based on APN-AMBR

• DL rate enforcement based on the accumulated MBRs of the aggregate of SDFs with the same GBR QCI (e.g. by rate policing/shaping)

• DHCPv4 (server and client) and DHCPv6 (client and server) functions

• Additionally the PDN GW includes the following functions for the GTP-based S5/S8

• UL and DL bearer binding

• UL bearer binding verification

• The PDN GW functions also includes user plane anchor for mobility between 3GPP access and non-3GPP access

RADIO ACCESS DOMAIN

Radio Access Domain is referred as Evolved UTRAN. It consists only of a number of eNodeBs (eNB) that are interconnected via X2 interface through an IP network. The eNBs are connected by means of the S1 interface to the EPC (Evolved Packet Core), more specifically to the MME (Mobility Management Entity) by means of the S1-MME and to the Serving Gateway (S-GW) by means of the S1-U interface. The S1 interface supports a many-to-many relation between MMEs / Serving Gateways and eNBs.

Evolved Packet System is another naming that group Evolved Packet Core EPC and E-UTRAN. The standard development in 3GPP is grouped into two working groups: Long Term Evolution (LTE) targeting Radio Access Network and System Architecture Evolution (SAE) targeting Core Network.

LTE/SAE naming is commonly used however it is more accurate to use E-UTRA/EPC.


- 16 - © Ericsson 2009 LZT 123 8958 R1A

eNB eNB

eNB

S1

X2

X2

X2

SAE(System ArchitectureEvolution)

LTE(Long Term Evolution)

EPC (Evolved Packet Core)

E-UTRAN

EPS (Evolved Packet System)

UE

Uu

MME MME

HSS

P/S-GW P/S-GW

S6a

Figure 1-3 EPS Architecture

The objective of this course is E-UTRAN. It explains eNodeB functions, its interaction with UE; X2 and S1 interfaces.

E-UTRAN Node B - eNB

An eNB is a logical network component which serves one or more E-UTRAN Cells. It is responsible for radio transmission and reception from/to UE. Some of eNodeB functionalities are:

• Cell Control and MME pool support:

• Control and User Plane Security

• Segmentation/Concatenation

• Error Correction

• Shared Channel Handling

• Scheduling

• Physical Layer functions such as channel coding, modulation, filtering

• Handling of Measurement Control/Reporting

• Mobility Control

An eNB can support FDD mode, TDD mode or dual mode operation


LZT 123 8958 R1A © Ericsson 2009 - 17 -

Above functions and more will be treated during this course in more details.

USER EQUIPMENT (UE)

The User Equipment allows a user access to network services. For the purpose of 3GPP specifications the interface between the UE and the network is the radio interface.

A User Equipment can be subdivided into a number of domains, the domains being separated by reference points. Currently the User Equipment is subdivided into the Universal Integrated Circuit Card (UICC) domain and the Mobile Equipment (ME) Domain. The ME Domain can further be subdivided into one or more Mobile Termination (MT) and Terminal Equipment (TE) components showing the connectivity between multiple functional groups

UU INTERFACE:

The LTE radio interface is based on OFDM (Orthogonal Frequency Division Multiplex) in DL and SC-FDMA (Single Carrier Frequency Division Multiple Access) in UL. These techniques are well suited for flexible bandwidth operation. This enables operators to deploy LTE in different regions with different frequency bands and bandwidths available. In addition to that, both FDD (Frequency Division Duplex) and TDD (Time Division Duplex) is supported, which opens up for deployment in both paired and unpaired spectrum. In FDD, different frequency bands are used for UL and DL. In TDD the UL and DL transmissions are separated in time.


- 18 - © Ericsson 2009 LZT 123 8958 R1A

GENERAL PROTOCOL MODEL

CONTROL PLANE/ USER PLANE

The protocols over Uu and S1 interfaces are divided into two structures:

Control plane protocols these are the protocols for controlling the E-RABs and the connection between the UE and the network from different aspects (including requesting the service, controlling different transmission resources, handover etc.). Also a mechanism for transparent transfer of NAS messages is included.

User plane protocols these are the protocols implementing the actual E-RAB service, i.e. carrying user data through the access stratum.

(Uu)

EUTRANEUTRANUE EPC

Access Stratum

Non-Access Stratum

Radio S1

Radio Protocols

Radio Protocols

S1Protocols

S1Protocols

EMM, ESM EMM, ESM

These are the protocols for controlling the E-RABs and the connection between the UE and the network from different aspects (including requesting the service, controlling different transmission resources, handover etc.).

Figure 1-4 General Protocol Model – Control Plane UE- MME

General Protocol model for control plane signaling, illustrated in Figure 1-4, can be horizontally be split into signaling between UE and MME so called Non Access Stratum (NAS) signaling and UE and eNB signaling so called Access Stratum signaling. Access Stratum Signaling is implemented using radio protocols and NAS signaling is using both radio and S1 protocols.


LZT 123 8958 R1A © Ericsson 2009 - 19 -

General protocol model for user plane is illustrated Figure 1-5

(Uu)

EUTRANEUTRANUE EPC

Access Stratum

Radio S1

Radio Protocols

Radio Protocols

S1Protocols

S1Protocols

These are the protocols implementing the actual E-RAB service, i.e. carrying user data through the access stratum. Figure 1-5 General Protocol Model- User Plane UE S-GW

RADIO NETWORK LAYER /TRANSPORT NETWORK LAYER

General protocol model for a single interface is illustrated Figure 1-6 using vertical planes: control plane and user plane and horizontal layers: Radio Network Layer and Transport Network Layer.

The structure is based on the principle that the layers and planes are logically independent of each other. Therefore, as and when required, the standardization body can easily alter protocol stacks and planes to fit future requirements.


- 20 - © Ericsson 2009 LZT 123 8958 R1A

ApplicationProtocol

TransportNetwork

Layer

Physical Layer

SignallingBearer(s)

Transport User

NetworkPlane

Control Plane User Plane

Transport User

NetworkPlane

Radio Network

Layer

DataBearer(s)

Figure 1-6 General Protocol Model for RAN Interface

X2 INTERFACE

The X2 interface specifications shall facilitate the following:

– inter-connection of eNBs supplied by different manufacturers;– support of continuation between eNBs of the E-UTRAN services

offered via the S1 interface;– separation of X2 interface Radio Network functionality and

Transport Network functionality to facilitate introduction of future technology

Figure 1-7 X2 Interface

As stated in Figure 1-7 X2 is the interface between eNBs. The main purpose for this interface is to give support to active mode UE mobility so called Packet Forwarding.

As illustrated in Figure 1-8 X2 CP signaling protocol is X2AP and is responsible for: • Mobility Management

• Load Management

• Reporting of general error situations


LZT 123 8958 R1A © Ericsson 2009 - 21 -

X2 is a logical interface with many to many relationship i.e. one eNB can be connected to more that one eNB.

X2-AP

TransportNetworkLayer

GTP-U

UDP

IP

Data link layer

Physical layer

GTP-U

UDP

IP

Data link layer

Physical layer

User PlanePDUs

SCTP

IP

Data link layer

Physical layer

SCTP

IP

Data link layer

Physical layer

RadioNetworkLayer


Transport Network User Plane


Figure 1-8 X2 Interface Protocol Stacks

S1 INTERFACE

The S1 interface specifications shall facilitate the following:procedures between the EPC and E-UTRANconveying messages transparently between the EPC and the UE without interpretation or processing by the E-UTRAN.

– Facilitate a set of general E-UTRAN procedures from the EPC such as paging-notification as defined by the notification SAP.

– Separate each User Equipment (UE) on the protocol level for mobile specific signalling management as defined by the dedicated SAP.

– Transfer of transparent non-access signalling as defined in the dedicated SAP.

– Request of various types of E-RABs through the dedicated SAP.– Perform the mobility function.. Figure 1-9 S1 Interface

As stated in the Figure 1-9 main purpose of S1 interface is to provide connectivity between E-UTRA and EPC i.e. eNB and MME through control plane protocols and eNB and S-GW through user plane protocols.


- 22 - © Ericsson 2009 LZT 123 8958 R1A

S1-AP


GTP-U

UDP

IP

Data link layer

Physical layer

GTP-U

UDP

IP

Data link layer

Physical layer

User PlanePDUs

SCTP

IP

Data link layer

Physical layer

SCTP

IP

Data link layer

Physical layer

RadioNetworkLayer




Figure 1-10 S1 Interface Protocol Stacks

eNB and MME are using S1AP protocol to facilitate: • EPS Bearer Management functions

• Initial Context Transfer functions

• Mobility functions for an active UE

• Paging

• NAS Signaling Transport function

• S1 UE Context Release function

• S1 Interface Management functions (Reset, Overload etc)


LZT 123 8958 R1A © Ericsson 2009 - 23 -

RAN INTERFACES 3GPP is the standardization body that is responsible for creation of technical specifications. It consists of four Technical Specification Groups. TSG RAN is responsible for the standardization of LTE and it is divided into four working groups:

• WG1 is responsible for the Layer 1 in the Uu interface.

• WG2 is responsible for Layers 2 & 3 in the Uu interface.

• WG3 is responsible for X2 and S1 interface.

• WG4 is responsible for radio requirements.

Figure 1-11 3GPP Organization

This book is based on the technical specifications listed in the Figure 1-12.


- 24 - © Ericsson 2009 LZT 123 8958 R1A

36.201 – Physical layer general description36.211 – Physical channels and modulation36.212 – Multiplexing and channel coding 36.213 – Physical layer procedures36.214 – Physical layer measurements

36.300 – E-UTRA overall description36.302 – Services provided by the physical layer36.304 – UE Functions related to idle mode36.306 – UE radio access capabilities36.321 – Medium Access Control (MAC)

Protocol Specification36.322 – Radio Link Control (RLC)

Protocol Specification36.323 – Packet Data convergence Protocol (PDCP)

Protocol Specification 36.331 – Radio Resource Control (RRC)

Protocol Specification

36.101 – UE radio transmission and reception (FDD) 36.104 – BTS radio transmission and reception (FDD)36.113 – Base station EMC 36.133 – Requirements for support of Radio Resource

Management (FDD)36.141 – Base station conformance testing (FDD)

36.401 – E-UTRA Architecture Description36.410 – S1 interface general aspects & principle36.411 – S1 interface Layer 136.412 – S1 interface signalling transport36.413 – S1 application protocol S1AP36.414 – S1 interface data transport 36.420 – X2 interface general aspects and principles36.421 – X2 interface layer136.422 – X2 interface signalling transport36.423 – X2 interface application part X2AP36.442 – UTRAN Implementation Specific O&M Transport

All specifications can be found on the web site www.3gpp.org

23.002 – Network Architecture23.003 – Numbering, addressing and identification 23.009 – Handover Procedures23.048 – Security mechanisms for USIM application23.401 – GPRS enhancements for eUTRA23.907 – QoS Concept

24.301 – NAS Protocol for Evolved Packet System (EPS)24.302 – Access to the EPC via non 3GPP networks

33.401 – System Architecture Evolution (SAE); Security Architecture

Figure 1-12 Selection of the technical specifications used in this book

TN INTERFACES

Control Plane

As it can be seen from the protocol stacks for X2 Figure 1-8 and S1 Figure 1-10 both interfaces are using same control plane and same user plane stacks.

Both X2AP and S1AP are users of the Stream Controlled Transfer Protocol.

The Stream Controlled Transmission Protocol (SCTP) is a reliable protocol. It provides a connection-oriented signaling between SCTP end points by the means of SCTP associations. An SCTP endpoint is defined by the SCTP transport address which consists of one or more IP address and an SCTP port. Multihoming (multiple IP addresses for a single node) is an essential property of the SCTP that provides a reliable connection between two SCTP end nodes.


LZT 123 8958 R1A © Ericsson 2009 - 25 -

SCTP provides the following:

• Acknowledged error-free non-duplicated transfer of data

• Detection of data corruption, loss of data and duplication of data

• Selective retransmission mechanism to correct loss or corruption of data

SCTP provides a general-purpose transport protocol for message-oriented applications such as signaling operating on top of a connectionless packet service such as IP.

User Plane

Both X2 and S1 are using GPRS Tunneling Protocol – User (GTP-U) protocol to transfer user data.

The GTP-U protocol entity provides packet transmission and reception services to user plane entities in the eNB, SGW and PDN-GW. The GTP-U protocol entity receives traffic from a number of GTP-U tunnel endpoints and transmits traffic to a number of GTP-U tunnel endpoints. There is a GTP-U protocol entity per IP address.

The TEID in the GTP-U header is used to de-multiplex traffic incoming from remote tunnel endpoints so that it is delivered to the User plane entities in a way that allows multiplexing of different users, different packet protocols and different QoS levels.

Transport Layer Protocols are standardized by Internet Engineering Task Force (IETF). More information can be found at www.ietf.org.


- 26 - © Ericsson 2009 LZT 123 8958 R1A

Intentionally Blank


LZT 123 8958 R1A © Ericsson 2009 - 27 -

2 EPS Protocol Walkthrough

OBJECTIVES

After this chapter the participants will be able to:1. Explain how the signaling takes place between the UE and the

EPC

2. State the main functions of Radio Resource Control (RRC), Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), Medium Access Control (MAC), the physical layer

3. Explain the interaction of the eUTRAN protocols and the mapping of logical, transport and physical channels Figure 2-1 Objectives


- 28 - © Ericsson 2009 LZT 123 8958 R1A

Intentionally Blank


LZT 123 8958 R1A © Ericsson 2009 - 29 -

INTRODUCTION

When the UE needs to contact the network; triggered either by system information (Tracking Area Update), or by a timer expiring (Periodic Registration), or by a paging message (Mobile Terminating) received, or the UE wants to initiate a call setup (Mobile Originating), a signaling connection needs to be set up. Signaling connection is further realized by setting up Signaling Radio Bearer and S1AP signaling connection. Further Signaling Radio Bearer is mapped to Logical Channel that is mapped to the Transport Channel that is mapped to Physical Channel

Lets start from the beginning!

In the Figure 2-2 and Figure 2-3 details of the protocol stacks for control plane and user plane signaling are illustrated

L2

L1

IP

SCTP

S1-MMEMME

S1-AP

NAS

SCTP

L2

L1

IP

eNodeB

S1- AP

MACRLC

PDCPRRC

Relay

MAC

L1

RLC

PDCP

UE

RRC

NAS

Uu

L1

Figure 2-2 UE-MME Control Plane Protocol Stacks

Serving GW PDN GW

S5/S8

UDP/IP UDP/IP

L2L2

L1 L1

UDP/IP

L2

L1

GTP-U

IP

SGiS1-UUu

eNodeB

RLC

L2

PDCP

MAC

L1 L1

PDCP

RLC

MAC

L1

IP

Application

UE

UDP/IP

GTP-URelay

GTP-URelay

GTP-U

Figure 2-3 UE-PGW User Plane Protocol Stack


- 30 - © Ericsson 2009 LZT 123 8958 R1A

Lets look into a traffic case Tracking Area Update. Definition of a traffic case is exchange of signals between two entities. What nodes are involved in the traffic case? What kind of information needs to be exchanged over the different interfaces? These are only two of many questions we in this course are going to find an answer to. To be able to understand the kind of signaling messages that need to be sent and how they are transmitted over the interfaces, there is a need to define a protocol and the purpose of a layered structure of protocols, that is, a protocol stack, in each node see again figures above.

TRAFFIC CASE EXAMPLE: TRACKING AREA UPDATE

The network knows the location of a UE that is roaming within a network. This makes it possible for the mobile subscriber to receive a call wherever it is. To keep the network up to date with the subscriber’s location, the UE performs location updating.

TA1TA1

TA4TA4TA3TA3

TA2TA2

UE’s belong to multiple TA1. UE belongs to TA1, TA3 and TA2.

The UE can move within TA1, TA2 and TA3 without TA update.

2. The UE will perform a TA update when moving to a cell withinTA4.

3. After succesful TA update in TA4 the UE will belong to TA2, TA3 and TA4

MMETA Update

TA list 1: TA list 2: ..........- TA1 - TA2- TA2 - TA3- TA3 - TA4

TA Update

confirm

Figure 2-4 Tracking Area Concept

The location of a UE in LTE_IDLE mode is maintained on a Tracking Area (TA) List level. In SAE/LTE there is only one common Intra-LTE TA concept defined both for the RAN and for the CN ,Figure 2-4. When a UE in LTE_IDLE mode moves into a cell that belongs to a TA different from the one(s) it is currently registered with, it performs a TA Update. The cell tracking area is broadcast in System Information


LZT 123 8958 R1A © Ericsson 2009 - 31 -

HSS

2. System Information

8. MME-initiated Connection Release

1. Cell re-selection

3. RRC Connection EstablishmentNAS Message =” TAU Request”

4. Initial UE MessageTAI, NAS message ”TAU Request”

6. Downlink NAS Signalling TransferNAS Message =”TAU Accept”

Conditional:5. Authentication and NAS Security Activation

Conditional:7. Uplink NAS Signalling TransferNAS Message =”TAU Complete”

MME GW

Figure 2-5 Traffic Case Tracking Area Update (Simplified- more details in the RRC Chapter))

1. The UE performs cell re-selection (typically based on system information received in the previous cell).

2. The UE reads the System Information, broadcast in the selected cell.

4. If the TA that the cell belongs is not the TA that the UE is registered in, the RRC Connection is established, with the NAS message “Tracking Area Update (TAU) Request”.

5. The Tracking Area Update (TAU) Request message is provided to the MME in the “Initial UE Message”.

6. Conditional step: If the integrity protection check fails the MME performs authentication and activates the NAS security functions using the Authentication and NAS Security Activation procedure.

7. The MME sends the NAS message “Tracking Area Update (TAU) Accept” to the UE, using the DL NAS Signalling Transfer procedure.

8. If the GUTI has been re-allocated, the NAS message “Tracking Area Update (TAU) Complete” is transferred to the MME, using the UL NAS Signalling Transfer procedure


- 32 - © Ericsson 2009 LZT 123 8958 R1A

9. Since the MME did not establish any bearers or user plane connection1, the MME releases the radio connection (and RAN resources) by the MME-initiated Connection Release.

More details about signaling will be provided during RRC Chapter

In order to send a Non Access Stratum Message Tracking Area Update from UE to MME a whole set of different entities needs to be established. It is easier to identify them if we have a look into the UE Protocol Stack in Figure 2-6

ROHC/Ciphering

TM AM UM

Physical Layer

L2

PDCP

RLC

MAC

RRC

NAS

Integrity/Ciphering

System InfoAquisition

Cell Selection

Paging Reception

Mobility Management

Session Management

Connected Mode

Mobility

NAS Security

IP

Application

AS Security RRC Connection

RB Managementv

Measurement Reporting

Con

trol/R

epor

t SA

Ps

RA Control HARQControl

Figure 2-6 UE Protocol Stack

1 Typically triggered by the “Active Flag” set to “Yes” in the NAS message “Tracking Area Update (TAU) Request”.


LZT 123 8958 R1A © Ericsson 2009 - 33 -

NON-ACCESS STRATUM (NAS)

The NAS consists of the Session Management (SM) and EPS Mobility Management (EMM) layers. The following are examples of functions are performed by NAS: • Mobility management for idle UEs

• UE Authentication

• EPS bearer management

• Configuration and control of Security

• Paging initiation for idle UEs

The NAS messages are transported by the RRC layer. There are two ways to transport the NAS messages by RRC, either by concatenating the NAS messages with other RRC messages, or by including the NAS messages in dedicated RRC messages without concatenation.

NAS messages are protected using the ciphering and integrity protection services provided by the PDCP layer. However, NAS is also protected by its own security functions terminated in the UE and MME, respectively.

On the network side, the NAS layers are in 3GPP agreed to be terminated by the MME.

RADIO RESOURCE CONTROL (RRC)

The following control plane functions are agreed in 3GPP to be performed by the Radio Resource Control (RRC) layer: • Broadcast of System Information related to the non-access

stratum

• Broadcast of System Information related to the access stratum

• Paging

• Establishment, maintenance and release of an RRC connection between the UE and E-UTRAN including:

o Allocation of temporary identifiers between UE and E-UTRAN

o Configuration of radio resources for RRC connection including SRBs

• Establishment, maintenance and release of point to point Radio Bearers


- 34 - © Ericsson 2009 LZT 123 8958 R1A

• Mobility functions including:

o UE measurement reporting and control of the reporting for inter-cell and inter-RAT mobility

o Inter-cell handover

o UE cell selection and reselection and control of cell selection and reselection;

o UE Context transfer between eNBs.

• Notification for MBMS services (FFS in 3GPP)

• Establishment, configuration, maintenance and release of Radio Bearers for MBMS services (FFS in 3GPP)

• QoS management functions. (Note: These functions are spread across multiple layers)

• UE measurement reporting and control of the reporting

• MBMS control (FFS in 3GPP)

• NAS direct message transfer to/from NAS from/to UE.

On the network side, the RRC layer is in 3GPP agreed to be terminated by the eNB.

PACKET DATA CONVERGENCE PROTOCOL (PDCP)

PDCP provides its services to the NAS / RRC at the UE or the relay at the evolved Node B (eNB).

The Packet Data Convergence Protocol supports the following functions: • header compression and decompression of IP data flows using

the ROHC (Robust Header Compression) protocol, at the transmitting and receiving entity, respectively.

• transfer of data (user plane or control plane). This function is used for conveyance of data between users of PDCP services.

• maintenance of PDCP sequence numbers for radio bearers for radio bearers mapped on RLC acknowledged mode.

• in-sequence delivery of upper layer PDUs at Handover

• duplicate elimination of lower layer SDUs at Handover for radio bearers mapped on RLC acknowledged mode

• ciphering and deciphering of user plane data and control plane data

• integrity protection of control plane data

• timer based discard


LZT 123 8958 R1A © Ericsson 2009 - 35 -

PDCP uses the services provided by the Radio Link Control (RLC) sublayer.

RADIO LINK CONTROL (RLC)

The RLC protocol supports an unacknowledged (UM) and an acknowledged mode (AM). Whether UM or AM is used is configured per radio bearer. For example, UM could be used for VoIP while AM is used to carry TCP-based traffic. An RLC transparent mode exists as well, but it shall be only used to send RRC messages when no RLC UM or AM entity is set up, yet.

MEDIUM ACCESS CONTROL (MAC)

The MAC layer for the LTE access can be compared to the Rel-6 MAC-hs/MAC-e and covers mainly similar functionality: HARQ, priority handling (scheduling), transport format selection and DRX control (not part of MAC in Rel-6).

MAC is responsible for • UL/DL Scheduling

• Link Adaptation

• Preamble based Random Access

• Mapping between Logical channels to Transport channels

• Error Correction by means of The Hybrid ARQ (HARQ) protocol.


- 36 - © Ericsson 2009 LZT 123 8958 R1A

PROTOCOL INTERACTION

The dependencies between protocols and their interaction is illustrated in Figure 2-7 below.

Segmentation, ARQ

Ciphering

Header Compr.

Hybrid ARQHybrid ARQ

MAC multiplexing

Antenna and resrouce mapping

Coding + RM

Data modulation

Antenna and resource mapping

Coding

ModulationAntenna and resource assignment

Modulationscheme

MA

C s

ched

uler

Retransmission control

Priority handling, payload selection

Payload selection

RLC#i

PHY

PDCP#i

User #i User #j

MAC

Concatenation, ARQ

Deciphering

Header Compr.

Hybrid ARQHybrid ARQ

MAC demultiplexing

Antenna and resrouce mapping

Coding + RM

Data modulation

Antenna and resource demapping

Decoding

Demodulation

RLC

PHY

PDCP

MAC

eNodeB UER

edun

danc

y ve

rsio

n

IP packet IP packet

EPS bearers

E-UTRA Radio Bearers

Logical Channels

Transport Channels

Physical Channels

Figure 2-7 Protocol interaction


LZT 123 8958 R1A © Ericsson 2009 - 37 -

L1- PHYSICAL LAYER

Physical Layer is responsible for the actual transmission over the radio interface. It is also responsible for channel coding (Cyclic Redundancy Check, Turbo Coding) Modulation and the mapping between Transport Channels to Physical Channels as can be seen in Figure 2-8.

UL-SCHPCHPCH DL-SCH

PCCHPCCH Logical Channels “type of information”(traffic/control)

Transport Channels“how and with what characteristics”(common/shared/mc/bc)

Downlink Uplink

PDSCHPDSCH

Physical Channels“bits, symbols, modulation, radio frames etc”

MTCHMTCH MCCHMCCH BCCHBCCH DTCHDTCH DCCHDCCH DTCHDTCH DCCHDCCH CCCHCCCH

PRACHPRACH

RACHRACH

CCCHCCCH

MCH BCH

PUSCHPUSCHPBCHPBCH PCFICHPCFICH PUCCHPUCCH

-CQI -ACK/NACK-Sched req.

-Sched TF DL-Sched grant UL-Pwr Ctrl cmd-HARQ info

MIB SIB

PMCHPMCH PHICHPHICHPDCCHPDCCH

ACK/NACKPDCCH

info

Physical Signals“only L1 info”RSRS SRSSRSP-SCHP-SCH S-SCHS-SCH RSRS

-meas for DL sched -meas for mobility-coherent demod

-half frame sync-cell id

-frame sync-cell id group -coherent demod

-measurements for UL scheduling

Figure 2-8 Channel Mapping


- 38 - © Ericsson 2009 LZT 123 8958 R1A

Intentionally Blank


LZT 123 8958 R1A © Ericsson 2009 - 39 -

3 Quality of Service

OBJECTIVES

After this chapter the participants will be able to:1. Explain the concept of Quality of Service

2. Explain the purpose of EPS Bearer Services and eUTRA Radio Bearers

3. List the different attributes of the eUTRA Radio Bearer and explain how they are used

Figure 3-1 Objectives


- 40 - © Ericsson 2009 LZT 123 8958 R1A

Intentionally Blank


LZT 123 8958 R1A © Ericsson 2009 - 41 -

QOS (QUALITY OF SERVICE) IN GENERAL TERMS Terms for QoS are defined in the CCITT Recommendation E.880.

Quality of service: How the subscriber is satisfied with the overall service

Accessibility: To be able to get in contact with the network

Retainability: To continue the connection with the network until all tasks are successfully terminated

Service Integrity: To be able to perform a service and to keep the quality of the connection on a level, where the information can successfully be exchanged in the shortest possible time

Support Performance: The ability of the operator to provide the service and to use its utilization

Operability Performance: The ability of a service to be successfully and easily used by the user

Security: EIR, secure billing, no unauthorized monitoring, TMSI, etc.

User (subscriber)

Serviceintegrity

Qualityof service

Service support

performance

Serviceoperability

performance

Serviceaccessibilityperformance

Serviceretainabilityperformance

Serveability performance

Provider (operator)

Service security

performance

Quality of Service

Network Performance

User (subscriber)

ServiceintegrityServiceintegrity

Qualityof serviceQuality

of service

Service support

performance

Service support

performance

Serviceoperability

performance

Serviceoperability

performance





Serveability performance

Provider (operator)

Service security

performance

Service security

performance

Quality of Service

Network Performance

Figure 3-2. How is Network QoS defined?.


- 42 - © Ericsson 2009 LZT 123 8958 R1A

Accessibility:– To be able to get in contact with the network

Retainability:– To continue the connection with the network until all tasks are

successfully terminatedService Integrity:

– To be able to perform a service and to keep the quality of the connection on a level, where the information can successfully beexchanged in the shortest possible time

Support Performance:– The ability of the operator to provide the service and to use its

utilization Operability Performance:

– The ability of a service to be successfully and easily used by the userSecurity:

– EIR, secure billing, no unauthorized monitoring, TMSI, etc. Figure 3-3. QoS: How the user is satisfied with the overall service.

Security (Figure 3-4.) is one of the aspects of the quality of service that provides User Identity confidentiality by using network generated temporary id(S_TMSI) instead of permanent id (IMSI) . Authentication is becomes very important once billing issues are discussed.

User identity confidentiality– The permanent user identity (IMSI), the location of the user and the

delivered servives to a user cannot be eavesdropped by a third party– Ensured by a temporary user identity (S-TMSI) plus ciphering of the

control plane signalling

Authentication– User is the one claimed– Network is the one claimed– Ensured by an authentication procedure invoked by the network

Typically at each connection setupThe security keys are derived locally in the UE and MME as side-effect of the authentication procedure

Figure 3-4 Security


LZT 123 8958 R1A © Ericsson 2009 - 43 -

Data confidentiality is enabled by having data encryption and integrity protection ensures that the control signalling can not be modified by third party. Integrity protection and ciphering are implemented both in PDCP protocol providing traffic security for the radio interface and on NAS level providing S1 and X2 security.

Data confidentiality– User data and control signalling can not be overheard by a third

party– Ensured by ciphering (C) of user data and control signalling

Data integrity– Control signalling cannot be modified/deleted or inserted by a

third party– Ensured by integrity protection (IP) of control signalling

CIPC

C C

IP

IP IP

Figure 3-5. Security(2).

For E-UTRAN access to the EPC the PDN connectivity service is provided by an EPS bearer. An EPS bearer uniquely identifies traffic flows that receive a common QoS treatment between a UE and a PDN GW.


- 44 - © Ericsson 2009 LZT 123 8958 R1A

P-GWS-GW PeerEntity

UE eNB

EPS Bearer

Radio Bearer S1 Bearer

End-to-end Service

External Bearer

Radio S5/S8

Internet

S1

E-UTRAN EPC

Gi

E-RAB S5/S8 Bearer

Figure 3-6. Bearer concept.

The packet filters signalled in the NAS procedures are associated with a unique packet filter identifier on per-PDN connection basis.

An EPS bearer is the level of granularity for bearer level QoS control in the EPC/E-UTRAN. That is, all traffic mapped to the same EPS bearer receive the same bearer level packet forwarding treatment (e.g. scheduling policy, queue management policy, rate shaping policy, RLC configuration, etc.). Providing different bearer level packet forwarding treatment requires separate EPS bearers

One EPS bearer is established when the UE connects to a PDN, and that remains established throughout the lifetime of the PDN connection to provide the UE with always-on IP connectivity to that PDN. That bearer is referred to as the default bearer. Any additional EPS bearer that is established for the same PDN connection is referred to as a dedicated bearer. The distinction between default and dedicated bearers is transparent to the access network (E-UTRAN )


LZT 123 8958 R1A © Ericsson 2009 - 45 -

For of E-UTRAN, the decision to establish or modify a dedicated bearer can only be taken by the EPC, and the bearer level QoS parameter values are always assigned by the EPC. Therefore, the MME shall not modify the bearer level QoS parameter values received on the S11 reference point during establishment or modification of a dedicated bearer. Instead, the MME shall only transparently forwards those values to the E-UTRAN. Consequently, "QoS negotiation" between the E-UTRAN and the EPC during dedicated bearer establishment / modification is not supported. The MME may, however, reject the establishment or modification of a dedicated bearer

An EPS bearer is referred to as a GBR bearer if dedicated network resources related to a Guaranteed Bit Rate (GBR) value that is associated with the EPS bearer are permanently allocated (e.g. by an admission control function in the eNodeB) at bearer establishment/modification. Otherwise, an EPS bearer is referred to as a Non-GBR bearer.

NOTE 5: Admission control can be performed at establishment / modification of a Non-GBR bearer even though a Non-GBR bearer is not associated with a GBR value.

A dedicated bearer can either be a GBR or a Non-GBR bearer. A default bearer shall be a Non-GBR bearer.

NOTE 6: A default bearer provides the UE with IP connectivity throughout the lifetime of the PDN connection. That motivates the restriction of a default bearer to bearer type Non-GBR.

Serving GW PDN GWeNBRadio Bearer S5/S8 Bearer

Application / Service Layer

UL-TFT → RB-ID

DL Traffic Flow Aggregates

DL-TFT

DL-TFT S5/S8-TEID RB-ID ↔S1-TEID

S1 Bearer

S1-TEID S5/S8-TEID

UE

UL Traffic Flow Aggregates

UL-TFT

Serving GW PDN GWeNodeB

→

UE

↔

EPS Bearer = RB id + S1 TEID+ S5/8 TEIDEPS Bearer = RB id + S1 TEID+ S5/8 TEID

EPS Bearer = RB id + S1 TEID+ S5/8 TEIDEPS Bearer = RB id + S1 TEID+ S5/8 TEID

TS 23.401

Figure 3-7 Two unicast EPS Bearers.


- 46 - © Ericsson 2009 LZT 123 8958 R1A

An EPS bearer is realized by the following elements:

- In the UE, the UL TFT maps a traffic flow aggregate to an EPS bearer in the uplink direction;

- In the PDN-GW, the DL TFT maps a traffic flow aggregate to an EPS bearer in the downlink direction;

- A radio bearer transports the packets of an EPS bearer between a UE and an eNodeB. If a radio bearer exists, there is a one-to-one mapping between an EPS bearer and this radio bearer;

- An S1 bearer transports the packets of an EPS bearer between an eNodeB and a Serving GW;

- An E-RAB (E-UTRAN Radio Access Bearer) refers to the concatenation of an S1 bearer and the corresponding radio bearer.

- An S5/S8 bearer transports the packets of an EPS bearer between a Serving GW and a PDN GW;

- A UE stores a mapping between an uplink packet filter and a radio bearer to create the mapping between a traffic flow aggregate and a radio bearer in the uplink;

- A PDN GW stores a mapping between a downlink packet filter and an S5/S8 bearer to create the mapping between a traffic flow aggregate and an S5/S8 bearer in the downlink;

- An eNodeB stores a one-to-one mapping between a radio bearer and an S1 Bearer to create the mapping between a radio bearer and an S1 bearer in both the uplink and downlink;

- A Serving GW stores a one-to-one mapping between an S1 Bearer and an S5/S8 bearer to create the mapping between an S1 bearer and an S5/S8 bearer in both the uplink and downlink.

EPS bearer identity

An EPS bearer identity uniquely identifies an EPS bearer for one UE accessing via E-UTRAN. The EPS Bearer Identity is allocated by the MME. There is a one to one mapping between EPS RB and EPS Bearer, and the mapping between EPS RB Identity and EPS Bearer Identity is made by E-UTRAN. The E-RAB ID value used at S1 and X2 interfaces to identify an E-RAB is the same as the EPS Bearer ID value used to identify the associated EPS Bearer.

When there is a mapping between an EPS bearer and a PDP context, the same identity value is used for the EPS bearer ID and the NSAPI/RAB ID.


LZT 123 8958 R1A © Ericsson 2009 - 47 -

QUALITY OF SERVICE CLASS IDENTIFIER

p2p file sharing, progressive video, etc.99

TCP-based (e.g., www, e-mail, chat, ftp,88

Video (Buffered Streaming)

10-6300 ms

67

Interactive Gaming

Video (Live Streaming)

Voice,

10-3100 ms7

Non-GBR

6

IMS Signalling10-6100 ms15

Real Time Gaming10-350 ms34

Non-Conversational Video (Buffered Streaming)10-6300 ms53

Conversational Video (Live Streaming)10-3150 ms42

Conversational Voice10-2100 ms2

GBR

1

Example ServicesPacket Error Loss Rate

Packet Delay Budget

PriorityResource Type

QCI




10-6300 ms

67

Interactive Gaming


Voice,

10-3100 ms7

Non-GBR

6






GBR

1


Packet Delay Budget


QCI




10-6300 ms

67

Interactive Gaming


Voice,

10-3100 ms7

Non-GBR

6






GBR

1


Packet Delay Budget


QCI




10-6300 ms

67

Interactive Gaming


Voice,

10-3100 ms7

Non-GBR

6






GBR

1


Packet Delay Budget


QCI

TS 23.203

Figure 3-8. QCI Characteristics.

The EPS bearer QoS profile includes the parameters QCI, ARP, GBR and MBR.

Each EPS bearer (GBR and Non-GBR) is associated with the following bearer level QoS parameters:

1 QoS Class Identifier (QCI);

2 Allocation and Retention Priority (ARP) .

A QCI is a scalar that is used as a reference to access node-specific parameters that control bearer level packet forwarding treatment (e.g. scheduling weights, admission thresholds, queue management thresholds, link layer protocol configuration, etc.), and that have been pre-configured by the operator owning the access node (eNodeB)


- 48 - © Ericsson 2009 LZT 123 8958 R1A

The ARP contains information about the priority level (scalar), the pre-emption capability (flag) and the pre-emption vulnerability (flag). The primary purpose of ARP is to decide whether a bearer establishment / modification request can be accepted or needs to be rejected in case of resource limitations (typically available radio capacity in case of GBR bearers). The priority level information of the ARP is used for this decision to ensure that the request of the bearer with the higher priority level is preferred. In addition, the ARP can be used (e.g. by the eNodeB) to decide which bearer(s) to drop during exceptional resource limitations (e.g. at handover). The pre-emption capability information of the ARP defines whether a bearer with a lower ARP priority level should be dropped to free up the required resources. The pre-emption vulnerability information of the ARP defines whether a bearer is applicable for such dropping by a pre-emption capable bearer with a higher ARP priority value. Once successfully established, a bearer's ARP shall not have any impact on the bearer level packet forwarding treatment (e.g. scheduling and rate control). Such packet forwarding treatment should be solely determined by the other EPS bearer QoS parameters: QCI, GBR and MBR, and by the AMBR parameters. The ARP is not included within the EPS QoS Profile sent to the UE.

NOTE 2: The ARP should be understood as "Priority of Allocation and Retention"; not as "Allocation, Retention, and Priority".

NOTE 3: Video telephony is one use case where it may be beneficial to use EPS bearers with different ARP values for the same UE. In this use case an operator could map voice to one bearer with a higher ARP, and video to another bearer with a lower ARP. In a congestion situation (e.g. cell edge) the eNB can then drop the "video bearer" without affecting the "voice bearer". This would improve service continuity.

NOTE 4: The ARP may also be used to free up capacity in exceptional situations, e.g. a disaster situation. In such a case the eNB may drop bearers with a lower ARP priority level to free up capacity if the pre-emption vulnerability information allows this.

Each GBR bearer is additionally associated with the following bearer level QoS parameters: • Guaranteed Bit Rate (GBR);

• Maximum Bit Rate (MBR).


LZT 123 8958 R1A © Ericsson 2009 - 49 -

The GBR denotes the bit rate that can be expected to be provided by a GBR bearer. The MBR limits the bit rate that can be expected to be provided by a GBR bearer.

Each APN access, by a UE, is associated with the following QoS parameter: • per APN Aggregate Maximum Bit Rate (APN-AMBR).The

GBR and MBR denote bit rates of traffic per bearer while UE-AMBR/APN-AMBR denote bit rates of traffic per group of bearers. Each of those QoS parameters has an uplink and a downlink component. On S1_MME the values of the GBR, MBR, and AMBR refer to the bit stream excluding the GTP-U/IP header overhead of the tunnel on S1_U

Each Service Data Flow (SDF) is associated with one and only one QoS Class Identifier (QCI). The QCI is scalar that is used as a reference to node specific parameters that control packet forwarding treatment (e.g. scheduling weights, admission thresholds, queue management thresholds, link layer protocol configuration, etc.) and that have been pre-configured by the operator owning the node (e.g. eNodeB).

Standardized QCI values describe the packet forwarding treatment that an SDF receives edge-to-edge between the UE and the PCEF in terms of the following performance characteristics:

1 Resource Type (GBR or Non-GBR);

2 Priority;

3 Packet Delay Budget;

4 Packet Error Loss Rate.

The Resource Type determines if dedicated network resources related to a service or bearer level Guaranteed Bit Rate (GBR) value are permanently allocated (e.g. by an admission control function in a radio base station). GBR SDF aggregates are therefore typically authorized "on demand" which requires dynamic policy and charging control.

The Packet Delay Budget (PDB) defines an upper bound for the time that a packet may be delayed between the UE and the PCEF. For a certain QCI the value of the PDB is the same in uplink and downlink. The purpose of the PDB is to support the configuration of scheduling and link layer functions (e.g. the setting of scheduling priority weights and HARQ target operating points).


- 50 - © Ericsson 2009 LZT 123 8958 R1A

Every QCI (GBR and Non-GBR) is associated with a Priority level. Priority level 1 is the highest Priority level. The Priority levels shall be used to differentiate between SDF aggregates of the same UE, and it shall also be used to differentiate between SDF aggregates from different UEs. Via its QCI an SDF aggregate is associated with a Priority level and a PDB. Scheduling between different SDF aggregates shall primarily be based on the PDB. If the target set by the PDB can no longer be met for one or more SDF aggregate(s) across all UEs that have sufficient radio channel quality then Priority shall be used as follows: in this case a scheduler shall meet the PDB of SDF aggregates on Priority level N in preference to meeting the PDB of SDF aggregates on Priority level N+1.

The Packet Error Loss Rate (PELR) defines an upper bound for the rate of SDUs (e.g. IP packets) that have been processed by the sender of a link layer protocol (e.g. RLC in E-UTRAN) but that are not successfully delivered by the corresponding receiver to the upper layer (e.g. PDCP in E-UTRAN). Thus, the PELR defines an upper bound for a rate of non congestion related packet losses. The purpose of the PELR is to allow for appropriate link layer protocol configurations (e.g. RLC and HARQ in E-UTRAN). For a certain QCI the value of the PELR is the same in uplink and downlink.

QoS for Emergency Services

Where local regulation requires supporting calls from an unauthorised caller, the MME may not have subscription data. Additionally, the local network may want to provide IMS emergency call support differently than what is allowed by a UE subscription. Therefore, the initial QoS values used for establishing emergency bearer services are configured in the MME in the MME Emergency Configuration Data.

This functionality is used by the Attach procedure and by the UE Requested PDN Connectivity procedure, in both cases when establishing emergency bearer services.


LZT 123 8958 R1A © Ericsson 2009 - 51 -

LTE QOS HANDLING The LTE Quality of Service (QoS) Handling coordinates and assigns the appropriate QoS to other functions in LTE RAN. The RBS maps QCIs (Quality of Service Class Indicators) to priorities for different Data Radio Bearers (DRBs) in the LTE radio interface and different data flows in the transport network. The RBS also ensures that different traffic types can be separated in the uplink by configuration of logical channel groups.

The LTE QoS Handling complies with the 3GPP Rel 8 QoS concept as in 3GPP TS 23.203. It provides service differentiation per user equipment by support of multiple parallel bearers. To provide service differentiation in the uplink, traffic separation must be ensured between the different data flows within the user equipment. This is done by offering an operator-configurable mapping between QCIs and LCGs (Logical Channel Groups, also sometimes referred to as radio bearer groups).

Moreover, service differentiation is enabled by mapping of QCIs to priorities as defined in 3GPP TS 23.203.

In the uplink, these priorities will serve as a basis for the user equipment to establish differentiation/prioritization between its logical channels.

Signalling Radio Bearers (SRBs) are assigned higher priority than Data Radio Bearers (DRBs). SRB1 has higher priority than SRB2.

The transport network benefits from QoS by mapping QCI to DiffServ Code Point (DSCP) in the RBS. This enables the transport network to prioritize between its different data flows over the S1 interface in the uplink and over the X2 interface for the downlink data in case of Packet Forwarding.

All QoS class identifiers defined by 3GPP are supported.


- 52 - © Ericsson 2009 LZT 123 8958 R1A

Scheduler

QoS translation

OSS-RCQoS parameters

QCI Table

QCI table•QoS configuration

QoS Handling

MME

Transport Network

QC

I Scheduling Strategy per RBS (RF, PF)

UL/DL(Radio Interface)Radio Network

DL Packet Forwarding

(X2)

DSC

P

Grant & Assignm

•Priorities etc

•PELR

•LCGs

UL (S1)

DSC

Pparam

eters

Figure 3-9 QoS Framework.

QoS Handling is based on mapping QCIs received from the core network to RBS-specific parameters. This makes it possible to have different priorities and DSCP (DiffServ Code Point) values.

If a user has multiple bearers with different QCI, these will be separated in the radio network into different bearers. This separation will achieve benefits for the end-user QoS as it removes the risk that one service such as file download would block the traffic for a voice call.

The LTE QoS Handling is realized by a central function in the RBS, which directly influences the radio and transport network behavior.

The Scheduler is an essential QoS enabler. In the downlink, the Scheduler operates on individual logical channels, with scheduling priorities based on a Round Robin or Proportional Fair scheduling strategy. In the uplink, the scheduling in the RBS operates on Logical Channel Groups (LCGs) using similar scheduling strategies as in the downlink to grant resources.


LZT 123 8958 R1A © Ericsson 2009 - 53 -

In uplink, the distribution of the granted resources is done per logical channel internally within the user equipment using the rate control function. The RBS maps the QCI to LCG and informs the user equipment about the association of a logical channel to a LCG and the logical channel priority for each logical channel.

Standardized QCIs (1-9) are used, according to 3GPP TS 23.203.

Non-standardized QCIs (10-256) are all given the same priority, which shall be lower compared to priorities for the standardized QCIs. The priority settings enable traffic separation of the different data flows in the RBS. For the uplink, the priorities associated with QCI are mapped to logical channel priorities which are sent to the UE. The UE will prioritize between its logical channels.

Mapping QCIs to Logical Channel Groups (LCGs) can be configured in OSS-RC and enables traffic separation in the uplink. There are three LCGs (1-3) available. By default, LCG 1 is assigned to all QCIs.

In Figure 3-10, an example showing when QCI 1-3 are mapped to LCG 1, QCI 4-6 are mapped to LCG 2 and QCI 7-9 and 10-256 are mapped to LCG 3 is shown.

The non-standardized QCIs are always mapped to the same LCG (In this example LCG 3).

An example on how to use the QoS support would be to map voice on QCI 1 and to let QCI 1 be assigned to its own logical channel group.

QCI 1

QCI 2

QCI 3

LCG 1 LCG 2 LCG 3QCI 4

QCI 5

QCI 6

QCI 7QCI 8QCI 9QCI 10-256

UE

6 3 8 5 2 1 4 7

28

77

36

35

84

33

42

81

QCILogical Channel

28

77

36

35

84

33

42

81

QCILogical Channel

Logical channels

Example of mapping of logical channels to logical channel

groups in uplink

1

3

1

1

3

1

2

3

LCG

1

3

1

1

3

1

2

3

LCG

310-256

37-9

24-6

11-3

LCGQCI

310-256

37-9

24-6

11-3

LCGQCI

Figure 3-10 UL traffic separation Example.


- 54 - © Ericsson 2009 LZT 123 8958 R1A

Mapping QCI to DiffServ Code Point (DSCP) for the uplink over S1 and in the downlink for packet forwarding over X2 can be configured in OSS-RC.

The DSCP setting determines the priority for the data stream in the IP transport network. The DSCP values may also be mapped to Ethernet Priority Bits (Pbits), which are used for prioritization on the Ethernet layers.

Several QCIs can be mapped to the same DSCP value. Non-standardized QCIs are all given the same configurable DSCP value.

From OSS-RC, it is possible to control the scheduling strategy (proportional fair or resource fair) per RBS.

Multiple RBSs can be configured in parallel from OSS-RC.


LZT 123 8958 R1A © Ericsson 2009 - 55 -

4 Radio Resource Control Protocol

OBJECTIVES

After this chapter the participants will be able to:1. Explain the Interaction between RRC and the lower layers in the

control plane.

2. Explain the RRC layer structure.

3. Explain the RRC Service States, and the difference between connected and idle mode.

4. Explain the functions and services of RRC.

5. Explain the RRC procedures.

After this chapter the participants will be able to:1. Explain the Interaction between RRC and the lower layers in the

control plane.

2. Explain the RRC layer structure.

3. Explain the RRC Service States, and the difference between connected and idle mode.

4. Explain the functions and services of RRC.

5. Explain the RRC procedures.



- 56 - © Ericsson 2009 LZT 123 8958 R1A

Intentionally Blank


LZT 123 8958 R1A © Ericsson 2009 - 57 -

RADIO RESOURCE CONTROL PROTOCOL Radio Resource Control (RRC) Protocol is the protocol that implements a great part of the Radio Resource Management (RRM) functions.

The RRC protocol controls and signals the allocation of radio resources to the UE. Most of the control signaling between UE and E-UTRAN is Radio Resource Control (RRC). The RRC messages carry parameters required to set up, modify and release layer 2 and even layer1 protocol entities. RRC Signaling is also used to convey NAS messages to/from UE

Header Compression

TM AM UM

Physical Layer

L2

PDCP

RLC

MAC

RRC

NAS

Integrity/Ciphering


Cell Selection

Paging Reception

Mobility Management

Session Management

Connected Mode

Mobility

NAS Security

IP

Application


RB Managementv


Con

trol/R

epor

t SA

Ps

RA Control HARQControl

Figure 4-2 RRC Protocol Stack – UE Side

Examples of the L2 parameters that are defined by RRC would be: mode of the RLC, retransmission timers and buffer sizes, priority of the logical channels, MAC time alignment and UL SCH Configuration, HARQ Configuration. Examples for the L1 parameters are pusch configuration, cqi reporting, antenna information etc.

The local control and local measurements reporting is handled through the control Service Access Points (SAPs) between RRC and the lower layers.


- 58 - © Ericsson 2009 LZT 123 8958 R1A

In the physical layer, measurements on the neighbor cells for handover and cell selection are performed. When events/criteria are fulfilled, RRC measurement reports are sent from the UE to the e-NodeB.

ECM/EMM AND RRC STATE

In order to be able to dig in into the RRC procedures it is essential to understand the main RRC States and its relationship with 3GPP standardized ECM and EMM states. Figure 4-3 illustrates ECM/EMM states and actions that triggers transitions between them.

ECM-CONNECTED(EMM-REGISTERED)

EMM-DEREGISTERED

ECM-IDLE(EMM- REGISTERED)

Attach

Detach

Detach

Connection Re-activation

MME-initiated Connection Release

Tracking Area UpdateTracking Area Update

Figure 4-3 LTE/SAE State Model

The NAS state model is based on a two-dimensional model which consists of EPS Mobility Management (EMM) states describing the mobility management states that result from the mobility management procedures e.g. Attach and Tracking Area Update procedures, and of EPS Connection Management (ECM) states describing the signaling connectivity between the UE and the EPC.

The ECM and EMM states are independent of each other. When the UE is in EMM-REGISTERED state this does not imply that the user plane (radio and S1 bearers) is established.

The relation between NAS and AS states is characterized by the following principles:

EMM-DEREGISTERED & ECM-IDLE ⇒ RRC_IDLE:

- Mobility: PLMN selection.

- UE Position: not known by the network.


LZT 123 8958 R1A © Ericsson 2009 - 59 -

EMM-REGISTERED & ECM-IDLE ⇒ RRC_IDLE:

- Mobility: cell reselection.

- UE position: known by network at TA level.

EMM-REGISTERED & ECM-CONNECTED with radio bearers established ⇒ RRC_CONNECTED.

- Mobility: handover.

- UE Position: known by the network at cell level

RRC-CONNECTED(EMM-REGISTERED)

RRC-IDLE(EMM- REGISTERED)

Connection Re-activation

MME-initiated Connection Release

Tracking Area UpdateTracking Area Update

Figure 4-4 RRC States

RRC_IDLE:

-UE controlled mobility;

The UE:

3 Monitors a Paging channel to detect incoming calls, system information change, and for ETWS capable UEs, ETWS notification,

4 Performs neighboring cell measurements and cell (re-)selection

5 Acquires system information.

RRC_CONNECTED:

-Transfer of unicast data to/from UE.

-Network controlled mobility, i.e. handover and cell change order with optional network assistance (NACC) to GERAN;


- 60 - © Ericsson 2009 LZT 123 8958 R1A

The UE:

1 Monitors a Paging channel and/ or System Information Block Type 1 contents to detect system information change, and for ETWS capable UEs, ETWS notification;

2 Monitors control channels associated with the shared data channel to determine if data is scheduled for it;

3 Provides channel quality and feedback information;

4 Performs neighboring cell measurements and measurement reporting

5 Acquires system information


LZT 123 8958 R1A © Ericsson 2009 - 61 -

RRC FUNCTIONS AND SERVICES PROVIDED TO UPPER LAYERS

Figure 4-5 lists all the RRC functions that will be discussed in this course book such as: broadcast and acquisition of System Information; Idle mode behavior: Cell Selection and Cell reselection; Transition from Idle to Connected mode including Paging, RRC Connection establishment/reconfiguration/re-establishment/release will be explained. Connected mode behavior such as Measurement Reporting, Mobility and transfer of transparent messages will be discussed both in RRC Chapter but also in X2 and S1.

System informationCell Selection / ReselectionConnection control

– Paging– RRC connection establishment– Security activation– RRC connection reconfiguration– RRC connection re-establishment– RRC connection release– Radio link failure related actions

Measurement Control– Measurement configuration– Measurement reporting

Mobility Management– Inter/Intra E-UTRA mobility– Mobility from E-UTRA– Handover to E-UTRA

Other procedures– DL Direct Transfer– UL Direct Transfer– UE capability transfer– Protocol error handling

RRC


Cell Selection

Paging Reception

Connected Mode

Mobility


RB Managementv


RRC


Cell Selection

Paging Reception

Connected Mode

Mobility


RB Managementv


TS 36.331

Figure 4-5 RRC Procedures

Protocol Error Handling procedure is out of scope of this course however it is listed in the Figure 4-5 for the reference.

RRC procedures

The above mentioned functions are supervised by different signaling procedures. For example, how should the UE act upon receiving a paging message or when it detects a change in Tracking Area? A procedure is triggered within the UE and the RRC will generate a suitable message for the task.


- 62 - © Ericsson 2009 LZT 123 8958 R1A

RRC MESSAGES

The RRC messages carry information that is structured into Information Elements (IEs). The messages are exchanged between the RRC in the eNodeB and RRC in the UE.

Figure 4-6 lists RRC messages as defined in 36.331

CounterCheckCounterCheckResponseCSFBParametersRequestCSFBParametersResponseDLInformationTransferHandoverFromEUTRAPreparationRequest MasterInformationBlockMeasurementReportMobilityFromEUTRACommandPagingRRCConnectionReconfigurationRRCConnectionReconfigurationCompleteRRCConnectionReestablishmentRRCConnectionReestablishmentCompleteRRCConnectionReestablishmentRejectRRCConnectionReleaseRRCConnectionRequestRRCConnectionSetupRRCConnectionSetupComplete

SecurityModeCommandSecurityModeCompleteSecurityModeFailureSystemInformationSystemInformationBlockType1UECapabilityEnquiryUECapabilityInformationULHandoverPreparationTransferULInformationTransfer

CSFBParametersRequestCDMA2000CSFBParametersResponseCDMA2000HandoverFromEUTRAPreparationRequest (CDMA2000)ULHandoverPreparationTransfer (CDMA2000)

Figure 4-6 RRC Messages (extract from 3gpp 36.331)


LZT 123 8958 R1A © Ericsson 2009 - 63 -

RRC FUNCTIONS AND PROCEDURES The RRC functions and procedures are explained in detail in this section.

BROADCAST OF SYSTEM INFORMATION

The system information is a set of parameters that defines rules for the UE how to behave while visiting the cell. The UE shall apply the system information acquisition procedure upon selecting (e.g. upon power on) and upon re-selecting a cell, after handover completion, after entering E-UTRA from another RAT, upon return from out of coverage, upon receiving a notification that the system information has changed, upon receiving an indication about the presence of an ETWS notification and upon exceeding the maximum validity duration. Unless explicitly stated otherwise in the procedural specification, the system information acquisition procedure overwrites any stored system information.

MASTER INFORMATION BLOCK (MIB)

SYSTEM INFORMATION 1

SYSTEM INFORMATION N

Figure 4-7 System Information Broadcast


- 64 - © Ericsson 2009 LZT 123 8958 R1A

System information is divided into the Master Information Block (MIB) and a number of System Information Blocks (SIBs). The MIB includes a limited number of most essential and most frequently transmitted parameters that are needed to acquire other information from the cell, and is transmitted on BCH. SIBs other than System Information Block Type 1 are carried in System Information (SI) messages and mapping of SIBs to SI messages is flexibly configurable by scheduling Info List included in System Information Block Type1, with restrictions that: each SIB is contained only in a single SI message, only SIBs having the same scheduling requirement (periodicity) can be mapped to the same SI message, and System Information Block Type 2 is always mapped to the SI message that corresponds to the first entry in the list of SI messages in scheduling Info List. There may be multiple SI messages transmitted with the same periodicity. System Information BlockType1 and all SI messages are transmitted on DL-SCH as illustrated in Figure 4-8

MIB SIB1 SIB2 SIB3 SIB4

SI-2 SI-4SI-3

SIB5

BCCH

BCH

PBCH PDSCH

BCCH

DL-SCH

PDSCH

DL-SCH

BCCH

TTI=80 TTI= 160 TTI= 320TTI= 40

Figure 4-8 System Information Mapping- Example

Different system information blocks may have different characteristics, for instance regarding their repetition rate and the requirements on UEs to re-read the SIBs. System Information that is broadcasted in MIB is sent with 40 ms Transmission Time Interval (TTI) while the rest of the system information will have different TTI. TTI of 80 ms is used for SB and SIB1 distribution, 160 ms for SIB2 and SIB3 and 320 ms for SIB4 and SIB5.

Main idea with SIBs is to group system information elements of the same nature, for example, cell selection and cell reselection parameters.


LZT 123 8958 R1A © Ericsson 2009 - 65 -

In the Figure 4-9 grouping can be identified.

xxETWS notification

xhome eNodeB

xInter RAT reselection (CDMA2000)

xInter RAT reselection (GRAN)

xInter RAT reselection (UTRA)

xNeighbouring Cells -inter frequency

xNeighbouring Cells -intra frequency

xCell Reselection

xPaging Info

xCommon Radio Resource Conf

xDL Bandwith

xUL Bandwith

xUL EARFCN

xSIB Scheduling

xFrequency Band Indicator

xCell Barred

xCell Id

xTracking Area Code

xPLMN-id

xCell Selection Info

SIB11

SIB10

SIB9

SIB8

SIB7

SIB6

SIB5

SIB4

SIB3

SIB2

SIB1MIBSystem Parameters Related to

xxETWS notification

xhome eNodeB

xInter RAT reselection (CDMA2000)

xInter RAT reselection (GRAN)

xInter RAT reselection (UTRA)

xNeighbouring Cells -inter frequency

xNeighbouring Cells -intra frequency

xCell Reselection

xPaging Info

xCommon Radio Resource Conf

xDL Bandwith

xUL Bandwith

xUL EARFCN

xSIB Scheduling

xFrequency Band Indicator

xCell Barred

xCell Id

xTracking Area Code

xPLMN-id

xCell Selection Info

SIB11

SIB10

SIB9

SIB8

SIB7

SIB6

SIB5

SIB4

SIB3

SIB2

SIB1MIBSystem Parameters Related to

Figure 4-9 System Information carried in the System Information Blocks

Please note that the table is incomplete, it is only here to illustrate the grouping of the parameters. For example MIB apart from DL Bandwidth will also carry PHICH Configuration (PHICH duration and PHICH resources) and System Frame Number (SFN).

Detailed information for each System Information Block can be found in the 3GPP 36.331

Change of System Information

When the System Information is changed, value tag in the scheduling info in System Information Block 1 is set. The actual change of System information can occur at specific radio frames as illustrated in Figure 4-10. System Information can be transmitted number of times with the same content within the modification period as defined by its scheduling.


- 66 - © Ericsson 2009 LZT 123 8958 R1A

The modification period boundaries are defined by SFN values for which:

SFN mod modificationPeriod = 0

BCCH modification period (n) BCCH modification period (n+1)

Change notification Updated information

Change of System Information can only occur at specific radio frames

SFN mod modificationPeriod = 0

Figure 4-10 System Information Change

When the network changes some of the System Information it first notifies the UE about this change using modification period. In the next modification period an updated System Information is transmitted, Figure 4-10

The RRC Paging message is used to inform UEs in IDLE and RRC Connected mode about the System Information Change. When the UE receives Paging message that includes “System Info Modification” it knows that the System Information will change in the next modification period boundary. However at this stage UE doesn’t know which part of the System Info that will be changed. In order to find out that UE needs to decode the SIB 1. UE will identify system information blocks that have been changed and will reread them as well.

”Paging: System Info Modification” PCCH/PCHa.

a) RRC_IDLE and RRC_CONNECTED - Pagingb) UE needs to reread SIB1 and check value tag

Figure 4-11 Re-reading of System Information


LZT 123 8958 R1A © Ericsson 2009 - 67 -

E-UTRAN may not update system Info Value Tag upon change of some system information e.g. ETWS information, regularly changing parameters like CDMA2000 system time. Similarly, E-UTRAN may not include the system Info Modification within the Paging message upon change of some system information

In order to understand the mechanisms for rereading of system information see Paging chapter

IDLE MODE TASKS

The idle mode tasks can be subdivided into four processes: • -PLMN selection;

• Cell selection and reselection;

• Location registration;

• Support for manual CSG ID selection.

The relationship between these processes is illustrated in the Figure 4-12.

PLMN Selection

Location Registration

PLMNsavailable

PLMN selected

LocationRegistration

response

Registration Area

changes

Indication to user

Manual Mode Automatic mode

Service requests

NAS Control

Radio measurements

Cell Selection and Reselection

Support for manual CSG ID selection

AvailableCSG IDsto NAS

CSG IDselected

Figure 4-12 Idle Mode Tasks


- 68 - © Ericsson 2009 LZT 123 8958 R1A

The UE shall, if necessary, then register its presence, by means of a NAS registration procedure, in the tracking area of the chosen cell and as outcome of a successful Location Registration the selected PLMN becomes the registered PLMN.

If the UE finds a more suitable cell, according to the cell reselection criteria, it reselects onto that cell and camps on it. If the new cell does not belong to at least one tracking area to which the UE is registered, location registration is performed.

If necessary, the UE shall search for higher priority PLMNs at regular time intervals and search for a suitable cell if another PLMN has been selected by NAS.

Search of available CSG IDs may be triggered by NAS to support manual CSG ID selection within the registered PLMN.

If the UE loses coverage of the registered PLMN, either a new PLMN is selected automatically (automatic mode), or an indication of which PLMNs are available is given to the user, so that a manual selection can be made (manual mode).

Registration is not performed by UEs only capable of services that need no registration.

The purpose of camping on a cell in idle mode is fourfold:

a) It enables the UE to receive system information from the PLMN.

b) When registered and if the UE wishes to establish an RRC connection, it can do this by initially accessing the network on the control channel of the cell on which it is camped.

c) If the PLMN receives a call for the registered UE, it knows (in most cases) the set of tracking areas in which the UE is camped. It can then send a "paging" message for the UE on the control channels of all the cells in this set of tracking areas. The UE will then receive the paging message because it is tuned to the control channel of a cell in one of the registered tracking areas and the UE can respond on that control channel.

d) It enables the UE to receive ETWS notifications.

If the UE is unable to find a suitable cell to camp on, or the USIM is not inserted, or if the location registration failed UE enters a "limited service" state in which it can only attempt to make emergency calls.


LZT 123 8958 R1A © Ericsson 2009 - 69 -

CELL SELECTION

Stored Information Cell Selection

Initial Cell Selection

Cell Selection when leaving connected mode


Cell Reselection Evaluation ProcessCell Reselection Evaluation Process

Connected Mode

Any Cell Selection

Cell Reselection Evaluation ProcessCell Reselection Evaluation Process

Camped on any cell

Connected Mode (Emergency calls only)

2

Camped Normally

go here whenever a new PLMN is selected

no cell information stored for the PLMN

cell informationstored for the PLMN

no suitable cell found

suitable cell found

Selected PLMN is rejected

suitable cell found

no suitable Cell found

return to Idle Mode

Leave Idle Mode

triggerSuitableCell found

no suitableCell found

go hereWhen no USIM in the UE

11

11

USIM inserted

22

AcceptableCell Found

SuitableCell found

no acceptable cell found



triggerAcceptableCell found

no acceptableCell Found

leave Idle Mode

AcceptableCell found

return toIdle Mode

suitable cell found

Figure 4-13 Cell Selection

The UE shall use one of the following two cell selection procedures:

a) Initial Cell Selection

This procedure requires no prior knowledge of which RF channels are E-UTRA carriers. The UE shall scan all RF channels in the E-UTRA bands according to its capabilities to find a suitable cell. On each carrier frequency, the UE need only search for the strongest cell. Once a suitable cell is found this cell shall be selected.

b) Stored Information Cell Selection

This procedure requires stored information of carrier frequencies and optionally also information on cell parameters, from previously received measurement control information elements or from previously detected cells. Once the UE has found a suitable cell the UE shall select it. If no suitable cell is found the Initial Cell Selection procedure shall be started.


- 70 - © Ericsson 2009 LZT 123 8958 R1A

CELL RESELECTION PROCESS

When camped on a cell, the UE shall regularly search for a better cell according to the cell reselection criteria. If a better cell is found, that cell is selected. The change of cell may imply a change of RAT.

For normal service, the UE shall camp on a suitable cell, tune to that cell's control channel(s) so that the UE can:

-Receive system information from the PLMN; and

-receive registration area information from the PLMN, e.g., tracking area information; and

-receive other AS and NAS Information; and

-if registered:

-receive paging and notification messages from the PLMN;

- and initiate transfer to connected mode.

The UE shall only perform cell reselection evaluation for E-UTRAN frequencies and inter-RAT frequencies that are given in system information and for which the UE has a priority provided.

The UE shall not consider any black listed cells as candidate for cell reselection.

When evaluating for reselection purposes UE shall use parameters provided by the serving cell. The cell-ranking criterion is applied.


LZT 123 8958 R1A © Ericsson 2009 - 71 -

PAGING

The purpose of this procedure is to transmit paging information to a UE in RRC_IDLE and/ or to inform UEs in RRC_IDLE and UEs in RRC_CONNECTED about a system information change and/ or about an ETWS primary notification and/ or ETWS secondary notification. The paging information is provided to upper layers, which in response may initiate RRC connection establishment, e.g. to receive an incoming call.

TAC 1

S1AP Paging message

RRC Paging message

TAC 2

The MME sends the PAGING message to each eNode B with cells belonging to the tracking area(s) in which the UE is registered.

Each eNode B can contain cells belonging to different tracking areas, whereas each cell can only belong to one TA.

UEs use DRx when in idle mode in order to wake at regular intervals to check for paging messages.

The paging response back to the MME is initiated on NAS layer and is sent by the eNB based on NAS-level routing information.

MME

Figure 4-14 CN Initiated Paging

E-UTRAN initiates the paging procedure by transmitting the Paging message at the UE’s paging occasion.


- 72 - © Ericsson 2009 LZT 123 8958 R1A

The MME initiates a paging message which is sent to all eNode Bs in a tracking area(s)

UEs use the Random Access procedure to initiate access to the serving cell

NAS messaging continues in order to set up the call

S1-AP: INITIAL UE MESSAGE (FFS)+ NAS: Service Request+ eNB UE signalling connection ID

Random Access Procedure

NAS: Service Request

RRC PAGINGS1AP:Paging

MME

Figure 4-15 RRC Paging

What is a Paging Occasion?

The UE may use Discontinuous Reception (DRX) in idle mode in order to reduce power consumption.

Paging channel (PCH) uses PDSCH transmissionPaging indicated on PDCCH

– DRX cycle defined– Special ‘paging MAC ID’ indicating paging group– If ID matches UE reads PDSCH to find which UE that is paged

subframe

DRX cycle

UE receiver circuitry switched off

Possibility to page this terminal

UE receiver circuitry switched off

PDCCH

Figure 4-16 Paging DRX Cycle on PDCCH

One Paging Occasion (PO) is a subframe where there may be P-RNTI transmitted on PDCCH addressing the paging message. One Paging Frame (PF) is one Radio Frame, which may contain one or multiple Paging Occasion(s). When DRX is used the UE needs only to monitor one PO per DRX cycle.

PF and PO is determined by following formula using the DRX parameters provided in System Information:

PF is given by following equation:


LZT 123 8958 R1A © Ericsson 2009 - 73 -

SFN mod T= (T div N)*(UE_ID mod N)

Index i_s pointing to PO from subframe pattern defined in the table will be derived from following calculation:

i_s = floor(UE_ID/N) mod Ns PO when i_s=0 PO when i_s=1 PO when i_s=2 PO when i_s=3

1 9 N/A N/A N/A

2 4 9 N/A N/A

4 0 4 5 9

System Information DRX parameters stored in the UE shall be updated locally in the UE whenever the DRX parameter values are changed in SI. If the UE has no IMSI, for instance when making an emergency call without USIM, the UE shall use as default identity UE_ID = 0 in the PF and i_s formulas above.

The following Parameters are used for the calculation of the PF and i_s:

-T: DRX cycle of the UE. T is determined by the shortest of the UE specific DRX value, if allocated by upper layers, and a default DRX value broadcast in system information. If UE specific DRX is not configured by upper layers, the default value is applied.

-nB: 4T, 2T, T, T/2, T/4, T/8, T/16, T/32.

-N: min(T,nB)

-Ns: max(1,nB/T)

-UE_ID: IMSI mod 1024.

IMSI is given as sequence of digits of type Integer (0..9), IMSI shall in the formulae above be interpreted as a decimal integer number, where the first digit given in the sequence represents the highest order digit.


- 74 - © Ericsson 2009 LZT 123 8958 R1A

ESTABLISHMENT, MAINTENANCE AND RELEASE OF RRC CONNECTION

When the UE receives a paging message (Idle mode UE), has changed Tracking Area, or is going to set up a session, it needs to set up a signaling connection with the core network. This is initiated with an RRC Connection Establishment procedure. The RRC Connection is a dedicated connection used for control signaling between the E-UTRAN and one UE. It comprises the connection between the UE and the E-UTRAN including all the resources, i.e. L1, L2 and L3. Before a signaling exchange can occur, a radio bearer is needed. The radio bearer available for transmission of RRC messages is defined as Signaling Radio Bearer. There exist three different signaling radio bearers as illustrated in Figure 4-17.

Signalling Radio Bearers (SRBs) are offered by the PDCP layer tothe RRC layer for transport of RRC (and NAS) messages

– SRB0: Used for RRC messages on the CCCH– SRB1: Used for RRC and NAS messages on the DCCH– SRB2 (optionally configured): Used for high-priority RRC

messages

PDCP

RRCSRB0 SRB1 SRB2

Figure 4-17 Signaling Radio Bearers

Signalling Radio Bearers" (SRBs) are defined as Radio Bearers (RB) that are used only for the transmission of RRC and NAS messages. More specifically, the following three SRBs are defined:

-SRB0 is for RRC messages using the CCCH logical channel;

-SRB1 is for RRC messages (which may include a piggybacked NAS message) as well as for NAS messages prior to the establishment of SRB2, all using DCCH logical channel;

-SRB2 is for NAS messages, using DCCH logical channel. SRB2 has a lower-priority than SRB1 and is always configured by E-UTRAN after security activation.


LZT 123 8958 R1A © Ericsson 2009 - 75 -

In downlink piggybacking of NAS messages is used only for one dependant (i.e. with joint success/ failure) procedure: bearer establishment/ modification/ release. In uplink NAS message piggybacking is used only for transferring the initial NAS message during connection setup.

The NAS messages transferred via SRB2 are also contained in RRC messages, which however do not include any RRC protocol control information.

Once security is activated, all RRC messages on SRB1 and SRB2, including those containing NAS or non-3GPP messages, are integrity protected and ciphered by PDCP. NAS independently applies integrity protection and ciphering to the NAS messages.

Establishment of RRC Connection

The UE initiates the procedure when upper layers request establishment of an RRC connection while the UE is in RRC_IDLE state

RRC Connection Request is initiated by the higher layers in the UE

– A unique UE identity RA RNTI is used in the request message

RRC Connection Setup RRC connection establishment procedure creates the signaling radio bearer RB#1,

”RRC Connection Request” CCCH/RACH

”RRC Connection Setup” CCCH/DLSCH

”RRC Connection Setup Complete” DCCH/ULSCH

Idle Mode

Connected Mode

Figure 4-18 RRC Connection Establishment

The purpose of this procedure is to establish a control plane signalling between UE and E-UTRAN - an RRC connection. RRC connection establishment involves SRB1 establishment. The procedure is also used to transfer the initial NAS dedicated information/ message from the UE to E-UTRAN.

E-UTRAN applies the procedure to establish SRB1 only.

A unique UE Identity U-RTNI is allocated by MAC during preamble procedure (see MAC Chapter) and returned to the E-UTRAN in the RRC Connection Request message.


- 76 - © Ericsson 2009 LZT 123 8958 R1A

Different reasons that can trigger this procedure are listed in Figure 4-10.

Emergency Call,High Priority Access,MT-Access,MO-Signalling,MO-Data

RRC Establishment CauseIE type and referenceIE/Group Name

Emergency Call,High Priority Access,MT-Access,MO-Signalling,MO-Data

RRC Establishment CauseIE type and referenceIE/Group Name

Figure 4-19 Establishment Causes

Security Mode Procedure

E-UTRAN initiates the security mode command procedure to a UE in RRC_CONNECTED. Moreover, E-UTRAN applies the procedure when only SRB1 is established and. prior to establishment of SRB2 and/ or DRBs

MME

INITIAL CONTEXT SETUP REQUEST(Integrity Protection Algorithm EIA;

Ciphering Algorithm EEA;Security Key)

SECURITY MODE COMMAND(EEA;EIA)

SECURITY MODE COMPLETE

2. Decide Algorithms, Derive KeysActivate Security for SRB

INITIAL CONTEXT SETUP RESPONSE Figure 4-20 Security Mode Command

RRC Security Mode Command is triggered by the EPC (MME) at Initial Context Setup Request. This message includes all security setting needed to start Integrity Protection of the control plane signaling and Encryption of the both user plane and control plane signaling. Security setting includes Integrity Algorithm (EIA) Ciphering Algorithm (EEA) and Security key.

Integrity Protection and Encryption are part of the Packet Data Convergence Protocol (PDCP) and more details about actual integrity protection and ciphering can be found in PDCP Chapter.

Additional security measures are added to LTE/SEA by adding Counter check function.


LZT 123 8958 R1A © Ericsson 2009 - 77 -

Counter check

The counter check procedure is used by E-UTRAN to request the UE to verify the amount of data sent/ received on each DRB. More specifically, the UE is requested to check if, for each DRB, the most significant bits of the COUNT match with the values indicated by E-UTRAN.

RRC COUNTER CHECK

RRC COUNTER CHECK RESPONSE

Figure 4-21 RRC Counter Check

The procedure enables E-UTRAN to detect packet insertion by an intruder (a ‘man in the middle’).

Transparent Message Transfer

The purpose of this procedure is to transfer NAS or (tunneled) non-3GPP dedicated information from the UE to E-UTRAN

A UE in RRC_CONNECTED initiates the UL information transfer procedure whenever there is a need to transfer NAS or non-3GPP dedicated information, except at RRC connection establishment in which case the NAS information is piggybacked to the RRC Connection Setup Complete message. The UE initiates the UL information transfer procedure by sending the UL Information Transfer message. When CDMA2000 information has to be transferred, the UE shall initiate the procedure only if SRB2 is established.


- 78 - © Ericsson 2009 LZT 123 8958 R1A

RRC UL INFORMATION TRANSFER (NAS message)

RRC DL INFORMATION TRANSFER (NAS message)

Figure 4-22 UL/DL Information Transfer

The purpose of this procedure is to transfer NAS or (tunnelled) non-3GPP dedicated information from E-UTRAN to a UE in RRC_CONNECTED

E-UTRAN initiates the DL information transfer procedure whenever there is a need to transfer NAS or non-3GPP dedicated information. E-UTRAN initiates the DL information transfer procedure by sending the DL Information Transfer message

UE Capability Transfer

E-UTRAN initiates the procedure to a UE in RRC_CONNECTED when it needs (additional) UE radio access capability information.

The eNodeB requests the UE Radio Capability by sending RRC UE Capability Enquiry message.

The UE responds to the eNodeB with requested UE Capability in the UE Capability Information message

The eNodeB forwards the received”UE Radio Capabilities” to the MME in the UE Capability Info Indication


LZT 123 8958 R1A © Ericsson 2009 - 79 -

RRC UE CAPABILITY ENQUIRY

RRC UE CAPABILITY INFORMATION

S1AP: UE Capability Info Indication

Figure 4-23 RRC UE Capability Enquiry/Information

Radio Link Failure

Two phases governs the behavior associated to radio link failure as illustrated in Figure 4-24:

First Phase: • -started upon radio problem detection;

• leads to radio link failure detection;

• no UE-based mobility;

• based on timer or other (e.g. counting) criteria (T1).

Second Phase:

• started upon radio link failure detection or handover failure;

• leads to RRC_IDLE;

• UE-based mobility;

• Timer based (T2).

normal operationradio

problem detection

no recovery during T1 no recovery during T2 goes back to idle

radio link failure

RRC_CONNECTED RRC_IDLE

First Phase Second Phase

Figure 4-24 RL Failure Phases


- 80 - © Ericsson 2009 LZT 123 8958 R1A

RRC CONNECTION RE-ESTABLISHMENT REQUEST

RRC CONNECTION RE-ESTABLISHMENT REJECT

RRC CONNECTION RE-ESTABLISHMENT COMPLETE

RRC CONNECTION RE-ESTABLISHMENT REQUEST

RRC CONNECTION RE-ESTABLISHMENT

Figure 4-25 RRC Radio Link Failure Procedure

Upon”radio link problems” (criteria FFS) detected UE starts timer T310. In case radio link recovery happens before T310 expires the UE stops the timer T310 and continue in state RRC Connected.

At T310 expiry UE starts timer T311 and start searches for a cell

If the UE finds a cell before T311 expires RRC Connection re-establishment procedure is triggered. In case T311 expiries before UE finds a cell than the UE enters idle mode


LZT 123 8958 R1A © Ericsson 2009 - 81 -

TRAFFIC CASES:

ATTACH REQUEST

MME

7. INITIAL UE MESSAGE (Attach Request)

14. INITIAL CONTEXT SETUP REQUEST(EPS bearers, Attach Accept, Security)

22. INITIAL CONTEXT SETUP RESPONSE(EPS bearers)

1. System Information *

4. RRC CONNECTION REQUEST

5. RRC CONNECTION SETUP

15. RRC SECURITY MODE COMMAND

16.RRC SECURITY MODE COMPLETE

6. RRC CONNECTION SETUP COMPLETE (Attach Request)

2. Random Access Preamble 3. Random Access Response

20. RRC CONNECTION RECONFIGURATION (Bearer Setup)21. RRC CONNECTION RECONFIGURATION COMPLETE

10.RRC DL INFORMATION TRANSFER (Authentication Request)

11. RRC UL INFORMATION TRANSFER (Authentication Response)

DL NAS TRANSFER (Authentication)

UL NAS TRANSFER (Auth. Response)

12. RRC DL INFORMATION TRANSFER (Security Mode Command)

13. RRC UL INFORMATION TRANSFER (Security Mode Complete)

DL NAS TRANSFER (NAS SMC)

UL NAS TRANSFER (NAS SMC)

CellSelect *

23. RRC UL INFORMATION TRANSFER (Attach Complete)) UL NAS TRANSFER (Attach Complete)

RRC IDLE

RRC IDLE

8.RRC DL INFORMATION TRANSFER (UE Identity Request)

9. RRC UL INFORMATION TRANSFER (UE Identity Response)

DL NAS TRANSFER (UE Identity Req)

UL NAS TRANSFER (UEid Response)

17. RRC UE CAPABILITY ENQUIRY

18. RRC UE CAPABILITY iNFORMATION19. UE CAPABILITY INFO INDICATION

(UE Radio Capability)

24. UE CONTEXT RELEASE COMMAND

26. RRC CONNECTION RELEASE 25. UE CONTEXT RELEASE COMPLETE

Figure 4-26 Traffic Case Attach Request

1 . The UE reads the System Information, broadcasted in the cell.

2 The UE performs cell selection, based on the cell selection parameters received system information and reads the rest of system information in the selected cell. Information available in the system info is also the available set of PRACH resources and their corresponding RA-RNTIs (more about this part can be found in MAC Chapter). UE will randomly select Random Access Preamble and send it to the eNodeB (MAC Protocol)

3 eNodeB answers with Random Access Response (MAC Protocol)


- 82 - © Ericsson 2009 LZT 123 8958 R1A

4 The UE requests establishment of the RRC connection by sending the message RRC Connection Request to the eNodeB. The UE provides the UE id (S-TMSI, IMSI or a random identifier) and the Establishment Cause of the RRC connection establishment. Note! The UE is identified by the S-TMSI if the UE is registered in the TA of the current cell.

5 The eNodeB creates SRB1 and its low layer entities and initiates establishment of the RRC connection by sending the message RRC Connection Setup to the UE.

6 The UE finalizes the establishment of the RRC connection by sending the message RRC Connection Setup Complete to the eNodeB. The UE indicates the selected PLMN and provides a NAS message to the eNodeB. In this case the NAS message is Attach Request

7 The Attach Request message is provided to the MME in the “Initial UE Message”. The UE is identified either by the GUTI or the IMSI (in the Attach Request message). More about S1 signaling is provided in S1AP chapter.

8 As this is Initial Attach EPC will request UE Identity by sending NAS “UE Identity Request” message

9 UE will send its IMSI in NAS “UE Identity Response”

10 MME sends Authentication Information Request to HSS including the IMSI to identify the UE/Subscriber. HSS responds with Authentication Information Answer including the requested number of Authentication Vectors (Kasme, RAND, AUTN, XRES) used for security and authentication between the UE and the network. The MME requests Authentication of the UE by sending the NAS message “Authentication Request” to the UE including the selected RAND and AUTN, using the RRC DL Information Transfer

11 The UE verifies the AUTN, calculates the Kasme and sends calculated RES to the MME in the NAS message “Authentication Response” to the MME, using the RRC UL Information Transfer procedure

12 If the RES from UE corresponds to the value XRES received from HSS, the MME sends the NAS message “Security Mode Command” to the UE to activate the NAS security functions (ciphering and integrity protection), using the DL NAS Signaling Transfer procedure


LZT 123 8958 R1A © Ericsson 2009 - 83 -

13 The UE acknowledges the activation of the NAS security functions by sending the NAS message “Security Mode Complete” to the MME, using the UL NAS Signaling Transfer procedure

14 The default Radio Bearer, i.e. the Radio Bearer supporting the default EPS Bearer, is established using the Initial Radio Bearer Establishment procedure. The Tunnel Endpoint Identifier (TEID) and the IP address for the UL (Serving GW) of the user plane received from the Serving GW are used. The NAS message “Attach Accept” (including the session management message “Activate Default EPS Bearer Context Request”) is transferred to the UE using Initial Context Setup Request.

15 eNodeB can initiate Integrity protection of RRC signaling and NAS signaling and encryption of the data using RRC Security Mode Command.

16 UE response using RRC Security Mode Complete

17 If no UE Capability was received in Initial Context Setup Request message than the UE Capability is fetched by sending “RRC UE Capability Enquiry” message

18 UE will send its capabilities

19 And eNodeB will forward them to the MME.

20 eNodeB will piggy back NAS Attach Accept message in RRC Radio Reconfiguration message.

21 The default Radio Bearer, i.e. the Radio Bearer supporting the default EPS Bearer, in the UE as well and the answer is sent to eNodeB using RRC Connection reconfiguration Complete

22 The confirmation is also sent to the MME in Initial Context Setup Response

23 Finally, the NAS message “Attach Complete” (including the session management message “Activate Default EPS Bearer Context Accept”) is transferred from the UE, using the UL Information Transfer procedure and further to the MME using UL NAS Transport over S1 Interface. For more details see S1AP Chapter

24 .MME can release a connection by sending S1AP UE Context Release Command that will

25 Trigger RRC Connection Release to the UE


- 84 - © Ericsson 2009 LZT 123 8958 R1A

CONNECTION REACTIVATION

Opt

iona

l

MME

7. INITIAL UE MESSAGE (Service Request)

12. INITIAL CONTEXT SETUP REQUEST(EPS bearers, Security, UECap Request)

20. INITIAL CONTEXT SETUP RESPONSE(EPS bearers)

1. System Information *

4. RRC CONNECTION REQUEST

5. RRC CONNECTION SETUP

13. RRC SECURITY MODE COMMAND

14.RRC SECURITY MODE COMPLETE

6. RRC CONNECTION SETUP COMPLETE (Service Request)

2. Random Access Preamble

3. Random Access Response

18. RRC CONNECTION RECONFIGURATION (Bearer Setup,Measurement conf))

19. RRC CONNECTION RECONFIGURATION COMPLETE

8.RRC DL INFORMATION TRANSFER (Authentication Request)

9. RRC UL INFORMATION TRANSFER (Authentication Response)

DL NAS TRANSFER (Authentication)

UL NAS TRANSFER (Auth. Response)

10. RRC DL INFORMATION TRANSFER (Security Mode Command)

11. RRC UL INFORMATION TRANSFER (Security Mode Complete)

DL NAS TRANSFER (NAS SMC)

UL NAS TRANSFER (NAS SMC)

CellSelect *

Opt

iona

l

15. RRC UE CAPABILITY ENQUIRY

16. RRC UE CAPABILITY iNFORMATION17. UE CAPABILITY INFO INDICATION

(UE Radio Capability)

RRC IDLE

RRC CONNECTED

Opt

iona

l

Figure 4-27 Traffic Case Connection Reactivation

Steps 1 – 5 are exactly as in the previous traffic case Attach Request. The difference starts with step 6.

1 The UE reads the System Information, broadcasted in the cell.

2 The UE performs cell selection, based on the cell selection parameters received system information and reads the rest of system information in the selected cell. Information available in the system info is also the available set of PRACH resources and their corresponding RA-RNTIs (more about this part can be found in MAC Chapter). UE will randomly select Random Access Preamble and send it to the eNodeB (MAC Protocol)

3 eNodeB answers with Random Access Response (MAC Protocol)


LZT 123 8958 R1A © Ericsson 2009 - 85 -

4 The UE requests establishment of the RRC connection by sending the message RRC Connection Request to the eNodeB. The UE provides the UE id (S-TMSI, IMSI or a random identifier) and the Establishment Cause of the RRC connection establishment. Note! The UE is identified by the S-TMSI if the UE is registered in the TA of the current cell.

5 The eNodeB creates SRB1 and its low layer entities and initiates establishment of the RRC connection by sending the message RRC Connection Setup to the UE.

6 The UE finalizes the establishment of the RRC connection by sending the message RRC Connection Setup Complete to the eNodeB. The UE indicates the selected PLMN and provides a NAS message to the eNodeB. In this case the NAS message is Service Request ( re-activation could have been triggered by Paging, user activity or re-entering the service area)

7 Optional Step: As UE has already been authenticated network can skip the authentication and NAS Security procedures.

8 … Authentication and NAS security Procedure

9 …are explained in the Traffic Case

10 …Attach request

11 …

12 The MME requests the eNodeB to establish the S1 UE context, by sending the Initial Context Setup Request message to the eNodeB. This message includes EPS Bearer parameters (e.g. QCI(s) and the UL TEID(s)) received from the Serving GW to be applied to the user plane connection(s) (i.e. GTP-U tunnel(s)) for the EPS Bearer(s), Security parameters, and optionally the UE Radio Capability Request and/or a NAS message to be sent to the UE. Optionally the message may also include Trace Activation information

13 .eNodeB can re-initiate Integrity protection of RRC signaling and NAS signaling and encryption of the data using RRC Security Mode Command.

14 UE response using RRC Security Mode Complete

15 If UE capability was requested by MME it will be fetched from UE using RRC UE Capability Enquiry message


- 86 - © Ericsson 2009 LZT 123 8958 R1A

16 UE Responds with RRC UE Capability Information.

17 This information is forwarded to the MME using S1 signaling UE Capability Info Indication.

18 The eNodeB establishes the Radio Bearer(s), needed to support the initial EPS Bearer(s), requested in the Initial Context Setup Request message, as well as the measurement configuration to be applied by the UE. If a NAS message was received in step 12, this message is transferred to the UE in the RRC message establishing the Radio Bearer.

19 After successfully establishing the initial Radio Bearer(s), the eNodeB respond to the MME with the Initial Context Setup Response message. This message includes EPS Bearer parameters (e.g. the DL TEID(s) and IP Address)

Now the UE is in the ECM and RRC CONNECTED state

The RRC Connected state takes us to the next RRC Chapter and that is RRC Mobility Management.

RRC MOBILITY MANAGEMENT

In RRC_IDLE state, the UE performs cell reselection based on measurements on neighbouring cellsIn RRC_CONNECTED state, the network always controls the UE mobility using handover based on measurement reportingInter-RAT mobility is standardized

– Intra-3GPP (UTRA, GSM)– Non-3GPP (cdma2000)

Figure 4-28 RRC Mobility

RRC IDLE mobility was covered at Idle Mode Behavior. The aim for this subchapter is to describe Connected Mode Mobility or Network Assisted mobility.

In order to be able to do that lets look into the Measurement and Measurement Reporting mechanisms.


LZT 123 8958 R1A © Ericsson 2009 - 87 -

MEASUREMENT CONFIGURATION

RRC CONNECTION RECONFIGURATION(Measurement configuration)

RRC CONNECTION RECONFIGURATION COMPLETE

Reporting criteria– Reporting threshold– Hysteresis– Time-to-trigger– Reporting interval

Figure 4-29 Measurement Configuration

The UE reports measurement information in accordance with the measurement configuration as provided by E-UTRAN. E-UTRAN provides the measurement configuration applicable for a UE in RRC_CONNECTED by means of dedicated signaling, i.e. using the RRC Connection Reconfiguration message.

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.


- 88 - © Ericsson 2009 LZT 123 8958 R1A

The measurement configuration includes the following parameters:

1. Measurement objects: The objects on which the UE shall perform the measurements. • For intra-frequency and inter-frequency measurements a

measurement object is a single E-UTRA carrier frequency. Associated with this carrier frequency, E-UTRAN can configure a list of cell specific offsets and a list of ‘blacklisted’ cells. Blacklisted cells are not considered in event evaluation or measurement reporting.

• For inter-RAT UTRA measurements a measurement object is a set of cells on a single UTRA carrier frequency.

• For inter-RAT GERAN measurements a measurement object is a set of GERAN carrier frequencies.

• For inter-RAT CDMA2000 measurements a measurement object is a set of cells on a single (HRPD or 1xRTT) carrier frequency.

2. Reporting configurations: A list of reporting configurations where each reporting configuration consists of the following: • Reporting criteria: The criteria that trigger the UE to send a

measurement report. This can either be periodical or a single event description.

• Reporting format: The quantities that the UE includes in the measurement report and associated information (e.g. number of cells to report).

3. Measurement identities: 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.

4. Quantity configurations: One quantity configuration is configured for intra-frequency measurements, one for inter-frequency measurements and one per RAT type. The quantity configuration defines the measurement quantities and associated filtering used for all event evaluation and related reporting of that measurement type. One filter can be configured per measurement quantity.

5. Measurement gaps: Periods that the UE may use to perform measurements, i.e. no (UL, DL) transmissions are scheduled.


LZT 123 8958 R1A © Ericsson 2009 - 89 -

The measurement procedures distinguish the following types of cells:

1. The serving cell.

2. Listed cells - these are cells listed within the measurement object(s).

3. Detected cells - these are cells that are not listed within the measurement object(s) but are detected by the UE on the carrier frequency (ies) indicated by the measurement object(s).

MEASUREMENT REPORTING

Measured results– Event id– Cell identity– Measured measurement quantity

RRC MEASUREMENT REPORT (Measured results)

Reporting criteriafulfilled

Figure 4-30 Measurement Reporting


- 90 - © Ericsson 2009 LZT 123 8958 R1A

Serving becomes worse than threshold1 and inter RAT neighbour becomes better than threshold2Event B2

Inter RAT neighbour becomes better than thresholdEvent B1

Serving becomes worse than threshold1 and neighbour becomes better than threshold2Event A5

Neighbour becomes better than thresholdEvent A4

Neighbour becomes offset better than servingEvent A3

Serving becomes worse than thresholdEvent A2

Serving becomes better than thresholdEvent A1

CriteriaEvent Name

Serving becomes worse than threshold1 and inter RAT neighbour becomes better than threshold2Event B2

Inter RAT neighbour becomes better than thresholdEvent B1

Serving becomes worse than threshold1 and neighbour becomes better than threshold2Event A5

Neighbour becomes better than thresholdEvent A4

Neighbour becomes offset better than servingEvent A3

Serving becomes worse than thresholdEvent A2

Serving becomes better than thresholdEvent A1

CriteriaEvent Name

Figure 4-31 Event List

How does Measurement Command and Measurement reports are inter working is further discussed in the Mobility Chapter.


LZT 123 8958 R1A © Ericsson 2009 - 91 -

5 Packet Data Convergance Protocol

OBJECTIVES

After this chapter the participants will be able to:1. Explain the Interaction between PDCP and the lower layers

2. Explain the functions and services of PDCP.

3. Explain the PDCP procedures.

After this chapter the participants will be able to:1. Explain the Interaction between PDCP and the lower layers

2. Explain the functions and services of PDCP.

3. Explain the PDCP procedures.



- 92 - © Ericsson 2009 LZT 123 8958 R1A

Intentionally Blank


LZT 123 8958 R1A © Ericsson 2009 - 93 -

PACKET DATA CONVERGENCE PROTOCOL (PDCP) PDCP provides its services to the NAS / RRC at the UE or the relay at the evolved Node B (eNB).

The Packet Data Convergence Protocol supports the following functions: • header compression and decompression of IP data flows using

the ROHC (Robust Header Compression) protocol, at the transmitting and receiving entity, respectively.

• transfer of data (user plane or control plane). This function is used for conveyance of data between users of PDCP services.

• maintenance of PDCP sequence numbers for radio bearers for radio bearers mapped on RLC acknowledged mode.

• in-sequence delivery of upper layer PDUs at Handover

• duplicate elimination of lower layer SDUs at Handover for radio bearers mapped on RLC acknowledged mode

• ciphering and deciphering of user plane data and control plane data

• integrity protection of control plane data

• timer based discard

PDCP uses the services provided by the Radio Link Control (RLC) sublayer.

PDCP Services– Transfer of user plane data– Transfer of control plane data– Header compression– Integrity protection of control plane– Ciphering both control and user plane

PDCP Functions– Header compression/decompression

of IP data flows using ROHC– Transfer of data– Maintenence of SNs for radio bearers– In sequence delivery of upper layer

PDUs at re-establishment of lower layers

– Duplicate detection of lower layer SDUs at re-establishment

– Integrity protection/verification of CP– Ciphering/deciphering of data– Timer based discard– Duplicate discarding

TS 36.323

Figure 5-2. Packet Data Convergence Protocol.


- 94 - © Ericsson 2009 LZT 123 8958 R1A

Services provided to upper layers:

PDCP provides its services to the RRC and user plane upper layers at the UE or to the relay at the evolved Node B (eNB). The following services are provided by PDCP to upper layers: • transfer of user plane data;

• transfer of control plane data;

• header compression;

• ciphering;

• integrity protection.

The maximum supported size of a PDCP SDU is 8188 octets.

Services expected from lower layers: • acknowledged data transfer service, including indication of

successful delivery of PDCP PDUs;

• unacknowledged data transfer service;

• in-sequence delivery, except at re-establishment of lower layers;

• Duplicate discarding, except at re-establishment of lower layers.

The PDCP entities are located in the PDCP layer. Several PDCP entities may be defined for a UE. Each PDCP entity carrying user plane data may be configured to use header compression.

Radio Bearers

UE/E-UTRAN

PDCP ...

RLC

PDCP - PDU

RLC - SDU

C-SAP

PDCP-SAP

RLC UM-SAP RLC AM-SAP

PDCP entity PDCP entity

PDCP-SAP

...

TS 36.323

Figure 5-3. PDCP Architecture.


LZT 123 8958 R1A © Ericsson 2009 - 95 -

Each RB (i.e. DRB and SRB, except for SRB0) is associated with one PDCP entity. Each PDCP entity is associated with one or two (one for each direction) RLC entities depending on the RB characteristic (i.e. uni-directional or bi-directional) and RLC mode. The PDCP entities are located in the PDCP sublayer.

The PDCP sublayer is configured by upper layers

Radio Interface (Uu)

UE/E-UTRAN E-UTRAN/UETransmittingPDCP entity

Ciphering

Header Compression(user plane only)

Receiving PDCP entity

Sequence numbering

Integrity Protection (control plane only)

Add PDCP header

Deciphering

Remove PDCP Header

In order delivery and duplicateDetection (U plane)

Integrity Verification (control plane only)

Packets associatedto a PDCP SDU

Header Compression(user plane only)

Packets associatedto a PDCP SDU

Packets N

OT associated

to a PD

CP

SD

U

Packets N

OT associated

to a PD

CP

SD

U

Figure 5-4. PDCP Entity.

Each PDCP entity is carrying the data of one radio bearer. In this version of the specification, only the robust header compression protocol (ROHC), is supported. Every PDCP entity uses at most one ROHC instance.

A PDCP entity is associated either to the control plane or the user plane depending on which radio bearer it is carrying data for.


- 96 - © Ericsson 2009 LZT 123 8958 R1A

SEQUENCE NUMBERING

Sequence numbering is the first PDCP task at reception of an IP package. There are several functions that are using sequence number: • Reordering of the PDCP PDUs at the receiver side

• Duplicate detection in case of packet forwarding at handover

• Used to calculate COUNT and COUNT-C used for integrity protection and ciphering. As illustrated in Figure 5-5 PDCP SN is part of the least significant bits of the counters COUNT and COUNT-C

UEUEUECtxUECtx

SRB1_UL

DRB_UL

COUNT

COUNT

COUNT-C

COUNT-C

HOW:PDCP SN:

Next_PDCP_TX_SN

TX_HFN

COUNT

WHY: * Reordering* Duplicate detection* Integrity protection* Ciphering

eNB

SRB1_DLSRB1_DL

SRB1_UL

DRB_DLDRB_DL

DRB_UL

HFN PDCP SNHFN PDCP SNHFN PDCP SN

Figure 5-5. Sequence numbering.

HEADER COMPRESSION AND DECOPMPRESSION

In many services and applications e.g. Voice over IP, interactive games, messaging etc the payload of the IP packet is sometimes even smaller than a header. Over end-to-end connection, comprised of multiple hops the content of the IP header is extremely important however over just one link (UE to eNodeB , hop-to-hop) some information can be omitted as it will never change due to its static nature during a connection time. It is possible to compress those headers in many cases up to 90%. As a consequence link budget can be improved by several dB due to the decrease in header size.


LZT 123 8958 R1A © Ericsson 2009 - 97 -

WHY: Saving the bandwith by HOW: *removing redundant info

*Encoding important info*Hop by Hop*Unidirectional

RB_ULRB_ULHeader PDCP PDUHeader PDCP PDU PDCP PDU HeaderPDCP PDU HeaderPDCP PDU

Timestamp

Destination address

Source address

Sequence no

Destination portSource port

PTMCCV P X

TTL Protocol Checksum

Fragment offsetFlagsIdentification

Packet lengthTOSV=4 Hlen

IPv4

UDP

STATIC

INFERRED

CHANGES RARELY

CHANGES OFTEN

RTP

Appr. 30 of 40 octets are static or easily compressible!

Checksum

SSRC Identifier

Length

8

Timestamp

Destination address

Source address

Sequence no


PTMCCV P X




IPv4

UDP

STATIC

INFERRED

CHANGES RARELY

CHANGES OFTEN

RTP


Checksum

SSRC Identifier

Length

8

Timestamp

Destination address

Source address

Sequence no


PTMCCV P X




IPv4

UDP

STATIC

INFERRED

CHANGES RARELY

CHANGES OFTEN

RTP


Checksum

SSRC Identifier

Length

8

CRCchecksum covering the header beforecompression is included in the compressed header

Compressed HeaderContains encoded data

UE/UE Context

UE/UE Context

Figure 5-6. Header Compression.

In the low bandwidth networks, using header compression results in a better response time due to smaller packet sizes.

Header Compression has to be negotiated at the time of the link set up. Both sides of the link needs to be capable of running the same header compression algorithms.

The header compression protocol specified in PDCP is based on the Robust Header Compression (ROHC) framework IETF RFC 3095. There are multiple header compression algorithms, called profiles, defined for the ROHC framework. Each profile is specific to the particular network layer, transport layer or upper layer protocol combination e.g. TCP/IP and RTP/UDP/IP.


- 98 - © Ericsson 2009 LZT 123 8958 R1A

Header compression

The header compression protocol generates two types of output packets: • compressed packets, each associated with one PDCP SDU

• standalone packets not associated with a PDCP SDU, i.e. interspersed ROHC feedback packets

A compressed packet is associated with the same PDCP SN and COUNT value as the related PDCP SDU.

Interspersed ROHC feedback packets are not associated with a PDCP SDU. They are not associated with a PDCP SN and are not ciphered.

Header decompression

If header compression is configured by upper layers for PDCP entities associated with u-plane data the PDCP PDUs are de-compressed by the header compression protocol after performing deciphering.

SECURITY HANDLING

Traffic security for the radio interface comprises integrity protection and ciphering of the RRC messages as well as ciphering of UP data messages.

Integrity protection is implemented in the PDCP layer in order to ensure that the data origin of the signaling data is indeed the one claimed. It also allows the receiving entity to verify that the received data has not been modified in an unauthorized way.

The purpose of the data encryption (ciphering) is to ensure that the user data cannot be eavesdropped on the radio


LZT 123 8958 R1A © Ericsson 2009 - 99 -

Integrity Protection and Verification

The integrity protection function includes both integrity protection and integrity verification and is performed in PDCP for PDCP entities associated with SRBs. The data unit that is integrity protected is the PDU header and the data part of the PDU before ciphering.

EIAEIACOUNTDirectionK_eNB_RRCInt

PDCP PDUPDCP PDUHeader PDCP SDU

Bearer Id

MAC-I

PD

CP PD

UH

eaderP

DC

P S

DU

PD

CP PD

UH

eaderP

DC

P S

DU

EIAEIACOUNT

DirectionK_eNB_RRCInt

PDCP PDUPDCP PDUHeaderPDCP SDU

Bearer Id

XMAC-I

XMAC-IMAC-I =

Sending SideUE/eNB

Receiving SideUE/eNB

WHY: To ensure data origin

Figure 5-7 Integrity Protection.

The integrity protection key to be used by the PDCP entity is generated during EPS Authentication and Key Agreement function UE Computes the KASME based on the parameters received in the Authentication Request message and the MME receives the KASME. from HSS. KASME is further used to generate K_eNB. Using key derivation function KRRCenc, KRRC int and KUPenc are derived from K_eNB.

Which algorithm to use is decided by eNodeB by during RRC security activation, the integrity protection function shall be applied to all control plane PDUs for the downlink and the uplink, respectively.


- 100 - © Ericsson 2009 LZT 123 8958 R1A

NOTE: As the RRC message which activates the integrity protection function is itself integrity protected with the configuration included in this RRC message, this message needs first be decoded by RRC before the integrity protection verification could be performed for the PDU in which the message was received.

The parameters that are required by PDCP for integrity protection are defined in 3GPP TS 33.401 and are input to the integrity protection algorithm. The required inputs to the integrity protection function include the COUNT value, and DIRECTION (DL or UL). The parameters required by PDCP which are provided by upper layers:

• BEARER defined as the radio bearer identifier, (SRB1 will use

the value RB identity –1)

• KEY (KRRCint).

At transmission, the UE computes the value of the Message Authentication Code – Integrity (MAC-I) field and at reception it verifies the integrity of the PDCP PDU by calculating the Expected Message Authentication Code Integrity (X-MAC-I) based on the input parameters as specified above. If the calculated X-MAC is equal to the received MAC-I, integrity protection is verified successfully.

When a PDCP entity receives a PDCP PDU that contains reserved or invalid values, the PDCP entity shall discard the received PDU.


LZT 123 8958 R1A © Ericsson 2009 - 101 -

Ciphering and Deciphering.

The ciphering function in PDCP includes both ciphering and deciphering and is performed in PDCP. For the control plane, the data unit that is ciphered is the data part of the PDCP PDU and the MAC-I. For the user plane, the data unit that is ciphered is the data part of the PDCP PDU; ciphering is not applicable to PDCP Control PDUs.

PLAINTEXTBLOCK

PLAINTEXTBLOCK

EEA

COUNT-C/COUNT DIRECTION

BEARER LENGTH

KEYUPenc

KEYSTREAM BLOCK

CIPHERTEXTBLOCK

CIPHERTEXTBLOCK

EEA

DIRECTION

BEARER LENGTH

KEYSTREAM BLOCK

PLAINTEXTBLOCK

PLAINTEXTBLOCK

Sender Receiver

EEA0EEA1EEA2

COUNT-C/COUNT

WHY: To protect the data over radio

KEYUPenc

Figure 5-8. Ciphering.

The encryption key to be used by the PDCP entity is generated during EPS Authentication and Key Agreement function UE Computes the KASME based on the parameters received in the Authentication Request message and the MME receives the KASME. from HSS. KASME is further used to generate K_eNB. Using key derivation function KRRCenc, KRRC int and KUPenc are derived from K_eNB

The ciphering function is activated by upper layers as defined in 3GPP TS 36.331. After security activation, the ciphering function shall be applied to all PDCP PDUs indicated by upper layers for the downlink and the uplink, respectively.

The parameters that are required by PDCP for ciphering are defined in 3GPP TS 33.401 and are input to the ciphering algorithm. The required inputs to the ciphering function include the: • COUNT , and


- 102 - © Ericsson 2009 LZT 123 8958 R1A

• DIRECTION (DL or UL).

• BEARER (defined as the radio bearer identifier );

• KEY (the ciphering keys for the control plane and for the user plane are KRRCenc and KUPenc, respectively).

PDCP PDU FORMATS

There are two type of PDCP PDUs: • PDCP Data PDUs and

• PDCP Control PDUs

As listed in the Figure 5-9 PDCP Data PDUs are used to convey both Control plane and User plane SDUs.

The PDCP Data PDU is used to convey:

1. A PDCP SDU SN2. User plane data containing uncompressed PDCP SDU3. User plane data containing compressed PDCP SDU4. Control plane data5. MAC-I field (for SRB only)

Figure 5-9. PDCP Data PDU.

Left part of Figure 5-10 shows the format of the PDCP Data PDU carrying data for control plane SRBs.

Upper right part of Figure 5-10 shows the format of the PDCP Data PDU when a 12 bit SN length is used. This format is applicable for PDCP Data PDUs carrying data from DRBs mapped on RLC AM or RLC UM.

Lower right part of Figure 5-10 shows the format of the PDCP Data PDU when a 7 bit SN length is used. This format is applicable for PDCP Data PDUs carrying data from DRBs mapped on RLC UM


LZT 123 8958 R1A © Ericsson 2009 - 103 -

Oct 1

Oct 2

Oct N

Oct N-1

Oct N-2

Oct N-3

...

Data

PDCP SNR R R

MAC-I

MAC-I (cont.)

MAC-I (cont.)

MAC-I (cont.)

Oct 1

Oct 2

Oct N

Oct N-1

Oct N-2

Oct N-3

...

Data

PDCP SNR R R

MAC-I

MAC-I (cont.)

MAC-I (cont.)

MAC-I (cont.)

...

PDCP SN (cont.)

Data

D/C PDCP SNR R R Oct 1

Oct 2

Oct 3

...

D/C PDCP S N Oct 1

Oct 2Data

PDCP Data: PDU format SRB PDCP Data: PDU format DRB:SN 12 bits mapped to RLC AM/UMSN 7 bits mapped to RLC UM

Figure 5-10 PDCP Data PDU format

Left part of Figure 5-11 shows the format of the PDCP Control PDU carrying one interspersed ROHC feedback packet. This format is applicable for DRBs mapped on RLC AM or RLC UM

Right part of Figure 5-11 shows the format of the PDCP Control PDU carrying one PDCP status report. This format is applicable for DRBs mapped on RLC AM.

PDCP Contorol: ROCH feedback

...

Interspersed ROHC feedback packet

D/C PDU Type R RR R Oct 1

Oct 2

PDCP Contorol: STATUS Report

...

Bitmap 1 (optional)

D/C PDU Type

BitmapN (optional )

FMS (cont.)

FMS Oct 1

Oct 2

Oct 3

Oct 2+N

D/C Data/ControlFMS First Missing PDCP SNROHC RObust Header Compression

Figure 5-11. PDCP Control PDU format.


- 104 - © Ericsson 2009 LZT 123 8958 R1A

Intentionally Blank


LZT 123 8958 R1A © Ericsson 2009 - 105 -

6 Radio Link Control (RLC) and Medium Access Control (MAC) Protocols

OBJECTIVES

After this chapter the participants will be able to:

1. Explain the RLC functions

2. List the different modes of RLC (transparent, unacknowledged and acknowledged mode) and explain the structure of the PDU involved in these cases.

3. Explain the MAC functions.

4. Explain the MAC architecture, its entities and their usage for the mapping of transport channels.

5. List the contents of the MAC Packet Data Unit (PDU)



- 106 - © Ericsson 2009 LZT 123 8958 R1A

Intentionally Blank


LZT 123 8958 R1A © Ericsson 2009 - 107 -

RADIO LINK CONTROL PROTOCOL Radio Link Control (RLC) Protocol Layer is a Layer 2 protocol.

It is controlled and configured by RRC layer but it offeres services both to RRC and PDCP protocols. As listed in the Figure 6-2 RLC is responsible for providing data transfer to/from the upper layers: (PDCP and RRC) in three different modes:

RLC ServicesRLC Services Provided to Upper Layers:

– Transparent data transfer– Unacknowledged data transfer– Acknowledged data transfer

RLC Services Expected From Lower Layers:– Data transfer– Notification of a transmission opportunity– Notification of HARQ delivery failure from transmitting MAC

entityRLC Functions

– Segmentation and re-assembly– Concatenation– Padding– Transfer of user data in TM, UM and AM.– Error correction (ARQ) – In-sequence delivery– Duplicate detection– Flow control– RLC Re-establishment– Protocol Error Detection and Recovery

TS 36.321

Figure 6-2 RLC Functions and Services

• TM Transparent Mode

• UM Unacknowledged Mode

• AM Acknowledged Mode

Functions of the RLC protocols are performed by the RLC entities. For an RLC entity in eNB there is a corresponding RLC entity in the UE and vice versa. An RLC entity can be configured to operate in TM, UM or AM mode Figure 6-3 illustrates RLC entities. TM and UM RLC entities are independent of each other in UL and DL and are configured to be either receiving or transmitting entity. For AM mode RLC entities there is dependency that is related to ARQ mechanism. AM RLC entities are also configured to be either receiving or transmitting entity.


- 108 - © Ericsson 2009 LZT 123 8958 R1A

radio interface

lower layers(i.e. MAC sub layer and physical layer)

transmittingTM RLC entity

transmittingUM RLC entity

AM RLC entityreceiving

TM RLC entityreceiving

UM RLC entity

receivingTM RLC entity

receivingUM RLC entity

AM RLC entitytransmitting

TM RLC entitytransmitting

UM RLC entity


upper layer (i.e. RRC layer or PDCP sub layer)


radio interface


transmittingTM RLC entity

transmittingUM RLC entity

AM RLC entityreceiving

TM RLC entityreceiving

UM RLC entity

receivingTM RLC entity

receivingUM RLC entity

AM RLC entitytransmitting

TM RLC entitytransmitting

UM RLC entity




eNB

UE

SAP betweenupper layers

logical channel

logical channel

SAP betweenupper layers

Figure 6-3 Overview model of the RLC

Following applies to all three RLC entity types: • RLC SDUs of variable sizes are byte aligned

• RLC PDUs are formed only when transmission opportunity has been notified by lower layer and then delivered to lower layer

Differences are described in following subchapters.


LZT 123 8958 R1A © Ericsson 2009 - 109 -

RLC TM ENTITY

Transparent Mode RLC entity is illustrated in Figure 6-4.

Transmissionbuffer

Transmitting TM-RLC entity

TM-SAP

radio interface

Receiving TM-RLC

entity

TM-SAP

UE/ENB ENB/UE

BCCH/PCCH/CCCH BCCH/PCCH/CCCH

Figure 6-4 RLC TM Entity

It can be configured to deliver/receive RLC PDUs through following logical channels: • BCCH Broadcast Control Channel (System Information

transfer)

• DL/UL CCCH Common Control Channel ( example: RRC Connection Request )

• PCCH Paging Control Channel (Paging)

When transmitting TM RLC SDUs TM Entity does not perform any segmentation nor concatenation of the data received and does not include any header information.

The size of the data i.e the fraction that is scheduled for the RLC TM entity indicated by the lower layer at the particular transmission opportunity must be large enough to fit TMD PDU

Receiving TM Entity just sends received data to the upper layer (RRC).


- 110 - © Ericsson 2009 LZT 123 8958 R1A

RLC UM ENTITY

RLC UM Entity is illustrated in Figure 6-5.

Transmissionbuffer

Segmentation &Concatenation

Add RLC header

Transmitting UM -RLC entity

UM -SAP

radio interface

Receiving UM-RLC

entity

UM-SAP

UE /ENB ENB /UE

DTCH DTCH

Receptionbuffer & HARQ

reordering

SDU reassembly

Remove RLC header

Figure 6-5 RLC UM Entity

It can be configured to send or receive the data sent on the DL/UL DTCH i.e. UM RLC entity is supposed to carry user data payload for the time critical services such as Voice over IP

Transmitting UM RLC entity segments and/or concatenates the RLC SDUs so that UMD PDU fit within the total size of RLC PDU indicated by the lower layer at the particular transmission opportunity.

As segmentation and/or concatenation is applicable an RLC header needs to be included.

Receiving UM RLC Entity:

1 Detects weather or not the UMD PDUs have been received already (duplicate detection) and if so discard the UMD PDU.


LZT 123 8958 R1A © Ericsson 2009 - 111 -

2 Reorders in case UMD PDUs are received out of sequence.

3 Reassembles RLC SDUs from reordered UMD PDUs and deliver the RLC SDUs to upper layer in ascending order of RLC SN.

4 Discards received UMD PDus that can not be re assembled into RLC SDUs due to loss at lower layers

In case of RLC reestablishment the receiving UM RLC Entity

5 If possible reassembles RLC SDUs from UMD PDUs that are received out of sequence and deliver them to upper layer

6 Discards any remaining UMD PDUs that could not be reassembled into RLC SDUs.

RLC AM ENTITY

RLC Am Entity is illustrated in Figure 6-6.

Transmissionbuffer

Segmentation &Concatenation

Add RLC header

Retransmission buffer

RLC control

Routing

Receptionbuffer & HARQ

reordering

SDU reassembly

DCCH /DTCH DCCH /DTCH

AM -SAP

Remove RLC header

Figure 6-6 RLC AM Entity


- 112 - © Ericsson 2009 LZT 123 8958 R1A

It can be configured to send or receive the data sent on the DL/UL DTCH DL/UL DCCH i.e. majority of the signaling and user data will be sent using RLC AM entity.

When the transmitting side of an AM RLC entity forms AMD PDUs from RLC SDUs, it:

1 Segments and/or concatenates the RLC SDUs so that the AMD PDUs fit within the total size of RLC PDU(s) indicated by lower layer at the particular transmission opportunity notified by lower layer.

2 The transmitting side of an AM RLC entity supports retransmission of RLC data PDUs (ARQ). If the RLC data PDU to be retransmitted does not fit within the total size of RLC PDU(s) indicated by lower layer at the particular transmission opportunity notified by lower layer, the AM RLC entity can re-segment the RLC data PDU into AMD PDU segments. The number of re-segmentation is not limited.

3 When the transmitting side of an AM RLC entity forms AMD PDUs from RLC SDUs received from upper layer or AMD PDU segments from RLC data PDUs to be retransmitted, it includes relevant RLC headers in the RLC data PDU

When the receiving side of an AM RLC entity receives RLC data PDUs it:

1 Detects whether or not the RLC data PDUs have been received in duplication, and discard duplicated RLC data PDUs;

2 Reorders the RLC data PDUs if they are received out of sequence;

3 Detects the loss of RLC data PDUs at lower layers and request retransmissions to its peer AM RLC entity;

4 Reassembles RLC SDUs from the reordered RLC data PDUs and deliver the RLC SDUs to upper layer in sequence.


LZT 123 8958 R1A © Ericsson 2009 - 113 -

At the time of RLC re-establishment, the receiving side of an AM RLC entity (eNodeB):

1 if possible, reassembles RLC SDUs from the RLC data PDUs that are received out of sequence and deliver them to upper layer;

2 Discards any remaining RLC data PDUs that could not be reassembled into RLC SDUs;

3 Initializes relevant state variables and stop relevant timers.

RLC PDU

As listed in the Figure 6-7 there are two types of RLC PDUs

RLC Data PDU– TM PDU, UM PDU, AM PDU and AMD PDU

Segment

RLC Control PDU– STATUS PDU

Figure 6-7 RLC PDU Types

RLC Data PDUs will carry both control plane and user plane signaling that origins from RRC or PDCP while RLC Control PDUs carries control information between RLC peer

RLC TM PDU

TM PDU is illustrated in Figure 6-8 and as already mentioned does not introduce any overhead in terms of RLC header. It consists of Data field only and is octet aligned

The RLC TM PDU introduces no overhead

TM is used for signaling on BCCH and PCCH. Figure 6-8 RLC TM PDU Format


- 114 - © Ericsson 2009 LZT 123 8958 R1A

RLC UM PDU

UM PDU is illustrated in Figure 6-9, Figure 6-10 and Figure 6-11

UM RLC Entity configured by RRC to use either 5 bit SN or 10 bit SNHeader: Fixed Part (FI, E, SN) + Extension Part (E(s), LI(s))

UMD PDU with 5 bit SN (No LI ) UMD PDU with 10 bit SN (No LI )

Figure 6-9 RLC UM PDU Format No LI

UMD PDU with 5 bit SN (Odd number of LIs, i.e. K = 1, 3, 5, …)

PDU with 5 bit SN (Even number of LIs, i.e. K = 2, 4, 6, …)

Figure 6-10 RLC UM PDU Format with LI SN 5


LZT 123 8958 R1A © Ericsson 2009 - 115 -

UMD PDU with 10 bit SN (Odd number of LIs, i.e. K = 1, 3, 5, …)

UMD PDU with 10 bit SN (Even number of LIs, i.e. K = 2, 4, 6, …)

Figure 6-11 RLC UM PDU with LI SN 10

UMD PDU consists of a Data field and an UMD PDU header.

UMD PDU header consists of a fixed part (fields that are present for every UMD PDU) and an extension part (fields that are present for an UMD PDU when necessary). The fixed part of the UMD PDU header itself is octet aligned and consists of a FI, an E and a SN. The extension part of the UMD PDU header consists of E(s) and LI(s).

An UM RLC entity is configured by RRC to use either a 5 bit SN or a 10 bit SN. When the 5 bit SN is configured, the length of the fixed part of the UMD PDU header is one byte. When the 10 bit SN is configured, the fixed part of the UMD PDU header is identical to the fixed part of the AMD PDU header, except for D/C, RF and P fields all being replaced with R1 fields. The extension part of the UMD PDU header is identical to the extension part of the AMD PDU header (regardless of the configured SN size).

An UMD PDU header consists of an extension part only when more than one Data field elements are present in the UMD PDU, in which case an E and a LI are present for every Data field element except the last. Furthermore, when an UMD PDU header consists of an odd number of LI(s), four padding bits follow after the last LI


- 116 - © Ericsson 2009 LZT 123 8958 R1A

RLC AM PDU

RLC AM PDU is illustrated in Figure 6-12 and Figure 6-13

AM RLC Entity uses10 bit SNHeader: Fixed Part (D/C, RF, P, FI, E, SN) + Extension Part (E(s), LI(s))

AMD PDU with 10 bit SN (No LI ) Figure 6-12 RLC AM PDU No LI

Figure 6-13 RLC AM PDU with LI and SN

AMD PDU consists of a Data field and an AMD PDU header.

AMD PDU header consists of a fixed part (fields that are present for every AMD PDU) and an extension part (fields that are present for an AMD PDU when necessary). The fixed part of the AMD PDU header itself consists of a D/C, a RF, a P, a FI, an E and a SN. The extension part of the AMD PDU header consists of E(s) and LI(s).

An AMD PDU header consists of an extension part only when more than one Data field elements are present in the AMD PDU, in which case an E and a LI are present for every Data field element except the last. Furthermore, when an AMD PDU header consists of an odd number of LI(s), four padding bits follow after the last LI


LZT 123 8958 R1A © Ericsson 2009 - 117 -

AMD PDU segment

AMD PDU segment consists of a Data field and an AMD PDU segment header.

AMD PDU segment header consists of a fixed part (fields that are present for every AMD PDU segment) and an extension part (fields that are present for an AMD PDU segment when necessary). The fixed part of the AMD PDU segment header consists of a D/C, a RF, a P, a FI, an E, a SN, a LSF and a SO. The extension part of the AMD PDU segment header consists of E(s) and LI(s).

An AMD PDU segment header consists of an extension part only when more than one Data field elements are present in the AMD PDU segment, in which case an E and a LI are present for every Data field element except the last. Furthermore, when an AMD PDU segment header consists of an odd number of LI(s), four padding bits follow after the last LI.

STATUS PDU

RLC Control PDU – Status PDU is illustrated in Figure 6-14.

Figure 6-14 Status PDU

STATUS PDU consists of a STATUS PDU payload and a RLC control PDU header.

RLC control PDU header consists of a D/C and a CPT field.


- 118 - © Ericsson 2009 LZT 123 8958 R1A

The STATUS PDU payload starts from the first bit following the RLC control PDU header, and it consists of one ACK_SN and one E1, zero or more sets of a NACK_SN, an E1 and an E2, and possibly a set of a SOstart and a SOend for each NACK_SN. When necessary one to seven padding bits are included in the end of the STATUS PDU to achieve octet alignment.

Field Definitions

Extension Bit

A set of E field and LI field follows from the octet following the fixed part of the header1

Data field follows from the octet following the fixed part of the header0

DescriptionValue

A set of E field and LI field follows from the octet following the fixed part of the header1

Data field follows from the octet following the fixed part of the header0

DescriptionValue

A set of E field and LI field follows from the bit following the LI field following this E field

1

Data field follows from the octet following the LI field following this E field0

DescriptionValue

A set of E field and LI field follows from the bit following the LI field following this E field

1

Data field follows from the octet following the LI field following this E field0

DescriptionValue

Figure 6-15 Extension Bit: Table 1 fixed header; Table2 extension part of the header

Length Indicator (LI) fieldThe LI field indicates the length in bytes of the corresponding Data field element present in the RLC data PDU delivered/received by an UM or an AM RLC entity.

The value 0 is reserved.

Figure 6-16 Length Indicator

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.

11

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.

10

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.

01

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.

00

DescriptionValue

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.

11

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.

10

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.

01

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.

00

DescriptionValue

Figure 6-17 Framing Information field


LZT 123 8958 R1A © Ericsson 2009 - 119 -

The Segment Offset field indicates the position of the AMD PDU segment in bytes within the original AMD PDU.

The first byte in the Data field of the original AMD PDU is referred by the SO field value "000000000000001", i.e., numbering starts at one

Figure 6-18 Segment Offset

Last byte of the AMD PDU segment corresponds to the last byte of an AMD PDU.1

Last byte of the AMD PDU segment does not correspond to the last byte of an AMD PDU.0

DescriptionValue

Last byte of the AMD PDU segment corresponds to the last byte of an AMD PDU.1

Last byte of the AMD PDU segment does not correspond to the last byte of an AMD PDU.0

DescriptionValue

Figure 6-19 Last Segment Flag field

Status report is requested1

Status report not requested0

DescriptionValue

Status report is requested1

Status report not requested0

DescriptionValue

Figure 6-20 Polling Bit

Reserved(PDUs with this coding will be discarded by the receiving entity for this

release of the protocol)

001-111

STATUS PDU000

DescriptionValue

Reserved(PDUs with this coding will be discarded by the receiving entity for this

release of the protocol)

001-111

STATUS PDU000

DescriptionValue

Figure 6-21 Control PDU Type


- 120 - © Ericsson 2009 LZT 123 8958 R1A

Variables Constants and Timers AM mode

RETX_COUNT

T_status_prohibit

T_reorderingT_poll_retransmit

Timers

BYTE_WITHOUT_POLL

PDU_WITHOUT_POLL

Counters

VR(H)Highest received state variable

VR(MS)Maximum STATUS transmit state variablePOLL_SNPoll send state variable

VR(X)T_reordering state variableVT(S)Send state variable

VR(MR)Maximum acceptable receive state variableVT(MS)Maximum send state variable

VR(R)Receive state variableVT(A)Acknowledgement state variable

Receiving sideTransmitting side

RETX_COUNT

T_status_prohibit

T_reorderingT_poll_retransmit

Timers

BYTE_WITHOUT_POLL

PDU_WITHOUT_POLL

Counters

VR(H)Highest received state variable

VR(MS)Maximum STATUS transmit state variablePOLL_SNPoll send state variable

VR(X)T_reordering state variableVT(S)Send state variable

VR(MR)Maximum acceptable receive state variableVT(MS)Maximum send state variable

VR(R)Receive state variableVT(A)Acknowledgement state variable


Figure 6-22 Transmitting vs Receiving RLC AM Entity variables, constants and timers

The transmitting side of each AM RLC entity maintains the following state variables:

a) VT(A) – Acknowledgement state variable

This state variable holds the value of the SN of the next AMD PDU for which a positive acknowledgment is to be received in-sequence, and it serves as the lower edge of the transmitting window. It is initially set to 0, and is updated whenever the AM RLC entity receives a positive acknowledgment for an AMD PDU with SN = VT(A).

b) VT(MS) – Maximum send state variable

This state variable equals VT(A) + AM_Window_Size, and it serves as the higher edge of the transmitting window.

c) VT(S) – Send state variable

This state variable holds the value of the SN to be assigned for the next newly generated AMD PDU. It is initially set to 0, and is updated whenever the AM RLC entity delivers an AMD PDU with SN = VT(S).


LZT 123 8958 R1A © Ericsson 2009 - 121 -

d) POLL_SN – Poll send state variable

This state variable holds the value of VT(S)-1 upon the most recent transmission of a RLC data PDU with the poll bit set to “1”. It is initially set to 0.

The transmitting side of each AM RLC entity maintains the following counters:

a) PDU_WITHOUT_POLL – Counter

This counter is initially set to 0. It counts the number of AMD PDUs sent since the most recent poll bit was transmitted.

b) BYTE_WITHOUT_POLL – Counter

This counter is initially set to 0. It counts the number of data bytes sent since the most recent poll bit was transmitted

c) RETX_COUNT – Counter This counter is initially set to 0. It counts the number of retransmissions of an AMD PDU

The receiving side of each AM RLC entity maintains the following state variables:

a) VR(R) – Receive state variable

This state variable holds the value of the SN following the last in-sequence completely received AMD PDU, and it serves as the lower edge of the receiving window. It is initially set to 0, and is updated whenever the AM RLC entity receives an AMD PDU with SN = VR(R).

b) VR(MR) – Maximum acceptable receive state variable

This state variable equals VR(R) + AM_Window_Size, and it holds the value of the SN of the first AMD PDU that is beyond the receiving window and serves as the higher edge of the receiving window.

c) VR(X) – T_reordering state variable

This state variable holds the value of the SN following the SN of the RLC data PDU which triggered T_reordering. It is initially set to NULL.


- 122 - © Ericsson 2009 LZT 123 8958 R1A

d) VR(MS) – Maximum STATUS transmit state variable

This state variable holds the highest possible value of the SN which can be indicated by “ACK_SN” when a STATUS PDU needs to be constructed. It is initially set to 0.

e) VR(H) – Highest received state variable

This state variable holds the value of the SN following the SN of the RLC data PDU with the highest SN among received RLC data PDUs. It is initially set to 0.

Variable Constants and Timers UM Mode

VR(UH)UM Highest received state variable

VR(UX)UM_T_reordering state variableVT(S)Send state variable

VR(UR)Receive state variableVT(US)Acknowledgement state variable


VR(UH)UM Highest received state variable

VR(UX)UM_T_reordering state variableVT(S)Send state variable

VR(UR)Receive state variableVT(US)Acknowledgement state variable


Figure 6-23 Transmitting vs Receiving RLC UM Entity variables, constants and timers

Each transmitting UM RLC entity maintains the following state variables:

a) VT(US)

This state variable holds the value of the SN to be assigned for the next newly generated UMD PDU. It is initially set to 0, and is updated whenever the UM RLC entity delivers an UMD PDU with SN = VT(US).

Each receiving UM RLC entity maintains the following state variables:

a) VR(UR) – UM receive state variable

This state variable holds the value of the SN of the earliest UMD PDU that is still considered for reordering. It is initially set to 0.

b) VR(UX) – UM T_reordering state variable

This state variable holds the value of the SN following the SN of the UMD PDU which triggered T_reordering. It is initially set to NULL.


LZT 123 8958 R1A © Ericsson 2009 - 123 -

c) VR(UH) – UM highest received state variable

This state variable holds the value of the SN following the SN of the UMD PDU with the highest SN among received UMD PDUs, and it serves as the higher edge of the reordering window. It is initially set to 0.


- 124 - © Ericsson 2009 LZT 123 8958 R1A

MEDIUM ACCESS CONTROL PROTOCOL Medium Access Control (MAC) Protocol Layer is a Layer 2 protocol.

It is configured by RRC. E-UTRA defines two MAC Entities: • One in the UE

• One in the eNodeB

Functions performed by these function entities are different as MAC entity on the E-UTRAN side is responsible for handling transmission/reception of the data for/from more than one UE and MAC entity on the UE side is responsible for transmission/reception of own data.

MAC Services– Data Transfer– Reallocation of resources

MAC Functions– Mapping between logical channels and transport channels– Multiplexing of MAC SDUs from one or different logical channels onto

transport block (TB) to be delivered to the physical layer on a transport channel

– Demultiplexing of MAC SDUs from one or different logical channels from transport block (TB) to be delivered from the physical layer on a transport channel

– Scheduling information reporting– Error Correction (HARQ)– Priority handling between UEs by means of dynamic scheduling– Priority handling between logical channels of one UE– Logical channel prioritization– Transport Format selection

Random Access Control

PCCH BCCH CCCH DCCH DTCH MAC-controlUpper layers

PCH BCH DL-SCH UL-SCH RACH

Lower layer

(De-) Multiplexing

Logical Channel Prioritization (

HARQ

Control

Figure 6-24 MAC Protocol Entity.


LZT 123 8958 R1A © Ericsson 2009 - 125 -

Figure 6-25 illustrates MAC structure on the UE side.


PCCH BCCH CCCH DCCH DTCH MAC-control

Upper layers

PCH BCH DL-SCH UL-SCH RACH

Lower layer

(De-) Multiplexing

Logical Channel Prioritization (UL only)

HARQ

Control

Figure 6-25 MAC Structure UE Side

Figure 6-26 illustrates MAC Architecture on the E-UTRAN (eNodeB) side.

Scheduling / Priority Handling

Multiplexing

DCCH DTCHCCCH

HARQ

DL-SCH HARQ Feedback

Control

HARQ

Demultiplexing

DCCH DTCH

UL-SCH

CCCH

MAC Control

BCCHPCCH

Scheduling / Priority Handling

HARQ

HARQ Feedback P

DC

CH

PU

CC

HS

RS

ched

uler

BCHPCH DL-SCH

Figure 6-26 MAC Structure – E-UTRAN side (RACH not shown)


- 126 - © Ericsson 2009 LZT 123 8958 R1A

The exact location of the functions for each MAC entity can be seen in the Figure 6-27.

XXScheduling information reporting

XXLogical Channel prioritisation

XXXPriority handling between logical channels of one UE

XXXPriority handling between UEs

XXXTransport Format Selection

XXX

XXXError correction through HARQ

XX

XXDemultiplexing

XX

XXMultiplexing

XXX

XXXMapping between logical channels and transport channels

UplinkDownlinkeNBUEMAC function

XXScheduling information reporting

XXLogical Channel prioritisation

XXXPriority handling between logical channels of one UE

XXXPriority handling between UEs

XXXTransport Format Selection

XXX

XXXError correction through HARQ

XX

XXDemultiplexing

XX

XXMultiplexing

XXX

XXXMapping between logical channels and transport channels

UplinkDownlinkeNBUEMAC function

Figure 6-27 MAC Function location

MAPPING BETWEEN LOGICAL CHANNELS AND TRANSPORT CHANNELS

Mapping of the logical channels to transport channels is the task for both MAC entities. In DL MAC function entity placed in the E-UTRAN is responsible for mapping Logical channels to Transport channels and mapping from Transport Channels to Logical Channels in UL.

What is a Logical Channel? What is a Transport Channel?

Logical Channel is a service that MAC provides to upper protocol layer (RLC) and indicates WHAT type of the data is sent: • Control Information

• Traffic Information

Control Channels provided by MAC to RLC are listed in Figure 6-28


LZT 123 8958 R1A © Ericsson 2009 - 127 -

Broadcast Control Channel (BCCH)– DL broadcast of system control information.

Paging Control Channel (PCCH)– DL paging information. UE position not known on cell level

Common Control Channel (CCCH)– UL/DL. When no RRC connection exists.

Multicast Control Channel (MCCH)– DL point-to-multipoint for MBMS scheduling and control, for one

or several MTCHs. Dedicated Control Channel (DCCH)

– UL/DL dedicated control information. Used by UEs having an RRC connection.

Figure 6-28 Control Logical Channels

Traffic Channels provided by MAC to RLC are listed in Figure 6-29

Dedicated Traffic Channel (DTCH)– UL/DL Dedicated Traffic to one UE, user information.

Multicast Traffic Channel (MTCH)– DL point-to-multipoint. MBMS user data.

Figure 6-29 Traffic Logical Channels

Transport Channel is a service that is provided to MAC by Physical layer and indicated HOW and with WHAT CHARACTERISTICS the data will be sent.

Figure 6-30 and Figure 6-31 are listing DL and UL Transport Channels

Broadcast Channel (BCH)– System Information broadcasted in the entire coverage area of

the cell. Beamforming is not applied.Downlink Shared Channel (DL-SCH)

– User data, control signaling and System Info. HARQ and link adaptation. Broadcast in the entire cell or beamforming. DRX and MBMS supported.

Paging Channel (PCH) – Paging Info broadcasted in the entire cell. DRX

Multicast Channel (MCH) – MBMS traffic broadcasted in entire cell. MBSFN is supported.

Figure 6-30 Transport Channels DL


- 128 - © Ericsson 2009 LZT 123 8958 R1A

Uplink Shared channel (UL-SCH)– User data and control signaling. HARQ and link adaptation.

Beamforming may be applied.Random Access Channel (RACH)

– Random Access transmissions (asynchronous and synchronous). The transmission is typically contention based. For UEs having an RRC connection there is some limited support for contention free access.

Figure 6-31 Transport Channel UL

Further there are Physical channels that do not belong to MAC Protocol layer but are L1 property. However they are listed in are for the completeness of the channel picture.

Physical channelsPhysical Downlink Shared Channel (PDSCH)

– transmission of the DL-SCH transport channelPhysical Uplink Shared Channel (PUSCH)

– transmission of the UL-SCH transport channelPhysical Control Format Indicator Channel (PCFICH)

– indicates the PDCCH format in DLPhysical Downlink Control Channel (PDCCH)

– DL L1/L2 control signalingPhysical Uplink Control Channel (PUCCH)

– UL L1/L2 control signalingPhysical Hybrid ARQ Indicator Channel (PHICH)

– DL HARQ infoPhysical Broadcast Channel (PBCH)

– DL transmission of the BCH transport channel.Physical Multicast Channel (PMCH)

– DL transmission of the MCH transport channel.Physical Random Access Channel (PRACH)

– UL transmission of the random access preamble as given by the RACH transport channel.Physical signals

Reference Signals (RS)– support measurements and coherent demodulation in uplink and downlink.

Primary and Secondary Synchronization signals (P-SCH and S-SCH)– DL only and used in the cell search procedure.

Sounding Reference Signal (SRS)– supports UL scheduling measurements

Figure 6-32 Physical Channels and Reference Signals


LZT 123 8958 R1A © Ericsson 2009 - 129 -

UL-SCHPCHPCH DL-SCH

PCCHPCCH Logical Channels “type of information”(traffic/control)

Transport Channels“how and with what characteristics”(common/shared/mc/bc)

Downlink Uplink

PDSCHPDSCH

Physical Channels“bits, symbols, modulation, radio frames etc”

MTCHMTCH MCCHMCCH BCCHBCCH DTCHDTCH DCCHDCCH DTCHDTCH DCCHDCCH CCCHCCCH

PRACHPRACH

RACHRACH

CCCHCCCH

MCH BCH

PUSCHPUSCHPBCHPBCH PCFICHPCFICH PUCCHPUCCH

-CQI -ACK/NACK-Sched req.

-Sched TF DL-Sched grant UL-Pwr Ctrl cmd-HARQ info

MIB SIB

PMCHPMCH PHICHPHICHPDCCHPDCCH

ACK/NACKPDCCH

info

Physical Signals“only L1 info”RSRS SRSSRSP-SCHP-SCH S-SCHS-SCH RSRS

-meas for DL sched -meas for mobility-coherent demod

-half frame sync-cell id

-frame sync-cell id group -coherent demod

-measurements for UL scheduling

Figure 6-33 Channel Mapping

DL Mapping:

The MAC entity in eNodeB is responsible for mapping of DL Logical Channels to DL Transport Channels. In the Figure 6-33 it is possible to see that there is one to one mapping between PCCH and PCH, BCCH and BCH while all other channels are mapped to DL –SCH (MTCH and MCCH can also be mapped MCH). The reason why is in “how and with what characteristics”. PCH, BCH and DL-SCH Transport Channels are treated differently by the MAC Scheduler. Further difference is in the fact that data that is sent using PCH and BCH is not associated with any HARQ entity.

UL Mapping

The MAC entity in the UE is responsible for mapping of UL Logical Channels to UL Transport Channels. In the Figure 6-33 it is possible to see that all logical channels are mapped to UL-SCH and will be associated with a HARQ entity.


- 130 - © Ericsson 2009 LZT 123 8958 R1A

MULTIPLEXING AND ASSEMBLY

The Logical Channel Prioritization procedure is applied when a new transmission is performed.

RRC controls the scheduling of uplink data by signalling for each logical channel: priority where an increasing priority value indicates a lower priority level, prioritisedBitRate (e.g bytes per sec) which sets the Prioritized Bit Rate (PBR), bucketSizeDuration (ms) which sets the Bucket Size Duration (BSD).

DTCHDTCH DCCHDCCH DCCHDCCH

B3 B2 B1

DTCHDTCH

Bj

...

...

UL-SCH

Max Bucket size= PBR x BSDAt each TTI Bucket size = bucket size + PBR

TTI n+1TTI n+1

Priority order

TTI nTTI n

TTI n+2TTI n+2TTI n+3TTI n+3

PBR LCH1

PBR LCH2

PBR LCH3

PBR LCH4

Figure 6-34 Logical Chanel Prioritization

The UE maintains a variable Bj for each logical channel j. Bj is initialized to zero when the related logical channel is established. It is incremented by the product PBR × TTI duration for each TTI, where PBR is Prioritized Bit Rate of logical channel j. However, the value of Bj can never exceed the bucket size and if the value of Bj is larger than the bucket size of logical channel j, it is set to the bucket size. The bucket size of a logical channel is equal to PBR × BSD, where PBR and BSD are configured by upper layers.


LZT 123 8958 R1A © Ericsson 2009 - 131 -

The UE performs the following Logical Channel Prioritization procedure when a new transmission is performed:

-The UE allocates resources to the logical channels in the following steps:

4 All the logical channels with Bj > 0 are allocated resources in a decreasing priority order. If the PBR of a radio bearer is set to “infinity”, the UE allocates resources for all the data that is available for transmission on the radio bearer before meeting the PBR of the lower priority radio bearer(s);

5 the UE decrements Bj by the total size of MAC SDUs served to logical channel j in Step 1

NOTE: The value of Bj can be negative.

6 if any resources remain, all the logical channels are served in a strict decreasing priority order (regardless of the value of Bj) until either the data for that logical channel or the UL grant is exhausted, whichever comes first. Logical channels configured with equal priority are be served equally.

MAC PDU

Logical Channel Multiplexing and De multiplexing can be understood by looking at the MAC Header., Figure 6-35 illustrates MAC PDU header. MAC header consists of more than one MAC Sub header, where each Sub header is associated with a logical channel (see Figure 6-35)


- 132 - © Ericsson 2009 LZT 123 8958 R1A

LCID Logical Channel IDE Extension BitR ReservedF Length Flag L Length

MAC Control element 1 ...MAC header

MAC payload

...R/R/E/LCID/F/Lsub-header

MAC Control element 2 MAC SDU MAC SDU Padding

(opt)

R/R/E/LCID/F/Lsub-header




R/R/E/LCID paddingsub-header

Figure 6-35 MAC PDU

A MAC PDU header consists of one or more MAC PDU subheaders; each subheader corresponds to either a MAC SDU, a MAC control element or padding.

A MAC PDU subheader consists of the six header fields R/R/E/LCID/F/L but for the last subheader in the MAC PDU and for fixed sized MAC control elements. The last subheader in the MAC PDU and subheaders for fixed sized MAC control elements consist solely of the four header fields R/R/E/LCID. A MAC PDU subheader corresponding to padding consists of the four header fields R/R/E/LCID.


LZT 123 8958 R1A © Ericsson 2009 - 133 -

LCIDR

F L

R/R/E/LCID/F/L sub-header with 7-bits L field

R/R/E/LCID/F/L sub-header with 15-bits L field

R E LCIDR

F L

R E

L

Oct 1

Oct 2

Oct 1

Oct 2

Oct 3

LCIDR

R/R/E/LCID sub-header

R E Oct 1

Figure 6-36 MAC Sub header

MAC Control Element:

Buffer Status Report (BSR) MAC control elements consist of either:

-Short BSR and Truncated BSR format: one LCG ID field and one corresponding Buffer Size field or

-Long BSR format: four Buffer Size fields, corresponding to LCG IDs #0 through #3

Buffer SizeLCG ID Oct 1

Buffer Size #0 Buffer Size #1



Oct 1

Oct 2

Oct 3

Short BSR

Long BSR

Figure 6-37 Control MAC PDU

The BSR formats are identified by MAC PDU subheaders with LCIDs as specified in table 6.2.1.-1.


- 134 - © Ericsson 2009 LZT 123 8958 R1A

The fields LCG ID and Buffer Size are defined as follow:

-LCG ID: The Logical Channel Group ID field identifies the group of logical channel(s) which buffer status is being reported. The length of the field is 2 bits;

-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 number of bytes. It shall include all data that is available for transmission in the RLC layer and in the PDCP layer; the definition of what data shall be considered as available for transmission is specified in [3] and [4] respectively. The size of the RLC and MAC headers are not considered in the buffer size computation. The length of this field is 6 bits

For more information regarding additional control MAC PDUs see 36.321.


LZT 123 8958 R1A © Ericsson 2009 - 135 -

MAC PROCEDURES

Random AccessMaintenance of Uplink Time AlignmentDL-SCH data transferUL-SCH data transferPCH receptionBCH receptionDiscontinuous Reception (DRX)MAC reconfigurationMAC ResetSemi-Persistent Scheduling

Figure 6-38 MAC Procedures

RANDOM ACCESS

The purpose with Random Access Procedure is to enable initial access for the UE to the E-UTRAN, to establish UL synchronization and to indicate presence of UL data.

Purpose– Initial access– Establish UL synchronization– Indicate presence of UL data

Two cases– Contention-based– Contention-free

Consists of four phases1. Random Access Preamble2. Random Access Response3. RRC Connection Request4. RRC Connection Setup

Random Access Preamble

Random Access Response

RRC Connection Request

UE eNB

1.

2.

3.

4.RRC Connection Setup

MAC procedureMAC procedure

RRC procedureRRC procedure

Figure 6-39 RA Procedure General

There are two types of random access:

7 CBRA Contention Based Random Access

8 CFRA Contention Free Random Access

CBRA is used at initial access and is a subject for collision. CFRA is used for UEs in handover and special preamble is reserved for it.


- 136 - © Ericsson 2009 LZT 123 8958 R1A

prachConfigurationIndexpreambleInitialReceivedTargetPowerpowerRampingStepRa-PreambleIndexra-ResponseWindowSizePreambleTransmissionMax


RACH

Figure 6-40 Random Access Parameters

In order to be able to initiate RA procedure UE needs to get the information listed in the Figure 6-40.

There are two types of the Random Access preamble groups. Depending on the message size and pathloss UE will select either Random Access Preamble group A or B. Once selected the group UE will randomly select a preamble within the group. The random function allowes selections to be made with equal probability

Uplink(PRACH)

Downlink(DLSCH)

RACH Preamble RACH Response

Data

RA message RACH Opportunity

preambleInitialReceivedTargetPower

powerRampingStep

Figure 6-41 Preamble based power ramping

Once preamble has been selected or it has been given by the network it should be sent using initial power setting.


LZT 123 8958 R1A © Ericsson 2009 - 137 -

Once the Random Access Preamble is transmitted the UE will monitor the PDCCH for Random Access Response(s) identified by the RA-RNTI, in the RA Response window which starts at the subframe that contains the end of the preamble transmission plus three subframes and has length ra-ResponseWindowSize subframes. If no response has been received UE will increase the power with powerRampingStep and will try again until it gets an response or until it reaches preambleTransMax. In this case a failure will be indicated to the upper layers.

Once response is received MAC part of the Random Access procedure is completed and RRC will take over by sending the RRC Connection Request message.

UPLINK TIMING ALLIGNMENT MAINTENANCE

The transmit-timing control operates such that the network measures the received uplink timing of the different UEs. If the received timing of a specific UE is “lagging” behind, the UE is commanded to advance its transmit timing a certain amount. Similarly, a UE can be ordered to retard it transmit timing. The steps by which the UEs can advance/retard their timings are multiple of 16×Ts » 0.52 ms. The timing-control commands are transmitted as higher-layer signaling (MAC) to the UEs.

When the UE gets Timing Advance Command:

Random Access Response

Timing Advance CommandR R Oct 1

Figure 6-42 Maintenance of Uplink Time Alignment

Different UEs within a cell will experience different propagation delay to/from the cell site, depending on their exact position within the cell coverage area. If UEs set their transmit timing based only on the timing of the received downlink timing, their corresponding uplink transmissions will thus arrive at the cell site with potentially very different timing. If these receive-timing differences are too large, the orthogonality between the uplink transmissions of different UEs will not be retained. Thus, an active uplink transmit-timing control is needed to ensure that uplink transmissions from different UEs are received with approximately the same timing at the cell site.


- 138 - © Ericsson 2009 LZT 123 8958 R1A

The UE has a configurable timer timeAlignmentTimer which is used to control how long the UE is considered uplink time aligned. The timeAlignmentTimer is valid only in the cell for which it was configured and started

DL/UL SCH DATA TRANSFER USING HARQ OPERATION

Downlink assignments transmitted on the PDCCH indicate if there is a transmission on the DL-SCH for a particular UE and provide the relevant HARQ information.

In order to transmit on the UL-SCH the UE must have a valid uplink grant (except for non-adaptive HARQ retransmissions) which it may receive dynamically on the PDCCH or in a Random Access Response or which may be configured semi-persistently. To perform requested transmissions, the MAC layer receives HARQ information from lower layers.

Receiver processing

Sender

Receiver

TTI

Known (fixed) timing relation

0

Receiver processing

NAK

Receiver processing

NAK

4 8

Number of HARQ processes tuned to match the RTT

• FDD 8 HARQ processes

• TDD depending on asymmetry

ACKACK

621

2

Receiver processing Receiver processing

NAK

1 65 9


ACKACK

621 621

2


NAK

1 65 9


Figure 6-43 HARQ Operation

Both UL and DL Data Transfer is using HARQ operation. There is one HARQ entity at the UE, which maintains a number of parallel HARQ processes allowing transmissions to take place continuously while waiting for HARQ the feedback on the successful or unsuccessful reception of previous transmissions. There is also one HARQ entity per UE in eNodeB maintains a number of parallel HARQ processes in DL


LZT 123 8958 R1A © Ericsson 2009 - 139 -

PCH RECEPTION

When in RRC IDLE the UE monitors its paging occasions (see Paging in RRC Chapter). Once the message is successfully decoded I will be transferred to the upper layer. Please note that PCCH signaling is sent on the RLC TM mode and MAC

BCH RECEPTION

The MIB is ASN.1 encoded as a BCCH-message by the RRC layer. It is then transported transparently through the RLC and MAC layers.The MIB is fitted and transparently transported in the fixed size byte aligned TB of BCH and delivered to the physical layer which uses the physical-layer-processing chain applicable for BCH (adding CRC etc). The physical-layer-processing chain maps one segment of modulated symbols in each of the four consecutive radio frames which each and all corresponds to the SFN div 4 contained in the MIB.

0 5

10 ms

40 ms

SFN=408 SFN=409 SFN=410 SFN=411 SFN=412

0 5 0 5 0 5 0 5 0

Coding etc.

MIB

10 ms

SFN-div-4 = 102

Coding etc.

MIBSFN-div-4 = 103

0 5

10 ms

40 ms

SFN=408 SFN=409 SFN=410 SFN=411 SFN=412

0 5 0 5 0 5 0 5 0

Coding etc.

MIB

10 ms

SFN-div-4 = 102

Coding etc.

MIBSFN-div-4 = 103

Figure 6-44 BCH Reception

The UE combines the received data with the data currently in the soft buffer related to the reception process for this BCH TTI. As soon as the data is successfully decoded, the UE delivers the decoded MAC PDU to RRC. The Figure 6-44 illustrates how the BCH is mapped to the physical layer. Mapped in SF#0 of each radio frame]


- 140 - © Ericsson 2009 LZT 123 8958 R1A

DATA FLOW AND MULTIPLEXING

The user plane data flow for an IP packet transmitted in downlink is illustrated in. ROHC Header compression is (optionally) performed in the PDCP layer. In addition, the PDCP SDU is ciphered. The PDCP header carries the required information for ROHC decompression and deciphering.

Each PDCP PDU corresponds to an RLC SDU. RLC performs segmentation and concatenation of those SDUs and adds an RLC header. The RLC PDUs form MAC SDUs. MAC SDUs from several radio bearers may be multiplexed in MAC. Depending on the amount of scheduled resources, more or less bits are selected for each transport block. The scheduling decision affects the concatenation and segmentation in RLC and the multiplexing in MAC.

In order delivery is proposed to be performed per radio bearer (logical channel) by means of RLC sequence numbers. In contrast to current MAC-hs, MAC in LTE supports multiplexing of MAC SDUs from different radio bearers into the same MAC PDU. Therefore, a MAC PDU will include a RLC sequence number per RLC PDU but no sequence number per MAC PDU. It is assumed that the RLC retransmission unit is an RLC PDU or an RLC PDU segment while the HARQ retransmission unit is the MAC PDU.

Finally, MAC delivers the transport block to the physical layer, where a Cyclic Redundancy Check (CRC) is added.

IPvia S1 or fromUE’s stack

Payloade.g. 1460 Byte

IP20B

L1Coding, Interleaving,Modulation

CRC3B

Transport BlockL1Coding, Interleaving,Modulation

CRC3B

Transport Block

TCP20B

Payloade.g. 50 Byte

IP20B

TCP20B

PDCPHeader Compression& Ciphering PDCP SDU

H~3B

PDCP2B

H~3B

PDCP2B

PDCPPDU

PDCPHeader Compression& Ciphering PDCP SDU

H~3B

PDCP2B

H~3B

PDCP2B

PDCPPDU

RLCSegmentation concatenation

RLC4B

RLC SDU

Concatenation

Segmentation

RLC SDU RLCPDU

RLC2B

RLCSegmentation concatenation

RLC4B

RLC SDU

Concatenation

Segmentation

RLC SDU RLCPDU

RLC2B

MACMultiplexing MAC SDU (e.g. 927 Byte)MAC

4B

Multiplexing (Padding)MAC1B

MAC SDU (e.g. 599 Byte)

MACPDU

MACMultiplexing MAC SDU (e.g. 927 Byte)MAC

4B

Multiplexing (Padding)MAC1B

MAC SDU (e.g. 599 Byte)

MACPDU

PDCP Header• Sequence Number (12 bit)

For ciphering, integrity protectionand during handover

• … and 4 other bitsRLC Header• Sequence Number (10 bit)

ARQ Window size = 512• Framing Info (2 bit)

0: first SDU starts here1: last SDU does not end here

• … and 4 other bits

RLC Framing Sub-Header• Length Indicator (11 bit)

Maximum SDU size = 2048 ByteFirst SDU is 55 Byte

• Extension bit

MAC Header• LCID (5 bit)

RLC Radio Bearer x• Length Field (15 bit)

MAC SDU is 927 Byte• LCID (5 bit)

LCID = Padding• … and 7 other bits

Figure 6-45 Data Flow, Summary


LZT 123 8958 R1A © Ericsson 2009 - 141 -

7 S1 Application Protocol – S1 AP

OBJECTIVES


1. Explain the S1 interface and the S1 Application Protocol (S1AP) protocol structure.

2. Explain the main functions and procedures of S1AP.


1. Explain the S1 interface and the S1 Application Protocol (S1AP) protocol structure.

2. Explain the main functions and procedures of S1AP.

Figure 7-1 Objectives of Chapter 7


- 142 - © Ericsson 2009 LZT 123 8958 R1A

Intentionally Blank


LZT 123 8958 R1A © Ericsson 2009 - 143 -

S1 INTERFACE

S1 CONTROL PLANE

(Uu)

EUTRANUE EPC

Access Stratum

Non-Access Stratum

Radio S1

Radio Protocols

Radio Protocols

S1Protocols

S1Protocols

EMM, ESM EMM, ESM


(Uu)

EUTRANEUTRANUE EPC

Access Stratum

Non-Access Stratum

Radio S1

Radio Protocols

Radio Protocols

S1Protocols

S1Protocols

EMM, ESM EMM, ESM


Figure 7-2 General Protocol Model for LTE Interfaces – Control Plane

The radio network signaling over S1consists of the S1 Application Part (S1AP). The S1AP protocol consists of mechanisms to handle all procedures between the EPC and E-UTRAN. It is also capable of conveying messages transparently between the EPC and the UE without interpretation or processing by the E-UTRAN.

Over the S1 interface the S1AP protocol is, e.g., used to:

- Facilitate a set of general E-UTRAN procedures from the EPC such as paging-notification as defined by the notification SAP.

- Separate each User Equipment (UE) on the protocol level for mobile specific signalling management as defined by the dedicated SAP.

- Transfer of transparent non-access signalling as defined in the dedicated SAP.

- Request of various types of E-RABs through the dedicated SAP.


- 144 - © Ericsson 2009 LZT 123 8958 R1A

- Perform the mobility function.

The E-RABs are provided by the Access Stratum.

S1 USER PLANE

(Uu)

EUTRANUE EPC

Access Stratum

Non-Access Stratum

Radio S1

Radio Protocols

Radio Protocols

S1Protocols

S1Protocols

These are the protocols implementing the actual E-RAB service, i.e. carrying user data through the access stratum.

(Uu)

EUTRANEUTRANUE EPC

Access Stratum

Non-Access Stratum

Radio S1

Radio Protocols

Radio Protocols

S1Protocols

S1Protocols

These are the protocols implementing the actual E-RAB service, i.e. carrying user data through the access stratum. Figure 7-3 .General Protocol Model for LTE Interfaces- User Plane

S1 is the interface between eNBs and MME and S-GW. In the user plane this interface will be based on GTP User Data Tunneling (GTP-U) (similar to today’s Iu and Gn interface). In the control plane the interface is more similar to Radio Access Network Application Part (RANAP), with some simplifications and changes due to the different functional split and mobility within EPS.

It has been agreed to split the S1 interface into a S1-CP (control) and S1-UP part (user plane). The signaling transport on S1-CP will be based on SCTP (Streaming Control Transmission Protocol). The signaling protocol for S1 is called S1-AP (Application Protocol).


LZT 123 8958 R1A © Ericsson 2009 - 145 -

The S1 interface specifications shall facilitate the following:procedures between the EPC and E-UTRANconveying messages transparently between the EPC and the UE without interpretation or processing by the E-UTRAN.

– Facilitate a set of general E-UTRAN procedures from the EPC such as paging-notification as defined by the notification SAP.

– Separate each User Equipment (UE) on the protocol level for mobile specific signalling management as defined by the dedicated SAP.

– Transfer of transparent non-access signalling as defined in the dedicated SAP.

– Request of various types of E-RABs through the dedicated SAP.– Perform the mobility function..

Figure 7-4 S1 Interface.

S1 PROTOCOL MODEL

S1-AP


GTP-U

UDP

IP

Data link layer

Physical layer

User PlanePDUs

SCTP

IP

Data link layer

Physical layer

RadioNetworkLayer




S1-AP


GTP-U

UDP

IP

Data link layer

Physical layer

GTP-U

UDP

IP

Data link layer

Physical layer

User PlanePDUs

SCTP

IP

Data link layer

Physical layer

SCTP

IP

Data link layer

Physical layer

RadioNetworkLayer




Figure 7-5 S1 Interface

The E-UTRAN is layered into a Radio Network Layer (RNL) and a Transport Network Layer (TNL). The E-UTRAN architecture, i.e. the E-UTRAN logical nodes and interfaces between them, are defined as part of the Radio Network Layer.


- 146 - © Ericsson 2009 LZT 123 8958 R1A

The E-UTRAN architecture consists of a set of eNBs connected to the EPC through the S1. The S1 interface is specified at the boundary between the EPC and the E-UTRAN. From the S1 perspective, the E-UTRAN access point is an eNB, and the EPC access point is either the control plane MME logical node or the user plane S-GW logical node. Two types of S1 interfaces are thus defined at the boundary depending on the EPC access point: S1-MME towards an MME and S1-U towards an S- GW.

There may be multiple S1-MME logical interfaces towards the EPC from any one eNB. The selection of the S1-MME interface is then determined by the NAS Node Selection Function. There may be multiple S1-U logical interfaces towards the EPC from any one eNB. The selection of the S1-U interface is done within the EPC and signaled to the eNB by the MME.

S1 signaling bearer provides the following functions:

- Provision of reliable transfer of S1-AP message over S1-MME interface.

- Provision of networking and routing function

- Provision of redundancy in the signaling network

- Support for flow control and congestion control

SCTP shall be supported as the transport layer of S1-MME signaling bearer.

SCTP refers to the Stream Control Transmission Protocol developed by the Sigtran working group of the IETF for the purpose of transporting various signaling protocols over IP network.

There shall be only one SCTP association established between one MME and eNB pair.

The eNB shall establish the SCTP association.

Within the SCTP association established between one MME and eNB pair:

- a single pair of stream identifiers shall be reserved for the sole use of S1AP elementary procedures that utilize non UE-associated signaling.


LZT 123 8958 R1A © Ericsson 2009 - 147 -

- At least one pair of stream identifiers shall be reserved for the sole use of S1AP elementary procedures that utilize UE-associated signalings. However a few pairs (i.e. more than one) should be reserved.

- A single UE-associated signaling shall use one SCTP stream and the stream should not be changed during the communication of the UE-associated signaling.

Transport network redundancy may be achieved by SCTP multi-homing between two end-points, of which one or both is assigned with multiple IP addresses. SCTP end-points shall support a multi-homed remote SCTP end-point. For SCTP endpoint redundancy an INIT may be sent from MME or eNB, at any time for an already established SCTP association.

The SCTP congestion control may, using an implementation specific mechanism, initiate higher layer protocols to reduce the signaling traffic at the source and prioritize certain messages.

The eNB and MME shall support IPv6 and/or IPv4.

The IP layer of S1-MME only supports point-to-point transmission for delivering S1-AP message.

The eNB and MME shall support the Diffserv Code Point marking.

The support of any suitable data link layer protocol, e.g. PPP, Ethernet, etc., shall not be prevented.

The GTP-U protocol over UDP over IP shall be supported as the transport for data streams on the S1 interface.

The transport bearer is identified by the GTP-U TEID and the IP address (source TEID, destination TEID, source IP address, destination IP address).

The path protocol used shall be UDP.

The UDP port number for GTP-U shall be as defined.

The eNB and the EPC shall support fragmentation and assembly of GTP packets at the IP layer.

The eNB and the EPC shall support IPv6 and/or IPv4 .


- 148 - © Ericsson 2009 LZT 123 8958 R1A

There may be one or several IP addresses in the eNB and in the EPC. The packet processing function in the EPC shall send downstream packets of a given E-RAB to the eNB IP address (received in S1-AP) associated to that particular E-RAB. The packet processing function in the eNB shall send upstream packets of a given E-RAB to the EPC IP address (received in S1-AP) associated to that particular E-RAB.


LZT 123 8958 R1A © Ericsson 2009 - 149 -

FUNCTIONS OF S1AP E-RAB ManagementInitial Context Transfer Function Common ID managementUE Capability Info Indication FunctionMobility Function for UEs in LTE_ACTIVE PagingS1 Interface Management FunctionsNAS signaling Transport between UE and MMES1 UE Context Release FunctionUE Context Modification FunctionStatus TransferTrace FunctionLocation ReportingS1 CDMA 2000 Tunneling FunctionWarning Message Transmission Function

Figure 7-6 Functions of S1AP

S1AP protocol has the following functions:

E-RAB management function: This overall functionality is responsible for setting up, modifying and releasing E-RABs, which are triggered by the MME The release of E-RABs may be triggered by the eNB as well.

Initial Context Transfer function: This functionality is used to establish an S1UE context in the eNB, to setup the default IP connectivity, to setup one or more E-RAB(s) if requested by the MME, and to transfer NAS signalling related information to the eNB if needed.

UE Capability Info Indication function: This functionality is used to provide the UE Capability Info when received from the UE to the MME.

Mobility Functions for UEs in LTE_ACTIVE in order to enable a change of eNBs within SAE/LTE (Inter MME/Serving SAE-GW Handovers) via the S1 interface (with EPC involvement).

Paging: This functionality provides the EPC the capability to page the UE.


- 150 - © Ericsson 2009 LZT 123 8958 R1A

S1 interface management functions comprise the:

- Reset functionality to ensure a well defined initialization on the S1 interface.

- Error Indication functionality to allow a proper error reporting/handling in cases where no failure messages are defined.

- Overload function to indicate the load situation in the control plane of the S1 interface.

- Load balancing function to ensure equally loaded MMEs within an MME pool area

- S1 Setup functionality for initial S1 interface setup for providing configuration information

- eNB and MME Configuration Update functions are to update application level configuration data needed for the eNB and MME to interoperate correctly on the S1 interface.

NAS Signalling transport function between the UE and the MME is used:

- to transfer NAS signaling related information and to establish the S1 UE context in the eNB.

- to transfer NAS signaling related information when the S1 UE context in the eNB is already established.

S1 UE context Release function: This functionality is responsible to manage the release of UE specific context in the eNB and the MME.

UE Context Modification function: This functionality allows to modify the established UE Context partly.

Status Transfer: This functionality transfers PDCP SN Status information from source eNB to target eNB in support of in-sequence delivery and duplication avoidance for intra LTE handover.

Trace function: 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 UE’s current location.


LZT 123 8958 R1A © Ericsson 2009 - 151 -

S1 CDMA2000 Tunneling function: This functionality is to carry CDMA2000 signaling between UE and CDMA2000 RAT over the S1 Interface.

Warning message transmission function: This functionality provides the means to start and overwrite the broadcasting of warning message.


- 152 - © Ericsson 2009 LZT 123 8958 R1A

S1AP ELEMENTARY PROCEDURES Figure 7-7 below shows the S1AP Elementary Procedures

HANDOVER FAILUREHANDOVER REQUEST ACKNOWLEDGE

HANDOVER REQUESTHandover Resource Allocation

INITIAL CONTEXT SETUP FAILURE

INITIAL CONTEXT SETUP RESPONSE

INITIAL CONTEXT SETUP REQUEST

Initial Context Setup

E-RAB RELEASE RESPONSEE-RAB RELEASE COMMANDE-RAB Release

E-RAB MODIFY RESPONSEE-RAB MODIFY REQUESTE-RAB Modify

E-RAB SETUP RESPONSEE-RAB SETUP REQUESTE-RAB Setup

HANDOVER CANCEL ACKNOWLEDGE

HANDOVER CANCELHandover Cancellation

PATH SWITCH REQUEST FAILURE

PATH SWITCH REQUEST ACKNOWLEDGE

PATH SWITCH REQUESTPath Switch Request

HANDOVER PREPARATION FAILURE

HANDOVER COMMANDHANDOVER REQUIREDHandover Preparation

Unsuccessful outcome Response Message

Successful OutcomeResponse Message

Initiating MessageElementary Procedure, class 1

HANDOVER FAILUREHANDOVER REQUEST ACKNOWLEDGE

HANDOVER REQUESTHandover Resource Allocation




Initial Context Setup

E-RAB RELEASE RESPONSEE-RAB RELEASE COMMANDE-RAB Release

E-RAB MODIFY RESPONSEE-RAB MODIFY REQUESTE-RAB Modify

E-RAB SETUP RESPONSEE-RAB SETUP REQUESTE-RAB Setup


HANDOVER CANCELHandover Cancellation



PATH SWITCH REQUESTPath Switch Request


HANDOVER COMMANDHANDOVER REQUIREDHandover Preparation




Figure 7-7. S1AP Elementary Procedures – Class 1

S1 SETUP FAILURES1 SETUP RESPONSES1 SETUP REQUESTS1 Setup

WRITE-REPLACE WARNING RESPONSE

WRITE-REPLACE WARNING REQUEST

Write-Replace Warning

MME CONFIGURATION UPDATE FAILURE

MME CONFIGURATION UPDATE ACKNOWLEDGE

MME CONFIGURATION UPDATE

MME Configuration Update

ENB CONFIGURATION UPDATE FAILURE

ENB CONFIGURATION UPDATE ACKNOWLEDGE

ENB CONFIGURATION UPDATE

eNB Configuration Update

UE CONTEXT MODIFICATION FAILURE

UE CONTEXT MODIFICATION RESPONSE

UE CONTEXT MODIFICATION REQUEST

UE Context Modification

UE CONTEXT RELEASE COMPLETE

UE CONTEXT RELEASE COMMAND

UE Context Release

RESET ACKNOWLEDGERESETReset




S1 SETUP FAILURES1 SETUP RESPONSES1 SETUP REQUESTS1 Setup



Write-Replace Warning




MME Configuration Update




eNB Configuration Update




UE Context Modification



UE Context Release

RESET ACKNOWLEDGERESETReset




Figure 7-8. S1AP Elementary Procedures – Class 1


LZT 123 8958 R1A © Ericsson 2009 - 153 -

TRACE STARTTrace Start

DEACTIVATE TRACEDeactivate Trace

MME STATUS TRANSFERMME Status Transfer

ENB STATUS TRANSFEReNB Status Transfer

UE CAPABILITY INFO INDICATIONUE Capability Info Indication

UPLINK S1 CDMA2000 TUNNELINGUplink S1 CDMA2000 Tunneling

DOWNLINK S1 CDMA 2000 TUNNELINGDownlink S1 CDMA 2000 Tunneling

UE CONTEXT RELEASE REQUESTUE Context Release Request

ERROR INDICATIONError Indication

NAS NON DELIVERY INDICATIONNAS non delivery Indication

UPLINK NAS TRANSPORTUplink NAS Transport

DOWNLINK NAS TRANSPORTDownlink NAS Transport

INITIAL UE MESSAGEInitial UE Message

PAGINGPaging

E-RAB RELEASE INDICATIONE-RAB Release Indication

HANDOVER NOTIFYHandover Notification

Initiating MessageElementary procedure, class 2

TRACE STARTTrace Start

DEACTIVATE TRACEDeactivate Trace

MME STATUS TRANSFERMME Status Transfer

ENB STATUS TRANSFEReNB Status Transfer

UE CAPABILITY INFO INDICATIONUE Capability Info Indication

UPLINK S1 CDMA2000 TUNNELINGUplink S1 CDMA2000 Tunneling

DOWNLINK S1 CDMA 2000 TUNNELINGDownlink S1 CDMA 2000 Tunneling

UE CONTEXT RELEASE REQUESTUE Context Release Request

ERROR INDICATIONError Indication

NAS NON DELIVERY INDICATIONNAS non delivery Indication

UPLINK NAS TRANSPORTUplink NAS Transport

DOWNLINK NAS TRANSPORTDownlink NAS Transport

INITIAL UE MESSAGEInitial UE Message

PAGINGPaging

E-RAB RELEASE INDICATIONE-RAB Release Indication

HANDOVER NOTIFYHandover Notification


Figure 7-9 S1AP Elementary Procedures – Class 2

The following applies concerning interference between Elementary Procedures:

• The Reset procedure takes precedence over all other EPs.

• The UE Context Release procedure takes precedence over all other EPs that are using the UE-associated signaling.

CELL TRAFFIC TRACECell Traffic Trace

MME CONFIGURATION TRANSFERMME Configuration Transfer

ENB CONFIGURATION TRANSFEReNB Configuration Transfer

MME DIRECT INFORMATION TRANSFERMME Direct Information Transfer

ENB DIRECT INFORMATION TRANSFEReNB Direct Information Transfer

OVERLOAD STOPOverload Stop

OVERLOAD STARTOverload Start

LOCATION REPORTLocation Report

LOCATION REPORTING FAILURE INDICATIONLocation Reporting Failure Indication

LOCATION REPORTING CONTROLLocation Reporting Control

TRACE FAILURE INDICATIONTrace Failure Indication


CELL TRAFFIC TRACECell Traffic Trace

MME CONFIGURATION TRANSFERMME Configuration Transfer

ENB CONFIGURATION TRANSFEReNB Configuration Transfer

MME DIRECT INFORMATION TRANSFERMME Direct Information Transfer

ENB DIRECT INFORMATION TRANSFEReNB Direct Information Transfer

OVERLOAD STOPOverload Stop

OVERLOAD STARTOverload Start

LOCATION REPORTLocation Report

LOCATION REPORTING FAILURE INDICATIONLocation Reporting Failure Indication

LOCATION REPORTING CONTROLLocation Reporting Control

TRACE FAILURE INDICATIONTrace Failure Indication


Figure 7-10 S1 AP Elementary Procedures – Class 2


- 154 - © Ericsson 2009 LZT 123 8958 R1A

E-RAB MANAGEMENT PROCEDURES

E-RAB SETUP

MMEMME

E-RAB SETUP REQUEST

E-RAB SETUP RESPONSE

eNBeNB MMEMME

E-RAB SETUP REQUEST

E-RAB SETUP RESPONSE

eNBeNB

Figure 7-11 E-RAB Setup

The purpose of the E-RAB Setup procedure is to assign resources on Uu and S1 for one or several E-RABs and to setup corresponding Data Radio Bearers for a given UE. The procedure uses UE-associated signaling.

The MME initiates the procedure by sending an E-RAB SETUP REQUEST message to the eNB.

The E-RAB SETUP REQUEST message shall contain the information required by the eNB to build the E-RAB configuration consisting of at least one E-RAB including for each E-RAB to setup in the E-RAB to be Setup List IE.

Upon reception of the E-RAB SETUP REQUEST message, and if resources are available for the requested configuration, the eNB shall execute the requested E-RAB configuration. For each E-RAB and based on the E-RAB level QoS parameters IE the eNB shall establish a Data Radio Bearer and allocate the required resources on Uu. The eNB shall pass the NAS-PDU IE and the value contained in the E-RAB ID IE received for the E-RAB for each established Data Radio Bearer to the UE. The eNB does not send the NAS PDUs associated to the failed Data radio bearers to the UE. The eNB shall allocate the required resources on S1 for the E-RABs requested to be established.

The E-RAB SETUP REQUEST message may contain the UE Aggregate Maximum Bit Rate IE


LZT 123 8958 R1A © Ericsson 2009 - 155 -

If the UE Aggregate Maximum Bit Rate IE is included in the E-RAB SETUP REQUEST the eNB shall replace the previously provided UE Aggregate Maximum Bit Rate by the received UE Aggregate Maximum Bit Rate in the UE context; the eNB shall use the received UE Aggregate Maximum Bit Rate for non-GBR Bearers for the concerned UE.

If the UE Aggregate Maximum Bit Rate IE is not contained in the E-RAB SETUP REQUEST message, the eNB shall use the previously provided UE Aggregate Maximum Bit Rate which is stored in the UE context.

The eNB shall establish or modify the resources according to the values of the Allocation and Retention Priority IE (priority level and pre-emption indicators) and the resource situation as follows:

-The eNB shall consider the priority level of the requested E-RAB, when deciding on the resource allocation.

-The priority levels and the pre-emption indicators may (individually or in combination) be used to determine whether the E-RAB setup has to be performed unconditionally and immediately. If the requested E-RAB is marked as "may trigger pre-emption" and the resource situation requires so, the eNB may trigger the pre-emption procedure which may then cause the forced release of a lower priority E-RAB which is marked as "pre-emptable". Whilst the process and the extent of the pre-emption procedure is operator-dependent, the pre-emption indicators shall be treated as follows:

1. The values of the last received Pre-emption Vulnerability IE and Priority Level IE shall prevail.

2. If the Pre-emption Capability IE is set to "may trigger pre-emption", then this allocation request may trigger the pre-emption procedure.

3. If the Pre-emption Capability IE is set to "shall not trigger pre-emption", then this allocation request shall not trigger the pre-emption procedure.

4. If the Pre-emption Vulnerability IE is set to "pre-emptable", then this E-RAB shall be included in the pre-emption process.

5. If the Pre-emption Vulnerability IE is set to "not pre-emptable", then this E-RAB shall not be included in the pre-emption process.


- 156 - © Ericsson 2009 LZT 123 8958 R1A

6. If the Priority Level IE is set to "no priority" the given values for the Pre-emption Capability IE and Pre-emption Vulnerability IE shall not be considered. Instead the values "shall not trigger pre-emption" and "not pre-emptable" shall prevail.

The E-UTRAN pre-emption process shall keep the following rules:

1. E-UTRAN shall only pre-empt E-RABs with lower priority, in ascending order of priority.

2. The pre-emption may be done for E-RABs belonging to the same UE or to other UEs.

The eNB shall report to the MME, in the E-RAB SETUP RESPONSE message, the result for all the requested E-RABs.

- A list of E-RABs which are successfully established shall be included in the E-RAB Setup List IE.

- A list of E-RABs which failed to be established shall be included in the E-RAB Failed to Setup List IE.

In case of the establishment of an E-RAB the EPC must be prepared to receive user data before the E-RAB SETUP RESPONSE message has been received.

When the eNB reports unsuccessful establishment of an E-RAB, the cause value should be precise enough to enable the MME to know the reason for an unsuccessful establishment e.g.: "Radio resources not available", "Failure in the Radio Interface Procedure".

Interactions with Handover Preparation procedure:

If a handover becomes necessary during E-RAB setup, the eNB may interrupt the ongoing E-RAB Setup procedure and initiate the Handover Preparation procedure as follows:

1. The eNB shall send the E-RAB SETUP RESPONSE message in which the eNB shall indicate, if necessary all the E-RABs fail with an appropriate cause value e.g."S1 intra system or S1 inter system Handover Triggered" or "X2 Handover Triggered"

2. The eNB shall trigger the handover procedure.

If the eNB receives a E-RAB SETUP REQUEST message containing a E-RAB Level QoS Parameters IE which contains a QCI IE indicating a GBR bearer (as defined in [13]), and which does not contain the GBR QoS Information IE, the eNB shall consider the establishment of the corresponding E-RAB as failed.


LZT 123 8958 R1A © Ericsson 2009 - 157 -

If the eNB receives an E-RAB SETUP REQUEST message containing several E-RAB ID IEs (in the E-RAB To Be Setup List IE) set to the same value, the eNB shall report the establishment of the corresponding E-RABs as failed in the E-RAB SETUP RESPONSE with the appropriate cause value, e.g. "Multiple E-RAB ID instances".

If the eNB receives an E-RAB SETUP REQUEST message containing a E-RAB ID IE (in the E-RAB To Be Setup List IE) set to the value that identifies an active E-RAB (established before the E-RAB SETUP REQUEST message was received), the eNB shall report the establishment of the new E-RAB as failed in the E-RAB SETUP RESPONSE with the appropriate cause value, e.g. "Multiple E-RAB ID instances".

E-RAB MODIFY

MMEMME

E-RAB MODIFY REQUEST

E-RAB MODIFY RESPONSE

eNBeNB MMEMME

E-RAB MODIFY REQUEST

E-RAB MODIFY RESPONSE

eNBeNB

Figure 7-12 E-RAB Modify

The MME initiates the procedure by sending an E-RAB MODIFY REQUEST message to the eNB.

The E-RAB MODIFY REQUEST message shall contain the information required by the eNB to modify one or several E-RABs of the existing E-RAB configuration.

Information shall be present in the E-RAB MODIFY REQUEST message only when any previously set value for the E-RAB configuration is requested to be modified.


- 158 - © Ericsson 2009 LZT 123 8958 R1A

Upon reception of the E-RAB MODIFY REQUEST message, and if resources are available for the requested target configuration, the eNB shall execute the modification of the requested E-RAB configuration. For each E-RAB that shall be modified and based on the new E-RAB level QoS parameters IE the eNB shall modify the Data Radio Bearer configuration and change allocation of resources on Uu according to the new resource request. The eNB shall pass the NAS-PDU IE and the value contained in the E-RAB ID IE received for the E-RAB to the UE when modifying the Data Radio Bearer configuration. The eNB does not send the NAS PDUs associated to the failed Data radio bearers to the UE. The eNB shall change allocation of resources on S1 according to the new resource request.

If the E-UTRAN failed to modify an E-RAB the E-UTRAN shall keep the E-RAB configuration as it was configured prior the E-RAB MODIFY REQUEST.

The E-RAB MODIFY REQUEST message may contain the UE Aggregate Maximum Bit Rate IE.

If the UE Aggregate Maximum Bit Rate IE is included in the E-RAB MODIFY REQUEST the eNB shall replace the previously provided UE Aggregate Maximum Bit Rate by the received UE Aggregate Maximum Bit Rate in the UE context; the eNB shall use the received UE Aggregate Maximum Bit Rate for non-GBR Bearers for the concerned UE.

If the UE Aggregate Maximum Bit Rate IE is not contained in the E-RAB MODIFY REQUEST message, the eNB shall use the previously provided UE Aggregate Maximum Bit Rate which is stored in the UE context.

The modification of resources according to the values of the Allocation and Retention Priority IE shall follow the principles described for the E-RAB Setup procedure.

The eNB shall report to the MME, in the E-RAB MODIFY RESPONSE message, the result for all the requested E-RABs to be modified.

A list of E-RABs which are successfully modified shall be included in the E-RAB Modify List IE.

A list of E-RABs which failed to be modified shall be included in the E-RAB Failed to Modify List IE.


LZT 123 8958 R1A © Ericsson 2009 - 159 -

When the eNB reports unsuccessful modification of an E-RAB, the cause value should be precise enough to enable the MME to know the reason for an unsuccessful modification e.g.: "Radio resources not available", "Failure in the Radio Interface Procedure".

In case of a modification of an E-RAB the EPC must be prepared to receive user data according to the modified E-RAB profile prior to the E-RAB MODIFY RESPONSE message.

Interactions with Handover Preparation procedure:

If a handover becomes necessary during E-RAB modify, the eNB may interrupt the ongoing E-RAB Modify procedure and initiate the Handover Preparation procedure as follows:

1. The eNB shall send the E-RAB MODIFY RESPONSE message in which the eNB shall indicate, if necessary all the E-RABs fail with an appropriate cause value e.g." S1 intra system or S1 inter system Handover Triggered" or "X2 Handover Triggered"

2. The eNB shall trigger the handover procedure.

If the eNB receives a E-RAB MODIFY REQUEST message containing a E-RAB Level QoS Parameters IE which contains a QCI IE indicating a GBR bearer for an E-RAB previously configured as a non-GBR bearer, and which does not contain the GBR QoS Information IE, the eNB shall consider the modification of the corresponding E-RAB as failed.

If the eNB receives an E-RAB MODIFY REQUEST message containing several E-RAB ID IEs (in the E-RAB to be Modified List IE) set to the same value, the eNB shall report the modification of the corresponding E-RABs as failed in the E-RAB MODIFY RESPONSE with the appropriate cause value, e.g. "Multiple E-RAB ID instances".

If the eNB receives an E-RAB MODIFY REQUEST message containing some E-RAB ID IEs that eNB does not recognize, the eNB shall report the corresponding invalid E-RABs as failed in the E-RAB MODIFY RESPONSE with the appropriate cause value, e.g. "Unknown E-RAB ID".


- 160 - © Ericsson 2009 LZT 123 8958 R1A

E-RAB RELEASE

MMEMME

E-RAB RELEASE INDICATION

eNBeNB

MMEMME

E-RAB RELEASE COMMAND

E-RAB RELEASE RESPONSE

eNBeNB

MMEMME

E-RAB RELEASE INDICATION

eNBeNB

MMEMME

E-RAB RELEASE COMMAND

E-RAB RELEASE RESPONSE

eNBeNB

Figure 7-13 E-RAB Release

The MME initiates the procedure by sending an E-RAB RELEASE COMMAND message.

The E-RAB RELEASE COMMAND message shall contain the information required by the eNB to release at least one E-RAB in the E-RAB To Be Released List IE. It may also contain a NAS-PDU IE corresponding to the released E-RAB. If so, the eNB shall pass the NAS-PDU IE to the UE

Upon reception of the E-RAB RELEASE COMMAND message the eNB shall execute the release of the requested E-RABs. For each E-RAB to be released the eNB shall release the corresponding Data Radio Bearer and release the allocated resources on Uu. The eNB shall pass the value contained in the E-RAB ID IE received for the E-RAB to the radio interface protocol for each Data Radio Bearer to be released. The eNB shall release allocated resources on S1 for the E-RABs requested to be released.

The E-RAB RELEASE COMMAND message may contain the UE Aggregate Maximum Bit Rate IE

If the UE Aggregate Maximum Bit Rate IE is included in the E-RAB RELEASE COMMAND the eNB shall

replace the previously provided UE Aggregate Maximum Bit Rate by the received UE Aggregate Maximum Bit Rate in the UE context; the eNB shall use the received UE Aggregate Maximum Bit Rate for non-GBR Bearers for the concerned UE.


LZT 123 8958 R1A © Ericsson 2009 - 161 -

If the UE Aggregate Maximum Bit Rate IE is not contained in the E-RAB RELEASE COMMAND message, the eNB shall use the previously provided UE Aggregate Maximum Bit Rate which is stored in the UE context.

The eNB shall report to the MME, in the E-RAB RELEASE RESPONSE message, the result for all the E-RABs to be released.

A list of E-RABs which are released successfully shall be included in the E-RAB Release List IE.

A list of E-RABs which failed to be released shall be included in the E-RAB Failed to Release List IE.

The eNB shall be prepared to receive an E-RAB RELEASE COMMAND message on an established UE-associated logical S1-connection containing an E-RAB Release List IE at any time and shall always reply to it with an E-RAB RELEASE RESPONSE message.

After sending an E-RAB RELEASE RESPONSE message containing an E-RAB ID within the E-RAB Release List IE, the eNB shall be prepared to receive an E-RAB SETUP REQUEST message requesting establishment of an E-RAB with this E-RAB ID.

The eNB initiates the procedure by sending an E-RAB RELEASE INDICATION message towards the MME.

The E-RAB RELEASE INDICATION message shall contain at least one E-RAB released at the eNB, in the E-RAB Released List IE.

Upon reception of the E-RAB RELEASE INDICATION message the MME shall normally initiate the appropriate release procedure on the core network side for the E-RABs identified in the E-RAB RELEASE INDICATION message.

Interaction with UE Context Release Request procedure:

If the eNB wants to remove all remaining E-RABs e.g. for user inactivity, the UE Context Release Request procedure shall be used instead.


- 162 - © Ericsson 2009 LZT 123 8958 R1A

If the eNB receives an E-RAB RELEASE COMMAND message containing several E-RAB ID IEs (in the E-RAB Released List IE) set to the same value, the eNB shall initiate the release of one corresponding E-RAB of the E-RAB Released List IE and consider the release of the other multiple duplication of the instances of the selected corresponding E-RABs as failed. The eNB shall report the corresponding invalid E-RABs as failed in the E-RAB RELEASE RESPONSE with the appropriate cause value, e.g. "Multiple E-RAB ID instances".

If the MME receives an E-RAB RELEASE INDICATION message containing several E-RAB ID IEs (in the E-RAB Released List IE) set to the same value, the MME shall initiate the release of the corresponding E-RAB.

If the eNB receives an E-RAB RELEASE COMMAND message containing some E-RAB ID IEs that eNB does not recognize, the eNB shall report the corresponding invalid E-RABs as failed in the E-RAB RELEASE RESPONSE with the appropriate cause e.g. "Unknown E-RAB ID".


LZT 123 8958 R1A © Ericsson 2009 - 163 -

CONTEXT MANAGEMENT PROCEDURES

INITIAL CONTEXT SETUP

The purpose of the Initial Context Setup procedure is to establish the necessary overall initial UE Context including E-RAB context, the Security Key, Handover Restriction List, UE Radio capability and UE Security Capabilities etc. The procedure uses UE-associated signaling.

MMEMME



eNBeNB

MMEMME



eNBeNB

MMEMME



eNBeNB MMEMME



eNBeNB

MMEMME



eNBeNB MMEMME



eNBeNB

Figure 7-14 Initial Context Setup

In case of the establishment of an E-RAB the MME must be prepared to receive user data before the INITIAL CONTEXT SETUP RESPONSE message has been received.

The INITIAL CONTEXT SETUP REQUEST message shall contain within the E-RAB to be Setup List IE the information required by the eNB to build the new E-RAB configuration consisting of at least one additional E-RAB.

The E-RAB to be Setup List IE may contain:

- the NAS-PDU IE


- 164 - © Ericsson 2009 LZT 123 8958 R1A

The INITIAL CONTEXT SETUP REQUEST message may contain

- the Trace Activation IE

- the Handover Restriction List IE, which may contain roaming, area or access restrictions

- the UE Radio Capability IE.

- the Subscriber Profile ID for RAT/Frequency priority IE

- the CS Fallback Indicator IE.

- the SRVCC Operation Possible IE

The INITIAL CONTEXT SETUP REQUEST message shall contain the Subscriber Profile ID for RAT/Frequency priority IE, if available in the MME.

Upon receipt of the INITIAL CONTEXT SETUP REQUEST the eNB shall attempt to execute the requested E-RAB configuration.

- store the UE Aggregate Maximum Bit Rate in the UE context, and use the received UE Aggregate Maximum Bit Rate for non-GBR Bearers for the concerned UE.

- pass the value contained in the E-RAB ID IE and the NAS-PDU IE received for the E-RAB for each established Data radio bearer to the radio interface protocol. The eNB does not send the NAS PDUs associated to the failed Data radio bearers to the UE.

- store the received Handover restriction List in the UE context.

- store the received UE Radio Capability in the UE context.

- store the received Subscriber Profile ID for RAT/Frequency priority in the UE context.

- store the received SRVCC operation possible in the UE context.

- store the received UE Security Capabilities in the UE context

- store the received Security Key in the UE context and take it into use

For the Intial Context Setup an initial value for the Next Hop Chaining Count is stored in the UE context.


LZT 123 8958 R1A © Ericsson 2009 - 165 -

The allocation of resources according to the values of the Allocation and Retention Priority IE shall follow the principles described for the E-RAB Setup procedure.

The eNB shall use the information in Handover Restriction List IE if present in the INITIAL CONTEXT SETUP REQUEST message to determine a target cell for handover. If the Handover Restriction List IE is not contained in the INITIAL CONTEXT SETUP REQUEST message, the target eNB shall consider that no roaming area nor access restriction applies to the UE.

If the Trace activation IE is included in the INITIAL CONTEXT SETUP REQUEST message then eNB shall, if supported, initiate the requested trace function.

If the CS Fallback Indicator IE is included in the INITIAL CONTEXT SETUP REQUEST message, it indicates that the UE Context to be set-up is subject to CS Fallback.

The eNB shall report to the MME, in the INITIAL CONTEXT SETUP RESPONSE message, the successful establishment of the security procedures with the UE, and, the result for all the requested E-RABs in the following way:

- A list of E-RABs which are successfully established shall be included in the E-RAB Setup List IE

- A list of E-RABs which failed to be established shall be included in the E-RAB Failed to Setup List IE.

When the eNB reports unsuccessful establishment of an E-RAB, the cause value should be precise enough to enable the MME to know the reason for an unsuccessful establishment e.g.: "Radio resources not available", "Failure in the Radio Interface Procedure".

After sending the INITIAL CONTEXT SETUP RESPONSE message, the procedure is terminated in the eNB.

If the eNB is not able to establish an S1 UE context, or cannot even establish one non GBR bearer it shall consider the procedure as failed and reply with the INITIAL CONTEXT SETUP FAILURE message


- 166 - © Ericsson 2009 LZT 123 8958 R1A

If the eNB receives an INITIAL CONTEXT SETUP REQUEST message containing a E-RAB Level QoS Parameters IE which contains a QCI IE indicating a GBR bearer, and which does not contain the GBR QoS Information IE, the eNB shall consider the establishment of the corresponding E-RAB as failed.

If the eNB receives an INITIAL CONTEXT SETUP REQUEST message containing several E-RAB ID IEs (in the E-RAB to Be Setup List IE) set to the same value, the eNB shall consider the establishment of the corresponding E-RABs as failed.

If the supported algorithms for encryption defined in the Encryption Algorithms IE in the UE Security Capabilities IE, plus the mandated support of EEA0 in all UEs , do not match any allowed algorithms defined in the configured list of allowed encryption algorithms in the eNB , the eNB shall reject the procedure using the INITIAL CONTEXT SETUP FAILURE message.

If the supported algorithms for integrity defined in the Integrity Protection Algorithms IE in the UE Security Capabilities IE, do not match any allowed algorithms defined in the configured list of allowed integrity protection algorithms in the eNB or if all bits in Integrity Protection Algorithms IE are equal to 0, the eNB shall reject the procedure using the INITIAL CONTEXT SETUP FAILURE message.

UE CONTEXT RELEASE REQUEST

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.

The purpose of the UE Context Release procedure is to enable the MME to order the release of the UE-associated logical connection due to various reasons, for example completion of a transaction between the UE and the EPC or completion of successful handover or completion of handover cancellation or release of the old UE-associated logical S1-connection when two UE-associated logical S1-connections toward the same UE is detected after the UE has initiated establishment of a new UE-associated logical S1-connections. The procedure uses UE-associated S1 connection.


LZT 123 8958 R1A © Ericsson 2009 - 167 -

MMEMME


eNBeNB

MMEMME



eNBeNB

A. UE Initiated

B. MME Initiated

MMEMME


eNBeNB

MMEMME



eNBeNB

A. UE Initiated

B. MME Initiated

Figure 7-15 UE Context Release

The eNB controlling a UE-associated logical S1-connection initiates the procedure by generating an UE CONTEXT RELEASE REQUEST message towards the affected MME node.

The UE CONTEXT RELEASE REQUEST message shall indicate the appropriate cause value e.g. "User Inactivity", "Radio Connection With UE Lost" for the requested UE-associated logical S1-connection release.

Interactions with UE Context Release procedure:

The UE Context Release procedure should be initiated upon reception of an UE CONTEXT RELEASE REQUEST message when the cause is different than "User Inactivity".

The MME initiates the procedure by sending the UE CONTEXT RELEASE COMMAND message to the eNB.

The UE CONTEXT RELEASE COMMAND message shall contain the UE S1AP ID pair if available, otherwise the message shall contain MME UE S1AP ID.

The MME provides the cause IE set to "Load Balancing TAU Required" in the UE CONTEXT RELEASE COMMAND sent to the eNB for all load balancing and offload cases in the MME.


- 168 - © Ericsson 2009 LZT 123 8958 R1A

Upon reception of the UE CONTEXT RELEASE COMMAND message, the eNB shall release all related signalling and user data transport resources and reply with the UE CONTEXT RELEASE COMPLETE message.

If the UE Context Release procedure is not initiated towards eNB before the expiry of the timer TS1RELOCoverall, the eNB shall release all resources associated with the UE context and request the MME to release the UE context.

If the UE returns to the eNB before the reception of the UE CONTEXT RELEASE COMMAND message or the expiry of the timer TS1RELOCoverall, the eNB shall stop the TS1RELOCoverall and continue to serve the UE.

UE CONTEXT MODIFICATION

The purpose of the UE Context Modification procedure is to modify the established UE Context partly (e.g. with the Security Key or Subscriber Profile ID for RAT/Frequency priority). The procedure uses UE-associated signaling.

MMEMME



eNBeNB

MMEMME



eNBeNB

MMEMME



eNBeNB

MMEMME



eNBeNB

Figure 7-16 UE Context Modification


LZT 123 8958 R1A © Ericsson 2009 - 169 -

The UE CONTEXT MODIFICATION REQUEST message may contain

- the Security Key IE

- the Subscriber Profile ID for RAT/Frequency priority IE

- the UE Aggregate Maximum Bit Rate IE

- the CS Fallback Indicator IE.

Upon receipt of the UE CONTEXT MODIFICATION REQUEST the eNB shall

- store the received Security Key IE, take it into use and associate it with the initial value of NCC.

- store the Subscriber Profile ID for RAT/Frequency priority IE.

If the UE Aggregate Maximum Bit Rate IE is included in the UE CONTEXT MODIFICATION REQUEST the eNB shall replace the previously provided UE Aggregate Maximum Bit Rate by the received UE Aggregate Maximum Bit Rate in the UE context; the eNB shall use the received UE Aggregate Maximum Bit Rate for non-GBR Bearers for the concerned UE.

If the UE Aggregate Maximum Bit Rate IE is not contained in the UE CONTEXT MODIFICATION REQUEST message, the eNB shall use the previously provided UE Aggregate Maximum Bit Rate which is stored in the UE context.

If the CS Fallback Indicator IE is included in the UE CONTEXT MODIFICATION REQUEST message, it indicates that the concerned UE Context is subject to CS Fallback.

The eNB shall report, in the UE CONTEXT MODIFICATION RESPONSE message to the MME, the successful update of the UE context:

After sending the UE CONTEXT MODIFICATION RESPONSE message, the procedure is terminated in the eNB.

In case the UE context update cannot be performed successfully the eNB shall respond with the UE CONTEXT MODIFICATION FAILURE message to the MME with an appropriate cause value in the Cause IE.


- 170 - © Ericsson 2009 LZT 123 8958 R1A

HANDOVER SIGNALING

HANDOVER PREPARATION

The purpose of the Handover Preparation procedure is to request the preparation of resources at the target side via the EPC. There is only one Handover Preparation procedure ongoing at the same time for a certain UE.

MMEMME

HANDOVER REQUIRED

HANDOVER COMMAND

source eNBsource eNB

MMEMME

HANDOVER REQUIRED



MMEMME

HANDOVER REQUIRED

HANDOVER COMMAND


MMEMME

HANDOVER REQUIRED



Figure 7-17 Handover Preparation

The source eNB initiates the handover preparation by sending the HANDOVER REQUIRED message to the serving MME. When the source eNB sends the HANDOVER REQUIRED message, it shall start the timer TS1RELOCprep. The source eNB shall indicate the appropriate cause value for the handover in the Cause IE.

The source eNB shall include the Source to Target Transparent Container IE in the HANDOVER REQUIRED message.

In case of intra-system handover, the container shall be encoded according to the definition of the Source eNB to Target eNB Transparent Container IE. In case of handover to UTRAN, the information in the Source to Target Transparent Container IE shall be encoded according to the Source RNC to Target RNC Transparent Container IE definition. If the handover is to GERAN A/Gb mode then the Source to Target Transparent Container IE shall be encoded according to the definition of the Source BSS to Target BSS Transparent Container IE.


LZT 123 8958 R1A © Ericsson 2009 - 171 -

When the preparation, including the reservation of resources at the target side is ready, the MME responds with the HANDOVER COMMAND message to the source eNB.

If the Target to Source Transparent Container IE has been received by the MME from the handover target then the transparent container shall be included in the HANDOVER COMMAND message.

Upon reception of the HANDOVER COMMAND message the source eNB shall stop the timer TS1RELOCprep and start the timer TS1RELOCOverall.

In case of intra-system handover, the information in the Target to Source Transparent Container IE shall be encoded according to the definition of the Target eNB to Source eNB Transparent Container IE. In case of inter-system handover to UTRAN, the Target to Source Transparent Container IE shall be encoded according to the Target RNC to Source RNC Transparent Container IE definition. In case of inter-system handover to GERAN A/Gb mode, the Target to Source Transparent Container IE shall be encoded according to the Target BSS to Source BSS Transparent Container IE definition.

If there are any E-RABs that could not be admitted in the target, they shall be indicated in the E-RABs to Release List IE.

If the DL forwarding IE is included within the Source eNB to Target eNB Transparent Container IE of the HANDOVER REQUIRED message and it is set to "DL forwarding proposed", it indicates that the source eNB proposes forwarding of downlink data.

The source eNB may include the Direct Forwarding Path Availability IE in the HANDOVER REQUIRED message if a direct data path is available.

If the HANDOVER REQUIRED message does not contain the Direct Forwarding Path Availability IE then indirect forwarding may be applied, if available.

The source eNB shall include the SRVCC HO Indication IE in the HANDOVER REQUIRED message if the SRVCC operation is needed as defined in [9]. The source eNB shall indicate to the MME in the SRVCC HO Indication IE if the handover shall be prepared for PS and CS domain or only for CS domain. In case of inter-system handover from E-UTRAN, the source eNB shall indicate in the Target ID IE, in case of inter-system handover to UTRAN, the Target RNC-ID of the RNC, in case of inter-system handover to GERAN A/Gb mode the Cell Global Identity (including the Routing Area Code) of the cell in the target system.


- 172 - © Ericsson 2009 LZT 123 8958 R1A

In case the SRVCC operation is performed, SRVCC HO Indication IE indicates that handover shall be prepared only for CS domain, the source eNB shall include in the HANDOVER REQUIRED message one Source to Target Transparent Container IEs and encode the information in the Source to Target Transparent Container IE according to the definition of the Old BSS to New BSS information IE .

In case the SRVCC operation is performed, SRVCC HO Indication IE indicates that handover shall be prepared for PS and CS domain, and if

- the target system is GERAN without DTM support then, the source eNB shall include in the HANDOVER REQUIRED message one Source to Target Transparent Container IEs and encode the information in the Source to Target Transparent Container IE according to the definition of the Old BSS to New BSS information IE .

- the target system is GERAN with DTM support, then the source eNB shall include in the HANDOVER REQUIRED message two Source to Target Transparent Container IEs. The first shall be encoded according to the definition of the Source BSS to Target BSS Transparent Container IE . The second shall be encoded according to the definition of the Old BSS to New BSS information IE.

In case the SRVCC operation is performed, SRVCC HO Indication IE indicates that handover shall be prepared only for CS domain, the HANDOVER COMMAND message shall contain one Target to Source Transparent Container IE that shall be encoded according to the definition of the Layer 3 Information IE.

In case the SRVCC operation is performed, SRVCC HO Indication IE indicates that handover shall be prepared for PS and CS domain, and if

- the target system is GERAN without DTM support, then the HANDOVER COMMAND message shall contain one Target to Source Transparent Container IE that shall be encoded according to the definition of the Layer 3 Information IE.

- the target system is GERAN with DTM support, then the HANDOVER COMMAND message shall contain two Target to Source Transparent Container IEs. The first IE shall be encoded according to the definition of the Layer 3 Information IE as specified in [x1]. The second IE shall be encoded according to the definition of the Target BSS to Source BSS Transparent Container IE.


LZT 123 8958 R1A © Ericsson 2009 - 173 -

If the HANDOVER COMMAND message contains DL GTP-TEID IE and DL Transport Layer Address IE for a bearer in E-RABs Subject to Forwarding List IE then the target eNB accepts the forwarding of downlink data for this bearer, proposed by the source eNB.

If the HANDOVER COMMAND message contains UL GTP-TEID IE and UL Transport Layer Address IE for a bearer in E-RABs Subject to Forwarding List IE then the target eNB requests forwarding of uplink data for this bearer.

Interactions with E-RAB Management procedures:

If, after a HANDOVER REQUIRED message is sent and before the Handover Preparation procedure is terminated, the source eNB receives a MME initiated E-RAB Management procedure on the same UE associated signaling connection, the source eNB shall either:

1. cancel the Handover Preparation procedure by executing the Handover Cancel procedure with an appropriate cause value . After successful completion of the Handover Cancel procedure, the source eNB shall continue the MME initiated E-RAB Management procedure

or

2. terminate the MME initiated E-RAB Management procedure by sending the appropriate response message with an appropriate cause value e.g"S1 intra system or S1 inter system Handover Triggered" to the MME and then the source eNB shall continue with the handover procedure.

If the EPC or the target system is not able to accept any of the bearers or a failure occurs during the Handover Preparation, the MME sends the HANDOVER PREPARATION FAILURE message with an appropriate cause value to the source eNB.

Interaction with Handover Cancel procedure:

If there is no response from the EPC to the HANDOVER REQUIRED message before timer TS1RELOCprep expires in the source eNB, the source eNB should cancel the Handover Preparation procedure by initiating the Handover Cancel procedure with the appropriate value for the Cause IE. The source eNB shall ignore any HANDOVER COMMAND or HANDOVER PREPARATION FAILURE message received after the initiation of the Handover Cancel procedure.


- 174 - © Ericsson 2009 LZT 123 8958 R1A

HANDOVER RESOURCE ALLOCATION

The purpose of the Handover Resource Allocation procedure is to reserve resources at the target eNB for the handover of a UE.

MMEMME

HANDOVER REQUEST

HANDOVER REQUEST ACKNOWLEGE

target eNBtarget eNB

MMEMME

HANDOVER REQUEST

HANDOVER FAILURE


MMEMME

HANDOVER REQUEST

HANDOVER REQUEST ACKNOWLEGE


MMEMME

HANDOVER REQUEST

HANDOVER FAILURE


Figure 7-18 Handover Resource Allocation

The MME initiates the procedure by sending the HANDOVER REQUEST message to the target eNB. The HANDOVER REQUEST message may contain the Handover Restriction List IE, which may contain roaming area or access restrictions.

If the Handover Restriction List IE is contained in the HANDOVER REQUEST message, the target eNB shall store this information in the UE context.

The eNB shall use the information in Handover Restriction List IE if present in the HANDOVER REQUEST message to determine a target cell for handover. If the Handover Restriction List IE is not contained in the HANDOVER REQUEST message, the target eNB shall consider that no access restriction applies to the UE.

Upon receiption of the HANDOVER REQUEST message the eNB shall store the received UE Security Capabilities IE in the UE context and use it to prepare the configuration of the AS security relation with the UE.

If the SRVCC Operation Possible IE is included in the HANDOVER REQUEST message, the target eNB shall store the received SRVCC operation possible in the UE context .


LZT 123 8958 R1A © Ericsson 2009 - 175 -

Upon reception of the HANDOVER REQUEST message the eNB shall store the received Security Context IE in the UE context and the eNB shall use it to derive the security configuration.

If the Trace activation IE is included in the HANDOVER REQUEST message, the target eNB shall if supported, initiate the requested trace function as described in .

If the Subscriber Profile ID for RAT/Frequency priority IE is contained in the Source eNB to Target eNB Transparent Container IE, the target eNB shall store the received Subscriber Profile ID for RAT/Frequency priority in the UE context and use it.

Upon reception of the UE History Information IE, which is included within the Source eNB to Target eNB Transparent Container IE in the HANDOVER REQUEST message, the target eNB shall collect the information defined as mandatory and may collect the information defined as optional in the UE History Information IE, for as long as the UE stays in one of its cells, and store the collected information to be used for future handover preparations.

After all necessary resources for the admitted E-RABs have been allocated the target eNB generates the HANDOVER REQUEST ACKNOWLEDGE message. The target eNB shall include in the E-RABs Admitted List IE the E-RABs for which resources have been prepared at the target cell. The E-RABs that have not been admitted in the target cell shall be included in the E-RABs Failed to Setup List IE.

For each bearer that target eNB has decided to admit and for which DL forwarding IE is set to "DL forwarding proposed", the target eNB may include the DL GTP-TEID IE and the DL Transport Layer Address IE IE within the E-RABs Admitted List IEs IE of the HANDOVER REQUEST ACKNOWLEDGE message indicating that it accepts the proposed forwarding of downlink data for this bearer.

If the HANDOVER REQUEST ACKNOWLEDGE message contains UL GTP-TEID IE and UL Transport Layer Address IE for a bearer in E-RABs Admitted List IE then the target eNB requests forwarding of uplink data for this bearer.

If the Request Type IE is included in the HANDOVER REQUEST message then the target eNB should perform the requested location reporting functionality for the UE.


- 176 - © Ericsson 2009 LZT 123 8958 R1A

If the target eNB is not able to admit any of the E-RABs or a failure occurs during the Handover Preparation, it shall send the HANDOVER FAILURE message to the MME with an appropriate cause value.

If the target eNB receives a HANDOVER REQUEST message containing RRC Container IE that does not include required information , the target eNB shall send the HANDOVER FAILURE message to the MME.

If the eNB receives a HANDOVER REQUEST message containing a E-RAB Level QoS Parameters IE which contains a QCI IE indicating a GBR bearer (as defined in [13]), and which does not contain the GBR QoS Information IE, the eNB shall not admit the corresponding E-RAB.

If the eNB receives a HANDOVER REQUEST message containing several E-RAB ID IEs (in the E-RABs To Be Setup List IE) set to the same value, the eNB shall not admit the corresponding E-RABs.

If the Subscriber Profile ID for RAT/Frequency priority IE is not contained in the Source eNB to Target eNB Transparent Container IE whereas available in the source eNB, the target eNB shall trigger a local error handling.


LZT 123 8958 R1A © Ericsson 2009 - 177 -

If the supported algorithms for encryption defined in the Encryption Algorithms IE in the UE Security Capabilities IE, plus the mandated support of EEA0 in all UEs , do not match any allowed algorithms defined in the configured list of allowed encryption algorithms in the eNB , the eNB shall reject the procedure using the HANDOVER FAILURE message.

If the supported algorithms for integrity defined in the Integrity Protection Algorithms IE in the UE Security Capabilities IE, do not match any allowed algorithms defined in the configured list of allowed integrity protection algorithms in the eNB or if all bits in Integrity Protection Algorithms IE are equal to 0, the eNB shall reject the procedure using the HANDOVER FAILURE message.

HANDOVER NOTIFICATION

The purpose of the Handover Notification procedure is to indicate to the MME that the UE has arrived to the target cell and the S1 handover has been successfully completed.

MMEMME

HANDOVER NOTIFY

target eNBtarget eNB MMEMME

HANDOVER NOTIFY


Figure 7-19 Handover Notification

The target eNB shall send the HANDOVER NOTIFY message to the MME when the UE has been identified in the target cell and the S1 handover has been successfully completed.


- 178 - © Ericsson 2009 LZT 123 8958 R1A

PATH SWITCH REQUEST

The purpose of the Path Switch Request procedure is to request the switch of a downlink GTP tunnel towards a new GTP tunnel endpoint.

MMEMME

PATH SWITCH REQUEST


eNBeNB

MMEMME

PATH SWITCH REQUEST


eNBeNB

MMEMME

PATH SWITCH REQUEST


eNBeNB

MMEMME

PATH SWITCH REQUEST


eNBeNB

Figure 7-20 Path Switch Request

The eNB initiates the procedure by sending the PATH SWITCH REQUEST message to the MME.

If the E-RAB To Be Switched in Downlink List IE in the PATH SWITCH REQUEST message does not include all E-RABs previously included in the Ue Context, the MME shall consider the non included E-RABs as implicitly released by the eNB.

After all necessary updates including the UP path switch have been successfully completed in the EPC for at least one of the E-RABs included in the PATH SWITCH REQUEST E-RAB To Be Switched in Downlink List IE, the MME shall send the PATH SWITCH REQUEST ACKNOWLEDGE message to the eNB and the procedure ends.


LZT 123 8958 R1A © Ericsson 2009 - 179 -

In case the EPC failed to perform the UP path switch for at least one, but not all, of the E-RABs included in the PATH SWITCH REQUEST E-RAB To Be Switched in Downlink List IE, the MME shall include the E-RABs it failed to perform UP path switch in the PATH SWITCH REQUEST ACKNOWLEDGE E-RAB t To Be Released List IE. In this case, the eNB shall release the corresponding data radio bearers, and the eNB shall regard the E-RABs indicated in the E-RAB To Be Released List IE as being fully released.

Upon reception of the PATH SWITCH REQUEST ACKNOWLEDGE message the eNB shall store the received Security Context IE in the UE context and the eNB shall use it for the next X2 handover or Intra eNB handovers.

The PATH SWITCH REQUEST ACKNOWLEDGE message may contain

- the UE Aggregate Maximum Bit Rate IE

If the UE Aggregate Maximum Bit Rate IE is included in the PATH SWITCH REQUEST ACKNOWLEDGE the eNB shall

- replace the previously provided UE Aggregate Maximum Bit Rate by the received UE Aggregate Maximum Bit Rate in the UE context; the eNB shall use the received UE Aggregate Maximum Bit Rate for non-GBR Bearers for the concerned UE.

If the UE Aggregate Maximum Bit Rate IE is not contained in the PATH SWITCH REQUEST ACKNOWLEDGE message, the eNB shall use the previously provided UE Aggregate Maximum Bit Rate which is stored in the UE context.

In case the EPC decides to change the uplink termination point of the tunnels it may include the E-RAB To Be Switched in Uplink List IE in the PATH SWITCH REQUEST ACKNOWLEDGE message to specify a new uplink transport layer address and uplink GTP-TEID for each respective E-RAB for which it wants to change the uplink tunnel termination point.

When the eNB receives the PATH SWITCH REQUEST ACKNOWLEDGE message and if this message includes the E-RAB To Be Switched in Uplink List IE, the eNB shall start delivering the uplink packets of the concerned E-RABs to the new uplink tunnel endpoints as indicated in the message.


- 180 - © Ericsson 2009 LZT 123 8958 R1A

the MME receives a PATH SWITCH REQUEST message containing several E-RAB ID IEs (in the E-RAB To Be Switched in Uplink List IE) set to the same value, the MME shall send the PATH SWITCH REQUEST FAILURE message to the eNB.

HANDOVER CANCELLATION

The purpose of the Handover Cancel procedure is to enable a source eNB to cancel an ongoing handover preparation or an already prepared handover.

The procedure uses UE-associated signaling.

MMEMME

HANDOVER CANCEL


source eNBsource eNB MMEMME

HANDOVER CANCEL



Figure 7-21 Handover Cancellation

The source eNB initiates the procedure by sending a HANDOVER CANCEL message to the EPC.

The HANDOVER CANCEL message shall indicate the reason for cancelling the handover by the appropriate value of the Cause IE

Upon reception of a HANDOVER CANCEL message, the EPC shall terminate the ongoing Handover Preparation procedure, release any resources associated with the handover preparation and send a HANDOVER CANCEL ACKNOWLEDGE message to the source eNB.

Transmission and reception of a HANDOVER CANCEL ACKNOWLEDGE message terminate the procedure in the EPC and in the source eNB. After this, the source eNB does not have a prepared handover for that UE-associated logical S1-connection.


LZT 123 8958 R1A © Ericsson 2009 - 181 -

ENODE B STATUS TRANSFER

MMEMME

eNB STATUS TRANSFER

eNBeNB MMEMME

eNB STATUS TRANSFER

eNBeNB

Figure 7-22 eNode B Status Transfer

The source eNB initiates the procedure by stop assigning PDCP SNs to downlink SDUs and sending the eNB STATUS TRANSFER message to the MME at the time point when it considers the transmitter/receiver status to be freezed.

- For each E-RAB for which PDCP-SN and HFN status preservation applies the source eNB shall include the E-RAB ID IE, the UL COUNT value IE and the DL COUNT value IE within the E-RABs Subject to Status Transfer Item IE in the eNB Status Transfer Transparent Container IE of the eNB STATUS TRANSFER message.

The source eNB may also include in the eNB STATUS TRANSFER message the missing and received uplink SDUs in the Receive Status Of UL PDCP SDUs IE for each bearer for which the source eNB has accepted the request from the target eNB for uplink forwarding.


- 182 - © Ericsson 2009 LZT 123 8958 R1A

MME STATUS TRANSFER

The purpose of the 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 to the target eNB via the MME during an S1 handover for each respective E-RAB for which PDCP SN and HFN status preservation applies.

MMEMME

MME STATUS TRANSFER

eNBeNB MMEMME

MME STATUS TRANSFER

eNBeNB

Figure 7-23. MME Status Transfer

The MME initiates the procedure by sending the MME STATUS TRANSFER message to the eNB.

For each bearer within the E-RABs Subject to Status Transfer List IE within the eNB Status Transfer Transparent Container IE for which the UL COUNT value IE is received in the MME STATUS TRANSFER message, the target eNB shall use it and not deliver any uplink packet which has a PDCP SN lower than the value contained in the PDCP SN IE of this IE.

For each bearer in E-RABs Subject to Status Transfer List IE within the eNB Status Transfer Transparent Container IE received in the MME STATUS TRANSFER message, the target eNB shall use DL COUNT valueIE for the first downlink packet for which there is no PDCP SN yet assigned.

If the Receive Status Of UL PDCP SDUs IE is included for at least one bearer in the eNB Status Transfer Transparent Container IE of the MME STATUS TRANSFER message, the target eNB may use it in a Status Report message sent to the UE over the radio.

If the target eNB receives this message for a UE for which no prepared handover exists at the target eNB, the target eNB shall ignore the message.


LZT 123 8958 R1A © Ericsson 2009 - 183 -

PAGING The purpose of the Paging procedure is to enable the MME to page a UE in the specific eNB.

MMEMME

PAGING

eNBeNB MMEMME

PAGING

eNBeNB

Figure 7-24 Paging

The MME initiates the paging procedure by sending the PAGING message to the eNB.

At the reception of the PAGING message, the eNB shall perform paging of the UE in cells which belong to tracking areas as indicated in the List of TAIs IE.

The CN Domain IE shall be transferred transparently to the UE.

The Paging DRX IE may be included in the PAGING message.

The Allowed CSG ID List of the paged UE (CSG Id List IE) may be included in the PAGING message if respective subscription information is available for that UE. If present, the E-UTRAN shall, if possible, avoid to send paging UEs within CSG cells for which the UE has no subscription.

For each cell that belongs to any of the TA indicated in the List of TAIs IE, the eNB shall generate one page on the radio interface.


- 184 - © Ericsson 2009 LZT 123 8958 R1A

NAS TRANSPORT The purpose of the NAS Transport procedure is to carry UE – MME signalling over the S1 Interface. The NAS messages are not interpreted by the eNB, and their content is outside the scope of this specification. The procedure may use an existing UE-associated logical S1-connection. If no UE-associated logical S1-connection exists, the establishment of the UE-associated logical S1-connection is initiated (and may be established) as part of the procedure.

The NAS messages are transported in an IE of the INITIAL UE MESSAGE, DOWNLINK NAS TRANSPORT or UPLINK NAS TRANSPORT messages.

MMEMME

INITIAL UE MESSAGE

eNBeNB MMEMME

INITIAL UE MESSAGE

eNBeNB

Figure 7-25 Initial UE Message

When the eNB has received from the radio interface the first UL NAS message transmitted on an RRC connection to be forwarded to an MME, the eNB shall invoke the NAS Transport procedure and send the INITIAL UE MESSAGE to the MME including the NAS message as a NAS-PDU IE. The eNB shall allocate a unique eNB UE S1AP ID to be used for the UE and the eNB shall include this identity in the INITIAL UE MESSAGE message. In case of network sharing, the selected PLMN is indicated by the PLMN ID part of the TAI IE included in the INITIAL UE MESSAGE message. When the eNB has received from the radio interface the S-TMSI IE, it shall include it in the INITIAL UE MESSAGE message.

If the establishment of the UE-associated logical S1-connection towards the CN is performed due to an RRC connection establishment originating from a CSG cell, the CSG Id IE shall be included in the INITIAL UE MESSAGE message.

NOTE: The first UL NAS message is always received in the RRC CONNECTION SETUP COMPLETE message.


LZT 123 8958 R1A © Ericsson 2009 - 185 -

DL/UL NAS TRANSPORT

MMEMME

UPLINK NAS TRANSPORT

eNBeNB

DOWNLINK NAS TRANSPORT

MMEMME

UPLINK NAS TRANSPORT

eNBeNB

DOWNLINK NAS TRANSPORT

Figure 7-26 DL/UL NAS Transport

If the MME only need to send a NAS message transparently via the eNB to the UE and a UE-associated logical S1-connection exists for the UE or if the MME have received the eNB UE S1AP ID IE in an INITIAL UE MESSAGE message, the MME shall send a DOWNLINK NAS TRANSPORT message to the eNB including the NAS message as a NAS-PDU IE. If the UE-associated logical S1-connection is not established the MME shall allocate a unique MME UE S1AP ID to be used for the UE and include that in the DOWNLINK NAS TRANSPORT message. By the reception of MME UE S1AP ID IE in eNB the UE-associated logical S1-connection is established.

The NAS-PDU IE contains an MME – UE message that is transferred without interpretation in the eNB.

The DOWNLINK NAS TRANSPORT message may contain the Handover Restriction List IE, which may contain roaming area or access restrictions.

If the Handover Restriction List IE is contained in the DOWNLINK NAS TRANSPORT message, the target eNB shall store this information in the UE context.

The eNB shall use the information in Handover Restriction List IE if present in the DOWNLINK NAS TRANSPORT message to determine a target cell for handover. If the Handover Restriction List IE is not contained in the DOWNLINK NAS TRANSPORT message and there is no previously stored Handover restriction information, the target eNB shall consider that no access restriction applies to the UE.


- 186 - © Ericsson 2009 LZT 123 8958 R1A

When the eNB has received from the radio interface a NAS message to be forwarded to the MME to which an UE-associated logical S1-connection for the UE exists, the eNB shall send the UPLINK NAS TRANSPORT message to the MME including the NAS message as a NAS-PDU IE. The eNB shall include the TAI and ECGI of the current cell in every S1-AP UPLINK NAS TRANSPORT message.

The NAS-PDU IE contains an UE - MME message that is transferred without interpretation in the eNB.

NAS NON DELIVERY INDICATION

MMEMME


eNBeNB MMEMME


eNBeNB

Figure 7-27 NAS Non Delivery Indication

When the eNB decides to not start the delivery of a NAS message that has been received over an UE-associated logical S1-connection or the eNB is unable to ensure that the message has been received by the UE, it shall report the non-delivery of this NAS message by sending a NAS NON DELIVERY INDICATION message to the MME including the non-delivered NAS message within the NAS-PDU IE and an appropriate cause value within an appropriate Cause IE e.g. "S1 intra system or S1 inter system" or "X2 Handover Triggered".

If the S-TMSI is not received by the MME in the INITIAL UE MESSAGE message whereas expected, the MME shall consider the procedure as failed.


LZT 123 8958 R1A © Ericsson 2009 - 187 -

MANAGEMENT PROCEDURES

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. This procedure doesn’t affect the application level configuration data exchanged during the S1 Setup procedure.

The procedure uses non-UE associated signaling.

MMEMME

RESET

RESET ACKNOWLEDGE

eNBeNB

MMEMME

RESET

RESET ACKNOWLEDGE

eNBeNB

A. Initiated from MME

B. Initiated from UTRAN

MMEMME

RESET

RESET ACKNOWLEDGE

eNBeNB

MMEMME

RESET

RESET ACKNOWLEDGE

eNBeNB

A. Initiated from MME

B. Initiated from UTRAN

Figure 7-28 Reset

In the event of a failure at the MME, which has resulted in the loss of some or all transaction reference information, a RESET message shall be sent to the eNB.

At reception of RESET message the eNB shall release all allocated resources on S1 and Uu related to the UE association(s) indicated explicitly or implicitly in the RESET message and remove the indicated UE contexts including S1AP ID.

After the eNB has released all assigned S1 resources and the UE S1AP IDs for all indicated UE associations which can be used for new UE-associated logical S1-connections over the S1 interface, the eNB shall respond with the RESET ACKNOWLEDGE message. The eNB does not need to wait for the release of radio resources to be completed before returning the RESET ACKNOWLEDGE message.


- 188 - © Ericsson 2009 LZT 123 8958 R1A

If the RESET message contains the UE-associated logical S1-connection list IE, then:

- The eNB shall use the MME UE S1AP ID IE and/or the eNB UE S1AP ID IE to explicitly identify the UE association(s) to be reset.

- The eNB shall in the RESET ACKNOWLEDGE message include, for each UE association to be reset, the UE-associated logical S1-connection Item IE in theUE-associated logical S1-connection list IE. The UE-associated logical S1-connection Item IEs shall be in the same order as received in the RESET message and shall include also unknown UE-associated logical S1-connections. Empty UE-associated logical S1-connection Item IEs, received in the RESET message, may be omitted in the RESET ACKNOWLEDGE message.

- If the MME UE S1AP ID IE is included in the UE-associated logical S1-connection Item IE for a UE association, the eNB shall include the MME UE S1AP ID IE in the corresponding UE-associated logical S1-connection Item IE in the RESET ACKNOWLEDGE message.

- If the eNB UE S1AP ID IE is included in the UE-associated logical S1-connection Item IE for a UE association, the eNB shall include the eNB UE S1AP ID IE in the corresponding UE-associated logical S1-connection Item IE in the RESET ACKNOWLEDGE message.

Interactions with other procedures:

If the RESET message is received, any other ongoing procedure (except another Reset procedure) on the same S1 interface related to a UE association, indicated explicitly or implicitly in the RESET message, shall be aborted.

In the event of a failure at the eNB, which has resulted in the loss of some or all transaction reference information, a RESET message shall be sent to the MME.

At reception of RESET message the MME shall release all allocated resources on S1 related to the UE association(s) indicated explicitly or implicitly in the RESET message and remove the S1AP ID for the indicated UE associations.

After the MME has released all assigned S1 resources and the UE S1AP IDs for all indicated UE associations which can be used for new UE-associated logical S1-connections over the S1 interface, the MME shall respond with the RESET ACKNOWLEDGE message.


LZT 123 8958 R1A © Ericsson 2009 - 189 -

If the RESET message contains the UE-associated logical S1-connection list IE, then:

- The MME shall use the MME UE S1AP ID IE and/or the eNB UE S1AP ID IE to explicitly identify the UE association(s) to be reset.

- The MME shall in the RESET ACKNOWLEDGE message include, for each UE association to be reset, the UE-associated logical S1-connection Item IE in theUE-associated logical S1-connection list IE. The UE-associated logical S1-connection Item IEs shall be in the same order as received in the RESET message and shall include also unknown UE-associated logical S1-connections. Empty UE-associated logical S1-connection Item IEs, received in the RESET message, may be omitted in the RESET ACKNOWLEDGE message.

- If the MME UE S1AP ID IE is included in the UE-associated logical S1-connection Item IE for a UE association, the MME shall include the MME UE S1AP ID IE in the corresponding UE-associated logical S1-connection Item IE in the RESET ACKNOWLEDGE message.

- If the eNB UE S1AP ID IE is included in a UE-associated logical S1-connection Item IE for a UE association, the MME shall include the eNB UE S1AP ID IE in the corresponding UE-associated logical S1-connection Item IE in the RESET ACKNOWLEDGE message.


If the RESET message is received, any other ongoing procedure (except another Reset procedure) on the same S1 interface related to a UE association, indicated explicitly or implicitly in the RESET message, shall be aborted.

ERROR INDICATION

The Error Indication procedure is initiated by a node to report detected errors in one incoming message, provided they cannot be reported by an appropriate failure message.

If the error situation arises due to reception of a message utilizing UE associated signaling, then the Error Indication procedure uses UE associated signaling. Otherwise the procedure uses non-UE associated signaling.


- 190 - © Ericsson 2009 LZT 123 8958 R1A

MMEMME

ERROR INDICATION

eNBeNB

MMEMME

ERROR INDICATION

eNBeNB

A. MME Originated

B. eNB Originated

MMEMME

ERROR INDICATION

eNBeNB

MMEMME

ERROR INDICATION

eNBeNB

MMEMME

ERROR INDICATION

eNBeNB

MMEMME

ERROR INDICATION

eNBeNB

A. MME Originated

B. eNB Originated

Figure 7-29 Error Indication

When the conditions defined in clause 10 are fulfilled, the Error Indication procedure is initiated by an ERROR INDICATION message sent from the receiving node.

The ERROR INDICATION message shall contain at least either the Cause IE or the Criticality Diagnostics IE.

In case the Error Indication procedure is triggered by utilising UE associated signalling the MME UE S1AP ID IE and the eNB UE S1AP IE shall be included in the ERROR INDICATION message. If one or both of MME UE S1AP ID IE and the eNB UE S1AP IE are not correct, the cause shall be set to appropriate value e.g. "Unknown MME UE S1AP ID", "Unknown eNB UE S1AP" or "Unknown pair of UE S1AP ID".

S1 SETUP

The purpose of the S1 Setup procedure is to exchange application level data needed for the eNB and MME to interoperate correctly on the S1 interface. This procedure shall be the first S1AP procedure triggered after the TNL association has become operational. The procedure uses non-UE associated signaling.


LZT 123 8958 R1A © Ericsson 2009 - 191 -

This procedure erases any existing application level configuration data in the two nodes and replaces it by the one received. This procedure also re-initialises the E-UTRAN S1AP UE-related contexts (if any) and erases all related signalling connections in the two nodes like a Reset procedure would do, and clears MME overload state information at the eNB. If the eNB or Home eNB initiating the S1 Setup procedure supports a CSG cell, the procedure shall report the CSG ID(s) of the supported CSGs.

MMEMME

S1 SETUP REQUEST

S1 SETUP RESPONSE

eNBeNB

MMEMME

S1 SETUP REQUEST

S1 SETUP FAILURE

eNBeNB

MMEMME

S1 SETUP REQUEST

S1 SETUP RESPONSE

eNBeNB

MMEMME

S1 SETUP REQUEST

S1 SETUP FAILURE

eNBeNB

Figure 7-30 S1 Setup

The eNB initiates the procedure by sending a S1 SETUP REQUEST message including the appropriate data to the MME. The MME responds with S1 SETUP RESPONSE including the appropriate data.

The exchanged data shall be stored in respective node and used for the duration of the TNL association. When this procedure is finished S1 interface is operational and other S1 messages can be exchanged.

If the eNB initiating the S1 SETUP procedure supports one (or more) CSG cell(s), the S1 SETUP REQUEST shall contain the CSG ID(s) of the supported CSG(s).

If the S1 SETUP REQUEST message contains the eNB Name IE the MME may use this IE as a human readable name of the eNB.

If the S1 SETUP RESPONSE message contains the MME Name IE the eNB may use this IE as a human readable name of the MME.


- 192 - © Ericsson 2009 LZT 123 8958 R1A

If the MME can not accept the setup it should respond with a S1 SETUP FAILURE and appropriate cause value.

If the S1 SETUP FAILURE messages include the Time To Wait IE the eNB shall wait at least for the indicated time before reinitiating the S1 setup towards the same MME.

If the eNB initiates the procedure by sending a S1 SETUP REQUEST message including the PLMN Identity IEs and the MME is not able to identify at least one of the PLMNs provided by the eNB, then the MME shall reject the eNB S1 Setup Request procedure with the appropriate cause value e.g "Unknown PLMN".

ENODE B CONFIGURATION UPDATE

The purpose of the eNB Configuration Update procedure is to update application level configuration data needed for the eNB and MME to interoperate correctly on the S1 interface. This procedure does not affect existing UE-related contexts, if any.

MMEMME



eNBeNB

MMEMME



eNBeNB

MMEMME



eNBeNB

MMEMME



eNBeNB

Figure 7-31 eNB Configuration Update

The eNB initiates the procedure by sending an ENB CONFIGURATION UPDATE message including the appropriate updated configuration data to the MME. The MME responds with ENB CONFIGURATION UPDATE ACKNOWLEDGE message to acknowledge that it successfully updated the configuration data. If information element(s) is/are not included in the ENB CONFIGURATION UPDATE message, the MME shall interpret that the corresponding configuration data is/are not changed and shall continue to operate the S1 with the existing related configuration data.


LZT 123 8958 R1A © Ericsson 2009 - 193 -

If the supported TA(s) is(are) to be updated, the whole list of supported TAs including those that are not to be updated shall be included in the Supported TAs IE. The MME shall overwrite the whole list of TAs.

If the supported CSG ID(s) is(are) to be updated, the whole list of supported CSG IDs including those that are not to be updated shall be included in the CSG Id List IE. The MME shall overwrite the whole list of CSG Ids.

If the ENB CONFIGURATION UPDATE message contains the eNB Name IE the MME may use this IE as a human readable name of the eNB.

If the Default Paging DRX IE is included, the MME shall overwrite any previously stored default paging DRX value for the eNB.

The updated configuration data shall be stored in both eNB and MME and used for the duration of the TNL association or until any further update is triggered by the eNB.

The eNB may initiate a further eNB Configuration Update procedure only after a previous eNB Configuration Update procedure has been completed.

If the MME can not accept the update it shall respond with an ENB CONFIGURATION UPDATE FAILURE message and appropriate cause value.

If the ENB CONFIGURATION UPDATE FAILURE messages includes the Time To Wait IE the eNB shall wait at least for the indicated time before reinitiating the ENB Configuration Update procedure towards the same MME. Both nodes shall continue to operate the S1 with the existing configuration data.

If the eNB after initiating eNB Configuration Update procedure receives neither an ENB CONFIGURATION UPDATE ACKOWLEDGE nor an ENB CONFIGURATION UPDATE FAILURE message, the eNB may reinitiate a further eNB Configuration Update procedure towards the same MME.


- 194 - © Ericsson 2009 LZT 123 8958 R1A


The purpose of the MME Configuration Update procedure is to update application level configuration data needed for the eNB and MME to interoperate correctly on the S1 interface. This procedure doesn’t affect existing UE-related contexts, if any.

MMEMME



eNBeNB

MMEMME



eNBeNB

MMEMME



eNBeNB

MMEMME



eNBeNB

Figure 7-32 MME Configuration Update

The MME initiates the procedure by sending an MME CONFIGURATION UPDATE message including the appropriate updated configuration data to the eNB. The eNB responds with MME CONFIGURATION UPDATE ACKNOWLEDGE to acknowledge that it successfully updated the configuration data. If information element(s) is/are not included in the MME CONFIGURATION UPDATE message, the eNB shall interpret that the corresponding configuration data is/are not changed and shall continue to operate the S1 with the existing related configuration data.

If the served PLMNs is(are) to be updated, the eNB shall overwrite the whole list of PLMNs.

If the MME CONFIGURATION UPDATE message contains the MME Name IE the eNB may use this IE as a human readable name of the MME.

The updated configuration data shall be stored in respective node and used for the duration of the TNL association or until any further update is performed from the MME.


LZT 123 8958 R1A © Ericsson 2009 - 195 -

The MME may initiate a further MME Configuration Update procedure only after a previous MME Configuration Update procedure has been completed.

If the eNB can not accept the update it shall respond with an MME CONFIGURATION UPDATE FAILURE message and appropriate cause value.

If the MME CONFIGURATION UPDATE FAILURE message includes the Time To Wait IE the MME shall wait at least for the indicated time before reinitiating the MME Configuration Update procedure towards the same eNB. Both nodes shall continue to operate the S1 with the existing configuration data.

If the MME neither receives a MME CONFIGURATION UPDATE ACKOWLEDGE nor a MME CONFIGURATION UPDATE FAILURE message, the MME may reinitiate MME Configuration Update procedure towards the same eNB provided that the content of the new MME CONFIGURATION UPDATE message is identical to the content of the previously unacknowledged MME CONFIGURATION UPDATE message.


- 196 - © Ericsson 2009 LZT 123 8958 R1A

OVERLOAD START/STOP The purpose of the Overload Start procedure is to inform an eNB to reduce the signalling load towards the concerned MME.

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


MMEMME

OVERLOAD START

eNBeNB

MMEMME

OVERLOAD STOP

eNBeNB

MMEMME

OVERLOAD START

eNBeNB

MMEMME

OVERLOAD STOP

eNBeNB

Figure 7-33 Overload Start/Stop

The eNB receiving the OVERLOAD START message shall assume the MME from which it receives the message as being in an overloaded state.

If the Overload Action IE in the OVERLOAD START message is set to

- "reject all RRC connection requests for non-emergency mobile originated data transfer ", or

- "reject all new RRC connection requests for signalling ",or

- "only permit RRC connection establishments for emergency sessions".

the eNB shall reject/permit the indicated signalling traffic.

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



LZT 123 8958 R1A © Ericsson 2009 - 197 -

S1 CDMA2000 TUNNELING PROCEDURES The purpose of S1 CDMA2000 Tunneling procedures is to carry CDMA2000 signaling between UE and CDMA2000 RAT over the S1 Interface. This includes signaling for pre-registration of UE with CDMA2000 HRPD network, signaling for handover preparation for handover from E-UTRAN to CDMA2000 HRPD/1xRTT and pre-registration and paging of UE with CDMA2000 1xRTT CS system. The CDMA2000 messages are not interpreted by the eNB, and their content is outside the scope of this specification, however, additional information may be sent along with the tunneled CDMA2000 message to assist the eNB and MME in the tunneling procedure. These procedures use an established UE-associated logical S1-connection.

The CDMA2000 messages are transported in an IE of the DOWNLINK S1 CDMA2000 TUNNELING or UPLINK S1 CDMA2000 TUNNELING messages.

MMEMME

DOWNLINK S1 CDMA2000 TUNNELING

eNBeNB

MMEMMEeNBeNB

UPLINK S1 CDMA2000 TUNNELING

MMEMME

DOWNLINK S1 CDMA2000 TUNNELING

eNBeNB

MMEMMEeNBeNB

UPLINK S1 CDMA2000 TUNNELING

Figure 7-34 S1 CDMA 2000 Tunneling Procedures DL/UL

If a CDMA2000 message shall be sent from the MME to the UE and a UE-associated logical S1-connection exists for the UE the MME should send a DOWNLINK S1 CDMA2000 TUNNELING message to the eNB including the CDMA2000 message in the CDMA2000-PDU IE. The eNB forwards the received CDMA2000-PDU IE to the UE along with an indication of the RAT Type associated with the CDMA2000-PDU IE based on the CDMA2000 RAT Type IE.


- 198 - © Ericsson 2009 LZT 123 8958 R1A

If the MME receives handover status information along with the tunnelled downlink CDMA2000 message the MME should include the handover status information in CDMA2000 HO Status IE in the DOWNLINK S1 CDMA2000 TUNNELING message.

If the DOWNLINK S1 CDMA2000 TUNNELING message contains the E-RABs Subject to Forwarding List IE it indicates that DL forwarding is available for the indicated E-RABs towards the tunnel endpoint identified by the DL GTP TEID IE for those E-RABs.

When the eNB has received from the radio interface a CDMA2000 message to be forwarded to the MME to which an UE-associated logical S1-connection for the UE exists, the eNB shall send the UPLINK S1 CDMA2000 TUNNELING message to the MME including the CDMA2000 message in the CDMA2000-PDU IE.

If the MME receives the CDMA2000 HO Required Indication IE set to "true" in UPLINK S1 CDMA2000 TUNNELING message the MME should send the necessary handover preparation information to the CDMA2000 target RAT.

If the MME receives any of the CDMA2000 1xRTT SRVCC InfoIE, or the CDMA2000 1xRTT RAND IE in the UPLINK S1 CDMA2000 TUNNELING message the MME should forward the received information to the CDMA2000 1xRTT RAT.

Interactions with E-RAB Management procedures:

If, after an UPLINK S1 CDMA2000 TUNNELING message with CDMA2000 HO Required Indication IE set to "true" is sent but before the DOWNLINK S1 CDMA2000 TUNNELING message with CDMA2000 HO Status IE is received, the source eNB receives a MME initiated E-RAB Management procedure on the same UE associated signaling connection, the source eNB shall terminate the MME initiated E-RAB Management procedure by sending the appropriate response message with an appropriate cause value e.g "S1 intra system or S1 inter system Handover Triggered" to the MME.


LZT 123 8958 R1A © Ericsson 2009 - 199 -

UE CAPABILITY INFO INDICATION The purpose of the UE Capability Info Indication procedure is used to enable the eNB to provide this information and relevant updates of this information within the eNB that took place without MME notice within the E-UTRAN to the MME.

MMEMME

UE CAPABILITY INFO INDICATION

eNBeNB MMEMME

UE CAPABILITY INFO INDICATION

eNBeNB

Figure 7-35 UE Capability Info Indication

The eNB controlling a UE-associated logical S1-connection initiates the procedure by generating an UE CAPABILITY INFO INDICATION message towards the affected MME node including UE capability information. The UE capability information provided to the MME should overwrite respective UE capability related information stored in the MME.


- 200 - © Ericsson 2009 LZT 123 8958 R1A

TRACE PROCEDURES

TRACE START/TRACE FAILURE INDICATION/DEACTIVATE TRACE

The purpose of the Trace Start procedure is to allow the MME to request the eNB to start a trace session for a UE in ECM_CONNECTED mode. The procedure uses UE-associated signaling.

The purpose of the Trace Failure Indication procedure is to allow the eNB to inform the MME that a Trace Start procedure or a Deactivate Trace procedure has failed due to an interaction with a handover procedure. The procedure uses UE-associated signaling.

The purpose of the Deactivate Trace procedure is to allow the MME to request the eNB to stop the trace session, for the indicated trace reference.

MMEMME

TRACE START

TRACE FAILURE INDICATION

eNBeNB

MMEMME

DEACTIVATE TRACE

eNBeNB

Deactivate Trace

MMEMME

TRACE START


eNBeNB MMEMME

TRACE START


eNBeNB

MMEMME

DEACTIVATE TRACE

eNBeNB MMEMME

DEACTIVATE TRACE

eNBeNB

Deactivate Trace

Figure 7-36 Trace Start

The MME initiates the procedure by sending a TRACE START message. On receipt of a TRACE START message, the eNB shall initiate the requested trace function.


If the eNB is not able to initiate the trace session due to ongoing handover of the UE to another eNB, the eNB shall initiate a Trace Failure Indication procedure with appropriate cause value.


LZT 123 8958 R1A © Ericsson 2009 - 201 -

The eNB initiates the procedure by sending a TRACE FAILURE INDICATION message. Upon reception of the TRACE FAILURE INDICATION message, the MME shall take appropriate action based on the failure reason indicated by the Cause IE.

The MME invokes the Deactivate Trace procedure by sending a DEACTIVATE TRACE message to the eNB.

Upon reception of this message, the eNB shall stop the trace session for the indicated trace reference in the E-UTRAN Trace ID IE.


If the eNB is not able to stop the trace session due to ongoing handover of the UE to another eNB, the eNB shall initiate a Trace Failure Indication procedure with appropriate cause value.


- 202 - © Ericsson 2009 LZT 123 8958 R1A

LOCATION REPORTING PROCEDURES

LOCATION REPORTING CONTROL/LOCATION REPORT FAILURE

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 procedure uses UE-associated signaling.

The Location Report Failure Indication procedure is initiated by an eNB in order to inform the MME that a Location Reporting Control procedure has failed. The procedure uses UE-associated signaling.

The purpose of Location Report procedure is to provide the UE's current location to the MME. The procedure uses UE-associated signaling

MMEMME

LOCATION REPORTING CONTROL

LOCATION REPORT FAILURE INDICATION

eNBeNB

MMEMME

LOCATION REPORT

eNBeNB

Location Report

MMEMME

LOCATION REPORTING CONTROL

LOCATION REPORT FAILURE INDICATION

eNBeNB

MMEMME

LOCATION REPORT

eNBeNB

Location Report

Figure 7-37 Location Reporting Control

The MME initiates the procedure by sending a LOCATION REPORTING CONTROL message. On receipt of a LOCATION REPORTING CONTROL message the eNB shall perform the requested location reporting control action for the UE.

The Request Type IE indicates to the eNB whether:

- to report directly;

- to report upon change of serving cell, or

- to stop reporting at change of serving cell.


LZT 123 8958 R1A © Ericsson 2009 - 203 -

If reporting upon change of serving cell is requested, the eNB shall report whenever the UE changes its serving cell to another cell belonging to the eNB.

The Request Type IE also indicates what type of location information the eNB shall report. The location information is E-UTRAN CGI and TAI.

Upon reception of the LOCATION REPORT FAILRE INDICATION message the MME shall based on the failure reason indicated by the Cause IE take appropriate action.

The eNB initiates the procedure by generating a LOCATION REPORT message. The LOCATION REPORT message may be used as a response to a LOCATION REPORTING CONTROL message.

In case reporting at change of serving cell has been requested, the eNB shall send a LOCATION REPORT message whenever the information given to the EPC in any S1AP message is not anymore valid.


- 204 - © Ericsson 2009 LZT 123 8958 R1A

WARNING MESSAGE TRANSMISSION PROCEDURES

WRITE REPLACE WARNING

The purpose of Write-Replace Warning procedure is to start and overwrite the broadcasting of warning message.

The procedure uses non UE-associated signaling.

MMEMME



eNBeNB MMEMME



eNBeNB

Figure 7-38 Write-Replace Warning

The MME initiates the procedure by sending a WRITE-REPLACE WARNING REQUEST message to the eNB.

Upon receipt of the WRITE-REPLACE WARNING REQUEST, eNB shall prioritize its resources to process the warning message.

If, in a certain area, broadcast of a warning message is already ongoing and the eNB receives a WRITE-REPLACE WARNING REQUEST message with Message Identifier IE and/or Serial Number IE which are different from those in the warning message being broadcast, the eNB shall replace the warning message being broadcast with the newly received one for that area.

If the eNB receives two or more WRITE-REPLACE WARNING REQUEST messages with the same Message Identifier IE and Serial Number IE, the eNB shall broadcast only one of the warning message.

If Warning Area List IE is not included in the WRITE-REPLACE WARNING REQUEST message, the eNB shall broadcast the indicated message in all of the cells within the eNB.


LZT 123 8958 R1A © Ericsson 2009 - 205 -

If Warning Type IE is included in WRITE-REPLACE WARNING REQUEST message, the eNB shall broadcast the Primary Notification the same way as if the Repetition Period IE is set as "0" and the Number of Broadcasts Requested IE is set as "1".

If the Warning Security Information IE is included in the WRITE-REPLACE WARNING REQUEST message, the eNB shall send this IE together with the Warning Type IE in the Primary Notification.

If the Data Coding Scheme IE and the Warning Message Contents IE are both included in the WRITE-REPLACE WARNING REQUEST message, the eNB shall broadcast the Secondary Notification according to the value of the Repetition Period IE and Number of Broadcasts Requested IE and process the Secondary Notification.

The eNB ends the procedure by sending a WRITE-REPLACE WARNING RESPONSE to the MME.

If the Broadcast Completed Area List IE is not included in WRITE-REPLACE WARNING RESPONSE, the MME shall consider that the broadcast is unsuccessful in all the cells within the eNB.


- 206 - © Ericsson 2009 LZT 123 8958 R1A

ENODE B DIRECT INFORMATION TRANSFER The purpose of the eNB Direct Information Transfer procedure is to transfer RAN information from the eNB to the MME in unacknowledged mode. The MME does not interpret the transferred RAN information.

This procedure uses non-UE associated signaling.

MMEMME

eNB DIRECT INFORMATION TRANSFER

eNBeNB MMEMME

eNB DIRECT INFORMATION TRANSFER

eNBeNB

Figure 7-39 eNB Direct Information Transfer

The procedure is initiated with an ENB DIRECT INFORMATION TRANSFER message sent from the eNB to the MME.

The RIM Transfer IE shall contain RIM Routing Address IE that identifies the final RAN destination node where the RIM information needs to be transferred by the core network.


LZT 123 8958 R1A © Ericsson 2009 - 207 -

MME DIRECT INFORMATION TRANSFER The procedure is initiated with a DIRECT INFORMATION TRANSFER message sent from the MME to the eNB.

MMEMME

MME DIRECT INFORMATION TRANSFER

eNBeNB MMEMME

MME DIRECT INFORMATION TRANSFER

eNBeNB

Figure 7-40 MME Direct Information Transfer


- 208 - © Ericsson 2009 LZT 123 8958 R1A

ENODE B CONFIGURATION TRANSFER The purpose of the eNB Configuration Transfer procedure is to transfer RAN configuration information from the eNB to the MME in unacknowledged mode. The MME does not interpret the transferred RAN configuration information.

MMEMME

eNB CONFIGURATION TRANSFER

eNBeNB MMEMME

eNB CONFIGURATION TRANSFER

eNBeNB

Figure 7-41 eNB Configuration Transfer

The procedure is initiated with an ENB CONFIGURATION TRANSFER message sent from the eNB to the MME.

If the MME receives the SON Configuration Transfer IE it shall transparently transfer the SON Configuration Transfer IE towards the eNB indicated in the Target eNB-ID IE which is included in the SON Configuration Transfer IE.


LZT 123 8958 R1A © Ericsson 2009 - 209 -

MME CONFIGURATION TRANSFER

MMEMME


eNBeNB MMEMME


eNBeNB

Figure 7-42 MME Configuration Transfer

The procedure is initiated with an MME CONFIGURATION TRANSFER message sent from the MME to the eNB.

If the eNB receives the SON Information IE containing the SON Information Request IE set to "X2 TNL Configuration Info", it may transfer back the requested information towards the eNB indicated in the Source eNB-ID IE of the SON Configuration Transfer IE by initiating the eNB Configuration Transfer procedure.

If the eNB receives the SON Information IE containing the SON Information Reply IE containing the X2 transport layer addresses as an answer to a former request, it may use it to initiate the X2 TNL establishment.


- 210 - © Ericsson 2009 LZT 123 8958 R1A

Intentionally Blank


LZT 123 8958 R1A © Ericsson 2009 - 211 -

8 X2 Application Protocol – X2 AP

OBJECTIVES

After this chapter the participants will be able to:1. Explain the X2 interface and the X2 Application Protocol

(X2AP) structure.

2. Explain the main functions and procedures of X2AP.

After this chapter the participants will be able to:1. Explain the X2 interface and the X2 Application Protocol

(X2AP) structure.

2. Explain the main functions and procedures of X2AP.

Figure 8-1 Objectives of Chapter 8


- 212 - © Ericsson 2009 LZT 123 8958 R1A

Intentionally Blank


LZT 123 8958 R1A © Ericsson 2009 - 213 -

X2 INTERFACE

The X2 interface specifications shall facilitate the following:

inter-connection of eNBs supplied by different manufacturers;support of continuation between eNBs of the E-UTRAN services offered via the S1 interface;separation of X2 interface Radio Network functionality and Transport Network functionality to facilitate introduction of future technology

Figure 8-2 X2 Interface

The general principles for the specification of the X2 interface are as follows: • the X2 interface is an open interface;

• the X2 interface supports the exchange of signaling information between two eNBs,

• in addition the interface supports the forwarding of PDUs to the respective tunnel endpoints;

From a logical standpoint, the X2 is a point-to-point interface between two eNBs within the E-UTRAN. A point-to-point logical interface is feasible even in the absence of a physical direct connection between the two eNBs.

User Plane/IP

X2AP

User Plane/IP

X2AP

Figure 8-3 Connection between two eNBs


- 214 - © Ericsson 2009 LZT 123 8958 R1A

X2 PROTOCOL MODEL

There is a clear separation between the Radio Network Layer and the Transport Layer. Therefore, the radio network signaling and X2 data streams are separated from the data transport resource and traffic handling.

X2-AP


GTP-U

UDP

IP

Data link layer

Physical layer

User PlanePDUs

SCTP

IP

Data link layer

Physical layer

RadioNetworkLayer




X2-AP


GTP-U

UDP

IP

Data link layer

Physical layer

GTP-U

UDP

IP

Data link layer

Physical layer

User PlanePDUs

SCTP

IP

Data link layer

Physical layer

SCTP

IP

Data link layer

Physical layer

RadioNetworkLayer




Figure 8-4 X2 Protocol Model

Radio Network Layer, defines the procedures related to the interaction between eNBs. It consists of a Radio Network Control Plane and a Radio Network User Plane.

Transport Network Layer provides services for user plane and signaling transport.


LZT 123 8958 R1A © Ericsson 2009 - 215 -

X2 USER PLANE

The transport layer for data streams over X2 is an IP based transport. The following figure shows the transport protocol stacks over X2.

eNodeB1 eNodeB2

GTP-U

UDP

GTP-U

UDP

X2

IP

L2

L1

IP

L2

L1

eNodeB1 eNodeB2

GTP-U

UDP

GTP-U

UDP

X2

IP

L2

L1

IP

L2

L1

Figure 8-5 X2 User Plane Protocol Stack

The GTP-U protocol over UDP over IP is supported as the transport for data streams on the X2 interface.

There may be zero or one UL data stream and zero or one DL data stream per E-RAB at the X2 interface.

- The DL data stream is used for DL data forwarding from the source eNB to the target eNB.

- The UL data stream is used for UL data forwarding from the source eNB to the target eNB.

Each data stream is carried on a dedicated transport bearer.

The identity of a transport bearer signaled in the RNL control plane consists of the IP address and the TEID of the corresponding GTP tunnel, allocated by the target eNB.

The eNBs over the X2 interface supports fragmentation and assembly of GTP packets at the IP layer.


- 216 - © Ericsson 2009 LZT 123 8958 R1A

There may be one or several IP addresses in the both eNBs. The packet processing function in the source eNB is responsible for sending downstream packets of a given E-RAB to the target eNB IP address (received in X2AP) associated to the DL transport bearer of that particular E-RAB. The packet processing function in the source eNB shall send upstream packets of a given E-RAB to the target eNB IP address (received in X2AP) associated to the UL transport bearer of that particular E-RAB.

The Transport Layer Address signaled in X2AP messages is a bit string of

a) 32 bits in case of IPv4 address according to; and

b) 128 bits in case of IPv6 address according to.

X2 CONTROL PLANE

The protocol responsible for providing signaling information across the X2 interface is called the X2 Application Protocol (X2AP). The X2AP is terminated by the two eNBs inter-connected via the X2 interface X2AP Procedure Modules.

eNodeB1 eNodeB2

X2AP

SCTP

X2AP

SCTP

X2

IP

L2

L1

IP

L2

L1

eNodeB1 eNodeB2

X2AP

SCTP

X2AP

SCTP

X2

IP

L2

L1

IP

L2

L1

Figure 8-6 X2 Control Plane Protocol Stack


LZT 123 8958 R1A © Ericsson 2009 - 217 -

X2 signaling bearer provides the following functions:

- Provision of reliable transfer of X2-AP message over X2 interface.

- Provision of networking and routing function

- Provision of redundancy in the signaling network

- Support for flow control and congestion control

Transport Layer

Stream Control Transmission Protocol (SCTP) is used for X2 signaling bearer.

SCTP is developed by the Sigtran working group of the IETF for the purpose of transporting various signaling protocols over IP network.

There shall be only one SCTP association established between one eNB pair. An eNB is using Destination Port Number value as assigned by IANA and this value shall also be used in Source Port Number by all eNBs within a network.

NOTE: A multi-homed eNB implementation provides the correspondent eNB with the set of IP addresses supported during SCTP association establishment unless the correspondent eNB already has this information e.g. through IP address management.

An arbitrary eNB is able to initiate the INIT procedure towards another eNB for establishing the SCTP association.

Within the SCTP association established between one eNB pair;

- A single pair of stream identifiers is reserved for the sole use of X2AP elementary procedures that utilize non UE-associated signaling.

- At least one pair of stream identifiers is reserved for the sole use of X2AP elementary procedures that utilize UE-associated signaling. However a few pairs (i.e. more than one) can be reserved.

- A single UE-associated signaling is using one SCTP stream and the stream is not changed during the communication of the UE-associated signaling.


- 218 - © Ericsson 2009 LZT 123 8958 R1A

Transport network redundancy may be achieved by SCTP multi-homing between two end-points, of which one or both is assigned with multiple IP addresses. SCTP end-points shall support a multi-homed remote SCTP end-point. For SCTP endpoint redundancy an INIT may be sent from either of the eNBs, at any time for an already established SCTP association.

The SCTP congestion control may, using an implementation specific mechanism, initiate higher layer protocols to reduce the signaling traffic at the source and prioritize certain messages.

IP Layer

The eNB shall support IPv6 and/or IPv4.

The IP layer of X2 only supports point-to-point transmission for delivering X2-AP message.

The eNB shall support the Diffserv Code Point marking.

Data Link Layer

The support of any suitable Data Link Layer protocol, e.g. PPP, Ethernet, etc., shall not be prevented.


LZT 123 8958 R1A © Ericsson 2009 - 219 -

FUNCTIONS OF X2 AP

Mobility ManagementLoad ManagementReporting of General Error SituationsResetting the X2Setting up the X2eNodeB Configuration Update

Figure 8-7. X2 AP Functions

INTRA LTE-ACCESS-SYSTEM MOBILITY SUPPORT FOR ECM-CONNECTED UE

This function allows the eNB to handover the control of a certain UE to another eNB.

Context transfer from source eNB to target eNB

This function allows transferring information required to maintain the E-UTRAN services for an UE in ECM-CONNECTED from source to target eNB.

Control of user plane transport bearers between source eNB and target eNB

This function allows establishing and releasing transport bearers between source and target eNB to allow for data forwarding. At most one user plane transport bearer per E-RAB allocated to the UE may be established for relaying DL data received from the EPC from the source eNB to the target eNB. At most one user plane transport bearer per E-RAB allocated to the UE may be established for relaying the UL data received from the UE from the source eNB to the target eNB.

Handover cancellation

This function allows informing an already prepared target eNB that a prepared handover will not take place. It allows releasing the resources allocated during a preparation.


- 220 - © Ericsson 2009 LZT 123 8958 R1A

UE context release in source eNB

This function allows the target eNB to trigger the release of the resources allocated to the UE in the source eNB.

LOAD MANAGEMENT

This function allows exchanging overload and traffic load information between eNBs, such that the eNBs can control the traffic load appropriately. This information may be spontaneously sent to selected neighbour eNBs, or reported as configured by a neighbour eNB.

INTER-CELL INTERFERENCE COORDINATION

This function allows keeping inter-cell interference under control. For this neighbouring eNBs exchange appropriate information allowing that eNBs make radio resource assignments such that interference is mitigated.

Uplink interference load management

This function allows indicating an uplink interference overload and resource blocks especially sensitive to inter-cell interference between neighbouring eNBs, such that neighbour eNBs can co-ordinate with each other such that the mutual interference caused by their uplink radio resource allocations is mitigated.

Downlink interference avoidance

This function allows an eNB to inform its neighbour eNBs about downlink power restrictions in its own cells, per resource block for interference aware scheduling by the neighbour eNBs.

GENERAL X2 MANAGEMENT AND ERROR HANDLING FUNCTIONS

These functions allow for managing of signaling associations between eNBs, surveying X2 interface and recovering from errors.

Error indication

This function allows the reporting of general error situations on application level.


LZT 123 8958 R1A © Ericsson 2009 - 221 -

Reset

This function allows an eNB1 to inform another eNB2 that it has recovered from an abnormal failure and that all the contexts related to eNB1 and stored in eNB2 shall be deleted, and the associated resources released.

TRACE FUNCTIONS

Trace recoding sessions on E-UTRAN interfaces for a particular UE is initiated by the EPC. The trace initiation information is also propagated to the Target eNB during handover, attached to certain handover messages on X2.

APPLICATION LEVEL DATA EXCHANGE BETWEEN ENBS

This function allows two eNBs to exchange application level data when an X2 connection is setup, and to update this information at any time.


- 222 - © Ericsson 2009 LZT 123 8958 R1A

X2AP ELEMENTARY PROCEDURES In the following figures, all EPs are divided into Class 1 and Class 2 EPs.

RESET RESPONSERESET REQUESTRESET

RESOURCE STATUS FAILURE

RESOURCE STATUS RESPONSE

RESOURCE STATUS REQUEST

RESOURCE STATUS REPORTING INITIATION





X2 SETUP FAILUREX2 SETUP RESPONSEX2 SETUP REQUESTX2 SETUP


HANDOVER REQUEST ACKNOWLEDGE

HANDOVER REQUESTHANDOVER PREPARATION




RESET RESPONSERESET REQUESTRESET




RESOURCE STATUS REPORTING INITIATION





X2 SETUP FAILUREX2 SETUP RESPONSEX2 SETUP REQUESTX2 SETUP



HANDOVER REQUESTHANDOVER PREPARATION




Figure 8-8 X2 AP Elementary Procedures - Class

ERROR INDICATIONERROR INDICATION

RESOURCE STATUS UPDATERESOURCE STATUS REPORTING

UE CONTEXT RELEASEUE CONTEXT RELEASE

SN STATUS TRANSFERSN STATUS TRANSFER

HANDOVER CANCELHANDOVER CANCEL

LOAD INFORMATIONLOAD INDICATION


ERROR INDICATIONERROR INDICATION

RESOURCE STATUS UPDATERESOURCE STATUS REPORTING

UE CONTEXT RELEASEUE CONTEXT RELEASE

SN STATUS TRANSFERSN STATUS TRANSFER

HANDOVER CANCELHANDOVER CANCEL

LOAD INFORMATIONLOAD INDICATION


Figure 8-9 X2AP Elementary Procedures - Class 2


LZT 123 8958 R1A © Ericsson 2009 - 223 -

BASIC MOBILITY PROCEDURES

HANDOVER PREPARATION

This procedure is used to establish necessary resources in an eNB for an incoming handover.


Target eNBTarget eNB

HANDOVER REQUEST




HANDOVER REQUEST




HANDOVER REQUEST


source eNBsource eNB Target eNBTarget eNB

HANDOVER REQUEST




HANDOVER REQUEST



HANDOVER REQUEST



Figure 8-10 Handover Preparation

Successful Operation

The source eNB initiates the procedure by sending the HANDOVER REQUEST message to the target eNB. When the source eNB sends the HANDOVER REQUEST message, it shall start the timer TRELOCprep.

The allocation of resources according to the values of the Allocation and Retention Priority IE shall follow the principles described for the E-RAB Setup procedure.

If at least one of the requested E-RABs is admitted to the cell indicated by the Target Cell ID IE, the target eNB shall reserve necessary resources, and send the HANDOVER REQUEST ACKNOWLEDGE message back to the source eNB. The target eNB shall include the E-RABs for which resources have been prepared at the target cell in the E-RABs Admitted List IE. The target eNB shall include the E-RABs that have not been admitted in the E-RABs Not Admitted List IE with an appropriate cause value.


- 224 - © Ericsson 2009 LZT 123 8958 R1A

At reception of the HANDOVER REQUEST message the target eNB shall:

- prepare configuration of the AS security relation between UE and target eNB using the information in UE Security Capabilities IE and the AS Security Information IE in the UE Context Information IE.

For each E-RAB for which the source eNB proposes to do forwarding of downlink data, the source eNB shall include the DL Forwarding IE within the E-RABs To be Setup Item IE of the HANDOVER REQUEST message. For each E-RAB that it has decided to admit, the target eNB may include the DL GTP Tunnel Endpoint IE within the E-RABs Admitted Item IE of the HANDOVER REQUEST ACKNOWLEDGE message to indicate that it accepts the proposed forwarding of downlink data for this bearer. This GTP tunnel endpoint may be different from the corresponding GTP TEID IE in the E-RAB To Be Switched in Downlink List IE of the PATH SWITCH REQUEST message depending on implementation choice.

For each bearer in the E-RABs Admitted List IE, the target eNB may include the UL GTP Tunnel Endpoint IE to indicate that it requests data forwarding of uplink packets to be performed for that bearer.

Upon reception of the HANDOVER REQUEST ACKNOWLEDGE message the source eNB shall stop the timer TRELOCprep, start the timer TX2RELOCoverall and terminate the Handover Preparation procedure. The source eNB is then defined to have a Prepared Handover for that X2 UE-associated signalling.

If the Trace Activation IE is included in the HANDOVER REQUEST message then the target eNB shall, if supported initiate the requested trace function.

If the Handover Restriction List IE is

- contained in the HANDOVER REQUEST message, the target eNB shall store the information received in the Handover Restriction List IE in the UE context and the target eNB shall use this information to determine a target cell for the UE during subsequent handover attempts.

- not contained in the HANDOVER REQUEST message, the target eNB shall consider that no roaming, no area and no access restriction applies to the UE.


LZT 123 8958 R1A © Ericsson 2009 - 225 -

If the Location Reporting Information IE is included in the HANDOVER REQUEST message then the eNB should initiate the requested location reporting functionality as defined in.

If the SRVCC Operation Possible IE is included in the HANDOVER REQUEST message, the target eNB shall store the received ‘SRVCC Operation Possible’ in the UE context and use it.

The HANDOVER REQUEST message shall contain the Subscriber Profile ID for RAT/Frequency priority IE, if available.

If the Subscriber Profile ID for RAT/Frequency priority IE is

- contained in the HANDOVER REQUEST message, the target eNB shall store this information and the target eNB should use the information.

Upon reception of UE History Information IE in the HANDOVER REQUEST message, the target eNB shall collect the information defined as mandatory in the UE History Information IE, for as long as the UE stays in one of its cells, and store the collected information to be used for future handover preparations.

Unsuccessful Operation

If the target eNB is not able to accept any of the E-RABs or a failure occurs during the Handover Preparation, the target eNB shall send the HANDOVER PREPARATION FAILURE message to the source eNB. The message shall contain the Cause IE with an appropriate value.

If the target eNB receives a HANDOVER REQUEST message containing RRC Context IE that does not include required information, the target eNB shall send the HANDOVER PREPARATION FAILURE message to the source eNB.

Interactions with Handover Cancel procedure:

If there is no response from the target eNB to the HANDOVER REQUEST message before timer TRELOCprep expires in the source eNB, the source eNB should cancel the Handover Preparation procedure towards the target eNB by initiating the Handover Cancel procedure with the appropriate value for the Cause IE. The source eNB shall ignore any HANDOVER REQUEST ACKNOWLEDGE or HANDOVER PREPARATION FAILURE message received after the initiation of the Handover Cancel procedure and remove any reference and release any resources related to the concerned X2 UE-associated signaling.


- 226 - © Ericsson 2009 LZT 123 8958 R1A

Abnormal Conditions

If the target eNB receives a HANDOVER REQUEST message containing several E-RAB ID IEs (in the E-RABs To Be Setup List IE) set to the same value, the target eNB shall not admit the corresponding E-RABs.

If the target eNB receives a HANDOVER REQUEST message containing a E-RAB Level QoS Parameters IE which contains a QCI IE indicating a GBR bearer, and which does not contain the GBR QoS Information IE, the target eNB shall not admit the corresponding E-RAB.

If the supported algorithms for encryption defined in the Encryption Algorithms IE in the in the UE Security Capabilities IE in the UE Context Information IE, plus the mandated support of EEA0 in all UEs, do not match any algorithms defined in the configured list of allowed encryption algorithms in the eNB, the eNB shall reject the procedure using the HANDOVER PREPARATION FAILURE message.

If the supported algorithms for integrity defined in the Integrity Protection Algorithms IE in the UE Security Capabilities IE in the UE Context Information IE, do not match any algorithms defined in the configured list of allowed integrity protection algorithms in the eNB or if all bits in Integrity Protection Algorithms IE are equal to 0, the eNB shall reject the procedure using the HANDOVER PREPARATION FAILURE message.

SN STATUS TRANSFER

The purpose of the SN 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 to the target eNB during an X2 handover for each respective E-RAB for which PDCP SN and HFN status preservation applies.



LZT 123 8958 R1A © Ericsson 2009 - 227 -


SN STATUS TRANSFER


SN STATUS TRANSFER


Figure 8-11 SN Status Transfer

The source eNB initiates the procedure by stop assigning PDCP SNs to downlink SDUs and stop delivering UL SDUs towards the EPC and sending the SN STATUS TRANSFER message to the target eNB at the time point when it considers the transmitter/receiver status to be frozen.

The E-RABs Subject To Status Transfer List IE included in the SN STATUS TRANSFER message contains the E-RAB ID(s) corresponding to the E-RAB(s) for which PDCP SN and HFN status preservation shall be applied.

If the source eNB includes in the SN STATUS TRANSFER message, the information on the missing and received uplink SDUs in the Receive Status Of UL PDCP SDUs IE for each E-RAB for which the source eNB has accepted the request from the target eNB for uplink forwarding, then the target eNB may use it in a Status Report message sent to the UE over the radio.

For each E-RAB for which the DL COUNT Value IE is received in the SN STATUS TRANSFER message, the target eNB shall use it to mark with the value contained in the PDCP-SN IE of this IE the first downlink packet for which there is no PDCP SN yet assigned.

For each E-RAB for which the UL COUNT Value IE is received in the SN STATUS TRANSFER message, the target eNB shall not deliver any uplink packet which has a PDCP SN lower than the value contained in the PDCP-SN IE of this IE.

If the target eNB receives this message for a UE for which no prepared handover exists at the target eNB, the target eNB shall ignore the message.


- 228 - © Ericsson 2009 LZT 123 8958 R1A

UE CONTEXT RELEASE

The UE Context Release procedure is initiated by the target eNB to signal to indicate the source eNB that radio and control plane resources for the handed over UE context are allowed to be released.



UE CONTEXT RELEASE


UE CONTEXT RELEASE


Figure 8-12 UE Context Release

The UE Context Release procedure is initiated by the target eNB. By sending the UE CONTEXT RELEASE message the target eNB informs the source eNB of Handover success and triggers the release of resources.

Upon reception of the UE CONTEXT RELEASE message, the source eNB may release radio and control plane related resources associated to the UE context. For E-RABs for which data forwarding has been performed, the source eNB should continue forwarding of U-plane data as long as packets are received at the source eNB from the EPC or the source eNB buffer has not been emptied (an implementation dependent mechanism decides that data forwarding can be stopped).

If the UE Context Release procedure is not initiated towards the source eNB from any prepared eNB before the expiry of the timer TX2RELOCoverall, the source eNB shall release all resources associated to the UE context and request the MME to release the UE context.

If the UE returns to source eNB before the reception of the UE CONTEXT RELEASE message or the expiry of the timer TX2RELOCoverall, the source eNB shall stop the TX2RELOCoverall and continue to serve the UE.


LZT 123 8958 R1A © Ericsson 2009 - 229 -

HANDOVER CANCEL

The Handover Cancel procedure is used to enable a source eNB to cancel an ongoing handover preparation or an already prepared handover.



HANDOVER CANCEL


HANDOVER CANCEL


Figure 8-13 Handover Cancel

The source eNB initiates the procedure by sending the HANDOVER CANCEL message to the target eNB. The source eNB shall indicate the reason for cancelling the handover by means of an appropriate cause value.

At the reception of the HANDOVER CANCEL message, the target eNB shall remove any reference to, and release any resources previously reserved to the concerned UE context.

The New eNB UE X2AP ID IE shall be included if it has been obtained from the target eNB.

Should the HANDOVER CANCEL message refer to a context that does not exist, the target eNB shall ignore the message.


- 230 - © Ericsson 2009 LZT 123 8958 R1A

GLOBAL PROCEDURES

LOAD INDICATION

The purpose of the Load Indication procedure is to transfer load and interference co-ordination information between eNBs controlling intra-frequency neighboring cells.


eNB2eNB2

LOAD INFORMATION

eNB1eNB1

eNB2eNB2

ERROR INDICATION

eNB1eNB1

eNB2eNB2

LOAD INFORMATION

eNB1eNB1

eNB2eNB2

ERROR INDICATION

eNB1eNB1

Figure 8-14 Load Indication

An eNB initiates the procedure by sending LOAD INFORMATION message to eNBs controlling intra-frequency neighbouring cells .

If the UL Interference Overload Indication IE is received in the LOAD INFORMATION message, it indicates the interference level experienced by the indicated cell on all resource blocks, per PRB. The receiving eNB may take such information into account when setting its scheduling policy and shall consider the received UL Interference Overload Indication IE value valid until reception of a new LOAD INFORMATION message carrying an update of the same IE.


LZT 123 8958 R1A © Ericsson 2009 - 231 -

If the UL High Interference Indication IE is received in the LOAD INFORMATION message, it indicates, per PRB, the occurrence of high interference sensitivity, as seen from the sending eNB. The receiving eNB should try to avoid scheduling cell edge UEs in its cells for the concerned PRBs. The Target Cell ID IE received within the UL High Interference Information IE group in the LOAD INFORMATION message indicates the cell for which the corresponding UL High Interference Indication is meant. The receiving eNB shall consider the value of the UL High Interference Information IE group valid until reception of a new LOAD INFORMATION message carrying an update.

If the Relative Narrowband Tx Power (RNTP) IE is received in the LOAD INFORMATION message, it indicates, per PRB, whether downlink transmission power is lower than the value indicated by the RNTP Threshold IE. The receiving eNB may take such information into account when setting its scheduling policy and shall consider the received Relative Narrowband Tx Power (RNTP) IE value valid until reception of a new LOAD INFORMATION message carrying an update.

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 like a Reset procedure would do.


eNB2eNB2

X2 SETUP REQUEST

X2 SETUP RESPONSE

eNB1eNB1

eNB2eNB2

X2 SETUP REQUEST

X2 SETUP FAILURE

eNB1eNB1

eNB2eNB2

X2 SETUP REQUEST

X2 SETUP RESPONSE

eNB1eNB1

eNB2eNB2

X2 SETUP REQUEST

X2 SETUP FAILURE

eNB1eNB1

Figure 8-15 X2 Setup


- 232 - © Ericsson 2009 LZT 123 8958 R1A


An eNB initiates the procedure by sending the X2 SETUP REQUEST message to a candidate eNB. The candidate eNB replies with the X2 SETUP RESPONSE message. The initiating eNB transfers a list of served cells and, if available, a list of supported GU Group Ids to the candidate eNB. The candidate eNB replies with a list of its served cells and shall include, if available, a list of supported GU Group Ids in the reply.

The initiating eNB may include the Neighbour Information IE in the X2 SETUP REQUEST message. The candidate eNB may also include the Neighbour Information IE in the X2 SETUP RESPONSE message. The Neighbour Information IE shall only include E-UTRAN cells that are direct neighbours of cells in the reporting eNB.


If the candidate eNB cannot accept the setup it shall respond with an X2 SETUP FAILURE message with appropriate cause value.

If the X2 SETUP FAILURE messages includes the Time To Wait IE the initiating eNB shall wait at least for the indicated time before reinitiating the X2 Setup procedure towards the same eNB.

Abnormal Conditions

If the X2 SETUP REQUEST message is not the first message received for a specific TNL association then this shall be treated as a logical error.

If the initiating eNB1 does not receive either X2 SETUP RESPONSE message or X2 SETUP FAILURE message, the eNB1 may reinitiate the X2 Setup procedure towards the same eNB, provided that the content of the new X2 SETUP REQUEST message is identical to the content of the previously unacknowledged X2 SETUP REQUEST message.


LZT 123 8958 R1A © Ericsson 2009 - 233 -

RESET

The purpose of the Reset procedure is to align the resources in eNB1 and eNB2 in the event of an abnormal failure. The procedure resets the X2 interface. This procedure doesn’t affect the application level configuration data exchanged during the X2 Setup procedure.


eNB2eNB2

RESET REQUEST

RESET RESPONSE

eNB1eNB1 eNB2eNB2

RESET REQUEST

RESET RESPONSE

eNB1eNB1

Figure 8-16 Reset

The procedure is initiated with a RESET REQUEST message sent from the eNB1 to the eNB2. Upon receipt of this message, eNB2 shall abort any other ongoing procedures over X2 between eNB1 and eNB2. The eNB2 shall delete all the context information related to the eNB1, except the application level configuration data exchanged during the X2 Setup or eNB Configuration Update procedures, and release the corresponding resources. After completion of release of the resources, the eNB2 shall respond with a RESET RESPONSE message.

If the RESET REQUEST message is received, any other ongoing procedure (except another Reset procedure) on the same X2 interface shall be aborted.

If Reset procedure is ongoing and the eNB2 receives the RESET REQUEST message from the peer entity on the same X2 interface, the eNB2 shall respond with the RESET RESPONSE message.

If the initiating eNB does not receive RESET RESPONSE message, the eNB1 may reinitiate the Reset procedure towards the same eNB, provided that the content of the new RESET REQUEST message is identical to the content of the previously unacknowledged RESET REQUEST message.


- 234 - © Ericsson 2009 LZT 123 8958 R1A

ENODE B CONFIGURATION UPDATE

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.


eNB2eNB2


ENB CONFIGURATION UPDATEACKNOWLEDGE

eNB1eNB1

eNB2eNB2


ENB CONFIGURATION UPDATEFAILURE

eNB1eNB1

eNB2eNB2



eNB1eNB1 eNB2eNB2



eNB1eNB1

eNB2eNB2



eNB1eNB1 eNB2eNB2



eNB1eNB1

Figure 8-17 eNB Configuration Update


An eNB1 initiates the procedure by sending an ENB CONFIGURATION UPDATE message to a peer eNB2.

Upon reception of an ENB CONFIGURATION UPDATE message, eNB2 shall update the information for eNB1 as follows:

Update of Served Cell Information:

- If Served Cells To Add IE is contained in the ENB CONFIGURATION UPDATE message, eNB2 shall add cell information according to the information in the Served Cell Information IE.

- If Served Cells To Modify IE is contained in the ENB CONFIGURATION UPDATE message, eNB2 shall modify information of cell indicated by Old ECGI IE according to the information in the Served Cell Information IE.

When either served cell information or neighbor information of an existing served cell in eNB1 need to be updated, the whole list of neighboring cells, if any, shall be contained in the Neighbor Information IE.


LZT 123 8958 R1A © Ericsson 2009 - 235 -

The eNB2 shall overwrite the served cell information and the whole list of neighbour cell information for the affected served cell.

- If Served Cells To Delete IE is contained in the ENB CONFIGURATION UPDATE message, eNB2 shall delete information of cell indicated by Old ECGI IE.

Update of GU Group ID List:

- If GU Group Id To Add List IE is contained in the ENB CONFIGURATION UPDATE message, eNB2 shall add the GU Group Id to its GU Group Id List.

- If GU Group Id To Delete List IE is contained in the ENB CONFIGURATION UPDATE message, eNB2 shall remove the GU Group Id from its GU Group Id List.

If Neighbour Information IE is contained in the ENB CONFIGURATION UPDATE message, eNB2 may use this information to update its neighbour cell relations, or use it for other functions, like PCI selection. The Neighbour Information IE shall only include E-UTRAN cells that are direct neighbours of cells in the reporting eNB.

After successful update of requested information, eNB2 shall reply with the ENB CONFIGURATION UPDATE ACKNOWLEDGE message to inform the initiating eNB1 that the requested update of application data was performed successfully. In case the peer eNB2 receives an ENB CONFIGURATION UPDATE without any IE except for Message Type IE it shall reply with ENB CONFIGURATION UPDATE ACKNOWLEDGE message without performing any updates to the existing configuration.

The eNB1 may initiate a further eNB Configuration Update procedure only after a previous eNB Configuration Update procedure has been completed.


- 236 - © Ericsson 2009 LZT 123 8958 R1A


If the eNB2 can not accept the update it shall respond with an ENB CONFIGURATION UPDATE FAILURE message and appropriate cause value.

If the ENB CONFIGURATION UPDATE FAILURE message includes the Time To Wait IE the eNB1 shall wait at least for the indicated time before reinitiating the eNB Configuration Update procedure towards the same eNB2. Both nodes shall continue to operate the X2 with the existing configuration data.

Abnormal Conditions

If the eNB1 after initiating eNB Configuration Update procedure receives neither ENB CONFIGURATION UPDATE ACKNOWLEDGE message nor ENB CONFIGURATION UPDATE FAILURE message, the eNB1 may reinitiate the eNB Configuration Update procedure towards the same eNB2, provided that the content of the new ENB CONFIGURATION UPDATE message is identical to the content of the previously unacknowledged ENB CONFIGURATION UPDATE message.


LZT 123 8958 R1A © Ericsson 2009 - 237 -

RESOURCE STATUS REPORTING

INITIATION

This procedure is used by an eNB to request the reporting of load measurements to another eNB.


eNB2eNB2



eNB1eNB1

eNB2eNB2



eNB1eNB1

eNB2eNB2



eNB1eNB1

eNB2eNB2



eNB1eNB1 eNB2eNB2



eNB1eNB1

Figure 8-18 nitiation


The procedure is initiated with a RESOURCE STATUS REQUEST message sent from eNB1 to eNB2. Upon receipt, eNB2 shall initiate the requested measurement according to the parameters given in the request in case the Registration Request IE set to "start" and shall terminate the reporting in case the Registration Request IE is set to “stop".

If the Registration Request IE is set to "start" then the Report Characteristics IE shall be included in RESOURCE STATUS REQUEST message.

The Report Characteristics IE indicates the type of measurements eNB2 shall perform.

For each request cell, the eNB2 shall include in the RESOURCE STATUS UPDATE message;

- the Radio Resource Status IE, if the first bit, “PRB Periodic” of the Report Characteristics IE included in the RESOURCE STATUS REQUEST message is set to 1,


- 238 - © Ericsson 2009 LZT 123 8958 R1A

- the S1 TNL Load Indicator IE, if the second bit, “TNL Load Ind Periodic” of the Report Characteristics IE included in the RESOURCE STATUS REQUEST message is set to 1,

- the Hardware Load Indicator IE, if the third bit, “HW Load Ind Periodic” of the Report Characteristics IE included in the RESOURCE STATUS REQUEST message is set to 1,

If the Reporting Periodicity IE is included in the RESOURCE STATUS REQUEST message, eNB2 shall use its value as the time interval between two subsequent measurement reports.

If eNB2 is capable to provide resource status information, it shall initiate the measurements as requested by eNB1, and respond with the RESOURCE STATUS RESPONSE message.


If the requested measurement cannot be initiated, eNB2 shall send a RESOURCE STATUS FAILURE message. The Cause IE shall be set to an appropriate value e.g. “Measurement Temporarily not Available”.

Abnormal Conditions

If the initiating eNB1 does not receive either RESOURCE STATUS RESPONSE message or RESOURCE STATUS FAILURE message, the eNB1 may reinitiate the Resource Status Reporting Initiation procedure towards the same eNB, provided that the content of the new RESOURCE STATUS REQUEST message is identical to the content of the previously unacknowledged RESOURCE STATUS REQUEST message.

If the Report Characteristics IE bitmap is set to 0 (all bits are set to 0) in the RESOURCE STATUS REQUEST message then eNB2 shall initiate a RESOURCE STATUS FAILURE message, the cause shall be set to appropriate value e.g. “ReportCharacteristicsEmpty”.

If Report Periodicity IE value is not specified when either the first and/or the second and or the third bit of the Report Characteristics IE is set to 1 then eNB2 shall initiate a RESOURCE STATUS FAILURE message, the cause shall be set to appropriate value e.g. “NoReportPeriodicity”.


LZT 123 8958 R1A © Ericsson 2009 - 239 -

If the eNB2 received a RESOURCE STATUS REQUEST message which includes the Registration Request IE set to "start" and a eNB1Measurement ID IE corresponding to an existing on-going load measurement reporting, then eNB2 shall initiate a RESOURCE STATUS FAILURE message, the cause shall be set to appropriate value e.g. “ExistingMeasurementID”.

If the Registration Request IE is set to "stop" and the RESOURCE STATUS REQUEST message does not contain both eNB1 Measurement ID IE and eNB2 Measurement ID IE, eNB2 shall consider the procedure as failed and respond with the RESOURCE STATUS FAILURE message, the cause shall be set to appropriate value e.g. “Unknown eNB Measurement ID.

RESOURCE STATUS REPORTING

This procedure is initiated by eNB2 to report the result of measurements requested by eNB1 using the Resource Status Reporting Initiation.


eNB2eNB2

RESOURCE STATUS UPDATE

eNB1eNB1 eNB2eNB2

RESOURCE STATUS UPDATE

eNB1eNB1

Figure 8-19 Resource Status Reporting

The eNB2 shall report the results of the measurements in RESOURCE STATUS UPDATE message for each requested cell.


- 240 - © Ericsson 2009 LZT 123 8958 R1A

Intentionally Blank


LZT 123 8958 R1A © Ericsson 2009 - 241 -

9 Auto Configuration of the eNodeB

OBJECTIVES

After this chapter the participants will be able to:1. Understand Auto Configuration of the Base Stations including

Cell Configuration and Common Channel setup

After this chapter the participants will be able to:1. Understand Auto Configuration of the Base Stations including

Cell Configuration and Common Channel setup

Figure 9-1 Objectives of Chapter 9.


- 242 - © Ericsson 2009 LZT 123 8958 R1A

Intentionally Blank


LZT 123 8958 R1A © Ericsson 2009 - 243 -

AUTOCONFIGURATION OF THE E NODEB

MME OSS-RC

8. MME Connected Notification

2. RBS local configuration info

5. Cell ConfigurationCell name, Cell ID, TAI, [MME FQDN or IP Address]

7. S1 Setup

Conditional:6. DNS Look-up

(retrieving MME IP addresses)

Site engineer

1. Cell configuration details

4. Connect to master server

3. FetchBasic Configuration Data

9. Activate (unlock) cells, start broadcast system

information

For each MME to be connected

Operator

Figure 9-2 Sequence of events: Autoconfiguration

1 The operator (or a Radio Network planning tool) prepares the OSS-RC with IP network, OSS-RC file-server address, equipment, and cell configuration details. The cell configuration is entered into the OSS-RC. If used, the DNS and DHCP are configured with RBS unique parameters. If a configuration file shall be used by the site engineer (in step 3), the file is prepared by the OSS-RC.

2 The site engineer loads RBS name and security data (used when fetching configuration data) into the eNodeB. Also O&M IP network configuration and the OSS-RC file-server address may be loaded, if it shall not be fetched from DHCP.


- 244 - © Ericsson 2009 LZT 123 8958 R1A

3 The eNodeB fetches RBS configuration from the OSS-RC file server.

4 The RBS connects to the OSS-RC master server, indicating that it is ready to be configured (for its role in the network) by the OSS-RC.

5 The OSS-RC provides the eNodeB with configuration data (as received in step 1). The configuration data includes the mapping between cells and TAs, and optionally the MME IP Addresses or FQDNs.

6 If no MME IP Addresses or FQDNs is received from the OSS-RC the eNodeB performs a translation between TAI and one IP address for each MME in the pool controlling the TA using the DNS Lookup procedure. This translation is performed for each TA supported by the eNodeB. If MME FQDNs are received from the OSS-RC, these are used to retrieve the MME IP addresses using the DNS look-up procedure, This look-up is performed for each MME FQDN received.

Steps 7 to 8 are repeated for each MME to be connected:

7 The eNodeB connects to the MME using the S1 Setup procedure.

8 The eNodeB notifies the OSS-RC that the MME is connected. The notification contains the TAI and PLMNs supported by each MME.

9 The OSS-RC activates (unlocks) the cells, enabling broadcast of system information..


LZT 123 8958 R1A © Ericsson 2009 - 245 -

10 Mobility

OBJECTIVES

After this chapter the participants will be able to:1. Explain the Intra LTE Mobility while in connected mode

2. Explain Interworking with 2G/3G



- 246 - © Ericsson 2009 LZT 123 8958 R1A

Intentionally Blank


LZT 123 8958 R1A © Ericsson 2009 - 247 -

MOBILITY The Intra-E-UTRAN-Access Mobility Support for UEs in ECM-CONNECTED handles all necessary steps for relocation/handover procedures, like processes that precede the final HO decision on the source network side (control and evaluation of UE and eNB measurements taking into account certain UE specific area restrictions), preparation of resources on the target network side, commanding the UE to the new radio resources and finally releasing resources on the (old) source network side. It contains mechanisms to transfer context data between evolved nodes, and to update node relations on C-plane and U-plane.

In E-UTRAN RRC_CONNECTED state, network-controlled UE-assisted handovers are performed and various DRX cycles are supported:

The UE makes measurements of attributes of the serving and neighbor cells to enable the process:

1 There is no need to indicate neighboring cell to enable the UE to search and measure a cell i.e. E-UTRAN relies on the UE to detect the neighboring cells;

2 For the search and measurement of inter-frequency neighboring cells, carrier frequencies are indicated;

3 Network signals reporting criteria for event-triggered and periodical reporting;

4 A neighbor cell list (NCL) can be provided by the serving cell to handle specific cases for intra- and inter-frequency neighboring cells. This NCL contain cell specific cell reselection parameters (e.g. cell specific offset) for specific neighboring cells;

5 Black lists can be provided to prevent the UE from measuring specific neighboring cells.


- 248 - © Ericsson 2009 LZT 123 8958 R1A

X2 HANDOVER

LTE Node BLTE Node B

LTE NodeBLTE NodeB

LTE Node BLTE Node B

X2 X2

Simplified mobility scheme to handled the most common scenarioHandover is performed in E-UTRAN without the knowledge of EPCForwarding of user data on X2 interface (Selective Forwarding)After handover is completed, EPC is informed and the route is optimized

SGWSGWMMEMME

Figure 10-2 X2 based Handover

The intra E-UTRAN HO in RRC_CONNECTED state is UE assisted NW controlled HO, with HO preparation signaling in E-UTRAN. HO command comes from the target eNB and is transparently forwarded to the UE by the source eNB. In order to prepare the HO, the source eNB passes all necessary information to the target eNB (e.g. E-RAB attributes and RRC context )

At the handover both the source eNB and UE keep some context details (e.g. C-RNTI) that enables the return of the UE in case of HO failure;

UE accesses the target cell via RACH following a contention-free procedure (CFRA see MAC Chapter) using a dedicated RACH preamble or following a contention-based (CBRA) procedure if dedicated RACH preambles are not available. The UE uses the dedicated preamble until the handover procedure is finished (successfully or unsuccessfully).

If the RACH procedure towards the target cell is not successful within a certain time, the UE initiates radio link failure recovery using the best cell;

Note: No ROHC context is transferred at handover.


LZT 123 8958 R1A © Ericsson 2009 - 249 -

Let’s study X2 Handover with some details now.

MME

RRC CONNECTED

S-GW

Source eNB Target eNB1. RRC CONNECTION RECONFIGURATION

(Bearer Setup,Measurement conf))

2. RRC Measurement Report (Event A3)

3. HO Decision

4. X2 HANDOVER REQUEST

5.Admission Control

6. X2 HANDOVER REQUESTACKNOWLEDGE

10. RRC CONNECTION RECONFIGURATION (Handover Command,Measurement conf)

7. X2 SN STATUS TRANSFER 8. Start Data

forwarding

9. Buffer Forwarded

Data

11 MAC: CFRA Random Access Preamble

12. MAC Random Access Response (UL allocation + TA)

13. RRC CONNECTION RECONFIGURATION COMPLETE(Handover Complete)

15. S1 PATH SWITCH REQUEST 16. S5 USER PLANE

UPDATE REQ 17. S5 USER PLANE UPDATE RSPONSE

18. S1 PATH SWITCH RESPONSE

20. X2 UE CONTEXT RELEASE RRC CONNECTED

14.Data Transfer in Target

21. Forward if any Data in transition

and release

T304

TRELOCprep

RegenerateSecurity Keys

Figure 10-3 X2 Handover Sequence

The Figure 10-3 illustrates X2 handover sequence. The HO procedure is performed without EPC involvement, i.e. preparation messages are directly exchanged between the eNBs. The release of the resources at the source side during the HO completion phase is triggered by the eNB. The figure below depicts the basic handover scenario where neither MME nor Serving Gateway changes

The UE context within the source eNB contains information regarding roaming restrictions which where provided either at connection establishment or at the last TA update.

1 The source eNB configures the UE measurement procedures according to the area restriction information. Measurements provided by the source eNB may assist the function controlling the UE's connection mobility. Measurement Command message is included in RRC Connection Reconfiguration message


- 250 - © Ericsson 2009 LZT 123 8958 R1A

2 When a certain criteria is fulfilled (in our example event A3) UE will inform the source eNB by sending Measurement Report

3 Source eNB makes decision based on Measurement Report and RRM information to hand off UE.

4 The source eNB issues a X2: Handover Request message to the target eNB passing necessary information to prepare the HO, Figure 10-4 at the target side (UE X2 signaling context reference at source eNB, UE S1 EPC signaling context reference, target cell ID, KeNB*, RRC context including the C-RNTI of the UE in the source eNB, AS-configuration, E-RAB context and physical layer ID of the source cell + MAC for possible RLF recovery). UE X2 / UE S1 signaling references enable the target eNB to address the source eNB and the EPC. The E-RAB context includes necessary RNL and TNL addressing information, and QoS profiles of the E-RABs.

indicates that both the UE and the MME are SRVCC-capableOSRVCC Operation Possible

E-UTRAN Trace ID; Depth; Ip to reportOTrace Activation

Last Visited Cell ListMUE History Information

Event and Report AreaO>Location Reporting Information

area roaming or access restrictions for handoverO>Handover Restriction List

OCTET STRING; Includes the RRC Handover Preparation Information messageM> RRC Context

Transport Layer Address and GTP TEID;SGW endpoint of the S1 transport bearer. For delivery of UL PDUs

M>>> UL GTP Tunnel Endpoint

indicates that the E-RAB is proposed for forwarding of downlink packetsO>>> DL Forwarding

QCI;ARP;GBR QoS (Max BitrateUL/DL;Guaranteed itrate UL/DL)M>>> E-RAB Level QoS Parameters

This IE uniquely identifies an E-RAB for a UEM>>> E-RAB ID

<1..maxnoof Bearers> maxnoofBearers = 256>>E-RABs To Be Setup Item

>E-RABs To Be Setup List

(1..256)O> Subscriber Profile ID for RAT/Frequency priority

UE Aggregate Maximum Bit Rate Uplink/DlM> UE Aggregate Maximum Bit Rate

KeNB; NextHop Chaining CountM>AS Security Information

Encryption and Integrity AlgorithmsM> UE Security Capabilities

INTEGER (0..232 -1) MME UE S1AP ID allocated at the MMEM> MME UE S1AP ID

UE Context Information

Globally unique MME identityMGUMMEI

ECGI; E-UTRAN Cell Global Identifier (ECGI) is used to globally identify a cell MTarget Cell ID

e.g Handover Desirable for Radio ReasonsMCause

eNB UE X2AP ID Integer (0..4095) Allocated at the source eNBMOld eNB UE X2AP ID

Handover RequestMMessage Type

IE type and referencePIE/Group Name

indicates that both the UE and the MME are SRVCC-capableOSRVCC Operation Possible

E-UTRAN Trace ID; Depth; Ip to reportOTrace Activation

Last Visited Cell ListMUE History Information

Event and Report AreaO>Location Reporting Information

area roaming or access restrictions for handoverO>Handover Restriction List

OCTET STRING; Includes the RRC Handover Preparation Information messageM> RRC Context

Transport Layer Address and GTP TEID;SGW endpoint of the S1 transport bearer. For delivery of UL PDUs

M>>> UL GTP Tunnel Endpoint

indicates that the E-RAB is proposed for forwarding of downlink packetsO>>> DL Forwarding

QCI;ARP;GBR QoS (Max BitrateUL/DL;Guaranteed itrate UL/DL)M>>> E-RAB Level QoS Parameters

This IE uniquely identifies an E-RAB for a UEM>>> E-RAB ID

<1..maxnoof Bearers> maxnoofBearers = 256>>E-RABs To Be Setup Item

>E-RABs To Be Setup List

(1..256)O> Subscriber Profile ID for RAT/Frequency priority

UE Aggregate Maximum Bit Rate Uplink/DlM> UE Aggregate Maximum Bit Rate

KeNB; NextHop Chaining CountM>AS Security Information

Encryption and Integrity AlgorithmsM> UE Security Capabilities

INTEGER (0..232 -1) MME UE S1AP ID allocated at the MMEM> MME UE S1AP ID

UE Context Information

Globally unique MME identityMGUMMEI

ECGI; E-UTRAN Cell Global Identifier (ECGI) is used to globally identify a cell MTarget Cell ID

e.g Handover Desirable for Radio ReasonsMCause

eNB UE X2AP ID Integer (0..4095) Allocated at the source eNBMOld eNB UE X2AP ID

Handover RequestMMessage Type


Figure 10-4 X2 Handover Request message


LZT 123 8958 R1A © Ericsson 2009 - 251 -

5 Admission Control is performed by the target eNB dependent on the received E-RAB QoS information to increase the likelihood of a successful HO, if the resources can be granted by target eNB. The target eNB configures the required resources according to the received E-RAB QoS information and reserves a C-RNTI and optionally a RACH preamble. The AS-configuration to be used in the target cell can either be specified independently (i.e. an "establishment") or as a delta compared to the AS-configuration used in the source cell (i.e. a "reconfiguration").

6 Target eNB prepares HO with L1/L2 and sends the X2: Handover Request Acknowledge to the source eNB. The Handover Request Acknowledge message includes a transparent container to be sent to the UE as an RRC message to perform the handover. The container includes a new C-RNTI, target eNB security algorithm identifiers for the selected security algorithms, may include a dedicated RACH preamble

OCTET STRING; Includes the RRC E-UTRA Handover Command message

MTarget eNB To Source eNB Transparent Container

E-RAB ListOE-RABs Not Admitted List

GTP Tunnel Endpoint; Identifies the X2 transport bearer. used for forwarding of DL PDUs

O>> DL GTP Tunnel Endpoint

GTP Tunnel Endpoint; Identifies the X2 transport bearer used for forwarding of UL PDUs

O>> UL GTP Tunnel Endpoint

M>> E-RAB ID

1 to <maxnoofBearers>

> E-RABs Admitted Item

1E-RABs Admitted List

eNB UE X2AP ID Allocated at the target eNBMNew eNB UE X2AP ID

eNB UE X2AP ID; Allocated at the source eNBMOld eNB UE X2AP ID

Handover Request AcknowledgeMMessage Type

IE type and referenceRangePIE/Group Name

OCTET STRING; Includes the RRC E-UTRA Handover Command message

MTarget eNB To Source eNB Transparent Container

E-RAB ListOE-RABs Not Admitted List

GTP Tunnel Endpoint; Identifies the X2 transport bearer. used for forwarding of DL PDUs

O>> DL GTP Tunnel Endpoint

GTP Tunnel Endpoint; Identifies the X2 transport bearer used for forwarding of UL PDUs

O>> UL GTP Tunnel Endpoint

M>> E-RAB ID

1 to <maxnoofBearers>

> E-RABs Admitted Item

1E-RABs Admitted List

eNB UE X2AP ID Allocated at the target eNBMNew eNB UE X2AP ID

eNB UE X2AP ID; Allocated at the source eNBMOld eNB UE X2AP ID

Handover Request AcknowledgeMMessage Type

IE type and referenceRangePIE/Group Name

RRC Connection ReconfigurationRRC Connection Reconfiguration Figure 10-5 X2: Handover Request Acknowledge message


- 252 - © Ericsson 2009 LZT 123 8958 R1A

7 The source eNB sends the SN STATUS TRANSFER message to the target eNB to convey the uplink PDCP SN receiver status and the downlink PDCP SN transmitter status of E-RABs for which PDCP status preservation applies (i.e. for RLC AM). The uplink PDCP SN receiver status includes at least the PDCP SN of the first missing UL SDU and may include a bit map of the receive status of the out of sequence UL SDUs that the UE needs to retransmit in the target cell, if there are any such SDUs. The downlink PDCP SN transmitter status indicates the next PDCP SN that the target eNB shall assign to new SDUs, not having a PDCP SN yet. The source eNB may omit sending this message if none of the E-RABs of the UE shall be treated with PDCP status preservation.

8 As soon as the source eNB receives the HANDOVER REQUEST ACKNOWLEDGE, or as soon as the transmission of the handover command is initiated in the downlink, data forwarding is initiated if necessary.

9 The target eNB has to buffer received DL data until the UE access the new cell.

10 The source eNB sends the received RRC message to perform the handover, i.e RRCConnectionReconfiguration that was included in X2: message Handover Request Acknowledge including the mobilityControlInformation, to the UE. The source eNB performs the necessary integrity protection and ciphering of the message. The UE receives the RRCConnectionReconfiguration message with necessary parameters. The UE does not need to delay the handover execution for delivering the HARQ/ARQ responses to source eNB. After receiving the RRCConnectionReconfiguration message including the mobilityControlInformation ,


LZT 123 8958 R1A © Ericsson 2009 - 253 -

RRCConnectionReconfiguration messageRRCConnectionReconfiguration-r8-IEs {

measConfigmobilityControlInforadioResourceConfigDedicatedsecurityConfigHO

MobilityControlInfo ::=targetPhysCellIdcarrierFreq OcarrierBandwidth OadditionalSpectrumEmission Ot304 ENUMERATED { ms50, ms100, ms150, ms200, ms500, ms1000,

ms2000, spare1},newUE-Identity C-RNTI,radioResourceConfigCommonrach-ConfigDedicated ra-PreambleIndex INTEGER (0..63),

ra-PRACH-MaskIndex INTEGER (0..15)

CarrierBandwidthEUTRA ::= SEQUENCE {dl-Bandwidth ENUMERATED { n6, n15, n25, n50, n75, n100}ul-Bandwidth ENUMERATED {n6, n15, n25, n50, n75, n100}

CarrierFreqEUTRA ::=dl-CarrierFrequl-CarrierFreq O

SecurityConfigHO ::=handoverType CHOICE {intraLTE {

securityAlgorithmConfig OkeyChangeIndicator BOOLEAN,nextHopChainingCount

},interRAT {

securityAlgorithmConfignas-SecurityParamToEUTRA

5 MHz

Figure 10-6 RRC Container, extract

11 UE performs synchronization to target eNB and accesses the target cell via RACH, following a contention-free procedure if a dedicated RACH preamble was indicated in the mobilityControlInformation, or following a contention-based procedure if no dedicated preamble was indicated. UE derives target eNB specific keys and configures the selected security algorithms to be used in the target cell.

12 The target eNB responds with UL allocation and timing advance.

13 When the UE has successfully accessed the target cell, the UE sends the RRCConnectionReconfigurationComplete message (C-RNTI) to confirm the handover, along with an uplink Buffer Status Report, whenever possible, to the target eNB to indicate that the handover procedure is completed for the UE. The target eNB verifies the C-RNTI sent in the RRCConnectionReconfigurationComplete message.

14 The target eNB can now begin sending data to the UE.


- 254 - © Ericsson 2009 LZT 123 8958 R1A

15 The target eNB sends a S1: PATH SWITCH message to MME to inform that the UE has changed cell.

Encryption and Integrity Protection AlgorithmsMUE Security Capabilities

uniquely identify a Tracking AreaMTAI

used to globally identify a cell ME-UTRAN CGI

The MME UE S1AP ID uniquely identify the UE associationover the S1 interface within the MME.

MSource MME UE S1AP ID

To deliver DL PDUsM>> GTP-TEID

The Radio Network Layer is not supposed to interpret theaddress information. It should pass it to the transport layerfor interpretation.

M>> Transport layer address

This element uniquely identifies a radio access bearer for aparticular UE, which makes the E-RAB ID unique over oneS1 connection. The E-RAB ID shall remain the same forthe duration of the E-RAB even if the UE-associatedlogical S1-connection is released or moved using S1handover.

M>> E-RAB ID

>E-RABs Switched in Downlink Item IEs

ME-RAB To Be Switched in Downlink List

The eNB UE S1AP ID uniquely identify the UE associationover the S1 interface within the eNB

MeNB UE S1AP ID

PathSwitchRequestMMessage Type

Semantics descriptionIE type and referencePIE/Group Name

Encryption and Integrity Protection AlgorithmsMUE Security Capabilities

uniquely identify a Tracking AreaMTAI

used to globally identify a cell ME-UTRAN CGI

The MME UE S1AP ID uniquely identify the UE associationover the S1 interface within the MME.

MSource MME UE S1AP ID

To deliver DL PDUsM>> GTP-TEID

The Radio Network Layer is not supposed to interpret theaddress information. It should pass it to the transport layerfor interpretation.

M>> Transport layer address

This element uniquely identifies a radio access bearer for aparticular UE, which makes the E-RAB ID unique over oneS1 connection. The E-RAB ID shall remain the same forthe duration of the E-RAB even if the UE-associatedlogical S1-connection is released or moved using S1handover.

M>> E-RAB ID

>E-RABs Switched in Downlink Item IEs

ME-RAB To Be Switched in Downlink List

The eNB UE S1AP ID uniquely identify the UE associationover the S1 interface within the eNB

MeNB UE S1AP ID

PathSwitchRequestMMessage Type

Semantics descriptionIE type and referencePIE/Group Name

Figure 10-7: S1 Path Switch Request

16 The MME sends an UPDATE USER PLANE REQUEST message to the Serving Gateway.

17 The Serving Gateway switches the downlink data path to the target side. The Serving gateway sends one or more "end marker" packets on the old path to the source eNB and then can release any U-plane/TNL resources towards the source eNB.

18 Serving Gateway sends an UPDATE USER PLANE RESPONSE message to MME.


LZT 123 8958 R1A © Ericsson 2009 - 255 -

19 The MME confirms the PATH SWITCH message with the PATH SWITCH ACKNOWLEDGE message.

One pair of {NCC, NH} is provided

The purpose of the Security Context IE is to provide security related parameters to the eNB which are used to derive security keys for user plane traffic and RRC signalling messages and for security parameter generation for subsequent X2 or intra eNB Handovers, or for the security parameters for the current S1 Handover

MSecurity Context

E-RAB List OE-RAB To Be Released List

This information element is the GTP Tunnel Endpoint Identifier to be used for the user plane transport between eNB and the serving gateway

M>> GTP-TEID

The Radio Network Layer is not supposed to interpret the address information. It should pass it to the transport layer for interpretation.

M>> Transport Layer Address

This element uniquely identifies a radio access bearer for a particular UE, which makes the E-RAB ID unique over one S1 connection. The E-RAB ID shall remain the same for the duration of the E-RAB even if the UE-associated logical S1-connection is released or moved using S1 handover.

M>> E-RAB ID

> E-RABs Switched in Uplink Item IEs

OE-RAB To Be Switched in Uplink List

The UE Aggregate Maximum Bitrate is applicable for all Non-GBR bearers per UE which is defined for the Downlink and the Uplink direction and provided by the MME to the eNB.

OUE Aggregate Maximum Bit Rate

The eNB UE S1AP ID uniquely identify the UE association over the S1 interface within the eNB

MeNB UE S1AP ID

The MME UE S1AP ID uniquely identify the UE association over the S1 interface within the MME.

MMME UE S1AP ID

PathSwitchRequestAckMMessage Type

Semantics description


One pair of {NCC, NH} is provided

The purpose of the Security Context IE is to provide security related parameters to the eNB which are used to derive security keys for user plane traffic and RRC signalling messages and for security parameter generation for subsequent X2 or intra eNB Handovers, or for the security parameters for the current S1 Handover

MSecurity Context

E-RAB List OE-RAB To Be Released List

This information element is the GTP Tunnel Endpoint Identifier to be used for the user plane transport between eNB and the serving gateway

M>> GTP-TEID

The Radio Network Layer is not supposed to interpret the address information. It should pass it to the transport layer for interpretation.

M>> Transport Layer Address

This element uniquely identifies a radio access bearer for a particular UE, which makes the E-RAB ID unique over one S1 connection. The E-RAB ID shall remain the same for the duration of the E-RAB even if the UE-associated logical S1-connection is released or moved using S1 handover.

M>> E-RAB ID

> E-RABs Switched in Uplink Item IEs

OE-RAB To Be Switched in Uplink List

The UE Aggregate Maximum Bitrate is applicable for all Non-GBR bearers per UE which is defined for the Downlink and the Uplink direction and provided by the MME to the eNB.

OUE Aggregate Maximum Bit Rate

The eNB UE S1AP ID uniquely identify the UE association over the S1 interface within the eNB

MeNB UE S1AP ID

The MME UE S1AP ID uniquely identify the UE association over the S1 interface within the MME.

MMME UE S1AP ID

PathSwitchRequestAckMMessage Type

Semantics description


Figure 10-8 S1 Path Switch Acknowledge

20 By sending UE CONTEXT RELEASE, the target eNB informs success of HO to source eNB and triggers the release of resources by the source eNB. The target eNB sends this message after the PATH SWITCH ACKNOWLEDGE message is received from the MME.

21 Upon reception of the UE CONTEXT RELEASE message, the source eNB can release radio and C-plane related resources associated to the UE context. Any ongoing data forwarding may continue.


- 256 - © Ericsson 2009 LZT 123 8958 R1A

U-plane handling

The U-plane handling during the Intra-E-UTRAN-Access mobility activity for UEs in ECM-CONNECTED takes the following principles into account to avoid data loss during HO:

During HO preparation U-plane tunnels are established between the source eNB and the target eNB. There is one tunnel established for uplink data forwarding and another one for downlink data forwarding for each E-RAB for which data forwarding is applied.

During HO execution, user data is forwarded from the source eNB to the target eNB. The forwarding is not specified by 3GPP.

Forwarding of downlink user data from the source to the target eNB should take place in order as long as packets are received at the source eNB from the EPC or the source eNB buffer has not been emptied.

At HO completion (UE Detection on the target side) the target eNB sends a PATH SWITCH message to MME to inform that the UE has gained access and MME sends a USER PLANE UPDATE REQUEST message to the Serving Gateway, the U-plane path is switched by the Serving Gateway from the source eNB to the target eNB.

The source eNB should continue forwarding of U-plane data as long as packets are received at the source eNB from the Serving Gateway or the source eNB buffer has not been emptied.

For RLC-AM bearers:

For in-sequence delivery and duplication avoidance, PDCP SN is maintained on a bearer basis and the source eNB informs the target eNB about the next DL PDCP SN to allocate to a packet which does not have a PDCP sequence number yet (either from source eNB or from the Serving Gateway).

For security synchronization, HFN is also maintained and the source eNB provides to the target one reference HFN for the UL and one for the DL i.e. HFN and corresponding SN.


LZT 123 8958 R1A © Ericsson 2009 - 257 -

The occurrence of duplicates over the air interface in the target eNB is minimized by means of PDCP SN based reporting at the target eNB by the UE. In uplink, the reporting is optionally configured on a bearer basis by the eNB and the UE should first start by transmitting those reports when granted resources in the target eNB. In downlink, the eNB is free to decide when and for which bearers a report is sent and the UE does not wait for the report to resume uplink transmission.

The target eNB re-transmits and prioritizes all downlink PDCP SDUs forwarded by the source eNB (i.e. the target eNB should send data with PDCP SNs from X2 before sending data from S1), with the exception of PDCP SDUs of which the reception was acknowledged through PDCP SN based reporting by the UE.

The UE re-transmits in the target eNB all uplink PDCP SDUs starting from the first PDCP SDU following the last consecutively confirmed PDCP SDU i.e. the oldest PDCP SDU that has not been acknowledged at RLC in the source, excluding the PDCP SDUs of which the reception was acknowledged through PDCP SN based reporting by the target.

For RLC-UM bearers:

-The PDCP SN and HFN are reset in the target eNB.

-No PDCP SDUs are retransmitted in the target eNB.

-The target eNB prioritize all downlink PDCP SDUs forwarded by the source eNB if any (i.e. the target eNB should send data with PDCP SNs from X2 before sending data from S1),.

-The UE PDCP entity does not attempt to retransmit any PDCP SDU in the target cell for which transmission had been completed in the source cell. Instead UE PDCP entity starts the transmission with other PDCP SDUs.

Path Switch

After the downlink path is switched at the Serving GW downlink packets on the forwarding path and on the new direct path may arrive interchanged at the target eNB. The target eNodeB should first deliver all forwarded packets to the UE before delivering any of the packets received on the new direct path.


- 258 - © Ericsson 2009 LZT 123 8958 R1A

In order to assist the reordering function in the target eNB, the Serving GW shall send one or more "end marker" packets on the old path immediately after switching the path for each E-RAB of the UE. The "end marker" packet shall not contain user data. The "end marker" is indicated in the GTP header. After completing the sending of the tagged packets the GW shall not send any further user data packets via the old path.

Upon receiving the "end marker" packets, the source eNB shall, if forwarding is activated for that bearer, forward the packet toward the target eNB.

On detection of an "end marker" the target eNB shall discard the end marker packet and initiate any necessary processing to maintain in sequence delivery of user data forwarded over X2 interface and user data received from the serving GW over S1 as a result of the path switch.

On detection of the "end marker", the target eNB may also initiate the release of the data forwarding resource.

EPC may change the uplink end-point of the tunnels with Path Switch procedure. However, the EPC should keep the old GTP tunnel end-point(s) sufficiently long time in order to minimise the probability of packet losses and avoid unintentional release of respective E-RAB(s).

Data forwarding

For RLC-AM DRBs

Upon handover, the source eNB may forward in order to the target eNB all downlink PDCP SDUs with their SN that have 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.

The source eNB discards any remaining downlink RLC PDUs. Correspondingly, the source eNB does not forward the downlink RLC context to the target eNB.

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 of time the source eNB stops delivering uplink PDCP SDUs to the S-GW and shall discard any remaining uplink RLC PDUs. Correspondingly, the source eNB does not forward the uplink RLC context to the target eNB.


LZT 123 8958 R1A © Ericsson 2009 - 259 -

Then the source eNB discards the uplink PDCP SDUs received out of sequence if the source eNB has not accepted the request from the target eNB for uplink forwarding or if the target eNB has not requested uplink forwarding for the bearer during the Handover Preparation procedure,

-forward to the target eNB the uplink PDCP SDUs received out of sequence if the source eNB has accepted the request from the target eNB for uplink forwarding for the bearer during the Handover Preparation procedure.

The PDCP SN of forwarded SDUs is carried in the "PDCP PDU number" field of the GTP-U extension header. The target eNB shall use the PDCP SN if it is available in the forwarded GTP-U packet.

In-sequence delivery of upper layer PDUs during handover is based on a continuous PDCP SN and is provided by the "in-order delivery and duplicate elimination" function at the PDCP layer:

-in the downlink, the "in-order delivery and duplicate elimination" function at the UE PDCP layer guarantees in-sequence delivery of downlink PDCP SDUs;

S-GW

Transmitter State

5

6

4

Receiver State

5

6

4

456

Status: ACK 4 & 5

X2APNext SN = 7

PDCP SN is continuous through Handover

end marker

• Source forwards outstanding un-ACK:ed SDUs to target with their SN attached. • Source tells Target what PDCP SN to allocate next. • Non-outstanding SDUs are forwarded (in order) without SN • Target “prioritizes” forwarded SDUs. • UE re-orders PDCP SDUs based on the SN. • UE may submit a PDCP Status to guide Target re-Tx• NO Data forwarding for SRBs; PDCP SN and HFN are reset @ target

Source eNB Target eNB

Figure 10-9 DL Data Forwarding

-in the uplink, the "in-order delivery and duplicate elimination" function at the target eNB PDCP layer guarantees in-sequence delivery of uplink PDCP SDUs.


- 260 - © Ericsson 2009 LZT 123 8958 R1A

“3”

“4”Receiver State

4

5

3Transmitter State

4

5

3

X2_AP:ACK 4, NACK 5

PDCPStatus report: ACK 4, NACK 5

6

6

6

5

S-GW

• Source forwards SDUs received out-of-sequence to Target with their SN attached.

• Target re-orders PDCP SDUs. • Target may submit a PDCP Status

(or, a Status tunneled from Source) to UE to guide re-transmissions to Target.

PDCP SN is continuous through Handover

Target eNBSource eNB

Figure 10-10 UL Data Forwarding

After handover, when the UE receives a PDCP SDU from the target eNB, it can deliver it to higher layer together with all PDCP SDUs with lower SNs regardless of possible gaps.

SRB handling

There is neither forwarding nor retransmissions of RRC messages in the target for the RRC signaling. The PDCP SN and HFN are reset in the target.

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. The source eNB discards any remaining downlink RLC PDUs. Correspondingly, the source eNB does not forward the downlink RLC context to the target eNB.


LZT 123 8958 R1A © Ericsson 2009 - 261 -

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) and discards any remaining uplink RLC PDUs. Correspondingly, the source eNB does not forward the uplink RLC context to the target eNB.

S1 HANDOVER

LTE NodeB

S1 handover:– Relocation of MME

or SGW– Handover to UTRAN

or GSM– Change of MME pool

areaSignalling is done via EPC and does not assume the existance of an X2 interface.Similar to inter-RAT handoverForwarding of user data either directly between eNodeB or in-direct via S-GW (Selective Forwarding)

MMEMMESGWSGW SGWSGWMMEMME

Figure 10-11 S1 Handoverr

S1 handover imply relocation of MME or S-GW. Signaling is done via EPC when X2 is non existent between source eNB and target eNB.

S1 Handover and IRAT Handover are very similar. Major difference is in creation of Source to Target Transparent Container.

Data forwarding

So how does the signaling look like?

1 The source eNB configures the UE measurement procedures according to the area restriction information. Measurements provided by the source eNB may assist the function controlling the UE's connection mobility. Measurement Command message is included in RRC Connection Reconfiguration message


- 262 - © Ericsson 2009 LZT 123 8958 R1A

2 When a certain criteria is fulfilled (in our example event A3) UE will inform the source eNB by sending Measurement Report

3 Source eNB makes decision based on Measurement Report and RRM information to hand off UE

4 The source eNB initiates the handover preparation by sending the HANDOVER REQUIRED message to the serving MME. When the source eNB sends the HANDOVER REQUIRED message, it shall start the timer TS1RELOCprep. The source eNB shall indicate the appropriate cause value for the handover in the Cause IE. The source eNB shall include the Source to Target Transparent Container IE in the HANDOVER REQUIRED message. In case of intra-system handover, the container shall be encoded according to the definition of the Source eNB to Target eNB Transparent Container IE. In case of handover to UTRAN, the information in the Source to Target Transparent Container IE shall be encoded according to the Source RNC to Target RNC Transparent Container IE definition as specified in [19]. If the handover is to GERAN A/Gb mode then the Source to Target Transparent Container IE shall be encoded according to the definition of the Source BSS to Target BSS Transparent Container IE.


LZT 123 8958 R1A © Ericsson 2009 - 263 -

RRC CONNECTED

S-GW

Source eNB Target eNB1. RRC CONNECTION RECONFIGURATION

(Bearer Setup,Measurement conf))

2. RRC Measurement Report (Event A3)

3. HO Decision

4. S1 HANDOVER REQIRED (Source to Target Transparent Container )

8. Admission Control

9. S1 HANDOVER REQUEST ACKNOWLEDGE

12. RRC CONNECTION RECONFIGURATION (Handover Command,Measurement conf)

13 MAC: CFRA Random Access Preamble

14. MAC Random Access Response (UL allocation + TA)

15. RRC CONNECTION RECONFIGURATION COMPLETE(Handover Confirm)

RRC CONNECTED

T304

TS1RELOCprep

RegenerateSecurity Keys

17.Data Transfer in Target

MME MMES-GW

TargetTarget

5. S10 FORWARD RELOCATION REQUEST

6. S11 CREATE BEARER REQ/RES

7. S1 HANDOVER REQUEST

10. S10 FORWARD RELOCATION RESPONSE

12. S1 HANDOVER COMMAND

18.S10 FORWARD RELOCATION COMPLETE

Source Source

19. S1 UE CONTEXT RELEASE COMMAND(Cause: Successful Handover)

UP Forwarding

Source eNB Target eNB SourceSource eNB Target eNB TargetSourceSource eNB Target eNB SourceTargetSourceSource eNB Target eNB TargetSourceTargetSourceSource eNB Target eNB

11. S11 CREATE BEARER REQ/RES

16. S1 HANDOVER NOTIFY

Figure 10-12 S1 Handover

5 Source MME identifies Target MME (MME Selection Function) and sends S10 Forward Relocation Request (MME UE Context ,Source to Target Transparent Container, target eNB Id)

6 At the reception of the S10 Forward Relocation Request Target MME checks if old S-GW can be used. If not it will select serving GW and orders allocation of the resources in target S-GW This also triggers GTP tunnel setup between P-GW and target S-GW.

7 Once S-GW resources are ordered and GTP Tunnel is set up S1 Handover Request message is sent to Target eNB.

8 Target eNodeB will perform Admission Control for each E-RAB that needs to be set up.


- 264 - © Ericsson 2009 LZT 123 8958 R1A

9 If any of the requested E-RABs (with requester QoS) is admitted target eNB will create Target to Source Container and will send it to the UE via Target MME in S1 Handover Request Acknowledge message.

10 Target will pass received Target to Source Container to Source eNB using S10 Forward Relocation Response message

11 If indirect forwarding is applicable the source MME sends Create Bearer Request (Cause, addresses and TEIDs for forwarding) to the Serving GW. In case the Serving GW is relocated it includes the tunnel identifier to the target serving GW. Cause indicates that the bearer(s) are subject to data forwarding. The Serving GW responds with a Create Bearer Response (Serving GW addresses and TEIDs for forwarding) message to the source MME

12 Source MME responds with the S1 Handover Command message to the source eNB. If the Target to Source Transparent Container IE has been received by the MME from the handover target then the transparent container shall be included in the S1 Handover Command message. Upon reception of the S1 Handover Command message the source eNB shall stop the timer TS1RELOCprep and start the timer TS1RELOCOverall.

13 The source eNB sends the received RRC message to perform the handover, i.e RRCConnectionReconfiguration that was included in S1: message Handover Command including the mobilityControlInformation, to the UE. The source eNB performs the necessary integrity protection and ciphering of the message. The UE receives the RRCConnectionReconfiguration message with necessary parameters. The UE does not need to delay the handover execution for delivering the HARQ/ARQ responses to source eNB. After receiving the RRCConnectionReconfiguration message including the mobilityControlInformation

14 UE performs synchronization to target eNB and accesses the target cell via RACH, following a contention-free procedure if a dedicated RACH preamble was indicated in the mobilityControlInformation, or following a contention-based procedure if no dedicated preamble was indicated. UE derives target eNB specific keys and configures the selected security algorithms to be used in the target cell.

15 The target eNB responds with UL allocation and timing advance.


LZT 123 8958 R1A © Ericsson 2009 - 265 -

16 When the UE has successfully accessed the target cell, the UE sends the RRCConnectionReconfigurationComplete message (C-RNTI) to confirm the handover, along with an uplink Buffer Status Report, whenever possible, to the target eNB to indicate that the handover procedure is completed for the UE. The target eNB verifies the C-RNTI sent in the RRCConnectionReconfigurationComplete message.

17 The target eNB informs Target MME that the UE has selected the target cell by sending S1 Handover Notify

Target MME informs P-GW to switch path (NOTE: not shown in the sequence)

18 Target MME informs Source MME that Handover was successful by sending S10 Forward Relocation Complete and the source responds with S10 Forward Relocation Complete Ack

19 Source MME initiates release in source eNB by sending S1 Ue Context Release Command with IE cause Successful Handover.


- 266 - © Ericsson 2009 LZT 123 8958 R1A

INTERWORKING WITH 2G/3G

Handover

CELL_PCHURA_PCH

CELL_DCH

UTRA_Idle

E-UTRARRC_CONNECTED

E-UTRARRC_IDLE

GSM_Idle/GPRS Packet_Idle

GPRS Packet transfer mode

GSM_ConnectedHandover

ReselectionReselection

Reselection

Connectionestablishment/release



CCO, Reselection

CCO withNACC

CELL_FACH

CCO, Reselection +PDP context est*

PMM_CONNECTED

PMM_IDLE

* PDP Context establishment is needed if no PDP context exists

Reselection +PDP context est*

ECM - CONNECTED

ECM -IDLE

PMM_DETACHED EMM_DEREGISTERED Idle

Cell change (without signaling)

Cell change(without signaling)

Figure 10-13 UE States: Interworking with 2G/3G

Handover

According to the 36.300 Inter RAT HO is designed so that changes to GERAN and UTRAN are minimized. This can be done by following the principles specified for GERAN to/from UTRAN intersystem HO. In particular the following principles are applied to E-UTRAN Inter RAT HO design: • Inter RAT HO is network controlled through source access

system. The source access system decides about starting the preparation and provides the necessary information to the target system in the format required by the target system. That is, the source system adapts to the target system. The actual handover execution is decided in the source system.

• Inter RAT HO is backwards handover, i.e. radio resources are prepared in the target 3GPP access system before the UE is commanded by the source 3GPP access system to change to the target 3GPP access system.


LZT 123 8958 R1A © Ericsson 2009 - 267 -

• To enable backwards handover, and while RAN level interfaces are not available, a control interface exists in CN level. In Inter RAT HO involving E-UTRAN access, this interface is between 2G/3G SGSN and corresponding MME/Serving Gateway.

• The target access system will be responsible for giving exact guidance for the UE on how to make the radio access there (this includes radio resource configuration, target cell system information etc.). This information is given during the handover preparation and should be transported completely transparently through the source access system to the UE.

• Mechanisms for avoiding or mitigating the loss of user data (i.e. forwarding) can be used until the 3GPP Anchor determines that it can send DL U-plane data directly to the target system.

• The handover procedure should not require any UE to CN signalling in order for data to start to flow in the target system. This requires that the security context, UE capability context and QoS context is transferred (or translated) within the network between source and target system.

• Similar handover procedure should apply for handovers of both real time and non-real time services.

• Similar handover procedure should apply for both Inter RAT Handover and intra-LTE Handover with EPC node change.

• Network controlled mobility is supported even if no prior UE measurements have been performed on the target cell and/or frequency i.e. “blind HO” is supported

Cell Reselection

A UE in RRC_IDLE performs cell reselection. The principles of this procedure according to 36.300 are as follows:

The UE makes measurements of attributes of the serving and neighbor cells to enable the reselection process: • For a UE to search and measure neighboring GERAN cells, the

ARFCNs of the BCCH carriers need to be indicated in the serving cell system information (i.e., an NCL). The NCL does not contain BSICs or cell specific offsets and Qrxlevmin is given per frequency band.

• For a UE to search and measure neighboring UTRAN cells, the serving cell can indicate an NCL containing a list of carrier frequencies and scrambling codes.

• Measurements may be omitted if the serving cell attribute fulfils particular search or measurement criteria.


- 268 - © Ericsson 2009 LZT 123 8958 R1A

• Cell reselection identifies the cell that the UE should camp on. It is based on cell reselection criteria which involves measurements of the serving and neighbor cells:

• Inter-RAT reselection is based on absolute priorities where UE tries to camp on highest priority RAT available. Absolute priorities for inter-RAT reselection are provided only by the RPLMN and valid only within the RPLMN; priorities are given by the system information and valid for all UEs in a cell, specific priorities per UE can be signaled in the RRC Connection Release message. A validity time can be associated with UE specific priorities.

• It should be possible to prevent the UE from reselecting to specific detected neighboring cells;

• The UE is allowed to "leave" the source E-UTRAN cell to read the target GERAN cell broadcast, in order to determine its "suitability", prior to completing the cell reselection;

• Cell reselection can be speed dependent (speed detection based on UTRAN solution);

Cell access restrictions apply as for UTRAN, which consist of access class (AC) barring and cell reservation (e.g. for cells "reserved for operator use") applicable for mobiles in RRC_IDLE mode.

When performing cell reselection while the UE is camped on another RAT, the principles of this procedure are as follows:

The UE measures attributes of the E-UTRA neighboring cells:

Only the carrier frequencies need to be indicated to enable the UE to search and measure E-UTRA neighboring cells;

Cell reselection identifies the cell that the UE should camp on. It is based on cell reselection criteria which involve measurements of the serving and neighbor cells:

For E-UTRA neighboring cells, there is no need to indicate cell-specific cell reselection parameters i.e. these parameters are common to all neighboring cells on an E-UTRA frequency;

Cell reselection parameters are applicable to all UEs in a cell, but it is possible to configure specific reselection parameters per UE group or per UE.

It should be possible to prevent the UE from reselecting to specific detected neighboring cells


LZT 123 8958 R1A © Ericsson 2009 - 269 -

CCO with NCC

CCO with NCC stands for Cell Change Order with Network assisted Cell Change. It is a mechanism that is used for load balancing in E-UTRAN.

Redirection mechanism can be used upon RRC establishment, in RRC_CONNECTED and upon RRC release and through the usage of inter-frequency and inter-RAT absolute priorities and inter-frequency Qoffset parameters.

Traffic Cases

In the Figure 10-14 and Figure 10-15 simplified LTE to 3G Handover and LTE to 3G Cell Reselection uses cases can be followed.

SGSNSGSN

RNC

MME

sourceS-GW

PDN-GW

targetS-GW

1

1. Handover Required2. Forward Relocation Request3. Create PDP Context Request4. Create PDP Context Response5. Relocation Request6. Relocation Request Ack7. Update PDP Context Request8. Update PDP Context Response9. Forward Relocation Response10. Create Bearer Request11. Create Bearer Response12. HO Command13. HO from E -UTRAN Command14. HO to UTRAN Complete15. Relocation Complete16. Forward Relocation Complete17. Forward Relocation Complete Ack18. Update PDP Context Request19. Update Bearer Request20. Update Bearer Response21. Update PDP Context Response

2

34

5 6

78

9

1011

12

1314

15

16

1718

19

20

21

SGSNSGSN

RNC

MME

Figure 10-14 LTE to 3G Handover


- 270 - © Ericsson 2009 LZT 123 8958 R1A

SGSNSGSN

RNC

MME

PDN-GW

S-GW

1a. Routing Area Update Request1b. Routing Area Update Request2. Context Request3. Context Response4. Context Acknowledge5. Update Bearer Request6. Update Bearer Request7. Update Bearer Response8. Update Bearer Response9. Routing Area Update Accept10. Routing Area Update Complete

2

1b 3

1a

67

4

58

9

10

SGSNSGSN

RNC

MME

Figure 10-15 LTE to 3G Cell Reselection


LZT 123 8958 R1A © Ericsson 2009 - 271 -

11 Appendix


- 272 - © Ericsson 2009 LZT 123 8958 R1A

Intentionally Blank


LZT 123 8958 R1A © Ericsson 2009 - 273 -

Extracts from: S1 and IRAT HO flows: TS 23.401

RNTI TS 36.321

Security TS 33.401


- 274 - © Ericsson 2009 LZT 123 8958 R1A

S1 BASED HANDOVER

UE Source eNodeB

Source MME

Source Serving GW PDN GW

Target MME

Target Serving GW

Target eNodeB

Detach from old cell and synchronize to new cell

HSS

16. Update Bearer Request

17. Update Bearer Response


Downlink User Plane data

2. Handover Required

Downlink User Plane data

1. Decision to trigger a relocation via S1

3. Forward Relocation Request

5. Handover Request 5a. Handover Request Acknowledge

7. Forward Relocation Response

9. Handover Command 9a. Handover Command

11a. Only for Direct forwarding of data

12. Handover Confirm Downlink data

13. Handover Notify

14. Forward Relocation Complete

14b. Forward Relocation Complete Acknowledge

16a. Update Bearer Response

. 8a. Create Bearer Response

(A)

11b. Only for Indirect forwarding of data

18. Tracking Area Update procedure

19c. Delete Bearer Request

(B)19a. UE Context Release Command

Uplink User Plane data

8. Create Bearer Request

6a. Create Bearer Response




19b. UE Context Release Complete 19d. Delete Bearer Response

20a. Delete Bearer Request

20b. Delete Bearer Response

21a. Delete Bearer Request

21b. Delete Bearer Response

10. eNB Status Transfer

10c. eNB Status Transfer

10a. Forward SRNS Context 10b. Forward SRNS Context Ack

Figure 11-1 Si Based Handover.


LZT 123 8958 R1A © Ericsson 2009 - 275 -

E-UTRAN TO UTRAN IU MODE INTER RAT HO,

PREPARATION PHASE

UE

Source eNodeB Target RNC Source MME Target SGSN Serving GW HSS

1. Handover Initiation 2. Handover Required 3. Forward Relocation Request

5. Relocation Request

5a. Relocation Request Acknowledge



PDN GW

8a. CreateBearer Response

Uplink and DownlinkUser Plane PDUs

Target Serving GW





Figure 11-2 E-UTRAN TO UTRAN IU MODE INTER RAT HO, Preparation phase


- 276 - © Ericsson 2009 LZT 123 8958 R1A

EXECUTION PHASE

UE

Source eNodeB Target RNC Source MME Target SGSN Serving GW HSS PDN GW

Uplink and Downlink User Plane PDUs

1. Handover Command 2. HO from E-UTRAN Command -

Sending of uplink data possible

4. UTRAN Iu Access Procedures

5. Relocation Complete

6. Forward Relocation Complete

6a. Forward Relocation Complete Acknowledge


8a. Update Bearer Response9. Update Bearer Response

Uplink and Downlink User Plane PDUs (Via Target SGSN if Direct Tunnel is not used)

4a. Handover to UTRAN Complete

Downlink User Plane PDUs

If Direct Forwarding applies

If Indirect Forwarding applies.

Target Serving GW

(A)8. Update Bearer Request

Via Target SGSN in case Direct Tunnel is not used

10. Routeing Area Update procedure

11. Delete Bearer Request

(B)11a. Delete Bearer Response

11b. Release Resources

For Serving GW relocation Steps 7, 8 and 9, and the following User Plane path, will be handled by Target Serving GW

12. Delete Bearer

Figure 11-3 E-UTRAN TO UTRAN IU MODE INTER RAT HO, Execution phase


LZT 123 8958 R1A © Ericsson 2009 - 277 -

E-UTRAN TO GERAN A/GB MODE INTER RAT HANDOVER

PREPARATION PHASE

UE

Source eNodeB Target BSS Source MME Target SGSN Serving GW HSS

1. Handover Initiation 2. Handov er Required

3. Forward Relocation Request

5. PS Handover Request

5a. PS Handover Request Acknowledge



PDN GW



Target Serving GW



6 Create Bearer Request


Figure 11-4 E-UTRAN TO GERAN A/GB MODE INTER RAT HANDOVER, Preparation phase


- 278 - © Ericsson 2009 LZT 123 8958 R1A

EXECUTION PHASE

UE

Source eNodeB Target BSS Source MME Target SGSN Serving GW HSS

PDN GW


1. Handover Command

2. HO from E-UTRAN Command

Sending of uplink data possible

4. GERAN A/Gb Access Procedures

5. XID Response

6. PS Handover Complete

8. Forward Relocation Complete8a. Forward Relocation Complete Acknowledge


11. Update Bearer Response


7. XID Response

12. XID Negotiation for LLC ADM

12a. SABM UA exchange re-establishment and XID negotiation for LLC ABM)

Downlink User Plane PDUs

Only if ”Direct Forwarding” applies

Target Serving GW

For Serving GW relocation Steps 9, 10 and 11, and the following User Plane path, will be handled by Target Serving GW

(A)10. Update Bearer Request

10a. Update Bearer Response

13. Routeing Area Update procedure

14b. Release Resource 14. Delete Bearer Request

(B)14a. Delete Bearer Response

Only if ”Indirect Forwarding” applies

Figure 11-5 Figure 12 4 E-UTRAN TO GERAN A/GB MODE INTER RAT HANDOVER, Execution phase


LZT 123 8958 R1A © Ericsson 2009 - 279 -

RNTI

N/AN/APhysical layer Uplink power controlTPC-PUSCH-RNTI

N/AN/APhysical layer Uplink power controlTPC-PUCCH-RNTI

N/AN/ASemi-Persistently scheduled unicast transmission (deactivation)

Semi-Persistent Scheduling C-RNTI

DCCH, DTCHDL-SCH, UL-SCH

Semi-Persistently scheduled unicast transmission (activation, reactivation and retransmission)


N/AN/ATriggering of PDCCH ordered random accessC-RNTI


Dynamically scheduled unicast transmissionC-RNTI

CCCH, DCCH, DTCH

UL-SCHMsg3 transmissionTemporary C-RNTI

CCCHDL-SCHContention Resolution (when no valid C-RNTI is available)

Temporary C-RNTI

N/ADL-SCHRandom Access ResponseRA-RNTI

BCCHDL-SCHBroadcast of System InformationSI-RNTI

PCCHPCHPaging and System Information change notificationP-RNTI

Logical Channel

Transport Channel

UsageRNTI

N/AN/APhysical layer Uplink power controlTPC-PUSCH-RNTI

N/AN/APhysical layer Uplink power controlTPC-PUCCH-RNTI

N/AN/ASemi-Persistently scheduled unicast transmission (deactivation)



Semi-Persistently scheduled unicast transmission (activation, reactivation and retransmission)


N/AN/ATriggering of PDCCH ordered random accessC-RNTI


Dynamically scheduled unicast transmissionC-RNTI

CCCH, DCCH, DTCH

UL-SCHMsg3 transmissionTemporary C-RNTI

CCCHDL-SCHContention Resolution (when no valid C-RNTI is available)

Temporary C-RNTI

N/ADL-SCHRandom Access ResponseRA-RNTI

BCCHDL-SCHBroadcast of System InformationSI-RNTI

PCCHPCHPaging and System Information change notificationP-RNTI

Logical Channel

Transport Channel

UsageRNTI

Figure 11-6 Radio Network Temporary Ids


- 280 - © Ericsson 2009 LZT 123 8958 R1A

SECURITY Key Derivation

K

IK CK

K_ASME

K_NASINT K_NASENC K_eNB

K_eNB_RRC INT K_eNB_RRC ENC K_eNB_UP enc

UICC/AUC

UE/HSS

UE/ASME

UE/eNB

Figure 11-7 Key Hierarchy

The key hierarchy includes following keys: KeNB, KNASint, KNASenc, KUPenc, KRRCint and KRRCenc

KeNB is a key derived by UE and MME from KASME when the UE goes to ECM-CONNECTED state or by UE and target eNB during eNB handover.

Keys for NAS traffic:

KNASint is a key, which shall only be used for the protection of NAS traffic with a particular integrity algorithm This key is derived by UE and MME from KASME, as well as an identifier for the integrity algorithm using the KDF as specified in Annex A.

KNASenc is a key, which shall only be used for the protection of NAS traffic with a particular encryption algorithm. This key is derived by UE and MME from KASME, as well as an identifier for the encryption algorithm using the KDF as specified in Annex A.


LZT 123 8958 R1A © Ericsson 2009 - 281 -

Keys for UP traffic:

KUPenc is a key, which shall only be used for the protection of UP traffic with a particular encryption algorithm. This key is derived by UE and eNB from KeNB, as well as an identifier for the encryption algorithm using the KDF as specified in Annex A.

Keys for RRC traffic:

KRRCint is a key, which shall only be used for the protection of RRC traffic with a particular integrity algorithm. KRRCint is derived by UE and eNB from KeNB, as well as an identifier for the integrity algorithm using the KDF as specified in Annex A.

KRRCenc is a key, which shall only be used for the protection of RRC traffic with a particular encryption algorithm. KRRCenc is derived by UE and eNB from KeNB as well as an identifier for the encryption algorithm using the KDF as specified in Annex A.

Intermediate keys:

NH is a key derived by UE and MME to provide forward security The NH is sent by the MME to the eNB using S1signalling.

KeNB* is a key derived by UE and eNB when performing an horizontal or vertical key derivation using a Key Derivation Function (KDF).


- 282 - © Ericsson 2009 LZT 123 8958 R1A

Intentionally Blank


LZT 123 8958 R1A © Ericsson 2009 - 283 -

12 Abbreviations


- 284 - © Ericsson 2009 LZT 123 8958 R1A

Intentionally Blank


LZT 123 8958 R1A © Ericsson 2009 - 285 -

3GPP 3rd Generation Partnership Project ACIR Adjacent Channel Interference Ratio ACK Acknowledgement ACLR Adjacent Channel Leakage Ratio ACP Automatic Cell Planning ACS Adjacent Channel Selectivity AES Advanced Encryption Standard AGW Access Gateway AIF Auto-Integration Function AISG Antenna Interface Standards Group AM Acknowledged Mode AMBR Aggregate Maximum Bit Rate A-MPR Additional Maximum Power Reduction ANR Automated Neighbour Relation APAC Asia Pacific API Application Programming Interface APN Access Point Name ARP Allocation and Retention Priority ARQ Automatic Repeat Request ARW Add RBS Wizard AS Access Stratum AS Application Server A-SBG Access SBG ASC Antenna System Controller ASD Automatic SW Download ASSL Adjacent Subcarrier Set Leakage ASSR Adjacent Subcarrier Set Rejection BCCH Broadcast Control Channel BCH Broadcast Channel BEM Block Edge Masks BM-SC Broadcast-Multicast Service Center BS Base Station BSR Buffer Status Report BW Bandwidth C/I Carrier-to-Interference Power Ratio CA Certificate Authority CAPEX Capital Expenditure CAZAC Constant Amplitude Zero Auto-Correlation CCCH Common Control Channel CDD Cyclic Delay Diversity CDF Cumulative Distribution Function CDMA Code Division Multiple Access CE Carrier Ethernet CEPT The European Conference of Postal and Telecommunications Administrations CM Configuration Management CMC Connection Mobility Control CMDB Configuration Management Data Base CN Core Network COMINF Common O&M Infrastructure CO-OP Cooperative Open-OSS Project (interface also called Itf-P2P) CORBA Common Object Request Broker Architecture


- 286 - © Ericsson 2009 LZT 123 8958 R1A

CP Cyclic Prefix CP Control Plane CPC Continous Packet Connectivity C-plane Control Plane CQI Channel Quality Indicator CRC Cyclic Redundancy Check C-RNTI Cell RNTI CS Circuit Switched CSCF Call Session Control Function CSV Comma-Separated Values CTR Cell TRace CW Codeword CW Continuous-wave DCCH Dedicated Control Channel DCH Dedicated Channel DCN Data Communication Network DFT Discrete Fourier Transform DFT-S-OFDM DTF Spread OFDM DHCP Dynamic Host Configuration Protocol DL Downlink DL-SCH Downlink Shared Channel DNS Domain Name Service DRB Data Radio Bearer DRX Discontinuous Reception DSCP Differentiated Services Code Point DTCH Dedicated Traffic Channel DTX Discontinuous Transmission DwPTS Downlink Pilot Time Slot EBS Event Based Statistics ECC Electronic Communications Committee ECGI E-UTRAN Cell Global Identifier ECM EPS Connection Management E-DCH Enhanced DCH EHPLMN Equivalent Home PLMN EMEA Europe, Middle East and Africa EMM EPS Mobility Management eNB E-UTRAN NodeB eNode B E-UTRAN NodeB EPC Ericsson Policy Control EPC Evolved Packet Core EPS Evolved Packet System (E-UTRAN and EPC) E-RAB E-UTRAN Radio Access Bearer ETSI European Telecommunications Standards Institute ETWS Earth Quake and Tsunami Warning System E-UTRA Evolved UTRA E-UTRAN Evolved UTRAN, used as synonym for LTE in the document. EV-DO Evolution - Data Optimized EVM Error Vector Magnitude FCC Federal Communications Commission FDD Frequency Division Duplex FDM Frequency Division Multiplexing FDMA Frequency Division Multiple Access


LZT 123 8958 R1A © Ericsson 2009 - 287 -

FEC Forward Error Correction FFS For Further Study FFT Fast Fourier Transform FM Fault Management FMX Fault Management Expert FQDN Fully Qualified Domain Name FS Frame Structure FTP File Transfer Protocol GBR Guaranteed Bit Rate GCL Generalized Chirp Like GE Gigabit Ethernet GERAN GSM EDGE Radio Access Network GGSN Gateway GPRS Support Node GMPLS Generalized Multi-Protocol Label Switching GNSS Global Navigation Satellite System GP Guard Period GPRS General Packet Radio Service GSM Global System for Mobile communication GTP GPRS Tunneling Protocol GTP-C GTP Control GTP-U GTP User Data Tunneling GUI Graphical user Interface GUTI Globally Unique Temporary Identifier GW Gateway HA-CS High Availability Cluster Solution HARQ Hybrid ARQ HO Handover HOM Higher Order Modulation HPLMN Home PLMN HRPD High Rate Packet Data HSDPA High Speed Downlink Packet Access HS-DSCH High Speed Downlink Shared Channel HSPA High Speed Packet Access HSS Home Subscriber Server HSUPA High Speed Uplink Packet Access HTTP Hypertext Transfer Protocol HW Hardware IASA Inter-Access Anchor ICIC Inter-Cell Interference Coordination I-CSCF Interrogating CSCF ID Identifier IEEE Institute of Electrical and Electronics Engineers IETF Internet Engineering Task Force IFFT Inverse FFT IMEI International Mobile Equipment Identity IMS IP Multimedia Telephony IMS IP Multimedia subsystem IMSI Individual Mobile Subscriber Identity IMT International Mobile Telecommunications IP Internet Protocol IRAT Inter Radio Access Technology IS Integrated Site


- 288 - © Ericsson 2009 LZT 123 8958 R1A

ITU International Telecommunications Union ITU-R ITU Radio communication Sector JSR Java Specification Request KPI Key Performance Indicator LB Load Balancing LCID Logical Channel ID LCR Low Chip Rate LCR-TDD Low Chip Rate TDD LDC Linear Dispersion Code LDPC Low-Density Parity-check Code LED Light Emitting Diode LTE Long Term Evolution, used as synonym for E-UTRAN in the document. MAC Medium Access Control MBA Management Based Activation MBMS Multimedia Broadcast Multicast Service MBR Maximum Bit Rate MBSFN Multicast Broadcast Single Frequency Network MCCH Multicast Control Channel MCE Multi-cell/multicast Coordination Entity MCH Multicast Channel MCS Modulation and Coding Scheme MEF Mobile Entertainment Forum MGC Media Gateway Controller MGW Media Gateway MIB Master Information Block MIB Management Information Base MIMO Multiple Input Multiple Output ML-PPP Multilink point to point protocol MM Multi Mediation MM Mobility Management MME Mobility Management Entity MMS Multimedia Messaging Service Managed Objects interface (MOCI) MMTel Multi Media Telephony MOCI Managed Object Configuration Interface MOP Maximum Output Power MPLS Multiple Protocol Label Switching MPR Maximum Power Reduction MS Management Services MSAP MCH Subframe Allocation Pattern MTAS Multimedia Telephony Application Server MTCH Multicast Traffic Channel MU-MIMO Multiple User-MIMO mUPE MBMS UPE NACK Negative Acknowledgement NAS Non-Access Stratum NCC Network Color Code NCL Neighbour Cell List NCLI Node Command Line Interface NCS Neighbouring Cell Support NE Network Element NEM Network Element Manager NGMN Next Generation Mobile Networks


LZT 123 8958 R1A © Ericsson 2009 - 289 -

NGSA Next Generation Service Assurance NH Next Hop Key NM Network Management NMS Network Management System NMX Network level deployment of expert rules NOC Network Operations Center NR Neighbor cell Relation NRT Non Real Time N-SBG Network SBG O&M Operation and Maintenance OAM Operations Administration and Management OFDM Orthogonal Frequency Division Multiplexing OFDMA Orthogonal Frequency Division Multiple Access OMC Operation and Maintenance Center OOB Out Of Band OPEX Operating Expenditures OSS Operation and Support System OSS-RC Operation and Support System Radio and Core OTN Operator Terminal Network P(N)CCH Paging (and Notification) Control Channel P2P Peer-to-Peer PA Power Amplifier PAPR Peak to Average Power Ratio PAR Peak to Average Ratio PARC Per Antenna Rate Control PBBTE Provider Backbone Bridge Traffic Engineering PBC Power and Battery Cabinet PBCH Physical Broadcast CHannel PBN Packet Backbone Network PBR Prioritised Bit Rate PCC Policy Charging Control PCCH Paging Control Channel PCEF Policy Charging Enforcement Function PCFICH Physical Control Format Indicator CHannel PCH Paging Channel PCI Physical Cell ID PCRF Policy Control and Charging Rules Function P-CSCF Proxy - Call Session Control Function PDCCH Physical Downlink Control CHannel PDCP Packet Data Convergence Protocol PDN Packet Data Network PDP Packet Data Protocol PDSCH Physical Downlink Shared CHannel PDU Protocol Data Unit P-GW PDN Gateway PHICH Physical Hybrid ARQ Indicator CHannel PHR Power Headroom Report PHS Personal Handy-phone System PHY Physical layer PLMN Public Land Mobile Network PM Performance Management PMCH Physical Multicast CHannel


- 290 - © Ericsson 2009 LZT 123 8958 R1A

PMIP Proxy Mobile IP PnP Plug and Play PoP Point of Presence PRACH Physical Random Access CHannel PRB Physical Resource Block P-RNTI Paging RNTI PS Packet Switched PSC Packet Scheduling P-SCH Primary Synchronization Channel PSK Pre-Shared Keys PSTN Public Switched Telephone Network PTT Push to Talk PUCCH Physical Uplink Control CHannel PUSCH Physical Uplink Shared Channel QAM Quadrature Amplitude Modulation QCI QoS Class Identifier QoS Quality of Service QPP Quadrature Permutation Polynomial QPSK Quadrature Phase Shift Keying RA Random Access RA Registration Authority RAC Radio Admission Control RACH Random Access Channel RAN Radio Access Network RANAP RAN Application Part RA-RNTI Random Access RNTI RAT Radio Access Technology RB Radio Bearer RB Resource Block RBC Radio Bearer Control RBG Radio Bearer Group RBS Radio Base Station RET Remote Electrical Tilt RF Radio Frequency RFC Request For Comment RLC Radio Link Control RM Rate Matching RNC Radio Network Controller RNL Radio Network Layer RNTI Radio Network Temporary Identifier ROHC Robust Header Compression ROP Recording Output Periods RPLMN Registered PLMN RRC Radio Resource Control RRM Radio Resource Management RRU Radio Remote Unit RS Reference Symbols RS Reference Signal RSN Retransmission SN RT Real Time RTCP RTP Control Protocol RTP Real Time Transport Protocol


LZT 123 8958 R1A © Ericsson 2009 - 291 -

RTSP Real Time Streaming Protocol RU Resource Unit RX Receiver S1-MME S1 for the control plane S1-U S1 for the user plane SAE System Architecture Evolution SAP Service Access Point SB Scheduling Block SBC Session Border Controller SBG Session Border Gateway SCCH Shared Control Channel SCCP Signaling Connection Control Part SCEP Simple Certificate Enrolment Protocol SC-FDMA Single Carrier – Frequency Division Multiple Access SCH Synchronization Channel S-CSCF Serving CSCF SCTP Streaming Control Transmission Protocol SDF Service Data Flow SDH Synchronous Digital Hierarchy SDMA Spatial Division Multiple Access SDP Session Description Protocol SDU Service Data Unit SeGW Security Gateway SEM Spectrum Emission Mask SFN System Frame Number SFP Small Form factor Pluggable S-FTP Secure File transfer protocol SGSN Serving GPRS Support Node S-GW Serving Gateway SI System Information SIB System Information Block SIP Session Initiation Protocol SI-RNTI System Info RNTI SISO Single Input Single Output SLA Service Level Agreement SLO Service Level Objectives SM Session Management SMO Software Manager Organizer SMRS Software Management Repository SMS Short Message Service SN Sequence Number SNF Service Network Framework SNR Signal to Noise Ratio SON Self Organizing Networks SOX Simple Outline XML S-PARC Selective PARC SPID Subscriber Profile ID for RAT/Frequency Priority SQL Structured Query Language SR Scheduling Request SRB Signaling Radio Bearer SRVCC Single Radio Voice Call Continuity S-SCH Secondary Synchronization Channel


- 292 - © Ericsson 2009 LZT 123 8958 R1A

SSH Secure Shell SSL Secure Sockets Layer SSLIOP IIOP over SSL SU Scheduling Unit SU-MIMO Single-User MIMO SW Soft Ware TA Tracking Area TAS Telephony Application Server TAU Tracking Area Update TB Transport Block TBD To Be Decided TCP Transmission Control Protocol TDD Time Division Duplex TFCI Transport Format Combination Indicator TFP Traffic Forwarding Policy TFT Traffic Flow Template TLP TEMS LinkPlanner TM Transparent Mode TMA Tower Mounted Amplifier TMO T-Mobile International AG TNL Transport Network Layer TSP Ericsson Telecom Server Platform TTI Transmission Time Interval TX Transmit UE User Equipment UETR UE TRace UL Uplink UL-SCH Uplink Shared Channel UM Unacknowledged Mode UMTS Universal Mobile Telecommunication System UP User Plane UPE User Plane Entity U-plane User plane UpPTS Uplink Pilot Time Slot URA UTRAN Routing Area UTRA UMTS Terrestrial Radio Access UTRAN UMTS Terrestrial Radio Access Network VoIP Voice over IP VPLMN Visited PLMN VRB Virtual Resource Block WAP Wireless Access Protocol WAPECS Wireless Access Policy for Electronic Communications Services WCDMA Wideband Code Division Multiple Access WDM Wavelength Division Multiplexing X2-C X2-Control plane X2-U X2-User plane XML Extensible Markup Language

Documents

LTE Protocols and Procedures - ST3 Telkomalfin.dosen.st3telkom.ac.id/.../12/LTE-Protocols-and-Procedures.pdf · LTE Protocols and Procedures ... the HSS provides support to the call