5 Restoration Procedures related to the User Plane Interfaces N3 and N9

23.5273GPP5G SystemRelease 18Restoration proceduresTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.1 General

This clause specifies the procedures supported in the 5G System to detect and handle failures affecting the user plane interfaces N3 and N9

5.2 User Plane Failure Detection

5.2.1 Loss of GTP-U contexts

A GTP-U entity may lose its GTP-U contexts upon a failure or restart.

When a GTP-U node receives a G-PDU for which no corresponding GTP-U tunnel exists, the GTP-U node shall discard the G-PDU and return a GTP-U Error Indication to the sending node, as specified in clause 7.3.1 of 3GPP TS 29.281 [3].

The receipt of a GTP-U Error Indication is an indication for the sending GTP-U entity that the peer GTP-U entity cannot receive any more user plane traffic on the corresponding GTP-U tunnel.

5.2.2 User Plane Path Failure

A GTP-U entity may detect a user plane path failure by using GTP-U Echo Request and Echo Response messages, as specified in clause 20.3.1 of 3GPP TS 23.007 [2].

5.3 Restoration Procedures upon Loss of GTP-U contexts

5.3.1 General

The following clauses specify the behaviour of the different network entities when receiving a GTP-U Error Indication.

5.3.2 Procedure for GTP-U Error Indication received from 5G-AN

5.3.2.1 Principles

Figure 5.3.2.1-1: GTP-U Error Indication from 5G-AN

1. The user plane connection of an existing PDU session is activated. Downlink G-PDUs are sent towards the 5G-AN.

2. The 5G-AN returns a GTP-U Error Indication if it does not have a corresponding GTP-U context (see clause 5.2).

3. Upon receipt of a GTP-U Error Indication, the UPF shall identify the related PFCP session and send an Error Indication Report to the SMF, as specified in clause 5.10 of 3GPP TS 29.244 [4].

4. For a GTP-U Error Indication received from a 5G-AN, the SMF shall modify the PFCP session to instruct the UPF to buffer downlink packets.

5. If the user plane connection of the PDU session is seen as activated by the SMF, the SMF shall initiate an Namf_Communication_N1N2MessageTransfer service operation to request the 5G-AN to release the PDU session’s resources, as specified in clause 4.3.7 of 3GPP TS 23.502 [5].

6. Upon receipt of an Namf_Communication_N1N2MessageTransfer request to transfer the PDU Session Resource Release Command, the AMF shall:

– proceed with the request, as specified in clause 5.2.2.3.1 of 3GPP TS 29.518 [6], if the UE is in CM-CONNECTED state for the Access Network Type associated to the PDU session;

– otherwise, reject the request with an error indicating that the UE is in CM-IDLE state for the Access Network Type associated to the PDU session.

7. If the AMF sent a PDU Session Resource Release Command to the 5G-AN, the PDU session’s resource release is acknowledged to the SMF.

8. The SMF initiates the Network Triggered Service Request procedure specified in clause 4.2.3.3 of 3GPP TS 23.502 [5], to re-activate the user plane connection of the PDU session.

5.3.3 Procedure for GTP-U Error Indication received from UPF

5.3.3.1 GTP-U Error Indication received by 5G-AN

Upon receipt of a GTP-U Error Indication, the 5G-AN shall proceed as follows:

– if the GTP-U Error Indication was received from an UPF over a NG-U tunnel that is not an indirect forwarding tunnel, the 5G-AN shall initiate a PDU Session Resource Notify procedure and release immediately the resources of the PDU session for which the Error Indication was received;

– if the GTP-U Error Indication was received from a peer5G-AN over a Xn-U direct forwarding tunnel or an UPF over a NG-U indirect forwarding tunnel, the 5G-AN may ignore the error indication or delete the forwarding tunnel context locally without deleting the corresponding PDU session and bearers.

NOTE: The 5G-AN behaviour for dual connectivity is not described in this specification.

5.3.3.2 GTP-U Error Indication received by another UPF

Upon receipt of a GTP-U Error Indication, the UPF shall identify the related PFCP session and send an Error Indication Report to the SMF, as specified in clause 5.10 of 3GPP TS 29.244 [4].

Upon receipt of an Error Indication Report from the UPF, the SMF shall identify the PDU session for which the Error Indication is received using the remote F-TEID included in the report.

For a GTP-U Error Indication received from another UPF, the SMF shall delete the PFCP session and PDU session, unless the UPF from which the Error Indication was received is controlled by the same SMF and the SMF is able to restore the user plane connectivity of the PDU session (e.g. Error Indication received from an Intermediate UPF controlled by the same SMF).

