Content for TS 23.527 Word version: 19.0.0

1… 4… 4.4… 4.5… 4.7… 5… 6… 6.3… 6.6… 7… 8… 8.3… 8.3.2.4 8.3.3… 8.4… 9…

4.1 General 4.2 N4 Failure and Restart Detection 4.3 UPF Restoration Procedures 4.3.1 General 4.3.2 Restoration Procedure for PSA UPF Restart 4.3.3 Restoration Procedure for PSA UPF Failure without Restart 4.3.4 Restoration Procedure for Intermediate UPF Restart 4.3.5 Restoration Procedure for Intermediate UPF Failure without Restart
...

4 Restoration Procedures related to the N4 Interface p. 7

4.1 General p. 7

This clause specifies the procedures supported in the 5G System to detect and handle failures affecting the N4 interface.

4.2 N4 Failure and Restart Detection p. 7

Across PFCP based interfaces, an SMF and UPF shall utilize the PFCP Heartbeat Request and Heartbeat Response messages to detect a peer PFCP entity failure or restart as described in clause 19A of TS 23.007.

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).

4.3 UPF Restoration Procedures p. 7

4.3.1 General p. 7

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

4.3.2 Restoration Procedure for PSA UPF Restart p. 8

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".

4.3.3 Restoration Procedure for PSA UPF Failure without Restart p. 8

Procedures for PSA UPF failure without restart are implementation specific.

4.3.4 Restoration Procedure for Intermediate UPF Restart p. 8

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.

4.3.5 Restoration Procedure for Intermediate UPF Failure without Restart p. 9

Procedures for Intermediate UPF failure without restart are implementation specific.