EP4356647A1

EP4356647A1 - Method and device for dynamic network function set

Info

Publication number: EP4356647A1
Application number: EP21749167.9A
Authority: EP
Inventors: Artur Hecker; Xun XIAO
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2021-07-23
Filing date: 2021-07-23
Publication date: 2024-04-24
Also published as: WO2023001386A1; CN117581589A

Abstract

The present disclosure relates to a network entity and a method, particularly for providing a dynamic AMF set. To this end, the disclosure proposes a network entity configured to: obtain a state report of a user device that is served by the network entity of a set of serving network entities, wherein the state report comprises at least one of: an identity of the user device, a link quality for the identity of the user device, a cell quality, and an identity of a sensed cell; update the set of serving network entities for the user device based on the state report; and synchronize a profile of the user device within the set of serving network entities. Further, this disclosure also proposes a corresponding method performed by the network entity.

Description

METHOD AND DEVICE FOR DYNAMIC NETWORK FUNCTION SET

TECHNICAL FIELD

The present disclosure relates to mobile communication networks, and more particularly to network functions for providing services. The disclosure proposes a network function set, which can be dynamically adapted to provide flexible services to user devices.

BACKGROUND

Current cellular network systems (e.g., a 5^th generation (5G) network) engage a control plane (CP) and user plane (UP) separation (CUPS) strategy. The core network part of a cellular network system contains both CP and UP network functions (NFs), wherein CP NFs act as a commander of a mobile system and govern UP NFs to realize concrete network services for user entities (UEs) or user devices. So far, a commercial core network follows a centralized deployment scheme. However, some trends are happening now, which challenge the centralized core network system.

First of all, higher frequency channels are increasingly employed (e.g., terahertz). High- frequency channels have shorter transmission ranges, so more cells (e.g., base stations) are needed to cover the same area than before. Correspondingly, more core NFs are needed to provide sufficient capacity and a centralized core network is not economical to manage geographically dense cells.

Secondly, the diversity of services is constantly growing and more latency- sensitive and mission-critical services are loaded on mobile systems such as virtual reality (VR), augmented reality (AR), eHealth, and autonomous driving. These services require high bandwidth and ultra-low latency. It is difficult for a centralized core network to handle a service request in a timely manner.

Thirdly, abundant vertical industries join in the mobile wireless ecosystem such as smart factories and wireless campuses. An enterprise-level organization (e.g., a university or a manufacturing company) prefers to have their private deployments. Naturally, non-public networks (NPNs) own their local core networks including CP and UP NFs onsite. A centralized core network scheme cannot fulfill such a requirement yet. An access and mobility management function (AMF) is one of the most important CP-NFs. The AMF is responsible for many critical procedures and managements for the UEs (e.g., access management, mobility management, an anchor point of authentication, etc.). Notably, the AMF is the first CP NF that UEs will contact when accessing services of a mobile wireless network.

An AMF may comprise multiple instances, and these AMF instances may be arranged in a distributed architecture. In this case, there may arise the technical problem that how to coordinate different AMF instances regarding a profile of a user device (e.g., UE).

SUMMARY

In view of the above, it is a general objective of the present disclosure to provide a mechanism for synchronizing a profile of a user device in a network.

Embodiments of the present disclosure, which achieve this objective, are based further on the following further considerations of the inventors.

A logical AMF, in reality, is not a single (physical) entity but - as mentioned - usually realized with a set of AMF instances in the core network. Different AMF instances are assigned to corresponding management domains. Internally, an AMF instance has to be prepared before serving, especially when one ongoing service switches from one to another AMF instance. Specifically, they have to maintain a synchronized view as an AMF set. At least two classes of states may need to be synchronized: UE states and internally running states. For UE states, in the current standard, they can be possibly stored in a shared user data repository (UDR); however, for AMF running states, that cannot be always exported.

Synchronizing states among AMF instances takes time, and thus cannot be always finished instantly. This will degrade the quality of ongoing services, especially when switching among AMF instances becomes much more frequent, for example, for handover events. This is not a serious issue for the current centralized core network deployment with a sparse cell density. That is, because the centralized core network has enough time and resources to handle infrequent handover activities. However, when switching AMF instances is required quite often in a distributed architecture, a more efficient way is needed to provide a faster switching solution to save the switching time. In view of these limitations, the embodiments of the present disclosure specifically have the objective to introduce a dynamic network entity set (e.g., AMF set) adjustment solution where the network entity switching at the core network side is decoupled from the actual switching commands. Thereby, another objective is to provide a faster switching solution to save switching time. A further objective is to predict potential events leading to the network entity switching for services, and to prepare a dynamic network entity set, which is self-adapted and is ready to serve a user device, therefore, whenever the switching occurs no live preparation is needed.

These and other objectives are achieved by embodiments as provided in the enclosed independent claims. Advantageous implementations of the embodiments are further defined in the dependent claims.

A first aspect of the disclosure provides a network entity, configured to obtain a state report of a user device that is served by the network entity of a set of serving network entities, wherein the state report comprises at least one of: an identity of the user device, a link quality for the identity of the user device, a cell quality, and an identity of a sensed cell; update the set of serving network entities for the user device based on the state report; and synchronize a profile of the user device within the set of serving network entities.

In this disclosure, an issue of a centralized core network deployment where an NF set (i.e. a group of the same type of NFs) cannot dynamically adapt itself, is considered. Since the NF set cannot be dynamically adapted, it cannot provide flexible services. Particularly, embodiments of this disclosure focus on how a set of AMFs, i.e. the set of network entities is an AMF set, can be self-adaptive to frequent mobility events.

According to this disclosure, the network entity may be an AMF instance that is currently serving the user device. The set of serving network entities may also refer to as the dynamic AMF set. In particular, information regarding the dynamic AMF set may be realized by constantly retrieving UE state reporting, e.g., from the radio access network (RAN). Based on such information, either the RAN side, or the core network side (i.e., the network entity) can characterize a concrete situation of the current served UE. In an implementation form of the first aspect, the state report of the user device comprises at least one of:

