Method and apparatus for session moving among a set of control plane function

Abstract

The embodiments herein relate to method and apparatus for session moving among a set of control plane function. In some embodiments, there proposes a method (400) performed by a first network node (101) implementing a user plane function. The method (400) may comprise at least the step of determining (S401) that a session between the first network node (101) and a second network node (102) implementing a first control plane function in a network function set is to be moved from the second network node (102) to a third network node (103, 104) implementing a second control plane function in the network function set; and a step of sending (S402) a session report request message to the third network node (103, 104), for moving the session to the third network node (103, 104).

Description

METHOD AND APPARATUS FOR SESSION MOVING AMONG A SET OF CONTROL PLANE FUNCTIONTechnical Field

[0001] The embodiments herein relate generally to the field of communication, and more particularly, the embodiments herein relate to method and apparatus for session moving among a set of control plane function.Background

[0002] The 3rd Generation Partnership Project (3GPP) has introduced the concept of "set" for control plane function, such as Session Management Function (SMF) . For example, as specified in clause 4.4.3.2 of 3GPP Technical Specification (TS) 23.527 Version (V) 19.0.0, when a control plane function (e.g., an SMF) in a set of control plane functions (e.g., an SMF set) fails, alternative control plane function (s) (e.g., other SMF) in the set may take over the session (s) of the failed control plane function.Summary

[0003] However, there is no specification that when and how to send a session report request from the user plane function to the alternative control plane function (s) , so that the alternative control plane function (s) may know the failure of the original control plane function.

[0004] In view of the above, the embodiments herein propose method and apparatus for session moving among a set of control plane function.

[0005] In some embodiments, there proposes a method performed by a first network node implementing a user plane function. The method may comprise at least a step of determining that a session between the first network node and a second network node implementing a first control plane function in a network function set is to be moved from the second network node to a third network node implementing a second control plane function in the network function set; and a step of sending a session report request message to the third network node, for moving the session to the third network node.

[0006] In some embodiments, there proposes a method performed by a third network node implementing a second control plane function in a network function set. The method may comprise at least a step of receiving a session report request message from a first network node implementing a user plane function, for moving a session between the first network node and a second network node implementing a first control plane function in the network function set from the second network node to the third network node.

[0007] In some embodiments, there proposes a network node in a communication network. The network node may comprise processing circuitry and a memory. The processing circuitry may be configured to perform the above methods. The network node may be configured as any one of the above first, second, or third network node.

[0008] In some embodiments, there proposes a communication system. The communication system may comprise the first, and third network nodes, and optionally may comprise the second network node.

[0009] In some embodiments, there proposes a computer readable medium comprising instructions that, when executed by a network node, cause the network node to perform the above methods.

[0010] In some embodiments, there proposes a computer readable product comprising instructions that, when executed by a network node, cause the network node to perform the above methods.

[0011] The embodiments may define clearly when and how the user plane function sends a session report request to the alternative control plane function (s) of the set of control plane function (s) when determining that a session is to be moved from an original network node to an alternative network node in the same set with the original network node.

[0012] The embodiments may avoid losses of messages (e.g. N4-u messages) from wireless device (such as User Equipment, UE) , which are essential for nearly all Protocol Data Unit (PDU) sessions.Brief Description of the Drawings

[0013] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate various embodiments of the present disclosure and, together with the description, further serve to explain the principles of the disclosure and to enable a person skilled in the pertinent art to make and use the embodiments disclosed herein. In the drawings, like reference numbers indicate identical or functionally similar elements, and in which:

[0014] Figure 1 is a schematic diagram showing example architecture for 5G network architecture at non-roaming scenario;

[0015] Figure 2A is a schematic signaling chart showing the messages in an example procedure for a session moving among a set of SMFs, according to the embodiments herein;

[0016] Figure 2B is a schematic signaling chart showing the messages in an example session set modification procedure, according to the embodiments herein;

[0017] Figure 3 is a schematic signaling chart showing the messages in another example procedure for session moving among a set of SMFs, according to the embodiments herein;

[0018] Figure 4 is a schematic flow chart showing an example method in the first network node, according to the embodiments herein;

[0019] Figure 5 is a schematic flow chart showing an example method in the third network node, according to the embodiments herein;

[0020] Figure 6 is a schematic block diagram showing an example first network node, according to the embodiments herein;

[0021] Figure 7 is a schematic block diagram showing an example third network node, according to the embodiments herein;

[0022] Figure 8 is a schematic block diagram showing an example computer-implemented apparatus, according to the embodiments herein; and

[0023] Figure 9 is a schematic block diagram showing an example communication system, according to the embodiments herein.Detailed Description of Embodiments

[0024] Embodiments herein will be described in detail hereinafter with reference to the accompanying drawings, in which embodiments are shown. These embodiments herein may, however, be embodied in many different forms and should not be construed as being limited to the embodiments set forth herein. The elements of the drawings are not necessarily to scale relative to each other.

[0025] Reference to “one embodiment” or “an embodiment” means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, the appearances of the phrase “in an embodiment” appearing in various places throughout the specification are not necessarily all referring to the same embodiment.

[0026] As used in the description and the appended claims, the singular forms “a” , “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term “and / or” as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

[0027] As used throughout this description, and in the claims, a list of items joined by the term “at least one of” or “one or more of” can mean any combination of the listed terms. For example, the phrase “at least one of A, B or C” can mean A; B; C; A and B; A and C; B and C; or A, B and C.

[0028] The methods and apparatuses herein are described by referring to the New Radio (NR) Radio Access Technology (RAT) , but can be also applicable to Long Term Evolution (LTE) RAT and any other RAT enabling direct communication between two (or more) nearby devices.

[0029] Figure 1 is a schematic diagram showing example architecture 100 for 5G network architecture at non-roaming scenario, in which the embodiments herein may be implemented. As shown in Figure 1, multiple SMFs 102, 103, 104 may form an SMF set, so that one an SMF (such as SMF 102) in the SMF set fails, alternatives SMFs 103, 104 may take over the affected sessions.

[0030] In an example, the example 5G system architecture may comprise the following network functions (NF) : -Unified Data Management (UDM) , Policy Control Function (PCF) , Network Exposure Function (NEF) , Network Repository Function (NRF) , Unified Data Repository (UDR) , Access and Mobility Management Function (AMF) , Session Management Function (SMF) , User Plane Function (UPF) , Application Function (AF) , User Equipment (UE) , and (Radio) Access Network ( (R) AN) such as Next Generation RAN (NG-RAN) .

[0031] In an example, when the User Plane Function (UPF) 101 detects that a peer Packet Forward Control Protocol (PFCP) entity in an SMF (such as SMF 102) is not responsive for a preconfigured time, or upon being instructed by SMF (s) of the SMF set (such as SMF 104) to move PFCP sessions, the UPF 101 may move the PFCP sessions that were served by the failed PFCP entity to another PFCP entity in the same SMF or another SMF (such as SMF 103) .

[0032] Figure 2A is a schematic signaling chart showing the messages in an example procedure for session moving among a set of SMFs, according to the embodiments herein. The signaling chart of Figure 2A may be applicable to the architecture in Figure 1 and other architecture (s) in for example LTE.

[0033] In an embodiment, the signaling chart in Figure 2A may include the following messages or steps:

[0034] Step 0: The SMFs 102, 103, 104 of the SMF set may establish one or more PFCP associations with the UPF 101. When using the MPAS (Multiple PFCP Associations to the SMFs in an SMF set) feature, the SMFs 102, 103, 104 of the SMF set may establish multiple PFCP associations with the UPF 101, for example including the SMF set Identifier (ID) Information Element (IE) set to a Fully Qualified Domain Name (FQDN) representing the SMF set and optionally alternative SMF Internet Protocol (IP) address IE (s) of alternative PFCP entities in the same SMF or different SMFs of the SMF set.

[0035] When using the SSET feature (one PFCP association per SMF Set and UPF) , one SMF of the SMF set establishes one PFCP association with the UPF 101 for the SMF set, optionally including alternative SMF IP address IE (s) of alternative PFCP entities in the same SMF or different SMFs of the SMF set. In this case, the UPF 101 may consider that the SMF1 102, SMF2 103 and SMF3 104 represent different PFCP entities.

[0036] The SMFs 102, 103, and 104 of the SMF set may establish PFCP sessions in the UPF 101, optionally providing a Fully qualified PDN Connection Set Identifier (FQ-CSID) and / or a group ID as described in clause 4.7.2 of 3GPP TS 29.244 V18.7.0.

[0037] Step 1. The SMF1 102 fails without restart.

[0038] Step 2. This is an optional step. In an example, the other SMF 103 or 104 of the SMF set may detect the failure of the SMF1 102. Then, the other SMF 103 or 104 of the SMF set may request the UPF 101 to move group (s) of PFCP sessions, each identified by a FQ-CSID, group ID or Control Plane (CP) IP address, to alternative SMF (s) of the SMF set.

[0039] Step 3. The UPF 101 may determine that a session between the UPF 101 and the SMF1 102 is to be moved from the SMF1 102 to another SMF in the set, such as SMF2 103.

[0040] In an example, the UPF 101 may determine the session moving upon being instructed by the SMF (s) in the SMF set to move PFCP sessions; note that any of the SMF in the SMF set may make such instruction, including the SMF1 102. In another example, the UPF 101 may determine the session moving upon detecting that the SMF1 102 is not responsive. In yet another example, the UPF 101 may determine the session moving upon detecting a failure of the SMF1 102, such as PFCP heartbeat failure, General Packet Radio Service (GPRS) Tunneling Protocol -User Plane (GTP-U) echo failure or GTP-U error indication.

[0041] Step 4. Upon determining the session moving, the UPF 101 may send subsequent PFCP Session Report Request (FPCPSRReq) message (s) to the alternative SMFs (such as the SMF2 103) of the SMF set. For example, the UPF 101 may set the Session Endpoint Identifier (SEID) field to zero in the PFCP header of the PFCP Session Report Request and include the old CP Fully Qualified SEID (F-SEID) that was assigned by the previous SMF in the request.

[0042] In an example, the PFCP Session Report Request message may comprise first information indicating a reason for the UPF 101 to send the session report request message.

[0043] In an example, the first information may comprise at least one of: a first indicator indicating that the UPF 101 moves the session due to the SMF1 102 not responding; a second indicator indicating that the UPF 101 moves the session due to the SMF1 102 failure; and a third indicator indicating that the UPF 101 moves the session as instructed by an SMF such as SMF3 104 in the SMF set.

