TK420.EPC Walid 2016 PDF

TK420
EPC Fundamentals
Copyright TEKonsult 2016
01_EPC Overview
Chapter 1
EPC Overview
TK420
Page 1
01_EPC Overview
1 LTE overview
3GPP Network evolution
3GPP Network evolution

EDGE
WCDMA
HSPA R6
HSPA + R7
I-HSPA R7
LTE R8
Peak data
rate DL/UP
384/384
Kbps
2/2 Mbps
14/5 Mbps
42/8 Mbps
42/8 Mbps
173/58
Mbps
Data Latency
200 ms
150 ms
50 ms
50 ms
25 ms
10 ms
Bandwidth
200 KHz
5 MHz
5 MHz
5 MHz
5 MHz
1.4 20
MHz
BSC based RNC based
RNC based
RNC based
Flat for PS
NB
Flat eNB
CS and PS
Broadband
PS
Broadband
PS
Capex &
OPEX
optimized
BB PS
PS only,
VoIP
Architecture
Services
CS and
high speed
PS
Figure 1 3GPP Network evolution
TK420
Page 1
01_EPC Overview
LTE Advantages
High network throughput
Low latency
Faster data DL/UP
Plug & Play architecture

Low Operating Costs
Response for applications

End-user experience
All-IP network
Higher Spectral Efficacity
for Network Operator
for End-user
1
Figure 2 LTE Advantages
LTE (Long-Term Evolution) of UMTS (Universal Mobile Telecommunications Service) is one of

the latest steps in an advancing series of mobile telecommunication systems. The standards
body behind the paperwork is the 3rd Generation Partnership Project (3GPP).
Along with the term LTE, the acronyms EPS (Evolved Packet System), EPC (Evolved Packet
Core), and SAE (System Architecture Evolution) are often heard. Figure 1.1 shows how these
terms are related to each other: EPS is the umbrella that covers both the LTE of the Evolved
Universal Terrestrial Radio Access Network (E-UTRAN) and the SAE of the EPC network.
LTE was and is standardized in parallel to other radio access network technologies like EDGE
(Enhanced Data Rates for GSM evolution) and HSPA (High-Speed Packet Access). This means
that LTE is not a simple replacement of existing technologies. Rather it is expected that
different kinds of radio access will coexist in operator networks.
From this background it emerges that understanding LTE also requires understanding
alternative and coexisting technologies. Indeed, one of the major challenges of LTE signaling
analysis will concern the analysis of handover procedures. Especially, the options for possible
inter-RAT (Radio Access Technology) handovers have multiplied compared to what was
possible in UMTS Release 99.
TK420
Page 2
01_EPC Overview
However, also intra-system handover and dynamic allocation of radio resources to particular
sub-scribers will play an important role.
The main drivers for LTE development are:
reduced delay for connection establishment;
reduced transmission latency for user plane data;
increased bandwidth and bit rate per cell, also at the cell edge;
reduced costs per bit for radio transmission;
greater exibility of spectrum usage;
simplied network architecture;
seamless mobility, including between different radio access technologies;
reasonable power consumption for the mobile terminal.
It must be said that LTE as a radio access technology is anked by a couple of signicant
improvements in the core network known as the EPS. Simplifying things a little, it is not
wrong to state that EPS is an all-IP transport network for mobile operators. IP will also
become the physical transport layer on the wired interfaces of the E-UTRAN. This all-IP
architecture is also one of the facts behind the bullet point on simplied network
architecture. However, to assume that to be familiar with the TCP/IP world is enough to
understand and measure LTE would be a fatal error.
While the network architecture and even the basic signaling procedures (except the
handovers) become simpler, the understanding and tracking of radio parameters require
more knowledge and deeper investigation than they did before. Conditions on the radio
interface will change rapidly and with a time granularity of 1 ms the radio resources assigned
to a particular connection can be adjusted accordingly.
For instance, the radio quality that is impacted by the distance between the UE and base
station can determine the modulation scheme and, hence, the maximum bandwidth of a
particular connection. Simultaneously, the cell load and neighbor cell interference mostly
depending on the number of active subscribers in that cell will trigger fast handover
procedures due to changing the best serving cell in city center areas, while in rural areas
macro cells will ensure the best possible coverage.
The typical footprint of a LTE cell is expected by 3GPP experts to be in the range from
approximately 700 m up to 100 km. Surely, due to the wave propagation laws such macro
cells cannot cover all services over their entire footprint. Rather, the service coverage within
TK420
Page 3
01_EPC Overview
a single cell will vary, for example, from the inner to the outer areas and the maximum
possible bit rates will decline. Thus, service optimization will be another challenge, too.
1.1.
LTE Standards and Roadmap
To understand LTE it is necessary to look back at its predecessors and follow its path of
evolution for packet switched services in mobile networks.
The rst stage of the General Packet Radio Service (GPRS), that is often referred to as the
2.5G network, was deployed in live networks starting after the year 2000. It was basically a
system that offered a model of how radio resources (in this case, GSM time slots) that had
not been used by Circuit Switched (CS) voice calls could be used for data transmission and,
hence, protability of the network could be enhanced. At the beginning there was no preemption for PS (Packet Switched) services, which meant that the packet data needed to wait
to be transmitted until CS calls had been nished.
3GPP releases
Next step for
GSM/WCDMA/HSPA
and cdma2000
UMTS Rel
99/4
2001
A true global
roaming
technology
IMS
HSDPA
ALL IP
MBMS
HSUPA
WLAN
IMS
evolution
LTE studies
UMTS Rel 5
UMTS Rel 6
UMTS Rel 7
2003
2005
2007
LTE & EPC

UMTS
Rel 8
2009
UMTS Rel
9/10
2011
Figure 3 3GPP Releases

In contrast to the GSM CS calls that had a Dedicated Trafc Channel (DTCH) assigned on the
radio interface, the PS data had no access to dedicated radio resources and PS signaling, and
the payload was transmitted in unidirectional Temporary Block Flows (TBFs).
TK420
Page 4
01_EPC Overview
These TBFs were short and the size of data blocks was small due to the fact that the blocks
must t the transported data into the frame structure of a 52-multiframe, which is the GSM
radio transmission format on the physical layer. Larger Logical Link Control (LLC) frames that
contain already segmented IP packets needed to be segmented into smaller Radio Link
Control (RLC) blocks.
The following tasks are handled by the RLC protocol in 2.5G:
Segmentation and reassembly of LLC packets segmentation results in RLC blocks.
Provision of reliable links on the air interface control information is added to each RLC
block
to allow Backward Error Correction (BEC).
Performing sub-multiplexing to support more than one MS (Mobile Station) by one
physical channel.
The Medium Access Control (MAC) protocol is responsible for:
point-to-point transfer of signaling and user data within a cell;
channel combining to provide up to eight physical channels to one MS;
mapping RLC blocks onto physical channels (time slots).
As several subscribers can be multiplexed on one physical channel, each connection has to
be (temporarily) uniquely identied. Each TBF is identied by a Temporary Flow Identier
(TFI). The TBF is unidirectional (uplink (UL) and downlink (DL)) and is maintained only for the
duration of the data transfer.
Toward the core network in 2.5G GPRS the Gb interface is used to transport the IP payload
as well as GPRS Mobility Management/Session Management (GMM/SM) signaling messages
and short messages (Short Message Service, SMS) between SGSN and the PCU (Packet
Control Unit).
The LLC protocol is used for peer-to-peer communication between SGSN and the MS and
provides acknowledged and unacknowledged transport services. Due to different
transmission conditions on physical layers (E1/T1 on the Gb and Abis interfaces, 52multiframe on the Air interface), the size of IP packets needs to be adapted. The maximum
size of the LLC payload eld is 1540 octets (bytes) while IP packets can have up to 65 535
octets (bytes). So the IP frame is segmented on SGSN before transmission via LLC and
reassembled on the receiver side.
All in all, the multiple segmentation/reassembly of IP payload frames generates a fair
overhead of transport header information that limits the chargeable data throughput. In
TK420
Page 5
01_EPC Overview
addition, the availability of radio resources for PS data transport has not been guaranteed.
So this system was only designed for non-real-time services like web-browsing or e-mail.
To overcome these limitations the standards organizations proposed a set of enhancements
that led to the parallel development of UMTS and EGPRS (Enhanced GPRS) standards. The
most successful EGPRS standard that is found today in operators networks is the EDGE
standard. From the American Code Division Multiple Access (CDMA) technology family
another branch of evolution led to the CDMA2000 standards (dened by the 3GGP2
standards organization), but since the authors have not seen any interworking between
CDMA2000 and Universal Terrestrial Radio Access Network (UTRAN) or GSM/EDGE Radio
Access Network (GERAN) so far, this technology will not be discussed further in this book.
On the one hand a new modulation technique, 8 Phase Shift Keying (8PSK), was introduced
to allow transmission of 8 bits per symbol across the air interface and, thus, an increase in
the maximum possible bit rate from 20 to 60 kbps. On the other hand, to use the advantages
of the new 8PSK modulation technique it was necessary to adapt the data format on the
RLC/MAC layer, especially regarding the size of the transport blocks and the time
transmission interval of the transport blocks.
Different transport block formats require a different CS. Thus, the so-called Modulation and
Coding Scheme (MCS) and CS for GPRS and EGPRS as shown in Figure 1.4 have been dened.
These MCSs stand for dened radio transmission capabilities on the UE and BTS (Base
Transceiver Station) side.
It is important to mention this, because in a similar way capability denition with UE physical
layer categories instead of MCS were introduced for HSPA and will be found in LTE again.
In comparison to GSM/GPRS, the EGPRS technology also offered a more efcient
retransmission of erroneous data blocks, mostly with a lower MCS than the one used
previously. The retransmitted data also does not need to be sent in separate data blocks, but
can be appended piece by piece to present regular data frames. This highly sophisticated
error correction method, which is unique for EGPRS, is called Incremental Redundancy or
Automatic Repeat Request (ARQ) II and is another reason why higher data transmission rates
can be reached using EGPRS.
As a matter of fact, as shown in Figure 1.6, the risk of interference and transmission errors
becomes much higher when the distance between a base station and a UE is large.
Consequently, the MCS that allows the highest maximum bit rate cannot be used in the
overall cell coverage area, but only in a smaller area close to the base stations antenna. Also
for this specic behavior, an adequate expression will be found in LTE radio access.
Since these early days two key parameters have driven the evolution of packet services
further toward LTE: higher data rates and shorter latency. EGPRS (or EDGE) focused mostly
on higher bit rates, but did not include any latency requirements or algorithms to guarantee
TK420
Page 6
01_EPC Overview
a dened Quality of Service (QoS) in early standardization releases. Meanwhile, in parallel to

the development of UMTS standards, important enhancements to EDGE have been dened
that allow pre-emption of radio resources for packet services and control of QoS. Due to its
easy integration in existing GSM networks, EDGE is widely deployed today in cellular
networks and is expected to coexist with LTE on the long haul.
Nevertheless, the rst standard that promised complete control of QoS was UMTS Release
99. In contrast to the TBFs of (E)GPRS, the user is assigned dedicated radio resources for PS
data that are permanently available through a radio connection. These resources are called
bearers.
In Release 99, when a PDP (Packet Data Protocol) context is activated the UE is ordered by
the RNC (Radio Network Controller) to enter the Radio Resource Control (RRC) CELL_DCH
state. Dedicated resources are assigned by the Serving Radio Network Controller (SRNC):
these are the dedicated physical channels established on the radio interface. Those channels
are used for transmission of both IP payload and RRC signaling see Figure 1.7. RRC signaling
includes the exchange of Non-Access Stratum (NAS) messages between the UE and SGSN.
The spreading factor of the radio bearer (as the combination of several physical transport
resources on the Air and Iub interfaces is called) depends on the expected UL/DL IP
throughput. The expected data transfer rate can be found in the RANAP (Radio Access
Network Application Part) part of the Radio Access Bearer (RAB) assignment request
message that is used to establish the Iu bearer, a GPRS Tunneling Protocol (GTP) tunnel for
transmission of a IP payload on the IuPS interface between SRNC and SGSN. While the
spreading factor controls the bandwidth of the radio connection, a sophisticated power
control algorithm guarantees the necessary quality of the radio transmission.
For instance, this power control ensures that the number of retransmitted frames does not
exceed a certain critical threshold.
Activation of PDP context results also in the establishment of another GTP tunnel on the Gn
interface between SGSN and GGSN. In contrast to IuPS, where tunnel management is a task
of RANAP, on the Gn interface as in (E)GPRS the GPRS Tunneling Protocol Control (GTPC) is responsible for context (or tunnel) activation, modication, and deletion.
TK420
Page 7
01_EPC Overview
2 Motivation and Targets for LTE

The work towards 3GPP LTE started in 2004 with the denition of the targets. Even though
HSDPA was not yet deployed at that time, it became evident that work for the next radio
system should be started. It takes more than 5 years from setting the system targets to
commercial deployment using interoperable standards. Therefore, system standardization
must be started early enough to be ready by the time the need is there. A few driving forces
can be identied advancing LTE development: wireline capability evolution, the need for
additional wireless capacity, the need for lower cost wireless data delivery and the
competition of other wireless technologies. As wireline technology keeps improving, a
similar evolution is required in the wireless domain to make sure that the applications also
work uently in the wireless domain. There are also other wireless technologies including
IEEE 802.16 which promise high data capabilities. 3GPP technologies must match and
exceed the competition. More capacity is a clear requirement for taking maximum
advantage of the available spectrum and base station sites. These reasons are summarized in
Figure xxx.
LTE must be able to deliver superior performance compared to existing 3GPP networks
based on High Speed Packet Access (HSPA) technology. The performance targets in 3GPP are
dened relative to HSPA in Release 6. The peak user throughput should be minimum 100
Mbps in downlink and 50 Mbps in uplink, which is ten times more than HSPA Release 6. Also
the latency must be reduced in order to improve the end user performance. The terminal
power consumption must be minimized to enable more usage of the multimedia
applications without recharging the battery. The main performance targets are shown in
Figure XXX and are listed below:
spectral efciency two to four times more than with HSPA Release 6;
peak rates exceed 100 Mbps in downlink and 50 Mbps in uplink;
enables round trip time <10 ms;
packet switched optimized;
high level of mobility and security;
optimized terminal power efciency;
frequency exibility with from below 1.5 MHz up to 20 MHz allocations.
TK420
Page 8
01_EPC Overview
LTE Motivations
Wireline
evolution pushes
Data rates
Wireless data
usage requires
more capacity
Flat rate pricing

pushes efficiency
Other
technologies
push wireless
capacities
LTE Targets
Figure 4 LTE Motivations
Main LTE performance targets

LTE
Optimized mobile OFDMA solution for new and wider spectrum

Higher peak data rates through wider bandwidth
Boosts data capacity in dense urban deployment
Interoperates seamlessly with 3G through multimode devices
HSPA+
HSPA (High Speed Packet Access) is a UMTS enhancement, commercially available at the
end of 2007.
HSPA+ allow the system to quickly react to data bursts.

Ensure fast adaptation to a change in radio transmission characteristics.
Figure 5 Main LTE performance targets
TK420
Page 9
01_EPC Overview
3 LTE Radio Access Network Architecture

The E-UTRAN comes with a simple architecture. The base stations of the network are called
eNodeB and each eNB is connected to one or multiple MMEs. These MMEs in turn are
connected to a S-GW that may also be co-located (comprising the same physical hardware)
with the MME. The interface between the eNB and MME is the called the S1 interface. In
case the MME and S-GW are not found in the same physical entity, the S1 control plane
interface (S1-MME) will connect the eNB and MME while the S1 user plane interface (here
S1-U) will connect the eNB with the S-GW.
In case one eNB is connected to multiple MMEs, these MMEs form a so-called MME pool
and the appropriate network functionality is called S1 ex. The initial signaling procedure
used to connect an eNB with a MME is the S1 setup procedure of the S1 Application Part
(S1AP).
The X2 interface is used to connect eNBs with each other. The main purpose of this
connectivity is intra-E-UTRAN handover. In the real world it will not be possible for all eNBs
of the network to be connected via X2 due to limited transport resources on the wired
interfaces. It also must be expected that, physically, the X2 links will lead from one eNB to
the MME and then back to a second eNB.
In other words, the hubs will be located at the physical location of the MME.
It is important to understand that only the base stations and their physical connections
(wires or bers) are dened by 3GPP as the E-UTRAN, while MME and S-GW are seen as
elements of the EPC network.
TK420
Page 10
01_EPC Overview
4 Network Elements and Function

The explanation given in the previous section indicates that, compared to base stations in
GSM and UMTS UTRAN, the eNB will cover a set of new functions that are crucial to
understand how the E-UTRAN is working.
In addition, the functionality of the MME and S-GW is different from that of their 2G/3G
relatives, the RNC and the SGSN.
The following list of logical meta-functions performed within the overall network/system
was dened by 3GPP:
Network access control functions.
Packet routing and transfer functions.
Mobility management functions.
Security functions.
Radio resource management functions.
Network management functions.
These meta-functions are found in the different network elements with a more specic
functionality denition.
TK420
Page 11
01_EPC Overview
4.1 evolved Node B

The eNB is the network entity that is responsible for radio interface transmission and
reception.
This includes radio channel modulation/demodulation as well as channel coding/decoding
and multiplexing/demultiplexing.
System information is broadcast in each cell on the radio interface DL to provide basic
information to UEs as a prerequisite to access the network.
The LTE base station hosts all RRC functions such as broadcast of system information and
RRC connection control including:
Paging of subscribers.
Establishment, modication, and release of RRC connection including the allocation
of temporary UE identities (C-RNTI).
Initial security activation, which means the initial conguration of the Access
Stratum (AS) integrity protection for the control plane and AS ciphering for both
control plane and user plane trafc.
RRC connection mobility that includes all types of intra-LTE handover (intrafrequency and inter-frequency). In the case of handover, the source eNB will take
care of the associated security handling and provide the necessary key and algorithm
information to the handover target cell by sending specic RRC context information
embedded in a transparent container to the handover target eNB.
Establishment, modication, and release of DRBs (Dedicated Radio Bearers)
carrying user data.
Radio conguration control, especially the assignment and modication of ARQ and
Hybrid Automatic Repeat Request (HARQ) parameters as well as Discontinuous
Reception (DRX) conguration parameters.
QoS control to ensure that, for example, user plane packets of different
connections are scheduled with the required priority for DL transmission and that
mobiles receive the scheduling grants for UL data transmission according to the QoS
parameters of the radio bearers.
Recovery functions that allow re-establishment of radio connections after physical
channel failure or Radio Link Control Acknowledged Mode (RLC AM) retransmission
errors.
The most crucial part for measuring the eNB performance is the UL/DL resource
management and packet scheduling performed by the eNB. This is probably the most
difcult function which requires the eNB to cope with many different constraints like radio
TK420
Page 12
01_EPC Overview
link quality, user priority, requested QoS, and UE capabilities. It is the task of the eNB to
make use of the available resources in the most efcient way.
Furthermore, the RRC entity of the eNB covers all types of intra-LTE and inter-RAT
measurements, in particular:
Setup, modication, and release of measurements for intra-LTE intra-frequency,
intra-LTE inter-frequency, inter-RAT mobility, transport channel quality, UE internal
measurement reports to indicate, for example, current power consumption and GPS
positioning reports sent by the handset.
For compressed mode measurements it is necessary to congure, activate, and
deactivate the required measurement gaps.
The evaluation of reported measurement results and start of necessary handover
procedures are also eNB functions (while in 3G UMTS all measurement evaluation
and handover control functions have been embedded in the RNC). The many
different parameters used in RRC measurement control functions like hysteresis
values, time to trigger timer values, and event level threshold of RSRP and
RSRQ (Received Signal Reference Power and Received Signal Reference Quality) are
the focus of radio network optimization activities.
Other functions of the eNB comprise the transfer of dedicated NAS information and
non-3GPP dedicated information, the transfer of UE radio access capability
information, support for E-UTRAN sharing (multiple Public Land Mobile Network
(PLMN) identities), and management of multicast/broadcast services.
The support of self-conguration and self-optimization is seen as one of the key features of
the E-UTRAN. Among these functions we nd, for example, intelligent learning functions for
automatic updates of neighbor cell lists (handover candidates) as they are used for RRC
measurement tasks and handover decisions.
The eNB is a critical part of the user plane connections. Here the data is routed, multiplexed,
ciphered/deciphered, segmented, and reassembled. It is correct to say that on the E-UTRAN
transport layer level, the eNB acts as an IP router and switch. The eNB is also responsible for
optional IP header compression. On the control plane level, the eNB selects the MME to
which NAS signaling messages are routed.
TK420
Page 13
01_EPC Overview
Evolved Node B (eNb)

The eNB hosts the following functions:
Radio Resource Management:
Radio Bearer Control (establishment/maintenance/release of
Radio Bearers).
Radio Admission Control.
Connection Mobility Control
Packet scheduling.
IP header compression and encryption of user data stream.

Selection of an MME at Initial UE attach. This function is
enabled when S1 Flex is implemented.
Routing of User Plane data towards SGW.
Scheduling and transmission of paging messages (originated
from the MME).
Scheduling and transmission of broadcast information
(originated from the MME or O&M).
Measurement and measurement reporting configuration for
mobility and scheduling.
MME
S1-MME
LTE-Uu
S1-U
LTE-UE
eNB
SGW
X2
eNB
Figure 6 eNodeB
TK420
Page 14
01_EPC Overview
4.2 Mobility Management Entity
The MME is responsible for the NAS connection with the UE. All NAS signaling messages are
exchanged between the UE and MME to trigger further procedures in the core network if
necessary.
A new function of the E-UTRAN is NAS signaling security. The purpose of this feature is to
protect the signaling messages that could reveal the true subscribers identity and location
from unauthorized eavesdropping.
The MME is also responsible for paging subscribers in the ECM_IDLE state and is concerned
with tracking area list management. The list of tracking areas is the list of locations where
the UE will be paged.
To route the user plane data streams the MME will select the best tting PDN-GW and SGW. It will also connect the E-UTRAN with the 3G UTRAN using the S3 interface (MME to
SGSN). When necessary, a relocation of gateways will be triggered and controlled by the
MME.
As its name suggests, the MME will perform management of handovers by selecting a new
(target) MME or SGSN for handovers to 2G or 3G 3GPP access networks. Also, it is the MME
that hosts the connection to the HSS across the S6a interface and, hence, it is responsible for
roaming management and authentication of subscribers.
Last but not least, the MME sets up, modies, and releases default and dedicated bearers.
This function is commonly known as the bearer management function.
According to standard documents, the MME will allow lawful interception of signaling trafc
and transfer of warning messages (including selection of an appropriate eNB). The purpose
of warning message transfer is to inform people living in a larger area about upcoming
natural disasters like storms, bush res, or tsunamis.
TK420
Page 15
01_EPC Overview
Mobility Management Entity (MME)

The MME host functions:
the NAS connection with the UE.
Paging subscribers in ECM-IDLE state.
Tracking Area list management.
PDN GW and SGW selection.
MME selection for handovers with MME
change.
Inter CN node signaling and SGSN selection for
mobility between 3GPP access networks.
Roaming control (S6a interface toward HSS).
User authentication and authorisation support.
Bearer management functions.
Lawful Interception of signaling traffic.
SGSN
S3
S6a
S10
MME
S1-MME
MME
HSS
SGs
S11
eNB
MSS
SGW
Figure 7 MME
TK420
Page 16
01_EPC Overview
4.3 Serving Gateway
The S-GW is the gateway which terminates the interface to the E-UTRAN. A particular LTE
subscriber will always be connected by a single S-GW.
In the case of inter-eNB handover, the S-GW acts as the mobility anchor of the connection
and remains the same while the path for the transport of signaling and user plane will be
switched onto the S1 interface. Once a handover is executed successfully and the associated
UE has left the S-GW, the old S-GW will send one or more end marker packets to the
source eNB, source SGSN, or source RNC of the handover to assist the reordering of user
plane packets in these network elements.
Mobility anchoring of the S-GW is also dened for inter-3GPP mobility. Here the S-GW acts
as the terminating point of the S4 interface (see Chapter 2 for interface denitions and
gures) and routes the trafc between the 2G/3G SGSN and the PDN-GW of the EPC. In
other words, when it comes to inter-RAT handover involving the S4 interface, the S-GW acts
as the GGSN that enables usage of the EPC transport and functions for UTRAN/GERAN PS
services.
If the UE is in ECM-IDLE mode (see Section 1.10.9 for a description of different NAS states)
the S-GW buffers user plane packets that will be sent to the UE after a successful paging
response. The paging via the S1 and Uu interfaces is also triggered by the S-GW.
The S-GW is the network element that provides connectivity and software implementations
for lawful interception.
On the IP transport layer the S-GW acts as a packet router. User plane packets are forwarded
transparently in the UL and DL direction and their underlying transport units are marked by
S-GW with parameters like DiffServ Code Point, based on the QoS Class Indicator (QCI) of the
associated EPS bearer.
Also embedded in the S-GW software are various charging functions for UL and DL charging
per UE, PDN, and QCI. These functions are used to charge the operators own subscribers as
well as roaming users (inter-operator charging).
The S-GW can be connected to SGSNs in non-roaming and roaming scenarios. However,
connectivity to a GGSN is not supported.
TK420
Page 17
01_EPC Overview
Serving Gateway (SGW)

The SGW host functions:
The local Mobility Anchor point for inter-eNodeB handover.
Sending of one or more "end marker" to the source eNB,
source SGSN or source RNC immediately after switching the
path during inter-eNB and inter-RAT handover, especially to
assist the reordering function in eNB.
Mobility anchoring for inter-3GPP mobility.
ECM-IDLE mode downlink packet buffering and initiation of
network triggered service request procedure.
Lawful Interception.
Packet routing and forwarding.
Transport level packet marking in the uplink and the
downlink, e.g. setting the DiffServ Code Point, based on the
QCI of the associated EPS bearer.
Accounting for inter-operator charging. For GTP-based
S5/S8, the Serving GW generates accounting data per UE
and bearer.
Interfacing OFCS according to charging principles
SGSN
S4
S12
MME
RNC
S11
Gxc
S1-U
SGW
PCRF
S5/S8
eNB
PGW
Figure 8 SGW
TK420
Page 18
01_EPC Overview
4.4 Packet Data Network Gateway
The PDN-GW provides access from the mobile operators network to the PS networks that
host the payload contents and operators IP services. If a user has access to more than one
packet data network it is possible that this user is connected to more than just one PDN-GW.
It is not possible for the same UE to simultaneously open connections to a PDN-GW and to a
GGSN in the 3G PS domain, according to 3GPP standards.
The main function of the PDN-GW is to establish, maintain, and delete GTP tunnels to S-GW
or SGSN in the case of inter-RAT mobility scenarios. The PDN-GW allocates the users
dynamic IP addresses and routes the user plane packets. In addition, it provides functions for
lawful interception, policy/QoS control, and charging.
For policy control and charging, the PDN-GW can be connected to a Policy and Charging Rule
Function (PCRF) via the Gx reference point. The PCRF provides guidance on how a particular
service data ow should be treated in terms of priority, throughput, and other QoS
parameters according to the users subscription prole.
Packet Data Network Gateway (PGW)

The PGW host functions:
PDN
packet filtering.
Packet screening (firewall).
Lawful Interception.
S4
UE IP address allocation.
Transport level packet marking in the uplink and downlink.
Accounting for inter-operator charging.
HSGW
UL and DL service level charging.

S2b
Interfacing through OFCS
Gx
S2a
PCRF
PGW
S5/S8
UL and DL service level gating control.

UL and DL service level rate enforcement as defined.
UL and DL rate enforcement based on APN-AMBR.
DL rate enforcement based on the accumulated MBRs of the
ePDGW
SGW
aggregate of SDFs with the same GBR QCI.

DHCP functions
Figure 9 PGW
4.5 Policy and Charging Rule Function
The PCRF was introduced in R5 as a part of the IMS network.

The main functions of the PCRF are:
TK420
PCRF is responsible for negotiating QoS Policy and Charging Policy on a per-flow
basis.
Page 19
01_EPC Overview
The PCRF major functionality is the Quality of Service (QoS) coordination between
the external PDN and EPC.
Therefore the PCRF is connected via Rx+ interface to the external Data network
(PDN)
This function can be used to check and modify the QoS associated with a SAE bearer
setup from SAE or to request the setup of a SAE bearer from the PDN.
This QoS management resembles the policy and charging control framework
introduced for IMS with UMTS release
Policy and Charging Rule Function (PCRF)

The PCRF hosts the following functions:
Binding mechanism, associates a service data flow to the
EPS bearer deemed to transport the service data flow.
PCRF
Reporting
Rx
Gx or
S7
Credit Management
Event Trigger
Policy Control
SGi
Service (data flow) prioritisation and conflict handling

Standardised QoS characteristics
IMS/PDN
PGW
Termination Action
Handling of packet filters.
Figure 10 Policy and Charging Rule Function
4.6. Home Subscriber Server
Home Subscriber Server (HSS) manages subscription-related information in real time, for
multi-access and multi-domain offerings in an all-IP environment.
Based on 3GPP specifications, HSS supports the network control layer with subscription and
session handling, providing capabilities for:
TK420
Page 20
01_EPC Overview
Mobile management
User security
User identification handling
Access authorization
Service authorization
Service profile
HSS is used in all of our IMS solutions, and provides authentication and authorization
functions in the Evolved Packet Core (EPC).
Home Subscriber Server (HSS)

The HSS host functions:
User Identification, Numbering and addressing
information;
User Security information: Network access control
information for authentication and authorization;
User Location information at inter-system level: the
HSS supports the user registration, and stores intersystem location information, etc.;
User profile information.
S6a
MME
HSS
HSS utilizes DIAMETER protocol to support LTE/EPC.

The HSS can be accessed by the MME via S6a interface.
Figure 11 Home Subscriber Server
TK420
Page 21
02_Evolved Core Network
Chapter 2
Evolved Core Network
TK420
Page 1
1 Core network architecture and its evolution

When the evolution of the radio interface started, it soon became clear that the system architecture
would also need to be evolved. The general drive towards optimizing the system only for packet
switched services is one reason that alone would have set the need for evolution, but some of the
radio interface design goals such as removal of soft handover opened up new opportunities in the
architecture design. Also, since it had been shown by High Speed Packet Access (HSPA) that all radio
functionality can be efciently co-located in the NodeB, the door was left open for discussions of
atter overall architecture.
Discussions for System Architecture Evolution (SAE) then soon followed the radio interface
development, and it was agreed to schedule the completion of the work in Release 8. There had
been several reasons for starting this work, and there were also many targets. The following lists
some of the targets that possibly shaped the outcome the most:
optimization for packet switched services in general, when there is no longer a need to support
the circuit switched mode of operation;
optimized support for higher throughput required for higher end user bit rates;
improvement in the response times for activation and bearer set-up;
improvement in the packet delivery delays;
overall simplication of the system compared to the existing 3GPP and other cellular systems;
optimized inter-working with other 3GPP access networks;
optimized inter-working with other wireless access networks.
TK420
Page 1
Core Network targets

optimization for packet switched services in general, when there is no longer a need to support
the circuit switched mode of operation;
optimized support for higher throughput required for higher end user bit rates;
improvement in the response times for activation and bearer set-up;
improvement in the packet delivery delays;
overall simplication of the system compared to the existing 3GPP and other cellular systems;
optimized inter-working with other 3GPP access networks;
optimized inter-working with other wireless access networks.
Figure 1 Core Network targets
Many of the targets implied that a at architecture would need to be developed. Flat architecture
with less involved nodes reduces latencies and improves performance. Development towards this
direction had already started in Release 7 where the Direct Tunnel concept allows User Plane (UP) to
bypass the SGSN, and the placement of RNC functions to HSPA NodeB was made possible. Figure 2
shows these evolution steps and how this aspect was captured at a high level in SAE architecture.
Some of the targets seem to drive the architecture development in completely different directions.
For example, optimized inter-working with several wireless access networks (ANs) indicates the need
to introduce a set of new functions and maybe even new interfaces to support specic protocols
separately for each one of them. This works against the target of keeping the architecture simple.
Therefore, since it is likely that that none of the actual deployments of the architecture would need
to support all of the potential inter-working scenarios, the 3GPP architecture specications were split
into two tracks:
GPRS enhancements for E-UTRAN access: This document describes the architecture and its
functions in its native 3GPP environment with E-UTRAN and all the other 3GPP ANs, and denes the
inter-working procedures between them. The common nominator for these ANs is the use of GTP
(GPRS Tunnelling Protocol) as the network mobility protocol.
Architecture enhancements for non-3GPP accesses [2]: This document describes the architecture
and functions when inter-working with non-3GPP ANs, such as cdma2000 High Rate Packet Data
(HRPD), is needed. The mobility functionality in this document is based on IETF protocols, such as
MIP (Mobile Internet Protocol) and PMIP (Proxy MIP), and the document also describes E-UTRAN in
that protocol environment.
This chapter further describes the 3GPP system architecture in some likely deployment scenarios:
basic scenario with only E-UTRAN, legacy 3GPP operator scenario with existing 3GPP ANs and E-
TK420
Page 2
UTRAN, and nally E-UTRAN with non-3GPP ANs, where inter-working with cdma2000 is shown as
a specic example.
TK420
Page 3
3GPP architecture evolution towards at

architecture
Release 6
Release 7
Direct Tunnel
Release 7
RNC in NodeB
Release 8
SAE & LTE
GGSN
GGSN
GGSN
SAE-GW
SGSN
SGSN
RNC
RNC
NodeB
NodeB
SGSN
NodeB & RNC
MME
eNodeB
Figure 2 3GPP architecture evolution towards at architecture
TK420
Page 4
2 Pool Concept for MME and SGW

3.1 MME pooling
The EPC supports MME and S-GW pools for improved mobility, geographical redundancy, and load
balancing. A pool is a set of MMEs or S-GWs that serve a set of Tracking Areas. A pool area is defined
as an area where a UE may be served without needing to change the serving network element. Each
cell is associated with a pool of MMEs and a pool of S-GWs. After an eNodeB selects an MME for a
UE, the selected MME will select an S-GW within the S-GW Pool supported by the cell.
MME Pool
An MME Pool is defined as a collection of MMEs that serve a defined group of cells.
An MME can only belong to one MME Pool
All MME nodes of one MME Pool serve the same one and only one MME Pool Area
Each Tracking Area can be associated with more than one MME Pool
All MMEs within an MME Pool are (or can be) logically connected
A UE is associated with a single MME within the MME pool
MME Pool Area
An MME Pool Area is an area within which a UE may be served without a need to change the serving
MME. An MME Pool Area is served by one or more MMEs (pool of MMEs) in parallel.
An MME Pool Area is a collection of complete Tracking Areas
MME Pool Areas may overlap each other
TK420
Page 5
MME Pooling
MME Pool
An MME Pool is defined as a collection of MMEs that serve a defined group of cells.
An MME can only belong to one MME Pool
All MME nodes of one MME Pool serve the same one and only one MME Pool Area
Each Tracking Area can be associated with more than one MME Pool
All MMEs within an MME Pool are (or can be) logically connected
A UE is associated with a single MME within the MME pool
MME Pool Area
An MME Pool Area is an area within which a UE may be served without a need to change the
serving MME. An MME Pool Area is served by one or more MMEs (pool of MMEs) in parallel.
An MME Pool Area is a collection of complete Tracking Areas
MME Pool Areas may overlap each other
Figure 3 MME Pooling
3.2 SGW pooling

Serving Gateway (S-GW) Service Area
A S-GW Service Area is an area within which a UE may be served without a need to change the S-GW
which is currently in use. An S-GW Service Area is served by one or more S-GWs at the same time.
An S-GW Service Area is a collection of complete Tracking Areas associated with the S-GW Service
Area
S-GW Service Areas may overlap each other
S-GW Serving Area
An S-GW serving area is served by one or more S-GWs acting in parallel (S-GW Pool)
All S-GWs within an S-GW Pool are (or can be) logically connected
A UE is associated with a single S-GW within the S-GW pool
Serving Gateway (S-GW) Pool
An S-GW Pool is a collection of S-GWs that serve an S-GW Service Area
An S-GW can belong to only one S-GW Pool
An S-GW Pool serves its associated S-GW Service Area
Each cell can be associated with more than one S-GW Pool
All S-GWs within an S-GW Pool are (or can be) connected for communication purposes
An S-GW within one S-GW Pool can communicate with S-GWs in other S-GW Pools
Connections between S-GWs within a pool or across pools are used for indirect packet forwarding
TK420
Page 6
S-GW Pooling
S-GW Serving Area
An S-GW serving area is served by one or more S-GWs acting in parallel (S-GW Pool)
All S-GWs within an S-GW Pool are (or can be) logically connected
A UE is associated with a single S-GW within the S-GW pool
Serving Gateway (S-GW) Pool
An S-GW Pool is a collection of S-GWs that serve an S-GW Service Area
An S-GW can belong to only one S-GW Pool
An S-GW Pool serves its associated S-GW Service Area
Each cell can be associated with more than one S-GW Pool
All S-GWs within an S-GW Pool are (or can be) connected for communication purposes
An S-GW within one S-GW Pool can communicate with S-GWs in other S-GW Pools
Connections between S-GWs within a pool or across pools are used for indirect packet
forwarding
Figure 4 S-GW Pooling
TK420
Page 7
3 EPC Network Interfaces

