Implementation of a policy-based framework for O-Cloud resource management and orchestration services in telecommunication networks

Abstract

A system and method for implementing a policy-based framework for O-Cloud resource management and orchestration services is provided. The method includes determining a network function (NF) hosted on an O-Cloud node to be instantiated on another O-Cloud node, creating an instantiation policy for the determined NF for ORMOS, sending the instantiation policy to ORMOS via an R1 interface, requesting an instantiation implementation of the determined NF from at least one O-Cloud management service via an O2 interface, instantiating the NF on the other O-Cloud node according to the implementation request, sending a registration and configuration request for the instantiated NF to an NF-associated RAN OAM service, sending a configuration notification of the instantiated NF to ORMOS, and sending an instruction to the at least one O-Cloud management service to complete the instantiation implementation of the determined NF.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application is based on and claims priority to U.S. Provisional Patent Application No. 63 / 441,457, filed with the United States Patent and Trademark Office on January 27, 2023, the disclosure of which is incorporated herein by reference in its entirety.

[0002] SUMMARY Exemplary embodiments of the present disclosure relate to an implementation of a policy-based framework for O-Cloud resource management and orchestration services. [Background technology]

[0003] The radio access network (RAN) is a key component in telecommunications systems because it connects end-user devices (or user equipment) to the rest of the network. The RAN includes a combination of various network elements (NEs) that connect end-user devices to the core network. Traditionally, the hardware and / or software of a particular RAN is vendor specific.

[0004] Open RAN (O-RAN) technology has emerged to enable multiple vendors to provide hardware and / or software for telecommunications systems. To this end, O-RAN decomposes RAN functions into a centralized unit (CU), a distributed unit (DU), and a radio unit (RU). The CU is a logical node for hosting the Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and / or Packet Data Convergence Protocol (PDCP) sublayers of the RAN. The DU is a logical node for hosting the Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY) sublayers of the RAN. The RU is a physical node that converts radio signals from the antenna into digital signals that can be transmitted to the DU via the fronthaul. These entities have open protocols and interfaces between them, allowing them to be developed by different vendors.

[0005] Figure 1 shows the O-RAN architecture of related technology. Referring to Figure 1, RAN functions in the O-RAN architecture are controlled and optimized by a RAN Intelligent Controller (RIC). The RIC is a software-defined component that implements modular applications to facilitate the multi-vendor operability required in an O-RAN system and to automate and optimize RAN operations. RICs are divided into two types: non-real-time RIC (NRT-RIC) and near-real-time RIC (nRT-RIC).

[0006] The NRT-RIC is the control point for a non-real-time control loop and operates on timescales greater than one second within a Service Management and Orchestration (SMO) framework. Its functions are implemented by modular applications called rApps. Functions include providing policies (i.e., sets of rules used to manage and control the change and / or maintenance of the state of one or more managed objects) based on guidance and enrichment over the A1 interface, which is an interface that enables communication between the NRT-RIC and the nRT-RIC; performing data analysis; artificial intelligence / machine learning (AI / ML) training and inference for RAN optimization; and / or recommending configuration management actions via the O1 interface for managing operations and maintenance (OAM) via the O1 interface, which is an interface that connects the SMO to RAN managed elements (e.g., nRT-RIC, O-RAN Centralized Unit (O-CU), O-RAN Distributed Unit (O-DU), etc.). The nRT-RIC operates on a timescale between 10 milliseconds and 1 second and connects to the O-DU, O-CU (decomposed into the O-CU Control Plane (O-CU-CP) and O-CU User Plane (O-CU-UP)), and Open Evolved Node B (O-eNB) via the E2 interface. The nRT-RIC uses the E2 interface to control the underlying RAN elements (E2 nodes / Network Functions (NFs)) via a near-real-time control loop. The nRT-RIC monitors, pauses / stops, overrides, and controls the E2 nodes (i.e., network functions such as the O-CU-CP, O-CU-UP, O-DU, and O-eNB) via policies, and the O-DU connects to the O-RU via fronthaul, including the Control User Synchronization (CUS) plane and the Management (M) plane.For example, the nRT sets policy parameters for activated functions of the E2 node. Additionally, the nRT-RIC hosts xApps to implement functions such as quality of service (QoS) optimization, mobility optimization, slicing optimization, interference mitigation, load balancing, and security. The two types of RICs work together to optimize O-RAN. For example, the NRT-RIC provides policies, data, and artificial intelligence / machine learning (AI / ML) models that are enforced and used by the nRT-RIC for RAN optimization via the A1 interface, and the nRT returns policy feedback (i.e., how the policies set by the NRT-RIC are performing).

[0007] The SMO framework in which the NRT-RIC is deployed manages and orchestrates RAN elements. In particular, the SMO includes O-Cloud resource management and orchestration services. The O-Cloud resource management and orchestration services include Federated O-Cloud Orchestration and Management (FOCOM) and a Network Function Orchestrator (NFO) that manages virtual machine (VM)-based virtual network functions (VNFs) and / or cloud-native network functions (CNFs) and container (i.e., instance)-based VNFs and / or CNFs. The O-Cloud is a collection of physical RAN nodes that host the RIC, O-CU, and O-DU, supporting software components (e.g., operating systems and runtime environments), and the SMO itself. In other words, the SMO manages the O-Cloud from within. The O2 interface is the interface between the SMO and the O-Cloud in which it resides. Through the O2 interface, SMO interacts with O-Cloud management services, such as Infrastructure Management Services (IMS) and Deployment Management Services (DMS) provided by O-Cloud, where IMS provides functionality responsible for the deployment and management of cloud infrastructure (i.e., IMS orchestrates the O-Cloud infrastructure), and DMS provides functionality responsible for managing virtualized / containerized deployments on the O-Cloud infrastructure (i.e., DMS orchestrates virtualized / containerized deployments of E2 node applications).

[0008] Furthermore, according to related art, during operation of the O-RAN architecture, after instantiation (i.e., virtualized / containerized deployment of network functions (NFs) such as VNFs and / or CNFs) of E2 nodes into the O-Cloud infrastructure (i.e., deployment into one or more O-Cloud nodes), the NFs (i.e., VNFs and / or CNFs) and / or the O-Cloud nodes (i.e., physical hosts such as servers or server clusters of the O-Cloud infrastructure) hosting one or more NFs may experience anomalies, such as performance degradation over time and / or across topographic locations within the O-RAN.

[0009] In another example, during operation of the O-RAN architecture, after instantiation (i.e., virtualized / containerized deployment of network functions (NFs), such as VNFs and / or CNFs) of E2 nodes into the O-Cloud infrastructure (i.e., deployment into one or more O-Cloud nodes), the NFs (i.e., VNFs and / or CNFs) and / or the O-Cloud nodes (i.e., physical hosts, such as servers or server clusters of the O-Cloud infrastructure) hosting one or more NFs may become outdated with respect to, for example, resource scaling for hosting NFs on the O-Cloud nodes and / or changing tenant operator requirements regarding updated service levels required by updated service-level agreements (SLAs) with the host operator (RAN operator).

[0010] In each of the above example cases, updated configurations of the O-Cloud nodes and / or NFs need to be provided in order for the application (e.g., one or more NFs) to respond correctly to the current state (or targeted state via updated metrics depending on the required service levels) of the O-Cloud infrastructure on which the application (e.g., one or more NFs) is orchestrated.

[0011] Referring to FIG. 1 , SMO (i.e., NFO and / or FOCOM) schedules one or more O-Cloud nodes in the O-Cloud infrastructure according to the related prior art O-RAN architecture, as described above. Scheduling refers to selecting one or more O-Cloud nodes suitable for implementing a particular workload (i.e., hosting one or more NFs, such as VNFs and / or CNFs), and an O-Cloud node according to the related art is defined as suitable when a specific resource is not explicitly requested (i.e., its suitability depends on the remaining unused hardware resources of the O-Cloud node). For example, FOCOM and / or NFO may control scheduling (instantiation), but its implementation may be applied to one or more NFs and / or one or more O-Cloud nodes, respectively, by the IMS and / or DMS. For this purpose, scheduling of O-Cloud nodes according to the related art focuses on predefined, individual hardware resources of the O-Cloud infrastructure.

[0012] Furthermore, according to the related art, the NRT-RIC framework does not have the capability to push policies to NFO / FOCOM via the R1 interface via O-Cloud Resource Management and Orchestration Services (OMRO) related functions.

[0013] As a result, the related state does not provide a policy-based framework for OMRO-related functions (i.e., ORMOS), and the related art's NFO / FOCOM scheduling has the drawback that it is based on individual pre-defined hardware resources of one or more O-Cloud nodes. This lack of capability in the related art can result in ineffective utilization and performance degradation of one or more NFs and / or the O-Cloud nodes hosting one or more NFs. Summary of the Invention

[0014] Exemplary embodiments provide an implementation of a policy-based framework for O-Cloud resource management and orchestration services in a telecommunications network, where scheduling of one or more O-Cloud nodes is based on a policy-based framework provided from an rApp (e.g., an R1 service) within the NRT-RIC framework (i.e., within the SMO framework) to at least one O-Cloud resource management and orchestration service (ORMOS) (e.g., NFO and / or FOCOM) via an R1 interface and SMO communication between the NRT-RIC framework and ORMOS. In particular, the present system and method provide a policy (e.g., an R1 policy) from the rApp for instantiation (i.e., relocation) of one or more NFs to one or more other O-Cloud nodes by the rApp.

[0015] To this end, the NRT-RIC framework (i.e., rApp) may use data indicating the usage patterns of at least one O-Cloud node and / or one or more NFs hosted thereon as input data for creating a policy for ORMOS (i.e., an R1 policy) (e.g., the rApp may subscribe to telemetric data services, such as O1-related services from NF-related Radio Access Network (RAN) Operations, Administration, and Maintenance (OAM) services (NF-related RAN OAM services), O2-related services from ORMOS, etc.). ORMOS requests the DMS / IMS to instantiate one or more NFs (e.g., instantiate one or more CNFs), and the DMS / IMS instructs the O-Cloud infrastructure to instantiate one or more NFs and send a registration and configuration request to the NF-related OAM Service. Once registered and configured, the NF-related OAM services confirm their instantiation to ORMOS, which then requests the termination of one or more NFs from the O-Cloud node that originally hosted them.

[0016] As a result, the policy-based framework guides ORMOS (i.e., NFO / FOCOM) to effectively schedule (deploy) resources of the O-Cloud infrastructure (i.e., select, instantiate, and relocate NFs on the O-Cloud infrastructure). Furthermore, based on the R1 policies and the optimized ability to receive R1 policies and / or actions from rApps, NFO and FOCOM can interact based on a common policy (i.e., R1 policies) that allows SMO to dynamically request hardware resources (i.e., one or more O-Cloud nodes).

[0017] The policy-based framework for ORMOS benefits from guidance on how to instantiate NFs (i.e., VNFs and / or CNFs) based on multiple scenarios, which may include, among other scenarios, effective implementation of SLA changes and energy-efficient and, in the O-Cloud, resource-optimized operation that adheres to metrics defined in the SLA without degrading the performance of the NFs and / or O-Cloud nodes, thereby enabling optimal (e.g., energy-efficient, resource-optimized, resilience-optimized, etc.) operational performance of the O-RAN.

