NRT RIC Architecture Supporting FCAPS and Cloud Orchestration

Abstract

A method executed by a non-real-time (NRT) radio access network (RAN) intelligent controller (RIC) within a service management and orchestration (SMO) framework of an Open RAN (O-RAN) network includes obtaining, by the NRT RIC, fault, configuration, accounting, performance, and security (FCAPS) related information from at least one network element (NE) in the O-RAN network via an O1 connection, and implementing, by the NRT RIC, for at least one NE, at least one first FCAPS related operation corresponding to the FCAPS related information via the O1 connection, wherein the O1 connection includes an interface between at least one NE and an O1 termination of the NRT RIC.

Description

Technical Field

[0001] [Cross - Reference to Related Applications] This application claims priority based on Indian Patent Application No. 202241058574 filed with the Indian Patent Office on October 13, 2022, and the entire disclosure thereof is incorporated herein by reference.

[0002] [Technical Field] Apparatuses and methods consistent with examples of the present disclosure relate to implementing policies for network elements.

Background Art

[0003] A radio access network (RAN) is an important component in a communication system that connects end - user devices (or user equipment) to other parts of the network. The RAN includes a combination of various network elements (NEs) that connect end - user devices to the core network. Conventionally, the hardware and / or software of a particular RAN was vendor - specific.

[0004] With the emergence of Open RAN (O-RAN) technology, multiple vendors can provide hardware and / or software to a communication system. For this purpose, O-RAN decomposes RAN functions into a Centralized Unit (CU), a Distributed Unit (DU), and a Radio Unit (RU). The CU is a logical node for hosting RAN sub-layers of Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and / or Packet Data Convergence Protocol (PDCP). The DU is a logical node for hosting RAN sub-layers of Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY). The RU is a physical node that converts radio signals from an antenna into digital signals that can be transmitted to the DU over the fronthaul. Since these entities have open protocols and interfaces between them, they can be developed by different vendors.

[0005] FIG. 1 is a diagram of an O-RAN architecture in the related art, FIG. 2 is a diagram in terms of the functional perspective of a Service Management and Orchestration (SMO) framework having a Non-Real-Time (NRT) RAN Intelligent Controller (RIC) architecture in the related art, and FIG. 3 is a diagram in terms of the service perspective of an SMO framework having an NRT RIC in the related art. Referring to FIGS. 1 to 3, the RAN functions in the O-RAN architecture are controlled and optimized by the RIC. The RIC is a software-defined component that implements modular applications to achieve the multi-vendor operability required in the O-RAN system and to automate and optimize RAN operations. The RIC is divided into two types: Non-Real-Time RIC (NRT RIC) and Near-Real-Time RIC (nRT RIC).

[0006] The NRT RIC is a control point for non-real-time control loops and operates within the SMO framework on a time scale longer than 1 second. Its functions are implemented through modular applications called rApps (rApp 1, …, rApp N in FIGS. 1 to 3), and include providing policy-based guidance and enrichment across the A1 interface, which is an interface enabling communication between the NRT RIC and the nRT RIC, performing data analytics, artificial intelligence / machine learning (AI / ML) training and inference for RAN optimization, and / or recommending configuration management actions on the O1 interface, which is an interface connecting the SMO to RAN management elements (e.g., nRT RIC, O-RAN Centralized Unit (O-CU), O-RAN Distributed Unit (O-DU), etc.).

[0007] The nRT RIC operates on time scales between 10 milliseconds and 1 second and connects via the E2 interface to the O-DU, the O-CU (which is decomposed into the O-CU control plane (O-CU-CP) and the O-CU user plane (O-CU-UP)), and the "open evolved NodeB" (O-eNB). The nRT RIC uses the E2 interface to control the underlying RAN elements (E2 nodes / network functions (NFs)) on a near-real-time control loop. The nRT RIC monitors, suspends / stops, overrides, and controls the E2 nodes (O-CU, O-DU, and O-eNB) via policies. For example, the nRT sets policy parameters on the functions activated in the E2 nodes. Further, the nRT RIC hosts xApps for implementing functions such as quality of service (QoS) optimization, mobility optimization, slicing optimization, interference mitigation, load balancing, security, etc. Two types of RICs cooperate to optimize O-RAN. For example, the NRT RIC provides the policies, data, and artificial intelligence (AI) / machine learning (ML) models enabled and used by the nRT RIC for RAN optimization on the A1 interface, and the nRT returns policy feedback (i.e., how the policies set by the NRT RIC work).

[0008] The SMO framework in which the NRT RIC is located manages and coordinates the RAN elements. Specifically, the SMO manages and coordinates what is represented as the O-RAN cloud (O-Cloud). The O-Cloud is a set of physical RAN nodes that host the RIC, the O-CU, and the O-DU, support software components (e.g., operating systems and runtime environments), and the SMO itself. In other words, the SMO manages the O-Cloud from within. The O2 interface is the interface between the SMO and the O-Cloud in which it resides. The SMO provides infrastructure management services (IMS) and deployment management services (DMS) via the O2 interface.

