Method and system for intelligent data collection and management for an open RAN intelligent controller

Abstract

The present disclosure relates to an open radio access network, a method of operating an O-RAN, wherein the O-RAN comprises a non-real-time RAN intelligent controller, a non-RT RIC (12), and a near-real-time RAN intelligent controller, a near-RT RIC (14). According to one embodiment, the method includes providing an interface (16) between the non-RT RIC (12) and the near-RT RIC (14), and sending analysis data from the near-RT RIC (14) to the non-RT RIC (12) using the interface (16).

Description

[Technical Field]

[0001] The present disclosure relates to communication methods and systems. The present disclosure has particular, but not exclusive, relevance to wireless communication systems and devices thereof that operate in accordance with 3rd Generation Partnership Project (3GPP®) standards or equivalents or derivatives thereof. The present disclosure has particular, but not exclusive, relevance to so-called “5G” (or “next generation”) systems that use intelligent data collection / management. More particularly, the present disclosure relates to methods of operating an open radio access network, O-RAN, the O-RAN comprising a non-real-time RAN intelligent controller, non-RT RIC (Non-RT RIC), and a near-real-time RAN intelligent controller, near-RT RIC (Near-RT RIC). [Background technology]

[0002] The following abbreviations and terms (unless otherwise specified) are used in this document: 3GPP 3rd Generation Partnership Project A1 Interface between non-RT RIC and quasi-RT RIC AI artificial intelligence DME Data management and exposure DMS Deployment Management Services E2 Interface between the quasi-RT RIC and the lower RAN functions (O-CU, O-DU, and O-RU) EI Enrichment Information KPI Key Performance Indicator ML Machine Learning Quasi-RT RIC O-RAN Quasi-Real-Time RAN Intelligent Controller Non-RT RIC O-RAN Non-Real Time RAN Intelligent Controller O-CU O-RAN Central Unit O-DU O-RAN Distributed Unit O-RU O-RAN Radio Unit Interface between O1 SMO and O-RAN management elements OAM Operations, Administration and Maintenance RAN Radio Access Network RIC O-RAN RAN Intelligent Controller rApp Non-RT RIC Application SMO Service Management and Orchestration UE User Equipment xApp Quasi-RT RIC Application

[0003] Additionally, this disclosure refers to the following documents, which are incorporated herein by reference: [1] 3GPP TR 21.905: “Vocabulary for 3GPP Specifications”, V17.0.0 (2020-07) [2] O-RAN WG2: “Non-RT RIC Functional Architecture Specification”, V01.00.05 (2022-03) [3] O-RAN WG2: “R1 interface: General Aspects and Principles”, V01.00.12 (2022-03) [4] O-RAN WG2: “A1 interface: General Aspects and Principles”, V02.02 (2021-03) [5] O-RAN WG3: “Near-RT RIC Architecture”, V02.01.04 (2021-11) [6] O-RAN WG3: “Near-Real-time RAN Intelligent Controller Architecture & E2 General Aspects and Principles”, V02.02.01 (2022-03) [7] A. Garcia-Saavedra and X. Costa-Perez, "O-RAN: Disrupting the Virtualized RAN Ecosystem," in IEEE Communications Standards Magazine, vol. 5, no. 4, pp. 96–103, December 2021, doi: 10.1109 / MCOMSTD.101.2000014.

[0004] Embodiments of the present invention are based on the Open Radio Access Network (O-RAN). O-RAN provides a technical concept designed to improve interoperability in the RAN of mobile networks. By defining standards for open interfaces and providing network elements that are abstracted from hardware, O-RAN creates a radio access network that is independent of proprietary technologies.

[0005] As shown in Figure 1, the novel O-RAN architecture for next-generation mobile systems defines a computing platform known as the O-Cloud 110 for offloading signal processing workloads from virtualized BSs. The O-Cloud 110 provides signal processors consisting of software processing devices 112 (e.g., general-purpose CPUs) and HAs 114, such as FPGAs, GPUs, or ASICs. Each processor queues FEC processing requests in a first-in, first-out (FIFO) queue, and once processed, the resulting TB data is sent back to the associated BS.

[0006] 1 shows a high-level diagram of the O-RAN architecture, where only the O-DU (O-RAN Distributed Node) network node 116 is shown for simplicity. As shown, the O-RAN architecture consists of network functions (e.g., O-DU 116) controlled by a near-real-time (near-RT) RAN Intelligent Controller (RIC) 118 through an E2 interface 120, a Service Management and Orchestration Framework (SMO) 122 for managing the network functions, and an O-Cloud 110 (O-RAN Cloud) for hosting cloudified network functions. The SMO 122 includes a non-real-time (non-RT) RAN Intelligent Controller (RIC) 124 as a central component, enabling non-real-time control and optimization of RAN elements and resources.

[0007] In the O-RAN, BSs (or, more specifically, O-DUs 116) are controlled by a Near Real-Time RAN Intelligent Controller (Near-RT RIC) 118 using applications. These applications, known as xApps, operate on timescales of approximately 10-100 ms (i.e., 10 or 100 times longer than the TTI). Data-driven policies are deployed within the Near-RT RIC 118, and the E2 interface 120 can be used to control the offloading strategies of BSs deployed on the prototype O-Cloud 110 platform. Common 3GPP Radio Resource Management (RRM) operations, for example, are performed through this interface. Conversely, the O2 interface 126 is used to provide two services: infrastructure management services (deployment and management of the O-Cloud 110 infrastructure) and deployment management services (lifecycle management of virtualized deployments on the O-Cloud 110 infrastructure).

[0008] ORAN Working Group 2 is currently defining the non-RT RIC architecture [2], the R1 interface [3], and the A1 interface [4], and ORAN Working Group 3 is currently defining the quasi-RT RIC architecture [5], and the E2 interface [6].

[0009] In the current ORAN design, applications in non-RT RICs can only obtain raw data from base stations via the defined O1 interface. While current ORAN designs and specifications allow non-RT RICs to provide analytical information to quasi-RT RICs in the form of enrichment information, they are unable to efficiently utilize the analytical data generated by the quasi-RT RIC, let alone access and obtain analytical data from the quasi-RT RIC in the other direction. [2][3] This wastes network resources in the mobile operator infrastructure because large amounts of raw data must be transported over the O1 interface, even though some relevant analytical data may be available within the quasi-RT RIC. This leads to multiple drawbacks in both network and application performance, not only causing redundant data collection but also potentially introducing delays in data collection and processing. In particular, some analytical data must be processed or trained by selected analytical tools or ML models, which in turn requires additional training time. [Prior art documents] [Non-patent literature]

[0010] [Non-Patent Document 1] 3GPP TR 21.905: “Vocabulary for 3GPP Specifications”, V17.0.0 (2020-07) [Non-patent document 2] O-RAN WG2: “Non-RT RIC Functional Architecture Specification”, V01.00.05 (2022-03) [Non-patent document 3] O-RAN WG2: “R1 interface: General Aspects and Principles”, V01.00.12 (2022-03) [Non-patent document 4] O-RAN WG2: “A1 interface: General Aspects and Principles”, V02.02 (2021-03) [Non-patent document 5] O-RAN WG3: “Near-RT RIC Architecture”, V02.01.04 (2021-11) [Non-patent document 6] O-RAN WG3: “Near-Real-time RAN Intelligent Controller Architecture & E2 General Aspects and Principles”, V02.02.01 (2022-03) [Non-Patent Document 7] A. Garcia-Saavedra and X. Costa-Perez, "O-RAN: Disrupting the Virtualized RAN Ecosystem," in IEEE Communications Standards Magazine, vol. 5, no. 4, pp. 96-103, December 2021, doi: 10.1109 / MCOMSTD.101.2000014 Summary of the Invention [Problem to be solved by the invention]