As already explained, the E-UTRAN is an all-IP network. Figure xxx shows the network elements that
are typically involved in the signaling procedures and routing of payload data from the UE to the PDN
and vice versa. The gure also shows the reference points for inter-RAT handover (and inter-RAT
packet routing) between E-UTRAN, UTRAN, and GERAN.
The pipeline symbols in the gure illustrate the different signaling connections and tunnels for IP
payload transport established and maintained during the connection. The signaling on Gx and Rx
used to negotiate specic QoS policies is ignored for reasons of better understandability. Besides, the
existence of the PCRF is optional. Due to the fact that the MME and the S-GW may also be combined
into a single physical entity, the S11 interface is also optional.
The signaling connection across the LTE-Uu interface is the RRC signaling connection, represented by
a set of Signaling Radio Bearers (SRBs). The user plane tunnel across LTE-Uu is the radio bearer. The
other user plane tunnels are named after the appropriate reference points: namely, S1 bearer and S5
bearer. After the PDN-GW the connection is carried by the external bearer on SGi. S1AP signaling
between the E-UTRAN and MME will be used to establish the tunnel on S1-U and GTP-C signaling will
be used to create the tunnel on S5. On SGi we can see already plain IP trafc pure payload, so to
say.
The reference points shown in Figures xxx can be briey described as follows:
S1-MME: Reference point for the control plane protocol between the E-UTRAN and MME. This
control plane protocol is the S1AP, which is quite similar to UTRAN RANAP. Indeed, in early drafts of
LTE specs this protocol was called E-RANAP.
S1-MME Interface
Control interface between eNB and MME
MME and UE will exchange non-access stratum signaling via eNB through this
interface.
S1AP:S1 Application Protocol
NAS
S1AP
eNodeB
SCTP
IP
MME
S1-MME
Figure 5 S1-MME Interface
TK420
Page 8
S1-U: Reference point between the E-UTRAN and S-GW for the per bearer user plane tunneling and
inter-eNB path switching during handover. The protocol used at this reference point is the GPRS
Tunneling Protocol for the User Plane (GTP-U).
S1-U Interface
User Plane interface between eNB and serving gateway.
It is a pure user data interface
Which Serving GW a users SAE bearer will have to use is signaled from the MME of
this user.
User Data
GTP-U
eNodeB
UDP
IP
SGW
S1-U
Figure 6 S1-U interface
S3: This is the reference point between the MME and SGSN. The SGSN may serve UTRAN, GERAN,
or both. On S3 we can see plain control plane information for user and bearer information exchange
for inter-3GPP access network mobility (inter-RAT handover) in the idle and/or active state. If the
connection was set up originally in the E-UTRAN and is handed over to UTRAN/GERAN the
appropriate user plane streams are routed across the S4 reference point. What happens in the case
of UTRAN/GERAN to E-UTRAN handover depends on whether S-GW also acts as the anchor for
UTRAN/GERAN trafc. If this is true the user plane tunnel can be switched smoothly between S4 and
S1-U during the handover. The protocol used at the S3 reference point is the GTP-C.
S4: The S4 reference point provides related control and mobility support between the GPRS core
and the 3GPP anchor function of the S-GW using GTP-C. In addition, if a direct tunnel across S12 is
not established, it provides user plane tunneling using GTP-U.
S5: The S5 reference point provides user plane tunneling and tunnel management between the SGW and PDN-GW. It is used in case of S-GW relocation due to UE mobility and if the S-GW needs to
connect to a non-collocated PDN-GW for the required PDN connectivity. The protocol used at this
reference point is GTP for both the control plane and user plane.
S8: The S8 reference point is used by roaming subscribers only. It is the inter-PLMN reference point
providing the user plane and control plane between the S-GW in the Visited PLMN (VPLMN) and the
PDN-GW in the Home PLMN (HPLMN). S8 is the inter-PLMN variant of S5, based on GTP as well, and
can be compared to the Gp interface dened for GERAN GPRS. The S8 reference point is also used by
roaming subscribers only. It provides transfer of (QoS) policy and charging control information
between the home PCRF and the visited PCRF in order to support the local breakout function. For
TK420
Page 9
example, imagine a prepaid limit that can only be known by the home PCRF and must be provided to
the visited PCRF to allow roaming services for this user.
S5/S8 Interface
Interface between Serving GW and PDN GW

S5: If Serving GW and PDN GW belong to the same network
S8: If Serving GW and PDN GW belong to different networks
S8 = S5 + inter-operator security functions
Mainly used to transfer user packet data between PDN GW and Serving GW
Signaling on S5/S8 is used to setup the associated bearer resources
S5/S8 can be implemented either by reuse of the GTP protocol from 2G/3G or by using
Mobile IPv6 with some IETF enhancements.
User PDUs
GTPv1-U
GTPv2-C
UDP
SGW
S5/S8 Interface based

on GTP
PGW
IP
S5/S8
User PDUs
GRE
PMIPv6
S5/S8 Interface based

on PMIPv6
IPv4/IPv6
Figure 7 S5/S8 Interface
S6a: The S6a reference point enables the transfer of subscription and authentication data for
authorizing user access to the network. The reference point can be also described as the AAA
interface between the MME and HSS. Compared to the legacy core network of 2G/3G standards, the
functionality provided by S6a is similar to the one on the Gr interface, but due to the all-IP concept of
EPC the protocol used at this reference point is the DIAMETER protocol. In the IP world DIAMETER is
known as the successor of RADIUS, a protocol for granting access and authentication.
TK420
Page 10
S6a Interface
Interface between the MME and the HSS
The MME uses it to retrieve subscription and authentication information from HSS
(handover/tracking area restrictions, external PDN allowed, QoS, etc.) during attaches
and updates
The HSS can during these procedures also store the users current MME address in its
database.
S6a Application
DIAMETER
SCTP
IP
MME
HSS
S6a
Figure 8 S6a Interface
S7: This point provides transfer of (QoS) policy and charging rules from the PCRF to the Policy and
Charging Enforcement Function (PCEF) in the PDN-GW. This means that a set of rules for charging the
transmission of a particular user data stream (called service ow) will be requested by the PDN-GW
upon bearer establishment and the PCRF will provide the required parameters for the charging
process. Especially, it will signal which of the following charging models will apply:
Volume-based charging.
Time-based charging.
Volume- and time-based charging.
Event-based charging.
No charging (if the user pays at a monthly at rate).
Also, information about prepaid limits and other thresholds can be included.
TK420
Page 11
S7 Interface
Also referred as Gx
Interface between the PDN GW and the PCRF
It allows:
the PCRF to request the setup of a SAE bearer with appropriate QoS
the PDN GW to ask for the QoS of an SAE bearer to setup
to indicate EPC status changes to the PCRF to apply a new policy rule.
S7 Application
DIAMETER
SCTP
PGW
IP
PCRF
S7
Figure 9 S7 Interface
S10: This is the reference point between MMEs for MME relocation and MME-to-MME information
transfer. This reference point provides mobility functions for intra-E-UTRAN handover/relocation. In
other words, signaling procedures on this interface are triggered by UE mobility. It should be noted
that this kind of MME relocation in 3GPP 23.401 is called S1 handover.
S10 Interface
Interface between different MMEs
Used during inter-MME tracking area updates (TAU) and handovers
Inter-MME TAU: The new MME can contact the old MME the user had been registered
before to retrieve data about identity (IMSI), security information (security context,
authentication vectors) and active SAE bearers (PDN gateways to contact, QoS, etc.)
Obviously S10 is a pure signaling interface, no user data runs on it.
GTPv2-C
UDP
MME
IP
MME
S10
Figure 10 S10 interface
TK420
Page 12
S11: This is the reference point between the MME and S-GW. The protocol used here is the GTP-C.
The appropriate user plane is routed across S1-U.
S11 Interface
Interface between MME and a Serving GW
A single MME can handle multiple Serving GW each one with its own S11 interface
Used to coordinate the establishment of SAE bearers within the EPC
SAE bearer setup can be started by the MME (default SAE bearer) or by the PDN
Gateway.
GTPv2-C
UDP
SGW
IP
MME
S11
S12: The S12 reference point is located between the RNC in the 3G UTRAN and the S-GW for user
plane tunneling when a direct tunnel is established. It is based on the Iu user plane and Gn user
plane reference points using the GTP-U as dened between the SGSN and RNC, or between the SGSN
and GGSN in the 3G core network. Use of the S12 reference point is an operator conguration
option. On S12 only GTP-U trafc can be monitored, as on S1-U.
S13: This point enables a UE identity check procedure between the MME and EIR (Equipment
Identity Register). Typically there is no EIR installed in public networks due to the high administrative
efforts, but this network element is found in some private networks.
SGi: This is the reference point between the PDN-GW and the packet data network. This network
may be an operator external public or private packet data network or an intra-operator packet data
network, for example for the provision of IP Multimedia Subsystem (IMS) services. To simplify the
denition, it can be said that for many user plane connections SGi is the interface to the public
Internet. This reference point corresponds to Gi for 3GPP access. Typically the complete TCP/IP suite
can be monitored at this point.
TK420
Page 13
SGi Interface
Interface used by the PDN GW to send and receive data to and from the external data
network or Service Platform
It is either IPv4 or IPv6 based
This interface corresponds to the Gi interface in 2G/3G networks
Standardized in 3GPP TS 29.061: Interworking between the Public Land Mobile
Network (PLMN) supporting packet based services and Packet Data Networks (PDN)
GRE, L2TP, IPSEC
TCP/UDP
PGW
IP
Packet Data
Network
SGi
Figure 12 SGi Interface
Rx: The Rx reference point resides between the Application Function (AF) and the PCRF dened in
3GPP 23.203. It is for instance mandatory if real-time communication services such as Voice over IP
(VoIP) are to be charged differently than common PS data transfer.
Rx Interface
Interface between PCRF and the external PDN network/operators IMS (in general,
towards the Service Domain)
Standardized in 3GPP TS 29.214: Policy and Charging Control over the Rx reference
point (release 8)
Rx Application
DIAMETER
SCTP
PCRF
IP
P-CSCF
Rx
Figure 13 Rx Interface
TK420
Page 14
SBc: The SBc reference point lies between the Cell Broadcast Center (CBC) and MME for warning
message delivery and control functions. This interface is used to broadcast warning messages to
subscribers (not to send warning messages about network element status to the operation and
maintenance center). A typical example of such warning messages could be the broadcast of bush
re or tsunami alarms. The special anchor function of the S-GW can be illustrated when looking at a
connection that was handed over from the E-UTRAN to UTRAN or GERAN as shown in Figure 1.12. In
this case the connections on S5 and SGi remain the same, but the payload is now routed through a
tunnel across S4 or S12 while the signaling necessary to execute the inter-RAT mobility will be sent
across S3. The old bearers and signaling connections on S1 and LTE-Uu will be deleted after
successful handover of the connection.
Figure xxx illustrates the basic connection of a roaming subscriber. Signaling and payload take the
same route as in Figure xxx, but the HSS and PDN-GW and, thus, the connection to the public packet
network are located in a foreign network. The IP tunneling from the S-GW to PDN-GW and vice versa
is realized through the S8 interface, which has identical protocol structure and functions to S5. The
only difference is that S8 must fulll higher requirements in terms of inter-operability, because
equipment from different manufacturers must be interconnected through this reference point.
TK420
Page 15
4 EPC Protocols
4.1 SCTP protocol
SCTP refers to the Stream Control Transmission Protocol developed by the Sigtran working group
of the IETF for the purpose of transporting various signalling protocols over IP network.
The SCTP replaces TCP because of some drawbacks, which are:
TCP is stream (byte) oriented, whereas signaling usually comes in messages. So if a signaling protocol
uses TCP it would need its own message delineation mechanism.
TCP supports only one byte stream between two end-points per connection. Especially if one or more
bytes are missing, TCP will stop the delivery until the missing parts are successfully retransmitted. This
means a single error blocks the whole stream. For signaling purposes usually multiple streams are
needed that should not block each other.
TCP works with single endpoint addresses only. But to have transmission redundancy it should be
possible to have the data streams between two signaling endpoints shared between multiple IP
addresses.
SCTP overcomes these limitations with the following features:
TK420
Multi-streaming Instead of single connections like with TCP, we have SCTP associations that describe
the relation between two SCTP endpoints. Within an association SCTP supports multiple unidirectional
data streams (so called inbound and outbound streams). Different streams do not block each other,
but messages within one stream are sent in-sequence.
Message oriented: Instead of a byte stream oriented transmission SCTP will pack higher layer
messages in a frame to separate them. So the higher layer protocols need not to define their own
message delineation.
Multi-homing: SCTP endpoints provide the other endpoint (during association startup) with a list of
transport addresses (i.e., multiple IP addresses in combination with an SCTP port) through which that
endpoint can be reached and from which it will originate SCTP packets. A SCTP association can be
spanned across multiple endpoint IP addresses. This allows using multi-homed hosts. So redundancy
can be provided, when one address pair fails, another address pair possibly can take over. Multihoming is a pure redundancy mechanism. It is not used for load sharing.
Reliability: SCTP is a reliable transport protocol operating on top of a potentially unreliable
connectionless packet service such as IP. It is connection-oriented in nature. It offers acknowledged
error-free non-duplicated transfer of datagrams (messages). Detection of data corruption, loss of data
and duplication of data is achieved by using checksums and sequence numbers. A selective
retransmission mechanism is applied to correct loss or corruption of data.
Page 16
SCTP vs TCP
TCP drawbacks
SCTP features
TCP is stream (byte)

oriented
TCP supports only one
byte stream between
two end-points per
connection.
TCP works with single
endpoint addresses
only
Security in the
connection
establishment
multi-streaming.
multi-homing.
cookie mechanism and
collision resolution at
initialisation.
Data exchange features (e.g.
selective ACK, flow and
congestion control and data
lifetime).
SCTP shutdown.
Path supervision
Four way hand shake
Figure 14 SCTP vs TCP
SCTP association
A SCTP association describes the relation between two SCTP endpoints for the transport of several
unidirectional streams in both directions. At least one unidirectional stream between the endpoints
in each direction must be present. At most 2E16 = 65536 unidirectional streams in each direction are
possible. With respect to one endpoint the unidirectional data streams are categorized as inbound or
outbound streams.
The SCTP association is spanned across all IP address appearances of each endpoint. This allows
having several IP connections for the purpose of redundancy.
To distinguish between different associations SCTP assigns local port numbers. When a frame is sent
within an association the corresponding source and destination port numbers of SCTP are contained.
With this and the source and destination IP address the receiving endpoint can find out which
association the frame belongs to. One association uniquely corresponds to one SCTP user.
In the LTE, There is only one SCTP association established between one MME and eNB pair.
The eNB establishes the SCTP association. The SCTP Destination Port number value assigned by IANA
to be used for S1AP is 36412.
TK420
Page 17
SCTP for S1AP protocol

There is only one SCTP association established between one MME and
eNB pair.
The eNB establishes the SCTP association.
Once STCP association is established, S1AP Setup Procedures establish
the signaling connections.
The SCTP Destination Port number value assigned by IANA to be used for
S1AP is 36412.
Per MME and eNB pair:
Single stream of S1AP elementary procedures for non UE-associated
signalling.
Single/Multi streams of S1AP elementary procedures for UE-associated
signalling.
Single stream for UE-associated signalling
May support multi-homing for redundancy.
Figure 15 SCTP for S1AP protocol
SCTP Packet Structure
36412
Figure 16 SCTP Packet Structure
TK420
Page 18
Association establishment
MME
INIT
(Initialisation Tag: Tag_eNB)
INIT ACK
(Initialisation Tag: Tag_MME, state cookie)
COOKIE ECHO
(state cookie)
Resource
Resource
reservation
COOKIE ACK
reservation
Figure 17 Association establishment
4.1.1 SCTP packet

The protocol data units (PDU) of SCTP are called SCTP packets and form the payload of an IP packet.
An SCTP packet is composed of a common header and chunks. Multiple chunks can be bundled (as
known as chunk bundling) into one SCTP packet up to the MTU size, except for the INIT, INIT Ack, and
SHUTDOWN COMPLETE chunks. These chunks must not be bundled with any other chunk in a packet.
A chunk may contain either control information or user data.
The common header consists of 12 bytes. For the identification of an association, SCTP uses the same
port concept as TCP and UDP. For the detection of transmission errors, each SCTP packet is protected
by a 32 bit checksum, which is more robust than the 16 bit checksum of TCP and UDP. SCTP packets
with an invalid checksum are silently discarded. The common header also contains a 32 bit value
called verification tag. The receiver of the packet uses the verification tag to validate the sender of
this SCTP packet. The verification tag is association specific, and exchanged between the endpoints at
association start-up. So there are two tag values used in one association. During the association startup, the transmit side must set the value of this verification tag to the value of the initiate tag
TK420
Page 19
received from the peer endpoint except that a packet that contain an INIT chunk must have a zero
verification tag.
SCTP Packet Structure
36412
Figure 18 SCTP Packet Structure
Each chunk begins with a chunk type field, which is used to distinguish data chunks and different
types of control chunks, followed by chunk specific flags and a chunk length field needed because
chunks have a variable length. The usage of chunk flag depends on the chunk type as given by the
chunk type field. The value field contains the actual payload of the chunk.
So far there are 13 chunk types defined for standard use.
TK420
DATA chunk: Used to deliver user data.

INIT chunk: Used to initiate an SCTP association between two endpoints
INIT ACK chunk: Used to acknowledge the initiation of an SCTP association. The parameter part of INIT
ACK is formatted similarly to the INIT chunk.
COOKIE ECHO chunk: This chunk is used only during the initialization of an association. It is sent by the
initiator of an association to its peer to complete the initialization process
COOKIE ACK chunk: This chunk is used only during the initialization of an association. It is used to
acknowledge the receipt of a COOKIE ECHO chunk.
SACK chunk: This chunk is sent to the peer endpoint to acknowledge received DATA chunks and to
inform the peer endpoint of gaps in the received subsequences of DATA chunks as represented by
their TSNs.
HEARTBEAT chunk: An endpoint should send this chunk to its peer endpoint to probe the reachability
of a particular destination transport address defined in the present association.
HEARTBEAT ACK chunk: An endpoint should send this chunk to its peer endpoint as a response to a
HEARTBEAT chunk
Abort chunk: The ABORT chunk is sent to the peer of an association to close the association. The
ABORT chunk may contain Cause Parameters to inform the receiver the reason of the abort
ERROR chunk: An endpoint sends this chunk to its peer endpoint to notify it of certain error
Page 20
conditions.
SHUTDOWN chunk: An endpoint in an association MUST use this chunk to initiate a graceful close of
the association with its peer
SHUTDOWN ACK chunk: This chunk must be used to acknowledge the receipt of the SHUTDOWN
chunk at the completion of the shutdown process
SHUTDOWN COMPLETE chunk: This chunk MUST be used to acknowledge the receipt of the
SHUTDOWN ACK chunk at the completion of the shutdown process
SCTP Chunks
ID
Chunk Type
Description
DATA
Used to deliver user data
INIT
Used to initiate SCTP association
INIT ACK
Used to acknowledge the initiation of an SCTP association.
SACK
Used to acknowledge received DATA chunks
HEARTBEAT
Used to to probe the reachability of a particular destination
HEARTBEAT ACK
Used as a response to a HEARTBEAT chunk.
ABORT
Used to close the association. It may contain Cause parameter to inform the receiver the
reason of the abort.
SHUTDOWN
Use this chunk to initiate a graceful close of the association with its peer.
SHUTDOWN ACK
Used to acknowledge the receipt of the SHUTDOWN chunk
ERROR
Used to notify the peer endpoint of certain error conditions
10
COOKIE ECHO
Sent by the initiator of an association to its peer to complete the initialization process.
11
COOKIE ACK
Used to acknowledge the receipt of a COOKIE ECHO chunk.
14
SHUTDOWN
COMPLETE
Used to acknowledge the receipt of the SHUTDOWN ACK
Figure 19 SCTP Chunks
4.1.2 SCTP functions
TK420
Page 21
SCTP Functions
Association Start-up and Takedown
Sequenced Delivery within Streams
User Data Fragmentation
Acknowledgement and Congestion Avoidance
Chunk Bundling
Packet Validation
Path Management
Figure 20 SCTP Functions
Association Start-up and Takedown

An association is initiated by a request from the SCTP user. A cookie mechanism is employed during
the initialization to provide protection against synchronization attacks. The cookie mechanism uses a
four-way handshake, the last two legs of which are allowed to carry user data for fast setup.
SCTP vs TCP
TCP drawbacks
SCTP features
TCP is stream (byte)

oriented
TCP supports only one
byte stream between
two end-points per
connection.
TCP works with single
endpoint addresses
only
Security in the
connection
establishment
multi-streaming.
multi-homing.
cookie mechanism and
collision resolution at
initialisation.
Data exchange features (e.g.
selective ACK, flow and
congestion control and data
lifetime).
SCTP shutdown.
Path supervision
Four way hand shake
In TCP, the attacker can issues a vast amount of SYN request, which is a message requesting setup of
a connection to the server and when it receive the SYN ACK reply from the server, it just simply
discards it, not responding with ACK as it should be in normal setup. This causes the server to retain
TK420
Page 22
the partial state that was allocated after the SYN request, and it will lead to a denial of service if
carried out repeatedly.
Connection establishment
denial of service
attack
normal connection
establishment
A
Attacker
SYN Request
SYN ACK
Server
SYN Requests
Resource allocated
Connection in
partial state
SYN ACK
Resources allocated
Connections in
partial state
ACK
ACK
Connection established
Attacker never sends ACK
Server overloaded
Figure 21 Connection establishment
For SCTP, rather than allocating memory for a Transmission Control Block (TCB), the server instead
encrypts enough information to build its TCB an internal key and sends this as a Cookie parameter in
the INIT ACK. Since the INIT ACK always goes back to the source address of the INIT, the blind
attacker will not get the cookie. A valid SCTP client will get the Cookie and return it in the COOKIE
ECHO chunk, where the SCTP server can decrypt the Cookie and verify that it is valid.
The establishment process consists of the following steps:
TK420
The eNB first sends an INIT chunk to the MME. In the INIT, the eNB must provide its Verification Tag
(Tag_eNB) in the Initiate Tag field.
MME shall respond immediately with an INIT ACK chunk. In the response, besides filling in other
parameters, MME must set the Verification Tag field to Tag_eNB, and also provide its own Verification
Tag (Tag_MME) in the Initiate Tag field. Moreover, MME must generate and send along with the INIT
ACK a State Cookie.
Upon reception of the INIT ACK from the MME, the eNB shall then send the State Cookie received in
the INIT ACK chunk in a COOKIE ECHO chunk.
Upon reception of the COOKIE ECHO chunk, the MME will reply with a COOKIE ACK chunk. An
association is in established state at this point for the MME.
Upon reception of the COOKIE ACK, the eNB will be in established state.
Page 23
Association establishment
MME
INIT
(Initialisation Tag: Tag_eNB)
INIT ACK
(Initialisation Tag: Tag_MME, state cookie)
COOKIE ECHO
(state cookie)
Resource
Resource
reservation
COOKIE ACK
reservation
SCTP provides for graceful close (i.e., shutdown) of an active association on request from the SCTP
user. SCTP also allows ungraceful close (i.e., abort), either on request from the user (ABORT
primitive) or as a result of an error condition detected within the SCTP layer.
Both sides may decide to terminate an SCTP association for a number of reasons, and can do so
practically at any time.
Graceful termination of the SCTP association in Established state can be triggered by:
SCTP internal event (local SCTP endpoint failure, Shutdown chunk, Abort chunk)
OAM (physical links deactivation, node deactivation)
Radio Network Layer (inclusion of the eNB containing the entry for a given X2 link in Global
eNB Id X2-link Blacklist)
After successful termination of SCTP association:
State changes from Established to Closed.

SCTP endpoint sends an indication to C-plane with association ID.
SCTP endpoint sends an indication to OAM with association ID.
SCTP endpoint removes secondary MME IP address from OAM database if association to a multihomed MME has been terminated.
Graceful Termination of an Association

Upon receiving the SHUTDOWN primitive from its upper layer, an SCTP endpoint should stop
accepting data from its upper layer. It waits for all outstanding data to be acknowledged by its peer.
It can retransmit data to the far end if necessary to fill gaps. Once all its outstanding data has been
acknowledged, it starts sending a SHUTDOWN chunk to its peer including the Cumulative TSN Ack
field the last sequential TSN it has received from the peer. Upon reception of the SHUTDOWN, the
peer endpoint stop accepting new data from its SCTP user and verify by checking the Cumulative TSN
TK420
Page 24
ACK field of the chunk, that all its outstanding DATA chunks have been received by the SHUTDOWN
sender. If there are still outstanding DATA chunks left, it continues to follow normal data
transmission procedures until all outstanding DATA chunks are acknowledged.
Association Termination: graceful

shutdown
MME
SHUTDOWN
(cumulative TSN acknowledgement)
send outstanding data chunks
acknowledge outstanding data chunks
with shutdown-chunk
SHUTDOWN ACK
SHUTDOWN COMPLETE
Figure 22 Association termination: graceful shutdown
Aborting an association
An endpoint may also decide to abort an existing association by sending an ABORT chunk to its peer
endpoint, taking into account that data still in flight may not be acknowledged.
Ungraceful termination of an SCTP association can be caused by:
Abort chunk received from peer endpoint
unsuccessful X2 link setup on Radio Network Layer
locally triggered Abort command caused by following SCTP internal reasons:
receipt of an SCTP INIT chunk from adjacent eNB, which hasnt been sent from OAMcontrolled IP address (only when the ANR is deactivated)
maximum number of supported adjacent eNBs reached (ANR-related event)
other SCTP internal events specified in RFC4960
In both cases, the SCTP endpoint sends the User-Initiated error cause to C-plane for the corresponding
association.
Upon termination of any OAM-controlled X2 SCTP association at an eNB, it continuously attempts to

initialize the lost (Closed) associations to all available peer eNBs that are not already connected via
Established association.
The sender must fill in the peer's Verification Tag in the outbound packet and must not bundle any
DATA chunk with the ABORT.
TK420
Page 25
The receiver of the ABORT does not reply, but validates the chunk, and removes the association, if
the ABORT contains the correct tag value. If so, it also reports termination to its upper layer process.
Sequenced Delivery within Streams

The term "stream" is used in SCTP to refer to a sequence of user messages that are to be delivered to
the upper-layer protocol in order with respect to other messages within the same stream. This is in
contrast to its usage in TCP, where it refers to a sequence of bytes.
The SCTP user can specify at association start-up time the number of streams to be supported by the
association. This number is negotiated with the remote end. User messages are associated with
stream numbers. Internally, SCTP assigns a stream sequence number to each message passed to it
by the SCTP user. On the receiving side, SCTP ensures that messages are delivered to the SCTP user
in sequence within a given stream. However, while one stream may be blocked waiting for the next
in-sequence user message, delivery from other streams may proceed.
User Data Fragmentation
When needed, SCTP fragments user messages to ensure that the SCTP packet passed to the lower
layer conforms to the path MTU. On receipt, fragments are reassembled into complete messages
before being passed to the SCTP user.
Acknowledgement and Congestion Avoidance
SCTP assigns a Transmission Sequence Number (TSN) to each user data fragment or unfragmented
message. The TSN is independent of any stream sequence number assigned at the stream level. The
receiving end acknowledges all TSNs received, even if there are gaps in the sequence. In this way,
reliable delivery is kept functionally separate from sequenced stream delivery.
The acknowledgement and congestion avoidance function is responsible for packet retransmission
when timely acknowledgement has not been received. Packet retransmission is conditioned by
congestion avoidance procedures similar to those used for TCP.
Chunk Bundling
The SCTP packet delivered to the lower layer consists of a common header followed by one or more
chunks. Each chunk may contain either user data or SCTP control information. The SCTP user has the
option to request bundling of more than one user messages into a single SCTP packet. The chunk
bundling function of SCTP is responsible for assembly of the complete SCTP packet and its
disassembly at the receiving end.
Packet Validation
A mandatory Verification Tag field and a 32 bit checksum field are included in the SCTP common
header. The Verification Tag value is chosen by each end of the association during association startup.
Packets received without the expected Verification Tag value are discarded, as a protection against
blind masquerade attacks and against stale SCTP packets from a previous association. The checksum
should be set by the sender of each SCTP packet to provide additional protection against data
corruption in the network. The receiver of an SCTP packet with an invalid checksum silently discards
the packet.
Path Management
TK420
Page 26
The sending SCTP user is able to manipulate the set of transport addresses used as destinations for
SCTP packet. The SCTP path management function chooses the destination transport address for
each outgoing SCTP packet based on the SCTP users instruction and the currently perceived
reachability status of the eligible destination set.
The path management function monitors reachability through heartbeats when other packet traffic
is inadequate to provide this information and advises the SCTP user when reachability of any far-end
transport address changes. The path management function is also responsible for reporting the
eligible set of local transport addresses to the far end during association startup, and for reporting
the transport addresses returned from the far end to the SCTP user.
At association startup, a primary path is defined for each SCTP endpoint, and is used for normal
sending of SCTP packets
On the receiving end, the path management is responsible for verifying the existence of a valid SCTP
association to which the inbound SCTP packet belongs before passing it for further processing.
4.2 S1AP protocol

4.2.1 S1AP functions
S1AP provides the signalling service between E-UTRAN and the evolved packet core (EPC)
S1AP protocol has the following functions (TS 36.413 section 7):
TK420
E-UTRAN radio access bearer (E-RAB) management function: This functionality is responsible for
setting up, modifying and releasing E-RABs, which are triggered by the MME. The release of E-RABs
may be triggered by the eNB as well.
Initial Context Transfer function which is used to:
establish an S1UE context in the Enb
setup the default IP connectivity
Page 27
setup one or more E-RABs if requested by the MME

transfer NAS-signalling related information to the eNB, if needed.
UE Capability Info Indication function which is used to provide the UE Capability Info when received
from the UE to the MME
The Paging function which provides the EPC the capability to page the UE.
The S1 interface management functions that comprise the:
Reset functionality to ensure a well-defined initialisation on the S1 interface.
Error Indication functionality to allow proper error reporting/handling in cases where no
failure messages are defined.
S1 Setup functionality for initial S1 interface setup for providing configuration information
eNB and MME Configuration Update functions are to update application level configuration data
needed for the eNB and MME to interoperate correctly on the S1 interface.
NAS Signalling transport function between the UE and the MME
S1 UE context Release function: This functionality is responsible to manage the release of UE specific
context in the eNB and the MME.
UE Context Modification function: This functionality allows to modify the established UE Context
partly.
Location Reporting: This functionality allows MME to be aware of the UE"s current location.
S1 Application Protocol (S1-AP)

S1AP services
Non UE-associated services
They are related to the whole S1 interface instance
between the eNB and MME.
UE-associated services
They are related to one UE.
UE-associated logical S1-connection, uses the
identities MME UE S1AP ID and eNB UE S1AP ID
S1AP elementary procedures:
Class1: Elementary Procedures with response (success
and/or failure).
E.g. Initial Context Setup Request/ Response.
Class2: Elementary Procedures without response.
E.g. Initial UE Message.
Figure 23 S1AP
TK420
Page 28
4.2.2 S1AP procedure

In the following tables, all elementary procedures (EPs) are divided into Class 1 and Class 2 EPs:
S1AP EP class 1
Elementory
Procedure
Initiating
Message
Successful
Outcome/Response message
Unsuccessful Outcome/Response
message
Handover
Preparation
HANDOVER
REQUIRED
HANDOVER COMMAND
HANDOVER
PREPARATION FAILURE
Handover
Resource
Allocation
HANDOVER
REQUEST
HANDOVER REQUEST
ACKNOWLEDGE
HANDOVER FAILURE
Path Switch
Request
PATH SWITCH
REQUEST
UPATH SWITCH
REQUEST
ACKNOWLEDGE
PATH SWITCH REQUEST

FAILURE
Handover
Cancellation
HANDOVER
CANCEL
HANDOVER CANCEL
ACKNOWLEDGE
E-RAB Setup
E-RAB SETUP
REQUEST
E-RAB SETUP
RESPONSE
E-RAB Modify
E-RAB MODIFY
REQUEST
E-RAB MODIFY
RESPONSE
E-RAB Release
E-RAB RELEASE
COMMAND
E-RAB RELEASE
RESPONSE
Figure 24 S1AP EP Class 1
TK420
Page 29
S1AP EP class 1 (suite)

Elementory
Procedure
Initiating
Message
Successful Outcome/Response
message
Unsuccessful Outcome/Response
message
Initial Context
Setup
INITIAL CONTEXT
SETUP REQUEST
NITIAL CONTEXT
SETUP RESPONSE
INITIAL CONTEXT SETUP

FAILURE
Reset
RESET
RESET
ACKNOWLEDGE
S1 Setup
S1 SETUP REQUEST
S1 SETUP RESPONSE
UE Context
Release
UE CONTEXT
RELEASE
COMMAND
UE CONTEXT RELEASE
COMPLETE
UE Context
Modification
UE CONTEXT
MODIFICATION
REQUEST
UE CONTEXT
MODIFICATION
RESPONSE
UE CONTEXT
MODIFICATION FAILURE
eNB
Configuration
Update
ENB
CONFIGURATION
UPDATE
ENB CONFIGURATION
UPDATE
ACKNOWLEDGE
ENB CONFIGURATION
UPDATE FAILURE
MME
Configuration
Update
MME
CONFIGURATION
UPDATE
MME CONFIGURAION
UPDATE
ACKNOWLEDGE
MME CONFIGURATION
UPDATE FAILURE
Write-Replace
Warning
WRITE-REPLACE
WARNING
REQUEST
WRITE-REPLACE
WARNING RESPONSE
S1 SETUP FAILURE
Figure 25 S1AP EP Class 1 suite
S1AP EP class 2
Elementory Procedure
Message
Handover Notification
HANDOVER NOTIFY
E-RAB Release Indication
E-RAB RELEASE INDICATION
Paging
PAGING
Initial UE Message
INITIAL UE MESSAGE
Downlink NAS Transport
DOWNLINK NAS TRANSPORT
Uplink NAS Transport
UPLINK NAS TRANSPORT
NAS non delivery indication
NAS NON DELIVERY INDICATION
Error Indication
ERROR INDICATION
UE Context Release Request
UE CONTEXT RELEASE REQUEST
DownlinkS1 CDMA2000 Tunneling
DOWNLINK S1 CDMA2000
TUNNELING
Uplink S1 CDMA2000 Tunneling
UPLINK S1 CDMA2000 TUNNELING
UE Capability Info Indication
UE CAPABILITY INFO INDICATION
eNB Status Transfer
eNB STATUS TRANSFER
MME Status Transfer
MME STATUS TRANSFER
Figure 26 S1AP EP Class 2
TK420
Page 30
S1AP EP class2 (suite)

Elementory Procedure
Message
Trace Failure Indication
TRACE FAILURE INDICATION
Location Reporting Control
LOCATION REPORTING CONTROL
Location Reporting Failure

Indication
LOCATION REPORTING FAILURE

INDICATION
Location Report
LOCATION REPORT
Overload Start
OVERLOAD START
Overload Stop
OVERLOAD STOP
eNB Direct Information Transfer
eNB DIRECT INFORMATION

TRANSFER
MME Direct Information Transfer
MME DIRECT INFORMATION

TRANSFER
eNB Configuration Transfer
eNB CONFIGURATION TRANSFER
MME Configuration Transfer
MME CONFIGURATION TRANSFER
Cell Traffic Trace
CELL TRAFFIC TRACE
Deactivate Trace
DEACTIVATE TRACE
Trace Start
TRACE START
Figure 27 S1AP EP Class 2 suite
The following applies concerning interference between Elementary Procedures:
The Reset procedure takes precedence over all other EPs.

The UE Context Release procedure takes precedence over all other EPs that are using the UEassociated signalling.
4.3 NAS protocols

This part specifies the procedures used by the protocols for mobility management and session
management between UE and MME. These protocols belong to the non-access stratum (NAS).
The EPS Mobility Management (EMM) protocol provides procedures for the control of mobility when
the UE is using the E-UTRAN. The EMM protocol also provides control of security for the NAS
protocols.
The EPS Session Management (ESM) protocol provides procedures for the handling of EPS bearer
contexts. Together with the bearer control provided by the access stratum, this protocol is used for
the control of user plane bearers.
For both NAS protocols the present document specifies procedures for the support of inter-system
mobility between E-UTRAN and other 3GPP or non-3GPP access networks:
For inter-system mobility between E-UTRAN and GERAN or UTRAN, this includes rules for a mapping
between parameters and procedures used by the NAS protocols.
For inter-system mobility between E-UTRAN and generic non-3GPP access networks, this includes
specific NAS procedures to maintain IP connectivity to the PDN-GW and to provide parameters
needed by the UE when using mobility management based on Dual-Stack Mobile IPv6 or MIPv4.
Linkage between the protocols for EMM and ESM:

TK420
Page 31
The ESM messages for the default EPS bearer context activation are transmitted in an IE in the EMM
messages.
The success of the attach procedure is dependent on the success of the default EPS bearer context
activation procedure. If the attach procedure fails, the the ESM procedures also fail.
Except for the attach procedure, during EMM procedures the transmission of ESM messages shall be
suspended.
4.3.1 EMM procedures

The function of the mobility management sublayer is
to support the mobility of a user equipment, such as informing the network of its present location and
providing user identity confidentiality.
to provide connection management services to the session management (SM) sublayer and the short
message services (SMS) entity of the connection management (CM) sublayer.
Depending on how they can be initiated, three types of EMM procedures can be distinguished:
EMM common procedures:

