Abd Motorola

LTE300: LTE Radio Link and EPS Signaling
LTE300: LTE Radio Link and EPS Signaling © 2010 Motorola, Inc.
FOR TRAINING PURPOSES ONLY - THIS MANUAL WILL NOT BE UPDATED
2010
Copyrights
The Motorola products described in this document may include copyrighted Motorola computer programs stored in semiconductor memories
or other media. Laws in the United States and other countries preserve for Motorola certain exclusive rights for copyright computer programs,
including the exclusive right to copy or reproduce in any form the copyright computer program. Accordingly, any copyright Motorola computer
programs contained in the Motorola products described in this document may not be copied or reproduced in any manner without the express
written permission of Motorola. Furthermore, the purchase of Motorola products shall not be deemed to grant either directly or by implication,
estoppel or otherwise, any license under the copyrights, patents or patent applications of Motorola, except for the rights that arise by operation
of law in the sale of a product.
Restrictions
The software described in this document is the property of Motorola. It is furnished under a license agreement and may be used and/or
disclosed only in accordance with the terms of the agreement. Software and documentation are copyright materials. Making unauthorized
copies is prohibited by law. No part of the software or documentation may be reproduced, transmitted, transcribed, stored in a retrieval system,
or translated into any language or computer language, in any form or by any means, without prior written permission of Motorola.
Accuracy
While reasonable efforts have been made to assure the accuracy of this document, Motorola assumes no liability resulting from any inaccuracies
or omissions in this document, or from the use of the information obtained herein. Motorola reserves the right to make changes to any products
described herein to improve reliability, function, or design, and reserves the right to revise this document and to make changes from time to
time in content hereof with no obligation to notify any person of revisions or changes. Motorola does not assume any liability arising out of the
application or use of any product or circuit described herein; neither does it convey license under its patent rights of others.
Trademarks
Motorola and the Motorola logo are registered trademarks of Motorola Inc.
M-Cell™, Taskfinder™ and Intelligence Everywhere™ are trademarks of Motorola Inc.
All other brands and corporate names are trademarks of their respective owners.
CE Compliance
The CE mark confirms Motorola Ltd’s statement of compliance with

EU directives applicable to this product. Copies of the Declaration
of Compliance and installation information in accordance with the
requirements of EN50385 can be obtained from the local Motorola
representative or the CNRC help desk, contact details below:
Email: csc.emea@motorola.com
Tel: +44 (0) 1793 565 444
© 2010 Motorola, Inc. LTE300: LTE Radio Link and EPS Signaling
2010
Contents
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
Chapter 1: Introduction to the 3GPP Evolved Packet System

Course Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1- 3
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1- 3
Prerequisite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1- 3
Target Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1- 3
Conventions Used in this Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1- 3
Purpose of the Participant Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1- 3
References and Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1- 3
Expectations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1- 5
Practicalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1- 5
Course Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1- 6
Course Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1- 6
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1- 8
Drivers for Long Term Evolution (LTE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10
3rd Generation Partnership Project (3GPP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12
GSM Network Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14
Global System for Mobile Communication (GSM) . . . . . . . . . . . . . . . . . . . . . . . 1-14
General Packet Radio Service (GPRS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15
Enhanced Data Rates for GSM Evolution (EDGE) . . . . . . . . . . . . . . . . . . . . . . . 1-15
Universal Mobile Telecommunications System (UMTS) Release 99 . . . . . . . . . . . . . . . 1-16
UMTS Release 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16
UMTS Release 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-17
UMTS Release 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-18
UMTS Release 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-19
UMTS Release 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20
How Does LTE Fit into 3GPP Roadmap? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-21
EPS Network Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-22
EPS Network Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-22
E-UTRAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24
E-UTRAN Air Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24
evolved NodeB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24
User Equipment (UE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-25
Evolved Packet Core (EPC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-28
Mobility Management Entity (MME) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-29
Serving Gateway (S-GW). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-30
Packet Data Network Gateway (P-GW) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-30
Selected EPS Reference Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-31
Other EPC Network Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-32
Interworking with Other Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-34
Motorola LTE Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-36
eNodeB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-36
Wireless Broadband Controller (WBC) 700 . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-38
Wireless Broadband Core (WBC) 700 as S-GW . . . . . . . . . . . . . . . . . . . . . . . . 1-39
Wireless Broadband Core (WBC) 700 as P-GW . . . . . . . . . . . . . . . . . . . . . . . . 1-40
Wireless Broadband Manager (WBM) 700 . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-40
WBM 700 Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-41
Motorola Support for GSM to LTE Migration/Overlay . . . . . . . . . . . . . . . . . . . . . . 1-41
Motorola Support for CDMA to LTE Overlay. . . . . . . . . . . . . . . . . . . . . . . . . . . 1-42
CDMA Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-42
Lesson Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-46
Memory Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-48
Chapter 2: LTE Air Interface – Physical Layer Basics

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2- 3
Radio Frequency Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2- 4
© 2010 Motorola, Inc. LTE300: LTE Radio Link and EPS Signaling i
2010
Contents LTE300: LTE Radio Link and EPS Signaling
LTE Spectrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2- 4
3GPP LTE Spectrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2- 4
Channel Bandwidth. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2- 5
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2- 6
Sampling Frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2- 7
Orthogonal Frequency Division Multiplexing (OFDM) . . . . . . . . . . . . . . . . . . . . . . . . 2- 8
Non-Orthogonal Subcarriers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2- 9
Orthogonal Frequencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10
OFDM Signal Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10
Subcarrier Transmitter Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11
Subcarrier Receiver Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12
IFFT Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13
FFT Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
FFT Algorithm Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
Scalable OFDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15
Subcarrier Spacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16
Symbol Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17
Multipath Delay and Inter-Symbol Interference . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18
Cyclic Prefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19
Subcarrier Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20
DC Subcarrier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20
Guard Subcarrier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21
Data Subcarriers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-22
Reference Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-22
Occupied Subcarriers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-23
LTE Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-25
LTE Frame Length and Subcarriers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-26
Channel Direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-27
Frequency Division Duplexing (FDD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-28
Time Division Duplexing (TDD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-29
FDD and Frame Type 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-30
Slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-30
Resource Blocks and Resource Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-32
Physical and Virtual Resource Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-33
Reference Signals, Normal TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-34
Reference Signals, Extended TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-35
Subframes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-37
FDD DL Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-38
FDD UL Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-39
TDD Operation and Frame Type 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-40
Frame Type 2 Special Subframe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-40
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-41
Frame Type 2 Configuration Exercise. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-42
Modulation Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-44
Modulation and Signal Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-44
Measuring Signal Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-45
Estimating FDD Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-46
Lesson Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-48
Memory Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-49
Chapter 3: LTE Air Interface – PHY Layer Advanced

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3- 3
OFDMA Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3- 4
OFDMA Transmitter Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3- 4
OFDMA Receiver Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3- 4
OFDM Bandwidth Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3- 5
OFDMA Bandwidth Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3- 6
OFDMA Modulation Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3- 7
OFDMA Subcarrier Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3- 8
OFDMA Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3- 9
Single Carrier-Frequency Division Multiple Access (SC-FDMA) . . . . . . . . . . . . . . . . . . 3-11
UE Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11
SC-FDMA Transmitter Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12
SC-FDMA Receiver Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
SC-FDMA Subcarrier Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
ii LTE300: LTE Radio Link and EPS Signaling © 2010 Motorola, Inc.
2010
LTE300: LTE Radio Link and EPS Signaling Contents
SC-FDMA Subcarrier Encoding, Continued . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15

SC-FDMA Precoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-16
Time Domain SC-FDMA Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17
Moving the SC-FDMA Symbol in the Frequency Domain . . . . . . . . . . . . . . . . . . . . 3-18
Channel Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19
Scrambling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19
Forward Error Correction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19
FEC Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-20
Rate Matching and HARQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-20
LTE Physical Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-22
Single Port Antenna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-22
2 Port Antenna DL Reference Signals, Normal TCP . . . . . . . . . . . . . . . . . . . . . . . 3-23
2 Port Antenna DL Reference Signals, Extended TCP . . . . . . . . . . . . . . . . . . . . . . 3-24
Antenna Port Layering, 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-25
4 Port Antenna DL Reference Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-26
4 Port Antenna DL Reference Signals – continued . . . . . . . . . . . . . . . . . . . . . . . 3-27
Antenna Port Layering, 4 Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-27
Synchronization Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-28
Synchronization Signals, Frame Type 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-28
Synchronization Signals, Frame Type 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-28
UL Demodulation Reference Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-30
Sounding Reference Signals (SRS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-31
Random Access Preamble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-32
Lesson Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-34
Memory Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-35
Chapter 4: LTE Channels

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4- 3
Uu Interface Sublayers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4- 4
LTE Channel Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4- 5
SAE Bearer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4- 5
Radio Bearer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4- 5
Signaling Radio Bearer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4- 5
Logical Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4- 6
Transport Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4- 6
Physical Channel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4- 6
Logical Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4- 7
Control Channels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4- 8
Traffic Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4- 8
Transport Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4- 9
Downlink Transport Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4- 9
Uplink Transport Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4- 9
Logical Channel to Transport Channel Mapping . . . . . . . . . . . . . . . . . . . . . . . . 4-10
Physical Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11
Downlink Physical Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11
Uplink Physical Channels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12
Transport to Physical Channel Mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12
Mapping DL Physical Channels to Subframes . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
Mapping PDSCH Subframes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
Resource Mapping for DL Control Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14
Mapping DL Control Channels to Subframes . . . . . . . . . . . . . . . . . . . . . . . . . . 4-15
PDCCH Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16
PDCCH Scheduling Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16
PDCCH MCS Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-18
PDCCH Transport Block Size Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20
Discontinuous Reception (DRX) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-21
Broadcast Channel (PBCH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-21
System Information Blocks (SIBs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-23
Mapping UL Physical Channels to Subframes . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24
Mapping PUSCH to Subframes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24
Mapping PUCCH to Subframes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24
Multiple PUCCH in One Subframe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-25
Random Access Channel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26
Lesson Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-28
Memory Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-29
© 2010 Motorola, Inc. LTE300: LTE Radio Link and EPS Signaling iii
2010
Chapter 5: Uu Interface Layer 2 Operation

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5- 3
TCP/IP Protocol Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5- 4
Uu Interface Sublayers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5- 5
Radio Resource Control (RRC) Sublayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5- 5
Packet Data Convergence Protocol (PDCP) Sublayer. . . . . . . . . . . . . . . . . . . . . . 5- 6
Radio Link Control (RLC) Sublayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5- 6
Medium Access Control (MAC) Sublayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5- 7
Uu Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5- 9
Uu Sublayers and Service Access Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10
Data Flow Through the Uu Sublayers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11
PDCP Headers and Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12
PDCP Header for Data Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13
PDCP Header for Control Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14
PDCP and Header Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-15
TCP/IP Protocol Suite and Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-15
ROHC Compressor States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16
Robust Header Compression (ROHC) Profiles . . . . . . . . . . . . . . . . . . . . . . . . . 5-16
ROHC Status PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18
PDCP Status Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-19
Radio Link Control (RLC) Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-20
RLC Packet Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-20
Transport Block Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-21
RLC Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-22
Unacknowledged Mode RLC PDU – One Data Element. . . . . . . . . . . . . . . . . . . . . 5-22
Acknowledged Mode RLC PDU – One Data Element . . . . . . . . . . . . . . . . . . . . . . 5-24
RLC Concatenation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-25
Acknowledged Mode RLC PDU – Multiple Data Elements . . . . . . . . . . . . . . . . . . . 5-25
RLC Segmenting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-26
Acknowledged Mode RLC PDU – Data Segment . . . . . . . . . . . . . . . . . . . . . . . . 5-27
ARQ Error Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-29
LTE and TCP/IP Error Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-29
ARQ Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-29
RLC Status PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-31
MAC Headers and Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-33
Packet Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-33
MAC Subheader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-35
MAC Control Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-38
Random Access Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-40
Random Access Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-40
Backoff Indicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-41
Random Access Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-42
Backoff Indicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-43
Random Access Response (RAR) Control Element Fields . . . . . . . . . . . . . . . . . . . 5-45
Random Access Response UL Grant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-46
HARQ Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-47
DL and UL Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-48
DL Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-48
UL Grant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-48
UE Cell-Based Identities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-48
Dynamic UL Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-49
Semi-Persistent Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-50
Buffer Status Report (BSR) Control Element . . . . . . . . . . . . . . . . . . . . . . . . . . 5-51
Buffer Size Values for Buffer Status Reports (BSRs) . . . . . . . . . . . . . . . . . . . . . . 5-53
Lesson Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-54
Memory Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-55
Chapter 6: EPC Protocol Overview

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6- 3
Selected EPS Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6- 4
EPS and TCP/IP Protocol Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6- 5
Control Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6- 6
Generic Control Message Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6- 7
Control Packet Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6- 8
iv LTE300: LTE Radio Link and EPS Signaling © 2010 Motorola, Inc.
2010
3–way Control Handshake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6- 9

User Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10
RRC Functions and Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11
RRC Signaling Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-12
RRC Signaling Messages and SRBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-14
S1-MME Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-15
S1-MME Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-15
S1-MME Interface Control Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16
S1 Application Protocol (S1AP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-17
S1AP Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-17
S1AP Signaling Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-18
Non-Access Stratum Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-20
UE to MME Control Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-20
Non-Access Stratum (NAS) Signaling Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 6-21
Non Access Stratum (NAS) Signaling Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 6-22
S1–U and S5 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-24
S1-U Interface User Plane Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25
S5-U User Plane Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-26
S5 Control Plane Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-27
Selected GTP-C Message Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-28
UE to P-GW User Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-29
S10 and S11 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-30
S10 Interface Control Plane Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-31
S11 Interface Control Plane Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-32
S6a Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-33
S6a Control Plane Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-34
Diameter Messages for E-UTRAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-35
X2 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-36
X2 Interface Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-36
X2 Control Plane Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-37
X2 Application Protocol (X2AP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-38
X2AP Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-38
X2AP Signaling Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-39
X2 User Plane Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-40
Mobility and X2 Data Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-41
Subscriber and Network Element Identities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-43
PLMN IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-43
MME Identities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-43
Subscriber IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-44
Selected EPS IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-46
Lesson Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-47
Memory Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-48
Chapter 7: UE States and LTE/SAE Signaling

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7- 3
Radio Resource Control (RRC) States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7- 4
Radio Resource Control (RRC) – Idle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7- 4
Radio Resource Control (RRC) – Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . 7- 4
Radio Resource Control (RRC) Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . 7- 4
EPS Mobility Management (EMM) States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7- 6
EPS Mobility Management (EMM) – Deregistered . . . . . . . . . . . . . . . . . . . . . . . 7- 6
EPS Mobility Management (EMM) – Registered . . . . . . . . . . . . . . . . . . . . . . . . 7- 6
EPS Connection Management (ECM) States . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7- 7
EPS Connection Management (ECM) – Idle . . . . . . . . . . . . . . . . . . . . . . . . . . 7- 7
EPS Connection Management (ECM) – Connect . . . . . . . . . . . . . . . . . . . . . . . . 7- 7
EPS Session Management (ESM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7- 8
ESM_INACTIVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7- 8
ESM_ACTIVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7- 8
Non Access Stratum (NAS) States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7- 9
EMM_DEREGISTERED, ECM_IDLE and ESM_INACTIVE . . . . . . . . . . . . . . . . . . . 7- 9
EMM_REGISTERED, ECM_IDLE and ESM_ACTIVE . . . . . . . . . . . . . . . . . . . . . . 7- 9
EMM_REGISTERED, ECM_CONNECT and ESM_ACTIVE. . . . . . . . . . . . . . . . . . . 7- 9
Context Information in the HSS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10
Context Information in the P-GW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11
Context Information in the UE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-12
© 2010 Motorola, Inc. LTE300: LTE Radio Link and EPS Signaling v
2010
Context Information in the MME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-13

Context Information in the S-GW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-14
Basic LTE Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-15
Attaching to the Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-16
NodeB Acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-17
System Information (SI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-18
Cell Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-20
Cell Service Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-20
UE Service Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-20
Network Attach Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-22
Procedure Starting Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-22
Procedure Ending Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-22
Network Attach Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-23
UE Service Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-27
Network Triggered Service Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-29
UE Triggered Detach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-31
Security in LTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-34
LTE Security Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-34
Function of LTE Security Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-35
Authentication and Key Agreement Process (AKA) . . . . . . . . . . . . . . . . . . . . . . . 7-35
Lesson Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-37
Memory Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-38
Chapter 8: Mobility Operation and Signaling

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8- 3
Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8- 4
Physical Layer Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8- 5
UE Measurement Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8- 5
E-UTRAN Measurement Abilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8- 6
General Description of Idle Mode Procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . 8- 8
Closed Subscriber Group (CSG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8- 9
Cell Selection and Reselection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-10
Cell Selection Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-11
Service Types in Idle Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-11
Cell Selection Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-12
Cell Reselection Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-13
Reselection priorities handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-13
Intra-frequency Measurement Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-13
Non Intra-frequency Measurement Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-14
Mobility States of a UE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-14
Intra-frequency and Equal Priority Inter-Frequency Cell Reselection Criteria. . . . . . . . . . . 8-15
E-UTRAN Inter-frequency and Inter-RAT Cell Reselection Criteria . . . . . . . . . . . . . . . 8-15
Tracking Area (TA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-17
Tracking Area Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-17
Tracking Area Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-18
MME and S-GW Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-19
MME Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-19
MME Pool Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-19
Serving Gateway (S-GW) Service Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-19
S-GW Serving Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-20
Serving Gateway (S-GW) Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-20
Tracking Area Updates (TAUs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-21
Tracking Area Update Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-21
Tracking Area Update (TAU) with no MME/S-GW Change . . . . . . . . . . . . . . . . . . . . . 8-22
Tracking Area Update (TAU) Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-23
TAU with MME and S-GW Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-26
TAU with MME and S-GW Change Procedure Steps . . . . . . . . . . . . . . . . . . . . . . 8-27
Connected Mode Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-32
Inter-RAT Measurements in Connected Mode. . . . . . . . . . . . . . . . . . . . . . . . . . 8-33
Measurement Report Triggering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-33
eNodeB (X2) Active Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-36
vi LTE300: LTE Radio Link and EPS Signaling © 2010 Motorola, Inc.
2010

eNodeB (X2) Active Handover Procedure Steps . . . . . . . . . . . . . . . . . . . . . . . . 8-37
Active Handover with MME and S-GW Change . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-42
Direct vs. Indirect Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-43
Active Handover with MME and S-GW Change Procedure Steps . . . . . . . . . . . . . . . . 8-44
Lesson Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-52
Memory Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-53
Chapter 9: Services and Bearer QoS

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9- 3
Quality of Service (QoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9- 4
QoS Functional Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9- 5
Bearer Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9- 6
Packet Forwarding and QoS Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9- 7
Quality of Service (QoS) / EPS Bearer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9- 8
End-to-End Bearer Service Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-10
QoS Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11
Traffic Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-12
Selected EPS Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-13
Basic Broadband . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-13
VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-13
Video On Demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-13
Push To Talk (PTT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-13
Basic Lawful Intercept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-13
Self Organizing Network (SON) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-14
IP Multimedia Subsystem (IMS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-15
Simplified IMS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-15
Serving Call Session Control Function (S-CSCF) . . . . . . . . . . . . . . . . . . . . . . . . 9-16
Proxy Call Session Control Function (P-CSCF) . . . . . . . . . . . . . . . . . . . . . . . . . 9-16
Media Gateway Control Function (MGCF) . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-16
Media Gateway (MGW) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-16
Application Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-16
IMS Signaling and Bearer Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-16
Signaling Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-17
VoIP to PSTN Bearer Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-17
VoIP to IP Device, Data, Other Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-17
Multimedia Broadcast/Multicast Service (MBMS) . . . . . . . . . . . . . . . . . . . . . . . . . . 9-18
MBMS Functional Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-18
Content Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-19
Broadcast Multicast Service Center (BM CS) . . . . . . . . . . . . . . . . . . . . . . . . . . 9-19
MBMS GW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-19
Multicell/Multicast Coordination Entity (MCE) . . . . . . . . . . . . . . . . . . . . . . . . . . 9-19
Lawful Intercept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-20
P-LIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-20
MME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-20
S-GW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-20
P-GW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-20
HSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-20
P-LIG Functions and Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-21
Self-Organizing Network (SON) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-22
Motorola SON Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-23
Proposed Motorola SON Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-24
Lesson Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-26
Memory Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-27
Chapter 10: Inter-Technology Mobility

Chapter 10 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10- 3
3GPP/3GPP2 Specifications Referenced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10- 4
What is Inter-RAT/Technology Mobility and Why is it Needed? . . . . . . . . . . . . . . . . . . . 10- 5
Cell Selection and Reselection in Idle Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 10- 5
Mobility in Connected Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10- 6
© 2010 Motorola, Inc. LTE300: LTE Radio Link and EPS Signaling vii
2010
Inter-RAT Mobility States Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10- 8

E-UTRA states and inter RAT mobility procedures, 3GPP . . . . . . . . . . . . . . . . . . . . 10- 8
Mobility procedures between E-UTRA and cdma2000 . . . . . . . . . . . . . . . . . . . . . 10- 9
Inter-RAT Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-10
E-UTRAN to UTRAN Iu mode Inter RAT handover . . . . . . . . . . . . . . . . . . . . . . . 10-10
E-UTRAN to GERAN A/Gb Mode Inter RAT Handover . . . . . . . . . . . . . . . . . . . . . 10-14
Circuit Switch Fallback in EPS for 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-19
Functional Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-20
Mobility Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-20
Mobile Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-22
EPS and CDMA Inter-Technology Working . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-24
Solutions to Inter-Technology Working . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-24
eHRPD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-25
Architecture for Optimized Handovers between E-UTRAN Access and cdma2000 HRPD
Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-26
Overview of Handover Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-27
Optimized Active Handover: E-UTRAN Access to cdma2000 HRPD Access . . . . . . . . . . 10-28
Single Radio Voice Call Continuity (SRVCC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-34
E-UTRAN and 3GPP2 1xCS SRVCC Concept . . . . . . . . . . . . . . . . . . . . . . . . . 10-34
E-UTRAN and 3GPP2 1xCS SRVCC Architecture . . . . . . . . . . . . . . . . . . . . . . . 10-34
SRVCC from E-UTRAN to 3GPP2 1xCS Procedure and Flow. . . . . . . . . . . . . . . . . . 10-36
Lesson Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-40
Memory Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-41
viii LTE300: LTE Radio Link and EPS Signaling © 2010 Motorola, Inc.
2010
About This Manual Version 2 Rev 4

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
© 2010 Motorola, Inc. LTE300: LTE Radio Link and EPS Signaling 1
2010
Version 2 Rev 4
This page intentionally left blank.
2 LTE300: LTE Radio Link and EPS Signaling © 2010 Motorola, Inc.
2010
Introduction to the 3GPP Evolved Packet System Version 2 Rev 4
Chapter 1
Introduction to the 3GPP Evolved Packet System
© 2010 Motorola, Inc. LTE300: LTE Radio Link and EPS Signaling 1-1
2010
Version 2 Rev 4 Introduction to the 3GPP Evolved Packet System
1-2 LTE300: LTE Radio Link and EPS Signaling © 2010 Motorola, Inc.
2010
Course Introduction Version 2 Rev 4
Course Introduction
Preface
The course is designed to provide an in depth technical introduction to the Evolved Packet System (EPS),
including the Long Term Evolution (LTE) and Evolved Packet Core (EPC) infrastructure, operations, and
signaling. In this course, we will focus on the LTE Uu (air) interface and LTE/SAE signaling and operation.
Prerequisite
Students should attend LTE100 Introduction to LTE before attending this course.
Target Audience
The primary audience of this course is Motorola and customer RF Engineers, Network Planning
Engineers, and Senior Technical Staff. A secondary audience includes anyone who requires a detailed
understanding of LTE/SAE concepts, operation, and signaling.
Conventions Used in this Guide

Throughout this guide, you will find icons representing various types of information. These icons serve
as reminders of their associated text.
Table 1-1
Indicates a Note or additional Indicates If/then situations. These

information that might be helpful to are found in many of the labs.
you.
Indicates a list of References that Indicates a Warning or Caution.

Telecoms
provide additional information about These generally flag a service
a topic. affecting operation.
LTE
300
Indicates a Lab that provides the Indicates a Memory Point. These

opportunity for you to exercise what provide a chance for the candidate
you’ve learned. to reflect on the training and if
necessary ask a relevant question.
Purpose of the Participant Guide

The Participant Guide contains the content that the instructor will cover during the course. Given the
interactive nature of instructor-led courses, this guide may not contain everything the instructor discusses.
Since the book is yours to take with you, feel free to make notes in it. You can also use it to document
key points, questions you’d like to pose and the answer(s), and if you are inclined, you can doodle in it.
While the Participant Guide can act as reference when you return to work, keep in mind that the
information does change. If you require technical references to the information presented in this
Participant Guide, always use the most current versions of the pertinent technical documentation.
2010
Version 2 Rev 4 Course Introduction
Course Introduction
References and Resources
The Participant Guide is not a technical book in the traditional, analytical sense. The material and
information contained here is subject to change. The following references were used in the development
of this course and should be used for most current information:
Table 1-2
Trade Press Books

Telecoms • Dahlman, Parkvall, Skolk, Beming; 3G Evolution: HSPA and LTE for Mobile Broadband, Ac
Press, 2nd edition 2008
LTE
300
• Lescuyer, Lucidarme; Evolved Packet System (EPS): The LTE and SAE Evolution of 3G U
John Wiley and Sons, 2008
3GPP Technical Specifications (www.3gpp.org)
• 23.122 NAS Procedures for Idle MS
• 23.401 GPRS Enhancements for E-UTRAN Access
• 23.402 Architecture Enhancements for non-3GPP Access
• 24.301 NAS Protocol for EPS
• 36.201 LTE Physical Layer, General Description
• 36.211 Physical Channels and Modulation
• 36.212 Multiplexing and Channel Coding
• 36.213 Physical Layer Procedures
• 36.214 Physical Layer Measurements
• 36.300 E-UTRA/E-UTRAN Overall description; Stage 2
• 36.321 Medium Access Control (MAC) Protocol Specification
• 36.322 Radio Link Control (RLC) Protocol Specification
• 36.323 Packet Data Convergence Protocol (PDCP) Specification
• 36.331 Radio Resource Control (RRC) Protocol Specification
• 36.410 S1 General Aspects and Principles
• 36.411 S1 Layer 1
• 36.412 S1 Signaling Transport
• 36.413 S1 Application Program (S1AP)
• 36.414 S1 Data Transport
• 36.420 X2 General Aspects and Principles
• 36.421 X2 Layer 1
• 36.422 X2 Signaling Transport
• 36.423 X2 Application Program (S1AP)
• 36.424 X2 Data Transport
MyNetworkSupport Web Page

The on-line support allows customers to open cases trouble tickets, open RMA’s to send boards back
for repair, and download technical documentation.
2010
Course Introduction Version 2 Rev 4
Course Introduction
Figure 1-1
The
TheURL
URLofofthe
URLof thecustomer
customersupport
supportweb
web
page
pageis:is:
h!h!ps://
ps://mynetworksupport.motorola.com
mynetworksupport.motorola.com
This
Thisisisa asecure
secureweb
website.
site.AApassword
Apassword
password
request form can be downloaded from
request form can be downloaded from
this page.
this ppage.
agge.
As LTE products continue to evolve, we will make a continued effort to keep this material up-to-date. All
suggestions and recommendations are welcomed. Please submit your recommended changes to the
instructor. Thanks for all your constructive feedback.
Expectations
The activities in this course will require individual and team participation and we ask you to:
• Ask questions
• Share openly
• Return promptly from lunch and breaks
• Avoid distracting others by turning off cell phones or setting them to voicemail or vibrate
• Respect others
• Have fun!!!
Practicalities
Many participants who attend this course may not be familiar with this location’s facilities or the
surrounding area. To ensure your comfort during this course, please make notes on the following
helpful information.
Locations
Restrooms close to classroom: _______________________________________________________
Restroom locations in building: _______________________________________________________
Lunch facilities in building: __________________________________________________________
Lunch facilities nearby: _____________________________________________________________
After hours activities

Where to eat?.........What to see?.........What to do?........
During class breaks, ask the instructor and other participants about local sites that may be of interest.
Jot down the information below.
2010
Course Introduction
Course Objectives
• Describe the EPS architecture and functional elements
• List LTE performance goals
• List Motorola LTE/SAE products
• Describe radio system components, operation and impairments
• Describe the LTE (Uu) air interface Physical Layer characteristics and operation
• Describe Uu scheduling and bandwidth management
• List the LTE air (Uu) interface Layer 2 functions and channels
• Describe the LTE air (Uu) interface Layer 2 headers and operation
• Describe UE states, including connected, active, and idle state
• Describe LTE and SAE signaling, including network entry and exit, data transfer, and mobility
between eNodeBs, MMEs, and SGWs
• List common services and QoS requirements
• Describe various inter-RAT interworking scenarios
Course Schedule
Table 1-3
Day 1
Course Introduction
Lesson 1 – Introduction to the 3GPP Evolved Packet System (EPS)
Lesson 2 – LTE Air Interface – Physical Layer Basics
Day 2
Lesson 3 – LTE Air Interface – Physical Layer Advanced
Lesson 4 – LTE Air (Uu) Interface Layer 2 Operation
Day 3
Lesson 5 – LTE Channels
Lesson 6 – LTE/SAE Interfaces and Protocol Stacks
Day 4
Lesson 7 – UE States and LTE/SAE Signaling
Lesson 8 – Mobility Operation and Signaling
Day 5
Lesson 9 – Services and Bearer QoS
Lesson 10 – Inter-RAT interworking
2010
2010
Version 2 Rev 4 Objectives
Objectives
At the completion of this lesson, you’ll be able to:
• Explain where LTE fits in the evolution of GSM/UMTS networks

• Describe the changes in network architecture introduced by LTE
• Describe the functional elements that comprise an EPS network
• List the performance goals of LTE
• Describe Motorola’s LTE network architecture
Figure 1-2 Lesson Context
2010
Version 2 Rev 4 Objectives
2010
Version 2 Rev 4 Drivers for Long Term Evolution (LTE)
Drivers for Long Term Evolution (LTE)
Figure 1-3 Drivers for Long Term Evolution (LTE)
Over the last several decades, technological advancements have had a huge impact on the telecom
industry as well as the consumer. Consumers are moving from the traditional “fixed” wireline or mobile
experience toward fixed/mobile convergence, an expectation that services and information are available
anytime, anywhere.
This expectation has forced changes in carrier business plans and services: fixed-line operators are
expanding their boundaries outside the home or business, while mobile operators are moving into the
fixed line voice and broadband business. The goal of both is to capture maximum revenue while trying
to meet the customer’s needs with what is referred to as Quadruple Play: TV, Internet, Telephone, and
Mobility.
Carrier success depends on providing Quadruple Play services with a low cost per bit, higher (broadband)
capacity, increased flexibility, and with global appeal.
To that end, the 3rd Generation Partnership Project (3GPP) has drafted a set of standards for the next
generation mobile broadband network: Long Term Evolution (LTE).
2010
Version 2 Rev 4 Drivers for Long Term Evolution (LTE)
2010
Version 2 Rev 4 3rd Generation Partnership Project (3GPP)
3rd Generation Partnership Project (3GPP)
Figure 1-4 3GPP Standards Organization
Formalized in December 1998, the 3rd Generation Partnership Project (3GPP) is a group of
telecommunications associations whose main goal is to make globally applicable specifications for
Third Generation (3G) mobile phone systems.
3GPP is responsible for developing global standards for Global System for Mobile Communication
(GSM) and all of its subsequent releases; General Packet Radio Service (GPRS), Enhanced Data
rates for GSM Evolution (EDGE), High-Speed Downlink Packet Access (HSDPA), High-Speed
Uplink Packet Access (HSUPA), IP Multimedia Subsystem (IMS), Multimedia Broadcast/Multicast
Service (MBMS), and Long Term Evolution (LTE).
2010
Version 2 Rev 4 3rd Generation Partnership Project (3GPP)
2010
Version 2 Rev 4 GSM Network Evolution
GSM Network Evolution
Figure 1-5 GSM Network Evolution
To understand where LTE fits into the GSM/UMTS network, let’s look at the evolution of GSM and UMTS
networks.
The following section is a brief review of GSM network evolution. Talk with
your instructor during breaks, before, or after class if you need further
explanation.
Global System for Mobile Communication (GSM)
Figure 1-6 GSM – The Starting Point
The Global System for Mobile Communication (GSM) is the most popular 2G standard for mobile
communication. It is estimated that over 80% of the global market uses GSM. Standardized in two
phases in 1992-1995, GSM initially supported circuit-switched voice services, circuit-switched data at
2.4, 4.8, and 9.6 kbps, and introduced Short Message Service (SMS).
2010
GSM Network Evolution Version 2 Rev 4

GSM Release 96 introduced higher speed circuit-switched data rates.
The 2G GSM network uses a 200 kHz air interface, and a Circuit Switched (CS) domain for digital
voice/signaling. The CS domain consists of one or more Mobile Switching Centers (MSC) and
(possibly) a Gateway Mobile Switching Center (GMSC) to interconnect with the Public Switched
Telephone Network (PSTN).
The Home Location Register (HLR) contains the subscriber records, including authentication
information and services associated with a subscriber.
The graphic shows an extremely simplified view of GSM, ignoring

critical functions such as Visited Location Register (VLR) and service
architectures.
General Packet Radio Service (GPRS)
Figure 1-7 GPRS/EDGE
Introduced in GSM Release 97, General Packet Radio Service (GPRS) is a 2.5 G packet data network
that shares the radio access network with GSM but has a separate Packet Switched (PS) core network.
In a GSM/GPRS network, data traffic is forwarded through the PS domain, while voice and SMS traffic
goes through the CS domain.
GPRS consists of Serving GPRS Support Nodes (SGSN) and Gateway GPRS Support Nodes
(GGSN). SGSNs and GGSNs support IP mobility tunnels based on the GPRS Tunneling Protocol
(GTP). GPRS has theoretical data rates between 56 and 114 kbps.
Enhanced Data Rates for GSM Evolution (EDGE)

Introduced in Release 99, Enhanced Data Rates for GSM Evolution (EDGE) provides coding and
modulation improvements to GPRS that support minimum 3G data rates from 236 kbps to 473 kbps
depending on coding and modulation techniques used. EDGE does not introduce any changes to the
network other than coding and modulation enhancements to the air interface to increase data speed.
2010
Universal Mobile Telecommunications System (UMTS) Release 99
Figure 1-8 UMTS Release 99
Introduced in Release 99, Universal Mobile Telecommunications System (UMTS) was designed
as the 3G replacement/evolution of GSM/GPRS. UMTS changes the air interface from 200 kHz Time
Division Multiple Access (TDMA) to 5 MHz Wideband Code Division Multiple Access (WCDMA).
Also, the BTS and BSC were replaced by the NodeB and Radio Network Controller . (RNC)
While UMTS was designed to coexist with GSM/GPRS, each new 3GPP release from this point forward
is referred to as UMTS Release n.
UMTS Release 4
2010

Introduced in 2000-1, UMTS Release 4 provided a more efficient circuit-switched domain by replacing
the MSC with an MSC Server and Media Gateways (MGW). This upgrade to the CS domain
dramatically reduced capital and upgrade costs, as well as reducing operational expenses for CS
domain trunk circuits.
Essentially, a MGW converts PCM voice samples to packet voice, and forwards the voice packets to a
terminating MGW over a data circuit. The terminating MGW converts the voice packets back to PCM
voice samples, and forwards the voice stream to the PSTN. The MSC Server, also called a soft-switch,
controls the MGWs, manages call setup, and handles all signaling requirements.
Although the MGW was intended to forward voice packets over IP, Bearer Independent Call Control
(BICC) allowed carriers to also use other packet data technologies such as ATM.
UMTS R4 does not affect data rates, services, or RAN or CS signaling techniques. The MSC Server and
MGWs emulate a traditional MSC.
With this release, 3GPP abandoned the “annual” release format (R97, R98,
etc.) and began numbering releases consecutively from 4.
UMTS Release 5
UMTS Release 5 (R5) introduced big changes to the UMTS network. Beginning in R5, all traffic is
transported via the PS domain using IP. Because all traffic is now forwarded by the PS domain, Release
5 removes the Circuit Switched domain from the network architecture.
Critical circuit switched functions, such as voice call setup, interconnecting with the PSTN, and so on,
are performed by the IP Multimedia Subsystem (IMS). An R5 compliant UE must communicate with
IMS using Session Initiation Protocol (SIP) signaling, and generate and receive voice over IP traffic
within the subscriber device.
UMTS R5 also introduced High Speed Downlink Packet Access (HSDPA); HSDPA increased peak
downlink throughput to 14.4 Mbps.
2010
UMTS Release 6
With the introduction of High Speed Uplink Packet Access (HSUPA), UMTS Release 6 increased the
peak uplink speed to 5.76 Mbps. UMTS R6 also enhanced IMS, and introduced Multimedia Broadcast
Multicast Services (MBMS) to support broadcast services such as mobile TV.
MBMS offers broadcast and/or multicast, unidirectional, point-to-multipoint, multimedia flows.
Broadcast and multicast are two completely different services. A broadcast service is transmitted to all
user devices which have the service activated in their equipment. A service provider does not attempt
to charge for or limit the broadcast transmission.
In contrast, a multicast service is subscription-based. A UE must have subscribed to the service and
explicitly joined the multicast group to receive the multicast transmission. A service provider may track,
control, and charge for the multicast transmission.
Examples of possible MBMS applications include audio/video streaming, audio/video downloading, file
downloading, and text/image distribution.
2010
UMTS Release 7
Along with enhancing IMS, UMTS Release 7 introduced Multiple Input Multiple Output (MIMO) antenna
technology and High Speed Packet Access+ (HSPA+). MIMO antenna systems significantly improve
radio network throughput and coverage. HSPA+ with 2X2 MIMO increases uplink speeds to 11.5 Mbps
and downlink speeds to 22 Mbps.
2010
UMTS Release 8
UMTS Release 8 introduced the Evolved Universal Terrestrial Radio Access Network (E-UTRAN)
and the Evolved Packet Core (EPC).
To reduce latency, the E-UTRAN collapsed the UMTS NodeB and RNC functionality into the evolved
NodeB (eNodeB). In addition to 5 MHz, the E-UTRAN radio access network supports 1.4, 3, 10, 15, and
20 MHz channels.
R8 with 2x2 MIMO and 64QAM modulation increases UL speeds to 23 Mbps, and DL speeds to 42 Mbps.
In the Evolved Packet Core, the SGSN and GGSN are replaced by the Serving Gateway (S-GW)
and Packet Data Network Gateway (P-GW). The Mobility Management Entity (MME) manages UE
mobility and paging functions.
2010
How Does LTE Fit into 3GPP Roadmap?
Figure 1-14 How Does LTE Fit into 3GPP Roadmap?
LTE can evolve directly from UMTS R5, R6 or R7. If using dual mode UEs or other overlay techniques,
LTE can interoperate with GSM/GPRS.
2010
Version 2 Rev 4 EPS Network Elements
EPS Network Elements
EPS Network Architecture
Figure 1-15 EPS Network Architecture
The UMTS Release 8 architecture consists of the EPC, E-UTRAN, and user entities (UEs).
The Evolved Universal Terrestrial Radio Access Network (E-UTRAN) is defined by UMTS Release
8 as Long Term Evolution (LTE).
System Architecture Evolution (SAE) defines the Evolved Packet Core (EPC). The EPC is an all IP,
packet switched network.
The Evolved Packet System (EPS) includes the EPC, LTE, and the end user terminals called User
Entities or User Equipment (UE).
2010
Version 2 Rev 4 EPS Network Elements
2010
Version 2 Rev 4 E-UTRAN
E-UTRAN
E-UTRAN Air Interface
Figure 1-16 E-UTRAN Air Interface
E-UTRAN air interface changes include new Physical Layer multiplexing, FDD and TDD duplexing, and
Multiple Input Multiple Output (MIMO) antennas
The LTE air interface uses Orthogonal Frequency Division Multiple Access (OFDMA) in the downlink
and Single Carrier Frequency Division Multiple Access (SC-FDMA) in the uplink. It also supports
both Frequency Division Duplex (FDD) and Time Division Duplex (TDD) schemes.
MIMO antenna systems are also now fully employed. MIMO uses multiple antennas at both the
transmitter and receiver, improving the network efficiency.
OFDMA, SC-FDMA, TDD, FDD, and MIMO are discussed in greater detail
Telecoms
in later lessons.
LTE
300
2010
E-UTRAN Version 2 Rev 4
E-UTRAN
evolved NodeB
Figure 1-17 evolved NodeB
The eNodeB is responsible for the following functions:
• Radio Resource Management – assignment, reassignment, and release of radio resources

• Routing user plane data to/from the S-GW
• Scheduling and transmission of paging messages received from the MME
• Scheduling and transmission of system broadcast information
• Measurement gathering for use in scheduling and mobility decisions
• Radio Protocol Support
• Non-Access Stratum (NAS) signaling
• EPC and RRC bearer activation/deactivation
• MME selection for handovers with MME change
3GPP TS 36.104 Base Station (BS) Radio Transmission and Reception
Telecoms
LTE
300
2010
E-UTRAN
User Equipment (UE)
Figure 1-18 User Equipment (UE)
The User Equipment (UE) must perform the following functions:
• Signal network entry and other state changes

• Report its Tracking Area location while in idle mode
• Request UL grants to transmit data while in active mode
• Act as PDCP, RLC, MAC, and PHY “client”. The eNodeB controls the air interface and all DL and
UL scheduling. The UE reacts to instructions from the eNodeB.
3GPP TS 36.101 User Equipment (UE) Radio Transmission and Reception
Telecoms
LTE
300
2010
2010
Version 2 Rev 4 Evolved Packet Core (EPC)
Evolved Packet Core (EPC)
Figure 1-19 Evolved Packet Core (EPC)
The Evolved Packet Core network is an all IP, packet switched network. The EPC consists of:
• Mobility Management Entity (MME) – key control node for the LTE access network
• Serving Gateway (S-GW) – routes and forwards data packets
• Packet Data Network Gateway (P-GW) – provides connectivity to external packet data networks
2010
Evolved Packet Core (EPC) Version 2 Rev 4
Mobility Management Entity (MME)
Figure 1-20 Mobility Management Entity (MME)
The MME helps authenticate UEs onto the system, tracks active and idle UEs, and pages UEs when
triggered by the arrival of new data.
When a UE attaches to an eNodeB, the eNodeB selects an MME. The MME in turn selects the Serving
Gateway (S-GW) and the Packet Data Network Gateway (P-GW) that will handle the user’s bearer
packets.
Other MME functions include:
• Non-Access Stratum (NAS) signaling

• Authentication (in conjunction with the Home Subscriber Server – HSS)
• Idle State Mobility Handling
• SAE (EPC) Bearer Control
• Lawful Intercept
2010
Serving Gateway (S-GW)
Figure 1-21 Serving Gateway (S-GW)
The S-GW routes and forwards user data packets, terminates downlink data for idle UEs, and is also the
local mobility anchor for inter-eNodeB handovers. The mobility anchor function applies to both a UE in
the E-UTRAN and other 2G/3G technologies. The S-GW also maintains a buffer for each idle UE and
holds the packets until the UE is paged and an RF channel is re-established. For each UE associated
with the EPC, at a given point of time, there is a single S-GW.
Other S-GW functions include:
• Policy enforcement point

• IP backhaul admission control
• IP backhaul congestion control
• IP backhaul QoS
• Core IP QoS
• Billing records
• Lawful intercept
• Call trace
2010

Packet Data Network Gateway (P-GW)
Figure 1-22 Packet Data Network Gateway (P-GW)
The P-GW is responsible for the UE IP address assignment and provides UE connectivity to the external
packet data networks (operator’s network and Internet). The P-GW provides charging (billing) support,
packet filtering/screening, policy enforcement, and lawful intercept. If a UE is accessing multiple packet
data networks, it may have connectivity to more than one (1) P-GW.
Other P-GW functions include:
• Mobile IP (MIP) anchor point across E-UTRAN and non 3GPP technologies (i.e. WiMAX, 3GPP2,
WiFi, etc.)
• DHCP server and client
• Transport level packet marking in uplink and downlink
• Transfer of QoS policy and charging rules from Policy and Charging Rules Function (PCRF) to
the Policy and Charging Enforcement Function (PCEF) within the P-GW
• UL and DL bearer binding
• UL bearer binding verification
2010

Selected EPS Reference Points
Figure 1-23 Selected EPS Reference Points
• S1-MME – Supports the control plane between E-UTRAN and MME

• S1-U – Supports the bearer plane between E-UTRAN and S-GW for the per-user tunneling and
inter-eNodeB path switching during handover
• S5 – Supports the bearer plane between an S-GW and P-GW in the same network
• S8 – Supports the bearer plane between an S-GW and P-GW in different networks
• S10 – Supports transfer of context and other information between MMEs
• S11 – Supports information transfer between MME and S-GW for session management functions
• SGi – Connects the P-GW to an external data network
• Uu – Air interface between eNodeB and UE
• X2 – The X2 interface is defined between adjacent eNodeBs. The X2 is used for mobility control,
bearer forwarding, and load management
2010

Other EPC Network Elements
Figure 1-24 Other EPC Network Elements
Home Subscriber Server (HSS)

The HSS is the master database that contains the UE profiles and authentication data used by the MME
for authenticating and authorizing UEs. It also stores the location information of the UE which is used for
user mobility and inter-technology handovers. The HSS communicates with the MME using the Diameter
protocol over the S6a interface.
Diameter is defined in many IETF and 3GPP specifications. The technical specifications listed below are
a good starting point for understanding Diameter.
IETF RFC 3588 Diameter Base Protocol

Telecoms
IETF RFC 3589 Diameter Command Codes for 3GPP R5
3GPP TS 29.230 Diameter Applications; 3GPP Specific Codes and
LTE
300
Identifiers
2010

Policy and Charging Rules Function (PCRF)
The PCRF creates policy and charging rules for LTE UEs. It provides network control for service data
flow detection, gating, QoS authorization and flow based charging.
• Applies the security procedures, as required by the operator, before accepting service information
• Decides how a certain service data flow will be treated in the P-GW and ensures that the P-GW
user plane traffic mapping and treatment matches the user’s subscription profile
• Communicates with the P-GW over the S7 interface
• Provides the S-GW with QoS policy and traffic flow mapping information over the Gxc interface
• Transfers application policy and charging information with IMS over the Rx interface
Packet Lawful Intercept Gateway (P-LIG)

The P-LIG provides the interfaces between the LTE/EPC network and Law Enforcement Agencies
(LEAs), enabling the LEAs to intercept UE communications.
• Communicates with the HSS, MME, S-GW, and P-GW over the X1, X2, and X3 interfaces
• The P-LIG X2 interface is different from the eNodeB X2 interface
Interworking with Other Technologies
Figure 1-25 Interworking with Trusted 3GPP and Non-3GPP Networks
Serving GPRS Support Node (SGSN)

In 2G and 3G systems, the Serving GPRS Support Node (SGSN) is responsible for the delivery of
data packets to and from UEs within its geographical service area. The SGSN provides the interfaces
between the MME and S-GW in the EPC.
Trusted Non-3GPP Access

“Non-3GPP IP Access” describes access to the EPC by technologies not defined by 3GPP. Non-3GPP
access technologies include WiFi, WiMAX, fixed access such as cable or DSL, and so on. System
Architecture Evolution (SAE) describes trusted and untrusted non-3GPP IP access.
The individual carrier must decide if a non-3GPP network is trusted or untrusted. This is a business
decision and does not depend on the access network technology.
2010

Figure 1-26 Interworking with Untrusted Non-3GPP Networks
evolved Packet Data Gateway (ePDG)

The evolved Packet Data Gateway (ePDG) connects the LTE network to an untrusted, non-3GPP
network. To access the LTE network, the non-3GPP subscriber must establish an IP Security (IPSec)
tunnel via the ePDG. The ePDG is the encapsulation/decapsulation point for Mobile IP/Proxy Mobile
IP (MIP/PMIP).
The ePDG also authenticates, authorizes, and enforces QoS policies in conjunction with the 3GPP AAA
server.
3GPP AAA Server

The 3GPP AAA server provides authentication, authorization, and accounting services for untrusted,
non-3GPP IP access.
2010
Version 2 Rev 4 Motorola LTE Architecture
Motorola LTE Architecture
Figure 1-27 Motorola LTE Architecture
In this section, we will discuss the platforms used for the Motorola suggested minimum offering; the
eNodeB; the Wireless Broadband Core (WBC) 700 MME, the Wireless Broadband Core (WBC) 700
S-GW and P-GW, and the Wireless Broadband Manager (WBM) 700.
This section will give you a general idea of Motorola’s solution for each of the
LTE Network Elements.
2010
Motorola LTE Architecture Version 2 Rev 4

eNodeB
Figure 1-28 eNodeB Types
Motorola’s eNodeB consists of a site control / baseband chassis and a radio unit.
The eNodeB comes in two different configurations:
• Traditional Frame where all equipment is co-located in a 19”, indoor frame configuration
• Remote Radio Head where the transceiver and Power Amplifier (PA) are mounted on the roof, wall,
or pole, and the baseband controller is mounted at the bottom of the tower (enclosed) or mounted
indoors in a 19” rack.
2010
Wireless Broadband Core (WBC) 700
Figure 1-29 Wireless Broadband Core (WBC) 700
Motorola’s Wireless Broadband Core (WBC) 700 performs the functions of the MME. It leverages the
WiMAX Carrier Access Point Controller (CAPC) hardware.
Subscriber Capacity
• Coverage Only Model: 8 Million UEs

• Dense Urban or Rural Model: 4 Million UEs
• Regional or High Mobility Model: 2 Million UEs
Each MME Supports
• Up to 8192 eNodeBs
• Up to 32 MMEs per MME pool
• Up to 8000 Tracking Areas (per MME Pool)
• Simultaneous communication to 128 MMEs, however the number of MMEs which can be connected
dynamically is unlimited
• Up to 128 S-GW Service Areas
• Up to 51 eNodeBs per Tracking Area
• Up to 64 HSSs
• 2 AAAs
2010
Wireless Broadband Core (WBC) 700 as S-GW
Figure 1-30 WBC 700 as S-GW
Motorola’s Wireless Broadband Core (WBC) 700 performs the functions of the Serving Gateway
(S-GW) and Packet Data Network Gateway (P-GW). The WBC 700 is a carrier-grade, fully redundant
Linux platform that can be employed in several configurations:
• Standalone S-GW or,

• Standalone P-GW or,
• Combined S-GW and P-GW
2010
Wireless Broadband Core (WBC) 700 as P-GW
Figure 1-31 WBC 700 as P-GW
Wireless Broadband Manager (WBM) 700
Figure 1-32 WBM 700
The Element Management System (EMS) for the eNodeB, WBC 700 MME, WBC 700 S-GW, and WBC
700 P-GW is the WBM 700. The WBM 700 leverages the implementation of the low cost reference
management architecture defined by the Motorola Public Safety team. The platform is comprised of a
collection of Sun T5440 servers to provide the required processing and RAID disk drive array systems
to provide multiple Terabytes of storage capability.
2010
WBM 700 Features
Figure 1-33 WBM 700 Features
Motorola Support for GSM to LTE Migration/Overlay
Figure 1-34 GSM to LTE Migration
For operators with installed GSM infrastructure, Motorola provides a migration path based on the
Motorola GSM Horizon II BTS to support both GSM and LTE access functionality in a single base
station. The Horizon II operating in the 900/1800 band supports a smooth migration to LTE. For
operators with additional spectrum, Motorola can also provide a complete LTE overlay network to work
in conjunction with the installed GSM base.
Migration to LTE in the 900/1800 MHz band would entail:
• Hardware upgrade of the radio modem by adding the rack mounted LTE BCU 3
• Firmware upgrade to the radio Power Amplifier (PA)
• Provisioning an IP connection from the radio modem to link into the EPC
• No changes to feeders, antennas or other site ancillary equipment
• No other changes to BTS cabinet (apart from LTE BCU 3)
2010
Motorola Support for CDMA to LTE Overlay
Figure 1-35 CDMA LTE Overlay
Motorola will offer the ability to add LTE via a modular expansion of installed 1X or DO Universal Base
Stations (UBS), regardless of band. Initially both the user interface and backhaul will remain common.
Motorola’s solution will enable combining onto existing antennas for use on an existing band or allow the
addition of a separate band within the same frame.
The above illustration shows the upgrade path – adding LTE in a separate band to an existing UBS frame.
2010

CDMA Evolution
Figure 1-36 CDMA Evolution
cdma2000 technical specifications are established by the 3rd Generation Partnership Project 2
(3GPP2). 3GPP2 was set up in late 1998 to create globally applicable specifications for CDMA 3G
mobile phone systems. 3GPP2 working groups and standards are found at www.3gpp2.org.
CDMAOne
Introduced in 1993, CDMAOne was based on the IS-95 standard. Like its counterpart GSM, CDMAOne
is a voice and low speed circuit switched data network that provides circuit switched data rates of 14.4
kbps.
CDMA2000 1x
Similar to GPRS, cdma2000 added packet switching to CDMAOne. The packet switching network initially
supported peak data rates of 153 kbps in both downlink and uplink. 1x refers to the number of CDMA
1.25 MHz channels.
CDMA 1x EV-DO Rev 0 (Evolution-Data Optimized Revision 0)

CDMA 1x EV-DO Rev 0 improved packet data throughput to 2.4 Mbps downlink and 153 kbps uplink for
FDD operation. In commercial networks, Rev 0 supports an average 300-700 kbps downlink and 70-90
kbps uplink. The UL rate does not provide adequate bandwidth for real-time services. The packet data
network provides an “always-on” IP service.
2010

CDMA 1x EV-DO Rev A (Evolution-Data Optimized Revision A)
CDMA 1x EV-DO Rev A increased the downlink data rate to 3.1 Mbps and the uplink data rate to 1.8
Mbps. In commercial networks, Rev A supports an average 450-800 kbps downlink and 300-400 kbps
uplink. The improved UL bandwidth and low average latency (<50 ms) allow Rev A to support real-time
services. Rev A is an all-IP service, supporting Voice Over IP (VoIP).
CDMA 1x EV-DO Rev B (Evolution-Data Optimized Revision B)

Rev B aggregates multiple Rev A 1x channels into a high performance broadband service. For example,
15x (20 MHz) service supports 46.5 Mbps downlink and 27 Mbps uplink. Rev B also incorporates
Orthogonal Frequency Division Multiplexing (OFDM) and Multiple In Multiple Out (MIMO) in the
air interface.
UMB (Ultra Mobile Broadband)

UMB was intended as the next evolutionary step beyond Rev B, incorporating improved MIMO
performance and so on. Because Qualcomm dropped support for UMB, this step is essentially dead.
2010
2010
Version 2 Rev 4 Lesson Summary
Lesson Summary
In this lesson you learned about:
• LTE’s role in the GSM/UMTS evolution

• The functions of the network elements in the Evolved Packet System (EPS)
• LTE performance goals
• Motorola’s LTE architecture
2010
2010
Version 2 Rev 4 Memory Points
Memory Points
Take a few minutes to recall key points that you may use in the
near future or that may address a current need. This is also a
good opportunity to jot down a question. If the debriefing of key
points does not address your question, ask it during this exercise
or during a break period. Be prepared to share a key point or
question with others in the class
Key Point – Something New:
Key Point – Something Forgotten, but Relearned:
Question on what was just covered:
2010
LTE Air Interface – Physical Layer Basics Version 2 Rev 4
Chapter 2
LTE Air Interface – Physical Layer Basics
In this lesson, we will discuss LTE Radio Frequency parameters, OFDM concepts, LTE Frame structure, OFDMA
and SC-FDMA operation, modulation and coding schemes, and LTE antenna systems.
2010
Version 2 Rev 4 LTE Air Interface – Physical Layer Basics
2010
Objectives Version 2 Rev 4
Objectives
At the completion of this lesson, you will be able to:
• State the operating frequencies used by the LTE air interface

• Describe OFDM subcarrier and symbol characteristics
• Describe LTE duplexing and framing methods
• List the modulation techniques used by the LTE air interface
• Estimate FDD DL and UL capacity
3GPP TS 36.101 UE Radio Transmission and Reception
Telecoms
3GPP TS 36.104 BS Radio Transmission and Reception
3GPP TS 36.201 LTE Physical Layer, General Description
LTE
300
3GPP TS 36.211 Physical Channels and Modulation

3GPP TS 36.212 Multiplexing and Channel Coding
3GPP TS 36.213 Physical Layer Procedures
3GPP TS 36.214 Physical Layer Measurements
2010
Version 2 Rev 4 Radio Frequency Parameters
Radio Frequency Parameters
LTE Spectrum
Figure 2-2 LTE Spectrum
In addition to new RF bands, LTE reuses the cellular IMT-2000 spectrum. Because the initial focus is on
Frequency Division Duplexing (FDD) operation, LTE needs paired spectrum. An important objective
for LTE is RF band coordination to facilitate roaming across each of the global regions.
3GPP LTE Spectrum
E-UTRA Frequency Bands

E-UTRA Duplex
Uplink (UL) Downlink (DL)
Band Mode
1 1920–1980 MHz 2110–2170 MHz FDD
2 1850–1910 MHz 1930–1990 MHz FDD

3 1710–1785 MHz 1805–1880 MHz FDD
4 1710–1755 MHz 2110–2155 MHz FDD
5 824–849 MHz 869–894 MHz FDD
6 830–840 MHz 875–885 MHz FDD
7 2500–2570 MHz 2620–2690 MHz FDD
8 880–915 MHz 925–960 MHz FDD
9 1749.9–1784.9 MHz 1844.9–1879.9 MHz FDD
10 1710–1770 MHz 2110–2170 MHz FDD
11 1427.9–1452.9 MHz 1475.9–1500.9 MHz FDD
12 698–716 MHz 728–746 MHz FDD
13 777–787 MHz 746–756 MHz FDD
14 788–798 MHz 758–768 MHz FDD
...
17 704–716 MHz 734–746 MHz FDD
...
2010
Radio Frequency Parameters Version 2 Rev 4

E-UTRA Frequency Bands
E-UTRA Duplex
Uplink (UL) Downlink (DL)
Band Mode
33 1900–1920 MHz TDD
34 2010–2025 MHz TDD
35 1850–1910 MHz TDD
36 1930–1990 MHz TDD
37 1910–1930 MHz TDD
38 2570–2620 MHz TDD
39 1880–1920 MHz TDD
40 2300–2400 MHz TDD
E-UTRA is designed to operate in the RF bands listed above
3GPP TS 36.101 E-UTRA UE Radio Transmission and Reception

Telecoms
LTE
300
Channel Bandwidth
Figure 2-3 Channel Bandwidth
2010
Version 2 Rev 4 Radio Frequency Parameters
E-UTRA Frequency Bands and Channel Bandwidth

Duplex
E-UTRA Uplink (UL) Downlink (DL) Channel BW Supported
Mode
1 1920–1980 MHz 2110–2170 MHz FDD 5, 10, 15, 20 MHz
2 1850–1910 MHz 1930–1990 MHz FDD 1.4, 3, 5, 10, 15Note1,
20Note1 MHz
3 1710–1785 MHz 1805–1880 MHz FDD 1.4, 3, 5, 10, 15Note1,
20Note1 MHz
4 1710–1755 MHz 2110–2155 MHz FDD 1.4, 3, 5, 10, 15, 20 MHz
5 824–849 MHz 869–894 MHz FDD 1.4, 3, 5, 10Note1 MHz
6 830–840 MHz 875–885 MHz FDD 5, 10Note1 MHz
7 2500–2570 MHz 2620–2690 MHz FDD 5, 10, 15, 20Note1 MHz
8 880–915 MHz 925–960 MHz FDD 1.4, 3, 5, 10Note1 MHz

9 1749.9–1784.9 1844.9–1879.9 FDD 5, 10, 15Note1, 20Note1
MHz MHz MHz
10 1710–1770 MHz 2110–2170 MHz FDD 5, 10, 15, 20 MHz
11 1427.9–1452.9 1475.9–1500.9 FDD 5, 10Note1, 15Note1, 20Note1
MHz MHz MHz
12 698–716 MHz 728–746 MHz FDD 1.4, 3, 5Note1, 10Note1 MHz
...
...
33 1900–1920 MHz TDD 5, 10, 15, 20 MHz
34 2010–2025 MHz TDD 5, 10, 15 MHz
35 1850–1910 MHz TDD 1.4, 3, 5, 10, 15, 20 MHz
36 1930–1990 MHz TDD 1.4, 3, 5, 10, 15, 20 MHz
37 1910–1930 MHz TDD 5, 10, 15, 20 MHz
38 2570–2620 MHz TDD 5, 10 MHz
39 1880–1920 MHz TDD 5, 10, 15, 20 MHz
40 2300–2400 MHz TDD 10, 15, 20 MHz
Note1 The UE receiver sensitivity may be relaxed when operating at this channel bandwidth.
3GPP TS 36.101 E-UTRA UE Radio Transmission and Reception

Telecoms
LTE
300
2010
Radio Frequency Parameters Version 2 Rev 4
Sampling Frequency
Figure 2-4 Channel Sampling Frequency
What is the “actual” channel bandwidth? We must “over-sample” the nominal channel bandwidth to
account for guard bands and orthogonal spacing of subcarriers. The resulting channel bandwidth is
called the Sampling Frequency (FS).
The table shows the Sampling Frequency for each supported channel size. We will use FS to calculate
subcarrier spacing and, indirectly, symbol time.
Sampling Frequencies
Nominal Channel Bandwidth
Parameters 1.4 MHz 3 MHz 5 MHz 10 MHz 15 MHz 20 MHz
Sampling 1.92 3.84 MHz 7.68 MHz 15.36 23.04 MHz 30.72 MHz
Freq (Fs) MHz MHz
2010
Version 2 Rev 4 Orthogonal Frequency Division Multiplexing (OFDM)
Orthogonal Frequency Division Multiplexing (OFDM)
Figure 2-5 Orthogonal Frequency Division Multiplexing (OFDM)
Orthogonal Frequency Division Multiplexing (OFDM) divides the channel bandwidth into lower
bandwidth subcarriers. Each subcarrier uses a different, equally-spaced center frequency to carry
modulated data or reference signals.
All data subcarriers may be modulated for simultaneous transmission during a time interval called the
symbol time.
Orthogonal Frequency Division Multiple Access (OFDMA) and Single Carrier Frequency Division
Multiple Access (SC-FDMA) add multiple access techniques to OFDM. We will discuss OFDMA and
SC-FDMA later in this lesson.
2010
Non-Orthogonal Subcarriers Version 2 Rev 4
Non-Orthogonal Subcarriers
Figure 2-6 Non-Orthogonal Subcarriers
OFDM divides the channel into lower-bandwidth, non-interfering subcarriers.

Without OFDM, the sidebands and harmonics of a frequency would interfere with adjacent frequencies.
The traditional solution is to insert guard bands between the frequencies. The graphic shows
non-orthogonal frequencies at an instant in time. Do you see that the frequency sidebands interfere
with each other?
2010
Version 2 Rev 4 Orthogonal Frequencies
Orthogonal Frequencies
Figure 2-7 Orthogonal Frequencies
In OFDM the channel is divided into many equally-spaced, lower-bandwidth subcarriers. Orthogonal
frequencies are designed (spaced) so they don’t interfere with each other, and don’t require guard bands
between subcarriers.
Do you see that the sidebands for frequencies f1 and f3 are null at frequency f2? If a receiver samples
an orthogonal subcarrier at precisely the correct (center) frequency, there is no inter-carrier interference
from the adjacent subcarriers.
OFDM Signal Requirements

• An integer number of cycles during an OFDM symbol
• An integer number of Hz separating the subcarriers
• No phase or amplitude changes may occur during the OFDM symbol
2010
Subcarrier Transmitter Operation Version 2 Rev 4
Subcarrier Transmitter Operation
Figure 2-8 Subcarrier Transmitter Operation
Imagine that every subcarrier is associated with a separate modem, and each “modem” operates at
a different center frequency. Each subcarrier modulates some number of bits (called a symbol), and
transmits the modulated signal simultaneously during a time interval called the symbol time.
This example shows blocks of 4 bits modulated by each

subcarrier, or 16QAM modulation. As we will see, groups of
subcarriers may use different modulation and coding schemes
during the same symbol time.
2010
Version 2 Rev 4 Subcarrier Receiver Operation
Subcarrier Receiver Operation
Figure 2-9 Subcarrier Receiver Operation
At the receiver, each subcarrier receives the modulated signal at its specific frequency, demodulates the
signal into bits, and restores the original bit pattern.
2010
IFFT Operation Version 2 Rev 4
IFFT Operation
Figure 2-10 IFFT Operation
We don’t actually have hundreds or thousands of modems in each eNodeB or UE. Instead, a single
modem modulates the bits and uses special algorithms called Fast Fourier Transforms (FFT) to convert
the modulated signals between the time and frequency domains.
As shown in the graphic, the transmitter modem performs Inverse Fast Fourier Transforms (IFFT) to
convert the modulated signals to a single summed output.
The graphic shows only some of the steps involved in

transmitting modulated symbols over the air. We will cover the
transmission steps in the next lesson.
From a transmitted power and radio frequency perspective,

a single modem performing IFFT looks exactly like individual
“mini-modems” (1 per subcarrier). For example, modulation
and IFFT for 512 subcarriers generates the same output as 512
individual modems (1 per subcarrier).
2010
Version 2 Rev 4 FFT Operation
FFT Operation
Figure 2-11 FFT Operation
The receiving modem uses FFT processing to convert the received signal back to its constituent
modulated signals. Demodulation converts the modulated signals back to bits.
FFT Algorithm Requirements
• An integer number of cycles during an OFDM symbol

• An integer number of Hz separating the subcarriers
• No phase or amplitude changes may occur during the OFDM symbol
The term FFT is used interchangeably with the total number of
subcarriers.
2010
Scalable OFDM Version 2 Rev 4
Scalable OFDM
Figure 2-12 Scalable OFDM
Scalable OFDM uses different numbers of subcarriers based on the channel size. For example, a 1.4
MHz channel is divided into 128 subcarriers (128 FFT), while a 10 MHz channel uses 1024 subcarriers
(1024 FFT). For LTE, the OFDM subcarrier spacing and symbol characteristics are identical; only the
FFT size and channel bandwidth vary.
The table below shows the number of FFT (subcarriers) for each channel size.
FFT and Channel Bandwidth

Freq (Fs) MHz MHz
NFFT 128 256 512 1024 1536 2048
2010
Version 2 Rev 4 Subcarrier Spacing
Subcarrier Spacing
Figure 2-13 Subcarrier Spacing
How “big” is a subcarrier? Because the subcarrier center frequencies are equally spaced across the
channel bandwidth, we can calculate the subcarrier spacing (Δf) by dividing the Sampling Frequency
(FS) by the number of subcarriers
Calculating Subcarrier Spacing

Δf = Fs/NFFT
Freq (Fs) MHz MHz
NFFT 128 256 512 1024 1536 2048
Subcarrier 15 kHz
Spacing (Δf)
For Multimedia Broadcast/Multicast Service (MBMS) traffic,

LTE supports both 15 kHz (non-dedicated cell) and 7.5 kHz
(dedicated cell) subcarrier spacing.
2010
Symbol Time Version 2 Rev 4
Symbol Time
Figure 2-14 Symbol Time vs. Subcarriers
The symbol time is the time interval used across all the subcarriers for simultaneous operation and
modulation. A symbol represents one encoded/modulated block of bits, based on the modulation and
coding scheme selected for each group of subcarriers. During a symbol time, data subcarriers may carry
modulated bits, while reference subcarriers carry signals used to estimate channel quality.
The symbol time is the inverse of the subcarrier spacing (1/ Δf). For LTE 15 kHz subcarriers, each symbol
time is 66.67 microseconds long. MBMS 7.5 kHz subcarriers use 133 microsecond symbols.
OFDM combines many symbol times into fixed-length,

time-dependent radio frames. For LTE, a radio frame is exactly
10 milliseconds long. We will explore the frame structure later
in this lesson.
2010
Version 2 Rev 4 Multipath Delay and Inter-Symbol Interference
Multipath Delay and Inter-Symbol Interference
Figure 2-15 Multipath Delay and Inter-Symbol Interference
How do we account for multipath delay? Let’s look at what happens to traffic between the eNodeB and
the UE. Symbol 1 is radiated out of the eNodeB, and arrives at the UE over the shortest path, or path
A. However, the same symbol also arrives over paths B, C, and D. If we transmit symbol 2 immediately
after symbol 1, the delayed symbols 1B, 1C, and 1D will interfere with symbol 2.
We need a guard interval between the symbols to protect against inter-symbol interference. The guard
interval must be large enough to account for “normal” delay in the cell, e.g., the RMS (Root, Mean,
Square) delay spread.
Another way of looking at multipath is linear path distance. Free space propagation delay is about 1
nanosecond per foot or 3.3 microseconds per kilometer. The guard interval must handle (account for)
multipath delay based on the cell radius.
2010
Cyclic Prefix Version 2 Rev 4
Cyclic Prefix
Figure 2-16 Cyclic Prefix
The Cyclic Prefix or TCP accounts for the multipath delay (distance) as described on the preceding page.
The guard interval itself contains a copy of the signals from the end of the symbol time. The Cyclic Prefix
process captures the signals from the end of the symbol time and copies them to the guard interval in
front of the symbol.
The Cyclic Prefix guarantees a whole number of Hz per symbol time and no phase or amplitude changes
during the extended symbol time (requirements of FFT).
LTE defines two TCP sizes, normal (4.67 microseconds) and

extended (16.67 microseconds).
Calculating the Frame Rate
1. Assuming a free space propagation delay of 3.3 µs per kilometer, what multipath distance is
collected by a normal TCP? (Hint: divide the normal TCP size by the propagation delay.)
2. What multipath distance is collected by an extended TCP? (Hint: divide the extended TCP size by
the propagation delay.)
2010
Version 2 Rev 4 Subcarrier Types
Subcarrier Types
Figure 2-17 Subcarrier Types
The DC and Guard Subcarriers are not used to carry data or

reference information; they are set to null (unpowered).
2010
Subcarrier Types Version 2 Rev 4
Subcarrier Types
DC Subcarrier
Figure 2-18 DC Subcarrier
Guard Subcarrier
Figure 2-19 Guard Subcarrier
How can we avoid Inter-Channel Interference (ICI) between cells (sectors) or networks? OFDM
requires guard subcarriers at each end of the channel frequency range to avoid interference with other
cells. Guard subcarriers are null (unpowered).
2010
Subcarrier Types
Data Subcarriers
Figure 2-20 Data Subcarriers
Data subcarriers contain modulated data bits. Groups of data subcarriers are temporarily scheduled to
carry (part of) user or signaling (control) packets.
Reference Signals
Figure 2-21 Reference Signals
2010
Subcarrier Types Version 2 Rev 4
Subcarrier Types
Occupied Subcarriers
Figure 2-22 Occupied Subcarriers
Freq (Fs) MHz MHz
NFFT 128 256 512 1024 1536 2048
Subcarrier 15 kHz
Spacing (Δf)
Occupied 72 180 300 600 900 1200
Subcarriers
2010
Subcarrier Types
Calculating Guard Band Overhead
Freq (Fs) MHz MHz
NFFT 128 256 512 1024 1536 2048
Subcarrier 15 kHz
Spacing (Δf)
Occupied 72 180 300 600 900 1200
Subcarriers
Using the table above, calculate the guard band overhead percentage. (Hint: divide the total bandwidth
of the occupied subcarriers plus 1, by the nominal bandwidth, then subtract from 100 %.)
1. What is the guard band overhead for a 1.4 MHz channel?

100% – 100 (1095000 / 1400000) =
2. What is the guard band overhead for a 3 MHz channel?

100% – 100 (2715000 / 3000000) =
3. What is the guard band overhead for a 5 MHz channel?

100% – 100 (4515000 / 5000000) =
4.
Which channel bandwidth uses the smallest % of guard subcarriers?
2010
LTE Frame Structure Version 2 Rev 4
LTE Frame Structure
Figure 2-23 LTE Frame
Think of a frame as a matrix of subcarriers and symbol times. The frequency domain (vertical axis)
consists of subcarriers, while the time domain (horizontal axis) consists of symbol times.
An LTE frame is always exactly 10 milliseconds long. The 10 ms frame length applies to FDD and TDD
operation for Frame Type 1 or 2.
Calculating the Frame Rate
1. Assuming 10 ms per radio frame, how many LTE frames are transmitted per second?
2010
Version 2 Rev 4 LTE Frame Length and Subcarriers
LTE Frame Length and Subcarriers
Figure 2-24 LTE Frame Length and Subcarriers
The graphic shows the impact of channel bandwidth over a 10 ms radio frame. The vertical dimension
shows the frequency domain (subcarriers), while the horizontal dimension shows the time domain (10
ms frame). While the frame duration is the same for every channel bandwidth, the number of subcarriers
varies dramatically.
2010
Channel Direction Version 2 Rev 4
Channel Direction
Figure 2-25 Channel Direction
The Downlink (DL) carries traffic flowing from or through the eNodeB to the UEs, while the Uplink (UL)
carries traffic from the UEs to the eNodeB. DL and UL bandwidth is shared by the active UEs in a cell
(sector).
Downlink and Uplink traffic may be carried on pairs of frequencies, or the same frequency. Paired
frequency operation is called Frequency Division Duplexing (FDD), while single frequency operation
is known as Time Division Duplexing (TDD).
2010
Version 2 Rev 4 Frequency Division Duplexing (FDD)
Frequency Division Duplexing (FDD)
Figure 2-26 Frequency Division Duplexing (FDD)
FDD uses pairs of frequencies, one frequency to transmit traffic from the eNodeB to the UEs (DL), and
a different frequency for traffic from the UEs to the eNodeB (UL).
FDD operation uses LTE Frame Type 1.
2010
Time Division Duplexing (TDD) Version 2 Rev 4
Time Division Duplexing (TDD)
Figure 2-27 Time Division Duplexing (TDD)
TDD uses a single frequency for both directions of traffic. Both DL and UL traffic are included in the same
10 ms frame.
The eNodeB allocates DL and UL capacity depending on the bandwidth requirements for that frame and
subframe. That means the DL/UL allocations will vary from frame to frame.
TDD operation uses LTE Frame Type 2. Frame Type 2 includes

built-in time gaps to switch the transmit direction from DL to UL.
2010
Version 2 Rev 4 FDD and Frame Type 1
FDD and Frame Type 1
Slots
Figure 2-28 Frame Type 1 Slots
Type 1 frames are divided into 20 slots; each slot is .5 ms long. Depending on the length of the Cyclic
Prefix, a slot contains either 7 or 6 symbols. (As illustrated above, a slot which uses normal size Cyclic
Prefixes contains 7 symbols).
For FDD operation, this frame structure occurs simultaneously for both the DL and UL on their respective
frequencies.
For normal sized Cyclic Prefixes, the first symbol’s Cyclic Prefix is
slightly larger than the TCP of the other symbols in the slot.
2010
FDD and Frame Type 1 Version 2 Rev 4
FDD and Frame Type 1

Figure 2-29 Frame Type 1 Slots
If extended Cyclic Prefixes are used, a Frame Type 1 slot contains only 6 symbols. Note that every
extended Cyclic Prefix is exactly the same size (16.67 microseconds).
2010
Version 2 Rev 4 Resource Blocks and Resource Elements
Resource Blocks and Resource Elements
Figure 2-30 Resource Blocks and Resource Elements
Bandwidth within slots is allocated based on resource blocks. A resource block is 180 kHz (12
subcarriers) in the frequency domain and one slot in the time domain. A resource element is one
subcarrier by one symbol time. A resource element may carry modulated data or a reference signal.
When using normal sized TCP, a resource block contains 84 resource elements (12 subcarriers by 7
symbols). For extended TCP, a resource block contains 72 resource elements (12 subcarriers by 6
symbols).
MBMS 7.5 kHz resource blocks are different in the following ways:
1. MBMS traffic always uses extended TCP.
2. Because this traffic uses 7.5 kHz subcarrier spacing, an
MBMS resource block (180 kHz divided by 7.5 kHz) contains
24 subcarriers.
3. An MBMS resource block contains 3 symbols.
2010
Physical and Virtual Resource Blocks Version 2 Rev 4
Physical and Virtual Resource Blocks

3GPP standards describe physical resource blocks and virtual resource blocks. A Physical Resource
Block (PRB) consists of consecutive subcarriers in the frequency domain and consecutive symbols in
the time domain.
Virtual resource blocks (VRB) are mapped to physical resource blocks. A virtual resource block may
be either localized or distributed.
Calculating Resource Blocks per Slot
Freq (Fs) MHz MHz
NFFT 128 256 512 1024 1536 2048
Subcarrier 15 kHz
Spacing (Δf)
Resource
Blocks per
Slot
1. Use the formula below to calculate the number of resource blocks per slot for each channel size.
Occupied Subcarriers / Subcarriers per Resource Block
2010
Version 2 Rev 4 Reference Signals, Normal TCP
Reference Signals, Normal TCP
Figure 2-31 Reference Signals, Normal TCP
DL and UL directions use different numbers of Reference Signals. For the DL, 4 Reference Signals are
distributed in the resource block. For the UL, an entire symbol time is devoted to carrying Reference
Signals. Note that the graphic shows resource blocks using normal sized TCP. All of the unshaded
resource elements may be used to carry modulated data or control information.
The graphic illustrates the DL Reference Signals used with normal

TCP for a single port antenna. We will look at 2-port and 4-port
Reference Signal patterns in the next lesson.
2010
Reference Signals, Extended TCP Version 2 Rev 4
Reference Signals, Extended TCP
Figure 2-32 Reference Signals, Extended TCP
The graphic shows resource blocks using extended TCP. All of the unshaded resource elements may be
used to carry modulated data or control information.
Calculating Resource Blocks Capacity
Use the graphics on the previous pages to answer the following questions. For the DL, assume a single
port antenna.
1. How many total resource elements (RS + RE) are contained in a DL or UL resource block using
normal sized TCP?
2. How many resource elements may carry data (total RE – RS) in a DL resource block using normal
sized TCP
3. How many resource elements may carry data (total RE – RS) in an UL resource block using normal
sized TCP
4. How many total resource elements (RS + RE) are contained in a DL or UL resource block using
extended TCP
2010
Version 2 Rev 4 Reference Signals, Extended TCP
Reference Signals, Extended TCP
5. How many resource elements may carry data (total RE – RS) in a DL resource block using extended
TCP
6. How many resource elements may carry data (total RE – RS) in an UL resource block using
extended TCP?
2010
Subframes Version 2 Rev 4
Subframes
Figure 2-33 Frame Type 1 Subframes
Adjacent slots are combined into a subframe; each subframe is 1 ms long. DL and UL bandwidth
allocations are made within a subframe. In TDD operation, a subframe may be associated with either
the DL or UL direction.
2010
Version 2 Rev 4 FDD DL Operation
FDD DL Operation
Figure 2-34 FDD Operation – DL
Control information at the beginning of a DL subframe describes both DL and UL scheduling. The DL
subframe may include system information, including eNodeB, cell, and network information, or paging.
Every UE must receive and interpret the system information.
DL scheduling is described in the “control” information. For example, DL traffic intended for UE1 is
described using the temporary ID for UE1, the starting resource block within the subframe, number of
resource blocks which carry the UE1 data, and modulation scheme selected by the eNodeB. The DL
scheduling information is carried in the Physical DL Control Channel (PDCCH).
2010
FDD UL Operation Version 2 Rev 4
FDD UL Operation
Figure 2-35 FDD Operation – UL
UL bandwidth allocations, also known as grants, are also described in the PDCCH. UL grants indicate
the UE’s temporary ID, the starting resource block within the UL subframe, number of resource blocks
allocated to the UE, and modulation scheme selected by the eNodeB. The UE must completely fill the
bandwidth grant, inserting padding if necessary.
The UL subframe may also contain a Physical Random Access Channel (PRACH). The PRACH allows
subscribers to contact the eNodeB during network entry or location updates, request bandwidth, and so
on.
Note that UL control information “points ahead” to a subsequent

subframe. To meet the 5 millisecond LTE latency requirement,
the eNodeB allocates UL bandwidth at N + 4, where N equals
the current DL subframe.
2010
Version 2 Rev 4 TDD Operation and Frame Type 2
TDD Operation and Frame Type 2
Figure 2-36 Frame Type 2
Frame Type 2 is designed exclusively for TDD operation. Similar to Frame Type 1, a Type 2 Frame is 10
ms long, and contains 10 1-ms subframes. With the exception of Special Subframes (Subframe 1 and
possibly 6), each DL or UL subframe contains two .5 ms slot; each slot contains 6 or 7 symbol periods.
DL scheduling and UL grants are always described in the DL PDCCH channel.
The DL and UL subframe allocations are controlled by the

eNodeB. They may vary from frame to frame.
2010
TDD Operation and Frame Type 2 Version 2 Rev 4

Frame Type 2 Special Subframe
Figure 2-37 Frame Type 2 Special Subframe
A Special Subframe consists of three fields: the DwPTS, GP, and UpPTS.
• The DL Primary Timing Signal (DwPTS) field contains the primary timing (slot synchronization)
signal for the DL and UL directions
• UL Primary Timing Signal (UpPTS) may be used for UL Sounding Reference Signals or the
PRACH channel
• Guard Period (GP) provides a DL-to-UL guard interval
• Total length of DwPTS, GP, and UpPTS fields must equal 1 ms
• For some UL/DL configurations, Subframe 6 may also be a Special Subframe
Frame Type 2 UL/DL Configurations

Subframe number
DL-to-UL
UL/DL
Switch-Point 0 1 2 3 4 5 6 7 8 9
Config.
Period
0 5 ms DL S UL UL UL DL S UL UL UL
1 5 ms DL S UL UL DL DL S UL UL DL
2 5 ms DL S UL DL DL DL S UL DL DL
3 10 ms DL S UL UL UL DL DL DL DL DL
4 10 ms DL S UL UL DL DL DL DL DL DL
5 10 ms DL S UL DL DL DL DL DL DL DL
6 5 ms DL S UL UL UL DL S UL UL DL
2010
Version 2 Rev 4 TDD Operation and Frame Type 2

Note – In the table above, S refers to the Special Subframe format consisting of DwPTS, GP, and UpPTS
fields.
Figure 2-38 FT2 UL/DL Configuration 0
The graphic shows Frame 2 UL/DL configuration 0.
Frame Type 2 Configuration Exercise

Using the table on the facing page, fill in the graphics and answer the questions below
1. Fill in the Frame Type 2 graphic below using UL/DL Configuration 2.
2. Where do Configuration 2 DL-to-UL switch points occur?

3. Where are the guard intervals located for UL/DL Configuration 2
4. Fill in the Frame Type 2 graphic below using UL/DL Configuration 3.
2010
TDD Operation and Frame Type 2 Version 2 Rev 4

5. How many Special Subframes are used? Why?
Comparing Frame Types 1 and 2
Configuration Frame Type 1 Frame Type 2
Frame Length 10 ms 10 ms
Subframes/Frame 10 10Note 1
Subframe Length 1 ms 1 ms
Slots/Subframe 2 2Note 1
Symbols/Slot, normal TCP 7 7
Symbols/Slot, extended TCP 6 6
Use FDD only TDD only
Note 1 Depending on the UL/DL configuration, Frame Type 2 contains 1 or 2 special subframes consisting
of the DwPTS, GP, and UpPTS fields.
2010
Version 2 Rev 4 Modulation Review
Modulation Review
Figure 2-39 Modulation Review
Each symbol represents 1-6 bits depending on the modulation technique. Each data point represents a
different bit pattern. QPSK bit patterns are illustrated on the graphic.
LTE devices use QPSK, 16QAM and 64QAM to modulate data and control information. The eNodeB
supports all of these modulation techniques for the Down Link direction. However, 64QAM is optional in
the Uplink direction.
2010
Modulation Review Version 2 Rev 4
Modulation Review
Modulation and Signal Quality
Figure 2-40 Modulation and Signal Quality
A modulation technique is selected based on the measured Signal to Noise Ratio (SNR). Subscribers
located away from the eNodeB must use more robust modulation schemes (lower throughput), or they
will experience unacceptable data loss rates. In addition, subscribers close to a sector boundary may
experience inter-sector interference.
Each modulation scheme has a threshold SNR. For example, let’s assume QPSK is associated with
SNR 9 dB, 16QAM with 15 dB, and 64QAM with 25 dB. If the SNR drops below 15 dB, the eNodeB will
instruct the UE to use QPSK modulation.
Measuring Signal Quality

• Signal quality measured using Reference Signals
• eNodeB initially measures UE signal quality during network entry
• eNodeB controls the modulation selected for both DL and UL
Both the eNodeB and the UE measure signal quality using Reference Signals. The Reference Signals
carry a known (pseudo-noise) bit pattern at a boosted power level. The receiver performs channel
equalization based on the received Reference Signals.
The eNodeB calculates the UE-transmitted signal quality by measuring UE Reference Signals, and by
requesting Channel Quality Indication (CQI) feedback from the UE.
The eNodeB always controls and selects the modulation and coding scheme for both the Downlink and
Uplink.
2010
Version 2 Rev 4 Modulation Review
Modulation Review
Estimating FDD Capacity

The formula below estimates the FDD DL capacity for a given channel bandwidth and modulation.
MCS? TCP Size and # of Antenna Ports?

(Bits per Symbol * Data Resource Elements per Resource Block) *
Channel Size? 20 100

(Resource Blocks per Slot * Slots per Frame) * Frames per Second
Calculating FDD Capacity Reference

NFFT 128 256 512 1024 1536 2048
Occupied 72 180 200 600 900 1200
Subcarriers
Resource 6 15 25 50 75 100
Blocks per
Slot
Calculating FDD DL Capacity
Assume normal sized TCP and one antenna port are used for each of the following questions. The table
above is included for reference.
1. Estimate the DL capacity in bits per second for a 20 MHz channel operating at 64QAM.
6 X 80 X 100 X 20 X 100 =
2. Estimate the DL capacity in bits per second for a 20 MHz channel operating at QPSK.
3. Estimate the DL capacity in bits per second for a 5 MHz channel operating at 16QAM.
Calculating FDD UL Capacity
2010
Modulation Review Version 2 Rev 4
Modulation Review
MCS? TCP Size?

(Bits per Symbol * Data Resource Elements per Resource Block) *
Channel Size? 20 100

(Resource Blocks per Slot * Slots per Frame) * Frames per Second
Using the formula above and the table from the facing page, estimate the FDD UL capacity for a given
channel bandwidth and modulation scheme. Assume normal sized TCP is used for each of the following
questions.
1. Estimate the UL capacity in bits per second for a 20 MHz channel operating at 16QAM.
4 X 72 X 100 X 20 X 100 =
2. Estimate the UL capacity in bits per second for a 20 MHz channel operating at QPSK.
3. Estimate the UL capacity in bits per second for a 5 MHz channel operating at 16QAM.
2010
Lesson Summary
In this lesson, you learned about:
• The operating frequencies used by the LTE air interface

• OFDM subcarrier and symbol concepts
• LTE duplexing and framing methods
• Modulation techniques used by the LTE air interface
• Estimating FDD DL and UL capacity
2010
Memory Points Version 2 Rev 4
Memory Points
2010
2010
LTE Air Interface – PHY Layer Advanced Version 2 Rev 4
Chapter 3
LTE Air Interface – PHY Layer Advanced
2010
Version 2 Rev 4 LTE Air Interface – PHY Layer Advanced
2010
Objectives
At the completion of this lesson, you will be able to:
• Compare OFDMA and SC-FDMA usage in LTE

• Describe Forward Error Correction (FEC) operation
• List LTE physical signals
• Describe DL Reference Signal patterns for LTE MIMO antenna systems
• Describe UL physical signals
• List LTE Physical Layer measurements
Figure 3-1 Lesson 3 Context
2010
Version 2 Rev 4 OFDMA Operation
OFDMA Operation
OFDMA Transmitter Functions
Figure 3-2 OFDMA Transmitter Functions
The OFDMA transmitter (eNodeB) performs the following steps:
1. Bits are scrambled, encoded for Forward Error Correction, and interleaved.
2. The encoded bits are grouped into 1 to 6 bit symbols and modulated using
BPSK, QPSK, 16QAM, or 64QAM.
3. The modulated signals are mapped into all or part of the channel for the required
number of symbol times.
4. The Inverse FFT (IFFT) process creates the time-domain waveform by
summing the modulated subcarriers.
5. The eNodeB attaches the Cyclic Prefix (CP) to the beginning of the symbol.
6. Power is adjusted as needed and the waveform is transmitted.
2010
OFDMA Operation Version 2 Rev 4
OFDMA Operation
OFDMA Receiver Functions
Figure 3-3 OFDMA Receiver Functions
The OFDMA receiver (UE) performs the following steps:
7. The UE receives the waveform from the eNodeB.
8. The CP is removed from the front of the symbol.

9. FFT recreates the frequency spectrum of the received signal, recreating the
subcarriers and their modulated bits.
10. The channel mapping is reversed to discover symbols allocated to individual
UE traffic.
11. Each modulated symbol is demodulated into its original bits.
12. The bits are returned to their original order (de-interleaved), FEC error correction
is performed, and bits are unscrambled. The resulting bit stream should be
identical to the original bit stream in the transmitter.
2010
OFDMA Operation
OFDM Bandwidth Allocation
Figure 3-4 OFDM Bandwidth Allocation
OFDM assigns all subcarriers for a symbol to a single user. Although a user may be allocated more than
one symbol time, OFDM does not assign less than a full symbol period. That is wasteful, depending on
the actual user bandwidth requirement.
Using OFDM, all DL subcarriers in a symbol period use the same

modulation and coding scheme.
2010
OFDMA Operation
OFDMA Bandwidth Allocation
Figure 3-5 OFDMA Bandwidth Allocation
Orthogonal Frequency Division Multiple Access (OFDMA) assigns bandwidth more efficiently than
OFDM. Rather than allocating all subcarriers for a symbol to a single user, OFDMA assigns resource
blocks as needed to users. LTE uses OFDMA on the Downlink.
Using OFDMA, DL subcarriers in one symbol period may use

different modulation and coding schemes.
2010
OFDMA Operation
OFDMA Modulation Mapping
Figure 3-6 OFDMA Modulation Mapping
The graphic shows the eNodeB modulating resource elements for different users in the same symbol
period. Note that the eNodeB has allocated DL bandwidth (resource blocks) and a modulation scheme to
each user. During the symbol time, subcarriers associated with each UE are modulated as indicated by
the eNodeB. Based on the control scheduling information in the PDCCH channel, each UE will receive
all of the subcarriers but ignore any assigned to other users.
Using OFDMA, DL subcarriers in a symbol period may use

different modulation schemes.
2010
OFDMA Operation
OFDMA Subcarrier Encoding
Figure 3-7 OFDMA Subcarrier Encoding
Let’s review OFDMA subcarrier encoding. As shown above, our serial bit stream is modulated using
QPSK. Each QPSK symbol is encoded in parallel on a separate 15 kHz subcarrier. Because the eNodeB
transmits over the entire range of occupied subcarriers, the QPSK data symbols are already positioned
at the desired location in the channel bandwidth; no separate step is needed to shift the symbol location.
As described earlier, the eNodeB allocates bandwidth in units of

12 adjacent subcarriers.
2010
OFDMA Operation
OFDMA Issues
Figure 3-8 OFDMA PAPR
OFDMA problems include:
• High Peak-to-Average Power Ratio (PAPR or PAR)

• Per subcarrier equalization for all subcarriers
• High sensitivity to frequency offset
• Sensitive to spectral nulls
Note that none of these limitations is an issue for the eNodeB. Even in high PAPR conditions, the
eNodeB has adequate power. On the other hand, a battery-powered UE would experience unacceptable
power requirements due to high PAPR. A mobile UE experiences high sensitivity to frequency offset; the
stationary eNodeB does not. Finally, the eNodeB must encode all of the occupied subcarriers for each
DL symbol time; other than the guard and DC subcarriers, none of the DL subcarriers are null. A UE
will only encode some of the occupied UL subcarriers. Because of these issues, LTE uses SC-FDMA
rather than OFDMA for the UL.
The IFFT process adds the encoded subcarrier sine waves together. If all the sine waves are at their
peak at the same time, a high peak amplitude is created – that creates more power requirements and
reduces battery life. To deal with the resulting high Peak-to-Average Power Ratio, an OFDMA power
amplifier must have a greater linear range than other technologies, such as SC-FDMA.
The eNodeB is capable of greater power and complexity than the

UE. OFDMA is appropriate for DL traffic from the eNodeB to the
UE. However, it was not selected for the UL direction.
2010
Single Carrier-Frequency Division Multiple Access (SC-FDMA) Version 2 Rev 4
Single Carrier-Frequency Division Multiple Access (SC-FDMA)
UE Requirements
UE requirements include:
• Reduced complexity
• Lower transmit power
• High QoS at cell boundaries
• High data rates
Although the eNodeB is capable of transmitting and receiving OFDMA symbols, the UE must balance
reduced complexity and lower transmit power requirements with support for high data rates and good
QoS at cell boundaries. To meet the UE requirements and deal with the OFDMA problems, Single
Carrier Frequency Division Multiple Access (SC-FDMA) was selected for the UL.
SC-FDMA helps with PAPR reduction by adding extra encoding steps. The modulated bits are run
through a Discrete Fourier Transform (DFT) algorithm using a subset of subcarriers with a fixed
amplitude, then mapped into a limited number of subcarriers. The normal Inverse FFT process views
this as a single-carrier input spread over a few subcarriers. All other subcarriers are set to null, reducing
the power (battery) requirements in the UE. The unused subcarriers may be allocated to other UEs in
the cell.
2010
Version 2 Rev 4 Single Carrier-Frequency Division Multiple Access (SC-FDMA)
SC-FDMA Transmitter Functions
Figure 3-9 SC-FDMA Transmitter Functions
The SC-FDMA transmitter (UE) performs the following steps:
1. Bits are scrambled, encoded for Forward Error Correction, and interleaved.
2. The encoded bits are grouped into 1 to 6 bit symbols and modulated using
BPSK, QPSK, 16QAM, or optionally, 64QAM.
3. The modulated symbols are run through a small-scale Discrete Fourier
Transform (DFT) process with a limited number of subcarriers at a fixed
amplitude.
4. The DFT frequency domain output is mapped into part of the channel. All
other subcarriers are set to null.
5. The Inverse FFT (IFFT) process creates the time-domain waveform by
summing the modulated subcarriers for the entire UL grant.
6. The UE attaches the Cyclic Prefix (CP) to the beginning of the symbol.
7. Power is adjusted as needed and the waveform is transmitted.
SC-FDMA specific behavior is associated with steps 3, 4, 11,

and 12. We will discuss these additional steps over the next few
pages.
2010
SC-FDMA Receiver Functions
Figure 3-10 SC-FDMA Receiver Functions
The SC-FDMA receiver (eNodeB) performs the following steps:
8. The eNodeB receives the waveform from the UE.

9. The CP is removed from the front of the symbol.
10. FFT recreates the frequency spectrum of the received signal, recreating the
subcarriers and their modulated bits.
11. The subcarrier mapping from step 4 is reversed to discover individual user's
symbols.
12. The DFT process from step 3 is reversed to discover the time domain of the
signals.
13. Each modulated symbol is demodulated into its original bits.
14. The bits are returned to their original order (de-interleaved), FEC error
correction is performed, and bits are unscrambled. The resulting bit stream
should be identical to the original bit stream in the transmitter.
2010

SC-FDMA Subcarrier Encoding
Figure 3-11 SC-FDMA Subcarrier Encoding
SC-FDMA Subcarrier Encoding Unlike OFDMA, the SC-FDMA signal appears to be more like a
single-carrier with each data symbol represented by a wide signal spanning several 15 kHz subcarriers.
The graphic shows a QPSK symbol spread over 180 kHz (12 x 15 KHz subcarriers).
2010
SC-FDMA Subcarrier Encoding, Continued
Figure 3-12 SC-FDMA Subcarrier Encoding, Continued
Instead of transmitting each data symbol in a separate subcarrier, SC-FDMA transmits M (12) data
symbols in the same symbol time. These “sub-symbols” are spread over M subcarriers. In other words,
each SC-FDMA symbol contains M sub-symbols transmitted at the rate M times 15 kHz.
2010
SC-FDMA Precoding
Figure 3-13 SC-FDMA Precoding
SC-FDMA signal generation begins with a special precoding process, which creates a time-domain
waveform of the data sub-symbols. The process creates one SC-FDMA 66.67 µs symbol in the time
domain. One SC-FDMA symbol contains 12 consecutive data sub-symbols.
Time-domain filtering of the data symbol transitions also occurs, although it is not discussed here.
2010
Time Domain SC-FDMA Symbols
Figure 3-14 Time Domain SC-FDMA Symbol
Once an SC-FDMA symbol has been created in the time domain, we must represent that symbol in the
frequency domain using a Discrete Fourier Transform (DFT). The DFT sampling frequency is chosen
such that the time-domain waveform of one SC-FDMA symbol is fully represented by M DFT bins spaced
15 kHz apart, with each bin representing one subcarrier in which amplitude and phase are held constant
for the symbol time.
A one-to-one correlation always exists between the number of data sub-symbols to be transmitted during
one SC-FDMA symbol period and the number of DFT bins created. This in turn becomes the number of
occupied subcarriers.
2010
Moving the SC-FDMA Symbol in the Frequency Domain
Figure 3-15 Moving the SC-FDMA Symbol in the Frequency Domain
Next, the SC-FDMA symbol must be moved to the allocated Resource Block(s) in the frequency domain
of the full channel bandwidth. The signal can be positioned anywhere in the channel bandwidth, thus
executing the Frequency-Division Multiple Access (FDMA) essential for efficiently sharing the uplink
between multiple users.
All other subcarriers are set to null by the UE.
2010
Channel Coding Version 2 Rev 4
Channel Coding
Figure 3-16 Transmitter Step 1
Let’s take a closer look at channel coding and modulation (Steps 1 and 2). In Step 1, bits are scrambled,
encoded for FEC, and interleaved. These functions are performed by both OFDMA (DL) and SC-FDMA
(UL) transceivers. In either case, the receiver must reverse the interleaving, FEC encoding, and
scrambling.
Scrambling
• Data bits are scrambled to avoid long strings of consecutive ones or zeros
• Bits are run through a Pseudo-Random Binary Sequence (PRBS) generator
• Random Access Preambles are not scrambled
• Bits must be de-scrambled at the receiver
Before forward error correction and modulation are performed at the transmitter, the bits are scrambled
to avoid long strings of consecutive ones or zeros. The receiver must reverse this process before
interpreting the bits.
Forward Error Correction
Figure 3-17 Forward Error Correction
2010
Version 2 Rev 4 Channel Coding
Channel Coding
The air interface is a hostile environment! Bits may be corrupted or improperly interpreted based on
low received signal strength and high interference and noise levels. FEC adds redundant bits to the
transmitted data enabling the receiver to correct errors without requesting retransmission.
FEC must strike a balance between “perfect” error correction and overhead. The FEC goal is an error
rate of 10-6 after correction.
Tail biting convolutional coding is used on the DL and UL control channels. All DL and UL traffic channels
use turbo coding.
FEC Operation
Figure 3-18 FEC Operation
FEC Operation The graphic shows a high level view of FEC operation. Moving from left to right, the
systematic (“data”) bits are fed into the turbo coder. For each systematic bit SN, the turbo coder creates
two parity bits: P1N and P2N. The systematic bits and parity bits are then placed in a circular buffer.
The circular buffer contains the systematic bits, followed by the interleaved parity bits. Note that the
buffer is divided into four areas called Redundancy Versions (RV). RV 0 contains the systematic bits
while the other Redundancy Version areas contain the interleaved parity bits.
2010
Channel Coding Version 2 Rev 4
Channel Coding
Rate Matching and HARQ
Figure 3-19 Rate Matching
Rate matching with Hybrid Automatic Repeat Request (HARQ) reduces the bandwidth requirements for
FEC.
Step
1. Using FEC with rate matching, the transmitter sends the systematic bits,
one RV portion of the parity bits, and a 24-bit Cyclic Redundancy Check
(CRC-24)
2. In our example, an error is detected based on the CRC.
3. The receiver will return a NACK.
4. The transmitter will resend the systematic bits, a different RV portion of
the parity bits, and a CRC.
5. If the step 4 message is corrupted, the receiver will combine the bits from
steps 1 and 4, and calculate the correct systematic bits.
6. The receiver sends an ACK to acknowledge the corrected (or correctly
received) message.
2010
Version 2 Rev 4 LTE Physical Signals
LTE Physical Signals

Downlink Physical Signals
• DL Demodulation Reference Signals (RS)

• Synchronization Signals
Uplink Physical Signals
• UL Demodulation Reference Signals

• Sounding Reference Signals
• Random Access Preamble
In addition to data and control information, LTE defines other physical signals, including Reference
Signals and Synchronization Signals.
The eNodeB and UE use Demodulation Reference Signals (DRS) to estimate RF channel quality
(measure SNR).
The eNodeB transmits periodic Synchronization Signals (SS) to synchronize each UE with the recurring
physical slots and frames.
The eNodeB uses Sounding Reference Signals (SRS) to control frequency-dependant scheduling for a
UE. As needed, the eNodeB orders the UE to transmit special (sounding) Reference Signals over some
or all of the occupied subcarriers during 1 or 2 symbols times. The eNodeB uses the sounding results to
schedule specific frequency ranges for that UE.
Single Port Antenna
Figure 3-20 Single Port Antenna
Let’s review the location of Reference Signals in the DL. For a single-port antenna, 4 Reference Signals
are distributed in each DL Resource Block. The graphic shows resource blocks using both normal sized
TCP and extended TCP for a single port antenna.
2010
LTE Physical Signals Version 2 Rev 4
2 Port Antenna DL Reference Signals, Normal TCP
Figure 3-21 2 Port Antenna DL Reference Signals, Normal TCP
If the eNodeB is equipped with two ports per antenna (e.g., 2X2 MIMO), each antenna port will use a
different Reference Signal pattern. Note that the Reference Signals do not overlap between the ports;
the corresponding resource element is unused on the other port. That is illustrated on the graphic by
shaded boxes with an “X” inside.
2010
2 Port Antenna DL Reference Signals, Extended TCP
Figure 3-22 2 Port Antenna DL Reference Signals, Extended TCP
2 Port Antenna DL Reference Signals, Extended TCP The graphic shows the DL Reference Signal
pattern for a 2 port antenna using extended TCP.
2010
Antenna Port Layering, 2
Figure 3-23 Antenna Port Layering, 2
Ports For single (0) or two port (0, 1) antenna systems, the eNodeB will transmit one MAC PDU for a UE
during a scheduling interval (1 ms for FDD).
How many MIMO antenna ports are used in a cell? The eNodeB periodically broadcasts the Master
Information Block (MIB) over the Broadcast Channel. The MIB indicates the channel bandwidth (1.4-20
MHz), number of eNodeB antenna ports, and Reference Signal power.
2010
4 Port Antenna DL Reference Signals
Figure 3-24 4 Port Antenna DL Reference Signals
If the eNodeB is equipped with four ports per antenna (e.g., 4X4 MIMO), each antenna port will use the
Reference Signal patterns as shown on these pages.
The graphic above shows the Reference Signal patterns for antenna ports 0 and 1 when using normal
TCP.
2010
4 Port Antenna DL Reference Signals – continued
Figure 3-25 4 Port Antenna DL Reference Signals – continued
The graphic above shows the Reference Signal patterns for antenna ports 2 and 3, normal TCP.
Antenna Port Layering, 4 Ports
Figure 3-26 Antenna Port Layering, 4 Ports
Depending on the mode of operation, a four port (0, 1, 2, 3) antenna system may transmit one or two
MAC PDUs for a UE, layered onto the antenna port grids.
2010
Version 2 Rev 4 Synchronization Signals
Synchronization Signals
Synchronization signals allow the UE to synchronize with the recurring slots and frames transmitted
by the eNodeB. The Primary Synchronization Signal (P-SS) provides LTE slot synchronization. The
Secondary Synchronization Signal (S-SS) provides LTE frame synchronization. In both cases, the
sync signals are transmitted by the eNodeB on 62 subcarriers centered around the DC subcarrier.
Synchronization Signals, Frame Type 1
Figure 3-27 Synchronization Signals, Frame Type 1
For Frame Type 1, the Primary Synchronization Signal (P-SS) is located in the last symbol of slots 0 and
10. The graphic shows slots using a normal TCP, with the P-SS located in symbol 6.
The S-SS is located in the next to last symbol of slots 0 and 10.
The P-SS and S-SS signals are sent on the same antenna port.
2010
Synchronization Signals Version 2 Rev 4
Synchronization Signals
Synchronization Signals, Frame Type 2
Figure 3-28 Sync Signals, Frame Type 2
For Frame Type 2, the P-SS is carried in the 3rd OFDM symbol in subframes 1 and 6 (in the DwPTS
field).
The S-SS is carried in the last symbol of Slots 1 and 11.
2010
Version 2 Rev 4 UL Demodulation Reference Signals
UL Demodulation Reference Signals
Figure 3-29 UL Demodulation Reference Signals
As we saw earlier, the UL uses more Reference Signals (RS) than the DL. The graphic shows the UL
RS pattern for Frame Type 1 and 2 using normal TCP.
Every UL subcarrier in the 4th symbol (S=3) location is used as a demodulation Reference Signal. The
RS pattern for extended TCP is also located in the 4th symbol.
2010
Sounding Reference Signals (SRS) Version 2 Rev 4
Sounding Reference Signals (SRS)
Figure 3-30 Sounding RS and Frame Type 2
Sounding Reference Signals (SRS) are used by the eNodeB to support frequency dependent
scheduling. In this optional procedure, the eNodeB orders one or more UEs to transmit on all or a
subset of the available subcarriers. Based on the UE’s SRS, the eNodeB estimates which subcarriers
perform best and allocates its resources accordingly.
Sounding is also used when the eNodeB does not have enough information to update the timing advance
or the transmit power for a given UE.
For Frame Type 1, the eNodeB may schedule Sounding RS operation on resource blocks which do not
include the PUCCH channel or CQI transmissions. For Frame Type 2, the eNodeB will use the UpPTS
field for sounding.
• The following SRS parameters are configured by higher layers for a UE:
• Transmission comb
• Starting physical resource block assignment
• Duration of SRS transmission: single or indefinite (until disabled)
• SRS periodicity (2, 5, 10, 20, 40,80,160, 320 ms) and SRS subframe offset
• SRS bandwidth
• Frequency hopping bandwidth
• Cyclic shift
2010
Version 2 Rev 4 Random Access Preamble
Random Access Preamble
Figure 3-31 Random Access Operation
Subframe 0 1 2 3 4 5 6 7 8 9
f2 (UL)
72 Contiguous
1.25 kHz PRACH Subframe
Subcarriers
CP RA Preamble GP
Size depends on Burst Format
LTE uses an UL contention-based channel, known as the Random Access Channel, which allows a UE to
request network entry, and signal RRC state changes. For example, a UE attempting network entry will
send a Random Access Preamble to the eNodeB. If successful, the eNodeB sends a Random Access
Response (RAR) to the UE. The RAR includes a temporary UE identity and a (small) UL resource grant
to allow the network entry or other action to continue.
Random Access Preambles are transmitted on blocks of 72 contiguous 1.25 kHz subcarriers allocated
for random access by the eNodeB. For Frame Type 2, the Physical Random Access Channel is allocated
in the UpPTS field of the Special Subframe (Subframe 1). 7.5 kHz subcarriers are used with the UpPTS
field.
2010
Random Access Preamble Version 2 Rev 4
Random Access Preamble

Figure 3-32 Random Access Preamble
The Random Access Preamble consists of a long cyclic prefix (TCP), the preamble itself, (TPRE)and a
guard period. Four different Random Access Preamble sizes are defined:
• Format 0 – Used for normal-sized cell

• Format 1 – Extended format used for a large cell
• Format 2 – Repeated format used for maximum cell size of 30 km
• Format 3 – Repeated format used for maximum cell size of 100 km
• Format 4 – Used with the UpPTS field in Frame Type 2
Formats 2 and 3 are defined to support power balancing and low data rates at the cell edge.
Random Access Preamble Formats

Frame
RA Format TCP TPRE
structure
0 103 µs 800 µs (24576 TS)
(3168 TS)
1 684 µs 800 µs (24576 TS)
Frame Type (21024 TS)
1 or 2 2 203 µs 1600 µs (2 x 24576
(6240 TS) TS)
3 684 µs 1600 µs (2 x 24576
(21024 TS) TS)
Frame Type 4 14.6 µs 133 µs (4096 TS)
2 (448 TS)
2010
Lesson Summary
• OFDMA and SC-FDMA usage in LTE

• FEC operation
• Reference Signals and Synchronization Signals
• UL Reference Signals and the Random Access Preamble
2010
Memory Points
2010
2010
LTE Channels Version 2 Rev 4
Chapter 4
LTE Channels
2010
Version 2 Rev 4 LTE Channels
2010
Objectives
• List the LTE channels

• Explain the functions of the LTE Logical, Transport, and Physical Channels
• Describe the mapping of LTE Physical Channels to physical subframes
2010
Version 2 Rev 4 Uu Interface Sublayers
Uu Interface Sublayers
Figure 4-2 Uu Interface Data Link Layer
For the Uu (air) interface, LTE divides the Data Link Layer into the following sublayers:
• Radio Resource Control (RRC)

• Packet Data Convergence Protocol (PDCP)
• Radio Link Control (RLC)
• Medium Access Control (MAC)
As illustrated in the graphic, control traffic and bearer traffic use
different protocol stacks.
2010
LTE Channel Architecture Version 2 Rev 4
LTE Channel Architecture
Figure 4-3 LTE Channel Architecture
The LTE Channel Architecture defines SAE bearer channels, Radio Bearer (RB) channels, Signaling
Radio Bearer (SRB) channels, Logical Channels, Transport Channels, and Physical Channels. In
general, each category behaves as a service access point between adjacent protocol layers.
3GPP TS 36.211 Physical Channel and Modulation

Telecoms
3GPP TS 36.321 Medium Access Control (MAC) Protocol
Specification
LTE
300
3GPP TS 36.322 Radio Link Control (RLC) Protocol Specification
SAE Bearer
An SAE bearer channel carries one or more service data flows between a UE and the EPC.
Radio Bearer
A Radio Bearer channel transports the data packets of an SAE Bearer from the eNodeB toward the UE.
Each SAE Bearer has a one-to-one mapping with a radio bearer.
Signaling Radio Bearer

A Signaling Radio Bearer (SRB) channel transports signaling packets between the RRC Sublayer and
the PDCP Sublayer.
2010
Version 2 Rev 4 LTE Channel Architecture
LTE Channel Architecture
Logical Channel
A Logical Channel transports control or data traffic between the RLC Sublayer and the MAC Sublayer.
Logical control channels are mapped to signaling radio bearer channels, while logical traffic channels
are mapped to radio bearer channels. Logical Channels describe transmission reliability (RLC
Acknowledged Mode, etc.). .
Transport Channel
A Transport Channel forwards control or data traffic between the MAC Sublayer and the Physical
Layer. Each Logical Channel is mapped to a transport channel. Transport Channels describe how the
information will be formatted before being transmitted (coding, transport block size, etc.).
Physical Channel
A Physical Channel provides the transmission media (resource elements) through which the information
is actually transmitted. Each Transport Channel is mapped to a physical channel.
2010
Logical Channels Version 2 Rev 4
Logical Channels
Figure 4-4 Logical Channels
Logical Channels provide control and data transport between the RLC and MAC Sublayers. Signaling
traffic is carried by control channels (xCCH), and data traffic is carried by traffic channels (xTCH). Control
channels are mapped to SRB channels, and traffic channels are mapped to user plane radio bearer
channels.
2010
Version 2 Rev 4 Logical Channels
Logical Channels
Figure 4-5 Logical Channel Types
Control Channels
Broadcast Control Channel (BCCH) – DL channel used to broadcast system information.
Paging Control Channel (PCCH) – DL channel used to carry paging information when the network does
not know the location of the UE.
Common Control Channel (CCCH) – Carries RRC signaling when no RRC connection currently exists
for the UE.
Dedicated Control Channel (DCCH) – A bidirectional control channel used to carry signaling information
when an RRC connection exists for the UE.
Multicast Control Channel (MCCH) – Carries multicast signaling information; it controls the operation
of the MTCH channel.
Traffic Channels
Dedicated Traffic Channel (DTCH) – A point-to-point channel dedicated to one UE for transmission of
user data. The DTCH may be uplink, downlink, or both.
Multicast Traffic Channel (MTCH) – A DL channel used to carry multicast data traffic.
2010
Transport Channels Version 2 Rev 4
Transport Channels
Figure 4-6 Transport Channel Types
Transport Channels carry signaling and data traffic between the MAC Sublayer and the Physical Layer.
Except for the RACH channel, each Transport Channel is mapped to one or more Logical Channels.
Downlink Transport Channels

Broadcast Channel (BCH) – Forwards broadcast information to the entire cell. The BCH maps to the
BCCH Logical Channel.
Paging Channel (PCH) – Forwards UE paging information to the entire cell. The PCH maps to the
PCCH Logical Channel.
Downlink Shared Channel (DL-SCH) – Carries DL data and some control traffic. For data traffic,
DL-SCH supports HARQ and dynamic link adaptation. The DL-SCH maps to the DCCH, CCCH, and
DTCH Logical Channels.
Multicast Channel (MCH) – Carries multicast traffic for the entire cell. The MCH maps to the MCCH
and MTCH Logical Channels
Uplink Transport Channels

Uplink Shared Channel (UL-SCH) – Carries UL data and some control traffic. The UL-SCH maps to
the DCCH, CCCH, and DTCH Logical Channels.
Random Access Channel (RACH) – Used for initial access to the cell or when a UE needs to transmit
on the PUSCH or PUCCH and does not have a valid uplink grant. The RACH is not mapped to a Logical
Channel.
2010
Version 2 Rev 4 Transport Channels
Transport Channels
Logical Channel to Transport Channel Mapping
Figure 4-7 Logical Channel to Transport Channel Mapping
The graphic shows the mapping between the LTE Logical Channels and Transport Channels.
2010
Physical Channels Version 2 Rev 4
Physical Channels
A Physical Channel is a set of resource elements carrying information originating from the higher layers.
Each Transport Channel maps into a Physical Channel.
Downlink Physical Channels
Figure 4-8 DL Physical Channels
Physical Broadcast Channel (PBCH) – DL channel that carries system information (broadcast) traffic.
The PBCH uses QPSK encoding.
Physical Hybrid ARQ Indicator Channel (PHICH) – Carries Hybrid ARQ (HARQ) ACKs or NACKs for
the UL transmissions on the PUSCH. The PHICH uses BPSK encoding.
Physical Control Format Indicator Channel (PCFICH) – Transmitted every subframe to inform the UE
about the number of OFDM symbols used for the PDCCH channel. The PCFICH uses QPSK encoding.
Physical Downlink Control Channel (PDCCH) – Informs the UE about the resource allocation for PCH
and DL-SCH, plus the HARQ information relating to the DL-SCH. It also controls the UL-SCH scheduling
grants and indicates the UE identity. The PDCCH has four formats, hence the need for the PCFICH. The
PDCCH signaling is located in the first 1–3 OFDM symbols in each subframe. The PDCCH uses QPSK
encoding.
Physical Downlink Shared Channel (PDSCH) – Carries downlink data and higher layer signaling.
The PDSCH is allocated to different UEs periodically, usually every 1 ms. PDSCH channel coding,
modulation, and subcarrier allocation is dynamically controlled by the PDCCH. The PDSCH may use
QPSK, 16QAM, or 64QAM encoding.
Physical Multicast Channel (PMCH) – Carries the MBMS data and control if the cell supports MBMS
functionality. The PMCH may use QPSK, 16QAM, or 64QAM encoding.
2010
Version 2 Rev 4 Physical Channels
Physical Channels
Uplink Physical Channels
Figure 4-9 UL Physical Channels
Physical Random Access Channel (PRACH) – Carries random access preambles used when the UE
makes initial contact with the network, etc.
Physical Uplink Shared Channel (PUSCH) – Carries uplink data and higher layer signaling. PUSCH
is a shared channel allocated to different UEs periodically, usually every 1 ms. The channel coding,
modulation, and subcarrier allocation is dynamically controlled by the PDCCH. The PUSCH may use
QPSK, 16QAM, or 64QAM encoding.
Physical Uplink Control Channel (PUCCH) – Carries uplink control information for a UE, including
CQI, HARQ ACKs and NACKs, and UL scheduling requests. Depending on format, the PUCCH may
use BPSK or QPSK encoding.
Transport to Physical Channel Mapping
Figure 4-10 Transport to Physical Channel Mapping
The graphic shows the mapping between LTE Transport Channels and Physical Channels. The PDCCH,
PCFICH, PHICH, and PUCCH Physical Channels are not mapped to Transport Channels.
2010
Mapping DL Physical Channels to Subframes Version 2 Rev 4
Mapping DL Physical Channels to Subframes
Mapping PDSCH Subframes
Figure 4-11 Mapping the PDSCH to Subframes
The PDSCH carries DL data packets and some control packets. DL traffic is mapped into resource
blocks; each DL allocation is described in the PDCCH. The PDSCH may use QPSK, 16QAM or 64QAM
modulation.
The MAC Sublayer in the eNodeB is responsible for completely filling the DL allocation. If necessary,
padding is added to completely fill the allocated resource blocks.
During a subframe, several different UEs may share the PDSCH. Using the PDCCH control channel, the
eNodeB will assign one or more resource blocks to each UE.
2010
Version 2 Rev 4 Mapping DL Physical Channels to Subframes
Resource Mapping for DL Control Channels
Figure 4-12 Mapping PRBs and CCEs
DL control channels are carried in the first (even) slot of each subframe of a Transmission Time Interval
(TTI). DL control channels consist of some number of Resource Element Groups (REGs); a REG
consists of 4 Resource Elements.
The four resource elements in a REG are consecutive when not used for other purposes, such as
Reference Signals. Nine REGs form a Control Channel Element (CCE).
2010
Mapping DL Control Channels to Subframes
Figure 4-13 Mapping DL Physical Channels to Subframes
PCFICH Channel
The PCFICH channel is 4 REGs (16 resource elements) long and is located in the 1st symbol. The
PCFICH channel indicates how many (1-3) symbols are used by the DL control channels in this subframe.
The PCFICH REGs are distributed evenly across the system bandwidth (occupied subcarriers). The
exact location of the PCFICH REGs is calculated by the UE based on the physical cell identity.
PHICH Channel
The PHICH channel is 3 REGs (12 resource elements) long and is located in the 1st or 3rd symbol. This
channel carries the HARQ ACKs and NACKs for packets sent by a specific UE on the uplink. The PHICH
REGs are distributed evenly across the system bandwidth (occupied subcarriers). The resources used
for the PHICH are configured on a semi-static basis.
For FDD, the PHICH ACK/NACK is located 4 subframes after the UL subframe which contains the MAC
PDU. For TDD, the PHICH ACK/NACK location depends on the DL/UL configuration.
2010
PDCCH Structure
The PDCCH channel occupies the remaining resource elements in the 1st-3rd symbols (as signaled by
the PCFICH channel). The PDCCH channel describes DL traffic allocations for this subframe and future
UL bandwidth grants.
Multiple PDCCH control channels are supported and a UE monitors a set (aggregation) of control
channels. The PDCCH can be transmitted with 4 different formats.
PDCCH Formats
PDCCH Number of Number of Number of Bits
Number of REs
Format CCEs REGs in PDCCH
0 1 9 36 72
1 2 18 72 144
2 4 36 144 288
3 8 72 288 576
The PDCCH describes DL allocations for the current subframe,

and UL grants for a future subframe.
PDCCH describes resource allocation characteristics such as resource block group size and localized
or distributed RBs using a Downlink Control Information (DCI) format. PDCCH DCI main formats are
numbered 0-3, with minor variations labeled 1A, 1B, 1C, etc.

Telecoms
LTE
300
PDCCH Scheduling Information
Figure 4-14 PDCCH Scheduling Information
For each DL allocation, the PDCCH contains the UE C-RNTI, Transport Format, DL resource allocation
in resource blocks, and a Modulation and Coding Scheme (MCS) index. In addition it contains UL
grants, Transport Format and Transmit Power Commands (TPC) for UL transmissions on the PUSCH
or PUCCH.
C-RNTI – uniquely identifies the UE within the cell.
2010

Transport Format – specifies the physical layer processing, such as channel coding and interleaving,
and any service-specific rate matching.
Starting PRB – identifies the starting physical Resource Block number for the DL or UL allocation.
Number of PRBs – identifies the total number of physical Resource Blocks in the allocation.
MCS Index – identifies the modulation and coding scheme used for the allocation.
Transmit Power Command – instructs the UE to adjust its power level for the UL transmission.
Depending on the PDCCH format, the UE power may be adjusted from –1 dB to +3 dB.

Telecoms
LTE
300
2010
PDCCH MCS Index
PDCCH MCS Index

Modulation TB Size Index
MCS Index IMCS
Order ITBS
0 QPSK 0
1 QPSK 1
2 QPSK 2
3 QPSK 3
4 QPSK 4
5 QPSK 5
6 QPSK 6
7 QPSK 7
8 QPSK 8
9 QPSK 9
10 16QAM 9
11 16QAM 10
12 16QAM 11
13 16QAM 12
14 16QAM 13
15 16QAM 14
16 16QAM 15
17 64QAM 15
18 64QAM 16
19 64QAM 17
20 64QAM 18
21 64QAM 19
22 64QAM 20
23 64QAM 21
24 64QAM 22
25 64QAM 23
26 64QAM 24
27 64QAM 25
28 64QAM 26
29 QPSK Reserved
30 16QAM Reserved
2010

PDCCH MCS Index
Modulation TB Size Index
MCS Index IMCS
Order ITBS
31 64QAM Reserved

Telecoms
LTE
300
2010
PDCCH Transport Block Size Index
PDCCH TBS Index

NPRB
ITBS
1 2 3 4 5 6 7 8 100
0 16 32 56 88 120 152 176 208 2792
1 24 56 88 144 176 208 224 256 3624
2 32 72 144 176 208 256 296 328 4584
3 40 104 176 208 256 328 392 440 5736
4 56 120 208 256 328 408 488 552 7224
5 72 144 224 328 424 504 600 680 8760
6 328 176 256 392 504 600 712 808 10296
7 104 224 328 472 584 712 840 968 12216
8 120 256 392 536 680 808 968 1096 14112
9 136 296 456 616 776 936 1096 1256 15840
10 144 328 504 680 872 1032 1224 1384 17568
11 176 376 584 776 1000 1192 1384 1608 19848
12 208 440 680 904 1128 1352 1608 1800 22920
13 224 488 744 1000 1256 1544 1800 2024 25456
14 256 552 840 1128 1416 1736 1992 2280 28336

15 280 600 904 1224 1544 1800 2152 2472 30576
16 328 632 968 1288 1608 1928 2280 2600 32856
17 336 696 1064 1416 1800 2152 2536 2856 36696
18 376 776 1160 1544 1992 2344 2792 3112 39232
19 408 840 1288 1736 2152 2600 2984 3496 43816
20 440 904 1384 1864 2344 2792 3240 3752 46888
21 488 1000 1480 1992 2472 2984 3496 4008 51024
22 520 1064 1608 2152 2664 3240 3752 4264 55056
23 552 1128 1736 2280 2856 3496 4008 4584 57336
24 584 1192 1800 2408 2984 3624 4264 4968 61664
25 616 1256 1864 2536 3112 3752 4392 5160 63776
26 712 1480 2216 2984 3752 4392 5160 5992 75376
Using the TBS index (left column) and the number of Physical Resource Blocks allocated, the UE
calculates the size of the Transport Block.
This table shows only a few columns of the actual values. The full
table in TS 36.213 has 110 NPRB columns.
2010
Discontinuous Reception (DRX)

LTE supports DRX to enable UE power savings by turning off some or all of its radio circuitry, thereby
increasing the battery lifetime of the UE. The DRX function is configured and controlled by the network.
The UE behavior is based on a set of rules that define when the UE must monitor the PDCCH for
scheduling assignments.
When the UE does not have an established RRC connection, that is, no radio bearers configured for
data transmission, it wakes up and monitors the paging channel every DRX cycle. When the UE has an
RRC connection, the DRX function is characterized by a DRX cycle(s), an on-duration period(s), and an
inactivity timer.
Using RRC signaling, the eNodeB may configure the UE with a Discontinuous Reception (DRX) cycle
that allows it to monitor the PDCCH in a semi-periodic manner (as opposed to every 1ms TTI). The DRX
operation is governed by a Long DRX cycle, a DRX Inactivity Timer, a DRX Retransmission Timer and,
optionally, a Short DRX cycle and a DRX Short Cycle Timer.
When DRX is configured, the UE 'wakes up' at the beginning of the DRX cycle and monitors the PDCCH
for a configured number of TTIs. This period is called the On-Duration. If no assignment is detected on
the PDCCH, the UE goes back to 'sleep' until the next On-Duration. The Long or Short DRX cycle length
sets the periodicity of the On-Duration.
If, during the On-Duration, an uplink or downlink assignment is detected on the PDCCH the UE
stays awake and starts the DRX Inactivity Timer. Any subsequent PDCCH assignment for an initial
transmission (i.e. not for a retransmission) will reset the timer. The UE re-enters DRX when the
Inactivity Timer expires.
The UE always wakes up to read DL ACK/NACKs on the PHICH for each of its UL transmissions on
the PUSCH. DL HARQ operation is also independent of DRX operation, with the exception of the DRX
Retransmission Timer. This timer sets how many TTIs the UE stays awake when a retransmission is
expected (i.e. the UE has sent an uplink NACK).
Figure 4-15 DRX Cycle
2010

Broadcast Channel (PBCH)
Figure 4-16 Physical Broadcast Channel
The Physical Broadcast Channel (PBCH) broadcasts RRC System Information Master Information
Block (MIB) messages. This information is critical for user devices attempting to enter or re-enter the
network. The MIB contains:
• DL system bandwidth
• Number of eNodeB transmit antennas
• Reference Signal transmit power
• System frame number
For Frame Type 1, the PBCH is located on the 72 subcarriers centered around the DC subcarrier in slot
1, symbols 0 through 3. The PBCH information is spread over four consecutive LTE radio frames (40 ms
Transmit Time Interval).

Telecoms
LTE
300
2010
System Information Blocks (SIBs)

System Information Blocks 1-11 are transmitted on the PDSCH. The MAC PDU indicates a C-RNTI value
of hexadecimal FFFF for System Information.
System Information Blocks

SIB
Use
Type
SIB1 Carries PLMN ID, Tracking Area ID, Cell ID. cell barring status, etc. SIB1
is transmitted every 80 ms and indicates the transmission interval for other
recurring SIB types.
SIB2 Carries common and shared channel information.
SIB3 Carries cell reselection information, mainly related to the serving cell.
SIB4 Carries information about the serving neighboring frequencies and
intra-frequency neighboring cells relevant for cell re-selection, covering both
E UTRA and other RATs.
SIB5 Carries information about other E UTRA frequencies and inter-frequency
neighboring cells relevant for cell reselection.
SIB6 Carries information about UTRA frequencies and UTRA neighboring cells
relevant for cell reselection.
SIB7 Carries information about GERAN frequencies and GERAN neighboring cells
relevant for cell reselection.
SIB8 Carries information about cdma2000 frequencies and cdma2000 neighboring
cells relevant for cell reselection.
SIB9 Carries the identifier of the home eNodeB.
SIB10 Carries Earthquake and Tsunami Warning System (ETWS) primary
notification, including security information.
SIB11 Carries ETWS secondary notification; supports additional segments of
ETWS information.
SIB4-SIB8 messages carry cell reselection parameters for

EUTRAN and other Radio Access Technology (RAT) neighbors,
such as GSM, UTRA, and cdma2000.
3GPP TS 36.331 RRC Protocol Specification

Telecoms
LTE
300
2010
Version 2 Rev 4 Mapping UL Physical Channels to Subframes
Mapping UL Physical Channels to Subframes
Mapping PUSCH to Subframes
Figure 4-17 Mapping PUSCH to Subframes
Mapping PUSCH to Subframes The graphic illustrates the mapping of the PUSCH channel to subframes.
Resources for the PUSCH are allocated on a subframe basis by the eNodeB (in the PDCCH). Subcarriers
are allocated in physical resource blocks and may be frequency hopped from subframe to subframe. The
PUSCH may use QPSK, 16QAM or 64QAM modulation.
The MAC Sublayer in the UE is responsible for completely filling the UL grant. If necessary, padding is
added to completely fill the allocated resource blocks.

Telecoms
LTE
300
Mapping PUCCH to Subframes

Mapping PUCCH to Subframes The PUCCH carries uplink control information such as CQI, Scheduling
Requests, and ACKs/NACKs for a specific UE. It is never transmitted simultaneously with the PUSCH.
As shown in the graphic, the PUCCH transmission is frequency hopped at the slot boundary for added
reliability. More than one PUCCH channel may be present in a subframe.

Telecoms
LTE
300
2010
Mapping UL Physical Channels to Subframes Version 2 Rev 4

Figure 4-18
Multiple PUCCH in One Subframe
Figure 4-19 Multiple PUCCH in One Subframe
2010
Version 2 Rev 4 Mapping UL Physical Channels to Subframes

PUCCH Formats
The PUCCH supports the formats shown in the table below.
PUCCH Formats
PUCCH Modulation
Bits per Subframe TCP Carries
Format Scheme
1 N/A N/A Normal, Extended SR

1a BPSK 1 Normal, Extended SR, ACK/NACK
1b QPSK 2 Normal, Extended SR, ACK/NACK
2 QPSK 20 Extended CQI, ACK/NACK
2a QPSK+BPSK 21 Normal CQI, ACK/NACK
2b QPSK+QPSK 22 Normal CQI, ACK/NACK
For PUCCH Format 1, information is carried by the presence or

absence of any PUCCH transmission from the UE. For all other
formats, the UE explicitly transmits bits.
Random Access Channel
Figure 4-20 Random Access Channel
The Random Access Channel (RACH/PRACH) is an UL contention-based channel which allows any
UE to request network entry, access a target cell after handover, access a cell to send a Scheduling
Request, and so on. The UE uses the PRACH channel to send a Random Access Preamble.
2010
Mapping UL Physical Channels to Subframes Version 2 Rev 4

Random Access Preambles are transmitted on blocks of 72 contiguous 1.25 kHz subcarriers allocated
for the Physical Random Access Channel (PRACH) by the eNodeB. For burst formats 0-3, the PRACH
Configuration Index describes the burst format and subframe location within an LTE radio frame type
In addition, Frame Type 2 supports burst format 4. When using burst format 4, the UpPTS field carries
the PRACH channel using 7.5 kHz subcarriers.

Telecoms
LTE
300
2010
Lesson Summary
• LTE Logical, Transport, and Physical Channels

• How DL channels are mapped to physical subframes
• How UL channels are mapped to physical subframes
2010
Memory Points
2010
2010
Uu Interface Layer 2 Operation Version 2 Rev 4
Chapter 5
Uu Interface Layer 2 Operation
2010
Version 2 Rev 4 Uu Interface Layer 2 Operation
2010
Objectives
• List Uu Layer 2 sublayers

• Describe PCDP operation and headers
• Describe RLC operation and headers
• Describe MAC operation and headers
• Describe ARQ and HARQ error recovery
Figure 5-1
2010
Version 2 Rev 4 TCP/IP Protocol Suite
TCP/IP Protocol Suite
Figure 5-2 TCP/IP Protocol Suite
2010
Uu Interface Sublayers Version 2 Rev 4
Figure 5-3 Uu Interface Data Link Layer
For the Uu (air) interface, LTE divides the Data Link Layer into the following sublayers:
• Radio Resource Control (RRC)

• Packet Data Convergence Protocol (PDCP)
• Radio Link Control (RLC)
• Medium Access Control (MAC)
As illustrated in the graphic, LTE control traffic and bearer traffic
use different protocol stacks.
Radio Resource Control (RRC) Sublayer
Figure 5-4 RRC Sublayer
2010
The RRC Sublayer is responsible for broadcast of system information, RRC connection and configuration
control, paging, initial security activation, mobility and handovers, recovery from radio link failure and
generic protocol error handling, measurement configuration and reporting, and MBMS scheduling.
RRC connection and configuration control includes setting up Radio Bearer (RB) channels carrying user
data, QoS configuration, and error recovery (ARQ and HARQ) configuration.
3GPP TS 36.331 Radio Resource Control (RRC) Protocol

Telecoms
Specification
LTE
300
Packet Data Convergence Protocol (PDCP) Sublayer
Figure 5-5 PDCP Sublayer
The Packet Data Convergence Protocol (PDCP) Sublayer is responsible for transferring RRC signaling
or user data, compressing data packet headers, timer-based packet discards, and encrypting packets.
For signaling packets, the PDCP Sublayer also checks message integrity.
3GPP TS 36.323 Packet Data Convergence Protocol (PDCP)

Telecoms
Specification
LTE
300
2010
Uu Interface Sublayers Version 2 Rev 4
Radio Link Control (RLC) Sublayer
Figure 5-6 RLC Sublayer
The Radio Link Control (RLC) Sublayer segments large packets and concatenates small packets for
handling by the MAC Sublayer and Physical Layer. RLC supports acknowledged, unacknowledged, and
transparent mode operation. In addition, the RLC Sublayer performs Automatic Repeat Request (ARQ)
error recovery for data packets. ARQ is a retransmission error recovery technique.

Telecoms
LTE
300
Medium Access Control (MAC) Sublayer
Figure 5-7 MAC Sublayer
2010
The Medium Access Control (MAC) Sublayer performs dynamic scheduling of Physical Layer
resources, and maps data and control traffic to and from the Physical Layer. The MAC Sublayer
multiplexes RLC packets into a single MAC PDU for transmission by the Physical Layer. In addition,
the MAC Sublayer performs Hybrid ARQ (HARQ) error recovery. Like ARQ, HARQ is a retransmission
error recovery technique.

Telecoms
Specification
LTE
300
2010
Uu Physical Layer Version 2 Rev 4
Uu Physical Layer
Figure 5-8 Uu Physical Layer
As discussed in the last two lessons, the Uu Physical Layer applies FEC encoding, modulates bits,
and maps the modulated signals into physical frames and subframes. In addition, the Physical Layer
calculates and attaches a 24-bit Cyclic Redundancy Check (CRC) to the end of the MAC PDU before
scrambling and modulating the packet.
2010
Version 2 Rev 4 Uu Sublayers and Service Access Points
Uu Sublayers and Service Access Points
Figure 5-9 Uu Sublayers and SAPs
The PDCP, RLC, and MAC Sublayers, as well as the Physical Layer, act as service access points. A
Service Access Point (SAP) provides service to the layer or sublayer above. A SAP receives a Service
Data Unit (SDU) from the layer above. After processing the SDU, a service access point delivers a
Protocol Data Unit (PDU) for the layer below. A PDU typically includes the processed SDU, and one or
more headers inserted by the service access point.
2010
Data Flow Through the Uu Sublayers Version 2 Rev 4
Data Flow Through the Uu Sublayers
Figure 5-10 Data Flow Through the Sublayers
The graphic shows a data message progressing though the Uu Data Link sublayers.
Step
1. An upper layer data message is received at the PDCP Sublayer. PDCP may compress the IP
data packet headers, and encrypt the resulting compressed packet.
2. After attaching a PDCP header to the data, the PDCP Sublayer passes the data packet to
the RLC Sublayer.
3. The RLC Sublayer segments or concatenates PDCP packets as needed, and adds an RLC
header. An RLC packet may contain more than one PDCP packet or segment.
4. The MAC Sublayer adds a MAC subheader for each MAC packet. The MAC subheader
contains a logical connection ID and length field for each MAC packet. The resulting MAC
packet is passed to the Physical Layer for encoding, modulation, and transmission within a
DL or UL subframe.
2010
Version 2 Rev 4 PDCP Headers and Operation
PDCP Headers and Operation
Figure 5-11 PDCP Functions
The PDCP Sublayer provides services to signaling radio bearers (RRC control packets) or data radio
bearers (IP data bearer packets). A separate PDCP entity is associated with each signaling or data
radio bearer.
The PDCP Sublayer encrypts/decrypts data and control packets, compresses/decompresses data
packet headers, and checks control packets for message integrity.
The PDCP Sublayer supports two control messages: PDCP Status Report and ROHC Feedback Report.
3GPP TS 36.323 Packet Data Convergence Protocol (PDCP)

Telecoms
Specification
IETF RFC 3095 RObust Header Compression (ROHC):
LTE
300
Framework and four profiles: RTP, UDP, ESP and uncompressed

IETF RFC 3843 RObust Header Compression (ROHC): A
Compression Profile for IP
IETF RFC 4815 RObust Header Compression (ROHC):
Corrections and Clarifications to RFC 3095
IETF RFC 4995 The RObust Header Compression (ROHC)
Framework
IETF RFC 4996 RObust Header Compression (ROHC): A Profile
for TCP/IP (ROHC-TCP)
IETF RFC 5225 RObust Header Compression (ROHC) Version 2:
Profiles for RTP, UDP, IP, ESP and UDP Lite
2010
PDCP Header for Data Packets Version 2 Rev 4
PDCP Header for Data Packets
Figure 5-12 PDCP Header for Data Packets
The graphic shows an IP datagram after processing by the PDCP Sublayer. The PDCP PDU contains
the following fields:
• Data/Control Bit – This field is set to 1 for a data packet, or 0 for a control packet.
• Reserved Bits – Reserved bits have no meaning; each reserved bit is set to 0.
• Sequence Number – Each PDCP PDU is assigned a consecutive 7 or 12-bit sequence number.
The graphic shows the 12-bit format.
• IP Data – Variable length field containing either a compressed or uncompressed IP datagram or
datagram fragment. The IP data field may be encrypted.
A PDCP header using a 12-bit Sequence Number is exactly 2
bytes (16 bits) long. A PDCP header using a 7-bit Sequence
Number is 1 byte long, including a D/C bit and a 7-bit Sequence
Number.
2010
Version 2 Rev 4 PDCP Header for Control Packets
PDCP Header for Control Packets
Figure 5-13 PDCP Header for Control Packets
The graphic shows a control packet after processing by the PDCP Sublayer. The PDCP PDU contains
the following fields:
• Sequence Number – Each PDCP PDU containing a control packet is assigned a consecutive 5-bit
sequence number.
• Control Packet – Variable length field containing an RRC control packet. The control packet may
be encrypted.
• Message Authentication Check Integrity – 4-byte integrity check protecting the control packet. If
the control packet is encrypted, the MAC-I field is also encrypted. The MAC-I field is always present
for control packets; if integrity is unused, the field is set to binary zeros.
Integrity protection is only applied to control packets. The
complete un-ciphered PDCP PDU is integrity protected. The
integrity algorithm and key to be used is configured through
RRC/NAS signaling.
2010
PDCP and Header Compression Version 2 Rev 4
PDCP and Header Compression
TCP/IP Protocol Suite and Headers
Figure 5-14
If configured, PDCP may compress/decompress Layer 3 and above headers for data packets using the
IETF Robust Header Compression (ROHC) standards. Let's look at the overhead "cost" of headers at
Layer 3 and above.
• Internet Protocol (IP) Header – 20 bytes for IPv4 header or 40 bytes for IPv6 header
• Transmission Control Protocol (TCP) Header – 20 bytes for TCP header
• User Datagram Protocol (UDP) Header – 8 bytes for UDP header
• Application Header – Variable depending on application. For example, Voice over IP bearer
packets use a 12-byte Real-time Transport Protocol (RTP) header.
For LTE, header compression is only used on the air interface.
The upper layer headers are decompressed before the data
packet is forwarded by the eNodeB over the X2 or S1 interface.
2010
Version 2 Rev 4 PDCP and Header Compression
ROHC Compressor States
Figure 5-15 ROHC Compressor States
A ROHC compressor is in one of three states: Initialization and Refresh, First Order, and Second Order.
Initialization and Refresh (IR) state occurs when the compressor has just been created or reset. In IR
state, full (uncompressed) packet headers are sent.
In First-Order state, the compressor has detected and stored static fields such as IP addresses and port
numbers. The compressor also sends dynamic packet field differences. This state compresses all static
fields and some dynamic fields.
In Second-Order state, the compressor suppresses all dynamic fields such as RTP sequence numbers.
In this state, the transmitter sends a logical sequence number and partial checksum, which the receiver
uses to predict the dynamic fields of the next expected packet. This state compresses all static fields
and all dynamic fields.
If compression or decompression failures are detected, the compressors will revert to IR state.
2010
PDCP and Header Compression Version 2 Rev 4

Robust Header Compression (ROHC) Profiles
Figure 5-16 Robust Header Compression (ROHC) Profiles
Header compression profiles describe the rules for ROHC compression. If used, header compression
will reduce the combined IPv4 + UDP + RTP header size from 40 bytes to 2-4 bytes.
ROHC Profiles
ROHC Profile Identifier
Usage Reference
(Hex.)
0x0000 No compression RFC 4995
0x0001 RTP/UDP/IP RFC 3095, RFC 4815
0x0002 UDP/IP RFC 3095, RFC 4815
0x0003 ESP/IP RFC 3095, RFC 4815
0x0004 IP RFC 3843, RFC 4815
0x0006 IP + TCP RFC 4996
0x0101 RTP/UDP/IP RFC 5225
0x0102 UDP/IP RFC 5225
0x0103 IP + ESP RFC 5225
0x0104 IP RFC 5225
The specific ROHC profile to use for a given data radio bearer is configured using RRC signaling.
Profiles 101-104 are defined using ROHC v2 which introduces

several improvements over ROHC v1.
2010
Version 2 Rev 4 PDCP and Header Compression
ROHC Status PDU
Figure 5-17 ROHC Status PDU
PDCP uses a ROHC Status PDU to carry header compression control information. This PDU is not
associated with higher layer (IP) data or RRC signaling; it is used to exchange control information needed
for compression/decompression between the UE and eNodeB.
• Data/Control Bit – This one-bit field is set to 0 for a control packet.

• PDU Type – This three-bit field is set to 001 for a ROHC Status PDU message.
• Payload – This variable-length field carries the ROHC control parameters.
2010
PDCP Status Report Version 2 Rev 4
PDCP Status Report
Figure 5-18
PDCP uses a PDCP Status Report message to report missing or duplicated PDCP PDUs after a handover
and to, if necessary, initiate retransmission of missing PDUs.
• Data/Control Bit – This one-bit field is set to 0 for a control packet.

• PDU Type – This three-bit field is set to 000 for a PDCP Status Report message.
• First Missing Sequence Number (FMS) – This 12-bit field carries the sequence number of the
first missing PDCP SDU.
• Bitmap – This variable-length field indicates if the PDCP SDU immediately following the missing
packet has been received and, optionally, decompressed correctly. The transmitter fills the bitmap
indicating which SDUs are missing, and which SDUs do not need retransmission.
2010
Version 2 Rev 4 Radio Link Control (RLC) Operation
Radio Link Control (RLC) Operation
Figure 5-19 RLC Functions

Telecoms
LTE
300
2010
Radio Link Control (RLC) Operation Version 2 Rev 4

RLC Packet Flow
Figure 5-20 Packet Flow
The RLC Sublayer receives a PDCP PDU (RLC SDU) from the PDCP Sublayer. After processing the
packet, an RLC header is attached to the front of the packet.
Transport Block Size
Figure 5-21 Transport Block Size
2010

The RLC Sublayer must prepare a PDU that fills the Physical Layer grant. The graphic illustrates this
process for the uplink.
The eNodeB “advertises” an UL grant for the UE in the PDCCH channel. The UL grant is described using
a modulation scheme and some number of resource blocks.
The MAC Sublayer calculates the number of bits/bytes represented by the grant and reports the
scheduled bandwidth to the RLC Sublayer as the Transport Block (TB) size. Using concatenation and
segmenting, the RLC Sublayer builds a PDU that fills the “advertised” TB size.
The MAC Sublayer may support multiple RLC Sublayers. When

serving different RLC stacks, the MAC Sublayer must balance
QoS requirements and data already buffered for transport.
RLC Modes
• Transparent Mode (TM)
– No RLC header
– No segmenting or concatenation
– Used for Broadcast (BCCH),Paging ( PCCH), and other ( CCCH) control packets
• Unacknowledged Mode (UM)
– Includes RLC header
– Supports segmenting and concatenation
• Acknowledged Mode (AM)
– Includes RLC header
– Supports segmenting and concatenation
– ACKs/NAKs with RLC Status PDU
In AM and UM modes, the RLC Sublayer segments and concatenates PDCP packets to form RLC PDUs.
How large an RLC PDU is allowed, e.g. when should a packet be segmented?
Based on dynamic grants or allocations, the MAC Sublayer determines the allowed TB size and passes
that information to the RLC Sublayer. The RLC Sublayer uses the TB size as it processes the PDCP
packets.
2010

Unacknowledged Mode RLC PDU – One Data Element
Figure 5-22 Unacknowledged Mode RLC PDU – One Data Element
The graphic shows an Unacknowledged Mode (UM) RLC PDU with one PDCP packet in the data field
(one data element). The RLC header contains the following fields:
• Extension Bit – 0 indicates the data field follows the SN; 1, other header fields follow.
• Framing Indicator (FI) – 2-bit field that indicates the presence of segments in the data field.
Framing Indicator Values
FI Value Description
00 First data byte associated with the beginning of an RLC SDU; last data byte
associated with the end of an RLC SDU.
associated with an RLC segment.
10 First data byte associated with an RLC segment; last data byte associated
with the end of an RLC SDU.
with an RLC segment.
• Sequence Number (SN) – 5-bit or 10-bit number assigned to every RLC PDU. The sequence
number is incremented by one for each RLC PDU.
2010
Acknowledged Mode RLC PDU – One Data Element
Figure 5-23 Acknowledged Mode RLC PDU – One Data Element
The graphic shows an Acknowledged Mode (AM) RLC packet with one PDCP packet in the data field.
The RLC header contains the following fields:
• Data/Control Indicator – 0 indicates this is a control packet; 1 indicates a data packet.

• Polling Bit (P) – 1 indicates a Status report is requested; 0, no Status report is requested.
• Resegmentation Flag (RF) – 0 indicates the RLC PDU is a complete PDU; 1 indicates a PDU
segment.
• Framing Indicator (FI) – 2-bit field that indicates the presence of segments in the data field.
Framing Indicator Values
FI Value Description
associated with the end of an RLC SDU.
associated with an RLC segment.
with the end of an RLC SDU.
with an RLC segment.
• Extension Bit – 0 indicates the data field follows the SN; 1, other header fields follow.
• Sequence Number (SN) – 10-bit number assigned to every RLC PDU. The sequence number is
incremented by one for each RLC PDU.
2010
RLC Concatenation
Figure 5-24 RLC Concatenation
As part of its traffic scheduling responsibility, the MAC Sublayer passes a Transport Block to the RLC
Sublayer describing the current transport capability for a logical connection. The RLC Sublayer may
concatenate (join together) more than one data element into a single RLC PDU to take full advantage of
the transport capability.
The graphic shows three data elements (RLC SDUs) concatenated into one RLC PDU. The RLC header
includes length fields used by the receiver to locate the separate data elements. Except for the last data
element, each concatenated data element has an associated length field in the RLC header.
The concatenated SDUs must be associated with the same

logical channel. The MAC Sublayer attaches a subheader with a
(single) logical channel ID to the RLC PDU.
2010

Acknowledged Mode RLC PDU – Multiple Data Elements
Figure 5-25 Acknowledged Mode RLC PDU – Multiple Data Elements
In addition to the fields already described, a concatenated PDU also contains additional Extension Bits
and Length Indicator fields.
• Length Indicator (LI) Field – 11-bit field that indicates the length in bytes of the associated data
element. An 11-bit length field allows values up to 2047.
Octet 1
• E = 1 indicates additional fields follow the Sequence Number.

Octet 3
• E = 1 indicates an additional E Bit and LI field follow the LI-1 field.

• LI-1 contains the length in bytes of the first data element (PDCP PDU 1).
Octet 4-5
• E = 0 indicates the data field follows the LI-2 field.

• LI-2 contains the length in bytes of the second data element (PDCP PDU 2).
The graphic shows an Acknowledged Mode (AM) RLC PDU with
three data elements. Exactly the same Bit and Length Indicator
fields are used with Unacknowledged Mode (UM).
2010

RLC Segmenting
Figure 5-26 RLC Segmenting
If necessary, the RLC Sublayer may segment (break apart) large data packets. Each segment is
transmitted in a separate RLC PDU. The RLC header describes how to rebuild the original data packet
using the Segment Offset and Last Segment Flag fields.
A large PDU may be broken into many segments. Every PDU

segment shares the same sequence number.
2010

Acknowledged Mode RLC PDU – Data Segment
Figure 5-27 Acknowledged Mode RLC PDU – Data Segment
In addition to the fields already described, a segment header also contains the following fields:
• Last Segment Flag (LSF) – 1 indicates this is the last segment of a data packet; 0 indicates this
is a first or middle segment.
• Segment Offset (SO) – Indicates the position in the original data packet associated with the first
data byte of this segment.
Octet 1
• E = 1 indicates additional fields follow the Sequence Number.

• RF = 1 indicates the data field contains a segment.
• FI = 01 indicates the first data byte is associated with the beginning of an SDU, while the last data
byte is not associated with the end of an SDU.
Octets 3-4
• LSF = 0 indicates this is not the last segment of an SDU.

• Segment Offset indicates the SDU offset position of the first data byte of this segment.
An RLC PDU may contain a segment and complete SDU. In
that case, the RLC header includes a length field for each data
element except the last.
2010
ARQ Error Recovery Version 2 Rev 4
ARQ Error Recovery
LTE and TCP/IP Error Handling
Figure 5-28 LTE and TCP/IP Error Handling
Error handling and recovery occurs on many layers and sublayers. The LTE Physical Layer uses
Forward Error Correction (FEC) overhead to recover from bit errors introduced by the air interface.
The LTE Layer 2 offers two error recovery techniques: ARQ and HARQ. Hybrid Automatic Repeat
Request (HARQ) offers quick, interval-based ACKs/NACKs with retransmissions. Automatic Repeat
Request (ARQ) offers slower, sequence number based ACKs/NACKs with retransmissions.
At Layer 4, both TCP and SCTP perform error recovery and retransmission.
Layer 5 offers several possible error recovery techniques. For applications that run on top of UDP, the
application protocol may offer sequence number and/or timer-based retransmission.
Voice and video traffic may use interpolation, prediction, or erasure error recovery techniques.
Note that the error recovery time-out period increases as you

move up the protocol stack. From a delay perspective, we want to
recover from error conditions at the lowest layer possible.
2010
Version 2 Rev 4 ARQ Error Recovery
ARQ Error Recovery

ARQ Operation
Figure 5-29 ARQ Operation
1 The RLC transmitter sends AM data, sequence number 1. The Polling

bit is set to 1, ordering the receiver to return an RLC Status message.
2 The RLC receiver returns a Status message with the ACK_SN set to
2. ACK_SN 2 indicates data message 1 was correctly received; the
next expected sequence number is 2.
3 The RLC transmitter sends Acknowledged Mode data, sequence
number 2 with the Polling bit = 1. This message was lost or corrupted
during transmission.
4 The RLC transmitter sends AM data, sequence number 3 with the
Polling bit = 1.
5 The RLC receiver returns a Status message with the ACK_SN=4 and
NACK_SN=2. ACK_SN 4 indicates data message 3 was correctly
received; the next expected sequence number is 4. However,
NACK_SN=2 orders the transmitter to resend message 2.
6 The RLC transmitter resends data message 2 with the Polling bit = 1.
7 The RLC receiver returns a Status message with the ACK_SN set
to 4 indicating all data messages up to (but not including) 4 were
correctly received.
The RLC Sublayer only supports ARQ for AM data packets.
2010
ARQ Error Recovery Version 2 Rev 4
ARQ Error Recovery
RLC Status PDU
Figure 5-30 RLC Status PDU (ACK + NACK)
The RLC STATUS PDU consists of an RLC Control header and a STATUS PDU payload. The RLC
Control header consists of a D/C bit and a Control PDU Type (CPT) field.
The payload consists of a ACK Sequence Number and one E1 field, zero or more sets of NACK_SN, E1
bit, and E2 bit, and possibly a set of Segment Offset Start (SOstart) and Segment Offset End (SOend)
fields for each NACK_SN. If necessary, padding bits are included to achieve octet alignment.
2010
Version 2 Rev 4 ARQ Error Recovery
ARQ Error Recovery

Figure 5-31
RLC Status PDU Fields
• Data/Control (D/C) Indicator – 0 indicates this is a control packet.

• Control PDU Type (CPT) – This 3-bit field indicates the type of RLC control packet. The Status
PDU has a type value of 000; all other values are currently reserved.
• ACK_SN – Indicates the 10-bit sequence number of the next RLC data PDU to be received. The
receiver interprets that all data PDUs up to but not including the ACK_SN have been correctly
received by its RLC peer, excluding any PDUs indicated with NACK_SN.
• E1 BIt – Indicates if a set of NACK_SN, E1, and E2 fields does (1) or does not (0) follow.
• NACK_SN – Indicates the 10-bit sequence number of the RLC data PDU that has been detected
as lost by the receiver.
• E2 Bit – Indicates if a set of SOstart and SOend fields does (1) or does not (0) follow.
• Segment Offset Start (SOstart) – This 15-bit field indicates the beginning data byte number of the
missing segment of the message identified by NACK-SN.
• Segment Offset End (SOend) – This 15-bit field indicates the ending data byte number of the
missing segment of the message identified by NACK-SN. If the SOend value is set to all 1 bits, the
missing portion extends from the SOstart to the last byte of the data PDU.
2010
MAC Headers and Operation Version 2 Rev 4
MAC Headers and Operation
Figure 5-32 MAC Functions

Telecoms
Specification
LTE
300
2010
Version 2 Rev 4 MAC Headers and Operation

Packet Flow
Figure 5-33 Packet Flow
The MAC Sublayer receives an RLC PDU (MAC SDU) from the RLC Sublayer. After processing the
packet, an MAC subheader is attached to the front of the packet. The MAC packet may contain more
than one RLC PDU and MAC subheader.
2010
MAC Subheader
Figure 5-34 MAC Subheader Fields
The MAC Sublayer creates a MAC subheader for each RLC PDU. MAC subheaders contain the following
fields:
• Extension Bit – 1 indicates more subheader bytes or more subheaders follow; 0 indicates last or
only subheader.
• Logical Channel ID (LCID) – 5-bit field that identifies the logical channel for the associated packet.
• Format Bit – 0 indicates the Length field is 7-bits long; 1 indicates the Length field is 15-bits long.
• Length Field – 7-bit or 15-bit field that indicates the length in bytes of the associated packet. A
7-bit length field allows values up to 127; a 15-bit length field allows values up to 32,767.
2010

Figure 5-35 MAC Subheader Octets
Several RLC PDUs may be multiplexed together in a single MAC PDU. Each RLC PDU will have its own
MAC subheader. The Length field indicates the size (and relative position) of each component of the
MAC PDU.
• 1-Octet MAC Subheader – A MAC subheader without a Length field is associated with the last or
only RLC PDU in the MAC PDU. This subheader format is also used for known fixed-length MAC
components.
• 2-Octet MAC Subheader – A MAC subheader with a 7-bit Length field (F bit=0). This format is
used with an RLC PDU up to 127 bytes long, which is not the last component in the MAC PDU.
• 3-Octet MAC Subheader – A MAC subheader with a 15-bit Length field (F bit=1). This format is
used with an RLC PDU greater than 127 bytes long, which is not the last component in the MAC
PDU.
Logical Channel Identifier (LCID) Values

DL Logical Channel IDs for the DL Shared Channel
DL Logical Channel IDs

Connection Type LCID Value LCID Binary Value
Common Control Channel 00 00000
(CCCH)
Dedicated Logical Channels 01-0A 00001–01010
Reserved 0B–19 01011–11001
UE Contention Resolution ID 1C 11100
Timing Advance 1D 11101
Discontinuous Reception 1E 11110
(DRX) Cmd
Padding 1F 11111
2010

UL Logical Channel IDs for the UL Shared Channel
UL Logical Channel IDs

Connection Type LCID Value LCID Binary Value
Common Control Channel 00 00000
(CCCH)
Dedicated Logical Channels 01–0A 00001–01010
Reserved 0B-19 01011–11001
Power Headroom Report 1A 11010
Cell Radio Network 1B 11011
Temporary ID (C-RNTI)
Truncated Buffer Status 1C 11100
Report (BSR)
Short Buffer Status Report 1D 11101
(BSR)
Long Buffer Status Report 1E 11110
(BSR)
Padding 1F 11111
MAC Sublayer Multiplexing
Figure 5-36 MAC Sublayer Multiplexing
The graphic shows the MAC multiplexing process. In this example, three RLC PDUs will be multiplexed
into one MAC PDU. A separate MAC subheader is created for each RLC PDU. The MAC subheaders for
RLC PDU 1 and 2 must contain Length fields; the MAC subheader for PDU 3 will not include a Length
field (last PDU).
2010

The MAC PDU begins with all of the MAC subheaders, followed by the component RLC PDUs in exactly
the same order as the MAC subheaders.
The MAC Sublayer can multiplex RLC PDUs together. However

it cannot segment or reassemble RLC PDUs. Only the RLC
Sublayer may segment packets.
MAC Control Elements
Figure 5-37 MAC Control Elements
The graphic shows a MAC PDU with Control Elements and an RLC PDU. A Control Element is a special
MAC “signaling message” used for Random Access Responses, UE buffer status reporting, and so on.
Control Elements are placed before RLC PDUs in the MAC payload.
Each MAC Control Element has its own MAC subheader.
MAC Control Element Types

Control Element Logical
Direction 2CE Size
Type Chan ID
Buffer Status UL 1C, 1D, 1E 8 or 24 bits
Report (BSR)
Cell Radio UL 1B 16 bits
Network
Temporary ID
(C-RNTI)
Discontinuous DL 1E 0 bits
Reception (DRX)
Command
2010

MAC Control Element Types
Control Element Logical
Direction 2CE Size
Type Chan ID
Power Headroom UL 1A 6 bits (+2 reserved)
Report
Timing Advance DL 1D 6 bits (+2 reserved)
(TA)
UE Contention DL 1C 48 bits
Resolution ID
Backoff Indicator DL N/A 0 bits
(BI)
Random Access DL N/A 48 bits
Response (RAR)
The following MAC Control Elements are defined:
• Buffer Status Report (BSR) – Sent by UE to describe the number of bytes of data ready for UL
transport
• C-RNTI – Sent by UE to identify the sending UE and traffic flow
• DRX Command – Sent by eNodeB to trigger discontinuous reception in the UE
• Power Headroom Report – Sent by UE to indicate the difference (headroom) between its current
power output and its maximum power output
• Timing Advance (TA) – Sent by eNodeB to adjust UE timing in .5 µs increments
• UE Contention Resolution ID – Sent by eNodeB to resolve UE contention on the PRACH
• Backoff Indicator (BI) – Sent by the eNodeB to indicate an overload condition
• Random Access Response (RAR) – Sent by the eNodeB in response to a Random Access
Preamble
2010
Version 2 Rev 4 Random Access Operation
Random Access Operation
Figure 5-38 Random Access Preamble
The Random Access Procedure is used by the UE to access the network when it does not have a
dedicated signaling channel. Random access is used for:
• Initial Access from RRC-IDLE – initial attachment/registration upon power-up, Tracking Area
Updates, UE attempting to set-up a data session, UE answering a page or session request.
• Handover – the UE must perform a Random Access Procedure with the new target cell before
resuming service.
• UL/DL data arrival in RRC-CONNECTED – UE may lose synchronization with the network OR
there are no scheduled resources for the for data transmission in the uplink.
The standard also defines two different types of Random Access Procedures:
• Contention-based – the UE transmits any valid RA Preamble ID for the cell. Other UEs may use
the same RA Preamble ID. This is used mainly in the Initial Access described above.
• Non-contention-based – the eNodeB assigns a specific RA Preamble ID to the UE. This
procedure is used in handovers and resumption of downlink data transmission while the UE is in
RRC-CONNECTED mode.
2010
Random Access Operation Version 2 Rev 4

Random Access Response
Figure 5-39 Random Access Operation
Step
1 During network entry or an RRC state change, the UE will send an RA

Preamble over the Physical Random Access Channel (PRACH).
2 If successfully received, the eNodeB returns a Random Access Response
(RAR). The Random Access Response contains an UL grant and a
Temporary C-RNTI.
3 The UE will use the UL grant to send a MAC PDU, such as an RRC
Connection Request or a MAC Buffer Status Report.
2010

Backoff Indicator
Figure 5-40 Backoff Indicator Operation
Step
1 During network entry or an RRC state change, the UE will send an RA

Preamble over the Physical Random Access Channel (PRACH).
2 If the eNodeB is congested, it will return a Backoff Indicator (BI). The BI
indicates how many milliseconds the UE must wait before sending another
Random Access Preamble.
3 After the time interval specified on the BI, the UE may send another RA
Preamble in the next PRACH opportunity.
2010

Random Access Response
Figure 5-41 Random Access Response Control Element
RAR/BI MAC Header Fields
• E Bit – A 1-bit field indicating more RAR headers are present (1), or not present (0).
• Type (T) Bit – A 1-bit field indicating the RAR subheader format. T is set to 1 to indicate a Random
Access ID, or 0 to indicate a Backoff Indicator. If T=1, a Random Access Response field is present
after the MAC subheader.
• Random Access Preamble ID (RAPID) – A 6-bit field identifying the transmitted Random Access
Preamble.
• R Bit – Reserved bit, set to 0.
2010

Backoff Indicator
Figure 5-42 Backoff Indicator
• Backoff Indicator (BI) – A 4-bit field describing the overload condition in the cell. The UE must
wait n milliseconds before attempting random access again.
Backoff Indicator Values
Index Backoff Indicator (ms)
0 0
1 10
2 20
3 30
4 40
5 60
6 80
7 120
8 160
9 240
10 320
11 480
12 960
13–15 Reserved
2010
Random Access Response (RAR) Control Element Fields
Figure 5-43 RAR Control Element Fields
• Timing Advance (TA) – An 11-bit field indicating the required adjustment to the UL transmission
timing for timing synchronisation. The timing adjustment units are .5 µs.
• UL Grant – A 20-bit field indicating the UL resources granted to the UE. The subfields are described
on the next page.
• Temporary C-RNTI – A 16-bit field indicating the temporary identity used by the UE during random
access operation.
2010
Random Access Response UL Grant
Figure 5-44 RAR UL Grant Subfields
The 20-bit UL Grant contains the following subfields:
• Hopping Flag Bit – If set to 1, the UE must perform PUSCH frequency hopping.
• Resource Block Assignment – A 10-bit field that indicates the number of resource blocks allocated
for the UL grant.
• Truncated Modulation and Coding Scheme – A 4-bit field that identifies the MCS required for the
UL grant.
• TPC command for scheduled PUSCH – A 3-bit field that indicates the required power setting for
the PUSCH channel.
• UL Delay Bit – If set to 0, UL Delay indicates the UL grant will occur in the next available subframe.
If set to 1, the UL must postpone the UL PUSCH transmission to the first available opportunity after
the next available subframe.
• CQI Request Bit – If set to 1, the UE must perform CQI reporting using the PUSCH channel.
2010
HARQ Operation Version 2 Rev 4
HARQ Operation
• Hybrid ARQ is an interval-based error recovery technique
• A MAC PDU transmitter must receive a HARQ ACK before transmitting the next MAC PDU
• For FDD, the HARQ ACK or NACK occurs 4 subframes after the beginning of a MAC PDU
Figure 5-45 HARQ Operation
2010
Version 2 Rev 4 DL and UL Scheduling
DL and UL Scheduling
Figure 5-46 FDD Scheduling
As we saw in Lesson 2, the eNodeB describes both DL and UL scheduling in the Physical Downlink
Control Channel (PDCCH). Each DL allocation or UL grant contains the following information:
• UE’s C-RNTI
• Starting resource block within the DL or UL subframe
• Number of resource blocks in the allocation or grant
• Modulation scheme selected by the eNodeB
DL Allocation
The UE must detect its C-RNTI in the PDCCH and interpret the MAC PDU in the DL allocation.
Remember, the MAC PDU contains a shared Logical Channel ID; the C-RNTI describes the specific
UE for this packet.
UL Grant
The UE must completely fill the bandwidth grant, inserting padding if necessary.
2010
DL and UL Scheduling Version 2 Rev 4
UE Cell-Based Identities
Figure 5-47 UE Cell-Based IDs
LTE relies on temporary identities for UE scheduling and operation. The manufacturer assigns a static
International Mobile Equipment ID (IMEI) to each UE type. The service provider assigns a static
International Mobile Subscriber ID (IMSI) to each subscriber UE (USIM card). The P-GW dynamically
assigns an IP address to the UE during network entry and registration. However, the eNodeB assigns
a 2-byte temporary ID called the Cell Radio Network Temporary ID (C-RNTI) to the UE for scheduling
UL bandwidth grants and DL allocations.
RNTI Values
FDD TDD RNTI
0000-0009 0000-003B RA-RNTI
000A-FFF2 003C-FFF2 C-RNTI, Semi-Persistent Scheduling C-RNTI,
Temporary C-RNTI, TPC-PUCCH-RNTI and
TPC-PUSCH-RNTI
FFF3-FFFC Reserved
FFFE P-RNTI
FFFF System Information (SI-RNTI)
2010
Dynamic UL Scheduling
Figure 5-48 Dynamic UL Scheduling
Step
1 The UE sends a contention-based or non-contention-based Random

Access Preamble on the PRACH
2 If successfully received, the eNodeB returns a Random Access
Response (RAR) on the PDSCH. The RAR contains an UL grant and a
Temporary C-RNTI.
3 The UE uses the UL grant to send a Scheduling Request on the PUCCH.
4 The eNodeB schedules an UL resource allocation and notifies the UE
using the PDCCH.
5 The UE uses the UL grant to send a MAC data packet on the PDSCH.
If the UE receives an UL grant, it may send a Buffer Status

Report (BSR) with the data packet.
2010
Semi-Persistent Scheduling
Figure 5-49 Semi-Persistent Scheduling
In semi-persistent scheduling, the eNodeB provides the UE an UL grant or DL allocation which

automatically repeats every n subframes. The semi-persistent interval n is configured via RRC signaling,
while the activation or deactivation of the semi-persistent scheduling is performed using the PDCCH.
Step
1 The eNodeB sends a semi-persistent UL grant to the UE.

2 The UE uses the UL grant to send data packet 1. The MAC PDU wil contain
the Semi-Persistent Scheduling RNTI (SP-RNTI) rather than the C-RNTI.
3 N subframes later, the UE sends data packet 2 using the SP-RNTI.
4 N subframes later, the UE sends data packet 3 using the SP-RNTI.
If dynamic scheduling and semi-persistent scheduling occur in the

same subframe for a UE, the dynamic scheduling has a higher
priority.
2010
Buffer Status Report (BSR) Control Element
Figure 5-50 BSR Control Element
Using the Buffer Status Report Control Element, the UE signals the amount of data in its UL buffers.
The UE sends a BSR when new UL data is ready for transmission, the UE moves to another cell, or a
periodic BSR timer expires.
The UE may organize its logical channels into up to four groups, based on increasing priority. The UE
reports on the number of bytes ready for transmission for one Logical Channel Group (short BSR), or
more than one (long BSR). The graphic illustrates both formats.
• Logical Channel Group ID – A 2-bit field identifying a specific group of logical channels.
• Buffer Size – A 6-bit field indicating the total amount of data available for all logical channels of a
specific Logical Channel Group. The Buffer Size includes all RLC and PDCP data, not counting
the RLC and MAC headers. The Buffer Size values are listed in the table on the next page.
Only one BSR Control Element may be used in a MAC PDU.
2010
Buffer Size Values for Buffer Status Reports (BSRs)
Buffer Size Values

Buffer Size Buffer Size value Buffer Size value
Index Index Index
value (bytes) (bytes) (bytes)
0 Buffer Size = 0 22 234 < BS ≤ 274 44 7505 < BS ≤ 8787
1 0 < BS ≤ 10 23 274 < BS ≤ 321 45 8787 < BS ≤ 10287
2 10 < BS ≤ 12 24 321 < BS ≤ 376 46 10287 < BS ≤ 12043
3 12 < BS ≤ 14 25 376 < BS ≤ 440 47 12043 < BS ≤ 14099
4 14 < BS ≤ 17 26 440 < BS ≤ 515 48 14099 < BS ≤ 16507
5 17 < BS ≤ 19 27 515 < BS ≤ 603 49 16507 < BS ≤ 19325
6 19 < BS ≤ 22 28 603 < BS ≤ 706 50 19325 < BS ≤ 22624
7 22 < BS ≤ 26 29 706 < BS ≤ 826 51 22624 < BS ≤ 26487
8 26 < BS ≤ 31 30 826 < BS ≤ 967 52 26487 < BS ≤ 31009
9 31 < BS ≤ 36 31 967 < BS ≤ 1132 53 31009 < BS ≤ 36304
10 36 < BS ≤ 42 32 1132 < BS ≤ 1326 54 36304 < BS ≤ 42502
11 42 < BS ≤ 49 33 1326 < BS ≤ 1552 55 42502 < BS ≤ 49759
12 49 < BS ≤ 57 34 1552 < BS ≤ 1817 56 49759 < BS ≤ 58255
13 57 < BS ≤ 67 35 1817 < BS ≤ 2127 57 58255 < BS ≤ 68201
14 67 < BS ≤ 78 36 2127 < BS ≤ 2490 58 68201 < BS ≤ 79846
15 78 < BS ≤ 91 37 2490 < BS ≤ 2915 59 79846 < BS ≤ 93479
16 91 < BS <= 107 38 2915 < BS ≤ 3413 60 93479 < BS ≤ 109439
17 107 < BS ≤ 125 39 3413 < BS ≤ 3995 61 109439 < BS ≤ 128125
18 125 < BS ≤ 146 40 3995 < BS ≤ 4677 62 128125 < BS ≤ 150000
19 146 < BS ≤ 171 41 4677 < BS ≤ 5476 63 Buffer Size > 150000
20 171 < BS ≤ 200 42 5476 < BS ≤ 6411
21 200 < BS ≤ 234 43 6411 < BS ≤ 7505
2010
Lesson Summary
• The Uu Layer 2 sublayers

• PDCP headers and operation for data and control packets RLC headers, concatenation, and
multiplexing
• MAC subheaders and multiplexing
• Special MAC signaling including Buffer Status Reports and Random Access Responses
• ARQ and HARQ error recovery
2010
Memory Points
2010
2010
EPC Protocol Overview Version 2 Rev 4
Chapter 6
EPC Protocol Overview
2010
Version 2 Rev 4 EPC Protocol Overview
2010
Objectives
• Describe the EPC protocol stacks
• Compare EPS interface functions
• List EPC signaling messages
• Describe UE and network element identifiers
2010
Version 2 Rev 4 Selected EPS Interfaces
Selected EPS Interfaces
Figure 6-2 Selected EPS Interfaces
Each interface supports a different set of control and status messages.
• Uu Interface – The air interface between the UE and the eNodeB.

• S1-MME Interface – The logical signaling interface between an eNodeB and MME. Each eNodeB
must be logically connected to every MME in the serving MME pool. This interface carries S1
Application Protocol (S1AP) control plane (signaling) traffic.
• S1-U Interface – The logical “data” interface between an eNodeB and S-GW. This interface carries
GPRS Tunneling Protocol – User Plane (GTP-U) traffic between an eNodeB and S-GW on behalf
of a UE. Each eNodeB must be logically connected to every S-GW in the serving S-GW pool.
• S5 Interface – The logical interface between an S-GW and P-GW. This interface carries GTP-C
control plane traffic and GTP-U user plane traffic between an S-GW and a P-GW.
• S6a Interface – The logical signaling interface between an MME and HSS. This interface carries
Diameter control plane traffic to authenticate the UE, and update the UE context.
• S10 Interface – The logical interface between two MMEs. This interface carries GTP-C control
plane traffic which manages UE handovers between two MMEs.
• S11 Interface – The logical signaling interface between an MME and S-GW. This interface carries
GTP-C control plane traffic which sets up and manages S5 user plane tunnels, and signals paging
is required for incoming data sessions.
• X2 Interface – The logical interface between two adjacent eNodeBs. The X2 interface carries
both control plane and GTP-U user plane traffic. The control plane traffic uses the X2 Application
Protocol (X2AP).
2010
EPS and TCP/IP Protocol Suite Version 2 Rev 4
EPS and TCP/IP Protocol Suite
Figure 6-3 TCP/IP Protocol Suite
The 3GPP standards describe an all-IP network. Both control plane (signaling) traffic and user plane
(bearer) traffic use the TCP/IP protocol suite. Except for the LTE air (Uu) interface, (almost) any Data
Link and Physical Layer protocols are allowed.
3GPP mandates support for either IPv4 or IPv6, or both. Depending on the interface and traffic
type, Transmission Control Protocol(TCP), User Datagram Protocol (UDP), or Stream Control
Transmission Protocol (SCTP) may be used at the Transport Layer.
The LTE air (Uu) interface subdivides the Data Link Layer into sublayers for user bearer and control
traffic.
All bearer traffic, including voice, video and data, uses IP for
transport. Either IPv4 or IPv6, or both, may be supported.
2010
Version 2 Rev 4 Control Plane
Control Plane
Figure 6-4 Control Plane
A Control Plane (CP) describes the protocol stack(s) required to transport control (signaling) traffic.
The LTE/SAE architecture distinguishes between signaling that directly controls the Uu (air) interface or
Access Stratum (AS), and Non-Access Stratum (NAS) signaling passed transparently from the UE to
the MME.
Radio Resource Control (RRC) signaling messages directly control the Uu interface between the UE
and eNodeB. As needed, the eNodeB will interwork RRC actions with S1 Application Protocol(S1AP)
operations and forward the S1AP message to the MME. These access stratum actions include radio
bearer management, user paging, radio mobility control, and so on.
NAS messages are carried inside of the RRC DL and UL Information Transfer messages, and passed
transparently through the eNodeB to the MME.
2010
Generic Control Message Structure Version 2 Rev 4
Generic Control Message Structure
Figure 6-5 Generic Control Message Structure
With the exception of RRC control packets, the graphic illustrates the generic structure for EPS control
packets.
Diameter, GTP-C, S1AP, and X2AP control packets are transported using an IP protocol stack. In each
case, a Type field indicates the message type. Parameters, response codes, and other information are
carried in Information Elements (IEs). Each IE contains IE Type, Length, and value fields.
2010
Version 2 Rev 4 Control Packet Transactions
Control Packet Transactions
Figure 6-6 2-way Handshake
2-way Handshake Control packets are associated into transactions. A transaction may consist of
standalone packet, a “2-way” handshake, or a “3-way” handshake. A transaction typically consists of a
“2-way” handshake with a control request and response. To help correlate the request and response in
a transaction, the response typically carries the same sequence number as the original request.
The example above shows a “2-way” handshake.
2010
3–way Control Handshake Version 2 Rev 4
3–way Control Handshake
Figure 6-7 3-way Handshake
The example above shows a “3-way” handshake. In a 3-way handshake, the response carries critical
information which must be acknowledged. The 3rd message (“ACK”) signals that the response was
received.
2010
Version 2 Rev 4 User Plane
User Plane
Figure 6-8 User Plane
A User Plane (UP) describes the protocol stack(s) required to transport bearer traffic. Bearer traffic
includes any user “data” traffic such as voice or video packets, Internet access, email, and so on. In
addition, application signaling messages are viewed as data.
Application signaling messages are viewed as data; they are

transparent to the LTE/SAE architecture. For example, voice over
IP sessions are managed using Session Initiation Protocol
(SIP). Essentially, the LTE/SAE architecture views SIP messages
as regular data.
2010
RRC Functions and Signaling Version 2 Rev 4
RRC Functions and Signaling

f
Figure 6-9 RRC Functions
The Radio Resource Control (RRC) layer sets up and manages the Uu air interface between the UE
and eNodeB, and transports Non-Access Stratum (NAS) messages between the UE and MME.
2010
Version 2 Rev 4 RRC Signaling Messages
RRC Signaling Messages

RRC Functions and Signaling Messages
RLC SRB Carried
RRC Function RRC Signaling Messages Direction
Mode Type on:
RRC RRC Connection Reconfiguration AM SRB1 eNodeB → UE DCCH
Connection
and Config RRC Connection Reconfig Complete AM SRB1 UE → eNodeB DCCH
Control RRC Connection Reestablishment TM SRB0 eNodeB → UE CCCH
RRC Connection Reestablishment AM SRB1 UE → eNodeB DCCH
Complete
RRC Connection Reestablishment TM SRB0 eNodeB → UE CCCH
Reject
RRC Connection Reestablishment TM SRB0 UE → eNodeB CCCH
Request
RRC Connection Reject TM SRB0 eNodeB → UE CCCH
RRC Connection Release AM SRB1 eNodeB → UE DCCH
RRC Connection Request TM SRB0 UE → eNodeB CCCH
RRC Connection Setup TM SRB0 eNodeB → UE CCCH
RRC Connection Setup Complete1 AM SRB1 UE → eNodeB DCCH
Broadcast of Master Information Block TM N/A eNodeB → UE BCCH
System Info
System Information TM N/A eNodeB → UE BCCH
System Information Block Type1 TM N/A eNodeB → UE BCCH
Measurement Measurement Report AM SRB1 UE → eNodeB DCCH

Config and
Reporting RRC Status AM SRB1 UE → eNodeB DCCH
NAS Signaling DL Information Transfer1 AM SRB22 eNodeB → UE DCCH

Transfer
UL Information Transfer1 AM SRB22 UE → eNodeB DCCH
Initial Security Security Mode Command AM SRB1 eNodeB → UE DCCH
Activation
Security Mode Complete AM SRB1 UE → eNodeB DCCH
Security Mode Failure AM SRB1 UE → eNodeB DCCH
RRC CDMA2000-CSFB Parameters AM SRB1 UE → eNodeB DCCH
Connection Request
Mobility and
Handovers CDMA2000-CSFB Parameters AM SRB1 eNodeB → UE DCCH
Response
Handover From EUTRA Preparation AM SRB1 eNodeB → UE DCCH
Request (CDMA2000)
Mobility From EUTRA Command AM SRB1 eNodeB → UE DCCH
UE Capability Enquiry AM SRB1 eNodeB → UE DCCH
UE Capability Information AM SRB1 UE → eNodeB DCCH
UL Handover Preparation Transfer AM SRB1 UE → eNodeB DCCH
(CDMA2000)
Paging Paging TM N/A eNodeB → UE PCCH
Note1 – This message may carry a NAS Signaling PDU
2010
RRC Signaling Messages Version 2 Rev 4
RRC Signaling Messages

Note2 – This message may use SRB1 if SRB2 is not yet established Table 6 1
3GPP TS 36.331 Radio Resource Control (RRC) Protocol

LTE Telecoms
Specification
300
2010
Version 2 Rev 4 RRC Signaling Messages and SRBs
RRC Signaling Messages and SRBs

SRB Types
Logical
SRB Type Carries:
Channel
SRB0 CCCH RRC messages
SRB1 DCCH RRC messages,
some NAS1
SRB2 DCCH NAS messages2
Note1 – SRB1 RRC message may carry a NAS message if SRB2 is not yet established
Note2 – SRB2 NAS messages are contained in RRC messages (e.g. DL/UL Information Transfer)
Signaling Radio Bearers (SRBs) are Radio Bearers used to transmit RRC and NAS (signaling)
messages. -SRB0 is for RRC messages using the common control (CCCH) logical channel, while
SRB1 and SRB2 carry RRC and NAS messages over a dedicated control (DCCH) logical channel.
SRB2 has a lower-priority than SRB1 and is always configured after security activation. Once security
is activated, all RRC messages are integrity protected and ciphered by PDCP. In addition, the UE and
MME independently perform integrity protection and ciphering for the NAS messages.
2010
S1-MME Interface Version 2 Rev 4
S1-MME Interface
Figure 6-10 S1-MME Interface
The S1-MME interface is an open logical interface that carries signaling information between an eNodeB
and the MME.
S1-MME Functions
The S1-MME interface functions are:
• UE context management
• SAE bearer management
• S1-MME and S1-U link management
• GTP-U tunnels management
• Mobility for active UEs
• Paging
• Network sharing and NAS node selection coordination
• Security, including data confidentiality, air interface encryption and key management, and data
integrity
• Service and network access, including signaling data transfer, UE tracing, and location reporting
3GPP TS 36.411 S1 Layer 1
Telecoms
3GPP TS 36.412 S1 Signaling Transport
3GPP TS 36.413 S1 Application Program (S1AP)
LTE
300
2010
Version 2 Rev 4 S1-MME Interface Control Protocol Stack
S1-MME Interface Control Protocol Stack
Figure 6-11 S1-MME Interface Control Protocol Stack
The graphic illustrates the S1-MME Interface signaling protocol stack. Any Physical Layer and Data Link
Layer are allowed. The IP version may be IPv6 and/or IPv4. In either case, the S1 endpoints must
support IP Differentiated Services (DiffServ) Code Points for QoS.
Instead of using TCP or UDP, 3GPP selected Stream Control Transmission Protocol (SCTP) at Layer
4. Essentially SCTP offers TCP-like reliability and error recovery with UDP-like throughput.
The S1 signaling state machine and messages are controlled by the S1 Application Protocol (S1AP).
The S1 Interface signaling protocol stack provides:
• Reliable transfer of S1AP messages over the S1 Interface

• Networking and routing
• Redundancy in the signaling network
• Flow control and overload protection
• In the future, this Interface may support load-sharing and dynamic S1-MME configuration
2010
S1 Application Protocol (S1AP) Version 2 Rev 4
S1 Application Protocol (S1AP)
Figure 6-12 S1AP Functions
S1AP Functions
The S1 Application Protocol (S1AP) provides the following functions:
• UE context transfer and context release

• SAE bearer management, including setting up, modifying and releasing SAE bearer channels
• Provides capability information to the UE
• Mobility Functions, including changing eNodeBs within LTE or RAN nodes between different RATs
• Paging
• S1 interface management functions, including S1 configuration and reset capability, error indication,
overload handling, and load balancing
• Transfer NAS signaling before or after the UE context is established in the eNodeB S1 UE context
release
• PDCP sequence number status transfer
2010
Version 2 Rev 4 S1AP Signaling Messages
S1AP Signaling Messages

S1AP Functions and Signaling Messages
S1AP Function S1AP Signaling Messages Direction
SAE Bearer SAE Bearer Modify Request MME → eNodeB
Management
SAE Bearer Modify Response eNodeB → MME
SAE Bearer Release Command MME → eNodeB
SAE Bearer Release Request eNodeB → MME
SAE Bearer Release Response eNodeB → MME
SAE Bearer Setup Response eNodeB → MME
SAE Bearer Setup Request MME →eNodeB
Context Management Initial Context Setup Failure eNodeB → MME
Initial Context Setup Request MME → eNodeB
Initial Context Setup Response eNodeB → MME
UE Context Modification Failure eNodeB → MME
UE Context Modification Request MME → eNodeB
UE Context Modification Response eNodeB → MME
UE Context Release Command MME → eNodeB
UE Context Release Complete eNodeB → MME
UE Context Release Request eNodeB → MME
Handover Signaling eNodeB Status Transfer eNodeB → MME
Handover Cancel eNodeB → MME
Handover Cancel ACK MME → eNodeB
Handover Command MME → eNodeB
Handover Failure eNodeB → MME
Handover Notify eNodeB → MME
Handover Preparation Failure MME → eNodeB
Handover Request MME → eNodeB
Handover Request ACK eNodeB → MME
Handover Required eNodeB → MME
MME Status Transfer MME → eNodeB
Path Switch Request eNodeB → MME
Path Switch Request ACK MME → eNodeB
Path Switch Request Failure MME → eNodeB
Paging Paging MME → eNodeB
Non-Access Stratum Downlink NAS Transport MME → eNodeB
(NAS) Transport
Initial UE Message eNodeB → MME
NAS Non Delivery Indication eNodeB → MME
Uplink NAS Transport eNodeB → MME
2010
S1AP Signaling Messages Version 2 Rev 4
S1AP Signaling Messages

S1AP Functions and Signaling Messages
S1AP Function S1AP Signaling Messages Direction
Management Messages eNodeB Configuration Update eNodeB → MME
eNodeB Configuration Update ACK MME → eNodeB
eNodeB Configuration Update Failure MME → eNodeB
Error Indication eNodeB↔MME
MME Configuration Update MME → eNodeB
MME Configuration Update ACK eNodeB↔MME
MME Configuration Update Failure eNodeB↔MME
Overload Start MME → eNodeB
Overload Stop MME → eNodeB
Reset eNodeB↔MME
Reset ACK eNodeB↔MME
S1 Setup Failure MME → eNodeB
S1 Setup Request eNodeB → MME
S1 Setup Response MME → eNodeB
S1 CDMA2000 Downlink S1 CDMA2000 Tunneling MME → eNodeB
Tunneling
UE Capability Info Indication eNodeB → MME
Uplink S1 CDMA2000 Tunneling eNodeB → MME
Trace Deactivate Trace MME → eNodeB
Trace Failure Indication eNodeB → MME
Trace Start MME → eNodeB
Location Reporting Location Report eNodeB → MME
Location Report Failure Indication eNodeB → MME
Location Reporting Control MME → eNodeB
S1AP signaling messages are generated based on state changes, X2 or Uu signaling, measured
conditions, or MME configuration changes.
3GPP TS 36.413 S1 Application Program (S1AP)

Telecoms
LTE
300
2010
Version 2 Rev 4 Non-Access Stratum Signaling
Non-Access Stratum Signaling
UE to MME Control Plane
Figure 6-13 UE to MME Control Plane
The graphic illustrates the control plane between the UE and the MME, including the air (Uu) and S1-MME
interfaces.
For Access Stratum (AS) messages, the eNodeB interworks RRC and S1AP signaling. Non-Access
Stratum (NAS) signaling is passed transparently from the UE to the MME.
2010
Non-Access Stratum (NAS) Signaling Transport Version 2 Rev 4
Non-Access Stratum (NAS) Signaling Transport
Figure 6-14 NAS Signaling Transport
The graphic lists the RRC and S1AP messages used to transport NAS signaling. The eNodeB interworks
RRC Connection Setup Complete and the S1AP Initial UE Message, RRC DL Information Transport and
S1AP DL NAS Transport, and RRC UL Information Transport and S1AP UL NAS Transport.
Although the eNodeB transfers the NAS message without interpretation, it will add any additional
Information Elements required, such as the cell identity.
In one case the eNodeB does interpret and act upon the NAS signaling. If the S1AP DL NAS Transport
message (from the MME) contains a Handover Restriction List IE, the eNodeB will store that information
in the UE context. The Handover Restriction List contains roaming area or access restrictions. The
eNodeB uses that information during a handover.
The RRC NAS transport packets are also used to carry cdma2000
signaling. The eNodeB will interwork the RRC DL/UL Information
Transfer messages with S1AP DL/UL S1 CDMA200 Tunneling
messages.
2010
Version 2 Rev 4 Non Access Stratum (NAS) Signaling Messages
Non Access Stratum (NAS) Signaling Messages

NAS EMM Signaling Messages
NAS Function NAS Signaling Messages Direction
EPS Mobility Attach Accept MME → UE
Management (EMM)
Attach Complete UE → MME
Attach Reject MME → UE
Attach Request UE → MME
Authentication Failure UE → MME
Authentication Reject MME → UE
Authentication Request MME → UE
Authentication Response UE → MME
Detach Accept MME → UE
Detach Request UE → MME
Downlink NAS Transport MME → UE
EMM Information MME ↔ UE
EMM Status MME → UE
Extended Service Request UE → MME
GUTI Reallocation Command MME → UE
GUTI Reallocation Complete UE → MME
Identity Request MME → UE
Identity Response UE → MME
NAS Circuit Switched Service Notification For Future Study
Security Mode Command MME → UE
Security Mode Complete UE → MME
Security Mode Reject UE → MME
Security Protected NAS Message MME ↔ UE
Service Reject MME → UE
Service Request UE → MME
Tracking Area Update Accept MME → UE
Tracking Area Update Complete UE → MME
Tracking Area Update Reject MME → UE
Tracking Area Update Request UE → MME
Uplink NAS Transport UE → MME
EPS Session Activate Dedicated EPS Bearer Context Accept UE → MME
Management (ESM)
Activate Dedicated EPS Bearer Context Reject UE → MME
Activate Dedicated EPS Bearer Context Request MME → UE
Activate Default EPS Bearer Context Accept UE → MME
Activate Default EPS Bearer Context Reject UE → MME
Activate Default EPS Bearer Context Request MME → UE
Bearer Resource Modification Reject MME → UE
2010
Non Access Stratum (NAS) Signaling Messages Version 2 Rev 4
Non Access Stratum (NAS) Signaling Messages

NAS EMM Signaling Messages
NAS Function NAS Signaling Messages Direction
Bearer Resource Modification Request UE → MME
Deactivate EPS Bearer Context Accept UE → MME
Deactivate EPS Bearer Context Request MME → UE
ESM Information Request MME UE ESM
Information Response UE → MME
ESM Status MME ↔ UE
Modify EPS Bearer Context Accept UE → MME
Modify EPS Bearer Context Reject UE → MME
Modify EPS Bearer Context Request MME → UE
PDN Connectivity Reject MME ↔ UE
PDN Connectivity Request UE → MME
PDN Disconnect Reject MME ↔ UE
PDN Disconnect Request UE → MME
3GPP TS 24.301 NAS Protocol for EPS

Telecoms
LTE
300
2010
Version 2 Rev 4 S1–U and S5 Interfaces
S1–U and S5 Interfaces
Figure 6-15 S1-U and S5-U Interfaces
The S1-U interface forwards user data traffic between the eNodeB and S-GW, and the S5 interface
forwards user data traffic between the S-GW and P-GW. Both interfaces support GPRS Tunneling
Protocol (GTP) for IP mobility. The EPS uses GTPv1 for user plane traffic and GTPv2 for GTP control
packets.
The S5 interface connects an S-GW and P-GW in the same PLMN.
The S8 interface is the inter-PLMN reference point providing

user and control plane between an S-GW in the Visited PLMN
(VPLMN) and a P-GW in the Home PLMN (HPLMN).
3GPP TS 29.274 Evolved GPRS Tunneling Protocol for EPS

Telecoms
(GTPv2)
3GPP TS 29.281 GPRS Tunnelling Protocol User Plane
LTE
300
(GTPv1-U)
2010
S1-U Interface User Plane Protocol Stack Version 2 Rev 4
S1-U Interface User Plane Protocol Stack
Figure 6-16 S1-U User Plane Protocol Stack
The graphic illustrates the protocol stack required to forward user data traffic over the S1-U interface.
A user data packet (Layers 3-5) is encapsulated by the GPRS Tunneling Protocol (GTP). The GTP
packet is carried by UDP/IP over any Data Link and Physical Layer. IPv4 and/or IPv6 may be supported.
GTP is the IP mobility protocol initially defined for GPRS mobile devices. Although GTP predated the
IETF Mobile IP (MIP) standards, both GTP and MIP have the same objective: mobility across an IP
–based network. They differ mainly in how the mobility tunnels are created and managed.
Each data stream is carried on a dedicated transport bearer; each transport bearer is uniquely identified
by the IP address and Tunnel Endpoint ID of the GTP tunnel.

Telecoms
(GTPv1-U)
LTE
300
2010
Version 2 Rev 4 S5-U User Plane Protocol Stack
S5-U User Plane Protocol Stack
Figure 6-17 S5 Interface User Plane Protocol Stack
The S5-U interface forwards user plane traffic between an S-GW and a P-GW. The S5-U interface uses
exactly the same protocol stack as the S1-U interface. S5 uses GTPv1 for user plane traffic and GTPv2
for GTP control packets.

Telecoms
(GTPv2)
LTE
300
(GTPv1-U)
2010
S5 Control Plane Protocol Stack Version 2 Rev 4
S5 Control Plane Protocol Stack
Figure 6-18 S5 Control Plane Protocol Stack
The graphic illustrates the S5 control plane protocol stack. The S5-CP interface carries signaling that
manages the GTP tunnels between the S-GW and P-GW. S5 uses GTPv2 for GTP-C (control) packets.

Telecoms
(GTPv2)
LTE
300
2010
Version 2 Rev 4 Selected GTP-C Message Types
Selected GTP-C Message Types

GTP-C Message Types
Message
Type Message Endpoints
(Decimal)
1 Echo Request Any
2 Echo Response Any
3 Version Not Supported Indication Any
32 Create Session Request MME to P-GW
33 Create Session Response MME to P-GW
36 Modify Bearer Request MME to P-GW
37 Modify Bearer Response MME to P-GW
38 Delete Session Request MME to P-GW
39 Delete Session Response MME to P-GW
64 Modify Bearer Command MME to P-GW
65 Modify Bearer Failure Indication P-GW to MME
66 Delete Bearer Command MME to P-GW
67 Delete Bearer Failure Indication P-GW to MME
68 Bearer Resource Command MME to P-GW
69 Bearer Resource Failure Indication P-GW to MME
70 Downlink Data Notification Failure Indication MME to S-GW
95 Create Bearer Request P-GW to MME
96 Create Bearer Response P-GW to MME
97 Update Bearer Request P-GW to MME
98 Update Bearer Response P-GW to MME
99 Delete Bearer Request P-GW to MME
100 Delete Bearer Response P-GW to MME
128 Identification Request MME to MME
129 Identification Response MME to MME
130 Context Request MME to MME
131 Context Response MME to MME
160 Create Forwarding Tunnel Request MME to S-GW
161 Create Forwarding Tunnel Response MME to S-GW
176 Downlink Data Notification S-GW to MME
177 Downlink Data Notification Acknowledgement S-GW to MME
GTP-C message types 64-70 do not have an explicit response.

Telecoms
(GTPv2)
LTE
300
2010
UE to P-GW User Plane Version 2 Rev 4
UE to P-GW User Plane
Figure 6-19 UE to P-GW User Plane
The graphic illustrates the user plane between the UE and the P-GW, including the Uu, S1-U, and S5-U
interfaces. Note that the P-GW extracts the original user traffic (Layer 3-5) from the GTP mobility tunnel.
The resulting packet may be forwarded based on the user-supplied destination IP address, or placed in
another GTP or Mobile IP tunnel and forwarded to another network. In the latter case, the P-GW will
interwork the two mobility tunnels.
2010
Version 2 Rev 4 S10 and S11 Interfaces
S10 and S11 Interfaces
Figure 6-20 S10 and S11 Interfaces
The S11 interface carries signaling that manages the GTP tunnels between the S-GW and P-GW. In
addition, the S-GW uses S11 to indicate that incoming data for a UE has arrived. The MME will page the
UE in the last reported Tracking Area or Tracking Area list. S11 uses GTPv2 for GTP-C (control) packets.
The S10 interface carries signaling between two MMEs. This interface is used when a UE moves to a
cell served by a different MME. The old MME passes UE context information to the new MME over the
S10 interface. S10 uses GTPv2 for GTP-C (control) packets.

Telecoms
(GTPv2)
LTE
300
2010
S10 Interface Control Plane Protocol Stack Version 2 Rev 4
S10 Interface Control Plane Protocol Stack
The graphic illustrates the S10 control plane protocol stack. S10 signaling uses GTP-C control
messages.

Telecoms
(GTPv2)
LTE
300
2010
Version 2 Rev 4 S11 Interface Control Plane Protocol Stack
S11 Interface Control Plane Protocol Stack
The graphic illustrates the S11 control plane protocol stack. S11 signaling uses GTP-C control messages.

Telecoms
(GTPv2)
LTE
300
2010
S6a Interface Version 2 Rev 4
S6a Interface
Figure 6-23 S6a Interface
The S6a interface carries signaling that manages the UE authentication and context between the MME
and HSS. S6a uses Diameter packets.
Based upon RADIUS, Diameter is an IETF remote access, authentication, policy, and user context
protocol. Basic Diameter architecture and operation is described in RFC 3588, and extended in many
other RFCs and 3GPP technical specifications. E-UTRAN specific extensions are described in TS
29.272.

Telecoms
IETF RFC 4740 Diameter SIP Application
IETF RFC 5224 Diameter Policy Processing Application
LTE
300
3GPP TS 29.272 MME and SGSN Related Interfaces Based on

Diameter
2010
Version 2 Rev 4 S6a Control Plane Protocol Stack
S6a Control Plane Protocol Stack
Figure 6-24 S6a Control Plane Protocol Stack
The graphic illustrates the Diameter protocol stack.

Telecoms
Diameter
LTE
300
2010
Diameter Messages for E-UTRAN Version 2 Rev 4
Diameter Messages for E-UTRAN

Diameter Messages Direction
Update-Location-Request (ULR) MME → HSS
Update-Location-Answer (ULA) HSS → MME
Authentication-Information-Request (AIR) MME → HSS
Authentication-Information-Answer (AIA) HSS → MME
Cancel-Location-Request (CLR) HSS → MME
Cancel-Location-Answer (CLA) MME → HSS
Insert-Subscriber-Data-Request (IDR) HSS → MME
Insert-Subscriber-Data-Answer (IDA) MME → HSS
Delete-Subscriber-Data-Request (DSR) HSS → MME
Delete-Subscriber-Data-Answer (DSA) MME → HSS
Purge-UE-Request (PUR) MME → HSS
Purge-UE-Answer (PUA) HSS → MME
Reset-Request (RSR) HSS → MME
Reset-Answer (RSA) MME → HSS
Notify-Request (NOR) MME → HSS
Notify-Answer (NOA) HSS → MME

Telecoms
Diameter
LTE
300
2010
Version 2 Rev 4 X2 Interface
X2 Interface
Figure 6-25 X2 Interface
The X2 interface is an open logical interface between two adjacent eNodeBs. The X2 interface carries
control (signaling) information between the eNodeBs and forwards user data traffic as needed toward an
S-GW or UE.
X2 Interface Functions
X2 interface functions are:
• Intra LTE-Access-System Mobility Support for UE in LTE_ACTIVE, including UE context transfer,

controlling user plane tunnels, and handover cancellation
• Load Management
• Inter-cell Interference Coordination
• General X2 management and error handling functions
• Trace functions
• Forward user data traffic as needed
Telecoms
(GTPv2)
LTE
300
(GTPv1-U)
3GPP TS 36.420 X2 General Aspects and Principles
3GPP TS 36.421 X2 Layer 1
3GPP TS 36.422 X2 Signaling Transport
3GPP TS 36.423 X2 Application Program (X2AP)
3GPP TS 36.424 X2 Data Transport
2010
X2 Control Plane Protocol Stack Version 2 Rev 4
X2 Control Plane Protocol Stack
Figure 6-26 X2 Control Plane Protocol Stack
The graphic illustrates the X2 Interface signaling protocol stack. Any Physical Layer and Data Link Layer
are allowed. The IP version may be IPv6 and/or IPv4. In either case, the X2 (eNodeB) endpoints must
support Differentiated Services (DiffServ) Code Points for QoS.
Instead of using TCP or UDP, 3GPP selected Stream Control Transmission Protocol (SCTP) at Layer
4. Essentially SCTP offers TCP-like reliability and error recovery with UDP-like throughput. In addition,
SCTP supports multi-homing for redundancy and continued operation even during a transport network
failure.
The X2 signaling messages and state machine are controlled by the X2 Application Protocol (X2AP).
The X2 Interface signaling protocol stack provides:
• Reliable transfer of X2AP messages over the X2 Interface

• Networking and routing
• Redundancy in the signaling network
• Flow control and overload protection
2010
Version 2 Rev 4 X2 Application Protocol (X2AP)
X2 Application Protocol (X2AP)
Figure 6-27 X2AP Functions
X2AP Functions
The X2 Application Protocol (X2AP) provides the following functions:
• Mobility management – Allows the eNodeB to move the responsibility for a UE to another eNodeB.
Mobility management includes forwarding of user plane data, Status Transfer and UE Context
Release.
• Load management – Indicates resource status, overload, and traffic load to an adjacent eNodeB.
• Reporting general error situations – Reports general error situations, for which function- specific
error messages have not been defined.
• Resetting the X2 – Completely resets the X2 interface.
• Setting up the X2 – Exchanges necessary data for the eNodeB to setup the X2 interface.
• eNodeB configuration update – Updates application level data needed for two eNodeBs to
interoperate correctly over the X2 interface.
2010
X2AP Signaling Messages Version 2 Rev 4
X2AP Signaling Messages

X2AP Functions and X2AP Signaling Messages
X2AP Function X2AP Signaling Messages
Mobility Management Handover Request
Handover Request ACK
Handover Preparation Failure
Handover Cancel
SN Status Transfer
UE Context Release
Load Management Load Information
Resource Status Request
Resource Status Response
Resource Status Failure
Resource Status Update
Reporting General Error Indication Resetting the X2
Error Situations
Reset Request
Reset Response
Setting up the X2 X2 Setup Request
X2 Setup Response
X2 Setup Failure
eNodeB Configuration eNodeB Configuration Update
Update
eNodeB Configuration Update ACK
eNodeB Configuration Update Failure
X2AP signaling messages are generated based on state changes, S1 or Uu signaling, measured
conditions, or eNodeB configuration changes.
3GPP TS 36.423 X2 Application Program (X2AP)

Telecoms
LTE
300
2010
Version 2 Rev 4 X2 User Plane Protocol Stack
X2 User Plane Protocol Stack
Figure 6-28 X2 User Plane Protocol Stack
The graphic illustrates the protocol stack required to forward user data traffic over the X2 interface. A
data packet is encapsulated by the GPRS Tunneling Protocol (GTP). The GTP packet is carried by
UDP/IP over any Data Link and Physical Layer. IPv4 and/or IPv6 may be supported.
Each data stream is carried on a dedicated transport bearer; each transport bearer is uniquely identified
by the IP address and Tunnel Endpoint ID (TEID) of the GTP tunnel.

Telecoms
(GTPv1-U)
LTE
300
2010
Mobility and X2 Data Transport Version 2 Rev 4
Mobility and X2 Data Transport
Figure 6-29 Mobility and X2 Data Transport – 1
Why do we need X2 data transport? The X2 user plane allows side-haul of user traffic during a handover
between two eNodeBs.
Step
1 The GTP mobility tunnel for a UE is initially anchored at a source or

originating eNodeB (eNB1 in our example).
2 After measuring the service available from the neighbor eNodeBs, the UE
signals a handover to eNB2. The source and target eNodeBs perform the
handover, and notify the MME of the operation.
3 The original mobility tunnel persists until the user’s mobility tunnel can be
anchored at eNB2. A “side-haul” tunnel is set up between eNodeB1 and
eNodeB2 to forward incoming data traffic to the user.

Telecoms
LTE
300
2010
Version 2 Rev 4 Mobility and X2 Data Transport
Mobility and X2 Data Transport

Figure 6-30 Mobility and X2 Data Transport – 1
Step
4 The MME instructs the S-GW to reconfigure the mobility tunnel for UE1,
anchoring the tunnel at eNodeB2. After forwarding any remaining traffic
between eNodeB1 and eNodeB2, the previous tunnel between the S-GW
and eNodeB1 is deleted. The handover operation is now complete.
2010
Subscriber and Network Element Identities Version 2 Rev 4
Subscriber and Network Element Identities
PLMN IDs
Figure 6-31 PLMN ID
The Public Land Mobile Network (PLMN) is the mobile service provider. The PLMN ID consists of the
3-digit Mobile Country Code (MCC) and the 2- or 3-digit Mobile Network Code (MNC).
The MCC uniquely identifies the country a mobile carrier operates in, while the MNC uniquely identifies
a mobile carrier within a country. MCC and MNC use 4-bit binary coded decimal digits.
MCCs and PLMN IDs are defined in the ITU E.212 standard.
ITU E.212 Land Mobile Numbering Plan

Telecoms
3GPP TS 23.003 Numbering, Addressing and Identification
LTE
300
2010
Version 2 Rev 4 Subscriber and Network Element Identities

MME Identities
Figure 6-32 MME IDs
In EPS, an MME is assigned the following IDs.
• MME Group ID (MMEGI) – 16-bit value assigned by the carrier to uniquely identify the MME group.
• MME Code (MMEC) – 8-bit value assigned to a specific MME within a group.
• Globally Unique MME ID (GUMMEI) – Uniquely identifies a specific MME within the PLMN. The
GUMMI consists of the MCC, MNC, MME Group ID (MMEGI), and MME Code (MMEC).
Telecoms
LTE
300
2010
Subscriber and Network Element Identities Version 2 Rev 4

Subscriber IDs
Figure 6-33 Subscriber IDs
In EPS, a subscriber is assigned the following IDs.
• International Mobile Subscriber ID (IMSI) – 14 or 15 decimal digits assigned by the home mobile
network to uniquely identify the subscriber. The IMSI consists of the MCC, MNC, and the subscriber
ID.
• International Mobile Equipment ID (IMEI) – 14 decimal digits assigned by the manufacturer to
uniquely identify the type of mobile device. The 16 digit IMEI/SVN includes the Software Version
Number (SVN).
• Cell Radio Network Temporary ID (C-RNTI) – 16-bit value assigned by the eNodeB for scheduling
air interface resources.
• Mobile Temporary Mobile Subscriber ID (M-TMSI) – 32-bit value assigned by the MME for paging
the UE.
• Globally Unique Temporary ID (GUTI) – Uniquely identifies an M-TMSI within the PLMN. The
GUTI consists of the GUMMEI and the M-TMSI (80 bits).
• Subscriber Temporary Mobile Subscriber ID (S-TMSI) – A smaller version of the GUTI used for
paging the UE. The S-TMSI consists of the MMEC plus the M-TMSI (40 bits).
ITU E.212 Land Mobile Numbering Plan 3GPP TS 23.003
Telecoms
Numbering, Addressing and Identification
LTE
300
2010
Version 2 Rev 4 Subscriber and Network Element Identities
Selected EPS IDs
Selected EPS IDs

Associated ID
ID Name Assigned by Length
with: includes:
PLMN (Public Land Mobile National regulatory Carrier MCC, MNC 24 bits
Network) ID agency Network
MMEGI (MME Group ID) Carrier MME 16 bits
MMEC (MME Code) Carrier MME 8 bits
GUMMEI (Globally Unique Carrier MME MCC, 48 bits
MME ID) MNC,
MMEGI,
MMEC
M-TMSI (Mobile Temporary MME UE/MME 32 bits
Mobile Subscriber ID)
GUTI (Globally Unique MME UE/MME MCC, 80 bits
Temporary ID) MNC,
MMEGI,
MMEC,
M-TMSI
S-TMSI (S. Temporary Mobile MME UE/MME MMEC, 40 bits
Subscriber ID) M-TMSI
TEID (Tunnel Endpoint ID) S-GW, P-GW, eNodeB UE Bearer 32 bits
Flow
IPv4 Address Carrier/Dynamically by Each Network 32 bits
P-GW Element
IPv6 Address Carrier/Dynamically by Each Network 128 bits
P-GW Element

Telecoms
LTE
300
2010
Lesson Summary Version 2 Rev 4
Lesson Summary
• EPS interface functions

• User and Control Plane protocol stacks
• RRC, S1AP, NAS, Diameter, and X2AP signaling messages
• Subscriber and network element IDs
2010
Memory Points
2010
UE States and LTE/SAE Signaling Version 2 Rev 4
Chapter 7
UE States and LTE/SAE Signaling
2010
Version 2 Rev 4 UE States and LTE/SAE Signaling
2010
Objectives
• List the UE Mobility Management and Session Management states

• Describe the UE network acquisition process
• Describe “typical” UE call processes
• Describe the UE authentication process
2010
Version 2 Rev 4 Radio Resource Control (RRC) States
Radio Resource Control (RRC) States

Let’s look at the UE’s Radio Resource Control (RRC) states. Before the UE can do anything, a RRC
connection must be established between the UE and E-UTRAN.
Figure 7-2 RRC and MM States
Radio Resource Control (RRC) – Idle

The UE is considered RRC_IDLE once it obtains the center frequency, reads the timing information,
syncs to the eNodeB, and is ready to receive system broadcast information. At this point the UE has no
signaling connection to the eNodeB. From the RRC_IDLE state the UE must perform:
• System acquisition
• Receive and respond to paging
• Tracking Area Update
• Cell re-selection as needed
Radio Resource Control (RRC) – Connect

In order to register with the EPC, the UE must set-up RRC signaling with the eNodeB. This is the
RRC_CONNECT state. From the RRC_CONNECT state the UE must perform:
• System acquisition
• Monitor DL control channels
• Send Channel Quality Information as directed by the eNodeB
• Handover
Telecoms
LTE
300
2010
Radio Resource Control (RRC) States Version 2 Rev 4
Radio Resource Control (RRC) States

Radio Resource Control (RRC) Connection
Figure 7-3 RRC Connection
RRC Connection is a logical connection between E-UTRAN and UE used to carry all UE to eNodeB or
MME (NAS) signaling, UE location tracking, UE “state” tracking, and establish a temporary identity for
the UE (C-RNTI).
After the RRC connection is set up the UE is “known” to the eNodeB, and the UE is in RRC_CONNECT
state.
2010
Version 2 Rev 4 EPS Mobility Management (EMM) States
EPS Mobility Management (EMM) States
Figure 7-4 EPS Mobility Management States
EPS Mobility Management (EMM) – Deregistered

In the EMM_DEREGISTERED state, the MME is not aware of the UE. It has no valid location or routing
information for the UE.
EPS Mobility Management (EMM) – Registered

The UE enters the EMM_REGISTERED state by a successful registration with an Attach procedure. In
the EMM_REGISTERED state, the UE can receive services that require registration in the EPS.
3GPP TS 23.401 GPRS Enhancements for E-UTRAN Access

Telecoms
LTE
300
2010
EPS Connection Management (ECM) States Version 2 Rev 4
EPS Connection Management (ECM) States
Figure 7-5 EPS Connection Management States
EPS Connection Management (ECM) – Idle

A UE is in ECM_IDLE state when no NAS signaling connection exists between the UE and MME. In
ECM_IDLE state, a UE performs cell selection/reselection. The UE location is known in the MME with
an accuracy of a Tracking Area.
EPS Connection Management (ECM) – Connect

In the ECM_CONNECT state, a (NAS) signaling connection exists between the UE and the MME. The
UE location is known in the MME with an accuracy of a serving Cell ID. UE mobility is handled by the
handover procedure.

Telecoms
LTE
300
2010
Version 2 Rev 4 EPS Session Management (ESM)
EPS Session Management (ESM)
Figure 7-6 EPS Session Management (ESM)
The LTE standards also describe the EPS Session Management states: ESM_INACTIVE and
ESM_ACTIVE.
ESM_INACTIVE
In this state, the UE has no default or dedicated bearers associated with it.
ESM_ACTIVE
In this state, the UE has at least one (1) bearer associated with it. Since the UE must be registered
before establishing a bearer, a UE in ESM_ACTIVE state will also be in EMM_REGISTERED state.
Data transfer may occur if the UE is in ECM_CONNECT state.
The PDN context includes information distributed across many

EPS network elements. We will discuss the context information in
each network element over the next few pages.

Telecoms
LTE
300
2010
Non Access Stratum (NAS) States Version 2 Rev 4
Non Access Stratum (NAS) States

The NAS state model combines EPS Mobility Management (EMM), EPS Connection Management
(ECM) and EPS Session Management (ESM) states as shown in the table below.
Figure 7-7 NAS States

Registra on
Service Request
TA update, paging, etc.
EMM-Deregistered, EMM-Registered, EMM-Registered,

ECM-Idle and ESM- ECM-Idle and ESM- ECM-Connected and
Inac ve Ac ve ESM-Ac ve
RRC: Null RRC: IDLE RRC: CONNECTED
No RRC or EPC Context EPC Context RRC & EPC Context

Power On
S-TMSI, TA-ID, IP S-TMSI, TA-ID, IP
IMSI Iden fier
Address Address
UE Unknown UE Known at TA Level UE Known at Cell Level
PLMN Selec on TA Update Handovers
No Data Transfer DRXon DL UL/ DL Data Transfer
Periodic TA update Inac vity

Timeout – out of area
Deregistra on
EMM_DEREGISTERED, ECM_IDLE and ESM_INACTIVE

In this state, the UE is not known by the network. The UE will use the Attach Procedure to
become registered (known) by the network. A registration process moves a UE from this state to
EMM_REGISTERED, ECM_CONNECT and ESM_ACTIVE.
EMM_REGISTERED, ECM_IDLE and ESM_ACTIVE

In this state, the UE has registered with the network. Its location in the network is known to the Tracking
Area (TA) level. An IP Address will also have been issued to the UE to move the UE into ESM_ACTIVE
state. The UE will also be able to perform cell reselections. An TAU timeout moves a UE from this state to
EMM_DEREGISTERED, ECM_IDLE and ESM_INACTIVE. A deregistration process moves a UE from
this state to EMM_DEREGISTERED, ECM_IDLE and ESM_INACTIVE.
EMM_REGISTERED, ECM_CONNECT and ESM_ACTIVE

In this state, the UE is able to send and receive data. Its location is known to the serving eNodeB ID.
The mobility of UE is handled by the handover procedure. An inactivity timeout moves a UE from this
state to EMM_REGISTERED, ECM_IDLE and ESM_INACTIVE. A deregistration process moves a UE
from this state to EMM_DEREGISTERED, ECM_IDLE and ESM_INACTIVE.

Telecoms
LTE
300
2010
Version 2 Rev 4 Context Information in the HSS
Context Information in the HSS
Figure 7-8 HSS Context Information
Selected Context Information in the HSS

General UE Context Information PDN Subscription Request
IMSI Context Identifier
MSISDN (Telephone Number) IP Address(es)
IMEI / IMEI-SV Access Point Name (APN)
Serving MME Address EPS Subscribed QoS profile
MME Capabilities Subscribed-APN-Bandwidth
Operator Determined Barring EPS Bearer Context Charging
status Characteristics
Access Restriction Visited PLMN P-GW allowed?
EPS Subscribed Charging P-GW Identity
Characteristics
Trace Information
Subscribed-UE-non GBR
Bandwidth
APN-Domain Name

Telecoms
LTE
300
2010
Context Information in the P-GW Version 2 Rev 4
Context Information in the P-GW
Figure 7-9 P-GW Context Information
Selected Context Information in the P-GW

General UE Context Information EPS Bearer
IMSI EPS Bearer ID
MSISDN S-GW Address in use (User
Plane)
Selected Core Network ID S-GW TEID for S5/S8 (User
Plane)
APN in use P-GW IP Address for S5/S8 (User
Plane)
Charging Information P-GW TEID for S5/S8 (User
Plane)
RAT Type EPS Bearer QoS
UE IP Address(es) Charging Information
S-GW Address in use (Control Plane)

S-GW TEID for S5/S8 (Control Plane)
S-GW TEID for S5/S8 (Control Plane)
P-GW IP Address for S5/S8 (Control
Plane)
P-GW TEID for S5/S8 (Control Plane)
2010
Version 2 Rev 4 Context Information in the UE
Context Information in the UE
Figure 7-10 UE Context Information
Selected Context Information in the UE

General UE Context EPS Bearer within PDN
PDN Subscription Context
Information Connection
IMSI IP Address(es) EPS Bearer ID
IMEI / IMEI-SV Access Point Name (APN) Transaction ID
Mobility Management State Bandwidth for Non-GBR EPS Bearer QoS
Bearers
GUTI EPS Bearer ID for Default UL Traffic Flow Template
Bearer
Tracking Area List
Last Visited Tracking Area ID
UE – specific DRX
Parameters
Security Parameters

Telecoms
LTE
300
2010
Context Information in the MME Version 2 Rev 4
Context Information in the MME
Figure 7-11
Selected Context information in the MME

General UE Context Information Active PDN Connection
IMSI, IMEI/IMEI-SV UE IP Address(es)
Mobility Management State APN in use and subscribed
GUTI Bandwidth for Non-GBR Bearers
Tracking Area List Bearer info for Default Bearer
Last Reported Tracking Area ID P-GW info for S5/S8 (Control Plane)
Security Parameters EPS Bearer within PDN Connection
Selected Core Network ID EPS Bearer ID
MME/S-GW info for S11 (CP) Transaction ID
eNodeB/MME UE S1AP IDs EPS Bearer QoS

eNodeB Address in use S-GW info for S1-U (User Plane)
E-UTRAN Cell Global ID (ECGI) S-GW/P-GW info for S5/S8 (User Plane)
Charging Information Charging Information
2010
Version 2 Rev 4 Context Information in the S-GW
Context Information in the S-GW
Figure 7-12 S-GW Context Information
Selected Context information in the S-GW

General UE Context Information EPS Bearer
IMSI EPS Bearer ID
MSISDN P-GW Address in use (User Plane)
Selected Core Network ID S-GW IP Address for S5/S8 (User Plane)
MME IP Address for S11 (Control S-GW TEID for S5/S8 (User Plane)
Plane)
MME TEID for S11 (Control Plane) P-GW IP Address for S5/S8 (User Plane)
S-GW IP Address for S11 (Control P-GW TEID for S5/S8 (User Plane)
Plane)
S-GW TEID for S11 (Control Plane) S-GW IP Address for S1-U (User Plane)
APN in use S-GW TEID for S1-U(User Plane)
P-GW Address in use (Control eNodeB IP Address for S1-U (User

Plane) Plane)
S-GW IP Address for S5/S8 eNodeB TEID for S1-U(User Plane)
(Control Plane)
S-GW TEID for S5/S8 (Control EPS Bearer QoS
Plane)
APN Restriction Charging Information

Telecoms
LTE
300
2010
Basic LTE Procedures Version 2 Rev 4
Basic LTE Procedures
Figure 7-13 Basic Procedures
We will discuss five (5) basic procedures:
• Attach
• Service Requests
• Tracking Area Update (discussed in Lesson 8)
• Handover (discussed in Lesson 8)
• Detach
2010
Version 2 Rev 4 Attaching to the Network
Attaching to the Network
Figure 7-14 Attaching to the Network
In order to send and receive data, the UE has to attach to both the E-UTRAN and the EPC.
Attaching to the E-UTRAN synchronizes the UE to the eNodeB allowing the UE to receive system
broadcast information to continue with the network attachment process.
Attaching to the EPC provides the UE with an IP address, sets-up QoS, and establishes bearer service.
Here is a simplified view of the Network Attach process we will be discussing in this lesson.
Attach – synchronizes UE to eNodeB and allows the UE to receive system broadcast information to
continue with the network attachment process.
Authenticate – UE is authenticated on the system.
MME Registration – UE is “assigned” to and registered on an MME.
P-GW Select – a P-GW is assigned. An IP address for the UE is also assigned during this step.
MME / S-GW Accept – the MME and S-GW “accept” the QoS parameters, bearers, and other system
information that was negotiated during the attach process and passes this information to the UE.
UE Ack Network Attach – UE acknowledges the MME / S-GW accept and attaches to the LTE Network.
2010
NodeB Acquisition Version 2 Rev 4
NodeB Acquisition
Figure 7-15 NodeB Acquisition
When the UE powers-up, it looks for and acquires the RF center frequency. Once it obtains the center
frequency, it reads the timing information and syncs to the eNodeB. With the UE synchronized to the
eNodeB, it can receive system broadcast information. The UE is now considered in the RRC_IDLE
state.
2010
Version 2 Rev 4 System Information (SI)
System Information (SI)
Figure 7-16 System Information (SI)
System information is broadcast in System Information (SI) Radio Resource Control (RRC)
messages. The SI-M carries the Master Information Block (MIB). It is transmitted on the BCH/PBCH
and contains:
• DL system bandwidth
• Number of transmit antennas
• Reference signal transmit power
• System frame number
The SI-1 carries the System Information Block Type 1 (SIB Type 1). It is transmitted on the
DL-SCH/PDSCH and contains:
• PLMN identity
• Tracking Area code
• Cell identity
• Cell barring status
• Other SIB scheduling and mapping information
2010
System Information (SI) Version 2 Rev 4
System Information (SI)

System Information Blocks 1-11 are transmitted on the PDSCH. The MAC PDU indicates a C-RNTI value
of hexadecimal FFFF for System Information.
System Information Blocks

SIB Type Use
SIB1 Carries PLMN ID, Tracking Area ID, Cell ID. cell barring status, etc.
SIB1 is transmitted every 80 ms and indicates the transmission interval
for other recurring SIB types.
SIB2 Carries common and shared channel information.
SIB3 Carries cell reselection information, mainly related to the serving cell.
SIB4 Carries information about the serving neighboring frequencies and
intra-frequency neighboring cells relevant for cell re-selection, covering
both E UTRA and other RATs.
SIB5 Carries information about other E UTRA frequencies and inter-frequency
SIB6 Carries information about UTRA frequencies and UTRA neighboring
SIB7 Carries information about GERAN frequencies and GERAN neighboring
SIB8 Carries information about cdma2000 frequencies and cdma2000
SIB9 Carries the identifier of the home eNodeB.
SIB10 Carries Earthquake and Tsunami Warning System (ETWS) primary
notification, including security information.
SIB11 Carries ETWS secondary notification; supports additional segments of
ETWS information.
SIB4-SIB8 messages carry cell reselection parameters for

EUTRAN and other Radio Access Technology (RAT) neighbors,
such as GSM, UTRA, and cdma2000.

Telecoms
LTE
300
2010
Version 2 Rev 4 Cell Selection
Cell Selection
Figure 7-17 Cell and UE Service Levels
Cell Service Types

Each cell supports one of the following service levels.
• Suitable Cell – a cell on which the UE may obtain normal service

• Acceptable Cell – a cell on which the UE may obtain limited service (originate emergency calls)
• Barred and Reserved Cells – a cell is barred or reserved if indicated in SIB1
UE Service Levels
What type of service does the UE require? The levels of service defined for the UE are:
• Normal service (for public use on a suitable cell)

• Limited service (emergency calls on an acceptable cell)
• Operator service (for operators only on a reserved cell)
2010
Cell Selection Version 2 Rev 4
Cell Selection
Figure 7-18 Initial Cell Selection
Based on information received in System Information messages, the UE searches the frequency bands
to find a suitable cell. A suitable cell is one that meets cell selection criteria and is not barred or reserved.
Once it finds a suitable cell, it camps on the cell and continues with the EPC attach procedure.
Cell Selection Techniques

There are two cell selection procedures:
• Stored Information Cell Selection – Requires stored information of carrier frequencies and
optionally cell parameters from previously received measurement control information elements or
from previously detected cells. If a suitable cell is found, the UE selects it. If no suitable cell is
found, the UE starts the Initial Cell Selection procedure.
• Initial Cell Selection – Requires no knowledge of which RF channels are E-UTRA carriers. The
UE scans all RF channels in the E-UTRA bands. On each carrier frequency, the UE searches for
the strongest cell. If a suitable cell is found, that cell is selected.
2010
Version 2 Rev 4 Network Attach Procedure
Network Attach Procedure
Procedure Starting Point
Figure 7-19 Procedure Starting Point
The graphic shows what each network element knows about the UE at the beginning of this procedure.

Telecoms
LTE
300
2010
Network Attach Procedure Version 2 Rev 4

Procedure Ending Point
Figure 7-20 Procedure Ending Point
The graphic shows what each network element knows about the UE at the end of this procedure.
Network Attach Steps
Figure 7-21 Network Attach Procedure – 1
2010

The diagram above illustrates UE Initial Access from an RRC-IDLE state.
Step
1 UE sends a Random Access Preamble on the PRACH.
2 eNodeB sends a Random Access Response on PDSCH. The
RAR contains the RA Preamble code, temporary C-RNTI,
timing advance, and an initial UL grant.
3 UE sends an RRC Connection Request to eNodeB on the
PUSCH.
4 eNodeB sends an RRC Connection Setup request on the
PDSCH.
5 UE sends an RRC Connection Setup Complete containing
a NAS Attach Request to eNodeB on PUSCH. The Attach
Request contains IMSI, UE Network Capability, PDN Type,
Protocol Configuration Options, and the selected network
Step
6 The eNodeB sends an S1AP INITIAL UE MESSAGE containing a NAS
Attach Request to the MME. Attach Request contains the Selected
Network, and Tracking Area Identity and E-UTRAN Global Cell Identity
(TAI+ECGI) of the cell from where it received the message to the MME.
7 The MME and UE will perform an authentication handshake. Initial
authentication key information is stored in the UE and HSS.
8 The MME selects the S-GW and sends a GTP-C CREATE DEFAULT
BEARER REQUEST (IMSI, MME IP and TEID for S11, P-GW IP, EPS
Bearer ID, AMBR, QoS).
2010
Network Attach Procedure Version 2 Rev 4

Step
9 The S-GW forwards the CREATE DEFAULT BEARER REQUEST to the
P-GW (IMSI, S-GW S5 IP and TEID, APN, EPS Bearer ID, AMBR, QoS,
PDN address request.
10 After assigning the UE IP address, the P-GW forwards the CREATE
DEFAULT BEARER REQUEST to the PCRF. The CREATE DEFAULT
BEARER REQUEST includes IMSI, User Location Information (ECGI),
Serving Network, RAT type, APN-AMBR, Default Bearer QoS.
Step
11 The PCRF forwards the CREATE DEFAULT BEARER RESPONSE to the
P-GW. The CREATE DEFAULT BEARER RESPONSE includes the EPS
Bearer ID, User IP address, UL Traffic Filter.
12 The P-GW forwards the CREATE DEFAULT BEARER RESPONSE to the
S-GW. The CREATE DEFAULT BEARER RESPONSE includes the Cause
code, S5 P-GW IP address and TEID, EPS Bearer ID, User IP address,
UL Traffic Filter.
13 The S-GW forwards the CREATE DEFAULT BEARER RESPONSE to the
MME. The CREATE DEFAULT BEARER RESPONSE includes the S11
S-GW IP address and TEID, S1U S-GW IP address and TEID, S5 P-GW
IP address and TEID, EPS Bearer ID, User IP address, UL Traffic Filter.
14 The MME forwards the INITIAL CONTEXT SETUP REQUEST to the
eNodeB. This message the MME S1AP UE ID, UE capabilities, security
context, AMBR, QoS, S-GW IP address and TEID, S1U S-GW IP address
and TEID, S5 P-GW IP address and TEID
15 The RRC RECONFIG configures Data Radio Bearer PDCP/RLC/MAC/PHY
parameters, and measurement configurations.
2010

Figure 7-24 Network Attach 4
Step
16 The RRC RECONFIG COMPLETE confirms that the RRC Connection
Reconfiguration has been completed.
17 The INITIAL CONTEXT SETUP RESP carries the eNodeB & MME S1AP
UE ID, eNodeB IP & TEID (S1-U), EPS Bearer ID.
18 The UE sends the NAS Attach Complete message (EPS Bearer Identity,
NAS sequence number, NAS-MAC).
19 The eNodeB forwards the NAS Attach Complete message to the new MME
in an Uplink NAS Transport message. After the Attach Accept message
and once the UE has obtained a PDN Address, the UE can then send
uplink packets towards the eNodeB which will then be tunneled to the
S-GW and P-GW.
20 The MME sends an UPDATE BEARER REQ to the S-GW (eNodeB IP &
TEID, EPS Bearer ID).
21 The S-GW returns an UPDATE BEARER RESP. - Includes Cause, EPS
Bearer ID.
2010
UE Service Request Version 2 Rev 4
UE Service Request
Figure 7-25 UE Service Request 1
The diagram above illustrates UE Service Request Procedure.
Step
1 The UE sends NAS SERVICE REQUEST (S-TMSI) message
toward the MME encapsulated in an RRC message to the
eNodeB.
2 The eNodeB forwards the NAS message to the MME. The NAS
message is encapsulated in an S1-AP: INITIAL UE MESSAGE
(NAS message, TAI+ECGI of the serving cell).
3 If needed, UE authentication may be performed.
4 The MME sends S1-AP INITIAL CONTEXT SETUP REQUEST
(S-GW address, S1-TEID(s) (UL), Bearer QoS(s), Security
Context, MME Signaling Connection Id, Handover Restriction
List) to the eNodeB. This step activates the radio and S1
bearers for all the active EPS Bearers. The eNodeB stores the
Security Context, MME Signaling Connection Id, Bearer QoS
profile(s) and S1-TEID(s).
5 The eNodeB performs the radio bearer establishment
procedure. When the user plane radio bearers are setup
the Service Request is complete and EPS bearer state is
synchronized between the UE and the network.

Telecoms
LTE
300
2010
Version 2 Rev 4 UE Service Request
UE Service Request
Figure 7-26 UE Service Request 2
Step
6 The uplink data from the UE can now be forwarded by eNodeB
to the Serving GW. The eNodeB sends the uplink data to the
S-GW address and TEID provided in the step 4.
7 The eNodeB sends an S1-AP message INITIAL CONTEXT
SETUP COMPLETE (eNodeB address, list of accepted EPS
bearers, list of rejected EPS bearers, S1 TEID(s) (DL)) to the
MME.
8 The MME sends an UPDATE BEARER REQUEST (eNodeB
address, S1 TEID(s) (DL) for the accepted EPS bearers, Delay
Downlink Packet Notification Request, RAT Type) to the S-GW.
If any downlink data is available for the UE, the S-GW is now
able to transmit downlink data towards the UE.
9 If the Radio Access Technology (RAT) Type has changed
compared to the last reported RAT Type, the S-GW will send
UPDATE BEARER REQUEST (RAT Type) to the P-GW.
10 The P-GW sends the UPDATE BEARER RESPONSE to the
S-GW.
11 The S-GW sends an UPDATE BEARER RESPONSE to the
MME.
2010
Network Triggered Service Request Version 2 Rev 4
Network Triggered Service Request
Figure 7-27 Network Triggered Service Request 1
The diagram above illustrates Network Triggered Service Request Procedure.
Step
1 When the S-GW receives data for a UE, it buffers the data and
identifies which MME is serving the UE.
2 The S-GW sends a DOWNLINK DATA NOTIFICATION
message to the MME which has control plane connectivity for
the given UE.
3 The MME responds to the S-GW with a DOWNLINK DATA
NOTIFICATION ACK message.
4 If the UE is registered in the MME, the MME sends a PAGING
message (NAS Paging ID, TAI(s), and Paging DRX ID) to each
eNodeB belonging to the Tracking Area(s) in which the UE is
registered
5 The eNodeBs (in the specified Tracking Area(s)), receive the
PAGING messages from the MME and page the UE.
2010
Version 2 Rev 4 Network Triggered Service Request
Network Triggered Service Request

Step
6 When the PAGING message is received by the UE, it sends a
PAGING RESPONSE back to the eNodeB and initiates the UE
Triggered Service Request procedure we just discussed.
7 The S-GW sends a STOP PAGING message to the MME.
8 The buffered data is sent towards the UE.

Telecoms
LTE
300
2010
UE Triggered Detach Version 2 Rev 4
UE Triggered Detach
Figure 7-28 UE Triggered Detach 1
The diagram above illustrates UE Triggered Detach Procedure.
Step
1 The UE sends NAS message DETACH REQUEST (GUTI,
Switch Off) to the MME. This NAS message is used to trigger
the establishment of the S1 connection if the UE is in ECM-IDLE
mode. Switch Off indicates whether detach is due to a switch off
situation or not. The eNodeB forwards this NAS message to the
MME along with the TAI+ECGI of the cell which the UE is using.
2 The active EPS Bearers in the S-GW for the UE are deactivated
by the MME sending DELETE BEARER REQUEST (TEID)
to the S-GW.
3 The S-GW acknowledges the DELETE BEARER REQUEST
with a DELETE BEARER RESPONSE (TEID).
4 The S-GW sends DELETE BEARER REQUEST (TEID) to the
P-GW.
5 The P-GW acknowledges with DELETE BEARER RESPONSE
(TEID).
2010
Version 2 Rev 4 UE Triggered Detach
UE Triggered Detach
Step
6 The P-GW sends a message to the PCRF indicating that the
EPS Bearer is released.
7 If Switch Off indicates that detach is not due to a switch off
situation, the MME sends a DETACH ACCEPT to the UE.
8 The MME releases the S1-MME signaling connection for the
UE by sending S1 RELEASE Command to the eNodeB with
Cause = Detach.

Telecoms
LTE
300
2010
Version 2 Rev 4 UE Triggered Detach
2010
Version 2 Rev 4 Security in LTE
Security in LTE
Figure 7-29 Security in LTE
Let’s take a brief look at the user security methods employed in LTE.
User data and RRC signaling between the UE and the eNodeB is protected by ciphering and integrity
methods. The security keys used are forwarded to the eNodeB by the MME to the eNodeB after the
Universal Subscriber Identity Module (USIM) and the MME have been authenticated. NAS signaling is
also cipher and integrity protected between the UE and MME using separate keys.
There are three types of security protections employed within the EPS:
• Ciphering –protects data from being “overheard.” This applies to user data as well as signaling
messages.
• Integrity –ensures that the receiving network element is able to verify that the signaling data has
not been modified since it was transmitted by the sending network element.
• Mutual Authentication – confirms the UE’s identity to the network, and the network’s identity to
the UE.
LTE Security Keys
Figure 7-30 LTE Security Keys
2010
Security in LTE Version 2 Rev 4
Security in LTE
The 3GPP LTE standard introduces new security keys to ensure the correct protection is applied for the
different information flows.
K – secret key permanently stored in the USIM and the HSS.
CK, IK – Ciphering Key and Integrity Key computed in the UE and HSS.
KASME (Access Security Management Entity) – derived by the UE and HSS from CK and IK during the
Authentication process. KASME is responsible for establishing and maintaining security associations with
UEs based on keys received from the HSS. In LTE, the ASME function is provided by the MME.
KeNB – derived by UE and MME from KASME and is used by the eNodeB to derive the keys for RRC and
User Plane traffic.
Using those keys, the other keys are produced to ensure integrity and privacy of:
• NAS signaling between the UE and MME
• AS (Access Stratum) signaling between the UE and eNodeB
• User Plane data between UE and S-GW.
Function of LTE Security Keys
Figure 7-31 Function of LTE Security Keys
The function of each security key is depicted in the diagram above.
Authentication and Key Agreement Process (AKA)

LTE and UMTS use the same Authentication and Key Agreement Process (AKA) process. The AKA
procedure uses the following keys:
• RAND – Random Challenge parameter used to generate the other four parameters in the vector
(XRES, AUTN, CK, IK below)
• XRES – Expected Result used by the network to Universal Subscriber Identity Module (USIM)
authentication
• AUTN – Authentication Token used by the USIM for network authentication
• CK – Ciphering Key
• IK – Integrity Key
• KASME — Key Access Security Management Entity
• KSIASME Key Set Identifier Access Security Management Entity
2010
Version 2 Rev 4 Security in LTE
Security in LTE
Figure 7-32 AKA
The diagram above illustrates AKA Procedure.
Step
1 Connection or service request by the UE. The UE identifies
itself with the IMSI. This is typically done at power-on.
2 MME requests authentication information for that IMSI from
HSS.
3 HSS sends MME one (1) to five (5) authentication vectors each
containing RAND, AUTH, XRES and KASME.
4 The MME chooses one of the five vectors and sends the UE a
USER AUTHENTICATION REQUEST using the RAND, AUTN
and KSIASME.
5 Using the RAND and its stored K secret key, the UE
authenticates the network by verifying the AUTN. The UE then
generates the RES and sends a USER AUTHENTICATION
RESPONSE to MME.
6a MME authenticates the UE by comparing the RES sent by the
UE and the XRES.
6b The CK and IK are computed in the UE the same way that
they are computed in the HSS. This way, they never have to
be sent over the air interface.
2010
Lesson Summary Version 2 Rev 4
Lesson Summary
• How the UE attaches to the E-UTRAN and EPC

• How the UE attaches, authenticates, and registers on the LTE Network
• The different Radio Resource Control and Mobility Management States
• How the UE acquires and selects an eNodeB
• The Initial Attach, UE Service Request, Network Triggered Service Request, UE Triggered Detach
2010
Memory Points
2010
Mobility Operation and Signaling Version 2 Rev 4
Chapter 8
Mobility Operation and Signaling
2010
Version 2 Rev 4 Mobility Operation and Signaling
2010
Objectives
• Describe UE mobility while idle

• Describe UE mobility while active
2010
Version 2 Rev 4 Mobility
Mobility
Figure 8-2 Mobility
As a UE moves throughout the network, it is “listening” to SIB1 messages to determine its Tracking Area
location in the network.
The eNodeB may also order the UE to report its measured channel quality as a Channel Quality
Indicator (CQI). Among other things, the CQI report sent back to the network may indicate that a
neighbor cell has a stronger signal than the current serving cell, making it a candidate for a handover.
In this lesson, we will discuss the Tracking Area Update and Active Handover Procedures.
2010
Physical Layer Measurements Version 2 Rev 4
Physical Layer Measurements

With the measurement specifications L1 provides measurement capabilities for the UE and E-UTRAN.
These measurements can be classified in different reported measurement types: intra-frequency,
inter-frequency, inter-system, traffic volume, quality and UE internal measurements.
To initiate a specific measurement in connected mode, the E-UTRAN transmits a ‘RRC connection
reconfiguration message' to the UE including a measurement ID and type, a command (setup, modify,
release), the measurement objects, the measurement quantity, the reporting quantities and the reporting
criteria (periodical/event-triggered).
When the reporting criteria are fulfilled the UE answers with a 'measurement report message' to the
E-UTRAN including the measurement ID and the results.
UE Measurement Capabilities
Figure 8-3 UE and E-UTRA Measurements
The following UE measurements can be initiated:

• Reference Signal Received Power (RSRP) — Is determined for a considered cell as the
linear average over the power contributions (in [W]) of the resource elements that carry
cell-specific reference signals within the considered measurement frequency bandwidth. For
RSRP determination the cell-specific reference signals R0 and if available R1 (second antenna)
accordingly can be used. If receiver diversity is in use by the UE, the reported value shall be
equivalent to the linear average of the power values of all diversity branches. This is applicable for:
– RRC_IDLE intra-frequency
– RRC_IDLE inter-frequency
– RRC_CONNECTED intra-frequency
– RRC_CONNECTED inter-frequency
• E-UTRA Carrier Received Signal Strength Indicator (RSSI) — comprises the total received
wideband power observed by the UE from all sources, including co-channel serving and
non-serving cells, adjacent channel interference, thermal noise etc.
• Reference Signal Received Quality (RSRQ) — is defined as the ratio N x RSRP/(E-UTRA carrier
RSSI), where N is the number of RBs of the E-UTRA carrier RSSI measurement bandwidth. The
measurements in the numerator and denominator shall be made over the same set of resource.
This is applicable for:
– RRC_IDLE intra-frequency
– RRC_IDLE inter-frequency
– RRC_CONNECTED intra-frequency
2010
Version 2 Rev 4 Physical Layer Measurements
Physical Layer Measurements

– RRC_CONNECTED inter-frequency
• UTRA FDD CPICH Received Signal Code Power (RSCP) — The received power on one code
measured on the Primary CPICH. This is applicable for:
– RRC_IDLE inter-RAT
– RRC_CONNECTED inter-RAT
• UTRA FDD carrier RSSI — The received wide band power, including thermal noise and noise
generated in the receiver for 3G cells. This is applicable for:
• UTRA FDD CPICH Ec/No — The received energy per chip divided by the power density in the
band for 3G cells. This is applicable for:
• GSM carrier RSSI — Received Signal Strength Indicator, the wideband received power within the
relevant channel bandwidth. Measurement shall be performed on a GSM BCCH carrier. This is
applicable for:
• cdma2000 1x RTT Pilot Strength — cdma2000 1x RTT pilot strength measurement.
• cdma2000 HRPD Pilot Strength — cdma2000 HRPD pilot strength measurement.
E-UTRAN Measurement Abilities

The following E-UTRAN measurements can be initiated:
• DL RS TX power — Downlink reference signal transmit power is determined for a considered cell
as the linear average over the power contributions (in [W]) of the resource elements that carry
cell-specific reference signals which are transmitted by the eNodeB within its operating system
bandwidth. For DL RS TX power determination the cell-specific reference signals R0 and if available
R1.
• Received Interference Power — The uplink received interference power, including thermal noise,
within one physical resource block’s bandwidth of resource elements.
• Thermal Noise Power — The uplink thermal noise power within the UL system bandwidth.
2010
Version 2 Rev 4 Physical Layer Measurements
2010
Version 2 Rev 4 General Description of Idle Mode Procedures
General Description of Idle Mode Procedures
Figure 8-4 LTE Idle Mode Tasks
Manual Mode Automatic Mode
PLMN Selection
Indication to user
Support for Manual
CSG ID Selection Available
Location area PLMNs PLMNs CSG IDs
response selected available to NAS
NAS Control
Cell Selection
and Reselection
Radio
measurements
Registration area
changes
Service requests
Location
Registration
When an UE is switched on, it attempts to make contact with a PLMN. The particular PLMN to be
contacted may be selected either automatically or manually.
The UE looks for a suitable cell of the chosen PLMN and chooses that cell to provide available services,
and tunes to its control channel. This choosing is known as "camping on the cell". The UE will then
register its presence in the registration area of the chosen cell if necessary, by means of a Network
attach procedure.
If the UE loses coverage of a cell, or find a more suitable cell, it reselects onto the most suitable cell of
the selected PLMN and camps on that cell. If the new cell is in a different registration area, a Tracking
Area Update (TAU) procedure is performed.
If the UE loses coverage of a PLMN, either a new PLMN is selected automatically, or an indication of
which PLMNs are available is given to the user, so that a manual selection can be made.
Registration is not performed by UEs only capable of services that need no registration.
The purpose of camping on a cell in idle mode is fourfold:
1. It enables the UE to receive system information from the PLMN.
2. If the UE wishes to initiate a call, it can do this by initially accessing the network on the control
channel of the cell on which it is camped.
3. If the PLMN receives a call for the UE, it knows (in most cases) the registration area of the cell in
which the UE is camped. It can then send a "paging" message for the UE on control channels of all
the cells in the registration area. The UE will then receive the paging message because it is tuned
to the control channel of a cell in that registration area, and the UE can respond on that control
channel.
4. It enables the UE to receive cell broadcast messages.
If the UE is unable to find a suitable cell to camp on, or the SIM is not inserted, or if it receives certain
responses to an TR request (e.g., "illegal MS"), it attempts to camp on a cell irrespective of the PLMN
identity, and enters a "limited service" state in which it can only attempt to make emergency calls.
The idle mode tasks can therefore be subdivided into four processes:
1. PLMN selection
2. Cell selection and reselection
3. Location registration
4. Provides support for manual Closed Subscriber Group (CSG) ID selection.
3GPP TS 23.122 V8.6.0 (2009–06) NAS functions in Idle Mode
2010
General Description of Idle Mode Procedures Version 2 Rev 4
General Description of Idle Mode Procedures

3GPP TS 36.304 V8.6.0 (2009–06) UE procedures in Idle Mode
Closed Subscriber Group (CSG)

This is a 3GPP Release 8 feature that provides support to Femto cells (or home eNodeBs) and allows
the network to identify groups of cells, so users can either be prevented from trying to enter these cells
or quickly establishing a connection if subscribed to that group.
2010
Version 2 Rev 4 Cell Selection and Reselection
Cell Selection and Reselection
Figure 8-5 LTE Cell Selection and Reselection Procedures
Go here whenever a new

PLMN is selected
Cell information No cell information

stored for PLMN 1 stored for PLMN
Stored
Initial
information No suitable cell found
cell selection
cell selection
2
No suitable Suitable cell found Suitable cell found
cell found
No suitable
cell found
Cell selection NAS indicates
when leaving Suitable Camped that registration
connected cell found normally on selected
mode PLMN is
rejected
Return to idle Trigger Suitable

mode Leave idle
mode cell found
Cell selection
Evaluation No suitable
Connected process cell found
mode Go here when
no USIM in
the UE
Any cell
No acceptable selection
cell found
USIM inserted
Acceptable
cell found
Cell selection
when leaving Acceptable Camp on Suitable cell
connected cell found any cell found 2
mode
Return to
idle mode Trigger Suitable
Leave idle
mode cell found
Connected Cell
mode reselection No acceptable
(emergency Evaluation cell found
calls only) process
2010
Cell Selection and Reselection Version 2 Rev 4
Cell Selection and Reselection
Cell Selection Process

The UE uses one of the following two cell selection procedures:
1. Initial Cell Selection
This procedure requires no prior knowledge of which RF channels are E-UTRA carriers. The UE
scans all RF channels in the E-UTRA bands according to its capabilities to find a suitable cell. On
each carrier frequency, the UE searches for the strongest cell. Once a suitable cell is found this
cell shall be selected.
2. Stored Information Cell Selection
This procedure requires stored information of carrier frequencies and optionally, information on cell
parameters from previously received measurement control information elements or from previously
detected cells. Once the UE has found a suitable cell the UE shall select it. If no suitable cell is
found the Initial Cell Selection procedure shall be started.
Service Types in Idle Mode

The action of camping on a cell is necessary to get access to some services. The levels of service are
defined for the UE:
• Limited service (emergency calls on an acceptable .
• Normal service (for public use on a suitable cell).
• Operator service (for operators only on a reserved cell).
The cells themselves are then categorized according to which services they offer.
Acceptable Cell
An "acceptable cell" is a cell on which the UE may camp to obtain limited service (originate emergency
calls). Such a cell shall fulfil the following requirements, which is the minimum set of requirements to
initiate an emergency call in a E-UTRAN network:
• The cell is not barred.
• The cell selection criteria are fulfilled.
Suitable Cell
A "suitable cell" is a cell on which the UE may camp on to obtain normal service. Such a cell shall fulfil
all the following requirements:
• The cell is part of either:
– the selected PLMN, or;
– the registered PLMN, or;
– a PLMN of the Equivalent PLMN list,
according to the latest information provided by the NAS.
• The cell is not barred.
• The cell is part of at least one Tracking Area (TA) that is not part of the list of "forbidden LAs for
roaming", which belongs to a PLMN that fulfils the first bullet above.
• The cell selection criteria are fulfilled.
• For a cell identified as Closed Subscriber Group (CSG) cell by system information, the CSG ID
is part of the CSG white list.
If more than one PLMN identity is broadcast in the cell, the cell is considered to be part of all TAs with
Tracking Area Identities (TAIs) constructed from the PLMN identities and the Tracking Area Code
(TAC) broadcast in the cell.
Barred and Reserved Cells

A cell is barred or reserved if it is so indicated in the system information
2010
Version 2 Rev 4 Cell Selection Criteria
Cell Selection Criteria
Figure 8-6 LTE Cell Selection Criteria
The cell selection criterion S is fulfilled when:

Srxlev > 0
Where:
Srxlev = Qrxlevmeas — (Qrxlevmin + Qrxlevminoffset) — Pcompensation
Parameter Meaning
Srxlev Cell selection RX level value (dB)
Qrxlevmeas Measured cell RX level value (RSRP)
Qrxlevmin Minimum required RX level in the cell
(dBm)
Qrxlevminoffset Offset to the signalled Qrxlevmin taken into
account in the Srxlev evaluation as a result
of a periodic search for a higher priority
PLMN while camped normally in a VPLMN
Pcompensation max(PEMAX – PUMAX, 0) (dB)
PEMAX Maximum TX power level an UE may use
when transmitting on the uplink in the cell
(dBm)
PUMAX Maximum RF output power of the UE
(dBm) according to the UE power class
The Qrxlevmin and PEMAX parameters are found in the SIB Type 1 and are broadcast to the UE in its control
channel.
2010
Cell Reselection Criteria Version 2 Rev 4
Cell Reselection Criteria
Figure 8-7 LTE Cell Reselection Search
Once the UE performs selection onto a particular cell the UE will continue to take measurements on the
serving cell. There are parameters to decide whether the UE should begin to take measurements of
other LTE intra, inter frequency neighbors or indeed other RATs and technologies.
Reselection priorities handling

Absolute priorities of different E-UTRAN frequencies or inter-RAT frequencies may be provided to the
UE in the system information, in the RRC Connection Release message, or by inheriting from another
RAT at inter-RAT cell (re)selection. The range of priorities is from 0 to 7, with 0 being the lowest priority
and 7 the highest.
Intra-frequency Measurement Rules

The following rules are used by the UE to limit needed measurements by the UE:
• If SServingCell > Sintrasearch, UE may choose to not perform intra-frequency measurements
• If SServingCell <= Sintrasearch, UE shall perform intra-frequency measurements.
2010
Version 2 Rev 4 Cell Reselection Criteria
Non Intra-frequency Measurement Rules

The UE applies the following rules for E-UTRAN inter-frequencies and inter-RAT frequencies which are
indicated in system information and for which the UE has priority:
• For an E-UTRAN inter-frequency or inter-RAT frequency with a reselection priority higher than the
reselection priority of the current E-UTRA frequency the UE shall perform measurements of higher
priority E-UTRAN inter-frequency or inter-RAT frequencies.
• For an E-UTRAN inter-frequency with a equal or lower reselection priority than the reselection
priority of the current E-UTRA frequency and for inter-RAT frequency with lower reselection priority
than the reselection priority of the current E-UTRA frequency:
– If SServingCell > Snonintrasearch UE may choose not to perform measurements of inter-RAT frequencies
or inter-frequencies of equal or lower priority.
– If SServingCell <= Snonintrasearch the UE shall perform measurements of inter-RAT frequencies or
inter-frequencies cells of equal or lower priority.
Where SServingCell is the S-value of the serving cell.
Mobility States of a UE
There are also parameters broadcast in system information to detect whether the UE is in:
• Normal mobility state.
• Medium mobility state.
• High mobility state.
If for instance the UE is detected in 'high mobility state' then cells which have been designated as small
cells (micro and pico cells) shall be discouraged for reselection purposes by using speed dependant
scaling rules.
2010
Cell Reselection Criteria Version 2 Rev 4
Intra-frequency and Equal Priority Inter-Frequency Cell Reselection

Criteria
Figure 8-8 LTE Cell Reselection Criteria Intra and Inter Frequency
Once the criteria has been met to measure intra-frequency or equal priority inter-frequency neighbors
then the UE will rank all cells that meet criterion S. It might be that the operator either wants to apply
a hysteresis to the serving cell to prevent numerous unnecessary reselections. Or an offset might be
applied to the neighbor to either make the neighbor more or less attractive.
Cell Ranking Criterion

The cell-ranking criterion Rs for serving cell and Rn for neighboring cells is defined by:
Rs = Qmeas,s + Qhysts
Rn = Qmeas,n — Qoffset
Where:
• Qmeas — Averaged RSRP measurement quantity used in cell reselections.
• Qoffset — Qoffsets,n for intra-frequency cells.
• Qoffset — Qoffsets,n + Qoffsetfrequency for inter-frequency cells.
Qoffsets,n — This specifies the offset between two cells.
Qoffsetfrequency — Frequency specific offset for equal priority frequencies.
The cell that is ranked highest by the R criterion will cause the UE to reselect if the following is true:
•The new cell is better ranked than the serving cell during a time interval Treselections. Treselections
is specified on a per technology basis, but is generically known as TreselectionRAT.
• Detect whether the UE is in high mobility state, if so apply scaling factor to this cell.
• More than 1 second has elapsed since the UE camped on the current serving cell.
2010
Version 2 Rev 4 Cell Reselection Criteria

E-UTRAN Inter-frequency and Inter-RAT Cell Reselection Criteria
Figure 8-9 LTE Cell Reselection High Priority or Inter-Frequency or Inter-RAT
It might be the case that the UE needs to move to a different LTE frequency or other RAT. The other RAT
maybe WCDMA 3G, GSM or cdma2000. The criteria to detect whether a reselection to these cells is
different to that of intra-frequency reselections and this procedure is explained here.
Criteria 1
The SnonServingCell,x of a cell on evaluated frequency is greater than Threshx, high during a time interval
TreselectionRAT;
Cell Reselection to a Cell on a Higher Priority E-UTRAN Frequency or Inter-RAT Frequency

In this case the UE will reselect if:
• A cell of a higher priority E-UTRAN frequency or inter-RAT frequency fulfils criteria 1; and
• more than 1 second has elapsed since the UE camped on the current serving cell.
Cell Reselection to a Cell on a Equal Priority E-UTRAN Frequency

This has been described in the section — “Intra-frequency and Equal Priority Inter-Frequency Cell
Reselection Criteria”.
Cell Reselection to a Cell on a Lower Priority E-UTRAN Frequency or Inter-RAT Frequency

In this case the UE will reselect if:
• No cell on a higher priority E-UTRAN frequency or inter-RAT frequency than serving frequency
fulfills the criteria 1; and
• No cell on serving frequency or on an equal priority E-UTRAN frequency fulfills the criteria stated
in the section — “Intra-frequency and Equal Priority Inter-Frequency Cell Reselection Criteria”.
• SServingCell < Threshserving, low and the SnonServingCell,x of a cell of a lower priority frequency RAT or frequency
is greater than Threshx, low during a time interval TreselectionRAT; and
• more than 1 second has elapsed since the UE camped on the current serving cell.
2010
Tracking Area (TA) Version 2 Rev 4
Tracking Area (TA)
Figure 8-10 Tracking Areas
A Tracking Area (TA) is a defined group of cells which can be used by the MME to page idle UEs. Within
a Tracking Area, a UE is associated with a single MME and S-GW. As it moves to a new Tracking Area,
an idle UE must announce its new “location” to the serving MME. That process is called a Tracking Area
Update (TAU).
Instead of using a single Tracking Area, the MME may supply a

Tracking Area List to reduce the location update signaling from
the UE. As long as the UE is located in any of the listed Tracking
Areas, a Tracking Area Update is not necessary.
Tracking Area Identifiers
Figure 8-11 Tracking Area ID
A Tracking Area ID (TAI) uniquely identifies the tracking area for paging and location updates. The TAI
consists of the Mobile Country Code (MCC), Mobile Network Code (MNC), and Tracking Area Code
(TAC). The graphic shows a Tracking Area consisting of two eNodeBs supporting five cells.
2010
Version 2 Rev 4 Tracking Area (TA)
Tracking Area (TA)

Together, the MCC and MNC identify the carrier’s PLMN identity. A Tracking Area (and TA Code) may
be shared by more than one carrier. In that case, each carrier will identify the Tracking Area with its MCC
and MNC values.
Mobile Country Code – 3 binary-coded decimal digits which uniquely identify the network operator’s
country.
Mobile Network Code – 3 binary-coded decimal digits which uniquely identify the network operator
within a country
Tracking Area Code – 16-bit code which uniquely identifies the Tracking Area within the PLMN. If the
Tracking Area is used by more than one PLMN, each carrier must use the same TAC.
Tracking Area Rules

There are several rules that need to be followed when implementing Tracking Areas:
• A cell can belong to one and only one Tracking Area

• Each eNodeB can contain cells belonging to different Tracking Areas
• A Tracking Area can belong to more than one MME Pool Area
• A Tracking Area can belong to more than one S-GW Service Area
• A Tracking Area must be completely contained within a S-GW Service Area
• A Tracking Area must be completely contained within a MME Pool Area
• There is no formal limit to the number of Tracking Areas that can be associated with an MME Pool,
although an artificial limit may be used
• There is no formal limit to the number of Tracking Areas that can be associated with a S-GW Service
Area, although an artificial limit may be used
• A Tracking Area can be no greater than the number of cells in the Pool (MME or SGW) that it is
associated with. Generally, Tracking Areas would be implemented contiguously, with all cells in the
Tracking Area, however this is not restricted by the standards
• Tracking Areas are shared across PLMN IDs, since a cell can only be associated with one Tracking
Area and a cell can be associated with multiple PLMN IDs
• An MME can assign several Tracking Areas to the UE, helping reduce the Tracking Area update
signaling
• The Tracking Areas defined in the Tracking Area list allocated to the UE shall be located within one
MME Pool Area
2010
MME and S-GW Pools Version 2 Rev 4
MME and S-GW Pools
Figure 8-12 Network Element Pooling
The EPC supports MME and S-GW pools for improved mobility, geographical redundancy, and load
balancing. A pool is a set of MMEs or S-GWs that serve a set of Tracking Areas. A pool area is defined
as an area where a UE may be served without needing to change the serving network element.
Each cell is associated with a pool of MMEs and a pool of S-GWs. After an eNodeB selects an MME for
a UE, the selected MME will select an S-GW within the S-GW Pool supported by the cell.
MME Pool
An MME Pool is defined as a collection of MMEs that serve a defined group of cells.
• An MME can only belong to one MME Pool

• All MME nodes of one MME Pool serve the same one and only one MME Pool Area
• Each Tracking Area can be associated with more than one MME Pool
• All MMEs within an MME Pool are (or can be) logically connected
• A UE is associated with a single MME within the MME pool
MME Pool Area

An MME Pool Area is an area within which a UE may be served without a need to change the serving
MME. An MME Pool Area is served by one or more MMEs (“pool of MMEs”) in parallel.
• An MME Pool Area is a collection of complete Tracking Areas

• MME Pool Areas may overlap each other
Serving Gateway (S-GW) Service Area

A S-GW Service Area is an area within which a UE may be served without a need to change the S-GW
which is currently in use. An S-GW Service Area is served by one or more S-GWs at the same time.
• An S-GW Service Area is a collection of complete Tracking Areas associated with the S-GW Service
Area
• S-GW Service Areas may overlap each other
2010
Version 2 Rev 4 MME and S-GW Pools
MME and S-GW Pools
S-GW Serving Area

• An S-GW serving area is served by one or more S-GWs acting in parallel (S-GW Pool)
• All S-GWs within an S-GW Pool are (or can be) logically connected
• A UE is associated with a single S-GW within the S-GW pool
Serving Gateway (S-GW) Pool

An S-GW Pool is a collection of S-GWs that serve an S-GW Service Area
• An S-GW can belong to only one S-GW Pool

• An S-GW Pool serves its associated S-GW Service Area
• Each cell can be associated with more than one S-GW Pool
• All S-GWs within an S-GW Pool are (or can be) connected for communication purposes
• An S-GW within one S-GW Pool can communicate with S-GWs in other S-GW Pools
• Connections between S-GWs within a pool or across pools are used for indirect packet forwarding
2010
Tracking Area Updates (TAUs) Version 2 Rev 4
Tracking Area Updates (TAUs)
Figure 8-13 Tracking Area Updates
In the Tracking Area Update (TAU) procedure, the UE notifies the MME that it has moved from one
Tracking Area to another, or from a Tracking Area in a TA list to a TA not on the list. If needed, the MME
will select a new S-GW.
Tracking Area Update Triggers

A Tracking Area Update (TAU) is triggered by any of the following events:
• Based on the Tracking Area ID advertised in system information, the UE discovers it has moved to
a new Tracking Area or to a TA not on its configured TA list
• The periodic TAU T3412 Timer has expired
• A dual-mode UE has moved from GPRS or UTRAN to E-UTRAN
• The UE’s RRC connection was released due to load rebalancing
• The UE’s core network capability and/or DRX parameters changed
2010
Version 2 Rev 4 Tracking Area Update (TAU) with no MME/S-GW Change
Tracking Area Update (TAU) with no MME/S-GW Change
This procedure will begin when the UE moves into a new Tracking Area based on its currently stored
Tracking Area ID or Tracking Area ID List, or a TAU timer expires.

Telecoms
LTE
300
2010
Tracking Area Update (TAU) with no MME/S-GW Change Version 2 Rev 4

Tracking Area Update (TAU) Steps
Figure 8-16 Tracking Area Update – Step 1
2010
Version 2 Rev 4 Tracking Area Update (TAU) with no MME/S-GW Change

Step
1 If a TAU trigger event occurs, the UE sends a Random Access Preamble to the
serving eNodeB to establish NAS signaling.
2 The eNodeB returns a Random Access Response with the RA Preamble ID, a
Temporary C-RNTI, and an UL grant.
3 The UE sends an RRC Connection Request message to the eNodeB during
the UL grant. This message contains the S-TMSI (if available) and reason for
this connection request.
4 The eNodeB returns a MAC Contention Resolution ID message to the UE.
If available, this message may include the RRC Connection Setup message
from step 5.
5 The eNodeB sets up a signaling radio bearer and returns an RRC Connection
Setup message to the UE. This message indicates the SRB1 parameters.
2010
Tracking Area Update (TAU) with no MME/S-GW Change Version 2 Rev 4

Figure 8-17 Tracking Area Update – 2
Step
6 The UE sends RRC Connection Setup Complete in response to the RRC

Connection Setup message. RRC Connection Setup Complete carries the NAS
Tracking Area Update Request to the eNodeB. The TAU Request includes the
UE network capability, active flag, EPS bearer status, last visited TAI, M-TMSI,
NAS sequence number, Security Keys, Selected Network, old GUMMEI, etc.
7 The eNodeB derives the MME from the GUMMEI and Selected Network. This
procedure assumes the derived MME is associated with the eNodeB (no MME
change). The eNodeB uses an S1AP Initial UE Message to transport the NAS
TAU Request together with the receiving cell’s TAI+ECGI to the MME.
8 If the MME’s authentication key timer has expired for this UE, the MME must
reauthenticate the UE. After this step, the UE and the TAU Request message
are considered valid.
9 If the UE is allowed to use the Tracking Area, the MME returns the NAS TAU
Accept message within the S1AP DL NAS Transfer PDU. TAU Accept contains
the GUTI, new TAI list, EPS bearer status, updated security keys, NAS sequence
number, and NAS-MAC parameters.
10 The eNodeB forwards the TAU Accept to the UE. TAU Accept is carried in the
RRC DL Information Transfer message. If the UE is in idle state, the MME will
release the S1 signaling resources.
2010
Version 2 Rev 4 TAU with MME and S-GW Change
TAU with MME and S-GW Change
Similar to the last procedure, an idle UE must signal a Tracking Area change. However, this scenario
requires an MME and S-GW change.
The S-GW is relocated if the old S-GW cannot serve the moved UE, if a new S-GW is expected to serve
the UE longer or with a more optimal bearer path, or if a new S-GW is co-located with the P-GW.

Telecoms
LTE
300
2010
TAU with MME and S-GW Change Version 2 Rev 4

Figure 8-19
The graphic shows what each network element knows about the UE at the end of this procedure
2010

TAU with MME and S-GW Change Procedure Steps
Figure 8-20 TAU with MME and S-GW Change – 1
Step
1 If a TAU trigger event occurs, the UE and eNodeB will perform an RRC
Connection Request and Setup handshake.
2 The UE sends RRC Connection Setup Complete with a NAS Tracking Area
Update Request to the eNodeB. The TAU Request includes the UE network
capability, active flag, EPS bearer status, last visited TAI, GUTI, NAS sequence
number, Security Keys, Selected Network, old GUMMEI, etc.
3 The eNodeB derives the MME from the GUTI and Selected Network. If that MME
is not associated with this NodeB, the eNodeB selects a new MME. Using the
S1AP Initial UE Message, the eNodeB forwards the NAS TAU Request together
with the its TAI+ECGI to the new MME.
4 The new MME derives the old MME from the GUTI in the TAU Request,
then sends a Context Request message (old GUTI, complete TAU Request
message, new MME Address, UE Validated, etc.) to the old MME to retrieve
user information. The old MME uses the complete TAU Request to validate the
Context Request. If the new MME indicates that it has authenticated the UE or if
the old MME correctly validates the UE, then the old MME starts a timer.
5 The old MME responds with a Context Response (e.g. IMSI, bearer contexts,
S-GW address and TEID). The P-GW address and TEID are part of the Bearer
Context.
2010

Step
6 If the integrity check in Step 4 fails, then authentication is mandatory. If a new

GUTI is allocated and the network supports ciphering, then NAS messages
are ciphered. If the authentication fails, then the TAU is rejected, and the new
MME sends a Reject Indication to the old MME. The old MME continues as if the
Step 5 was never performed.
7 The new MME decides whether to relocate the S-GW or not. If a new S-GW
is selected, the new MME sends a Context ACK (S-GW Change Indication)
message to the old MME. The old MME marks in its context that the information
in the S-GW, P-GW, and HSS must be updated.
8 Using the UE context received from the old MME, the new MME constructs a
Mobility Management (MM) context for the UE. The new MME releases any
network resources related to EPS bearers that are not active in the UE. If no
default bearer context exists, the MME rejects the TAU Request. If a new S-GW
was selected, the MME sends a GTP-C Create Bearer Request (IMSI, bearer
contexts, MME Context ID, Type, Protocol Type over S5/S8) message to the new
S-GW. Type instructs the S-GW to send Update Bearer Request the P-GW.
Protocol Type over S5/S8 tells the S-GW which IP mobility protocol should be
used over the S5/S8 interface.
9 The new S-GW sends the GTP-C Update Bearer Request (S-GW address,
S-GW TEID) to the P-GW.
10 The P-GW updates the bearer contexts and returns GTP-C Update Bearer
Response (P-GW address, TEIDs, etc.).
11 The S-GW updates its bearer context. The S-GW is now able to route bearer
PDUs from the eNodeB to the P-GW. The S-GW returns a GTP-C Create Bearer
Response to the new MME.
2010

Step
12 The new MME verifies whether it holds subscription data for the UE identified
by the GUTI. If there are no subscription data in the new MME for this UE then
the new MME sends a Diameter Update Location (Update Type) message to
the HSS. Update Type instructs the HSS to update the MME registration, and
whether the HSS should cancel the UE location in the old MME.
13 The HSS sends the Diameter Cancel Location (IMSI, Cancellation Type)
message to the old MME with Cancellation Type set to Update Procedure.
14 The old MME acknowledges with the Diameter Cancel Location Ack (IMSI)
message. When the timer started in step 5 expires, the old MME removes the
UE’s MM context. (The timer ensures that the MM context is kept in the old MME
in case the UE initiates another TAU procedure before completing the ongoing
TAU procedure.)
15 The HSS acknowledges the Update Location message by sending a Diameter
Update Location Answer to the new MME.
2010

Step
16 The old MME releases any local MME resources when the timer started in Step 5
expires. If the Context ACK (Step 7) message indicates an S-GW change, the
old MME deletes the EPS bearer resources by sending GTP-C Delete Bearer
Request (Cause, TEID) to the old S-GW. Cause indicates that the old S-GW
should not initiate a delete procedure towards the P-GW.
17 The old S-GW acknowledges with GTP-C Delete Bearer Response (TEID).
18 The new MME sends a NAS TAU Accept (GUTI, TAI list, EPS bearer status, NAS
sequence number, etc.) message to the UE. If the active flag is set, the MME
may provide the eNodeB with a Handover Restriction List. GUTI is included if the
MME allocates a new GUTI. If the active flag is set in the TAU Request message,
the user plane setup procedure can be activated at this time. The MME indicates
the EPS Bearer Status IE to the UE. The UE removes any internal resources
related to bearers that are not marked active in the received EPS Bearer Status.
19 If a GUTI was included in the TAU Accept, the UE returns a NAS TAU Complete
message to the MME. If the UE is in idle mode, the MME will release any
signaling resources with the UE.
2010
Version 2 Rev 4 Connected Mode Mobility
Connected Mode Mobility
Figure 8-24 LTE Connected Mode Mobility
In RRC_CONNECTED state , the network controls UE mobility, i.e. the network decides when the UE
shall move to which cell (which may be on another frequency or RAT). The network triggers the handover
procedure e.g. based on for example radio conditions or load. To facilitate this, the network may configure
the UE to perform measurement reporting (possibly including the configuration of measurement gaps).
The network may also initiate handover blindly, i.e. without having received measurement information
from the UE. Blind handovers are usually used when both source and target cells occupy the same
physical area so mobility can be more-or-less guaranteed.
2010
Connected Mode Mobility Version 2 Rev 4
Inter-RAT Measurements in Connected Mode

The UE reports measurement information in accordance with the measurement configuration
as provided by E-UTRAN. E-UTRAN provides the measurement configuration applicable
for a UE in RRC_CONNECTED state by means of dedicated signalling, i.e. using the
RRCConnectionReconfiguration message.
Measurement Types
The following measurement types have been defined for Inter-RAT handovers:
• Inter-RAT measurements of UTRA frequencies.
• Inter-RAT measurements of GERAN frequencies.
• Inter-RAT measurements of cdma2000 HRPD or 1xRTT frequencies.
Measurement Objects
The objects on which the UE shall perform the measurements for Inter-RAT handovers:
• For inter-RAT UTRA measurements a measurement object is a set of cells on a single UTRA carrier
frequency.
• For inter-RAT GERAN measurements a measurement object is a set of GERAN carrier frequencies.
• For inter-RAT cdma2000 (HRPD or 1xRTT) measurements a measurement object is a set of cells
on a single (HRPD or 1xRTT) carrier frequency.
.
Reporting Configurations
A list of reporting configurations where each reporting configuration consists of the following:
• Reporting criteria: The criteria that triggers the UE to send a measurement report. This can either
be periodical or a single event description.
• Reporting format: The quantities that the UE includes in the measurement report and associated
information (e.g. number of cells to report).
Types of Cells to be Measured

The UE measures and reports the following types of cells:
• The serving cell.
• Listed cells - these are cells listed within the measurement object(s).
• Detected cells - these are cells that are not listed within the measurement object(s) but are detected
by the UE on the carrier frequency(ies) indicated by the measurement object(s).
For E-UTRA, the UE measures and reports on the serving cell, listed cells and detected cells. For
Inter-RAT UTRA the UE measures and reports on listed cells. For Inter-RAT GERAN the UE measures
and reports on detected cells. For Inter-RAT cdma2000 the UE measures and reports on listed cells.
2010
Version 2 Rev 4 Connected Mode Mobility

Measurement Report Triggering
Figure 8-25 LTE Measurement Report Triggering
The UE will deliver a measurement report to the eNodeB based upon the content of the measurement
configuration message delivered to the UE. This message could contain:
• Report of strongest cells for SON
• Report CGI
• If Event driven reports — Event that triggered the report
• Neighbor list
Handover Events
Figure 8-26 Measurement Report Delivery
2010
Connected Mode Mobility Version 2 Rev 4

The events currently defined are:
• A1 — Serving Cell becomes better than a threshold
• A2 — Serving cell becomes worse than a threshold
• A3 — Neighbor cell becomes better than the serving cell by an offset
• A4 — Neighbor cell becomes better than a threshold
• A5 — Serving cell becomes worse than threshold 1 and neighbor becomes better than threshold 2
• B1 — Inter-RAT neighbor becomes better than a threshold
• B2 — Serving cell becomes worse than threshold 1 and Inter-RAT neighbor becomes better than
threshold 2
2010
Version 2 Rev 4 eNodeB (X2) Active Handover
eNodeB (X2) Active Handover
In contrast with the last two procedures, the UE is active and has radio bearer resources to send and
receive data over the air interface. In this scenario, the eNodeB changes but the MME and S-GW remain
the same.

Telecoms
LTE
300
2010
eNodeB (X2) Active Handover Version 2 Rev 4

eNodeB (X2) Active Handover Procedure Steps
Figure 8-29 eNodeB Active Handover – 1
2010

Step
1 The Source eNodeB sends, via RRC System Information messages,

measurement procedures.
2 In response, the UE sends an RRC Measurement Report.
3 The Source eNodeB makes a decision based on the UE’s Measurement Report
to hand over the UE.
4 The Source eNodeB issues an X2AP Handover Request message to the
Target eNodeB. The Handover Request includes the UE’s X2 signaling context
reference at the Source eNodeB, the UE’s S1 EPC signaling context reference,
target cell ID, EPS bearer context and physical layer ID of the source cell.
5 The Target eNodeB may perform admission control based on the EPS bearer
QoS information to improve the chances of a successful handover. The Target
eNodeB configures the required resources according to the received EPS bearer
QoS information.
6 The Target eNodeB prepares the Layer 1 and 2 handover resources and sends
the X2AP Handover Request Acknowledge message to the Source eNodeB.
Handover Request Acknowledge includes a new C-RNTI, Target eNodeB
security algorithm identifiers, and access parameters, SIBs, etc.
2010

Step
7 The Source eNodeB sends the RRC Handover Command to the UE. Handover
Command includes the Target eNodeB’s new C-RNTI, security algorithm
identifiers, and access parameters, SIBs, etc. and is commanded by the Source
eNodeB to perform the HO. The Source eNodeB performs the necessary integrity
protection and ciphering of the message.
8 The UE detaches from the Source eNodeB and synchronizes to the Target
eNodeB. At this point the UE no longer has radio resources with the Source
eNodeB.
9 The Source and Target eNodeBs set up the X2 user plane tunnel.
10 The Source eNodeB sends the X2AP SN Status Transfer message to the Target
eNodeB to convey the PDCP DL and UL sequence numbers for the UE’s bearers.
Step
11 The Source eNodeB will now forward DL UE traffic to the Target eNodeB. The DL
packets are buffered in the Target eNodeB.
12 The UE sends a Random Access Preamble to the Target eNodeB.
13 The Target eNodeB returns a MAC Random Access Response (RAR)
containing an UL grant and Timing Aadvance (TA).
14 The UE sends the RRC Handover Confirm message along with a MAC Buffer
Status Report indicating the pending UL traffic in the UE. The Target eNodeB can
now begin sending DL data to the UE.
2010

Step
15 The Target eNodeB sends an S1AP Path Switch message to the MME to signal
that the UE has changed cells.
16 The MME sends a GTP-C User Plane Update Request (eNodeB address and
TEIDs for the EPS bearers) message to the serving S-GW.
17 The S-GW switches the DL data path to the Target eNodeB. The S-GW may start
sending DL packets to the Target eNodeB using the newly received address and
TEIDs. However, the Target eNodeB will buffer any packets received over the
new S1-U bearer path.
18 The S-GW sends one or more "end marker" packets on the old path to the
Source eNodeB and then releases any resources towards the Source eNodeB.
2010

Step
19 The S-GW sends a GTP-C User Plane Update Response message to the MME.
20 The MME confirms the Path Switch Request (Step x) message with the S1AP
Path Switch Request ACK message.
21 The Target eNodeB sends the X2AP UE Context Release message to inform the
Source eNodeB that the handover was successful.
22 The Source eNodeB will flush its DL buffer and continue to deliver any in-transit
packets. When finished, the Source eNodeB forwards the end marker packets
to the Target eNodeB. All DL packets (except the end marker packets) are
forwarded from the Target eNodeB to the UE.
23 After receiving the end marker packets, the Target eNodeB sends an X2AP
Release Resource message to the Source eNodeB. Upon receiving the X2AP
Release Resources message, the Source eNodeB will release any resources
associated with the UE.
2010
Version 2 Rev 4 Active Handover with MME and S-GW Change
Active Handover with MME and S-GW Change
The UE is active and has radio bearer resources to send and receive data over the air interface. In this
scenario, the eNodeB, MME, and S-GW change during an active handover.

Telecoms
LTE
300
2010
Active Handover with MME and S-GW Change Version 2 Rev 4

2010

Direct vs. Indirect Forwarding
Figure 8-36 Inter MME/S-GW Handover
The inter eNodeB handover with MME relocation procedure is used to relocate the MME only, or both
the MME and the S-GW. The procedure is initiated in the source eNodeB which also selects the target
MME. The MME will not be relocated during inter-eNodeB handover unless the UE leaves the MME Pool
Area where the UE is served. If the target MME determines the S-GW needs to be relocated, then it is
selected by the target MME.
The source eNodeB decides which of the EPS bearers are subject for forwarding of packets from the
source eNodeB to the target eNodeB. The EPC does not change the decisions taken by the RAN
node. Packet forwarding can take place either directly from the source eNodeB to the target eNodeB,
or indirectly from the source eNodeB to the target eNodeB via the source and target S-GWs (or if the
S-GW is not relocated, only the single S-GW).
The availability of a direct forwarding path is determined in the source eNodeB and indicated to the
source MME. If X2 connectivity is available between the source and target eNodeBs, a direct forwarding
path is available.
If a direct forwarding path is not available, indirect forwarding may be used. The MMEs (source and
target) use configuration data to determine whether indirect forwarding paths are to be established.
Depending on configuration data, the source MME determines and indicates to the target MME whether
indirect forwarding paths should be established. Based on this indication and on its configuration data,
the target MME determines whether indirect forwarding paths are established.
2010

Active Handover with MME and S-GW Change Procedure Steps
Figure 8-37 Active Handover with MME and S-GW Change – 1
Step
1 The Source eNodeB decides to initiate an inter-eNodeB handover, where the

Target eNodeB is served by a different MME.
2 The Source eNodeB sends an S1AP Handover Required message to the
Source MME. Handover Required indicates which bearers are subject to data
forwarding, and whether direct (X2) forwarding is available from the Source
eNodeB to the Target eNodeB.
3 The Source MME selects the Target MME and sends a GTP-C Forward
Relocation Request. This message contains the MME UE context including the
P-GW addresses and TEIDs, S-GW addresses and TEIDs, and an if direct (X2)
forwarding or indirect (S-GW) forwarding will be used.
4 If the Source S-GW cannot continue to serve the UE, the Target MME selects a
new S-GW and sends a GTP-C Create Bearer Request containing the bearer
context(s) with P-GW addresses and TEIDs to the target S-GW. The Target
S-GW allocates S-GW addresses and TEIDs for the uplink traffic on the S1-U
reference point (one TEID per bearer).
5 The Target S-GW sends a GTP-C Create Bearer Response containing the S-GW
addresses and uplink TEID(s) back to the Target MME.
2010

Step
6 The Target MME sends the S1AP Handover Request containing the S1 S-GW
addresses and TEID(s) to the Target eNodeB. This message creates the UE
context in the Target eNodeB, including information about the bearers, and the
security context.
7 The Target eNodeB sends a Handover Request Acknowledge message to the
Target MME. This includes the list of rejected EPS bearers and addresses and
TEIDs allocated at the Target eNodeB for downlink traffic on the S1-U interface
(one TEID per bearer).
8 The Target MME sends a Forward Relocation Response (S-GW change
indication) message to the Source MME. If indirect forwarding is used, this
message includes S-GW Address and TEIDs for indirect forwarding. S-GW
change indication indicates a new S-GW has been selected.
9 The Source MME sends an S1AP Handover Command (target addresses and
TEID(s) for data forwarding) to the Serving eNodeB.
2010

10 The Source eNodeB sends the Handover Command to the UE. Upon receipt of
this message the UE will remove any EPS bearers for which it did not receive
corresponding EPS radio bearers in the target cell.
Step
11 The Source eNodeB will start forwarding downlink data towards the Target
eNodeB for bearers subject to data forwarding.
12 The UE will detach from the Source eNodeB.
13 The UE will synchronize with the Target eNodeB.
14 The UE sends a Handover Confirm message to the Target eNodeB. DL packets
forwarded from the Source eNodeB can be sent to the UE. UL packets can now
be sent from the UE to the Target S-GW.
2010

Step
15 The Target eNodeB sends a Handover Notify message to the Target MME.
16 The Target MME sends Forward Relocation Complete to the Source MME.
17 The Source MME returns a Forward Relocation Complete Ack to the Target
MME. A timer in the Source MME is started to supervise when resources in the
Source eNodeB and Source S-GW will be released.
18 The Target MME sends an Update Bearer Request message to the Target S-GW.
Update Bearer Request contains the eNodeB addresses and TEIDs allocated at
the Target eNodeB for DL traffic on S1–U for the accepted EPS bearers, and the
P-GW address and TEIDs for UL traffic.
2010

Step
19 If the S-GW is relocated, the Target S-GW assigns addresses and TEIDs (one
per bearer) for DL traffic from the P-GW. It sends Update Bearer Request
to inform the P-GW of the S-GW and TEID(s) changes. If the S-GW is not
relocated, no message is sent in this step and DL packets from the S-GW are
immediately sent on to the Target eNodeB.
20 The P-GW updates its context field and returns Update Bearer Response (P-GW
address and TEID, MSISDN, etc.) to the Target S-GW. The P-GW starts sending
DL packets to the Target S-GW using the newly received address and TEIDs.
21 The Target S-GW sends Update Bearer Response (P-GW addresses and TEIDs
at the P-GW for uplink traffic) to the Target MME.
2010

Step
22 The Target eNodeB triggers the UE to initiate a Tracking Area Update procedure
with the Target MME. Because the Target MME knows that a Handover procedure
has been performed for this UE, it performs only a subset of the TAU procedure.
Specifically it excludes the context transfer procedures between Source MME
and Target MME.
23 When the timer started in step 17 expires the Source MME sends a UE Context
Release Command to the Source eNodeB.
24 The Source eNodeB releases its resources related to the UE and notifies the
Source MME that the resources have been released with UE Context Release
Complete.
25 When the timer started in step 17 expires and if the Source MME received
the S-GW change indication in the Forward Relocation Response message, it
deletes the EPS bearer resources by sending Delete Bearer Request (Cause,
TEID) to the Source S-GW. Cause indicates that the S-GW changed and the
Source S-GW shall not initiate a delete procedure towards the P-GW.
26 The Source S-GW acknowledges with Delete Bearer Response (TEID). If
resources for indirect forwarding have been allocated then they are released.
2010
2010
Lesson Summary
In this lesson you learned:
• How an idle UE performs a Tracking Area Update

• How an active UE performs an eNodeB handover
2010
Memory Points
2010
2010
Services and Bearer QoS Version 2 Rev 4
Chapter 9
Services and Bearer QoS
2010
Version 2 Rev 4 Services and Bearer QoS
2010
Objectives
• List typical end user services

• Describe QoS operation in the EPS
• Describe the IMS architecture and IMS-based services
• Describe the MBMS architecture and MBMS-based services
• Describe Lawful Intercept functional elements
• List Self Organizing Network features
2010
Version 2 Rev 4 Quality of Service (QoS)
Quality of Service (QoS)

QoS describes managing the congestion of resources that are insufficient to support all possible traffic
loads. Under those conditions, higher priority traffic/users will have more access to network resources
than lower priority traffic. QoS processes manage the traffic load within the available resources and
adjust the traffic load when congestion occurs.
There are four aspects to managing congestion that QoS addresses:
1. QoS Service Establishment determines whether the user is authorized to have the requested QoS,
and establishes or reconfigures a service data flow to provide that QoS.
2. Admission Control determines if a Guaranteed Bit Rate (GBR) traffic flow can be granted its
requested QoS without affecting existing flows. Admission control will apply to requests to obtain
resources to support a subscriber’s GBR service request (i.e. a service data flow). Admission
control will apply to new traffic, hand-in traffic, and reactivation of the UE. In some cases it applies
when a network element reaches a maximum limit of such items as S-TMSIs, number of sessions
supported, number of flows supported, etc. QoS attributes and QoS policies will be used as part
of the admission control function. Pre-emption is supported, based on QoS at-tributes. Admission
control will not be used for the non-GBR bearer, common control and access channels. Also
referred to as Resource Allocation.
3. Congestion Control monitors real time utilization of resources, detects if resource utilization exceeds
a threshold, takes actions to bring utilization back within threshold, detects that utilization is within
threshold, and removes any actions taken to reduce utilization. Congestion control can occur when
available resources are reduced due to faults or OAMP reasons, or due to failure of the Admission
Control process to prevent over-utilization of resources. Congestion control will also be applied in
some cases to transaction management, i.e. for example a network element exceeds the maximum
number of transactions it is allowed to handle, or the maximum number of transactions it is allowed
to handle within a certain time. Congestion control may include pre-emption. Packet discard due
to congestion is considered part of Traffic Conditioning.
4. Traffic Conditioning deals with the dynamic processing of the individual packets, including packet
scheduling, traffic rate policing/shaping, and packet dropping. Packet scheduling puts higher
priority packets onto the physical interface first. Traffic rate policing/shaping ensures that users
do not exceed their maximum bit rates. Packet dropping discards packets when resources are
exceeded.
2010
QoS Functional Architecture Version 2 Rev 4
QoS Functional Architecture

The QoS Architecture for the LTE End-to-End bearer traffic is shown below.
Figure 9-2 QoS Functional Architecture
2010
Version 2 Rev 4 Bearer Protocol Stack
Bearer Protocol Stack
Figure 9-3 UE to P-GW User Plane
The graphic illustrates the user plane between the UE and the P-GW, including the Uu, S1-U, and S5-U
interfaces. Note that the P-GW extracts the original user traffic (Layer 3-5) from the GTP mobility tunnel.
The resulting packet may be forwarded based on the user-supplied destination IP address, or placed in
another GTP or Mobile IP tunnel and forwarded to another network. In the latter case, the P-GW will
interwork the two mobility tunnels.
2010
Packet Forwarding and QoS Functions Version 2 Rev 4
Packet Forwarding and QoS Functions
Figure 9-4 Packet Forwarding Functions
2010
Version 2 Rev 4 Quality of Service (QoS) / EPS Bearer
Quality of Service (QoS) / EPS Bearer
Figure 9-5 Quality of Service (QoS) / EPS Bearer
The EPS bearer is a logical connection between the UE and the P-GW. One EPS default bearer is
established when the UE connects to a PDN, and that remains established throughout the lifetime of
the PDN connection to provide the UE with always-on IP connectivity to that PDN. Any additional EPS
bearer that is established to the same PDN is referred to as a dedicated bearer. The initial bearer level
QoS parameter values of the default bearer are assigned by the network, based on subscription data.
The decision to establish or modify a dedicated bearer can only be taken by the EPC, and the bearer
level QoS parameter values are always assigned by the EPC.
An EPS bearer consists of the following elements:
S5 Bearer – a tunnel which transports packets between the S-GW and P-GW
S1 Bearer – a tunnel which transports packets between the S-GW and eNodeB
Radio Bearer – established by an RLC connection between the eNodeB and the UE (one RLC per Radio
Bearer)
2010
Version 2 Rev 4 Quality of Service (QoS) / EPS Bearer
2010
Version 2 Rev 4 End-to-End Bearer Service Architecture
End-to-End Bearer Service Architecture
Figure 9-6 Bearer Service Architecture
A data flow transported by the EPS bearer is known as a Service Data Flow (SDF). Each SDF identifies
both termination points as well as the service being used. An SDF could be a connection to a web server,
streaming video server, etc.
• An UL Traffic Flow Template (TFT) in the UE binds an SDF to an EPS bearer in the uplink direction.
Multiple SDFs can be multiplexed onto the same EPS bearer by including multiple uplink packet
filters in the UL TFT.
• A DL TFT in the P-GW binds an SDF to an EPS bearer in the downlink direction. Multiple SDFs
can be multiplexed onto the same EPS bearer by including multiple downlink packet filters in the
DL TFT.
• A Radio Bearer transports the packets of an EPS bearer between a UE and eNodeB. There is a
one-to-one mapping between an EPS bearer and a Radio Bearer.
• An S1 bearer transports the packets of an EPS bearer between an eNodeB and a S-GW.
• An S5/S8 bearer transports the packets of an EPS bearer between an S-GW and a P-GW.
• A UE stores a mapping between a UL packet filter and a Radio Bearer.
• A P-GW stores a mapping between a DL packet filter and an S5 bearer.
• An eNodeB stores a one-to-one mapping between a radio bearer and an S1 bearer.
• An S-GW stores a one-to-one mapping between an S1 bearer and an S5 bearer.
2010
QoS Parameters Version 2 Rev 4
QoS Parameters
Figure 9-7 QoS Parameters
The bearer level (i.e. per bearer or per bearer aggregate) QoS parameters are QoS Class Identifier
(QCI), Allocation and Retention Priority (ARP), Guaranteed Bit Rate (GBR), and Aggregate
Maximum Bit Rate (AMBR). Each EPS bearer is associated with the following bearer level QoS
parameters:
QoS Class Identifier – used as a reference to access node-specific parameters that control bearer
level packet forwarding treatment (e.g. scheduling weights, admission thresholds, queue management
thresholds, link layer protocol configuration, etc.), and that have been pre-configured by the operator
owning the eNodeB.
Allocation and Retention Priority – the primary purpose of ARP is to decide whether a bearer
establishment / modification request can be accepted or needs to be rejected in case of resource
limitations. In addition, the ARP can be used by the eNodeB to decide which bearer(s) to drop during
exceptional resource limitations (e.g. at handover).
Guaranteed Bit Rate – applicable to bearers which require guaranteed QoS for services such as VoIP
and streaming video.
Maximum Bit Rate (MBR) – maximum amount of bandwidth a GBR flow can use.
Aggregate Maximum Bit Rate – denotes a bit rate of traffic per group of bearers and applies to only
non-guaranteed bit rate bearers. The AMBR limits the overall bit rate of all bearers associated with the
limit for a given Packet Data Network.
2010
Version 2 Rev 4 Traffic Categories
Traffic Categories
The traffic is divided into three types: QoS managed bearer traffic that is admission controlled (GBR),
unmanaged bearer traffic which is not admission controlled (non-GBR), and unmanaged non-bearer
traffic. Admission control, along with congestion control, is responsible for keeping the applied QoS
traffic load within the available amount of resources. The traffic conditioning will deal with any QoS
managed traffic packets that exceed the available resources.
While unmanaged non-GBR and non-bearer traffic is not admission controlled, they have their QoS
managed by the traffic conditioning functionality. The unmanaged traffic load may be larger than the
available bandwidth. Traffic conditioning will drop the excess unmanaged packets so that the unmanaged
traffic fits within the available resources. Unmanaged traffic is typically TCP based and TCP will throttle
back its transmission rate when there is congestion (i.e. packet drops). This results in the unmanaged
traffic load coming into relative balance with the available resources. For UDP based unmanaged traffic
the application will need to be able to deal with the packet loss. Within the unmanaged traffic there will
be different levels of priority applied by the traffic conditioning so that the different types of traffic have
different probabilities of being dropped when congestion occurs.
Figure 9-8 Traffic Categories
2010
Selected EPS Services Version 2 Rev 4
Selected EPS Services

• Broadband Data
• VoIP
• Video and Video on Demand
• Push-to-Talk
• Lawful Intercept
• Self Organizing Network
Basic Broadband
The Basic Broadband service introduces the EPC and EUTRAN infrastructure and provides system
initialization and basic services to allow a device to access the system and send and receive data.
The service includes the eNodeB base station platform, the MME control platform, the SGW/PDN GW
bearer platform and reuses the MotoManager platform for OAMP services.
This service includes an integrated and tested EUTRAN/EPC solution that also includes HSS, AAA,
DHCP and DNS in addition to the Motorola provided components.
VoIP
This service introduces Voice over Internet Protocol (VoIP) service on the LTE Network. This service
is intended to provide trials for the following types of sessions:
• Mobile to Mobile
• Mobile to Land
This service assumes that default bearer support is provided by the LTE Basic Broadband service and
that dedicated bearer support is provided by the Basic Admission Control service. It is assumed a Voice
Application server is located in the IMS portion of the network to support VoIP calls.
Video On Demand
This service allows the user to subscribe to VOD services, and then download over a unicast connection
from the operator’s network either stored or real-time (linear TV) multimedia content. The operator
provides a means to access a guide to content that the user may access - this may be downloaded from
the operator’s network via the SGi interface to the user. The user may subscribe to the VOD service
through wired or wireless means. Requested content may be streamed or downloaded to the user.
Push To Talk (PTT)

Push To Talk (PTT) service supports the familiar “walkie-talkie” type half-duplex audio calls between two
or more users. PTT is also called PTT over Cellular (PoC).
Basic Lawful Intercept

The Basic Lawful Intercept service allows government authorities to monitor the communications
of individuals after a warrant is obtained. Although the regulations are country specific, in general,
authorities can monitor signaling information (e.g., Attach messages, etc.) and communication content
(i.e., the bearer, be it voice or data).
This service provides lawful intercept capabilities according to the anticipated 3GPP lawful intercept
architecture for LTE from EPC network components (i.e. the MME, Serving Gateway, PDN Gateway and
HSS) and by addition of a Packet Lawful Intercept Gateway (P-LIG). Intercept of all communication
is provided (i.e., voice and data). Basic location (e.g., cell) is provided. Intercept of Multicast is not
provided.
2010
Version 2 Rev 4 Selected EPS Services
Selected EPS Services
Self Organizing Network (SON)

A Self-Organizing Network (SON) is a network that can automatically extend, change, configure, and
optimize its topology, coverage, capacity, cell size, and channel allocation based on changes in location,
traffic pattern, interference, and the situation/environment. LTE promises significant cost savings using
SON techniques.
2010
IP Multimedia Subsystem (IMS) Version 2 Rev 4
IP Multimedia Subsystem (IMS)

• Introduced in UMTS R5, enhanced in R6 and R7
• Core service architecture for UMTS, CDMA, Cable, DSL access networks
• Performs multimedia call control
• Interworks signaling and voice traffic with PSTN
• Application services include:
•
– Voice or Video over IP
– Push-to-Talk (PTT)
– Video/Audio Conferencing
– Instant Messaging
– Location and Presence-based Services
– “Buddy” Lists
Introduced in UMTS Release 5, the IP Multimedia Subsystem (IMS) was further defined in UMTS
Releases 6 and 7. IMS was designed to replace the call control and interworking functions of the CS
domain with a more flexible, packet-based, multimedia core service architecture. Although originally
defined by the 3GPP for UMTS networks, IMS has been adopted as the core multimedia service
architecture for CDMA, packet cable, DSL, and WiFi access networks.
IMS allows new services to be rapidly and cheaply deployed. Some examples of IMS application services
are listed above.
The graphic on the next page shows an extremely simplified IMS

architecture.
Simplified IMS Architecture
Figure 9-9 Simplified IMS Architecture
2010
Version 2 Rev 4 IP Multimedia Subsystem (IMS)
Serving Call Session Control Function (S-CSCF)

The S-CSCF provides the call control logic for setting up and maintaining multimedia sessions. The
S-CSCF is located in the UE’s home network, and provides home-based service control for subscribed
services.
Proxy Call Session Control Function (P-CSCF)

The P-CSCF forwards session control signaling to the appropriate S-CSCF, handles initial IMS
authentication and authorization, maintains an IPsec association with the UE, and participates in
resource authorization and QoS management. A P-CSCF may be located in both home and visited
networks.
Media Gateway Control Function (MGCF)

The MGCF provides the control logic for one or more media gateways, and interworks SIP and SS7
signaling.
Media Gateway (MGW)

A MGW interworks voice over IP bearer packets with PSTN G.711 voice flows. The MGW may also
support ISDN video conferencing.
Application Servers
Application servers offer services beyond basic call control, including video or audio conferencing, PTT
service, presence-based service, instant messaging interworking, and so on.
IMS Signaling and Bearer Flows
Figure 9-10 IMS Signaling and Bearer Flows
2010
IP Multimedia Subsystem (IMS) Version 2 Rev 4
Signaling Flow
IMS uses the IETF Session Initiation Protocol(SIP) and Session Description Protocol (SDP) to set
up and tear down calls. The UE uses SIP to register with the IMS, initiate multimedia calls, and subscribe
to various IMS services. Most IMS elements are specialized SIP servers.
The MGCF interworks SIP and SS7 signaling. SS7 is widely used for signaling in the PSTN. In addition,
the MGCF uses the Media Gateway Control Protocol (MEGACO) to control the MGW.
VoIP to PSTN Bearer Flow

For voice or video conferencing calls which terminate in the PSTN, voice bearer packets are routed to
an MGW. The MGW interworks the voice packets with uncompressed G.711 PCM voice streams.
VoIP to IP Device, Data, Other Flow

For voice or video streams which terminate in an IP device, the IMS is strictly used for call setup and call
management. Other data flows such as HTTP or FTP will completely bypass the IMS.
2010
Version 2 Rev 4 Multimedia Broadcast/Multicast Service (MBMS)
Multimedia Broadcast/Multicast Service (MBMS)

• Introduced in UMTS R6
• Broadcast traffic is sent to everyone
• Multicast traffic is subscription-based
• Possible MBMS applications include:
– Audio/Video Streaming (“Online”)
– Audio/Video Downloading (‘Offline”)
– File Downloading
– Text/Image
The Multimedia Broadcast/Multicast Service (MBMS) was introduced in UMTS Release 6 and further
defined in Release 8. MBMS offers broadcast and/or multicast, unidirectional, point-to-multipoint,
multimedia flows.
Broadcast and multicast are two completely different services. A broadcast service is transmitted to all
user devices which have the service activated in their equipment. A service provider does not attempt
to charge for or limit the broadcast transmission.
In contrast, a multicast service is subscription-based. A UE must have subscribed to the service and
explicitly joined the multicast group to receive the multicast transmission.
A service provider may track, control, and charge for the multicast transmission.
Some examples of possible MBMS applications are listed above.
MBMS Functional Elements
Figure 9-11 MBMS Functional Elements
2010
Multimedia Broadcast/Multicast Service (MBMS) Version 2 Rev 4
Multimedia Broadcast/Multicast Service (MBMS)
Content Provider
The content provider is the broadcast or multicast source, for example, a video server.
Broadcast Multicast Service Center (BM CS)

The Broadcast Multicast Service Center (BMSC) is responsible for authorizing user devices attempting
to activate an MBMS service, scheduling and transmission of broadcast/multicast traffic, announcing
services, and securing MBMS data.
MBMS GW
The MBMS Gateway is responsible for transmitting broadcast/multicast packets to the eNodeBs, starting
and stopping sessions, and collecting charging information for multicast service.
Multicell/Multicast Coordination Entity (MCE)

The MCE does the actual scheduling of radio resources when multiple cells are involved. This function
could be integrated into the eNodeB.
2010
Version 2 Rev 4 Lawful Intercept
Lawful Intercept
Lawful Intercept is controlled by a Packet-Lawful Intercept Gateway (P-LIG). The P-LIG interfaces with
EPS network elements and with a Law Enforcement Monitoring Facility (LEMF). When a target is being
surveilled by multiple LEMFs, the P-LIG ensures that each LEMF receives the intercepted information.
All interception is performed in the MME, S-GW, P-GW, and HSS.
P-LIG
The P-LIG provides the interface between the EPS network elements and the LEMFs of the different
Law Enforcement Agencies (LEA).
The P-LIG controls the provisioning of interceptions. In general, an intercept will be provisioned to report
signaling information, or both signaling and user plane (voice, video, data) traffic.
The P-LIG receives the intercepted traffic and forwards the data to the LEMFs.
MME
The MME intercepts signaling information only. The MME reports data for the following events: Attach;
Detach; Tracking Area Update; and UE-requested PDN connectivity.
S-GW
The S-GW intercepts signaling and user plane traffic. S-GW reports data for the following events: Bearer
Activation; Bearer Modification; Bearer Deactivation; Start of Intercept while a bearer is active; reception
of data packets to and from the UE.
P-GW
The P-GW intercepts signaling and user plane traffic. The P-GW reports data for the following events:
Bearer Activation; Start of Intercept while a bearer is active; Bearer Modification; Bearer Deactivation;
reception of data packets to and from the UE.
HSS
The HSS reports serving system information for a UE.
2010
Lawful Intercept Version 2 Rev 4
Lawful Intercept
P-LIG Functions and Interfaces
Figure 9-12 P-LIG Functions and Interfaces
The P-LIG consists of three major logical functions: the Administrative Function (ADMF), Delivery
Function 2 (DF2), and Delivery Function 3 (DF3).
Administrative Function (ADMF)

The ADMF receives monitoring instructions from the LEMF and instructs the HSS, MME, S-GW, and
P-GW to set up or stop the intercept. The X1 interfaces connect the ADMF and the EPS network
elements.
Delivery Function 2 (DF2)

The DF2 captures signaling and other related intercept information via the X2 interfaces. The signaling
is forwarded to the monitoring LEMF(s).
Delivery Function 3 (DF3)

The DF3 captures user plane traffic from the S-GW and P-GW over the X3 interfaces. The traffic is
forwarded to the monitoring LEMF(s).
2010
Version 2 Rev 4 Self-Organizing Network (SON)
Self-Organizing Network (SON)

A SON is a network that can automatically extend, change, configure, and optimize its topology,
coverage, capacity, cell size, and channel allocation based on changes in location, traffic pattern,
interference, and the situation/environment.
• Purpose
– Reduce operational costs
• Focus Areas
– Self-installation and self-configuration
– Self-operating
– Self-optimization
– Operator controls the behavior of the SON instead of controlling detail and fixed parameters
◊ The operator provides boundaries for neighbor auto-discovery by controlling which
neighbor must be included or not included, and allowing the system to discover the rest
Self-configuring, self-optimizing wireless networks concepts are not new. As operators and standards
bodies move towards next generation networks, the ability to automate network management has
become an important requirement.
The objective is to minimize the cost of running a network by eliminating manual configuration – using
expensive dedicated resources – of equipment at the time of deployment as well as dynamically
optimizing radio network performance during operation.
2010
Self-Organizing Network (SON) Version 2 Rev 4
Motorola SON Architecture
Figure 9-13 Motorola SON Architecture
• Automated generation of RF / transport / QoS

plan, with import/export capability
• Centralized optimization based on statistical
analysis
• Tracking area selection
• Initial configuration
• Centralized policy management

• Distributed SON review and commit (establishing
trust mode)
• Full tracking of locally applied SON changes
• Fallback
• Distributed policy management

• Automatic neighbors
• Inter-cell interference coordination
• Auto allocation of resources
• Self-analysis and healing
• Locally applied optimization algorithms
• Locally administered power management
• Plug 'n Play (auto discovery), full inventory
reporting
The Motorola SON architecture places little responsibility of the SON functionality at the EMS layer.
When combined with the intelligence and autonomous nature of the Motorola NE’s, this design creates
an EMS layer upon which there is little dependence for vital, daily operations.
The Motorola LTE Manager provides support for operators related to the networks SON functions such
as, SON enable/disable controls, verification of SON optimization recommendations (establishing trust),
and full tracking of all manual and automated configuration changes. The LTE Manager also provides
NE software management including automated software upgrade and activation. The Motorola SON
architecture also provides for a centralized SON function to support optimization and configuration
capabilities required which span across the network or multiple NE types.
2010
Version 2 Rev 4 Self-Organizing Network (SON)
Proposed Motorola SON Features
Basic Auto Operations

○ Autonomous Inventory, auto detection, test and configuration of hardware on insert
► Near Real-Time performance management reporting
○ Automatic EMS software upgrade
○ Automatic network element software upgrade
○ Dynamic configuration of signaling links
► Automatic generation of radio, handover configuration parameters
○ Auto backup and restore
Advanced Auto Operations

► Resource outage detection and action
► Outage compensation
► Smart re-configuration
Basic Deployment
○ Auto-detect PnP hardware, auto-authenticate
○ Auto inventory
○ On connection to EMS, auto-software upgrade
○ Auto RF/Transport configuration update
○ Self discovery of new NE resources
Advanced Deployment
► Auto-test network element
► Auto-compute antenna loss at eNodeB
Interference Coordination and Control

► Exchange of metrics over 2 interface to enable coordination of determining edge
of cell Physical Radio Resource Blocks
► Motorola enhanced algorithm
Automatic Neighbor Relationships

○ eNodeB discovers new neighbors (eNodeB directed UE measurements), deletes
stale neighbors
○ Operator control of on-demand, periodic, white/black list
○ Dynamic configuration of X2 signaling link
Subscriber Trace Support

○ Network element support for trace on per-subscriber identity (IMSI) and per-equipment
identity (IMEI) basis
Key
2010
Self-Organizing Network (SON) Version 2 Rev 4

○ Auto-test network element
► Future or multi-phase features
2010
Lesson Summary
• QoS in LTE
• LTE-Based Services
2010
Memory Points
2010
2010
Inter-Technology Mobility Version 2 Rev 4
Chapter 10
Inter-Technology Mobility
2010
Version 2 Rev 4 Inter-Technology Mobility
2010
Chapter 10 Objectives Version 2 Rev 4
Chapter 10 Objectives
On completion of this chapter the student will be able to:
• Describe how LTE provides inter-working to GSM, UMTS and CDMA networks
• Differentiate the measurements needed for the E-UTRAN to choose a suitable network based on
coverage, service or subscription
• Describe the interfaces that allow inter-working to GSM, UMTS and CDMA
• Determine from examples why the UE would select another network in idle mode
• Recognize from call flows the message content necessary for successful completion of a handover
to GSM, UMTS and CDMA
2010
Version 2 Rev 4 3GPP/3GPP2 Specifications Referenced
3GPP/3GPP2 Specifications Referenced

3GPP TS 36.304 V8.6.0 (2009 – 06) — UE procedures in idle mode
3GPP TS 23.216 V8.4.0 (2009 – 06) — Single Radio Voice Call Continuity (SRVCC)
3GPP TS 23.272 V8.4.0 (2009 – 06) — Switched Fallback in EPS
3GPP TS 23.401 V8.6.0 (2009 – 06) — GPRS enhancements for E-UTRAN access
3GPP TS 23.402 V8.6.0 (2009 – 06) — Architecture enhancements for non-3GPP accesses
3GPP TS 36.214 V8.6.0 (2009 – 6) — Physical layer – Measurements
3GPP TS 36.331 V8.6.0 (2009 – 06) — Radio Resource Control
2010
What is Inter-RAT/Technology Mobility and Why is it Needed? Version 2 Rev 4
What is Inter-RAT/Technology Mobility and Why is it Needed?
Figure 10-1 Inter-Technology Mobility
Simply put, inter-technology mobility is the ability to support movement of a device between differing
radio access network types. There are many variations of this definition. In particular, the LTE standards
body, 3GPP, defines two:
• Inter-RAT (Radio Access Technology) mobility, which refers to mobility between LTE and earlier
3GPP technologies
• Inter-Technology mobility which refers to mobility between LTE and non-3GPP technologies
Inter-technology mobility can be supported in a variety of ways. The most basic form of inter-technology
mobility can be provided by a multi-technology device without any inter-technology support from the
operator’s network(s). In this case, the user or the device selects which technology to use and initiates
access to that technology. For many applications this is unacceptable as the user would have to
reestablish the data session from the original RAT to the new one. Therefore procedures have been
defined for 3GPP and non-3GPP mobility to provide a seamless transfer of a data session. In this
lesson we shall investigate some of the strategies defined.
A fundamental user requirement for LTE deployments is that users expect the new network to provide not
only exciting new services but also to support all the services from the legacy network. Also, operators
want to leverage their existing coverage and existing investments in applications and services to support
their broadband subscribers. Inter-technology mobility is an important tool for meeting these needs.
Cell Selection and Reselection in Idle Mode

Procedures are defined for:
• Initial cell selection
• Cell Reselection to (and from):
– E-UTRAN Cells
– UTRAN Cells
– GERAN Cells
– cdma2000 HRPD Cells
– cdma2000 1xRTT Cells
2010
Version 2 Rev 4 What is Inter-RAT/Technology Mobility and Why is it Needed?
What is Inter-RAT/Technology Mobility and Why is it Needed?
Mobility in Connected Mode

Procedures are defined for:
• Inter RAT Handovers:
– E-UTRAN to UTRAN Iu mode
– UTRAN Iu mode to E-UTRAN
– E-UTRAN to GERAN A/Gb mode Inter RAT
– GERAN A/Gb mode to E-UTRAN Inter RAT
– Circuit Switched Fallback for UTRAN/GERAN
• Inter-Technology Handovers:
– Non-Optimized Handover to cdma2000 HRPD Access
– Optimized Active Handover: E-UTRAN Access to cdma2000 HRPD Access
– Optimized Active Handover: cdma2000 HRPD Access to E-UTRAN
SRVCC Procedure for 1xRTT
Note: Only a subset of procedures is described in this lesson.
2010
Version 2 Rev 4 What is Inter-RAT/Technology Mobility and Why is it Needed?
2010
Version 2 Rev 4 Inter-RAT Mobility States Overview
Inter-RAT Mobility States Overview

This section of the lesson allows us to review the E-UTRA states for both 3GPP and 3GPP2.
Figure 10-2 E-UTRA States and Mobility 3GPP
Connected
Handover Handover
E-UTRA
CELL_DCH RRC_CONNECTED
GSM_CONNECTED
GPRS Packet
CELL_FACH CCO Transfer Mode
with
NACC
CELL_PCH
CCO,
URA_PCH Reselection
Reselection
Connection Connection
Connection Establishment/Release Establishment/Release
Establishment/Release
Reselection
Reselection
E-UTRA GSM_Idle/GPRS
UTRA_Idle RRC_IDLE Packet_Idle
CCO, Reselection
UTRA E-UTRA GSM
E-UTRA states and inter RAT mobility procedures, 3GPP

The following figure not only provides an overview of the RRC states in E-UTRA, but also illustrates the
mobility support between E-UTRAN, UTRAN and GERAN.
UTRA States
In the UTRA_Idle state the UE has no uplink connection with the NodeB and can only decode system
information and respond to paging messages. If data needs to be transmitted in both directions, the
state will either change to CELL_DCH or CELL_FACH. CELL_DCH means the resources allocated are
dedicated to one UE. However another state exists if the UE is utilizing HSPA. Namely CELL_DCH with
HS. In this state the UE is using a HSPA channel and is sharing a code with other UEs. If the UE is in
CELL_FACH state it means the UE is using common channels to transfer data. This state is used when
only small amounts of data need to be transferred. If no data is transferred for a period of time then
the UE will transition into CELL_PCH state. In this state the UE maintains a logical connection with the
NodeB i.e. a C-RNTI for the UE is stored. If data needs to be transferred a relatively short connection
setup time is needed. However if the UE reselects to another cell a Cell Update procedure is required to
update the C-RNTI for the new cell. To do this the UE must transition to CELL_FACH or CELL_DCH to
pass the necessary signalling. If a high number of reselections takes place within a defined time period
the UE will transition to URA_PCH. A URA is a group of cells that are configured in the RNC database to
reduce the amount of signalling needed due to a high number of cell reselections triggering Cell Update
procedures.
GSM States
The GSM_Idle state is defined for CS traffic, in this state the UE monitors DL system information from
the CS network and CS paging. The GPRS Packet Idle state is for the PS network, therefore the UE will
monitor DL system information for the PS network and PS paging. If the UE needs to move onto a TCH
for a CS call it transitions to GSM_Connected state and if a PS call is needed then the UE transitions to
GPRS Packet Transfer Mode.
2010
Inter-RAT Mobility States Overview Version 2 Rev 4
Inter-RAT Mobility States Overview
Mobility procedures between E-UTRA and cdma2000

The following figure illustrates the mobility support between E-UTRAN, cdma2000 1xRTT and cdma2000
HRPD.
Figure 10-3 E-UTRA States and Mobility 3GPP
Handover Handover
1xRTT CS E-UTRA
RRC_CONNECTED
HRPD Active
Active
Connection
Establishment/Release
Reselection Reselection
1xRTT E-UTRA
RRC_IDLE HRPD Dormant
Dormant
E-UTRA
1xRTT
Radio Transmission Technology (1xRTT) is a high-speed broadband technology based on the CDMA
platform. 1xRTT has the capability of providing broadband-like speeds of up to 144 kbps. 1xRTT is also
referred to as cdma2000, 1xRTT is the circuit switched version of the standard.
1xRTT Dormant state is when a Point-to-Point Protocol (PPP) connection is maintained without actively
using a traffic channel on the network, and the traffic channel can be allocated to other users on the
network.
1xEVDO
EVolution, Data-Optimized (1xEVDO) is a 3G digital broadband standard. 1xEVDO is based on a
technology initially known as High Data Rate (HDR) or High Rate Packet Data (HRPD), developed
by Qualcomm. The international standard is known as IS-856. 1xEVDO has the capability of providing
broadband-like performance at speeds averaging 300-600 kbps.
2010
Version 2 Rev 4 Inter-RAT Handover
Inter-RAT Handover
During Inter RAT handover indirect forwarding may apply for the data forwarding performed as part of
the handover. From its configuration data the MME knows whether indirect forwarding applies and it
allocates a data forwarding path on a S-GWs for indirect forwarding. From its configuration data the S4
SGSN knows whether indirect forwarding applies and it allocates data forwarding paths on S-GWs for
indirect forwarding. It is configured on MME and S4 SGSN whether indirect forwarding does not apply,
applies always or applies only for inter PLMN inter RAT handovers.
E-UTRAN to UTRAN Iu mode Inter RAT handover

The precondition for this handover to occur is that the UE is in ECM-CONNECTED state.
Note: In this description direct forwarding of data is assumed and the other RAT is within the same PLMN.
If indirect forwarding and handover to another PLMN is described, additional signalling would apply for
details go to 23.401.
Preparation Phase
Figure 10-4 E-UTRAN to UTRAN Iu mode Inter RAT handover 1
Bearer(s) have been established between the UE and source eNodeB and GTP tunnel(s) between the
source eNodeB, S-GW and P-GW. The stages of the preparation phase are listed in numbered order
and relate to the figure:
1. The source eNodeB has initiated a handover based on, for example the delivery of an event and/or
measurement report(s) from the UE and has targeted an Inter-RAT 3G neighbor cell within the
same PLMN.
2. The source eNodeB sends a Handover Required message to the source MME to request the CN
to establish resources in the target RNC, target SGSN and the S-GW.
3. The source MME determines that the handover is Inter-RAT to 3G and initiates a handover resource
allocation procedure by sending a Forward Relocation Request.
4. The target SGSN determines whether the S-GW needs to be relocated (PLMN change is an
example for this). In this example S-GW change is not needed. The target SGSN requests the
target RNC to establish radio network resources (RABs) by sending the Relocation Request.
5. The target RNC allocates the resources and returns the applicable parameters to the target SGSN
in the message Relocation Request Acknowledge. The target RNC shall be prepared to receive
2010
Inter-RAT Handover Version 2 Rev 4
Inter-RAT Handover
downlink GTP PDUs from the S-GW, or target SGSN in case direct tunnel is not used, for the
accepted RABs.
6. The target SGSN sends the message Forward Relocation Response to the source MME.
Execution Phase
The source eNodeB continues to receive downlink and uplink user plane PDUs. The stages of the
execution phase are listed in numbered order and relate to the figure:
1. The source MME completes the preparation phase towards the source eNodeB by sending the
message Handover Command.
2. The source eNodeB will give a command to the UE to handover to the target access network via the
message HO from E-UTRAN Command. This message includes a transparent container including
radio aspect parameters that the target RNC has setup in the preparation phase. The UE will
associates the bearer IDs to the respective RABs based on the relation with the Network Service
Access Point Identifier (NSAPI) and will suspend uplink transmission of user plane data.
3. The UE moves to the target UTRAN Iu (3G) system and executes the handover according to the
parameters provided in the message in step 2. The procedure is the same as for intra-system 3G
2010
Inter-RAT Handover
handover with the additional function of association of the received RABs and existing bearer id
related to the particular NSAPI.
The UE may resume the user data transfer only for those NSAPIs for which there are radio
resources allocated in the target RNC.
4. When the new source RNC-ID + S-RNTI are successfully exchanged with the UE, the target RNC
will send the Relocation Complete message to the target SGSN. The purpose of the Relocation
Complete procedure is to indicate by the target RNC the completion of the relocation from the
source E-UTRAN to the RNC. After the reception of the Relocation Complete message the target
SGSN shall be prepared to receive data from the target RNC, if direct forwarding isn't used.
5. The target SGSN knows that the UE has arrived at the target side and the target SGSN informs
the source MME by sending the Forward Relocation Complete Notification (ISR Activated, S-GW
change) message. A timer in source MME is started to supervise when resources in Source eNodeB
and Source S-GW (for S-GW relocation) shall be released.
6. The target SGSN will now complete the handover procedure by informing the S-GW (for S-GW
relocation this will be the Target S-GW) that the target SGSN is now responsible for all the EPS
Bearer Contexts the UE has established. This is performed in the message Modify Bearer Request.
The SGSN releases the non-accepted EPS Bearer contexts by triggering the Bearer Context
deactivation procedure. If the S-GW receives a DL packet for a non-accepted bearer, the S-GW
drops the DL packet and does not send a Downlink Data Notification to the SGSN.
7. The S-GW (for S-GW relocation this will be the Target S-GW) may inform the P-GW(s) the change
of for example for S-GW relocation or the RAT type that e.g. can be used for charging, by sending
the message Modify Bearer Request. The P-GW must acknowledge the request with the message
Modify Bearer Response. In the case of S-GW relocation, the P-GW updates its context field and
returns a Modify Bearer Response message to the S-GW. The MSISDN is included if the P-GW
has it stored in its UE context.
If PCC infrastructure is used, the P-GW informs the PCRF about the change of, for example, the
RAT type.
8. The S-GW (for S-GW relocation this will be the Target S-GW) acknowledges the user plane switch
to the target SGSN via the message Modify Bearer Response. At this stage the user plane path is
2010
Inter-RAT Handover
established for all EPS Bearer contexts between the UE, target RNC or target SGSN in case Direct
Tunnel is not used, S-GW (for S-GW relocation this will be the Target S-GW) and P-GW.
If the S-GW does not change, the S-GW shall send one or more "end marker" packets on the old
path immediately after switching the path.
9. When the UE recognizes that its current Routing Area is not registered with the network, or when
the UE's TIN indicates "GUTI", the UE initiates a Routing Area Update procedure with the target
SGSN informing it that the UE is located in a new routing area. It is RAN functionality to provide
the PMM-CONNECTED UE with Routing Area information.
10. When the timer started at step 5 expires, the source MME sends a Release Resources message
to the Source eNodeB. The Source eNodeB releases its resources related to the UE.
2010
Inter-RAT Handover
E-UTRAN to GERAN A/Gb Mode Inter RAT Handover

The preconditions are that the UE is in ECM-CONNECTED state and the BSS supports Packet Flow
Management (PFM).
Preparation Phase
Figure 10-8 E-UTRAN to GERAN A/Gb Mode Inter RAT Handover 1
Bearer(s) have been established between the UE and source eNodeB and GTP tunnel(s) between the
source eNodeB, S-GW and P-GW. The stages of the preparation phase are listed in numbered order
and relate to the figure:
1. The source eNodeB has initiated a handover based on, for example the delivery of an event and/or
measurement report(s) from the UE and has targeted an Inter-RAT 2G neighbor cell within the
same PLMN.
2. The source eNodeB sends a Handover Required message to the source MME to request the CN
to establish resources in the target BSS, target SGSN and the S-GW.
3. The source MME determines that the handover is Inter-RAT to 3G and initiates a handover resource
allocation procedure by sending a Forward Relocation Request.
4. The target SGSN establishes the EPS Bearer context(s) in the indicated order. The SGSN
deactivates the EPS Bearer contexts which cannot be established. The Target SGSN requests the
Target BSS to establish the necessary resources (PFCs) by sending the message PS Handover
Request.
5. The Target BSS allocates the requested resources and returns the applicable parameters to
the Target SGSN in the message PS Handover Request Acknowledge. Upon sending the PS
Handover Request Acknowledge message the target BSS is prepared to receive downlink Logical
Link Control (LLC) PDUs from the target SGSN for the accepted Packet Flow Contexts (PFCs).
6. The target SGSN sends the message Forward Relocation Response to the source MME.
2010
Inter-RAT Handover
Execution Phase
The source eNodeB continues to receive downlink and uplink user plane PDUs. The stages of the
execution phase are listed in numbered order and relate to the figure:
1. The source MME completes the preparation phase towards the source eNodeB by sending the
message Handover Command.
2. The source eNodeB will give a command to the UE to handover to the target access network via the
message HO from E-UTRAN Command. This message includes a transparent container including
radio aspect parameters that the target RNC has setup in the preparation phase. The UE will
associates the bearer IDs to the respective RABs based on the relation with the Network Service
Access Point Identifier (NSAPI) and will suspend uplink transmission of user plane data.
3. The UE moves to the target GERAN A/Gb (2G) system and executes the handover according to
the parameters provided in the message in step 2. The procedure is the same as for intra-system
2G PS handover with the additional function of association of the received PFI and existing bearer
id related to the particular NSAPI.
4. After accessing the cell using access bursts and receiving timing advance information from the BSS
in step 3, the UE processes the NAS container and then sends one XID response message to the
target SGSN via target BSS. The UE sends this message immediately after receiving the Packet
2010
Inter-RAT Handover
Physical Information message containing the timing advance or, in the synchronized network case,
immediately if the PS Handover Access message is not required to be sent.
The UE may resume the user data transfer only for those NSAPIs for which there are radio
resources allocated in the target BSS.
5. Upon reception of the first correct RLC/MAC block (sent in normal burst format) from the UE to
the Target BSS, the Target BSS informs the Target SGSN by sending the message PS Handover
Complete.
6. The Target BSS also relays the message XID Response to the Target SGSN. Note, the message
in step 5 and 6 may arrive in any order in the Target SGSN.
7. The target SGSN knows that the UE has arrived at the target side and the target SGSN informs
the source MME by sending the Forward Relocation Complete Notification message. A timer in
source MME is started to supervise when resources in Source eNodeB and Source S-GW (for
S-GW relocation) shall be released.
2010
Inter-RAT Handover
8. The target SGSN will now complete the Handover procedure by informing the S-GW (for S-GW
relocation this will be the Target S-GW) that the target SGSN is now responsible for all the EPS
Bearer Contexts the UE has established. This is performed in the message Modify Bearer Request.
The SGSN releases the non-accepted EPS Bearer contexts by triggering the Bearer Context
deactivation procedure. If the S-GW receives a DL packet for a non-accepted bearer, the S-GW
drops the DL packet and does not send a Downlink Data Notification to the SGSN.
9. The S-GW (for S-GW relocation this will be the Target S-GW) may inform the P-GW(s) of the
change: for example S-GW relocation or the RAT type that can be used for charging, by sending
the message Modify Bearer Request. The P-GW must acknowledge the request with the message
Modify Bearer Response. In the case of S-GW relocation, the P-GW updates its context field and
returns a Modify Bearer Response message to the S-GW. The MSISDN is included if the P-GW
has it stored in its UE context.
If PCC infrastructure is used, the P-GW informs the PCRF about the change of, for example, the
RAT type.
10. The S-GW (for S-GW relocation this will be the Target S-GW) acknowledges the user plane switch
to the target SGSN via the message Modify Bearer Response. At this stage the user plane path is
established for all EPS Bearer contexts between the UE, target RNC or target SGSN in case Direct
Tunnel is not used, S-GW (for S-GW relocation this will be the Target S-GW) and P-GW.
If the S-GW does not change, the S-GW shall send one or more "end marker" packets on the old
path immediately after switching the path.
11. If the Target SGSN indicated XID Reset (i.e. reset to default XID parameters) in the NAS container
included in the HO from E-UTRAN Command message, then on receipt of the PS Handover
Complete the Target SGSN initiates an LLC/SNDCP XID negotiation for each LLC Service
Access Point Identifier (SAPI) used in LLC Asynchronous Disconnect Mode (ADM). In this
case if the Target SGSN wants to use the default XID parameters, it shall send an empty XID
Command. If the Target SGSN indicated 'Reset to the old XID parameters' in the NAS container,
no further XID negotiation is required for LLC SAPIs used in LLC ADM only.
11a — The Target SGSN (re-)establishes LLC Asynchronous Balanced Mode (ABM) for the
EPS Bearer contexts which use acknowledged information transfer. During the exchange of Set
Asynchronous Balanced Mode (SABM) and Unnumbered Acknowledgement (UA) the SGSN
will perform LLC/Sub-Network Dependant Convergence Protocol SNDCP XID negotiation.
12. After the UE has finished the reconfiguration procedure the UE shall initiate the Routing Area
Update procedure.
2010
Inter-RAT Handover
13. When the timer started at step 7 expires, the source MME sends a Release Resources message
to the source eNodeB. The Source eNodeB releases its resources related to the UE.
2010
Circuit Switch Fallback in EPS for 3GPP Version 2 Rev 4
Circuit Switch Fallback in EPS for 3GPP

The CS fallback in EPS enables the provisioning of voice and other CS-domain services by reuse of
CS infrastructure when the UE is served by E-UTRAN. A CS fallback enabled terminal, connected to
E-UTRAN may use GERAN or UTRAN to connect to the CS domain. This function is only available in
case E-UTRAN coverage is overlapped by either GERAN coverage or UTRAN coverage. Two additional
reference points are defined, SGs for mobility management/paging/SMS and S3 for support of ISR in CS
Fallback.
2010
Version 2 Rev 4 Circuit Switch Fallback in EPS for 3GPP
Functional Entities
Figure 10-12 CS Fallback Functional Overview
The entities shown in the figure must be enabled to support CS Fallback. The additional functionality
needed is described in the following sections.
UE
The CS fallback capable UE supports access to E-UTRAN/EPC as well as access to the CS-domain
over GERAN and/or UTRAN. It supports the following additional functions:
• Combined procedures for EPS/IMSI attach, update and detach.
• CS fallback and SMS procedures for using CS domain services.
MME
The CS fallback enabled MME supports the following additional functions:
• Deriving a VLR number and LAI from the GUTI received from the UE or from a default LAI.
• Maintaining of SGs association towards MSC/VLR for EPS/IMSI attached UE.
• Initiating IMSI detach at EPS detach.
• Initiating paging procedure towards the eNodeB when the MSC pages the UE for CS services.
• Supporting SMS procedures.
• Rejecting CS Fallback call request.
MSC
The CS fallback enabled MSC supports the following additional functions:
• Maintaining SGs association towards MME for EPS/IMSI attached UE.
• Supporting SMS procedures.
E-UTRAN
The CS fallback enabled E-UTRAN supports the following additional functions:
• Forwarding paging request and SMS to the UE.
• Directing the UE to the target CS capable cell.
2010

Mobility Management
The CS fallback in EPS is realized by using the SGs interface mechanism between the MSC Server and
the MME.
Mobility management includes:
• Attach procedure
• Detach procedures:
– UE Initiated
– MME Initiated
– HSS Initiated
• TA/LA Update procedures
– Combined TA/LA Update procedure
– Periodic TA and LA Update procedure.
Only the attach procedure is discussed here
Attach Procedure
Figure 10-13 CS Fallback Attach Procedure
The attach procedure for the CS fallback in EPS is realized based on the combined GPRS/IMSI Attach
procedure utilizing the Gs interface. This is specified in TS 23.060.
1. The UE initiates the attach procedure by the transmission of an Attach Request message to the
MME. The Attach Type indicates that the UE requests a combined EPS/IMSI attach and informs
the network that the UE is capable and configured to use CS fallback.
2. The EPS Attach start procedure is performed as specified in Lesson 7.
3. The VLR shall be updated according to the combined GPRS/IMSI Attach procedure if the Attach
Request message includes an Attach Type indicating that the UE requests a combined EPS/IMSI
attach. The MME allocates a default LAI, which is configured on the MME and may take into
account the current TAI and/or E-CGI. The MME derives a VLR number based on the allocated LAI
and IMSI hash function. The MME starts the location update procedure towards the new MSC/VLR
upon receipt of the first Insert Subscriber Data message from the HSS in step 2. This operation
marks the MS as EPS-attached in the VLR.
2010
Version 2 Rev 4 Circuit Switch Fallback in EPS for 3GPP

4. The MME sends a Location Update Request (new LAI, IMSI, MME address, Location Update Type)
message to the VLR. MME address is an IP address.
5. The VLR creates an association with the MME by storing MME address.
6. The VLR performs Location Updating procedure in CS domain.
7. The VLR responds with Location Update Accept (VLR TMSI) to the MME.
8. The EPS Attach end procedure is performed as specified in Lesson 7.
Mobile Calls
There are a number of procedures described in the specifications for mobile calls:
• Mobile Originating call in Active Mode — PS HO supported.
• Mobile Originating call in Active Mode — No PS HO support
• Mobile Originating call in Idle Mode
• Mobile Terminating call in Idle Mode
• Mobile Terminating call in Active Mode — PS HO supported
• Mobile Terminating call in Active Mode — No PS HO support
In this course only 'Mobile Originating call in Active mode — PS HO supported' will be discussed.
Mobile Originating call in Active mode — PS HO supported (No MSC Change)

The UE will be in ECM-CONNECTED mode and it is assumed that the 2G/3G coverage is within the
same area geographical area as the LTE source cell.
Figure 10-14 Mobile Originating call in Active mode — PS HO supported (No MSC
Change) 1
1. The UE sends an Extended Service Request (CS Fallback Indicator) to the MME. Extended Service
Request message is encapsulated in RRC and S1 AP messages. CS Fallback Indicator indicates
MME to perform CS Fallback. The UE only transmits this request if it is attached to CS domain
(with a combined EPS/IMSI Attach) and can not initiate an IMS voice session (because e.g. the UE
is not IMS registered or IMS voice services are not supported by the serving IP CAN, home PLMN
or UE).
2010

2. The MME sends an S1 AP Request message to eNodeB that includes a CS Fallback indicator.
This message indicates to the eNodeB that the UE should be moved to UTRAN/GERAN.
3. The eNodeB may optionally solicit a measurement report from the UE to determine the target
GERAN/UTRAN cell to which PS handover will be performed. If measurements are not taken
then the UE could perform a blind handover to the 2G/3G cell. Blind handovers are used when the
coverage area of the LTE cell is with the same geographical area as the 2G or 3G cell.
4. The eNodeB triggers PS handover to a GERAN/UTRAN neighbor cell by sending a Handover
Required message to the MME. In this case an inter-RAT handover from E-UTRAN to UTRAN
or GERAN described previously begins. As part of this handover, the UE receives a HO from
E-UTRAN Command and tries to connect to a cell in the target RAT. The HO from the E-UTRAN
Command may contain a CS Fallback Indicator which indicates to the UE that the handover is
triggered due to a CS fallback request. If the HO from the E-UTRAN Command contains a CS
Fallback Indicator and the UE fails to establish connection to the target RAT, then the UE considers
that CS fallback has failed. The Service Request procedure is considered to be successfully
completed when the PS Handover procedure is completed successfully.
Figure 10-15 Mobile Originating call in Active mode — PS HO supported (No

MSC Change) 2
5. Target RAT is UTRAN or GERAN Iu mode: The UE establishes a CS signalling connection by

sending an RRC Initial Direct Transfer or Complete Layer 3 Information message that contains a
CM Service Request.
6. The CM Service Request is forwarded to the MSC.
7. The UE initiates the CS call establishment procedure.
8. After the UE moves to a cell in the target RAT, the inter-RAT handover from E-UTRAN to UTRAN
or GERAN is completed. At the end of this handover the UE may trigger the Routing Area Update
procedure when the sending of uplink packet data is possible.
2010
Version 2 Rev 4 EPS and CDMA Inter-Technology Working
EPS and CDMA Inter-Technology Working

Standards have been designed for inter-working between the LTE EPS and CDMA. There are different
methods to achieve this depending on the operators service strategy.
Solutions to Inter-Technology Working
Figure 10-16 Solutions to Inter-Technology Working
Strategy A Strategy B Strategy C
Non-real-! me data services Real-! me data services All services including

- LTE/eHRPD bi-direc on non- (non-VoIP) VoIP
op mized handover - LTE/eHRPD bi-direc on non- - LTE/eHRPD bi-direc on non-
op mized handover op mized handover
- LTE/eHRPD bi-direc on - LTE/eHRPD bi-direc on
op mized handover op mized handover
- CSFB - SRVCC
3GPP Release Standard Rel8
EPS eHRPD cdma 1x
It is likely that the operator will choose a phased introduction for Inter-Technology working. In this lesson
it is described as strategy A, B and C in the 3GPP R8 specifications.
Strategy A
LTE to/from eHRPD bidirectional non-optimized handover. This is used for non-real time services, as
there is a delay introduced of around 4s as the UE handover between technologies.
Strategy B
LTE to/from eHRPD bidirectional non-optimized handover.
LTE/eHRPD bidirectional optimized handover — Preregistration takes place before the handover, so this
is suitable for real-time services.
CSFB for cdma2000 — As CS fallback for 3GPP, suitable for small deployments as there is a large
signalling overhead.
Strategy C
LTE to/from eHRPD bidirectional non-optimized handover.
LTE/eHRPD bidirectional optimized handover
Single Radio Voice Call Continuity (SRVCC) — Based on IMS, so seen as the future for voice services.
2010
EPS and CDMA Inter-Technology Working Version 2 Rev 4
eHRPD
Figure 10-17 eHRPD
A focus of 3GPP standardization has been the evolution and interworking among 3G UMTS networks,
to 4G LTE networks, to non-3GPP access networks all using a single packet core called EPC. Since
several CDMA operators have committed to migrating to LTE, evolution becomes a key challenge. As
currently defined, standard HRPD and LTE access networks will be complete overlay networks without
seamless service mobility for customers, or sharing of common functions such as policy, charging and
authentication.
Today’s mobile subscribers are used to a seamless service experience, which would require market
wide deployment of LTE networks, or the implementation of a solution for the LTE and HRPD networks
to work together. 3GPP2 is defining such an interworking method by evolving existing HRPD networks
to be compatible with 3GPP EPC through a step called eHRPD. eHRPD is being standardized as a
method of interworking multiple access networks (eHRPD, E-UTRAN) under a single packet switched
core network, SAE/EPC.
The introduction of eHRPD requires the introduction of an HRPD Serving Gateway (HS-GW). The
HS-GW ensures converged mobility management between HRPD and LTE networks. The HS-GW
provides interworking between the HRPD Access Node (HRPD AN) and the P-GW, a key element of
the SAE/EPC network. In some network instances, the existing Packet Data Serving Node (PDSN) can
be integrated with or upgraded to the HS-GW while the existing Home Agent (HA) can be integrated
with or upgraded to the P-GW (or provided as a separate node).
One of the main advantages of eHRPD is the ability to provide seamless service mobility between
HRPD and LTE access networks with a single mobility management protocol. Moreover, with eHRPD,
the operator can leverage the benefit of optimized handover – no dropped sessions and reduced
handover latency — between LTE and eHRPD. The benefit of seamless and optimized mobility for
data is highly dependant on the mobile operator business model for adding new services. As new
applications emerge, the requirement for seamless service mobility becomes greater. Since SAE is an
all-IP network infrastructure, the network will quickly move to mobile VoIP for voice. Moreover, with the
introduction of eHRPD, the operator can leverage the benefit of optimized intra eHRPD handover when
the user crosses the HS-GW boundaries. This capability does not exist in current HRPD systems.
Packet Data Interworking Function (PDIF)
2010
Architecture for Optimized Handovers between E-UTRAN Access and

cdma2000 HRPD Access
Optimized handover supported by this architecture is intended for the scenario where the operator owns
both the E-UTRAN access and the HRPD access, or where there is a suitable inter-operator agreement
in place.
Figure 10-18 Architecture for Optimized Handovers between E-UTRAN Access and
cdma2000 HRPD Access
Reference Points
S101: — The S101 interface supports procedures for Pre-Registration, Session Maintenance and Active
handovers between E-UTRAN and HRPD networks. This is based on tunnelling over S101 signalling of
one technology while the UE is in the other technology.
S103: — The S103 interface between the S-GW and HS GW supports the forwarding of DL data during
mobility from E-UTRAN to HRPD. Signalling procedures on the S101 interface are used to set up tunnels
on the S103 interface.
2010
Overview of Handover Procedures
Figure 10-19 Overview of Optimized Handover Procedures
• Ac ve - E-UTRAN Access to cdma2000 HRPD Access

• Idle - E-UTRAN Access to cdma2000 HRPD Access
• Ac ve – cdma2000 HRPD Access to E-UTRAN
• Idle - cdma2000 HRPD Access to E-UTRAN
The S101 reference point, and E-UTRAN and HRPD access is used for transparent transfer of
pre-registration and handover signalling between the UE and the target access system.
The purpose of the procedures is to minimize the total service interruption time experienced at the UE,
by allowing the UE to attach and perform service activation (in the case of E-UTRAN) or to perform
a session configuration or traffic allocation request (in the case of HRPD) in the target access system
before leaving the source access system.
In the case where the UE is connected to the E-UTRAN and conditions are such that a handover
to HRPD may be required, the source system provides the UE with sufficient information to perform
pre-registration with the target HRPD access and core network, over the S101 tunnelling interface.
If conditions subsequently warrant that a handover should occur, the handover signalling will also be
performed over the S101 tunnelling interface. Once the UE is ready to connect to the target system,
it switches to the HRPD access. Alternatively, the E-UTRAN may redirect the UE to HRPD using the
RRC Connection Release with Redirection Information set. If pre-registration has not been performed
successfully, upon receiving the redirection message, the UE acquires the HRPD channel and performs
the non-optimized handover. If pre-registration is successful, upon receiving the redirection message,
the UE follows the RRC Connection Release with Redirection procedure to reselect the HRPD cell
according to TS 33.311 and then performs the idle-mode optimized handover procedure.
In case where the UE is connected to the HRPD and conditions are such that a handover to
E-UTRAN may be required, the source system provides the UE with sufficient information to perform
pre-registration with the target EPS. The pre-registration may be performed over the S101 tunnelling
interface. If conditions subsequently warrant that a handover should occur, the handover signalling may
also be performed over the S101 tunnelling interface. Once the UE is ready to connect to the target
system, it switches to the E-UTRAN access.
The following figure lists the Optimized Handover Types in Active and Idle modes. In this lesson we shall
only discuss the 'Active - E-UTRAN Access to cdma2000 HRPD Access'.
2010
Optimized Active Handover: E-UTRAN Access to cdma2000 HRPD Access

This section describes the Optimized Handover from E-UTRAN Access to cdma2000 HRPD Access
in two phases, pre-registration and the actual handover. In pre-registration phase the UE registers to
the cdma2000 HRPD Access, while the UE remains connected to the E-UTRAN. The pre-registration
may take place well in advance of the need to make the actual handover. In the handover phase, the
connection is handed over to cdma2000 HRPD Access, and the UE leaves the E-UTRAN.
Pre-registration Phase
Figure 10-20 Pre-registration Phase 1
The following illustrates a high-level call flow for the optimized E-UTRAN to HRPD handover procedure,
Pre-registration phase:
1. The UE is registered with E-UTRAN/MME. It may have an ongoing data session established over
EPS/E-UTRAN access.
2. Based on a Radio Layer trigger (e.g., an indication from the E-UTRAN when the UE is in connected
state or an indication over the broadcast channel), the UE decides to initiate a pre-registration
procedure with potential target HRPD access. The pre-registration procedure allows the UE
to establish and maintain a dormant session in the target HRPD access, while attached to the
E-UTRAN/MME.
3. Registration to the HRPD is achieved by exchanging a series of HRPD messages between the
UE and the HRPD Access Network. The HRPD signalling that is tunneled transparently over the
E-UTRAN and EPC creates an HRPD session context between the UE and the HRPD Access
Network.
4. The HRPD Access Network creates a signalling relationship with the HS GW for the UE with
interactions in HRPD network A10 / A11 interfaces.
2010

5. The UE, HS-GW, and 3GPP AAA exchange EAP AKA signalling to authenticate the UE on the
HRPD system. The HS-GW receives the APN(s) and P-GW identity(ies) information from AAA
during authentication.
Figure 10-21 Pre-registration Phase 2
6. The HS-GW initiates a Gateway Control Session Establishment Procedure with the PCRF. If the
HS-GW supports UE to Network bearer control mode, the PCRF provides the rules required for the
HS GW to perform the bearer binding for all the active sessions the UE may establish as a result
of the handover procedure.
7. The UE and HS GW exchange signalling to establish context to support the bearer traffic
environment in use over the E-UTRAN.
8. At any time prior to the Handover Phase, if session maintenance activity is required, the UE or
HRPD access network shall perform session maintenance signalling by tunnelling the HRPD
session maintenance messages over the S101. If QoS parameters require updating, then this
step includes the PCRF interaction. The MME uses the S101 Session ID to identify the UE context
over the S101 interface.
9. PCRF interacations due to session maintenance can be initiated by the PCRF or the HS GW. The
PCRF initiates the Gateway Control and QoS Rules Provision Procedure. The HS GW initiates the
Gateway Control and QoS Policy Rules Request Procedure.
Note: Between Step 7 and Step 8 the UE may enter ECM-IDLE state. To execute the session
maintenance procedures at Step 8 it is necessary for the UE to enter ECM-CONNECTED state.
Handover Phase
The following illustrates a high-level call flow for the optimized E-UTRAN to HRPD handover procedure,
Handover phase. The prerequisite of the handover phase is the successfully performed pre-registration
phase
2010

Figure 10-22 Handover Phase 1
1. Ongoing session established over EPS/E-UTRAN access.

2. The eNodeB receives measurement reports from the UE.
3. The eNodeB makes the handover decision.
4. The handover decision is signalled to the UE with Handover from E-UTRA preparation request
message.
5. UE sends a UL handover preparation transfer message (HRPD message starting HO access) to
the eNodeB. The HRPD message starting HO access will be carried transparently to the HRPD
access node, and its purpose is to request information for accessing an HRPD traffic channel.
The message indicates to the eNodeB that the UE is responding to the Handover from E-UTRA
preparation request message, and is requesting information for accessing an HRPD traffic channel.
6. The eNodeB sends the Uplink S1 cdma2000 Tunneling message (HRPD message starting HO
access, and SectorID, cdma2000 HO Required Indication) to the MME. The SectorID is statically
configured in the eNB. The eNodeB will also include cdma2000 HO Required Indication IE to Uplink
2010

S1 cdma2000 Tunneling message, which indicates to the MME that the handover preparation has
started.
7. When receiving an Uplink S1 cdma2000 Tunneling message with a cdma2000 HO Required

Indication the MME determines a HRPD access node address based on the SectorID. An S101
Session ID is used to identify signalling related to that UE on S101. The MME sends a Direct
Transfer Request message (S101 Session ID, SectorID, P-GW Identity(ies), GRE key(s) for uplink
traffic, APN(s), HRPD message starting HO access) to the HRPD access node.
8. The HRPD access network allocates the requested radio access resources, and requests a
forwarding address from HS-GW. The information sent in the request from the HRPD access
network to HS-GW includes APN(s), P-GW Identity(ies) and GRE key(s) for uplink traffic. The
response includes the HS-GW Address and GRE key(s) for forwarded traffic on S103. There is
one GRE key for each PDN connection for which traffic is to be forwarded.
9. The HRPD access network sends the Direct Transfer Request message (S101 Session ID, HRPD
message with HO access information, HS-GW Address and GRE key(s) for forwarded traffic,
cdma2000 HO Status) to the MME. The HS-GW Address and GRE key(s) for forwarded traffic
are sent if data forwarding applies. If the HRPD access network did not allocate the resources as
requested, this will be indicated to the MME and eNodeB with the cdma2000 HO Status IE, and
the embedded HRPD message indicates the failure to the UE.
10. (a). If a Direct Transfer Request message included HS-GW Address and GRE key(s) for forwarded
traffic, the MME determines which of the S1–U bearers should be forwarded to the HRPD and
configures resources for indirect data forwarding by sending Create Forwarding Tunnel Request
(HS-GW address, GRE key(s) for forwarded traffic, EPS bearer ID(s) subject to forwarding) to the
S-GW.
(b) The S-GW confirms data forwarding resources for S103 and allocates forwarding address for
S1 in Create Forwarding Tunnel Response (cause, S-GW address, S1–U uplink TEID(s)). The
S1–U uplink TEIDs are provided one per S1–U bearers subject to forwarding.
11. The MME sends the downlink S1 cdma2000 tunneling message (HRPD message with HO access
information, S-GW address, S1-U uplink TEID(s), cdma2000 HO Status) to the E-UTRAN. If the
cdma2000 HO Status indicates that handover preparation failed, the Downlink S1 cdma2000
tunneling message will be sent with appropriate cause, and the embedded HRPD message that
2010

indicates the failure to the UE. The message from the MME provides the eNodeB also with the
data forwarding S1–U uplink TEIDs allocated at the S-GW.
12. The E-UTRAN forwards the HRPD message with HO access information to the UE in the mobility
from E-UTRA message. This is perceived by the UE as a Handover Command message. If
handover preparation fails, a DL Information transfer message will be sent instead, with the
embedded HRPD message that indicates the failure to the UE. The E-UTRAN starts forwarding
received downlink data to the S-GW on a per S1–U bearer forwarding tunnel, which then forwards
these packets on a per-PDN per-UE S103 tunnel to the HS-GW. The forwarding starts at the same
moment as the Mobility from E-UTRA message is sent to the UE.
13. The UE retunes to the HRPD radio access network and performs traffic channel acquisition.
14. The UE sends an HRPD Traffic Channel Complete (TCC) message to the HRPD access network.
15. The E-UTRAN triggers switching the flow in the EPC with the following sequence:
a. The HRPD access network sends A11 request signalling to HS-GW to start setting up the
U-Plane connection between the HRPD access network and HS-GW.
b. The HS-GW sends a Proxy Binding Update to P-GW. The HS-GW sends the all zero IPv4
Home Address (0.0.0.0) or all zero IPv6 Home Prefix (0::/0) in the PBU message. In order to
support session continuity, the P-GW performs the Binding Cache entry existence test based
on the NAI and assigns the same IPv4 Home Address and/or IPv6 Home Prefix to the UE and
acknowledge in the PBA message.
c. The P-GW switches the flow from S-GW to HS-GW, and sends Proxy Binding Acknowledge to
HS-GW, including the Charging ID for the PDN connection.
d. The HS-GW responds with an A11 response signalling to the HRPD access network.
2010

e. The P-GW executes a PCEF-Initiated IP-CAN Session Modification Procedure with the PCRF
to obtain the rules required for the P-GW to function as the PCEF for all the active IP sessions
the UE has established with new IP-CAN type. Otherwise, information configured with the
P-GW may be used to determine policy. Since Steps 15c and 15e are both triggered by the
Proxy Binding Update in Step 15b, Steps 15c and 15e may occur in parallel.
For a multiple PDN connection, steps 15b to 15e are performed for each PDN connection.
16. (a) The HRPD access network sends a Notification Request (HO Complete, S101 session ID)
message to the MME (including the S101 session ID to identify the UE context).
(b) The MME responds by sending a Notification Response (S101 session ID) to the HRPD access
network.
Timers in MME are started to supervise when the EPS bearer resources in the S-GW and the
temporary resources, used for indirect forwarding in the S-GW, shall be released.
17. The MME releases the UE context in the source E-UTRAN based on the normal E-UTRAN
procedure.
18. (a and b) This step is only performed in case of the S-GW resource is not yet released and timers
have expired. When either one of the timers started in step 16 expires, the MME releases S-GW
resources by sending a Delete Bearer Request (Cause, TEID) message to the S-GW. The MME
shall indicate to the S-GW that the S-GW shall not initiate a delete procedure towards the P-GW.
19. At any time after step 15c, the P-GW shall initiate the P-GW Initiated PDN Disconnection procedure
at E-UTRAN or the P-GW Initiated Bearer Deactivation procedure.
2010
Version 2 Rev 4 Single Radio Voice Call Continuity (SRVCC)
Single Radio Voice Call Continuity (SRVCC)
Figure 10-26 SRVCC Overview
• E-UTRAN to 3GPP2s 1xCS

• E-UTRAN to 3GPP’s UTRAN/ GERAN
• UTRAN(HSPA) to UTRAN/ GERAN
For CS calls that are anchored in the IMS.
The SRVCC feature deals with inter-working between E-UTRAN access and 3GPP2's 1xCS, and
between E-UTRAN access and 3GPP's UTRAN/GERAN accesses and between UTRAN (HSPA)
access and 3GPP's UTRAN/GERAN accesses, for CS calls that are anchored in the IMS. In this lesson
we shall concentrate on E-UTRAN access to 3GPP2 1xCS inter-working.
E-UTRAN and 3GPP2 1xCS SRVCC Concept
Figure 10-27 E-UTRAN and 3GPP2 1xCS SRVCC Concept
For SRVCC-capable UEs, the call is always anchored at the VCC AS in the 3GPP2s IMS. The 3GPP2
1xCS IWS enables a single radio UE to communicate in parallel both with the source system and the
target system. From the VCC perspective, this mechanism minimizes the voice gap by supporting the
transport of signalling for establishment of the target CS access leg while the terminal is connected to
the source PS access network.
The S102 reference point is used to convey 3GPP2 1xCS signalling messages between the MME and
the 3GPP2 1xCS IWS. These 1xCS signalling messages are actually exchanged between the UE and
the 3GPP2 1xCS IWS, and S102 is only one link in the overall UE 1xCS IWS tunnelling path. On the
remaining portion of the tunnelling path, the 3GPP2 1xCS signalling messages are encapsulated in the
E-UTRAN/EPS tunnelling messages (UE MME).
2010
Single Radio Voice Call Continuity (SRVCC) Version 2 Rev 4

E-UTRAN and 3GPP2 1xCS SRVCC Architecture
Figure 10-28 E-UTRAN and 3GPP2 1xCS SRVCC Architecture
The specifications introduced an additional functional entity to those defined in the E-UTRAN architecture
TS 23.402, called 1xCS SRVCC inter-working solution function (3GPP2 1xCS IWS).
3GPP2 1xCS SRVCC Inter-working Solution Function (1xCS IWS)

3GPP2 1xCS IWS uses the S102 reference point to communicate with the MME and to transport 3GPP2
1xCS signalling messages to the SRVCC UE. The role of the 3GPP2 1xCS IWS is:
• To be a signalling tunnelling end point towards the MME for receiving/sending encapsulated 3GPP2
1xCS signalling messages to/from the UE; and
• To emulate a 1xRTT BSS towards the 1xRTT MSC (reference point A1 as defined in 3GPP2
A.S0014 between 1xBS and MSC).
MME Inter-working with 3GPP2 1xCS IWS

If the MME (operator) supports inter-working to 3GPP2 1xCS, the MME shall follow the rules and
procedures described in TS 23.402 with the following additions and clarifications:
• To be a signalling tunnelling end point towards the 3GPP2 1xCS IWS for sending/receiving
encapsulated 3GPP2 1xCS signalling messages to/from the UE, which are encapsulated in
S1-MME S1 Information Transfer messages.
• Release of the E-UTRAN resources after SRVCC to the 3GPP2 1xCS is completed.
UE enhanced for SRVCC Inter-working with 3GPP2 1xCS IWS

If the UE supports 3GPP2 1xCS access, the 1xCS SRVCC UE is a UE that is capable of performing
SRVCC to the 3GPP2 1xCS system. The interaction between UE and E-UTRAN is as previously
described.
E-UTRAN
If the E-UTRAN (operator) supports interworking to 3GPP2 1xCS, the E-UTRAN performs the HO trigger,
tunnelling of the 3GPP2 1xCS signalling messages toward the MME, and interacting with the SRVCC
UE.
2010
SRVCC from E-UTRAN to 3GPP2 1xCS Procedure and Flow

The procedures described in TS23.401 for E-UTRAN Attach and Service Request are modified when
SRVCC is enabled in the network.
E-UTRAN Attach procedure for SRVCC

E-UTRAN attach procedure for 3GPP2 SRVCC UE is performed as defined in TS 23.401 with the
following additions:
• SRVCC UE includes the SRVCC capability indication as part of the UE network capability in the
Attach Request message. MME stores this information for SRVCC operation.
• MME includes a "SRVCC operation possible" indication in the S1 AP Initial Context Setup Request,
meaning that both UE and MME are SRVCC-capable.
Service Request procedures for SRVCC

Service Request procedures for 3GPP2 SRVCC UE are performed as defined in TS 23.401 with the
following additions:
• MME includes a "SRVCC operation possible" indication in the S1 AP Initial Context Setup Request,
meaning that both UE and MME are SRVCC-capable.
Call flows for SRVCC from E-UTRAN

The following illustrates a high-level call flow for the E-UTRAN-to-1x voice service continuity procedure.
Figure 10-29 SRVCC from E-UTRAN to 3GPP2 1xCS Procedure and Flow 1
1. Ongoing VoIP session over the IMS access established over EPS/E-UTRAN.
2. 1xCS SRVCC UE sends measurement reports to eNodeB.
3. The E-UTRAN (e.g., based on some trigger, measurement reports) makes a determination to initiate
an inter technology handover to cdma2000 1xRTT Rev A.
4. The E-UTRAN signals the UE to perform an inter technology handover by sending a Handover from
E-UTRA Preparation Request (3G1x Overhead Parameters, RAND value) message.
2010
Single Radio Voice Call Continuity (SRVCC) Version 2 Rev 4

5. The UE initiates signalling for establishment of the CS access leg by sending a UL Information
Transfer message containing the 1xRTT Origination message.
6. The E-UTRAN sends an Uplink S1 cdma2000 Tunnelling (MEID, RAND, 1x Origination, Reference
Cell ID) message to the MME.
7. Upon reception of the Uplink S1 cdma2000 Tunnelling message, the MME selects a 3GPP2 1xCS
IWS based on Reference Cell ID and encapsulates the 1x Origination Message along with the MEID
and RAND in a S102 Direct Transfer message (as "1x Air Interface Signaling").
8. The traffic channel resources are established in the 1x RTT system and 3GPP2 1xCS procedures
for initiation of Session Transfer are performed.
9. The 3GPP2 1xCS IWS creates a 1x Handoff Direction message and encapsulates it in a S102
Direct Transfer message.
10. The MME sends the 1x Handoff Direction message embedded in a Downlink S1 cdma2000
Tunnelling message to the E-UTRAN.
11. The E-UTRAN forwards the 1x Handoff Direction message embedded in a Mobility from the E-UTRA
Command message to the UE. This is perceived by the UE as a Handover Command message.
12. Once the UE receives the traffic channel information from the cdma2000 1xRTT Rev A system, the
UE retunes to the 1xRTT radio access network and performs traffic channel acquisition with the
1xRTT CS access (e.g., 1xRTT BSS).
13. The UE sends a 1xRTT handoff completion message to the 1xRTT CS access (e.g., 1xRTT BSS).
14. The 1xRTT CS Access sends message to 1xRTT MSC to indicate the handoff is done. The
resources between 1x CS IWS and 1xRTT MSC may be released at this step.
2010

15. Ongoing voice call over the CS access leg established over 1xRTT access. The E-UTRAN/EPS
context may be released based on the normal E-UTRAN/EPS procedure.
16. The eNodeB sends an S1 UE Context Release Request (Cause) message to the MME. Cause
indicates the S1 release procedure is caused by handover from E-UTRAN to 1xRTT.
17. The MME exchanges Suspend Request/ Acknowledge messages with the S-GW. The S1-U bearers
are released for all EPS bearers and the GBR bearers are deactivated by the MME. The non-GBR
bearers are preserved and are marked as suspended in the S-GW. Upon receipt of downlink data
the S-GW should not send a downlink data notification message to the MME.
18. UE Context in the eNodeB is released.
2010
2010
Lesson Summary
• Inter-working to GSM, UMTS and CDMA Networks

• Measurements needed for inter-working
• The interfaces needed for inter-working to GSM, UMTS and CDMA
• Idle mode cell selection and reselection to GSM, UMTS and CDMA
• Handovers to GSM, UMTS and CDMA
2010
Memory Points
2010

Abd Motorola

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Abd Motorola

Uploaded by

Copyright:

Available Formats

LTE300: LTE Radio Link and EPS Signaling

The CE mark confirms Motorola Ltd’s statement of compliance with

Tel: +44 (0) 1793 565 444

LTE300: LTE Radio Link and EPS Signaling

Chapter 1: Introduction to the 3GPP Evolved Packet System

Chapter 2: LTE Air Interface – Physical Layer Basics

Chapter 3: LTE Air Interface – PHY Layer Advanced

SC-FDMA Subcarrier Encoding, Continued . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15

Chapter 4: LTE Channels

Chapter 5: Uu Interface Layer 2 Operation

Chapter 6: EPC Protocol Overview

3–way Control Handshake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6- 9

Chapter 7: UE States and LTE/SAE Signaling

Context Information in the MME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-13

Chapter 8: Mobility Operation and Signaling

Procedure Starting Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-36

Chapter 9: Services and Bearer QoS

Chapter 10: Inter-Technology Mobility

Inter-RAT Mobility States Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10- 8

LTE300: LTE Radio Link and EPS Signaling

This page intentionally left blank.

Introduction to the 3GPP Evolved Packet System

This page intentionally left blank.

Conventions Used in this Guide

Indicates a Note or additional Indicates If/then situations. These

Indicates a list of References that Indicates a Warning or Caution.

Indicates a Lab that provides the Indicates a Memory Point. These

Purpose of the Participant Guide

Trade Press Books

MyNetworkSupport Web Page

After hours activities

This page intentionally left blank.

• Explain where LTE fits in the evolution of GSM/UMTS networks

Figure 1-2 Lesson Context

This page intentionally left blank.

Drivers for Long Term Evolution (LTE)

Figure 1-3 Drivers for Long Term Evolution (LTE)

This page intentionally left blank.

3rd Generation Partnership Project (3GPP)

Figure 1-4 3GPP Standards Organization

This page intentionally left blank.

GSM Network Evolution

Figure 1-5 GSM Network Evolution

Global System for Mobile Communication (GSM)

Figure 1-6 GSM – The Starting Point

GSM Network Evolution

The graphic shows an extremely simplified view of GSM, ignoring

General Packet Radio Service (GPRS)

Figure 1-7 GPRS/EDGE

Enhanced Data Rates for GSM Evolution (EDGE)

GSM Network Evolution

Universal Mobile Telecommunications System (UMTS) Release 99

Figure 1-8 UMTS Release 99

Figure 1-9 UMTS Release 4

GSM Network Evolution

Figure 1-10 UMTS Release 5

GSM Network Evolution

Figure 1-11 UMTS Release 6

GSM Network Evolution

Figure 1-12 UMTS Release 7

GSM Network Evolution

Figure 1-13 UMTS Release 8

GSM Network Evolution

How Does LTE Fit into 3GPP Roadmap?