[0011] It is an object of the present disclosure to improve and further develop open radio access networks, O-RAN, and the methods of operating them so that available information can be used more efficiently and intelligently. [Means for solving the problem]

[0012] According to the present invention, the above-mentioned object is achieved by a method of operating an open radio access network, O-RAN, wherein the O-RAN comprises a non-real-time RAN intelligent controller, non-RT RIC, and a quasi-real-time RAN intelligent controller, quasi-RT RIC, the method comprising the steps of providing an interface between the non-RT RIC and the quasi-RT RIC, and sending analysis data from the quasi-RT RIC to the non-RT RIC using the interface.

[0013] Furthermore, the above-mentioned object is achieved by an open radio access network, O-RAN, system, the O-RAN system comprising a non-real-time RAN intelligent controller, non-RT RIC, a quasi-real-time RAN intelligent controller, quasi-RT RIC, and an interface between the non-RT RIC and the quasi-RT RIC, the interface being configured to enable sending analysis data from the quasi-RT RIC to the non-RT RIC.

[0014] To address and resolve the above-mentioned problems caused by current inefficient data collection mechanisms, the present disclosure proposes intelligent data collection via a data management and publishing (DME) solution to provide data, including analytical data, generated from quasi-RT RICs to non-RT RICs. More specifically, embodiments of the present disclosure resolve the following unaddressed problems in ORAN: - How can non-RT RICs find the analytical data they need that are generated by quasi-RT RICs? - How can non-RT RICs access and retrieve the required analytical data generated by quasi-RT RICs? - What type of data information is relevant to non-RT RICs? - What new parameters are needed to improve the efficiency of data collection? How will these new parameters be used? - How can non-RT RICs effectively use analytical data generated by quasi-RT RICs?

[0015] Embodiments of the present disclosure propose a new method, including a suite of new interfaces and procedures, for an O-RAN non-real-time RAN intelligent controller (non-RT RIC) to collect analytical data. A new set of parameters to be used in these procedures is proposed together to enable the non-RT RIC to acquire data more efficiently while optimizing operator network resource utilization and reducing overall data collection, inference, and training time.

[0016] Currently, there is a unidirectional A1 interface that allows a quasi-RT RIC to obtain analytical data from a non-RT RIC. The purpose of the new interface according to the present disclosure is to allow an rApp in a non-RT RIC to obtain analytical data provided by an xApp in a quasi-RT RIC. According to one embodiment, the new interface may be implemented as a bidirectional extension of the currently defined unidirectional A1-EI interface. According to alternative or additional embodiments, the new interface may be implemented as an entirely new interface—either unidirectional or bidirectional—to allow for the provision of analytical data from a quasi-RT RIC to a non-RT RIC.

[0017] The definition of a new interface and suite of data collection and management related procedures, including data registration procedures, data discovery procedures, data subscription procedures, and data request procedures, enables applications (e.g., rApps) in non-RT RICs to discover and obtain the required analytical data from quasi-RT RICs (provided by xApps) or possibly even from non-RT RICs (provided by rApps).

[0018] In the context of the present disclosure, the term “analytics data” should be understood broadly and may generally include all types of data that may be produced in a quasi-RT RIC and required by a non-RT RIC, or vice versa. For example, considering a massive MIMO (multiple-input multiple-output) use case, an xApp in the quasi-RT RIC can produce analytics data for UE trajectory prediction, cell coverage prediction, cell load prediction, and traffic prediction based on collected raw data. An rApp in the non-RT RIC, whose primary functionality is to optimize massive MIMO beamforming, can utilize these analytical data from the xApp for beam management optimization rather than training its AI / ML model based solely on raw data. Thus, providing analytical data according to embodiments disclosed herein reduces duplicated data collection, reduces the load on O1, and improves the efficiency of AI / ML model training.

[0019] According to embodiments of the present disclosure, to improve the efficiency of data collection in terms of saving network resources, reducing overall data collection time and training time, new parameters (i.e., Data Source, Output Data Function ID, and Methods Used) are defined to specify the data source, output data type, and methods used. These new parameters may not only be used in procedures / messages from quasi-RT RIC to non-RT RIC, but may also be used in current procedures / messages from non-RT RIC to quasi-RT RIC to bring efficiency to data collection.

[0020] Currently, in the ORAN design, non-RT RICs can provide analytical information to quasi-RT RICs in the form of enrichment information, but cannot collect analytical data from quasi-RT RICs. Embodiments of the present disclosure propose a new interface and suite of data management-related procedures, namely, data registration procedures, data discovery procedures, data subscription procedures, and data request procedures, to enable applications in non-RT RICs to discover and obtain needed analytical data from quasi-RT RICs. In this way, analytical data generated by applications in quasi-RT RICs can be used by applications in non-RT RICs, thus providing a significantly greater selection of data and reducing the amount of data collection.

[0021] Currently, in current O-RAN systems, i.e., as described in references [2]-[6], the purpose of data collection is to obtain data that exists in a database, and therefore the data cannot be used intelligently. Embodiments of the present disclosure propose to use several parameters, such as the output data function ID and the method used, to enable applications to undertake data analysis based on data from different data sources and different methods, and therefore use the data efficiently and intelligently.

[0022] Note that there are many non-RT RIC use cases and applications that can also benefit from obtaining analytical data directly from the quasi-RT RIC, such as vrAIn as described in [7]. vrAIn requires context information from all base stations deployed within the O-Cloud. This information includes the average and variance SNR across all UEs within each base station, as well as the aggregated buffer state within a time period. By aggregating and analyzing this information in the quasi-RT-RIC, vrAIn saves significant bandwidth on the O1 interface.

[0023] According to one embodiment of the present disclosure, a new interface is provided between a non-RT RIC and a quasi-RT RIC to send analytical data from the quasi-RT RIC to the non-RT RIC. This interface can be used by an xApp to register its produced data with the non-RT RIC along with some data-related parameters. The interface can also be used by an rApp to discover its required data produced by an xApp in the quasi-RT RIC along with some data-related parameters, to subscribe to its required data produced by an xApp in the quasi-RT RIC along with some data-related parameters, and / or to request its required data produced by an xApp in the quasi-RT RIC along with some data-related parameters.

[0024] According to one embodiment of the present disclosure, a data registration procedure may be performed that allows an xApp in a quasi-RT RIC to register the data it provides to the non-RT RIC along with some data-related parameters to facilitate intelligent use of the data (xApp -> DME in the non-RT RIC). In this context, it may be specified that the xApps are registering their generated data in the non-RT RIC via a novel interface between the non-RT RIC and the quasi-RT RIC.

