Patent Description:
The usage of the "Restart counter" field in the "Recovery" information element in GTP-U messages was changed in March <NUM> through 3GPP TS <NUM> Rel-<NUM> CR <NUM>, which was written on 3GPP TS <NUM> V3. <NUM> and was implemented in 3GPP TS <NUM> V3. The "Reason for change" in the CR (3GPP TS <NUM> Rel-<NUM> CR <NUM>) reads as follows: "Restart counter in the Echo response message is used to inform the peer node that a node has experienced a restart. It is unnecessary to use the Restart counter value in both GTP-U and GTP-C, since it is sufficient to use it only in GTP-C. Moreover, at lu interface RANAP already has a procedure for node restarts. Therefore, it is proposed that the Restart counter value in the Echo Response message is not used in GTP-U. The CR also proposes some clarifications how to react when Echo response is received.

Before 3GPP Rel-<NUM>, the normative specification of GTP-U was included together with GTPv1 in 3GPP TS <NUM>. In 3GPP Rel-<NUM>, the normative specification of GTP-U was moved from 3GPP TS <NUM> to 3GPP TS <NUM>. The text on GTP-U was, in fact, left "as was" in 3GPP TS <NUM> and a note was added at the beginning of clause <NUM> in the specification. The note reads as follows: "From release <NUM> onwards, the normative specification of the user plane of GTP version <NUM> is 3GPP TS <NUM> [<NUM>]. All provisions about GTPv1 user plane in the present document shall be superseded by 3GPP TS <NUM> [<NUM>].

So as specified in TS <NUM>, clause <NUM>. <NUM> states: "The Restart Counter value in the Recovery information element shall not be used, i.e. it shall be set to zero by the sender and shall be ignored by the receiver. The Recovery information element is mandatory due to backwards compatibility reasons. The optional Private Extension contains vendor or operator specific information. " (Emphasis added).

<FIG> of the present disclosure includes Table <NUM>. -<NUM> of the clause <NUM>. <NUM> of TS <NUM>.

Further, clause <NUM>. <NUM> ("ULI Timestamp") of TS <NUM> discloses, "The ULI Timestamp IE is coded as shown in <FIG>. <NUM>-<NUM>. It indicates the UTC time when the user location information was acquired. Octets <NUM> to <NUM> are encoded in the same format as the first four octets of the <NUM>-bit timestamp format as defined in clause <NUM> of IETF RFC <NUM> [<NUM>]. NOTE: The encoding is defined as the time in seconds relative to <NUM>:<NUM>:<NUM> on <NUM> January <NUM>.

<FIG> of the present disclosure includes the figure ("<FIG>. <NUM>-<NUM>: ULI Timestamp") in clause <NUM>. <NUM> of TS <NUM>.

Consequently, 3GPP does not specify any requirement on the peer GTP-u restart, but only GTP-U path failure. For example, as stated in, in TS <NUM> for Fifth Generation System (5GS):.

Upon detecting a GTP-U user plane path failure as specified in clause <NUM>. <NUM>, the UPF shall report the user plane path failure to the SMF, by sending a PFCP Node Report Request (see 3GPP TS <NUM> [<NUM>]) 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.

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

NOTE <NUM>: 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 <NUM>: 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.

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

And in TS <NUM> for EPS, clause <NUM> discloses:.

GTP-U entities shall support detection of path failure by using Echo Request / Echo Response messages in the following way. A path counter shall be reset each time an Echo Response is received on the path and incremented when the T3-RESPONSE timer expires for any Echo Request message sent on the path. The path shall be considered to be 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 either.

When a GTP-U entity receives a GTP-U packets without corresponding context, it will send a GTP error indication. Clause <NUM>. <NUM> of TS <NUM> discloses:.

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), in order to simplify the implementation of mechanisms that can mitigate the risk of Denial-of- Service attacks in some scenarios.

Handling of the received Error Indication is specified in 3GPP TS <NUM> [<NUM>] and 3GPP TS <NUM> [<NUM>].

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

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. A GTP-U Peer Address can 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 related PDP context, RAB, PDU session or EPS bearer in the receiving node.

The optional Private Extension contains vendor or operator specific information.

<FIG> of the present disclosure includes a table of TS <NUM>, clause <NUM>. <NUM> ("Table <NUM>. <NUM>-<NUM>: Information Elements in an Error Indication").

Once the peer GTP-U entity has received a GTP Error Indication, which indicates the user plane path for a given Packet Data Network (PDN) connection/Protocol Data Unit (PDU) session is broken, this has to be reported to control plane function, e.g. Serving Gateway Control plane function (SGW-C), or PDN Gateway Control plane function (PGW-C), or Session Management Function (SMF), so that the control plane function may trigger relevant control plane signalling procedure to request restarted GTP-U entity (e.g. a New Generation Radio Access Network (NG-RAN)) to setup the user plane for that PDN connection.

<FIG> includes a figure ("<FIG>. <NUM>-<NUM>: GTP-U Error Indication from <NUM>-AN") in clause <NUM>. <NUM> ("Procedure for GTP-U Error Indication received from <NUM>-AN") of TS <NUM>. Regarding the figure ("<FIG>. <NUM>-<NUM>: GTP-U Error Indication from <NUM>-AN"), clause <NUM>. <NUM> of TS <NUM> further discloses:.

In TS <NUM>, clause <NUM>. <NUM> ("PFCP Node Report Request - General") discloses, "The PFCP Node Report Request shall be sent over the Sxa, Sxb, Sxc and N4 interface by the UP function to report information to the CP function that is not specific to a PFCP session.

<FIG> of the present disclosure includes a table ("Table <NUM>. <NUM>-<NUM>: Information Elements in PFCP Node Report Request") in clause <NUM>. <NUM> of TS <NUM>.

<FIG> of the present disclosure includes a table ("Table <NUM>. <NUM>-<NUM>: User Plane Path Failure Report IE within PFCP Node Report Request") of clause <NUM>. <NUM> ("User Plane Path Failure Report IE within PFCP Node Report Request") of TS <NUM>.

<FIG> of the present disclosure includes a figure ("Figure <NUM>. <NUM>-<NUM>: Remote GTP-U Peer") in clause <NUM>. 70Figure <NUM> ("Remote GTP-U Peer") of TS <NUM>.

The objectives of the present invention are achieved through the subject-matter of the independent claims <NUM> and <NUM>, respectively claiming a method performed by a first User Plane, UP, function communicating with a Control Plane, CP, function and a second UP function in a telecommunication network for managing a restart of the second UP function and a method performed by a first User Plane, UP, function communicating with a Control Plane, CP, function and a second UP function in a telecommunication network for managing a restart of the second UP function.

There currently exist certain challenge(s). In the event of a GTP-U entity restart, for example, a NG-RAN (e.g., a gNB) has restarted, it will lose all its contexts, therefore it is not possible to find corresponding contexts for the DL GTP-U packets from Intermediate User Plane Function (I-UPF) or Visiting UPF (V-UPF). This triggers the restarted GTP-U entity to send massive amounts of GTP error indication messages, which, in turn, leads to massive amounts of signalling over Sx/N4 interface since the UP function has to report the receiving of GTP error indication to the CP function.

When a GTP-U entity has restarted, such massive signalling over GTP-U interface (for sending GTP error indication) and over Sx/N4 (reporting the receiving of GTP error indication and Packet Forwarding Control Protocol (PFCP) session modification signalling to update DL FAR) should be avoided.

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

The embodiments of the present disclosure include one or more of the following features:.

Certain embodiments may provide one or more of the following technical advantage(s). Massive signalling for a GTP-U entity restart may be avoided where the GTP-U has lost all its GTP-U contexts and those GTP-U contexts cannot be restored by other means, e.g., via its CP function.

Embodiments are provided by way of example 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 <NUM> and Appendix <NUM>).

<FIG> illustrates one embodiment of a procedure for detecting and reporting a peer GTP-U entity restart, in accordance with one example embodiment of the present disclosure. The procedure is performed by a CP function ("CP-<NUM><NUM>"), a first UP function ("UP-<NUM><NUM>"), and a second UP function ("UP-<NUM><NUM>"). The CP-<NUM><NUM> may be or be implemented in SGW-C, PGW-C, or SMF. The UP-<NUM><NUM> or the UP-<NUM><NUM> may be or be implemented in gNB, eNB, SGW-U, PGW-U, I-UPF (Intermediate UPF), or V-UPF (Visiting UPF). <FIG> of the present disclosure illustrates the following steps.

In step <NUM> and step <NUM>, PFCP Session Establishment and Modification Request / Response messages are used to setup PFCP session between the CP-<NUM><NUM> and the UP-<NUM><NUM>. The procedure enables the CP-<NUM><NUM> to provide a remote GTP-U's (the UP-<NUM><NUM>) F-TEID (IP address + Tunnel Endpoint ID) to the UP-<NUM><NUM>. In other words, the PFCP Session Establishment and Modification Request message may contain the remote GTP-U 's F-TEID. Thus, the UP-<NUM><NUM> will send the payload towards and, at the same time, the UP-<NUM><NUM> will provide its GTP-U F-TEID (that is used to receive a payload from the remote GTP-U (the UP-<NUM><NUM>)) to the CP function. The CP function will further use control plane signalling to populate the UP-<NUM>'s GTP-U F-TEID to the UP-<NUM><NUM>, e.g. via NGAP signalling message (a PDU Session Resource Setup Request message if the UP-<NUM><NUM> is a NG-RAN node).

