System and method for implementing write configuration changes in non-real-time radio access network intelligence controller (NRT-RIC) architecture within telecommunications network

Abstract

Systems and methods are provided for implementing write configuration changes in an open radio access network (O-RAN) architecture including a service management and orchestration (SMO) framework and a non-real-time radio access network intelligent controller (NRT-RIC) framework in an open radio access network (O-RAN). The method includes receiving at least one request to write a configuration change to one or more O-RAN Operation and Maintenance (OAM) related functions; authorizing at least one request from the rApp to write a configuration change to one or more O-RAN OAM related functions; validating information provided by at least one request to write a configuration change to the one or more O-RAN OAM related functionality; creating a job for writing the configuration change based on information provided by at least one request to write the configuration change to the one or more O-RAN OAM related functions; and transmitting a job identifier including information on the job to the rApp.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application is based upon and claims the benefit of U.S. Provisional Patent Application No. 63 / 452,821, filed on March 17, 2023, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] Apparatus and methods consistent with example embodiments of the present disclosure relate to apparatus and methods for implementing write configuration changes in a non-real-time radio access network intelligent controller (NRT-RIC) architecture, which NRT-RIC architecture includes a service management and orchestration (SMO) framework and an NRT-RIC framework in an open radio access network (O-RAN). Background Art

[0004] The Radio Access Network (RAN) is a crucial component in telecommunications systems because it connects end-user devices (or user equipment) to the rest of the network. The RAN comprises 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 is vendor-specific.

[0005] The emergence of open RAN (O-RAN) technology enables multiple vendors to provide hardware and / or software for telecommunications systems. To this end, O-RAN decomposes RAN functionality into a centralized unit (CU), a distributed unit (DU), and a radio unit (RU). The CU is a logical node for hosting the radio resource control (RRC), service data adaptation protocol (SDAP), and / or packet data convergence protocol (PDCP) sublayers of the RAN. The DU is a logical node for hosting the radio link control (RLC), medium access control (MAC), and physical layer (PHY) sublayers of the RAN. The RU converts the radio signal from the antenna into a digital signal that can be transmitted to the DU via fronthaul. Because these entities have open protocols and interfaces between them, they can be developed by different vendors.

[0006] Figure 1 The figure shows the O-RAN architecture of related technologies. Figure 1 RAN functions in the O-RAN architecture are controlled and optimized by the RIC. The RIC is a software-defined component that implements modular applications to facilitate the multi-vendor operability required in O-RAN systems and automate and optimize RAN operations. RICs are categorized into two types: non-real-time RIC (NRT-RIC) and near-real-time RIC (nRT-RIC).

[0007] NRT-RIC is the control point of the non-real-time control loop and operates on a time scale greater than 1 second within the Service Management and Orchestration (SMO) framework. Its functions are implemented through modular applications called rApps (rApp1, ..., rAppN) and include: providing policy-based guidance and enrichment functions through the A1 interface, which is the interface that enables communication between NRT-RIC and nRT-RIC; performing data analysis; artificial intelligence / machine learning (AI / ML) training and inference for RAN optimization; and / or recommending configuration management operations through the O1 interface, which is the interface that connects the SMO to the RAN management unit (e.g., nRT-RIC, O-RAN Centralized Unit (O-CU), O-RAN Distributed Unit (O-DU), etc.).

[0008] nRT-RIC operates on a time scale between 10 milliseconds and 1 second and is connected to the O-DU, O-CU (decomposed into the O-CU control plane (O-CU-CP) and the O-CU user plane (O-CU-UP)) and the open evolved NodeB (O-eNB) via the E2 interface. nRT-RIC uses the E2 interface to control the underlying RAN units (E2 nodes / network functions (NF)) through a near real-time control loop. nRT-RIC monitors, pauses / stops, covers and controls E2 nodes (O-CU, O-DU and O-eNB) via policies. For example, nRT-RIC sets policy parameters for activated functions of the E2 nodes. In addition, nRT-RIC hosts xApps to implement functions such as quality of service (QoS) optimization, mobility optimization, slice optimization, interference suppression, load balancing, security, etc. The two types of RICs work together to optimize O-RAN. For example, NRT-RIC provides policies, data, and AI / ML models that nRT-RIC executes and uses for RAN optimization through the A1 interface, and nRT-RIC returns policy feedback (i.e., how the policies set by NRT-RIC work).

[0009] The SMO framework, where the NRT-RIC resides, is responsible for managing and orchestrating the RAN elements. Specifically, the SMO is responsible for managing and orchestrating the so-called O-RAN Cloud (O-Cloud). The O-Cloud is a collection of physical RAN nodes that host the RIC, O-CU and O-DU, supporting software components (e.g., operating system and runtime environment), and the SMO itself. In other words, the SMO manages the O-Cloud from the inside. The O2 interface is the interface between the SMO and the O-Cloud in which it resides. Through the O2 interface, the SMO provides Infrastructure Management Services (IMS) and Deployment Management Services (DMS).

[0010] On the other hand, O-Cloud is a cloud computing platform that consists of a collection of physical infrastructure nodes that meet O-RAN requirements and is used to host related O-RAN functions (such as nRT-RIC, O-CU-CP, O-CU-UP, O-DU, etc.), supporting software components (such as operating systems, virtual machine monitors, container runtimes, etc.) and appropriate management and orchestration capabilities.

[0011] The SMO framework, where the NRT-RIC resides, is responsible for managing and orchestrating RAN elements. The SMO performs the following services (i.e., management and orchestration of RAN elements) through four key interfaces with O-RAN elements: the A1 interface between the NRT-RIC and nRT-RIC in the SMO (for RAN optimization); the O1 interface between the SMO and the O-RAN network function (for FCAPS support); in the case of a hybrid model, the open fronthaul M-plane interface between the SMO and the O-RU (for FCAPS support); and the O2 interface between the SMO and the O-Cloud (for platform resource and workload management).

[0012] In the prior art, there is no standardized communication between the rApp and the non-anchor functions of the SMO framework and the NRT-RIC framework for sending 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.

[0013] Therefore, the communication between the rApp requesting a write request to write configuration changes to one or more O-RAN Operation and Maintenance (OAM) related functions and the non-anchor functions of the SMO framework and the NRT-RIC framework may not facilitate the required multi-vendor operability in the O-RAN system. Summary of the Invention

[0014] According to an embodiment, an apparatus and method for implementing write configuration changes in a non-real-time radio access network intelligent controller (NRT-RIC) architecture are provided, wherein the NRT-RIC architecture includes a service management and orchestration (SMO) framework and an NRT-RIC framework in an open radio access network (O-RAN), wherein the implementation of write configuration changes allows network operators to effectively manage (standardize) rApps from multiple vendors to facilitate the multi-vendor operability required in the NRT-RIC architecture of O-RAN.