[0025] According to one embodiment of the present disclosure, a data discovery procedure may be performed that enables an rApp in a non-RT RIC to discover data provided in the non-RT RIC along with some data-related parameters to facilitate intelligent use of the data (rApp -> DME in the non-RT RIC). In this context, it may be provided that an rApp requests discovery of required data from a function that registers / manages data in the non-RT RIC. The function that registers / manages data in the non-RT RIC may respond with information related to the required data.

[0026] According to one embodiment of the present disclosure, a data subscription procedure may be performed that allows an rApp in a non-RT RIC to subscribe to required data provided by an xApp in a quasi-RT RIC along with some data-related parameters to facilitate intelligent use of the data (rApp -> DME in the non-RT RIC). In this context, it may be specified that an rApp requests to subscribe to the required data from a function that registers / manages data in the non-RT RIC. The function that registers / manages data in the non-RT RIC may subscribe to the required data via an interface between the non-RT RIC and the quasi-RT RIC. The quasi-RT RIC may respond with information on how to collect the required data.

[0027] According to one embodiment of the present disclosure, a data request procedure may be performed that allows an rApp in a non-RT RIC to request data provided by an xApp in a quasi-RT RIC along with some data-related parameters to facilitate intelligent use of the data (rApp -> DME in the non-RT RIC). In this context, it may be specified that an rApp requests the required data from a function that registers / manages data in the non-RT RIC. The function that registers / manages data in the non-RT RIC may subscribe to the required data via an interface between the non-RT RIC and the quasi-RT RIC. The quasi-RT RIC may respond with information on how to collect the required data.

[0028] According to the above embodiments, the present disclosure provides two different ways to obtain analytical data from a quasi-RT RIC: one is a data subscription and the other is a data request. With a data subscription, the xApp provides the rApp with the required data as long as the subscription is valid. The xApp will stop providing data to the rApp only when the rApp terminates the subscription. On the other hand, with a data request, the xApp provides the rApp with the required data in a one-time operation, i.e., upon request. It will be understood that an rApp can utilize both options in parallel / simultaneously.

[0029] There are several ways how the teaching of the present invention can be advantageously designed and further developed. For this purpose, reference is made on the one hand to the dependent claims and on the other hand to the following description of preferred embodiments of the invention, which are shown by way of example in the figures. In connection with the description of preferred embodiments of the invention with the aid of the figures, generally preferred embodiments and further developments of the teaching are explained. In the figures: [Brief explanation of the drawings]

[0030] [Figure 1] FIG. 1 is a block diagram illustrating a schematic overview of a typical O-RAN architecture according to the prior art. [Figure 2] FIG. 1 is a block diagram that schematically illustrates an O-RAN architecture with a new interface between a non-RT RIC and a quasi-RT RIC, in accordance with an embodiment of the present disclosure. [Figure 3] FIG. 1 illustrates a data registration procedure according to an embodiment of the present disclosure. [Figure 4] FIG. 1 illustrates a data discovery procedure for an rApp in a non-RT RIC according to one embodiment of the present disclosure. [Figure 5] FIG. 1 illustrates a data subscription procedure for an rApp in a non-RT RIC according to one embodiment of the present disclosure. [Figure 6] FIG. 1 illustrates a data request procedure for an rApp in a non-RT RIC according to one embodiment of the present disclosure. [Figure 7] FIG. 1 illustrates schematically an O-RAN architecture to which aspects of the present disclosure are applicable. [Figure 8] FIG. 8 is a block diagram illustrating, in simplified form, the salient components of a UE communicating with the system shown in FIG. 7. [Figure 9] FIG. 8 is a block diagram illustrating the main virtual components of a v(R)AN used in the system shown in FIG. [Figure 10] FIG. 8 is a block diagram illustrating, in simplified form, the main virtual components of a typical core network node (or function) used within the system shown in FIG. 7. DETAILED DESCRIPTION OF THE INVENTION

[0031] Currently, in ORAN designs, non-RT RICs can provide analytical information to quasi-RT RICs in the form of enrichment information, but cannot collect analytical data from the quasi-RT RIC. According to one embodiment, the present disclosure provides an O-RAN architecture that includes a new interface between the non-RT RIC 12 and the quasi-RT RIC 14. As shown in the exemplary architecture illustrated in FIG. 2, a new interface 16 may be configured to send analytical data from the quasi-RT RIC 14 to the non-RT RIC 12. In particular, the new interface 16 may be defined to enable an rApp 18 in the non-RT RIC 12 to obtain analytical data provided by an xApp 20 in the quasi-RT RIC 14. As shown in FIG. 2, the new interface 16 may be realized by extending the currently defined unidirectional A1-EI interface to be bidirectional, or may be specified as an entirely new interface to enable the quasi-RT RIC 14 to provide analytical data to the non-RT RIC 12. This design offers significant implementation flexibility.

[0032] As will be appreciated by those skilled in the art, different names may be used for the above designs, particularly for new interfaces, while serving the same and similar purposes.

[0033] According to another aspect of the present disclosure, a data registration procedure may be implemented that allows an xApp 20 in a quasi-RT RIC 14 to register the data it provides to a non-RT RIC 12 along with new parameters to facilitate intelligent use of the data. The main idea of ​​the data registration procedure is that the xApp 20 sends a data registration request to the non-RT RIC 12 to register the data it will produce. According to one embodiment, the xApp 20 may register the data it provides to a DME 22 in the non-RT RIC 12.

[0034] 3 illustrates a data registration procedure according to one embodiment of the present disclosure. This procedure focuses on the interaction between the xApp 20 in the quasi-RT RIC 14 and the function that registers / manages data in the non-RT RIC 12. The function that will register / manage data in the non-RT RIC 12 may be the DME 22 or another entity with a different name that serves the same and similar purpose.

[0035] As shown in FIG. 3, the following steps may be performed for an xApp 20 in a quasi-RT RIC 14 to register the data it provides to a non-RT RIC 12.

[0036] As shown in step S310, to register its generated data, xApp 20 may invoke a data registration request procedure or any other related procedure, or may send a "data registration request" message or any other related message to non-RT RIC 12 via terminating function 16a of new interface 16 to register its generated data. New interface terminating function 16a in quasi-RT-RIC 14 may be an A1-related function supporting bidirectional A1-EI to provide analytical data in both directions.

[0037] The message sent from the xApp 20 to the new interface termination function 16a in step S310 may include one or more of the following parameters: - xApp ID (i.e. the ID of the xApp20 itself) or SDL ID (SDL, Storage Definition Languages, file identifier), - Sub-RT RIC ID (i.e., the ID of the Sub-RT RIC 14 associated with the xApp 20 providing the data); - Analytical data types of data generated by xApp20, - Analytics data reporting information to indicate the status and / or configuration related to collecting analytics data, such as the interval between data generation; - Data source used. This parameter indicates what data source xApp20 is using to generate the analysis data. If the registered output data from xApp20 is statistical data or inferred data, this parameter can list the original data source. This will help data consumers to understand the output data better. - an output data function ID. Examples of output data functions include, but are not limited to, raw data, statistical data, inferred data, etc.; and / or - Methods used. Specifying what methods are used will help data consumers better understand how the output data is generated, e.g., based on what source data. Examples of methods used include, but are not limited to, traditional methods such as linear regression, AI / ML methods such as deep learning algorithms, or a combination of the above.

