LTE Evolved Packet Core Network

(1)

LTE Evolved

Packet Core Network

Course Code: LT3604LT3604 Duration: 2 days2 days Technical Level:33

LTE/SAE Engineering Overview LTE Air Interface

LTE Radio Access Network Cell Planning for LTE Networks LTE Evolved Packet Core Network 4G Air Interface Technologies

LTE Technologies, Services and Markets

... del

deliv

iveri

ering know

ng knowled

ledge,

ge,

max

maximi

imizin

zing

g per

perfo

forrman

mance

ce...

www.wraycastle.com

Wray Castle – leading the way in

(2)

(3)

LTE EVOLVED PACKET CORE

NETWORK

WRAY CASTLE LIMITED BRIDGE MILLS STRAMONGATE KENDAL

LA9 4UB UK

Y

Yours to have and to hold but no

ours to have and to hold but not to copy

t 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. All of our paper is

(4)

LTE Evolved Packet Core Network

(5)

LTE EVOLVED PACKET CORE NETWORK

LTE Evolved Packet Core Network

(7)

LTE Evolved Packet Core Network

1.i © Wray Castle Limited

LT3604/v4.0

LTE OVERVIEW

SECTION 1

(8)

LTE Evolved Packet Core Network

(9)

LTE Overview

1.iii © Wray Castle Limited

LT3604/v4.0

Evolution t o L TE.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .1.1 EPC and IMS Architecture . . . .1.2 PDN (Packet Data Network) Connectivity Services . . . .1.3 E-UTRAN (Evolved UMTS Terrestrial Radio Access Network) . . . .1.4 EPC (Evolved Packet Core). . . .1.5 Additional Network Elements . . . .1.6

PS Interworking .. .. . .. .. .. .. .. .. .. .. . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .1.7 CS Interworking .. .. . .. .. .. .. .. .. .. .. . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .1.8 Non-3GPP Access Interworking. . . .1.9 LTE User Services .. .. . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .1.10

(10)

LTE Evolved Packet Core Network

(11)

At the end of this section you will be able to:

OBJECTIVES

LTE Overview

1.v © Wray Castle Limited

LT3604/v4.0

■ discuss the evolution of 3GPP networks and show where LTE fits in

■ describe the basic architecture of a an LTE network

■ define the term ‘PDN Connection’ and describe the role of the EPS Bearer within it

■ list the main elements and interfaces found within the E-UTRAN

■ outline the basic set of network elements that comprise an EPC

■ describe the functions of additional network elements such as HeNBs and LTE Relay Nodes

■ demonstrate an understanding of the interworking options available to LTE networks for PS,

CS and non-3GPP access types

(12)

LTE Evolved Packet Core Network

(13)

LT3604/v4.0 © Wray Castle Limited 1.1

LTE Overview

Evolution to LTE Evolution to LTE

LTE (Long Term Evolution) represents the next developmental step for the 3GPP standards group. It provides for a continued evolutionary path from 2G GSM/GPRS, beyond 3G UMTS/HSPA and ultimately towards a 4G solution.

UMTS has continued to build on the success of GSM and momentum is gathering behind its significantly increased capability with the introduction of HSPA. 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 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), and this in turn can be used as a direct pathway to LTE. Similarly, the interworking capabilities of the EPC (Evolved Packet Core) make it possible for CDMA (Code Division Multiple Access) to migrate radio access from 1x or 1xEV-DO (1x Evolution – Data Only) to LTE.

Evolution beyond LTE has been mapped out by 3GPP with the specification of LTE-Advanced, which offers the possibility of downlink data rates (to stationary or low mobility users) of 1 Gbit/s or more.

Further Reading: 3GPP TS 36.300 (LTE Radio Access), 23.401 (LTE Core Network) GSM/GPRS GSM/GPRS GSM/EGPRS GSM/EGPRS 50 kbit/s 150 kbit/s UMTS UMTS UMTS/HSPA UMTS/HSPA EDGE EDGE Evolution Evolution UMTS/HSPA+ UMTS/HSPA+ 1 Mbit/s 10 Mbit/s 40 Mbit/s 400 kbit/s LTE(4G) LTE(4G) 100+ Mbit/s LTE-Advanced Advanced 1+ Gbit/s

(14)

1.2

LTE Evolved Packet Core Network

EPC and IMS Architecture EPC and IMS Architecture

In addition to the S1 interface connecting the E-UTRAN (Evolved Universal Terrestrial Radio Access Network) to the EPC, a broader range of ‘S’ interfaces have been defined to identify interconnections between EPC nodes and external nodes.

