Apparatus and method for implementing the R1-O1 application protocol within a telecommunications network

Abstract

This invention provides a method and apparatus for effectively managing modular applications (rApps) from multiple vendors in a non-real-time radio access network intelligence controller (NRT-RIC) within an open radio access network (O-RAN). [Solution] The processor of an apparatus implementing the NRT-RIC framework is configured to receive at least one request for R1-O1 related services from an rApp hosted by NRT-RIC via the R1 interface, and to send at least one response from the NRT-RIC framework to the rApp via the R1 interface, the request and response being implemented as data types including multiple R1 data models of the R1 application protocol that enable the NRT-RIC framework and the rApp to generate and / or consume data for R1-O1 related services within NRT-RIC.

Description

Technical Field

[0001] This application claims priority based on U.S. Provisional Patent Application No. 63 / 413,274, filed on October 5, 2022, the disclosure of which is hereby incorporated by reference in its entirety.

[0002] Devices and methods consistent with exemplary embodiments of the present disclosure relate to application protocol procedures for the R1 interface in a non-real-time radio access network intelligence controller (NRT-RIC), and more particularly, to application protocol procedures for accessing various services provided to an rApp via the R1 interface by an NRT-RIC platform.

Background Art

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

[0004] Open RAN (O-RAN) technology emerged to allow multiple vendors to provide hardware and / or software to telecommunications systems. For this purpose, O-RAN divides the RAN functionality into a centralized unit (CU), a distributed unit (DU), and a distributed unit (RU). The CU is a logical node for hosting the RAN's Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and / or Packet Data Convergence Protocol (PDCP) sublayers. The DU is a logical node for hosting the RAN's Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY) sublayers. The RU is a physical node that converts radio signals from antennas into digital signals that can be transmitted to the DU via the fronthaul. Because these entities have open protocols and interfaces between them, they can also be developed by different vendors.

[0005] Figure 1 illustrates a conventional O-RAN architecture. Referring to Figure 1, the RAN functionality in the O-RAN architecture is 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 to automate and optimize RAN operation. RICs are classified into two types: non-real-time RICs (NRT-RICs) and near-real-time RICs (nRT-RICs).

[0006] The NRT-RIC is the control point of the non-real-time control loop and operates on a timescale of more than one second within the Service Management and Orchestration (SMO) framework. Its functions are implemented via modular applications called rApps (rApp1, ..., rAppN) and include providing policy-based guidance and refinements across the A1 interface, which is an interface that enables communication between nRT-RICs and nRT RICs; performing data analysis; training and inference of artificial intelligence / machine learning (AI / ML) to optimize the RAN; and / or recommending configuration management actions via the O1 interface, which is an interface that connects the SMO to RAN management elements (e.g., nRT-RIC, O-RAN Centralized Unit (O-CU), O-RAN Distributed Unit (O-DU), etc.).

[0007] The nRT-RIC operates on a timescale of 10 milliseconds to 1 second and connects to the O-DU, O-CU (divided into the O-CU control plane (O-CU-CP) and 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 (NF)) via a near real-time control loop. The nRT-RIC monitors, pauses / stops, overrides, and controls the E2 nodes (O-CU, O-DU, O-eNB) via policies. For example, the nRT-RIC sets policy parameters for activated functions of the E2 nodes. Furthermore, the nRT-RIC hosts xApps to implement functions such as Quality of Service (QoS) optimization, mobility optimization, slice optimization, interference mitigation, load balancing, and security. The two types of RICs work together to optimize the O-RAN. For example, NRT-RIC provides policies, data, and AI / ML models implemented and used by nRT-RIC for RAN optimization via the A1 interface, and nRT-RIC returns policy feedback (i.e., how the policies set by NRT-RIC are performing).

[0008] The SMO framework on which the NRT-RIC is located manages and coordinates the RAN elements. Specifically, the SMO manages and coordinates what is called the O-RAN Cloud (O-Cloud). The O-Cloud is a collection of RICs, O-CUs and O-DUs, supporting software components (e.g., operating systems and runtime environments), and the physical RAN nodes that host 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 on which it resides. Through the O2 interface, the SMO provides infrastructure management services (IMS) and deployment management services (DMS).

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