[0038] As will be appreciated by those skilled in the art, different names may be used for the above parameters to serve the same and similar purposes. Furthermore, it should be noted that the above parameters may be used in the same or similar manner in connection with various other embodiments disclosed herein, particularly in connection with data discovery procedures, data subscription procedures, and data request procedures as described below.

[0039] Regarding the parameter "analysis data type" above, it should be noted that this parameter generally specifies the type of analysis data (e.g., generated by xApp), such as UE trajectory prediction, cell coverage prediction, and cell load prediction. Because the parameter specifies the data type of the analysis data, the parameter cannot be applied to raw data.

[0040] Regarding the parameter "output data function" above, note that this parameter generally specifies whether the generated data is raw data, statistical data, or inferred data. Raw data is not analytical data. Statistical data can be analytical data without prediction. Inferred data is analytical data with prediction. Each output data function can be assigned an identifier to create an output data function ID (e.g., output data function 1 = raw data, output data function 2 = statistical data, output data function 3 = inferred data).

[0041] 3, the new interface termination function 16a in the quasi-RT RIC 14 may invoke a data registration request procedure or any other related procedure, or send a "data registration request" message or any other related message to the associated interface termination function 16b on the new interface 16 between the quasi-RT RIC 14 and the non-RT RIC 12. As will be appreciated by those skilled in the art, different names may be used for the above messages to serve the same and similar purposes.

[0042] As shown in step S330, the new interface termination function 16b in the non-RT RIC 12 may forward the data registration request procedure or any other related procedure, or send a "data registration request" message or any other related message to a function that registers / manages data in the non-RT RIC 12, which may be the DME 22 (as shown in FIG. 3) or any other entity with a different name that serves the same and similar purpose.

[0043] The function that registers / manages data in the non-RT RIC 12, i.e., the DME 22 in the exemplary embodiment of FIG. 3, performs data registration of the data provided by the xApp 20, as shown in step S340.

[0044] After the data registration step, and as shown in steps S350, S360, and S370, the function that registers / manages data in the non-RT RIC 12, i.e., DME 22 in the illustrated embodiment, responds with a "Data Registration Response" message or any other relevant message, which is forwarded to the respective xApp 20 via the interface termination functions 16b, 16a of the new interface 16. As will be appreciated by those skilled in the art, different names may be used for the above messages to serve the same and similar purposes.

[0045] A similar data registration procedure as described above in connection with Figure 3 may be used by rApp 18 over R1 interface 24 to register its data within a function that registers / manages data within non-RT RIC 12. The function that registers / manages data within non-RT RIC may be DME 22 as shown in Figure 3, or any other entity with a different name that serves the same and similar purpose.

[0046] Each message sent from the rApp 18 to the DME 22 for data registration may include one or more of the following parameters: - the rApp ID (i.e. the ID of the rApp18 itself), - Analytical data types for data generated by rApp18, - Analytics data reporting information to indicate the status and / or configuration related to reporting analytics data, such as the interval between data generation; - Data source used. This parameter indicates what data source rApp18 is using to generate the analysis data. If the registered output data from rApp18 is statistical or inferred data, this parameter will list the original data source. This will help data consumers to better understand the output data. - an output data function ID. Examples of output data functions include, but are not limited to, raw data, statistical data, inferred data, etc.; and / or - The method used. Specifying what method is used will help the data consumer to better understand how the output data was obtained.

[0047] Note again that different names may be used for the above parameters to serve the same and similar purposes.

[0048] According to another aspect of the present disclosure, a data discovery procedure may be implemented that allows an rApp 18 in a non-RT RIC 12 to discover data provided by the non-RT RIC 12 along with new parameters to facilitate intelligent use of the data. The main idea of ​​the data discovery procedure is that the rApp 18 sends a data discovery request to a data registration / management function in the non-RT RIC 12 to discover the requested data. According to one embodiment, the rApp 18 may discover the requested data from the DME 22 in the non-RT RIC 12.

[0049] 4 illustrates a data discovery procedure according to one embodiment of the present disclosure. This procedure focuses on the interaction between the rApp 18 in the non-RT RIC 12 and the function that registers / manages data in the non-RT RIC 12. The function that registers / manages data in the non-RT RIC may be the DME 22 or another entity with a different name that serves the same and similar purpose.

[0050] As shown in FIG. 4, the following steps may be performed for an rApp 18 in a non-RT RIC 12 to discover any data it needs.

[0051] As shown in step S410, to discover the required data, rApp18 may invoke a data discovery request procedure or any other related procedure, or may send a "data discovery request" message or any other related message to a function that registers / manages data in non-RT RIC12, such as DME22, to discover the required data.

[0052] The message sent from the rApp 18 to the DME 22 in step S410 may include one or more of the following parameters: - the rApp ID (i.e. the ID of the rApp18 itself), - Analyze data types of data required by rApp18, - analytical data reporting information to indicate the status and / or configuration related to reporting analytical data; - Data source used. This parameter indicates what data source xApp20 is using to generate the analysis data. If the registered output data from xApp20 is statistical or inferred data, this parameter will list the original data source. This will help data consumers to better understand the output data. - the time interval required to collect the data; - an output data function ID. Examples of output data functions include, but are not limited to, raw data, statistical data, inferred data, etc.; and / or - Methods used. Specifying what methods are used will help data consumers better understand how the output data was obtained. Examples of methods used include, but are not limited to, traditional methods such as linear regression, AI / ML methods such as deep learning algorithms, or a combination of the above.

[0053] Note again that different names may be used for the above parameters to serve the same and similar purposes.

[0054] 4, the function that registers / manages data in the non-RT RIC 12, i.e., DME 22 in the shown case, checks the registered data and finds the required data (provided that the required data is registered). In addition, the function that registers / manages data in the non-RT RIC 12 can also provide alternative data sources to the rApp 18, for example, based on the function's own embedded intelligent data analysis capabilities. For example, the function (i.e., DME 22 in the shown case) can provide alternative analysis data if there is no exact match for the required data, or provide analysis data if the required data is only raw data.

[0055] Different names may be used for the above messages while serving the same and similar purposes.

[0056] As shown in step S430, the function that registers / manages data in the non-RT RIC 12 (i.e., the DME 22 in the shown case) responds with a "Data Discovery Response" message or any other relevant message. The response message from the DME 22 to the rApp 18 may include one or more of the following parameters: - the rApp ID (i.e. the ID of the rApp18 itself), - the ID of the xApp20 and / or rApp18 that can produce and / or provide the required data, - Application ID of the application capable of providing the requested analytical data type; - analytical data reporting information to indicate the status and / or configuration related to reporting analytical data; - Data source used. This parameter indicates what data source xApp20 or rApp18 is using to generate the analysis data. If the registered output data from xApp20 or rApp18 is statistical or inferred data, this parameter will list the original data source. This will help data consumers to better understand the output data. - the time interval used to collect the data; - an output data function ID. Examples of output data functions include, but are not limited to, raw data, statistical data, inferred data, etc.; and / or - Methods used. Specifying what methods are used will help data consumers better understand how the output data was obtained. Examples of methods used include, but are not limited to, traditional methods such as linear regression, AI / ML methods such as deep learning algorithms, or a combination of the above.

