lte100-motorola lte training_

LTE100: Introduction to Long Term Evolution

LTE100: Introduction to Long Term EvolutionFOR TRAINING PURPOSES ONLY - THIS MANUAL WILL NOT BE UPDATED

© 2010 Motorola, Inc.

Copyrights

The Motorola products described in this document may include copyrighted Motorola computer programs stored in semiconductor memoriesor 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 computerprograms contained in the Motorola products described in this document may not be copied or reproduced in any manner without the expresswritten 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 operationof 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/ordisclosed only in accordance with the terms of the agreement. Software and documentation are copyright materials. Making unauthorizedcopies 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 beenmade to assure the accuracy of this document, Motorola assumes no liability resulting from any inaccuraciesor omissions in this document, or from the use of the information obtained herein. Motorola reserves the right to make changes to any productsdescribed herein to improve reliability, function, or design, and reserves the right to revise this document and to make changes from time totime in content hereof with no obligation to notify any person of revisions or changes. Motorola does not assume any liability arising out of theapplication 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 withEU directives applicable to this product. Copies of the Declarationof Compliance and installation information in accordance with therequirements of EN50385 can be obtained from the local Motorolarepresentative or the CNRC help desk, contact details below:

Email: [email protected]

Tel: +44 (0) 1793 565 444

© 2010 Motorola, Inc. LTE100: Introduction to Long Term EvolutionFOR TRAINING PURPOSES ONLY - THIS MANUAL WILL NOT BE UPDATED

Contents■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

■

■

LTE100: Introduction to Long Term Evolution

