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

Abstract

An apparatus and method for a non-real-time radio access network smart controller (NRT-RIC) framework in an open radio access network (O-RAN). The apparatus includes: a memory storing instructions; and at least one processor configured to implement an NRT-RIC framework to: receive, via an R1 interface within the O-RAN architecture, at least one request for at least one R1-O1 related service from an rApp hosted by the NRT-RIC; and transmitting, via the R1 interface, at least one response of the at least one R1-O1 related service from the NRT-RIC framework to the rApp; wherein the at least one request and the at least one response are implemented as a data type comprising a plurality of R1 data models of the R1 application protocol, the data type enabling the NRT-RIC framework and the rApp to generate and / or consume data of the at least one R1-O1 related service in the NRT-RIC.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application is based upon and claims priority to U.S. Provisional Patent Application No. 63 / 413,274 filed on October 5, 2022, the entire contents of which are incorporated herein by reference. Technical Field

[0003] Apparatus and methods consistent with example embodiments of the present disclosure relate to processes for application protocols of the R1 interface in a non-real-time radio access network intelligent controller (NRT-RIC), and more specifically to processes for application protocols of accessing different services provided by the NRT-RIC platform to rApps through the R1 interface. Background Art

[0004] The Radio Access Network (RAN) is an important component in a telecommunication system as it connects the end-user equipment (or UE) to the rest of the network. The RAN comprises a combination of various network elements (NEs) that connect the end-user equipment to the core network. Traditionally, the hardware and / or software of a particular RAN is vendor specific.

[0005] Open RAN (O-RAN) technology has emerged to enable multiple vendors to provide hardware and / or software to telecommunications systems. To this end, O-RAN decomposes RAN functions into centralized units (CU), distributed units (DU), and radio units (RU). CU is a logical node for hosting the radio resource control (RRC), service data adaptation protocol (SDAP), and / or packet data convergence protocol (PDCP) sublayers of the RAN. DU is a logical node for hosting the radio link control (RLC), media access control (MAC), and physical (PHY) sublayers of the RAN. RU is a physical node that converts the radio signal from the antenna into a digital signal, which can be sent to the DU via fronthaul. Because there are open protocols and interfaces between these entities, they can be developed by different vendors.

[0006] Figure 1 The figure shows the O-RAN architecture of the prior art. Figure 1 , RAN functions in the O-RAN architecture are controlled and optimized by RIC. RIC is a software-defined component that implements modular applications to facilitate multi-vendor operability required in O-RAN systems and to automate and optimize RAN operations. RIC is divided into two types: 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 (rApp 1, ..., rApp N), and include: providing policy-based guidance and enrichment across the A1 interface, which is an interface that enables communication between NRT-RIC and nRT-RIC; performing data analysis; artificial intelligence / machine learning (AI / ML) training and reasoning for RAN optimization; and / or recommending configuration management actions through 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.).

[0008] The nRT-RIC operates on a time scale between 10 milliseconds and 1 second and is connected to the O-DU, O-CU (decomposed into the O-CU control plane (O-CU-CP) and the O-CU user plane (O-CU-UP)), and the open evolved NodeB (O-eNB) via the E2 interface. The nRT-RIC uses the E2 interface to control the underlying RAN elements (E2 nodes / network functions (NFs)) in a near real-time control loop. The nRT-RIC monitors, suspends / stops, overturns, and controls the E2 nodes (O-CU, O-DU, and O-eNB) via policies. For example, the nRT-RIC sets policy parameters for the activation functions of the E2 nodes. In addition, the nRT-RIC hosts xApps to implement functions such as quality of service (QoS) optimization, mobility optimization, slicing optimization, interference mitigation, load balancing, security, etc. These two types of RICs work together to optimize O-RAN. For example, NRT-RIC provides policies, data, and AI / ML models enforced and used by nRT-RIC 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 manages and orchestrates RAN elements. Specifically, the SMO manages and orchestrates the so-called O-Ran Cloud (O-Cloud). The O-Cloud is a collection of physical RAN nodes that host the RIC, O-CU and O-DU, supporting software components (e.g., operating system and runtime environment), and the SMO itself. In other words, the SMO manages the O-Cloud from the inside. The O2 interface is the interface between the SMO and the O-Cloud where it resides. Through the O2 interface, the SMO provides infrastructure management services (IMS) and deployment management services (DMS).

[0010] On the other hand, O-Cloud is a cloud computing platform that includes a collection of physical infrastructure nodes that meet O-RAN requirements and are used to host relevant 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 NRT-RIC resides manages and orchestrates RAN elements. SMO performs the following services (i.e., management and orchestration of RAN elements through four key interfaces with O-RAN elements): A1 interface between NRT-RIC and nRT-RIC in SMO for RAN optimization; O1 interface between SMO and O-RAN network functions for FCAPS support; open fronthaul M-plane interface between SMO and O-RU for FCAP support in the case of a hybrid model; O2 interface between SMO and O-Cloud for platform resource and workload management. Summary of the invention

