LT3600/v1.1 © Wray Castle Limited iii
Contents
EPS Major Protocols ...6.1 IETF Dependence ...6.2 IP in the EPS/IMS ...6.3 3GPP Protocols...6.4 Legacy GTP ...6.5 GTP in the EPS...6.6 S1AP (S1 Application Protocol) ...6.7 S1AP and SCTP ...6.8 X2AP (X2 Application Protocol) ...6.9 X2AP and SCTP ...6.10
LTE/SAE Engineering Overview
iv © Wray Castle Limited LT3600/v1.1
Major Protocols
LT3600/v1.1 © Wray Castle Limited v
Objectives
At the end of this section you will be able to:
discuss the derivation of the major protocols employed by the EPC and highlight the organizations responsible for specifying them
list the set of major protocols defined by the IETF
outline the support the EPC provides for deployment of different versions of IP
describe the IP mobility concept and provide an outline of the functions of MIP, PMIP and DSMIP
discuss the transport layer protocols that are available for use in the EPC
describe the specific features of SCTP that make it suitable for transporting signalling flows over the EPC
outline the basic concepts employed by SCTP
discuss the role of SIP within the EPC and IMS and the supplementary functions performed by SDP and RTP
describe the functions performed by DiffServ within the EPC
outline the role of the Diameter protocol and discuss its use within the EPC
list the set of 3GPP-specific protocols developed or adapted for use in the EPC
describe the role performed by GTP in legacy 3GPP networks and highlight the differences between those versions and GTPv1-U and GTPv2-C
outline the functions performed by the S1 Application Protocol and the X2 Application Protocol
describe the message types and formats employed by the S1 and X2 protocols
LTE/SAE Engineering Overview
vi © Wray Castle Limited LT3600/v1.1
Major Protocols
LT3600/v1.1 © Wray Castle Limited 6.1
IETF 3GPP
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.
Further Reading: 3GPP TS 23.401, 36.300; www.ietf.org
LTE/SAE Engineering Overview
6.2 © Wray Castle Limited LT3600/v1.1
IETF
Underlying Transport
UDP SCTP TCP
IPv4/IPv6 SDP
SIP
RTCP RTP
DiffServ Mobile IP Diameter
IETF Dependence
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
Major Protocols
LT3600/v1.1 © Wray Castle Limited 6.3
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 interface a new IPv6-based EPS with existing IPv4-based legacy packet core networks.
Further Reading: IETF RFCs at www.ietf.org
LTE/SAE Engineering Overview
6.4 © Wray Castle Limited LT3600/v1.1
GTPv2
S1AP
X2AP
3GPP
3GPP Protocols
The Evolved Packet Core employs a number of protocols designed by 3GPP and ETSI (European Telecommunications Standards Institute). 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)
Major Protocols
LT3600/v1.1 © Wray Castle Limited 6.5
Legacy GTP
SGSNs
GTPv0 tunnels
2G PS Core
3G PS Core GTPv1 Tunnels
RNC
GTPvC and
GTP-U tunnels User traffic
flow
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.
Further Reading: 3GPP TS 23.060
LTE/SAE Engineering Overview
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)
Major Protocols
LT3600/v1.1 © Wray Castle Limited 6.7
SCTP IP L2 L1 S1AP
E-RAB management
Initial context transfer
UE context management
Additional E-RAB creation
Mobility functions
Paging
Direct transfer of NAS signalling eNB
S1-MME
MME
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.
S1AP is an evolution of the RANAP protocol employed in 3G networks.
Further Reading: 3GPP TS 36.41x series, 36.413 (S1AP)
LTE/SAE Engineering Overview
6.8 © Wray Castle Limited LT3600/v1.1
S1-MME
MME Pool
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
Major Protocols
LT3600/v1.1 © Wray Castle Limited 6.9
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 signalling protocol employed on the Iur.
Further Reading: 3GPP TS 36.423 and 36.42x series in general
LTE/SAE Engineering Overview
6.10 © Wray Castle Limited LT3600/v1.1
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
LTE/SAE Engineering Overview
© Wray Castle Limited