[0044] In an example, the first information may be presented by the "PFCPSRReq-Flags" IE and each of the first indicator, the second indicator and the third indicator may be presented by a bit of the "PFCPSRReq-Flags" IE respectively.

[0045] The "PFCPSRReq-Flags" IE indicates flags applicable to the PFCP Session Report Request message. It may be coded as depicted in following table 1.

[0046] Table 1: PFCPSRReq-Flags

[0047] The following bits within Octet 5 may indicate:

[0048] -Bit 1 –PSDBU (PFCP Session Deleted By the UP function) : if this bit is set to "1" , it indicates that the UP function has reported all non-zero Usage Reports for all URRs in the PFCP Session and the PFCP Session is being deleted in the UP function locally.

[0049] -Bit 2 –MPSNR (Move PFCP Session due to SMF no responding) : if this bit is set to "1" , it indicates that the UP function moves the PFCP session due to the SMF not responding.

[0050] -Bit 3 –MPSHF (Move PFCP Session due to SMF Heartbeat Failure) : if this bit is set to "1" , it indicates that the UP function moves the PFCP session due to the SMF heartbeat failure.

[0051] -Bit 4 –MPSAI (Move PFCP Session As Instructed) : if this bit is set to "1" , it indicates that the UP function moves the PFCP session as instructed by the SMF in a PFCP Session Set Modification Request.

[0052] -Bit 5 to 8 –Spare, for future use, shall be set to "0" by the sender and discarded by the receiver.

[0053] Note that, in this example, the first indicator, the second indicator and the third indicator may be presented respectively by the bits 2-4 of "PFCPSRReq-Flags" IE. In other examples, the first indicator, the second indicator and the third indicator may be presented respectively by other bits such as bits 3-5 or bits 4-6 etc. of "PFCPSRReq-Flags" IE.

[0054] In an example, the first information may be presented by an additional IE, which may be referred to or called as "SMF Change Indication" , and each of the first indicator, the second indicator and the third indicator is presented by a bit of the "SMF Change Indication" .

[0055] For example, there may be new IE in the PFCP Session Report Request message, which may be referred to or called as SMF Change Indication IE. The Flags of SMF Change Indication IE may indicate the reason for the UPF 101 sending a PFCP Session Report Request message to move the PFCP session to an alternative SMF 103 pertaining to the same SMF set. It may be coded as depicted in table 2.

[0056] Table 2: SMF Change Indication

[0057] The following bits within Octet 5 may indicate:

[0058] -Bit 1 –MPSNR (Move PFCP Session due to SMF no responding) : if this bit is set to "1" , it indicates that the UP function moves the PFCP session due to the SMF not responding.

[0059] -Bit 2 –MPSHF (Move PFCP Session due to SMF Heartbeat Failure) : if this bit is set to "1" , it indicates that the UP function moves the PFCP session due to the SMF heartbeat failure.

[0060] -Bit 3 –MPSAI (Move PFCP Session As Instructed) : if this bit is set to "1" , it indicates that the UP function moves the PFCP session as instructed by the SMF in a PFCP Session Set Modification Request.

[0061] -Bit 4 to 8 –Spare, for future use, shall be set to "0" by the sender and discarded by the receiver.

[0062] Note that, in this example, the first indicator, the second indicator and the third indicator may be presented respectively by the bits 1-3 of "SMF Change Indication" IE. In other examples, the first indicator, the second indicator and the third indicator may be presented respectively by other bits of "SMF Change Indication" IE. Or the “SMF Change Indication” IE has a data structure of enum, the first, second and third indicators are different values of the IE.

[0063] In an example, the session report request message may comprise second information indicating a report type of the session report request message.

[0064] In an example, the report type indicated by the second information may be one of: a Downlink Data Report (DLDR) , a Usage Report (USAR) , an Error Indication Report (ERIR) , a User Plane Inactivity Report (UPIR) , a Time Sensitive Communication (TSC) Management Information Report (TMIR) , a Session Report (SESR) , and a UP Initiated Session Request (UISR) .

[0065] In an example, the "Report Type" IE may be encoded as shown in table 3. It indicates the type of the report the UP function (such as UPF 101) sends to the CP function (such as SMF 103) .

[0066] Table 3: Report Type

[0067] Octet 5 may be encoded as follows:

[0068] -Bit 1 –DLDR (Downlink Data Report) : when set to "1" , this indicates Downlink Data Report

[0069] -Bit 2 –USAR (Usage Report) : when set to "1" , this indicates a Usage Report

[0070] -Bit 3 –ERIR (Error Indication Report) : when set to "1" , this indicates an Error Indication Report.

[0071] -Bit 4 –UPIR (User Plane Inactivity Report) : when set to "1" , this indicates a User Plane Inactivity Report.

[0072] -Bit 5 –TMIR (TSC Management Information Report) : when set to "1" , this indicates a TSC Management Information Report, includes support of integration with TSN, TSCTS and DetNet.

[0073] -Bit 6 –SESR (Session Report) : when set to "1" , this indicates a Session Report.

[0074] -Bit 7 –UISR (UP Initiated Session Request) : when set to "1" , this indicates it is a UP function initiated request for a reason which is indicated by the PFCPSRReq-Flags, for the PFCP session.

[0075] -Bit 8 –Spare, for future use and set to "0" .

[0076] For example, at least one bit of the "Report Type" IE shall be set to "1" . Alternatively or additionally, several bits of the "Report Type" IE may be set to "1" .

[0077] For example, if the UPF 101 send a PFCP Session Report Request message to the alternative SMF 103 of the SMF set when there is a Downlink Data Report (DLDR) , a Usage Report (USAR) , an Error Indication Report (ERIR) , a User Plane Inactivity Report (UPIR) , a TSC Management Information Report (TMIR) , a Session Report (SESR) to send, the UPF 101 may set the respective bit of the "Report Type" IE to "1" .

[0078] In addition, if the UPF 101 send a PFCP Session Report Request message to the alternative SMF 103 of the SMF set if there are no such reports to send, the UPF 101 may set the bit 7 "UISR" of the "Report Type" IE to "1" .

[0079] Alternatively, the report type indicated by the second information may be a first additional type, which may be referred as "SMF Change Report" .

[0080] Alternatively, the report type indicated by the second information may be a second additional type, which may be referred as "Pending Payload Packet to Control Plane Function Report" .

[0081] In an example, the additional report types "SMF Change Report" or "Pending Payload Packet to Control Plane Function Report" may be presented by the spare bit 8 of the "Report Type" IE.

[0082] Alternatively, the additional report types "SMF Change Report" or "Pending Payload Packet to Control Plane Function Report" may be presented by new IE (s) respectively, such as "SMF Change Report" IE or "Pending Payload Packet to Control Plane Function Report" IE.

[0083] Note that, the above "SMF Change Indication" IE in table 2, for example the spare bit 4 of this "SMF Change Indication" IE, may be also used to indicate the additional report types "SMF Change Report" or "Pending Payload Packet to Control Plane Function Report" .

[0084] In an example, the session report request message may comprise third information indicating there is at least one pending payload packet for the session to be sent. For example, the third information may include a fourth indicator.

[0085] In an example, the third information may be presented by the "PFCPSRReq-Flags" IE in the table 1 and the fourth indicator is presented by a bit of the "PFCPSRReq-Flags" IE of table 1.

[0086] For example, the spare bit 5 of the "PFCPSRReq-Flags" IE may be defined as:

[0087] Bit 5 –PPPCP (Pending Payload Packet to CP function) : if this bit is set to "1" , it indicates if there are pending payload packets to be sent towards the new SMF via a new N4-u tunnel.

[0088] Alternatively, other bits such as bit 2 of the "PFCPSRReq-Flags" IE may be defined as PPPCP. In this case, the reason field may use other bits of the "PFCPSRReq-Flags" IE.

[0089] In addition, the third information may be presented by an additional IE, for example, "Pending Payload Packet to Control Plane Function" IE.

[0090] Note that, the above "SMF Change Indication" IE in table 2 or the above "SMF Change Report" IE or "Pending Payload Packet to Control Plane Function Report" IE may be also used to indicate the third information "Pending Payload Packet to Control Plane Function" .

[0091] In an example, the UPF 101 may send a PFCP Session Report Request message proactively or reactively to an alternative SMF 103 in the SMF set.

[0092] In an example, the UPF 101 may send a PFCP Session Report Request message proactively to an alternative SMF 103 in the SMF set, e.g., when there is no other report to be sent to the SMF 103 in the PFCP Session Report Request message. That is, there is no report with known report type, such as a Downlink Data Report (DLDR) , a Usage Report (USAR) , an Error Indication Report (ERIR) , a User Plane Inactivity Report (UPIR) , a Time Sensitive Communication (TSC) Management Information Report (TMIR) , a Session Report (SESR) , and a UP Initiated Session Request (UISR) .

[0093] In example (1) of the proactively approach, the PFCP Session Report Request message may include the first information indicating a reason for the UPF 101 to send the PFCP Session Report Request message, and the first information may be presented by a new IE (which may be referred as "SMF Change Indication" ) , for example, bit (s) of the IE "SMF Change Indication" in table 2 may be used to present the reason (s) respectively. In addition, in the example (1) , the PFCP Session Report Request message may include the second information indicating the report type, and the report type may be set as UISR, for example, the second information may be presented by bit 7 (UISR) of the "Report Type" IE in table 3.

[0094] In example (2) of the proactively approach, the PFCP Session Report Request message may include the first information indicating a reason for the UPF 101 to send the PFCP Session Report Request message, and the first information may be presented by the IE "PFCPSRReq-Flags" , for example, bit (s) of the IE "PFCPSRReq-Flags" in table 1 may be used to present the reason (s) respectively. In addition, in the example (2) , the PFCP Session Report Request message may include the second information indicating the report type, and the report type may be set as UISR, for example, the second information may be presented by bit 7 (UISR) of the "Report Type" IE in table 3.

