Network-Aware Computational Resource Management Use Case for O-RAN Non-RT RIC

Abstract

A system and method are provided for optimizing Open Radio Access Network (O-RAN) Cloud (O-Cloud) resources using an rApp of a Non-RT RIC. The method includes: acquiring O1 data received by an rApp hosted in the Non-RT RIC via an O1 interface of an SMO framework for managing and orchestrating an O-Cloud platform, the O1 interface being for communicating with Virtualized Network Functions (VNFs) hosted in multiple physical nodes of the O-Cloud platform; acquiring O2 data received by the rApp via an O2 interface of the SMO framework, the O2 interface being for communicating with an Infrastructure Management Service (IMS) and a Deployment Management Service (DMS) of the O-Cloud platform; and generating, by the rApp, a policy for optimizing the O-Cloud platform or the VNF via an SMO fixed function or the O1 interface of the SMO framework based on at least one of the acquired O1 data and the acquired O2 data.

Description

[Background technology]

[0001] The radio access network (RAN) is a critical component in telecommunications systems, as 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-users to the core network. Traditionally, the hardware and / or software of a particular RAN is vendor-specific.

[0002] Open RAN (O-RAN) technology has emerged to allow multiple vendors to provide hardware and / or software for telecommunication systems. Since different vendors are involved, the types of hardware and / or software provided may also differ. That is, different types of NEs may be provided by different vendors, and depending on the specific service, the NEs may be virtualized in software form (e.g., virtual machine (VM)-based) or in physical hardware form (e.g., non-VM-based).

[0003] The RAN functions in the O-RAN architecture are controlled and optimized by the RAN Intelligent Controller (RIC), a software-defined component that implements modular applications to facilitate the multi-vendor operability required in an O-RAN system, as well as to automate and optimize RAN operations.

[0004] RICs are divided into two types: Non-RT RICs and Near-RT RICs. Non-RT RICs operate on timescales greater than one second within a Service Management and Orchestration (SMO) framework. Their functionality is implemented via modular applications called rApps and includes providing policy-based guidance and reinforcement over the A1 interface, an interface that enables communication between Non-RT RICs and Near-RT RICs, performing data analytics, Artificial Intelligence / Machine Learning (AI / ML) training and inference for RAN optimization, and / or recommending configuration management actions over the O1 interface, an interface that connects SMOs to RAN managed elements (e.g., Near-RT RICs, O-RAN Centralized Units (O-CUs), O-RAN Distributed Units (O-DUs), etc.).

[0005] The Near-RT RIC operates on a timescale between 10 ms and 1 second and is coupled with the O-CU Control Plane (O-CU-CP) and O-CU User Plane (O-CU-UP) through the E2 interface. The Near-RT RIC hosts xApps to implement functions such as interference mitigation, load balancing, and security. The two types of RICs work together to optimize O-RAN. For example, the Non-RT RIC provides policies, data, and AI / ML models that are enforced and used by the Near-RT RIC for RAN optimization.

[0006] As mentioned above, the Non-RT RIC is placed within the SMO framework that manages and orchestrates the RAN elements. Specifically, the SMO manages and orchestrates what is called the O-Ran Cloud (O-Cloud). 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.

[0007] In more detail, O-RAN E2 nodes (i.e., O-CU, O-DU, etc. connected to Near-RT RIC via E2 interface) are orchestrated on O-Cloud as virtualized network functions (VNFs). SMO anchored functions (e.g., Network Function Orchestrator (NFO), Federated O-Cloud Orchestration and Management (FOCOM)) handle the management and orchestration of VNFs and O-Cloud. However, in the prior art, SMO anchored functions are limited to utilizing intelligence by correlation of observability from E2 nodes, infrastructure, and network functions (NFs) to affect management / orchestration. O-Cloud resources cannot be optimized based on intent (e.g., policy objectives of NFO / FOCOM) or by configuration changes over the O2 interface (i.e., interface between SMO and O-Cloud) from Non-RT RIC rApps. That is, in the prior art, rApps in Non-RT RICs have no scope to optimize or influence the orchestration and management of O-Cloud or the operation and maintenance of O-RAN elements, nor are use cases defined that utilize intelligence via rApps with the help of AI / ML to optimize or influence the orchestration and management of O-Cloud or the operation and maintenance of O-RAN elements. Summary of the Invention [Means for solving the problem]

[0008] According to an example embodiment, a system and method are provided for optimizing O-Cloud resources utilizing one or more rApps in a Non-RT RIC.

[0009] According to an example embodiment, a system and method are provided that enables a Non-RT RIC to provide intelligence to O-Cloud operations and capabilities by optimizing O-Cloud resources.

[0010] According to an exemplary embodiment, a system for optimizing O-Cloud resources includes: an O-RAN cloud platform (O-Cloud) including a plurality of physical nodes configured to host Virtualized Network Functions (VNFs), the VNFs including an O-RAN Centralized Unit (O-CU) and an O-RAN Distributed Unit (O-DU); a Service Management and Orchestration (SMO) framework configured to manage and orchestrate the O-Cloud, the SMO including fixed functions, a Non-Real-Time Radio Access Network (RAN) Intelligent Controller (Non-RT RIC), an O1 interface for communicating with the VNFs, and an O2 interface for communicating with Infrastructure Management Services (IMS) and Deployment Management Services (DMS) of the O-Cloud; and a Near-Real-Time RAN Intelligent Controller (Near-RT RIC) configured to perform RAN optimization using policies and data provided by the Non-RT RIC, the Non-RT RIC being configured to perform RAN optimization using policies and data provided by the Non-RT RIC. The RIC is configured to collect node-level or O-Cloud-level O-Cloud inventory and telemetry data via an O2 interface, collect cell-wise traffic data including mobility and neighbor cell load data via an O1 interface, train and deploy artificial intelligence / machine learning (AI / ML) models to generate policies based on the collected O1 and O2 data, and implement one or more applications (rApps) to generate policies for the O-Cloud or VNFs based on at least one of priority, load, and energy consumption, and the fixed functionality of the SMO framework is a Non-RTand configured to receive and manage policies for the O-Cloud from the RIC, generate optimization controls for transmission to the O-Cloud via the O2 interface, and / or transmit policies to the IMS and DMS via the O2 interface for implementation.

[0011] Fixed functions of the SMO framework may include a Network Function Orchestrator (NFO) and Federated O-Cloud Orchestration and Management (FOCOM).

[0012] According to an exemplary embodiment, a system for implementing a service management and orchestration (SMO) framework for managing and orchestrating an open radio access network (O-RAN) cloud (O-Cloud) platform includes at least one memory that stores first instructions and second instructions; and a non-real-time radio access network (RAN) intelligent controller (Non-RT) that hosts a plurality of applications (rApps). and at least one second processor configured to execute a second instruction to implement an SMO pinned function, wherein the at least one first processor is configured to execute the first instruction to: acquire O1 data received via an O1 interface of an SMO framework, the O1 interface being for communicating with Virtualized Network Functions (VNFs) hosted in a plurality of physical nodes of an O-Cloud platform; acquire O2 data received via an O2 interface of the SMO framework, the O2 interface being for communicating with an Infrastructure Management Service (IMS) and a Deployment Management Service (DMS) of the O-Cloud platform; acquire the O2 data; and generate a policy for optimizing the O-Cloud platform or the VNFs via the SMO pinned function or the O1 interface of the SMO framework based on at least one of the acquired O1 data and the acquired O2 data by an rApp from among a plurality of applications; and the at least one second processor is configured to execute the first instruction to: and configured to execute second instructions to receive and manage policies from the RIC and generate optimization controls for transmission to an O-Cloud platform via an O2 interface or transmit the policies to an IMS and a DMS via an O2 interface for implementation.