[0018] According to one embodiment, a system includes an rApp, at least one O-Cloud management service, an NF-related RAN OAM service, and an O-Cloud Resource Management and Orchestration Service (ORMOS). The system is configured to determine, via an rApp in a Service Management Orchestration Framework (SMO), one or more Network Functions (NFs) hosted on at least one O-Cloud node to be instantiated on one or more other O-Cloud nodes. The system is configured, via the rApp, to create an instantiation policy for the determined one or more NFs for the O-Cloud Resource Management and Orchestration Service (ORMOS). The ORMOS may include a Network Function Orchestrator (NFO) and a Federated O-Cloud Orchestration and Management (FOCOM). The system is configured, via the rApp, to send the instantiation policy to ORMOS via an R1 interface. The system is configured, via ORMOS, to request instantiation implementation (implementation of instantiation) of the one or more NFs determined via an O2 interface from the at least one O-Cloud management service based on the instantiation policy. The system is configured to, upon receiving an implementation request (an implementation request), instantiate, by at least one O-Cloud management service, one or more NFs on one or more other O-Cloud nodes according to the implementation request. The at least one O-Cloud management service may include a deployment management service (DMS) and an infrastructure management service (IMS). The system is configured to send, by the at least one O-Cloud management service, registration and configuration requests for the instantiated one or more NFs to an NF-associated Radio Access Network (RAN) Operations, Administration, and Maintenance (OAM) service. The system is configured, based on the registration and configuration requests, to send, by the NF-associated RAN OAM service, configuration notifications for the instantiated one or more NFs to the ORMOS.The system is configured to send instructions to at least one O-Cloud management service to complete instantiation implementation of the one or more NFs determined by the ORMOS.

[0019] According to one embodiment, a method includes determining, by an rApp in a Service Management Orchestration Framework (SMO), one or more Network Functions (NFs) hosted on at least one O-Cloud node to be instantiated on one or more other O-Cloud nodes. The method includes creating, by the rApp, an instantiation policy for the determined one or more NFs for an O-Cloud Resource Management and Orchestration Service (ORMOS). ORMOS may include a Network Function Orchestrator (NFO) and a Federated O-Cloud Orchestration and Management (FOCOM). The method includes sending, by the rApp, the instantiation policy to ORMOS via an R1 interface. The method includes requesting, by ORMOS, instantiation implementation (implementation of instantiation) of the one or more determined NFs via an O2 interface from at least one O-Cloud management service based on the instantiation policy. Upon receiving the implementation request (implementation request), the method includes instantiating, by the at least one O-Cloud management service, the one or more NFs on the one or more other O-Cloud nodes according to the implementation request. The at least one O-Cloud management service may include a Deployment Management Service (DMS) and an Infrastructure Management Service (IMS). The method includes sending, by the at least one O-Cloud management service, a registration and configuration request for the one or more instantiated NFs to an NF-associated Radio Access Network (RAN) Operations, Administration, and Maintenance (OAM) service. The method includes sending, by the NF-associated RAN OAM service, a configuration notification for the one or more instantiated NFs to ORMOS based on the registration and configuration request. The method includes sending, by ORMOS, an instruction to the at least one O-Cloud management service to complete the instantiation implementation of the one or more determined NFs.

[0020] According to one embodiment, a non-transitory computer-readable storage medium having stored thereon instructions executable by at least one processor configured to execute a method is provided. The method includes determining, by an rApp in a Service Management Orchestration Framework (SMO), one or more Network Functions (NFs) hosted on at least one O-Cloud node to be instantiated on one or more other O-Cloud nodes. The method includes creating, by the rApp, an instantiation policy for the determined one or more NFs for an O-Cloud Resource Management and Orchestration Service (ORMOS). ORMOS may include a Network Function Orchestrator (NFO) and a Federated O-Cloud Orchestration and Management (FOCOM). The method includes sending, by the rApp, the instantiation policy to ORMOS via an R1 interface. The method includes requesting, by ORMOS, an instantiation implementation (perform instantiation) of the determined one or more NFs from at least one O-Cloud management service via an O2 interface based on the instantiation policy. The method includes, upon receiving an implementation request (execution request), instantiating, by at least one O-Cloud management service, one or more NFs on one or more other O-Cloud nodes according to the implementation request. The at least one O-Cloud management service may include a deployment management service (DMS) and an infrastructure management service (IMS). The method includes sending, by the at least one O-Cloud management service, registration and configuration requests for the instantiated one or more NFs to an NF-associated Radio Access Network (RAN) Operations, Administration, and Maintenance (OAM) service. The method includes sending, by the NF-associated RAN OAM service, configuration notifications for the instantiated one or more NFs to ORMOS based on the registration and configuration requests. The method includes sending, by ORMOS, instructions to the at least one O-Cloud management service to complete the instantiation implementation of the one or more NFs determined.

[0021] 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 learned by practice of presented embodiments of the present disclosure.

[0022] Features, aspects, and advantages of certain exemplary embodiments of the present disclosure are described below with reference to the accompanying drawings, in which like reference numerals refer to like elements. [Brief explanation of the drawings]

[0023] [Figure 1] FIG. 1 illustrates an O-RAN architecture according to the related art.

[0024] [Figure 2] FIG. 1 illustrates an architecture of an SMO framework for implementing a policy-based framework for O-Cloud resource management and orchestration services, according to one or more example embodiments.

[0025] [Figure 3] 1 is a flowchart of a method for implementing a policy-based framework for O-Cloud resource management and orchestration services in a telecommunications network, according to one embodiment.

[0026] [Figure 4] 10 is a flowchart of a method for determining one or more NFs hosted on at least one O-Cloud node to be instantiated on one or more other O-Cloud nodes according to another embodiment.

[0027] [Figure 5] 10 is a flowchart of a method for instantiating one or more NFs on at least one O-Cloud according to an implementation request, according to another embodiment.

[0028] [Figure 6] 10 is a flowchart of a method for creating one or more NFs on one or more other O-Cloud nodes for each of the one or more created NFs according to another embodiment.

[0029] [Figure 7] 10 is a flowchart of a method for completing instantiation implementation of one or more determined NFs according to another embodiment.

[0030] [Figure 8] 10 is a flowchart of a method for implementing the determined termination of one or more NFs according to another embodiment.

[0031] [Figure 9] 10 is a flowchart of a method for sending feedback to ORMOS for the determined termination of one or more NFs according to another embodiment.

[0032] [Figure 10] 1 is a process flowchart of a method for O-Cloud NF instantiation according to another embodiment.

[0033] [Figure 11] FIG. 1 is a diagram of an example environment in which the systems and / or methods described herein may be implemented.

[0034] [Figure 12] FIG. 2 is a diagram of exemplary components of a device according to one embodiment.

[0035] [Figure 13] FIG. 1 illustrates a tentative roadmap for identifying NFO / FOCOM related services for R1.

[0036] [Figure 14] FIG. 1 illustrates the proposed structure of the R1 interface.

[0037] [Figure 15] FIG. 1 is a diagram illustrating a RAN Sharing SLA Assurance Use Case.

[0038] [Figure 16] FIG. 1 illustrates a use case of policy-based fault finding and node draining. DETAILED DESCRIPTION OF THE INVENTION

[0039] In the following detailed description of the exemplary embodiments, reference will be made to the accompanying drawings, in which the same reference numbers in different drawings may identify the same or similar elements.

[0040] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of implementations. Furthermore, 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, in the flowcharts and descriptions of operations provided below, it should be understood that one or more operations may be omitted, one or more operations may be added, one or more operations may occur (at least partially) concurrently, and the order of one or more operations may be rearranged.

[0041] It will be apparent that the 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 limiting of the implementation. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It will be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

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

[0043] As used herein, no element, act, or instruction 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 elements (portions) and can be used interchangeably with "one or more." Where only one element (portion) is intended, the term "one" or similar language is used. Also, as used herein, terms such as "has," "have," "having," "include," and "including" are intended to be open-ended terms. Furthermore, the phrase "based on" is intended to mean "based at least in part on," unless specifically stated otherwise. Furthermore, phrases such as "at least one of A and B" or "at least one of A or B" should be understood to include only A, only B, or both A and B.

[0044] 2 illustrates an architecture of an SMO framework for implementing a policy-based framework for O-Cloud resource management and orchestration services, according to one or more exemplary embodiments. In particular, FIG. 2 illustrates an NRT-RIC framework (or platform), one or more rApps hosted by the NRT-RIC with respect to the R1 interface within the SMO framework system architecture, and the O1, O2, and A1 interfaces within the O-RAN for implementing the R1 policy-based framework for O-Cloud resource management and orchestration services, according to one or more exemplary embodiments.

[0045] 2, the NRT-RIC represents a subset of the functionality of the SMO framework. The NRT-RIC has access to other SMO framework functions, thereby affecting (i.e., controlling and / or executing) what is conveyed across the O1 and O2 interfaces (e.g., fault management (FM), configuration management (CM), and / or performance management (PM) execution).

[0046] The NRT-RIC includes an NRT-RIC framework, which includes, among other functions, R1 service exposure functions that handle R1 services (e.g., Service Management & Exposure (SME) functions, Data Management & Exposure (DME) functions, AI / ML workflow functions, A1-related service functions, etc.). For example, R1 services and related service procedures may include R1-Service Management & Exposure (SME) services, R1-Data Management & Exposure (DME) services, R1-A1 services, R1-O1 data services, R1-O2 data services, R1-AI / ML services, etc.). Among these R1 services, for example, the DME service distributes data created or collected by data producers (e.g., RAN NF Operations, Administration, and Maintenance (OAM) services within the SMO framework) to data consumers (e.g., rApps) according to their needs (e.g., fault management (FM), consumption management (CM), production management (PM)).

[0047] To this end, the NRT-RIC framework produces and / or consumes R1 services, and rApps are applications that leverage the functionality available in the NRT-RIC framework and / or the SMO framework to provide value-added services related to RAN operation and optimization. The scope of rApps includes, but is not limited to, radio resource management, data analysis, etc., and information enrichment.

[0048] Within the NRT-RIC framework, the rApp communicates with the SMO function via the R1 interface, which is an open logical interface between the rApp and the NRT-RIC framework of the NRT-RIC within the O-RAN architecture. The R1 interface supports the exchange of control signaling information between endpoints (e.g., an rApp and one or more NFs, or one or more O-Cloud nodes hosting an NF), as well as data collection and distribution.

[0049] Furthermore, the R1 interface is independent of specific SMO and NRT-RIC framework implementations. The R1 interface is defined in an extensible manner that allows new services and data types to be added without having to modify protocols or procedures (e.g., standardized protocols or procedures). In particular, the R1 interface facilitates interconnection between rApps provided by different vendors and the NRT-RIC framework (i.e., facilitates interconnection in a multi-vendor environment). To this end, the R1 interface provides a level of abstraction between rApps and the NRT-RIC framework and / or SMO framework (e.g., NFO and / or FOCOM).

[0050] 2, the NRT-RIC framework includes A1-related functions that communicate with nRT-RIC and O1 nodes (i.e., NFs such as O-CUs, VNFs and / or CNFs implementing O-DUs) via O1 and A1 interfaces. The A1-related functions of the NRT-RIC framework support, for example, A1 logical termination, A1 policy coordination and catalog, A1-EI coordination and catalog, etc.

[0051] Additionally, within the NRT-RIC framework, AI / ML workflow services provide access to AI / ML workflow processes. For example, the AI / ML workflow services can assist with model training, monitoring of AI / ML models deployed in the NRT-RIC, etc.

[0052] The NRT-RIC framework (eg, rApp) communicates with (eg, consumes or subscribes to) multiple SMO framework services (eg, SMO communicates with the NRT-RIC via the A2 interface).