[0095] In example (3) of the proactively approach, the PFCP Session Report Request message may include the first information indicating a reason for the UPF 101 to send the PFCP Session Report Request message, and the first information may be presented by a new IE (which may be referred as "SMF Change Indication" ) , for example, bit (s) of the IE "SMF Change Indication" in table 2 may be used to present the reason (s) respectively. In addition, in the example (3) , the PFCP Session Report Request message may include the second information indicating the report type, and the report type may be set as a new type (which may be referred as "SMF Change Report" ) , for example, the second information may be presented by spare bit 8 of the "Report Type" IE in table 3.

[0096] In example (4) of the proactively approach, the PFCP Session Report Request message may include the first information indicating a reason for the UPF 101 to send the PFCP Session Report Request message, and the first information may be presented by the IE "PFCPSRReq-Flags" , for example, bit (s) of the IE "PFCPSRReq-Flags" in table 1 may be used to present the reason (s) respectively. In addition, in the example (4) , the PFCP Session Report Request message may include the second information indicating the report type, and the report type may be set as a new type (which may be referred as "SMF Change Report" ) , for example, the second information may be presented by spare bit 8 of the "Report Type" IE in table 3.

[0097] In an example, the UPF 101 may control the pace of the PFCP session restoration towards the alternative SMF (s) 103, for example, the UPF 101 may control the pace for sending the PFCP Session Report Request message, to avoid the overloading of the SMF (s) .

[0098] In an example, the UPF 101 may send a PFCP Session Report Request message reactively to an alternative SMF 103 in the SMF set. The reactive approach may spread the restoration signalling over the time, and thus may reduce the risk for SMF overloading.

[0099] In an example, the UPF 101 may send a PFCP Session Report Request message reactively, when there is a report to be sent to the SMF 103 in the PFCP Session Report Request message. That is, there is a report with known report type, such as a Downlink Data Report (DLDR) , a Usage Report (USAR) , an Error Indication Report (ERIR) , a User Plane Inactivity Report (UPIR) , a Time Sensitive Communication (TSC) Management Information Report (TMIR) , a Session Report (SESR) , and a UP Initiated Session Request (UISR) .

[0100] In example (5) of the reactively approach, the PFCP Session Report Request message may include the first information indicating a reason for the UPF 101 to send the PFCP Session Report Request message, and the first information may be presented by a new IE (which may be referred as "SMF Change Indication" ) , for example, bit (s) of the IE "SMF Change Indication" in table 2 may be used to present the reason (s) respectively. In addition, in the example (5) , the PFCP Session Report Request message may include the second information indicating the report type, and the report type may be set according to the type of the report to be sent, for example, the second information may be presented by bit 1 (DLDR) of the "Report Type" IE in table 3, if the report to be sent is a Downlink Data Report.

[0101] In example (6) of the reactively approach, the PFCP Session Report Request message may include the first information indicating a reason for the UPF 101 to send the PFCP Session Report Request message, and the first information may be presented by the IE "PFCPSRReq-Flags" , for example, bit (s) of the IE "PFCPSRReq-Flags" in table 1 may be used to present the reason (s) respectively. In addition, in the example (6) , the PFCP Session Report Request message may include the second information indicating the report type, and the report type may be set according to the type of the report to be sent, for example, the second information may be presented by bit 1 (DLDR) of the "Report Type" IE in table 3, if the report to be sent is a Downlink Data Report.

[0102] In an example, the UPF 101 may send a PFCP Session Report Request message reactively, for example when there is at least one pending payload packet for the session to be sent to SMF in a user plane tunnel. For example, when the UPF 101 receives payload packets (pertaining to an affected PFCP session) which is supposed to be sent to the old SMF 102 via N4-u (via an Uplink (UL) Packet Detection Rule or Forwarding Action Rule (PDR / FAR) ) , e.g. a packet containing Route Solicitation for a IPv6 PDU session, the UPF 101 may send a PFCP Session Report Request message reactively.

[0103] In example (7) of the reactively approach, the PFCP Session Report Request message may include the first information indicating a reason for the UPF 101 to send the PFCP Session Report Request message, and the first information may be presented by a new IE (which may be referred as "SMF Change Indication" ) , for example, bit (s) of the IE "SMF Change Indication" in table 2 may be used to present the reason (s) respectively. In addition, in the example (7) , the PFCP Session Report Request message may include the second information indicating the report type, and the report type may be set as UISR, for example, the second information may be presented by bit 7 (UISR) of the "Report Type" IE in table 3. In addition, in the example (7) , the PFCP Session Report Request message may include the third information indicating that there is at least one pending payload packet for the session to be sent, and the third information may be presented by a new IE (for example the "SMF Change Indication" ) , for example, a bit (e.g. bit 4) of the IE "SMF Change Indication" in table 2 may be used to present the third information.

[0104] In example (8) of the reactively approach, the PFCP Session Report Request message may include the first information indicating a reason for the UPF 101 to send the PFCP Session Report Request message, and the first information may be presented by a new IE (which may be referred as "SMF Change Indication" ) , for example, bit (s) of the IE "SMF Change Indication" in table 2 may be used to present the reason (s) respectively. In addition, in the example (8) , the PFCP Session Report Request message may include the second information indicating the report type, and the report type may be set as UISR, for example, the second information may be presented by bit 7 (UISR) of the "Report Type" IE in table 3. In addition, in the example (8) , the PFCP Session Report Request message may include the third information indicating that there is at least one pending payload packet for the session to be sent, and the third information may be presented by the above PPPCP (bit 2 or 5) of the "PFCPSRReq-Flags" IE in table 1.

[0105] In example (9) of the reactively approach, the PFCP Session Report Request message may include the first information indicating a reason for the UPF 101 to send the PFCP Session Report Request message, and the first information may be presented by the IE "PFCPSRReq-Flags" , for example, bit (s) of the IE "PFCPSRReq-Flags" in table 1 may be used to present the reason (s) respectively. In addition, in the example (9) , the PFCP Session Report Request message may include the second information indicating the report type, and the report type may be set as UISR, for example, the second information may be presented by bit 7 (UISR) of the "Report Type" IE in table 3. In addition, in the example (9) , the PFCP Session Report Request message may include the third information indicating that there is at least one pending payload packet for the session to be sent, and the third information may be presented by the above PPPCP (bit 2 or 5) of the "PFCPSRReq-Flags" IE in table 1.

[0106] In example (10) of the reactively approach, the PFCP Session Report Request message may include the first information indicating a reason for the UPF 101 to send the PFCP Session Report Request message, and the first information may be presented by a new IE (which may be referred as "SMF Change Indication" ) , for example, bit (s) of the IE "SMF Change Indication" in table 2 may be used to present the reason (s) respectively. In addition, in the example (10) , the PFCP Session Report Request message may include the second information indicating the report type, and the report type may be set as a new type (which may be referred as "SMF Change Report" or "Pending Payload Packet to Control Plane Function Report" ) , for example, the second information may be presented by spare bit 8 of the "Report Type" IE in table 3. In addition, in the example (10) , the PFCP Session Report Request message may include the third information indicating that there is at least one pending payload packet for the session to be sent, and the third information may be presented by a new IE (for example the "SMF Change Indication" ) , for example, a bit (e.g. bit 4) of the IE "SMF Change Indication" in table 2 may be used to present the third information. Note that, if the second information is set as the new type "Pending Payload Packet to Control Plane Function Report" , the PFCP Session Report Request message may not include the third information.

[0107] In example (11) of the reactively approach, the PFCP Session Report Request message may include the first information indicating a reason for the UPF 101 to send the PFCP Session Report Request message, and the first information may be presented by a new IE (which may be referred as "SMF Change Indication" ) , for example, bit (s) of the IE "SMF Change Indication" in table 2 may be used to present the reason (s) respectively. In addition, in the example (11) , the PFCP Session Report Request message may include the second information indicating the report type, and the report type may be set as a new type (which may be referred as "SMF Change Report" or "Pending Payload Packet to Control Plane Function Report" ) , for example, the second information may be presented by spare bit 8 of the "Report Type" IE in table 3. In addition, in the example (11) , the PFCP Session Report Request message may include the third information indicating that there is at least one pending payload packet for the session to be sent, and the third information may be presented by the above PPPCP (bit 2 or 5) of the "PFCPSRReq-Flags" IE in table 1. Note that, if the second information is set as the new type "Pending Payload Packet to Control Plane Function Report" , the PFCP Session Report Request message may not include the third information.

[0108] In example (12) of the reactively approach, the PFCP Session Report Request message may include the first information indicating a reason for the UPF 101 to send the PFCP Session Report Request message, and the first information may be presented by the IE "PFCPSRReq-Flags" , for example, bit (s) of the IE "PFCPSRReq-Flags" in table 1 may be used to present the reason (s) respectively. In addition, in the example (12) , the PFCP Session Report Request message may include the second information indicating the report type, and the report type may be set as a new type (which may be referred as "SMF Change Report" or "Pending Payload Packet to Control Plane Function Report" ) , for example, the second information may be presented by spare bit 8 of the "Report Type" IE in table 3. In addition, in the example (12) , the PFCP Session Report Request message may include the third information indicating that there is at least one pending payload packet for the session to be sent, and the third information may be presented by the above PPPCP (bit 2 or 5) of the "PFCPSRReq-Flags" IE in table 1. Note that, if the second information is set as the new type "Pending Payload Packet to Control Plane Function Report" , the PFCP Session Report Request message may not include the third information.

[0109] The above example (1) to (12) may be summarized in the following table 4.

[0110] Table 4. information to be sent in the PFCP Session Report Request message

[0111] Upon receiving such request (s) in for example the PFCP Session Report Request message, the SMF 103 (or 104, depending on which SMF receives the request) may take over the control of the PFCP sessions from the previous SMF 102 and send a PFCP Session Report Response messages. The PFCP Session Report Response messages may include an identifier of the user plane tunnel at the SMF 103, for example a Full Qualified Tunnel Endpoint Identifier (F-TEID) of the new tunnel. For example, the PFCP Session Report Response messages may include N4-u F-TEID if the UPF has indicated there are pending payload packet to be sent towards the new SMF via a new N4-u tunnel in the message.

[0112] In an example, for each PFCP session, the PFCP Session Report Response messages may include the CP F-SEID IE with the IPv4 or IPv6 address of the new PFCP entity and the same or a modified SEID.

[0113] In an example, the PFCP Session Report Response messages may optionally include the N4-u F-TEID that the UPF may use for sending data towards the new entity.

