Application programming interface (API) for configuration management (CM) in open radio access network (o-ran)

Abstract

Example embodiments of the present disclosure relate to an Application Programming Interface (API) for configuration management (CM) in Open Radio Access Network (O-RAN). According to example embodiments, a system may include an Operations and Management (OAM) function and a Non-Real-Time (Non-RT) Radio Access Network (RAN) Intelligent Controller (RIC). The Non-RT RIC may implement at least one application (rApp). The rApp may be communicatively coupled to the OAM function via an Open API that supports two Hypertext Transfer Protocol (HTTP) operations. In this regard, the rApp may be configured to send, to the OAm function via the Open API, an API request. Further, the OAM function may be configured to receive the API request from the rApp via the Open API and perform a CM operation based on the API request.

Description

APPLICATION PROGRAMMING INTERFACE (API) FOR CONFIGURATION MANAGEMENT (CM) IN OPEN RADIO ACCESS NETWORK (O-RAN)TECHNICAL FIELD

[0001] The present disclosure relates to an application programming interface (API) for configuration management (CM) in an open radio access network (O-RAN).BACKGROUND

[0002] The information disclosed in this background section is only for the enhancement of understanding of the general background of the disclosure and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person skilled in the art.

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

[0004] Open RAN (O-RAN) technology has emerged to enable multiple vendors to provide hardware and / or software to a telecommunications system. Since different vendors are involved, the type of hardware and / or software provided may also be different. That is, different types of NEs may be provided by different vendors, and depending on the specific service, the NE could be virtualized in software form or could be in physical hardware form.

[0005] To this end, O-RAN disaggregates the RAN functions into a central unit (CU), a distributed unit (DU), and a radio unit (RU). The CU may be a logical node for hosting Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and / or Packet DataConvergence Protocol (PDCP) sublayers of the RAN. The DU may be a logical node hosting Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY) sublayers of the RAN. The RU may be a physical node that converts radio signals from antennas to digital signals that can be transmitted over the Front Haul to a DU. Because these entities have open protocols and interfaces between them, they can be developed by different vendors.

[0006] The 0-RAN also includes a Service Management and Orchestration (SMO) framework that may be configured to implement one or more Operation and Maintenance (0AM) functions such as a configuration management (CM) function, amongst others. For instance, the SMO may communicate with an NE and manage the configuration of one or more NEs within the 0-RAN architecture.SUMMARY

[0007] Example embodiments of the present disclosure provide systems, apparatuses, methods, and the like, that utilize a novel application programming interface (API) for configuration management in the 0-RAN.

[0008] According to example embodiments, a system may include an Operations and Management (0AM) function and a Non-Real-Time (Non-RT) Radio Access Network (RAN) Intelligent Controller (RIC). The Non-RT RIC may implement at least one application (rApp). The rApp may be communicatively coupled to the 0AM function via an Open API that may support two Hypertext Transfer Protocol (HTTP) operations. In this regard, the rApp may be configured to send, to the 0AM function via the Open API, an API request. Further, the 0AM function may be configured to receive the API request from the rApp via the Open API and perform a configuration management (CM) operation based on the API request.

[0009] According to example embodiments, a method may include: providing, by at least one rApp of a Non-RT RIC to an 0AM function via an Open API that may support two HTTP operations, an API request; receiving, by the 0AM function via the Open API, the API request; and performing, by the 0AM function based on the API request, a CM operation.

[0010] According to example embodiments, a non-transitory computer-readable recording medium may have recorded thereon instructions executable by a system that may include a Non- RT RIC and an 0AM function to cause the system to perform a method including: providing, by at least one rApp of the Non-RT RIC to the 0AM function via an Open API that may support two HTTP operations, an API request; receiving, by the 0AM function via the Open API, the API request; and performing, by the 0AM function based on the API request, a CM operation.

[0011] Additional aspects will be set forth in part in the description that follows and, in part, will be apparent from the description, or may be realized by practice of the presented embodiments of the disclosure.BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Features, aspects, and advantages of embodiments of the disclosure will be described below with reference to the accompanying drawings, in which like reference numerals denote like elements, and wherein:

[0013] FIG. 1 illustrates a table of service APIs defined in a technical specification of ORAN Alliance, in the related art.

[0014] FIG. 2 illustrates an example system architecture, according to one or more example embodiments;

[0015] FIG. 3 illustrates a block diagram of an example method, according to one or more example embodiments;

[0016] FIG. 4 illustrates a flow diagram of an example use case in which communication associated with the reading of configuration data of an NE is performed via an Open API, according to one or more example embodiments;

[0017] FIG. 5 illustrates a flow diagram of an example use case in which communication associated with the writing of configuration change information of an NE is performed via the Open API, according to one or more example embodiments; and

[0018] FIG. 6 illustrates an example device for implementing one or more example embodiments.DETAILED DESCRIPTION

[0019] The following detailed description of example embodiments refers to the accompanying drawings. The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise forms disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations. Further, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). Additionally, the flowchart and description of operations provided below relate to one of the various embodiments. It should be noted that it is possible to make other embodiments that do not exactly match the flowchart and its description. It is understood that in other embodiments 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).

[0020] It will be apparent that systems and / or methods, described herein, may be implemented in different forms of hardware, firmware, or a combination of hardware and software.The actual specialized control hardware or software code used to implement these systems and / ormethods is not limited to the described implementations. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It is understood that software and hardware may be designed to implement the systems and / or methods based on the description herein.

[0021] Even though particular combinations of features are disclosed in the claims and / or in the specification, these combinations are not intended to limit the disclosure of 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 implementations includes each dependent claim in combination with every other claim in the claim set.

[0022] No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles “a” and “an” are intended to include one or more items, and may be used interchangeably with “one or more.” Also, as used herein, the terms “has,” “have,” “having,” “include,” “including,” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise. Furthermore, expressions such as “at least one of [A] and [B]”, “[A] and / or [B]”, or “at least one of [A] or [B]”, are to be understood as including only A, only B, or both A and B.

[0023] It shall be noted that, descriptions of example embodiments of the present disclosure may include terms and names defined in one or more standard organizations, such as the 3rd Generation Partnership Project (3GPP) standard organization, the European Telecommunications Standards Institute (ETSI) standard organization, the Open Radio Access Network (ORAN) Alliance standard organization, and the like. For instance, the terms “CM”,“SMO”, “rApp”, “OAM”, and the like, as well as the associated features and operations, are to be interpreted as consistent with those specified in one or more technical specifications, unless being described otherwise.

[0024] In the open radio access network (0-RAN) architecture, the RAN elements may be disaggregated into various types of network elements (NEs). The radio side may be comprised of a near-real-time (Near-RT) RAN intelligent controller (RIC), an 0-RAN Central Unit (O-CU), an 0-RAN Distributed Unit (0-DU), and an 0-RAN Radio Unit (0-RU). The management side may be comprised of a Service Management and Orchestration (SMO) framework that may include a non-real-time (Non-RT) RIC and a plurality of RAN Operation and Maintenance (OAM) functions. The SMO framework may be configured to manage the radio side RAN elements via the respective open interface (e.g., performing one or more fault, configuration, accounting performance, security (FCAPS) operations via 01 interface, performing cloud management via 02 interface, etc.)