[0053] For example, but not limited to, NF-related RAN OAM services (i.e., RAN NF OAM services) that collect (i.e., generate) OAM-related data such as fault management (FM), consumption management (CM), production management (PM), among others, from nRT-RIC and / or O1 nodes (i.e., network NFs such as O-CUs, VNFs and / or CNFs implementing O-DUs, etc.). In an example embodiment, the OAM-related data (i.e., data of NF-related OAM services) is collected via the O1 interface. Alternatively, the OAM-related data may be collected from the O-RU via the FH M plane interface.

[0054] Additionally, the NRT-RIC framework (e.g., rApp) communicates with (e.g., consumes or subscribes to) multiple O-Cloud resource management and orchestration services within the SMO framework. For example, but not limited to, the SMO may include, among others, a Network Function Orchestrator (NFO), Federated O-Cloud Orchestration and Management (FOCOM), etc., which manages virtual machine (VM)-based virtual network functions (VNFs) and / or quad-native network functions (CNFs) and container (i.e., instance)-based VNFs and / or CNFs.

[0055] In an example embodiment, O-Cloud Resource Management and Orchestration Services (ORMOS) may include services within the SMO framework that communicate with the NRT-RIC via the A2 interface.

[0056] In an example embodiment, O-Cloud Resource Management and Orchestration Services (ORMOS) (i.e., NFO / FOCOM) may be an O2-related function that communicates with O-Cloud management services, such as DMS and / or IMS, via an O2 interface as outlined in Figure 1. Additionally, in an example embodiment, NFO and FOCOM may communicate based on a common policy (R1 policy).

[0057] To enable ORMOS capability to implement a policy-based framework (i.e., an R1 policy-based framework), ORMOS must be able to expose SME data, receive and transform (e.g., analyze, interpret, evaluate, etc.) policies and actions for the O-Cloud infrastructure via O2-related interfaces, receive actions from rApps, implement said actions for the O-Cloud infrastructure via O2 interfaces, etc., and NFO and FOCOM must define the services provided by NFO / FOCOM via R1 interfaces that will be consumed by rApps.

[0058] To this end, for the implementation of the R1 policy-based framework, the R1 application protocol specification can include service descriptions, service procedures, resource (e.g., O-Cloud hardware-related resource) definitions, and application programming interface (API) definitions for various R1 services (e.g., R1 services to be produced / consumed by rApps) for the implementation of the R1 policy-based framework. Furthermore, an R1 interface can be defined to include specific R1 interface type specifications, such as data models and data types, to implement the R1 policy-based framework for ORMOS. The definition of these specific R1 interface types allows rApps with the NRT-RIC framework to push policies / changes to NFO / FOCOM via the R1 interface.

