Module IX: EPC
1
Module IX: EPC
2
Module IX: EPC
3
Module IX: EPC
4
Module IX: EPC
5
Module IX: EPC
6
Module IX: EPC
7
Module IX: EPC
8
Module IX: EPC
S1: interface between an eNB and an EPC, providing an interconnection point
between the EUTRAN and the EPC. It is also considered as a reference point.
S1-MME: Reference point for the control plane protocol between E-UTRAN and MME.
S1-UP : Reference point for the transport for data streams on the S1 interface
between E-UTRAN and SGW using the GTP-U protocol
Interface between eNB ( X2)
The X2 interface provides capability to support radio interface mobility between
eNBs, of UEs having a connection with E-UTRAN. The X2 interface enables inter-
connection of eNBs and support of continuation between eNBs of the E-UTRAN
services offered via the S1 interface
Interface between MME and HSS (S6a-interface)
This interface is used to exchange the data related to the location of the mobile
station and to the management of the subscriber. The main service provided to the
mobile subscriber is the capability to transfer packet data within the whole service
area. The MME informs the HSS of the location of a mobile station managed by the
latter. The HSS sends to the MME all the data needed to support the service to the
mobile subscriber. Exchanges of data may occur when the mobile subscriber requires
a particular service, when he wants to change some data attached to his subscription
or when some parameters of the subscription are modified by administrative means.
9
Module IX: EPC
Reference point between 3GPP2 1xCS IWF and MME (S102-reference point)
The S102 reference point provides a tunnel between MME and 3GPP2 1xCS IWS to relay 3GPP2 1xCS
signalling messages in order to support SRVCC
Reference point between HRDP AN and MME (S101-reference point)
The S101 interface supports procedures for Pre-Registration, Session Maintenance and Active
handovers between E UTRAN and HRPD networks. This is based on tunnelling over S101 signalling of
one technology while the UE is in the other technology
Interface between HSGW and S-GW (S103-interface)
The S103 interface between the Serving GW and HRPD PDSN HSGW supports the forwarding of DL data
during mobility from E-UTRAN to HRPD . Signalling procedures on the S101 interface are used to set up
tunnels on the S103 interface.
Interface between Trusted non-3GPP IP Access and S-GW/P-GW (S2a-interface)
It provides the user plane with related control and mobility support between trusted non 3GPP IP access
and the Gateway
Interface between PDN-GW/S-GW and ePDG (S2b-interface)
It provides the user plane with related control and mobility support between ePDG and the Gateway.
Interface between PDN-GW and UE (S2c-interface)
It provides the user plane with related control and mobility support between UE and the Gateway. This
reference point is implemented over trusted and/or untrusted non-3GPP Access and/or 3GPP access
Interface between Trusted non-3GPP IP Access and 3GPP AAA Server/proxy (STa-interface)
It connects the Trusted non-3GPP IP Access with the 3GPP AAA Server/Proxy and transports access
authentication, authorization, mobility parameters and charging-related information in a secure
manner.
Interface between ePDG and Untrusted non-3GPP Access (SWn-interface)
This is the reference point between the Untrusted Non-3GPP IP Access and the ePDG. Traffic on this
interface for a UE-initiated tunnel has to be forced towards ePDG
10
Module IX: EPC
S1 Application Protocol (S1-AP): Application Layer Protocol between the eNodeB and
the MME.
- SCTP for the control plane (SCTP): This protocol guarantees delivery of
signalling messages between MME and eNodeB (S1).
11
Module IX: EPC
NAS: The NAS protocol supports mobility management functionality and user plane
bearer activation, modification and deactivation. It is also responsible of ciphering
and integrity protection of NAS signalling.
- LTE-Uu: The radio protocol of E-UTRAN between the UE and the
eNodeB
12
Module IX: EPC
GPRS Tunnelling Protocol for the control plane (GTP-C): This protocol tunnels
signalling messages between MME and S-GW (S11).
-User Datagram Protocol (UDP): This protocol transfers signalling messages
GPRS Tunnelling Protocol for the control plane (GTP-C): This protocol tunnels
signalling messages between S-GW and P-GW (S5 or S8).
-User Datagram Protocol (UDP): This protocol transfers signalling messages between
S-GW and P-GW.
13
Module IX: EPC
GPRS Tunnelling Protocol for the user plane (GTP-U): This protocol tunnels user data
between eNodeB and the S-GW as well as between the S-GW and the P-GW in the
backbone network. GTP shall encapsulate all end user IP packets.
-MME controls the user plane tunnel establishment and establishes User Plane
Bearers between eNodeB and S-GW.
-UDP/IP: These are the backbone network protocols used for routeing user data and
control signalling.
-LTE-Uu: The radio protocols of E-UTRAN between the UE and the eNodeB
14
Module IX: EPC
Proxy Mobile IPv6 protocol is intended for providing network-based IP mobility
management support to a mobile node, without requiring the participation of the
mobile node in any IP mobility related signaling. The mobility entities in the network
will track the mobile node's movements and will initiate the mobility signaling and
set up the required routing state. The core functional entities in the NETLMM
infrastructure are the Local Mobility Anchor (LMA) and the Mobile Access Gateway
(MAG). The local mobility anchor is responsible for maintaining the mobile node's
reachability state and is the topological anchor point for the mobile node's home
network prefix(es). The mobile access gateway is the entity that performs the
mobility management on behalf of a mobile node, and it resides on the access link
where the mobile node is anchored. The mobile access gateway is responsible for
detecting the mobile node's movements to and from the access link and for initiating
binding registrations to the mobile node's local mobility anchor. There can be
multiple local mobility anchors in a Proxy Mobile IPv6 domain each serving a different
group of mobile nodes. The architecture of a Proxy Mobile IPv6 domain is shown in
Figure 1
When a mobile node enters a Proxy Mobile IPv6 domain and attaches to an access
link, the mobile access gateway on that access link, after identifying the mobile node
and acquiring its identity, will determine if the mobile node is authorized for the
network-based mobility management service. If the network determines that the
mobile node is authorized for network-based mobility service, the network will
ensure that the mobile node using any of the address configuration mechanisms
permitted by the network will be able to obtain the address configuration on the
connected interface and move anywhere in that Proxy Mobile IPv6 domain. The
obtained address configuration includes the address(es) from its home network
prefix(es), the default-router address on the link, and other related configuration
parameters. From the perspective of each mobile node, the entire Proxy Mobile IPv6
domain appears as a single link, the network ensures that the mobile node does not
detect any change with respect to its layer-3 attachment even after changing its point
of attachment in the network.
15
Module IX: EPC
A subdomain name shall be derived from the MNC and MCC by adding the label "tac"
to the beginning of the Home Network Realm/Domain (see subclause 19.2).
The TAI FQDN shall be constructed as:
tac-lb<TAC-low-byte>.tac-hb<TAC-high-
byte>.[Link]<MNC>.mcc<MCC>.[Link]
The TAC is a 16 bit integer. <TAC-high-byte> is the hexadecimal string of the
most significant byte in the TAC and <TAC-low-byte > is the hexadecimal string
of the least significant byte. If there are less than 2 significant digits in <TAC-
high-byte> or <TAC-low-byte >, "0" digit(s) shall be inserted at the left side to
fill the 2 digit coding.
16
Module IX: EPC
17
Module IX: EPC
IMSI is composed of three parts:
1) Mobile Country Code (MCC) consisting of three digits. The MCC
identifies uniquely the country of domicile of the mobile subscriber;
2) Mobile Network Code (MNC) consisting of two or three digits for
GSM/UMTS applications. The MNC identifies the home PLMN of the mobile
subscriber. The length of the MNC (two or three digits) 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 outside the scope of this specification.
3) Mobile Subscriber Identification Number (MSIN) identifying the mobile
subscriber within a PLMN.
The National Mobile Subscriber Identity (NMSI) consists of the Mobile
Network Code and the Mobile Subscriber Identification Number.
18
Module IX: EPC
The number consists of:
- Country Code (CC) of the country in which the MS is registered,
followed by:
- National (significant) mobile number, which consists of:
- National Destination Code (NDC) and
- Subscriber Number (SN).
19
Module IX: EPC
The purpose of the GUTI is to provide an unambiguous identification of the UE that
does not reveal the UE or the user's permanent identity in the Evolved Packet System
(EPS). It also allows the identification of the MME and network. It can be used by the
network and the UE to establish the UE's identity during signalling between them in
the EPS. The GUTI has two main components:
- one that uniquely identifies the MME which allocated the GUTI; and
- one that uniquely identifies the UE within the MME that allocated the
GUTI.
Within the MME, the mobile shall be identified by the M-TMSI.
The Globally Unique MME Identifier (GUMMEI) shall be constructed from the
MCC, MNC and MME Identifier (MMEI).
The MMEI shall be constructed from an MME Group ID (MMEGI) and an MME
Code (MMEC).
The GUTI shall be constructed from the GUMMEI and the M-TMSI.
20
Module IX: EPC
Session management establishes and handles the connection between an UE and a
PDN. The UE is connected to a PDN during Attach to provide “Always on ”IP
connectivity. The EPS session management deals, for example, with the allocation of
Serving Gateway and PDN Gateway IP addresses. Both static IP addresses and
dynamic allocation of IP addresses are supported. A session spans the period of a
connection. One context contains the information for the connection. A connection
consists of one or several EPS bearers
21
Module IX: EPC
For PMIP-based S5/S8 and E-UTRAN access, an EPS bearer consists of the
concatenation of one Radio Bearer and one S1 bearer. The PDN Connectivity Service
between a UE and an external packet data network is supported through a
concatenation of an EPS Bearer and IP connectivity between Serving GW and PDN
GW. QoS control between a Serving GW and a PDN GW is provided at the Transport
Network Layer (TNL).
22
Module IX: EPC
The EPS bearer is realised by the following elements:
- In the UE, UL TFT maps a traffic flow aggregate to an EPS bearer in the uplink
direction.
- In the Serving GW, the DL TFT maps a traffic flow aggregate to an EPS bearer
in the downlink direction.
- A radio bearer transports the packets of an EPS bearer between a UE and an
eNodeB. There is a one-to-one mapping between an EPS bearer and a radio bearer.
- An S1 bearer transports the packets of an EPS bearer between an eNodeB and
a Serving GW. There is a one-to-one mapping between an EPS bearer and a S1 bearer.
- A per UE per PDN tunnel transports the packets of an EPS bearer between a
Serving GW and a PDN GW. There is a many-to-one mapping between an EPS bearer
and this per UE, per PDN tunnel.
- A UE stores a mapping between an uplink packet filter and a radio bearer to
create the mapping between a traffic flow aggregate and a radio bearer in the uplink.
- An eNodeB stores a one-to-one mapping between a radio bearer and an S1
bearer to create the binding between a radio bearer and an S1 bearer in both the
uplink and the downlink direction.
- A Serving GW stores a one-to-one mapping between a downlink packet filter
and an S1 bearer to create the mapping between a traffic flow aggregate and an S1
bearer in the downlink.
- A PDN GW enforces APN-AMBR across all SDFs of the same APN that is
associated with Non-GBR QCIs.
23
Module IX: EPC
24
Module IX: EPC
25
Module IX: EPC
26
Module IX: EPC
PDN GW selection function (3GPP accesses)
The PDN GW selection function allocates a PDN GW that shall provide the PDN connectivity for the 3GPP access. The
function uses subscriber information provided by the HSS and possibly additional criteria. The PDN subscription contexts
provided by the HSS contain:
-the identity of a PDN GW and an APN (PDN subscription contexts with subscribed PDN GW address are not used when
there is interoperation with pre Rel-8 2G/3G SGSN), or
-an APN and an indication for this APN whether the allocation of a PDN GW from the visited PLMN is allowed or whether a
PDN GW from the home PLMN shall be allocated. Optionally an identity of a PDN GW may be contained for handover with
non-3GPP accesses.
In the case of static address allocation, a static PDN GW is selected by either having the APN configured to map to a given
PDN GW, or the PDN GW identity provided by the HSS indicates the static PDN GW.
The HSS also indicates which of the PDN subscription contexts is the Default one for the UE.
To establish connectivity with a PDN when the UE is already connected to one or more PDNs, the UE provides the requested
APN for the PDN GW selection function.
If one of the PDN subscription contexts provided by the HSS contains a wild card APN (see TS 23.003 [9]), a PDN connection
with dynamic address allocation may be established towards any APN requested by the UE.
If the HSS provides the identity of a statically allocated PDN GW, or the HSS provides the identity of a dynamically allocated
PDN GW and the Attach Type indicates "Handover", no further PDN GW selection functionality is performed. If the HSS
provides the identity of a dynamically allocated PDN GW and the Attach Type indicates "initial Attach", either the provided
PDN GW is used or a new PDN GW is selected. The PDN GW identity refers to a specific PDN GW. If the PDN GW identity
includes the IP address of the PDN GW, that IP address shall be used as the PDN GW IP address; otherwise the PDN GW
identity includes an FQDN which is used to derive the PDN GW IP address by using Domain Name Service function, taking
into account the protocol type on S5/S8 (PMIP or GTP).
NOTE: Provision of a PDN GW identity of a PDN GW as part of the subscriber information allows also for a PDN GW
allocation by HSS.
If the HSS provides a PDN subscription context that allows for allocation of a PDN GW from the visited PLMN for this APN,
the PDN GW selection function derives a PDN GW identity from the visited PLMN. If a visited PDN GW identity cannot be
derived, or if the subscription does not allow for allocation of a PDN GW from the visited PLMN, then the APN is used to
derive a PDN GW identity from the HPLMN. The PDN GW identity is derived from the APN, subscription data and additional
information by using the Domain Name Service function. If the PDN GW identity is a logical name instead of an IP address,
the PDN GW address is derived from the PDN GW identity, protocol type on S5/S8 (PMIP or GTP) by using the Domain
Name Service function. The S8 protocol type (PMIP or GTP) is configured per HPLMN in MME/SGSN.
27
Module IX: EPC
28
Module IX: EPC
29
Module IX: EPC
The term Application Function (AF) is defined in TS 23.207 [19]. The terms Policy and
Charging Rules Function (PCRF) and Policy and Charging Enforcement Function (PCEF) are
defined in TS 23.203 [20].
A dedicated SAE bearer is associated with uplink packet filters in the UE and downlink packet
filters in the PCEF where the filters only match certain packets. A default SAE bearer is
associated with “match all” uplink and downlink packet filters in the UE and the PCEF,
respectively.
An SAE bearer is referred to as a GBR SAE bearer if dedicated network resources related to a
Guaranteed Bit Rate (GBR) value that is associated with the SAE bearer are permanently
allocated (e.g. by an admission control function in the eNB) at SAE bearer
establishment/modification. Otherwise, an SAE bearer is referred to as a Non-GBR SAE
bearer.
A dedicated SAE bearer can either be a GBR or a Non-GBR SAE bearer. A default SAE bearer
shall be a Non-GBR SAE bearer.
An operator controlled Rx service is a service for which the PCEF receives from the PCRF
service specific uplink/downlink packet filters and service specific QoS parameters where the
QoS parameters have been derived from information that the PCRF received over the Rx
interface from an AF.
An operator controlled Gx only service is a service for which the PCEF receives from the PCRF
service specific uplink/downlink packet filters and service specific QoS parameters without
any interaction across an Rx interface.
NOTE: A single PCEF may realize any combination of operator controlled Rx and Gx
only services on the same or different SAE bearers.
NOTE: An operator controlled Gx only service may be realized based on a default
SAE bearer or a dedicated Non-GBR SAE bearer. An operator controlled Gx only service
realized based on a dedicated GBR SAE bearer is FFS.
30
Module IX: EPC
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 uniquely identifies traffic flows that receive a common QoS treatment 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. The packet filters signalled in the NAS
procedures are associated with a unique packet filter identifier on per-PDN connection basis.
NOTE 1:The EPS Bearer Identity together with the packet filter identifier is used to reference which packet filter the UE intends
to modify or delete, i.e. it is used to implement the unique packet filter identifier.
The EPS bearer traffic flow template (TFT) is the set of all packet filters associated with that EPS bearer.
An EPS bearer is the level of granularity for bearer level QoS control in the EPC/E-UTRAN. That is, all traffic 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 packet forwarding treatment requires separate EPS
bearers.
NOTE 2:In addition but independent to bearer level QoS control, the PCC framework allows an optional enforcement of service
level QoS control on the granularity of SDFs independent of the mapping of SDFs to EPS bearers.
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 for the same PDN connection is referred to as a dedicated bearer.
An UpLink Traffic Flow Template (UL TFT) is the set of uplink packet filters in a TFT. A DownLink Traffic Flow Template (DL TFT) is
the set of downlink packet filters in a TFT. Every dedicated EPS bearer is associated with a TFT. The UE uses the UL TFT for
mapping traffic to an EPS bearer in the uplink direction. The PCEF (for GTP-based S5/S8) or the BBERF (for PMIP-based S5/S8)
uses the DL TFT for mapping traffic to an EPS bearer in the downlink direction. The UE may use the UL TFT and DL TFT to
associate EPS Bearer Activation or Modification procedures to an application and to traffic flow aggregates of the application.
Therefore the PDN GW shall, in the Create Dedicated Bearer Request and the Update Bearer Request messages, provide all
available traffic flow description information (e.g. source and destination IP address and port numbers and the protocol
information).
For the UE, the evaluation precedence order of the packet filters making up the UL TFTs is signalled from the P-GW to the UE as
part of any appropriate TFT operations.
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. When the PCEF changes those values, the MME shall
use the bearer level QoS parameter values received on the S11 reference point during establishment or modification of the
default bearer.
31
Module IX: EPC
An EPS bearer is realized by the following elements:
-In the UE, the UL TFT maps a traffic flow aggregate to an EPS bearer in the
uplink direction;
-In the PDN-GW, the DL TFT maps a traffic flow aggregate to an EPS bearer in
the downlink direction;
-A radio bearer (defined in TS 36.300 [5]) transports the packets of an EPS
bearer between a UE and an eNodeB. If a radio bearer exists, there is a one-
to-one mapping between an EPS bearer and this radio bearer;
-An S1 bearer transports the packets of an EPS bearer between an eNodeB
and a Serving GW;
-An E-RAB (E-UTRAN Radio Access Bearer) refers to the concatenation of an
S1 bearer and the corresponding radio bearer, as defined in TS 36.300 [5].
-An S5/S8 bearer transports the packets of an EPS bearer between a Serving
GW and a PDN GW;
-A UE stores a mapping between an uplink packet filter and a radio bearer to
create the mapping between a traffic flow aggregate and a radio bearer in
the uplink;
-A PDN GW stores a mapping between a downlink packet filter and an S5/S8
bearer to create the mapping between a traffic flow aggregate and an S5/S8
bearer in the downlink;
-An eNodeB stores a one-to-one mapping between a radio bearer and an S1
Bearer to create the mapping between a radio bearer and an S1 bearer in
both the uplink and downlink;
32
Module IX: EPC
Here we see the components needed for the deployment of an end-to-end IP RAN
and how they are interlinked.
To implement an IP RAN:
1. At the RBS site
• GSM/WCDMA base stations need to be able to terminate IP and provide a physical
Ethernet interface. Security gateways may also be deployed as an option.
2. At the BSC/RNC site
• BSC and RNC need to be equipped with IP interfaces (GSM –PGW, and WCDMA ET-
MFX12/13)
• RAN Switch/routers, time servers and security gateways are required according to
the chosen IP RAN implementation.
The chosen backhaul solution will vary significantly according to the network and
operator situation preferences, and this will affect the equipment required to
implement the IP RAN solution.
33
Module IX: EPC
At the RBS site, the LTE RBS (eNodeB) can be:
located on a new site containing one or more eNodeBs only
each eNodeB has one Ethernet WAN interface, which can be connected directly to the
transport network.
co-located with a WCDMA RBS
An SIU can be used for traffic aggregation; otherwise aggregation can take place in the first
transport network node, for example MINI-LINK TN or Marconi OMS 1410.
co-located with an existing GSM (and likely WCDMA) RBS
the eNodeB will be connected to the co-location port on the SIU, any WCDMA RBS will be
connected to one of the flexible Ethernet ports, and GSM RBSs are connected via E1/T1 links.
All eNodeBs are connected by the logical X2 interface. X2 is mainly used to support active
user mobility; it may also be used for multi-cell Radio Resource Management (RRM)
functions.
At the switching site, LTE traffic is handled differently for control and user planes. User plane
traffic must be routed to a Serving Gateway function, where the S1-U interface is terminated.
The Serving Gateway and PDN Gateway (the payload gateway facing the IP services) are
physically realized in a common node called the SAE-Gw. Routing/switching takes place in a
SmartEdge device; it is recommended that Mobile-PBN Site Routers / Ethernet Switches
(combined using BVI feature) be reused for this purpose.
Control plane traffic (S1-C interface) is handled at an MME (Mobility Management Entity)
node. This function is combined with a 2G/3G SGSN, denoted SGSN-MME 2009B.
Accurate synchronization for the eNodeB is a mandatory requirement in LTE, and this can be
achieved in a number of ways. SoIP (synchronization over IP) design has been adopted for
LTE, using either an RNC’s ET-MFX board or a standalone NTP server as SoIP server.
Alternatively, GPS based synchronization systems can be deployed at eNodeB sites or
synchronization can be obtained from a co-located WCDMA RBS (containing an ET-MFX
board) or SIU.
34
Module IX: EPC
IP network scenarios have to be described for the LTE IP RAN design.
eNodeB/RBS A is directly connected to a Layer 2 network/MEN (Net A), which
connects a number of Switching/Primary sites (where S-Gw and MME pools for that
eNodeB are located).
eNodeB/RBS B is connected to a Layer 2 network/MEN, but connectivity to the
Switching/Primary sites (where S-Gw and MME pools for that eNodeB are located) is
provided by a Layer 3 network (typically IP/MPLS).
eNodeB/RBS C is directly connected to a Layer 3 network through a site router.
35
Module IX: EPC
36