EPC Signaling

AP
IS
EPS Introduction
NAS Protocols
S1AP
GTP
EPS Mobility
DNS use in EPS
Diameter
PCC
Security
10
Interworking with
GERAN/UTRAN
11
Interworking with non-3GPP

IP-acces
12
13
14
Foldouts
15
AP
I
Apis Technical Training AB

Tjrhovsgatan 21, 5th floor
SE-116 28 Stockholm
Sweden
Tel +46-8-555 105 00
Fax +46-8-555 105 99
E-mail info@apistraining.com
www.apistraining.com
EPC Signalling
AP
IS
The use of a term in this document should not be interpreted in a manner that would affect the
validity or legal status of any proprietary rights that may be attached to that term.
This is a training document and as such simplifies what are often highly complex
technological issues. The system or systems described here should therefore be seen in that
light, i. E. as simplifications rather than generalizations.
Due to ongoing progress in methodology, design, its contents are furthermore subject to
revision without prior notice.
Apis Technical Training AB assumes no legal responsibility for any error or damage resulting
from the use of this document.
Copyright Apis Technical Training AB 2013. All rights are reserved.
This training material is the confidential and proprietary property of Apis Technical Training
AB. It is to be used solely for the purpose for which it was produced and is not to be copied or
otherwise reproduced without the prior written permission of Apis Technical Training AB.
To our best knowledge, the information in this document is accurate as per
the date of publication.
Other than by prior written agreement, Apis Technical Training AB will not update or
otherwise advise of errors in the document which may be brought to our attention.
All trademarks are trademarks of their respective owners.
Apis Technical Training AB. welcomes customer feedback as part of a process of ongoing
development of our documentation in order to better meet our customers' needs. Please
submit your comments to our Head Office in Stockholm.
AP
I
Apis Technical Training AB

th
Tjrhovsgatan 21, 5 floor
SE-116 28 Stockholm
Sweden
E-mail: info@apistraining.com
AP
IS
EPS Introduction
BACKGROUND .................................................................................. 1-2
1.1.1
Long Term Evolution (LTE) ...................................................... 1-2
1.1.2
System Architecture Evolution (SAE) ...................................... 1-2
1.2
EVOLVED UTRA & E-UTRAN........................................................... 1-3
1.2.1
Network Architecture ................................................................ 1-3
1.2.2
Requirements on E-UTRA/E-UTRAN ...................................... 1-3
1.2.3
Overview of Technical Solutions .............................................. 1-4
1.3
EVOLVED PACKET CORE ................................................................... 1-6
1.3.1
Network Architecture ................................................................ 1-6
1.3.2
Requirements on the EPC ....................................................... 1-7
1.4
SOME BASIC EPS PROCEDURES AND TERMINOLOGY.......................... 1-7
1.4.1
Network Attach and PDN Connection Setup ........................... 1-7
1.4.2
EPS Bearers ............................................................................ 1-8
1.4.3
QoS and Policy Control ............................................................ 1-8
REFERENCES ................................................................................... 1-8
1.5
EPS Overview
Copyright Apis Technical Training AB 2013. All rights reserved.
1-1
AP
I
1.1
AP
IS
1.1
Background
1.1.1
Long Term Evolution (LTE)

3GPP Long Term Evolution (LTE) originally was the name given to a project within the
Third Generation Partnership Project (3GPP) to improve the UMTS 3G mobile system
standard to cope with future requirements. Goals included improving efficiency, lowering
costs, reducing complexity, improving services, making use of new spectrum
opportunities and better integration with other open standards (such as WLAN and
WiMAX). The outcome from the LTE project is a set of standards defining the
functionality and requirements of an evolved, packet based, radio access network and a
new radio access. The new radio access network is referred to as the Evolved UTRAN
(E-UTRAN) and the new radio access is referred to as the Evolved UTRA (E-UTRA).
The LTE project was part of 3GPP Release 8, with added features and functionality in
Releases 9, 10 and 11.
However, the term LTE has become more or less synonymous to the (proper) terms
Evolved UTRA (the new radio access) and Evolved UTRAN (the new radio access
network). With this in mind, the author has taken the freedom to use the terms LTE and
E-UTRA interchangeably for the new OFDM-based radio interface. In fact, when
people talk about LTE, they may even include also to the Evolved Packet Core (EPC).
So in effect LTE is sometimes used as a synonym to the entire Evolved Packet System
(EPS).
The work on LTE started with a workshop in Nov 2004 in Toronto, Canada. A set of high
level requirements were initially identified:
Reduced cost per transmitted bit
More services at lower cost with better user experience
Flexibility of use of existing and new frequency bands
Simplified architecture, open interfaces
Reasonable terminal power consumption.
It was also agreed that the E-UTRA/E-UTRAN standard should bring significant
improvements to justify the standardization effort and that it should avoid unnecessary
options (i.e. reduced overall complexity as compared to UMTS).
A feasibility study on the UTRA & UTRAN Long Term Evolution was then started in
December 2004. The objective was "to develop a framework for the evolution of the
3GPP radio access technology towards a high data rate, low latency and packet optimized
radio access technology". The study focused on supporting services exclusively from the
Packet Switched (PS) domain.
System Architecture Evolution (SAE)

In parallel to, and coordinated with, the LTE project there was also a 3GPP
standardisation project relating to the core network. It was called System Architecture
Evolution (SAE) and aimed at standardising the new Evolved Packet Core (EPC). The
SAE project was started in December 2004, with the objective to develop a framework
for an evolution or migration of the 3GPP system to a higher data rate, lower latency,
packet optimized system that supports multiple RATs.
EPS Overview
1-2
AP
I
The EPC is a fully IP-based core network (all-IP) supporting access not only via
GERAN, UTRAN and E-UTRAN but also via WiFi, WiMAX and wired technologies
such as xDSL. The SAE project is also a part of 3GPP Release 8 with
additions/developments in later releases.
1.1.2
AP
IS
Evolved UTRA & E-UTRAN
1.2.1
Network Architecture
Uu
S 1 -M M E
X 2 -C
S6a
MME
eN B
X 2 -U
HSS
S11
PCRF
Gx
Uu
S 1 -U
eN B
E -U T R A
S5
SGW
E -U T R A N
Rx
SG i
PGW
IM S /In te rn e t/
EPC
The Evolved Packet System (EPS), simplified

The Evolved UTRAN consists of the evolved NodeB (eNB), providing the E-UTRA User
Plane (UP) and Control Plane (CP) protocol terminations towards the UE. From a
functionality point of view, the eNB can be seen as a combination of the UMTS NodeB
and Radio Network Controller, hosting functions like dynamic resource allocation
(through packet scheduling) and radio resource management.
The eNBs are (optionally) interconnected via the X2-interface, e.g. for support of
handovers without data loss. The X2-interface consists of a User Plane instance (X2-U)
and a Control Plane instance (CP).
The eNBs are connected to the EPC via the S1-interface. The S1-interface supports a
many-to-many relation between eNBs and MME/SGWs and is (logically) divided into a
UP instance (S1-U) and a CP instance (S1-MME).
At the onset of the LTE project a series of requirement targets relating to performance,
complexity and interworking were defined. Some of these are listed below:
Peak data rate: at least 100 Mb/s DL and 50 Mb/s UL (assuming 20 MHz
system bandwidth). Benchmarking targets for data rates is set to 3-4 times those
of HSPA as of R6 (5 MHz bandwidth).
Control Plane (CP) latency: transition time less than 100 ms from an idle state
to an active state, and less than 50 ms between a dormant state (such as R6
CELL_PCH) and an active state.
User Plane (UP) latency: less than 5 ms in unloaded condition (single user with
single data stream) for small IP packet.
CP capacity: at least 200 users per cell should be supported in the active state (5
MHz system bandwidth).
Mobility: E-UTRAN should be optimized for low mobile speed (0-15 km/h) and
higher speeds (15-120 km/h) should be supported with high performance.
Mobility shall be maintained between 120-350 km/h (up to 500 km/h depending
on the frequency band).
Coverage: the throughput and mobility targets above should be met for 5 km
cells with a slight degradation for 30 km cells. Cells range up to 100 km should
be possible.
Spectrum flexibility: E-UTRA shall operate in different spectrum allocations of
different sizes, including 1.4, 3, 5, 10, 15 and 20 MHz in both UL and DL.
Operation in paired (FDD) and unpaired (TDD) spectrum shall be supported.
EPS Overview
1-3
Requirements on E-UTRA/E-UTRAN
AP
I
1.2.2
1.2
AP
IS
Interworking: co-existence in the same geographical area and co-location with

GERAN/UTRAN on adjacent channels. E-UTRAN terminals supporting also
UTRAN/GERAN operation should be able to support measurement of, and
handover from/to, both UTRAN and GERAN. The interruption time during a
handover of real-time services between E-UTRAN and UTRAN/GERAN should
be less than 300ms.
Architecture: the E-UTRAN architecture shall be packet based, supporting realtime and conversational class traffic. The architecture shall minimize the
presence of "single points of failure".
Complexity: minimised number of options and avoidance of redundant
mandatory features.
Overview of Technical Solutions

The E-UTRA radio interface makes exclusive use of shared channels for both user data
and signalling transfer. In this respect the E-UTRA is similar to the 3GPP High Speed
Packet Access, HSPA. The selected radio access technology, however, is very different to
HSPA. Where HSPA uses WCDMA, the E-UTRA uses Orthogonal Frequency Division
Multiplexing (OFDM).
OFDM splits the available system bandwidth into hundreds, or even thousands, of
narrow-band so-called sub-carriers. This means that a high bitrate data stream to a given
UE is split by the eNB into a large number of narrow-band, low bitrate, data streams. The
received parallel data streams (sub-carriers) are then de-multiplexed by the UE in order
to re-create the original high bitrate data stream. This has some advantages over
WCDMA:
Better spectral efficieny. More information can be sent using the same system
bandwidth as compared to a single-carrier system.
Flexible/scalable spectrum allocation. The system bandwidth can be expanded
in increments (by adding more sub-carriers) as more spectrum becomes
available to the operator. For example, the initial system roll-out may use a
system bandwidth of 1.4 MHz and at a later stage this may be increased to, say,
5 MHz.
Better performance under multipath fading conditions. Multipath effects leads
to so-called frequency selective fading, which is much more damaging to a
wideband signal than to a narrowband signal (the sub-carrier).
There are, of course, drawbacks with OFDM as well. One such drawback is that an
OFDM signal exhibits a very high peak-to-average power ratio (PAPR). This is not really
a problem on the network side, but leads to inefficient use of power amplifiers, and hence
high power consumption, in a mobile terminal. The E-UTRA system therefore uses a
variant of OFDM for uplink transmission that reduces PAPR. This variant of OFDM is
called Single-Carrier Frequency Division Multiple Access (SC-FDMA). Despite the
name, there is very little that differentiates SC-FDMA from classic OFDM.
EPS Overview
1-4
AP
I
The LTE physical layer specifications are written in such a way that it does not really
matter on what physical carrier frequency the system is deployed. The LTE frequency
bands in 3GPP Release 11 are listed in the table below.
1.2.3
AP
IS
E-UTRA band
Uplink (MHz)
Downlink (MHz)
Mode
1
2
3
4
5
61
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
...
23
24
25
...
33
34
35
36
37
38
39
40
41
42
43
1920 1980
1850 - 1910
1710 - 1785
1710 - 1755
824 - 849
830 - 840
2500 - 2570
880 - 915
1749.9 1784.9
1710 - 1770
1427.9 1447.9
699 - 716
777 - 787
788 - 798
Reserved
Reserved
704 -716
815 830
830 845
832 -862
1447.9 1462.9
2110 2170
1930 - 1990
1805 - 1880
2110 - 2155
869 - 894
875 -885
2620 - 2690
925 - 960
1844.9 1879.9
2110 - 2170
1475.9 - 1495.9
729 746
746 -756
758 -768
Reserved
Reserved
734 -746
860 -875
875 -890
791 -821
1495.9 -1510.9
FDD
FDD
FDD
FDD
FDD
FDD
FDD
FDD
FDD
FDD
FDD
FDD
FDD
FDD
FDD
FDD
FDD
FDD
FDD
FDD
FDD
2000 -2020
1626.5 1660.5
1850 -1915
2180 -2200
1525 1559
1930 -1995
FDD
FDD
FDD
1900 1920
2010 -2025
1850 -1910
1930 - 1990
1910 -1930
2570 -2620
1880 - 1920
2300 - 2400
2496 2690
3400 3600
3600 - 3800
1900 1920
2010 - 2025
1850 - 1910
1930 - 1990
1910 - 1930
2570 - 2620
1880 - 1920
2300 - 2400
2496 2690
3400 - 3600
3600 - 3800
TDD
TDD
TDD
TDD
TDD
TDD
TDD
TDD
TDD
TDD
TDD
No te 1 : Ban d 6 i s no t a pp li ca bl e
LTE (E-UTRA) frequency bands

The use of Multiple Input Multiple Output antenna arrays (MIMO) is an integral part of
the E-UTRA standard. The standard supports up to four transmit/receive antennas while
the expected baseline configuration is two transmit antennas at the eNB and two receive
antennas at the UE. In short, MIMO can be used in two different ways:
To transmit more information over the radio interface without using more
bandwidth than a single antenna system. The number of antennas used increases
the system capacity in a linear manner, i.e. two antennas allows twice the
amount of information to be transmitted (or, equivalently, the bitrate is doubled).
To transmit the same information, with the same bitrate as a single antenna
system, but with less output power (or higher reliability).
The E-UTRA physical layer channel processing chain (channel coding and modulation) is
very similar to what is used today for HSPA. It was agreed at an early stage in the
standardisation process that Turbo coding should be used for error correction purposes
and that the supported data modulation schemes should be QPSK, 16QAM, and 64QAM
for downlink and uplink.
The mapping of modulation symbols onto physical channel resources is very different
compared to HSPA though. The nature of OFDM gives rise to the concept of 2dimensional radio resources. The information to be transmitted over the radio interface is
mapped onto a 2-dimensional time-frequency resource grid.
EPS Overview
1-5
AP
I
(A common misunderstanding is that OFDM, by itself, makes very high bit rates possible.
This is not true. Rather, the very high bit rates mentioned for E-UTRA are made possible
first and foremost by a higher transmission bandwidth (up to 20MHz), higher order
modulation (64QAM) and the support for MIMO with up to four antennas).
AP
IS
The channel and protocol architecture for E-UTRAN layer 2 and layer 3 is quite similar to
the one used in UTRAN today. For example, the UE protocol stack is almost identical and
the channel hierarchy is still divided into logical, transport and physical channels.
1.3
Evolved Packet Core
1.3.1
Network Architecture
UTRAN
Iu -P S
SGSN
G b /Iu
GERAN
Gr
S3
HSS
S4
S12
SPR
S6a
OCS
S 1 -M M E
MME
S 1 -U
S10
Gy
O FCS
S11
Gz
X 2 -C
E -U T R A N
Sp
PCRF
Gx
Rx
SGi
S5
SGW
IM S / In te rn e t /
PGW
X 2 -U
S2b
T ru ste d
IP a cce ss
S6b
S2a
ePDG
SW m
HSS/
AAA
SW n
N o n -tru ste d
IP a cce ss
The Evolved Packet System (EPS)