[0015] To this end, implementation of writing configuration changes includes authorization and verification to create a job (e.g., a job ticket) for writing the configuration changes to one or more O-RAN operations and maintenance (OAM) related functions.

[0016] As a result, the communication between rApps requesting write requests to write configuration changes to one or more O-RAN operations and maintenance (OAM) related functions and non-anchor functions of the SMO framework and NRT-RIC framework is standardized based on the authorization and verification of the creation job (e.g., job ticket).

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

[0018] According to an embodiment, a method for implementing writing configuration changes in an open radio access network (O-RAN) including a service management and orchestration (SMO) framework and a non-real-time radio access network intelligent controller (NRT-RIC) framework in an NRT-RIC architecture is provided. The method includes: receiving at least one request to write a configuration change to one or more O-RAN operation and maintenance (OAM)-related functions from an rApp via an R1 interface between the rApp and the NRT-RIC framework; authorizing, by the NRT-RIC framework, at least one request from the rApp to write a configuration change to 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 by the at least one request to write a configuration change to the one or more O-RAN OAM-related functions; based on the verification, creating, by the one or more O-RAN OAM-related functions, a job for writing the configuration change based on the information provided by the at least one request to write the configuration change to the one or more O-RAN OAM-related functions; and based on the job creation, sending, by the one or more O-RAN OAM-related functions, a job identifier including information about the job to the rApp via the NRT-RIC framework and via the R1 interface.

[0019] According to an embodiment, a non-transitory computer-readable recording medium having recorded thereon instructions executable by at least one processor for performing a method for implementing a write configuration change in a service management and orchestration (SMO) framework and a non-real-time radio access network intelligent controller (NRT-RIC) framework in an open radio access network (O-RAN) is provided. The method includes: receiving, from the rApp via an R1 interface between the rApp and the NRT-RIC framework, at least one request to write a configuration change to one or more O-RAN operation and maintenance (OAM)-related functions; 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; verifying, by the one or more O-RAN OAM-related functions, information provided by the at least one request to write the configuration change to the one or more O-RAN OAM-related functions based on the authorization; creating, by the one or more O-RAN OAM-related functions, a job for writing the configuration change based on the information provided by the at least one request to write the configuration change to the one or more O-RAN OAM-related functions based on the verification; and sending, by the one or more O-RAN OAM-related functions, a job identifier including information about the job to the rApp via the NRT-RIC framework and via the R1 interface based on the job creation.

[0020] Additional aspects will be set forth in part in the description which follows and, in part, will be obvious from the description, or may be achieved by practice of the presented embodiments of the disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Features, aspects, and advantages of certain exemplary embodiments of the present disclosure will now be described with reference to the accompanying drawings, wherein like reference numerals represent like elements, and wherein:

[0022] Figure 1 The figure illustrates the O-RAN architecture in related technologies;

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

[0024] Figure 3 is a diagram of example components of a device according to an embodiment;

[0025] Figure 4 illustrates an NRT-RIC architecture including an SMO framework within O-RAN and non-anchor functionality of the NRT-RIC framework according to an embodiment;

[0026] Figure 5The diagram illustrates the operation flow between the rApp and the non-anchor functions of the SMO framework and the NRT-RIC framework according to an embodiment;

[0027] Figure 6 illustrates a method for implementing write configuration changes in an SMO framework including an NRT-RIC framework in an open radio access network O-RAN according to an embodiment;

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

[0029] Figure 8 illustrates a method for validating information provided by at least one request to write a configuration change to one or more O-RAN OAM-related functions according to an embodiment;

[0030] Figure 9 illustrates a method for creating a job for writing configuration changes according to an embodiment;

[0031] Figure 10 illustrates a method for receiving at least one job query via an R1 interface between an rApp and an NRT-RIC framework within an O-RAN architecture according to an example embodiment; and

[0032] Figure 11 An operation flow of rApp between rApp and NRT-RIC according to an example embodiment is illustrated. DETAILED DESCRIPTION

[0033] 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.

[0034] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit implementation to the disclosed precise form. In view of the above disclosure, modifications and variations are possible, or can be obtained from the practice of implementation. In addition, one or more features or components of an embodiment can be incorporated into or combined with another embodiment (or one or more features of another embodiment). In addition, in the operational descriptions and flow charts provided below, it should be understood that one or more operations can be omitted, one or more operations can be added, one or more operations can be performed (at least in part) simultaneously, and the order of one or more operations can be switched.

[0035] Obviously, the systems and / or methods described herein can be implemented in various forms of hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods does not limit the implementation. Therefore, the operation and behavior of the systems and / or methods described herein are not referenced to specific software code. It is understood that software and hardware can be designed to implement these systems and / or methods based on the description herein.

[0036] Even though particular combinations of features are recited in the claims and / or disclosed in the specification, these combinations are not intended to limit the disclosure of possible implementations. In fact, many of these features can be combined in ways not explicitly recited in the claims and / or disclosed in the specification. Although each dependent claim listed below may only directly depend on one claim, the disclosure of possible implementations includes each dependent claim in combination with all other claims in the claim set.

[0037] Unless explicitly stated, any element, action or instruction used herein should not be understood as key or necessary. In addition, as used herein, the articles "one" and "an" are intended to include one or more items and can be used interchangeably with "one or more". When referring to only one item, the term "one" or similar language is used. In addition, as used herein, "having", "including" and the like terms are intended to be open terms. In addition, unless explicitly stated otherwise, the phrase "based on" is intended to mean "based at least in part". In addition, statements such as "at least one of [A] and [B]" or "at least one of [A] or [B]" should be understood to include only A, only B, or both.

[0038] Figure 2 is a diagram of an example environment 200 in which the systems and / or methods described herein may be implemented. Figure 3 As shown in FIG, environment 200 may include user device 210, platform 220, and network 220. The devices in environment 200 may be interconnected via wired connections, wireless connections, or a combination of wired and wireless connections. Figures 4 to 10 Any functions and operations described can be performed by Figure 3 The present invention may be performed by any combination of the elements shown in the figure.

[0039] User device 210 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information associated with 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, etc.), a wearable device (e.g., smart glasses or a smart watch), or the like. In some implementations, user device 210 may receive information from platform 220 and / or transmit information to platform 220.

[0040] The platform 220 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information. In some implementations, the platform 220 may include a cloud server or a group of cloud servers. In some implementations, the platform 220 may be designed to be modular so that certain software components can be replaced depending on specific needs. In this way, the platform 220 can be easily and / or quickly reconfigured for different uses.

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

