11 Notification of supported features between peer GTP-C entities

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

11.1 General

11.1.1 Introduction

New functionality, i.e. functionality beyond the Rel-9 standard, which can not be specified without backward incompatible changes (e.g. requiring support of a new message or a specific receiver node’s behaviour) should be introduced as a feature, see clause 11.1.2.

A GTP-C entity should verify that a backward incompatible feature is supported by its peer GTP entities before starting to use it.

NOTE: GTPv2 does not support a Comprehension Required mechanism allowing a sender to force the receiver to support comprehension of some specific IEs as a precondition to process a backward incompatible message.

Features may be generic node capabilities supported homogeneously for all GTP tunnels, UEs and PDN connections. Such features are referred in this specification as "Node Features". They are signalled with the granularity of a node on all GTPv2 interfaces (i.e. S11, S4, S5, S8, S10, S3, S16, Sv, S101, S121, Sm, Sn, S2a, S2b). A GTP-C entity may discover the features supported by a peer GTP-C entity with which it is in direct contact as specified in clause 11.2.1.

11.1.2 Defining a feature

A feature is a function extending the base GTPv2 functionality that has a significant meaning to the operation of GTPv2, i.e. a single new parameter without a substantial meaning to the functionality of the GTPv2 endpoints should not be defined to be a new feature.

A functionality requiring the definition of a new GTPv2 message or extending the use of an existing message over a new interface should be defined as a feature.

NOTE: Features are ultimately defined on a case-by-case basis on the merits of defining an extension as a feature.

Features should be defined so that they are independent from each other. A GTP-C entity may support the same feature over different interfaces, e.g. an SGW may support a feature over both S11 and S4 interface, however support of a feature on a given interface shall not depend on the support of the same or another feature on another interface.

11.2 Dynamic discovery of supported features

11.2.1 General

A node supporting at least one feature defined in the Node Features IE shall support dynamic discovery of supported features as specified in the following clauses.

11.2.2 Features supported by direct peer GTP-C entities

A node shall signal to a direct peer node the list of features it supports by sending the Sending Node Features IE in every Echo Request and Echo Response messages to that node.

An exception to this is where the sending node does not support or use any features towards the peer node and is not prepared to accept a message which is constructed by making use of any features.

The peer receiving the Sending Node Features IE shall store the list of features supported by the sending node per IP address and only update this list based on the Sending Node Features IE in the Echo Request and Echo Response messages, and it shall only use common supported features to initiate subsequent GTPv2 messages towards this IP address. Receipt of an Echo Request or an Echo Response message without the Sending Node Features IE shall indicate that the sending node does not support any feature specified in Table 8.83-1 on the corresponding interface.