[0025] In this regard, the Non-RT RIC of the SMO framework may be a software-defined component that implements a modular, non-real-time application (rApp) to facilitate multivendor operability, as well as to automate and optimize RAN operations. On the other hand, the RAN OAM functions may provide various types of network function (NF)-related Management Services (MnS), such as configuration management (CM), fault management (FM), performance management (PM), and the like. The rApp and the RAN OAM functions may be developed or provided by different vendors and may be required to interoperate with each other to perform operational optimization and management on the RAN elements. For instance, in order to perform optimization operations for improving the end-to-end user service experience and / or the network performance, the rApp may need to interact with the RAN OAM functions to collect measurementdata from the network for AI / ML training / inference / analyzing, for configuring policies, and the like.

[0026] Similarly, the RAN 0AM functions may provide configuration management (CM) on an NF of the NEs, such as creating a new NF for the NEs, deleting an existing NF of the NEs, and modifying an NF (or an attribute associated therewith) of the NEs. The configuration information may be required by the rApp to, for example, discover the current configuration of the NEs, verify the configuration of the NEs with the desired policies, perform fault recovery by adjusting the configuration of the NEs, and the like.

[0027] Nevertheless, in the related art, the communication interface between the rApp and the 0AM functions, particularly those associated with CM, is not specified. Specifically, although the concept of performing the communication between the rApp and the CM-related 0AM functions via an application programming interface (API) is introduced in the related art, the functionalities supported by the CM API, as well as the data types supported by the CM API, have not yet been defined and have not yet been standardized.

[0028] For instance, FIG. 1 illustrates a table of service APIs defined in the current technical specification, such as 0-RAN.WG2.R1AP, of the ORAN Alliance. The APIs with the terms “-alpha.1” indicate that the associated APIs are under development and are not yet implementable to the actual products or network elements. As illustrated in FIG. 1, in the current ORAN technical specification, the APIs associated with RAN 0AM, including the CM-related API, are still under development and have not yet been specified.

[0029] In this regard, since the Non-RT RIC may implement multiple rApps and multiple 0AM functions that are developed and provided by different parties (e.g., vendors, network operator, etc.), the rApps may not be able to efficiently and effectively communicate with theassociated OAM functions for configuration management, without an API that has clear and standardized supported functionalities and data types.

[0030] By way of example, a vendor may implement an Open API (defined in 3GPP TS. 28.532 as a provisioning management service API), which is utilized between the OAM function and the E2 nodes (e.g., RAN NEs like O-CU, 0-DU, etc.) via the 01 interface and supports five Hypertext Transfer Protocol (HTTP) operations (i.e., PUT, POST, DELETE, GET, and PATCH) to the associated rApp, while the service API supported by the CM-related OAM functions may support only two HTTP operations (e.g., GET and PATCH). In this case, the rApp may not be able to properly communicate with the CM-related OAM functions via the implemented API, since the API of the rApp does not comply with the functionalities supported by the API of the CM-related OAM functions.

[0031] As another example, assuming that the API of the rApp supports a first data type while the API of the CM-related OAM functions supports a second data type, when the rApp communicates with the CM-related OAM functions via the API, the rApp and the CM-related OAM functions may provide and receive data that is not compatible or readable by each other.

[0032] In this regard, example embodiments of the present disclosure provide an API that enables an rApp to effectively and efficiently communicate with an OAM function for configuration management in the 0-RAN. Specifically, example embodiments of the present disclosure implement a novel Open API that is communicatively coupling the rApp and the CM- related OAM function and supports two operations, such as an HTTP GET operation for reading configuration data associated with an NE and an HTTP PATCH operation for writing configuration changes information in the NE.

[0033] The term “Open API” described herein may refer to an API that enables communication between a CM service consumer (e.g., an rApp) and a CM service producer (e.g., an 0AM function) within the O-RAN architecture. This Open API may be vendor-neutral for enabling interoperability between applications (e.g., rApps, 0AM functions, etc.) provided by different vendors, while ensuring compliance to features and requirements defined in technical specifications provided by the standard organizations (e.g., 3GPP, ORAN Alliance, etc.) The “Open API” provided by the example embodiments of the present disclosure may be different from the Open API introduced in the related art in that, the “Open API” of the example embodiments is communicatively coupling the rApp to an 0AM function within an SMO framework for configuration management purposes, while the Open API in the related art is utilized for the communication among the SMO framework and the E2 nodes (e.g., 0-CU, 0-DU, etc.) via the 01 interface. Further, the “Open API” of the example embodiments specifically required only the support of two HTTP operations (i.e., GET and PATCH) for configuration management purposes, while the Open API in the related art supports five HTTP operations (i.e., PUT, POST, DELETE, GET, and PATCH).

[0034] In addition to specifying the functionalities (e.g., supported HTTP operations) of the API, example embodiments of the present disclosure also specify the data type supported by the API. As further described below, according to example embodiments, the Open API of the present disclosure may support at least the following three data types: a “Resource” data type, a “Scope” data type, and a “Patchitem” data type. These data types may be utilized during the communication between the rApp and the 0AM function via the Open API of the present disclosure, thereby facilitating efficient and effective communication for configuration management.

[0035] It is contemplated that features, advantages, and significances of example embodiments described hereinabove are merely a portion of the present disclosure, and are not intended to be exhaustive or to limit the scope of the present disclosure. Further descriptions of the features, components, configuration, operation are provided in the following.Example System Architecture

[0036] FIG. 2 illustrates an example system architecture, according to one or more example embodiments. As illustrated in FIG. 2, the system architecture may include a Service Management and Orchestration (SMO) framework 110, a plurality of 0-RAN Network Elements (NEs) 120, and an O-RAN Cloud (O-Cloud) 130.

[0037] The SMO framework 110 may include a non-real-time (Non-RT) RAN Intelligent Controller (RIC) 111 and an Operation and Management (0AM) function 112. The Non-RT RIC 111 may implement an application (rApp) 111-1, while the 0AM function 112 may include a configuration management (CM)-related 0AM function 112-1.

[0038] The 0-RAN NEs 120 may include a plurality of Virtualized Network Functions (VNFs) 121 and a plurality of Physical Network Functions (PNFs) 122. The VNFs 121 may be configured to provide centralized functions, while the PNFs 122 may be configured to provide functions closer to the user. As illustrated in FIG. 2, the VNFs 121 may include a near-real-time (Near-RT) RIC 121-1 and an 0-RAN Central Unit (O-CU) 121-2. In some example embodiments, the O-CU 121-2 may be further disaggregated into an O-CU Control Plane (O-CU-CP) and an O- CU User Plane (O-CU-UP). Further, the PNFs 122 may include an 0-RAN Distributed Unit (O- DU) 122-2 and an 0-RAN Radio Unit (0-RU) 122-2. In some example embodiments, the 0-DU 122-2 may be implemented in the form of VNF (instead of being implemented in the form of PNF).

[0039] The O-Cloud 130 may refer to a cloud computing platform comprising a collection of physical infrastructure nodes or entities that meet O-RAN requirements to host the SMOFramework 110, at least one of the plurality of O-RAN NEs 120, the supporting software components (e.g., operating system, network function, virtual machine monitor, container runtime, etc.), and / or the appropriate management orchestration function.