[0042] Cloud computing environment 222 includes an environment that hosts platform 220. Cloud computing environment 222 can provide computing, software, data access, storage, and other services without requiring end users (e.g., user devices 210) to be aware of the physical location and configuration of the systems and / or devices hosting platform 220. As shown, cloud computing environment 222 can include a set of computing resources 224 (collectively referred to as "computing resources 224" and individually as "computing resource 224").

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

[0044] like Figure 2As further shown in the figure, the computing resources 224 include a set of cloud resources, such as one or more applications ("APP") 224-1, one or more virtual machines ("VM") 224-2, virtualized storage devices ("VS") 224-3, one or more hypervisors ("HYP") 224-4, and the like.

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

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

[0047] The virtualized storage device 224-3 includes one or more storage systems and / or one or more devices that use virtualization technology in the storage system or device of the computing resource 224. In some implementations, within the context of the storage system, the types of virtualization may include block virtualization and file virtualization. Block virtualization may refer to abstracting (or separating) logical storage from physical storage so that the storage system can be accessed without considering the physical storage or heterogeneous structure. This separation can allow administrators of the storage system to have flexibility in how to manage storage for end users. File virtualization can eliminate the dependency between data accessed at the file level and the location where the file is physically stored. This can achieve optimization of storage usage, server consolidation and / or performance of non-disruptive file migration.

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

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

[0050] Figure 2 The number and arrangement of devices and networks shown in the FIGURES are provided as examples. In practice, there may be more than Figure 2 More devices and / or networks, fewer devices and / or networks, different devices and / or networks, or differently arranged devices and / or networks than those shown in . Figure 2 Two or more devices shown in FIG may be implemented in a single device, or Figure 2 The single device shown in FIG200 may be implemented as multiple distributed devices. Additionally or alternatively, one set of devices (eg, one or more devices) of environment 200 may perform one or more functions described as being performed by another set of devices of environment 200.

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

[0052] The bus 310 includes components that allow communication between components of the device 300. The processor 320 can be implemented in hardware, firmware, or a combination of hardware and software. The processor 320 can be a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or other types of processing components. In some implementations, the processor 320 includes one or more processors that can be programmed to perform functions. The memory 320 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.

[0053] The storage component 330 stores information and / or software related to the operation and use of the device 300. For example, the storage component 330 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optical disk, and / or a solid-state hard disk), a compact disk (CD), a digital versatile disk (DVD), a floppy disk, a magnetic cassette, a magnetic tape, and / or other types of non-transitory computer-readable media, and corresponding drives. The input component 350 includes components that allow the device 300 to receive information, such as via user input (e.g., a touch screen, a keyboard, a keypad, a mouse, buttons, switches, and / or a microphone). Additionally or alternatively, the input component 350 may include a sensor for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, and / or an actuator). The output component 360 includes components that provide output information from the device 300 (e.g., a display, a speaker, and / or one or more light-emitting diodes (LEDs)).

[0054] The communication interface 370 includes transceiver-like components (e.g., a transceiver and / or a separate receiver and transmitter) that enable the device 300 to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. The communication interface 370 can allow the device 300 to receive information from another device and / or provide information to another device. For example, the communication interface 370 can include an Ethernet interface, a fiber optic 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, and the like.

[0055] Device 300 can perform one or more processes described herein. Device 300 can perform these processes in response to processor 320 executing software instructions stored by a non-transitory computer-readable medium (such as memory 320 and / or storage component 330). Computer-readable media 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.

[0056] The software instructions may be read into memory 320 and / or storage component 330 from another computer-readable medium or from another device via communication interface 370. When executed, the software instructions stored in memory 320 and / or storage component 330 may cause processor 320 to perform one or more processes described herein.

[0057] Additionally or alternatively, hard-wired circuitry may be used in place of or in combination with software instructions to perform one or more of the processes described herein.Thus, the implementations described herein are not limited to any specific combination of hardware circuitry and software.

[0058] Figure 3 The number and arrangement of components shown in FIG are provided as examples. In practice, the device 300 may include more than Figure 3 More components, fewer components, different components, or differently arranged components than those shown in . Additionally or alternatively, one set of components (e.g., one or more components) of device 300 may perform one or more functions described as being performed by another set of components of device 300.

[0059] In an embodiment, Figures 4 to 10 Any operation or process may be performed by or using Figures 2 to 3 It can be implemented by any one of the components shown in the figure.

[0060] Figure 4 The diagram illustrates the NRT-RIC architecture (or platform) and rApps hosted by NRT-RIC according to an embodiment, involving the R1 interface within the SMO framework system architecture and the O1, O2, and A1 interfaces within O-RAN.

