Standardized custom resource definition for lifecycle management of cloud-native network functions

Abstract

Example embodiments of the present disclosure relate to standardized custom resource definitions for life cycle management of cloud-native network functions. The method may include receiving, by an orchestration and management entity, a customized resource (CR) based on a standardized custom resource definition (CRD) schema from a management system for a network; and managing, by the orchestration and management entity, a first set of one or more network function (NF) workload(s) of the network based on the standardized CRD schema.

Description

STANDARDIZED CUSTOM RESOURCE DEFINITION FOR LIFECYCLE MANAGEMENT OF CLOUD-NATIVE NETWORK FUNCTIONSTECHNICAL FIELD

[0001] The present disclosure relates to standardized custom resource definitions for lifecycle management of cloud-native network functions.BACKGROUND

[0002] The information disclosed in this background section is only for the enhancement of understanding of the general background of the disclosure and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person skilled in the art.

[0003] In large scale cloud deployments for telecommunications networks, a management system may convey declarative descriptions of network function (NF) deployment requirements to an orchestrator for creation, modification and termination of cloud-native NF’s. The descriptor may include the requirements (e.g. artifacts, metadata, interface endpoints, performance requirement etc.) for the orchestrator to select, configure or modify the appropriate cloud resources to host the workload(s) of the cloud-native NF. Declarative systems continuously evaluate the current state, determine the steps to realize the intended state as described in the descriptor, and then reconcile those states by modifying the current state.

[0004] In the related art, a container-based cloud-native orchestration system (such as Kubemetes) may define a Custom Resource Definition (CRD) which implements the above principle. It may typically be a schema-driven mechanism which allows for creation of customized objects on the API server. The customized object is associated with an operator which handles theimperative NF orchestration procedures to fulfdl the declarative requirements defined in the custom resource model.

[0005] For example, the user may make modifications to the CRD, which represents the desired future state of the NF. The operator may receive state change events from the CRD, and update the status in the CRD accordingly. The orchestrator may use the CRD to adjust the current state of the NF to match the desired future state of the NF.SUMMARY

[0006] In the related art, vendors for the orchestration system may typically implement proprietary customer resource models (CRD schemas) in order to manage their own NF’s in the cloud. However, since these are non-standardized CRD schemas, there is no interoperable way for a management system (e.g., implemented in 3 GPP) to understand the vendor-specific CRD contents, and accordingly it cannot retrieve or construct the deployment requirements for each vendor’s NF’s. In some use-cases where resources allocated for multi-vendor NF’s need to be modified, coordinated, or jointly optimized by the management system, there is currently no interoperable multi-vendor solution.

[0007] FIG. 1 illustrates an example multi-vendor cloud environment according to the related art. Management system 100 (for example, implemented in 3 GPP) may provide a CRD based on schema A to orchestration system 1 110, which has an operator 111 for vendor A, and CRD based on schema B to orchestration system 2 120, which has an operator 121 for vendor B. Operator 111 may perform orchestration tasks for NF workload(s) 112 for vendor A, and associated with resources for cluster A 113, whereas operator 121 may perform orchestration tasks for NF workload(s) 122 for vendor B, and associated with resources for cluster B 123. Cluster A113 and Cluster B 113 are isolated resources from each other. All the above elements may be implemented within cloud site 130.

[0008] Without standardization of the CRD schema, management system 100 has no way to understand the content in the CRDs, and to retrieve / construct the deployment requirement information to modify, coordinate, or jointly optimize the resource. Each vendor (vendor A and B) manages its own NF’s independently in an isolated cloud resources (e.g., the clusters or namespaces are separated). The management system accordingly cannot modify the deployment requirements in the CRD’s, since there is no centralized management, runtime resource coordinate and joint optimization.

[0009] Even considering the case where the vendor is the same for all NF’s, if the CRD schema is not standardized, collaboration among different teams within the same vendor may be difficult, since it may not be clear how to express the NF resource requirements.

[0010] Accordingly, there is a need for a standardized CRD schema for different types of NF’s (e g., in Radio Access Network (RAN) and core) to enhance interoperability in multi-vendor NF cloud environment.

[0011] Example embodiments of the present disclosure provide a method for standardized custom resource definitions for life cycle management of cloud-native network functions. The method may include receiving, by a orchestration and management entity, a custom resource (CR) based on a standardized custom resource definition (CRD) schema from a management system for a network; and managing, by the orchestration and management entity, a first set of one or more network function (NF) workload(s) of the network based on the standardized CRD schema.

[0012] Based on the above example embodiments, an example benefit may include enhanced interoperability, cost efficiency, and performance in multi-vendor cloud in both single-tenant and multi-tenant cluster environments. Through understanding CRD contents based on standardized schemas, the management system can retrieve vendor specific development requirements from the CRD's and configure cloud infrastructure / make NF deployment decisions accordingly. Different vendor's NF's can have their resources be jointly optimized in runtime. Further, standardized CRD's can specify only the high-level declaration of what to be achieved by the orchestration system (deployment requirements) such that the specific implementation is left to the vendor.

[0013] According to example embodiments, a system may be provided including an orchestration and management entity and a management system for a network, wherein the orchestration and management entity is configured to: receive a custom resource (CR) based on a standardized custom resource definition (CRD) schema from the management system; and manage a first set of one or more network function (NF) workload(s) of the network based on the standardized CRD schema .