- one or more target cells or cell identities measured by the user device,

- one or more cells or cell identities which are outdated for the user device,

- a destination data network name (DNN), and

- a link quality of the one or more target cells or cell identities measured by the user device.

When a cell is outdated, the user device may be outside the serving domain of the network entity, and thus cannot serve the user device anymore. Notably, a target cell may be the cell to which the user device is approaching, or intends to join.

In an implementation form of the first aspect, the network entity is further configured to: send a request to a network repository function (NRF), wherein the request indicates the NRF to provide information of one or more serving network entities based on the state report; and receive a response, from the NRF, which includes information of the one or more serving network entities.

Specifically, NF instances are registered at the NRF in the core network. In an NRF, an NF instance registers as an entry record that contains the information of the NF instance, which includes one or more global unique AMF identifiers (GUAMIs), the pointer of its backup AMF instance, the current service load, and UE associations such as transport layer network associations (TNLAs).

In an implementation form of the first aspect, the network entity is configured to trigger to update the set of serving network entities based on the information of the one or more serving network entities.

In an implementation form of the first aspect, updating the set of serving network entities for the user device comprises: updating each serving network entity of the set of serving network entities for the user device by sending a request to each serving network entity of the set of serving network entities for the user device, wherein the request comprises an identity of the user device, and/or a quality requirement on a running service of the user device, and/or the request indicates the serving network entity to update registration information at the NRF if the serving network entity is suitable for serving the user device.

Possibly, such request can fail if the information provided by the NRF is incorrect or invalid due to asynchronization between the NRF and the registered AMF instances.

In an implementation form of the first aspect, the network entity is configured to receive a response from each serving network entity of the set of serving network entities, wherein each response indicates that the update is successful or failed.

In an implementation form of the first aspect, when receiving a response indicates that the update is failed, the network entity is further configured to remove the serving network entity that sends the response from the set of serving network entities.

Optionally, if the request from the network entity fails, the network entity can re-send a request to the NRF. The NRF may return a new response with updated information about the AMF instance if possible.

In an implementation form of the first aspect, the synchronizing of the profile of the user device within the set of serving network entities comprises synchronizing the profile of the user device in a centralized manner or a decentralized manner.

It should be noted that the synchronization process can be done in a centralized manner or a decentralized manner. A centralized manner directly transfers the states from the network entity to candidates (other serving network entities in the set). A decentralized manner requires a distributed consensus to synchronize the states from the network entity to candidates.

In an implementation form of the first aspect, the synchronizing of the profile of the user device in a centralized manner comprises transferring the profile of the user device to each serving network entity within the set of serving network entities.

In an implementation form of the first aspect, the profile of the user device includes at least one of: a state of the user device, a serving gateway, and a quality of service policy, wherein the state of the user device includes at least one of: an identity of the user device, a link quality for the identity of the user device, a cell quality, and an identity of a sensed cell.

In an implementation form of the first aspect, the network entity is configured to: detect a handover event of the user device; and send a handover notification to a target serving network entity of the set of serving network entities.

As the AMF set (i.e. serving network instances in it) has been proactively prepared, once an actual handover event is triggered, the switching of AMF instances can be done quickly.

In an implementation form of the first aspect, the network entity is configured to receive a handover complete notification from the target serving network entity.

In an implementation form of the first aspect, the network entity is configured to de-register the network entity at an NRF for the user device, if a cell is outdated for the user device.

Optionally, the network entity may de-register itself at the NRF, e.g., by removing its current GUAMI corresponding to the current AMF set, when the user device is outside its serving range.

In an implementation form of the first aspect, the network entity is configured to: receive another request from another serving network entity within a set of serving network entities for another user device, wherein the another request comprises an identity of the another user device, and/or a quality requirement on a running service of the another user device, and/or the another request indicates the network entity to update registration information at the NRF if the network entity is suitable for serving the another user device.

It should be noted that the network entity acting as a serving AMF to one user device, may also act as a candidate serving network entity (cAMF) for a different user device. In such case, it may receive requests from other serving network entities to confirm whether it is suitable to serve the different user device.

In an implementation form of the first aspect, the network entity is configured to update the registration information at the NRF if the network entity is suitable for serving the another user device. In an implementation form of the first aspect, the network entity is configured to receive a profile of the another user device from the another serving network entity, wherein the profile of the another user device includes at least one of: a state of the another user device, a serving gateway, and a quality of service policy, wherein the state of the another user device includes at least one of: an identity of the another user device, a link quality for the identity of the another user device, a cell quality, an identity of a sensed cell.

Notably, the network entity may be prepared for severing the other user device for potential handover events.

In an implementation form of the first aspect, the network entity is configured to propagate the profile of the user device to a following serving network entity.

In a decentralized manner for synchronizing the profile of a user device, the profile of a user device has to be 1) propagated to every entity, then 2) every entity compete with a consensus protocol, after that, 3) a winner can propose an update to all the other network entities.

In an implementation form of the first aspect, the network entity is configured to compete with other serving network entities within the set to win a chance, using a competition protocol, to propagate the profile of the user device to the following serving network entity.

In an implementation form of the first aspect, the competition protocol at least comprises a random process, a voting-based competition, and a Nakamoto consensus.

In an implementation form of the first aspect, the network entity is configured to associate each of the other serving network entities within the set with a priority based on the received profile of the user device; and transfer the profile of the user device to the other serving network entities in an order of the priorities.

In particular, a prediction on a priority group of target AMF instances is made, where state transferring and synchronization happen first to the AMF instances in the identified priority group. In an implementation form of the first aspect, the network entity is configured to analyze the received profile of the user device and decide whether to update a user plane function (UPF) instance or insert a new UPF instance; and provide configurations to the UPF instance when an update or insertion of the UPF is determined.

