System and method for implementing writing configuration changes in a non-real-time radio access network intelligence controller (NRT-RIC) architecture in a communication network

Abstract

A system and method for implementing writing configuration changes in a Non-Real-Time Radio Access Network Intelligence Controller (NRT-RIC) architecture including a Service Management and Orchestration (SMO) framework in an Open Radio Access Network (O-RAN) and an NRT-RIC framework is provided. The method includes receiving at least one request to write configuration changes to one or more O-RAN Operations and Maintenance (OAM) related functions, authorizing the at least one request to write configuration changes to the one or more O-RAN OAM related functions from an rApp, validating information provided in the at least one request to write configuration changes to the one or more O-RAN OAM related functions, generating a job for writing the configuration changes based on the information provided in the at least one request to write configuration changes to the one or more O-RAN OAM related functions, and sending a job identifier comprising information about the job to the rApp.

Description

[Technical Field]

[0001] [CROSS REFERENCE TO RELATED APPLICATIONS] This application claims priority to U.S. Provisional Patent Application No. 63 / 452,821, filed March 17, 2023, the disclosure of which is incorporated herein by reference in its entirety.

[0002] [Technical field] Apparatus and methods consistent with embodiments of the present disclosure relate to implementing writing configuration changes in a Non-Real-Time Radio Access Network Intelligence Controller (NRT-RIC) architecture comprising a Service Management and Orchestration (SMO) framework and an NRT-RIC framework in an Open Radio Access Network (O-RAN). [Background technology]

[0003] The Radio Access Network (RAN) is a critical component in a communication system that connects end-user devices (or user equipment) to the rest of the network. The RAN includes a combination of various network elements (NEs) that connect end-user devices to the core network. Traditionally, the hardware and / or software of a particular RAN has been vendor-specific.

[0004] The emergence of Open RAN (O-RAN) technology allows multiple vendors to provide hardware and / or software for communication systems. To this end, O-RAN decomposes RAN functions into a centralized unit (CU), distributed units (DUs), and radio units (RUs). The CU is a logical node for hosting the RAN sublayers of Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and / or Packet Data Convergence Protocol (PDCP). The DU is a logical node for hosting the RAN sublayers of Radio Link Control (RLC), Medium Access Control (MAC), and Physical (PHY). The RU is a physical node that converts radio signals from the antenna into digital signals that can be transmitted over the fronthaul to the DU. These entities can be developed by different vendors because of the open protocols and interfaces between them.

[0005] Figure 1 illustrates an O-RAN architecture in the related art. Referring to Figure 1, RAN functions in the O-RAN architecture are controlled and optimized by RICs. RICs are software-defined components that implement modular applications to realize the multi-vendor operability required in O-RAN systems and automate and optimize RAN operations. RICs are divided into two types: non-real-time RICs (NRT-RICs) and near-real-time RICs (nRT-RICs).

[0006] The NRT-RIC is the control point for non-real-time control loops and operates on sub-second timescales within a Service Management and Orchestration (SMO) framework. Its functions are implemented through modular applications called rApps (rApp 1, ..., rApp N) and include providing policy-based guidance and enrichment over the A1 interface, which is the interface enabling communication between the NRT-RIC and nRT-RIC; performing data analytics; artificial intelligence / machine learning (AI / ML) training and inference for RAN optimization; and / or recommending configuration management actions over the O1 interface, which is the interface connecting the SMO to RAN management elements (e.g., nRT-RIC, O-RAN aggregation unit (O-CU), O-RAN distributed unit (O-DU), etc.).

[0007] The nRT-RIC operates on a time scale between 10 milliseconds and 1 second and connects 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 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) through policies. For example, the nRT-RIC sets policy parameters on the activated functions of the E2 nodes. Furthermore, the nRT-RIC hosts xApps for implementing functions such as quality of service (QoS), mobility optimization, slicing optimization, interference mitigation, load balancing, and security. The two types of RICs work together to optimize the O-RAN. For example, the NRT-RIC provides policies, data, and AI / ML models over the A1 interface that are enabled and used by the nRT-RIC for RAN optimization, and the nRT-RIC returns policy feedback (i.e., how the policies set by the NRT-RIC are working).

[0008] The SMO framework in which the NRT-RIC resides manages and coordinates RAN elements. Specifically, the SMO manages and coordinates what is referred to as the O-RAN Cloud (O-Cloud). The O-Cloud is a collection of physical RAN nodes that host the RIC, O-CU, O-DU, supporting software components (e.g., operating systems and runtime environments), and the SMO itself. In other words, the SMO manages the O-Cloud from within. The O2 interface is the interface between the SMO and the O-Cloud in which it resides. Through the O2 interface, the SMO provides Infrastructure Management Services (IMS) and Deployment Management Services (DMS). Summary of the Invention [Problem to be solved by the invention]

[0009] On the other hand, the O-Cloud is a cloud computing platform that comprises a collection of physical infrastructure nodes that meet the O-RAN requirements for hosting the relevant O-RAN functions (nRT-RIC, O-CU-CP, O-CU-UP, O-DU, etc.), supporting software components (operating systems, virtual machine monitors, container runtimes, etc.), and appropriate management and orchestration functions.

[0010] The SMO framework in which the NRT-RIC resides manages and coordinates RAN elements. The SMO performs the following services: management and orchestration of RAN elements through four key interfaces to O-RAN elements: A1 interface between NRT-RIC and nRT-RIC in the SMO for RAN optimization; O1 interface between SMO and O-RAN network functions for FCAPS support; open fronthaul M-plane interface between SMO and O-RU for FCAPS support in case of hybrid model; O2 interface between SMO and O-Cloud for platform resource and workload management.

[0011] In the related art, there is no standardized communication by which an rApp sends at least one request to write a configuration change to one or more O-RAN operations and maintenance (OAM) related functions via the R1 interface between the rApp and the non-anchor functions of the SMO framework and the NRT-RIC framework.

[0012] As a result, communication between rApps requesting write requests to change configurations to one or more O-RAN operations and maintenance (OAM) related functions and non-anchor functions of the SMO framework and NRT-RIC framework may not facilitate the multi-vendor operability desired in O-RAN systems. [Means for solving the problem]

[0013] According to embodiments, an apparatus and method are provided for implementing writing configuration changes in a Non-Real-Time Radio Access Network Intelligence Controller (NRT-RIC) architecture, including a Service Management and Orchestration (SMO) framework and an NRT-RIC framework in an Open Radio Access Network (O-RAN). The implementation of writing configuration changes enables network operators to effectively manage (standardize) rApps from multiple vendors to facilitate the multi-vendor operability required in the O-RAN NRT-RIC architecture.

[0014] To this end, the implementation of writing configuration changes comprises authorization and validation to generate a job (e.g., a job ticket) for writing the configuration change to one or more O-RAN operations and maintenance (OAM) related functions.

[0015] As a result, communication between rApps requesting write requests to change configurations to one or more O-RAN operations and maintenance (OAM) related functions based on authorization and validation to generate jobs (e.g., job tickets) and non-anchor functions of the SMO framework and NRT-RIC framework is standardized.