GUTI reallocation;
authentication;
security mode control;
identification;
EMM information.
EMM specific procedures
attach and combined attach.
detach and combined detach.
Normal and periodic tracking area updating (S1 mode only);
EMM connection management procedures (S1 mode only)
service request.
paging procedure.
Following the list of all the EMM messages:
TK420
Page 32
EMM messages
Attach request
Authentication request
Attach accept
Authentication response
Attach complete
Authentication reject
Attach reject
Authentication failure
Detach request
Identity request
Detach accept
Identity response
Tracking area update request
Security mode command
Tracking area update accept
Security mode complete
Tracking area update complete
Security mode reject
Tracking area update reject
EMM status
Extended service request
EMM information
Service request
Downlink NAS transport
GUTI reallocation command
Uplink NAS transport
GUTI reallocation complete
CS Service notification
Figure 28 EMM messages
4.3.2 ESM procedures

The main function of the ESM sublayer is to support the EPS bearer context handling in the UE and in
the MME.
Two types of ESM procedures:
Procedures related to EPS bearer contexts , which are initiated by the network and are used for the
manipulation of EPS bearer contexts:
default EPS bearer context activation;
dedicated EPS bearer context activation;
EPS bearer context modification;
EPS bearer context deactivation.
Transaction related procedures, which are initiated by the UE to request for resources, i.e. a new PDN
connection or dedicated bearer resources, or to release these resources:
PDN connectivity procedure;
PDN disconnect procedure;
bearer resource allocation procedure;
bearer resource modification procedure.
Following the list of all the EMM messages:
TK420
Page 33
ESM messages
Activate default EPS bearer context request
PDN connectivity request
Activate default EPS bearer context accept
PDN connectivity reject
Activate default EPS bearer context reject
PDN disconnect request
Activate dedicated EPS bearer context request
PDN disconnect reject
Activate dedicated EPS bearer context accept
Bearer resource allocation request
Activate dedicated EPS bearer context reject
Bearer resource allocation reject
Modify EPS bearer context request
Bearer resource modification request
Modify EPS bearer context accept
Bearer resource modification reject
Modify EPS bearer context reject
ESM information request
Deactivate EPS bearer context request
ESM information response
Deactivate EPS bearer context accept
ESM status
Figure 29 ESM messages
4.3.3 NAS Message Format

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.
If the message is a plain NAS message:
protocol discriminator;
EPS bearer identity or security header type;
procedure transaction identity;
message type;
other information elements, as required.
If the message is a security protected NAS message:
TK420
protocol discriminator;
security header type;
message authentication code;
sequence number;
plain NAS message.
Page 34
Plain NAS message

EPS bearer identity
or Security header type
Protocol discriminator
Procedure transaction identity

Message type
Other information elements as required (n octets)
Security protected NAS message

Security header type
Protocol discriminator
Message authentication code (4 osctets)
Sequence number
NAS message (n octets)
Figure 30 NAS message format
4.4 DIAMETER Base Protocol
The diameter protocol is yet another AAA protocol. It addresses many of the shortcomings of other
AAA protocols such as the RADIUS protocol. The name is a pun on RADIUS: In geometry Diameter is
twice the Radius.
Compatibility to RADIUS is maintained by the NASReq application, which enables RADIUS
functionality on top of a diameter based infrastructure. Furthermore similarities between RADIUS
and Diameter exist concerning the transport of information AVPs which are grouped together in
messages.
The main key features of the Diameter protocol are:
Reliable Transport
Diameter runs over a reliable transport that offers congestion control (e.g., TCP, SCTP). In
particular, Diameter does not run over UDP. Unlike RADIUS, lost Diameter messages are retransmitted
at each hop.
Diameter provides an application-level heartbeat message that monitors the status of the connection
and allows recovery in failure situations.
Diameter also allows accounting messages to be routed to a different server than
authentication/authorization messages.
The standard port used for Diameter is 3868.
TK420
Inband security
Page 35

The Transport Layer Security (TLS) protocol allows applications to communicate across a network in a
way designed to prevent eavesdropping, tampering and message forgery.
Capabilities Negotiation
The first time two Diameter peers communicate after having established a transport connection (TCP
connection or a SCTP association), they exchange so called Capabilities Exchange messages
(Capabilities Exchange Request/ Capabilities Exchange Answer).
These messages contain the peers identity and its capabilities (e.g. Supported Diameter applications,
the protocol version number ). This ensures that a peer only sends commands to other peers that
support the associated application.
Error notification
As opposed to RADIUS, Diameter enforced meaningful and well-defined error messages. There are
two different types of violations: those on protocol level and those on application level.
Link State Health Monitoring

In case a peer connection is idle or a response for an outstanding request has not been received
timely, peers can send so called Devise-Watchdog-Requests and answers (DWR/DWA). These
messages are used to proactively detect transport failures.
Additional Applications
In Diameter, it is possible to create or extend existing ones. And it is possible also to implement
custom functionality or business logic.
Applications are developed as extensions, so new applications are developed when needed.
A variety of applications already exists, covering of cases found in an operators environments.
Session Control
Session management is independent of accounting. Accounting information can be routed to a
different server than authentication/authorization messages. Session termination is conveyed by a
specific Session-Termination message rather than an Accounting Stop message. The server may
initiate a message to request session termination.
TK420
Page 36
Key Features of diameter
Symmetric (both peers may act as client/server)

Reliable transport (by TCP or SCTP)
Inband security (by TLS)
Capabilities negotiation
Error notification
Failover / Link state health monitoring
Routing based on message information
Extensibility (additional applications, vendor
specific AVPs)
Figure 31 Key Features of Diameters
TK420
Page 37
4.4.1 Basic terms

The Diameter Base protocol is defined in RFC3588. It is extended to provide an Authentication,
Authorization and accounting (AAA) framework for different applications. The Diameter Base
Protocol provides the minimum requirements needed for an AAA protocol.
In the context of Diameter, network element can usually assume the role of a client, a server or one
of the agents described below:
Client
A Diameter Client is a device at the edge of the network that performs access control. A diameter
client generates Diameter messages to request authentication, authorization and accounting services
for the user. Diameter clients must support the base protocol, which includes accounting. In
implement the clients service.
Server
A Diameter server performs authentication and/or authorization of the user. A Diameter node may
act as an agent for certain requests while acting as a server for others. Diameter servers must
support the base protocol, which includes accounting. In addition, they must fully support each
Diameter application that is needed to implement the intended service.
Proxy Agent
Similar to the relay agent, the proxy agent accept diameter messages and route them using to
Realm-Based Routing Table. In addition to forwarding Diameter messages, makes policy decisions
relating to resource usage and provisioning (this is the difference between relay and proxy). A proxy
may modify messages to implement policy decisions, such as controlling resource usage, providing
admission control, and provisioning.
Relay Agent
Relay Agent are Diameter agents that accept requests and route messages to other Diameter nodes
based on information (AVPs) found in the messages (e.g. Destination-Realm, Host-Realm ). This
routing decision is performed using a list of supported realms, and known peers (Peer Routing
Table). Relays may be used to aggregate requests from multiple Network Access Servers (NASes)
within a common geographical area. The use of Relays is advantageous since it eliminates the need
for NASes to be configured with the necessary security information they would otherwise require to
communicate with Diameter servers in other realms. Likewise, this reduces the configuration load on
diameter servers that would otherwise be necessary when NASes are added, changed or deleted.
Relays modify Diameter messages by inserting and removing routing information, but do not modify
any other portion of a message.
A relay is typically transparent. It can modify Diameter messages only by inserting or removing
routing-related data, but cant modify other data.
Redirect Agent
TK420
Page 38
Redirect Agent refers clients to servers and allows them to communicate directly. The Redirect
Agents are useful in scenarios where the Diameter routing configuration needs to be centralized. An
example is a redirect that provides services to all members of a consortium, but does not wish to be
burdened with relaying all messages between realms. This scenario is advantageous since it does not
require that the consortium provide routing updates to its members when changes, and only return
an answer with the information necessary for Diameter agents to communicate directly, they dont
modify messages. Since redirect agents dont receive answer messages, they cant maintain session
state. Further, since redirect agents never relay requests, they are not required to maintain
transaction state.
Translation Agent
A Translation Agent is a device that performs protocol translation between Diameter and other AAA
protocols, such as RADIUS. Translation agents are likely to be used as aggregation servers to
communicate with a Diameter infrastructure, while allowing for the embedded systems to be
migrated at a slower pace.
Given that the Diameter protocol introduces the concepts of long-living authorized sessions,
translation agents must session stateful and must maintain transaction state.
Transaction of messages can only occur if the agent recognizes the application of a particular
request, and therefore translation agents must only advertise their locally supported applications.
Diameter nodes
Clients
Server
Relay agent
Proxy agent
Redirect agent
Translation agent
Figure 32 Diameter nodes
TK420
Page 39
Diameter base protocol: basic terms

The diameter base protocol is a peer-to-peer protocol
Connection: transport level connection between two
peers
Session: logical concept at the application layer
Client: performs access control, generates diameter
messages to request services for the user
Server: performs authentication, authorization and
accounting for the user, generates diameter answer
messages
Relay agent: accept requests and route messages to
other Diameter nodes
Figure 33 Diameter base protocol: basic terms
TK420
Page 40
Diameter connections and sessions

Client
Request
Request
Relay
Answer
Peer connection A
Answer
Server
Peer connection B
User session
RFC 3588
Figure 34 Diameter connections and sessions
The diameter base protocol is a peer-to-peer protocol. Any node can initiate a request
A connection is a transport level connection between two peers, used to send and receive Diameter
messages.
A session is a logical concept at the application layer, and is shared between the Diameter Client and
the Diameter Server. It is identified via the Session-Id AVP. The Session-Id is globally unique and is
meant to uniquely identify a user session without reference to any other information.
4.4.2 Diameter Message Structure
As already mentioned above, the diameter base protocol all by itself can only be used for basic
accounting purposes, as this functionality is part of the base protocol. It is possible and necessary to
extend the base protocol with applications that provide additional functionality.
TK420
Page 41
The base protocol itself provides basic mechanisms for reliable transport, message delivery and error
handling. All applications rely on the basic services of the base protocol. The latter defines the basic
diameter message format.
Diameter messages contain data in the form of collection of AVPs (comparable to RADIUS
attributes).
A diameter message consists of a fixed-length header followed by a variable number of AVPs.
There are two types of messages, Request and Answers. There are few circumstances where a
request is silently discarded, and therefore the originator of request will nearly always receive an
answer. Every answer message carries a Result-Code AVP. The data value of the Result-Code AVP is
an integer code indicating whether a particular request was completed successfully or an error
occurred. Every Diameter message carries the diameter identity of the originating Diameter process
in the Origin-Host AVP. Every Diameter message also carries the realm of the originating Diameter
process in the Origin-Realm AVP.
Diameter messages consist of the header with 20 octets that is followed by a variable number of
AVPs for the actual data.
An AVP is used to encapsulate protocol-specific data. It is possible, for a new application, to create a
new AVP or define a new AVP value. Of course, new applications should attempt to reuse AVPs
defined in existing application always when possible.
In order to create a new AVP, a request must be sent to IANA, with a specification for this AVP. The
request must include the commands that would make use of this AVP.
4.4.3 Diameter Header

Diameter header
Version: the version field must be set to 1 to indicate Diameter Version 1.
Message length: the Message length field is three octets and indicates the length of the Diameter
message including the header fields.
Command-Code: The Command-Code field is also three octets, and is used to identify Diameter
commands. This field is used to determine the action that is to be taken for a particular message.
Both the request and the answer for a given command share the same command code.
Command Flags: the Command Flags field consists of eight bits
RPETrrrr
R (Request) or REQ: if set, the message is a request. If cleared, the message is an answer.
P (Proxiable) or PRX: if set, the message may be proxied, relayed or redirected. Else, the message
must be locally processed.
E (Error) or ERR: if set, the message contains a protocol error. This bit must not be set in the request
messages.
T (potentially re-transmitted message): this flag is set after a link failover procedure, to aid the
removal of duplicate requests. It is set when resending request not yet acknowledged, as an indication
TK420
Page 42

of a possible duplicate due to a link failure. This bit must be cleared when sending a request for the
first time.
R (Reserved): these flag bits are reserved for future use, and must be set to zero, and ignored by the
receiver.
Application-ID
The application-ID id four octets and is used to identify a specific Diameter (in this context the
meaning of application is called a protocol) to which the message is applicable. The application can
be an authentication application, an accounting application or a vendor specific application. There
are standards-track application ids and vendor specific application ids. IANA has assigned the range
0*00000001to 0*00ffffff for standards-track applications; and 0*01000000 to 0*ffffffe for vendor
specific applications.
The following values are some well-known application-ID for standard applications:
Diameter Common Messages: 0
NASREQ: 1 [NASREQ]
Mobile-IP: 2 [DIAMMIP]
Diameter Base Accounting: 3
Hop-by-Hop Identifier
The Hop-by-Hop Identifier is an unsigned 32-bit integer field and aids in matching requests and
replies. The sender of an Answer message must ensure that the Hop-by-Hop Identifier field contains
the same value that was found in the corresponding request. The Hop-by-Hop Identifier is normally a
monotonically increasing number, whose start value was randomly generated. An answer message
that is received with an unknown Hop-by-Hop Identifier MUST be discarded.
End-to-End Identifier
The End-to-End Identifier is also an unsigned 32-bit integer field and is used to detect duplicated
messages. Senders of request messages MUST insert a unique identifier on each message. The same
End-to-End identifier of the request is used in the answer. Duplicated requests should cause the
same to be transmitted. Duplicated answer should be discarded.
TK420
Page 43
Version
Message Length
Command
Command-Code
Flags
Application-ID
Hop-by-Hop identifier
End-to-End identifier
AVPs
.
.
31
20
Bytes
Figure 35 Diameter message structure
4.4.4 AVP Attribute-Value-Pair

Diameter messages, like RADIUS messages, transport a collection of Attribute Value Pairs
(AVPs). An AVP is a container of data, so it carries specific details for the request and reply.
Some AVPs may be listed more than once.
AVP consists of a Header, called AVP Header, following by AVP Data
AVP header
AVP Header consists of:
TK420
AVP Code
Page 44
AVP Length
AVP Flags
Vendor Id
AVP Code
The AVP Code in conjunction with the Vendor-ID eld, if present, uniquely identifies the attribute.
The absence of a Vendor-ID eld or a Vendor-ID eld with a value set to zero indicates a standard
AVP specied in an IETF specication. AVP code numbers ranging from 1 to 255 identify attributes
imported from or already dened by RADIUS. AVP numbers 256 and higher identify Diameter-specic
attributes. They are allocated by IANA.
AVP Flags
The AVP flags field informs the receiver how each attribute must be handled.
VMPrrrrr
V (Vendor-Specific): the vendor specific bit indicates whether the optional Vendor-ID field is present
in the AVP header. When set, the AVP code belongs to the specific vendor code address space.
M (Mandatory): the M bit indicates that support of the AVP is required. If an AVP with the M bit set
is received by a Diameter agent and either the AVP or its value is unrecognized, the message must be
rejected. AVPs with the M bit cleared are informational only and a receiver that receives a message
with such an AVP that is not supported, or whose value is not supported, may simply ignore this AVP.
P (Protected): the protected bit indicates the need for encryption for end-to-end security.
R (reserved): those bits are unused and should be set to 0.
TK420
Page 45
VMPrrrrr
AVP Code
31
AVP length
Vendor-ID (opt)
Data
.
.
Figure 36 AVP Format
AVP Length
The AVP Length field consists of three octets. it indicates the number of octets in this AVP including
the AVP Code, AVP Length, AVP Flags, Vendor-ID field and the AVP data. If a message is received with
an invalid attribute length, the message should be rejected.
Vendor-ID
The Vendor-ID field is present if the V bit is set in the AVP Flags field. Any vendor wishing to
implement a vendor-specific Diameter AVP MUST use his own Vendor-ID along with his privately
managed AVP address space.
AVP Data Format
The Data field is length of several octets and contains information specific to the attribute. The
format and length of the data field is determined by the AVP Code and AVP Length fields. The format
of the Data field must be one of the data types or a data type derived from the base data types.
Below we have the well-known basic AVP data formats.
OctetString: the data contains arbitrary data of variable length. Unless otherwise noted, the AVP
Length field MUST be set to at least 8 (12 if the 'V' bit is enabled). AVP Values of this type that are not
a multiple of four-octets in length is followed by the necessary padding so that the next AVP (if any)
will start on a 32-bit boundary.
Integer32: 32 bit signed value, in network byte order. The AVP Length field MUST be set to 12 (16 if
the 'V' bit is enabled).
TK420
Page 46
Integer64: 64 bit signed value, in network byte order. The AVP Length field MUST be set to 16 (20 if
the 'V' bit is enabled).
Unsigned32: 32 bit unsigned value, in network byte order. The AVP Length field MUST be set to 12
(16 if the 'V' bit is enabled).
Unsigned64: 64 bit unsigned value, in network byte order. The AVP Length field MUST be set to 16
(20 if the 'V' bit is enabled).
Float32: This represents floating point values of single precision as described by [FLOATPOINT]. The
32-bit value is transmitted in network byte order. The AVP Length field MUST be set to 12 (16 if the
'V' bit is enabled).
Float64: This represents floating point values of double precision as described by [FLOATPOINT]. The
64-bit value is transmitted in network byte order. The AVP Length field MUST be set to 16 (20 if the
'V' bit is enabled).
Grouped: The Data field is specified as a sequence of AVPs. Each of these AVPs follows in the order in
which they are specified - including their headers and padding. The AVP Length field is set to 8 (12 if
the 'V' bit is enabled) plus the total length of all included AVPs, including their headers and padding.
Thus the AVP length field of an AVP of type Grouped is always a multiple of 4.
In addition to using the Basic AVP Data Formats, applications may define data formats derived from
the Basic AVP Data Formats. An application that defines new AVP Derived Data Formats MUST
include them in a section entitled "AVP Derived Data Formats", using the same format as the
definitions below. Each new definition must be either defined or listed with a reference to the RFC
that defines the format.
The below AVP Derived Data Formats are commonly used by applications.
UTF8String: The UTF8String format is derived from the OctetString AVP Base Format. This is a human
readable string represented using the ISO/IEC IS 0646-character set, encoded as an OctetString using
the UTF-8 [UFT8] transformation format described in RFC 2279.
Time: The Time format is derived from the OctetString AVP Base Format. The string MUST contain four
octets, in the same format as the first four bytes are in the NTP timestamp format. The NTP
Timestamp format is defined in chapter 3 of [SNTP].
TK420
Page 47
Address: The Address format is der derived from the OctetString AVP Base Format. It is a
discriminated union, representing, for example a 32-bit (IPv4) [IPV4] or 128-bit (IPv6) [IPV6] address,
most significant octet first. The first two octets of the Address AVP represents the AddressType, which
contains an Address Family defined in [IANAADFAM]. The AddressType is used to discriminate the
content and format of the remaining octets.
DiameterIdentity: The DiameterIdentity format is derived from the OctetString AVP Base Format.
DiameterIdentity = FQDN
DiameterIdentity value is used to uniquely identify a Diameter node for purposes of duplicate
connection and routing loop detection. The contents of the string MUST be the FQDN of the Diameter
node. If multiple Diameter nodes run on the same host, each Diameter node MUST be assigned a
unique DiameterIdentity. If a Diameter node can be identified by several FQDNs, a single FQDN should
be picked at startup, and used as the only DiameterIdentity for that node, whatever the connection it
is sent on.
IPFilterRule: the address format is derived from OctetString AVP Base Format. It represents, for
example a 32-bit (IPv4) or 128-bit (IPv6) address, most significant octet first. The first two octets of the
Address AVP represent the AddressType, which contains an Address Family. The Address type is used
to discriminate the content and format of remaining octets.
Enumerated: Enumerated is derived from the Integer32. For AVPs of type Enumerated an application
may require a new value to communicate some service-specific information. In order to allocate a new
AVP value, request must be sent to IANA, along with an explanation of the new AVP value.
TK420
Page 48
Some AVP Data Formats

Basic AVP Data Formats:
OctetString
Unsigned32
Integer32
Grouped

Derived AVP Data Formats:

UTF8String
DiameterIdentity
Enumerated
IPFilterRule

Figure 37 AVP Data Format
4.4.3
Diameter Base Protocol Messages
The Diameter messages are either requests or answers. A request and its corresponding answer are
identied by a common Command-Code in the Diameter header, and according to the flag field (R
bit) the requestor the answer is identified.
The Command-Code is a number that indicates the action the Diameter server needs to take. As a
request and its corresponding answer share the same Command-Code address space, we need to
refer to the Command-Flags to nd out if the command is a request or an answer. The Diameter base
protocol (RFC 3588) species an initial number of command codes. An application is able to extend
these basic commands and add new application-specic ones. Table 1 shows the initial set of
requests and answers dened in the Diameter base protocol.
TK420
Page 49
Table 1: Diameter commands
Command-Name
Abbreviation
Command-Code
Abort-Session-Request
ASR
274
Abort-Session-Answer
ASA
274
Accounting-Request
ACR
271
Accounting-Answer
ACA
271
Capabilities-Exchange-Request
CER
275
Capabilities-Exchange-Answer
CEA
275
Device-Watchdog-Request
DWR
280
Device-Watchdog-Answer
DWA
280
Disconnect-Peer-Request
DPR
282
Disconnect-Peer-Answer
DPA
282
Re-Auth-Request
RAR
258
Re-Auth-Answer
RAA
258
Session-Termination-Request
STR
275
Session-Termination-Answer
STA
275
Figure 38 Base Diameter Commands
Command flag
Meaning
REQ
Request flag:
If set, the message is a request, else the
message is answer
ERR
Error flag:
If set in an answer message, the originating
Request contained a protocol error.
Note:
Codes 0-255 are reserved for RADIUS backwards compatibility
Figure 39 Command Flags
TK420
Page 50
4.4.4 Diameter Request Routing
A Diameter request originating from a client can be routed by other diameter agents (like the
proxy/relay agent) to its final destination (i.e. the Diameter server). The following slide on the next
page illustrates the situation.
Routing principals
Routing is based on 2 tables: the Realm-Based Routing Table and the Peer Table.
The Realm-Based Routing Table tells the Diameter agent, which is the next hop for the request. The
primary key is the Destination-Realm, the secondary key is the Diameter Application-ID.
The Peer Table lists all the peers, that the diameter is directly connected to the current connection
status.
A Relay Agent first looks into the Realm-Based Routing table for the realm and the Application-ID,
picks the assigned server, validates it in the Peer Table and routes the request to that server.
The routing of the answer is performed using the Hop-by-Hop identifiers. Using these identifiers the
answer is routed back to the client passing the same Diameter Nodes as the request.
TIP
For the sake of simplicity the principles above describe the basic Diameter routing only. Actually the
routing decision can be much more complicated.
Each Diameter Node supervises the connections to its direct peers using the Diameter watchdog
request/answer (DWR/DWA).
Directly connected Diameter peers send Capability Exchange request/answer to each other (CER/CEA).
This way they each know the set of supported Diameter features (e.g. the list of applications they can
handle), and the Diameter identity of connected peer (i.e. the server FQDN name).
The Realm-Based Routing Table as well as the Peer Table can be setup manually or can be discovered
dynamically using DNS records.
As to the standard, a diameter node should have at least 2 directly connected peers per realm
(primary, secondary).
TK420
The relationship between the client and the server is called a session.
Page 51
Basic Diameter Routing

Realm-Based Routing Table
Realm
Appl-ID
Local Action
RealmB.com
Relay
Server
Server.RealmB.com
Peer Table
RealmA.com
Client
Host Identity
Status
Server.RealmB.com
connected
RealmB.com
Relay/
Proxy
1. Request
4. Answer
Peer connection A
2. Request
3. Answer
Server
Peer connection B
User session
Figure 40 Basic Diameter Routing
Client
Relay/Proxy Agent
1. Request: Destination-Realm =
RealmB.com, Destination-Host =
<empty>, Hop-by-Hop ID1, Endto-End ID
Server
2. Request: Destination-Realm =
RealmB.com, Destination-Host =
Server.RealmB.com, Hop-by-Hop
ID2, End-to-End ID
3. Answer: Hop-by-Hop ID2, Endto-End ID
4. Answer: Hop-by-Hop ID1, Endto-End ID
Figure 41 Basic Diameter Routing Call Flow
TK420
Page 52
4.4.5 Transport timers at Diameter protocol level
The Transport timers at Diameter protocol level are:
TK420
Connectivity timer
Procedure safety timer
Watchdog timer
Connection retry timer
Page 53
Diamater
Node A
Diamater
Node B
Connectivity timer
TCP or SCTP connection
CER
CEA
Watchdog timer
Watchdog timer
DWR
DWA
DWR
Connection retry timer
Connection to peer lost
Connectivity timer
TCP or SCTP connection
Figure 42 Transport timers at Diameter protocol level
4.4.6 Error Handling
Two different types of errors in Diameter protocol are possible:
Protocol errors: occur at the base protocol level (e.g. DIAMETER_UNABLE_TO_DELIVER)
Application errors: occur due to a problem with a function specified in a Diameter application (e.g.
DIAMETER_MISSING_AVP)
Result Codes
The Result-Code AVP (AVP Code 268) is of type Unsigned32 and indicates whether a particular
request was completed successfully or whether an error occurred. All Diameter answer messages
must include one Result-Code AVP. A non-successful Result-Code AVP contains a non 2xxx value.
Result-Code AVP values that are used to report protocol errors must only be present in answer
messages whose E bit is set. Result-Code AVP is set to the appropriate protocol error value.
Diameter provides the following classes of errors, all identified by the thousands digit in the decimal
notation:
TK420
Page 54
1xxx: Informational
2xxx: Success
3xxx: Protocol Errors
4xxx: transient Failures
5xxx: Permanent Failure
SUCCESS
DIAMETER_SUCCESS
2001
DIAMETER_LIMITED_SUCCESS
2002
Figure 43 Success codes
TK420
Page 55
Protocol Errors
DIAMETER_COMMAND_UNSUPPORTED
3001
DIAMETER_UNABLE_TO_DELIVER
3002
DIAMETER_REALM_NOT_SERVED
3003
DIAMETER_TOO_BUSY
3004
DIAMETER_LOOP_DETECTED
3005
DIAMETER_REDIRECT_INDICATION
3006
DIAMETER_APPLICATION_UNSUPPORTED
3007
DIAMETER_INVALID_HDR_BITS
3008
DIAMETER_INVALID_AVP_BITS
3009
DIAMETER_UNKNOWN_PEER
3010
Figure 44 Protocol errors codes
SUCCESS
DIAMETER_AUTHENTICATION_REJECTED
4001
DIAMETER_OUT_OF_SPACE
4002
DIAMETER_LOST
4003
Figure 45 Permanent Failures codes
TK420
Page 56
Permanent Failures
DIAMETER_AVP_UNSUPPORTED
5001
DIAMETER_UNKNOWN_SESSION_ID
5002
DIAMETER_AUTHORIZATION_REJECTED
5003
DIAMETER_INVALID_AVP_VALUE
5004
DIAMETER_MISSING_AVP
5005
DIAMETER_RESSOURSES_EXEEDED
5006
DIAMETER_CONTRACUDTING_AVPS
5007
DIAMETER_AVP_NOT_ALLOWED
5008
DIAMETER_AVP_OCCURES_TOO_MANY_TIMES
5009
DIAMETER_NO_COMMON_APPLICATION
5010
DIAMETER_UNSUPPORTED_VERSION
5011
DIAMETER_UNABLE_TO_COMPLY
5012
DIAMETER_INVALID_BIT_IN_HEADER
5013
DIAMETER_INVALID_AVP_LENGTH
5014
DIAMETER_INVALID_MESSAGE_LENGTH
5015
DIAMETER_INVALID_AVP_BIT_COMBO
5016
DIAMETER_NO_COMMON_SECURITY
5017
Figure 46 Permanent Failures codes
4.5 GTP-U
4.5.1 GTP-U Tunnels
GTP-U Tunnels are used to carry encapsulated T-PDUs and signalling messages between a given pair
of GTP-U Tunnel Endpoints. TEID which is present in the GTP header shall indicate which tunnel a
particular T-PDU belongs to. In this manner, packets are multiplexed and de-multiplexed by GTP-U
between a given pair of Tunnel Endpoints. The TEID value to be used in the TEID field shall be
negotiated using a control plane protocol like GTPv1-C, GTPv2-C, RANAP or S1-AP.
In what follows we refer to the outer GTPv1-U IP packet as the IP packet that carries a GTPv1-U
packet. The inner IP packet in a GTPv1-U packet (T-PDU) is either:
An IP packet sent to the UE/MS in the downlink direction over one or more tunnels from the external
network identified by the APN.
An IP packet sent from a UE/MS in the uplink direction over one or more tunnels to the external
network identified by the APN.
4.5.2 GTP-U Protocol Entity

The GTP-U protocol entity provides packet transmission and reception services to user plane entities
in the RNC, SGSN, GGSN, eNB, SGW and PDN-GW. The GTP-U protocol entity receives traffic from a
number of GTP-U tunnel endpoints and transmits traffic to a number of GTP-U tunnel endpoints.
There is a GTP-U protocol entity per IP address.
TK420
Page 57
The TEID in the GTP-U header is used to de-multiplex traffic incoming from remote tunnel endpoints
so that it is delivered to the User plane entities in a way that allows multiplexing of different users,
different packet protocols and different QoS levels. Therefore no two remote GTP-U endpoints shall
send traffic to a GTP-U protocol entity using the same TEID value except for data forwarding as part
of mobility procedures.
GTP-U
GTPv1-U, also known as GTP-U is used mainly on user plane.

The UDP Destination Port number for GTP-U request messages is
2152.
Beside carrying data, two types of GTP-U messages are defined
Path Management Message
Echo Request
Echo Response
Supported Extension Headers Notification
Tunnel Management Message
Error Indication
End Marker
Figure 47 GTP-U Description
4.5.3 Protocol stack

UDP/IP is the only path protocol defined to transfer GTP messages in the version 1 of GTP.
A GTPv1-U peer shall support the UDP as defined by IETF RFC 768 shall be used.
A GTPv1-U peer shall support IPv4 as defined by IETF RFC 791 and should support IPv6 as defined by
IETF RFC 2460.
TK420
Page 58
GTPv1-U
GTP tunnels are used between two nodes
communicating over a GTP based interface.
UDP Destination Port number for GTPv1
Initial messages shall be 2152
Used in X2, S1-U, S5, S8, S3, S12 interfaces
User Data
GTPv1-U
GTPv1
entity
UDP
IP
GTPv1
entity
X2, S1-U, S5, S8, S3,

S12
Figure 48 GTP-U Protocol
4.5.4 GTP-U header

The GTP-U header is a variable length header whose minimum length is 8 bytes. There are three flags
that are used to signal the presence of additional optional fields: the PN flag, the S flag and the E flag.
The PN flag is used to signal the presence of N-PDU Numbers. The S flag is used to signal the
presence of the GTP Sequence Number field. The E flag is used to signal the presence of the
Extension Header field, used to enable future extensions of the GTP header defined in this
document, without the need to use another version number. If and only if one or more of these
three flags are set, the fields Sequence Number, N-PDU and Extension Header shall be present. The
sender shall set all the bits of the unused fields to zero. The receiver shall not evaluate the unused
fields.
TK420
Page 59
GTP-U Header
Octets
1
2
3
4
m to
k(m+3)
n to (n+2)
(n+3)
(n+4)
Version
P
T
Spare Spare Spare
Message Type
Message Length (1st Octet)
Message Length (2nd Octet)
If T flag is set to 1, then TEID shall be placed into octets 58. Otherwise, TEID field is not present at all.
Sequence Number
N-PDU Number
Next Extension Header Type
Figure 49 GTP-U Header
Always present fields:

- Version field: This field is used to determine the version of the GTP-U protocol. The version number
shall be set to '1'.
- Protocol Type (PT): This bit is used as a protocol discriminator between GTP (when PT is '1') and
GTP' (when PT is '0'). GTP is described in this document and the GTP' protocol in 3GPP TS 32.295 [8].
Note that the interpretation of the header fields may be different in GTP' than in GTP.
- Extension Header flag (E): This flag indicates the presence of a meaningful value of the Next
Extension Header field. When it is set to '0', the Next Extension Header field either is not present or,
if present, shall not be interpreted. When it is set to '1', the Next Extension Header field is present,
and shall be interpreted, as described below in this section.
- Sequence number flag (S): This flag indicates the presence of a meaningful value of the Sequence
Number field. When it is set to '0', the Sequence Number field either is not present or, if present,
shall not be interpreted. When it is set to '1', the Sequence Number field is present, and shall be
interpreted, as described below in this section. For the Echo Request, Echo Response, Error
Indication and Supported Extension Headers Notification messages, the S flag shall be set to '1'. Since
the use of Sequence Numbers is optional for G-PDUs, the PGW, SGW and eNodeB should set the flag
to '0'. However, when a G-PDU (T-PDU+header) is being relayed by the Indirect Data Forwarding for
Inter RAT HO procedure, then if the received G-PDU has the S flag set to '1', then the relaying entity
shall set S flag to '1' and forward the G-PDU (T-PDU+header).
- N-PDU Number flag (PN): This flag indicates the presence of a meaningful value of the N-PDU
Number field. When it is set to '0', the N-PDU Number field either is not present, or, if present, shall
not be interpreted. When it is set to '1', the N-PDU Number field is present, and shall be interpreted,
as described below in this section.
- Message Type: This field indicates the type of GTP-U message.
TK420
Page 60
- Length: This field indicates the length in octets of the payload, i.e. the rest of the packet following
the mandatory part of the GTP header (that is the first 8 octets). The Sequence Number, the N-PDU
Number or any Extension headers shall be considered to be part of the payload, i.e. included in the
length count.
- Tunnel Endpoint Identifier (TEID): This field unambiguously identifies a tunnel endpoint in the
receiving GTP-U protocol entity. The receiving end side of a GTP tunnel locally assigns the TEID value
the transmitting side has to use. The TEID shall be used by the receiving entity to find the PDP
context, except for the following cases:
- The Echo Request/Response and Supported Extension Headers notification messages, where the
Tunnel Endpoint Identifier shall be set to all zeroes.
- The Error Indication message where the Tunnel Endpoint Identifier shall be set to all zeros.
Optional fields:
- Sequence Number: If Sequence Number field is used for G-PDUs (T-PDUs+headers), an increasing
sequence number for T-PDUs is transmitted via GTP-U tunnels, when transmission order must be
preserved. For Supported Extension Headers Notification and Error Indication messages, the
Sequence Number shall be ignored by the receiver, even though the S flag is set to '1'.
- N-PDU Number: This field is used at the Inter SGSN Routeing Area Update procedure and some
inter-system handover procedures (e.g. between 2G and 3G radio access networks). This field is used
to co-ordinate the data transmission for acknowledged mode of communication between the MS
and the SGSN. The exact meaning of this field depends upon the scenario. (For example, for
GSM/GPRS to GSM/GPRS, the SNDCP N-PDU number is present in this field).
- Next Extension Header Type: This field defines the type of Extension Header that follows this field
in the GTP-PDU.
4.6.
GTP-C
4.5.1 GTP Tunnel

GTP tunnels are used between two nodes communicating over a GTP based interface, to separate
traffic into different communication flows.
A GTP tunnel is identified in each node with a TEID, an IP address and a UDP port number. The
receiving end side of a GTP tunnel locally assigns the TEID value the transmitting side has to use. The
TEID values are exchanged between tunnel endpoints using GTP-C or S1-MME messages.
The criteria defining when the same or different GTP tunnels shall be used between the two nodes
differs between the control and the user plane, and also between interfaces.
For the control plane, for each end-point of a GTP-C tunnel:
- The TEID-C shall be unique per PDN-Connection on GTP based S2b, S5 and S8 interfaces. The same
tunnel shall be shared for the control messages related to all bearers associated to the PDNConnection. A TEID-C on the S2b/S5/S8 interface shall be released after all its associated EPS bearers
are deleted.
TK420
Page 61
- There shall be only one pair of TEID-Cs per UE on each of the S3, S10 and the S16 interfaces. The
same tunnel shall be shared for the control messages related to the same UE operation. A TEID-C on
the S3/S10/S16 interface shall be released after its associated UE context is removed or the UE is
detached.
4.5.2 Protocol stack

There shall be only one pair of TEID-C per UE over the S11 and the S4 interfaces. The same tunnel
shall be shared for the control messages related to the same UE operation. A TEID-C on the S11/S4
interface shall be released after all its associated EPS bearers are deleted.
The source and destination IP addresses and UDP ports used for each GTP-C message depend on the
role that the message plays in a message exchange. A message can be an Initial message, or a
Triggered message, or a Triggered Reply message to Triggered message. An Initial message is sent to
a peer GTP entity with a sequence number chosen by the sending entity. A Triggered message is sent
in response to an Initial message. Triggered Reply message may be sent in response to a Triggered
message.
Typically, a Request message is an Initial message, but a Request message may be a Triggered
messages in certain procedures where they are triggered by an Initial Command message.
The UDP Destination Port number for GTPv2 Initial messages shall be 2123. It is the registered port
number for GTP-C.
The UDP Source Port for a GTPv2 Initial message is a locally allocated port number at the sending
GTP entity.
TK420
Page 62
GTPv2-C
GTP tunnels are used between two nodes
communicating over a GTP based interface.
UDP Destination Port number for GTPv2
Initial messages shall be 2123
Used in S4, S11, S5, S8, S2b interfaces
User Data
GTPv2-C
GTPv2
entity
UDP
IP
GTPv2
entity
S4, S11, S5, S8, S2b
Figure 50 GTPv2-C
Piggybacking is an optional feature. When used, a common IP header and a common UDP header
shall be used for the triggered response message and the piggybacked initial message as depicted in
next figure. Immediately following the triggered response message is the piggybacked initial
message, following which no additional information shall be present.
TK420
Page 63
Packet Format for the Piggybacking of messages
IP Header
UDP header
Triggered response
message (P=1)
Piggybacked initial
message (P=0)
Figure 51 Packet Format for the Piggybacking of messages
4.5.3 GTP Header for Control Plane