SUMMARY OF THE INVENTION

PROBLEMS TO BE SOLVED BY THE INVENTION

[0009] In related art, NRT RIC cannot be deployed independently without the SMO framework. As shown in FIG. 2, only fault, configuration, accounting, performance, and security (FCAPS) can be supported through the SMO internal interface. There is no O1 termination, or direct O1 connection from the NRT RIC framework for FCAPS operations to the network element (NE). Further, in related art, NRT RIC cannot be deployed independently without the SMO framework. As shown in FIG. 2, only O-Cloud management and orchestration can be supported through the SMO internal interface. There is no O2 termination, or direct O2 connection from the NRT RIC framework to the cloud infrastructure hosting the NE. In many cases, this leads to unnecessary platform implementation complexity and performance overhead, creating an entry barrier for new market players.

MEANS FOR SOLVING THE PROBLEMS

[0010] According to an embodiment, a system and method are provided for implementing a policy for a network element (NE).

[0011] According to one aspect of the present disclosure, a method executed by a non-real-time (NRT) radio access network (RAN) intelligent controller (RIC) within a service management and orchestration (SMO) framework of an open RAN (O-RAN) network includes obtaining, by the NRT RIC, fault, configuration, accounting, performance, and security (FCAPS) related information from at least one network element (NE) in the O-RAN network via an O1 connection; and implementing, by the NRT RIC, at least one first FCAPS related operation corresponding to the FCAPS related information for at least one NE via the O1 connection, wherein the O1 connection includes an interface between the at least one NE and the O1 termination of the NRT RIC.

[0012] According to one aspect of the present disclosure, a system implemented in a communication network includes a memory storing instructions; and a processor configured to execute the instructions to obtain, by a non-real-time (NRT) radio access network (RAN) intelligent controller (RIC) within an SMO framework of an O-RAN network, FCAPS related information from at least one network element (NE) connected to the O-RAN network via an O1 connection; and implement, by the NRT RIC, at least one first FCAPS related operation corresponding to the FCAPS related information for at least one NE via the O1 connection, wherein the O1 connection includes an interface between the at least one NE and the O1 termination of the NRT RIC.

[0013] According to one aspect of the present disclosure, when a non-transitory computer-readable storage medium is executed by at least one processor, at least one NE connected to the O-RAN network obtains FCAPS-related information via an O1 connection from the NRT RIC within the SMO framework of the O-RAN network, and the NRT RIC implements at least one first FCAPS-related operation corresponding to the FCAPS-related information for at least one NE via the O1 connection, and the instructions for causing the at least one processor to execute may be stored, and the O1 connection includes an interface between the O1 terminations of at least one NE and the NRT RIC.

[0014] Additional aspects are presented in part in the following description, become apparent in part from the description, or may be realized by the implementation of the presented embodiments of the disclosure.

Brief Description of the Drawings

[0015] The features, advantages, and significance of the exemplary embodiments of the disclosure are described below with reference to the accompanying drawings in which like reference numerals represent like elements.

[0016] FIG. 1 is a diagram of an Open Radio Access Network (O-RAN) architecture according to the related art.

[0017] FIG. 2 is a diagram in terms of the functional perspective of an SMO (Service Management and Orchestration) framework having a non-real-time (NRT) RAN Intelligent Controller (RIC) architecture according to the related art.

[0018] FIG. 3 is a diagram in terms of the service perspective of an SMO framework having an NRT RIC in the related art according to the related art.

[0019] FIG. 4 is a diagram of an O-RAN architecture according to one embodiment.

[0020] Figure 5 is a diagram of an O-RAN architecture according to an embodiment.

[0021] Figure 6 is a diagram of an O-RAN architecture according to an embodiment.

[0022] Figure 7 is a flowchart of policy implementation with at least one network element (NE) according to an embodiment.

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

[0024] Figure 9 is a diagram of an example of components of a device according to an embodiment. **DETAILED DESCRIPTION OF THE INVENTION**

[0025] The following detailed description of the embodiments refers to the accompanying drawings. The same reference numerals in different figures may identify the same or similar elements.

[0026] The foregoing disclosure provides illustrations and descriptions, but is not intended to be exhaustive or to limit implementations to the exact forms disclosed. Changes and modifications are possible in light of the foregoing disclosure or may be obtained from practice of the implementations. Further, one or more features or components of one embodiment may be integrated with or combined with one or more features of other embodiments (or one or more features of other embodiments). Additionally, in the flowcharts and operation descriptions provided below, one or more operations may be omitted, one or more operations may be added, one or more operations may be executed simultaneously (at least in part), and the order of one or more operations may be interchanged.

