Apparatus and method for implementing R1-O1 data model of O1-related services within telecommunication network

Abstract

An apparatus for a non-real-time Radio Access Network Intelligent Controller (NRT-RIC) framework in an O-RAN. The apparatus includes a memory storing instructions; and at least one processor configured to implement an NRT-RIC framework of the NRT-RIC by executing the instructions to: receive a first request from the rApp to retrieve a configuration mode of a network element in the O-RAN, the first request comprising a first R1-O1 data model identifying the network element, and the first request being received via the R1 interface; and issuing a first response to the requested configuration mode from the NRT-RIC framework, the first response comprising a second R1-O1 data model identifying the network element and identifying configuration management (CM) attributes of the network element, where the R1 interface enables the NRT-RIC framework and the rApp to produce and consume at least one O1 interface related R1 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,392 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 an R1-O1 data model for configuration management (CM) of at least one network element in an open radio access network (O-RAN) implemented in a non-real-time radio access network intelligent controller (NRT-RIC) framework of the NRT-RIC within a service management and orchestration (SMO) framework of a telecommunications network. Background Art

[0004] The Radio Access Network (RAN) is an important component in a telecommunication system as it connects the end-user equipment (or user equipment) 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 the fronthaul (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.

[0007] RIC is a software-defined component that is used to implement 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).

[0008] 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 through 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 SMO to RAN management elements (e.g., nRT-RIC, O-RAN centralized unit (O-CU), O-RAN distributed unit (O-DU), etc.).

[0009] 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, overrides and controls the E2 nodes (O-CU, O-DU and O-eNB) via policies. For example, the nRT sets policy parameters for the activation functions of the E2 node. 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 returns policy feedback (i.e., how the policies set by NRT RIC are working).

[0010] 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).

[0011] On the other hand, O-Cloud is a cloud computing platform that includes a set 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.

[0012] The SMO framework where NRT-RIC resides manages and orchestrates RAN elements. SMO performs these services (i.e., management and orchestration of RAN elements through the following 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; in the case of a hybrid model, an open fronthaul (FrontHaul) M-plane interface between SMO and O-RU for FCAP support; O2 interface between SMO and O-Cloud for platform resource and workload management). Summary of the invention

[0013] According to an embodiment, an apparatus and method for implementing a non-real-time radio access network intelligent controller (NRT-RIC) are provided, the NRT-RIC issuing multiple requests and responses to the multiple requests, the requests and responses including multiple R1-O1 CM data models for at least one network element in an open radio access network (O-RAN). In particular, the apparatus and method are implemented in a non-real-time radio access network intelligent controller (NRT-RIC) framework of the NRT-RIC within a service management and orchestration (SMO) framework of a telecommunications network. The apparatus and method enable the NRT-RIC platform to communicate with at least one network element within the O-RAN via an R1 interface based on a specified R1-O1 CM data model. Specifically, the specified R1-O1 CM data models include a first R1-O1 CM data model and a second R1-O1 CM data model for retrieving a CM data schema of at least one network element, a third R1-O1 CM data model and a fourth R1-O1 CM data model for reading CM data from at least one network element, and a fifth R1-O1 data model and a sixth R1-O1 data model for writing CM data to at least one network element. Multiple R1-O1 CM data models allow network operators to effectively manage (standardize) rApp applications from multiple vendors to define the requirements of the NRT-RIC platform.

[0014] According to one embodiment, an apparatus 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 configured to implement the NRT-RIC framework of the NRT-RIC by executing the instructions to perform the following operations: receiving a first request to retrieve a configuration mode of at least one network element in the O-RAN from an rApp hosted by the NRT-RIC, the first request including a first R1-O1 configuration management (CM) data model identifying the at least one network element, and the first request is received via an R1 interface within the O-RAN architecture between the rApp and the NRT-RIC framework; and issuing a first response to the requested configuration mode from the NRT-RIC framework to the rApp via the R1 interface, the first response including a second R1-O1 CM data model identifying the at least one network element and identifying at least one CM attribute of the at least one network element, wherein the R1 interface enables the NRT-RIC framework and the rApp to produce and consume at least one O1 interface-related R1 service in the NRT-RIC.

[0015] The first R1-01 CM data model may include: a message type parameter identifying a type of the first request; and at least one network element parameter including a network element identifier (ID).

[0016] The second R1-O1 CM data model may include: a message type parameter identifying a type of the first response; and, for each of the at least one network element, a supported information object class (IOC) entity parameter including one or more related entity items identifying one or more CM attributes.

[0017] The at least one processor may also be configured to execute the instructions to receive, from the rApp, a second request to read configuration data of a CM attribute among at least one CM attribute identified in the first response, the second request including a third R1-O1 CM data model identifying the network element and the CM attribute, and the second request being received via the R1 interface; and in response to the second request, issuing a second response from the NRT-RIC framework to the rApp via the R1 interface, the second response including a fourth R1-O1 CM data model identifying the CM attribute.

[0018] The third R1-O1 CM data model may include: a message type parameter identifying the type of the second request; an rApp identifier (ID) identifying the rApp; a request identifier (ID) of the second request; a network element parameter, including the network element ID of the network element; and a first name-contained IOC entity parameter (first name-contained IOC entity parameter), wherein the first name-contained IOC entity parameter includes an IOC entity name and a first related entity item identifying a CM attribute.

[0019] The fourth R1-O1 CM data model may include: a message type parameter identifying the type of the second response; an rApp ID identifying the rApp; a network element parameter including a network element identifier (ID); a second named IOC entity parameter, the second named IOC entity parameter including an IOC entity name and a second related entity item identifying a CM attribute.

