Content for TS 23.527 Word version: 18.2.0

1… 4… 5… 6… 6.6… 7… 8… 8.3… 8.3.2.4 8.3.3… 8.4…

5.1 General 5.2 User Plane Failure Detection 5.2.1 Loss of GTP-U contexts 5.2.2 User Plane Path Failure 5.3 Restoration Procedures upon Loss of GTP-U contexts 5.3.1 General 5.3.2 Procedure for GTP-U Error Indication received from 5G-AN 5.3.3 Procedure for GTP-U Error Indication received from UPF 5.4 Restoration Procedures upon User Plane Path Failure 5.5 Reporting of a Peer GTP-U Entity Restart
...

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

5.1 General p. 13

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 p. 13

5.2.1 Loss of GTP-U contexts p. 13

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 TS 29.281.

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 p. 13

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 TS 23.007.

5.3 Restoration Procedures upon Loss of GTP-U contexts p. 14

5.3.1 General p. 14

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 p. 14

5.3.2.1 Principles p. 14

Reproduction of 3GPP TS 23.527, Fig. 5.3.2.1-1: GTP-U Error Indication from 5G-AN

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

Step 1.

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

Step 2.

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

Step 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 TS 29.244.

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

Step 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 TS 23.502.

Step 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 TS 29.518, 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.

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

Step 8.

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

5.3.3 Procedure for GTP-U Error Indication received from UPF p. 15

5.3.3.1 GTP-U Error Indication received by 5G-AN p. 15

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. The 5G-AN should indicate to the SMF that the release is due to receiving the GTP-U Error Indication from the NG-U tunnel.
Upon receiving this information, the SMF may re-establish the PFCP session for the affected PDU session using the procedure specified in clause 4.3.2, if the related UPF is a PSA UPF or is an I-UPF controlled by the same SMF;
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.

5.3.3.2 GTP-U Error Indication received by another UPF p. 15

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 TS 29.244.

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 p. 15

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

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.
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 TS 23.502) ensures that there is no undue charging.

5.5 Reporting of a Peer GTP-U Entity Restart |R17| p. 16

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 TS 23.007.

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.