[0027] It will become apparent that the systems and / or methods described herein may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual special control hardware or software code used to implement these systems and / or methods is not a limitation of the implementation. For this reason, 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 may be designed to implement the systems and / or methods based on the description herein.

[0028] Even if certain combinations of features are recited in the claims and / or disclosed in the specification, these combinations are not intended to limit the disclosure of possible implementations. In fact, many of these features may be combined in different ways than specifically recited in the claims and / or specifically disclosed in the specification. Each of the dependent claims listed below may depend directly on only one claim, but the disclosure of possible implementations includes each dependent claim in combination with all other claims in the claim group.

[0029] Any element, act, or instruction used herein should not be construed as important or essential unless explicitly stated. Also, as used herein, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more". When only one item is intended, the term "one" or a similar term is used. Also, as used herein, the terms "has", "have", "having", "include", "including", etc. are intended to be open-ended terms. Further, the phrase "based on" is intended to mean "at least in part, based on" unless explicitly stated otherwise. Further, expressions such as "at least one of A and B" or "at least one of A or B" are understood to include only A, only B, or both A and B.

[0030] Embodiments provide a system, method, network, and device that enable a non-real-time (NRT) radio access network (RAN) intelligent controller (RIC) to operate independently of service management and orchestration (SMO) operations, administration, and maintenance (OAM) functions and support fault, configuration, accounting, performance, and security (FCAPS) operations via a direct O1 connection to a network element (NE). This significantly reduces the complexity of the platform and the performance overhead while reducing or removing the barriers to entry for new market players. According to embodiments, an option is provided to the operator to deploy a lightweight NRT RIC without SMO infrastructure or with a lighter SMO implementation for capital expenditure (CAPEX) reduction. The SMO OAM functions are provided with third-party rApps in the NRT RIC, with diverse vendor and solution choices and potentially advanced artificial intelligence (AI) / machine learning (ML) techniques. Further, smaller vendors or new market players may benefit by reducing or removing the barriers to entry from the implementation costs of legacy SMO functions. The efforts for application programming interface (API) implementation, integration, and interoperability testing from integrating the NRT RIC framework into an existing SMO framework are also significantly reduced for the removal of dependencies on existing SMO OAM and O1-related functions.

[0031] Embodiments provide a system, method, network, and device in which the NRT RIC operates independently of SMO Open RAN (O-RAN) Cloud (O-Cloud) related functions and enables support for O-Cloud management, orchestration, and workflow management functions via a direct O2 connection to the NE. This significantly reduces the complexity of the platform and the performance overhead while reducing or removing the barriers to entry for new market players. According to an embodiment, an option is provided to the operator to deploy a lightweight NRT RIC without SMO infrastructure or with a lighter SMO implementation for CAPEX reduction. Conventional SMO O-Cloud management and orchestration functions are provided with third-party rApps in the NRT RIC, which involve diverse vendor and solution selections and potentially advanced AI / ML technologies. Further, small vendors or new market players may benefit by reducing or removing the barriers to entry from the implementation costs of legacy SMO functions. The efforts for API implementation, integration, and interoperability testing from integrating the NRT RIC framework into an existing SMO framework are also significantly reduced for removing the dependencies on existing SMO cloud and O2 related functions.

[0032] The O1 interface may represent an interface that connects the SMO to RAN managed elements (e.g., near real-time (nRT) RIC, O-RAN Centralized Unit (O-CU), O-RAN Distributed Unit (O-DU), etc.) or NEs external to the SMO. The O2 interface may represent an interface between the SMO and the O-Cloud in which it resides, or an interface between the SMO and an external O-Cloud infrastructure. Through the O2 interface, the SMO provides Infrastructure Management Service (IMS) and Deployment Management Service (DMS).

[0033] Thus, a system and method are provided that include operations that may be performed by a NRT RIC within the SMO framework of an O-RAN network. The operations include obtaining, by the NRT RIC, at least one FCAPS-related data / information corresponding to FCAPS operations for at least one NE connected to the O-RAN network, and implementing, by the NRT RIC, for at least one NE, at least one first FCAPS-related operation corresponding to an OAM function via an O1 connection. The O1 connection may include an interface between at least one NE and an O1 termination of the NRT RIC. The O1 termination may be within the NRT RIC framework of the NRT RIC. The operations may further include obtaining, by the NRT RIC, at least one second data / information corresponding to an O-Cloud function, and implementing, by the NRT RIC, via an O2 connection, at least one second cloud orchestration and management operation corresponding to the O-Cloud function. The O2 connection may include an interface between the O-Cloud infrastructure and an O2 termination of the NRT RIC. The O2 termination may be within the NRT RIC framework of the NRT RIC. The NRT RIC may include a policy manager configured to implement at least one first policy. The NRT RIC may include a NRT RIC framework separated from the policy manager.