After the network entity is notified about the other user device that it may be going to serve, the network entity may start to interact with corresponding Session Management Function(s) SMF(s) as well as UPF(s) if necessary. In this way, if later a handover occurs, the new serving AMF instance, i.e., the network entity in this case, including all necessary preparations on SMFs will be ready immediately.

In an implementation form of the first aspect, the network entity is configured to send a response to the another serving network entity, wherein the response indicates that the update is successful or failed.

In an implementation form of the first aspect, the network entity is configured to receive a handover notification from the another serving network entity.

A second aspect of the disclosure provides a method performed by a network entity, the method comprising: obtaining a state report of a user device that is served by the network entity of a set of serving network entities, wherein the state report comprises at least one of: an identity of the user device, a link quality for the identity of the user device, a cell quality, and an identity of a sensed cell; updating the set of serving network entities for the user device based on the state report; and synchronizing a profile of the user device within the set of serving network entities.

Implementation forms of the method of the second aspect may correspond to the implementation forms of the network entity of the first aspect described above. The method of the second aspect and its implementation forms achieve the same advantages and effects as described above for the network entity of the first aspect and its implementation forms.

A third aspect of the disclosure provides a computer program product comprising a program code for carrying out, when implemented on a processor, the method according to the second aspect and any implementation forms of the second aspect. It has to be noted that all devices, elements, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof.

BRIEF DESCRIPTION OF DRAWINGS

The above-described aspects and implementation forms of the present disclosure will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which

FIG. 1 shows a network entity according to an embodiment of the disclosure.

FIG. 2 shows a comparison of a procedure according to an embodiment of the disclosure, and a conventional procedure.

FIG. 3 shows a procedure of AMF set extension according to an embodiment of the disclosure.

FIG. 4 shows a procedure of centralized synchronization of the profile of a user device according to an embodiment of the disclosure.

FIG. 5 shows a procedure of decentralized synchronization of the profile of a user device according to an embodiment of the disclosure.

FIG. 6 shows a procedure of handling an actual handover activity according to an embodiment of the disclosure. FIG. 7 shows interfaces between a network entity and serving network entities according to an embodiment of the disclosure.

FIG. 8 shows a network entity according to an embodiment of the disclosure.

FIG. 9 shows a method according to an embodiment of the disclosure.

DETAILED DESCRIPTION OF EMBODIMENTS

Illustrative embodiments of method, device, and program product for providing a dynamic NF set in a communication system are described with reference to the figures. Although this description provides a detailed example of possible implementations, it should be noted that the details are intended to be exemplary and in no way limit the scope of the application.

Moreover, an embodiment/example may refer to other embodiments/examples. For example, any description including but not limited to terminology, element, process, explanation and/or technical advantage mentioned in one embodiment/example is applicative to the other embodiments/examples.

FIG. 1 shows a network entity 100 according to an embodiment of the disclosure. The network entity 100 may comprise processing circuitry (not shown) configured to perform, conduct or initiate the various operations of the network entity 100 described herein. The processing circuitry may comprise hardware and software. The hardware may comprise analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuitry may comprise components such as application-specific integrated circuits (ASICs), field-programmable arrays (FPGAs), digital signal processors (DSPs), or multi-purpose processors. The network entity 100 may further comprise memory circuitry, which stores one or more instruction(s) that can be executed by the processor or by the processing circuitry, in particular under control of the software. For instance, the memory circuitry may comprise a non-transitory storage medium storing executable software code which, when executed by the processor or the processing circuitry, causes the various operations of the network entity 100 to be performed. In one embodiment, the processing circuitry comprises one or more processors and a non-transitory memory connected to the one or more processors. The non-transitory memory may carry executable program code which, when executed by the one or more processors, causes the network entity 100 to perform, conduct or initiate the operations or methods described herein. The network entity 100 is configured to obtain a state report 101 of a user device that is served by the network entity 100 of a set of serving network entities 10. In particular, the state report 101 comprises at least one of: an identity of the user device, a link quality for the identity of the user device, a cell quality, and an identity of a sensed cell. The network entity 100 is further configured to update the set of serving network entities 10 for the user device based on the state report 101. Then, the network entity 100 is configured to synchronize a profile 102 of the user device within the set of serving network entities 10.

Thereby, the network entity 100 may be further configured to synchronize the profile 102 of the user device within the set of serving network entities 10 in a centralized manner or a decentralized manner. In the centralized manner, the profile of the user device may be directly transferred to at least one network entity in the set of serving network entities 10, while in the decentralized manner a distributed consensus may be performed between the network entities 100, 10 to synchronize the profile of the user device.

The set of serving network entities may, respectively, be AMFs. Accordingly, embodiments of this disclosure propose, in particular, a dynamic AMF set adjustment solution where the AMF switching at the core network side is decoupled from the actual switching commands (e.g., an actual handover event triggered from RAN side). In particular, a prediction on a group of candidate AMF instances, i.e., the set of serving network entities 10 as shown in FIG. 1, is made. This logically forms a dynamic AMF set that is always prepared to serve a user device if actual switching ultimately happens (e.g., a handover event).

A user device in this disclosure may be hardware equipment that has chipsets onboard for one/some/all of purposes on computing, storage, and networking; or it may be a hardware component that realizes certain actions interacting with the physical world (such as cameras, sensors, GPS, etc.); or especially it may be a software element (e.g. an application ) that is realized in a form of a computer program running on dedicated hardware equipment (such as server machine, smartphone, tablet); or it may be a combination of any previous possibilities.

Due to the mobility of the user device, the AMF that is currently serving the user device may become impropriate and the user device may need to switch to another AMF that is more suitable for serving the user device. FIG. 2 shows a comparison of a procedure according to an embodiment of the disclosure, and a conventional handover procedure.