[0040] According to example embodiments, the O-Cloud 130 may refer to a single federated cloud that is constituted by multiple O-Clouds (e g., the same type of O-Clouds, a mixture of different types of O-Clouds, etc.) Alternatively or additionally, the O-Cloud 130 may refer to a cloud cluster that consists of a plurality of O-Cloud nodes. In some example implementations, the SMO Framework 110 (and the associated components) may be implemented in a first O-Cloud resource pool, and the O-RAN NEs 120 (and the associated components) may be implemented in a second O-Cloud resource pool.

[0041] It is contemplated that the system architecture in FIG. 2 is simplified for descriptive purposes, and the actual system architecture may be different according to the respective implementation requirements, without departing from the scope of the present disclosure. For instance, the Non-RT RIC 111 may implement a plurality of rApps, the 0AM function 112 may further include other types of 0AM functions (e.g., Fault Management (FM)-related 0AM Function, etc.), the PNFs may include a plurality of O-DUs and / or a plurality of O-RUs, and the like.

[0042] The Non-RT RIC 111 may be a software-defined component that implements at least one modular, non-real-time application (e.g., rApp 111-1) to facilitate multivendor operability, as well as to automate and optimize RAN operations. In some example implementations, the Non-RT RIC 111 may be deployed in the form of VNF, containerized / cloud-native network function (CNF), and the like. In this case, the operations associated with the Non-RT RIC 111 may be performed by, for example, a processor upon executing the software-formNon-RT RIC 111 (or the computer-executable instructions associated therewith).

[0043] In some example embodiments, the Non-RT RIC 111 may be the control point of a non-real-time control loop and may operate on a timescale greater than 1 second within the SMO Framework 110. On the other hand, the rApp 111-1 may be a modular application that leverages the functionality exposed by the Non-RT RIC 111 and / or the 0AM function 112 to perform RAN optimization and other functions. For instance, the Non-RT RIC 111 may implement the rApp 111-1 to provide services such as configuration management, policy management, radio resource management, data analytics, and providing enrichment information. In some example implementations, the Non-RT RIC 111 may implement multiple rApps that were developed or provided by the same vendors and / or by different vendors.

[0044] The 0AM function 112 may be a software-defined component that provides comprehensive management of the 0-RAN NEs 120. As illustrated in FIG. 2, the 0AM function 112 may include at least one 0AM function associated with configuration management (CM), i.e., CM-related 0AM function 112-1. In some example embodiments, the 0AM function 112 may include a plurality of CM-related 0AM functions, and / or may further include an 0AM function associated with fault management (FM), an 0AM function associated with performance monitoring (PM), and any other suitable types of 0AM function.

[0045] The Non-RT RIC 111 (and the associated rApp 111-1) may be communicatively coupled to the 0AM function 112 (and the associated CM-related 0AM function 112-1) via an Open Application Programming Interface (API). The Open API may support two Hypertext Transfer Protocol (HTTP) operations, such as an HTTP GET operation and an HTTP PATCHoperation. In addition, the Open API does not require the support of the following HTTP operations: an HTTP PUT operation, an HTTP POST operation, and an HTTP DELETE operation. The supported and unsupported HTTP operations comply with the API requirements for configuration management as defined by the ORAN Alliance. Further, the Open API supports at least the following data types: a Resource data type, a Scope data type, and a Patchitem data type. As further described below, these supported data types may be utilized in various operations and notifications during the communication between the Non-RT RIC 111 (and the associated rApp 111-1) and the OAM function 112 (and the CM-related 0AM function 112-1) for configuration management purposes.

[0046] Through the Open API of example embodiments, the Non-RT RIC 111 (and the associated rApp 111-1) may interact with the OAM function 112 (and the CM-related OAM function 112-1) to gather and analyze data from the network, thereby providing configuration management for the 0-RAN NEs 120 based thereon. For instance, the rApp 111-1 may request the CM-related OAM function 112-1 to provide configuration data associated with one or more of the 0-RAN NEs 120, and then analyze the configuration data to determine a policy management for the associated 0-RAN NEs 120. As another example, the rApp 111-1 may determine the need to write information associated with configuration changes in one or more of the 0-RAN NEs 120, and may thus request the CM-related OAM function 112-1 to write the configuration changes information. Several example use cases associated therewith are further described below with reference to FIG. 4 and FIG. 5.

[0047] In view of the above, the Non-RT RIC 111 (and the associated rApp 111-1) and the OAM function 112 (as well as the CM-related OAM function 112-1) may interoperate within the SMO Framework 110 via the Open API of the example embodiments. Subsequently, the SMOFramework 110 may be configured to manage the 0-RAN NEs 120 via various interfaces. For instance, the SMO Framework 110 may provide access to 0AM functionalities for the E2 nodes (e.g., Near-RT RIC 121-1, O-CU 121-2, 0-DU 122-1) via 01 interface, for the 0-RU 122-2 via the open fronthaul (O-FH) management plane (M-Plane) interface, and for the O-Cloud 130 via 02 interface. In this regard, it is contemplated that when one or more of the 0-RAN NEs 120 (e.g., Near-RT RIC 121-1, O-CU 121-2, etc.) are implemented in the O-Cloud 130, the SMO Framework 110 may also manage said 0-RAN NE(s) via the 02 interface.

[0048] On the other hand, the 0-RAN NEs 120 may also be communicatively coupled to each other via a respective interface. For instance, the Near-RT RIC 121-1 may be communicatively coupled to the O-CU 121-2 and the 0-DU 122-1 via an E2 interface, the O-CU 121-2 may be communicatively coupled to the 0-DU 122-1 an Fl interface and / or the E2 interface, and the 0-DU 122-1 may be communicatively coupled to the 0-RU 12202 via one or more O-FH Control (C), User (U), Synchronization (S), and Management (M) plane interfaces.

[0049] The Near-RT RIC 121-1 may refer to a logical function that enables near-real-time control and optimization of RAN elements and resources. For instance, the Near-RT RIC 121-1 may provide near-real-time control and optimization via fine-grained (e.g., UE basis, Cell basis, etc.) data collection and actions over the E2 interface. In some example implementations, the Near- RT RIC 121-1 may operate on a timescale between 10 milliseconds and 1 second and may be coupled with the O-CU 121-2 and the 0-DU 122-1 via the E2 interface. The Near-RT RIC 121-1 may use the E2 interface to control the underlying RAN elements (E2 nodes / network functions) over a near-real-time control loop. According to example embodiments, the Near-RT RIC 121-1 may host or implement an application (xApp) to implement the functions or operations associated with the Near-RT RIC 121 -1 .

[0050] Next, the descriptions of the 0-CU 121-2, the 0-DU 122-1, and the 0-RU 122-2 are provided. Generally, the O-CU 121-2, the 0-DU 122-1, and the 0-RU 122-2 may constitute a base station, such as a gNodeB (gNB) of 5GNR, a node in Next Generation Radio Access Network (NG-RAN), a base station of a 6G network, and the like.