[0016] The apparatus includes a non-real-time radio access network intelligence controller (NRT-RIC) configured to receive, from an rApp, at least one request to write a configuration change to one or more O-RAN operations and maintenance (OAM)-related functions via an R1 interface between the rApp and the NRT-RIC framework. The apparatus authorizes the at least one request from the rApp to write a configuration change to one or more O-RAN OAM-related functions. The apparatus, based on the authorization, verifies information provided in the at least one request to write a configuration change to one or more O-RAN OAM-related functions. The apparatus, based on the verification, generates a job for writing the configuration change based on the information provided in the at least one request to write a configuration change to one or more O-RAN OAM-related functions. Based on the job generation, the apparatus sends a job identifier comprising information about the job to the rApp via the NRT-RIC framework and the R1 interface.

[0017] According to one embodiment, a method is provided for implementing writing configuration changes in a Non-Real-Time Radio Access Network Intelligence Controller (NRT-RIC) architecture that includes a Service Management and Orchestration (SMO) framework and an NRT-RIC framework in an Open Radio Access Network (O-RAN). The method includes receiving, from the rApp, at least one request to write a configuration change to one or more O-RAN operations and maintenance (OAM) related functions via an R1 interface between the rApp and an NRT-RIC framework; authorizing, by the NRT-RIC framework, the at least one request from the rApp to write the configuration change to the one or more O-RAN OAM related functions; based on the authorization, verifying, by the one or more O-RAN OAM related functions, information provided in the at least one request to write the configuration change to the one or more O-RAN OAM related functions; based on the verifying, generating, by the one or more O-RAN OAM related functions, a job for writing the configuration change based on the information provided in the at least one request to write the configuration change to the one or more O-RAN OAM related functions; and based on generating the job, sending, by the one or more O-RAN OAM related functions via the NRT-RIC framework and via the R1 interface, a job identifier including information about the job to the rApp.

[0018] According to one embodiment, a non-transitory computer-readable storage medium having instructions executable by at least one processor to perform a method for implementing writing configuration changes in a Non-Real-Time Radio Access Network Intelligence Controller (NRT-RIC) architecture including a Service Management and Orchestration (SMO) framework and an NRT-RIC framework in an Open Radio Access Network (O-RAN) is provided. The method includes receiving, from the rApp, at least one request to write a configuration change to one or more O-RAN operations and maintenance (OAM) related functions via an R1 interface between the rApp and an NRT-RIC framework; authorizing, by the NRT-RIC framework, the at least one request from the rApp to write the configuration change to the one or more O-RAN OAM related functions; based on the authorization, verifying, by the one or more O-RAN OAM related functions, information provided in the at least one request to write the configuration change to the one or more O-RAN OAM related functions; based on the verifying, generating, by the one or more O-RAN OAM related functions, a job for writing the configuration change based on the information provided in the at least one request to write the configuration change to the one or more O-RAN OAM related functions; and based on generating the job, sending, by the one or more O-RAN OAM related functions via the NRT-RIC framework and via the R1 interface, a job identifier including information about the job to the rApp.

[0019] Additional aspects will be set forth in part in the description that follows, and in part will be obvious from the description, or may be realized by practice of the presented embodiments of the present disclosure. [Brief explanation of the drawings]

[0020] Features, aspects, and advantages of certain exemplary embodiments of the disclosure are described below with reference to the accompanying drawings, in which like reference numerals represent like elements.

[0021] FIG. 1 illustrates an O-RAN architecture in the related art.

[0022] FIG. 2 is a diagram of an example environment in which the systems and / or methods described herein may be implemented.

[0023] FIG. 3 is a diagram of example components of a device according to one embodiment.

[0024] FIG. 4 illustrates an NRT-RIC architecture comprising a non-anchor function of the SMO framework and the NRT-RIC framework in the O-RAN, according to one embodiment.

[0025] FIG. 5 illustrates an operational flow between an rApp and non-anchor functions of the SMO framework and the NRT-RIC framework, according to one embodiment.

[0026] FIG. 6 illustrates a method for implementing writing configuration changes in an SMO framework with an NRT-RIC framework in an open radio access network (O-RAN), according to one embodiment.

[0027] FIG. 7 illustrates a method for authorizing at least one request from an rApp to write a configuration change to one or more O-RAN OAM-related functions, according to one embodiment.

[0028] FIG. 8 illustrates a method for validating information provided in at least one request to write a configuration change to one or more O-RAN OAM-related functions, according to one embodiment.

[0029] FIG. 9 illustrates a method for creating a job for writing configuration changes according to one embodiment.

[0030] FIG. 10 illustrates a method for receiving at least one job query over an R1 interface in an O-RAN architecture between an rApp and an NRT-RIC framework according to one embodiment.

[0031] FIG. 11 illustrates an operational flow between an rApp and an NRT-RIC according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

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

[0033] The foregoing disclosure provides illustrations and descriptions, but is not intended to be exhaustive or to limit implementations to the precise form disclosed. Modifications and variations are possible in light of the foregoing disclosure or may be acquired from practice of implementations. Furthermore, one or more features or components of one embodiment may be combined or combined with other embodiments (or one or more features of other embodiments). Additionally, in the flowcharts and operational descriptions 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 concurrently (at least in part), or the order of one or more operations may be rearranged.

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

[0035] Although particular feature combinations are recited in the claims and / or disclosed in the specification, these combinations are not intended to limit the disclosure of possible implementations. Indeed, many of these features may be combined in ways other than those specifically recited in the claims and / or specifically disclosed in the specification. Although each dependent claim listed below may depend directly on only one claim, the disclosure of possible implementations includes each dependent claim in combination with all other claims in the claim group.

[0036] No element, act, or instruction used herein should be construed as critical or required unless explicitly stated otherwise. 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." Where only one item is intended, the term "one" or similar words are used. Also, as used herein, the terms "has," "have," "having," "include," "including," etc. are intended to be open-ended terms. Furthermore, the phrase "based on" is intended to mean "based, at least in part, on," unless expressly stated otherwise. Furthermore, phrases such as "at least one of A and B" or "at least one of A or B" are understood to include A only, B only, or both A and B.

[0037] 2 is a diagram of an example environment 200 in which the systems and / or methods described herein may be implemented. As shown in FIG. 2, environment 200 may include a user device 210, a platform 220, and a network 230. The devices in environment 200 may be interconnected via wired connections, wireless connections, or a combination of wired and wireless connections. In an embodiment, any of the functions and operations described below with reference to FIGS. 4-10 below may be performed by any combination of the elements illustrated in FIG. 3.

[0038] User device 210 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information related to platform 220. For example, user device 210 may include a computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a handheld computer, a smart speaker, a server, etc.), a mobile phone (e.g., a smartphone, a wireless phone), a wearable device (e.g., smart glasses or a smart watch), or a similar device. In some implementations, user device 210 may receive information from and / or send information to platform 220.

[0039] Platform 220 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information. In some implementations, platform 220 may include a cloud server or a group of cloud servers. In some implementations, platform 220 may be designed to be modular, such that particular software components may be swapped in or out depending on particular needs. In this manner, platform 220 may be easily and / or quickly reconfigured for different uses.

[0040] In some implementations, as shown, platform 220 may be hosted in a cloud computing environment 222. Note that although the implementations described herein describe platform 220 as being hosted in a cloud computing environment 222, in some implementations platform 220 may not be cloud-based (i.e., may be implemented outside of a cloud computing environment) or may be partially cloud-based.

[0041] Cloud computing environment 222 includes an environment that hosts platform 220. Cloud computing environment 222 may provide services such as computation, software, data access, storage, etc., without requiring end-user (e.g., user device 210) knowledge of the physical location and configuration of the systems and / or devices that host platform 220. As shown, cloud computing environment 222 may include a group of computing resources 224 (collectively referred to as “computing resources 224” and individually referred to as “computing resource 224”).

[0042] Computing resources 224 may include one or more personal computers, clusters of computing devices, workstation computers, server devices, or other types of computation and / or communication devices. In some implementations, computing resources 224 may host platform 220. Cloud resources may include compute instances executing on computing resources 224, storage devices provided on computing resources 224, data transfer devices provided by computing resources 224, etc. In some implementations, computing resources 224 may communicate with other computing resources 224 via wired connections, wireless connections, or a combination of wired and wireless connections.

[0043] As further shown in FIG. 2, computing resources 224 include a group of cloud resources such as one or more applications (“APP”) 224-1, one or more virtual machines (“VM”) 224-2, virtualized storage (“VS”) 224-3, and one or more hypervisors (“HYP”) 224-4.

[0044] Application 224-1 includes one or more software applications that may be provided to or accessed by user device 210. Application 224-1 may obviate the need to install and run a software application on user device 210. For example, application 224-1 may include software associated with platform 220 and / or any other software that may be provided via cloud computing environment 222. In some implementations, one application 224-1 may send or receive information to or from one or more other applications 224-1 via virtual machine 224-2.

[0045] Virtual machine 224-2 includes a software implementation of a device (e.g., a computer) that executes programs like a physical device. Virtual machine 224-2 may be a system virtual machine or a process virtual machine, depending on the use by virtual machine 224-2 and the degree of correspondence with any real-world device. A system virtual machine may provide a complete system platform that supports the execution of a complete operating system (“OS”). A process virtual machine may execute a single program or support a single process. In some implementations, virtual machine 224-2 may execute on behalf of a user (e.g., user device 210) and manage the infrastructure of cloud computing environment 222, such as data management, synchronization, or long-term data transfer.

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

[0047] Hypervisor 224-4 may provide hardware virtualization technology that allows multiple operating systems (e.g., "guest operating systems") to run simultaneously on a host computer, such as computing resource 224. Hypervisor 224-4 may present a virtual operating platform to the guest operating systems and may manage the execution of the guest operating systems. Multiple instances of different operating systems may share virtualized hardware resources.

[0048] Network 230 may include one or more wired and / or wireless networks. For example, network 230 may include a cellular network (e.g., a fifth-generation (5G) network, a long-term evolution (LTE) network, a third-generation (3G) network, a code division multiple access (CDMA) network, etc.), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., a public switched telephone network (PSTN), a private network, an ad hoc network, an intranet, the Internet, an optical fiber-based network, etc.), and / or a combination of these or other types of networks.

[0049] The number and arrangement of devices and networks shown in Figure 2 are provided as an example. In practice, there may be additional, fewer, different, or differently arranged devices and / or networks than those shown in Figure 2. Furthermore, two or more devices shown in Figure 2 may be implemented within a single device, and a single device shown in Figure 2 may be implemented as multiple distributed devices. Additionally or alternatively, a set of devices in environment 200 (e.g., one or more devices) may perform one or more functions that are described as being performed by other sets of devices in environment 200.

[0050] 3 is a diagram of example components of a device 300. The device 300 may correspond to the user device 210 and / or the platform 220. As shown in FIG. 3, the device 300 may include a bus 310, a processor 320, a memory 330, a storage component 340, an input component 350, an output component 360, and a communication interface 370.

[0051] The bus 310 includes components that enable communication between the components of the device 300. The processor 320 may be implemented in hardware, firmware, or a combination of hardware and software. The processor 320 may be a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or other type of processing component. In some implementations, the processor 320 includes one or more processors that are programmable to perform functions. The memory 330 includes random access memory (RAM), read-only memory (ROM), and / or other types of dynamic or static storage devices (e.g., flash memory, magnetic memory, and / or optical memory) that store information and / or instructions for use by the processor 320.

[0052] Storage component 340 stores information and / or software related to the operation and use of device 300. For example, storage component 340 may include a hard disk (e.g., a magnetic disk, optical disk, magneto-optical disk, and / or solid-state disk), a compact disk (CD), a digital versatile disk (DVD), a floppy disk, a cartridge, magnetic tape, and / or other type of non-transitory computer-readable medium, along with a corresponding drive. Input component 350 includes components that enable device 300 to receive information, such as via user input (e.g., a touchscreen display, a keyboard, a keypad, a mouse, buttons, switches, and / or a microphone). Additionally or alternatively, input component 350 may include sensors for measuring information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, and / or an actuator). Output component 360 includes components that provide output information from device 300 (e.g., a display, a speaker, and / or one or more light-emitting diodes (LEDs)).

[0053] Communications interface 370 includes transceiver-like components (e.g., a transceiver and / or a separate receiver and transmitter) that allow device 300 to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. Communications interface 370 allows device 300 to receive information from and / or provide information to other devices. For example, communications interface 370 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.

[0054] Device 300 may perform one or more processes described herein. Device 300 may perform these processes in response to processor 320 executing software instructions stored by a non-transitory computer-readable medium, such as memory 330 and / or storage component 340. A computer-readable medium is defined herein as a non-transitory memory device. A memory device includes memory space within a single physical storage device or memory space distributed across multiple physical storage devices.

[0055] The software instructions may be loaded into memory 330 and / or storage component 340 from other computer-readable media or other devices via communication interface 370. When executed, the software instructions stored in memory 330 and / or storage component 340 may cause processor 320 to perform one or more of the processes described herein.

[0056] Additionally or alternatively, hardwired circuitry may be used in place of, or in combination with, software instructions to implement one or more processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.

[0057] The number and arrangement of components shown in Figure 3 are provided as an example. In practice, device 300 may include additional, fewer, different, or differently arranged components than those shown in Figure 3. Additionally or alternatively, a set of components (e.g., one or more components) of device 300 may perform one or more functions that are described as being performed by other sets of components of device 300.

[0058] In an embodiment, any of the operations or processes of FIGS. 4-10 may be implemented by or using any of the elements illustrated in FIGS.

[0059] FIG. 4 illustrates an NRT-RIC architecture (or platform) and rApps hosted by the NRT-RIC with respect to the R1 interface within the SMO framework system architecture and the O1, O2, and A1 interfaces within the O-RAN, according to one embodiment.

[0060] Referring to FIG. 4, the NRT-RIC represents a subset of the SMO framework functions (i.e., functions anchored within the NRT-RIC framework, functions anchored outside the NRT-RIC framework, and functions that are not anchored (i.e., non-anchor functions)). The NRT-RIC has access to other SMO framework functions and affects (i.e., controls and / or executes) what is transmitted across at least one of the O1 interface, the fronthaul M-Plane interface, and the O2 interface for the O-CU, O-DU, O-RU, near-RT RIC, etc. (e.g., performs configuration management (CM) and / or performance management (PM)).

[0061] The NRT-RIC includes an NRT-RIC framework. The NRT-RIC framework includes, among other functions, an R1 Service Management and Exposure (SME) function that handles the R1 services provided in accordance with the present embodiment. For example, the SME function performs authorization and attestation in a gatekeeper role within the NRT-RIC framework. Additionally, the SME function may cooperate with non-anchored functions (i.e., non-anchor functions) to authorize and attest rApps or perform rApp requests, such as writing configuration changes to one or more O-RAN operation and maintenance (OAM) related functions.