[0114] Alternatively or additionally (not depicted in the Figure 2A) , the SMF 103 may redirect a PFCP session report request to a different SMF (for example, the SMF 104) of the same SMF set, either by rejecting the PFCP session report request with the cause "Redirection Requested" and with the IP address of the new entity to contact, or by forwarding the request to another PFCP entity pertaining to the same SMF or another SMF in the SMF set. In the former case, the UPF 101 may resend a PFCP session report request to the new PFCP entity to contact. In the latter case, the new PFCP entity may send a PFCP session report response including the CP F-SEID IE with the IPv4 or IPv6 address of the new PFCP entity and the same or a modified SEID, and optionally including the N4-u F-TEID that the UPF shall use for sending data towards the new entity.

[0115] Alternatively or additionally, when the UPF 101 detects that none of the SMF 102, 103, 104 of the SMF set is responsive for a preconfigured time, the UPF 101 may delete all the session contexts established by any SMF of the SMF set that it may have stored.

[0116] In the examples, the method for session moving among a set of control plane function are described by reference to the session moving among a set of SMFs 102, 103, 104 over N4 with the UPF 101.

[0117] Note that, the examples may be also applicable to session moving among a set of other control plane functions. For example, the examples may be also applicable to Sxa and Sxb, for combined SGW-C / PGW-C / SMF, i.e. Sxa-U and Sxb-U. That is, in other examples, the UPF 101 may be replaced with other user plane function, for example Packet Data Network Gateway-User Plane (PGW-U) or Serving GateWay-User Plane (SGW-U) ; and the SMFs 102, 103, 104 may be replaced with other control plane functions, comprising Packet Data Network Gateway-Control Plane (PGW-C) , Serving GateWay-Control Plane (SGW-C) , or combined SGW-C / PGW-C / SMF.

[0118] The above examples may define clearly when and how the user plane function shall send a session report request to the alternative control plane function (s) of the set of control plane function (s) .

[0119] The above examples may avoid losses of messages from wireless device (such as User Equipment, UE) , which are essential for nearly all Protocol Data Unit (PDU) sessions.

[0120] Figure 2B is a schematic signaling chart showing the messages in an example session set modification procedure, according to the embodiments herein. The signaling chart of Figure 2B may be applicable to the architecture in Figure 1 and other architecture (s) in for example LTE.

[0121] In an embodiment, the signaling chart in Figure 2B may include the following messages or steps:

[0122] Step 1. When there is a need to change the SMF controlling certain PFCP sessions, e.g. when a partial or complete failure takes place, the SMF (either the SMF 102 serving the PFCP sessions or another SMF 103 or 104 in the same Set taking over the control of the PFCP sessions) may send a PFCP Session Set Modification Request message to the UPF (s) 101 to request the UPF (s) to send subsequent PFCP Session Report Request messages to the alternative SMF (as indicated in the Alternative SMF IP Address IE) for the PFCP sessions which are associated with the FQ-CSID (s) or Group ID (s) , or which have their CP F-SEIDs containing the SMF IP Address as shown in Figure 2B.

[0123] The SMF may instruct the UPF to move sessions associated with different SMF FQ-CSIDs, Group Ids or SMF IP addresses, to different SMF addresses.

[0124] Step 2. The UPF 101 shall continue with the step 3 in the procedure shown in Figure 2A. In addition, the UPF 101 may send a response message.

[0125] Figure 3 is a schematic signaling chart showing the messages in another example procedure for session moving among a set of SMFs, according to the embodiments herein. The signaling chart of Figure 3 may be applicable to the architecture in Figure 1 and other architecture (s) in for example LTE.

[0126] In an embodiment, the signaling chart in Figure 3 may include the following messages or steps:

[0127] Step 1. The UE 301 may send protocol packets to the UPF 101, for example via the Access and Mobility Management Function (AMF) 302.

[0128] Step 2. The UPF 101 may forward the protocol packets to SMF1 102 successfully.

[0129] Step 3. The UE 301 may send protocol packets to the UPF 101.

[0130] Step 4. The UPF 101 may still send protocol packets to the SMF1 102 because no failure is detected at the UPF 101. However, the protocol packets are discarded finally since the SMF1 102 fails.

[0131] Step 5. The UE 101 may send protocol packets to the UPF 101. The UPF 101 may buffer the protocol packets, since the UPF 101 has detected the failure of the SMF1 102 and set FAR of N4-u to buffer. The buffered protocol packets may form the pending packets to the SMF (s) , for example the SMF1 102.

[0132] Step 6. The UPF 101 may send a PFCP session report request to the SMF3 104 (or SMF2 103, depending on the UPF 101 determine to move the session to which SMF) in the same SMF set as SMF1 102, with Report type: UISR, PFCPSRReq-Flags: PPPCP and IE "SMF Change Indication" to trigger session switch (or session moving) . Note that, the UPF 101 may send a PFCP session report request with various parameter or information described in Figure 2A.

[0133] Step 7. The SMF3 104 may send a PFCP session report response message to the UPF 101 to switch session. The SMF3 104 may include the new tunnel ID (for example, N4u F-TEID) in the PFCP session report response message.

[0134] Step 8. The UPF 101 may set FAR of N4-u back to "FORWARD" and forward protocol packets to the SMF3 104 successfully.

[0135] Step 9. The UE 301 may send protocol packets to the UPF 101.

[0136] Step 10. The UPF 101 may forward the protocol packets to the SMF3 104 successfully.

[0137] Figure 4 is a schematic flow chart showing an example method 400 in the first network node, according to the embodiments herein. In an embodiment, the flow chart in Figure 4 may be implemented in the UPF 101, but may also implemented in other user plane function or network node implementing a user plane function.

[0138] The method 400 may begin with step S401, in which the first network node (such as the UPF 101) may determine that a session between the first network node and a second network node implementing a first control plane function in a network function set (such as the SMF1 102) is to be moved from the second network node to a third network node implementing a second control plane function in the network function set (such as the SMF2 103 or the SMF3 104) .

[0139] In an embodiment, determining that the session is to be moved from the second network node to the third network node may be based on: detecting that the second network node is not responsive; detecting a failure of the second network node; or being instructed by a network node implementing a control plane function (which may be the SMFs 102, 103, 104 shown in Figure 2A or other SMF (s) in the SMF set) in the network function set to move the session.

[0140] Then, the method 400 may proceed to step S402, in which the first network node (such as the UPF 101) may send a session report request message to the third network node, for moving the session to the third network node.

[0141] In an embodiment, the session report request message may comprise first information indicating a reason for the first network node to send the session report request message.

[0142] In an embodiment, the first information may comprise at least one of: a first indicator (such as MPSNR) indicating that the first network node moves the session due to the second network node not responding; a second indicator (such as MPSHF) indicating that the first network node moves the session due to the second network node failure; and a third indicator (such as MPSAI) indicating that the first network node moves the session as instructed by the network node.

[0143] In an embodiment, the session report request message may be a Packet Forward Control Protocol (PFCP) session report request (PFCPSRReq) message.

[0144] In an embodiment, the first information may be presented by an information element PFCPSRReq-Flags and each of the first indicator, the second indicator and the third indicator is presented by a bit of the information element PFCPSRReq-Flags respectively, as shown in the above table 1.

[0145] In an embodiment, the first information may be presented by a first additional information element for example "SMF Change Indication" and each of the first indicator, the second indicator and the third indicator is presented by the first additional information element respectively, as shown in the above table 2.

[0146] In an embodiment, the session report request message may comprise second information indicating a report type of the session report request message.

[0147] In an embodiment, the report type indicated by the second information may be one of: a Downlink Data Report (DLDR) , a Usage Report (USAR) , an Error Indication Report (ERIR) , a User Plane Inactivity Report (UPIR) , a Time Sensitive Communication (TSC) Management Information Report (TMIR) , a Session Report (SESR) , and a UP Initiated Session Request (UISR) , as shown in the above table 3.

[0148] In an embodiment, the report type indicated by the second information may be a first additional type, for example "SMF Change Report" .

[0149] In an embodiment, the report type indicated by the second information may be a second additional type, for example "Pending Payload Packet to Control Plane Function Report" .

[0150] In an embodiment, the session report request message may be sent proactively by the first network node. In an embodiment, the session report request message may be sent when there is no report to be sent to the third network node in the session report request message. In an embodiment, the first network node may control a pace for sending the session report request message, to avoid overloading. The examples for the proactive approach may include but not limit to the above examples (1) to (4) described in related to Figure 2A.

[0151] In an embodiment, the session report request message may be sent reactively by the first network node. In an embodiment, the session report request message may be sent when there is a report to be sent to the third network node in the session report request message or there is at least one pending payload packet for the session to be sent to a control plane function in a user plane tunnel. The examples for the reactive approach may include but not limit to the above examples (5) to (12) described related to Figure 2A.

[0152] In an embodiment, the session report request message may comprise a fourth indicator (such as the "PPPCP" as described related to Figure 2A) indicating that there is at least one pending payload packet for the session to be sent.

[0153] In an embodiment, the fourth indicator may be included in third information in the session report request message, the third information is presented by an information element PFCPSRReq-Flags as shown in table 1, and the fourth indicator may be presented by a bit such as bit 2 or bit 5 of the information element PFCPSRReq-Flags.

[0154] In an embodiment, the fourth indicator may be a second additional information element (Pending Payload Packet to Control Plane Function) or may be included in the IE "SMF Change Indication" .

[0155] Then, the method 400 may proceed to step S403, in which the first network node (such as the UPF 101) may receiving a session report response message from the third network node. The session report response message may comprise fourth information indicating an identifier of the user plane tunnel at the third network node.

[0156] In an embodiment, the identifier of the user plane tunnel at the third network node may be a Full Qualified Tunnel Endpoint Identifier (F-TEID) , such as N4u F-TEID.

[0157] Note that, the examples may be also applicable to session moving among a set of other control plane functions. For example, the examples may be also applicable to Sxa and Sxb, for combined SGW-C / PGW-C / SMF, i.e. Sxa-U and Sxb-U. That is, in other examples, the UPF 101 may be replaced with other user plane function, for example Packet Data Network Gateway-User Plane (PGW-U) or Serving GateWay-User Plane (SGW-U) ; and the SMFs 102, 103, 104 may be replaced with other control plane functions, comprising Packet Data Network Gateway-Control Plane (PGW-C) , Serving GateWay-Control Plane (SGW-C) , or combined SGW-C / PGW-C / SMF.