[0061] See also Figure 4, NRT-RIC represents a subset of the functions of the SMO framework (i.e., functions anchored inside the NRT-RIC framework, functions anchored outside the NRT-RIC framework, and non-anchored (i.e., non-anchored functions). NRT-RIC can access other SMO framework functions, thereby affecting (i.e., controlling and / or executing) the content carried on at least one of the O1 interface, fronthaul M-plane interface, and O2 interface of O-CU, O-DU, O-RU, near-RT RIC, etc. (e.g., performing configuration management (CM) and / or performance management (PM)).

[0062] 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 R1 services provided according to embodiments. For example, the SME function acts as a gatekeeper within the NRT-RIC framework to perform authorization and authentication. In addition, the SME function can collaborate with non-anchor (i.e., non-anchor functions) to perform authorization and authentication of rApps, or to execute requests from rApps, such as writing configuration changes to one or more O-RAN operations and maintenance (OAM) related functions.

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

[0064] NRT-RIC Applications (rApps) are applications that leverage the functionality available in the NRT-RIC framework and / or the SMO framework to provide value-added services related to RAN operations and optimization. The scope of rApps includes, but is not limited to, radio resource management, data analytics, and information enrichment. For example, an rApp can request that configuration changes be written to one or more O-RAN OAM-related functions.

[0065] To this end, according to an exemplary embodiment, the NRT-RIC framework generates and / or uses R1 services via an R1 interface. The R1 interface terminates at an R1 terminal of the NRT-RIC framework. The R1 terminal is connected to the NRT-RIC framework and rApp via the R1 interface and enables the NRT-RIC framework and rApp to exchange messages / data (i.e., requests and responses including data models), thereby accessing R1 services via the R1 interface.

[0066] In addition, the NRT-RIC framework includes A1-related functions, such as supporting A1 logical terminals, A1 policy coordination and directory, and A1-EI coordination and directory.

[0067] The data management and exposure services within the NRT-RIC framework deliver data created or collected by data producers to data consumers based on their needs (e.g., Functional Management (FM) / Configuration Management (CM) / Production Management (PM) data delivered to rApp or CM changes from rApp to O-RAN via the O1 interface).

[0068] The NRT-RIC framework also includes external endpoints. For example, external endpoints support data exchange between the NRT-RIC framework and external AI / ML functions, enriched information (EI) sources, or external supervision.

[0069] Within the NRT-RIC framework, the AI / ML workflow service provides access to AI / ML workflows. For example, the AI / ML workflow service can assist in training models and monitoring AI / ML models deployed in NRT-RIC.

[0070] In addition, the NRT-RIC framework includes A2-related functions, such as support for A2 logical terminals, A2 policy coordination and directory, etc.

[0071] Still see Figure 4 Within the NRT-RIC framework, the R1 interface is an open logical interface between the NRT-RIC framework and rApps in the O-RAN architecture. The R1 interface supports the exchange of control signaling information between endpoints, as well as the collection and delivery of data. For example, the R1 interface supports multi-vendor rApps consuming and / or generating R1 services.

[0072] The R1 interface is independent of the NRT-RIC SMO and the specific implementation of the NRT-RIC framework. The R1 interface is defined in an extensible way, which supports the addition of new services and data types without changing the protocol or procedures.

[0073] Specifically, the R1 interface facilitates interconnection between rApps supplied by different vendors and the NRT-RIC framework (ie, facilitates interconnection in a multi-vendor environment). To this end, the R1 interface provides an abstraction level between rApps and the NRT-RIC framework and / or the SMO framework.

[0074] According to an embodiment, the framework of the R1 application protocol specifies R1 services and related service procedures as well as API definitions.

[0075] For example, R1 services and related service processes 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 via the fronthaul M plane, etc.

[0076] To this end, the logical functions that generate RAN OAM-related services that are exposed to rApps via the R1 interface are referred to as O-RAN operation and maintenance (OAM)-related functions. For example, the O-RAN OAM-related functions can implement the generation of O-RAN OAM-related services that are exposed to rApps via the R1 interface, where at least one service may include performing CM conflict mitigation and interfacing, such as 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.

[0077] Interfacing with the near-RT RIC and E2 nodes through the O1 terminal may include O-RAN OAM related functions for receiving fault notifications and obtaining alarm lists from the near-RT RIC and E2 nodes (i.e., E2O-RU), providing configuration changes to the near-RT RIC and E2 nodes, and collecting performance data from the near-RT RIC and E2 nodes.

[0078] Interfacing with the O-RU through the open fronthaul M-plane terminal may include RAN OAM-related functions for receiving fault notifications and obtaining alarm lists from the O-RU, providing configuration changes to the O-RU, and collecting performance data from the O-RU.

[0079] Interfacing with the RAN-specific slice management functions in the SMO framework may include RAN OAM related functions for providing configuration changes related to the RAN-specific network slice and collecting performance data related to the RAN-specific network slice.

[0080] Hereinafter, the rApp may provide (e.g., write) configuration changes to the O-RU, near-RT RIC, and E2 nodes (O-CU, O-DU) via the O1 terminal using the R1 interface (between the rApp and RAN OAM-related functions), and / or provide (e.g., write) configuration changes to the O-RU through the open fronthaul M-plane terminal.

[0081] In accordance with Figure 1 In the related art, rApp communicates with non-anchor functions (including RAN OAM-related functions) via the R1 interface (between rApp and RAN OAM-related functions) to provide (e.g., write) configuration changes to the O-RU, near-RT RIC and E2 nodes (O-CU, O-DU) via the O1 terminal, and / or provide (e.g., write) configuration changes to the O-RU through the open fronthaul M-plane terminal. This communication has not yet been standardized.

[0082] Figure 5The diagram illustrates the operation flow between the rApp and the non-anchor functions of the SMO framework and the NRT-RIC framework according to an embodiment.

[0083] See also Figure 5 The operation flow between rApp and the non-anchor functions of SMO framework and NRT-RIC framework solves the problem of standardizing the process of rApp writing configuration change information to the configuration management service producer (i.e., Figure 4 issues regarding the operation of one or more RAN OAM related functions as described in

[15] .

[0084] To this end, Figure 5 In the embodiment, the operation flow is performed by an rApp playing the role of a CM service consumer, which requests configuration change information related to one or more managed entities (e.g., at least one request to write configuration changes to one or more O-RAN OAM related functions) (e.g., via O1 termination to O-RU, near-RT RIC and E2 nodes (O-CU, O-DU) and / or through open fronthaul M-plane termination to O-RU)).

[0085] According to an embodiment, the 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.

[0086] Furthermore, according to another embodiment, the rApp may determine the need to write configuration change information based on data consumed from the NRT-RIC framework and unanchored (i.e., non-anchored) functions (such as, for example, one or more O-RAN OAM related functions) via the R1 interface.

[0087] In operation 1 , the rApp requests to write a configuration change (eg, a message related to writing a configuration change, which provides information to RAN OAM related functions) to the NRT-RIC framework (ie, the NRT-RIC hosting the NRT-RIC framework).

[0088] For example, the rApp may provide an rApp identifier, optional query conditions, and information about the managed entity and the desired configuration change, etc. On the other hand, 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 an R1 interface between the rApp and the NRT-RIC framework (i.e., the NRT-RIC hosting the NRT-RIC framework).

[0089] In operation 2, the O-RAN OAM-related function (i.e., NRT-RIC) checks whether the rApp is authorized to initiate a request to write the configuration change to one or more O-RAN OAM-related functions. For example, authorization and authentication can be performed in collaboration with at least one SME service function that acts as a gatekeeper. In an embodiment, the O-RAN OAM-related function may not be aware of the rApp, so the O-RAN OAM-related function can collaborate with at least one SME function to authenticate the rApp and verify that the rApp is authorized to request to write the configuration change to the O-RAN node (e.g., to the O-RU, Near RT RIC and E2 nodes (O-CU, O-DU) via the O1 terminal, and / or to the O-RU through the open fronthaul M-plane terminal).

[0090] In operation 3, the O-RAN OAM-related function (i.e., NRT-RIC) verifies the information provided by the request to write the configuration change to one or more O-RAN OAM functions. For example, in an embodiment, the verification may include verifying the syntax and message content of the request as defined by O-RAN and other subsequent standards organizations (such as, for example, 3GPP, ITU-T, etc.). In addition, in another embodiment, the verification may include resolving conflicts between requests from multiple rApps, which may include similar target nodes (i.e., similar O-RAN nodes) that may or may not have similar configurations that may have similar effects on the operation of, for example, an E2 open radio unit (i.e., E2 / O-RU).

[0091] Depending on the embodiment, O-RAN OAM related functions may not verify, for example, whether the E2 node or O-RU is allowed to make certain configuration changes and / or is available or present in the O-RAN. According to this embodiment, these details may be captured in other O-RAN OAM related services that focus on generating data based on retrieval requests for configuration solutions of E2 nodes and / or O-RUs within the O-RAN.

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

[0093] According to an embodiment, the RAN OAM-related function can create the job regardless of whether the E2 / O-RU node is available. To this end, based on information provided by at least one request to write a configuration change, one or more O-RAN OAM-related functions (e.g., an O-RAN OAM-related service dedicated to generating data based on a request to retrieve a configuration solution of an E2 node and / or O-RU within the O-RAN) determine the availability of the E2 node and / or O-RU (E2 / O-RU) to write a configuration change; and, based on the information provided by at least one request to write a configuration change, the one or more O-RAN OAM-related functions create a job for writing the configuration change for the E2 / O-RU, regardless of the availability of the E2 / O-RU.

[0094] In operation 5, the O-RAN OAM-related function (i.e., 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 job creation, one or more O-RAN OAM-related functions may send a job identifier including information about the job to the rApp via the NRT-RIC framework and via the R1 interface.

[0095] According to an embodiment, the rApp may use information about the created job to query or receive notifications about the status and / or results of the requested configuration changes.

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

[0097] Figure 6 A method for implementing write configuration changes in an SMO framework including an NRT-RIC framework in an open radio access network O-RAN according to an embodiment is illustrated.

[0098] See also Figure 6 In step 601, an O-RAN Operation and Maintenance (OAM) function (i.e., NRT-RIC) receives at least one request to write a configuration change to one or more O-RAN Operation and Maintenance (OAM) functions from an rApp via an R1 interface between the rApp and the NRT-RIC framework.

[0099] According to an embodiment, at least one request to write configuration changes to one or more O-RAN OAM-related functions includes a 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.

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

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

[0102] In step 604 , based on the verification, the one or more O-RAN OAM related functions create a job for writing the configuration change based on information provided by the at least one request to write the configuration change to the one or more O-RAN OAM related functions.

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

[0104] Figure 7 A method for authorizing at least one request from a rApp to write a configuration change according to an embodiment is illustrated.

[0105] See also Figure 7 , in step 701, the Service Management and Exposure (SME) function of the NRT-RIC framework (i.e., NRT-RIC) authenticates the rApp from which it receives at least one request to write a configuration change to one or more O-RAN OAM-related functions.

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

[0107] According to an embodiment, authorization and authentication may be performed in collaboration with at least one SME service function acting as a gatekeeper. In another embodiment, the O-RAN OAM-related functions may not be aware of the rApp, and therefore, the O-RAN OAM-related functions may collaborate with at least one SME function to authenticate the rApp and verify that the rApp is authorized to request to write configuration changes to the O-RAN node (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 open fronthaul M-plane termination).

[0108] Figure 8 A method for validating information provided by at least one request to write a configuration change to one or more O-RAN OAM-related functions according to an embodiment is illustrated.

[0109] See also Figure 8 In step 801, one or more O-RAN OAM-related functions (ie, NRT-RIC) verify at least one of syntax and message content of at least one request to write a configuration change to the one or more O-RAN OAM-related functions.

[0110] In step 802 , based on the verification, one or more O-RAN OAM-related functions resolve conflicts between requests from multiple rApps to write configuration changes for similar O-RAN nodes.

[0111] For example, in an embodiment, verification may include verifying the syntax and message content of the request as defined by O-RAN and other subsequent standards organizations (such as, for example, 3GPP, ITU-T, etc.).

[0112] Furthermore, according to another embodiment, the verification may include resolving conflicts between requests from multiple rApps that may include similar target nodes (i.e., similar O-RAN nodes) that may or may not have similar configurations that may have similar effects on the operation of, for example, an E2 Open Radio Unit (i.e., E2 / O-RU).

[0113] According to yet another embodiment, the O-RAN OAM-related functions may not verify, for example, whether the E2 node or O-RU is allowed to make certain configuration changes and / or is available or present in the O-RAN. According to this embodiment, these details may be captured in other O-RAN OAM-related services that focus on generating data based on retrieval requests for configuration solutions of E2 nodes and / or O-RUs within the O-RAN.

[0114] Figure 9A method for creating a job for writing configuration changes according to an embodiment is illustrated.

[0115] See also Figure 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., another other O-RAN OAM-related service focused on generating data based on a retrieval request for a configuration solution of an E2 node and / or O-RU within the O-RAN) (i.e., NRT-RIC) determines availability of an E2 node and / or open radio unit (E2 / O-RU) for writing a configuration change.

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

[0117] Figure 10 Illustrated is a method for receiving at least one job query via an R1 interface between an rApp and an NRT-RIC framework within an O-RAN architecture according to an example embodiment.

[0118] See also Figure 10 In step 1001, based on the job creation, one or more O-RAN OAM related functions send a job identifier including information about the job to the rApp via the NRT-RIC framework and via the R1 interface.

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

[0120] According to an embodiment, the rApp may send a job query via the R1 interface between the rApp and the NRT-RIC framework within the O-RAN architecture, wherein at least one job query may be at least one query for notification of the job status and a query for the job result of the requested configuration change.

[0121] according to Figures 5 to 10 The embodiments illustrated in the provide systems and methods for implementing write configuration changes to allow network operators to efficiently manage (standardize) rApps from multiple vendors, thereby facilitating the multi-vendor operability required in O-RAN's NRT-RIC architecture.

[0122] As a result, rApps from multiple vendors are allowed to request configuration changes to be written to one or more O-RAN OAM functions from multiple vendors (i.e., to O-RAN nodes from multiple vendors), thereby optimizing the multi-vendor operability of the entire O-RAN.

[0123] An example use case according to an embodiment may be as follows:

[0124]

[0125] 8 Use cases for RAN OAM-related services

[0126] <<Change #1 Start>>>

[0127] 8.x RAN OAM-related use case Y: Write configuration changes.

[0128] 8.x.1 Overview

[0129] This use case allows an rApp acting as a CM service consumer to write information related to configuration changes of one or more managed entities.

[0130] 8.x.2 Use Case Background and Objectives

[0131] A rApp acting as a CM service consumer can write information related to configuration changes of one or more managed entities from a configuration management service producer.

[0132] 8.x.3 Entities / resources involved in the use case

[0133] 1) RAN OAM-related functions as a configuration management service producer

[0134] a. Receive a "write configuration change" request to write configuration change information related to one or more managed entities.

[0135] b. Provide a response indicating the success or failure of the Write Configuration request.

[0136] 2) rApp

[0137] a. Support the function of initiating a "write configuration change" request process to write configuration change information.

[0138] 8.x.4 Solution

[0139] 8.x.4.1 Writing Configuration Change Information

[0140] Table 8.x.4.1-1: Write configuration change information use case.

[0141]

[0142]

[0143] @startuml

[0144] !pragma teoz true

[0145] skinparam ParticipantPadding 70

[0146] skinparam BoxPadding 10

[0147] skinparam defaultFontSize 12

[0148] skinparam lifelineStrategy solid

[0149] box"Non-RT RIC"#whitesmoke

[0150] box#ivory

[0151] participant"rApp"as rapp

[0152] endbox

[0153] box"Non-anchored functions in SMO / Non-RT RIC Framework"#cadetBlue

[0154] participant"RAN OAM-related functions"as cmsp

[0155] endbox

[0156] endbox

[0157] rapp->cmsp:< <r1>>Write Configuration Changes request\n(rAppId,queryCriteria,configuration changes information)

[0158] cmsp-->cmsp:AuthZ

[0159] note right

[0160] Check authorization in

[0161] Collaboration with SME functions

