Deploying network slicing network functions
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-06-28
- Publication Date
- 2026-08-14
Smart Images
Figure CN117641310B_ABST
Abstract
Description
Background Technology
[0001] Network slicing is a feature implemented by modern communication systems, such as fifth-generation (5G) mobile networks. Network slicing allows multiple logical networks (or slices) to be deployed on the same physical infrastructure resources. Various resources (such as compute, storage, access, transport, virtual network functions (VNFs), etc.) can be dedicated to a single slice or shared among multiple slices. Network slicing can include the instantiation, configuration, and / or activation of a target network slice. Network functions (NFs) / a set of NF instances can be selected for a given network slice. These NF instances are instantiated, configured, and / or activated. Various resources can be allocated to the selected NF instances to support the network slice. NF instances can be registered at the Network Function (NF) Repository Function (NRF) so that they can be discovered by other NF instances. Based on the availability of a network slice, one or more user equipments can use customized services provided by that specific network slice. Attached Figure Description
[0002] This disclosure will be described in detail with reference to the following figures, based on one or more various examples. These figures are for illustrative purposes only and describe examples only, as shown in the figures:
[0003] Figure 1 A schematic diagram of a network architecture in which various examples of this disclosure can be implemented is shown;
[0004] Figure 2 A flowchart depicting various examples of methods for deploying network slices according to this disclosure is shown;
[0005] Figure 3 It is a block diagram of a network management system based on various examples of this disclosure;
[0006] Figure 4A A schematic diagram illustrating the deployment of various NF instances of network slices according to various examples of this disclosure is shown;
[0007] Figure 4B A schematic diagram illustrating the deployment of various NF instances for registration in the NRF, according to various examples of this disclosure;
[0008] Figure 4C A schematic diagram illustrating communications for the discovery of NF instances at an NRF, according to various examples of this disclosure;
[0009] Figure 4D Another schematic diagram illustrates the communication discovery at the NRF for NF instances according to various examples of this disclosure;
[0010] Figure 4EA schematic diagram illustrating communication between an NF instance and an NRF according to various examples of this disclosure is shown;
[0011] Figure 4F A schematic diagram illustrating communication between interdependent NF instances according to various examples of this disclosure is shown;
[0012] Figure 5 Flowcharts illustrating deployments for network slicing according to various examples of this disclosure are shown; and
[0013] Figure 6 A block diagram of a storage medium storing processor-executable instructions according to various examples of this disclosure is shown.
[0014] The accompanying drawings are not exhaustive and do not limit this disclosure to the precise form disclosed. Detailed Implementation
[0015] Evolving communication systems, such as 5G mobile networks, are expected to deliver improved transmission capacity with reduced packet transmission latency. Leveraging network slicing, Cellular Service Providers (CSPs) can create and launch custom services with varying network requirements for a wide range of applications and services, such as the Internet of Things (IoT), Augmented Reality (AR), and autonomous vehicle technologies. CSPs can rely on virtualization technologies, such as Network Function Virtualization (NFV) for network slicing. As used in this paper, NFV is used to virtualize features of network services, such as routing, security, load balancing, etc., which have traditionally run on dedicated hardware. NFV can be implemented by separating the NF instances of a network slice from the physical resources on which they are deployed, allowing CSPs to manage and scale their network functions on demand. Furthermore, such implementations can be optimized for deployments on distributed resources, such as cloud infrastructure. Cloud infrastructure resources can be dynamically provisioned to optimize resource utilization, energy consumption, etc. Therefore, 5G services are cloud-native and capable of supporting a range of applications with continuous update capabilities. Additionally, CSPs can use automation-driven services, such as Continuous Integration (CI) and / or Continuous Deployment (CD), for continuous updates.
[0016] In some cases, network slice deployers (such as DevOps models based on CD capabilities) can be used for the automated deployment of 5G network slices. For example, a network slice deployer can deploy various components of a 5G network slice on a container orchestration platform. In some examples, to speed up deployment, the network slice deployer can use the parallel instantiation of NF instances that constitute a network slice. However, such a deployment process can impact reliability because the startup of some NF instances may fail due to their dependencies on other NF instances awaiting deployment. Therefore, a large amount of error information (such as logs, traces, and / or alerts) may be created, which may be irrelevant from a monitoring / troubleshooting perspective—considering that there may be no actual faults or failures in the system.
[0017] Furthermore, such information can cause congestion, resulting in overhead on (multiple) observability applications. Typically, observability applications are used for monitoring and / or troubleshooting the state and / or behavior of NF instances. Due to concurrent instantiation, multiple NF instances can accumulate and create a large amount of irrelevant information; thus, additional resources are allocated to observability applications. Moreover, some critical error information may be lost in such a large amount of irrelevant information, making error isolation and prioritization challenging. In some other known processes, network slice deployers with CD pipelines can handle the concurrent instantiation of some NF instances that may not have dependencies on other NF instances. However, dependent NF instances may be processed sequentially, causing some NF instances to wait first for the deployment of their NF dependencies and therefore their registration at the NRF. While such a process may reduce irrelevant information, it impacts deployment speed.
[0018] This disclosure provides techniques for the parallel instantiation of NF instances for network slices with reliability and speed. According to the example techniques of this disclosure, one approach may include first determining that the NRF is part of a network slice being deployed and that the NRF is pending deployment. In one example, a set of NF instances of the network slice is registered at the NRF. The status indicator for each NF instance in this set is set to "DEPLOYING". The status indicator for deployed and started NF instances may be set to "REGISTERED". As used herein, an NF instance is considered started when the process constituting the application associated with the NF instance has begun and the NF instance is able to handle network traffic. The start of the process may refer to a software package running on a platform. In some examples, the platform may be a container orchestration platform and the software package may include components such as code and associated runtime, system libraries, and / or any default values used for settings. In one example, the software package may be a container or a container image. Furthermore, the status indicator for NF instances waiting to be deployed and having dependencies on one or more NF instances pending deployment is set to "WAIT_REGISTERING". Therefore, when the status indicator of an NF instance is updated to "REGISTERED", that NF instance can be considered to have been deployed by other NF instances. The deployed NF instance can be an NF service producer, which can provide services based on service requests from NF service consumers. In some examples, a network slice deployer can perform one or more steps of the techniques discussed herein. In other examples, a network management system capable of managing one or more components of a network architecture can perform at least some steps of the techniques discussed herein. In still other examples, the techniques discussed herein can be executed on a container orchestration platform, network nodes of a network architecture, or a computing device with a processor that executes instructions stored on storage media.
[0019] In some existing communication system standards (such as 5G), NF instances can have three states: "REGISTERED," "SUSPENDED," and "DISCOVERABLE." "REGISTERED" indicates that the NF instance is registered with the NRF and is discoverable by other NF instances. "SUSPENDED" indicates that the NF instance is registered with the NRF and is not operative but is discoverable by other NF instances. "DISCOVERABLE" indicates that the NF instance is registered with the NRF and is operative but is not discoverable by other NF instances.
[0020] As described above, this disclosure provides techniques for reliably deploying network slices at improved speed. To aid in reliable and improved NF instance deployment, three states and corresponding status indicators (i.e., "DEPLOYING", "WAIT_REGISTERING", and "UNDEPLOYING") are introduced. These status indicators can be recognized by both NRF and NF instances.
[0021] "DEPLOYING" can be interpreted by the NRF as an NF instance registered with the NRF, inoperable but discoverable by other NF instances. Other NF instances can interpret this status indicator as implying that an NF with the "DEPLOYING" indicator is awaiting deployment or that deployment is in progress. Furthermore, the status indicator of a given NF instance can subsequently be changed to "REGISTERED" during deployment. For example, an NF instance can discover other NF instances registered with the NRF with the "DEPLOYING" status and subscribe to being notified of the change in status indicator to "REGISTERED".
[0022] The state "WAIT_REGISTERING" can be interpreted by the NRF as meaning that the NF instance registered with the NRF is inoperable but discoverable by other NF instances. This status indicator can indicate to other NF instances that the NF instance is ready to be registered, but waits for the other NF instances it depends on to complete their deployment before doing so. Therefore, other NF instances can discover NF instances registered with the NRF with the state set to "WAIT_REGISTERING". Specifically, these other NF instances can subscribe to be notified of a state change when the status indicator changes to "REGISTERED".
[0023] According to the technology disclosed herein, an NF instance awaiting deployment of another NF instance can subscribe to the NRF to be notified of state changes of the NF instance to be deployed. Therefore, instead of repeatedly pinging the NRF to check for state changes, the NF instance can wait for notification of the state change by the NRF. Thus, the NF instance can avoid creating irrelevant information that might be caused by frequent pings, as the creation of unnecessary error logs is limited or eliminated. An NF instance awaiting deployment due to its dependency on another NF instance can update its state to "REGISTERED" based on discovering or being notified of a state change of the given NF instance. Therefore, the technology disclosed herein enables NF instances in a network slice to be deployed efficiently in parallel.
[0024] In some examples, an NF instance may wait for other NF instances due to its dependency on them. The waiting NF instance may be notified of a state change by the NRF, or the waiting NF instance may discover the NF instances(s) it is interested in at the NRF when their state changes. The examples provided below further illustrate NF instances that depend on each other for deployment. Even with such mutual dependencies between two NF instances, the techniques disclosed herein enable each NF instance in the NF instance set to register. Under conditions of mutual dependency, NF instances can discover each other and register. In one example, a first NF instance may be waiting for a second NF instance, where the first NF instance's state indicator is set to "WAIT_REGISTERING". The first NF instance can subscribe to be notified when the second NF instance's state indicator changes. Similarly, the second NF instance can query the NRF for the state of the first NF instance. Based on the response received from the NRF that the first NF instance is waiting for the second NF instance, where the first NF instance's state indicator is "WAIT_REGISTERING", the second NF instance can declare itself "REGISTERED". To declare its state indicator as "REGISTERED", the second NF instance can update its state indicator value at the NRF. Furthermore, the first NF instance can also declare itself "REGISTERED" at the NRF by updating its state indicator value there, thereby eliminating the deadlock condition between the first and second NF instances.
[0025] Furthermore, the technology can include deregistering one or more NF instances based on a determination that one or more NF instances in a set of NF instances have failed to deploy and were subsequently deregistered. Additionally, the network slice deployer can implement concurrent dedeployment of a set of instances in the same manner as concurrent deployment. In some examples, in response to the initiation of the network slice dedeployment process, the network slice deployer representing the NF instances can update the status indicator of each instance in the set at the NRF to "UNDEPLOYING," thereby causing the NF instances to be concurrently dedeployed.
[0026] Figure 1 A schematic diagram of a network architecture 100 in which various examples of this disclosure may be implemented is shown. Network architecture 100 illustrates selected, non-limiting components corresponding to a communication system. In one example, the communication system is a 5G communication system. In some other examples, the communication system may be associated with a fourth-generation (4G) or earlier, or a sixth-generation (6G) or later communication system.
[0027] In some examples, network architecture 100 can be scalable using agile infrastructure, which can be based on various architectural concepts. In one example, architectural concepts may include one or more of network function virtualization (NFV), container orchestration, software-defined networking (SDN), network slicing, etc. In some other examples, the aforementioned agile infrastructure may have infrastructure resources distributed from the edge to the cloud. As used herein, edge can refer to a location that is close to the data source. Furthermore, in the examples, communication systems may include network functions, applications, and / or services that can be deployed as workloads on distributed infrastructure resources. As used herein, infrastructure resources may include physical and / or virtual resources that support storage, processing, networking, communication, etc.
[0028] As mentioned above, in some examples, network architecture 100 may distribute resources, such as servers, across multiple data centers. According to... Figure 1 Illustrative examples are provided, and these data centers may include edge data center 105A, regional data center 105B, and central data center 105C. As used herein, an edge data center can refer to a data center that is closer to the data source compared to a traditional data center. A central data center may be farther from the data source compared to an edge data center. Regional data centers may be geographically and / or logically deployed between edge data centers and central data centers. Although... Figure 1 The network architecture 100 illustrates three data centers, but the number of data centers is not limited to the example shown and can include any number of data centers. Each data center may include physical or virtual resources to instantiate network functions corresponding to various network slices.
[0029] Furthermore, the communication system may include multiple network slices that can be supported by network architecture 100. Multiple network slices can be used to support diverse use cases based on customer needs and / or segmentation. Each network slice can utilize a portion of infrastructure resources. In the ongoing example, network architecture 100 includes multiple network slices 110A, 110B, ..., 110N. Each of these network slices 110A to 110N can be implemented using infrastructure resources deployed at one or more data centers 105A to 105C.
[0030] Based on some examples, network slices 110A to 110N can use NFV to instantiate various network functions onto virtual resources, as opposed to the traditional use of fixed resources. NFV can be used to manage the infrastructure resources required throughout the lifecycle of a network slice. Furthermore, SDN can be used to provision virtual resources located at the edge, regional, or central data centers 105A, 105B, or 105C. In one example, SDN can include an application layer, a control layer, and an infrastructure layer. The application layer enables the development of applications related to automation, configuration, management, monitoring, troubleshooting, policy, and / or network security. The infrastructure layer can manage basic network services, such as data forwarding and rule processing for the control plane. In another example, the application programming interface (API) of the control layer can be configured to handle traffic flows. Control plane functions can provide access to each other's services in a way that is a set of interconnected network functions.
[0031] Network architecture 100 can facilitate communication for various categories of user equipment (UEs) 115A to 115N. That is, each network slice can be customized to cater to a specific category of UE. In the illustrative example, the first network slice 110A caters to a cellular phone 115A for a UE. Similarly, the second and Nth network slices 110B and 110N cater to a motor vehicle 115B and a home automation 115N, respectively. As used herein, a UE can be any other communication device, such as a portable computing device, an IoT device, a sensing / metering device, a smart TV, a security device (e.g., a security camera), a vehicle control system, a network device, a remotely controlled aircraft (e.g., a drone), or any other device with communication capabilities.
[0032] Network architecture 100 may include a network slice deployer 130, which can be used for the dynamic deployment of network slices(s). Network slice deployer 130 may include a deployment pipeline with at least one of continuous integration (CI) and continuous deployment (CD) capabilities for loading network slices corresponding to network services. In one example, the network service may be provisioned entirely on cloud-native network resources. In another example, a combination of edge resources, data centers(s), and cloud-native resources may be used.
[0033] Furthermore, network architecture 100 may include a radio access network (RAN) communicatively coupled to the core network. Customers (e.g., users of a UE) can connect to the core network via the RAN. In one example, the RAN may include a base station 120, which may be a transceiver. Multiple UEs may establish one or more Packet Data Unit (PDU) sessions, which communicate via the base station. In a 5G communication system, the 5G core network (5GC) may be the associated core network, and the base station may be a gNodeB (gNB).
[0034] Furthermore, the core network may include multiple NFs configured to provide various data and / or telecommunications services. For example, the 5GC may include various NFs such as Access and Mobility Management Functions (AMF), Authentication Server Functions (AUSF), Policy Control Functions (PCF), Session Management Functions (SMF), User Plane Functions (UPF), Network Exposure Functions (NEF), Network Function Repository Functions (NRF), Unified Data Management (UDM), etc. One or more of these functions may operate according to 5G 3rd Generation Partnership Project (3GPP) standards (e.g., 3GPP Technical Specifications 29.502 and / or 29.518). One or more of these NFs may be instantiated to support PDU sessions for (multiple) UEs. In another example, NFV may be used to virtualize one or more NFs, which may be in the form of executable instructions stored in one or more computer-readable storage media.
[0035] Based on the techniques discussed herein, network slice deployer 130 can concurrently deploy NF instances of network slices. NF instances can be distributed across network architecture 100 based on various parameters (such as latency, data rate, bandwidth, cost, etc.). In an illustrative example, first network slice 110A includes two NF instances, NF3 1403 and NF4 1404, deployed in regional data center 105B. Second network slice 110B includes one NF instance, NF1 1411, deployed in edge data center 105A, and two NF instances, NF3 1413 and NF5 1415, deployed in central data center 105C. Nth network slice includes two NF instances, NF1 14N1 and NF2 14N2, deployed in edge data center 105A, one NF instance, NF4 14N4, deployed in regional data center 105B, and one NF instance, NF5 14N5, deployed in central data center 105C. As used in this article, an NF instance can be a standalone virtual or physical logical network function that can perform functions such as computing, storage, and network communication.
[0036] In some examples, network architecture 100 may include one or more network nodes deployed in various data centers. In one example, network node 150 deployed at edge data center 105A is shown. Network nodes may be physical resources, controllers, provisioning systems, container orchestration systems, etc. In one example, network node 150 may at least partially implement end-to-end services for network slices. In another example, network node may implement connectivity between the UE and the data network (DN). In the ongoing example, network node 150 may support the instantiation of at least one NF instance (e.g., NF114N1 and NF214N2 of the Nth network slice 110N). Network node 150 may include processor 155 and storage medium 160. Non-transitory type storage medium 160 may store instructions 170 to 178, which are executable by the processor to cause it to perform one or more actions. In the following, NF114N1 may be referred to as the "first NF instance" and NF214N2 may be referred to as the "second NF instance".
[0037] In some examples, processor 155 can execute registration instruction 170, which causes processor 155 to register each NF instance corresponding to network slice 110N at the NRF. In one example, the NF instances may include a set of NF instances 14N1 to 14N5. Each NF instance can be registered at the NRF with a corresponding status indicator of "DEPLOYING". This can indicate the initiation of concurrent deployment of a set of NF instances of network slice 110N. In one example, the NRF may be one NF instance among the NF instances, such as NF4 14N4.
[0038] Furthermore, processor 155 can execute determination instruction 172, which causes processor 155 to determine whether: a first NF instance 14N1 in a set of NF instances is awaiting deployment and whether the deployment of the first NF instance 14N1 depends on a second NF instance 14N2 in that set of NF instances that is awaiting deployment. In one example, the first NF instance 14N1 may depend on multiple NF instances of a network slice. Due to such dependencies, the first NF instance 14N1 may be deployed after the deployment of the NF instances that the first NF instance 14N1 depends on. As used herein, an NF instance can be considered deployed when its status indicator at the NRF is updated to "REGISTERED" and based on the deployments and traffic being handled by the particular NF instance.
[0039] Processor 155 can execute update instruction 174, which causes processor 155 to update the status indicator of the first NF instance 14N1 at the NRF to "WAIT_REGISTERING". This change to the "WAIT_REGISTERING" status indicates that the first NF instance 14N1 is waiting for the dependent NF instance(s) to complete its deployment (e.g., waiting for the second NF instance 14N2 to complete its deployment).
[0040] Processor 155 can execute subscription instruction 176, which causes processor 155 to subscribe to be notified of changes to the status indicator of the second NF instance 14N2. That is, the second NF instance 14N2 can update its status indicator in the NRF to "REGISTERED" when its deployment is complete, after which the first NF instance 14N1 can receive notification of such an update.
[0041] In response to a notification of a specific change in the status indicator of the second NF instance 14N2 (e.g., to “REGISTERED”), the processor 155 may execute a further update instruction 178, which causes the processor 155 to update the status indicator of the first NF instance 14N1 from “WAIT_REGISTERING” to “REGISTERED”. Updating the status indicator to “REGISTERED” indicates that the first NF instance 14N1 is discoverable by other NF instances at the NRF.
[0042] In some examples, each data center 105A, 105B, and 105C may include a network node with capabilities similar to those of network node 150, as discussed herein. Each network node may be configured to instantiate one or more NF instances of a network slice.
[0043] Figure 2 A flowchart illustrating a method 200 for deploying network slices according to various examples of this disclosure is shown. Although the execution of method 200 is described below with reference to the procedure, other suitable components for executing method 200 may be utilized. Additionally, the components for executing method 200 may be distributed across multiple systems / devices. In some examples, method 200 may be implemented in the form of executable instructions stored on a machine-readable storage medium and / or in the form of an electronic circuit system (e.g., hardware). In some other examples, the blocks of method 200 may be implemented substantially concurrently or in conjunction with… Figure 2 The order shown is different from the order of execution. In some other examples, method 200 may include additional boxes or skips. Figure 2 Some of the boxes shown. In some additional examples, some boxes in method 200 may be in progress and / or may be repeated at certain times.
[0044] At box 202, a set of NF instances for a network slice can be registered with the NRF. Each NF instance in this set can include a status indicator that is set to DEPLOYING after registration with the NRF. NF instances can be registered with the NRF, allowing other NF instances to request specific NF types or NF services from the NRF. An NF type can represent different types of NFs or network entities that can be found in the 5GC. NF services can be structured information, part of an NF profile created during NF instance registration. Furthermore, NF instances of the same NF type may support different NF services. In some examples, the NRF's NF discovery service can implement filtering of NF instances by NF services.
[0045] In some examples, the NRF can maintain NF profiles of available NF instances and their associated services. The NRF can support service discovery functionality to discover NF profiles registered with the NRF. The NF profile of an NF instance maintained at the NRF can include the NF instance ID, NF type, Network Slice Identifier (NSI) ID, NF capacity information, names of supported services, etc. For service discovery, the NRF can receive discovery requests from NF instances and respond to the requested NF instance with information associated with the discovered NF instance.
[0046] Furthermore, at box 204, the first NF instance in this set of NF instances can determine that its deployment (i.e., the deployment of the first NF instance) depends on the second NF instance in this set of NF instances. Additionally, the second NF instance may be awaiting deployment, with its status indicator set to "DEPLOYING". That is, according to some examples, the first NF instance may depend on the second NF instance, and since the second NF instance is awaiting deployment, the first NF instance may also be awaiting deployment. As used herein, "awaiting deployment" can indicate that an NF instance can set its status indicator to either "DEPLOYING" or "WAIT_REGISTERING". As used herein, dependency / dependency can indicate that for the deployment of a given NF instance, it may depend on other NF instances to complete their deployment first (e.g., a status indicator of "REGISTERED").
[0047] In box 206, in response to determining that (the first NF instance has a dependency on the second NF instance and the second NF instance is waiting for deployment), the first NF instance may update its status indicator from "DEPLOYING" to "WAIT_REGISTERING". According to some examples, the status indicator "WAIT_REGISTERING" can indicate to other NF instances that the first NF instance is waiting for the deployment of some other NF instance (in the ongoing example, the second NF instance).
[0048] In box 208, the first NF instance can subscribe at the NRF to be notified of changes to the state indicator of the second NF instance. In some examples, the first NF instance may depend on more than one NF instance in this set of NF instances. In such examples, the first NF instance can subscribe at the NRF to be notified of changes to the state indicator of each NF instance it depends on. According to some examples, the first NF instance can subscribe to be notified of changes to the state indicator of the second NF instance. In some examples, the first NF instance is particularly interested in being notified of changes to the state indicator to "REGISTERED". Whenever the state indicator of an NF instance (e.g., the second NF instance) changes, the NRF can notify the requesting NF instance (e.g., the first NF instance).
[0049] In box 210, when the deployment of the second NF instance is complete, the first NF instance can be notified of the change in the second NF instance's status indicator. In response to the notified change in status indicator, the first NF instance can update its status indicator in the NRF from "WAIT_REGISTERING" to "REGISTERED". This status change makes the first NF instance discoverable by other NF instances in the same group. In another example, other NF instances can now send service requests to the NRF to identify multiple NF instances that may be able to provide services of interest. In some examples, a third NF instance may be waiting for the first NF instance (with a status indicator of "WAIT_REGISTERING") to be deployed. The third NF instance can update its status indicator from "WAIT_REGISTERING" to "REGISTERED" in response to discovery by one or more NF instances (e.g., the first NF instance).
[0050] Furthermore, the method may include additional steps for efficient and concurrent deployment of NF instances. Based on the examples discussed herein, such additional steps can be analogous to various steps performed by a system, a processor executing instructions, a storage medium encoded with instructions that cause the processor to perform actions, or other execution devices.
[0051] Figure 3This is a block diagram of a network management system 300 according to various examples of this disclosure. In one example, the network function may be cloud-native and the network management system 300 may include cloud capabilities. In another example, the network function may be a containerized application, built as a stateless microservice deployed on a container orchestration platform (e.g., Kubernetes, Docker Swarm, etc.). Such cloud-native or container orchestration approaches enable more frequent and agile changes to the 5G core network. In some examples, the network functions may be handled at least partially by the network management system, network slice deployer, or computing device.
[0052] In some examples, the network management system 300 may be implemented by hardware, software, or a combination of hardware and software to instantiate various network functions of network slices. In some examples, the network management system may include processor-executable instructions stored on a non-transitory machine-readable storage medium (e.g., storage medium 310). In some examples, the instructions stored on storage medium 310 may be executable by a processing resource, which causes the processing resource to perform one or more operations according to this disclosure.
[0053] In the examples described herein, processing resources (e.g., processor 305) may include, for example, one or more processors, which may be included in a single computing device or distributed across multiple computing devices. As used herein, a "processor" may be at least one of a central processing unit (CPU), a semiconductor-based microprocessor, a graphics processing unit (GPU), or a field-programmable gate array (FPGA) configured to fetch and process execution instructions. In other examples, other electronic circuitry systems suitable for fetching and executing instructions stored on a computer-readable storage medium may be used.
[0054] In the examples described herein, processing resources can fetch, decode, and execute instructions 315 stored in machine-readable storage medium 310 to perform concurrent instantiation of network functions, as described herein. According to this disclosure, when executed by processor 305, instructions 315 can at least partially implement some or all of the functions of network management system 300. Hereinafter, for the sake of brevity, the network management system may be referred to as the “system”.
[0055] According to instruction 320, processor 305 of system 300 can register NF instances of a network slice at the NRF. System 300 achieves concurrent instantiation of NF instances by having each NF instance in a set of NF instances register a status indicator of "DEPLOYING" at the NRF. In some examples, system 300 can maintain the NRF. In some other examples, a separate network management system independent of system 300 can maintain the NRF. In some additional examples, each NF instance can send a registration message, such as "Nnrf_NFManagement_NFRegister" along with its NF profile. As used herein, an "NF profile" can provide several parameters of the NF instance, including an Internet Protocol (IP) address, a fully qualified domain name (FQDN), etc., to reach the NF instance. The NF profile may also include information about the services provided or otherwise exposed by the NF instance, an NF instance identifier (ID) for unique identification (e.g., a Universally Unique Identifier (UUID)), supported NF service instances, etc. In addition, registration can occur when the producer's NF instance and its(multiple) NF service instances first become operational.
[0056] According to instruction 322, the processor 305 of system 300 can determine that: the first NF instance in a group of NF instances is waiting to be deployed, and the deployment of the first NF instance depends on the second NF instance in the group of NF instances that is waiting to be deployed. When the status indicator is "DEPLOYING" or "WAIT_REGISTERING", the NF instance can be considered to be waiting to be deployed.
[0057] According to instruction 324, processor 305 of system 300 may update the status indicator of the first NF instance from "DEPLOYING" to "WAIT_REGISTERING" in response to determining that the first NF instance has a dependency on the second NF instance and that the second NF instance is awaiting deployment. In some examples, the first NF instance may depend on multiple NF instances and may wait for those multiple NF instances to complete their deployment.
[0058] According to instruction 326, the processor 305 of system 300 can subscribe at the NRF to be notified of changes in the state indicator of a second NF instance. In some examples, the first NF instance may depend on multiple NF instances; therefore, the first NF instance can subscribe to being notified of state changes of each of the multiple NF instances. Thus, when there is a state change of each of the multiple NF instances, the NRF can notify the first NF instance. Preferably, the NRF can notify the requesting NF instance when the state indicator of the NF instance(s) of interest changes to "REGISTERED".
[0059] According to instruction 328, in response to a specific change in the status indicator of the notified second NF instance, the processor 305 of the network management system 300 can update the status indicator of the first NF instance from "WAIT_REGISTERING" to "REGISTERED". With the status indicator updated, the first NF instance can indicate that it can be discovered by other NF instances in that group of NF instances. In one example, other NF instances can send a query to the NRF related to a service request to identify the first NF instance that may be able to provide the requested service.
[0060] Figure 4A Schematic diagrams illustrating the deployment of various NF instances of network slices according to various examples of this disclosure are shown. In some examples, a network slice may include a set of network functions 440A to 440G. Network functions may be virtualized or containerized functions using a selected platform, such as a VNF or container orchestration platform. In some examples, a virtualized Infrastructure Manager (VIM) may be used to run this set of network functions. Management and Orchestration (MANO) may monitor the network functions deployed on the network. Continuous Integration and Continuous Deployment pipelines may be used to manage network functions on the VIM using MANO components. In some examples, a network slice deployer 430 may implement the concurrent deployment of a set of NF instances in accordance with the techniques disclosed herein.
[0061] In the illustrative examples, NF instances 440A to 440G may correspond to NF instances of a 5G network slice. Therefore, NF instances may include UDM 4401, NEF 4402, AMF 4403, SMF 4404, UPF 4405, PCF 4406, Authentication Server Function (AUSF) 4407, Unified Data Repository 4408, and NRF 445. One or more of these NF instances may depend on other NF instances. In some examples, an NF instance such as UDM 4401 may have a dependency on an NF instance such as UDR 4408. In one example, UDR 4408 may store different types of data, such as subscription, policy, structured, and application data. These data formats may be provided by UDR 4408 to UDM 4401. For example, UDM 4401 may store and retrieve subscription data from UDR 4408, thus UDM 4401 may have a dependency on UDR 4408.
[0062] exist Figures 4B to 4F The illustrative examples discuss techniques for concurrent deployment of NF instances. Figures 4B to 4FIn this context, the first NF instance can be an NF service consumer, and the second NF instance can be an NF service producer. As used herein, an NF service consumer can discover a target NF service producer via NRF. As used herein, an NF service producer can provide services to service requests from an NF service consumer.
[0063] Figure 4B Schematic diagrams illustrating the deployment of various NF instances for registration in an NRF, according to various examples of this disclosure. In some examples, the network slice deployer can concurrently instantiate a set of NF instances corresponding to the network slice being deployed (e.g., Figure 4A NF instances 4401 to 4408, 445). Each NF instance in this group can register its profile (4501, 4502, ..., 450N) in NRF 445. In some examples, a group of NF instances can use the "NFRegister" service operation defined for the Nnrf_NFManagement service. NFRegister enables NF instances to register their profiles at NRF 445. Profile registration can include the registration of general parameters of the NF instance and a list of potential services exposed by the NF instance.
[0064] Furthermore, each NF instance being deployed in a network slice can register at NRF 445 as 4501, 4502, ..., 450N, with their corresponding status indicator set to "DEPLOYING". As mentioned above, an NF instance ID can be used to uniquely identify each NF instance in a set of NF instances. For brevity, the NF instance ID may be referred to as the "instance ID" below. In some examples, an NF instance can be registered at the NRF by sending a PUT request for a given NF instance. In one example, the PUT request may include a payload body containing a representation of the given NF instance being registered. As used herein, according to this disclosure, a "PUT" message can be Hypertext Transfer Protocol (HTTP) communication used for service request / response in a Service-Based Architecture (SBA).
[0065] Based on some examples, the status indicator for each NF instance set to "DEPLOYING" in a set of NF instances indicates that, from the perspective of NRF 445, the NF instance registered at NRF 445 is inoperable, but other NF instances can discover that particular NF instance. From the perspective of (or more) other NF instances regarding a given NF instance, the NF instance is either waiting to initiate a deployment process or the deployment process is in progress, and the status indicator can be changed to "REGISTERED" upon deployment. The value of the status indicator specifies the current state of the NF instance; therefore, the status indicator value is updated to a value indicating the current state of the NF instance.
[0066] According to the illustrative example, based on the successful registration of an NF instance, the network slice deployer can receive a PUT response 4511. In some examples, the PUT response 4511 may include a "201 created" response with a payload body containing a representation of the created resource (e.g., a complete or partial NF profile). "201 created" is an HTTP response indicating that the request has been satisfied. The network slice deployer 430 can receive a PUT response 4511 for each NF instance registered at NRF 445; however, for brevity, in the illustrative example... Figure 4B The example only depicts a PUT response. In some examples, the NRF 445 may send a "heartbeat timer" along with the PUT response, where the heartbeat timer can indicate the duration expected by the NRF 445 between two consecutive heartbeat messages from a given NF instance.
[0067] Figure 4C A schematic diagram illustrating communications for discovering NF instances at NRF 445 according to various examples of this disclosure is shown. According to some examples, a first NF instance 451 (NFIDInstance-1) may send a discovery request 4601 to NRF 445 to discover services provided by NF instances registered at NRF 445. According to an illustrative example, the first NF instance may send an "NFDiscovery" ("NF Discovery") service request 4601, which enables the NF instance to discover (or more) other NF instances with potential services provided. The first NF instance 451 may be an NF service consumer and is identifiable by its instance ID. The first NF instance 451 may receive a response (e.g., "200") 4602 from NRF 445 upon successful identification of the NF service. Furthermore, the body of the response may include an NF profile (e.g., NF profile ID-2) corresponding to the NF instance identified in the request (e.g., a second NF instance). Additionally, NRF 445 may indicate the current status indicator value of the requested NF instance in the response.
[0068] Furthermore, the first NF instance 451 can subscribe 4603 to be notified at NRF 445 of changes in the state of the second NF instance. According to an illustrative example, the first NF instance 451 can send a subscription request 4603 at NRF 445, such as “NFStatusSubscribe” (“NF Status Subscription”). In one example, the first NF instance performs a subscription operation by sending a POST request to NRF 445. The POST request can create a new subscription for notifications related to changes in the state indicators of(multiple) specified NF instances. In some examples, NRF 445 may include a storage device 446 configured to store subscription requests 447 received from various NF instances.
[0069] According to another example, the body of the subscription request may include the type of notification that the first NF instance, as an NF service consumer, might be interested in receiving. The notification of interest may relate to state change information of one or more NF instances that the NF service consumer depends on. Furthermore, the request may include a Uniform Resource Identifier (URI) where the first NF instance 451 can be prepared to receive notifications. In some examples, along with the request, the NF instance may transmit a validity period, which indicates the expected duration for which its subscription will be active. After the duration expires, the requesting NF instance may not receive further state indicator notifications. Therefore, the NF instance may have to send a new subscription request to be notified of changes in state indicators. Additionally, in one example, the subscription request may include a list of attributes that can be monitored in the NF profile, such that notifications can be sent when any of the listed attributes change. Furthermore, the first NF instance 451 may subscribe to be notified of multiple NF instances. Upon successful subscription, the first NF instance 451 may receive a response (e.g., 200) 4604 from NRF 445. Response 4604 may include subscription-related data (e.g., subscription data).
[0070] The first NF instance 451 can update its status indicator 4605 at NRF 445 to "WAIT_REGISTERING". As used herein, "WAIT_REGISTERING" can refer to a status indicator interpreted by NRF 445, meaning that the given NF instance registered at NRF 445 is not operational but can be discovered by other NF instances. However, other NF instances might interpret this status indicator as meaning that the given NF instance is ready to be registered but is waiting for other NF instances that the given NF instance depends on to complete deployment so that their status indicators can be updated to "REGISTERED". An NF instance is considered operational / started when it begins processing network traffic. Updating the status indicator can include changing the status indicator of the first NF instance 451 from "DEPLOYING" to "WAIT_REGISTERING".
[0071] In some examples, the first NF instance 451 may use the "NFUpdate" ("NF Update") service operation to update the status indicator. This service operation can be used to update the NF profile of the first NF instance 451 by providing an updated NF profile with appropriate changes. In some examples, depending on the type of update, the first NF instance 451 may send a PUT / PATCH HTTP request. The PUT request may update the entire NF profile using the payload body of the PUT request containing the latest NF profile, which must completely replace any NF profile that may have been presented earlier. However, the PATCH request may partially update the NF profile. After a successful update of the status indicator, the NRF 445 may send a response (e.g., "200") 4606 to the first NF instance 451. In the event that updating the status indicator fails, the first NF instance 451 may receive an error code associated with the failure. Furthermore, the first NF instance 451, which depends on the second NF instance 452, may wait to be notified by NRF 445 instead of sending continuous requests to NRF 445, which may cause irrelevant alerts such as errors, traces, and / or logs.
[0072] Based on various examples of this disclosure Figure 4D Another schematic diagram illustrates the communication discovery of NF instances at NRF 445. Upon instantiation of a given NF instance, NRF 445 can send a notification (e.g., NFStatusNotify) 4611 to the NF instance that has previously subscribed to changes in the notified status indicator. Figure 4DAs an illustrative example, the first NF instance 451 may receive a notification 4611 from NRF 445 regarding a change in the state of the second NF instance 452. In another example, the NRF may notify the NF instance at a specified URI during the subscription process. The body of the notification may include a reference to the NF instance with a changed state indicator. NRF 445 may indicate the event type as "NF_PROFILE_CHANGED" ("NF_profile_changed") in the notification received by the first NF instance 451. In some cases, the first NF instance 451 may receive the entire profile with the change or details of a specific change in the profile. Upon receiving the notification, the first NF instance 451 may send a response 4612 to NRF 445. In one example, the response may be "204" (No Content), an HTTP status code indicating that the request has been satisfied and that there is no additional content to be sent in the response body.
[0073] Furthermore, in response to being notified of a change in the status indicator of the second NF instance 452, the first NF instance 451 can update 4613 its status indicator at NRF 445. That is, according to one example, the first NF instance 451 can send an update request (e.g., “NFUpdate”) 4613 to NRF 445 to change the status indicator from “WAIT_REGISTERING” to “REGISTERED”, making the first NF instance 451 discoverable by other NF instances. As discussed in the previous examples, the “NFUpdate” service request can update the NF profile of the first NF instance 451 by providing an updated NF profile with the appropriate changes. After a successful update of the status indicator, NRF 445 can send a response (e.g., “200”) 4614 to the first NF instance 451.
[0074] Furthermore, the first NF instance 451 can utilize the service through direct communication with the second NF instance 452. According to the ongoing example, for direct communication, the first NF instance 451, which may be an NF service consumer, discovers a target NF service producer, which may be the second NF instance 452. Therefore, the first NF instance 451 can send a service request 4615 to the second NF instance 452. In response, the first NF instance 451 can receive a service response 4616 from the second NF instance 452.
[0075] Figure 4E A schematic diagram illustrating communication between an NF instance and an NRF 445 according to various examples of this disclosure is shown. According to one example, a first NF instance 451 may depend on a second NF instance (e.g., Figure 4D(The second NF instance 452). In one example, an NF service consumer (such as the first NF instance 451) can send a discovery request to NRF 445 to discover NF service producers based on potential services offered by the NF service producers. In some cases, the first NF instance 451 can wait for the second NF instance 452 to complete instantiation so that the first NF instance 451 can begin operations.
[0076] However, under certain conditions, the instantiation of an NF instance may fail during deployment. For example, an NF instance may have a status indicator of "DEPLOYING" when instantiation fails. The deployer (e.g., Figure 1 The network slice deployer 130 can receive information about such failures. However, according to certain existing processes, the NF service consumer may not be aware of such a failure and may continue to wait for the NF instance to complete instantiation. According to some examples of this disclosure, the NF service consumer can subscribe at NRF 445 to be notified of changes in the status indicator of the NF instance it may be waiting for. Thus, when the instantiation of an NF instance (e.g., the second NF instance 452) subscribed to by another NF instance (e.g., the first NF instance 451) has failed, the first NF instance 451 can receive a notification request 4621 from NRF 445 indicating that the second NF instance 452 is “DEREGISTERED”. The change of the status indicator to “DEREGISTERED” can indicate that a particular NF instance has been deregistered from NRF 445 due to instantiation failure or one or more other conditions that cause deregistration. The notification request 4621 may include the status indicator value “NF_DEREGISTERED”. The first NF instance 451 can receive multiple deregistration notifications from the second NF instance 452 from the NRF 445, and the notification request body can include the instance ID of the deregistered NF instance. Upon receiving the notification request, the first NF instance 451 can send a response 4622 to the NRF 445. In one example, the response could be "204" (no content).
[0077] In addition, the first NF instance 451 can send a deregistration request 4623 to NRF 445. In one example, the deregistration request can be a "Deregister" service request. The deregistration request enables the first NF instance 451 to unregister its NF profile at NRF 445. Deregistration can include unregistering services provided by the first NF instance 451 from NRF 445. When sending the deregistration request, the first NF instance 451 can receive a response 4624 from NRF 445. In one example, the response can be "204" (No Content), indicating that no data is included in the response body.
[0078] Figure 4F A schematic diagram illustrating communication between interdependent NF instances according to various examples of this disclosure is shown. Specifically, according to one example, a first NF instance 451 may have a dependency on a second NF instance 452 and may wait for the second NF instance 452 to be instantiated. The first NF instance 451 may wait for the second NF instance 452 to be "REGISTERED". Similarly, the second NF instance 452 may depend on the first NF instance 451 and may wait for the status indicator of the first NF instance 451 to be "REGISTERED". Traditionally, deadlock conditions may occur due to such interdependencies.
[0079] According to some examples of this disclosure, a first NF instance 451 and a second NF instance 452 can be instantiated concurrently. The first and second NF instances 451 and 452 can be registered at NRF 445 with their status indicators set to "DEPLOYING". Furthermore, the first NF instance 451 can send a discovery request to NRF 445 for the second NF instance 452. The first NF instance 451 can receive a response from NRF 445 including the status indicator information of the second NF instance 452. Based on the condition that the status indicator of the second NF instance 452 can also be "DEPLOYING", the first NF instance 451 subscribes to be notified of changes to the status indicator of the second NF instance 452. Additionally, the first NF instance 451 can update its status indicator to "WAIT_REGISTERING". The above process can be similar to... Figure 4C The process 4601 to 4606 is detailed in the example description.
[0080] Similarly, the second NF instance 452 can send a discovery request 4631 to NRF 445. The second NF instance 452 can receive a response (e.g., "200") 4632 from NRF 445. The body of the response from NRF 445 may include profile information corresponding to the first NF instance 451, where the status indicator of the first NF instance 451 may also be "WAIT_REGISTERING". Based on the condition that the status indicators of the first NF instance 451 and the second NF instance 452 are both "WAIT_REGISTERING", the second NF instance 452 can determine that a deadlock condition may exist. In response to the determination of a possible deadlock condition, the second NF instance 452 can send an update request 4633 to NRF 445, updating the status indicator to "REGISTERED". The second NF instance 452 can receive a response 4634 from NRF 445, where the response may be "200", which is an HTTP success status response code indicating a successful request.
[0081] In response to the change in the status indicator of the second NF instance 452 from “WAIT_REGISTERING” to “REGISTERED”, the first NF instance 451 can receive a notification 4635 from NRF 445. The first NF instance 451 can send a response 4636 to NRF 445. In one example, the notification from the NRF indicates that the status indicator of the first NF instance 451 has changed, and thus enables the first NF instance 451 to update its status indicator. The first NF instance 451 can then send an update request 4637 to NRF 445 to update the status indicator to “REGISTERED”. NRF 445 can send a response 4638 to the first NF instance 451. Therefore, NF instances 451 and 452, which have mutual dependencies, can be deployed concurrently for registration at the NRF, and (multiple) NF instances can identify possible deadlock conditions and avoid them in the manner described in the examples discussed herein. In another example, the first NF instance 451 can send a service request 4639 to the second NF instance 452, and the first NF instance 451 can receive a response 4640 from the second NF instance 452.
[0082] Figure 5 A flowchart illustrating the deployment of network slicing according to various examples of this disclosure is shown. The flowchart's frames can be composed of, for example... Figure 3 The network management system 300 can be executed on a single system or distributed across multiple systems / devices. In one example, flowchart 500 can be implemented as executable instructions stored on a machine-readable storage medium and / or as an electronic circuit system (e.g., hardware). According to some examples, one or more blocks of flowchart 500 can be implemented with... Figure 5The different sequences shown are executed substantially concurrently. In some other examples, one or more boxes may be skipped and may be performed and / or repeated at specific times. In some examples, the boxes of flowchart 500 may be stored as instructions in the system's storage medium (e.g., Figure 3 The network management system 300). Such instructions can be generated by processing resources (e.g., Figure 3 The processor 305) executes, causing the processing resources to perform one or more steps discussed herein.
[0083] In box 505, a network slice deployer can initiate the deployment of a network slice. In one example, the network slice deployer may have CI and / or CD capabilities. In some examples, a network slice may include a set of NF instances. In some other examples, a network slice may also include NRFs as part of a set of NF instances being deployed.
[0084] In box 510, the network slice deployer can determine whether a network slice includes an NRF and whether the NRF has been deployed. In this document, the terms "deployed" and "installed" are used interchangeably. Deployed / installed can indicate that an NF workload (which may be a collection of files describing an associated set of container orchestration resources (e.g., Helm diagrams or operator-defined resources)) has been instantiated on a target runtime environment (e.g., Kubernetes, Docker Swarm, etc.). Furthermore, an NF instance is considered to have started when the processes that compose the NF application have been started (e.g., the associated containers may be running in a Kubernetes pod).
[0085] In box 515, based on the condition that the NRF is part of a network slice (i.e., the "yes" condition in box 510), the network slice deployer can deploy the NRF first. That is, the deployment of the NRF can be prioritized before the deployment of other NF instances of the network slice. In some examples, flowchart 500 may include additional boxes to determine whether the NF management service endpoint of the NRF is configured to be deployed by the network slice deployer (e.g., ...). Figure 1 The network slice deployer 130) is connected. After the NF management service endpoint is configured to be accessible by the network slice deployer, this set of NF instances will be registered in NRF on their behalf for concurrent deployment.
[0086] In box 520, based on the determination that network slicing does not include NRF (i.e., the "No" condition at box 510) and that NRF is instantiated, the network slice deployer can register a set of NF instances at the NRF. In some examples, NF instances are considered registered when the NF application has already performed an initialization phase before processing network traffic. Furthermore, after performing the initialization phase, NF instances can declare operational readiness by registering at the NRF.
[0087] In box 525, each NF instance in a group of NF instances registered with the NRF sets its status indicator at the NRF to "DEPLOYING". The NRF considers such NF instances to be registered and inactive, but (multiple) NF instances can be discovered by other NF instances. (Multiple) other NF instances will regard NF instances with the status value "DEPLOYING" as waiting to initiate a deployment process or in the process of deployment, and the status indicator may change to "REGISTERED" during deployment.
[0088] In box 530, the deployment of each NF instance in a set of NF instances is checked. As used in this document, an NF instance can be considered deployed when the workload of a particular NF instance has already been instantiated on the target runtime environment. In one example, the target runtime environment could be a container orchestration platform.
[0089] In box 535, the deployment of a particular NF instance is considered to have failed based on the condition that a particular NF instance has not been deployed (i.e., the "No" condition at box 530). In the following text, in this current example, this particular NF instance may be referred to as the "first NF instance" for ease of reference.
[0090] In box 540, the first NF instance that has failed to deploy can be deregistered from the NRF by the network slice deployer. In some examples, a second NF instance in this set of NF instances may have a dependency on the first NF instance. In response to the failure of instantiation of the first NF instance, the second NF instance can be notified of a state change. The second NF instance can be deregistered from the NRF from its NF profile. Furthermore, the second NF instance can be shut down.
[0091] However, in box 545, based on the condition that the first NF instance has been deployed (i.e., the "yes" condition at box 530), it can be determined whether the first NF instance is waiting for (multiple) other NF instances that are to be deployed. This can determine whether the first NF instance depends on one or more NF instances.
[0092] In box 550, based on the condition that the first NF instance is not waiting for any other NF instance (i.e., the "No" condition in box 545), the first NF instance can update its status indicator in the NRF to "REGISTERED". Since there are no dependencies, the first NF instance completes registration and can be used to consume network traffic.
[0093] In box 555, based on the condition that the first NF instance is waiting for (multiple) other NF instances (i.e., the "Yes" condition at box 545), the first NF instance updates its status indicator in the NRF to "WAIT_REGISTERING". In other words, the first NF instance can update its status indicator from "DEPLOYING" to "WAIT_REGISTERING" to indicate to other NF instances that it is waiting for the deployment of (multiple) other NF instances it depends on.
[0094] In box 560, the first NF instance can subscribe at the NRF to be notified of changes in the state of(multiple) other NF instances at the NRF. As previously described, the first NF instance can send a subscription request by transmitting a POST request to the NRF. The POST request can create new subscriptions for(multiple) notifications related to changes in the state indicators of(multiple) NF instances(s) specified in the request.
[0095] In box 565, NRF can determine whether the state indicators of one or more NF instances that the first NF instance depends on have changed. Based on the determination that the state of (multiple) NF instances has not changed (i.e., the "No" condition at box 565), NRF can wait for the state to change.
[0096] In box 570, based on the condition that the state indicator of the first NF instance has changed (i.e., the "Yes" condition in box 565), the first NF instance can be notified of the change in the state indicator by the NRF. In response to the specific change in the notified state indicator (e.g., to "REGISTERED"), the first NF instance can update its state indicator from "WAIT_REGISTERING" to "REGISTERED". With the state change of the first NF instance, it can be discovered by other NF instances for use in service requests.
[0097] Figure 6 A block diagram depicts a storage medium 610 storing instructions executable by processor 605 according to various examples of this disclosure. Furthermore, it should be understood that although various instructions are shown to coexist within a single processing unit, in some examples multiple processing units may be used, and one or more instructions may be executed remotely from other instructions. In some examples, instructions 620 to 628 may be encoded on storage medium 610.
[0098] In some examples, instruction 620 is executable by processor 605 to register a set of NF instances of a network slice at the NRF. Each NF instance in the set of NF instances can be registered at the NRF with a status indicator of "DEPLOYING".
[0099] In some examples, instruction 622 is executable by processor 605 to determine that: a first NF instance in a set of NF instances is waiting to be deployed; the deployment of the first NF instance depends on a second NF instance in the set of NF instances that is awaiting deployment. An NF instance can be considered awaiting deployment when the status indicator is "DEPLOYING" or "WAIT_REGISTERING".
[0100] In some examples, instruction 624 is executable by processor 605 to update the status indicator of the first NF instance from “DEPLOYING” to “WAIT_REGISTERING” in response to determining that the first NF instance has a dependency on the second NF instance and that the second NF instance is pending deployment.
[0101] In some examples, instruction 626 is executable by processor 605 to subscribe at the NRF to be notified of changes to the state indicator of the second NF instance. In some examples, the first NF instance may depend on multiple NF instances; therefore, the first NF instance may subscribe to be notified of state changes of each of the multiple NF instances. Instruction 626 can cause the first NF instance to subscribe to be notified of changes to the state indicator. Thus, when the state of each of the multiple NF instances changes, the NRF can notify the first NF instance.
[0102] In some examples, instruction 628, executable by processor 605, updates the status indicator of a first NF instance from "WAIT_REGISTERING" to "REGISTERED" in response to a specific change in the notified status indicator. This specific change could occur when the status indicator changes to "REGISTERED". Furthermore, as the status of the first NF instance changes, the first NF instance can indicate that it is discoverable by other NF instances in that set of NF instances. In one example, other NF instances can now send queries to the NRF related to service requests to identify NF instances that may be able to provide the requested service.
[0103] Generally, as used herein, the terms "component," "system," etc., can refer to logic embodied in hardware or firmware, or to a set of instructions written in a programming language that may have entry and exit points. It will be understood that software components can be invoked from other components or from themselves, and / or can be invoked in response to detected events or interrupts. Software code may be stored, in whole or in part, on a memory device executing the computing device. Software instructions may be embedded in firmware, such as erasable programmable read-only memory (EPROM). It will also be understood that hardware components may include interconnected logic units, such as gates and flip-flops, and / or may include programmable units, such as programmable gate arrays or processors.
[0104] As used herein, the term “or” may be interpreted as inclusive or exclusive. Furthermore, descriptions of resources, operations, or structures in the singular form should not be construed as excluding the plural form. Conditional language, such as “may,” “might,” or “possibly,” unless otherwise specified or otherwise understood in the context in which they are used, is generally intended to convey that certain examples include certain features, elements, and / or steps that are not included in other examples. Unless otherwise expressly stated, the terms and phrases used in this document and their variations should be interpreted as open-ended rather than restrictive. Adjectives such as “traditional,” “known,” and terms with similar meanings should not be interpreted as limiting the described items to those available for a given period or time, but should be understood to include traditional, conventional, or standard techniques. In some cases, the presence of extended words and phrases (such as “one or more,” “at least,” “but not limited to,” or other similar phrases) should not be construed as implying that the narrower scope is intended or required where such extended phrases may not exist.
Claims
1. A method comprising: A set of network function (NF) instances of a network slice are registered at the Network Function Repository Function (NRF), each of the set of NF instances having a status indicator set to DEPLOYING; Sure: The first NF instance in the group of NF instances is waiting to be deployed; as well as The deployment of the first NF instance depends on the second NF instance in the group of NF instances that are to be deployed; In response to the determination, the status indicator of the first NF instance is updated from DEPLOYING to WAIT_REGISTERING to indicate to other NF instances in the group of NF instances, other than the first NF instance, that the first NF instance is waiting for the deployment of the second NF instance before deployment; Subscribe to the first NF instance via the NRF to be notified of changes to the state indicator of the second NF instance; as well as In response to a specific change in the status indicator of the second NF instance, the status indicator of the first NF instance is updated from WAIT_REGISTERING to REGISTERED, so that the first NF instance can be discovered by other NF instances in the set of NF instances besides the first NF instance.
2. The method according to claim 1, further comprising: Based on the determination that the NRF is part of the network slice, the Network Function Repository Function NRF is deployed prior to the registration of the set of NF instances.
3. The method according to claim 2, further comprising: Based on the condition that the NRF is deployed during the deployment of the set of NF instances in the network slice, the NF management service endpoint of the NRF is configured such that the NF management service endpoint is accessible by the network slice deployer, wherein the network slice deployer is configured to perform automatic deployment of the network slice.
4. The method of claim 1, wherein registering the set of NF instances further comprises: Instantiate the set of NF instances as virtualization functionality on the platform; In response to the failure of instantiation of the first NF instance in the set of NF instances, the network function NF profile of the third NF instance in the set of NF instances is deregistered. The third NF instance depends on the first NF instance and is waiting for the first NF instance to complete registration. as well as Shut down the third NF instance.
5. The method according to claim 1, further comprising: In response to the initiation of the network slice de-deployment process, the status indicator of each NF instance in the group of NF instances at the NRF is updated to UNDEPLOOYING, so that the group of NF instances are de-deployed concurrently.
6. The method according to claim 1, further comprising: It is determined that the first NF instance and the second NF instance are deployment dependencies; The first NF instance queries the status indicator of the second NF instance; Based on the condition that the status indicator of the second NF instance is WAIT_REGISTERING, the first NF instance updates the status indicator to REGISTERED; and Based on the condition that the first NF instance is registered, the status indicator of the second NF instance is updated to REGISTERED at the NRF.
7. The method of claim 1, wherein registering the set of NF instances at the NRF comprises: The NRF is provided with an NF profile for each of the set of NF instances, wherein each NF profile includes a list of services provided by the specific NF instance.
8. The method of claim 1, wherein in response to the discovery of one or more NF instances to be deployed, the status indicator of the third NF instance is updated from WAIT_REGISTERING to REGISTERED.
9. The method of claim 1, wherein the status indicator having the value REGISTERED indicates that the NF instance is registered at the NRF and can be discovered by other NF instances.
10. The method of claim 1, wherein the status indicator having the value DEPLOYING indicates that the NF instance is waiting to initiate a deployment process or that a deployment process is in progress, and the status indicator changes to "REGISTERED" upon deployment.
11. The method of claim 1, wherein the status indicator having the value WAIT_REGISTERING indicates that the NF instance is ready to be registered and is waiting for other NF instances it depends on to complete deployment before it completes its deployment.
12. The method of claim 1, wherein the set of NF instances is concurrently deployed by a network slice deployer with continuous deployment CD capability for registration at the NRF.
13. The method according to claim 1, further comprising: The first NF instance updates the status indicator from DEPLOYING to REGISTERED based on the condition that the first NF instance has been deployed and has started processing network traffic of the network slice.
14. A system comprising: processor; as well as A storage medium, operatively connected to the processor and storing instructions that, when executed, cause the processor to: Register a set of network function (NF) instances at the network function repository (NRF) where the status indicator of each NF instance in the set of NF instances is set to DEPLOYING, wherein the set of NF instances is part of a network slice. Based on the condition that the first NF instance in the group of NF instances is in a waiting state to be deployed and the first NF instance has a dependency on one or more NF instances in the group of NF instances that are waiting to be deployed, the status indicator of the first NF instance is updated to WAIT_REGISTERING. Subscribe to be notified to the first NF instance of changes to the status indicator of one or more NF instances that are pending deployment in the group of NF instances; as well as In response to a specific change in the status indicator of one or more NF instances that are pending deployment in the set of NF instances, the status indicator of the first NF instance is updated from WAIT_REGISTERING to REGISTERED, so that the first NF instance can be discovered by the other NF instances in the set of NF instances.
15. The system of claim 14, wherein the instructions for causing the processor to subscribe to notifications further include instructions for causing the processor to perform the following operations: At the first NF instance, a notification is received from the NRF regarding a change in the status indicator of one or more NF instances that are pending deployment in the group of NF instances at the NRF.
16. The system of claim 14, wherein the system includes a network slice deployer to concurrently deploy the set of NF instances.
17. A non-transitory storage medium for storing instructions, said instructions being executable by a processor to: Based on the determination that the Network Function Repository Function (NRF) is part of a network slice being deployed and that the NRF is pending deployment, the NRF is deployed first. At the NRF, a set of registered network function (NF) instances are provided, and the status indicator of each NF instance in the set of NF instances is set to DEPLOYING, wherein the set of NF instances is part of the network slice. Based on the condition that the first NF instance in the group of NF instances is in a waiting state to be deployed and the first NF instance depends on one or more NF instances in the group of NF instances that are waiting to be deployed, the status indicator of the first NF instance is updated to WAIT_REGISTERING. Subscribe to be notified to the first NF instance of changes to the status indicator of one or more NF instances that are pending deployment in the group of NF instances; as well as In response to a specific change in the status indicator of one or more NF instances that are pending deployment in the set of NF instances, the status indicator of the first NF instance is updated from WAIT_REGISTERING to REGISTERED, so that the first NF instance can be discovered by the other NF instances in the set of NF instances.
18. The non-transitory storage medium of claim 17, wherein the instructions for registering the set of NF instances at the NRF include instructions to: Concurrently register the set of NF instances at the NRF; and Based on the deployments and traffic being processed by the one or more NF instances, update the status indicator of one or more NF instances in the set of NF instances to REGISTERED.
19. The non-transitory storage medium of claim 17, wherein each NF instance in the set of NF instances is uniquely identifiable based on a universally unique identifier (UUID).
20. The non-transitory storage medium of claim 17, wherein the instructions further include instructions to: Instantiate the set of NF instances as virtualization functionality on the platform; Based on the failure of instantiation of the first NF instance in the aforementioned set of NF instances, the second NF instance, which was waiting for the first NF instance to complete registration, cancels its registration; and Shut down the second NF instance.
Citation Information
Patent Citations
Management methods for network function information and related equipment
CN109379206A
Method and apparatus for service registration and service discovery
WO2022062920A1