[0020] The second related entity item may further include a CM attribute value identifying a value of the CM attribute.

[0021] The at least one processor may also be configured to execute the instructions to: receive a third request for configuration data of a CM attribute written to at least one CM attribute from the rApp, the third request including a fifth R1-O1 CM data model identifying the network element and the CM attribute, and the third request being received via the R1 interface; and issue a third response from the NRT-RIC framework to the rApp via the R1 interface, the third response including a sixth R1-O1 CM data model for identifying the CM attribute modified in response to the third request.

[0022] The fifth R1-O1 CM data model may include: a message type parameter identifying the type of the third request; an rApp ID identifying the rApp; a network element parameter including a network element identifier (ID) of the network element; a third named IOC entity parameter including an IOC entity name and a third related entity item, the third related entity item identifying a CM attribute to be modified in response to the third request.

[0023] The sixth R1-O1 CM data model may include: a message type parameter identifying the type of the third response; rAppID; a network element parameter, including a network element identifier (ID); an attribute status confirming the configuration status; a fourth named IOC entity parameter, the fourth named IOC entity parameter including an IOC entity name and a fourth related entity item, the fourth related entity item identifying the CM attribute and the written status.

[0024] Based on the fact that the write is not accepted, the fourth related entity item may further include a cause parameter, which identifies the reason why the write is not accepted.

[0025] According to one embodiment, a method for a non-real-time radio access network intelligent controller (NRT-RIC) framework in an open radio access network (O-RAN) is provided, the method comprising: receiving a first request to retrieve a configuration mode of at least one network element in the O-RAN from an rApp hosted by the NRT-RIC, the first request comprising a first R1-O1 CM data model identifying the at least one network element, and the first request being received via an R1 interface within the O-RAN architecture between the rApp and the NRT-RIC framework; and issuing a first response to the requested configuration mode from the NRT-RIC framework to the rApp via the R1 interface, the first response comprising a second R1-O1 CM data model identifying the at least one network element and identifying at least one configuration management (CM) attribute of the at least one network element, wherein the R1 interface enables the NRT-RIC framework and the rApp to produce and consume at least one O1 interface-related R1 service in the NRT-RIC.

[0026] The first R1-01 CM data model may include: a message type parameter identifying a type of the first request; and at least one network element parameter including a network element identifier (ID).

[0027] The first R1-01 CM data model may include: a message type parameter identifying a type of the first request; and at least one network element parameter including a network element identifier (ID).

[0028] The second R1-O1 CM data model may include: a message type parameter identifying a type of the first response; and, for each of the at least one network element, a supported information object class (IOC) entity parameter including one or more related entity items identifying one or more CM attributes.

[0029] The method may also include: receiving, from the rApp, a second request to read configuration data of a CM attribute among at least one CM attribute identified in the first response, the second request including a third R1-O1 CM data model identifying the network element and the CM attribute, and the second request being received via the R1 interface; and in response to the second request, issuing a second response from the NRT-RIC framework to the rApp via the R1 interface, the second response including a fourth R1-O1 CM data model identifying the CM attribute.

[0030] The method may also include: receiving a third request for configuration data of CM attributes written to at least one CM attribute from the rApp, the third request including a fifth R1-O1 CM data model identifying the network element and the CM attribute, and the third request being received via the R1 interface; and issuing a third response from the NRT-RIC framework to the rApp via the R1 interface, the third response including a sixth R1-O1 CM data model for identifying the CM attribute to be modified in response to the third request.

[0031] According to one embodiment, a non-transitory computer-readable recording medium is provided, on which instructions executable by at least one processor are recorded, the at least one processor being configured to execute a method for a non-real-time radio access network intelligent controller (NRT-RIC) framework in an open radio access network (O-RAN), the method comprising: receiving a first request for retrieving a configuration mode of at least one network element in the O-RAN from an rApp hosted by the NRT-RIC, the first request comprising a first R1-O1 CM data model identifying the at least one network element, and the first request being received via an R1 interface within the O-RAN architecture between the rApp and the NRT-RIC framework; and issuing a first response to the requested configuration mode from the NRT-RIC framework to the rApp via the R1 interface, the first response comprising a second R1-O1 CM data model identifying the at least one network element and identifying at least one configuration management (CM) attribute of the at least one network element, wherein the R1 interface enables the NRT-RIC framework and the rApp to produce and consume at least one O1 interface-related R1 service in the NRT-RIC.

[0032] The method may also include: receiving, from the rApp, a second request to read configuration data of a CM attribute among at least one CM attribute identified in the first response, the second request including a third R1-O1 CM data model identifying the network element and the CM attribute, and the second request being received via the R1 interface; and in response to the second request, issuing a second response from the NRT-RIC framework to the rApp via the R1 interface, the second response including a fourth R1-O1 CM data model identifying the CM attribute.

[0033] The method may also include: receiving a third request for configuration data of CM attributes written to at least one CM attribute from the rApp, the third request including a fifth R1-O1 CM data model identifying the network element and the CM attribute, and the third request being received via the R1 interface; and issuing a third response from the NRT-RIC framework to the rApp via the R1 interface, the third response including a sixth R1-O1 CM data model for identifying the CM attribute to be modified in response to the third request.

[0034] 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

[0035] 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:

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

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

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

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

[0040] Figure 5 illustrates the flow of requests and responses from an rApp to an NRT-RIC framework of an NRT-RIC via an R1 interface, the requests and responses involving multiple R1-O1 CM data models of at least one network element according to one embodiment;