[0059] To this end, in one example embodiment, on the ORMOS side, FOCOM can include (fault, configuration, billing, performance, and security) FCAPS related services, which include O2 related IMS FCAPS services such as performance management (PM) services, which can provide O-Cloud infrastructure telemetry data to monitor the health of O-Cloud infrastructure components (e.g., O-Cloud servers), and O2 related data, such as O-Cloud infrastructure monitoring services, which can provide the status of network operations (e.g., performance, capacity, deployment status (i.e., number of NFs deployed on the O-Cloud) and resource utilization of the O-Cloud infrastructure.

[0060] Additionally, according to another exemplary embodiment, FOCOM FCAPS related services may include fault management (FM) services, including fault reporting related to the O-Cloud infrastructure.

[0061] Additionally, according to another example embodiment, the FOCOM FCAPS services may include a configuration management (CM) service that includes at least one reporting service for the O-Cloud infrastructure configuration schema (e.g., O-Cloud-related hardware inventory) and at least one provisioning service that modifies the O-Cloud-related hardware inventory in the context of infrastructure lifecycle management (in connection with infrastructure lifecycle management).

[0062] According to the FOCOM FCAPS as described above, ORMOS (i.e., FOCOM) can request information (e.g., O2-related data) related to O-Cloud Infrastructure Management Services (IMS) from the IMS. The information (e.g., O2-related data) can be provided by at least one of the O-Cloud IMS, such as, for example, an O-Cloud IMS performance measurement service, an infrastructure inventory service, an infrastructure monitoring service, a data infrastructure provisioning service, an infrastructure lifecycle management service, and an infrastructure software management service.

[0063] Further referring to ORMOS, in an example embodiment, the NFO may include FCAPS-related services (fault, configuration, billing, performance, and security), where the FCAPS services include O2-related DMS FCAPS services, such as information related to O-Cloud Deployment Management Services (DMS), such as deployment inventory services, deployment monitoring services, and deployment lifecycle management services.

[0064] Alternatively, ORMOS may collect (ie, generate or subscribe to) O-Cloud related performance data via other O-Cloud infrastructure performance related information channels (eg, external services).

[0065] In an example embodiment, the rApp may collect data indicative of usage patterns of at least one O-Cloud node and / or one or more NFs hosted thereon via multiple interfaces (i.e., via various information channels, e.g., via various subscriptions to services that generate usage pattern-related data), e.g., via at least one of an A1 interface, an A2 interface, an O1 interface (e.g., including 3GPP interfaces such as E1, F1, etc.), an O2 interface, an FH M-plane interface, etc.

[0066] FIG. 3 illustrates a flowchart of a method for implementing a policy-based framework for O-Cloud resource management and orchestration services in a telecommunications network, according to one embodiment.

[0067] Referring to FIG. 3, in step 301, an rApp within a Service Management Orchestration Framework (SMO) (i.e., within the NRT-RIC framework of the SMO framework) determines one or more Network Functions (NFs) hosted on at least one O-Cloud node that should be instantiated on one or more other O-Cloud nodes.

[0068] Referring to step 301, the decision of whether to instantiate one or more NFs on one or more other O-Cloud nodes in the O-Cloud may be triggered, for example, when a tenant operator of a telecommunications network (i.e., RAN) sends an updated service level agreement (SLA) from the telecommunications network provider (i.e., host operator) that defines the level of service expected by the tenant operator.

[0069] Alternatively, instantiation may be triggered by a degradation in NF performance on an O-Cloud node, a change in O-Cloud node inventory and / or RAN resources, and / or a change in the level of service metrics within the RAN, etc., and an R1 policy is created to resolve (resolve) the deviation between the current (poor or outdated) status and the intended (planned, updated, etc., or targeted) status.

[0070] According to an example embodiment, the tenant operator RAN shared rApp can send an updated service level agreement (SLA) to the host operator RAN shared rApp (i.e., the host operator's RAN shared rApp).

[0071] In this case, the rApp receives metrics describing the level of service for the updated SLA from the tenant operator RAN shared rApp. The level of service describes the metrics by which the service is measured (e.g., O1-related key performance indicators (KPIs), O2-related KPIs, etc.). Upon receipt, the rApp analyzes the metrics describing the level of service for the updated SLA. Analysis of the SLA includes interpreting it in terms of O-Cloud infrastructure requirements such as CPU, storage, memory, bandwidth (BW), etc.

[0072] Upon analysis, the rApp collects O1 related performance data for predicting expected RAN resource from NF related RAN OAM services and O2 related telemetry data of O-Cloud nodes from at least one O-Cloud management service (e.g., IMS and / or DMS).

[0073] For example, a hosted Operator RAN shared rApp may collect data (i.e., consume or subscribe to a service that provides the data) indicative of the usage patterns of at least one O-Cloud node and / or one or more NFs hosted thereon (e.g., the rApp may read telemetric data from at least one of the interfaces as outlined in Figures 1 and 2).

[0074] For example, the host operator RAN shared rApp may collect data indicative of usage patterns (e.g., performance data, KPI data, etc.) from NF-related Radio Access Network (RAN) Operations, Administration, and Maintenance (OAM) services, O-Cloud Resource Management and Orchestration Services (ORMOS), and / or at least one O-Cloud management service (e.g., IMS and / or DMS), e.g., as shown in Figures 1 and 2.

[0075] For example, data indicative of usage patterns (e.g., performance data, KPI data, etc.) may include O2-related data such as IMS and / or DMS telemetry data, inventory data, etc. Additionally, the host operator RAN shared rApp may collect O1-related data (e.g., performance data, KPI data, etc.) such as traffic data and / or user density data for forecasting expected O-Cloud resources to meet updated SLA levels of service expected from tenant operators.

[0076] The rApp then evaluates the necessary RAN resources to be reconfigured for instantiation of one or more NFs on the O-Cloud node inventory based on the collected data. Upon evaluation, the rApp determines one or more NFs to be instantiated on one or more other O-Cloud nodes. For example, the rApp analyzes and evaluates the existing (i.e., available) O-Cloud inventory to identify target nodes (i.e., one or more O-Cloud nodes) for creation (i.e., instantiation) of NFs (e.g., deployment CNFs) with updated resources (i.e., reconfigured O-Cloud nodes).

[0077] 3, in step 302, the rApp creates an instantiation policy (i.e., an R1 policy) for the determined one or more NFs for O-Cloud Resource Management and Orchestration Services (ORMOS). For example, ORMOS includes a Network Function Orchestrator (NFO) and a Federated O-Cloud Orchestration and Management (FOCOM).

[0078] In one example embodiment, an rApp may consume data indicating usage patterns generated by O2-related services via the O-Cloud DMS and input the data into an AI / ML model, where at least one AI / ML model algorithm may identify one or more NFs hosted on at least an O-Cloud node (e.g., one or more virtual machine (VM)-based virtual network functions (VNFs) and container (i.e., instance)-based cloud-native network functions (CNFs)).

[0079] In this case, the input data refers to usage patterns generated by at least one of a deployment inventory service, a deployment monitoring service, a deployment lifecycle management service, etc. Furthermore, the input data refers to usage patterns generated by a DMS service to provision changes to the configuration of the O-Cloud and services to obtain additional information related to the O-Cloud.

[0080] In an example embodiment, the rApp may consume usage patterns generated by O2-related services via the O-Cloud IMS. In this case, the at least one AI / ML model algorithm may identify, via the O2 interface, at least one physical host (e.g., hardware infrastructure such as a server, server cluster, etc.) in the O-Cloud infrastructure in the O-RAN architecture according to Figures 1 and 2. In this case, the input data refers to usage patterns generated by an infrastructure inventory service, an infrastructure monitoring service, an infrastructure provisioning service, an infrastructure lifecycle management service, an infrastructure software management service, etc.

[0081] In one example embodiment, to create an instantiation policy, an rApp may consume data indicating usage patterns generated by O2-related services via NFO FCAPS associated with O-Cloud DMS or via FOCOM FCAPS associated with O-Cloud IMS, as shown in FIG. 2.

[0082] The instantiation policy (i.e., R1 policy) may guide and identify one or more NFs hosted on at least an O-Cloud node (e.g., one or more virtual machine (VM)-based virtual network functions (VNFs) and container (i.e., instance)-based cloud-native network functions (CNFs)).

[0083] To this end, the capabilities of the NFO and FOCOM for establishing R1 interface-based communications to implement the R1 policy framework for ORMOS provide information for determining one or more NFs in step 302 .

[0084] Furthermore, the instantiation policy (i.e., R1 policy) may guide one of the following scenarios: instantiating an NF due to a tenant operator's updated SLA as described above; based on NF performance degradation in the O-Cloud inventory; based on changes in RAN resources and / or O-Cloud inventory; based on the level of service demand within the telecommunications network; etc.

[0085] In step 303, the rApp sends the instantiation policy to ORMOS via the R1 interface. For example, according to the SMO communication shown in Figure 2, the rApp sends the instantiation policy to ORMOS via the R1 interface within the NRT-RIC framework.

[0086] To this end, for implementation of the R1 policy-based framework, the R1 application protocol specification includes at least one of service descriptions, service procedures, resource (e.g., O-Cloud hardware-related resource) definitions, and API definitions for various R1 services (e.g., rApps). Furthermore, the R1 interface for the R1 policy-based framework for ORMOS defines a specification including at least one specific R1 interface type including one or more data models and one or more data types for implementing the R1 policy-based framework for ORMOS. The specific R1 interface type enables rApps in the NRT-RIC framework to communicate (e.g., push) policies / changes to NFO / FOCOM via the R1 interface.

[0087] Furthermore, as shown in Figure 2, FOCOM and NFO have the ability to communicate with rApps (i.e., publishing data to rApps) via the R1 interface, receive R1 policies and actions from rApps, interact (i.e., establishing interactions between FOCOM and NFO-related services), etc., to implement policies and actions within the O-Cloud infrastructure via the O2 interface.

[0088] In step 304, ORMOS requests instantiation implementation of the determined one or more NFs from at least one O-Cloud management service via an O2 interface based on the instantiation policy. For example, the instantiation implementation request (instantiation execution request) can be sent to at least one O-Cloud management service including a deployment management service (DMS) and an infrastructure management service (IMS) via the O2 interface.

[0089] In step 305, upon receiving the implementation request (execution request), at least one O-Cloud management service instantiates one or more NFs on one or more other O-Cloud nodes according to the implementation request.

[0090] In an example embodiment, during instantiation, the DMS and IMS may communicate with the NFO and FOCOM, respectively (eg, the DMS communicates with the NFO, and the IMS communicates with the FOCOM).

[0091] For example, when instantiating one or more NFs on at least one O-Cloud node according to an implementation request (implementation request), the NFO, based on the received instantiation policy, sends an implementation request to the DMS to deploy the one or more NFs determined according to the received instantiation policy on one or more other O-Cloud nodes. In response to receiving the deployment instruction, the DMS can create one or more NFs on the other one or more O-Cloud nodes.

[0092] To this end, the NFO FCAPS service provides O2-related DMS services including at least one of a deployment inventory service, a deployment monitoring service, and a deployment lifecycle management service.

[0093] In step 306, the at least one O-Cloud management service sends a registration and configuration request for the instantiated one or more NFs to an NF-associated Radio Access Network (RAN) Operation, Administration, and Maintenance (OAM) service.

[0094] In step 307, based on the registration and configuration request, the NF-associated RAN OAM service sends a configuration notice of the instantiated NF(s) to the ORMOS.

[0095] In step 308, ORMOS sends an instruction to at least one O-Cloud management service to complete instantiation implementation of the determined one or more NFs.

[0096] For example, when finalizing the instantiation implementation of the determined one or more NFs, at least one O-Cloud management service (IMS / DMS) performs the termination of the determined one or more NFs on at least one O-Cloud node.

[0097] According to an example embodiment, when implementing the termination of the determined one or more NFs, the NFO may send a request to the DMS to terminate the determined one or more NFs on at least one O-Cloud. The DMS may send a termination confirmation notification in response to the termination of the determined one or more NFs. Upon receipt, the NFO may send the termination confirmation notification to the FOCOM. Based on the termination confirmation notification, the FOCOM may send an implementation request to the IMS to unload at least one O-Cloud node hosting the terminated one or more NFs.

[0098] To this end, the FOCOM FCAPS service provides O2-related IMS services including at least one of an O-Cloud IMS performance measurement service, an infrastructure inventory service, an infrastructure monitoring service, a data infrastructure provisioning service, an infrastructure lifecycle management service, and an infrastructure software management service.

[0099] Based on an implementation request to unload at least one O-Cloud node hosting one or more terminated NFs, the IMS may command the draining and / or cordoning of the at least one O-Cloud node.

[0100] Furthermore, according to an exemplary embodiment, when completing the instantiation implementation of the determined one or more NFs, if the termination of the determined one or more NFs on the at least one O-Cloud node is performed, the at least one O-Cloud management service sends feedback regarding the termination of the determined one or more NFs on the at least one O-Cloud node to ORMOS.

[0101] 3, a method for implementing a policy-based framework for ORMOS advantageously provides guidance to ORMOS on how to instantiate NFs (i.e., VNFs and / or CNFs) based on multiple scenarios, which may include, among other scenarios, effective implementation of SLA changes and energy-efficient and, in the O-Cloud, resource-optimized operation that adheres to metrics defined in the SLA without degrading the performance of the NFs and / or O-Cloud nodes, thereby enabling optimal (e.g., energy-efficient, resource-optimized, resilience-optimized, etc.) operational performance of the O-RAN.

[0102] FIG. 4 shows a flowchart of a method for determining one or more NFs hosted on at least one O-Cloud node to be instantiated on one or more other O-Cloud nodes according to another embodiment.

[0103] Referring to FIG. 4, in step 401, the rApp receives metrics describing the level of service of an updated service level agreement (SLA).

[0104] In step 402, the rApp analyzes metrics that describe the level of service of the updated service level agreement (SLA).

[0105] In step 403, the rApp collects O1-related performance data for predicting expected RAN resources from NF-related RAN OAM services and O2-related telemetry data of O-Cloud node inventory from at least one O-Cloud management service.

[0106] In step 404, the rApp evaluates the required RAN resources to be reconfigured for the instantiation of one or more NFs on the O-Cloud node inventory based on the collected data.

[0107] In step 405, the rApp determines, based on the evaluation, one or more NFs to be instantiated on one or more other O-Cloud nodes.

[0108] 4, a method for determining one or more NFs hosted on at least one O-Cloud node to be instantiated on one or more other O-Cloud nodes enables the collection of O1-related performance data and O2-related telemetry data of the O-Cloud node inventory to predict expected RAN resources. This enables the rApp to create accurate policies for ORMOS that take into account the actual RAN operating status of the NFs (e.g., traffic load, number of users, etc., and the impact of an NF outage on other NFs, as well as the resource status of the O-Cloud node inventory hosting the NFs. This has the advantage that the rApp can create optimal policies for envisioned operating scenarios, e.g., for service level changes due to SLA updates in the RAN.

[0109] 5 shows a flowchart of a method for instantiating one or more NFs on at least one O-Cloud according to an implementation request according to another embodiment. Referring to FIG. 5, when instantiating one or more NFs on at least one O-Cloud according to an implementation request, in step 501, the NFO sends an instruction to the DMS to deploy one or more NFs determined on one or more other O-Cloud nodes according to the received instantiation policy.

[0110] In step 502, upon receiving the deployment instruction, the DMS creates (ie, deploys, instantiates) one or more NFs (eg, CNFs) on one or more other O-Cloud nodes.

[0111] For example, when creating (i.e., deploying, instantiating) one or more NFs (e.g., CNFs) on one or more other O-Cloud nodes, the NFO via the DMS may perform a sanity and health check on the new NFs, e.g., based on at least one O-Cloud-related data (e.g., telemetric data) received via the O2 interface and / or O-RAN-related data (e.g., telemetric data) received via the O1 interface (i.e., the O1-related data may be available after registration and configuration of the new NFs in the NF-associated RAN OAM services according to step 306 of FIG. 3 or FIG. 6).

[0112] FIG. 6 shows a flowchart of a method for creating one or more NFs on one or more other O-Cloud nodes for each of the created one or more NFs according to another embodiment.

[0113] Referring to FIG. 6, when creating one or more NFs on one or more other O-Cloud nodes, for each of the one or more created NFs, in step 601, each of the one or more created NFs sends an NF registration and configuration request to the NF-associated RAN OAM service.

[0114] In step 602, the NF-associated RAN OAM service registers and configures each of the one or more created NFs in response to receiving the NF registration and configuration request.

[0115] In step 603, the NF-associated RAN OAM service sends a configuration confirmation notification to the NFO for each of the one or more NFs created.

[0116] For example, upon completing a sanity and health check on the new NF based on a configuration confirmation notification for each of the one or more created NFs to the NFO, the NFO may determine that the sanity and health check on the new NF is successful. For example, the NFO performs a check of the performance of the NF and the hardware resources of the O-Cloud node hosting the NF in the O-RAN. To this end, the NFO instructs the DMS to divert traffic from the NF to be moved to the new NF. When the NFO via the DMS determines that all traffic from the NF to be moved has been diverted to the new NF, the NFO can communicate with the FOCOM, and the FOCOM prepares to drain the O-Cloud node (i.e., unload the O-Cloud node).

[0117] Referring to Figure 6, the created configuration confirmation notification to the NFO for each of one or more NFs enables the NFO to communicate information regarding the registration and confirmation of NF-related RAN OAM services to the FOCOM. This allows the information to be communicated to the IMS, enabling a round-robin exchange of information between the NFO, DMS, FOCOM, and IMS to enforce common policies. As a result, an R1 policy-based framework can be effectively implemented for ORMOS.

[0118] 7 shows a flowchart of a method for completing instantiation implementation of one or more determined NFs according to another embodiment. Referring to FIG. 7, when completing instantiation implementation of one or more determined NFs, in step 701, at least one O-Cloud management service performs termination of the determined one or more NFs on at least one O-Cloud node.

[0119] In step 702, at least one O-Cloud management service sends feedback to ORMOS regarding the determined termination of one or more NFs on at least one O-Cloud node.

[0120] Referring to FIG. 7, feedback of the determined termination of one or more NFs on at least one O-Cloud node to ORMOS includes, for example, performing sanity and health checks on the new NFs based on O-RAN-related (KPI) data (e.g., telemetric data) received via the O1 interface, including registration and configuration of the new NFs from the NF-associated RAN OA to optimize the efficiency of NF deployment (instantiation) on the O-Cloud node for optimal RAN operation.

[0121] 8 shows a flowchart of a method for terminating one or more determined NFs according to another embodiment. Referring to FIG. 8, when terminating one or more determined NFs, in step 801, the NFO sends a request to the DMS to terminate one or more determined NFs on at least one O-Cloud.

[0122] In step 802, the DMS sends a termination acknowledgement when the determined one or more NFs are terminated. Similar to the embodiment described above with reference to Figure 6, the DMS diverts all traffic at this point and sends a termination acknowledgement.

[0123] In step 803, the NFO sends a completion confirmation to the FOCOM.

[0124] In step 804, based on the NFO termination confirmation notification, FOCOM sends an implementation request (implementation request) to IMS to unload at least one O-Cloud node.

[0125] For example, FOCOM prepares to drain and cordon the O-Cloud node that hosted the old NF.

[0126] To this end, the FOCOM FCAPS service provides O2-related IMS services including at least one of an O-Cloud IMS performance measurement service, an infrastructure inventory service, an infrastructure monitoring service, a data infrastructure provisioning service, an infrastructure lifecycle management service, and an infrastructure software management service.

[0127] In step 805, upon receiving the implementation request to unload, the IMS commands the drain and / or cordon of at least one O-Cloud node.

[0128] For example, based on the termination confirmation notification from the NFO, FOCOM determines that all traffic from the NF to be moved will be diverted to the new NF. The IMS drains and / or cordons at least one O-Cloud node and notifies FOCOM that the NF instantiation is complete (e.g., the new CNF is running on the new O-Cloud node and the O-Cloud node that hosted the old CNF is drained and cordoned). To this end, FOCOM FCAPS also provides feedback to the rApp regarding inventory status.

[0129] Referring to Figure 8, the interaction between NFO and FOCOM (e.g., between NFO, DMS, FOMO, and IMS to enforce common policies) has the advantage that an R1 policy-based framework can be effectively implemented for ORMOS to optimize the efficiency of NF deployment (instantiation) on O-Cloud nodes for optimal RAN operation.

[0130] FIG. 9 illustrates a flowchart of a method for sending feedback to ORMOS for the determined termination of one or more NFs according to another embodiment.

[0131] Referring to Figure 9, when sending feedback to ORMOS regarding the determined termination of one or more NFs, in step 901, the IMS sends an unload confirmation notification to FOCOM when it unloads at least one O-Cloud node (if it has unloaded it).

[0132] In step 902, FOCOM sends instantiation policy feedback to the rApp based on the unload confirmation.

[0133] In an example embodiment, the feedback is based on data received from ORMOS (e.g., FOCOM) or results from an update of the O-Cloud deployment inventory based on a reconfigured O-Cloud node and / or one or more NFs hosted thereon after deployment (e.g., after instantiation) (i.e., feedback based on O-Cloud IMS service data pointing to at least one O-Cloud node after the inventory update).

[0134] Based on the feedback in an example embodiment, the rApp can apply an AI / ML model (e.g., a reinforcement learning model configured to update data pointing to the R1 policy based on feedback to the rApp, where the feedback includes at least one of O-Cloud node-related data received via the O2 interface (and / or NF-related data received via the O1 interface).

[0135] Referring to FIG. 9, the closed-loop control operation of updating data related to R1 policies based on feedback to the rApp has the advantage that it is possible to optimize the instantiation (deployment) of NFs based on different trigger scenarios defined by different R1 policies (e.g., RAN operation scenarios such as SLA updates, environmental changes, infrastructure changes, behavioral usage changes, etc.).

[0136] 10 shows a process flowchart of a method for O-Cloud NF instantiation according to another embodiment. Referring to FIG. 10, in operation 1, an rApp (e.g., a host operator rApp) collects O1-related data, for example, referring to a reported (e.g., bad) performance degradation of an NF from an NF-related RAN OAM service.

[0137] In operation 2, an rApp (e.g., a host operator rApp) collects O2-related data (e.g., IMS and / or DMS telemetry data from ORMOS (e.g., collects O2-related data from DMS and / or IMS via FOCOM FCAPS and / or NFO FCAPS according to operation 2').

[0138] In operation 3, the rApp creates an R1 policy for a RAN operation scenario (e.g., updating a tenant operator's SLA).

[0139] In operation 4, the rApp sends the R1 policy to ORMOS.

[0140] In operation 5, the NFO collects data from the DMS to prepare for instantiation of a new NFS (eg, CNF) on the O-Cloud node according to the O-Cloud infrastructure (eg, via NFO FCAPS).

[0141] In operation 6, the NFO requests (e.g., to the NF-associated RAN OAM service via NFO FCAPS) the deployment (instantiation) of a new NFS (e.g., CNF) on the O-Cloud node.

[0142] In operation 7, each of the created (deployed, instantiated) NFS registers in the NF-associated RAN OAM service is configured according to its role (e.g., as an E2 node, such as an O-CU, O-DU, etc.).

[0143] In operation 8, the NF-associated RAN OAM service sends a configuration notification of the instantiated NF(s) to ORMOS. The configuration notification of the instantiated NF(s) may be used for sanity and health check of the new NF(s) in the NFO.

[0144] In operation 9, the NFO sends a request to the DMS to terminate the determined one or more NFs on at least one O-Cloud. For example, if the sanity and health check of the new NF is successful, the NFO instructs the DMS to divert all traffic from the old NF (CNF) to the new NF (CNF). Once all traffic of the old NF (CNF) has been diverted to the new NF (CNF), the DMS confirms the traffic diversion to the NFO.

[0145] In operation 10, upon receiving DMS confirmation that all traffic has been diverted to the NFO, the NFO communicates confirmation of creation and termination of all traffic to the old NF to the FOCOM.

[0146] In operation 11, FOCOM requests IMS to drain and cordon one or more O-Cloud nodes that originally hosted the old (terminated) NF. Upon unloading and cordoning one or more O-Cloud nodes, IMS sends an acknowledgement to FOCOM. (For example, the acknowledgement may include inventory information and / or feedback for the termination.)

[0147] In operation 12, ORMOS (eg, FOCOM) sends policy (ie, R1 policy) feedback to the rApp.

[0148] Referring to FIG. 10, the method for O-Cloud NF instantiation based on the R1 policy for ORMOS according to actions 1 to 11 has the advantage of guidance on how to instantiate NFs (i.e., VNFs and / or CNFs) to achieve optimal (e.g., energy-efficient, resource-optimized, resilience-optimized, etc.) operational performance of the O-RAN.

[0149] 11 is a diagram of an example environment 1100 in which the systems and / or methods described herein may be implemented. As shown in FIG. 11, environment 1100 may include a user device 1110, a platform 1120, and a network 1130. The devices in environment 1100 may be interconnected via wired connections, wireless connections, or a combination of wired and wireless connections. In an embodiment, any of the functions and operations described with reference to FIGS. 1-10 above may be performed by any combination of elements shown in FIG. 11.

[0150] The user device 1110 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information related to the platform 1120. For example, the user device 1110 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 smartphone, a wireless phone, etc.), a wearable device (e.g., smart glasses or a smart watch), or a similar device. In some implementations, the user device 1110 may receive information from and / or transmit information to the platform 1120.

[0151] Platform 1120 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information. In some implementations, platform 1120 may include a cloud server or a group of cloud servers. In some implementations, platform 1120 may be designed to be modular, such that particular software components can be swapped in or out depending on particular needs. As such, platform 1120 may be easily and / or quickly reconfigured for different uses.

[0152] In some implementations, as shown, platform 1120 may be hosted in a cloud computing environment 1122. In particular, although the implementations described herein describe platform 1120 as being hosted within cloud computing environment 1122, in some implementations platform 1120 may not be cloud-based (i.e., may be implemented outside of a cloud computing environment) or may be partially cloud-based.

[0153] Cloud computing environment 1122 includes an environment that hosts platform 1120. Cloud computing environment 1122 can provide services such as computation, software, data access, storage, etc. that do not require end-user (e.g., user device 1110) knowledge of the physical location and configuration of the systems and / or devices that host platform 1120. As shown, cloud computing environment 1122 can include a group of computing resources 1124 (collectively referred to as “computing resources 1124” and individually referred to as “each computing resource 1124”).

[0154] Each computing resource 1124 includes one or more personal computers, clusters of computing devices, workstation computers, server devices, or other types of computing and / or communication devices. In some implementations, each computing resource 1124 can host platform 1120. Cloud resources may include compute instances executing within each computing resource 1124, storage devices provided within each computing resource 1124, data transfer devices provided by each computing resource 1124, etc. In some implementations, each computing resource 1124 may communicate with other computing resources 1124 via wired connections, wireless connections, or a combination of wired and wireless connections.

[0155] As further shown in FIG. 11, each computing resource 1124 includes a group of cloud resources such as one or more applications (APPs) 1124-1, one or more virtual machines (VMs) 1124-2, virtualized storage (VS) 1124-3, and one or more hypervisors (HYPs) 1124-4.

[0156] Applications 1124-1 include one or more software applications that may be provided to or accessed by user device 1110. Applications 1124-1 may obviate the need to install and run software applications on user device 1110. For example, applications 1124-1 may include software associated with platform 1120 and / or any other software that may be provided via cloud computing environment 1122. In some implementations, one application 1124-1 may send information to or receive information from one or more other applications 1124-1 via virtual machine 1124-2.

[0157] Virtual machine 1124-2 includes a software-implemented machine (e.g., a computer) that executes programs like a physical machine. Virtual machine 1124-2 can be either a system virtual machine or a process virtual machine, depending on the application and the degree to which virtual machine 1124-2 represents an actual machine. A system virtual machine can provide a complete system platform that supports the execution of a complete operating system (OS). A process virtual machine can execute a single program and support a single process. In some implementations, virtual machine 1124-2 can run on behalf of a user (e.g., user device 1110) and manage the infrastructure of cloud computing environment 1122, such as data management, synchronization, or long-duration data transfer.

[0158] Virtualized storage 1124-3 includes one or more storage systems and / or one or more devices that use virtualization technology within the storage system or device of each computing resource 1124. In some implementations, in the context of storage systems, types of virtualization may include block virtualization and file virtualization. Block virtualization may refer to the abstraction (or separation) of logical storage from physical storage so that the storage system can be accessed regardless of the physical storage or heterogeneous structure. Separation may provide storage system administrators with flexibility in how they manage storage for end users. File virtualization may eliminate the dependency between data accessed at the file level and where the file is physically stored. This may enable performance optimization of storage usage, server consolidation, and / or non-disruptive file migration.

[0159] The hypervisor 1124-4 may provide hardware virtualization technology that allows multiple operating systems (e.g., guest operating systems) to run simultaneously on a host computer, such as each computing resource 1124. The hypervisor 1124-4 may present a virtual operating platform to the guest operating systems and may manage the execution of the guest operating systems. Multiple instances of various operating systems may share virtualized hardware resources.

[0160] Network 1130 may include one or more wired and / or wireless networks. For example, network 1130 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., a public switched telephone network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, an optical fiber-based network, etc., and / or a combination of these or other types of networks.

[0161] The number and arrangement of devices and networks shown in Figure 11 are provided as an example. In practice, there may be additional, fewer, different, or differently arranged devices and / or networks than those shown in Figure 11. Furthermore, two or more devices shown in Figure 11 may be implemented within a single device, or a single device shown in Figure 11 may be implemented as multiple distributed devices. Additionally, or instead, a set of devices (e.g., one or more devices) of environment 1100 may perform one or more functions that are described as being performed by another set of devices of environment 1100.

[0162] 12 is a diagram of example components of device 1200. Device 1200 may correspond to user device 1110 and / or platform 1120. As shown in FIG. 12, device 1200 may include a bus 1210, a processor 1220, a memory 1230, a storage component 1240, an input component 1250, an output component 1260, and a communication interface 1270.

[0163] Bus 1210 includes components that enable communication between components of device 1200. Processor 1220 may be implemented in hardware, firmware, or a combination of hardware and software. Processor 1220 may be a central processing unit (CPU), graphics processing unit (GPU), accelerated processing unit (APU), microprocessor, microcontroller, digital signal processor (DSP), field programmable gate array (FPGA), application specific integrated circuit (ASIC), or another type of processing component. In some implementations, processor 1220 includes one or more processors that can be programmed to perform functions. Memory 1230 includes random access memory (RAM), read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, and / or optical memory) that stores information and / or instructions used by processor 1220.

[0164] Storage component 1240 stores information and / or software related to the operation and use of device 1200. For example, storage component 1240 may include a hard disk (e.g., a magnetic disk, optical disk, magneto-optical disk, and / or solid-state disk), a compact disk (CD), a digital versatile disk (DVD), a floppy disk, a cartridge, magnetic tape, and / or another type of non-transitory computer-readable medium, along with a corresponding drive. Input component 1250 includes components that enable device 1200 to receive information, such as via user input (e.g., a touchscreen display, a keyboard, a keypad, a mouse, buttons, switches, and / or a microphone). Additionally or alternatively, input component 1250 may include sensors for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, and / or an actuator). Output component 1260 includes components that provide output information from device 1200 (e.g., a display, a speaker, and / or one or more light-emitting diodes (LEDs)).

[0165] Communications interface 1270 includes transceiver-like components (e.g., a transceiver and / or a separate receiver and transmitter) that enable device 1200 to communicate with other devices via wired connections, wireless connections, or a combination of wired and wireless connections, etc. Communications interface 1270 may enable device 1200 to receive information from and / or provide information to another device. For example, communications interface 1270 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi interface, a cellular network interface, etc.

[0166] Device 1200 may perform one or more processes described herein. Device 1200 may perform these processes in response to processor 1220 executing software instructions stored by a non-transitory computer-readable medium, such as memory 1230 and / or storage component 1240. A computer-readable medium is defined herein as a non-transitory memory device. A memory device includes memory space within a single physical storage device or memory space spread across multiple physical storage devices.

[0167] The software instructions may be loaded into memory 1230 and / or storage component 1240 from another computer-readable medium or from another device via communication interface 1270. When executed, the software instructions stored in memory 1230 and / or storage component 1240 may cause processor 1220 to perform one or more processes described herein.

[0168] Additionally, or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement one or more processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.

[0169] The number and arrangement of components shown in Figure 12 are provided as an example. In practice, device 1200 may include additional, fewer, different, or differently arranged components than those shown in Figure 12. Additionally or alternatively, a set of components (e.g., one or more components) of device 1200 may perform one or more functions that are described as being performed by another set of components of device 1200.

[0170] In an embodiment, any one of the operations or processes of FIGS. 1-10 may be implemented by or using any one of the elements shown in FIGS.

[0171] The exemplary embodiments may be implemented according to the following description. O-Cloud Optimization Framework WG1 SMO Decoupled TR Problem statement The SMO Decoupled TR does not define use cases for data collection, policy-based changes, or configuration changes to NFO and FOCOM. The ability to publish data from NFO / FOCOM to rApp via SME is not defined. The data type NFO / FOCOM must be collected from the O-Cloud via an O2 interface that is not defined in the TR. The ability to receive policies or actions from the northbound is not defined. The required interaction between NFO and FOCOM to perform certain actions such as node draining FOCOM shall query NFO to idle O-Cloud nodes by relocating NFs from one node to other. The capability of non-RT RIC SMOs needs to be defined to push policy or changes to NFO / FOCOM via the R1 interface via O2 related functions (which can be renamed ORMO related functions). There are no use cases under non-RT RIC SMO that show how an rApp can push policies / changes to NFO / FOCOM. NFO and FOCOM capabilities for policy-based frameworks Network Function Orchestration SMOS (NFO) NFO SMOS capabilities include: Receives and responds to policies from non-RT RICs and enforces them towards the O-Cloud via the O2 interface Reports O-Cloud deployment telemetry to other SMOs such as DME, topology and inventory related SMOs, non-RT RIC SMOs, etc. Federated O-Cloud Orchestration and Management SMOS (FOCOM) FOCOM SMOS capabilities include: Receives and responds to policies from non-RT RICs and enforces them towards the O-Cloud via the O2 interface Reports O-Cloud deployment telemetry to other SMOs such as DME, topology and inventory related SMOs, non-RT RIC SMOs, etc. Figure 13 shows a tentative roadmap for identifying NFO / FOCOM related services for R1. Figure 14 shows the proposed structure of the R1 interface. RAN shared SLA guaranteed use case #RAN Shared SLA Policy { ”policy_id”:”1”, "Scope":{ ”Actor”:NFO ”oCloudId”:”ABx65201” “globalcloudId”:”GCx909034598” }, "Statement":{ ”Operation”:”NF create” ”target”:{ ”targettype”:”CNF” “O-RANNFtype”:”O-CU-UP” ”policy_id”:”2”, "Scope":{ ”Actor”:NFO ”oCloudId”:”ABx65201” “globalcloudId”:”GCx909034598” “cnfcInstanceID”:”CNFxCD0090 }, "Statement":{ “Operation”:”NF Terminate” ”target”:{ ”targettype”:”CNF” “O-RANNFtype”:”O-CU-UP” } } Figure 15 shows the RAN Sharing SLA Assurance use case. Policy-based fault detection and node draining use cases #Node drain policy { ”policy_id”:”1”, "Scope":{ "Actor":FOCOM “oCloudId”:”ABx65201”, “globalcloudId”:”GCx909034598” }, "Statement":{ “Operation”:”Drain O-Cloud Node” ”target”:{ ”targettype”:”VM” ”policy_id”:”2”, "Scope":{ ”Actor”:NFO ”oCloudId”:”ABx45201” “globalcloudId”:”GCx789034598” }, "Statement":{ ”Operation”:”NF create” ”target”:{ ”targettype”:”CNF” ”NFtype”:”O-DU” ”policy_id”:”3”, "Scope":{ ”Actor”:NFO ”oCloudId”:”ABx65201” “globalcloudId”:”GCx909034598” “cnfcInstanceID”:”CNFxCD0090 }, "Statement":{ “Operation”:”NF Terminate” ”target”:{ ”targettype”:”CNF” ”O-RANNFtype”:”O-DU” } Figure 16 shows the use case of policy-based fault detection and node draining. Appendix Services from NFO and FOCOM In order to collect data and provision changes, data types must be identified which are registered with the DME. Data types can be divided into two types of FCAPS related to the O-Cloud: FOCOM related FCAPS service (o2ims FCAPS service) The PM may include: An O-Cloud infrastructure monitoring service that can provide infrastructure telemetry to monitor the health of O-Cloud infrastructure components. Network operations are interested in discovering whether all components in the O-Cloud infrastructure are operating properly and at what capacity, how many deployments are running on each node, as well as resource utilization of the O-Cloud infrastructure. FM shall include reporting of infrastructure faults CM services may include: Reporting infrastructure configuration schemas such as inventory Provisioning changes related to infrastructure lifecycle management. To obtain information related to O-Cloud infrastructure management services, such as: O-Cloud IMS performance measurement Infrastructure inventory. Infrastructure monitoring. Infrastructure provisioning. Infrastructure lifecycle management. Infrastructure software management. NFO related services (o2dms related services) To obtain information related to O-Cloud deployment management services, such as: Deployment inventory. Deployment monitoring. Deployment lifecycle management.

[0172] It will be appreciated that other embodiments may be implemented in a variety of different architectures, including, but not limited to, bare metal architectures and any cloud-based or deployment architecture, such as Kubernetes, Docker, OpenStack, etc.

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

[0174] Some embodiments may relate to systems, methods, and / or computer-readable media at any possible level of technical detail. Furthermore, 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 for causing a processor to perform operations.

[0175] A computer-readable storage medium may 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 computer-readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD), memory stick, floppy disk, mechanically encoded devices such as punch cards or ridge-in-groove structures having instructions recorded thereon, and any suitable combination of the foregoing. Computer-readable storage medium, as used herein, should not be construed as being a transitory signal per se, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse passing through a fiber optic cable), or an electrical signal transmitted through a wire.

[0176] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface within each computing / processing device receives the 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.

[0177] The computer-readable program code / instructions for carrying out operations may be either source code or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or object-oriented programming languages ​​such as Smalltalk, C++, and procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) may execute computer-readable program instructions to personalize the electronic circuitry by utilizing state information of the computer-readable program instructions to perform aspects or operations.

[0178] These computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, form means for implementing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may also be stored on a computer-readable storage medium that can instruct a computer, programmable data processing apparatus, and / or other device to function in a particular way, such that the computer-readable storage medium on which the instructions are stored comprises an article of manufacture containing instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0179] The computer-readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device to cause the computer, other programmable apparatus, or other device to perform a series of operational steps to create a computer-implemented process, such that the instructions, executing on the computer, other programmable apparatus, or other device, perform the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0180] The flowcharts 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 flowcharts or block diagrams may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing a particular logical function. The methods, computer systems, and computer-readable media may include additional, fewer, different, or differently arranged blocks than those shown 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 actually be executed concurrently or substantially concurrently, or the blocks may be executed in the reverse order, depending on the functionality involved. It should also be noted that each block in the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a dedicated hardware-based system that performs the specified functions or operations or executes a combination of dedicated hardware and computer instructions.

