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 TS 29.060 and TS 29.274, 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.

The support of GTP-U based restart procedure is optional for a GTP-U entity. When the feature is supported, across GTP-U based interfaces, i.e. the S1-U, S11-U, S2a, S2b, X2, S4, S5, S8, S12, M1 and Sn interfaces of the Evolved Packet System in EPS, and the F1-U, Xn, N3, N9, N19, N3mb and N19mb interfaces of the 5G System in 5GS, a GTP-U entity shall utilize GTP-U Echo Request, Echo Response messages and GTP-U Error Indication message containing the Recovery Time Stamp Information Element to detect and handle a restart. A GTP-U entity shall be prepared to receive an Echo Request message at any time (even from unknown peers), and it shall reply with an Echo Response message. A GTP-U entity shall maintain two Recovery Time Stamps:

• in volatile memory a remote Recovery Time Stamp of a peer GTP-U entity with which the entity is in contact;
• in non-volatile memory own, or local Recovery Time Stamp that was sent to a peer GTP-U entity.

After a GTP-U entity has (re)started and all its GTP-U contexts have been lost, and if the GTP-U entity knows these GTP-U contexts are not to be restored, e.g., by its Control Plane function, it shall immediately update all local Recovery Time Stamps and shall clear all remote Recovery Time Stamps. When peer GTP-U entities information is available, e.g. when the first GTP-U tunnel towards the peer GTP-U entity is established, the (re)started GTP-U entity may send its (updated) Recovery Time Stamps in an Echo Request message to the peer GTP-U entity before sending GTP-U packets. A GTP-U entity may have a common local Recovery Time Stamp for all peer GTP-U entities, or it may have a separate local Recovery Time Stamp for each peer GTP-U entity. A GTP-U entity may probe the liveliness of each peer GTP-U entity with which it is in contact by sending an Echo Request message. The Recovery Time Stamp signalled in the GTP-U Echo Request and Response messages is associated with the GTP-U entity identified by the source IP address of the message. The Recovery Time Stamp signalled in the GTP-U Error Indication is associated with the source IP address of the GTP-U Error Indication or associated with a list of IP address(es) which are sharing the same Recovery Time Stamp if those IP address(es) are explicitly included in the GTP-U Error Indication message. The GTP-U entity that receives a Recovery Time Stamp Information Element from a peer GTP-U entity shall compare the received remote Recovery Time Stamp value with the previous Recovery Time Stamp value stored for that peer GTP-U entity.

• If no previous value was stored, the Recovery Time Stamp value received in the Echo Request or Response messages or the GTP Error Indication message shall be stored for the peer GTP-U entity.
• If the value of a Recovery Time Stamp previously stored for a peer GTP-U entity is smaller than the Recovery Time Stamp received in the Echo Request or Response messages or the GTP-U Error Indication messages, this indicates that the entity that sent the Echo Request or Response messages or the GTP-U Error Indication messages has restarted. The received, new Recovery Time Stamp value shall be stored by the receiving entity, replacing the value previously stored for the peer GTP-U entity.
• If the value of a Recovery Time Stamp previously stored for a peer GTP-U entity is larger than the Recovery Time Stamp value received in the Echo Request or Response messages or the GTP-U Error Indication messages, this indicates a possible race condition (newer message arriving before the older one). The received new Recovery Time Stamp value shall be discarded and an error may be logged.

Based on operator's policy, when a Recovery Time Stamp IE is received in an Echo Request from a peer GTP-U entity, with a Recovery Time Stamp larger than the value of the Recovery Time Stamp previously stored for the peer GTP-U entity, the GTP-U entity may verify whether the peer GTP-U entity has really restarted by:

• sending one or more Echo Request message(s) towards the peer GTP-U entity; and
• determining that the peer GTP-U entity has restarted if the Recovery Time Stamp in the Echo Response message is larger than the value of the Recovery Time Stamp previously stored for the peer GTP-U entity.

Across PMIPv6 based interfaces, SGW, PGW, TWAN and ePDG utilize PMIPv6 Heartbeat mechanism for node restart detection as specified in TS 29.275. A PMIPv6 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 an own, or local restart counter that was sent to a peer.

After a PMIPv6 entity has restarted, it shall immediately increment all local restart counters and shall clear all remote restart counters. A PMIPv6 entity may have a common local restart counter for all peers, or it may have a separate local restart counter for each peer.

Across PFCP based interfaces, an SGW-C, SGW-U, PGW-C and PGW-U Node shall utilize PFCP Heartbeat Request and Heartbeat Response messages to detect and handle a peer PFCP entity failure or restart. A PFCP entity shall be prepared to receive a Heartbeat Request message at any time (even from unknown peers), and it shall reply with a Heartbeat Response message. A PFCP entity shall maintain two Recovery Time Stamps:

• in volatile memory a remote Recovery Time Stamp of a peer PFCP entity with which the entity is in contact;
• in non-volatile memory own, or local Recovery Time Stamp that was sent to a peer PFCP entity.