[0034] FIG. 4 is a diagram of an O-RAN architecture 400 according to one embodiment. The O-RAN architecture 400 may include a SMO 402, an external data access 404, an O-cloud NE 406, other NEs 407, an element management system (EMS) / observability framework (OBF) module 408, and an accounting module 410. The SMO 402 may include a NRT RIC 412 that includes a plurality of rApps 414 (e.g., rApp1, …, rAppN), an R1 interface 415, and an NRT RIC framework 416, a fault management (FM) / performance management (PM) module 418, a cloud management as a service (CMaaS) module 420, and other SMO functions 422 understood by those skilled in the art from the disclosure herein. The NRT RIC 412 may be configured to access an external data access 404 that includes a core network 430, an inventory database 432, a geolocation database 434, an external AI / ML / autonomous network (AN) engine 436, and a planning database 438. The NRT RIC framework 416 may include a policy manager 440, a resource policy 442, an R1 termination 444, an OAM component 446, an O1 termination 448, a cloud orchestration module 450, and an O2 termination 452.

[0035] As shown in FIG. 4, the NRT RIC 412 may implement an OAM function 446 and an O1 termination 448 for FCAPS operations with the NE. In one embodiment, the OAM function and the O1 termination 448 in the SMO 402 may be implemented within the NRT RIC framework 416 to support FCAPS operations. The NRT RIC 412 may be deployed independently without the SMO infrastructure 402. The OAM and FCAPS functions may be supported by the OAM component 446 in the NRT RIC framework 416, or may be provided by an rApp 414 with a third-party implementation. In one embodiment, the SMO 402 and the NRT RIC 412 may be deployed together and may cooperate to support FCAPS operations with the NE together.

[0036] In one embodiment, the OAM function may be implemented as a native implementation in the NRT RIC framework 416 by the NRT RIC 412 to provide support for the O-RAN network function FCAPS via the O1 termination 448. The following FCAPS functions defined in the O1 specification are examples of functions across the O1 interface: PM, FM, configuration management (CM), file management, communication surveillance (e.g., heartbeat), trace, physical network function (PNF) discovery, PNF software management, etc. The OAM component 446 may operate independently to support full FCAPS operations without support from a third-party rApp and interaction with a third-party rApp. The OAM component 446 may operate in cooperation with the rApp 414 to deliver the same or different FCAPS services.

[0037] rApp414 may provide the O-RAN network function FCAPS independently or partially via the O1 termination 448. The R1 interface 415 may include a set of services, hereinafter referred to as R1 services, that facilitate the interaction between rApp414 and the NRT RIC framework 416. rApp414 may support FCAPS operations through the O1-related services provided by the R1 interface 415. If rApp414 provides full support for the FCAPS function, the native FCAPS implementation in the NRT RIC framework 416 may be excluded.

[0038] The native OAM implementations in rApp414 and the NRT RIC framework 416 may operate together to provide a single FCAPS service via the O1 termination 448. In this case, the functions and responsibilities may be separated and negotiated between rApp414 and the native OAM at the service registration stage. rApp414 may support or improve the native OAM operations by providing policy guidance, or rApp414 may directly execute FCAPS operations in parallel with the native OAM. The NRT RIC412 may provide a conflict management service to resolve potential configuration and control conflicts between rApp414 and the native OAM functions of rApp414 and the NRT RIC412.

[0039] FIG. 5 is a diagram of an O-RAN architecture 500 according to one embodiment. The architecture 500 of FIG. 5 is similar to the architecture 400 of FIG. 4, but the NRT RIC 502 may include an NRT RIC framework 504 that implements a solution automation studio configured to automate actions on southbound interfaces (e.g., O1 / O2) by using a cross-link interface (CLI) or a simple script. The framework 504 may prepare a default response based on the received FCAPS information in the architecture 500. The NRT RIC 502 may utilize this framework 504 to automate and provide a faster response to southbound interfaces (i.e., interfaces facing south or downward of the NRT RIC). The default policy of the framework 504 may be updated by the NRT RIC 502 based on an AI / ML learning process or by direct configuration by the rApp 414.

[0040] In the embodiment shown in FIG. 5, the NRT RIC framework 504 functions, including the OAM / FCAPS function and the O1 termination, may be implemented and integrated in an automation studio and orchestrator 506 that provides support for O-RAN network function FCAPS via the O1 interface. The R1 interface 415 may include a set of services, hereinafter referred to as R1 services, that facilitate the interaction between the rApp 414 and the automation studio and orchestrator 506. Service / responsibility negotiation and conflict management functions may be provided by the automation studio and orchestrator 506 for service coordination between the rApp 414 and the native OAM implementation of the platform.