[0181] It will be apparent that the 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 limiting of the implementation. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It will be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

[0182] Various further respective aspects and features of embodiments of the present disclosure can be defined by the following clauses. Item [1] A system including an rApp, at least one O-Cloud management service, an NF-related RAN OAM service, and an O-Cloud Resource Management and Orchestration Service (ORMOS), wherein the system is configured to determine, by an rApp in a Service Management Orchestration Framework (SMO), one or more Network Functions (NFs) hosted on at least one O-Cloud node to be instantiated on one or more other O-Cloud nodes, and the system is configured, by the rApp, to create an instantiation policy for the determined one or more NFs for the O-Cloud Resource Management and Orchestration Service (ORMOS), wherein the ORMOS may include a Network Function Orchestrator (NFO) and a Federated O-Cloud Orchestration and Management (FOCOM). The system is configured such that the rApp sends an instantiation policy to ORMOS via the R1 interface, and the system is configured such that, based on the instantiation policy, ORMOS requests instantiation implementation of one or more NFs determined via the O2 interface from at least one O-Cloud management service, and upon receiving the implementation request (implementation request), the system is configured such that the at least one O-Cloud management service instantiates one or more NFs on one or more other O-Cloud nodes according to the implementation request, and the at least one O-Cloud management service may include a deployment management service (DMS) and an infrastructure management service (IMS).The system is configured to send, by the at least one O-Cloud management service, registration and configuration requests for the one or more instantiated NFs to an NF-associated Radio Access Network (RAN) Operations, Administration, and Maintenance (OAM) service; the system is configured to send, by the NF-associated RAN OAM service, configuration notifications for the one or more instantiated NFs to ORMOS based on the registration and configuration requests; and the system is configured to send, by ORMOS, instructions to the at least one O-Cloud management service to complete instantiation implementation of the one or more determined NFs. Item [2] The system configured to determine one or more NFs hosted on at least one O-Cloud node to be instantiated on one or more other O-Cloud nodes may further be configured to: receive, by an rApp, metrics describing a level of service of an updated Service Level Agreement (SLA); analyze, by the rApp, the metrics describing the level of service of the updated Service Level Agreement (SLA); collect, by an App, O1-related performance data for predicting expected RAN resources from an NF-related RAN OAM service and O2-related telemetry data of an O-Cloud node inventory from at least one O-Cloud management service; based on the collected data, evaluate, by the rApp, required RAN resources to be reconfigured for instantiation of one or more NFs on the O-Cloud node inventory; and based on the evaluation, determine, by the rApp, one or more NFs to be instantiated on one or more other O-Cloud nodes. Item [3] The system configured to instantiate one or more NFs on at least one O-Cloud according to an implementation request (implementation request) may be further configured to: send, by the NFO, an instruction to the DMS to deploy one or more NFs determined according to the received instantiation policy on one or more other O-Cloud nodes; and upon receiving the deployment instruction, create, by the DMS, one or more NFs on the other one or more O-Cloud nodes. The system described in Item [1] or [2]. Item [4] The system configured to create one or more NFs on one or more other O-Cloud nodes for each of the one or more created NFs may further be configured to: send an NF registration and configuration request to an NF-related RAN OAM service by each of the one or more created NFs; and, upon receiving the NF registration and configuration request, register and configure each of the one or more created NFs by the NF-related RAN OAM service; and send a configuration confirmation notification for each of the one or more created NFs to the NFO by the NF-related RAN OAM service. The system described in Item [3] may be further configured to: Item [5] The system configured to complete the instantiation implementation of the determined one or more NFs may further be configured to: perform, by at least one O-Cloud management service, the termination of the determined one or more NFs on at least one O-Cloud node; and send, by at least one O-Cloud management service, feedback regarding the termination of the determined one or more NFs on the at least one O-Cloud node to ORMOS. The system described in any of Items [1] to [4]. Item [6] The system configured to perform the termination of one or more determined NFs may further be configured to: send, via an NFO, a request to a DMS to terminate one or more determined NFs on at least one O-Cloud; when the determined one or more NFs are terminated, send, via the DMS, a termination confirmation notification; send, via the NFO, a termination confirmation notification to FOCOM; based on the NFO termination confirmation notification, send, via FOCOM, an implementation request (implementation request) to an IMS to unload at least one O-Cloud node hosting the terminated one or more NFs; and, upon receiving the implementation request for unloading, command a drain and / or cordon of the at least one O-Cloud node, according to the system described in Item [5]. Item [7] The system configured to send feedback to ORMOS regarding the determined termination of one or more NFs may further be configured to, upon unloading at least one O-Cloud node, send an unload confirmation notification to FOCOM by IMS, and, based on the unload confirmation, send instantiation policy feedback to the rApp by FOCOM, the system described in Item [5] or [6]. Item [8] The method includes determining, by an rApp in a Service Management Orchestration Framework (SMO), one or more network functions (NFs) hosted on at least one O-Cloud node to be instantiated on one or more other O-Cloud nodes, and creating, by the rApp, an instantiation policy for the determined one or more NFs for an O-Cloud Resource Management and Orchestration Service (ORMOS). ORMOS may include a Network Function Orchestrator (NFO) and a Federated O-Cloud Orchestration and Management (FOCOM). The method includes sending, by the rApp, the instantiation policy to ORMOS via an R1 interface; requesting, by ORMOS, instantiation of the determined one or more NFs via an O2 interface from at least one O-Cloud management service based on the instantiation policy; and, upon receiving the implementation request (execution request), instantiating, by the at least one O-Cloud management service, the one or more NFs on one or more other O-Cloud nodes according to the implementation request. The at least one O-Cloud management service may include a Deployment Management Service (DMS) and an Infrastructure Management Service (IMS). The method includes sending, by the at least one O-Cloud management service, a registration and configuration request for the instantiated one or more NFs to an NF-associated Radio Access Network (RAN) Operations, Administration, and Maintenance (OAM) service; sending, by the NF-associated RAN OAM service, a configuration notification of the instantiated one or more NFs to ORMOS based on the registration and configuration request; and sending, by ORMOS, an instruction to the at least one O-Cloud management service to complete the instantiation implementation of the determined one or more NFs. Item [9] The method for determining one or more NFs hosted on at least one O-Cloud node to be instantiated on one or more other O-Cloud nodes may further include: receiving, by an rApp, metrics describing a level of service of an updated Service Level Agreement (SLA); analyzing, by the rApp, the metrics describing the level of service of the updated Service Level Agreement (SLA); collecting, by the App, O1-related performance data for predicting expected RAN resources from an NF-related RAN OAM service and O2-related telemetry data of an O-Cloud node inventory from at least one O-Cloud management service; evaluating, by the rApp, required RAN resources to be reconfigured for instantiation of one or more NFs on the O-Cloud node inventory based on the collected data; and determining, by the rApp, one or more NFs to be instantiated on one or more other O-Cloud nodes based on the evaluation. The method described in Item [8]. Item

