7.2 Path Management Messages

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

7.2.0 General

The Path Management messages may be sent between any type of GSN or GSN – RNC pair.

7.2.1 Echo Request

A GSN or an RNC may send an Echo Request on a path to the other GSN or RNC to find out if the peer GSN or RNC is alive (see clause Path Failure). Echo Request messages may be sent for each path associated with at least one of the active PDP context, or MBMS UE context, or MBMS bearer context. When and how often an Echo Request message may be sent is implementation specific but an Echo Request shall not be sent more often than every 60 s on each path.

Even if the path is not associated with any active PDP contexts, or MBMS UE contexts, or MBMS bearer contexts, a GSN or RNC shall be prepared to receive an Echo Request at any time and it shall reply with an Echo Response. The optional Private Extension contains vendor or operator specific information.

Table 2: Information Elements in an Echo Request

Information element	Presence requirement	Reference
Private Extension	Optional	7.7.46

7.2.2 Echo Response

The message shall be sent as a response to a received Echo Request.

The Recovery information element contains the local Restart Counter (see clause Restoration and Recovery) value for the GSN that sends the Echo Response message. For GTP-U the Restart Counter value shall not be used, i.e. it shall be set to zero by the sender and shall be ignored by the receiver.

The GSN that receives an Echo Response from a peer GSN shall compare the Restart Counter value received with the previous Restart Counter value stored for that peer GSN. If no previous value was stored, the Restart Counter value received in the Echo Response shall be stored for the peer GSN.

The value of a Restart Counter previously stored for a peer GSN may differ from the Restart Counter value received in the Echo Response from that peer GSN. In this case, the GSN shall handle the Restart Counter as specified in clause 18 of 3GPP TS 23.007 [3].

If the sending GSN is a GGSN and the receiving GSN is an SGSN, the SGSN shall consider all PDP contexts using the GGSN as inactive. For further actions of the SGSN refer to 3GPP TS 23.007 [3].

If the sending GSN is an SGSN and the receiving GSN is a GGSN, the GGSN shall consider all PDP contexts using the SGSN as inactive. For further actions of the GGSN refer to 3GPP TS 23.007 [3].

The optional Private Extension contains vendor or operator specific information.

Table 3: Information Elements in an Echo Response

Information element	Presence requirement	Reference
Recovery	Mandatory	7.7.11
Private Extension	Optional	7.7.46

7.2.3 Version Not Supported

This message contains only the GTP header and indicates the latest GTP version that the GTP entity on the identified UDP/IP address can support (see clause 11.1.1).

7.2.4 Supported Extension Headers Notification

This message indicates a list of supported Extension Headers that the GTP entity on the identified IP address can support. This message is sent only in case a GTP entity was required to interpret a mandatory Extension Header but the GSN or RNC was not yet upgraded to support that extension header. The GTP endpoint at the GSN or RNC sending this message is marked as not enabled to support some extension headers (as derived from the supported extension header list). The GSN may retry to use all the extension headers with that node, in an attempt to verify it has been upgraded. Implementers should avoid repeated attempts to use unknown extension headers with an endpoint that has signalled its inability to interpret them.

Table 4: Information Elements in Supported Extension Headers Notification

Information element	Presence requirement	Reference
Extension Header Type List	Mandatory	7.7.40