[0062] Generally, the NRT-RIC functions within the NRT-RIC framework support authorization, certification, registration, discovery, communication support, etc. for rApps.

[0063] An NRT-RIC application (rApp) is an application that leverages the functionality available in the NRT-RIC framework and / or the SMO framework to provide value-added services related to RAN operation and optimization. The scope of an rApp includes, but is not limited to, radio resource management, data analytics, and other information enrichment. For example, an rApp may request to write configuration changes to one or more O-RAN OAM-related functions.

[0064] To this end, the NRT-RIC framework produces and / or consumes an R1 service according to an embodiment via an R1 interface. The R1 interface terminates at an R1 termination of the NRT-RIC framework. The R1 termination connects the NRT-RIC framework and the rApp via the R1 interface, allowing the NRT-RIC framework and the rApp to exchange messages / data (i.e., requests and responses configured according to a data model) to access the R1 service via the R1 interface.

[0065] Furthermore, the NRT-RIC framework includes A1-related functions, such as supporting A1 logical termination, A1 policy coordination and catalog, and A1-EI coordination and catalog.

[0066] The Data Management and Exposure Services within the NRT-RIC framework transmit data generated or collected by data producers to data consumers according to their needs (e.g., Function Management (FM) / Configuration Management (CM) / Production Management (PM) data for rApps, or CM changes from rApps to O-RAN via the O1 interface).

[0067] The NRT-RIC framework further comprises an external termination, which supports the exchange of data between the NRT-RIC framework and, for example, external AI / ML functions, enrichment information (EI) sources, or external oversight.

[0068] Within the NRT-RIC framework, AI / ML workflow services provide access to AI / ML workflows. For example, AI / ML workflow services may assist with model training, monitoring of AI / ML models deployed in the NRT-RIC, etc.

[0069] Additionally, the NRT-RIC framework provides A2 related functions that support, for example, A2 logical termination, A2 policy coordination and catalogs.

[0070] Still referring to Figure 4, within the NRT-RIC framework, the R1 interface is an open logical interface within the O-RAN architecture between rApps and the NRT-RIC framework of the NRT-RIC. The R1 interface supports the exchange of control signaling information and the collection and delivery of data between endpoints. The R1 interface allows, for example, multi-vendor rApps to consume and / or produce R1 services.

[0071] The R1 interface is independent of the specific implementation of the NRT-RIC framework of the SMO and NRT-RIC. The R1 interface is defined in an extensible manner that allows new services and data types to be added without having to change protocols or procedures.

[0072] In particular, the R1 interface facilitates interconnection between rApps and NRT-RIC frameworks provided by different vendors (i.e., facilitates interconnection in a multi-vendor environment). To this end, the R1 interface provides a level of abstraction between rApps and the NRT-RIC and / or SMO frameworks.

[0073] The R1 application protocol framework, according to one embodiment, specifies R1 services and associated service procedures and API definitions.

[0074] For example, R1 services and related service procedures may include R1 Service Management and Exposure (SME) services, R1 Data Management and Exposure (DME) services, R1-A1 services, R1-O1 services, R1-O2 data services, R1-AIML services, R1 services over the fronthaul M-Plane, etc.

[0075] To this end, logical functions that create RAN OAM-related services exposed to rApps over the R1 interface are referred to as O-RAN operation and maintenance (OAM)-related functions. For example, an O-RAN OAM-related function may realize the creation of O-RAN OAM-related services exposed to rApps over the R1 interface, where at least one of the services may comprise performing CM conflict mitigation and, for example, interfacing with near-RT RIC and E2 nodes through O1 termination, interfacing with O-RUs through open fronthaul M-plane termination, and interfacing with RAN-specific slice management functions in the SMO framework.

[0076] Interfacing with the near-RT RIC and E2 nodes through the O1 termination may comprise O-RAN OAM-related functions receiving fault notifications and retrieving alarm lists from the near-RT RIC and E2 nodes (i.e., E2 O-RU), provisioning configuration changes to the near-RT RIC and E2 nodes, and collecting performance data from the near-RT RIC and E2 nodes.

[0077] Interfacing with the O-RU through the open fronthaul M-plane termination may comprise RAN OAM-related functions receiving fault notifications and retrieving alarm lists from the O-RU, provisioning configuration changes to the O-RU, and collecting performance data from the O-RU.

[0078] Interfacing with RAN-specific slice management functions in the SMO framework may comprise RAN OAM-related functions provisioning configuration changes with respect to RAN-specific network slicing and collecting performance data with respect to RAN-specific network slicing.

[0079] In the following, the rApp may use the R1 interface (between the rApp and the RAN OAM related functions) to provision (e.g., write) configuration changes to the O-RU, near-RT RIC, E2 nodes (O-CU, O-DU) via the O1 termination, and / or to the O-RU through the open fronthaul M-plane termination.

[0080] In the related art according to FIG. 1 , communication of rApp and non-anchor functions (including RAN OAM related functions) over the R1 interface (between rApp and RAN OAM related functions) to provision (e.g., write) configuration changes to O-RU, near-RT RIC and E2 nodes (O-CU, O-DU) via O1 termination and / or to O-RU through open fronthaul M-plane termination is not standardized.

[0081] FIG. 5 illustrates an operational flow between an rApp and non-anchor functions of the SMO framework and the NRT-RIC framework, according to one embodiment.

[0082] Referring to FIG. 5, the operational flow between the rApp and the non-anchor functions of the SMO framework and the NRT-RIC framework solves the problem to standardize operations such that the rApp writes configuration change information to a configuration management service producer (i.e., one or more RAN OAM related functions as presented in FIG. 4).

[0083] To this end, in FIG. 5, the operational flow is performed by an rApp in the role of a CM service consumer requesting configuration change information (e.g., at least one request to write a configuration change to one or more O-RAN OAM-related functions) regarding one or more managed entities (e.g., to the O-RU, near-RT RIC and E2 nodes (O-CU, O-DU) via O1 termination, and / or to the O-RU via the open fronthaul M-plane termination).

[0084] According to one embodiment, an rApp may be deployed to the NRT-RIC framework and authorized to write configuration change information to the NRT-RIC framework via the R1 interface.

[0085] Additionally, according to other embodiments, the rApp may determine the need to write configuration change information based on data consumed over the R1 interface from unanchored (i.e., non-anchor) functions, such as the NRT-RIC framework and one or more O-RAN OAM-related functions.

[0086] In operation 1, the rApp requests the NRT-RIC framework (i.e., the NRT-RIC hosting the NRT-RIC framework) to write a configuration change (e.g., a message regarding writing a configuration change that provides information to RAN OAM-related functions).

[0087] For example, the rApp may provide an rApp identifier, optional query criteria and information about the managed entity, desired configuration change information, etc. Meanwhile, in operation 1, the NRT-RIC framework receives at least one request to write a configuration change to one or more O-RAN OAM-related functions via the R1 interface between the rApp and the NRT-RIC framework (i.e., the NRT-RIC hosting the NRT-RIC framework).