[0013] The at least one first processor may be configured to execute first instructions to train and deploy at least one artificial intelligence / machine learning (AI / ML) model to generate a policy based on at least one of the acquired O1 data and the acquired O2 data.

[0014] The at least one first processor may be configured to execute first instructions to obtain feedback from the O-Cloud platform or the VNF and evaluate the policy.

[0015] O2 data may include O-Cloud inventory and telemetry data at the node level or at the O-Cloud level.

[0016] O1 data can include fault, configuration, accounting, performance, and security (FCAPS) data.

[0017] SMO fixed functions may include a Network Function Orchestrator (NFO) and Federated O-Cloud Orchestration and Management (FOCOM).

[0018] At least one of the acquired O1 data and the acquired O2 data may include data regarding at least one of central processing unit (CPU) utilization, bare metal power consumption, CPU load, memory load, and CPU frequency for a network function (NF), and the policy may be a policy for energy conservation for at least one of the NF, O-Cloud infrastructure, and O-Cloud hardware.

[0019] At least one of the acquired O1 data and the acquired O2 data may include data regarding at least one of user mobility performance, traffic distribution between cells, neighboring cell measurements, NF configuration, NF inventory, and NF telemetry, and the policy may be a policy for RAN network or infrastructure load balancing.

[0020] At least one of the acquired O1 data and the acquired O2 data may include data regarding at least one of network slice utilization, network slice throughput, network slice availability, and network slice life cycle management (LCM), and the policy may be a policy for dynamic allocation and optimization of O-Cloud resources for network slicing.

[0021] At least one of the acquired O1 data and the acquired O2 data may include RAN sharing related FCAPS data, and the policy may be a policy for O-Cloud resource management and service legal agreement (SLA) guarantees for RAN sharing.

[0022] At least one of the acquired O1 data and the acquired O2 data may include at least one of O-Cloud failure data, O-Cloud performance data, NF failure data, and NF performance data, and the policy may be a policy for recovery or root cause analysis of performance degradation or failure of the O-Cloud or O-Cloud infrastructure network elements.

[0023] According to an exemplary embodiment, a method for optimizing O-Cloud resources using policy-based guidance from a Non-RT RIC includes: The method includes obtaining, by an application (rApp) hosted in the RIC, O1 data received via an O1 interface of an SMO framework for managing and orchestrating an Open Radio Access Network (O-RAN) Cloud (O-Cloud) platform, where the O1 interface is for communicating with Virtualized Network Functions (VNFs) hosted in multiple physical nodes of the O-Cloud platform; obtaining, by the rApp, O2 data received via an O2 interface of the SMO framework, where the O2 interface is for communicating with an Infrastructure Management Service (IMS) and a Deployment Management Service (DMS) of the O-Cloud platform; generating, by the rApp, a policy for optimizing the O-Cloud platform or the VNF via an SMO fixed function or an O1 interface of the SMO framework based on at least one of the obtained O1 data and the obtained O2 data; and providing the policy to the SMO fixed function for implementation or performing a configuration change to optimize O-Cloud resources via the O2 interface.

[0024] The method may further include training and deploying at least one artificial intelligence / machine learning (AI / ML) model to generate a policy based on at least one of the acquired O1 data and the acquired O2 data.

[0025] The method may further include obtaining, by the rApp, feedback from the O-Cloud platform or the VNF and evaluating the policy.

[0026] O2 data may include O-Cloud inventory and telemetry data at the node level or at the O-Cloud level.

[0027] O1 data may include fault, configuration, billing, performance, and security (FCAPS) data.

[0028] According to an exemplary embodiment, at least one non-transitory computer-readable storage medium has stored thereon instructions executable by at least one processor to perform a method for optimizing O-Cloud resources using policy-based guidance from a Non-RT RIC, the method comprising: The method includes obtaining, by an application (rApp) hosted in the RIC, O1 data received via an O1 interface of an SMO framework for managing and orchestrating an Open Radio Access Network (O-RAN) Cloud (O-Cloud) platform, where the O1 interface is for communicating with Virtualized Network Functions (VNFs) hosted in multiple physical nodes of the O-Cloud platform; obtaining, by the rApp, O2 data received via an O2 interface of the SMO framework, where the O2 interface is for communicating with an Infrastructure Management Service (IMS) and a Deployment Management Service (DMS) of the O-Cloud platform; generating, by the rApp, a policy for optimizing the O-Cloud platform or the VNF via an SMO fixed function or an O1 interface of the SMO framework based on at least one of the obtained O1 data and the obtained O2 data; and providing the policy to the SMO fixed function for implementation or performing a configuration change to optimize O-Cloud resources via the O2 interface.

[0029] The method may further include training and deploying at least one artificial intelligence / machine learning (AI / ML) model to generate a policy based on at least one of the acquired O1 data and the acquired O2 data.

[0030] The method may further include obtaining, by the rApp, feedback from the O-Cloud platform or the VNF and evaluating the policy.

[0031] O2 data may include O-Cloud inventory and telemetry data at the node level or at the O-Cloud level.

[0032] O1 data may include fault, configuration, billing, performance, and security (FCAPS) data. [Brief description of the drawings]

[0033] The features, advantages, and significance of exemplary embodiments of the present disclosure will be explained with reference to the accompanying drawings.

[0034] [Figure 1] FIG. 1 is a diagram of an O-RAN system architecture according to an example embodiment. [Figure 1c] FIG. 1 is a diagram of an O-RAN system architecture according to an example embodiment. [Diagram 2] 1 is a flowchart of a method for providing energy saving policy-based guidance for O-Cloud components from a Non-RT RIC via an SMO pinning function, according to an example embodiment. [Diagram 3] 1 is a flowchart of a method for providing RAN network and infrastructure load balancing policy based guidance for RAN network and O-Cloud infrastructure components from a Non-RT RIC via an SMO pinning function according to an example embodiment. [Figure 4]1 is a flowchart of a method for providing policy-based guidance from a Non-RT RIC via an NFO and / or NSSMF for optimizing and / or rebalancing O-Cloud infrastructure resources to achieve a desired service level agreement (SLA) for a network slice, according to an example embodiment. [Diagram 5] 1 is a flowchart of a method for providing policy-based guidance from a Non-RT RIC via an SMO pinning function for optimizing O-Cloud and RAN resources to achieve desired SLAs for RAN sharing, according to an example embodiment. [Figure 6] 1 is a flowchart of a method for providing network element recovery policy-based guidance from a Non-RT RIC via a SMO pinning function, according to an example embodiment. [Figure 7] 1 is a flowchart of a method for providing root cause analysis policy-based guidance from a Non-RT RIC via an SMO pinning function for determining the root cause of a fault event and / or performance degradation of a network element, according to an example embodiment. [Figure 8] FIG. 1 illustrates an example environment in which the systems and / or methods described herein may be implemented. [Figure 9] FIG. 2 is a diagram of exemplary components of a device according to one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0035] The following detailed description of the exemplary embodiments refers to the accompanying drawings, in which the same reference numbers in different drawings may identify the same or similar elements.

[0036] The foregoing disclosure provides illustrations and descriptions, but is not intended to be exhaustive or to limit the implementation to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations. Furthermore, one or more features or components of one embodiment may be incorporated in or combined with another embodiment (or one or more features of another embodiment). Furthermore, in the flowcharts and descriptions of operations provided below, it is understood that one or more operations may be omitted, one or more operations may be added, one or more operations may be performed (at least partially) simultaneously, and the order of one or more operations may be permuted.