[0010] The SMO framework in which the NRT-RIC is located manages and coordinates RAN elements. The SMO performs management and orchestration of RAN elements through the following services (i.e., four critical interfaces to O-RAN elements: the A1 interface between the SMO's NRT-RIC and the nRT-RIC for RAN optimization, the O1 interface between the SMO and O-RAN network functions for FCAPS support, the open fronthaul M-plane interface between the SMO and O-RU for FCAPS support in the hybrid model, and the O2 interface between the SMO and O-Cloud for platform resource and workload management). [Overview of the Initiative]

[0011] According to the embodiment, an apparatus and method are provided for implementing the NRT-RIC Non-Real-Time Radio Access Network Intelligent Controller (NRT-RIC) framework, in the role of an R1 service producer, communicating with at least one R1 service consumer rApp hosted by the NRT-RIC based on an R1-O1 application protocol that includes multiple R1 services and R1 service procedures, and the R1-O1 application protocol enables network operators to effectively manage (standardize) rApp applications from multiple vendors to define the requirements of the NRT-RIC platform.

[0012] According to one embodiment, a device for a non-real-time radio access network intelligence controller (NRT-RIC) framework in an open radio access network (O-RAN) comprises a memory for storing instructions and at least one processor, the processor being configured to implement the NRT-RIC framework of the NRT-RIC to receive at least one request for at least one R1-O1 related service from an rApp hosted by the NRT-RIC via an R1 interface in the O-RAN architecture between the rApp and the NRT-RIC framework, and to send at least one response for at least one R1-O1 related service from the NRT-RIC framework to the rApp via the R1 interface, wherein the at least one request and at least one response are implemented as data types comprising multiple R1 data models of an R1 application protocol that enables the NRT-RIC framework and the rApp to generate and / or consume data for at least one R1-O1 related service in the NRT-RIC.

[0013] At least one R1-O1 related service may include an O1 network information (NI) service for providing NI data, and at least one processor may be further configured to implement the NRT-RIC framework to receive NI data requests for the O1-NI service from an rApp hosted by NRT-RIC via the R1 interface in the O-RAN architecture, and to send NI data responses for the O1-NI service from the NRT-RIC framework to the rApp via the R1 interface in the O-RAN architecture, the NI data may include at least one of network configuration information, network topology information, network element status information, geolocation information, and network inventory information.

[0014] At least one R1-O1 related service may include an O1 configuration management (CM) service for accessing the configuration of network elements within the O-RAN, and at least one processor may be further configured to implement the NRT-RIC framework to receive requests for O1-CM services from an rApp hosted by the NRT-RIC via the R1 interface within the O-RAN architecture, and to send responses for O1-CM services from the NRT-RIC framework to the rApp via the R1 interface within the O-RAN architecture.

[0015] A request to the O1-CM service may be a request to retrieve the configuration schema of at least one network element, and the response from the O1-CM service may include the configuration schema.

[0016] A request for the O1-CM service may be a request to read CM data of a network element, and the response may include CM data, or a request for the O1-CM service may include a request to write CM data of a network element.

[0017] At least one R1-O1 related service may include an O1 performance management (PM) service for accessing performance information collected from at least one network element, and at least one processor may be further configured to implement the NRT-RIC framework to receive requests for O1-PM services from an rApp hosted by the NRT-RIC via the R1 interface in the O-RAN architecture, and to send responses for O1-PM services from the NRT-RIC framework to the rApp via the R1 interface in the O-RAN architecture, wherein a request for O1-PM services may be a request to receive performance information.

[0018] At least one R1-O1 related service may include an O1-Fault Management (FM) service for obtaining information about alarms, and at least one processor may be further configured to implement the NRT-RIC framework to receive requests for O1-FM services from an rApp hosted by the NRT-RIC for obtaining information about at least one alarm, and to send responses for the O1-FM services from the NRT-RIC framework to the rApp.

[0019] According to one embodiment, a method implemented by a Non-Real-Time Radio Access Network Intelligence Controller (NRT-RIC) framework in an Open Radio Access Network (O-RAN) to provide R1-O1 related services includes receiving at least one request for at least one R1-O1 related service from an rApp hosted by the NRT-RIC via the R1 interface in the O-RAN architecture between the rApp and the NRT-RIC framework, and sending at least one response for at least one R1-O1 related service from the NRT-RIC framework to the rApp via the R1 interface, wherein the at least one request and at least one response are implemented as data types comprising multiple R1 data models of an R1 application protocol that enables the NRT-RIC framework and the rApp to generate and / or consume data for at least one R1-O1 related service in the NRT-RIC.

[0020] At least one R1-O1 related service may include an O1 Network Information (NI) service for providing NI data, where receiving includes receiving an NI data request for the O1-NI service from an rApp hosted by NRT-RIC via the R1 interface in the O-RAN architecture, and transmitting includes transmitting an NI data response for the O1-NI service from the NRT-RIC framework to the rApp via the R1 interface in the O-RAN architecture, where the NI data may include at least one of network configuration information, network topology information, network element status information, geolocation information, and network inventory information.

[0021] At least one R1-O1 related service may include an O1 Configuration Management (CM) service for accessing the configuration of network elements within the O-RAN, and receiving includes receiving a request for an O1-CM service from an rApp hosted by the NRT-RIC via the R1 interface within the O-RAN architecture, and transmitting includes sending a response for an O1-CM service from the NRT-RIC framework to the rApp via the R1 interface within the O-RAN architecture.

[0022] A request to the O1-CM service may be a request to retrieve the configuration schema of at least one network element, and the response from the O1-CM service may include the configuration schema.

[0023] A request for the O1-CM service may be a request to read CM data of a network element, and the response may include CM data, or a request for the O1-CM service may be a request to write CM data of a network element.

[0024] At least one R1-O1 related service may include an O1 performance management (PM) service for accessing performance information collected from at least one network element, where receiving includes receiving a request for an O1-PM service from an rApp hosted by NRT-RIC via the R1 interface in the O-RAN architecture, and transmitting includes sending a response for an O1-PM service from the NRT-RIC framework to the rApp via the R1 interface in the O-RAN architecture, where the request for an O1-PM service is a request to receive performance information.

[0025] At least one R1-O1 related service may include an O1-Fault Management (FM) service for obtaining information about alarms, and receiving includes receiving a request for an O1-FM service for obtaining information about at least one alarm from an rApp hosted by the NRT-RIC, and transmitting includes transmitting a response for the O1-FM service from the NRT-RIC framework to the rApp.

[0026] According to one embodiment, a non-temporary computer-readable recording medium recording instructions executable by at least one processor implementing a non-real-time radio access network intelligence controller (NRT-RIC) framework in an open radio access network (O-RAN) for performing a method for providing R1-O1 related services, the method comprising: receiving at least one request for at least one R1-O1 related service from an rApp hosted by the NRT-RIC via an R1 interface in the O-RAN architecture between the rApp and the NRT-RIC framework; and transmitting at least one response for at least one R1-O1 related service from the NRT-RIC framework to the rApp via the R1 interface, wherein the at least one request and at least one response are implemented as data types comprising multiple R1 data models of an R1 application protocol that enables the NRT-RIC framework and the rApp to generate and / or consume data for at least one R1-O1 related service in the NRT-RIC.

[0027] At least one R1-O1 related service may include an O1 Network Information (NI) service for providing NI data, where receiving includes receiving an NI data request for the O1-NI service from an rApp hosted by NRT-RIC via the R1 interface in the O-RAN architecture, and transmitting includes transmitting an NI data response for the O1-NI service from the NRT-RIC framework to the rApp via the R1 interface in the O-RAN architecture, where the NI data may include at least one of network configuration information, network topology information, network element status information, geolocation information, and network inventory information.

[0028] At least one R1-O1 related service can include an O1 configuration management (CM) service for accessing the configuration of network elements within O-RAN, receiving includes receiving a request for the O1-CM service from an rApp hosted by the NRT-RIC via the R1 interface within the O-RAN architecture, and transmitting includes transmitting a response for the O1-CM service from the NRT-RIC framework to the rApp via the R1 interface within the O-RAN architecture.

[0029] The request for the O1-CM service may be a request to search for the configuration schema of at least one network element, the response for the O1-CM service can include the configuration schema, the request for the O1-CM service may be a request to read the CM data of a network element, the response can include the CM data, or the request for the O1-CM service may be a request to write the CM data of a network element.

[0030] At least one R1-O1 related service can include an O1 performance management (PM) service for accessing performance information collected from at least one network element, receiving includes receiving a request for the O1-PM service from an rApp hosted by the NRT-RIC via the R1 interface within the O-RAN architecture, transmitting includes transmitting a response for the O1-PM service from the NRT-RIC framework to the rApp via the R1 interface within the O-RAN architecture, and the request for the O1-PM service may be a request to receive performance information.

[0031] At least one R1-O1 related service may be an O1-Fault Management (FM) service for obtaining information about alarms, and receiving includes receiving a request for an O1-FM service for obtaining information about at least one alarm from an rApp hosted by the NRT-RIC, and transmitting includes sending a response for an O1-FM service from the NRT-RIC framework to the rApp.

[0032] Additional embodiments are some of which are described below, some of which are evident from the description, and some may be realized by the practice of the embodiments presented in this disclosure. [Brief explanation of the drawing]

[0033] Features, aspects, and advantages of certain exemplary embodiments of the present disclosure are described below with reference to the accompanying drawings, in which similar reference numerals indicate similar elements.

[0034] [Figure 1] This shows the O-RAN architecture in related technologies. [Figure 2] This is a diagram of an exemplary environment in which the systems and / or methods described herein may be implemented. [Figure 3] This is a diagram illustrating exemplary components of a device according to an embodiment. [Figure 4] This document illustrates the NRT-RIC framework within O-RAN according to an embodiment. [Figure 5] This document illustrates an exemplary embodiment of the R1 application protocol between an R1 service consumer and an R1 service producer present in the NRT-RIC rApp and / or NRT-RIC framework. [Figure 6A] This document describes the service procedures for R1-O1 related services and the R1 application protocol for R1-O1 related services according to exemplary embodiments. [Figure 6B]This document describes the service procedures for R1-O1 related services and the R1 application protocol for R1-O1 related services according to exemplary embodiments. [Figure 6C] This document describes the service procedures for R1-O1 related services and the R1 application protocol for R1-O1 related services according to exemplary embodiments. [Figure 6D] This document describes the service procedures for R1-O1 related services and the R1 application protocol for R1-O1 related services according to exemplary embodiments. [Figure 7] This illustrates the flow of the R1-O1 Network Information NI Data Service, including a request (i.e., an initial message) "GET NI Data REQUEST" and a response "GET NI Data RESPONSE" (or "GET NI Data FAILURE"), according to an exemplary embodiment. [Figure 8] The following is an example embodiment illustrating the flow of the R1-O1 configuration management CM data service, including a first request (i.e., initial message) "CM SCHEMAS REQUEST", a first response "GET CM SCHEMAS RESPONSE" (or "GET CM SCHEMAS FAILURE"), a second request "GET (READ) CM DATA REQUEST", a second response "GET CM DATA REQUEST RESPONSE" (or "GET PM DATA REQUEST FAILURE"), and a third request "WRITE CM REQUEST" and a third response "WRITE CM REQUEST RESPONSE" (or "WRITE CM REQUEST FAILURE"). [Figure 9] This illustrates the flow of the R1-O1 Performance Management PM service, including a request (i.e., initial message) "GET PM Data REQUEST" and a response "GET PM Data RESPONSE" (or "GET PM Data FAILURE"), using an exemplary embodiment. [Figure 10]The flow of the R1-O1 fault management FM service, including a request (i.e., initial message) "GET FM Data REQUEST" and a response "GET FM Data RESPONSE" (or "GET FM Data FAILURE"), is shown in an exemplary embodiment. [Modes for carrying out the invention]

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

[0036] The foregoing disclosures are illustrative and illustrative, but are not intended to be exhaustive or to limit implementations to the exact forms disclosed. Modifications and variations are possible in light of the foregoing disclosures or may be derived from implementations. Furthermore, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). In addition, it is understood that in the flowcharts and operation descriptions provided below, one or more operations may be omitted, one or more operations may be added, one or more operations may be performed (at least partially) simultaneously, and the order of one or more operations may be changed.

