Codepoints Ø
Differentiated Services Codepoint (DSCP) RFC 2474
Ø
IP Precedence IP Precedence 111 Network Control 110 Internetwork Control
: :
001 Priority 000 Routine
ToS Field ToS Field 1000 Min. delay 0100 Max. throughout
0010 Max. reliability 0001 Min. cost 0000 Normal
3.10
LTE Evolved Packet Core Network
3GPP
3GPP Diameter
Apps
GTP
S1AP/
X2AP
RRC
EMM/ESM
3GPP-speci
3GPP-specific fic ProtocolsProtocols
The EPS employs a number of protocols that were developed by 3GPP or ETSI (European Telecommunications Standards Institute). Non-IETF protocols were developed for situations in which an Internet-standard protocol didn’t exist or in which it was necessary to maintain continuity with a legacy 3GPP/ETSI protocol.
The main 3GPP-specific protocols employed in the EPS include:
■ 3GPP-specified Diameter Applications, which are designed to operate over standard Diameter Base Protocol links between core network database functions. Examples include the 3GPP Gx (PCRF to PCEF), S6a (HSS to MME), S6d (HSS to S4 SGSN) and S13 (MME to EIR) applications.
■ GTP (GPRS Tunnelling Protocol), which has been used to support IP mobility in PS core networks since 2.5G GPRS. This protocol has been updated and extended to support LTE functionality that has mainly been inherited from the SS7 MAP protocol
■ S1AP and X2AP (X2 Application Part) protocols provide signalling functionality over the S1 (eNB-MME) and X2 (eNB-eNB) interfaces
■ RRC, which provides signalling and control plane functions over the LTE air interface. Each generation of ETSI/3GPP network has had its own version of RRC and the LTE version has been created to specifically support the requirements of the OFDMA/SC-FDMA air interface environment
■ EMM and ESM, which are sub-protocols of the LTE layer 3 NAS control plane that operates between UEs and their controlling MME
Some of these protocols are discussed in more detail in the following pages, more details on the others can be found by following the further reading references at the foot of the page.
Further Reading: 3GPP TS25.331, 29.275 (GTPv2-C), 29.281 (GTPv1-U), 36.413 (S1AP), 36.423 (X2AP), 36.331 (RRC), 24.301 (NAS)
Further Reading: 3GPP TS25.331, 29.275 (GTPv2-C), 29.281 (GTPv1-U), 36.413 (S1AP), 36.423 (X2AP), 36.331 (RRC), 24.301 (NAS)
LT3604/v4.0 © Wray Castle Limited 3.11
Major Protocols
Base protocol – RFC 3588
Supports accounting messages and AVPs (parameters) Extensible via vendor specific of applications for example,
– to support authentication and authorization – to support for IMS Cx/Dx and Sh/Dh interfaces Transported by TCP or SCTP
Diameter session
A related set of events devoted to a particular activity. For example a set of all Diameter messages, with the same Session-Id between, MME and HSS from the moment a User registers to the moment the user deregisters or is deregistered by the HSS.
A functional entity that sits at the edge of a network and performs access control Any Diameter node can send or receive Requests
(asynchronously) and Responses, i.e. acts as client
or server from a signalling perspective A functional entity that performs authentication and authorization
Diameter in the EPC Diameter in the EPC
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 provided 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.
Diameter was designed to be a flexible and extensible peer-to-peer protocol but is often deployed in a client-server arrangement. Diameter is a peer-to-peer protocol in the sense that any host that supports Diameter can send Diameter request messages.
From a signalling point of view a Diameter client is one that sends a request message and a server is one that provides a response to a request.
From a functional point of view LTE devices such as the MME, PDN-GW and legacy SGSN are generally considered to be Diameter clients and authentication and authorization database devices such as the PCRF, HSS or EIR are considered to be Diameter servers. In all cases, either associated device may send requests, i.e. act as a client from a signalling perspective and respond to requests, i.e. act as server from a signalling perspective, depending upon the requirements of the signalling protocol being served.
In the example, the Diameter client is an MME, which may send an Access Request message to an HSS configured as a Diameter server that provides authentication and authorization services.
A Diameter session is considered to be a related set of events devoted to a particular activity. For example, a session may be the set of messages exchanged between an MME and the HSS from the moment a user registers to the moment a user deregisters or is deregistered by the HSS. All Diameter messages belonging to the same session contain the same Session-ID value.
Diameter defines a Base protocol (RFC 3588), which all Diameter implementations must support. The Base protocol includes the support of messages and parameters, known as AVPs (Attribute Value Pairs), related to accounting and Diameter control procedures. Diameter also allows for extensibility via applications that define their own messages and AVPs based on the application’s characteristics. For example, authentication and authorization mechanisms may vary among applications. Therefore, the Diameter base protocol does not define command codes or AVPs specific to authentication and authorization.
Further Reading: IETF RFC 3588
3.12
LTE Evolved Packet Core Network
Diameter Base Protocol (RFC 3588) Diameter Base Protocol (RFC 3588)
Diameter Base Protocol Cx, Dx Application, 3GPP 29.228, 29.229
Command-Name
Diameter functionality is extensible through the definition of vendor-specific applications (applications are in fact protocols). A range of vendor-specific applications currently approved by the IETF are shown in the diagram, together with their commands and command codes. The commands for the Base protocol are also shown.
As an example, 3GPP required additional functionality for Diameter on IMS interfaces including Cx, Dx and Sh and on LTE interfaces including S6a, S6d and S13. In this case the vendor, 3GPP, applied to the IETF for command codes and AVPs for these interfaces. These were approved and the resulting command codes are shown on the IANA (Internet Assigned Names and Numbers Authority) website on the Diameter AVP Page.
Every message sent that relates to a particular application carries the vendor name, vendor identity and application id.
A given network element may use command codes from different applications or the Base protocol as required. For example, a PDN-GW may be required to provide accounting data to a charging function, in which case it may use the Accounting Request and Accounting Answer commands from the Base protocol. An MME may need to request subscriber authentication vectors from an HSS, which it would achieve over the S6a interface using the Authentication Information request/answer and Insert Subscriber data request/answer. The S6a and S13 Diameter applications can be viewed as versions of the legacy MAP (Mobile Application Part) signalling messages that have been adapted for transport via Diameter.
Further Reading: IANA Diameter parameters: www.iana.org/assignments/aaa-parameters/aaa-parameters.xml, 3GPP TS29.272 (S6a/S13 Application)
LT3604/v4.0 © Wray Castle Limited 3.13
Major Protocols
Diameter Operation Diameter Operation
Once a transport layer connection has been established between Diameter peers, using TCP or SCTP (but never UDP), they negotiate the parameters of the service that follow.
A CER Request) is sent by the initiating peer and a CEA Answer) is returned. This message exchange allows each peer to discover the other’s identity and its
capabilities (protocol version number, supported Diameter applications, security mechanisms, etc).
If the required application is supported by both peers, the connection can continue.
Security may be invoked at this stage, using TLS or IPsec to encrypt any further messages exchanged.
The Diameter protocol provides an inactivity timer, which is started after each message is received. If the inactivity timer expires the peers will exchange keep-alives in the form of Device-Watchdog-Request/
Answer messages.
Diameter connections are terminated by the exchange of DPR and DPA (Disconnect-Peer-Request/
Answer) messages. The TCP or SCTP transport connection may then also be terminated.
Although the terminology used describes connected Diameter devices as ‘peers’ it is also possible to use Diameter in client-server mode. This is the method most commonly employed in the EPS.
Further Reading: IETF RFC3588; 3GPP TS 23.401
Peer A Peer B
CER
CEA
Optional TLS or IPsec establishment Connection Establishment
Application Data Exchange Device Watchdog Exchange
Connection Termination
3.14
LTE Evolved Packet Core Network
Legacy GTP Legacy GTP
GTP was srcinally 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 SGSNs
GGSN
2G PS core GTPv0 Tunnels
User traffic flow
RNC
3G PS core SGSN GGSN
User traffic flow
GTP-U Tunnel
GTP-C and GTP-U tunnels
LT3604/v4.0 © Wray Castle Limited 3.15
Radio Bearer GTP Tunnel GTP Tunnel
E-RAB
Zero or more Extension Headers One T-PDUs 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)
3.16
LTE Evolved Packet Core Network
GTPv2-C Packet Header GTPv2-C Packet Header
The format of the GTPv2-C packet header is shown in the diagram.
The ‘P’ and ‘T’ fields relate to optional functions and operate as boolean flags (‘1’ equals ‘true’ and ‘0’
equals ‘false’).
The ‘P’ field shows whether this message contains instructions related to the ‘piggybacking’ of EPS Bearers. Piggybacking, which is described in Annex F of TS 23.401, is the process whereby one or more dedicated bearers can be established on Attach during the creation of the default bearer.
The ‘T’ field indicates whether the TEID field is present in the header. A TEID may not be present for all message types; it is only required for messages that impact directly on tunnel management, handover and some other U-plane related functions.
Further Reading: 3GPP TS 23.401, 29.274 (GTPv2-C)
Message Type
Zero or more Information Elements P
LT3604/v4.0 © Wray Castle Limited 3.17
Major Protocols
GTPv2-C Message Types GTPv2-C Message Types
GTPv2-C supports messages types that perform seven main functions:
■ Path Management
■ Tunnel Management
■ Mobility Management
■ CS Fallback and SR-VCC
■ Non-3GPP Access
■ Restoration and Recovery
■ Trace Management
GTPv2-C has inherited all of the path and tunnel management functions performed by legacy versions of GTP/GTP-C, but it has also inherited mobility management functions that were previously handled by the SS7 MAP protocol in legacy packet core networks.
Further Reading: 29.274 (GTPv2-C)
3.18
LTE Evolved Packet Core Network
GTPv1-U Packet Header GTPv1-U Packet Header
The format of the GTPv1-U packet header is shown in the diagram.
The ‘PT’ field indicates the Protocol Type as either GTP (as used in PS core networks) or GTP’
(pronounced ‘GTP Prime’, as used on Charging interfaces).
The ‘E’ field shows whether this message contains any additional Extension Headers, which will occupy the first part of the payload section if they exist.
Only two Extension Header type are currently supported.
The UDP Port header can be appended to an Error Indication and carries the UDP Port Number of the G-PDU that triggered the error. The other extension header type carries the PDCP Sequence Number assigned to the unit of user data on the air interface; this may be sent during handovers.
The ‘S’ field shows how to handle the Sequence Number field. If S bit equals 0 then the field is either not present, or is present but does not contain a meaningful value. If the S bit equals 1 then the field is present and does contain a meaningful value. The Sequence Number is only required for connections that need to preserve transmission order.
The ‘PN’ bit indicates the presence or otherwise of an N-PDU Number field. The N-PDU Number is used to indicate the order of packets transferred between SGSNs during ‘Inter SGSN routing’ activities.
A T-PDU (Transport Protocol Data Unit) is an encapsulated user data packet which is being transferred along the GTP tunnel between a UE and a PDN-GW.
Further Reading: 3GPP TS 23.401; 29.281 (GTPv1-U)
Message Type
Zero or more Extension Headers Zero or more T-PDUs
LT3604/v4.0 © Wray Castle Limited 3.19
Major Protocols
GTPv1-U Message Types GTPv1-U Message Types
GTPv1-U supports a limited set of message types.
GTP-U Signalling message types are:
■ Echo Request
■ Echo Response
■ Error Indication
■ Supported Extension Headers Notification
■ End Marker
User traffic, encapsulated into a T-PDU, is carried in a G-PDU (GTP Protocol Data Unit) packet. If no additional information is being carried along with the T-PDU, the G-PDU message header may only contain eight bytes of data (version, flags, message type, length, TEID).
Further Reading: 3GPP TS 23.401; 29.281 (GTP v1-U)
GTPv1-U Message Types
GTP-U GTP-U Signalling Signalling
User User Traffic Traffic
Echo request/response Error Indication Supported Extension Headers Notification End Marker
G-PDU
3.20
LTE Evolved Packet Core Network
S1AP S1AP
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 management, i.e. setting up, modifying and releasing bearers under instruction from an MME. It also performs initial context transfer to establish an S1 UE context in the eNB on Initial Attach or handover 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) S1-MME
MME
eNB
IP L2 S1AP S1AP
SCTP
L1
E-RAB management initial context transfer UE context management additional E-RAB creation mobility functions paging
direct transfer of NAS signalling
LT3604/v4.0 © Wray Castle Limited 3.21 MessageTransfer Transfer
Uplink/
S1AP protocol has been designed to perform the following functions:
■ E-RAB management
■ Initial Context Transfer
■ UE Capability Info Indication
■ Mobility Functions for UEs
■ Paging
eNB and MME Configuration Update
■ NAS Signalling transport
■ S1 UE context Release
■ UE Context Modification
■ RIM (RAN Information Management)
■ Configuration Transfer
■ LPPa (LTE Position Protocol Annex A) Message Transfer
The functions are performed by employing the various EP (Elementary Procedure) message types shown in the diagram.
Further Reading: 3GPP TS36.413:7
3.22
LTE Evolved Packet Core Network
To support UE mobility
To support the session management procedures that
establish and maintain IP connectivity between the UE
and a PDN-GW.
NAS – Non Access Stratum
ESM – EPS Session Management EMM – EPS Mobility Management
NAS Functions and Procedures NAS Functions and Procedures
The EPS NAS offers the highest stratum of signalling and control between a UE and an MME.
The main functions performed by the NAS are support of UE mobility and support of the session management procedures that establish and maintain IP connectivity between the UE and a PDN-GW.
Integrity Protection and Ciphering are offered by the EPS NAS as a means of securing signalling transaction between the UE and an MME.
NAS functions are performed by invoking a specific EP (Elementary Procedure). EPs exist to perform functions that support mobility and session management.
Sets of EPs have been defined that relate to EMM, which perform Attach, security and location update functions, and others have been defined that relate to ESM, which perform bearer management and resource allocation functions.
LT3604/v4.0 © Wray Castle Limited 3.23
Activate Default EPS Bearer Context Request Activate Default EPS Bearer Context Accept Activate Default EPS Bearer Context Reject Activate Dedicated EPS Bearer Context Request Activate Dedicated EPS Bearer Context Accept Activate Dedicated EPS Bearer Context Reject
Modify EPS Bearer Context Request Modify EPS Bearer Context Accept Modify EPS Bearer Context Reject Deactivate EPS Bearer Context Request Deactivate EPS Bearer Context Accept PDN Connectivity Request
Message Type codes are used to identify the type of transaction being performed by a NAS message.
Message Type codes starting with 01 relate to EMM functions whilst codes starting with 11 relate to ESM messages.
Further Reading: 3GPP TS24.301:9.8
3.24