[0037] It will be apparent that the systems and / or methods described herein may be implemented in various forms of hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods is not intended to limit the implementation form. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It is understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

[0038] 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 may 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.

[0039] No element, act, or instruction used herein should be construed as critical or essential unless expressly described as such. Additionally, the articles "a" and "an" as used herein are intended to include one or more items and may be used interchangeably with "one or more." When only one item is intended, the term "one" or similar language is used. Additionally, terms such as "has," "have," "having," "include," "including," and the like as used herein are intended to be open-ended terms. Additionally, the phrase "based on" is intended to mean "based at least in part on," unless specifically noted otherwise. Additionally, phrases such as "at least one of [A] and [B]" and "at least one of [A] or [B]" should be understood to include only A, only B, or both A and B.

[0040] Exemplary embodiments of the present disclosure provide systems and methods that utilize one or more rApps of a Non-RT RIC to optimize O-Cloud resources via a fixed function of an SMO and / or an O2 interface. Exemplary embodiments of the present disclosure provide systems and methods that enable a Non-RT RIC to provide intelligence to O-Cloud operations and functions by optimizing O-Cloud resources.

[0041] 1 and 1c (continuation) are diagrams of an O-RAN system architecture according to an example embodiment. Referring to FIG. 1 and 1c (continuation), the O-RAN system architecture includes an SMO framework, a Near-RT RIC, and an O-Cloud. The SMO framework includes a fixed function (SMO / NFO / OAM) and a Non-RT RIC.

[0042] According to an exemplary embodiment, the Non-RT RIC hosts third-party applications as rApps in the SMO that can read various observability data via O1 and O2 related services. These third-party rApps can be utilized to provide policy-based guidance via NFO / FOCOM for optimization of O-Cloud resources or Configuration Management (CM) changes directly via the O2 interface.

[0043] In particular, a Non-RT RIC framework according to one or more exemplary embodiments can collect node-level or O-Cloud-level O-Cloud inventory and telemetry data via the O2 interface, collect cell-wise traffic data (including mobility and neighboring cell load data) via the O1 interface, train and deploy AI / ML models to generate policies based on the O1 and O2 data, generate policies for O-Cloud or E2 nodes based on priority, load, and energy consumption, and provide policies for optimization of O-Cloud resources when CM is changed via SMO fixed functions and / or directly via the O2 interface.

[0044] The SMO pinning function according to one or more exemplary embodiments is configured to receive and manage policies from rApps to optimize resources of the O-Cloud and generate optimization controls or policies for the O-Cloud via the O2 interface. The O-Cloud services (e.g., IMS and DMS) expose data to the SMO and Non-RT RIC via the O2 interface, and the O-Cloud implements and provides feedback to the changes and recommendations made by the Non-RT RIC and / or the SMO.

[0045] In accordance with one or more exemplary embodiments, third-party rApps may affect automation and / or optimization aspects of O-Cloud infrastructure lifecycle management (LCM), such as energy savings (e.g., through use of rApps / AI / ML, real-time load forecasting, correlation between network function (NF) performance and O-Cloud performance data, etc.), hardware (HW) recovery (e.g., HW reboot) and automated maintenance, security (e.g., password changes), root cause analysis, etc.

[0046] Additionally, according to one or more example embodiments, third-party rApps may affect O-Cloud deployment LCM such as NF recovery (e.g., restarting, relocating, re-instantiating, etc.), scale in / out in horizontal scaling (e.g., scaling NFs in / out based on configuration and load-related data from O-Cloud and E2 nodes to improve efficiency in terms of load balancing and energy savings), scale up / down in vertical scaling, health / status checks (e.g., auditing, adjusting real-time state, health of NFs, etc.), diagnostics, etc.

[0047] Additionally, according to one or more example embodiments, third party rApps may affect O-Cloud provisioning in terms of capacity, availability, etc., as well as O-Cloud inventory in terms of mapping resources to their usage.

[0048] Additionally, a third party rApp according to one or more example embodiments may affect management aspects of the Assist Acceleration Abstraction Layer Interface (AALI) and Acceleration Abstraction Layer (AAL)-Logical Profile Unit (LPU), where an LPU is a logical representation of resources within an instance of a HW accelerator (e.g., there can be multiple processing units or subsystems or resource divisions (hard-dedicated resources, soft-soft resources) on a hardware accelerator, which can be logically represented as an AAL logical processing unit).

[0049] According to an exemplary embodiment, the third party rApp may affect the above functions with the help of (or based on) data via O2 and O1, such as O2-IMS related data (e.g., O2ims_InfrastructureInventory service, O2ims_InfrastructureMonitoring service, O2ims_InfrastructureProvisioning service, O2ims_InfrastructureLifecycleManagement service, etc.), O2-DMS related data (e.g., Deployment Lifecycle Management service, Deployment Monitoring service, etc.), and O1 FCAPS (Fault, Configuration, Billing, Performance, Security) data. Using this data, correlation between deployed NF events and downward or underlying O-Cloud events can be performed to discover or analyze root causes and take smart and / or intelligence-driven actions towards NF and O-Cloud. As a result, the rApp according to the exemplary embodiment can make the O-Cloud more operator-driven.

[0050] According to an example embodiment, the rApp can provide policy-based guidance for action and / or intent management via the SMO pinning function. In this regard, the NFO is responsible for LCM actions for the NF. As an example, the rApp according to an embodiment can pass intent (i.e., policy or policy goal) to the NFO, which guides the deployment management service (DMS) for the NF to perform the action. For example, in the case of an NF recovery scenario, the rApp can assist the NFO to reboot, relocate, and / or reinstantiate the NF.

[0051] Additionally, FOCOM is responsible for LCM of O-Cloud. As an example, an rApp according to an embodiment can pass intent to FOCOM to guide the IMS to perform actions. For example, the rApp can assist in case of root cause analysis of hardware or software related O-Cloud failures based on observability correlation.

[0052] According to one or more example embodiments, an rApp can configure changes via the O2 interface. To this end, an rApp can provide low latency, fast and continuous actions towards the O-Cloud, such as changing the P-state or C-state of a vCPU when needed or desired for energy saving purposes.

[0053] Aspects of the exemplary embodiments provide for more interoperable O-Cloud orchestration and management with the use of third party applications (rApps) and AI / ML as intelligent inputs to NFO / FOCOM or direct inputs via the O2 interface.

[0054] O-Cloud resource optimization use cases

[0055] The following describes use cases of O-Cloud resource optimization according to various exemplary embodiments.

[0056] 1.0 Use Case 1: Energy Saving in O-Cloud

[0057] The O-Cloud energy saving use case according to the example embodiments enables operators to define different objectives for energy saving of various components of O-RAN elements such as NFs deployed on the O-Cloud, O-Cloud infrastructure, and O-Cloud under-layer hardware.

[0058] 1.1 Background and goals of this use case

[0059] Energy consumption in mobile networks is a key topic for mobile operators. Energy Saving (ES) functions involve different network mechanisms, network nodes and layers that operate on different time scales. Specific ES functions are already deployed in network equipment and are vendor specific.

[0060] The ES use cases according to the example embodiments provide various options via the Non-RT RIC platform and rApp to enable energy saving capabilities for RAN NFs deployed on the O-Cloud, the O-Cloud infrastructure, and the O-Cloud underlayer hardware.

[0061] 1.2 Entities / Resources Involved in This Use Case