It can be seen that in an existing standard procedure, AMF switching happens only after an explicit handover event is triggered, for example, by the RAN side. Such passive AMF switching, which is tightly coupled with handover events, causes possibly longer delays or may even cause service disruptions. Details of the handover process are as shown in the right part of FIG. 2.

Embodiments of this disclosure propose particularly a proactive AMF set adaptation procedure, as shown in the left part of FIG. 2, which is independent and decoupled from an actual handover event. Such proactive process considers any possible change of the serving AMF instance, and potential events leading AMF switching for a service, where a typical reason can be an actual handover event. A dynamic AMF set is always maintained while its set member may be adjusted in terms of the states of the considered user device, while no matter if for example the RAN triggers a handover event. Comparing with existing mobile systems, this gives an instantiation of a UE-centric service paradigm.

Notably, an AMF set can adjust its size and the member organization depending on the situation. When the serving AMF instance has to be changed, e.g., taking a handover activity as an example, the adjusted AMF set can provide a target AMF instance that is already prepared during the independent AMF set adjustment process as shown in FIG. 2.

A solution proposed in this disclosure will start to prepare AMF switching with multiple AMF instances that may or may not be in the same AMF set. After candidate AMF instances are selected, a consensus procedure will be triggered to synchronize the states of a user device among those AMF instances if a decentralized manner is used. This makes the existing AMF set to expand with more AMF instances. It should be noted that an AMF set is dynamically extended, growing or shrinking, i.e., members may come and leave, depending on the situation. In addition, during the consensus procedure, a priority group of AMF instances may be identified, where transferring profiles (states) of a user device and synchronization happen first to the AMF instances in the identified priority group. This further secures the service continuity if a handover activity of the UE eventually occurs. Furthermore, after new AMF instances are notified, each AMF instance may start to interact with corresponding SMF(s) as well as UPF(s) if necessary. In this way, if later a handover actually occurs, the new serving AMF instance including all necessary preparations on SMFs will be ready immediately. If a user device eventually associates with a new AMF instance joining in the AMF set and the old AMF set that is outdated being in the AMF set, the old AMF instance will leave the AMF set.

FIG. 3 shows a procedure of how a dynamic AMF set formation is realized with interacting with other CP NFs according to an embodiment of this disclosure. This procedure may be based on an example of a potential handover event for a user device. The source AMF instance (sAMF) of FIG. 3 may be the network entity 100 as shown in FIG. 1. Accordingly, candidate AMF instances (cAMFl, cAMF2, cAMFk) of FIG. 3 may be the serving network entity 200, 300, 400 of the set of serving network entities 10. Details of the steps are described in the following.

1. UE state reporting, i.e., the state report 101 of a user device, may be constantly sent from RAN to source AMF instance (sAMF), i.e., the network entity 100. The UE RAN state reporting may contain the following information: one or multiple UE IDs, link quality (e.g., signal-noise-ratio) for each UE ID, cell quality, sensed cell IDs, etc.

According to an embodiment of this disclosure, the state report 101 of the user device comprises at least one of:

• one or more target cells or cell identities measured by the user device,

• one or more cells or cell identities that are outdated for the user device,

• a destination DNN, and

• a link quality of the one or more target cells or cell identities measured by the user device.

Notably, the sAMF is an AMF instance that is currently serving the user device. The sAMF serves a user device, which associates via a transport layer network association (TNLA) connection over RAN. When a cell is outdated, the user device may be outside the serving domain of the network entity 100, and thus it cannot serve the user device anymore. Notably, a target cell may be the cell to which the user device is approaching. The sAMF maintains a profile of the user device, where the profile of the user device may or may not be stored in a centralized UDR. Based on the state report 101, either the RAN side or later the core network side (the serving AMF instance) can characterize a concrete situation of the current served user device. In a specific implementation, if information about multiple user devices is reported at the same time, this can also improve the signaling efficiency.

2. The sAMF analyzes the reporting to retrieve necessary information for predicting the potential AMF changing events, such as mobility information of the user device.

For instance, the information may include the cell IDs where the user device can move to, the destination DNNs, and/or quality of service (QoS) requirements on running services, mobility patterns (e.g., speed, orientation, etc.), whether the RAN side indicates potential target cells, etc. Possibly, if candidate cells are determined by the RAN side, the sAMF may follow the decision; otherwise, the sAMF may have to make the decision by itself.

3. The sAMF requests NRF (i.e., a request 103) to provide the information of candidate AMF instances, which are available to serve the services and fulfill requirements of the user device according to the profile of the user device the RAN reporting.

Specifically, NF instances are registered at NRF in the core network. In NRF, an NF instance registers as an entry record that contains the information of the NF instance, which includes one or more GUAMIs, the pointer of its backup AMF instance, the current service load, and UE associations such as TNLAs. Specifically, a GUAMI of an AMF instance further consists of the set identifier where the AMF instance belongs, its track area of the AMF instance, and the pointer of the AMF instance where other NFs can access.

According to an embodiment of this disclosure, the network entity 100 may be further configured to send the request 103 to the NRF 500, wherein the request 103 indicates the NRF 500 to provide information of one or more serving network entities based on the state report 101

The sAMF may provide some parameters to NRF, which can be used by NRF to filter out AMF instances. The parameters can include the desirable cell IDs, the list of service requirements (e.g., DNN ID of the ongoing service of each UE ID), etc. Optionally, different sets of information for different UE IDs can be provided to NRF at the same time, to improve signaling efficiency.

4. NRF responses to the sAMF with candidate AMF instances according to the requirements provided by the sAMF. The response may include a list of GUAMIs corresponding to selected AMF instances that can serve the requested cell IDs for every UE ID.

According to an embodiment of this disclosure, the network entity 100 may be further configured to receive a response, from the network repository function 500, which includes information of the one or more serving network entities.

Optionally, the network entity 100 may trigger to update the set of serving network entities 10, i.e., the dynamic AMF set, based on the information of the one or more serving network entities.