Chapter 1: Lesson 1: What is Long Term Evolution (LTE)?Course Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1- 3

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1- 3Prerequisite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1- 3Target Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1- 3Conventions Used in this Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1- 3Purpose of the Participant Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1- 3References and Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1- 4Expectations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1- 5Practicalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1- 5Course Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1- 6Course Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1- 6

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1- 8Drivers for Long Term Evolution (LTE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1- 93rd Generation Partnership Project (3GPP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10GSM Network Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11

Global System for Mobile Communication (GSM) Evolution . . . . . . . . . . . . . . . . . . . 1-11How Does LTE Fit into 3GPP Roadmap? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13

3GPP Release 8 Network Architecture (LTE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-19E-EUTRAN Air Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20Performance Goals for LTE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-21

Spectrum Flexibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-21Spectrum Efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-22Increased Peak Data Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-22Increased User Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-23Control Plane Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-23User Plane Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24Mobility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24Cell Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24

Lesson 1 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-25Memory Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-26

Chapter 2: Lesson 2: LTE Network ArchitectureObjectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2- 33GPP Release 8 Network Architecture (LTE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2- 4

evolved Node B (eNodeB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2- 4User Entity (UE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2- 5Mobility Management Entity (MME) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2- 6Serving Gateway (S-GW). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2- 8Packet Data Network Gateway (P-GW) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2- 9Other EPC Network Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10Interworking with Other Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10eNodeB Reference Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13

Motorola LTE Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14eNodeB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14Wireless Broadband Controller (WBC) 700 . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16Wireless Broadband Controller (WBC) 700 as S-GW . . . . . . . . . . . . . . . . . . . . . . 2-17Wireless Broadband Core (WBC) 700 as P-GW . . . . . . . . . . . . . . . . . . . . . . . . 2-18Wireless Broadband Manager (WBM) 700 . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18WBM 700 Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19GSM to LTE Migration/Overlay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20CDMA LTE Overlay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21CDMA Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21

Self-Organizing Network (SON) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-24


i

Contents LTE100: Introduction to Long Term Evolution

SON Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-24Motorola SON Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-24Proposed Motorola SON Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-25


Chapter 3: Lesson 3: LTE Air InterfaceObjectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3- 3Radio Frequency Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3- 4

LTE Spectrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3- 4Channel Bandwidth. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3- 4Channel Sampling Frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3- 6

Orthogonal Frequency Division Multiplexing (OFDM) . . . . . . . . . . . . . . . . . . . . . . . . 3- 7Non-Orthogonal Subcarriers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3- 7Orthogonal Frequencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3- 8Subcarrier Transmitter Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3- 9Subcarrier Receiver Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10Fast Fourier Transform (FFT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11Scalable OFDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12Subcarrier Spacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13Symbol Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15Multipath Delay and Inter-Symbol Interference . . . . . . . . . . . . . . . . . . . . . . . . . 3-15Cyclic Prefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-16Subcarrier Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17Occupied Subcarriers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19

LTE Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-20LTE Frame Length and Subcarriers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-20

Channel Direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-22Frequency Division Duplexing (FDD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-22Time Division Duplexing (TDD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-23

Frame Type 1 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-24Slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-24Resource Blocks and Resource Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-24Physical and Virtual Resource Blocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-25Reference Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-26Frame Type 1 Subframes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-27FDD Operation – DL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-28FDD UL Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-29

Frame Type 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-30Special Subframe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-30Frame Type 2 UL/DL Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-31

OFDM Bandwidth Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-32OFDMA Bandwidth Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-32

OFDMA Transmitter Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-34OFDMA Receiver Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-35Single Carrier-Frequency Division Multiple Access (SC-FDMA) . . . . . . . . . . . . . . . . . . . 3-36

OFDMA Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-36UE Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-36SC-FDMA Transmitter Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-36SC-FDMA Receiver Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-37OFDMA Subcarrier Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-38SC-FDMA Subcarrier Encoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-39

Modulation and Coding Schemes (MCS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-41Selected Transmitter Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-41Modulation Techniques Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-41Modulation Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-42Modulation and Signal Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-43Estimating FDD Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-44

Multiple Antenna Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-46Single Input Multiple Output (SIMO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-46Multiple Input Single Output (MISO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-47Multiple Input Multiple Output (MIMO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-48MIMO Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-49Single User MIMO (SU–MIMO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-50Multi-User MIMO (MU–MIMO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-51

ii LTE100: Introduction to Long Term EvolutionFOR TRAINING PURPOSES ONLY - THIS MANUAL WILL NOT BE UPDATED


LTE100: Introduction to Long Term Evolution Contents


Chapter 4: Lesson 4: LTE and EPC Protocol OverviewObjectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4- 3Selected EPS Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4- 4

EPS and the TCP/IP Protocol Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4- 4Control Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4- 5User Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4- 6

Uu Interface Data Link Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4- 8Radio Resource Control (RRC) Sublayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4- 9Packet Data Convergence Protocol (PDCP) Sublayer . . . . . . . . . . . . . . . . . . . . . 4- 9Radio Link Control (RLC) Sublayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4- 9Medium Access Control (MAC) Sublayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10Uu Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10

SAE and LTE Channel Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11Logical Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11Transport Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13Physical Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14Transport to Physical Channel Mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-15

Mapping DL Physical Channels to Subframes . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16Broadcast Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16Synchronization Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-17

Mapping UL Physical Channels to Subframes . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20Mapping PUCCH to Subframes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20Random Access Channel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-21Random Access Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-22

S1-MME Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24S1-MME Interface Control Protocol Stack. . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24S1 Application Protocol (S1AP) Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-25UE to MME Control Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-27

S1-U and S5-U Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-28S1-U User Plane Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-28S5 Interface User Plane Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-29S5 Control Plane Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-29Uu to P-GW User Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-30

X2 Interface Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-31X2 Control Plane Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-31X2 Application Protocol (X2AP) Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-32X2 User Plane Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-33


Chapter 5: Lesson 5: Network Acquisition and Call ProcessObjectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5- 3Basic Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5- 4Radio Resource Control (RRC) States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5- 5

Radio Resource Control (RRC) – Idle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5- 5Radio Resource Control (RRC) – Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . 5- 5Radio Resource Control (RRC) Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . 5- 5

EPS Mobility Management (EMM) States. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5- 7EPS Mobility Management (EMM) – Deregistered . . . . . . . . . . . . . . . . . . . . . . . 5- 7EPS Mobility Management (EMM) – Registered . . . . . . . . . . . . . . . . . . . . . . . . 5- 7

EPS Connection Management (ECM) States . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5- 8EPS Connection Management (ECM) – Idle . . . . . . . . . . . . . . . . . . . . . . . . . . 5- 8EPS Connection Management (ECM) – Connect . . . . . . . . . . . . . . . . . . . . . . . . 5- 8

EPS Session Management (ESM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5- 9ESM_INACTIVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5- 9ESM_ACTIVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5- 9

Non Access Stratum (NAS) States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10EMM_DEREGISTERED, ECM_IDLE and ESM_INACTIVE . . . . . . . . . . . . . . . . . . . 5-10EMM_REGISTERED, ECM_IDLE and ESM_ACTIVE. . . . . . . . . . . . . . . . . . . . . . 5-10EMM_REGISTERED, ECM_CONNECT and ESM_ACTIVE. . . . . . . . . . . . . . . . . . . 5-10

Selected EPS IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11


iii

Contents LTE100: Introduction to Long Term Evolution

MME IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11UE IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12International Mobile Subscriber Identifier (IMSI) Structure . . . . . . . . . . . . . . . . . . . 5-13

Attaching to the Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14eNodeB Acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14System Information (SI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-15Initial Cell Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16Network Attach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16

Quality of Service (QoS) / EPS Bearer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18Bearer Service Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-19QoS Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-20

Service Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-21UE Triggered Service Request — Simplified . . . . . . . . . . . . . . . . . . . . . . . . . . 5-21

Mobility Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-22Tracking Area (TA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-22MME and S-GW Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-23Tracking Area Update (TAU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-24X2 Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-25

UE Triggered Detach (UE Switched Off) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-28Security in LTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-30

LTE Security Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-30Function of LTE Security Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-31Authentication and Key Agreement Process (AKA) . . . . . . . . . . . . . . . . . . . . . . . 5-31


iv LTE100: Introduction to Long Term EvolutionFOR TRAINING PURPOSES ONLY - THIS MANUAL WILL NOT BE UPDATED


About This Manual Version 3 Rev 1

LTE100: Introduction to Long Term Evolution■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

■

■

■

■


1

Version 3 Rev 1

This page intentionally left blank.

2 LTE100: Introduction to Long Term EvolutionFOR TRAINING PURPOSES ONLY - THIS MANUAL WILL NOT BE UPDATED


Lesson 1: What is Long Term Evolution (LTE)? Version 3 Rev 1

Chapter 1

Lesson 1: What is Long Term Evolution (LTE)?

In this lesson, we will introduce the LTE standards body, define LTE and its performance goals, look at the networkarchitecture changes introduced by LTE, and compare/contrast LTE to current wireless technologies.


1-1

Version 3 Rev 1 Lesson 1: What is Long Term Evolution (LTE)?


1-2 LTE100: Introduction to Long Term EvolutionFOR TRAINING PURPOSES ONLY - THIS MANUAL WILL NOT BE UPDATED


Course Introduction Version 3 Rev 1

Course Introduction

PrefaceThe course is designed to provide an introductory technical overview 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/SAEsignaling and operation.

PrerequisiteStudents should have a general knowledge of telecommunications systems or have attended LTE102 atwo hour online LTE Technical Overview course.

Target AudienceThe primary audience of this course is Motorola and customer RF Engineers, Network PlanningEngineers, and Senior Technical Staff. A secondary audience includes anyone who requires anoverview of LTE/SAE concepts, operation, and signaling.

Conventions Used in this GuideThroughout this guide, you will find icons representing various types of information. These icons serveas reminders of their associated text.

Table 1-1

Indicates a Note or additionalinformation that might behelpful to you.

Indicates If/then situations.These are found in many ofthe labs.

LT

E30

0

Telecoms

Indicates a list of Referencesthat provide additionalinformation about a topic.

Indicates a Warning orCaution. These generallyflag a service affectingoperation.

Indicates a Lab that providesthe opportunity for you toexercise what you’ve learned.

Indicates a Memory Point.These provide a chance forthe candidate to reflect on thetraining and if necessary aska relevant question.

Purpose of the Participant GuideThe Participant Guide contains the content that the instructor will cover during the course. Given theinteractive nature of instructor-led courses, this guidemay 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 documentkey 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 theinformation does change. If you require technical references to the information presented in thisParticipant Guide, always use the most current versions of the pertinent technical documentation.


1-3

Version 3 Rev 1 Course Introduction

Course Introduction

References and ResourcesThe Participant Guide is not a technical book in the traditional, analytical sense. The material andinformation contained here is subject to change. The following references were used in the developmentof this course and should be used for most current information:

Table 1-2

Trade Press Books• Dahlman, Parkvall, Skolk, Beming; 3G Evolution: HSPA and LTE for Mobile

Broadband, Academic Press, 2nd edition 2008• Lescuyer, Lucidarme; Evolved Packet System (EPS): The LTE and SAE

Evolution of 3G UMTS, John Wiley and Sons, 2008

LT

E30

0

Telecoms

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 PageThe on-line support allows customers to open cases trouble tickets, open RMA’s to send boards backfor repair, and download technical documentation.



Course Introduction Version 3 Rev 1

Course IntroductionFigure 1-1

The URL of the customer support web page is:

h�ps://mynetworksupport.motorola.com

This is a secure web site. A password request form can be downloaded from this page.

The URL of the customer support webpage is:


This is a secure web site. A passwordrequest form can be downloaded fromthis ppagge.

The URL of the customer support web page is:


This is a secure web site. A password request form can be downloaded from this page.

As LTE products continue to evolve, we will make a continued effort to keep this material up-to-date. Allsuggestions and recommendations are welcomed. Please submit your recommended changes to theinstructor. Thanks for all your constructive feedback.

ExpectationsThe 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!!!

PracticalitiesMany participants who attend this course may not be familiar with this location’s facilities or thesurrounding area. To ensure your comfort during this course, please make notes on the followinghelpful information.

LocationsRestrooms close to classroom: _______________________________________________________Restroom locations in building: _______________________________________________________Lunch facilities in building: __________________________________________________________Lunch facilities nearby: _____________________________________________________________

After hours activitiesWhere 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.


1-5


Course Introduction

Course Objectives

• Describe the goals of the 3rd Generation Partnership Project (3GPP)• Explain the performance goals of LTE• Explain where LTE fits in the evolution of GSM/UMTS networks• Explain how LTE differs from existing 3G networks• Describe the changes in network architecture introduced by LTE• State the functional blocks that comprise an LTE network• Explain the function of the network elements that comprise the Evolved Universal Terrestrial

Radio Access Network (E-UTRAN)• Explain the function of the network elements that comprise the Evolved Packet Core (EPC)• Describe Motorola’s LTE network architecture• 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• Compare OFDMA and SC-FDMA usage in LTE• Describe LTE antenna systems• Describe the LTE Uu User and Control Plane protocol stacks• List the LTE transport, logical and physical channels• Explain the functions of the LTE physical channels• List the Uu, S1-MME, S1-U, S5-U, and X2 interface functions• Describe the S1-MME, S1-U, S5-U, S5–C and X2 User and Control Plane protocol stacks• List the UE states• Describe the UE network acquisition process• Describe the UE registration process• Describe “typical” UE call processes• Describe UE active and mobility processes• Describe the UE authentication process

Course Schedule

Table 1-3

Day 1

Course Introduction

Lesson 1 – What is Long Term Evolution (LTE)?

Lesson 2 – LTE Network Architecture

Lesson 3 — LTE Air Interface

Day 2

Lesson 3 – LTE and EPC Protocol Overview

Lesson 4 – Network Acquisition and Call Process






1-7

Version 3 Rev 1 Objectives

ObjectivesAt the completion of this lesson, you’ll be able to:

• Describe the goals of the 3rd Generation Partnership Project (3GPP)• Explain the performance goals of LTE• Explain where LTE fits in the evolution of GSM/UMTS networks• Explain how LTE differs from existing 3G networks• Describe the changes in network architecture introduced by LTE



Drivers for Long Term Evolution (LTE) Version 3 Rev 1

Drivers for Long Term Evolution (LTE)

Figure 1-2 Introduction – Drivers for Long Term Evolution

Over the last several decades, technological advancements have had a huge impact on the consumeras well as the telecommunications carriers. Today, consumers expect voice, video and data informationto be available anytime, anywhere.These advancements have also brought changes to the way the Telecom industry does business asthe traditional boundaries are blurring. Traditional fixed-line operators are expanding their boundariesoutside the home while the traditional mobile operators are moving into the fixed line business. Thegoal of both is to capture maximum revenue while trying to meet the customer’s needs with what is nowreferred to as the Quadruple Play; TV, Internet, Telephone, and Mobile.The key is to be able to provide these services with a low cost per bit, higher capacity, increased flexibility,and have global appeal so that network operators will want to deploy the technology.To that end, the 3rd Generation Partnership Project (3GPP) has drafted a set of standards for the nextgeneration mobile broadband network: Long Term Evolution (LTE).


1-9

Version 3 Rev 1 3rd Generation Partnership Project (3GPP)

3rd Generation Partnership Project (3GPP)

Figure 1-3 Figure 1-2: 3GPP Standards Organization

GSMGPRS/EDGEUMTSHSDPAHSUPAHSPA+IMSMBMSLTE

�

��

��

��

��

Formalized in December 1998, the 3rd Generation Partnership Project (3GPP) is a group oftelecommunications associations whose main goal is to make globally applicable specifications forThird Generation (3G) mobile phone systems.3GPP is responsible for establishing the global standards for Global System for MobileCommunication (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), and now Long Term Evolution (LTE).



GSM Network Evolution Version 3 Rev 1

GSM Network Evolution

Figure 1-4 GSM Network Evolution

New “mobile” services such as streaming HD video, Online Gaming, Live Video, Social Networking, andPeer2Peer file exchanges are in demand and on the horizon. Current wireless networks will struggleto deliver enough capacity to “future proof” the desire for greater access, greater speed, and moreapplications. To better understand why current networks struggle, let’s look at the evolution of GSM.

The following section is intended to be a brief review of GSM network evolution. Becauseof the time constraints of the course, a detailed discussion is not possible. Talk with yourinstructor during breaks, before, or after class if you need further explanation.


1-11

Version 3 Rev 1 GSM Network Evolution

GSM Network EvolutionGlobal System for Mobile Communication (GSM) Evolution

Figure 1-5 GSM Evolution – GSM, GPRS, EDGE, UMTS R99

Global System for Mobile Communication (GSM)GSM is the most popular standard for mobile communication in the world. It is estimated that over 80%of the global market uses the standard. GSM is considered a 2G network as both the signaling and voicechannels are digital. GSM also introduced Short Message Service (SMS). GSM data rates are 2.4, 4.8,and 9.6 kbps.

General Packet Radio Service (GPRS)GPRS is a packet data network that shares the radio access network with GSM but has a separate corenetwork. GPRS provides services such as Wireless Application Protocol (WAP), Short MessageService (SMS), Multimedia Messaging Service (MMS), and email and Internet Access. GPRS hastheoretical data rates between 56 and 114 kbps. GPRS is considered a 2.5G network.

Enhanced Data Rates for GSM Evolution (EDGE)EDGE provides coding and modulation improvements to GPRS that provides data speeds from 236 kbpsto 473 kbps depending on coding and modulation techniques used. Because of the latter (i.e., 473 kbps)data rates, EDGE is considered 3G technology.

Univeral Mobile Telecommunications System R99 (UMTS R99)UMTS R99 is the first release of UMTS. UMTS changes the air interface from Time Division MultipleAccess (TDMA) to Wideband Code Division Multiple Access (WCDMA). It is also characterized bytwo separate core networks; Circuit Switch Core Network (CS-CN, voice traffic) and a Packet SwitchCore Network (PS-CN, data traffic).




GSM Network EvolutionFigure 1-6 GSM Evolution – UMTS R4, R5, R6, R7

UMTS R4UMTS R4 does not affect data rates. However, with the introduction of softswitch technology and BearerIndependent Call Control (BICC), UMTS R4 provides a more efficient core network.

UMTS R5UMTS R5 and R6 bring about sizeable increases in data rates. UMTS R5 starts the shift to all IPnetworking by introducing the IP Multimedia Subsystem (IMS). UMTS R5 also introduces High SpeedDownlink Packet Access (HSDPA) that increases peak downlink throughput to 14.4 Mbps.

UMTS R6UMTS R6 increases peak uplink speed to 5.76 Mbps with the introduction of High Speed Uplink PacketAccess (HSUPA). UMTS R6 also introduces Multimedia Broadcast Multicast Services (MBMS) thatsupports services such as mobile TV.

UMTS R7UMTS R7 is also known asHigh Speed Packet Access “plus” (HSPA+). UMTS R7 introducesMultipleInput Multiple Output (MIMO) antenna systems as well as higher-order modulation schemes. PeakData rates in UMTS R7 are 28 Mbps downlink and 11 Mbps uplink. The downlink rate increases in R8to 42 Mbps.


1-13


GSM Network EvolutionHow Does LTE Fit into 3GPP Roadmap?

Figure 1-7 How Does LTE Fit into 3GPP Roadmap?

LTE can evolve directly from a GPRS/EDGE network without having to go through the UMTS releases.If the UMTS path was followed, LTE can evolve directly from UMTS R5/R6 or UMTS R7.

GSM – The Starting Point

Figure 1-8 GSM – The Starting Point

The GSM network is characterized by a 200 kHz air interface, and a Circuit Switched (CS) domain fordigital voice/signaling as well as SMS.




GSM Network EvolutionGPRS/EDGE

Figure 1-9 GPRS/EDGE

GPRS introduces a new domain, the Packet Switched (PS) domain. While the PS domain shares theRadio Access Network (RAN) with the CS domain, all data traffic now goes through the PS domainwhile all voice traffic (and SMS) goes through the CS domain.EDGE DOES NOT introduce any changes to the network other than coding and modulationenhancements to the air interface to increase data speed.

UMTS R99

Figure 1-10 UMTS R99

UMTS R99 is the first release of UMTS. There are a couple of major changes in UMTS R99.The Air Interface changes from Time Division Multiple Access (TDMA) using 200 kHz bandwidth toWideband Code Division Multiple Access (WCDMA) using 5 MHz bandwidth.Also, the BTS and BSC are now replaced by the NodeB and Radio Network Controller (RNC).


1-15


GSM Network EvolutionUMTSR4

Figure 1-11 UMTS R4

UMTS R4 provides a more efficient network with the addition of the Softswitch (MSC Server/MediaGateways) in the CS Domain and Bearer Independent Call Control (BICC).

UMTS R5

Figure 1-12 UMTS R5

UMTS R5 introduces big changes to the UMTS network.

1. Starts the shift to an all IP network with the introduction of the IP Multimedia Subsystem (IMS).2. The Circuit Switch Domain is “collapsed” moving the Softswitch and telephony functions into the

IMS cloud.3.




GSM Network EvolutionChanges the UE functionality enabling it to setup multimedia calls using the IETF’s Session InitiationProtocol (SIP).The IP Multimedia Subsystem replaces the call control and interworking functions of the circuitswitched domain with a more flexible, packet-based, multimedia core service architecture. Althoughoriginally defined by the 3GPP for UMTS networks, IMS has been adopted as the core multimediaservice architecture for CDMA, packet cable, DSL, and WiFi access networks.IMS allows new services to be rapidly and cheaply deployed.

UMTS R6

Figure 1-13 UMTS R6

Along with increasing peak uplink data speed to 5.76 Mbps, UMTSR6 introducesMultimedia BroadcastMulticast Service (MBMS). 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 alluser devices which have the service activated in their equipment. A service provider does not attemptto charge for or limit the broadcast transmission.In contrast, a multicast service is subscription-based. A UE must have subscribed to the service andexplicitly joined the multicast group to receive the multicast transmission. A service provider may track,control, and charge for the multicast transmission.


1-17


GSM Network EvolutionUMTS R7

Figure 1-14 UMTS R7

Along with enhancing IMS, UMTS R7 introduces higher-order modulation techniques (DL 64QAM, UL16QAM) and Multiple Input Multiple Output (MIMO) antenna technology. These enhancements canincrease uplink speeds to 11.5 Mbps uplink and 42 Mbps downlink.

UMTS R8

Figure 1-15

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 evolvedNodeB (eNodeB). In addition to 5 MHz, the E-UTRAN radio access network supports 1.4, 3, 10, 15, and20 MHz channels.R8 with 2x2 MIMO and 64QAMmodulation increases UL speeds to 23 Mbps, and DL speeds to 42 Mbps.In the Evolved Packet Core (EPC), 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 UEmobility and paging functions.



3GPP Release 8 Network Architecture (LTE) Version 3 Rev 1

3GPP Release 8 Network Architecture (LTE)

Figure 1-16 3GPP Release 8 Network Architecture (LTE)

LTE introduces new terminology to describe the architecture. The Evolved Universal Terrestrial RadioAccess Network (E-UTRAN) consists of the User Equipment (UE), Evolved Node B (eNodeB), andtheir associated interfaces. The E-UTRAN is also known as Long Term Evolution (LTE).The Evolved Packet Core (EPC) is an all-IP, packet-switched core network consisting 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 networksThe EPC is also known as System Architecture Evolution (SAE). The goal of the SAE is to create anevolutionary framework which supports higher data rates, lower latency, packet optimized systems usingmultiple Radio Access Technologies (RATs).

NOTEEPC network elements will be discussed in greater detail in Lesson 2.


1-19

Version 3 Rev 1 E-EUTRAN Air Interface

E-EUTRAN Air Interface

Figure 1-17 E-EUTRAN Air Interface

The key air interface changes for E-UTRAN are Orthogonal Frequency Division Multiplexing (OFDM)and the use of Multiple Input Multiple Output (MIMO) antennas.The LTE air interface utilizes Orthogonal Frequency Division Multiple Access (OFDMA) in thedownlink and Single Carrier Frequency Division Multiple Access (SC-FDMA) in the uplink. It alsosupports both Frequency Division Duplex (FDD) and Time Division Duplex (TDD) schemes.Multiple Input Multiple Output (MIMO) antenna systems are also now fully employed. MIMO usesmultiple antennas at both the transmitter and receiver, improving the network efficiency.

NOTEOFDMA, SC-FDMA, TDD, FDD, and MIMO will be discussed in greater detail in Lesson 3.



Performance Goals for LTE Version 3 Rev 1

Performance Goals for LTE

Figure 1-18 Performance Goals for LTE – Spectrum

The 3GPP working group established several goals for LTE:

• Provide the user with the services they desire• Provide the network operators with low cost per bit, higher capacity, and flexible architecture they

will want to deploy

Spectrum FlexibilityThe LTE air interface operates in 1.4, 3, 5, 10, 15, and 20 MHz spectrum allocations in both uplink anddownlink, paired and unpaired.


1-21

Version 3 Rev 1 Performance Goals for LTE


Spectrum EfficiencySpectrum efficiency is the amount of bits of data that are able to be transmitted per 1 hertz(bits/sec/Hz/site). The more bits, in less bandwidth, equals less cost. In a loaded network, the downlinktarget is 3-4 times R6 HSDPA while the uplink target is 2-3 times R6 Enhanced Uplink.

Figure 1-19 Performance Goals for LTE – Throughput/Data Rates

Increased Peak Data RatesWithin a 20 MHz spectrum, LTE supports theoretical instantaneous peak data rates of 100 Mbps downlink(5bps/Hz) and 50 Mbps uplink (2.5bps/Hz).



Performance Goals for LTE Version 3 Rev 1


Increased User ThroughputThe target for downlink average user throughput per MHz is 3-4 times R6 HSDPA while the uplink targetis 2-3 times R6 Enhanced Uplink. This equates to greater than 10 Mbs downlink and greater than 5Mbps uplink.

Figure 1-20 Performance Goals for LTE – Latency

Control Plane LatencyControl plane latency is the transition time from different connection modes, e.g. from idle or dormantstates to the active state. From an idle state to an active state, transition time is less than 100ms. Froma dormant state to an active state, transition time is less than 50ms.


1-23

Version 3 Rev 1 Performance Goals for LTE


User Plane LatencyUser Plane Latency is the one-way transit time of a packet between the user equipment and the radioaccess network (and vice versa). In an LTE network, user plane latency is less than 5ms in an unloadedcondition for small IP packet (single user with single data stream, 0 byte payload + IP headers).

Figure 1-21 Performance Goals for LTE – Capacity, Mobility, Cell Coverage

CapacityAt least 200 users per cell will be supported (5 MHz). For larger spectrum allocations, up to 400 usersmay be supported.

MobilityFull 3GPP mobility will be supported and optimized for 0-15 km/h (~9 mph). Speeds from 15-120 km/h(~9-75 mph) will also be supported with high performance. Mobility will be maintained for speeds of120-350 km/h (~217 mph).

Cell CoverageThroughput, spectral efficiencies, and mobility will be met for cell ranges up to 5 km (~3 miles). For cellranges up to 30 km (~18 miles), mobility will be maintained but degradation in throughput and spectralefficiency is permitted. Cell ranges up to 100 km (~62 miles) are supported…degradation is accepted.



Lesson 1 Summary Version 3 Rev 1

Lesson 1 SummaryIn this lesson you learned about:

• The key drivers for Long Term Evolution (LTE)• The Standards Body – 3GPP – that established the goals for LTE• The GSM network evolutions and the upgrade path to LTE• The Performance Goals for LTE• The changes to the current 3G architecture brought about by LTE• The 3GPP Release 8 (LTE) Network Architecture


1-25

Version 3 Rev 1 Memory Points

Memory Points

Take a few minutes to recall key points that you may use in thenear future or that may address a current need. This is also agood opportunity to jot down a question. If the debriefing of keypoints does not address your question, ask it during this exerciseor during a break period. Be prepared to share a key point orquestion with others in the class

Key Point – Something New:

Key Point – Something Forgotten, but Relearned:

Question on what was just covered:



Lesson 2: LTE Network Architecture Version 3 Rev 1

Chapter 2

Lesson 2: LTE Network Architecture

In this lesson, we will discuss the network elements that comprise the LTE network; the Evolved UniversalTerrestrial Radio Access Network (E-UTRAN) and the Evolved Packet Core (EPC). We will then look atMotorola’s LTE solution.


2-1

Version 3 Rev 1 Lesson 2: LTE Network Architecture




Objectives Version 3 Rev 1

ObjectivesAt the completion of this lesson, you’ll be able to:

• State the functional blocks that comprise an LTE network• Explain the function of the network elements that comprise the Evolved Universal Terrestrial

Radio Access Network (E-UTRAN)• Explain the function of the network elements that comprise the Evolved Packet Core (EPC)• Describe Motorola’s LTE network architecture


2-3

Version 3 Rev 1 3GPP Release 8 Network Architecture (LTE)


Figure 2-1 3GPP Release 8 Network Architecture (LTE)

As we discussed in Lesson 1, the Evolved Universal Terrestrial Radio Access Network (E-UTRAN)and Evolved Packet Core (EPC) make-up the overall LTE architecture. In Lesson 2, we will discuss thenetwork elements that comprise the E-UTRAN and EPC.

The graphic above illustrates the E-UTRAN and EPC architecture we will discuss, in itssimplest form.After we have discussed the function of each of the network elements in the graphic, wewill expand and explain the “rest” of the system.




3GPP Release 8 Network Architecture (LTE)evolved Node B (eNodeB)

Figure 2-2 eNodeB

The eNodeB is responsible for the following functions:

• Radio Resource Management (RRM) – assignment, reassignment, and release of radio resources• Header compression and encryption of user data streams• Routing user plane data to S-GW• Scheduling and transmission of paging messages received from the MME• Scheduling and transmission of broadcast information received from the MME or configured from

the Element Manager• Measurement gathering for use in scheduling and mobility decisions• Radio Protocol Support• Transfer of Non-Access Stratum (NAS) signaling• Access Stratum (AS) Signalling• SAE (EPC) Bearer activation/deactivation• Lawful Intercept• MME selection for handovers with MME change


2-5


3GPP Release 8 Network Architecture (LTE)User Entity (UE)

Figure 2-3 User Entity

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.

LT

E30

0

Telecoms

3GPP TS 36.101 User Equipment (UE) Radio Transmission and Reception




3GPP Release 8 Network Architecture (LTE)Mobility Management Entity (MME)

Figure 2-4 Mobility Management Entity (MME)

The MME helps authenticate UEs onto the system, tracks active and idle UEs, and pages UEs whentriggered by the arrival of new data.When a UE attaches to an eNodeB, the eNodeB selects an MME. The MME in turn selects the ServingGateway (S-GW) and the Packet Data Network Gateway (P-GW) that will handle the user’s bearerpackets.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


2-7



Serving Gateway (S-GW)

Figure 2-5 Serving Gateway (S-GW)

The S-GW routes and forwards user data packets, terminates downlink data for idle UEs, and is also thelocal mobility anchor for inter-eNodeB handovers. The mobility anchor function applies to both a UE inthe E-UTRAN and other 2G/3G technologies. The S-GW also maintains a buffer for each idle UE andholds the packets until the UE is paged and an RF channel is re-established. For each UE associatedwith 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





Packet Data Network Gateway (P-GW)

Figure 2-6 Packet Data Network Gateway (P-GW

The P-GW is responsible for the UE IP address assignment and provides UE connectivity to the externalpacket 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 packetdata networks, it may have connectivity to more than one P-GW.Other P-GW functions include:

• Mobile IP / Proxy Mobile IP (MIP/PMIP) anchor point across E-UTRAN and non 3GPPtechnologies (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


2-9



Other EPC Network Elements

Figure 2-7 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 MMEfor authenticating and authorizing UEs. It also stores the location information of the UE which is used foruser mobility and inter-technology handovers (similar to the GSM HLR/VLR). The HSS communicateswith the MME using Diameter protocol.

Policy and Charging Rules Function (PCRF)The PCRF creates rules for setting policy and charging rules for the UE. It provides network control forservice 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• Provides the S-GW with QoS policy and traffic flow mapping information

Packet Lawful Intercept Gateway (P-LIG)The P-LIG provides the interface between the LTE access network and Law Enforcement Agencies(LEAs), enabling the LEAs to intercept UE communications carried by a carrier.




3GPP Release 8 Network Architecture (LTE)Interworking with Other Technologies

Figure 2-8 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 ofdata packets to and from UEs within its geographical service area. The SGSN provides the interfacesbetween 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-3GPPaccess technologies include WiFi, WiMAX, fixed access such as cable or DSL, and so on. SystemArchitecture 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 businessdecision and does not depend on the access network technology.


2-11


3GPP Release 8 Network Architecture (LTE)Figure 2-9 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-3GPPnetwork. 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). TheePDG also authenticates, authorizes, and enforces QoS policies in conjunction with the 3GPP AAAserver.

3GPP AAA ServerThe 3GPP AAA server provides Authentication, Authorization, and Accounting (AAA)services foruntrusted, non-3GPP IP access.





eNodeB Reference Points

Figure 2-10 eNodeB Reference Points

• S1-MME – Carries control plane traffic between E-UTRAN and MME.• S1-U - Carries bearer plane traffic between the eNodeB and S-GW.• S5 – Carries control and bearer traffic between an S-GW and P-GW located in the same network.• S6a - Carries context and other information between the HSS and MME.• S8 – Carries control and bearer traffic between an S-GW and P-GW located in different networks.• S10 - Carries context and other information between MMEs.• S11 – Carries control traffic between MME and the S-GW for session management functions.• SGi – Carries bearer information between the P-GW and the external data network.• Uu - Air interface from eNodeB to UE.• X2 - Connects eNodeBs. The X2 is used for mobility control, bearer forwarding, and load

management.


2-13

Version 3 Rev 1 Motorola LTE Architecture

Motorola LTE Architecture

Figure 2-11 Motorola LTE Architecture

In this section, we will discuss the platforms used for the Motorola suggested minimum offering; theeNodeB; the Wireless Broadband Controller (WBC) 700 MME, the Wireless Broadband Controller(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 theLTE Network Elements.



Motorola LTE Architecture Version 3 Rev 1

Motorola LTE ArchitectureeNodeB

Figure 2-12 eNodeB Types

Motorola’s eNodeB consists of a site control / baseband chassis and a radio unit. The control / basebandchassis leverages the BCUII platform from the WiMAX Access Point (AP).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 mountedindoors in a 19” rack.


2-15



Wireless Broadband Controller (WBC) 700

Figure 2-13 Wireless Broadband Controller (WBC) 700

Motorola’sWireless Broadband Controller (WBC) 700 performs the functions of the MME. It leveragesthe 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





Wireless Broadband Controller (WBC) 700 as S-GW

Figure 2-14 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 redundantLinux platform that can be employed in several configurations:

• Standalone S-GW or,• Standalone P-GW or,• Combined S-GW and P-GW


2-17



Wireless Broadband Core (WBC) 700 as P-GW

Figure 2-15 WBC 700 as P-GW

Wireless Broadband Manager (WBM) 700

Figure 2-16 WBM 700

The Element Management System (EMS) for the eNodeB, WBC 700 MME, WBC 700 S-GW, and WBC700 P-GW is the WBM 700. The WBM 700 leverages the implementation of the low cost referencemanagement architecture defined by the Motorola Public Safety team. The platform is comprised of acollection of Sun T5440 servers to provide the required processing and RAID disk drive array systemsto provide multiple Terabytes of storage capability.

LTE 1.0 employs one Sun Microsystems T5440 server with no RAIDsolution.





WBM 700 Features

Figure 2-17 WBM 700 Features


2-19



GSM to LTE Migration/Overlay

Figure 2-18 GSM to LTE Migration

For operators with installed GSM infrastructure, Motorola plans to provide a migration path based on theMotorola 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 withadditional spectrum, Motorola can also provide a complete LTE overlay network to work in conjunctionwith the installed GSM base.A migration to LTE in the 900/1800 band would entail:

• Hardware upgrade of the radio modem by adding the rack mounted LTE BCU• Firmware upgrade to the radio PA• Provision of an IP connection from the radio modem to link into the Evolved Packet Core (EPC)• No changes to feeders, antennas or other site ancillary equipment• No other changes to BTS cabinet (apart from LTE BCU)

Figure 2-19 GSM to LTE Overlay





CDMA LTE Overlay

Motorola will offer the ability to add LTE via a modular expansion of installed 1X or DO Universal BaseStation (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 addinga separate band within the same frame.The above illustration shows the upgrade path – adding LTE in a separate band to an existing UBS frame.

Figure 2-20 CDMA LTE Overlay

The Motorola LTE eNodeB will also support site co-location with non-Motorola equipment in an “overlay”solution.The migration of 3GPP2 service providers to E-UTRAN/EPC involves the overlay of the EPC networkelements and the potential to use the EV-DO BTS frame to deploy both the baseband and radio headE-UTRAN components (as discussed on the previous page).


2-21


Motorola LTE ArchitectureCDMA 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 3Gmobile phone systems. 3GPP2 working groups and standards are found at www.3gpp2.org.

CDMAOneIntroduced in 1993, CDMAOne was based on the IS-95 standard. Like its counterpart GSM, CDMAOneis a voice and low speed circuit switched data network that provides circuit switched data rates of 14.4kbps.

CDMA2000 1xSimilar to GPRS, CDMA2000 added packet switching to CDMAOne. The packet switching networkinitially supported peak data rates of 153 kbps in both downlink and uplink. 1x refers to the number ofCDMA 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 forFDD operation. In commercial networks, Rev 0 supports an average 300-700 kbps downlink and 70-90kbps uplink. The UL rate does not provide adequate bandwidth for real-time services. The packet datanetwork provides an “always-on” IP service.

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.8Mbps. In commercial networks, Rev A supports an average 450-800 kbps downlink and 300-400 kbpsuplink. The improved UL bandwidth and low average latency (<50 ms) allow Rev A to support real-timeservices. Rev A is an all-IP service, supporting Voice over IP (VoIP).




Motorola LTE ArchitectureCDMA 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 incorporatesOrthogonal Frequency Division Multiplexing (OFDM) and Multiple In Multiple Out (MIMO) in theair interface.

UMB (Ultra Mobile Broadband)Ultra Mobile Broadband was intended as the next evolutionary step beyond Rev B, incorporatingimproved MIMO performance and so on. After Qualcomm dropped support for UMB, this step isessentially dead.


2-23

Version 3 Rev 1 Self-Organizing Network (SON)

Self-Organizing Network (SON)

SON DefinitionA self-organizing network is a network that can automatically extend, change, configure, and optimizeits topology, coverage, capacity, cell size, and channel allocation based on changes in location, trafficpattern, 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 whichneighbor 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 standardsbodies move towards next generation networks, the ability to automate network management hasbecome an important requirement.The objective is to minimize the cost of running a network by eliminating manual configuration – usingexpensive dedicated resources – of equipment at the time of deployment as well as dynamicallyoptimizing radio network performance during operation.

Motorola SON Architecture

Figure 2-21 Motorola SON Architecture

The Motorola SON architecture places little responsibility of the SON functionality at the EMS layer. Thisdesign when combined with the intelligence and autonomous nature of the Motorola NE’s, creates anEMS layer upon which there is little dependence for vital, daily operations. The Motorola LTEManagerprovides support for operators related to the networks SON functions such as, SON enable/disable



Self-Organizing Network (SON) Version 3 Rev 1

Self-Organizing Network (SON)controls, verification of SON optimization recommendations (establishing trust), and full trackingof all manual and automated configuration changes. The LTEManager also provides NE softwaremanagement including automated software upgrade and activation. The Motorola SON architecturealso provides for a centralized SON function to support optimization and configuration capabilitiesrequired which span across the network or multiple NE types.

Proposed Motorola SON FeaturesBasic Auto Operations

Autonomous Inventory, auto detection, test and configuration of hardware on insert

Near Real-Time PM reporting

Automatic EMS Software Upgrade

Automatic NE Software Upgrade

Dynamic Configuration of signaling links

Automatic generation of radio, HO configuration parameters

Auto Backup and restore

Advanced Auto Operations

Resource outage detection and action, e.g. Sleeping Cell

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 config update

Self discovery of new NE resources

Advanced Deployment

Auto-test NE

Auto-compute antenna loss at eNB

Interference Coordination and Control

Exchange of metrics over X2 interface to enable coordination of determining edge of cellPhysical Radio Resource Blocks

Motorola enhanced Algorithm

Automatic Neighbor Relationships

eNB discovers new neighbors (eNB directed UE measurements), deletes stale neighbors

Operator control of on-demand, periodic, white/black list

Dynamic configuration of X2 signaling link

Subscriber Trace Support

NE support for trace on per-subscriber identity (IMSI) and per-equipment identity (IMEI) basis


2-25

Version 3 Rev 1 Lesson 2 Summary

Lesson 2 SummaryIn this lesson you learned about:

• The function of the eNodeB• The functions of the Network Elements in the Evolved Packet Core (EPC); MME, S-GW, P-GW• Traffic Areas and Pooling (MME and S-GW) concepts• How LTE interworks with other technologies• Motorola’s LTE architecture• Motorola’s migration paths from GSM/CDMA to LTE



Memory Points Version 3 Rev 1

Memory Points






2-27

Lesson 3: LTE Air Interface Version 3 Rev 1

Chapter 3

Lesson 3: LTE Air Interface

In this lesson, we will discuss LTE Radio Frequency parameters, OFDM concepts, LTE Frame structure, OFDMAand SC-FDMA operation, modulation and coding schemes, and LTE antenna systems.


3-1

Version 3 Rev 1 Lesson 3: LTE Air Interface





ObjectivesAt 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• Compare OFDMA and SC-FDMA usage in LTE• Describe LTE antenna systems

LT

E30

0

Telecoms

3GPP TS 36.201; LTE Physical Layer, General Description3GPP TS 36.211; Physical Channels and Modulation3GPP TS 36.212; Multiplexing and Channel Coding3GPP TS 36.213; Physical Layer Procedures3GPP TS 36.214; Physical Layer Measurements


3-3

Version 3 Rev 1 Radio Frequency Parameters

Radio Frequency Parameters

LTE Spectrum

Figure 3-1 LTE Spectrum

In addition to new RF bands, LTE reuses the cellular IMT-2000 spectrum. Because the initial focus is onFrequency Division Duplexing (FDD) operation, LTE needs paired spectrum. An important objectivefor LTE is RF band coordination to facilitate roaming across each of the global regions.

Channel Bandwidth

Figure 3-2 Channel Bandwidth



Radio Frequency Parameters Version 3 Rev 1

Radio Frequency ParametersExtremely small channel sizes (1.4 and 3 MHz) are useful in the lower RF bands (such as 700 MHz).Larger channel sizes are more appropriate for the higher and larger RF bands.

3GPP LTE Spectrum

E-EUTRA Frequency Bands and Channel Bandwidth

E-EUTRABAND

Uplink (UL) Downlink (DL) DuplexMode

Channel BW Supported

1 1920–1980 MHz 2110–2170MHz

FDD 5, 10, 15, 20 MHz

2 1850–1910 MHz 1930–1990MHz

FDD 1.4, 3, 5, 10, 15Note1, 20Note1 MHz

3 1710–1785 MHz 1805–1880MHz

FDD 1.4, 3, 5, 10, 15Note1, 20Note1 MHz

4 1710–1755 MHz 2110–2155MHz

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–2690MHz

FDD 5, 10, 15, 20Note1 MHz

8 880–915 MHz 925–960 MHz FDD 1.4, 3, 5, 10Note1 MHz

9 1749.9–1784.9MHz

1844.9–1879.9MHz

FDD 5, 10, 15Note1, 20Note1 MHz

10 1710–1770 MHz 2110–2170MHz

FDD 5, 10, 15, 20 MHz

11 1427.9–1452.9MHz

1475.9–1500.9MHz

FDD 5, 10Note1, 15Note1, 20Note1 MHz

12 698–716 MHz 728–746 MHz FDD 1.4, 3, 5Note1, 10Note1 MHz

13 777–787 MHz 746–756 MHz FDD 1.4, 3, 5Note1, 10Note1 MHz

14 788–798 MHz 758–768 MHz FDD 1.4, 3, 5Note1, 10Note1 MHz...

17 704–716 MHz 734–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.


3-5

Version 3 Rev 1 Radio Frequency Parameters

Radio Frequency ParametersE-UTRA is designed to operate in the RF bands listed above.

LT

E30

0

Telecoms

3GPP TS 36.101 E-UTRA UE Radio Transmission and Reception

Channel Sampling Frequency

Figure 3-3

What is the “actual” channel bandwidth? We must “over-sample” the nominal channel bandwidth toaccount for guard bands and orthogonal spacing of subcarriers. The resulting channel bandwidth iscalled the Sampling Frequency (SF).The table shows the Sampling Frequency for each supported channel size. We will use FS to calculatesubcarrier spacing.Sampling Frequencies

Nominal Channel Bandwidth

Parameters 1.4 MHz 3 MHz 5 MHz 10 MHz 15 MHz 20 MHz

Sampling Freq(Fs)

1.92 MHz 3.84 MHz 7.68 MHz 15.36 MHz 23.04 MHz 30.72 MHz



Orthogonal Frequency Division Multiplexing (OFDM) Version 3 Rev 1

Orthogonal Frequency Division Multiplexing (OFDM)

Figure 3-4 Orthogonal Frequency Division Multiplexing (OFDM)

Orthogonal Frequency Division Multiplexing (OFDM) divides the channel bandwidth into lowerbandwidth subcarriers. Each subcarrier uses a different, equally-spaced center frequency to carrymodulated data or reference signals.All data subcarriers may be modulated for simultaneous transmission during a time interval called thesymbol time.Orthogonal Frequency Division Multiple Access (OFDMA) and Single Carrier Frequency DivisionMultiple Access (SC-FDMA) add multiple access techniques to OFDM. We will discuss OFDMA andSC-FDMA later in this lesson.


3-7

Version 3 Rev 1 Orthogonal Frequency Division Multiplexing (OFDM)

Orthogonal Frequency Division Multiplexing (OFDM)Non-Orthogonal Subcarriers

Figure 3-5 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 showsnon-orthogonal frequencies; that is, the sidebands of the frequencies interfere with each other.




Orthogonal Frequency Division Multiplexing (OFDM)Orthogonal Frequencies

Figure 3-6 Orthogonal Frequencies

In OFDM the channel is divided into many equally-spaced, lower-bandwidth subcarriers. Orthogonalfrequencies are designed (spaced) so they don’t interfere with each other, and don’t require guard bandsbetween subcarriers.Do you see that the sidebands for frequencies f1 and f3 are null at frequency f2? If a receiver samplesan orthogonal subcarrier at precisely the correct (center) frequency, there is no inter-carrier interferencefrom 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


3-9


Orthogonal Frequency Division Multiplexing (OFDM)Subcarrier Transmitter Operation

Figure 3-7 Subcarrier Transmitter Operation

Imagine that every subcarrier is associated with a separate modem, and each “modem” operates ata different center frequency. Each subcarrier modulates some number of bits (called a symbol), andtransmits the modulated signal simultaneously during a time interval called the symbol time.

This example shows blocks of 4 bits modulated by each subcarrier, or 16QAMmodulation. As we will see, groups of subcarriers may use different modulation andcoding schemes during the same symbol time.




Orthogonal Frequency Division Multiplexing (OFDM)Subcarrier Receiver Operation

Figure 3-8 Subcarrier Receiver Operation

At the receiver, each subcarrier receives the modulated signal at its specific frequency, demodulates thesignal into bits, and restores the original bit pattern.

Fast Fourier Transform (FFT)

Figure 3-9 IFFT Operation

We don’t actually have hundreds or thousands of modems in each eNodeB or UE. Instead, a singlemodem performs the functions we saw on the previous pages using special algorithms called FastFourier Transforms (FFT).


3-11


Orthogonal Frequency Division Multiplexing (OFDM)A Fourier Transform converts signals between the time and frequency domains. The transmitter modemperforms Inverse Fast Fourier Transforms (IFFT) to convert the modulated signals to a single summedoutput.

From a transmitted power and radio frequency perspective, a single modem performingIFFT looks exactly like individual “mini-modems” (1 per subcarrier). For example,IFFT for 512 subcarriers generates the same output as 512 individual modems (1per subcarrier).

FFT Operation

Figure 3-10 FFT Operation

The receiving modem uses FFT processing to convert the received signal back to its constituentmodulated 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.




Orthogonal Frequency Division Multiplexing (OFDM)Scalable OFDM

Figure 3-11 Scalable OFDM

Scalable OFDM uses different numbers of subcarriers based on the channel size. For example, a 1.4MHz channel is divided into 128 subcarriers (128 FFT), while a 10 MHz channel uses 1024 subcarriers(1024 FFT). The OFDM subcarrier spacing and symbol characteristics are identical; only the FFT sizeand channel bandwidth vary.The table below shows the number of FFT (subcarriers) for each channel size.FFT and Channel Bandwidth



SamplingFreq (Fs)


NFFT 128 256 512 1024 1536 2048


3-13


Orthogonal Frequency Division Multiplexing (OFDM)Subcarrier Spacing

Figure 3-12 Subcarrier Spacing

How “big” is a subcarrier? Because the subcarrier center frequencies are equally spaced across thechannel bandwidth, we can calculate the subcarrier spacing (Δf) by dividing the Sampling Frequency(FS) by the number of subcarriersΔf = FS/NFFTCalculating Subcarrier Spacing



SamplingFreq (Fs)


NFFT 128 256 512 1024 1536 2048

SubcarrierSpacing (Δf)

For multimedia broadcast/multicast (MBMS) traffic, LTE uses 7.5 kHz subcarrierspacing.





Symbol Time

Figure 3-13 Symbol Time vs. Subcarriers

The symbol time is the time interval used across all the subcarriers for simultaneous operation andmodulation. A symbol represents one encoded/modulated block of bits, based on the modulation andcoding scheme selected for each group of subcarriers. During a symbol time, data subcarriers may carrymodulated 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 symboltime is 66.67 microseconds long. MBMS 7.5 kHz subcarriers use 133 microsecond symbols.

OFDM combines many symbol times into fixed-length, time-dependent Physical Layerframes. For LTE, a frame is exactly 10 milliseconds long. We will talk about the framestructure later in this lesson.


3-15


Orthogonal Frequency Division Multiplexing (OFDM)Multipath Delay and Inter-Symbol Interference

Figure 3-14 Multipath Delay and Inter-Symbol Interference

How do we account for multipath delay? The graphic illustrates what happens to traffic between theeNodeB and the UE. Symbol 1 is radiated out of the eNodeB, and arrives at the UE over the shortestpath, path A. However, the same symbol also arrives over paths B, C and D. If we transmit symbol 2immediately 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 guardinterval 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 1nanosecond per foot or 3.3 microseconds per kilometer. The guard interval must handle (account for)multipath delay based on the cell radius.




Orthogonal Frequency Division Multiplexing (OFDM)Cyclic Prefix

Figure 3-15 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 Prefixprocess captures the signals from the end of the symbol time and copies them to the guard interval infront of the symbol.The Cyclic Prefix guarantees a whole number of Hz per symbol time and no phase or amplitude changesduring the extended symbol time (requirements of FFT).

LTE defines two TCP sizes, normal (4.67 microseconds) and extended (16.67microseconds).


3-17


Orthogonal Frequency Division Multiplexing (OFDM)Subcarrier Types

Figure 3-16 Subcarrier Types

The DC and Guard Subcarriers are not used to carry data or reference information;they are set to null (unpowered).

DC Subcarrier

• DC Subcarrier = Subcarrier associated with the channel center frequency• DC Subcarrier is not used• If used, this subcarrier would be contaminated in the receiver by any DC leakage current

Guard Subcarriers

• Used to eliminate inter-channel interference• Guard Subcarriers are null (unpowered)How can we avoid Inter-Channel Interference (ICI) between the cells (sectors) or networks? OFDMrequires guard subcarriers at each end of the channel frequency range to avoid interference with otherchannels. Guard subcarriers are null (unpowered).

Data Subcarriers

• Carry user data• Carry messages which control the Physical Layer• Modulated based on signal quality (SNR)Data subcarriers contain modulated data bits. In the next lesson, we will see that LTE isconnection-oriented. For now, groups of data subcarriers are temporarily scheduled to carry user orcontrol connection packets.

Reference Signals

• Used to estimate signal quality• Distributed across the subcarriers





Occupied Subcarriers

Figure 3-17 Occupied Subcarriers

Occupied Subcarriers



SamplingFreq (Fs)


NFFT 128 256 512 1024 1536 2048

SubcarrierSpacing (Δf)

OccupiedSubcarriers

72 180 300 600 900 1200


3-19

Version 3 Rev 1 LTE Frame Structure

LTE Frame Structure

Figure 3-18 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. This applies to both FDD and TDD configurationsfor Frame Type 1 or 2.

Calculating the Frame Rate

1. Assuming 10 ms per frame, how many LTE frames are transmitted per second?



LTE Frame Structure Version 3 Rev 1

LTE Frame StructureLTE Frame Length and Subcarriers

Figure 3-19 LTE Frame Length and Subcarriers

This graphic shows the impact of channel bandwidth over a frame time. The vertical dimension showsthe number of subcarriers (FFT), while the horizontal dimension shows the 10 millisecond LTE frame.While the frame duration is always the same, the channel bandwidth (FFT) varies dramatically.


3-21

Version 3 Rev 1 Channel Direction

Channel Direction

Figure 3-20 Channel Direction

The Down Link (DL) carries traffic flowing from or through the eNodeB to the subscribers, while the UpLink (UL) carries traffic from the subscriber stations to the eNodeB. DL and UL bandwidth is shared bythe active subscribers in a sector.DLand UL traffic may be carried on different (pairs of) frequencies, or the same frequency. Pairedfrequency operation is called Frequency Division Duplexing (FDD), while single frequency operationis known as Time Division Duplexing (TDD).

Frequency Division Duplexing (FDD)

Figure 3-21 Frequency Division Duplexing (FDD)



Channel Direction Version 3 Rev 1

Channel DirectionFDD uses pairs of frequencies, one to transmit traffic from the eNodeB to the subscribers (DL) and oneto receive traffic from the subscribers to the eNodeB (UL).

FDD operation uses LTE Frame Type 1.

Time Division Duplexing (TDD)

Figure 3-22 Time Division Duplexing (TDD)

TDD uses a single frequency for both directions of traffic. Both DL and UL traffic are included in the same10 ms frame.

TDD operation may use LTE Frame Type 1 or 2. Frame Type 2 includes time gapsto switch the transmit direction from DL to UL.


3-23

Version 3 Rev 1 Frame Type 1 Structure

Frame Type 1 Structure

Slots

Figure 3-23 Frame Type 1 Slots

.5 msSlot.5 msSlot

Occ

upie

dS

ubca

rrie

rs10 ms Frame – Frame Type 1

Slot

16

Slot

17

Slot

18

Slot

19

Slot

12

Slot

13

Slot

14

Slot

15

Slot

8

Slot

9

Slot

10

Slot

11

Slot

6

Slot

7

Slot

4

Slot

5

Slot

2

Slot

3

Slot

0

Slot

1

Slot

16

Slot

17

Slot

18

Slot

19

Slot

12

Slot

13

Slot

14

Slot

15

Slot

8

Slot

9

Slot

10

Slot

11

Slot

6

Slot

7

Slot

4

Slot

5

Slot

2

Slot

3

Slot

0

Slot

1

.5 msSlot.5 msSlot

0 1 2 3 4 5 60 1 2 3 4 5 60 1 2 3 4 5 6

CP SymbolCP SymbolCP Symbol

• If normal TCP used, slot contains 7 symbols

• For normal TCP , symbol 0 TCPsize is 5.21 µs

• For normal TCP , symbols 1-6 TCP size is 4.67 µs

Type 1 frames are divided into 20 slots; each slot is .5 ms long. Depending on the length of the CyclicPrefix, a slot contains either 7 or 6 symbols. (As illustrated above, a slot which uses normal size CyclicPrefixes contains 7 symbols).If extended Cyclic Prefixes are used, a slot contains only 6 symbols. Every extended TCP is exactly thesame size (16.67 microseconds).For FDD operation, this frame structure occurs simultaneously for both the DL and UL on their respectivefrequencies.

For normal sized Cyclic Prefixes, the first symbol’s Cyclic Prefix is slightly larger thanthe TCP of the other symbols in the slot.



Frame Type 1 Structure Version 3 Rev 1

Frame Type 1 StructureResource Blocks and Resource Elements

Figure 3-24 Resource Blocks and Resource Elements

12 S

ubca

rrier

s(1

80 k

Hz)

Slot7 or 6 Symbols

Occu

pied

Su

bcar

riers

ResourceElement

RBRB

RBRB

RBRB

RBRB

ResourceBlock f=1

f=2

f=3

f=12

f=11

f=1

f=2

f=3

f=12

f=11

S=0 S=nS=0 S=n

Bandwidth within slots is allocated based on resource blocks. A resource block is 180 kHz (12subcarriers) in the frequency domain and one slot in the time domain. A resource element is onesubcarrier by one symbol. 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 7symbols). When using extended TCP, a resource block contains 72 resource elements (12 subcarriersby 6 symbols).

Physical and Virtual Resource Blocks3GPP standards describe physical resource blocks and virtual resource blocks. A Physical ResourceBlock (PRB) consists of consecutive subcarriers in the frequency domain and consecutive symbols inthe time domain.Virtual Resource Blocks (VRB) are mapped to physical resource blocks. A VRBmay be either localizedor distributed.

Calculating Resource Blocks per Slot

Calculating Resource Blocks per Slot



SamplingFreq (Fs)


NFFT 128 256 512 1024 1536 2048

SubcarrierSpacing(Δf)

15 kHz


3-25


Frame Type 1 StructureNominal Channel Bandwidth


OccupiedSubcarriers

72 180 300 600 900 1200

ResourceBlocks perSlot

1. Using the formula below, calculate the number of resource blocks per slot for each channel size.Occupied Subcarriers / Subcarriers per Resource Block

Reference Signals

Figure 3-25 Reference Signals

DL and UL directions use different numbers of reference signals. For the DL, 4 reference signals aredistributed in the resource block. For the UL, an entire symbol time is devoted to carrying referencesignals. Note that the graphic shows resource blocks using normal sized TCP. All of the unshadedresource elements may be used to carry modulated data or control information.

The graphic illustrates the DL reference signals used with normal TCP for a singleport antenna. Two and four port antennas use a different DL reference signal patternfor each port. Two port antennas use an 8 reference signal pattern for the DL, whilefour port antennas use a 12 reference signal pattern for the DL.





Frame Type 1 Subframes

Figure 3-26 Frame Type 1 Subframes

Adjacent slots are combined into a subframe; each subframe is 1 ms long. DL and UL bandwidthallocations are made within a subframe. In TDD operation, a subframe may be associated with eitherthe DL or UL direction.


3-27



FDD Operation – DL

Figure 3-27 FDD Operation – DL

Control information at the beginning of a DL subframe describes both DL scheduling and UL resourceallocations (grants). The DL subframe may include broadcast information, including system informationor paging. Every UE must receive and interpret the broadcast information.DL scheduling is described in the “control” information. For example, DL traffic intended for UE1 isdescribed using the starting resource block within the subframe, number of resource blocks which carrythe UE1 data, and modulation scheme selected by the eNodeB. The DL scheduling information is carriedin the Physical DL Control Channel (PDCCH).





FDD UL Operation

Figure 3-28 FDD Operation – UL

UL bandwidth allocations, also known as grants, are also described in the PDCCH. UL grants indicatethe UE, the starting resource block within the UL subframe, number of resource blocks allocated to theUE, 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 Random Access Channel. TheRandom Access Channel allows subscribers to request bandwidth, re-enter the network from idle mode,and so on.


3-29

Version 3 Rev 1 Frame Type 2

Frame Type 2

Figure 3-29 Frame Type 2

Frame Type 2 is designed exclusively for TDD operation. Similar to Frame Type 1, a Type 2 Frame is 10milliseconds long, and contains 10 1-ms subframes. With the exception of Special Subframes (Subframe1 and possibly 6), each DL or UL subframe contains two .5 ms slot; each slot contains 6 or 7 symbolperiods. 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 varyfrom frame to frame.

Special Subframe

A Special Subframe contains Downlink Pilot Timeslot (DwPTS), Guard Period (GP), and Uplink PilotTimeslot (UpPTS) fields.

• The DwPTS field contains the primary timing (slot synchronization) signal• UpPTS may be used for UL Sounding Reference Signals or the PRACH channel• GP provides a DL-to-UL guard interval



Frame Type 2 Version 3 Rev 1

Frame Type 2

Frame Type 2 UL/DL ConfigurationsFrame Type 2 UL/DL Configurations

Subframe NumberUL/DLConfig.

Dl-to-ULSwitch-PointPeriod 0 1 2 3 4 5 6 7 8 9

0 5 ms DL 1 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 V 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 V UL DL S UL UL DL

Note – In the table above, S refers to the Special Subframe format.


3-31

Version 3 Rev 1 OFDM Bandwidth Allocation

OFDM Bandwidth Allocation

Figure 3-30 OFDM Bandwidth Allocation

OFDM assigns all subcarriers for a symbol to a single user. Although a user may be allocated more thanone symbol time, OFDM was not intended to assign less than a full symbol period. That may be wasteful,depending on the actual user bandwidth requirement.

OFDMA Bandwidth Allocation

Figure 3-31 OFDMA Bandwidth Allocation



OFDM Bandwidth Allocation Version 3 Rev 1

OFDM Bandwidth AllocationOrthogonal Frequency Division Multiple Access (OFDMA) assigns bandwidth more efficiently thanOFDM. Rather than allocating all subcarriers for a symbol to a single user, OFDMA assigns resourceblocks as needed to users. LTE uses OFDMA on the DL.

LTE allocates DL (OFDMA) bandwidth based on resource blocks rather thanindividual subcarriers.


3-33

Version 3 Rev 1 OFDMA Transmitter Functions

OFDMA Transmitter Functions

Figure 3-32 OFDMA Transmitter Functions

The OFDMA transmitter must perform the following steps:

1. Channel Coding – Bits are scrambled, encoded for Forward Error Correction, and interleaved.2. Modulation – The encoded bits are grouped into 1 to 6 bit symbols and modulated using BPSK,

QPSK, 16QAM, or 64QAM.3. Channel Mapping – The modulated signals are mapped into all or part of the channel for the

required number of symbol times.4. Inverse FFT (IFFT) – This step creates the time-domain waveform by summing the modulated

subcarriers.5. Cyclic Prefix Insertion – This step attaches the Cyclic Prefix to the beginning of the symbol.6. Transmit – Power is adjusted as needed and the waveform is transmitted by one or more antenna

ports.



OFDMA Receiver Functions Version 3 Rev 1

OFDMA Receiver Functions

Figure 3-33 OFDMA Receiver Functions

The OFDMA receiver must perform the following steps:

1. Receive – The UE receives the waveform from the eNodeB.2. Cyclic Prefix Removal– The CP is removed from the front of the symbol.3. FFT – FFT recreates the frequency spectrum of the received signal, recreating the subcarriers and

their modulated bits.4. Channel Demapping – The channel mapping is reversed to discover individual user's symbols.5. Demodulation – Each modulated symbol is demodulated into its original bits.6. Channel Decoding – 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 tothe original bit stream in the transmitter.


3-35

Version 3 Rev 1 Single Carrier-Frequency Division Multiple Access (SC-FDMA)

Single Carrier-Frequency Division Multiple Access (SC-FDMA)

OFDMA IssuesLTE does not use OFDMA for the UL. OFDMA problems include:

• High Peak-to-Average Power Ratio (PAPR or PAR)• Per subcarrier equalization for all subcarriers• High sensitivity to frequency offset for mobile subscribersHigh amplitude power peaks occur when the transmitted signal is a combination of all of the subcarriers.To deal with the resulting high Peak-to-Average Power Ratio, the power amplifier must have a greaterlinear range than other technologies, such as SC-FDMA.

The eNodeB is capable of greater power and complexity than the UE. OFDMA isappropriate for DL traffic from the eNodeB to the UE. However, it was not selectedfor the UL direction.

UE RequirementsUE requirements include:

• Reduced complexity• Lower transmit power• High QoS at cell boundaries• High data ratesAlthough the eNodeB is fully capable of transmitting and receiving OFDMA symbols, the UEmust balancereduced complexity and lower transmit power requirements with support for high data rates and goodQoS at cell boundaries. For the UL, Single Carrier Frequency Division Multiple Access (SC-FDMA)was selected to meet those requirements.SC-FDMA helps with PAPR reduction by adding extra encoding steps. The modulated bits are runthrough a Discrete Fourier Transform (DFT) algorithm using a subset of subcarriers with a fixedamplitude, then mapped into a limited number of subcarriers. The normal Inverse FFT process viewsthis as a single-carrier input spread over a few subcarriers. All other subcarriers are set to null, reducingthe power (and battery) requirements in the UE. The unused subcarriers may be used by other UEs inthe cell.



Single Carrier-Frequency Division Multiple Access (SC-FDMA) Version 3 Rev 1

Single Carrier-Frequency Division Multiple Access (SC-FDMA)SC-FDMA Transmitter Functions

Figure 3-34 SC-FDMA Transmitter Functions

The SC-FDMA transmitter must perform the following steps:

1. Channel Coding – Bits are scrambled, encoded for Forward Error Correction, and interleaved.2. Modulation – The encoded bits are grouped into 1 to 6 bit symbols and modulated using BPSK,

QPSK, 16QAM, or 64QAM.3. DFT – The modulated symbols are run through an Discrete Fourier Transform (DFT) process with

a limited number of subcarriers at a fixed amplitude.4. Subcarrier Mapping – The FFT frequency domain output is mapped into part of the channel. All

other subcarriers are set to null.5. Inverse FFT (IFFT) – This step creates the time-domain waveform by adding the modulated

subcarriers. The output is called an SC-FDMA symbol.6. Cyclic Prefix Insertion – Attaches the Cyclic Prefix to the beginning of the symbol7. Transmit – Power is adjusted as needed and the waveform is transmitted.

SC-FDMA specific behavior is associated with steps 3, 4, 11, and 12. We willdiscuss these additional steps over the next few pages.


3-37


Single Carrier-Frequency Division Multiple Access (SC-FDMA)SC-FDMA Receiver Functions

Figure 3-35 SC-FDMA Receiver Functions

The SC-FDMA receiver must perform the following steps:

1. Receive – The eNodeB receives the waveform from the UE.2. Cyclic Prefix Removal – The CP is removed from the front of the symbol.3. FFT – FFT recreates the frequency spectrum of the received signal, recreating the subcarriers and

their modulated symbols received in step 54. Subcarrier Demapping – The channel mapping is reversed to discover individual user's symbols.5. Inverse DFT (IDFT) – The DFT process from step 3 is reversed to discover the time domain of the

signals.6. Demodulation – Each modulated symbol is demodulated into its original bits.7. Channel Decoding – 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 tothe original bit stream in the transmitter.



Single Carrier-Frequency Division Multiple Access (SC-FDMA) Version 3 Rev 1

Single Carrier-Frequency Division Multiple Access (SC-FDMA)OFDMA Subcarrier Encoding

Figure 3-36 OFDMA Subcarrier Encoding

Let’s compare OFDMA and SC-FDMA subcarrier encoding for twelve subcarriers for one symbol time.As shown above, our serial bit stream is modulated using QPSK. In the OFDMA example, each QPSKsymbol is encoded in parallel on a separate subcarrier. Because the eNodeB transmits over the entirerange of occupied subcarriers, the QPSK data symbols are already positioned at the desired location inthe channel bandwidth; no separate step is needed to shift the symbol location.

As described earlier, the eNodeB allocates subcarriers in units of 12 adjacentsubcarriers (a resource block).


3-39


Single Carrier-Frequency Division Multiple Access (SC-FDMA)SC-FDMA Subcarrier Encoding

Figure 3-37 SC-FDMA Subcarrier Encoding

SC-FDMA subcarrier encoding is significantly different. Instead of transmitting each data symbol ina separate subcarrier, SC-FDMA transmits M data symbols in the same subcarrier and symbol time.These “sub-symbols” are spread over M subcarriers. In other words, each SC-FDMA symbol containsM sub-symbols transmitted at the rate M times 15 kHz. As shown in the example, the value of M is 12.Unlike OFDMA, the SC-FDMA signal appears to be more like a single-carrier with each data symbolrepresented by a wide signal spanning several subcarriers.



Modulation and Coding Schemes (MCS) Version 3 Rev 1

Modulation and Coding Schemes (MCS)

Selected Transmitter Functions

Figure 3-38 Selected Transmitter Functions

Let’s discuss the first two steps of the transmission process: channel coding and modulation. In Step 1,bits are scrambled, encoded for Forward Error Correction, and interleaved.Scrambling shuffles the bit pattern to avoid long strings of 0 or 1 bits.Forward Error Correction (FEC) adds redundant bits to the transmitted data enabling the receiver tocorrect errors without requesting retransmission.In Step 2, the scrambled, interleaved, and forward error corrected bits are grouped into 2-6 bit symbolsand modulated using QPSK, 16QAM, or 64QAM.These functions are performed by both OFDMA and SC-FDMA transmitters. In either case, the receivermust reverse these actions.

Modulation Techniques Supported

• Modulation techniques supported:– BPSK – 1 bit per symbol– QPSK – 2 bits per symbol– 16QAM – 4 bits per symbol– 64QAM – 6 bits per symbol

• DL traffic uses QPSK, 16QAM, 64QAM• UL traffic uses QPSK, 16QAM, (64QAM optional)•LTE devices use QPSK, 16QAM and 64QAM to modulate data and control information. The eNodeBsupports all of these modulation techniques for the Down Link direction. However, 64QAM is optional inthe Up Link direction.


3-41

Version 3 Rev 1 Modulation and Coding Schemes (MCS)


Modulation Review

Figure 3-39 Modulation Review

Each symbol represents 1-6 bits depending on the modulation technique. Each data point represents adifferent bit pattern. QPSK bit patterns are illustrated on the graphic.





Modulation and Signal Quality

Figure 3-40 Modulation and Signal Quality

A modulation technique is selected based on the measured SNR. Subscribers located away fromthe eNodeB must use more robust modulation schemes (lower throughput), or they will experienceunacceptable data loss rates. In addition, subscribers close to a cell boundary may experience inter-cellinterference.Each modulation scheme has a threshold SNR ratio. For example, let’s assume QPSK is associatedwith SNR 9 dB, 16QAM with 15 dB, and 64QAM with 25 dB. If the SNR drops below 15 dB, the eNodeBwill instruct the UE to use QPSK modulation.


3-43

Version 3 Rev 1 Modulation and Coding Schemes (MCS)


Estimating FDD CapacityThe formula below estimates the FDD 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 DL Capacity Reference



SamplingFreq (Fs)


NFFT 128 256 512 1024 1536 2048

OccupiedSubcarriers

72 180 300 600 900 1200

ResourceBlocks perSlot

6 15 25 50 75 100

Calculating FDD DL Capacity

Assume normal sized TCP and one antenna port are used for each of the following questions. The tableabove 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.




Modulation and Coding Schemes (MCS)Calculating FDD UL Capacity

Using the formula and table from the facing page, estimate the FDD UL capacity for a given channelbandwidth and modulation scheme. Assume normal sized TCP and one antenna port are used for eachof 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.


3-45

Version 3 Rev 1 Multiple Antenna Systems

Multiple Antenna Systems

Figure 3-41 Multiple Antenna Systems

LTE Physical Layer services assume multiple port antenna systems are used. Multiple port antennasystems are implemented for the following reasons:

• Improved transmission reliability• Greater coverage or range• Reduced UE power consumption• Increased transmission throughputMultiple port antenna systems include the following:

• Single Input Multiple Output (SIMO)• Multiple Input Single Output (MISO)• Multiple Input Multiple Output (MIMO)



Multiple Antenna Systems Version 3 Rev 1

Multiple Antenna SystemsSingle Input Multiple Output (SIMO)

Figure 3-42 Single Input Multiple Output (SIMO)

In a SIMO configuration the transmitter (usually the UE) has one transmitter and the receiver (theeNodeB) has two physically separated antenna ports. The receiver picks up multiple versions of thesame signal but separated spatially. SIMO receivers use the following techniques to compute the bestreceived signal.

Switched DiversityIn Switched Diversity, the input with the best signal is chosen as the best source. The “best” signalmay be based on Signal-to-Noise Ratio (SNR) or Bit Error Rate (BER). Switched diversity is the mostsimple and inexpensive SIMO technique.

Equal Gain CombiningEqual Gain Combining is a summation of all available received signals.

Maximum Ratio CombiningInMaximumRatio Combining (MRC), each received signal has compensation applied to it before beingcombined to produce a composite single signal. This technique is particularly effective where the signalundergoes deep fading. Because fading probably occurs at different frequencies on each antenna port,the reliability of the radio link is increased.


3-47


Multiple Antenna SystemsMultiple Input Single Output (MISO)

Figure 3-43 Multiple Input Single Output (MISO)

A MISO (eNodeB) transmitter has two or more physically separated antenna ports, while the MISO (UE)receiver has one antenna. Each Tx port transmits the same information bits. In addition to data signals,reference signals are also transmitted via both antenna ports. The normal reference signal pattern issent via the first antenna port and the diversity reference signal pattern via the second antenna port.

Space-Time Transmit Diversity (STTD)In Space-Time Transmit Diversity (STTD) the same data is transmitted simultaneously over both Txports. On each port, the channel-coded data is processed in blocks of four bits, then the bits are timereversed and complex conjugated. The physical separation of the antenna ports provides the spacediversity, and the time difference derived from the bit-reversing process provides the time diversity. Thesefeatures together make the decoding process in the receiver more reliable.




Multiple Antenna SystemsMultiple Input Multiple Output (MIMO)

Figure 3-44 Multiple Input Multiple Output (MIMO)

MIMO systems contain multiple antenna ports at both the transmitter and receiver. The MIMO transmittertransmits signals using time, frequency, and space diversity. TheMIMO receiver recovers the data acrossmultiple receiving antenna ports.

MIMO antenna systems are not unique to LTE; WiMAX, WiFi, and some cellularnetworks also use MIMO. The techniques described in this topic apply to any MIMOsystem; they are not restricted to LTE.


3-49


Multiple Antenna SystemsMIMO Techniques

Figure 3-45 MIMO Techniques

Space-Time Coding (STC)Space-Time Coding (STC) provides diversity gain to combat the effects of unwanted multipathpropagation. Similar to STTD, time delayed and coded versions of the same signal are sent from thesame transmitter antenna. The codes that are used are mainly: trellis and block (less complex) codes.This improves the SNR for cell edge performance.

Spatial Multiplexing (SM)With Spatial Multiplexing, unique (different) data streams are transmitted over different antenna ports.Spatial multiplexing can double (2x2 MIMO) or quadruple (4x4 MIMO) capacity and throughput. Thistechnique gives higher capacity when RF conditions are favorable and users are closer to the eNodeB.The graphic shows spatial multiplexing with a 2x2 MIMO configuration. The receiver can identify thetransmitting antenna port for each received signal.

A combination of spatial multiplexing and space-time coding may be implemented.Depending on the RF conditions, a device may dynamically switch between thetwo MIMO techniques.




Multiple Antenna SystemsSingle User MIMO (SU–MIMO)

Figure 3-46 Single User MIMO (SU–MIMO)

MIMO supports single user MIMO and multi-user MIMO. Single User MIMO improves the performancefor a UE (via space time coding), or increases the throughput for a UE (using spatial multiplexing).

Multi-User MIMO (MU–MIMO)

Figure 3-47 Multi-User MIMO (MU–MIMO)

In multi-user MIMO, the data for different users is multiplexed onto a single time-frequency resource, sothe capacity of the cell can increase in terms of users without increasing the system bandwidth.

Switching between SU-MIMO and MU-MIMO is supported on a per UE basis. Theuse of codes and reference signals not only allows the receiver to differentiatebetween antenna streams and users, but also allows accurate channel estimation.


3-51


Multiple Antenna SystemsOpen Loop vs Closed Loop MIMO

Figure 3-48 Closed Loop MIMO

MIMO supports both open loop and closed loop control. Open loop MIMO transceivers adjust theirtransmission based on received (reference signal) measurements. This assumes no rapid feedbacktechnique is available from the UE receiver back to the eNodeB transmitter. Unfortunately, in open loopoperation, the transmitter receives no feedback regarding antenna port operation or signal strength inthe forward direction.Closed loop MIMO supports a feedback loop describing eNodeB transmitter operation and UErecommendations. Both the eNodeB and UE contain a codebook which describes possible RFparameters, for example, the phase shift between antenna ports. In closed loop MIMO, the UEdescribes eNodeB transmitter operation by returning an index into the shared codebook.Closed loop operation uses the following steps.

1. The eNodeB transmits a DL pilot channel as a reference signal on all antenna ports.2. he UE evaluates various codebook options that specify the RF parameters.3. The UE transmits its recommendations in the form of a codebook index to the eNodeB.4. The eNodeB adjusts its DL transmission to the UE based on the recommended parameters.




Lesson 3 Summary

• State the operating frequencies used by the LTE air interface• Describe OFDM subcarrier and symbol concepts• Describe LTE duplexing and framing methods• List the modulation techniques used by the LTE air interface• Compare OFDMA and SC-FDMA usage in LTE• Describe LTE antenna systems


3-53


Memory Points

Take a few minutes to recall key points that you may use in thenear future or that may address a current need. This is also a goodopportunity to jot down a question. If the debriefing of key pointsdoes not address your question, ask it during this exercise or duringa break period. Be prepared to share a key point or question withothers in the class






Lesson 4: LTE and EPC Protocol Overview Version 3 Rev 1

Chapter 4

Lesson 4: LTE and EPC Protocol Overview

In this lesson we will discuss the LTE Air Interface (Uu) sublayers, the LTE Logical and Physical Channels, andthe S1, S5, and X2 interface User and Control Plane protocol stacks.


4-1

Version 3 Rev 1 Lesson 4: LTE and EPC Protocol Overview





Objectives

• Describe the LTE Uu User and Control Plane protocol stacks• List the LTE transport, logical and physical channels• Explain the functions of the LTE physical channels• List the Uu, S1-MME, S1-U, S5-U, and X2 interface functions• Describe the S1-MME, S1-U, S5-U, S5–C and X2 User and Control Plane protocol stacks


4-3

Version 3 Rev 1 Selected EPS Interfaces

Selected EPS Interfaces


• S1-MME – Carries control plane traffic between E-UTRAN and MME.• S1-U – Carries bearer plane traffic between the eNodeB and S-GW.• S5 – Carries control and bearer traffic between an S-GW and P-GW located in the same network.• S6a – Carries context and other information between the HSS and MME.• S8 – Carries control and bearer traffic between an S-GW and P-GW located in different networks.• S10 – Carries context and other information between MMEs.• S11 – Carries control traffic between MME and the S-GW for session management functions.• SGi – Carries bearer information between the P-GW and the external data network.• Uu – Air interface from eNodeB to UE.• X2 – Connects eNodeBs. The X2 is used for mobility control, bearer forwarding, and load

management.



Selected EPS Interfaces Version 3 Rev 1

Selected EPS InterfacesEPS and the TCP/IP Protocol Suite

Figure 4-2 TCP/IP Protocol Suite

The 3GPP standards describe an all-IP network. Both control plane (signaling) traffic and user plane(bearer) traffic user the TCP/IP protocol suite. Except for the LTE air (Uu) interface, essentially any DataLink and Physical Layer protocols are allowed.3GPP mandates support for either IPv4 or IPv6, or both. Depending on the interface and traffictype, Transmission Control Protocol (TCP), User Datagram Protocol (UDP), or Stream ControlTransmission 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 controltraffic.

All bearer traffic, including voice, video and data, uses IP for transport. Either IPv4 orIPv6, or both, may be supported.


4-5

Version 3 Rev 1 Selected EPS Interfaces

Selected EPS InterfacesControl Plane

Figure 4-3 Control Plane

A control plane describes the protocol stack(s) required to transport control (signaling) traffic. TheLTE/SAE architecture distinguishes between signaling that directly controls the air interface or AccessStratum (AS), and Non-Access Stratum (NAS) signaling passed transparently from the UE to the MME.Radio Resource Control (RRC) signaling messages directly control the air (Uu) interface between theUE 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 includeradio bearer management, user paging, radio mobility control, etc.NAS messages are carried inside of RRC messages, and passed transparently through the eNodeB tothe MME. NAS actions Evolved Packet System (EPS) bearer management,GPRS Tunneling Protocol(GTP) management, security control and authentication, and so on.



Selected EPS Interfaces Version 3 Rev 1

Selected EPS InterfacesUser Plane

Figure 4-4 User Plane

A User Plane (UP) describes the protocol stack(s) required to transport “data” traffic. Data traffic includesany user bearer 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 theLTE/SAE architecture. For example, voice over IP sessions are managed usingSession Initiation Protocol (SIP). Essentially, the LTE/SAE architecture viewsSIP messages as regular data.


4-7

Version 3 Rev 1 Uu Interface Data Link Layer

Uu Interface Data Link Layer

Figure 4-5 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 protocolstacks.

Figure 4-6 RRC and PDCP Sublayer Functions



Uu Interface Data Link Layer Version 3 Rev 1


Radio Resource Control (RRC) SublayerThe Radio Resource Control (RRC) Sublayer is responsible for broadcast of system information, RRCconnection and configuration control, paging, initial security activation, mobility and handovers, recoveryfrom radio link failure and generic protocol error handling, measurement configuration and reporting, andMBMS scheduling.RRC connection and configuration control includes setting up Radio Bearer (RB) channels carrying userdata, QoS configuration, and error recovery (ARQ and HARQ) configuration.

Packet Data Convergence Protocol (PDCP) SublayerThe Packet Data Convergence Protocol (PDCP) Sublayer is responsible for transferring RRC signalingor user data, compressing data packet headers, timer-based packet discards, and encrypting packets.For signaling packets, the PDCP Sublayer also checks message integrity.

LT

E30

0

Telecoms

3GPP TS 36.331 Radio Resource Control (RRC) Protocol Specification3GPP TS 36.323 Packet Data Convergence Protocol (PDCP) Specification

Figure 4-7 RLC and MAC Sublayer Functions

Radio Link Control (RLC) SublayerThe Radio Link Control (RLC) Sublayer segments large packets and concatenates small packets forhandling by the MAC Sublayer and Physical Layer. RLC supports acknowledged, unacknowledged, andtransparent mode operation. In addition, the RLC Sublayer performs Automatic Repeat Request (ARQ)error recovery for data packets. ARQ is a retransmission error recovery technique.


4-9

Version 3 Rev 1 Uu Interface Data Link Layer


Medium Access Control (MAC) SublayerThe Medium Access Control (MAC) Sublayer performs dynamic scheduling of Physical Layerresources, and maps data and control traffic to and from the Physical Layer. The MAC Sublayermultiplexes 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 retransmissionerror recovery technique.

LT

E30

0

Telecoms

3GPP TS 36.322 Radio Link Control (RLC) Protocol Specification3GPP TS 36.321 Medium Access Control (MAC) Protocol Specification

Uu Physical Layer

Figure 4-8 Physical Layer

As discussed in the last lesson, the Uu Physical (PHY) Layer applies FEC encoding, modulates bits,and maps the modulated signals into physical frames and subframes. In addition, the Physical Layercalculates and attaches a 24-bit Cyclic Redundancy Check (CRC) to the end of the MAC PDU beforescrambling and modulating the packet.



SAE and LTE Channel Architecture Version 3 Rev 1

SAE and LTE Channel Architecture

Figure 4-9 SAE and LTE Channel Architecture

The SAE and 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.SAE BearerAn SAE bearer channel carries one or more service data flows between a UE and the EPC.Radio BearerA 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 BearerA SRB channel transports signaling packets between the RRC Sublayer and the PDCP Sublayer.Logical ChannelA logical channel transports control or data traffic between the RLC Sublayer and the MAC Sublayer.Logical control channels are mapped to SRB channels, while logical traffic channels are mapped to RBchannels. Logical channels describe the transmission reliability (RLC Acknowledged Mode, etc.).Transport ChannelA 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 informationwill be formatted before being transmitted (coding, transport block size, etc.).Physical ChannelA physical channel provides the transmission media (resource elements) through which the informationis actually transmitted. Each transport channel is mapped to a physical channel.


4-11

Version 3 Rev 1 SAE and LTE Channel Architecture

SAE and LTE Channel ArchitectureLogical Channels

Figure 4-10 Logical Channels

Logical channels provide control and data transport between the RLC and MAC Sublayers. Signalingtraffic is carried by Control Channels (CCH), and data traffic is carried by Traffic Channels (TCH).Control channels are mapped to SRB channels, and traffic channels are mapped to user plane radiobearer channels.

Figure 4-11 Logical Channel Types

Control ChannelsBroadcast Control Channel (BCCH) – DL channel used to broadcast system information.Paging Control Channel (PCH) – DL channel used to carry paging information when the network doesnot know the location of the UE.Common Control Channel (CCCH) – Carries RRC signaling when no RRC connection currently existsfor the UE.Dedicated Control Channel (DCCH) – A bidirectional control channel used to carry signaling informationwhen an RRC connection exists for the UE.Multicast Control Channel (MCCH) – Carries multicast signaling information; it controls the operationof the MTCH channel.




SAE and LTE Channel ArchitectureTraffic ChannelsDedicated Traffic Channel (DTCH) – A point-to-point channel dedicated to one UE for transmission ofuser data. The DTCH may be uplink, downlink, or both.Multicast Traffic Channel (MTCH) – A DL channel used to carry multicast data traffic.

Transport Channels

Figure 4-12 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 ChannelsBroadcast Channel (BCH) – Forwards broadcast information to the entire cell. The BCH maps to theBCCH logical channel.Paging Channel (PCH) – Forwards UE paging information to the entire cell. The PCH maps to thePCCH 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, andDTCH logical channels.Multicast Channel (MCH) – Carries multicast traffic for the entire cell. The MCH maps to the MCCHand MTCH logical channels.

Uplink Transport ChannelsUplink Shared Channel (UL-SCH) – Carries UL data and some control traffic. The UL-SCH maps tothe DCCH, CCCH, and DTCH logical channels.Random Access Channel (RACH) – Used for initial access to the cell or when a known UE needs totransmit on the PUSCH or PUCCH and does not have a valid uplink grant. The RACH is not mapped toa logical channel.


4-13

Version 3 Rev 1 SAE and LTE Channel Architecture

SAE and LTE Channel ArchitectureLogical Channel to Transport Channel Mapping

Figure 4-13 Logical Channel to Transport Channel Mapping

The graphic shows the mapping between the LTE logical channels and transport channels.

Physical Channels

Figure 4-14 DL 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 ChannelsPhysical Broadcast Channel (PBCH) – DL channel that carries broadcast information.Physical Hybrid ARQ Indicator Channel (PHICH) – Carries Hybrid ARQ (HARQ) ACKs or NACKs forthe UL transmissions on the PUSCH.Physical Control Format Indicator Channel (PCFICH) – Transmitted every subframe to inform the UEabout the number of OFDM symbols used for the PDCCH channel.Physical Downlink Control Channel (PDCCH) – Informs the UE about the resource allocation for PCHand DL-SCH, plus the HARQ information relating to the DL-SCH. It also controls the UL-SCH schedulinggrants and indicates the UE identity. The PDCCH has four formats, hence the need for the PCFICH. ThePDCCH signaling is located in the first 1–3 OFDM symbols in each subframe.




SAE and LTE Channel ArchitecturePhysical 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.Physical Multicast Channel (PMCH) – Carries the MBMS data and control if the cell supports MBMSfunctionality.

Uplink Physical Channels

Figure 4-15 UL Physical Channels

Physical Random Access Channel (PRACH) – Carries the random access preambles used when theUE makes initial contact with the network, etc.Physical Uplink Shared Channel (PUSCH) – Carries uplink data and higher layer signaling. PUSCHis 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.Physical Uplink Control Channel (PUCCH) – Carries uplink control information for a UE, including CQI,HARQ ACKs and NACKs, and UL scheduling requests.

Transport to Physical Channel Mapping

Figure 4-16 Transport to Physical Channel Mapping

The graphic shows the mapping between LTE transport channels and physical channels.


4-15

Version 3 Rev 1 Mapping DL Physical Channels to Subframes

Mapping DL Physical Channels to Subframes

Figure 4-17 Mapping DL Physical Channels to Subframes

The PDCCH, PHICH, and PCFICH control channels occupy the 1st-3rd symbols of a subframe. ThePDSCH channel occupies the remaining symbols of the subframe.The PCFICH channel is 16 resource elements long and is located in the 1st symbol. The PCFICH channelindicates how many (1-3) symbols are used by the DL control channels in this subframe.The PHICH channel is 12 resource elements long and is located in the 1st or 3rd symbol. This channelcarries the HARQ ACKs and NACKs for packets sent by a UE on the uplink.The PDCCH channel occupies the remaining resource elements in the 1st-3rd symbols (as signaled bythe PCFICH channel). The PDCCH channel describes DL traffic and UL bandwidth grants for each UE.DL traffic is carried in the PDSCH channel in the remaining symbols of the subframe.

The graphic shows the Reference Signal pattern for port 0 of a 2-port MIMOantenna. The resource elements with an “X” are powered by antenna port 1.



Mapping DL Physical Channels to Subframes Version 3 Rev 1

Mapping DL Physical Channels to SubframesBroadcast Channel

Figure 4-18 Physical Broadcast Channel

The Physical Broadcast Channel (PBCH) carries DL system bandwidth, the number of transmitantenna ports, Reference Signal transmit power, system frame number, and so on. This information iscritical for UEs attempting to enter or re-enter the network.The PBCH is located on the 72 subcarriers centered around the DC subcarrier in slot 1, symbols 0through 3. The PBCH information is spread over four consecutive LTE radio frames.

Synchronization SignalsSynchronization signals allow the UE to synchronize with the recurring slots and frames transmittedby the eNodeB. The Primary Synchronization Signal (P-SS) provides LTE slot synchronization. TheSecondary Synchronization Signal (S-SS) provides LTE frame synchronization. In both cases, thesync signals are transmitted by the eNodeB on 62 subcarriers centered around the DC subcarrier.


4-17

Version 3 Rev 1 Mapping DL Physical Channels to Subframes

Mapping DL Physical Channels to SubframesSynchronization Signals, Frame Type 1

Figure 4-19 Sync Signals, Frame Type 1

For Frame Type 1, the Primary Synchronization Signal (P-SS) is located in the last symbol of slots 0and 10. The graphic shows slots using a normal TCP, with the P-SS located in symbol 6.



Mapping DL Physical Channels to Subframes Version 3 Rev 1

Mapping DL Physical Channels to SubframesThe Secondary Synchronization Signal (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.

Synchronization Signals, Frame Type 2

Figure 4-20 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 DwPTSfield).The S-SS is carried in the last symbol of Slots 1 and 11.


4-19

Version 3 Rev 1 Mapping UL Physical Channels to Subframes

Mapping UL Physical Channels to Subframes

Figure 4-21 Mapping UL Physical Channels to Subframes

The graphic illustrates the mapping of UL physical channels to subframes. Resources for the PUSCHare allocated on a subframe basis by the eNodeB. Subcarriers are allocated in physical resource blocksand may be frequency hopped from subframe to subframe. The PUSCH may employ QPSK, 16QAM or64QAM modulation.



Mapping UL Physical Channels to Subframes Version 3 Rev 1

Mapping UL Physical Channels to SubframesMapping PUCCH to Subframes

Figure 4-22 Mapping PUCCH to Subframes

The PUCCH carries uplink control information such as CQI, scheduling requests, and ACKs/NACKs fora UE. It is never transmitted simultaneously with the PUSCH. As shown in the graphic, the PUCCHtransmission is frequency hopped at the slot boundary for added reliability.


4-21

Version 3 Rev 1 Mapping UL Physical Channels to Subframes

Mapping UL Physical Channels to SubframesRandom Access Channel

Figure 4-23 Random Access Preamble

The Random Access Channel (RACH/PRACH) is an UL contention-based channel which allows anyUE to request network entry, access a target cell after handover, access a cell to send a SchedulingRequest, and so on. The UE uses the PRACH channel to send a Random Access Preamble.Random Access Preambles are transmitted on blocks of 72 contiguous 1.25 kHz subcarriers allocatedfor the Physical Random Access Channel (PRACH) by the eNodeB. For burst formats 0-3, the PRACHConfiguration Index describes the burst format and subframe location within an LTE radio frame type 1.Burst Formats 2 and 3 are defined to support power balancing and low data rates at the cell edge.In addition, Frame Type 2 supports burst format 4. When using burst format 4, the UpPTS field carriesthe PRACH channel using 7.5 kHz subcarriers.

LT

E30

0

Telecoms

3GPP TS 36.211 Physical Channels and Modulation



Mapping UL Physical Channels to Subframes Version 3 Rev 1

Mapping UL Physical Channels to SubframesRandom Access Operation

Figure 4-24 Random Access Operation

The graphic shows a random access handshake.

1. The eNodeB will allocate bandwidth for the PRACH in the UL.2. As needed, a UE will send a Random Access Preamble in the PRACH.3. If successful, the eNodeB will send a Random Access Response (RAR) PDU to the UE in a

subsequent DL subframe. The RAR includes a temporary UE identity and a (small) UL resourcegrant to allow the network entry or other operation to continue.


4-23

Version 3 Rev 1 S1-MME Interface

S1-MME Interface

Figure 4-25 S1-MME Interface

The S1-MME interface is an open logical interface that carries signaling information between an eNodeBand the MME. 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

LT

E30

0

Telecoms

3GPP TS 36.410; S1 General Aspects and Principles3GPP TS 36.411; S1 Layer 1



S1-MME Interface Version 3 Rev 1

S1-MME InterfaceS1-MME Interface Control Protocol Stack

Figure 4-26 S1-MME Interface Control Protocol Stack

The graphic illustrates the S1-MME Interface signaling protocol stack. Any Physical Layer and Data LinkLayer are allowed. The IP version may be IPv6 and/or IPv4. In either case, the S1 endpoints mustsupport IP Differentiated Services (DiffServ) Code Points for QoS.Instead of using TCP or UDP, 3GPP selected Stream Control Transmission Protocol (SCTP) at Layer4. 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

LT

E30

0

Telecoms

3GPP TS 36.412; S1 Signaling Transport3GPP TS 36.413; S1 Application Program (S1AP)3GPP TS 36.411; S1 Layer 1


4-25

Version 3 Rev 1 S1-MME Interface

S1-MME InterfaceS1 Application Protocol (S1AP) Functions

Figure 4-27

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



S1-MME Interface Version 3 Rev 1

S1-MME Interface

UE to MME Control Plane

Figure 4-28 NAS Signaling Transport

The graphic illustrates the control plane between the UE and theMME, including the air (Uu) and S1-MMEinterfaces.The eNodeB interworks Access Stratum (AS) RRC and S1AP signaling; Non-Access Stratum (NAS)signaling is passed transparently from the UE to the MME.


4-27

Version 3 Rev 1 S1-U and S5-U Interfaces

S1-U and S5-U Interfaces

Figure 4-29 S1-U and S5-U Interfaces

The S1-U and S5-U interfaces forward user data traffic between the eNodeB and S-GW, and the S-GWand P-GW, respectively. Both interfaces support GPRS Tunneling Protocol (GTP) for IP mobility.

S1-U User Plane Protocol Stack

Figure 4-30 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 GTPpacket 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 theInternet Engineering Task Force (IETF)Mobile IP (MIP) standards, both GTP and MIP have the sameobjective: mobility across an IP – based network. They differ mainly in how the mobility tunnels arecreated and managed.



S1-U and S5-U Interfaces Version 3 Rev 1

S1-U and S5-U InterfacesEach data stream is carried on a dedicated transport bearer; each transport bearer is uniquely identifiedby the IP address and Tunnel Endpoint ID (TEID) of the GTP tunnel.

LT

E30

0Telecoms

3GPP TS 36.414; S1 Data Transport3GPP TS 29.274 Evolved GPRS Tunneling Protocol for EPS (GTPv2)

S5 Interface User Plane Protocol Stack

Figure 4-31 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 usesexactly the same protocol stack as the S1-U interface.


4-29

Version 3 Rev 1 S1-U and S5-U Interfaces

S1-U and S5-U InterfacesS5 Control Plane Protocol Stack

Figure 4-32 S5 Control Plane Protocol Stack

The graphic illustrates the S5 control plane protocol stack. The S5-CP interface carries signaling thatmanages the GTP tunnels between the S-GW and P-GW.

Uu to P-GW User Plane

Figure 4-33 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-Uinterfaces. 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 inanother GTP or Mobile IP tunnel and forwarded to another network. In the latter case, the P-GW willinterwork the two mobility tunnels.



X2 Interface Functions Version 3 Rev 1

X2 Interface Functions

Figure 4-34 X2 Interface

The X2 interface is an open logical interface between two adjacent eNodeBs. The X2 interface carriescontrol (signaling) information between the eNodeBs and forwards user data traffic as needed toward anS-GW or UE.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

LT

E30

0

Telecoms

3GPP TS 36.420; X2 General Aspects and Principles3GPP TS 36.421; X2 Layer 13GPP TS 36.422; X2 Signaling Transport3GPP TS 36.423; X2 Application Program3GPP TS 36.424; X2 Data Transport


4-31

Version 3 Rev 1 X2 Interface Functions

X2 Interface FunctionsX2 Control Plane Protocol Stack

Figure 4-35 X2 Control Plane Protocol Stack

The graphic illustrates the X2 Interface signaling protocol stack. Any Physical Layer and Data Link Layerare allowed. The IP version may be IPv6 and/or IPv4. In either case, the X2 (eNodeB) endpoints mustsupport Differentiated Services Code Points (DSCP) for QoS.Instead of using TCP or UDP, 3GPP selected Stream Control Transmission Protocol (SCTP) at Layer4. 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 networkfailure.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




X2 Interface FunctionsX2 Application Protocol (X2AP) Functions

Figure 4-36 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 ContextRelease.

• 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.


4-33

Version 3 Rev 1 X2 Interface Functions

X2 Interface FunctionsX2 User Plane Protocol Stack

Figure 4-37 X2 User Plane Protocol Stack

The graphic illustrates the protocol stack required to forward user data traffic over the X2 interface. Adata packet is encapsulated by the GPRS Tunneling Protocol (GTP). The GTP packet is carried byUDP/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 identifiedby the IP address and Tunnel Endpoint ID (TEID) of the GTP tunnel.

Mobility and X2 User Plane

Figure 4-38 Mobility and X2 Data Transport – 1




X2 Interface FunctionsWhy do we need X2 data transport? The X2 user plane allows side-haul of user traffic during a handoverbetween two eNodeBsSTEP

1. The GTP mobility tunnel for a UE is initially anchored at a source or originating eNodeB (eNodeB1in our example).

2. After measuring the service available from the neighbor eNodeBs, the UE signals a handover toeNB2. 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 eNodeB2.A “side-haul” tunnel is set up between eNodeB1 and eNodeB2 to forward incoming data traffic tothe user.

4. The MME instructs the S-GW to reconfigure the mobility tunnel for UE1, anchoring the tunnel ateNodeB2. After forwarding any remaining traffic between eNodeB1 and eNodeB2, the previoustunnel between the S-GW and eNodeB1 is deleted. The handover operation is now complete.

LT

E30

0

Telecoms

3GPP TS 36.424 X2 Data Transport


4-35

Version 3 Rev 1 Lesson 4 Summary

Lesson 4 Summary

• List the Uu, S1, S5, and X2 interface functions• Describe the S1, S5, and X2 User and Control Plane protocol stacks• Compare the LTE Uu User and Control Plane protocol stacks•• List the LTE logical channels• Explain the functions of the LTE physical channels



Memory Points Version 3 Rev 1

Memory Points






4-37

Lesson 5: Network Acquisition and Call Process Version 3 Rev 1

Chapter 5

Lesson 5: Network Acquisition and Call Process

In this lesson we will look at how a UE gains access to and makes a call on an LTE network. We will discuss theUE attach and registration procedures. We will then take a look at a UE initiated “call,” a typical handover, and aUE detach.


5-1

Version 3 Rev 1 Lesson 5: Network Acquisition and Call Process





Objectives

• List the UE states• Describe the UE network acquisition process• Describe the UE registration process• Describe “typical” UE call processes• Describe UE active and mobility processes• Describe the UE authentication process


5-3

Version 3 Rev 1 Basic Procedures

Basic Procedures

Figure 5-1 Basic Procedures

There are five (5) basic procedures that we are going to discuss:

• Attach• Service Request• Tracking Area Update (TAU)• Handover• DetachBefore we discuss the procedures, we need to discuss a few concepts that will be used throughout thislesson.



Radio Resource Control (RRC) States Version 3 Rev 1

Radio Resource Control (RRC) StatesLet’s look at the UE’s RRC states. Before the UE can do anything, a RRC connection must be establishedbetween the UE and E-UTRAN.

Figure 5-2 RRC and MM States

Radio Resource Control (RRC) – IdleThe 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 nosignaling 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) – ConnectIn order to register with the EPC, the UE must set-up RRC signaling with the eNodeB. This is theRRC_CONNECT state. From the RRC_CONNECT state the UE must perform:

• System acquisition• Monitor DL control channels• Send Channel Quality Information (CQI) as directed by the eNodeB• Handover

LT

E30

0

Telecoms

3GPP TS 36.331 RRC Protocol Specification


5-5

Version 3 Rev 1 Radio Resource Control (RRC) States

Radio Resource Control (RRC) StatesRadio Resource Control (RRC) Connection

Figure 5-3 RRC Connection

RRC Connection is a logical connection between E-UTRAN and UE used to carry all UE-to-eNodeB orUE-to-MME (NAS) signaling, UE location tracking, UE “state” tracking, and establish a temporary identityfor the UE (C-RNTI).After the RRC connection is set up the UE is “known” to the eNodeB, and the UE is in RRC_CONNECTstate.



EPS Mobility Management (EMM) States Version 3 Rev 1

EPS Mobility Management (EMM) States

Figure 5-4 EPS Mobility Management States

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

EPS Mobility Management (EMM) – RegisteredThe UE enters the EMM_REGISTERED state by a successful registration with an Attach procedure. Inthe EMM_REGISTERED state, the UE can receive services that require registration in the EPS.

LT

E30

0

Telecoms

3GPP TS 23.401 GPRS Enhancements for E-UTRAN Access


5-7

Version 3 Rev 1 EPS Connection Management (ECM) States

EPS Connection Management (ECM) States

Figure 5-5 EPS Connection Management States

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

EPS Connection Management (ECM) – ConnectIn the ECM_CONNECT state, a (NAS) signaling connection exists between the UE and the MME. TheUE location is known in the MME with an accuracy of a serving eNodeB ID. UE mobility is handled bythe handover procedure.

LT

E30

0

Telecoms




EPS Session Management (ESM) Version 3 Rev 1

EPS Session Management (ESM)

Figure 5-6 EPS Session Management (ESM)

The LTE standards also describe the EPS Session Management states: ESM_INACTIVE andESM_ACTIVE.

ESM_INACTIVEIn this state, the UE has no default or dedicated bearers associated with it.

ESM_ACTIVEIn this state, the UE has at least one bearer associated with it. Since the UE must be registered beforeestablishing a bearer, a UE in ESM_ACTIVE state will also be in EMM_REGISTERED state. Datatransfer may occur if the UE is in ECM_CONNECT state.

LT

E30

0

Telecoms



5-9

Version 3 Rev 1 Non Access Stratum (NAS) States

Non Access Stratum (NAS) StatesThe Non Access Stratum (NAS) state model combines EPSMobility Management (EMM) states, EPSConnection Management (ECM) states and EPS State Management (ESM) states as shown in thetable below.

Figure 5-7 NAS States

EMM-Registered,ECM-Connected and

ESM-Ac�ve

RRC: CONNECTED

RRC & EPC Context

S-TMSI, TA-ID, IP Address

UE Known at Cell Level

Handovers

UL/DL Data Transfer

EMM-Registered,ECM-Connected and

ESM-Ac�ve

RRC: CONNECTED

RRC & EPC Context


UE Known at Cell Level

Handovers

UL/DL Data Transfer

Power On

Registra�on

RRC: Null

EMM-Deregistered,ECM-Idle and ESM-

Inac�ve

No RRC or EPC Context

IMSI Iden�fier

UE Unknown

PLMN Selec�on

No Data Transfer

RRC: Null

EMM-Deregistered,ECM-Idle and ESM-

Inac�ve

No RRC or EPC Context

IMSI Iden�fier

UE Unknown

PLMN Selec�on

No Data Transfer

Service Request

TA update, paging, etc.

EMM-Registered,ECM-Idle and ESM-

Ac�ve

RRC: IDLE

EPC Context


UE Known at TA Level

TA Update

DRX on DL

EMM-Registered,ECM-Idle and ESM-

Ac�ve

RRC: IDLE

EPC Context


UE Known at TA Level

TA Update

DRX on DL

Periodic TA updateTimeout – out of area

Inac�vity

Deregistra�on

EMM_DEREGISTERED, ECM_IDLE and ESM_INACTIVEIn this state, the UE is not known by the network. The UE will use the Attach Procedure tobecome registered (known) by the network. A registration process moves a UE from this state toEMM_REGISTERED, ECM_CONNECT and ESM_ACTIVE.

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

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



Selected EPS IDs Version 3 Rev 1

Selected EPS IDs

MME IDs


Public Land Mobile Network (PLMN) Identity – Identifies the mobile network carrier. The PLMN IDconsists of the Mobile Country Code (MCC) and the Mobile Network Code (MNC).MME Group Identity (MMEGI) – Identifies the MME group in a PLMN.MME Code (MMEC) – Uniquely identifies the MME in a group.Globally Unique MME Identity (GUMMEI) – Uniquely identifies a specific MME in a PLMN. TheGUMMEI consists of the MCC + MNC +MMEGI +MMEC.


5-11

Version 3 Rev 1 Selected EPS IDs

Selected EPS IDs

UE IDs

Figure 5-9 UE Identities

International Mobile Subscriber ID (IMSI) – Uniquely identifies the subscriber within a mobile network.The IMSI is assigned by the home mobile network and stored in the SIM/USIM.International Mobile Equipment ID (IMEI) – Uniquely identifies the subscriber equipment type. TheIMEI is stored in the device.Cell Radio Network Temporary ID (C-RNTI) – A temporary ID used by the eNodeB for schedulingresources. The C-RNTI is assigned by the eNodeB. The C-RNTI is used by the eNodeB for schedulingresources on the DL or UL.MME Temporary Mobile Subscriber ID (M-TMSI) – A temporary ID used to identify the UE within theMME. The M-TMSI is assigned by the MME. The M-TMSI, GUTI, and S-TMSI are used by the MME toidentify a UE for paging or control procedures.Globally Unique Temporary UE ID (GUTI) – Uniquely identifies the UE within the PLMN. The GUTIconsists of the GUMMEI and the M-TMSI.SAE Temporary Mobile Subscriber ID (S-TMSI) – A smaller version of the GUTI used for paging theUE. The S-TMSI consists of the MMEC plus the M-TMSI.



Selected EPS IDs Version 3 Rev 1

Selected EPS IDs

International Mobile Subscriber Identifier (IMSI) Structure

Figure 5-10 IMSI Structure

An LTE carrier uses the International Mobile Subscriber Identifier (IMSI) to uniquely identify individualsubscribers. The IMSI consists of a country code, mobile network code, and a subscriber identificationnumber.The IMSI is stored in the LTE mobile device SIM/USIM, and signaled to the network during the initialattach process. After the subscriber attaches to a network, LTE network elements refer to the subscriberwith temporary identifiers such as C-RNTI or S-TMSI.


5-13

Version 3 Rev 1 Attaching to the Network

Attaching to the Network

Figure 5-11 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 systembroadcast 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 tocontinue 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 systeminformation 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.

eNodeB Acquisition

Figure 5-12 eNodeB Acquisition



Attaching to the Network Version 3 Rev 1

Attaching to the NetworkWhen the UE powers-up, it looks for and acquires the RF center frequency. Once it obtains the centerfrequency, it reads the timing information and syncs to the eNodeB. With the UE synchronized to theeNodeB, it may receive system broadcast information. The UE is now considered in the RRC_IDLEstate.

System Information (SI)

Figure 5-13 System Information (SI)

System information is broadcast in System Information (SI) Radio Resource Control (RRC)messages. The Master Information Block (MIB) is transmitted on the PBCH and contains the DLsystem bandwidth. After reading this information in the PBCH, a UE is able to read messages spreadacross the total number of occupied subcarriers.System Information Block Type 1 (SIB Type 1) is transmitted on the PDSCH and contains the PLMNID, cell ID, Tracking Area ID, and the scheduling for other SIB types.From the information received in System Information messages, the UE again searches the frequencybands to try to find a suitable cell. A suitable cell is one that meets cell selection criteria and is notbarred or reserved. Once it finds an acceptable cell, it camps on the cell and continues with EPC attachprocedure.

• SIB2 messages carry common and shared channel information• SIB3-SIB8 messages carry cell reselection parameters for EUTRAN and other

Radio Access Technology (RAT) neighbors• SIB 10-11 carry emergency information

LT

E30

0

Telecoms

3GPP TS 36.331 RRC Protocol Specification


5-15

Version 3 Rev 1 Attaching to the Network

Attaching to the Network

Initial Cell Selection

Figure 5-14 Initial Cell Selection

LTE uses the following cell selection procedures.

1. Initial Cell Selection requires no knowledge of which RF channels are E-UTRA carriers. The UEscans all RF channels in the E-UTRA bands to find the strongest suitable cell. Once a suitable cellis found this cell is selected.

2. Stored Information Cell Selection requires stored information of carrier frequencies and (optionally)cell parameters from previously received measurement control information or from previouslydetected cells. If no suitable cell is found based on stored information, the Initial Cell Selectionprocedure is started.

Cell Service TypesCells are categorized according to which services they offer.

• Acceptable Cell – a cell on which the UE may camp-on to obtain limited service (originateemergency calls)

• Suitable Cell – a cell on which the UE may camp-on to obtain normal service• Barred and Reserved Cells – available for operator access only. Cell barring (reserved) status is

signaled in SIB1 messages.

Network AttachA UE needs to register with the network to receive services that require registration. This registration iscalled Network Attach. The always-on IP connectivity for the UE of the EPS is enabled by establishinga default EPS bearer during the Network Attach.

Network Attach Simplified ProcedureThis simplified procedure is described in the steps and associated Figure following.



Attaching to the Network Version 3 Rev 1

Attaching to the Network1. The UE performs the RRC Connection Establishment procedure as described previously.2. During the RRC Connection Establishment procedure the UE initiates the Network Attach

procedure by the transmission, the eNodeB of an Attach Request. This message containsparameters to identify the UE (e.g. IMSI) and the UEs capabilities (e.g. Core Network (CN)capabilities).

3. Assuming no UE context for the UE exists anywhere in the network, or security checks for the UEfail, then authentication and NAS security setup procedures take place.

4. The default bearer is created between the P-GW and eNodeB by identifying GTP TEIDs and IPaddresses for all network elements. If dynamic Policy Charging Control (PCC) is deployed theP-GW performs an IP-CAN session establishment with the Policy Charging Rules Function(PCRF).

5. The RRC Connection Reconfigure message contains the EPS radio bearer id together with theradio layer context.

6. The Attach Accept is actually embedded in the S1AP message from the MME to eNodeB (partof step 4) and the RRC Connection Reconfigure (part of step 5). The Attach Accept contains theTracking Area Identity (TAI) and GUTI, hence it can derive the S-TMSI. The UE will also be giventhe PDN user IP and UL TFT and Access Point Name (APN) At this stage downlink data maybetransferred and buffered at the S-GW.

7. The Attach Complete is embedded in a Direct Transfer message to the eNodeB and an Uplink NASTransport message to the MME. The Attach Complete message contains the EPS Bearer Id, NASSequence Number etc. After the UE has obtained a PDN address, the UE can send uplink packetstowards the eNodeB which is then tunnelled to the S-GW and P-GW.

8. Upon reception of the Attach Complete the MME sends a Modify Bearer Request containing theEPS Bearer Id, eNodeB address and TEID to the S-GW. The S-GW responds with a Modify BearerResponse and the S-GW can send its buffered downlink packets.

Figure 5-15


5-17

Version 3 Rev 1 Quality of Service (QoS) / EPS Bearer

Quality of Service (QoS) / EPS Bearer

Figure 5-16 Quality of Service (QoS) / EPS Bearer

Quality of Service (QoS) parameters cannot be applied separately from the data flows to which theyrelate to. Because of this, the EPS Bearer has been added to the LTE standard.The EPS bearer is a logical connection between the UE and the P-GW. One EPS bearer is establishedwhen the UE connects to a PDN, and that remains established throughout the lifetime of the PDNconnection to provide the UE with always-on IP connectivity to that PDN. That bearer is referred to asthe default bearer. Any additional EPS bearer that is established to the same PDN is referred to as adedicated bearer. The initial bearer level QoS parameter values of the default bearer are assigned bythe network, based on subscription data. The decision to establish or modify a dedicated bearer canonly be taken by the EPC, and the bearer level QoS parameter values are always assigned by the EPC.An EPS bearer is comprised of the following elements:S5/S8 Bearer – a tunnel which transports packets between the S-GW and P-GWS1 Bearer – a tunnel which transports packets between the S-GW and eNodeBRadio Bearer – established by an RLC connection between the eNodeB and the UE (one RLC per RadioBearer)



Quality of Service (QoS) / EPS Bearer Version 3 Rev 1


Bearer Service Architecture

Figure 5-17 Bearer Service Architecture

The data flows being transported by the EPS bearer are known as Service Data Flow(s) (SDF). Each ofthem identifies both termination points Terminal Endpoint Identifier (TEID) as well as the service beingused. 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 packetfilters in the UL TFT.

• A DL TFT in the P-GW binds an SDF to an EPS bearer in the downlink direction. Multiple SDFscan be multiplexed onto the same EPS bearer by including multiple downlink packet filters in theDL TFT.

• A Radio Bearer transports the packets of an EPS bearer between a UE and an eNodeB. There isa 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 an uplink packet filter and a Radio Bearer to create the binding

between an SDF and a Radio Bearer in the uplink.• A P-GW stores a mapping between a downlink packet filter and an S5/S8 bearer to create the

binding between an SDF and an S5/S8 bearer in the downlink.• An eNodeB stores a one-to-one mapping between a radio bearer and an S1 to create the binding

between a Radio Bearer and an S1 bearer in both the uplink and downlink.• An S-GW stores a one-to-one mapping between an S1 bearer and an S5/S8 bearer to create the

binding between an S1 bearer and an S5/S8 bearer in both the uplink and downlink.


5-19

Version 3 Rev 1 Quality of Service (QoS) / EPS Bearer


QoS Parameters

Figure 5-18 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 AggregateMaximum Bit Rate (AMBR). Each EPS bearer is associated with the following bearer level QoSparameters:QoS Class Identifier (QCI) – used as a reference to access node-specific parameters that control bearerlevel packet forwarding treatment (e.g. scheduling weights, admission thresholds, queue managementthresholds, link layer protocol configuration, etc.), and that have been pre-configured by the operatorowning the eNodeB.Allocation and Retention Priority (ARP) – the primary purpose of ARP is to decide whether a bearerestablishment / modification request can be accepted or needs to be rejected in case of resourcelimitations. In addition, the ARP can be used by the eNodeB to decide which bearer(s) to drop duringexceptional resource limitations (e.g. at handover).Guaranteed Bit Rate (GBR) – applicable to bearers which require guaranteed QoS for services suchas VoIP and streaming video.Maximum Bit Rate (MBR) – maximum amount of bandwidth a GBR flow can use.Aggregate Maximum Bit Rate (AMBR) – denotes a bit rate of traffic per group of bearers and appliesto only non-guaranteed bit rate bearers. The AMBR limits the overall bit rate of all bearers associatedwith the limit for a given Packet Data Network.



Service Request Version 3 Rev 1

Service RequestA Service Request sets up or modifies an EPS bearer. Each EPS bearer has some or all of the QoScharacteristics described on the preceding pages. Three general procedures are available.

• Create Bearer – One or more EPS bearers may be created upon network entry, or as needed• Modify Bearer, UE Triggered – an existing EPS bearer may be modified based on UE-initiated

signaling• Modify Bearer, Network Triggered – an existing EPS bearer may be modified based on

network-initiated signaling (e.g. incoming call)

UE Triggered Service Request — SimplifiedSTEPS

1. The NAS Service Request is sent from the UE to MME. This informs the MME of the identity of theUE (S-TMSI), Tracking Area and Cell. A cause value is also included to indicate to the MME thereason for setting up the call (i.e. Mobile Originating Access).

2. NAS Authentication maybe performed at this stage.3. The MME sends an S1–AP Initial Context Request message to the eNodeB to activate the Radio

and EPS Bearers required.4. The eNodeB performs the RB establishment procedure for the UP, when this is complete the EPS

bearers are considered synchronized between the UE and the network.5. The UL data can now be transferred by the eNodeB to the S-GW by the routes specified in steps

3 and 4.6. The eNodeB sends an Initial Context Setup Complete message that indicates to the MME which

bearers the UE will use.7. The MME exchanges messaging with the S-GW to notify which bearers shall be used. If there are

any non-accepted bearers the MME initiates a bearer release procedure.8. The S-GW is now able to send DL packets to the UE.

Figure 5-19 UE Service Request


5-21

Version 3 Rev 1 Mobility Procedures

Mobility Procedures

Figure 5-20 Mobility

As a UE moves throughout the network, it is “listening” to system messages that help determine itslocation in the network (if it has changed Tracking Areas).Those system messages also have the UE measure and report channel quality. Among other things,the channel quality report sent back to the network can indicate that one of the neighboring cells has astronger signal than that of the current serving cell, making it a candidate for a handover.Mobility Procedures

UE State Mobility Procedure

RRC_IDLE, ECM_IDLE Tracking Area Update (TAU)

RRC_IDLE, ECM_IDLE TAU with MME/S-GW Change

RRC_CONNECT, ECM_CONNECT eNodeB Handover

RRC_CONNECT, ECM_CONNECT Handover with MME/S-GW Change

Handover to GSM/UMTS, cdma2000



Mobility Procedures Version 3 Rev 1

Mobility ProceduresTracking Area (TA)

Figure 5-21 Tracking Areas

A Tracking Area (TA) is a defined group of cells which can be used by the MME to page idle UEs. Withina 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 AreaUpdate (TAU).A Tracking Area ID (TAI) uniquely identifies the MME tracking area for paging and location updates. TheTAI consists of the Mobile Country Code (MCC), Mobile Network Code (MNC), and Tracking AreaCode (TAC).

Instead of using a single Tracking Area, the MME may supply a Tracking Area List toreduce the location update signaling from the UE. As long as the UE is located in any ofthe listed Tracking Areas, a TAU is not necessary.

MME and S-GW Pools

Figure 5-22 Network Element Pooling


5-23


Mobility ProceduresThe EPC supports MME and S-GW pools for improved mobility, geographical redundancy, and loadbalancing. A pool is a set of MMEs or S-GWs that serve a set of Tracking Areas. A pool area is definedas 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 fora UE, the selected MME will select an S-GW within the S-GW Pool supported by the cell.There is no distinct relationship between S-GW Pools and MME Pools. However the following must beconsidered when the Pools are defined:

• S-GW Pools are not tied to MME Pools• S-GW Service Areas can be a subset or a super-set of MME Pool Areas• S-GW Service Areas can overlap MME Pool Areas• MME Pool Areas can overlap S-GW Service Areas

Tracking Area Update (TAU)When the UE moves between different TAI it will have to perform a Tracking Area Update (TAU)procedure. The UE detects a change to a new TA by discovering that its current TAI is not in the list ofTAIs that the UE registered with the network, or the UE reselects an E-UTRAN cell and is not registered,or updated with the MME (e.g. periodic TAU timer expired while camping on GERAN or UTRAN), or theUE was in PMM_Connected state (e.g. URA_PCH) when it reselects an E UTRAN cell.There are four different types of TAU currently defined in 3GPP 23.401 (v8.6.0):

• TAU procedure with S-GW change• TAU procedure without S-GW change• Routing Area Update (RAU) with MME interaction and without SGW change (2G/3G to LTE)• RAU with MME interaction and with SGW change (2G/3G to LTE)In this course we shall only concentrate on the TAU procedure without S-GW change.

TAU Procedure without S-GW ChangeSTEPS

1. The trigger to start the TAU procedure has been detected by the UE.2. The UE initiates the TAU procedure by sending the eNodeB a TAU request. This contains the

UEs CN capabilities, EPS bearer status, identity, security information, old GUTI, TAI and selectednetwork. The eNodeB forwards the TAU request together with the TAI and EGCI of the cell whereit received the message to the new MME.

3. The new MME can derive the old MME (or SGSN) from the old GUTI received and sends a contextrequest to retrieve the user information including the EPS bearer contexts for the UE. The newMME may be able to maintain authentication for the UE so the authentication/security procedureslisted in step 4 might not be necessary.

4. If the integrity check in step was to fail, then the authentication procedure is mandatory. If securityis enabled in the network then ciphering procedures will be used.

5. The newMME adopts the bearer contexts received from the old MME/SGSN as the UEs EPS bearercontexts to be maintained by the new MME. The new MME verifies the EPS bearer status receivedfrom the UE with the EPS bearer contexts it maintains and releases any network resources notactively used by the UE. To do this a Modify Bearer request/Response procedure is used betweenthe MME and S-GW. If the RAT type has changed the P-GW will be informed for charging purposes,also if PCC is deployed the PCRF will be used

6. If the new MME doesn't hold any subscription data regarding this UE, this will have to be retrievedfrom the HSS.

7. The HSS cancels the subscription data from the old MME.8. The new MME responds to the UE with a TAU Accept giving the UE the new GUTI, TAI lists, EPS

bearer status etc. When the GUTI has changed the UE will respond with a TAU complete.




Mobility ProceduresFigure 5-23 Tracking Area Update

X2 HandoverThese procedures are used to handover a UE from a source eNodeB to a target eNodeB using the X2reference point. In these procedures the MME is unchanged. Two procedures are defined dependingon whether the S-GW unchanged or is relocated:

• X2–based handover without S-GW relocation• X2–based handover with S-GW relocation.In this course we will discuss the simplified 'X2–based handover without S-GW relocation' procedure. Inthe beginning of the description the UE has an ongoing data call.STEP

1. During the initial data call setup the UE would be sent via RRC signalling a Measurement Controlmessage. This contains the handover parameters needed to enable the UE to inform the eNodeBthat it has detected that it needs to do a handover. When the UE detects the need for a handoverit sends a RRC Measurement Report to the source eNodeB containing the cause value and a listof neighbor cells ranked by signal strength or quality.

2. The source eNodeB makes a decision based on the RRC Measurement Report and other factorssuch as the target eNodeB loading or type, to decide which neighbor cell the handover should bedirected to.

3. An X2–AP Handover Request is sent to the target eNodeB. This identifies the target cell id, the EPSbearers that need to be established and the physical cell id of source cell. At this stage the targeteNodeB can make a decision on whether it can except this incoming handover or not, based on itsavailable capacity. If the incoming handover can be excepted the target eNodeB will respond witha X2–AP Handover Request Acknowledge message to the source eNodeB. This contains a newC-RNTI, security and access parameters. This message gives the source eNodeB the parametersit needs to build the handover message.

4. The handover command is embedded in the RRC Connection Reconfiguration message. Thiscontains the parameters needed (sent by the target eNodeB) by the UE to perform the handover.Any EPS bearers not identified will be removed by the UE.

5. The source eNodeB sends an X2–AP SN Status Transfer message to the target eNodeB to conveythe UL/DL PDCP SN status of the SAE bearers.

6. Data can now be forwarded and buffered to the target eNodeB.


5-25


Mobility Procedures7. Using the RRC procedures the UE will synchronize to the target eNodeB, during this procedure the

UE obtains its new timing advance etc.8. At the end of the synchronization phase the UE will send the RRC Connection Reconfiguration

Complete message to the target eNodeB to confirm the successful completion of an RRCConnection Reconfiguration.

9. When the UE has arrived at the target eNodeB, downlink data forwarding by the source eNodeBcan be delivered to it.

Figure 5-24 X2 Handover – 1

STEP10. Uplink data from the UE can be delivered via the S-GW to the P-GW as the UL GTP TEID

parameters have been sent in step 3.11. The target eNodeB sends a Path Switch request message to the MME, this includes the new cell

EGCI and TAI of the target cell, also the list of EPS bearers (if any). In this case the MME willdetermine that the S-GW can continue to serve the UE.

12. The MME sends a Modify Bearer request containing the eNodeB address and TEIDs for the DLUP for all the accepted EPS bearers to the S-GW. The MME will release any non-accepted EPSbearers.

13. Once a Modify Bearer response is sent back to the MME the S-GW starts sending packets to thetarget eNodeB using the newly received address and TEIDs.

14. In order to assist the reordering function in the eNodeB, the S-GW sends one of more “end marker”packets on the old path immediately after switching the path.

15. The MME confirms the Path Switch Request message with the Path Switch Acknowledge. Anybearers which have changed will be indicated to the eNodeB.STEP

16. The Release Resource message indicates the success of the handover and informs the sourceeNodeB to release resources.




Mobility Procedures17. If the UE hasmoved to a cell in another Tracking Area (TA) then a TAU procedure will be performed.

Figure 5-25 X2 Handover – 2


5-27

Version 3 Rev 1 UE Triggered Detach (UE Switched Off)

UE Triggered Detach (UE Switched Off)This procedure describes the case where the UE camps on the E-UTRAN and a Detach Request is sentto the MME when the UE switches off.STEP

1. The UE sends the NAS message Detach request containing the GUTI and Switch Off indication tothe MME. This NAS message is used to trigger the establishment of the S1 connection if the UEwas in ECM-IDLE mode. Switch Off indicates whether Detach is due to a switch off situation or not.The eNodeB forwards this message to the MME along with the TAI and EGCI of the cell where theUE is camped.

2. The active EPS Bearers in the S-GW are deactivated by the MME sending a Delete SessionRequest to the S-GW. When the S-GW receives the Delete Session Request message from theMME it releases the related EPS Bearer Context information and sends a Delete Session Requestto the P-GW. If the P-GW employs PCEF initiated IP-CAN Session Termination procedure, thenthe PCRF will be told that the EPS Bearers are to be released. The P-GW acknowledges withDelete Bearer Response. The S-GW sends Delete Bearer Request.

3. The MME releases the S1–MME signaling connection for the UE by sending a S1 ReleaseCommand to the eNodeB with a cause value set to detach.

Figure 5-26 UE Triggered Detach



Version 3 Rev 1 UE Triggered Detach (UE Switched Off)



5-29

Version 3 Rev 1 Security in LTE

Security in LTE

Figure 5-27 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 integritymethods. The security keys used are forwarded to the eNodeB by the MME to the eNodeB after theUniversal Subscriber Identity Module (USIM) and the MME have been authenticated. NAS signaling isalso 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 signalingmessages.

• Integrity –ensures that the receiving network element is able to verify that the signaling data hasnot 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 tothe UE.

LTE Security Keys

Figure 5-28 LTE Security Keys



Security in LTE Version 3 Rev 1

Security in LTEThe 3GPP LTE standard introduces new security keys to ensure the correct protection is applied for thedifferent 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 theAuthentication process. KASME is responsible for establishing and maintaining security associations withUEs 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 andUser 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 5-29 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 AKAprocedure 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


5-31

Version 3 Rev 1 Security in LTE

Security in LTEFigure 5-30 AKA

The diagram above illustrates AKA Procedure.

Step

1 Connection or service request by the UE. The UE identifiesitself with the IMSI. This is typically done at power-on.

2 MME requests authentication information for that IMSI fromHSS.

3 HSS sends MME one (1) to five (5) authentication vectors eachcontaining RAND, AUTH, XRES and KASME.

4 The MME chooses one of the five vectors and sends the UE aUSER AUTHENTICATION REQUEST using the RAND, AUTNand KSIASME.

5 Using the RAND and its stored K secret key, the UEauthenticates the network by verifying the AUTN. The UE thengenerates the RES and sends a USER AUTHENTICATIONRESPONSE to MME.

6a MME authenticates the UE by comparing the RES sent by theUE and the XRES.

6b The CK and IK are computed in the UE the same way thatthey are computed in the HSS. This way, they never have tobe sent over the air interface.




Lesson 5 SummaryIn this lesson you learned:

• How the UE attaches to the E-UTRAN and EPC• How the UE attaches, authenticates, and registers on the LTE Network• The different RRC 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,

Tracking Area Update, and Handover “call processes”


5-33


Memory Points







lte100-motorola lte training_

Documents

wireless broadband

long term

secure web

wireless broadband

evolved packet

ip multimedia

enhanced data

radio resource