Patent Description:
The fifth generation of mobile technology (<NUM>) is positioned to provide a much wider range of services than are provided by the existing third generation (<NUM>) or fourth generation (<NUM>) technologies. <NUM> is expected to enable a fully connected society, in which a rich set of Use Cases - some of them are still not yet conceptualized - will be supported from the Enhanced Mobile Broadband (EMBB) through media distribution and Machine Type Communication (MTC), such as via Massive MTC (M-MTC) to Mission Critical Services, Critical MTC (C-MTC).

The C-MTC Use Case group covers a big set of applications, but most of them can be characterized by low latency and high reliability, as well as high availability. It should be mentioned that although low latency is an important criterion in numerous Use Cases, high reliability is expected to be a basic requirement in much wider range of services. For example, low latency and high reliability are very important factors in Industry (Factory) Automation Use Cases (e.g., high speed motion control, packaging, printing, etc.), and for several special subtasks of the Smart Grid service. In the above use cases, guarantees on latency and reliability requirements together provide sufficient service quality.

High reliability is also important in such use cases where there are relaxed requirements on latency (e.g., where higher delay and/or higher jitter can be tolerated). Illustrative examples include, but are not limited to, Intelligent Traffic Systems (ITS), remote control with or without haptic feedback, robotized manufacturing, Smart Grid functions, Automated Guided Vehicles (AGVs), drone controlling, tele-surgery, etc. In these cases, extreme low latency is not the crucial factor, but a high reliability (and in some cases, extremely high reliability) of the connectivity between the application server and the C-MTC device is the most important requirement. In short, while reliability is a very important requirement in many use cases that have a low latency requirement, reliability in itself could be a basic characteristic of C-MTC services.

The Time-Sensitive Networking (TSN) Task Group of Institute of Electrical and Electronic Engineers (IEEE) <NUM> provides a standardized solution to satisfy low latency and high reliability requirements in fixed Ethernet networks. The Internet Engineering Task Force (IETF) DetNet activity extends the solution to layer <NUM> networks.

<FIG> illustrates the reliability solution provided by TSN/DetNet. A replication entity N1 creates a replica of each Ethernet frame / Internet Protocol (IP) packet, and assigns a sequence number to it. An elimination entity N2 uses the sequence number to find duplicates of the same frame/packet, so that only a single copy of a given frame/packet is forwarded onwards. The Frame/Packet Replication and Elimination for Reliability (FRER/PREF) function may be applied between intermediate switches, or between the end devices themselves. The paths taken by the replicated frames are configured to be disjoint, so that a fault on one path does not affect the other path.

There is a demand for a similar type of reliability approach for <NUM> (or even <NUM>/LTE) networks. One approach is shown in <FIG>.

<FIG> illustrates a conventional reliability approach based on the Dual Connectivity (DC) feature of <NUM> or <NUM>/LTE. Dual connectivity allows a single User Equipment (UE) that is suitably equipped with two transceivers to have User Plane (UP) connectivity with two base stations, such as New Radio Base Stations (gNBs), shown as a Master gNB (MgNB) and a Secondary gNB (SgNB), while it is connected only to a single base station (e.g., MgNB) in the Control Plane (CP). Third Generation Partnership Project (3GPP) Technical Specifications (TS) <NUM>, TS <NUM>, and TS <NUM> include more details on dual connectivity in <NUM>/LTE and <NUM>.

The use of dual connectivity for redundant data transmission is described in commonly owned or assigned International Publication Number WO <NUM>/<NUM>, entitled "METHODS PROVIDING DUAL CONNECTIVITY FOR REDUNDANT USER PLANE PATHS AND RELATED NETWORK NODES. " In that case, the UE establishes two Protocol Data Unit (PDU) sessions, such that the Core Network (CN) selects separate User Plane Function (UPF) entities, and the CN also requests the Radio Access Network (RAN) to establish dual connectivity.

<FIG> illustrates another conventional reliability approach, which is to equip the terminal device with multiple physical UEs. It is then possible to set up disjoint paths with disjoint PDU-sessions from these UEs. The solution described in commonly owned or assigned International Publication Number <CIT>, entitled "INDUSTRY AUTOMATION APPARATUS WITH REDUNDANT CONNECTIVITY TO A COMMUNICATION NETWORK AND CONTROLLERS THEREFOR," presents a way to select different RAN entities for the UEs based on a static grouping. The solution is illustrated in <FIG>, where the device is equipped with separate UEs, UE1 and UE2, and the network provides redundant coverage with RAN entities gNB1 and gNB2 that are preferably selected such that UE1 connects to gNB1, and UE2 connects to gNB2.

In the case of redundant paths, mobility handling requires special attention. In commonly owned or assigned International Publication Number <CIT>, entitled "METHODS AND APPARATUS FOR HANDOVER CONTROL OF AFFILIATED COMMUNICATION MODULES IN A WIRELESS COMMUNICATION NETWORK," a solution is given for avoiding simultaneous handovers in the case of multiple UEs per device. The handover is a volatile process, when interruption or failure may take place. Hence, it is useful to co-ordinate the RAN handovers for the gNBs in the two paths, so that at least one path is always available. The solution in <CIT> introduces a locking mechanism such that in the case of handover, the other path defers handovers if possible. However, since a handover usually does not involve a change of a PDU Session Anchor (PSA), <CIT> does not address this issue.

Besides the RAN handovers, mobility may also take place in the core network when the PDU Session Anchor (PSA) is relocated. Such an anchor change can take place when the UE has moved away from its original location and it is determined in the core network that a change of the PSA is beneficial, e.g., for reducing the end-to-end latency. There are several ways to execute an anchor change: 3GPP TS <NUM> section <NUM>. <NUM> defined procedures for Session and Service Continuity (SSC) mode <NUM> when the old PDU session is released before a new PDU session is established and for SSC mode <NUM> when the new PDU session is established before the old PDU session is released. Additionally, the solution in commonly owned or assigned International Patent Application Serial Number <CIT>, proposes a way for Ethernet PDU Sessions to change the anchor (PSA) of an existing session without the need to establish a new session. However, that solution does not address the particular problems that arise where there are redundant user plane paths.

In the case of mobility with change of the anchor point with redundant user plane paths, disruptions may occur due to the anchor point change. The disruption may be a result of the anchor point change itself, or may be due to the fact that a change of the anchor point can lead to the need to configure a new end-to-end path. Due to the risk of disruptions following an anchor point change it is beneficial to make sure that anchor point changes on the different paths are coordinated in time, in order to avoid simultaneous anchor point changes on multiple paths. Due to redundancy, if the anchor changes are not simultaneous, disruptions can be avoided. However, if the anchor changes happen at the same time on both paths, the disruption can be significant. Currently there is no way to avoid such simultaneous anchor changes.

The publication "3rd Generation Partnership Project; Study on enhancement of Ultra-Reliable Low-Latency Communication (URLLC) support in the <NUM> Core network (5GC) (Release <NUM>)" discloses a study and performs an evaluation of potential architecture enhancements for supporting URLLC services in <NUM> System (5GS).