[0012] According to an embodiment, an apparatus and method for implementing a non-real-time radio access network intelligent controller (NRT-RIC) NRT-RIC framework are provided, which, in its role as an R1 service producer, communicates with at least one R1 service consumer rApp hosted by the NRT-RIC based on an R1-O1 application protocol including multiple R1 services and R1 service processes, wherein the R1-O1 application protocol allows network operators to effectively manage (standardize) rApp applications from multiple vendors to define the requirements of the NRT-RIC platform.

[0013] According to an embodiment, a device for a non-real-time radio access network intelligent controller (NRT-RIC) framework in an open radio access network (O-RAN) includes: a memory storing instructions; and at least one processor, the at least one 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 within the O-RAN architecture between the rApp and the NRT-RIC framework; and 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 at least one request and at least one response are implemented as data types of multiple R1 data models including an R1 application protocol, which enables the NRT-RIC framework and the rApp to generate and / or consume data of at least one R1-O1 related service in the NRT-RIC.

[0014] At least one R1-O1 related service may include an O1-NI service for providing network information (NI) data, and the at least one processor may also be configured to implement the NRT-RIC framework to: receive an NI data request for the O1-NI service from an rApp hosted by the NRT-RIC via an R1 interface within the O-RAN architecture; and send an NI data response for the O1-NI service from the NRT-RIC framework to the rApp via the R1 interface within the O-RAN architecture, and 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.

[0015] At least one R1-O1 related service may include an O1-Configuration Management (CM) service for accessing the configuration of a network element in the O-RAN, and the at least one processor is also configured to implement the NRT-RIC framework to: receive a request for the O1-CM service from an rApp hosted by the NRT-RIC via an R1 interface within the O-RAN architecture; and send a response for the O1-CM service from the NRT-RIC framework to the rApp via the R1 interface within the O-RAN architecture.

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

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

[0018] 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 the at least one processor may also be configured to implement the NRT-RIC framework to: receive a request for the O1-PM service from an rApp hosted by the NRT-RIC via an R1 interface within the O-RAN architecture; and send 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 for receiving performance information.

[0019] At least one R1-O1 related service may include an O1-Fault Management (FM) service for obtaining information about an alarm, and the at least one processor may also be configured to implement the NRT-RIC framework to: receive a request for the O1-FM service for obtaining information about at least one alarm from an rApp hosted by the NRT-RIC; and send a response for the O1-FM service from the NRT-RIC framework to the rApp.

[0020] According to an embodiment, a method for providing R1-O1 related services is implemented by a non-real-time radio access network intelligent controller (NRT-RIC) framework in an open radio access network (O-RAN), 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 within 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 at least one request and at least one response are implemented as data types of multiple R1 data models including an R1 application protocol, which enables the NRT-RIC framework and the rApp to generate and / or consume data of at least one R1-O1 related service in the NRT-RIC.

[0021] At least one R1-O1 related service may include an O1-NI service for providing network information (NI) data, receiving includes: receiving a NI data request for the O1-NI service from an rApp hosted by the NRT-RIC via the R1 interface within the O-RAN architecture, sending includes: sending a NI data response for the O1-NI service from the NRT-RIC framework to the rApp via the R1 interface within the O-RAN architecture, and 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.

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

[0023] The request of the O1-CM service may be a request to retrieve a configuration pattern of at least one network element, and the response of the O1-CM service may include the configuration pattern.

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

[0025] 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; 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; sending includes: sending 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 is a request to receive performance information.

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

[0027] According to one embodiment, a non-transitory computer-readable recording medium having instructions executable by at least one processor recorded thereon, the at least one processor implementing a non-real-time radio access network intelligent controller (NRT-RIC) framework in an open radio access network (O-RAN) to execute 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 within 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 at least one request and at least one response are implemented as data types of multiple R1 data models including an R1 application protocol, which enables the NRT-RIC framework and the rApp to generate and / or consume data of at least one R1-O1 related service in the NRT-RIC.

[0028] At least one R1-O1 related service may include an O1-NI service for providing network information (NI) data, receiving includes: receiving a NI data request for the O1-NI service from an rApp hosted by the NRT-RIC via the R1 interface within the O-RAN architecture, sending includes: sending a NI data response for the O1-NI service from the NRT-RIC framework to the rApp via the R1 interface within the O-RAN architecture, and 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.

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

[0030] The request for the O1-CM service may be a request to retrieve a configuration mode of at least one network element, and the response of the O1-CM service may include the configuration mode; the request for the O1-CM service may be a request to read CM data of the network element, and the response may include the CM data; or the request for the O1-CM service may be a request to write CM data of the network element.

[0031] 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; 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; sending includes: sending 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 for receiving performance information.

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

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

[0034] Features, aspects, and advantages of certain exemplary embodiments of the present disclosure will be described below with reference to the accompanying drawings, in which like reference numerals represent like elements, and in which:

