4 General

29.2743GPP3GPP Evolved Packet System (EPS)Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C)Release 18Stage 3TS

4.1 GTP Tunnel

GTP tunnels are used between two nodes communicating over a GTP based interface, to separate traffic into different communication flows.

A GTP tunnel is identified in each node with a TEID, an IP address and a UDP port number. The receiving end side of a GTP tunnel locally assigns the TEID value the transmitting side has to use. The TEID value shall be assigned in a non-predictable manner for PGW S5/S8/S2a/S2b interfaces (see 3GPP TS 33.250 [85]). The TEID values are exchanged between tunnel endpoints using GTP-C or S1-MME or Iu-PS messages. The GTPv2 entity communicates to the peer GTPv2 entity the TEID value at which it expects to receive all subsequent control plane messages related to that GTP tunnel via the:

– "Sender F-TEID for Control Plane" IE,

– "PGW S5/S8/S2a/S2b F-TEID for PMIP based interface or for GTP based Control Plane interface" IE,

– "MSC Server Sv TEID for Control Plane" IE,

– "S3/S16/S10 Address and TEID for Control Plane" IE, or

– "MME/SGSN Sv TEID for Control Plane" IE.

The criteria defining when the same or different GTP tunnels shall be used between the two nodes differs between the control and the user plane, and also between interfaces.

For the control plane, for each end-point of a GTP-C tunnel:

– The TEID-C shall be unique per PDN-Connection on GTP based S2a, S2b, S5 and S8 interfaces. The same tunnel shall be shared for the control messages related to all bearers associated to the PDN-Connection. A TEID-C on the S2a/S2b/S5/S8 interface shall be released after all its associated EPS bearers are deleted.

– There shall be only one pair of TEID-Cs per UE on each of the S3, S10, S16 and N26 interfaces. The same tunnel shall be shared for the control messages related to the same UE operation. A TEID-C on the S3/S10/S16/N26 interface shall be released after its associated UE context is removed or the UE is detached. For the S3 interface, when ISR is active for the UE, during I-RAT handover between the ISR associated nodes, the existing S3 TEID-C may be re-used or new S3 TEID-C may be allocated. During this scenario, if the node decides to allocate new S3 TEID-C, it shall release its own old S3 TEID-C.

– There shall be only one pair of TEID-C per UE over the S11 and the S4 interfaces. The same tunnel shall be shared for the control messages related to the same UE operation. A TEID-C on the S11/S4 interface shall be released after all its associated EPS bearers are deleted.

– There shall be only one pair of TEID-C per MBMS Bearer Service (i.e. per TMGI and MBMS Flow Identifier, if the MBMS Flow Identifier is provided; or per TMGI, if the MBMS Flow Identifier is not provided) over the Sm and Sn interfaces respectively. The same tunnel shall be shared for the control messages related to the same MBMS Bearer Service. A TEID-C on the Sm/Sn interface shall be released after the MBMS Bearer Session is stopped.

For GTP-U, a TEID-U is used according to 3GPP TS 29.281 [13].

NOTE: GTP-U is based on GTP version 1 (GTPv1).

4.2 Protocol stack

4.2.0 General

The protocol stack for GTPv2 shall be as depicted in Figure 4.2.0-1.

Figure 4.2.0-1: GTPv2 stack

The GTPv2 headers are specified in the respective clauses of this specification.

The source and destination IP addresses and UDP ports used for each GTP-C message depend on the role that the message plays in a message exchange. A message can be an Initial message, or a Triggered message, or a Triggered Reply message to Triggered message. An Initial message is sent to a peer GTP entity with a sequence number chosen by the sending entity (see clause 7.6). A Triggered message is sent in response to an Initial message. Triggered Reply message may be sent in response to a Triggered message. See clause 7.6 for the sequence number usage.

Typically, a Request message is an Initial message, but a Request message may be a Triggered messages in certain procedures where they are triggered by an Initial Command message. See clause 4.2.5 for classification of the Initial messages and their possible Triggered messages, as well as cases where there are Triggered Reply messages to the Triggered messages.

Piggybacking is an optional feature, which is described in Annex F of 3GPP TS 23.401 [3]. If the feature is supported, then the piggybacking of the initial messages on triggered response messages for 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]) and UE-requested PDN Connectivity procedures shall be implemented as per requirements in clauses 4.2.0 and 5.5.1 of this specification .When piggybacking is used, a common IP header and a common UDP header shall be used for the triggered response message and the piggybacked initial message as depicted in Figure 4.2.0-2. Immediately following the triggered response message is the piggybacked initial message, following which no additional information shall be present. The clause 5.5 specifies the usage of piggybacking-specific fields in the GTP-C header.

IP header

UDP header

Triggered response message (P=1)

Piggybacked initial message (P=0)

Figure 4.2.0-2: Packet Format for the Piggybacking of messages

4.2.1 UDP header and port numbers

4.2.1.0 General

A User Datagram Protocol (UDP) compliant with IETF RFC 768 [7] shall be used.