[0041] 6A-6D depict a first R1-O1 CM data model for a first request (i.e., initial message), i.e., a GET CM SCHEMAS REQUEST, and a second R1-O1 CM data model for a first response (i.e., a GET CM SCHEMAS RESPONSE or a GET CM SCHEMAS FAILURE) according to an example embodiment;

[0042] 7A to 7C depict a third R1-O1 CM data model for a second request (ie, a GET (READ) CM DATA REQUEST) according to an example embodiment;

[0043] 8A-8C depict a fourth R1-O1 CM data model for a second response (ie, "GET CM DATA REQUEST RESPONSE" or "GET CM DATA REQUEST FAILURE") according to an example embodiment;

[0044] 9A to 9C depict a fifth R1-O1 CM data model for a third request (ie, WRITE CMREQUEST) according to an example embodiment;

[0045] 10A to 10C depict a sixth R1-O1CM data model for a third response (ie, WRITE CM REQUEST RESPONSE or WRITE CM REQUEST FAILURE) according to an example embodiment; and

[0046] Fig.11 An example embodiment of a third R1-01 CM data model for a second request, ie, a GET (READ) CM DATA REQUEST, is illustrated. DETAILED DESCRIPTION

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

[0048] 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, it is possible to modify and deform, or it is possible to obtain modification and deformation from the practice of implementation. In addition, one or more features or parts of an embodiment may 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 is understood that one or more operations may be omitted, one or more operations may be added, one or more operations may be performed simultaneously (at least in part), and the order of one or more operations may be switched.

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

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

[0051] Unless explicitly stated, any element, behavior or instruction used in this article should not be interpreted as critical or necessary. In addition, as used in this article, the terms "a" and "an" are intended to include one or more items, and can be used interchangeably with "one or more". If only one item is intended to be represented, the term "one" or similar language is used. In addition, as used in this article, the terms "has", "have", "having", "include", "including", etc. are intended to be open terms. In addition, unless explicitly stated otherwise, the word "based on" means "based at least in part". In addition, statements such as "at least one of [A] and [B]" or "at least one of [A] or [B]" should be understood to include only A, only B, or both A and B.

[0052] Figure 2 2 is a diagram of an example environment 200 in which the systems and / or methods described herein may be implemented. Figure 2 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 11 Any functions and operations described can be performed by Figure 2 The invention may be performed by any combination of the elements shown.

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

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

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

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

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

[0058] like Figure 2 As further shown, the computing resources 224 include a set of cloud resources, such as one or more applications ("APPs") 224-1, one or more virtual machines ("VMs") 224-2, virtualized storage ("VSs") 224-3, one or more hypervisors ("HYPs") 224-4, or the like.

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

[0060] Virtual machine 224-2 includes a software implementation of a machine (e.g., a computer) (such as a physical machine) that executes a program. 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.

[0061] 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 optimize the performance of storage usage, server consolidation, and / or non-disruptive file migration.