[0035] Figure 1 The diagram illustrates an O-RAN architecture in the prior art;

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

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

[0038] Figure 4 illustrates a NRT-RIC framework within an O-RAN according to an embodiment;

[0039] Figure 5 illustrates an R1 application protocol between an R1 service producer and an R1 service consumer residing in an rApp and / or in an NRT-RIC framework of an NRT-RIC according to an example embodiment;

[0040] 6A to 6D describe a service process of an R1-O1 related service and an R1 application protocol for the R1-O1 related service according to an example embodiment;

[0041] Figure 7 illustrates the flow of an R1-O1 network information NI data service according to an example embodiment, the service including a request (i.e., initial message) "Get NI Data Request" and a response "Get NI Data Response" (or "Get NI Data Failed");

[0042] Figure 8 The flow of the R1-O1 configuration management CM data service according to an example embodiment is illustrated, the service including a first request (i.e., initial message) "CM mode request", a first response "get CM mode response" (or "get CM mode failure"), a second request "get (read) CM data request", a second response "get CM data request response" (or "get PM data request failure"), a third request "write CM request", and a third response "write CM request response" (or "write CM request failure");

[0043] Fig. 9 illustrates a flow of an R1-O1 performance management PM service according to an example embodiment, the service including a request (ie, initial message) "Get PM Data Request" and a response "Get PM Data Response" (or "Get PM Data Failure"); and

[0044] Fig.10The flow of the R1-O1 fault management FM service according to an example embodiment is illustrated, the service comprising a request (ie, initial message) "Get FM Data Request" and a response "Get FM Data Response" (or "Get FM Data Failure"). DETAILED DESCRIPTION

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

[0046] The above disclosure provides illustration and description, but is not intended to be exhaustive or to limit implementation to the disclosed precise form. According to the above disclosure, modification and variation are possible, or can be obtained from the practice of implementation. In addition, one or more features or parts of an embodiment can be incorporated into another embodiment (or one or more features of another embodiment) or combined with it. In addition, in the flow chart and the operation description provided below, it can be understood that one or more operations can be omitted, one or more operations can be added, one or more operations can be performed simultaneously (at least in part), and the order of one or more operations can be switched.

[0047] It is obvious that the system and / or method described herein can be implemented with different forms of hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code for implementing these systems and / or methods does not limit these implementations. Therefore, the operation and behavior of the system and / or method are described herein without reference to specific software codes. It should be understood that software and hardware can be designed to implement these systems and / or methods based on the description herein.

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

[0049] Unless explicitly stated, no element, act, or instruction used herein should be interpreted as critical or essential. In addition, as used herein, the terms "a" and "an" are intended to include one or more items and can be used interchangeably with "one or more". Figure 1items, the term "one" or similar language is used. In addition, as used herein, the terms "has," "have," "having," "include," "including," and the like are intended to be open-ended terms. Furthermore, unless expressly stated otherwise, the term "based on" means "based at least in part on." Furthermore, expressions such as "at least one of [A] and [B]" or "at least one of [A] or [B]" should be understood to include only A, only B, or both A and B.

[0050] Figure 2 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, environment 200 may include user device 210, platform 220, and network 230. The devices of 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 invention may be performed by any combination of the elements shown.

[0051] The user device 210 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information associated with the platform 220. For example, the 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 smart phone, a wireless phone, etc.), a wearable device (e.g., smart glasses or a smart watch), or a similar device. In some implementations, the user device 210 can receive information from the platform 220 and / or send information to the platform 220.

[0052] 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 may be swapped in or out according to specific needs. Therefore, the platform 220 may be easily and / or quickly reconfigured for different purposes.

[0053] In some implementations, as shown, the platform 220 can be hosted in a cloud computing environment 222. It is worth noting that although 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.

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

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

[0056] like Figure 2 As further shown, 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 ("VS") 224-3, one or more hypervisors ("HYP") 224-4, and the like.

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

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

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

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

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

[0062] Figure 2 The number and arrangement of devices and networks shown in are provided as examples. Figure 2There may be 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. Figure 2 Two or more of the devices shown in may be implemented in a single device, or Figure 2 A single device shown in the environment 200 may be implemented as multiple distributed devices. Additionally or alternatively, a set of devices (eg, one or more devices) of the environment 200 may perform one or more functions described as being performed by another set of devices of the environment 200.

[0063] Figure 3 300 is a diagram of example components of device 300. Device 300 may correspond to user device 210 and / or platform 220. Figure 3 As shown, 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 .

[0064] 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 a random access memory (RAM), a read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, and / or optical memory) that stores information and / or instructions for use by the processor 320.

[0065] 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 disk), an optical disk (CD), a digital versatile disk (DVD), a floppy disk, a cassette, a magnetic tape, and / or another type of non-transitory computer-readable medium, and a corresponding drive. The input component 350 includes a component that allows the device 300 to receive information such as via user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, and / or a microphone). Additionally or alternatively, the input component 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 a component that provides output information from the device 300 (e.g., a display, a speaker, and / or one or more light emitting diodes (LEDs)).