[0037] It will be apparent that the systems and / or methods described herein can be implemented in different forms of hardware, firmware, or combinations of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods is not limited to the implementation form. Therefore, the operation and behavior of the systems and / or methods have been described herein without reference to specific software code. It will be understood that software and hardware can be designed to implement the systems and / or methods based on the descriptions herein.

[0038] Certain combinations of features are described in the claims and / or disclosed herein, but these combinations do not limit the disclosure of possible implementations. In fact, many of these features can be combined in ways not specifically described in the claims and / or disclosed herein. Each dependent claim listed below may directly depend on only one claim, but the disclosure of possible implementations includes each dependent claim in combination with all other claims in the claim set.

[0039] Any element, action, or instruction used herein should not be construed as important or essential unless expressly stated otherwise. Furthermore, where used herein, the articles “a” and “an” are intended to include one or more items and may be used interchangeably with “one or more.” When only one item is intended, the term “one” or similar language should be used. Also, where used herein, terms such as “has,” “have,” “having,” “include,” and “including” are intended to be non-restrictive. Additionally, the phrase “based on” should mean “at least partially based on” unless otherwise specified. Furthermore, expressions such as “at least one of [A] and [B]” or “at least one of [A] or [B]” should be understood as including only A, only B, or both A and B.

[0040] Figure 2 is a diagram of an exemplary environment 200 in which the system and / or method described herein can be implemented. As shown in Figure 3, the environment 200 may include user devices 210, a platform 220, and a network 220. The devices in environment 200 can be interconnected via wired connections, wireless connections, or a combination of wired and wireless connections. In embodiments, any of the functions and operations described below with reference to Figures 4 to 10 can be performed by any combination of the elements shown in Figure 3.

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

[0042] 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 so that certain software components can be swapped in or swapped out as needed. Thus, Platform 220 can be easily and / or quickly reconfigured for different uses.

[0043] In some implementations, as shown in the figure, platform 220 may be hosted in a cloud computing environment 222. In particular, the implementations described herein describe platform 220 as being hosted within a cloud computing environment 222, but in some implementations, platform 220 may not be cloud-based (i.e., it may be implemented outside a cloud computing environment), or it may be partially cloud-based.

[0044] The cloud computing environment 222 includes an environment that hosts the platform 220. The cloud computing environment 222 can provide services such as computing, software, data access, and storage, which do not require the end user's (e.g., user device 210) knowledge of the physical location and configuration of the system and / or device hosting the platform 220. As shown in the diagram, the cloud computing environment 222 may include a group of computing resources 224 (collectively referred to as "computing resources (plural) 224" and individually as "computing resource (singular) 224").

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

[0046] As further shown in Figure 2, the computing resource 224 includes 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.

[0047] Application 224-1 includes one or more software applications that can be provided or accessed by the user device 210. Application 224-1 may eliminate the need to install and run software applications on the user device 210. For example, Application 224-1 may 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 and receive information to and from one or more other applications 224-1 via a virtual machine 224-2.

