EP4356647A1 - Procédé et dispositif pour un ensemble de fonctions de réseau dynamique - Google Patents

Procédé et dispositif pour un ensemble de fonctions de réseau dynamique

Info

Publication number
EP4356647A1
EP4356647A1 EP21749167.9A EP21749167A EP4356647A1 EP 4356647 A1 EP4356647 A1 EP 4356647A1 EP 21749167 A EP21749167 A EP 21749167A EP 4356647 A1 EP4356647 A1 EP 4356647A1
Authority
EP
European Patent Office
Prior art keywords
user device
network entity
serving
serving network
profile
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP21749167.9A
Other languages
German (de)
English (en)
Inventor
Artur Hecker
Xun XIAO
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of EP4356647A1 publication Critical patent/EP4356647A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/12—Reselecting a serving backbone network switching or routing node
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0016—Hand-off preparation specially adapted for end-to-end data sessions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H04W8/20—Transfer of user or subscriber data

Definitions

  • 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.
  • CP control plane
  • UP user plane
  • CP NFs CP and UP network functions
  • UEs user entities
  • a commercial core network follows a centralized deployment scheme.
  • some trends are happening now, which challenge the centralized core network system.
  • High- 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.
  • cells e.g., base stations
  • core NFs are needed to provide sufficient capacity and a centralized core network is not economical to manage geographically dense cells.
  • An enterprise-level organization e.g., a university or a manufacturing company
  • NPNs non-public networks
  • NPNs non-public networks
  • a centralized core network scheme cannot fulfill such a requirement yet.
  • An access and mobility management function 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.).
  • 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).
  • a user device e.g., UE
  • 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.
  • UDR shared user data repository
  • 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.
  • a more efficient way is needed to provide a faster switching solution to save the switching time.
  • 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.
  • 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.
  • 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.
  • an issue of a centralized core network deployment where an NF set i.e. a group of the same type of NFs
  • an NF set i.e. a group of the same type of NFs
  • the NF set cannot be dynamically adapted, it cannot provide flexible services.
  • 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.
  • 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.
  • 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.
  • the state report of the user device comprises at least one of:
  • a target cell may be the cell to which the user device is approaching, or intends to join.
  • 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.
  • NRF network repository function
  • NF instances are registered at the NRF in the core network.
  • 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).
  • GUIs global unique AMF identifiers
  • TNLAs transport layer network associations
  • 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.
  • 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.
  • 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.
  • 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.
  • the network entity when receiving a response indicates that the update is failed, is further configured to remove the serving network entity that sends the response from the set of serving network entities.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • AMF set i.e. serving network instances in it
  • AMF set i.e. serving network instances in it
  • the network entity is configured to receive a handover complete notification from the target serving network entity.
  • 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.
  • 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.
  • 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.
  • 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.
  • cAMF candidate serving network entity
  • 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.
  • 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.
  • the network entity may be prepared for severing the other user device for potential handover events.
  • the network entity is configured to propagate the profile of the user device to a following serving network entity.
  • 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.
  • 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.
  • the competition protocol at least comprises a random process, a voting-based competition, and a Nakamoto consensus.
  • 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.
  • 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.
  • UPF user plane function
  • 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.
  • SMF Session Management Function
  • 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.
  • 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.
  • 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.
  • an embodiment/example may refer to other embodiments/examples.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 2 shows a comparison of a procedure according to an embodiment of the disclosure, and a conventional handover 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.
  • an AMF set can adjust its size and the member organization depending on the situation.
  • 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.
  • 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.
  • 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.
  • the state report 101 of the user device comprises at least one of:
  • 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.
  • TNLA transport layer network association
  • 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.
  • 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.
  • the sAMF analyzes the reporting to retrieve necessary information for predicting the potential AMF changing events, such as mobility information of the user device.
  • 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.
  • QoS quality of service
  • 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.
  • NF instances are registered at NRF in the core network.
  • 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.
  • 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.
  • 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.
  • different sets of information for different UE IDs can be provided to NRF at the same time, to improve signaling efficiency.
  • the response may include a list of GUAMIs corresponding to selected AMF instances that can serve the requested cell IDs for every UE ID.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the network entity 100 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.
  • the candidate AMF instances acknowledge the sAMF for confirmation.
  • 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.
  • the selected AMF instances may be in the same AMF set or in a different set. This covers both Xn-/N2-based handover scenarios.
  • 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.
  • 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.
  • 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.
  • the synchronization of the user device profile may be performed in a centralized manner or a decentralized manner.
  • a candidate AMF instance 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.
  • the new SMF instance 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.
  • Newly configured UPFs acknowledge newly configured SMFs with configuration results (OK or FAILED).
  • every AMF instance acknowledges to the sAMF.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • the winning AMF instance sends them the state synchronization with a best-effort strategy without any preference.
  • Every AMF instance 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • RAN triggers an actual handover for a UE to the current serving AMF (sAMF), i.e., the network entity 100.
  • sAMF serving AMF
  • the sAMF returns directly target AMF instance with access information RAN.
  • RAN replies target AMF instance access information to the UE.
  • 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.
  • 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.
  • the target AMF instance informs the sAMF that the UE handover is finished.
  • the network entity 100 may receive a handover complete notification from the target serving network entity 200.
  • the sAMF de-registers itself at NRF, e.g., by removing its current GUAMI corresponding to the current AMF set.
  • 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.
  • UE establishes a connection to UPF and continues its service.
  • 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.
  • An AMF instance 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
  • An AMF instance i.e., one candidate AMF instance
  • the network entity 100 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the network entity 100 may be configured to propagate the profile of the user device to a following serving network entity 202.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the method 900 comprises a step 903 of synchronizing a profile 102 of the user device within the set of serving network entities 10.
  • 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.
  • 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.
  • TCM trellis-coded modulation
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