In step <NUM> and step <NUM>, the UP-<NUM><NUM> may send an "Echo Request" to the UP-<NUM><NUM>, which includes the IP address (in the F-TEID from the UP-<NUM><NUM>) to probe the liveness of the UP-<NUM><NUM>. The Echo Request comprises Recovery Information of the UP-<NUM><NUM>, which is identified by the source IP address of the Echo Request. The UP2 will reply with an "Echo Response" message that contains its Recovery Information, which is identified by the resource IP address of the Echo Response. The UP-<NUM><NUM> will store the UP-<NUM>'s Recovery Information for future comparison. The UP-<NUM><NUM> may send an "Echo Request" to the UP-<NUM><NUM> as well. Then, the UP-<NUM><NUM><NUM> may receive an "Echo Response" from the UP-<NUM><NUM> as well. A payload is transferring end to end, including the segment between the UP-<NUM><NUM> and the UP-<NUM><NUM>. The UP-<NUM><NUM> has restarted and recovered from the restart. However, the UP-<NUM><NUM> has lost all its GTP-U contexts, i.e. it cannot recognize the F-TEIDs it allocated before its restart.

In step <NUM>, when the restarted UP-<NUM><NUM> receives a payload addressing a GTP-U F-TEID which it does not recognize, the restarted UP-<NUM><NUM> sends (<NUM>) a "GTP Error Indication" message, which contains a changed Recovery Information, and (<NUM>) a list of IP address affected by the restart, i.e. all GTP-U context associated with these IP addresses have been lost.

In step <NUM>, the UP-<NUM><NUM> sends a "PFCP Node Report Request" message to the CP-<NUM><NUM>, which indicates that (<NUM>) the peer UP (the UP-<NUM><NUM>) has restarted, and GTP-U context associated with a list of IP addresses (provided in GTP Error Indication) have been lost; and (<NUM>) the UP-<NUM><NUM> is to set apply-action in DL FAR to "buffering" and remove DL F-TEID (from the UP-<NUM><NUM>), for all affected PFCP sessions, i.e. the CP-<NUM><NUM> needs not to send a "PFCP Session Modification Request" message to change DL FAR per a PFCP session.

In step <NUM>, as a response to the PFCP Node Report Request message, the CP-<NUM><NUM> sends, to the UP-<NUM><NUM>, a "PFCP Node Report Response" comprising an acknowledgment that the Downlink FAR in all affected PFCP sessions (with the restarted UP-<NUM><NUM>) has been updated with apply-action set to "buffering," and remote F-TEID (from the UP-<NUM><NUM>) is removed.

In step <NUM>, the CP-<NUM><NUM> decides to release the PDU sessions affected by the remote GTP-U restart based on a local configuration, e.g. to release the affected PDU sessions if the restarted remote GTP-U entity is a PSA UPF; or to restore the user plane connection for affected PDU sessions, e.g. if the restarted remote GTP-U entity is a NG-RAN (e.g., gNB) or RAN (e.g., eNB).

In one embodiment, the CP-<NUM><NUM> may perform the following steps illustrated in <FIG>.

In step <NUM>, the CP-<NUM><NUM> receives a PFCP message, from the UP-<NUM><NUM>, containing a report related to the UP-<NUM><NUM> has restarted. Optionally, the PFCP message is a PFCP Node Report Request message. Optionally, the report further comprises an indication that the UP-<NUM><NUM> has removed remote F-TEID(s) allocated by the UP-<NUM><NUM> and changed apply-action in FAR to "buffering" for all affected PFCP sessions.

In step <NUM>, the CP-<NUM><NUM> acknowledges the report, i.e. the CP-<NUM><NUM> will not send a PFCP session modification request message to remove the remote F-TEID and change Apply-action in FAR to the UP-<NUM><NUM>.

In step <NUM>, the CP-<NUM><NUM> performs an action based on an identity of the UP-<NUM><NUM>. In step 904A, the CP-<NUM><NUM> restores a user plane connection for affected PDU sessions if the UP-<NUM><NUM> is RAN or NG-RAN node. In step 904B, the CP-<NUM><NUM> releasing the affected PDU sessions if the UP-<NUM><NUM> is a PSA UPF or a PGW-U.

In one embodiment, the UP-<NUM><NUM> may perform the following steps illustrated in <FIG>.

In step <NUM>, the UP-<NUM><NUM> sends an Echo Request to the UP-<NUM><NUM>. Optionally, the Echo Request may comprise recovery timestamp.

In step <NUM>, the UP-<NUM><NUM> receives an Echo Response from the UP-<NUM><NUM>.

In step <NUM>, the UP-<NUM><NUM> receives an Echo Request from the UP-<NUM><NUM>.

In step <NUM>, the UP-<NUM><NUM> sends an Echo Response to the UP-<NUM><NUM>. Up to this step, the UP-<NUM><NUM> and the UP-<NUM><NUM> have exchanged their recovery timestamps, so they will know any F-TEID allocated before a new recovery timestamp (due to a restart) become invalid. The above steps <NUM> to <NUM> are example steps of exchanging the Echo Requests / the Echo Responses between the UP-<NUM><NUM> and UP-<NUM><NUM>. Thus, the time order of the steps <NUM> to <NUM> can be varied. For example, the steps <NUM> and <NUM> may occur before the steps <NUM> and <NUM>.