[0048] A virtual machine 224-2 includes a software implementation of a machine (e.g., a computer) that runs programs like a physical machine. Depending on its application and the degree to which the virtual machine 224-2 corresponds to an actual machine, it may be either a system virtual machine or a process virtual 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 run a single program and can support a single process. In some implementations, a virtual machine 224-2 can run on behalf of a user (e.g., a user device 210) and manage the infrastructure of a cloud computing environment 222, such as data management, synchronization, or long-term data transfer.

[0049] Virtualized storage 224-3 includes one or more storage systems and / or one or more devices that use virtualization technology within 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 the extraction (or separation) of logical storage from physical storage so that the storage system can be accessed regardless of the physical storage or heterogeneous structure. Separation gives the storage system administrator flexibility in how the administrator manages the storage for end users. File virtualization can eliminate the dependency between data accessed at the file level and where the file is physically stored. This can enable optimization of storage usage, server consolidation, and / or performance of non-disruptive file migration.

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

[0051] Network 220 includes one or more wired and / or wireless networks. For example, Network 220 may include cellular networks (e.g., fifth-generation (5G) networks, long-term evolution (LTE) networks, third-generation (3G) networks, code division multiple access (CDMA) networks, etc.), public land mobile networks (PLMN), local area networks (LANs), wide area networks (WANs), metropolitan area networks (MANs), telephone networks (e.g., public switched telephone networks (PSTNs)), private networks, ad hoc networks, intranets, the Internet, fiber optic-based networks, etc., and / or combinations thereof, or combinations of other types of networks.

[0052] The number and arrangement of devices and networks shown in Figure 2 are provided as examples. In practice, there may be additional devices and / or networks, fewer devices and / or networks, different devices and / or networks, or devices and / or networks in different arrangements than those shown in Figure 2. Furthermore, two or more devices shown in Figure 2 may be implemented within a single device, or a single device shown in Figure 2 may be implemented as multiple distributed devices. In addition, or instead, 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 another set of devices in environment 200.

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

[0054] Bus 310 includes components that enable communication between components of 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), graphics processing unit (GPU), accelerated processing unit (APU), microprocessor, microcontroller, digital signal processor (DSP), field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), or another type of processing component. In some implementations, the processor 320 includes one or more processors that can be programmed to perform functions. The memory 320 comprises random-access memory (RAM), read-only memory (ROM), and / or other forms of dynamic or static storage devices (e.g., flash memory, magnetic memory, and / or optical memory) for storing information and / or instructions used by the processor 320.

[0055] The storage component 330 stores information and / or software related to the operation and use of device 300. For example, the storage component 330, along with a corresponding drive, may include hard disks (e.g., magnetic disks, optical disks, magneto-optical disks, and / or solid-state disks), compact discs (CDs), digital versatile discs (DVDs), floppy disks, cartridges, magnetic tapes, and / or other types of non-temporary computer-readable media. The input component 350 includes components that enable device 300 to receive information via user input (e.g., touchscreen displays, keyboards, keypads, mice, buttons, switches, and / or microphones). In addition, or instead, the input component 350 may include sensors for sensing information (e.g., global positioning system (GPS) components, accelerometers, gyroscopes, and / or actuators). 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)).

[0056] The communication interface 370 includes transceiver-like components (e.g., transceivers and / or separate receivers and transmitters) that enable device 300 to communicate with other devices via wired connections, wireless connections, or a combination of wired and wireless connections. The communication interface 370 may also enable device 300 to receive information from and / or provide information to other devices. For example, the communication interface 370 may include Ethernet interfaces, optical interfaces, coaxial interfaces, infrared interfaces, radio frequency (RF) interfaces, universal serial bus (USB) interfaces, Wi-Fi interfaces, cellular network interfaces, and the like.

[0057] Device 300 can perform one or more processes as described herein. Device 300 can perform these processes in response to a processor 320 that executes software instructions stored in a non-temporary computer-readable medium, such as memory 320 and / or storage component 330. Computer-readable medium is defined herein as a non-temporary memory device. A memory device includes a memory space within a single physical storage device or a memory space that extends across multiple physical storage devices.

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

[0059] In addition, or instead, hard wired circuits may be used in place of or in combination with software instructions to perform one or more processes described herein. Therefore, the implementations described herein are not limited to any particular combination of hardware circuits and software.

[0060] The number and arrangement of components shown in Figure 3 are provided as an example. In practice, device 300 may include additional components, fewer components, different components, or components arranged differently compared to the components shown in Figure 3. In addition, or instead, a set of components of device 300 (e.g., one or more components) may perform one or more functions, which are described as being performed by another set of components of device 300.

[0061] In the embodiment, any one of the operations or processes shown in Figures 4 to 10 may be implemented by or using any one of the elements shown in Figures 2 to 3.

[0062] Figure 4 shows the NRT-RIC framework (or platform) and NRT-RIC-hosted rApp for the R1 interface in the SMO framework system architecture and the O1, O2, and A1 interfaces in O-RAN according to an embodiment.

[0063] Referring to Figure 4, NRT-RIC represents a subset of the SMO framework's functions. NRT-RIC can access other SMO framework functions and thereby influence (i.e., control and / or execute) what is carried across the O1 and O2 interfaces (e.g., the execution of configuration management (CM) and / or performance management (PM)).

[0064] NRT-RIC includes the NRT-RIC framework. The NRT-RIC framework includes R1 service exposure functionality, which handles R1 services provided in exemplary embodiments, among several other functions. Generally, NRT-RIC functions within the NRT-RIC framework support authorization, authentication, registration, discovery, communication support, etc., for rAPPs.

[0065] An NRT-RIC application (rApp) is an application that leverages the capabilities available in the NRT-RIC framework and / or SMO framework to provide value-added services related to RAN operation and optimization. The scope of rApps includes, but is not limited to, wireless resource management, data analytics, and information enhancement.

[0066] To this end, the NRT-RIC framework generates and / or consumes R1 services according to embodiments of the present invention via the R1 interface. The R1 interface terminates at the R1 terminus of the NRT-RIC framework. The R1 terminus connects to the NRT-RIC framework and rApp via the R1 interface, enabling the NRT-RIC framework and rApp to access R1 services via the R1 interface by exchanging messages / data (i.e., requests and responses including data models).

[0067] Furthermore, the NRT-RIC framework includes A1-related functions. These A1-related functions support, for example, A1 logical termination, A1 policy coordination and cataloging, and A1-EI coordination and cataloging.