[0062] The entities involved in the ES use case include the SMO Fixed Function (NFO / FOCOM / OAM (Operation and Maintenance)), which supports interpretation and enforcement of policies from the Non-RT RIC, and provides the necessary control to the O-Cloud elements (IMS and DMS) based on the policies from the Non-RT RIC. Furthermore, at least one rApp and the Non-RT RIC framework obtains the necessary performance, configuration, and other data from the O-Cloud via the O2 interface and / or the O1 interface to define and update policies for energy saving to the SMO Fixed Function. The O-Cloud (IMS and DMS) according to this exemplary embodiment is configured to read the control data from the SMO Fixed Function, enforce changes to the respective nodes or hardware under it, and provide feedback to the SMO Post-Control Enforcement.

[0063] 1.3 Solution

[0064] FIG. 2 illustrates a flowchart of a method for providing energy saving policy-based guidance for O-Cloud components (e.g., NFs deployed on the O-Cloud, O-Cloud infrastructure, underlying O-Cloud hardware) from a Non-RT RIC via an SMO pinning function, according to an example embodiment.

[0065] Referring to FIG. 2, in step S201, an rApp (i.e., one or more rApps) according to an exemplary embodiment subscribes to FCAPS (Fault, Configuration, Billing, Performance, Security) data such as CPU utilization, bare metal power consumption, CPU load, memory load, CPU frequency, etc. for an NF from an E2 node and an O-Cloud service (IMS / DMS) via an O1 interface and an O2 interface, respectively.

[0066] In step S202, the rApp trains at least one AI / ML model and / or executes at least one predefined algorithm with data acquired via the O1 and O2 interfaces to generate policy intents for energy saving in different schemes for each node. Examples of policy intents include CPU frequency change, CPU load reduction, suspending ongoing processes in the O-Cloud, relocating applications to another set of servers, putting unused servers into sleep state, etc.

[0067] In step S203, the rApp passes the intent to the NFO and / or FOCOM.

[0068] In step S204, the NFO / FOCOM translates the policy intent from the Non-RT RIC and enforces the control to the O-Cloud (eg, sending control data or instructions to the IMS and / or DMS via the O2 interface).

[0069] In step S205, the O-Cloud (eg, IMS and / or DMS) enforces the changes instructed by the NFO / FOCOM to the respective nodes and provides feedback to the SMO or Non-RT RIC upon success or failure of policy implementation.

[0070] In step S206, the rApp monitors performance and / or configuration changes of the RAN functions, NFs, and O-Cloud infrastructure for closed-loop evaluation of the policy.

[0071] 2.0 Use Case 2: RAN Network and Infrastructure Load Balancing

[0072] The RAN network and infrastructure load balancing use case according to the example embodiment enables the Non-RT RIC and O2 interfaces to support O-Cloud resource load management and E2 traffic load management based on O1 and O2 performance, configuration, and fault management data.

[0073] 2.1 Background and Goals of this Use Case

[0074] Balancing the traffic allows operators to distribute the load across different cells of the network, providing a better user experience in terms of throughput, latency etc.

[0075] However, the prior art traffic steering use cases defined in O-RAN are limited to RAN traffic management and do not have any requirement or coordination with the O-Cloud to perform load management on network functions.

[0076] The RAN network and infrastructure load balancing use case according to the example embodiment provides configuration for Non-RT RIC, O2, SMO, and O-Cloud to enable an rApp (i.e., one or more rApps) to perform load balancing in both directions (i.e., on the RAN side and on the O-Cloud side), i.e., the RAN network and infrastructure load balancing use case makes load balancing complete and more efficient from the user and operator perspectives.

[0077] 2.2 Entities / Resources Involved in This Use Case

[0078] The entities involved in this use case include the SMO pinning function (NFO / FOCOM / OAM), which supports the interpretation and enforcement of policies from the Non-RT RIC, and provides the necessary control to the O-Cloud elements (IMS and DMS) based on the policies from the Non-RT RIC. Furthermore, at least one rApp and the Non-RT RIC framework obtains the necessary performance, configuration, and other data from the O-Cloud via the O2 interface and / or the O1 interface to define and update policies for load balancing to the SMO pinning function. The O-Cloud (IMS and DMS) according to this exemplary embodiment is configured to read the control data from the SMO pinning function, enforce changes to the respective nodes or hardware under it, and provide feedback to the SMO post-control enforcement.

[0079] 2.3 Solution

[0080] FIG. 3 illustrates a flowchart of a method for providing RAN network and infrastructure load balancing policy-based guidance for RAN network and O-Cloud infrastructure components from a Non-RT RIC via an SMO pinning function, according to an example embodiment.

[0081] Referring to FIG. 3, in step S301, an rApp (i.e., one or more rApps) according to an exemplary embodiment subscribes to FCAPS data, such as user mobility performance data, traffic distribution between cells, neighboring cell measurement data, NF configuration, NF inventory and telemetry, from an E2 node and an O-Cloud service (IMS / DMS) via an O1 interface and an O2 interface, respectively.

[0082] In step S302, the rApp trains at least one AI / ML model and / or executes at least one predefined algorithm with data obtained via the O1 and O2 interfaces to generate a load balancing policy or configuration change over O1 or O2. For example, a traffic steering policy may be generated when the NF load is high and there is a target cell available for mobility. If there is no available target cell, a scale-in policy may be generated for NFO to scale in the NF to accommodate the load. Traffic steering and scale-out policies may be generated to move users to another cell and perform NF scale-out (i.e., downscale or remove instances of the NF) when the NF is less loaded.

[0083] In step S303, the rApp passes the policy to at least one SMO fixed function (eg, NFO).

[0084] In step S304, at least one SMO fixed function translates policies from the Non-RT RIC and enforces controls to the O-Cloud (eg, sends control data or instructions to the IMS and / or DMS via the O2 interface).

[0085] In step S305, the O-Cloud (eg, IMS and / or DMS) enforces the changes instructed by the SMO to the respective nodes and provides feedback to the SMO or Non-RT RIC upon success or failure of policy implementation.

[0086] In step S306, the Near-RT RIC enforces the policy received from the Non-RT RIC.

[0087] In step S307, the rApp monitors the performance of the user equipment (UE), RAN functions, NFs, and O-Cloud infrastructure for policy evaluation.

[0088] 3.0 Use Case 3: Dynamic Allocation and Optimization of O-Cloud Resources for Network Slicing

[0089] The dynamic allocation and optimization of O-Cloud resources for network slicing use case according to example embodiments enables the Non-RT RIC and O2 interfaces to support optimization of O-Cloud resources for a particular network slice in coordination with RAN resources based on operator defined O1 and O2 performance, configuration, and fault management data and intent.

[0090] 3.1 Background and Goals of this Use Case

[0091] Network slicing helps network providers slice a single network into multiple virtual networks built on a single infrastructure setup. Network slicing overlays these multiple virtual networks on top of a shared network. Furthermore, through network slicing, each of the sliced ​​virtual networks can be configured separately with different network attributes such as logical topology, security rules, and performance characteristics to cater to different use cases. However, each of these sliced ​​virtual networks is built on the O-Cloud infrastructure. The characteristics and requirements of the network slices change semi-statically or dynamically, which optimizes the O-Cloud infrastructure and deployment resources as well as radio resource management (RRM) resources.

[0092] This use case enables rApps to influence NSSMF (Network Slice Subnet Management Function) and / or NFO for optimization or rebalancing of O-Cloud infrastructure resources (scale, recovery, etc.) via policies to achieve the desired SLA (Service Level Agreement) for a particular network slice.

[0093] 3.2 Entities / Resources Involved in This Use Case