[0088] In operation 2, the O-RAN OAM-related function (i.e., the NRT-RIC) checks whether the rApp is authorized to initiate a request to write a configuration change to one or more O-RAN OAM-related functions. For example, authorization and attestation may be performed in cooperation with at least one SME service function acting as a gatekeeper. In one embodiment, the O-RAN OAM-related function may not know the rApp, and as a result, the O-RAN OAM-related function may attest the rApp and cooperate with at least one SME function to verify that the rApp is authorized to request writing of configuration changes to O-RAN nodes (e.g., to the O-RU, near-RT RIC, and E2 nodes (O-CU, O-DU) via O1 termination, and / or to the O-RU through the open fronthaul M-plane termination).

[0089] In operation 3, the O-RAN OAM-related function (i.e., the NRT-RIC) validates the information provided in the request to write the configuration change to one or more O-RAN OAM functions. For example, in one embodiment, validating may comprise validating the syntax and message content of the request as defined by the O-RAN and other subsequent standardization bodies, such as 3GPP, ITU-T, etc. Furthermore, in other embodiments, validating may comprise resolving conflicts between requests from multiple rApps that may involve similar target nodes (i.e., for similar O-RAN nodes) with or without similar configurations that may have similar impacts on the operation of the E2 open radio unit (i.e., E2 / O-RU).

[0090] According to one embodiment, the O-RAN OAM related functionality may not verify, for example, whether an E2 node or O-RU is allowed for a particular configuration change and / or is available or present with the O-RAN. According to this embodiment, details may be captured in other O-RAN OAM related services that focus on the production of data based on retrieval requests about the configuration scheme of the E2 node and / or O-RU in the O-RAN.

[0091] In operation 4, the O-RAN OAM-related function (i.e., the NRT-RIC) generates a job to write a configuration change to one or more O-RAN OAM-related functions based on information provided in the at least one request to write a configuration change (i.e., generates a configuration write job from information provided in the configuration change write request).

[0092] According to one embodiment, the RAN OAM-related functions may generate jobs regardless of the availability of the E2 / O-RU node by determining, by one or more O-RAN OAM-related functions (e.g., by an O-RAN OAM-related service focused on the production of data based on a request to obtain configuration schemes for E2 nodes and / or O-RUs in the O-RAN) the availability of the E2 node and / or O-RU (E2 / O-RU) for writing the configuration change based on information provided in the at least one request to write a configuration change; and generating, by one or more O-RAN OAM-related functions, a job for writing the configuration change independently of the availability of the E2 / O-RU based on information provided in the at least one request to write a configuration change to the E2 / O-RU.

[0093] In operation 5, the O-RAN OAM-related function (i.e., the NRT-RIC) responds to the rApp with information about the created job. For example, the O-RAN OAM-related function may respond with a job identifier (e.g., a job ticket). To this end, upon creating the job, one or more O-RAN OAM-related functions may send a job identifier comprising information about the job to the rApp via the NRT-RIC framework and via the R1 interface.

[0094] According to one embodiment, the rApp may use information about the generated job to query or receive notifications about the status and / or results of the requested configuration change.

[0095] To this end, one or more O-RAN OAM-related functions may receive at least one job query from the rApp based on sending a job identifier comprising information about the job to the rApp. The rApp may send the job query via the R1 interface between the rApp and the NRT-RIC framework in the O-RAN architecture, where the at least one job query may be at least one query for notification of job status and query of job result of requested configuration change.

[0096] FIG. 6 illustrates a method for implementing writing configuration changes in an SMO framework with an NRT-RIC framework in an open radio access network (O-RAN), according to one embodiment.

[0097] Referring to FIG. 6, in step 601, an O-RAN Operations and Maintenance (OAM) function (i.e., NRT-RIC) receives at least one request from an rApp to write a configuration change to one or more O-RAN Operations and Maintenance (OAM) functions via the R1 interface between the rApp and the NRT-RIC framework.

[0098] According to one embodiment, the at least one request to write a configuration change to one or more O-RAN OAM related functions comprises an rApp identifier and at least one information of one or more desired configuration changes for one or more O-RAN nodes in the O-RAN.

[0099] In step 602, the NRT-RIC framework (e.g., one or more O-RAN operation OAM related functions working with at least one SME service function acting as a gatekeeper) authorizes at least one request from the rApp to write a configuration change to one or more O-RAN OAM related functions.

[0100] In step 603, based on authorization, one or more O-RAN OAM related functions verify information provided in at least one request to write a configuration change to one or more O-RAN OAM related functions.

[0101] In step 604, based on the verification, the one or more O-RAN OAM related functions generate a job to write the configuration change to the one or more O-RAN OAM related functions based on information provided in the at least one request to write the configuration change.

[0102] In step 605, based on the job creation, one or more O-RAN OAM related functions send a job identifier comprising information about the job to the rApp via the NRT-RIC framework and via the R1 interface.

[0103] FIG. 7 illustrates a method for authorizing at least one request from an rApp to write a configuration change to one or more O-RAN OAM-related functions, according to one embodiment.

[0104] Referring to FIG. 7, in step 701, the Service Management and Exposure (SME) function of the NRT-RIC framework (i.e., the NRT-RIC) certifies to one or more O-RAN OAM-related functions the rApp from which at least one request to write a configuration change has been received.

[0105] In step 702, based on the attestation, the SME function of the NRT-RIC framework verifies the authorization of the rApp to request at least one request to write a configuration change to one or more O-RAN nodes.

[0106] According to one embodiment, authorization and attestation may be performed in cooperation with at least one SME service function acting as a gatekeeper. In other embodiments, the O-RAN OAM-related functions may not be aware of the rApp, and as a result, the O-RAN OAM-related functions may cooperate with at least one SME function to attest the rApp and verify that the rApp is authorized to request writing configuration changes to O-RAN nodes (e.g., to the O-RU, near-RT RIC and E2 nodes (O-CU, O-DU) via O1 termination, and / or to the O-RU through open fronthaul M-plane termination).

[0107] FIG. 8 illustrates a method for validating information provided in at least one request to write a configuration change to one or more O-RAN OAM-related functions, according to one embodiment.

[0108] Referring to FIG. 8, in step 801, one or more O-RAN OAM-related functions (i.e., NRT-RIC) validate at least one of the syntax and message content of at least one request to write a configuration change to one or more O-RAN OAM-related functions.

[0109] In step 802, based on the verifying, one or more O-RAN OAM related functions resolve conflicts between requests from multiple rApps to write configuration changes to the same O-RAN node.

[0110] For example, in one embodiment, validating may comprise validating the syntax and message content of the request as defined by O-RAN and other subsequent standardization bodies such as 3GPP, ITU-T, etc.

[0111] Additionally, according to other embodiments, validating may comprise resolving conflicts between requests from multiple rApps, which may involve similar target nodes (i.e., for similar O-RAN nodes) with or without similar configurations that may have a similar impact on the operation of the E2 open radio unit (i.e., E2 / O-RU).

[0112] According to yet another embodiment, the O-RAN OAM related functionality may not verify, for example, whether an E2 node or O-RU is allowed for a particular configuration change and / or is available or present with the O-RAN. According to this embodiment, details may be captured in other O-RAN OAM related services that focus on the production of data based on retrieval requests about the configuration scheme of the E2 node and / or O-RU in the O-RAN.

[0113] FIG. 9 illustrates a method for creating a job for writing configuration changes according to one embodiment.

[0114] Referring to FIG. 9 , in step 901, based on information provided by at least one request to write a configuration change, one or more O-RAN OAM-related functions (e.g., O-RAN OAM-related services that focus on the production of data based on a request to obtain configuration schemes of E2 nodes and / or O-RUs in other O-RANs) (i.e., NRT-RIC) determine the availability of E2 nodes and / or open radio units (E2 / O-RUs) for writing configuration changes.