[10] The method for instantiating one or more NFs on at least one O-Cloud in accordance with an implementation request (implementation request) may further include, based on the received instantiation policy, sending an instruction by the NFO to the DMS to deploy one or more NFs determined in accordance with the received instantiation policy on one or more other O-Cloud nodes, and upon receiving the deployment instruction, creating one or more NFs on the other one or more O-Cloud nodes by the DMS, as described in Item [8] or Item [9]. Item

[11] The method for creating one or more NFs on one or more other O-Cloud nodes for each of the one or more created NFs may further include sending an NF registration and configuration request to an NF-associated RAN OAM service by each of the one or more created NFs, and upon receiving the NF registration and configuration request, registering and configuring each of the one or more created NFs by the NF-associated RAN OAM service, and sending a configuration confirmation notification for each of the one or more created NFs to the NFO by the NF-associated RAN OAM service. Item

[12] The method for completing the instantiation implementation of the determined one or more NFs, as described in any of items [8] to

[11] , may further include: by at least one O-Cloud management service, performing termination of the determined one or more NFs on at least one O-Cloud node; and by at least one O-Cloud management service, sending feedback regarding the termination of the determined one or more NFs on the at least one O-Cloud node to ORMOS. Item

[13] The method for performing the termination of one or more determined NFs on at least one O-Cloud may further include: sending, by an NFO, a request to a DMS to terminate one or more determined NFs on at least one O-Cloud; when the determined one or more NFs are terminated, sending, by the DMS, a termination confirmation notification; sending, by the NFO, a termination confirmation notification to a FOCOM; based on the NFO's termination confirmation notification, sending, by the FOCOM, an implementation request (implementation request) to an IMS to unload at least one O-Cloud node hosting the terminated one or more NFs; and, upon receiving the implementation request for unloading, ordering, by the IMS, draining and / or cordoning of at least one O-Cloud node. Item

