LTE System Structure and Signalling

Course 502
LTE Long Term Evolution

Architecture and Connection Processing
August, 2010
Course 502 v1.1 (c)2010 Scott Baxter
Page 1
Course Outline
LTE Network Architecture and Networking Components Air Interface Quick Review Standard Interfaces and key protocol stacks Radio System Identifiers Tunnels, Connections and Bearers System Acquisition and Synchronization Idle Mode and Paging g g UE Attach to the Network (Registration procedures) Connected Mode and UE States Network Performance Evaluation and Optimization issues Mobility, Interoperability and Handover Management Lets setup and process various LTE call flows and scenarios Review, Summary and conclusion
Course 502 v1.1 (c)2010 Scott Baxter Page 2
August, 2010
LTE Network Architecture and Networking Components
August, 2010
Course 502 (c)2010 Scott Baxter
Page 3
1. LTE Network Architecture and Networking Components

1-1 Quick Review of the Air Interface 1-2 1 2 The Evolved Packet System (EPS) and Evolved Packet Core (EPC) overview 1-3 Networking Functional Elements (eNB; MME; SGW; PGW; PCRF; HSS) Remarks
August, 2010
Page 4
The LTE Air Interface A Quick Review
August, 2010
Page 5
The LTE Downlink and Uplink Signals

The LTE signal uses variations of Orthogonal Frequency Division Multiplexing on both its uplink and downlink The LTE downlink signal uses dozens to even thousands of thin carriers spaced 15 kHz, covering the operators licensed spectrum Different users users data can be carried on different subsets of the carriers, using dynamic scheduling to maintain QoS the Operator sets the number of carriers to fit in its spectrum Modulation type for each user is dynamically adjusted from QPSK to even 64QAM in response to instantaneous conditions The LTE uplink signal of each user is dynamically assigned to use a small or large g fraction of the uplink p spectrum p to meet Q QoS g goals OFDMs spectral efficiency is higher than CDMA or HSPA Multiple antenna techniques can be used on both uplink and downlink to multiply link throughput rates up to theoretically 4 times
August, 2010
Page 6
Advanced Technologies of LTE

OFDM
Pow wer Frequency
OFDM, OFDMA
Orthogonal Frequency Division Multiplexing; g Frequency q y Division Muliple p Access Orthogonal The signal consists of many (from dozens to thousands) of thin carriers carrying symbols In O OFDMA, , the e symbols sy bo s a are e for o multiple u p e use users s OFDM provides dense spectral efficiency and robust resistance to fading, with great flexibility of use
MIMO
MIMO
Multiple Input Multiple Output An An ideal companion to OFDM OFDM, MIMO allows exploitation of multiple antennas at the base station and the mobile to effectively multiply g p for the base station and users the throughput
August, 2010
Page 7
The LTE Downlink Uses OFDMA
In generic OFDM, users are assigned fractions of the total subcarriers available on a stable stable, continuing basis OFDMA means Orthogonal Frequency Division Multiple Access OFDMA uses dynamic scheduling to package each users data flow into an appropriate number of subcarriers based on the users user s immediate needs This assures effective utilization of the total capacity of the downlink signal, and good compliance with QoS goals
August, 2010
Page 8
The LTE Uplink Signal
The uplink uses SC-FDMA with some dynamic multiple of 4 15-khz subcarriers to carrier the information Modulation can be QPSK, 16QAM or 64QAM for conditions SC-FDMA has a low Peak-to-Average Power Ratio (PAPR) which provides more transmit power and longer battery life
August, 2010 Course 502 (c)2010 Scott Baxter Page 9
Type 1 Forward Link Frames: For Frequency Division Duplex (FDD)
In Frequency Division Duplex, separate identical blocks of frequencies are available for base stations (eNB) and mobiles (UE) to transmit independently at the same time This frequency division duplex mode is used virtually everywhere in North o t America e ca a and d is st the e most ost p prevalent e a e t mode ode in t the e rest est o of t the e world In FDD mode, LTE radio frames are 10 ms long Each frame is composed of 10 subframes, each 1 ms long Each subframe is composed of two slots, each 0.5 ms long
Type 2 - TDD
In some cases, governments assign a wireless operator a single block of frequencies to use for an LTE system In this case, transmitting and receiving must alternate with each other, like one lane traffic in a construction site The forward link is transmitted discontinuously, alternating with the reverse link li k on th the same f frequency This arrangement allows effective LTE operation in a small amount of spectrum, but does limit the capacity of the system The Th figure fi shows h th the subdivision bdi i i of f ti time i into t uplink li k and dd downlink li k periods, with the additional requirement of guard periods between
The Building Blocks of the Downlink Signal: Elements and Blocks
One Resource Element is the smallest part of the LTE DL signal Its what one subcarrier can do in just one modulation symbol One Resource Block is the smallest usable piece of the signal Its It what h t 12 subcarriers b i can d do d during i a whole h l slot, l t 0 0.5 5 ms In one slot, a subcarrier normally carries 7 symbols
August, 2010 Course 502 v1.1 (c)2010 Scott Baxter Page 12
Downlink Physical Resources and Mapping
August, 2010
Page 13
Example of Downlink Control Signal Mapping

This figure shows a typical mapping of downlink control signals to the timeslots which carry them Notice the T1, T2, T3, and T4 information which occupies a fixed pattern. By observing these streams the mobile is able to learn the multipleantenna configuration of the base station (eNB) without requiring long layer-3 messages
August, 2010
Page 14
Generic Frame Sequences
Each OFDM symbol y begins g with a cyclic y p prefix, , of duration below:
August, 2010
Page 15
Uplink Physical Resources and Mapping
August, 2010
Page 16
Uplink Format PUCCH 0 or 1
August, 2010
Page 17
UL SC-FDMA Subcarrier Options
On the reverse link, there are two ways to assign subcarrier frequencies to UEs One is Localized Subcarriers, which gives one user a single block of adjacent carriers this can be vulnerable to selective fading, but frequency control is not as critical The other is Distributed Subcarriers this provides superior protection against selective fading this requires very precise frequency control to avoid interference
LTE Physical Signals
August, 2010
Page 19
LTE Physical Channels
August, 2010
Page 20
SISO, MISO, SIMO, MIMO

Single-Input Single-Output is the default mode for radio links over the years, and the baseline for further comparisons. Multiple-Input Single Output provides transmit diversity (recall CDMA2000 OTD) It reduces the total transmit OTD). power required, but does not increase data rate. Its also a delicious Japanese soup. Single-Input Multiple Output is receive diversity. It reduces the necessary SNR but does not increase data rate. Close but no relation to Dr. Ernest Simo, wireless communications expert Multiple-Input Multiple Output is highly effective, using the differences in path characteristics to provide a new dimension to hold additional signals and increase the total data speed.
SU-MIMO, MU-MIMO, Co-MIMO

Single-User MIMO allows the single user to gain throughput by having multiple essentially independent paths for data Multi-User MIMO allows multiple users on the reverse link to transmit simultaneously to the eNB eNB, increasing system capacity Cooperative MIMO allows a user to receive its signal g from multiple eNBs in combination, increasing reliability and throughput
August, 2010
Page 22
The Evolved Packet System (EPS) and Evolved Packet Core (EPC) Overview
August, 2010
Page 23
The Evolved Packet System and the Evolved Packet Core

E-UTRAN
eNB
Inter-cell RMM RB Control Connection Mobility Ctrl Radio Admission Ctrl. NAS Security eNB Measurement Config. & Provision Dynamic Resource Allocation (scheduler) RRC PDCP RLC MAC Idle State Mobility Handling EPS Bearer Control
EPC
MME
S-GW
Mobility Anchoring
P-GW
UE IP Address Allocation Packet Filtering
Internet
S1
PHY
August, 2010
Page 24
Networking Functional Elements (eNB; MME; SGW; PGW; PCRF; HSS)
August, 2010
Page 25
Networking Functional Elements (eNB; MME; Anchors/Gateways, PCRF; HSS)

Legacy GSM radio Networks
GERAN UTRAN
WCDMA /HSPA radio Networks
Gb
Policy and Charging Rules Function
SGSN GPRS CORE Iu S3 S5a S7 S5b S4

Ref Pt.
PCRF Rx+
Home Subscriber Server Super HLR
Mobility Management Entity User Plane Entity
S6a 3GPP Anchor SAE Anchor
HSS SGi
Operators IP Services
Evolved RAN: eNB

LTE radio Networks
S1
Ref Pt.
MME UPE
Inter Access System Anchor
IASA
Uu
E l dP Evolved Packet k tC Core

S2a
1xRTT, 1 RTT CDMA2000, CDMA2000 EV-DO networks
S2b,c
WLAN 3GPP IP access
Page 26
Non-3GPP IP access
August, 2010
Course S2K 5000 v1.5 (c)2010 Scott Baxter
Functions of Key Network Elements

NAS signaling Mobility between 3GPP Ans Idle mode UE connectivity Gb P-GW and S-GW selection SGSN selection at HO Iu Authentication Bearer Establishment
GERAN UTRAN
Mobility y Anchor Packet Routing Idle Mode GPRS packet buffering CORE SGSN & DL initiation Legal Interception
S12
UE IP Address allocation Packet Screening g & Rules Function Policy and Charging Filtering Policy Enforcement PCRF $Charging Support Legal Interception
WCDMA /HSPA radio Networks Mobility Management Entity User Plane Entity
S11
S8a
S3
S7
Rx+
S4
S6a PDN
Gateway
HSS SGi
Evolved RAN: eNB

LTE radio Networks
S1-MME MME
UPE
S10
Serving Gateway
Operators IP Services
IASA
Uu
S1-U

S2a S2b,c
Non-3GPP IP access
WLAN 3GPP IP access

Page 27
August, 2010
Integration of LTE, EVDO and HSPA
Home Subscriber Server (super HLR)
Gateway
Mobility Management g Entity Packet Data Serving Node Serving Gateway y Support Node Enhanced Node B
August, 2010
Page 28
LTE Standard Interfaces and Key Protocol Stacks
August, 2010
Page 29
2. Standard Interfaces and Key Protocol Stacks

