When a UPF fails, all its Session contexts and PFCP associations affected by the failure become invalid and may be deleted.

If F-TEID and/or UE IP address allocation is performed in the UPF, the UPF shall ensure that previously used F-TEID values and/or UE IP addresses are not immediately reused after a UPF restart, in order to avoid inconsistent F-TEID and/or UE IP address allocation throughout the network and to enable the restoration of PFCP sessions affected by the failure. How this is ensured is implementation specific. The UPF shall not send GTP-U Error indication message for a configurable period after an UPF restart when the UPF receives a G-PDU not matching any PDRs. During or immediately after an UPF Restart, the UPF shall place a local UPF Recovery Time Stamp value in all Heartbeat Request/Response messages. Immediately after the re-establishment of a PFCP association between the SMF and the UPF, the SMF may start restoring PFCP sessions in the UPF. The SMF should prioritize the PFCP sessions to restore based on operator's policy. The SMF should control the load induced on the UPF when performing the PFCP restoration procedures, the way it is done is implementation specific. When re-establishing a PFCP session and if F-TEID allocation and/or UE IP address is performed in the PSA UPF by network configuration, the SMF shall include a restoration indication in the PFCP Session Establishment Request message to indicate to the UPF it is for a restoration of an existing PFCP session and the UPF shall accept SMF allocated F-TEID and/or UE IP address if possible. If the UPF cannot accept the requested F-TEID and/or UE IP address because the IP address is no longer available at the UPF, the UPF shall reject the PFCP Session Establishment Request with the cause "PFCP session restoration failure due to requested resource not available".

Procedures for PSA UPF failure without restart are implementation specific.

The SMF will receive the UPF recovery time stamps in PFCP heartbeat requests/responses. After an Intermediate UPF restart, the PFCP association between the SMF(s) and the Intermediate UPF has to be re-established. The restoration of the PFCP sessions may start immediately after the PFCP association setup procedure:

• if the restoration is supported in the SMF on a proactive basis, the SMF may start re-establishing PFCP sessions matching any PDRs.
• as defined in clause 4.3.2, the SMF should prioritize the PFCP sessions restoration.
• if the restoration is supported in the SMF on a reactive basis:
  • the SMF shall establish an PFCP session with a wildcarded PDR to instruct the Intermediate UPF to forward G-PDU packets which are not matching any other PDRs to the SMF (to a F-TEID uniquely assigned in the SMF for this PFCP-u tunnel);
  • upon receipt of G-PDUs from this PFCP-u tunnel, the SMF shall then check if it has an active session for each received G-PDU packet:
  • if so, the SMF shall perform the PFCP Session establishment procedures to re-establish the corresponding PFCP sessions in the Intermediate UPF;
  • otherwise the SMF shall generate a GTP-U Error Indication with a destination address set to the source IP address of the received G-PDU, and send it to the Intermediate UPF. The Intermediate UPF shall forward this GTP-U Error Indication transparently. The SMF shall delete the G-PDU after the check for active sessions.

When re-establishing a PFCP session and if F-TEID allocation is performed in the Intermediate UPF by network configuration, the SMF shall include a restoration indication in the PFCP Session Establishment Request message to indicate to the UPF it is for a restoration of an existing PFCP session and the UPF shall accept SMF allocated F-TEID if possible. If the UPF cannot accept the requested F-TEID because the IP address is no longer available at the UPF, the UPF shall reject the PFCP Session Establishment Request with the cause "PFCP session restoration failure due to requested resource not available". The Intermediate UPF shall not send any Error indication messages for an operator configurable period after an Intermediate UPF restart when the Intermediate UPF receives G-PDU not matching any PDRs.

Procedures for Intermediate UPF failure without restart are implementation specific.

When a SMF fails, all its PDU session contexts and PFCP associations affected by the failure may become invalid and may be deleted. If F-TEID allocation is performed in the SMF, the SMF should ensure as far as possible that previously used F-TEID values are not immediately reused after a SMF restart, in order to avoid inconsistent TEID allocation throughout the network.

During or immediately after a SMF Restart, the SMF shall place local SMF-C Recovery Time Stamp value in all Heartbeat Request/Response messages. The UPF will receive the SMF recovery time stamps in PFCP heartbeat requests/responses. When a UPF detects that a peer PFCP entity in the SMF has restarted (as specified in clause 4.2), the UPF shall delete all session contexts affected by the PFCP entity restart that it may have stored. When the UPF receives a GTP-U PDU not matching any PDRs, it shall discard the GTP-U PDU and return a GTP error indication to the originating node (e.g. other UPF, gNB or N3IWF).

When a UPF detects that a peer PFCP entity in the SMF is not reachable for a preconfigured time, the UPF shall delete all the session contexts affected by the peer PFCP entity failure that it may have stored.