[0066] The communication interface 370 includes a transceiver-like component (e.g., a transceiver, and / or a separate receiver and transmitter) that enables 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 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi interface, a cellular network interface, etc.

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

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

[0069] Additionally or alternatively, hardwired circuitry 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 specific combination of hardware circuitry and software.

[0070] Figure 3The number and arrangement of components shown in FIG. are provided as examples. In practice, Figure 3 Compared to those shown, device 300 may include more components, fewer components, different components, or differently arranged components. Additionally or alternatively, a 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.

[0071] In an embodiment, Figures 4 to 10 Any operation or process may be performed by or using Figures 2 to 3 Any one of the components shown can be used to implement

[0072] Figure 4 The diagram illustrates the NRT-RIC framework (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, A1 interfaces within O-RAN.

[0073] refer to Figure 4 , NRT-RIC represents a subset of the functionality of the SMO framework. NRT-RIC can access other SMO framework functions and thereby influence (i.e., control and / or execute) the content carried across the O1 and O2 interfaces (e.g., perform configuration management (CM) and / or performance management (PM)).

[0074] NRT-RIC includes an NRT-RIC framework. The NRT-RIC framework includes an R1 service exposure function for processing R1 services provided according to an example embodiment, etc. Generally, the NRT-RIC function within the NRT-RIC framework supports authorization, authentication, registration, discovery, communication support, etc. for rAPP.

[0075] NRT-RIC Applications (rApps) are applications that leverage the functionality available in the NRT-RAC framework and / or 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, etc., and information enrichment.

[0076] To this end, the NRT-RIC framework generates and / or consumes R1 services via an R1 interface according to an example embodiment. The R1 interface terminates in 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) to access R1 services via the R1 interface.

[0077] In addition, the NRT-RIC framework includes A1-related functions. The A1-related functions of the NRT-RIC framework support, for example, A1 logical terminals, A1 policy coordination and cataloging, A1-EI coordination and cataloging, etc.

[0078] 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, for example, delivering functional management (FM) / consumption management (CM) / production management (PM) data to rApp, or delivering CM changes from rApp to O-RAN via the O1 interface.

[0079] The NRT-RIC framework also includes external terminations, which support data exchange between the NRT-RIC framework and external AI / ML functions, enriched information (EI) sources, or external insights, for example.

[0080] 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, monitoring AI / ML models deployed in NRT-RIC, etc.

[0081] In addition, the NRT-RIC framework includes A2-related functions that support, for example, A2 logical terminals, A2 policy coordination and cataloging.

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

[0083] The R1 interface is independent of the specific implementation of the NRT-RIC framework of SMO and NRT-RIC.The R1 interface is defined in an extensible way that enables new services and data types to be added without changing the protocol or procedures.

[0084] In particular, the R1 interface facilitates interconnection between rApps and NRT-RIC frameworks provided by different vendors (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.

[0085] In the prior art, there is no R1 application protocol specified for O1-related services in the NRT-RIC framework of NRT-RIC.

[0086] The framework of the R1 application protocol according to an embodiment specifies R1 services and related service procedures and API definitions.

[0087] 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, R2-O2 data services, R1-AIML services, etc. Hereinafter, R1-O1 services and service processes according to example embodiments are described.

[0088] At the same time, the corresponding API specifications may include specifications of R1-SME API, R1-DME API, R1-A1API, R1-O1 API, R1-O2 API, R1-AIML API, etc.

[0089] Figure 5 Illustrated is an R1 application protocol between an R1 service consumer and an R1 service producer residing in an rApp and / or in an NRT-RIC framework of an NRT-RIC according to an example embodiment.

[0090] refer to Figure 5 , the R1 AP framework specified according to the example embodiment includes R1 services and related service processes. The R1 AP framework provides a standardized R1 AP to allow an R1 service consumer rAPP related to (or consuming at least one of) 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 to connect to the NRT-RIC framework of the NRT-RIC.

[0091] In an example embodiment, communication via the R1 interface may be via an R1-SME API, an R1-DME API, an R1-A1 API, an R1-O2 API, an R1-AIML API, an R1-O1 API, or the like.

[0092] In an example embodiment, the API may be configured to provide an interface for a separate R1 service. In an example embodiment, one or more (or all) APIs may be configured as one API for an R1 interface. In any case, the R1 AP protocol provides data types and structures (i.e., data models) to implement the example embodiments.

[0093] R1 AP is based on signaling between R1 service consumers residing in rApp or in NRT-RIC framework and R1 service producers according to the parallel communication between NRT-RIC framework and rApp of NRT-RIC.

[0094] For example, the rApp may be associated with an R1 service consumer (i.e., consuming telemetry data of O-RAN), and the NRT-RIC framework may be associated with an R1 service producer (i.e., producing (providing) telemetry data of O-RAN). The interaction between the R1 service consumer and the R1 service producer via the R1 interface is based on the service framework for 3GPP network functions (NFs), for example, as described in Section 7.1.2 of 3GPP TS 23.501 [6]. The service framework 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., NRT-RIC framework).

