Improved GTP-U entity restart

Abstract

Disclosed herein is a method implemented by a control plane function (800) in a communications network (1302) for managing a restart of a user plane (UP) function in a user plane path for a protocol data unit (PDU) session managed by the CP function (800), the method including receiving (900) a Packet Forwarding Control Protocol (PFCP) message from the UP function (802) including a report relating to a restart of a UP-2 (804), acknowledging (902) the report, and performing (904) an action based on an identification of another UP-2 (804).

Description

[Background technology]

[0001] About 20 years ago, 3GPP decided to remove the use of recovery from the General Packet Radio Service (GPRS) Tunneling Protocol (GTP) echo response message for the user plane (GTP-U), which was defined as a restart counter for the GTP entity. At the time, because the GTP entity had a control plane (CP) portion and a user plane (UP) portion, communicating the restart counter for the GTP entity over both the control plane signaling path and the user plane payload path was redundant.

[0002] The use of the "Restart Counter" field in the "Recovery" information element in GTP-U messages was changed in March 2000 through 3GPP TS29.060 Rel-3 CR096, which was written into 3GPP TS29.060 V3.4.0 and implemented in 3GPP TS29.060 V3.5.0. The "Reason for Change" in the CR (3GPP TS29.060 Rel-3 CR 096) reads as follows: "The Restart Counter in the Echo Reply message is used to inform the peer node that the node has experienced a restart. Using the Restart Counter value in both GTP-U and GTP-C is unnecessary since it is sufficient to use the Restart Counter value only in GTP-C. Moreover, on the Iu interface, RANAP already has a procedure for node restart. Therefore, it is proposed that the Restart Counter value in the Echo Reply message is not used in GTP-U. The CR also proposes some clarifications on how to react when an Echo Reply is received."

[0003] Prior to 3GPP Rel-8, the normative specification for GTP-U was included together with GTPv1 in 3GPP TS 29.060. In 3GPP Rel-8, the normative specification for GTP-U was moved from 3GPP TS 29.060 to 3GPP TS 29.281. The text relating to GTP-U was effectively left "as written" in 3GPP TS 29.060, and a note was added at the beginning of Section 9 in the specification. The note reads as follows: "From Release 8 onwards, the normative specification for the GTP version 1 user plane is 3GPP TS 29.281

[41] . All clauses in this document relating to the GTPv1 user plane shall be superseded by 3GPP TS 29.281

[41] ."

[0004] Thus, as specified in TS 29.281, clause 7.2.2 states: "The Restart Counter value in the Recovery Information Element shall not be used, i.e., the Restart Counter value shall be set to 0 by the sender and ignored by the receiver. The Recovery Information Element is mandatory for backward compatibility reasons. Optional private extensions contain vendor or operator specific information." (emphasis added).

[0005] Figure 1 Figure 1 of the present disclosure includes Table 7.2.2-1 of Section 7.2.2 of TS29.281.

[0006] Furthermore, Section 7.7.114 ("ULI Timestamp") of TS29.281 discloses the following: "The ULI Timestamp IE is coded as shown in Figure 7.7.114-1. The ULI Timestamp IE indicates the UTC time at which the user location information was collected. Octets 4 through 7 are encoded in the same format as the first four octets of the 64-bit timestamp format specified in Section 6 of IETF RFC5905

[55] . Note: The encoding is specified as the time in seconds relative to 00:00:00 on January 1, 1900."

[0007] Figure 2 Figure 2 of this disclosure includes a diagram in section 7.7.114 of TS29.281 ("Figure 7.7.114-1: ULI Timestamp").

[0008] Therefore, 3GPP does not specify requirements regarding peer GTP-u restart, but only GTP-U path failure, for example, as stated in TS 23.527 for 5th generation systems (5GS):

[0009] TS 23.527, start of section 5.4 5.4 Recovery Procedures for User Plane Path Failures 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]) containing a User Plane Path Failure Report with the IP address(es) of the remote GTP-U peer(s) towards which the failure was detected. The UPF should also notify the GTP-U user plane path failure via the operation and maintenance system.

[0010] When the SMF receives a PFCP node report request with a user plane path failure report, the SMF may do the following: - deleting the PDU session context associated with the failed path, or - Maintain PDU session contexts related to a failed path for an operator-configurable maximum path failure duration. The SMF shall delete PDU session contexts related to a failed path if the path is still down when this duration expires. NOTE 1: During transient route failures (e.g., route failures lasting no more than a few minutes), maintaining the PDU session context associated with the peer's IP address allows delivery of end-user services (when the route is re-established again), and it also avoids unnecessary signaling in the network to restore those PDU sessions. NOTE 2: It is not intended to maintain PDU session context during long path failures (e.g., more than a few minutes at most), as this would imply undesirable effects such as excessive charging.

[0011] When it decides to delete the PDU session context related to the failed path, the SMF shall modify or delete the affected PFCP session in the UPF. NOTE 3: The SMF should take care to smooth the signalling load towards the UPF when a large number of PFCP sessions are affected by a user plane path failure. End of TS 23.527, Section 5.4

[0012] Also, in TS 23.007 for EPS, section 20.3 discloses the following:

[0013] TS23.007, start of section 20.3 20.3 User Plane Path Failure Detection and Handling 20.3.1 Overview A GTP-U entity shall support the detection of path failures through the use of Echo Request / Echo Reply messages in the following manner: A path counter shall be reset each time an Echo Reply is received on the path and incremented when the T3 Reply timer expires for an Echo Request message sent on the path. A path shall be considered down if the counter exceeds N3 Requests.

[0014] Upon detecting a path failure, the network node should notify the failure via the operation and maintenance system and may do one of the following: - deleting the bearer context associated with the failed path, or - Maintain bearer contexts associated with a failed path for an operator-configurable maximum path failure duration. The network node shall delete the maintained resources if the path is still down when this duration expires. End of TS23.007, Section 20.3

[0015] When a GTP-U entity receives a GTP-U packet without a corresponding context, the GTP-U entity will send a GTP error indication. Clause 7.3.1 of TS 29.281 discloses the following:

[0016] TS29.281, start of section 7.3.1 7.3.1 Error Indications When a GTP-U node receives a G-PDU for which no EPS bearer context, PDP context, PDU session, MBMS bearer context, or RAB exists, the GTP-U node shall discard the G-PDU. If the TEID of the incoming G-PDU is different from the value "all zeros", the GTP-U node shall also return a GTP error indication to the originating node. GTP entities may include the "UDP Port" extension header (type 0x40) to simplify the implementation of mechanisms that can mitigate the risk of denial-of-service attacks in some scenarios.

[0017] The handling of received error indications is specified in 3GPP TS 23.007 [3] and 3GPP TS 23.527

[33] .

[0018] The information element Tunnel Endpoint Identifier data I shall be the TEID fetched from the G-PDU that triggered this procedure.

[0019] The information element GTP-U Peer Address shall be the destination address (e.g. destination IP address, MBMS bearer context) fetched from the original user data message that triggered this procedure. The GTP-U Peer Address may be a GGSN, SGSN, RNC, PGW, SGW, ePDG, eNodeB, TWAN, MME, gNB, N3IWF, or UPF address. The TEID and the GTP-U Peer Address together uniquely identify the involved PDP context, RAB, PDU session or EPS bearer at the receiving node.

[0020] An optional private extension contains vendor or operator specific information. End of TS 29.281, Section 7.3.1

[0021] Figure 3 Figure 3 of this disclosure includes a table from TS 29.281, section 7.3.1 ("Table 7.3.1-1: Information Elements in Error Indications").

[0022] When a peer GTP-U entity receives a GTP error indication indicating that the user plane path for a given packet data network (PDN) connection / protocol data unit (PDU) session has been disconnected, this must be reported to a control plane function, e.g., a Serving Gateway Control Plane Function (SGW-C), or a PDN Gateway Control Plane Function (PGW-C), or a Session Management Function (SMF), which may then trigger the relevant control plane signaling procedures to request the restarting GTP-U entity (e.g., a New Generation Radio Access Network (NG-RAN)) to set up the user plane for that PDN connection.

[0023] Figure 4 4 includes a diagram ("Figure 5.3.2.1-1: GTP-U Error Indication from a 5G-AN") in section 5.3.2 ("Procedure for a GTP-U Error Indication Received from a 5G-AN") of TS 23.527. With respect to the diagram ("Figure 5.3.2.1-1: GTP-U Error Indication from a 5G-AN"), section 5.3.2 of TS 23.527 further discloses the following:

[0024] TS 23.527, start of section 5.3.2 1. The user plane connection for the 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 the 5G-AN does not have a corresponding GTP-U context (see Section 5.2). 3. Upon receiving a GTP-U error indication, the UPF shall identify the involved 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 the 5G-AN, the SMF shall modify the PFCP session to instruct the UPF to buffer downlink packets. 5. When the user plane connection of the PDU session is considered activated by the SMF, the SMF shall initiate the Namf_Communication_N1N2MessageTransfer service operation to request the 5G-AN to release the resources of the PDU session as specified in clause 4.3.7 of 3GPP TS23.502 [5]. 6. Upon receiving a Namf_Communication_N1N2MessageTransfer request to transfer a PDU session resource release command, the AMF shall do the following: - if the UE is in CM-CONNECTED state for the access network type associated with the PDU session, proceed with the request as specified in clause 5.2.2.3.1 of 3GPP TS 29.518 [6]; - Otherwise, reject the request with an error indicating that the UE is in CM-IDLE state for the access network type associated with the PDU session. 7. When the AMF sends a PDU session resource release command to the 5G-AN, the PDU session 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 reactivate the user plane connection of the PDU session. End of TS 23.527, Section 5.3.2