[0057] Different names may be used for the above parameters while serving the same and similar purposes.

[0058] Obtaining information along with one or more of the above parameters, in particular the data source, output data function ID, and method used, assists rApp18 to improve data analysis based on data from different data sources and different ways in which the data was obtained, and therefore to use the data efficiently and intelligently.

[0059] According to another aspect of the present disclosure, a data subscription procedure may be implemented that allows an rApp 18 in a non-RT RIC 12 to subscribe to needed data provided by an xApp 20 in a quasi-RT RIC 14 along with new parameters to facilitate intelligent use of the data. The main idea of ​​the data subscription procedure is that an rApp 18 can subscribe to available analytical data from the application that produces the data. According to one embodiment, an rApp 18 may subscribe to needed data from a DME 22 in a non-RT RIC 12.

[0060] 5 illustrates a data subscription procedure according to one embodiment of the present disclosure. This procedure focuses on the interaction between an rApp 18 in a non-RT RIC 12 and an xApp 20 in a quasi-RT RIC 14 that produces the required analytical data.

[0061] As shown in FIG. 5, the following steps may be performed for an rApp 18 in a non-RT RIC 12 to subscribe to the data it needs.

[0062] As shown in steps S510, S512, and S514, it may be specified that xApp 20 stores their generated data in a database 26 in quasi-RT RIC 14, for example, by using an SDL (Storage Definition Language) based database management system 28.

[0063] To subscribe to the required data usage, the rApp 18 performs a data subscription request procedure or any other related procedure, or sends a "Data Subscription Request" message as shown in step S520, or any other related message, to the DME 22. This message sent from the rApp 18 to the DME 22 may include one or more of the following parameters: - the rApp ID (i.e. the ID of the rApp18 itself), - the ID of the xApp20 that can create and / or provide the required data, - the analytical data types required, - analytical data reporting information to indicate the status and / or configuration related to reporting analytical data; - Data source used. This parameter indicates what data source xApp20 is using to generate the analysis data. If the registered output data from xApp20 is statistical or inferred data, this parameter will list the original data source. This will help data consumers to better understand the output data. - the time interval required to collect the data; - an output data function ID. Examples of output data functions include, but are not limited to, raw data, statistical data, inferred data, etc.; and / or - Methods used. Specifying what methods are used will help data consumers better understand how the output data was obtained. Examples of methods used include, but are not limited to, traditional methods such as linear regression, AI / ML methods such as deep learning algorithms, or a combination of the above.

[0064] Different names may be used for the above parameters while serving the same and similar purposes.

[0065] As shown in steps S522, S524, and S526, the DME 22 forwards the "Data Subscription Request" message or any other related message to a function that manages data within the quasi-RT RIC 14 to process the data subscription request procedure or any other related procedure or to collect the required data. According to the embodiment shown, the respective message is relayed over the new interface 16 described in detail above via interface terminal functions 16b, 16a.

[0066] The facility that manages the data in the quasi-RT RIC 14 may be an SDL-based database management system 28, or any other entity that provides the same or similar functionality.

[0067] The "Data Subscription Request" message sent from the DME 22 to the SDL-based database management system 28 may include one or more of the parameters specified above. According to a preferred embodiment, the "Data Subscription Request" message sent from the DME 22 to the SDL-based database management system 28 may include exactly the same parameters (see step S520) as the message sent from the rApp 18 to the DME 22.

[0068] As shown in step S530, the function that manages the data in the quasi-RT RIC 14 fetches the data when it is available or updated. In particular, as shown in FIG. 5, the database management system 28 may fetch the data from the database 26 when it is available.

[0069] In steps S540, S542, and S544, the functionality managing the data in the quasi-RT RIC 14 responds with a "Data Subscription Response" message or any other relevant message. This message sent from the SDL-based database management system 28 to the DME 22 may include one or more of the following parameters: - the rApp ID (i.e. the ID of the rApp18 itself), - xApp ID of xApp20, capable of generating and / or providing the required data, - the analytical data types required, - analytics data reporting information to indicate the status and / or configuration related to reporting analytics data; - Data source used. This parameter indicates what data source xApp20 is using to generate the analysis data. If the registered output data from xApp20 is statistical or inferred data, this parameter will list the original data source. This will help data consumers to better understand the output data. - the time interval used to collect the requested data; - Output data function ID. Examples of output data functions include, but are not limited to, raw data, statistical data, inferred data, etc. - Methods used. Specifying what methods are used will help data consumers better understand how the output data was obtained. Examples of methods used include, but are not limited to, traditional methods such as linear regression, AI / ML methods such as deep learning algorithms, or a combination of the above. - Location of the data; and / or - Method of data delivery.

[0070] As shown in step S550, the DME 22 responds to the rApp 18 with a "Data Subscription Response" message or any other relevant message.

[0071] Obtaining information about the above-mentioned parameters, in particular information about the data sources used and the methods used, helps rApp18 to improve data analysis based on data from different data sources and different methods by which the data was obtained, and therefore to use the data efficiently and intelligently.

[0072] A similar data subscription procedure as described above may be used by rApp 18 to subscribe to data produced / provided by a function that registers / manages data in non-RT RIC 12 over R1 interface 24. The function that registers / manages data in non-RT RIC 12 may be DME 22 or any entity with another name that serves the same and similar purpose. Each message sent from rApp 18 to DME 22 may include one or more of the following parameters: - the rApp ID (i.e. the ID of the rApp18 itself), - the rApp ID of the rApp18 that can generate and / or provide the required data; - Analytical data types for data generated by rApp18, - Analytics data reporting information to indicate the status and / or configuration related to reporting analytics data, such as the interval between data generation; - Data source used. This parameter indicates what source rApp18 is using to generate the analytical data. If the registered output data from rApp18 is statistical or inferred data, this parameter will list the original data source. This will help data consumers to better understand the output data. - the time interval required to collect the data; - output data function ID, - The method used, which will help the data consumer to better understand how the output data was obtained.

[0073] Different names may be used for the above parameters while serving the same and similar purposes.

[0074] According to another aspect of the present disclosure, a data request procedure may be implemented that allows an rApp 18 in a non-RT RIC 12 to obtain needed data provided by an xApp 20 in a quasi-RT RIC 14 along with new parameters to facilitate intelligent use of the data (rApp -> DME in the non-RT RIC). The main idea of ​​the data request procedure is to allow an rApp 18 to request one-time needed analytical data from the application that produces the requested data. According to one embodiment, an rApp 18 may request needed data from a DME 22 in a non-RT RIC 12.

[0075] 6 illustrates a data request procedure for an rApp 18 in a non-RT RIC 12 to obtain needed data, according to one embodiment of the present disclosure. This procedure focuses on the interaction between the rApp 18 in the non-RT RIC 12 and the xApp 20 in the quasi-RT RIC 14 that produces the needed analytical data.

[0076] As shown in FIG. 6, the following steps may be performed for an rApp 18 in a non-RT RIC 12 to obtain / acquire the data it needs.