[0051] The 0-DU 122-1 may receive radio signals from an end user (via one or more UEs and one or more cells) and may provide operation or support for lower layers of protocol stacks (e.g., RLC layer, MAC layer, Physical Layer, etc.) accordingly. As an example, the 0-DU 122-1 may perform one or more scheduling operations. The O-CU 121-2 may communicatively couple the O-DU 122-1 to a core network (e.g., 4G Evolved Packet Core (EPC) network, 5G Core network, etc.) and may receive the radio signals from the O-DU 122-1, thereby providing operation or support for higher layers of protocol stacks (e.g., PDCP layer, RRC layer, etc.) accordingly.

[0052] According to example embodiments, the O-CU 121-2 may include an O-CU control plane (O-CU-CP) and an O-CU user plane (O-CU-UP). The O-CU-CP may refer to the logical node that hosts or implements the RRC and the control plane part of the PDCP protocol, and may be responsible for managing the signaling between the core network and the radio network, handling tasks such as session management, radio bearer control, and mobility management. On the other hand, the O-CU-UP may refer to the logical node that hosts or implements the user plane part of the PDCP protocol and the SDAP protocol, and may be responsible for managing the data traffic and the transmission of user data packets. The O-CU-CP and the O-CU-UP may be coupled to each other via the El interface.

[0053] Further, a single 0-DU 122-1 may host or serve multiple network cel

[0054] Is formed by multiple O-RUs 122-2. According to example embodiments, the O-DU 122-1 may implement various radio technologies, such as massive multiple-input multiple-output (MIMO), beamforming, and the like, to optimize radio communication among the multiple cells and the O-CU 121-2. In some example implementations, the O-DU 122-1 may concurrently host or serve hundreds (e.g., 512, etc.) of cells at a time.

[0055] The O-RU 122-2 may be a physical node that converts radio signals from antennas to digital signals that can be transmitted over the Front Haul to the O-DU 122-1. In this regard, a network cell described herein may correspond to one or more radio units responsible for providing wireless coverage and signal transmission within the network cell. The network cell may include a macro cell, a micro cell, a pico cell, a femto cell, and / or any other suitable type of network cell. Each of the cells may have an associated coverage area, in which at least one O-RU 122-2, at least one antenna system, and any other suitable type of transport network element (TNE), may be deployed therein. According to example embodiments, the O-DU 122-1 may be configured to control or instruct the associated O-RU(s) via one or more of the O-FH C / U / S / M plane interfaces. On the other hand, the capability exchange between the O-DU 122-1 and the O-RU(s) 122-2 may be performed via the O-FH M-plane interface.

[0056] In view of the above, example embodiments of the present disclosure provide a system architecture for implementing a novel Open API that enables efficient and effective communication among the Non-RT RIC (as well as the rApp associated therewith) and the 0AM function for configuration management in the 0-RAN. Further descriptions associated with the functionalities and data types supported by the Open API of the example embodiments are provided in the following.Open API: Supported Functionalities

[0057] According to example embodiments, the Open API may support functionalities that comply with the requirements of configuration management API specified by the ORAN Alliance.Further, although the Open API of the example embodiments may support a portion of functionalities of the provisioning management service API defined by 3 GPP, the Open API of the example embodiments is different from the provisioning management service API in that it does not require to support several specific functionalities of the provisioning management service API.

[0058] The following Table 1 presents HTTP operations supported by the Open API of example embodiments, which include adaptations of HTTP operations consistent with the provisioning management service API in 3GPP.Table 1: Examples of Adapted HTTP Operations

[0059] Further, the following Table 2 presents HTTP operations of the provisioning management service API that may be excepted from the Open API of example embodiments.Table 2: Examples of Excepted HTTP Operations

[0060] The Open API of example embodiments of the present disclosure may be configured to support the two HTTP operations presented in Table 1 and to exclude the three HTTP operations presented in Table 2. For instance, the vendor or developer of the rApp may define a schema that specifies the supported HTTP operations and / or the non-supported HTTP operations, and then integrate the Open API accordingly.

[0061] An example method performed via the Open API is described below with reference to FIG. 3, and example use cases that involved the HTTP operations presented in Table 1 are described below with reference to FIG. 4 and FIG. 5.Open API: Supported data types

[0062] According to example embodiments, the Open API may support a portion of data types that comply with the data types used by the provisioning Management Services (MnS), as required by 3GPP. Further, the Open API of example embodiments may also utilize data types from external documents by the RAN OAM-related service APIs, while complying with restrictions and adaptations of these data types for their usage within the context of the RAN OAM- related APIs.

[0063] The following Table 3 presents data types supported by the Open API of example embodiments.Table 3: Examples of Supported Data Types

[0064] These supported data types may be utilized by the Open API of example embodiments to support various operations and notifications in the provisioning of configuration management in the 0-RAN.

[0065] According to example embodiments, the “Resource” data type may be used to represent various network resources during the communication performed via the Open API. For example, when the configuration of an NF is required to be modified, the “Resource” data type can be used by the rApp and / or 0AM function to define the properties of the desired NF (e.g., resourcelD, type, configuration parameters, etc.) after the modification.

[0066] According to example embodiments, the “Scope” data type may be used to extend the set of targeted resources beyond the base resource identified with the authority and path component of the URL Specifically, the “Scope” data type may define the range or extent of the resources that an operation applies to, such as specific network elements or configurations within a larger set. For example, when modifying the configuration of a set of resources, the rApp and / or 0AM function can specify a Scope to identify all related resources that need to be modified.

[0067] According to example embodiments, the “Patchitem” data type may be used to specify a patch item in a patch document. For instance, in the context of the HTTP PATCH operation, the “Patchitem” data type may be used by the rApp and / or 0AM function to support operations like add, replace, remove, copy, move, and test on a resource's attributes. This allows for fine-grained updates to the resource's configuration without replacing the entire resource.

[0068] The data types supported by the Open API of the example embodiments, as presented in Table 3, can be utilized during the communication between the Non-RT RIC (as well as the rApp associated therewith) and the 0AM function (e.g., CM-related 0AM function). Forinstance, one or more of the supported data types (as presented in Table 3) may be utilized in one or more of the supported HTTP operations (as presented in Table 1).

[0069] In view of the above, example embodiments of the present disclosure specify the data types that can be directly used in the request or response message content of the Open API. In addition, the externally defined data types (datatypes defined by external documents such as documents from 3 GPP) are listed that are descendants of a directly used data type and for which restrictions and adaptations are defined in the present document. Other external ancestor data types are not listed, as they are referenced directly in the external specification.Examples Operations and Use Cases

[0070] As described above, example embodiments of the present disclosure provide a system that utilized a novel Open API for configuration management in the 0-RAN. Example operations of performable by the system, as well as example use cases associated therewith, are described in the following.

[0071] FIG. 3 illustrates a block diagram of an example method 300, according to one or more example embodiments. The operations of method 300 may be performed by a system that includes an rApp implemented by a Non-RT RIC (e.g., rApp 111-1) and an 0AM function (e.g., 0AM function 112-1). It is contemplated that, when the Non-RT RIC (as well as the associated rApp) and the 0AM function are implemented in a hardware (e.g., a server, a device, etc.), one or more operations described herein may be performed by a component of the hardware (e.g., a processor of the server upon executing computer-readable instruction stored in a memory of the server, etc.)