In step <NUM>, the UP-<NUM><NUM> receives a GTP error indication comprising a recovery timestamp.

In step <NUM>, the UP-<NUM><NUM> compares the recovery timestamp received in the GTP error indication with the one previously received via the Echo Request, the Echo Response, or the GTP error indication.

In step <NUM>, the UP-<NUM><NUM> determines that the UP-<NUM><NUM> has restarted.

In step <NUM>, the UP-<NUM><NUM> stops sending further payload to the restarted UP-<NUM><NUM>, for example, to avoid receiving further GTP error indications, and over-charge UE/PDU sessions affected by the restart of the UP-<NUM><NUM>.

In step <NUM>, the UP-<NUM><NUM> removes the F-TEID allocated by the UP-<NUM><NUM> and change "apply-action" to "Buffering" because the UP-<NUM><NUM> does not send payloads anymore.

In step <NUM>, the UP-<NUM><NUM> sends a PFCP request message to report the restart of the UP-<NUM><NUM>. Optionally, the PFCP request message is PFCP node report request message.

In step <NUM>, the UP-<NUM><NUM> receives a PFCP response message.

In step <NUM>, the UP-<NUM><NUM> sends an Echo Request to the UP-<NUM><NUM>. Optionally, the Echo Request comprises a recovery timestamp.

In step <NUM>, the UP-<NUM><NUM> sends a GTP error indication comprising a new recovery timestamp to the UP-<NUM><NUM>.

In step <NUM>, the CP-<NUM><NUM> receives a Packet Forwarding Control Protocol (PFCP) request message from the UP-<NUM><NUM>, which comprises a report related to the UP-<NUM><NUM> has restarted.

In step <NUM>, the CP-<NUM><NUM> acknowledges the report by sending a PFCP response message to the UP-<NUM><NUM>.

In step <NUM>, the CP-<NUM><NUM> performs an action based on an identity of the UP-<NUM><NUM>. If the identity of the UP-<NUM><NUM> is a RAN or a NG-RAN node, the action is restoring user plane connection for affected PDU sessions. If the identity of the UP-<NUM><NUM> is a PSA UDF or a PGW-U, the action is releasing affected PDU sessions.

In step <NUM> and step <NUM>, the UP-<NUM><NUM> exchanges Echo Requests and Echo Responses with the UP-<NUM><NUM>.

In step <NUM>, the UP-<NUM><NUM> receives an GTP error indication containing a recovery timestamp;.

In step 1206A, the UP-<NUM><NUM> compares the recovery timestamp received in the GTP error indication with a recovery timestamp previously received via the Echo Request, the Echo Response or the GTP error indication.

In step 1206B, the UP-<NUM><NUM> determines that the UP-<NUM><NUM> has restarted.

In step 1206C, the UP-<NUM><NUM> stops sending a further payload to the restarted UP-<NUM><NUM>.

In step 1206C, the UP-<NUM><NUM> removes the F-TEID allocated by the UP-<NUM><NUM> and change apply-action to Buffering.

In step <NUM>, the UP-<NUM><NUM> sends the PFCP request message to report the restart of the UP-<NUM><NUM>.

In step <NUM>, the UP-<NUM><NUM> receives the PFCP response message.

In step <NUM>, the UP-<NUM><NUM> sends an GTP error indication comprising a new recovery timestamp.

The following exemplifies several 3GPP changes (in stage <NUM> specifications) to support the present disclosure. The texts (or Information Elements) in italicized bold font indicate newly suggested changes to the 3GPP standards.

The following clauses (<NUM>. <NUM> and <NUM>. <NUM>) of TS <NUM> are proposed to change in the portions indicated by the text (or Information Elements) in italicized bold font:.

The message shall be sent as a response to a received Echo Request.

The Restart Counter value in the Recovery information element shall not be used, i.e. it shall be set to zero by the sender and shall be ignored by the receiver. The Recovery information element is mandatory due to backwards compatibility reasons.

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), in order to simplify the implementation of mechanisms that can mitigate the risk of Denial-of-Service attacks in some scenarios.

Handling of the received Error Indication is specified in 3GPP TS <NUM> [<NUM>] and 3GPP TS <NUM> [<NUM>]. The information element Tunnel Endpoint Identifier Data I shall be the TEID fetched from the G-PDU that triggered this procedure.

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. A GTP-U Peer Address can 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 related PDP context, RAB, PDU session or EPS bearer in the receiving node. The optional Private Extension contains vendor or operator specific information.

The following clauses of TS <NUM> are proposed to change in the portions indicated by the text (or Information Elements) in italicized bold font:.

The PFCP Node Report Request shall be sent over the Sxa, Sxb, Sxc and N4 interface by the UP function to report information to the CP function that is not specific to a PFCP session.