2-1 Interfaces (Uu, X2, S1, S5, S8, S11) 2-2 2 2 Protocol Stacks (Physical (Physical, MAC MAC, RLC RLC, PDCP PDCP, RRC RRC, NAS Layers)
August, 2010
Page 30
Key Network Interfaces

GERAN UTRAN
Gb Iu S12 SGSN GPRS CORE S3 S11
PCRF S7 Rx+
WCDMA /HSPA radio Networks Mobility Management Entity User Plane Entity
S8a
S4
S6a
PDN Gateway
HSS SGi
Evolved RAN: eNB

LTE radio Networks
S1-MME MME
UPE
S10
Serving Gateway
Operator s Operators IP Services
IASA
Uu
S1-U

S2a S2b,c
Non-3GPP N 3GPP IP access
WLAN 3GPP IP access

Page 31
August, 2010
Key Network Interfaces (1)

Uu The LTE physical layer interface connecting the UE with the eNodeB on both uplink and downlink directions (GTP-U Protocol) S1-MME S1 MME The Th Control C t l Pl Plane ( (command d and d control) t l) connection ti from the eNB to the MME managing user mobility (GTP) S1-U The User Plane (traffic-carrying) connection from the eNB to the serving gateway (GTP protocol) S2a PDN link to trusted non-3GPP networks (CDMA EVDO) (based on proxy mobile IP, can use client mobile IP FA mode) S2b PDN li link kt to serving i gateway t f for an untrusted t t d network t k GTP (based on proxy mobile IP) S2c PDN link to trusted non-3GPP network (CDMA, EVDO) GTP (based on client mobile co-location) S3 Connection between 2G/3G SGSN and SAE MME (GTP) S4 -- Provides user plane connection and mobility support between a 2G/3G SGSN and the SGW (based on Gn reference point defined between SGSN and GGSN) (GTP protocol)

S5 Provides user plane tunneling and tunnel management between SGW and PDN GW. Handles S GW relocation for UE mobility if the S GW must connect to a non-collocated PDN GW. S5 is the intra PLMN variant of S8. S6a Carries subscription and authentication data between the MME and the HSS (often called a super HLR) S7 Carries policy and charging rules information between the PDN gateway and the PCRF S8 Inter-PLMN reference point providing user and control plane between the Serving GW in the VPLMN and the PDN GW in the HPLMN. S8 is the inter PLMN variant of S5. S9 - Transfers T f (QoS) (Q S) policy li and d charging h i control t li information f ti between Home/Visited PCRF to support local breakout function. S10 -- Reference point between MMEs for MME relocation and MME to MME information transfer

S11 -- Reference point between MME and Serving GW S12 Connection from UTRAN to Serving GW during user plane Direct Tunnel. Based on Iu-u/Gn-u ref. point and GTP-U protocol SGSN-to-UTRAN or SGSN-to-GGSN. Optional by Operator. S13 Enables UE identity check between MME and EIR SGi -- Reference point between PDN GW and packet data network. Packet data network can be external public, private, or p p packet data network, , e.g. g for p provision of IMS. intra-operator Corresponds to Gi interface for 3GPP accesses. Rx -- The Rx reference point resides between the AF and the PCRF in the TS 23.203 [6]. Wn* The reference point between the Untrusted Non-3GPP IP Access and the ePDG. Traffic on this interface for a UE initiated tunnel must be forced towards the ePDG.
August, 2010
Page 34

X2 -- The X2 interface can provide inter-connection 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. SBc:- Reference point between CBC and MME for warning message delivery and control functions
August, 2010
Page 35
Radio Control Plane Protocol Stack

Layers Non-Access Stratum Radio Resource Control Packet Data Convergence Protocol Radio Link Control Media Access Control Physical UE
NAS RRC PDCP RLC MAC PHY
eNB
RRC PDCP RLC MAC PHY
MME
NAS
CONTROL PLANE
The NAS protocol is used for network attach, authentication, setting up bearers, and mobility management The RRC in eNB makes handover decisions decisions, pages UEs UEs, sends system information, controls UE measurements, assigns cell-level temporary identifiers to UEs, transfers UE contexts in handovers The PDCP compresses/decompresses headers; does ciphering The RLC formats and transports traffic between UE and eNB The MAC layer implements HARQ The Th PHY layer l uses adaptive d ti modulation d l ti and d coding di t to protect t t data from errors and keep rates optimally high
Radio User Plane Protocol Stack

User Plane
Layers Packet Data Convergence Protocol Radio Link Control Media Access Control Physical
UE PDCP RLC MAC PHY eNodeB PDCP RLC MAC PHY
Th The PDCP compresses/decompresses /d headers h d and d does d ciphering The RLC formats and transports traffic between UE and eNB, and implements outer ARQ The MAC layer implements HARQ The PHY layer uses adaptive modulation and coding to protect data from errors and keep rates optimally high
August, 2010
Page 37
Layer-2 Structure for Downlink
August, 2010
Page 38
Layer-2 Structure for Uplink
August, 2010
Page 39
The S1 User Plane

The S1 User Plane Interface (S1-U) connects between the eNB and the S-GW. S GW. It provides: Guaranteed delivery of user plane PDUsff The transport network layer is built on IP transport and GTP-U GTP U is used on top of UDP/IP to carry the user plane PDUs between the eNB and the S-GW
S1 Interface User Plane (eNB S GW) (eNBS-GW)
User Plane PDUs
GTP-U UDP IP Data Link Layer Physical Layer
August, 2010
Page 40
The S1 Control Plane

The S1 control plane interface (S1-MME) is defined between the eNB and the MME The transport network layer is built on IP transport, like the user plane However, However for the reliable transport of signaling messages SCTP is added on top of IP The application layer signaling protocol is called S1-AP ( (S1 Application pp Protocol) )
S1 Interface Control Plane (eNBMME)

User Plane PDUs
SCTP IP Data Link Layer Physical Layer
August, 2010
Page 41
S1 Interface Signaling Procedures

E-RAB signaling: Setup, Modification, Release, Release Indication Handover signaling: Preparation, Resource Allocation, Completion, Cancellation Transfers: eNB Status, MME Status Paging procedures NAS transport procedures: Initial UE Msg Msg., UL/DL NAS transport LPPa Transport: UE and Non-UE Assoc. UL/DL transport Error Indication procedure: eNB initiated, MME initiated Reset procedure: eNB initiated initiated, MME initiated Initial Context Setup; UE Context Modification S1 Setup procedure; eNB, eNB MME Configuration Update procedure; Location Reporting: Reporting Control, Report, Report Failure Indication Overload: Start, Stop, Write Replace Warning procedures Direct Di t I Information f ti T Transfer: f eNB NB C Configuration, fi ti MME C Configuration fi ti S1 CDMA2000 Tunneling: DL S1 CDMA2000, UL S1 CDMA2000
SCTP handles Application Layer Messages

The SCTP (Stream Control Transmission Protocol) layer provides the guaranteed delivery of application layer messages. In the transport IP layer point-to-point transmission is used to deliver the signaling PDUs. A single SCTP association per S1-MME S1 MME interface instance is used with one pair of stream identifiers for S1-MME common procedures. Only a few pairs of stream identifiers should be used for S1-MME dedicated procedures. MME communication context identifiers that are assigned by the MME for S1-MME dedicated procedures and eNB communication context identifiers that are assigned by the eNB for S1-MME dedicated procedures shall be used to distinguish UE specific S1 S1MME signaling transport bearers. The communication context identifiers are conveyed in the respective S1-AP messages.
August, 2010
Page 43
The X2 Interface
eNodeB X2AP SCTP IP L2 L1 eNodeB X2AP SCTP IP L2 L1 eNodeB GTP-U UDP IP L2 L1 eNodeB GTP-U UDP IP L2 L1
X2 Control Plane
X2 User Plane
The X2 Interface connects eNodeBs with one another Usually routed via the same transport connection used by S1 used only for control plane data but during handover it can be used temporarily p y for user data forwarding g X2 control plane uses SCTP (Stream Control Transmission Protocol) for reliable delivery of control data between eNBs X2 user plane is sufficiently reliable using ordinary UDP X2AP (X2 Application Protocol) functions are Management of Intra-LTE mobility (HO msg. over X2 interface) Load management for inter-cell interference coordination by sharing resource, load, and traffic details Setting up and resetting the X2 interface
X2 Protocol Stack
The transport layer over X2 is IP based. GTP-U GTP U protocol over UDP over IP transports 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 stream is used for DL data forwarding from the source eNB to the target eNB. The UL stream is used for UL data forwarding g 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 eNB.
August, 2010 Course 502 v1.1 (c)2010 Scott Baxter
Transport network layer for d data streams over X2
Page 45
GTP-U Protocol over X2 Interface

The UDP path protocol is used The GTP-U UDP user-plane port number is 2152 eNBs over the X2 interface can support fragmentation and assembly of GTP packets at the IP layer An eNB will support IPv6 and/or IPv4. A pair of eNBs may use one or several IP addresses A source eNB sends packets of a given E-RAB to the target eNB IP address ( (received in X2AP) ) This address corresponds to the DL transport bearer of that particular E-RAB. The Transport p Layer y Address in X2AP messages g is a bit string g of a) 32 bits in case of IPv4 address b) 128 bits in case of IPv6 address
August, 2010
Page 46
X2 Control Plane Procedures
August, 2010
Page 47
Handling of Application Protocol Identities

An Application Protocol Identity (AP ID) is allocated when a new UE-associated UE associated logical connection is created in an eNB or an MME. An AP ID uniquely identifies a logical connection for the UE over the S1 or X2 interface within a node (eNB or MME). When it receives a message that has a new AP ID from the sending node, the receiving node stores the AP ID of the sending node for as long as the logical connection lasts The receiving g node assigns g the AP ID to be used to identify y the logical connection for the UE and include it as well as the previously received new AP ID from the sending node, in the first returned message to the sending node In I all ll subsequent b t messages t to and df from sending di node, d AP ID IDs of both sending node and receiving node are included
August, 2010
Page 48
UE-Associated S1 or X2 Connections
Control plane messages (S1AP, X2AP) associated with the UE are sent on the logical S1 or X2 connection. This connection is set up at the first S1/X2AP exchange between peer nodes. The connection is maintained as long as messages are exchanged. The UE-associated logical S1-connection uses the identities MME UE S1AP ID and eNB UE S1AP ID. The UE-associated logical X2-connection uses the identities Old eNB UE X2AP ID and New eNB UE X2AP ID. When an MME or eNB receives a UE associated S1/X2AP message it retrieves ti th the associated i t d UE b based d on S1/X2AP ID. ID UE-associated signaling is an exchange of S1/X2-AP messages for one UE over the UE-associated logical S1/X2-connection. NOTE: The UE-associated logical S1/X2-connection may exist before the eNB UE context is setup in eNB.
S1 and X2 Application Protocol Identities

An eNB UE S1AP ID uniquely identifies a UE over the S1 interface within an eNB logical node. When an MME receives an eNB UE S1AP ID it stores it for the duration of the UE-associated logical S1S1 connection for this UE. Once known to an MME this IE is included in all UE associated S1-AP signaling. An MME UE S1AP ID uniquely identifies a UE over the S1 interface within the MME logical node. When an eNB receives MME UE S1AP ID it stores it for the duration of the UEassociated logical S1- connection for this UE. Once known to an eNB this IE is included in all UE associated S1 S1-AP AP signaling. signaling An Old eNB UE X2AP ID uniquely identifies a UE over the X2 interface within a source eNB logical node. When a target eNB receives an Old eNB UE X2AP ID it stores it for the duration of the logical X2-connection of this UE. Once known to a target eNB this ID is included in all UE assoc. X2-AP signaling. A New eNB UE X2AP ID uniquely identifies a UE over the X2 interface within a target eNB. When a source eNB receives a New eNB UE X2AP ID it stores it for the duration of the UEassociated logical X2-connection for this UE. Once known to source eNB this IE is included in all UE associated X2-AP signaling. The New eNB UE X2AP ID is unique within the eNB logical node. An eNB1 Measurement ID identifies the measurement configuration over the X2 interface within the eNB requesting measurement. The eNB1 Measurement ID is unique within the eNB logical node. An eNB2 Measurement ID uniquely identifies the measurement configuration over the X2 interface within the eNB performing the measurement measurement. The eNB2 Measurement ID is unique within the eNB logical node.
August, 2010
Page 50
Radio System Identifiers and Parameters
August, 2010
Page 51
3. Radio System Identifiers and Parameters

UE Identifiers (IMSI, TMSI, GUTI ) Random Access Radio Network Temporary Identifier (RA-RNTI) contained in the MAC C subheader of each random access response LCID Logical channel identifier RRC layer in the Enb allocates celllevel temporary identifiers S-TMSI SAE Temporary Mobile Station Identifier UTRAN and EPC Identifiers ECGI E-UTRAN Cell Global Identifier one or multiple 'PLMN PLMN identity' identity in a given cell CSG identity: broadcast by cells in a CSG to allow authorized CSG member UEs to access C-RNTI (Cell Radio Network Temporary Identifier) PCI Physical Cell Identifier QC QoS Q S Class C Identifier f QCI RNTI Radio Network Temporary Identifier y yp contains SystemInformationBlockType9 a home eNB identifier (HNBID); eNB Identifier (eNB ID): used to identify eNBs within a PLMN. Tracking Area identity (TAI): used to identify tracking areas NAS UE identifier NAS (EPC/UE) level AKA procedure (KASME) and identified with a key identifier (KSIASME). MME includes a session identifier SI-RNTI System Information RNTI CID Context Identifier
August, 2010
Page 52
E-UTRAN Network Identities