[0025] In TS29.244, clause 7.4.5.1.1 ("PFCP Node Report Request - General") discloses that "PFCP Node Report Requests shall be sent by the UP function on the Sxa, Sxb, Sxc and N4 interfaces to report information that is not specific to a PFCP session to the CP function."

[0026] Figure 5 Figure 5 of the present disclosure includes a table in section 7.4.5.1.1 of TS29.244 ("Table 7.4.5.1.1-1: Information Elements in a PFCP Node Report Request").

[0027] Figure 6 Figure 6 of the present disclosure includes a table ("Table 7.4.5.1.2-1: User Plane Path Failure Reporting IE in PFCP Node Report Request") of section 7.4.5.1.2 ("User Plane Path Failure Reporting IE in PFCP Node Report Request") of TS29.244.

[0028] Figure 7 Figure 7 of the present disclosure includes a diagram ("Figure 8.2.70-1: Remote GTP-U Peer") in section 8.2.70 ("Remote GTP-U Peer") of TS29.244. Summary of the Invention

[0029] Currently, one or more challenges exist: In the event of a GTP-U entity restart, e.g., when an NG-RAN (e.g., gNB) restarts, it will lose all its context and therefore will not be able to find the corresponding context for DL ​​GTP-U packets from the intermediate user plane function (I-UPF) or visiting UPF (V-UPF). This triggers the restarted GTP-U entity to send a large amount of GTP error indication messages, which leads to a large amount of signaling on the Sx / N4 interface as the UP function must report the receipt of the GTP error indication to the CP function.

[0030] When a GTP-U entity restarts, such extensive signaling on the GTP-U interface (to send a GTP error indication) and on Sx / N4 (to report receipt of a GTP error indication and Packet Forwarding Control Protocol (PFCP) session modification signaling to update the DL FAR) should be avoided.

[0031] Some aspects of the present disclosure and their embodiments may provide solutions to these or other problems. The present disclosure proposes embodiments for enabling a GTP-U entity (e.g., for an SGW-U, PGW-U, or UPF) to detect that a peer GTP-U entity has restarted and, when the peer GTP-U entity has restarted, to report the restart of the peer GTP-U entity to a CP function (e.g., an SGW-C, PGW-C, SMF) so that the CP function can restore the user plane path.

[0032] Embodiments of the disclosure include one or more of the following features. 1. Add a recovery timestamp in the echo reply message. The recovery timestamp may reuse the GTPv1 IE "ULI Timestamp" or a new IE with the same encoding as in the "ULI Timestamp" IE. 2. Add a recovery timestamp in the GTP error indication to populate a restart to the peer GTP-U entity as soon as possible. Some GTP-U entity implementations may not send echo requests / responses when there are payload packets in transit. In this case, the user plane path may be considered healthy. 3. Since a user plane function (UP function) may have multiple GTP-U entities identified by "IP address", add a list of IP addresses (affected by the restart) in the GTP error indication. 4. When the UP function detects that the peer GTP-U has restarted, it will send a "PFCP Node Report Request" message to the CP function. The PFCP Node Report Request message contains information that the peer GTP-U entity has restarted, along with a list of IP addresses and network instance / destination interfaces. Furthermore, the UP function indicates that it intends to remove the remote Fully Qualified Tunnel Endpoint Identifier (F-TEID) for all PFCP sessions affected by the peer GTP-U restart and set the application action to "buffering" in the FAR (which contains the remote F-TEID assigned by the remote GTP-U entity and therefore affected by the remote GTP-U restart); thus, the CP function does not need to send a "PFCP Session Modify Request" for each PFCP session to do this (e.g., the CP function removes the remote F-TEID and changes the application action in the FAR). 5. The CP function acknowledges the report that the peer GTP-U entity has restarted and that the F-TEID assigned by the restarting GTP-U entity has become invalid and should be removed from the affected PFCP session. 6. The CP function determines based on local configuration to release the PDU session affected by the remote GTP-U restart, for example, to release the affected PDU session if the restarting remote GTP-U entity is a PDU Session Anchor (PSA) UPF, or to restore the user plane connection for the affected PDU session if, for example, the restarting remote GTP-U entity is an NG-RAN (e.g., gNB) or RAN (e.g., eNB).

[0033] Some embodiments may provide one or more of the following technical advantage(s): Extensive signaling for GTP-U entity restart may be avoided if a GTP-U has lost all its GTP-U contexts and those GTP-U contexts cannot be restored by other means, for example, via the CP function of that GTP-U.

[0034] These and other objects, features and advantages of the present disclosure will become apparent from the following detailed description of illustrative embodiments thereof, which is to be read in connection with the accompanying drawings. [Brief explanation of the drawings]

[0035] [Figure 1] This figure includes Table 7.2.2-1 of Section 7.2.2 in TS29.281. [Figure 2] This figure includes the figure in Section 7.7.114 of TS29.281 ("Figure 7.7.114-1: ULI Timestamp"). [Figure 3] This figure includes the table from TS 29.281, section 7.3.1 ("Table 7.3.1-1: Information elements in an error indication"). [Figure 4] This figure includes a diagram ("Figure 5.3.2.1-1: GTP-U error indication from 5G-AN") in Section 5.3.2 ("Procedure for GTP-U error indication received from 5G-AN") of TS23.527. [Figure 5]This figure includes a table in section 7.4.5.1.1 of TS29.244 ("Table 7.4.5.1.1-1: Information elements in a PFCP node report request"). [Figure 6] This figure includes a table ("Table 7.4.5.1.2-1: User Plane Path Failure Reporting IE in PFCP Node Report Request") from section 7.4.5.1.2 of TS29.244 ("User Plane Path Failure Reporting IE in PFCP Node Report Request"). [Figure 7] This figure includes the figure ("Figure 8.2.70-1: Remote GTP-U Peer") in Section 8.2.70 ("Remote GTP-U Peer") of TS29.244. [Figure 8] FIG. 1 illustrates one embodiment of a procedure for detecting and reporting a peer GTP-U entity restart, according to one exemplary embodiment of the present disclosure. [Figure 9] FIG. 8 illustrates one embodiment in which CP-1 800 may perform several steps. [Figure 10] FIG. 1 illustrates an embodiment in which UP-1 802 may perform several steps. [Figure 11] FIG. 1 illustrates an embodiment in which UP-2 804 may perform several steps. [Figure 12] FIG. 8 illustrates one embodiment in which CP-1 800 may perform several steps. [Figure 13] FIG. 13 illustrates an example of a cellular communication system 1300 in which embodiments of the present disclosure may be implemented. [Figure 14] FIG. 1 illustrates a wireless communication system represented as a 5G network architecture assembled from core network functions (NFs), where interaction between any two NFs is represented by a point-to-point reference point / interface. [Figure 15] FIG. 15 illustrates a 5G network architecture that uses a service-based interface between NFs in a CP instead of the point-to-point reference point / interface used in the 5G network architecture of FIG. [Figure 16]16 is a schematic block diagram of a network node 1600 according to some embodiments of the present disclosure. [Figure 17] 16 is a schematic block diagram illustrating a virtualized embodiment of a network node 1600, in accordance with some embodiments of the present disclosure. [Figure 18] 16 is a schematic block diagram of a network node 1600 according to some other embodiments of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0036] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. The embodiments are provided by way of example and to convey the scope of the subject matter to those skilled in the art. Additional information may also be found in the document(s) provided in the appendices (Appendix 1 and Appendix 2).