[0068] The data management and exposure services within the NRT-RIC framework distribute data generated or collected by data producers to data consumers according to their needs (e.g., function management (FM) / consumption management (CM) / production management (PM) data to rApp, or CM conversion from rApp to O-RAN via the O1 interface).

[0069] The NRT-RIC framework further includes an external terminal. The external terminal supports data exchange between the NRT-RIC framework and, for example, external AI / ML functions, enrichment information (EI) sources, or external monitoring.

[0070] 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 monitor AI / ML models deployed to NRT-RIC.

[0071] Furthermore, the NRT-RIC framework includes A2-related features, such as A2 logical termination, A2 policy coordination, and cataloging.

[0072] Referring further to Figure 4, within NRT-RIC, the R1 interface is an open logical interface within the O-RAN architecture between NRT-RIC's rApp and the NRT-RIC framework. The R1 interface supports the exchange of control signaling information and the collection and distribution of data between endpoints. The R1 interface enables, for example, a multi-vendor rApp to consume and / or generate R1 services.

[0073] The R1 interface is independent of the SMO of NRT-RIC and any specific implementation of the NRT-RIC framework. The R1 interface is defined in an extensible manner that allows for the addition of new services and data types without requiring any changes to the protocol or procedures.

[0074] In particular, the R1 interface facilitates interconnection between rApps supplied by different vendors and the NRT-RIC framework (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 framework and / or the SMO framework.

[0075] In conventional technology, the NRT-RIC framework does not specify an R1 application protocol for O1-related services.

[0076] One embodiment of the R1 application protocol framework specifies R1 services and associated service procedures, as well as API definitions.

[0077] For example, R1 services and associated service procedures may include R1-Service Management & Exposure (SME) services, R1-Data Management & Exposure (DME) services, R1-A1 services, R1-O1 services, R1-O2 data services, R1-AIML services, and so on. The following describes R1-O1 services and service procedures according to exemplary embodiments.

[0078] Each API specification may include specifications such as R1-SME API, R1-DME API, R1-A1 API, R1-O1 API, R1-O2 API, and R1-AIML API.

[0079] Figure 5 shows an R1 application protocol between an R1 service consumer and an R1 service producer, present in the NRT-RIC rApp and / or NRT-RIC framework, according to an exemplary embodiment.

[0080] Referring to Figure 5, the R1 AP framework defined by the exemplary embodiment includes R1 services and associated service procedures. The R1 AP framework provides standardized R1 APs so that R1 service consumer rAPPs associated with (or consuming) at least one of the R1-SME service, R1-DME service, R1-A1 service, R1-O1 service, R1-O2 data service, and R1-AIML service can connect to the NRT-RIC framework of NRT-RIC.

[0081] In an exemplary embodiment, communication via the R1 interface may be via the R1-SME API, aR1-DME API, R1-A1 API, R1-O2 API, R1-AIML API, R1-O1 API, etc.

[0082] In exemplary embodiments, the API may be configured to provide an interface for a separate R1 service. In exemplary embodiments, one or more (or all) APIs may be configured as a single API for the R1 interface. In either case, the R1 AP protocol provides data types and structures (i.e., data models) for implementing exemplary embodiments.

[0083] According to the parallel communication between the NRT-RIC framework and rApp, the R1 AP is based on signaling between the R1 service consumer and the R1 service producer, which exists in either the rApp or the NRT-RIC framework.

[0084] For example, rApp may be associated with an R1 service consumer (i.e., consuming O-RAN telemetry data), and the NRT-RIC framework may be associated with an R1 service producer (i.e., generating (providing) O-RAN telemetry data). Interaction between the R1 service consumer and the R1 service producer via the R1 interface is based on the service framework used for 3GPP network functions (NFs), as specified, for example, in 3GPP® TS 23.501[6] section 7.1.2. The service framework used for 3GPP NFs specifies that requests are sent from the R1 consumer side (e.g., rApp) and responses and notifications are sent from the R1 producer side (e.g., the NRT-RIC framework).

[0085] According to the 3GPP NF framework, in one exemplary embodiment, an R1 producer (e.g., the NRT-RIC framework) handles the resources (i.e., network elements of O-RAN) on which an R1 consumer (e.g., rApp) performs an operation. Consequently, the terms R1 consumer and R1 producer do not refer to the direction of data transfer over the R1 interface. For this reason, R1 consumers and R1 producers can send requests and responses, respectively.

[0086] Referring further to Figure 5, the O1-related services and service procedures for the R1 interface include the O1 Configuration Management (CM) service, the O1 Network Information (NI) service, the O1 Performance Management (PM) service, and the O1 Fault Management (FM) service. The O1-related services generated by the NRT-RIC framework and / or the SMO framework provide access to administration and maintenance (OAM) functions.

[0087] In particular, with respect to R1 AP, O1-related services generated by the NRT-RIC framework and / or SMO framework enable R1 service consumers (e.g., rApp) to obtain information about alarms related to O1 telemetry parameters, modify O1 telemetry parameters and their acknowledgment status, obtain performance information related to network elements in O-RAN, obtain the current configuration of at least one network element in O-RAN, provide changes to the configuration of at least one network element in O-RAN, and obtain additional information related to at least one network element in O-RAN.

[0088] Figures 6A to 6D illustrate the R1-O1 related services and the service procedures of the R1 application protocol for the R1-O1 related services according to exemplary embodiments. The R1-O1 related services and service procedures identify at least one network element (e.g., CU, DU, etc.) within the O-RAN architecture as shown in Figure 1 or Figure 4.

[0089] Referring to Figure 6A, the R1 AP's request and response to the O1 Network Information (NI) service procedure includes a first NI request (i.e., an initial message sent from the R1 service consumer rApp) and a first NI response. The NI data service provides O-RAN-related NI data (e.g., consumer information) aggregated from multiple sources and available to the SMO framework via the O-RAN architecture (i.e., the NRT-RIC framework within the SMO framework) as shown in Figures 4 and 5. For example, the NI data may include at least one of the following: configuration, topology, network element status, geographic location, inventory, etc.

[0090] With respect to Network Information (NI) services, the term NI “Service Consumer” refers to the role of an rApp that consumes NI services. NI “Service Producer” refers to the role of a logical O1-related function in the NRT-RIC framework and / or SMO framework that generates NI services.

[0091] For this purpose, the NI service procedure by R1 AP includes at least a first request “GET NI Data REQUEST” initiated by the R1 service consumer rApp and a first response “GET NI Data RESPONSE” for a successful operation (or “GET NI Data FAILURE” for a failed operation).

[0092] Referring to Figure 6B, the R1 AP's requests and responses to the CM service procedure enable the R1 service consumer rApp to access configuration information related to the managed entities obtained by the CM service producer. The CM service further enables the service consumer to request configuration changes related to the managed entities (e.g., network elements in O-RAN).

[0093] With respect to Configuration Management (CM) services, the term CM "Service Consumer" refers to the role of an rApp that consumes CM services. The term CM "Service Producer" refers to the role of logical O1-related functions in the NRT-RIC framework and / or SMO framework that generate CM services.

[0094] In particular, the CM service producer on the R1 interface (i.e., the NRT-RIC framework with the SMO framework) enables the R1 service consumer rApp to look up the configuration schema, read configuration data, and write configuration changes.

[0095] For this purpose, requests and responses from an R1 AP to the O1 Configuration Management (CM) service and service procedures include, initiated by an R1 service consumer rApp, a first request GET CM SCHEMAS REQUEST to retrieve a configuration schema, a first response GET CM SCHEMAS REQUEST to return the CM attributes of the configuration schema (or a first response GET CM SCHEMAS FAILURE if the operation fails), a second request GET (READ) CM DATA REQUEST to read configuration data (e.g., the value of an attribute identified in the corresponding configuration schema), a second response GET CM DATA REQUEST RESPONSE to provide the configuration data (or a second response GET CM DATA REQUEST FAILURE if the operation fails), and a third request WRITE CM REQUEST and a third response WRITE CM REQUEST RESPONSE to write CM data (or a third response WRITE CM REQUEST FAILURE if the operation fails).

[0096] Referring to Figure 6C, the R1 AP's requests and responses to the Performance Management (PM) service procedure enable the R1 service consumer rApp to access performance information collected from at least one network element within the O-RAN by the R1 service producer (e.g., NRT-RIC). With respect to PM services, the term PM “Service Consumer” refers to the role of the rApp that consumes the PM service. The term PM “Service Producer” refers to the role of the logical O1-related functions in the NRT-RIC framework and / or SMO framework that generate the PM service.

[0097] For this purpose, the PM service procedure includes a first request (i.e., an initial message) "GET PM Data REQUEST" initiated by the R1 consumer service rApp to query performance information from at least one network element of O-RAN (e.g., to extract performance information from at least one network element or subscribe to an information provision service), and a first response "GET PM Data RESPONSE" (e.g., to provide performance information from at least one network element if a performance-related event occurs in response to the request, or to push performance information based on the subscription) (or a first response "GET PM Data FAILURE" if the operation fails).

[0098] Referring to Figure 6D, the R1 AP's requests and responses to the O1-Fault Management (FM) service procedure enable the R1 service consumer rApp to obtain information about alarms (e.g., event trigger notifications) regarding the performance of network elements within the O-RAN generated by the R1 service producer (e.g., NRT-RIC).

[0099] With respect to O1-FM services, the term FM "Service Consumer" refers to the role of an rApp that consumes O1-FM services. The term FM "Service Producer" refers to the role of logical O1-related functions in the NRT-RIC framework and / or SMO framework that generate FM services.

[0100] For this purpose, the R1-O1 FM service procedure includes a first request "GET FM Data REQUEST" and a first response "GET FM Data RESPONSE" (or a first response "GET FM Data FAILURE" if the operation fails), initiated by the R1 consumer service rApp, to query alarm information. In this case, the request may be a request to pull alarm information, or it may be a subscription request to receive push notifications of alarms (e.g., in real time or near real time).

[0101] Figure 7 shows the flow of the R1-O1 NI Data Service, including a request (i.e., initial message) "GET NI Data REQUEST" and a response "GET NI Data RESPONSE" (or "GET NI Data FAILURE"), according to an exemplary embodiment.

[0102] Referring to Figure 7, among multiple requests and responses, the rApp hosted by NRT-RIC sends the first request, "GET NI Data REQUEST," to the NRT-RIC framework via the R1 interface. The NRT-RIC framework (i.e., the O1-related functions of the NRT-RIC framework) returns the first response, "GET NI Data RESPONSE" (or, if the operation fails, the first response, "GET NI Data FAILURE").

[0103] Figure 8 shows the flow of the R1-O1 configuration management CM data service, including a first request (i.e., initial message) "CM SCHEMAS REQUEST", a first response "GET CM SCHEMAS RESPONSE" (or "GET CM SCHEMAS FAILURE"), a second request "GET (READ) CM DATA REQUEST", a second response "GET CM DATA REQUEST RESPONSE" (or "GET CM DATA REQUEST FAILURE"), and a third request "WRITE CM REQUEST" and a third response "WRITE CM REQUEST RESPONSE" (or "WRITE CM REQUEST FAILURE"), according to an exemplary embodiment.

[0104] Referring to Figure 8, in operation 1, the rApp hosted by NRT-RIC sends a first request to the NRT-RIC framework via the R1 interface to retrieve the configuration schema "GET CM SCHEMAS REQUEST". The NRT-RIC framework (i.e., the O1-related functions of the NRT-RIC framework) returns a first response "GET CM SCHEMAS RESPONSE" (or a first response "GET CM SCHEMAS FAILURE" if the operation fails).

[0105] In operation 2, the NRT-RIC framework receives a second request from rApp, "GET CM DATA REQUEST," to read configuration data, and sends a second response, "GET CM DATA REQUEST RESPONSE" (or "GET CM DATA REQUEST FAILURE" if the operation fails).

[0106] In operation 3, the NRT-RIC framework receives a third request from rApp, "WRITE CM REQUEST," to write the configuration, and sends a third response, "WRITE CM REQUEST RESPONSE" (or "WRITE CM REQUEST FAILURE" if the operation fails).

[0107] Figure 9 shows the flow of the R1-O1 Performance Management PM service, including a request (i.e., initial message) "GET PM Data REQUEST" and a response "GET PM Data RESPONSE" (or "GET PM Data FAILURE"), according to an exemplary embodiment. Referring to Figure 9, an rApp hosted in NRT-RIC sends a first request, "GET PM Data REQUEST," to the NRT-RIC framework via the R1 interface. The NRT-RIC framework (i.e., the O1-related functions of the NRT-RIC framework) returns a first response, "GET PM Data RESPONSE" (or a first response, "GET PM Data FAILURE," if the operation fails).

[0108] Figure 10 illustrates the flow of the R1-O1 fault management FM service, including a request (i.e., an initial message) "GET FM Data REQUEST" and a response "GET FM Data RESPONSE" (or "GET FM Data FAILURE"), in an exemplary embodiment. Referring to Figure 10, the rApp hosted by NRT-RIC sends a first request "GET FM Data REQUEST" to the NRT-RIC framework via the R1 interface. The NRT-RIC framework (i.e., the O1-related functions of the NRT-RIC framework) returns a first response "GET FM Data RESPONSE" (or a first response "GET FM Data FAILURE" if the operation fails).

[0109] According to the embodiment, an apparatus and method are provided for implementing an R1-O1 application protocol that includes multiple R1 services and R1 service procedures, and the R1-O1 application protocol enables network operators to effectively manage (standardize) rApp applications from multiple vendors to define the requirements of the NRT-RIC platform.

[0110] The foregoing disclosures are illustrative and descriptive, but are not intended to be exhaustive or to limit implementations to the exact forms disclosed. Modifications and variations are possible in light of the foregoing disclosures or may be derived from the practice of the implementations.

[0111] Some embodiments may relate to systems, methods, and / or computer-readable media in integration at any possible level of technical detail. Furthermore, one or more of the components described above may be implemented as instructions stored on a computer-readable medium and executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include computer-readable non-temporary storage media (or more media) having computer-readable program instructions for causing a processor to perform an action.

[0112] A computer-readable storage medium can be a tangible device capable of holding and storing instructions for use by an instruction-executing device. A computer-readable storage medium may, but is not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer diskettes, hard disks, random-access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random-access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital multipurpose disks (DVDs), memory sticks, floppy disks, mechanically encoded devices such as punch cards or grooved raised structures on which instructions are recorded, and any suitable combination of the foregoing. The computer-readable storage medium as used herein should not be construed as a transient signal itself, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., optical pulses through optical fiber cables), or electrical signals transmitted through wires.

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