[0014] Additional aspects will be set forth in part in the description that follows and, in part, will be apparent from the description, or may be realized by practice of the presented embodiments of the disclosure.BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Features, aspects, and advantages of embodiments of the disclosure will be described below with reference to the accompanying drawings, in which like reference numerals denote like elements, and wherein:

[0016] FIG. 1 illustrates an example multi-vendor cloud environment according to the related art;

[0017] FIG. 2 illustrates an example multi-vendor cloud environment for a single-tenant resource pool according to one or more example embodiments;

[0018] FIG. 3 illustrates an example multi-vendor cloud environment for a multi-tenant resource pool according to one or more example embodiments;

[0019] FIG. 4 illustrates an example multi-vendor cloud environment for a jointly optimized multi-tenant resource pool according to one or more example embodiments;

[0020] FIG. 5 illustrates an example multi-vendor cloud environment for a dynamic slice assurance multi-tenant resource pool according to one or more example embodiments;

[0021] FIG. 6 illustrates an example system architecture diagram showing the interaction between the management system and the orchestration management system according to one or more example embodiments;

[0022] FIG. 7 illustrates an example structure of a custom resource definition for a user plane function according to one or more example embodiments;

[0023] FIG. 8 illustrates an example structure of a custom resource definition for a central unit user plane function according to one or more example embodiments;

[0024] FIG. 9 illustrates an example information model of a custom resource definition according to one or more example embodiments;

[0025] FIG. 10 illustrates a block diagram of an example method for receiving a custom resource definition according to one or more example embodiments;

[0026] FIG. 11 illustrates an example system architecture diagram showing the interaction between the management system and the orchestration management system for NF deployment instance modification according to one or more example embodiments;

[0027] FIG. 12 illustrates an example system architecture diagram showing the interaction between the management system and the orchestration management system for NF deployment instance termination according to one or more example embodiments;

[0028] FIG. 13 illustrates a block diagram of an example device for implementing one or more example embodiments; and

[0029] FIG. 14 illustrates a block diagram of an example environment for implementing one or more example embodiments.DETAILED DESCRIPTION

[0030] The following detailed description of example embodiments refers to the accompanying drawings. The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise forms disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations. Further, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). Additionally, the flowchart and description of operations provided below relate to one of the various embodiments. It should be noted that it is possible to make other embodiments that do not exactly match the flowchart and its description. It is understood that in other embodiments one or more operations may be omitted, one or more operations may be added, one or more operations may be performed simultaneously (at least in part).

[0031] It will be apparent that systems and / or methods, described herein, may be implemented in different forms of hardware, firmware, or a combination of hardware and software.The actual specialized control hardware or software code used to implement these systems and / or methods is not limited to the described implementations. Thus, the operation and behavior of thesystems and / or methods are described herein without reference to specific software code. It is understood that software and hardware may be designed to implement the systems and / or methods based on the description herein.

[0032] Even though particular combinations of features are disclosed in the claims and / or in the specification, these combinations are not intended to limit the disclosure of implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and / or disclosed in the specification. Although each dependent claim listed below may directly depend on only one claim, the disclosure of implementations includes each dependent claim in combination with every other claim in the claim set.

[0033] No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles “a” and “an” are intended to include one or more items, and may be used interchangeably with “one or more.” Also, as used herein, the terms “has,” “have,” “having,” “include,” “including,” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise. Furthermore, expressions such as “at least one of [A] and [B]”, “[A] and / or [B]”, or “at least one of [A] or [B]”, are to be understood as including only A, only B, or both A and B.

[0034] It shall be noted that, descriptions of example embodiments of the present disclosure may include terms and names defined in one or more standard organizations, such as the 3rd Generation Partnership Project (3GPP) standard organization, the European Telecommunications Standards Institute (ETSI) standard organization, the Open Radio AccessNetwork (O-RAN) Alliance standard organization, and the like.

[0035] Example embodiments of the present disclosure provide a method for standardized custom resource definitions for life cycle management of cloud-native network functions. The method may include receiving, by a orchestration and management entity, a custom resource (CR) based on a standardized custom resource definition (CRD) schema from a management system for a network; and managing, by the orchestration and management entity, a first set of one or more network function (NF) workload(s) of the network based on the standardized CRD schema.

[0036] Based on the above example embodiments, an example benefit may include enhanced interoperability, cost efficiency, and performance in multi-vendor cloud in both singletenant and multi-tenant cluster environments. Through understanding CR contents based on standardized schemas, the management system can retrieve vendor specific development requirements from the CRs and configure cloud infrastructure / make NF deployment decisions accordingly. Different vendor's NF's can have their resources be jointly optimized in runtime. Further, standardized CRD's can specify only the high-level declaration of what to be achieved by the orchestration system (deployment requirements) such that the specific implementation is left to the vendor.

[0037] It is contemplated that features, advantages, and significances of example embodiments described hereinabove are merely a portion of the present disclosure, and are not intended to be exhaustive or to limit the scope of the present disclosure. Further descriptions of the features, components, configuration, operations, and implementations of the example embodiments of the present disclosure are provided in the following.

[0038] FIG. 2 illustrates an example multi-vendor cloud environment for a single-tenant resource pool according to one or more example embodiments.

[0039] Management system 100 may provide a CRD to both orchestration system 1 110 and orchestration system 2 120 based on the same schema C. Even though orchestration system 1110 is run by operator 111 (vendor A), and orchestration 2 120 is run by operator 121 (vendor B), the CRD schema is standardized to be the same. Management system 100 can accordingly understand the CRD content for each vendor’s NF’s deployment (vendor A and B), and manage the resource allocation through retrieving and constructing requirement information from / to the CRD’s. The management system can modify the NF deployment (as part of LCM requirements) to coordinate or jointly optimize the resources in runtime, and modify the infrastructure configuration to adjust the resource allocation to different clusters and namespaces.