[0072] Referring to FIG. 3, at operation S310, the rApp may be configured to send, to an0AM function via an Open API, an API request. The Open API may communicatively couple therApp to the OAM function, and may support two HTTP operations. For instance, the Open API may support an HTTP GET operation and an HTTP PATCH operation, and may not support the following HTTP operations: an HTTP PUT operation, an HTTP POST operation, and an HTTP DELETE operation. Further, the Open API may support at least the following data types: a Resource data type, a Scope data type, and a Patchitem data type. The content of the API request may be defined or presented by one or more of the supported data types

[0073] According to example embodiments, the rApp may be configured to send the API request based on determining the need to request configuration data of an 0-RAN NE. For instance, based on determining that the configuration data of the 0-RAN NE is needed, the rApp may generate a request to perform the HTTP GET operation (may be referred to as “HTTP GET request” herein) to read the configuration data, and then send the HTTP GET request to the associated OAM function (e.g., CM-related OAM function 112-1) via the Open API. Further descriptions of an associated example use case are provided below with reference to FIG. 4.

[0074] According to example embodiments, the rApp may be configured to send the API request based on determining the need to write information pertaining to configuration changes of an 0-RAN NE (may be referred to as “configuration change information” herein). For instance, based on determining that the writing of the configuration change information in an NE is needed, the rApp may generate a request to perform the HTTP PATCH operation (may be referred to as “HTTP PATCH request” herein) to write the configuration change information in the NE, and then send the HTTP PATCH request to the associated OAM function via the Open API. Further descriptions of an associated example use case are provided below with reference to FIG. 5.

[0075] Referring still to FIG. 3, at operation S320, the OAM function may be configured to receive the API request from the rApp via the Open API. Accordingly, at operation S33O, theOAM function may be configured to perform, based on the API request, a configuration management (CM) operation. According to example embodiments in which the API request includes an HTTP GET request, the OAM function may obtain the configuration requested by the rApp and then provide the requested configuration data to the rApp via the Open API. According to example embodiments in which the API request includes an HTTP PATCH request, the OAM function may perform an operation to write the configuration change information (or create a Write configuration job) based on the API request, and then provide the information of the operation (or information of the created job) to the rApp via the Open API.

[0076] Referring next to FIG. 4 and FIG. 5, each of which is associated with an example use case that involves the Open API of the example embodiments. For descriptive purposes, it is assumed that the example use cases involve the rApp 111-1 and the CM-related OAM function 112-1 described above with reference to FIG. 2, and the communication therebetween are performed via the Open API of example embodiments described herein and may involve one or more of the supported data types described herein..

[0077] FIG. 4 illustrates a flow diagram of an example use case in which communication associated with the reading of configuration data of an NE is performed via the Open API, according to one or more example embodiments.

[0078] In this example use case, the rApp 111-1 may act as a CM service consumer that retrieves, from the CM-related OAM function 112-1 (i.e., the CM service producer), information pertaining to the configuration data of one or more NEs (e.g., one or more of 0-RAN NEs 120) that the rApp 111-1 are managing. Further, this example use case may be initiated by the rApp111-1 when the rApp 111-1 determines the need to request the configuration data.

[0079] As illustrated in FIG. 4, at step 1, the rApp 111-1 may send, via an Open API, an HTTP GET request to the CM-related 0AM function 112-1. The HTTP GET request may be an API request that requests to read configuration data of an NE, and may include an identifier (ID) of the rApp 111-1 (e.g., rAppId) and information associated with the desired configuration data. Optionally, the HTTP GET request may further include query criteria and information about the associated NE. The response of the 0AM function 112-1 may be scoped by the information provided in the HTTP GET request.

[0080] At step 2, the CM-related 0AM function 112-1 may receive, from the rApp 111-1 via the Open API, the HTTP GET request, and then perform a CM operation based thereon. For instance, the CM-related 0AM function 112-1 may determine, based on the HTTP GET request (e.g., rAppId included in the request, etc.), whether or not the rApp 111-1 is authorized to read the requested configuration data. In some example implementations, the 0AM function 112-1 may further validate the information provided in the HTTP GET request (e.g., whether or not the requested configuration data is available, etc.)

[0081] In this regard, based on determining that the rApp 111-1 is authorized, the flow diagram may proceed to step 3, at which the 0AM function 112-1 may provide, to the rApp 111- 1 via the Open API, a message that includes the requested configuration data. In some example embodiments, the message may include an HTTP 200 OK success status response.

[0082] On the other hand, based on determining that the rApp 111-1 is not authorized, the flow diagram may proceed to step 4, at which the 0AM function 112-1 may provide, to the rApp 111-1 via the Open API, a message that includes error information, such as an error code, the reason(s) of the error, and the like.

[0083] FIG. 5 illustrates a flow diagram of an example use case in which communication associated with the writing of configuration change information of an NE is performed via the Open API, according to one or more example embodiments.

[0084] In this example use case, the rApp 111-1 may act as a CM service consumer that requests, via the Open API, the CM-related 0AM function 112-1 (i.e., the CM service producer) to write information associated with configuration changes in one or more NEs (e.g., one or more of 0-RAN NEs 120) that the rApp 111-1 are managing. Further, this example use case may be initiated by the rApp 111-1 when the rApp 111-1 determines the need to write the configuration change information.

[0085] As illustrated in FIG. 5, at step 1, the rApp 111-1 may send, via an Open API, an HTTP PATCH request to the CM-related 0AM function 112-1. The HTTP PATCH request may be an API request that requests to write information associated with configuration changes in an NE, and may include an identifier (ID) of the rApp 111-1 (e.g., rAppId) and information associated with the desired configuration changes. The response of the 0 AM function 112-1 may be scoped by the information provided in the HTTP PATCH request.

[0086] At step 2, the CM-related 0AM function 112-1 may receive, from the rApp 111-1 via the Open API, the HTTP PATCH request, and then perform a CM operation based thereon. For instance, the CM-related 0AM function 112-1 may determine, based on the HTTP PATCH request (e.g., rAppId included in the request, etc.), whether or not the rApp 111-1 is authorized to read the requested configuration data. In some example implementations, the 0AM function 112- 1 may further validate the information provided in the HTTP PATCH request (e.g., whether or not the associated NE is available, etc.)

[0087] In this regard, based on determining that the rApp 111-1 is authorized, the flow diagram may proceed to step 3, at which the 0AM function 112-1 may create, based on the information provided in the HTTP PATCh request, a job (e.g., Write Configuration job) to write the information of the configuration changes in the NE. Accordingly, at step 4, the 0AM function 112-1 may provide, to the rApp 111-1 via the Open API, a message that includes the information of the created job, such as a job identifier (ID). In some example embodiments, the message may include an HTTP 200 OK success status response.

[0088] On the other hand, based on determining that the rApp 111-1 is not authorized, the flow diagram may proceed to step 5, at which the 0AM function 112-1 may provide, to the rApp 111-1 via the Open API, a message that includes error information, such as an error code, the reason(s) of the error, and the like.