The SMF and UPF may support the partial failure handling feature over N4. If so, they shall support the requirements specified in this clause. This feature enables to clean up PFCP sessions optimally in the peer PFCP node (i.e. SMF or UPF), when a hardware or software failure affects a significant number of PFCP sessions. When it is not possible to recover the affected PFCP sessions, it is useful to inform the peer PFCP node about the affected PFCP sessions using an identifier that represents a large set of PFCP sessions, rather than doing so per PFCP session. A Connection Set Identifier (CSID) shall identify a set of PFCP sessions within a PFCP node that may belong to an arbitrary number of UEs. A CSID is an opaque parameter local to a PFCP node. Each PFCP node that supports the feature shall maintain a local mapping of CSID to its internal resources. When one or more of these resources fail, the corresponding one or more fully qualified CSIDs shall be signalled to the peer PFCP nodes. The fully qualified CSID (FQ-CSID) is the combination of the PFCP node identity and the CSID assigned by the PFCP node which together globally identifies a set of PFCP sessions. The node identifier shall be globally unique across all 3GPP EPS and 5GS networks. Its format is defined in TS 29.244.

The SMF and the UPF may each assign one FQ-CSID to a PFCP session during the PFCP session establishment, by signalling the SMF FQ-CSID in the PFCP Session Establishment Request or the UPF FQ-CSID in the PFCP Session Establishment Response, as shown in Figure 4.6.2-1.

The SMF and the UPF shall assign only one FQ-CSID for a given PFCP session and each FQ-CSID shall have exactly one CSID within the FQ-CSID. The peer PFCP node shall store the received FQ-CSID for the related PFCP session. The receipt of a FQ-CSID also implicitly indicates that the peer FFCP node supports the feature. The SMF and the UPF may update the FQ-CSID associated to a PFCP session during a PFCP session modification procedure, by signalling the SMF FQ-CSID in the PFCP Session Modification Request or the UPF FQ-CSID in the PFCP Session Modification Response, as shown in Figure 4.6.2-2.

An SMF that detects then that it has undergone a partial failure shall send a PFCP Session Set Deletion Request, including all its CSIDs corresponding to the component(s) that failed, to the UPF, if the UPF is known to support the feature, as shown in Figure 4.6.2-3.

Likewise, an UPF that detects then that it has undergone a partial failure shall send a PFCP Session Set Deletion Request, including all its CSIDs corresponding to the component(s) that failed, to the SMF, if the SMF is known to support the feature, as shown in Figure 4.6.2-4.

Upon receiving a PFCP Session Set Deletion Request reporting a partial failure for one or more FQ-CSID(s), the SMF or UPF shall find the PFCP sessions matching the FQ-CSID(s) and then proceed with the restoration procedures specified in clause 4 for an SMF or UPF failure.

To reduce signalling latency and achieve a better load balancing among SMFs in a SMF Set when it is deployed, an SMF in a SMF Set and a UPF may support the procedures specified in this clause. These procedures enable an SMF from the same set to request UPF to move PFCP sessions associated with certain FQ-CSIDs (when partial failure handling is supported as specified in clause 4.6), Group IDs or SMF IP addresses, to (another) SMF(s) in the set proactively, without causing massing signalling (per PFCP session) towards UPF(s).

To optimize the resource utilization for PFCP session(s), e.g. to meet different traffic requirements for different APNs/DNNs and/or DCNs/Network Slices, and also to facilitate moving a (sub)set of PDN connections/PFCP sessions among an SMF set, e.g. for a partial or complete SMF failure or a scale-in operation, an SMF in a SMF Set may:

• allocate a globally unique Group Id in the PFCP Session Establishment Request message for a PFCP session during a PFCP session establishment procedure and update the Group Id, if necessary, in subsequent PFCP Session Modification Request messages (see also clause 5.22 of TS 29.244).

Alternatively, if partial failure handling is supported, the SMF may assign an FQ-CSID to a PFCP session as specified in clause 4.6. Subsequently, e.g. when a partial or complete failure takes place affecting all PFCP sessions which are sharing either the same FQ-CSID or the Group ID (see clause 4.7.1), a PGW-C/SMF in a PGW-C/SMF Set may trigger the restoration procedure for those affected PFCP sessions as specified in clauses 4.7.3.

When there is a need to change the SMF controlling certain PFCP sessions, e.g. when a partial or complete failure takes place, the SMF (either the SMF serving the PFCP sessions or another SMF in the same Set taking over the control of the PFCP sessions) may send a PFCP Session Set Modification Request message to the UPF(s) to request the UPF(s) to send subsequent PFCP Session Report Request messages to the alternative SMF (as indicated in the Alternative SMF IP Address IE) for the PFCP sessions which are associated with the FQ-CSID(s) or Group ID(s), or which have their CP F-SEIDs containing the SMF IP Address as shown in Figure 4.7.3-1. The SMF may instruct the UPF to move sessions associated with different SMF FQ-CSIDs, Group Ids or SMF IP addresses, to different SMF addresses.