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 a non-exclusive but certain relevance to wireless communication systems and their devices operating according to 3rd Generation Partnership Project (3GPP (registered trademark)) standards or their equivalents or derivatives. The present disclosure has a non-exclusive but certain relevance to so-called "5G" (or "next-generation") systems that use intelligent data collection / management. More specifically, the present disclosure relates to methods of operating an Open Radio Access Network, an O-RAN, where the O-RAN includes a Non-Real-Time RAN Intelligent Controller, a Non-RT RIC, and a Near-Real-Time RAN Intelligent Controller, a Near-RT RIC.

Background Art

[0002] The following abbreviations and terms (unless otherwise specified) are used in this document. 3GPP 3rd Generation Partnership Project A1 Interface between the Non-RT RIC and the Near-RT RIC AI Artificial Intelligence DME Data management and exposure DMS Deployment Management Services E2 Interface between the Near-RT RIC and lower RAN functions (O-CU, O-DU, and O-RU) EI Enrichment Information KPI Key Performance Indicator ML Machine Learning Near-RT RIC O-RAN Near-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 Element OAM Operation, 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 Near-RT RIC Application

[0003] Furthermore, 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 abstracted from hardware, O-RAN creates a radio access network that does not rely on proprietary technologies.

[0005] As shown in FIG. 1, the new O-RAN architecture for next-generation mobile systems defines a computing platform known as O-Cloud110 to offload signal processing workloads from the virtualized BS. O-Cloud110 provides a signal processor composed of a software processing device 112 (e.g., a general-purpose CPU) and a HA114 such as an FPGA, GPU, or ASIC. Each processor queues FEC processing requests in a first-in-first-out (FIFO) queue, and when processed, the resulting TB data is returned to the associated BS.

[0006] Figure 1 shows a high-level diagram of the O-RAN architecture, where only the O-DU (O-RAN Distributed Unit) 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 that enables non-real-time control and optimization of RAN elements and resources.

[0007] In O-RAN, the BS (i.e., more specifically, the O-DU 116) is controlled by a near-real-time RAN Intelligent Controller (near-RT RIC) 118 using applications. These applications are known as xApps and operate on a time scale of about 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 strategy of the BS deployed on the prototype O-Cloud 110 platform. Common 3GPP Radio Resource Management (RRM) operations are executed, for example, through this interface. Conversely, the O2 interface 126 is used to provide two services, namely, an infrastructure management service (deployment and management of the O-Cloud 110 infrastructure) and a deployment management service (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], R1 interface [3], and A1 interface [4], and ORAN Working Group 3 is currently defining the quasi-RT RIC architecture [5] and E2 interface [6].

[0009] In the current ORAN design, applications within the non-RT RIC can only obtain raw data from the base station via the defined O1 interface. In the case of the latest ORAN design and specifications, the non-RT RIC can provide analysis information to the quasi-RT RIC in the form of enrichment information, but it cannot efficiently utilize the analysis data generated by the quasi-RT RIC, nor can it access and obtain the analysis data from the quasi-RT RIC in other directions [2][3]. This results in a waste of network resources in the mobile operator infrastructure because a large amount of raw data needs to be transported via the O1 interface, even though some relevant analysis data may be available within the quasi-RT RIC. This not only causes redundant data collection but also delays in data collection and processing, leading to multiple drawbacks in both network and application performance. In particular, some analysis data needs to be processed or trained by selected analysis tools or ML models, which then requires additional training time.

Prior Art Documents

Non-Patent Documents

[0010]

Non-Patent Document 1

Non-Patent Document 2

Non-Patent Document 3

Non-Patent Document 4

Non-Patent Document 5

Non-Patent Document 6

Non-Patent Document 7

Summary of the Invention

Problems to be Solved by the Invention

[0011] The objective of the present disclosure is to improve and further develop an open radio access network, O-RAN, and a method of operating such that available information can be used more efficiently and intelligently.

Means for Solving the Problem

[0012] According to the present invention, the above object is achieved by a method of operating an Open Radio Access Network, O-RAN, where the O-RAN includes a non-real-time RAN intelligent controller, non-RT RIC, and a quasi-real-time RAN intelligent controller, quasi-RT RIC, and the method includes 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 object is achieved by an Open Radio Access Network, O-RAN, system, where the O-RAN system includes 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 solve the above problems caused by the current inefficient data collection mechanism, the present disclosure proposes intelligent data collection via a Data Management and Exposure (DME) solution for providing data including analysis data generated by the quasi-RT RIC to the non-RT RIC. More specifically, embodiments of the present disclosure solve the following problems not addressed in ORAN. - How can the non-RT RIC find the required analysis data generated by the quasi-RT RIC? - How can the non-RT RIC access and obtain the required analysis data generated by the quasi-RT RIC? - What types of data information are relevant to the non-RT RIC? - What new parameters are needed to improve the efficiency of data collection? How can these new parameters be used? - How can a non-RT RIC efficiently use the analysis data generated by a quasi-RT RIC?

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