The figure above shows the network architecture of the Evolved Packet Core (EPC). The
EPC consists of three main nodes: the Mobility Management Entity (MME), the Serving
Gateway (SGW) and the Packet Data Network Gateway (PGW). The MME may be colocated with the SGW, and the SGW may be co-located with the PGW. Hence, the
standard allows a completely collapsed one-node core network or a distributed (easily
scalable) core network, or any possible combination in-between.
The MME connects to the E-UTRAN via the S1-MME interface and is present solely in
the CP. It is responsible for handling mobility and security procedures such as network
attach, tracking area updates (similar to location/routing area updates) and authentication.
The MME also connects to the legacy SGSN via the S3-interface and to the SGW via the
S11-interface. These interfaces are used for signalling related to user mobility and UP
Bearer management.
The SGW connects to the E-UTRAN via the S1-U interface and is present solely in the
UP. Its prime responsibility is routing and forwarding of user IP-packets. It acts as a UP
anchor when the UE moves between different 3GPP radio access technologies (via the
S4-interface). The S12-interface is used for data transfer if the direct tunnel solution is
supported in UTRAN.
The PGW connects to the SGW via the S5-interface (or S8 in case the gateways are in
different PLMNs) and to external packet data networks (PDNs) via the SGi-interface. It is
responsible for the enforcing of QoS and charging policies. It also acts as a UP anchor
when the UE moves between 3GPP and non-3GPP radio access (S2-interfaces).
EPS Overview
1-6
AP
I
Additional network nodes/functions, some shown in the figure above, may be present as
well. For example, an evolved Packet Data Gateway (ePDG) is needed for non-trusted IP
access and a Policy and Charging Rules Function (PCRF) is required for IMS controlled
The Home Subscriber Server (HSS) holds subscription profiles and security related
parameters. Additional subscription/security databases may also be present, such as the
Subscription Profile Repository (SPR) and the 'triple-A' server (AAA, short for
Authentication, Authorization and Accounting).
AP
IS
QoS and charging mechanisms. For the purpose of charging there is typically also the
Online Charging System (OCS) and/or Offline Charging System (OFCS).
1.3.2
Requirements on the EPC