[0077] As shown in steps S610, S612, and S614, it is again assumed that xApp 20 stores their generated data in a database 26 within quasi-RT RIC 14, for example, by using an SDL (Storage Definition Language) based database management system 28.

[0078] To request the required data, it may be provided that rApp 18 invokes a Request Data Request procedure or any other related procedure, or sends a "Request Data" message as shown in step S620, or any other related message, to DME 22 to collect the required data. This message from rApp 18 to xApp 20 may include one or more of the following parameters: - the rApp ID (i.e. the ID of the rApp18 itself), - the ID of the xApp20 that can generate and / or provide the required data; - the analytical data types required, - analytical data reporting information to indicate the status and / or configuration related to reporting analytical data; - Data source used. This parameter indicates what source xApp20 is using to generate the analytical data. If the registered output data from xApp20 is statistical or inferred data, this parameter will list the original data source, which will help data consumers to better understand the output data. - the time interval required to collect the data; - an output data function ID. Examples of output data functions include, but are not limited to, raw data, statistical data, inferred data, etc.; and / or - Methods used. Specifying what methods are used will help data consumers better understand how the output data was obtained. Examples of methods used include, but are not limited to, traditional methods such as linear regression, AI / ML methods such as deep learning algorithms, or a combination of the above.

[0079] Different names may be used for the above parameters and messages while serving the same and similar purpose.

[0080] Next, as shown in step S630, the DME 22 (or any other function that registers / manages data in the non-RT RIC 12) checks whether the required data is stored in the database 30 internal to the non-RT RIC 12.

[0081] If the data is stored in the database 30 in the non-RT RIC 12, the procedure proceeds to step S640, that is, the DME 22 fetches the required data from the database 30 in the non-RT RIC 12.

[0082] On the other hand, if the data is not stored in the database 30 in the non-RT RIC 12, the procedure proceeds to steps S650, S652, and S654. Accordingly, the DME 22 invokes a request data request procedure or any other related procedure, or sends a "request data request" message or any other related message to the function managing the data in the quasi-RT RIC 14 to collect the required data. Specifically, as shown in steps S650, S652, and S654, the message is forwarded over the new interface 16 (see FIG. 2) via interface terminal functions 16b, 16a. The function managing the data in the quasi-RT RIC 14 may be an SDL-based database management system 28 (as shown in FIG. 6) or any other entity providing the same or similar functionality.

[0083] Messages sent from the DME 22 to the SDL 28 may include one or more of the following parameters: - the rApp ID (i.e. the ID of the rApp18 itself), - the ID of the xApp20 that can generate and / or provide the required data; - the analytical data types required, - analytical data reporting information to indicate the status and / or configuration related to reporting analytical data; - Data source used. This parameter indicates what source xApp20 is using to generate the analytical data. If the registered output data from xApp20 is statistical or inferred data, this parameter will list the original data source, which will help data consumers to better understand the output data. - the time interval required to collect the data; - an output data function ID. Examples of output data functions include, but are not limited to, raw data, statistical data, inferred data, etc.; and / or - Methods used. Specifying what methods are used will help data consumers better understand how the output data was obtained. Examples of methods used include, but are not limited to, traditional methods such as linear regression, AI / ML methods such as deep learning algorithms, or a combination of the above.

[0084] Different names may be used for the above parameters to serve the same and similar purposes.

[0085] As shown in step S660, the SDL database management system 28 (or any other facility that manages data within the quasi-RT RIC 14) fetches the data when it is available in the database 26 of data within the quasi-RT RIC 14.

[0086] Next, as shown in step S670, the SDL database management system 28 (or any other function managing data in the quasi-RT RIC 14) responds with a "Request Data Response" message or any other relevant message. This message is forwarded to the DME 22 (or any other function managing data in the non-RT RIC 12) via the interface terminating functions 16a, 16b of the new interface 16 (as shown in FIG. 2), as shown in steps S672 and S674. The message sent from the SDL 28 to the DME 22 may include one or more of the following parameters: - the rApp ID (i.e. the ID of the rApp18 itself), - the ID of the xApp20 that can generate and / or provide the required data; - the analytical data types required, - analytical data reporting information to indicate the status and / or configuration related to reporting analytical data; - Data source used. This parameter indicates what source xApp20 is using to generate the analytical data. If the registered output data from xApp20 is statistical or inferred data, this parameter will list the original data source, which will help data consumers to better understand the output data. - the time interval used to collect the data; - Output data function ID. Examples of output data functions include, but are not limited to, raw data, statistical data, inferred data, etc. - Methods used. Specifying what methods are used will help data consumers better understand how the output data was obtained. Examples of methods used include, but are not limited to, traditional methods such as linear regression, AI / ML methods such as deep learning algorithms, or a combination of the above. - Location of the data; and / or - The method used for data delivery.

[0087] As shown in step S680, the DME 22 responds to the rApp 18 with a "Request Data Response" message or any other relevant message.

[0088] Obtaining information along with one or more of the above parameters, in particular the data source used and the method used, assists rApp18 to undertake improved data analysis based on data from different data sources and different methods by which the data was obtained, and thus to use the data efficiently and intelligently.

[0089] A similar data request procedure as described above in connection with Figure 6 may be used by rApp 18 over R1 interface 24 to request that data at the end function that registers / manages the data in non-RT RIC 12. The function that registers / manages the data in the non-RT RIC may be DME 22 as shown in Figure 6, or any other entity with a different name that serves the same and similar purpose.

[0090] Each message for a data request sent from the rApp 18 to the DME 22 may include one or more of the following parameters: - the rApp ID (i.e. the ID of the rApp18 itself), - ID of the rApp18 that can generate and / or provide the required data, - rApp18 generated analytical data types, - Analytics data reporting information to indicate the status and / or configuration related to reporting analytics data, such as the interval between data generation; - Data source used. This parameter indicates what source the rApp18 used or is using to generate the analytical data. If the registered output data from the rApp is statistical or inferred data, this parameter will list the original data source, which will help the data consumer to better understand the output data. - Output Data Function ID, and / or - Method used. This parameter will help the data consumer to better understand how the output data was obtained.

[0091] Different names may be used for the above parameters while serving the same and similar purposes.

[0092] According to embodiments of the present disclosure, new parameters proposed herein, such as the data source used, the output data function ID, and the method used, are provided by the non-RT RIC 12 to the quasi-RT RIC 14 via a similarly new or extended A1-EI interface 16. These parameters are used in data registration, data discovery, data subscription, and data request related procedures / messages. In this way, the xApp 20 can improve data analysis based on data from different data sources and different methods, and thus use data efficiently and intelligently.

[0093] System Overview FIG. 7 illustrates schematically an O-RAN architecture to which the above aspects are applicable.

[0094] The architecture comprises functional components: a non-RT RIC 12 and a quasi-RT RIC 14. The former is hosted by the system's SMO framework 10 (e.g., embedded within ONAP), while the latter can be co-located with the 3GPP gNB functions (O-CU and / or O-DU) or in a separate node as long as latency constraints are respected. Figure 7 also shows O-Cloud 8, an O-RAN compliant cloud platform that uses hardware acceleration add-ons, when needed, and a software stack that is decoupled from the hardware, to deploy eNB / gNB as virtualized network functions in a v(R)AN scenario.