[0016] Currently, there is a one-way A1 interface that enables a quasi-RT RIC to obtain analysis data from a non-RT RIC. The purpose of the new interface according to the present disclosure is to enable the rApp within the non-RT RIC to obtain the analysis data provided by the xApp within the quasi-RT RIC. According to one embodiment, the new interface can be implemented as a bidirectional extension of the currently defined unidirectional A1-EI interface. According to an alternative or additional embodiment, the new interface can be implemented as a completely new interface - either unidirectional or bidirectional - to enable the quasi-RT RIC to provide analysis data to the 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 within a non-RT RIC (e.g., rApp) to discover and obtain the required analysis data from a near-RT RIC (provided by an xApp), or in some cases from a non-RT RIC (provided by an rApp).

[0018] In the context of this disclosure, the term "analysis data" should be understood broadly and can generally include all kinds of data that are created within a near-RT RIC and may be required by a non-RT RIC, and vice versa. For example, considering a massive MIMO (multiple input multiple output) use case, an xApp within a near-RT RIC can create analytical data for UE trajectory prediction, cell coverage prediction, cell load prediction, and traffic prediction based on the raw data collected. An rApp within a non-RT RIC, whose main functionality is to optimize the beamforming of massive MIMO, can utilize this analysis data from the xApp for beam management optimization instead of training its AI / ML model based only on the raw data. Therefore, the provision of analysis data according to the embodiments disclosed herein reduces duplicate data collection, reduces the load on O1, and improves the efficiency of AI / ML model training.

[0019] According to embodiments of the present disclosure, new parameters (i.e., data sources, Output Data Function IDs, and Methods Used) are defined to specify data sources, output data types, and methods used in order to improve the efficiency of data collection with respect to network resource savings and reduction of overall data collection time and training time. These new parameters can be used not only in procedures / messages from quasi-RT RIC to non-RT RIC, but also 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 RIC can provide analysis information to quasi-RT RIC in the form of enrichment information, but cannot collect analysis data from quasi-RT RIC. Embodiments of the present disclosure propose new interfaces and suites of data management-related procedures, namely, data registration procedures, data discovery procedures, data subscription procedures, and data request procedures, to enable applications within non-RT RIC to discover and obtain the required analysis data from quasi-RT RIC. In this way, the analysis data generated by applications within quasi-RT RIC can be used by applications within non-RT RIC, thus providing significantly greater data options and reducing the amount of data collected.

[0021] Currently, that is, in current O-RAN systems as described in References [2] to [6], the purpose of data collection is to obtain data existing in the database, and thus the data cannot be used intelligently. Embodiments of the present disclosure propose to enable applications to undertake data analysis based on data from different data sources and different methods, and thus use the data efficiently and intelligently, using several parameters such as Output Data Function IDs and Methods Used.

[0022] Note that there are a number of non-RT RIC use cases and applications that can also gain benefits from directly obtaining analysis data from quasi-RT RICs 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 over a time period. By aggregating and analyzing this information in the quasi-RT RIC, vrAIn saves a significant amount of bandwidth at 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 for sending analysis data from the quasi-RT RIC to the non-RT RIC. This interface can be used by an xApp to register the data it has created with the non-RT RIC, along with some data-related parameters. The interface can similarly be used by an rApp to discover the required data created by an xApp within the quasi-RT RIC, to subscribe to the required data created by an xApp within the quasi-RT RIC, along with some data-related parameters, and / or to request the required data created by an xApp within 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 executed. The data registration procedure enables an xApp in a quasi-RT RIC to register data provided to a non-RT RIC along with some data-related parameters in order to facilitate intelligent use of the data (xApp -> DME in the non-RT RIC). In this context, it may be defined that the xApp registers its generated data in the non-RT RIC via a new 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 executed. The data discovery procedure enables an rApp in a non-RT RIC to discover data provided in the non-RT RIC along with some data-related parameters in order to facilitate intelligent use of the data (rApp -> DME in the non-RT RIC). In this context, it may be defined that the rApp requests to discover the required data from the function of registering / managing data in the non-RT RIC. The function of registering / managing data in the non-RT RIC may respond using information related to the required data.

[0026] According to one embodiment of the present disclosure, a data subscription procedure may be executed. The data subscription procedure enables 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 in order to facilitate intelligent use of the data (rApp -> DME in the non-RT RIC). In this context, it may be defined that the rApp requests to subscribe to the required data from the function of registering / managing data in the non-RT RIC. The function of registering / managing 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 using information on how to collect the required data.