[0089] Upon receiving the information of the created job (at step 4), the rApp 111-1 may utilize said information for querying or receiving information about the status and / or result of the created job. For instance, the rApp 111-1 may continuously (or periodically) send, to the 0AM function 112-1 via the Open API, a query (that includes the job ID) associated with the status of the created job. Upon receiving the query from the rApp 111-1, the 0AM function 112-1 may provide, to the rApp via the Open API, the status of the created job.

[0090] For instance, the status of the created job may include one of: a success status that indicates that all requested configuration changes information were written in the NE, a partial success status that indicates that a portion of the requested configuration changes information were written in the NE, and a failure status that indicates that none of the requested configuration changes information was written in the NE. In the case of partial success or failure, the statusprovided by the OAM function 112-1 may further include information associated with the reasons and / or the errors that prohibit the writing of all requested configuration changes information.

[0091] It is contemplated that the operations and use cases described herein are mere examples of the potential embodiments of the present disclosure, and the scope of the present disclosure should not be limited thereto.Examples of Device Components

[0092] One or more components of the system of the example embodiments (e.g., rApp 111-1, OAM function 112-1, etc.), as well as the operations associated therewith, may be implemented in one or more systems, devices, or hardware components, such as one or more servers, and the like. In the following, descriptions of a device in which the systems or components of the example embodiments may be implemented are provided. It is contemplated that one or more features, operations, and methods described above with reference to FIG. 2 to FIG. 5 may be performed by the device. For instance, the one or more operations or methods may be performed by at least one processor of the device upon executing machine-readable instructions or computer- readable instructions (e.g., instructions for implementing the operations described herein, etc., etc.) stored in a memory or a storage component of the device.

[0093] FIG. 6 illustrates an embodiment of a device 600. As shown in FIG. 6, the device 600 may include a processor 610, a memory 620, a storage component 630, an input component 640, an output component 650, a communication interface 660, and a bus 670.

[0094] The processor 610, as used herein, means any type of computational circuit that may comprise hardware elements and software elements. The processor 610 may be embodied as a multi-core processor, a single core processor, or a combination of one or more multi-core processors and / or one or more single core processors, a distributed processing system, or the like.The processor 610 may be a Central Processing Unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), an application-specific integrated circuit (ASIC), or another type of processing component.

[0095] Memory 620 includes a non-transitory computer readable medium. Memory 620 includes a random-access memory (RAM), a read only memory (ROM), and / or another type of dynamic or static storage device (e.g., a flash memory, a magnetic memory, and / or an optical memory) that stores information and / or instructions for use by processor 610. The memory 620 comprises machine-readable instructions which are executable by the processor 610. These machine-readable instructions when executed by the processor 610 cause the processor 610 to perform one or more method steps of an embodiment described above.

[0096] Storage component 630 stores information and / or software related to the operation and use of the device 600. For example, storage component 630 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, and / or a solid-state disk), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, a magnetic tape, and / or another type of non-transitory computer-readable medium, along with a corresponding drive.

[0097] Input component 640 is configured to receive information, such as user input. For example, the input component 640 may include, but not be limited to, a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, and / or a microphone. Additionally, or alternatively, the input component 640 may include a sensor for sensing information (e.g., a global positioning system (GPS), an accelerometer, a gyroscope, and / or an actuator).

[0098] Output component 650 is configured to provide output information from the device 600. For example, the output component 650 may be, but not limited to, a display, a speaker, instructions to an external device, and / or one or more light-emitting diodes (LEDs).

[0099] Communication interface 660 is an interface that provides a communication connection to other devices, such as external devices and internal devices. The connection by the communication interface 660 can be a wired connection, a wireless connection, or a combination of wired and wireless connections, and can be a direct connection or an indirect connection via a communication network that exists between the device 600 and other devices. In other words, the standard of the communication interface 660 is not limited.

[0100] The bus 670 acts as an interconnect between the processor 610, the memory 620, the storage component 630, the input component 640, the output component 650, and the communication interface 660 of the device 600. The bus 670 may include a wired interconnection or a wireless interconnection.

[0101] The number and arrangement of components shown in FIG. 6 are provided as an example. In practice, device 600 may include additional components, fewer components, different components, or differently arranged components than those shown in FIG. 6. Additionally, or alternatively, a set of components (e.g., one or more components) of device 600 may perform one or more functions described as being performed by another set of components of device 600. Further, one or more method steps described in any of the embodiments may be performed utilizing a plurality of devices 600 in communication with one another.Various Aspects of Embodiments

[0102] It is contemplated that the example embodiments described hereinabove with reference to FIG. 2 to FIG. 6 are merely examples of possible embodiments of the present disclosure, and are not intended to limit or restrict the scope of the present disclosure.

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

[0104] Some embodiments may relate to a device (e.g., network node, etc.), a system, a method, and / or a computer-readable medium at any possible technical detail level of integration. Further, one or more of the above components described above may be implemented as instructions stored on a computer-readable medium and executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include a computer-readable non-transitory storage medium (or media) having computer-readable program instructions thereon for causing a processor to carry out operations.

[0105] The computer-readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), electrically erasable programmable read-only memory (EEPROM), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer-readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic wavespropagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

[0106] Computer-readable program instructions described herein can be downloaded to respective computing / processing devices from a computer-readable storage medium or to an external computer or external storage device via a network, for example, 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 computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing / processing device.

[0107] Computer-readable program code / instructions for carrying out operations may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, including an object-oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the "C" programming language or similar programming languages.

[0108] The computer-readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the 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 connectionmay be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer-readable program instructions by utilizing state information of the computer- readable program instructions to personalize the electronic circuitry, in order to perform aspects or operations.

[0109] 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 block or blocks. These computer- readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer-readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function / act specified in the flowchart and / or block diagram block or blocks.

[0110] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices 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 block or blocks.

[0111] The flowchart and block diagrams in the Figures illustrate the architecture,functionality, and operation of possible implementations of systems, methods, and computer- readable media according to various embodiments. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). The method, computer system, and computer-readable medium may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in the Figures. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed concurrently or substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustration, and combinations of blocks in the block diagrams and / or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

[0112] It will be apparent that systems and / or methods, described herein, may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not limited to the implementations. Thus, the operation and behavior of the systems and / or methods were 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.

[0113] In view of the above, various further respective aspects and features of embodiments of the present disclosure may be defined by the following items:Item [1]: A system including: an Operations and Management (OAM) function and a Non-Real-Time (Non-RT) Radio Access Network (RAN) Intelligent Controller (RIC). The Non-RT RIC may be configured to implement at least one application (rApp). The rApp may be communicatively coupled to the OAM function via an Open Application Programming Interface (API) that may support two Hypertext Transfer Protocol (HTTP) operations. The rApp may be configured to send, to the OAM function via the Open API, an API request. The OAM function may be configured to receive the API request from the rApp via the Open API and perform, based on the API request, a configuration management (CM) operation.Item [2]: The system according to item [1], wherein the two HTTP operations supported by the Open API may include an HTTP GET operation and an HTTP PATCH operation.Item [3]: The system according to one of items [ l]-[2], wherein the Open API may not support the following HTTP operations: an HTTP PUT operation, an HTTP POST operation, and an HTTP DELETE operation.Item [4]: The system according to one of items