[0095] According to the 3GPP NF framework, in an example embodiment, the R1 producer (e.g., NRT-RIC framework) handles the resources (i.e., network elements of O-RAN) on which the R1 consumer (e.g., rApp) performs operations. Therefore, the terms R1 consumer and R1 producer do not refer to the direction of data transmission on the R1 interface. For this purpose, the R1 consumer and the R1 producer can send requests and responses, respectively.

[0096] Still refer to Figure 5 ,O1-related services and service processes for R1 interface include O1 configuration management (CM) service, O1 network information (NI) service, O1 performance management (PM) service, and O1 fault management (FM) service. The O1-related services generated by the NRT-RIC framework and / or the SMO framework provide access to the operations, administration, and maintenance (OAM) functions.

[0097] In particular, for R1 AP, the O1-related services generated by the NRT-RIC framework and / or the SMO framework enable an R1 service consumer (e.g., rApp) to obtain information about alarms related to O1 telemetry parameters, change O1 telemetry parameters and their confirmation status, obtain performance information related to network elements in O-RAN, obtain the current configuration of at least one network element in O-RAN, supply 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.

[0098] 6A to 6D illustrate a service process of an R1-O1 related service and an R1 application protocol for the R1-O1 related service according to an example embodiment. Figure 1 or Figure 4 , R1-O1 related services and service processes identify at least one network element (e.g., CU, DU, etc.) within the O-RAN architecture.

[0099] Referring to FIG6A , the request and response of the R1 AP to the O1 Network Information (NI) service process 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 NI data related to O-RAN (e.g., consumer information) that has been aggregated from multiple information sources, such as Figure 4 and Figure 5 The O-RAN architecture shown (ie, the NRT-RIC framework within the SMO framework) can be used in the SMO framework. For example, the NI data may include at least one of configuration, topology, network element status, geographic location, inventory, etc.

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

[0101] To this end, the NI service process according to 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 an unsuccessful operation).

[0102] 6B, R1 AP's requests and responses to CM service procedures allow R1 service consumer rApp to access configuration information related to managed entities acquired by CM service producers. CM services also allow service consumers to request configuration changes related to managed entities (e.g., network elements of O-RAN).

[0103] Regarding configuration management (CM) services, the term CM "service consumer" refers to the role of 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 produces CM services.

[0104] In particular, the CM service producer on the R1 interface (ie, the NRT-RIC framework with the SMO framework) enables the R1 service consumer rApp to retrieve configuration schemas, read configuration data, and write configuration changes.

[0105] To this end, R1 AP's requests and responses to O1 configuration management (CM) services and service processes include: a first request "Get CM Mode Request" initiated by the R1 service consumer rApp for retrieving the configuration mode, a first response "Get CM Mode Response" for returning the CM attributes of the configuration mode (or the first response "Get CM Mode Failure" in the case of an unsuccessful operation), a second request "Get (Read) CM Data Request" for reading configuration data (for example, the attribute values ​​identified in the corresponding configuration mode), a second response "Get CM Data Request Response" for providing configuration data (or the second response "Get PM Data Request Failure" in the case of an unsuccessful operation), a third request "Write CM Request" for writing CM data, and a third response "Write CM Request Response" (or the third response "Write CM Request Failure" in the case of an unsuccessful operation).

[0106] Referring to Figure 6C, the R1 AP's request and response to the performance management (PM) service process allows the R1 service consumer rApp to access the performance information collected by the R1 service producer (e.g., NRT-RIC) from at least one network element in O-RAN. 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 produces the PM service.

[0107] To this end, the PM service process includes: a first request (i.e., an initial message) "Get PM Data Request" initiated by the R1 consumer service rApp to query at least one network element of O-RAN for performance information (for example, extracting performance information from at least one network element or subscribing to information to provide services), and a first response "Get PM Data Response" (for example, in response to a request to provide performance information from at least one network element in the event of a performance-related event, or to push performance information based on a subscription) (or a first response "Get PM Data Failure" in the event of an unsuccessful operation).

[0108] 6D , the R1 AP's request and response to the O1 Fault Management (FM) service process allows the R1 service consumer rApp to obtain information about alarms (e.g., event trigger notifications) related to the performance of network elements in the O-RAN generated by the R1 service producer (e.g., NRT-RIC).

[0109] Regarding O1-FM services, the term FM "service consumer" refers to the role of the rApp that consumes O1-FM services. The term FM "service producer" refers to the role of the logical O1-related functions in the NRT-RIC framework and / or SMO framework that produces FM services.