The gateways and the MME (Mobility Management Entity) 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 (IP Multimedia Subsystem). In this respect the S6a interface connects the MME to the HSS (Home Subscriber Server), and the S7/Gx interface provides access from the PCRF (Policy and Charging Resource Function) to the PDN-GW (Packet 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.

WLANs (Wireless Local Area Networks) 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.

Further Reading: 3GPP TS 23.401:4.2 MME PDN–GW PCRF HSS 2G/3G SGSN SGi S5 S3 S4 S6a S7/Gx S–GW IP Services IMS WLAN or WiMAX S2 S1-U E-UTRAN E-UTRA UTRAN/ GERAN UMTS/ GPRS S1-MME S12 S11 Interworking to MME Rx EIR S13

(15)

LTE Overview

PDN (Packet Data Network) Connectivity Services PDN (Packet Data Network) Connectivity Services

The EPS (Evolved Packet System) is designed to perform one function, which is to provide IP connectivity between a UE (User Equipment) and a PDN. No services exist within an EPS apart from those designed to enable the creation, maintenance and teardown of IP connections. The IP connectivity service provided to a UE is referred to as a PCS (PDN Connectivity Service), sometimes known as just a PDN Connection.

A PCS is a logical connection between an IP Address assigned to a UE and an APN (Access Point Name) in a PDN-GW. The connectivity provided by a PCS consists of one or more EPS Bearers that connect the UE to the Access Point and traverse both the E-UTRAN and the EPC. The PDN-GW routes traffic between the EPS Bearer and the external PDN. The EPS Bearers, in turn, carry a TFA (Traffic Flow Aggregate) that consists of one or more SDF (Service Data Flow) connections between the UE and external data services.

If a UE requires additional connectivity that is only available via a different external PDN, then additional PDN Connectivity Services may be established in parallel via different PDN-GW Access Points, each with their own set of EPS Bearers.

PDN Connectivity is the only service provided by an LTE network. All other services, such as voice telephony, location-based services, messaging and Internet browsing are provided by external PDNs via a PCS. Further Reading: 3GPP TS 23.401:4.7.1 PDN Connectivity Service EPS Bearer IP Address APN PDN Connectivity Service

EPS Bearers APN

Packet Data Networks Packet Data Networks IP Address

(16)

1.4

LTE Evolved Packet Core Network

E-UTRAN (Evolved UMTS Terrestrial Radio Access Network) E-UTRAN (Evolved UMTS Terrestrial Radio Access Network)

The basic building blocks of the E-UTRA (Evolved Universal Terrestrial Radio Access) access network are the eNB (E-UTRAN 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. HSDPA (High Speed Download Packet Access) 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.

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 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. An eNB may be associated with MMEs belonging to different PLMNs (Public Land Mobile Networks), allowing for the easy creation of multi-operator networks.

The interfaces that interconnect UEs and eNBs and that connect eNBs to each other and to the LTE core network are: the Uu air interface, the X2 inter-eNB interface and the S1 eNB backhaul interface to the EPC core network. The X2 interface is optional and, if present, is used for inter-eNB resource management and handover control messaging.

The LTE user terminal continues to be known as the UE just as it was in UMTS.

Further Reading: 3GPP TS36.300, 23.401 S1 EvolvedEvolved Packet Core Packet Core S1 X2 eNB (E-UTRAN Node B) eNB E-UTRAN E-UTRAN LTE UE Uu

(17)

LTE Overview

EPC (Evolved Packet Core) EPC (Evolved Packet Core)

The reduced complexity in the RAN (Radio Access Network) 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 backwards-compatibility purposes.

■ the MME handles control plane functions related to mobility management and idle mode handling

■ the S-GW (Serving Gateway) and PDN-GW perform user plane handling, switching/routing and

interfacing functions

■ the PCRF is an optional network element which, if deployed, handles QoS (Quality of Service) and

bearer policy enforcement

■ subscriber management and security functions are handled by the HSS, which incorporates the

functions of the legacy HLR (Home Location Register)

Further Reading: 3GPP TS23.401 Internet EPC MME S-GW PDN-GW PCRF HSS IP network

(18)

1.6

LTE Evolved Packet Core Network

Additional Network Elements Additional Network Elements

A number of optional or additional network elements may be required to support some of the enhanced or extended functionality introduced in LTE.

Small cell (micro-, pico-, femtocell) deployments require network operators or even customers to deploy small cell base stations, which are generically known as HeNBs (Home eNode Bs) even if they are not necessarily deployed in a customer’s home. HeNBs can connect into the operator’s core network in a variety of ways but the recommended method employs an HeNB GW, which concentrates and manages the C-plane S1-MME interfaces from multiple HeNBs towards the network’s MMEs. As HeNBs generally connect to the operator’s core network via the Internet a SeGW (Security Gateway) is usually employed to provide firewall and access control functionality on the edge of the core network.

SeGWs are also employed in the access network. LTE backhaul generally employs packet-based technologies such as Carrier Ethernet or MPLS (Multi Protocol Label Switching) on links between eNBs and an operator’s core network. The IP-based traffic carried over these links can be protected and encrypted using IPsec (IP Security), with tunnels created between the eNB and a SeGW. The SeGW therefore acts as the gateway into the core from the access network and can apply security policies and authenticate eNBs before accepting new backhaul connections.

3GPP Release 10 specifications introduced the concept of the LTE Relay Node (RN) which can be deployed to act as a relay or repeater for base station signals in areas that traditional cells have struggled to serve, for example, areas in the shadows of large buildings, or in valleys or even in indoor or underground locations such as shopping centres and car parks. ARN connects to its controlling DeNB (Donor eNB) using one of the main site’s cells and then relays the traffic it receives into the served area using the same radio resource. The DeNB is a standard base station that also acts as an MME-proxy for the RNs it controls.

These additional network elements are key to a network operator’s ability to successfully deploy optional additional services.

Further Reading: 3GPP TS23.401 HeNB (Home eNode B)

LTE Relay Node (RN) Security Gateway (SeGW) Donor eNB (DeNB) HeNB GW Operator’s core network

IPsec tunnels via the Internet IPsec tunnels via

(19)

LTE Overview

PS Interworking PS Interworking

The EPS forms part of the ongoing evolution of GSM and UMTS networks and therefore has been designed to offer full backwards compatibility with legacy networks and has also been provided with the ability to interwork with non-3GPP network types.

The EPC S3 and S4 interfaces enable a legacy SGSN (Serving GPRS Support Node) to interwork with the EPS MME and S-GW nodes.

This in turn allows UEs served by 2G GERAN (GPRS/EDGE Radio Access Network) or 3G UTRAN access networks to establish connections via the EPC (in this scenario, access is provided via the 2G/3G SGSN, with the EPC PDN-GW taking on the ‘connection anchor’ role of the GGSN (Gateway GPRS Support Node)).

The interworking capabilities provided by these interfaces also allows handover of PS (Packet Switched) connections between 2G and 3G access networks and the E-UTRAN.

The S12 interface has been designed to allow UMTS UTRAN elements (specifically the RNC) to interface directly with an EPC S-GW without the need for an intermediate SGSN.

The S16 interface is an optional interface that allows upgraded SGSNs to exchange EPS Bearer management signalling messages.

Further Reading: 3GPP 3GPP TS23.401 MME PDN–GW PCRF HSS 2G/3G SGSN SGi S5 S3 S4 S6a S7/Gx S–GW IP Services IMS WLAN or WiMAX S2 S1-U E-UTRAN LTE UTRAN/ GERAN UMTS/ GPRS S1-MME S12 S11 Interworking to MME Rx S16 S6d

(20)

1.8

LTE Evolved Packet Core Network

CS Interworking CS Interworking

Although LTE networks do not directly provide CS (Circuit Switched) services, the EPC is able to interwork with legacy core networks to support the CS services that they offer.

Media sessions set up via the IMS using the VoLTE (Voice over LTE) method that were initially carried by the E-UTRAN can be transferred to a legacy CS network using the SRVCC (Single Radio Voice Call Continuity) functions specified in 3GPP TS 23.216 and the IMS Service Continuity features of TS 23.237. Call handover signalling is carried between the LTE MME and a legacy MSC Server using the Sv interface. Prior to Release 11 SRVCC operated in one direction only (E-UTRAN to UTRAN/GERAN) and it was not possible to hand calls back to the E-UTRAN after a session transfer had taken place. Release 11 introduced the ability to support two way SRVCC session transfers. SRVCC allows the ‘access leg’ of a call (e.g. the connection between the UE and the serving IMS) to be transferred from an LTE EPS Bearer to a legacy CS bearer, whilst maintaining the anchor for the call in the IMS.

When an E-UTRAN-connected UE with an active VoLTE/IMS call determines that the only handover candidates are GERAN or UTRAN cells, it initiates the SRVCC process. The MME differentiates between the UE’s current CS and PS sessions; CS sessions are subject to SRVCC, whilst PS sessions can be handed over to an SGSN using PS HO (Packet Switched Handover) procedures. The MME co-ordinates the handover with a CS domain MSC-Server using a set of ‘PS to CS’ handover messages. Once the target cell and BSS/RNS have been prepared for the handover and CS resources have been reserved, the session traffic is transferred by the IMS away from the EPC PDN-GW and towards a CS domain MGW. The MGW forwards the traffic to the selected BSS (Base Station System)/RNS (Radio Network Subsystem) and on to the UE.

LTE-connected UEs may alternatively be provided with access to CS services via the CSFB (CS Fallback) feature. CSFB allows UEs to make use of legacy CS networks when making or receiving calls; when a call is initiated a CSFB-capable UE can be instructed to ‘fallback’ to a GERAN or UTRAN cell to enable the call to connect. When the call is over the UE is free to reselect back to E-UTRAN coverage again. Interworking between the EPC and a legacy CS core network for CSFB purposes is managed via the SGs interface between an MME and an MSC Server.

Further Reading: 3GPP TS 23.401, 23.216 (SRVCC), 23.237 (IMS Service Continuity), 23.272 (CS Fallback)

UE _MME PDN–GW S–GW E-UTRAN E-UTRAN GERAN/ GERAN/ UTRAN UTRAN MSC Server MGW IMS IMS Traffic Connection Sv and SGs interfaces

(21)

LTE Overview

Non-3GPP Access Interworking Non-3GPP Access Interworking

The 3GPP R6 and R7 series of specifications included several solutions aimed at allowing access to 3GPP core network environments from non-3GPP radio access networks. These facilities have been evolved to accommodate access to the EPS from non-3GPP systems also.

There are specific provisions to allow access from Wi-Fi (802.11-based systems), WiMAX (802.16-based systems) and 3GPP2 systems such as cdmaOne™ and CDMA2000™, although access from other types of system is not necessarily precluded.

3GPP makes the distinction between ‘trusted’ and ‘non-trusted’ access networks and provides a range of different interworking options for each scenario.

The diagram shows options supporting UEs that can access an EPC directly (via the E-UTRAN) and also via trusted and non-trusted, non-3GPP access systems.

Further Reading: 3GPP TS 23.402 PDN–GW PCRF HSS S–GW IP Services IMS 3GPP Access HPLMN

ePDG 3GPP AAA_Server

Trusted Non-3GPP IP access Non-trusted, Non-3GPP IP access Non-3GPP Networks S6a SWx Rx SGi Gxb SWm S6b Gxa Gx Gxc STa SWa SWn S5 S2c S2c S2c

(22)

1.10

LTE Evolved Packet Core Network

LTE User Services LTE User Services

An LTE network is designed to support only one user service, the provision of an IP-based bearer to a mobile device.

Depending upon the type and capabilities of the external PDNs (Packet Data Networks) to which LTE UEs are connected, users should be able to access all of the user services offered by legacy networks plus the ability to access very high bit rate data bearers with rates of 100 Mbit/s or more.

In some cases these services will be managed via an IMS (IP Multimedia Subsystem) and in other cases they will be supplied as OTT (Over the Top) services. OTT services are typically provided via the Internet and connect to users ‘over the top’ of their EPS Bearer.

Examples of some of the services that could be made available to LTE users are shown in the diagram. Internet

Internet Access

Access IntranetIntranet

Access Access SMS, SMS, MMS, IM MMS, IM Email Email V

Voice oice andand Video Video Telephony Telephony Online Online Gaming Gaming Location-based Location-based Services Services Roaming Roaming

(23)

EVOLVED PACKET CORE

LTE Evolved Packet Core Network

2.i © Wray Castle Limited

LT3604/v4.0

SECTION 2

(24)

LTE Evolved Packet Core Network

2.ii

MME ... ... ... ... ... ... ... ... ... ... ... ... ... 2.2 S-GW ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 2.3 PDN-GW... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... .2.4 PCRF ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 2.5 HSS ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... .2.6 Combined Functionality . . . .2.7 Tracking Area. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 2.8 Tracking Area Management. . . .2.9 Resilience Through Pooling . . . .2.10 Network Sharing . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .2.11 EPS Area Identities. . . .2.12 Node Identifiers .. .. .. .. . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .2.13 NAS Identities.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 2.14 EPC Interfaces.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .2.15 S1AP (S1 Application Protocol) . . . .2.16 GTPv1-U T raffic Interfaces.. . . .2.17 GTPv2-C C-plane Interfaces . . . .2.18 Diameter-based Interfaces. . . .2.19 EPS Resilience.. .. .. . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 2.20 Interface to CS Networks . . . .2.21 Non-3GPP Access N etworks . . . .2.22 PDN C onnectivity S ervices. . . .2.23 EPS Bearers and UE Connectivity. . . .2.24

(25)

Evolved Packet Core

2.iii © Wray Castle Limited

LT3604/v4.0

Default and Dedicated EPS Bearers . . . .2.25 EPS Bearer Termination.. . . .2.26 Default APN Characteristics. . . .2.27 EPS Bearers and Underlying Bearers . . . .2.28 Connection Hierarchies . . . .2.29 Transport Identities. . . .2.30 IP Addressing.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 2.31 PDN IP Address Allocation. . . .2.32 PCS H ierarchy .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .2.33 SDF ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 2.34 SDF 5-tuple .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .2.35 Traffic Flow Templates . . . .2.36 EPS Quality of Service.. . . .2.37 QCI ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... .2.38 ARP . . . .2.39 QoS Attributes .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. . .. .. .. .. .. .. .. .. .. .. .. .. .. .. 2.40 PCC ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 2.41 Information Storage . . . .2.42 Charging Capture Points . . . .2.43 Small Cells . . . .2.44 HeNBs and Closed Subscriber Groups . . . .2.45 HeNB GW and HeNB Connectivity Options. . . .2.46 LIPA and the L-GW.. .. . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .2.47 SIPTO (Selected IP Traffic Offload) . . . .2.48

(26)

LTE Evolved Packet Core Network

2.iv

IP Flow Mobility ... .. . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 2.49 Location-Based Services . . . .2.50 Machine Type Communication. . . .2.51 End-to-End Connectivity. . . .2.52 UE to PDN-GW via E-UTRAN . . . .2.53 EPS Bearer Via Home GERAN/UTRAN. . . .2.54 UE to PDN-GW via 2G GERAN. . . .2.55 UE to PDN-GW via 3G UTRAN . . . .2.56 LTE Voice Options . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .2.57 LTE Voice – CS Fallback . . . .2.58 LTE Voice - VoLTE .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 2.59 SRVCC ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... .2.60 EPC Security Functions . . . .2.61 AKA (Authentication and Key Agreement) . . . .2.62 User Confidentiality . . . .2.63 Ciphering and Integrity Protection . . . .2.64

(27)

Evolved Packet Core

2.v © Wray Castle Limited

LT3604/v4.0

At the end of this section you will be able to:

OBJECTIVES

■ outline the functions performed by key EPC elements such as the MME, S-GW, PDN-GW,

HSS and PCRF

■ discuss options for interworking the EPC with legacy packet core networks

■ describe the main points of interest related to EPC topics such as MME pooling, S-GW

Service Areas, Tracking Areas and TA List management

■ list the basic set of identifiers used to describe EPC areas, network nodes and UEs/

subscriber as employed by the EPC

■ list the set of S interfaces described for the EPC and outline their basic functions and

protocols

■ outline the interaction between the EPC, GTP and IP

■ outline how combinations of redundant S interfaces can provide for EPC resilience

■ describe the interworking options that exist between the EPC and legacy/non-3GPP access

and core network types

■

discuss options for User Plane connectivity between a UE and a PDN-GW

■ discuss the concept of the PDN Connection and its relevance within the EPC

■ outline the functions of the default EPS Bearer

■ 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 in the handling of a PCS

■ 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

■ discuss the concept of PCC (Policy and Charging Control) and its application in the EPC

■ outline the role played by Small Cells in LTE service deployment including the functionality of

the HeNB and HeNB GW

■ describe the functionality of additional network architectural features and services such as

LIPA, SIPTO, IP Flow Mobility, LPP/LPPa and Machine Type Communication

■ outline the methods that are available for providing CS services to EPS attached UEs,

including OTT (Over the Top) services, VoLTE , CS Fallback and Voice Call Continuity functions

(28)

LTE Evolved Packet Core Network

(29)

Evolved Packet Core

WLAN or WiMAX to MME S2 Interworking 2G/3G SGSN UTRAN/ GERAN UMTS/ GPRS S4 S12 MME PDN–GW PCRF HSS S–GW IP Services IMS E-UTRAN LTE SGi S5 S3 S6a S7/Gx S1-U S1-MME S11 Rx Network Access IP Functions Mobility Management Anchoring 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 PDN Connection set up for a UE.

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 determining the PDN-GW node that will anchor each user PCS; 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.

(30)

2.2

LTE Evolved Packet Core Network

 NAS signalling and signalling security  Authentication and authorization

 PDN GW and S-GW selection

 Inter CN node signalling for mobility between 3GPP access networks

 MME selection for handovers with MME change

 SGSN selection

 UE reachability in idle mode

 Tracking Area list management

 Roaming connection towards home HSS

 Bearer management and establishment

 Lawful interception

 Warning message transfer

 Support for LTE Relay Nodes

Mobility Management Entity

(MME)

MME MME

The MME assumes many of the functions that would previously have been performed by the VLR (Visitor Location Register) or SGSN and which in the evolved network are termed EMM (EPS Mobility Management) and NAS (Non-Access Stratum) functions.

The MME’s main responsibilities are to terminate the Control Plane NAS signalling flows from individual UEs and to manage the mobility, 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 UE’s user plane connections.

The EMM functions also include responsibility for tracking the general location of UEs that are in idle mode and the MME ensures ‘UE Reachability’ by receiving TAU (Tracking Area Update) 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 manage the user plane connections for each UE.

The MME is also in charge of roaming and handover functions to 2G/3G SGSNs and for Lawful Intercept and Warning Message handling. Release 10 MMEs will additionally be responsible for serving the needs of LTE Relay Nodes.

(31)

Evolved Packet Core

 Local mobility anchor point for inter-eNB handover

 Mobility anchoring for inter-3GPP mobility

 Inserting end-marker packets into traffic streams during handover ‘path switch’ events

 GTP tunnel and TEID management

 Packet routing and forwarding

 Idle mode downlink packet buffering

 Transport level DiffServ packet marking

 Charging  Lawful interception Serving Gateway (S-GW) S-GW S-GW

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 facilitating transport network layer QoS by inserting DSCP (DiffServ Code Point) markers into outbound IP packet headers.

The S-GW also provides mobility anchoring for connections that roam onto legacy 3GPP GERAN (2G) and UTRAN (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.

During handovers, the S-GW is responsible for inserting ‘end marker’ packets into the downlink data stream destined for the handover UE which indicate that ‘path switch’ is due to take place.

The standard S5 and S8 interfaces that link the S-GW and PDN-GW are based on 3GPP GTP (GPRS Tunnelling Protocol), the S-GW is therefore responsible for GTP tunnel management functions and for the allocation and use of TEIDs (Tunnel Endpoint ID). 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 anchor non-3GPP 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.

Early in its development, the S-GW was also known as the UPE (User Plane Entity), although this terminology has now been dropped.

(32)

2.4

LTE Evolved Packet Core Network

 Contains APN (Access Point Name)

 UE IP address allocation

 DHCPv4 (server and client) and DHCPv6 (client, relay and

server) functions

 GTP tunnel and TEID management

 Creates and maintains TFT (Traffic Flow Templates) for packet routing discrimination

 Static PCC if no PCRF available

 Per-user-based packet filtering  SDF level charging

 SDF gating control and data rate enforcement

 DiffServ packet marking

 Lawful interception

PDN Gateway (PDN-GW)

PDN-GW PDN-GW

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 and TFT (Traffic Flow Templates) that are used to classify packets into particular SDFs before routing them over an EPS Bearer. Under direction from the PCRF the PDN-GW will act as a PCEF (Policy and Charging Enforcement Function) and will apply ‘per SDF’ charging, service level and rate enforcement and QoS-related traffic shaping functions that control the ‘gating’ of user traffic flows. In the absence of the dynamic PCC (Policy and Charging Control) exercised by a PCRF, the PDN-GW is able to apply static PCC to enable the management of bearer setup activities.

Each PDN-GW contains a number of logical access points, each identified by an APN, which act as the logical endpoints and mobility anchors of the PDN Connections and 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 PDN Connection and for routing traffic between the Bearers and particular external networks.

(33)

Evolved Packet Core

 Applies operator-determined PCC rules to control bearer resource

allocation, modification and release

 Each UE is managed by one PCRF which deals with all PDN Connection

and EPS Bearers related decision-making and also applies maximum number of active bearer limits

 Ud interface provides connectivity to User Data Repository such as HSS

 S9 interface allows for interaction between ‘home’ and ‘visited’ PCRFs to control provision of services to roaming subscribers

 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 Policy and Charging Rules Function (PCRF)

PCRF PCRF

The PCRF is an optional element that, if deployed, is responsible for propagating the network’s PCC rules to the PCEF located in traffic-handling elements such as the PDN-GW. It is designed to centrally apply operator-determined PCC rules to control the allocation, modification and release of bearer resources. This means, in simple terms, that the PCRF is the network element that decides if new connections are to be allowed and, if so, whether they will be carried by modifying an existing EPS Bearer or by creating a new one.

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 real-time traffic it may ‘gate’ up to the data rate and QoS level indicated by the PCRF and the user’s subscription profile. The central control of policy offered by the PCRF is only possible if the authorization of all services made available to each individual UE is managed via the same PCRF. This means that a network must either have only one PCRF that serves all users or must have a link between each PCRF and the HSS to allow subscriber management to be properly coordinated. This connectivity is provided by the Ud interface. Having PCC for each UE centrally managed by one PCRF allows policies such as the maximum number of active EPS Bearers that an operator will allow a UE to have established to be managed.

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.

The PCRF connects to the PDN-GW via the S7/Gx interface and to traffic gateway elements within the IMS via the Rx interface. 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 H-PCRF (Home Policy and Charging Rules Function) and V-PCRF (Visited Policy and Charging Rules Function) logical functions.

(34)

2.6

LTE Evolved Packet Core Network

HSS HSS

Centralized Subscriber Database Mobility management

User security info generation User security support Service provisioning support Call/session establishment support

Identification handling Service authorization support Access authorization Application services support

CAMEL services support

EPS EPS MME GMSC MSC/ VLR gsmSCF SGSN GGSN OSA-SCS IM-SSF CSCF SIP AS C

CS S DDoommaaiinn PPS S DDoommaaiinn SubsystemSubsystemIM CNIM CN

C D Gr Gc Sh Si Cx S6a

HSS HSS

The HSS is a centralized subscriber database that has evolved from the HLR. It is the master database for subscribers of an operator’s network. In the IMS domain, it interfaces with the I-CSCF (Interrogating Call State Control Function) and the S-CSCF (Serving Call State Control Function) to provide information about the subscriber’s location and their subscription information. A home network may contain one or several HSSs, depending on the number of mobile subscribers, the capacity of the network and its organization.

The HSS supports mobility management through the CS domain, PS domain and IM CN (IP Multimedia Core Network) subsystem. It also performs an important role in user security, generating integrity and cipher keys and subscriber authentication.

The HSS also provides appropriate user identification handling and relates all identifiers uniquely, determining a user in the system. It provides access authorization, ensuring users are allowed to roam to visited networks, and service authorization support, updating relevant entities with information related to services to be provided to users. In addition it provides access to service profile data for use within the IM CN subsystem and the PS and CS domains.

Further HSS tasks include communicating with SIP (Session Initiation Protocol) application servers and the OSA-SCS (OSA Service Capability Server) to support application services in the IM CN subsystem as well as with the IM-SSF to support CAMEL (Customized Applications for Mobile Enhanced Logic) services related to the IM CN subsystem, and with the gsmSCF (GSM Service Control Function) to support CAMEL services in the CS and PS domains.

(35)

Evolved Packet Core

Serving Gateway (S-GW) PDN Gateway (PDN-GW) Functions could be combined within same device Mobility Management Entity (MME) S5

Policy & Charging Rules Function

(PCRF)

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 MME, 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.

The PCRF is a software function that may reside in a standalone device or may be incorporated into the functionality of another device such as a PDN-GW.

(36)

2.8

LTE Evolved Packet Core Network

TAC a TAC b TAC c Single cell TA _{Single eNB} TA E-UTRAN region TA Tracking Area Tracking Area

eNBs and the cells they manage are organized into contiguous geographical units known as the TA (Tracking Area).

A TA may be as small as one cell or as large as a region of an E-UTRAN or an entire E-UTRAN, but some networks configure them to cover the set of cells generated by a single eNB. This configuration might be more likely in E-UTRANs that employ distributed cell coverage, where a central eNB manages a distributed set of remote radio heads that cover a large area. Functionally, a TA represents an area within which an idle mode UE can roam without performing a location update and within which that UE will be paged in the event of a mobile terminated transaction. Individual TAs are bound into larger, UE-specific meta units known as Tracking Area Lists to provide an enhanced level of flexibility to the tracking and paging processes.

The TAI (Tracking Area Identity) – which consists of MCC (Mobile Country Code), MNC (Mobile Network Code) and TAC (Tracking Area Code) - of the TA to which a cell belongs is advertised on each cell’s BCCH. To this extent, the TA as used in LTE is analogous to the LA (Location Area) and RA (Routing Area) as used in CS and PS mobility respectively in legacy GSM and UMTS Networks.

An individual cell may belong to one Tracking Area (per PLMN) only, although conceivably an eNB may be associated with more than one TA, if its set of supported cells extends across a TA boundary. In multi-operator E-UTRAN deployments a single eNB may be associated with up to six PLMNs. In these cases SIB 1 of the cell’s BCCH (Broadcast Control Channel) is able to broadcast a separate PLMN Identity IE (Information Element) carrying the MCC/MNC details of those networks, however, SIB 1 only has space to carry one TAC. This means that all six possible PLMNs associated with that E-UTRAN must have aligned and coordinated TA configurations. Each PLMN will continue to have its own set of TAIs as these are constructed using the network’s MCC/MNC followed by the cell’s TAC.

(37)

Evolved Packet Core

TAC 1

TAC 2

TAC 99 Tracking Area

boundary

Tracking Area List boundary

TAC 7

TAC 3

UE M-TMSI last reported TA = TA 1 TAI List for TAC1 (in PLMN 1) TAI 1, TAI 2, TAI 7 MME

TAI = PLMN ID (MCC/MNC) + TAC This example shows ‘regional’ TAs, consisting of cells belonging to multiple eNBs, other configuration options include defining TAs based on the set of cells managed by a single eNB

Tracking Area Management Tracking Area Management

The LTE TA concept incorporates an additional element, however, that is not supported in legacy systems, that of the TAI List (also known simply as TA Lists).

TAI/TA Lists are configured by an operator in their MMEs and consist of a set of adjacent TAs that, between them, form a larger contiguous area than that covered by just a single TA. Typically, the MME will be provided with datafill that shows the set of associated Tracking Areas for each individual TA and from that will compile TAI Lists based on each UE’s current location. All TAs in a TA List must be associated with the MME, TA Lists cannot span multiple MMEs. The TA List can therefore be viewed as creating a meta area that concatenates a number of TAs into a larger virtual unit. UEs are able to roam within the set of TAs without being required to perform a TAU when they move between TAs. TA Lists are assigned on a UE-by-UE basis and different UEs in the same cell may be assigned different TA Lists if the MME decides it is advantageous.

The current location of UEs in ECM-Idle mode is tracked by the MME down to the TA level. When an idle mode UE reselects to a new cell it must check the TAI of the new cell and perform a TAU if the new cell belongs to a TA that is not in the UE’s current TA List. When necessary, an MME will page for an idle mode UE in all cells belonging to the current TA List. When a UE performs a TAU, the MME will calculate a new TA List based on the TAI contained in the TAU and will pass that information back to the UE in the TAU Accept message.

One of the reasons for employing the Tracking Area List is that it allows operators to resize paging areas without needing to reconfigure any base stations. In GSM/UMTS the size of a Location Area is always a balance between the paging load on cell paging channels generated in large LAs and the level of LA Update signalling generated by small LAs. If high paging or LA Update loads are experienced it may be an indication that the network’s LAs are incorrectly sized, resulting in the operator being required to reconfigure base stations into different LAs. This would typically require careful planning and a period of downtime for each base station as it was reconfigured.

If the LTE paging or TAU load is too high operators can rebalance the sizes of paging areas by editing the TA List associated with each TA; removing TAs from a list could reduce the size of the TA List area and lower the paging load or adding TAs to a list could make the TA List area larger and therefore lower the TAU load. All of this is achieved by reconfiguring the MME and avoids the need to take any sites down to reconfigure the base stations.

(38)

2.10

LTE Evolved Packet Core Network

MME Group 1 MMEC 1 MMEC 2 MMEC 3 MMEC 4 MMEC 5 MMEC 6 MME Group 2 MMEC 1 MMEC 2 MMEC 3 MMEC 4 MMEC 5 MMEC 6

TA1, TA2, TA3

TA1

TA2

TA3

MME Pool Area = _{MME Pool Area =}

TA3, TA4

TA4

S-GW Service Area = TA1, TA2 S-GW Service Area = TA3, TA4

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 associated with an MME Pool Area, which consists of all of the eNBs in one or more complete tracking areas. MME pools (or MME Groups) are assigned unique MME Group IDs within their network and each MME in a Group is assigned an MMEC (MME Code), which is its index number within that group. MMEs that are members of multiple groups will be assigned separate MMEIs (MME Identities) by each Group.

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. Technically, a Serving Gateway Service Area consists of the set of TAs associated with an S-GW.

The S-GW selection function in the MME is invoked when a UE Attaches or when an S-GW Change is triggered and attempts to limit the possibility of further S-GW changes by ensuring that the S-GW that is selected to serve a UE is associated with a Service Area that covers all of the Tracking Areas in the UE’s current TA List.

MME pools may overlap, and each MME pool area is identified by an MMEGI (MME Group Identifier). S-GW Services Areas are typically provided with DNS-resolvable names but there is no official ‘S-GW Service Area Identifier’. S-GW Service Areas are also permitted to overlap.

(39)

Evolved Packet Core

Site/ Infrastructure Sharing

Shared sites and/or shared backhaul, separate eNBs

and EPCs Operator A CN Operator B CN RAN Sharing -each eNB broadcasts both PLMNs Shared eNBs Operator A CN Operator B CN Shared eNBs Operator A CN Operator B CN Separate core networks Separate HSS, Gateways S1-Flex selects different

MMEs per PLMN MOCN

GWCN

Shared MMEs S1-Flex selects from same pool of MMEs for all PLMNs

Network Sharing Network Sharing

The costs associated with building (CAPEX) and operating (OPEX) cellular networks have driven many operators to explore the potential methods of sharing systems with other operators.

The first stage of network sharing is often site and infrastructure sharing. In these deals, two or more operators pool their RAN resources and ensure that, where possible base stations belonging to each of them are deployed on the same sites, thus allowing them to share the costs of site acquisition/rental, power and transmission.

The next level of sharing is to implement RAN sharing, in which individual base stations are shared by operators. In 2G and 3G networks base station sharing was often implemented on the basis of ‘shared base station, separate frequencies’ with each base station generating a different set of cells per operator. LTE allows not only base station sharing but frequency sharing as well, with each eNB able to broadcast the PLMN codes of up to six operators.

RAN sharing can, in turn, be associated with two different kinds of core network sharing, known as MOCN (Multi-Operator Core Networks) and GWCN (Gateway Core Networks).

In MOCN configurations, the shared eNBs are connected to fully separate EPCs. UEs would perform PLMN Selection on Attach and the S1-flex function performed by the eNB would select an MME in the chosen PLMN to forward Attach Requests on to. MOCN configurations are also possible in 3G networks, with the RNC and Iu-flex functions replacing those of the eNB.

In GWCN configurations, the shared eNBs are connected to a set of shared MMEs, which in turn connect to a set of separate core networks. UEs would again perform PLMN selection but the eNB would perform S1-flex functions towards a single, combined set of MMEs. The MMEs would then perform separate S-GW/PDN-GW selection per PLMN and would support S6a interfaces to a different set of HSS nodes per PLMN. GWCN configurations are also possible for both 2G and 3G networks, where a shared set of MSC Servers/SGSNs replace the MMEs.

The final level of sharing is full network integration, in which both the RAN and the EPC are shared by multiple operators. Each operator could then exist as a separate ‘brand’ of the same PLMN or could each operate as a separate MVNO (Mobile Virtual Network Operator) attached to the same PLMN.

(40)

2.12

LTE Evolved Packet Core Network

PLMN – MCC+MNC

MME Group ID (MMEGI)

Tracking Area ID (TAI)

E-UTRAN Cell ID (ECGI) = eNB ID + Cell ID

EPS Area

EPS Area IdentitiesIdentities

The EPS continues to use the PLMN identifier employed by legacy 3GPP systems, which consists of the MCC and the MNC. The assignment of MCC and MNC numbers is ultimately the responsibility of the ITU (International Telecommunication Union).

The MMEGI is a 16-bit identifier assigned to an individual MME Pool. The MMEGI only has to be unique within a PLMN and is assigned by individual operators.

The TAI is analogous to the LA or RA 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 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.

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 MNC Assignments 2011 - www.itu.int/dms_pub/itu-t/opb/ sp/T-SP-E.212B-2011-PDF-E.pdf

(41)

Evolved Packet Core

Gateway names/IP addresses Access Point Name (APN)

GUMMEI MCC MNC MMEI 24 bits MMEI MMEGI MMEC 8 bits 16 bits

MCC MNC eNB ID Cell ID eCGI

20 bits 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 an MMEI (MME Identifier), which in turn consists of the MMEGI and the MMEC. 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. Examples of this naming convention could include ‘sgw6.operator. com’ or ‘hss01.region.operator.com’.

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. Example APNs could include ‘internet’, ‘mms’ or ‘ims’.

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.

(42)

2.14

LTE Evolved Packet Core Network

M MCCC C MMNNC C MMMMEEII 24 bits GUTI M-TMSI M-TMSI 32 bits M-TMSI M-TMSI 32 bits M-TMSI M-TMSI M-TMSI 32 bits MMEC MMEC 8 bits S-TMSI M MCCC C MMNNC C MMSSIINN 64 bits IMSI NAS Identities NAS 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 (MME Temporary Mobile Subscriber Identity). 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 (Temporary Mobile Subscriber Identity) use, the MME may elect to reissue the M-TMSI 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 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.

(43)

Evolved Packet Core

MSC MME MME PDN–GW PDN–GW PCRF PCRF HSS HSS 2G/3G SGSN 2G/3G SGSN SGi S5 S3 S4 S6a S7/Gx S–GW S–GW IP Services IP Services IMS IMS WLAN or WLAN or WiMAX WiMAX S2 S1-U E-UTRAN E-UTRAN E-UTRA E-UTRA UTRAN/ UTRAN/ GERAN GERAN UMTS/ UMTS/ GPRS GPRS S1-MME S12 S11 Interworking to MME Rx EIR EIR S13 Roaming PCRF S9 S8 EPS Roaming Ud S6d SGs/ Sv EPC Interfaces EPC Interfaces

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.

(44)

2.16

LTE Evolved Packet Core Network

MME

S-GW

IP Data link layer

S1–AP S1–AP SCTP Physical layer S1-MME Physical layer UDP IP Data link layer

User plane User planePDUsPDUs

GTPv1-U S1-U

S1AP (S1 Application Protocol) 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 (Radio Access Network Application Part) protocol employed in 3G networks.

(45)

Evolved Packet Core

Home or Visited Network S-GW SGSN S4 PDN-GW IP Services S5 RNC S12 S8 Home Network PDN-GW S1-U eNB L1 UDP IP L2 GTPv1-U

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 a 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. The S1 and X2 E-UTRAN user plane interfaces are also based on GTPv1-U.

(46)

2.18

LTE Evolved Packet Core Network

Home or Visited Network SGSN MME S3 S10 MME MSC Sv S-GW SGSN S11 S16 PDN-GW S5 S8 Home Network PDN-GW IP Services L1 UDP IP L2 GTPv2-C 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.

The Sv interface that interconnects an MME and a legacy MSC Server is also based on GTPv2-C. The Sv is used to manage the SRVCC feature that allows an IMS-based real time session to be handed over to a CS-capable network to continue as a legacy phone call.

(47)

Evolved Packet Core

MME HSS SGSN EIR S6a S13 S6d Ud S9 PDN–GW Visited PCRF IMS Home PCRF S7/Gx Rx L1 TCP/SCTP IP L2 Diameter Diameter-based Interfaces Diameter-based Interfaces

The S6a interface connects the MME to the HSS and allows the secure transfer of subscriber profiles 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/S16 interfaces to connect directly to the EPS HSS for mobility management and subscriber data access purposes. The S7/Gx interface connects the PCEF in 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 details from a user’s home network but they are under no obligation to enforce them if they contradict local policies.

The Ud interface logically exists between the PCRF and a UDR (User Data Repository) such as the HSS. Depending upon vendor architecture the Ud may employ legacy protocols, it may employ a protocol such as LDAP (Lightweight Directory Access Protocol) or it may employ a Diameter-based Ud protocol.

(48)

2.20

LTE Evolved Packet Core Network

PDN-GW S11 S11 S5 S5 PDN-GW S-GW S-GW S1-U S1-U S1-MME S1-MME MME MME EPS Resilience EPS Resilience

The interfaces deployed within the EPS have been designed to offer scalable flexibility to operators to allow them to maximize the opportunities to provide resilience within their core network.

The flexible S1 association between eNBs and members of the associated MME groups gives E-UTRAN elements a choice of core network nodes to contact when attempting to forward Attach messages from UEs. The S1-Flex procedures allow an eNB to employ some form of load balancing algorithm to distribute UE S1-MME connectivity amongst multiple MMEs.

Each MME can be provided with logical S11 associations to multiple S-GWs, which provides the MME with a redundant set of user plane nodes to choose from when establishing new EPS Bearers. MMEs will attempt to select an S-GW whose Service Area includes all of the TAs in each UE’s current TA List to minimize the chance of an S-GW change being required.

EPS network operators have the option to assign access points in different PDN-GWs to serve the same external network SGi connections. MMEs can then choose which PDN-GW to select when establishing a new PDN Connection. As each S-GW can support logical S5 interfaces to multiple PDN-GWs there is a further set of redundancies within the EPC.

(49)

Evolved Packet Core

MME MSC Server SGs Sv L1 SCTP IP L2 SGsAP L1 UDP IP L2 GTPv2-C Interface to CS Networks Interface to CS Networks

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 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, including the transfer of paging messages from the MSC/VLR to the MME and the exchange of SMS messages in either direction.

Other interfaces have been developed to support other forms of EPC-CS Core interaction; the Sv interface, for example, carries MME-MSC-S signalling to support the SRVCC, which allows IMS-anchored real time sessions to be seamlessly handed over between EPS Bearers and GERAN/UTRAN CS Bearers. The Sv interface is based on GTPv2-C.

LTE Evolved Packet Core Network

LTE Evolved

LTE Evolved

Packet Core Network

Packet Core Network

... del

deliv

iveri

ering know

ng knowled

ledge,

ge,

max

maximi

imizin

zing

g per

perfo

forrman

mance

ce...

www.wraycastle.com

www.wraycastle.com

LTE EVOLVED PACKET CORE

LTE EVOLVED PACKET CORE

NETWORK

NETWORK

Y

Yours to have and to hold but no

ours to have and to hold but not to copy

t to copy

LTE Evolved Packet Core Network

LTE EVOLVED PACKET CORE NETWORK

LTE EVOLVED PACKET CORE NETWORK

CONTENTS

CONTENTS

LTE Evolved Packet Core Network

LTE Evolved Packet Core Network

LTE OVERVIEW

LTE OVERVIEW

SECTION 1

SECTION 1

LTE Evolved Packet Core Network

CONTENTS

CONTENTS

LTE Overview

LTE Evolved Packet Core Network

OBJECTIVES

OBJECTIVES

LTE Overview

LTE Evolved Packet Core Network

LTE Overview

LTE Evolved Packet Core Network

LTE Overview

LTE Evolved Packet Core Network

LTE Overview

LTE Evolved Packet Core Network

LTE Overview

LTE Evolved Packet Core Network

LTE Overview

LTE Evolved Packet Core Network

EVOLVED PACKET CORE

EVOLVED PACKET CORE

LTE Evolved Packet Core Network

SECTION 2

SECTION 2

LTE Evolved Packet Core Network

CONTENTS

CONTENTS

Evolved Packet Core

CONTENTS

CONTENTS

LTE Evolved Packet Core Network

CONTENTS

CONTENTS

Evolved Packet Core

OBJECTIVES

OBJECTIVES

LTE Evolved Packet Core Network

Evolved Packet Core