[0162] end note

[0163] cmsp-->cmsp:Validate request

[0164] cmsp->rapp:< <r1>>Write Configuration Changes response\n(Success / partialsucceess / failure,ConfigurationData)

[0165] @enduml

[0166] Figure 11 Refers to the calling process between rApp and NRT-RIC. Figure 11 , Figure 11 Involving original Figure 8 .3.4.1-1: Write configuration change information use case flow chart.

[0167] 8.3.5 Required Data: A Write Configuration Change Request for writing configuration change information includes the rAppId, query criteria (including information about the relevant managed entity), and information about the requested configuration changes (a list of attributes and expected values ​​for the managed entity). The Write Configuration Response includes the written expected and unchanged configuration changes as configuration data and is a success result only if all expected configuration changes have been written to the mentioned managed entity; a partial success result if some but not all expected configuration changes have been written to the mentioned managed entity due to specified or unspecified reasons; and a failure result if all expected configuration changes have not been written to the mentioned managed entity due to specified or unspecified reasons.

[0168] Note: Whether the rAppId will be passed as a separate piece of information, embedded in the authorization information, or implied by the authorization information depends on the design of the authorization mechanism.

[0169] <<END OF CHANGES #1>>

[0170] 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 implementations.

[0171] Some embodiments may involve systems, methods, and / or computer-readable media at any possible level of technical detail integration. In addition, one or more of the above components may be implemented as instructions stored on a computer-readable medium and executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include a computer-readable non-transitory storage medium (or multiple media) having computer-readable program instructions thereon for causing a processor to perform operations.

[0172] Computer-readable storage media can be a tangible device that can save and store instructions used by an instruction execution device. Computer-readable storage media can be, for example, but not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the above devices. A non-exhaustive list of more specific examples of computer-readable storage media includes: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), 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 mechanical encoding device (such as a raised structure with instructions recorded in a punched card or groove), and any suitable combination of the above devices. As used herein, computer-readable storage media should not be interpreted as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagated by waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted by wires.

[0173] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device, or downloaded to an external computer or external storage device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network). The network can include copper transmission cables, optical fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to be stored in a computer-readable storage medium within the corresponding computing / processing device.

[0174] The computer readable program code / instructions for performing operations can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​(such as Smalltalk, C++, etc.) and procedural programming languages ​​(such as "C" programming language or similar programming languages). The computer readable program code / instructions can be executed entirely on the user's computer, partially on the user's computer (as a standalone software package), partially on the user's computer and partially on a remote computer, or completely on a remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer via any type of network (including a local area network (LAN) or a wide area network (WAN)), or can be connected to an external computer (for example, by using the Internet of an Internet service provider). In some embodiments, an electronic circuit comprising, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) can execute the computer readable program instructions in the following manner: the electronic circuit is personalized using the state information of the computer readable program instructions to perform various aspects or operations.

[0175] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device create components for implementing the functions / actions specified in the flowcharts and / or block diagrams. These computer-readable program instructions can also be stored in a computer-readable storage medium, which can direct the computer, programmable data processing device, and / or other equipment to operate in a specific manner, so that the computer-readable storage medium storing the instructions constitutes an article of manufacture, which includes instructions for implementing various aspects of the functions / actions specified in one or more blocks of the flowcharts and / or block diagrams.

[0176] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device, thereby producing a computer-implemented process, such that the instructions executed on the computer, other programmable apparatus, or other device implement the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0177] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operations of possible implementations of systems, methods, and computer-readable media according to various embodiments. In this regard, each block in the flowchart or block diagram may represent a portion of a module, segment, or instruction, which includes one or more executable instructions for implementing (multiple) specified logical functions. The method, computer system, and computer-readable medium may include more blocks, fewer blocks, different blocks, or blocks arranged differently than those depicted in the accompanying drawings. In some alternative implementations, the functions noted in the blocks may not occur in the order shown in the figures. For example, two blocks shown in succession may actually be executed simultaneously or substantially simultaneously, or may sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, as well as combinations of blocks in the block diagram and / or flowchart, may be implemented by a dedicated hardware system that performs the specified function or action or executes a combination of dedicated hardware and computer instructions.

[0178] Obviously, the systems and / or methods described herein can be implemented in various forms of hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods does not limit the implementation. Therefore, the operation and behavior of the systems and / or methods described herein are not referenced to specific software code, and it is understood that software and hardware can be designed to implement these systems and / or methods based on the description herein.

[0179] Various further respective aspects and features of embodiments of the present disclosure may be defined by the following clauses:

[0180] Clause [1] An apparatus comprising a non-real-time radio access network intelligent controller (NRT-RIC) configured to receive, from an rApp via an R1 interface between the rApp and the NRT-RIC framework, at least one request to write a configuration change to one or more O-RAN operations and maintenance (OAM)-related functions; authorize 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, verify information provided by the at least one request to write the configuration change to the one or more O-RAN OAM-related functions; based on the verification, create a job for writing the configuration change based on the information provided by the at least one request to write the configuration change to the one or more O-RAN OAM-related functions; and based on the job creation, send, to the rApp via the NRT-RIC framework and via the R1 interface, a job identifier including information about the job.

[0181] Clause [2] An apparatus according to clause [1], wherein: at least one request to write a configuration change to one or more O-RAN OAM-related functions includes an rApp identifier and at least one information of one or more desired configuration changes to one or more O-RAN nodes within the O-RAN.