[0110] To this end, the R1-O1 FM service process includes: a first request "Get FM Data Request" initiated by the R1 consumer service rApp for querying alarm information, and a first response "Get FM Data Response" (or a first response "Get FM Data Failed" in the case of an unsuccessful operation). In this case, the request can be a request to extract alarm information, or it can be a subscription request to receive push notifications of alarms (e.g., real-time or near real-time).

[0111] Figure 7 The flow of the R1-O1 NI data service according to an example embodiment is illustrated, the service including a request (ie, initial message) "Get NI Data Request" and a response "Get NI Data Response" (or "Get NI Data Failure").

[0112] refer to Figure 7 , among multiple requests and responses, the rApp hosted by NRT-RIC sends a first request "Get NI Data Request" to the NRT-RIC framework via the R1 interface. The NRT-RIC framework (i.e., the O1-related function of the NRT-RIC framework) returns a first response "Get NI Data Response" (or a first response "Get NI Data Failure" in the case of an unsuccessful operation).

[0113] Figure 8 The diagram illustrates the process of the R1-O1 configuration management CM data service according to an example embodiment, which service includes a first request (i.e., initial message) "CM mode request", a first response "Get CM mode response" (or "Get CM mode failure"), a second request "Get (read) CM data request", a second response "Get CM data request response" (or "Get CM data request failure"), a third request "Write CM request", and a third response "Write CM request response" (or "Write CM request failure").

[0114] refer to Figure 8 In operation 1, the rApp hosted by NRT-RIC sends a first request "Get CM Mode Request" for retrieving the configuration mode to the NRT-RIC framework via the R1 interface. The NRT-RIC framework (i.e., the O1-related function of the NRT-RIC framework) returns a first response "Get CM Mode Response" (or a first response "Get CM Mode Failure" in the case of an unsuccessful operation).

[0115] In operation 2, the NRT-RIC framework of NRT-RIC receives a second request "Get CM Data Request" for reading configuration data from rAPP, and sends a second response "Get CM Data Request Response" (or "Get CM Data Request Failure" in case of an unsuccessful operation).

[0116] In operation 3, the NRT-RIC framework of the NRT-RIC receives a third request “Write CM Request” for writing configuration from the rAPP, and sends a third response “Write CM Request Response” (or “Write CM Request Failure” in case of an unsuccessful operation).

[0117] Fig. 9 The flow of the R1-O1 performance management PM service according to an example embodiment is illustrated, the service including a request (ie, initial message) "Get PM Data Request", and a response "Get PM Data Response" (or "Get PM Data Failure"). Fig. 9 , the 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 function of the NRT-RIC framework) returns a first response "Get PM Data Response" (or a first response "Get PM Data Failure" in the case of an unsuccessful operation).

[0118] Fig.10 The flow of the R1-O1 fault management FM service according to an example embodiment is illustrated, the service including a request (ie, initial message) "Get FM Data Request", and a response "Get FM Data Response" (or "Get FM Data Failure"). Fig.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 function of the NRT-RIC framework) returns a first response "Get FM Data Response" (or a first response "Get FM Data Failed" in the case of an unsuccessful operation).

[0119] According to an embodiment, an apparatus and method for implementing an R1-O1 application protocol including multiple R1 services and R1 service processes are provided, wherein the R1-O1 application protocol allows network operators to effectively manage (standardize) rApp applications from multiple vendors to define requirements for an NRT-RIC platform.

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

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

[0122] Computer readable storage medium can be a tangible device, which can retain and store instructions for use by instruction execution devices. Computer readable storage medium can be, for example, but not limited to, electronic storage device, magnetic storage device, optical storage device, electromagnetic storage device, semiconductor storage device, or any suitable combination of the above. A non-exhaustive list of more specific examples of computer readable storage medium includes: portable computer floppy disk, hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanical encoding device (such as a convex structure in a punch card or groove) with instructions recorded thereon, and any suitable combination of the above. Computer readable storage medium as used herein itself should not be interpreted as transient signal, such as radio wave or other free propagating electromagnetic wave, electromagnetic wave propagated by waveguide or other transmission medium (for example, light pulse passing through optical fiber cable) or electrical signal sent by wire.

[0123] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device, or 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 fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network, and forwards the computer-readable program instructions to be stored in a computer-readable storage medium in the corresponding computing / processing device.

[0124] The computer readable program code / instruction for performing the operation can be an assembly instruction, an instruction set architecture (ISA) instruction, a machine instruction, a machine-related instruction, a microcode, a firmware instruction, a state setting data, a configuration data for an integrated circuit system, or a source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​(such as Smalltalk, C++, etc.) and process programming languages ​​(such as "C" programming languages ​​or similar programming languages). The computer readable program instruction can be executed completely on the user's computer, partially on the user's computer, executed as an independent software package, partially on the user's computer and partially on a remote computer, or completely on a remote computer or server. In the latter case, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or a connection to an external computer can be executed (for example, using an Internet service provider through the Internet). In some embodiments, an electronic circuit system (including, for example, a programmable logic circuit system, a field programmable gate array (FPGA) or a programmable logic array (PLA)) can execute computer readable program instructions by using the state information of the computer readable program instruction to personalize the electronic circuit system, thereby executing various aspects or operations.

