Network-Aware Compute 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 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 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. Because different vendors are involved, the types of hardware and / or software provided may also vary. 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 may be physical hardware form (e.g., non-VM-based).

[0003] 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 O-RAN systems and to automate and optimize RAN operations.

[0004] RICs are divided into two types: non-real-time RICs (Non-RT RICs) and near-real-time RICs (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, which is an interface enabling 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, which is an interface connecting 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 milliseconds and 1 second and is coupled with the O-CU control plane (O-CU-CP) and O-CU user plane (O-CU-UP) via 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 collaborate 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 located within the SMO framework, which manages and orchestrates 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] More specifically, O-RAN E2 nodes (i.e., O-CU, O-DU, etc. connected to the Near-RT RIC via the E2 interface) are orchestrated on the O-Cloud as virtualized network functions (VNFs). SMO anchored functions (e.g., Network Function Orchestrator (NFO) and Federated O-Cloud Orchestration and Management (FOCOM)) handle the management and orchestration of the VNFs and the O-Cloud. However, in the prior art, SMO anchored functions are limited to leveraging intelligence through correlation of observability from E2 nodes, infrastructure, and network functions (NFs) to influence management / orchestration. O-Cloud resources cannot be optimized based on intent (e.g., policy goals of NFO / FOCOM) or by configuration changes via the O2 interface (i.e., the interface between the SMO and the 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 have any use cases been 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 exemplary embodiment, a system and method is provided that enables a Non-RT RIC to provide intelligence to O-Cloud operations and functions by optimizing O-Cloud resources.

[0010] According to an example 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-RT RAN Intelligent Controller (Near-RT RIC) 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 Non-RT.and 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 second instructions to implement an SMO pinning function, wherein the at least one first processor is configured to execute the first instructions 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 on 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; and generate, by an rApp from among a plurality of applications, a policy for optimizing the O-Cloud platform or the VNFs via the SMO pinning function or the O1 interface of the SMO framework based on at least one of the acquired O1 data and the acquired O2 data; and wherein the at least one second processor is configured to execute the first instructions to implement an SMO pinning function or a policy for optimizing the O-Cloud platform or the VNFs via the O1 interface of the SMO framework based on at least one of the acquired O1 data and the acquired O2 data. and configured to execute second instructions to receive and manage policies from the RIC and 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.

[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 node-level or O-Cloud-level O-Cloud inventory and telemetry data.

[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 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, the O1 interface being for communicating with Virtualized Network Functions (VNFs) hosted on multiple physical nodes of the O-Cloud platform; obtaining, by the rApp, 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, 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 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 node-level or O-Cloud-level O-Cloud inventory and telemetry data.

[0027] O1 data may include fault, configuration, accounting, 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, the O1 interface being for communicating with Virtualized Network Functions (VNFs) hosted on multiple physical nodes of the O-Cloud platform; obtaining, by the rApp, 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, 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 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 node-level or O-Cloud-level O-Cloud inventory and telemetry data.

[0032] O1 data may include fault, configuration, accounting, performance, and security (FCAPS) data. [Brief explanation 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. [Figure 2] 10 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. [Figure 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 anchoring 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 to optimize and / or rebalance O-Cloud infrastructure resources to achieve a desired service level agreement (SLA) for a network slice, according to an example embodiment. [Figure 5] 1 is a flowchart of a method for providing policy-based guidance from a Non-RT RIC via an SMO anchoring 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 an SMO anchoring 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 anchoring function to determine the root cause of a failure 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 INVENTION

[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 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. Moreover, 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). 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) concurrently, 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. 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 explicitly described as such. Additionally, as used herein, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more." Where only one item is intended, the term "one" or similar language is used. Additionally, 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 expressly stated otherwise. Furthermore, phrases such as "at least one of [A] and [B]" and "at least one of [A] or [B]" should be understood to include A only, B only, or both A and B.

[0040] Exemplary embodiments of the present disclosure provide systems and methods that utilize one or more rApps in 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 (continued) are diagrams of an O-RAN system architecture according to an example embodiment. Referring to FIG. 1 and 1c (continued), the O-RAN system architecture includes an SMO framework, a Near-RT RIC, and an O-Cloud. The SMO framework includes fixed functions (SMO / NFO / OAM) and a Non-RT RIC.

[0042] According to an exemplary embodiment, the Non-RT RIC hosts third-party applications as rApps within 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 neighbor 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 O-Cloud resource optimization when CM changes via SMO fixation 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 O-Cloud resources and generate optimization controls or policies for the O-Cloud via the O2 interface. 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 changes and recommendations made by the Non-RT RIC and / or the SMO.

[0045] According to 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 the 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., restart, redeployment, re-instantiation, etc.), scale in / out in horizontal scaling (e.g., scale 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., audits, real-time state adjustments, NF health, etc.), diagnostics, etc.

[0047] Additionally, according to one or more exemplary embodiments, third-party rApps may influence 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 the 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 exemplary embodiments, third-party rApps can 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 downstream or underlying O-Cloud events can be performed to discover or analyze root causes and take smart and / or intelligence-driven actions towards the NF and O-Cloud. As a result, rApps according to exemplary embodiments can make the O-Cloud more operator-driven.

[0050] According to an example embodiment, an 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, an rApp according to an example embodiment can pass intent (i.e., policy or policy goal) to the NFO, which then 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 in rebooting, relocating, and / or re-instantiating the NF.

[0051] Additionally, FOCOM is responsible for LCM of O-Cloud. For example, an rApp according to one embodiment can pass intent to FOCOM to guide the IMS to take action. For example, the rApp can assist in 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 toward the O-Cloud, such as changing the P-state or C-state of a vCPU when needed or desired for energy conservation 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] Below, use cases for O-Cloud resource optimization according to various exemplary embodiments are described.

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

[0057] The O-Cloud energy saving use case according to the example embodiments allows 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 an important topic for mobile operators. Energy saving (ES) functions involve different network mechanisms, network nodes and layers that operate on different timescales. 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 underlying 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 (Operations 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 obtain 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 savings for the SMO Fixed Function. The O-Cloud (IMS and DMS) according to this exemplary embodiment is configured to read 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.

[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, and CPU frequency for an NF from the E2 node and O-Cloud service (IMS / DMS) via the O1 interface and the O2 interface, respectively.

[0066] In step S202, the rApp trains at least one AI / ML model and / or runs at least one predefined algorithm using data obtained via the O1 and O2 interfaces to generate policy intents for energy conservation in different schemes for each node. Examples of policy intents include changing CPU frequency, reducing CPU load, 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 (e.g., sends control data or instructions to the IMS and / or DMS via the O2 interface).

[0069] In step S205, the O-Cloud (e.g., 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 interface 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] Traffic balancing 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 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 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. Additionally, at least one rApp and the Non-RT RIC framework obtain 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 control data from the SMO Pinning Function, enforce changes to the respective nodes or hardware underneath, 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 anchoring 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, inter-cell traffic distribution, neighboring cell measurement data, NF configuration, NF inventory and telemetry, from the E2 node and O-Cloud service (IMS / DMS) via the O1 interface and the O2 interface, respectively.

[0082] In step S302, the rApp trains at least one AI / ML model and / or runs at least one predefined algorithm using data obtained via the O1 and O2 interfaces to generate a load balancing policy or configuration change over O1 or O2. For example, if the NF load is high and there is an available target cell for mobility, a traffic steering policy may be generated. If there is no available target cell, a scale-in policy for NFO may be generated 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 not heavily 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 (e.g., 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 on 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] A use case of dynamic allocation and optimization of O-Cloud resources for network slicing according to example embodiments enables the Non-RT RIC and O2 interface 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 sliced ​​virtual network can be separately configured with different network attributes, such as logical topology, security rules, and performance characteristics, to accommodate 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 allows rApps to influence the 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 anchoring function (NFO / FOCOM / OAM) and the NSSMF, which support the interpretation and enforcement of policies from the Non-RT RIC and provide 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 obtain 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 optimizing and / or rebalancing O-Cloud infrastructure resources of a particular network slice to the SMO anchoring 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 anchoring function, enforce changes to the respective nodes or hardware underneath, 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 for 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 the O1 interface and the O2 interface, respectively.

[0098] In step S402, the rApp trains at least one AI / ML model and / or runs at least one predefined algorithm using data obtained via the O1 and O2 interfaces to generate policies for the NSSMF and / or NFO to perform optimization. For example, if there are more requirements 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 requirements on the NF in terms of computation / control or memory are 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 specific functions based on use case requirements, such as URLLC, eMBB, and eMTC.

[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 the policy from the Non-RT RIC and enforces the control 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 on 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 slice, RAN function, NF, 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 enable 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 at 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 each operator's SMO.

[0108] The rApp according to this exemplary embodiment reads the SLA from Operator B via a remote interface, which defines the various requirements for Operator B on Operator A's infrastructure, and thereby optimizes the O-Cloud and RAN resources to achieve the expected SLA 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 obtain 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 for the SMO fixed function. The Near-RT RIC framework supports the interpretation and execution 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 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 these 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 influence 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 anchoring 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 the E2 node and O-Cloud service (IMS / DMS) via the O1 interface and the O2 interface, respectively.

[0114] In step S502, the rApp trains at least one AI / ML model and / or runs at least one predefined algorithm using data obtained via the O1 and O2 interfaces to generate policies for SMO fixed functions (e.g., FOCOM and / or NFO) to perform optimization. For example, if there are more requirements on the NF in terms of computation / control or memory, a scale-in policy for the NFO may be generated to scale in the NF to accommodate the load. If the requirements on the NF in terms of computation / control or memory are reduced, a scale-out policy for the NFO may be generated 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 specific functions, such as URLLC, eMBB, and eMTC, based on use case requirements. 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 (e.g., sends control data or instructions to the IMS and / or DMS via the O2 interface).

[0117] In step S505, the O-Cloud (e.g., IMS and / or DMS) enforces the changes instructed by the SMO to the respective nodes 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 slice, RAN function, NF, 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 resiliency is becoming important for mobile operators to perform cloud-native operations in mobile networks. Network resiliency 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 the events with the topology, and passing the correct policy action intent to make network applications live again. Prior art network resiliency 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 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. Additionally, 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 underneath, 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 an SMO anchoring 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 failure / performance data, NF failure / performance data (e.g., NF_faulted, NF_deployment_failed, Hardware_failure, etc.), from an E2 node and an O-Cloud service (IMS / DMS) via the O1 interface and the O2 interface, respectively.

[0130] In step S602, 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 desired policy intentions for recovery in different schemes for each node. For example, if an application goes down and a failure event for 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 a policy action intention (e.g., restart the application, relocate the application to a different server, increase the resource limits of the application, etc.). As another example, if hardware goes down and a failure event for 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 a policy action intention (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 the policy 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 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 causes of network element failure 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 can result in network outages for extended periods if there is a delay in fixing the problem. Automatically finding the root cause 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 action.

[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 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 Fixing 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. Additionally, an incident management tool is provided to raise network incidents so that the respective operations teams can act on them. Furthermore, at least one rApp and the Non-RT RIC framework obtain the necessary fault and performance data from the NF via the O1 interface and from the O-Cloud via the O2 interface to define and update the policy intent for root cause analysis to the SMO Fixing Function. The O-Cloud (IMS and DMS) according to this exemplary embodiment is configured to read control data from the SMO Fixing Function, enforce changes to the respective nodes or hardware underneath, 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 anchoring function to determine the root cause of a network element failure event and / or performance degradation, 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 failure / performance data, NF failure / 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 the O1 interface and the O2 interface, respectively.

[0145] In step S702, the rApp trains at least one AI / ML model and / or runs at least one predefined algorithm using data obtained via the O1 and O2 interfaces to correlate the data and dig into or determine the exact root cause scheme for each node. For example, if it is determined that application performance has dropped below a threshold, this performance KPI is received by the rApp. The rApp then evaluates possible root causes based on the defined algorithm (e.g., CPU and memory overutilization on the 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 an incident for the root cause, and proposing an action to add more computation to the O-Cloud). As another example, if an application is unreachable, 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 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, environment 800 may include a user device 810, a platform 820, and a network 830. The devices of 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 FIGS. 1 through 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 phone, 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] Platform 820 includes one or more devices that can receive, generate, store, process, and / or provide information. In some implementations, platform 820 may include a cloud server or a collection of cloud servers. In some implementations, platform 820 may be designed modularly so that specific software components can be swapped out depending on specific needs. Thus, platform 820 can be easily and / or quickly reconfigured for various uses.

[0152] In some implementations, as shown, platform 820 may be hosted in a cloud computing environment 822. Notably, although the implementations described herein describe platform 820 as being hosted in a cloud computing environment 822, in some implementations 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 compute 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 via 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 group 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 that may be 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] Virtual machine 824-2 includes a software implementation of a machine (e.g., a computer) that executes programs like a physical machine. 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 virtual machine 824-2 corresponds to any 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 824-2 can run on behalf of a user (e.g., user device 810) and manage the infrastructure of 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 storage system flexibility regarding how they manage storage for end users. File virtualization can eliminate the dependency between data accessed at the file level and where the file is physically stored. This can enable optimization of storage usage, server consolidation, and / or nondisruptive 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 computing 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 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, 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. The input component 950 includes components that enable the device 900 to receive information via user input (e.g., a touchscreen display, a keyboard, a keypad, a mouse, buttons, switches, and / or a microphone), etc. 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 communication 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 communication interface 970 may enable the device 900 to receive information from and / or provide information to another device. For example, the communication 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 communication 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, fewer, different, or differently arranged components 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 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. 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 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 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. The 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 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 sticks, floppy disks, mechanically encoded devices such as punch cards or groove ridge structures having instructions recorded thereon, and any suitable combination thereof. As used herein, computer-readable storage media should not be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission 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 each computing / processing device or to an external computer or external 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.

[0175] 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 through 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., 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 aspects or operations.

[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 produce a machine, such that the instructions, which execute on the processor of the computer or other programmable data processing apparatus, create means for performing 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 direct 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 containing instructions that implement aspects of the functions / acts 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 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.

[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 microservice, module, segment, or portion of an instruction set, comprising 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 noted in the blocks may occur in a different order than noted in the figures. For example, two blocks shown in succession may actually be executed concurrently or substantially concurrently, 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, and combinations of blocks in the block diagrams and / or flowchart diagrams, can 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 that stores 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) that hosts multiple 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 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 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; the at least one of the acquired O1 data and the acquired O2 data includes RAN sharing related FCAPS (Fault, Configuration, Accounting, Performance, Security) data; The system, wherein the policy is a policy for O-Cloud resource management and service level agreement (SLA) guarantee for RAN sharing.

2. 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 that stores 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) that hosts multiple 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 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 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; 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 system, wherein the policy is a policy for recovery or root cause analysis of performance degradation or failure of an O-Cloud or O-Cloud infrastructure network element.

3. 3. 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.

4. The system of claim 1 or 2, 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.

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

6. The system of claim 1 or 2, wherein the O1 data includes FCAPS (Fault, Configuration, Accounting, Performance, Security) data.

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

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

9. 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; 3. The system according to claim 1 or 2.

10. 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.

3. The system according to claim 1 or 2.

11. 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 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; 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; Including, the at least one of the acquired O1 data and the acquired O2 data includes RAN sharing related FCAPS (Fault, Configuration, Accounting, Performance, Security) data; The method, wherein the policy is a policy for O-Cloud resource management and service level agreement (SLA) guarantee for RAN sharing.

12. 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 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; 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; Including, 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 method, wherein the policy is a policy for recovery or root cause analysis of performance degradation or failure of an O-Cloud or O-Cloud infrastructure network element.

13. 13. The method of claim 11 or 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 11 or 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 11 or 12, wherein the O2 data includes node-level or O-Cloud-level O-Cloud inventory and telemetry data.

16. 13. The method of claim 11 or 12, wherein the O1 data comprises FCAPS (Fault, Configuration, Accounting, Performance, Security) data.

17. At least one non-transitory computer-readable storage medium having 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: 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 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; 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; Including, the at least one of the acquired O1 data and the acquired O2 data includes RAN sharing related FCAPS (Fault, Configuration, Accounting, Performance, Security) data; At least one non-transitory computer-readable storage medium, wherein the policy is a policy for O-Cloud resource management and service level agreement (SLA) guarantees for RAN sharing.

18. At least one non-transitory computer-readable recording medium having 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: 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 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; 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; Including, 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; At least one non-transitory computer-readable storage medium, wherein the policy is a policy for recovery or root cause analysis of performance degradation or failure of an O-Cloud or O-Cloud infrastructure network element.

19. 19. At least one non-transitory computer-readable storage medium according to claim 17 or 18, 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.

20. 19. At least one non-transitory computer-readable storage medium according to claim 17 or 18, wherein the method further comprises obtaining, by the rApp, feedback from the O-Cloud platform or the VNF and evaluating the policy.

21. 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; At least one non-transitory computer-readable storage medium according to claim 17 or 18.

Images