A (rather long) list of general requirements was set up as guidelines for the
standardisation work related to the EPC. Some of those are:
3GPP and non-3GPP access systems shall be supported.
Scalable system architecture and solutions without compromising the system
capacity (e.g. by separating CP from UP).
CP response time shall be such that the UE can move from an idle state to one
where it is sending/receiving data in less than 200 ms.
Basic IP connectivity is established during the initial access phase (hence, the
UE is always-on).
The Mobility Management (MM) solution shall be able to accommodate
terminals with different mobility requirements (fixed, nomadic and mobile
terminals).
The MM functionality shall allow the network operator to control the type of
access system being used by a subscriber.
MM procedures shall provide seamless operation of both real-time (e.g. VoIP)
and non real-time applications.
In order to maximise users' access opportunities, the architecture should allow a
UE that is roaming to use a non-3GPP access (e.g. WLAN. For example, it
should be possible for a user to use a WLAN access network with which only the
visited operator has a direct relationship (not the home operator).
The evolved system shall support Ipv4 and Ipv6 connectivity.
Access to the evolved system shall be possible with R99 USIM. (Please note that
this also dis-allows access using SIM)
The authentication framework should be independent from the used access
network technology.
The SAE/LTE system shall support network-sharing functionality.
It shall be possible to support service continuity between IMS over LTE/SAE
access and the Circuit Switched (CS) domain.
It shall be possible for the operator to provide the UE with access network
information pertaining to locally supported 3GPP and non-3GPP access
technologies.
1.4
Some basic EPS Procedures and

Terminology
1.4.1
Network Attach and PDN Connection Setup

One of the fundamental ideas with EPS is the always connected concept. This means
that when a UE is switched on and registers in the network, it shall also become
connected to an external Packet Data Network (PDN).
The registration in the MME is done by means of the Attach Procedure. It is initiated by
the UE, and during this procedure the UE (and network) is authenticated and subscriber
data is downloaded from the HSS to the MME.
EPS Overview
1-7
AP
I
The PDN Connection Setup Procedure is coordinated with Network Attach. In this
procedure, the UE gets an IP-address from the PGW and the first EPS Bearer is setup to
allow the UE to send and receive IP-packets. In EPS, the Attach and PDN Connection
Setup procedure are always coordinated! This is in contrast to how things are dome in
GPRS/UMTS, where Attach and PDP Context Activation is defined as two separate,
independent procedures.
AP
IS
EPS Bearers
The connection or path or pipe that allows a UE to send and receive IP-packets is
called an EPS Bearer. The first EPS Bearer that is set up between a UE and a PDN is
called the Default EPS Bearer. The Default EPS Bearer has a QoS-profile which is part
of the subscriber data. However, the Default EPS Bearer never has a Guaranteed Bit Rate
(GBR), which from a bit rate point of view the Default Bearer is best-effort. The
Default Bearer is used for IP-Connectivity between the UE and the external PDN. The
Default Bearer remains until the UE de-registers from the network and the PDN
Connection is released.
For services that require a Guaranteed Bit Rate, or in some other way a different QoSprofile, additional bearers need to be setup. They are referred to as Dedicated EPS
Bearers. A Dedicated Bearer is set up for some specific purpose e.g. an IP-TV session or
VoIP-call. When the Dedicated Bearer is not needed anymore, it is released.
1.4.3
QoS and Policy Control

Each EPS Bearer has a QoS-profile. The high-level QoS parameters for an EPS Bearer
are:
Guaranteed Bit Rate, GBR (which may be zero)
Maximum Bit Rate, MBR
Allocation and Retention Priority, ARP
Quality if Service Class Identifier, QCI
The QCI is an integer (a number) which is a reference to e.g. delay requirements and
packet loss tolerance.
The QoS-profile for the Default EPS Bearer is part of the subscriber data that is stored in
the HSS and downloaded to the MME when a subscriber registers.
The QoS profile for a Dedicated Bearer is set up (authorized and enforced) based on who
the subscriber is and what the subscriber wants to do.
For Policy (and Charging) Control, the Policy and Charging Rules Function (PCRF)
creates so called PCC Rules with authorized Bearer QoS parameters and sends these rules
to the PGW. The Policy and Charging Enforcement Function (PCEF) that resides inside
the PGW, then makes sure that the QoS-profile for a Bearer is not violated (e.g. that the
MBR is not exceeded).
References
GPRS enhancements for Long Term Evolution (LTE)
3GPP SAE: Architecture enhancements for non-3GPP accesses
E-UTRA/E-UTRAN; overall description; Stage 2
Policy and Charging Control architecture
23.401
23.402
36.300
23.203
EPS Overview
1-8
AP
I
1.5
1.4.2
AP
IS
NAS Protocols
NAS INTRODUCTION ......................................................................... 2-2
2.1.1
NAS Functionality..................................................................... 2-2
2.1.2
NAS Area Concepts ................................................................. 2-2
2.2
NAS SIGNALLING PROCEDURES........................................................ 2-3
2.2.1
EMM Procedures ..................................................................... 2-3
2.2.2
ESM Procedures ...................................................................... 2-4
2.2.3
NAS States and State Transitions ........................................... 2-5
NAS MESSAGE FORMATS ................................................................. 2-6
2.4
REFERENCES ................................................................................... 2-7
2.3
NAS Protocols
2-1
AP
I
2.1
AP
IS
2.1
NAS Introduction
UE
MME
NAS
NAS
eNB
RRC
RRC
PDCP
PDCP
R LC
R LC
MAC
PHY
Uu
S1AP
S1AP
SCTP
SCTP
MAC
IP
IP
PHY
L 1 /L 2
L 1 /L 2
S 1 -M M E
NAS protocol stack
2.1.1
NAS Functionality
The Non Access Stratum (NAS) protocols are used for signalling between the UE and the
Mobility Management Entity (MME) in the EPC. The term Non Access refers to the fact
that NAS signalling has nothing to do with radio access network specific matters, e.g.
radio resources. As can be seen in the figure above, all NAS signalling exchange takes
place transparently through the radio access network (i.e. the eNB will never read and
interpret these messages).
The NAS layer sits on top of the RRC layer in the UE and the S1AP layer in the MME.
All NAS messages are therefore carried inside, or sent concatenated with, RRC and S1AP
messages when transmitted over the radio interface and S1-MME interface respectively.
In EPS, there are only two NAS protocols defined: the EPS Mobility Management
protocol (EMM) and the EPS Session Management protocol (ESM). The EMM protocol
handles signalling related to UE mobility and various security procedures. The ESM
protocol handles signalling related to management of default and dedicated bearers for
transport of user data.
The functionality of both protocols is similar to the corresponding GSM/UMTS NAS
protocols. The EMM protocol is modelled on the GPRS Mobility Management protocol
(GMM) and the ESM protocol is modelled on the Session Management protocol (SM).
NAS Area Concepts
NAS Protocols
2-2
AP
I
The NAS layer makes use of so-called Tracking Areas (TA) for mobility management
purposes. The concept of a Tracking Area is in principle the same as the GSM/UMTS
concept of a Routing Area (or Location Area). Hence, the TA is an operator defined
group of cells that all belong to the area served by one MME. One or more TA may be
handled by each MME. The MME is aware of the location of an attached UE on TA-level
through the TA Update procedure. The TA is typically, but not necessarily, the area inside
which the UE is paged for incoming calls/data.
2.1.2
AP
IS
MME pool areas

The EPC uses the IMSI number as the permanent user identifier (or rather, USIM
identifier). As in the legacy Core Network, a temporary identifier is also used for
subscriber identity confidentiality reasons in place of the IMSI whenever possible. The
temporary identifier in the EPS is called the Globally Unique Temporary Identity
(GUTI).
The GUTI is allocated when the UE performs initial registration (i.e. Attach) with an
MME. The GUTI is then typically changed whenever the UE performs some EMMprocedure, such as TA Update. The S-TMSI is a shortened version of the GUTI that
uniquely identifies the user within an MME Group (the 'S' is just a label and is not an
abbreviation for anything). The shorter S-TMSI, rather than the complete GUTI, is used
within most NAS messages.
2.2
NAS Signalling Procedures
2.2.1
EMM Procedures
The EMM procedures are divided into three groups:
Common
Specific
Connection Management
The Common procedures relate to security functions and are listed below.
Authentication: user (USIM) authentication and NAS key agreement. The
procedure uses EPS Authentication Vectors (similar to UMTS quintets).
Security Mode Control (SMC): initiation of and control of the NAS
ciphering and integrity protection functions.
GUTI Re-allocation: provision of a new GUTI to the UE.
Identification: allows the MME to request either IMSI or IMEI from the
UE when needed.
NAS Protocols
2-3
AP
I
The Specific procedures relate to registration/de-registration functions.
AP
IS
Attach: initial registration of the UE in one MME. The attach procedure is

always combined with ESM signalling to establish basic IP-connectivity
(using a 'default bearer'). The attach procedure may also be combined with
IMSI Attach, whereby the UE also becomes registered in the legacy MSC
Server (this is to support the 'CS Fallback' feature).
Detach: de-registration from the network. May be performed as a
combined detach, whereby the UE becomes de-registered for EPS services
and/or non-EPS services (i.e. IMSI Detach).
Tracking Area Update (TAU): performed when the UE enters a TA not
currently in its stored list of TAIs (normal TAU) or at timer expiry
(periodic TAU). May also be a combined update, whereby the UE also
performs a Location Area Update towards the MSC Server.
The Connection Management procedures are used for mobile terminating or mobile
originating connection management and will always trigger ESM protocol procedures (for
the actual call/session setup signalling).
Paging: used when the UE is in Idle mode and the network has downlink
data or signalling pending. The UE responds by initiating the Service
Request procedure (there is no explicit 'paging response' message defined).
Service Request (SR): used when the UE is in Idle or Connected mode and
has uplink data or signalling pending. The network responds by initiating
the Authentication and/or SMC (Security Mode Control) procedure.
ESM Procedures
The ESM procedures are divided into two groups: Network Initated procedures and UE
Initiated procedures. The Network Initiated procedures are used for establishment,
modification or release of default or dedicated EPS bearers and are listed below.
Default EPS Bearer Context Activation: provides the UE with basic IPconnectivity (a default bearer) to a given external Packet Data Network
(PDN). The first default bearer is always established in conjunction with
the Attach procedure. Subsequent default bearers, to other PDNs, are
established when needed.
Dedicated EPS Bearer Context Activation: provides the UE with a bearer
associated with a certain specified QoS (Quality of Service) which is
typically higher than QoS for the default bearer.
EPS Bearer Context Modification: used by the network to modify a given
bearer.
EPS Bearer Context Deactivation: used by the network to release a given
dedicated or default bearer. To release a default bearer is the same as to
disconnect from the associated PDN. When the last default bearer is
released the UE enters the detached state.
NAS Protocols
2-4
AP
I
UE Requested PDN Connection: request for basic IP-connectivity (a

default bearer) to a given external Packet Data Network (PDN). The first
default bearer is always requested in conjunction with the Attach
procedure. Subsequent default bearers, to other PDNs, are requested when
needed. This procedure always triggers the network initiated Default EPS
Bearer Context Activation procedure:
The UE Initiated procedures are used for establishment, modification or release of default
or dedicated EPS bearers.
2.2.2
AP
IS
UE Requested PDN Disconnection: used by the UE to disconnect from a

given PDN.
UE Requested Bearer Resource Allocation: used by the UE to request a
dedicated bearer associated with a certain QoS. This procedure triggers
either the Default EPS Bearer Context Activation procedure or the EPS
Bearer Context Modification procedure.
UE Requested Bearer Resource Release: used by the UE to release a
dedicated bearer.
NAS States and State Transitions

The NAS States for a UE specifies the relationship between the UE and the EPC. Is the
UE e.g. registered or not, can the UE do immediate signalling or data transfer?
There are separate (but mutually dependent) protocol state machines for the EMM
protocol and the ESM protocol.
The EMM protocol state machine relates to whether the UE is properly registered in the
network or not and whether there exists an active NAS Signalling Connection between the
UE and MME or not. A NAS Signalling Connection is UE specific and is required for any
exchange of NAS messages, with the exception of the very messages that triggers the
establishment of the NAS Signalling Connection itself (e.g. Attach Request or Paging).
The EMM protocol state machine contains two sets of states: EMM states and ECM states
(EPS Connection Management). The UE is either EMM Registered or EMM
Deregistered, i.e. attached or not. The ECM states are only relevant in the EMM
Registered state and reflect whether there is an active NAS Signalling Connection
established (ECM Connected) or not (ECM Idle).
The ESM protocol state machine deals exclusively with the existence (or not) of EPS
bearers.
NAS Protocols
2-5
AP
I
NAS states
2.2.3
AP
IS
The ESM states are quite straightforward: when at least one (default) bearer is established
the UE is in the ESM Active state, otherwise it is in the ESM Inactive state. The ESM
signalling needed to establish a bearer requires that the UE is properly registered in the
network. It therefore naturally follows that the UE must be in the EMM Registered state
whenever it is ESM Active.
It also follows that there must be a NAS Signalling Connection present during the ESM
signalling phase when a bearer is being established, i.e. the UE is then ECM Connected.
However, there is no requirement to keep the NAS Signalling Connection active for the
lifetime of an EPS bearer. Hence, the UE may very well be ECM Idle while being ESM
Active. This makes sense, since the UE may be continuously attached for days, weeks or
even months. All the time a default bearer will be active, but there may be long silent
periods with no NAS signalling and user data transfer.
The NAS states (MME related states) are aligned with the RRC states in E-UTRAN. A
UE in RRC Idle state is, from the MMEs point of view, in the NAS state ECM Idle.
Paging or a request from higher layers to transmit uplink data or signalling will cause a
transition from RRC Idle to RRC Connected, causing also a transition from ECM Idle to
ECM Connected. This is however not shown in figure above.
NAS Message Formats

The NAS messages have different format depending on if it is an EMM message or an
ESM message and also on whether the message is security protected or not. All NAS
messages are octet-aligned.
All EMM messages except Service Request, which has a special format, consist of a
Protocol Discriminator, a Security Header Type field, a Message Type field and zero, one
or more additional Information Elements (IEs, or payload 'parameters').
All ESM messages consist of a Protocol Discriminator, an EPS Bearer Id field, a
Procedure Transaction Id, Message Type field and zero, one or more additional IE.
Any security protected NAS message also contains a security header appended at the
beginning of the message. The security header consists of a Protocol Discriminator, a
Security Header Type field, a NAS Sequence Number field and a Message Authentication
Code field.
E M M M essage
8
S e c u rity H e a d e r T y p e
E S M M essage
3
P ro to c o l D is c rim in a to r
E P S B e a re r Id
M essage Type
P ro c e d u re T ra n s a c tio n Id
M essage Type
O th e r In fo rm a tio n E lem e n ts
(M a n d /O p t/C o n d )
O th e r In fo rm a tio n E lem e n ts
(M a n d /O p t/C o n d )
S ecurity H eader
8
S e c u rity H e a d e r T y p e
M essage
A u th e n tic a tio n
C o d e (4 o ct)
NAS Protocols
2-6
AP
I
NAS message format
N A S Sequence N um ber
2.3
AP
IS
Protocol Discriminator (PD). The PD identifies the NAS protocol (EMM or ESM) to
which the message belongs. The PD is defined in TS 24.007 and shares the same value
space as the GSM/UMTS NAS protocols.
Security Header Type (SHT). The SHT indicates the presence or not of a security header,
i.e. whether the message is security protected or not.
Message Type (MT). The MT identifies a message (e.g. 'Attach Request').
EPS Bearer Id (EBI). The EBI field specifies the EPS bearer to which the message
pertains. Implicitly it also specifies the specific ESM protocol instance to which the
message is addressed (there is one ESM protocol entity active per EPS bearer).
Procedure Transaction Id (PTI). The PTI allows distinguishing between different
parallel bi-directional ESM message flows (or 'transactions'). The PTI also links a
'request' message with its 'response' message for a given transaction.
Message Authentication Code (MAC). The MAC field is the output from the NAS
integrity protection algorithm and is used in the receiver for checking the integrity of the
message.
NAS Sequence Number (SN). The SN field is used as input to the NAS ciphering and
integrity protection algorithms.
References
GPRS enhancements for E-UTRAN
Mobile radio interface layer 3; general aspects
Non-Access Stratum (NAS) protocol for EPS
3GPP System Architecture Evolution: security architecture
NAS Protocols
2-7
AP
I
23.401
24.007
24.301
33.401
2.4
AP
IS
S1AP S1 Application
Protocol
S1AP INTRODUCTION ....................................................................... 3-2
3.2
S1-MME CONNECTION AND S1 CONNECTION.................................... 3-2
3.3
S1AP PROCEDURES ........................................................................ 3-3
3.4
SCTP AND TRANSPORT PROTOCOLS ................................................ 3-4
3.5
REFERENCES ................................................................................... 3-5
S1AP
3-1
AP
I
3.1
AP
IS
3.1
S1AP Introduction
The S1-interface connects E-UTRAN (eNBs) with the EPC. The S1-interface is an IPbased interface and can therefore be seen as a point to multi-point interface. The Control
Plane (CP) instance of the S1-interface (S1-MME) uses the S1 Application Protocol
(S1AP) for control signalling purposes between the eNB and the MME. The S1AP
protocol runs on top of the Stream Control Transmission Protocol (SCTP).
For more clarity, the figure below also shows the GPRS Tunnelling Protocol (GTP) The
User Plane (UP) instance of the S1-interface (S1-U) uses GTP User plane (GTP-U) for
user data tunnelling. The termination point on the EPC side for S1-U is the Serving
Gateway, SGW.
eNB
MME
SGW
S1A P
S1A P
G T P -C
G T P -C
SCTP
SCTP
UDP
UDP
IP
IP
IP
IP
L 1 /L 2
L 1 /L 2
L 1 /L 2
L 1 /L 2
S 1 -M M E
S11
eNB
SGW
G T P -U
G T P -U
UDP
UDP
IP
IP
L 1 /L 2
L 1 /L 2
S 1 -U
S1 and S11 protocol stacks
The S11-interface is, like the S1-interface, an IP-based point to multi-point interface. The
S11-interface is used for signalling between the MME and the SGW and does not have a
UP instance. The S11-interface uses GTP Control plane (GTP-C) for control signalling
purposes. For more about GTP refer to chapter 4.
S1-MME Connection and S1 Connection
S1AP
3-2
AP
I
The EPS is an all-IP network. This means not only that services are IP-based, but also that
all nodes have IP-addresses and are connected via IP transport. This means that (in
principle) everything is connected to everything else.
3.2
AP
IS
Between an eNB and an MME that are configured to work together there is a so called
S1-MME Connection. This can be viewed as a logical link that allow the eNB and
MME to exchange S1AP signalling. The S1-MME connection is configured, i.e. set up
manually or by the nodes themselves (in case of Self Organizing Networks, SON).
All UE associated signalling takes place over a logical S1 Connection. The UE-specific
S1 Connection is identified in each node with an S1AP UE Identifier. Thus, all S1AP
messages pertaining to a specific UE will carry two reference numbers: the S1AP UE Id
selected by the eNB and the S1AP UE Id selected by the MME. One such pair of
reference numbers uniquely identifies a UE context in a node.
S1AP Procedures
In the S1AP Specification (36.413) the S1 procedures are divided into the following
groups:
E-RAB management
Context management
Handover Signalling
Paging
NAS transport
Node management
CDMA 2000 tunneling
UE Capability information
Trace procedures
Location Reporting
Warning Message transmission
eNB direct information transfer
MME direct information transfer
eNB configuration transfer
MME configuration transfer
LPPa transport
The text below describes some selected fundamental procedures. For a full description,
refer to 36.413.
EPS Radio Access Bearer (E-RAB) Management

Procedures
The EPS Bearer management procedures are responsible for establishing, modifying and
releasing E-UTRAN resources for user data transport with a given QoS (once an initial
UE context is available in the eNB). The procedures are initiated from the MME, with the
exception of EPS Bearer Release that may be initiated from the eNB.
Context Management Procedures

Initial Context Setup. This procedure supports the establishment of the necessary initial
UE Context in the eNB. The UE Context includes: EPS Bearer context, security context,
roaming restriction, UE capability info, subscriber type info etc. The procedure is
always initiated from the MME, typically in combination with network registration
(Attach or TA Update). The logical S1 Connection is established after successful
execution of this procedure.
S1AP
3-3
AP
I
UE Context Release. The purpose of this procedure is to release the logical S1

Connection related to a specific UE (thus also releasing the associated UE context). The
UE Context Modification. The purpose of this procedure is to modify an already

established UE context in the eNB (e.g. change the eNB security key). The procedure is
always initiated from the MME.
3.3
AP
IS
procedure may be initiated from the MME (e.g. due to completed NAS signalling
transaction) or from the eNB (due to handover, timer expiry or other radio related reason).
Handover Procedures
Handover preparation and execution signalling over the S1-interface is only needed
during inter-RAT handover or when there is no X2-interface present between the Source
eNB and the Target eNB.
For a normal X2-interface initiated inter-eNB handover a S1AP Handover Notification
message is sent from the Target eNB to the MME after the UE has been successfully
handed over to the new cell.
Paging
Enables the MME to page a UE in the radio network. The MME initiates the paging
procedure by sending a Paging message to each eNB with cells belonging to the Tracking
Area(s) in which the UE is registered. The paging response back to the MME is initiated
on the NAS layer and is forwarded to MME by the eNB as part of the NAS Signalling
Transport procedure.
NAS Signalling Transport

This procedure provides means to transport NAS messages to/from a given UE over the
S1-MME interface.
Node Management Procedures

S1 Setup. The purpose of the S1 Setup procedure is to exchange data needed for the eNB
and MME to interoperate correctly on the S1-interface. This procedure shall be the first
S1AP procedure triggered after the SCTP association (see below) has become operational
(e.g, when a new eNB has been added in the network).
Configuration Update. The purpose of this procedure is to exchange application level
data that have changed since the last S1 setup procedure was executed. The procedure
may be initiated from the eNB or the MME.
Reset. The purpose of the Reset procedure is to initialise or re-initialise the S1AP UE
contexts, in the event of a failure in the MME or eNB. This procedure does not affect the
application level configuration data exchanged during the S1 Setup procedure.
Location Reporting Procedures

These procedures allow the MME to request the current location (i.e. cell) of the UE. The
eNB can be asked to report immediately or when the UE leaves the current cell.
SCTP and Transport Protocols

The Stream Control Transmission Protocol (SCTP) is used for the exchange of S1AP
signalling messages between eNB and MME. SCTP is a session-oriented protocol
providing connection-oriented, error-free, flow-controlled, in-sequence transfer of
signalling messages over IP. It is in many respects similar to TCP, but there are some
differences. One such difference is that SCTP is message oriented while TCP is byte
oriented. Another difference is that the in-sequence delivery is optional for SCTP (i.e. it
can be turned off) while it is always mandatory for TCP.
S1AP
3-4
AP
I
SCTP makes use of so-called Stream Identifiers to identify a logical signalling connection
(stream) between two network nodes. A single SCTP association per S1-MME interface
instance is used, with different pairs of Stream Identifiers for S1-MME non-UE
associated and UE associated procedures.
3.4
AP
IS
An SCTP PDU consists of a header and one or more 'chunk' fields. The payload is either
higher layer information (an S1AP message in this case) or SCTP layer control
information. The chunk type 'DATA' is used for transport of higher layer information.
G eneral S C TP P D U Form at
0
0
1
1
2
1
S o u rce P o rt
D e stin a tio n P o rt
Set per
a sso cia tio n
a t In itia lisa tio n
C om m on H eader
V e rifica tio n T a g
(1 2 b yte s)
C h e cksu m
C hunk H eader
C h u n k T yp e
(4 b yte s)
C h u n k F la g s
C h u n k V a lu e s
C h u n k L e n g th
P a ylo a d o r C o n tro l
(v a ria b le )
The D A TA C hunk
0
0
1
1
T yp e = D A T A
2
1
R e se rv e d
U B E
C h u n k L e n g th
T ra n sp o rt S e q u e n ce N u m b er
S tre a m Id e n tifie r
S tre a m S e q u e n ce N u m b e r (o p t)
P a ylo a d P ro to co l Id
R e g iste re d
w ith IA N A
D A T A , p o ssib ly se g m e n te d
(e .g . X 2 A P o r S 1 A P m e ssa g e )
SCTP PDU format

The transport layer uses IP running over the selected data link (L2) and physical layer
(L1) protocols. These transport layer protocols are not discussed further in this document.
References
GPRS enhancements for E-UTRAN access
E-UTRA S1 Application Protocol (S1AP) specification
An introduction to SCTP
SCTP
S1AP
3-5
AP
I
23.401
36.413
RFC 3286
RFC 4960
3.5
AP
IS
GTP GPRS Tunneling

Protocol
4.1
INTRODUCTION ................................................................................. 4-2
4.2
GPRS TUNNELING PROTOCOL .......................................................... 4-2
4.2.1
General..................................................................................... 4-2
4.2.2
S1 Interface: eNB - SGW ......................................................... 4-2
4.2.3
S11 Interface: MME - SGW ..................................................... 4-2
4.2.4
S5/S8 Interface: SGW-PGW .................................................... 4-3
4.2.5
S10 (MME-MME), S3 (MME-SGSN) ........................................ 4-4
4.2.6
S4 Interface: SGW-SGSN ........................................................ 4-4
4.2.7
GTP Header Format................................................................. 4-4
EPS QOS CONCEPTS ...................................................................... 4-5
4.3.1
User Plane Bearer Establishment ............................................ 4-5
4.3.2
QoS Parameters ...................................................................... 4-7
REFERENCES ................................................................................... 4-7
4.4
GTP GPRS Tunneling Protocol

4-1
AP
I
4.3
AP
IS
4.1
Introduction
The GPRS Tunnelling Protocol (GTP) is used extensively on several interfaces in the
EPC e.g. on S11 between MME and SGW and S5/S8 between SGW and PGW. GTP is
also used on S1-U between eNB and SGW.
GTP can be seen as a combination of two protocols; GTP-C (as in Control Plane) and
GTP-U (us in User Plane). GTP-U is used for tunnelling of user data, while GTP-C is
used e.g. for setting up and releasing those tunnels.
4.2
GPRS Tunneling Protocol
4.2.1
General
The GTP protocol used in EPS is quite similar to the legacy GTP protocol in use already
since the introduction of GPRS in Release 97.
For EPC, GTP version 2 is specified for the control plane (GTPv2-C) in 3GPP TS 29.274.
The specification for GTP-U is 29.281.
The main task of the GTP-U protocol is encapsulation and tunnelling of user data packets
between network nodes. In E-UTRAN it is used on the S1-interface (and the X2-interface
between eNBs). In EPC it is used on e.g. S5/S8 (SGW-PGW) and on S4 between SGW
and SGSN.
Each user data IP-packet is encapsulated and a GTP header is added. The header contains,
among other things, a Tunnel Endpoint Identifier (TEID). The TEID is a locally allocated
reference number that uniquely identifies a GTP tunnel in the node that allocated it. Thus,
a GTP tunnel has two TEIDs associated with it (one in each end).
The GTP-C protocol is used several different EPC interfaces. The exact set of GTP-C
procedures in use is therefore interface-dependent.
The GTPv2-C specification does not divide GTP functions so much into 'procedures' as
into 'scenarios'. For example, the specific GTP-C message (and thus also procedure) to
use for releasing an EPS bearer in the SGW will be different depending on whether the
release was UE initiated or eNB/MME initiated. A consequence of this is that there are
several GTP-C messages/procedures that achieve, more or less, the same thing.
For ease of reading the following descriptions therefore do not include all scenarios that
will trigger a given GTP procedure. Instead, for more detailed information the reader is
encouraged to consult the specification 29.274.
4.2.2
S1 Interface: eNB - SGW

The S1-interface connects E-UTRAN (eNBs) with the EPC. The S1-interface is IP-based
and can be seen as a point to multi-point interface. As described in chapter 3, the Control
Plane instance of the S1-interface (S1-MME) uses the S1 Application Protocol (S1AP)
between an eNB and an MME.
The User Plane instance of the S1-interface (S1-U) uses GTP-U for user data tunnelling.
The termination point on the EPC side for S1-U is the SGW.
S11 Interface: MME - SGW

4-2
AP
I
The S11-interface is, like the S1-interface, an IP-based point to multi-point interface. The
S11-interface is used for signalling between MME and SGW and does not have a UP
instance. The S11-interface uses GTP-C for control signalling purposes.
4.2.3
AP
IS
In the following section, selected GTP-C procedures relevant for the S11-interface are
described.
Create Session. This procedure is initiated from the MME towards the SGW when the
UE requests activation of a Default EPS Bearer due to initial Attach or when the SGW
changes due to the UE performing a TA Update.
Create Bearer. This procedure is initiated from the SGW towards the MME due to
network initiated establishment of a Dedicated EPS Bearer.
Allocate Bearer Resource. This procedure is initiated from the MME towards the SGW
due to UE initiated establishment of a Dedicated EPS Bearer.
Modify Bearer. This procedure is initiated from the MME towards the SGW when a
Dedicated EPS Bearer needs to be released due to network initiated S1 Release, or
modified due to the UE performing TA Update that does not trigger change of SGW.
Delete Session. This procedure is initiated from the MME towards the SGW due to UE
initiated release of a Default EPS Bearer.
Release TFT Filter. This procedure is initiated from the MME towards the SGW due to
UE initiated release of a Dedicated EPS bearer.
Update User Plane. This procedure is initiated from the MME towards the SGW when a
GTP tunnel needs to be modified (moved from one eNB to another) as a result of
handover.
Downlink Data Notification. This procedure is initiated from the SGW towards the MME
in order to trigger paging for an incoming call/session.
Echo. A GTP-C entity (within eNB, SGW, MME or other node) may send an Echo
Request to find out if the peer GTP entity is 'alive'. The peer entity shall respond with an
Echo Response message. This procedure is relevant for both GTP-C and GTP-U.
S5/S8 Interface: SGW-PGW

In the following section, selected GTP-C procedures that are relevant for the S5/S8interface are described.
Create Session. This procedure is initiated from the SGW towards the PGW when the UE
requests activation of a Default EPS Bearer due to initial Attach or when the SGW
changes due to the UE performing a TA Update.
Create Bearer. This procedure is initiated from the SGW towards the MME due to
network initiated establishment of a Dedicated EPS Bearer.
Modify Bearer. This procedure is initiated from the SGW towards the PGW when a
Dedicated EPS Bearer needs to be modified e.g. due to a UE triggered service request.
Update Bearer. This procedure is initiated from the PGW towards the SGW e.g. due to
PGW initiated bearer modification with QoS update.
Delete Session. This procedure is initiated from the SGW towards the PGW e.g. due to
UE initiated release of a Default EPS Bearer.

4-3
AP
I
Delete Bearer. This procedure is initiated from the PGW towards the SGW e.g. due to
PGW initiated release of a Dedicated EPS Bearer.
4.2.4
AP
IS
S10 (MME-MME), S3 (MME-SGSN)
GTP-C is used for some mobility related procedures on the S10 and S3 interfaces
between MMEs and SGSNs, e.g.
Forward Relocation. Initiated from the old (source) MME/SGSN in order to move UE
context to a new (target) MME/SGSN in a handover scenario.
Context Transfer. This procedure is initiated from a target MME/SGSN in order to
transfer UE context from a source MME/SGSN in an inter-RAT Routing Area or
Tracking Area Update scenario.
Identification. Initiated from a target MME/SGSN in order to to transfer the IMSI
identity of a UE from a source MME/SGSN (in case the UE has identified itself to the
target node with a GUTI identity.
4.2.6
S4 Interface: SGW-SGSN
The S4 Interface between SGW and SGSN makes use of both GTP-C and GTP-U.
The S4 Interface is generally used for mobility between E-UTRAN and UTRAN. The
procedures described above for the other GTP based interfaces are generally used also on
S4. It should be noted that for mobility between E-UTRAN and UTRAN, translation
from EPS concepts (such as bearers) to legacy concepts (such as PDP Contexts) are
required.
GTP Header Format

A GTP PDU consists of a GTP header, zero one or more extension headers and a GTP
message. The GTP message is either a GTP-C or a GTP-U message. Thus, GTP-C and
GTP-U use the same header format but the use of a given header field is not necessarily
the same for GTP-C and GTP-U.
V e rsio n
FFS
FFS
M e ssa g e T yp e
M a n d a to ry H e a d e r
(G T P -C a n d G T P -U )
M e ssa g e L e n g th
e xc l m a n d a to ry h e a d e r (2 o c t)
T u n n e l E n d p o in t
Id e n tifie r, T E ID
A ll m e ssa g e s, e xce p t
E ch o R e q /R e sp a n d
V e rsio n N o t S u p p o rte d
(4 o c t)
S e q u e n ce N u m b e r
(2 o c t)
A ll G T P -C m e ssa g e s
S p a re O cte ts
(2 o c t)
CR
R 8 e xte n sio n : P D C P
se q u e n ce n u m b e r
S p a re
E x te n sio n H e a d e r T yp e
NEH
E x te n sio n H e a d e r L e n g th
E x te n sio n V a lu e (s)
P a d d in g if n e e d e d
(n x 4 o c t)
The length of a GTP version 2 header is always a multiple of 4 octets, containing at least
the mandatory part shown in the figure above. The usage of the different fields is
described below:
4-4
GTP header format
AP
I
4.2.7
4.2.5
AP
IS
Version: specifies the GTP protocol version (version 2 in this case).

FFS: For Further Study (currently not standardised).
T flag: signals the presence or not of the TEID field.
E flag: signals the presence or not of the first extension header.
S flag: signals the presence or not of the sequence number field.
Message Type: specifies the GTP message (e.g. 'Echo Request').
Message Length: specifies the length in octets of the GTP message, excluding the
mandatory 4-octet header.
Tunnel Endpoint Identifier (TEID): together with an IP-address and a UDP port number,
the TEID uniquely identifies a GTP tunnel. The TEID is unique per EPS bearer for GTPU and per PDN connection for GTP-C.
Sequence Number: allows in-order delivery of user plane PDUs (and re-ordering of
forwarded user plane PDUs during handover) in the case of GTP-U. For GTP-C the
sequence number links a 'request' message with its 'response', thus acting as a transaction
identifier.
Extension Header Type: specifies the type of extension header. The current R8 GTP
standard only defines one extension header: the PDCP sequence number (passed between
nodes during handover).
Comprehension Required (CR): specifies to the receiving entity if the extension header
must be understood or whether it can be skipped in case the receiver does not recognise it.
Next Extension Header flag (NEH): indicates the presence or not of yet another
extension header, immediately following the current one.
4.3
EPS QoS Concepts
4.3.1
User Plane Bearer Establishment

As mentioned in earlier chapters, the EPS specifications separate between Default EPS
Bearers and Dedicated EPS Bearers.
A Default Bearer provides basic IP-connectivity between the UE and an external Packet
Data Network (PDN). A Default Bearer has a QoS-profile, but never with a Guaranteed
Bit Rate, and is typically used for service level signalling purposes (e.g. for SIP) or for
un-demanding services.
A Dedicated EPS Bearer is another bearer (linked to the Default Bearer) that is
established between the UE and the same PDN. There may be zero, one or more
Dedicated Bearers active for each PDN (but only one Default Bearer).

4-5
AP
I
There are different ways of establishing Dedicated Bearers: UE initiated, EPC initiated
and IMS/PCC initiated bearer establishment. These different mechanisms can all be
realised with a limited number of signalling procedures or, rather, blocks of procedures.
AP
IS
Procedures for EPS bearer establishment

The UE initiated establishment case is, perhaps, the mechanism most similar to how QoS
is handled in legacy GPRS/UMTS networks. The UE requests a certain QoS and the
network responds either 'OK' or 'reject'. For a connected mode UE this corresponds to
step D in the figure followed by step E. In case the UE is in idle mode this must be
preceded by step B, in order to establish a security protected NAS Signalling Connection
first.
The EPC initiated establishment case can be realised in a number of ways. Assuming that
the UE is in idle mode we must start with paging (step A), to which the UE responds with
a Service Request message (step B). The network will then push QoS parameters to the
UE using the procedures in step E again (there is some GTP signalling required between
steps B and E that is not visible in the figure). If the UE is already connected we can
simply skip the paging and go straight for step E.
The IMS/PCC initiated establishment case requires interaction with the Policy and
Charging Control framework (PCC). In short though, neither the UE nor the EPC will in
such a case be the entity selecting QoS parameters. Instead there will be a form of end-toend 'negotiation' between the UE and whatever other entity is involved (e.g. another UE
or a web server). This negotiation is done using the Session Initiation Protocol (SIP), step
C in the figure above. This signalling is, from the point of view of the EPC, seen as just
any other user plane IP packets being routed through the network.
However, control nodes within the IMS infrastructure will be perfectly aware of what
those SIP messages contain and can then push down QoS policies to the PDN Gateway
via the Policy and Charging Rules Function (PCRF). Several IMS/PCC-based scenarios
can be foreseen depending on whether the UE is the entity initiating the SIP signalling or
not and whether the UE is in idle or connected mode.
Assume that the UE is not the entity that initiates the SIP signalling ('MT case'). If the UE
is in idle mode we need to page the UE in order to deliver the first incoming SIP packet.
This would then result in the sequence A, B, C and E. If the UE is already connected we
skip steps A and B.

4-6
AP
I
There are more cases possible but the point here is that we can, with a limited number of
carefully defined procedures, allow a large number of scenarios to be realised.
Assume that the UE is the entity that initiates the SIP signalling ('MO case'). If the UE is
in idle mode it must start with a Service Request, so that we can send the first outgoing
SIP packet over a security-protected connection. The sequence then becomes B, C and E.
AP
IS
QoS Parameters
The EPS QoS architecture has, from a parameter point of view, been substantially
simplified as compared to GPRS/UMTS. As already mentioned, there are only two types
of bearers: Default Bearers and Dedicated Bearers. Furthermore, an EPS bearer either has
a guaranteed bit rate (GBR) or it has not.
A Default Bearer is always a non-GBR bearer. HSS contains the QoS profile for the
Default Bearers. Subscriber data in HSS also includes a maximum aggregate bit rate for
all non-GBR bearers for a UE (UE-AMBR) or for a UE per PDN (APN-AMBR). These
aggregate bit rates cannot be changed or overridden by the EPC.
A Dedicated Bearer can be a GBR or a non-GBR bearer. The EPC, or the PCC
framework, may also assign a (variable) Maximum Bit Rate (MBR) for each Dedicated
Bearer. The MBR may, or may not, be part of the subscription profile stored in the HSS.
Both Default and Dedicated Bearers are also associated with a QoS Class identifier
(QCI). The QCI is a number that, in turn, links to the acceptable/allowed packet delay
budget and packet loss rate. The (current) QCI table can be seen in the figure below.
Q o S C la s s Id e n tifie r
P a c k e t D e la y B u d g e t
P a c k e t L o s s R a te
E x a m p le S e rvic e s
1 (G B R )
< 50 m s
H ig h (e .g .1 0 -1 )
R e a ltim e G a m in g
2 (G B R )
50 m s
M e d iu m (e .g .1 0 -2 )
V o IP
3 (G B R )
90m s
M e d iu m (e .g . 1 0 -2 )
C o n v e rsa tio n a l P S V id e o
4 (G B R )
250 m s
L o w (e .g .1 0 -3 )
S tre a m in g
5 (n o n -G B R )
L o w (~ 5 0 m s)
e .g . 1 0 -6
IM S sig n a llin g
6 (n o n -G B R )
L o w (~ 5 0 m s)
e .g . 1 0 -3
In te ra ctiv e G a m in g
7 (n o n -G B R )
M e d iu m (~ 2 5 0 m s)
e .g . 1 0 -4
T C P in te ra ctiv e
8 (n o n -G B R )
M e d iu m (~ 2 5 0 m s)
e .g . 1 0 -6
P re fe rre d T C P b u lk d a ta
9 (n o n -G B R )
H ig h (~ 5 0 0 m s)
n .a .
B e st e ffo rt T C P b u lk d a ta
O p e ra to r d e fin e d
O p e ra to r d e fin e d
K ille r A p p lica tio n
U p to 2 5 6
QoS Class Identifiers (QCI)

The QoS parameters mentioned in this section are translated or mapped by eNB, MME,
SGW and PGW, into node- and interface specific parameter to allow realisation of EPS
Bearers that fulfil the QoS requirements. How this mapping is done is an implementation
question.
Bearers are also associated with a Traffic Flow Template (TFT). The TFT is a
specification of a packet filter to be applied to all IP packets to be sent over a given
bearer. A TFT could, for example, only allow TCP/IP packets or UDP/IP packets or only
packets with a certain port number or destination address (or any specific combination of
port, address and protocol) to travel on a certain bearer.
References
Evolved GPRS Tunnelling Protocol for Control plane (GTPv2-C)
GPRS Tunnelling Protocol User Plane (GTPv1-U)
23.203
23.401
29.274
29.281

4-7
AP
I
4.4
4.3.2
AP
IS
EPS Mobility
INTRODUCTION ................................................................................. 5-2
5.2
TRACKING AREAS ............................................................................. 5-2
5.3
SUBSCRIBER IDENTITIES ................................................................... 5-3
5.4
MOBILITY PRINCIPLES ....................................................................... 5-3
5.5
REFERENCES ................................................................................... 5-4
EPS Mobility
5-1
AP
I
5.1
AP
IS
5.1
Introduction
User mobility in EPS is hardly surprising handled in similar ways as in legacy 2G and
3G systems.
UEs in idle state (no ongoing data transfer) will do cell re-selection to find better cells to
camp on. If the new cell belongs to a new Tracking Area, the UE will initiate a Tracking
Area Update procedure.
For UEs in connected state (ongoing data transfer) there will be handovers between cells.
However, there are new terms and also some new features and possibilities in order to
create more flexible and efficient solutions, e.g. for fixed and nomadic terminals (as
opposed to truly mobile devices).
Tracking Areas
The EPS uses so called Tracking Areas (TA) for mobility management purposes. The
concept of a Tracking Area is the same as the GSM/UMTS concept of a Routing Area (or
Location Area). Hence, the TA is an operator defined group of cells that all belong to
the area served by one (or more) MME. One or more TA may be defined for each MME.
The MME knows the TA for a registered UE. If the (idle) UE moves, it updates the MME
through the TA Update procedure. The TA is typically, but not necessarily, the area
within which the UE is paged for incoming calls.
A Tracking Area is identified by a Tracking Area Identity.
TAI = MCC + MNC + TAC, where
TAI = Tracking Area Identity
MCC = Mobile Country Code (3 digits)
MNC = Mobile Network Code (3 digits)
TAC = Tracking Area Code (16 bits)
As an operator option, there may also be MME Pool Areas defined. An MME Pool Area
is defined as an area within which a UE may be served without need to change MME. An
MME Pool Area is served by one or more MMEs ("pool of MMEs") in parallel. MME
Pool Areas are a collection of complete Tracking Areas. MME Pool Areas may overlap
each other, as seen in the figure below.
AP
I
EPS Mobility
5-2
MME pool areas
5.2
AP
IS
Subscriber Identities
The EPC uses the IMSI number as the permanent user identifier (or rather, USIM
identifier). As in the legacy Core Network a temporary identifier is also used, for
subscriber identity confidentiality reasons, in place of the IMSI whenever possible. The
temporary identifier for a UE in the EPC is called the Globally Unique Temporary
Identity (GUTI).
The use of the GUTI is very similar to the use of the legacy TMSI (CS domain) and PTMSI (PS domain) numbers. There is a difference however: the GUTI explicitly links
with the MME Pool Area concept. The relationship can be seen in the figure above.
Please note that the length of MCC and MNC is in digits, while the other fields are given
in bits.
GUTI = MCC + MNC + MMEGI + MMEC + M-TMSI, where
MMEGI = MME Group Identifier (16 bits)
MMEC = MME Code (8)
M-TMSI = M- Temporary Mobile Subscriber Identity (32)
The MMEGI uniquely identifies a group ('pool') of MMEs within one network. The
MMEC uniquely identifies an MME within one such group and the M-TMSI uniquely
identifies one UE within one MME (the 'M' is just a label and is not an abbreviation for
anything).
The MMEGI together with the MMEC combines to the MME Identifier (MMEI). Thus,
the MMEI uniquely identifies an MME within one core network. The MMEI together
with MCC and MNC combines to the Globally Unique MME Identifier (GUMMEI).
Thus, the GUMMEI uniquely identifies an MME on planet Earth.
The GUTI is allocated when the UE performs initial registration (i.e. Attach) with an
MME. The GUTI is then typically changed whenever the UE performs some EMMprocedure, such as TA Update. The S-TMSI is a shortened version of the GUTI that
uniquely identifies the user within an MME Group (the 'S' is just a label and is not an
abbreviation for anything). The shorter S-TMSI, rather than the complete GUTI, is used
within most NAS messages.
Mobility Principles
Tracking Area Lists
When a UE is switched on, it will do Network Attach to register in an MME. In the Attach
Accept message, the MME may include a TA list, containing a list of Tracking Areas in
which the idle UE can roam, and do cell-reselection, without updating the MME.
A TA list can also be sent to the UE as part of a Tracking Area Update procedure.
The TA list is individual on UE-level. This allows the operator to know the location on
some UEs (e.g. fixed or nomadic) on single-TA level, and other (more mobile) UEs on
multi-TA level. Allowing a UE to move freely inside several TAs without updating the
MME will obviously decrease the amount of mobility related signalling in the network.
On the other hand, paging for incoming data for a UE needs to be done in all Tracking
Areas in the TA list for that subscriber.
3GPP specifications does not really give much information on how (based on what?) the
lists can be designed by the MME. The type of UE and mobility behaviour and paging
history could possibly be input, but no details are revealed in the specs.
MME and SGW Selection and Change
All cells/TAs in a MME Pool Area are served by the same MME(s). Consequently, as
long as the UE stays inside the MME Pool Area, there should normally be no need to
EPS Mobility
5-3
AP
I
5.4
5.3
AP
IS
change MME. The selection of MME to be used, is made by the eNB. (The selection of
SGW is made by the MME).
However, if an idle UE moves into a TA which is served by a new MME (pool), the
MME for the UE has to be changed. For the UE, it means that a TA Update procedure
will be done (since the new TA is not on the TA list stored in the UE). For the core
network, it means that context for this UE is moved over the S10-interface from the old
(source) MME to the new (target) MME. Subject to operator policy, NAS security
procedures (e.g. authentication) may be done as a result of the MME change.
Also SGWs can (and are likely to) work in a pool solution, meaning that more than one
SGWs will serve an area of cells/TAs. When the MME selects a SGW for setting up
bearers, this will partly be based on reducing the possibility of SGW relocation during a
session. Still, if a UE moves into a new SGW area, bearers will be moved from the old to
the new SGW.
Handovers
Handovers of a connected UE should normally and preferably be done with as little
involvement as possible from the core network. At an intra-eNB handover, the old and the
new cell are both handled by the same eNB, and impact on the core network very limited
(if any).
Another case of handover is between two eNBs that have a direct interface (X2) in
between them. The handover can be prepared and executed almost entirely by the eNBs.
However, the core network needs to be informed about the change of eNB, as the S1-U
interface has to be moved from source eNB to target eNB. In order to do this, the target
eNB will inform the MME about the handover (using S1AP).
More unusual and complicated handovers require MME and SGW changes, with context
transferred between source and target nodes. In addition, making sure that all user data
reaches the UE involves temporary forwarding of user data. Depending on the
configuration of the network, such handover cases may be relatively complicated.
References
Non-Access Stratum (NAS) protocol for EPS
EPS Mobility
5-4
AP
I
24.301
23.401
5.5
AP
IS
DNS use in EPS

INTRODUCTION ................................................................................. 6-2
6.2
RESOURCE RECORDS ....................................................................... 6-2
6.3
EXAMPLE: SELECTING SGW AND PGW ............................................. 6-3
6.4
REFERENCES ................................................................................... 6-3
DNS use in EPS

6-1
AP
I
6.1
AP
IS
6.1
Introduction
The Domain Name System (DNS) is a hierarchical distributed naming system for
computers, services, or other resources connected to the Internet or a private network. It
associates various information (like IP-addresses) with domain names. A Domain Name
Service resolves queries for these names into IP addresses for the purpose of locating
computer services and devices worldwide. Needless to say, the Domain Name System is
an essential component of the functionality of the Internet.
3GPP TS 29.303 describes DNS Procedures for the Evolved Packet System. The
document covers the EPC gateway node selection using DNS (e.g. SGW and PGW
selection) excluding all User Equipment (UE) initiated DNS-based discovery and
selection procedures. 29.203 also covers DNS procedures in order to find/select other
core network nodes, e.g. MME, SGSN and MSC Server.
Compared to the typical Internet use case for DNS (i.e. resolving www.example.com into
an IP-address), the DNS procedures are somewhat different. The input to a DNS query
for PGW selection is e.g. based on an APN and the requested service (protocol used on
S5/8 (GTP or PMIP)). And the DNS response may contain a list of candidates, along with
other information.
Resource Records
Resource Records (RR) are stored in DNS Servers and contain information related to a
domain name.
A and AAAA
The A resource record is used to define IPv4 host address corresponding to fully qualified
name of the host as defined in IETF RFC 1035.
The AAAA resource record is used to define IPv6 host address corresponding to fully
qualified name of the host as defined in IETF RFC 3596
.
It should be noted that in DNS A or AAAA record names, in general, represent a host and
its "equivalent" interface. Host names, in general, cannot be used as node names. A node
may need to have more than one host name for the simple reason that it can have multiple
interfaces for different purposes.
NAPTR
The NAPTR resource record (RFC 3403) allows DNS to be used to lookup services for a
wide variety of resource names, which are not in domain name syntax. NAPTR can be
used by a client program to rewrite a string into a domain name. The rewrite process is
controlled by flags that provide information on how to communicate with the host at the
domain name that was the result of the rewrite. If DNS returns multiple NAPTR resource
records those can be prioritized using embedded order and preference values defined by
the DNS administrator.
The "Straightforward-NAPTR" (S-NAPTR) procedure (defined in RFC 3958) describes a
procedure on how to resolve a domain name, application service name, and application
protocol dynamically to target server and port by using both NAPTR and SRV (RFC
2782) resource records. The S-NAPTR also simplifies the use of NAPTR by e.g. limiting
the use of NAPTR flags.
SRV
DNS use in EPS

6-2
AP
I
The SRV resource record (RFC 2782) allows DNS administrators to use pool of servers
for a single domain with static load balancing to each server, to move services from host
to host, and to designate some hosts as primary servers for a service from a pool of hosts.
A resolver can ask for a specific service/protocol combination for a specific domain name
and get back a Fully Qualified Domain Names (FQDN) of any available servers.
6.2
AP
IS
Example: Selecting SGW and PGW
When a UE requests a PDN Connection to be set up, it sends a PDN Connectivity
Request to the MME. The PDN Connectivity Request may contain an APN, or have an
empty APN field. If the APN field is empty, this means that the UE requests a PDN
Connection to the Default APN which is part of the subscriber data in HSS.
It is the MMEs responsibility to select SGW and PGW for the PDN Connection, e.g.
using DNS procedures. However, also non-DNS procedures (e.g. based on configuration)
can also be used
For DNS procedures, the MME may use the following information as input in a DNS
query:
IMSI
APN
TA-id
Subscriber data
SGW selection
In order to find a SGW with a GTP-based S5-interface, the MME uses the S-NAPTR
procedure with:
Service parameter: x-3gpp-sgw:x-s5-gtp"
Application Unique String:
tac<TAC>.tac.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org
In addition to the requested interface (S5) and protocol (GTP), the Tracking Area Code
(in the format of a TAI-FQDN) is included in the DNS query that is to a DNS Server.
The DNS Server returns NAPTR records containing a replacement field with node
names e.g.:
topoff.vip2.gw01.node.epc.mnc123.mcc321.3gppnetwork.org.
topoff.vip1.gw21.node.epc.mnc123.mcc321.3gppnetwork.org.
The response may also contain A or AAAA-records with IP-addresses to the nodes. The
MME can then select a suitable SGW.
PGW selection
To find a PGW with a GTP-based S5-interface, the MME uses the S-NAPTR procedure
with:
Service parameter: x-3gpp-pgw:x-s5-gtp"
Application Unique String:
services.operator.se.apn.epc.mnc01.mcc240.3GPPnetwork.org
This is sent in a DNS query to a DNS Server. The DNS Server returns NAPTR records
containing a replacement field and (optionally) also contain A or AAAA-records with
IP-addresses to the nodes. The MME can then select a suitable PGW.
References
Domain names - concepts and facilities
Domain names - implementation and specification
Domain Name System Procedures
RFC 1034
RFC 1035
TS 29.303
DNS use in EPS

6-3
AP
I
6.4
6.3
AP
IS
Diameter
7.1
INTRODUCTION ................................................................................. 7-2
7.2
COMMANDS AND AVPS ..................................................................... 7-2
7.3
DIAMETER USE IN EPC ..................................................................... 7-2
7.3.1
General..................................................................................... 7-2
7.3.2
Diameter on S6a and S6d ........................................................ 7-2
7.3.3
Diameter for PCC ..................................................................... 7-3
7.3.4
Other 3GPP use of Diameter ................................................... 7-3
REFERENCES ................................................................................... 7-3
Diameter
7-1
AP
I
7.4
AP
IS
7.1
Introduction
Diameter is a protocol that originates from the Internet world, and is thus specified by
IETF (Internet Engineering Task Force). The current baseline Diameter specification is
RFC 6733.
Note: The name Diameter is not an abbreviation, but a play with words. The protocol is
an improved alternative to the RADIUS (Remote Access Dial In User Service) protocol.
Diameter is often described as providing a framework for AAA (Authentication,
Authorization & Accounting).
7.2
Commands and AVPs

Diameter is an application layer protocol in the IP protocol stack. This means that
Diameter messages are transferred in IP-packets using a reliable transport protocol, i.e.
TCP or SCTP.
The Diameter messages are called Commands. They are exchanged between Diameter
entities in a straightforward Request/Answer syntax. The information parameters
(identities, password, credit control etc) are transferred inside the commands in so called
Attribute/Value Pairs (AVPs). As an example an attribute is e.g. user identity and its
value can be some username or number.
7.3
Diameter use in EPC
7.3.1
General
Like some other IETF protocols, Diameter is extensible, meaning that new applications,
commands and AVPs can be added. 3GPP has used this opportunity and uses Diameter on
several interfaces in EPC. 3GPP Diameter applications are described in TS 29.230.
Diameter on S6a and S6d

Diameter is used e.g. on the S6a interface between MME and HSS and on S6d between a
Release 8+ SGSN and HSS. TS 29.272 list some groups of procedures/use cases for
S6a/S6d:
Location Management procedures
Update Location
Cancel Location
Purge UE
Subscriber Data Handling procedures
Insert Subscriber Data
Delete Subscriber Data
Authentication procedures
Authentication Information Retrieval
Fault Recovery procedures
Reset
Notification procedures
Notification
Diameter
7-2
AP
I
For details about the use of Diameter on S6a and S6d, refer to TS 29.272.
7.3.2
AP
IS
Diameter for PCC
Diameter is also a key protocol in the PCC architecture. Policy and charging information
is exchanged using DIAMETER commands, e.g. between PCRF (Policy and Charging
Rules Function) and PCEF (Policy and Charging Enforcement Function). For more
information about PCC, refer to chapter 8.
7.3.4
Other 3GPP use of Diameter

Diameter is used on the S13-interface between MME and the EIR (Equipment Identity
Register) for ME Identity Check procedures. This is in order find out if an IMEI-number
is on the black list and therefore should be blocked from use. The corresponding
interface between an SGSN and MME is called S13.
The Diameter protocol is also used on several interfaces in the IMS architecture.
Typically, in IMS, Diameter is used for transferring subscriber profiles and authentication
parameters (quite like the MAP protocol has done in GSM and UMTS).
References
Diameter
Diameter applications; 3GPP specific codes and identifiers
Mobility Management Entity (MME)
and Serving GPRS Support Node (SGSN) related interfaces based on
Diameter protocol
RFC 6733
TS 23.203
TS 23.401
TS 29.230
TS 29.272
Diameter
7-3
AP
I
7.4
7.3.3
AP
IS
Policy and Charging

Control
8.1
INTRODUCTION ................................................................................. 8-2
8.2
HIGH-LEVEL PCC ARCHITECTURE ..................................................... 8-3
8.3
PCC AREAS ..................................................................................... 8-5
8.3.1
Policy Control ........................................................................... 8-5
8.3.2
Charging Control ...................................................................... 8-5
Policy and Charging Control

8-1
REFERENCES ................................................................................... 8-5
AP
I
8.4
AP
IS
Introduction
The purpose of Policy and Charging Control (PCC) is to allow the network
to make relevant decisions about QoS (quality of service) and charging on
a detailed level. These decisions can mainly be based on:
subscriber information (stored in some network database),
the service requested by the UE,
current status in the network (e.g. available resources), and/or
general policies and rules in the network.
In the old circuit switched world, Policy and Charging control was less
complex. Quality basically meant provided using circuits (e.g. dedicated
timeslots). Charging was often quite intuitive; normally based on the
duration of a call and the geographical distance (although most operators
nowadays tend to have a multitude of different subscriptions with many
different tariffs and payment models).
When packet data was introduced with GPRS, operators found that - for
various reasons - charging subscribers for sessions, bytes or packets
was difficult. Thus, the dominating tariff model became some type of flat
monthly fee for data traffic, possibly with some maximum data volume per
month. As long as data was only a small portion of the total traffic in the
networks, this model was considered sufficient for most operators.
With the deployment of HSPA and LTE/EPS, mobile broadband offerings
and new services, data traffic volumes have sky-rocketed in many
networks, leading to a demand for improved charging models/mechanisms.
Also, QoS handling becomes more complex in a packet based, multiservice multi-access environment. Particularly, this is the case if we do not
want to use the best effort QoS approach.
One main novelty in PCC is that it allows policy control and charging on a
finer level (smaller granularity) that has been the case previously. Policy
and charging control can be done on Service Data Flow (SDF)1 level,
which basically allows operators to differentiate QoS and pricing on a
service by service level.
PCC can also be done on higher level than per SDF. One use case is that
an operator wants to restrict the bit rate for a subscriber after a certain
monthly quota has been reached. Or maybe raise the price after 10 GB has
been consumed per month. This means that PCC can also be done on a
subscriber level, or on so called IP-CAN Session or IP-CAN Bearer level.
Bearers
User plane resources for IP data traffic are generally referred to as
Bearers. As the term suggests, the bearer carries IP packets belonging to
one or several IP services (e.g. web browsing, e-mail, voice over IP).
AP
I
The concept of a Service Data Flow will be described later. Simplified, a SDF can be
viewed as all the IP-packets belonging to a certain service.
8-2
8.1
AP
IS
In GPRS and UMTS, the packet switched bearer is often referred to as a

PDP Context2. A UE that has a PDP Context is logged on in the sense
that it has an IP-address and some sort of logical connection (pipe) via a
radio access network, SGSN and GGSN to an external Packet Data
Network (PDN).
In LTE/EPS the user plane consists of so called EPS Bearers. There are
two types of EPS Bearers, named Default and Dedicated EPS Bearers. A
Default Bearer is established when a UE registers in EPS and connects to
an external Packet Data Network (PDN). The Default Bearer does not have
a guaranteed bit rate (GBR), and consequently provides only basic IPconnectivity between the UE and the PGW. For services that require
higher QoS (e.g. a guaranteed bit rate) an additional bearer will be
established. These additional bearers are called Dedicated Bearers.
In the PCC specifications, the general term IP-CAN Bearers is often used
for various types of bearers in various types of networks.
IP-CANs
3GPPs architecture for PCC is primarily developed for LTE/EPS and
UMTS (using the legacy PS core). However, the same (or similar)
architecture may also be used with e.g. CDMA2000, xDSL and DOCSIS.
IP-CAN (IP Connectivity Access Network) is a general term for a network
that provides the user with an IP-address and allows the user to send and
receive IP packets over some type of connection or bit pipe.
PDNs
Packet Data Network (PDN) is the general term for a network to which the
UE can be connected via the IP-CAN. The PDN may e.g. be the public
Internet or a service network owned/controlled by a telecom operator (e.g.
IMS the IP Multimedia Subsystem).
High-Level PCC Architecture

PCRF Policy and Charging Rules Function
The PCC architecture consists of a number of nodes/functions with
specified interfaces between them. The Policy and Charging Rules
Function (PCRF) can be viewed as the centre-piece in the PCC
architecture. The PCRF is responsible for creating Policy and Charging
related information for IP-CAN sessions, IP-CAN bearers or Service Data
Flows (SDFs).
In order to do PCC on SDF-level, so called PCC Rules are used. These
rules ultimately govern how QoS is handled and charging is done for
SDFs.
A PCC Rule consists of three main parts.
AP
I
The term GRPS/UMTS Bearer is also used in specifications. However, in daily life
most people tend to use the term PDP Context.
8-3
8.2
AP
IS
AF Application Function
PCC Rules are partly based on requirements from an Application Function
(AF). AF is a general name for a node/function that needs PCC rules to be
decided and implemented. The AF can e.g. be an IMS node (P-CSCF) or a
streaming server. The AF knows requirements on a service level e.g. bit
rate and delay requirements for a media over IP session.
PCEF Policy and Charging Enforcement Function
PCC Rules have to be enforced into nodes in the user plane so that bearers
can be set up and monitored according to service level requirements. The
Policy and Charging Enforcement Function (PCEF) resides in a user plane
node. In EPS this node is the PGW, in GPRS/UMTS it is GGSN. PCEF
also has interfaces to charging systems, in order to get charging
instructions or report events.
The basic idea is that an AF (Application Function) that is responsible for
the actual service communicates service level requirements e.g. regarding
bit rate and delay to PCRF. This allows user plane bearers to be tailor
made for services provided by an operator, e.g. IMS services like Voice
over IP. But do note that PCC Rules can also be generated for unknown
services e.g. an unidentifiable Internet service.
SPR Subscription Profile Repository
The SPR logical entity contains all subscriber/subscription related
information needed for subscription-based policies and IP-CAN bearer
level PCC rules by the PCRF. The SPR may be combined with or
distributed across other databases in the operator's network, but those
functional elements and their requirements for the SPR are out of scope of
this document.
Note that the SPR's relation to existing subscriber databases is not
specified as of 3GPP Release 11. From Release 11, 3GPP also introduces
the User Data Repository (UDR) as an alternative database for converged
storage of subscriber data.
AP
I

8-4
Online Charging System - OCS

The Online Charging System performs charging functions e.g. Credit
Control in real-time. This allows the OCS to affect service execution in
real-time, typically for pre-paid subscribers. However, online charging can
also be used for post-paid subscribers.
Service Data Flow identification: filters that allows the PGW to

identify a specific Service Data Flow (SDF) by looking at source
and destination IP-addresses, port numbers and the transport
protocol (TCP or UDP)
Authorized QoS for the Service Data Flow: GBR, MBR; ARP and
QCI
Charging Information: instructions on how to charge for the SDF
(time based, volume based, event based etc)
AP
IS
Offline Charging System OFCS

The Offline Charging System receives charging information (Charging
Data Records CDRs) from the network nodes. The CDRs are processed
and ultimately a bill for the subscriber is produced. The OFCS is typically
used for post-paid subscribers.
8.3
PCC Areas
Policy and Charging Control can be divided into two sub-areas; Policy
Control which is mainly related to QoS, and Charging control.
8.3.1
Policy Control
Policy Control aims at providing the PCEF with authorized QoS values
and parameters for each Service Data Flow (SDF) or Bearer or Session.
The QoS high-level parameters in a PCC Rule are;
Guaranteed Bit Rate (GBR)
Maximum Bit Rate (MBR)
Allocation and Retention Priority3 (ARP)
Quality of Service Class Identifier4 (QCI)
These QoS parameters (GBR/MBR, ARP, QCI) will eventually be
mapped down to bearer level parameters in different parts of the network,
e.g. radio network parameters for E-UTRAN. (How this mapping is done
is however implementation dependant.)
It is the PCRF that decides upon the PCC rules to be used. These decisions
are based on input from the AF, SPR, PCEF, TDF, OCS and the PCRF
itself. PCC rules may be static throughout a session, but can also change as
a result of events taking place (e.g. an inter-RAT handover).
8.3.2
Charging Control
Charging information can be generated by network nodes for a multitude
of reasons and on different levels.
Flow Based Charging (FBC) allows the operator to generate charging
information on Service Data Flow (SDF) level, based on data volumes,
session time, events or combinations of these.
As mentioned above, PCC comprised functionality for both offline and
online charging.
References
The ARP gives the SDFs priority in relation to other service data flows
The QCI is a reference to e.g. delay and packet loss sensitivity
8-5
Policy and Charging Control Architecture

Policy and Charging Control (PCC) over Gx/Sd reference point
Policy and Charging Control (PCC) over Rx reference point
AP
I
23.203
23.212
23.214
8.4
AP
IS
EPS Security
9.1
GENERAL ......................................................................................... 9-2
9.2
AS SECURITY FUNCTIONS................................................................. 9-2
9.3
NAS SECURITY FUNCTIONS .............................................................. 9-2
9.3.1
Authentication and Key Agreement ......................................... 9-2
9.3.2
Ciphering and Integrity Protection ............................................ 9-4
NETWORK DOMAIN SECURITY ........................................................... 9-5
9.4.1
Control Plane ........................................................................... 9-5
9.4.2
Security in the User Plane........................................................ 9-6
REFERENCES ................................................................................... 9-6
9.5
EPS Security
9-1
AP
I
9.4
AP
IS
9.1
General
Security in EPS provides security features such as:
User and network authentication
User confidentiality
Information confidentiality
Information integrity (to make sure info has not been changed)
Information origin authentication (to make sure that info comes from the right
source)
EPS security is based on / developed from legacy 3GPP procedures (e.g. UMTS AKA
(Authentication and Key Agreement) and standard IETF mechanisms, e.g. IP sec.
Security mechanisms have to be applied in different parts of the network and at different
levels,
Access Stratum (AS) security provides security between UE and network on the
radio interface (Uu)
Non Access Stratum (NAS) security provides security between UE and the core
network
Network Domain Security (NDS) provides security over interfaces between
network entities.
9.2
AS Security Functions
The Access Stratum security functions are outside the scope for this core network
oriented course. However, in short the AS Security provides;
Integrity check of signalling from UE to eNB (and vice versa)
Ciphering of signalling between UE and eNB
Ciphering of traffic between UE and eNB
Keys for integrity check and ciphering are derived from the EPS Authentication Vector.
9.3
NAS Security Functions
9.3.1
Authentication and Key Agreement

The purpose authentication is to protect the network against unauthorized use. In doing
so, it also protects the subscribers, by preventing intruders to e.g. make calls or set up
sessions pretending to be someone else.
This is achieved by executing an Authentication procedure when a subscriber makes
Network Attach or requests some kind of service from the network (or initiates a
signalling procedure). NAS signalling for authentication takes place between the UE and
the MME but involves also the HSS, where the Authentication Vectors are generated.
EPS makes use of so called mutual authentication. This allows also the UE to
authenticate the network to make sure that it is connected to a real network that is
authorized by the user's operator.
EPS Security
9-2
AP
I
The AKA procedure must, according to the specifications, be performed at least during
initial attach. After that it is up to the MME to decide when to perform a new AKA
procedure. It may be performed whenever the UE wishes to execute some signalling
Authentication and Key Agreement (AKA) is the combined process of authenticating the
user (and network) and calculating keys for NAS ciphering and integrity protection. A socalled security context is established in the UE and in the MME after a successful AKA
run.
AP
IS
An EPS Authentication Vector (AV) is produced in the HSS and consists of four
parameters:
RAND is input to a set of algorithms; together with the secret authentication key
K, for calculation of RES, AUTN and KASME. The authentication key, K, is
uniquely linked to one, and only one, IMSI number in the HSS/AuC. The RAND
parameter from a selected AV is sent to the UE in an Authentication Request
message whenever the MME wishes to perform an AKA run. This parameter is
sometimes referred to as the authentication challenge or random challenge.
RES/XRES is the signed response used for authentication. This parameter is
sent in the Authentication Response message from the UE to the MME. The UE
is regarded as authenticated if the RES provided by the UE matches the one
stored in the selected AV in the MME. The term XRES is short for expected
RES and is just an indication that the RES (i.e. XRES) stored in the MME will
be compared to another version of itself (i.e. the RES sent back from the UE).
AUTN is the authentication token used by the UE to validate that the network is
authorised. The AUTN is sent to the UE along with the RAND in the
Authentication Request message. The AUTN is calculated in the HSS/AuC
based on the Anonymity Key (AK) and the Message Authentication Code
(MAC) in the same manner as in a GSM/UMTS HSS. Note: do not confuse this
'MAC' parameter with the 'MAC' present in a security protected NAS message,
they are not the same!
KASME is the Access Security Management Entity key, where 'ASME' is to be
understood as the MME in the EPS case. K ASME is derived from an HSS/AuC
produced Ciphering Key (CK) and integrity Key (IK), both 128 bits long. The
CK and IK keys are, in turn, calculated in the same manner as in a GSM/UMTS
HSS.
Key Hierarchy
The EPS system uses a security key hierarchy (see figure below) with multiple levels. The
base keys on the top level (CK and IK) are only visible to the UE and the home network
domain database (HSS). On the next level there is KASME, which is only visible to the UE
and the visited MME.
EPS Security
9-3
AP
I
KASME is, in turn, used for derivation of the ciphering and integrity keys needed to protect
NAS signaling messages (i.e. signaling between UE and MME). KASME is also used for
derivation of an eNodeB key, KeNB. Finally, KeNB is used for derivation of keys for
ciphering and integrity protection of RRC signaling messages and a key for the ciphering
of user data over the radio interface (i.e. between UE and eNodeB).
procedure (e.g. tracking area update) or when the UE requests some form of service (e.g.
establishment of dedicated bearers) or both.
AP
IS
N e ve r le a ve s H o m e D o m a in
C K , IK
O n ly u s e d in a c c e s s N W
N e ve r le a ve s E P C
(K A S M E is v P L M N s p e c ific )
C K N AS
K ASM E
(K e N B is c e ll s p e c ific )
K eN B
IK N A S
CKUP
CKCP
IK C P
EPS security key hierarchy

This hierarchy allows the keys in the Home domain, the (visited) EPC domain and the
Access domain to be cryptographically separate, while still being produced by the same
set of Home domain controlled base keys.
Ciphering and Integrity Protection
N AS SN
O th e r in p u t
S ta n d a rd H e a d e r
O th e r IE s (o n e o r m o re m e s s a g e )
E n c ryp tio n
C K NAS
In te g rity
IK N A S
N AS SN
O th e r in p u t
S e c u rity
P ro to c o l
H e a d e r T yp e D is c rim in a to r
MAC
N AS SN
S e c u rity H e a d e r
Ciphering and integrity protection of NAS messages

A simplified version of the processing sequence for ciphering and integrity protection
of NAS messages can be seen in the figure above. The message to be encrypted is fed
to the encryption algorithm together with the NAS Ciphering Key, the NAS Sequence
Number (SN) and additional input parameters. The output is an encrypted message
(the NAS SN is not encrypted).
EPS Security
9-4
AP
I
The encrypted message is then fed to the integrity algorithm together with the NAS
Integrity Key, the NAS SN and additional input parameters. The output is the
calculated MAC, which is placed in the security header appended to the message.
9.3.2
AP
IS
9.4
Network Domain Security
9.4.1
Control Plane
Control plane signalling between different security domains (e.g. different networks)
needs to be protected (confidentiality, integrity, authentication and non-replay). This
applies for interfaces between network entities in the core network (EPS) as well as
between EPC and E-UTRAN.
The security protocols to be used at the network layer are the IETF defined IPsec
security protocols as specified in RFC 4301 and 4309.
Note that there is no 3GPP requirement for NDS/IP security in the user plane.
Security Domains and Security Gateways (SEG)

A central concept is the notion of a security domain. A security domain is network(s) that
are managed by a single administrative authority. Within a security domain the same level
of security and usage of security services is expected. Typically, a network operated by a
single network operator will constitute one security domain. However, an operator may at
will subsection its network into separate sub-networks.
S e cu rity D o m a in B
S e cu rity D o m a in A
N e tw o rk
E n tity
N e tw o rk
E n tity
Zb
Zb
Za
SEG
Zb
Zb
SEG
Zb
Zb
N e tw o rk
E n tity
N e tw o rk
E n tity
Za and Zb interfaces
Security Gateways (SEGs) are entities on the borders of the IP security domains. The
SEGs are defined to handle communication over the Za-interface, which is located
between SEGs from different IP security domains. All NDS/IP traffic shall pass through a
SEG before entering or leaving the security domain. The security may include filtering
policies and firewall functionality not required in this specification.
SEGs are responsible for security sensitive operations and shall be physically secured.
They shall offer capabilities for secure storage of long-term keys used for IKEv1 and
IKEv2 authentication. IPsec SA (Security Association) defines which security protocol to
be used, the mode and the endpoints of the SA.
EPS Security
9-5
AP
I
For NDS/IP-networks the IPsec security protocol shall always be ESP. For NDS/IPnetworks it is further mandated that integrity protection/message authentication together
with anti-replay protection shall always be used.
AP
IS
Security in the User Plane
S1-U (eNB to SGW)
The transport of user data over the S1-U interface (between eNB and SGW shall be
integrity, confidentiality and anti-replay protected from unauthorized parties.
This can be accomplished by using cryptographic means in which case IPsec ESP
shall be used. Alternatively, the operator may provide security by means of a
physically secured environment including eNB and SGW.
S8 (SGW to PGW)
NDS/IP has been designed to protect control plane protocols. However, 3GPP
recognizes that NDS/IP may also be used to protect user plane traffic (GTP-U). It is
observed that Border Gateways and SEG will both reside at the edge of an operators
network.
References
Non-Access Stratum (NAS) protocol for EPS; stage 3
Network Domain Security, IP network layer security
3GPP System Architecture Evolution: security architecture
Security Architecture for the Internet Protocol
Using Advanced Encryption Standard (AES) CCM Mode with IPsec
Encapsulating Security Payload (ESP)
24.301
33.210
33.401
RFC 4301
RFC 4309
EPS Security
9-6
AP
I
9.5
9.4.2
AP
IS
EPS Interworking with

GERAN / UTRAN
10.1 INTRODUCTION ............................................................................... 10-2
10.2 BACKGROUND AND BASIC REQUIREMENTS....................................... 10-2
10.3 PS INTERWORKING ......................................................................... 10-3
10.3.1 Interworking with GERAN/UTRAN ......................................... 10-3
10.4 CS INTERWORKING......................................................................... 10-3
10.4.1 The CS "Problem" .................................................................. 10-3
10.4.2 CS Fallback ............................................................................ 10-4
10.4.3 Single Radio Voice Call Continuity (SRVCC) ........................ 10-5
EPS Interworking with GERAN / UTRAN

10-1
AP
I
10.5 REFERENCES ................................................................................. 10-6
10
AP
IS
10.1
Introduction
UTRAN
Iu -P S
SGSN
G b /Iu
GERAN
Gr
S3
HSS
S4
S12
SPR
S6a
OCS
S 1 -M M E
MME
S 1 -U
S10
Gy
O FCS
S11
Gz
X 2 -C
E -U T R A N
Sp
PCRF
Gx
Rx
SGi
S5
SGW
PGW
X 2 -U
S2b
T ru ste d
IP a cce ss
S6b
S2a
ePDG
SW m
HSS/
AAA
SW n
N o n -tru ste d
IP a cce ss
EPS network architecture

The figure above shows the overall Evolved Packet System (EPS) network architecture.
As can be seen, there are interfaces defined between the nodes/functions in the Evolved
Packet Core (EPC) and other, non-LTE, Radio Access Technologies (RATs). The
purpose of these interfaces is to allow the UE to access the EPC (and the corresponding
services) from a wide variety of access technologies. One can therefore say that the EPC
is 'access agnostic', i.e. it should not (at least in theory) matter what radio access
technology the UE is currently using - the same services should be available anyway.
This is clearly reflected in some of the basic requirements that were agreed upon early in
the EPS standardisation process.
UE Mobility (in both idle and connected mode) to/from 3GPP defined (i.e.
GERAN/UTRAN) is discussed later in this chapter.
Interworking with legacy circuit switched (CS) networks is of particular interest. The
reason being that the EPS is a fully IP-based network, where all forms of CS
transmission/services have been eliminated! Some solutions for CS domain interworking
are described later in the chapter.
Interworking with non-3GPP Access is described in chapter 11. However, for the sake of
understanding the background, it is briefly discussed here too.
Background and Basic Requirements

In the beginning there was circuit switched GSM, and no interworking problems
existed. Then, in Release 97, GPRS was introduced and suddenly a whole range of
questions appeared. Can a terminal support both CS and PS connections simultaneously?
What about paging co-ordination? Can the CS core network domain be interconnected
with the PS domain? What happens with a voice call when a packet session is
established?

10-2
AP
I
"E-UTRAN terminals supporting also UTRAN/GERAN operation should be able to

support measurement of, and handover from/to, both UTRAN and GERAN. The
Much has happened since then. Today there are multi-RAT terminals and network
operators that deploy multiple access technologies, all connected to the same core
network and/or service layer. The people taking part in the initial standardisation process
for E-UTRAN and EPC of course knew all this. Let's look at some of the basic
requirements that were agreed upon.
10.2
AP
IS
interruption time at handover of real-time services between E-UTRAN and

UTRAN/GERAN should be less than 300ms."
This means that the handover mechanisms defined for EPS are basically backwards
compatible to those used in GERAN/UTRAN. The source access system (e.g. E-UTRAN)
decides about starting a handover and provides the necessary information to the target
system (e.g. UTRAN) in the format required by the target system.
"3GPP and non-3GPP access systems shall be supported."
Interworking with WLAN was introduced already in R6. However, this was 3GPPdefined WLAN access and not just any WLAN access point. The requirement above goes
a lot further than that. The term 'non-3GPP access system' means exactly that: any form of
access not standardised by 3GPP. This includes other wireless technologies such as
WiMAX and CDMA2000, but also fixed access technologies such as xDSL. Thus, the
EPC should be able to, in a well-controlled manner, handle connections to/from pretty
much any access network technology in which the UE can be allocated an IP-address.
"It shall be possible to support service continuity between IMS over LTE/EPS access and
the Circuit Switched (CS) domain."
As can be understood from the above quotation, the 'CS problem' alluded to earlier was
foreseen already at start of the standardisation process. The IMS specifications contain a
service called Single Radio Voice Call Continuity (SRVCC) that allows transfer of an
IMS voice call from the PS domain to the CS domain.
There is also another scenario that requires interworking between the EPC and the CS
Domain. This is if IMS is not deployed, or cannot be used for some other reason, and an
LTE-UE in an E-UTRAN cell makes or receives a CS voice call. The solution for this is
called CS Fallback, and is described later in this chapter.
10.3
PS Interworking
10.3.1
Interworking with GERAN/UTRAN

The GTP-C based S3-interface allows MME
SGSN communication, such as retrieval
of UE contexts due to idle mode inter-RAT mobility. An example of this is when an idle
UE makes cell re-selection from an E-UTRAN cell to a UTRAN cell, thus triggering a
Routing Area update towards the SGSN. This is, in effect, no different to any inter-SGSN
Routing Area update. The SGSN need not even be Release 8 or later, since the MME
must be able to perform a fallback from GTP version 2 to GTP version 1 when necessary.
The same interface is used for signalling at PS handover involving the MME and the
SGSN. The signalling messages needed for a well-defined, real-time, PS handover where
introduced already in R6. Thus, the SGSN and the access network node (BSC or RNC)
must be at least R6 nodes. It is the task of the MME to convert a 'PDN context' to a 'PDP
context' and to convert from EPS QoS parameters to QoS parameters that the SGSN can
understand (i.e. the 'QoS profile' as part of the PDP context).
10.4
CS Interworking
10.4.1
The CS "Problem"

10-3
AP
I
The potential problem of interworking with legacy Circuit Switched (CS) networks lies in
the fact that the EPS is an all-IP network and that there are no mandatory interfaces
defined between the MME and the MSC Server. A VoIP call (Voice or Video call over
IP) may very well be handed over to GERAN/UTRAN provided that the target system
After an E-UTRAN to GERAN/UTRAN PS handover, the user plane remains anchored in

the SGW (it acts as a GGSN towards the SGSN). A new GTP-U tunnel is established on
the S4-interface or, if UTRAN supports direct-tunnel to RNC, the S12-interface.
AP
IS
supports PS Handover signalling and can handle the strict QoS requirements for real-time
services in the PS domain. But real-time media over IP is typically not supported in
GERAN. It may - or may not - be supported in UTRAN depending on the release and
HSPA capabilities. Consequently, there is a need for solutions for interworking between
the EPC and the CS domain.
A number of companies/representatives proposed various solutions to this conundrum at
EPS-related standardisation meetings. Two of these were agreed upon since they do not
require any major changes to the core EPS specifications and that they do not add
unreasonable complexity to the system. These solutions are 'CS Fallback' and 'Single
Radio Voice Call Continuity'.
CS Fallback
G b /Iu
GERAN/
UTRAN
SGSN
A /Iu
S3
M SC
S e rv e r
S4
SGs
MME
E -U T R A N
SGW
PGW
S G s-in te rfa ce : a llo w s C S F a llb a ck, w h e re th e U E is p a g e d in E -U T R A N a n d th e ca ll is se tu p in G E R A N /U T R A N
SGs-interface for CS Fallback

The 'CS Fallback' feature enables fallback from E-UTRAN access to UTRAN/GERAN
CS domain access (or to CDMA2000 1xRTT CS domain access). It covers the speech
service but also SMS, CS data and non-call related Supplementary Services (e.g. USSD).
The basic idea is that an incoming or outgoing voice call to a terminal in E-UTRAN is
immediately moved over to GERAN/UTRAN and the CS domain. The handover is done
immediately even before the call setup.
The feature requires the introduction of the SGs-interface between the MME and the
MSC Server. The SGs-interface is used for coordinated mobility management and paging
procedures between EPS and the CS domain and is also used for the transfer of mobile
originating/terminating SMS. The S102-interface is the SGs-interface equivalent when
the target system is CDMA2000 1xRTT.
The feature relies on dual registration. A CS Fallback capable UE will request a
combined EPS/IMSI Attach from the MME. The MME uses the SGs-interface to relay
the registration to the MSC Server. The UE will then maintain the dual registration by
initiating combined TA/LA Updates.

10-4
AP
I
The UE moves to the target system/cell and sends a 'Handover Complete' message (the
exact name of the message depends on the target system and its capabilities). Completion
of the handover means that the UE now has an 'RRC Connection' in the target system/cell.
This connection is used to send a Paging Response to the MSC Server. Normal call setup
signalling is then used to establish the call in the target system.
When the MSC Server receives an incoming call for the UE, it will initiate paging over
the SGs-interface. The MME sends an S1AP paging message, together with a CS
Fallback Indicator, to the eNB. The UE is then paged and an RRC Connection is
established in the normal manner. The eNB then immediately triggers a handover to the
target system. This step may be preceded by a short period during which the UE is
ordered to perform, and report, measurements on the target system.
10.4.2
AP
IS
The CS Fallback feature for mobile originating calls is very similar. In that case the UE
sends an EMM Service Request message with a CS Fallback Indicator to the MME. The
rest of the signalling is the same as above, with the exception that the UE sends a CM
Service Request message instead of a Paging Response to the MSC Server.
The SGs-interface is modelled on the legacy MSC
SGSN Gs-interface. The L3
protocol is called the SGs Application Protocol (SGsAP), which is based on the Gsinterface BSSAP+ protocol. The Combined EPS/IMSI Attach and TA/LA Update
procedures are based on the legacy combined GPRS/IMSI Attach and RA/LA Update
procedures.
Single Radio Voice Call Continuity (SRVCC)

Gb/Iu
GERAN/
UTRAN
SGSN
A/Iu
S3
MSC
Server
S4
SV
MME
E-UTRAN
SGW
PGW
IMS /IMS
Internet /
SV-interface: For SRVCC related signalling between MME and MSC Server
SV-interface for SRVCC

'Single Radio Voice Call Continuity' (SRVCC), enables transfer of IMS voice calls
between PS access and CS access when the UE is not capable of transmitting/receiving in
both of those access networks simultaneously (hence 'single radio'). SRVCC feature
requires explicit support in the UE, the eNB, the MME and the MSC Server. It is also
required that the voice call has been setup as an IMS (multimedia) telephony call/session
and that the call remains anchored in IMS after the transfer (in a so called Service
Centralization and Continuity Application Server SCC AS).
It should be noted that SRVCC is defined as a service. It is possible that subscription data
in the HSS dictate that the service is not allowed under certain circumstances, such as
when the UE is in a visited network. It should also be noted that SRVCC from
UTRAN/GERAN CS access to E-UTRAN is also specified in R11.
The SRVCC feature transfers an ongoing IMS-based call from the PS to the CS domain.
This is in contrast to the CS Fallback feature, which transfers a call even before it has
been established.
The SRVCC transfer of a call from the PS domain to the CS domain is in many ways
similar to a normal PS handover.

10-5
AP
I
Based on measurement reports, the eNB takes a handover decision. The eNB sends a
handover request to the MME, with an indication that this is a SRVCC handover. The
MME triggers the SRVCC procedure with the MSC Server via the Sv-interface. The MSC
Server then initiates the session transfer towards IMS and coordinates it with the CS
handover to the target cell. The MSC Server sends a response back to the MME when
radio resources have been prepared in the target cell. The response includes the radio
interface Handover Command message for the UE. The UE moves to the target cell and
transmits a Handover Complete message.
10.4.3
AP
IS
In parallel, there is signalling (e.g. using SIP) between the MSC Server and the IMS
nodes (CSCF and SCC AS) in order to transfer the session transfer to the CS domain.
When this has been completed, the downlink flow of VoIP packets is redirected towards
the CS access network.
References
Single Radio Voice Call Continuity (SRVCC)
IMS Service Continuity (ISC)
IMS Centralized Services (ICS)
CS Fallback in Evolved Packet System (EPS)
Architecture enhancements for non-3GPP accesses
E-UTRA/E-UTRAN; overall description

10-6
AP
I
23.216
23.237
23.292
23.272
23.401
23.402
36.300
10.5
AP
IS
Interworking with non3GPP IP-access

11.1 INTRODUCTION ............................................................................... 11-2
11.1.1 Network and Host based mobility .......................................... 11-2
11.2 ARCHITECTURE .............................................................................. 11-2
11.2.1 Trust Relationship .................................................................. 11-4
11.2.2 The Access Network Discovery and Selection Function
(ANDSF) ............................................................................................. 11-4
11.3 IP MOBILITY MANAGEMENT ON THE S2 INTERFACES .......................... 11-4
11.3.1 Mobile IP (MIP) ...................................................................... 11-5
11.3.2 S2 variants and MIP flavours ................................................. 11-5
11.3.3 IP Mobility Management Selection (IPMS) ............................ 11-6
11.4 GATEWAY SELECTION ..................................................................... 11-6
11.5 HSS/AAA AUTHENTICATION AND AUTHORIZATION ............................ 11-7
11.5.1 AKA for trusted non-3GPP access......................................... 11-7
11.5.2 AKA for untrusted non-3GPP access..................................... 11-7
11.5.3 AKA for UEs connecting via non-3GPP access over S2c. .... 11-8
11.6 OPTIMISED HANDOVERS .................................................................. 11-8
Interworking with non-3GPP IP-access

11-1
AP
I
11.7 REFERENCES ................................................................................. 11-9
11
AP
IS
11.1
Introduction
EPS allows the UE to use non-3GPP access networks for connecting to the Evolved
Packet Core. Non-3GPP means that those networks use access technology whose
specification is outside the scope of 3GPP, e.g. WLAN/WiFi, CDMA2000 and WiMAX.
To handle idle and active mode mobility between the 3GPP- and non-3GPP access
networks, EPS supports a few different IETF-defined mobility management mechanisms
over the so called S2 reference points (S2a, S2b and S2c).
11.1.1
Network and Host based mobility

There are two main principles for how to handle mobile IP-devices; network- and hostbased mobility.
Network based mobility means that the network takes care of IP mobility for the
device. This is how things are done in GPRS/UMTS and EPS with E-UTRAN access
the network takes care of moving radio bearers to new cells and redirecting IP-tunnels.
The device (UE) has one IP-address received from e.g. the PGW and does not have to be
active regarding IP-mobility.
Proxy Mobile IP version 6 (PMIPv6) is the network-based mobility management
mechanism used in EPS.
Host based mobility implies that the device (mobile node) has to be active regarding
IP-mobility. This means and e.g. that the device gets a local IP-address from a visited
network that it has to register in its home network.
Dual Stack Mobile IP version 6 (DSMIPv6) and Mobile IP version 4 in FA mode
(MIPv4_FA) are host-based mechanisms used in EPS.
Used in their native form, all Mobile IP (MIP) versions above have handover delay- and
packet loss characteristics that might be unacceptable for real-time applications like VoIP.
The specifications refer to an active mode UE system change, based on these procedures
as handover without optimisations between 3GPP accesses and non-3GPP IP accesses.
In order to improve things, 3GPP additionally has specified Handovers with
optimisations between E-UTRAN access and non-3GPP accesses, like CDMA2000 and
WiMAX, however with different levels of detail.
Architecture

11-2
AP
I
The architecture for EPS with non-3GPP IP accesses is described in TS 23.402. No less
than eight possible scenarios without optimisation are specified. Two of them deal with
non-roaming situations (roaming here means that a VPLMN is involved), four are for
roaming cases where the traffic is home routed and the last two handles roaming with
local breakout of the traffic. To these eight, the optimised scenario(s) can be added.
11.2
AP
IS
HSS
SW x
PCRF
S6a
G xc
Rx
G xb
Gx
O p e ra to rs IP
se rvice s,
e .g . IM S
SGi
3G PP
A cce ss
SGW
PGW
S5
S6b
S2b
SW m
S2a
3G PP AAA
S e rve r
ePD G
SW n
SW u
H PLM N
N on- 3G P P
N e tw o rk s
U n tru ste d
G xa
n o n -3 G P P
IP-a cce ss
T ru ste d
n o n -3 G P P
SW a
STa
UE
IP-a cce ss
Example architecture for non-3GPP access to EPC.

Non-roaming in EPS using S5, S2a, S2b
HSS
SW x
PCRF
S6a
G xc
Rx
G xb
Gx
O p e ra to rs IP
SGi
3G PP
A cce ss
SGW
se rvice s,
e .g . IM S
PGW
S5
S6b
SW m
3G PP AAA
S e rve r
e PeDPGD G
SW n
H PLM N
N on- 3G P P
N e tw o rk s
U n tru ste d
G xa
n o n -3 G P P
IP-a cce ss
T ru ste d
n o n -3 G P P
SW a
STa
IP-a cce ss
S2c
UE

11-3
AP
I
Example architecture for non-3GPP access to EPC.

Non-roaming in EPS using S5, S2c
AP
IS
Note: Throughout this chapter, the HSS and the 3GPP AAA server are referred to with a
single label HSS/AAA. In the architecture those two elements are connected via
reference point SWx. The SWx reference point (see TS 29.273) is based on Diameter.
11.2.1
Trust Relationship
The non-3GPP accesses are classified as trusted or un-trusted networks. Whether a non3GPP IP access network is trusted or un-trusted is not a characteristic of the access
network or the technology, but is more related to ownership-/ business relation issues. It
is thus the EPS operator that decides whether an IP access network that connects to its
EPC is a trusted or un-trusted IP access network.
A Trusted non-3GP access network contains functions/features that support interworking
with the EPC. Interaction between the UE and the EPC is considered to be secure since
communication between the access network and the EPC is transferred over preestablished secure links.
In contrast, for the un-trusted non-3GPP IP access network, the communication between
the UE and the EPC is not regarded to be secure and for that reason, an IPsec tunnel is
established between the UE and the EPC. The network element terminating this tunnel in
the EPC is the evolved Packet Data Gateway (ePDG). The ePDG is the EPS version of a
PDG introduced by 3GPP in the pre-R8 feature: I-WLAN (TS 23.234).
When performing initial attach in- or handover to a non-3GPP access network the UE
needs to discover the trust relationship of the non-3GPP access network in order to
understand which procedure to initiate (IPsec tunnel set-up or not, ).
The trust relationship of a non-3GPP access network is made known to the UE through:
Pre-configured policy in the UE.
The UE discovers the trust relationship when communicating with the
HSS/AAA for authentication.
11.2.2
The Access Network Discovery and Selection Function

(ANDSF)
In a situation where multi-band, multi-RAT, multi-radio terminals are roaming in an
environment can be served by multiple technologies and multiple operators, the
seemingly simple process of network selection after power-on can then take quite some
time. And it is not trivial to figure out what services are best handled over what access
technology. Then there are the questions of roaming agreements, QoS policies, security
and charging to consider.
For these, and other, reasons a new network function has been introduced: the Access
Network Discovery and Selection Function (ANDSF). A logical interface, S14, between
the UE and the ANDSF (in the home domain) has been defined. The purpose of the
ANDSF is to provide the UE with lists of available, local, access technologies. It will also
be possible for the home network operator to, via the ANDSF, provide the UE with local
inter-RAT mobility policies, such as preferred and/or restricted access
technologies/networks.
IP mobility management on the S2

Interfaces

11-4
AP
I
EPS support IETF-defined mobility management mechanisms over S2 reference points.

These mechanisms are all based on Mobile IP (MIP).
11.3
AP
IS
Mobile IP (MIP)
In brief, Mobile IP works as follows. The device is referred to as a mobile node (MN),
and is associated with two IP addresses:
a home address (HoA) provided by a Home Agent (HA) in the home network
and
a care of address (CoA), which is allocated from the network the mobile node
is currently visiting.
The home agent is a router in the mobile nodes home network. It stores information
about the MN in a so called binding cache. This information obviously includes the
HoA and CoA.
A node (correspondent node-CN) that would like to communicate with the mobile node
uses the home address (HoA) of the mobile node as the destination address for IP-packets.
Normal IP routing mechanisms forward these packets to the home network where they are
captured by the home agent. After checking its binding cache table, the original IP packet
is encapsulated in another IP-packet and the home agent tunnels packets to the CoA. The
original packets are de-capsulated at the end of the tunnel at the MN.
For outgoing IP-packets, the mobile node can simply send packets directly to the other
communicating node, using its home address as the source address for the IP packets.
This is known as triangular routing. Alternatively, reverse tunneling may be employed.
This means tunneling the mobile node's outgoing packets to the home agent, which in
turn forwards them to the communicating node. This is needed in networks whose
gateway routers have ingress filtering enabled and hence the source IP address of the
mobile host would need to belong to the subnet of the foreign network, else the packets
will be discarded by the router.
If the mobile node leaves the visited network (from which it has gotten the CoA) and
moves into a new (sub-) network, it will no longer receive the incoming packets. They
will be sent to the old network as long as the binding cache in the HA is not updated. In
order to correct this the MN has to:
detect that it has moved
perform a link layer attach
configure a new Care of Address and
execute an update of the binding cache in the home agent
This will cause the HA to re-direct the tunnel and incoming packets can once again be
received by the MN. In the response to the binding cache update request, the home agent
can confirm continous usage of the same HoA as before. This means that sessions
established over the old connection can continue to run over the new one and we have
session continuity.
MIPv4 may also work in Foreign Agent mode (MIPv4_FA). In this mode, the CoA is
not for the MN itself, but for a Foreign Agent in the visited network. A MN registers the
FA_CoA in the binding cache and the FA forward tunneled IP-packets to the MN.
S2 variants and MIP flavours

There are three distinct variants of the S2 interface called S2a, S2b and S2c. Different
flavours of Mobile IP are used on these interface variants. For details of the MIP flavours,
refer to the relevant RFCs listed at the end of the chapter.
In the trusted case when a function in the access network acts on behalf of- or assists
the UE in mobility signalling procedures, the reference point of interest is called S2a and
is based on MIPv4_FA or PMIPv6.

11-5
AP
I
11.3.2
11.3.1
AP
IS
For use of MIPv4_FA, the S2a is between a Foreign Agent in the trusted access network
and a Home Agent in the PGW.
When PMIPv6 is used, S2a spans from a Mobile Access Gateway (MAG) function,
located e.g. in a specialized router in the trusted access network to a Local Mobility
Anchor (LMA) function in the Gateway (PGW in most scenarios).
In the un-trusted case, the ePDG can act on behalf of the UE and take care of the
mobility signalling. Here the reference point is called S2b and is based on PMIPv6. The
MAG is located in the ePDG and the LMA in the Gateway (PGW in most scenarios).
Finally, the UE can host the mobility protocol and talk directly with the anchor point in
the EPC over any kind of access network, 3GPP-defined as well as non-3GPP trusted and
un-trusted networks. This logical interface between the UE and the Home Agent EPC
anchor is called S2c and here, DSMIPv6 is used.
11.3.3
IP Mobility Management Selection (IPMS)

It is an operator decision which Mobility Management mechanisms that are supported
between 3GPP- and non-3GPP accesses within the operator and its roaming partner's
network.
One possibility is to statically configure one single MM-mechanism per access type or per
roaming agreement. In this case, the mechanism to use is configured in the terminal (or
UICC) and in the network.
If more than one MM-mechanism is supported, a negotiation and decision on which
protocol to use has to take place.
The decision is made by the HSS/AAA at initial attachment or handover when the UE is
authenticated for network access or IPsec tunnel establishment via the non-3GPP access
system. During the authentication process, both the UE and the non-3GPP access network
can provide explicit indications of their supported mobility mechanisms. In addition to
indication via explicit signalling, the support of different IP mobility management
protocols at local- and home network can also be known by the HSS/AAA through static
pre-configuration.asdasdasdasdasdasdasda
The final decision on which protocol to use can then be based on the total information
HSS/AAA has about the UE-, local- and home network capabilities and operator policies.
At the end of the procedure, the network sends an indication back to the access network
and the UE telling about the selected mobility management mechanism.
IPMS is performed at:
Initial attach to a non-3GPP access
Handover without optimisation from a 3GPP access to a non-3GPP access
Upon change of access between a non-3GPP access and a 3GPP access or
between two non-3GPP accesses.
Gateway selection

11-6
AP
I
Note: In some roaming scenarios with PMIPv6 based S2a/S2b and home routed traffic
over S8, the S2a/S2b interfaces terminates on an SGW in the VPLMN. Here the
HSS/AAA infrastructure, in addition to providing information for PGW selection also
gives information for the trusted non-3GPP access network/ ePDG to find the SGW.
After network access authentication (trusted) or authentication for IPsec tunnel

establishment (un-trusted), a PGW is selected. The PGW-selection function is located in
the Foreign Agent or Mobile Access Gateway for the trusted (S2a) case, in the ePDGMAG for un-trusted (S2b) case and finally in the UE for the S2c case. The selection
function receives PGW selection information from the HSS/AAA during the
authentication/ IPsec tunnel establishment procedure.
11.4
AP
IS
HSS/AAA authentication and
authorization
During HSS/AAA authentication and authorization, in addition to UE-EPC mutual
authentication, other types of important information is exchanged for network access/
IPsec tunnel establishment.
In this procedure:
the UE can learn the trust relationship of interest for the current situation.
the UE and the access network can become aware of what IP mobility
mechanism to use.
vital information necessary for GW selection is delivered from HSS/AAA to
where it is needed.
Below, brief descriptions of these important procedures for authentication and
authorization are given together with references to more detailed documents.
As described in TS 33.402, the authentication for non-3GPP access and IPsec tunnelestablishment builds upon the 3GPP access EPS-AKA procedure and the usage of HSS
security vectors. However, for non-3GPP access, the keys and challenge/responseparameters of the vector are carried by other protocols compared to the 3GPP access case.
End to end between the UE and the 3GPP-AAA server, the Extensible Authentication
Protocol (EAP) carries the relevant AKA parameters. The details can be found in RFC
4187 EAP-AKA. How the EAP messages in turn are transported, depends on whether
the case is for a trusted or un-trusted scenario.
Note: The identity provided by the UE for authentication purposes is the Network Access
Identifier (NAI) as described in TS 24.302 and RFC 4282. The NAI used here is based on
the IMSI. In order to run the AKA procedure, a USIM must be present in the UE.
11.5.1
AKA for trusted non-3GPP access

To carry the EAP-messages between the UE and the trusted non-3GPP access network,
protocols specific to the access network are used. The details are outside the scope of
3GPP standardisation.
Over the STa reference point (i.e. between the trusted non-3GPP access network and the
3GPP AAA server) Diameter serves as transport for the EAP signalling. This applies
both when PMIPv6 and when MIPv4_FA mode is used over S2a.
AKA for untrusted non-3GPP access

With the aim of making the communication UE to EPS secure, an IPsec tunnel is
established from the UE over the untrusted non-3GPP access network to the ePDG in the
EPC. The protocol used to establish the IPsec security associations is called IKEv2 (RFC
4306).
As a part of the tunnel establishment, the UE and the 3GPP AAA server performs EAPAKA mutual authentication. The UE sends EAP messages over IKEv2 to the ePDG (SWu
reference point) and the ePDG forwards them using Diameter to the 3GPP AAA Server
(SWm reference point).
During idle and active mode mobility events the tunnel end nodes, i.e. the UE and the
ePDG, manage IPsec tunnel handling. If the UE connects to the same ePDG over the
target access system as the one used when in the source access system, MOBIKE (RFC
4555) is used to update the ePDG with the UEs new IP address. On the other hand, if the
UE connects to a new ePDG over the target system, a new IPsec-tunnel needs to be
established.
11-7
AP
I
11.5.2
11.5
AP
IS
AKA for UEs connecting via non-3GPP access over
S2c.
As an alternative for global mobility management, the HSS/AAA may instruct the UE not
to rely on functions in the access network but instead handle the mobility signalling by
itself. Here the UE talks directly with the anchor point (home agent function in the
PGW) over the S2c reference point using DSMIPv6.
After a local IP address has been configured in the UE when connecting via E-UTRAN or
trusted/untrusted non-3GPP IP access, the UE learns the address to the home agent
function in the PGW.
The Home Agent address can be discovered based on:
Protocol Configuration Options in the E-UTRAN case,
IKEv2 signalling for IPsec tunnel establishment in the untrusted non-3GPP IP
access case,
DHCP (+ DNS query) and
Stand alone DNS query.
Knowing the PGW/Home Agent address makes it possible for the UE to establish a
security association with the PGW. The goal with this association is to secure the
DSMIPv6 signalling. IKEv2 is used to set-up the association and IKEv2 carries EAP
messages between the UE and the PGW for authentication/authorisation purposes. The
PGW relays the EAP signalling to the HSS/AAA over Diameter on S6b.
Optimised handovers
In order to reduce delay and minimize data loss during handover, the standard suggests
handovers with optimisations between E-UTRAN and a few non-3GPP access
technologies, currently CDMA2000 HRPD and mobile WiMAX.
For the CDMA2000 HRPD case, the source and target access systems are closely
integrated via additional interfaces for signalling (S101) and user data (S103). Over S101
the UE can perform a pre-registration in the target system and create a so called dormant
session there, maybe well in advance of the actual handover execution. This will reduce
the amount of signalling that has to be exchanged during the handover phase and thus
have a positive impact on overall delay.
A packet that has arrived in the SGW but has not been delivered to the UE before the
PGW switches the tunnel between S5 and S2a can now be forwarded over S103 and
thereby data loss can be avoided.
SW x
HSS
AAA
S6b
S6a
X 2 -C
S 1 -U
SGi
S5
E -U T R A N
SGW
X 2 -U
S10
G xc
S 1 -M M E
MME
PGW
Gx
Rx
PCRF
S11
STa
G xa
S101
S103
S2a
H R P D A ccess
IO S
HSGW
HRPD
AN

11-8
AP
I
11.6
11.5.3
AP
IS
Optimised handover; Architecture: E-UTRAN <-> CDMA2000 HRPD, non

roaming case
References
TS 23.003: Numbering, addressing and identification
TS 23.234: 3GPP System to WLAN Interworking; System Description
TS 23.401: GPRS Enhancements for E-UTRAN Access
TS 23.402: Architecture enhancements for non-3GPP access
TS 24.302: Access to the EPC via non-3GPP access networks
TS 29.273: 3GPP EPS AAA interfaces
TS 33.234: 3G security; WLAN interworking security
TS 33.402: Security aspects of non-3GPP accesses
TS 36.300: E-UTRA and E-UTRAN; Overall description
Revised
IPsec

11-9
AP
I
RFC 2784: Generic Routing Encapsulation (GRE)

RFC 2890: Key and Sequence Number Extensions to GRE
RFC 3344: IP Mobility Support for IPv4
RFC 3748: Extensible Authentication Protocol (EAP)
RFC 3775: Mobility Support in IPv6
RFC 4072: Diameter EAP Application
RFC 4282: The Network Access Identifier
RFC 4285: Authentication Protocol for Mobile IPv6
RFC 4306: Internet Key Exchange (IKEv2) Protocol
RFC 4555: IKEv2 Mobility and Multihoming Protocol (MOBIKE)
RFC 4877: Mobile IPv6 Operation with IKEv2 and the
Architecture
11.7

Гораздо больше, чем просто документы.

EPC Signaling

Загружено:

Сведения о документе

Описание:

Описание:

Авторское право:

Доступные форматы

EPC Signaling

Загружено:

Описание:

Авторское право:

Доступные форматы

Похожие издания

AP

DNS use in EPS

Interworking with non-3GPP

Apis Technical Training AB

Apis Technical Training AB

Long Term Evolution (LTE) ...................................................... 1-2

System Architecture Evolution (SAE) ...................................... 1-2

EVOLVED UTRA & E-UTRAN........................................................... 1-3

Network Architecture ................................................................ 1-3

Requirements on E-UTRA/E-UTRAN ...................................... 1-3

Overview of Technical Solutions .............................................. 1-4

EVOLVED PACKET CORE ................................................................... 1-6

Network Architecture ................................................................ 1-6

Requirements on the EPC ....................................................... 1-7

SOME BASIC EPS PROCEDURES AND TERMINOLOGY.......................... 1-7

Network Attach and PDN Connection Setup ........................... 1-7

EPS Bearers ............................................................................ 1-8

QoS and Policy Control ............................................................ 1-8

REFERENCES ................................................................................... 1-8

Long Term Evolution (LTE)

System Architecture Evolution (SAE)

The Evolved Packet System (EPS), simplified

Interworking: co-existence in the same geographical area and co-location with

Overview of Technical Solutions

LTE (E-UTRA) frequency bands

Evolved Packet Core

The Evolved Packet System (EPS)

Requirements on the EPC

Some basic EPS Procedures and

Network Attach and PDN Connection Setup

QoS and Policy Control

NAS Functionality..................................................................... 2-2

NAS Area Concepts ................................................................. 2-2

NAS SIGNALLING PROCEDURES........................................................ 2-3

EMM Procedures ..................................................................... 2-3

ESM Procedures ...................................................................... 2-4

NAS States and State Transitions ........................................... 2-5

NAS MESSAGE FORMATS ................................................................. 2-6

REFERENCES ................................................................................... 2-7

NAS protocol stack

NAS Area Concepts

MME pool areas

NAS Signalling Procedures

The Specific procedures relate to registration/de-registration functions.

Attach: initial registration of the UE in one MME. The attach procedure is

UE Requested PDN Connection: request for basic IP-connectivity (a

UE Requested PDN Disconnection: used by the UE to disconnect from a

NAS States and State Transitions

NAS Message Formats

NAS message format

S1-MME CONNECTION AND S1 CONNECTION.................................... 3-2

S1AP PROCEDURES ........................................................................ 3-3

SCTP AND TRANSPORT PROTOCOLS ................................................ 3-4

REFERENCES ................................................................................... 3-5

S1 and S11 protocol stacks

S1-MME Connection and S1 Connection

EPS Radio Access Bearer (E-RAB) Management

Context Management Procedures

UE Context Release. The purpose of this procedure is to release the logical S1

UE Context Modification. The purpose of this procedure is to modify an already

NAS Signalling Transport

Node Management Procedures

Location Reporting Procedures

SCTP and Transport Protocols

SCTP PDU format

GTP GPRS Tunneling