The publication "3rd Generation Partnership Project; Procedures for the <NUM> System; Stage <NUM> (Release <NUM>)" discloses and defines the Stage <NUM> procedures and Network Function Services for the <NUM> system architecture.

The invention is defined by the independent claims and embodiments are defined in the dependent claims. The present disclosure provides for coordination of the PSA change in the case of redundant PDU Sessions. The solution provides coordination in order to avoid a situation where the PSA of the redundant PDU Sessions are changed simultaneously. This is avoided by a locking database which prevents PSA change for the other PDU Session once a PSA change is in progress. The locking database may be implemented as a central function, or distributed in the core network, or realized in RAN. The solution with locking realized in RAN can provide not only coordination between PSA changes of the two sessions, but also between PSA change and handover in RAN; thereby achieving full coordination for redundant sessions to avoid any disruption at mobility.

According to some embodiments, a method for coordinated change of PSAs comprises, at a node for maintaining PSA change status for PDU sessions, receiving a request for a PSA change or handover for a first PDU session having a first PSA, where the first PDU session and a second PDU session having a second PSA different from the first PSA are redundant PDU sessions with each other. If the second PDU session is undergoing a PSA change or handover, the request to change the first PDU session is denied; otherwise, the request to change the first PDU session is granted, and the second PDU session will not be allowed to be changed until the change to the first PDU session is complete.

According to one aspect of the present disclosure, a method for coordinated change of Protocol Data Unit (PDU) Session Anchors (PSAs) comprises: at a node for maintaining PSA change status for PDU sessions: receiving a request for a PSA change for a first PDU session having a first PSA, where the first PDU session and a second PDU session are redundant PDU sessions with each other; determining whether the PSA change for the first PDU session is temporarily prohibited; upon determining that the PSA change for the first PDU session is temporarily prohibited, denying the request for the PSA change for the first PDU session; and upon determining that the PSA change for the first PDU session is not temporarily prohibited: granting the request for the PSA change for the first PDU session; setting a PSA change status associated with the first PDU session to indicate that the PSA change for the first PDU session is temporarily prohibited; subsequently receiving an indication that the PSA change for the first PDU session is completed; and setting the PSA change status associated with the first PDU session to indicate that the PSA change for the first PDU session is allowed, wherein determining that the PSA change for the first PDU session is temporarily prohibited comprises at least one of: determining that the first PDU session is currently undergoing a handover; determining that the second PDU session is currently undergoing a handover; and determining that the second PDU session is currently undergoing a PSA change.

In some embodiments, the PSA change status associated with the first PDU session is also associated with the second PDU session.

In some embodiments, setting the PSA change status associated with the first PDU session to indicate that the PSA change for the first PDU session is temporarily prohibited further comprises setting a PSA change status associated with the second PDU session to indicate that a PSA change for the second PDU session is temporarily prohibited, and setting the PSA change status associated with the first PDU session to indicate that the PSA change for the first PDU session is allowed further comprises setting the PSA change status associated with the second PDU session to indicate that the PSA change for the second PDU session is allowed.

In some embodiments, the node for maintaining PSA change status for PDU sessions comprises a synchronization database function for maintaining PSA change status variables that indicate PSA change status for PDU sessions.

According to another aspect of the present disclosure, a method for coordinated change of PSAs comprises: at a first node being associated with a first PDU session: receiving, from a requesting entity, a request for a PSA change for the first PDU session, where the first PDU session and a second PDU session are redundant PDU sessions with each other; determining whether the PSA change for the first PDU session is temporarily prohibited; upon a determination that the PSA change for the first PDU session is temporarily prohibited: denying the request for the PSA change for the first PDU session; and subsequently determining that the PSA change for the first PDU session is allowed; and upon a determination that the PSA change for the first PDU session is not temporarily prohibited: granting the request for the PSA change for the first PDU session; setting a PSA change status associated with the first PDU session to indicate that the PSA change is temporarily prohibited; subsequently receiving an indication that the PSA change for the first PDU session is completed; and setting the PSA change status associated with the first PDU session to indicate that the PSA change is allowed, wherein determining that the PSA change for the first PDU session is temporarily prohibited comprises at least one of: determining that the first PDU session is currently undergoing a handover; determining that the second PDU session is currently undergoing a handover; and determining that the second PDU session is currently undergoing a PSA change.

In some embodiments, the method further comprises, subsequent to denying the request for the PSA change for the first PDU session: determining that the PSA change for the first PDU session is allowed; and setting the PSA change status associated with the first PDU session to indicate that the PSA change is allowed.

In some embodiments, the method further comprises notifying the requesting entity that the PSA change for the first PDU session is now allowed.

In some embodiments, the node for maintaining PSA change status receives a request from the requesting entity that comprises a Session Management Function (SMF) associated with the PSA being changed.

In some embodiments, the first node being associated with the first PDU session comprises a Radio Access Network (RAN) node.

In some embodiments, the RAN node comprises a New Radio Base Station (gNB).

In some embodiments, the second node being associated with the second PDU session comprises a RAN node.

In some embodiments, the RAN node comprises a gNB.

According to another aspect of the present disclosure, a method for coordinated change of PSAs comprises: at a SMF node: determining that a PSA change is needed for a first PDU session having a first PSA, where the first PDU session and a second PDU session are redundant PDU sessions with each other; sending, to a node for maintaining PSA change status for PDU sessions, a request for the PSA change for the first PDU session; receiving, from the node for maintaining PSA change status for PDU sessions, a response to the request for the PSA change for the first PDU session, and if the response to the request for the PSA change for the first PDU session indicates that the PSA change is allowed, initiating the PSA change for the first PDU session; and if the response to the request for the PSA change for the first PDU session indicates that the PSA change is temporarily prohibited, not initiating the PSA change for the first PDU session.

In some embodiments, if the response to the request for the PSA change for the first PDU session indicates that the PSA change is temporarily prohibited, the process further comprises: receiving a notification that the temporarily prohibited PSA change is now allowed; and resending the request for the PSA change for the first PDU session to the node for maintaining PSA change status for PDU sessions.

In some embodiments, sending the request for the PSA change for the first PDU session to the node for maintaining PSA change status for PDU sessions comprises sending the request to a core network node.

In some embodiments, sending the request for the PSA change for the first PDU session to the node for maintaining PSA change status for PDU sessions comprises sending the request to a RAN node.

In some embodiments, sending the request to the RAN node comprises sending the request to a gNB.

According to another aspect of the present disclosure, a method for coordinated change of PSAs comprises: at a first node being associated with a first PDU session: determining that a handover is needed for the first PDU session having a first PSA, where the first PDU session and a second PDU session are redundant PDU sessions with each other; determining whether the handover for the first PDU session is temporarily prohibited; upon a determination that the handover for the first PDU session is temporarily prohibited, postponing the handover for the first PDU session; and upon a determination that the handover for the first PDU session is not temporarily prohibited: setting the change status associated with the first PDU session to indicate that a PSA change or handover for the first PDU session is temporarily prohibited; performing the handover for the second PDU session; and setting the change status associated with the first PDU session to indicate that a PSA change or handover is allowed, wherein determining that a PSA change or handover for the first PDU session is temporarily prohibited comprises at least one of: determining that the first PDU session is currently undergoing a PSA change; determining that the second PDU session is currently undergoing a PSA change; and determining that the second PDU session is currently undergoing a handover.

