EVOLVED PACKET CORE
S- GW EPS IP Transport
Non-guaranteed PDU delivery via
GTP-U
S1-U
A logical S1-U interface is created between an eNB and each S-GW with which it is associated and provides AS connectivity for E-UTRAN users.
User traffic, transmitted in the form of a PDU, is encapsulated in GTPv1-U and carried across the S1-U.
GTPv1-U operates across UDP/IP and offers a non-guaranteed delivery service; user connections that require guaranteed delivery must employ a connection-oriented protocol above the GTP transport layer to manage retransmissions.
GTPv1-U is simply a relabelled version of the GTPv1 protocol employed in 3G packet core and UTRAN environments, although only the U-plane element is employed. An evolved version of GTP – GTPv2 – is employed to provide C-plane services on some other EPS interfaces but is not required on the S1-U.
Connection establishment and control functions for S1-U connections are managed by the S1 Application Protocol via the S1-MME interface.
An Evolved Radio Access Bearer (E-RAB) is a service provided by the Access Stratum to the Non Access Stratum for transfer of data of between the UE and the S-GW. Individual E-RAB traffic connections are established to carry an end user’s EPS Bearer; the E-RAB is itself carried within a GTPv1-U Tunnel over the S1 interface and is identified at the GTP level by TEIDs.
Further Reading: 3GPP TS36.414 (S1 Data Transport) and 29.281 (GTPv1-U)
S-GW 1 MME 1
S-GW 2 MME 2
S-GW 3 MME 3
S1-MME
S1-U
S1-Flex
S1-Flex Operation
Each eNB is able to establish associations with multiple MME and S-GW devices following a principle known as S1-Flex.
The main benefit of Flex capability is that it provides redundant core network services for each eNB and the set of UEs they serve. When a new UE requests service in a cell, whether due to an initial Attach or following a Handover, the eNB is able to select the MME to which it forwards the NAS connectivity request from one or more MME Groups. If an individual MME fails or becomes overloaded, the Flex concept ensures that only a subset of each cell’s users will be affected. Similar redundancies are provided for EPS Bearer connections through S-GWs.
Associated with the benefits of service redundancy are those of load balancing. If eNBs tailor the numbers of UEs they introduce to each MME to the advertised ‘relative capacity’ of each of those devices then the chances of individual MMEs becoming overloaded is minimized.
A further, but less obvious, benefit of the S1-Flex process is the ability it offers to allow each eNB to connect to and offer services for more than one PLMN. In theory, a physical network of base stations can advertise the services of, and connect traffic to, multiple PLMNs; this is a key enabler of LTE’s ability to support shared or Multi-Operator network environments. In this model, user connection requests are forwarded by the eNB to an MME belonging to one or other of the core networks that are sharing the same E-UTRAN.
Further Reading: 3GPP TS36.401
S1-MME
MME
Home eNB
(HeNB) S-GW
S1-U
Home eNB Gateway (HeNB GW)
Broadband
IP L2 S1-AP
SCTP
L1
L1 UDP
IP L2 User PDU
GTPv1-U
S1 Interfaces for Home eNBs
The HeNB (Home eNode B) concept provides a standardized method for creating and connecting LTE
‘femtocells’. Similar methods have been developed for the 3G HNB (Home Node B).
A femtocell provides limited-area radio coverage to residential or business premises; connections are passed back to the operator’s core network via a broadband Internet connection. Indeed, femtocell devices are often incorporated into broadband routers along with the broadband modem and Wi-Fi access point.
The HeNB provides the same set of services as a ‘full’ eNB and is logically connected to the EPC via the same S1-MME and S1-U interfaces.
Operators may optionally deploy an HeNB GW (Home eNB Gateway) to concentrate S1-MME traffic towards the MMEs, although the HeNBs will work even without a Gateway.
The HeNB presents itself to the HeNB GW as an eNB; the Gateway presents itself to the HeNB as an MME. The HeNB GW presents itself to the MME as an eNB.
An X2 interface between neighbouring HeNBs is not supported, although mobility between HeNB cells and other cells via the MME/S-GW is possible.
Further Reading: 3GPP TS 36.300:4.6, TR 25.820
UE Capability
S1AP protocol has been designed to perform the following functions:
E-RAB management Initial Context Transfer UE Capability Info Indication Mobility Functions for UEs
eNB and MME Configuration Update NAS Signalling transport
S1 UE context Release UE Context Modification RIM (RAN Information Management) Configuration Transfer
The functions are performed by employing the various EP message types shown in the diagram.
Further Reading: 3GPP TS 36.413:8.1
Home or Visited Network
SGSN
S-GW SGSN
S4
S16
PDN-GW
IP Services
S5 SGi
RNC
S12
S8
Home Network
SGi PDN-GW
L1 UDP
IP L2 GTPv1-U
GTPv1-U Traffic Interfaces
Most EPC interfaces are based on a combination of GTPv1-U and GTPv2-C.
The S4 interface carries U-plane traffic between an S-GW and an SGSN for EPC-attached UEs that have roamed onto GERAN (GSM EDGE Radio Access Network)/UTRAN access. SGSNs that support the S4 can also be upgraded to use the S16 interface, which allows the evolved combination of GTPv1-U and GTPv2-C to be used between SGSNs.
The S5 interface interconnects an S-GW to a PDN-GW within the same PLMN. The S8 Interface provides roaming connectivity between a visited S-GW and a home PDN-GW. The S5 interface is based on the 2G/3G Gn interface, whilst the S8 is analogous to the Gp interface.
The S12 interface is used to provide a U-plane only ‘direct tunnel’ between an S-GW and a 3G RNC, which allows the user plane to bypass the SGSN and thus avoids any traffic bottlenecks that may occur.
Further Reading: 3GPP TS 23.401:5.1, 23.281 (GTPv1-U), 23.060 (GPRS)
Home or
The S3 interface provides control plane connectivity between an MME and an SGSN and is used to carry handover and other control signalling between EPS and GERAN/UTRAN PS environments. The S16 interface carries control messaging between evolved SGSNs.
The S16 interface carries control messaging between evolved SGSNs. If an S16 interface exists it can be used to handle the relocation of bearers between SGSNs without requiring the operation to be controlled by an S-GW.
In addition to carrying user traffic, the S5 and S8 interfaces also carry GTPv2-C based control messaging. Networks based on non-3GPP protocols may elect to use variants of the S5 and S8 interfaces based on IETF ‘mobile IP’ protocols instead.
The S10 interface carries inter-MME signalling traffic and is employed during functions such as MME relocation. This may occur, for example, when a Connected Mode UE roams out of one MME pool area into another, or when MME load balancing or rebalancing is taking place. The S10 is analogous to the Gn interface and is based on GTPv2-C running over UDP/IP.
Further Reading: 3GPP TS 23.401:5.1, 29.274 (GTPv2-C), 23.060 (GPRS)
MME
HSS SGSN
EIR S6a
S13 S6d
L1 TCP/SCTP
IP L2 Diameter
Diameter-based Interfaces
The Diameter protocol was designed by the IETF as a more standardized successor to the venerable RADIUS (Remote Access Dial-In User Service) protocol, which provides a method of transporting AAA (Authentication, Authorization and Accounting) data over an IP network. Various proprietary adaptations of RADIUS have been developed, which were largely non-interoperable, making it a de facto closed standard.
The S6a interface connects the MME to the HSS and allows the secure transfer of subscriber and other data between those nodes. The Diameter Base Protocol and the applications that enable communication between the MME and HSS run over an IP link and can be protected at the transport layer by either TCP or SCTP.
The S13 interface optionally interconnects the MME and the Equipment Identity Register (EIR) and is therefore analogous to the GPRS Gf interface. Unlike the Gf, however, the S13 interface is based on the Diameter protocol.
The S6d interface allows 2G/3G SGSNs that also support the S4 interface to the S-GW to connect directly to the EPS HSS for mobility management and subscriber data access purposes.
PDN–GW
Visited PCRF
IMS Home PCRF
S7/Gx Rx
S9
L1 TCP/SCTP
IP L2 Diameter
PCRF Diameter Interfaces
The S7 interface connects the PDN-GW to the PCRF. It carries policy lookups sent by the PDN-GW in response to connection requests and the replies generated by the PCRF that determine how or if those requests will be fulfilled.
The S7 interface is based on the existing Gx interface and 3GPP specifications and diagrams use the reference names interchangeably.
The Rx interface connects the PCRF to the IMS and carries a similar range of message types as the Gx.
The S9 interface carries policy and charging rules data between home and visited PCRFs to allow home network policies to be applied to roaming UE connections.
Visited PCRFs may have the facility to request PCC (Policy and Charging Control) details from a user’s home network but they are under no obligation to enforce them if they contradict local policies.
Further Reading: 3GPP TS 23.401:4.7.4; 23.203
MME MSC/VLR or
MSC Server
SGs/Sv
L1 SCTP
IP L2 SGsAP
Interface to CS Networks
The EPC was designed as an ‘all IP’ environment and as such carries all traffic, even voice, in IP streams but interfaces have been developed that allow for backwards compatibility with and handover of CS (Circuit Switched) traffic to legacy networks, if required.
The SGs interface is based on the GERAN/UTRAN Gs interface and carries mobility management and handover signalling between an MME and a legacy MSC (Mobile-services Switching Centre) or MSC Server. It was created to serve the interfacing requirements of the CS Fallback service, which allows EPC-Attached UEs to drop back to 2G/3G networks to handle CS calls.
The SGsAP (SGs Application Part) message format employed on the interface is an adaptation of the BSSAP+ (Base Station System Application Part +) protocol employed on the legacy Gs interface, and provides much the same set of services.
Other interfaces have been developed to support other forms of EPC-CS Core interaction; the SGs interface, for example, carries MME-MSC/MSC-S signalling to support the SRVCC (Single Radio VCC), which allows IMS-anchored real time sessions to be seamlessly handed over between EPS Bearers and GERAN/UTRAN CS Bearers.
Further Reading: 3GPP TS 23.216 (SRVCC), 23.272 (CS Fallback)
UE
MME
PDN-GW S-GW
eNB
EPS Bearer
Radio Bearer
External Bearer
S5/S8 Bearer E-RAB
S1 Bearer
Uu S1 S5/S8
Connection Identifiers
The EPS Bearer ID (EBI) is assigned by the MME upon bearer establishment.
The EBI consists of 4 bits which in theory allows a maximum of 16 EPS bearers to be created for each UE. However, the relevant specification indicates that 5 values are reserved which limits the number of EPS Bearers per UE to 11. EBI values are always assigned by the MME which sets the EBI value for the default bearer and sends it to the S-GW. In the same way, the MME also assigns the EBI value to dedicated bearers. In UMTS networks the equivalent of an EBI is the NSAPI (Network Layer Service Access Point Identifier) which is used to identify a PDP context. When the UE moves from LTE to UMTS, the EBI is mapped to an NSAPI – this mapping is not complex as both NSAPI and EBI are 4 bit values.
The EPS Bearer travels between the UE and the PDN-GW; during handovers it may also extend over the X2 interface between source and target eNBs.
When travelling over the S1 and X2 interfaces, there is a one-to-one mapping between the EPS Bearer and the E-RAB and between the identities assigned to each of those entities.
Further Reading: 3GPP TS 23.401:5.2.1
UE S1-AP ID
S1-MME S1-AP Context
MME S1-AP ID
Tunnel Endpoint IDs
(TE-ID) S1-U GTP Tunnel
X2-C (UE X2-AP IDs) X2-U (GTP TE-IDs) UE
MME
S-GW
Transport Identities
To allow the S1 and X2 protocols to identify the UEs that form the endpoint of each transport tunnel, terminals are assigned identities that are unique within the eNBs or MMEs that support those endpoints.
The UE S1-AP ID and MME S1-AP ID are unique within the eNB and MME respectively that are handling the E-RAB/EPS Bearer to an Attached UE. The IDs are simple numerical identifiers (24-bits in the eNB and 32-bits in the MME) and are not associated with a specific instance of the S1 interface in each device. An eNB can therefore support a maximum of 224 (16.7 million) UE S1 connections and an MME 232(4.3 billion).
The UE X2-AP ID performs the same basic function as the S1-related identities, but for the X2 interface.
The X2 is optional and is only used to pass handover-related traffic between source and target eNBs, so the X2-AP ID will only be created as required when a handover is initiated. The ID is 12 bits long and provides a maximum of 4096 UE X2 handover identities per eNB.
The 4-byte GTP TEID is used in the EPS the same way as it is in legacy networks. Each device that supports a GTP tunnel refers to it in terms of the TEID assigned to the tunnel plus the IP address and UDP port number of the interface that handles it. TEIDs are assigned by the receiving side of each connection and are exchanged using S1-AP during tunnel establishment.
Further Reading: 3GPP TS 23.401:5.2; 36.413:9.2.3; 29.274 (GTPv2-C); 36.41x (S1); 36.42x (X2)
PDN-GW
Default and Dedicated EPS Bearers
Each UE will establish an initial or default EPS Bearer as part of the attach process. This will provide the required ‘always on’ IP connectivity to the UE and may be to a default APN (Access Point Name), if one is stored in the user’s subscriber profile, or to an APN selected by the network.
In networks that interconnect to an IMS, the default bearer allows the UE to perform SIP registration and thereafter to provide a path for session initiation messaging. In these circumstances, the data rate and QoS assigned initially to the default bearer is commensurate with the expected low level of SIP-based traffic flow, but these parameters could be modified to accommodate the requirements of application traffic flows when a connection is established. In reality, however, a separate EPS Bearer is established to carry LTE call media traffic, so the Default EPS Bearer would only need to be adjusted if the level of SIP traffic exceeded the capacity provided by the original QoS settings.
If a UE has a requirement to establish an application connection whose QoS or data rate demands are incompatible with those currently assigned to the default bearer (but which can still be routed through the current APN), the PDN-GW or PCRF may initiate the establishment of an additional EPS Bearer to carry the new traffic flow. Any additional bearers assigned to a UE in addition to the Default EPS Bearer are termed Dedicated EPS Bearers and will be identified by different EPS Bearer/E-RAB and radio bearer IDs.
A UE may have more than one PDN Connectivity Service running if it has connections established through more than one APN/PDN-GW. In that case, there will be one Default Bearer and an optional number of Dedicated Bearers created for each PCS. The 4-bit EPS Bearer ID and the set of reserved IDs limit the total number of bearers that can be established for one UE to eleven (numbered 5 to 16).
Further Reading: 3GPP TS 23.401:4.7.2
PCEF (Policy and Charging Enforcement
Function) in PDN-GW
QCI (QoS Class Identifier)
ARP (Allocation and Retention Priority) GBR (Guaranteed Bit Rate)
MBR (Maximum Bit Rate) EPS
EPS QoS Characteristics
EPS Quality of Service
QoS in the EPS is defined by a combination of four parameters:
QCI (QoS Class Identifier)
ARP (Allocation and Retention Priority)
GBR (Guaranteed Bit Rate)
MBR (Maximum Bit Rate)
EPS QoS is applied between the UE and the PDN-GW.
Further Reading: 3GPP TS 23
PDN-GW1 S-GW
UE
PDN-GW2 EPS bearer with
GBR QoS
APN-AMBR for non-GBR EPS bearers to PDN-GW 1
UE-AMBR for all non-GBR EPS Bearers from UE
APN-AMBR for non-GBR EPS bearers to PDN-GW 2
QoS Levels
QoS in the EPC is currently defined by three levels: GBR, MBR and AMBR (Aggregate Maximum Bit Rate).
GBR connections are assigned a guaranteed data rate and are therefore useful for carrying certain types of real-time and delay-sensitive traffic. MBR connections are non-guaranteed, variable-bit-rate services with a defined maximum data rate. If a connection’s data rate goes beyond the set maximum the network may decide to begin discarding the excess traffic.
GBR and MBR parameters are applied on a ‘per bearer’ basis, whereas AMBR is applied to a group of bearers; specifically, a group of non-GBR bearers that terminate on the same UE. AMBR allows the EPS to set a maximum aggregate bit rate for the whole group of bearers that can then be shared between them.
The APN-AMBR parameter sets the shared bit rate available to a group of non-GBR bearers that terminate on the same APN and can therefore be seen to be applied on a ‘per PCS’ basis; the UE-AMBR parameter aggregates all non-GBR bearers associated with one UE.
Dedicated bearers can be established as GBR or non-GBR (i.e. MBR) as required. Default bearers, due to the probable need to adjust their bandwidth after the initial Attach has taken place, must be non-GBR.
Further Reading: 3GPP TS 23.401:4.7.3
Bearer Context – Active
Radio Bearer/E-RAB/EPS Bearer Active
DRB S1 Tunnel S5/S8 Tunnel
UE eNB S-GW PDN-GW
MME Bearer Attributes
Active EPS Bearers and Bearer Contexts
An EPS bearer provides a data path between a UE and an APN located in a PDN-GW. Once created, an EPS bearer can be in one of two states – active or inactive.
When active, the EPS bearer is assigned bearer resources that amount to a radio bearer and GTP tunnels, with assigned TEIDs (Tunnel Endpoint IDs) that will carry the E-RAB (E-UTRAN Radio Access Bearer) and EPS Bearer over the Uu, S1-U and S5/S8 interfaces.
Each PDN connection and default and dedicated EPS bearer is described by a Bearer Context stored in the UE and MME and in other devices required to serve each bearer.
Default and dedicated bearer contexts describe the UE’s current ECM state (idle or connected) plus the bearer’s EPS bearer ID and QoS parameters, and can be either active or inactive.
An active Bearer Context is deemed to be in the ESM BEARER CONTEXT ACTIVE state.
Further Reading: 3GPP TS 23.401:4.7.2
Bearer Context – Inactive
S5/S8 EPS Bearer Active S5/S8 Tunnel
UE eNB S-GW PDN-GW
MME Bearer Attributes
Radio Bearer/
E-RAB Released
Inactive EPS Bearers and Bearer Contexts
When an EPS Bearer is inactive, either as a result of an instruction from the UE or MME or of an inactivity timer expiring, Uu and S1-U resources are released, although the S5/S8 tunnel is retained and details of the bearer context are retained by the UE and the MME for future reactivation when required.
The separation of the bearer resources from the bearer context means that details of each bearer can be retained by the network even when the physical resources associated with it have been released during periods of inactivity.
An inactive bearer context can be reactivated by either the UE or the network using the Service Request procedure.
The S-GW may invoke the Downlink Data Notification procedure if data arrives for an inactive bearer.
The Bearer Context data held in the UE and the MME may become unsynchronized during periods of inactivity; both devices will attempt to re-synchronize this data when a signalling connection is
The Bearer Context data held in the UE and the MME may become unsynchronized during periods of inactivity; both devices will attempt to re-synchronize this data when a signalling connection is