5. The sAMF starts to send requests to the listed AMF instances returned by the NRF. Possibly, such a request can fail if the provided information is incorrect or invalid due to asynchronization between the NRF and the registered AMF instances.

According to an embodiment of this disclosure, the network entity 100 may be further configured to update each serving network entity 200, 300, 400 of the set of serving network entities 10 for the user device by sending a request to each serving network entity 200, 300, 400 of the set of serving network entities 10 for the user device. In particular, the request may comprise an identity of the user device, and/or a quality requirement on a running service of the user device, and/or the request indicates the serving network entity 200, 300, 400 to update registration information at the NRF 500 if the serving network entity 200, 300, 400 is suitable for serving the user device.

6. [Optional] a. If the request from the sAMF fails, the sAMF can re-send a request to NRF ; b. NRF returns a new response with updated information about the AMF instance if possible; c. The sAMF re-connects/re-contacts to candidate AMF instances with new information from NRF. Notably, this can be executed multiple rounds when a specific AMF instance is preferred.

According to an embodiment of this disclosure, the network entity 100 may be further configured to receive a response from each serving network entity 200, 300, 400 of the set of serving network entities 10, wherein each response indicates that the update is successful or failed.

Accordingly, when receiving a response indicates that the update is failed, the network entity 100 is further configured to remove the serving network entity (400) that sends the response from the set of serving network entities 10.

7. The candidate AMF instances acknowledge the sAMF for confirmation.

8. Selected AMF instances update their registration information in NRF. This will cause the changes on GUAMIs where the field of the AMF IDs will be updated. The AMF set extension happens when selected candidate AMF instances register or update their GUAMIs in NRF.

It should be understood that the selected AMF instances may be in the same AMF set or in a different set. This covers both Xn-/N2-based handover scenarios. Further, the NRF could be a single network element (a centralized service point) or internally implemented as another NF set as well, which can provide asynchronous information for a set of identified AMF instances.

9. The sAMF starts to synchronize with the candidate AMF instances for a profile of a considered user device. The synchronization transfers the profile of the user device (e.g., as shown in FIG. 1) to the candidate AMF instances. Notably, the profile of the user device may also include one or more local states of the sAMF, for instance, running states such as memory copy, program context, etc., on the sAMF. These local states can also include stored states related to one or multiple services such as served UE IDs, QoS metrics and IDs of ongoing sessions, etc. As mentioned above, the synchronization of the user device profile may be performed in a centralized manner or a decentralized manner.

10. [Optional] After receiving the states from the sAMF, a candidate AMF instance starts to analyze the transferred states and decides whether a new SMF so as UPF(s) in UP must be updated or adjusted further. If a candidate AMF instance realizes that a new SMF adjustment is required, it will also send the profile of the user device to the new SMF instance; This new SMF addition is done by the candidate AMF checking the synchronized states and determining in terms of the ongoing service information such as DNN IDs. This information tells the new AMF whether or not a new SMF has to be chosen if the service of a UE has to be served.

11. [Optional] After the new SMF instance receives the UE states, it will further decide whether one or more UPFs have to be adjusted. Possible actions could be reconfiguring the existing UPF(s), inserting intermediate UPFs, etc.; once the new SMF instance is determined, accordingly, the new SMF will further determine whether one or multiple UPF(s) have to be added as well.

12. [Optional] Newly configured UPFs acknowledge newly configured SMFs with configuration results (OK or FAILED).

13. [Optional] Newly configured SMFs response corresponding candidate AMF instances with configuration results (OK or FAILED).

14. After handover preparations are finished on every candidate AMF instance (including possible SMF and UPF adjustments), every AMF instance acknowledges to the sAMF.

It may be worth mentioning that the preparations on a candidate AMF instance can fail. Possible reasons can be that the candidate AMF instance does not have enough resources to support the considered UE in terms of the synchronized states. If a candidate AMF instance replies a negative result, the candidate AMF instance not only replies to the sAMF but may also update NRF to exit the proposed AMF set from the sAMF. The sAMF saves the list of candidate AMF instances that successfully finish the preparation work and waits for the actual handover event of the UE from RAN.

FIG. 4 shows a state synchronization process in a centralized manner according to an embodiment of the disclosure. FIG. 4 is based on FIG. 3, where further illustrates the details of the centralized synchronization process.

1. The sAMF, i.e., the network entity 100, ranks candidate AMF instances, i.e., the serving network entities of the set of serving network entities 10 with a priority order. The priorities may be ranked according to the UE state reporting from RAN. As previously described, the UE state reporting can include link quality, cell quality, mobility patterns, and ongoing service requirements. This gives a local estimation about which candidate AMF instance could be the most probable target AMF instance if an actual handover activity happens later.

2. The sAMF transfers the local states, i.e., the profile 102 of the user device, according to the order of the priority values given to the candidate AMF instances, where the candidate AMF instance with the highest priority receives transferred states first. The state parameters are similar to the states listed in step 9 of FIG. 3.

Possibly, the profile 102 of the user device includes at least one of: a state of the user device, a serving gateway, and a quality of service policy, wherein the state of the user device includes at least one of: an identity of the user device, a link quality for the identity of the user device, a cell quality, and an identity of a sensed cell.

3. Candidate AMFs acknowledge to the sAMF with receiving the state transferring messages respectively.

FIG. 5 shows a state synchronization process in a decentralized manner according to an embodiment of the disclosure. FIG. 5 is also based on FIG. 3, where further illustrates the details of the decentralized synchronization process.

1. The sAMF proposes a state synchronization that including UE states and information of the candidate AMF instances. The UE states can include link quality, cell quality, mobility patterns, and ongoing service requirements. In addition to UE states, running states of the sAMF can be included as well, wherein the running states can be local memory states, locally maintained execution environment variables, temporally cached data regarding UEs’ services, etc.

This proposal will be propagated among candidate AMF instances so every candidate AMF instance will receive the states to be synchronized and peer candidates from the list.