In some embodiments, the first node being associated with the first PDU session comprises a RAN node.

In some embodiments, a second node being associated with the second PDU session comprises a RAN node.

According to another aspect of the present disclosure, a network node for coordinated change of PSAs comprises processing circuitry that performs any of the methods disclosed herein.

In some embodiments, the network node comprises a core network node.

In some embodiments, the network node comprises a SMF.

In some embodiments, the network node comprises a RAN node.

In some embodiments, the network node comprises a gNB.

Core Network Node: As used herein, a "core network node" is any type of node in a core network or any node that implements a core network function. Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (PGW), a Service Capability Exposure Function (SCEF), a Home Subscriber Server (HSS), or the like. Some other examples of a core network node include a node implementing a Access and Mobility Function (AMF), a UPF, a Session Management Function (SMF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Function (NF) Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), or the like.

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

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

Seen from the access side the <NUM> network architecture shown in <FIG> comprises a plurality of User Equipment (UEs) connected to either a Radio Access Network (RAN) or an Access Network (AN) as well as an Access and Mobility Management Function (AMF). Typically, the (R)AN comprises base stations, e.g., such as evolved Node Bs (eNBs) or NR base stations (gNBs) or similar. Seen from the core network side, the <NUM> core NFs shown in <FIG> include a Network Slice Selection Function (NSSF), an Authentication Server Function (AUSF), a Unified Data Management (UDM), an AMF, a Session Management Function (SMF), a Policy Control Function (PCF), and an Application Function (AF).

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

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

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

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

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

<FIG> illustrates an exemplary system for providing coordinated change of PDU session anchors according to some embodiments of the present disclosure. <FIG> illustrates coordination for a PSA change in case where there are redundant PDU Sessions and a User Equipment (UE) or other terminal device (which, for brevity, may be referred to as "the UE" or "the device") moves from a first mobility configuration to a second mobility configuration, e.g., when a UE moves from a first location to a second location.

In the embodiment illustrated in <FIG>, before the move the UE has two redundant PDU Sessions to the DN (Data Network) with User Plane Functions UPF1 and UPF2 acting as the PSAs, controlled by Session Management Functions SMF1 and SMF2, respectively. In the embodiment illustrated in <FIG>, PDU session <NUM> connects the UE to the DN via UPF1, and PDU session <NUM> connects the UE to the DN via UPF2. After the UE moves from the first location to the second location, the anchors are changed to User Plane Functions UPF1' and UPF2', controlled by Session Management Functions SMF1' and SMF2', respectively. In the embodiment illustrated in <FIG>, PDU session <NUM>' connects the UE to the DN via UPF1' and PDU Session <NUM>' connects the UE to the DN via UPF2'.

The systems and methods of the present disclosure provide coordination in order to avoid changing UPF1 to UPF1' (and the associated configuration changes) at the same time as changing UPF2 to UPF2' (and the associated configuration changes). In some embodiments of the present disclosure, this is achieved by a locking database that facilitates the coordination of the PSA change processes with the respective SMF entities. In the embodiment illustrated in <FIG>, the locking database is implemented in the logical "Synch DB" function. In some embodiments, the PDU Sessions can be correlated in the Synch DB function by a set of identifiers, such as the combination of SUPI, DNN and S-NSSAI, which are provided to the Synch DB function.

In some embodiments, there will be some a priori information which determines which PDU sessions are related. For example, the combination of DNN and S-NSSAI parameters could be used to determine the pairing. In some embodiments, other or additional information, such as subscription, local configuration, or other information, may be used to determine which PDU sessions are related. In some embodiments, the Synch DB uses some or all of these parameters or other parameters to determine which PDU sessions are paired.

In some embodiments, before starting a PSA change on a first path, a control plane entity indicates the intention to perform the PSA change and checks whether a PSA change is in progress for one of the other paths. If a PSA change is in progress for one of the other paths, the PSA change for the first path is postponed. The PSA change is executed only when the ongoing PSA change on another path and related other actions (such as reconfiguration of the end-to-end user plane paths) are completed.

It is noted that, depending on the realization of the anchor change, the SMFs may or may not change during anchor change. In <FIG>, for example, it is possible that SMF1 and SMF1' coincide, and it is possible that SMF2 and SMF2' coincide. Moreover, the two SMFs handling the UPFs may or may not be the same, e.g., it is possible that SMF1 and SMF2 coincide, and similarly it is possible that SMF1' and SMF2' coincide.

In some embodiments, the Synch DB is a logical function, which may be a separate, centralized function, or it may be a distributed database. In some embodiments, the Synch DB may be co-located with other entities. For example, in some embodiments, the Synch DB may be integrated into the SMF entities or into the AMF entities.

In some embodiments, the two redundant PDU Sessions from the device may be realized either using two UEs integrated within the device, or using a single UE and relying on RAN dual connectivity feature.

<FIG> and <FIG> are signaling graphs showing messages exchanged during an exemplary process for coordinated change of PDU session anchors according to some embodiments of the present disclosure. <FIG> and <FIG> are signaling charts involving SMF entities that are responsible for executing the anchor change processes and a common Synch DB (database) that is implementing a locking function to avoid simultaneous anchor change. The process begins on <FIG> and continues on <FIG>.

In the embodiment illustrated in <FIG>, the process includes the steps detailed below.

Step <NUM>. A first SMF (SMF1) determines the need for an anchor change of PDU session <NUM>, which in this example is associated with a wireless device. As used hereinafter, the terms "UE," "device," and "wireless device" may be used interchangeably.

Step <NUM>. Before starting the process of the anchor change, SMF1 sends a PSA anchor change request to a node for maintaining PSA change status, which in the embodiment illustrated in <FIG> and <FIG> is labeled "Synch DB.

Step <NUM>. The Synch DB checks the PSA change status and determines that a PSA change is not locked, i.e., that a PSA change is not currently in progress. In some embodiments, checking the PSA change status comprises determining whether the PDU session that is the subject of the PSA change request and another PDU session are redundant PDU sessions with each other (which may also be referred to as being disjoint paths), and determining whether that second PDU session is currently undergoing a PSA change. Likewise, checking the PSA change status may comprise determining whether the PDU session that is the subject of the change request is currently undergoing a PSA change. If a PDU session is currently undergoing a PSA change, that may be noted in some manner, e.g., by setting a flag or entry in a database, or other technique. When a PDU session is currently undergoing a PSA change, the redundant PDU sessions will be temporarily blocked or prevented from also undergoing a PSA change; this may be referred to herein as being "blocked," "locked," or being subject to a "PSA change lock.