[0027] According to one embodiment of the present disclosure, a data request procedure can be executed. The data request procedure enables 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, in order to facilitate the intelligent use of data (rApp -> DME in the non-RT RIC). In this context, it can be stipulated that the rApp is required to request the required data from the function of registering / managing data in the non-RT RIC. The function of registering / managing data in the non-RT RIC can subscribe to the required data via the interface between the non-RT RIC and the quasi-RT RIC. The quasi-RT RIC can respond using information on how to collect the required data.

[0028] According to the above embodiment, the present disclosure provides two different ways to obtain analysis data from the quasi-RT RIC. One is data subscription, and the other is data request. In data subscription, the xApp provides the required data to the rApp 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, in data request, the xApp provides the required data to the rApp once, that is, in a one-time operation at the time of request. It will be understood that the rApp can utilize both options in parallel / simultaneously.

[0029] There are several ways to design and further develop the teachings of the present invention in an advantageous manner. For this purpose, on the one hand, reference is made to the dependent claims, and on the other hand, by way of example, reference is made to the following description of the preferred embodiments of the present invention shown in the figures. In connection with the description of the preferred embodiments of the present invention with the aid of the figures, generally preferred embodiments and further developments of the teachings are described. In the drawings, it is as follows.

Brief Description of the Drawings

[0030]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

DETAILED DESCRIPTION OF THE INVENTION

[0031] Currently, in the ORAN design, the non-RT RIC can provide analysis information to the near-RT RIC in the form of enrichment information, but it cannot collect analysis data from the near-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 near-RT RIC 14. As shown in the exemplary architecture shown in FIG. 2, the new interface 16 can be configured to send analysis data from the near-RT RIC 14 to the non-RT RIC 12. Specifically, it can be defined that the new interface 16 enables the rApp 18 within the non-RT RIC 12 to obtain the analysis data provided by the xApp 20 within the near-RT RIC 14. As shown in FIG. 2, the new interface 16 can be implemented by extending the currently defined unidirectional A1-EI interface bidirectionally, or can be designated as a completely new interface to enable the near-RT RIC 14 to provide analysis data to the non-RT RIC 12. This design provides significant implementation flexibility.

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

[0033] According to another aspect of the present disclosure, a data registration procedure can be implemented. The data registration procedure enables the xApp 20 within the near-RT RIC 14 to register the data to be provided to the non-RT RIC 12 with new parameters to facilitate the 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 to be created. According to one embodiment, the xApp 20 can register the data to be provided with the DME 22 within the non-RT RIC 12.

[0034] Figure 3 is a diagram showing a data registration procedure according to an embodiment of the present disclosure. This procedure focuses on the interaction between the xApp20 within the quasi-RT RIC14 and the function for registering / managing data within the non-RT RIC12. The function that will register / manage the data within the non-RT RIC12 can be the DME22 or other entities with different names that serve the same and similar purposes.

[0035] As shown in Figure 3, the following steps may be executed for the xApp20 within the quasi-RT RIC14 to register the data it provides with the non-RT RIC12.

[0036] As shown in step S310, in order to register the generated data, the xApp20 may call a data registration request procedure or any other relevant procedure, or send a "data registration request" message or any other relevant message to the non-RT RIC12 via the termination function 16a of the new interface 16 in order to register the generated data. The new interface termination function 16a within the quasi-RT-RIC14 can be an A1-related function that supports bidirectional A1-EI to provide analysis data in both directions.

[0037] The message sent from the xApp20 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), - Quasi-RT RIC ID (i.e., the ID of the quasi-RT RIC14 related to the xApp20 that provides the data), - Analysis data type of the data generated by the xApp20, - Analysis data reporting information for indicating the status and / or configuration related to collecting the analysis data, such as the data generation interval, - 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 may list the original data source. This will help the data consumer better understand the output data. - Output data function ID. Examples of output data functions include, but are not limited to, raw data, statistical data, inferred data, etc., and / or - Method used. Specifying what method is used will help the data consumer better understand how the output data is generated, for example, based on what source data. Examples of methods used include, but are not limited to, conventional methods such as linear regression, AI / ML methods such as deep learning algorithms, combinations of the above, etc.

[0038] As will be understood by those skilled in the art, different names may be used for the above parameters for the same and similar purposes. Further, note that the above parameters may be used in the same or similar form 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 above parameter "analysis data type", note that this parameter generally specifies the type of analysis data (e.g., generated by an xApp), such as UE trajectory prediction, cell coverage prediction, and cell load prediction. Since the parameter specifies the data type of the analysis data, it cannot be applied to raw data.