[0040] Each vendor’s operator (111, 121) still manages its own NFs in isolated cloud resources. NF workload(s) 112 (vendor A) and cluster A 113 may have its own single-tenant resource pool (having its own unique namespace / cluster), and NF workload(s) 122 (vendor B) and cluster B 123 may also be its own separate single-tenant resource pool. Cloud site 130 may also be provided as part of the multi-vendor cloud.

[0041] FIG. 3 illustrates an example multi-vendor cloud environment for a multi-tenant resource pool according to one or more example embodiments.

[0042] Management system 300 may provide a common CRD to orchestration system 310, wherein the operators 311 are common. NF workload(s) 312 (belonging to vendor A) and NF workload(s) 313 (belonging to vendor B) may be part of the same multi -tenant resource pool, and share a cluster common 320. Cloud site 330 may be provided as part of the multi-vendor cloud.

[0043] Similar to the single-tenant case, the management system 300 may understand the CRD content for each vendor’s NF deployment and manage the resource allocation through retrieving and constructing requirement information from / to the CRD’s. However, in this use-case,a system integrator may manage NFs from vendor A and B (122, 123) based on the standardized (common) CRD schema. Accordingly, multi-vendor NFs may share the same cluster, and may be jointly managed by the common operators 311.

[0044] FIG. 4 illustrates an example multi-vendor cloud environment for a jointly optimized multi-tenant resource pool according to one or more example embodiments.

[0045] Similar to FIG. 3, management system 300 may provide multiple CRs corresponding to standardized CRD schema to an orchestration system 310. However, in this situation, Distributed Unit (DU) 312 belonging to vendor A, Central Unit User Plane (CU-UP) 313 belonging to vendor B, and User Plane Function (UPF) 314 belonging to vendor C may be provided. DU 312, CU-UP 313, and UPF 314 may have its resource located in the same pool as part of the edge cloud cluster 320. Accordingly, DU 312, CU-UP 313, and UPF 314 may be collected at the edge, and jointly optimized by the same common operator. This is made possible since even though each NF 312, 313, and 314 are provided by different vendors, the standardized CRD schema used allows each NF to be managed independent of the vendor.

[0046] FIG. 5 illustrates an example multi-vendor cloud environment for a dynamic slice assurance multi-tenant resource pool according to one or more example embodiments.

[0047] Similar to FIG.4, management system 300 may provide multiple CRs each corresponding to a standardized CRD schema to an orchestration system 310. However, in this situation, DU 312 (belonging to vendor A) may be separated into a best effort slice, whereas UPF, CU-UP 315 and DU 316 (belonging to vendor B) may be in its own bit rate and latency guaranteed slice. When the traffic demand of one of the slices increases (e.g., UPF, CU-UP and DU), resources may be re-allocated to that slice in order to guarantee the bit rate and latency.

[0048] FIG. 6 illustrates an example system architecture diagram showing the interaction between the management system and the orchestration management system according to one or more example embodiments.

