6 GTP Header
29.0603GPPGeneral Packet Radio Service (GPRS)GPRS Tunnelling Protocol (GTP) across the Gn and Gp interfaceRelease 17TS
The GTP header is a variable length header used for both the GTP-C and the GTP-U protocols. The minimum length of the GTP header is 8 bytes. There are three flags that are used to signal the presence of additional optional fields: the PN flag, the S flag and the E flag. The PN flag is used to signal the presence of N-PDU Numbers. The S flag is used to signal the presence of the GTP Sequence Number field. The E flag is used to signal the presence of the Extension Header field, used to enable future extensions of the GTP header defined in this document, without the need to use another version number. If and only if one or more of these three flags are set, the fields Sequence Number, N-PDU and Extension Header shall be present. The sender shall set all the bits of the unused fields to zero. The receiver shall not evaluate the unused fields.
The GTP-C and the GTP-U use some of the fields in the GTP header differently. The detailed use of such fields is described in the clauses related to GTP-C and to GTP-U.
Always present fields:
– Version field: This field is used to determine the version of the GTP protocol. For the treatment of other versions, see clause 11.1.1, "Different GTP versions". The version number shall be set to "1".
– Protocol Type (PT): This bit is used as a protocol discriminator between GTP (when PT is "1") and GTP’ (when PT is "0"). GTP is described in this document and the GTP’ protocol in 3GPP TS 32.295 [33]. Note that the interpretation of the header fields may be different in GTP’ than in GTP.
– Extension Header flag (E): This flag indicates the presence of a meaningful value of the Next Extension Header field. When it is set to "0", the Next Extension Header field either is not present or, if present, shall not be interpreted. When it is set to "1", the Next Extension Header field is present, and shall be interpreted, as described below in this clause.
– Sequence number flag (S): This flag indicates the presence of a meaningful value of the Sequence Number field. When it is set to "0", the Sequence Number field either is not present or, if present, shall not be interpreted. When it is set to "1", the Sequence Number field is present, and shall be interpreted, as described below in this clause.
– N-PDU Number flag (PN): This flag indicates the presence of a meaningful value of the N-PDU Number field. When it is set to "0", the N-PDU Number field either is not present, or, if present, shall not be interpreted. When it is set to "1", the N-PDU Number field is present, and shall be interpreted, as described below in this clause.
– Message Type: This field indicates the type of GTP message. The valid values of the message type are defined in clause 7.1 for both GTP-C and GTP-U.
– 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 shall be 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 receiving end side of a GTP tunnel locally assigns the TEID value the transmitting side has to use. The TEID values are exchanged between tunnel endpoints using GTP-C (or RANAP, over the Iu) messages.
Optional fields:
– Sequence Number: This field is an optional field in G -PDUs. It is used as a transaction identity for signalling messages having a response message defined for a request message, that is the Sequence Number value is copied from the request to the response message header. In the user plane, an increasing sequence number for T-PDUs is transmitted via GTP-U tunnels, when transmission order must be preserved.
– N-PDU Number: This field is used at the Inter SGSN Routeing Area Update procedure and some inter-system handover procedures (e.g. between 2G and 3G radio access networks). This field is used to co-ordinate the data transmission for acknowledged mode of communication between the MS and the SGSN. The exact meaning of this field depends upon the scenario. (For example, for GSM/GPRS to GSM/GPRS, the SNDCP N-PDU number is present in this field).
– Next Extension Header Type: This field defines the type of Extension Header that follows this field in the GTP‑PDU.
|
Bits |
|||||||||||
|
Octets |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|||
|
1 |
Version |
PT |
(*) |
E |
S |
PN |
|||||
|
2 |
Message Type |
||||||||||
|
3 |
Length (1st Octet) |
||||||||||
|
4 |
Length (2nd Octet) |
||||||||||
|
5 |
Tunnel Endpoint Identifier (1st Octet) |
||||||||||
|
6 |
Tunnel Endpoint Identifier (2nd Octet) |
||||||||||
|
7 |
Tunnel Endpoint Identifier (3rd Octet) |
||||||||||
|
8 |
Tunnel Endpoint Identifier (4th Octet) |
||||||||||
|
9 |
Sequence Number (1st Octet)1) 4) |
||||||||||
|
10 |
Sequence Number (2nd Octet)1) 4) |
||||||||||
|
11 |
N-PDU Number2) 4) |
||||||||||
|
12 |
Next Extension Header Type3) 4) |
||||||||||
NOTE 0: (*) This bit is a spare bit. It shall be sent as "0". The receiver shall not evaluate this bit.
NOTE 1: 1) This field shall only be evaluated when indicated by the S flag set to 1.
NOTE 2: 2) This field shall only be evaluated when indicated by the PN flag set to 1.
NOTE 3: 3) This field shall only be evaluated when indicated by the E flag set to 1.
NOTE 4: 4) This field shall be present if and only if any one or more of the S, PN and E flags are set.
Figure 2: Outline of the GTP Header
The format of GTP Extension Headers is depicted in figure 2. The Extension Header Length field specifies the length of the particular Extension header in 4 octets units. The Next Extension Header Type field specifies the type of any Extension Header that may follow a particular Extension Header. If no such Header follows, then the value of the Next Extension Header Type shall be 0.
|
Octets 1 |
Extension Header Length |
|
|
2 – m |
Extension Header Content |
|
|
m+1 |
Next Extension Header Type (note) |
NOTE: The value of this field is 0 if no other Extension header follows.
Figure 3: Outline of the Extension Header Format
The length of the Extension header shall be defined in a variable length of 4 octets, i.e. m+1 = n*4 octets, where n is a positive integer.
Bits 7 and 8 of the Next Extension Header Type define how the recipient shall handle unknown Extension Types. The recipient of an extension header of unknown type but marked as "comprehension not required" for that recipient shall read the "Next Extension Header Type" field (using the Extension Header Length field to identify its location in the GTP-PDU).
The recipient of an extension header of unknown type but marked as "comprehension required" for that recipient shall:
– If the message with the unknown extension header was a request, send a response message back with CAUSE set to "unknown mandatory extension header".
– Send a Supported Extension Headers Notification to the originator of the GTP PDU.
– Log an error.
Bits 7 and 8 of the Next Extension Header Type have the following meaning:
|
Bits 8 7 |
Meaning |
|
0 0 |
Comprehension of this extension header is not required. An Intermediate Node shall forward it to any Receiver Endpoint |
|
0 1 |
Comprehension of this extension header is not required. An Intermediate Node shall discard the Extension Header Content and not forward it to any Receiver Endpoint. Other extension headers shall be treated independently of this extension header. |
|
1 0 |
Comprehension of this extension header is required by the Endpoint Receiver but not by an Intermediate Node. An Intermediate Node shall forward the whole field to the Endpoint Receiver. |
|
1 1 |
Comprehension of this header type is required by recipient (either Endpoint Receiver or Intermediate Node) |
Figure 4: Definition of bits 7 and 8 of the Extension Header Type
An Endpoint Receiver is the ultimate receiver of the GTP-PDU (e.g. an RNC or the GGSN for the GTP-U plane). An Intermediate Node is a node that handles GTP but is not the ultimate endpoint (e.g. an SGSN for the GTP-U plane traffic between GGSN and RNC).
|
Next Extension Header Field Value |
Type of Extension Header |
|
0000 0000 |
No more extension headers |
|
0000 0001 |
MBMS support indication |
|
0000 0010 |
MS Info Change Reporting support indication |
|
0010 0000 |
Reserved for GTP-U. See 3GPP TS 29.281 [41]. |
|
0100 0000 |
Reserved for GTP-U. See 3GPP TS 29.281 [41]. |
|
1000 0001 |
Reserved for GTP-U. See 3GPP TS 29.281 [41]. |
|
1100 0000 |
PDCP PDU number |
|
1100 0001 |
Suspend Request |
|
1100 0010 |
Suspend Response |
Figure 5: Definition of Extension Header Type
6.1 Extension headers
6.1.1 PDCP PDU Number
This extension header is transmitted, for example, at SRNS relocation time to provide the PDCP sequence number of not yet acknowledged N-PDUs. It is 4 octets long, and therefore the Length field has value 1.
|
Bits |
||||||||||||
|
Octets |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
||||
|
1 |
1 |
|||||||||||
|
2 |
PDCP PDU number |
|||||||||||
|
3 |
PDCP PDU number. |
|||||||||||
|
4 |
Next Extension Header Type (note) |
|||||||||||
NOTE: The value of this field is 0 if no other Extension header follows.
Figure 6: PDCP PDU number Extension Header
6.1.2 Suspend Request
This extension header is transmitted at inter-SGSN handover, when a DTM capable MS has an ongoing circuit call and it moves to a cell that does not support DTM, under the domain of a new 2G SGSN. When the new SGSN receives a "Suspend" message from the BSS, it sends a SGSN context request with this additional extension header to the old SGSN. The old SGSN shall reply with a SGSN context response, including the Extension Header described in clause 6.1.3. The SGSN Context Request message shall not be handled other than for the purpose of implementing the Suspend functionality as described in 3GPP TS 23.060 [4]. The "SGSN context request" message shall not include the "IMSI", "packet-TMSI", "packet TMSI signature" and "MS validated" IEs.
NOTE 1: The "packet TMSI signature" is not available in the BSSGP Suspend message (see clause 10.3.6 of 3GPP TS 48.018 [20]) and hence an SGSN cannot include this IE.
NOTE 2: For an SGSN to MME Suspend Request, the MME cannot suspend the bearers after receving the Suspend Request message from the SGSN, since the GUTI cannot be derived from the P-TMSI and RAI pair, as the P-TMSI Signature is not included in the message. The MME however still replies with an SGSN Context Response, including the Extension Header described in clause 6.1.3 to the SGSN. Suspend procedure on the MME is triggered by the S1 UE Context Release message sent from the eNodeB to the MME. Refer to clause 6.3 and clause 7.4 in 3GPP TS 23.272 [58] for detail.
|
Bits |
||||||||||||
|
Octets |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
||||
|
1 |
1 |
|||||||||||
|
2 |
0xFF |
|||||||||||
|
3 |
0xFF |
|||||||||||
|
4 |
Next Extension Header Type (note) |
|||||||||||
NOTE: The value of this field is 0 if no other Extension header follows.
Figure 7: Suspend Request Extension Header
6.1.3 Suspend Response
When a SGSN receives a SGSN Context Request with the extension header "Suspend Request" described in clause 6.1.2, it shall perform the actions specified in 3GPP TS 23.060 [4] and it shall return a SGSN Context Response with this extension header included. The SGSN Context Response message shall not be handled other than for the purpose of implementing the Suspend functionality as described in 3GPP TS 23.060 [4]. The "SGSN context response" shall not include the "IMSI", "Radio priority SMS", "Radio priority", "packet flow ID", "MM context", "PDP context" and "SGSN Address for control plane" IEs.
|
Bits |
||||||||||||
|
Octets |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
||||
|
1 |
1 |
|||||||||||
|
2 |
0xFF |
|||||||||||
|
3 |
0xFF |
|||||||||||
|
4 |
Next Extension Header Type (note) |
|||||||||||
NOTE: The value of this field is 0 if no other Extension header follows.
Figure 8: Suspend Response Extension Header
6.1.4 MBMS support indication
This Extension Header shall be included by an SGSN supporting MBMS in all Create PDP Context Request messages Update PDP Context Request messages, SGSN Context Request messages and Forward Relocation Response messages.
A GGSNsupporting MBMS receiving this Extension Header in a Create PDP Context Request or in an Update PDP Context Request shall assume the SGSN originating the message supports MBMS in the handling of all subsequent MBMS-related procedures. If this Extension Header is not received in a Create PDP Context Request or in an Update PDP Context Request, then the GGSN shall assume that the SGSN originating the message does not support MBMS in the handling of all subsequent MBMS-related procedures.
An SGSN supporting MBMS receiving this Extension Header in an SGSN Context Request or in a Forward Relocation Response shall assume the SGSN originating the message supports MBMS in the handling of all subsequent MBMS-related procedures. If this Extension Header is not received in a SGSN Context Request or in a Forward Relocation Response, then the receiving SGSN shall deactivate the associated MBMS UE Contexts.
|
Bits |
||||||||||||
|
Octets |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
||||
|
1 |
1 |
|||||||||||
|
2 |
0xFF |
|||||||||||
|
3 |
0xFF |
|||||||||||
|
4 |
Next Extension Header Type (note) |
|||||||||||
NOTE: The value of this field is 0 if no other Extension header follows.
Figure 8A: MBMS support indication Extension Header
6.1.5 MS Info Change Reporting support indication
If the SGSN supports MS Info Change Reporting mechanism and if the SGSN’s operator policy permits reporting of the User Location Information change to the operator of the GGSN, the SGSN shall include this Extension Header in all Create PDP Context Request messages and Update PDP Context Request messages towards the corresponding GGSN. It is 4 octets long, and therefore the Length field has the value 1.
A GGSNsupporting the MS Info Change Reporting meachanism receiving this Extension Header in a Create PDP Context Request or in an Update PDP Context Request shall assume that the SGSN originating the message supports the MS Info Change Reporting meachanism. If this Extension Header is not received by a GGSN in a Create PDP Context Request or in an Update PDP Context Request, then the GGSN shall assume that the SGSN originating the message does not support the MS Info Change Reporting meachanism. The MS Info Change Reporting meachanism is defined in clause 7.5B.1.
|
Bits |
||||||||||||
|
Octets |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
||||
|
1 |
1 |
|||||||||||
|
2 |
0xFF |
|||||||||||
|
3 |
0xFF |
|||||||||||
|
4 |
Next Extension Header Type (note) |
|||||||||||
NOTE: The value of this field is 0 if no other Extension header follows.
Figure 6.1.5/1: MS Info Change Reporting support indication Extension Header