The GTP-C uses a variable length header which shall be a multiple of 4 octets.
TK420
Page 64
General format of GTPv2 Header for Control Plane

Octets
1
2
3
4
m to
k(m+3)
n to (n+2)
(n+3)
Version
P
T
Spare Spare Spare
Message Type
If T flag is set to 1, then TEID shall be placed into octets 58. Otherwise, TEID field is not present at all.
Sequence Number
Spare
Figure 52 General format of GTPv2 Header for Control Plane

Where:
- if T = 0, TEID field is not present, k = 0, m = 0 and n = 5;
- if T = 1, TEID field is present, k = 1, m = 5 and n = 9.
Octet 1 bits shall be coded as follows:
- Bits 6-8 represent the Version field.
- Bit 5 represents the Piggybacking flag (P).
- Bit 4 represents the TEID flag (T).
- Bits 3-1 are spare, the sender shall set them to "0" and the receiving entity shall ignore them.
The legacy Extension Header mechanism is not used for the GTP version 2 control plane (GTPv2-C).
Future extensions will be implemented by adding Information Elements in the message body if new
parameters are needed.
GTP-C header for Echo and Version Not Supported messages
The GTPv2-C message header for the Echo Request, Echo Response and Version Not Supported
Indication messages shall not contain the TEID field, but shall contain the Sequence Number fields,
followed by one spare octet as depicted in next figure. The spare bits shall be set to zero by the
sender and ignored by the receiver. For the Version Not
Supported Indication message header, the Sequence Number may be set to any number and shall be
ignored by the receiver.
TK420
Page 65
The format of Echo and Version Not Supported messages Header

Octets
Version
2
3
4
5
6
7
8
P
T=0
Spare
Message Type
Sequence Number (1st Octet)
Sequence Number (2nd Octet)
Sequence Number (3rd Octet)
Spare
Spare
Spare
Figure 53 The format of Echo and Version Not Supported messages Header
EPC specific GTP-C header
Apart from the Echo Request, Echo Response and Version Not Supported Indication messages, the
GTP-C message header shall contain the TEID and Sequence Number fields followed by one spare
octet. A typical GTP-C header is depicted in next figure. The spare bits shall be set to zero by the
sender and ignored by the receiver.
The format of EPC specific GTPv2 Control Plane message Header

Octets
1
2
3
4
5
6
7
8
7
Version
T=0
Spare
Spare
Spare
Message Type
Tunnel Endpoint Identifier (1st Octet)
Tunnel Endpoint Identifier (2nd Octet)
Tunnel Endpoint Identifier (3rd Octet)
Tunnel Endpoint Identifier (4th Octet)
Sequence Number (1st Octet)
10
Sequence Number (2nd Octet)
11
Sequence Number (3rd Octet)
12
Spare
Figure 54 The format of EPC specific GTPv2 Control Plane message Header
TK420
Page 66
4.5.4 GTP-C Message Types and Message Formats

A GTP-C message is sent across a GTP control plane tunnel. In a message, the GTP-C header is
followed by zero or more information elements. The GTP-C messages are used for the control plane
path management, for the control plane tunnel management and for mobility management.
A T-PDU is an original packet, for example an IP datagram, from an UE, or from a network node in an
external packet data network.
Table 1 Message types for GTPv2
Message
Type
Message
Common GTP-C messages
0
1
2
3
4 to 24
25 to 31
Reserved
Echo Request
Echo Response
Version Not Supported Indication
Reserved for S101 interface
Reserved for Sv interface
32
33
36
37
Create Session Request

Create Session Response
Delete Session Request
Delete Session Response
34
35
38
39
40 to 63
164
165
Modify Bearer Request

Modify Bearer Response
Change Notification Request
Change Notification Response
For future use
Resume Notification
Resume Acknowledge
64
65
66
67
68
69
70
71
72
73
74 to 94
Modify Bearer Command

Modify Bearer Failure Indication
Delete Bearer Command
Delete Bearer Failure Indication
Bearer Resource Command
Bearer Resource Failure Indication
Downlink Data Notification Failure Indication
Trace Session Activation
Trace Session Deactivation
Stop Paging Indication
For future use
95
Create Bearer Request
TK420
SGSN/MME/ePDG to PGW (S4/S11, S5/S8, S2b)
SGSN/MME to PGW (S4/S11, S5/S8)
Messages without explicit response
PGW to SGSN/MME/ePDG (S5/S8, S4/S11, S2b)
Page 67
96
97
98
99
100
101
102
103 to 127
Create Bearer Response

Update Bearer Request
Update Bearer Response
Delete Bearer Request
Delete Bearer Response
PGW to MME, MME to PGW, SGW to PGW, SGW to MME,

PGW to ePDG, ePDG to PGW (S5/S8, S11, S2b)
Delete PDN Connection Set Request
Delete PDN Connection Set Response
For future use
MME to MME, SGSN to MME, MME to SGSN, SGSN to

SGSN (S3/S10/S16)
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142 to 148
152
Identification Request
Identification Response
Context Request
Context Response
Context Acknowledge
Forward Relocation Request
Forward Relocation Response
Forward Relocation Complete Notification
Forward Relocation Complete Acknowledge
Forward Access Context Notification
Forward Access Context Acknowledge
Relocation Cancel Request
Relocation Cancel Response
Configuration Transfer Tunnel
For future use
RAN Information Relay
149
150
151
153
154
155
156
157 to 159
Detach Notification
Detach Acknowledge
CS Paging Indication
Alert MME Notification
Alert MME Acknowledge
UE Activity Notification
UE Activity Acknowledge
For future use
162
163
Suspend Notification
Suspend Acknowledge
160
161
166
167
168
169
170
Create Forwarding Tunnel Request

Create Forwarding Tunnel Response
Create Indirect Data Forwarding Tunnel Request
Create Indirect Data Forwarding Tunnel Response
Delete Indirect Data Forwarding Tunnel Request
Delete Indirect Data Forwarding Tunnel Response
Release Access Bearers Request
TK420
SGSN to MME, MME to SGSN (S3)
SGSN/MME to SGW, SGSN to MME (S4/S11/S3)

SGSN to SGSN (S16), SGW to PGW (S5/S8)
SGSN/MME to SGW (S4/S11)
Page 68
171
172 to 175
Release Access Bearers Response

For future use
176
177
179
180
Downlink Data Notification

Downlink Data Notification Acknowledge
PGW Restart Notification
PGW Restart Notification Acknowledge
178
181 to 199
Reserved. Allocated in earlier version of the specification.

For future use
200
201
202 to 210
Update PDN Connection Set Request

Update PDN Connection Set Response
For future use
211
212
213 to 230
Modify Access Bearers Request

Modify Access Bearers Response
For future use
231
232
233
234
235
236
237 to 239
MBMS Session Start Request

MBMS Session Start Response
MBMS Session Update Request
MBMS Session Update Response
MBMS Session Stop Request
MBMS Session Stop Response
For future use
240 to 255
For future use
TK420
SGW to SGSN/MME (S4/S11)
SGW to SGSN (S4)
SGW to PGW, PGW to SGW (S5/S8)
MME to SGW (S11)
MBMS GW to MME/SGSN (Sm/Sn)
Others
Page 69
5 Roaming Architecture
5.1 Local Breakout Roaming
In this scenario all traffic breaks out locally from VPLMN, the Application Function (AF) located in
VPLMN gets dynamic policy information from both VPLMN and HPLMN. The VPLMN includes all EPC
entities except for HSS and H-PCRF. The MME fetches subscription information via S6a roaming
reference point from the HSS located in the HPLMN. The SAE-GW gets dynamic PCRF policies related
to AF from both V-PCRF and H-PCRF via Gx reference point. V-PCRF receives policies from H-PCRF via
S9 reference point. This scenario enables SAE-GW functionality without the need for an S8 reference
point. As in the above scenario, if AF/PRCF infrastructure is not deployed for local breakout traffic,
S6a remains the only roaming reference point for this scenario. Thus, this scenario and the scenario
with home operator's application functions become identical.
Local breakout
the used APN uses a P-GW that is located in the visited PLMN. This
allows the user to access local services.
The APN subscription in HSS needs to indicate that the allocation of a
P-GW from the visited network is allowed, meaning that the breakout
can be done.
If local breakout applies, the MME selects S5 entries from the first
DNS query result applying collocation and topological closeness
criteria.
the MME inserts a visited network OI into the DNS query to get the IP
address of a P-GW located in the visited network.
Figure 55 Local Breakout
TK420
Page 70
S9 Interface
Interfaces between the hPCRF and the vPCRF is used in roaming cases.
It is used in the VPLMN for enforcement of dynamic control polices from the hPLMN.
It is standardized in 3GPP TS 29.215: Policy and Charging Control over the S9
reference point (Release 8).
S9 Application
DIAMETER
SCTP
hPCRF
IP
vPCRF
S9
Local Breakout Roaming

HSS
H-PLMN
HPCRF
S6a
S9
V-PLMN
VPCRF
S7
MME
S5
PDN
LTE-UE
SGW
PGW
Figure 57 Local Breakout Roaming
5.2 Remote Breakout Roaming

This is the default roaming scenario. In this scenario the S8 interface is used.
TK420
Page 71
Remote Breakout Roaming

HSS
H-PLMN
PDN
PCRF
PGW
S7
S6a
V-PLMN
S8
MME
LTE-UE
SGW
Figure 58 Remote Breakout Roaming
TK420
Page 72
03_Mobility and Connection Management
Chapter 3
Mobility and
Connection
Management
TK420
Page 1
1 Mobility Areas
1.1
Cell
The cell is the smallest entity regarding mobility. When the UE is in the connected mode, the
MME will know the UEs position on cell level.
Cells are identified by the Cell Identification (CI) and by the Physical Cell Identification (PCI)
1.1.1 Cell Id
Cell Identity (CI or CellID)
Used to identify the cell uniquely within the PLMN.
28-bits long
Broadcasted on System Information Block Type 1
Cell Identify together with the PLMN Identity form the Evolved Cell Global Identity (ECGI),
used to differentiate EUTRAN cell globally
More on CI and ECGI in 36.331 RRC-specification
1.1.2 Physical Cell Identity
There are 504 Physical Cell Identities (PCIs) values in the LTE system, compared with the 512
primary scrambling codes in WCDMA.
The range of PCI is from 0 to 503.
Since there are only 504 PhyCelIDs, they must be planned
More on PCI in 36.211 Physical Layer Specification
The PhyCellID is a Physical level parameter.
- UE gets the PhyCellID from the Primary and Secondary Synchronization Signals (PSS and
SSS)
PSS: provides the PhyCellID sector: 0..2
SSS: provides the PhyCellID group: 0167
TK420
Page 1
Cell
Smallest entity regarding mobility
When the UE is connected mode, the MME will know the UEs position on cell level
Cells are identified by the Cell Identification (CI) and by the Physical Cell Identification (PCI)
Cell Identity
28-bits long
Used to identify the cell uniquely within the PLMN.
Broadcasted on System Information Block Type 1
Cell Identify together with the PLMN Identity form the Evolved Cell Global Identity (ECGI), used to
differentiate EUTRAN cell globally
Physical Cell Identity
It is used in downlink to scramble the data transmitted by the cell.
It helps the UE to distinguish information coming from different transmitters.
Similar to scrambling codes in UMTS
Range: from 0 to 503
Since there are only 504 PhyCelIDs, they must be repeated
Figure 1 Cell
1.2
Tracking Area
A Tracking Area (TA) is a defined group of cells which can be used by the MME to page idle UEs.
Within a Tracking Area, a UE is associated with a single MME and S-GW. As it moves to a new
Tracking Area, an idle UE must announce its new location to the serving MME. That process is
called a Tracking Area Update (TAU).
While an LTE-UE is in active state, its location is known by the LTE network at cell level. However, in
idle state its location is known by the LTE network at tracking area level.
An operator defines a group of neighbor eNBs as a TA. A TA can be made up of cells or eNBs.
TK420
Page 2
Tracking Area
It is the successor of location and routing areas from 2G/3G.
When a UE is attached to the network, the MME will know the UEs position on tracking area level.
In case the UE has to be paged, this will be done in the full tracking area.
Tracking areas are identified by a Tracking Area Identity (TAI).
The Tracking Area Identity is constructed from the MCC (Mobile Country Code), MNC (Mobile Network Code) and
TAC (Tracking Area Code).
The TA is broadcasted to the users in the SIB1.
Figure 2 Tracking Area Concept
The Tracking Area Identity is constructed from the MCC (Mobile Country Code), MNC (Mobile
Network Code) and TAC (Tracking Area Code).
TK420
Page 3
MME 1
MME 2
TA
1
TA
2
TA
3
TAI
MCC MNC
12
12
TAC
16
40 Bits
Figure 3 Tracking Area
There are several rules that need to be followed when implementing Tracking Areas:
A cell can belong to one and only one Tracking Area
Each eNodeB can contain cells belonging to different Tracking Areas
A Tracking Area can belong to more than one MME Pool Area
A Tracking Area can belong to more than one S-GW Service Area
A Tracking Area must be completely contained within a S-GW Service Area
A Tracking Area must be completely contained within a MME Pool Area
There is no formal limit to the number of Tracking Areas that can be associated with an
MME Pool, although an artificial limit may be used
There is no formal limit to the number of Tracking Areas that can be associated with a S-GW
Service Area, although an artificial limit may be used
A Tracking Area can be no greater than the number of cells in the Pool (MME or SGW) that it
is associated with. Generally, Tracking Areas would be implemented contiguously, with all
cells in the Tracking Area, however this is not restricted by the standards
Tracking Areas are shared across PLMN IDs, since a cell can only be associated with one
Tracking Area and a cell can be associated with multiple PLMN IDs
TK420
Page 4
An MME can assign several Tracking Areas to the UE, helping reduce the Tracking Area
update signaling
The Tracking Areas defined in the Tracking Area list allocated to the UE shall be located
within one MME Pool Area
Tracking Area Rules

There are several rules that need to be followed when implementing Tracking Areas:
A cell can belong to one and only one Tracking Area
Each eNodeB can contain cells belonging to different Tracking Areas
A Tracking Area can belong to more than one MME Pool Area
A Tracking Area can belong to more than one S-GW Service Area
A Tracking Area must be completely contained within a S-GW Service Area
A Tracking Area must be completely contained within a MME Pool Area
There is no formal limit to the number of Tracking Areas that can be associated with an MME Pool, although an artificial limit may be used
There is no formal limit to the number of Tracking Areas that can be associated with a S-GW Service Area, although an artificial limit may be
used
A Tracking Area can be no greater than the number of cells in the Pool (MME or SGW) that it is associated with. Generally, Tracking Areas
would be implemented contiguously, with all cells in the Tracking Area, however this is not restricted by the standards
Tracking Areas are shared across PLMN IDs, since a cell can only be associated with one Tracking Area and a cell can be associated with
multiple PLMN IDs
An MME can assign several Tracking Areas to the UE, helping reduce the Tracking Area update signaling
The Tracking Areas defined in the Tracking Area list allocated to the UE shall be located within one MME Pool Area
Figure 4 Tracking Area Rules
1.3
Tracking Area List
Instead of using a single Tracking Area, the MME may supply a Tracking Area List to reduce
the location update signaling from the UE. As long as the UE is located in any of the listed
Tracking Areas, a Tracking Area Update is not necessary.
Tracking Area list management comprises the functions to allocate and reallocate a Tracking
Area Identity list to the UE. All the tracking areas in a Tracking Area List to which a UE is
registered are served by the same serving MME.
The "tracking area list concept" is used with E-UTRAN. With this concept, when the UE
registers with the network, the MME allocates a set (a "list") of tracking areas to the UE. By
making the centre of this set of tracking areas close to the UE's current location, the chance
of a UE rapidly making another tracking area update can be reduced.
TK420
Page 5
NOTE: This TAI list functionality is different to the SGSN behavior in GERAN and UTRAN
systems. In GERAN/UTRAN the UE is only registered in one Routing Area at a time.
Tracking Area List

Instead of TA, the MME may supply a Tracking Area List to reduce the location update signalling from the UE.
As long as the UE is located in any of the listed Tracking Areas, a Tracking Area Update is not necessary.
Tracking Area list management comprises the functions to allocate and reallocate a Tracking Area Identity list to the
UE. All the tracking areas in a Tracking Area List to which a UE is registered are served by the same serving MME.
when the UE registers with the network, the MME allocates a list of tracking areas to the UE.
The Tracking Area List is identified by the TAL
The TAL is broadcasted to the users in the ATTACH ACCEPT message.
Figure 5 Tracking Area List Concept
The size of the tracking area can be optimized in network planning. A larger TA is beneficial
to avoid tracking area update signaling. On the other hand, a smaller tracking area is
beneficial to reduce the paging signaling load for the incoming packet calls.
UE can be assigned multiple tracking areas to avoid unnecessary tracking area updates at the
tracking area borders, e.g. when the UE is ping-ponging between cells of two different
TK420
Page 6
tracking areas. UE can also be assigned both a LTE tracking area and a UTRAN routing area to
avoid signaling when changing between the two systems.
Tracking Area Optimization
Large TA
avoid tracking area update signaling
Small TA
reduce the paging signaling load for the

incoming packet calls
Figure 6 Tracking Area Optimization
TK420
Page 7
2 LTE-UE Identifications
2.1 IMSI
The IMSI allows unambiguous identication of a particular SIM or USIM card. The IMSI is
composed of three parts:
The Mobile Country Code (MCC), consisting of three digits. The MCC uniquely identies the
country of domicile of the mobile subscriber. MCC values are administrated and allocated by
an international numbering plan.
The Mobile Network Code (MNC), consisting of two or three digits for GSM/UMTS
applications. The MNC identies the home PLMN of the mobile subscriber. The length of the
MNC depends on the value of the MCC. A mixture of two- and three-digit MNC codes within
a single MCC area is not recommended and is beyond the scope of this specication.
The Mobile Subscriber Identication Number (MSIN), identifying the mobile subscriber
within a PLMN. As a rule the rst two or three digits of the MSIN reveal the identity of the
HLR or HSS that is used for Signaling Connection Control Part (SCCP) Global Title translation
procedures when roaming subscribers register in foreign networks.
The National Mobile Subscriber Identity (NMSI) consists of the MNC and the MSIN.
2.2 LMSI, TMSI, P-TMSI, M-TMSI, and S-TMSI

All temporary subscriber identities, Local Mobile Subscriber Identity (LMSI), TMSI, and PTMSI, will not be seen in E-UTRAN signaling as long as there is no inter-RAT mobility between
the E-UTRAN and UTRAN/GERAN. Indeed, for LTE a new NAS protocol was specied that
introduces a new temporary subscriber identity for the E-UTRAN: the GUTI.
However, to fulll inter-RAT mobility requirements TMSI, P-TMSI, and LMSI will still be found
in E-UTRAN NAS messages, or at least it will be indicated if valid values of these parameters
are stored on the USIM card.
The LMSI is a four-octet/byte number. It is a pointer to a database record for a particular
IMSI in the VLR database. Although the VLR is no longer found in the EPC network
architecture, there is a database with the same function hosted by the MME. The purpose of
the LMSI was to speed up the search for particular database records. From denitions given
in 3GPP 23.003 it can be guessed that the LMSI will not be used by the MME.
The TMSI is also encoded as a four-octet/byte number. It is allocated to a particular
subscriber during initial attach. The TMSI is used to mask the true subscribers identity,
which is the IMSI, in NAS signaling procedures. In the E-UTRAN it is often used together with
the GUTI. Since the TMSI has only local signicance (i.e., within a VLR and the area controlled
TK420
Page 8
by a VLR, or within a SGSN and the area controlled by a SGSN, or within a MME and the area
controlled by a MME), the structure and coding of it can be chosen by agreement between
the operator and manufacturer in order to meet local needs.
The TMSI allocation procedure should always be executed in ciphered mode to prevent
unauthorized eavesdropping.
The P-TMSI is the complement of TMSI in the UTRAN/GERAN PS domain. It is allocated by
the SGSN and, hence, will be monitored in the EPC and E-UTRAN during inter-RAT
handover/relocation preparation and execution. The P-TMSI is encoded in the same way as
the TMSI. The difference is in dening value ranges. If the rst two leading digits have the
value 11 the parameter is identied as a P-TMSI. Thus, in the hexadecimal format, all TMSI
values starting with C, D, E, or F as the rst hex number are P-TMSIs.
The M-TMSI is a 32-digit binary number that is part of the GUTI and exclusively used in the EUTRAN.
The S-TMSI consists of the Mobility Management Entity Code (MMEC) and M-TMSI. Indeed,
it is just a shorter variant of the GUTI.
2.3 GUTI
The GUTI is assigned only by the MME during initial attach of a UE to the E-UTRAN.
The purpose of the GUTI is to provide an unambiguous identication of the UE that does not
reveal the UE or the users permanent identity in the E-UTRAN. It also allows identication of
the MME and network to which the UE attaches. The GUTI can be used by the network to
identify each UE unambiguously during signaling connections.
The GUTI has two main components: the Globally Unique Mobility Management Entity
Identier (GUMMEI) that uniquely identies the MME which allocated the GUTI; and the MTMSI that uniquely identies the UE within the MME that allocated the GUTI. The GUMMEI
is constructed from the MCC, MNC, and Mobility Management Entity Identier (MMEI).
The MMEI should be constructed from a Mobility Management Entity Group ID (MMEGI)
and a MMEC.
For paging purposes, the mobile is paged with the S-TMSI. The S-TMSI is constructed from
the MMEC and the M-TMSI. It is correct to say that the S-TMSI is a shorter format of GUTI
that can be used because, after successful registration of a UE, the serving network as well
as the serving MME group are known and stored in the core network databases.
The operator needs to ensure that the MMEC is unique within the MME pool area and, if
overlapping pool areas are in use, unique within the area of overlapping MME pools.
TK420
Page 9
MCC and MNC should have the same eld size as described for the IMSI.
The M-TMSI has a length of 32 bits, MMEGI is 16 bits in length, and MMEC 8 bits in length.
It is important to understand that on the S1 interface the IMSI is typically not seen, just like
the GUTI. Exceptions are initial attach to the network when no old GUTI is stored on the
USIM card or the true subscribers identity is checked using NAS signaling, which regularly
happens when roaming subscribers attach. Also, in the case of the paging procedure the
IMSI might be seen.
Globally Unique Temporary Identity (GUTI)

0
S-TMSI
MCC
(12 bits)
MNC
(12 bits)
MMEGI
(16 bits)
PLMN-ID
MMEC
(8 bits)
MMEI
GUMMEI
M-TMSI
(32 bits)
Random number
generated by the MME
Figure 7 GUTI
2.4 IMEI
The IMEI or IMEISV is used to identify the hardware and (with IMSISV) software version of a
mobile phone. The IMEISV that is expected to be used for all 4G and UEs consists of 16 bits.
The IMEI is composed of the following elements (each element shall consist of decimal digits
only):
- Type Allocation Code (TAC). Its length is 8 digits;
- Serial Number (SNR) is an individual serial number uniquely identifying each equipment
within the TAC. Its length is 6 digits;
- Check Digit (CD) / Spare Digit (SD): If this is the Check Digit see paragraph below; if this
digit is Spare Digit it shall be set to zero, when transmitted by the MS.
TK420
Page 10
The IMEI (14 digits) is complemented by a Check Digit (CD). The Check Digit is not part of the
digits transmitted when the IMEI is checked, as described below. The Check Digit is intended
to avoid manual transmission errors, e.g. when customers register stolen MEs at the
operator's customer care desk. The Check Digit is defined according to the Luhn formula.
The IMEISV is composed of the following elements (each element shall consist of decimal
digits only):
- Type Allocation Code (TAC). Its length is 8 digits;
- Serial Number (SNR) is an individual serial number uniquely identifying each equipment
within each TAC. Its length is 6 digits;
- Software Version Number (SVN) identifies the software version number of the mobile
equipment. Its length is 2 digits.
Regarding updates of the IMEISV: The security requirements of 3GPP TS 22.016 apply only to
the TAC and SNR, but not to the SVN part of the IMEISV.
International Mobile Equipment Identity (IMEI)

IMEI: 15 digit code (used prior to 2003)
Type Allocation Code
Serial Number
Check Digit
8 digits
6 digits
1 digit
IMEISV: 16 digit code (new format used since 2003)

Type Allocation Code
Serial Number
Software Version
8 digits
6 digits
2 digits
Figure 8 IMEI Format
2.5 RNTI
In 3G UMTS the Radio Network Temporary Identiers (RNTIs) are always used to identify
information dedicated to a particular subscriber on the radio interface, especially if common
or shared channels are used for data transmission. Now, in LTE it is the rule that common
channels and shared channels are used to transmit all UE-specic data, but also some
network-specic data across the radio interface.
TK420
Page 11
For this reason the RNTI in LTE is not always related to a particular subscriber, but
sometimes also used to distinguish broadcast network information from data streams of
subscribers.
The RNTI is signaled in the MAC layer.
When MAC uses the Physical Downlink Control Channel (PDCCH) to indicate radio resource
allocation, the RNTI that is mapped on the PDCCH depends on the logical channel type:
C-RNTI, Temporary Cell Radio Network Temporary Identier (temp C-RNTI), and SemiPersistent Scheduling (SPS) C-RNTI for Dedicated Control Channel (DCCH) and DTCH;
Paging Radio Network Temporary Identity (P-RNTI) for Paging Control Channel (PCCH);
Random Access Radio Network Temporary Identier (RA-RNTI) for Random Access
Response (RAR) on DL-SCH;
Temporary C-RNTI for Common Control Channel (CCCH) during the random access
procedure;
System Information Radio Network Temporary Identier (SI-RNTI) for Broadcast Control
Channel (BCCH).
All RNTIs are encoded using the same 16-bit format (two octets = 2 bytes).
The C-RNTI is a 16-bit numeric value. Its format and encoding are specied in 3GPP 36.321
(MAC). The C-RNTI is part of the MAC Logical Channel Group ID eld (LCG ID). It denes
unambiguously which data sent in a DL direction within a particular LTE cell belongs to a
particular subscriber.
For instance, all RRC messages belonging to a single connection between a UE and the
network are marked with the same C-RNTI value by the MAC entity that provided transport
services to the RRC and NAS. Thus, C-RNTI is an important parameter for call tracing.
The C-RNTI comes in three different avors: temp C-RNTI, semi-persistent scheduling C-RNTI,
and permanent C-RNTI.
The temp C-RNTI is allocated to the UE during random access procedure (with a RRC
connection setup message) and may turn into a permanent C-RNTI depending on the result
of a subsequently performed contention resolution procedure or in the case of contentionfree random access.
The semi-persistent scheduling C-RNTI is used if the subscriber is running services with a
predictable unchanging QoS prole. A typical example is VoIP for which the required bit rate
will not change during the entire connection. In such a case the dynamic (re)scheduling of
radio resources, which is mandatory in the case of bursty payload trafc to ensure optimal
TK420
Page 12
usage of resource blocks, is not required. The SPS C-RNTI is used to indicate an area of
resource blocks that will be used by the same UE for a longer time frame without any
expected change.
TK420
Page 13
3 UE states
3.1
RRC states
According to the LTE Standard, the UE can be considered in the eNb as RRC_Connected or
RRC_Idle.
RRC Idle: The UE is considered RRC_IDLE once it obtains the center frequency, reads the
timing information, syncs to the eNodeB, and is ready to receive system broadcast
information. At this point the UE has no signaling connection to the eNodeB. From the
RRC_IDLE state the UE must perform:
System information acquisition

Receive and respond to paging
Tracking Area Update
neighbouring cell measurements

Cell re-selection as needed
Monitoring Paging channel to detect incoming calls, system information change, for
ETWS capable UEs, ETWS notification, and for CMAS capable UEs, CMAS notification
RRC_CONNECT
In order to register with the EPC, the UE must set-up RRC signaling with the eNodeB. This is
the RRC_CONNECT state. From the RRC_CONNECT state the UE must perform:
System information acquisition

Monitor DL control channels
Send Channel Quality and feedback information
Handover
Monitors a Paging channel and SIB1 contents to detect system information change, for ETWS
capable UEs, ETWS notification, and for CMAS capable UEs, CMAS notification;
Performs neighbouring cell measurements and measurement reporting;
After the RRC connection is set up the UE is known to the eNB, and the UE is in
RRC_CONNECT state.
RRC_CONNECTED:
TK420
UE has an E-UTRAN-RRC connection;

UE has context in E-UTRAN (C-RNTI);
E-UTRAN knows the cell which the UE belongs to;
Network can transmit and/or receive data to/from UE;
Page 14
Network controlled mobility (handover and inter-RAT cell change order to GERAN with
NACC);
Neighbor cell measurements;
Radio Resource Control (RRC)

RRC Connection Establishment
RRC_CONNECT
RRC_ IDLE
RRC Connection Release
RRC-IDLE
No signalling connection between the UE and
the E-UTRAN.
UE Receives system information and listens for
Paging.
Mobility based on PLMN selection.
No RRC context stored inRACH procedure used
on RRC connection establishment.
the eNB
RRC-CONNECTED
UE has an E-UTRAN RRC connection.
UE has context in E-UTRAN.
E-UTRAN knows the cell which the UE belongs to.
Network can transmit and/or receive data to/from UE.
Mobility based on handovers
UE reports neighbour cell measurements.
Figure 9 RRC States
3.2 EMM states

On the NAS layer there are two EPS Mobility Management (EMM) states dened to describe
the results of mobility management procedures like Attach and Tracking Area Update. The
EMM states are:
EMM-DEREGISTERED.
EMM-REGISTERED.
The UE in the EMM-DEREGISTERED state is not attached to the network. From the MMEs
point of view, there is no active context for a UE, no routing information, and no location
information. So the UE is not reachable by the MME.
In the EMM-DEREGISTERED state, some UE context can still be stored in the UE and MME,
e.g. to avoid running an AKA procedure during every Attach procedure.
After a successful attach the UE enters the EMM-REGISTERED state. Now the MME knows
where to page the UE and the HSS is able to provide routing information for mobile
terminating connections of this particular subscriber. In the EMM-REGISTERED state the UE
always has an active PDN connection and EPS security context.
In the EMM-REGISTERED state, the UE shall:
TK420
Page 15
perform a tracking area update if the new TA is not in the list of TAs that the UE has received
from the network in order to maintain the registration and enable the MME to page the UE;
perform the periodic tracking area updating procedure to notify the EPC that the UE is
available;
answer to paging from the MME by performing a service request procedure;
perform the service request procedure in order to establish the radio bearers when uplink
user data is to be sent.
After performing the Detach procedure, the state is changed to EMM-DEREGISTERED in the
UE and in the MME. Upon receiving the TAU Reject and Attach Reject messages the actions
of the UE and MME depend upon the 'cause value' in the reject message, but, in many cases
the state is changed to EMM-DEREGISTERED in the UE and in the MME.
The MME may perform an implicit detach any time after the UE reachable timer expires.
EPS Mobility Management (EMM)

Attach Accept, TAU Accept
EMM_
REGISTERED
EMM_
DEREGISTERED
Detach, Attach Reject, TAU Reject
EMM-DEREGISTERED
Location of UE is unknown for the MME.
MME may keep some UE context when the UE
moves to this state.
Successful TAU procedures lead to transition to
EMM-REGISTERED.
EMM-REGISTERED
MME holds location information for the UE at least to the
accuracy of a tracking area.
In this state the UE performs TAU procedures, responds to
paging messages and performs the service request
procedure if there is uplink data to be sent.
Figure 10 EMM states
3.3 ECM states

The ECM states indicate if there is an active signaling connectivity between the UE and the
EPC. The ECM states are:
ECM-IDLE.
ECM-CONNECTED.
TK420
Page 16
The location of a UE in the ECM-IDLE state is known by the network on behalf of the current
Tracking Area List. All tracking areas in a Tracking Area List to which a UE is registered must
be connected to the same MME.
A UE is in the ECM-IDLE state when no active NAS signaling connection between the UE and
network exists. In other words, there are no SRBs assigned to this mobile. In this state the
mobility is managed by cell reselection mechanism.
The UE and MME should enter the ECM-CONNECTED state whenever the UE sends or MME
receives one of the following NAS messages: Attach Request, Tracking Area Update Request,
Service Request, or Detach Request.
When the UE is in the ECM-IDLE state it is possible that the UE and the network have
different sets of established EPS bearers stored in their system memory. When the UE and
MME enter the ECM-CONNECTED state, the set of EPS bearers is synchronized between the
UE and network. ECM state and EMM state do not strictly depend on each other. For
instance, a UE can be in ECM-IDLE, but EMM-REGISTERED. However, a UE can also be in
ECM-CONNECTED while in EMM-DEREGISTERED, yet this happens during the radio
connection for initial registration. Firstly, the UE must enter ECM-CONNECTED to send
Attach Request, and only if Attach Accept is sent back by the network does this UE enter
EMM-REGISTERED.
For a UE in the ECM-CONNECTED state, there exists a signaling connection between the UE
and the MME. The signaling connection is made up of two parts: an RRC connection and an
S1_MME connection.
The S1 release procedure changes the state at both UE and MME from ECM-CONNECTED to
ECM-IDLE.
NOTE: The UE may not receive the indication for the S1 release, e.g. due to radio link error
or out of coverage. In this case, there can be temporal mismatch between the ECM-state in
the UE and the ECM-state in the MME.
After a signaling procedure (e.g. tracking area update), the MME may decide to release the
signaling connection to the UE, after which the state at both the UE and the MME is changed
to ECM-IDLE.
TK420
Page 17
EPS Connection Management (ECM)

S1 Connection Establishment
ECM_CONNECTED
ECM_IDLE
S1 Connection Release
ECM-IDLE
no NAS signaling and there is no context for the UE
held in the E-UTRAN.
The location of the UE is known in the tracking
area level
Mobility is managed by tracking area updates.
ECM-CONNECTED
NAS signaling connection which is provided in the form of
a RRC connection and an S1 connection.
The location of the UE is known in cell level.
Mobility is managed by handovers.
Figure 11 ECM states
3.4 ESM States
TK420
Page 18
The LTE standards also describe the EPS Session Management states: ESM_INACTIVE and
ESM_ACTIVE.
ESM_INACTIVE
In this state, the UE has no default or dedicated bearers associated with it.
ESM_ACTIVE
In this state, the UE has at least one bearer associated with it. Since the UE must be
registered before establishing a bearer, a UE in ESM_ACTIVE state will also be in
EMM_REGISTERED state. Data transfer may occur if the UE is in ECM_CONNECT state.
The PDN context includes information distributed across many EPS network elements.
EPS Session Management (ESM)

First EPS Bearer Established
ESM_INACTIVE
ESM_ACTIVE
Last EPS Bearer Released
Figure 12 ESM States
3.5 EMM & ECM States Transitions
TK420
Page 19
EMM & ECM States Transitions

Registration
ECM-REGISTERED
ECM_CONNECTED
Deregistration/PLMN change
ECM-DEREGISTERED
ECM_IDLE
New
traffic
or TAU
Inactivity
Power ON
ECM-REGISTERED
ECM_IDLE
Timeout of PTAU
Figure 13 EMM & ECM States Transitions
3.6 NAS States
NAS States
Registration
Service Request
TA update, paging
Power On
EMM-Deregistered,
ECM-Idle
ESM-Inactive
EMM-Registered,
ECM-Idle
ESM-Active
EMM-Registered,
ECM-Connected
ESM-Active
RRC: Null
RRC: IDLE
RRC: CONNECTED
No RRC or EPC Context
EPC Context
RRC & EPC Context
IMSI Identifier
S-TMSI, TA-ID, IP Address
S-TMSI, TA-ID, IP Address
UE Unknown
UE Known at TA Level
UE Known at Cell Level
PLMN Selection
TA Update
Handovers
No Data Transfer
PTAU Timeout
out of area
DRX on DL
Inactivity
UL/DL Data Transfer
Deregistration
Figure 14 NAS States
4 EPS Bearer
TK420
Page 20
4.1 The EPS bearer in general

For E-UTRAN access to the EPC the PDN connectivity service is provided by an EPS bearer in
case of GTP-based S5/S8, and by an EPS bearer concatenated with IP connectivity between
Serving GW and PDN GW in case of PMIP-based S5/S8.
An EPS bearer is a logical aggregate of one or more Service Data Flows (SDFs), running
between a UE and a PDN GW in case of GTP-based S5/S8, and between UE and Serving GW
in case of PMIP-based S5/S8. An EPS bearer is the level of granularity for bearer level QoS
control in the EPC/E-UTRAN.
Each EPS bearer is uniquely identified by EPS bearer identity (EBI), which is allocated by the
MME. the EBI is used for the one to one mapping between EPS RB Identity and EPS Bearer
Identity is made by E-UTRAN. E-RAB ID value is the same as the EPS Bearer ID value
The EBI is coded in 4 bits: values from 0 to 4 are reserved for future use.
EPS bearer identity (EBI)

uniquely identifies an EPS bearer for one UE accessing via E-UTRAN
allocated by the MME
one to one mapping between EPS RB Identity and EPS Bearer Identity is made
by E-UTRAN
E-RAB ID value is the same as the EPS Bearer ID value
The EBI is coded in 4 bits: values from 0 to 4 are reserved for future use.
Figure 15 EPS Bearer Identity