Step <NUM>. The Synch DB allows the anchor change by responding with a PSA change OK message. In the embodiment illustrated in <FIG>, a PSA change is possible at this point in the process because there is no other PSA change in progress for the other session of the device involving the disjoint path.

Step <NUM>. The Synch DB sets the PSA change status to "blocked," to temporarily prohibit additional PSA changes to any of the redundant PDU sessions.

In some embodiments, the Synch DB may associate the blocked status with just the PDU session being changed (e.g., PDU session <NUM>), and if a PSA change request for PDU session <NUM> is received, the Synch DB first determines that PDU session <NUM> is redundant with PDU session <NUM>, then checks the PSA status PDU session <NUM> to determine if the PSA for PDU session <NUM> may be changed. When the PSA change for PDU session <NUM> is complete, the Synch DB will change the PSA change status for just PDU session <NUM>.

In alternative embodiments, the Synch DB may associate the blocked status not with the PDU session being changed but to all of the PDU sessions that are redundant sessions with the PDU session being changed. For example, while PDU session <NUM> is undergoing a PSA change, the Synch DB may put a lock on PDU session <NUM>. In this embodiment, if a PSA change request for PDU session <NUM> is received, the Synch DB may check the PSA change status of PDU session <NUM> directly. When the PSA change for PDU session <NUM> is complete, the Synch DB will adjust the PSA change status for all of the other redundant PDU sessions, such as PDU session <NUM> in this example.

In other alternative embodiments, the Synch DB may associate the blocked status not only with the PDU session undergoing a PSA change but may also set the PSA change status of all of the redundant sessions as blocked. When the PSA change for one of the PDU sessions is complete, the Synch DB will adjust the PSA change status for all of the redundant PDU sessions, including the PDU session that just completed the PSA change.

In still other alternative embodiments, the Synch DB associates a blocked status with a variable that represents the collection of redundant PDU sessions, rather than any particular PDU session. In these embodiments, specific PDU sessions, such as PDU session <NUM> and PDU session <NUM> in <FIG> and <FIG>, are associated with that variable. In these embodiments, the Synch DB need only maintain information indicating whether or not there is an ongoing PSA change without being specific about which of the redundant PDU sessions in particular is undergoing that PSA change.

Finally, it is noted that where the redundant PDU sessions are associated with one particular UE, the PSA change lock may be thought of as applying to that particular UE in general. In such a scenario it may also be said that the particular UE (rather than a specific PDU session) is subject to the PSA change lock.

It is noted that steps <NUM> and <NUM> can be in any order.

Step <NUM>. SMF1 starts the PSA change process.

Step <NUM>. The session via UPF1, called PDU session <NUM>, is released.

Step <NUM>. A request arrives to the Synch DB to perform another PSA change.

Step <NUM>. The Synch DB checks the PSA change status and determines that a PSA change lock is in place.

Step <NUM>. That request is rejected due to the ongoing PSA change. However, in some embodiments, the Synch DB may remember the request, so that it can notify the requestor once the PSA change becomes possible.

As part of the PSA change process, the SMF entity may in certain cases change. In the example shown in <FIG>, the SMF entity changes from SMF1 to SMF1'. However, as will be discussed in more detail below, such change does not necessarily occur in all cases.

Step <NUM>. SMF1' establishes the user plane of the PDU Session via a new UPF, UPF1', which has been changed compared to UPF1. This PDU session is referred to as PDU Session <NUM>'.

Step <NUM>. The PSA change process ends for the first PDU session. (Note that the figure here does not show all the messaging that may take place with a PSA anchor change).

