8 Control Plane (GTP-C)

29.0603GPPGeneral Packet Radio Service (GPRS)GPRS Tunnelling Protocol (GTP) across the Gn and Gp interfaceRelease 17TS

The control plane in this case relates to GPRS Mobility Management functions like for example GPRS Attach, GPRS Routeing Area Update and Activation of PDP Contexts. The GPRS Tunnelling Protocol-Control plane (GTP-C) shall perform the control plane signalling between GSN nodes.

Figure 63: Signalling Plane – Protocol Stack

8.1 Control Plane Protocol

The GTP-C control plane flow shall be logically associated with, but separate from, the GTP-U tunnels. For each GSN-GSN pair one or more paths exist. One or more tunnels may use each path. GTP-C shall be the means by which tunnels are established, used, managed and released. A path may be maintained by keep-alive echo messages. This ensures that a connectivity failure between GSNs can be detected in a timely manner.

8.2 Usage of the GTP-C Header

For control plane messages the GTP header shall be used as specified in clause 6 with the following clarifications and additions:

– Version shall be set to decimal 1 ("001").

– Protocol Type flag (PT) shall be set to "1".

– Sequence number flag (S) shall be set to "1".

– N-PDU Number flag (PN) shall be set to "0". A GTP-C receiver shall not return an error if this flag is set to "1".

– Message Type shall be set to the unique value that is used for each type of control plane message. Valid message types are marked with an x in the GTP-C column in table 1.

– Length shall be 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.

– The Tunnel Endpoint Identifier is set by the sending entity to the value requested by the corresponding entity (SGSN or GGSN); it identifies all the PDP Contexts with the same PDP address or two IP addresses (one IPv4 and one IPv6 if PDP Type IPv4v6 is supported and used) and APN (for Tunnel Management messages) or it identifies each MS and its associated context data (for messages not related to Tunnel Management), except for the following cases:

– The Create PDP Context Request message and the Create MBMS Context Request message for a given MS sent to a specific GGSN shall have the Tunnel Endpoint Identifier set to all zeroes, if the SGSN has not been assigned a Tunnel Endpoint Identifier Control Plane by the GGSN.

– The Identification Request/Response messages, where the Tunnel Endpoint Identifier shall be set to all zeroes.

– The SGSN Context Request message, where the Tunnel Endpoint Identifier shall be set to all zeroes.

– The Echo Request/Response, Supported Extension Headers notification and the Version Not Supported messages, where the Tunnel Endpoint Identifier shall be set to all zeroes.

– The Forward Relocation Request message, where the Tunnel Endpoint Identifier shall be set to all zeroes.

– The PDU Notification Request message, where the Tunnel Endpoint Identifier shall be set to all zeroes.

– The MBMS Notification Request message, where the Tunnel Endpoint Identifier shall be set to all zeroes.

– The RAN Information Relay message, where the Tunnel Endpoint Identifier shall be set to all zeroes.

– The Relocation Cancel Request message where the Tunnel Endpoint Identifier shall be set to all zeroes, except for the case where the old SGSN has already been assigned the Tunnel Endpoint Identifier Control Plane of the new SGSN.

– All Location Management messages, where the Tunnel Endpoint Identifier shall be set to all zeroes.

– If a GSN receives a GTP-C message requesting action related to a PDP context that the sending node believes is in existence, but that is not recognised by the receiving node, the receiving node shall send back to the source of the message, a response with the appropriate cause value (either "Non-existent" or "Context not found"). The Tunnel Endpoint Identifier used in the response message shall be set to all zeroes.

– The MBMS Registration Request message, if successful assignment of Tunnel Endpoint Identifier Control Plane has not been confirmed, and, for MBMS Broadcast, the MBMS Session Start Request message, where the Tunnel Endpoint Identifier shall be set to all zeroes.

NOTE: Legacy implementation conforming to earlier versions of this specification can send the MS Info Change Reporting Request/Response messages on the TEID zero in spite of the peer’s node TEID being available.

The GSN Address for Control Plane set in the request message could be different from the IP Source address of the message. The Tunnel Endpoint Identifier notified in the request message is also used in this case for sending the corresponding response message.

– Sequence Number shall be a message number valid for a path. Within a given set of contiguous Sequence Numbers from 0 to 65535, a given Sequence Number shall, if used, unambiguously define a GTP control plane request message sent on the path (see clause Reliable delivery of signalling messages). The Sequence Number in a control plane response message shall be copied from the control plane request message that the GSN is replying to. For GTP-C messages not having a defined response message for a request message, i.e. for messages Version Not Supported, RAN Information Relay and Supported Extension Headers Notification, the Sequence Number shall be ignored by the receiver.

– N-PDU Number shall not be interpreted.

The GTP-C header may be followed by subsequent information elements dependent on the type of control plane message. Only one information element of each type is allowed in a single control plane message, except for the Authentication Triplet, the PDP Context, the Tunnel Endpoint Identifier Data II, NSAPI, PS Handover XID Parameters, Packet Flow ID, RFSP Index, PDU Numbers, Evolved Allocation/Retention Priority II, APN-AMBR with NSAPI, Signalling Priority Indication with NSAPI, Local Home Network ID (LHN-ID) with NSAPI, Charging Characteristics and the FQDN information element where several occurrences of each type are allowed.

		Bits
	Octets	8	7	6	5	4	3	2	1
	1 – m	GTP header
	m – n	Information Element(s)

Figure 64: GTP Header followed by subsequent Information Elements