The Node Report Type IE shall be encoded as shown in <FIG>. <NUM>-<NUM>. It indicates the type of the node report the UP function sends to the CP function.

Octet <NUM> shall be encoded as follows:.

Bit <NUM> - CKDR (Clock Drift Report): when set to " <NUM>", this indicates a Clock Drift Report.

At least one bit shall be set to "<NUM>". Several bits may be set to "<NUM>".

NOTE: If both UPFR and UPRR bits are set to "<NUM>", the Remote GTP-U Peer IEs in the User Plane Path Failure Report IE and in the User Plane Path Recovery Report IE are different.

The CP function and UP function needs to indicate their Support of this new feature (as described above) via CP function feature and UP function feature.

The CP Function Features IE indicates the features supported by the CP function. Only features having an impact on the (system-wide) UP function behaviour are signalled in this IE. It is coded as depicted in <FIG>. <NUM>-<NUM>.

The CP Function Features IE takes the form of a bitmask where each bit set indicates that the corresponding feature is supported. Spare bits shall be ignored by the receiver. The same bitmask is defined for all PFCP interfaces.

The following table specifies the features defined on PFCP interfaces and the interfaces on which they apply.

The UP Function Features IE indicates the features supported by the UP function. It is coded as depicted in <FIG>. <NUM>-<NUM>.

The UP Function Features IE takes the form of a bitmask where each bit set indicates that the corresponding feature is supported. Spare bits shall be ignored by the receiver. The same bitmask is defined for all PFCP interfaces.

<FIG> illustrates one example of a cellular communications system <NUM> in which embodiments of the present disclosure may be implemented. In the embodiments described herein, the cellular communications system <NUM> is a <NUM> system (5GS) including a Next Generation RAN (NG-RAN) and a <NUM> Core (5GC). In this example, the RAN includes base stations <NUM>-<NUM> and <NUM>-<NUM>, which in the 5GS include NR base stations (gNBs) and optionally next generation eNBs (ng-eNBs) (e.g., LTE RAN nodes connected to the 5GC) and in the EPS include eNBs, controlling corresponding (macro) cells <NUM>-<NUM> and <NUM>-<NUM>. The base stations <NUM>-<NUM> and <NUM>-<NUM> are generally referred to herein collectively as base stations <NUM> and individually as base station <NUM>. Likewise, the (macro) cells <NUM>-<NUM> and <NUM>-<NUM> are generally referred to herein collectively as (macro) cells <NUM> and individually as (macro) cell <NUM>. The RAN may also include a number of low power nodes <NUM>-<NUM> through <NUM>-<NUM> controlling corresponding small cells <NUM>-<NUM> through <NUM>-<NUM>. The low power nodes <NUM>-<NUM> through <NUM>-<NUM> can be small base stations (such as pico or femto base stations) or RRHs, or the like. Notably, while not illustrated, one or more of the small cells <NUM>-<NUM> through <NUM>-<NUM> may alternatively be provided by the base stations <NUM>. The low power nodes <NUM>-<NUM> through <NUM>-<NUM> are generally referred to herein collectively as low power nodes <NUM> and individually as low power node <NUM>. Likewise, the small cells <NUM>-<NUM> through <NUM>-<NUM> are generally referred to herein collectively as small cells <NUM> and individually as small cell <NUM>. The cellular communications system <NUM> also includes a core network <NUM>, which in the <NUM> System (5GS) is referred to as the 5GC. The base stations <NUM> (and optionally the low power nodes <NUM>) are connected to the core network <NUM>.

<FIG> illustrates a wireless communication system represented as a <NUM> network architecture composed of core Network Functions (NFs), where interaction between any two NFs is represented by a point-to-point reference point/interface. <FIG> can be viewed as one particular implementation of the system <NUM> of <FIG>.

Seen from the access side the <NUM> network architecture shown in <FIG> comprises a plurality of UEs <NUM> connected to either a RAN <NUM> or an Access Network (AN) as well as an AMF <NUM>. Typically, the R(AN) <NUM> comprises base stations, e.g. such as eNBs or gNBs or similar. Seen from the core network side, the 5GC NFs shown in <FIG> include a NSSF <NUM>, an AUSF <NUM>, a UDM <NUM>, the AMF <NUM>, a SMF <NUM>, a PCF <NUM>, and an Application Function (AF) <NUM>.

Reference point representations of the <NUM> network architecture are used to develop detailed call flows in the normative standardization. The N1 reference point is defined to carry signaling between the UE <NUM> and AMF <NUM>. The reference points for connecting between the AN <NUM> and AMF <NUM> and between the AN <NUM> and UPF <NUM> are defined as N2 and N3, respectively. There is a reference point, N11, between the AMF <NUM> and SMF <NUM>, which implies that the SMF <NUM> is at least partly controlled by the AMF <NUM>. N4 is used by the SMF <NUM> and UPF <NUM> so that the UPF <NUM> can be set using the control signal generated by the SMF <NUM>, and the UPF <NUM> can report its state to the SMF <NUM>. N9 is the reference point for the connection between different UPFs <NUM>, and N14 is the reference point connecting between different AMFs <NUM>, respectively. N15 and N7 are defined since the PCF <NUM> applies policy to the AMF <NUM> and SMF <NUM>, respectively. N12 is required for the AMF <NUM> to perform authentication of the UE <NUM>. N8 and N10 are defined because the subscription data of the UE <NUM> is required for the AMF <NUM> and SMF <NUM>.