[0049] Management system 600 (which may be implemented, for example, in 3GPP) and orchestration and management (which may be implemented, for example, in Kubemetes (K8S) may be provided. XYZ reference point refers to the interaction between these different systems. Interactions may be provided over the xyz reference point for cloud-native NF termination. For example, management system 600 may send a standardized CRD model for life-cycle management (LCM) of a cloud-native NF to orchestration and management 610. The deployment requirements when creating, modifying, or terminating the workload(s) of a NF are conveyed from the management system 600 to the orchestration and management system 610 via the CRD models based on standardized schemas.

[0050] The standardized CRD models may only provide a declaration in high-level on what to be achieved by the orchestration system (the deployment requirements) rather than how to achieve it, and only focus on the common, non-differentiating aspects of vendors’ solutions, leaving it completely to vendor implementations to develop unique and value critical features. If the orchestration and management system is ETSI NFV MANO, the interactions over XYZ reference point are as specified in clause 7.10 of 28.531 [7] (of 3GPP).

[0051] FIG. 7 illustrates an example structure of a custom resource definition for a user plane function according to one or more example embodiments.

[0052] CRD UPF may be defined as a high-level schema. The interface, capacity requirements, dependency, network endpoints, and resource requirements (optional) may be specified in the CRD. For example, the interface section may specify the logical interfacedefinitions, and the mapping with the network interfaces. The network endpoints may specify network interface definitions (e.g., IP / FQDN configuration and mapping with NF logical interfaces). The resource requirements may specify a resource requirement or constraint for the NF deployment (e.g., CPU / RAM / storage capacity, NUMA awareness, node binding, etc.)

[0053] Capacity requirements may be specified in terms of attributes. Attributes may include, but are not necessarily limited to, the maximum number of UE’s, the downlink latency, the uplink latency, the downlink throughput per slice subnet, the downlink throughput per UE, the uplink throughput per slice subnet, the uplink throughput per UE, the maximum number of PDU sessions, the coverage area TA list , the reliability, resource sharing level, downlink maximum packet size, uplink maximum packet size, slice simulation use, delay tolerance, energy efficiency, downlink deterministic communication, uplink deterministic communication, survival time, NSSAA support, and N6 protection. It should be appreciated that the above list is merely an example, and other attributes may be included.

[0054] FIG. 8 illustrates an example structure of a custom resource definition for a central unit user plane function according to one or more example embodiments.

[0055] CRD CUUP may be defined as a high-level schema. The interface, capacity requirements, dependency, network endpoints, and resource requirements (optional) may be specified in the CRD. For example, the interface section may specify the logical interface definitions, and the mapping with the network interfaces. The network endpoints may specify network interface definitions (e.g., IP / FQDN configuration and mapping with NF logical interfaces). The resource requirements may specify a resource requirement or constraint for theNF deployment (e.g., CPU / RAM / storage capacity, NUMA awareness, node binding, etc.)

[0056] Capacity requirements may be specified in terms of attributes. Attributes may include, but are not necessarily limited to, the coverage area TA list, the UE mobility level, resource sharing level, the maximum number of UE’s, the activity factor, the downlink throughput per slice subnet, the downlink throughput per UE, the uplink throughput per slice subnet, the uplink throughput per UE, the UE speed, reliability, nR operating bands, sST, downlink latency, uplink latency, delay tolerance, slice simultaneous use, downlink max packet size, uplink max packet size, energy efficiency, term density, survival time, downlink determination communication, uplink deterministic communication, position, and synchronicity.

[0057] FIG. 9 illustrates an example information model of a custom resource definition according to one or more example embodiments.

[0058] A parent element (CRD TOP) may be the uppermost block and may consist of several sub elements. For example, resource definition, network definition, dependency definition, capacity definition, and interface definitions, corresponding to their respective elements in the example for CRD-CUUP illustrated in FIG. 8 may be provided.

[0059] Different CRD schemas for different NF functions may also be part of the same CRD TOP definition. For example, CRD UPF and CRD CUUP may be sub elements with respect to parent element CRD TOP.

[0060] FIG. 10 illustrates a block diagram of an example method 1000 for receiving a custom resource definition according to one or more example embodiments.

[0061] At operation 1010, a CR based on standardized schema (e.g., CRD) may be received from the management system by a first orchestration system. The first orchestration system may be operated by a first vendor.

[0062] The standardized schema may include one or more of an interface definition, a capacity or performance requirement definition, a networks endpoint definition, a resource requirement definition, and a dependency definition.

[0063] At operation 1020, a first set of NF workload(s) may be managed based on the standardized CRD schema by the first orchestration system. The NF workload(s) implementations may be provided by the first vendor. According to example embodiments, the standardized CRD schema may include a UPF definition, in which case the first NF workload(s) is UPF workload(s). The CRD schema may include a CU-UP definition, and the first NF workload(s) may also include CU-UP workload(s). The CRD schema may also include a DU definition, and the first NF workload(s) may also include DU workload(s). The CRD schema may be configured according to any 3GPP network function (e.g., Access and Mobility Management Function (AMF)).

[0064] According to example embodiments, managing the first set of one or more NF workload(s) may include an interaction for modifying a declarative descriptor of the standardized CRD schema over a deployment management reference point between the orchestration and management entity and the management system to modify one or more of the NF workload(s) of the first set.

[0065] Managing the first set of one or more NF workload(s) may also include an interaction for deleting a declarative descriptor of the standardized CRD schema over a deployment management reference point between the orchestration and management entity and the management system to terminate one or more of the NF workload(s) of the first set.

[0066] It should be appreciated that operation 1010 and 1020 may be repeated for a second orchestration system run by a second vendor, for second NF workload(s) provided by the secondvendor, the first vendor different from the second vendor. The second orchestration system may be the same as the first orchestration system in common shared operator scenario.

[0067] Based on the above example embodiments, an example benefit may include enhanced interoperability, cost efficiency, and performance in multi-vendor cloud in both singletenant and multi-tenant cluster environments. Through understanding CR contents based on standardized schemas, the management system can retrieve vendor specific development requirements from the CRs and configure cloud infrastructure / make NF deployment decisions accordingly. Different vendor's NFs can have their resources be jointly optimized in runtime. Further, standardized CRs can specify only the high-level declaration of what to be achieved by the orchestration system (deployment requirements) such that the specific implementation is left to the vendor.

[0068] FIG. 11 illustrates an example system architecture diagram showing the interaction between the management system and the orchestration management system for NF deployment instance modification according to one or more example embodiments.

[0069] In this example use-case, management system 1100 (e.g., 3GPP management system) interacts with an orchestration and management entity 1110 for modification of a NF deployment instance. A deployment management reference point may be provided between management system 1100 and orchestration and management entity 1110.

[0070] An already deployed NF deployment instance may be modified (e.g. reconfiguration). To modify a NF deployment instance an updated description of the NF requirements and parameters can be conveyed to the orchestration and management entity 1110. Management system 1100 should be able to request orchestration and management entity 1110 to modify a NF deployment instance.

[0071] Potential requirements are listed as follows:

[0072] REQ-LCM-MODIFY-1 The deployment management reference point should have the capability enabling management system 1110 to request modification of a NF deployment instance based on NF deployment requirements.

[0073] REQ-LCM-MODIFY-2 The deployment management reference point should have the capability enabling orchestration and management entity 1110 to inform management system 1100 of the result of the request for modification of a NF deployment instance.

[0074] In this solution, management system 1100 interacts with an orchestration and management entity 1100 using the deployment management reference point for modification of a NF deployment instance. To this end, FIG. 11 exemplifies a high-level view of an example procedure for modification of a NF deployment instance.

[0075] Management system 1100 requests modification of a NF deployment instance from an orchestration and management entity 1110 for LCM of NF deployment instances over deployment management reference point, and receives the result of the request for modification of the NF deployment instance from the orchestration and management entity.

[0076] An example of modifying the NF deployment instance based on declarative descriptor is also depicted in FIG. 11. The modified requirements of the deployment of a NF deployment instance may be conveyed from management system 1100 to the orchestration and management system 1110 via a modified version of the declarative descriptor that was used for creation of the NF deployment instance.

[0077] FIG. 12 illustrates an example system architecture diagram showing the interaction between the management system and the orchestration management system for NF deployment instance termination according to one or more example embodiments.

[0078] In this example use-case, management system 1200 (e.g., 3GPP management system) interacts with an orchestration and management entity 1210 for termination of a NF deployment instance. A deployment management reference point may be provided between management system 1200 and orchestration and management entity 1210.

[0079] A deployed NF deployment instance may be terminated by management system 1200. To terminate a NF deployment instance there is a need to request the termination of the NF deployment instance from orchestration and management entity 1210. Management system 1200 should be able to request orchestration and management entity 1210 to terminate a NF deployment instance.

[0080] Potential requirements are listed as follows:

[0081] REQ-LCM- TERMINATE- 1 The deployment management reference point should have the capability enabling management system 1210 to request termination of a NF deployment instance.

[0082] REQ-LCM-MODIFY-2 The deployment management reference point should have the capability enabling orchestration and management entity 1210 to inform management system 1200 of the result of the request for termination of a NF deployment instance.

[0083] In this solution, management system 1200 interacts with an orchestration and management entity 1200 using the deployment management reference point for termination of a NF deployment instance. To this end, FIG. 12 exemplifies a high-level view of an example procedure for termination of a NF deployment instance.

[0084] Management system 1200 requests termination of a NF deployment instance from an orchestration and management entity 1210 for LCM of NF deployment instances overdeployment management reference point, and receives the result of the request for termination of the NF deployment instance from the orchestration and management entity.

[0085] An example of terminating the NF deployment instance based on declarative descriptor is also depicted in FIG. 12. The previous descriptor created in the orchestration and management entity 1210 is deleted by management system 1200 via the deployment management reference point. The orchestration and management entity 1210 removes the existing resources allocated to the NF and terminates the NF.

[0086] FIG. 13 illustrates a block diagram of an example device 1300 for implementing one or more example embodiments. As shown in FIG. 13, the device 1300 includes processor 1310, a memory 1320, a storage component 1330, an input component 1340, an output component 1350, a communication interface 1360, and a bus 1370.

[0087] The processor 1310, as used herein, means any type of computational circuit that may comprise hardware elements and software elements. The processor 1310 may be embodied as a multi-core processor, a single core processor, or a combination of one or more multi-core processors and / or one or more single core processors, a distributed processing system, or the like. The processor 1310 may be a Central Processing Unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), an application-specific integrated circuit (ASIC), or another type of processing component.

