18 GTP-C based restart procedures

23.0073GPPRelease 18Restoration proceduresTS

Across GTP-C based interfaces an SGSN, GGSN, MME, SGW, PGW, TWAN, ePDG and HRPD Access Node utilize either GTPv1-C or GTPv2-C Echo Request and Echo Response messages or GTP-C messages containing the Recovery Information Element to detect and handle a restart.

A GTP-C entity shall maintain two Restart counters:

– in volatile memory a remote Restart counter of a peer with which the entity is in contact;

– in non-volatile memory own, or local Restart counter that was sent to a peer.

After a GTP-C entity has restarted, it shall immediately increment all local Restart counters and shall clear all remote Restart counters.

A GTP-C entity may have a common local Restart counter for all peers, or it may have a separate local Restart counter for each peer.

A GTP-C entity may probe the liveliness of each peer with which it is in contact by sending an Echo Request message (see clause 20 "Path management procedures") . The presence of the Restart counter in Echo Request or in a GTP-C message depends on the GTP-C version and therefore is specified in 3GPP TS 29.060 [8] and 3GPP TS 29.274 [13], respectively. The restart counter signalled in the GTP-C message is associated with the GTP-C entity identified by the sender’s F-TEID or SGSN/GGSN IP address for control plane if present in the message, otherwise (e.g. in echo request message) it is associated with the GTP-C entity identified by the source IP address of the message.

The GTP-C entity that receives a Recovery Information Element in an Echo Response or in another GTP-C message from a peer, shall compare the received remote Restart counter value with the previous Restart counter value stored for that peer entity.

– If no previous value was stored the Restart counter value received in the Echo Response or in the GTP-C message shall be stored for the peer.

– If the value of a Restart counter previously stored for a peer is smaller than the Restart counter value received in the Echo Response message or the GTP-C message, taking the integer roll-over into account, this indicates that the entity that sent the Echo Response or the GTP-C message has restarted. The received, new Restart counter value shall be stored by the receiving entity, replacing the value previously stored for the peer.

– If the value of a Restart counter previously stored for a peer is larger than the Restart counter value received in the Echo Response message or the GTP-C message, taking the integer roll-over into account, this indicates a possible race condition (newer message arriving before the older one). The received new Restart counter value shall be discarded and an error may be logged.

Based on operator’s policy, when a Recovery IE is received in an Echo Request or in any incoming GTP-C request message (which includes a Recovery IE) from a peer GTP-C entity, with a Restart counter value larger than the value of the Restart counter previously stored for the peer GTP-C entity, the GTP-C entity may verify whether the peer GTP-C entity has really restarted by:

– sending one or more Echo Request message(s) towards the peer GTP-C entity, or by monitoring other GTP-C request messages it may have sent for any PDN connections (e.g. Update Bearer Request message) towards the peer GTP-C entity; and

– determining that the peer GTP-C entity has restarted if the value of the restart counter received in the Recovery IE in the Echo Response message or in the corresponding GTP-C response messages (e.g. Update Bearer Response) is larger than the value of the Restart counter previously stored for the peer GTP-C entity.

NOTE: This can be used e.g. when two GTP-C entities are connected via a roaming interface and Network Domain Security (e.g. IPsec ESP) is not applied or may not provide sufficient protection of the GTP-C signalling, e.g. against IP address spoofing.