[0125] 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 flowchart and / or block diagram blocks. These computer-readable program instructions can also be stored in a computer-readable storage medium that can guide a computer, a programmable data processing device, and / or other equipment to work in a specific manner, so that the computer-readable storage medium having the instructions stored therein includes an article of manufacture, which includes instructions for implementing various aspects of the functions / actions specified in the flowchart and / or block diagram blocks.

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

[0127] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the system, method and computer-readable medium according to various embodiments. In this regard, each block in the flowchart or block diagram can represent a module, segment or part of an instruction, which includes one or more executable instructions for implementing (multiple) specified logical functions. Compared with what is shown in the accompanying drawings, the method, computer system and computer-readable medium may include more blocks, fewer blocks, different blocks or blocks arranged differently. In some alternative implementations, the functions described in the blocks may not occur in the order shown in the accompanying drawings. For example, in fact, the two blocks shown in succession can be executed simultaneously or substantially simultaneously, or these blocks can sometimes be executed in the opposite order, depending on the functions involved. It will also be noted that each block illustrated in the block diagram and / or the flowchart and the combination of the blocks in the block diagram and / or the flowchart can be implemented by a system based on special-purpose hardware, which performs a specified function or action or performs a combination of special-purpose hardware and computer instructions.

[0128] It is obvious that the system and / or method described herein can be implemented with different forms of hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code to implement these systems and / or methods does not limit these implementations. Therefore, the operation and behavior of these systems and / or methods are described in this article without reference to specific software codes. It should be understood that software and hardware can be designed to implement these systems and / or methods based on the description herein.

Claims

1. A device for a non-real-time radio access network intelligent controller (NRT-RIC) framework in an open radio access network (O-RAN), the device comprising: Memory, which stores instructions; as well as At least one processor configured to implement the NRT-RIC framework of the NRT-RIC to: receiving, via an R1 interface within the O-RAN architecture between the rApp and the NRT-RIC framework, at least one request for at least one R1-O1 related service from a rApp hosted by the NRT-RIC; and sending, from the NRT-RIC framework to the rApp via the R1 interface, at least one response of the at least one R1-O1 related service; Wherein the at least one request and the at least one response are implemented as data types of multiple R1 data models including the R1 application protocol, and the data types enable the NRT-RIC framework and the rApp to generate and / or consume data of the at least one R1-O1 related service in the NRT-RIC.

2. The device according to claim 1, wherein: The at least one R1-O1 related service comprises: an O1-NI service for providing network information (NI) data, The at least one processor is further configured to implement the NRT-RIC framework to: receiving, via the R1 interface within the O-RAN architecture, a NI data request for the O1-NI service from the rApp hosted by the NRT-RIC; and An NI data response of the O1-NI service is sent from the NRT-RIC framework to the rApp via the R1 interface within the O-RAN architecture, and the NI data includes at least one of: network configuration information, network topology information, network element status information, geolocation information, and network inventory information.

3. The device according to claim 1, wherein: The at least one R1-O1 related service comprises: an O1-Configuration Management (CM) service for accessing configurations of network elements in the O-RAN, and The at least one processor is further configured to implement the NRT-RIC framework to: receiving, via the R1 interface within the O-RAN architecture, a request for the O1-CM service from the rApp hosted by the NRT-RIC; and A response for the O1-CM service is sent from the NRT-RIC framework to the rApp via the R1 interface within the O-RAN architecture. 4 . The apparatus of claim 3 , wherein the request of the O1-CM service is a request to retrieve a configuration mode of at least one network element, and the response of the O1-CM service includes the configuration mode.

5. The device according to claim 3, wherein: The request for the O1-CM service is a request to read 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 of the network element.

6. The device according to claim 1, wherein: The at least one R1-O1 related service comprises: an O1-Performance Management (PM) service for accessing performance information collected from at least one network element, The at least one processor is further configured to implement the NRT-RIC framework to: receiving, via the R1 interface within the O-RAN architecture, a request for the O1-PM service from the rApp hosted by the NRT-RIC; and sending a response of 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 is a request for receiving the performance information.

7. The device according to claim 1, wherein: The at least one R1-O1 related service comprises: an O1-Fault Management (FM) service for obtaining information about alarms, The at least one processor is further configured to implement the NRT-RIC framework to: receiving, from the rApp hosted by the NRT-RIC, a request for the O1-FM service to obtain information about at least one alarm; and A response of the O1-FM service is sent from the NRT-RIC framework to the rApp.