[0158] The above steps are only examples, and the first network node (such as the UPF 101) may perform any related actions described with respect to Figures 1 to 3.

[0159] Figure 5 is a schematic flow chart showing an example method 500 in the third network node, according to the embodiments herein. In an embodiment, the flow chart in Figure 5 may be implemented in the SMF2 103 or SMF3 104, but may also implemented in other control plane function or network node implementing a control plane function.

[0160] The method 500 may begin with step S501, in which the third network node (such as the SMF2 103 or SMF3 104) may receive a session report request message from a first network node implementing a user plane function (such as the UPF1 101) , for moving a session between the first network node and a second network node implementing a first control plane function in the network function set (such as the SMF1 102) from the second network node to the third network node (such as the SMF2 103 or the SMF3 104) .

[0161] In an embodiment, determining that the session is to be moved from the second network node to the third network node may be based on: detecting that the second network node is not responsive; detecting a failure of the second network node; or being instructed by a network node implementing a control plane function (which may be the SMFs 102, 103, 104 shown in Figure 2A or other SMF (s) in the SMF set) in the network function set to move the session.

[0162] In an embodiment, the session report request message may comprise first information indicating a reason for the first network node to send the session report request message.

[0163] In an embodiment, the first information may comprise at least one of: a first indicator (such as MPSNR) indicating that the first network node moves the session due to the second network node not responding; a second indicator (such as MPSHF) indicating that the first network node moves the session due to the second network node failure; and a third indicator (such as MPSAI) indicating that the first network node moves the session as instructed by the network node.

[0164] In an embodiment, the session report request message may be a Packet Forward Control Protocol (PFCP) session report request (PFCPSRReq) message.

[0165] In an embodiment, the first information may be presented by an information element PFCPSRReq-Flags and each of the first indicator, the second indicator and the third indicator is presented by a bit of the information element PFCPSRReq-Flags respectively, as shown in the above table 1.

[0166] In an embodiment, the first information may be presented by a first additional information element for example "SMF Change Indication" and each of the first indicator, the second indicator and the third indicator is presented by the first additional information element respectively, as shown in the above table 2.

[0167] In an embodiment, the session report request message may comprise second information indicating a report type of the session report request message.

[0168] In an embodiment, the report type indicated by the second information may be one of: a Downlink Data Report (DLDR) , a Usage Report (USAR) , an Error Indication Report (ERIR) , a User Plane Inactivity Report (UPIR) , a Time Sensitive Communication (TSC) Management Information Report (TMIR) , a Session Report (SESR) , and a UP Initiated Session Request (UISR) , as shown in the above table 3.

[0169] In an embodiment, the report type indicated by the second information may be a first additional type, for example "SMF Change Report" .

[0170] In an embodiment, the report type indicated by the second information may be a second additional type, for example "Pending Payload Packet to Control Plane Function Report" .

[0171] In an embodiment, the session report request message may be sent proactively by the first network node. In an embodiment, the session report request message may be sent when there is no report to be sent to the third network node in the session report request message. In an embodiment, the first network node may control a pace for sending the session report request message, to avoid overloading. The examples for the proactive approach may include but not limit to the above examples (1) to (4) described in related to Figure 2A.

[0172] In an embodiment, the session report request message may be sent reactively by the first network node. In an embodiment, the session report request message may be sent when there is a report to be sent to the third network node in the session report request message or there is at least one pending payload packet for the session to be sent to a control plane function in a user plane tunnel. The examples for the reactive approach may include but not limit to the above examples (5) to (12) described related to Figure 2A.

[0173] In an embodiment, the session report request message may comprise a fourth indicator (such as the "PPPCP" as described related to Figure 2A) indicating that there is at least one pending payload packet for the session to be sent.

[0174] In an embodiment, the fourth indicator may be included in third information in the session report request message, the third information is presented by an information element PFCPSRReq-Flags as shown in table 1, and the fourth indicator may be presented by a bit such as bit 2 or bit 5 of the information element PFCPSRReq-Flags.

[0175] In an embodiment, the fourth indicator may be a second additional information element (Pending Payload Packet to Control Plane Function) or may be included in the IE "SMF Change Indication" .

[0176] Then, the method 500 may proceed to step S502, in which the third network node (such as the SMF2 103 or SMF3 104) may send a session report response message to the first network node. The session report response message may comprise fourth information indicating an identifier of the user plane tunnel at the third network node.

[0177] In an embodiment, the identifier of the user plane tunnel at the third network node may be a Full Qualified Tunnel Endpoint Identifier (F-TEID) , such as N4u F-TEID.

[0178] Note that, the examples may be also applicable to session moving among a set of other control plane functions. For example, the examples may be also applicable to Sxa and Sxb, for combined SGW-C / PGW-C / SMF, i.e. Sxa-U and Sxb-U. That is, in other examples, the UPF 101 may be replaced with other user plane function, for example Packet Data Network Gateway-User Plane (PGW-U) or Serving GateWay-User Plane (SGW-U) ; and the SMFs 102, 103, 104 may be replaced with other control plane functions, comprising Packet Data Network Gateway-Control Plane (PGW-C) , Serving GateWay-Control Plane (SGW-C) , or combined SGW-C / PGW-C / SMF.

[0179] The above steps are only examples, and the third network node (such as the SMF2 103 or SMF3 104) may perform any related actions described with respect to Figures 1 to 3.

[0180] Figure 6 is a schematic block diagram showing an example network node 600, according to the embodiments herein. In an embodiment, the example network node 600 in Figure 6 may be implemented as the above UPF 101 shown in Figures 1 to 3.

[0181] In an embodiment, the network node 600 may comprise processing circuitry 601; and a memory 602. The processing circuitry 601 may be configured to perform the above method 400.

[0182] Note that, the network node 600 may be implemented as hardware, software, firmware and any combination thereof. For example, the network node 600 may include a plurality of units, circuities, modules or the like, each of which may be used to perform one or more steps of the example method 400 or one or more steps shown in Figure 4 related to the first network node (such as UPF 101) .

[0183] Figure 7 is a schematic block diagram showing an example network node 700, according to the embodiments herein. In an embodiment, the example network node 700 in Figure 7 may be implemented as the above SMF 103 or 104 shown in Figures 1 to 3.

[0184] In an embodiment, the network node 700 may comprise processing circuitry 701; and a memory 702. The processing circuitry 701 may be configured to perform the above method 500.

[0185] Note that, the network node 700 may be implemented as hardware, software, firmware and any combination thereof. For example, the network node 700 may include a plurality of units, circuities, modules or the like, each of which may be used to perform one or more steps of the example method 500 or one or more steps shown in Figure 5 related to the third network node (such as SMF 103 or 104) .

[0186] Figure 8 is a schematic block diagram showing an example computer-implemented network node 800, according to the embodiments herein. In an embodiment, the network node 800 may be configured as the above mentioned network node, such as the UPF 101, SMF 103 or 104 as shown in Figures 1 to 3.

[0187] In an embodiment, the network node 800 may include but not limited to at least one processor such as Central Processing Unit (CPU) 801, a computer-readable medium 802, and a memory 803. The memory 803 may comprise a volatile (e.g., Random Access Memory, RAM) and / or non-volatile memory (e.g., a hard disk or flash memory) . In an embodiment, the computer-readable medium 802 may be configured to store a computer program and / or instructions, which, when executed by the processor 801, causes the processor 801 to carry out any of the above mentioned methods 400 or 500.

[0188] In an embodiment, the computer-readable medium 802 (such as tangible, non-transient computer readable medium) may be stored in the memory 803. In another embodiment, the computer program may be stored in a remote location for example computer program product 804 (also may be embodied as or include a tangible, non-transient computer-readable medium) , and accessible by the processor 801 via for example carrier 805.

[0189] The computer-readable medium 802 and / or the computer program product 804 may be distributed and / or stored on a removable computer-readable medium, e.g. diskette, CD (Compact Disk) , DVD (Digital Video Disk) , flash or similar removable memory media (e.g. compact flash, SD (secure digital) , memory stick, mini SD card, MMC multimedia card, smart media) , HD-DVD (High Definition DVD) , or Blu-ray DVD, USB (Universal Serial Bus) based removable memory media, magnetic tape media, optical storage media, magneto-optical media, bubble memory, or distributed as a propagated signal via a network (e.g. Ethernet, ATM, ISDN, PSTN, X. 25, Internet, Local Area Network (LAN) , or similar networks capable of transporting data packets to the infrastructure node) .

[0190] Figure 9 is a schematic block diagram showing an example communication system 900, according to the embodiments herein.

[0191] In an embodiment, the communication system 900 may comprise the first network node 600 and the third network node 700. In an embodiment, the communication system 900 may further comprise a second network node 901, which may be in the same network function set as the third network node 700 and has the similar structure as the third network node 700. In an embodiment, the communication system 900 may further comprise other wireless devices and / or network nodes (not shown in Figure 9) .

[0192] In an embodiment, the communication system 900 may be configured in an OTT scenario. The OTT connection may be transparent in the sense that the participating communication devices through which the OTT connection passes are unaware of routing of uplink and downlink communications. For example, the network node 600 or 700 may not or need not be informed about the past routing of an incoming downlink communication with data originating from one or more network functions to be forwarded (e.g., handed over) to a connected terminal device (s) , such as UE 301. Similarly, the network node 600 or 700 needs not be aware of the future routing of an outgoing uplink communication originating from the terminal device (s) , such as UE 301 towards one or more network functions.

[0193] It should also be understood that, a network element (such as the UE 301, AMF 302, UPF 101, SMFs 102, 103, 104, the network nodes 600, 700) can be implemented either as a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., on a cloud infrastructure.

[0194] Although the computing devices described herein (e.g., UEs, network nodes, hosts) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. 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. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0195] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on 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 hard-wired 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.

[0196] This disclosure also proposes the following embodiments / implements.

[0197] The Change Request for 3GPP TS 23.527 V19.0.0 (2024-09)

[0198] Title: Triggering to move PFCP sessions upon forwarding Sxb / N4-u packets

[0199] Reason for change: As specified in clause 4.4.3.2 of 3GPP TS 23.527 V19.0.0, upon detecting the SMF failure, not responding, or be requested to move a set of PFCP sessions associated with the FQ-CSID (s) or Group ID (s) or CP F-SEID (s) containing the SMF IP address (see also the clause 4.7.3) , the UPF will move the affected PFCP sessions towards an alternative SMF pertaining to the same SMF set.