That is, SDFs mapped to the same EPS bearer receive the same bearer level packet
forwarding treatment (e.g. scheduling policy, queue management policy, rate shaping policy,
RLC configuration, etc.). Providing different bearer level QoS to two SDFs thus requires that a
separate EPS bearer is established for each SDF.
The decision to establish or modify a dedicated bearer can only be taken by the EPC, and the
bearer level QoS parameter values are always assigned by the EPC. Therefore, the MME shall
not modify the bearer level QoS parameter values received on the S11 reference point
TK420
Page 21
during establishment or modification of a dedicated bearer. Instead, the MME shall only
transparently forwards those values to the E-UTRAN. The MME may, however, reject the
establishment or modification of a dedicated bearer (e.g. in case the bearer level QoS
parameter values sent by the PCEF over a GTP based S8 roaming interface do not comply
with a roaming agreement).
Editor's Note: It is FFS in case of GTP based roaming how an MME in the VPLMN can enforce
roaming restrictions on an 'EPS subscribed QoS profile' received from the HSS in the HPLMN
during the Attach procedure.
"QoS negotiation" between the E-UTRAN and the EPC during dedicated bearer
establishment / modification is not supported.
An UpLink Traffic Flow Template (UL TFT) is a set of uplink packet filters. A DownLink Traffic
Flow Template (DL TFT) is a set of downlink packet filters.
One EPS bearer is established when the UE connects to a PDN, and that remains established
throughout the lifetime of the PDN connection to provide the UE with always-on IP
connectivity to that PDN. That bearer is referred to as the default bearer. Any additional EPS
bearer that is established to the same PDN is referred to as a dedicated bearer.
Every EPS bearer is associated with an UL TFT in the UE and a DL TFT in the PCEF.
The initial bearer level QoS parameter values of the default bearer are assigned by the
network, based on subscription data (in case of E-UTRAN the MME sets those initial values
based on subscription data retrieved from HSS). The PCEF may change those values based in
interaction with the PCRF or based on local configuration.
The distinction between default and dedicated bearers should be transparent to the access
network (e.g. E-UTRAN).
An EPS bearer is referred to as a GBR bearer if dedicated network resources related to a GBR
value that is associated with the EPS bearer are permanently allocated (e.g. by an admission
control function in the eNB) at bearer establishment/modification. Otherwise, an EPS bearer
is referred to as a Non-GBR bearer.
A dedicated bearer can either be a GBR or a Non-GBR bearer. A default bearer shall be a
Non-GBR bearer.
TK420
Page 22
EPS Bearer and SDF

PDN Connection
The IP Connection between a UE and a PDN
UE: represented by UE IP address
PDN: represented by APN
EPS Session
The same meaning as PDN Connection
Incorporates one or more EPS Bearers, and exists as long as UE IP address is
established
EPS Bearer
A Logical transport channel(transmission path) between the UE and the P-GW for
transporting IP traffic with a specific QoS
Each EPS Bearer is associated with a set of QoS parameters that describe the
properties of the transport channel
All EPS Bearers belonging to one PDN connection share the same UE IP address
An EPS bearer identity uniquely identifies an EPS bearer for one UE. The EPS Bearer
Identity is allocated by the MME.
EPS Bearer and SDF

Default Bearer
The EPS Bearer Which is first established for a new PDN connection and remains
established throughout the lifetime of the PDN connection
Always Non-GBR Bearer
Dedicated Bearer
Additional EPS Bearer that may be activated for a PDN connection
May be activated on demand
Either GBR Bearer of Non-GBR Bearer
SDF(Service Data Flow)

A IP flow(packet flow) or an aggregate set of IP flows corresponding to a service, which is
identifiable using IP/TCP/UDP headers of the packets
One SDF can be given one QoS treatments in P-GW (PCC rule by PCRF)
Multiple SDFs can be multiplexed onto the same EPS Bearer by including multiple
uplink/downlink packet filters in the UL/DL TFT
TK420
Page 23
EPS Bearers
Figure 16 EPS Bearers
TK420
Page 24
4.2 EPS Bearer sections

The EPS bearers is composed from 3 parts:
S5/S8 Bearer
Between the P-GW to S-GW.
This is usually a GTP or MIP (Mobile IP) tunnel between the two network elements.
S1 Bearer
Between eNB and S-GW.
The S1 Bearer is implemented using the 2G/3G GTP (GPRS Tunneling Protocol)
protocol which builds a GTP tunnel between eNB and S-GW.
The setup of this S1Bearer is managed by the MME. S-GW and eNB do not directly
exchange signaling to create it.
Radio Bearer
Between UE and eNB.
The eNB connects a radio bearer internally with the associated S1 Bearer on S1-U
interface.
The mapping of radio bearers to physical resources on the air interface is the major
task of the eNB scheduler.
TK420
Page 25
EPS Bearer sections

SAE-GW
MME
LTE-Uu
S5/S8
S1-U
SGi
PDN
End-to-End Service
External Bearer
EPS Bearer
Radio Bearer
E-UTRAN
S1 Bearer
S5/S8 Bearer
EPC
PDN
Figure 17 EPS Bearer Sections
4.3 Default Bearer Concept

Unlike 2G and 3G technologies, in the LTE network the subscriber get a kind of tunnel to the
PDN network during the attach procedure, this tunnel is kept as long as the subscriber is
EMM_ REGISTRED to give the subscriber the always-on connectivity. This tunnel is called the
default bearer.
Each UE that is attached to the LTE network has at least one bearer available, that is
called the default bearer.
Its goal is to provide continuous IP connectivity towards the EPC (always-on

concept)
From the QoS point of view, the default bearer is normally a quite basic bearer
If an specific service requires more stringent QoS attributes, then a dedicated bearer
should be established.
TK420
Page 26
Default Bearer Concept

A default bearer is created for each access point.
Each UE that is attached to the LTE network has at least one bearer available, that is called the default
bearer.
Its goal is to provide continuous IP connectivity towards the EPC
From the QoS point of view, the default bearer is normally a quite basic bearer
If an specific service requires more stringent QoS attributes, then a dedicated bearer should be
established.
A UE can get 3 default bearer in the same time.
This concept is not used in 2G/3G networks.
Figure 18 Default Bearer Concept
4.4 Dedicated Bearer

The dedicated bearers provides dedicated tunnel to one or more specific traffic (i.e. VoIP,
video). Dedicated bearer acts as an additional bearer on top of default bearer. It does not
require separate IP address due to the fact that only additional default bearer needs an IP
address and therefore dedicated bearer is always linked to one of the default bearer
established previously. Dedicated bearer can be GBR or non-GBR (whereas default bearer
can only be non-GBR). For services like VoLTE we need to provide better user experience and
this is where dedicated bearer would come handy. Dedicated bearer uses Traffic flow
templates (TFT) to give special treatment to specific services.
The value of "Linked EPS bearer identity" defined in setup info of dedicated bearer is used to
link dedicated bearer to default bearer.
5 QoS in LTE/EPS
The bearer level (i.e. per bearer or per bearer aggregate) QoS parameters are QCI, ARP, GBR,
MBR, and AMBR described in this section.
TK420
Page 27
Each EPS bearer (GBR and Non-GBR) is associated with the following bearer level QoS
parameters:
- QoS Class Identifier (QCI);
- Allocation and Retention Priority (ARP).
8.1 Quality of Service Class Identifier

A QCI is a scalar that is used as a reference to access node-specific parameters that control
bearer level packet forwarding treatment (e.g. scheduling weights, admission thresholds,
TK420
Page 28
queue management thresholds, link layer protocol configuration, etc.), and that have been
pre-configured by the operator owning the access node (e.g. eNB).
The QCI is simply an integer number assigned to the bearer. This number indicates the QoS
category the bearer belongs to by identifying a set of locally configured values for 3 QoS
attributes: Priority, Delay and Loss Rate.
TK420
Priority: used to define the priority for the Packet Scheduler function in the eNB.
Delay Budget: helps the packet scheduler to ensure that users are scheduled
sufficiently often to guarantee the delay requirements of the Bearer.
Loss Rate tolerance is primarily intended for setting the RLC protocol settings (e.g.
number of RLC retransmissions). The label will most likely also include a priority
parameter, which the packet scheduler can use for differentiation.
Page 29
QCI Concept
3G
LTE/EPS
Figure 19 QCI Concept
QoS Class Identifier (QCI)

QCI
Guarantee
Priority
Delay budget
Loss rate
GBR
100 ms
1e-2
VoIP
GBR
150 ms
1e-3
Video call
GBR
300 ms
1e-6
Streaming
GBR
50 ms
1e-3
Real time gaming
Non-GBR
100 ms
1e-6
IMS signalling
Non-GBR
100 ms
1e-3
Interactive gaming
Non-GBR
300 ms
1e-6
Non-GBR
300 ms
1e-6
Non-GBR
300 ms
1e-6
Application
TCP protocols : browsing, email,

file download
Figure 20 QCI Table according to 3GPP
It is up to the operator to define these labels, although some standard labels might be
provided by 3GPP. This label can be translated into a DiffServ-tag used on S1-U and S5/S8 in
the IP header to implement IP differentiated service routing in the associated IP protocol
stacks.
TK420
Page 30
Relation between QCI and DSCP

LTE-Uu
EPC
eNB
LTE-UE
QCI
PDN
DSCP
A mapping table between
QCI and DSCP value must
be defined in the eNB.
Figure 21 Relation between QCI and DSCP
Differentiated Services field

Version
IHL
DS (former TOS)
Identification
TTL
Total Length
Flags
Fragment Offset
Protocol (IP)
Header Checksum
Source Address
Destination Address
Options and Padding (optional)
Differentiated Services field
bit 1
bit 2
bit 3
Per Hop Behaviour

(1...4)
bit 4
bit 5
Drop Precedence
(1=low, 2=medium,
3=high)
bit 6
0
bit 7
bit 8
CU
Currently Unused
Figure 22 Differentiated Services field
TK420
Page 31
Mapping between DSCP and Assured forwarding

classes
Figure 23 Mapping between DSCP and Assured forwarding classes
8.2 Allocation, Retention, and Priority

The primary purpose of ARP is to decide whether a bearer establishment / modification
request can be accepted or needs to be rejected in case of resource limitations (typically
available radio capacity in case of GBR bearers). In addition, the ARP can be used (e.g. by the
eNB) to decide which bearer(s) to drop during exceptional resource limitations (e.g. at
handover). Once successfully established, a bearer's ARP shall not have any impact on the
bearer level packet forwarding treatment (e.g. scheduling and rate control). Such packet
forwarding treatment should be solely determined by the other bearer level QoS
parameters: QCI, GBR, MBR, and AMBR.
The ARP should be understood as "Priority of Allocation and Retention"; not as "Allocation,
Retention, and Priority".
The range of the ARP priority level is 1 to 15 with 1 as the highest level of priority. The preemption capability information defines whether a service data flow can get resources that
were already assigned to another service data flow with a lower priority level. The preemption vulnerability information defines whether a service data flow can lose the resources
assigned to it in order to admit a service data flow with higher priority level. The preemption capability and the pre-emption vulnerability can be either set to 'yes' or 'no'.
TK420
Page 32
The ARP priority levels 1-8 should only be assigned to resources for services that are
authorized to receive prioritized treatment within an operator domain (i.e. that are
authorized by the serving network). The ARP priority levels 9-15 may be assigned to
resources that are authorized by the home network and thus applicable when a UE is
roaming.
ARP is stored in HSS typically on a per APN basis, it contains three fields
Priority level: 115, 1 is the highest priority
Pre-emption capability: determines whether a bearer with a lower ARP priority level
should be dropped to free up the required resources.
Pre-emption vulnerability: determines whether a bearer is applicable for dropping by a
pre-emption capable bearer with a higher ARP priority value.
The values in ARP IE is used by Radio Resource Management module of an eNB for
admission control and congestion control. How RRM works is implementation specific means
it will differ from vendor to vendor and customized to their product offering.
Allocation Retention Priority

The primary purpose of ARP is to decide whether a bearer establishment / modification
request can be accepted or needs to be rejected in case of resource limitations. In addition,
the ARP can be used to decide which bearer(s) to drop during exceptional resource
limitations.
The ARP should be understood as "Priority of Allocation and Retention.
ARP is stored in HSS typically on a per APN basis, it contains three fields:
Priority level: 115
Pre-emption capability: determines whether a bearer with a lower ARP priority level
should be dropped to free up the required resources.
Pre-emption vulnerability: determines whether a bearer is applicable for dropping by a
pre-emption capable bearer with a higher ARP priority value.
5.3 GBR and MBR

Each GBR bearer is additionally associated with the following bearer level QoS parameters:
- Guaranteed Bit Rate (GBR);
- Maximum Bit Rate (MBR).
TK420
Page 33
The GBR denotes the bit rate that can be expected to be provided by a GBR bearer. The MBR
limits the bit rate that can be expected to be provided by a GBR bearer (e.g. excess traffic
may get discarded by a rate shaping function). The MBR may be greater than or equal to GBR
for a particular GBR bearer.
5.4 Aggregate Maximum Bit Rate

Each PDN connection (i.e. IP address) is associated with the following IP-CAN session level
QoS parameter: Aggregate Maximum Bit Rate (AMBR).
Multiple EPS bearers of the same PDN connection can share the same AMBR. That is, each of
those EPS bearers could potentially utilize the entire AMBR, e.g. when the other EPS bearers
do not carry any traffic. The AMBR limits the aggregate bit rate that can be expected to be
provided by the EPS bearers sharing the AMBR (e.g. excess traffic may get discarded by a
rate shaping function). AMBR applies to all Non-GBR bearers belonging to the same PDN
connection.
GBR bearers are outside the scope of AMBR.
The GBR and MBR denote bit rates of traffic per bearer while AMBR denotes a bit rate of
traffic per group of bearers.
Each of those three bearer level QoS parameters has an uplink and a downlink component.
On S1_MME the values of the GBR, MBR, and AMBR refer to the bit stream excluding the
GTP-u header overhead on S1_U.
One 'EPS subscribed QoS profile' is defined for each APN permitted for the subscriber. It
contains the bearer level QoS parameter values for that APN's default bearer (QCI and ARP)
and that APN's AMBR.
5.5 Traffic Flow Control (UL/DL-TFT)

The purpose of the traffic flow template information element is to specify the TFT
parameters and operations for a bearer. In addition, this information element may be used
to transfer extra parameters to the network (e.g. the Authorization Token). The TFT may
contain packet filters for downlink, uplink or both directions. The packet filters determine
the traffic mapping to different bearers. The downlink packet filters shall be applied by the
network and the uplink packet filters shall be applied by the UE. A packet filter that applies
for both directions shall be applied by the network as a downlink packet filter and by the UE
as an uplink filter.
TK420
Page 34
The traffic flow template is a type 4 information element with a minimum length of 3 octets.
The maximum length for the IE is 257 octets.
When sending this IE in the BEARER RESOURCE ALLOCATION REQUEST message, the UE shall
set the packet filter identifier values to 0.
When sending this IE in the BEARER RESOURCE MODIFICATION REQUEST message, the UE
shall set the packet filter identifier values from those of already assigned packet filter
identifiers of the existing EPS bearer, so that they are unique across all packet filters for the
EPS bearer context indicated by the EPS bearer identity IE.
Traffic Flow Template

Because a single UE can have multiple SAE bearers, the system requires some kind of
packet filter to decide which IP datagram has to go to which SAE bearer.
These packet filters are formed by the uplink and downlink TFT (Traffic Flow Template).
Each dedicated SAE bearer has to have one UL and one DL TFT.
Some criteria like source and destination IP address, flow labels, port numbers, transport
layer protocol type, etc. specifies, which IP datagrams will have to be sent in the
associated SAE bearer.
In the moment the concrete structure of the TFT is for further study, especially whether
additional QoS parameters might be inside or not.
Figure 24 Traffic Flow Template
6 EPS Procedures and Signaling
6.1 Attach procedure

The attach procedure is used to attach to an EPC for packet services in EPS.
The attach procedure is used for two purposes:
TK420
by a UE in PS mode of operation to attach for EPS services only.
Page 35
by a UE in CS/PS mode 1 or CS/PS mode 2 of operation to attach for both EPS and non-EPS
services.
To attach for emergency bearer services
With a successful attach procedure, a context is established for the UE in the MME, and a
default bearer is established between the UE and the PDN GW, thus enabling always-on IP
connectivity to the UE. The network may also initiate the activation of dedicated bearers as
part of the attach procedure.
During the attach procedure, the UE may also obtain the home agent IPv4 and IPv6
addresses.
The UE shall construct the TAI of the cell from the chosen PLMN identity (in case of shared
network) and the TAC received as part of the broadcast system information.
MME
EMM: Attach Request

(IMSI/old GUTI, old TAI, old ECGI)
ESM: PDN Connectivity request
(PDN address req. IPv4or IPv6)
PCRF
PGW
SGW
HSS
AIR
AIA
EMM: Authentication Request

EMM: Authentication Response
ULR
ULA
Create Default
Bearer Request
Create Default
Bearer Response
Create Default
Bearer Request
Create Default
Bearer Response
PCRF
Interaction
EMM: Attach Accept

(new GUTI, TAI List, Attach Result, PTAU timer)
ESM: Activate default EPS bearer context req
(APN, User IP@, QoS )
EMM: Attach complete

ESM Activate Default EPS bearer
context accept
Figure 25 Attach Procedure
6.2 S1 Setup procedure
TK420
Page 36
S1 Setup procedure
Used to exchange application level data needed for the eNB and
MME to interoperate correctly on the S1 interface.
MME
S1 SETUP REQUEST
(eNB Name IE)
Successful
operation
The MME store the exchanged data.

those information are used for the
duration of the TNL association
S1 SETUP RESPONSE
(MME Name IE )
S1 SETUP REQUEST
Unsuccessful
operation
S1 SETUP FAILURE
(Cause IE)
Figure 26 S1 Setup Procedure
6.3 S1 Release
S1 release
MME
SGW
EMM_Registered
ECM_Connected
S1 Release Request
(Cause)
Update Bearer Request

Update Bearer Response
S1 Release Command
(Cause)

Ack
S1 Release Complete
EMM_Registered
ECM_Idle
Figure 27 S1 Release Procedure
TK420
Page 37
6.4 Dedicated Bearer Activation

The MME shall initiate the dedicated bearer context activation procedure by sending an
ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST message.
The MME allocates the EPS bearer identity and includes it in the ACTIVATE DEDICATED EPS
BEARER CONTEXT REQUEST message. The MME shall include the EPS bearer identity of the
associated default bearer as the linked EPS bearer identity in the ACTIVATE DEDICATED EPS
BEARER CONTEXT REQUEST message. The ACTIVATE DEDICATED EPS BEARER CONTEXT
REQUEST message shall also include a procedure transaction identity (PTI), if this procedure
was initiated by a UE requested bearer resource allocation procedure or a UE requested
bearer resource modification procedure.
Dedicated EPS Bearer Context Activation

MME
NAS: Activate Dedicated EPS Bearer Context Request
NAS: Activate Dedicated EPS Bearer Context Accept
Figure 28 Dedicated EPS Bearer Context Activation
1. If dynamic PCC is deployed, the PCRF sends a PCC decision provision (QoS policy)
message to the PDN GW.
2. The PDN GW uses this QoS policy to assign the EPS Bearer QoS, i.e., it assigns the
values to the bearer level QoS parameters QCI, ARP, GBR and MBR. The PGW
generates a Charging Id for the dedicated bearer. The PDN GW sends a Create Bearer
Request message (IMSI, PTI, EPS Bearer QoS, TFT, S5/S8 TEID, Charging Id, LBI,
Protocol Configuration Options) to the Serving GW, the Linked EPS Bearer Identity
(LBI) is the EPS Bearer Identity of the default bearer.
TK420
Page 38
3. The Serving GW sends the Create Bearer Request (IMSI, PTI, EPS Bearer QoS, TFT, S1TEID, PDN GW TEID (GTP-based S5/S8), LBI, Protocol Configuration Options) message
to the MME. If the UE is in ECM-IDLE state the MME will trigger the Network
Triggered Service Request from step 3. In that case the following steps 4-7 may be
combined into Network Triggered Service Request procedure or be performed
standalone.
4. The MME selects an EPS Bearer Identity, which has not yet been assigned to the UE.
The MME then builds a Session Management Request including the PTI, TFT, EPS
Bearer QoS parameters (excluding ARP), Protocol Configuration Options, the EPS
Bearer Identity and the Linked EPS Bearer Identity (LBI). The MME then signals the
Bearer Setup Request (EPS Bearer Identity, EPS Bearer QoS, Session Management
Request, S1-TEID) message to the eNodeB.
5. The eNodeB maps the EPS Bearer QoS to the Radio Bearer QoS. It then signals a RRC
Connection Reconfiguration (Radio Bearer QoS, Session Management Request, EPS
RB Identity) message to the UE. The UE NAS stores the EPS Bearer Identity and links
the dedicated bearer to the default bearer indicated by the Linked EPS Bearer
Identity (LBI).
6.
The UE uses the uplink packet filter (UL TFT) to determine the mapping of
traffic flows to the radio bearer. The UE may provide the EPS Bearer QoS parameters
to the application handling the traffic flow. The application usage of the EPS Bearer
QoS is implementation dependent.
7. The UE acknowledges the radio bearer activation to the eNodeB with a RRC
Connection Reconfiguration Complete message.
8. The eNodeB acknowledges the bearer activation to the MME with a Bearer Setup
Response (EPS Bearer Identity, S1-TEID) message.
9. The UE NAS layer builds a Session Management Response including EPS Bearer
Identity. The UE then sends a Direct Transfer (Session Management Response)
message to the eNodeB.
10. The eNodeB sends an Uplink NAS Transport (Session Management Response)
message to the MME.
11. Upon reception of the Bearer Setup Response message in step 7 and the Session
Management Response message in step 9, the MME acknowledges the bearer
activation to the Serving GW by sending a Create Bearer Response (EPS Bearer
Identity, S1-TEID) message.
12. The Serving GW acknowledges the bearer activation to the PDN GW by sending a
Create Bearer Response (EPS Bearer Identity, S5/S8-TEID) message.
TK420
Page 39
13. If the dedicated bearer activation procedure was triggered by a PCC Decision
Provision message from the PCRF, the PDN GW indicates to the PCRF whether the
requested PCC decision (QoS policy) could be enforced or not, allowing the
completion of the PCRF-Initiated IP-CAN Session Modification procedure or the PCEF
initiated IP-CAN Session Modification procedure, after the completion of IP-CAN
bearer signaling.
6.5 Paging Procedure

The MME initiates the paging procedure by sending the PAGING message to the eNB.
At the reception of the PAGING message, the eNB shall perform paging of the UE in cells
which belong to tracking areas as indicated in the List of TAIs IE.
The CN Domain IE shall be transferred transparently to the UE.
The Paging DRX IE may be included in the PAGING message.
The Allowed CSG ID List of the paged UE (CSG Id List IE) may be included in the PAGING
message if respective subscription information is available for that UE. If present, the EUTRAN shall, if possible, avoid to send paging UEs within CSG cells for which the UE has no
subscription.
TK420
Page 40
Paging
A UE attached to the system and in ECM_IDLE state is traceable only to
its registered TAs.
Usually, this is triggered by the arrival of downlink data for an idle UE
at the Serving Gateway (S-GW).
Another reason could be that the MME wants to establish C-plane
connectivity for other reasons, for example the network-initiated TAU
procedure, or for location services..
The MME starts paging by distributing a paging request message to
each eNB supporting cells corresponding to the UE's registered tracking
areas.
The MME also coordinates paging responses and supervises the
process by scheduling retransmissions.
Figure 29 Paging
For each cell that belongs to any of the TA indicated in the List of TAIs IE, the eNB shall
generate one page on the radio interface.
When the paging indication is received, the UE responds to the paging procedure with a
Service Request message.
TK420
Page 41
Paging
Used to get UE from ECM-IDLE to ECM-CONNECTED and to
establish the E-RAB.
SAE-GW
MME
DL Data Notification
RRC: PAGING
Message
PAGING
(UE-ID IE, S-TMSI IE or
IMSI, TAIs IE, CN Domain
IE, Paging DRX IE, CSG Id
List IE)
Incoming
data
Service request procedure

Figure 30 Paging Procedure
7 EPS Authentication and Key Argument

Wireless communication, in its nature, is always at a risk of eavesdropping or manipulation
because data originally sent from/to a user may be received and unlawfully used by an
unintended user. Locations or traveling routes of a user can also be easily tracked by tracing
to which cells the user is connected or through which cells the user is travelling. And this can
result in privacy infringement. Mobile communication networks provide security features to
ensure data transferred across radio links is not manipulated, prevent unauthorized access
by an unintended user to the data received, and protect the privacy of users.
The LTE Security document describes basic security features offered by LTE networks,
including LTE authentication, NAS security and AS security. LTE authentication is the process
of determining whether a user is an authorized subscriber to the network that he/she is
trying to access, while NAS security and AS security are features required to securely deliver
user data that travels through LTE radio links at NAS and AS levels.
9.1 LTE Security Concept

9.1.1 Scope and Concept of LTE Security
TK420
Page 42
The Following figure shows the scope and overall concept of the LTE Security documents.
The scope of these documents will include the following three areas:
LTE Authentication: performs mutual authentication between a UE and a network.
NAS Security: performs integrity protection/verification and ciphering
(encryption/decryption) of NAS signaling between a UE and an MME.
AS Security
performs integrity protection/verification and ciphering of RRC signaling between a
UE and an eNB.
performs ciphering of user traffic between a UE and an eNB.
Figure 31 Scope and concept of LTE security

LTE Authentication:
In mobile communication networks, authentication refers to the process of determining
whether a user is an authorized subscriber to the network that he/she is trying to access.
Among various authentication procedures available in such networks, EPS AKA
(Authentication and Key Agreement) procedure is used in LTE networks for mutual
authentication between users and networks.
The EPS AKA procedure consists of two steps. First, an HSS generates EPS authentication
vector(s) (RAND, AUTN, XRES, KASME) and delivers them to an MME. Then in the second
step, the MME selects one of the authentication vectors and uses it for mutual
authentication with a UE and shares the same authentication key (KASME) each other.
Mutual authentication is the process in which a network and a user authenticate each other.
In LTE networks, since the ID of the user's serving network is required when generating
TK420
Page 43
authentication vectors, authentication of the network by the user is performed in addition to

authentication of the user by the network.
ASME (Access Security Management Entity) is an entity that receives top-level key(s), from
an HSS, to be used in an access network. In EPS, an MME serves as ASME and KASME is used
as the top-level key to be used in the access network. The MME, on behalf of an HSS,
conducts mutual authentication with a UE using KASME. Once mutually authenticated, the
UE and MME get to share the same KASME as an authentication key.
To avoid any possible eavesdropping or manipulation of data across radio links, KASME is not
delivered to the UE via E-UTRAN. Instead, the MME delivers part of authentication vector to
the UE, which uses it to authenticate the network and generates KASME as the HSS does.
HSS
MME
NAS: Attach Request

(IMSI)
NAS: Authentication Request
(RAND, AUTN)
NAS: Authentication Response
(RES)
Authentication Information Request

(IMSI, Visited PLMN-ID, type and
number of requested AVs)
Authentication Information Answer
(requested Avs={AUTN, XRES, RAND,
Kasme})
RES = XRES
NAS: Security Mode Command

(selected ciphering and integrity algorithms, UE security capability)
NAS: Security Mode complete
MME generates KeNB,

Knas_enc and Knas_int
S1AP: Initial Context Setup

(Security Key (KeNB))
eNB generates Krrc_enc,

Krrc_int and Kup_enc
RRC: Security Mode Command
(selected ciphering and integrity algorithms)
UE generates Krrc_enc,
Krrc_int, Kup_enc,
NAS Security:
NAS security, designed to securely deliver signaling messages between UEs and MMEs over
radio links, performs integrity check (i.e., integrity protection/verification) and ciphering of
NAS signaling messages. Different keys are used for integrity check and for ciphering. While
integrity check is a mandatory function, ciphering is an optional function. NAS security keys,
such as integrity key (KNASint) and ciphering key (KNASenc), are derived by UEs and MMEs
from KASME.
TK420
Page 44
AS Security:
AS security is purposed to ensure secure delivery of data between a UE and an eNB over
radio links. It conducts both integrity check and ciphering of RRC signaling messages in
control plane, and only ciphering of IP packets in user plane. Different keys are used for
integrity check/ciphering of RRC signaling messages and ciphering of IP packets. Integrity
check is mandatory, but ciphering is optional.
AS security keys, such as KRRCint, KRRCenc and KUPenc, are derived from KeNB by a UE and
an eNB. KRRCint and KRRCenc are used for integrity check and ciphering of control plane
data (i.e., RRC signaling messages), and KUPenc is used for ciphering of user plane data (i.e.,
IP packets). Integrity check and ciphering are performed at the PDCP (Packet Data
Convergence Protocol) layer.
A UE can derive KeNB from KASME. However, since KASME is not transferred to an eNB, an
MME instead generates KeNB from KASME and forwards it to the eNB.
LTE Integrity mechanism

COUNT
MESSAGE
Key
COUNT
DIRECTION
BEARER
DIRECTION
MESSAGE
EIA
BEARER
EIA
Key
MAC-I/NAS-MAC
XMAC-I/XNAS-MAC
Sender
Receiver
9.1.2 Overview of LTE Security Procedure

Following figure shows the overview of LTE security procedure.
authentication procedure while
and AS respectively.
TK420
and
displays LTE
demonstrate security setup procedures for NAS
Page 45
Figure 2. Overview of LTE security procedure

LTE Authentication
When a user requests for access to a LTE network, mutual authentication between the
user and the network is conducted using EPS AKA procedure. An MME, upon receipt of
such request, identifies the user using his/her IMSI and requests authentication
vector(s) (AVs) from an HSS1. The HSS then generates AV(s) using EPS AKA algorithm,
AV={RAND, XRES, AUTNHSS, KASME}, and forwards them to the MME.
After storing the AVs, the MME selects one of them and uses it to perform mutual
authentication with the UE2. The MME forwards RAND and AUTNHSS to the UE, which
then computes RES, AUTNUE and KASMEusing EPS AKA algorithm. The UE now
compares its own AUTNUE and AUTNHSS received from the MME for network
authentication. Once authenticated, RES is forwarded to the MME, which then
compares the XRES received from the HSS and the RES received from the UE for user
authentication. If the UE and network have authenticated each other, they share the
same key KASME (KASME is not transferred between UE and MME, though).
NAS Security
TK420
Page 46
Once the UE and MME have authenticated each other and the same key KASME is
shared, NAS security setup procedure begins. In this procedure, NAS security keys to
be used when delivering NAS signaling messages are derived from KASME for secure
delivery of these messages. This procedure consists of a round trip of NAS signaling
messages (Security Mode Command and Security Mode Completemessage), and
begins when the MME delivers a Security Mode Command message to the UE.
First, the MME selects NAS security algorithms (Alg-ID: Algorithm ID) and uses them to
create an integrity key (KNASint ) and a ciphering key (KNASenc) from KASME. Then, it
applies KNASint to the Security Mode Command message to generate an NAS
message authentication code (NAS-MAC, Message Authentication Code for NAS for
Integrity). The MME then delivers the Security Mode Commandmessage including the
selected NAS security algorithms and the NAS-MAC to the UE. As the UE does not
know the selected encryption algorithm yet, this message is integrity protected only
but not ciphered.
Upon receiving the Security Mode Command message, the UE verifies the integrity
thereof by using the NAS integrity algorithm selected by the MME and uses NAS
integrity/ciphering algorithm to generate NAS security keys (KNASint and KNASenc)
from KASME. Then it ciphers the Security Command Completemessage with
KNASenc and generates a message authentication code, NAS-MAC with KNASint to the
ciphered message. Now it forwards the ciphered and integrity protected message to
the MME with the NAS-MAC included.
Once the MME successfully verifies the integrity of the received Security Mode
Complete message and has them decrypted using the NAS security keys (KNASint and
KNASenc), the NAS security setup procedure is completed.
Once the NAS security is set up, NAS signaling messages between the UE and the MME
are ciphered and integrity protected by the NAS security keys and then securely
delivered over radio links.
AS Security
After NAS security setup is finished, AS security setup procedure between a UE and an
eNB begins. In this procedure, AS security keys to be used when delivering RRC
signaling messages and IP packets are derived from KeNB for secure delivery of these
data. This procedure consists of a round trip of RRC signaling messages (Security Mode
Command and Security Mode Complete message), and begins when an eNB
delivers Security Mode Command message to the UE.
First, the MME calculates KeNB from KASME and delivers it to the eNB, which uses it
to perform the AS security setup procedure. The eNB selects AS security algorithms
(Alg-ID: Algorithm ID) and uses them to create an integrity key (KRRCint) and a
ciphering key (KRRCenc), from KeNB. to be used for RRC signaling messages, and a
ciphering key (KUPenc) to be used in the user plane. Then, it applies KRRCint to
TK420
Page 47
the Security Mode Command message to generate a message authentication code

(MAC-I, Message Authentication Code for Integrity). The eNB now delivers the Security
Mode Command message including the selected AS security algorithms and the MAC-I
to the UE.
Upon receiving the Security Mode Command message from the eNB, the UE verifies
the integrity thereof by using the AS integrity algorithm selected by the eNB and uses
AS integrity/ciphering algorithm to generate AS security keys (KRRCint, KRRCenc and
KUPenc). Then it generates a message authentication code, MAC-I, with the RRC
integrity key to the Security Command Complete message, and then forwards the
message including the MAC-I to the eNB.
When the eNB successfully verifies the integrity of the received Security Mode
Complete message by using the AS integrity key, the AS security setup procedure is
completed.
After the AS security is set up, RRC signaling messages between the UE and the eNB
are ciphered and integrity protected by the AS security keys, and user IP packets are
encrypted and then securely delivered over radio links.
9.2 LTE Authentication Procedure

The LTE authentication procedure briefly described in Chapter II will be further discussed
below. Figure 3 shows the EPS AKA-based LTE authentication procedure that is performed
when a UE attaches to the LTE network. On the USIM and in the HSS/AuC are stored a
permanent key, LTE key (K), and IMSI3. These LTE key (K) and IMSI are stored on the USIM
card when UE is being manufacturing, and provisioned in the SS/AuC when a user begins
subscription to his/her operators network.
TK420
Page 48
Figure 3. LTE authentication procedure

9.2.1 Authentication Request by UE
[UE MME] Request by UE for Network Registration
When a UE attempts to access the network for initial attach, it delivers Attach
Request (IMSI,UE Network Capability, KSIASME=7) message to an MME. And this triggers EPS
AKA procedure. The following information elements are included in the Attach
Request message:
IMSI: International Mobile Subscriber Identity, a unique identifier associated with the
user
UE Network Capability: security algorithms available to UE
KSIASME=7: indicates UE has no authentication key
UE network capability informs the MME of what kinds of capability the UE has related
to EPS, and indicates which NAS and AS security algorithms, i.e., EPS Encryption
Algorithms (EEA) and EPS Integrity Algorithms (EIA) are supported by the UE. Each of
them has a value of 1 bit that is presented as on (supported) or off (not supported)
(e.g. EEA0=on, EEA1=on, EEA2=off, , EIA1=on, EIA2=on, ). Table 1 lists some of UE
network capability information, specifically ciphering and integrity protection
algorithms.
TK420
Page 49
Table 1. UE network aapability information EEA and EIA [3]

EEA
EIA
EEA0
Null ciphering algorithm
EIA04
Null integrity protection algorithm
128-EEA1
SNOW 3G
128-EIA1
SNOW 3G
128-EEA2
AES
128-EIA2
AES
128-EEA3
ZUC
128-EIA3
ZUC
KSIASME identifies KSIASME for te UE and the MME. It is 3 bits and has values ranging
from 0 ('000') to 7 ('111'), where 7 ('111') indicates the UE has no KASME available.
9.2.2 Authentication Data Exchange between MME and HSS
[MME HSS] Request by MME for Authentication Data
The MME recognizing the UE has no KASME available initiates LTE authentication procedure
to get new authentication data by sending an Authentication Information Request (IMSI, SN
ID, n, Network Type) message to the HSS. Message parameters used for this purpose are as
follows:
IMSI: a unique identifier associated with the user