[0115] In step 902, one or more O-RAN OAM-related functions generate a job to write the configuration change, independent of the availability of the E2 / O-RU, based on information provided by the at least one request to write the configuration change to the E2 / O-RU.

[0116] FIG. 10 illustrates a method for receiving at least one job query over an R1 interface in an O-RAN architecture between an rApp and an NRT-RIC framework according to one embodiment.

[0117] Referring to FIG. 10, in step 1001, based on creating a job, one or more O-RAN OAM-related functions send a job identifier comprising information about the job to the rApp via the NRT-RIC framework and via the R1 interface.

[0118] In step 1002, one or more O-RAN OAM-related functions (i.e., NRT-RIC) receive at least one job query from the rApp via the R1 interface based on sending a job identifier comprising information about the job to the rApp.

[0119] According to one embodiment, an rApp may send job queries over an R1 interface in the O-RAN architecture between the rApp and the NRT-RIC framework, where the at least one job query may be at least one query for notification of job status and query of job results of requested configuration changes.

[0120] According to the embodiments illustrated in FIGS. 5-10, systems and methods are provided for implementing writing configuration changes that enable network operators to effectively manage (standardize) rApps from multiple vendors to facilitate the multi-vendor operability desired in O-RAN NRT-RIC architectures.

[0121] As a result, rApps from multiple vendors can request to write configuration changes to one or more O-RAN OAM functions from multiple vendors (i.e., from multiple vendors to O-RAN nodes), optimizing multi-vendor operability across the O-RAN.

[0122] An example use case according to one embodiment may be as follows: [Table 1] 8 Use cases for RAN OAM related services << start of change #1 >>> 8.x RAN OAM related use case Y: Writing configuration changes. 8.x.1 Overview This use case allows an rApp acting as a CM service consumer to write information about configuration changes to one or more managed entities. 8.x.2 Background and Use Case Goals An rApp acting as a CM service consumer can write information about configuration changes for one or more managed entities from a configuration management service producer. 8.x.3 Entities / Resources Involved in Use Cases 1) RAN OAM related functions as a configuration management service producer a. receiving a configuration change write request to write configuration change information for one or more managed entities; b. Provide a response resulting from the success or failure of the write configuration request. 2) rApp a. Supports the functionality to initiate a configuration change write request procedure to write configuration change information. 8.x.4 Solution 8.x.4.1 Write configuration change information Table 8.x.4.1-1: Use case for writing configuration change information. [Table 2] JPEG2026507608000004.jpg199170@startuml !pragma teoz true skinparam ParticipantPadding 70 skinparam BoxPadding 10 skinparam defaultFontSize 12 skinparam lifelineStrategy solid box "Non-RT RIC" #whitesmoke box #ivory participant "rApp" as rapp endbox box "Non-anchored functions in SMO / Non-RT RIC Framework" #cadetBlue participant "RAN OAM-related functions" as cmsp endbox endbox rapp -> cmsp: < <r1>> Write Configuration Changes request\n(rAppId, queryCriteria,configuration changes information) cmsp --> cmsp: AuthZ note right Check authorization in Collaboration with SME functions end note cmsp --> cmsp: Validate request cmsp -> rapp: < <r1>> Write Configuration Changes response\n (Success / partialsucceess / failure, ConfigurationData) @enduml Refer to Figure 11 for invoking the flowchart between rApp and NRT-RIC. Referring to Figure 11, Figure 11 relates to the original Figure 8.3.4.1-1: Use Case Flow Diagram for Writing Configuration Change Information. 8.3.5 Required Data: A configuration change write request to write configuration change information contains the rAppId, the query criteria (including information about the associated managed entities), and the requested configuration change information (a list of attributes and desired values ​​for the managed entities). The configuration write response contains the written desired and immutable configuration changes as configuration data, a success result if and only if all desired configuration changes were written at the referenced managed entities, a partial success result if some (but not all) desired configuration changes were written at the referenced managed entities for explicit or implicit reasons, or a failure if all desired configuration changes were not written at the referenced managed entities for explicit or implicit reasons. Note: Whether the rAppId is passed as a separate piece of information or is embedded in or implied by the authorization information is up to the design of the authorization mechanism. << end of change #1 >>

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

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

[0125] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, punch cards, or mechanically encoded devices such as raised structures in grooves in which instructions are recorded, or any suitable combination thereof. As used herein, computer-readable storage medium is not to be understood as a transitory signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse passing through a fiber optic cable), or an electrical signal transmitted over a wire.

[0126] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium into each computing / processing device, or may be downloaded to an external computer or external storage device over a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing / processing device.

[0127] The 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 an integrated circuit, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk or C++, procedural programming languages ​​such as the "C" programming language, or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, partially on the user's computer, partially on a remote computer, or entirely on a remote computer or server, as a standalone software package. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), may execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry to perform a certain aspect or operation.

[0128] 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 an apparatus, such that the instructions, when executed by the processor of the computer or other programmable data processing apparatus, produce means for implementing the functions / acts set forth in the flowcharts and / or block diagrams (one or more blocks). These computer-readable program instructions may be stored on a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other device to function in a particular manner, such that the computer-readable storage medium on which the instructions are stored comprises an article including instructions that implement aspects of the functions / acts set forth in the flowcharts and / or block diagrams (one or more blocks).

[0129] The computer-readable program instructions may be loaded onto a computer, other programmable data processing apparatus, or other device such that a series of operational steps are performed on the computer, other programmable apparatus, or other device to generate a computer-implemented process such that the instructions, executed on the computer, other programmable apparatus, or other device, implement the functions / acts described in the flowcharts and / or block diagrams (one or more blocks).

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

[0131] It will be apparent that the systems and / or methods described herein may be implemented in different forms, such as hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods does not limit the implementation. As such, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It will be understood that software and hardware may be designed to implement the systems and / or methods based on the description herein.