La présente invention concerne une entité de réseau et un procédé, en particulier pour fournir un ensemble AMF dynamique. À cette fin, l'invention propose une entité de réseau configurée pour : obtenir un rapport d'état d'un dispositif d'utilisateur qui est desservi par l'entité de réseau d'un ensemble d'entités de réseau de desserte, dans lequel le rapport d'état comprend au moins un élément parmi : une identité du dispositif d'utilisateur, une qualité de liaison pour l'identité du dispositif d'utilisateur, une qualité de cellule, et une identité d'une cellule détectée ; mettre à jour l'ensemble d'entités de réseau de desserte pour le dispositif d'utilisateur sur la base du rapport d'état ; et synchroniser un profil du dispositif d'utilisateur dans l'ensemble d'entités de réseau de desserte. En outre, cette invention propose également un procédé correspondant exécuté par l'entité de réseau.
EP21749167.9A 2021-07-23 2021-07-23 Procédé et dispositif pour un ensemble de fonctions de réseau dynamique Pending EP4356647A1 (fr)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2021/070722 WO2023001386A1 (fr) 2021-07-23 2021-07-23 Procédé et dispositif pour un ensemble de fonctions de réseau dynamique

Publications (1)

Publication Number Publication Date
EP4356647A1 true EP4356647A1 (fr) 2024-04-24

Family

ID=77168246

Family Applications (1)

Application Number Title Priority Date Filing Date
EP21749167.9A Pending EP4356647A1 (fr) 2021-07-23 2021-07-23 Procédé et dispositif pour un ensemble de fonctions de réseau dynamique

Country Status (3)

Country Link
EP (1) EP4356647A1 (fr)
CN (1) CN117581589A (fr)
WO (1) WO2023001386A1 (fr)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013068529A1 (fr) * 2011-11-11 2013-05-16 Research In Motion Limited Procédé et appareil de mise à jour d'un ensemble actif pour un dispositif
WO2018194971A1 (fr) * 2017-04-17 2018-10-25 Intel Corporation Contexte et sécurité basés sur un groupe pour des dispositifs de l'internet des objets massif
US20190116486A1 (en) * 2017-10-17 2019-04-18 Electronics And Telecommunications Research Institute Method and apparatus for location based service in 5g system
WO2021128157A1 (fr) * 2019-12-26 2021-07-01 华为技术有限公司 Dispositif, système et procédé de transfert

Also Published As

Publication number Publication date
CN117581589A (zh) 2024-02-20
WO2023001386A1 (fr) 2023-01-26

Similar Documents

Publication Publication Date Title
US20210289340A1 (en) Method and apparatus for network virtualization and session management
US10313997B2 (en) User equipment registration method for network slice selection and network controller and network communication system using the same
CN109792458B (zh) 用于用户面路径选择的方法和系统
CN110049070B (zh) 事件通知方法及相关设备
CN111565404B (zh) 一种数据分流方法和装置
TWI380713B (en) Expedited handoff
US11622398B2 (en) Methods and devices for connecting a wireless communication device to a user plane in a wireless communication network
CN109150808B (zh) 通信方法、装置和系统
JP4422101B2 (ja) 途切れずに引渡しを行うためのコンテキスト転送
US20230232228A1 (en) Method and apparatus for establishing secure communication
CN114208296A (zh) 一种通信方法及相关设备
CN113395238B (zh) 一种认证授权方法及对应装置
KR20220047034A (ko) Mec 서비스를 제공하기 위한 방법 및 장치
EP3586543B1 (fr) Placement de contexte dans le réseau de communication mobile
CN117082612B (zh) 针对电机的集群式控制方法及装置
US20240040005A1 (en) Context transfer method and communication apparatus
CN111614424B (zh) 一种子网融合方法、装置、节点及存储介质
JP7149328B2 (ja) カップリングリダイレクト方法および装置
WO2023001386A1 (fr) Procédé et dispositif pour un ensemble de fonctions de réseau dynamique
US20240323707A1 (en) Network resilience
US20170289945A1 (en) Control device, network device and methods thereof
EP4210248A1 (fr) Procédé et dispositif de fourniture de service mec
WO2023141827A1 (fr) Informations spécifiques à une zone d'intérêt pour une informatique périphérique à accès multiple
US20240090069A1 (en) Decentralized session management
TWI854211B (zh) 一種用於傳輸上下文的方法和通信裝置

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20240116

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR