NRT RIC architecture supporting FCAPS and cloud orchestration
By achieving O1 connection in the NRT RIC in the SMO framework of the O-RAN network, the problem that NRT RIC cannot deploy independently is solved, the platform complexity and performance overhead are reduced, and the entry of new market participants has been promoted.
Patent Information
- Application Number
- CN202280096978.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2022-10-13
- Filing Date
- 2022-12-01
- Publication Date
- 2025-01-21
AI Technical Summary
In the prior art, non-real-time (RIC) cannot be deployed independently without a service management and orchestration (SMO) framework, resulting in platform implementation complexity and performance overhead and poses a barrier to entry of new market participants.
By implementing O1 connectivity in the NRT RIC within the SMO framework of the O-RAN network, the NRT RIC is allowed to independently obtain and perform fault, configuration, accounting, performance and security (FCAPS) operations related to the network element (NE).
It reduces platform complexity and performance overhead, reduces or eliminates entry barriers for new market participants, allows operators to deploy lightweight NRT RIC without SMO infrastructure, and reduces capital expenditures.
Smart Images

Figure CN119343945A_ABST
Abstract
Description
[0001] CROSS-REFERENCE TO RELATED APPLICATIONS
[0002] This application is based on and claims priority from Indian Patent Application No. 202241058574 filed in the Indian Patent Office on October 13, 2022, the entire contents of which are incorporated herein by reference. Technical Field
[0003] Apparatus and methods consistent with example embodiments of the present disclosure relate to implementing policies of network elements. Background Art
[0004] The Radio Access Network (RAN) is an important component in a telecommunication system as it connects the end-user equipment (or user equipment) to the rest of the network. The RAN comprises a combination of various network elements (NEs) that connect the end-user equipment to the core network. Traditionally, the hardware and / or software of a particular RAN is vendor specific.
[0005] Open RAN (O-RAN) technology has emerged to enable multiple vendors to provide hardware and / or software to telecommunications systems. To this end, O-RAN decomposes RAN functions into centralized units (CU), distributed units (DU), and radio units (RU). CU is a logical node for hosting the radio resource control (RRC), service data adaptation protocol (SDAP), and / or packet data convergence protocol (PDCP) sublayers of the RAN. DU is a logical node for hosting the radio link control (RLC), media access control (MAC), and physical (PHY) sublayers of the RAN. RU is a physical node that converts the radio signal from the antenna into a digital signal, which can be sent to the DU via fronthaul. Because there are open protocols and interfaces between these entities, they can be developed by different vendors.
[0006] Figure 1 This is a diagram of the O-RAN architecture of the prior art. Figure 2 is a diagram of a prior art service management and orchestration (SMO) framework with a non-real-time (NRT) RAN intelligent controller (RIC) architecture in a functional view; Figure 3 is a diagram of a prior art SMO framework with NRT RIC in the service view. Figures 1 to 3 , RAN functions in the O-RAN architecture are controlled and optimized by RIC. RIC is a software-defined component that is used to implement modular applications to facilitate multi-vendor operability required in O-RAN systems and to automate and optimize RAN operations. RIC is divided into two types: NRT RIC and near real-time RIC (nRTRIC).
[0007] NRT-RIC is the control point of the non-real-time control loop and operates on a time scale greater than 1 second within the SMO framework. Its functionality is provided by a so-called rApp ( Figures 1 to 3 , rApp N) in the RAN, and includes: providing policy-based guidance and enrichment through an A1 interface, which is an interface for realizing communication between NRT-RIC and nRT RIC; performing data analysis; artificial intelligence / machine learning (AI / ML) training and reasoning for RAN optimization; and / or recommending configuration management actions through an O1 interface, which is an interface for connecting the SMO to RAN management elements (e.g., nRT RIC, O-RAN centralized unit (O-CU), O-RAN distributed unit (O-DU), etc.).
[0008] The nRT RIC operates on a time scale between 10 milliseconds and 1 second and is connected to the O-DU, O-CU (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) via the E2 interface. The nRT RIC uses the E2 interface to control the underlying RAN elements (E2 nodes / network functions (NFs)) in 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 for the activation functions of the E2 nodes. In addition, the nRT RIC hosts xApps to implement functions such as quality of service (QoS) optimization, mobility optimization, slicing optimization, interference mitigation, load balancing, security, etc. These two types of RICs work together to optimize O-RAN. For example, NRT-RIC provides policies, data, and artificial intelligence (AI) / machine learning (ML) models enforced and used by nRTRIC for RAN optimization through the A1 interface, and nRT returns policy feedback (i.e., how the policies set by NRT-RIC are working).
[0009] The SMO framework where the NRT-RIC resides manages and orchestrates the RAN elements. Specifically, the SMO manages and orchestrates the so-called 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 system and runtime environment), and the SMO itself. In other words, the SMO manages the O-Cloud from the inside. The O2 interface is the interface between the SMO and the O-Cloud where it resides. Through the O2 interface, the SMO provides infrastructure management services (IMS) and deployment management services (DMS).
[0010] In the prior art, NRT RIC cannot be deployed independently without the SMO framework, but can only be deployed through Figure 2 The SMO internal interface shown in FIG. 1 is used to support Fault, Configuration, Charging, Performance, and Security (FCAPS). For FCAPS operation, there is no O1 termination or direct O1 connection from the NRT RIC framework to the network element (NE). In addition, in the prior art, the NRT RIC cannot be deployed independently without the SMO framework, but can only be deployed through the SMO framework. Figure 2 The SMO internal interfaces shown are used to support O-Cloud management and orchestration. 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, and creates barriers to entry for new market players. Summary of the invention
[0011] According to an embodiment, systems and methods for implementing policies for a network element (NE) are provided.
[0012] According to one aspect of the present disclosure, a method performed 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 may include: obtaining fault, configuration, charging, performance, and security (FCAPS) related information from at least one NE in the O-RAN network via an O1 connection through an NRTRIC, and implementing at least one first FCAPS related operation corresponding to the FCAPS related information for at least one NE via the O1 connection through an NRT RIC, 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, a system implemented in a telecommunications network may include a memory storing instructions and a processor, the processor being configured to: execute the instructions to obtain FCAPS-related information from at least one NE connected to the O-RAN network via an O1 connection through an NRT RIC within a SMO framework of the O-RAN network, and implement at least one first FCAPS-related operation corresponding to the FCAPS-related information for at least one NE via the O1 connection through the NRT RIC, wherein the O1 connection includes an interface between the at least one NE and the O1 termination of the NRT RIC.
[0014] According to one aspect of the present disclosure, a non-transitory computer-readable storage medium may store instructions that, when executed by at least one processor, cause the at least one processor to: obtain FCAPS-related information from at least one NE connected to an O-RAN network via an O1 connection through an NRT RIC within a SMO framework of the O-RAN network, and implement at least one first FCAPS-related operation corresponding to the FCAPS-related information for at least one NE via the O1 connection through the NRT RIC, wherein the O1 connection includes an interface between the at least one NE and the O1 termination of the NRT RIC.
[0015] Additional aspects will be set forth in part in the description which follows and, in part, will be apparent from the description, or may be achieved by practice of the presented embodiments of the disclosure. BRIEF DESCRIPTION OF THE DRAWINGS
[0016] The features, advantages and significance of exemplary embodiments of the present disclosure will be described below with reference to the accompanying drawings, in which like symbols represent like elements, and in which:
[0017] Figure 1 is a diagram of an open radio access network (O-RAN) architecture according to the prior art;
[0018] Figure 2 is a diagram of a service management and orchestration (SMO) framework with a non-real-time (NRT) RAN intelligent controller (RIC) architecture in a functional view according to the prior art;
[0019] Figure 3 is a diagram of a prior art SMO framework with NRT RIC in a service view according to the prior art;
[0020] Figure 4 is a diagram of an O-RAN architecture according to an embodiment;
[0021] Figure 5 is a diagram of an O-RAN architecture according to an embodiment;
[0022] Figure 6 is a diagram of an O-RAN architecture according to an embodiment;
[0023] Figure 7 is a flow chart of a policy implementation with at least one network element (NE) according to an embodiment;
[0024] Figure 8 is a diagram of an example environment in which the systems and / or methods described herein may be implemented according to an embodiment; and
[0025] Fig. 9 is a diagram of example components of a device according to an embodiment. DETAILED DESCRIPTION
[0026] The following detailed description of example embodiments refers to the accompanying drawings.The same reference numbers in different drawings may identify the same or similar elements.
[0027] The above disclosure provides illustration and description, but is not intended to be exhaustive or to limit implementation to the disclosed precise form. According to the above disclosure, it is possible to modify and deform, or it is possible to obtain modification and deformation from the practice of implementation. In addition, one or more features or parts of an embodiment may be incorporated into another embodiment (or one or more features of another embodiment) or combined with it. In addition, in the flow chart and the operation description 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 simultaneously (at least in part), and the order of one or more operations may be switched.
[0028] It is obvious that the system and / or method described herein can be implemented with different forms of hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code for implementing these systems and / or methods does not limit these implementations. Therefore, the operation and behavior of the system and / or method are described herein without reference to specific software codes. It should be understood that software and hardware can be designed to implement these systems and / or methods based on the description herein.
[0029] Even though particular 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 ways not specifically recited in the claims and / or disclosed in the specification. Although each dependent claim listed below may directly depend on only one claim, the disclosure of possible implementations includes each dependent claim in combination with every other claim in the claim set.
[0030] Unless explicitly stated, any element, behavior or instruction used in this article should not be interpreted as critical or necessary. In addition, as used in this article, the terms "a" and "an" are intended to include one or more items, and can be used interchangeably with "one or more". If only one item is intended to be represented, the term "one" or similar language is used. In addition, as used in this article, the terms "has", "have", "having", "include", "including", etc. are intended to be open terms. In addition, unless explicitly stated otherwise, the word "based on" means "based at least in part". In addition, statements such as "at least one of [A] and [B]" or "at least one of [A] or [B]" should be understood to include only A, only B, or both A and B.
[0031] Example embodiments provide systems, methods, networks, and devices that allow non-real-time (NRT) radio access network (RAN) intelligent controllers (RICs) to work independently of service management and orchestration (SMO) operations, management, and maintenance (OAM) functions and to support fault, configuration, billing, performance, and security (FCAPS) operations via direct O1 connections to network elements (NEs). This greatly reduces the complexity and performance overhead of the platform while reducing or eliminating barriers to entry for new market participants. According to example embodiments, operators can choose to deploy lightweight NRT RICs without SMO infrastructure, or use lightweight SMO implementations to reduce capital expenditures (CAPEX). SMO OAM functions are provided by third-party rApps in NRT RICs, with a diverse selection of suppliers and solutions, and potentially using advanced artificial intelligence (AI) / machine learning (ML) technologies. In addition, small suppliers or new market participants can also benefit by reducing or eliminating barriers to entry for the implementation costs of traditional SMO functions. Since the dependency on existing SMO OAM and O1-related functions is eliminated, the application programming interface (API) implementation, integration and interoperability testing efforts for integrating the NRT RIC framework with the existing SMO framework are also greatly reduced.
[0032] Example embodiments provide systems, methods, networks, and devices that allow NRT RIC to work independently of SMO open RAN (O-RAN) cloud (O-Cloud) related functions and support O-Cloud management, orchestration, and workflow management functions via direct O2 connections to NEs. This greatly reduces the complexity and performance overhead of the platform while reducing or eliminating barriers to entry for new market participants. According to example embodiments, operators can choose to deploy lightweight NRT RIC without SMO infrastructure, or use lightweight SMO implementations to reduce capital expenditures. Conventional SMO O-Cloud management and orchestration functions are provided by third-party rApps in NRT RIC, with a variety of suppliers and solution options, and potentially using advanced AI / ML technologies. In addition, small suppliers or new market participants can also benefit by reducing or eliminating barriers to entry for the implementation costs of traditional SMO functions. Since the reliance on existing SMO clouds and O2-related functions is eliminated, the API implementation, integration, and interoperability testing work of integrating the NRT RIC framework with the existing SMO framework is also greatly reduced.
[0033] The O1 interface may refer to an interface that connects the SMO to a RAN management element (e.g., near real-time (nRT) RIC, O-RAN centralized unit (O-CU), O-RAN distributed unit (O-DU), etc.) or NE outside the SMO. The O2 interface may refer to an interface between the SMO and the O-Cloud in which it is located, or an interface between the SMO and an external O-Cloud infrastructure. Through the O2 interface, the SMO provides infrastructure management services (IMS) and deployment management services (DMS).
[0034] Therefore, a system and method are provided, which include operations that can be performed by an NRT RIC within an SMO framework of an O-RAN network. The operation may include obtaining, by the NRT RIC, at least one FCAPS-related data / information corresponding to an FCAPS operation of at least one NE connected to the O-RAN network, and implementing, by the NRT RIC, at least one first FCAPS-related operation corresponding to an OAM function for at least one NE 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 in an NRT RIC framework of the NRT RIC. The operation may also include obtaining, by the NRT RIC, at least one second data / information corresponding to an O-Cloud function, and implementing, by the NRT RIC, at least one second cloud orchestration and management operation corresponding to the O-Cloud function via an O2 connection. The O2 connection may include an interface between the O-Cloud infrastructure and the O2 termination of the NRT RIC. The O2 termination may be in an 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 an NRT RIC framework separate from the policy manager.
[0035] Figure 4 400 , which is a diagram of an O-RAN architecture according to an embodiment. The O-RAN architecture 400 may include an SMO 402, external data access 404, an O-Cloud NE 406, other NEs 407, an element management system (EMS) / observability framework (OBF) module 408, and a charging module 410. The SMO 402 may include an NRT RIC 412 (the NRT RIC 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 that can be understood by a person of ordinary skill in the art from the disclosure herein. NRT RIC 412 may be configured to access external data access 404, including core network 430, inventory database 432, geolocation database 434, external AI / ML / autonomous network (AN) engine 436, and planning database 438. NRT RIC framework 416 may include policy manager 440, resource policy 442, R1 termination 444, OAM component 446, O1 termination 448, cloud orchestration module 450, and O2 termination 452.
[0036] like Figure 4As shown, the NRT RIC 412 may implement OAM functionality 446 and O1 termination 448 for FCAPS operations with the NE. In an example embodiment, the OAM functionality and 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 functionality may be supported by the OAM component 446 in the NRT RIC framework 416, or may be provided by the rApp 414 with a third-party implementation. In an example embodiment, the SMO 402 and the NRT RIC 412 may be deployed together, and both may support FCAPS operations with the NE in a collaborative manner.
[0037] In an example embodiment, the OAM functions may be implemented by the NRT RIC 412 as a local implementation in the NRT RIC framework 416 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 on the O1 interface: PM, FM, Configuration Management (CM), File Management, Communication Monitoring (e.g., Heartbeat), Tracing, Physical Network Function (PNF) Discovery, PNF Software Management, etc. The OAM component 446 may operate independently to support full FCAPS operations without support from and interaction with any third-party rApps. The OAM component 446 may operate in conjunction with the rApp 414 to deliver the same or different FCAPS services.
[0038] The rApp 414 may independently or partially provide the O-RAN network function FCAPS via the O1 termination 448. The R1 interface 415 may include a set of services, hereinafter referred to as R1 services, which facilitate the interaction between the rApp 414 and the NRT RIC framework 416. The rApp 414 may support FCAPS operations through the O1-related services provided by the R1 interface 415. If the rApp 414 provides full support for the FCAPS function, the native FCAPS implementation in the NRT RIC framework 416 may be excluded.
[0039] The rApp 414 and the local OAM implementation in 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 the rApp 414 and the local OAM during the service registration phase. The rApp 414 may support or enhance the local OAM operations by providing policy guidance, or the rApp 414 may conduct FCAPS operations directly in parallel with the local OAM. The NRT RIC 412 may provide conflict management services to resolve potential configuration and control conflicts between rApps 414 and between rApps 414 and the NRT RIC 412 local OAM functions.
[0040] Figure 5 is a diagram of an O-RAN architecture 500 according to an embodiment. Figure 5 The architecture 500 is similar to Figure 4 400, however, the NRT RIC 502 may include an NRT RIC framework 504 that implements a solution automation studio that is configured to automate actions on sound bound interfaces (e.g., O1 / O2) using a cross link interface (CLI) or simple scripts. In the architecture 500, the framework 504 may prepare default responses based on the received FCAPS information. The NRT RIC 502 may utilize the framework 504 to automate and provide faster responses to southbound interfaces (i.e., interfaces below the NRT RIC or south of the NRT RIC). The default policies of the framework 504 may be updated by the NRT RIC 502 based on an AI / ML learning process, or by the rApp 414 through direct configuration.
[0041] exist Figure 5 In the illustrated embodiment, NRT RIC framework 504 functionality including OAM / FCAPS functionality and O1 termination may be implemented and integrated in automation studio and orchestrator 506 to provide support for O-RAN network function FCAPS via the O1 interface. R1 interface 415 may include a set of services, hereinafter referred to as R1 services, that facilitate interaction between rApp 414 and automation studio and orchestrator 506. Service / responsibility negotiation and conflict management functionality may be provided by automation studio and orchestrator 506 for service coordination between rApp 414 and platform native OAM implementation.
[0042] Figure 6 is a diagram of an O-RAN architecture 600 according to an embodiment. Figure 6 The architecture of 600 is similar to Figure 5The architecture 500 of the embodiment of the present invention is shown, and the NRT RIC 602 also includes a separate policy manager 604 and a communication manager 606. The R1 interface 415 is configured to provide interaction between the rApp 414 and the communication manager 606. The policy manager 604 can provide more default policies, which can be executed on top of the automation studio and orchestrator 506. The communication manager 606 can be configured to manage the communication between different modules. The R1 interface 415 may include a set of R1 services for facilitating the interaction between the rApp 414 and the policy manager 604. Service / responsibility negotiation and conflict management functions can be provided by the policy manager 604 for service coordination between the rApp 414 and the platform local OAM implementation.
[0043] exist Figures 4 to 6 In the illustrated embodiment, rApp 414 can access data from the network interface to the core network through the newly defined core-related services provided by R1 interface 415. If rApp 414 provides support for core control functions, the functions and responsibilities can be separated and negotiated between rApp 414 and the local control function in the core network during the service registration phase. rApp 414 can support or enhance local core control operations by providing policy guidance, or rApp 414 can directly configure or control the core network in parallel with the local control function. Conflict management can be implemented in NRT RIC 412, 502 and 602 to resolve potential configuration and control conflicts between rApp and local control functions. Priorities and privileges can be assigned by the operator or supplier to guide the conflict management process, thereby giving priority to configuration and control commands from different resources.
[0044] Reference again Figure 4 , NRT RIC 412 can implement the cloud orchestration functions and O2 termination of the cloud orchestration module 450 for O-Cloud management, orchestration, and workflow management. The cloud orchestration functions of the cloud orchestration module 450 and the O2 termination 452 can be implemented within the NRTRIC framework 416. NRT RIC 412 can be deployed independently without a conventional SMO infrastructure. The cloud orchestration functions of the cloud orchestration module 450 can be supported in the NRT RIC framework 416, or can be provided by rApp 414 with a third-party implementation. In one embodiment, SMO 402 and NRT RIC 412 can be deployed together, and both can support cloud orchestration functions in a collaborative manner. In addition, when the orchestration functions are outside the NRT RIC 412, the NRT RIC 412 can provide policies for configuring the orchestration.
[0045] The cloud orchestration functionality of the cloud orchestration module 450 can be implemented by the NRT RIC platform provider as a native function in the NRT RIC framework 416, which can work independently without support from and interaction with any third-party rApps, or the framework can operate in conjunction with rApps that provide the same or different O-Cloud management and orchestration services.
[0046] In some embodiments, rApp 414 may provide O-Cloud management and orchestration functions independently or partially through O2-related services provided by R1 interface 415. If rApp 414 provides full support for O-Cloud management and orchestration functions of cloud orchestration module 450, the local cloud orchestration module 450 implementation in NRT RIC framework 416 may be excluded.
[0047] In some embodiments, rApp 414 and cloud orchestration module 450 in NRT RIC framework 416 may work together to provide a single O-Cloud management and orchestration service via O2 termination 452. In this case, functions and responsibilities may be separated and negotiated between rApp 414 and cloud orchestration module 450 during the service registration phase. rApp 414 may support or enhance the operation of cloud orchestration module 450 by providing policy guidance, or rApp 414 may directly configure and control the O-Cloud infrastructure in parallel with cloud orchestration module 450. Conflict management may be required in NRT RIC 412 to resolve potential configuration and control conflicts between rApp 414 and cloud orchestration module 450. Priorities and privileges may be assigned by the operator or vendor to guide the conflict management process, thereby assigning priorities to configuration and control commands from different resources.
[0048] Reference again Figure 5 , the NRT RIC framework 504 can implement an automation studio and orchestrator 506 that automates actions on southbound interfaces (e.g., O1 / O2) using a CLI or simple scripts. The automation studio and orchestrator 506 can prepare default responses based on the received FCAPS information. The NRT RIC 502 can leverage the framework to automate and provide faster responses to southbound interfaces. The default policy for the interface can be updated by the NRT RIC 502 based on AI / ML learning, or can be updated by rApp 414 through direct configuration. rApp 414 can also support O-Cloud management and orchestration operations through O2-related services (completely or partially) provided by the R1 interface 415. Service / responsibility negotiation and conflict management functions can be provided by the automation studio and orchestrator 506 for service coordination.
[0049] Reference again Figure 6 , NRT RIC 602 can use policy manager 604, and policy manager 602 can provide more default policies, which can be executed on top of automation studio. Communication manager 606 can manage communication between different modules. NRT RIC framework functions (including O-Cloud management and orchestration functions and O2 termination) can be implemented and integrated in policy manager 604. rApp 414 can also support O-Cloud management and orchestration operations through O2 related services (completely or partially) provided by R1 interface 415. Service / responsibility negotiation and conflict management functions can be provided by the policy manager.
[0050] Figure 7 is a flow chart of a 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 through an 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 through an NRT RIC. The O1 connection may include an interface between at least one NE and an O1 termination of the NRT RIC.
[0051] Figure 8 8 is a diagram of an example environment 800 in which the systems and / or methods described herein may be implemented. Figure 8 As shown, environment 800 may include user device 810, platform 820, and network 830. The devices of environment 800 may be interconnected via wired connections, wireless connections, or a combination of wired and wireless connections. Figure 8 Any of the functions and operations described can be performed by Figure 8 The invention may be performed by any combination of the shown elements.
[0052] The user device 810 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information associated with 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 smart phone, 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 the platform 820 and / or send information to the platform 820.
[0053] The platform 820 includes one or more devices capable of receiving, generating, storing, processing and / or providing information. In some implementations, the platform 820 may include a cloud server or a group of cloud servers. In some implementations, the platform 820 may be designed to be modular so that certain software components can be swapped in or out according to specific needs. Therefore, the platform 820 can be easily and / or quickly reconfigured for different purposes.
[0054] In some implementations, as shown, the platform 820 can be hosted in a cloud computing environment 822. It is worth noting that although the implementations described herein describe the platform 820 as being hosted in a cloud computing environment 822, in some implementations, the platform 820 may not be cloud-based (i.e., may be implemented outside of a cloud computing environment), or may be partially cloud-based.
[0055] Cloud computing environment 822 includes an environment hosting platform 820. Cloud computing environment 822 can provide computing, software, data access, storage, and other services that do not require end users (e.g., user devices 810) to be aware of the physical location and configuration of the systems and / or devices hosting platform 820. As shown, cloud computing environment 822 can include a set of computing resources 824 (collectively, "computing resources 824," and individually, "computing resource 824").
[0056] The computing resources 824 include one or more personal computers, computing device clusters, workstation computers, server devices, or other types of computing and / or communication devices. In some implementations, the computing resources 824 can host the platform 820. Cloud resources can include computing instances executed in the computing resources 824, storage devices provided in the computing resources 824, data transmission devices provided by the computing resources 824, etc. In some implementations, the computing resources 824 can communicate with other computing resources 824 via wired connections, wireless connections, or a combination of wired and wireless connections.
[0057] like Figure 8 As further shown, the computing resources 824 include a set 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, or the like.
[0058] The applications 824-1 include one or more software applications that can be provided to or accessed by the user device 810. The applications 824-1 can eliminate the need to install and execute software applications on the user device 810. For example, the applications 824-1 can include software associated with the platform 820, and / or any other software that can be provided via the cloud computing environment 822. In some implementations, one application 824-1 can send information to / receive information from one or more other applications 824-1 via the virtual machine 824-2.
[0059] The virtual machine 824-2 includes a software implementation of a machine (e.g., a computer) (such as a physical machine) that executes a program. The virtual machine 824-2 can be a system virtual machine or a process virtual machine, depending on the use and correspondence of the virtual machine 824-2 to any real machine. The system virtual machine can provide a complete system platform that supports the execution of a complete operating system ("OS"). The process virtual machine can execute a single program and can support a single process. In some implementations, the virtual machine 824-2 can execute on behalf of a user (e.g., a user device 810) and can manage the infrastructure of the cloud computing environment 822, such as data management, synchronization, or long-term data transfer.
[0060] Virtualized storage 824-3 includes one or more storage systems and / or one or more devices using virtualization technology within the storage system or device of computing resource 824. In some implementations, in the context of a storage system, the types of virtualization may include block virtualization and file virtualization. Block virtualization may refer to the abstraction (or separation) of logical storage from physical storage, so that the storage system can be accessed without considering physical storage or heterogeneous structures. This separation may allow administrators of storage systems to have flexibility in how administrators manage storage for end users. File virtualization may eliminate the dependency between data accessed at the file level and the location where the file is physically stored. This may optimize the performance of storage usage, server consolidation, and / or non-disruptive file migration.
[0061] The hypervisor 824-4 can provide hardware virtualization technology that allows multiple operating systems (e.g., "guest operating systems") to execute simultaneously on a host (e.g., computing resources 824). The hypervisor 824-4 can present a virtual operating platform to the guest operating systems and can manage the execution of the guest operating systems. Multiple instances of various operating systems can share virtualized hardware resources.
[0062] 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-based network, etc., and / or a combination of these or other types of networks.
[0063] Figure 8 The number and arrangement of devices and networks shown are provided as examples. In practice, there may be Figure 8 More devices and / or networks, fewer devices and / or networks, different devices and / or networks, or differently arranged devices and / or networks than shown. Figure 8 Two or more of the devices shown may be implemented in a single device, or Figure 8 The single device shown may be implemented as multiple distributed devices. Additionally or alternatively, one set of devices (eg, 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.
[0064] Fig. 9 8 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. Fig. 9 As shown, 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 .
[0065] The bus 910 includes components that allow communication between components of the device 900. The processor 920 can be implemented in hardware, firmware, or a combination of hardware and software. The processor 920 can 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 other types of processing components. In some implementations, the processor 920 includes one or more processors that can be programmed to perform functions. The memory 930 includes a random access memory (RAM), a 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.
[0066] The storage component 940 stores information and / or software related to the operation and use of the device 900. For example, the storage component 940 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optical disk, and / or a solid-state disk), an optical disk (CD), a digital versatile disk (DVD), a floppy disk, a cassette, a magnetic tape, and / or another type of non-transitory computer-readable medium, and a corresponding drive. The input component 950 includes a component that allows the device 900 to receive information such as via user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, and / or a microphone). Additionally or alternatively, the input component 950 may include a sensor for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, and / or an actuator). The output component 960 includes a component that provides output information from the device 900 (e.g., a display, a speaker, and / or one or more light-emitting diodes (LEDs)).
[0067] The communication interface 970 includes a transceiver-like component (e.g., a transceiver and / or a separate receiver and transmitter) that enables the device 900 to communicate with other devices (such as via a wired connection, a wireless connection, or a combination of wired and wireless connections). The communication interface 970 can allow the device 900 to receive information from another device 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.
[0068] Device 900 may perform one or more processes described herein. Device 900 may perform these processes in response to processor 920 executing software instructions stored by non-transitory computer-readable media such as memory 930 and / or storage component 940. Computer-readable media are defined herein as non-transitory memory devices. Memory devices include memory space within a single physical storage device or memory space distributed across multiple physical storage devices.
[0069] The software instructions may be read into memory 930 and / or storage component 940 from another computer-readable medium or from another device via communication interface 970. When executed, the software instructions stored in memory 930 and / or storage component 940 may cause processor 920 to perform one or more processes described herein.
[0070] Additionally or alternatively, 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, the implementations described herein are not limited to any specific combination of hardware circuitry and software.
[0071] Fig. 9The number and arrangement of components shown are provided as examples. In practice, the device 900 may include Fig. 9 More components, fewer components, different components, or differently arranged components than shown. Additionally or alternatively, one 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.
[0072] In an embodiment, Figures 4 to 7 Any operation or process may be performed by or using Figure 8 and Fig. 9 It should be understood that other embodiments are not limited thereto and can be implemented in a variety of different architectures (e.g., bare metal architecture, any cloud-based architecture or deployment architecture, such as Kubernetes, Docker, OpenStack, etc.).
[0073] The above 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.
[0074] Some embodiments may involve systems, methods, and / or computer-readable media at any possible level of integrated technical detail. In addition, one or more of the above components may be implemented as instructions stored on a computer-readable medium and executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include a computer-readable non-transitory storage medium having computer-readable program instructions thereon for causing a processor to perform operations.
[0075] Computer readable storage medium can be a tangible device, which can retain and store instructions for use by instruction execution devices. Computer readable storage medium can be, for example, but not limited to, electronic storage device, magnetic storage device, optical storage device, electromagnetic storage device, semiconductor storage device, or any suitable combination of the above. A non-exhaustive list of more specific examples of computer readable storage medium includes: portable computer floppy disk, hard disk, 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 disk (DVD), memory stick, floppy disk, mechanical encoding device (such as a convex structure in a punch card or groove) with instructions recorded thereon, and any suitable combination of the above. Computer readable storage medium as used herein itself should not be interpreted as transient signal, such as radio wave or other free propagating electromagnetic wave, electromagnetic wave propagated by waveguide or other transmission medium (for example, light pulse passing through optical fiber cable) or electrical signal sent by wire.
[0076] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to a corresponding computing / processing device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network), or downloaded to an external computer or external storage device. The network may include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network, and forwards the computer-readable program instructions to be stored in a computer-readable storage medium within the corresponding computing / processing device.
[0077] The computer readable program code / instruction for performing the operation can be an assembly instruction, an instruction set architecture (ISA) instruction, a machine instruction, a machine-related instruction, a microcode, a firmware instruction, a state setting data, the configuration data of the integrated circuit system, or a source code or object code written in any combination of one or more programming languages, including object-oriented programming languages (such as Smalltalk, C++, etc.) and process programming languages (such as "C" programming languages or similar programming languages). The computer readable program instruction can be executed completely on the user's computer, partially on the user's computer, executed as an independent software package, partially on the user's computer and partially on a remote computer, or completely on a remote computer or server. In the latter case, the remote computer can 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 to an external computer (for example, using an Internet service provider through the Internet) can be executed. In some embodiments, an electronic circuit system (including, for example, a programmable logic circuit system, a field programmable gate array (FPGA) or a programmable logic array (PLA)) can execute computer readable program instructions by using the state information of the computer readable program instruction to personalize the electronic circuit system, thereby performing various aspects or operations.
[0078] These computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine, such that the instructions executed by the processor of the computer or other programmable data processing device create components for implementing the functions / actions specified in the flowchart and / or block diagram blocks. These computer-readable program instructions may also be stored in a computer-readable storage medium, which may direct a computer, a programmable data processing device, and / or other device to operate in a particular manner, such that the computer-readable storage medium having the instructions stored therein includes an article of manufacture, which includes instructions for implementing various aspects of the functions / actions specified in the flowchart and / or block diagram blocks.
[0079] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operating steps to be performed on the computer, other programmable apparatus, or other device, thereby producing a computer-implemented process, so that the instructions executed on the computer, other programmable apparatus, or other device implement the functions / actions specified in the flowchart and / or block diagram blocks.
[0080] The flowchart and block diagram in the figure illustrate the possible implementation architecture, function and operation of the system, method and computer-readable medium according to various embodiments. In this regard, each block in the flowchart or block diagram may represent a microservice, module, segment or part of an instruction, which includes one or more executable instructions for implementing a specified logical function. Compared with what is shown in the figure, the method, computer system and computer-readable medium may include more blocks, fewer blocks, different blocks or blocks arranged differently. In some alternative implementations, the functions described in the block may not appear in the order shown in the figure. For example, in fact, the two blocks shown in succession may be executed simultaneously or substantially simultaneously, or, depending on the functions involved, these blocks may sometimes be executed in the opposite order. It will also be noted that each block illustrated in the block diagram and / or flowchart and the combination of blocks in the block diagram and / or flowchart can be implemented by a system based on special hardware, which performs a specified function or action or performs a combination of special hardware and computer instructions.
[0081] It is obvious that the system and / or method described herein can be implemented with different forms of hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code for implementing these systems and / or methods does not limit these implementations. Therefore, the operation and behavior of these systems and / or methods are described in this article without reference to specific software codes. It should be understood that software and hardware can be designed to implement these systems and / or methods based on the description herein.
Claims
1. A method, performed 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, the method comprising: Obtaining, by the NRT RIC via the O1 connection, fault, configuration, charging, performance, and security (FCAPS) related information from at least one network element (NE) in the O-RAN network; as well as performing, by the NRT RIC via the O1 connection, at least one first FCAPS-related operation corresponding to the FCAPS-related information for the at least one NE, The O1 connection comprises an interface between the at least one NE and an O1 termination of the NRT RIC. 2 . The method of claim 1 , wherein the O1 is terminated in an NRT RIC framework of the NRT RIC.
3. The method according to claim 1, further comprising: Acquiring, by the NRT RIC, at least one second FCAPS-related operation corresponding to an O-RAN cloud (O-Cloud) function; as well as The at least one second FCAPS-related operation corresponding to the O-Cloud function is implemented by the NRT RIC via the O2 connection.
4. The method according to claim 3, wherein the O2 connection comprises: The interface between the O-Cloud infrastructure and the O2 termination of the NRT RIC.
5. The method of claim 4, wherein the O2 is terminated in the NRT RIC framework of the NRT RIC.
6. The method of claim 1, wherein the NRT RIC comprises: A policy manager configured to implement the at least one first FCAPS-related operation.
7. The method of claim 6, wherein the NRT RIC comprises: The NRTRIC framework is separate from the policy manager.
8. A system implemented in a telecommunications network, the system comprising: Memory, which stores instructions; as well as A processor configured to execute the instructions to: obtaining, 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, fault, configuration, charging, performance and security (FCAPS) related information from at least one network element (NE) connected to the O-RAN network via an O1 connection; as well as At least one first FCAPS-related operation corresponding to the FCAPS-related information is implemented by the NRT RIC for the at least one NE via the O1 connection, wherein the O1 connection includes an interface between the at least one NE and an O1 termination of the NRT RIC.
9. The system of claim 8, wherein the O1 is terminated in an NRT RIC framework of the NRT RIC.
10. The system of claim 8, wherein the processor is further configured to execute the instructions to: acquiring, by the NRT RIC, at least one second FCAPS related data corresponding to an O-RAN cloud (O-Cloud) function; and The at least one second FCAPS-related operation corresponding to the O-Cloud function is implemented by the NRT RIC via the O2 connection.
11. The system of claim 10, wherein the O2 connection comprises: The interface between the O-Cloud infrastructure and the O2 termination of the NRTRIC.
12. The system of claim 11, wherein the O2 is terminated in an NRT RIC framework of the NRT RIC.
13. The system of claim 8, wherein the NRT RIC comprises: A policy manager configured to implement the at least one first FCAPS-related operation.
14. The system of claim 13, wherein the NRT RIC comprises: The NRTRIC framework is separate from the policy manager.
15. A non-transitory computer-readable storage medium storing instructions that, when executed by at least one processor, cause the at least one processor to: obtaining, 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 via an O1 connection, at least one first fault, configuration, charging, performance, and security (FCAPS) related operation from at least one network element (NE) in the O-RAN network; and performing, by the NRT RIC via the O1 connection, at least one first FCAPS-related operation corresponding to the FCAPS-related information for the at least one NE, The O1 connection comprises an interface between the at least one NE and an O1 termination of the NRT RIC.
16. The storage medium of claim 15, wherein the O1 is terminated in an NRT RIC frame of the NRT RIC.
17. The storage medium of claim 15, wherein the instructions, when executed, further cause the at least one processor to: Acquiring, by the NRT RIC, at least one second FCAPS-related operation corresponding to an O-RAN cloud (O-Cloud) function; and The at least one second FCAPS-related operation corresponding to the O-Cloud function is implemented by the NRT RIC via the O2 connection.
18. The storage medium of claim 17, wherein the O2 connection comprises: The interface between the O-Cloud infrastructure and the O2 termination of the NRT RIC.
19. The storage medium of claim 18, wherein the O2 is terminated in an NRT RIC framework of the NRT RIC.
20. The storage medium of claim 15, wherein the NRT RIC comprises: A policy manager configured to implement the at least one first FCAPS-related operation.