After a PFCP entity has restarted, it shall immediately update all local Recovery Time Stamps and shall clear all remote Recovery Time Stamps. When peer PFCP entities information is available, i.e. when the PFCP Association is still alive, the restarted PFCP entity shall send its updated Recovery Time Stamps in a Heartbeat Request message to the peer PFCP entities before initiating any PFCP session signalling. A PFCP entity may have a common local Recovery Time Stamp for all peer PFCP entities, or it may have a separate local Recovery Time Stamp for each peer PFCP entity. A PFCP entity may probe the liveliness of each peer PFCP entity with which it is in contact by sending a Heartbeat Request message (see clause 20 "Path management procedures"). The Recovery Time Stamp signalled in the PFCP Heartbeat Request and Response messages is associated with the PFCP entity identified by the source IP address of the message. The Recovery Time Stamp signalled in the PFCP Session Establishment Request messages is associated with the IP address in the CP F-SEID IE. The PFCP entity that receives a Recovery Time Stamp Information Element from a peer PFCP entity shall compare the received remote Recovery Time Stamp value with the previous Recovery Time Stamp value stored for that peer PFCP entity.

• If no previous value was stored, the Recovery Time Stamp value received in the Heartbeat Request or Response messages or the PFCP Session Establishment Request messages shall be stored for the peer PFCP entity.
• If the value of a Recovery Time Stamp previously stored for a peer PFCP entity is smaller than the Recovery Time Stamp value received in the Heartbeat Request or Response messages or the PFCP Session Establishment Request messages, this indicates that the entity that sent the Heartbeat Request or Response messages has restarted. The received, new Recovery Time Stamp value shall be stored by the receiving entity, replacing the value previously stored for the peer PFCP entity.
• If the value of a Recovery Time Stamp previously stored for a peer PFCP entity is larger than the Recovery Time Stamp value received in the Heartbeat Request or Response message or the PFCP Session Establishment Request messages, this indicates a possible race condition (newer message arriving before the older one). The received Sx node related message and the received new Recovery Time Stamp value shall be discarded and an error may be logged.

A PFCP function shall ignore the Recovery Timestamp received in PFCP Association Setup Request and PFCP Association Setup Response messages (see clause 6.2.6 of TS 29.244). When a NAT device is deployed between PFCP entities, e.g. between the CP function and UP function, the following requirements shall apply in addition to the above requirements:

• the Heartbeat Request message may include a Source IP Address IE;
• when the Source IP Address IE is present, the Recovery Time Stamp signalled in the Heartbeat Request message shall be associated with the Source IP Address IE, instead of the source IP address of the message.

Across URCMP based interfaces, an MME and UCMF Node shall utilize URCMP Heartbeat Request and Heartbeat Response messages to detect and handle a peer URCMP entity failure or restart. A URCMP entity shall be prepared to receive a Heartbeat Request message at any time (even from unknown peers), and it shall reply with a Heartbeat Response message. A URCMP entity shall maintain two Recovery Time Stamps:

• in volatile memory a remote Recovery Time Stamp of a peer URCMP entity with which the entity is in contact;
• in non-volatile memory own, or local Recovery Time Stamp that was sent to a peer URCMP entity.

After a URCMP entity has restarted and if it loses all dictionary mapping information between UE Radio Capability Information and UE Radio Capability IDs, it shall immediately update all local Recovery Time Stamps and shall clear all remote Recovery Time Stamps. A URCMP entity may have a common local Recovery Time Stamp for all peer URCMP entities, or it may have a separate local Recovery Time Stamp for each peer URCMP entity. A URCMP entity may probe the liveliness of each peer URCMP entity with which it is in contact by sending a Heartbeat Request message (see clause 20 "Path management procedures"). The Recovery Time Stamp signalled in the URCMP Heartbeat Request and Response messages is associated with the URCMP entity identified by the source IP address of the message. The URCMP entity that receives a Recovery Time Stamp Information Element from a peer URCMP entity shall compare the received remote Recovery Time Stamp value with the previous Recovery Time Stamp value stored for that peer URCMP entity.

• If no previous value was stored, the Recovery Time Stamp value received in the Heartbeat Request or Response messages shall be stored for the peer URCMP entity.
• If the value of a Recovery Time Stamp previously stored for a peer URCMP entity is smaller than the Recovery Time Stamp value received in the Heartbeat Request or Response messages, this indicates that the entity that sent the Heartbeat Request or Response messages has restarted. The received, new Recovery Time Stamp value shall be stored by the receiving entity, replacing the value previously stored for the peer URCMP entity.
• If the value of a Recovery Time Stamp previously stored for a peer URCMP entity is larger than the Recovery Time Stamp value received in the Heartbeat Request or Response message, this indicates a possible race condition (newer message arriving before the older one). The received Sx node related message and the received new Recovery Time Stamp value shall be discarded and an error may be logged.