EPS
EPS Major Protocols
The Evolved Packet System is designed to be an ‘all-IP’ environment. This means that all protocols, whatever their function, will travel between network nodes via an IP transport network.
IP is an open standards Network Layer/Layer 3 packet delivery system specified by the loose community of IT academics and professionals that comprise the IETF.
IETF specifications exist in the form of RFCs (Requests For Comment), which are freely available for download and comment from their website – www.ietf.org.
Most major protocols employed within the EPS were developed by the IETF, which means that the EPS can be regarded as a (mostly) open-standards networking environment.
Where relevant IETF-based specifications do not exist or where a legacy protocol can be employed, 3GPP has developed protocols or reused protocols of its own. These protocols are mainly related to inter-node signalling functions and are either evolutions or combinations of existing 3GPP systems.
IETF
Underlying Transport
UDP SCTP TCP
IPv4/IPv6 SDP
SIP
RTCP RTP
DiffServ Mobile IP Diameter
IETF Dependence
Many IETF protocols are employed within the EPS and the IMS.
These include:
IP – support for IPv4 and IPv6
UDP – employed at the transport layer in many protocol stacks
TCP – generally only employed on the SGi interface
SCTP – employed on signalling interfaces
Mobile IP – MIPv4, PMIPv6 and DSMIPv6 are variously employed
SIP – employed by the IMS to establish user sessions
SDP – employed within SIP to describe session parameters
RTP – transports user session media flows
RTCP – provides control and feedback for RTP sessions
DiffServ – provides IP QoS services
Diameter – provides secure connections between signalling nodes
Further Reading: 3GPP TS 23.401; 36.300; www.ietf.org
IPv6 EPS
IPv4 EPS
IPv4 Internet
IP in the EPS/IMS Access Network
IP in the EPS/IMS
IP is the only packet transport mechanism employed by the EPS transport network. It does not support the layer 2 transmission protocols employed in legacy systems such as TDM (Time Division Multiplexing) and ATM (Asynchronous Transfer Mode).
An IP ‘cloud’ provides logical and physical interconnections between EPS network nodes. The design of the cloud is intended to ensure that redundant paths exist between all nodes to allow the network to operate in a resilient and fault-tolerant manner.
Equipment vendors and network operators have the option of deploying systems that support IPv4 (IP version 4) or IPv6 (IP version 6) or a combination of both (functionality which is referred to by EPS nodes as ‘IPv4v6’).
Compared to legacy IPv4, which has been in use since the early 1980s, IPv6 has a flatter protocol structure - with many functions that required additional protocols in IPv4 being performed within the IP layer itself in IPv6.
These additional features include functions such as dynamic IP address allocation, which required an additional protocol such as DHCP (the Dynamic Host Configuration Protocol) in IPv4, but is managed automatically (by means of router prefixes and host link local addresses) in IPv6. Support for security mechanisms such as IPsec (IP security) are also incorporated into the IP layer in IPv6.
IPv6 is a backwards-compatible system, however, so network operators have the opportunity
GTPv2
S1AP
X2AP
3GPP
3GPP Protocols
The Evolved Packet Core employs a number of protocols designed by 3GPP and ETSI. These include GTP (the GPRS Tunnelling Protocol), S1AP (S1 Application Protocol) and X2AP (X2 Application Protocol).
Further Reading: 3GPP TS 29.274 (GTPv2-C), 36.41x (S1), 36.42x (X2)
Legacy GTP SGSNs
RNC
3G PS core
GGSN 2G PS core
User traffic flows GTPv0 Tunnels
User traffic flow GTPv1 Tunnels
GTP-C and GTP-U tunnels
Legacy GTP
GTP was originally designed as part of the 2.5G GPRS packet core network and was employed to route encapsulated traffic packets between GPRS Support Nodes (SGSNs and GGSNs).
The initial 2.5G version of GTP became known as GTPv0.
As it matured, a number of basic problems were discovered. Chief amongst these was the fact that GTPv0 placed tunnel control and administrative information in fields in the headers of packets that also encapsulated user data. This meant packets that carried user data but no control information had a greater amount of header overhead than necessary, leading to a potentially inefficient service.
GTPv1 was developed to offer an evolved service to 3G packet core networks. The most obvious difference with GTPv0 was the extension of the service beyond the SGSN and down to the RNC.
Another major difference was the separation of the protocol into parts that dealt with control plane (GTP-C) and user plane (GTP-U) traffic. GTP-U packet headers could therefore be smaller and offer a more efficient service, as all control data was carried in its own logical stream.
MME
GTPv2 (GTP version 2) was developed to allow the control of the tunnelling service offered by the protocol to adapt to the specific needs of the EPS environment.
C-plane functions on GTP-based interfaces are handled by GTPv2-C, while U-plane traffic tunnelling continues to be handled by GTPv1, now known as GTPv1-U.
In v1, GTP-C was used to carry tunnel creation and management messages between the GSNs and between the RNC and SGSN.
To reflect the separation of bearer management and routing functions into the MME and S-GW respectively, in GTPv2-C the protocol is also used to carry bearer creation and management directives over the S11 interface between those nodes.
The main functional evolution that GTPv2-C needs to support is the creation of default and dedicated EPS bearers on the S5 and S8 interfaces between S-GW and PDN-GW.
GTPv2-C is also employed on the S3 interface that connects the MME to legacy SGSNs and on the S10 interface that interconnects MMEs. SGSNs that support the S4 interface to the EPC may also be upgraded to support the S16 interface in place of the legacy Gn; the S16 is also based on GTPv2-C.
GTP-C is not employed on the S1-MME and X2 interfaces, where bearer creation and management is instead handled by interface specific Application Protocols (S1AP and X2AP), although GTPv2-C does carry instructions to the S-GW regarding the establishment of GTP tunnels that will then run over the S1-U interface.
GTPv1-U is employed to encapsulate and route user plane traffic on all traffic-carrying interfaces, including S1, X2, S4, S5, S8, S12 and S16.
Further Reading: 3GPP TS 23.401, 29.274 (GTPv2-C); 29.281 (GTPv1-U)
SCTP
UE context management
Additional E-RAB creation
Mobility functions
Paging
Direct transfer of NAS signalling
S1AP (S1 Application Protocol)
S1AP is designed to provide a control plane connection on the S1-MME interface between an eNB and an associated MME.
The S1-flex concept means that each base station may be associated with multiple MMEs, which in turn means that each eNB could host multiple instances of the S1AP.
S1AP is responsible for E-RAB (E-UTRAN Radio Access Bearer) management i.e. setting up, modifying and releasing bearers under instruction from an MME. It also performs initial context transfer to establish an S1UE context in the eNB on initial attach including collating details of the UE’s capabilities and the creation of a default bearer. It undertakes UE context management; transferring UE context data between eNBs and MMEs in the event of handovers or relocations.
S1AP is also responsible for the creation of additional E-RABs (for carrying further Default or
Dedicated EPS Bearers) and for mobility functions for UEs in ECM-Connected state. It also performs paging and the Direct Transfer of NAS signalling between the UE and the MME.
S1AP takes the place of GTP-C on the S1 interface, carrying bearer-specific control information between the MME and the eNB, including details such as TEIDs and UE S1 identities.
S1AP is also responsible for carrying the messaging that enables the E-RAB ‘path switch’ function to take place after an inter-eNB handover. Additionally, it provides support for MME relocation and S-GW change functions.
S1-MME
eNB
MME
MME
MME
MME S1 over SCTP Association
eNB and MME act as SCTP endpoints
S1AP and SCTP
S1AP connections are logical and are designed to operate over SCTP/IP links to multiple MMEs.
The redundancy and resilience built into the ‘S1 Flex’ concept should ensure that the administrative load (and therefore also the risk) associated with the UEs served by one eNB is shared evenly between a group of MMEs.
Each S1-MME interface is carried by an SCTP Association established between an eNB and an MME. One or more streams may then be established to carry S1AP message flows.
Further Reading: 3GPP TS 36.413; 23.401
X2-CP (Control Plane)
SCTP IP Data link layer
X2- AP
Physical layer
X2 X2AP
X2AP (X2 Application Protocol)
The X2 interface is used to forward buffered traffic between eNBs during handovers and to provide a service management message path between neighbouring base stations.
The X2 interface is optional but recommended as it has the potential to reduce significantly the amount of S1 signalling and handover traffic that the MMEs and S-GWs in a network are required to support.
The X2 interface can be viewed as being broadly analogous in function to the Iur interface employed between 3G RNCs, although with no requirement to support macro diversity functions the scope of the X2 interface is greatly reduced. X2AP can therefore be viewed as analogous to the RNSAP (Radio Network Subsystem Application Part) signalling protocol employed on the Iur.
X2
eNB A
X2 interfaces are only required between eNBs that are likely to be required to hand traffic over between the cells
they control.
E-UTRAN IP transport
X2
eNB Z X2
X2 over SCTP Association Neighbouring eNBs act
as SCTP endpoints
X2AP and SCTP
X2AP connections can be logical (in which case they exist as routes travelling through the E-UTRAN IP transport network) or physical (carried between eNBs by a dedicated link or virtual path) and are designed to operate over SCTP/IP links between neighbouring eNBs.
The X2 interface is optional but recommended.
An X2 interface is only required between eNBs if there is a chance of handover traffic passing
between the cells that they control; if eNB ‘A’ does not have an adjacency formed with eNB ‘Z’ there is no requirement for an X2 to exist between them.
Each X2 interface is carried by an SCTP Association established between eNBs. One or more streams may then be established to carry X2AP message flows.
Further Reading: 3GPP TS 36.423; 23.401
Glossary
ATM (Asynchronous Transfer Mode) ... 3 DHCP (the Dynamic Host Configuration Protocol) ... 3 E-RAB (E-UTRAN Radio Access Bearer) ... 7 GTP (the GPRS Tunnelling Protocol) ... 4 IPsec (IP security) ... 3 IPv4 (IP version 4) ... 3 IPv6 (IP version 6) ... 3 RFC (Request For Comment) ... 1 RNSAP (Radio Network Subsystem Application Part) ... 9 S1AP (S1 Application Protocol) ... 4 TDM (Time Division Multiplexing) ... 3 X2AP (X2 Application Protocol) ... 4