[0114] Computer-readable program code / instructions for performing an operation may be either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk and C++, and procedural programming languages ​​such as the "C" programming language or similar programming languages. Computer-readable program instructions can run 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 entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or wide area network (WAN), or it may be connected to an external computer (for example, via the Internet using an Internet service provider). In some embodiments, for example, an electronic circuit including a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA) can execute computer-readable program instructions by personalizing the electronic circuit using state information of computer-readable program instructions in order to perform an action or operation.

[0115] These computer-readable program instructions may also be provided to the processor of a general-purpose computer, a dedicated computer, or other programmable data processing device for producing a machine, thereby generating means for instructions executed via the processor of the computer or other programmable data processing device to implement functions / operations specified in one or more blocks of a flowchart and / or block diagram, or both. These computer-readable program instructions may also be stored in a computer-readable storage medium that can instruct a computer, a programmable data processing device, and / or other device, or a combination thereof, to function in a particular manner, thereby including a product in which the computer-readable storage medium internally storing the instructions contains instructions that implement modes of functions / operations specified in one or more blocks of a flowchart and / or block diagram, or both.

[0116] Computer-readable program instructions may also be loaded into a computer, other programmable device, or other device to perform a series of operational steps on the computer, other programmable device, or other device to generate a computer implementation process, thereby enabling the instructions executed on the computer, other programmable device, or other device to implement a function / operation specified in one or more blocks of a flowchart and / or block diagram, or both.