PLMN Identity A Public Land Mobile Network is uniquely q y identified by y its PLMN Identity. y Globally Unique MME Identifier (GUMMEI) The Globally Unique MME Identifier consists of a PLMN Identity, a MME Group Identity and a MME Code An MME logical node may be associated with one or more GUMMEI GUMMEI, but each GUMMEI uniquely identifies an MME logical node. Global eNB ID The Global eNB ID is used to globally identify an eNB E-UTRAN Cell Global Identifier (ECGI) The ECGI is used to globally identify a cell. Tracking Area Identity (TAI) Each E hT Tracking ki A Area ( (a d defined fi d group of fl local l cells) ll ) h has an assigned i d TAI E-RAB ID An E-RAB uniquely identifies the combination of an S1 bearer and the corresponding Data Radio Bearer. Under an E-RAB, there is a one-to-one mapping between this E-RAB and an EPS bearer of the Non Access Stratum.
August, 2010
Page 53
E-UTRAN UE Identifiers (1)

RNTI Radio Network Temporary Identifiers (RNTI) are used as UE identifiers within E-UTRAN and in signaling messages between UE and E-UTRAN. Some types of RNTI exist: C C-RNTI RNTI Connected Radio Network Temporary Identifier The C-RNTI provides a unique UE identification at the cell level identifying RRC Connection RA-RNTI Random-Access Ratio Network Temporary Identifier The RA-RNTI is used during some transient states, the UE is temporarily identified with a random value for contention p p resolution purposes S-TMSI S-Temporary Mobile Subscriber Identity (S-TMSI) The S-TMSI is a temporary UE identity in order to support the subscriber identity confidentiality. This S-TMSI S TMSI is allocated by MME.
E-UTRAN UE Identifiers (2)

Transport Layer Addresses The transport layer address parameter is sent in radio signaling procedures to establish the transport bearer connections connections. The transport layer address parameter is not interpreted in the radio network application protocols An eNB UE context is a block of information about one active UE held by the eNB. The block contains UE state t t information, i f ti security it information, i f ti UE capability bilit information, identities of the UEs logical S1-connection An eNB UE context is established when the transition to active state for a UE is completed or in target eNB after completion of handover resource allocation during handover preparation. LCID Logical channel identifier RRC layer in the eNB allocates cell-level temporary identifiers
Tunnels, Connections and Bearers
August, 2010
Page 56
4. Tunnels, Connections and Bearers

4-1 Default Bearers, Dedicated Bearers 4-2 4 2 GPRS Tunneling T nneling Protocol (GTP) and Pro Proxy Mobile IP (PMIP) 4-3 Tunnel parameters (TEID; F-TEID )
August, 2010
Page 57
LTE Bearers
In LTE, , data plane p a e traffic t a c travels t a e s over o e virtual tua connections co ect o s ca called ed service data flows (SDFs). SDFs travel over bearers: Virtual containers with unique QoS characteristics. A bearer is a datapath between UE and PDN, in three segments: Radio bearer between UE and eNodeB Data bearer between eNodeB and SGW (S1 bearer) Data bearer between SGW and PGW (S5 bearer)
Basics of GTP-U Protocol General Tunneling Protocol

GPRS Tunneling Protocol (GTP) is a group of IP-based communications protocols used in wireless networks. GTP includes variant protocols, GTP-C, GTP-U and GTP'. GTP-C is used within the GPRS core network for signaling between Gateway GPRS Support Nodes (GGSN) and Serving GPRS Support Nodes (SGSN). GTP-U is used for carrying user data within the GPRS Core Network and between the Radio Access Network and the core network. The user data transported can be packets in any of IPv4, IPv6, or PPP formats. It is used in the LTE EPC network. GTP' (GTP prime) uses the same message structure as GTP-C and d GTP GTP-U, U b but t can b be used df for carrying i charging h i d data t f from th the Charging Data Function (CDF) of the GSM or UMTS network to the Charging Gateway Function (CGF). GTP can be used with UDP or TCP. TCP GTP version one is used only on UDP.
GTP-U Tunneling Protocol

GTP-U is an IP-based tunneling protocol allowing many tunnels between each set of end points. Each tunnel has TEID (Tunnel Endpoint Identifier) in the GTP-U messages, derived from a dynamically generated random number. GTP GTP-U U is used for user plane tunneling and GTP-C GTP C is used for control plane (setup, teardown and modification of the user plane's parameters mainly). GTP-C is j just the control p protocol used to set up p the user tunnels. Actually GTP-C gets allocated its own TEID by both ends of the connection so it is a tunnel on its own. It is possible use different IP addresses for GTP-U and GTP-C. Both use UDP and fixed port numbers (2123 for GTP-C and 2152 for GTP-U). User's are separated based on the TEID (which is unique per direction).
August, 2010
Page 60
Basics of Proxy Mobile IP

Proxy Mobile IP (or PMIP, or Proxy Mobile IPv6) is a new standard under the Internet Engineering Task Force (IETF). Also called Network-based mobility management, it is somewhat like Mobile IP, but does not require modifications to the mobile host's network stack, as mobility is handled by the network. How Proxy Mobile IP works Two network entities are involved: Local Mobility Anchor (LMA) is the home agent for the mobile host in a Proxy Mobile IP domain. Mobile Access Gateway (MAG) is a function on an access router g the mobility y related signalling g g for a mobile host that that manages is attached to its access link.
August, 2010
Page 61
Operation of Proxy Mobile IP

The protocol works as follows: A mobile host enters a PMIP domain A Mobile Access Gateway on that link checks host authorization A mobile host obtains an IP address A Mobile Access Gateway updates a Local Mobility Anchor about the current location of a host Both B th MAG and d LMA create t a bi bi-directional di ti lt tunnel l
August, 2010
Page 62
Default and Dedicated Bearers

When a UE connects to the network it gets an IP address. This is called "Default EPS Bearer Activation, , and it has no QoS. Its also possible to do a "Dedicated EPS Bearer Activation" which offers QoS and other beneficial features VoIP, VoIP IMS, IMS VoLGA and other real time streaming applications applications, depend on QoS policies on the air interface A dedicated bearer is connected to a Traffic Flow Template (TFT), a list of IP addresses and TCP/UDP p port combinations The TFT is forwarded to the mobile during the dedicated bearer activation and it guides the protocol stack to move the IP packets to or from a specific TCP/UDP port and/or IP addresses dd i into t a special i lQ QoS S queue f for b better tt t treatment t t No extra IP address is needed, as the protocol stack uses the Traffic Flow Template information to decide what to do with each IP packet packet.
Tunnel parameters (TEID; F-TEID ) Default Bearer (2)

The call flow is straightforward. Notice the fields TEID and FTEID. TEID is present in the GTP GTP-C C header to identify the tunnel tunnel. FTEID is Fully Qualified Tunnel End Point Identifier. This IE is used to send TEID/GRE Key and IP info of the sending entity. Create Session Request is always sent with TEID set to zero zero. The S-FTEID is the senders FTEID. The MME sends this field with a TEID value, say 0x111 and its IP address dd t to S-GW. S GW From this message the S-GW learns the IP address of the MME and the TEID field to be used in the response. S-GW S GW sends d Create C t Session S i Response R message with ith TEID value 0x111 and S-FTEID which contains the TEID value, say 0x222, for use by MME and IP address of the S-GW. MME uses TEID: 0x222 for sending control plane info to S S-GW GW and S-GW uses TEID 0x111 to send control plane info to MME.

LTE : Tunnel Identifiers (GTPv2) First step in understanding bearers is tunnels tunnels. How are tunnels identified? Lets follow LTE call flow where two activities are running on mobile phone, one is using default bearer and other is using dedicated bearer. The key detail is the TEID and FTEID fields.
August, 2010
Page 65

Once the control plane is set traffic has to flow. Modify Bearer Request is used to indicate the S1-U S1 U interface of eNB. So S-FTEID S FTEID (S1-U eNB FTEID) value is set to say 0x0a + IP address and sent to S-GW. S-GW replies with its S1-U interface FTEID. At this stage the TEID for the user plane are set. User plane traffic will flow using the TEID's exchanged exchanged. Thus the traffic flows on default bearer.
August, 2010
Page 66
Tunnel parameters (TEID; F-TEID ) Dedicated Bearer (1)
August, 2010
Page 67
Tunnel parameters (TEID; F-TEID ) Dedicated Bearer (2)

A Bearer Resource Command is used by MME to request a dedicated bearer. Receiving the bearer resource command, the S-GW initiates a Create Bearer request. The same TEID field negotiated earlier is used again again. In create bearer request S-GW includes S1-U SGW F-TEID for user plane traffic. MME sends a Create Bearer Response message with the S1-U eNB FTEID. Now the dedicated bearer is created and the user plane traffic tunnel is negotiated. g Dedicated bearer user p plane traffic flows using the exchanged TEIDs The interface is S11. This interface is mapped to S5/S8 and S1MME interfaces. TEID are used to identify and map the tunnels in various interfaces.
System Acquisition and Synchronization
August, 2010
Page 69
System Acquisition
S Searching hi In I Frequency F S Searching hi In I Time Ti
At power-up, the UE notes its LTE band class capabilities and begins exploring the frequencies used for the SCH in each band The UE first looks for the primary synchronization signal (P-SCH) in the last OFDM symbol of the first time slot of the first subframe (subframe 0) in each radio frame. It reads symbol timing, and learns which of three cell identities is being transmitted, and locks its freqencies to the eNB. The UE next searches for the (S-SCH) secondary synchronization signal, and dl learns which hi h of f 170 cell ll id identities titi i is b being i t transmitted. itt d F From thi this it decodes the PCI, physical cell identity, and the frame boundaries The UE next finds the RS sequence and learns antenna port configuration Now the UE can decode the P P-BCH BCH and apply cell selection and reselection criteria
The Downlink Reference Signal

The downlink reference signals consist of known reference symbols inserted in the first and third last OFDM symbol y of each slot. There is one reference signal transmitted per downlink antenna port. The number of downlink antenna ports equals 1, 2, or 4. Frequency q y hopping pp g can be applied pp to the downlink reference signals. g The hopping pattern period is one frame (10 ms). Each frequency hopping pattern corresponds to one cell identity group. The downlink MBSFN reference signals consist of known reference symbols inserted every other sub-carrier in the 3rd 3rd, 7th and 11th OFDM symbol of sub-frame in case of 15kHz sub-carrier spacing and extended cyclic prefix
August, 2010
Page 71
Example of RS Sequences for 4 Antennas
August, 2010
Page 72
How The UE Gets Essential System Information

After the cell-search, the UE can decode the Physical Broadcast Channel (PBCH) and read the Master Information Block (MIB) The PBCH is in the first four OFDM symbols of the second time slot of the first subframe. Thats every 40 ms, so the MIB is transmitted every fourth radio frame. The PBCH is scrambled by a sequence based on the cells cell ID N. Its carried by the 72 reserved subcarriers, QPSK-modulated The MIB carries the most essential system y information: transmission bandwidth i.e., # of available resource blocks. configuration of Physical HARQ Indicator Channel (PHICH) System Frame Number (SFN) The number of transmission antennas used on the eNB side This is derived from the sequence in which one of the CRC bits is scrambled and is added to each transport block. block
Types of System Information Blocks
August, 2010
Page 74
S Cell Selection and Reselection criteria

After finding a cell, the UE may or may not be permitted to use it, based on various signal quality criteria broadcast by the eNB. Here are two procedures for cell qualification: In the initial cell selection procedure, no knowledge about RF channels carrying an E-UTRA E UTRA signal is available at the UE UE. In that case the UE scans the supported E-UTRA frequency bands to find a suitable cell. Only the cell with the strongest g signal g p per carrier will be selected by y the UE. The second procedure relies on information about carrier frequencies and optionally cell parameters received and stored from previously-detected cells. If no suitable cell is found using the stored information the UE starts with the initial cell selection procedure. S is the criterion defined to decide if the cell is still suitable . This criterion is fulfilled when the cell selection receive level is Srxlev > 0. Srxlev is computed based on the following Equation:
S Cell Selection and Reselection criteria

Srxlev = Qrxlevmeas (Qrxlevmin + Qrxlevminoffset) Pcompensation Where Pcompensation = max (PEMAX PUMAX, 0)
All in db
Qrxlevmeas is the UE-measured receive level value for this cell, i.e. the Reference Signal Received Power (RSRP Qrxlevmin is the minimum required receive level in this cell, in dBm. Qrxlevminoffset is an offset to Qrxlevmin that is only taken into account as a result of a periodic search for a higher priority PLMN while camped normally in a Visitor PLMN (VPLMN). PCompensation is a maximum function. PEMAX is maximum power allowed for a UE in this cell. PUMAX is maximum for power class A UE may discover cells from different network operators. First the UE will look for the strongest cell per carrier, Then the PLMN identity y from the SIB Type yp 1 to see if suitable, , Then it will compute the S criterion and decide if suitable
Cell Search Measurements

An LTE UE measures reference signal RSRP (Reference Signal Received Power) ) and RSRQ (Reference ( Signal g Received Quality). y) RSRP is a RSSI type of measurement. It measures the average received power over the resource elements that carry cell-specific reference signals within certain frequency bandwidth. RSRQ i is a C/I type t of f measurement t and d it i indicates di t th the quality lit of f th the received reference signal, defined as (N*RSRP)/(E-UTRA Carrier RSSI), N ensures the nominator and denominator are measured over the same frequency q y bandwidth; ; carrier RSSI measures the average total received power observed only in OFDM symbols containing reference symbols for antenna port 0 in the measurement bandwidth over N resource blocks. The total carrier RSSI includes all incoming RF from all sources sources. RSRP is applicable in both RRC_idle and RRC_connected modes, while RSRQ is only applicable in RRC_connected mode. procedure of cell selection and cell reselection in idle mode, , RSRP In the p is used. In the procedure of handover, the LTE specification provides the flexibility of using RSRP, RSRQ, or both.
Physical Layer Measurements Definition

The physical layer measurements to support mobility are classified as: within E-UTRAN (intra-frequency, inter-frequency); between E-UTRAN and GERAN/UTRAN (inter-RAT); between E E-UTRAN UTRAN and non non-3GPP 3GPP RAT (Inter 3GPP access system mobility). For measurements within E-UTRAN at least two basic UE measurement quantities shall be supported: Reference symbol received power (RSRP); E-UTRA carrier received signal strength indicator (RSSI).
August, 2010
Page 78
Idle Mode and Paging
August, 2010
Page 79
Tracking Area Update

Consider a UE in idle state (RRC idle and ECM idle) This UE is free to travel and only do a Tracking Area Update (TAU) when it discovers it has landed on a cell in a different TA If data arrives for the UE, the system must page the UE throughout the TA where it last registered The mobile responds to the page, page implicitly revealing its cell location and re-establishing its connection to the network When a mobile is switched on it always has at least a default bearer with the IP address that comes with it A UE is in ECM-IDLE state when no NAS signaling connection exists between the UE and the network The mobile only performs cell selection and PLMN selection There is no UE context, no S1_MME and no S1_U connection The UE will perform the TA procedure when the TAI in the EMM isn isnt t on the UEs UE s registered list of Tas The UE will then be in ECM-CONNECTED state again
Cell Reselection (Idle Mode Handover)

The mobile is in power-conservation mode Does not inform network of every cell change; rather rather, just when it detects entry into a new Tracking Area UE-terminated calls are paged in the UEs last reported TA TA organization and procedures have been widely debated Static non-overlapping TAs were used in earlier technologies New techniques reduce ping-ponging, distribute TA update l d more evenly load l across cells, ll and d reduce d aggregate t TA update load Mechanisms include overlapping TAs, multiple TAs, and distance based schemes distance-based
August, 2010
Page 81
UE UL Transmission in Idle State

In Idle State, a UE must use the Random Access Procedure to be recognized by the eNB without causing interference to other UEs There are four variations in Random Access Procedure types The parameters of each RAP type are designed to ensure that the UEs UE s transmission will be heard by the eNB eNB, taking into account Existing noise and interference levels, UE apparent timing as received at the UE Needed N d d retransmission t i i if collisions lli i occur
August, 2010
Page 82
Contention-Based Random Access Procedures (1)

The four steps of the contention based random access procedures are: 1) ) Random Access Preamble on RACH in uplink: p There are two possible groups defined and one is optional. If both groups are configured the size of message 3 and the pathloss are used to determine which group a preamble is selected from. The group to which a preamble belongs provides an indication of the size of the message 3 and the radio conditions at the UE. The preamble group information along with the necessary thresholds are broadcast on system information. 2) Random Access Response generated by MAC on DL-SCH: Semi-synchronous (within a flexible window of which the size is one or more TTI) with message 1; No HARQ; Addressed to RA-RNTI on PDCCH; Conveys at least RA-preamble identifier, Timing Alignment information, initial UL grant and assignment of Temporary C-RNTI (which may or may not be made permanent upon Contention Resolution); Intended for a variable number of UEs in one DL-SCH message.
August, 2010
Page 83