[0037] Figure 8 Figure 8 shows one embodiment of a procedure for detecting and reporting a peer GTP-U entity restart according to one exemplary embodiment of the present disclosure. The procedure is performed by a CP function (“CP-1 800”), a first UP function (“UP-1 802”), and a second UP function (“UP-2 804”). CP-1 800 may be or may be implemented in an SGW-C, PGW-C, or SMF. UP-1 802 or UP-2 804 may be or may be implemented in a gNB, eNB, SGW-U, PGW-U, I-UPF (Intermediate UPF), or V-UPF (Visiting UPF). Figure 8 of the present disclosure shows the following steps: In steps 806 and 808, PFCP session establishment and modification request / response messages are used to set up a PFCP session between CP-1 800 and UP-1 802. The procedure allows CP-1 800 to provide UP-1 802 with the remote GTP-U's (UP-2 804) F-TEID (IP address + tunnel endpoint ID). In other words, the PFCP session establishment and modification request messages may include the remote GTP-U's F-TEID. Thus, UP-1 802 will send a payload toward the CP function, and at the same time, UP-1 802 will provide the CP function with UP-1 802's GTP-U F-TEID (used to receive payload from the remote GTP-U (UP-2 804)). The CP function will further use control plane signaling to populate UP-2 804 with UP-1's GTP-U F-TEID, for example via an NGAP signaling message (PDU Session Resource Setup Request message if UP-2 804 is an NG-RAN node). In steps 810 and 812, UP-1 802 may send an "echo request" to UP-2 804, where the echo request includes an IP address (in the F-TEID from UP-2 804) for probing the liveness of UP-2 804. The echo request includes recovery information for UP-1 802, identified by the source IP address of the echo request. UP-2 will reply with an "echo reply" message containing recovery information for UP-2, identified by the resource IP address of the echo reply. UP-1 802 will store the recovery information for UP-2 for future comparison. UP-2 804 may also send an "echo request" to UP-1 802. UP-2 804 may then also receive an "echo reply" from UP-1 802. Payloads are forwarded end-to-end, including segments between UP-1 802 and UP-2 804. UP-2 804 restarts and recovers from the restart, however, UP-2 804 has lost all of its GTP-U context, i.e., UP-2 804 cannot recognize the F-TEID that it assigned before its restart. In step 814, when restarting UP-2 804 receives a payload addressed to a GTP-U F-TEID that restarting UP-2 804 does not recognize, restarting UP-2 804 sends (1) a "GTP Error Indication" message containing the modified recovery information and (2) a list of IP addresses affected by the restart, i.e., all GTP-U contexts associated with these IP addresses have been lost. In step 816, UP-1 802 sends a "PFCP Node Report Request" message to CP-1 800, which indicates that (1) the peer UP (UP-2 804) has restarted and that the GTP-U context associated with the list of IP addresses (provided in the GTP Error Indication) has been lost, and (2) UP-1 802 should set the apply action in the DL FAR to "buffering" and remove the DL F-TEID (from UP-2 804) for all affected PFCP sessions, i.e., CP-1 800 does not need to send a "PFCP Session Modify Request" message to change the DL FAR for each PFCP session. In step 818, in response to the PFCP Node Report Request message, CP-1 800 sends a "PFCP Node Report Response" to UP-1 802, which includes an acknowledgment that the downlink FARs in all affected PFCP sessions (with the restarted UP-2 804) have been updated with the apply action set to "buffering" and that the remote F-TEID (from UP-2 804) has been removed. In step 820, CP-1 800 determines based on local configuration to release the PDU session affected by the remote GTP-U restart, for example, to release the affected PDU session if the restarting remote GTP-U entity is a PSA UPF, or to restore the user plane connection for the affected PDU session if, for example, the restarting remote GTP-U entity is an NG-RAN (e.g., gNB) or RAN (e.g., eNB).

[0038] Figure 9 In one embodiment, CP-1 800 may perform the following steps shown in FIG. In step 900, CP-1 800 receives a PFCP message from UP-1 802 containing a report related to UP-2 804 restarting the PFCP session. Optionally, the PFCP message is a PFCP Node Report Request message. Optionally, the report further includes an indication that UP-1 802 has removed the remote F-TEID(s) assigned by UP-2 804 for all affected PFCP sessions and changed the applied action in the FAR to "buffering." In step 902, CP-1 800 acknowledges the report, i.e., CP-1 800 will not send a PFCP Session Modify Request message to UP-1 802 to remove the remote F-TEID and change the applied action in the FAR. In step 904, CP-1 800 performs an action based on the identity of UP-2 804. In step 904A, CP-1 800 restores the user plane connection for the affected PDU session if UP-2 804 is a RAN or NG-RAN node. In step 904B, CP-1 800 releases the affected PDU session if UP-2 804 is a PSA UPF or PGW-U.

[0039] Figure 10 In one embodiment, UP-1 802 may perform the following steps shown in FIG. In step 1000, UP-1 802 sends an echo request to UP-2 804. Optionally, the echo request may include a recovery timestamp. In step 1002 , UP- 1 802 receives an echo response from UP- 2 804 . In step 1004 , UP- 1 802 receives an echo request from UP- 2 804 . In step 1006, UP-1 802 sends an echo response to UP-2 804. By this step, UP-1 802 and UP-2 804 have exchanged their recovery timestamps, and thus UP-1 802 and UP-2 804 know the F-TEIDs that were assigned before the new recovery timestamp (due to the restart) became invalid. The above steps 1000-1006 are exemplary steps for exchanging an echo request / echo response between UP-1 802 and UP-2 804. Therefore, the time order of steps 1000-1006 may be varied. For example, steps 1004 and 1006 may be performed before steps 1000 and 1002. In step 1008, UP-1 802 receives the GTP error indication, which includes a recovery timestamp. In step 1010, UP-1 802 compares the recovery timestamp received in the GTP error indication with recovery timestamps previously received via an echo request, echo reply, or GTP error indication. In step 1012, UP-1 802 determines that UP-2 804 has restarted. In step 1014, UP-1 802 stops sending further payloads to the restarted UP-2 804, for example, to avoid receiving further GTP error indications and overcharging the UE / PDU session affected by the restart of UP-2 804. In step 1016, UP-1 802 removes the F-TEID assigned by UP-2 804 and changes the "Applied Action" to "Buffering" since UP-1 802 is no longer sending payloads. In step 1018, UP-1 802 sends a PFCP request message to report the restart of UP-2 804. Optionally, the PFCP request message is a PFCP node report request message. In step 1020, UP-1 802 receives the PFCP response message.

[0040] Figure 11 In one embodiment, UP-2 804 may perform the following steps shown in FIG. In step 1100, UP-2 804 sends an echo request to UP-1 802. Optionally, the echo request includes a recovery timestamp. In step 1102 , UP- 2 804 receives an echo response from UP- 1 802 . In step 1104 , UP- 2 804 receives an echo request from UP- 1 802 . In step 1106, UP-2 804 sends an echo response to UP-1 802. By this step, UP-1 802 and UP-2 804 have exchanged their recovery timestamps, and thus UP-1 802 and UP-2 804 know the F-TEIDs that were assigned before the new recovery timestamps (due to the restart) became invalid. The above steps 1100-1106 are exemplary steps for exchanging echo requests / echo responses between UP-1 802 and UP-2 804. Therefore, the time order of steps 1100-1106 may be varied. For example, steps 1104 and 1106 may be performed before steps 1100 and 1102. In step 1108, UP-2 804 sends a GTP error indication to UP-1 802 that includes a new recovery timestamp.

[0041] Figure 12 In one embodiment, CP-1 800 may perform the following steps shown in FIG. In step 1208, CP-1 800 receives a Packet Forwarding Control Protocol (PFCP) request message from UP-1 802 containing a report relating to UP-2 804 restarting. In step 1210, CP-1 800 acknowledges the report by sending a PFCP response message to UP-1 802. In step 1212, CP-1 800 performs an action based on the identity of UP-2 804. If the identity of UP-2 804 is a RAN or NG-RAN node, the action is to restore the user plane connection for the affected PDU session. If the identity of UP-2 804 is a PSA UDF or PGW-U, the action is to release the affected PDU session. In one embodiment, UP-1 802 may perform the following steps shown in FIG. In steps 1200 and 1202 , UP- 1 802 exchanges echo requests and echo replies with UP- 2 804 . In step 1204, UP-1 802 receives the GTP error indication, which includes a recovery timestamp. In step 1206A, UP-1 802 compares the recovery timestamp received in the GTP error indication with recovery timestamps previously received via an echo request, echo reply, or GTP error indication. In step 1206B, UP-1 802 determines that UP-2 804 has restarted. In step 1206C, UP-1 802 stops sending further payloads to the restarted UP-2 804. In step 1206C, UP-1 802 removes the F-TEID assigned by UP-2 804 and changes the applied action to buffering. In step 1208, UP-1 802 sends a PFCP request message to report the restart of UP-2 804. In step 1210, UP-1 802 receives the PFCP response message. In one embodiment, UP-2 804 may perform the following steps shown in FIG. In steps 1200 and 1202 , UP-2 804 exchanges echo requests and echo replies with UP-1 802 . In step 1204, UP-2 804 sends a GTP error indication that includes a new recovery timestamp.

[0042] 3GPP changes The following illustrates some 3GPP changes (in the Stage 3 specification) to support this disclosure: Bold italicized text (or information elements) indicates new suggested changes to the 3GPP standard.

[0043] The following clauses of TS 29.281 (7.2.2 and 7.3.1) are proposed to be changed where indicated by the italicized bold text (or information elements):

[0044] Start of TS29.281 7.2.2 Echo Response The message shall be sent in response to a received echo request.

[0045] The Restart Counter value in the Recovery Information Element shall not be used, i.e., the Restart Counter value shall be set to 0 by the sender and ignored by the receiver. The Recovery Information Element is mandatory for backward compatibility reasons.

[0046] An optional private extension contains vendor or operator specific information. TIFF0007728459000001.tif29170

[0047] 7.3.1 Error Indications When a GTP-U node receives a G-PDU for which no EPS bearer context, PDP context, PDU session, MBMS bearer context, or RAB exists, the GTP-U node shall discard the G-PDU. If the TEID of the incoming G-PDU is different from the value "all zeros", the GTP-U node shall also return a GTP error indication to the originating node. GTP entities may include the "UDP Port" extension header (type 0x40) to simplify the implementation of mechanisms that can mitigate the risk of denial-of-service attacks in some scenarios.

[0048] The handling of received error indications is specified in 3GPP TS 23.007 [3] and 3GPP TS 23.527

[33] .

[0049] The information element Tunnel Endpoint Identifier data I shall be the TEID fetched from the G-PDU that triggered this procedure.

[0050] The information element GTP-U Peer Address shall be the destination address (e.g., destination IP address, MBMS bearer context) fetched from the original user data message that triggered this procedure. The GTP-U Peer Address may be a GGSN, SGSN, RNC, PGW, SGW, ePDG, eNodeB, TWAN, MME, gNB, N3IWF, or UPF address. The TEID and GTP-U Peer Address together uniquely identify the involved PDP context, RAB, PDU session, or EPS bearer at the receiving node. An optional private extension contains vendor- or operator-specific information. TIFF0007728459000002.tif50170