[0117] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media in various embodiments. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions containing one or more executable instructions for implementing a specified logical function(s). Methods, computer systems, and computer-readable media may include additional blocks, fewer blocks, different blocks, or blocks arranged differently compared to those shown in the figures. In some alternative implementations, the functions described in the blocks may be performed in a different order than shown in the figures. For example, two consecutively shown blocks may actually be executed simultaneously or substantially simultaneously, or blocks may sometimes be executed in reverse order depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, or both, and any combination of blocks in a block diagram or flowchart, or both, may be implemented by a dedicated hardware-based system that performs a specified function or operation, or a combination of dedicated hardware and computer instructions.

[0118] It will be apparent that the systems and / or methods described herein may be implemented in different forms of hardware, firmware, or combinations of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods is not limited to the implementation form. Therefore, the operation and behavior of the systems and / or methods are described herein without reference to specific software code, and it should be understood that software and hardware may be designed to implement the systems and / or methods based on the descriptions herein.

Claims

1. A device for a Non-Real-Time Radio Access Network Intelligence Controller (NRT-RIC) framework in an Open Radio Access Network (O-RAN), Memory for storing instructions, The system comprises at least one processor, the processor implementing the NRT-RIC framework of NRT-RIC, Receiving at least one request for at least one R1-O1 related service from an rApp hosted by NRT-RIC via the R1 interface in the O-RAN architecture between the rApp and the NRT-RIC framework, The NRT-RIC framework is configured to send at least one response to the at least one R1-O1 related service via the R1 interface to the rApp, The device wherein the at least one request and the at least one response are implemented as data types comprising a plurality of R1 data models of the NRT-RIC framework and the R1 application protocol that enables the rApp to generate and / or consume data for the at least one R1-O1 related service within the NRT-RIC.

2. The at least one R1-O1 related service includes an O1 network information (NI) service for providing NI data, The at least one processor implements the NRT-RIC framework, The rApp hosted by the NRT-RIC receives the NI data request for the O1-NI service via the R1 interface in the O-RAN architecture. The NRT-RIC framework is further configured to send NI data responses for the O1-NI service from the rApp via the R1 interface in the O-RAN architecture. The aforementioned NI data includes at least one of the following: network configuration information, network topology information, network element status information, geolocation information, and network inventory information. The apparatus according to claim 1.

3. The at least one R1-O1 related service includes an O1 configuration management (CM) service for accessing the configuration of network elements within the O-RAN. The at least one processor implements the NRT-RIC framework, The rApp hosted by the NRT-RIC receives a request for the O1-CM service via the R1 interface in the O-RAN architecture. The NRT-RIC framework is further configured to send the response of the O1-CM service from the rApp via the R1 interface in the O-RAN architecture. The apparatus according to claim 1.

4. The apparatus according to claim 3, wherein the request of the O1-CM service is a request to retrieve a configuration schema of at least one network element, and the response of the O1-CM service includes the configuration schema.

5. The request for the O1-CM service is a request to read the CM data of a network element, and the response includes the CM data or The request for the O1-CM service is a request to write CM data to the network element. The apparatus according to claim 3.

6. The at least one R1-O1 related service includes an O1 performance management (PM) service for accessing performance information collected from at least one network element. The at least one processor implements the NRT-RIC framework, The rApp hosted by the NRT-RIC receives a request for the O1-PM service via the R1 interface in the O-RAN architecture. The NRT-RIC framework is further configured to send the response of the O1-PM service from the rApp via the R1 interface in the O-RAN architecture, The aforementioned request for the O1-PM service is a request to receive the performance information. The apparatus according to claim 1.