The 5GC network aims at separating UP and CP. The UP carries user traffic while the CP carries signaling in the network. In <FIG>, the UPF <NUM> is in the UP and all other NFs, i.e., the AMF <NUM>, SMF <NUM>, PCF <NUM>, AF <NUM>, NSSF <NUM>, AUSF <NUM>, and UDM <NUM>, are in the CP. Separating the UP and CP guarantees each plane resource to be scaled independently. It also allows UPFs to be deployed separately from CP functions in a distributed fashion. In this architecture, UPFs may be deployed very close to UEs to shorten the Round Trip Time (RTT) between UEs and data network for some applications requiring low latency.

The core <NUM> network architecture is composed of modularized functions. For example, the AMF <NUM> and SMF <NUM> are independent functions in the CP. Separated AMF <NUM> and SMF <NUM> allow independent evolution and scaling. Other CP functions like the PCF <NUM> and AUSF <NUM> can be separated as shown in <FIG>. Modularized function design enables the 5GC network to support various services flexibly.

In the CP, a set of interactions between two NFs is defined as service so that its reuse is possible. The UP supports interactions such as forwarding operations between different UPFs.

<FIG> illustrates a <NUM> network architecture using service-based interfaces between the NFs in the CP, instead of the point-to-point reference points/interfaces used in the <NUM> network architecture of <FIG>. However, the NFs described above with reference to <FIG> correspond to the NFs shown in <FIG>. The service(s) etc. that a NF provides to other authorized NFs can be exposed to the authorized NFs through the service-based interface. In <FIG> the service based interfaces are indicated by the letter "N" followed by the name of the NF, e.g. Namf for the service based interface of the AMF <NUM> and Nsmf for the service based interface of the SMF <NUM>, etc. The NEF <NUM> and the NRF <NUM> in <FIG> are not shown in <FIG> discussed above. However, it should be clarified that all NFs depicted in <FIG> can interact with the NEF <NUM> and the NRF <NUM> of <FIG> as necessary, though not explicitly indicated in <FIG>.

Some properties of the NFs shown in <FIG> and <FIG> may be described in the following manner. The AMF <NUM> provides UE-based authentication, authorization, mobility management, etc. A UE <NUM> even using multiple access technologies is basically connected to a single AMF <NUM> because the AMF <NUM> is independent of the access technologies. The SMF <NUM> is responsible for session management and allocates Internet Protocol (IP) addresses to UEs. It also selects and controls the UPF <NUM> for data transfer. If a UE <NUM> has multiple sessions, different SMFs <NUM> may be allocated to each session to manage them individually and possibly provide different functionalities per session. The AF <NUM> provides information on the packet flow to the PCF <NUM> responsible for policy control in order to support QoS. Based on the information, the PCF <NUM> determines policies about mobility and session management to make the AMF <NUM> and SMF <NUM> operate properly. The AUSF <NUM> supports authentication function for UEs or similar and thus stores data for authentication of UEs or similar while the UDM <NUM> stores subscription data of the UE <NUM>. The Data Network (DN), not part of the 5GC network, provides Internet access or operator services and similar.

<FIG> is a schematic block diagram of a network node <NUM> according to some embodiments of the present disclosure. Optional features are represented by dashed boxes. The network node <NUM> may be, for example, a core network node that implements a NF (e.g., AMF <NUM>, SMF <NUM>, or NSACF <NUM>) or a network node that implements all or part of the functionality of an NF (e.g., all or part of the functionality of the AMF <NUM>, the SMF <NUM>, or the NSACF <NUM> described herein). As illustrated, the network node <NUM> includes a one or more processors <NUM> (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like), memory <NUM>, and a network interface <NUM>. The one or more processors <NUM> are also referred to herein as processing circuitry. The one or more processors <NUM> operate to provide one or more functions of the network node <NUM> as described herein (e.g., one or more functions of the AMF <NUM>, the SMF <NUM>, or the NSACF <NUM> described herein). In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory <NUM> and executed by the one or more processors <NUM>. Examples of the network node <NUM> may include the CP-<NUM><NUM>, the UP-<NUM><NUM>, and the UP-<NUM><NUM> in <FIG>.