[0040] Regarding the above parameter "output data function", it should be noted that this parameter generally specifies whether the generated data is raw data, statistical data, or inferred data. Raw data is not analysis data. Statistical data can be analysis data without prediction. Inferred data is analysis data with prediction. Each output data function can be assigned an identifier for creating 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] In the next step shown at S320 in FIG. 3, the new interface termination function 16a within the quasi-RT RIC 14 can call a data registration request procedure or any other related procedure, or send a "data registration request" message or any other related message to the related interface termination function 16b on the new interface 16 between the quasi-RT RIC 14 and the non-RT RIC 12. As will be understood by those skilled in the art, different names may be used for the above messages to achieve the same and similar purposes.

[0042] As shown in step S330, the new interface termination function 16b within the non-RT RIC 12 can transfer a data registration request procedure or any other related procedure to the function for registering / managing data within the non-RT RIC 12, or send a "data registration request" message or any other related message, and this function can be the DME 22 (as shown in FIG. 3) or any other entity with a different name that serves the same and similar purposes.

[0043] The function for registering / managing data within the non-RT RIC 12, i.e., the DME 22 in the exemplary embodiment of FIG. 3, executes the 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 of registering / managing data within the non-RT RIC12, i.e., in the illustrated embodiment, DME22, responds using a "Data Registration Response" message or any other relevant message, and this message is transferred to each xApp20 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 FIG. 3 can be used by the rApp18 to register that data within the function of registering / managing data within the non-RT RIC12 on the R1 interface 24. The function of registering / managing data within the non-RT RIC can be DME22 as shown in FIG. 3, or any other entity with a different name that serves the same and similar purposes.

[0046] Each message for data registration sent from the rApp18 to the DME22 may include one or more of the following parameters. - rApp ID (i.e., the ID of the rApp18 itself), - The analysis data type of the data generated by the rApp18, - Analysis data reporting information to indicate the status and / or configuration related to reporting the analysis data, such as the interval of data generation, - The data source used. This parameter indicates what the data source is that the rApp18 is using to generate the analysis data. If the registered output data from the rApp18 is statistical data or inferred data, this parameter will list the original data sources. This will help the data consumer better understand the output data. - 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 can help the data consumer 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. The data discovery procedure enables the rApp18 in the non-RT RIC12 to discover the data provided by the non-RT RIC12 together with new parameters to facilitate the intelligent use of the data. The main idea of the data discovery procedure is that the rApp18 sends a data discovery request to the function in the non-RT RIC12 that registers / manages the data in the non-RT RIC12 to discover the requested data. According to one embodiment, the rApp18 may discover the requested data from the DME22 in the non-RT RIC12.

[0049] FIG. 4 is a diagram showing a data discovery procedure according to an embodiment of the present disclosure. This procedure focuses on the interaction between the rApp18 in the non-RT RIC12 and the function that registers / manages the data in the non-RT RIC12. The function that registers / manages the data in the non-RT RIC may be the DME22, or other entities with different names that serve the same and similar purposes.

[0050] As shown in FIG. 4, the following steps may be performed for the rApp18 in the non-RT RIC12 to discover any data it needs.

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

[0052] The message sent from rApp18 to DME22 in step S410 may include one or more of the following parameters. - rApp ID (i.e., the ID of rApp18 itself), - The analysis data type of the data required by rApp18, - Analysis data reporting information to indicate the state and / or configuration related to reporting the analysis data, - The data source used. This parameter indicates what the data source is that xApp20 uses to generate the analysis data. If the registered output data from xApp20 is statistical data or inferred data, this parameter will list the original data source. This will help the data consumer better understand the output data. - The time interval required 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., and / or - The method used. Specifying what method is used will help the data consumer better understand how the output data was obtained. Examples of methods used include, but are not limited to, conventional methods such as linear regression, AI / ML methods such as deep learning algorithms, combinations of the above, etc.

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

[0054] In the next step shown at S420 in FIG. 4, the function of registering / managing data within the non-RT RIC 12, i.e., in the case shown DME22, checks the registered data and finds the required data (on the condition that the required data is registered). In addition, the function of registering / managing data within the non-RT RIC 12 can also provide an alternative data source to the rApp 18, for example, based on the built-in intelligent data analysis function of the function itself. For example, the function (i.e., DME22 in the case shown) can provide alternative analysis data if there is no exact match of the required data, or can provide analysis data if the required data is only raw data.

[0055] While serving the same and similar purposes, different names may be used for the above messages.

[0056] As shown in step S430, the function of registering / managing data within the non-RT RIC 12 (i.e., DME22 in the case shown) responds using a "data discovery response" message or any other related message. The response message from DME22 to the rApp 18 may include one or more of the following parameters. - rApp ID (i.e., the ID of the rApp 18 itself), - The ID of the xApp 20 and / or rApp 18 that can create and / or provide the required data, - The application ID of the application that can provide the required analysis data type, - Analysis data reporting information for indicating the status and / or configuration related to reporting the analysis data, - The data source used. This parameter indicates what data source the xApp20 or rApp18 is using to generate the analysis data. If the registered output data from the xApp20 or rApp18 is statistical data or inferred data, this parameter will list the original data source. This will help the data consumer 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., and / or - The method used. Specifying what method is used will help the data consumer better understand how the output data was obtained. Examples of methods used include, but are not limited to, conventional methods such as linear regression, AI / ML methods such as deep learning algorithms, combinations of the above, etc.