[14] The method for sending feedback to ORMOS regarding the determined termination of one or more NFs may further include, when at least one O-Cloud node is unloaded (if unloaded), sending an unload confirmation notification to FOCOM by IMS, and, based on the unload confirmation, sending instantiation policy feedback to the rApp by FOCOM, as described in item

[12] or item

[13] . Item

[15] A non-transitory computer-readable recording medium having stored thereon instructions executable by at least one processor configured to execute a method, the method including: determining, by an rApp within a Service Management Orchestration Framework (SMO), one or more Network Functions (NFs) hosted on at least one O-Cloud node to be instantiated on one or more other O-Cloud nodes; and creating, by the rApp, an instantiation policy for the determined one or more NFs for an O-Cloud Resource Management and Orchestration Service (ORMOS), where the ORMOS may include a Network Function Orchestrator (NFO) and a Federated O-Cloud Orchestration and Management (FOCOM). The method also includes the rApp sending an instantiation policy to ORMOS via the R1 interface; and, based on the instantiation policy, ORMOS requesting instantiation implementation of the one or more NFs determined via the O2 interface from at least one O-Cloud management service; and, upon receiving the implementation request (implementation request), instantiating, by the at least one O-Cloud management service, the one or more NFs on one or more other O-Cloud nodes according to the implementation request, wherein the at least one O-Cloud management service may include a deployment management service (DMS) and an infrastructure management service (IMS). The method also includes sending, by at least one O-Cloud management service, a registration and configuration request for the instantiated one or more NFs to an NF-associated Radio Access Network (RAN) Operations, Administration, and Maintenance (OAM) service; sending, by the NF-associated RAN OAM service, a configuration notification of the instantiated one or more NFs to ORMOS based on the registration and configuration request; and sending, by ORMOS, instructions to the at least one O-Cloud management service to complete instantiation implementation of the determined one or more NFs. Item

[16] The non-transitory computer-readable storage medium of item

[15] , wherein the method for determining one or more NFs hosted on at least one O-Cloud node to be instantiated on one or more other O-Cloud nodes may further include: receiving, by an rApp, metrics describing a level of service of an updated Service Level Agreement (SLA); analyzing, by the rApp, the metrics describing the level of service of the updated Service Level Agreement (SLA); collecting, by the App, O1-related performance data for predicting expected RAN resources from an NF-related RAN OAM service and O2-related telemetry data of an O-Cloud node inventory from at least one O-Cloud management service; evaluating, by the rApp, required RAN resources to be reconfigured for instantiation of one or more NFs on the O-Cloud node inventory based on the collected data; and determining, by the rApp, one or more NFs to be instantiated on one or more other O-Cloud nodes based on the evaluation. Item

[17] A method for instantiating one or more NFs on at least one O-Cloud in accordance with an implementation request (implementation request), the non-transitory computer-readable recording medium described in Item

[15] or Item

[16] , may further include: based on the received instantiation policy, by the NFO, sending an instruction to the DMS to deploy one or more NFs determined in accordance with the received instantiation policy on one or more other O-Cloud nodes; and upon receiving the deployment instruction, by the DMS, creating one or more NFs on the other one or more O-Cloud nodes. Item

[18] The method for instantiating one or more NFs on at least one O-Cloud in accordance with an implementation request (implementation request) may further include, based on the received instantiation policy, sending an instruction by the NFO to the DMS to deploy one or more NFs determined in accordance with the received instantiation policy on one or more other O-Cloud nodes, and, upon receiving the deployment instruction, creating one or more NFs on the other one or more O-Cloud nodes by the DMS. Item

[19] A non-transitory computer-readable recording medium described in any of items

[15] to

[18] , wherein the method for completing the instantiation implementation of the determined one or more NFs may further include: by at least one O-Cloud management service, performing termination of the determined one or more NFs on at least one O-Cloud node; and by at least one O-Cloud management service, sending feedback regarding the termination of the determined one or more NFs on the at least one O-Cloud node to ORMOS. Item

[20] The method for performing the termination of one or more determined NFs on at least one O-Cloud may further include: sending, by an NFO, a request to a DMS to terminate the determined one or more NFs on at least one O-Cloud; sending, by the DMS, a termination confirmation notification upon termination of the determined one or more NFs; sending, by the NFO, a termination confirmation notification to a FOCOM; sending, by the FOCOM, an implementation request (implementation request) to an IMS to unload at least one O-Cloud node hosting the terminated one or more NFs based on the NFO's termination confirmation notification; and, upon receiving the implementation request for unloading, ordering, by the IMS, draining and / or cordoning of the at least one O-Cloud node.

Claims

1. 1. A system including: a rApp; at least one O-Cloud management service; an NF-related RAN OAM service; and an O-Cloud resource management and orchestration service (ORMOS), The system is configured to determine, by an rApp within a Service Management Orchestration Framework (SMO), one or more Network Functions (NFs) hosted on at least one O-Cloud node to be instantiated on one or more other O-Cloud nodes; The system is configured to create, by the rApp, an instantiation policy for the determined one or more NFs for an O-Cloud Resource Management and Orchestration Service (ORMOS), the ORMOS including at least one of a Network Function Orchestrator (NFO) or a Federated O-Cloud Orchestration and Management (FOCOM); The system is configured to send the instantiation policy to the ORMOS via an R1 interface by the rApp; The system is configured to request, via the ORMOS, an instantiation implementation of the determined one or more NFs from at least one O-Cloud management service via an O2 interface based on the instantiation policy; The system is configured, upon receiving the implementation request, to instantiate, by the at least one O-Cloud management service, one or more NFs on the one or more other O-Cloud nodes according to the implementation request, wherein the at least one O-Cloud management service includes at least one of a Deployment Management Service (DMS) or an Infrastructure Management Service (IMS); The system is configured to send, by the at least one O-Cloud management service, registration and configuration requests for the instantiated one or more NFs to an NF-associated Radio Access Network (RAN) Operation, Administration, and Maintenance (OAM) service; The system is configured to send a configuration notification of the instantiated one or more NFs to the ORMOS by the NF-related RAN OAM service based on the registration and configuration request; The system is configured to send, by the ORMOS, an instruction to the at least one O-Cloud management service to complete the instantiation implementation of the determined one or more NFs. system.