[0041] FIG. 6 is a diagram of an O-RAN architecture 600 according to one embodiment. The architecture 600 of FIG. 6 is similar to the architecture 500 of FIG. 5, and the NRT RIC 602 further includes a separate policy manager 604 and a communication manager 606. The R1 interface 415 is configured to provide an interaction between the rApp 414 and the communication manager 606. The policy manager 604 may provide more default policies that may be executed on top of the automation studio and the orchestrator 506. The communication manager 606 may be configured to manage communication between different modules. The R1 interface 415 may include a set of R1 services that facilitate the interaction between the rApp 414 and the policy manager 604. For service coordination between the rApp 414 and the native OAM implementation of the platform, a service / responsibility negotiation and conflict management function may be provided by the policy manager 604.

[0042] In the embodiments illustrated in FIGS. 4-6, rApp 414 may access data from a network interface to a core network through newly defined core-related services provided by R1 interface 415. When rApp 414 provides support for core control functions, the functions and responsibilities may be separated and negotiated between rApp 414 and the native control functions in the core network. rApp 414 may support or improve native core control operations by providing policy guidance, or rApp 414 may directly configure or control the core network in parallel with the native control functions. Conflict management to resolve potential configuration and control conflicts between rApp and the native control functions may be implemented in NRT RICs 412, 502, and 602. Priorities and privileges may be assigned by an operator or vendor to assign priorities to configuration and control commands from different resources to guide the conflict management process.

[0043] Returning to FIG. 4, the NRT RIC 412 may implement the cloud orchestration function of the cloud orchestration module 450 and the O2 termination for O-Cloud management, orchestration, and workflow management. The cloud orchestration function and the O2 termination 452 of the cloud orchestration module 450 may be implemented within the NRT RIC framework 416. The NRT RIC 412 may be deployed independently without the conventional SMO infrastructure. The cloud orchestration function of the cloud orchestration module 450 may be supported in the NRT RIC framework 416 or provided by the rApp 414 with a third-party implementation. In one embodiment, the SMO 402 and the NRT RIC 412 may be deployed together and may cooperate to support the cloud orchestration function together. Further, if the orchestration function is outside the NRT RIC 412, the NRT RIC 412 may provide policies for configuring the orchestration.

[0044] The cloud orchestration function of the cloud orchestration module 450 may be implemented by the NRT RIC platform vendor as a native function in the NRT RIC framework 416 that may operate independently without support from and interaction with a third-party rApp, or may operate in cooperation with the rApp to deliver the same or different O-Cloud management and orchestration services.

[0045] In some embodiments, rApp414 may provide O-Cloud management and orchestration functions, either independently or partially, through the O2-related services provided by the R1 interface 415. If rApp414 provides full support for the O-Cloud management and orchestration functions of the cloud orchestration module 450, the native cloud orchestration module 450 implementation in the NRT RIC framework 416 may be excluded.

[0046] In some embodiments, the cloud orchestration module 450 in rApp414 and the NRT RIC framework 416 may operate together to provide a single O-Cloud management and orchestration service via the O2 termination 452. In this case, the functions and responsibilities may be separated and negotiated between rApp414 and the cloud orchestration module 450 at the service registration stage. rApp414 may support or improve the cloud orchestration module 450 operations by providing policy guidance, or rApp414 may directly configure and control the O-Cloud infrastructure in parallel with the cloud orchestration module 450. Conflict management may be required in the NRT RIC412 to resolve potential configuration and control conflicts between rApp414 and the cloud orchestration module 450. Priorities and privileges may be assigned by the operator or vendor to assign priorities to configuration and control commands from different resources to guide the conflict management process.

[0047] Returning to FIG. 5, the NRT RIC framework 504 may implement an automation studio and orchestrator 506 that automates actions on southbound interfaces (e.g., O1 / O2) by using a CLI or a simple script. The automation studio and orchestrator 506 may prepare default responses based on the received FCAPS information. The NRT RIC 502 may utilize this framework to automate and provide faster responses to southbound interfaces. The default policy of this interface may be updated by the NRT RIC 502 based on AI / ML learning or by direct configuration by the rApp 414. The rApp 414 may support (wholly or in part) O-Cloud management and orchestration operations through the O2-related services provided by the R1 interface 415. For service coordination, service / responsibility negotiation and conflict management functions may be provided by the automation studio and orchestrator 506.

[0048] Returning to FIG. 6, the NRT RIC 602 may use a policy manager 604. The policy manager 604 may provide more default policies that may be executed on top of the automation studio. A communication manager 606 may manage communications between different modules. The NRT RIC framework functions including O-Cloud management and orchestration functions and O2 termination may be implemented and integrated in the policy manager 604. The rApp 414 may support (wholly or in part) O-Cloud management and orchestration operations through the O2-related services provided by the R1 interface 415. Service / responsibility negotiation and conflict management functions may be provided by the policy manager.

[0049] FIG. 7 is a flowchart of policy implementation with at least one NE according to an embodiment. In operation 702, the system may obtain FCAPS-related information from at least one network element (NE) in the O-RAN network via an O1 connection by the NRT RIC. In operation 704, the system may implement at least one first FCAPS-related operation corresponding to the FCAPS-related information for at least one NE via an O1 connection by the NRT RIC. The O1 connection may include an interface between the O1 terminations of at least one NE and the NRT RIC.

