LTE Protocols and Procedures
LZT 123 8958 R1A © Ericsson 2009 - 1 -
LTE Protocols and Procedures
STUDENT BOOK LZT 123 8958 R1A
LTE Protocols and Procedures
- 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 .
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 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
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 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
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 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
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 10 - © Ericsson 2009 LZT 123 8958 R1A
Intentionally Blank
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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
LTE Protocols and Procedures
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
Control Plane User Plane
Transport Network User Plane
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.
LTE Protocols and Procedures
- 22 - © Ericsson 2009 LZT 123 8958 R1A
S1-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
Control Plane User Plane
Transport Network User Plane
Transport Network User Plane
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)
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 26 - © Ericsson 2009 LZT 123 8958 R1A
Intentionally Blank
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 28 - © Ericsson 2009 LZT 123 8958 R1A
Intentionally Blank
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 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
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 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”.
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 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
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 38 - © Ericsson 2009 LZT 123 8958 R1A
Intentionally Blank
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 40 - © Ericsson 2009 LZT 123 8958 R1A
Intentionally Blank
LTE Protocols and Procedures
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
Serviceaccessibilityperformance
Serviceaccessibilityperformance
Serviceretainabilityperformance
Serviceretainabilityperformance
Serveability performance
Provider (operator)
Service security
performance
Service security
performance
Quality of Service
Network Performance
Figure 3-2. How is Network QoS defined?.
LTE Protocols and Procedures
- 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
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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 )
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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
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
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
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
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)
LTE Protocols and Procedures
- 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).
LTE Protocols and Procedures
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).
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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.
Figure 4-1 Objectives
LTE Protocols and Procedures
- 56 - © Ericsson 2009 LZT 123 8958 R1A
Intentionally Blank
LTE Protocols and Procedures
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
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 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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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;
LTE Protocols and Procedures
- 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
LTE Protocols and Procedures
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
System InfoAquisition
Cell Selection
Paging Reception
Connected Mode
Mobility
AS Security RRC Connection
RB Managementv
Measurement Reporting
RRC
System InfoAquisition
Cell Selection
Paging Reception
Connected Mode
Mobility
AS Security RRC Connection
RB Managementv
Measurement Reporting
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.
LTE Protocols and Procedures
- 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)
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
LZT 123 8958 R1A © Ericsson 2009 - 69 -
CELL SELECTION
Stored Information Cell Selection
Initial Cell Selection
Cell Selection when leaving connected mode
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
Cell Selection when leaving connected mode
Cell Selection when leaving connected mode
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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:
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 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
LTE Protocols and Procedures
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)
LTE Protocols and Procedures
- 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
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 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)
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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.
Figure 5-1 Objectives
LTE Protocols and Procedures
- 92 - © Ericsson 2009 LZT 123 8958 R1A
Intentionally Blank
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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
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
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
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.
LTE Protocols and Procedures
- 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
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 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
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 104 - © Ericsson 2009 LZT 123 8958 R1A
Intentionally Blank
LTE Protocols and Procedures
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)
Figure 6-1 Objectives
LTE Protocols and Procedures
- 106 - © Ericsson 2009 LZT 123 8958 R1A
Intentionally Blank
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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
lower layers(i.e. MAC sub layer and physical layer)
upper layer (i.e. RRC layer or PDCP sub layer)
upper layer (i.e. RRC layer or PDCP sub layer)
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
lower layers(i.e. MAC sub layer and physical layer)
upper layer (i.e. RRC layer or PDCP sub layer)
upper layer (i.e. RRC layer or PDCP sub layer)
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.
LTE Protocols and Procedures
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).
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 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
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 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
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 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
Receiving sideTransmitting side
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).
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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
Receiving sideTransmitting side
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
Receiving sideTransmitting side
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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
LZT 123 8958 R1A © Ericsson 2009 - 125 -
Figure 6-25 illustrates MAC structure on the UE side.
Random Access Control
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)
LTE Protocols and Procedures
- 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
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 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
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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)
LTE Protocols and Procedures
- 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/F/Lsub-header
R/R/E/LCID/F/Lsub-header
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.
LTE Protocols and Procedures
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
Buffer Size #1 Buffer Size #2
Buffer Size #2 Buffer Size #3
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 136 - © Ericsson 2009 LZT 123 8958 R1A
prachConfigurationIndexpreambleInitialReceivedTargetPowerpowerRampingStepRa-PreambleIndexra-ResponseWindowSizePreambleTransmissionMax
Random Access Control
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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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
Receiver processing Receiver processing
ACKACK
621 621
2
Receiver processing Receiver processing
NAK
1 65 9
Receiver processing Receiver processing
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
LTE Protocols and Procedures
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]
LTE Protocols and Procedures
- 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
LTE Protocols and Procedures
LZT 123 8958 R1A © Ericsson 2009 - 141 -
7 S1 Application Protocol – S1 AP
OBJECTIVES
After this chapter the participants will be able to:
1. Explain the S1 interface and the S1 Application Protocol (S1AP) protocol structure.
2. Explain the main functions and procedures of S1AP.
After this chapter the participants will be able to:
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
LTE Protocols and Procedures
- 142 - © Ericsson 2009 LZT 123 8958 R1A
Intentionally Blank
LTE Protocols and Procedures
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
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.).
(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 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.
LTE Protocols and Procedures
- 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).
LTE Protocols and Procedures
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
TransportNetworkLayer
GTP-U
UDP
IP
Data link layer
Physical layer
User PlanePDUs
SCTP
IP
Data link layer
Physical layer
RadioNetworkLayer
Control Plane User Plane
Transport Network User Plane
Transport Network User Plane
S1-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
Control Plane User Plane
Transport Network User Plane
Transport Network User Plane
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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 .
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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 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
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
Unsuccessful outcome Response Message
Successful OutcomeResponse Message
Initiating MessageElementary Procedure, 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
Unsuccessful outcome Response Message
Successful OutcomeResponse Message
Initiating MessageElementary Procedure, class 1
Figure 7-8. S1AP Elementary Procedures – Class 1
LTE Protocols and Procedures
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
Initiating MessageElementary procedure, class 2
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
Initiating MessageElementary procedure, class 2
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
Initiating MessageElementary procedure, class 2
Figure 7-10 S1 AP Elementary Procedures – Class 2
LTE Protocols and Procedures
- 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
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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".
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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".
LTE Protocols and Procedures
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
INITIAL CONTEXT SETUP REQUEST
INITIAL CONTEXT SETUP RESPONSE
eNBeNB
MMEMME
INITIAL CONTEXT SETUP REQUEST
INITIAL CONTEXT SETUP FAILURE
eNBeNB
MMEMME
INITIAL CONTEXT SETUP REQUEST
INITIAL CONTEXT SETUP RESPONSE
eNBeNB MMEMME
INITIAL CONTEXT SETUP REQUEST
INITIAL CONTEXT SETUP RESPONSE
eNBeNB
MMEMME
INITIAL CONTEXT SETUP REQUEST
INITIAL CONTEXT SETUP FAILURE
eNBeNB MMEMME
INITIAL CONTEXT SETUP REQUEST
INITIAL CONTEXT SETUP FAILURE
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
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
LZT 123 8958 R1A © Ericsson 2009 - 167 -
MMEMME
UE CONTEXT RELEASE REQUEST
eNBeNB
MMEMME
UE CONTEXT RELEASE COMMAND
UE CONTEXT RELEASE COMPLETE
eNBeNB
A. UE Initiated
B. MME Initiated
MMEMME
UE CONTEXT RELEASE REQUEST
eNBeNB
MMEMME
UE CONTEXT RELEASE COMMAND
UE CONTEXT RELEASE COMPLETE
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.
LTE Protocols and Procedures
- 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
UE CONTEXT MODIFICATION REQUEST
UE CONTEXT MODIFICATION RESPONSE
eNBeNB
MMEMME
UE CONTEXT MODIFICATION REQUEST
UE CONTEXT MODIFICATION FAILURE
eNBeNB
MMEMME
UE CONTEXT MODIFICATION REQUEST
UE CONTEXT MODIFICATION RESPONSE
eNBeNB
MMEMME
UE CONTEXT MODIFICATION REQUEST
UE CONTEXT MODIFICATION FAILURE
eNBeNB
Figure 7-16 UE Context Modification
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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
HANDOVER PREPARATION FAILURE
source eNBsource eNB
MMEMME
HANDOVER REQUIRED
HANDOVER COMMAND
source eNBsource eNB
MMEMME
HANDOVER REQUIRED
HANDOVER PREPARATION FAILURE
source eNBsource eNB
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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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
target eNBtarget eNB
MMEMME
HANDOVER REQUEST
HANDOVER REQUEST ACKNOWLEGE
target eNBtarget eNB
MMEMME
HANDOVER REQUEST
HANDOVER FAILURE
target eNBtarget eNB
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 .
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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
target eNBtarget eNB
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.
LTE Protocols and Procedures
- 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
PATH SWITCH REQUEST ACKNOWLEDGE
eNBeNB
MMEMME
PATH SWITCH REQUEST
PATH SWITCH REQUEST FAILURE
eNBeNB
MMEMME
PATH SWITCH REQUEST
PATH SWITCH REQUEST ACKNOWLEDGE
eNBeNB
MMEMME
PATH SWITCH REQUEST
PATH SWITCH REQUEST FAILURE
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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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
HANDOVER CANCEL ACKNOWLEDGE
source eNBsource eNB MMEMME
HANDOVER CANCEL
HANDOVER CANCEL ACKNOWLEDGE
source eNBsource eNB
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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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
NAS NON DELIVERY INDICATION
eNBeNB MMEMME
NAS NON DELIVERY INDICATION
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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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.
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.
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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
ENB CONFIGURATION UPDATE
ENB CONFIGURATION UPDATE ACKNOWLEDGE
eNBeNB
MMEMME
ENB CONFIGURATION UPDATE
ENB CONFIGURATION UPDATE FAILURE
eNBeNB
MMEMME
ENB CONFIGURATION UPDATE
ENB CONFIGURATION UPDATE ACKNOWLEDGE
eNBeNB
MMEMME
ENB CONFIGURATION UPDATE
ENB CONFIGURATION UPDATE FAILURE
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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 194 - © Ericsson 2009 LZT 123 8958 R1A
MME CONFIGURATION UPDATE
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
MME CONFIGURATION UPDATE
MME CONFIGURATION UPDATE ACKNOWLEDGE
eNBeNB
MMEMME
MME CONFIGURATION UPDATE
MME CONFIGURATION UPDATE FAILURE
eNBeNB
MMEMME
MME CONFIGURATION UPDATE
MME CONFIGURATION UPDATE ACKNOWLEDGE
eNBeNB
MMEMME
MME CONFIGURATION UPDATE
MME CONFIGURATION UPDATE FAILURE
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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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.
The procedure uses non-UE associated signaling.
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.
The procedure uses non-UE associated signaling.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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
TRACE FAILURE INDICATION
eNBeNB MMEMME
TRACE START
TRACE FAILURE INDICATION
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.
Interactions with other procedures:
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.
LTE Protocols and Procedures
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.
Interactions with other procedures:
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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
WRITE-REPLACE WARNING REQUEST
WRITE-REPLACE WARNING RESPONSE
eNBeNB MMEMME
WRITE-REPLACE WARNING REQUEST
WRITE-REPLACE WARNING RESPONSE
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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
LZT 123 8958 R1A © Ericsson 2009 - 209 -
MME CONFIGURATION TRANSFER
MMEMME
MME CONFIGURATION TRANSFER
eNBeNB MMEMME
MME CONFIGURATION TRANSFER
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.
LTE Protocols and Procedures
- 210 - © Ericsson 2009 LZT 123 8958 R1A
Intentionally Blank
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 212 - © Ericsson 2009 LZT 123 8958 R1A
Intentionally Blank
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 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
TransportNetworkLayer
GTP-U
UDP
IP
Data link layer
Physical layer
User PlanePDUs
SCTP
IP
Data link layer
Physical layer
RadioNetworkLayer
Control Plane User Plane
Transport Network User Plane
Transport Network User Plane
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
Control Plane User Plane
Transport Network User Plane
Transport Network User Plane
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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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
ENB CONFIGURATION UPDATE FAILURE
ENB CONFIGURATION UPDATE ACKNOWLEDGE
ENB CONFIGURATION UPDATE
ENB CONFIGURATION UPDATE
X2 SETUP FAILUREX2 SETUP RESPONSEX2 SETUP REQUESTX2 SETUP
HANDOVER PREPARATION FAILURE
HANDOVER REQUEST ACKNOWLEDGE
HANDOVER REQUESTHANDOVER PREPARATION
Unsuccessful outcome Response Message
Successful OutcomeResponse Message
Initiating MessageElementary Procedure, class 1
RESET RESPONSERESET REQUESTRESET
RESOURCE STATUS FAILURE
RESOURCE STATUS RESPONSE
RESOURCE STATUS REQUEST
RESOURCE STATUS REPORTING INITIATION
ENB CONFIGURATION UPDATE FAILURE
ENB CONFIGURATION UPDATE ACKNOWLEDGE
ENB CONFIGURATION UPDATE
ENB CONFIGURATION UPDATE
X2 SETUP FAILUREX2 SETUP RESPONSEX2 SETUP REQUESTX2 SETUP
HANDOVER PREPARATION FAILURE
HANDOVER REQUEST ACKNOWLEDGE
HANDOVER REQUESTHANDOVER PREPARATION
Unsuccessful outcome Response Message
Successful OutcomeResponse Message
Initiating MessageElementary Procedure, class 1
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
Initiating MessageElementary procedure, class 2
ERROR INDICATIONERROR INDICATION
RESOURCE STATUS UPDATERESOURCE STATUS REPORTING
UE CONTEXT RELEASEUE CONTEXT RELEASE
SN STATUS TRANSFERSN STATUS TRANSFER
HANDOVER CANCELHANDOVER CANCEL
LOAD INFORMATIONLOAD INDICATION
Initiating MessageElementary procedure, class 2
Figure 8-9 X2AP Elementary Procedures - Class 2
LTE Protocols and Procedures
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.
The procedure uses UE-associated signaling.
Target eNBTarget eNB
HANDOVER REQUEST
HANDOVER REQUEST ACKNOWLEDGE
source eNBsource eNB
Target eNBTarget eNB
HANDOVER REQUEST
HANDOVER PREPARATION FAILURE
source eNBsource eNB
Target eNBTarget eNB
HANDOVER REQUEST
HANDOVER REQUEST ACKNOWLEDGE
source eNBsource eNB Target eNBTarget eNB
HANDOVER REQUEST
HANDOVER REQUEST ACKNOWLEDGE
source eNBsource eNB
Target eNBTarget eNB
HANDOVER REQUEST
HANDOVER PREPARATION FAILURE
source eNBsource eNB Target eNBTarget eNB
HANDOVER REQUEST
HANDOVER PREPARATION FAILURE
source eNBsource eNB
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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.
The procedure uses UE-associated signaling.
LTE Protocols and Procedures
LZT 123 8958 R1A © Ericsson 2009 - 227 -
Target eNBTarget eNB
SN STATUS TRANSFER
source eNBsource eNB Target eNBTarget eNB
SN STATUS TRANSFER
source eNBsource eNB
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.
LTE Protocols and Procedures
- 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.
The procedure uses UE-associated signaling.
Target eNBTarget eNB
UE CONTEXT RELEASE
source eNBsource eNB Target eNBTarget eNB
UE CONTEXT RELEASE
source eNBsource eNB
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.
LTE Protocols and Procedures
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.
The procedure uses UE-associated signaling.
Target eNBTarget eNB
HANDOVER CANCEL
source eNBsource eNB Target eNBTarget eNB
HANDOVER CANCEL
source eNBsource eNB
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.
LTE Protocols and Procedures
- 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.
The procedure uses non UE-associated signaling.
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.
LTE Protocols and Procedures
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.
The procedure uses non UE-associated signaling.
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
LTE Protocols and Procedures
- 232 - © Ericsson 2009 LZT 123 8958 R1A
Successful Operation
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.
Unsuccessful Operation
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.
LTE Protocols and Procedures
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.
The procedure uses non UE-associated signaling.
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.
LTE Protocols and Procedures
- 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.
The procedure uses non UE-associated signaling.
eNB2eNB2
ENB CONFIGURATION UPDATE
ENB CONFIGURATION UPDATEACKNOWLEDGE
eNB1eNB1
eNB2eNB2
ENB CONFIGURATION UPDATE
ENB CONFIGURATION UPDATEFAILURE
eNB1eNB1
eNB2eNB2
ENB CONFIGURATION UPDATE
ENB CONFIGURATION UPDATEACKNOWLEDGE
eNB1eNB1 eNB2eNB2
ENB CONFIGURATION UPDATE
ENB CONFIGURATION UPDATEACKNOWLEDGE
eNB1eNB1
eNB2eNB2
ENB CONFIGURATION UPDATE
ENB CONFIGURATION UPDATEFAILURE
eNB1eNB1 eNB2eNB2
ENB CONFIGURATION UPDATE
ENB CONFIGURATION UPDATEFAILURE
eNB1eNB1
Figure 8-17 eNB Configuration Update
Successful Operation
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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 236 - © Ericsson 2009 LZT 123 8958 R1A
Unsuccessful Operation
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.
LTE Protocols and Procedures
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.
The procedure uses non UE-associated signaling.
eNB2eNB2
RESOURCE STATUS REQUEST
RESOURCE STATUS RESPONSE
eNB1eNB1
eNB2eNB2
RESOURCE STATUS REQUEST
RESOURCE STATUS FAILURE
eNB1eNB1
eNB2eNB2
RESOURCE STATUS REQUEST
RESOURCE STATUS RESPONSE
eNB1eNB1
eNB2eNB2
RESOURCE STATUS REQUEST
RESOURCE STATUS FAILURE
eNB1eNB1 eNB2eNB2
RESOURCE STATUS REQUEST
RESOURCE STATUS FAILURE
eNB1eNB1
Figure 8-18 nitiation
Successful Operation
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,
LTE Protocols and Procedures
- 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.
Unsuccessful Operation
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”.
LTE Protocols and Procedures
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.
The procedure uses non UE-associated signaling.
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.
LTE Protocols and Procedures
- 240 - © Ericsson 2009 LZT 123 8958 R1A
Intentionally Blank
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 242 - © Ericsson 2009 LZT 123 8958 R1A
Intentionally Blank
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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..
LTE Protocols and Procedures
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
Figure 10-1 Objectives
LTE Protocols and Procedures
- 246 - © Ericsson 2009 LZT 123 8958 R1A
Intentionally Blank
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 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
IE type and referencePIE/Group Name
Figure 10-4 X2 Handover Request message
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 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 ,
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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
IE type and referencePIE/Group Name
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
IE type and referencePIE/Group Name
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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
Connectionestablishment/release
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.
LTE Protocols and Procedures
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.
LTE Protocols and Procedures
- 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
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 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
LTE Protocols and Procedures
LZT 123 8958 R1A © Ericsson 2009 - 271 -
11 Appendix
LTE Protocols and Procedures
- 272 - © Ericsson 2009 LZT 123 8958 R1A
Intentionally Blank
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 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
15. Update Bearer Request
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
6. Create Bearer Request
4a. Create Bearer Response
4. Create Bearer Request
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.
LTE Protocols and Procedures
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
8. Create Bearer Request
7. Forward Relocation Response
PDN GW
8a. CreateBearer Response
Uplink and DownlinkUser Plane PDUs
Target Serving GW
4. Create Bearer Request
4a. Create Bearer Response
6. Create Bearer Request
6a. Create Bearer Response
Figure 11-2 E-UTRAN TO UTRAN IU MODE INTER RAT HO, Preparation phase
LTE Protocols and Procedures
- 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
7. Update Bearer Request
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
LTE Protocols and Procedures
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
8. Create Bearer Request
7. Forward Relocation Response
PDN GW
8a. Create Bearer Response
Uplink and Downlink User Plane PDUs
Target Serving GW
4. Create Bearer Request
4a. Create Bearer Response
6 Create Bearer Request
6a. Create Bearer Response
Figure 11-4 E-UTRAN TO GERAN A/GB MODE INTER RAT HANDOVER, Preparation phase
LTE Protocols and Procedures
- 278 - © Ericsson 2009 LZT 123 8958 R1A
EXECUTION PHASE
UE
Source eNodeB Target BSS 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. GERAN A/Gb Access Procedures
5. XID Response
6. PS Handover Complete
8. Forward Relocation Complete8a. Forward Relocation Complete Acknowledge
9. Update Bearer Request
11. Update Bearer Response
Uplink and Downlink User Plane PDUs
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
LTE Protocols and Procedures
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)
Semi-Persistent Scheduling C-RNTI
N/AN/ATriggering of PDCCH ordered random accessC-RNTI
DCCH, DTCHDL-SCH, UL-SCH
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-Persistent Scheduling C-RNTI
DCCH, DTCHDL-SCH, UL-SCH
Semi-Persistently scheduled unicast transmission (activation, reactivation and retransmission)
Semi-Persistent Scheduling C-RNTI
N/AN/ATriggering of PDCCH ordered random accessC-RNTI
DCCH, DTCHDL-SCH, UL-SCH
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
LTE Protocols and Procedures
- 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.
LTE Protocols and Procedures
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).
LTE Protocols and Procedures
- 282 - © Ericsson 2009 LZT 123 8958 R1A
Intentionally Blank
LTE Protocols and Procedures
LZT 123 8958 R1A © Ericsson 2009 - 283 -
12 Abbreviations
LTE Protocols and Procedures
- 284 - © Ericsson 2009 LZT 123 8958 R1A
Intentionally Blank
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 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
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 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
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 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
LTE Protocols and Procedures
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
LTE Protocols and Procedures
- 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