[0088] Memory 1320 includes a non-transitory computer readable medium. Memory 1320 includes a random-access memory (RAM), a read only memory (ROM), and / or another type of dynamic or static storage device (e.g., a flash memory, a magnetic memory, and / or an optical memory) that stores information and / or instructions for use by processor 1310. The memory 1320 comprises machine-readable instructions which are executable by the processor 1310. Thesemachine-readable instructions when executed by the processor 1310 cause the processor 1310 to perform one or more method steps of an embodiment described above.

[0089] Storage component 1330 stores information and / or software related to the operation and use of the device 1300. For example, storage component 1330 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, and / or a solid-state disk), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, a magnetic tape, and / or another type of non-transitory computer-readable medium, along with a corresponding drive.

[0090] Input component 1340 is configured to receive information, such as user input. For example, the input component 1340 may include, but not be limited to, a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, and / or a microphone. Additionally, or alternatively, the input component 1340 may include a sensor for sensing information (e.g., a global positioning system (GPS), an accelerometer, a gyroscope, and / or an actuator).

[0091] Output component 1350 is configured to provide output information from the device 1300. For example, the output component 1350 may be, but not limited to, a display, a speaker, an instruction device to an external device, and / or one or more light-emitting diodes (LEDs).

[0092] Communication interface 1360 is an interface that provides a communication connection to other devices, such as external devices and internal devices. The connection by the communication interface 1360 can be a wired connection, a wireless connection, or a combination of wired and wireless connections, and can be a direct connection or an indirect connection via a communication network that exists between the device 1300 and other devices. In other words, the standard of the communication interface 1360 is not limited.

[0093] The bus 1370 acts as an interconnect between the processor 1310, the memory 1320, the storage component 1330, the input component 1340, the output component 1350, and the communication interface 1360 of the device 1300. The bus 1370 may include a wired interconnection or a wireless interconnection.

[0094] The number and arrangement of components shown in FIG. 13 are provided as an example. In practice, device 1300 may include additional components, fewer components, different components, or differently arranged components than those shown in FIG. 13. Additionally, or alternatively, a set of components (e.g., one or more components) of device 1300 may perform one or more functions described as being performed by another set of components of device 1300. Further, one or more method steps described in any of the embodiments may be performed utilizing a plurality of devices 1300 in communication with one another.

[0095] Example embodiments of the present disclosure may be implemented in any suitable type of environment. In the following, an example environment (in which the example embodiments may be implemented) is described.