[0050] FIG. 8 is a diagram of an example of an environment 800 in which the systems and / or methods described herein may be implemented. As shown in FIG. 8, the environment 800 may include user devices 810, a platform 820, and a network 830. The devices of the environment 800 may be interconnected via a wired connection, a wireless connection, or a combination of wired and wireless connections. In an embodiment, any of the functions and operations described above with reference to FIG. 1 and the like may be performed by any combination of the elements illustrated in FIG. 8.

[0051] The user devices 810 include one or more devices capable of receiving, generating, storing, processing, and / or providing information related to the platform 820. For example, the user devices 810 may include computing devices (e.g., desktop computers, laptop computers, tablet computers, handheld computers, smart speakers, servers, etc.), mobile phones (e.g., smartphones, wireless phones, etc.), wearable devices (e.g., smart glasses or smart watches), or similar devices. In some implementations, the user devices 810 may receive information from the platform 820 and / or transmit information to the platform 820.

[0052] Platform 820 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information. In some implementations, platform 820 may include a cloud server or a group of cloud servers. In some implementations, platform 820 may be designed to be modular so that specific software components may be swapped (in or out) depending on specific needs. Thus, platform 820 may be easily and / or quickly reconfigured for different uses.

[0053] In some implementations, as shown, platform 820 may be hosted in a cloud computing environment 822. Note that the implementations described herein describe platform 820 as being hosted in cloud computing environment 822, but 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.

[0054] Cloud computing environment 822 includes an environment that hosts platform 820. Cloud computing environment 822 may provide services that do not require knowledge of the physical location and configuration of the system and / or device (e.g., user device 810) that hosts platform 820, such as computing, software, data access, storage, etc. As shown, cloud computing environment 822 may include a group of computing resources 824 (collectively referred to as "computing resources 824" and individually referred to as "a computing resource 824").

[0055] Computing resource 824 includes one or more personal computers, a cluster of computing devices, a workstation computer, a server device, or other types of computing and / or communication devices. In some implementations, computing resource 824 may host platform 820. Cloud resources may include computing instances running on computing resource 824, storage devices provided on computing resource 824, data transfer devices provided by computing resource 824, etc. In some implementations, computing resource 824 may communicate with other computing resources 824 via a wired connection, a wireless connection, or a combination of wired and wireless connections.

[0056] As further shown in FIG. 8, computing resource 824 includes 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, one or more hypervisors ("HYP") 824-4, etc.

[0057] Application 824-1 includes one or more software applications that may be provided to user device 810 or accessed by user device 810. Application 824-1 may obviate the need to install and execute software applications on user device 810. For example, application 824-1 may include any other software that can be provided via the software associated with platform 820 and / or cloud computing environment 822. In some implementations, one application 824-1 may send and receive information to and from one or more other applications 824-1 via virtual machine 824-2.

[0058] The virtual machine 824-2 includes a software implementation of a device (e.g., a computer) that executes programs like a physical device. Depending on its use by the virtual machine 824-2 and the degree of correspondence with any real device, the virtual machine 824-2 may be a system virtual machine or a process virtual machine. A system virtual machine may provide a complete system platform that supports the execution of a complete operating system ("OS"). A process virtual machine may execute a single program or support a single process. In some implementations, the virtual machine 824-2 may execute on behalf of a user (e.g., the user device 810) and manage the infrastructure of a cloud computing environment 822 such as data management, synchronization, or long-duration data transfer.

[0059] The virtualized storage 824-3 includes one or more storage systems and / or devices of one or more devices or computing resources 824 that use virtualization technology within the storage system. In some implementations, within the context of a storage system, the types of virtualization may include block virtualization and file virtualization. Block virtualization may represent the abstraction (or separation) of logical storage from physical storage so that the storage system may be accessed without considering the physical storage or heterogeneous structure. The separation may provide flexibility to the storage system administrator when managing storage for end users. File virtualization may remove the dependency between the data accessed at the file level and the location where the files are physically stored. This may enable optimization of storage usage, server consolidation, and / or performance of non-disruptive file migration.

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

[0061] 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, a fiber-optic based network, etc.), and / or a combination of these or other types of networks.

[0062] The number and arrangement of the devices and networks shown in FIG. 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 with different arrangements, compared to those shown in FIG. 8. Further, two or more of the devices shown in FIG. 8 may be implemented within a single device, and a single device shown in FIG. 8 may be implemented as a plurality of distributed devices. Additionally or alternatively, 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.

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