[0132] Various further respective aspects and features of embodiments of the present disclosure may be defined by the following items. Item 1: receiving at least one request from an rApp to write a configuration change to one or more O-RAN operations and maintenance (OAM) related functions via an R1 interface between the rApp and the NRT-RIC framework; authorizing the at least one request from the rApp to write a configuration change to the one or more O-RAN OAM-related functions; verifying information provided in the at least one request to write a configuration change to one or more O-RAN OAM-related functions based on the authorizing; generating, based on the verifying, a job to write the configuration change to the one or more O-RAN OAM-related functions based on information provided in the at least one request to write the configuration change; Based on creating a job, sending a job identifier to the rApp via the NRT-RIC framework and via the R1 interface, the job identifier comprising information about the job; 1. An apparatus comprising: a non-real-time radio access network intelligence controller (NRT-RIC) configured to execute: Item 2: Item 10. The apparatus of item 1, wherein the at least one request to write a configuration change to the one or more O-RAN OAM-related functions comprises an rApp identifier and at least one information of one or more desired configuration changes for one or more O-RAN nodes within the O-RAN. Item 3: The NRT-RIC is configured to authorize the at least one request from the rApp to write a configuration change to one or more O-RAN OAM related functions. Attesting the rApp from which the at least one request to write a configuration change to one or more O-RAN OAM related functions was received by a Service Management and Exposure (SME) function of the NRT-RIC framework; verifying, based on the attestation, the authorization of the rApp to request at least one request to write a configuration change to one or more O-RAN nodes by the SME function of the NRT-RIC framework; 3. The apparatus according to item 1 or 2, which may be further configured to perform the following: Item 4: the device configured to verify information provided in the at least one request to write a configuration change to the one or more O-RAN OAM-related functions; validating, by the one or more O-RAN OAM related functions, at least one of a syntax and a message content of the at least one request to write a configuration change to one or more O-RAN OAM related functions; resolving conflicts between requests from multiple rApps to write configuration changes to the same O-RAN node, by the one or more O-RAN OAM-related functions based on the verifying; and 4. The apparatus of any of items 1 to 3, further configured to perform the following: Item 5: The device configured to generate a job for writing the configuration, determining, by the one or more O-RAN OAM-related functions, availability of an E2 node and / or an open radio unit (E2 / O-RU) for writing the configuration change based on the information provided in the at least one request to write a configuration change; generating, by the one or more O-RAN OAM-related functions, the job for writing the configuration change based on the information provided in the at least one request to write the configuration change to the E2 / O-RU, independent of the availability of the E2 / O-RU; 5. The apparatus of any of items 1 to 4, further configured to perform Item 6: 6. The apparatus of claim 1, further configured to receive at least one job query from the rApp via an R1 interface in the O-RAN architecture between the rApp and the NRT-RIC framework based on sending a job identifier to the rApp comprising information about the job. Item 7: 7. The apparatus of claim 6, wherein the at least one job query may be at least one query for notification of job status and query of job results of the requested configuration change. Item 8: receiving at least one request from an rApp to write a configuration change to one or more O-RAN Operations and Maintenance (OAM) related functions via an R1 interface between the rApp and an NRT-RIC framework; authorizing, via the NRT-RIC framework, the at least one request from the rApp to write a configuration change to the one or more O-RAN OAM-related functions; verifying, by the one or more O-RAN OAM-related functions, information provided in the at least one request to write a configuration change to one or more O-RAN OAM-related functions based on the authorizing; generating, by the one or more O-RAN OAM-related functions based on the verifying, a job to write the configuration change to the one or more O-RAN OAM-related functions based on information provided in the at least one request to write the configuration change; sending, by the one or more O-RAN OAM-related functions, via the NRT-RIC framework and via the R1 interface, a job identifier comprising information about the job to the rApp based on creating the job; A method comprising: Item 9: Item 9. The method of item 8, wherein the at least one request to write a configuration change to the one or more O-RAN OAM-related functions comprises an rApp identifier and at least one information of one or more desired configuration changes for one or more O-RAN nodes within the O-RAN. Item 10: Attesting the rApp from which the at least one request to write a configuration change to one or more O-RAN OAM related functions was received by a Service Management and Exposure (SME) function of the NRT-RIC framework; verifying, based on the attestation, the authorization of the rApp to request at least one request to write a configuration change to one or more O-RAN nodes by the SME function of the NRT-RIC framework; 10. The method according to item 8 or 9, which may further comprise: Item 11: validating, by the one or more O-RAN OAM related functions, at least one of a syntax and a message content of the at least one request to write a configuration change to one or more O-RAN OAM related functions; resolving conflicts between requests from multiple rApps to write configuration changes to the same O-RAN node, by the one or more O-RAN OAM-related functions based on the verifying; and 11. The method according to any one of items 8 to 10, which may further comprise: Item 12: determining, by the one or more O-RAN OAM-related functions, availability of an E2 node and / or an open radio unit (E2 / O-RU) for writing the configuration change based on the information provided in the at least one request to write a configuration change; generating, by the one or more O-RAN OAM-related functions, the job for writing the configuration change based on the information provided in the at least one request to write the configuration change to the E2 / O-RU, independent of the availability of the E2 / O-RU; 12. The method according to any one of items 8 to 11, which may further comprise: Item 13: 13. The method of any of items 8 to 12, further comprising receiving at least one job query from the rApp via an R1 interface in the O-RAN architecture between the rApp and the NRT-RIC framework based on sending a job identifier to the rApp comprising information about the job. Item 14: Item 14. The method of item 13, wherein the at least one job query may be at least one query for notification of job status and a query for job results of the requested configuration change. Item 15: receiving at least one request from an rApp to write a configuration change to one or more O-RAN Operations and Maintenance (OAM) related functions via an R1 interface between the rApp and an NRT-RIC framework; authorizing, via the NRT-RIC framework, the at least one request from the rApp to write a configuration change to the one or more O-RAN OAM-related functions; verifying, by the one or more O-RAN OAM-related functions, information provided in the at least one request to write a configuration change to one or more O-RAN OAM-related functions based on the authorizing; generating, by the one or more O-RAN OAM-related functions based on the verifying, a job to write the configuration change to the one or more O-RAN OAM-related functions based on information provided in the at least one request to write the configuration change; sending, by the one or more O-RAN OAM-related functions, via the NRT-RIC framework and via the R1 interface, a job identifier comprising information about the job to the rApp based on creating the job; A non-transitory computer-readable storage medium having stored thereon instructions executable by at least one processor to perform a method including: Item 16: Item 16. The non-transitory computer-readable storage medium of item 15, wherein the at least one request to write a configuration change to the one or more O-RAN OAM-related functions comprises an rApp identifier and at least one information of one or more desired configuration changes for one or more O-RAN nodes in the O-RAN. Item 17: The method comprises: Attesting the rApp from which the at least one request to write a configuration change to one or more O-RAN OAM related functions was received by a Service Management and Exposure (SME) function of the NRT-RIC framework; verifying, based on the attestation, the authorization of the rApp to request at least one request to write a configuration change to one or more O-RAN nodes by the SME function of the NRT-RIC framework; 17. The non-transitory computer-readable storage medium according to item 15 or 16, which may further include: Item 18: The method comprises: validating, by the one or more O-RAN OAM related functions, at least one of a syntax and a message content of the at least one request to write a configuration change to one or more O-RAN OAM related functions; resolving conflicts between requests from multiple rApps to write configuration changes to the same O-RAN node, by the one or more O-RAN OAM-related functions based on the verifying; and 18. The non-transitory computer-readable storage medium according to any one of items 15 to 17, which may further include: Item 19: The method comprises: determining, by the one or more O-RAN OAM-related functions, availability of an E2 node and / or an open radio unit (E2 / O-RU) for writing the configuration change based on the information provided in the at least one request to write a configuration change; generating, by the one or more O-RAN OAM-related functions, the job for writing the configuration change based on the information provided in the at least one request to write the configuration change to the E2 / O-RU, independent of the availability of the E2 / O-RU; 19. The non-transitory computer-readable storage medium of any of items 15 to 18, which may further include: Item 20: 20. The non-transitory computer-readable storage medium of any of items 15 to 19, wherein the method may further include receiving at least one job query from the rApp via an R1 interface in the O-RAN architecture between the rApp and the NRT-RIC framework based on sending a job identifier to the rApp comprising information about the job.

Claims