<FIG> is a schematic block diagram that illustrates a virtualized embodiment of the network node <NUM> according to some embodiments of the present disclosure. As used herein, a "virtualized" network node is an implementation of the network node <NUM> in which at least a portion of the functionality of the network node <NUM> is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, in this example, the network node <NUM> includes one or more processing nodes <NUM> coupled to or included as part of a network(s) <NUM>. Each processing node <NUM> includes one or more processors <NUM> (e.g., CPUs, ASICs, FPGAs, and/or the like), memory <NUM>, and a network interface <NUM>. In this example, functions <NUM> of the network node <NUM> described herein (e.g., one or more functions of the AMF <NUM>, the SMF <NUM>, or the NSACF <NUM> described herein) are implemented at the one or more processing nodes <NUM> or distributed across the two or more processing nodes <NUM> in any desired manner. In some particular embodiments, some or all of the functions <NUM> of the network node <NUM> described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) <NUM>.

In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the network node <NUM> or a node (e.g., a processing node <NUM>) implementing one or more of the functions <NUM> of the network node <NUM> in a virtual environment according to any of the embodiments described herein is provided.

<FIG> is a schematic block diagram of the network node <NUM> according to some other embodiments of the present disclosure. The network node <NUM> includes one or more modules <NUM>, each of which is implemented in software. The module(s) <NUM> provide the functionality of the network node <NUM> described herein. This discussion is equally applicable to the processing node <NUM> of <FIG> where the modules <NUM> may be implemented at one of the processing nodes <NUM> or distributed across multiple processing nodes <NUM>.

It is to be understood that these computing devices may comprise any suitable combination of hardware and/or software needed to perform the tasks, features, functions, and methods disclosed herein. Determining, calculating, obtaining, or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and/or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box or nested within multiple boxes, in practice computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components.

In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored in memory, which in certain 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 circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hardwired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry 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 a wireless network generally.

Across GTP-U based interfaces, i.e. the S1-U, S11-U, S2a, S2b, X2, S4, S5, S8, S12, M1 and Sn interfaces of the Evolved Packet System in EPS, and the F1-U, Xn, N3, N9, N19, N3mb and N19mb interfaces of the <NUM> System in 5GS, a GTP-U entity may utilize GTP-U Echo Request and Echo Response messages or GTP-U Error Indication message containing the Recovery Time Stamp Information Element to detect and handle a restart.

A GTP-U entity shall be prepared to receive an Echo Request message at any time (even from unknown peers), and it shall reply with an Echo Response message.

A GTP-U entity shall maintain two Recovery Time Stamps:.

After a GTP-U entity has (re)started, it shall immediately update all local Recovery Time Stamps and shall clear all remote Recovery Time Stamps. When peer GTP-U entities information is available, e.g. when the first GTP-U tunnel towards the peer GTP-U entity is to be established, the (re)started GTP-U entity may send its (updated) Recovery Time Stamps in an Echo Request message to the peer GTP-U entity before sending GTP-U packets.

A GTP-U entity may have a common local Recovery Time Stamp for all peer GTP-U entities, or it may have a separate local Recovery Time Stamp for each peer GTP-U entity.

A GTP-U entity may probe the liveliness of each peer GTP-U entity with which it is in contact by sending an Echo Request message.

The Recovery Time Stamp signalled in the GTP-U Echo Request and Response messages is associated with the GTP-U entity identified by the source IP address of the message.

The Recovery Time Stamp signalled in the GTP-U Error Indication is associated with the source IP address of the GTP-U Error Indication or associated with a list of IP address(es) which are sharing the same Recovery Time Stamp if those IP address(es) explicitly included in the GTP-U Error Indication message.

The GTP-U entity that receives a Recovery Time Stamp Information Element from a peer GTP-U entity shall compare the received remote Recovery Time Stamp value with the previous Recovery Time Stamp value stored for that peer GTP-U entity.

Based on operator's policy, when a Recovery Time Stamp IE is received in an Echo Request from a peer GTP-U entity, with a Recovery Time Stamp larger than the value of the Recovery Time Stamp previously stored for the peer GTP-U entity, the GTP-U entity may verify whether the peer GTP-U entity has really restarted by:.

The paper is to provide an analysis on a GTP-U entity restart and also propose to introduce enhancements to detect and reporting of such GTP-U entity restart in an efficient way.

About <NUM> years ago, 3GPP has decided to remove the usage of Recovery from the GTP Echo Response message for user plane (GTP-U), where the Recovery is defined as the restart counter for a GTP entity, since at that time, a GTP entity comprises a Control plane part and user plane part, it is redundant to communicate the restart counter for a GTP entity via both the control plane signalling path and user plane payload path.

The usage of the "Restart counter" field in the "Recovery" information element in GTP-U messages was changed in March <NUM> through 3GPP TS <NUM> Rel-<NUM> CR <NUM> [<NUM>], which was written on 3GPP TS <NUM> V3. <NUM> [<NUM>] and was implemented in 3GPP TS <NUM> V3. <NUM> [<NUM>]. The "Reason for change" in the CR reads as follows:.