[0094] The entities involved in this use case include the SMO pinning function (NFO / FOCOM / OAM) and the NSSMF, which supports the interpretation and enforcement of policies from the Non-RT RIC and provides the necessary control to the O-Cloud elements (IMS and DMS) based on the policies from the Non-RT RIC. Furthermore, at least one rApp and the Non-RT RIC framework obtains the necessary performance, configuration, and other data from the O-Cloud via the O2 interface and / or the O1 interface to define and update policies for optimization and / or rebalancing of O-Cloud infrastructure resources of a particular network slice to the SMO pinning function and / or the NSSMF. The O-Cloud (IMS and DMS) according to this exemplary embodiment is configured to read the control data from the SMO pinning function, enforce changes to the respective nodes or hardware under it, and provide feedback to the SMO post-control enforcement.

[0095] 3.3 Solution

[0096] FIG. 4 illustrates a flowchart of a method for providing policy-based guidance from a Non-RT RIC via an NFO and / or NSSMF for optimizing and / or rebalancing O-Cloud infrastructure resources to achieve a desired SLA of a network slice, according to an example embodiment.

[0097] Referring to FIG. 4, in step S401, an rApp (i.e., one or more rApps) according to an exemplary embodiment subscribes to FCAPS data, such as network slicing related FCAPS data (slice utilization, slice throughput, slice availability, etc.), network slicing NF LCM data, etc., from an E2 node and an O-Cloud service (IMS / DMS) via an O1 interface and an O2 interface, respectively.

[0098] In step S402, the rApp trains at least one AI / ML model and / or executes at least one predefined algorithm with data acquired via the O1 and O2 interfaces to generate a policy for the NSSMF and / or NFO to perform optimization. For example, if there is more requirement on the NF in terms of computation / control or memory, a scale-in policy may be generated for the NFO to scale in the NF to accommodate the load. If the requirement on the NF in terms of computation / control or memory is reduced, a scale-out policy may be generated for the NFO to scale out the NF to accommodate the load. An AAL-LPU profiling policy may be generated to select or optimize one or more of various AAL-LPU profiles for accelerating a particular function based on use case requirements such as URLLC, eMBB, eMTC, etc.

[0099] In step S403, the rApp passes the policy to at least one SMO fixed function and / or NSSMF.

[0100] In step S404, at least one SMO fixed function and / or NSSMF translates policies from the Non-RT RIC and enforces controls to the O-Cloud (e.g., sends control data or instructions to the IMS and / or DMS via the O2 interface).

[0101] In step S405, the O-Cloud (e.g., IMS and / or DMS) enforces the changes instructed by the SMO and / or NSSMF to the respective nodes and provides feedback to the SMO / NSSMF or Non-RT RIC upon success or failure of policy implementation.

[0102] In step S406, the Near-RT RIC enforces the policy received from the Non-RT RIC.

[0103] In step S407, the rApp monitors the performance of the UE, network slices, RAN functions, NFs, and O-Cloud infrastructure for policy evaluation.

[0104] 4.0 Use Case 4: O-Cloud Resource Management and SLA Guarantee for RAN Sharing

[0105] The O-Cloud resource management and SLA guarantee use case for RAN sharing according to example embodiments enables multiple operators to share the same O-RAN infrastructure while allowing operators to remotely configure and control the shared resources via remote O1, O2, and E2 interfaces.

[0106] 4.1 Background and Goals of this Use Case

[0107] RAN sharing offers the possibility for an operator (Operator A or Home Operator) to share a network infrastructure with another operator (Operator B or Visitor Operator). Exemplary embodiments allow Operator B to configure and control resources in the infrastructure owned by Operator A. In this scenario, the adoption of an O-RAN architecture can facilitate the remote control and configuration of such VNFs. Indeed, Operator B can monitor and control the remote O-DUs via the Near-RT RIC of Site B using a "remote" E2 interface, while all remote VNF configuration procedures can be handled by specific rApps in the Non-RT RIC located in the SMO of each operator.

[0108] The rApp according to this exemplary embodiment reads the SLAs from Operator B via a remote interface, which define the various requirements for Operator B on Operator A's infrastructure, and thereby optimizes the O-Cloud and RAN resources to achieve the expected SLAs via a policy mechanism.

[0109] 4.2 Entities / Resources Involved in This Use Case

[0110] The entities involved in this use case include the SMO fixed function (NFO / FOCOM / OAM), which supports the interpretation and enforcement of policies from the Non-RT RIC and provides the necessary control to the O-Cloud elements (IMS and DMS) based on the policies from the Non-RT RIC. Furthermore, at least one rApp and the Non-RT RIC framework obtains the necessary performance, configuration, and other data from the O-Cloud via the O2 interface and / or the O1 interface to define and update policies for RAN sharing optimization to the SMO fixed function. The Near-RT RIC framework supports the interpretation and enforcement of intent and policies from the Non-RT RIC to derive RAN sharing optimization at the RAN level with respect to expected behavior, and sends use case performance reports to the Non-RT RIC for evaluation and optimization. The O-Cloud (IMS and DMS) according to this exemplary embodiment is configured to read the control data from the SMO fixed function, enforce changes to the respective nodes or hardware below it, and provide feedback to the SMO post-control enforcement. The RAN node supports network state and UE performance reporting with the required granularity and provides them to the SMO via the O1 interface, and supports policy enforcement based on messages from the A1 and / or E2 interfaces that are expected to affect RRM behavior.

[0111] 4.3 Solution

[0112] FIG. 5 illustrates a flowchart of a method for providing policy-based guidance from a Non-RT RIC via an SMO pinning function for optimizing O-Cloud and RAN resources to achieve desired SLAs for RAN sharing, according to an example embodiment.

[0113] Referring to FIG. 5, in step S501, an rApp (i.e., one or more rApps) according to an exemplary embodiment subscribes to FCAPS data, such as RAN sharing related FCAPS data (slice level data, current utilization of infrastructure resources, etc.), from an E2 node and an O-Cloud service (IMS / DMS) via an O1 interface and an O2 interface, respectively.

[0114] In step S502, the rApp trains at least one AI / ML model and / or executes at least one predefined algorithm using data acquired via the O1 and O2 interfaces to generate a policy for the SMO fixed functions (e.g., FOCOM and / or NFO) to perform optimization. For example, if there is more requirement on the NF in terms of computation / control or memory, a scale-in policy may be generated for the NFO to scale in the NF to accommodate the load. If the requirement on the NF is reduced in terms of computation / control or memory, a scale-out policy may be generated for the NFO to scale out the NF to accommodate the load. An AAL-LPU profiling policy may be generated to select or optimize one or more of various AAL-LPU profiles for accelerating a particular function based on use case requirements such as URLLC, eMBB, eMTC, etc. An NF reconfiguration policy may be generated based on the O1 data.

[0115] In step S503, the rApp passes the policy to at least one SMO fixed function.

[0116] In step S504, at least one SMO fixed function translates policies from the Non-RT RIC and enforces controls to the O-Cloud (eg, sends control data or instructions to the IMS and / or DMS via the O2 interface).

[0117] In step S505, the O-Cloud (eg, IMS and / or DMS) enforces the changes instructed by the SMO to each node and provides feedback to the SMO / NSSMF or Non-RT RIC upon success or failure of policy implementation.

[0118] In step S506, the Near-RT RIC enforces the policy received from the Non-RT RIC.

[0119] In step S507, the rApp monitors the performance of the UE, network slices, RAN functions, NFs, and O-Cloud infrastructure for policy evaluation.

[0120] 5.0 Use Case 5: Infrastructure Network Element Recovery

[0121] The infrastructure and network element restoration use case according to the example embodiments enables operators to define different restoration scenarios for various O-RAN elements such as the O-Cloud and network functions deployed over the O-Cloud infrastructure.

[0122] 5.1 Background and Goals of this Use Case