Step <NUM>. The end of the PSA change is indicated to the Synch DB. (This may also indicate the change of the SMF when necessary.

Step <NUM>. The Synch DB releases the lock on the PSA change for the given device, e.g., by setting the PSA change status to "allowed.

Step <NUM>. The Synch DB may optionally send a notification to SMF2 that the lock has been released. (If the system does not provide such a notification, then SMF2 would need to repeatedly try to request a PSA change until it becomes available).

The process continues in <FIG>. In the embodiment illustrated in <FIG>, the process includes the steps detailed below.

Step <NUM>. SMF2 again requests a PSA change. This request can now succeed given that there is no longer a parallel PSA change in progress.

Step <NUM>. The Synch DB checks the PSA change status and determines that a PSA change for PDU session <NUM> is allowed.

Step <NUM>. The Synch DB allows the anchor change by responding with a PSA change OK message. The PSA change process can now start for the second PDU session ("PDU session <NUM>").

Step <NUM>. A lock is placed for PSA change for the given device in the Synch DB.

It is noted that steps <NUM> and <NUM> can be performed in any order.

Step <NUM>. SMF2 begins the PSA change process.

Step <NUM>. As part of the PSA change, the user plane via UPF2 is released. In the embodiment illustrated in <FIG>, the SMF2 function changes to SMF2' during the PSA change process, even though such a change is not always necessary.

Step <NUM>. SMF2' creates the user plane session via UPF2', which is the new PSA that has been changed from UPF2. This PDU session is called PDU session <NUM>'.

Step <NUM>. The PSA change process for the second PDU session ends.

Step <NUM>. The end of the PSA change is signaled to the Synch DB.

Step <NUM>. The Synch DB then releases the lock, e.g., by setting the PSA change status to "allowed.

Different types of PSA changes can be possible. The present disclosure describes four alternatives.

Alternative <NUM>. One possibility is described in International Patent Application Serial Number <CIT>, for Ethernet PDU Sessions, where the PSA of an existing PDU Session is changed. In that case, the SMF remains unchanged, and the PSA can be changed without releasing or reestablishing the session.

Alternative <NUM>. A second possibility is the SSC mode <NUM> PSA change as described in 3GPP TS <NUM> section <NUM>. In that case, the PDU Session is first released with a cause code to the UE that indicates the requirement to re-establish a new PDU session.

Alternative <NUM>. A third possibility is the SSC mode <NUM> PSA change as described in 3GPP TS <NUM> section <NUM>. In that case, a new PDU Session is established first based on a network indication that a new PDU Session to the same data network is needed. Once the new PDU session is established and the data flows are transferred to the new PDU session, the old PDU session is released.

Alternative <NUM>. A fourth possibility is the SSC mode <NUM> PSA change with an IPv6 multi-homed session as described in 3GPP TS <NUM> section <NUM>. In that case, a new PDU Session anchor is established first, together with a user plane branching point. The new IPv6 address is provided to the terminal. Once the data flows use the new address via the new anchor point, the old anchor can be released (together with the branching point).

In the case of alternative <NUM> and alternative <NUM>, the SMF remains unchanged in the process. Hence, it does not pose any problem for the SMF to notify the central database about the end of the PSA change process. However, in the case of alternative <NUM> and alternative <NUM>, the SMF changes as part of the anchor change, and the new SMF may not know whether the established PDU Session was due to a PSA change. Therefore, additional mechanisms are needed to trigger the new SMF to indicate to the Synch DB when the PSA change has ended. Several options are possible for this.

In some embodiments, redundant sessions use a specific DNN. When a new PDU Session has been established to a given DNN, it is indicated to the Synch DB, and the corresponding lock is released. Note that in this case it is possible that an indication is sent to the Synch DB even when there has been no anchor change, e.g., when the PDU session is initially established. In that case there was no lock originally, so nothing needs to be released, so this does not cause a problem.

In some embodiments, redundant session use a specific combination of DNN and S-NSSAI (slice id); or just a specific S-NSSAI, and similarly as above, indicate to the Synch DB when a new PDU session has been established in the case of a given set of DNN, S-NSSAI combinations.

In some embodiments, besides the existing session ID, the terminal also assigns a new session identifier to the sessions, called here SSN for Session Sequence Number. The SSN is assigned by the UE in such a way that it remains the same as for the old session in the case of Alternative <NUM> and <NUM> when a new session is established due to PSA change, otherwise the SSN is changed. For example, in the case of Alternative <NUM>, the same SSN is used for the new session as for the old session that was released and whose release triggered the new session. And in the case of Alternative <NUM>, the same SSN is used for the new session as for the old session that triggered the establishment of the new session. When a new session is established, the SSN is provided to the Synch DB; in the case of a lock corresponding to a given SSN of the UE, the lock can be released when the new session is established with the same SSN for the UE. (In the case of Alternative <NUM>, the old session may still exist when the new session is completed and the PSA change is regarded complete, however the existence of the old session this does not cause a problem if the new path is already operational.

In some embodiments, it can also be possible that the SSN is provided by the AMF rather than the UE. When the AMF detects that a PDU Session is released and soon (within a present time period) a new PDU session is established to the same DDN, the AMF may regard this to be a PSA change and assign the same SSN. Also, if the AMF detects that a new PDU session was triggered for SSC mode <NUM>, it may assign the same SSN for the new session as the triggering session.

Different options may be possible for realizing the logical Synch DB. In some embodiments, such as the one illustrated in <FIG> and <FIG>, the Synch DB may be realized as a centralized function. It could be a standalone entity, or it could be co-located with other entities such as the UDM, NRF or NEF.

In some embodiments, the Synch DB may be a distributed function that is realized by multiple entities. For example, the Synch DB is implemented at each SMF (or at each SMF of a given network domain). Each time there is a change, it is signaled to all other SMFs. The distributed function is realized by a distributed database which is able to act as a logically single entity. That is, the database can resolve conflicts that concern the same UE when multiple changes are pending.

In some embodiments, the Synch DB may also be realized in the RAN by signaling between the RAN nodes for the two PDU Sessions. This is elaborated in the next section below.

RAN based synchronization of the PSA change scheduling could be applied in cases when the two RAN nodes (such as gNBs) of the two PDU sessions are aware of each other. This is the case e.g., when dual connectivity based redundancy solution is applied, where one RAN node may be acting as a Master gNB and the other RAN node may be acting as a Secondary gNB, with Xn signaling connection between them. In the case of redundancy solution using multiple UEs, it might also be possible that the two gNBs where the UEs of the same device are connected are aware of each other, though this may not always be the case. For gNBs, there could be different cases. For example, where there is a single UE with dual connectivity, then the two gNBs already know each other, as they are for the same UE and they play the master and secondary gNB roles. On the other hand, where there are two different UEs, then some special identifier, such as a device id, may be used to pair the two gNBs and continuously update the mapping.

In this approach, it will become known to both gNBs that the PSA of one of the PDU sessions is being changed. While the change is taking place, a PSA change on another PDU session will be blocked. This approach is illustrated in <FIG> and <FIG>.

<FIG> and <FIG> are signaling graphs showing messages exchanged during an exemplary process for coordinated change of PDU session anchors according to some embodiments of the present disclosure. <FIG> and <FIG> are signaling charts involving SMF entities that are responsible for executing the anchor change processes and a distributed system for providing a locking function to avoid simultaneous anchor change. The process begins on <FIG> and continues on <FIG>.

In the embodiment illustrated in <FIG> and <FIG>, the process includes the steps detailed below.

Step <NUM>. A first SMF, SFM1, determines that a PSA is to be changed for a PDU Session, e.g., PDU session <NUM>, between a first gNB, gNB1, and a first UPF, UPF1. SMF1 therefore signals this request to gNB1.

Step <NUM>. gNB1 checks the PSA change status. In this example, PDU session <NUM> is not currently ongoing PSA change, and thus a PSA change for PDU session <NUM> is allowed. However, gNB1 knows that PDU session <NUM> is a redundant session with another PDU session, PDU session <NUM>, between a second gNB, gNB2, and a second UPF, UPF2. In the embodiment illustrated in <FIG> and <FIG>, gNB1 maintains the PSA change status for all related PDU sessions, e.g., gNB1 maintains the PSA change status for PDU session <NUM> and also for PDU session <NUM>, even though PDU session <NUM> is with gNB2, not gNB1. Thus, in some embodiments, gNB1 already knows the last reported PSA change status for PDU session2. Nevertheless, in order to avoid a race condition in which a request for a PSA change to PDU session <NUM> and a request for a PSA change to PDU session <NUM> occur simultaneously, in the embodiment illustrated in <FIG> and <FIG>, gNB1 notifies gNB2 that there has been a request to change the PSA for PDU session <NUM>, so that if there is also a pending request to change the PSA for PDU session <NUM>, gNB2 can warn gNB1 that there is a potential race condition so that gNB1 and gNB2 can negotiate which one of them gets to proceed with the PSA change and which one of them must wait.

Step <NUM>. Thus, in the embodiment illustrated in <FIG>, gNB1 forwards the request to gNB2. It should be noted that the message sent by gNB1 to gNB2 in step <NUM> is not requesting that gNB2 perform a PSA change, but is instead intended to notify gNB2 that a PSA change of PDU session <NUM> has been requested and is pending. Because the message in step <NUM> identifies PDU session <NUM> as the target of a potential PSA change, gNB2 will know which PDU session will be affected - something that is particularly useful in cases where more than two PDU sessions are redundant with each other. In alternative embodiments, the message in step <NUM> need not be a PSA change request but may instead be another form of notification message or even a query message (e.g., to ask whether PDU session <NUM> is currently undergoing a PSA change or not).

Step <NUM>. gNB2 checks the PSA change status. In this example, PDU session <NUM> is not currently undergoing a PSA change, and thus a PSA change for PDU session <NUM> is allowed. In alternative embodiments where, in step <NUM>, gNB1 asks gNB2 about the status of PDU session <NUM> specifically, gNB2 may report to gNB1 that a PSA change of PDU session <NUM> is allowed, in which case gNB1 may infer that a PSA change of PDU session <NUM> is therefore not blocked.

Step <NUM>. gNB2 notifies gNB1 that a PSA change for PDU session <NUM> is allowed, and so gNB1 can allow a PSA change for PDU session <NUM>. gNB1 therefore notifies SMF1 that the PSA change for PDU session1 is allowed. At this point, both gNB1 and gNB2 are now aware that the PSA of the PDU session <NUM> will be changed. It is noted that steps <NUM>, <NUM>, and <NUM> can be performed in any order.

Step <NUM>. Since PDU session <NUM> will be undergoing a PSA change, gNB2 sets the PSA change status for PDU session <NUM> to "blocked.

Step <NUM>. Since PDU session <NUM> will be undergoing a PSA change, gNB1 sets the PSA change status for PDU session <NUM> to "blocked.

Step <NUM>. The PSA change of the first PDU session, PDU session <NUM>, is started.

Step <NUM>. The UPF currently handling PDU session <NUM>, UPF1, is released by SMF1.

Step <NUM>. In the embodiment illustrated in <FIG>, while PDU session <NUM> is undergoing a PSA change, a second SMF, SMF2, also attempts to perform PSA change on PDU session <NUM> by sending a request to gNB2.

Step <NUM>. gNB2 checks the PSA change status for PDU session <NUM>.

Step <NUM>. In the embodiment illustrated in <FIG>, because gNB2 is aware of the ongoing PSA change of the first PDU session, gNB2 rejects the PSA change of the second session, PDU session <NUM> (i.e., "NOT OK"), and does not forward that request to gNB1. In some embodiments, gNB2 may store the request for the PSA change.

Step <NUM>. SMF1' creates a PDU session with UPF1'. This PDU session is called PDU session <NUM>'.

Step <NUM>. The PSA change for PDU session <NUM> ends. The PSA change of the first PDU session is then completed. In the example illustrated in <FIG> and <FIG>, the SMF is changed from SMF1 to SMF1'.

Step <NUM>. The end of the PSA change is indicated from SMF1' to gNB1, which forwards the notification to gNB2.

Step <NUM>. gNB2 acknowledges the PSA change to gNB1, which forwards the acknowledgement to SMF1'.

Step <NUM>. gNB2 sets the PSA change status for PDU session <NUM> to "allowed.

Step <NUM>. gNB1 sets the PSA change status for PDU session <NUM> to "allowed. " It is noted that steps <NUM>, <NUM>, and <NUM> may be performed in any order.

Step <NUM>. In this optional step, based on gNB2's stored information that SMF2 requested a PSA change, gNB2 may notify SMF2 that the ongoing change has completed. (If this optional feature is not provided by gNB2, then SMF2 would have to repeatedly try to re-request the change).

Step <NUM>. SMF2 again requests a PSA change from gNB2 for a second PDU session, PDU session <NUM>.

Step <NUM>. gNB2 checks the PSA change status and determines that PDU session <NUM> is not currently undergoing a PSA change.

Step <NUM>. Because gNB2 knows that PDU session <NUM> and PDU session <NUM> are redundant PDU sessions, and that PDU session <NUM> is through gNB1, gNB2 forwards the request to gNB1.

Step <NUM>. gNB1 checks the PSA change status and determines that PDU session <NUM> is not currently undergoing a PSA change.

Step <NUM>. gNB1 sends a PSA change OK message to gNB2, which forwards that message to SMF2. At this point, both gNB2 and gNB1 are now aware that the PSA of the second PDU session is being changed.

Step <NUM>. gNB1 sets the PSA change status for PDU session <NUM> to "blocked.

Step <NUM>. gNB2 sets the PSA change status for PDU session <NUM> to "blocked. " It is noted that steps <NUM>, <NUM>, and <NUM> may be performed in any order.

Step <NUM>. The PSA change for the second PDU session is started.

Step <NUM>. SMF2 releases the PDU session with UPF2 (PDU session <NUM>).

Step <NUM>. SMF2' creates a PDU session with UPF2' (PDU session <NUM>').

Step <NUM>. The PSA change for the second PDU session ends.

Step <NUM>. SMF2' signals the end of the PSA change to gNB2 and gNB1, hence gNB2 and gNB1 will become aware that the process is finished, and new PSA change processes may be allowed.

Step <NUM>. gNB1 sets the PSA change status for PDU session <NUM> to "allowed.

Step <NUM>. The end of the PSA change is acknowledged by gNB1 and gNB2. It is noted that steps <NUM>, <NUM>, and <NUM> may be performed in any order.

A possible issue that may arise is a race condition between gNB1 and gNB2 when both PDU Sessions request PSA change at the same time. In that case it may happen that both gNB1 and gNB2 send a message to the other gNB for a PSA Change Request. To resolve such race conditions, a conflict resolution needs to be agreed in advance which request to accept in the case of simultaneous requests. (Simultaneous requests would mean that a gNB gets a new request for PSA change while its own request for PSA change is pending, i.e., sent to the other gNB and waiting for an answer. ) There could be several such rules which uniquely determine which gNB should win such race conditions. Example rules include, but are not limited to, rules such as: always the Master gNB should win in the case of dual connectivity; or always the gNB with a higher identity number; or always the PDU Session with a higher session id, and so on. Other conflict resolution techniques could also be possible.

The PSA change of a PDU Session causes temporary outages or change in the delay for that PDU Session. Therefore, it is important that the other PDU Session can remain operational and unaffected, so that at least one of the PDU Sessions can continuously deliver user data uninterrupted. For that reason, it can be advantageous to temporarily postpone handovers on the other PDU sessions, since handovers in RAN can also lead to temporary disruptions in the delivery of user plane data. For example, in case PSA change is indicated for a first PDU Session, the handovers are temporarily postponed on the other PDU Session. An example of this is shown in <FIG>.

<FIG> is a signaling graph showing messages exchanged during an exemplary process for coordinated change of PDU session anchors and/or handovers. In <FIG>, the process includes the following steps.

Step <NUM>. A first gNB, gNB1, determines that a handover involving a PDU session that is being handled by gNB1, PDU session <NUM>, is needed. In <FIG>, PDU session <NUM> and PDU session <NUM>, which is being handled by a second gNB, gNB2, are redundant sessions.

Step <NUM>. gNB1 sends, to a centralized node for maintaining PSA change / handover status for PDU sessions, Synch DB, a handover request for PDU session <NUM>.

Step <NUM>. In the embodiment illustrated in <FIG>, Synch DB determines that a change is allowed, i.e., neither PDU session <NUM> nor PDU session <NUM> are currently undergoing a PSA change or a handover.

Step <NUM>. Synch DB notifies gNB1 that a handover for PDU session <NUM> is allowed.

Step <NUM>. Synch DB sets the change status associated with PDU session <NUM> to "blocked.

Step <NUM>. gNB1 begins the handover process.

Step <NUM>. In the embodiment illustrated in <FIG>, while the handover involving PDU session <NUM> is in progress, gNB2 determines that a handover involving PDU session <NUM> is needed.

Step <NUM>. gNB2 sends Synch DB a handover request for PDU session <NUM>.

Step <NUM>. In the embodiment illustrated in <FIG>, Synch DB determines that a PSA change / handover is blocked, e.g., because PDU session <NUM> is currently undergoing a handover.

Step <NUM>. Synch DB notifies gNB2 that a handover for PDU session <NUM> is not allowed.

Step <NUM>. gNB1 completes the handover involving PDU session <NUM>.

Step <NUM>. gNB1 notifies Synch DB that the handover involving PDU Session <NUM> is complete.

Step <NUM>. Synch DB sets a change status associated with PDU session <NUM> to "allowed.

Step <NUM>. In this optional step, Synch DB notifies gNB2 that a PSA change or handover is now allowed for PDU session <NUM>.

Step <NUM>. gNB2 again sends Synch DB a handover request for PDU session <NUM>.

Step <NUM>. Synch DB determines that a PSA change / handover is allowed.

Step <NUM>. Synch DB notifies gNB2 that a handover for PDU session <NUM> is allowed.

Step <NUM>. Synch DB sets a change status associated with PDU session <NUM> to "blocked.

Step <NUM>. gNB2 performs a handover involving PDU session <NUM>.

Step <NUM>. gNB2 notifies Synch DB that the handover involving PDU session <NUM> is complete.

<FIG> is a signaling graph showing messages exchanged during an exemplary process for coordinated change of PDU session anchors and/or handovers according to other embodiments of the present disclosure. In the embodiment illustrated in <FIG>, the process includes the following steps.

Step <NUM>. A first gNB, gNB1, determines that a handover involving a PDU session that is being handled by gNB1, PDU session <NUM>, is needed. In the embodiment illustrated in <FIG>, PDU session <NUM> and PDU session <NUM>, which is being handled by a second gNB, gNB2, are redundant sessions.

Step <NUM>. gNB1 checks a change status associated with PDU session <NUM>. In the embodiment illustrated in <FIG>, a PSA change or handover is allowed, e.g., because PDU session <NUM> is not currently undergoing a PSA change or a handover.

Step <NUM>. gNB1 knows that PDU session <NUM> is a redundant session with PDU session <NUM>, so gNB1 queries gNB2 to check a change status associated with PDU session <NUM>.

Step <NUM>. In the embodiment illustrated in <FIG>, gNB2 determines that a PSA change or handover is allowed, e.g., because PDU session <NUM> is not currently undergoing a PSA change or a handover.

Step <NUM>. gNB2 notifies gNB1 that a PSA change or handover is allowed for PDU session <NUM>.

Step <NUM>. gNB1 notifies gNB2 that a PSA change or handover for PDU session <NUM> is blocked, i.e., because a handover will be performed.

Step <NUM>. gNB1 sets the change status associated with PDU session <NUM> to "blocked.

Step <NUM>. gNB1 sets the change status associated with PDU session <NUM> to "blocked. " It is noted that steps <NUM> and <NUM> may be performed in any order.

Step <NUM>. gNB2 checks the change status, determines that PSA change or handover for PDU session <NUM> is blocked, i.e., because PDU session <NUM> is currently undergoing a handover.

Step <NUM>. gNB1 sets a change status associated with PDU session <NUM> to "allowed.

Step <NUM>. In this optional step, gNB1 notifies gNB2 that a PSA change or handover is now allowed for PDU session <NUM>.

Step <NUM>. Knowing that PDU session <NUM> is redundant with PDU session <NUM>, gNB2 sets a change status associated with PDU session <NUM> to "allowed.

Step <NUM>. gNB2 queries gNB1 to check on a change status associated with PDU session <NUM>.

Step <NUM>. gNB1 determines that a PSA change / handover of PDU session <NUM> is allowed.

Step <NUM>. gNB1 signals to gNB2 that a PSA change or handover for PDU session <NUM> is allowed.

Step <NUM>. gNB2 signals to gNB1 that a PSA change or handover for PDU session <NUM> is blocked, i.e., because a handover for PDU session <NUM> will be performed.

Step <NUM>. gNB2 sets a change status associated with PDU session <NUM> to "blocked.

Step <NUM>. gNB1 sets a change status associated with PDU session <NUM> to "blocked.

Step <NUM>. gNB2 notifies gNB1 that a PSA change or handover for PDU session <NUM> is not allowed.

Step <NUM>. gNB2 sets a change status associated with PDU session <NUM> to "allowed.

The RAN based synchronization approach gives a good solution for this, since the PSA change is also signaled to the gNB of the other PDU Session. Therefore, in case a gNB is aware that a PSA change is taking place on the other PDU session, it temporarily tries to postpone handovers. Note that in case the radio link quality deteriorates below a certain level, it may be necessary to perform the handover anyway, but in many cases it could be possible to postpone the handover for a limited period of time.

Similarly, it may be preferable to delay/postpone the PSA change while a handover is ongoing in RAN. In the signaling sequence above, for example, if gNB1 is aware that a handover is ongoing for the other PDU session, gNB1 may postpone the PSA change. This could be done by waiting with the signaling to gNB2 until the handover is completed; or alternatively informing SMF1 to re-try later (where it is possible to specify a retry interval as well). Also, it is possible to postpone the PSA change if a handover is ongoing for the given session rather than the other session.

<FIG> is a schematic block diagram of a network node <NUM> according to some embodiments of the present disclosure. The network node <NUM> may be, for example, a radio access node, such as a base station <NUM> or <NUM>, or a core network node. As illustrated, the network node <NUM> includes a control system <NUM> that includes one or more processors <NUM> (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like), memory <NUM>, and a network interface <NUM>. The one or more processors <NUM> are also referred to herein as processing circuitry. In addition, the network node <NUM> optionally includes one or more radio units <NUM> that each includes one or more transmitters <NUM> and one or more receivers <NUM> coupled to one or more antennas <NUM>. The radio units <NUM> may be referred to or be part of radio interface circuitry. In some embodiments, the radio unit(s) <NUM> is external to the control system <NUM> and connected to the control system <NUM> via, e.g., a wired connection (e.g., an optical cable). However, in some other embodiments, the radio unit(s) <NUM> and potentially the antenna(s) <NUM> are integrated together with the control system <NUM>. The one or more processors <NUM> operate to provide one or more functions of a network node <NUM> as described herein. In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory <NUM> and executed by the one or more processors <NUM>.

<FIG> is a schematic block diagram that illustrates a virtualized embodiment of the network node <NUM> according to some embodiments of the present disclosure.

As used herein, a "virtualized" radio access node is an implementation of the network node <NUM> in which at least a portion of the functionality of the network node <NUM> is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, in this example, the network node <NUM> includes the control system <NUM> that includes the one or more processors <NUM> (e.g., CPUs, ASICs, FPGAs, and/or the like), the memory <NUM>, and the network interface <NUM> and the one or more optional radio units <NUM> that each includes the one or more transmitters <NUM> and the one or more receivers <NUM> coupled to the one or more antennas <NUM>, as described above. The control system <NUM> may be connected to the optional radio unit(s) <NUM> via, for example, an optical cable or the like. The control system <NUM> is connected to one or more processing nodes <NUM> coupled to or included as part of a network(s) <NUM> via the network interface <NUM>. Each processing node <NUM> includes one or more processors <NUM> (e.g., CPUs, ASICs, FPGAs, and/or the like), memory <NUM>, and a network interface <NUM>.

In this example, functions <NUM> of the network node <NUM> described herein are implemented at the one or more processing nodes <NUM> or distributed across the control system <NUM> and the one or more processing nodes <NUM> in any desired manner. In some particular embodiments, some or all of the functions <NUM> of the network node <NUM> described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) <NUM>. As will be appreciated by one of ordinary skill in the art, additional signaling or communication between the processing node(s) <NUM> and the control system <NUM> is used in order to carry out at least some of the desired functions <NUM>. Notably, in some embodiments, the control system <NUM> may not be included, in which case the radio unit(s) <NUM> communicate directly with the processing node(s) <NUM> via an appropriate network interface(s).

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

<FIG> is a schematic block diagram of the network node <NUM> according to some other embodiments of the present disclosure. The network node <NUM> includes one or more modules <NUM>, each of which is implemented in software. The module(s) <NUM> provide the functionality of the network node <NUM> described herein.

<FIG> is a schematic block diagram of a UE <NUM> according to some embodiments of the present disclosure. As illustrated, the UE <NUM> includes one or more processors <NUM> (e.g., CPUs, ASICs, FPGAs, and/or the like), memory <NUM>, and one or more transceivers <NUM> each including one or more transmitters <NUM> and one or more receivers <NUM> coupled to one or more antennas <NUM>. The transceiver(s) <NUM> includes radio-front end circuitry connected to the antenna(s) <NUM> that is configured to condition signals communicated between the antenna(s) <NUM> and the processor(s) <NUM>, as will be appreciated by on of ordinary skill in the art. The processors <NUM> are also referred to herein as processing circuitry. The transceivers <NUM> are also referred to herein as radio circuitry. In some embodiments, the functionality of the UE <NUM> described above may be fully or partially implemented in software that is, e.g., stored in the memory <NUM> and executed by the processor(s) <NUM>. Note that the UE <NUM> may include additional components not illustrated in <FIG> such as, e.g., one or more user interface components (e.g., an input/output interface including a display, buttons, a touch screen, a microphone, a speaker(s), and/or the like and/or any other components for allowing input of information into the UE <NUM> and/or allowing output of information from the UE <NUM>), a power supply (e.g., a battery and associated power circuitry), etc..

<FIG> illustrates a telecommunication network connected via an intermediate network to a host computer in accordance with some embodiments of the present disclosure. In the embodiment illustrated in <FIG>, a communication system includes a telecommunication network <NUM>, such as a 3GPP-type cellular network, which comprises an access network <NUM>, such as a RAN, and a core network <NUM>. The access network <NUM> comprises a plurality of base stations 1706A, 1706B, 1706C, such as Node Bs, eNBs, gNBs, or other types of wireless Access Points (APs), each defining a corresponding coverage area 1708A, 1708B, 1708C. Each base station 1706A, 1706B, 1706C is connectable to the core network <NUM> over a wired or wireless connection <NUM>. A first UE <NUM> located in coverage area 1708C is configured to wirelessly connect to, or be paged by, the corresponding base station 1706C. A second UE <NUM> in coverage area 1708A is wirelessly connectable to the corresponding base station 1706A.

<FIG> is a generalized block diagram of a host computer communicating via a base station with a UE over a partially wireless connection in accordance with some embodiments of the present disclosure. In the embodiment illustrated in <FIG>, in a communication system <NUM>, a host computer <NUM> comprises hardware <NUM> including a communication interface <NUM> configured to set up and maintain a wired or wireless connection with an interface of a different communication device of the communication system <NUM>.

It is noted that the host computer <NUM>, the base station <NUM>, and the UE <NUM> illustrated in <FIG> may be similar or identical to the host computer <NUM>, one of the base stations 1706A, 1706B, 1706C, and one of the UEs <NUM>, <NUM> of <FIG>, respectively.

The wireless connection <NUM> between the UE <NUM> and the base station <NUM> is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to the UE <NUM> using the OTT connection <NUM>, in which the wireless connection <NUM> forms the last segment. More precisely, the teachings of these embodiments coordinate the change of PSAs for redundant user plane paths and thereby provide benefits such as increased stability in dual-connectivity scenarios.

In certain embodiments, measurements may involve proprietary UE signaling facilitating the host computer's <NUM> measurements of throughput, propagation times, latency, and the like.

These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include DSPs, special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as ROM, RAM, cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein.

The methods and systems of the present disclosure facilitate maintaining redundant paths in the case of mobile devices. As the anchor point is changed on one of the paths only, the other path can carry data uninterrupted. Once the anchor point change completes on one path, the roles can be reversed and the anchor point can be changed on the other path if necessary. By taking anchor change processes one at a time, critical applications may remain uninterrupted.

Methods and systems according to the present disclosure can allow anchor change to take place, whereas in conventional systems, solution critical applications may otherwise choose to not perform anchor change. As a result of the possibility of anchor change, the end-to-end paths can become shorter, which reduces the end-to-end latency. Additionally, shorter end-to-end paths lead to less failure opportunities on the way, and thereby improving the communication systems availability. Also, by allowing the flexibility to do anchor change with the related path modification, it may be possible to maintain redundant paths, when otherwise such redundant paths might not be available with too distant anchor points.

Claim 1:
A method for coordinated change of Protocol Data Unit, PDU, Session Anchors, PSAs, the method comprising:
at a network
node for maintaining PSA change status for PDU sessions:
receiving (<NUM>,<NUM>,<NUM>, <NUM>, <NUM>), from a requesting entity, a request for a PSA change for a first PDU session having a first PSA, where the first PDU session and a second PDU session are redundant PDU sessions with each other;
determining (<NUM>,<NUM>,<NUM>, <NUM>, <NUM>) whether the PSA change for the first PDU session is temporarily prohibited;
upon determining (<NUM>, <NUM>) that the PSA change for the first PDU session is temporarily prohibited, denying (<NUM>, <NUM>) the request for the PSA change for the first PDU session; and
upon determining (<NUM>, <NUM>, <NUM>) that the PSA change for the first PDU session is not temporarily prohibited:
granting (<NUM>,<NUM>, <NUM>, <NUM>) the request for the PSA change for the first PDU session;
setting (<NUM>,<NUM>, <NUM>, <NUM>) a PSA change status associated with the first PDU session to indicate that the PSA change for the first PDU session is temporarily prohibited;
subsequently receiving (<NUM>,<NUM>, <NUM>, <NUM>) an indication that the PSA change for the first PDU session is completed; and
setting (<NUM>,<NUM>, <NUM>, <NUM>) the PSA change status associated with the first PDU session to indicate that the PSA change for the first PDU session is allowed,
wherein determining that the PSA change for the first PDU session is temporarily prohibited comprises at least one of: determining that the first PDU session is currently undergoing a handover; determining that the second PDU session is currently undergoing a handover; and determining that the second PDU session is currently undergoing a PSA change.