SN ID (Serving Network ID): refers to the network accessed by the user. Consists of
PLMN ID (MCC+MNC).
n (number of Authentication Vectors): No. of authentication vectors that MME
requests
Network Type: type of the network accessed by UE (E-UTRAN herein)
Upon receipt of the Authentication Information Request message from the MME, the HSS
generates RAND and SQN, and creates XRES, AUTN, CK and IK using EPS AKA algorithm with
LTE key (K), SQN and RAND. Thereafter, using CK, IK, SQN and SN ID, it derives a top-level key
(KASME) of the access network, from Key Derivation Function (KDF), to be delivered to
the MME. KDF is a one-way has function. Since SN ID is required when deriving KASME,
KASME is derived again if the serving network is changed. After KASME is derived, the HSS
forms authentication vectors AVi=(RANDi, AUTNi, XRESi, KASMEi), i=0..n.
[MME HSS] Response by HSS to the Authentication Data Request
The HSS forms as many AVs as requested by the MME and then delivers an Authentication
Information Answer (AVs) message to the MME.
9.2.3 Mutual Authentication by UE and MME
The MME stores the AVs received from the HSS, and selects one of them to use in LTE
authentication of the UE. In Figure 3, the MME selected ith AV (AVi). KASME is a base key of
MME and serves as a top-level key in the access network. It stays within EPC only and is not
TK420
Page 50
delivered to the UE through E-UTRAN, which is not secure. The MME allocates KSIASME, an
index for KASME, and delivers it instead of KASME to the UE so that the UE and the MME can
use it as a substitute for KASME (in Fig. 3, KSIASME=1).
[UE MME] Request by MME for User Authentication
The MME keeps KASMEi and XRESi in AVi but delivers KSIASMEi, in substitution for KASMEi,
RANDi and AUTNias included in the Authentication Request (KSIASMEi, RANDi, AUTNi)
message to the UE. XRESi is used later in
when authenticating the user.
The UE, upon receiving the Authentication Request message from the MME, delivers
RANDi and AUTNito USIM. USIM, using the same EPS AKA algorithm that the HSS used,
derives RES, AUTNUE, CK and IK with the stored LTE key (K) and RANDi and SQN generated
from the HSS5. The UE then compares AUTNUE generated using EPS AKA algorithm and
AUTN received from MME (AUTNi in Fig. 3) to authenticate the LTE network (the serving
network).
[UE MME] Response by UE to User Authentication
Once the UE completes the network authentication, it delivers an Authentication
Response (RES) including RES generated using EPS AKA algorithm to MME. If the network
authentication using AUTN fails in 4, UE sends an Authentication Failure (CAUSE) message
that contains a CAUSE field stating reasons for such failure.
When the MME receives the Authentication Response message from the UE, it compares
RES generated by the UE and XRESi of the AV received from the HSS to authenticate the
user.
USIM delivers CK and IK to the UE after its network authentication is completed. The
UE derives KASMEusing Key Derivation Function (KDF) with CK, IK, SQN and SN ID and
stores it using KSIASME received from the MME as its index. Thereafter, KSIASME is
used instead of KASME during the NAS security setup between the UE and the MME.
IV. Closing
We have discussed the LTE authentication, one of the LTE security topics. As seen so
far, LTE authentication is mutual authentication performed by and between a user and
a network based on EPS AKA procedure. An MME in the serving network performs
mutual authentication with a UE on behalf of an HSS, and as a result, KASME is shared
by the UE and the MME. Table 2 summarizes the LTE authentication-related keys
covered herein. In Part II, LTE Security II, that follows, NAS and AS security setup
procedures based on KASME discussed herein will be further explained.
Table 2. LTE security keys: authentication
Key
Length
Location
Derived from
K
128 bits USIM, HSS/AuC
TK420
Description
LTE key
Page 51
CK
IK
KASME 256 bits UE, HSS, MME
TK420
K
K
CK, IK
Cipher key
Integrity key
MME base key
Page 52
AKA and signalling protection

AKA procedure
MME
LTE-Uu
eNB
LTE-UE
SGW
Confidentiality and integrity for signalling and confidentiality for user plane (RRC & NAS)
Confidentiality and integrity for signalling only (NAS)
Optional user plane protection (IPsec)
Figure 32 AKA and signalling protection

HSS
MME
NAS: Attach Request

(IMSI)
NAS: Authentication Request
(RAND, AUTN)
NAS: Authentication Response
(RES)
Authentication Information Request

(IMSI, Visited PLMN-ID, type and
number of requested AVs)
Authentication Information Answer
(requested Avs={AUTN, XRES, RAND,
Kasme})
RES = XRES
NAS: Security Mode Command

(selected ciphering and integrity algorithms, UE security capability)
NAS: Security Mode complete
MME generates KeNB,

S1AP: Initial Context Setup

(Security Key (KeNB))
eNB generates Krrc_enc,

Krrc_int and Kup_enc
RRC: Security Mode Command
(selected ciphering and integrity algorithms)
UE generates Krrc_enc,
Krrc_int, Kup_enc,
TK420
Page 53
Deeper Key hierarchy in LTE

USIM / AuC
K
CK, IK
UE / HSS
KASME
UE / ASME
KNASenc
KNASint
KeNB
UE / MME
KUPint
KUPenc
KRRCint
KRRCenc
UE / eNB
Faster handovers and key changes, independent of AKA

Added complexity in handling of security contexts
Security breaches local
LTE Ciphering mechanism

COUNT
BEARER
Key
COUNT
DIRECTION
LENGTH
EEA
BEARER
Key
Key stream
block
Plain text
block
DIRECTION
LENGTH
EEA
Key stream
block
Plain text
block
Cipher text
block
Sender
Receiver
Figure 33 LTE Ciphering mechanism

Figure 34 LTE Integrity mechanism
TK420
Page 54
TK420
Page 55
TK420
Page 56
04_Interworking with other radio access technologies
Chapter 4
Interworking With other
Radio Access Technologies
TK420
Page 1
1. Interworking with CS Domain

1.1 Voice in EPS
While the EPS is purely a Packet Switched (PS) only system without a specic Circuit Switched (CS)
domain with support for VoIP, the legacy 3GPP systems treat CS services such as voice calls with a
specic CS infrastructure. IMS VoIP may not be ubiquitously available, and therefore the SAE design
includes two special solutions that address inter-working with circuit switched voice.
Two specic functions have been dened for that purpose, Circuit Switched Fall Back (CSFB) and
Single Radio Voice Call Continuity (SR-VCC).
SR-VCC is a solution for converting and handing over an IMS VoIP call to a CS voice call in the
legacy CS domain. This functionality would be needed when the coverage of an IMS VoIP
capable network is smaller than that of the legacy CS networks. SR-VCC allows a UE entering
the edge of the VoIP coverage area with an ongoing VoIP call to be handed over to the CS
network without interrupting the call. SR-VCC is a one way handover from the PS network
with VoIP to the CS network. If E-UTRAN coverage becomes available again, the UE may
return there when the call ends and the UE becomes idle. The solution relies on running only
one radio at a time, i.e. the UE does not need to communicate simultaneously with both
systems. In this solution the MME is connected to the MSC Server in the CS domain via a Sv
interface, which is used for control signalling in the SR-VCC handover. A summary of
additional interfaces and protocols for inter-working with legacy 3GPP CS infrastructure is
given in next table.
CSFB is a solution for networks that do not have support for IMS VoIP. Instead, the voice calls
are handled by the CS domain, and the UE is handed over there at the time of a voice call.
The SGs interface between the MME and MSC Server is used for related control signalling
TK420
Page 1
Voice in LTE
LTE is an all packet technology supporting Packet switched domain only

Support for Voice is still a necessity
Regulatory requirements present for support of voice call [emergency calls]
In the age of smart phones, voice still accounts for 15% of mobile traffic.
CSFB is 3GPP endorsed initial voice support, commercially launched in 2011.
LTE networks are deployed alongside legacy voice networks [UTRAN/GERAN/CDMA 1xRTT]
UE will be handed over or redirected to the legacy voice RAT when Voice service is needed
Increases call establishment time by 5 to 8 seconds.
SRVCC is next logical step after CSFB in LTE road map
UE while camping in LTE uses IMS [VoLTE] for voice
Core network on both sides will be connected and synchronised.
Allows single Radio in UE to be handed over from VoLTE to legacy CS domain UTRAN/GERAN/1XRTT;
Provides a seamless voice experience to customers using LTE multi mode handsets
Some operators going for non 3GPP endorsed technologies, for example SVLTE
UE will be simultaneously camping on LTE network for data and some voice technology
No need for core networks to be connected and synchronised
2 UEs put in one plastic case
Figure 1 Voice in LTE
1.2 Circuit Switched Fallback for LTE
Voice service with LTE terminals can also be offered before high quality VoIP support is included into
LTE radio and before IP Multimedia Subsystem (IMS) is deployed. The rst phase can use so-called
CSFB for LTE where the LTE terminal will be moved to GSM, WCDMA or CDMA network to provide
the same services that exists in CS networks today, for example voice calls, video call or Location
Services. The CS fallback procedures require that the MME as well as MSC/VLR network elements are
upgraded to support procedures described in this section.
When LTE UE executes the attach procedure towards the LTE core network, the LTE core network will
also execute a location update towards the serving CS core network to announce the presence of the
terminal to the CS core network via the LTE network in addition to executing the normal attach
procedures. The UE sends the attach request together with specic CS Fallback Indicator to the
MME, which starts the location update procedure towards MSC/VLR via an IP based SGs interface.
The new Location Area Identity (LAI) is determined in the MME based on mapping from the Tracking
area. A mapped LAI could be either GERAN or UTRAN based on the operator conguration.
Additionally GERAN and UTRAN can be served by different MSC/VLR in the network architecture,
which causes execution of a roaming retry for the CS fallback procedure as described later. The VLR
TK420
Page 2
creates an association with the MME. This procedure is similar to the combined LA/RA update
supported in GERAN by using Network Mode of Operation 1 (NMO1) with Gs interface.
Circuit-switched fallback (CSFB)

The CSFB offert Voice service even if VoIP is not
supported by the LTE network.
The CS fallback procedures require upgrades in the
MME and in the MSC/VLR network elements.
To activate CSFB, UE need to make a combined
EPS/IMSI attach, which creates an association with
the MSC/VLR.
SGs interface must be implemented.
CSFB used for mobile origination and mobile
terminating calls
Figure 2 CSFB
If MME supports the connection to the multiple core network nodes similarly as SGSN does in
GERAN/UTRAN, then a single MME can be connected to multiple MSC/VLR network elements in the
CS core network. The bene t is the increased overall network resiliency compared to the situation
when the MME is connected to only a single MSC/VLR.
TK420
Page 3
MME
Attach Request
(CS Fallback Indicator)
PCRF
PGW
SGW
HSS
MSC/VLR
Combined EPS/IMSI attach
AIR
AIA
Authentication Request
Authentication Response
ULR
ULA
Create Default
Bearer Request
Create Default
Bearer Response
Create Default
Bearer Request
Create Default
Bearer Response
PCRF
Interaction
Combined EPS/IMSI attach

Location Update Request
Attach Accept
LA in CS Domain
Location Update Response
Attach complete
Figure 3 Attach wich CSFB indicator
For a mobile terminated call, MSC/VLR sends a paging message via SGs interface to the correct MME
based on the location update information. eNodeB triggers the packet handover or network assisted
cell change from LTE to the target system. The UE sends the paging response in the target system
and proceeds with the CS call setup.
An overview of the mobile terminated fallback handover is shown in next figure.
TK420
Page 4
CSFB handover mobile terminated call

1. Location update
via MME to MSS
2. Paging via LTE
E-UTRAN
MME
MSS/VLR
LTE-UE
UTRAN or
GERAN
3. Paging response
and CS call setup
in GSM/WCDMA
Figure 4 CSFB handover mobile terminated call

An overview of the mobile originated call is shown in next figure. The UE sends a CS call request to
the eNodeB, which may ask the UE to measure the target cell. eNodeB triggers the handover to the
target system. the UE starts the normal CS call establishment procedure in the target cell.
Once the CS call ends, the UE again reselects LTE to get access to high data rate capabilities. If the
service areas covered by LTE Tracking Area (TA) and GERAN/UTRAN Location Area (LA) are not
similar, the serving MSC/VLR of LTE UE is different from MSC/VLR that serves the target LA. The
target MSC/VLR is not aware of the UE and is not expecting a response to the paging message. This
case is handled with a procedure called as Roaming Retry for CS fallback. When LTE UE has received
the paging request, it executes an additional location update procedure to the target MSC/VLR to
make the target MSC/VLR aware of the existence of the UE. Based on this location update the HLR of
the LTE UE will send a cancel message to the MSC/VLR that was serving the LTE UE prior to the CS
fallback attempt. This cancel message will stop the paging process in that MSC/VLR and will trigger
the resume call handling procedure. This procedure is similar to the Mobile Terminating Roaming
Retry Call procedure used in GERAN/UTRAN to request a call to be re-routed to a new MSC/VLR from
a gateway MSC. The gateway MSC will re-execute the mobile terminating call procedure by executing
a HLR enquiry resulting in the call being routed to the correct MSC/VLR.
If there is an active packet session in LTE and if the target system supports simultaneous voice and
data connection, the packet session is relocated from LTE to the target system. If the target system
TK420
Page 5
does not support simultaneous voice and data, the data connection is suspended during the CS voice
call. This happens when LTE UE is moved to a GERAN that does not support simultaneous voice and
data connection, called Dual Transfer Mode (DTM).Voice is one of the most demanding services in
terms of delay requirements and in terms of call reliability. Many optimized GERAN (GSM) and
UTRAN (WCDMA) networks today can provide call drop rates below 0.5% or even below 0.3%. The
advantage of the fallback handover is that there is no urgent need to implement QoS support in LTE
or SAE. The network optimization may also be less stringent if the voice is not supported initially.
Also, there is no need to deploy IMS just because of the voice service. From the end user point of
view, the voice service in GSM or in WCDMA is as good as voice service in LTE, except that the
highest data rates are not available during the voice call. On the other hand, the CS fallback for LTE
adds some delay to the call setup process as the UE must search for the target cell. With high
mobility, the CS fallback for LTE may also affect the call setup success rate, which naturally needs to
be addressed in practical implementation.
Similar fallback procedures can also be used for other services familiar from todays network such as
Unstructured Supplementary Service Data (USSD) and Location Services (LCS). Due to the popularity
of SMS, the number of SMSs can be very high and the CS fallback handover may create a large
number of reselections between LTE and GERAN/UTRAN. Therefore, it was seen as the preferred way
to transmit SMSs over LTE even if the voice calls would use the CS fallback solution. If the core
network has support for IMS, then SMS body can be transferred over SIP messages in LTE as dened
by 3GPP.
TK420
Page 6

Table 1 interfaces and protocols for inter-working with legacy 3GPP CS infrastructure
TK420
Interface
Protocol
S3
GTP-C/UDP/IP
S4
GTP-C/UDP/IP
S12
GTP-C/UDP/IP
S16
GTP-C/UDP/IP
S6d
Diameter
SGs
SGsAP/SCTP/IP
Sv
Diameter
Page 7
2 Interworking with 3GPP Network

2.1 Overview of 3GPP Inter-working System Architecture Configuration
Next figure describes the architecture and network elements in the architecture conguration where
all 3GPP dened ANs, E-UTRAN, UTRAN and GERAN, are connected to the EPC.
This is called here the 3GPP Inter-working System Architecture Conguration, and it allows optimized
inter-working between the mentioned accesses. Functionally the E-UTRAN, UTRAN and GERAN all
provide very similar connectivity services, especially when looking at the situation from the end user
point of view, where the only difference may be the different data rates and improved performance,
but architecturally these ANs are quite different, and many things are carried out differently. There
are, for example, big differences in how the bearers are managed in the EPS compared to the existing
networks with UTRAN or GERAN access. However, when UTRAN or GERAN is connected to EPC, they
may still operate as before from this perspective, and for this purpose the S-GW simply assumes the
role of the Gateway GPRS Support Node (GGSN). Also in optimized inter-working with the E-UTRAN,
the GERAN and UTRAN ANs behave almost the same way as they behave when inter-working
between themselves. The differences become more visible in the EPC, because what used to be the
xed GGSN is now the S-GW that may be changed along with the SGSN change during UE mobility.
All nodes and functions described in the previous section for the Basic System Architecture
Conguration are needed here also. The EPC needs the addition of a few new interfaces and
functions to connect and inter-work with UTRAN and GERAN. The corresponding functions will also
be required from GERAN and UTRAN. The new interfaces are S3, S4 and S12 as shown in Figure 4 and
5. The interface from SGSN to HSS can also be updated to Diameter based S6d, but the use of the
legacy MAP based Gr is also possible.
TK420
Page 8
S3 and S4 Interface
S3/S4 are interfaces between EPC and 2G/3G packet switched core network
domain
They would allow inter-system changes between LTE and 2G/3G
S3: It enables user and bearer information exchange for inter 3GPP access
network mobility in idle and/or active state.
S4: It provides related control and mobility support between GPRS Core and
the 3GPP Anchor function of Serving GW. In addition, if Direct Tunnel is not
established, it provides the user plane tunnelling.
MME
GTPv2-C
GTPv1-U
UDP
UDP
IP
SGSN
S3
IP
SGW
S4
Figure 5 S3 and S4 Interfaces
Keeping E-UTRAN, i.e. the eNodeB design as focused to, and as optimized for the requirements of the
new OFDMA radio interface, and as clean of inter-working functionality as possible, was an important
guideline for the inter-working design. Consequently, the eNodeB does not interface directly with the
other 3GPP ANs, and the interaction towards the EPC is the same as in other mobility cases that
involve EPC. However, optimized inter-working means that the network is in control of mobility
events, such as handovers, and provides functionality to hand the communication over with
minimum interruption to services. This means that an eNodeB must be able to coordinate UE
measuring UTRAN and GERAN cells, and perform handover decisions based on measurement results,
and thus E-UTRAN radio interface protocols have been appended to support the corresponding new
functions. Similar additions will be required from UTRAN and GERAN to support handover to EUTRAN.
TK420
Page 9
S12 Interface
Interfaces between EPC and 3G Radio access network
It would allow inter-system changes between LTE and 3G
The S12 is the user plane interface used for tunneling user data directly between
the Serving GW and the UTRAN.
This would allow to forward packet data from 3G RAN to Serving GW to PDN GW.
It is based on the Gn interface between the SGSN and the GGSN and therefore uses
the GTP-U protocol.
GTPv1-U
UDP
IP
RNC
SGSN
S12
Figure 6 S12 Interface
Other
Networks
Services
SGi
PGW
EPC
S6a
S4
S6d or Gr
HSS
MME
S5/S8
S12
S1-MME
S16
S3
S11
SGW
SGSN
S10
Iu-PS
Gb
S1-U
UTRAN
E-UTRAN
Uu
LTE-Uu
GERAN
Um
LTE-UE
Figure 7 System architecture for 3GPP access networks
TK420
Page 10
2.2 Additional and Updated Logical Elements in 3GPP Inter-working System

Architecture Configuration
2.2.1 User Equipment
From the UE point of view, inter-working means that it needs to support the radio technologies in
question, and the mobility operations dened for moving between them. The optimized interworking means that the network controls the usage of radio transmitter and receiver in the UE in a
way that only one set of them needs to be operating at the same time. This is called single radio
operation, and allows UE implementations where only one pair of physical radio transmitter and
receiver is implemented.
The standard does not preclude implementing multiple radio transmitters and receivers, and
operating them simultaneously in dual radio operation. However, single radio operation is an
important mode, because the different ANs often operate in frequencies that are so close to each
other that dual radio operation would cause too much interference within the terminal. That,
together with the additional power consumption, will decrease the overall performance.
2.2.2 E-UTRAN
The only addition to E-UTRAN eNodeB compared to the Basic System Architecture
Conguration is the mobility to and from other 3GPP ANs. From the eNodeB perspective the
functions are very similar irrespective of whether the other 3GPP AN is UTRAN or GERAN.
For the purpose of handover from E-UTRAN to UTRAN or GERAN, the neighbouring cells from those
networks need to be congured into the eNodeB. The eNodeB may then consider handover for those
UEs that indicate corresponding radio capability. The eNodeB requests the UE to measure the signal
level of the UTRAN or GERAN cells, and analyses the measurement reports. If the eNodeB decides to
start the handover, it signals the need to the MME in the same way that it would signal inter-eNodeB
handover when the X2 interface is not available.
Subsequently, the eNodeB will receive the information needed for the Handover Command from the
target Access System via the MME. The eNodeB will send the Handover Command to the UE without
the need for interpreting the content of this information.
In the case of handover from UTRAN or GERAN to E-UTRAN, the eNodeB does not need to make any
specic preparations compared to other handovers where the handover preparation request comes
through the MME. The eNodeB will allocate the requested resources, and prepare the information
TK420
Page 11
for handover command, which it sends to the MME, from where it is delivered to the UE through the
other 3GPP Access System that originated the handover.
2.2.3 UTRAN
In UTRAN, the radio control functionality is handled by the Radio Network Controller (RNC), and
under its control the Node B performs Layer 2 bridging between the Uu and Iub interfaces.
UTRAN has evolved from its initial introduction in Release 99 in many ways, including the evolution
of architectural aspects. The rst such item is Iu ex, where the RNC may be connected to many
Serving GPRS Support Nodes (SGSNs) instead of just one. Another such concept is I-HSPA, where the
essential set of packet data related RNC functions is included with the Node B, and that connects to
Iu-PS as a single node.
Inter-working with E-UTRAN requires that UTRAN performs the same measurement control and
analysis functions as well as the transparent handover information delivery in Handover Command
that were described for eNodeB in the earlier section. Also the UTRAN performs similar logic that it
already uses with Relocation between RNCs, when the Iur interface is not used.
2.2.4 GERAN
GSM EDGE Radio AN (GERAN) is the evolved version of GSM AN, which can also be connected to 3G
Core Network. It consists of the Base Station Controller (BSC) and the Base Station (BS), and the radio
interface functionalities are divided between them.
The GERAN is always connected to the SGSN in both Control and UPs, and this connection is used for
all the inter-working functionality. Also the GERAN uses logic similar to that described above for EUTRAN and UTRAN for inter-working handover.
2.2.5 EPC
The EPC has a central role for the inter-working system architecture by anchoring the ANs together.
In addition to what has been described earlier, the MME and S-GW will support connectivity and
functions for inter-working. Also the SGSN, which supports the UTRAN and GERAN access networks,
will need to support these functions, and when these additions are supported, it can be considered
to belong to the EPC.
TK420
Page 12
The S-GW is the mobility anchor for all 3GPP access systems. In the basic bearer operations and
mobility between SGSNs, it behaves like a GGSN towards the SGSN, and also towards the RNC if UP
tunnels are set up in Direct Tunnel fashion bypassing the SGSN. Many of the GGSN functions are
actually performed in the P-GW, but this is not visible to the SGSN. The S-GW retains its role as a UP
Gateway, which is controlled by either the MME or the SGSN depending on which AN the UE is being
served by.
To support the inter-working mobility, the MME will need to signal with the SGSN. These operations
are essentially the same as between those two MMEs, and have been described earlier in section 3.2.
An additional aspect of the MME is that it may need to combine the change of S-GW and the interworking mobility with SGSN.
The SGSN maintains its role as the controlling node in core network for both UTRAN and GERAN. The
SGSN has a role very similar to that of the MME. The SGSN needs to be updated to support for S-GW
change during mobility between SGSNs or RNCs, because from the legacy SGSN point of view this
case looks like GGSN changing, which is not supported. As discussed earlier, the SGSN may direct the
UP to be routed directly between the S-GW and UTRAN RNC, or it may remain involved in the UP
handling.
From the S-GW point of view this does not really make a difference, since it does not need to know
which type of node terminates the far end of the UP tunnel.
2.3 Interfaces and Protocols in 3GPP Inter-working System Architecture

Configuration
Table 3.2 summarizes the interfaces in the 3GPP Inter-working System Architecture Conguration
and the protocols used in them. Interfaces and protocols in legacy 3GPP networks are not listed.
Interfaces and protocols listed for Basic System Architecture Conguration are needed in addition to
these.
3 Interworking with non-3GPP Network

3.1 Overview of 3GPP and Non-3GPP Inter-working System Architecture
Configuration
TK420
Page 13
Inter-working with non-3GPP ANs was one of the key design goals for SAE, and to support it, a
completely separate architecture specication was developed in 3GPP.
The non-3GPP Inter-working System Architecture includes a set of solutions in two categories. The
rst category contains a set of generic and loose inter-working solutions that can be used with any
other non-3GPP AN. Mobility solutions dened in this category are also called Handovers without
Optimizations, and the same procedures are applicable in both connected and idle mode. The second
category includes a specic and tighter inter-working solution with one selected AN, the cdma2000
HRPD. This solution category is also called Handovers with Optimizations, and it species separate
procedures for connected and idle mode.
The generic non-3GPP Inter-working System Architecture is shown in Figure 8. The specic
application of the architecture for cdma2000 HRPD inter-working and the required additional
interfaces are described with more detail in section 3.5.
Figure 8 describes the generic inter-working solution that relies only on loose coupling with generic
interfacing means, and without AN level interfaces. Since there are so many different kinds of ANs,
they have been categorized to two groups, the trusted and un-trusted non-3GPP ANs, depending on
whether it can be safely assumed that 3GPP dened authentication can be run by the network, which
makes it trusted, or if authentication has to be done in overlay fashion and the AN is un-trusted. The
P-GW will maintain the role of mobility anchor, and the non-3GPP ANs are connected to it either via
the S2a or the S2b interface, depending on whether the non-3GPP AN functions as a Trusted or Untrusted non-3GPP AN. Both use network controlled IP layer mobility with the PMIP protocol. For
networks that do not support PMIP, Client MIPv4 Foreign Agent mode is available as an option in
S2a. In addition to mobility functions, the architecture includes interfaces for authenticating the UE
within and through the non-3GPP ANs, and also allows PCC functionality in them via the Gxa and Gxb
interfaces.
TK420
Page 14
Other
Networks
AAA
S6b
SGi
SWx
S5/
S8
MME
STa
HSS
S11
S2b
S2a
SWn
Trusted
non-3GPP
Access
E-UTRAN
LTE-Uu
SWa
SWm
ePDG
Un-Trusted
non-3GPP
Access
Swu
LTE-UE
Figure 8 System architecture for 3GPP and non-3GPP access networks
In addition to the network controlled mobility solutions, a completely UE centric solution with
DSMIPv6 is also included in the inter-working solutions.
In this conguration the UE may register in any non-3GPP AN, receive an IP address from there, and
register that to the Home Agent in P-GW. This solution addresses the mobility as an overlay function.
While the UE is served by one of the 3GPP ANs, the UE is considered to be in home link, and thus the
overhead caused by additional MIP headers is avoided.
Another inter-working scenario that brings additional exibility is called the chained S8 and S2a/S2b
scenario. In that scenario the non-3GPP AN is connected to S-GW in the visited Public Land Mobile
Network (PLMN) through the S2a or S2b interface, while the P-GW is in the home PLMN. This enables
the visited network to offer a roaming subscriber the use of non-3GPP ANs that might not be
associated with the home operator at all, even in the case where P-GW is in the home PLMN. This
scenario requires that S-GW performs functions that normally belong to P-GW in order to behave as
the termination point for the S2a or S2b interfaces. In Release 8, this scenario does not support
dynamic policies through the PCC infrastructure, i.e. the Gxc interface will not be used. Also, chaining
TK420
Page 15
with GTP based S5/S8 is not supported. All other interfaces related to non-3GPP ANs are used
normally as shown in Figure 8.
Services
Other
v
Networks
SGi
E-UTRAN
EPC
PDN-GW
S2c
S2c
S2c
E-UTRAN
Trusted
non-3GPP
Access
Un-Trusted
non-3GPP
Access
LTE-UE
Figure 9 Simplied system architecture showing only S2c
3.2 Additional and Updated Logical Elements in 3GPP Inter-working System

Architecture Configuration
3.2.1 User Equipment
Inter-working between the non-3GPP ANs requires that the UE supports the corresponding radio
technologies, and the specied mobility procedures. The mobility procedures and required radio
capabilities vary depending on whether optimizations are in place or not. The procedures dened for
Handovers without Optimizations do not make any assumption about the UEs capability to use the
radio transmitters and receivers simultaneously, and both single radio and dual radio congurations
can use the procedures. However, the handover gap time is expected to be shorter, if preparing the
connections towards the target side can start already while data are still owing through the source
side. This is caused by the fact that Handovers without Optimizations do not have procedures in the
network side to assist in handover preparations, and the procedures follow the principle where UE
TK420
Page 16
registers to the target network according to the method dened for that network, and then the
network switches the ow to the target network.
This may be time consuming, since it normally includes procedures such as authentication. Also, the
decision to make these handovers is the responsibility of the UE.
The Handovers with Optimizations, i.e. inter-working with cdma2000 HRPD, assume that they do
include network control for connected mode, so the handovers are decided by the network, while
the idle mode mobility relies on UE decision making, which may use cdma2000 HRPD related
information in the LTE-Uu broadcast. Furthermore, the procedures are designed with the assumption
that single radio conguration is enough for the UE.
3.2.2 Trusted Non-3GPP Access Networks