7. The at least one R1-O1 related service includes an O1-Fault Management (FM) service for obtaining information about alarms, The at least one processor implements the NRT-RIC framework, The NRT-RIC receives a request for the O1-FM service from the rApp hosted by the NRT-RIC to obtain information about at least one alarm. The NRT-RIC framework is further configured to transmit the response of the O1-FM service to the rApp. The apparatus according to claim 1.

8. A method implemented by a Non-Real-Time Radio Access Network Intelligence Controller (NRT-RIC) framework in an Open Radio Access Network (O-RAN) for providing R1-O1 related services, Receiving at least one request for at least one R1-O1 related service from an rApp hosted by NRT-RIC via the R1 interface in the O-RAN architecture between the rApp and the NRT-RIC framework, This includes transmitting at least one response of the at least one R1-O1 related service from the NRT-RIC framework to the rApp via the R1 interface, A method wherein the at least one request and the at least one response are implemented as data types comprising a plurality of R1 data models of the NRT-RIC framework and the R1 application protocol that enables the rApp to generate and / or consume data of the at least one R1-O1 related service within the NRT-RIC.

9. The at least one R1-O1 related service includes an O1 network information (NI) service for providing NI data, The receiving described above includes receiving an NI data request for the O1-NI service from the rApp hosted by the NRT-RIC via the R1 interface in the O-RAN architecture, The aforementioned transmission includes transmitting the NI data response of the O1-NI service from the NRT-RIC framework to the rApp via the R1 interface in the O-RAN architecture, The aforementioned NI data includes at least one of the following: network configuration information, network topology information, network element status information, geolocation information, and network inventory information. The method according to claim 8.

10. The at least one R1-O1 related service includes an O1 configuration management (CM) service for accessing the configuration of network elements within the O-RAN. The receiving described above includes receiving a request for the O1-CM service from the rApp hosted by the NRT-RIC via the R1 interface in the O-RAN architecture, The transmission includes transmitting the response of the O1-CM service from the NRT-RIC framework to the rApp via the R1 interface in the O-RAN architecture. The method according to claim 8.

11. The method according to claim 8, wherein the request of the O1-CM service is a request to retrieve a configuration schema of at least one network element, and the response of the O1-CM service includes the configuration schema.

12. The request for the O1-CM service is a request to read the CM data of a network element, and the response includes the CM data or The request for the O1-CM service is a request to write CM data to the network element. The method according to claim 8.

13. The at least one R1-O1 related service includes an O1 performance management (PM) service for accessing performance information collected from at least one network element. The receiving described above includes receiving a request for the O1-PM service from the rApp hosted by the NRT-RIC via the R1 interface in the O-RAN architecture, The aforementioned transmission includes transmitting the response of the O1-PM service from the NRT-RIC framework to the rApp via the R1 interface in the O-RAN architecture, The aforementioned request for the O1-PM service is a request to receive the performance information. The method according to claim 8.

14. The at least one R1-O1 related service includes an O1-Fault Management (FM) service for obtaining information about alarms, The receiving described above includes receiving a request for the O1-FM service from the rApp hosted by the NRT-RIC to obtain information regarding at least one alarm, The aforementioned transmission includes transmitting the response of the O1-FM service from the NRT-RIC framework to the rApp. The method according to claim 8.

15. A non-temporary computer-readable recording medium that records instructions executable by at least one processor implementing a non-real-time radio access network intelligence controller (NRT-RIC) framework in an open radio access network (O-RAN) in order to perform a method for providing R1-O1 related services, wherein the method is: Receiving at least one request for at least one R1-O1 related service from an rApp hosted by NRT-RIC via the R1 interface in the O-RAN architecture between the rApp and the NRT-RIC framework, This includes sending at least one response of the at least one R1-O1 related service from the NRT-RIC framework to the rApp via the R1 interface, A non-temporary computer-readable recording medium, wherein the at least one request and the at least one response are implemented as data types comprising a plurality of R1 data models of the NRT-RIC framework and the R1 application protocol that enables the rApp to generate and / or consume data for the at least one R1-O1 related service within the NRT-RIC.

16. The at least one R1-O1 related service includes an O1 network information (NI) service for providing NI data, The receiving described above includes receiving an NI data request for the O1-NI service from the rApp hosted by the NRT-RIC via the R1 interface in the O-RAN architecture, The aforementioned transmission includes transmitting the NI data response of the O1-NI service from the NRT-RIC framework to the rApp via the R1 interface in the O-RAN architecture, The aforementioned NI data includes at least one of the following: network configuration information, network topology information, network element status information, geolocation information, and network inventory information. The non-temporary computer-readable recording medium according to claim 15.

17. The at least one R1-O1 related service includes an O1 configuration management (CM) service for accessing the configuration of network elements within the O-RAN. The receiving described above includes receiving a request for the O1-CM service from the rApp hosted by the NRT-RIC via the R1 interface in the O-RAN architecture, The aforementioned transmission includes transmitting the response of the O1-CM service from the NRT-RIC framework to the rApp via the R1 interface in the O-RAN architecture. The non-temporary computer-readable recording medium according to claim 15.

18. The request of the O1-CM service is a request to retrieve the configuration schema of at least one network element, and the response of the O1-CM service includes the configuration schema. The O1-CM service request is a request to read the CM data of a network element, and the response includes the CM data or, The request for the O1-CM service is a request to write CM data to the network element. The non-temporary computer-readable recording medium according to claim 15.

19. The at least one R1-O1 related service includes an O1 performance management (PM) service for accessing performance information collected from at least one network element. The receiving described above includes receiving a request for the O1-PM service from the rApp hosted by the NRT-RIC via the R1 interface in the O-RAN architecture, The aforementioned transmission includes transmitting the response of the O1-PM service from the NRT-RIC framework to the rApp via the R1 interface in the O-RAN architecture, The aforementioned request for the O1-PM service is a request to receive the performance information. The non-temporary computer-readable recording medium according to claim 15.

20. The at least one R1-O1 related service includes an O1-Fault Management (FM) service for obtaining information about alarms, The receiving described above includes receiving a request for the O1-FM service from the rApp hosted by the NRT-RIC to obtain information regarding at least one alarm, The aforementioned transmission includes transmitting the response of the O1-FM service from the NRT-RIC framework to the rApp. The non-temporary computer-readable recording medium according to claim 15.

Images