[0057] For the same and similar purposes, different names may be used for the above parameters.

[0058] Obtaining information, together with one or more of the above parameters, particularly the data source, output data function ID, and the method used, helps the rApp18 to improve 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.

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

[0060] FIG. 5 is a diagram showing a data subscription procedure according to an 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 creates the required analysis data.

[0061] As shown in FIG. 5, the following steps may be executed for the rApp 18 in the non-RT RIC 12 to subscribe to the required data.

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

[0063] To subscribe to the use of the required data, the rApp 18 may execute a data subscription request procedure or any other related procedure, or send a "data subscription request" message or any other related message to the DME 22 as shown in step S520. This message sent from the rApp 18 to the DME 22 may include one or more of the following parameters. - rApp ID (i.e., the ID of rApp18 itself), - the ID of xApp20 that can create and / or provide the required data, - the required analysis data type, - analysis data reporting information for indicating the state and / or configuration related to reporting the analysis data, - the data source used. This parameter indicates what the data source is that xApp20 uses to generate the analysis data. If the registered output data from xApp20 is statistical data or inferred data, this parameter will list the original data source. This will help the data consumer better understand the output data, - the time interval required to collect the data, - the 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 better understand how the output data is obtained. Examples of the methods used include, but are not limited to, conventional methods such as linear regression, AI / ML methods such as deep learning algorithms, combinations of the above, etc.