[0200] When doing so, it shall send a PFCP Session Report Request message per PFCP session. 4.4.3.2 Failure of an SMF in a SMF set

[0201] …

[0202] 3. Upon being instructed by the SMFs to move PFCP sessions, or upon detecting that the SMF1 is not responsive, the UPF sends subsequent PFCP Session Report Request messages to the alternative SMFs of the SMF set, as specified in clause 5.22 of 3GPP TS 29.244 [4] and clause 4.7.3. The UPF sets the SEID field to zero in the PFCP header of the PFCP Session Report Request and includes the old CP F-SEID that was assigned by the previous SMF in the request.

[0203] …

[0204] 4.7.3 Restoration of PFCP sessions associated with an FQ-CSID, Group ID or SMF IP Address

[0205] When there is a need to change the SMF controlling certain PFCP sessions, e.g. when a partial or complete failure takes place, the SMF (either the SMF serving the PFCP sessions or another SMF in the same Set taking over the control of the PFCP sessions) may send a PFCP Session Set Modification Request message to the UPF (s) to request the UPF (s) to send subsequent PFCP Session Report Request messages to the alternative SMF (as indicated in the Alternative SMF IP Address IE) for the PFCP sessions which are associated with the FQ-CSID (s) or Group ID(s) , or which have their CP F-SEIDs containing the SMF IP Address as shown in Figure 4.7.3-1 (referring to Figure 2B) .

[0206] The SMF may instruct the UPF to move sessions associated with different SMF FQ-CSIDs, Group Ids or SMF IP addresses, to different SMF addresses.

[0207] However, it is NOT clear when the UPF shall send subsequent PFCP Session Report Request messages to the alternative SMFs of the SMF set:

[0208] ·should the UPF perform such restoration proactively, i.e. trigger to send PFCP Session Report Request message as soon as the SMF failure is detected, or the request to move a group of PFCP sessions is received; or

[0209] ·should the UPF perform it reactively, i.e. send a PFCP session report request message only when there is a need to contact the SMF, e.g. when there is a usage report, downlink data report.

[0210] Proactive approach may lead signaling overload at the SMF, so that the UPF may control the pace of the PFCP session restoration towards the alternative SMF (s) to avoid the SMFs overloaded;

[0211] ·to enable proactively sending PFCP Session Report Request message, 3GPP shall specify how the UPF shall set the Mandatory IE "Report Type" , it seems, unless introducing a new Node type, the existing USIR seems a right one;

[0212] ·If UISR is used, a few new flags in the PFCPSRReq-Flags should be introduced to explain to the SMF why the UPF is doing PFCP session move, e.g. move the PDU session due to SMF failure, move the PDU session due to SMF no responding, move the PDU session upon the request; (these flags can be used for reactive approach as additional purpose to send PFCP session report request message)

[0213] Reactive approach will spread the restoration signalling over the time, this is good. But, there is a problem related to N4-u which needs to be clarified. (see also clause 5.3 in 3GPP TS 29.244)

[0214] ·If the UPF has determined to move all affected PFCP sessions associated with the old SMF to an alternative SMF, besides those occasions to send Dowlink Data Report, Usage Report, Error Indication Report, User Plane Inactivity Report, TSC management Information Report, Session Report, when the UPF receives payload packets (pertaining to an affected PFCP session) which is supposed to be sent to the old SMF via N4-u (via a UL PDR / FAR) , e.g. a packet containing Route Solicitation for a IPv6 PDU session, this shall also trigger the UPF to send a PFCP session report request message; (sending those payload packets to the old SMF are simply not correct! )

[0215] ·Several Report Types, e.g. Downlink Data Report (DLDR) may be used (though it is uplink packets literally) if the UPF implementation consider the FAR (to forward the packets to the old SMF via N4u) is set to buffered, or Usage Report (USAR) if the UPF implementation consider this as START (Start of Traffic) , or UISR can also be used, or even a new report type may be defined.

[0216] ·It is proposed to use UISR, with an additional information indicating to the SMF that the UPF sending PFCP Session Report Request message is to move the PFCP session to the new SMF, due to SMF failure / not responding / ordered to do so, and when the UPF detects there are some payload packets needs to be forwarded to the SMF.

[0217] (note that, it is important to indicate so, since the N4-u F-TEID is an optional IE in the PFCP session report response message, the new SMF shall allocate an N4-u F-TEID when such new additional information is present in the PFCP session report request message.

[0218] Consequences if not approved: It remains unspecified how UPF would move the PFCP session from one SMF to the other using PFCP Session Report Request message; the UPF may not trigger the move of the PFCP session when it receives UL payload packets intended to be sent via N4-U / Sxb-U, therefore it leads a failure for the signaling communication between the UE and the SMF (via user plane) .

[0219] ***First Change *** (the underlined part are parts to be added into the 3GPP specification)

[0220] 4.4.3.2 Failure of an SMF in a SMF set

[0221] When the MPAS or SSET procedure specified for SMF set in clause 5.22 of 3GPP TS 29.244 [4] ) is used, when the UPF detects that a peer PFCP entity in an SMF is not responsive for a preconfigured time, or upon being instructed by SMF (s) of the SMF set to move PFCP sessions, the UPF shall move the PFCP sessions that were served by the failed PFCP entity to another PFCP entity in the same SMF or another SMF, as specified in clause 5.22 of 3GPP TS 29.244 [4] and clause 4.7.3.

[0222] Figure 4.4.3.2-1 (referring to Figure 2A) depicts an example call flow for a failure (without restart) of an SMF in an SMF set using the MPAS or SSET feature.

[0223] Figure 4.4.3.2-1 (referring to Figure 2A) : Failure (without restart) of an SMF in an SMF set using the MPAS or SSET feature

[0224] 0. When using the MPAS feature, the SMFs of the SMF set establish PFCP associations with the UPF, including the SMF Set ID IE set to an FQDN representing the SMF Set and optionally Alternative SMF IP Address IE (s) of alternative PFCP entities in the same SMF or different SMFs of the SMF set.

[0225] When using the SSET feature, one SMF of the SMF set establishes one PFCP association with the UPF for the SMF set, optionally including Alternative SMF IP Address IE (s) of alternative PFCP entities in the same SMF or different SMFs of the SMF set. In this case, the UPF considers that the SMF1, SMF2 and SMF3 represent different PFCP entities.

[0226] The SMFs of the SMF set establish PFCP sessions in the UPF, optionally providing a FQ-CSID and / or a Group ID as described in clause 4.7.2.

[0227] 1. The SMF1 fails without restart.

[0228] 2. The SMFs of the SMF set may request the UPF to move group (s) of PFCP sessions, each identified by a FQ-CSID, Group ID or CP IP Address, to alternative SMF (s) of the SMF set.

[0229] 3. Upon being instructed by the SMFs to move PFCP sessions, or upon detecting that the SMF1 is not responsive, the UPF sends subsequent PFCP Session Report Request messages to the alternative SMFs of the SMF set, as specified in clause 5.22 of 3GPP TS 29.244 [4] and clause 4.7.3. The UPF sets the SEID field to zero in the PFCP header of the PFCP Session Report Request and includes the old CP F-SEID that was assigned by the previous SMF in the request.

[0230] The UPF may send a PFCP Session Report Request message proactively to an alternative SMF in the SMF set, i.e. when there is no Downlink Data Report, nor Usage Report, nor Error Indication Report, nor User Plane Inactivity Report, nor TSC Management Information Report, nor Session Report, to be included in the message; in this case, the UPF shall set Report Type to the "UISR" and indicate the reason for sending the request message, e.g. "move the PFCP session due to the SMF not responding" , "move the PFCP session due to the SMF heartbeat failure" , "move the PFCP session instructed by the SMF in a PFCP Session Set Modification Request" .

[0231] The UPF may send a PFCP Session Report Request message reactively to the alternative SMFs of the SMF set only when there is a report to send, e.g. a Downlink Data Report, a Usage Report, an Error Indication Report, a User Plane Inactivity Report, a TSC Management Information Report, a Session Report. The UPF may also send a PFCP Session Report Request message when it receives payload packets (pertaining to an affected PFCP session) which is intended to be forwarded to the old SMF via N4-u (as instructed via a UL PDR and a UL FAR) , e.g. a packet containing a Route Solicitation message for a IPv6 PDU session; in this case, the UPF shall set Report Type to the "UISR" and indicate the reason for sending the request message (as described above) , in addition, the UPF shall indicate to the SMF there are pending payload packets to be sent towards the new SMF via a new N4-u tunnel in the message.

[0232] Upon receiving such requests, the SMF takes over the control of the PFCP sessions from the previous SMF and sends PFCP Session Report Response messages including, for each PFCP session, the CP F-SEID IE with the IPv4 or IPv6 address of the new PFCP entity and the same or a modified SEID, and shall include N4-u F-TEID if the UPF has indicated there are pending payload packet to be sent towards the new SMF via a new N4-u tunnel in the message, otherwise optionally including the N4-u F-TEID that the UPF shall use for sending data towards the new entity.

[0233] ***Next Change *** (the underlined part are parts to be added into the 3GPP specification)

[0234] 4.7.3 Restoration of PFCP sessions associated with an FQ-CSID, Group ID or SMF IP Address

[0235] When there is a need to change the SMF controlling certain PFCP sessions, e.g. when a partial or complete failure takes place, the SMF (either the SMF serving the PFCP sessions or another SMF in the same Set taking over the control of the PFCP sessions) may send a PFCP Session Set Modification Request message to the UPF (s) to request the UPF (s) to send subsequent PFCP Session Report Request messages to the alternative SMF (as indicated in the Alternative SMF IP Address IE) for the PFCP sessions which are associated with the FQ-CSID (s) or Group ID(s) , or which have their CP F-SEIDs containing the SMF IP Address as shown in Figure 4.7.3-1 (referring to Figure 2B) .

[0236] The SMF may instruct the UPF to move sessions associated with different SMF FQ-CSIDs, Group Ids or SMF IP addresses, to different SMF addresses. The UPF shall continue with the step 3 in the procedure specified in clause 4.4.3.2.

[0237] Figure 4.7.3-1 (referring to Figure 2B) : SMF initiated PFCP Session Set Modification procedure

[0238] ***End of Changes ***

[0239] ***For information ***

