LTE Course
Short Description
LTE Course...
Description
LTE/SAE Engineering Overview Course Code: LT3600
Duration: 2 days
Technical Level: 2
... delivering knowledge, maximizing performance...
LTE courses include:
LTE/SAE Engineering Overview
LTE Air Interface
LTE Radio Access Network
Cell Planning for LTE Networks
LTE Evolved Packet Core Network
4G Air Interface Awareness
Understanding Next Generation LTE
Wray Castle – leading the way in LTE training
www.wraycastle.com
LTE/SAE Engineering Overview
LTE/SAE ENGINEERING OVERVIEW
First published May 2009 Last amended June 2009 WRAY CASTLE LIMITED BRIDGE MILLS STRAMONGATE KENDAL LA9 4UB UK
Yours to have and to hold but not to copy The manual you are reading is protected by copyright law. This means that Wray Castle Limited could take you and your employer to court and claim heavy legal damages. Apart from fair dealing for the purposes of research or private study, as permitted under the Copyright, Designs and Patents Act 1988, this manual may only be reproduced or transmitted in any form or by any means with the prior permission in writing of Wray Castle Limited. © Wray Castle Limited
LTE/SAE Engineering Overview
ii
© Wray Castle Limited
LT3600/v1.1
Introduction to LTE
LTE ENGINEERING OVERVIEW
Contents Section 1
Introduction to LTE
Section 2
OFDMA Principles
Section 3
The LTE Radio Interface
Section 4
Radio Access Protocols
Section 5
Evolved Packet Core
Section 6
Major Protocols
Section 7
EPC Operation
Glossary
LT3600/v1.1
© Wray Castle Limited
iii
LTE/SAE Engineering Overview
iv
© Wray Castle Limited
LT3600/v1.1
Introduction to LTE
Section 1
Introduction to LTE
LT3600/v1.1
© Wray Castle Limited
v
LTE/SAE Engineering Overview
vi
© Wray Castle Limited
LT3600/v1.1
Introduction to LTE
Contents
LTE Overview.......................................................................................................................................1.1 Broadband Access with LTE ................................................................................................................1.2 Architecture Terminology .....................................................................................................................1.3 LTE Development and Design Goals...................................................................................................1.4 LTE Standards Development...............................................................................................................1.5 LTE Key Technologies .........................................................................................................................1.6 Access Networks and the eNB (Evolved Node B) ...............................................................................1.7 X2 Interface..........................................................................................................................................1.8 The EPC (Evolved Packet Core) .........................................................................................................1.9 S1 Interface........................................................................................................................................1.10 Evolved Packet Core ‘S’ Interfaces....................................................................................................1.11 Data Rates and Services ...................................................................................................................1.12 E-UTRA Protocols..............................................................................................................................1.13
LT3600/v1.1
© Wray Castle Limited
vii
LTE/SAE Engineering Overview
viii
© Wray Castle Limited
LT3600/v1.1
Introduction to LTE
Objectives
At the end of this section you will be able to:
outline the evolutionary process prescribed for GSM and UMTS networks and show where LTE/SAE fits in
explain the significance of LTE in the continued progression towards converging telecommunications and entertainment markets
outline the overall performance aims for LTE
identify the key air interface, radio access and core network technologies chosen for E-UTRA
outline the basic architecture of the E-UTRAN and EPC including the eNB, the E-UTRAN interfaces and the EPC elements
explain the role of the X2 interface in the E-UTRAN
explain the role of the S1 interface and other possible S interfaces within the EPC
outline the peak and average data rates that E-UTRA promises to supply and the range of services that could be carried
describe the E-UTRA protocol stack and assign layer functions to the correct network entities
LT3600/v1.1
© Wray Castle Limited
ix
LTE/SAE Engineering Overview
x
© Wray Castle Limited
LT3600/v1.1
Introduction to LTE
100+ Mbit/s
40 Mbit/s 10 Mbit/s 400 kbit/s
LTE (4G)
UMTS/HSPA+
UMTS/HSPA
UMTS EDGE Evolution 1 Mbit/s GSM/EGPRS GSM/GPRS
150 kbit/s
50 kbit/s
LTE Overview
LTE Overview LTE (Long Term Evolution) represents the next developmental step for the 3GPP(3rd Generation Partnership Project) standards group. It provides for a continued evolutionary path from 2G GSM/GPRS, beyond 3G UMTS/HSPA and ultimately towards a 4G solution. UMTS (Universal Mobile Telecommunications System) has continued to build on the success of GSM (Global System for Mobile Communications) and momentum is gathering behind its significantly increased capability with the introduction of HSPA (High Speed Packet Access). The classic fixed and mobile telecommunications business models are undergoing enormous change with the move towards all-IP switching and a total-communications service profile. Meanwhile, the last decade has seen the Internet develop into a serious business tool and fixed broadband access is fast becoming a basic commodity. This market landscape is ready for a technology that combines broadband capabilities with an efficient scalable switching infrastructure and a flexible service delivery mechanism. LTE provides just such a solution and is designed to address growing global demand for anywhere, anytime broadband access while maintaining efficient provision of more traditional telecommunications services and maximizing compatibility and synergies with other communications systems. Although LTE most obviously represents an evolutionary path for UMTS networks it has also been designed to allow cost-effective upgrade paths from other technology starting points. For example, GSM operators now have the possibility to access 3G-like performance through EDGE (Enhanced Data rates for Global Evolution) Evolution, and this in turn can be used as a direct pathway to LTE. Similarly, the interworking capabilities of the Evolved Packet Core (EPC) make it possible for CDMA (Code Division Multiple Access) to migrate radio access from 1x or 1xEV-DO (1x Evolution – Data Only) to LTE.
LT3600/v1.1
© Wray Castle Limited
1.1
LTE/SAE Engineering Overview
Broadcast content provider
Former ‘Fixed’ Operator
Former ‘Mobile’ Operator
New market opportunities
LTE Radio Access
LTE Radio Access
New market opportunities
Broadband Access with LTE Wide-area LTE radio access combined with the EPC (Evolved Packet Core) represents a complete adoption of an all-IP (Internet Protocol) architecture, offering broadband delivery capability with the potential for bit rates of several hundred megabits per second and QoS (Quality of Service) management suitable for real-time operation of high-quality voice and video telephony. LTE has a very important role in the overall telecommunications service convergence concept. LTE could provide a key to unlocking a truly converged fixed/mobile network for the delivery of quadruple play services. Its potential bandwidth capabilities are sufficient for the support of services ranging from managed QoS real-time voice or video telephony to high-quality streamed TV. Its flat all-IP architecture means that it can act as a universal access network for a wide range of core network types.
1.2
© Wray Castle Limited
LT3600/v1.1
Introduction to LTE
LTE
SAE
EPS UE E-UTRA E-UTRAN
EPC
Architecture Terminology LTE is the term used to describe collectively the evolution of the RAN (Radio Access Network) into the E-UTRAN (Evolved Universal Terrestrial Radio Access Network ) and the RAT (Radio Access Technology) into E-UTRA (Evolved Universal Terrestrial Radio Access). SAE (System Architecture Evolution) is the term used to describe the evolution of the core network into the EPC (Evolved Packet Core). There is also a collective term, EPS (Evolved Packet System), which refers to the combined E-UTRAN and EPC.
LT3600/v1.1
© Wray Castle Limited
1.3
LTE/SAE Engineering Overview
LTE/SAE Design Aims 100 Mbit/s (downlink) and 50 Mbit/s (uplink) Increased cell edge bit rate 2-4 times better spectral efficiency Reduced radio access network latency Scalable bandwidth up to 20 MHz Interworking with 3G systems
LTE Development and Design Goals
LTE Development and Design Goals The debate about the structure and composition of LTE has been ongoing since at least 2004, with many different organizations promoting their preferred technological solutions for the systems. 3GPP brought some focus to the debate in June 2005 by publishing Technical Report TR 25.913 – Requirements for Evolved UTRA and UTRAN. TR 25.913 stated several objectives for the evolution of the radio interface and radio access network architecture. Targets included a significantly increased peak data rate, e.g. 100 Mbit/s (downlink) and 50 Mbit/s (uplink), and an increased ‘cell edge bit rate’ while maintaining the same site locations as are deployed for R99 (Release 99) and HSPA. Other objectives include significantly improved spectrum efficiency (e.g. two to four times that provided by Release 6 HSPA), the possibility for a significantly reduced radio access network latency for both C-plane and U-plane traffic, scaleable bandwidth with support for channel bandwidths up to 20 MHz, and support for interworking with existing 3G systems and non-3GPP-specified systems.
1.4
© Wray Castle Limited
LT3600/v1.1
Introduction to LTE
Phase 1
Phase 2
GSM900
GSM1800 GSM1900
Phase 2+
Rel 96-98
Rel 99
Rel 4
Rel 5
Rel 6
Rel 7
Rel 8
Rel 9
EDGE Evolution
GPRS EGPRS Rel 99 UMTS
Rel 4
Rel 5
Rel 6
Rel 7
HSDPA IMS
HSUPA
HSPA+
Rel 8
Rel 9
LTE/SAE
LTE Standards Development Since the publication of the first GSM specifications in the late 1980s, the technologies and techniques employed by GSM networks have continued to evolve and develop. GSM itself underwent a series of changes, from Phase 1 to Phase 2 and eventually to Phase 2+. Phase 2+ progressed with a series of yearly releases, starting with Release 96. UMTS was introduced as part of Release 99 and from then onwards the 3GPP 3G network technology has also been undergoing a process of evolution. The evolutions that particularly affect the air interface are mainly contained in Releases 5, 6, 7 and 8. Release 5 and 6 introduced HSPA – HSDPA (High Speed Downlink Packet Access) in Release 5 and HSUPA (High Speed Uplink Packet Access), or Enhanced Uplink, in R6. Release 7 outlines the changes necessary to deliver HSPA+ and Release 8 specifications begin to describe LTE. Some have termed LTE ‘3.9G’, while others have queried whether it should be considered to be a 4G technology.
LT3600/v1.1
© Wray Castle Limited
1.5
LTE/SAE Engineering Overview
LTE Signalling
LTE Traffic
SCTP E-UTRA M OFD
A
E-UTRAN
All-IP
EPC
A FDM C S
LTE Key Technologies Tests and evaluations carried out during 2007 eventually led to the publication of the Release 8 36series of specifications, which begin to detail the technological basis for LTE. Of the original four candidate air interface technologies, two were chosen for the final version: OFDMA (Orthogonal Frequency Division Multiple Access) and SC-FDMA (Single Carrier FDMA). OFDMA is employed on the LTE downlink and is expected eventually to provide peak data rates in excess of 300 Mbit/s in a 20 MHz channel. SC-FDMA is employed on the LTE uplink and may deliver in excess of 80 Mbit/s. In addition to the air interface technologies, LTE simplifies the range of technologies employed in other parts of the network. LTE is an ‘all-IP’ environment, meaning that all air interface, backhaul and core network interfaces will carry only IP-based traffic. The need to support different protocols for different traffic types, as was the case with R99, is therefore avoided. In this all-IP environment, layer 4 transport layer functions for signalling connections are performed using an alternative to the traditional choices, TCP (Transmission Control Protocol) or UDP (User Datagram Protocol). SCTP (Stream Control Transmission Protocol) was developed with the needs of IP-based signalling in mind and is used to manage and protect all LTE signalling services.
1.6
© Wray Castle Limited
LT3600/v1.1
Introduction to LTE
• Inter-cell RRM • Radio bearer control • Connection mobility control • Radio admission control • Measurement control • Cell configuration • Dynamic resource allocation
eNB
eNB (Evolved Node B)
Uu S1
X2
RRC PDCP
S1
RLC MAC PHY
LTE UE
Evolved Packet Core
E-UTRAN
Access Networks and the eNB (Evolved Node B)
Access Networks and the eNB (Evolved Node B) The basic building blocks of the E-UTRA access network are the eNB (Evolved Node B) plus backhaul – and nothing else. All layers of the air interface protocol stack, including the elements that previously resided in the RNC (Radio Network Controller) – RRC (Radio Resource Control), RLC (Radio Link Control) and MAC (Medium Access Control) – have been moved out to the base station. As the eNB now anchors the main backhaul link to the core network, it has also assumed responsibility for managing the PDCP (Packet Data Convergence Protocol) service, which provides header compression and ciphering facilities over the air interface. HSDPA began the process of moving RRM (Radio Resource Management) functions, such as packet scheduling, from the RNC to the Node B. In LTE, all remaining RRC functions are devolved to the eNB, meaning that there is no longer a role for a device such as the RNC. Among the RRM functions now devolved to the eNB are radio bearer control, radio admission control, connection mobility control and the dynamic allocation (via scheduling) of resources to UEs (User Equipments) in both uplink and downlink directions. Following on from innovations in R4 and R5 networks, LTE also supports the concept of flexible associations between access and core network elements, meaning that each eNB has a choice of MME (Mobility Management Entity) nodes to which to pass control of each UE. Dynamic selection of an MME for each UE as it attaches is therefore also an eNB responsibility. The eNB also receives, schedules and transmits control channel information in its cell, including paging messages and broadcast system information, both of which are received from the MMEs. The eNB also retains many of the more traditional roles associated with base stations, such as bearer management. The eNB is responsible for routing U-plane traffic between each UE and its S-GW (Serving Gateway). The complexity of the eNB and of the decisions it is required to make are therefore much greater than for a more traditional R99 Node B. LT3600/v1.1
© Wray Castle Limited
1.7
LTE/SAE Engineering Overview
X2-C X2-AP
SCTP IP Data Link Layer Physical Lyer
X2
X2-U User Plane PDUs
GTP-U UDP IP Data Link Layer Physical Layer
X2 Interface With the removal of the RNC from the access network architecture, inter-eNB handover is negotiated and managed directly between eNBs using the X2-C interface. In LTE implementations that need to support macro diversity, the X2-U interface will carry handover traffic PDUs (Protocol Data Units) between eNBs. X2-C (control plane) signalling is carried by the X2AP (X2 Application Protocol), which travels over an SCTP association established between neighbouring eNBs. X2AP performs duties similar to those performed by RNSAP (Radio Network Subsystem Application Protocol), which operates between neighbouring RNCs over the Iur interface in UMTS R99 networks. X2-U (user plane) traffic is carried by the existing GTP-U (GPRS Tunnelling Protocol – User plane), as employed in UMTS R99 networks. The facilities provided by the X2-U interface are only expected to be required if macro-diversity handover is supported. Both sub-types of the X2 interface travel over IP: SCTP/IP for the X2-C and UDP/IP for the X2-U.
1.8
© Wray Castle Limited
LT3600/v1.1
Introduction to LTE
HSS
• NAS Security • Idle state mobility handling • EPS bearer control
MME PCRF
IP network
Internet • Mobility • Anchoring
S-GW
PDN-GW EPC
The EPC (Evolved Packet Core) The reduced complexity in the RAN is mirrored by a similar reduction in the core network, where the EPC structure consists of five main nodes, although others may be required for backwardscompatibility purposes. The MME handles control plane functions related to mobility management (authentication and security) and idle mode handling (location updates and paging), in which sense it is broadly analogous to the VLR (Visitor Location Register) or GMM (GPRS Mobility Management) functions found in legacy networks. The MME is also responsible for EPC bearer control, and so handles connection control signalling. The S-GW and PDN (Public Data Network) Gateway are broadly analogous to the SGSN (Serving GPRS Support Node) and GGSN (Gateway GPRS Support Node) found in R99 networks and perform user plane handling, switching/routing and interfacing functions. Unlike legacy systems, however, bearer control has been removed from these devices and resides with the MME. The PCRF (Policy and Charging Rules Function) handles QoS and bearer policy enforcement and also provides charging and rating facilities. Subscriber management and security functions are handled by the HSS (Home Subscriber Server), which incorporates the functions of the legacy HLR (Home Location Register) and which is already familiar from R5 elements such as the IMS (IP Multimedia Subsystem). For backwards-compatibility purposes, SGSNs deployed to legacy parts of an operator’s network can be interfaced to both the MME (for mobility management) and the S-GW (for user plane flows). The MME then provides legacy systems with an interface to the HSS, and the S-GW and PDN EPC GW assume the role previously performed by the GGSN. The packet data services of legacy (GSM/GPRS, R99 and HSPA) networks and LTE/SAE systems can therefore interwork via a unified set of core network elements if required. The gateway elements form the EPC. LT3600/v1.1
© Wray Castle Limited
1.9
LTE/SAE Engineering Overview
S1-AP
MME SCTP IP Data Link Layer Physical Layer
S1-MME
User Plane PDUs
S1-U
GTP–U UDP
S-GW
IP Data Link Layer Physical Layer
S1 Interface Backhaul links to the core network are carried by the S1 interface. Following the general structure of the Iub interface which it replaces, traffic over the S1 is logically split into two types. S1-U flows carry user plane traffic and S1-MME flows carry mobility management, bearer control and direct transfer control plane traffic. Message structures for the S1-MME interface that operate between the eNB and the MME are defined by S1AP (S1 Application Protocol). The S1-MME protocol (A1AP) performs duties that can be seen as a combination of those performed by R99 RANAP (Radio Access Network Application Part) and GTP-C (GPRS Tunnelling Protocol – Control plane). To provide additional redundancy, traffic differentiation and load balancing, the S1- flex concept allows each eNB to maintain logical connections to multiple S-GWs and MMEs – there may therefore be multiple instances of the S1 interface per node. The S1-U interface employs GTP-U to create and manage user-plane data contexts between the eNB and the S-GW.
1.10
© Wray Castle Limited
LT3600/v1.1
Introduction to LTE
2G/3G SGSN
HSS
UMTS/ GPRS
S6a
S3
UTRAN/ GERAN
S4
PCRF
MME
S12
LTE
S7
S11
S1-MME
Rx+
IMS E-UTRAN
S5
S1-U
Interworking to MME
SGi
IP Services
PDN-GW
S-GW S2
WLAN or WiMAX
Evolved Packet Core ‘S’ Interfaces In addition to the S1 interface connecting the E-UTRAN to the EPC, a broader range of ‘S’ interfaces has been defined to identify interconnections between EPC nodes and external nodes. The gateways and the MME are the main new nodes in the EPC. They are interconnected via the S5 and S11 interfaces. The SGi interface provides a connection to the operator’s IP-based services. It is likely that this will include services managed through the IMS. In this respect the S6a interface connects the MME to the HSS, and the S7 interface provides access from the PCRF to the PDN-GW (Public Data Network Gateway). The S3 and S4 interfaces provide connectivity into the EPC from legacy 2G/3G SGSNs. However, the UTRAN may be connected directly to the EPC via the S12 interface. WLAN (Wireless Local Area Network) or WiMAX (Worldwide Interoperability for Microwave Access) can be supported through the EPC via the S2 interface. This would require connectivity to the MME, which is provided by interfaces and interworking functions not shown in this diagram.
LT3600/v1.1
© Wray Castle Limited
1.11
LTE/SAE Engineering Overview
Channel bandwidth Modulation and 1.4 MHz 3 MHz 5 MHz 10 MHz 20 MHz MIMO coding rate 1x1 0.9 2.2 3.6 7.2 14.4 QPSK 1/2 16QAM 1/2
1x1
1.7
4.3
7.2
14.4
28.8
16QAM 3/4
1x1
2.6
6.5
10.8
21.6
43.2
64QAM 3/4
1x1
3.9
9.7
16.2
32.4
64.8
64QAM 4/4
1x1
5.2
13.0
21.6
43.2
86.4
64QAM 3/4
2x2
7.8
19.4
32.4
64.8
129.6
64QAM 4/4
2x2
10.4
25.9
43.2
86.4
172.8
QPSK 1/2
1x1
0.9
2.2
3.6
7.2
14.4
16QAM 1/2
1x1
1.7
4.3
7.2
14.4
28.8
16QAM 3/4
1x1
2.6
6.5
10.8
21.6
43.2
16QAM 4/4
1x1
3.5
8.6
14.4
28.8
57.6
64QAM 3/4
1x1
3.9
9.7
16.2
32.4
64.8
64QAM 4/4
1x1
5.2
13.0
21.6
43.2
86.4
Source: WCDMA for UMTS: 4th Edition – Holma & Toskala (Ed)
Data Rates and Services
Data Rates and Services The potential peak data rates of 100 Mbit/s and more are only available when employing channel bandwidths of 20 MHz, which are difficult to find in most countries’ crowded radio environments. Even then, the fastest data rates will only be achievable on links that use advanced antenna techniques such as MIMO (Multiple Input Multiple Output). 2x2 MIMO, where both transmitter and receiver use two separate antennas to carry parallel streams of data over the same channel, is required for data rates of up to 170 Mbit/s, while future versions of E-UTRA that promise data rates of up to 360 Mbit/s would require 4x4 MIMO. The data rates for E-UTRA variants up to 2x2 MIMO in a 20 MHz channel are shown in the diagram. These data rates assume error coding rates of 1/2, 3/4 and 4/4, which are not currently defined in the specifications and so should only be considered to be an example of what is generically achievable with the technology. Data rates of 100 Mbit/s or more will provide users with access to almost any Internet or communications service currently available, from movie downloads and database access down to simpler communications activities such as making a telephone call or sending a text message. The capacity allocation method employed by E-UTRA has more in common with that used in HSPA than the methods used in R99 UMTS. There is no dedicated channel in LTE, meaning that bandwidth is shared between users in a flexible, on-demand way. This flexibility, coupled with the high data rates, makes E-UTRA very attractive. Although E-UTRA’s theoretical ability to provide one user in a cell with a 100 Mbit/s connection has been much discussed, network operators are more excited about the possibility of providing 1 Mbit/s connections to 100 simultaneous users in one cell.
1.12
© Wray Castle Limited
LT3600/v1.1
Introduction to LTE
User Equipment Non-Access Stratum (NAS)
eNB
RRC
RRC
PDCP
PDCP
RLC
RLC
MAC
MAC
Physical Layer
Physical Layer
Evolved Packet Core Non-Access Stratum (NAS)
E-UTRA Protocols In line with other aspects of E-UTRA, the air interface protocol stack has been designed to reduce complexity. Whereas an R99/HSPA-enabled Node B employs a protocol stack with a variety of RLC and MAC instances, an E-UTRA eNB employs a protocol stack with just one instance of each layer. The extent of the air interface protocol stack has also been reduced. In previous incarnations of UMTS some layers operated between the UE and the Node B, while most extended all the way to the RNC. With the elimination of the RNC, all air interface protocols in E-UTRA operate between the UE and the eNB.
LT3600/v1.1
© Wray Castle Limited
1.13
LTE/SAE Engineering Overview
1.14
© Wray Castle Limited
LT3600/v1.1
LTE/SAE Engineering Overview
Section 2
OFDMA Principles
© Wray Castle Limited
LTE/SAE Engineering Overview
ii
© Wray Castle Limited
LT3600/v1.1
OFDMA Principles
Contents Orthogonal Radio Carriers ...................................................................................................................2.1 Variable Channel Bandwidth................................................................................................................2.2 Factors Affecting Data Rate .................................................................................................................2.3 FFT (Fast Fourier Transform) ..............................................................................................................2.4 New Air Interface Technologies ...........................................................................................................2.5 OFDM Concepts ..................................................................................................................................2.6 The Cyclic Prefix ..................................................................................................................................2.7 Subcarrier Assignment.........................................................................................................................2.8 The ‘Brickwall’ Effect ............................................................................................................................2.9 OFDM and OFDMA............................................................................................................................2.10 OFDMA Operation .............................................................................................................................2.11 SC-FDMA Concept ............................................................................................................................2.12 SC-FDMA and OFDMA......................................................................................................................2.13 SC-FDMA Operation ..........................................................................................................................2.14 SC-FDMA Multiple Access.................................................................................................................2.15
LT3600/v1.1
© Wray Castle Limited
iii
LTE/SAE Engineering Overview
iv
© Wray Castle Limited
LT3600/v1.1
OFDMA Principles
Objectives
At the end of this section you will be able to:
list the new set of technologies employed by E-UTRAN on the air interface, including OFDMA and SC-FDMA
describe the basic concepts that underlie OFDM such as subcarriers, the cyclic prefix and symbols
explain the meaning of the term ‘orthogonality’ with reference to OFDM systems
demonstrate an understanding of the concept of orthogonal carriers and the relationship between carrier spacing and bandwidth
outline the functionality and use of the FFT (Fast Fourier Transform) in OFDM
outline the differences between OFDM and OFDMA and the benefits associated with each system
explain the basic concepts that underlie SC-FDMA as used by the E-UTRA uplink
outline the basic concepts that underlie the SCTP and the reasons for its use in EPS
LT3600/v1.1
© Wray Castle Limited
v
LTE/SAE Engineering Overview
vi
© Wray Castle Limited
LT3600/v1.1
OFDMA Principles
FDM
Carrier Spacing
Adjacent Carrier Interference
C–1 C C+1
OFDM A Centre point of subcarrier C intersects with subcarriers C–1 and C+1
Orthogonal Radio Carriers In a standard FDM (Frequency Division Multiplexing) system, the radio carriers are spaced sufficiently far apart to minimize the effects of adjacent channel interference. High-capacity FDM systems therefore require large amounts of bandwidth. For an OFDM (Orthogonal Frequency Division Multiplexing) system to work efficiently there should be as little interference as possible between adjacent subcarriers that make up the transmitted channel. To ensure minimum interference, orthogonal radio subcarriers are selected. Orthogonality among a set of adjacent radio subcarriers occurs when the peak of one subcarrier intersects with the point where the signals and harmonics produced by neighbouring subcarriers are passing through zero. This is shown at point A. The peak power frequency of subcarrier C is also the frequency at which the signals from subcarriers C+1 and C–1 pass through zero and the point at which the secondary harmonics from subcarriers C+2 and C–2 do the same. The net effect of this is that the signals radiated by adjacent subcarriers contribute no interference to signals radiating on any particular neighbouring subcarrier. Guard bands, in the form of a number of unused subcarriers, are employed at the top and bottom ends of the channel width to ensure that minimal interference is received from services occupying adjacent channels. Channel width and subcarrier spacing are vitally important in OFDM systems – if the subcarrier spacing is incorrect then adjacent subcarriers will not be orthogonal.
Further Reading: 3GPP TS 36.211, 36.300 LT3600/v1.1
© Wray Castle Limited
2.1
LTE/SAE Engineering Overview a) Initial Separation
Orthogonal Carriers
Initial Bandwidth
b) Separation Constant Non-orthogonal Carriers
Bandwidth Increased
c)
Separation Increased
Orthogonal Carriers
Bandwidth Increased
Variable Channel Bandwidth If the number of subcarriers remains fixed but the bandwidth of the overall channel is increased, the separation between the subcarriers can increase. Increased separation means that each subcarrier must increase its radiated bandwidth by a comparable amount; otherwise, the orthogonality between adjacent subcarriers will be lost. Section (a) shows a set of subcarriers operating orthogonally. Section (b) shows an example of increasing the bandwidth of the centre subcarrier without increasing the separation between it and its neighbouring subcarriers. The intersection between subcarriers no longer occurs at the ‘zero’ point. Section (c) demonstrates an increase in separation and a comparable increase in subcarrier bandwidth, which shows that the orthogonality between the subcarriers can be maintained. One way of increasing the radiated bandwidth of each subcarrier is to increase the number of modulation symbols transmitted across them, as a channel’s occupied bandwidth is proportional to its modulation rate. If more modulation symbols are transmitted it means that more data is transferred across each subcarrier, which in turn increases system throughput. The symbol rate of the system must also fit in with the requirements of the receiving equipment. To ensure that all signals are received correctly, the receiver sampling rate should be slightly higher than the bandwidth of the signal used to carry it – for example, an OFDM channel with a bandwidth of 1.75 MHz may be sampled at a rate of 2 MHz. This allows for the inclusion of a symbol guard period. The sampling frequency for a given channel bandwidth is the fundamental parameter associated with OFDM capacity planning. Once this figure is known, subcarrier spacing and symbol rates can be derived.
Further Reading: 3GPP TS 36.211, 36.300 2.2
© Wray Castle Limited
LT3600/v1.1
OFDMA Principles
Carrier Spacing Number of Carriers
Modulation Schemes
Symbol Rate Number of Null Carriers
Channel Width
Factors Affecting Data Rate The data rate achievable by an OFDM system is dependent upon several interrelated factors: channel bandwidth channel frequency band number of orthogonal subcarriers separation between subcarriers number of unused or ‘null’ subcarriers modulation scheme employed on subcarriers the optimum sample rate employed by OFDM receivers The E-UTRA OFDM-based air interface avoids the complexities associated with the interrelated dependencies of OFDM parameters by employing a fixed subchannel spacing of 15 kHz. A fixed spacing eliminates the variability between subcarrier width, symbol rate, data rate and sample rate, making it a far simpler implementation of OFDM than that used by, for example, WiMAX.
Further Reading: 3GPP TS 36.211, 36.300 LT3600/v1.1
© Wray Castle Limited
2.3
LTE/SAE Engineering Overview
Data In
Serial/Parallel Conversion
Data Out
Discrete Channels
Combined Waveform
Discrete Channels
Data In
Virtual Serial/Parallel Conversion
Parallel/Serial Conversion
Data Out
Inverse Fast Fourier Transform
Transmitted Waveform
Fast Fourier Transform
Virtual Parallel/Serial Conversion
FFT (Fast Fourier Transform) An OFDM transmitter can be thought of as comprising hundreds of separate radio modulators, all operating in parallel on different radio frequencies. Data is converted from serial to parallel and then fed to each separate modulator to be transmitted across a discrete radio channel. An OFDM receiver can be conceptualized as hundreds of separate radio receivers all demodulating the data from different radio channels. The data is then combined back into the original, serial data stream before being processed. This conceptual view of an OFDM system is useful for explaining the principles of OFDM, but would be expensive and unwieldy to produce and operate in real life. Real OFDM and DMT (Discrete MultiTone modulation) systems make use of a mathematical function known as FFT (Fast Fourier Transforms) to create the ‘parallel’ data signals required by a multicarrier system. The FFT is a more efficient form of the DFT (Discrete Fourier Transform), which itself provides a way of analysing the frequencies that make up a complex signal. Data is first converted from a serial stream to n parallel virtual branches, n being equal to the number of subcarriers being employed on the RF (Radio Frequency) channel. The modulation scheme to be employed on each subcarrier is selected and the inverse FFT system computes the characteristics of the wideband radio signal that would result if all of the signals were transmitted on a set of parallel radio carriers. This ‘combined’ signal is then transmitted across the radio channel employed by the system. The OFDM receiver takes the wideband signal it receives and passes it to an FFT. The FFT unit processes the received signal and determines the mix of parallel modulation symbols that would have had to have been combined together to produce a signal with those precise characteristics. The FFT process can output parallel virtual streams for each carrier, which can then be converted back into a serial stream of received data.
Further Reading: Anders E. Zonst, Understanding FFT Applications: A Tutorial. (Citrus Press, 2000) 2.4
© Wray Castle Limited
LT3600/v1.1
OFDMA Principles
Orthogonal Frequency Division Multiple Access (OFDMA) Single Carrier - Frequency Division Multiple Access (SC-FDMA)
New Air Interface Technologies The Long Term Evolution of UMTS requires a number of new technologies to be deployed. Chief amongst these are the technologies used to provide air interface connections. Although other technologies were considered during the consultation and development phases, 3GPP finally settled on the use of OFDMA on the downlink and SC-FDMA on the uplink. OFDMA is a well understood and widely used technology that has formed the basis of air interface services for systems such as Wi-Fi (802.11a,g and n), WiMAX (802.16), DAB (Digital Audio Broadcasting) radio and DVB-T/H/S (Digital Video Broadcasting for Terrestrial Handheld and Satellite) television systems. SC-FDMA is a more recent variation of OFDMA, which provides a similar service but in a less powerhungry way.
Further Reading: 3GPP TS 36.211, 36.300 LT3600/v1.1
© Wray Castle Limited
2.5
LTE/SAE Engineering Overview
Time Symbols 1
2
3
4
5
6
7
8
9
10
11
12
f1 f2 f3 f4 f5 f6 f7 f8 f9 f10 f11 f12 f13 f14 f15 f16
Symbol Period CP
1 OFDM Symbol
Usable Symbol
OFDM Concepts OFDM, also known as discrete multi-tone modulation and multi-carrier modulation, is an advanced form of FDM Instead of transmitting a single modulated radio signal, as would happen in a single carrier system, OFDM transmits hundreds or even thousands of separately modulated radio signals using carriers spread across a wideband channel. Each radio carrier is known as a subcarrier. Data is sent in parallel across the set of subcarriers, each subcarrier only transporting a part of the whole transmission. The modulation rate of all subcarriers in the channel is synchronized to a central source, so all modulation symbols should be transmitted at the same points in time on all subcarriers. The time period occupied by the modulation symbols on all subcarriers is known as an OFDM symbol and represents all the data being transferred in parallel at that point in time. OFDM symbols can make use of adjustable ‘guard periods’ before the ‘useable’ part of the symbol to provide protection against multipath effects. This guard period is known as a CP (Cyclic Prefix) and is created by repeating part of the modulated RF signal for a specified period of time. The achievable symbol rate is determined by the bandwidth of the channel and the spacing between the subcarriers.
2.6
© Wray Castle Limited
LT3600/v1.1
OFDMA Principles
Symbol Period CP
Usable Symbol
Last x samples of symbol
The Cyclic Prefix The OFDM cyclic prefix is designed to combat the ISI (Inter Symbol Interference) effects caused by multipaths and other channel impulse response effects. Multipaths cause ‘echoes’ of a previous part of the signal that, having travelled via a longer path than the primary component of the signal, arrive later in time. The cyclic prefix eliminates or masks the effects of ISI, as long as the cyclic prefix period is longer than the maximum delay spread suffered by the signal. The cyclic prefix is formed by taking a portion of the ‘useable’ part of each OFDM symbol and copying it onto the beginning of the symbol period. This is necessary, rather than just using a blank guard period, in order to maintain orthogonality between adjacent subcarriers at all points through the nominal symbol period. The cyclic prefix ratio has potentially significant consequences for the bandwidth efficiency of a channel, but these tend to be outweighed by the benefits in terms of minimized ISI. The use of the cyclic prefix to manage the effects of ISI is only permissible due to the comparatively long symbol duration enjoyed by OFDM-based systems. LTE’s typical total symbol duration (including the cyclic prefix) of 71.42 μsec compares with 3.69 μsec for GSM and just 0.26 μsec for WCDMA (Wideband Code Division Multiple Access). A cyclic prefix with a duration of around 5 μsec, which would be prohibitively expensive if employed by these other systems, is easily accommodated by an OFDMbased system, meaning that the more complex ISI management techniques employed by other systems are not required.
Further Reading: 3GPP TS 36.211, 36.300 LT3600/v1.1
© Wray Castle Limited
2.7
LTE/SAE Engineering Overview
Reference Signals
Lower Guard Subcarriers
DC Carrier
Data Subcarriers
Higher Frequency Guard Subcarriers
Subcarrier Assignment Different subcarriers from across the whole population of subcarriers created by an OFDM channel are assigned to perform different functions. Most subcarriers will be assigned to carry modulated user data signals. Each data subcarrier will be modulated to carry one part of the entire parallel signal being transmitted across the multitone channel. The data rate of each data subcarrier is determined by a combination of the symbol rate and the modulation scheme employed. In some OFDM variants (such as that employed by WiMAX), entire subcarriers are given over to carrying ‘pilot signals’. Pilot subcarriers allow channel quality and signal strength estimates to be made and allow other control functions, such as frequency calibration, to operate. Pilots are generally transmitted at a higher power level than data subcarriers – typically 2.5 dB higher – which serves to make them more easily acquired by receiving stations. In E-UTRA and other systems, including DVB, the same function is performed by ‘reference signals’. A reference signal, like a pilot, allows a receiving station to recalibrate its receiver and make channel estimates, but instead of occupying an entire subcarrier it is instead periodically embedded in the stream of data being carried on a ‘normal’ subcarrier. There are two types of ‘null’ subcarrier – guards and the DC carrier. Nothing is transmitted on null subcarriers. Guard subcarriers separate the top and bottom data subcarriers from any adjacent channel interference that may be leaking in from neighbouring channels and, in turn, serve to limit the interference caused by the OFDM channel. The more guard subcarriers that are assigned, the lower the amount of adjacent channel interference that will be caused or detected, but this also has an impact on the data throughput of the channel. The DC carrier is the centre subcarrier of each OFDM channel – the one that has a 0 Hz offset from the channel’s centre frequency – and is also null.
2.8
© Wray Castle Limited
LT3600/v1.1
OFDMA Principles
Nominal Channel Width
Reference
Data
Null
Frequency Steep Drop Off
The ‘Brickwall’ Effect The use of null or guard subcarriers at the top and bottom ends of each OFDM channel produces a very sudden drop-off in radiated power. Power reduces far more rapidly than at the edge of a traditional single carrier channel. This affects the level of interference caused to adjacent channels. When viewed on a spectrum analyser, the steep drop-off in power seen at the edge of an OFDM channel has been dubbed the ‘brickwall effect’. A representation of this can be seen in the diagram. The difference between the radiated power level of data subcarriers and pilots can also be seen.
LT3600/v1.1
© Wray Castle Limited
2.9
LTE/SAE Engineering Overview Symbol Periods (time) -1
0
1
2
3
4
1 2 3
User 1
4
User 2
User 3
5 6 7 OFDM
Symbol Periods (time) -1
0
1
2
3
4
1 2
User 1
3
User 3
4 5 6
User 2
7 OFDMA
OFDM and OFDMA The 3GPP E-UTRA specifications refer to the technology employed on the downlink as OFDM, whereas a more commonly accepted term for the technology employed would be OFDMA (Orthogonal Frequency Division Multiple Access). These two technologies are almost identical; the only substantial difference is in the way capacity is allocated. Allocation of capacity in OFDM systems is generally based on time division principles. Each user is allocated the full channel and all subcarriers exclusively for a certain number of symbol periods. This allocation method can be inflexible, especially when user connections do not have enough data to send to fill up the space allocated. In these situations network capacity is wasted by carrying padding. OFDMA systems allocate capacity based on a combination of time and frequency – a certain number of subcarriers for a certain number of symbol periods. This allocation method has two main benefits. Firstly, OFDMA-based systems assign capacity to connections on the basis of a number of subcarriers for a number of symbol periods, rather than assigning the entire channel to one user at a time. This allows the amount of capacity assigned to each connection to match more closely the amount of data it has queued ready to transmit. Secondly, the ability to subdivide the subcarrier population allows the link to serve more than one user at a time.
2.10
© Wray Castle Limited
LT3600/v1.1
OFDMA Principles
Transmitter
Modulation mapping e.g. QPSK symbols
01 10
10/11/01/10/10/01
I F F T
10
S/P
01 11 10
TX
01 10 01/10/10/01/11/10
10
P/S
01 11
F F T
TX
10
Receiver
OFDMA Operation The layout of a typical OFDMA transmitter/receiver pair is shown in the diagram. In most FDM variants, data is introduced in serial and then converted into n parallel streams, n being equal to the number of data subcarriers. The parallel data streams are then separately passed through error coding, interleaving and modulation stages before being transmitted. In reality, the process outlined above would take place in a DSP (Digital Signal Processor) rather than in discrete physical processing stages, and the eventual transmitted signal would be created using IFFT (Inverse FFT) techniques.
Further Reading: 3GPP TS 36.211, 36.300 LT3600/v1.1
© Wray Castle Limited
2.11
LTE/SAE Engineering Overview
Symbols 1 2 3 4 5 6 7 8 9 10 11 12
1
2
3
4
5
6
7
8
9
180 kHz channel 12 x15 kHz spacing
Symbol Period CP
Usable Symbol
SC-FDMA Concept SC-FDMA, as employed on the E-UTRA uplink, can be viewed as a power-efficient adaptation of OFDM. SC-FDMA employs subcarriers, FFTs and other OFDM concepts but is designed to provide a better PAPR (Peak to Average Power Ratio) using a narrower channel. PAPR relates to the ratio between the peak power output of a signal and its average transmit strength – the higher the peaks, the greater the range of power levels over which the transmitter is required to work. Systems such as OFDM, with a high PAPR, are not best suited for use with mobile and other battery-powered devices. The lower PAPR achieved by a system like SC-FDMA makes devices that employ it much less powerhungry and therefore more suitable for mobile operation. For SC-FDMA a form of subchannel is used for resource allocation. Each subchannel occupies 180 KHz of spectrum containing 12 subcarriers. Resource allocation can be flexible, with all subcarriers in a channel being assigned to one user or separate groups of subcarriers being assigned to multiple users.
Further Reading: 3GPP TS 36.211, 36.300 2.12
© Wray Castle Limited
LT3600/v1.1
OFDMA Principles
10 10
OFDMA
011011011010
01
S/P
11 10 01
OFDMA Symbol
011011011010
SC-FDMA
011011011010
FFT
SC-FDMA Symbol
SC-FDMA and OFDMA The most immediately apparent difference between the operation of the E-UTRA downlink and uplink technologies is that OFDM transmits data in parallel across multiple subcarriers, whereas SC-FDMA transmits data in series, but still employs multiple subcarriers. Using the basic E-UTRA numerology of 12 subcarriers occupying 180 kHz of bandwidth, during one symbol period on the downlink OFDM will transmit 12 modulation symbols, one on each subcarrier. On a corresponding uplink channel, SC-FDMA will transmit 12 modulation symbols in series during the same time period – each SC-FDMA modulation symbol in this example therefore has a duration 1/12th that of an OFDM modulation symbol. In the case of an OFDM channel employing 16QAM (16-state Quadrature Amplitude Modulation), if all subcarriers happened to modulate a high-amplitude symbol at the same time, the aggregate transmitted power of the channel would be high. If during the next symbol period all subcarriers modulated a low-amplitude symbol the aggregate transmitted power of the channel would drop – the corresponding ratio between the peak power transmitted and its long term average could therefore be high. This is an extreme example and is unlikely to occur often, if at all, when real data is being applied to parallel OFDM subcarriers, but the potential for a large difference between peak and average radiated power remains. SC-FDMA avoids such large differences by employing an additional processing stage in front of the IFFT process. This additional stage deals with the group of modulation symbols to be transmitted during one SC-FDMA symbol period in a series. An FFT process represents the changes made to the modulated signal during the symbol period as outputs on a set of subcarriers – each modulation symbol results in a set pattern of outputs across the 12 subcarriers that make up an individual uplink LTE channel. The subcarriers created by this process have a set amplitude, which should remain more or less constant between one SC-FDMA symbol and the next for a given modulation scheme, resulting in little difference between the peak power radiated on that channel and its long-term average. Further Reading: 3GPP TS 36.211, 36.300 LT3600/v1.1
© Wray Castle Limited
2.13
LTE/SAE Engineering Overview
Frequency component analysis of modulation symbols
Lower PAPR than OFDM
a
Modulation mapping, e.g. QPSK symbols 011101010100
F F T
I F F T
b c
Transmitter
d
a
b c
d
f
a
001010110110
I F F T
Mod
b c
Receiver
F F T
Mod
d
SC-FDMA Operation The typical layout of a SC-FDMA transmitter and receiver is shown in the diagram. Despite its name, the transmitted radio signal for SC-FDMA is an orthogonal multicarrier transmission similar to OFDM. The term ‘single carrier’ refers to the pre-processing of the baseband data prior to its application to the IFFT. The data stream is presented in a serial fashion to the radio transmission process. The first stage is modulation symbol mapping, which produces blocks of complex-valued symbols. Modulation mapping may operate on pairs of baseband bits, as shown in the diagram, for QPSK (Quadrature Phase Shift Keying) but if 16QAM or 64QAM are in use then each modulation symbol will represent either four or six serial baseband bits respectively. The series of modulation symbols is then presented to the FFT, which produces an output representing the frequency components of the modulation symbols. It is then these frequency components that are mapped to the allocated inputs of the IFFT. Note that the FFT output size is always smaller than the IFFT input size. This is because a typical cell’s uplink capacity will generally be greater than 180 kHz, meaning that more than one uplink channel will be available. Individual UEs will be assigned one or more 180 kHz uplink blocks to use, which represents only a portion of the total uplink capacity in the cell. Other UEs will be assigned other groups of subcarriers to use across the uplink channel bandwidth. No two UEs will be assigned the same 180 kHz block to use simultaneously, unless Multi-User MIMO is in use. The output of the IFFT and modulator will be a multi-carrier transmission. However, unlike OFDM there is not a direct mapping of each baseband symbol onto individual transmitted subcarriers. Instead, the frequency components of each baseband symbol are now represented across all the transmitted subcarriers, hence the term ‘single carrier’. The result is a transmitted signal with an improved PAPR compared to an equivalent OFDM transmission.
Further Reading: 3GPP TS 36.211, 36.300 2.14
© Wray Castle Limited
LT3600/v1.1
OFDMA Principles
UE 1
UE 2
UE 3
F F T
I F F T
F F T
I F F T
F F T
I F F T
Mod
UE 1
Mod
Mod
Mod
F F T
I F F T
UE 2 UE 3
Combined signal occupying entire uplink channel bandwidth
SC-FDMA Multiple Access Again, in the example above, the channel is being shared by three UEs, each of which has been assigned a different set of subcarriers. From the receiver’s point of view, it receives one signal that occupies the whole channel but which is in reality the sum of three separate orthogonal signals generated by the three UEs. An overall receive FFT process, operating across the entire channel, recovers the separate subcarrier data streams and individual IFFT processes can then recover the original serial data streams transmitted by each UE.
Further Reading: 3GPP TS 36.211, 36.300 LT3600/v1.1
© Wray Castle Limited
2.15
LTE/SAE Engineering Overview
2.16
© Wray Castle Limited
LT3600/v1.1
LTE/SAE Engineering Overview
Section 3
The LTE Radio Interface
© Wray Castle Limited
LTE/SAE Engineering Overview
ii
© Wray Castle Limited
LT3600/v1.1
The LTE Radio Interface
Contents
Physical Layer Functions ........................................................................................................................ 3.1 Channels Bandwidths ............................................................................................................................. 3.2 Physical Layer Parameters for LTE ........................................................................................................ 3.3 Timing Units ............................................................................................................................................ 3.4 LTE Frequency Bands ............................................................................................................................ 3.5 The Physical Layer Frame Structure ...................................................................................................... 3.6 Resource Descriptions ............................................................................................................................ 3.7 Error Protection and Modulation Schemes ............................................................................................. 3.8 Downlink Reference Signals ................................................................................................................... 3.9 Uplink Reference Signals......................................................................................................................3.10 Air Interface Synchronization ................................................................................................................3.11 Timing and Power Control.....................................................................................................................3.12 LTE Radio Measurement Types ...........................................................................................................3.13 Downlink Physical Channels .................................................................................................................3.14 Downlink Transmission Structure .........................................................................................................3.15 Uplink Physical Channels......................................................................................................................3.16 Uplink Transmission Structure ..............................................................................................................3.17 Advanced Antenna Options ..................................................................................................................3.18
LT3600/v1.1
© Wray Castle Limited
iii
LTE/SAE Engineering Overview
iv
© Wray Castle Limited
LT3600/v1.1
The LTE Radio Interface
Objectives
At the end of this section you will be able to:
outline the general structure of the E-UTRA physical layer
define the term ‘bandwidth agnostic’ in the context of E-UTRA
define the term ‘basic timing unit’ and its relevance in E-UTRA
outline parameters of the versions of OFDMA and SC-FDMA employed by EUTRA
describe the configuration of downlink and uplink frames and list the range of frame types employed, with particular reference to Frame Type 1
describe the resource allocation models employed by E-UTRA including the role of the resource block, resource grid and resource element
list the modulation and error coding options made available in E-UTRA
outline the function of the reference signal and the purpose of UE sounding
describe the arrangements made for managing synchronization, timing and power control functions
list the type of physical layer measurements taken by an E-UTRA-enabled UE
outline the functions of the E-UTRA physical channels on both uplink and downlink
outline the basic configuration of typical Type 1 downlink and uplink frames and the positioning of relevant data types such as control channel, reference signals and synchronization
describe the uplink and downlink MIMO options available to E-UTRA
LT3600/v1.1
© Wray Castle Limited
v
LTE/SAE Engineering Overview
vi
© Wray Castle Limited
LT3600/v1.1
The LTE Radio Interface
Physical channels Error coding Reference signals Random access OFDM and SC-FDMA Modulation and up conversion Synchronization and timing Power control Reporting and feedback UE sounding and HARQ Measurements Handover Bandwidth agnostic TDD and FDD SFN supported for MBMS
Physical Layer Functions To support asymmetric services and to promote longer battery life for mobile terminals, the E-UTRA physical layer employs different technologies on the uplink and downlink: OFDMA and SC-FDMA respectively. The functions of the E-UTRA physical layer can be summarized as follows: creation and management of the uplink and downlink physical channels modulation – BPSK (Binary Phase Shift Keying), QPSK, QAM – and error coding creation of reference signals in both uplink and downlink management of the RACH (Random Access Channel) OFDMA signal generation in the downlink and SC-FDMA signal generation in the uplink modulation and up conversion synchronization procedures, including cell search procedure and timing synchronization power control procedures management of CQI (Channel Quality Indication) reporting and MIMO feedback physical uplink shared channel-related procedures, including UE sounding and HARQ (Hybrid ARQ) ACK/NACK detection reporting of measurement results to higher layers and the network handover measurements, idle-mode measurements, etc.
E-UTRA supports services in a variety of channel bandwidths. In fact, the specification explicitly labels E-UTRA as ‘bandwidth agnostic’, meaning that it has no rigidly defined or preferred channel bandwidth and can be scaled to channels of almost any size. Both FDD (Frequency Division Duplex) and TDD (Time Division Duplex) modes are supported, as is a ‘half duplex’ mode, which is midway between the two. E-UTRA has also been designed to work as the bearer for MBMS (Multicast and Broadcast Multimedia Services) and therefore includes support for SFN (Single Frequency Network) operation. Support for advanced antenna configurations has also been designed into the specification with MIMO and beam-forming adaptive antennas both being referenced. Further Reading: 3GPP TS 36.211 LT3600/v1.1
© Wray Castle Limited
3.1
LTE/SAE Engineering Overview
20 MHz/1200 15 MHz/900 10 MHz/600 5 MHz/300 3 MHz/180 1.4 MHz/72
Channel bandwidths (bandwidth/data subcarriers)
Channels Bandwidths E-UTRA OFDMA was designed to work in a variety of downlink bandwidths ranging initially from 1.4 MHz to 20 MHz. As E-UTRA is described as being ‘bandwidth agnostic’, other bandwidths, ones that allow E-UTRA to be backwards compatible with channel allocations from legacy network types, for example, could be incorporated in the future. The version of OFDMA employed by E-UTRA is similar to the versions employed by WiMAX or DVB, but with a few key differences. In systems such as WiMAX, OFDMA schemes occupying different channel bandwidths employ different subcarrier spacings, meaning that there is a different set of physical layer parameters for each version of the system. The E-UTRA scheme allows for two fixed subcarrier spacing options – 15 kHz in most cases, with an optional 7.5 kHz spacing scheme for TDD in very narrow bandwidth channels. Fixing the subcarrier spacing reduces the complexity of a system that can support multiple channel bandwidths. On the downlink there is an additional set of parameters relevant to operation in narrow channels with 7.5 kHz bandwidth.
Further Reading: 3GPP TS 36.211 3.2
© Wray Castle Limited
LT3600/v1.1
The LTE Radio Interface
1.4 MHz
3 MHz
5 MHz
Subframe Duration (ms)
1
Subcarrier Spacing (kHz)
15
10 MHz
15 MHz
20 MHz
Sampling Rate (MHz)
1.92
3.84
7.68
15.36
23.04
30.72
Data Subcarriers
72
180
300
600
900
1200
Symbols/slot CP Length
Normal CP = 7, extended CP = 6 Normal CP = 4.69/5.12 µsec, extended CP = 16.67 µsec
Physical Layer Parameters for LTE One parameter that does change between different bandwidths is the sampling rate. Based on the UMTS WCDMA chip rate of 3.84 Mcps, E-UTRA employs sample rates that range from 1.92 MHz in a 1.4 MHz wide channel to 30.72 MHz in a 20 MHz wide channel. The decision to use factors or multiples of 3.84 was taken to ensure backwards compatibility with WCDMA devices through the use of common clocking. The allocation of subcarriers between data and null functions varies with channel bandwidth, with a 20 MHz channel supporting 1200 data subcarriers and a 1.4 MHz channel supporting just 72. Other OFDMA systems employ sets of dedicated pilot subcarriers, whereas E-UTRA embeds ‘reference signals’ into the data stream across selected subcarriers. This reduces the amount of ‘pilot’ overhead, but possibly at the expense of reduced accuracy. E-UTRA employs a fixed frame duration period of 10 ms, which is itself created from a set of slots and subframes. A subframe encapsulates two slots and a slot consists of a varying number of symbol periods, depending upon which frame type and CP (Cyclic Prefix) scheme is in use. There are two frame types. Type 1 is designed for FDD full- and half-duplex implementations, while Type 2 is reserved for TDD operation. Type 2 frames are only ever used with systems that need to be backwards-compatible with the Chinese 3GPP TD-SCDMA (Time Division-Synchronous CDMA) standard. There are two CP options, normal and extended. The normal CP is designed to be used either in small cells or in those with a short multipath delay spread; the extended CP is designed for use in large cells or those with complex and long lasting delay spread profiles.
Further Reading: 3GPP TS 36.211 LT3600/v1.1
© Wray Castle Limited
3.3
LTE/SAE Engineering Overview
Timing Unit (Ts) =
1 second subcarrier spacing x max FFT size
1
=
15,000 x 2048
=
32.5 nsec
Timing Units Almost all numbers, durations and calculations related to E-UTRA are derived from a fundamental parameter known as Ts – or the Basic Time Unit. Ts represents the ‘sampling time’ of the overall channel and is itself derived from basic channel parameters. The underlying calculations for E-UTRA are based on a service that operates in a 20 MHz channel, with 2048 subcarriers set at 15 kHz spacing. E-UTRA deployments at all other bandwidths are based on these parameters. Ts is calculated to be the reciprocal of the subcarrier spacing multiplied by the total number of subcarriers in the FFT, or: Ts = 1/15,000 x 2048 seconds = 0.0325 μsec Frame, subframe and slot lengths, cyclic prefix durations and many other key parameters are calculated as multiples of Ts. Crucially, the value of Ts does not vary even when E-UTRA operates in channel bandwidths that are smaller then 20 MHz. As Ts stays constant, all of the key parameters used to define E-UTRA services also stay constant. The consistency reduces the overall complexity of E-UTRA and enables system manufacturers to scale their devices more easily to a variety of channel bandwidths and frequency bands.
Further Reading: 3GPP TS 36.211 3.4
© Wray Castle Limited
LT3600/v1.1
The LTE Radio Interface
FDD
TDD
Band
Popular name
Frequencies (MHz)
1
IMT Core
1920–1980/2110–2170
2
PCS 1900
1850–1910/1930–1990
3
GSM 1800
1710–1785/1805–1880
4
AWS (US)
1710–1755/2110–2155
5
850 (US)
824–849/869–894
6
850 (Japan)
830–840/875–885
7
IMT Extension
2500–2570/2620–2690
8
GSM 900
880–915/925–960
9
1700 (Japan)
1750–1785/1845–1880
10
3G Americas
1710–1770/2110–2170
Band
Popular name
Frequencies (MHz)
33
TDD 1900
1900–1920
34
TDD 2.0
2010–2025
37
PCS Centre Gap
(1915)1910–1930
38
IMT Extension Centre Gap
2570–2620
LTE Frequency Bands Preparation for the deployment of EPS systems has begun in many countries, with operators, vendors and regulators starting to discuss the spectrum requirements for these systems. The standards currently identify 13 bands for FDD operation, ranging from frequencies in the range 800 MHz through to frequencies in the range 2.5 GHz. There also eight bands identified for TDD operation ranging from 1900 MHz to 2.5 GHz. Considerable scope has been left in the standards to add more frequency bands as global requirements evolve.
Further Reading: 3GPP TS 36.211, 36.104 LT3600/v1.1
© Wray Castle Limited
3.5
LTE/SAE Engineering Overview
10 ms Frame
0
1
2
3
4
5
6
7
8
9 10 11 12 13 14 15 16 17 18 19 0.5 ms Slot
1 ms Subframe (2 slots)
0 1 2 3 4 5 6 0 1 2 3 4 5 6
Cyclic Prefix
Modulation Symbol
Normal CP 7 symbols/slot
1 ms Subframe (2 slots)
0 1 2 3 4 5 0 1 2 3 4 5
Cyclic Prefix
Modulation Symbol
Extended CP 6 symbols/slot
The Physical Layer Frame Structure There are two basic frame types employed in E-UTRA, which are common to both uplink and downlink. Type 1 frames are employed for FDD full- and half-duplex systems, while Type 2 frames are reserved for TDD operation only. Type 1 frames last for 10 ms and are composed of 20 slots of 0.5 ms each. Two slots are combined to form a subframe, which lasts for 1 ms. For FDD, 10 subframes are available for downlink transmissions and 10 for uplink transmissions in each 10 ms interval. Uplink and downlink transmissions are separated in the frequency domain. Type 1 slots contain either 7 or 6 symbols, depending upon which CP type is used. The length of the CP prefixed to each symbol may vary depending upon where that symbol sits within the slot. With the normal CP, symbol 0 in each slot has a CP equal to 160 x Ts or 5.21 μsec, while the remaining symbols in the slot have slightly shorter CPs of just 144 x Ts or 4.7 μsec. When using the extended CP, all symbols are prefixed with a CP of 512 x Ts or 16.67 μsec. Scheduling occurs across a subframe period. Up to the first three symbols in the first slot of each subframe can be defined as a ‘control region’ carrying control and scheduling messages. The remaining symbols of the first and all symbols in the second slot within the subframe are then available for user traffic. Type 2 frames are used by TDD systems, which are required to be backwards-compatible with the Chinese TD-SCDMA IMT-2000 standard; they last for 10 ms and consist of two 5 ms half-frames. Each half-frame carries six subframes and three specialized fields. Subframe 0 and the DwPTS (Downlink Pilot Time Slot) field are reserved for downlink services and subframe 1 and the UpPTS (Uplink PTS) field are reserved for uplink – the other fields can be assigned dynamically between uplink and downlink.
Further Reading: 3GPP TS 36.211 3.6
© Wray Castle Limited
LT3600/v1.1
The LTE Radio Interface Resource Grid 1 ms Subframe (2 slots) Subcarrier 1
0 1 2 3 4 5 66 0 1 2 3 4 5 6 0 1 2 3 4 5 66 0 1 2 3 4 5 6 0 1 2 3 4 5 66 0 1 2 3 4 5 6 0 1 2 3 4 5 66 0 1 2 3 4 5 6 0 1 2 3 4 5 66 0 1 2 3 4 5 6 0 1 2 3 4 5 66 0 1 2 3 4 5 6
180 kHz
0 1 2 3 4 5 66 0 1 2 3 4 5 6 0 1 2 3 4 5 66 0 1 2 3 4 5 6 0 1 2 3 4 5 66 0 1 2 3 4 5 6 0 1 2 3 4 5 66 0 1 2 3 4 5 6 0 1 2 3 4 5 66 0 1 2 3 4 5 6
Subcarrier 12
0 1 2 3 4 5 66 0 1 2 3 4 5 6
Resource Element
Resource Block
Equal to one modulation symbol
Resource Descriptions Capacity allocation in E-UTRA is based on a concept known as the RB (Resource Block). A PRB (Physical Resource Block) consists of 12 subcarriers (in the frequency domain) for one slot period (in the time domain). On both uplink and downlink channels, 12 subcarriers correspond to 180 kHz of bandwidth. The minimum possible capacity allocation period is the TTI (Transmission Time Interval) of 1 ms. This equates to the allocation of two consecutive resource blocks. For capacity allocation purposes, the resources available during a frame period are organized into resource grids, which consist of a number of consecutive resource blocks. The theoretical minimum definable capacity allocation unit is the resource element, which is defined as one subcarrier during one symbol period. Within each resource grid the resource elements that will be carrying reference signals are assigned first; the remaining elements are then available to have user data or control messages mapped to them. In data transfer terms, one resource element is the equivalent of one modulation symbol on a subcarrier, so if QPSK modulation was being employed, one resource element would be equal to 2 bits, with 16QAM 4 bits and with 64QAM 6 bits of transferred data. If MIMO is employed on the downlink then separate resource grids are created for each antenna port – each port maps to a different MIMO stream.
Further Reading: 3GPP TS 36.211, 36.300 LT3600/v1.1
© Wray Castle Limited
3.7
LTE/SAE Engineering Overview
Modulation Schemes
BPSK
Signalling functions only
QPSK 16QAM Optional on uplink
64QAM
Error Coding Schemes
1/3 Turbo Coding 1/3 CC
CRC
Traffic and most control channels BCH only
Transport Block
24 bit CRC
Error Protection and Modulation Schemes The range of modulation schemes used in E-UTRA comprises BPSK, QPSK, 16QAM and 64QAM. BPSK is only employed for a limited set of signalling and reference functions, while 64QAM is optional on the uplink. The range of error coding options used in E-UTRA devices is far more limited than those available to, for example, an HSPA device. For shared and multiplex traffic channels, the only error coding option mentioned in the current version of the applicable 3GPP specification (TR 36.212) is 1/3 Turbo coding. Broadcast traffic channels are only permitted to use 1/3 Tail Biting convolutional coding. Various control channels have been assigned either convolutional coding, block coding or simple repetition as their error coding options. In addition to error coding, transport blocks containing user and control traffic may also optionally have a CRC (Cyclic Redundancy Check) block attached. Transport blocks on connections that have CRC selected have a 24-bit CRC block appended to the end of the data container. The familiar UMTS error monitoring levels of BER (Bit Error Rate), derived from the error coding service, and BLER (Block Error Rate), derived from CRC, continue to be available in E-UTRA.
Further Reading: 3GPP TS 36.211, 36.300 3.8
© Wray Castle Limited
LT3600/v1.1
The LTE Radio Interface
1 ms Subframe (2 slots) Subcarrier 1
0 1 2 3 4 5 6 0 1 2 3 4 5 6 R
R
R
R
180 kHz
R
Subcarrier 12
R
R
R
Reference Signal
Downlink Reference Signals In any mobile radio system it is necessary to provide mobile devices with a means of measuring and monitoring the strength and quality of the signal they receive and of calibrating their own output to ensure that the correct frequencies are being employed. In an OFDM-based system, where different UEs are assigned the use of different sets of closely packed subcarriers, the need for reliable frequency calibration is critical. E-UTRA’s version of OFDMA/SC-FDMA employs a physical reference signal, embedded in the main body of the transmitted signal to provide an opportunity for channel estimation and frequency calibration on the downlink. A process of UE sounding performs a similar function on the uplink. Reference signal symbols are placed in predetermined locations within each resource grid. An example of this for both uplink and downlink is shown in the diagram. On the downlink, three types of downlink reference signals are currently defined: cell-specific reference signals, MBSFN (Multicast/Broadcast Single Frequency Network) reference signals, associated with MBSFN transmission, and UE-specific reference signals. In most circumstances only the first of these reference signal types will be used. The reference signal takes the form of a modulated symbol chosen from a pseudo-random sequence of symbols, which is inserted into the transmitted signal following a predetermined sequence. Cell-specific reference signals, as well as providing a ‘known signal’ upon which to base channel estimations, are modulated to identify the cell to which they belong. When MIMO is employed, separate reference signals are transmitted by each air interface port. In Type 1 frames the downlink reference signal is transmitted during symbol periods 0 and 4, although the subcarrier on which it is transmitted varies following a predetermined pattern.
Further Reading: 3GPP TS 36.211, 36.300 LT3600/v1.1
© Wray Castle Limited
3.9
LTE/SAE Engineering Overview
1 ms Subframe (2 slots) Subcarrier 1
0
1
2
Subcarrier 1
Subcarrier 12
D
4
5
6
0
1
2
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
4
5
6
Demodulation Reference Signal
Uplink Reference Signals
Uplink Reference Signals A ‘demodulation’ reference signal is embedded in uplink user traffic and control transmissions. The demodulation signal provides the receiving eNB with a ‘known signal’ element upon which to perform channel estimations and from which it can calculate timing adjustments. In Type 1 frames, the uplink demodulation reference signal is always sent in symbol 3 of each slot. Channel estimations for received uplink signals are made by the eNB based on measurements taken of the reference signal symbols embedded in uplink transmissions. If there is no uplink transmission taking place, however, the eNB cannot take measurements. In these circumstances a UE may be instructed to perform uplink sounding, which consists of the UE transmitting a reference signal within an uplink resource allocation specifically set aside for the purpose. UEs may also be instructed to undertake sounding to enable the eNB to perform ‘frequency-specific scheduling’. This term describes a procedure whereby the eNB measures the sounding signal transmitted by a UE across some or all subcarriers and then chooses the resource block that consists of the best performing set of frequencies.
Further Reading: 3GPP TS 36.211, 36.300 3.10
© Wray Castle Limited
LT3600/v1.1
The LTE Radio Interface
Cell-specific Reference Signal – Physical Layer Group (1 of 168)
PSS – Cell ID within Physical Layer Group (1 of 3)
SSS – other synchronization parameters
Air Interface Synchronization
Air Interface Synchronization E-UTRA employs two synchronization channels, Primary and Secondary, which, although based on different technologies, perform much the same functions as the PSS (Primary Synchronization Signal) and SSS (Secondary Synchronization Signal) in R99 UMTS. To facilitate fast cell search, E-UTRA cells are assigned one of 504 physical layer cell identities. The 504 available identities are grouped into 168 groups, each of which contains three cell identities. The physical layer cell identity group to which a cell belongs is explicitly flagged by the modulation of the cell-specific reference signal it transmits. The PSS provides coarse frequency synchronization, on a whole channel basis, and also allows a UE to discover symbol, slot and subframe synchronization. The physical cell ID index of the ID assigned to the transmitting cell is carried by the P-SCH. There are three cell IDs per physical cell ID group, index numbers 0,1 and 2. The SSS is modulated to allow a UE to discover the boundary of each 10 ms frame, and provides details of the physical cell ID group to which the cell belongs. This information can also be gained from the cell-specific reference signal transmitted in the cell. On a wider scale, the synchronization of the eNB within the E-UTRAN is an area of future study in the current versions of the specifications. The only directive given so far is that eNBs should be permitted to obtain synchronization via a wide range of sources. This means that an eNB will be free to obtain a synchronization signal from either wired (via cable or fibre link) or wireless via GPS (Global Positioning System) or some other radio link.
Further Reading: 3GPP TS 36.211, 36.300 LT3600/v1.1
© Wray Castle Limited
3.11
LTE/SAE Engineering Overview
PRACH, uplink traffic or UE sounding
Timing Advance – steps of 0.52 μsec (16 x Ts)
Power Adjustment – EPRE in steps of 1 dB
Timing and Power Control The E-UTRA uplink employs a slotted frame structure which is shared by multiple simultaneous users. To ensure that transmission from each active UE arrives within its allotted slot period, however near to or far from the cell site each UE is, the eNB is required to measure and adjust each UE’s uplink timing offset. A timing advance system, similar in principle to that employed by GSM, is used to manage this aspect of UE transmission. Received transmissions from each UE are measured by the eNB and any deviation from the required arrival time is noted. A TA (Timing Advance) message is returned to each UE specifying the amount of change, positive or negative, that is required. Timing advance adjustments are made in multiples of 0.52 μsec. Uplink power output for each UE is defined in terms of the EPRE (Energy Per Resource Element) that is radiated. EPRE is an average measurement of the energy in one subcarrier during one symbol period and excludes the cyclic prefix. The EPRE figure for one UE will be the same across all radiated subcarriers during a power control cycle. Like WCDMA in R99 UMTS, E-UTRA employs both open and closed loop power control. Open loop power control is used for random access events, when the UE is not receiving power control messages from the eNB. Closed loop power control occurs once a connection has been established and the eNB has begun sending TPC (Transmit Power Control) messages to the UE.
Further Reading: 3GPP TS 36.211, 36.300 3.12
© Wray Castle Limited
LT3600/v1.1
The LTE Radio Interface
RSRP – Reference Signal Received Power RSSI – Received Signal Strength Indicator RSRQ – Reference Signal Received Quality
LTE Radio Measurement Types The basic air interface measurements applicable to E-UTRA are RSRP (Reference Signal Received Power), RSSI (Received Signal Strength Indicator) and RSRQ (Reference Signal Received Quality). The RSRP measurement provides an average of power levels received across all reference signal symbols within a given time period and across a nominated bandwidth. On the uplink this means that the eNB only needs to take into account the reference signals received from the channel assigned to a particular UE when taking measurements in relation to that UE. On the downlink a UE only needs to take measurements from the cell-specific reference signal elements related to the cell it is currently being served by. If MIMO or some other form of receiver diversity is in use by the UE, the measurements taken will be an average of the RS power received on all active diversity branches. Received signal strength, as the name suggests, is a measurement of everything received on a given channel regardless of source – so wanted channel noise, co- and adjacent-channel interference and even thermal noise all contribute to the overall RSSI measurement. Current versions of the relevant 3GPP specification (TR 36.214) do not state when RSSI measurements should be taken during the E-UTRA frame cycle. RSRQ is derived from the previous two measurements. The measured RSRP is divided by the current RSSI value and the result is multiplied by the number of resource blocks contained within the bandwidth measured to obtain the RSSI figure. Quality and signal strength feedback are required to allow link adaptation to take place. The eNB schedules regular opportunities for each active UE to send CQI and other measurements. If the UE has data to transmit when a feedback opportunity is scheduled it is piggybacked onto the PUSCH (Physical Uplink Shared Channel) transmission. If not, the UE instead sends the feedback using the defined PUCCH (Physical Uplink Control Channel) resource elements.
Further Reading: 3GPP TS 36.211, 36.300, 36.801 LT3600/v1.1
© Wray Castle Limited
3.13
LTE/SAE Engineering Overview
Logical
BCCH
PCCH
CCCH
DCCH DTCH
MCCH
MTCH
Transport BCH
PCH
DL-SCH
MCH
Physical PBCH
PDCCH PCFICH PHICH
PDSCH
PMCH
Physical Signals
Downlink Physical Channels The PDSCH (Physical Downlink Shared Channel) is the only channel available for carrying data to individual terminals – E-UTRA has no equivalent of the dedicated channels employed by other GSM and UMTS variants. The PDSCH carries a multiplexed data stream for some or all active users in a cell or on a MIMO stream in a cell. The PMCH (Physical Multicast Channel) is designed to carry multicast traffic, such as MBMS services and other traffic flows destined for multiple users. Traffic carried by the PDSCH and PMCH is ultimately mapped into the available space in downlink resource grids. The PDCCH (Physical Downlink Control Channel) occupies up to the first three symbol periods in every subframe. The main function of the PDCCH is to carry resource assignment messages for downlink capacity allocations and scheduling grants for uplink allocations. A PDCCH notification specifies which connections have been allocated capacity, which RBs have been assigned and the number of symbols for which the allocation lasts. Due to the limited complexity of the allocation method, capacity allocations always consist of sets of contiguous RBs and symbols, leading to a two-dimensional assignment within a resource grid. The notification will also specify the format of the allocation – the modulation and error coding scheme employed plus any MIMO or advanced antenna parameters applicable to the transmission. The PCFICH (Physical Control Format Indicator Channel) carries details of the formatting of a subframe’s control fields and the PHICH (Physical HARQ Indicator Channel) carries ARQ (Automatic Repeat Request) ACK/NACK messages from the eNB back to the UEs. The PDCCH, PCFICH and PHICH all share capacity in the first three symbol periods of each subframe. The PBCH (Physical Broadcast Channel) carries the Master Information Block, which directs UEs to the system information carried in the PDSCH. In addition to the physical channels specified above, the E-UTRA downlink also carries several ‘physical signals’. These are the reference and synchronization signals.
Further Reading: 3GPP TS 36.211, 36.321, 36.300 3.14
© Wray Castle Limited
LT3600/v1.1
The LTE Radio Interface Subframe 0
Resource Block 0 –
Resource Block 0 – MIMO Port 2
MIMO Port 1
Control Symbols
0 1 2 3 4 5 6 0 1 2 3 4 5 6
0 1 2 3 4 5 6 0 1 2 3 4 5 6
X
R
X
R
R
X
R
X
R
X
R
X
X
R
X
R
X
R
X
R
R
X
R
X
R
X
R
X
X
R
X
R
10 ms Frame Resource Block 0
DC Carrier
Resource Block 99 Resource Blocks carrying PBCH, PSS and SSS
Resource Blocks carrying only PSS and SSS
Downlink Transmission Structure
Downlink Transmission Structure An example of a populated downlink subframe (using frame Type 1 and the normal CP) is shown in the diagram. To allow for flexible, low latency scheduling and also to allow the capacity scheduler to focus its functions on groups of users with similar requirements, multiple PDCCHs can operate in parallel during the same subframe periods. Each separate PDCCH manages a different CCE (Control Channel Element), which has responsibility for allocating the capacity of a subset of resource elements to a subset of active users. Segmentation of the PDCCH into smaller CCEs also allows UEs to decode and process only the channel control information that relates to their own CCE, rather than expending processing time and power decoding all PDCCH messages. The PBCH logical channel is transmitted during subframe 0 of each 10 ms frame and is spread over slots 0 (symbols 3 and 4) and 1 (symbols 0 and 1). The subcarriers chosen to carry the PBCH consist of those in the six RBs clustered either side of the DC carrier (the centre frequency of the radio channel), which provides a total of 72 subcarriers. Slots assigned to reference signals are excluded from this, however, meaning that in slot 0 symbol 4 and slot 1 symbol 0 a reduced number of subcarriers are assigned to carry the PBCH. PSS and SSS synchronization signals are transmitted twice in each 10 ms frame period, in subframe 0 and subframe 5. They again occupy the six resource blocks either side of the DC carrier during symbols 5 and 6. Also included in the diagram is an example of the configuration of a downlink channel employing 2x2 MIMO. Separate subframe maps are created for each antenna port, which themselves then map onto different MIMO streams. To reduce the potential for inter-stream interference, resource elements in one stream that correspond to resource elements carrying reference signals in the other stream are left unassigned.
Further Reading: 3GPP TS 36.211, 36.300 LT3600/v1.1
© Wray Castle Limited
3.15
LTE/SAE Engineering Overview
CCCH
DCCH
DTCH
Logical
RLC
RACH
UL-SCH
Transport
MAC
Physical
Physical PRACH
PUCCH
PUSCH
Uplink Physical Channels The PUSCH (Physical Uplink Shared Channel) is the shared uplink data channel. Again, as with the downlink, the E-UTRA uplink does not support the concept of a dedicated channel. Traffic bursts from multiple UEs are scheduled by the eNB and are interleaved to share the same uplink resources. The PUCCH (Physical Uplink Control Channel) provides an uplink control path for each UE to send HARQ (Hybrid Automatic Repeat Request) ACK/NACK indications, uplink scheduling requests, CQIs and MIMO feedback. If control traffic is sent at the same time as uplink data is being transmitted, the UE time-multiplexes the two streams of data together to preserve the ‘single carrier’ nature of the SC-FDMA service. If control data is to be sent when there is no uplink capacity grant scheduled, the UE will transmit the message using a set of specially set aside resource elements at the extreme edges of the overall channel. The size of this reserved region is configurable depending on the expected amount of PUCCH traffic and its location, at the top and bottom ends of the radio band. It allows UEs to transmit on these subcarriers at slightly higher power levels than would be desirable on subcarriers with a trafficbearing channel either side of them. The PRACH (Physical Random Access Channel) carries random access attempts from the UEs to the eNB. The location of the resource elements set aside for PRACH use are flagged in the PDCCH. The location of the resource elements set aside for PRACH use is based on a fixed mapping determined by the PRACH configuration option in force in a cell, which itself is flagged on the BCCH (Broadcast Control Channel). The Type 1 frame structure allows a maximum of 64 orthogonal preambles per cell and the list of allowed preambles is carried on the PBCH, as is the required length of the preamble to be transmitted in that cell. The guard gap after the preamble is designed to prevent PRACH signals transmitted by a distant UE overlapping into a subsequent PRACH period.
Further Reading: 3GPP TS 36.211, 36.321, 36.300 3.16
© Wray Castle Limited
LT3600/v1.1
The LTE Radio Interface Resource Block 1 0 1 2 D 3 4 5 6 0 1 2 D 3 4 5 6
D D D D D D D D D D D
D D D D D D D D D D D
10 ms Frame Resource Block 0
Resource Block 99 Reserved PUCCH resource elements
Uplink Transmission Structure An example of a populated uplink subframe (using frame Type 1 and the normal CP) is shown in the diagram. The uplink frame structure is much simpler than that employed by the downlink. Symbol 3 in each slot carries the uplink demodulation reference signal, leaving the other six symbols available to carry traffic. A configurable number of outer subcarriers, as shown in the diagram, can be set aside to carry contention-based PUCCH messages. The nature of SC-FDMA means that UEs are assigned capacity in terms of a number of RBs, but only transmit across a subset of subcarriers within each RB.
Further Reading: 3GPP TS 36.211, 36.300 LT3600/v1.1
© Wray Castle Limited
3.17
LTE/SAE Engineering Overview
Stream 1
Stream 2
DL MIMO
UL MU- MIMO
User 1 on RB
User 2 on RB
Advanced Antenna Options The higher-order data rates potentially achievable through the E-UTRA – rates above 50 Mbit/s on the downlink – are only possible if advanced antenna techniques are employed. MIMO transmission uses a diverse set of transmit and, optionally, receive antennas to create multiple signal ‘streams’ over the same physical radio channel. The physical separation of the transmit antennas – either spatially or in terms of polarization – allows a receiving station to perceive the separate streams as multipaths, which can then be recovered using a rake receiver. The higher data rates available through E-UTRA systems only become possible with 2x2 MIMO – two transmit and two receive antennas. This system requires that each eNB transmits using two antennas per sector and each UE is equipped with spatially or polarity separated antennas. The very high downlink data rates, 300 Mbit/s and above, that are mathematically possible with E-UTRA, are only possible using more extreme versions of MIMO – up to 4x4. MU-MIMO (Multi-User MIMO) allows an eNB to schedule two UEs to use the same RBs simultaneously. As the UEs are assumed to be physically distant from each other, the resulting combined transmissions arrive at the eNB as multipaths and can be processed in the same way as separate MIMO streams. MU-MIMO effectively doubles the capacity of the uplink, but cannot be used in all circumstances.
Further Reading: 3GPP TS 36.211, 36.300 3.18
© Wray Castle Limited
LT3600/v1.1
LTE/SAE Engineering Overview
Section 4
Radio Access Protocols
© Wray Castle Limited
LTE/SAE Engineering Overview
ii
© Wray Castle Limited
LT3600/v1.1
Radio Access Protocols
Contents Radio Access Protocol Stack ...............................................................................................................4.1 SCTP (Stream Control Transmission Protocol) ...................................................................................4.2 PDCP And RRC ...................................................................................................................................4.3 MAC PDU Structure .............................................................................................................................4.4 MAC Random Access Procedure ........................................................................................................4.5 MAC Scheduling Functions..................................................................................................................4.6 Resource Multiplexing..........................................................................................................................4.7 QoS and Priority Handling....................................................................................................................4.8 HARQ Operation ..................................................................................................................................4.9 RLC Modes ........................................................................................................................................4.10 RLC PDU Structure............................................................................................................................4.11 PDCP Operation ................................................................................................................................4.12 Integrity Protection .............................................................................................................................4.13 RRC Functions...................................................................................................................................4.14 RRC States ........................................................................................................................................4.15 Radio Resource Management Functions...........................................................................................4.16 Network Nodes and Areas .................................................................................................................4.17 System Acquisition.............................................................................................................................4.18 Attach Procedures..............................................................................................................................4.19 Idle Mode Procedures ........................................................................................................................4.20 Tracking Areas and Paging................................................................................................................4.21 LTE Handover Types .........................................................................................................................4.22 LT3600/v1.1
© Wray Castle Limited
iii
LTE/SAE Engineering Overview
iv
© Wray Castle Limited
LT3600/v1.1
Radio Access Protocols
Objectives
At the end of this section you will be able to:
list the general set of protocols employed for E-UTRA above the physical layer and list their main functions
outline the general structure of the E-UTRA MAC layer
describe the format of a typical MAC PDU
describe the functions performed by the physical layer and the MAC in support of random access procedures
outline the MAC scheduling concept
outline the methods employed by the MAC to multiplex user traffic
list the basic QoS levels described so far for the E-UTRAN specifications
describe the methods employed by the MAC to manage retransmission and other HARQ functions
outline the basic functions of the RLC layer and describe the layout of the RLC PDU
describe the differences between the RLC connection modes – transparent, unacknowledged and acknowledged
demonstrate an understanding of the role and functions of the PDCP layer
list the functions of the RRC layer and describe the two RRC states
outline the main RRM functions of the E-UTRAN
outline the basic procedures followed in respect of cell search, network attach, idle mode, connection establishment and handover
identify the handover options for radio access through the E-UTRAN
LT3600/v1.1
© Wray Castle Limited
v
LTE/SAE Engineering Overview
vi
© Wray Castle Limited
LT3600/v1.1
Radio Access Protocols
User Equipment
eNB
Evolved Packet Core Non-Access Stratum (NAS)
Non-Access Stratum (NAS) RRC
RRC
PDCP
PDCP
RLC
RLC
MAC
MAC
Physical Layer
Physical Layer
Radio Access Protocol Stack The Long Term Evolution of UMTS has demanded a reduction in the complexity of the relationship between the UE and the RAN. This in turn allows a reduction in the complexity of the access network itself. Formerly, UMTS air interface protocols operating from the UE interacted with spilt destinations; the physical layer operated between the UE and the Node B, while the MAC, RLC, PDCP and RRC were all forwarded to the RNC. In the E-UTRA all air interface protocols operate between the UE and the eNB only. The protocol layers are shown in the diagram. The MAC layer is responsible for random access management, scheduling, priority, handling, multiplexing, HARQ error correction and transport format selection. The RLC layer is responsible for managing different transfer modes, transfer of upper-layer PDUs, error correction through ARQ, concatenation, segmentation and reassembly of RLC SDUs (Service Data Units).
Further Reading: 3GPP TS 36.300 LT3600/v1.1
© Wray Castle Limited
4.1
LTE/SAE Engineering Overview
eNB
EPC Nodes
eNB
SCTP Signalling Associations
eNB
SCTP (Stream Control Transmission Protocol) In UMTS Release 99, Iu interface traffic was carried over ATM (Asynchronous Transfer Mode) with different AAL (ATM Adaptation Layer) types being used to encapsulate and transport control and user plane traffic. The Release 5 specifications provided an upgrade path to ‘IP Transport’, which allowed existing U-plane traffic formats to be encapsulated by IP in place of ATM. The Release 8 EPS specifications describe an all-IP network environment in which the message formats themselves change, using the S1AP and X2AP protocols for control-plane traffic, which are both carried over IP. In order to provide effective transport for signalling messages, the protocol used above IP at layer 4 must provide fast and reliable data transmission. The protocols most often seen at layer 4 in an IP protocol stack, UDP and TCP, cannot provide a good enough service for signalling traffic. UDP provides a fast but connectionless service in which there are no facilities to retransmit errored packets, remove duplicate packets, or ensure sequenced delivery. TCP provides the required reliability but suffers from timing problems caused by, for example, head-of-line blocking whilst a lost or errored packet is retransmitted. SCTP is a general-purpose transport protocol designed by the IETF for message-oriented applications such as signalling. It overcomes the problems identified with TCP and UDP in a conventional IP protocol stack by breaking message flows between two peer devices into a number of separate ‘streams’ – each stream manages its own retransmission process, so that retransmission of an errored packet belonging to one stream does not slow down delivery of packets belonging to other streams. SCTP also introduces network-level fault tolerance with its multihoming feature, which allows one device to be connected to IP links in multiple networks. SCTP was originally designed as a reliable method of carrying SS7 (Signalling System No. 7) signalling messages over an IP network, but it can carry messages for a wide variety of other communications protocols too.
Further Reading: 3GPP TS 23.401; IETF RFC 2690 4.2
© Wray Castle Limited
LT3600/v1.1
Radio Access Protocols
Radio Bearers PDCP
RLC
ROHC
ROHC
ROHC
ROHC
Security
Security
Security
Security
Segm. ... Segm. ARQ etc ARQ etc
Segm. ... Segm. ARQ etc ARQ etc
BCCH PCCH
Logical Channels Scheduling / Priority Handling MAC
Downlink Protocols
Multiplexing UEn
Multiplexing UE1
HARQ
HARQ Transport Channels
Radio Bearers PDCP
RLC
ROHC
ROHC
Security
Security
Segm. Segm. ... ARQ etc ARQ etc
Uplink Protocols Logical Channels
Scheduling/Priority Handling MAC
Multiplexing HARQ Transport Channels
PDCP And RRC PDCP is responsible for: header compression, using RoHC (Robust Header Compression) ciphering of U- and C- plane data integrity protection for C-plane data transfer of U-plane and RRC data The RRC layer is responsible for: creation of BCH (Broadcast Channel) system information creation and management of the PCH (Paging Channel) RRC connection management between eNB and UEs, including generating temporary identifiers such as the C-RNTI (Cell Radio Network Temporary Identifier) mobility-related functions such as measurement reporting, inter-cell handover and inter-eNB UE context handover QoS management direct transfer of messages from the NAS (Non-Access Stratum) to the UE
Further Reading: 3GPP TS 36.300 LT3600/v1.1
© Wray Castle Limited
4.3
LTE/SAE Engineering Overview
2 bits 1 bit
R
E
5 bits
1 bit
7/15 bits
LCID
F
Length indicator
n MAC sub-header
1 MAC sub-header
1
n
1
n
MAC CE
MAC CE
MAC SDU
MAC SDU
Padding
MAC payload
MAC header MAC PDU
MAC PDU Structure E-UTRA upper-layer data is formatted into transport blocks. Transport blocks pass through several stages of formatting before arriving at the MAC layer, where they are placed into MAC PDUs. The basic structure of a MAC PDU consists of a MAC header part and MAC payload part. The payload part contains variable numbers of MAC SDUs carrying data, MAC CEs (Control Elements) and, if required, a padding field. The fields within a MAC PDU vary in size. The PDU itself, however, must be sized to fit into the physical layer resource blocks to which they will be mapped. Downlink frames must be transmitted in their entirety; there cannot be any gaps in transmission, but the resource block structure may not fit exactly with the amount of data being carried in a PDU, hence the need for padding. The MAC header part consists of one or more MAC sub-headers. Each MAC sub-header relates to one of the MAC SDUs, MAC control elements and, under some circumstances, the padding elements in the MAC payload part. The order of MAC sub-headers matches the order of the MAC payload elements to which they relate. Most MAC sub-headers are made up of six elements: two reserved bits, one extension field bit, one LCID (Logical Channel Identity), one ‘F-field’ bit and one length indicator. The extension field ‘E’ bit indicates whether there are any further sub-headers before the payload part. The LCID identifies the logical channel identity for the corresponding MAC SDU or, if the sub-header relates to a MAC control element or padding, it acts as a type field. The ‘F-field’ indicates the size of the length indicator (either 7 or 15 bits). The length indicator indicates the length of the corresponding MAC SDU or control element in octets. Transport blocks are not permitted to overlap across multiple MAC PDUs since a maximum of one MAC PDU can be transmitted per transport block per UE. A transport block will be transmitted within the TTI, which for E-UTRA is defined as a subframe period, or 1 ms.
Further Reading: 3GPP TS 36.321 4.4
© Wray Castle Limited
LT3600/v1.1
Radio Access Protocols
PBCH – RACH Preamble, Contention parameters
RACH Preamble
C-RNTI, TA, Power Adjustment
MAC Random Access Procedure The random access procedure is handled by the MAC and the physical layer and operates using a combination of the PRACH on the uplink and the PDCCH. UEs are informed of the range of random access preambles available in the current cell via the PBCH, as are the contention management parameters (maximum number of retries, back-off variables, etc.) currently in force. When a random access event is required, the UE will perform the following functions: review and randomly select a preamble check the BCCH for the current PRACH configuration; this will indicate the location and periodicity of PRACH resources in uplink subframes calculate open loop power control parameters – initial transmit power, maximum transmit power and power step discover contention management parameters As with legacy WCDMA systems, once the UE transmits an initial RACH it will wait a specified period of time (RA_WINDOW) for a response before backing off and retrying. Open loop power control ensures that each successive retry will be at a higher power level. Upon receipt of a successful uplink RACH preamble, the eNB will calculate power adjustment and timing advance parameters for the UE based on the strength and delay of the received signal and schedule an uplink capacity grant to enable the UE to send further details of its request. If necessary, it will also assign a RNTI (Radio Network Temporary Identifier) for the UE to use for radio mobility.
Further Reading: 3GPP TS 36.321 LT3600/v1.1
© Wray Castle Limited
4.5
LTE/SAE Engineering Overview
Bursty data
VoIP or other conversational services
Dynamic scheduling
Persistent scheduling
MAC (PDCCH)
MAC (PDCCH) RRC (DL-SCH)
Semi-Persistent scheduling
MAC Uplink Grant(PDCCH) Data
Data
Data
Data
Data
MAC Downlink Assignment (PDCCH) Data
Data
Data
Data
Data
MAC Scheduling Functions The main function of the MAC is to manage the shared access to a common transmission medium by multiple devices. This is achieved through the eNB’s scheduling function. Resource allocation will be performed on the basis of a scheduling algorithm, the specifics of which are not defined by the standards. However, channel performance, data buffer fill, UE power capability and traffic priority are likely to be considered. When a UE establishes an RRC relationship with an eNB it is assigned a C-RNTI, which will uniquely identify that UE in that cell. The C-RNTI will be used to address any control and scheduling messages to or from the UE. Each UE is capable of establishing multiple EPS bearers, which are the NAS traffic and signalling connections that travel from the UE to the core network. Allocations take the form of one or more PRB (Physical Resource Block), which will be populated using a specified MCS (Modulation and Coding Scheme). The allocations can be made for one or more TTI periods. LTE offers three scheduling modes. The first, known as ‘dynamic scheduling’, involves the use of MAC downlink assignment messages and uplink grant messages in the PDCCH to allocate resources as required. Dynamic scheduling is intended for typical bursty packet data traffic. For VoIP (Voice over IP) traffic where regular and reliable allocation of resources is required to meet more demanding QoS requirements, LTE offers ‘persistent scheduling’. This is achieved through a combination of RRC signalling in the DL-SCH (Downlink Shared Channel), for the initial specification of the resource allocation interval, and MAC signalling in the PDCCH for more specific PRB and MCS information. The result is a lower overhead in the PDCCH for these regular resource allocations. The third scheduling option, known as ‘semi-persistent scheduling’, is used specifically for the purpose of resource allocation for the establishment or reconfiguration of a persistent scheduled resource., i.e. for the transport of RRC messages relating to the persistent scheduled resource. In this case an SPS (Semi Persistent Scheduling) will be used to address the UE, which is different from the UE’s C-RNTI.
Further Reading: 3GPP TS 36.321, 36.331 4.6
© Wray Castle Limited
LT3600/v1.1
Radio Access Protocols
LCID 10
Voice bearer
SAE
C-RNTI – a12b
Data bearer
LCID 12
LCID L E LCID L E 10 12
PDCCH Scheduling Grant to C-RNTI a12b
Resource Multiplexing Each separate traffic flow, carrying one or more upper-layer EPS bearer connections, is assigned an LCID at the physical layer. The LCID is used to differentiate between logical data flows belonging to the same UE and is therefore be significant under the umbrella of one C-RNTI. Scheduling of non-multicast/broadcast traffic takes place on a ‘per UE’, or more precisely, on a ‘per C-RNTI’ basis. The allocation of uplink or downlink capacity to a UE is signalled on the PDCCH by the inclusion of the UE’s C-RNTI and the parameters of the allocated capacity. A MAC PDU will be mapped into the capacity thus signalled. The MAC PDU format makes it possible to multiplex a number of upper-layer SDUs and control messages together, the position of each within the PDU being flagged by MAC sub-headers showing the MAC SDU’s LCID. In this scenario, each MAC PDU will carry traffic for one UE only, but will be capable of multiplexing together traffic from several parallel services connected to that UE.
Further Reading: 3GPP TS 36.321 LT3600/v1.1
© Wray Castle Limited
4.7
LTE/SAE Engineering Overview
Downlink: Guaranteed Bit Rate (GBR) Aggregate Maximum Bit Rate (AMBR)
Uplink: Prioritized Bit Rate (PBR) Maximum Bit Rate (MBR)
QoS and Priority Handling QoS definition is the responsibility of the RRC layer but also has a bearing on the functionality of the MAC scheduler. On the downlink, SAE bearers are assigned a QoS level of either GBR (Guaranteed Bit Rate) or AMBR (Aggregate Maximum Bit Rate). GBR is applied to individual bearers, whilst AMBR is applied to a group of aggregated bearers which have been given no individual rate guarantees but which must share bandwidth with other members of the group. On the uplink, EPS bearers are first assigned a priority level, determined by the traffic type or some other differentiator. Each priority group in a cell is assigned a PBR (Prioritized Bit Rate), which limits the bit rates available to members of each group. Additionally, each bearer will be assigned its own specific MBR (Maximum Bit Rate). Scheduling for uplink allocations is handled on the basis of decreasing priority. For example, EPS bearers with the highest priority are scheduled first, then others in decreasing priority until capacity is exhausted.
Further Reading: 3GPP TS 36.300, 36.331 4.8
© Wray Castle Limited
LT3600/v1.1
Radio Access Protocols
Punctured Transmission Original data block
Chase Combining
Incremental Redundancy Pattern 1 Pattern 2 Pattern 3
N-process stop and wait subchannels
A
B
C
A
B
C
A
B
C
Sequential transport blocks assigned to different HARQ subchannels
HARQ Operation The ARQ process is managed by the RLC layer, while HARQ is handled by the physical layer and the MAC. Both processes are employed to manage the transmission and retransmission of transport blocks. ARQ performs retransmission of RLC PDUs carried by RLC acknowledged mode connections that fail to arrive and are therefore not acknowledged. Based on ACK/NACK responses from the peer RLC entity, ARQ will simply retransmit failed PDUs in sequence. HARQ is designed to speed up the retransmission cycle and to reduce the effect of retransmission problems such as head-of-line blocking. It does this in two ways. Firstly, HARQ employs complex TB (Transport Block) coding methods which initially reduce the amount of data transferred per block. This is achieved using ‘puncturing’ techniques, where specific bits in each TB are ‘knocked out’ of the block following a puncturing algorithm. The reduced size of each punctured TB therefore increases the overall capacity of the air interface. For punctured blocks that are received unerrored, the inverse of the puncturing process restores the missing data ready for the block to be processed. HARQ has two methods of dealing with errored blocks – chase combining and incremental redundancy. Chase combining simply retransmits the errored block and the receiving station attempts to build a ‘good’ copy of the original data from the received versions. Incremental redundancy is more complex and uses three puncturing algorithms on the original transport block. If the first copy of the block, punctured with the first algorithm, arrives with errors, the retransmitted block will be created using an alternative puncturing method. Again, the receiving station attempts to build a ‘good’ copy of the data from the blocks received. The other technique employed by HARQ is ‘N-process Stop and Wait’. In this technique the sequential stream of TBs travelling over a bearer is divided into a number of logical HARQ subchannels – for example, the 1st, 4th, 7th, etc. blocks could form subchannel A, the 2nd, 5th, 8th, etc. subchannel B and so on. Retransmission of an errored TB belonging to subchannel A only affects subsequent TBs belonging to that subchannel. TBs belonging to other subchannels will not be affected by the need to stop and wait for the missing TB to be retransmitted.
Further Reading: 3GPP TS 36.321 LT3600/v1.1
© Wray Castle Limited
4.9
LTE/SAE Engineering Overview
Transparent Mode Unacknowledged Mode Acknowledged Mode
RLC Modes The E-UTRA RLC layer is responsible for managing the flow of each EPS bearer across the air interface. To deal with the range of EPS bearer types, the E-UTRA RLC layer is required to support three different transfer modes: TM (Transparent Mode), UM (Unacknowledged Mode) and AM (Acknowledged Mode). Peer RLC layers dealing with the transfer of one bearer are known as RLC entities. TM bearers receive no service from the RLC layer, not even the addition of an RLC header to PDUs. Transport blocks are simply encapsulated and transferred. Error correction, retransmission and segmentation services for TM connections are assumed to take place at higher layers, if at all. UM bearers receive a connectionless service from the RLC layer. Segmentation and reassembly of RLC PDUs may occur if required; sequential transfer and reordering of PDUs will be performed, duplicate and errored PDUs will be discarded but retransmission is not supported. AM performs all of the functions of UM but also supports retransmission of errored or missing PDUs.
Further Reading: 3GPP TS 36.322 4.10
© Wray Castle Limited
LT3600/v1.1
Radio Access Protocols
Transparent Mode PDU – no added protocol data
Transport Block/PDCP SDU
Unacknowledged and Acknowledged Mode
SN
FI
E
LI
Transport Block/PDCP SDU
RLC PDU Structure For TM bearers an RLC PDU is simply the upper layer transport block with no additional protocol data added. For UM and AM connections the RLC layer adds a header and may or may not perform segmentation or concatenation of transport blocks as required. There are slightly different header layouts for UM and AM PDUs, but both types support the following fields: SN – Sequence Number FI – Framing Information E – Extension headers present indicator LI – Length Indicator (optional) Extension headers can optionally be added to the PDU Unlike the RLC layer in some legacy GSM and UMTS variants, the E-UTRA RLC has no fixed PDU size. Some legacy systems segmented all traffic into fixed-size RLC PDUs and then forced the MAC layer to concatenate multiple RLC SDUs into its own PDU structure. The E-UTRA avoids this unnecessary segmentation and concatenation where possible. The RLC layer attempts to deal with an upper-layer TB as a complete unit and will only segment when the TB (plus RLC data) is larger than the MAC PDU that will carry it.
Further Reading: 3GPP TS 36.322 LT3600/v1.1
© Wray Castle Limited
4.11
LTE/SAE Engineering Overview
IP Header
ROHC Applied
Transport Block
Transport Block
PDCP Ciphering
PDCP Header
£$%&^*&@~#%$#~@£$$
PDCP Operation Until relatively late on in the development of E-UTRA, PDCP was scheduled to operate between the eNB and the core network over the S1 interface, or between peer eNBs over the X2 interface during handovers. By the time the first release of specifications were published in October 2007, however, the functionality had been moved to the eNB. The basic functions of the PDCP layer are upper-layer (IP) packet header compression, ciphering and integrity protection of control messages. The header compression protocol is based on the RoHC framework, specified in IETF RFC 4995. There are multiple header compression algorithms, called profiles, defined for the RoHC framework. Each profile is specific to the particular network layer, transport layer or upper layer protocol combinations, e.g. TCP/IP and RTP/UDP/IP. Currently, E-UTRA supports only RoHC profiles that handle TCP/IP flows. Ciphering and deciphering in E-UTRA are performed at the PDCP layer, rather than at the physical, MAC or RLC layers as has variously been the case in previous systems. A detailed description of the E-UTRA ciphering services has yet to be published, but the outline details available so far indicate that it operates following the same principles as the ciphering schemes employed by GSM and R99 UMTS – a shared secret operating between the SIM (Subscriber Identity Module) and the HSS. PDCP is only responsible for ciphering over the air interface. Each eNB will also maintain a separate ciphered connection with the EPC over the S1 interface and with other eNBs over the X2 interface. Ciphering is enabled by the CK (Cipher Key) parameter shared by the SIM and the HSS.
Further Reading: 3GPP TS 36.323 4.12
© Wray Castle Limited
LT3600/v1.1
Radio Access Protocols
No message authentication
MS
Message vulnerable, connection could be hijacked eNB CMAC message authentication
MS
Message protected, connection cannot be hijacked eNB
Integrity Protection The PDCP layer is also responsible for ensuring that control messages between the eNB and each UE are protected and that any interception or modification of messages is detectable. The integrity protection scheme employed in the E-UTRA is outlined in 3GPP TR 35.201 and uses a MAC (Message Authentication Code) mechanism based on the f9 Kasumi algorithm. CMAC (Cipher-based MAC) authentication provides a simple method of checking the authenticity of a message and determining whether it has been tampered with ‘in flight’. Management messages are provided with a CMAC tag, which is generated using a combination of the CMAC algorithm, the message content and the encryption system’s ‘shared secret’. The transmitting device inserts a CMAC into each management message that is issued. The receiving device generates its own CMAC tag based on the received message contents, the CMAC algorithm and its copy of the shared secret. If the message is authentic and unaltered the locally generated CMAC tag should match the one appended to the message and the management message is therefore accepted as genuine. Integrity protection is enabled by the IK (Integrity Key) parameter shared by the SIM and the HSS.
Further Reading: 3GPP TS 35.201, 36.323 LT3600/v1.1
© Wray Castle Limited
4.13
LTE/SAE Engineering Overview
User Equipment
eNB
Evolved Packet Core Non-Access Stratum (NAS)
Non-Access Stratum (NAS) RRC
RRC
Broadcast Control Channel (BCCH) Paging Control Channel (PCCH) Connection management C-RNTI Measurement reporting Handover QoS management Direct Transfer
RRC Functions As with other E-UTRA protocols, the RRC layer which previously resided in the RNC has been devolved to the eNB. The main RRC functions performed by the eNB include: creation of BCH (Broadcast Channel) system information creation and management of the PCH (Paging Channel) RRC connection management between eNB and UEs, including generating temporary identifiers such as the C-RNTI mobility-related functions such as measurement reporting, inter-cell handover and inter-eNB UE context handover QoS management direct transfer of messages from the NAS to the UE The RRC is in overall control of radio resources in each cell and is responsible for collating and managing all relevant information related to the active UEs in its area. The BCH provides the main means of advertising the services available in a cell and the means by which those services can be accessed. The E-UTRA BCH carries system information related to the NAS, such as PLMN identity (network code and country code) and AS (Access Stratum) details such as cell ID and tracking area identity. E-UTRA has been designed with network sharing in mind and the BCH can in theory carry details of up to six sharing PLMNs (Public Land Mobile Networks). Each eNB is responsible for managing inter-cell handovers between all the cells it controls. When handover to another cell site is required the eNB will pass details of the current UE context to its neighbour. This includes details of identities used, historical measurements taken and active EPS bearers. Further Reading: 3GPP TS 36.331 4.14
© Wray Castle Limited
LT3600/v1.1
Radio Access Protocols
Monitors BCH system information Monitors paging channel Performs cell reselection Assigned tracking area ID by MME Performs location updates No RRC context stored in the eNB.
RRC Idle
RRC Connected UE has an E-UTRAN-RRC connection UE has context in E-UTRAN E-UTRAN knows the cell which the UE belongs to Network can transmit and/or receive data to/from UE Network-controlled mobility Neighbour cell measurements
RRC States Legacy GSM and UMTS air interfaces used a variety of terms to describe the states an MS (Mobile Station) or UE could be in over time: GSM used one set of descriptions, GPRS a slightly different set and R99 a different set again. E-UTRA also uses a different, but very simple, set of RRC state descriptions. The RRC idle state refers to terminals that are powered on and have performed network access, but are currently not supporting any connections. RRC idle terminals will monitor the paging channel in the camped-on cell and will perform cell reselection as required. Idle UEs have no RRC content with any eNB and therefore have no C-RNTI assigned. The only transitory identity they have will be the TAI used for paging purposes by the MME. A connected UE will have an active RRC context in place with one or more eNBs. Its location will therefore be known down to the serving-cell level and it will have at least one C-RNTI assigned. As part of the RRC context establishment process the eNB will have contacted the HSS (via the MME) and received security and authentication vectors for the UE. Ciphering and integrity keys will therefore also be in place. RRC-connected does not necessarily imply that the UE has any active EPS bearers, only that it has made contact with an eNB.
Further Reading: 3GPP TS 36.331 LT3600/v1.1
© Wray Castle Limited
4.15
LTE/SAE Engineering Overview
Radio Bearer Control Radio Admission Control Connection Mobility Control
Resource Allocation
Interference Co-ordination
Load Balancing
Inter-RAT Functions
Radio Resource Management Functions As well as the RRC layer, the eNB has also inherited the RRM (Radio Resource Management) that previously resided in the RNC. The basic set of RRM functions performed by the eNB are described below. The RBC (Radio Bearer Control) functions in the E-UTRAN share more in common with those in HSPA than in R99 due to the lack of a dedicated channel structure. RBC functions are closely allied to those of the scheduler in that they are both concerned with making the best possible use of the radio resources available in a cell. The task of RAC (Radio Admission Control) is to admit or reject the establishment requests for new radio bearers. Each new request made in response to a user request, a paging event or a handover, is evaluated in terms of the current cell load and the effect the new bearer may have on existing connections. CMC (Connection Mobility Control) is concerned with mobility management functions such as the creation and control of broadcast channel parameters that aid cell selection and reselection for idlemode UEs. CMC also manages handover events for active-mode UEs and the collation and analysis of measurements associated with handover. The task of DRA (Dynamic Resource Allocation) or PS (Packet Scheduling) is to allocate and deallocate eNB and air interface resources for the transmission of user and control plane packets. At the physical layer this includes the selection of resource blocks and at higher layers these functions take aspects such as priority and QoS into account. ICIC (Inter-Cell Interference Coordination) has to manage radio resources so that inter-cell interference is kept under control. This may involve communication over the X2 interface to ensure that neighbouring eNBs co-ordinate their ICIC activities. LB (Load Balancing) seeks to provide even distribution of the air interface traffic load over the cells controlled by the eNB so that no individual cell is overloaded. Inter-RAT RRM ensures that the eNB co-ordinates its activities with base stations supporting other air interface variants such as GSM or WCDMA. Further Reading: 3GPP TS 36.300, 36.331 4.16
© Wray Castle Limited
LT3600/v1.1
Radio Access Protocols
MME-1
MME-1 SG-W
TA2 TA1
TA4 TA3
MME Pool Area 1
TA6 TA5
MME Pool Area 2
Network Nodes and Areas
Network Nodes and Areas Individual network nodes, such as eNBs, MMEs and gateways, will continue to require unique identifiers in EPS just as in legacy networks. The MME ID and eNB ID will therefore perform the same functions (and may have the same format) as the VLR and base station IDs employed currently in GSM and R99 UMTS. For paging purposes, the E-UTRAN is subdivided into one or more TAs (Tracking Areas), each of which is assigned a unique TAI (Tracking Area ID). The use and functions of the TA are analogous to the location areas employed by GSM. A TA is, in theory, the responsibility of one MME, but to ensure resilience in the event of device failure, MMEs can be logically grouped into MME pools with some or all TAs being multihomed to more than one MME.
Further Reading: 3GPP TS 23.401, 29.803 LT3600/v1.1
© Wray Castle Limited
4.17
LTE/SAE Engineering Overview
PBCH and P/S-SCH 3 MHz channel 5 MHz channel
10 MHz channel
UE scans for DC carrier
20 MHz channel
System Acquisition Cell search is a prerequisite to network entry and must be performed each time a UE in the detached state finds itself with no valid assigned or stored channel details. Compared to systems such as GSM and UMTS R99/R4, which employ fixed channel bandwidths, E-UTRA’s support for a variety of channel bandwidths – from 1.4 MHz to 20 MHz – represents a slightly more complex challenge in relation to cell search. There are, however, a few basic system constants designed to ensure that cell search operates in much the same way across all channel bandwidths. Firstly, although the overall channels have a variety of bandwidths, they are all constructed from resource blocks, which are always 180 kHz wide. Additionally, irrespective of the bandwidth, all the main control channel functionality is contained in 72 subcarriers in the centre of the channel. The UE continues to employ the cell search conventions used by GSM and UMTS. Where possible the UE will store details of the last used channel on the SIM on power-off and will attempt to reuse that channel when powered back on. If the stored channel is not available the UE will attempt to use the operator-defined channel list stored on the SIM, if such a list exists. If not then the UE will be forced to perform a full cell search over the range of channel bandwidths and frequency bands that it supports. Neighbour-cell search for handover and reselection purposes is based on the same downlink signals as initial cell search.
Further Reading: 3GPP TS 23.401, 36.300, 36304 4.18
© Wray Castle Limited
LT3600/v1.1
Radio Access Protocols
MME A requests authentication vectors from HSS MME A
eNB selects an MME to serve newly connected UE MME B
UE answers MME authentication challenge using security details stored on USIM
HSS
MME C
Attach Procedures Once acquisition has taken place, the process of synchronizing with a channel to read its broadcast control information must be achieved. Again, the basic architecture of the E-UTRA channel is designed to ensure that the process is the same for any channel bandwidth. The P-SCH and S-SCH are transmitted every 5 ms and use the six RBs clustered around the DC carrier. Six RBs, at 180 kHz per block, occupy a little over 1 MHz of bandwidth. As the narrowest channels currently being considered for E-UTRA operation are 1.4 MHz wide it means that the P/S-SCH (Primary/Secondary Synchronization Channel) will be able to occupy the same position in the frequency structure of any E-UTRA variant. The MIB (Master Information Block) of the BCCH also occupies the same six RBs at the centre of each E-UTRA downlink channel, allowing UEs to discover information such as PLMN identity, Cell ID (or eNB identity) and random access parameters in a standardized way. In response to a random access preamble transmitted by a UE, the eNB will grant a series of uplink and downlink capacity blocks via which it and the UE can perform the network attach procedure. If the S1-flex facility is available and the serving eNB has access to multiple MMEs, it will select, possibly at random or following a ‘round robin’ process, an MME with which to initiate the attach process. Not all UEs camped-on the same cell will necessarily have contexts established with the same MME, allowing a greater degree of resilience in the event of an MME failing. In principle, the E-UTRAN attach process operates in the same way as in GSM, only the names of some of the nodes and the location of some of the events has changed; the UE provides an IMSI (International Mobile Subscriber Identity) to the MME; the MME interrogates the HSS and receives AVs (Authentication Vectors); the UE is challenged using these vectors and if it provides the correct response it is deemed to be authentic; the eNB is provided with security vectors that allow ciphering and integrity protection to be established over the air interface; the MME assigns an M-TMSI (MME Temporary Mobile Subscriber Identity) to the UE and commences location tracking. A default EPS bearer will be created to allow the UE to register with the IMS. In order to perform the attach, the UE will move to the RRC connected state for the duration of the attach process before moving back down to the RRC Idle state. Once attached, the UE will be logged as in the EMM (EPS Mobility Management) attached, ECM (EPS Connection Management) idle states by the MME. Further Reading: 3GPP TS 23.401, 36.300, 36.304 LT3600/v1.1
© Wray Castle Limited
4.19
LTE/SAE Engineering Overview
Current best cell
Optional NCL
Reselection made if candidate achieves reselection criteria
Idle Mode Procedures RRC idle mode procedures for a UE are mainly concerned with cell reselection functions. Reselection is intended to ensure that a UE is camped-on to the best available cell for the purposes of monitoring the paging channel and for handling any outgoing connection requests from the user interface. Reselection is triggered if measurements taken of the current camped-on cell fall below thresholds defined on the BCCH. Neighbour cell measurements are only required if the signal received from the current camped-on cell drops below an advertised threshold. The reselection process undertaken by the UE can be simplified if the eNB publishes an idle mode neighbour cell list that gives details of the cells available for reselection. This facility is optional in E-UTRA and if a neighbour cell list is not available the UE will be required to perform a full cell search each time reselection is triggered.
Further Reading: 3GPP TS 23.401, 36.300, 36.304 4.20
© Wray Castle Limited
LT3600/v1.1
Radio Access Protocols
MME
New best cell
Current best cell TA ID=11 Optional NCL
TA ID=10
Reselection made Location Update on MME as TA changes
Tracking Areas and Paging UEs in the idle state will be performing cell reselections as required to ensure that the best available cell is camped on (even if it means changing air interface RAT). After reselection, the UE will monitor the BCH in the new cell. If the Tracking Area ID transmitted in the new cell differs from that transmitted in the old cell then the UE moves to the RRC connected state and performs a location update. The MME will track the location of each attached UE down to the TA level and will update its stored information on receipt of a TAU (Tracking Area Update). In legacy GSM networks, the location tracking function performed by the MME was the responsibility of the VLR in the serving MSC (Mobile-services Switching Centre). Each VLR had sole responsibility for a specific set of base stations and if the VLR failed then paging and locations updates within that set of cells also failed. In LTE, the S1-flex facility ensures that each eNB has access to a number of MMEs and S-GWs. This flexibility ensures more resilience than was previously available and mirrors the Iu-flex facility introduced into UMTS in Release 5. Each eNB is responsible for compiling its own paging channel, based on a paging request sent from the MMEs. In an S1-flex environment each eNB will be receiving paging information from multiple MMEs, which will be combined and propagated through its cells.
Further Reading: 3GPP TS 23.401, 36.300, 36.304 LT3600/v1.1
© Wray Castle Limited
4.21
LTE/SAE Engineering Overview
Seamless Handover
Lossless Handover
(non-delay tolerant, error tolerant)
(delay tolerant, non-error tolerant) MME
S-GW PDCP sequence continued
LP
S-GW
4
PDCP reset
4
MME
1
5
1
2
6
2
3
3
7
Source eNB
Target eNB
Source eNB
LP
4
Target eNB
3 6
4
4
5
3
3
3
4
2
2
2
3
1
1
1
H/O
H/O
LTE Handover Types LTE offers two mechanisms for maintaining data flow to a UE as it moves from one cell coverage area to another. Once a handover decision has been made based on measurement information the system may transfer the data flow using either a ‘seamless’ handover or a ‘lossless’ handover. A seamless handover is intended for delay tolerant services such as VoIP. In general seamless handover is applied for radio bearers using the UM mode of RLC. In this procedure, untransmitted packets can be transferred from the source eNB to the target eNB, but no acknowledgment status is supplied. Thus in the example shown the packet transmitted with PDCP sequence number 3, which has not been acknowledged will be lost. Only PDCP packet 4 is transferred since it has not yet been transmitted. When transmission is resumed on the target cell, PDCP and other counters are reset. This results in a faster handover, but may result in packet loss. For data services that can tolerate some delay but for which packet loss is not acceptable, a lossless handover is used. In general, lossless handover is applied for radio bearers using the AM mode of RLC. In this procedure PDCP context is transferred from the source eNB to the target eNB. PDCP and other counters continue the existing sequence. Thus in the example, PDCP packet 3 is retransmitted on the target eNB since although it had already been transmitted, it had not yet been acknowledged.
Further Reading: 3GPP TS 23.401, 36.300 4.22
© Wray Castle Limited
LT3600/v1.1
LTE/SAE Engineering Overview
Section 5
Evolved Packet Core
© Wray Castle Limited
LTE/SAE Engineering Overview
ii
© Wray Castle Limited
LT3600/v1.1
Evolved Packet Core
Contents EPS Network Functions .......................................................................................................................5.1 Network Logical Structure ....................................................................................................................5.2 MME (Mobility Management Entity) .....................................................................................................5.3 S-GW (Serving Gateway).....................................................................................................................5.4 PDN-GW (Packet Data Network Gateway)..........................................................................................5.5 PCRF (Policy and Charging Rules Function).......................................................................................5.6 Combined Functionality........................................................................................................................5.7 Resilience Through Pooling .................................................................................................................5.8 Interface Naming Convention ..............................................................................................................5.9 S1 to E-UTRAN Interface...................................................................................................................5.10 S1-U Interface ....................................................................................................................................5.11 S1 Interfaces for Home eNBs ............................................................................................................5.12 GTPv1-U Traffic Interfaces ................................................................................................................5.13 GTPv2-C C-plane Interfaces..............................................................................................................5.14 Diameter-based Interfaces.................................................................................................................5.15 PCRF Diameter Interfaces .................................................................................................................5.16 Interface to CS Networks ...................................................................................................................5.17 EPS Area Identities ............................................................................................................................5.18 Node Identifiers ..................................................................................................................................5.19 Subscriber Identities...........................................................................................................................5.20 Connection Identifiers ........................................................................................................................5.21 Transport Identities ............................................................................................................................5.22 LT3600/v1.1
© Wray Castle Limited
iii
LTE/SAE Engineering Overview
Default and Dedicated EPS Bearers..................................................................................................5.23 EPS Quality of Service.......................................................................................................................5.24 QoS Levels.........................................................................................................................................5.25 Providing CS Services via LTE/EPS..................................................................................................5.26 CS Fallback ........................................................................................................................................5.27 CS Service Provision via a GANC .....................................................................................................5.28 VCC (Voice Call Continuity) ...............................................................................................................5.29 EPC Security Functions .....................................................................................................................5.30 AKA (Authentication and Key Agreement).........................................................................................5.31 User Confidentiality ............................................................................................................................5.32
iv
© Wray Castle Limited
LT3600/v1.1
Evolved Packet Core
Objectives
At the end of this section you will be able to:
outline the functions performed by EPC elements
discuss options for interworking the EPC with legacy packet core networks
describe the main points of interest related to EPC topics such as pooling
list the set of S interfaces described for the EPC and outline their basic functions and protocols
discuss options for User Plane connectivity between a UE and a PDN-GW
outline how combinations of redundant S interfaces can provide for EPC resilience
list the basic set of identifiers used to describe EPC areas
outline the set of node identifiers that have been defined for the EPC
discuss the impact of the evolved device/subscriber identifiers employed by the EPC
outline the fundamental properties of an EPS Bearer and describe the structure of an EPS Bearer ID
describe the relationship that exists between an EPS Bearer and an E-RAB (E-UTRAN Radio Access Bearer)
outline the role of the APN (Access Point Name) in the handling of a PCS (PDN Connectivity Service)
describe the interaction between the EPC and the GTP
outline the interaction between the EPC, GTP and IP
discuss the concept of the PCS and its relevance within the EPC
outline the functions of the default EPS Bearer
describe the differences between the default and dedicated bearer types and outline their relationship with the Service Data Flow
describe the EPC connection hierarchy and list the set of parameter types that define them
outline the QoS concepts employed by the EPC and define the roles of the QCI and the ARP
outline the methods that are available for providing CS services to EPS attached UEs, including Generic Access Network functions, CS Fallback and Voice Call Continuity
outline the security functions employed by the EPC
LT3600/v1.1
© Wray Castle Limited
v
LTE/SAE Engineering Overview
vi
© Wray Castle Limited
LT3600/v1.1
Evolved Packet Core 2G/3G SGSN
UMTS/ GPRS
HSS
Network Access IP Functions
UTRAN/ GERAN
S6a
S3
PCRF
MME S4 S12 S7/Gx
E-UTRA S1-MME
S11
IMS S5
E-UTRAN
SGi IP Services
S1-U S-GW Interworking to MME
Rx+
PDN GW
S2
Mobility Management Anchoring
WLAN or WiMAX
Network Management
EPS Network Functions
EPS Network Functions Network Access functions include providing information to assist terminals with network selection and performing admission control, authentication and authorization, charging and policy control. EPC gateway nodes are essentially IP routers with an extended capability set, and as such are primarily dedicated to performing IP packet routing functions for user traffic, signalling and network management data flows. The EPC (via the PDN-GW) is also responsible for allocating valid IP addresses to each new EPS Bearer. Regarding mobility management, the EPC has responsibility for idle mode mobility management of attached UEs and for managing the relocation of user traffic connections when a UE roams from one network area to another or to another network. The EPC is responsible for selecting the PDN-GW node that will anchor each user traffic connection (or EPS Bearer); this is achieved by selecting the appropriate PDN-GW access point for the type of service being requested by a UE. Basic network management functions performed by the EPC include load balancing and rebalancing between MMEs. The objective of these balancing functions is to prevent an MME or pool of MMEs from becoming overloaded.
Further Reading: 3GPP TS 23.401:4.3 LT3600/v1.1
© Wray Castle Limited
5.1
LTE/SAE Engineering Overview
User Equipment
Uu
eNode B
Non-Access Stratum (NAS) Access Stratum (AS)
S1
Evolved Packet Core
Non-Access Stratum (NAS) Access Stratum (AS)
Network Logical Structure
Network Logical Structure As with UMTS R99, the services provided to UEs by the EPS are divided into those handled by the AS and those provided by the NAS. The AS comprises all of the functions performed by the E-UTRAN. The NAS consists of the Bearers and bearer control signalling functions that support them. S1AP includes provision for the direct transfer of NAS signalling between UE and MME via the eNB. Compared to the core network architecture of previous generations of mobile system such as GSM or R99 UMTS, the EPC has been provided with a much ‘flatter’ network design, which limits the number of node types deployed.
Further Reading: 3GPP TS 36.300 5.2
© Wray Castle Limited
LT3600/v1.1
Evolved Packet Core
Mobility Management Entity (MME)
NAS signalling and signalling security Inter CN node signalling for mobility between 3GPP access networks UE reachability in idle mode Tracking Area list management PDN GW and serving GW selection MME selection for handovers with MME change SGSN selection Roaming connection towards home HSS Authentication Bearer management and establishment
MME (Mobility Management Entity)
MME (Mobility Management Entity) The MME assumes many of the functions that would previously have been performed by the VLR or SGSN and which in the evolved network are termed EMM (EPS Mobility Management) functions. The MME’s main responsibility is to terminate the Control Plane NAS signalling flows from individual UEs and to manage the authentication and security functions for each attached UE. Unlike the legacy VLR, however, the MME is also responsible for bearer establishment. It receives Service Requests from UEs and issues appropriate instructions to the S-GW that will handle each user plane connection. The EMM functions also include responsibility tracking UEs that are in idle mode and the MME ensures ‘UE Reachability’ by receiving TAU messages, maintaining the tracking area lists and performing paging of individual UEs when required. To assist with service resilience, MMEs can be grouped into ‘pools’. eNBs are able to contact any MME within the pool(s) with which they are associated when passing on UE Attach requests. The MME then has flexibility as to the S-GW chosen to establish the user plane connection for each UE. The MME is also in charge of roaming and handover functions to 2G/3G SGSNs.
Further Reading: 3GPP TS 23.401:4.4.2 LT3600/v1.1
© Wray Castle Limited
5.3
LTE/SAE Engineering Overview
Serving Gateway (S-GW)
Local mobility anchor point for inter-eNB handover Mobility anchoring for inter-3GPP mobility Idle mode downlink packet buffering Lawful interception Packet routing and forwarding Transport level DiffServ packet marking Charging
S-GW (Serving Gateway)
S-GW (Serving Gateway) The S-GW handles user plane connectivity between UEs and the EPC and acts as the EPC mobility anchor for UEs roaming within part of a PLMN. This entails performing IP packet routing and buffering functions and also managing QoS by inserting DSCP (DiffServ Code Point) data into IP packet headers. The S-GW also provides mobility anchoring for connections that roam onto legacy 3GPP GERAN (GPRS/EDGE Radio Access Network) (2G) and UTRAN (UMTS Terrestrial Radio Access Network) (3G) access networks. As all EPS user traffic must pass through an S-GW it is a logical node within which, in concert with the PDN-GW, to base the EPS Lawful Interception interface and also the charging functions. The standard S5 and S8 interfaces that link the S-GW and PDN-GW are based on the 3GPP GTP; many non-3GPP systems obtain similar IP mobility functionality by employing the MIPv4 (Mobile IPv4) or PMIPv6 (Proxy Mobile IPv6) protocols developed by the IETF (Internet Engineering Task Force). Adapted versions of the S5 and S8 interfaces are available that support the PMIP protocol for IP mobility. In such cases, the S-GW will also act as the FA (Foreign Agent) to anchor mobile IP tunnels. To provide some legacy perspective, taken together the MME and S-GW provide the EPC with functionality similar to that previously provided by the SGSN, with the MME handling the signalling and session control aspects and the S-GW dealing with the user traffic.
Further Reading: 3GPP TS 23.401:4.4.3.2 5.4
© Wray Castle Limited
LT3600/v1.1
Evolved Packet Core
PDN Gateway (PDN-GW)
Per-user-based packet filtering Lawful interception UE IP address allocation DiffServ packet marking SDF level charging SDF gating control and data rate enforcement Contains APN (Access Point Name) DHCPv4 (server and client) and DHCPv6 (client, relay and server) functions
PDN-GW (Packet Data Network Gateway)
PDN-GW (Packet Data Network Gateway) If the functionality of the MME/S-GW can be thought of as analogous to that of the legacy SGSN, then the PDN-GW can be thought of as similar in function to the legacy GGSN. The PDN-GW (also known in some versions of the specifications as the P-GW) routes traffic between EPS Bearers and the SGi interface, which leads to external data networks such as the IMS and the Internet. As all inbound and outbound EPS traffic must pass through a PDN-GW it is the logical node in which the network’s packet filtering and classification functions are based. These include the ‘deep packet inspection’ techniques that are used to classify packets into particular SDFs (Service Data Flows) before routing them over an EPS Bearer or the SGi interface, which in turn allows the PDN-GW to act as the network’s PCEF (Policy and Charging Enforcement Function) Under direction from the PCRF (Policy and Charging Rules Function) the PDN-GW will apply ‘per SDF’ charging, service level and rate enforcement and QoS-related traffic shaping functions that control the ‘gating’ of user traffic flows. Each PDN-GW contains a number of logical access points (each identified by an Access Point Name or APN) which act as the GTP tunnel endpoints and mobility anchors of the EPS Bearers that extend service out to mobile UEs. As in the legacy GGSN, the APNs are responsible for the allocation of IP addresses to UEs during the establishment of each EPS Bearer and for routing traffic between the Bearers and particular external networks.
Further Reading: 3GPP TS 23.401:4.4.3.3 LT3600/v1.1
© Wray Castle Limited
5.5
LTE/SAE Engineering Overview
Policy and Charging Rules Function (PCRF)
Decides whether and when to create additional EPS bearers Provides PCC data such as service data flow detection, gating, QoS, ARP and flow-based charging information to traffic handling entities Terminates the S7/Gx and Rx interfaces for home network service and the S9 interface point for roaming with local breakout
PCRF (Policy and Charging Rules Function)
PCRF (Policy and Charging Rules Function) The PCRF is responsible for propagating the network’s connection policies and charging rules to the PDN-GW via the S7/Gx interface and to traffic gateway elements within the IMS via the Rx interface. It is the element that decides if new connections are to be allowed and, if so, whether they will be carried by an existing EPS Bearer or whether a new one is required. The PCRF is responsible for providing service data flow detection, gating, QoS and flow-based charging information to traffic handling entities within the network. This includes rules that allow the PDN-GW to provide the correct level of service to user data flows once the type of traffic being carried has been determined. For example, if the PDN-GW determines that the SDF to a user is carrying realtime traffic it may ‘gate’ up to the data rate and QoS level indicated by the PCRF and the user’s subscription profile. The PCRF’s charging rules allow the operator to apply the appropriate rating to CDRs (Call Data Records) generated for each SDF so that, for instance, real-time connections can be differentiated from an Internet browsing session. In the case of EPS roaming, when users use their terminals abroad, 3GPP has developed an extended PCRF architecture, based on the S9 interface, that defines Home (H-PCRF) and Visited (V-PCRF) logical functions.
Further Reading: 3GPP TS 23.401:4.4.7 5.6
© Wray Castle Limited
LT3600/v1.1
Evolved Packet Core
S1 1
Mobility Management Entity (MME)
Functions could be combined within same device S5
PDN Gateway (PDN-GW)
Serving Gateway (S-GW)
Combined Functionality
Combined Functionality 3GPP has deliberately designed the EPC network elements and interfaces to give vendors the greatest possible flexibility when developing their solutions. Although the MMW, S-GW, PDN-GW and PCRF all have a set of rigidly defined functions and open interfaces, the specifications make it explicit that equipment vendors are free to deploy these logical functions to physical devices in whatever way suits them best. For example, the MME and SGW functions can both be located in one device, such as an upgrade to an existing 3G SGSN platform. The S11 interface would then be internal to that combined device. In the same way it is conceivable that a vendor may decide to combine the functions of the S-GW and PDN-GW into one combined EPS gateway, rendering the S5 an internal interface.
Further Reading: 3GPP TS 23.401:4.4 LT3600/v1.1
© Wray Castle Limited
5.7
LTE/SAE Engineering Overview PDN-GW
Co-ordinated MME Pool and S-GW Service Area
E-UTRAN Tracking Areas served by Pools and Areas
Resilience Through Pooling
Resilience Through Pooling In common with ongoing developments within many existing 3G core networks, the EPC is designed to take advantage of the concept of ‘pooling’, specifically of MME and S-GW nodes. The ‘S1-flex’ facility that allows each eNB in the E-UTRAN to be associated with multiple MMEs in the EPC allows those MMEs to be grouped into ‘pools’. Each pool will be responsible for the eNBs in one or more complete tracking areas. This means that when an eNB selects the MME that will handle the Attach process for a UE, that MME can continue to serve that UE as long as it remains within the tracking areas associated with the MME’s pool. This reduces the requirement for MME relocation and consequently reduces the network’s signalling load. Pooling also provides a measure of resilience for network services to the extent that, if one MME falls over, eNBs have a number of alternative devices to select. As with current implementations of the pooling concept, however, MME pooling does not protect the connections to UEs being served by a failed MME – when the MME fails all ongoing services supported by it fail too. In the same way as an MME pool area comprises a set of cells within which a UE does not need to change the serving MME, an S-GW service area is a set of cells within which a UE does not need to change S-GW. MME pools may overlap, and each MME pool area is identified by an MMEGI (MME Group Identifier). S-GW Areas are also permitted to overlap.
Further Reading: 3GPP TS 23.401:3.1 5.8
© Wray Castle Limited
LT3600/v1.1
Evolved Packet Core 2G/3G SGSN
UMTS/ GPRS
HSS Roaming PCRF
UTRAN/ GERAN
S6a
S3
EIR
EIR PCRF
S9
MME S12
S4 S13
E-UTRA S1-MME
S7/Gx
S11
IMS S5
E-UTRAN
SGi IP Services
S1-U S-GW Interworking to MME
Rx+
PDN GW S8
S2 EPS Roaming
WLAN or WiMAX
Interface Naming Convention
Interface Naming Convention There are numerous interfaces defined for the EPC, most of which share the reference letter ‘S’. They are functionally separated into those that carry control (C-plane) and those that carry user (U-plane) traffic. Support of most S interfaces in the EPC is mandatory, although some are optional. An overview of the interfaces is given in the diagram.
Further Reading: 3GPP TS 23.401:4.2 LT3600/v1.1
© Wray Castle Limited
5.9
LTE/SAE Engineering Overview MME
S1-AP SCTP IP S1-MME
L2 L1
User PDU eNB
GTPv1-U
S1-U
SCTP IP L2 S-GW
L1
S1 to E-UTRAN Interface
S1 to E-UTRAN Interface The S1 interface can be seen as the evolved equivalent of the 3G Iu interfaces and interconnects the E-UTRAN with the EPC. Individual S1 interfaces run logically between each eNB and the set of MMEs and S-GWs to which it is associated. Messages and other control plane traffic and S1-U flows carry user plane and call control traffic. Message structures for the S1-MME interface, which operates between the eNB and the MME, are defined by the S1AP. S1AP performs duties that combine those performed by the legacy RANAP and GTP-C protocols with additional elements to support traffic flows in an all-IP environment. Data flow over the S1-MME is protected from loss and network failure by the use of SCTP at the transport layer (layer 4). SCTP was specifically designed by the IETF to handle the flow of signalling and control traffic over an IP network. Retransmission of failed or missing data packets, and therefore guaranteed delivery of signalling data, is one of the facilities provided by SCTP.
Further Reading: 3GPP TS 23.401:5.1, 36.413 (S1AP) 5.10
© Wray Castle Limited
LT3600/v1.1
Evolved Packet Core MME
S1-AP SCTP IP S1-MME
L2 L1
User PDU eNB
GTPv1-U
S1-U
SCTP IP L2 S-GW
L1
S1-U Interface
S1-U Interface The S1-U interface employs GTP-U to create and manage tunnels carrying user-plane data contexts between the eNB and the S-GW. 3GPP has developed a new version of GTP (GTPv2) for use within the EPS. GTPv2 only changes the C-plane aspects of GTP, however, and is referred to as GTPv2-C. U-plane traffic continues to be carried by GTPv1. Current versions of the relevant 3GPP specifications refer to this version of GTP and GTPv1-U. The S1-U user plane carries all traffic destined to travel over the air interface to the UE, which includes all user data plus application control data such as SIP and RTP messages. It also handles the delivery of NAS signalling messages carried between the UE and the MME using the DTAP (Direct Transfer Application Part) facility. The S1-U interface employs UDP at layer 4 and therefore has no data retransmission capabilities available at the transport layer. Although the S1-Flex functionality allows each eNB to connect to multiple MMEs and S-GWs, an individual UE will, unless a relocation is taking place, only ever be served by one MME and one S-GW at any one time. All signalling and traffic connections for a UE will therefore be concentrated through one pair of devices.
Further Reading: 3GPP TS 23.401:5.1, 29.274 (GTPv2-C), 23.281 (GTPv1-U) LT3600/v1.1
© Wray Castle Limited
5.11
LTE/SAE Engineering Overview MME
S1-AP SCTP IP L2 L1
Home eNB Gateway (HeNB GW)
User PDU GTPv1-U
S1-MME Home eNB (HeNB)
SCTP
Broadband
IP L2
S1-U S-GW
L1
S1 Interfaces for Home eNBs
S1 Interfaces for Home eNBs The HeNB (Home eNode B) concept provides a standardized method for creating and connecting LTE ‘femtocells’. Similar methods have been developed for the 3G HNB (Home Node B). A femtocell provides limited-area radio coverage to residential or business premises; connections are passed back to the operator’s core network via a broadband Internet connection. Indeed, femtocell devices are often incorporated into broadband routers along with the broadband modem and Wi-Fi access point. The HeNB provides the same set of services as a ‘full’ eNB and is logically connected to the EPC via the same S1-MME and S1-U interfaces. Operators may optionally deploy an HeNB GW (Home eNB Gateway) to concentrate S1-MME traffic towards the MMEs, although the HeNBs will work even without a Gateway. The HeNB presents itself to the HeNB GW as an eNB; the Gateway presents itself to the HeNB as an MME. The HeNB GW presents itself to the MME as an eNB. An X2 interface between neighbouring HeNBs is not supported, although mobility between HeNB cells and other cells via the MME/S-GW is possible.
Further Reading: 3GPP TS 36.300:4.6, TR 25.820 5.12
© Wray Castle Limited
LT3600/v1.1
Evolved Packet Core RNC SGSN
S16 SGSN
S12
GTPv1-U S4
Roaming EPS
UDP IP L2
S8 PDN-GW
L1
S8 S-GW
S5 PDN-GW
GTPv1-U Traffic Interfaces
GTPv1-U Traffic Interfaces Most EPC interfaces are based on a combination of GTPv1-U and GTPv2-C. The S4 interface carries U-plane traffic between an S-GW and an SGSN for EPC-attached UEs that have roamed onto GERAN/UTRAN access. SGSNs that support the S4 can also be upgraded to use the S16 interface, which allows the evolved combination of GTPv1-U and GTPv2-C to be used between SGSNs. The S5 interface interconnects an S-GW to PDN-GW within the same PLMN. The S8 Interface provides roaming connectivity between a visited S-GW and a home PDN-GW. The S5 interface is based on the 2G/3G Gn interface, whilst the S8 is analogous to the Gp interface. The S12 interface is used to provide a U-plane only ‘direct tunnel’ between an S-GW and a 3G RNC, which allows the user plane to bypass the SGSN and thus avoids any traffic bottlenecks that may occur.
Further Reading: 3GPP TS 23.401:5.1, 23.281 (GTPv1-U), 23.060 (GPRS) LT3600/v1.1
© Wray Castle Limited
5.13
LTE/SAE Engineering Overview SGSN
S16 SGSN
S10 S3 MME
MME
GTPv2-C UDP IP
S11 Roaming EPS
L2 L1
S5 S8
S-GW
PDN-GW
GTPv2-C C-plane Interfaces
GTPv2-C C-plane Interfaces The S3 interface provides control plane connectivity between an MME and an SGSN and is used to carry handover and other control signalling between EPS and GERAN/UTRAN PS environments. The S16 interface carries control messaging between evolved SGSNs. The S16 interface carries control messaging between evolved SGSNs. If an S16 interface exists it can be used to handle the relocation of bearers between SGSNs without requiring the operation to be controlled by an S-GW. In addition to carrying user traffic, the S5 and S8 interfaces also carry GTPv2-C based control messaging. Networks based on non-3GPP protocols may elect to use variants of the S5 and S8 interfaces based on IETF ‘mobile IP’ protocols instead. The S10 interface carries inter-MME signalling traffic and is employed during functions such as MME relocation. This may occur, for example, when a Connected Mode UE roams out of one MME pool area into another, or when MME load balancing or rebalancing is taking place. The S10 is analogous to the Gn interface and is based on GTPv2-C running over UDP/IP.
Further Reading: 3GPP TS 23.401:5.1, 29.274 (GTPv2-C), 23.060 (GPRS) 5.14
© Wray Castle Limited
LT3600/v1.1
Evolved Packet Core
HSS SGSN
S6d
Diameter
S6a
TCP/SCTP
IP L2 L1 MME S13
EIR
Diameter-based Interfaces
Diameter-based Interfaces The Diameter protocol was designed by the IETF as a more standardized successor to the venerable RADIUS (Remote Access Dial-In User Service) protocol, which provides a method of transporting AAA (Authentication, Authorization and Accounting) data over an IP network. Various proprietary adaptations of RADIUS have been developed, which were largely non-interoperable, making it a de facto closed standard. The S6a interface connects the MME to the HSS and allows the secure transfer of subscriber and other data between those nodes. The Diameter Base Protocol and the applications that enable communication between the MME and HSS run over an IP link and can be protected at the transport layer by either TCP or SCTP. The S13 interface optionally interconnects the MME and the EIR (Equipment Identity Register) and is therefore analogous to the GPRS Gf interface. Unlike the Gf, however, the S13 interface is based on the Diameter protocol. The S6d interface allows 2G/3G SGSNs that also support the S4 interface to the S-GW to connect directly to the EPS HSS for mobility management and subscriber data access purposes.
Further Reading: 3GPP TS 23.401 LT3600/v1.1
© Wray Castle Limited
5.15
LTE/SAE Engineering Overview
Visited PCRF
S9
Home PCRF
Diameter
S7/Gx
Rx
TCP/SCTP
IP L2 IMS
L1
PDN-GW
PCRF Diameter Interfaces
PCRF Diameter Interfaces The S7 interface connects the PDN-GW to the PCRF. It carries policy lookups sent by the PDN-GW in response to connection requests and the replies generated by the PCRF that determine how or if those requests will be fulfilled. The S7 interface is based on the existing Gx interface and 3GPP specifications and diagrams use the reference names interchangeably. The Rx interface connects the PCRF to the IMS and carries a similar range of message types as the Gx. The S9 interface carries policy and charging rules data between home and visited PCRFs to allow home network policies to be applied to roaming UE connections. Visited PCRFs may have the facility to request PCC (Policy and Charging Control) details from a user’s home network but they are under no obligation to enforce them if they contradict local policies.
Further Reading: 3GPP TS 23.401:4.7.4; 23.203 5.16
© Wray Castle Limited
LT3600/v1.1
Evolved Packet Core
MSC/VLR or MSC Server
SGsAP SCTP SGs/SV
IP L2 L1
MME
Interface to CS Networks
Interface to CS Networks The EPC was designed as an ‘all IP’ environment and as such carries all traffic, even voice, in IP streams but interfaces have been developed that allow for backwards compatibility with and handover of CS traffic to legacy networks, if required. The SGs interface is based on the GERAN/UTRAN Gs interface and carries mobility management and handover signalling between an MME and a legacy MSC or MSC Server. It was created to serve the interfacing requirements of the CS Fallback service, which allows EPC-Attached UEs to drop back to 2G/3G networks to handle CS calls. The SGsAP (SGs Application Part) message format employed on the interface is an adaptation of the BSSAP+ (Base Station System Application Part +) protocol employed on the legacy Gs interface, and provides much the same set of services. Other interfaces have been developed to support other forms of EPC-CS Core interaction; the SGs interface, for example, carries MME-MSC/MSC-S signalling to support the SRVCC, which allows IMSanchored real time sessions to be seamlessly handed over between EPS Bearers and GERAN/UTRAN CS Bearers.
Further Reading: 3GPP TS 23.216 (SRVCC), 23.272 (CS Fallback) LT3600/v1.1
© Wray Castle Limited
5.17
LTE/SAE Engineering Overview PLMN = MCC+MNC
MME Group ID (MMEGI)
Tracking Area ID (TAI)
Evolved Cell ID (ECGI) = eNB ID + Cell ID
EPS Area Identities
EPS Area Identities The EPS continues to use the PLMN identifier employed by legacy 3GPP systems, which consists of the MCC (Mobile Country Code) and the MNC (Mobile Network Code). The MMEGI (MME Group Identifier) is a 16-bit identifier assigned to an individual MME Pool. The MMEGI only has to be unique within a PLMN. The TAI (Tracking Area Identifier) is analogous to the LA (Location Area) or RA (Routing Area) identifiers employed by the GERAN/UTRAN in that it is used to identify a group of cells in the access network. In the E-UTRAN the TA (Tracking Area) is the granularity with which each UE’s location is tracked. It is also the area within which a UE will be paged. The TAI consists of the network’s MCC and MNC followed by a TAC (Tracking Area Code). As in legacy systems it is necessary to be able to identify uniquely each cell in the network for call establishment, paging, handover and billing purposes. 3GPP has devised an updated Cell ID known as an ECGI (E-UTRAN Cell Global Identifier). The ECGI incorporates a unique eNB Identifier, which allows the S1 and X2 interface protocols to discover and identify the target nodes for functions such as EPS Bearer handover.
Further Reading: 3GPP TS 29.803, 23.401:5.2, 36.300:8.2 5.18
© Wray Castle Limited
LT3600/v1.1
Evolved Packet Core Gateway Names/IP addresses Access Point Name (APN)
MCC
MNC
MMEI
GUMMEI
24 bits
MMEGI
16 bits
MCC
MNC
eNB ID
20 bits
MMEC
MMEI
8 bits
Cell ID
ECGI
8 bits
Node Identifiers
Node Identifiers The MME is primarily a signalling node and each MME has to be accessible to and exchange control data with MMEs and other devices within its own network and in other networks elsewhere in the world. For this reason, each MME is assigned a unique and globally significant identifier known as a GUMMEI (Globally Unique MME Identity). The GUMMEI consists of the network’s MCC and MNC followed by a MMEI (MME Identifier), which in turn consists of the MMEGI and the MMEC (MME Code). The MMEGI identifies the Pool to which the MME belongs and the MMEC is its index within that pool. The addressing of S-GW and PDN-GW nodes follows the model for addressing legacy PS core network nodes – ultimately, each node will be identified by an IP address, which may or may not be backed up with a DNS-resolvable device name. The termination and anchor point for an EPS Bearer is an access point in a PDN-GW, which is analogous to a PDP Context terminating on GGSN APN in 2G/3G networks. Each PDN-GW AP is assigned an IP address associated with a DNS-resolvable name – the APN (Access Point Name). The EPS ECGI is globally unique and allows individual cells to be separately identified. The ECGI is a 28-bit identifier which consists of the PLMN ID (MCC + MNC), a 20-bit eNB ID (which will be unique within a PLMN) and an 8-bit Cell ID (which will be unique within one eNB). This gives each PLMN scope to identify up to 1 million eNBs and for each eNB to control up to 256 cells.
Further Reading: 3GPP TS 23.401:5.2, 36.300 LT3600/v1.1
© Wray Castle Limited
5.19
LTE/SAE Engineering Overview
MCC
MNC
MMEI
M-TMSI
24 bits
32 bits
M-TMSI
GUTI
M-TMSI
32 bits
MMEC
M-TMSI
8 bits
32 bits
S-TMSI
Subscriber Identities
Subscriber Identities The main means of identifying EPS subscribers remains the IMSI, which is permanently assigned to a subscriber account. Temporary and anonymous identification of subscribers is provided by the GUTI (Globally Unique Temporary Identity), which is assigned by the serving MME when a UE has successfully attached and is reassigned if the UE moves to the control of a new MME. The GUTI is analogous to the legacy TMSI, but with the additional feature that its structure uniquely identifies not only the subscriber within the MME but also the MME that assigned it. The GUTI is constructed from the GUMMEI, which identifies the MME, and the M-TMSI. The M-TMSI is used to provide anonymous identification of a subscriber within an MME once that subscriber has been authenticated and attached. As with legacy TMSI use, the MME may elect to reissue the MTMSI at periodic intervals and it will be reissued in any case if the UE passes to the control of a different MME. The M-TMSI allows a subscriber to be uniquely identified within an individual MME, whereas the S-TMSI (SAE TMSI) allows subscribers to be identified within an MME group or pool. To achieve this, the S-TMSI simply adds the one-octet MMEC to the M-TMSI. The MMEC is the MME’s index within its pool.
Further Reading: 3GPP TS 23.203, 23.401:5.2 5.20
© Wray Castle Limited
LT3600/v1.1
Evolved Packet Core
MME
S-GW UE
PDN-GW
EPS Bearer Radio Bearer
Connection Identifiers
Connection Identifiers The EPS Bearer ID is assigned by the MME upon bearer establishment. It uniquely identifies an EPS Bearer for one UE accessing via the E-UTRAN. The EPS Bearer ID is a one-octet string, which in theory means that each UE can have up to 256 EPS Bearers associated with it per MME. However, the relevant specifications currently indicate that the most significant 4 bits of the ID should be set to 0, which limits the number of EPS Bearers per UE to 16. The EPS Bearer travels between the UE and the PDN-GW; during handovers it may also extend over the X2 interface between source and target eNBs. When travelling over the S1 and X2 interfaces, there is a one-to-one mapping between the EPS Bearer and the E-RAB (E-UTRAN Radio Access Bearer) and between the identities assigned to each of those entities.
Further Reading: 3GPP TS 23.401:5.2.1 LT3600/v1.1
© Wray Castle Limited
5.21
LTE/SAE Engineering Overview
MME UE S1-AP ID
MME S1-AP ID
S1-MME S1-AP Context
UE
X2-U (GTP TE-IDs) X2-C (UE X2-AP IDs)
S1-U GTP Tunnel
S-GW
Tunnel Endpoint IDs (TE-ID)
Transport Identities
Transport Identities To allow the S1 and X2 protocols to identify the UEs that form the endpoint of each transport tunnel, terminals are assigned identities that are unique within the eNBs or MMEs that support those endpoints. The UE S1-AP ID and MME S1-AP ID are unique within the eNB and MME respectively that are handling the E-RAB/EPS Bearer to an Attached UE. The IDs are simple numerical identifiers (24-bits in the eNB and 32-bits in the MME) and are not associated with a specific instance of the S1 interface in each device. An eNB can therefore support a maximum of 224 (16.7 million) UE S1 connections and an MME 232 (4.3 billion). The UE X2-AP ID performs the same basic function as the S1-related identities, but for the X2 interface. The X2 is optional and is only used to pass handover-related traffic between source and target eNBs, so the X2-AP ID will only be created as required when a handover is initiated. The ID is 12 bits long and provides a maximum of 4096 UE X2 handover identities per eNB. The 4-byte GTP TEID (Tunnel Endpoint ID) is used in the EPS the same way as it is in legacy networks. Each device that supports a GTP tunnel refers to it in terms of the TEID assigned to the tunnel plus the IP address and UDP port number of the interface that handles it. TEIDs are assigned by the receiving side of each connection and are exchanged using S1-AP during tunnel establishment.
Further Reading: 3GPP TS 23.401:5.2; 36.413:9.2.3; 29.274 (GTPv2-C); 36.41x (S1); 36.42x (X2) 5.22
© Wray Castle Limited
LT3600/v1.1
Evolved Packet Core
Both Bearers share same IP address
Initial or Default EPS Bearer
eNB
Both Bearers routed via same APN
PDN-GW
S-GW Subsequent or Dedicated EPS Bearer
UE
IMS
Internet
Default and Dedicated EPS Bearers
Default and Dedicated EPS Bearers Each UE will establish an initial or default EPS Bearer as part of the attach process. This will provide the required ‘always on’ IP connectivity to the UE and may be to a ‘default APN’, if one is stored in the user’s subscriber profile, or to an APN selected by the network. In networks that interconnect to an IMS, the default bearer allows the UE to perform SIP registration and thereafter to provide a path for session initiation messaging. In these circumstances, the data rate and QoS assigned initially to the default bearer is commensurate with the expected low level of SIPbased traffic flow, but these parameters can be modified to accommodate the requirements of application traffic flows when a connection is established. If a UE has a requirement to establish an application connection whose QoS or data rate demands are incompatible with those currently assigned to the default bearer (but which can still be routed through the current APN), the PDN-GW or PCRF may initiate the establishment of an additional EPS Bearer to carry the new traffic flow. Any additional bearers assigned to a UE in addition to the default bearer are termed dedicated bearers and will be identified by different EPS Bearer/E-RAB and radio bearer IDs. A UE may have more than one PDN Connectivity Service running if it has connections established through more than one APN/PDN-GW. In that case, there will be one Default Bearer and an optional number of Dedicated Bearers created for each PCS. The 4-bit EPS Bearer ID limits the total number of bearers established for one UE to sixteen (numbered 0 to 15).
Further Reading: 3GPP TS 23.401:4.7.2 LT3600/v1.1
© Wray Castle Limited
5.23
LTE/SAE Engineering Overview
EPS QoS Characteristics
PCEF (Policy and Charging Enforcement Function) in PDN-GW
EPS
QCI (QoS Class Identifier) ARP (Allocation and Retention Priority) GBR (Guaranteed Bit Rate) MBR (Maximum Bit Rate)
EPS Quality of Service
EPS Quality of Service QoS in the EPS is defined by a combination of four parameters:
QCI – QoS Class Identifier
ARP – Allocation and Retention Priority
GBR – Guaranteed Bit Rate
MBR – Maximum Bit Rate
EPS QoS is applied between the UE and the PDN-GW.
Further Reading: 3GPP TS 23.401 5.24
© Wray Castle Limited
LT3600/v1.1
Evolved Packet Core
EPS bearer with GBR QoS
APN-AMBR for non-GBR EPS bearers to PDN-GW 2
S-GW
PDN-GW 1
UE
PDN-GW 2
UE-AMBR for all non-GBR EPS Bearers from UE APN-AMBR for non-GBR EPS bearers to PDN-GW 2
QoS Levels
QoS Levels QoS in the EPC is currently defined by three levels: GBR (Guaranteed Bit Rate), MBR (Maximum Bit Rate) and AMBR (Aggregate Maximum Bit Rate). GBR connections are assigned a guaranteed data rate and are therefore useful for carrying certain types of real-time and delay-sensitive traffic. MBR connections are non-guaranteed, variable-bit-rate services with a defined maximum data rate. If a connection’s data rate goes beyond the set maximum the network may decide to begin discarding the excess traffic. GBR and MBR parameters are applied on a ‘per bearer’ basis, whereas AMBR is applied to a group of bearers; specifically, a group of non-GBR bearers that terminate on the same UE. AMBR allows the EPS to set a maximum aggregate bit rate for the whole group of bearers that can then be shared between them. The APN-AMBR parameter sets the shared bit rate available to a group of non-GBR bearers that terminate on the same APN and can therefore be seen to be applied on a ‘per PCS’ basis; the UE-AMBR parameter aggregates all non-GBR bearers associated with one UE. Dedicated bearers can be established as GBR or non-GBR (i.e. MBR) as required. Default bearers, due to the probable need to adjust their bandwidth after the initial Attach has taken place, must be non-GBR.
Further Reading: 3GPP TS 23.401:4.7.3 LT3600/v1.1
© Wray Castle Limited
5.25
LTE/SAE Engineering Overview
MGW
A/Iu
GERAN/UTRAN Access
Gb/Iu
SGSN
Mc
S4
GERAN/UTRAN
CS traffic
MSC-S
S3
IMS
Sv
EPS
PS traffic MME UE using E-UTRAN access
SGi
S11
E-UTRAN Access
S5
S1 S-GW
PDN-GW
Providing CS Services via LTE/EPS
Providing CS Services via LTE/EPS The EPC was designed to handle non-real-time IP-based PS (Packet Switched) applications such as Internet access and messaging by providing an EPS Bearer between a UE and an external network or AF. 3GPP’s intention was that real-time and more traditional services, especially those that were handled by CS (Circuit Switched) networks – voice, fax, SMS, dial-up data, supplementary services, emergency calls, etc – would be handled in conjunction with an IMS. It was always accepted that some network operators may wish to continue to make use of their legacy CS core networks, either in place of an IMS or alongside one, and 3GPP and a number of industry bodies have proposed methods of achieving this.
5.26
© Wray Castle Limited
LT3600/v1.1
Evolved Packet Core
MGW
GERAN/UTRAN Access
Gb/Iu
EPS Attached UE
A/Iu
Paged via E-UTRAN SGSN
Falls back to GERAN/UTRAN for connection
IMS not required
Mc
CS traffic
Returns to E-UTRAN when Idle
S4
GERAN/UTRAN
MSC-S
S3 Sv
EPS
CS signalling MME SGi
S11
E-UTRAN Access
S5
S1 S-GW
PDN-GW
CS Fallback
CS Fallback Arguably, the simplest solution to the problem of providing CS services without necessarily deploying an IMS is to use 3GPP’s CS Fallback service. CS Fallback allows an EPS UE to perform combined Attach/Location Update functions with the EPS and the legacy CS core. Mobile-Terminated CS transactions, such as inbound calls or SMS, are directed to the legacy CS core as usual. The MSC or MSC Server that receives the inbound transaction alerts the UE’s serving MME via the SGs interface and the MME pages the UE. When it responds, the UE is directed to drop down to a ‘CS capable cell’ in the GERAN/UTRAN to receive the inbound service. Mobile-Originated CS services are handled in the same way, with the UE requesting the service via the EPS but being directed to GERAN/UTRAN access resources to complete the transaction. Once the CS transaction is over, the UE will return to idle mode and will camp onto an E-UTRAN cell. Any EPS Bearers carrying PS traffic will be handed over to the GERAN/UTRAN via an SGSN, if possible, when the CS Fallback is initiated. CS Fallback can operate in conjunction with IMS-based services or could be used as an interim measure by an operator that is not yet ready to deploy one.
Further Reading: 3GPP TS 23.272 (CS Fallback) LT3600/v1.1
© Wray Castle Limited
5.27
LTE/SAE Engineering Overview
MSC-S GERAN/UTRAN Access
MGW
A/Iu CS traffic
EPS Attached UE CS traffic forwarded to EPS via GANC GERAN/UTRAN
A/Iu
EPS-GERAN/UTRAN CS HO negotiated via SGs or Sv interfaces
GANC
SGs/Sv
IMS not required
EPS
MME SGi S11
E-UTRAN Access
S1
S5 S-GW
PDN-GW
CS Service Provision via a GANC
CS Service Provision via a GANC One further proposal for offering CS services via the EPS, put forward by the VoLGA (Voice over LTE Generic Access) Forum, is to reuse the framework developed to provide connectivity to 3GPP services via a GAN (Generic Access Network). A GAN can be essentially any kind of network that can support the flow of IP traffic, although the GAN specifications produced by organizations like 3GPP are mainly aimed at Wi-Fi based systems. This option involves causing the least disruption to the CS core and the EPS by installing a GANC (Generic Access Network Controller) between the two network environments. Handover and control signalling between the EPS and CS core would travel over the SGs or Sv interfaces, which were developed to support CS Fallback and SRVCC services respectively. The scheme does involve some administrative extensions to EPS operation, which would allow a suitably equipped UE to register for VoLGA services and for CS handovers between the EPS and 2G/3G networks.
Further Reading: 3GPP TS 43.318, 44.318 (GAN); www.volga-forum.com 5.28
© Wray Castle Limited
LT3600/v1.1
Evolved Packet Core
MGW UE HO to GERAN/UTRAN access
Gb/Iu
GERAN/UTRAN Access
A/Iu
SGSN
CS call employs SRVCC PS uses standard HO techniques
Mc
IMS S4
GERAN/UTRAN
CS traffic
MSC-S
S3 Sv
EPS
PS traffic MME SGi
S11 E-UTRAN Access
S5
S1 S-GW
PDN-GW
VCC (Voice Call Continuity)
VCC (Voice Call Continuity) VCC (Voice Call Continuity) is designed to make use of the combined resources of the IMS and legacy CS core network by allowing IMS-anchored real-time or CS calls to be handed over from the E-UTRAN and the GERAN/UTRAN. The specific variant of this concept outlined in the diagram is SRVCC (Single Radio VCC), which supports UEs that only contain one radio and can therefore only connect to one air interface method at a time; in this scenario, the UE is capable of connecting to E-UTRAN, UTRAN or GERAN cells but only one at a time. Call- and handover-related signalling is passed between the MME and MSC-MSC Server via the Sv interface. Handover or hand back of calls from UTRAN/GERAN to E-UTRAN is not supported; once a call drops down to 2G/3G it stays there. Any active PS sessions will be split from the CS sessions and handed over to a 2G/3G SGSN at the same time as the CS sessions are transferred. The SRVCC specification also provides options for handing over IMS-anchored real-time sessions from UTRAN (HSPA) and 3GPP2 1xRTT CDMA2000 access networks to GERAN/UTRAN resources.
Further Reading: 3GPP TS 23.216 (SRVCC) LT3600/v1.1
© Wray Castle Limited
5.29
LTE/SAE Engineering Overview
Mutual authentication Authorization User confidentiality Ciphering Integrity protection
EPC Security Functions
EPC Security Functions The EPC is responsible for maintaining user subscription and security data and for using that data to ensure that unauthorized users cannot gain access to network services. UEs must also be given the means to ensure that the network they are connecting to is valid and authentic. The EPC must also ensure that users’ identities remain confidential. The same applies to the traffic that users send over the network. Finally, the integrity of the flow of signalling and control traffic around and across the network must be protected to ensure that it is not intercepted and altered by unauthorized persons.
Further Reading: 3GPP TS 33.301 5.30
© Wray Castle Limited
LT3600/v1.1
Evolved Packet Core Quintuplet RAND
HSS
XRES
AUTN CK IK
MME
eNB
UE/USIM
AKA (Authentication and Key Agreement)
AKA (Authentication and Key Agreement) EPS employs the same AKA mechanism as is used by 3G UMTS networks. The EPS AKA mechanism aims to ensure that the network can authenticate users and vice versa, and that once authenticated, users and network can agree on a set of encryption mechanisms to employ to protect user and control traffic. EPS AKA operates between the UE and the MME and is facilitated by subscription data stored in the USIM (Universal Subscriber Identity Module) and the HSS. As in 3G UMTS, when a user is required to authenticate, the HSS will generate a quintet of AVs (Authentication Vectors): a random 128-bit number (RAND), an XRES (Expected Response), a CK (Cipher Key), an IK (Integrity Key) and an AUTN (Authentication Token) – which are passed to the serving MME. RAND is used as a challenge and is transmitted to the UE. The USIM processes RAND through its copy of the ‘shared secret’ K authentication key and generates a response, which is transmitted back to the MME. If the USIM response matches XRES then the USIM is deemed to be genuine and the UE is allowed to access network services. The CK is passed to the serving eNB to allow user plane encryption to and from the UE to take place, while the IK is employed between the UE and the MME to protect the integrity of signalling messages. Finally, the AUTN is passed to the UE to allow it to authenticate the network.
Further Reading: 3GPP TS 33.102; 33.401; 23.401 LT3600/v1.1
© Wray Castle Limited
5.31
LTE/SAE Engineering Overview
MME
M-TMSI
IMSI EPC and E-UTRAN
UE/USIM
User Confidentiality
User Confidentiality As with legacy 3GPP systems, the EPS uses the IMSI to absolutely and uniquely identify each user. The user confidentiality mechanism provides subscriber anonymity by ensuring that the IMSI is transmitted across the network as little as possible. A UE accessing a network for the first time or after a long period of inactivity has no option but to transmit its user’s IMSI to the network to allow identification and authentication to take place. Once the user has been authenticated, however, the MME generates an ‘alias’ that may then be used in place of the IMSI to identify the subscriber. Generically in 3GPP networks this alias is known as a TMSI (Temporary Mobile Subscriber Identity). The specific variety employed in the EPS is the M-TMSI. The correspondence between M-TMSI and a user’s true IMSI is known only to the MME and user’s UE. An M-TMSI will be unique within the MME that issued it. When combined with an MMEC to make an S-TMSI it becomes unique within an MME pool. When the M-TMSI is combined with a GUMMEI to form a GUTI it becomes unique within all EPS networks. The MME may elect to request UEs to reauthenticate periodically and will issue a new M-TMSI at this time. A UE may be issued a new M-TMSI when it moves to the control of a new MME. The EPS user confidentiality mechanism is essentially the same as that employed in the GERAN and UTRAN, although the identities of the relevant network elements have changed.
Further Reading: 3GPP TS 23.401; 33.401 5.32
© Wray Castle Limited
LT3600/v1.1
LTE/SAE Engineering Overview
Section 6
Major Protocols
© Wray Castle Limited
LTE/SAE Engineering Overview
ii
© Wray Castle Limited
LT3600/v1.1
Major Protocols
Contents
EPS Major Protocols ............................................................................................................................6.1 IETF Dependence ................................................................................................................................6.2 IP in the EPS/IMS ................................................................................................................................6.3 3GPP Protocols....................................................................................................................................6.4 Legacy GTP .........................................................................................................................................6.5 GTP in the EPS....................................................................................................................................6.6 S1AP (S1 Application Protocol) ...........................................................................................................6.7 S1AP and SCTP ..................................................................................................................................6.8 X2AP (X2 Application Protocol) ...........................................................................................................6.9 X2AP and SCTP ................................................................................................................................6.10
LT3600/v1.1
© Wray Castle Limited
iii
LTE/SAE Engineering Overview
iv
© Wray Castle Limited
LT3600/v1.1
Major Protocols
Objectives
At the end of this section you will be able to:
discuss the derivation of the major protocols employed by the EPC and highlight the organizations responsible for specifying them
list the set of major protocols defined by the IETF
outline the support the EPC provides for deployment of different versions of IP
describe the IP mobility concept and provide an outline of the functions of MIP, PMIP and DSMIP
discuss the transport layer protocols that are available for use in the EPC
describe the specific features of SCTP that make it suitable for transporting signalling flows over the EPC
outline the basic concepts employed by SCTP
discuss the role of SIP within the EPC and IMS and the supplementary functions performed by SDP and RTP
describe the functions performed by DiffServ within the EPC
outline the role of the Diameter protocol and discuss its use within the EPC
list the set of 3GPP-specific protocols developed or adapted for use in the EPC
describe the role performed by GTP in legacy 3GPP networks and highlight the differences between those versions and GTPv1-U and GTPv2-C
outline the functions performed by the S1 Application Protocol and the X2 Application Protocol
describe the message types and formats employed by the S1 and X2 protocols
LT3600/v1.1
© Wray Castle Limited
v
LTE/SAE Engineering Overview
vi
© Wray Castle Limited
LT3600/v1.1
Major Protocols
EPS
IETF
3GPP
EPS Major Protocols The Evolved Packet System is designed to be an ‘all-IP’ environment. This means that all protocols, whatever their function, will travel between network nodes via an IP transport network. IP is an open standards Network Layer/Layer 3 packet delivery system specified by the loose community of IT academics and professionals that comprise the IETF. IETF specifications exist in the form of RFCs (Requests For Comment), which are freely available for download and comment from their website – www.ietf.org. Most major protocols employed within the EPS were developed by the IETF, which means that the EPS can be regarded as a (mostly) open-standards networking environment. Where relevant IETF-based specifications do not exist or where a legacy protocol can be employed, 3GPP has developed protocols or reused protocols of its own. These protocols are mainly related to inter-node signalling functions and are either evolutions or combinations of existing 3GPP systems.
Further Reading: 3GPP TS 23.401, 36.300; www.ietf.org LT3600/v1.1
© Wray Castle Limited
6.1
LTE/SAE Engineering Overview
IETF
SDP
RTCP RTP
SIP
UDP
Diameter
SCTP IPv4/IPv6
TCP DiffServ
Mobile IP
Underlying Transport
IETF Dependence
IETF Dependence Many IETF protocols are employed within the EPS and the IMS. These include:
IP – support for IPv4 and IPv6
UDP – employed at the transport layer in many protocol stacks
TCP – generally only employed on the SGi interface
SCTP – employed on signalling interfaces
Mobile IP – MIPv4, PMIPv6 and DSMIPv6 are variously employed
SIP – employed by the IMS to establish user sessions
SDP – employed within SIP to describe session parameters
RTP – transports user session media flows
RTCP – provides control and feedback for RTP sessions
DiffServ – provides IP QoS services
Diameter – provides secure connections between signalling nodes
Further Reading: 3GPP TS 23.401; 36.300; www.ietf.org 6.2
© Wray Castle Limited
LT3600/v1.1
Major Protocols
Access Network
IPv4 Internet
IPv6 EPS
IPv4 EPS
IP in the EPS/IMS
IP in the EPS/IMS IP is the only packet transport mechanism employed by the EPS transport network. It does not support the layer 2 transmission protocols employed in legacy systems such as TDM (Time Division Multiplexing) and ATM (Asynchronous Transfer Mode). An IP ‘cloud’ provides logical and physical interconnections between EPS network nodes. The design of the cloud is intended to ensure that redundant paths exist between all nodes to allow the network to operate in a resilient and fault-tolerant manner. Equipment vendors and network operators have the option of deploying systems that support IPv4 (IP version 4) or IPv6 (IP version 6) or a combination of both (functionality which is referred to by EPS nodes as ‘IPv4v6’). Compared to legacy IPv4, which has been in use since the early 1980s, IPv6 has a flatter protocol structure - with many functions that required additional protocols in IPv4 being performed within the IP layer itself in IPv6. These additional features include functions such as dynamic IP address allocation, which required an additional protocol such as DHCP (the Dynamic Host Configuration Protocol) in IPv4, but is managed automatically (by means of router prefixes and host link local addresses) in IPv6. Support for security mechanisms such as IPsec (IP security) are also incorporated into the IP layer in IPv6. IPv6 is a backwards-compatible system, however, so network operators have the opportunity interface a new IPv6-based EPS with existing IPv4-based legacy packet core networks.
Further Reading: IETF RFCs at www.ietf.org LT3600/v1.1
© Wray Castle Limited
6.3
LTE/SAE Engineering Overview
3GPP
GTPv2
X2AP
S1AP
3GPP Protocols The Evolved Packet Core employs a number of protocols designed by 3GPP and ETSI (European Telecommunications Standards Institute). These include GTP (the GPRS Tunnelling Protocol), S1AP (S1 Application Protocol) and X2AP (X2 Application Protocol).
Further Reading: 3GPP TS 29.274 (GTPv2-C), 36.41x (S1), 36.42x (X2) 6.4
© Wray Castle Limited
LT3600/v1.1
Major Protocols GTPv0 tunnels
2G PS Core
SGSNs
GTPv1 Tunnels
RNC
3G PS Core
GTPvC and GTP-U tunnels
User traffic flow
Legacy GTP
Legacy GTP GTP was originally designed as part of the 2.5G GPRS packet core network and was employed to route encapsulated traffic packets between GPRS Support Nodes (SGSNs and GGSNs). The initial 2.5G version of GTP became known as GTPv0. As it matured, a number of basic problems were discovered. Chief amongst these was the fact that GTPv0 placed tunnel control and administrative information in fields in the headers of packets that also encapsulated user data. This meant packets that carried user data but no control information had a greater amount of header overhead than necessary, leading to a potentially inefficient service. GTPv1 was developed to offer an evolved service to 3G packet core networks. The most obvious difference with GTPv0 was the extension of the service beyond the SGSN and down to the RNC. Another major difference was the separation of the protocol into parts that dealt with control plane (GTP-C) and user plane (GTP-U) traffic. GTP-U packet headers could therefore be smaller and offer a more efficient service, as all control data was carried in its own logical stream.
Further Reading: 3GPP TS 23.060 LT3600/v1.1
© Wray Castle Limited
6.5
LTE/SAE Engineering Overview
GTP-U RNC
GTP-U and GTP-C GTP-C
Iu SGSN S3
S10
S12 S4
MME
MME
S11 Roaming EPS X2 S5 S8 S1-U
S-GW
PDN-GW
GTP in the EPS
GTP in the EPS GTPv2 (GTP version 2) was developed to allow the control of the tunnelling service offered by the protocol to adapt to the specific needs of the EPS environment. C-plane functions on GTP-based interfaces are handled by GTPv2-C, while U-plane traffic tunnelling continues to be handled by GTPv1, now known as GTPv1-U. In v1, GTP-C was used to carry tunnel creation and management messages between the GSNs and between the RNC and SGSN. To reflect the separation of bearer management and routing functions into the MME and S-GW respectively, in GTPv2-C the protocol is also used to carry bearer creation and management directives over the S11 interface between those nodes. The main functional evolution that GTPv2-C needs to support is the creation of default and dedicated EPS bearers on the S5 and S8 interfaces between S-GW and PDN-GW. GTPv2-C is also employed on the S3 interface that connects the MME to legacy SGSNs and on the S10 interface that interconnects MMEs. SGSNs that support the S4 interface to the EPC may also be upgraded to support the S16 interface in place of the legacy Gn; the S16 is also based on GTPv2-C. GTP-C is not employed on the S1-MME and X2 interfaces, where bearer creation and management is instead handled by interface specific Application Protocols (S1AP and X2AP), although GTPv2-C does carry instructions to the S-GW regarding the establishment of GTP tunnels that will then run over the S1-U interface. GTPv1-U is employed to encapsulate and route user plane traffic on all traffic-carrying interfaces, including S1, X2, S4, S5, S8, S12 and S16.
Further Reading: 3GPP TS 23.401, 29.274 (GTPv2-C); 29.281 (GTPv1-U) 6.6
© Wray Castle Limited
LT3600/v1.1
Major Protocols
MME
S1AP
SCTP IP
S1-MME
L2 L1
E-RAB management Initial context transfer UE context management Additional E-RAB creation Mobility functions Paging Direct transfer of NAS signalling
eNB
S1AP (S1 Application Protocol) S1AP is designed to provide a control plane connection on the S1-MME interface between an eNB and an associated MME. The S1-flex concept means that each base station may be associated with multiple MMEs, which in turn means that each eNB could host multiple instances of the S1AP. S1AP is responsible for E-RAB (E-UTRAN Radio Access Bearer) management i.e. setting up, modifying and releasing bearers under instruction from an MME. It also performs initial context transfer to establish an S1UE context in the eNB on initial attach including collating details of the UE’s capabilities and the creation of a default bearer. It undertakes UE context management; transferring UE context data between eNBs and MMEs in the event of handovers or relocations. S1AP is also responsible for the creation of additional E-RABs (for carrying further Default or Dedicated EPS Bearers) and for mobility functions for UEs in ECM-Connected state. It also performs paging and the Direct Transfer of NAS signalling between the UE and the MME. S1AP takes the place of GTP-C on the S1 interface, carrying bearer-specific control information between the MME and the eNB, including details such as TEIDs and UE S1 identities. S1AP is also responsible for carrying the messaging that enables the E-RAB ‘path switch’ function to take place after an inter-eNB handover. Additionally, it provides support for MME relocation and S-GW change functions. S1AP is an evolution of the RANAP protocol employed in 3G networks.
Further Reading: 3GPP TS 36.41x series, 36.413 (S1AP) LT3600/v1.1
© Wray Castle Limited
6.7
LTE/SAE Engineering Overview
MME Pool MME
S1-MME MME
eNB MME
S1 over SCTP Association eNB and MME act as SCTP endpoints MME
S1AP and SCTP S1AP connections are logical and are designed to operate over SCTP/IP links to multiple MMEs. The redundancy and resilience built into the ‘S1 Flex’ concept should ensure that the administrative load (and therefore also the risk) associated with the UEs served by one eNB is shared evenly between a group of MMEs. Each S1-MME interface is carried by an SCTP Association established between an eNB and an MME. One or more streams may then be established to carry S1AP message flows.
Further Reading: 3GPP TS 36.413; 23.401 6.8
© Wray Castle Limited
LT3600/v1.1
Major Protocols
X2-CP (Control Plane)
X2- AP
SCTP IP X2
Data link layer
X2AP
Physical layer
X2AP (X2 Application Protocol) The X2 interface is used to forward buffered traffic between eNBs during handovers and to provide a service management message path between neighbouring base stations. The X2 interface is optional but recommended as it has the potential to reduce significantly the amount of S1 signalling and handover traffic that the MMEs and S-GWs in a network are required to support. The X2 interface can be viewed as being broadly analogous in function to the Iur interface employed between 3G RNCs, although with no requirement to support macro diversity functions the scope of the X2 interface is greatly reduced. X2AP can therefore be viewed as analogous to the RNSAP signalling protocol employed on the Iur.
Further Reading: 3GPP TS 36.423 and 36.42x series in general LT3600/v1.1
© Wray Castle Limited
6.9
LTE/SAE Engineering Overview
X2 E-UTRAN IP transport X2
eNB A
eNB Z
X2 X2 interfaces are only required between eNBs that are likely to be required to hand traffic over between the cells they control.
X2 over SCTP Association Neighbouring eNBs act as SCTP endpoints
X2AP and SCTP X2AP connections can be logical (in which case they exist as routes travelling through the E-UTRAN IP transport network) or physical (carried between eNBs by a dedicated link or virtual path) and are designed to operate over SCTP/IP links between neighbouring eNBs. The X2 interface is optional but recommended. An X2 interface is only required between eNBs if there is a chance of handover traffic passing between the cells that they control; if eNB ‘A’ does not have an adjacency formed with eNB ‘Z’ there is no requirement for an X2 to exist between them. Each X2 interface is carried by an SCTP association established between eNBs. One or more streams may then be established to carry X2AP message flows.
Further Reading: 3GPP TS 36.423; 23.401 6.10
© Wray Castle Limited
LT3600/v1.1
LTE/SAE Engineering Overview
Section 7
EPC Operations
© Wray Castle Limited
LTE/SAE Engineering Overview
ii
© Wray Castle Limited
LT3600/v1.1
EPC Operations
Contents State Management...............................................................................................................................7.1 Combining EPS States.........................................................................................................................7.2 Active EPS Bearers and Bearer Contexts ...........................................................................................7.3 Inactive EPS Bearers and Bearer Contexts.........................................................................................7.4 Attach and Registration Requirements ................................................................................................7.5 EPS Initial Attach .................................................................................................................................7.6 Default Bearer Establishment ..............................................................................................................7.7 UE Idle Mode Functions.......................................................................................................................7.8 EPC Support for Idle Mode ..................................................................................................................7.9 TAU (Tracking Area Update)..............................................................................................................7.10 Idle-mode Signalling Reduction .........................................................................................................7.11 Paging ................................................................................................................................................7.12 IMS Functions in Idle Mode................................................................................................................7.13 Levels of Connectivity ........................................................................................................................7.14 UE-Triggered Service Request ..........................................................................................................7.15 Handling Additional Traffic Flows.......................................................................................................7.16 Dedicated Bearer Creation.................................................................................................................7.17 IMS Connection Establishment..........................................................................................................7.18 Charging Capture Points....................................................................................................................7.19 Connected Mode Procedures ............................................................................................................7.20 Intra-E-UTRAN Handover (X2-based) ...............................................................................................7.21 S-GW Relocation (X2-based).............................................................................................................7.22 MME Relocation.................................................................................................................................7.23 LT3600/v1.1
© Wray Castle Limited
iii
LTE/SAE Engineering Overview
Inter-RAT Handover ...........................................................................................................................7.26 Inter-RAT Handover Preparation .......................................................................................................7.27 Inter-RAT Handover Execution ..........................................................................................................7.28 IMS Procedures .................................................................................................................................7.30 E-UTRAN Detach...............................................................................................................................7.31 UE-initiated Detach ............................................................................................................................7.32
iv
© Wray Castle Limited
LT3600/v1.1
EPC Operations
Objectives
At the end of this section you will be able to:
describe the set of ‘state machines’ employed within the EPS
outline the roles of the Mobility Management and Connection Management state machines
discuss the concept of the EPS Bearer Context
describe the EPS network selection and Attach processes
outline the set of activities required to establish a default EPS bearer and discuss the reasoning behind the decision to make this a stage in the attach process
describe the activities related to IMS registration
discuss the roles played by various devices involved in EPS device selection
outline the set of functions a UE will perform when in idle mode
describe the functions performed by the EPC in support of UEs in Idle Mode
outline the set of activities related to the Tracking Area Update (TAU) process
discuss the activities performed to allow UEs to be paged
outline the functions related to ISR (Idle-mode Signalling Reduction)
describe the actions performed by the MME and HSS in support of UE Reachability
discuss the use of the Service Request process and its relationship to the modify and create bearer functions
list the stages through which the IMS connection establishment process must proceed
outline the processes used to establish CS services for EPS attached subscribers
describe how IMS signalling and media flows are routed and handled
outline the EPC’s support for charging
describe the functions that enable connected mode mobility management to operate
outline the processes employed to support various handover scenarios including intra-EUTRAN and inter-RAT HO
describe the procedures employed to detach a UE from the EPS
LT3600/v1.1
© Wray Castle Limited
v
LTE/SAE Engineering Overview
vi
© Wray Castle Limited
LT3600/v1.1
EPC Operations
UE
eNB
RRC
RRC
MME
ECM
ECM
EMM
EMM State machines store UE and bearer context data
State Management
State Management In order to offer effective service to UEs, the EPS needs to be able to define and keep track of the availability and reachability of each terminal. It achieves this by maintaining two sets of ‘contexts’ for each UE – an EMM (EPS Mobility Management) context and an ECM (EPS Connection Management) context – each of which is handled by ‘state machines’ located in the UE and the MME. A further state machine operates in the UE and serving eNB to track the terminal’s RRC state, which can be either RRC-IDLE (which relates to a UE in idle mode) or RRC-CONNECTED (which relates to a UE with an active traffic bearer).
Further Reading: 3GPP TS 23.401:4.6 LT3600/v1.1
© Wray Castle Limited
7.1
LTE/SAE Engineering Overview
RRC
ECM
EMM
RRC-Idle
ECM-Idle
EMM-Deregistered
UE powered on but idle
RRC-Idle
ECM-Idle
EMM-Registered
UE powered on and active
RRC-Connected
ECM-Connected
EMM-Registered
UE powered off, unreachable or non-EPC attached
Combining EPS States
Combining EPS States Although the EMM and ECM states are independent of each other they are related and any discussion of a UE’s reachability is best served by viewing these states in a combined fashion. There are three main phases of UE activity, each of which can be described by a combination of EMM and ECM states. In the UE Powered Off/Unreachable phase a UE is not contactable via the EPS and cannot use the EPS network’s services. This may be because the UE is powered off, has no signal, or is connected to a non-3GPP access network. This could be described as EMM-DEREGISTERED/ECM-IDLE. It was previously described as LTE_DETACHED. RRC will also be idle. In the UE Powered On but Idle phase a UE is powered on and has attached to the EPS network, but is idle. This could be described as EMM-REGISTERED/ECM-IDLE. It was previously described as LTE_IDLE. RRC will also be idle. In the UE with Active Traffic Connection phase the UE has an established EPS bearer over which traffic is flowing. This could be described as EMM-REGISTERED/ECM-CONNECTED. It was previously described as LTE_ACTIVE. RRC will also be connected.
Further Reading: 3GPP TS 24.801 7.2
© Wray Castle Limited
LT3600/v1.1
EPC Operations
Bearer Context – Active Bearer Attributes
MME
UE
eNB
RRC
S-GW
S1 Tunnel
PDN-GW
S5/S8 Tunnel
Radio Bearer/E-RAB/EPS Bearer Active
Active EPS Bearers and Bearer Contexts
Active EPS Bearers and Bearer Contexts An EPS bearer provides a data path between a UE and an APN located in a PDN-GW. Once created, an EPS bearer can be in one of two states – active or inactive. When active, the EPS bearer is assigned bearer resources that amount to a radio bearer and GTP tunnels, with assigned TEIDs that will carry the E-RAB and EPS Bearer over the Uu, S1-U and S5/S8 interfaces. Each PDN connection and default and dedicated EPS bearer is described by a Bearer Context stored in the UE and MME and in other devices required to serve each bearer. Default and dedicated bearer contexts describe the UE’s current ECM state (idle or connected) plus the bearer’s EPS bearer ID and QoS parameters, and can be either active or inactive.
Further Reading: 3GPP TS 23.401:4.7.2 LT3600/v1.1
© Wray Castle Limited
7.3
LTE/SAE Engineering Overview
Bearer Context – Inactive Bearer Attributes
MME
UE
eNB
S-GW
PDN-GW
S5/S8 Tunnel
Radio Bearer/ E-RAB Released
S5/S8 EPS Bearer Active
Inactive EPS Bearers and Bearer Contexts
Inactive EPS Bearers and Bearer Contexts When an EPS Bearer is inactive, either as a result of an instruction from the UE or MME or of an inactivity timer expiring, Uu and S1-U resources are released, although the S5/S8 tunnel is retained and details of the bearer context are retained by the UE and the MME for future reactivation when required. The separation of the bearer resources from the bearer context means that details of each bearer can be retained by the network even when the physical resources associated with it have been released during periods of inactivity. An inactive bearer context can be reactivated by either the UE or the network using the Service Request procedure. The S-GW may invoke the Downlink Data Notification procedure if data arrives for an inactive bearer. The Bearer Context data held in the UE and the MME may become unsynchronized during periods of inactivity, both devices will attempt to re-synchronize this data when a signalling connection is re-established.
Further Reading: 3GPP TS 23.401:4.7.2 7.4
© Wray Castle Limited
LT3600/v1.1
EPC Operations
Stored Information: Last used ECGI and EARFCN
Initial Cell selection: Scan frequency bands, compile list of strongest allowed cells
Attach and Registration Requirements
Attach and Registration Requirements As with legacy 3GPP systems, a UE can only access network services after it has performed an Attach and can only access IMS services once it has Registered. An Attach is usually required when a UE is powered on or after it returns from a period outside of network coverage. Prior to the attach being initiated, the UE must perform either ‘stored information’ or ‘initial’ cell selection functions to allow it to determine the best available cell resource via which to connect. The EPS specifications include the ‘stored information cell selection’ process that allows details of the ‘last used’ cell to be retained in the USIM so that the UE can attempt to reconnect quickly to that resource on power on. Stored last cell details include the ECGI (E-UTRAN Cell Global Identity), and EARFCN (E-UTRAN Absolute Radio Frequency Channel Number). If there are no stored cell details, or if the stored cell is unavailable, the UE must scan for available cells and perform an ‘initial cell selection’. Again, data stored on the USIM can aid this process allowing the UE to be instructed to search for preferred EARFCNs, preferred networks and preferred radio access technologies. Cell selection is based on similar criteria to those employed in legacy systems – after searching at least a minimum number of carriers the UE will have compiled a list of ‘acceptable’ cells from which it will select a ‘suitable’ cell, which is the one it regards as offering the best service, and will attempt to attach. Before attempting to attach the UE must check to ensure that the selected cell is not barred and that it meets the USIM access priority level indicated on the cell’s BCCH.
Further Reading: 3GPP TS 23.011; 36.300:10 LT3600/v1.1
© Wray Castle Limited
7.5
LTE/SAE Engineering Overview
UE
eNB
MME
S-GW
PDN-GW
EIR
HSS
1. Attach Request 2. Attach Request 3. AKA/Security
4. Identity Request/Response
4. ME Identity Check
4. Ciphered Options Request 4. Ciphered Options Response 5. Update Location 5. Insert Subscriber Data 5. Insert Subscriber Data Ack 5. Update Location Ack
Optional Stage
EPS Initial Attach
EPS Initial Attach The UE’s objective when performing an attach is to register the subscriber’s identity and location with the network to enable services to be accessed. During the attach procedure the UE will be assigned a default EPS bearer to enable always-on connectivity with a PDN. The UE may be provided with details of a local P-CSCF to enable it to register with the IMS. A simplified view of the attach process – assuming that it is an initial attach with stored details from a recent previous context for a UE using its H-PLMN (Home PLMN) and accessing via the Home E-UTRAN – is shown, and the stages of the process are described below. Once a suitable cell has been selected the UE employs the Random Access procedure to request an RRC connection with the chosen eNB. With that in place an Attach Request message (1) can be transmitted. If the UE has previously been registered with the PLMN, it may include a previously assigned GUTI in the message, otherwise the Attach Request message contains the subscriber’s IMSI and some other parameters. On receipt of the Attach Request the eNB either derives the identity of the previously used MME from the supplied GUTI or selects an MME from the pool available and forwards the message (2). The MME contacts the HSS indicated by the subscriber’s IMSI and in response receives the relevant elements of the ‘quintuplet’ that allows the EPS-AKA process to take place (3). Optionally, at this point the MME may be required to check the identity and status of the UE via the EIR (4) using the ME Identity Check process. Ciphering may then be invoked over the air interface. Once the AKA procedures have successfully concluded the MME transmits an Update Location message to the HSS and receives the Insert Subscriber Data message in response containing the user’s service profile (5). An Insert Subscriber Data Ack from the MME is followed by an Update Location Ack from the HSS. The UE is now Attached to the EPC.
Further Reading: 3GPP TS 23.401:5.3.2 7.6
© Wray Castle Limited
LT3600/v1.1
EPC Operations
UE
eNB
MME
S-GW PDN-GW
PCRF
HSS
6. Create Default Bearer Request
8. Create Default Bearer Response
7. PCC Lookup
9. Initial Context Setup Request/ Attach Accept 10. RRC Conn Reconfig 11. RRC Conn Reconfig Complete
12. Initial Context Setup Response
13. Direct Transfer
14. Attach Complete Data flow
Optional Stage
Default Bearer Establishment
Default Bearer Establishment A default bearer must then be established and the MME selects the S-GW that will handle and a PDN-GW that supports the requested APN. The MME issues a Create Default Bearer Request to the selected S-GW, which assigns a GTP TEID to the EPS bearer and passes the request to the indicated PDN-GW (6). If the network employs dynamic PCC the PDN-GW will query the PCRF assigned to serve the UE for bearer parameters, otherwise the bearer will be established using local QoS parameters stored in the PDN-GW (7). If the network employs dynamic PCC the PDN-GW will query a PRCF for bearer parameters, otherwise the bearer will be established using local QoS parameters stored in the PDN-GW (7). A Create Default Bearer Response message passes from the PDN-GW to the S-GW, which contains relevant parameters such as the EPS bearer’s IP address and possibly the IP address or DNS name of a local IMS P-CSCF. The S-GW creates the bearer as specified and passes the Create Default Bearer Response message to the MME (8). The details that define the S1-U service will also have been defined during this stage. The MME sends an Initial Context Setup Request/Attach Accept message, which contains the assigned parameters for the EPS bearer context, to the eNB (9). That element in turn sends an RRC Connection Reconfiguration message to the UE (10) to inform it of the bearer details and the changed air interface parameters. The UE returns an RRC Connection Reconfiguration Complete message (11) to verify that the radio bearer, which was initially established just to carry the attach message, has been reconfigured to support the new parameters. The eNB forwards an Attach Complete message to the MME (12). The UE then sends a Direct Transfer message to the eNB (13), which confirms the details of the EPS Bearer. Finally, the eNB sends an Attach Complete message to the MME to confirm that both the Attach and the Default EPS Bearer processes have completed successfully. Uplink and downlink data can now flow if required. Further Reading: 3GPP TS 23.401:5.3.2 LT3600/v1.1
© Wray Castle Limited
7.7
LTE/SAE Engineering Overview
UE Idle Mode Functions: No active Bearer Contexts Neighbour Cell List only necessarily contains neighbour frequencies, cell details are optional Neighbour measurements required only if serving cell falls below threshold Tracking Area Update (TAU) performed if required
UE Idle Mode Functions
UE Idle Mode Functions A UE in idle mode needs to perform a set of functions that enable it to stay camped onto the best of the available local cells. It achieves this by performing the cell reselection process, which although similar to that employed by legacy 3GPP systems such as GSM and UMTS, is slightly different in the E-UTRAN. Detailed NCLs (Neighbour Cell Lists) are optional in the E-UTRAN, on a cell-by-cell basis, and in most cells the NCL requirement is limited to advertising the set of ‘non-intra frequency’ channels employed by EUTRAN and ‘inter-RAT’ neighbours. A full N-Cell list is only deployed in cells with specific requirements or complex reselection options. This change means that the UEs can be responsible for discovering neighbour cells and that they are not required to measure those neighbours continuously. A UE only needs to undertake neighbour cell measurements if the current serving cell’s signal drops below a broadcast minimum threshold. If the signal strength is above the threshold the UE will only measure the serving cell. The E-UTRAN is able to control the how Idle mode terminals behave by issuing each UE an RFSP Index (Index to RAT/Frequency Selection Priority). The RFSP Index specifies the priority the UE should assign to the available local radio channels belonging the any of the allowed radio access technologies and allows the network to control which cells are viewed as re-selection candidates by the UE (and which are not). Use of the RFSP standardizes some of the informal techniques that have previously been used to influence UE reselection activities, such as adjusting C2 values to make a cell unattractive to UEs. The RFSP Index is UE-specific and is provided to a serving MME in HSS data. If a reselection is deemed necessary the UE will obtain the new cell’s TAI after the change has been achieved. If the new cell’s TAI is different to those broadcast by the old cell, the UE will perform a TAU.
Further Reading: 3GPP TS 36.304; 23.401:4.3.6 (RFSP) 7.8
© Wray Castle Limited
LT3600/v1.1
EPC Operations
UE Default Bearer Context – Inactive
UE TA List
ECM State EPS Bearer ID QoS
TA 9 TA 12
MME Pool A
TA 9 TA 12
EPC Support for Idle Mode
EPC Support for Idle Mode The MME currently serving each UE is responsible for ensuring its ‘reachability’. It achieves this by monitoring the current TA in which the terminal is located. The EPS allows a cell to be a member of more than one TA. This allows a UE to roam within a set of contiguous TAs without being required to perform a TAU, which reduces the amount of locationrelated signalling that is required, although it may conversely increase the amount of paging required per UE connection request. The MME reflects this extended mobility by maintaining a TA list for each registered UE within which the list shows the set of TAs the UE is currently registered. During a TAU, and periodically in the event that a TAU does not occur within a set time-frame, the MME is responsible for reauthenticating each registered UE and for reissuing the M-TMSI used to confidentially identify it. When a UE drops into the ECM-IDLE state its existing default bearer can be ‘parked’ and any dedicated bearers can either be parked or released. To support this, the MME stores details of the UE’s current ‘bearer contexts’ ready to reactivate them in the event of a UE or network-triggered Service Request. A TAU may result in the need to change the S-GW assigned to handle an idle UE’s bearer contexts or of the MME with which the UE is registered, if the reselected cell is associated with a different S-GW Service Area or MME Pool. If ISR (Idle-mode Signalling Reduction) is active for a UE, the MME may be required to pass location updates and other pertinent information to the SGSN with which the UE is co-registered.
Further Reading: 3GPP TS 23.401:4.3.5 LT3600/v1.1
© Wray Castle Limited
7.9
LTE/SAE Engineering Overview
UE
eNB
MME
HSS
TAU trigger event 1. TAU Request 2. TAU Request + TAI and ECGI 3. Authentication/Security
4. TAU Accept 5. TAU Complete
Optional Stage
TAU (Tracking Area Update)
TAU (Tracking Area Update) A TAU takes place between a UE and the MME with which it is registered and is triggered by the UE detecting a change in TAI after a cell reselection. A TAU is also be used as part of the Initial Attach process and may additionally be triggered by events such as the expiry of the periodic TAU timer or as part of MME load balancing or rebalancing. In the example message flow it is assumed that the UE is connected to its HPLMN and that an S-GW change and MME relocation are not required. After detecting a change in TAI, the UE transmits a TAU Request message to the eNB (1). The TAU Request contains data such as the old GUTI, old TAI, EPS bearer status and a NAS MAC (Message Authentication Code) for integrity protection purposes. The eNB forwards the TAU Request (plus the new TAI and ECGI) to the MME indicated by the supplied GUTI (2). If the MME indicated by the GUTI is not associated with the new eNB, an MME relocation will be triggered and the base station will select a new MME to pass the TAU Request to. If the integrity check of the MAC carried in the TAU Request is successful, the MME may elect not to reauthenticate the UE. If the MME is configured to always reauthenticate, or if the integrity check fails, then the EPS-AKA process must be followed and a new GUTI (which includes the new M-TMSI) will be issued (3). Once the MME is satisfied that the UE/USIM is authentic and assuming that the UE is allowed to roam in the new TA, it transmits a TAU Accept message to the eNB, which relays it to the UE (4). The TAU Accept message contains the new GUTI, if one was assigned, plus the current TA List associated with the UE. The TA List enables the UE to determine the set of TAs within which it can roam without being required to perform another TAU. The UE responds with a TAU Complete message (5), which finishes the process.
Further Reading: 3GPP TS 23.401:5.3.3 7.10
© Wray Castle Limited
LT3600/v1.1
EPC Operations
GERAN/UTRAN
SGSN
UE and Bearer Contexts stored
RA
UE can reselect to any registered RAT without sending an update
UE paged across all registered areas
S3 S-GW
PDN-GW
UE and Bearer Contexts stored
TA MME
E-UTRAN
Idle-mode Signalling Reduction
Idle-mode Signalling Reduction ISR is designed, as the name suggests, to reduce the amount of UE-network and MME-SGSN signalling required to manage idle mode terminals. ISR is a feature of the S3 and S16 interfaces and is not available to legacy SGSNs that do not support them. When an Idle UE activates (or is instructed to activate) ISR, copies of UE Context and Bearer Contexts are stored in both an MME (for E-UTRAN access) and SGSN (for GERAN/UTRAN access). The UE is able to reselect freely between registered RATs without transmitting location updates, unless a change in RAI or TAI is detected. Any location updates that are sent need only be transmitted via the RAT currently in use; the receiving core network element will forward the update to its peer over the S3 interface. The MME and SGSN both stores copies of the UE’s bearer contexts and will both page for the UE. When the UE needs to move to connected mode, whether in response to a page or to a user-initiated event, it can do so by sending a Service Request via whichever RAT it is currently camped on. The receiving device will then instruct the S-GW to re-establish the parked bearers. A UE with ISR activated maintains details of the RAT and therefore the RAT-specific temporary identifier that is in use using the TIN (Temporary Identity used in Next update) parameter. The TIN can be set to P-TMSI (for GERAN/UTRAN access), GUTI (for E-UTRAN access) or RATrelated TMSI. This last option means that the UE will use the P-TMSI or GUTI depending upon which RAT is currently in use. A UE will deactivate ISR if it looses contact with one of the registered access networks. For example, a UE might be within the coverage of both an E-UTRAN and a GERAN cell when ISR is activated but may roam out of coverage of the E-UTRAN cell; in such circumstances it would revert to being attached to just an SGSN.
Further Reading: 3GPP TS 23.401:Annex J LT3600/v1.1
© Wray Castle Limited
7.11
LTE/SAE Engineering Overview UE TA List TA 9 TA 12
S1 Paging messages
TA 9 TA 12
Paging
Paging The main purpose of the TAU process is to ensure that the MME knows roughly where each UE is in the event that there is inbound traffic to deliver. Paging will usually be triggered by the receipt of an S-GW Downlink Data Notification at the MME, indicating that data has arrived at the S-GW on the S5/S8 portion of a parked EPS Bearer. If it becomes necessary to contact an idle UE (that is, a UE that has entered the ECM-IDLE state), the MME will employ the paging process. With no equivalent node to the RNC, EPS paging is managed directly between the MME and eNBs. When a Paging message is to be sent, the MME checks the current TA list stored for the target UE and inserts the paging data into the S1 paging messages sent to all eNBs in the indicated TAs. Each eNB inserts the UE’s NAS paging ID (IMSI or S-TMSI can be used) into the appropriate repetitions of its PCH (Paging Channel). Paging groups may be established to reduce the number of repetitions of the PCH that each UE is required to monitor; the operation of the paging reduction scheme is controlled via cell-specific DRX (Discontinuous Reception) functions. When a UE receives its paging ID on the PCH it initiates the service request process, which ensures that any ‘parked’ EPS bearers are reactivated ready to carry traffic. If a UE has ISR activated the paging notification will be forwarded to the peer core network node; either MME or SGSN.
Further Reading: 3GPP TS 23.401:5.3.4; 36.300 7.12
© Wray Castle Limited
LT3600/v1.1
EPC Operations
Re-registration causes: Change of IP Address Change of PDN-GW Expiry of Registration Timer S-CSCF
UE
EPS
IMS Functions in Idle Mode
IMS Functions in Idle Mode There is no specific equivalent of idle mode in the IMS – a UE is either registered or deregistered. The main function that an idle mode UE performs in relation to the IMS is to perform periodic re-registration. The periodicity of the re-registration is determined by the registration expiry value included in the initial Registration message and the process ensures that the S-CSCF is kept informed of the reachability of each registered UE. Re-registration is also required if the UE’s IP address changes – either as a result of a change of PDN-GW or as part of a network’s DHCP IP address allocation processes (which may seek to reduce the possibilities of fraud or connection hijack by periodically refreshing the IP addresses assigned to terminals). An additional trigger for re-registration would be if the UE or IMS capabilities changed, for example if the client supporting a new IMS application was loaded to the terminal.
Further Reading: 3GPP TS 23.228:5.2 LT3600/v1.1
© Wray Castle Limited
7.13
LTE/SAE Engineering Overview
Modify/Create Dedicated Bearer
Service Request
To carry new SDFs
Reactivate 'parked' EPS Bearers
Inactive Default EPS Bearer
IMS
UE
eNB
S-GW
PDN-GW
Inactive Dedicated EPS Bearer
Internet
Levels of Connectivity
Levels of Connectivity User connectivity in a combined EPS/IMS network requires two levels of connection to be established: firstly, the radio and EPS bearers that will carry traffic through the E-UTRAN and EPC, and secondly the IMS SIP and media connections that will carry call-related signalling and end-to-end user traffic. A UE’s default bearer may be an operator’s first choice for carrying application traffic, but if the QoS demanded by a new service data flow is incompatible with that of the default bearer, then the PDNGW/PCRF may decide that an additional dedicated bearer is established. When a UE enters idle mode the physical S1 and radio resources assigned to the default EPS bearer will be released and the bearer context details will be stored. Any existing dedicated bearers may be released or stored also. When the UE moves from ECM-IDLE to ECM-CONNECTED the stored bearer contexts will be reactivated using the Service Request procedure.
Further Reading: 3GPP TS 23.401:5.3.4 7.14
© Wray Castle Limited
LT3600/v1.1
EPC Operations
UE
eNB
MME
S-GW
PDN-GW
PCRF
HSS
Trigger Event 1. NAS: Service Request
2. NAS: Service Request
3. Authentication/Security
4. S1AP: Initial Context Setup Request 5. Radio Bearer Establishment 6. Uplink Data Flow 7. S1AP: Initial Context Setup Complete 8. Update Bearer Request 9. Update Bearer Request/Response 10. Update Bearer Response 11. Downlink Data Flow
Optional Stage
UE-triggered Service Request
UE-Triggered Service Request A UE will trigger a Service Request to reactivate its parked bearer contexts in response to a command from an application client, the terminal management software or the user interface. A response to a network initiated paging message will also trigger a Service Request. The process begins with the transmission of a NAS: Service Request either following the random access procedure or carried in scheduled uplink capacity. The NAS: Service Request contains the UE’s current S-TMSI and the service type (data or paging response). The request is initially forwarded to the eNB encapsulated in an RRC message (1). Direct Transfer NAS messages were transparent to the UMTS Node B and were only accessible to the RNC. In the E-UTRAN, NAS messages are switched from the RRC bearer used on the air interface to an S1AP bearer for forwarding to the MME (2) and in some cases are interpreted by the eNB. Depending upon configuration, the MME may initiate a reauthentication of the UE/USIM before processing the Service Request (3). The MME sends the eNB an S1AP: Initial Context Setup Request, which issues the commands that re-establish physical resources for the stored bearer contexts on the S1 interface between the UE and the S-GW (4). The eNB allocates radio resources (5) on the air interface and informs the UE. Uplink traffic is then able to flow (6). The eNB confirms these actions with an S1AP: Initial Context Setup Complete message (7). The MME instructs the S-GW to establish its end of the S1-U tunnels using the Update Bearer Request message (8). If the PDN-GW has requested updates regarding the UE’s location, the S-GW will pass this on in an Update Bearer Request (9). After the PDN-GW and S-GW return Update Bearer Responses, data can begin to flow on the downlink (9, 10 and 11)
Further Reading: 3GPP TS 23.401:5.3.4 LT3600/v1.1
© Wray Castle Limited
7.15
LTE/SAE Engineering Overview
UE
eNB
MME
S-GW
PDN-GW
PCRF
HSS
Trigger Event 1. Request Bearer Resource Modification
2. Request Bearer Resource Modification 3. PCC Lookup
4. Existing TFT modified, new TFT or Bearer activated or existing TFT or Bearer deactivated
Optional Stage
Handling Additional Traffic Flows
Handling Additional Traffic Flows If a UE determines that there is a requirement to establish a traffic flow aggregate (which may contain one or more SDFs) to a new AF (Application Function) destination – in response to a user interface request, for example – it will transmit a Request Bearer Resource Modification to the MME. If the UE had been in Idle Mode when it made this determination it will first send a Service Request to reactivate the existing bearers. The MME forwards the request to the S-GW currently dealing with the UE’s EPS Bearer(s), which in turn forwards it to the appropriate PDN-GW. If dynamic PCC (Policy and Charging Control) is in use, the PDN-GW interacts with the PCRF to determine how best to deal with the request: if static PCC is in use then the PDN-GW makes the determination itself. The Modification request includes the required QoS, the EPS Bearer ID and a TAD (Traffic Aggregate Descriptor), which describes the modification function to be performed (add, modify or delete) and the SDF 5-tuple details that enable the PCRF to build a packet filter for the flow. The PCC function will evaluate the request and either accept or reject it. Accepted requests result in new or updated packet filters. In the case of a new traffic flow that is to be added to an existing bearer, the PCC function will add an additional packet filter to the TFT (Traffic Flow Template) related to the bearer over which the flow will travel. If the addition of the new flow alters the bearers QoS requirements the adjustment will be communicated to other elements using the Update Bearer Request process. In addition to UE-initiated Bearer Modification the EPC also supports PDN-GW-initiated Bearer Modification; HSS-initiated Bearer QoS Modification and MME and PDN-GW initiated Bearer Deactivation.
Further Reading: 3GPP TS 23.401:5.4 7.16
© Wray Castle Limited
LT3600/v1.1
EPC Operations
UE
eNB
MME
S-GW
PDN-GW
PCRF
HSS
1. Trigger Event 2. Request Bearer Resource Modification
3. Request Bearer Resource Modification 4. PCC Lookup 5. Create Dedicated Bearer Request
7. RRC Conn Reconfig 7. RRC Conn Reconfig Complete
6. Bearer Setup Request/ Session Management Request
8. Bearer Setup Response
9. Direct Transfer 10. Session Management Response
11. Create Dedicated Bearer Response
Data Flow
12. IP-CAN Session Modified
Optional Stage
Dedicated Bearer Creation
Dedicated Bearer Creation If PCC decides that a new traffic flow is incompatible with any of the UE’s existing bearers it may decide that a new Dedicated Bearer is required, in which case it will instruct the PDN-GW to issue a Create Dedicated Bearer Request. The stages of this process are outlined in the diagram.
Further Reading: 3GPP TS 23.401:5.4.1 LT3600/v1.1
© Wray Castle Limited
7.17
LTE/SAE Engineering Overview Home Home PDN-GW P-CSCF
UE
Home S-CSCF
Destination IMS/UE
Trigger event 1. Invite
2. Invite
3. Invite 4. Session Progress
Edit 4. Session Progress
Edit 4. Session Progress 5. Provisional Acknowledgement
5. PRACK
5. PRACK
Resource Allocation
Optional Stage
6. 200 OK
6. 200 OK
6. 200 OK
IMS Connection Establishment
IMS Connection Establishment IMS connection establishment is the responsibility of SIP. The EPS default bearer is established to a home network PDN-GW and maintained mainly to provide a path for SIP messaging between a UE and its serving I-CSCF (Interrogating Call State Control Function). Consider an example SIP flow between a roaming UE and its home S-CSCF (Serving Call State Control Function) during which a media session to a distant IMS-connected UE is initiated. Not all network elements involved in the process have been shown. In response to an instruction received via the user interface, the originating UE initiates the session by transmitting a Service Request to reactivate its bearers followed by a SIP Invite message to the current I-CSCF (1). The Invite message contains an SDP payload, which describes the type of connection the originating UE wishes to establish with the destination UE. The I-CSCF passes the message on to the assigned S-CSCF for authorization (2). The S-CSCF discovers the called party’s home network and passes the Invite to an I-CSCF in that network for forwarding to the S-CSCF and the destination UE (3). Once discovered, the destination UE inspects the SDP (Session Description Protocol) payload and determines if it can support the type of service and QoS parameters specified. A Session Progress message is returned to the originating UE containing the IP address of the distant terminal and a response to the SDP parameters (4). Each CSCF in the return path is able to approve or edit the SDP response so that the eventual media session’s parameters match the capabilities of the busiest link in the chain. The originating UE returns a PRACK (Provisional Acknowledgement), which confirms the parameters of the media session (5). This triggers the reservation of resources for the distant UE, which it confirms with a 200 OK message (6).
Further Reading: 3GPP TS 23.228:5.4 7.18
© Wray Castle Limited
LT3600/v1.1
EPC Operations
PDN-GW Per SDF Rating determined by PCC
Web Server
Email Server Service Data Flows EPS Bearer
Voice Call
S-GW Per EPS Bearer Up and down byte count plus QCI and ARP
Charging Capture Points
Charging Capture Points Like its legacy-network counterparts, an EPS will in most cases be operated on a commercial basis. There is therefore a need to capture and process all billable events that take place while a UE is attached. Charging data is captured at a number of points in the combined EPS and IMS environment: The S-GW collates charging data on a ‘per UE per PDN’ basis and logs the amount of data carried on both the uplink and downlink parts of each bearer. It also logs the QCI and ARP parameters in force in each direction on each set of EPS Bearers attached to the same PDN. The PDN-GW is able to use more sophisticated differentiation when gathering charging data. Whereas the S-GW can only gather data on a ‘per bearer’ basis, the PDN-GW can employ deep packet inspection techniques to gather data on a ‘per service flow’ basis. This means that the PDN-GW can differentiate between a voice call, a streaming video connection and web browsing session all travelling over the same EPS bearer at the same time and can charge for each flow separately. If the network employs a PCRF, the PDN-GW will request PCC data dynamically for each SDF as it is established and will rate charging data accordingly. In networks with no PRCF the PDN-GW will use locally configured, static charging parameters.
Further Reading: 3GPP TS 23.401:5.7A; 23.203 LT3600/v1.1
© Wray Castle Limited
7.19
LTE/SAE Engineering Overview
Intra-E-UTRAN
Inter-S-GW
Inter-RAT
Inter-MME
Non-3GPP
Connected Mode Procedures
Connected Mode Procedures Mobility management functions related to UEs in the ECM-CONNECTED state with active EPS Bearers and service data flows can be summarized as follows:
intra-E-UTRAN handover
intra-E-UTRAN handover with S-GW relocation
intra-E-UTRAN handover with MME relocation
Inter-RAT handover
E-UTRAN-Non-3GPP Access Handover
Further Reading: 3GPP TS 23.401:5.5 7.20
© Wray Castle Limited
LT3600/v1.1
EPC Operations
UE
Source eNB
Target eNB
MME
S-GW
PDN-GW
1. Uplink and downlink data flow 2. Handover Preparation 2. Handover Execution including new S1 tunnel creation 3. X2 Direct Forwarding 3. Uplink Data 4. Path Switch Request
5. User Plane Update Request
7. User Plane Update Response 8. Downlink Data
6. UE location information updated
9a. End Markers 9b. End Markers forwarded, X2 data forwarding ends
10. Path Switch Request Ack 11. Release Resources
Optional Stage
Intra-E-UTRAN Handover (X2 based)
Intra-E-UTRAN Handover (X2-based) In this scenario a UE with active EPS bearers initiates the inter-eNB cell handover procedure when both source and target eNBs are associated with the serving MME and S-GW and an X2 path can be established between them. At the start of the process the UE is connected to the E-UTRAN and is taking neighbour cell measurements (1). Traffic may or may not be flowing over the connected EPS Bearers. A neighbour cell achieves the criteria necessary for the UE to initiate handover, which is effected by the source and target eNBs without core network involvement beyond the establishment of S1 resources towards the target eNB (2). Once the handover is complete the source eNB forwards any further downlink traffic received for the UE to the target eNB either directly via the X2 interface (3); this is termed Direct Forwarding. Uplink traffic travels from the target eNB to the S-GW via the newly established tunnel. The target eNB sends a Path Switch Request to the MME informing it of the handover (4). The MME determines that the existing S-GW is still capable of serving the UE and instructs it to switch the Downlink user plane over to the tunnel created towards the new cell using a User Plane Update Request message (5). If the PDN-GW has indicated that needs to be kept informed of the UE’s location (for variable charging purposes), the S-GW informs it using an Update Bearer Request (6). The S-GW realigns the tunnel carrying the EPS bearer(s) to point to the target eNB and sends confirmation to the MME that the path has been switched successfully (7); both uplink and downlink traffic now travels over the new S1 tunnels (8). The S-GW sends ‘end marker’ packets to the source eNB to confirm that the path has been switched, which are forwarded to the target eNB to indicate that X2 forwarding will cease (9). The MME confirms the procedure to the new eNB with the Path Switch Request Ack message (10) and it in turn confirms the handover to the old eNB using the Release Resource message (11). Further Reading: 3GPP TS 23.401:5.5.1 LT3600/v1.1
© Wray Castle Limited
7.21
LTE/SAE Engineering Overview
UE
Source eNB
Target eNB
MME
Source S-GW
Target S-GW
PDN-GW
1. Uplink & Downlink Data flow 2. Handover Preparation 3. Handover Execution including new S1 tunnel creation 4. X2 Downlink data forwarding 4. Uplink Data 5. Path Switch Request
5. Create Bearer Request
6/7. Update Bearer Request/Response
8. Create Bearer Response 4. Downlink Data 9. Path Switch Request Ack 10. Uplink Data 11. Release Resources 12. Delete Bearer Request/Response
Optional Stage
S-GW Relocation (X2 based)
S-GW Relocation (X2-based) If a UE is handed over between eNBs that are associated with different S-GW service areas, the data path will need to be switched to a new S-GW as well as a new eNB. The procedure outlined below assumes that an X2 path can be established between source and target eNBs. The initial phases of this process are the same as those followed for the inter-eNB handover (1 to 4). Note that an X2 tunnel carries downlink data from the source eNB to the target cell and that uplink data travels to the source S-GW directly from the target eNB. If the MME determines that the current S-GW cannot continue to serve the UE (generally because the UE has moved into a TA that is not associated with the current S-GW) it selects a target SGW and issues a Create Bearer Request to it (5). The S-GW forwards the request to the current PDN-GW in an Update Bearer Request message (6). The PDN-GW realigns the tunnel carrying the EPS bearer towards the target S-GW and confirms the change by returning an Update Bearer Response (7). The target S-GW starts forwarding Downlink traffic to the target eNB and sends a Create Bearer Response to the MME to confirm that the path switch was successful (8). The MME sends a Path Switch Request Ack to the target eNB (9) to inform it to switch the path of the Uplink traffic stream towards the target S-GW. Downlink and uplink data are now active for the UE in the new cell and the target S-GW (10). The new eNB sends a Release Resource message to the old eNB (11) and the eNB and old S-GW delete the old S1 data path (12). The procedure for S1-based S-GW relocation is the same as that outlined above with the additional steps required to establish an Indirect Forwarding tunnel between eNBs via the two S-GWs; this would travel between the source eNB and S-GW over the S1 interface, between S-GWs using an unnamed forwarding connection and finally to the target eNB via its S1 interface.
Further Reading: 3GPP TS 23.401:5.5 7.22
© Wray Castle Limited
LT3600/v1.1
EPC Operations
UE
Source eNB
Target eNB
MME
MME Source S-GW
Target S-GW
PDN-GW
1. Uplink and Downlink Data flow 2. Handover Preparation 2. Handover Required 3. Forward Relocation Request 4. Create Bearer Request/Response 5. Handover Request 6. Handover Request Ack 7. Create Bearer Request/ Response for indirect forwarding between S-GWs 8. Forward Relocation Response
X2-based Actions
9. Create Bearer Request/ Response for indirect forwarding between S-GWs
S1-based Actions
Optional Stage
10. Handover Command
MME Relocation
MME Relocation In situations where the change of cell also dictates a change of MME (or MME and S-GW), the handover procedure becomes more complicated in that the source eNB must initiate the handover process with the MME before the UE can be instructed to release its radio resources and move to the target cell. When the UE indicates that a handover is required (1) and the source eNB determines that it will involve a change of MME (as the target cell indicated by the UE is associated with a different MME pool), the source eNB issues a Handover Required message to the source MME (2). The source MME selects a target MME and issues the Forward Relocation Request message (3), which includes the UE context data held by the source node. As with all EPS handover types, the source eNB passes its UE and Bearer context details to the target eNB (or target BSC/RNC in the case of inter-RAT handover) in a ‘transparent container’, which will be carried in signalling between the eNBs and MMEs. The target MME selects a target S-GW and issues a Create Bearer Request that includes details of the bearer contexts to be established (4). The target S-GW responds to the target MME, which in turn issues a Handover Request to the target eNB (5). The target eNB allocates radio resources for the UE and responds to the MME with a Handover Request Acknowledge (6). If no X2 interface exists between source and target eNBs, the target MME instructs the target S-GW to create and ‘indirect forwarding’ bearer to carry user traffic between it and the source S-GW (7). The forwarding interface between S-GWs is unnamed. Once the preparation is complete, the target MME sends a Forward Relocation Response to the source MME (8), which instructs the source S-GW to create its end of the forwarding bearer (9). The MME also issues a Handover Command to the source eNB (10). Further Reading: 3GPP TS 23.401:5.5.1 LT3600/v1.1
© Wray Castle Limited
7.23
LTE/SAE Engineering Overview
UE UE
10. Handover Command
Source eNB
Target eNB
MME
MME Source S-GW
Target S-GW
PDN-GW
11. eNB Status Transfer 11. eNB Status Transfer
11. Forward SRNS Context/Ack 12a. S1-based Indirect Forwarding Downlink Data
12b. X2-based Direct Forwarding Downlink Data
13. Release and resynchronize 13. Handover Confirm 14. Downlink Data X2-based Actions
14. Uplink Data
S1-based Actions
15. Handover Notify Optional Stage
MME Relocation (continued)
MME Relocation (continued) Up until this point the UE has continued to transmit and receive data via the source cell. When it receives the forwarded Handover Command from the source eNB it releases its assigned radio resources and resynchronizes with the target cell (10 and 13). While this is proceeding, the source eNB transmits an eNB Status Transfer to the target eNB (which will be forwarded between source and target MMEs as Forward SRNS Context and Ack messages). This carries details of the state of all E-RABs associated with the UE at the point the handover commenced and allows PDCP Preservation to occur, which maintains air interface delivery sequencing (11). As a path switch has not yet been performed, downlink traffic destined for the UE is still being forwarded to the source eNB. This traffic is forwarded either indirectly (12a) or directly(12b) to the target cell and is buffered there until the UE confirms that is has re-established its connection by sending the target eNB a Handover Confirm message (13). The target eNB releases buffered downlink traffic and allows uplink traffic to flow via the newly established S1 tunnel to the target S-GW (14). The eNB also sends a Handover Notify to the target MME to confirm that the handover was successful (15).
Further Reading: 3GPP TS 23.401:5.5.1 7.24
© Wray Castle Limited
LT3600/v1.1
EPC Operations
UE
Source eNB
Target eNB
Source MME
Target MME
Source S-GW
Target S-GW
PDN-GW
15. Handover Notify 16. Forward Relocation Complete/Ack 17. Update Bearer Request/Response
18. Update Bearer Request/Response
19. Downlink & Uplink Data 20. Tracking Area Update
22. UE Context Release Command/Complete
21. Delete Bearer Request/Response
X2-based Actions
23. Delete Bearer Request/ Response (for S1 Indirect Forwarding tunnels)
S1-based Actions
Optional Stage
MME Relocation (continued)
MME Relocation (continued) The target MME informs the source MME that the relocation has succeeded via the Forward Relocation Complete message, which is acknowledged by the source MME (16). The target instructs the target S-GW to switch the downlink data path towards the target eNB (17), which in turn informs the serving PDN-GW of the change via an Update Bearer Request (18), in response to which the PDN-GW realigns the tunnel carrying the EPS bearer towards the target S-GW. Uplink and downlink user traffic is now flowing through the new network nodes (19) and the UE uses the new connections to send a TAU to the target MME (20), which may optionally instruct the UE to reauthenticate. The source MME started a timer when the relocation commenced and at the expiry of the timer it will instruct the source S-GW and source eNB to release any resources held for the UE and to delete any contexts (21 and 22). If Indirect Forwarding between S-GWs was employed, te source and target MMEs instruct the S-GWs to delete the forwarding tunnel (23). The MME relocation is now complete.
Further Reading: 3GPP TS 23.401:5.5.1 LT3600/v1.1
© Wray Castle Limited
7.25
LTE/SAE Engineering Overview
3GPP GERAN
3GPP UTRAN
EPS
3GPP2 CDMA2000
IEEE 802.11 WLAN (Wi-Fi)
SRVCC GANC
CS Domain
IEEE 802.16 WiMAX
Inter-RAT Handover
Inter-RAT Handover EPS support for backwards compatibility ensures that packet data connections can be handed over between the E-UTRAN and a variety of other RAT types. These include legacy 3GPP access RATs such as 2G GPRS, 3G UMTS/HSPA and non-3GPP RATs such as IEEE 802.11 Wi-Fi and 802.16 WiMAX along with 3GPP2 CDMA2000. All of the above handover types relate to the relocation of PS bearers only – there is no direct handover possible between the EPS and legacy CS domains without employing additional techniques, such as SRVCC for networks that use an IMS and, possibly, a GAN-based handover for networks that do not.
Further Reading: 3GPP TS 23.401:5.5.2 7.26
© Wray Castle Limited
LT3600/v1.1
EPC Operations
UE
Source Target eNB RNC
MME
Source S-GW
Target SGSN
PDN-GW
Data flow 1. Handover decision 2. Handover Required
3. Forward Relocation Required
4. Create Bearer Request/Response 5. Relocation Request 6. Relocation Request Ack
Direct Forwarding
7. Forward Relocation Response 8. Create Bearer Request/Response
Indirect Forwarding
Optional Stage
Inter-RAT Handover Preparation
Inter-RAT Handover Preparation The example provided below is for handover of active traffic connections between a home-network E-UTRAN cell and a home-network 3G UTRAN cell without an S-GW change and with no S12 Direct Tunnel support. Following a UE’s decision to request a handover (1), but before that handover can be initiated, a certain amount of preparation must take place. The source eNB determines that the indicated handover candidate is an inter-RAT neighbour and informs the source MME using the Handover Required S1AP message (2). The source MME selects a target SGSN and issues a Forward Relocation Request via the S3 interface (3). If the target SGSN has an S4 interface to the existing S-GW it issues a Create Bearer Request to that S-GW (4). If the target SGSN has no S4 interface to the serving S-GW (if they are in different PLMNs for example) then the target SGSN must select a local target S-GW, establish a bearer to it and then initiate an S-GW Relocation between the source and target nodes. Inter-PLMN traffic travels from visited S-GW to home PDN-GW, not visited SGSN to home PDN-GW. The target SGSN instructs the target BSC/RNC to reserve radio resources for the UE in the target cell using the Relocation Request message (5), and the target RNC responds with Relocation Request Ack once this is complete (6). Once the GERAN/UTRAN RAB and PDP context are in place, the target SGSN sends the Forward Relocation Response to the source MME (7).
Further Reading: 3GPP TS 23.401:5.5.2 LT3600/v1.1
© Wray Castle Limited
7.27
LTE/SAE Engineering Overview
UE
Source Target eNB RNC
MME
Source S-GW
Target SGSN
PDN-GW
Data flow 9. Handover Command 10a. HO from E-UTRAN Command Release and reconnect 10b. HO to UTRAN Complete
11a. Downlink Data via Direct Forwarding (eNB-RNC) 11b. Downlink Data via Indirect Forwarding 11a/b. Downlink Data 11c. Uplink Data
Direct Forwarding Indirect Forwarding
12. Relocation Complete 13. Forward Relocation Complete
Optional Stage
Inter-RAT Handover Execution
Inter-RAT Handover Execution The UE remains connected to the source E-UTRAN cell during the preparation phase, but once alternative resources are in place the source MME issues a Handover Command to the source eNB (9), which in turn sends a HO from E-UTRAN Command to the UE (10a). This message encapsulates a ‘transparent container’ that travels between the target RNC and the UE, which contains details of the resources that have been reserved for the UE in the target cell. The UE releases its E-UTRAN resources and performs the access activities required to establish connectivity in the target UTRAN cell and sends the Handover to UTRAN Complete message (10b) in the new cell to confirm the connection. As the tunnel from the PDN-GW has not yet been realigned, Downlink packet traffic destined for the UE is still being sent to the source eNB and must be forwarded to the target RNC. Direct forwarding between the source eNB and target RNC (11a) uses an unnamed forwarding interface. Indirect Forwarding travels between source eNB, source S-GW, target SGSN and target UTRAN (11b). Once the handover is complete, the UE can send traffic on the uplink via the PDP Context that has been created towards the SGSN, from where it will be forwarded to the S-GW and on to the PDN-GW (11c). Once the UE has successfully connected to the UTRAN cell the target RNC sends a Relocation Complete message (12) to the target SGSN, which in turn informs the source MME using the Forward Relocation Complete message (13).
Further Reading: 3GPP TS23.401:5.5.2 7.28
© Wray Castle Limited
LT3600/v1.1
EPC Operations
UE
Source Target eNB RNC
MME
Source S-GW
Target SGSN
PDN-GW
14. Update Bearer Request/Response
15. Data Flow
16. Routing Area Update
17. Delete Bearer Request/Response
17. Release Resources
18. Delete Bearer Request/Response (if Indirect Forwarding used)
Direct Forwarding Indirect Forwarding
Optional Stage
Inter-RAT Handover Execution (continued)
Inter-RAT Handover Execution (continued) The target SGSN issues an Update Bearer Request to the S-GW (14), which initiates the path switch. Any indirect forwarding will cease and downlink traffic will travel from the S-GW directly to the target SGSN (15). If the relocation involved a change in S-GW the PDN-GW would also need to be informed so that it could realign its end of the EPS bearer tunnel. The UE performs a RAU (Routing Area Update) (16) and the target SGSN may decide to instruct the UE to reauthenticate. The MME started a timer when the handover initiated; when it expires it instructs the source S-GW and source eNB to release any resources and contexts stored for the UE (17). If indirect forwarding was employed, the source S-GW and SGSN will release any tunnel resources that were created (18). Traffic is now flowing to the UE from the PDN-GW, via an S-GW to an SGSN and onwards via the UTRAN.
Further Reading: 3GPP TS23.401:5.5.2 LT3600/v1.1
© Wray Castle Limited
7.29
LTE/SAE Engineering Overview S-CSCF
I-CSCF
PDN-GW A
I-CSCF
PDN-GW B
E-UTRAN A Periodic Re-registration or due to IP address change
E-UTRAN B
Re-registration due to P-CSCF change
UE
IMS Procedures
IMS Procedures IMS support for connected-mode UEs is limited to ensure that the UE’s IP address remains valid and reachable and that the UE is periodically reregistered. A roaming UE may at times move from one access network to another, as in the inter-RAT handovers outlined above. From the IMS point of view all UEs access via an IP-CAN (IP Connectivity Access Network), so a change of RAT may only entail a change of IP address. In such cases the UE only needs to initiate the SIP Register process to inform the I-CSCF of the new IP address details. In some circumstances the new IP-CAN to which a UE moves may not have connectivity to the I-CSCF currently serving that UE. In such cases the UE must employ the I-CSCF discovery process before registering with that new node.
Further Reading: 3GPP TS 23.228 (IMS) 7.30
© Wray Castle Limited
LT3600/v1.1
EPC Operations
UE
MME
UE-initiated Detach
SGSN
MME-initiated Detach
SGSN-initiated Detach
EMM-Deregistered
HSS
HSS-initiated Detach
EMM-Registered
If the UE has multiple PDN connections established, the detach procedure must be repeated for each of them
E-UTRAN Detach
E-UTRAN Detach A UE will detach from the network either when service is no longer required by the user or when the network decides that service is no longer to be offered to the UE. There are currently four EPS-related detach procedures:
UE-initiated detach
MME-initiated detach
SGSN-initiated detach
HSS-initiated detach
As with legacy 3GPP networks, a detach can be ‘explicit’ or ‘implicit’. An implicit detach is initiated when a UE fails to send a TAU (or, if the UE has ISR active, a RAU) within a specified time. At the expiry of the TAU timer the MME will start an implicit detach timer; when that expires the UE will be detached. If ISR is active for the UE, the device initiating the detach will inform its peer via the S3 interface. 3GPP is also investigating whether there is a need to allow the S-GW and PDN-GW to initiate detaches too.
Further Reading: 3GPP TS 23.401:5.3.8 LT3600/v1.1
© Wray Castle Limited
7.31
LTE/SAE Engineering Overview
UE
eNB
MME
S-GW PDN-GW
SGSN
HSS
1. Detach Request 2. Delete Bearer Request 3. Delete Bearer Response 4a. Detach Indication (if ISR active) 4b. Delete PDP Context Request 5. Delete Bearer Request 6. Delete Bearer Response 4c. Delete PDP Context Response 4d. Detach Indication Ack 7. Detach Accept 8. Release Resources 9. Notify/Request, Notify Response Optional Stage
UE-initiated Detach
UE-initiated Detach A UE will explicitly detach from the EPS under instruction from the user interface, usually in response to a power-down command. The process is initiated by the UE sending a Detach Request NAS message to the MME containing its current GUTI and a cause (e.g ‘switch off’) (1). The MME forwards a Delete Bearer Request to the S-GW (2), which responds to confirm (3). The S-GW forwards the Delete Bearer Request to the PDN-GW, which releases S5/S8 resources and confirms to the S-GW using a Delete Bearer Response (5 and 6). If the UE has ISR activated, whilst the functions related to the S-GW and PDN-GW are taking place, the MME will inform its peer SGSN of the detach and will receive a response (4a and 4b). The S-GW and SGSN will delete the S4 bearer context and the SGSN confirms the detach to the MME (4c and 4d). The MME transmits a NAS Detach Accept message to the UE (7) and in response the UE and eNB release air interface and S1 physical and logical resources (8). The UE is now detached and the HSS is informed of the change in its availability (9).
Further Reading: 3GPP TS 23.401:5.3.8 7.32
© Wray Castle Limited
LT3600/v1.1
LTE/SAE Engineering Overview
LTE/SAE Engineering Overview
Glossary of Terms
© Wray Castle Limited
LTE/SAE Engineering Overview 16QAM 1xEV-DO 3GPP 64QAM
16-state Quadrature Amplitude Modulation 1x Evolution – Data Only 3rd Generation Partnership Project 64-state Quadrature Amplitude Modulation
AAA AAL AF AM AMBR APN ARQ AS ATM AUTN AV
Authentication Authorization and Accounting ATM Adaptation Layer Application Function Acknowledged Mode Aggregate Maximum Bit Rate Access Point Name Automatic Repeat Request Access Stratum Asynchronous Transfer Mode Authentication Token Authentication Vector
BCCH BCH BER BLER BPSK BSC BSSAP+
Broadcast Control Channel Broadcast Channel Bit Error Rate Block Error Rate Binary Phase Shift Keying Base Station Controller Base Station System Application Part +
CCE CDMA CDRs CE CK CMAC CMC CP CQI CRC C-RNTI CS
Control Channel Element Code Division Multiple Access Call Data Records Control Element Cipher Key Cipher-based MAC Connection Mobility Control Cyclic Prefix Channel Quality Indication Cyclic Redundancy Check Cell Radio Network Temporary Identifier Circuit Switched
DAB DFT DHCP DiffServ DL-SCH DMT DRA DRX DSCP DSMIPv6 DSP DTAP DVB-T/H/S DVRB DwPTS
Digital Audio Broadcasting Discrete Fourier Transform the Dynamic Host Configuration Protocol Differentiated Services Downlink Shared Channel Discrete Multi-Tone modulation Dynamic Resource Allocation Discontinuous Reception DiffServ Code Point Dual Stack Mobile IP version 6 Digital Signal Processor Direct Transfer Application Part Digital Video Broadcasting for Terrestrial Handheld and Satellite Distributed Virtual Resource Block Downlink Pilot Time Slot
E EARFCN ECGI ECGI ECM EDGE EMM
Extension E-UTRAN Absolute Radio Frequency Channel Number E-UTRAN Cell Global Identifier E-UTRAN Cell Global Identity EPS Connection Management Enhanced Data rates for Global Evolution EPS Mobility Management
G.2
© Wray Castle Limited
LT2300/v1.1
Glossary of Terms eNB EPC EPRE EPS EIR E-RAB ETSI E-UTRA E-UTRAN
Evolved Node B Evolved Packet Core Energy Per Resource Element Evolved Packet System Equipment Identity Register E-UTRAN Radio Access Bearer European Telecommunications Standards Institute Evolved Universal Terrestrial Radio Access Evolved Universal Terrestrial Radio Access Network
FA FDD FDM FFT FI
Foreign Agent Frequency Division Duplex Frequency Division Multiplexing Fast Fourier Transform Framing Information
GAN GANC GBR GERAN GGSN GMM GPRS GPS GSM GTP-C GTP-U GTPv2 GUMMEI GUTI
Generic Access Network Generic Access Network Controller Guaranteed Bit Rate GPRS/EDGE Radio Access Network Gateway GPRS Support Node GPRS Mobility Management General Packet Radio Service Global Positioning System Global System for Mobile Communications GPRS Tunnelling Protocol – Control plane GPRS Tunnelling Protocol – User plane GTP version 2 Globally Unique MME Identity Globally Unique Temporary Identity
HARQ HeNB HeNB GW HLR H-PCRF H-PLMN HSDPA HSPA HSS HSUPA
Hybrid Automatic Repeat Request Home eNode B Home eNode B Gateway Home Location Register Home Policy and Charging Rules Function Home PLMN High Speed Downlink Packet Access High Speed Packet Access Home Subscriber Server High Speed Uplink Packet Access
ICIC I-CSCF IETF IFFT IK IMS IMSI IMT-2000 IP IP-CAN IPsec IPv4 IPv6 ISI ISR
Inter-Cell Interference Coordination Interrogating Call State Control Function Internet Engineering Task Force Inverse Fast Fourier Transform Integrity Key IP Multimedia Subsystem International Mobile Subscriber Identity International Mobile Telecommunications 2000 Internet Protocol IP Connectivity Access Network IP security IP version 4 IP version 6 Inter Symbol Interference Idle-mode Signalling Reduction
LT2300/v1.1
© Wray Castle Limited
G.3
LTE/SAE Engineering Overview LA LB LCID LI LTE
Location Area Load Balancing Logical Channel Identity Length Indicator Long Term Evolution
MAC MAC MBMS MBR MBSFN MCC MCS MIB MIMO MIPv4 MME MMEC MMEGI MNC MS MSC M-TMSI MU-MIMO
Medium Access Control Message Authentication Code Multicast and Broadcast Multimedia Services Maximum Bit Rate Multicast/Broadcast Single Frequency Network Mobile Country Code Modulation and Coding Scheme Master Information Block Multiple Input Multiple Output Mobile IPv4 Mobility Management Entity Mobility Management Entity Code MME Group Identifier Mobile Network Code Mobile Station Mobile-services Switching Centre MME Temporary Mobile Subscriber Identity Multi-User MIMO
NAS NCL
Non-Access Stratum Neighbour Cell List
OFDM OFDMA
Orthogonal Frequency Division Multiplexing Orthogonal Frequency Division Multiple Access
P/S-SCH PAPR PBCH PBR PCC PCEF PCFICH PCH PCRF PDCCH PDCP PDN PDN-GW PDSCH PDU PHICH PLMN PMCH PMIPv6 PRACH PRACK PRB PS PS PSS PUCCH PUSCH
Primary/Secondary Synchronization Channel Peak to Average Power Ratio Physical Broadcast Channel Prioritized Bit Rate Policy and Charging Control Policy and Charging Enforcement Function Physical Control Format Indicator Channel Paging Channel Policy and Charging Rules Function Physical Downlink Control Channel Packet Data Convergence Protocol Public Data Network Public Data Network Gateway Physical Downlink Shared Channel Protocol Data Units Physical H-ARQ Indicator Channel Public Land Mobile Network Physical Multicast Channel Proxy Mobile IPv6 Physical Random Access Channel Provisional Acknowledgement Physical Resource Block Packet Scheduling Packet Switched Primary Synchronization Signal Physical Uplink Control Channel Physical Uplink Shared Channel
G.4
© Wray Castle Limited
LT2300/v1.1
Glossary of Terms QoS QPSK
Quality of Service Quadrature Phase Shift Keying
R99 RA RAC RACH RADIUS RAN RANAP RAND RAT RB RBC RF RFC RFSP RLC RNC RNSAP RNTI RoHC RRC RRM RSRP RSRQ RSSI RTCP RTP
Release 99 Routing Area Radio Admission Control Random Access Channel Remote Access Dial-In User Service Radio Access Network Radio Access Network Application Part Random Number Radio Access Technology Resource Block Radio Bearer Control Radio Frequency Request For Comment RAT/Frequency Selection Priority Radio Link Control Radio Network Controller Radio Network Subsystem Application Protocol Radio Network Temporary Identifier Robust Header Compression Radio Resource Control Radio Resource Management Reference Signal Received Power Reference Signal Received Quality Received Signal Strength Indicator Real Time Control Protocol Real Time Protocol
S1AP SAE SC-FDMA S-CSCF SCTP SDF SDP SDU SFN SGsAP SGSN S-GW SIM SIP SMS SN SPS SRVCC SS7 SSS S-TMSI
S1 Application Protocol System Architecture Evolution Single Carrier FDMA Serving Call State Control Function Stream Control Transmission Protocol Service Data Flow Session Description Protocol Service Data Unit Single Frequency Network SGs Application Part Serving GPRS Support Node Serving Gateway Subscriber Identity Module Session Initiation Protocol Short Message Service Sequence Number Semi Persistent Scheduling Single Radio VCC Signalling System No 7 Secondary Synchronization Signal) SAE Temporary Mobile Subscriber Identity
TA TA TAC TAD TAI TAI TAU TB TCP
Timing Advance Tracking Area Tracking Area Code Traffic Aggregate Descriptor Tracking Area ID Tracking Area Identifier Tracking Area Update Transport Block Transmission Control Protocol
LT2300/v1.1
© Wray Castle Limited
G.5
LTE/SAE Engineering Overview TDD TDM TD-SCDMA TEID TFT TIN TM TPC TTI UDP
Time Division Duplex Time Division Multiplexing Time Division Synchronous Code Division Multiple Access Tunnel Endpoint ID Traffic Flow Template Temporary Identity used in Next update Transparent Mode Transmit Power Control Transmission Time Interval User Datagram Protocol
UE UM UMTS UPE UpPTS USIM UTRAN
User Equipment Unacknowledged Mode Universal Mobile Telecommunications System User Plane Entity Uplink PTS Universal Subscriber Identity Module UMTS Terrestrial Radio Access Network
VCC VLR VoIP VoLGA V-PCRF VRB
Voice Call Continuity Visitor Location Register Voice over IP Voice over LTE Generic Access Visited Policy and Charging Rules Function Virtual Resource Block
WCDMA WiMAX WLAN
Wideband Code Division Multiple Access Worldwide Interoperability for Microwave Access Wireless Local Area Network
X2AP XRES
X2 Application Protocol Expected Response
G.6
© Wray Castle Limited
LT2300/v1.1
View more...
Comments