The term trusted non-3GPP AN refers to networks that can be trusted to run 3GPP dened
authentication. 3GPP Release 8 security architecture specication for non-3GPP ANs mandates that
the Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key
Agreement (EAP-AKA') is performed. The related procedures are performed over the STa interface.
The trusted non-3GPP ANs are typically other mobile networks, such as the cdma2000 HRPD. The
STa interface supports also delivery of subscription pro le information from Authentication,
Authorization and Accounting (AAA)/HSS to the AN, and charging information from the AN to AAA
Server, which are typical functions needed in mobile networks. It can also be assumed that such ANs
TK420
Page 17
may benet from connecting to the PCC infrastructure, and therefore the Gxc interface may be used
to exchange related information with the PCRF.
The trusted non-3GPP AN connects to the P-GW with the S2a interface, with either PMIP or
MIPv4 Foreign Agent mode. The switching of UP ows in P-GW is therefore the responsibility of the
trusted non-3GPP AN when UE moves into the ANs service area.
S2a Interface
It provides the user plane with related control and mobility support between trusted
non-3GPP IP access and the PDN Gateway.
S2a is based on Proxy Mobile IP.
To enable access via trusted non-3GPP IP accesses that do not support PMIP, S2a
also supports Client Mobile IPv4 FA mode.
User PDUs
Trusted
Non-3GPP
Gateway
IPv4/IPv6
Tunneling layer
PMIPv6
S2a based on
PMIPv6
PGW
IPv4/IPv6
S2a
User PDUs
IPv4/IPv6
IPv4/IPv6
Tunneling layer
UDP
S2a based on:

Mobile IPv4 Foreign
Agent (FA) Mode
IPv4
Figure 10 S2a interface
3.2.3 Un-trusted Non-3GPP Access Networks
To a large extent, the architectural concepts that apply for un-trusted non-3GPP ANs are inherited
from the Wireless Local Area Network Inter-Working (WLAN IW) dened originally in Release 6. The
Release 8 functionality for connecting un-trusted non-3GPP ANs to EPC is specied fully in with
references to the earlier WLAN IW specications when applicable.
The main principle is that the AN is not assumed to perform any other functions besides delivery of
packets. A secure tunnel is established between UE and a special node called the Enhanced Packet
Data Gateway (EPDG) via the SWu interface, and the data delivery takes place through that tunnel.
TK420
Page 18
Furthermore, the P-GW has a trust relationship with the EPDG connected to it via the S2b interface,
and neither node needs to have secure association with the un-trusted non-3GPP AN itself.
As an optional feature, the un-trusted non-3GPP AN may be connected to the AAA Server with the
SWa interface, and this interface may be used to authenticate the UE already in the non-3GPP AN
level. This can be done only in addition to authentication and authorization with the EPDG.
3.2.4 EPC
The EPC includes quite a few additional functions for the support of non-3GPP ANs, when compared
to the previously introduced architecture congurations. The main changes are in the P-GW, PCRF
and HSS, and also in S-GW for the chained S8 and S2a/S2b scenario. In addition, completely new
elements, such as the EPDG (Evolved Packet Data Gateway) and the AAA are introduced. The AAA
infrastructure contains the AAA Server, and it may also contain separate AAA proxies in roaming
situations. Figure 8 highlights the AAA connections and functions for non-3GPP ANs.
The P-GW is the mobility anchor for the non-3GPP ANs. For PMIP based S2a and S2b interfaces, the
P-GW hosts the Local Mobility Anchor (LMA) function in a manner similar to that for the S5/S8 PMIP
interfaces. Also the Home Agent (HA) function for the Client MIPv4 Foreign Agent mode in S2a is
located in P-GW. The relation between P-GWs and non-3GPP ANs is many to many. The P-GW will
also interface with the AAA Server, which subsequently connects to HSS. This interface is used for
reporting the selected P-GW to the HSS so that it is available in mobility between non-3GPP ANs, and
to authenticate and authorize users connecting with S2c mode. Each P-GW may connect to more
than one AAA server.
The PCRF supports PCC interfaces for non-3GPP ANs. The Gxa is used towards trusted non-3GPP ANs,
and Gxb towards un-trusted non-3GPP ANs. Only Gxa is specied in detail level in Release 8. The Gxa
interface functions in a fashion similar to that of the Gxc interface. In this case the BBERF function
will be in the non-3GPP AN, and it will receive instructions from the PCRF on how to handle the
bearer level functions for the IP ows in the S2a interface. The further bearer functions internal to
non-3GPP ANs are not addressed in 3GPP specications.
The EPDG is a dedicated node for controlling the UE and inter-network connection, when an untrusted non-3GPP AN is connected to EPC. Since the AN is not trusted, the main function is to secure
TK420
Page 19
the connection. The EPDG establishes an IPsec tunnel to the UE through the un-trusted non-3GPP AN
with IKEv2 signalling over the SWu interface.
During the same signalling transaction the EAP-AKA authentication is run, and for that the EPDG
signals with the AAA Server through the SWm interface. While the SWm interface is logically
between UE and the EPDG, the SWn interface represents the interface on a lower layer between the
EPDG and the un-trusted non-3GPP AN. The Release 8 specications do not assume that EPDG would
signal with PCRF for any PCC functions, but the architecture already contains the Gxb interface for
that purpose.
The 3GPP AAA Server, and possibly a AAA Proxy in the visited network, performs a 3GPP dened set
of AAA functions. These functions are a subset of what the standard IETF dened AAA infrastructure
includes, and do not necessarily map with the way other networks use AAA infrastructure. The AAA
Server acts between the ANs and the HSS, and in doing so it creates a context for the UEs it serves,
and may store some of their information for further use. Thus, the 3GPP AAA Server consolidates the
signalling from different types of ANs into a single SWx interface towards the HSS, and terminates
the access speci c interfaces S6b, STa, SWm and SWa. Most importantly the AAA Server performs as
the authenticator for the EAP-AKA authentication through the non-3GPP ANs. It checks the
authenticity of the user, and informs the AN about the outcome. The authorization to use the AN in
question will also be performed during this step. Depending on the AN type in question, the AAA
Server may also relay subscription prole information to the AN, which the AN may further use to
better serve the UE.
When the UE is no longer served by a given non-3GPP AN, the AAA Server participates in removing
the UEs association from the HSS. Figure 8 summarizes the AAA Server main functions in relation to
other nodes.
The HSS performs functions similar to those for the 3GPP ANs. It stores the main copy of the
subscription prole as well as the secret security key in the AuC portion of it, and when requested, it
provides the prole data and authentication vectors to be used in UEs connecting through non-3GPP
ANs. One addition compared to 3GPP ANs is that since the non-3GPP ANs do not interface on the AN
level, the selected P-GW needs to be stored in the HSS, and retrieved from there when the UE
mobility involves a non-3GPP AN. The variety of different AN types are mostly hidden from the HSS,
since the AAA Server terminates the interfaces that are specic to them, and HSS only sees a single
TK420
Page 20
SWx interface. On the other hand, the subscription prole stored in the HSS must reect the needs of
all the different types of ANs that are valid for that operator.
3.3 Interfaces and Protocols in Non-3GPP Inter-working System Architecture

Configuration
Connecting the non-3GPP ANs to EPC and operating them with it requires additional interfaces to
those introduced in earlier sections. Table 3.4 lists the new interfaces.
Table 2 interfaces and protocols in non-3GPP
Interface
Protocol
S2a
PMIP/IP, or MIPv4/UDP/IP
S2b
PMIP
S2c
DSMIPv6, IKEv2
S6b
Diameter
Gxa
Diameter
Gxb
Not dened in Release 8
STa
Diameter
SWa
Diameter
SWd
Diameter
SWm
Diameter
SWn
PMIP
SWu
IKEv2
SWx
Diameter
UE foreign agent in trusted non-3GPP Access
MIPv4
UE Trusted or Un-trusted non-3GPP access
EAP-AKA
3.4 Roaming in Non-3GPP Inter-working System Architecture Configuration
Both home routed and local breakout scenarios are supported and the main variations in the
architecture relate to the PCC arrangement, which depends on where the services are consumed.
The additional consideration that non-3GPP ANs bring to roaming is related to the case where the
user is roaming to a visited 3GPP network in Home Routed model, and it would be benecial to use a
TK420
Page 21
local non-3GPP AN that is afliated with the visited network, but there is no association between that
network and the home operator. For this scenario, the 3GPP Release 8 includes a so-called chained
case, where the S-GW may behave as the anchor for the non-3GPP ANs also, i.e. it terminates the S2a
or S2b interface, and routes the trafc via the S8 interface to the P-GW in the home network.
TK420
Page 22
05_IP Multimedia Subsystem
Chapter 5
IP Multimedia Subsystem
TK420
Page 1
1 IMS Overview
When studying the general architecture in the IMS we should keep in mind that 3GPP does
not standardize nodes, but functions. The IMS architecture is a collection of functions linked
by standardized interfaces. We can implement several functions into a single node and a
single function can be split into two or more nodes.
In general, most vendors follow the 3GPP IMS architecture closely. It is possible to nd
nodes implementing more than one function and functions distributed over more than one
node.
IMS architecture is split to three layers: transport layer, control layer, and service layer.
Transport Layer
The transport layer is responsible for hiding the nature of the access networks from the IMS
architecture. It is responsible for doing initial IP provisioning (assigning IP address and
default gateway via DHCP) as well as facilitating the registration of devices with the higher
layers (Control layer or Application layer).
Control Layer
The control layer controls the authentication, routing, and distribution of IMS traffic
between the transport layer and the application layer. Most of the traffic in this layer is
based on the session initiation protocol (SIP) that is often associated with VoIP technology.
In addition to routing SIP messages to their appropriate services, the control layer also
provides the capability to interface the application layer with other services.
The main entity in the control layer is the CSCF Call Session Control Function which facilitates
the correct interaction between the application servers, media servers, and the Home
Subscriber Service (HSS), that is the centralized repository for all subscriber account
information. This enables the IMS devices to have multiple services delivered nearly
simultaneously over a single session.
TK420
Page 1
Application Layer (Service Layer)

The application layer is where all of the actual services live. This includes traditional voice
services (like voicemail, announcements, interactive voice response, and so on) as well as
new applications built on the IMS architecture. This is the final layer of abstraction that gives
IMS architecture the power and flexibility to rapidly deploy new services.
Services Elements
AS
MRFC
Mp
MRFP
Other
Networks
Mb
Mr
ISC
ISC, Ma
IBCF
Mx
Sh, Si
S-CSCF
Cx
Dh
Ut
Mi
Mw
Mx
HSS
SLF
Dx
Session
Management Mw
And Routing
Mg
TrGW
Ici
Interworking Elements
BGCF
I-CSCF
Mb
Ix
CS Domain
Mk
Mj
Mb
Mn
P-CSCF
Databases
Rx
MGCF
IMS-MGW
SGi
Gm
S7
SAE-GW
PCRF
Radio Access Network

LTE-UE
Figure 1 IMS Architecture
The IMS specification defines the following network functions:

CSCF Call Session Control Functions:
CSCFs are SIP servers and clients. They provide session control functionality known from SIP
Redirect servers, SIP Proxy servers and SIP Registrars. We can find different types of CSCF
that are P-CSCF, I-CSCF, S-CSCF and E-CSCF.
HSS Home Subscriber Server:
TK420
Page 2
The HSS is similar to the HLR and the AuC for the GSM. It stores IMS subscriber profiles and
several informations of the session to be established. For example, when an IMS subscriber
is registered, the associated P-CSCF is stored in the HSS. This can be used to locate the user
in case of mobile terminated sessions.
SLF Subscription Locator Function.
The SLF is used in case we find many HSS servers in the Network. So, in order to determine
which HSS server to communicate with, the message is first sent to the SLF. The SLF then
returns the address of the required HSS.
MGCF Media Gateway Control Function.
The MGCF Communicates with CSCF, BGCF, and circuit switched network entities. It controls
the parts of the call state to control media channels in an IMS-MGW. Depending of the
routing number of the incoming calls, the MGCF determines the next hop.
BGCF Breakout Gateway Control Function.
The BGCF is used to select the breakout of a media stream. Therefore the BGCF is used to
determine which MGCF or which PSTN/ISDN network shall be used for the media stream.
If the originating S-CSCF is unable to route a SIP INVITE request for a SIP session setup to a
terminating IMS network, the SIP INVITE request is forwarded to BGCF. This occurs when the
originating S-CSCF is unable to perform a successful ENUM translation, or when service
numbers must be routed to BGCF. BGCF is then required for IMS breakout, and the resulting
IMS interworking with the CS/PSTN domains. When BGCF receives a SIP INVITE request, it is
then responsible for selecting the media gateway control function (MGCF) for local IMS
breakout, or another BGCF in a remote network for remote IMS breakout. In the latter case,
the local BGCF forwards the SIP request to a remote BGCF over a standard Mk interface.
BGCF is implemented as follows:
As stated above, S-CSCF and BGCF are co-located. By default, each S-CSCF accesses its
own BGCF internally over the Mi interface. Since the Mi interface is implemented in a
TK420
Page 3
standard manner, it can be configured to support interworking with a 3rd party BGCF as
well.
BGCF uses a set of rules and filters to select MGCF.
MRFC Multimedia Resource Function Controller
This function controls a MRFP for announcements, trans-coding or multi-party calls.
MRFP Multimedia Resource Function Processor
MRFP acts as multi-conferencing unit to transcode, mix media streams and as multimedia
announcement machines and is controlled by a MRFC.
LRF Location Retrieval Function:
The LRF Retrieval Function retrieves location information for the UE.
IBCF Interconnection Border Control Function:
The IBCF provides application specific functions at the SIP/SDP protocol layer to perform
interconnection between two operator domains. it enables communication between IPv6
and IPv4 SIP applications, network topology hiding, selecting the appropriate signaling
interconnect (TrGW) and generation of charging data records.
MRB The Media Resource Broker
MRB supports the sharing of a pool of MRF resources by assigning suitable MRF resources to
calls.
IMS MGW IMS-Media Gateway.

A MGW provides functionality and resources to perform switching/routing, transport layer
conversion and media stream processing. It is controlled by a MGCF. MGW can also be used
to connect IMS with ISDN/PSTN networks.
TrGW The Transition Gateway
TK420
Page 4
TrGW is located within the media path and controlled by an IBCF. It provides functions like
network address/port translation and IPv4/IPv6 protocol translation.
TK420
Page 5
2 IP-CAN
According to 3GPP the IP multimedia Subsystem utilizes the IP- Connectivity Access Network
(IP-CAN) to transport multimedia signaling and bearer traffic. The IP-CAN maintains the
service, while the terminal moves and hides these moves from the IP multimedia subsystem.
The IMS is situated between the IP-Connectivity Network (to provide the access for the
mobile subscribers) on one side and the actual services. The IMS provides here on one side
central functionality towards the subscribers like application services, Quality of Service
policy, one common IP Network, common charging function etc. On the other side it uses
the services of the application servers, connections to CS Networks, other IMS etc.
IP-Connectivity Access Network
Figure 2: IP-CAN.
As already stated the IP Connectivity Access Network (IP-CAN) is the link between the user
equipment on one side and the IP Multimedia Subsystem on the other side. It provides the
signaling and traffic or multimedia connection. The access comprises the physical
connection: radio interface, cable based connections. Common for all access networks at the
TK420
Page 6
end is an IP based signaling connection and an IP based bearer connection: IPv4 or IPv6
could be used.
Depending on the used technology there can be different types of access technology:
PS network 2G, 3G UMTS

A primary PDP Context has to be set up via the base station system, the SGSN
and the GGSN. Inside this PDP context the SIP takes care for the IMS session
setup. A secondary PDP Context is used as a bearer connection: transporting the
media plane traffic.
PS LTE
A bearer has to be set up via the Evolved UMTS Radio Access Network, the
serving nodes (MME and SGW) and the packet data network gateways (PDNGW). Inside this primary bearer the SIP signaling messages are used for the IMS
session setup. A secondary bearer is used as a media plane connection.
WLAN and WIMAX

Wireless connections via 802.11 or 801.16 can be used to access the IMS. Via the
air connection as well as the cable based connection IP is used to transport the
session initiation protocol as well as to carry the bearer. The WLAN/WIMAX
network accesses the IMS via the Packet data Gateway.
Fixed Network
The fixed network is accessed via a wireless or wired connection in the customer
premises and from there via digital subscriber line (DSL). The fixed network
provides as a IP-CAN the access technology to the mobile subscriber. The DSL
and the fixed network cable connection carries the bearer as well as the session
initiation Protocol signaling.
TK420
Page 7
IP-Connectivity Access Network
Figure 3: IP-CAN types.
TK420
Page 8
3 IMS Architecture
The IP Multimedia Services Sub-System (IMS) is the preferred service machinery for LTE/SAE.
IMS was rst introduced in Release 5, and with the well dened inter-working with existing
networks and services that have been introduced since, the Rel-8 IMS can now be used to
provide services over xed and wireless accesses alike. IMS is an overlay service layer on top
of the IP connectivity layer that the EPS provides.
Next figure shows a thick grey line from UE to P-GW that represents the UEs IP connectivity
to IMS and other external networks through the RAN and EPC. The signalling interfaces Gm
and Ut run on top of this connection, which typically use the default bearer a UE will always
have in LTE/SAE. The services may further require that dedicated bearers are set up through
EPC, and the service data ows may need to be handled by one of the Inter-working or
Services Elements.
In principle the IMS is independent of the connectivity layer, which requires its own
registration and session management procedures, but it has also been specically designed
to operate over the 3GPP-dened ANs, and it works seamlessly with the PCC. IMS uses SIP
protocol for registration and for controlling the service sessions.
SIP is used both between the terminal and the IMS (Gm Interface) and between various IMS
nodes (ISC, Mw, Mg, Mr, Mi, Mj, Mx, Mk and Mm Interfaces). Diameter (Cx, Dx, Dh and Sh
Interfaces) and H.248 (Mp) are the other protocols used in IMS.
TK420
Page 9
Services Elements
AS
MRFC
Mp
MRFP
Other
Networks
Mb
Mr
ISC
ISC, Ma
IBCF
Mx
Sh, Si
S-CSCF
Cx
Dh
Ut
Mi
Mw
Mx
HSS
SLF
Session
Management Mw
And Routing
I-CSCF
Mg
TrGW
Ici
Interworking Elements
BGCF
Dx
Mb
Ix
CS Domain
Mk
Mj
Mb
Mn
P-CSCF
Databases
Rx
MGCF
IMS-MGW
SGi
Gm
SAE-GW
S7
PCRF
Radio Access Network

LTE-UE
Figure 4 IMS architecture
The UE primarily signals with the CSCFs for the services it wishes to use, and in addition
some service specic signalling may be run directly with the Application Servers. The
signaling may also be network originated for terminating services. The Session Management
and Routing functions are handled by the CSCFs that are in control of the UEs registration in
IMS.
For that purpose they signal with the Databases to get the appropriate information. The
CSCFs are also in control of the UEs service sessions in IMS, and for that purpose they may
need to signal with one or more of the Services Elements to know what kind of connectivity
is needed for the service in question, and then with the connectivity layer through the Rx
interface to make corresponding requests to bearer resources. Finally, the CSCFs may need
to signal with one or more of the Inter-working Elements to control the interconnection
between networks.
TK420
Page 10
Whenever the UP ow is routed through one of the IMS elements, it is done through the Mb
interface that connects IMS to IP networks. The following sections introduce the main
functions in the functional groups highlighted in Figure 4.
Most IMS elements responsible for session management and routing or inter-working are
involved in collecting charging information. Rf and Ro interfaces are the main IMS charging
interfaces. For simplicity, charging related nodes and interfaces are not shown in Figure 4.
3.1 Session Management and Routing

The Call State Control Function (CSCF) is the central element in SIP signalling between the
UE and the IMS, and it takes care of the UEs registration to the IMS, and service session
management. The registration includes authentication. The primary authentication method
is IMS-AKA, but other methods such as http digest may also be used. CSCF is dened to have
three different roles that may reside in the same node, or separate nodes connected
through the Mw interface, and all are involved in the UE-related SIP signalling transactions.
CSCF
Is the central and the essential entity.
CSCF is a SIP server.
4 types of CSCF:
* Proxy CSCF,
* Serving CSCF,
* Interrogating,
* Emergency CSCF .
Figure 5 CSCF Functions
TK420
Page 11
3.1.1 The Proxy CSCF

The Proxy (P-CSCF) is the closest IMS node the UE interacts with, and it is responsible for all
functions related to controlling the IP connectivity layer, i.e. the EPS. For this purpose the PCSCF contains the Application Function (AF) that is a logical element for the PCC concept.
The P-CSCF is typically located in the same network as the EPS, but the Rel-8 includes a socalled Local Breakout concept that allows P-CSCF to remain in the home network, while
PCRF in the visited network may still be used.
The P-CSCF is the rst point of contact of the IMS terminal with the IMS network. From the
SIP point of view the P-CSCF is acting as an SIP proxy server. This means that all the signaling
messages send by or received by the IMS terminal traverses the P-CSCF. The P-CSCF
forwards SIP requests and responses in the appropriate direction.
During an IMS registration of an IMS user, a P-CSCF is allocated to that User and does not
change for the duration of the registration. So, the IMS terminal communicates with a single
P-CSCF during the registration.
The P-CSCF includes several functions related to security. It establishes a number of IPsec
security associations toward the IMS terminal. These IPsec security associations offer
integrity protection: The ability to detect whether the contents of the message have
changed since its creation.
Once the P-CSCF authenticates the user, the P-CSCF asserts the identity of the user to the
rest of the nodes in the network. This way, other nodes do not need to further authenticate
the user, because they trust the P-CSCF.
Additionally, the P-CSCF veries the correctness of SIP requests sent by the IMS terminal.
This verication keeps IMS terminals from creating SIP requests that are not built according
to SIP rules.
The P-CSCF also includes a compressor and a decompressor of SIP messages. Given that SIP
is a text-based protocol, SIP messages can be too huge. While a SIP message can be
transmitted over a broadband connection in a fairly short time, transmitting large SIP
messages over a narrowband channel may take a few seconds. The mechanism used to
TK420
Page 12
reduce the time to transmit a message is to compress the message, send it over the air
interface, and decompress it at the other end.
The P-CSCF may include a PDF (Policy Decision Function). The PDF may be integrated with
the P-CSCF or be implemented as a stand-alone unit. The PDF authorizes media plane
resources and manages Quality of Service over the media plane.
The P-CSCF also generates charging information toward a charging collection node.
An IMS network usually includes a number of P-CSCFs for the sake of scalability and
redundancy. Each P-CSCF serves a number of IMS terminals, depending on the capacity of
the node.
Proxy-Call Session Control Function (P-CSCF)

Statfull SIP proxy server.
PDF
Entry point to IMS cloud from any Access network.

All the signaling messages goes through it.
contains the AF that is a logical element for the PCC
concept
Establishes a number of IPsec security associations
toward the IMS terminal, and Perform the integrity
protection
Rx
Asserts the identity of the user to the rest of the nodes

in the network.
IMS Client
Veries the correctness of SIP requests
Mw
Gm
IP-CAN
Compression and decompression of SIP signaling

messages.
It includes a PDF that authorizes bearer resources.
P-CSCF
I/S-CSCF
Mn
Generates charging information

Collocated with the BCF
BGF
Figure 6: Proxy-CSCF
In the P-CSCF is the visited operator can specify from which domains users are
permitted/restricted to access this IMS as visited IMS. The check on the P-CSCF gives the
visited network operator the opportunity to have roaming traffic under control and to
specify other networks with a signed roaming agreement. The check can be provided on a
domain basis only, since there are no user specific data available on the P-CSCF for "visitors".
TK420
Page 13
The P-CSCF contains two lists, one for the home domains and one for the foreign domains. In
the lists the "allowed" and "forbidden" domains can be entered.
First the P-CSCF has to examine each REGISTER request, it checks whether the domain part
of the users IMPU (obtained from the from header) matches to any value preconfigured in
the home domains list. If the value matches then the Request is handled according to
current implementation. Otherwise the check is conducted again but against foreign
domains list. If the domain is not allowed then the 403 Forbidden response has to be send
back.
Policy Control on the P-CSCF

P-CSCF
Home domains list

South.com
North.com
East.com
West.com
SIP: REGISTER (p-cscf@europe.com

FROM (user1@europe.com)
TO (user2@europe.com)
SIP: 403 Forbidden response
(If the domain europe.com is
forbidden
If no match
I-CSCF
SIP: REGISTER
Foreign domains list

Africa.com
Allowed
Asia.com
Forbidden
America.com
Forbidden
Europe.com
Allowed
Home Network: Europe.com
Figure 7 Policy Control on the P-CSCF

3.1.2 The Interrogating CSCF
The Interrogating CSCF (I-SCSF) is a SIP proxy located at the border of the home network,
and it is responsible for nding out the UEs registration status, and either assigning a new SCSCF or routing to the right existing S-CSCF. The address of the I-CSCF is listed in the DNS
records of the domain.
TK420
Page 14
The request may come from P-CSCF, from other multimedia networks, or from CS networks
through the Media Gateway Control Function (MGCF). Also I-CSCF may need to interact with
the ASs for service handling.
The Ma interface is used for this when Public Service Identity (PSI) is used to identify the
service, and the I-CSCF can route the request directly to the proper AS.
Besides the SIP proxy server functionality the I-CSCF has an interface to the SLF and the HSS.
This interface is based on the Diameter protocol. The I-CSCF retrieves user location
information and routes the SIP request to the appropriate destination.
Additionally, the I-CSCF may optionally encrypt the parts of the SIP messages that contain
sensitive information about the domain, such as the number of servers in the domain, their
DNS names, or their capacity. This functionality is called Topology Hiding Inter-network
Gateway (THIG). A network will include typically a number of I-CSCFs for the sake of
scalability and redundancy.
Interrogating-Call Session Control Function (I-CSCF)

AS
HSS
Statfull SIP proxy server.
First Contact Point in home network.
Performs S-CSCF and AS selection.
Performs network topology hiding (THIG).
Cx
Mw
P-CSCF
ISC,
Ma
Mw
I-CSCF
S-CSCF
Dx
SLF
Figure 8: Interrogating-CSCF.
TK420
Page 15
The I-CSCF is used the home network operator to control requests coming from other
operators, according to roaming agreement.
The check on the I-CSCF can be provided on a domain basis only, since there are no user
specific data available on the I-CSCF for roamers.
In the I-CSCF there is also a Visited Networks List, where the home operator specifies, from
which visited networks the users are allowed or forbidden to access their home network.
This procedure is done in three steps:
The I-CSCF determines whether the domain of the request URI is one of the domains
the I-CSCF is responsible for.
The I-CSCF has to check whether the value in the P-Visited-Network-Id header
matches to a value in the Home Network ID parameter.
If the I-CSCF checks the P-Visited-Network-Id against the preconfigured values of the
Visited Networks List. When the Visited Networks List has the forbidden flag, the ICSCF answer by the 403 Forbidden response.
TK420
Page 16
Policy Control on the I-CSCF

I-CSCF
Home Network ID
South.com
If no match
SIP: REGISTER (p-cscf@europe.com
FROM (user1@europe.com)
TO (user2@europe.com)
P-visited-NetworkID (South.com)
Visited domains list
SIP: 403 Forbidden response

(If the domain south.com is
forbidden
South.com
Allowed
North.com
Forbidden
East.com
Forbidden
West.com
Allowed
HSS
DIAMETER: UAR
Home Network: Europe.com
Figure 9 Policy Control on the I-CSCF

3.1.3 The Serving CSCF
The Serving CSCF (S-CSCF) locates in the users home network, and it will maintain the users
registration and session state. At registration, it interfaces with the HSS to receive the
subscription prole, including authentication information, and it will authenticate the UE.
For the service sessions, the S-CSCF signals with the UE through the other CSCFs, and may
also interact with the Application Servers (ASs) or the MRFCs for setting up the service
session properly. It also carries the main responsibility for controlling the Inter-working
Elements. The S-CSCF may also need to interact with MGCF for inter-working with CS
networks, or with other multimedia networks for UE requested services.
The S-CSCF is the central node of the IMS signaling plane. The S-CSCF is essentially a SIP
server that performs session control. In addition to statfull SIP server functionality the SCSCF also acts as a SIP registrar. This means that it maintains a binding between the user
location and the users SIP address of record. Like the I-CSCF the S-CSCF also implements a
Diameter interface to the HSS. The main reasons to interface the HSS are as follows:
TK420
Page 17
In order to authenticate the user trying to access the IMS, the S-CSCF downloads the
authentication vectors from the HSS.
Download the user prole from the HSS. The user prole includes the service prole,
which is a set of triggers that may cause a SIP message to be routed through one or
more application servers.
Inform the HSS that this is the S-CSCF allocated to the user for the duration of the
registration. All the SIP signaling messages the IMS terminals sends or receives,
traverses the allocated S-CSCF. The S-CSCF determines whether the SIP signaling
messages should visit one or more application servers en route toward the nal
destination.
One of the main functions of the S-CSCF is to provide SIP routing services. If the user dials a
telephone number instead of a SIP URI the S-CSCF provides translation services, typically
based on DNS E.164 Number Translation.
The S-CSCF also enforces the policy of the network operator. For example, a user may not be
authorized to establish certain types of sessions. The S-CSCF keeps users from performing
unauthorized operations.
A network usually includes a number of S-CSCFs for the sake of scalability and
redundancy. Each S-CSCF serves a number of IMS terminals, depending on the capacity of
the node.
TK420
Page 18
Serving-Call Session Control Function (S-CSCF)

The S-CSCF is the central node of the IMS cloud.
AS
HSS
MRFC
Statefull SIP proxy providing session control.

SIP registrar.
Performs subscriber authentication
Mr
Cx
Download user profile from HSS.
ISC
Allocated to IMS user during one registration.

Invokes the AS using Initial filter criteria.
BGCF
Mi
Mw
I-CSCF
Mj
S-CSCF
Mg
Dx
MGCF
SLF
Figure 10: Serving-CSCF
3.1.4 The Emergency CSCF

In addition to the above-mentioned three CSCF roles, a fourth role, the Emergency CSCF (ECSCF), has been dened. As the name indicates, the E-CSCF is dedicated to handling the
emergency call service in IMS. The E-CSCF connects to the P-CSCF via the Mw interface, and
these nodes must always be in the same network.
Interconnection between CSCFs in different operators networks may be routed through a
common point called the Interconnection Border Control Function (IBCF).
As soon the P-CSCF detects an emergency call situation, it tries to retrieve location
information from the CLF via the E2 interface. This information is used to modify the
received P-access-network-information (PANI) header. If there is no PANI header available,
the header is created by the P-CSCF.
The E-CSCF handles all emergency calls that the P-CSCF detects based on a pre-configured
list of emergency numbers. The E-CSCF serves sessions for registered and unregistered
TK420
Page 19
subscribers. For selecting a public safety answering point (PSAP), the E-CSCF interfaces a
location retrieval function (LRF) through the SIP- based Ml interface. The Ml interface is
based on the ISC interface. The E-CSCF can perform offline charging, which can, for example,
be used for inter-operator-inter-working charging/accounting and for statistical purposes.
Emergency-Call Session Control Function (E-CSCF)

Handles emergency calls
LRF
HSS
PSAP
Can be collocated with S-CSCF

Always exist in the same network as the P-CSCF
Retrieves user location from the LRF
Le
Cx
can perform offline charging
Ml
Selects the PSAP according to the user location
BGCF
Mi
Mw
P-CSCF
Mj
E-CSCF
Mg
Dx
MGCF
SLF
Figure 11: E-CSCF
TK420
Page 20
Emergency Call handling

P-CSCF
User Location?
User Location
Emergency
Numbers
911
112
110
197
SIP: INVITE
(TO:911)
LRF
E-CSCF
SIP: INVITE
(TO:911, PANI: User Location)
SIP: INVITE
MGCF
SIP: INVITE
User Location?
PSAP
User Location
CLF
Figure 12 Emergency Call handling
3.1.5 CSCF interfaces

As already seen in preview the CSCF provide the functionality of SIP proxies, SIP registrars
and SIP redirection servers. Hence CSCF control the sessions as well as user registrations.
Following interfaces are to be provided:
Interface
Gm
Description
This interface is between UE and P-CSCF. It
enables the exchange of SIP messages
between user agent (implemented in UE)
and the SIP server provided by the P-CSCF.
Mw
This interface is towards other CSCF and is

used for SIP signaling like between proxy-
TK420
Page 21
proxy or proxy-redirect, etc.

Mm
This interface is used if IMS shall inter-work

with SIP based multi-media networks other
than IMS.
Cx
It represents the interface between CSCF

and HSS. Usually only I-CSCF and S-CSCF use
it. The S-CSCF performs registration updates
via this interface, whereas the I-CSCF
interrogates the current P-CSCF address of a
user for mobile terminated sessions.
Mn
The Mn interface is towards IMS-MGW to

configure routing or switching functions,
allocate bandwidth, etc.
Mp
The Mp interface is used by the CSCF to

configure MRFP for codec conversion, multiparty session mixing functions, etc.
Rx
Rx allows for dynamic QoS-related service

information and dynamic charging-related
service
information
to
be
exchanged
between the Policy and Charging Rules

Function
(PCRF)
and
the
Application
Function (AF). This information is used by

the PCRF for the selection and completion of
charging rules.
Gx
This interface allows the Policy Charging

Rules Function (PCRF) to control the Flow
TK420
Page 22
Based Charging functionality and to apply

policy to the bearer usage in the GGSN by
means of providing the applicable policy and
charging rules.
To handle Mn and Mp interfaces the CSCF usually has MGCF and MRFC integrated. Hence
the interfaces CSCF-MGCF and CSCF-MRFC are usually not according to the standard. On Mn
and Mp the protocol MEGACO (Media Gateway Control) based on the ITU-T standard H.248
is to be used.
For finding the correct MGCF/MGW and MRFC/MRFP for a session the BGCF is used. Hence
it also is considered to be an integrated part together with CSCF.
For handling of the Cx interface towards HSS the SLF is needed. The SLF returns the HSS
address if the CSCF does not already know. The interface between CSCF and SLF is called Dx.
It has the same protocol appearance as Cx.
TK420
Page 23
MGCF
SLF
Mg
Dx
MRFC
BGCF
Mr
Mi
CSCF
Gm
Rx
UE
PCRF
Cx
Mw
CSCF
HSS
Figure 13: Main CSCF interfaces.
TK420
Page 24
3.2 Databases
3.2.1 The Home Subscriber Server
The HSS is the main database used by the IMS. The HSS contains the master copy of
subscription data, and it is used in much the same way as with the IP connectivity layer. It
provides the location and authentication information based on requests from the I- or SCSCF, or the AS. The interface between the HSS and the Services Elements will be either Sh
or Si depending on the type of services elements. The Sh interface is used in case of SIP o
OSA service capability server and the Si when CAMEL based AS is in question.
It is possible to find several HSSs in a home network. It depends on the number of
subscribers and the capacity of the equipments implemented.
The HSS holds the following IMS user related information: User Id, User Security information
(authentication and authorization), User Location, and User Profile.
Figure 14: HSS logical functionalities (extracted from ts23004)

TK420
Page 25
As invoked in the 3GPP standard, the HSS consists of the following functionalities:
- Call/session establishment support
The HSS supports the call and/or session establishment procedures in CS Domain, PS
Domain and IM CN subsystem. For terminating traffic, it provides information on which call
and/or session control entity currently hosts the user.
- User security information generation
-
The HSS generates user authentication, integrity and ciphering data for the CS and PS
Domains and for the IM CN subsystem. User security support

The HSS supports the authentication procedures to access CS Domain, PS Domain and IM
CN subsystem services by storing the generated data for authentication, integrity and
ciphering and by providing these data to the appropriate entity in the CN (i.e. MSC/VLR,
SGSN, MME, 3GPP AAA Server or CSCF).
- User identification handling
The HSS provides the appropriate relations among all the identifiers uniquely determining
the user in the system:
CS Domain, PS Domain and IM CN subsystem (e.g. IMSI and MSISDNs for CS Domain; IMSI,
MSISDNs and
IP addresses for PS Domain, private identity and public identities for IM CN subsystem).
- Access authorisation
The HSS authorises the user for mobile access when requested by the MSC/VLR, SGSN,
MME, 3GPP AAA Server or CSCF, by checking that the user is allowed to roam to that visited
network.
- Service authorisation support
The HSS provides basic authorisation for MT call/session establishment and service
invocation. Besides, the
TK420
Page 26
HSS updates the appropriate serving entities (i.e., MSC/VLR, SGSN, MME, 3GPP AAA Server,
CSCF) with the relevant information related to the services to be provided to the user.
- Service Provisioning Support
-
The HSS provides access to the service profile data for use within the CS Domain, PS
Domain and/or IM CN subsystem. Application Services and CAMEL Services Support (for
GERAN and UTRAN access).
The HSS communicates with the SIP Application Server and the OSA-SCS to support
Application Services in the IM CN subsystem. It communicates with the IM-SSF to support
the CAMEL Services related to the IM CN subsystem. It communicates with the gsmSCF to
support CAMEL Services in the CS Domain and GPRS PS Domain (for GERAN and UTRAN
access).
- GUP Data Repository
The HSS supports the storage of IM CN Subsystem user related data, and provides access
to these data through the Rp reference point.
3.2.2 Subscription Locator Function

When multiple and separately addressable HSSs have been deployed in the network,
the AS cannot know which HSS it needs to contact. However, the AS needs to contact the
SLF rst. For this purpose the Dh reference point was introduced in Release 6. In Release 5
the correct HSS is discovered by using proprietary means. The Dh reference point is always
used in conjunction with the Sh reference point. The protocol used in this reference point is
based on Diameter. Its functionality is implemented by means of the routing mechanism
provided by an enhanced Diameter re-direct agent.
The resolution mechanism is not required in networks that utilize a single HSS or when an
AS is configured to use pre-defined HSS. There are no additional Diameter messages or
procedures on the Dh regarding the Sh interface.
TK420
Page 27
The resolution mechanism either uses a Subscription Locator Function (SLF) or a

Diameter Proxy Agent providing the routing mechanism as a Diameter redirect agent, i.e.
the SLF or the Diameter Proxy Agent is used to determine the HSS identity.
SLF Usage
To get the HSS identity the AS sends the Sh request normally destined to the HSS to a preconfigured Diameter address/name.
If this Sh Request is received by an SLF (acting as a Diameter redirect agent), the SLF
determines the HSS address and sends to the AS a notification of redirection
containing the HSS identity, in response to the Sh request. Multiple HSS identities
may be included in the response. In such a case, the AS sends the Sh Request to the
first HSS identity in the ordered list received in the Sh Response from the SLF.
If the AS does not receive a successful response to the Sh Request, the AS shall send a Sh
Request to the next HSS identity in the ordered list. This procedure will be repeated until a
successful response from an HSS is received.
If this Sh Request is received by the Diameter Proxy Agent, the Diameter Proxy Agent
determines the HSS identity and forwards the Sh request directly to the HSS. The AS
shall determine the HSS identity from the response to the Sh request received from
the HSS.
The AS should store the HSS identity/name/Realm and shall use it in further Sh requests
associated to the same IMS Public Identity.
In networks where the use of the user identity to HSS resolution mechanism is required and
the AS is not configured to use a predefined HSS, each AS has to be configured with the preconfigured address/name of the SLF or the Diameter Proxy Agent to enable the use of these
resolution mechanisms.
TK420
Page 28
SLF
AS
HSS
Dh: REQUEST
(HSS realm/ HSS host name)
Dh: ANSWER
(result= REDIRECT_INDICATION,
HSS address)
Sh: REQUEST
Sh: ANSWER
Figure 15 SLF usage

Proxy DRA
AS
HSS
Dh: REQUEST
Dh: REQUEST
Sh: REQUEST
Sh: ANSWER
Figure 16 Proxy DRA usage
TK420
Page 29
3.3 Services Elements

The actual service logic is located in the Application Servers (AS). A variety of different
services may be provided with different ASs, and the standards do not aim to cover all
possible services.
Some of the main services are covered in order to facilitate easier inter-working with
operators in roaming, and to provide for consistent user experience. One example of a
standardized AS is the Telephony Application Server (TAS), which may be used to provide
the IMS VoIP service.
The media component of the service can be handled by the Multimedia Resource Function
(MRF), which is dened as a separate controller (MRFC) and processor (MRFP). The UP may
be routed through MRFP for playing announcements as well as for conferencing and
transcoding. For coordination purposes, the MRFC may also be connected to the related AS.
In a network there is generally more than one Application Server. Typically, there will be
several Application Servers, each one specialized in providing a particular service.. All of
these ASs are characterized by implementing a SIP interface toward the S-CSCF. For
historical reasons the interface dened between the S-CSCF and the AS is known as the IMS
Service Control (ISC) interface.
Application Server can be located in the home network or in a third-party service provider
network. But it is up to the S-CSCF to decide whether to involve an AS in the session setup
or not.
For instance, an AS may carry out the same task as a call-forwarding service. The user may
log onto the web page of the AS to congure the SIP URI where all the sessions will be
forwarded. The graphical user interface provided by a web page is an improvement to the
end-users experience when conguring services, compared with the current mechanism of
conguring services in circuit-switched networks.
3GPP Release 6 adds yet another optional standardized interface toward an Application
Server. This interface is code-named Ut and is used to provide the user with a protocol to
TK420
Page 30
congure and manage groups, policies, etc. So, this is not an interface used for live trafc.
The protocol on the Ut interface is based on the XML Conguration Access Protocol (XCAP).
Application server
each one specialized in providing a particular
service.
All ASs are characterized by implementing a
SIP interface toward the S-CSCF
Application Server can be located in the home
network or in a third-party service provider
network
3GPP Release 6 adds Ut interface between
the AS and the IMS user.
Figure 17: Application Server.
3.3.1 SIP-AS
The SIP Application Server is the native AS in the IMS. New services exclusively developed
for the IMS are likely to be executed by SIP ASs.
When a SIP AS is located in the home network, it can optionally implement an interface to
the HSS. The implementation of the interface depends on whether the actual service logic
needs to further interact with the HSS or not. The optional interface from the AS to the HSS
is code-named Sh. This interface is based on Diameter.
We already mentioned that SIP ASs can be located in the home network or in a third-party
service provider network. If the SIP AS is located in a third-party service provider network, it
cannot implement the Sh interface in the HSS.
TK420
Page 31
3.3.2 OSA-SCS
The Open Service AccessService Capability Server (OSA-SCS) provides the gateway
functionality to execute OSA services in the IMS. There is an existing base of services
implemented in the OSA framework AS. So, in order to provide access to those services from
the IMS a gateway is needed. This gateway is the OSA-SCS.
The OSA-SCS provides an interface, external to the IMS, toward the OSA framework AS. The
OSA-SCS AS also provides the ISC interface toward the S-CSCF based on SIP and may use the
optional Sh interface toward the HSS.
From the S-CSCF, the OSA-SCS appears and behaves as a SIP AS. The S-CSCF cannot
differentiate an OSA-SCS from a SIP AS.
3.3.3 IM-SSF Application server

The third type of Application Server is the IP Multimedia Service Switching Function (IMSSF). This AS provides a gateway to legacy service networks that implement CAMEL
(Customized Applications for Mobile network Enhanced Logic) services, which are widely
deployed in GSM networks.
The IM-SSF acts as a gateway between SIP and CAMEL
services, thus allowing CAMEL services to be invoked from the IMS.

On the IMS side the IM-SSF interfaces the S-CSCF via the ISC interface, with SIP as the
protocol. The IM SSF also interfaces the HSS with an interface code-named Si. The protocol
on the Si interface is MAP (Mobile Application Part).
Outside the IMS the IM-SSF interfaces the gsmSCF (GSM Service Control Function), which is
part of the Camel Service Environment (CSE). The protocol on this interface is CAP (CAMEL
Application Part), a non-IMS protocol.
The IM-SSF is located in the home network.
From the perspective of the S-CSCF, the IM-SSF appears and behaves as a SIP AS. The S-CSCF
cannot differentiate an IM-SSF from a SIP AS.
TK420
Page 32
gsmSCF
OSA-AS
SIP-AS
OSA-SCS
SIP-AS
S-CSCF
IM-SSF
HSS
Figure 18: AS types.
3.3.4 Initial Filter criteria

Filter criteria are among the most important pieces of user information stored in the
network, because they determine the services that will be provided to each user. Filter
criteria contain a collection of user-related information that helps the S-CSCF to decide
when to involve a particular Application Server to provide the service.
Initial lter criteria are supposed to be evaluated with those SIP initial requests that either
create a dialog or are stand-alone requests. For instance, the S-CSCF evaluates initial lter
criteria when it receives a rst SUBSCRIBE request, INVITE, OPTIONS, or any such requests
that either create a dialog or are sent outside any dialog. The S-CSCF does not evaluate
initial lter criteria when it receives a PRACK, NOTIFY, UPDATE, or BYE request, since they
are always sent as part of an existing SIP dialog.
TK420
Page 33
Initial Filter Criteria

Filter criteria are among the most important pieces
of user information stored in the network.
They determine the services that will be provided to
each user.
Helps the S-CSCF to decide when to involve a
particular Application Server to provide the service.
The S-CSCF evaluates initial lter criteria when it
receives a rst SUBSCRIBE request, INVITE,
OPTIONS .
Figure 19: Initial Filter Criteria.
The HSS stores all the data related to a user in a data structure named the user prole.
Figure 18 shows a high-level simplied structure of the user prole. We mention that the
user prole contains the Private User Identity to which the user prole is applicable and one
or more service proles. Each service prole contains one or more Public User Identities to
which the service prole is applicable and zero or more lter criteria.
TK420
Page 34
User Profile
Private User Identity
Service Profile n
Service Profile 1
Public IDs
Figure 20: User Profile.
When the user registers with the S-CSCF, the S-CSCF contacts the HSS and downloads the
user prole that includes the lter criteria. So, lter criteria are available in the S-CSCF at the
moment the user registers.
Filter criteria determine the services that are applicable to the collection of Public User
Identities listed in the Service prole. Filter criteria are further structured as presented in
Figure 19.
The rst eld in the lter criteria structure is the Priority. The Priority eld determines the
order in which these lter criteria will be assessed, compared with the remaining lter
criteria that are part of the same service prole. The S-CSCF will rst choose lter criteria
that have higher priority. After evaluating it, the S-CSCF continues with the lter criteria of
the next Priority number. The Priority eld of lter criteria is a unique number with respect
to all the lter criteria that belong to the same service prole. In any case, numbers do not
need to be consecutive.
After the Priority eld, there can be zero or one Trigger Points. A Trigger Point is an
expression that needs to be evaluated in order to determine whether or not the SIP request
TK420
Page 35
will be forwarded to a particular AS. A trigger point is a collection of individual lters called
Service Point Triggers.
The Service Point Trigger allows us to access the information stored in different elds of the
SIP request:
The value of Request-URI.
The method of the SIP request (e.g., INVITE, OPTIONS, SUBSCRIBE, etc.).
The presence or absence of any SIP header.
A partial or full match between the contents of any SIP header.
The session case: whether the SIP request is originated by the served user,
addressed to the served registered user, or addressed to the served unregistered
user.
The session description.
If there is no Trigger Point, then any SIP request is unconditionally forwarded to the AS.
After the Trigger Points, which include one or more Service Point Triggers, the initial lter
criteria contains the AS SIP URI. This is the address of the AS that will receive the SIP request
if the conditions described in the Trigger Points are met. There is a Default Handling eld
that indicates the action to be taken if the S-CSCF cannot contact, for whatever reason, that
AS. The possible actions are to continue processing the SIP request or to abort the process.
The Service Information eld contains some transparent data (transparent to the HSS and SCSCF) that the AS may need to process the request. The use of this eld is restricted to SIP
REGISTER requests or any other request where the S-CSCF is acting as a SIP User Agent
Client. The reason is that these data are appended in a body to the SIP request. This action is
not allowed in SIP proxies. Therefore, the only possibility of using this information is when
the S-CSCF, due to initial lter criteria triggering, acting as a SIP User Agent Client generates
a third-party SIP REGISTER request to the AS. Such a REGISTER request can contain the
Service Information, whose purpose is to transfer the IMSI to the IM-SSF of the subscriber,
so that the IMSI can be used by the IM-SSF.
TK420
Page 36
Lastly, the user prole is encoded using the Extensible Markup Language (XML). An XML
schema dening initial lter criteria is specied by 3GPP. Initial lter criteria are transported
from the HSS to the S-CSCF over Diameter messages.

Priority
Trigger Point
Trigger Point
Service Trigger Point
Service Trigger Point
Request URI
SIP method
SIP Header
Session Case
Session Description
Application Server
SIP URI
Default Handling
Service Information
Figure 21: Initial Filter Criteria
TK420
Page 37
3.4 Inter-working Elements

The Inter-working Elements are needed when the IMS interoperates with other networks,
such as other IMS networks, or CS networks. The following are the main functions of the
standardized inter-working elements:
3.4.1 The Breakout Gateway Control Function
The Breakout Gateway Control Function (BGCF) is used when inter-working with CS
networks is needed, and it is responsible for selecting where the interconnection will take
place.
It may select the Media Gateway Control Function (MGCF) if the breakout is to happen in
the same network, or it may forward the request to another BGCF in another network. This
interaction may be routed through the Interconnection Border Control Function (IBCF).
3.4.2 The Interconnection Border Control Function
The Interconnection Border Control Function (IBCF) is used when interconnection between
operators is desired to be routed through de ned points, which hide the topology inside
the network. The IBCF may be used in interconnection between CSCFs or BGCFs and it is in
control of Transition Gateway (TrGW), which is used for the same function in the UP.
Note that the IBCFTrGW interface is not fully specied in Release 8. The IBCFs and the
TrGWs in different operators networks may be interconnected to each other via the Ici and
Izi interfaces respectively, and together they comprise the Inter IMS Network to Network
Interface (II-NNI).
3.4.3 The Media Gateway Control Function
The Media Gateway Control Function (MGCF) and IMS-Media Gateway (IMS-MGW) are the
CP and UP nodes for inter-working with the CS networks such as the legacy 3GPP networks
with CS domain for GERAN or UTRAN, or for PSTN/ISDN. Both incoming and outgoing IMS
TK420
Page 38
VoIP calls are supported with the required signalling inter-working and transcoding between
different voice coding schemes. The MGCF works in the control of either the CSCF or BGCF.
TK420
Page 39
4 IMS specific identifiers

In a network of any kind, it must be possible to uniquely identify users. This is the property
that allows a particular phone to ring when we dial a sequence of digits in the PSTN.
Central to any network is the ability of the operator to identify users, so that calls can be
directed to the appropriate user. In the PSTN, users are identied by a telephone number.
Additionally, when a service is provided, sometimes there is a need to identify the service. In
the PSTN services are identied by special numbers, typically through a special prex. IMS
also provides mechanisms to identify services.
4.1 Public user identities

In the IMS there is also a deterministic way to identify users. An IMS user is allocated with
one or more Public User Identities (IMPU). The home operator is responsible for allocating
these Public User Identities to each IMS subscriber. In the IMS, Public User Identities are
used to route SIP signaling. So we can compare the IMPU to the MSISDN.
There are reasons for allocating more than one Public User Identity to a user, such as having
the ability to differentiate personal identities that are known to friends and family from
business Public User Identities, or for triggering a different set of services.
The IMS brings an interesting concept: a set of implicitly registered public user identities. In
regular SIP operation, each identity that needs to be registered requires a SIP REGISTER
request. In the IMS, it is possible to register several IMPU in one message in order to save
time and bandwidth.
An IMPU can be a SIP URI, a SIPS URI or a TEL URI.
4.1.1 SIP URI
When the Public User Identity contains a SIP URI, it typically takes the form of sip:
sip:username@hostname, although IMS operators are able to change this scheme and
TK420
Page 40
address their own needs. SIP URI always begins with the indication sip:, whereas SIPS URI
begins with sips:
Additionally, it is possible to include a telephone number in a SIP URI using the following
format:
sip:+21612345678@operator.com;user=phone
This format is needed because SIP requires that the URI under registration be a SIP URI. So, it
is not possible to register a TEL URI in SIP, although it is possible to register a SIP URI that
contains a telephone number.
4.1.2 TEL URI
The TEL URI is the other format that an IMPU can take. The telephone URI scheme, tel, can
be used to represent a resource identified by a telephone number. Telephone numbers can
be of two general forms, local or global. A local number is only valid in a particular
geographic area and has only local significance. If the number is used outside of this area, it
will either fail or return the wrong resource. A global telephone number, also called an
E.164 number, is one that is, in principle, valid anywhere. It contains enough information
about the country, region, and locality so that the PSTN network is capable of routing calls
to the correct resource. An example of a local phone number is:
tel:411;phone-context=+1314
Which indicates a call to directory assistance valid only within country code 1 and area code
314 as identified in the required phone-context parameter. An example of a global phone
number is:
tel:+13145551212
Global phone numbers always begin with the + identifier followed by the country code, 1
in this case, followed by the remaining telephone digits.
A tel URL can also contain some characters and information about dialing strings and
patterns. For example:
TK420
Page 41
tel:#70555-1212;isub=1000
In this example, the dialed digit string, interpreted by a PSTN gateway, would be the DTMF
digit # then 70 (to cancel call waiting, for example), then the digits 5551212. Additional
parameters include an ISDN subaddress of 1000. This example shows both types of optional
visual separators allowed, either -or . as the separator.
TEL URIs are needed to make a call from an IMS terminal to a PSTN phone, because PSTN
numbers are represented only by digits. On the other hand, TEL URIs are also needed if a
PSTN subscriber wants to make a call to an IMS user, because a PSTN user can only dial
digits.
4.2 Private User Identity

Each IMS subscriber is assigned a Private User Identity. Unlike Public User Identities, Private
User Identities are not SIP URIs or TEL URIs; instead, they take the format of a NAI (Network
Access Identier). The format of a NAI is username@operator.com.
Unlike Public User Identities, Private User Identities are not used for routing SIP requests.
They are exclusively used for subscription identication and authentication purposes.
A Private User Identity performs a similar function in the IMS as an IMSI does in GSM. A
Private User Identity need not be known by the user, because it might be stored in a smart
card, in the same way that an IMSI is stored in a SIM (Subscriber Identity Module).
4.3 Relation between Private and public User identity

Operators assign one or more Public User Identities and one or more Private User Identity to
each user.
In the case of GSM/UMTS/LTE, the smart card stores the Private User Identity and at least
one Public User Identity. The HSS, as a general database for all the data related to a
subscriber, stores the Private User Identity and the collection of Public User Identities
TK420
Page 42
allocated to the user. The HSS and the S-CSCF also correlate the Public and Private User
Identities.
The relation between an IMS subscriber, the Private User Identity and the Public User
Identities is shown in Figure 25. An IMS subscriber is assigned one Private User Identity and
a number of Public User Identities. This is the case of the IMS as standardized in 3GPP
Release 5.
Public User
Identity 1
IMS
Subscriber
Private User
Identity
Public User
Identity 2
Public User
Identity n
Figure 22: Relation between different user identities Release 5.
3GPP Release 6 has extended the relationship of Private and Public User Identities, as shown
in Figure 26. An IMS subscriber is allocated not with one, but with a number of Private User
Identities. In the case of UMTS, only one Private User Identity is stored in the smart card,
but users may have different smart cards that they insert in different IMS terminals. It might
be possible that some of those Public User Identities are used in combination with more
than a single Private User Identity.
TK420
Page 43
Public User
Identity 1
Private User
Identity 1
Public User
Identity 2
IMS
Subscriber
Private User
Identity 2
Public User
Identity 3
Public User
Identity n
Figure 23: relation between different user identities release 6.
A single subscription may have one or several Private User Identities, several Public User
Identities, several service profiles and several implicit registration sets.
When a user has a set of Public User Identities defined to be implicitly registered via single
IMS registration of one of the Public User Identity's in that set, it is considered to be an
Implicit Registration. No single public identity shall be considered as a master to the other
Public User Identities.
HSS stores the set of Public User Identities that are part of implicit registration. All Public
User Identities of an Implicit Registration set must be associated to the same Private User
Identities.
When one of the Public User Identities within the set is registered, all Public user identities
associated with the implicit registration set are registered at the same time.
TK420
Page 44
When one of the Public User Identities within the set is de-registered, all Public User
Identities that have been implicitly registered are de-registered at the same time.
Public user identities belonging to an implicit registration set may point to different service
profiles; or some of these Public User Identities may point to the same service profile.
When a Public User Identity belongs to an implicit registration set, it cannot be registered or
de-registered individually without the Public User Identity being removed from the implicit
registration list.
All IMS related registration timers should apply to the set of implicitly registered Public User
Identities S-CSCF, P-CSCF and UE shall be notified of the set of Public User Identities
belonging to the implicitly registered function. Session set up shall not be allowed for the
implicitly registered Public User Identities until the entities are updated, except for the
explicitly registered Public User Identity.
The S-CSCF shall store during registration all the Service profiles corresponding to the Public
User Identities being registered.
TK420
Page 45
Implicit Registration
Public User
Identity 1
Private User
Identity 1
Public User
Identity 2
IMS
Subscriber
Private User
Identity 2
Public User
Identity 3
Public User
Identity n
Figure 24: Implicit registration
4.4 Public Service Identity

The concept of Public Service Identities (PSIs) is introduced in Release 6 of the 3GPP
specications. Unlike Public User Identities, which are allocated to users, a PSI is an identity
allocated to a service hosted in an Application Server. For instance, an Application Server
hosting a chat room is identied by a PSI. Like Public User Identities, PSIs may take the
format of a SIP URI or a TEL URI.
Unlike Public User Identities, PSIs do not have an associated Private User Identity. This is
because the Private User Identity is used for user authentication purposes. PSIs are not
applicable to users.
TK420
Page 46
4.5 ISIM
A third application that may be present in the UICC is ISIM. ISIM is of a special importance
for the IMS, because it contains the collection of parameters that are used for user
identication, user authentication, and terminal conguration when the terminal operates in
the IMS. ISIM can co-exist with a SIM, a USIM, or both applications in the same UICC.
The relevant parameters stored in ISIM are as follows
Private User Identity: ISIM stores the Private User Identity allocated to the user.
There can only be one Private User Identity stored in ISIM.
Public User Identity: ISIM stores one or more SIP URIs of Public User Identities
allocated to the user.
Home Network Domain URI: ISIM stores the SIP URI that contains the home network
domain name. This is used to nd the address of the home network during the
registration procedure. There can only be one home network domain name URI
stored in ISIM.
Long-term secret: ISIM stores a long-term secret that is used for authentication
purposes and for calculating the integrity and cipher keys used between the terminal
and the network. The IMS terminal uses the integrity key to integrity-protect the SIP
signaling that the IMS terminal sends to or receives from the P-CSCF. If the signaling
is ciphered, the IMS terminal uses the cipher key to encrypt and decrypt the SIP
signaling that the IMS terminal sends to or receives from the P-CSCF.
All of the above-mentioned elds are read-only, meaning that the user cannot modify the
values of the parameters. From the description of the elds contained in ISIM we realize that
ISIM is important for authenticating users.
TK420
Page 47
Access to a 3GPP IMS network relies on the presence of either an ISIM or a USIM application
in the UICC. ISIM is preferred because it is tailored to the IMS, although access with USIM is
also possible. This allows operation in an IMS network of users who have not upgraded their
UICCs to IMS-specic ones that contain an ISIM application.
Due to the lower degree of security contained in a SIM application, access to a 3GPP IMS
network with a SIM application is not allowed. Non-3GPP IMS networks that do not support
UICC in the IMS terminals store the parameters contained in the ISIM as part of the
terminals conguration or in the terminals built-in memory.
3GPP2 IMS networks also allow the above-mentioned parameters to be stored in an R-UIM
(Removable User Identity Module). The R-UIM is a smart card secure storage, equivalent to a
3GPP UICC with an ISIM application.
Universal Integrated Circuit Card

2G SIM
IMSI
SMS
Data
ISIM
MSISDN
Address
Book
UMTS SIM (USIM)

Multimedia
messaging
config data
MSISDN
Auth Data
and keys
IMSI
Security Keys
Home Network Domain
Name URI
Administrative Data
Private User Identity (s)
P-CSCF Address
Access Rule Reference
Private User Identity (s)
Figure 25: ISIM.
TK420
Page 48
IMS Signaling flows
Before an IMS terminal starts any IMS-related operation there are a number of prerequisites
that have to be met.
First, the IMS service provider has to authorize the end-user to use the IMS service. This
typically requires a subscription or contract signed between the IMS network operator and
the user. This contract is similar to the subscription that authorizes an end-user to receive
and establish telephone calls over a wireless network.
Second, the IMS terminal needs to get access to an IP-CAN (IP Connectivity Access Network)
such as GPRS (in GSM/UMTS networks), ADSL (Asymmetric Digital Subscriber Line), or WLAN
(Wireless Local Access Network). IP-CAN provides access to the IMS home network or to an
IMS visited network. As part of this prerequisite the IMS terminal needs to acquire an IP
address.
When these two prerequisites are fullled the IMS terminal needs to discover the IP address
of the P-CSCF that will be acting as an outbound/inbound SIP proxy server. All SIP signaling
messages sent by the IMS terminal goes through P-CSCF. When the P-CSCF discovery
procedure is completed the IMS terminal is able to send and receive SIP signaling to or from
the P-CSCF. The P-CSCF is allocated permanently for the duration of IMS registration, a
procedure that is typically triggered when the IMS terminal is switched on or off.
TK420
Page 49
IMS
Terminal
IP-CAN
IMS
Network
1. Establishment of an IMS Service Contract
2. Getting IP connectivity
access
3.P-CSCF dicovery
4. IMS level registration
Figure 26: Basic steps to get IMS services.
5.1 P-CSCF Discovery

P-CSCF discovery is the procedure by which an IMS terminal obtains the IP address of a PCSCF. This is the P-CSCF that acts as an outbound/inbound SIP proxy server toward the IMS
terminal. This means that all the SIP signaling messages sent to or from the IMS terminal
traverses the P-CSCF.
P-CSCF discovery may take place in different ways:
integrated into the procedure that gives access to the IP-CAN;
as a stand-alone procedure.
The integrated version of P-CSCF discovery depends on the type of IP Connectivity Access
Network. If IP-CAN is a GPRS network, once the GPRS attach procedures are complete the
terminal is authorized to use the GPRS network. Then, the IMS terminal does a so-called
Activate PDP Context Procedure. The main goal of the procedure is to congure the IMS
TK420
Page 50
terminal with an IP address, but in this case the IMS terminal also discovers the IP address of
the P-CSCF to which to send SIP requests.
The stand-alone version of the P-CSCF discovery procedure is based on the use of DHCP (or
DHCPv6, for IPv6) and DNS (Domain Name System).
In DHCPv6 the terminal does not need to know the address of the DHCP server, because it
can send its DHCP messages to a reserved multicast address. If DHCP is used (for IPv4), the
terminal broadcasts a discover message on its local physical subnet. In some congurations a
DHCP relay may be required to relay DHCP messages to an appropriate network, although
the presence of the DHCP relay is transparent to the terminal.
Another way to provide the address of the P-CSCF relies in some means of conguration.
This can be, for example, an SMS sent to the terminal for the purpose of conguration.
Eventually, the IMS terminal discovers the IP address of its P-CSCF and can send SIP
signaling to its allocated P-CSCF. The P-CSCF takes care of forwarding the SIP signalling to
the IMS cloud. The P-CSCF allocated to the IMS terminal does not change until the next PCSCF discovery procedure. This procedure typically takes place when the terminal is
switched on or during severe error conditions. The important aspect to highlight is that the
IMS terminal does not need to worry about possible changes of address of the P-CSCF,
because its address is not variable.
TK420
Page 51
P-CSCF discovery
IMS terminal obtains the IP address of a PCSCF.
This procedure can be:
* integrated into the procedure that gives
access to the IP-CAN
* as stand alone procedure: DHCP, DNS.
Figure 27: P-CSCF Discovery.
IMS Terminal
DHCP
Server
IP-CAN
DNS
Server
1.IP-CAN Bearer
establishement
2.DHCP Query/
Response
3.DHCP Relay
4.DNS Query/ Response
Figure 28: P-CSCF discovery using DHCP and DNS.

TK420
Page 52
In LTE P-CSCF discovery procedure can be done using one of the following mechanisms:
After the IP-Connectivity access establishment by using DHCP to provide the UE with
the domain name and/or IP address of a Proxy-CSCF and the address of a Domain
Name Server (DNS) that is capable of resolving the Proxy-CSCF name.
As part of the IP-Connectivity access establishment towards the Network. NAS

signalling can be used to request and provide the address of the P-CSCF. The UE shall
indicate the request for a P-CSCF address to the network within the Protocol
Configuration Options information element of the PDN CONNECTIVITY REQUEST
message or BEARER RESOURCE ALLOCATION REQUEST message. If the network
provides the UE with a list of P-CSCF IPv4 or IPv6 addresses in the ACTIVATE
DEFAULT EPS BEARER CONTEXT REQUEST message or ACTIVATE DEDICATED EPS
BEARER CONTEXT REQUEST message, the UE shall assume that the list is prioritised
with the first address within the Protocol Configuration Options information element
as the P-CSCF address with the highest priority.
Pre-configuration of the UE. We can put in the ISIM the FQDN of the P-CSCF or its IP
address. If the domain name is known, DNS resolution is used to obtain the IP
address.
TK420
The UE selects a P-CSCF from the list in IMS management object.
Page 53
UE
SGW
MME
Initial attach
Request
Create Session
Request
Initial attach
Response
Create Session
Response
PGW
DHCP
DNS
Create Session
Request
Create Session
Response
Primary EPS Bearer

DHCP Discover
DHCP Offer
DHCP Request
DHCP ACK
Query( QTYPE=NAPTR, QNAME=P-CSCF service from DHCP)
Response( SRV Records = transport layer and service layer pointer
Query( QTYPE=SRV, QNAME=P-CSCF name from SRV record)
Response( SRV Resource Records = Server name, port, Opt address)
Query( QTYPE=AAAA, QNAME= Selected P-CSCF Name)
Response( IP address)
Figure 29: LTE P-CSCF Discovery with DHCP and DNS servers.
MME
UE
Initial attach
Request
SGW
Create Session
Request
PGW
Create Session
Request
P-CSCF
address
retrieval
Initial attach
Response
Create Session
Response
Create Session
Response
Figure 30: LTE P-CSCF discovery.

TK420
Page 54
5.2 IMS level Registration

Once the IMS terminal has followed the procedures of getting access to an IP Connectivity
Access Network, has acquired an IP address and has discovered the IP address of its P-CSCF,
the IMS terminal can begin IMS level registration procedure.
IMS-level registration is the procedure where the IMS user requests authorization to use the
IMS services in the IMS network. The IMS network authenticates and authorizes the user to
access the IMS network.
IMS-level registration is accomplished by a SIP REGISTER request. The SIP registration is the
procedure whereby a user binds his public URI to a URI that contains the host name or IP
address of the terminal where the user is logged in. The registration of the IMS user is
mandatory before the IMS terminal can establish a session.
The IMS registration procedure uses a SIP REGISTER request. However, this procedure is
heavily overloaded in the IMS, for the sake of fullling the 3GPP requirement of a minimum
number of round trips. The goal is achieved and the procedure completes after two round
trips.
TK420
Page 55
IMS
Terminal
P-CSCF
I-CSCF
HSS
S-CSCF
1. Register
2. Register
3. UAR
4. UAA
5. Register
6. MAR
7. MAA
8. 401 Unauthorized
10. 401
Unauthorized
9. 401
Unauthorized
Figure 31: IMS level registration phase 1

IMS
Terminal
P-CSCF
I-CSCF
HSS
S-CSCF
11. Register
12. Register
13. UAR
14. UAA
15. Register
16. SAR
17. SAA
18. 200 OK
19. 200 OK
20. 200 OK
Figure 32: IMS level registration phase 2
TK420
Page 56
The registration procedure is quite similar, independently of the presence of an ISIM or

USIM, there are certainly detailed differences.
The IMS registration procedure satises the following requirements in two round trips:
The user binds a Public User Identity to a contact address this is the main purpose
of a SIP REGISTER request;
The home network authenticates the user;
The user authenticates the home network;
The home network authorizes the SIP registration and the usage of IMS resources;
In case the P-CSCF is located in a visited network, the home network veries that
there is an existing roaming agreement between the home and the visited network
and authorizes the usage of the P-CSCF;
The home network informs the user about other possible identities that the home
network operator has allocated exclusively to that user;
The IMS terminal and the P-CSCF negotiates the security mechanism that will be in
place for subsequent signaling;
The P-CSCF and the IMS terminal establish a set of security associations that protect
the integrity of SIP messages sent between the P-CSCF and the terminal;
Both the IMS terminal and the P-CSCF upload to each other the algorithms used for
compression of SIP messages.
TK420
Page 57
IMS registration
The home network authenticates the user.

The user authenticates the home network.
The home network authorizes the SIP registration and the usage of IMS
resources;
In case the P-CSCF is located in a visited network, the home network
veries that there is an existing roaming agreement between the home
and the visited network.
The IMS terminal and the P-CSCF negotiates the security mechanism that
will be in place for subsequent signaling;
The P-CSCF and the IMS terminal establish a set of security associations
that protect the integrity of SIP messages sent between the P-CSCF and
the terminal;
The IMS terminal and the P-CSCF upload to each other the algorithms
used for compression of SIP messages.
Figure 33: IMS Registration.
Before creating the initial SIP REGISTER request, the IMS terminal retrieves from ISIM the
Private User Identity, a Public User Identity, and the home network domain URI. Then, the
IMS terminal creates a SIP REGISTER request and includes the following four parameters.
The registration URI: this is the SIP URI that identies the home network domain
used to address the SIP REGISTER request. This is a URI that typically points to the home
network, but it could be any subdomain of the home network. The registration URI is
included in the Request-URI of the REGISTER request.
The Public User Identity: this is a SIP URI that represents the user ID under
registration. In SIP, it is known as the SIP Address-of-Record. It is included in the To header
eld value of the REGISTER request.
The Private User Identity: this is an identity that is used for authentication purposes
only, not for routing. It is equivalent to what in GSM is known as IMSI (International Mobile
Subscriber Identity); it is never displayed to the user. It is included in the username
parameter of the Authorization header eld value included in the SIP REGISTER request.
TK420
Page 58
The Contact address: this is a SIP URI that includes the IP address of the IMS
terminal or the host name where the user is reachable. It is included in the SIP Contact
header eld value of the REGISTER request.
IMS Registration
P-CSCF may be either located in a visited or a home
network.
That I-CSCF is located at the entrance to the home
network
The P-CSCF inserts a P-Visited-Network-ID that
contains an identier of the network where the PCSCF is located.
The I-CSCF does not keep a registration state
Figure 34: IMS registration 2.
It must be noted that the P-CSCF may be either located in a visited or a home network. So,
in general, the P-CSCF may not be located in the same network as the home network and
needs to locate an entry point into the home network by executing a DNS procedure. These
procedures provide the P-CSCF with the SIP URI of an I-CSCF. That I-CSCF is located at the
entrance to the home network. The P-CSCF inserts a P-Visited-Network-ID that contains an
identier of the network where the P-CSCF is located. The home network requires this
header eld to validate the existence of a roaming agreement between the home and
visited networks. The P-CSCF also inserts a Path header eld with its own SIP URI to request
the home network to forward all SIP requests through this P-CSCF. Eventually, the P-CSCF
forwards the SIP REGISTER request to an I-CSCF in the home network.
TK420
Page 59
The I-CSCF does not keep a registration state, mainly because it is typically congured in
DNS to be serving a load-balancing function. When a SIP proxy needs to contact a SIP proxy
located in another network, it gets a different IP address of an I-CSCF, because of the DNS
load-balancing mechanisms. As a consequence, I-CSCFs do not keep any state associated to
registration. In particular, I-CSCFs are not aware of whether an S-CSCF is allocated to the
user and what the address of such an S-CSCF would be.
In order to carry out a rst-step authorization and to discover whether there is an S-CSCF
already allocated to the user, the I-CSCF sends a Diameter User-Authentication-Request
(UAR) to the HSS. The I-CSCF transfers to the HSS the Public and Private User Identities and
the visited network identier that are extracted from the SIP REGISTER request. The HSS
authorizes the user to roam the visited network and validates that the Private User Identity
is allocated to the Public User Identity under registration. The HSS answers with a Diameter
User-Authentication-Answer (UAA).
The HSS also includes the SIP URI of a previously allocated S-CSCF in the Diameter UAA
message, if there was an S-CSCF already allocated to the user. But if this was the rst
registration there will most likely not be an S-CSCF allocated to the user. Instead, the HSS
returns a set of S-CSCF capabilities that are the input for the I-CSCF when selecting the SCSCF.
Lets assume for the time being that the user switches his IMS terminal on and the S-CSCF is
unallocated as yet. The I-CSCF needs to perform an S-CSCF selection procedure based on the
S-CSCF capabilities that the HSS returned in the Diameter UAA message.
These capabilities are divided into mandatory capabilities, or capabilities that the chosen SCSCF has to fulll, and optional capabilities, or capabilities that the chosen S-CSCF may or
may not fulll. The standard does not indicate what these capabilities are and how they are
specied. Instead, capabilities are represented by an integer and have semantics only in a
particular home network. Because the Diameter interface standardized between the I-CSCF
and the HSS is an intra-operator interface, mapping the capabilities to the semantics is a
matter of operator conguration.
TK420
Page 60
S-CSCF selection is based on the capabilities received from the HSS in the Diameter UAA.
The I-CSCF has a congurable table of S-CSCFs operating in the home network and the
capabilities supported by each one. This allows the I-CSCF to choose an appropriate S-CSCF
for this particular user. Then, the I-CSCF continues with the process by proxying the SIP
REGISTER request to the chosen S-CSCF.
IMS Registration
The HSS returns a set of S-CSCF capabilities that are the input
for the I-CSCF when selecting the S-CSCF.
Mapping the capabilities to the semantics is a matter of
operator conguration.
S-CSCF receives the REGISTER request and authenticates the
user
S-CSCF needs to save the S-CSCF URI in the HSS
the S-CSCF contact the HSS to indicate that the user is now
registered and to download the user prole.
The HSS indicates to the S-CSCF which are the Public User
Identities are automatically registered in the S-CSCF in a set of
implicitly registered Public User Identities.
Figure 35: IMS Registration 3.
The S-CSCF receives the REGISTER request and authenticates the user. Initial registrations
are always authenticated in the IMS. Other registrations may or may not be authenticated,
depending on a number of security issues.
Only REGISTER requests are authenticated in the IMS. Other SIP requests, such as INVITE,
are never authenticated by the IMS.
The S-CSCF then contacts the HSS for a double purpose: on the one hand, the S-CSCF needs
to download authentication data to perform authentication for this particular user. On the
other hand, the S-CSCF needs to save the S-CSCF URI in the HSS, so that any further query to
the HSS for the same user will return routing information pointing to this S-CSCF.
TK420
Page 61
For this purpose the S-CSCF creates a Diameter Multimedia-Auth-Request (MAR) message.
The HSS stores the S-CSCF URI in the user data and answers in a Diameter Multimedia-AuthAnswer (MAA) message. In 3GPP IMS, users are authenticated by the S-CSCF with data
provided by the HSS. These authentication data are known as authentication vectors. The
HSS includes one or more authentication vectors in the Diameter MAA message, so that the
S-CSCF can properly authenticate the user.
Then, the S-CSCF creates a SIP 401 (Unauthorized) response. This response includes a
challenge in the WWW-Authenticate header eld that the IMS terminal should answer. The
SIP 401 (Unauthorized) response is forwarded, according to regular SIP procedures, via the
I-CSCF and P-CSCF.
When the IMS terminal receives the SIP 401 (Unauthorized) response, it realizes that there
is a challenge included and produces an appropriate response to that challenge. The
response to the challenge is included in a new SIP REGISTER request. The actual contents of
the credentials depend on the IMS network. If we are dealing with a 3GPP IMS terminal,
then the terminal stores authentication information in a smart card UICC (Universal
Integrated Circuit Card). The IMS terminal extracts or derives the parameters stored in the
smart card to build the credentials and does so transparently to the user.
In response, the IMS terminal sends a new SIP REGISTER request to the P-CSCF. The P-CSCF
does the same operation as for the rst REGISTER request; that is, it determines the entry
point in the network stored in the Request-URI of the REGISTER request and nds an I-CSCF
in the home network. It must be noted that this I-CSCF, due to DNS load-balancing
mechanisms, may not be the same I-CSCF that the rst REGISTER request traversed.
The I-CSCF sends a new Diameter UAR message for the same reasons as explained before.
The difference in this situation is that the Diameter UAA message includes routing
information: the SIP URI of the S-CSCF allocated to the user. The HSS stored this URI when it
received a Diameter MAR message. Therefore, no matter whether the I-CSCF is the same ICSCF the rst REGISTER request traversed or not, the second REGISTER request ends up in
the same S-CSCF, the one that was allocated to the user at the time of the registration. The
S-CSCF receives the REGISTER request that includes the user credentials.
TK420
Page 62
The S-CSCF then validates these credentials against the authentication vectors provided by
the HSS in a Diameter MAA message. If authentication is successful, then the S-CSCF sends a
Diameter SAR message to the HSS for the purpose of informing the HSS that the user is now
registered and to download the user prole. The user prole is an important piece of
information that includes, among other things, the collection of all the Public User Identities
allocated for authentication of the Private User Identity. It also indicates to the S-CSCF
which of these Public User Identities are automatically registered in the S-CSCF in a set of
implicitly registered Public User Identities. Additionally, the user prole also contains the
initial lter criteria, which is the collection of triggers that determine when a SIP request is
forwarded to the Application Server that will be providing the service.
At this stage the S-CSCF has stored the contact URI for this user, as it was present in the
Contact header eld of the SIP REGISTER request. It has also stored the list of URIs included
in the Path header eld. This list always includes the P-CSCF URI and may optionally include
an I-CSCF URI. Later, the S-CSCF will route initial SIP requests addressed to the user via the
list of URIs included in the Path header eld and the contact address in this order.
Last, the S-CSCF sends a 200 (OK) response to the REGISTER request, to indicate the success
of the REGISTER request. The 200 (OK) response includes a P-Associated-URI header eld
that contains the list of URIs allocated to the user (not to be confused with the list of
implicitly registered URIs). It also contains a Service-Route header eld that includes a list of
SIP server URIs. Future SIP requests that the IMS terminal sends will be routed via these SIP
servers, in addition to the outbound proxy (P-CSCF).
In the IMS the Service-Route header eld value always contains the address of the S-CSCF of
the user and may also contain the address of an I-CSCF in the home network. Eventually, the
IMS terminal gets the 200 (OK) response. At this stage the registration procedure is
complete. The IMS terminal is registered with the IMS for the duration of time indicated in
the expires parameter of the Contact header eld.
We want to stress that the IMS terminal is able to register a Public User Identity at any time.
For instance, when the IMS application in the terminal is switched on, the IMS terminal may
be congured to register one Public User Identity. Other Public User Identities may be
TK420
Page 63
registered later, at any time, upon explicit indication of the user. For example, this allows us
to register independently a personal Public User Identity from a business Public User
Identity.
TK420
Page 64
VoLTE
There is no CS domain in Evolved Packet System (EPS), so to provide E-UTRAN attached UEs
with voice services, two main solution can be used:
Voice over IP
CS Fallback: UEs must be redirected over towards other RAT that provides CSdomain services.
VoIP in LTE is a standardized (GSMA IR.92) solution using IMS network and dedicated EPS
bearers.
TK420
Page 65
SRVCC
Single Radio Voice Call Continuity (SRVCC) has been standardized in TS 23.216 of 3GPP Rel-8
to provide seamless continuity when UE handovers from E-UTRAN to UTRAN/GERAN.
E-UTRAN (4G) access together with EPC will provide Packet Switched services for Mobile
subscribers, and is able to provide sufficient QoS for VoIP calls as well.
However, 4G access might be available only in spotted areas in the first phases of
introduction, which means that VoIP calls cannot be maintained outside 4G coverage. In
order to enable seamless voice service from 4G access (VoIP) to 3G/2G (UTRAN/GERAN)
access (CS voice) the MSC Server Single Radio Voice Call Continuity (SRVCC) functionality has
been specified by 3GPP.
SRVCC has been standardized in TS 23.216 of 3GPP Rel-8 to provide seamless continuity
when UE handovers from E-UTRAN to UTRAN/GERAN.
With SRVCC procedure the Mobile subscribers are able to roam outside 4G coverage without
the call being disconnected.
TK420
Page 66
eUTRAN
SRVCC Architecture
MME
Handover/
Relocation
Sv
IMS
MSS
GERAN/UTRAN
Figure 36 SRVCC Architecture
The SRVCC functionality will cause challenges for the MSS enhanced with SRVCC, called as
MSS-SRVCC. The UE shall move in SRVCC from 4G to 3G/2G with limited amount of
information, no signaling connection and not attached to any CS services. The SRVCC
procedure shall be also done in very short period of time during which also user plane,
charging and statistics shall be fixed.
The enhancements SRVCC (eSRVCC) are specified in TR 23.856 of 3GPP Rel-10.
The interruption time of SRVCC must be less than 300 ms as required in TS 22.278, from
EUTRAN to UTRAN.
Especially when roaming, the requirement for SRVCC handover cannot be fulfilled by Rel-8
SRVCC solution.
TK420
Page 67
The MSC Server Enhanced for SRVCC shall support the following additional functionalies for
SRVCC:
The Sv interface support between the MME/SGSN and the MSS(SRVCC)
Handling the relocation/handover request for the voice component
Coordinating the CS relocation/handover and SIP session transfer
Interworking with SIP session transfer procedure to CS
Handling the Location Update instead of the terminal
Sv Interface
GTP tunnels are used between two nodes The
Sv interface is defined exclusively for SRVCC functionality by 3GPP TS 23.216
and 3GPP TS 29.280.
The Sv interface establishes connection between the MSS and the MME to
enable the SRVCC specific procedures. The MSS acts as a server and the
MME/SGSN as a client.
Two nodes communicate with GTP tunnels over a GTP based interface.
The The Sv interface supports IPv4 and IPv6 connections.
GTPv2-C
UDP
MME
IP
MSS
Sv
Figure 37 Sv Interface
TK420
Page 68

TK420.EPC Walid 2016 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TK420.EPC Walid 2016 PDF

Uploaded by

Copyright:

Available Formats

TK420

Copyright TEKonsult 2016

3GPP Network evolution

BSC based RNC based

Figure 1 3GPP Network evolution

Faster data DL/UP

Plug & Play architecture

Response for applications

Figure 2 LTE Advantages

LTE (Long-Term Evolution) of UMTS (Universal Mobile Telecommunications Service) is one of

LTE Standards and Roadmap

LTE & EPC

Figure 3 3GPP Releases

a dened Quality of Service (QoS) in early standardization releases. Meanwhile, in parallel to

2 Motivation and Targets for LTE

Flat rate pricing

Figure 4 LTE Motivations

Main LTE performance targets

Optimized mobile OFDMA solution for new and wider spectrum

HSPA+ allow the system to quickly react to data bursts.

Figure 5 Main LTE performance targets

3 LTE Radio Access Network Architecture

4 Network Elements and Function

4.1 evolved Node B

Evolved Node B (eNb)

IP header compression and encryption of user data stream.

4.2 Mobility Management Entity

Mobility Management Entity (MME)

4.3 Serving Gateway

Serving Gateway (SGW)

4.4 Packet Data Network Gateway

Packet Data Network Gateway (PGW)

UL and DL service level charging.

Interfacing through OFCS

UL and DL service level gating control.

aggregate of SDFs with the same GBR QCI.

4.5 Policy and Charging Rule Function

The PCRF was introduced in R5 as a part of the IMS network.

Policy and Charging Rule Function (PCRF)

Service (data flow) prioritisation and conflict handling

Figure 10 Policy and Charging Rule Function

4.6. Home Subscriber Server

Home Subscriber Server (HSS)

HSS utilizes DIAMETER protocol to support LTE/EPC.

Figure 11 Home Subscriber Server

02_Evolved Core Network

02_Evolved Core Network

1 Core network architecture and its evolution

02_Evolved Core Network

Core Network targets

Figure 1 Core Network targets

02_Evolved Core Network

02_Evolved Core Network

3GPP architecture evolution towards at

NodeB & RNC

Figure 2 3GPP architecture evolution towards at architecture

02_Evolved Core Network

2 Pool Concept for MME and SGW

02_Evolved Core Network

Figure 3 MME Pooling

3.2 SGW pooling

02_Evolved Core Network

02_Evolved Core Network