[0095] The SMO 10 has various orchestration and management services that can go beyond pure RAN management, such as 3GPP (NG) core management, or end-to-end network slice management. In the context of O-RAN, the primary responsibilities of the SMO 10 include the fault, configuration, accounting, performance, and security (FCAPS) interface to O-RAN network functions, large timescale RAN optimization, and O-Cloud management and orchestration via the O2 interface, including resource discovery, scaling, FCAPS, software management, and interaction with O-Cloud resources.

[0096] The non-RT RIC 12 is a logical function that enables non-real-time control and optimization of RAN elements and resources, AI / ML workflows including model training and updates, and policy-based guidance of applications / features within the quasi-RT RIC 14. The non-RT RIC 12 also provides an A1 interface to the quasi-RT RIC 14. Its primary goal is to support large timescale RAN optimization (seconds or minutes), including policy computation, ML model management, and other radio resource management functions within this timescale. Data management tasks required by the non-RT RIC 12 should be translated to the O1 / O2 interface, and context / enrichment information can be provided to the quasi-RT RIC 14 via the A1 interface.

[0097] The Near-RT RIC14 is a logical function that enables near-real-time optimization and control of O-CU and O-DU nodes and resources and data monitoring on the near-RT time scale (between 10 ms and 1 s) via fine-grained data collection and action over the E2 interface. The near-RT RIC14 control is steered by policy and aided by models computed / trained by the non-RT RIC12. The near-RT RIC14 also supports xApp20, an independent software plug-in to the near-RT RIC14 platform to provide functionality extensibility to the RAN by third parties.

[0098] This architecture essentially provides three independent control loops. Non-RT RIC12 control loop: Large timescale operation on the order of seconds or minutes. The goal is to execute O-RAN specific orchestration decisions, such as policy configuration or ML model training. Quasi-RT RIC14 control loop: Sub-second timescale operations. The goal is to perform tasks such as policy enforcement or radio resource management operations. O-DU Scheduler Control Loop: Real-time operation that performs legacy radio operations such as HARQ, beamforming, or scheduling.

[0099] It will be appreciated that although the control loops are understood to be independent, they may still interact with each other.

[0100] The components of this architecture are configured to implement one or more of the solutions described above.

[0101] User Equipment (UE) FIG. 8 is a block diagram illustrating the main components of a UE (mobile device 3) that communicates with the system shown in FIG. 7. As shown, the UE 3 includes transceiver circuitry 31 operable to transmit signals to and receive signals from connected nodes via one or more antennas 33. While not necessarily shown in FIG. 8, the UE 3 will, of course, have all of the usual functionality of a conventional mobile device (such as a user interface 35), which may be provided by any one or any combination of hardware, software, and firmware, as appropriate. A controller 37 controls the operation of the UE 3 in accordance with software stored in memory 39. The software may be pre-installed in memory 39 and / or downloaded, for example, via a telecommunications network or from a removable data storage device (RMD). The software includes, among other things, an operating system 41 and a communications control module 43. The communications control module 43 is responsible for handling (generating / sending / receiving) signaling messages and uplink / downlink data packets between the UE 3 and other nodes, including the v(R)AN node 5, application functions, and core network nodes. Such signaling includes properly formatted requests and responses related to AI&ML model training, validation, registration, and deployment.

[0102] Virtual RAN (v(R)AN) node FIG. 9 is a block diagram illustrating the major virtual components of an exemplary v(R)AN node 5 (base station) that may be used in the system illustrated in FIG. 7. As illustrated, the v(R)AN node 5 includes transceiver circuitry 51 operable to transmit signals to and receive signals from connected UEs 3 via one or more antennas 53, and to transmit signals to and receive signals from other network nodes (either directly or indirectly) via a network interface 55. The network interface 55 typically includes an appropriate base station-to-base station interface (e.g., X2 / Xn) and an appropriate base station-to-core network interface (e.g., NG-U / NG-C). A controller 57 controls the operation of the v(R)AN node 5 according to software stored in memory 59. The software may be pre-installed in memory 59 and / or downloaded, for example, via a telecommunications network or from a removable data storage device (RMD). The software includes, among other things, an operating system 61 and a communications control module 63. The communication control module 63 is responsible for handling (generating / sending / receiving) signaling between the v(R)AN node 5 and other nodes such as the UE 3 and core network nodes.

[0103] Core Network Node FIG. 10 is a block diagram illustrating the major virtual components of a typical core network node (or function) that may be used in the system illustrated in FIG. 7. As illustrated, the core network node includes transceiver circuitry 71 operable to transmit signals to and receive signals from other nodes (including UE 3 and v(R)AN node 5) via a network interface 75. A controller 77 controls the operation of the core network node in accordance with software stored in memory 79. The software may be pre-installed in memory 79 and / or downloaded, for example, via a telecommunications network or from a removable data storage device (RMD). The software includes, among other things, an operating system 81 and at least a communications control module 83. The communications control module 83 is responsible for handling (generating / sending / receiving) signaling between the core network node and other nodes, such as UE 3, v(R)AN node 5, and other core network nodes. Such signaling includes appropriately formatted requests and responses related to intelligent data collection and management for the open RAN intelligent controller.

[0104] Modifications and Alternatives Detailed embodiments have been described above. As those skilled in the art will appreciate, several modifications and alternatives may be made to the above embodiments while still benefiting from the invention embodied therein. By way of example, only some of these alternatives and modifications are now described.

[0105] In the above description, for ease of understanding, the UE, v(R)AN node, and core network node are described as having several individual modules (e.g., a communications control module). These modules may be provided in this manner in certain applications, for example, where an existing system has been modified to implement the above aspects, but in other applications, for example, in systems designed from the beginning with the features of the present invention, these modules may be incorporated into an overall operating system or code and therefore may not be identifiable as individual entities. These modules may also be implemented in software, hardware, firmware, or a mixture of these.

[0106] Each controller may comprise any suitable form of processing circuitry, including (but not limited to) for example, one or more hardware-implemented computer processors, microprocessors, central processing units (CPUs), arithmetic logic units (ALUs), input / output (IO) circuitry, internal memory / cache (program and / or data), processing registers, communication buses (e.g., control, data, and / or address buses), direct memory access (DMA) functions, hardware or software-implemented counters, pointers, and / or timers, etc.

[0107] In the above aspects, several software modules have been described. As those skilled in the art will appreciate, the software modules may be provided in compiled or uncompiled form and may be supplied to the UE, the (R)AN node, and the core network node as a signal, over a computer network, or on a recording medium. Furthermore, the functionality performed by some or all of this software may be implemented using one or more dedicated hardware circuits. However, the use of software modules is preferred because it facilitates updating the functionality of the UE, the (R)AN node, and the core network node.

[0108] The above aspects are also applicable to "non-mobile" or generally fixed user equipment.

[0109] Many modifications and other embodiments of the inventions described herein will come to mind to one skilled in the art to which these inventions pertain having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. It is to be understood, therefore, that the invention is not limited to the specific embodiments disclosed, and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only, and not for purposes of limitation. [Explanation of symbols]