[0182] Clause [3] An apparatus according to clause [1 or 2], wherein the apparatus configured to authorize at least one request from an rApp to write a configuration change to one or more O-RAN OAM-related functions may also be configured to: authenticate, by a service management and exposure (SME) function of the NRT-RIC framework, the rApp from which the at least one request to write a configuration change to one or more O-RAN OAM-related functions is received; and based on the authentication, verify, by the SME function of the NRT-RIC framework, the authorization of the at least one request requested by the rApp to write a configuration change to one or more O-RAN nodes.

[0183] Clause [4] An apparatus according to any one of clauses [1 to 3], wherein the apparatus configured to verify information provided by at least one request to write a configuration change to one or more O-RAN OAM-related functions may also be configured to: verify, by the one or more O-RAN OAM-related functions, at least one of the syntax and message content of the at least one request to write a configuration change to one or more O-RAN OAM-related functions; and based on the verification, resolve, by the one or more O-RAN OAM-related functions, conflicts between requests from multiple rApps to write configuration changes to similar O-RAN nodes.

[0184] Clause [5] An apparatus according to any one of clauses [1 to 4], wherein the apparatus configured to create a job for writing a configuration may further be configured to: determine, by one or more O-RAN OAM-related functions, the availability of an E2 node and / or open radio unit (E2 / O-RU) for writing a configuration change based on information provided by at least one request to write a configuration change; and create, by one or more O-RAN OAM-related functions, for the E2 / O-RU, a job for writing a configuration change based on the information provided by at least one request to write a configuration change, regardless of the availability of the E2 / O-RU.

[0185] Clause [6] An apparatus according to any of clauses [1 to 5], wherein the apparatus may be further configured to: receive at least one job query from the rApp via the R1 interface between the rApp and the NRT-RIC framework within the O-RAN architecture, based on sending a job identifier including information about the job to the rApp.

[0186] Clause [7] An apparatus according to clause [6], wherein the at least one job query can be at least one query for notification of job status and a query for job results of a requested configuration change.

[0187] Clause [8] A method comprises: receiving, from the rApp via an R1 interface between the rApp and the NRT-RIC framework, at least one request to write a configuration change to one or more O-RAN operations and maintenance (OAM)-related functions; 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 by the at least one request to write the configuration change to the one or more O-RAN OAM-related functions; based on the verification, creating, by the one or more O-RAN OAM-related functions, a job for writing the configuration change based on the information provided by the at least one request to write the configuration change to the one or more O-RAN OAM-related functions; and based on the job creation, 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.

[0188] Clause [9] A method according to clause [8], wherein: at least one request to write a configuration change to one or more O-RAN OAM-related functions includes an rApp identifier and at least one information of one or more desired configuration changes to one or more O-RAN nodes within the O-RAN.

[0189] Clause

[10] A method according to clause [8 or 9], wherein the method may further include: authenticating, by the Service Management and Exposure (SME) function of the NRT-RIC framework, the rApp from which at least one request to write a configuration change to one or more O-RAN OAM-related functions is received; and based on the authentication, verifying, by the SME function of the NRT-RIC framework, the authorization of the at least one request of the rApp to request writing a configuration change to one or more O-RAN nodes.

[0190] Clause

[11] A method according to any one of clauses [8 to 10], wherein the method may further comprise: verifying, by the one or more O-RAN OAM-related functions, at least one of the syntax and message content of at least one request to write a configuration change to the one or more O-RAN OAM-related functions; and based on the verification, resolving, by the one or more O-RAN OAM-related functions, conflicts between requests from multiple rApps to write configuration changes to similar O-RAN nodes.

[0191] Clause

[12] A method according to any one of clauses [8 to 11], wherein the method may further comprise: determining, by one or more O-RAN OAM-related functions, the availability of an E2 node and / or open radio unit (E2 / O-RU) for writing configuration changes based on information provided by at least one request to write configuration changes; and creating, by one or more O-RAN OAM-related functions, for the E2 / O-RU, a job for writing configuration changes based on the information provided by at least one request to write configuration changes, regardless of the availability of the E2 / O-RU.

[0192] Clause

[13] A method according to any of clauses [8 to 12], wherein the method may further comprise: receiving at least one job query from the rApp via the R1 interface between the rApp and the NRT-RIC framework within the O-RAN architecture, based on sending a job identifier including information about the job to the rApp.

[0193] Clause

[14] The method of clause

[13] , wherein the at least one job query can be at least one query for notification of job status and a query for job results of a requested configuration change.

[0194] Clause

[15] A non-transitory computer-readable recording medium having recorded thereon instructions executable by at least one processor to perform a method, the method comprising: receiving, from an rApp via an R1 interface between the rApp and an NRT-RIC framework, at least one request to write a configuration change to one or more O-RAN operations and maintenance (OAM)-related functions; authorizing, by 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; based on the authorization, verifying, by the one or more O-RAN OAM-related functions, information provided by the at least one request to write a configuration change to the one or more O-RAN OAM-related functions; based on the verification, creating, by the one or more O-RAN OAM-related functions, a job for writing a configuration change based on the information provided by the at least one request to write a configuration change to the one or more O-RAN OAM-related functions; and based on the job creation, 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.

[0195] Clause

[16] A non-transitory computer-readable recording medium as described in clause

[15] , wherein: at least one request to write a configuration change to one or more O-RAN OAM-related functions includes 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.

[0196] Clause

[17] A non-transitory computer-readable recording medium according to clause [15 or 16], wherein the method may further include: authenticating, by a service management and exposure (SME) function of the NRT-RIC framework, the rApp from which at least one request to write a configuration change to one or more O-RAN OAM-related functions is received; and based on the authentication, verifying, by the SME function of the NRT-RIC framework, the authorization of the at least one request of the rApp to request writing a configuration change to one or more O-RAN nodes.

[0197] Clause

[18] A non-transitory computer-readable recording medium according to any one of clauses [15 to 17], wherein the method may further include: verifying, by one or more O-RAN OAM-related functions, 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; and based on the verification, resolving, by the one or more O-RAN OAM-related functions, conflicts between requests from multiple rApps to write configuration changes to similar O-RAN nodes.

[0198] Clause

[19] A non-transitory computer-readable recording medium according to any one of clauses [15 to 18], wherein the method may further include: determining, by one or more O-RAN OAM-related functions, the availability of an E2 node and / or open radio unit (E2 / O-RU) for writing a configuration change based on information provided by at least one request to write a configuration change; and creating, by one or more O-RAN OAM-related functions, a job for writing a configuration change for the E2 / O-RU based on the information provided by at least one request to write a configuration change, regardless of the availability of the E2 / O-RU.

[0199] Clause