[0096] FIG. 14 illustrates a block diagram of an example environment 1400 for implementing in which systems and / or method, described herein, may be implemented. The implementation environment 1400 includes a UE (User equipment) 1410, a service environment1420, and a network 1430. The service environment 1420 include one or more sub-environments1421. To illustrate this, FIG. 14 shows, for convenience, examples of a 1st sub-environment 1421- 1, a 2nd sub-environment 1421-2, and an N-th sub-environment 1421-N (where N is any natural number).

[0097] The UE 1410 is connected to the network 1430, and the network 1430 is connected to the service environment 1420. The connections may be wired, wireless, or a combination ofboth wired and wireless. The UE 1410 and the service environment 1420 are connected via the network 1430.

[0098] The UE 1410 is a device that communicates with the service environment 1420. The UE 1410 receives information from the service environment 1420 and / or sends information to the service environment 1420. Also, the UE 1410 may generate and / or store information to be transmitted, as necessary. Also, the UE 1410 may store and / or process information that is received, as necessary.

[0099] The example figure 14 refers to the “UE”. However, it should be understood by those skilled in the art that general terms such as “user device,” “terminal,” “terminal device,” “communication device,” and “communication terminal” can be used interchangeably with the term “UE.”

[0100] For example, the UE 1410 may include a computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a handheld computer, a smart speaker, a server, etc.), a mobile phone (e.g., a smart phone, a radiotelephone, etc.), a wearable device (e.g., a pair of smart glasses or a smart watch), or a similar device.

[0101] The service environment 1420 is an environment that communicates with the UE 1410 to provide one or more services. The service environment 1420 receives information from the UE 1410 and / or sends information to the UE 1410. Also, the service environment 1420 may generate and / or store information to be transmitted, as necessary. Also, the service environment 1420 may store and / or process information that is received, as necessary. For example, the service environment 1420 may provide computing resources as one of the services. It should be noted that the service is not limited to being provided to the UE; it may also be provided to devices other than the UE. For example, based on communication from the UE, the service may performprocesses such as anomaly detection or traffic analysis and notify the results to a predetermined destination.

[0102] The example figure 14 refers to the “service environment”. The term "service environment" is used to refer to the broader context within which services operate. For example, cloud environments, platforms, computing systems, network systems, and cloud systems generally represent the environments in which services are conducted, and these are included within the "service environment." However, the "service environment" is not limited to these examples. Additionally, the specific types of environments within the "service environment" are not restricted. For instance, cloud environments and cloud systems can be categorized as private cloud, public cloud, hybrid cloud, or multi-cloud, all of which are included within the "service environment."

[0103] The one or more services provided by the service environment 1420 is not specifically limited and can be adjusted according to the embodiments. For example, the services may include a service that provides information to the UE 1410, a service that stores information from the UE 1410, or a service that performs processing based on information from the UE 1410 and returns the results of the processing.

[0104] In an embodiment, the Service Environments 1420 may also provide computing resources as the service. The computing resources can be hardware resources and / or software resources. For example, applications, processors, memory, and storage can be included in the provided computing resources. Each computing resource can communicate with other computing resources via wired connections, wireless connections, or a combination of wired and wireless connections.

[0105] The provided computing resources can be actual resources (also referred to as physical resources) and / or virtual resources. Furthermore, means of virtualization for virtualresources can be selected as appropriate. That is, in this disclosure, the use of adjectives such as "Virtual" or "Virtualized" to describe names does not imply that they are virtualized by a specific means of virtualization. For example, “virtual machine” refers to software that operates like an actual computer, realized through means of virtualization, and it is not intended to exclude those realized by specific means of virtualization such as Hypervisors or Containers. Conversely, when means of virtualization such as Hypervisors or containers are mentioned in this disclosure, it is merely cited as a general method of implementation. It should also be interpreted that embodiments implemented with other virtualization means are also disclosed. Also, the services may also be provided using resources virtualized by different means.

[0106] The service environment 1420 includes one or more devices, such as servers and network devices, which provide services or perform processes. The placement of these devices within the service environment 1420 can be determined as appropriate. Additionally, if the service environment 1420 includes one or more sub-environments 1421, the placement of devices can be determined based on predetermined policies for each sub-environment 1421. For example, devices related to the first service may be placed in the 1st sub-environment 1421-1, and devices related to the second service may be placed in the 2nd sub-environment 1421-2. In another example, devices expected to have a higher load than a predetermined threshold may be placed in the 1st sub-environment 1421-1, while devices expected to have a lower load than the predetermined threshold may be placed in the 2nd sub-environment 1421-2. In this way, specific devices can be placed in specific sub-environments 1421. Conversely, each sub-environment 1421 can be specialized for a particular purpose.

[0107] In an embodiment, all processes executed in a single service may run within a single service environment, or in multiple service environments. Multiple processes executed in a single service could be provided by different service environments.

[0108] The network 1430 is a network that exchanges information between the UE 1410 and the service environment 1420. The network 1430 includes one or more wired and / or wireless networks.

[0109] For example, the network 1430 may include a cellular network (e.g., a fifth generation (5G) network, a long-term evolution (LTE) network, a third generation (3G) network, a code division multiple access (CDMA) network, etc.), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., the Public Switched Telephone Network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, a fiber optic-based network, or the like, a non-terrestrial network (NTN), and / or a combination of these or other types of networks.

[0110] The network 1430 can be a part of a network. For example, in a 5G network that includes a RAN, a transport network, and a core network, the network 1430 can be at least one of the RAN, the transport network, or the core network. For example, the service environment 1420 could be in the core network, in which case the network 1430 could correspond to a network that is a combination of a RAN and a transport network and is part of the 5G network.[0U1] The number and arrangement of devices and networks shown in FIG. 14 are provided as an example. It should be understood that any changes that may be implemented by those skilled in the art, such as the addition or rearrangement of well-known devices or networks at the time of implementation, are included in this disclosure.Various Aspects of Embodiments