Before 3GPP Rel-<NUM>, the normative specification of GTP-U was included together with GTPv1 in 3GPP TS <NUM>. In 3GPP Rel-<NUM>, the normative specification of GTP-U was moved from 3GPP TS <NUM> to 3GPP TS <NUM> [<NUM>]. The text on GTP-U was, in fact, left "as was" in 3GPP TS <NUM> [<NUM>] and a note was added at the beginning of clause <NUM> in the specification. The note reads as follows:
From release <NUM> onwards, the normative specification of the user plane of GTP version <NUM> is 3GPP TS <NUM> [<NUM>]. All provisions about GTPv1 user plane in the present document shall be superseded by 3GPP TS <NUM> [<NUM>].

So as specified in TS <NUM> [<NUM>], clause <NUM>.

Conclusion <NUM>: the motivation as described in the "Reason for change" in the CR to disable the detection of GTP-U entity restart is NOT valid any longer in the context of CUPS, where Control plane function and User plane function are separated since Rel-<NUM>. CP function and UP function have to maintain their own restart counter/recovery timestamp, as specified in clause 19a in 3GPP TS <NUM>.

Conclusion <NUM>: There is no mechanism since then to enable a User Plane function to detect the peer GTP-U entity has restarted. Consequently, there is no requirement on the peer GTP-U restart.

3GPP has specified relevant requirements for user plane path failure (GTP-U path failure) in 3GPP TS <NUM>, clause <NUM> and 3GPP TS <NUM>, clause <NUM>. See below:.

The (operator configurable maximum) path failure timer is NORMALLY much larger than the recovery time of a GTP-U entity, i.e., before the path failure can be detected, the GTP-U entity has most likely recovered from its restart.

Therefore, the mechanism which is used during a GTP-U path failure, e.g., where the UP function is possible to use a single PFCP Node Report Request message to report GTP-U path failure, can't be used for the remote GTP-U entity restart.

When a GTP-U entity restarts, for example, a gNB has restarted, it will lose all its GTP-U contexts, after it recovers from the restart and it receives DL packets, the gNB is not able to find corresponding contexts for the DL GTP-U packets from (I/V-)UPF, so it just sends a GTP Error Indication for an unknown DL GTP-U packet.

So, a gNB which has just recovered from its restart will send massive amounts of GTP Error Indication messages to the (I/V-)UPF, which in turn leads to massive amounts of signalling over Sx/N4 interface since the UP function has to report the receiving of GTP Error Indication to the CP function (e.g. (I/V-)SMF; even worse, the CP function needs subsequently to trigger PFCP Session Modification procedure for each of affected PFCP sessions to update the DL Forwarding Action Rule which contains the DL TEID associated with the restarted gNB, i.e. to remove the DL F-TEID (which was allocated by the restarted gNB) and change Apply-Action to "BUFF". (see the signalling flow as below as specified in <NUM>. <NUM> of 3GPP TS <NUM>, where step <NUM> and step <NUM> should be optimized.

The gNB is an example here, any GTP-U entity will apply the same behaviour when it restarts and its contexts on the user plane can't be restored, e.g. by the corresponding control plane.

NOTE that, if the user plane contexts can be restored by a control plane function, the UP function will be required to not send GTP Error Indication for a period of time, e.g. for an intermediate UPF restart.

Conclusion <NUM>: A restarted GTP-U entity, if its GTP-U contexts can't be restored, e.g. by the control plane, will send massive amount of GTP Error Indication messages for the unknown incoming GTP-U packets to the peer User Plane function sending those GTP-U packets; and receiving those GTP Error Indication message leads further massive signalling over Sx/N4 interface. Such massive signalling over GTP-U interface and Sx/N4 interface should be avoided.

It is proposed to introduce detection of a GTP-U entity restart over GTP-U interface and report such GTP-U entity restart using PFCP Node Report procedure, like GTP-U path failure reporting, to avoid PFCP Session Modification procedure.

Claim 1:
A method performed by a Control Plane function, CP, function (<NUM>), in a telecommunication network (<NUM>) to manage a restart of a second User Plane, UP, function (<NUM>) in a user plane path for Protocol Data Unit, PDU, sessions that the CP function (<NUM>) is managing, the method comprises:
• receiving (<NUM>) a Packet Forwarding Control Protocol, PFCP, Node Report Request message from a first UP function (<NUM>) comprising a report related to a restart of the second UP function (<NUM>), where the PFCP Node Report request message indicates:
(<NUM>) that the second UP function (<NUM>) has restarted and GTP-U context associated with the list of IP addresses have been lost; and
(<NUM>) that the CP function (<NUM>) needs not to send a PFCP Session Modification Request message to change DL FAR per a PFCP session;
• sending (<NUM>), as a response to the PFCP Node Report Request message, a PFCP Node report Response message that comprises an acknowledgment that the Downlink FAR in all affected PFCP sessions associated with the restarted second UP function (<NUM>) has been updated with apply-action set to buffering, and remote F-TEID from the second UP function (<NUM>) has been removed; and
• releasing (<NUM>) PDU sessions affected by the remote GTP-U restart based on a local configuration.