1. receiving at least one request from an rApp to write a configuration change to one or more O-RAN Operations and Maintenance (OAM) related functions via an R1 interface between the rApp and a Non-Real-Time Radio Access Network Intelligence Controller (NRT-RIC) framework; authorizing the at least one request from the rApp to write a configuration change to the one or more O-RAN OAM-related functions; verifying information provided in the at least one request to write a configuration change to one or more O-RAN OAM-related functions based on the authorizing; generating, based on the verifying, a job to write the configuration change to the one or more O-RAN OAM-related functions based on information provided in the at least one request to write the configuration change; Based on creating a job, sending a job identifier to the rApp via the NRT-RIC framework and via the R1 interface, the job identifier comprising information about the job; 12. An apparatus comprising: an NRT-RIC configured to execute:

2. 2. The apparatus of claim 1, wherein the at least one request to write a configuration change to the one or more O-RAN OAM-related functions comprises at least one information of an rApp identifier and one or more desired configuration changes for one or more O-RAN nodes within the O-RAN.

3. The NRT-RIC is configured to authorize the at least one request from the rApp to write a configuration change to one or more O-RAN OAM related functions. attesting to the rApp from which the at least one request to write a configuration change to one or more O-RAN OAM related functions was received; verifying the authorization of the rApp to request at least one request to write a configuration change to one or more O-RAN nodes based on the attestation; The apparatus of claim 1 , further configured to perform:

4. the device configured to verify information provided in the at least one request to write a configuration change to the one or more O-RAN OAM-related functions; Validating at least one of a syntax and a message content of the at least one request to write a configuration change to one or more O-RAN OAM related functions; Resolving conflicts between requests from multiple rApps to write configuration changes to the same O-RAN node based on the verifying; and The apparatus of claim 1 , further configured to perform:

5. The device configured to generate a job for writing the configuration, determining availability of an E2 node and / or an open radio unit (E2 / O-RU) for writing the configuration change based on the information provided by the at least one request to write a configuration change; generating the job for writing the configuration change based on the information provided by the at least one request to write a configuration change to the E2 / O-RU, independent of the availability of the E2 / O-RU; The apparatus of claim 1 , further configured to perform:

6. 10. The apparatus of claim 1, further configured to receive at least one job query from the rApp via an R1 interface in the O-RAN architecture between an rApp and the NRT-RIC framework based on sending a job identifier to the rApp comprising information about the job.

7. The apparatus of claim 6 , wherein the at least one job query is at least one query for notification of job status and a query for job results of the requested configuration change.

8. receiving at least one request from an rApp to write a configuration change to one or more O-RAN Operations and Maintenance (OAM) related functions via an R1 interface between the rApp and an NRT-RIC framework; authorizing, via the NRT-RIC framework, the at least one request from the rApp to write a configuration change to the one or more O-RAN OAM-related functions; verifying, by the one or more O-RAN OAM-related functions, information provided in the at least one request to write a configuration change to one or more O-RAN OAM-related functions based on the authorizing; generating, by the one or more O-RAN OAM-related functions based on the verifying, a job to write the configuration change to the one or more O-RAN OAM-related functions based on information provided in the at least one request to write the configuration change; sending, by the one or more O-RAN OAM-related functions, via the NRT-RIC framework and via the R1 interface, a job identifier comprising information about the job to the rApp based on creating the job; A method for providing the above.

9. 10. The method of claim 8, wherein the at least one request to write a configuration change to the one or more O-RAN OAM-related functions comprises at least one information of an rApp identifier and one or more desired configuration changes for one or more O-RAN nodes within the O-RAN.

10. Attesting the rApp from which the at least one request to write a configuration change to one or more O-RAN OAM related functions was received by a Service Management and Exposure (SME) function of the NRT-RIC framework; verifying, based on the attestation, the authorization of the rApp to request at least one request to write a configuration change to one or more O-RAN nodes by the SME function of the NRT-RIC framework; The method of claim 8 further comprising:

11. validating, by the one or more O-RAN OAM related functions, at least one of a syntax and a message content of the at least one request to write a configuration change to one or more O-RAN OAM related functions; resolving conflicts between requests from multiple rApps to write configuration changes to the same O-RAN node, by the one or more O-RAN OAM-related functions based on the verifying; and The method of claim 10 further comprising:

12. determining, by the one or more O-RAN OAM-related functions, availability of an E2 node and / or an open radio unit (E2 / O-RU) for writing the configuration change based on the information provided in the at least one request to write a configuration change; generating, by the one or more O-RAN OAM-related functions, the job for writing the configuration change based on the information provided in the at least one request to write the configuration change to the E2 / O-RU, independent of the availability of the E2 / O-RU; The method of claim 8 further comprising:

13. 10. The method of claim 8, further comprising receiving at least one job query from the rApp via an R1 interface in the O-RAN architecture between an rApp and the NRT-RIC framework based on sending a job identifier to the rApp comprising information about the job.

14. The method of claim 13 , wherein the at least one job query is at least one of a query for notification of job status and a query for job results of the requested configuration change.

15. receiving at least one request from an rApp to write a configuration change to one or more O-RAN Operations and Maintenance (OAM) related functions via an R1 interface between the rApp and an NRT-RIC framework; authorizing, via the NRT-RIC framework, the at least one request from the rApp to write a configuration change to the one or more O-RAN OAM-related functions; verifying, by the one or more O-RAN OAM-related functions, information provided in the at least one request to write a configuration change to one or more O-RAN OAM-related functions based on the authorizing; generating, by the one or more O-RAN OAM-related functions based on the verifying, a job to write the configuration change to the one or more O-RAN OAM-related functions based on information provided in the at least one request to write the configuration change; sending, by the one or more O-RAN OAM-related functions, via the NRT-RIC framework and via the R1 interface, a job identifier comprising information about the job to the rApp based on creating the job; A non-transitory computer-readable storage medium having stored thereon instructions executable by at least one processor to perform a method comprising:

16. 16. The non-transitory computer-readable medium of claim 15, wherein the at least one request to write a configuration change to the one or more O-RAN OAM-related functions comprises at least one information of an rApp identifier and one or more desired configuration changes for one or more O-RAN nodes in the O-RAN.

17. The method comprises: Attesting the rApp from which the at least one request to write a configuration change to one or more O-RAN OAM related functions was received by a Service Management and Exposure (SME) function of the NRT-RIC framework; verifying, based on the attestation, the authorization of the rApp to request at least one request to write a configuration change to one or more O-RAN nodes by the SME function of the NRT-RIC framework; 16. The non-transitory computer-readable storage medium of claim 15, further comprising:

18. The method comprises: validating, by the one or more O-RAN OAM related functions, at least one of a syntax and a message content of the at least one request to write a configuration change to one or more O-RAN OAM related functions; resolving conflicts between requests from multiple rApps to write configuration changes to the same O-RAN node, by the one or more O-RAN OAM-related functions based on the verifying; and 20. The non-transitory computer-readable storage medium of claim 17, further comprising:

19. The method comprises: determining, by the one or more O-RAN OAM-related functions, availability of an E2 node and / or an open radio unit (E2 / O-RU) for writing the configuration change based on the information provided in the at least one request to write a configuration change; generating, by the one or more O-RAN OAM-related functions, the job for writing the configuration change based on the information provided in the at least one request to write the configuration change to the E2 / O-RU, independent of the availability of the E2 / O-RU; 16. The non-transitory computer-readable storage medium of claim 15, further comprising:

20. 16. The non-transitory computer-readable storage medium of claim 15, wherein the method further comprises receiving at least one job query from the rApp via an R1 interface in the O-RAN architecture between the rApp and the NRT-RIC framework based on sending a job identifier to the rApp comprising information about the job.

Images