[0051] The following clauses of TS 29.244 are proposed to be changed where indicated by bold italicized text (or information elements):

[0052] Start of TS29.244 7.4.5.1.1 Overview The PFCP Node Report Request shall be sent by the UP function on the Sxa, Sxb, Sxc and N4 interfaces to report information that is not specific to a PFCP session to the CP function. TIFF0007728459000003.tif107170

[0053] 7.4.5.1.X Peer UP Restart Report IE in PFCP Node Report Request Table 7.4.5.1.X-1: User Plane Path Recovery Report IE in PFCP Node Report Request JPEG0007728459000004.jpg72170

[0054] 8.2.69 Node Report Type The Node Report Type IE shall be encoded as shown in Figure 8.2.69-1. The Node Report Type IE indicates the type of Node Report that the UP function sends to the CP function. TIFF0007728459000005.tif46170

[0055] Octet 5 shall be encoded as follows: - Bit 1 - UPFR (User Plane Path Failure Reporting): When set to "1", this indicates a User Plane Path Failure Reporting. - Bit 2 - UPRR (User Plane Path Recovery Report): When set to "1", this indicates a User Plane Path Recovery Report. Bit 3 - CKDR (Clock Drift Report): When set to "1", this indicates clock drift reporting. - Bit 4 - GPQR (GTP-U Path QoS Reporting): When set to "1", this indicates GTP-U Path QoS Reporting. - Bit 5 - PURR (Peer GTP-U Entity Restart Report): When set to "1", this indicates a Peer GTP-U Restart Report. - Bits 6-8 - Spare for future use and set to "0".

[0056] At least one bit shall be set to "1". Any number of bits may be set to "1". NOTE: If both the UPFR and UPRR bits are set to "1", the Remote GTP-U Peer IE in the User Plane Path Failure Report IE and the Remote GTP-U Peer IE in the User Plane Path Recovery Report IE are different.

[0057] The CP Function and UP Function must indicate their support of this new feature (described above) via the CP Function and UP Function features.

[0058] 8.2.58 CP Function Features The CP Function Features IE indicates the features supported by the CP function. Only features that have an impact on the (system-wide) UP function behavior are signaled in this IE. The CP Function Features IE is coded as shown in Figure 8.2.58-1. TIFF0007728459000006.tif46170

[0059] The CP Capability Features IE takes the form of a bit mask where each bit set indicates that the corresponding feature is supported. Spare bits shall be ignored by the receiver. The same bit mask is specified for all PFCP interfaces.

[0060] The following table specifies the features defined on the PFCP interface and the interfaces to which they apply. JPEG0007728459000007.jpg96170

[0061] 8.2.25 UP Function Features The UP Capability Features IE indicates the features supported by the UP Capability. The UP Capability Features IE is coded as shown in Figure 8.2.25-1. TIFF0007728459000008.tif57170

[0062] The UP Capabilities Features IE takes the form of a bit mask where each bit set indicates that the corresponding feature is supported. Spare bits shall be ignored by the receiver. The same bit mask is specified for all PFCP interfaces.

[0063] The following table specifies the features defined on the PFCP interface and the interfaces to which they apply. JPEG0007728459000009.jpg90170

[0064] Figure 13 13 illustrates an example of a cellular communication system 1300 in which embodiments of the present disclosure may be implemented. In the embodiments described herein, the cellular communication system 1300 is a 5G system (5GS) including a Next Generation RAN (NG-RAN) and a 5G Core (5GC). In this example, the RAN includes NR base stations (gNBs) in 5GS and optionally Next Generation eNBs (ng-eNBs) (e.g., LTE RAN nodes connected to 5GC), and includes eNBs in the EPS, including base stations 1302-1 and 1302-2, which control corresponding (macro) cells 1304-1 and 1304-2. Base stations 1302-1 and 1302-2 are generally referred to herein collectively as base stations 1302 and individually as base stations 1302. Similarly, (macro) cells 1304-1 and 1304-2 are generally referred to herein collectively as (macro) cells 1304 and individually as (macro) cells 1304. The RAN may also include several low-power nodes 1306-1 through 1306-4 that control corresponding small cells 1308-1 through 1308-4. The low-power nodes 1306-1 through 1306-4 may be small base stations (such as pico or femto base stations) or remote radio heads (RRHs), etc. Notably, although not shown, one or more of the small cells 1308-1 through 1308-4 may alternatively be provided by the base station 1302. The low-power nodes 1306-1 through 1306-4 are generally referred to herein collectively as low-power nodes 1306 and individually as low-power nodes 1306. Similarly, the small cells 1308-1 through 1308-4 are generally referred to herein collectively as small cells 1308 and individually as small cells 1308. The cellular communication system 1300 also includes a core network 1310, referred to as 5GC in 5G systems (5GS). The base stations 1302 (and optionally low power nodes 1306) are connected to the core network 1310.

[0065] Base station 1302 and low power node 1306 serve wireless communication devices 1312-1 through 1312-5 in corresponding cells 1304 and 1308. Wireless communication devices 1312-1 through 1312-5 are generally referred to herein collectively as wireless communication devices 1312 and individually as wireless communication devices 1312. In the following description, wireless communication devices 1312 are often UEs, although the disclosure is not limited thereto.

[0066] Figure 14 14 illustrates a wireless communication system represented as a 5G network architecture assembled from core network functions (NFs), where interaction between any two NFs is represented by a point-to-point reference point / interface. Figure 14 may be considered a specific implementation of the system 1300 of FIG. 13.

[0067] From the access side, the 5G network architecture shown in Figure 14 comprises either a RAN 1302 or an access network (AN) and multiple UEs 1312 connected to an AMF 1400. Generally, the RAN 1302 comprises a base station, for example, an eNB or gNB or the like. From the core network side, the 5GC NFs shown in Figure 14 include an NSSF 1402, an AUSF 1404, a UDM 1406, an AMF 1400, an SMF 1408, a PCF 1410, and an application function (AF) 1412.

[0068] The 5G network architecture reference point representation is used to develop detailed call flows in the standardization. An N1 reference point is defined to carry signaling between the UE 1312 and the AMF 1400. Reference points for connecting between the AN 1302 and the AMF 1400 and between the AN 1302 and the UPF 1414 are defined as N2 and N3, respectively. There is a reference point N11 between the AMF 1400 and the SMF 1408, which implies that the SMF 1408 is at least partially controlled by the AMF 1400. N4 is used by the SMF 1408 and the UPF 1414; therefore, the UPF 1414 can be set using a control signal generated by the SMF 1408, and the UPF 1414 can report its status to the SMF 1408. N9 is a reference point for connection between different UPFs 1414, and N14 is a reference point for connection between different AMFs 1400, respectively. N15 and N7 are defined because the PCF 1410 applies policies to the AMF 1400 and SMF 1408, respectively. N12 is required for the AMF 1400 to perform authentication of the UE 1312. N8 and N10 are defined because subscription data of the UE 1312 is required for the AMF 1400 and SMF 1408.

[0069] The 5GC network aims to separate the UP and CP. The UP carries user traffic, and the CP carries signaling within the network. In Figure 14, the UPF 1414 is in the UP, and all other NFs, namely, the AMF 1400, SMF 1408, PCF 1410, AF 1412, NSSF 1402, AUSF 1404, and UDM 1406, are in the CP. Separating the UP and CP ensures that each plane resource is scaled independently. Separating the UP and CP also allows the UPF to be distributed and deployed separately from the CP function. In this architecture, the UPF can be deployed very close to the UE to reduce the round-trip time (RTT) between the UE and the data network for some applications requiring low latency.

[0070] The core 5G network architecture is assembled from modularized functions. For example, the AMF 1400 and SMF 1408 are independent functions in the CP. The separated AMF 1400 and SMF 1408 allow for independent evolution and scaling. Other CP functions, such as the PCF 1410 and AUSF 1404, can be separated as shown in Figure 14. The modularized functional design allows the 5GC network to flexibly support various services.

[0071] Each NF interacts directly with another NF. It is possible to use intermediate functions to route messages from one NF to another. In a CP, a set of interactions between two NFs is specified as a service, and therefore its reusability is possible. This service allows for modularity support. A UP supports interactions, such as forwarding operations, between different UPFs.

[0072] Figure 15 Figure 15 shows a 5G network architecture that uses a service-based interface between NFs in a CP instead of the point-to-point reference point / interface used in the 5G network architecture of Figure 14. However, the NFs described above with reference to Figure 14 correspond to the NFs shown in Figure 15. The service(s) that an NF provides to other authorized NFs may be exposed to authorized NFs through the service-based interface. In Figure 15, the service-based interface is indicated by the letter "N" followed by the name of the NF, for example, Namf for the service-based interface of the AMF 1400 and Nsmf for the service-based interface of the SMF 1408. The NEF 1500 and NRF 1502 in Figure 15 are not shown in Figure 14 described above. However, it should be clarified that, although not explicitly indicated in Figure 14, all NFs shown in Figure 14 can interact with the NEF 1500 and NRF 1502 in Figure 15 as necessary.