[0112] It is contemplated that the example embodiments described hereinabove with reference to FIG. 2 to FIG. 14 are merely examples of possible embodiments of the present disclosure, and are not intended to limit or restrict the scope of the present disclosure.

[0113] Specifically, the foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations.

[0114] Some embodiments may relate to a device (e.g., node, etc.), a system, a method, and / or a computer-readable medium at any possible technical detail level of integration. Further, one or more of the above components described above may be implemented as instructions stored on a computer-readable medium and executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include a computer-readable non- transitory storage medium (or media) having computer-readable program instructions thereon for causing a processor to carry out operations.

[0115] The computer-readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), electrically erasable programmable read-only memory (EEPROM), a static random access memory (SRAM), a portable compact discread-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer-readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

[0116] Computer-readable program instructions described herein can be downloaded to respective computing / processing devices from a computer-readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing / processing device.

[0117] Computer-readable program code / instructions for carrying out operations may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, including an object-oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the "C" programming language or similar programming languages.

[0118] The computer-readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer-readable program instructions by utilizing state information of the computer- readable program instructions to personalize the electronic circuitry, in order to perform aspects or operations.

[0119] These computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. These computer- readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer-readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function / act specified in the flowchart and / or block diagram block or blocks.

[0120] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operationalsteps to be performed on the computer, other programmable apparatus or other devices to produce a computer-implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0121] The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer- readable media according to various embodiments. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). The method, computer system, and computer-readable medium may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in the Figures. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed concurrently or substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustration, and combinations of blocks in the block diagrams and / or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

[0122] It will be apparent that systems and / or methods, described herein, may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not limited to the implementations. Thus, the operation and behavior of the systemsand / or methods were described herein without reference to specific software code — it is understood that software and hardware may be designed to implement the systems and / or methods based on the description herein.

[0123] In view of the above, various further respective aspects and features of embodiments of the present disclosure may be defined by the following items:Item [1] A method including: receiving, by a orchestration and management entity, a custom resource (CR) based on a standardized custom resource definition (CRD) schema from a management system for a network; and managing, by the orchestration and management entity, a first set of one or more network function (NF) workload(s) of the network based on the standardized CRD schema.Item [2]: The method according to Item [1], further including receiving, by a second orchestration and management entity, a CR based on the standardized CRD schema from the management system of the network; and managing, by the second orchestration system, a second set of one or more NF workload(s) of the network based on the standardized CRD schema.Item [3]: The method according to any one of Items [ l]-[2], wherein the standardized CRD schema includes an interface definition.Item [4]: The method according to any one of Items

[0001] -[2], wherein the standardized CRD schema includes a capacity or performance requirement definition.Item [5]: The method according to any one of Items

[0001] -[2], wherein the standardized CRD schema includes a network endpoints definition.Item [6]: The method according to any one of Items

[0001] -[2], wherein the standardized CRD schema includes a resource requirement definition.Item [7]: The method according to any one of Items

[0001] -[2], wherein the standardized CRD schema includes a dependency definition.Item [8]: The method according to any one of Items

[0001] -[7], wherein the standardized CRD schema is configured to be applied to network functions including one or more of a Distributed Unit (DU), a Central Unit Control Plane (CU-CP), a Central Unit User Plane (CU-UP), a User Plane Function (UPF), and an Access and Mobility Management Function (AMF).Item [9]: The method according to any one of Items [l]-[8], wherein managing the first set of one or more NF workload(s) includes an interaction for modifying a declarative descriptor of the standardized CRD schema over a deployment management reference point between the orchestration and management entity and the management system to modify one or more of the NF workload(s) of the first set.Item

[0010] : The method according to any one of Items [l]-[9], wherein managing the first set of one or more NF workload(s) includes an interaction for deleting a declarative descriptor of the standardized CRD schema over a deployment management reference point between theorchestration and management entity and the management system to terminate one or more of the NF workload(s) of the first set.Item

[0011] : A system including an orchestration and management entity and a management system for a network, wherein the orchestration and management entity is configured to: receive a custom resource (CR) based on a standardized custom resource definition (CRD) schema from the management system; and manage a first set of one or more network function (NF) workload(s) of the network based on the standardized CRD schema .Item

[0012] The system according to Item

[0011] , further including a second orchestration and management entity, wherein the second orchestration and management entity is configured to: receive a CR based on the standardized CRD schema from the management system; and manage a second set of one or more NF workload(s) of the network based on the standardized CRD schema.Item

[0013] The system according to any one of Items

[0011] -

[0012] , wherein the standardized CRD schema includes an interface definition.Item

[0014] The system according to any one of Items

[0011] -

[0012] , wherein the standardized CRD schema includes a capacity or performance requirement definition.Item

[0015] The system according to any one of Items

[0011] -

[0012] , wherein the standardized CRD schema includes a network endpoints definition.Item

[0016] The system according to any one of Items

[0011] -

[0012] , wherein the standardized CRD schema includes a resource requirement definition.Item

[0017] The system according to any one of Items

[0011] -

[0012] , wherein the standardized CRD schema includes a dependency definition.Item

[0018] The system according to any one of Items

[0011] -

[0017] , wherein the standardized CRD schema is configured to be applied to network functions including one or more of a Distributed Unit (DU), a Central Unit Control Plane (CU-CP), a Central Unit User Plane (CU- UP), a User Plane Function (UPF), and an Access and Mobility Management Function (AMF).Item