[0064] Bus 910 includes components that enable communication among components of device 900. Processor 920 may be implemented in hardware, firmware, or a combination of hardware and software. 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, processor 920 includes one or more programmable processors for executing functions. Memory 930 includes random access memory (RAM), read-only memory (ROM), and / or other types of dynamic or static storage devices (e.g., flash memory, magnetic memory, and / or optical memory) for storing information and / or instructions for use by processor 920.

[0065] 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, together with the corresponding drive, may include a hard disk (e.g., magnetic disk, optical disk, magneto-optical disk, and / or solid state disk), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, a magnetic tape, and / or other types of non-transitory computer-readable media. The input component 950 includes components that enable the device 900 to receive information via user input (e.g., touch screen display, keyboard, keypad, mouse, button, switch, and / or microphone), etc. Additionally or alternatively, the input component 950 may include sensors for measuring information (e.g., global positioning system (GPS) component, accelerometer, gyroscope, and / or actuator). The output component 960 includes components that provide output information from the device 900 (e.g., display, speaker, and / or one or more light emitting diodes (LEDs)).

[0066] The communication interface 970 includes components such as a transceiver (e.g., transceiver and / or split receiver and transmitter) that enable the device 900 to communicate with other devices via a wired connection, a wireless connection, or a combination of wired and wireless connections, etc. The communication interface 970 enables the device 900 to receive information from other devices and / or provide information to other devices. 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.

[0067] Device 900 may execute one or more of the processes described herein. Device 900 may execute these processes in response to a processor 920 that executes software instructions stored by a non-transitory computer-readable medium such as a memory 930 and / or a storage component 940. The computer-readable medium is defined herein as a non-transitory memory device. The memory device includes a memory space within a single physical storage device or a memory space distributed across multiple physical storage devices.

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

[0069] Additionally or alternatively, instead of software instructions or in combination with software instructions, a wired circuit may be used to execute one or more of the processes described herein. Thus, the implementations described herein are not limited to a particular combination of hardware circuits and software.

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

[0071] In an embodiment, any operation or process of FIGS. 4 to 7 may be implemented by or using any element illustrated in FIGS. 8 and 9. Other embodiments are not limited thereto and may be implemented in various different architectures (e.g., bare metal architecture, any cloud-based architecture or deployment architectures such as Kubernetes, Docker, OpenStack, etc.).

[0072] The above disclosure provides examples and descriptions, but is not intended to be exhaustive or to limit implementations to the exact forms disclosed. Changes and modifications are possible in light of the above disclosure or may be obtained from the practice of the implementation.

[0073] Some embodiments may relate to a system, method, and / or computer-readable medium at any possible level of technical detail of integration. Further, one or more of the above-described components may be stored on a computer-readable medium and implemented as instructions executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include a computer-readable non-transitory storage medium (or medium) storing computer-readable program instructions for causing a processor to execute operations.

[0074] 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 is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD), memory stick, floppy disk, punch cards, mechanically encoded devices such as raised structures in grooves in which instructions are recorded, and any suitable combination thereof. As used herein, a computer-readable storage medium is not construed to be a transitory signal per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., optical pulses passing through an optical fiber cable), or electrical signals transmitted through a wire.

[0075] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to respective computing / processing devices, or can be downloaded from an external computer or an 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 comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions for storage in a computer-readable storage medium within each respective computing / processing device.

[0076] The computer-readable program code / instructions for performing the operation may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for an integrated circuit, or source code or object code written in any combination of one or more programming languages including 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 as a stand-alone software package, partially on the user's computer, partially on the user's computer, 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 the connection may be made to an external computer (e.g., through the Internet using an Internet service provider). In some embodiments, for example, an electronic circuit including a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA) may execute the computer-readable program instructions by utilizing the state information of the computer-readable program instructions to personalize the electronic circuit for performing the aspect or operation.

[0077] These computer-readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram (one or more blocks). These computer-readable program instructions may be stored in a computer-readable storage medium that, when containing instructions that implement aspects of the functions / acts specified in the flowchart and / or block diagram (one or more blocks), causes a computer, programmable data processing apparatus, and / or other device to function in a particular manner.

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

[0079] The flowchart and block diagrams shown illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media according to various embodiments. Here, each block in the flowchart or block diagram may represent a microservice, module, segment, or portion of instructions that include one or more executable instructions for implementing a particular logical function. The methods, computer systems, and computer-readable media may include additional blocks, fewer blocks, different blocks, or differently arranged blocks compared to those shown in the figures. In some alternative implementations, the functions shown in the blocks may occur out of the order shown in the figures. For example, two blocks shown in succession may actually be executed simultaneously or substantially simultaneously, depending on the functions involved, or the blocks may be executed in the reverse order. Note that each block of the illustrations of the block diagrams and / or flowcharts, and combinations of blocks in the illustrations of the block diagrams and / or flowcharts, may be implemented by a system based on dedicated hardware for performing a particular function or action, or by a combination of dedicated hardware and computer instructions.