[0240] 7.5.8.1 General

[0241] The PFCP Session Report Request shall be sent over the Sxa, Sxb, Sxc, N4 and N4mb interface by the UP function to report information related to a PFCP session to the CP function.

[0242] Table 7.5.8.1-1: Information Elements in a PFCP Session Report Request

[0243] ***Next Information ***

[0244] 8.2.21 Report Type

[0245] The Report Type IE shall be encoded as shown in Figure 8.2.21-1. It indicates the type of the report the UP function sends to the CP function.

[0246] Figure 8.2.21-1: Report Type

[0247] Octet 5 shall be encoded as follows:

[0248] -Bit 1 –DLDR (Downlink Data Report) : when set to "1" , this indicates Downlink Data Report

[0249] -Bit 2 –USAR (Usage Report) : when set to "1" , this indicates a Usage Report

[0250] -Bit 3 –ERIR (Error Indication Report) : when set to "1" , this indicates an Error Indication Report.

[0251] -Bit 4 –UPIR (User Plane Inactivity Report) : when set to "1" , this indicates a User Plane Inactivity Report.

[0252] -Bit 5 –TMIR (TSC Management Information Report) : when set to "1" , this indicates a TSC Management Information Report, includes support of integration with TSN, TSCTS and DetNet.

[0253] -Bit 6 –SESR (Session Report) : when set to "1" , this indicates a Session Report.

[0254] -Bit 7 –UISR (UP Initiated Session Request) : when set to "1" , this indicates it is a UP function initiated request for a reason which is indicated by the PFCPSRReq-Flags, for the PFCP session.

[0255] -Bit 8 –Spare, for future use and set to "0" .

[0256] At least one bit shall be set to "1" . Several bits may be set to "1" .

[0257] The Change Request for 3GPP TS 29.244 V18.7.0 (2024-09)

[0258] Title: Triggering to move PFCP sessions upon forwarding Sxb / N4-u packets

[0259] Reason for change: the same with the “Reason for change” in the above mentioned “The Change Request for 3GPP TS 23.527 V19.0.0 (2024-09) ” .

[0260] This contribution adds protocol impact corresponding the CR to 23.527.

[0261] Consequences if not approved: the same with the “Consequences if not approved” in the above mentioned “The Change Request for 3GPP TS 29.244 V18.7.0 (2024-09) ” .

[0262] ***First Change *** (the added parts are parts to be added into the 3GPP specification) 5.22.2 With one PFCP association per SMF Set and UPF

[0263] When a UPF supports that a PFCP session can be successively controlled by different SMF (s) in the same SMF set, the following applies:

[0264] 1) -6) are omitted, which can be referred to clause 5.22.2 in 3GPP TS 29.244 V18.7.0 (2024-09)

[0265] 7) The UPF shall trigger the SMF restoration procedures for an SMF in a SMF set specified in clause 4.4.3.2 of 3GPP TS 23.527 V19.0.0

[0040] for a PFCP session that can be controlled by different SMFs of an SMF set, e.g. when a heartbeat failure is detected for the IP address of the assigned CP F-SEID.

[0266] When sending a PFCP Session Report Request message to move the PFCP session towards an alternative SMF, UPF shall set Report Type to the "UISR" if:

[0267] - there is no other report to send, e.g. a Downlink Data Report;

[0268] - there are pending payload packets to be sent towards the new SMF via a new N4-u tunnel;

[0269] For the latter case, the UPF shall also set "Pending Payload Packet to CP function" flag in the PFCPSRReq-Flags IE. Otherwise, the UPF shall set Report Type according to the report included in the message.

[0270] The UPF shall also include the SMF Change Indications IE to indicate the reason for SMF change, e.g. "move the PFCP session due to the SMF not responding" , "move the PFCP session due to the SMF failure" , "move the PFCP session instructed by the SMF in a PFCP Session Set Modification Request" .

[0271] ***Next Change *** (the underlined parts are parts to be added into the 3GPP specification)

[0272] 5.22.3 With one PFCP association per SMF and UPF

[0273] If multiple PFCP associations are setup between an UPF and the SMFs in an SMF set, the following applies:

[0274] 1) -6) are omitted, which can be referred to the clause 5.22.3 in 3GPP TS 29.244 V18.7.0 (2024-09)

[0275] 7) The UPF shall trigger the SMF restoration procedures for an SMF in a SMF set specified in clause 4.4.3.2 of 3GPP TS 23.527

[0040] for a PFCP session that can be controlled by different SMFs of an SMF set, e.g. when a heartbeat failure is detected.

[0276] When sending a PFCP Session Report Request message to move the PFCP session towards an alternative SMF, UPF shall set Report Type to the "UISR" if:

[0277] - there is no other report to send, e.g. a Downlink Data Report;

[0278] - there are pending payload packets to be sent towards the new SMF via a new N4-u tunnel;

[0279] For the latter case, the UPF shall also set "Pending Payload Packet to CP function" flag in the PFCPSRReq-Flags IE. Otherwise, the UPF shall set Report Type according to the report included in the message.

[0280] The UPF shall also include the SMF Change Indications IE to indicate the reason for SMF change, e.g. "move the PFCP session due to the SMF not responding" , "move the PFCP session due to the SMF failure" , "move the PFCP session instructed by the SMF in a PFCP Session Set Modification Request" .

[0281] NOTE 4: These restoration procedures cause the UPF to delete the PFCP session contexts only if heartbeat procedures fail with all of the SMFs in the SMF set (i.e. the SMFs with which the UPF has established associations with the same SMF Set ID) .

[0282] 8) If an SMF or UPF fails, the peer PFCP node that detects that error shall remove the PFCP association locally. The SMF and UPF shall then handle the PFCP sessions that were served by this PFCP association as described in step 2 for a PFCP association release.

[0283] 9) A UPF supporting the MPAS feature shall support UE IP address / prefix allocation in the UP function (see clause 5.21) .

[0284] ***Next Change *** (the underlined parts are parts to be added into the 3GPP specification)

[0285] 7.5.8.1 General

[0286] The PFCP Session Report Request shall be sent over the Sxa, Sxb, Sxc, N4 and N4mb interface by the UP function to report information related to a PFCP session to the CP function.

[0287] Table 7.5.8.1-1: Information Elements in a PFCP Session Report Request

[0288] ***Next Change *** (the underlined parts are parts to be added into the 3GPP specification)

[0289] 7.5.9.1 General

[0290] The PFCP Session Report Response shall be sent over the Sxa, Sxb, Sxc, N4 and N4mb interface by the CP function to the UP function as a reply to the PFCP Session Report Request.

[0291] Table 7.5.9.1-1: Information Elements in a PFCP Session Report Response

[0292] ***Next Change *** (the underlined parts are parts to be added into the 3GPP specification)

[0293] 8.1.2 Information Element Types

[0294] A PFCP message may contain several IEs. In order to have forward compatible type definitions for the PFCP IEs, all of them shall be TLV (Type, Length, Value) coded. PFCP IE type values are specified in the Table 8.1.2-1.

[0295] The 3rd column of this table specifies if the IE is either Extendable or has a variable length or a fixed length and a reference to the clause where the IE is specified:

[0296] -Fixed Length: the IE has a fixed set of fields, and a fixed number of octets;

[0297] -Variable Length: the IE has a fixed set of fields, and has a variable number of octets.

[0298] For example, the last octets may be numbered similar to "5 to (n+4) " . In this example, if the value of the length field, n, is 0, then the last field is not present;

[0299] -Extendable: the IE has a variable number of fields, and has a variable number of octets.

[0300] The last fields are typically specified with the statement: "These octet (s) is / are present only if explicitly specified" . The legacy receiving entity shall ignore the unknown octets.

[0301] The 4th column of this table indicates the number of fixed Octets the IE contained when the IE was first defined in the specification, which shall be an integer value reflecting the minimum length of fixed octets defined for the IE.

[0302] An IE of any of the above types may have a null length as specified in clause 5.6.3. This shall not be considered as an error by the receiving PFCP entity.

[0303] In order to improve the efficiency of troubleshooting, it is recommended that the IEs should be arranged in the signalling messages as well as in the grouped IEs, according to the order the IEs are listed in the message definition table or grouped IE definition table in clause 7. However the receiving entity shall be prepared to handle the messages with IEs in any order.

[0304] Within IEs, certain fields may be described as spare. These bits shall be transmitted with the value set to "0" . To allow for future features, the receiver shall not evaluate these bits.

[0305] Table 8.1.2-1: Information Element Types

[0306] ***Next Change *** (the underlined parts are parts to be added into the 3GPP specification)

[0307] 8.2.119 PFCPSRReq-Flags

[0308] The PFCPSRReq-Flags IE indicates flags applicable to the PFCP Session Report Request message. It is coded as depicted in Figure 8.2.119-1.

[0309] Figure 8.2.199-1: PFCPSRReq-Flags

[0310] The following bits within Octet 5 shall indicate:

[0311] -Bit 1 –PSDBU (PFCP Session Deleted By the UP function) : if this bit is set to "1" , it indicates that the UP function has reported all non-zero Usage Reports for all URRs in the PFCP Session and the PFCP Session is being deleted in the UP function locally.

[0312] - Bit 2 – PPPCP (Pending Payload Packet to CP function) : if this bit is set to "1" , it indicates if there are pending payload packets to be sent towards the new SMF via a new N4-u tunnel.

[0313] -Bit 2 to 8 –Spare, for future use, shall be set to "0" by the sender and discarded by the receiver.

[0314] ***Next Change *** (the underlined parts are parts to be added into the 3GPP specification)

[0315] 8.2. aaa SMF Change Indications

[0316] The FlagsSMF Change Indications IE indicates the reason for the UPF sending a PFCP Session Report Request message to move the PFCP session to an alternative SMF pertaining to the same SMF set. It is coded as depicted in Figure 8.2. aaa-1.

[0317] Figure 8.2. aaa-1: SMF Change Indications

[0318] The following bits within Octet 5 shall indicate:

[0319] - Bit 1 – MPSNR (Move PFCP Session due to SMF no responding) : if this bit is set to "1" , it indicates that the UP function moves the PFCP session due to the SMF not responding.

[0320] - Bit 2 – MPSHF (Move PFCP Session due to SMF Heartbeat Failure) : if this bit is set to "1" , it indicates that the UP function moves the PFCP session due to the SMF heartbeat failure.