[0073] Some characteristics of the NFs shown in Figures 14 and 15 can be described in the following manner: The AMF 1400 provides UE-based authentication, authorization, mobility management, etc. The AMF 1400 is independent of access technology, so even a UE 1312 using multiple access technologies is essentially connected to a single AMF 1400. The SMF 1408 is responsible for session management and assigns an Internet Protocol (IP) address to the UE. The SMF 1408 also selects and controls the UPF 1414 for data forwarding. If the UE 1312 has multiple sessions, a different SMF 1408 may be assigned to each session to manage the multiple sessions separately and possibly provide different capabilities for each session. The AF 1412 provides information about packet flows to the PCF 1410, which is responsible for policy control, to support QoS. Based on that information, the PCF 1410 determines policies related to mobility and session management to ensure the AMF 1400 and SMF 1408 operate appropriately. The AUSF 1404 supports authentication functions for the UE or the like and therefore stores data for authentication of the UE or the like, and the UDM 1406 stores subscription data of the UE 1312. Data networks (DNs) that are not part of the 5GC network provide internet access or operator services and the like.

[0074] An NF may be implemented either as a network element on dedicated hardware, as a software instance running on dedicated hardware, or as a virtualized function instantiated on a suitable platform, e.g., a cloud infrastructure.

[0075] Figure 16 16 is a schematic block diagram of a network node 1600 according to some embodiments of the present disclosure. Optional features are represented by dotted boxes. The network node 1600 may be, for example, a core network node implementing an NF (e.g., the AMF 1400, the SMF 1408, or the NSACF 1504), or a network node implementing all or a portion of the functionality of an NF (e.g., all or a portion of the functionality of the AMF 1400, the SMF 1408, or the NSACF 1504 described herein). As shown, the network node 1600 includes one or more processors 1604 (e.g., a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), etc.), a memory 1606, and a network interface 1608. The one or more processors 1604 are also referred to herein as processing circuits. The one or more processors 1604 operate to provide one or more functions of the network node 1600 described herein (e.g., one or more functions of the AMF 1400, SMF 1408, or NSACF 1504 described herein). In some embodiments, the function(s) are implemented in software, e.g., stored in the memory 1606 and executed by the one or more processors 1604. An example of the network node 1600 may include CP-1 800, UP-1 802, and UP-2 804 in FIG. 8.

[0076] Figure 17 17 is a schematic block diagram illustrating a virtualized embodiment of a network node 1600 in accordance with some embodiments of the present disclosure. Again, optional features are represented by dotted boxes. As used herein, a “virtualized” network node is an implementation of a network node 1600 in which at least a portion of the functionality of the network node 1600 is implemented as virtual component(s) (e.g., via virtual machine(s) executing on physical processing node(s) in network(s)). As shown, in this example, the network node 1600 includes one or more processing nodes 1700 coupled to or included as part of network(s) 1702. Each processing node 1700 includes one or more processors 1704 (e.g., CPUs, ASICs, FPGAs, etc.), memory 1706, and a network interface 1708. In this example, the functions 1710 of network node 1600 described herein (e.g., one or more functions of AMF 1400, SMF 1408, or NSACF 1504 described herein) are implemented in one or more processing nodes 1700 or distributed in any desired manner across two or more processing nodes 1700. In some particular embodiments, some or all of the functions 1710 of network node 1600 described herein are implemented as virtual components executed by one or more virtual machines implemented in virtual environment(s) hosted by processing node(s) 1700.

[0077] In some embodiments, a computer program is provided that includes instructions that, when executed by at least one processor, cause the at least one processor to perform functions of network node 1600 or a node (e.g., processing node 1700) that implements one or more of the functions 1710 of network node 1600 in a virtual environment in accordance with any of the embodiments described herein. In some embodiments, a carrier is provided that comprises the above-mentioned computer program product. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer-readable storage medium (e.g., a non-transitory computer-readable medium such as a memory).

[0078] Figure 18 18 is a schematic block diagram of a network node 1600 in accordance with some other embodiments of the present disclosure. Network node 1600 includes one or more modules 1800, each of which is implemented in software. Module(s) 1800 provide the functionality of network node 1600 described herein. This description is equally applicable to processing node 1700 of FIG. 17, where module 1800 may be implemented in one of processing nodes 1700 or distributed across multiple processing nodes 1700.

[0079] While the computing devices (e.g., UEs, network nodes, hosts) described herein may include the depicted combinations of hardware components, other embodiments may comprise computing devices with different combinations of components. It should be understood that these computing devices may comprise any suitable combination of hardware and / or software required to perform the tasks, features, functions, and methods disclosed herein. The determining, calculating, obtaining, or similar operations described herein may be performed by processing circuitry, which may process information by, for example, transforming the obtained information to other information, comparing the obtained or transformed information to information stored in a network node, and / or performing one or more operations based on the obtained or transformed information and as a result of the processing making a decision. Moreover, while a component is illustrated as a single box located within a larger box or nested within multiple boxes, in reality the computing device may comprise multiple different physical components that make up the single depicted component, and functionality may be partitioned among the separate components. For example, a communications interface may be configured to include any of the components described herein, and / or the functionality of those components may be partitioned between the processing circuitry and the communications interface. In another example, non-computationally intensive functionality of any of such components may be implemented in software or firmware, and computationally intensive functionality may be implemented in hardware.

[0080] In some embodiments, some or all of the functionality described herein may be provided by a processing circuit executing instructions stored in a memory, which in some embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuit without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hardwired manner. In any of these particular embodiments, the processing circuit may be configured to perform the described functionality, regardless of whether or not it executes instructions stored on a non-transitory computer-readable storage medium. Benefits provided by such functionality are not limited to the processing circuit alone or to other components of the computing device, but are enjoyed by the computing device as a whole and / or by end users and wireless networks generally.

[0081] Overview of Some Embodiments Some of the above-described embodiments can be summarized in the following manner.

[0082] 1. A method implemented by a control plane function (CP-1) (800) in a communications network (1302) for managing a re-initiation of a user plane (UP) function in a user plane path for a protocol data unit (PDU) session managed by the CP-1 (800), the method comprising: Receiving a Packet Forwarding Control Protocol (PFCP) message (900, FIG. 9) from a UP function (UP-1) (802) containing a report relating to the restart of another UP function (UP-2) (804); Acknowledging the report (Figure 9, 902); Taking action based on the identity of another UP-2 (804) (Figure 9, 904) A method comprising:

[0083] 2. The method described in embodiment 1, wherein the identification information of UP-2 (804) is a radio access node (RAN) or a new generation (NG)-RAN node, and the action is to restore user plane connectivity for the affected PDU session (FIG. 9, 904A).

[0084] 3. The method according to embodiment 1, wherein the identification information of UP-2 (804) is PSA UDF or PGW-U, and the action is to release the affected PDU session (FIG. 9, 904B).

[0085] 4. The method according to any one of embodiments 1 to 3, wherein the PFCP message is a PFCP node report request message.

[0086] 5. The method according to any one of embodiments 1 to 4, wherein the report includes an indication that UP-1 (802) has removed the remote F-TEID assigned by UP-2 (804) for the affected PFCP session and changed the application action in the FAR to buffering.

[0087] 6. The method according to any one of embodiments 1 to 5, wherein the CP-1 (800) is implemented in one or more of: (a) a serving gateway control plane function (SGW-C); (b) a packet data network (PDN) gateway control plane function (PGW-C); and (c) a session management function (SMF).

[0088] 7. A method implemented in a communications network (1302) by a first user plane function (UP-1) (802) in communication with a control plane function (CP-1) (800) and a second user plane function (UP-2) (804) for managing a peer UP function re-initiation, the method comprising: Sending an echo request to UP-2 (804) (Fig. 10, 1000); Receiving an echo response from UP-2 (804) (Figure 10, 1002); Receiving an echo request from UP-2 (804) (Figure 10, 1004); Sending an echo reply to UP-2 (804) (Figure 10, 1006); receiving a GTP error indication including a recovery timestamp (FIG. 10, 1008); Comparing the recovery timestamp received in the GTP Error Indication with a recovery timestamp previously received via an Echo Request, Echo Reply, or GTP Error Indication (FIG. 10, 1010); · Determining that UP-2 (804) has restarted (Figure 10, 1012); Stopping sending further payloads to the restarted UP-2 (804) (Figure 10, 1014); Remove the F-TEID assigned by UP-2 (804) and change the application action to buffering (Figure 10, 1016); Sending a PFCP request message to report the restart of UP-2 (804) (Figure 10, 1018); Receiving a PFCP response message (Figure 10, 1020) A method comprising:

[0089] 8. The method of embodiment 7, wherein the echo request sent by the UP-1 (802) includes a recovery timestamp.

[0090] 9. The method of embodiment 7 or 8, wherein the UP-1 (802) is implemented in one or more of: (a) a New Radio (NR) Node B (gNB); (b) an Evolved Node B (eNB); (c) a Serving Gateway Control Plane Function (SGW-U); (d) a Packet Data Network (PDN) Gateway Control Plane Function (PGW-U); (e) an Intermediate User Plane Function (I-UPF); (f) a Visited User Plane Function (V-UPF); and (g) a Protocol Data Unit (PDU) Session Anchor (PSA) UPF.

[0091] 10. The method according to any one of embodiments 7 to 9, wherein the echo request sent by the UP-1 (802) includes recovery information of the UP-1 (802) identified by the source IP address of the echo request sent by the UP-1 (802).

[0092] 11. The method according to any one of embodiments 7 to 10, wherein the echo response received by UP-1 (802) includes recovery information of UP-2 (804) identified by the resource IP address of the echo response received by UP-1 (802).

[0093] 12. The method of any one of embodiments 7 to 11, wherein the PFCP request message is a PFCP node report request message.