2. The system configured to determine the one or more NFs hosted on at least one O-Cloud node to be instantiated on one or more other O-Cloud nodes, receiving, by the rApp, metrics describing a level of service of an updated Service Level Agreement (SLA); analyzing, by the rApp, the metrics describing a level of service of an updated service level agreement (SLA); collecting, by the App, O1-related performance data for predicting expected RAN resources from the NF-related RAN OAM service and O2-related telemetry data of O-Cloud node inventory from the at least one O-Cloud management service; assessing, by the rApp based on the collected data, the required RAN resources to be reconfigured for instantiation of one or more NFs on the O-Cloud node inventory; determining, based on the evaluation, the one or more NFs to be instantiated by the rApp on one or more other O-Cloud nodes; The system of claim 1 , further configured to:

3. The system is configured to instantiate one or more NFs on at least one O-Cloud according to the implementation requirements, Based on the received instantiation policy, sending, by the NF, an instruction to the DMS to deploy the determined one or more NFs on the one or more other O-Cloud nodes according to the received instantiation policy; Upon receiving the deployment command, creating, by the DMS, one or more NFs on the other one or more O-Cloud nodes; The system of claim 1 , further configured to:

4. The system is configured to create, for each of the one or more created NFs, one or more NFs on the one or more other O-Cloud nodes, sending, by each of the one or more created NFs, a NF registration and configuration request to the NF-associated RAN OAM service; registering and configuring each of the created one or more NFs by the NF-related RAN OAM service upon receiving the NF registration and configuration request; sending, by the NF-related RAN OAM service, a configuration confirmation notification for each of the one or more created NFs to the NFO; The system of claim 3 , further configured to:

5. A system configured to complete the instantiation implementation of the determined one or more NFs, performing, by the at least one O-Cloud management service, a termination of the determined one or more NFs on the at least one O-Cloud node; sending, by the at least one O-Cloud management service, a feedback to the ORMOS regarding the termination of the determined one or more NFs on the at least one O-Cloud node; The system of claim 1 , further configured to:

6. The system configured to implement the termination of the determined one or more NFs, Sending a request to the DMS to terminate the determined one or more NFs on the at least one O-Cloud by the NFO; sending, by the DMS, a termination confirmation notification in response to the termination of the determined one or more NFs; sending a termination confirmation notice to the FOCOM via the NFO; sending, by the FOCOM to the IMS, an implementation request to unload the at least one O-Cloud node hosting the terminated one or more NFs based on the termination confirmation notification of the NFO; upon receiving the implementation request to unload, ordering, by the IMS, a drain and / or cordon of the at least one O-Cloud node; The system of claim 5 , further configured to:

7. The system for sending feedback to the ORMOS regarding the termination of the determined one or more NFs comprises: Upon unloading the at least one O-Cloud node, sending an unload confirmation notification to the FOCOM by the IMS; sending instantiation policy feedback to the rApp by the FOCOM based on the unload confirmation; The system of claim 6 , further configured to:

8. 1. A method comprising: Determining, by an rApp in a Service Management Orchestration Framework (SMO), one or more Network Functions (NFs) hosted on at least one O-Cloud node to be instantiated on one or more other O-Cloud nodes; creating, by the rApp, an instantiation policy for the determined one or more NFs for an O-Cloud Resource Management and Orchestration Service (ORMOS), wherein the ORMOS includes at least one of a Network Function Orchestrator (NFO) or a Federated O-Cloud Orchestration and Management (FOCOM); The method includes sending, by the rApp, the instantiation policy to the ORMOS via an R1 interface; Requesting instantiation implementation of the determined one or more NFs from at least one O-Cloud management service via an O2 interface by the ORMOS based on the instantiation policy; upon receiving the implementation request, instantiating, by the at least one O-Cloud management service, one or more NFs on the one or more other O-Cloud nodes according to the implementation request, wherein the at least one O-Cloud management service comprises at least one of a Deployment Management Service (DMS) or an Infrastructure Management Service (IMS); The method includes sending, by the at least one O-Cloud management service, a registration and configuration request for the instantiated one or more NFs to an NF-associated Radio Access Network (RAN) Operation, Administration, and Maintenance (OAM) service; sending, by the NF-related RAN OAM service, a configuration notification of the instantiated one or more NFs to the ORMOS based on the registration and configuration request; sending, by the ORMOS, an instruction to the at least one O-Cloud management service to complete the instantiation implementation of the determined one or more NFs; A method comprising:

9. A method for determining the one or more NFs hosted on at least one O-Cloud node to be instantiated on one or more other O-Cloud nodes, comprising: receiving, by the rApp, metrics describing a level of service of an updated Service Level Agreement (SLA); analyzing, by the rApp, the metrics describing a level of service of an updated service level agreement (SLA); collecting, by the App, O1-related performance data for predicting expected RAN resources from the NF-related RAN OAM service and O2-related telemetry data of O-Cloud node inventory from the at least one O-Cloud management service; assessing, by the rApp based on the collected data, the required RAN resources to be reconfigured for instantiation of one or more NFs on the O-Cloud node inventory; determining, based on the evaluation, the one or more NFs to be instantiated by the rApp on one or more other O-Cloud nodes; The method of claim 8 further comprising:

10. The method for instantiating one or more NFs on at least one O-Cloud according to the implementation requirements, comprising: Based on the received instantiation policy, sending, by the NF, an instruction to the DMS to deploy the determined one or more NFs on the one or more other O-Cloud nodes according to the received instantiation policy; Upon receiving the deployment command, creating, by the DMS, one or more NFs on the other one or more O-Cloud nodes; The method of claim 8 further comprising:

11. The method for instantiating one or more NFs on at least one O-Cloud according to the implementation requirements, comprising: Based on the received instantiation policy, sending, by the NF, an instruction to the DMS to deploy the determined one or more NFs on the one or more other O-Cloud nodes according to the received instantiation policy; Upon receiving the deployment command, creating, by the DMS, one or more NFs on the other one or more O-Cloud nodes; The method of claim 10 further comprising:

12. The method for completing the instantiation implementation of the determined one or more NFs includes: performing, by the at least one O-Cloud management service, a termination of the determined one or more NFs on the at least one O-Cloud node; sending, by the at least one O-Cloud management service, a feedback to the ORMOS regarding the termination of the determined one or more NFs on the at least one O-Cloud node; The method of claim 8 further comprising:

13. The method for implementing the termination of the determined one or more NFs comprises: Sending a request to the DMS to terminate the determined one or more NFs on the at least one O-Cloud by the NFO; sending, by the DMS, a termination confirmation notification in response to the termination of the determined one or more NFs; sending a termination confirmation notice to the FOCOM via the NFO; sending, by the FOCOM to the IMS, an implementation request to unload the at least one O-Cloud node hosting the terminated one or more NFs based on the termination confirmation notification of the NFO; upon receiving the implementation request to unload, ordering, by the IMS, a drain and / or cordon of the at least one O-Cloud node; The method of claim 12 further comprising:

14. The method for sending feedback regarding the termination of the determined one or more NFs to the ORMOS comprises: Upon unloading the at least one O-Cloud node, sending an unload confirmation notification to the FOCOM by the IMS; sending instantiation policy feedback to the rApp by the FOCOM based on the unload confirmation; 14. The method of claim 13, further comprising:

15. 1. A non-transitory computer-readable medium having stored thereon instructions executable by at least one processor configured to perform a method, the method comprising: Determining, by an rApp in a Service Management Orchestration Framework (SMO), one or more Network Functions (NFs) hosted on at least one O-Cloud node to be instantiated on one or more other O-Cloud nodes; creating, by the rApp, an instantiation policy for the determined one or more NFs for an O-Cloud Resource Management and Orchestration Service (ORMOS), wherein the ORMOS includes at least one of a Network Function Orchestrator (NFO) or a Federated O-Cloud Orchestration and Management (FOCOM); The method further comprises: sending, by the rApp, the instantiation policy to the ORMOS via an R1 interface; Requesting instantiation implementation of the determined one or more NFs from at least one O-Cloud management service via an O2 interface by the ORMOS based on the instantiation policy; upon receiving the implementation request, instantiating, by the at least one O-Cloud management service, one or more NFs on the one or more other O-Cloud nodes according to the implementation request, wherein the at least one O-Cloud management service comprises at least one of a Deployment Management Service (DMS) or an Infrastructure Management Service (IMS); The method further comprises: sending, by the at least one O-Cloud management service, a registration and configuration request for the instantiated one or more NFs to an NF-associated Radio Access Network (RAN) Operation, Administration, and Maintenance (OAM) service; sending, by the NF-related RAN OAM service, a configuration notification of the instantiated one or more NFs to the ORMOS based on the registration and configuration request; sending, by the ORMOS, an instruction to the at least one O-Cloud management service to complete the instantiation implementation of the determined one or more NFs; A non-transitory computer-readable recording medium comprising:

16. The method for determining the one or more NFs hosted on at least one O-Cloud node to be instantiated on one or more other O-Cloud nodes comprises: receiving, by the rApp, metrics describing a level of service of an updated Service Level Agreement (SLA); analyzing, by the rApp, the metrics describing a level of service of an updated service level agreement (SLA); collecting, by the App, O1-related performance data for predicting expected RAN resources from the NF-related RAN OAM service and O2-related telemetry data of O-Cloud node inventory from the at least one O-Cloud management service; assessing, by the rApp based on the collected data, the required RAN resources to be reconfigured for the instantiation of one or more NFs on the O-Cloud node inventory; determining, based on the evaluation, the one or more NFs to be instantiated by the rApp on one or more other O-Cloud nodes; 16. The non-transitory computer-readable storage medium of claim 15, further comprising:

17. The method for instantiating one or more NFs on at least one O-Cloud according to the implementation requirements, comprising: Based on the received instantiation policy, sending, by the NF, an instruction to the DMS to deploy the determined one or more NFs on the one or more other O-Cloud nodes according to the received instantiation policy; Upon receiving the deployment command, creating, by the DMS, one or more NFs on the other one or more O-Cloud nodes; 16. The non-transitory computer-readable storage medium of claim 15, further comprising:

18. The method for instantiating one or more NFs on at least one O-Cloud according to the implementation requirements, comprising: Based on the received instantiation policy, sending, by the NF, an instruction to the DMS to deploy the determined one or more NFs on the one or more other O-Cloud nodes according to the received instantiation policy; Upon receiving the deployment command, creating, by the DMS, one or more NFs on the other one or more O-Cloud nodes; 20. The non-transitory computer-readable storage medium of claim 17, further comprising:

19. The method for completing the instantiation implementation of the determined one or more NFs includes: performing, by the at least one O-Cloud management service, a termination of the determined one or more NFs on the at least one O-Cloud node; sending, by the at least one O-Cloud management service, a feedback to the ORMOS regarding the termination of the determined one or more NFs on the at least one O-Cloud node; 16. The non-transitory computer-readable storage medium of claim 15, further comprising:

20. The method for implementing the termination of the determined one or more NFs comprises: Sending a request to the DMS to terminate the determined one or more NFs on the at least one O-Cloud by the NFO; sending, by the DMS, a termination confirmation notification in response to the termination of the determined one or more NFs; sending a termination confirmation notice to the FOCOM via the NFO; sending, by the FOCOM to the IMS, an implementation request to unload the at least one O-Cloud node hosting the terminated one or more NFs based on the termination confirmation notification of the NFO; upon receiving the implementation request to unload, ordering, by the IMS, a drain and / or cordon of the at least one O-Cloud node; 20. The non-transitory computer-readable storage medium of claim 19, further comprising:

Images