[0123] Network restoration is becoming important for mobile operators to perform cloud-native operations in mobile networks. Network restoration involves monitoring fault and performance data of network elements, receiving fault events that mark undesirable states of the network elements, analyzing policy actions defined for the faults, correlating with the topology of the events, and passing the correct policy action intent to make the network applications live again. Prior art network restoration capabilities deployed in network equipment are limited and vendor-specific.

[0124] The infrastructure and network element restoration use case according to the example embodiments provides various options via the Non-RT RIC platform and rApp to enable RAN network functions deployed on the O-Cloud and network element restoration functions for the O-Cloud infrastructure.

[0125] 5.2 Entities / Resources Involved in This Use Case

[0126] The entities involved in this use case include the SMO Fixation Function (NFO / FOCOM / OAM), which supports the interpretation and enforcement of policies from the Non-RT RIC and provides the necessary control to the O-Cloud elements (IMS and DMS) based on the policy intent from the Non-RT RIC. Furthermore, at least one rApp and the Non-RT RIC framework obtains the necessary performance, configuration, and other data from the O-Cloud via the O2 interface and / or from the NF via the O1 interface to define and update the desired policy intent for recovery to the SMO Fixation Function. The O-Cloud (IMS and DMS) according to this exemplary embodiment is configured to read the control data from the SMO Fixation Function, enforce changes to the respective nodes or hardware under it, and provide feedback to the SMO post-control enforcement.

[0127] 5.3 Solution

[0128] FIG. 6 illustrates a flowchart of a method for providing network element recovery policy-based guidance from a Non-RT RIC via a SMO pinning function, according to an example embodiment.

[0129] Referring to FIG. 6, in step S601, an rApp (i.e., one or more rApps) according to an exemplary embodiment subscribes to FCAPS data, such as O-Cloud fault / performance data, NF fault / performance data (e.g., NF_faulted, NF_deployment_failed, Hardware_failure, etc.), from an E2 node and an O-Cloud service (IMS / DMS) via an O1 interface and an O2 interface, respectively.

[0130] In step S602, the rApp trains at least one AI / ML model and / or executes at least one predefined algorithm with data acquired via the O1 and O2 interfaces to generate desired policy intent for recovery in different schemes of the respective nodes. For example, if an application goes down and a failure event of the respective application is received by the rApp, the rApp according to the exemplary embodiment evaluates possible root causes based on the defined algorithm and generates policy action intent (e.g., restart the application, relocate the application to a different server, increase the resource limit of the application, etc.). As another example, if a hardware goes down and a failure event of the respective hardware is received by the rApp, the rApp according to the exemplary embodiment evaluates possible root causes based on the defined algorithm and generates policy action intent (e.g., reboot the hardware, relocate the application to a different server, and if the problem persists after rebooting the hardware, issue a hardware maintenance ticket in the incident management module).

[0131] In step S603, the rApp passes the policy to at least one SMO fixed function (eg, NFO or FOCOM).

[0132] In step S604, at least one SMO pinning function translates policies from the Non-RT RIC and enforces controls to the O-Cloud (e.g., sending control data or instructions to the IMS and / or DMS via the O2 interface and / or via an API to take desired actions such as rebooting hardware, relocating applications to a different server, etc.).

[0133] In step S605, the O-Cloud (e.g., IMS and / or DMS) enforces the changes instructed by the SMO (NFO / FOCOM) to the respective applications and / or hardware and provides feedback to the SMO or Non-RT RIC upon success or failure of policy implementation.

[0134] In step S606, the rApp monitors performance and / or configuration changes of the RAN NFs and O-Cloud infrastructure for closed-loop evaluation of the policy and determines whether to take follow-up action, such as raising an incident ticket.

[0135] 6.0 Use Case 6: Infrastructure Network Troubleshooting

[0136] An infrastructure network troubleshooting use case according to an example embodiment enables mobile network operators to discover the root cause of network element fault events and performance degradation based on AI / ML algorithms and correlation of data from network functions and O-Cloud infrastructure.

[0137] 6.1 Background and Goals of this Use Case

[0138] For complex virtual application deployment scenarios, manually finding the root cause of a failure event or performance degradation is a very time-consuming process and may result in network outages for extended periods if there is a delay in fixing the problem. Finding the root cause automatically involves monitoring the fault and performance data of network elements, performing root cause analysis using AI / ML algorithms and correlation of data from various layers, digging into the exact cause of the problem, and taking appropriate actions.

[0139] An infrastructure network troubleshooting use case according to an example embodiment provides various options via the Non-RT RIC platform and rApp to enable root cause analysis of network element issues for RAN network functions deployed on the O-Cloud and the O-Cloud infrastructure.

[0140] 6.2 Entities / Resources Involved in This Use Case

[0141] The entities involved in this use case include the SMO Fixation Function (NFO / FOCOM / OAM), which supports the interpretation and enforcement of policies from the Non-RT RIC, and provides the necessary control to the O-Cloud elements (IMS and DMS) based on the policies from the Non-RT RIC. Furthermore, an incident management tool is provided to raise network incidents so that the respective operational teams can act on them. Furthermore, at least one rApp and the Non-RT RIC framework obtains the necessary fault and performance data from the NFs via the O1 interface and from the O-Cloud via the O2 interface to define and update policy intent for root cause analysis to the SMO Fixation Function. The O-Cloud (IMS and DMS) according to this exemplary embodiment is configured to read the control data from the SMO Fixation Function, enforce changes to the respective nodes or hardware under it, and provide feedback to the SMO post-control enforcement.

[0142] 6.3 Solution

[0143] FIG. 7 illustrates a flowchart of a method for providing root cause analysis policy-based guidance from a Non-RT RIC via an SMO pinning function for determining the root cause of a fault event and / or performance degradation of a network element, according to an example embodiment.

[0144] Referring to FIG. 7, in step S701, an rApp (i.e., one or more rApps) according to an exemplary embodiment subscribes to FCAPS data such as O-Cloud fault / performance data, NF fault / performance data (e.g., CPU_utilization, Memory_utilization, fan_failure, NF_faulted, NF_deployment_failed, Hardware_failure, etc.) from an E2 node and an O-Cloud service (IMS / DMS) via an O1 interface and an O2 interface, respectively.

[0145] In step S702, the rApp trains at least one AI / ML model and / or executes at least one predefined algorithm with the data obtained through the O1 and O2 interfaces to correlate the data and dig up or determine the exact root cause scheme for each node. For example, if it is determined that the application performance has dropped below a threshold, this performance KPI is received by the rApp. The rApp then evaluates the possible root causes based on the defined algorithm (e.g., CPU, memory overutilization on O-Cloud, checking the number of applications deployed on the same cloud, correlating the performance of all applications on the same cloud and confirming that CPU overallocation is the root cause, triggering the occurrence of the root cause incident, and proposing an action to add more computation to the O-Cloud). As another example, if an application is not reachable, rApp may find the O-Cloud component or node on which this application is deployed, check if there is a problem with the O-Cloud infrastructure by correlating with related failure events from the infrastructure, raise a ticket in the Incident Manager about this hardware issue, and evaluate the possible root cause by passing a policy intent to NFO / FOCOM to deploy the application on a different O-Cloud component (e.g., server or node).

[0146] In step S703, the rApp passes the intent to NFO and / or FOCOM and / or raises an incident ticket for root cause analysis.

[0147] In step S704, the NFO / FOCOM translates the policy intent from the Non-RT RIC and enforces the control to the O-Cloud (e.g., sending control data or instructions to the IMS and / or DMS via the O2 interface and / or via API to take the desired action). If an incident occurs within the Incident Management module, the operations team is notified and can immediately act on the root cause to resolve the issue.

[0148] In step S705, the rApp monitors performance and / or configuration changes of the RAN NFs and the O-Cloud infrastructure for correlation of data over time.