[0001] -[3], wherein the Open API may support at least the following data types: a Resource data type, a Scope data type, and a Patchitem data type.Item [5]: The system according to item [2], wherein the API request may include a request to perform the HTTP GET operation to read configuration data of a Network Element (NE), an identifier (ID) of the rApp, and information associated with the desired configuration data. The OAM function may be configured to perform the CM operation by: determining, based on the API request, whether or not the rApp is authorized to read theconfiguration data; based on determining that the rApp is authorized, providing, to the rApp via the Open API, a message that includes the configuration data; and based on determining that the rApp is not authorized, providing, to the rApp via the Open API, a message that includes error information.Item [6]: The system according to item [2], wherein the API request may include a request to perform the HTTP PATCH operation to write information associated with configuration changes in an NE, an ID of the rApp, and information associated with the desired configuration changes. The OAM function may be configured to perform the operation by: determining, based on the API request, whether or not the rApp is authorized to initiate the operation to write the configuration changes information; based on determining that the rApp is authorized, creating, based on the API request, a job to write the information of the configuration changes in the NE; providing, to the rApp via the Open API, a message that includes information associated with the created job; and based on determining that the rApp is not authorized, providing, to the rApp via the Open API, a message that includes error information.Item [7]: The system according to item [6], wherein the information associated with the created job may include a job ID. The rApp may be further configured to send, to the OAM function via the Open API, a query associated with the status of the created job, wherein the query may include the job ID. The OAM function may be further configured to provide, to the rApp via the Open API, the status of the created job, wherein the status of the created job may include one of: a success status that indicates all requested configuration changes information were written in the NE, a partial success status that indicates a portion of the requested configuration changes information were written in theNE, and a failure status that indicates none of the requested configuration changes information was written in the NE.Item [8]: A method including: providing, by at least one application (rApp) of a non-real-time (Non-RT) radio access network (RAN) intelligent controller (RIC) to an Operation and Management (OAM) function via an Open Application Programming Interface (API) that may support two Hypertext Transfer Protocol (HTTP) operations, an API request; receiving, by the OAM function via the Open API, the API request; and performing, by the OAM function based on the API request, a configuration management (CM) operation.Item [9]: The method according to item [8], wherein the two HTTP operations supported by the Open API may include an HTTP GET operation and an HTTP PATCH operation.Item

[0010] : The method according to any one of items [8]-[9], wherein the Open API may not support the following HTTP operations: an HTTP PUT operation, an HTTP POST operation, and an HTTP DELETE operation.Item

[0011] : The method according to any one of items [8]-

[0010] , wherein the Open API may support at least the following data types: a Resource data type, a Scope data type, and a Patchitem data type.Item

[0012] : The method according to item [9], wherein the API request may include a request to perform the HTTP GET operation to read configuration data of a Network Element (NE), an identifier (ID) of the rApp, and information associated with the desired configuration data. The performing the CM operation may include: determining, based on the API request, whether or not the rApp is authorized to read the configuration data; basedon determining that the rApp is authorized, providing, to the rApp via the Open API, a message that includes the configuration data; and based on determining that the rApp is not authorized, providing, to the rApp via the Open API, a message that includes error information.Item

[0013] : The method according to item [9], wherein the API request may include a request to perform the HTTP PATCH operation to write information associated with configuration changes in an NE, an ID of the rApp, and information associated with the desired configuration changes. The performing the CM operation may include: determining, based on the API request, whether or not the rApp is authorized to initiate the operation to write the configuration changes; based on determining that the rApp is authorized, creating, based on the API request, a job to write the information of the configuration changes in the NE; providing, to the rApp via the Open API, a message that includes information associated with the created job; and based on determining that the rApp is not authorized, providing, to the rApp via the Open API, a message that includes error information.Item

[0014] : The method according to item

[0013] , wherein the information associated with the created job may include a job ID, and wherein the method may further include: sending, by the rApp to the OAM function via the Open API, a query associated with the status of the created job, wherein the query may include the job ID; and providing, by the OAM function to the rApp via the Open API, the status of the created job, wherein the status of the created job may include one of: a success status that indicates all requested configuration changes information were written in the NE, a partial success status that indicates a portion of the requested configuration changes information were written in theNE, and a failure status that indicates none of the requested configuration changes information was written in the NE.Item

[0015] : A non-transitory computer-readable recording medium having recorded thereon instructions executable by a system that may include a non-real-time (Non-RT) radio access network (RAN) intelligent controller (RIC) and an Operation and Management (OAM) function to cause the system to perform a method including: providing, by at least one application (rApp) of a non-real-time (Non-RT) radio access network (RAN) intelligent controller (RIC) to an Operation and Management (OAM) function via an Open Application Programming Interface (API) that may support two Hypertext Transfer Protocol (HTTP) operations, an API request; receiving, by the OAM function via the Open API, the API request; and performing, by the OAM function based on the API request, a configuration management (CM) operation.Item

[0016] : The non-transitory computer-readable recording medium according to item

[0015] , wherein the two HTTP operations supported by the Open API may include an HTTP GET operation and an HTTP PATCH operation.Item

[0017] : The non-transitory computer-readable recording medium according to any one of items

[0015] -

[0016] , wherein the Open API may not support the following HTTP operations: an HTTP PUT operation, an HTTP POST operation, and an HTTP DELETE operation.Item

[0018] : The non-transitory computer-readable recording medium according to any one of items

[0015] -

[0017] , wherein the Open API may support at least the following data types: a Resource data type, a Scope data type, and a Patchitem data type.Item

[0019] : The non-transitory computer-readable recording medium according to item

[0016] , wherein the API request may include a request to perform the HTTP GET operation to read configuration data of a Network Element (NE), an identifier (ID) of the rApp, and information associated with the desired configuration data. The performing the CM operation may include: determining, based on the API request, whether or not the rApp is authorized to read the configuration data; based on determining that the rApp is authorized, providing, to the rApp via the Open API, a message that includes the configuration data; and based on determining that the rApp is not authorized, providing, to the rApp via the Open API, a message that includes error information.Item

[0020] : The non-transitory computer-readable recording medium according to item

[0016] , wherein the API request may include a request to perform the HTTP PATCH operation to write information associated with configuration changes in an NE, an ID of the rApp, and information associated with the desired configuration changes. The performing the CM operation may include: determining, based on the API request, whether or not the rApp is authorized to initiate the operation to write the configuration changes; based on determining that the rApp is authorized, creating, based on the API request, a job to write the information of the configuration changes in the NE; providing, to the rApp via the Open API, a message that includes information associated with the created job; and based on determining that the rApp is not authorized, providing, to the rApp via the Open API, a message that includes error information.

[0114] It can be understood that numerous modifications and variations of the present disclosure are possible in light of the above teachings. It will be apparent that within the scope ofthe appended clauses, the present disclosures may be practiced otherwise than as specifically described herein.

Claims

What is claimed is:

