Section: 5.5 Usage of the GTPv2-C Header 5.5.1 General
Content: 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[ 3GPP Evolved Packet System (EPS); Optimized handover procedures and protocols between E-UTRAN access and cdma2000 HRPD Access; Stage 3 ]  [14]) and Sv (3GPP TS 29.280[ Evolved Packet System (EPS); 3GPP Sv interface (MME to MSC, and SGSN to MSC) for SRVCC ]  [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[ Architecture enhancements for non-3GPP accesses ]  [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[ Architecture enhancements for non-3GPP accesses ]  [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.