[0094] 13. The method of embodiment 12, wherein the PFCP node report request message indicates that the UP-2 (804) has restarted and that the GTP-U context associated with the list of IP addresses has been lost.

[0095] 14. The method of embodiment 12, wherein the PFCP node report response message includes an acknowledgement that the downlink FARs in all affected PFCP sessions have been updated with the apply action set to buffering and the remote F-TEID has been removed.

[0096] 15. A method implemented in a communications network (1302) by a second user plane function (UP-2) (804) in communication with a control plane function (CP-1) (800) and a first user plane function (UP-1) (802) for managing re-initiation of UP functions, the method comprising: Sending an echo request to UP-1 (802) (Fig. 11, 1100); Receiving an echo response from UP-1 (802) (Figure 11, 1102); Receiving an echo request from UP-1 (802) (Figure 11, 1104); Sending an echo reply to UP-1 (802) (Figure 11, 1106); Sending a GTP Error Indication containing a new recovery timestamp (Figure 11, 1108); A method comprising:

[0097] 16. The method of embodiment 15, wherein the echo request sent by UP-2 (804) includes a recovery timestamp.

[0098] 17. The method of embodiment 15 or 16, wherein UP-2 (804) is implemented in one or more of: (a) a new radio (NR) Node B (gNB); (b) an evolved Node B (eNB); (c) a serving gateway control plane function (SGW-U); (d) a packet data network (PDN) gateway control plane function (PGW-U); (e) an intermediate user plane function (I-UPF); (f) a visiting user plane function (V-UPF); and (g) a protocol data unit (PDU) session anchor (PSA) UPF.

[0099] 18. A network node (1308) implementing a control plane function (CP-1) (800), Receiving a Packet Forwarding Control Protocol (PFCP) message from UP-1 (802) containing a report relating to the restart of UP-2 (804) (FIG. 9, 900); Acknowledging the report (Figure 9, 902); Implementing actions based on the identification information of UP-2 (804) (Figure 9, 904) A network node (1308) adapted to perform the above.

[0100] 19. A network node (1600) implementing CP-1 (800) as described in embodiment 18, wherein the network node (1600) is further adapted to perform a method described in any one of embodiments 2 to 6.

[0101] 20. A network node (1600) implementing a control plane function (CP-1) (800), the network node (1600) comprising a processing circuit, the processing circuitry providing the network node (1600): Sending and receiving Packet Forwarding Control Protocol (PFCP) messages from UP-1 (802) containing reports relating to the restart of UP-2 (804) (FIG. 9, 900); Acknowledging the report (Figure 9, 902); Implementing actions based on the identification information of UP-2 (804) (Figure 9, 904) A network node (1600) configured to perform the above.

[0102] 21. A network node (1600) implementing CP-1 (800) as described in embodiment 20, wherein the processing circuitry is further configured to cause the network node (1600) to perform a method as described in any one of embodiments 2 to 6.

[0103] 22. A network node (1600) implementing a first user plane function (UP-1) (802), Sending an echo request to UP-2 (804) (Fig. 10, 1000); Receiving an echo response from UP-2 (804) (Figure 10, 1002); Receiving an echo request from UP-2 (804) (Figure 10, 1004); Sending an echo reply to UP-2 (804) (Figure 10, 1006); receiving a GTP error indication including a recovery timestamp (FIG. 10, 1008); Comparing the recovery timestamp received in the GTP Error Indication with a recovery timestamp previously received via an Echo Request, Echo Reply, or GTP Error Indication (FIG. 10, 1010); · Determining that UP-2 (804) has restarted (Figure 10, 1012); Stopping sending further payloads to the restarted UP-2 (804) (Figure 10, 1014); Remove the F-TEID assigned by UP-2 (804) and change the application action to buffering (Figure 10, 1016); Sending a PFCP request message to report the restart of the second UP function (Figure 10, 1018); Receiving a PFCP response message (Figure 10, 1020) A network node (1600) adapted to perform the following.

[0104] 23. A network node (1600) implementing UP-1 (802) as described in embodiment 22, wherein the network node (1600) is further adapted to perform a method as described in any one of embodiments 8 to 14.

[0105] 24. A network node (1600) implementing a first user plane function (UP-1) (802), the network node (1600) comprising a processing circuit, the processing circuitry causing the network node (1600) to: Sending an echo request to UP-2 (804) (Fig. 10, 1000); Receiving an echo response from UP-2 (804) (Figure 10, 1002); Receiving an echo request from UP-2 (804) (Figure 10, 1004); Sending an echo reply to UP-2 (804) (Figure 10, 1006); receiving a GTP error indication including a recovery timestamp (FIG. 10, 1008); Comparing the recovery timestamp received in the GTP Error Indication with a recovery timestamp previously received via an Echo Request, Echo Reply, or GTP Error Indication (FIG. 10, 1010); · Determining that UP-2 (804) has restarted (Figure 10, 1012); Stopping sending further payloads to the restarted UP-2 (804) (Figure 10, 1014); Remove the F-TEID assigned by UP-2 (804) and change the application action to buffering (Figure 10, 1016); Sending a PFCP request message to report the restart of the second UP function (Figure 10, 1018); Receiving a PFCP response message (Figure 10, 1020) A network node (1600) configured to perform the above.

[0106] 25. A network node (1600) implementing UP-1 (802) as described in embodiment 24, wherein the processing circuitry is further configured to cause the network node (1600) to perform a method as described in any one of embodiments 8 to 14.

[0107] 26. A network node (1600) implementing a second user plane function (UP-2) (804), Sending an echo request to UP-1 (802) (Fig. 11, 1100); Receiving an echo response from UP-1 (802) (Figure 11, 1102); Receiving an echo request from UP-1 (802) (Figure 11, 1104); Sending an echo reply to UP-1 (802) (Figure 11, 1106); Sending a GTP Error Indication containing a new recovery timestamp (Figure 11, 1108); A network node (1600) adapted to perform the following.

[0108] 27. A network node (1600) implementing UP-2 (804) as described in embodiment 26, wherein the network node (1600) is further adapted to perform the method described in embodiment 16 or 17.

[0109] 28. A network node (1600) implementing a second user plane function (UP-2) (804), the network node (1600) comprising a processing circuit, the processing circuitry causing the network node (1600) to: Sending an echo request to UP-1 (802) (Fig. 11, 1100); Receiving an echo response from UP-1 (802) (Figure 11, 1102); Receiving an echo request from UP-1 (802) (Figure 11, 1104); Sending an echo reply to UP-1 (802) (Figure 11, 1106); Sending a GTP Error Indication containing a new recovery timestamp (Figure 11, 1108); A network node (1600) configured to perform the above.

[0110] 29. A network node (1600) implementing UP-2 (804) as described in embodiment 28, wherein the processing circuitry is further configured to cause the network node (1600) to perform a method as described in embodiment 27 or 28.

[0111] 30. A method implemented in a communications network (1302) by a control plane function (CP-1) (800), a first user plane function (UP-1) (802), and a second user plane function (UP-2) (804) for managing a peer UP function re-initiation, the method comprising: At CP-1(800), o receiving a Packet Forwarding Control Protocol (PFCP) request message from UP-1 (802) containing a report relating to the restart of UP-2 (804) (FIG. 12, 1208); Acknowledging the report by sending a PFCP Response message (Figure 12, 1210); ○ Implementing actions based on the identification information of UP-2 (804) (Fig. 12, 1212); In UP-1(802), Sending an echo request to UP-2 (804) (Figure 12, 1200); Receiving an echo reply from UP-2 (804) (Figure 12, 1200); Receiving an echo request from UP-2 (804) (Figure 12, 1202); Sending an echo reply to UP-2 (804) (Figure 12, 1202); receiving a GTP error indication containing a recovery timestamp (FIG. 12, 1204); Comparing the recovery timestamp received in the GTP Error Indication with a recovery timestamp previously received via an Echo Request, Echo Reply, or GTP Error Indication (FIG. 12, 1206A); Determining that UP-2 (804) has restarted (Figure 12, 1206B); Stopping sending further payloads to the restarted UP-2 (804) (Figure 12, 1206C); and Remove the F-TEID assigned by UP-2 (804) and change the application action to buffering (Figure 12, 1206D); Sending a PFCP request message to report the restart of UP-2 (804) (Figure 12, 1208); Receiving a PFCP response message (Figure 12, 1210); In UP-2(804), Sending an echo request to UP-1 (802) (Figure 12, 1202), Receiving an echo response from UP-1 (802) (Figure 12, 1202); Receiving an echo request from UP-1 (802) (Figure 12, 1200); Sending an echo reply to UP-1 (802) (Figure 12, 1200); Sending a GTP Error Indication containing a new recovery timestamp (Figure 12, 1204) A method comprising:

[0112] 31. The method of embodiment 30, wherein the identity of UP-2 (804) is a radio access node (RAN) or a new generation (NG)-RAN node, and the action is to restore user plane connectivity for the affected PDU session (FIG. 9, 904A).

[0113] 32. The method of embodiment 30, wherein the identification information of UP-2 (804) is PSA UDF or PGW-U, and the action is to release the affected PDU session (FIG. 9, 904B).