4.2.1.1 Initial Messages

The UDP Destination Port number for GTPv2 Initial messages shall be 2123. It is the registered port number for GTP-C.

The UDP Source Port for a GTPv2 Initial message is a locally allocated port number at the sending GTP entity.

If GTPv2 and GTP’ v2 modules are using the same IP address for sending messages, the implementation shall ensure that while some source port number is used by GTPv2 messages, the same source port number shall not be used by GTP’ v2 messages. Otherwise, the IP interface may have difficulty to delivering a response message to the right protocol entity.

4.2.1.2 Triggered Messages

The UDP Destination Port value of a GTPv2 Triggered message and for a Triggered Reply message shall be the value of the UDP Source Port of the corresponding message to which this GTPv2 entity is replying, except in the case of the SGSN pool scenario.

The UDP Source Port of a GTPv2 Triggered message and for a Triggered Reply message shall be the value from the UDP Destination Port of the corresponding message to which this GTPv2 entity is replying, except in the case of the SGSN pool scenario.

In the SGSN pool scenario, if the Identification Request, the Context Request or the Suspend Notification messages have been forwarded by another SGSN in the pool, the UDP Destination Port for the Identification Response, the Context Response or the Suspend Acknowledge message shall be determined in the following way. The value from the information element "UDP Source Port Number", which was sent in the corresponding forwarded request, shall be copied into the UDP Destination Port field. The UDP Source Port for the Identification Response, the Context Response or the Suspend Acknowledge message may be a locally allocated port number at the sending GTP entity.

In the handover scenario when the CIoT feature is deployed, if the Forward Relocation Request message has been forwarded by the target MME, the UDP Destination Port for the Forward Relocation Response shall be set to the value of Source UDP Port Number IE included in the Forward Relocation Request message; the UDP Source Port for the Forward Relocation Response message may be a locally allocated port number at the sending GTP entity.

4.2.1.3 Piggybacked Messages

A piggybacked initial message is carried as a concatenation after a triggered response message and they share a common UDP header (see Figure 4.2.0-2).

The UDP Destination port for the IP packet containing both the triggered response message and the piggybacked initial message shall be the same as the port number used for the triggered response message.

The UDP Source port for the IP packet containing both the triggered response message and the piggybacked initial message shall be the same as the port number used for the triggered response message.

4.2.2 IP header and IP addresses

4.2.2.1 Initial Messages

The IP Destination Address of a GTPv2 Initial message shall be an IP address of the destination GTPv2 entity.

During the establishment of the GTP tunnel, the GTPv2 entity selects and communicates to the peer GTPv2 entity the IP Destination Address at which it expects to receive subsequent control plane Initial messages related to that GTP tunnel via the:

– "Sender F-TEID for Control Plane" IE,

– "PGW S5/S8/S2a/S2b F-TEID for PMIP based interface or for GTP based Control Plane interface" IE,

– "MSC Server Sv Address for Control Plane" IE,

– "S3/S16/S10 Address and TEID for Control Plane" IE, or

– "MME/SGSN Sv Address for Control Plane" IE.

A Create Session Request shall only include in the Sender F-TEID the same IP address type as the destination address used in the IP header. An IPv4/IPv6 capable SGW and PGW may advertize an IPv4 address and/or an IPv6 address in the F-TEID of the above IEs.

Upon a change of MME, SGSN or SGW, the new MME, SGSN or SGW may switch to a different IP address type (e.g. IPv6 address) in the IP header if a different IP address type was advertized by the SGW or PGW earlier. A Modify Bearer Request shall only include in the Sender F-TEID the same IP address type as the destination address used in the IP header.

NOTE 1: Advertizing a single IP address type in a Create Session Request or a Modify Bearer Request ensures that both GTP-C peers know without ambiguity the IP address type to be used in subsequent control plane Initial messages in the reverse direction related to that GTP-C tunnel, and it avoids intempestive IP address switching during the establishment of the GTP-C tunnel or during an established communication between two GTP-C peers.

NOTE 2: IP switching between IPv4 and IPv6 can occur upon a change of MME/SGSN or SGW in deployments with MME/SGSNs or SGWs with different IPv6 capabilities.

EXAMPLE 1: If an MME gets IPv4 addresses from the DNS for the SGW, the MME only includes an IPv4 address in the Sender F-TEID IE of the Create Session Request. In the response, the SGW advertises an IPv4 address and optionally an IPv6 address, and the SGW uses IPv4 addressing in subsequent control plane Initial messages it sends to the MME related to that GTP-C tunnel.

EXAMPLE 2: As a continuation of EXAMPLE 1, upon a subsequent change of MMEs, assuming the source MME only supports IPv4 and the target MME supports IPv4 and IPv6, the target MME can switch to IPv6 addressing by sending a Modify Bearer Request to the SGW using the SGW S11 IPv6 address in the IP header and including a Sender F-TEID with an MME S11 IPv6 address only.