[0149] 8 is a diagram of an example environment 800 in which the systems and / or methods described herein may be implemented. As shown in FIG. 8, the environment 800 may include a user device 810, a platform 820, and a network 830. The devices of the environment 800 may be interconnected by 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 FIG. 1 through FIG. 7 may be performed by any combination of elements shown in FIG. 8.

[0150] The user device 810 includes one or more devices that can receive, generate, store, process, and / or provide information related to the platform 820. For example, the user device 810 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 telephone, etc.), a wearable device (e.g., smart glasses or a smart watch), or a similar device. In some implementations, the user device 810 can receive information from and / or transmit information to the platform 820.

[0151] The platform 820 includes one or more devices that can receive, generate, store, process, and / or provide information. In some implementations, the platform 820 may include a cloud server or a collection of cloud servers. In some implementations, the platform 820 may be designed to be modular so that specific software components can be swapped out depending on specific needs. Thus, the platform 820 can be easily and / or quickly reconfigured for various uses.

[0152] In some implementations, as shown, the platform 820 may be hosted in a cloud computing environment 822. Notably, although the implementations described herein describe the platform 820 as being hosted in a cloud computing environment 822, in some implementations the platform 820 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 822 includes an environment that hosts platform 820. Cloud computing environment 822 may provide services such as computing, software, data access, storage, etc. that do not require end-user (e.g., user device 810) knowledge of the physical location and configuration of the systems and / or devices that host platform 820. As shown, cloud computing environment 822 may include a collection of computing resources 824 (collectively referred to as “computing resources 824” or individually as “computing resource 824”).

[0154] The computational resources 824 include one or more personal computers, a fleet of computing devices, workstation computers, server devices, or other types of computing and / or communication devices. In some implementations, the computational resources 824 may host the platform 820. Cloud resources may include computing instances executing within the computational resources 824, storage devices provided within the computational resources 824, data transfer devices provided by the computational resources 824, etc. In some implementations, the computational resources 824 may communicate with other computational resources 824 by wired connections, wireless connections, or a combination of wired and wireless connections.

[0155] As further shown in FIG. 8, the computational resources 824 include a collection of cloud resources, such as one or more applications (“APP”) 824-1, one or more virtual machines (“VM”) 824-2, virtualized storage (“VS”) 824-3, and one or more hypervisors (“HYP”) 824-4.

[0156] Applications 824-1 include one or more software applications that may be provided to or accessed by user device 810. Applications 824-1 may eliminate the need to install or run software applications on user device 810. For example, applications 824-1 may include software associated with platform 820 and / or any other software capable of being provided via cloud computing environment 822. In some implementations, one application 824-1 may send and receive information to one or more other applications 824-1 via virtual machine 824-2.

[0157] The virtual machine 824-2 includes a software implementation of a machine (e.g., a computer) that executes programs like a physical machine. The virtual machine 824-2 can be either a system virtual machine or a process virtual machine, depending on the application and the degree to which the virtual machine 824-2 corresponds to any real 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, the virtual machine 824-2 can run on behalf of a user (e.g., the user device 810) and manage the infrastructure of the cloud computing environment 822, such as data management, synchronization, or long-term data transfer.

[0158] Virtualized storage 824-3 includes one or more storage systems and / or one or more devices that use virtualization techniques within the storage systems or devices of the computational resources 824. In some implementations, within the context of a storage system, 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 such that the storage system can be accessed regardless of the physical storage or heterogeneous structure. The separation may allow administrators flexibility in the storage system regarding how they manage the 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 optimization of storage usage, server consolidation, and / or non-disruptive file migration performance.

[0159] The hypervisor 824-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 the computational resource 824. The hypervisor 824-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 the virtualized hardware resources.

[0160] The network 830 includes one or more wired and / or wireless networks. For example, the network 830 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 8 are provided as an example. In practice, there may be additional devices and / or networks, fewer devices and / or networks, different devices and / or networks, or devices and / or networks arranged differently than those shown in Figure 8. Furthermore, two or more devices shown in Figure 8 may be implemented within a single device, or a single device shown in Figure 8 may be implemented as multiple distributed devices. Additionally, or instead, a set of devices (e.g., one or more devices) of environment 800 may perform one or more functions described as being performed by another set of devices of environment 800.

[0162] 9 is a diagram of example components of a device 900. The device 900 may correspond to a user device 810 and / or a platform 820. As shown in FIG. 9, the device 900 may include a bus 910, a processor 920, a memory 930, a storage component 940, an input component 950, an output component 960, and a communication interface 970.

[0163] The bus 910 includes components that enable communication between the components of the device 900. The processor 920 may be implemented in hardware, firmware, or a combination of hardware and software. The processor 920 may be a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or another type of processing component. In some implementations, the processor 920 includes one or more processors that can be programmed to perform certain functions. The memory 930 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 for use by the processor 920.

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

[0165] The communications interface 970 includes transceiver-like components (e.g., a transceiver and / or a separate receiver and transmitter) that enable the device 900 to communicate with other devices, such as by a wired connection, a wireless connection, or a combination of wired and wireless connections. The communications interface 970 may enable the device 900 to receive information from and / or provide information to another device. For example, the communications interface 970 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] The device 900 may perform one or more processes described herein. The device 900 can perform these processes in response to the processor 920 executing software instructions stored by a non-transitory computer-readable medium, such as the memory 930 and / or the storage component 940. 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 spanning multiple physical storage devices.

[0167] Software instructions may be loaded into memory 930 and / or storage component 940 from another computer-readable medium or from another device via communications interface 970. The software instructions stored in memory 930 and / or storage component 940, when executed, may cause processor 920 to perform one or more of the processes described herein.

[0168] Additionally, or instead, hardwired circuitry may be used in place of, or in combination with, software instructions to perform one or more of the 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 9 is provided as an example. In practice, device 300 may include additional components, fewer components, different components, or components arranged differently than those shown in Figure 9. Additionally or alternatively, a set of components (e.g., one or more components) of device 900 may perform one or more functions described as being performed by another set of components of device 900.

[0170] In some embodiments, any one of the operations or processes of FIGS. 1 through 7 may be performed by or using any one of the elements shown in FIGS.

[0171] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise forms disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations. Furthermore, one or more features from one or more embodiments can be combined with one or more features of one or more other embodiments described above.

[0172] Some embodiments may relate to systems, methods, and / or computer-readable media at any possible level of technical detail of integration. Furthermore, one or more of the above components described above may be implemented as instructions stored in 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(s) having computer-readable program instructions for causing a processor to perform operations.

[0173] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but 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 thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer diskettes, hard disks, random access memories (RAMs), read-only memories (ROMs), erasable programmable read-only memories (EPROMs or flash memories), static random access memories (SRAMs), portable compact disk read-only memories (CD-ROMs), digital versatile disks (DVDs), memory sticks, floppy disks, mechanically encoded devices such as punch cards or grooved ridge structures with instructions recorded thereon, and any suitable combination thereof. As used herein, computer-readable storage media should not be construed as being a transitory signal per se, such as electric waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted through electrical wires.

[0174] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to the respective 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 transmission fiber, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in 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 in the respective computing / processing device.

[0175] The computer readable program code / instructions for performing the 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 an integrated circuit, 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 be executed 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 through any type of network, including a local area network (LAN) or wide area network (WAN), or may be connected to an external computer (e.g., through 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) can execute computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry to perform an aspect or operation.

[0176] These computer-readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to generate a machine such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for performing the functions / operations 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 capable of directing a computer, programmable data processing apparatus, and / or other device to function in a particular manner, such that the computer-readable storage medium on which the instructions are stored comprises a product including instructions implementing aspects of the functions / operations specified in one or more blocks of the flowcharts and / or block diagrams.