[0114] 33. A method implemented in a communications network (1302) by a control plane function (CP-1) (800), a first user plane function (UP-1) (802), and a second user plane function (UP-2) (804), for detecting a restart of UP-2 (804) and reporting the restart to CP-1 (800) to restore a user plane path, the method comprising: In UP-2(804), Sending a General Packet Radio Service Tunneling Protocol (GTP) Error Indication message to UP-1 (802) after the restart of UP-2 (804) (Figure 8, 814); In UP-1(802), Sending a PFCP Node Report Request message to CP-1 (800) (Figure 8, 816); At CP-1(800), Releasing (820, Figure 8) the Protocol Data Unit (PDU) sessions affected by the restart of UP-2 (804) after receiving a PFCP Node Report Request message from UP-1 (802); A method comprising:

[0115] 34. In UP-1(802), Sending an echo request to UP-2 (804) (Figure 8, 810); Receiving an echo reply from UP-2 (804) (Figure 8, 810); Receiving a GTP Error Indication message (Figure 8, 814); In UP-2(804), Sending an echo request to UP-1 (802) (Figure 8, 812); Receiving an echo response from UP-1 (802) (Figure 8, 812); In UP-1(802), o Receive a PFCP node report response message from CP-1 (800) (Figure 8, 818) 34. The method of embodiment 33, further comprising:

[0116] 35. The method of embodiment 34, wherein the echo request sent by UP-1 (802) includes recovery information of UP-1 (802) identified by the source IP address of the echo request sent by UP-1 (802).

[0117] 36. The method of embodiment 34, wherein the echo response received by UP-1 (802) includes recovery information for UP-2 (804), which is identified by the resource IP address of the echo response received by UP-1 (802).

[0118] 37. The method of any one of embodiments 33 to 36, wherein CP-1 (800) is implemented in one or more of: (a) a serving gateway control plane function (SGW-C); (b) a packet data network (PDN) gateway control plane function (PGW-C); and (c) a session management function (SMF).

[0119] 38. The method of any one of embodiments 33 to 37, wherein the UP-1 (802) is implemented in one or more of: (a) a new radio (NR) Node B (gNB); (b) an evolved Node B (eNB); (c) a serving gateway control plane function (SGW-U); (d) a packet data network (PDN) gateway control plane function (PGW-U); (e) an intermediate user plane function (I-UPF); (f) a visiting user plane function (V-UPF); and (g) a protocol data unit (PDU) session anchor (PSA) UPF.

[0120] 39. The method of any one of embodiments 33 to 38, wherein UP-2 (804) is implemented in one or more of: (a) a new radio (NR) Node B (gNB); (b) an evolved Node B (eNB); (c) a serving gateway control plane function (SGW-U); (d) a packet data network (PDN) gateway control plane function (PGW-U); (e) an intermediate user plane function (I-UPF); (f) a visiting user plane function (V-UPF); and (g) a protocol data unit (PDU) session anchor (PSA) UPF.

[0121] 40. The method of any one of embodiments 33 to 39, wherein the GTP error indication message includes recovery information.

[0122] 41. The method of any one of embodiments 40, wherein the GTP error indication message further includes a list of IP addresses affected by the restart of UP-2 (804).

[0123] 42. The method according to any one of embodiments 33 to 41, wherein the PFCP node report request message indicates that the UP-2 (804) has restarted and that the GTP-U context associated with the list of IP addresses has been lost.

[0124] 43. The method of any one of embodiments 33 to 41, wherein the PFCP node report response message includes an acknowledgement that the downlink FARs in all affected PFCP sessions have been updated with the apply action set to buffered and the remote F-TEID has been removed.

[0125] Abbreviation At least some of the following abbreviations may be used in this disclosure. In the event of inconsistencies between abbreviations, the abbreviation as used above should prevail. If listed multiple times below, the first listing should prevail over the subsequent listing(s). 2G Second Generation 3G 3rd generation 3GPP 3rd Generation Partnership Project 4G 4th Generation 5G (5th Generation) 5GS 5th Generation System 6G 6th generation AMF Access and Mobility Management Functions AP Access point BS base station BSC Base Station Controller BTS Base Transceiver Station DL Downlink eNB Evolved Node B E-UTRA Enhanced Universal Terrestrial Radio Access E-UTRAN Evolved Universal Mobile Telecommunications System Terrestrial Radio Access Network F-TEID Fully Qualified Tunnel Endpoint Identifier gNB NR Node B GPRS General Packet Radio Service GSM Global System for Mobile Communications GTP General Packet Radio Service Tunneling Protocol HSS Home Subscriber Server IoT Internet of Things I-UPF Intermediate User Plane Function LTE Long Term Evolution MME Mobility Management Entity MSC Mobile Switching Center MTC Machine Type Communication NEF network publishing function NFV Network Functions Virtualization NR new radio O&M operation and maintenance OSS Operational Support System OTT Over-the-top PDN Packet Data Network PDU Protocol Data Unit PFCP Packet Forwarding Control Protocol PGW Packet Gateway PGW-C Packet Data Network (PDN) Gateway Control Plane Function PLMN Public Land Mobile Network RAN Radio Access Network RAT Radio Access Technology RNC Radio Network Controller SGW Serving Gateway SGW-C Serving gateway control plane function SMF Session Management Facility TCP / IP Transmission Control Protocol / Internet Protocol UE User Equipment UL Uplink UMTS Universal Mobile Telecommunications System UPF User Plane Function USIM Universal Subscriber Identity Module WCDMA Wideband Code Division Multiple Access WLAN Wide Local Area Network Appendix 1 3GPP TSG-CT WG4 meeting #107-e C4-216xyz Electronic conference, November 15-25, 2021 TIFF0007728459000010.tif24170About using this format help About: You can find comprehensive instructions below. http: / / www.3gpp.org / Change-Requests TIFF0007728459000011.tif15170TIFF0007728459000012.tif92170TIFF0007728459000013.tif45170TIFF0007728459000014.tif36170TIFF0007728459000015.tif15170TIFF0007728459000016.tif917018A GTP-U based restart procedure Across GTP-U based interfaces, i.e., the S1-U, S11-U, S2a, S2b, X2, S4, S5, S8, S12, M1 and Sn interfaces of Evolved Packet systems in EPS, and the F1-U, Xn, N3, N9, N19, N3mb and N19mb interfaces of 5G systems in 5GS, GTP-U entities may utilize GTP-U Echo Request and Echo Reply messages or GTP-U Error Indication messages containing a Recovery Timestamp information element to detect and handle restarts. A GTP-U entity shall be prepared to receive an Echo Request message at any time (even from an unknown peer), and the GTP-U entity shall reply with an Echo Reply message. A GTP-U entity has two recovery timestamps: - the remote recovery timestamps, in volatile memory, of the peer GTP-U entities with which the entity is in contact; - or the local recovery timestamp sent to the peer GTP-U entity in the non-volatile memory itself shall be maintained. After a GTP-U entity (re)initializes, the GTP-U entity shall immediately update all local recovery timestamps and clear all remote recovery timestamps. When peer GTP-U entity information is available, e.g., when the first GTP-U tunnel towards the peer GTP-U entity is to be established, the (re)initiating GTP-U entity may send the (re)initiating GTP-U entity's (updated) recovery timestamp in an Echo Request message to the peer GTP-U entity before sending any GTP-U packets. A GTP-U entity may have a common local recovery timestamp for all peer GTP-U entities, or the GTP-U entity may have a separate local recovery timestamp for each peer GTP-U entity. A GTP-U entity may probe the liveness of each peer GTP-U entity with which it is in contact by sending an Echo Request message. The recovery timestamps signaled in GTP-U echo request and response messages are relative to the GTP-U entity identified by the source IP address of the message. The recovery timestamp signaled in a GTP-U error indication is relative to the source IP address of the GTP-U error indication, or to a list of IP address(es) sharing the same recovery timestamp if those IP address(es) are explicitly included in the GTP-U error indication message. A GTP-U entity receiving a recovery timestamp information element from a peer GTP-U entity shall compare the received remote recovery timestamp value with the previous recovery timestamp value stored for that peer GTP-U entity. - The recovery timestamp value received in an Echo Request or Reply message or a GTP Error Indication message shall be stored for the peer GTP-U entity if no previous value was stored. - If the previously stored recovery timestamp value for the peer GTP-U entity is smaller than the recovery timestamp received in the Echo Request or Reply message or GTP-U Error Indication message, this indicates that the entity that sent the Echo Request or Reply message or GTP-U Error Indication message has restarted. The received, new recovery timestamp value shall be stored by the receiving entity and replace the previously stored value for the peer GTP-U entity. - If the previously stored recovery timestamp value for a peer GTP-U entity is greater than the recovery timestamp value received in an echo request or reply message or a GTP-U error indication message, this indicates a possible race condition (a newer message arriving before an older message). The received new recovery timestamp value shall be discarded and an error may be logged. Based on operator policy, when a Recovery Timestamp IE is received in an echo request from a peer GTP-U entity, and the Recovery Timestamp is greater than the previously stored Recovery Timestamp value for the peer GTP-U entity, the GTP-U entity may determine whether the peer GTP-U entity has actually restarted by: - sending one or more Echo Request messages towards the peer GTP-U entity or monitoring for a GTP-U Error Indication message including a Recovery Timestamp IE from the peer GTP-U entity; - determining that the peer GTP-U entity has restarted if the recovery timestamp in the Echo Reply message or in the GTP-U Error Indication message is greater than the previously stored recovery timestamp value for the peer GTP-U entity; This can be verified by: TIFF0007728459000017.tif9170 Appendix 2 3GPP TSG-CT WG4 meeting #107-e C4-216abc Electronic conference, November 15-25, 2021 Source:Ericsson Title: A study on detecting and reporting GTP-U entity restarts Release: Rel-17 Agenda item: 6.3.2 Document purpose: Judgment 1. Introduction This document aims to provide an analysis of GTP-U entity restarts and also to propose improvements to the detection and reporting of such GTP-U entity restarts in an efficient manner. 2. Description 2.1 Detection of GTP-U restart About 20 years ago, 3GPP decided to remove the use of recovery from the GTP Echo Response message for the user plane (GTP-U), and that recovery was Restart Counter At that time, the GTP entity had a control plane part and a user plane part, so It is redundant to communicate the restart counter for a GTP entity via both the control plane signaling path and the user plane payload path. . The use of the "Restart Counter" field in the "Recovery" information element in GTP-U messages was changed in March 2000 through 3GPP TS29.060 Rel-3 CR096 [7], which was documented in 3GPP TS29.060 V3.4.0 [5] and implemented in 3GPP TS29.060 V3.5.0 [6]. The "Reason for Change" in the CR reads as follows: A Restart Counter in the Echo Reply message is used to inform the peer node that the node has experienced a restart. Using the Restart Counter value in both GTP-U and GTP-C is unnecessary since using the Restart Counter value only in GTP-C is sufficient. Moreover, on the Iu interface, RANAP already has a procedure for node restart. Therefore, it is proposed that the Restart Counter value in the Echo Reply message is not used in GTP-U. The CR also proposes some clarifications on how to react when an echo response is received. Prior to 3GPP Rel-8, the normative specification for GTP-U was included along with GTPv1 in 3GPP TS 29.060. In 3GPP Rel-8, the normative specification for GTP-U was moved from 3GPP TS 29.060 to 3GPP TS 29.281 [3]. The text regarding GTP-U was effectively left "as described" in 3GPP TS 29.060 [4], and a note was added to the beginning of Section 9 in the specification. The note reads as follows: From Release 8 onwards, the normative specification for the GTP version 1 user plane is 3GPP TS 29.281