2. Candidate AMF instances may perform the following three actions: store and further propagate the state synchronization message, and peer candidate AMF instances compete with each other to win a chance to propose a final update of the state synchronization with a distributed consensus protocol. The distributed consensus protocol has the following options as listed in Table 1, depending on an assumed security level.

Table 1

The detailed interactions, as well as the security level, will be different, depending on the chosen competition rules.

The random process may be the lightest competition scheme. For example, every participant can randomly generate a token integer (RE Token) with a synchronized time spot. After that every participant compares its own token with others’, the participant who generates either the largest or the least token wins. For those who generate the equal tokens, either smaller or greater RE ID participant wins. This simple random competition has the weakest security level because the tokens could be fraudulent, thus difficult to prevent malicious attacks. However, given a strong security assumption where every participant is benign, such random competition is feasible.

The voting-based competitions involve multi-round interactions for a collective voting stage. Typical choices are distributed consensus protocols such as Paxos, Ripple, and Rift. These will cause some overheads of signaling messages among participants. Comparing with a simple random mechanism, a voting-based competition offers a better security level where system failures can be prevented. However, it cannot handle malicious behaviors. The Nakamoto consensus is also known as Proof-of-Work (PoW) distributed consensus protocol widely used in a blockchain network - a distributed ledger technology. This competition does not involve frequent interactions among participants but heavy computational costs on the local side. Specifically, a computational puzzle has to be solved individually. For example, in PoW, a nonce has to be found in order to make the whole hash value fulfill a pre defined criterion, while no shortcut is possible except enumerating all possible solutions. Nakamoto consensus also achieves the highest security level where malicious behaviors can be prevented, given that 51% of participants are benign or not compromised.

The common outcome of different competition models is a winner in a competition round, who is allowed to suggest a state synchronization update. They are trade-offs between efficiency and security resilience. The higher the security resilience is desired, the lower the efficiency will be.

3. The winning AMF instance (could be either one of the candidate AMF instances or sAMF) ranks AMF instances with a priority order according to the included UE state reporting. In this example, the winning AMF instance is the cAMFl, i.e., the serving network entity 200. The ranking can be decided based on the UE states such as UE mobility patterns, signal strengthen, and/or session information.

4. The winning AMF picks the top k AMF instances in the ranking list and sends them the state synchronization messages individually. The states here are also similar to step 9 in FIG. 3.

5. For other AMF instances not in top k, for instance, cAMFk, the winning AMF instance sends them the state synchronization with a best-effort strategy without any preference.

6. After every AMF instance receives the state synchronization message, it first verifies the attached winning evidence. If the evidence proves the winning result, the AMF instance validates the integrity of the proposed state updates.

7. If the integrity is checked and OK, the AMF instance commits the state update. The above procedure describes a distributed consensus procedure with the sAMF. The sAMF may not participate in this distributed consensus. If this is the case, the sAMF acts as a client to propose state synchronization while candidate AMF instances assume the states are given. The consensus is only reached among candidate AMF instances, where the assumption here is that candidate instances cannot simply trust each other.

It should be noted that the centralized synchronization manner is suitable for a trusted environment where candidate AMF instances trust the sAMF. The decentralized synchronization manner is suitable for a distributed environment where candidate AMF instances may be controlled by different owners. The centralized manner is more efficient because the consensus procedure is a single-point decision, while the decentralized manner is more costly because it depends on the option of distributed consensus protocols, which usually require peer-to-peer signaling and multiple rounds interactions. However, the latter manner is a preferred embodiment because it provides the possibility where AMF instances of different owners can work together directly and are more resilient against single-point-of-failure.

Notably, compared to the centralized manner, the decentralized manner does not have a synchronization master node to decide who should store what states. Instead, there is a distributed consensus protocol to control the synchronization process.

FIG. 6 shows a procedure of handling an actual handover activity according to an embodiment of this disclosure. The actual handover activity is handled with a proactively prepared AMF set. In this disclosure, more than one potential target AMF instance is prepared in advance, thus the actual handover activity can be handled straightforwardly. One step that the sAMF will take is to leave the AMF set after it eventually hands over the UE to a target AMF instance. This involves updating itself in NRF 500 to modify its registration information there (e.g., removing a GUAMI associated with its current AMF set), which can be depicted in the following.

1. RAN triggers an actual handover for a UE to the current serving AMF (sAMF), i.e., the network entity 100.

2. The sAMF returns directly target AMF instance with access information RAN.

3. RAN replies target AMF instance access information to the UE. 4. A user device/UE accesses the target AMF instance with the provided information. The target AMF instance has already prepared the necessary information for the UE because in the independent proactive AMF set adjustment, the synchronization has been done.

5. The target AMF instance acknowledges to the UE that a new TNLA establishment is done and provides SMF and UPF access information for UP traffic.

6. The target AMF instance informs the sAMF that the UE handover is finished.

Optionally, the network entity 100 may receive a handover complete notification from the target serving network entity 200.

7. The sAMF de-registers itself at NRF, e.g., by removing its current GUAMI corresponding to the current AMF set.

Optionally, the network entity 100 may de-register itself at the NRF 500 for the user device, if a cell is outdated for the user device, i.e., the user device is outside of the serving domain of the network entity 100.

8. UE establishes a connection to UPF and continues its service.

According to an embodiment of this disclosure, the network entity 100 may be further configured to detect a handover event of the user device. Then, the network entity 100 may be further configured to send a handover notification to a target serving network entity 200 of the set of serving network entities 10.

The disclosure includes new interfaces and a set of new interactions with new parameters exchanged among AMF instances, as shown in FIG. 7.

