5 GTP Header for Control Plane
29.2743GPP3GPP Evolved Packet System (EPS)Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C)Release 18Stage 3TS
5.1 General format
Control Plane GTP uses a variable length header. Control Plane GTP header length shall be a multiple of 4 octets. Figure 5.1-1 illustrates the format of the GTPv2-C Header.
|
Bits |
|||||||||
|
Octets |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
|
1 |
Version |
P |
T |
Spare |
Spare |
Spare |
|||
|
2 |
Message Type |
||||||||
|
3 |
Message Length (1st Octet) |
||||||||
|
4 |
Message Length (2nd Octet) |
||||||||
|
m to k(m+3) |
If T flag is set to 1, then TEID shall be placed into octets 5-8. Otherwise, TEID field is not present at all. |
||||||||
|
n to (n+2) |
Sequence Number |
||||||||
|
(n+3) |
Spare |
||||||||
Figure 5.1-1: General format of GTPv2 Header for Control Plane
Where:
– if T = 0, TEID field is not present, k = 0, m = 0 and n = 5;
– if T = 1, TEID field is present, k = 1, m = 5 and n = 9.
The usage of GTPv2-C header across the EPC specific interfaces is defined in the clause 5.5 "Usage of the GTPv2-C Header". Octet 1 bits shall be coded as follows:
– Bits 6-8 represent the Version field.
– Bit 5 represents the Piggybacking flag (P).
– Bit 4 represents the TEID flag (T).
– Bits 3-1 are spare, the sender shall set them to "0" and the receiving entity shall ignore them.
5.2 Control Plane GTP Extension Header
The legacy Extension Header mechanism is not used for the GTP version 2 control plane (GTPv2-C). Future extensions will be implemented by adding Information Elements in the message body if new parameters are needed.
5.3 GTP-C header for Echo and Version Not Supported Indication messages
The GTPv2-C message header for the Echo Request, Echo Response and Version Not Supported Indication messages shall not contain the TEID field, but shall contain the Sequence Number fields, followed by one spare octet as depicted in figure 5.3-1. The spare bits shall be set to zero by the sender and ignored by the receiver. For the Version Not Supported Indication message header, the Sequence Number may be set to any number and shall be ignored by the receiver.
|
Bits |
|||||||||
|
Octets |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
|
1 |
Version |
P |
T=0 |
Spare |
Spare |
Spare |
|||
|
2 |
Message Type |
||||||||
|
3 |
Message Length (1st Octet) |
||||||||
|
4 |
Message Length (2nd Octet) |
||||||||
|
5 |
Sequence Number (1st Octet) |
||||||||
|
6 |
Sequence Number (2nd Octet) |
||||||||
|
7 |
Sequence Number (3rd Octet) |
||||||||
|
8 |
Spare |
||||||||
Figure 5.3-1: The format of Echo and Version Not Supported Indication messages Header
5.4 EPC specific GTP-C header
Apart from the Echo Request, Echo Response and Version Not Supported Indication messages, the GTP-C message header shall contain the TEID and Sequence Number fields followed by one spare octet. A typical GTP-C header is depicted in figure 5.4-1. The spare bits shall be set to zero by the sender and ignored by the receiver.
|
Bits |
|||||||||
|
Octets |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
|
1 |
Version |
P |
T=1 |
MP |
Spare |
Spare |
|||
|
2 |
Message Type |
||||||||
|
3 |
Message Length (1st Octet) |
||||||||
|
4 |
Message 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) |
||||||||
|
10 |
Sequence Number (2nd Octet) |
||||||||
|
11 |
Sequence Number (3rd Octet) |
||||||||
|
12 |
Message Priority |
Spare |
|||||||
Figure 5.4-1: The format of EPC specific GTPv2 Control Plane message Header
5.5 Usage of the GTPv2-C Header
5.5.1 General
The format of the GTPv2-C header is specified in clause 5.1 "General format". The usage of the GTP-C header across e.g. S101/S121 (3GPP TS 29.276 [14]) and Sv (3GPP TS 29.280 [15]) interfaces are defined in their respective specifications.
The usage of the GTPv2-C header for EPC specific interfaces shall be as defined below.
The first octet of the header shall be used is the following way:
– Bits 8 to 6, which represent the GTP-C version, shall be set to decimal 2 ("010").
– Bit 5 represents a "P" flag. If the "P" flag is set to "0", no piggybacked message shall be present. If the "P" flag is set to "1", then another GTPv2-C message with its own header and body shall be present at the end of the current message.
When present, a piggybacked message shall have its "P" flag set to "0" in its own header. If a Create Session Response message (as part of EUTRAN initial attach, a Handover from Trusted or Untrusted Non-3GPP IP Access to E-UTRAN (see clauses 8.6 and 16.11 of 3GPP TS 23.402 [45]) or UE-requested PDN connectivity procedure) has the "P" flag set to "1", then a single Create Bearer Request message shall be present as the piggybacked message. As a response to the Create Bearer Request message, if the Create Bearer Response has the "P" flag set to "1", then a single Modify Bearer Request (as part of EUTRAN initial attach, a Handover from Trusted or Untrusted Non-3GPP IP Access to E-UTRAN (see clauses 8.6 and 16.11 of 3GPP TS 23.402 [45]) or UE-requested PDN connectivity procedure) shall be present as the piggybacked message. A Create Bearer Response with "P" flag set to "1" shall not be sent unless a Create Session Response with "P" flag set to "1" has been received for the same procedure. Apart from Create Session Response and Create Bearer Response messages, all the EPC specific messages shall have the "P" flag set to "0".
– Bit 4 represents a "T" flag, which indicates if TEID field is present in the GTP-C header or not. If the "T" flag is set to 0, then the TEID field shall not be present in the GTP-C header. If the "T" flag is set to 1, then the TEID field shall immediately follow the Length field, in octets 5 to 8. Apart from the Echo Request, Echo Response and Version Not Supported Indication messages, in all EPC specific messages the value of the "T" flag shall be set to "1".
– Bit 3 represents a "MP" flag. If the "MP" flag is set to "1", then bits 8 to 5 of octet 12 shall indicate the message priority.
– Bit 2 is a spare bit. The sending entity shall set it to "0" and the receiving entity shall ignore it.
– Bit 1 is a spare bit. The sending entity shall set it to "0" and the receiving entity shall ignore it.
The usage of the fields in octets 2 – n of the header shall be as specified below.
– Octet 2 represents the Message type field, which shall be set to the unique value for each type of control plane message. Message type values are specified in Table 6.1-1 "Message types for GTPv2".
– Octets 3 to 4 represent the Message Length field. This field shall indicate the length of the message in octets excluding the mandatory part of the GTP-C header (the first 4 octets). The TEID (if present) and the Sequence Number shall be included in the length count. The format of the Length field of information elements is specified in clause 8.2 "Information Element Format".
– A piggybacked initial message and the preceding triggered response message present in the common IP/UDP packet shall have their own length and sequence number in their respective GTP-C headers. The overall length of the IP/UDP packet shall indicate the total length of the two GTP-C messages.
– For EPC specific interfaces, T=1, and therefore octets 5 to 8 represent the Tunnel Endpoint Identifier (TEID) field. This field shall unambiguously identify a tunnel endpoint in the receiving GTP-C entity. The Tunnel Endpoint Identifier is set by the sending entity in the GTP header of all control plane messages to the TEID value provided by the corresponding receiving entity (see clause 4.1). If a peer’s TEID is not available the TEID field shall be present in a GTPv2-C header, but its value shall be set to "0", as specified in clause 5.5.2 "Conditions for sending TEID=0 in GTPv2-C header".
NOTE: The TEID in the GTP header of a Triggered (or Triggered Reply) message is set to the TEID value provided by the corresponding receiving entity regardless of whether the source IP address of the Initial (or Triggered) message and the IP Destination Address provided by the receiving entity for subsequent control plane Initial messages (see clause 4.2.2.1) are the same or not.
– Octets 9 to 11 represent GTP Sequence Number field.
– Bits 8 to 5 of octet 12 shall indicate the relative priority of the GTP-C message, if the "MP" flag is set to 1 in Octet 1. It shall be encoded as the binary value of the Message Priority and it may take any value between 0 and 15, where 0 corresponds to the highest priority and 15 the lowest priority.
If the "MP" flag is set to "0" in Octet 1, bits 8 to 5 of octet 12 shall be set to "0" by the sending entity and ignored by the receiving entity.
– Bits 4 to 1 of octet 12 are spare bits. The sending entity shall set them to "0" and the receiving entity shall ignore them.
5.5.2 Conditions for sending TEID=0 in GTPv2-C header
If a peer’s TEID is not available, the TEID field still shall be present in the header and its value shall be set to "0" in the following messages:
– Create Session Request message on S2a/S2b/S5/S8
– Create Session Request message on S4/S11, if for a given UE, the SGSN/MME has not yet obtained the Control TEID of the SGW.
– Create Indirect Data Forwarding Tunnel Request message on S4/S11, if the SGW selected by the MME/S4-SGSN for indirect data forwarding is different from the SGW used as anchor.
– Identification Request/Response messages.
– Forward Relocation Request message over the S10, S16 and N26 interfaces, and over the S3 interface during I-RAT handover when ISR is not active.
– Forward Relocation Request message over the S3 interface during I-RAT handover between ISR associated nodes, when ISR is active for the UE, and if the node decides to allocate new S3 TEID-C.
– Context Request message over the S10, S16, S3 and N26 interfaces.
– Relocation Cancel Request message over the S10, S16, S3 and N26 interfaces, except for the case where the old SGSN/MME or AMF has already been assigned the Tunnel Endpoint Identifier Control Plane of the new SGSN/MME or AMF.
– Relocation Cancel Response message over the S10, S16, S3 and N26 interfaces if the new SGSN/MME or AMF does not have the Tunnel Endpoint Identifier Control Plane of the old SGSN/MME or AMF.
– Delete PDN Connection Set Request/Response messages.
– Configuration Transfer Tunnel message.
– RAN Information Relay message.
– If a node receives a message and the TEID-C in the GTPv2 header of the received message is not known, it shall respond with "Context not found" Cause in the corresponding response message to the sender, the TEID used in the GTPv2-C header in the response message shall be then set to zero.
– If a node receives a request message containing protocol error, e.g. Mandatory IE missing, which requires the receiver to reject the message as specified in clause 7.7, it shall reject the request message. For the response message, the node should look up the remote peer’s TEID and accordingly set the GTPv2-C header TEID and the message cause code. As an implementation option, the node may not look up the remote peer’s TEID and set the GTPv2-C header TEID to zero in the response message. However in this case, the cause code shall not be set to "Context not found".
– MBMS Session Start Request message.
– PGW Restart Notification / PGW Restart Notification Acknowledge messages.
– Downlink Data Notification message sent on S11/S4 as part of the Network Triggered Service Restoration procedure (see 3GPP TS 23.007 [17]), and corresponding Downlink Data Notification Acknowledge and Downlink Data Notification Failure Indication if the SGW did not include the Sender F-TEID for Control Plane IE in the Downlink Data Notification message.
– Stop Paging Indication message is sent to the the restarted CN node (or another node in the same pool) as part of the Network Triggered Service Restoration procedure with ISR (see 3GPP TS 23.007 [17]).
– Suspend Notification and Suspend Acknowledge messages: over S16 interface; over S3 interface when ISR is not active.
– PGW Downlink Triggering Notification message on S5 and S11/S4, PGW Downlink Triggering Acknowledge message on S11/S4, and PGW Downlink Triggering Acknowledge message on S5 if the PGW did not include the Sender F-TEID for Control Plane IE in the PGW Downlink Triggering Notification message.
– UE Registration Query Request and UE Registration Query Response messages over S3 interface.
NOTE: Legacy implementation conforming to earlier versions of this specification can send the Change Notification Request/Response messages on the TEID zero in spite of the peer’s node TEID being available.
5.6 Format of the GTPv2-C Message
The GTP-C header may be followed by subsequent information elements dependent on the type of control plane message.
|
Bits |
||||||||||
|
Octets |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
||
|
1 to m |
GTP-C header |
|||||||||
|
m+1 to n |
Zero or more Information Element(s) |
|||||||||
Figure 5.6-1: GTP-C Header followed by subsequent Information Elements