[20] A non-transitory computer-readable recording medium according to any one of clauses [15 to 19], wherein the method may further include: receiving at least one job query from the rApp via the R1 interface between the rApp and the NRT-RIC framework within the O-RAN architecture based on sending a job identifier including information about the job to the rApp.

Claims

1. A device comprising: A non-real-time radio access network intelligent controller (NRT-RIC) configured to: receiving, from the rApp via an R1 interface between the rApp and the NRT-RIC framework, at least one request to write a configuration change to one or more O-RAN operations and maintenance (OAM) related functions; authorizing the at least one request from the rApp to write a configuration change to the one or more O-RAN OAM-related functions; validating, based on the authorization, information provided by the at least one request to write a configuration change to one or more O-RAN OAM-related functions; based on the verification, creating a job for writing the configuration change based on the information provided by the at least one request to write the configuration change to one or more O-RAN OAM-related functions; as well as Upon job creation, a job identifier including information about the job is sent to the rApp via the NRT-RIC framework and via the R1 interface.

2. The device according to claim 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 to one or more O-RAN nodes within the O-RAN.

3. The apparatus of claim 1 , wherein the at least one processor 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 is further configured to: authenticating 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; and Based on the authentication, the authorization of at least one request of the rApp to write a configuration change to one or more O-RAN nodes is verified.

4. The apparatus of claim 1 , wherein the apparatus configured to verify the information provided by the at least one request to write a configuration change to one or more O-RAN OAM-related functions is further configured to: verifying at least one of syntax and message content of the at least one request to write a configuration change to one or more O-RAN OAM-related functions; and Based on the verification, conflicts between requests from multiple rApps to write configuration changes for similar O-RAN nodes are resolved.

5. The apparatus according to claim 1 , wherein the apparatus configured to create a job for writing the configuration is further configured to: determining, based on said information provided by said at least one request to write a configuration change, said availability of an E2 node and / or an open radio unit (E2 / O-RU) for writing said configuration change; and For the E2 / O-RU, the job for writing the configuration change is created based on the information provided by the at least one request to write the configuration change, regardless of the availability of the E2 / O-RU.

6. The apparatus according to claim 1, wherein the apparatus is further configured to: At least one job query is received from the rApp via an R1 interface between the rApp and the NRT-RIC framework within the O-RAN architecture based on sending a job identifier including information about the job to the rApp. 7 . The apparatus of claim 6 , wherein the at least one job query is at least one query for notification of a job status and a query for a job result of the requested configuration change.

8. A method comprising: receiving, from the rApp via an R1 interface between the rApp and the NRT-RIC framework, at least one request to write a configuration change to one or more O-RAN operations and maintenance (OAM) related functions; authorizing, by 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 by the at least one request to write a configuration change to the one or more O-RAN OAM-related functions based on the authorization; creating, by the one or more O-RAN OAM-related functions, a job for writing the configuration change based on the information provided by the at least one request to write the configuration change to the one or more O-RAN OAM-related functions, based on the verification; as well as Based on job creation, a job identifier including information about the job is sent to the rApp via the NRT-RIC framework and via the R1 interface by the one or more O-RAN OAM related functions.

9. The method according to claim 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.

10. The method according to claim 8, wherein the method further comprises: authenticating, by a Service Management and Exposure (SME) function of the NRT-RIC framework, 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; as well as Based on the authentication, the authorization of at least one request of the rApp to request writing a configuration change to one or more O-RAN nodes is verified by the SME function of the NRT-RIC framework.

11. The method according to claim 10, wherein the method further comprises: verifying, 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 the one or more O-RAN OAM-related functions; as well as Based on the verification, conflicts between requests from multiple rApps to write configuration changes for similar O-RAN nodes are resolved by the one or more O-RAN OAM related functions.

12. The method according to claim 8, further comprising: determining, by said one or more O-RAN OAM-related functions, said availability of an E2 node and / or an Open Radio Unit (E2 / O-RU) for writing said configuration change based on said information provided by said at least one request to write said configuration change; and Creating, by the one or more O-RAN OAM-related functions, the job for writing the configuration change for the E2 / O-RU based on the information provided by the at least one request to write the configuration change, regardless of the availability of the E2 / O-RU.

13. The method according to claim 8, wherein the method further comprises: At least one job query is received from the rApp via an R1 interface between the rApp and the NRT-RIC framework within the O-RAN architecture based on sending a job identifier including information about the job to the rApp.

14. The method of claim 13, 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.

15. A non-transitory computer-readable recording medium having instructions recorded thereon, the instructions being executable by at least one processor to perform a method, the method comprising: receiving, from the rApp via an R1 interface between the rApp and the NRT-RIC framework, at least one request to write a configuration change to one or more O-RAN operations and maintenance (OAM) related functions; authorizing, by 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 by the at least one request to write a configuration change to the one or more O-RAN OAM-related functions based on the authorization; creating, by the one or more O-RAN OAM-related functions, a job for writing the configuration change based on the information provided by the at least one request to write the configuration change to the one or more O-RAN OAM-related functions, based on the verification; as well as Based on job creation, a job identifier including information about the job is sent to the rApp via the NRT-RIC framework and via the R1 interface by the one or more O-RAN OAM related functions.

16. The non-transitory computer-readable recording medium according to claim 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 within the O-RAN.

17. The non-transitory computer-readable recording medium of claim 15, wherein the method further comprises: authenticating, by a Service Management and Exposure (SME) function of the NRT-RIC framework, 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; as well as Based on the authentication, the authorization of at least one request of the rApp to request writing a configuration change to one or more O-RAN nodes is verified by the SME function of the NRT-RIC framework.

18. The non-transitory computer-readable recording medium of claim 17, wherein the method further comprises: verifying, 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 the one or more O-RAN OAM-related functions; as well as Based on the verification, conflicts between requests from multiple rApps to write configuration changes for similar O-RAN nodes are resolved by the one or more O-RAN OAM related functions.

19. The non-transitory computer-readable recording medium of claim 15, wherein the method further comprises: determining, by said one or more O-RAN OAM-related functions, said availability of an E2 node and / or an Open Radio Unit (E2 / O-RU) for writing said configuration change based on said information provided by said at least one request to write said configuration change; and Creating, by the one or more O-RAN OAM-related functions, the job for writing the configuration change for the E2 / O-RU based on the information provided by the at least one request to write the configuration change, regardless of the availability of the E2 / O-RU.

20. The non-transitory computer-readable recording medium of claim 15, wherein the method further comprises: At least one job query is received from the rApp via an R1 interface between the rApp and the NRT-RIC framework within the O-RAN architecture based on sending a job identifier including information about the job to the rApp.

Images