1. A system comprising: an Operations and Management (OAM) function; and a Non-Real-Time (Non-RT) Radio Access Network (RAN) Intelligent Controller (RIC), wherein the Non-RT RIC is configured to implement at least one application (rApp), wherein the rApp is communicatively coupled to the OAM function via an Open Application Programming Interface (API) that supports two Hypertext Transfer Protocol (HTTP) operations, wherein the rApp is configured to send, to the OAM function via the Open API, an API request, wherein the OAM function is configured to receive the API request from the rApp via the Open API and perform, based on the API request, a configuration management (CM) operation.

2. The system according to claim 1, wherein the two HTTP operations supported by the Open API comprise an HTTP GET operation and an HTTP PATCH operation.

3. The system according to claim 1, wherein the Open API does not support the following HTTP operations: an HTTP PUT operation, an HTTP POST operation, and an HTTP DELETE operation.

4. The system according to claim 1, wherein the Open API supports at least the following data types: a Resource data type, a Scope data type, and a Patchitem data type.

5. The system according to claim 2, wherein the API request comprises a request to perform the HTTP GET operation to read configuration data of a Network Element (NE), an identifier (ID) of the rApp, and information associated with the desired configuration data, and wherein the OAM function is configured to perform the CM operation by: determining, based on the API request, whether or not the rApp is authorized to read the configuration data; based on determining that the rApp is authorized, providing, to the rApp via the Open API, a message that includes the configuration data; and based on determining that the rApp is not authorized, providing, to the rApp via the Open API, a message that includes error information.

6. The system according to claim 2, wherein the API request comprises a request to perform the HTTP PATCH operation to write information associated with configuration changes in an NE, an ID of the rApp, and information associated with the desired configuration changes, and wherein the OAM function is configured to perform the operation by: determining, based on the API request, whether or not the rApp is authorized to initiate the operation to write the configuration changes information;based on determining that the rApp is authorized, creating, based on the API request, a job to write the information of the configuration changes in the NE; providing, to the rApp via the Open API, a message that includes information associated with the created job; and based on determining that the rApp is not authorized, providing, to the rApp via the Open API, a message that includes error information.

7. The system according to claim 6, wherein the information associated with the created job comprises a job ID; wherein the rApp is further configured to send, to the OAM function via the Open API, a query associated with the status of the created job, wherein the query includes the job ID; wherein the OAM function is further configured to provide, to the rApp via the Open API, the status of the created job; and wherein the status of the created job comprises one of: a success status that indicates all requested configuration changes information were written in the NE, a partial success status that indicates a portion of the requested configuration changes information were written in the NE, and a failure status that indicates none of the requested configuration changes information was written in the NE.

8. A method comprising: providing, by at least one application (rApp) of a non-real-time (Non-RT) radio access network (RAN) intelligent controller (RIC) to an Operation and Management (OAM)function via an Open Application Programming Interface (API) that supports two Hypertext Transfer Protocol (HTTP) operations, an API request; receiving, by the OAM function via the Open API, the API request; and performing, by the OAM function based on the API request, a configuration management (CM) operation.

9. The method according to claim 8, wherein the two HTTP operations supported by the Open API comprise an HTTP GET operation and an HTTP PATCH operation.

10. The method according to claim 8, wherein the Open API does not support the following HTTP operations: an HTTP PUT operation, an HTTP POST operation, and an HTTP DELETE operation.

11. The method according to claim 8, wherein the Open API supports at least the following data types: a Resource data type, a Scope data type, and a Patchitem data type.

12. The method according to claim 9, wherein the API request comprises a request to perform the HTTP GET operation to read configuration data of a Network Element (NE), an identifier (ID) of the rApp, and information associated with the desired configuration data, and wherein the performing the CM operation comprises: determining, based on the API request, whether or not the rApp is authorized to read the configuration data;based on determining that the rApp is authorized, providing, to the rApp via the Open API, a message that includes the configuration data; and based on determining that the rApp is not authorized, providing, to the rApp via the Open API, a message that includes error information.

13. The method according to claim 9, wherein the API request comprises a request to perform the HTTP PATCH operation to write information associated with configuration changes in an NE, an ID of the rApp, and information associated with the desired configuration changes, and wherein the performing the CM operation comprises: determining, based on the API request, whether or not the rApp is authorized to initiate the operation to write the configuration changes; based on determining that the rApp is authorized, creating, based on the API request, a job to write the information of the configuration changes in the NE; providing, to the rApp via the Open API, a message that includes information associated with the created job; and based on determining that the rApp is not authorized, providing, to the rApp via the Open API, a message that includes error information.

14. The method according to claim 13, wherein the information associated with the created job comprises a job ID; wherein the method further comprises:sending, by the rApp to the OAM function via the Open API, a query associated with the status of the created job, wherein the query includes the job ID; and providing, by the OAM function to the rApp via the Open API, the status of the created job, wherein the status of the created job comprises one of: a success status that indicates all requested configuration changes information were written in the NE, a partial success status that indicates a portion of the requested configuration changes information were written in the NE, and a failure status that indicates none of the requested configuration changes information was written in the NE.

15. A non-transitory computer-readable recording medium having recorded thereon instructions executable by a system that comprise a non-real-time (Non-RT) radio access network (RAN) intelligent controller (RIC) and an Operation and Management (OAM) function to cause the system to perform a method comprising: providing, by at least one application (rApp) of the Non-RT RIC to the OAM function via an Open Application Programming Interface (API) that supports two Hypertext Transfer Protocol (HTTP) operations, an API request; receiving, by the OAM function via the Open API, the API request; and performing, by the OAM function based on the API request, a configuration management (CM) operation.

16. The non-transitory computer-readable recording medium according to claim 15, wherein the two HTTP operations supported by the Open API comprise an HTTP GET operation and an HTTP PATCH operation.

17. The non-transitory computer-readable recording medium according to claim 15, wherein the Open API does not support the following HTTP operations: an HTTP PUT operation, an HTTP POST operation, and an HTTP DELETE operation.

18. The non-transitory computer-readable recording medium according to claim 15, wherein the Open API supports at least the following data types: a Resource data type, a Scope data type, and a Patchitem data type.

19. The non-transitory computer-readable recording medium according to claim 16, wherein the API request comprises a request to perform the HTTP GET operation to read configuration data of a Network Element (NE), an identifier (ID) of the rApp, and information associated with the desired configuration data, and wherein the performing the CM operation comprises: determining, based on the API request, whether or not the rApp is authorized to read the configuration data; based on determining that the rApp is authorized, providing, to the rApp via the Open API, a message that includes the configuration data; and based on determining that the rApp is not authorized, providing, to the rApp via the Open API, a message that includes error information.

0. The non-transitory computer-readable recording medium according to claim 16, wherein the API request comprises a request to perform the HTTP PATCH operation to write information associated with configuration changes in an NE, an ID of the rApp, and information associated with the desired configuration changes, and wherein the performing the CM operation comprises: determining, based on the API request, whether or not the rApp is authorized to initiate the operation to write the configuration changes; based on determining that the rApp is authorized, creating, based on the API request, a job to write the information of the configuration changes in the NE; providing, to the rApp via the Open API, a message that includes information associated with the created job; and based on determining that the rApp is not authorized, providing, to the rApp via the Open API, a message that includes error information.

Images