[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, DME 22 transfers a "data subscription request" message or any other relevant message to the function that manages the data within the quasi-RT RIC 14 in order to process a data subscription request procedure or any other relevant procedure, or to collect the required data. According to the disclosed embodiment, each message is relayed via interface terminal functions 16b, 16a on the new interface 16 described in detail above.

[0066] The function that manages the data within the quasi-RT RIC 14 can be an SDL-based database management system 28, or any other entity that provides the same or a similar function.

[0067] The "data subscription request" message sent from 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 DME 22 to the SDL-based database management system 28 may include exactly the same parameters (see step S520) as the message sent from rApp 18 to DME 22.

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

[0069] In steps S540, S542, and S544, the function that manages the data within the quasi-RT RIC 14 responds using a "data subscription response" message or any other relevant message. This message sent from the SDL-based database management system 28 to DME 22 may include one or more of the following parameters. - rApp ID (i.e., the ID of rApp18 itself), - The xApp ID of xApp20 that can create and / or provide the required data, - The required analysis data type, - Analysis data reporting information for indicating the status and / or configuration related to reporting the analysis data, - The 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 will list the original data source. This will help the data consumer better understand the output data, - The time interval used to collect the required data, - Output data function ID. Examples of output data functions include, but are not limited to, raw data, statistical data, inferred data, etc., - The method used. Specifying what method is used will help the data consumer better understand how the output data was obtained. Examples of methods used include, but are not limited to, conventional methods such as linear regression, AI / ML methods such as deep learning algorithms, combinations of the above, etc., - The location of the data, and / or - The method of data delivery.

[0070] As shown in step S550, DME22 responds to rApp18 using a "data subscription response" message or any other relevant message.

[0071] Obtaining information about the above parameters, especially 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 thus to use data efficiently and intelligently.

[0072] Similar data subscription procedures as described above can be used by rApp18 to subscribe to data created / provided in the function of registering / managing data within non-RT RIC12 on R1 interface 24. The function of registering / managing data within non-RT RIC12 can be DME22, or any entity with another name that serves the same and similar purposes. Each message sent from rApp18 to DME22 can include one or more of the following parameters. - rApp ID (i.e., the ID of rApp18 itself), - The rApp ID of rApp18 that can create and / or provide the required data, - The analysis data type of the data generated by rApp18, - Analysis data reporting information for indicating the status and / or configuration related to reporting analysis data, such as the interval of data generation, - The data source used. This parameter indicates what source rApp18 is using to generate the analysis data. If the registered output data from rApp18 is statistical data or inferred data, this parameter will list the original data sources. This will help data consumers better understand the output data. - The time interval required to collect the data, - Output data function ID, - The method used. This will help data consumers better understand how the output data was obtained.

[0073] While serving the same and similar purposes, different names may be used for the above parameters.

[0074] According to another aspect of the present disclosure, a data request procedure may be implemented. The data request procedure enables the rApp 18 in the non-RT RIC 12 to obtain the required data provided by the xApp 20 in the quasi-RT RIC 14 together with new parameters in order to facilitate the intelligent use of data (rApp -> DME in the non-RT RIC). The main idea of the data request procedure is to enable the rApp 18 to request the one-time required analysis data from the application that creates the requested data. According to one embodiment, the rApp 18 may request the required data from the DME 22 in the non-RT RIC 12.

[0075] FIG. 6 is a diagram showing a data request procedure for the rApp 18 in the non-RT RIC 12 to obtain the required data according to an 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 creates the required analysis data.

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

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

[0078] To request the required data, rApp18 may call a request data request procedure or any other related procedure, or send a "request data request" message or any other related message as shown in step S620 to DME22 to collect the required data. This message from rApp18 to xApp20 may include one or more of the following parameters. - rApp ID (i.e., the ID of rApp18 itself), - The ID of xApp20 that can generate and / or provide the required data, - The required analysis data type, - Analysis data reporting information to indicate the state and / or configuration related to reporting the analysis data, - The data source used. This parameter indicates what source xApp20 is using to generate the analysis data. If the registered output data from xApp20 is statistical data or inferred data, this parameter will list the original data source, which will help the data consumer better understand the output data. - The time interval required 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., and / or - The method used. Specifying what method is used will help the data consumer better understand how the output data was obtained. Examples of methods used include, but are not limited to, conventional methods such as linear regression, AI / ML methods such as deep learning algorithms, combinations of the above, etc.

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

[0080] Next, as shown in step S630, DME22 (or any other function that registers / manages data within non-RT RIC12) checks whether the required data is stored in the database 30 within non-RT RIC12.

[0081] If the data is stored in the database 30 within non-RT RIC12, the procedure proceeds to step S640, i.e., DME22 fetches the required data from the database 30 within non-RT RIC12.

[0082] On the other hand, if the data is not stored in the database 30 within non-RT RIC12, the procedure proceeds to steps S650, S652, and S654. Thus, DME22 either 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 that manages data within quasi-RT RIC14 to collect the required data. Specifically, as shown in steps S650, S652, and S654, the message is transferred via interface terminal functions 16b, 16a on the new interface 16 (see Figure 2). The function that manages data within quasi-RT RIC14 can be an SDL-based database management system 28 (as shown in Figure 6), or any other entity that provides the same or a similar function.

[0083] The message sent from DME22 to SDL28 can include one or more of the following parameters. - rApp ID (i.e., the ID of rApp18 itself), - The ID of xApp20 that can generate and / or provide the required data, - The required analysis data type, - Analysis data reporting information for indicating the state and / or configuration related to reporting the analysis data, - The data source used. This parameter indicates what source the xApp20 is using to generate the analysis data. If the registered output data from the xApp20 is statistical data or inferred data, this parameter will list the original data source, which will help the data consumer better understand the output data. - The time interval required 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., and / or - The method used. Specifying what method is used will help the data consumer better understand how the output data was obtained. Examples of methods used include, but are not limited to, conventional methods such as linear regression, AI / ML methods such as deep learning algorithms, combinations of the above, etc.

[0084] For the same and similar purposes, different names may be used for the above parameters.

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

[0086] Next, as shown in step S670, the SDL database management system 28 (or any other function that manages data within the quasi-RT RIC 14) responds using a "request data response" message or any other relevant message. This message is transferred to the DME 22 (or any other function that manages data within the non-RT RIC 12) via the interface termination 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. - rApp ID (i.e., the ID of the rApp 18 itself), - The ID of the xApp 20 that can generate and / or provide the required data, - The required analysis data type, - Analysis data reporting information for indicating the state and / or configuration related to reporting the analysis data, - The data source used. This parameter indicates what source the xApp 20 is using to generate the analysis data. If the registered output data from the xApp 20 is statistical data or inferred data, this parameter will list the original data source, which will help the data consumer 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. - The method used. Specifying what method is used will help the data consumer better understand how the output data was obtained. Examples of methods used include, but are not limited to, conventional methods such as linear regression, AI / ML methods such as deep learning algorithms, combinations of the above, etc. - The location of the data, and / or - The method used for data delivery.

[0087] As shown in step S680, DME22 responds to rApp18 using a "request data response" message or any other relevant message.

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

[0089] A similar data request procedure as described above in connection with FIG. 6 can be used by rApp18 to request that data in an end function that registers / manages data within non-RT RIC12 on R1 interface 24. The function that registers / manages data within non-RT RIC can be DME22 as shown in FIG. 6, or any other entity with a different name that serves the same and similar purposes.

[0090] Each message for a data request sent from rApp18 to DME22 can include one or more of the following parameters. - rApp ID (i.e., the ID of rApp18 itself), - The ID of rApp18 that can generate and / or provide the required data, - The analysis data type generated by rApp18, - Analysis data reporting information for indicating states and / or configurations related to reporting analysis data, such as the interval of data generation, - The data source used. This parameter indicates what source rApp18 used or is using to generate the analysis 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 better understand the output data. - Output data function ID, and / or - The method used. This parameter will help the data consumer better understand how the output data was obtained.

[0091] For the same and similar purposes, different names may be used for the above parameters.

[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 to the quasi-RT RIC14 by the non-RT RIC12 via the 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 xApp20 can improve data analysis from different data sources and based on different methods, and thus can use data efficiently and intelligently.

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

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

[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 main responsibilities of the SMO 10 include O-RAN network function fault, configuration, accounting, performance, and security (FCAPS) interfaces, large time-scale 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 updating, and policy-based guidance of applications / features within the near-RT RIC 14. The non-RT RIC 12 also provides an A1 interface to the near-RT RIC 14. Its main objective is to support large time-scale RAN optimization (seconds or minutes), including policy calculation, ML model management, and other radio resource management functions within this time scale. The data management tasks required by the non-RT RIC 12 should be converted to O1 / O2 interfaces, and context / enrichment information can be provided to the near-RT RIC 14 via the A1 interface.

[0097] The near-RT RIC 14 is a logical function that enables near-real-time optimization and control of O-CU and O-DU nodes and resources, as well as data monitoring, at a near-RT time scale (between 10 ms and 1 s), via fine-grained data collection and actions on the E2 interface. The near-RT RIC 14 control is steered by policies and assisted by models calculated / trained by the non-RT RIC 12. The near-RT RIC 14 also supports xApps 20 (independent software plugins to the near-RT RIC 14 platform to provide functionality expansion to the RAN by third parties).

[0098] This architecture essentially provides three independent control loops. · Non-RT RIC 12 control loop: Operates at a large time scale of seconds or minutes. The objective is to perform O-RAN specific orchestration decisions such as policy configuration or ML model training. · Near-RT RIC 14 control loop: Operates at a time scale of less than 1 second. The objective is to perform tasks such as policy enforcement or radio resource management operations. · O-DU Scheduler Control Loop: A real-time operation that performs legacy radio operations such as HARQ, beamforming, or scheduling.

[0099] The control loops are understood to be independent, yet it is understood that they can still interact with each other.

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

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

[0102] Virtual RAN (v(R)AN) node FIG. 9 is a block diagram showing the main virtual components of an exemplary v(R)AN node 5 (base station) that can be used within the system shown in FIG. 7. As shown, the v(R)AN node 5 is operable to transmit signals to the connected UE3 and receive signals from the connected UE3 via one or more antennas 53, and to transmit signals to other network nodes (either directly or indirectly) and receive signals from other network nodes via a network interface 55. The network interface 55 typically includes an appropriate base station-base station interface (such as X2 / Xn) and an appropriate base station-core network interface (such as NG-U / NG-C). The controller 57 controls the operation of the v(R)AN node 5 according to software stored in the memory 59. The software can be pre-installed in the memory 59 and / or downloaded, for example, via a telecommunications network or from a removable data storage device (RMD). The software particularly includes an operating system 61 and a communication 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 UE3 and core network nodes.

[0103] Core network node FIG. 10 is a block diagram showing the main virtual components of a general core network node (or function) that can be used within the system shown in FIG. 7. As shown, the core network node includes a transceiver circuit 71 operable to transmit signals to and receive signals from other nodes (including UE3 and v(R)AN node 5) via a network interface 75. A controller 77 controls the operation of the core network node according to software stored in a memory 79. The software can be pre-installed in the memory 79 and / or downloaded, for example, via a telecommunications network or from a removable data storage device (RMD). The software includes, in particular, an operating system 81 and at least a communication control module 83. The communication control module 83 is responsible for handling (generating / sending / receiving) signaling between the core network node and other nodes such as UE3, 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 an open RAN intelligent controller.

[0104] Variations and alternatives Detailed aspects have been described above. As will be appreciated by those skilled in the art, several variations and alternatives can be made to the above aspects while still obtaining the benefits of the invention embodied therein. Only some of these alternatives and variations are described below as examples.

[0105] In the above description, the UE, v(R)AN node, and core network node have been described in an easy-to-understand manner as having several individual modules (such as a communication control module). These modules can be provided in this way in a specific application, for example, where an existing system is modified to implement the above aspect. However, in other applications, for example, in a system designed from the beginning with the features of the present invention in mind, these modules may be incorporated into the overall operating system or code. Therefore, these modules may not be distinguishable as individual entities. These modules can also be implemented in software, hardware, firmware, or a combination thereof.

[0106] Each controller may comprise a processing circuit in any suitable form, including, but not limited to, for example, a computer processor, a microprocessor, a central processing unit (CPU), an arithmetic logic unit (ALU), input / output (IO) circuitry, internal memory / cache (program and / or data), processing registers, a communication bus (such as a control, data, and / or address bus), a direct memory access (DMA) function, a counter, a pointer, and / or a timer implemented by hardware or software.

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

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

[0109] Numerous modifications and other embodiments of the invention described herein will come to the mind of those skilled in the art having the benefit of the teachings presented in the above description and the related drawings. Accordingly, it is to be understood that the invention is not to be 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.

Description of Reference Numerals

[0110] 3 Mobile device, UE 5 v(R)AN node 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 interface, New or Extended A1-EI Interface, Interface 16a Terminal function, New interface terminal function, Interface terminal function, Interface terminal function 16b Related interface terminal function, New interface terminal function, Interface terminal function, Interface terminal function 18 rApp 20 xApp 22 DME 24 R1 interface 26, 30 Database 28 SDL (Specification and Description 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 Antennas 35 User interface 37, 57, 77 Controllers 39, 59, 79 Memories 41, 61, 81 Operating systems 43, 63, 83 Communication control modules 55, 75 Network interfaces 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. A method for operating an Open Radio Access Network, O-RAN, wherein the O-RAN comprises a non-real-time RAN intelligent controller, a non-RT RIC (12), and a quasi-real-time RAN intelligent controller, a quasi-RT RIC (14), and the method comprises: providing an interface (16) between the non-RT RIC (12) and the quasi-RT RIC (14); sending analysis data from the quasi-RT RIC (14) to the non-RT RIC (12) using the interface (16). A method comprising the above.

2. Executing a data registration procedure via the 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). The method according to claim 1, further comprising the above.

3. The method according to claim 2, wherein the data registration procedure comprises the step of sending a data registration request from the xApp (20) to a function for registering and / or managing data in the non-RT RIC (12).

4. The data registration request comprises one or more parameters specifying characteristics of the data to be registered, wherein the one or more parameters comprise at least one of an indication of the ID of the xApp (20) requesting data registration, the ID of each quasi-RT RIC (14), the 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 analysis data type of the data to be registered, an indication of a 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. The method according to claim 3.

5. Executing a data discovery procedure via the interface (16), wherein an rApp (18) in the non-RT RIC (12) discovers data generated and / or provided by an xApp (20) in the non-RT RIC (12). The method according to any one of claims 1 to 4, further comprising the above.

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

7. The method according to claim 6, wherein when the function of registering and / or managing data finds that the analysis data related to the data discovery request is not registered, it provides an alternative data source and / or alternative analysis data.

8. A step of executing a data subscription procedure via the interface (16), wherein the rApp (18) in the non-RT RIC (12) subscribes to data generated and / or provided by the xApp (20) in the quasi-RT RIC (14). The method according to any one of claims 1 to 7, further comprising this step.

9. The data subscription procedure includes a step of sending, by the rApp (18), a data subscription message related to the analysis data required for the function of registering and / or managing data in the non-RT RIC (12). The function of registering and / or managing data in the non-RT RIC (12) requests the required data from the quasi-RT RIC (14) via the interface (16). The method according to claim 8, wherein the quasi-RT RIC (14) provides the required data via the interface (16) or responds using information on how to obtain the required data.

10. A step of executing a data request procedure via the interface (16), wherein the rApp (18) in the non-RT RIC (12) requests data generated and / or provided by the xApp (20) in the quasi-RT RIC (14). The method according to any one of claims 1 to 9, further comprising this step.

11. The data request procedure includes a step of sending, by the rApp (18), a data request message related to analysis data required for a function of registering and / or managing data in the non-RT RIC (12). The function of registering and / or managing data in the non-RT RIC (12) requests the required data from the quasi-RT RIC (14) via the interface (16). The method according to claim 10, wherein the quasi-RT RIC (14) provides the required data via the interface (16) or responds using information on how to obtain the required data.

12. An open radio access network, O-RAN, system for executing the method according to any one of claims 1 to 11, wherein the O-RAN system includes a non-real-time RAN intelligent controller, non-RT RIC (12), a quasi-real-time RAN intelligent controller, quasi-RT RIC (14), an interface (16) between the non-RT RIC (12) and the quasi-RT RIC (14), the interface (16) being configured to enable sending analysis data from the quasi-RT RIC (14) to the non-RT RIC (12), and an open radio access network, O-RAN, system comprising the same.

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

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

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

16. The interface (16) is configured to enable the exchange of messages between the non-RT RIC (12) and the quasi-RT RIC (14), The message is enriched by one or more parameters that specify the characteristics of the data handled by each of the messages, The system according to any one of claims 12 to 15, wherein the one or more parameters include at least one of an ID of an xApp (20) that requests data registration, an ID of each of the quasi-RT RICs (14), an ID of an SDL (28) that manages 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 a state and / or configuration related to the generation of the data, and an output data function ID of the data.

Images