[0080] It is clear that the systems and / or methods described herein may be implemented in different forms of hardware, firmware, or a combination of hardware and software. It is understood that the actual dedicated control hardware or software code used to implement these systems and / or methods does not limit the implementation. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. This is understood to mean that software and hardware may be designed based on the description herein to implement the systems and / or methods.

Claims

1. A method executed by a non-real-time (NRT) radio access network (RAN) intelligent controller (RIC) within a service management and orchestration (SMO) framework of an Open RAN (O-RAN) network, comprising: obtaining, by the NRT RIC, fault, configuration, accounting, performance, and security (FCAPS) related information from at least one network element (NE) in the O-RAN network via an O1 connection; implementing, by the NRT RIC, at least one first FCAPS related operation corresponding to the FCAPS related information for the at least one NE via the O1 connection; and wherein the O1 connection comprises an interface between the at least one NE and an O1 termination of the NRT RIC.

2. The method according to claim 1, wherein the O1 termination is within an NRT RIC framework of the NRT RIC.

3. obtaining, by the NRT RIC, at least one second FCAPS related operation corresponding to an O-RAN cloud (O-Cloud) function; implementing, by the NRT RIC, the at least one second FCAPS related operation corresponding to the O-Cloud function via an O2 connection; The method according to claim 1, further comprising.

4. The method according to claim 3, wherein the O2 connection comprises an interface between an O-Cloud infrastructure and an O2 termination of the NRT RIC.

5. The method according to claim 4, wherein the O2 termination is within an NRT RIC framework of the NRT RIC.

6. The method according to claim 1, wherein the NRT RIC comprises a policy manager configured to implement the at least one first FCAPS related operation.

7. The method according to claim 6, wherein the NRT RIC comprises an NRT RIC framework separated from the policy manager.

8. A system implemented in a communication network, comprising: a memory storing instructions; By a non-real-time (NRT) Radio Access Network (RAN) Intelligent Controller (RIC) within a Service Management and Orchestration (SMO) framework of an Open RAN (O-RAN) network, obtaining, via an O1 connection, fault, configuration, accounting, performance, and security (FCAPS) related information from at least one network element (NE) connected to the O-RAN network, by the NRT RIC, implementing, via the O1 connection, at least one first FCAPS related operation corresponding to the FCAPS related information for the at least one NE, a processor configured to execute the instructions so as to perform, comprising, The O1 connection comprises an interface between the at least one NE and an O1 termination of the NRT RIC. A system. **Claim 9** The O1 termination is within an NRT RIC framework of the NRT RIC. The system according to claim 8. **Claim 10** The processor is by the NRT RIC, obtaining at least one second FCAPS related data corresponding to an O-RAN Cloud (O-Cloud) function, by the NRT RIC, implementing, via an O2 connection, the at least one second FCAPS related operation corresponding to the O-Cloud function, The system according to claim 8, further configured to execute the instructions so as to perform. **Claim 11** The O2 connection comprises an interface between an O-Cloud infrastructure and an O2 termination of the NRT RIC. The system according to claim 10. **Claim 12** The O2 termination is within an NRT RIC framework of the NRT RIC. The system according to claim 11. **Claim 13** The NRT RIC comprises a policy manager configured to implement the at least one first FCAPS related operation. The system according to claim 8. **Claim 14** The NRT RIC comprises an NRT RIC framework separated from the policy manager. The system according to claim 13. **Claim 15** When executed by at least one processor, At least one first fault, configuration, accounting, performance, and security (FCAPS) related operation is obtained via an O1 connection from at least one network element (NE) in the O-RAN network by a non-real-time (NRT) radio access network (RAN) intelligent controller (RIC) within a service management and orchestration (SMO) framework of the open RAN (O-RAN) network. At least one first FCAPS related operation corresponding to the FCAPS related information is implemented via the O1 connection for the at least one NE by the NRT RIC. Stores instructions for causing the at least one processor to execute. The O1 connection is a non-transitory computer-readable storage medium comprising an interface between the at least one NE and an O1 termination of the NRT RIC. **Claim 16** The O1 termination is the storage medium according to claim 15, which is within an NRT RIC framework of the NRT RIC. **Claim 17** When executed, the instructions Cause the NRT RIC to obtain at least one second FCAPS related operation corresponding to an O-RAN cloud (O-Cloud) function. Cause the NRT RIC to implement the at least one second FCAPS related operation corresponding to the O-Cloud function via an O2 connection. The storage medium according to claim 15, which further causes the at least one processor to execute. **Claim 18** The O2 connection is the storage medium according to claim 17, which comprises an interface between an O-Cloud infrastructure and an O2 termination of the NRT RIC. **Claim 19** The O2 termination is the storage medium according to claim 18, which is within an NRT RIC framework of the NRT RIC. **Claim 20** The NRT RIC of the storage medium according to claim 15 comprises a policy manager configured to implement the at least one first FCAPS related operation.

Images