19A PFCP based restart procedures

23.0073GPPRelease 18Restoration proceduresTS

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 3GPP TS 29.244 [43]).

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.