3) First scheduled UL transmission on UL-SCH: Uses HARQ; Size of the transport blocks depends on the UL grant conveyed in step 2 and is at least 80 bits. For initial access: Conveys the RRC Connection Request generated by the RRC layer y and transmitted via CCCH; ; Conveys at least NAS UE identifier, no NAS message; RLC TM: no segmentation; For RRC Connection Re-establishment procedure: Re establishment Request Conveys RRC Connection Re-establishment generated by RRC layer and transmitted via CCCH; RLC TM: no segmentation; Does not contain any NAS message. After handover, in the target cell: Conveys the ciphered and integrity protected RRC Handover Confirm generated by the RRC layer and transmitted via DCCH; Conveys the C-RNTI of the UE (which was allocated via th H the Handover d C Command); d) Includes an uplink Buffer Status Report when possible. August, 2010 Course 502 v1.1 (c)2010 Scott Baxter Page 84

For other events: Conveys at least the C-RNTI of the UE. ) Contention Resolution on DL: 4) Early contention resolution shall be used i.e. eNB does not wait for NAS reply before resolving contention Not synchronised with message 3; pp HARQ is supported; Addressed to: The Temporary C-RNTI on PDCCH for initial access and after radio link failure; The C-RNTI on PDCCH for UE in RRC_CONNECTED; HARQ feedback is transmitted only by the UE which detects its own UE identity, as provided in message 3, echoed in the Contention Resolution message; For initial access and RRC Connection Re Reestablishment procedure, no segmentation is used (RLC-TM). The Temporary C-RNTI is promoted to C-RNTI for a UE which detects RA success and does not already have a CRNTI it is CRNTI; i dropped d d by b others. th A UE which hi h d detects t t RA success and already has a C-RNTI, resumes using its CRNTI. August, 2010 Course 502 v1.1 (c)2010 Scott Baxter Page 85
Non-Contention-Based Random Access Procedure

Non-contention based random access procedures are: 0) Random Access Preamble assignment via dedicated signaling in DL: eNB assigns UE a non-contention Random Access Preamble signaled via: HO msg msg. target eNB to source eNB for HO PDCCH in case of DL data arrival or positioning. 1) Random Access Preamble on RACH in uplink: UE transmits the assigned non-contention RAP. 2) Random Access Response on DL-SCH: Semi-synchronous (within a flexible window); No HARQ, Sent to RA-RNTI on PDCCH; Conveys at least: Timing Alignment info, initial UL grant for HO Timing Alignment info. for DL data arrival; RA-preamble p identifier. Sent to one or more UEs in one DL-SCH msg.
UE Attach to the Network (Registration Procedure)
August, 2010
Page 87
7. UE Attach to the Network (Registration Procedure)

7-1 Suitable MME, SGW and PGW selection 7 2 Authentication 7-2 Authentication, ciphering and IP address allocation 7-3 Default Bearer setup 7-3 Initial Attach process: A comprehensive Message-flow summary
August, 2010
Page 88
Connected Mode and UE States
August, 2010
Page 89
8. Connected Mode and UE States

8-1 RRC connection setup 8 2 Service Establishment and QoS 8-2 8-3 QoS parameters and TFTs 8-4 Connected Mode: Incoming and outgoing call flows (end-toend)
August, 2010
Page 90
RRC Connection
RRC Connection Setup procedure triggered by a request from UE NAS layer UE origination, NAS signaling, or Paging Response RRC connection ti is i established t bli h d b between t UE and d eNB NB and d SRB1 i is set t up If overloaded, eNodeB sets access class barring parameters in SRB1 If UE has valid S-TMSI, UE includes it in RRC connection request message; otherwise 40 bit random value otherwise, After successful RRC connection procedure, UE is in RRC-Connected state
QoS Parameters and TFTs (1)

A Traffic Flow Template (TFT) is all the packet filters associated with an EPS bearer. A packet filter may be associated with a protocol. Several packet filters can be combined to form a Traffic Flow Template Template. EBI+Packet filter ID gives us a "unique" packet filter Identifier. The following is the TFT for FTP protocol.
August, 2010
Page 92

Bearer level QoS is associated with a bearer and all traffic mapped to that will receive same bearer level packet forwarding treatment. QoS parameter values of the default bearer are assigned g by y the network based on the subscription data received from HSS. In LTE the decision to establish or modify a dedicated bearer is taken by EPC and bearer level QoS parameters are assigned by EPC Th EPC. These values l are not t modified difi d b by MME b but t are f forwarded d d transparently to EUTRAN. However MME may reject the establishment of dedicated bearer if there is any discrepancy.
August, 2010
Page 93

A default bearer may or may not be associated with a TFT. But a dedicated bearer is always associated with TFT. So we have bearers, the QoS values for them and TFT which indicate what type of application should run over them. This defines the LTE QoS. We have Uplink TFT and Downlink TFT which are used by UE and PDN The UE routes uplink packets to the different EPS bearers based on uplink packet filters in the TFT's assigned to those EPS bearers. We have evaluation packet precedence index in packet filter which is used by UE to search for a match (to map the application traffic) traffic). Once the UE finds a match it uses that particular packet filter to transmit the data. If there is no match UE transmits the data on bearer to which no TFT has been assigned.
Network Performance Evaluation and Optimization Issues
August, 2010
Page 95
9. Network Performance Evaluation and Optimization Issues

9-1 Channel Quality reporting 9 2 ARQ; H-ARQ 9-2 H ARQ and Scheduling 9-3 QoS revisited 9-4 Throughput calculations and optimization 9-5 Voice-over-IP support and voice capacity projections
August, 2010
Page 96
Limiting measurement load at UE