[0177] The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause the computer, other programmable apparatus, or other device to execute a series of operational steps to generate 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.

[0178] 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 portion of a microservice, a module, a segment, or an instruction that comprises one or more executable instructions that implement the specified 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 described in the blocks may occur in a different order than described in the figures. For example, two blocks shown in succession may actually be executed simultaneously or substantially simultaneously, or the blocks may sometimes be executed in the reverse order depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, as well as 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.

[0179] It will be apparent that the systems and / or methods described herein may be implemented in various forms of hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods is not intended to limit the implementation. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code, and it will be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

Claims

1. 1. A system for implementing a service management and orchestration (SMO) framework for managing and orchestrating an Open Radio Access Network (O-RAN) Cloud (O-Cloud) platform, the system comprising: at least one memory storing first instructions and second instructions; at least one first processor configured to execute the first instructions to implement a non-real-time radio access network (RAN) intelligent controller (Non-RT RIC) hosting a plurality of applications (rApps); at least one second processor configured to execute the second instructions to implement an SMO fixed function; Equipped with The at least one first processor: Obtaining O1 data received via an O1 interface of the SMO framework, the O1 interface being for communicating with Virtualized Network Functions (VNFs) hosted on multiple physical nodes of the O-Cloud platform; Acquiring O2 data received via an O2 interface of the SMO framework, the O2 interface being for communicating with an Infrastructure Management Service (IMS) and a Deployment Management Service (DMS) of the O-Cloud platform; generating a policy for optimizing the O-Cloud platform or the VNF through the O1 interface of the SMO fixed function or the SMO framework based on at least one of the acquired O1 data and the acquired O2 data by an rApp from among the plurality of applications; configured to execute the first instructions to the at least one second processor is configured to execute the second instructions to receive and manage the policies from the Non-RT RIC, generate optimization controls for transmission to the O-Cloud platform via the O2 interface, or transmit the policies to the IMS and DMS via the O2 interface for implementation.

2. 2. The system of claim 1, wherein the at least one first processor is configured to execute the first instructions to train and deploy at least one artificial intelligence / machine learning (AI / ML) model to generate the policy based on the at least one of the acquired O1 data and the acquired O2 data.

3. The system of claim 1 , wherein the at least one first processor is configured to execute the first instructions to obtain feedback from the O-Cloud platform or the VNF and evaluate the policy.

4. The system of claim 1 , wherein the O2 data includes node-level or O-Cloud-level O-Cloud inventory and telemetry data.

5. The system of claim 1 , wherein the O1 data comprises fault, configuration, accounting, performance, and security (FCAPS) data.

6. The system of claim 1 , wherein the SMO fixed functions include a Network Function Orchestrator (NFO) and a Federated O-Cloud Orchestration and Management (FOCOM).

7. the at least one of the acquired O1 data and the acquired O2 data includes data regarding at least one of a central processing unit (CPU) utilization for a network function (NF), bare metal power consumption, a CPU load, a memory load, and a CPU frequency; The policy is a policy for energy saving for at least one of NF, O-Cloud infrastructure, and O-Cloud hardware; The system of claim 1 .

8. The at least one of the acquired O1 data and the acquired O2 data includes data related to at least one of user mobility performance, traffic distribution between cells, neighboring cell measurements, NF configuration, NF inventory, and NF telemetry; The policy is a policy for RAN network or infrastructure load balancing. The system of claim 1 .

9. the at least one of the acquired O1 data and the acquired O2 data includes data related to at least one of network slice utilization, network slice throughput, network slice availability, and network slice lifecycle management (LCM); The policy is a policy for dynamic allocation and optimization of O-Cloud resources for network slicing. The system of claim 1 .

10. the at least one of the acquired O1 data and the acquired O2 data includes RAN sharing related FCAPS data; The policy is a policy for O-Cloud resource management and service legal agreement (SLA) guarantee for RAN sharing; The system of claim 1 .

11. the at least one of the acquired O1 data and the acquired O2 data includes at least one of O-Cloud failure data, O-Cloud performance data, NF failure data, and NF performance data; The policy is a policy for recovery or root cause analysis of performance degradation or failure of O-Cloud or O-Cloud infrastructure network elements; The system of claim 1 .

12. 1. A method for optimizing O-Cloud resources using policy-based guidance from a Non-RT RIC, the method comprising: Acquiring O1 data received by an application (rApp) hosted in the Non-RT RIC via an O1 interface of an SMO framework for managing and orchestrating an Open Radio Access Network (O-RAN) Cloud (O-Cloud) platform, the O1 interface being for communicating with Virtualized Network Functions (VNFs) hosted in a plurality of physical nodes of the O-Cloud platform; Acquiring O2 data received by the rApp via an O2 interface of the SMO framework, the O2 interface being for communicating with an Infrastructure Management Service (IMS) and a Deployment Management Service (DMS) of the O-Cloud platform; generating, by the rApp, a policy for optimizing the O-Cloud platform or the VNF through an SMO fixed function or the O1 interface of the SMO framework based on at least one of the acquired O1 data and the acquired O2 data; providing the policy to an SMO fixed function for implementation or performing configuration changes to optimize the O-Cloud resources via the O2 interface; A method comprising:

13. 13. The method of claim 12, further comprising training and deploying at least one artificial intelligence / machine learning (AI / ML) model to generate the policy based on the at least one of the acquired O1 data and the acquired O2 data.

14. The method of claim 12, further comprising obtaining feedback from the O-Cloud platform or the VNF by the rApp to evaluate the policy.

15. The method of claim 12 , wherein the O2 data includes node-level or O-Cloud-level O-Cloud inventory and telemetry data.

16. The method of claim 12 , wherein the O1 data includes fault, configuration, accounting, performance, and security (FCAPS) data.

17. At least one non-transitory computer-readable storage medium having instructions executable by at least one processor to perform a method for optimizing O-Cloud resources using policy-based guidance from a Non-RT RIC, the method comprising: Acquiring O1 data received by an application (rApp) hosted in the Non-RT RIC via an O1 interface of an SMO framework for managing and orchestrating an Open Radio Access Network (O-RAN) Cloud (O-Cloud) platform, the O1 interface being for communicating with Virtualized Network Functions (VNFs) hosted in a plurality of physical nodes of the O-Cloud platform; Acquiring O2 data received by the rApp via an O2 interface of the SMO framework, the O2 interface being for communicating with an Infrastructure Management Service (IMS) and a Deployment Management Service (DMS) of the O-Cloud platform; generating, by the rApp, a policy for optimizing the O-Cloud platform or the VNF through an SMO fixed function or the O1 interface of the SMO framework based on at least one of the acquired O1 data and the acquired O2 data; providing the policy to an SMO fixed function for implementation or performing configuration changes to optimize the O-Cloud resources via the O2 interface; At least one non-transitory computer readable storage medium comprising:

18. 13. The at least one non-transitory computer-readable storage medium of claim 12, wherein the method further comprises training and deploying at least one artificial intelligence / machine learning (AI / ML) model to generate the policy based on the at least one of the acquired O1 data and the acquired O2 data.

19. 13. The at least one non-transitory computer-readable storage medium of claim 12, wherein the method further comprises obtaining, by the rApp, feedback from the O-Cloud platform or the VNF and evaluating the policy.

20. The O2 data includes node-level or O-Cloud-level O-Cloud inventory and telemetry data; The O1 data includes fault, configuration, accounting, performance, and security (FCAPS) data; 13. At least one non-transitory computer readable storage medium as recited in claim 12.

Images