5.4 Restoration Procedures upon User Plane Path Failure

Upon detecting a GTP-U user plane path failure as specified in clause 5.2.2, the UPF shall report the user plane path failure to the SMF, by sending a PFCP Node Report Request (see 3GPP TS 29.244 [4]) including a User Plane Path Failure Report with the IP address of the remote GTP-U peer(s) towards which a failure has been detected. The UPF should also notify the GTP-U user plane path failure via the Operation and Maintenance system.

Upon detecting a failed GTP-U user plane path become recovered, the UPF shall report the user plane path recovery to the SMF, by sending a PFCP Node Report Request (see 3GPP TS 29.244 [4]) including a User Plane Path Recovery Report with the IP address of the remote GTP-U peer(s) associated with the recovered user plane path. The UPF should also notify the GTP-U user plane path recovery via the Operation and Maintenance system.

When the SMF receives the PFCP Node Report Request with a User Plane Path Failure Report, the SMF may:

– delete the PDU session contexts associated with the path in failure; or

– maintain the PDU session contexts associated with the path in failure during an operator configurable maximum path failure duration. The SMF shall delete the PDU session contexts associated with the path in failure if the path is still down when this duration expires; or

NOTE 1: During transient path failures (e.g. path failures not exceeding few minutes at most), maintaining the PDU session contexts associated with the peer’s IP address enables the delivery of end user services (when the path is re-established again) and this also avoids unnecessary signalling in the network for restoring those PDU sessions.

NOTE 2: It is not intended to maintain PDU session contexts during long path failures (e.g. exceeding few minutes at most) as this would imply undesirable effects like undue charging.

– maintain the PDU session contexts associated with the path in failure if the path in failure is towards a 5G-AN. When deciding to maintain the PDU session contexts, it shall send a PFCP Session Modification Request message with changing Apply-Action from FORW to BUFF and NOCP for each affected PFCP session. In addition, upon receipt of subsequent downlink data notifications from the UPF or the service request from affected UE, the SMF will try to reestablish the PDU session resources in the NG-RAN. As an implementation option, the SMF may try to re-establish the PDU session resources in the NG-RAN for those PDU sessions associated with the user plane path in failure prior to receiving downlink data notifications from the UPF or service request from the affected UE.

NOTE 3: This approach (as above for user plane path failure towards a 5G-AN) allows to maintain the PDU session even for non-transient path failures. For a PDU session with I/V-SMF, the pause of charging (as specified in clause 4.4.4 of 3GPP TS 23.502 [5]) ensures that there is no undue charging.

When deciding to delete the PDU session contexts associated with the path in failure, the SMF shall modify or delete the affected PFCP sessions in the UPF.

NOTE 4: The SMF need to take care to smoothen the signalling load towards the UPF if a large number of PFCP sessions are affected by the user plane path failure.

5.5 Reporting of a Peer GTP-U Entity Restart

To reduce massive amount of N4 signalling to report the receiving of GTP-U Error Indication messages and to perform subsequent PFCP Session Modification for PFCP sessions affected by the peer GTP-U restart, a user plane function (UPF) and a control plane function (SMF) may optionally support reporting of a peer GTP-U entity restart.

A GTP-U entity, e.g. in a UPF, may detect the restart of the peer GTP-U entity as specified in clause 18A of 3GPP TS 23.007 [2].

When the user plane function detects the peer GTP-U entity has restarted via receiving one or more GTP-U Error Indication message(s) or Echo Request/Response message(s) containing a larger Recovery Time Stamp, and when the control plane function supports Reporting of a GTP-U Entity Restart, it shall send a PFCP Node Report Request message to the control plane function to report that:

– the peer GTP-U entity identified by Remote GTP-U Peer IE has restarted; and

– all PFCP sessions associated with the restarted peer GTP-U entity have been modified by the user plane function, i.e. the F-TEID(s) that had been allocated by the restarted GTP-U entity have been removed from the FARs and the Apply-Action in these FARs changed to BUFF and NOCP, if the restarted GTP-U entity is a 5G-AN.

NOTE: The UP function can learn if the restarted GTP-U entity is a 5G-AN by using the Destination Interface Type included in the Forwarding Parameters in the FAR (which contains the F-TEID that had been allocated by the restarted GTP-U entity). The control plane function shall send a PFCP Node Report Response message to acknowledge the receipt of the report of the peer GTP-U entity restart; and the control plane may further behave as if it receives a Error Indication Report for those PFCP sessions affected by the peer GTP-U entity restart, e.g. to trigger a Network Triggered Service Request procedure if the restarted GTP-U entity is a 5G-AN. (see also clause 5.3)