[0019] The system according to any one of Items

[0011] -

[0018] , wherein managing the first set of one or more NF workload(s) includes an interaction for modifying a declarative descriptor of the standardized CRD schema over a deployment management reference point between the orchestration and management entity and the management system to modify one or more of the NF workload(s) of the first set.Item

[0020] The system according to any one of Items

[0011] -

[0019] , wherein managing the first set of one or more NF workload(s) includes an interaction for deleting a declarative descriptor of the standardized CRD schema over a deployment management reference point between the orchestration and management entity and the management system to terminate one or more of theNF workload(s) of the first set.Item

[0021] The method according to any one of Items [l]-

[0010] , wherein managing the first set of one or more NF workload(s) comprises an interaction for creating a declarative descriptor of the standardized CRD schema over a deployment management reference point between the orchestration and management entity and the management system to create one or more of the NF workload(s) of the first set.Item

[0022] The system according to any one of Items

[0011] -

[0020] , wherein managing the first set of one or more NF workload(s) comprises an interaction for creating a declarative descriptor of the standardized CRD schema over a deployment management reference point between the orchestration and management entity and the management system to create one or more of the NF workload(s) of the first set.It will be apparent that within the scope of the appended clauses, the present disclosures may be practiced otherwise than as specifically described herein.

Claims

What is claimed is:

1. A method comprising: receiving, by an orchestration and management entity, a custom resource (CR) based on a standardized custom resource definition (CRD) schema from a management system for a network; and managing, by the orchestration and management entity, a first set of one or more network function (NF) workload(s) of the network based on the standardized CRD schema.

2. The method as claimed in claim 1, further comprising: receiving, by a second orchestration and management entity, a CR based on the standardized CRD schema from the management system of the network; and managing, by the second orchestration system, a second set of one or more NF workload(s) of the network based on the standardized CRD schema.

3. The method as claimed in claim 1, wherein managing the first set of one or more NF workload(s) comprises an interaction for creating a declarative descriptor of the standardized CRD schema over a deployment management reference point between the orchestration and management entity and the management system to create one or more of the NF workload(s) of the first set.

4. The method as claimed in claim 1, wherein the standardized CRD schema comprises acapacity or performance requirement definition.

5. The method as claimed in claim 1, wherein the standardized CRD schema comprises a network endpoints definition.

6. The method as claimed in claim 1, wherein the standardized CRD schema comprises a resource requirement definition.

7. The method as claimed in claim 1, wherein the standardized CRD schema comprises a dependency definition.

8. The method as claimed in claim 1, wherein the standardized CRD schema is configured to be applied to network functions including one or more of a Distributed Unit (DU), a Central Unit Control Plane (CU-CP), a Central Unit User Plane (CU-UP), a User Plane Function (UPF), and an Access and Mobility Management Function (AMF).

9. The method as claimed in claim 1, wherein managing the first set of one or more NF workload(s) comprises an interaction for modifying a declarative descriptor of the standardized CRD schema over a deployment management reference point between the orchestration and management entity and the management system to modify one or more of the NF workload(s) of the first set.

10. The method as claimed in claim 1, wherein managing the first set of one or more NF workload(s) comprises an interaction for deleting a declarative descriptor of the standardized CRD schema over a deployment management reference point between the orchestration and management entity and the management system to terminate one or more of the NF workload(s) of the first set.

11. A system comprising an orchestration and management entity and a management system for a network, wherein the orchestration and management entity is configured to: receive a custom resource (CR) based on a standardized custom resource definition (CRD) schema from the management system; and manage a first set of one or more network function (NF) workload(s) of the network based on the standardized CRD schema .

12. The system as claimed in claim 11 further comprising a second orchestration and management entity, wherein the second orchestration and management entity is configured to: receive a CR based on the standardized CRD schema from the management system; and manage a second set of one or more NF workload(s) of the network based on the standardized CRD schema.

13. The system as claimed in claim 11, wherein managing the first set of one or more NF workload(s) comprises an interaction for creating a declarative descriptor of the standardized CRD schema over a deployment management reference point between the orchestration andmanagement entity and the management system to create one or more of the NF workload(s) of the first set.

14. The system as claimed in claim 11, wherein the standardized CRD schema comprises a capacity or performance requirement definition.

15. The system as claimed in claim 11, wherein the standardized CRD schema comprises a network endpoints definition.

16. The system as claimed in claim 11, wherein the standardized CRD schema comprises a resource requirement definition.

17. The system as claimed in claim 11, wherein the standardized CRD schema comprises a dependency definition.

18. The system as claimed in claim 11, wherein the standardized CRD schema is configured to be applied to network functions including one or more of a Distributed Unit (DU), a Central Unit Control Plane (CU-CP), a Central Unit User Plane (CU-UP), a User Plane Function (UPF), and an Access and Mobility Management Function (AMF).

19. The system as claimed in claim 11, wherein managing the first set of one or more NF workload(s) comprises an interaction for modifying a declarative descriptor of the standardized CRD schema over a deployment management reference point between the orchestration andmanagement entity and the management system to modify one or more of the NF workload(s) of the first set.

20. The system as claimed in claim 11, wherein managing the first set of one or more NT workload(s) comprises an interaction for deleting a declarative descriptor of the standardized CRD schema over a deployment management reference point between the orchestration and management entity and the management system to terminate one or more of the NF workload(s) of the first set.

Images