During the network triggered service restoration procedure (see 3GPP TS 23.007 [17]), if an MME/S4-SGSN sends a Downlink Data Notification Failure Indication message to the SGW, then the destination address for this message shall be the SGW IP address signalled via the Sender F-TEID for Control Plane IE in the Downlink Data Notification message (if present in the message), otherwise the source IP address of the Downlink Data Notification message received earlier.

The IP Source Address of a GTPv2 Initial message shall be an IP address of the source GTPv2 entity from which the Initial message is originating.

4.2.2.2 Triggered Messages

The IP Destination Address of a GTPv2 Triggered message and for a Triggered Reply message shall be copied from the IP Source Address of the message to which this GTPv2 entity is replying, except in the case of the SGSN pool scenario.

The IP Source Address of a GTPv2 Triggered message and for a Triggered Reply message shall be copied from the IP destination address of the message to which this GTPv2 entity is replying, except in the case of SGSN pool scenario and handover scenario when the CIoT feature is deployed.

In the SGSN pool scenario, if the Identification Request, the Context Request or the Suspend Notification messages have been forwarded by another SGSN in the pool, the IP Source address for the Identification Response, the Context Response or the Suspend Acknowledge messages shall be locally allocated by the sending GTP entity. The IP Destination Address for the Identification Response, the Context Response or the Suspend Acknowlegde messages shall be determined in the following way. The value from the information element "Address for Control Plane", which was sent in the corresponding Identification Request or the Suspend Notification message; or the value from the information element "S3/S16/S10 Address and TEID for Control Plane", which was sent in the corresponding Context Request message, shall be copied into the IP Destination Address field.

In the handover scenario when the CIoT feature is deployed, if the Forward Relocation Request message has been forwarded by the target MME, the IP Source address of the Forward Relocation Response shall be locally allocated by the sending GTP entity. The IP Destination Address field of the Forward Relocation Response shall be set to the value of the "Sender’s F-TEID for Control Plane" IE received in the Forward Relocation Request message.

4.2.2.3 Piggybacked Messages

A piggybacked initial message is carried as a concatenation after a triggered response message and they share a common IP header (see Figure 4.2.0-2).

The IP Source Address for the IP packet containing both the triggered response message and the piggybacked initial message shall be the same as the IP Address used for the triggered response message.

The IP Destination Address for the IP packet containing both the triggered response message and the piggybacked initial message shall be the same as the IP Address used for the triggered response message.

4.2.3 Layer 2

Typically Ethernet should be used as a Layer 2 protocol, but operators may use any other technology.

4.2.4 Layer 1

Operators may use any appropriate Layer 1 technology.

4.2.5 Messages with GTPv2 defined replies: Classification of Initial and Triggered Messages

An Initial message is a GTPv2 message that is not triggered as a response to another GTPv2 message across the given interface.

The expected reply to a Request message is a Triggered message and the reply has the same message name as the Request but with "Response" replacing "Request".

NOTE 1: If the SGW receives a "Create Session Request" on S11/S4, this can trigger either of the following GTPv2 messages across S5/S8: "Create Session Request" or "Modify Bearer Request". However, neither of these messages across S5/S8 is considered to be a Triggered message.

If a Request message is a reply to a Command message, then the Request message is a Triggered message; otherwise the Request message is an Initial message. Responses do not have replies except when a "Context Acknowledge" is required as a reply to "Context Response" message as specified in relevant Stage 2 procedures. Context Acknowledge is always triggered message and does not have a reply.

NOTE 2: The "Context Acknowledge" message is sent only if the "Context Response" message is received with the acceptance cause.

A message whose name ends in "Command" is always an initial message. If a "Command" message fails, the name of the reply message is constructed by replacing "Command" with "Failure Indication". Apart from "Downlink Data Notification Failure Indication" message, a "Failure Indication" is a Triggered message. The "Failure Indication" message does not have a reply. If a "Command" message is successful, its reply will be a Request as specified in relevant Stage 2 procedures.

A message whose name ends in "Notification" is always an Initial message, The expected Triggered message in reply has the same message name but with "Acknowledge" replacing "Notification", except for the case of the message "Downlink Data Notification" which has the reply "Downlink Data Notification Acknowledge" and "PGW Resart Notification" which has the reply "PGW Restart Notification Acknowledge". An "Acknowledge" message does not have a reply.

CS Paging Indication, Stop Paging Indication, RAN Information Relay, Configuration Transfer Tunnel, Trace Session Activation, Trace Session Deactivation, ISR Status Indication and Downlink Data Notification Failure Indication messages are Initial messages that do not have a reply.

A Version Not Supported Indication message is a Triggered message.

4.3 Transmission Order and Bit Definitions

The messages in this document shall be transmitted in network octet order starting with octet 1 with the Most Significant Bit sent first.

The most significant bit of an octet in a GTP message is bit 8. If a value in a GTP message spans several octets and nothing else is stated, the most significant bit is bit 8 of the octet with the lowest number.