This disclosure may impact the functionality of an AMF defined in 3 GPP SA2. For instance, an AMF instance will also be extended to identify candidate AMF instances with higher priority for handover event preparation, independent of the actual handover event. This disclosure may mainly impact an AMF-to-AMF interface, which could or could not be in the same AMF set. An AMF instance (i.e., the sAMF) that is currently severing a user device may interact with candidate AMF instances for state synchronization over the interface. An AMF instance (i.e., one candidate AMF instance) may run a distributed consensus protocol (in a decentralized manner) to compete with other AMF instances to win a chance to propose a state update, also winning evidence will be exchanged over the interfaces.

It should be noted that the network entity 100 according to embodiments of the disclosure, may also act as a candidate serving network entity (cAMF) for another user device different from the one it currently serves. FIG. 8 shows such network entity 100 according to an embodiment of the disclosure.

According to an embodiment of this disclosure, the network entity 100 may be configured to receive another request 103 from another serving network entity 201 within a set of serving network entities 20 for another user device. In particular, the another request 103 comprises an identity of the another user device, and/or a quality requirement on a running service of the another user device, and/or the another request indicates the network entity 100 to update registration information at the network repository function 500 if the network entity 100 is suitable for serving the another user device.

In this example, the serving network entity 201 is the “sAMF” currently serving the other user device. A dynamic AMF instance set 20 is maintained by the serving network entity 201.

According to an embodiment of this disclosure, the network entity 100 may be configured to update the registration information at the NRF 500 if the network entity 100 is suitable for serving the another user device.

According to an embodiment of this disclosure, the network entity 100 may be configured to receive a profile of the another user device from the another serving network entity 201 , wherein the profile of the another user device includes at least one of: a state of the another user device, a serving gateway, and a quality of service policy, wherein the state of the another user device includes at least one of: an identity of the another user device, a link quality for the identity of the another user device, a cell quality, and an identity of a sensed cell. According to an embodiment of this disclosure, the network entity 100 may be configured to propagate the profile of the user device to a following serving network entity 202.

According to an embodiment of this disclosure, the network entity 100 may be configured to compete with other serving network entities within the set 20 to win a chance, using a competition protocol, to propagate the profile of the user device to the following serving network entity 202.

According to an embodiment of this disclosure, the competition protocol may at least comprise a random process, a voting-based competition, and a Nakamoto consensus. Details of the competition protocols are as previously described in FIG. 5.

According to an embodiment of this disclosure, the network entity 100 may be configured to associate each of the other serving network entities 202, 203 within the set with a priority based on the received profile of the user device; and transfer the profile of the user device to the other serving network entities in an order of the priorities.

According to an embodiment of this disclosure, the network entity 100 may be configured to analyze the received profile of the user device and decide whether to update a UPF instance or insert a new UPF instance. The network entity 100 may be further configured to provide configurations to the UPF instance when an update or insertion of the UPF is determined.

According to an embodiment of this disclosure, the network entity 100 may be configured to send a response to the another serving network entity 201, wherein the response indicates that the update is successful or failed.

According to an embodiment of this disclosure, the network entity 100 may be configured to receive a handover notification from the another serving network entity 201.

One advantage of this disclosure is that it mitigates the pressure and risk that AMF switching preparation may be late. Because of the proactive strategy, necessary preparations are ongoing no matter if switching will happen eventually, at the cost of redundant backups. Whenever the switching really occurs, no live preparation is needed. Another advantage is that it is more suitable for a distributed core network (especially with high cell density), where UE behavior has more influence on network operations. In a distributed architecture, the deployment of CP NFs tightly follows the infrastructure resources across entire regions. For example, CP and UP NFs could be just aside with most of base stations at the edge of the network. The dynamic AMF set concept fits in such a frequent changing association and dynamically adjusts the member organization in the set. Hence, network operation changes along with UE’s activities. This converts the system (previously centralized and relying on manual configurations) to a user-centric system, which can be considered a revolutionary paradigm.

FIG. 9 shows a method 900 according to an embodiment of the disclosure. In a particular embodiment of the disclosure, the method 900 is performed by a network entity 100. The method 900 comprises: a step 901 of obtaining a state report 101 of a user device that is served by the network entity 100 of a set of serving network entities 10, wherein the state report 101 comprises at least one of: an identity of the user device, a link quality for the identity of the user device, a cell quality, and an identity of a sensed cell. The method 900 further comprises a step 902 of updating the set of serving network entities 10 for the user device based on the state report 101. Then, the method 900 comprises a step 903 of synchronizing a profile 102 of the user device within the set of serving network entities 10.

The present disclosure has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed disclosure, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word “comprising” does not exclude other elements or steps and the indefinite article “a” or “an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.

Furthermore, any method according to embodiments of the disclosure may be implemented in a computer program, having code means, which when run by processing means causes the processing means to execute the steps of the method. The computer program is included in a computer readable medium of a computer program product. The computer readable medium may comprise essentially any memory, such as a ROM (Read-Only Memory), a PROM (Programmable Read-Only Memory), an EPROM (Erasable PROM), a Flash memory, an EEPROM (Electrically Erasable PROM), or a hard disk drive. Moreover, it is realized by the skilled person that embodiments of the network entity 100 comprises the necessary communication capabilities in the form of e.g., functions, means, units, elements, etc., for performing the solution. Examples of other such means, units, elements and functions are: processors, memory, buffers, control logic, encoders, decoders, rate matchers, de-rate matchers, mapping units, multipliers, decision units, selecting units, switches, interleavers, de-interleavers, modulators, demodulators, inputs, outputs, antennas, amplifiers, receiver units, transmitter units, DSPs, trellis-coded modulation (TCM) encoder, TCM decoder, power supply units, power feeders, communication interfaces, communication protocols, etc. which are suitably arranged together for performing the solution. Especially, the processor(s) of the network entity 100 may comprise, e.g., one or more instances of a Central Processing Unit (CPU), a processing unit, a processing circuit, a processor, an Application Specific Integrated Circuit (ASIC), a microprocessor, or other processing logic that may interpret and execute instructions. The expression “processor” may thus represent a processing circuitry comprising a plurality of processing circuits, such as, e.g., any, some or all of the ones mentioned above. The processing circuitry may further perform data processing functions for inputting, outputting, and processing of data comprising data buffering and device control functions, such as call processing control, user interface control, or the like.