[0110] 3 Mobile Devices, UE 5 v(R)AN nodes 8, 110 O-Cloud 10 SMO Framework, SMO 12 Non-RT RIC, Non-Real-Time RAN Intelligent Controller 14 Quasi-RT RIC, Quasi-RT-RIC, Quasi-Real-Time RAN Intelligent Controller 16 New interfaces, new or expanded A1-EI interfaces, interfaces 16a Termination Function, New Interface Termination Function, Interface Termination Function, Interface Terminal Function 16b Related Interface Termination Functions, New Interface Termination Functions, Interface Termination Functions, Interface Terminal Functions 18 rApp 20 xApp 22 DME 24 R1 interfaces 26, 30 Database 28 SDL (Storage Definition Language) based database management system, SDL based database management system, database management system, SDL, SDL database management system 31, 51, 71 Transceiver circuits 33, 53 antenna 35 User Interface 37, 57, 77 Controller 39, 59, 79 memory 41, 61, 81 Operating Systems 43, 63, 83 Communication control module 55, 75 network interface 112 Software Processing Device 114 HA 116 O-DU (O-RAN distributed node) network node, O-DU 118 Near-real-time (near-RT) RAN intelligent controller (RIC), Near-real-time RAN intelligent controller (near-RT RIC), Near-RT RIC 120 E2 interface 122 Service Management and Orchestration Framework (SMO), SMO 124 Non-Real-Time (Non-RT) RAN Intelligent Controller (RIC) 126 O2 interface

Claims

1. 1. A method of operating an open radio access network (O-RAN), the O-RAN comprising a non-real-time RAN intelligent controller (non-RT RIC) (12), a near-real-time RAN intelligent controller (near-RT RIC) (14), and at least one E2 node, the method comprising: providing a first interface (16) between the non-RT RIC (12) and the quasi-RT RIC (14); providing a second interface (120) between the quasi-RT RIC (14) and the at least one E2 node; receiving raw data from the at least one E2 node at the quasi-RT RIC (14) via the second interface (120); processing the raw data in the quasi-RT RIC (14) to generate analytical data including statistical and / or inferred data; transmitting the analysis data from the quasi-RT RIC (14) to the non-RT RIC (12) via the first interface (16); A method comprising:

2. executing a data registration procedure via the first interface (16), wherein an xApp (20) in the quasi-RT RIC (14) registers data generated and / or provided by the xApp (20) in the non-RT RIC (12); 10. The method of claim 1, further comprising:

3. 3. The method of claim 2, wherein the data registration procedure includes sending a data registration request by the xApp (20) to a function that registers and / or manages data in the non-RT RIC (12).

4. the data registration request includes one or more parameters specifying characteristics of the data to be registered; 4. The method of claim 3, wherein the one or more parameters include at least one of an indication of an ID of the xApp (20) requesting data registration, an ID of each of the quasi-RT RICs (14), an ID of an SDL (28) managing the data to be registered, a data source and / or method used to generate the data to be registered, an analytical data type of the data to be registered, an indication of state and / or configuration related to the generation of the data to be registered, and an output data function ID of the data to be registered.

5. performing a data discovery procedure via the first interface (16), wherein an rApp (18) in the non-RT RIC (12) discovers data generated and / or provided by an xApp (20) in the quasi-RT RIC (14); 10. The method of claim 1, further comprising:

6. the data discovery procedure includes a step of sending, by the rApp (18), a data discovery request related to the required analytical data to a function that registers and / or manages data in the non-RT RIC (12); 6. The method of claim 5, wherein the function for registering and / or managing data in the non-RT RIC (12) checks whether the required analytical data is registered upon receiving the data discovery request.

7. 7. The method of claim 6, wherein the function for registering and / or managing data provides alternative data sources and / or alternative analytical data if it finds that the analytical data to which the data discovery request relates is not registered.

8. performing a data subscription procedure via the first interface (16), wherein an rApp (18) in the non-RT RIC (12) subscribes to data generated and / or provided by an xApp (20) in the quasi-RT RIC (14); 10. The method of claim 1, further comprising:

9. the data subscription procedure includes a step of sending, by the rApp (18), a data subscription message relating to required analytical data to a function that registers and / or manages data in the non-RT RIC (12); the function for registering and / or managing data in the non-RT RIC (12) requests the required data from the quasi-RT RIC (14) via the first interface (16); 9. The method of claim 8, wherein the quasi-RT RIC (14) provides the requested data or responds with information on how to obtain the requested data via the first interface (16).

10. executing a data request procedure via the first interface (16), wherein an rApp (18) in the non-RT RIC (12) requests data generated and / or provided by an xApp (20) in the quasi-RT RIC (14); 10. The method of claim 1, further comprising:

11. the data request procedure includes a step of sending, by the rApp (18), a data request message relating to the required analytical data to a function that registers and / or manages data in the non-RT RIC (12); the function for registering and / or managing data in the non-RT RIC (12) requests the requested data from the quasi-RT RIC (14) via the first interface (16); 11. The method of claim 10, wherein the quasi-RT RIC (14) provides the requested data or responds with information on how to obtain the requested data via the first interface (16).

12. 12. An Open Radio Access Network (O-RAN) system for carrying out the method of any one of claims 1 to 11, said system comprising: a non-real-time RAN intelligent controller (non-RT RIC) (12); Near-real-time RAN intelligent controller (near-RT RIC) (14) and At least one E2 node; a first interface (16) between the non-RT RIC (12) and the quasi-RT RIC (14) configured to enable analytical data, including statistical data and / or inferred data, to be transmitted from the quasi-RT RIC (14) to the non-RT RIC (12); a second interface (120) between the quasi-RT RIC (14) and the at least one E2 node configured to enable raw data to be transmitted from the at least one E2 node to the quasi-RT RIC (14); The quasi-RT RIC (14) is configured to process the raw data received from the at least one E2 node via the second interface (120) and generate the analyzed data for transmission to the non-RT RIC (12) via the first interface (16).

13. 13. The system of claim 12, wherein the first interface (16) is a bidirectional extension of an O-RAN A1-EI interface implemented between the non-RT RIC (12) and the quasi-RT RIC (14).

14. the first interface (16) is implemented between the non-RT RIC (12) and the quasi-RT RIC (14) as an additional interface separate from an O-RAN A1-EI interface; 13. The system of claim 12, wherein the first interface (16) is configured to enable analysis data to be sent from the quasi-RT RIC (14) to the non-RT RIC (12).

15. the first interface (16) is configured to enable the exchange of messages between the non-RT RIC (12) and the quasi-RT RIC (14); The system of claim 12 , wherein the message relates to at least one of a data registration procedure, a data discovery procedure, a data subscription procedure, and a data request procedure.

16. the first interface (16) is configured to enable the exchange of messages between the non-RT RIC (12) and the quasi-RT RIC (14); said messages being enriched with one or more parameters specifying characteristics of the data handled by each said message; 13. The system of claim 12, wherein the one or more parameters include at least one of an ID of an xApp (20) requesting data registration, an ID of each of the quasi-RT RICs (14), an ID of an SDL (28) managing the data to be registered, an indication of a data source and / or method used to generate the data, an analysis data type of the data, an indication of state and / or configuration related to the generation of the data, and an output data function ID of the data.

Images