[0062] Hypervisor 224-4 can provide hardware virtualization technology that allows multiple operating systems (e.g., "guest operating systems") to execute simultaneously on a host (e.g., 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.

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

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

[0065] 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 330 , a storage component 340 , an input component 350 , an output component 360 , and a communication interface 370 .

[0066] 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 330 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.

[0067] The storage component 340 stores information and / or software related to the operation and use of the device 300. For example, the storage component 340 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 components that allow 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 components that provide output information from the device 300 (e.g., a display, a speaker, and / or one or more light-emitting diodes (LEDs)).

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

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

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

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

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

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

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

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

[0076] NRT-RIC includes an NRT-RIC framework. The NRT-RIC / framework includes R1 service exposure functions for processing R1 services provided according to example embodiments, etc. In general, the NRT-RIC functions within the NRT-RIC framework support authorization, authentication, registration, discovery, communication support, etc. of rAPP.

[0077] NRT-RIC Applications (rApps) are applications that leverage the functionality available in the NRT-RIC 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.

[0078] To this end, the NRT-RIC framework produces and / or consumes R1 services via an R1 interface according to an example embodiment. The R1 interface terminates at an R1 termination of the NRT-RIC framework. The R1 termination 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.

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

[0080] The data management and exposure services within the NRT-RIC framework deliver data created or collected by data producers to data consumers based on the needs of data consumers (e.g., delivering functional management (FM) / consumption management (CM) / production management (PM) data to rApp via the O1 interface, or changing CM from rApp to O-RAN).

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

[0082] Within the NRT-RIC framework, the AI / ML workflow service provides access to AI / ML workflows. For example, the AI / ML workflow service can help train models, monitor AI / ML models deployed in NRT-RIC, and more.

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

[0084] Still refer to Figure 4 , within NRT-RIC, the R1 interface is an open logical interface between rApps within the O-RAN architecture 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.

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

[0086] In particular, the R1 interface facilitates interconnection between rApp and NRT-RIC frameworks provided by different vendors (ie, facilitates interconnection in a multi-vendor environment). To this end, the R1 interface provides a certain degree of abstraction between rApp and the NRT-RIC framework and / or the SMO framework.

[0087] In the prior art, there is no R1-O1 CM data model and data type definition for O1-related services in the NRT-RIC framework of NRT-RIC specified.

[0088] The framework of the R1 interface telemetry data TD according to the embodiment specifies the data model and type. The data model may include an R1 service management and exposure (SME) data model, an R1 data management and exposure (DME) data model, an R1-A1 data model, an R1-O2 data model, an R2-AIML data model, and an R1-O1 data model. The R1-O1 data model may include an O1-CM data model, an O1-NI data model, an O1-PM data model, and an O1-FM data model. In the following, the CM data model according to the example embodiment is described.

[0089] Meanwhile, the data type may include R1-SME data type, R1-DME data type, R1-A1 data type, R1-O2 data type, R1-AIML data type and R1-O1 data type. R1-O1 data type may include O1-CM data type, O1-NI data type, O1-PM data type and O1-FM data type.

[0090] Figure 5 Illustrated is the flow of requests and responses from an rApp to an NRT-RIC framework of an NRT-RIC via an R1 interface, the requests and responses involving multiple R1-O1 CM data models of at least one network element according to one embodiment.

[0091] refer to Figure 5 , the R1 interface telemetry data TD of O1-related R1 services includes multiple R1-O1 CM data models for multiple requests and responses.

[0092] In operation 1, among multiple requests and responses, the rApp hosted by NRT-RIC issues a first request to retrieve the configuration schema "GET CM SCHEMAS 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) obtains the first request and includes a first R1-O1 CM data model, which is based on Figure 1 or Figure 4 At least one network element (eg, CU, DU, etc.) within the O-RAN architecture is identified.

[0093] The first request, i.e., "Get CM Mode Request", is an initial message for requesting the CM mode of O1-related services from at least one network element in O-RAN. The CM mode may depend on the provider of the O1-related services or the provider of at least one network element. To this end, based on the first request (i.e., the initial "Get CM Mode Request"), the rApp requests the NRT-RIC framework (i.e., the O1-related function of the NRT-RIC framework) to identify the CM mode of at least one network element in O-RAN by identifying at least one CM attribute of the at least one network element.

[0094] Based on at least one CM attribute of the at least one network element, the rApp identifies a CM mode of the at least one network element.To this end, the rApp retrieves a first response to the requested CM mode, ie, a Get CM Mode Response, from the NRT-RIC framework via the R1 interface.

[0095] The first response includes a second R1-O1 data model that identifies at least one network element and identifies at least one configuration management (CM) attribute of the at least one network element. Specifically, the rApp identifies the at least one configuration management (CM) attribute based on supported information object class (IOC) entity parameters, the IOC entity parameters including one or more related entity items that identify one or more CM attributes (i.e., identify a CM mode of a vendor-dependent O1-related service).

[0096] As a result, the rApp may select the structure (ie, syntax) of multiple R1-O1 CM data models after identifying the CM schema of the vendor-dependent O1-related services.

[0097] The identification of one or more CM attributes enables the rApp to select a data structure (ie, syntax) of a plurality of R1-O1 CM data models that fits the data structure (ie, syntax) of at least one network element.

[0098] As a result, identification of one or more CM attributes allows the NRT-RIC framework and rApps to produce and / or consume at least one O1-related R1 service in the NRT-RIC.

[0099] Still referring to operation 1, in an example embodiment, if the "get CM mode request" fails, the first response may be "get CM mode failed".

[0100] In operation 2, after identifying the mode of at least one network element, the NRT-RIC framework of the NRT-RIC receives a second request from the rApp to read configuration data of a CM attribute in at least one CM attribute, the second request includes a third R1-O1 data model identifying the network element and the CM attribute, and the second request is received via the R1 interface.

[0101] The third R1-O1 CM data model includes a message type parameter identifying the type of the second request. For example, the second request is a "get CM data request" for reading configuration data of CM attributes. In response to the second request, the NRT-RIC framework of the NRT-RIC issues a second response "get CM data request response", which includes a fourth R1-O1 CM data model. The fourth R1-O1 data model identifies the name and / or value of the CM attribute.

[0102] In an example embodiment, the third R1-O1 CM data model of the second request includes at least one test condition for testing (ie, comparing) a CM attribute according to the test condition to retrieve a compared value (eg, checking for correct release version, correct maintenance parameters, etc.).

[0103] To this end, the third R1-O1 CM data model of the second request includes an attribute name identifying the CM attribute. In addition, based on the attribute name, the third R1-O1 CM data model of the second request may include at least one test condition for the CM attribute (e.g., the third R1-O1 CM data model of the second request includes at least one test condition for testing the CM attribute (e.g., checking whether the CM attribute is correctly updated, whether the CM attribute exists, etc.). To this end, in an example embodiment, the third R1-O1 data model may include a comparison parameter and a logic OR parameter, wherein the logic OR parameter may be enumerated as true or false.

[0104] Referring to operation 2, in an exemplary embodiment, if the "get CM mode request" fails, the second response may be "get PM data request failed".

[0105] In operation 3, the NRT-RIC framework of the NRT-RIC receives a third request, i.e., a "Write CM Request", from the rApp for configuration data of a CM attribute written in at least one CM attribute, the third request, i.e., the "Write CM Request", including a fifth R1-O1 CM data model identifying a network element and a CM attribute, and the third request, i.e., the "Write CM Request", is received via the R1 interface. In the third request, i.e., the "Write CM Request", a CM attribute name and / or a CM attribute value of at least one network element within the O-RAN may be pushed to the NRT-RIC framework of the NRT-RIC.

[0106] After obtaining the third request for configuration data for writing CM attributes, the NRT-RIC framework of the NRT-RIC issues a third response, namely, a "write CM request response", to the rApp via the R1 interface, the response including a sixth R1-O1 CM data model for identifying the CM attributes modified in response to the third request (e.g., the third response may include confirmation of the CM attribute name or CM attribute value used to confirm the write request). The CM attribute name may be a generic name of the CM attribute. For example, the CM attribute name may be a generic name such as "energy saving control", etc.

[0107] Referring to operation 3, in an exemplary embodiment, if the "write CM request" fails, the third response may be "write CM failure".

[0108] 6A to 6D depict a first R1-O1 CM data model for a first request (ie, initial message) (ie, “Get Mode Request”) and a second R1-O1 CM data model for a first response (ie, “Get CM Mode Response” or “Get CM Mode Failure”) according to an example embodiment.

[0109] Referring to FIG. 6A , the first request (i.e., initial message) (i.e., “get mode request”) includes a first R1-O1 CM data model for each network element. The first R1-O1 CM data model includes at least one of the following parameters: a message type, a list of network elements (i.e., at least one network element) including a network element item IE, and an element ID of each network element in the one or more network elements, wherein the message type and the network element ID may be mandatory. In an example embodiment, the network element list nests a certain number of <maximum number of network elements> of network element items, each of which has a network element ID.

[0110] Referring to FIG6B , the first response (i.e., "Get CM Mode Response") includes a second R1-O1 CM data model for each network element. The second R1-O1 CM data model includes at least one of the following parameters: message type, a list of network elements (i.e., at least one network element) including a Network Element Item IE, and an element ID parameter for each of the one or more network elements, an IOC type for the network element, a list of related entities, a Related Entity Item IE in which one or more related entities are nested, wherein the message type and the network element ID and the one or more related entities may be mandatory. The IOC Type of the network element parameter (IOC Type) may be optional.

[0111] In an example embodiment, the network element list may include a certain number of <maximum number of network elements> of network element item IEs. In another example embodiment, the related entity item IE may include a certain number of <maximum number of entities> of one or more related entities.

[0112] 6C , the second R1-O1 CM data model of each related entity further includes at least one of the following parameters: a choice entity type, an attribute, an attribute name, an attribute definition, an IOC parameter including supported IOC entities, wherein the choice entity type (CHOICE Entity Type) and the attribute name (Attribute Name) and the supported IOC entities (supported IOC Entity) may be mandatory. The attribute definition (AttributeDefinition) may be optional.

[0113] 6D, the second R1-O1 CM data model for each supported IOC entity further includes at least one of the following parameters: an IOC name, a list of associated entities (i.e., one or more associated entities) including an associated entity item IE, and an associated entity parameter of each of the one or more associated entities, wherein the IOC name (IOC Name) and the associated entity parameter (Associated Entity parameter) may be mandatory. In an example embodiment, the list of associated entities may include a certain number of <maximum number of network elements> of associated entity item IEs.

[0114] 7A to 7C describe a third R1-O1 CM data model of the second request (ie, “Get (Read) CM Data Request”) according to example embodiments.

[0115] Referring to FIG. 7A , the second request (i.e., “Get (Read) CM Data Request”) is used to request to read configuration data of one or more network elements (NEs). The second request includes a third R1-O1 CM data model. The third R1-O1 CM data model includes at least one of the following parameters: message type, rApp ID, request ID, network element ID, managed object instance ID, a list of related entities including related entity item IE (i.e., one or more related entities), and related entity parameters of each related entity item IE in the one or more related entity item IEs, wherein the message type, rApp ID, request ID (Request ID), network element ID and one or more associated entities (Associated Entities) may be mandatory. The managed object instance ID (Managed Object Instance ID) may be optional.

[0116] In an example embodiment, the list of related entities may include a certain number of <maximum number of entities> of related entity items IEs.

[0117] Referring to FIG. 7B , the third R1-O1 CM data model of each of the one or more related entities includes at least one of the following parameters: selecting an entity type, an attribute, an attribute name, selecting an attribute type (i.e., an attribute type based on the selected attribute), a query attribute based on the selected attribute type, a list of test conditions including a test condition item IE (i.e., one or more test conditions), and a test condition parameter of each of the one or more test conditions, a comparison parameter of the one or more test conditions, a comparison value, a comparison logical OR combination logic, an IOC parameter, and an IOC entity with a name, wherein the selecting entity type, the attribute, the test condition, the comparison parameter, and the comparison value may be mandatory. The selecting attribute type and the logical OR combination logic may be optional.

[0118] For example, the test condition may be a test for checking the version or configuration status according to the CM attributes of each related entity.

[0119] In an example embodiment, the list of test conditions may include a certain number of <maximum number of test conditions> of test condition items IE. In another example embodiment, the logical OR combination logic of the compared values ​​may be enumerated as true, false, and the like.

[0120] 7C, the third R1-O1 CM data model for requesting to read configuration data of one or more named IOC entities includes at least one of the following parameters: IOC name, managed object instance ID, a list of related entities including a related entity item IE (i.e., one or more related entities), and related entity parameters of each of the one or more related entities, wherein the IOC name parameter and the one or more related entities may be mandatory. The managed object instance ID parameter may be optional.

[0121] In an example embodiment, the list of related entities may include a certain number of <maximum number of network elements> of one or more related entity item IEs.

[0122] 8A to 8C depict a fourth R1-O1 CM data model of a second response (ie, "Get CM Data Request Response" or "Get PM Data Request Failure") according to example embodiments.

[0123] 8A , the fourth R1-O1 CM data model of the second response of one or more NEs (i.e., "Get (Read) CM Data Request Response") includes at least one of the following parameters: message type, rApp ID, subscription ID, network element ID, managed object instance ID, a list of related entities including one or more related entity item IEs (i.e., one or more related entities), and related entity parameters of each of the one or more related entities, wherein the message type, rApp ID, subscription ID, network element ID, and one or more related entities may be mandatory. Managed object instance ID data may be optional. According to one or more example embodiments, for each of the plurality of network elements, at least the network element ID, the managed object instance ID, and a list of related entities may be included.

[0124] In an example embodiment, the list of related entity data may include a certain number <maximum number of entities> of one or more related entity item IEs.

[0125] 8B , the fourth R1-O1 CM data model of one or more related entities includes at least one of the following parameters: Select Entity Type, Attribute, Attribute Name, Attribute Value, IOC Parameter, and Name-contained IOC Entity, wherein Select Entity Type, Attribute Name, and Name-contained IOC Entity may be mandatory. Attribute Value may be optional.

[0126] 8C, the fourth R1-O1 CM data model of one or more named IOC entities includes at least one of the following parameters: an IOC name, a managed object instance ID, a list of related entities (i.e., one or more related entities) including a related entity item IE parameter, and related entity parameters of each of the one or more related entities, wherein the IOC name and the one or more related entities may be mandatory. The managed object instance ID may be optional.

[0127] In an example embodiment, the list of related entities may include a number of <maximum number of network elements> of related entity items IEs.

[0128] 9A to 9C describe a fifth R1-O1CM data model of a third request (ie, a “write CM request”) according to example embodiments.

[0129] 9A , the fifth R1-O1 CM data model of one or more NEs includes at least one of the following parameters: message type, rApp ID, subscription ID, network element ID, managed object instance ID, a list of related entities including one or more related entity items IE (i.e., one or more related entities), and related entity parameters of each of the one or more related entities, wherein the message type, rApp ID, subscription ID, network element ID, and one or more related entities may be mandatory. Managed object instance ID data may be optional. According to one or more example embodiments, for each of the plurality of network elements, at least the network element ID, the managed object instance ID, and a list of related entities may be included.

[0130] In an example embodiment, the list of related entities may include a certain number <maximum number of entities> of one or more related entity item IEs.

[0131] 9B , the fifth R1-O1 CM data model of one or more related entities includes at least one of the following parameters: select entity type, attribute, attribute name, attribute, value, and named IOC entity, wherein the select entity type, attribute name, and named IOC entity may be mandatory, and the attribute value may be optional.

[0132] Referring to FIG9C , the fifth R1-O1 CM data model with the name IOC entity includes at least one of the following parameters: the IOC name, the managed object instance ID, a list of related entities (i.e., one or more related entities) including a related entity item IE, and related entity parameters for each of the one or more related entities, wherein the IOC name parameter and the one or more related entities may be mandatory. The managed object instance ID may be optional. In an example embodiment, the list of related entities may include a certain number of <maximum number of network elements> of related entity item IEs.

[0133] 10A to 10C describe a sixth R1-01 CM data model of the third response (ie, "Write CM Request Response" or "Write CM Request Failure") according to example embodiments.

[0134] 10A , for one or more NEs, the sixth R1-O1 CM data model for the third write configuration change "write CM request response" or "write CM request failure" includes at least one of the following parameters: message type, rApp ID, subscription ID, network element ID, managed object instance ID, a list of related entities including one or more related entity item IEs (i.e., one or more related entities), and related entity parameters of each of the one or more related entities, wherein the message type, rApp ID, subscription ID, network element ID, and one or more related entities may be mandatory. The managed object instance ID may be optional. According to one or more example embodiments, for each of the plurality of network elements, at least the network element ID, the managed object instance ID, and the list of related entities may be included.

[0135] In an example embodiment, the list of related entities may include a certain number of <maximum number of entities> of related entity items IEs.

[0136] 10B , the sixth R1-O1 data model of one or more related entities includes at least one of the following parameters: select entity type, attribute, attribute name, state (i.e., the state parameter may be a confirmation of the state or state change), cause (i.e., a description of the cause of the state), named IOC entity parameter, wherein the select entity type, attribute name, and named IOC entity may be mandatory. The cause may be optional.

[0137] 10C , the sixth R1-O1 CM data model of one or more named IOC entities includes at least one of the following parameters: an IOC name, a managed object instance ID, a list of related entities including a related entity item IE (i.e., one or more related entities), and related entity parameters of each of the one or more related entities, wherein the IOC name and the one or more related entities may be mandatory. The managed object instance ID data may be optional.

[0138] In an example embodiment, the list of related entities may include a certain number of Related Entity Item IEs ≤ the maximum number of network elements >.

[0139] Fig.11 An example of a third R1-01 CM data model for the second request (ie, “Get (Read) CM Data Request”) is illustrated.

[0140] refer to Fig.11, an example of a third request (i.e., “Get CM Data Request”) is shown in FIG7 . The “Get CM Data Request” includes a third R1-O1 CM data model of one or more network elements, a third R1-O1 CM data model of one or more related entities, and a third R1-O1 CM data model of one or more named IOC entities, respectively.

[0141] In particular, the third request (ie, "Get CM Data Request") according to an example embodiment shows a message type: Get CM Data Request, with rApp ID: 1 and Subscription ID: x1232323.

[0142] refer to Fig.11 , the network element list includes one network element. The network element item IE parameter of the network element is set to "0IEs" (i.e., 0 IEs). The single network element has a network element ID: 10001001 (gNB ID).

[0143] Furthermore, according to this example, the list of related entities includes two related entities. According to an example embodiment, each of the first related entity, the second related entity, and the third related entity nests a named IOC entity. Fig.11 The fourth related entity at the bottom has no nested named IOC entity in this example.

[0144] The first related entity is set to "0IEs" (i.e., 0 IEs). The first named IOC entity has an IOC name: gNBCUCPFunction. The list of related entities nested in the IOC named gNBCUCPFunction includes one related entity. The related entity is set to "0IEs". In addition, according to an example embodiment, the related entity includes a CM attribute, the CM attribute having an attribute name: PLMN ID (Plane Management Identifier).

[0145] The second related entity is set to "1IEs" (i.e., 1 IE). The second named IOC entity has an IOC name: NRCellCU. The list of related entities nested in the IOC named NRCellCU includes one related entity. The related entity is set to "0IEs". In addition, according to an example embodiment, the related entity includes a CM attribute, which has an attribute name: cellLocalID (Cell Location Identifier).

[0146] The third related entity is set to "1 IEs" (i.e., 1 IE). The third named IOC entity has an IOC name: CESManagementFunc. The list of related entities nested in the IOC named CESManagementFunc includes one related entity. The related entity is set to "0 IEs". In addition, according to an example embodiment, the related entity includes a CM attribute, the CM attribute having an attribute name: energySavingState.

[0147] The fourth related entity is set to "1IEs" (ie, 1 IE). The fourth related entity does not include an IOC entity with a name. According to an example embodiment, the related entity includes a CM attribute with an attribute name: energySavingState.

[0148] The above disclosure provides illustration and description, but is not intended to be exhaustive or to limit 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.

[0149] 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 a computer-readable non-transitory storage medium having computer-readable program instructions thereon for causing a processor to perform operations.

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

[0151] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to a corresponding computing / processing device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network), or downloaded to an external computer or external storage device. The network may 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 within the corresponding computing / processing device.

[0152] 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 parameter, the configuration data of the 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 the connection to an external computer (for example, using an Internet service provider through the Internet) can be executed. 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 performing various aspects or operations.

[0153] These computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine, such 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 may also be stored in a computer-readable storage medium, which may direct a computer, a programmable data processing device, and / or other device to operate in a particular manner, such 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.

[0154] 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 performed 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.

[0155] The flowchart and block diagram in the figure illustrate the possible implementation architecture, function and operation 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 a specified logical function. Compared with what is shown in the figure, 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 block may not appear in the order shown in the figure. For example, in fact, the two blocks shown in succession can be executed simultaneously or substantially simultaneously, or, depending on the functions involved, these blocks can sometimes be executed in the opposite order. 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 hardware, which performs a specified function or action or performs a combination of special hardware and computer instructions.

[0156] 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 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. An apparatus for a non-real-time radio access network intelligent controller (NRT-RIC) framework in an open radio access network (O-RAN), the apparatus comprising: Memory, which stores instructions; as well as At least one processor is configured to implement the NRT-RIC framework of NRT-RIC by executing the instructions to perform the following operations: receiving, from an rApp hosted by the NRT-RIC, a first request to retrieve a configuration mode of at least one network element in the O-RAN, the first request comprising a first R1-O1 configuration management (CM) data model identifying the at least one network element, and the first request being received via an R1 interface between the rApp and the NRT-RIC framework within the O-RAN architecture; and sending a first response to the requested configuration mode from the NRT-RIC framework to the rApp via the R1 interface, the first response comprising a second R1-O1 CM data model, the second R1-O1 CM data model identifying the at least one network element and identifying at least one CM attribute of the at least one network element, The R1 interface enables the NRT-RIC framework and the rApp to produce and consume at least one O1 interface-related R1 service in the NRT-RIC.

2. The apparatus of claim 1, wherein the first R1-O1 CM data model comprises: A message type parameter, identifying the type of the first request; as well as At least one network element parameter includes a network element identifier (ID).

3. The apparatus of claim 2, wherein the second R1-O1 CM data model comprises: A message type parameter, identifying the type of the first response; as well as For each of the at least one network element, the supported Information Object Class (IOC) entity parameters include one or more associated entity items identifying one or more CM attributes.

4. The apparatus of claim 1 , wherein the at least one processor is further configured to execute the instructions to: receiving a second request from the rApp, the second request for reading configuration data of a CM attribute of the at least one CM attribute identified in the first response, the second request comprising a third R1-O1 CM data model identifying a network element and the CM attribute, and the second request being received via the R1 interface; and In response to the second request, a second response is sent from the NRT-RIC framework to the rApp via the R1 interface, the second response including a fourth R1-O1 CM data model identifying the CM attributes.

5. The apparatus of claim 4, wherein the third R1-O1 CM data model comprises: A message type parameter, identifying the type of the second request; rApp identifier (ID), identifying the rApp; a request identifier (ID) of the second request; Network element parameters, including a network element ID of the network element; as well as The first named IOC entity parameter includes an IOC entity name and a first related entity item identifying the CM attribute.

6. The apparatus of claim 4, wherein the fourth R1-O1 CM data model comprises: A message type parameter, identifying the type of the second response; rApp ID, identifying the rApp; Network element parameters, including said network element identifier (ID); The second named IOC entity parameter includes the IOC entity name and a second related entity item identifying the CM attribute.

7. The apparatus according to claim 5, wherein the second related entity item further comprises: CM attribute value, identifying the value of the CM attribute.

8. The apparatus of claim 1, wherein the at least one processor is further configured to execute the instructions to: receiving a third request from the rApp, the third request for configuration data written to a CM attribute of the at least one CM attribute, the third request comprising a fifth R1-O1 CM data model identifying a network element and the CM attribute, and the third request being received via the R1 interface; and A third response including a sixth R1-O1 CM data model is sent from the NRT-RIC framework to the rApp via the R1 interface, the sixth R1-O1 CM data model being used to identify the CM attribute modified in response to the third request.

9. The apparatus of claim 8, wherein the fifth R1-O1 CM data model comprises: A message type parameter, identifying the type of the third request; rApp ID, identifying the rApp; network element parameters, including a network element identifier (ID) of said network element; The third named IOC entity parameter includes an IOC entity name and a third related entity item, wherein the third related entity item identifies the CM attribute to be modified in response to the third request.

10. The apparatus of claim 8, wherein the sixth R1-01 CM data model comprises: A message type parameter, identifying the type of the third response; the rApp ID; Network element parameters, including said network element identifier (ID); confirming the attribute status of the configuration status; as well as The fourth named IOC entity parameter includes the IOC entity name and a fourth related entity item, where the fourth related entity item identifies the CM attribute and the written status.

11. The apparatus according to claim 10, wherein based on the fact that the writing is not accepted, the fourth related entity item further comprises: A reason parameter identifies the reason why the write was not accepted.

12. A method for a non-real-time radio access network intelligent controller (NRT-RIC) framework in an open radio access network (O-RAN), the method comprising: receiving, from an rApp hosted by the NRT-RIC, a first request to retrieve a configuration mode of at least one network element in the O-RAN, the first request comprising a first R1-O1 CM data model identifying the at least one network element, and the first request being received via an R1 interface between the rApp and the NRT-RIC framework within the O-RAN architecture; and sending a first response to the requested configuration mode from the NRT-RIC framework to the rApp via the R1 interface, the first response comprising a second R1-O1 CM data model, the second R1-O1 CM data model identifying the at least one network element and identifying at least one configuration management (CM) attribute of the at least one network element, The R1 interface enables the NRT-RIC framework and the rApp to produce and consume at least one O1 interface-related R1 service in the NRT-RIC.

13. The method of claim 12, wherein the first R1-O1 CM data model comprises: A message type parameter, identifying the type of the first request; as well as At least one network element parameter includes a network element identifier (ID).

14. The method of claim 12, wherein the first R1-O1 CM data model comprises: A message type parameter, identifying the type of the first request; as well as At least one network element parameter includes a network element identifier (ID).

15. The method of claim 12, wherein the second R1-O1 CM data model comprises: A message type parameter, identifying the type of the first response; as well as For each of the at least one network element, the supported Information Object Class (IOC) entity parameters include one or more associated entity items identifying one or more CM attributes.

16. The method according to claim 12, wherein the method further comprises: receiving a second request from the rApp, the second request for reading configuration data of a CM attribute of the at least one CM attribute identified in the first response, the second request comprising a third R1-O1 CM data model identifying a network element and the CM attribute, and the second request being received via the R1 interface; and In response to the second request, a second response is sent from the NRT-RIC framework to the rApp via the R1 interface, the second response including a fourth R1-O1 CM data model identifying the CM attributes.

17. The method according to claim 12, wherein the method further comprises: receiving a third request from the rApp, the third request for configuration data written to a CM attribute of the at least one CM attribute, the third request comprising a fifth R1-O1 CM data model identifying a network element and the CM attribute, and the third request being received via the R1 interface; and A third response including a sixth R1-O1 CM data model is sent from the NRT-RIC framework to the rApp via the R1 interface, the sixth R1-O1 CM data model being used to identify CM attributes to be modified in response to the third request.

18. A non-transitory computer-readable recording medium having recorded thereon instructions executable by at least one processor, the at least one processor being configured to execute a method for a non-real-time radio access network intelligent controller (NRT-RIC) framework in an open radio access network (O-RAN), the method comprising: receiving, from an rApp hosted by the NRT-RIC, a first request to retrieve a configuration mode of at least one network element in the O-RAN, the first request comprising a first R1-O1 CM data model identifying the at least one network element, and the first request being received via an R1 interface between the rApp and the NRT-RIC framework within the O-RAN architecture; and sending a first response to the requested configuration mode from the NRT-RIC framework to the rApp via the R1 interface, the first response comprising a second R1-O1 CM data model, the second R1-O1 CM data model identifying the at least one network element and identifying at least one configuration management (CM) attribute of the at least one network element, The R1 interface enables the NRT-RIC framework and the rApp to produce and consume at least one O1 interface-related R1 service in the NRT-RIC.

19. The non-transitory computer readable medium of claim 18, wherein the method further comprises: receiving a second request from the rApp, the second request for reading configuration data of a CM attribute of the at least one CM attribute identified in the first response, the second request comprising a third R1-O1 CM data model identifying a network element and the CM attribute, and the second request being received via the R1 interface; and In response to the second request, a second response is issued from the NRT-RIC framework to the rApp via the R1 interface, the second response including a fourth R1-O1 CM data model identifying the CM attributes.

20. The non-transitory computer readable medium of claim 18, wherein the method further comprises: receiving a third request from the rApp, the third request for configuration data written to a CM attribute of the at least one CM attribute, the third request comprising a fifth R1-O1 CM data model identifying a network element and the CM attribute, and the third request being received via the R1 interface; and A third response including a sixth R1-O1 CM data model is sent from the NRT-RIC framework to the rApp via the R1 interface, the sixth R1-O1 CM data model being used to identify CM attributes to be modified in response to the third request.

Images