Claims

1. A network entity (100), being configured to: obtain a state report (101) of a user device that is served by the network entity (100) of a set of serving network entities (10), wherein the state report (101) comprises at least one of: an identity of the user device, a link quality for the identity of the user device, a cell quality, and an identity of a sensed cell; update the set of serving network entities (10) for the user device based on the state report (101); and synchronize a profile (102) of the user device within the set of serving network entities

(10).

2. The network entity (100) according to claim 1, wherein the state report (101) of the user device comprises at least one of:

- one or more target cells or cell identities measured by the user device,

- one or more cells or cell identities which are outdated for the user device,

- a destination data network name, and

3. The network entity (100) according to claim 2, further configured to: send a request (103) to a network repository function (500), wherein the request (103) indicates the network repository function (500) to provide information of one or more serving network entities based on the state report (101); and receive a response (104), from the network repository function (500), which includes information of the one or more serving network entities.

4. The network entity (100) according to claim 3, further configured to trigger to update the set of serving network entities (10) based on the information of the one or more serving network entities.

5. The network entity (100) according to one of the claims 1 to 4, wherein updating the set of serving network entities (10) for the user device comprises: updating each serving network entity (200, 300, 400) of the set of serving network entities (10) for the user device by sending a request to each serving network entity (200, 300, 400) of the set of serving network entities (10) for the user device, wherein the request comprises an identity of the user device, and/or a quality requirement on a running service of the user device, and/or the request indicates the serving network entity (200, 300, 400) to update registration information at the network repository function (500) if the serving network entity (200, 300, 400) is suitable for serving the user device.

6. The network entity (100) according to claim 5, configured to: receive a response from each serving network entity (200, 300, 400) of the set of serving network entities (10), wherein each response indicates that the update is successful or failed.

7. The network entity (100) according to claim 6, when receiving a response indicates that the update is failed, the network entity (100) is further configured to: remove the serving network entity (400) that sends the response from the set of serving network entities (10).

8. The network entity (100) according to one of the claims 1 to 7, wherein the synchronizing of the profile (102) of the user device within the set of serving network entities (10) comprises: synchronizing the profile (102) of the user device in a centralized manner or a decentralized manner.

9. The network entity (100) according to claim 8, wherein the synchronizing of the profile (102) of the user device in a centralized manner comprises: transferring the profile (102) of the user device to each serving network entity (200, 300, 400) within the set of serving network entities (10).

10. The network entity (100) according to one of the claims 1 to 9, wherein the profile (102) of the user device includes at least one of: a state of the user device, a serving gateway, and a quality of service policy, wherein the state of the user device includes at least one of: an identity of the user device, a link quality for the identity of the user device, a cell quality, and an identity of a sensed cell.

11. The network entity (100) according to one of the claims 1 to 10, configured to: detect a handover event of the user device; and send a handover notification to a target serving network entity (200) of the set of serving network entities (10).

12. The network entity (100) according to claim 11, configured to: receive a handover complete notification from the target serving network entity (200).

13. The network entity (100) according to one of the claims 1 to 12 and claim 2, configured to de-register the network entity (100) at a network repository function (500) for the user device, if a cell is outdated for the user device.

14. The network entity (100) according to one of the claims 1 to 13, configured to: receive another request (103) from another serving network entity (201) within a set of serving network entities (20) for another user device, wherein the another request (103) comprises an identity of the another user device, and/or a quality requirement on a running service of the another user device, and/or the another request (103) indicates the network entity (100) to update registration information at the network repository function (500) if the network entity (100) is suitable for serving the another user device.

15. The network entity (100) according to claim 14, configured to: update the registration information at the network repository function (500) if the network entity (100) is suitable for serving the another user device.

16. The network entity (100) according to claim 15, configured to: receive a profile of the another user device from the another serving network entity (201), wherein the profile of the another user device includes at least one of: a state of the another user device, a serving gateway, and a quality of service policy, wherein the state of the another user device includes at least one of: an identity of the another user device, a link quality for the identity of the another user device, a cell quality, an identity of a sensed cell.

17. The network entity (100) according to claim 16, configured to: propagate the profile (104) of the user device to a following serving network entity

(202).

18. The network entity (100) according to claim 17, configured to: compete with other serving network entities within the set (20) to win a chance, using a competition protocol, to propagate the profile of the user device to the following serving network entity (202).

19. The network entity (100) according to claim 18, wherein the competition protocol at least comprises: a random process, a voting-based competition, and a Nakamoto consensus.

20. The network entity (100) according to one of the claims 16 to 19, configured to: associate each of the other serving network entity (202, 203) within the set with a priority based on the received profile (104) of the user device; and transfer the profile (104) of the user device to the other serving network entities in an order of the priorities.

21. The network entity (100) according to one of the claims 16 to 20, configured to: analyze the received profile (104) of the user device and decide whether to update a user plane function instance or insert a new user plane function instance; and provide configurations to the user plane function instance when an update or insertion of the user plane function is determined.

22. The network entity (100) according to one of the claims 15 to 21, configured to: send a response to the another serving network entity (201), wherein the response indicates that the update is successful or failed.

23. The network entity (100) according to one of the claims 14 to 22, configured to: receive a handover notification from the another serving network entity (201).

24. A method performed by a network entity (100), comprising: obtaining a state report (101) of a user device that is served by the network entity (100) of a set of serving network entities (10), wherein the state report (101) comprises at least one of: an identity of the user device, a link quality for the identity of the user device, a cell quality, and an identity of a sensed cell; updating the set of serving network entities (10) for the user device based on the state report (101); and synchronizing a profile (102) of the user device within the set of serving network entities

(10).

25. A computer program product comprising a program code for carrying out, when implemented on a processor, the method according to claim 24.