Introduction of E-UTRA implies co-existence of various UE capabilities. Each UE may support different combinations of RATs, e.g., E-UTRA, UTRA, GSM, and non-3GPP RATs, and different combinations of frequency bands, e.g., 800 MHz, 1.7 GHz, 2 GHZ, etc. Despite such heterogeneous environment, the measurement load at UE should be minimised minimised. To limit the measurement load and the associated control load: E-UTRAN can configure the RATs to be measured by UE; The Th number b of f measurement t criteria it i (event ( t and d periodic i di reporting criteria) should be limited (as in TS 25.133 subclause 8.3.2 [7]); E-UTRAN E UTRAN should be aware of the UE capabilities for efficient measurement control, to prevent unnecessary waking up of the measurement entity; Blind HO (i.e., HO without measurement reports from UE) is possible.
Measurement Limitations of UE
August, 2010
Page 98
LTE UE Field Measurements and KPIs

RF Key Performance Indicators RSRP Reference Signal Received Power RSSI Received Signal Strength Indicator RSRQ Reference Signal Receive Quality. Defined as N RSRP / RSSI, RSSI where N is the number of resource blocks across which RSSI was measured
August, 2010
Page 99
Mobility, Interoperability and Handover Management
August, 2010
Page 100
Introduction to Handover
With the fast-changing mobile landscape and convergence in all aspects of telecommunications, seamless seamless handover handover is important for any technology to succeed. Operators and consumers both benefit from seamless handover in terms of cost effectiveness, enhanced features, location independence and ease of use, not only within a Long Term Evolution (LTE) network but also between networks including UMTS, GSM and CDMA. In I this thi chapter h t we briefly b i fl touch t h upon the th procedures d executed t db by the user equipment (UE) and the various network elements to provide the handover services requested by the UE. We cover Intra-LTE and LTE to/from UMTS handovers.
August, 2010
Page 101
Handover Procedures - Objectives

Objectives of Handover Procedures It is important that QoS is maintained, maintained not just before and after a handover, but during the handover as well. Handover must not unduly drain the UE battery power. Service continuity shall be maintained (i (i.e., e minimal handover latency). Seamless handoff is required to 3G / 2G / CDMA technology. There Th are t two ways a handoff h d ff can be b d decided: id d Network Evaluated: the network makes the handover decision Mobile Evaluated: the UE makes the handoff decision and i f informs th the network t k about b t it. it In this instance, the final decision will be made by the network based upon on the Radio Resource Management.
August, 2010
Page 102
Handover Types
In 3G and LTE networks, a hybrid approach is used to decide on the handover. The Th UE will ill assist i t in i the th h handoff d ff d decision i i b by measuring i th the neighboring cells and reporting the measurements to the network The network decides upon the handoff timing and the target cell/node. The parameters to measure and the thresholds for reporting are decided by the network network. In LTE there are three types of handovers: Intra-LTE: Handover happens within the current LTE nodes (intra-MME and Intra-SGW) Inter-LTE: Handover happens toward the other LTE nodes (inter-MME and Inter-SGW) Inter-RAT: Inter RAT: Handover between different radio technology networks, for example GSM/UMTS and UMTS
Flow Examples
Intra-LTE (Intra-MME / SGW) Handover Using the X2 Interface
August, 2010
Page 104
Case I. Intra-LTE (Intra-MME / SGW) Handover Using the X2 Interface

Consider Intra-LTE handovers with X2AP signaling and S1AP signaling first, then Inter-RAT Inter RAT handovers in LTE (i.e., handover between LTE and UMTS). Intra-LTE (Intra-MME / SGW) Handover Using the X2 Interface: This procedure is used to handover a UE from a source eNodeB (S-eNB) to a target eNodeB (T-eNB) using the X2 interface when the Mobility Management Entity (MME) and Serving Gateway (SGW) are unchanged. It is possible only if direct connectivity exists i t between b t the th source and dt target t eNodeBs N d B with ith th the X2 interface. The X2 handover procedure is performed without Evolved Packet Core (EPC) involvement, involvement i.e. i e preparation messages are directly exchanged between the S-eNB and T-eNB. The release of the resources at the source side during the handover completion phase is triggered by the T-eNB. The message flow is shown in Figure 1 followed by the description
The Data call is already established between the UE, S-eNB and network elements. Data packets are already flowing to/from the UE on both DL & UL UL.
August, 2010
Page 106
The Network sends a MEASUREMENT CONTROL REQ message to the UE to set the measurement parameters and thresholds thresholds. The UE is instructed to send measurement report when thresholds are met.
August, 2010
Page 107
The UE sends a MEASUREMENT REPORT to the S S-eNB eNB as soon as thresholds are met. The S-eNB decides to hand UE off to a T-eNB using network operators handover algorithm. operators
August, 2010
Page 108
Optionally S-eNB issues RESOURCE STATUS REQUEST message to determine the load on T-eNB. Based on received RESOURCE STATUS RESPONSE, , the S-eNB can decide whether to continue the handover procedure using the X2 interface.
August, 2010
Page 109
The S-eNB issues a HANDOVER REQUEST message to the TeNB with UE and RB contexts to prepare handover at the target.
August, 2010
Page 110
T-eNB checks availability, reserves resources and sends back HANDOVER REQUEST ACKNOWLEDGE message including i l di a transparent container for the UE as an RRC message to perform the handover. The container includes a new C-RNTI C-RNTI, T-eNB security algorithm identifiers for the selected security algorithms, and may include a dedicated RACH preamble and possibly some other parameters (i.e., access parameters, SIBs, etc.).
August, 2010
Page 111
The S-eNB generates the RRC message to perform the handover, i.e, RRCCONNECTION RECONFIGURATION message including the mobility Control Information. The S-eNB performs the necessary integrity protection and ciphering of the message and sends it to the UE UE.
August, 2010
Page 112
The S S-eNB eNB sends the eNB STATUS TRANSFER message to the T-eNB to convey the PDCP and HFN status of the E-RABs.
August, 2010
Page 113
The S-eNB starts forwarding the downlink data packets to the TeNB for all the data bearers (which are being established in the TeNB during the HANDOVER REQ message processing).
August, 2010
Page 114
In the meantime, the UE tries to access the T-eNB cell using the non-contention-based Random Access Procedure.
August, 2010
Page 115
If it succeeds in accessing the target cell, it sends the RRC CONNECTION RECONFIGURATION COMPLETE to the T T-eNB eNB.
August, 2010
Page 116
The T-eNB sends a PATH SWITCH REQUEST message to the MME to t inform i f it that th t the th UE has h changed h d cells, ll including i l di the th TAI+ECGI of the target. The MME determines that the SGW can continue to serve the UE.
August, 2010
Page 117
The MME sends a MODIFY BEARER REQUEST (eNodeB address dd and d TEIDs TEID f for d downlink li k user plane l f for th the accepted t d EPS bearers) message to the SGW. If the PDN GW requested the UEs location info, the MME also includes the User Location Information g IE in this message.
August, 2010
Page 118
The SGW sends one or more end end marker marker packets on the old path to the S-eNB and then can release any user plane / TNL resources toward the S-eNB.
August, 2010
Page 119
1 15. Th The MME responds d to the h T T-eNB NB with i h a PATH SWITCH REQ ACK message to notify the completion of the handover.
August, 2010
Page 120
User data packets now flow between the SGW and the UE.
August, 2010
Page 121
The T-eNB now requests the S-eNB to release the resources using the X2 UE CONTEXT RELEASE message message. With this, this the handover procedure is complete.
Flow Examples
Intra-LTE (Intra-MME / SGW) Handover Using the S1 Interface
August, 2010
Page 123
Case II. Intra-LTE (Intra-MME / SGW) Handover Using the S1 Interface

An S1-based handover procedure is used when the X2-based handover cannot be used no X2 connectivity to the target eNodeB; by an error indication from the T-eNB after an unsuccessful X2based handover by dynamic information learned by the S-eNB using the STATUS TRANSFER procedure. The S-eNB initiates the handover by sending a Handover required message over the S1-MME reference point. The EPC does not change the decisions taken by the S-eNB. The availability of a direct forwarding path is determined in the SeNB NB (based (b d on the th X2 connectivity ti it with ith the th T T-eNB) NB) and di indicated di t d to the source MME. If a direct forwarding path is not available, indirect forwarding will be used. used The source MME uses the indication from the S SeNB to determine whether to apply indirect forwarding or not.

Based on the MEASUREMENT REPORT from the UE, the S-eNB decides to Handover the UE to another eNodeB (T-eNB). (T eNB). The handover procedure in this section is very similar to that in the previous section (Intra-LTE Handover Using the X2 Interface), except the involvement of the MME in relaying the handover signaling between the S S-eNB eNB and T T-eNB. eNB There are two differences here: No need for the PATH SWITCH Procedure between the T-eNB and d MME MME, as MME is i aware of f the th Handover. H d The SGW is involved in the DL data forwarding if there is no direct forwarding path available between the S-eNB and TeNB. eNB Once the Handover is complete, the MME clears the logical S1 connection with the S-eNB by initiating the UE CONTEXT RELEASE procedure.
August, 2010
Page 125
The UE is sending and receiving user data on both the uplink and downlink.
August, 2010
Page 126
The S-eNB sends an RRC: Measurement Control message to the UE, instructing it to take certain measurements at specific intervals and dt to report t the th results lt when h specific ifi criteria it i are met. t The UE sets to work taking the requested measurements and performing comparisons against the specified criteria.
August, 2010
Page 127
The UE notices that measurements have satisfied the specified criteria It sends an RRC: Measurement Report to the Currently criteria. Serving eNB. The handover procedure in this section is very similar to that in the previous section (Intra-LTE Handover Using the X2 Interface), Interface) except the involvement of the MME in relaying the handover signaling between the S-eNB and T-eNB.
August, 2010
Page 128
The serving eNB sends a Handover Required message to the MME
August, 2010
Page 129
MME sends d H Handover d R Request tt to T Target t eNB NB
August, 2010
Page 130
The Target eNB sends a Handover Request Acknowledgment to the MME
August, 2010
Page 131
The MME sends a Handover Command to the serving eNB
August, 2010
Page 132
The Serving eNB sends an RRC Connection Reconfiguration Request to the UE
August, 2010
Page 133
The Serving eNB sends an eNB Status Transfer message to the MME
August, 2010
Page 134
The Serving eNB sends a Forward User Data message to the SGW by GTP protocol
August, 2010
Page 135
The MME sends an MME Status Transfer message to the Target eNB
August, 2010
Page 136
The UE performs the Non-Contention RACH Process on the Target eNB
August, 2010
Page 137
The SGW sends Forward User Data to the Target eNB
August, 2010
Page 138
The UE sends an RRC Connection Reconfiguration Complete message to the Target eNB
August, 2010
Page 139
The Target eNB sends a Handover Notify message to the MME
August, 2010
Page 140
The MME sends a Modify Bearer Request message to the SGW by GTP
August, 2010
Page 141
The SGW sends a Modify Bearer Response to the MME by GTP
August, 2010
Page 142
User U d data packets k now fl flow b between the h UE and d the h SGW SGW.
August, 2010
Page 143
The T-eNB sends an S1AP UE Context Release Command to the the S-eNB.
August, 2010
Page 144
The S-eNB confirms the requested UE context release by sending the MME an S1AP UE Context Release Complete message message.
Flow Examples
Inter-MME Handover (Intra-SGW) ( change (no h in i Gateway) G t )
August, 2010
Page 146
Case III. Inter-MME Handover (Intra-SGW) (no change in Gateway)

In an inter-MME handover, two MMEs are involved in the handover, the source MME (S-MME) (S MME) and target MME (T-MME). (T MME). The S-MME controls the S-eNB and the T-MME controls the TeNB; both MMEs are connected to the same SGW. This handover is triggered when the UE moves from one MME area to another MME area. area
August, 2010
Page 147
Case III. Inter-MME Handover (Intra-SGW)
August, 2010
Page 148
The Serving eNB sends a Handover Request to the Serving MME
August, 2010
Page 149
The Serving MME sends a Forward Relocation Request to the Target MME by GTP
August, 2010
Page 150
The Target MME sends a Handover Request to the Target eNB
August, 2010
Page 151
The Target eNB sends a Handover Request Acknowledgment to the Target MME
August, 2010
Page 152
The Target MME sends a Forward Relocation Response to the Serving MME
August, 2010
Page 153
The Serving MME sends a Handover Command to the Serving eNB
August, 2010
Page 154
The Serving eNB sends a RRC Connection Reconfiguration Request to the UE
August, 2010
Page 155
Th The S Serving i eNB NB sends d an eNB NB St Status t T Transfer f to t the th Serving S i MME, which forwards it to the Target MME
August, 2010
Page 156
The Target MME sends an eNB Status Transfer to the Target eNB
August, 2010
Page 157
The Serving eNB sends Forward User data to the SGW by GTP
August, 2010
Page 158
The SGW sends Forward User Data to the Target eNB by GTP
August, 2010
Page 159
Th The UE performs f the h N Non-Contention C i RACH procedure d on the h Target eNB
August, 2010
Page 160
The UE sends RRC Connection Reconfiguration Complete to the Target eNB
August, 2010
Page 161
The Target eNB sends a Handover Notify message to the Target MME
August, 2010
Page 162
The Target MME sends a Modify Bearer Request to the SGW by GTP
August, 2010
Page 163
The SGW sends a Modify Bearer Response to the Target MME by GTP
The Target MME sends a Forward Relocation Complete message t the to th Serving S i MME
The Serving MME sends a Forward Relocation Complete Acknowledgment to the Target MME
User Packets now flow directly from UE to SGW in both directions

The S-MME sends a UE Context Release Command to S-eNB

The S-eNB responds with a UE Context Release Complete

Flow Examples
Inter-MME / SGW Handover U i the Using th S1 Interface I t f
August, 2010
Page 170
Case IV. Inter-MME / SGW Handover Using the S1 Interface

Inter-MME / SGW Handover Using the S1 Interface This scenario is similar to the previous section with the difference being the Source and Target eNodeBs are served by different MME / SGW nodes. Figure 4 depicts the procedures and is followed by the explanation.
August, 2010
Page 171
Case IV. Inter-MME / SGW Handover Using the S1 Interface

1 Based on the MEASUREMENT REPORT from the UE, the S-eNB decides to handover the UE to another eNodeB ( (T-eNB). ) The procedure is like earlier ones except for involvement of two SGWs (S-SGW and TSGW) to transfer data packets during handover. 2. After receiving GTP: FORWARD RELOCATION REQ from S-MME, TMME detects SGW change, change starts bearer creation toward target T-SGW T SGW using GTP: CREATE SESSION REQ message. 3. After creation of requested bearers, T-SGW responds back to MME with a GTP: CREATE SESSION RESPONSE message. 4. From here on, message flow is very similar to Inter-MME, Intra- SGW handover except for these differences: While processing the S1 HANDOVER NOTIFY message from the TeNB the T-MME updates the T-eNB endpoint information to the TeNB, SGW using GTP: MODIFY BEARER REQ. After updating T-eNB information in the bearers T-SGW sends GTP: MODIFY BEARER RESPONSE message to the T-MME. When Handover Complete, S-MME releases bearer resources with the SSGW for this UE by GTP: DELETE SESSION procedure
Case IV. Inter-MME / SGW Handover
August, 2010
Page 173
The S-eNB sends RRC Measurement Procedures to the UE The UE p performs the requested q measurements The S-eNB receives information when specified thresholds are exceeded, triggering need for a handover
August, 2010
Page 174
The Serving eNB sends a Handover Request to the serving MME
August, 2010
Page 175
The serving MME sends a Forward Relocation Request to the target MME
August, 2010
Page 176
The Target MME sends a Create Session Request to the Target SGW by GTP
August, 2010
Page 177
The Target SGW sends a Create Session Request to the Target MME by GTP
August, 2010
Page 178
The Target MME sends a Handover Request to the Target eNB
August, 2010
Page 179
The Target eNB sends a handover Request Acknowledgment to the Target MME
August, 2010
Page 180
The Target MME sends a Forward Relocation Request to the Serving MME using GTP
August, 2010
Page 181
The Serving MME sends a Handover Command to the Serving eNB
August, 2010
Page 182
Th The Serving S i eNB NB sends d an RRC Connection C ti Reconfiguration R fi ti Request to the UE
August, 2010
Page 183
The Serving eNB sends an eNB Status Transfer to the Target MME
August, 2010
Page 184
The Target MME sends an eNB Status Transfer to the Target eNB
August, 2010
Page 185
The Serving eNB sends Forward User Data to the Target eNB
August, 2010
Page 186
The UE performs the Non-Contention Non Contention RACH Procedure on the Target eNB
August, 2010
Page 187
The UE sends an RRC Connection Reconfiguration Complete message to the Target eNB
August, 2010
Page 188
The Target eNB sends a Handover Notify message to the Target MME
August, 2010
Page 189
The Target MME sends a Modify Bearer Request to the Target SGW using GTP
August, 2010
Page 190
The Target SGW sends a Modify Bearer Response to the Target MME by GTP
August, 2010
Page 191
The Target MME sends a Forward Relocation Complete message to the Serving MME
August, 2010
Page 192
The Serving MME sends a UE Context Release Command to the S i eNB Serving NB
The Serving MME sends a Forward Relocation Completion acknowledgment to the Target MME
The Serving eNB sends a UE Context release Complete to the Serving MME
The Serving MME sends a Delete Session Request to the Serving SGW
The S-SGW sends a Delete Session Response to the S-MME

User data packets flow from UE to T-SGW in both UL and DL

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 d i HO during HO: During HO preparation U-plane tunnels can be 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 applied. During HO execution, user data can be forwarded from the source eNB to the target eNB. The forwarding may take place in a service and deployment dependent and implementation specific way. Forwarding F di of f downlink d li k user d data t f from th the source t to the th target t t eNB NB should h ld 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. During HO completion: 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.
Handoff for RLC-AM Bearers

For RLC-AM bearers: During normal HO not involving Full Configuration: 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 synchronisation synchronisation, 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. In both the UE and the target eNB, a window-based mechanism is needed for duplication detection. The occurrence of duplicates over the air interface in the target eNB is minimised 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 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. August, 2010 Course 502 v1.1 (c)2010 Scott Baxter Page 200
HO with Full Configuration for RLC-UM Bearers

During HO involving Full Configuration: The following description below for RLC RLC-UM UM bearers also applies for RLC-AM bearers. Data loss may happen. For RLC-UM bearers: The PDCP SN and HFN are reset in the target eNB eNB. No PDCP SDUs are retransmitted in the target eNB. The target eNB prioritize all downlink PDCP SDUs forwarded b th by the source eNB NB if any (i (i.e. th the t target t eNB NB should h ld send dd data t 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.
August, 2010
Page 201
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. The method employed in the target eNB to enforce the correct delivery order of packets is outside the scope of the standard. 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 UE. The "end marker" packet shall not contain user ser data 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. resource However, However the release of the data forwarding resource is implementation dependent and could also be based on other mechanisms (e.g. timer-based mechanism). 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).
August, 2010
Page 202
Data Forwarding for RLC-AM DRBs (1)

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. NOTE: NOTE Target T t eNB NB does d not t have h to t wait it for f the th completion l ti of f forwarding f di from f the th source eNB NB before it begins transmitting packets to the UE. The source eNB discards any remaining downlink RLC PDUs. Correspondingly, the source eNB does not forward the downlink RLC context to the target eNB. NOTE: Source eNB does not need to abort on going RLC transmissions with the UE as it starts data forwarding to the target eNB. Upon handover, the source eNB forwards to the Serving Gateway the uplink PDCP SDUs successfully received insequence 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 SGW and shall discard any remaining uplink RLC PDUs PDUs. Correspondingly Correspondingly, the source eNB does not forward the uplink RLC context to the target eNB. Then the source eNB shall either: discard the uplink PDCP SDUs received out of sequence if the source eNB has not accepted p the request q from the target g eNB for uplink p forwarding g or if the target g 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.
August, 2010
Page 203
Data Forwarding for RLC-AM DRBs (2)

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. For F normal l HO in-sequence i d li delivery of f upper l layer PDU PDUs d during i h handover d i is b based d 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 insequence delivery of downlink PDCP SDUs; 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. After a normal 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 For handovers involving Full Configuration gaps. Configuration, the source eNB behaviour is unchanged from the description above. The target eNB may not send PDCP SDUs for which delivery was attempted by the source eNB. The target eNB identifies these by the presence of the PDCP SN in the forwarded GTP-U packet and discards them. After a Full Configuration handover, when the UE delivers received PDCP SDU from the source cell ll t to th the hi higher h l layer regardless dl of f possible ibl gaps. UE di discards d uplink li k PDCP SDU SDUs f for which hi h transmission was attempted and retransmission of these over the target cell is not possible.
August, 2010
Page 204
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 g downlink RLC PDUs. Correspondingly, p g y the source eNB does not forward the downlink RLC context to the target eNB. Upon handover, the source eNB forwards all uplink PDCP SDUs successfully received to the Serving Gateway (i.e. including the ones received out of sequence) and discards any remaining uplink RLC PDUs PDUs. Correspondingly, the source eNB does not forward the uplink RLC context to the target eNB. SRB handling With respect to SRBs, the following principles apply at HO: No forwarding or retransmissions of RRC messages in the target; The PDCP SN and HFN are reset in the target
August, 2010
Page 205
Inter and Intra-frequency Measurement Scenarios
August, 2010
Page 206
Course 502
LTE Flow Examples
August, 2010
Page 207
11. Lets Setup and Process various LTE Call Flows and Scenarios
11-1 Lets Attach the UE to the Network 11 2 Lets 11-2 Let s setup a Default Bearer; a Dedicated Bearer 11-3 Lets process an incoming data call; an outgoing data call 11-4 Lets watch and follow various handover scenarios 11-5 Lets setup a Voice-over-IP (VoIP) call 11-6 Lets setup a Broadband connection and a video call over LTE
August, 2010
Page 208
Flow Examples
Initial Attach
August, 2010
Page 209
LTE Initial Attach (1)

The S1 interface is initialized by request from the eNB to the MME The MME confirms setup of the S1AP interface by sending an S1 Setup Successful Outcome message to the eNB S1 Setup: This is where eNB is attached to the network. As long the eNB is functioning the S1 setup remains remains. The UE sends an RRC connection request message to the eNB The eNB sends an RRC Connection Setup message to the UE The Th UE sends d an RRC C Connection ti S Setup t C Complete l t message t to the eNB The message contains an NAS attachment request and a PDN connectivity request RRC Connections: Once UE comes up a RRC connection is established for communication with the network.
August, 2010
Page 210

The eNB sends the requests on to the MME NAS Attach Request PDN connectivity request NAS: After RRC is established then the NAS signaling begins . UE sends Attach request along with PDN connectivity request to network. Attach is for attaching to the network and the other message are for f establishing t bli hi th the b bearers. The MME sends an Authentication Info Request to the HSS HSS: This is Home Subscriber System and it understands di diameter t protocol. t l Once O MME receives i Attach Att h Request, R t it queries i HSS for authentication details. HSS sends the authentication vectors to MME in Authentication Info Answer The HSS responds to the MME with an Authentication Info Answer

The MME now has sufficient information to begin authentiation of the UE The MME sends an S1AP DL NAS Transport and NAS message containing the Authentication Request The eNB sends a RRC DL info Transfer and NAS message to the UE, containing the Authentication Request Authentication/Security: Networks request Authentication Vectors from UE. Once UE p provides them, , MME compares p them with what HSS has sent. If they match UE is authenticated. Next is security. After the security all the NAS messages are encrypted using the security algorithms that were exchanged. The Th UE replies li with ith an RRC UL i info f t transfer f and d NAS message including an NAS Authentication Response The eNB sends an S1AP UL NAS transport and NAS message containing the Authentication Response

The MME processes the authentication response and if successful, sends a DL NAS Transport and NAS message containing a Security Mode Command to the eNB The eNB sends a DL Info Transfer and NAS message including the Security Mode Command to the UE. The UE confirms it has applied the Security Mode Command by sending to the eNB a UL Info Transfer and NAS message containing Security Mode Complete The eNB forwards a UL NAS Transport and NAS message to the MME with the Security Mode Complete details Now the MME is able to send a Create Session Request to the SGW. SGW After security mode is complete, all the NAS messages are encrypted using the security algorithms that were exchanged. The PGW sends a Proxy Binding Update/ACK message to the SGW using PMIP

The SGW sends Create Session Response to the MME using GTP MME sends eNB the Initial Context Setup Request and NAS message containing Attach Accept and Activate Default EPS Bearer Context Request eNB sends RRC Connection Reconfiguration and NAS message to UE containing Attach Accept, Activate Default EPS Bearer Context Request. UE sends RRC Configuration g Complete p message g to eNB MME sends Initial Context Setup Response message to the eNB Security: network creates the EPS bearers (GTP messages). Then radio bearers created, , RRC connections modified, , radio bearers created, eNB downlink addresses sent to SGW in GTP messages eNB sends UL NAS transport and NAS Attach Complete message to MME, and Activate Default EPS Bearer Context Accept MME sends Modify Bearer Request by GTP to the SGW
The S1 interface is initialized by y request q from the eNB to the MME
LTE In nitial A Attach

August, 2010
Page 215
The MME confirms setup of the S1AP interface by sending an S1 Setup Successful Outcome message to the eNB S1 Setup: This is where eNB is attached to the network. As long g the eNB is functioning the S1 setup remains.
August, 2010
Page 216
The UE sends an RRC connection request message to the eNB

August, 2010
Page 217
The eNB sends an RRC Connection Setup message to the UE

August, 2010
Page 218
The UE sends an RRC Connection Setup Complete message g to the eNB The message contains an NAS attachment request and a PDN connectivity request RRC Connections: Once UE comes up a RRC connection is established for communication with the network.
August, 2010
Page 219
The eNB sends the requests on to the MME NAS Attach Request PDN connectivity y request q NAS: After RRC is established then the NAS signaling begins . UE sends Attach request along with PDN connectivity request to network. Attach is for attaching to the network and the other message are for establishing the bearers.
August, 2010
Page 220
The MME sends an Authentication Info Request to the HSS HSS: This is Home Subscriber System and it understands diameter protocol. protocol Once MME receives Attach Request Request, it queries HSS for authentication details. HSS sends the authentication vectors to MME in Authentication Info Answer
August, 2010
Page 221
The HSS responds to the MME with an Authentication Info Answer
August, 2010
Page 222
The MME now has sufficient information to begin authentiation of the UE The MME sends an S1AP DL NAS Transport and NAS message containing the Authentication Request
August, 2010
Page 223
The eNB sends a RRC DL info Transfer and NAS message to the UE, containing the Authentication Request Authentication/Security: Networks request Authentication Vectors f from UE. UE O Once UE provides id them, th MME compares them th with ith what h t HSS has sent. If they match UE is authenticated. Next is security. After the security all the NAS messages are encrypted using the security algorithms that were exchanged.
August, 2010
Page 224
The UE replies with an RRC UL info transfer and NAS message including an NAS Authentication Response
August, 2010
Page 225
The eNB sends an S1AP UL NAS transport and NAS message g the Authentication Response p containing
August, 2010
Page 226
The MME p processes the authentication response p and if successful, sends a DL NAS Transport and NAS message containing a Security Mode Command to the eNB.
August, 2010
Page 227
The eNB sends a DL Info Transfer and NAS message including the Security Mode Command to the UE.
August, 2010
Page 228
The UE confirms it has applied the Security Mode Command by sending to the eNB a UL Info Transfer and NAS message containing Security Mode Complete
August, 2010
Page 229
The eNB forwards a UL NAS Transport and NAS message to the t the t e Security Secu ty Mode ode Co Complete p ete deta details. s MME with
August, 2010
Page 230
Now the MME is able to send a Create Session Request q to the SGW. After security mode is complete, all the NAS messages are encrypted using the security algorithms that were exchanged.
August, 2010
Page 231
Th The PGW sends d aP Proxy Bi Binding di U Update/ACK d /ACK message to the h SGW using PMIP
August, 2010
Page 232

The SGW sends a Create Session Response to the MME using GTP
August, 2010
Page 233

MME sends eNB the Initial Context Setup Request and NAS message containing Attach Accept and Activate Default EPS Bearer Context Request
August, 2010
Page 234

eNB sends RRC Connection Reconfiguration and NAS message to UE containing Attach Accept, Activate Default EPS Bearer C t t Request. Context R t

UE sends RRC Configuration g Complete p message g to eNB
August, 2010
Page 236

MME sends Initial Context Setup p Response p message g to the eNB
August, 2010
Page 237

Security: network creates the EPS bearers (GTP messages). Then radio bearers created, RRC connections modified, radio bearers created, eNB downlink addresses sent to SGW in GTP messages

eNB sends UL NAS transport and NAS Attach Complete message to MME, and Activate Default EPS Bearer Context Accept

MME sends Modify Bearer Request by GTP to the SGW

Attach complete
Flow Examples
UE Detach
August, 2010
Page 242
LTE UE Detach
The UE is attached to this network. It decides to detach. In the following pages, It sends a detach request message to network. Network deletes the EPS bearers then the radio bearers are torn down. Finally RRC connection is released.
August, 2010
Page 243
LTE UE Detach
The UE sends an RRC UL Info Transfer + NAS containing a detach request.
August, 2010
Page 244
LTE UE Detach
The eNB sends to the MME an UL NAS Transport + NAS g containing g a Detach request q message
August, 2010
Page 245
LTE UE Detach
The MME sends a Delete Session Request q to the SGW using g GTP protocol.
August, 2010
Page 246
LTE UE Detach
The SGW sends the PGW a PMIP Proxy Binding Update, deleting the EPS bearers.
August, 2010
Page 247
LTE UE Detach
The PGW sends a PMIP Proxy Binding ACK to the SGW
August, 2010
Page 248
LTE UE Detach
The SGW sends a Delete Session Response message by GTP to the MME MME.
August, 2010
Page 249
LTE UE Detach
The MME updates the HSS on the UEs detachment with a Notify Request
August, 2010
Page 250
LTE UE Detach
The HSS confirms it has received the notification by sending a Notify Answer to the MME
August, 2010
Page 251
LTE UE Detach
Now the MME sends the eNB a DL NAS Transport + NAS Detach A Accept t
August, 2010
Page 252
LTE UE Detach
The eNB sends the UE an RRC Connection Reconfiguration message
August, 2010
Page 253
LTE UE Detach
The UE confirms to the eNB by sending an RRC Connection Reconfiguration Complete message
August, 2010
Page 254
LTE UE Detach
The MME sends the eNB a UE Context Release Command
August, 2010
Page 255
LTE UE Detach
The eNB responds to the MME with a UE Context Release Complete message
LTE UE Detach
The eNB sends the UE an RRC Connection Release message

LTE InterRAT Handover
August, 2010
Page 258
LTE PMIP TEID Tunnel Endpoint ID
August, 2010
Page 259
Flow Examples
Default Bearer Establishment Incoming g
August, 2010
Page 260
LTE Default Bearer Establishment, Incoming (1)

UE is in RRC_IDLE condition MME has traffic for specific UE UE. It sends Page message to all eNBs in UEs current tracking area (TA). eNB sends page message over air interface for UE UE recognizes the page and responds by sending RRC Connection Request message to eNB eNB sends RRC Connection Setup message to UE UE sends d eNB NB a RRC C Connection ti S Setup t C Complete l t message and d NAS message including Attach Request and PDN Connectivity Request eNB sends Initial UE Message + NAS attach request and PDN connectivity request to MME eNB sends Initial UE Message + NAS attach request and PDN connectivity request to MME MME sends Create Session Request to SGW using GTP
LTE Default Bearer Establishment, Incoming

UE is in RRC_IDLE condition
August, 2010
Page 262
MME has traffic for specific p UE. It sends Page g message g to all eNBs in UEs current tracking area (TA).
August, 2010
Page 263
eNB sends page message over air interface for UE
August, 2010
Page 264
UE recognizes the page and responds by sending RRC Connection Request message to eNB
August, 2010
Page 265
eNB sends RRC Connection Setup message to UE
August, 2010
Page 266
UE sends eNB a RRC Connection Setup Complete message and NAS message including Attach Request and PDN Connectivity Request
August, 2010
Page 267
eNB sends Initial UE Message + NAS attach request and PDN connectivity request to MME
August, 2010
Page 268
MME sends Create Session Request to SGW using GTP
August, 2010
Page 269
SGW sends PGW a PMIP Proxy Binding Update
August, 2010
Page 270
PGW responds to SGW with PMIP Proxy Binding ACK
August, 2010
Page 271
SGW sends d C Create t S Session i R Response t to MME
August, 2010
Page 272
MME sends eNB Initial Context Setup request + NAS Activate Default EPS Bearer Context Request and Attach Accept
August, 2010
Page 273
eNB sends UE an RRC Connection Reconfig and NAS Activate Default EPS bearer context request and Attach Accept
August, 2010
Page 274
UE responds d with i h RRC C Connection i R Reconfiguration fi i C Complete l
August, 2010
Page 275
eNB sends Initial Context Setup Response to MME
August, 2010
Page 276
UE sends eNB an RRC UL Info Transfer and NAS Activate Default EPS bearer context accept and Attach Accept
August, 2010
Page 277
eNB sends to MME UL NAS Transport and NAS Activate Default EPS Bearer B Context C t t Accept A t and d Attach Att h Accept A t
MME sends Modify Bearer Request to SGW using GTP

SGW responds to MME with Modify Bearer Response over GTP

Flow Examples
Default Bearer Establishment Outgoing g g
August, 2010
Page 281
LTE Default Bearer Establishment, Outgoing
UE is in RRC_Idle mode UE has data and needs connection to network
August, 2010
Page 282
UE sends RRC Connection Request to eNB
August, 2010
Page 283
eNB sends RRC Connection Setup to UE
August, 2010
Page 284
UE sends RRC Connection Setup Complete and NAS Attach Request and PDN Connectivity Request to eNB
August, 2010
Page 285
eNB sends Initial UE Message and NAS Attach Request and PDN Connectivity Request to MME
August, 2010
Page 286
MME sends Create Session Request to SGW using GTP
August, 2010
Page 287
SGW semds PMIP Proxy Binding Update to PGW
August, 2010
Page 288
PGW sends PMIP Proxy Binding Ack to SGW
August, 2010
Page 289
SGW sends Create Session Response to MME by GTP
August, 2010
Page 290
MME sends eNB an Initial Context Setup Request and NAS Activate Default EPS Bearer Context request and Attach Accept
August, 2010
Page 291
eNB sends UE an RRC Connection Reconfiguration and NAS A ti t Default Activate D f lt EBS Bearer B Context C t t Request R t and d Attach Att h Accept A t
August, 2010
Page 292
UE sends eNB RRC Connection Reconfiguration Complete
August, 2010
Page 293
eNB sends MME an Initial Context Setup Response message
August, 2010
Page 294
UE sends eNB RRC UL Info Transfer NAS Activate Default EPS Bearer Context Accept and Attach Accept
August, 2010
Page 295
eNB sends MME a UL NAS Transport + NAS Activate Default EPS Bearer Context Accept and Attach Complete
MME sends SGW a Modify Bearer request by GTP

SGW sends MME a Modify Bearer Response message by GTP


UE is in RRC_Idle mode UE has data and needs connection to network UE sends RRC Connection Request to eNB eNB sends RRC Connection Setup to UE UE sends RRC Connection Setup Complete and NAS Attach Request and PDN Connectivity Request to eNB eNB sends Initial UE Message and NAS Attach Request and PDN C Connectivity ti it R Request tt to MME MME sends Create Session Request to SGW using GTP SGW sends PMIP Proxy Binding Update to PGW PGW sends PMIP Proxy Binding Ack to SGW SGW sends Create Session Response to MME by GTP MME sends eNB an Initial Context Setup Request and NAS Activate Default EPS Bearer Context request and Attach Accept
Course 502 v1.1 (c)2010 Scott Baxter Page 299
August, 2010

eNB sends UE an RRC Connection Reconfiguration and NAS Activate Default EBS Bearer Context Request and Attach Accept UE sends eNB RRC Connection Reconfiguration Complete eNB sends MME an Initial Context Setup Response message UE sends eNB RRC UL Info Transfer NAS Activate Default EPS Bearer Context Accept and Attach Accept eNB sends MME a UL NAS Transport + NAS Activate Default EPS Bearer Context Accept and Attach Complete MME sends SGW a Modify Bearer request by GTP SGW sends MME a Modify Bearer Response message by GTP
August, 2010
Page 300
RRC Procedures (1)

RRC Procedures There are two RRC states in LTE. LTE RRC_Idle RRC Idle & RRC_Connected. RRC Connected In RRC_Idle there is no signaling radio bearer established, that is there is no RRC connection. In RRC RRC_Connected Connected a signaling radio bearer is established Signaling Radio Bearers(SRB) are defined as Radio bearers that are used only to transmit RRC and NAS messages. SRBs SRB are classified l ifi d i into t Si Signaling li R Radio di B Bearer 0 0: SRB0 SRB0: RRC message using CCCH logical channel. Signaling Radio Bearer 1: SRB1: is for transmitting NAS messages over DCCH logical channel channel. Signaling Radio Bearer 2: SRB2: is for high priority RRC messages. Transmitted over DCCH logical channel.
August, 2010
Page 301
RRC Procedures (2)

Paging To transmit paging info/system info to UE in RRC RRC_IDLE IDLE state state. RRC Connection Establishment to establish SRB1 This procedure is initiated by UE when upper layers requests of a signaling connection when UE is in RRC RRC_IDLE IDLE mode mode. RRC Connection Reconfiguration to establish/modify/release radio bearers, perform handovers RRC Connection Re-Establishment To re-establish RRC connection which involves SRB1 resumption and reactivation. Initial Security Activation Activate security upon RRC establishment. eNB initiated procedure.
August, 2010
Page 302
Flow Examples
Random Access
August, 2010
Page 303
LTE Random Access
To access the system for services, the idle UE performs the Random Access Procedure Procedure. The procedure deals with physical layer radio considerations such as contention between UEs and uncertain required UE transmit power to be successfully p y received at the eNodeB. The first step of the procedure is for the UE to send a Random Access Preamble. The Preamble allows the eNB to estimate the transmission timing of the terminal.
August, 2010
Page 304
LTE Random Access
Next the network transmits a Random Access Response. This consists of timing advance command to adjust the terminal transmit timing, g, based on timing g measurement received in the first step. In addition to establishing uplink synchronization this step also assigns uplink resources to be used in next steps to the terminal. i l A Temporary identity is also assigned to UE for further communication with the network. This response is sent on PDCCH PDCCH.
LTE Random Access
The Third step consists of transmission of mobile terminal identity to the network using UL-SCH. The exact content of this signal depends on the state of the terminal (whether the network previously knows it or not). (RRC_IDLE)
August, 2010
Page 306
LTE Random Access
The fourth step step consists of contention resolution message from network to terminal on DL-SCH
August, 2010
Page 307
LTE Packets
August, 2010
Page 308
GTPv2 Create Session Request (Malformed Packet)
August, 2010
Page 309
Flow Examples
Tracking Area Update
August, 2010
Page 310
Case VII. LTE Tracking Area Update
tracking

The UE is operating in LTE using the eNodeB, Old MME, SGW and PGW. PGW
August, 2010
Page 312
The UTE moves away from the LTE network and into the UTRAN/GERAN service area
August, 2010
Page 313
The UE sends a Routing Area Update to the Gn/Gp SGSN
August, 2010
Page 314
The Gn/Gp sends a Context Request to the Old MME
August, 2010
Page 315
The Old MME sends an SGSN Context Response to the Gn/Gp SGSN
August, 2010
Page 316
Security Processes are applied
August, 2010
Page 317
The Gn/Gp SGSN sends a SGSN Context ACK to the Old MME
August, 2010
Page 318
The Gn/Gp SGSN sends an Update PDP Context Request to the PGW
August, 2010
Page 319
Th The PGW sends d an Update U d t PDP Context C t t Response R to t the th Gn/Gp G /G SGSN
August, 2010
Page 320
The Gn/Gp SGSN sends an Update Location Request to the HSS
August, 2010
Page 321
The HSS sends an Insert Subscriber Data message to the Gn/Gp SGSN
August, 2010
Page 322
The Gn/Gp SGSN sends an Insert Subscriber Data Ack to the HSS
August, 2010
Page 323
The HSS sends an Update Location Ack to the Gn/Gp SGSN
August, 2010
Page 324
The Gn/Gp SGSN sends a Routing Area Accept to the UE
August, 2010
Page 325
The Old MME sends a Delete Session Request to the SGW
August, 2010
Page 326
The UE sends a Routing Area Complete to the Gn/Gp SGSN
August, 2010
Page 327
The SGW sends a Delete Session Response to the Old MME

The Old MME sends an S1 Release message to the Gn/Gp SGSN

Review, Summary and Conclusions
August, 2010
Page 330
12. Review, Summary and Conclusion

12-1 CP Implications on Performance Evaluation and Optimization 12-2 12 2 Concluding Remarks
August, 2010
Page 331
LTE Network Manufacturers

The Big 4: Ericsson AB (Nasdaq: ERIC) Nokia Siemens Networks Alcatel-Lucent (NYSE: ALU) Huawei Technologies Co. Ltd. Nipping at the heels: Fujitsu for NTT DoCoMo, remote RF pods Kyocera Motorola same hardware as for WiMax WiMax, in 2G/3G cabinets NEC very dense, cabinets or pole-mount form factors Nortel standalone and rackmount within CDMA & GSM BTS ZTE Unified Hardware Platform supports LTE+ other 2G/3G Samsung (handset mfr. too!
August, 2010 Course 502 (c)2010 Scott Baxter
Kyocera
NEC
Page 332
LTE Handset Manufacturers

Samsung for MetroPCS Dual-mode, Dual mode with EVDO fallback Announced Mar. 25, 2010 at CTIA Will be deployed in Las Vegas mkt.
August, 2010
Page 333
eNB Developments
Xilinx's LTE Baseband Targeted Design Platform Serves as complete LTE eNB channel card Intended for incorporation in manufacturers LTE eNBs http://www.youtube.com/watch?v=0n3Fbbca21Y&feature=channel
August, 2010
Page 334
LTE RF Design Tools

Atoll from Forsk http://www.forsk.com/ Aircomm ENTERPRISE: ADVANTAGE, ASSET, NetACT http://www.aircominternational.com/ Mentum Planet http://www.mentum.com/index.php?page=mentumplanet&hl=en_US Ascom TEMS Cellplanner p http://www.ascom.com/en/index/products-solutions/yourindustry/industry/5/solution/ant-planning-anddesign/product/tems-cellplanner-2/solutionloader.htm EDX SignalPro 7.2 http://www.edx.com/products/signalpro.html Capesso from Symena www.symena.com

LTE System Structure and Signalling

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

LTE System Structure and Signalling

Enviado por

Direitos autorais:

Formatos disponíveis

Course 502

LTE Long Term Evolution

Course 502 v1.1 (c)2010 Scott Baxter

LTE Network Architecture and Networking Components

Course 502 (c)2010 Scott Baxter

1. LTE Network Architecture and Networking Components

Course 502 v1.1 (c)2010 Scott Baxter

The LTE Air Interface A Quick Review

Course 502 (c)2010 Scott Baxter

The LTE Downlink and Uplink Signals

Course 502 (c)2010 Scott Baxter

Advanced Technologies of LTE

Course 502 (c)2010 Scott Baxter

The LTE Downlink Uses OFDMA

Course 502 (c)2010 Scott Baxter

The LTE Uplink Signal

Type 1 Forward Link Frames: For Frequency Division Duplex (FDD)

The Building Blocks of the Downlink Signal: Elements and Blocks

Downlink Physical Resources and Mapping

Course 502 (c)2010 Scott Baxter

Example of Downlink Control Signal Mapping

Course 502 (c)2010 Scott Baxter

Generic Frame Sequences

Each OFDM symbol y begins g with a cyclic y p prefix, , of duration below:

Course 502 (c)2010 Scott Baxter

Uplink Physical Resources and Mapping

Course 502 (c)2010 Scott Baxter

Uplink Format PUCCH 0 or 1

Course 502 (c)2010 Scott Baxter

UL SC-FDMA Subcarrier Options

LTE Physical Signals

Course 502 (c)2010 Scott Baxter

LTE Physical Channels

Course 502 (c)2010 Scott Baxter

SISO, MISO, SIMO, MIMO

SU-MIMO, MU-MIMO, Co-MIMO

Course 502 (c)2010 Scott Baxter

Course 502 (c)2010 Scott Baxter

The Evolved Packet System and the Evolved Packet Core

Course 502 v1.1 (c)2010 Scott Baxter

Networking Functional Elements (eNB; MME; SGW; PGW; PCRF; HSS)

Course 502 (c)2010 Scott Baxter

Networking Functional Elements (eNB; MME; Anchors/Gateways, PCRF; HSS)

SGSN GPRS CORE Iu S3 S5a S7 S5b S4

Mobility Management Entity User Plane Entity

S6a 3GPP Anchor SAE Anchor

Evolved RAN: eNB

Inter Access System Anchor

E l dP Evolved Packet k tC Core

Course S2K 5000 v1.5 (c)2010 Scott Baxter

Functions of Key Network Elements

Home Subscriber Server Super HLR

Evolved RAN: eNB

E l dP Evolved Packet k tC Core

1xRTT, 1 RTT CDMA2000, CDMA2000 EV-DO networks

WLAN 3GPP IP access

Course S2K 5000 v1.5 (c)2010 Scott Baxter

Integration of LTE, EVDO and HSPA

Home Subscriber Server (super HLR)

Policy and Charging Rules Function

Course S2K 5000 v1.5 (c)2010 Scott Baxter

LTE Standard Interfaces and Key Protocol Stacks

Course 502 (c)2010 Scott Baxter