8. A method for providing R1-O1 related services, implemented by a non-real-time radio access network intelligent controller (NRT-RIC) framework in an open radio access network (O-RAN), the method comprising: receiving, via an R1 interface within the O-RAN architecture between the rApp and the NRT-RIC framework, at least one request for at least one R1-O1 related service from a rApp hosted by the NRT-RIC; and sending, from the NRT-RIC framework to the rApp via the R1 interface, at least one response of the at least one R1-O1 related service, Wherein the at least one request and the at least one response are implemented as data types of multiple R1 data models including the R1 application protocol, and the data types enable the NRT-RIC framework and the rApp to generate and / or consume data of the at least one R1-O1 related service in the NRT-RIC.

9. The method according to claim 8, wherein: The at least one R1-O1 related service comprises: an O1-NI service for providing network information (NI) data, The receiving comprises: receiving, via the R1 interface within the O-RAN architecture, a NI data request for the O1-NI service from the rApp hosted by the NRT-RIC, The sending includes: sending a NI data response of the O1-NI service from the NRT-RIC framework to the rApp via the R1 interface within the O-RAN architecture, and The NI data includes at least one of: network configuration information, network topology information, network element status information, geographic location information, and network inventory information.

10. The method according to claim 8, wherein: The at least one R1-O1 related service comprises: an O1-Configuration Management (CM) service for accessing configurations of network elements in the O-RAN, The receiving comprises: receiving a request for the O1-CM service from the rApp hosted by the NRT-RIC via the R1 interface within the O-RAN architecture; and The sending includes: sending a response of the O1-CM service from the NRT-RIC framework to the rApp via the R1 interface within the O-RAN architecture.

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

12. The method according to claim 8, wherein: The request for the O1-CM service is a request to read 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 of the network element.

13. The method according to claim 8, wherein: 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 comprises: receiving a request for the O1-PM service from the rApp hosted by the NRT-RIC via the R1 interface within the O-RAN architecture; The sending includes: sending a response of 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 is a request for receiving the performance information.

14. The method of claim 8, wherein: The at least one R1-O1 related service includes: an O1-Fault Management (FM) service for obtaining information about alarms; The receiving includes: receiving a request for the O1-FM service from the rApp hosted by the NRT-RIC to obtain information about at least one alarm; and The sending includes: sending a response of the O1-FM service from the NRT-RIC framework to the rApp.

15. A non-transitory computer-readable recording medium having recorded thereon instructions executable by at least one processor, the at least one processor implementing a non-real-time radio access network intelligent controller (NRT-RIC) framework in an open radio access network (O-RAN) to perform a method for providing R1-O1 related services, the method comprising: receiving, via an R1 interface within the O-RAN architecture between the rApp and the NRT-RIC framework, at least one request for at least one R1-O1 related service from a rApp hosted by the NRT-RIC; and sending, from the NRT-RIC framework to the rApp via the R1 interface, at least one response of the at least one R1-O1 related service; Wherein the at least one request and the at least one response are implemented as data types of multiple R1 data models including the R1 application protocol, and the data types enable the NRT-RIC framework and the rApp to generate and / or consume data of the at least one R1-O1 related service in the NRT-RIC.

16. The non-transitory computer readable recording medium according to claim 15, wherein: The at least one R1-O1 related service comprises: an O1-NI service for providing network information (NI) data, The receiving comprises: receiving, via the R1 interface within the O-RAN architecture, a NI data request for the O1-NI service from the rApp hosted by the NRT-RIC, The sending includes: sending a NI data response of the O1-NI service from the NRT-RIC framework to the rApp via the R1 interface within the O-RAN architecture, and The NI data includes at least one of: network configuration information, network topology information, network element status information, geographic location information, and network inventory information.

17. The non-transitory computer readable recording medium according to claim 15, wherein: The at least one R1-O1 related service comprises: an O1-Configuration Management (CM) service for accessing configurations of network elements in the O-RAN, The receiving comprises: receiving a request for the O1-CM service from the rApp hosted by the NRT-RIC via the R1 interface within the O-RAN architecture; and The sending includes: sending a response of the O1-CM service from the NRT-RIC framework to the rApp via the R1 interface within the O-RAN architecture.

18. The non-transitory computer readable recording medium according to claim 15, wherein: the request of the O1-CM service is a request to retrieve a configuration mode of at least one network element, and the response of the O1-CM service includes the configuration mode; The request for the O1-CM service is a request to read 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 of the network element.

19. The non-transitory computer readable recording medium according to claim 15, wherein: 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 comprises: receiving a request for the O1-PM service from the rApp hosted by the NRT-RIC via the R1 interface within the O-RAN architecture; The sending includes: sending a response of 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 is a request for receiving the performance information.

20. The non-transitory computer readable recording medium of claim 15, wherein: The at least one R1-O1 related service includes: an O1-Fault Management (FM) service for obtaining information about alarms; The receiving includes: receiving a request for the O1-FM service from the rApp hosted by the NRT-RIC to obtain information about at least one alarm; and The sending includes: sending a response of the O1-FM service from the NRT-RIC framework to the rApp.

Images