[41] . All clauses in this document relating to the GTPv1 user plane are superseded by 3GPP TS 29.281

[41] . Therefore, as specified in TS29.281[3], section 7.2.2: The Restart Counter value in the Recovery Information Element shall not be used, i.e., the Restart Counter value shall be set to 0 by the sender and ignored by the receiver. The Recovery Information Element is mandatory for backward compatibility reasons. An optional private extension contains vendor or operator specific information. TIFF0007728459000018.tif24170 Conclusion 1: The motivation explained in the "Reasons for the change" in the CR to disable detection of GTP-U entity restarts is no longer valid in the context of CUPS where control plane and user plane functions have been separated since Rel-14. The CP and UP functions must maintain their own restart counters / recovery timestamps as specified in clause 19a in 3GPP TS 23.007. Conclusion 2: Since then, there has been no mechanism to enable the user plane function to detect that a peer GTP-U entity has restarted. Therefore, there is no requirement for a peer GTP-U restart. 2.2 Problems when a remote GTP-U entity restarts 3GPP has specified relevant requirements for user plane path failure (GTP-U path failure) in 3GPP TS 23.007, clause 20.3 and 3GPP TS 23.527, clause 5.4, see below. 20.3.1 Overview A GTP-U entity shall support the detection of path failures through the use of Echo Request / Echo Reply messages in the following manner: A path counter shall be reset each time an Echo Reply is received on the path and incremented when the T3 Reply timer expires for an Echo Request message sent on the path. A path shall be considered down if the counter exceeds N3 Requests. Upon detecting a path failure, the network node should notify the failure via the operation and maintenance system and may do one of the following: - deleting the bearer context associated with the failed path, or - Maintain bearer contexts associated with a failed path for an operator-configurable maximum path failure duration. The network node shall delete the maintained resources if the path is still down when this duration expires. The (operator configurable maximum) path failure timer is typically much larger than the recovery time of the GTP-U entity, i.e., the GTP-U entity will most likely have recovered from its restart before a path failure can be detected. Therefore, the mechanism used during a GTP-U path failure cannot be used for remote GTP-U entity restart, for example, if the UP function is able to use a single PFCP Node Report Request message to report a GTP-U path failure. When a GTP-U entity restarts, for example, when a gNB restarts, it will lose all its GTP-U context after it recovers from the restart and it receives a DL packet, and the gNB will not be able to find the corresponding context for the DL GTP-U packet from the (I / V-)UPF, and therefore the gNB will only send a GTP error indication for the unknown DL GTP-U packet. Therefore, the gNB that has just recovered from its restart will send a large amount of GTP Error Indication messages to the (I / V-)UPF, which will lead to a large amount of signaling on the Sx / N4 interface as the UP function has to report the receipt of the GTP Error Indication to the CP function (e.g., the (I / V-)SMF). What's worse, the CP function will then have to trigger a PFCP session modification procedure to update, for each affected PFCP session, the DL forwarding action rules containing the DL TEIDs associated with the restarting gNB, i.e., to remove the DL F-TEID (assigned by the restarting gNB) and change the applied action to "BUFF". (See the following signaling flow specified in 5.3.2.1 of 3GPP TS 23.527, where steps 3 and 4 should be optimized.) The gNB is an example here, and any GTP-U entity will apply the same behavior when it restarts and the context of that GTP-U entity on the user plane cannot be restored, for example, by the corresponding control plane. Note that if the user plane context can be restored by the control plane function, the UP function will be required not to send a GTP error indication for a period of time, e.g., during an intermediate UPF restart. 5.3.2.1 Principle TIFF0007728459000019.tif138170 Figure 5.3.2.1-1: GTP-U error indication from 5G-AN 1. The user plane connection for the 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 the 5G-AN does not have a corresponding GTP-U context (see Section 5.2). 3. Upon receiving a GTP-U error indication, the UPF shall identify the involved 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 the 5G-AN, the SMF shall modify the PFCP session to instruct the UPF to buffer downlink packets. Conclusion 3: If a restarted GTP-U entity cannot recover its GTP-U context, e.g., by the control plane, it will send a large amount of GTP error indication messages for unknown incoming GTP-U packets to the peer user plane function that sent those GTP-U packets, and receiving those GTP error indication messages will lead to further large-scale signaling on the Sx / N4 interface. Such large-scale signaling on the GTP-U and Sx / N4 interfaces should be avoided. 3. Proposal It is proposed to introduce detection of GTP-U entity restarts on the GTP-U interface and to report such GTP-U entity restarts using PFCP node reporting procedures such as GTP-U Path Failure Report in order to avoid PFCP session modification procedures. C4-216xyz starts with a stage 2 CR that describes the detection of a GTP-U entity restart.

Claims

1. 1. A method implemented by a control plane function (CP) function (800) in a communications network (1302) for managing a re-initiation of a second user plane (UP) function (804) in a user plane path for a protocol data unit (PDU) session managed by said CP function (800), said method comprising: receiving (816) a Packet Forwarding Control Protocol (PFCP) Node Report Request message from a first UP function (802) that includes a report related to the re-initiation of said second UP function (804), said PFCP Node Report Request message including: (1) the second UP function (804) has restarted and the GTP-U context associated with the list of IP addresses has been lost; (2) The CP function (800) does not need to send a PFCP session modification request message to change the DL FAR for each PFCP session. receiving a Packet Forwarding Control Protocol (PFCP) Node Report Request message (816) indicating sending (818) a PFCP Node Report Response message in response to the PFCP Node Report Request message, the PFCP Node Report Response message including an acknowledgement that the downlink FARs in all affected PFCP sessions associated with the restarted second UP function (804) have been updated with the Apply Action set to Buffered and the remote F-TEID from the second UP function (804) has been removed; Releasing (820) PDU sessions affected by the remote GTP-U re-initiation based on local configuration; A method comprising:

2. 1. A method implemented in a communications network (1302) by a first user plane (UP) function (802) in communication with a control plane (CP) function (800) and a second UP function (804) for managing a re-initiation of said second UP function (804), said method comprising: receiving (814) a GTP error indication including a recovery timestamp and a list of IP addresses affected by the re-initiation of said second UP function (804) to indicate that all GTP-U contexts associated with these IP addresses have been lost; sending (816) a Packet Forwarding Control Protocol (PFCP) Node Report Request message to a Control Plane (CP) function (800) to report the re-initiation of the second UP function (804), wherein the PFCP Node Report Request message includes: (1) the second UP function (804) has restarted and the GTP-U context associated with the list of IP addresses has been lost; (2) The CP function (800) does not need to send a PFCP session modification request message to change the DL FAR for each PFCP session. sending a Packet Forwarding Control Protocol (PFCP) Node Report Request message (816) indicating Receiving a PFCP Node Report Response message (818); A method comprising:

3. 3. The method of claim 2, wherein the first UP function (802) is implemented in one or more of: (a) a New Radio (NR) Node B (gNB); (b) an Evolved Node B (eNB); (c) a Serving Gateway Control Plane Function (SGW-U); (d) a Packet Data Network (PDN) Gateway Control Plane Function (PGW-U); (e) an Intermediate User Plane Function (I-UPF); (f) a Visited User Plane Function (V-UPF); and (g) a Protocol Data Unit (PDU) Session Anchor (PSA) UPF.

4. 3. The method of claim 2, wherein the PFCP Node Report Response message includes an acknowledgement that the downlink FARs in all affected PFCP sessions have been updated with apply action set to buffered and the remote F-TEID has been removed.

Images