The GPRS Tunneling Protocol includes both the GTP control plane (GTP-C) and the GTP user plane (GTP-U) providing procedures for data transfer. GTP also lists the messages and information elements used by the GTP based charging protocol GTP’, which is defined for the interface between Call Detail Record (CDR) generating functional network elements and Charging Gateway(s) within a PLMN.
There is a many-to-many relationship between SGSNs and GGSNs. A SGSN may provide service to many GGSNs. A single GGSN may be associated with many SGSNs to deliver traffic to a large number of geographically diverse mobile stations.
Functions of GTP
GTP consists of the GTP control plane (GTP-C) and the GTP user plane (GTP-U). Additionally the charging protocol GTP’ is based on GTP functionality.
The main functions of the GTP control plane (GTP-C) include:
- the tunnel management which allows and enable packet data network access for an MS, i.e. GTP-C signaling is used to create, modify and delete GTP tunnels and to transfer GSN capability information between an SGSN and GGSN.
- the path management to detect communication failures at thepath(UDP/IP) providing GTP tunnels between SGSN and GGSN.
- the support of GPRS Mobility Management.
- the optional support of Location Management if a GGSN does not support MAP signaling, i.e. if the GGSN has no Gc interface. In this case a GTP-MAP protocol converter is used and located in a dedicated GSN.
The main functions of the GTP user plane (GTP-U) include:
- the transparent, connection-oriented and unconfirmed transport of user datapackets between an SGSN and GGSN.
- the path management to detect communication failures at the path(UDP/IP) providing GTP tunnels between SGSN and GGSN.
- the support of error indication to indicate errors regarding a certain GTP user plane tunnel.
GTP Tunnels and Tunnel End Point Identifier
The GPRS Tunneling Protocol provides tunnels to forward user data packets between an external packet data network and an MS as well as between different GSNs. GTP also provides tunnels to exchange GTP signaling messages between different GSNs, i.e. there are GTP tunnels for GTP-U and GTP-C message flows.
A GTP tunnel in the GTP-U plane is defined for each PDP Context in the GSN. A GTP tunnel in the GTP-C plane is defined for all PDP Contexts with the same PDP address and APN (for Tunnel Management messages) or for each MS (for messages not related to Tunnel Management).
A GTP tunnel is uniquely identified in each node, i.e. SGSN or GGSN, with a TEID, an IP address and an UDP port number.
The TEID is part of the GTP frame header and used to:
- unambiguously identify a tunnel endpoint in the receiving GTP-U or GTP-C protocol entity,
- identify a PDPcontext,
- de-multiplex traffic incoming from remote tunnel endpoints so that it can be delivered to the user plane entities in a way that allows multiplexing of different users, different packet protocols and different QoS levels.
- forward N-PDUs from the old SGSN to the new SGSN and after an inter-SGSN routing area update.The receiving end side of a GTP tunnel locally assigns the TEID value that the transmitting side has to use, e.g. the TEID is generated by the SGSN and forwarded to the GGSN upon PDP Context Creation and used in subsequent tunneling of user data in downlink direction from the GGSN to the SGSN. The TEID values are assigned and exchanged between tunnel endpoints using GTP-C messages.
GTP Frame Structure
The GTP frame carries either user data (in case of GTP-U) or GTP signaling (in case of GTP-C). The GTP frame header is a variable length header and used for both the GTP-C and the GTP-U protocols. Only some of the fields in the GTP header are used differently by GTP-C and GTP-U.
The GTP header consists of the following fields:
- Version field:This field is used to determine the version of the GTP protocol (V1 for GPRS and V2 for 4G/LTE).
- Protocol Type (PT):This bit is used as a protocol discriminator between GTP (when PT is ‘1’) and GTP’ (when PT is ‘0’).
- Extension Header flag (E): This flag indicates the presence of the Next Extension Header field when it is set to ‘1’.
- Sequence number flag(S): This flag indicates the presence of the Sequence Number field when it is set to ‘1’.
- N-PDU Number flag(PN): This flag is significant only for GTP-U and indicates the presence of the N-PDU Number field when it is set to ‘1’.
- MessageType: This field indicates the type of GTP message.
- Length:This field indicates the length in octets of the payload,i.e.the rest of the packet following the mandatory part of the GTP header (that is the first 8 octets). The Sequence Number, the N-PDU Number or any Extension headers are considered to be part of the payload, i.e. included in the length count.
- Tunnel Endpoint Identifier (TEID): This field unambiguously identifies a tunnel endpoint in the receiving GTP-U or GTP-C protocol entity. The TEID values are exchanged between tunnel endpoints using GTP-C messages.
- Sequence Number: This field is an optional field in G-PDUs. In GTP-C it is used to correlate request and response messages. In GTP-U the sequence number is used to preserve the transmission order of T-PDUs per GTP-U tunnel.
- N-PDU Number: This optional field is used at the Inter SGSN Routing Area Update procedure and some inter-system handover procedures (e.g. between 2G and 3G radio access networks) and used to co-ordinate the data transmission for acknowledged mode of communication between the MS and the SGSN.
- Next Extension Header Type: This optional field defines the type of Extension Header that follows this field in the GTP-PDU.
GTP Procedures
GTP-C Functionality
The GTP control plane (GTP-C) offers signaling procedures to support the following functionality:
- Path management, i.e. the detection of communication failures at the paths (UDP/IP) providing GTP tunnels between SGSN and GGSN, detection of GSN restarts and also version control.
- Tunnel management, i.e. the creation, modification and deletion of GTP tunnels between an SGSN and GGSN.
- GPRS Mobility Management, e.g. to support the GPRS attach procedure or the Inter SGSN Routing Area Update procedure across the Gn interface.
- Optional Location Management,i.e.to handle location information about an MS if a GGSN does not support MAP signaling which means that the GGSN has no Gc interface.
Reliable Delivery of GTP-C Messages
Each path maintains a queue with signaling messages to be sent to the peer. Each message is sent with a sequence number and held in a path list until a response is received. Each path has its own list. The sequence number is unique for each outstanding request message sourced from the same IP/UDP endpoint.
A timer (T3-RESPONSE) is started when a signaling request message is sent. A signaling message request or response has probably been lost if a response has not been received before the timer expires. The request is then retransmitted if the total number of request attempts is less than the retry counter (N3-REQUESTS).
A response message without a matching outstanding request should be considered as a duplicate and is discarded.
Tunnel Management
Five different procedures exist to support GTP Tunnel Management:
- The Create PDP Context Procedure isused by the SGSN to createa PDP context in the GGSN associated to a certain MS, to establish tunnels across the Gn interface for user data and GTP signaling and to negotiate the QoS.
- The Update PDP Context Procedure is used by the SGSN or GGSN mainly to re-negotiate the QoS but also to change the path or to redistribute contexts due to load sharing.
The Delete PDP Context Procedure is used by the SGSN or GGSN to delete or deactivate a PDP context.
- The PDU Notification Procedure is used by the GGSN in case of the Network- Requested PDP Context Activation procedure to notify an SGSN of a data packet coming in from an external PDN
Create PDP Context Procedure
The Create PDP Context Procedure is executed during the GPRS PDP Context Activation procedure of the Session Management layer to create a PDP context in the GGSN associated to a certain MS, to establish a tunnel each for control messages and for user data across the Gn interface, i.e. the GPRS backbone network and also to negotiate the QoS to be applied.
The SGSN sends a Create PDP Context Request (IMSI, Selection Mode, TEID-U, TEID-C, NSAPI, linked NSAPI, Charging Characteristics, Trace Type, PDP Type, PDP Address, APN, Protocol Configuration Options, SGSN Address for control plane, SGSN Address for user data, MSISDN, QoS, TFT) message to the GGSN and marks the PDP context as ‘waiting for response’. In this state the SGSN accepts G- PDUs from the GGSN but does not send these G-PDUs to the MS.
The TEID-U field specifies a downlink Tunnel Endpoint Identifier for user data (G- PDUs) which is chosen by the SGSN. The GGSN includes this Tunnel Endpoint Identifier in the GTP header of all subsequent downlink G-PDUs which are related to the requested PDP context.
The TEID-C field specifies a downlink Tunnel Endpoint Identifier for control plane messages which is chosen by the SGSN. The GGSN includes this Tunnel Endpoint Identifier in the GTP header of all subsequent downlink control plane messages which are related to the requested PDP context. If there is already an TEID-C value assigned for this MS, this field is not present.
The MSISDN of the MS is also passed to the GGSN and can be used when a secure access to a remote application residing on a server is needed.
If the MS requests a dynamic PDP address, then the PDP Address field is left empty. If the MS requests a static PDP Address then the PDP Address field contains the static PDP Address. The Quality of Service Profile information element are the QoS values to be negotiated between the MS and the SGSN at PDP Context activation.
The SGSN includes an SGSN Address for control plane and one for user data. The GGSN stores these SGSN (= IP) Addresses and uses them when sending control messages or G-PDUs on these GTP tunnels to the SGSN for the MS.
The SGSN indicates the origin of the APN using the Selection Mode IE and includes either the MS provided APN, a subscribed APN or an SGSN selected APN in the Create PDP Context Request message.
For contexts created by the Secondary PDP Context Activation Procedure the SGSN includes the linked NSAPI indicating the NSAPI assigned to any one of the already activated PDP contexts for this PDP address and APN, and the TFT used for packet filtering in the GGSN. When using the Secondary PDP Context Activation Procedure, the Selection mode, IMSI, MSISDN, PDP Address, Access Point Name and Protocol Configuration Options information elements are not included in the Create PDP Context Request message.
If Protocol Configuration Options (PCO) have been included in the associated Activate PDP Context Request sent by the MS, the SGSN transparently passes them to the GGSN in the Create PDP Context Request message.
The SGSN selects the target GGSN based on the APN. The APN is a logical name that has to be converted to an IP-address. The conversion is done by a DNS query to a DNS server located in the GPRS backbone. The IP address returned in the DNS response is then stored in the “GGSN Address in Use” field in the PDP context and used during the entire lifetime of the PDP context.
The IMSI information element together with the NSAPI information element uniquely identifies the PDP context to be created.
The SGSN determines Charging Characteristics from the Subscribed Charging Characteristics and/or PDP Context Charging.
The SGSN includes Trace Reference, Trace Type, Trigger Id, and OMC Identity in the message if GGSN trace is activated.
The GGSN responds with a Create PDP Context Response (Cause, Reordering required, TEID-U, TEID-C, Charging ID, PDP Type, PDP Address, Protocol Configuration Options, GGSN Address for control plane, GGSN Address for user data, QoS). The Cause value in the Create PDP Context Response indicates if a PDP context has been successfully created in the GGSN or not. A PDP context has not been created in the GGSN if the Cause differs from ‘Request accepted’. If the Cause value indicates ‘Request Accepted’, the SGSN activates the PDP context and may start to forward T-PDUs to/from the MS from/to the external data network.
The TEID-U and TEID-C fields chosen by the GGSN specify uplink Tunnel Endpoint Identifiers for user data or control messages respectively. The GGSN includes the TEID-U or TEID-C in the GTP header of all subsequent downlink G-PDUs or control messages respectively which are related to the created PDP context.
The GGSN includes a GGSN Address for control plane and one for user traffic which the SGSN stores and uses when sending control messages or G-PDUs on the corresponding GTP tunnels to the GGSN.
If the MS requested a dynamic PDP address the PDP address IE contains the dynamic PDP Address allocated by the GGSN. If the MS requested a static PDP address the PDP address IE is not included.
The QoS values supplied in the Create PDP Context Request may be negotiated downwards by the GGSN.
The GGSN starts to forward T-PDUs after the Create PDP Context Response has been sent. The Reordering Required value indicates whether the SGSN/GGSN shall perform reordering or not (the end user protocol benefits from packet in sequence delivery). The Charging ID is generated by the GGSN and used to identify all charging records produced in SGSN(s) and the GGSN for this PDP context.
If the Create PDP Context procedure is not successfully completed, the SGSN repeats the Create PDP Context Request message to the next GGSN address in the list of IP addresses, if there is one. If the list is exhausted the activation procedure fails.
Update PDP Context Procedure
SGSN-Initiated Update PDP Context Procedure
The Update PDP Context Procedure is executed during the GPRS Inter SGSN Routing Update procedure or during the PDP Context Modification procedure.
The Update PDP Context Procedure is used to:
- change the QoS and/or the path.
- redistribute contexts due to loadsharing.
- change the GTP version of atunnel to a GGSN.
The SGSN sends an Update PDP Context Request (IMSI, TEID-U, TEID-C, NSAPI, Trace Type, SGSN Address for control plane, SGSN Address for user data, QoS, TFT) message to the GGSN.
The TEID-U and TEID-C fields chosen by the SGSN specify downlink Tunnel Endpoint Identifiers for user data or control messages resp. The GGSN includes the TEID-U or TEID-C in the GTP header of all subsequent downlink G-PDUs or control messages respectively which are related to the updated PDP context.
The NSAPI information element together with the Tunnel Endpoint Identifier in the GTP header unambiguously identifies a PDP Context in the GGSN. The SGSN includes Trace Type if GGSN trace is activated.
The SGSN includes an SGSN Address for control plane and one for user data. The GGSN stores these SGSN Addresses and uses them when sending control messages or G-PDUs on the corresponding GTP tunnels to the SGSN for the MS.
In case of the Inter SGSN Routing Update procedure the QoS IE includes the QoS negotiated between the MS and SGSN at the related PDP Context activation or in case of the PDP Context Modification procedure the QoS IE includes the modified QoS.
In case there exist already PDP contexts using the same PDP address as the updated PDP context a Traffic Flow Template (TFT) is included in the Update PDP Context Request used to distinguish between different user traffic flows.
The GGSN responds with an Update PDP Context Response (Cause, TEID-U, TEID-C, Charging ID, GGSN Address for control plane, GGSN Address for user data, QoS). If the SGSN receives an Update PDP Context Response with a Cause value other than ‘Request accepted’, it aborts the update of the PDP context.
The TEID-U and TEID-C fields chosen by the GGSN specify uplink Tunnel Endpoint Identifiers for user data or control messages respectively. The GGSN includes the TEID-U or TEID-C in the GTP header of all subsequent downlink G-PDUs or control messages respectively which are related to the updated PDP context.
The QoS values supplied in the Update PDP Context Request may be negotiated downwards by the GGSN.
The GGSN includes a GGSN Address for control plane and one for user traffic which the SGSN stores and uses when sending control messages or G-PDUs on the corresponding GTP tunnels to the GGSN. The Charging ID is generated by the GGSN and used to identify all charging records produced in SGSN(s) and the GGSN for this PDP context. If an inter SGSN routing area update occurs, it is transferred to the new SGSN as part of each active PDP context.
GGSN-Initiated Update PDP Context Procedure
An Update PDP Context Request (NSAPI, PDP address, QoS) may also be sent from a GGSN to a SGSN to:
- re-negotiate the QoS of a PDP context.
- provide a PDP address to the SGSN (and MS) in case of non-transparent access.
The Quality of Service Profile IE includes the QoS requested by the GGSN. The PDP Address IE contains a valid IPv4 or IPv6 address.
The NSAPI information element together with the Tunnel Endpoint Identifier in the GTP header unambiguously identifies a PDP Context in the SGSN.
The SGSN responds with an Update PDP Context Response (Cause, QoS). If the GGSN receives an Update PDP Context Response with a Cause value other than ‘Request accepted’, it aborts the update of the PDP context if the associated Update PDP Context Request was sent only to re-negotiate the QoS of a PDP context. Furthermore if the associated Update PDP Context Request included an ‘PDP Address’ information element the GGSN deletes the PDP context using the Delete PDP Context procedure and notifies the Operation and Maintenance network element.
The QoS values supplied in the Update PDP Context Request may be negotiated downwards by the SGSN. The negotiated values or the original value from GGSN is inserted in the Quality of Service Profile information element.
Delete PDP Context Procedure
The Delete PDP Context Procedure is executed during the GPRS Detach procedure or the GPRS PDP Context Deactivation procedure to delete or deactivate a PDP context. The Delete PDP Context Procedure can be initialized by both SGSN and GGSN.
A GSN shall be prepared to receive a Delete PDP Context Request at any time and has to always reply regardless if the PDP context exists or not. If any collision occurs, the Delete PDP Context Request message takes precedence over any other Tunnel Management message.
Note: When an MS detaches, all ongoing GTP control plane procedures related to this MS will be aborted. The SGSN sends Delete PDP Context Request messages for all active PDP contexts to the peer GGSNs.
A Delete PDP Context Request (Teardown Indicator, NSAPI) message is used to deactivate an activated PDP Context or an activated set of PDP contexts associated to a PDP address which is assigned to a single MS.
The Teardown Indicator is used to indicate whether all PDP contexts that share the PDP address with the PDP context identified in the request should also be deactivated. This triggers the deletion of all the information kept for a MS at a GSN, if no other PDP contexts associated to other PDP addresses are active on the GSN. If the Teardown Indicator IE value is set to ‘1’, then all PDP contexts that share the same PDP address with the PDP context identified by the NSAPI included in the Delete PDP Context Request Message are torn down. If the Teardown Indicator IE value is ‘0’, then only the PDP context identified by the NSAPI included in the Delete PDP context Request is torn down.
The Delete PDP Context Response (Cause) message is sent in response to a Delete PDP Context Request message.
If a GSN receives a Delete PDP Context Request message for a non existing PDP context, it will send back to the source of the message a Delete PDP Context Response message with cause value “Non existent”.
If the received Delete PDP Context Response contains a cause value other than ‘Request accepted’ and ‘Non Existent’, the PDP context is kept active.
GTP User Plane Procedure
The GTP user plane (GTP-U) offers the following procedures to support user data transfer:
- The User data transfer itself is used to transport T-PDUs between different GSNs.
- The Error Indication Procedure is used by the SGSN or GGSN to notify the peer GSN in case the SGSN or GGSN received a G-PDU destined for a non-active PDP context.
- The Version Control Procedures are used by a SGSN or GGSN to indicate to the peer GSN the GTP version in use (see Path Management).
- The Echo procedure is used to perform path failure detection and recovery indication (see Path Management).
User Data Transfer
The GTP-U plane offers transparent, connection-oriented and unacknowledged user data transfer services between a pair of GTP-U tunnel endpoints. The tunnel establishment and tunnel set-up between two GTP-U endpoints is done via control plane procedures defined by GTP-C.
Multiplexing
External PDN packets, i.e. T-PDUs, are transferred between GSN pairs encapsulated in G-PDUs. A G-PDU is a packet consisting of a GTP-U header and a T-PDU.
The Path Protocol defines the path and the Tunnel Endpoint Identifier in the GTP-U header defines the tunnel. The Tunnel Endpoint Identifier indicates which tunnel a particular T-PDU belongs to. The Tunnel Endpoint Identifier value to be used is negotiated for instance during the GTP-C plane procedure “Create PDP Context”. Several tunnels may use the same path. The TEID in the GTP-U header is used to de-multiplex traffic incoming from remote tunnel endpoints so that it is delivered to the user plane entities in a way that allows multiplexing of different users, different packet protocols and different QoS levels. There is one GTP-U protocol entity per IP address.
Reordering using Sequence Numbers
This functionality is provided only when the S bit is set to 1 in the GTP header. The GTP-U protocol entity must reorder out of sequence T-PDUs when in sequence delivery is required. The user plane entity may provide sequence numbers together with T-PDUs to the GTP-U layer to be transmitted in sequence or alternatively the GTP-U protocol entity at the GGSN autonomously generates the sequence numbers. The sequence number is handled on a per GTP-U Tunnel (that is TEID) basis. The sending GGSN uses 0 for the value of the Sequence Number of the first G-PDU in a tunnel and increments the Sequence Number for each following G-PDU. The value wraps to zero after 65535. The receiving GGSN sets the content of a counter to zero during the PDP context activation. When the receiving GGSN receives a valid G-PDU, it increments this counter by one. This counter wraps to zero after 65535. It defines the ‘Expected Sequence Number’. Based on the received and Expected Sequence Number values, a maximum number of valid received frames and a maximum elapsed time, the receiving GGSN decides whether a G-PDU is assumed to be lost or duplicated and whether it has to be discarded.
For GTP-U signaling messages having a response message defined for a request message, one of the continuous Sequence Numbers from 0 to 65535 is assigned and copied from the signaling request message to the response message for reliable delivery of signaling messages.
Fragmentation
T-PDUs exceeding the maximum size (1500 octets) are fragmented, discarded or rejected by the SGSN/GGSN. The decision if the T-PDUs shall be fragmented or discarded is dependent on the external packet data network protocol.
Note: If any fragment is lost, the whole packet is discarded.
GTP User Plane Procedure
The GTP user plane (GTP-U) offers the following procedures to support user data transfer:
- The User data transfer itself is used to transport T-PDUs between different GSNs.
- The Error Indication Procedure is used by the SGSN or GGSN to notify the peer GSN in case the SGSN or GGSN received a G-PDU destined for a non-active PDP context.
- The Version Control Procedures are used by a SGSN or GGSN to indicate to the peer GSN the GTP version in use (see Path Management).
- The Echo procedure is used to perform path failure detection and recovery indication (see Path Management).
Although more than 20years working on Mobile Telecommunications – Core Network. Always wanting to learn and try new things.