[0321] - Bit 3 – MPSAI (Move PFCP Session As Instructed) : if this bit is set to "1" , it indicates that the UP function moves the PFCP session as instructed by the SMF in a PFCP Session Set Modification Request.

[0322] - Bit 4 to 8 – Spare, for future use, shall be set to "0" by the sender and discarded by the receiver.

[0323] ***End of Changes ***

[0324] It will be recognized that principles of the disclosure are not limited to the embodiments so described, but instead can be practiced with modification and alteration without departing from the scope of the appended claims. The above embodiments may include the undertaking only a subset of such features, undertaking a different order of such features, undertaking a different combination of such features, and / or undertaking additional features than those features explicitly listed. The scope of the embodiments should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

Claims

1.A method (400) performed by a first network node (101) implementing a user plane function, comprising:- determining (S401) that a session between the first network node (101) and a second network node (102) implementing a first control plane function in a network function set is to be moved from the second network node (102) to a third network node (103, 104) implementing a second control plane function in the network function set; and- sending (S402) a session report request message to the third network node (103, 104) proactively or reactively, wherein the session report request message indicates moving the session to the third network node (103, 104) .2.The method (400) according to claim 1, wherein determining (S401) that the session is to be moved from the second network node (102) to the third network node (103, 104) comprises: determining (S401) that the session is to be moved from the second network node (102) to the third network node (103, 104) whendetecting that the second network node (102) is not responsive;detecting a failure of the second network node (102) ; orbeing instructed by a network node (102, 103, 104) implementing a control plane function in the network function set to move the session.3.The method (400) according to claim 1 or 2, wherein the session report request message comprises first information indicating a reason for the first network node (101) to send the session report request message.4.The method (400) according to claim 3, wherein the first information indicates at least one of following reasons:that the first network node (101) moves the session due to the second network node (102) not responding;that the first network node (101) moves the session due to the second network node (102) failure; orthat the first network node (101) moves the session as instructed by a network node (102, 103, 104) implementing a control plane function in the network function set to move the session.5.The method (400) according to claim 3 or 4, wherein the session report request message is a Packet Forward Control Protocol (PFCP) session report request (PFCPSRReq) message;the first information is presented by an information element PFCPSRReq-Flags and each of the reasons is presented by a bit of the information element PFCPSRReq-Flags respectively; orthe first information is presented by a first additional information element (Session Management Function, SMF, Change Indication) and each of the reasons is presented by the first additional information element respectively.6.The method (400) according to any one of claim 1 to 5, wherein the session report request message comprises second information indicating at least one report type respectively of at least one report included in the session report request message.7.The method (400) according to claim 6,wherein the report type indicated by the second information is one of: a Downlink Data Report (DLDR) type, a Usage Report (USAR) type, an Error Indication Report (ERIR) type, a User Plane Inactivity Report (UPIR) type, a Time Sensitive Communication (TSC) Management Information Report (TMIR) type, a Session Report (SESR) type, and a UP Initiated Session Request (UISR) type;wherein the report type indicated by the second information is a first additional type (SMF Change Report) ; orwherein the report type indicated by the second information is a second additional type (Pending Payload Packet to Control Plane Function Report) .8.The method (400) according to any one of claims 1 to 7, wherein the session report request message is sent proactively when there is no report to be sent to the third network node (103, 104) in the session report request message.9.The method (400) according to claim 8 , wherein the first network node (101) controls a pace for sending the session report request message.10.The method (400) according to any one of claims 1 to 7 , wherein the session report request message is sent reactively whenthere is a report to be sent to the third network node (103, 104) in the session report request message; orthere is at least one pending payload packet for the session to be sent to a control plane function in a user plane tunnel.11.The method (400) according to claim 10, wherein the session report request message comprises a fourth indicator indicating that there is at least one pending payload packet for the session to be sent.12.[Corrected under Rule 26, 28.01.2026]The method (400) according to claim 11, wherein the session report request message is a PFCP session request message,the fourth indicator is included in third information in the session report request message, the third information is presented by an information element PFCPSRReq-Flags and the fourth indicator is presented by a bit of the information element PFCPSRReq-Flags.13.The method (400) according to claim 12, wherein the second information indicates a UISR type.14.The method (400) according to any one of claims 10 to 13, further comprising:- receiving (S403) , from the third network node (103, 104) , a session report response message, wherein the session report response message comprises fourth information indicating an identifier of the user plane tunnel at the third network node (103, 104) .15.The method (400) according to claim 14, wherein the identifier of the user plane tunnel at the third network node (103, 104) is a Full Qualified Tunnel Endpoint Identifier (F-TEID) .16.The method (400) according to any one of claims 1 to 15, whereinthe user plane function comprises a User Plane Function (UPF) , or the first network node comprises Packet Data Network Gateway-User Plane (PGW-U) or Serving GateWay-User Plane (SGW-U) ; and / orthe first control plane function and the second control plane function comprise a Session Management Function (SMF) , or the second network node and the third network node comprise Packet Data Network Gateway-Control Plane (PGW-C) , Serving GateWay-Control Plane (SGW-C) , or combined SMF, PGW-C, SGW-C.17.A method (500) performed by a third network node (103, 104) implementing a second control plane function in a network function set, comprising:-receiving (S501) a session report request message from a first network node (101) implementing a user plane function, wherein the session report request message indicates moving a session between the first network node (101) and a second network node (102) implementing a first control plane function in the network function set from the second network node (102) to a third network node (103, 104) implementing a second control plane function in the network function set;wherein the session report request message is sent proactively or reactively.18.The method (500) according to claim 17, wherein the session is to be moved from the second network node (102) to the third network node (103, 104) because:the second network node (102) is not responsive;there is a failure in the second network node (102) ; orthe first network node (101) is instructed by a network node (102, 103, 104) implementing a control plane function in the network function set to move the session.19.The method (500) according to claim 17 or 18, wherein the session report request message comprises first information indicating a reason for the first network node (101) to send the session report request message.20.The method (500) according to claim 19, wherein the first information indicates at least one of following reasons:that the first network node (101) moves the session due to the second network node (102) not responding;that the first network node (101) moves the session due to the second network node (102) failure; andthat the first network node (101) moves the session as instructed by a network node (102, 103, 104) implementing a control plane function in the network function set to move the session.21.The method (500) according to claim 19 or 20, wherein the session report request message is a Packet Forward Control Protocol (PFCP) session report request (PFCPSRReq) message;the first information is presented by an information element PFCPSRReq-Flags and each of the reasons is presented by a bit of the information element PFCPSRReq-Flags respectively; orthe first information is presented by a first additional information element (Session Management Function, SMF, Change Indication) and each of the reasons is presented by the first additional information element respectively.22.The method (500) according to any one of claim 17 to 21, wherein the session report request message comprises second information indicating at least one report type of respectively of at least one report included in the session report request message.23.The method (500) according to claim 22,wherein the report type indicated by the second information is one of: a Downlink Data Report (DLDR) type, a Usage Report (USAR) type, an Error Indication Report (ERIR) type, a User Plane Inactivity Report (UPIR) type, a Time Sensitive Communication (TSC) Management Information Report (TMIR) type, a Session Report (SESR) type, and a UP Initiated Session Request (UISR) type;wherein the report type indicated by the second information is a first additional type (SMF Change Report) ; orwherein the report type indicated by the second information is a second additional type (Pending Payload Packet to Control Plane Function Report) .24.The method (500) according to any one of claims 18 to 25, wherein the session report request message is sent proactively when there is no report to be sent to the third network node (103, 104) in the session report request message.25.The method (500) according to any one of claims 17 to 23, wherein the session report request message is sent reactively whenthere is a report to be sent to the third network node (103, 104) in the session report request message; orthere is at least one pending payload packet for the session to be sent to a control plane function in a user plane tunnel.26.The method (500) according to claim 25, wherein the session report request message comprises a fourth indicator indicating that there is at least one pending payload packet for the session to be sent.27.The method (500) according to claim 26, wherein the session report request message is a PFCP session request message,the fourth indicator is included in third information in the session report request message, the third information is presented by an information element PFCPSRReq-Flags and the fourth indicator is presented by a bit of the information element PFCPSRReq-Flags.28.The method (500) according to claim 27, wherein the second information indicates a UISR type.29.The method (500) according to any one of claims 25 to 28, further comprising:-sending (S502) , to the first network node (101) , a session report response message, wherein the session report response message comprises fourth information indicating an identifier of the user plane tunnel at the third network node (103, 104) .30.The method (500) according to claim 29, wherein the identifier of the user plane tunnel at the third network node (103, 104) is a Full Qualified Tunnel Endpoint Identifier (F-TEID) .31.The method (500) according to any one of claims 17 to 30, whereinthe user plane function comprises a User Plane Function (UPF) , or the first network node comprises Packet Data Network Gateway-User Plane (PGW-U) or Serving GateWay-User Plane (SGW-U) ; and / orthe first control plane function and the second control plane function comprise a Session Management Function (SMF) , or the second network node and the third network node comprise Packet Data Network Gateway-Control Plane (PGW-C) or Serving GateWay-Control Plane (SGW-C) , or combined SMF, PGW-C, SGW-C.32.A first network node (101, 600) , comprising:- processing circuitry (601) ; and- a memory (602) ;the processing circuitry (601) is configured to perform the method (400) according to any one of claims 1 to 16.33.A third network node (103, 104, 700) , comprising:- processing circuitry (701) ; and- a memory (702) ;the processing circuitry (701) is configured to perform the method (500) according to any one of claims 17 to 31.34.A communication system (900) , comprising:-  a first network node (101, 600) , comprising:processing circuitry (601) ;a memory (602) ;the processing circuitry (601) is configured to perform the method (400) according to any one of claims 1 to 16; and- a third network node (103, 104, 700) , comprising:processing circuitry (701) ;a memory (702) ;the processing circuitry (701) is configured to perform the method (500) according to any one of claims 17 to 31.35.The communication system (900) according to claim 34, further comprising:- a second network node (102) implementing a first control plane function in a network function set.36.A computer readable medium (802) comprising instructions that, when executed by a network node (800) , cause the network node (800) to perform the method (400, 500) according to any one of claims 1-31.37.A computer readable product (804) instructions that, when executed by a network node (800) , cause the network node (800) to perform the method (400, 500) according to any one of claims 1-31.

Images