WO2025136453A1

WO2025136453A1 - O-ran ric xapp/rapp conflict resolution

Info

Publication number: WO2025136453A1
Application number: PCT/US2024/035708
Authority: WO
Inventors: Siddhartha TRIVEDI
Original assignee: Rakuten Mobile Inc; Rakuten Symphony Usa LLC
Current assignee: Rakuten Mobile Inc; Rakuten Symphony Usa LLC
Priority date: 2023-12-21
Filing date: 2024-06-27
Publication date: 2025-06-26
Anticipated expiration: 2026-06-21

Abstract

According to example embodiments, a system may include a Non-RT RIC and a Near-RT RIC. The Non-RT RIC includes an rApp and a first conflict management (CM) entity, while the Near-RT RIC includes an xApp and a second CM entity. The first CM may be configured to communicate with the second CM entity to provide information of the rApp thereto and to obtain information of the xApp therefrom. Similarly, the second CM entity may be configured to communicate with the first CM entity to provide the information of the xApp thereto and to obtain information of the rApp therefrom. The rApp and the xApp may be configured to obtain the information of the xApp and information of the rApp, respectively, from the associated CM entity, and then initiate an associated operation thereafter.

Description

O-RAN RIC XAPP/RAPP CONFLICT RESOLUTION

CROSS REFERENCE TO RELATED APPLICATION

[0001] This application claims priority from U.S. Provisional Patent Application No. 63/613,344 filed with the U.S. Patent and Trademark Office on December 21, 2023, the entire contents of which are incorporated herein by reference.

TECHNICAL FIELD

[0002] The present disclosure relates to resolution of conflict between xApps and/or rApps of the radio access network (RAN) intelligent controllers (RICs) in an open radio access network (O-RAN).

BACKGROUND

[0003] The information disclosed in this background section is only for the enhancement of understanding of the general background of the disclosure and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person skilled in the art.

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

[0005] Open RAN (O-RAN) technology has emerged to enable multiple vendors to provide hardware and/or software to a telecommunications system. Since different vendors are involved, the type of hardware and/or software provided may also be different. That is, different types of NEs may be provided by different vendors, and depending on the specific service, the NE could be virtualized and/or containerized in software form (e.g., virtual machine (VM)-based, containerized network function (CNF)-based, etc.), or could be in physical hardware form (e.g., non-VM-based, non-CNF -based, etc.) Accordingly, O-RAN disaggregates the RAN functions into different entities, such as a central unit (CU), a distributed unit (DU), and a radio unit (RU). Since these entities have open protocols and interfaces between them, they can be developed by different vendors.

[0006] In O-RAN architecture, the RAN operations or functions may be controlled and optimized by a RAN Intelligent Controller (RIC). The RIC may be a software-defined component that implements modular applications to facilitate the multivendor operability required in the O- RAN system, as well as to automate and optimize RAN operations. In general, the RIC may be divided into two types: a non-real-time RIC (Non-RT RIC) and a near-real-time RIC (Near-RT RIC). The Non-RT RIC and the Near-RT RIC may each implement one or more applications to perform one or more desired operations. The application(s) implemented in the Non-RT RIC is called rApp(s), and the application(s) implemented in the Near-RT RIC is called xApp(s). The rApp(s) and xApp(s) may be developed by independent parties or vendors and then deployed on the Non-RT RIC and the Near-RT RIC.

SUMMARY

[0007] Example embodiments of the present disclosure provide systems, apparatuses, methods, and the like, that effectively and efficiently provide resolution of conflicts between an xApp and an rApp of the O-RAN RICs.

[0008] According to example embodiments, a system includes: a non-real-time (Non-RT) radio access network intelligent controller (RIC) and a near-real-time (Near-RT) RIC; wherein the Non-RT RIC may include at least one application (rApp) and a first conflict management (CM) entity; wherein the Near-RT RIC may include at least one application (xApp) and a second CM entity; wherein the first CM entity may be configured to collect information of the rApp, and the first CM entity may be configured to communicate with the second CM entity to provide information of the rApp thereto and to obtain information of the xApp therefrom; wherein the second CM entity may be configured to collect information of the xApp, and the second CM entity may be configure to communicate with the first CM entity to provide the information of the xApp thereto and to obtain information of the rApp therefrom; wherein the rApp may be configured to obtain the information of the xApp from the first CM entity and to initiate a first operation thereafter; and wherein the xApp may be configured to obtain the information of the rApp from the second CM entity and to initiate a second operation thereafter.

[0009] According to example embodiments, a method includes: collecting, by a first conflict management (CM) entity associated with a non-real-time (Non-RT) radio access network intelligent controller (RIC), information of at least one application (rApp) associated with the Non-RT RIC; providing, by the first CM entity, information of the rApp to a second CM entity associated with a near-real-time (Near-RT) RIC; collecting, by the second CM entity, information of at least one application (xApp) associated with the Near-RT RIC; providing, by the second CM entity, information of the xApp to the first CM entity; obtaining, by the rApp from the first CM entity, information of the xApp; initiating, by the rApp, a first operation after receiving the information of the xApp; obtaining, by the xApp from the second CM entity, information of the rApp; and initiating, by the xApp, a second operation after receiving the information of the rApp. [0010] According to embodiments, a non-transitory computer-readable recording medium may have recorded thereon instructions executable by a device to cause the device to perform a method comprising: collecting, by a first conflict management (CM) entity associated with a non- real-time (Non-RT) radio access network intelligent controller (RIC), information of at least one application (rApp) associated with the Non-RT RIC; providing, by the first CM entity, information of the rApp to a second CM entity associated with a near-real-time (Near-RT) RIC; collecting, by the second CM entity, information of at least one application (xApp) associated with the Near-RT RIC; providing, by the second CM entity, information of the xApp to the first CM entity; obtaining, by the rApp from the first CM entity, information of the xApp; initiating, by the rApp, a first operation after receiving the information of the xApp; obtaining, by the xApp from the second CM entity, information of the rApp; and initiating, by the xApp, a second operation after receiving the information of the rApp.

[0011] Additional aspects will be set forth in part in the description that follows and, in part, will be apparent from the description, or may be realized by practice of the presented embodiments of the disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Features, aspects, and advantages of embodiments of the disclosure will be described below with reference to the accompanying drawings, in which like reference numerals denote like elements, and wherein:

[0013] FIG. 1 illustrates an 0-RAN architecture in which one or more example embodiments may be applied;

[0014] FIG. 2 illustrates a block diagram of an example configuration of the interaction between the rApp, xApp, and the respective CM entity, according to one or more example embodiments; [0015] FIG. 3 illustrates an example of a priority table, according to one or more example embodiments;

[0016] FIG. 4 illustrates a flow diagram of an example method for initiating an operation, according to one or more example embodiments; and

[0017] FIG. 5 illustrates an example embodiment of a device for implementing one or more example embodiments.

DETAILED DESCRIPTION

[0018] The following detailed description of example embodiments refers to the accompanying drawings. The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise forms disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations. Further, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). Additionally, the flowchart and description of operations provided below relate to one of the various embodiments. It should be noted that it is possible to make other embodiments that do not exactly match the flowchart and its description. It is understood that in other embodiments one or more operations may be omitted, one or more operations may be added, one or more operations may be performed simultaneously (at least in part).

[0019] It will be apparent that systems and/or methods, described herein, may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and/or methods is not limited to the described implementations. Thus, the operation and behavior of the systems and/or methods are described herein without reference to specific software code. It is understood that software and hardware may be designed to implement the systems and/or methods based on the description herein.

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

[0021] No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles “a” and “an” are intended to include one or more items, and may be used interchangeably with “one or more.” Also, as used herein, the terms “has,” “have,” “having,” “include,” “including,” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise. Furthermore, expressions such as “at least one of [A] and [B]”, “[A] and/or [B]”, or “at least one of [A] or [B]”, are to be understood as including only A, only B, or both A and B.

[0022] It shall be noted that, descriptions of example embodiments of the present disclosure may include terms and names defined in one or more standard organizations, such as the 3rd Generation Partnership Project (3GPP) standard organization, the European Telecommunications Standards Institute (ETSI) standard organization, the Open Radio Access Network (0-RAN) Alliance standard organization, and the like. For instance, the terms “rApp”, “xApp”, “Al interface”, “Al policy”, “E2 interface”, “01 interface”, “02 interface”, and the like, as well as the associated features and operations, are to be interpreted as consistent with those specified in one or more technical specifications.

[0023] Furthermore, although example embodiments of the present disclosure described herein are associated with the resolutions of conflicts between rApp and xApp, it is contemplated that the example embodiments can also be utilized to resolve the conflicts between multiple rApps and the conflicts between multiple xApps, without departing from the scope of the present disclosure.

[0024] As described above, in the open radio access network (O-RAN) architecture, the RAN functions may be disaggregated into multiple logical nodes or entities, such as a central unit (CU), a distributed unit (DU), and a radio unit (RU). To this end, since the disaggregated entities have open protocols and interfaces between them, they can be developed by different vendors. Further, the RAN functions may be controlled and optimized by RAN Intelligent Controller (RIC), such as a non-real-time RIC (Non-RT RIC) and a near-real-time RIC (Near-RT RIC). The Non- RT RIC may implement one or more applications called rApp(s), and the Near-RT RIC may implement one or more applications called xApp(s). Each of the rApps and xApps may be developed and provided by different vendors.

[0025] Nevertheless, although the open architecture of O-RAN allows flexibility in the participants or vendors of the RAN components or entities, it also creates complications and challenges in controlling the RAN. Amongst others, control action conflicts may occur at many levels among different RAN components, since multiple entities or components may be involved in the configuration and execution of RAN operations. Within RICs, these conflicts can occur between rApps in the Non-RT RIC, between xApps in the Near-RT RIC, and between the rApp(s) of the Non-RT RIC and the xApp(s) of the Near-RT RIC. Further, these conflicts may be categorized into different types, such as direct conflicts, indirect conflicts, and implicit conflicts.

[0026] Direct conflicts can be observed directly by the network system and can be mitigated by pre-action coordination. As an example, an rApp and an xApp may request different settings for the same configuration of one or more parameters of a control target, such as the same network node (similar conflicts may occur when two or more rApps/two or more xApps request different setting for the same configuration of the one or more parameters of the same control target). In this regard, the system may detect the conflicts and decide on a resolution (e.g., determine an order the changes are applied, etc.)

[0027] Indirect conflicts, although cannot be observed directly, may be anticipated by the network system. Specifically, the system may observe the parameters and resources of the target rApp(s)/xApp(s) and take action to mitigate the indirect conflicts when said conflicts are anticipated. As an example, when the changes required by rApp (or an xApp) create a system impact that is equivalent to a parameter change targeted by another rApp (or another xApp), an indirect conflict may occur. In this regard, the indirect conflicts can be resolved by post-action verification. Specifically, the actions are executed and the effects on the target component are observed. Based on the observations, the system can decide on potential corrections (e g., rolling back one of the actions, etc.)

[0028] Implicit conflicts cannot be observed directly, even the dependence between the rApps and/or xApps is not obvious. As an example of implicit conflicts, an rApp/xApp may optimize different metrics and manage different parameters. Nonetheless, optimizing one metric may have implicit, unintended side effects on one of the metrics optimized by another rApp/xApp. Since the implicit conflicts are difficult (if not impossible) to be observed, the implicit conflicts are the most difficult to mitigate and the resolutions thereof are hard to model.

[0029] In view of the above, there is a need to provide resolutions for all of the aforementioned types of conflicts, particularly the implicit conflicts. Nevertheless, at the present time, no methods of detecting or resolving all types of conflicts are defined and specified in the ORAN technical specifications as they are considered for future study. Further, although the concepts and demands for solving the conflicts between rApps and conflicts between xApps are recognized in the related art, the resolutions of the conflicts between rApp and xApp remained undefined and unspecified.

[0030] Example embodiments of the present disclosure provide a system, a method, a device, and the like, that efficiently and effectively provide the resolution of all types of conflicts between the rApp and xApp. Specifically, example embodiments of the present disclosure introduce a conflict management (CM) entity in each of the Non-RT RIC and Near RT RIC, and each CM entity may be configured to continuously (or periodically) monitor the active rApp(s) and xApp(s) and publish the associated information to the active (or selected) rApp(s) and xApp(s). Accordingly, before taking any action, the rApp(s) and xApp(s) can refer to the information of other active applications to determine or detect any potential conflict between the to-be-performed action and the action being performed by or scheduled to be performed by other applications, which effectively and efficiently mitigate conflicts therebetween. Further, in some example embodiments, the rApp(s) and xApp(s) can determine an appropriate resolution for any detected conflict(s) (e.g., determining an alternative network node to which the intended action/operation can be performed, canceling/delaying the action to avoid conflicting a higher priority operation, etc.) [0031] It is contemplated that features, advantages, and significances of example embodiments described hereinabove are merely a portion of the present disclosure, and are not intended to be exhaustive or to limit the scope of the present disclosure. Further descriptions of the features, components, configuration, operations, and implementations of the example embodiments of the present disclosure are provided in the following.

Example System Architecture

[0032] FIG. 1 illustrates an 0-RAN architecture in which one or more example embodiments may be applied. As shown in FIG. 1, the system architecture may include at least one Service Management and Orchestration (SMO) framework 110 that includes at least one non- real-time RAN Intelligent Controller (Non-RT RIC) 120, at least one near-real-time RIC (Near- RT RIC) 130, at least one O-RAN Central Unit (O-CU) 140, at least open evolved NodeB (O-eNB) 150, at least one O-RAN Distributed Unit (O-DU) 160, a plurality of O-RAN Radio Units (O-RUs) 170, and at least one O-RAN Cloud (O-Cloud) 180. The Non-RT RIC 120 may further include at least one rApp 121 and a first conflict management (CM) entity 122, while the Near-RT RIC 130 may further include at least one xApp 131 and a second CM entity 132. As further described below, the components may be communicatively coupled to another component(s) via a respective interface(s).

[0033] It is contemplated that the system architecture may include more/fewer components than illustrated, and/or may be configured in a different manner, without departing from the scope of the present disclosure. For instance, in some implementations, the system architecture may include a plurality of O-DUs 160 each of which is communicatively coupled to the O-CU 140, the Non-RT RIC 120 may include a plurality of rApps, the Near-RT RIC 130 may include a plurality of xApps, and the like. [0034] Generally, the RIC may be a software-defined component that implements modular applications to facilitate multivendor operability, as well as to automate and optimize RAN operations. As shown in FIG. 1, the RIC may be divided into two types, i.e., the Non-RT RIC 120 and the Near-RT RIC 130. In the following, descriptions of the Non-RT RIC 120 are provided, followed by the descriptions of the Near-RT RIC 130.

[0035] The Non-RT RIC 120 may refer to a logical function within the SMO framework 110 that drives the content carried across the Al interface to enable non-real-time control and optimization of RAN elements and resources. The Al interface may refer to a logical interface between the Non-RT RIC 120 and the Near-RT RIC 130, which enables the Non-RT RIC 120 to provide policy-based guidance to the Near-RT RIC 130 and enables the Near-RT RIC 130 to provide one or more feedback to the Non-RT RIC 120 thereby enabling the Non-RT RIC 120 to monitor the status or implementation of one or more policies.

[0036] In some example implementations, the Non-RT RIC 120 may be the control point of a non-real-time control loop and may operate on a timescale greater than 1 second within the SMO framework 110. Generally, the functionalities of the Non-RT RIC 120 may include, for example, providing policy-based guidance and enrichment across the Al interface, performing data analytics, Artificial Intelligence/Machine Learning (AI/ML) models training and inference for RAN optimization, and/or recommending configuration management actions. As further described below, the Non-RT RIC 120 may access or communicate with other SMO framework functionalities or components via the Al interface, 01 interface, 02 interface, and one or more interfaces associated with one or more open fronthaul (O-FH) planes.

[0037] According to example embodiments, the functionalities of the Non-RT RIC 120 may be implemented through at least one modular, Non-RT RIC application, such as the rApp 121 . The rApp 111 may leverage the functionalities available in the SMO framework 110 and/or the Non-RT RIC 120 to provide value-added services related to RAN operation and optimization, such as policy management, radio resource management, data analytics, and providing enrichment information. In some example implementations, the Non-RT RIC 120 may implement a plurality of rApps 121.

[0038] According to example embodiments, the Non-RT RIC 120 (or the rApp 121 associated therewith) may be configured to generate and provide one or more policies to the Near- RT RIC 130 via the Al interface, and may be configured to manage one or more policies that are provided to the Near-RT RIC 130 over the Al interface. Said policies may be referred to as “Al policies” herein, and are declarative policies that contain information applicable to one or more network nodes (e.g., one or more UEs, one or more network cells, etc.) The one or more Al policies may consist of a scope identifier and one or more policy statements. The scope identifier may represent the network node(s) that the policy statements are to be applied on (e.g., cells, UEs, DUs, etc.) The policy statements may define the goals or objectives of the policy and may include information associated with one or more policy objectives and one or more policy resources. The Non-RT RIC 120 (or the rApp 121 associated therewith) may provide the one or more Al policies to the Near-RT RIC 230, thereby providing guidance to the Near-RT RIC 230 towards one or more objectives or goals defined in the RAN intent. The RAN intent may refer to the high-level operational or business goal(s) to be achieved by the RAN, which may be defined by one or more desired service level agreements (SLAs) that the RAN is to fulfill for all users or for a subset of users in a given area over at least a predefined period of time.

[0039] According to example embodiments, the Non-RT RIC 120 (or the rApp 121 associated therewith) may be configured to receive, from the Near-RT RIC 130 via the Al interface, one or more feedback associated with one or more Al policies (“Al policy feedback” herein).

Similarly, the Non-RT RIC 120 (or the rApp 121 associated therewith) may be configured to receive one or more observables (e.g., events, counters, etc.) provided by the O-CU 140, the O- DU 160, and/or one or more of the O-RUs 170 over the 01 interface. Accordingly, the Non-RT RIC 120 (or the rApp 121 associated therewith) may be configured to continuously (or periodically) manage the one or more Al policies based on the Al policy feedback(s) and/or the observables provided over the 01 interface. For instance, the Non-RT RIC 120 (or the rApp 121 associated therewith) may continuously (or periodically) evaluate the impact or effectiveness of the one or more Al policies towards the fulfillment of the RAN intent and then configure or update the one or more Al policies accordingly.

[0040] According to example embodiments, the rApp 121 may include any suitable type of application, such as an application associated with energy saving, an application associated with network configuration management, an application associated with policy management, an application associated with network optimization, and the like. When the rApp 121 is first deployed or implemented, the rApp 121 may subscribe or register to the CM entity 122 and be assigned (e.g., by the network operator) one or more priorities in performing an associated action or operation.

[0041] According to example embodiments, the Non-RT RIC 120 may implement at least one conflict management (CM) entity 122. In this regard, the CM entity 122 may include a database or a dashboard application (or a component implementing the dashboard application), or may be implemented in the form of rApp. The CM entity 122 may be configured to collect information associated with the rApp 121 (e.g., application name, current/past status, undergoing actions, scheduled actions, action type, action name, policy-change decision, associated priorities, next update time, etc.) and then provide the information to other nodes or applications in a standardized way. As an example, the CM entity 122 may collect the information of the rApp 121 and then provide the information to the Near-RT RIC 130.

[0042] According to example embodiments, the CM entity 122 may be configured to broadcast the information of the rApp(s) that has subscribed to the CM entity 122 or published their information (e.g., existing task, changes in priority/policy, scheduled action, etc.) thereto. In this regard, the CM entity 122 may be configured to broadcast or publish the information of the rApp(s) to all rApp(s) that have subscribed thereto, or to selected rApp(s) only (e.g., rApp of a specific type, etc.) In this way, the CM entity can be accessed by the rApp(s) (via the Al interface, etc.) as part of the enrichment procedure.

[0043] Further, in example embodiments in which the Non-RT RIC 120 includes multiple rApps and/or the Near-RT RIC 130 includes multiple xApps, the CM entity 122 may share the information of the rApp 121 to the multiple rApps and/or multiple xApps in a standardized manner, such that all rApps/xApps can understand the content of the shared information and appropriately utilize said information to determine any potential conflicts with their own current/upcoming action(s).

[0044] According to example embodiments, the CM entity 122 may receive, from the rApp 121, a request to publish or update the associated information. For instance, the CM entity 122 may receive a “Write Request” along with the associated information as well as information like the priority, change request, time to expire, and override state. The CM entity 122 may also receive other types of requests in a similar manner, such as a “Read Request” for accessing and viewing the information published by the CM entity 122, a “Configuration Lock Request” for notifying other network nodes that the configuration of a target network node(s) should be locked (further described below), a “Cancel Action Request” for canceling a scheduled/pending action, a “Cancel

Request Order” defining an order to cancel a request, a “Configuration Update Request” for updating the configuration of a target network node(s), and the like. Furthermore, the CM entity 122 may also receive a combination of one or more of the above-mentioned requests, such as a “Read-Write Request” for publishing the associated information and for reading the published information. Further, the CM entity 122 can optionally publish the request(s) to other network nodes. For example, the CM entity 122 may publish the “Configuration Lock Request” for a set gNB/eNB/VNF/PNF level.

[0045] In the example embodiments in which the Non-RT RIC 120 includes multiple rApps, the CM entity 122 may receive the request(s) from a part of (or all of) the existing rApps. In response, the CM entity 122 may provide the response only to the rApps that have provided the request(s). For instance, assuming that the Non-RT RIC 120 includes three rApps A to C, while rApp A has provided a “Write Request” along with the associated information to the CM entity 122 and rApps B and C have each provided a “Read Request” to the CM entity 122. In this regard, the CM entity 122 may collect the information of the rApp A and publish said information to rApps B and C.

[0046] According to example embodiments, the CM entity 122 may be configured to communicate (via the Al interface, etc.) with the CM entity 132 implemented in the Near-RT RIC 130 (further described below) to provide the information of the rApp 121 thereto and to obtain information of the xApp 131 therefrom. In some example implementations, the CM entity 122 and the CM entity 132 may synchronize with each other by periodically (or continuously) exchanging a synchronization message, in real-time (or near-real-time such as in the time scale of milliseconds). The synchronization message may include new or updated information collected by the CM entities, as well as the requests (if any) from the rApp/xApp, such as the “Configuration Lock Request” and the like.

[0047] According to example embodiments, the CM entity 122 may include information of the priority of the rApp(s) implemented within the Non-RT RIC 120. As further described below with reference to the example of FIG. 3, the priority of the rApp(s) may be presented in a table form (said table may be referred to as “priority table” herein). In this case, the CM entity 122 may include the priority table that includes the priority information of the rApp(s), and said priority table may be provided by the user (e.g., network operator) and be regularly updated as required. In some example implementations, when a new rApp is first implemented in the Non-RT RIC 120 and subscribes to the CM entity 122 (e.g., sending a “Write Request” along with the associated information such as name, application type, assigned priorities, etc.), the CM entity 122 may determine whether or not the new rApp has the same priority(s) with any existing, previously subscribed rApp. Accordingly, based on determining that the new rApp does not have the same priority(s) as any of the existing rApp(s), the CM entity 122 may update the priority table to include the priority information of the new rApp. On the other hand, based on determining that the new rApp has the same priority(s) as any of the existing rApp(s), the CM entity 122 may notify the user (e g., the network operator) by, for example, presenting an error message, such that the user can reconsider and reassign an appropriate priority(s) to the new rApp or the existing rApp.

[0048] Referring still to FIG. 1, in addition to the communication with the Near-RT-RIC 130 via the Al interface, the SMO framework 110 (as well as the Non-RT RIC 120 and/or the rApp 121 and the CM entity 122 implemented therein) may communicate with the Near-RT RIC 130, the O-CU 140, the O-eNB 150, the O-DU 160, and/or the O-RU(s) 170 via the 01 interface. In this regard, the 01 interface may refer to a logical interface between the SMO framework 110, the Near-RT RIC 130, the O-CU 140, the O-eNB 150, the O-DU 160, and the O-RU(s) 170, which enables the SMO framework 110 (as well as the Non-RT RIC 120 and the rApp 121 implemented therein) to provide Fault, Configuration, Accounting, Performance, and Security (FCAPS) and other management operations, such as network monitoring, network discovery, and the like, to the Near-RT RIC 130, the O-CU 140, the O-eNB 150, the O-DU 160, and the O-RU(s) 170. Additionally, the 01 interface enables the Near-RT RIC 130, the O-CU 140, the O-eNB 150, the O-DU 160, and the O-RU(s) 170 to provide information or observable(s) that may be utilized by the Non-RT RIT 120 (or the rApp 121 associated therewith) to manage one or more Al policies, to train one or more AI/ML models, and the like.

[0049] Further, the SMO framework 110 (as well as the Non-RT RIC 120 and/or the rApp 121 and the CM entity 122 implemented therein) may communicate with the O-Cloud 180 via the 02 interface. In this regard, the 02 interface may refer to a logical interface between the SMO framework 110 and the O-Cloud 180, which may be a collection of physical RAN nodes that host the Non-RT RIC 120, the Near-RT RIC 130, the O-CU 140, and the O-DU 160, the supporting software components (e.g., the operating systems and runtime environments), and the SMO framework 110 itself. In other words, the SMO framework 110 may manage the O-Cloud 180 from within, and the 02 interface may be the interface between the SMO framework 110 and the O- Cloud 180 it resides in. Through the 02 interface, the SMO framework 110 (as well as the Non- RT RIC 120 and/or the rApp 121 implemented therein) may provide infrastructure management services (IMS) and deployment management services (DMS) for the O-Cloud 180.

[0050] Furthermore, the SMO framework 110 (as well as the Non-RT RIC 120 and/or the rApp 121 and the CM entity 122 implemented therein) may also communicate with the O-RU(s) 170 via an open fronthaul (O-FH) management plane (M-Plane) interface. In this regard, the O- FH M-Plane may enable the SMO framework 110 (as well as the Non-RT RIC 120 and/or the rApp 121 implemented therein) to perform one or more FCAPS operations on the O-RU(s) 170.

[0051] Next, the descriptions of the Near-RT RIC 130 are provided. The Near-RT RIC 130 may refer to a logical function that enables near-real-time control and optimization of RAN elements and resources. For instance, the Near-RT RIC 130 may provide near-real-time control and optimization via fine-grained (e.g., UE basis, Cell basis, etc.) data collection and actions over the E2 interface. In some example implementations, the Near-RT RIC 130 may operate on a timescale between 10 milliseconds and 1 second and may be coupled with the O-CU 140, the O- eNB 150, and the O-DU 160 via the E2 interface. The Near-RT RIC 130 may use the E2 interface to control the underlying network nodes or RAN elements (e.g., E2 nodes, network functions (NFs), etc.) over a near-real-time control loop.

[0052] According to example embodiments, the Near-RT RIC 130 may be configured to perform (based on one or more Al policies provided by the Non-RT RIC 120) one or more energysaving operations, such as switching a cell/carrier On/Off, handover a user from a cell to another cell, and the like. Further, the Near-RT RIC 130 may monitor, suspend/stop, override, and control the E2 nodes (e.g., O-CU 140, O-DU 160, etc.) via utilizing one or more Al policies. For example, the Near-RT RIC 230 may receive the one or more Al policies (e.g., energy-saving policy(s), etc.) from the Non-RT RIC 120 (or the rApp 121 associated therewith), and then interpret the received Al policy(s) to determine one or more control operations (e.g., energy-saving operation(s), etc.) or one or more policy commands. In some example implementations, upon receiving the Al policy(s), the Near-RT RIC 130 may collect one or more measurement data from one or more E2 nodes (e.g., O-CU 140, O-eNB 150, O-DU 160, etc.) via the E2 interface, and then determine (e.g., by performing artificial intelligence (AI)/machine learning (ML) inference based on the received Al policy(s) and the collected measurement data, etc.) the one or more control operations thereafter. Subsequently, the Near-RT RIC 130 may generate and send one or more control messages (e.g., Cell/Carrier Switch On/Off message, etc.) to one or more E2 nodes and/or one or more of the O-RUs 170. Accordingly, the E2 node(s) and/or the O-RU(s) may be configured to update their associated configurations to execute one or more operations to switch on/off the cell or carrier.

[0053] According to example embodiments, the Near-RT RIC 130 may host one or more applications, such as the xApp 131, to implement the associated functions or operations described herein. In this regard, the xApp 131 may consist of one or more microservices, which may be independent of the Near-RT RIC 130 and may be provided by any third-party vendor. The E2 interface may enable a direct association between the xApp 131 and other RAN functionalities (e.g., O-CU 140, 0-DU 160, etc.), thereby enabling the xApp 131 to provide information or data to the RAN functionalities for further utilization. According to example embodiments, the Near- RT RIC 130 may consist of multiple xApps 131 and a set of platform functions that are commonly used to support the specific functions hosted by the multiple xApps 131. In this regard, the Near- RT RIC platform may communicate with the xApp(s) 131 via one or more application programming interfaces (APIs). Further, the Near-RT RIC platform may be configured to route Al policy management messages to the registered xApp(s) based on Al policy type and operator policies.

[0054] According to example embodiments, the xApp 131 may include any suitable type of application, such as an application associated with energy saving, an application associated with handover optimization, an application associated with mobility management, an application associated with radio link monitoring, an application associated with traffic steering, an application associated with load balancing, an application associated with policy management, an application associated with interference management, and the like. Similar to the rApp 121, when the xApp 131 is first deployed or implemented, the xApp 131 may subscribe or register to the CM entity 132 and be assigned (e g., by the network operator) one or more priorities in performing an associated action or operation.

[0055] According to example embodiments, the Near-RT RIC 130 may implement at least one CM entity 132. Similar to the CM entity 122, the CM entity 132 may include a database or a dashboard application (or a component implementing the dashboard application), or may be implemented in the form of xApp. The CM entity 132 may be configured to collect information associated with the xApp 131 (e g., application name, current/past status, undergoing actions, scheduled actions, action type, action name, policy-change decision, associated priorities, next update time, etc.) and then provide the information to other nodes or applications in a standardized way. As an example, the CM entity 132 may collect the information of the xApp 131 and then provide the information to the Non-RT RIC 120.

[0056] According to example embodiments, the CM entity 132 may be configured to broadcast the information of the xApp(s) that has subscribed to the CM entity 132 or published their information (e g., existing task, changes in priority/policy, scheduled action, etc.) thereto. In this regard, the CM entity 132 may be configured to broadcast or publish the information of the xApp(s) to all xApp(s) that have subscribed thereto, or to selected xApp(s) only (e.g., xApp of a specific type, etc.) In this way, the CM entity 132 can be accessed by the xApp(s) (via the Al interface, etc.) as part of the enrichment procedure.

[0057] Further, in example embodiments in which the Non-RT RIC 120 includes multiple rApps and/or the Near-RT RIC 130 includes multiple xApps, the CM entity 132 may share the information of the xApp 131 to the multiple rApps and/or multiple xApps in a standardized manner, such that all rApps/xApps can understand the content of the shared information and appropriately utilize said information to determine any potential conflicts with their own current/upcoming action(s).

[0058] According to example embodiments, the CM entity 132 may receive, from the xApp 131, a request to publish or update the associated information. For instance, the CM entity 132 may receive a “Write Request” along with the associated information as well as information like the priority, change request, time to expire, and override state. The CM entity 132 may also receive other types of requests in a similar manner, such as a “Read Request” for accessing and viewing the information published by the CM entity 132, a “Configuration Lock Request” for notifying other network nodes that the configuration of a target network node(s) should be locked (further described below), a “Cancel Action Request” for canceling a scheduled/pending action, a “Cancel Request Order” defining an order to cancel a request, a “Configuration Update Request” for updating the configuration of a target network node(s), and the like. Furthermore, the CM entity 132 may also receive a combination of one or more of the above-mentioned requests, such as a “Read-Write Request” for publishing the associated information and for reading the published information. Further, the CM entity 132 can optionally publish the request(s) to other network nodes. For example, the CM entity 132 may publish the “Configuration Lock Request” for a set gNB/eNB/VNF/PNF level.

[0059] In the example embodiments in which the Near-RT RIC 130 includes multiple xApps, the CM entity 132 may receive the request(s) from a part of (or all of) the existing xApps.

In response, the CM entity 132 may provide the response only to the xApps that have provided the request(s). For instance, assuming that the Near-RT RIC 130 includes three xApps D to F, while xApp D has provided a “Write Request” along with the associated information to the CM entity

132 and xApps E and F have each provided a “Read Request” to the CM entity 132. In this regard, the CM entity 132 may collect the information of the xApp D and publish said information to xApps E and F.

[0060] According to example embodiments, the CM entity 132 may be configured to communicate (via the Al interface, etc.) with the CM entity 122 implemented in the Non-RT RIC 120 to provide the information of the xApp 131 thereto and to obtain information of the rApp 121 therefrom. As described above, in some example implementations, the CM entity 132 and the CM entity 122 may synchronize with each other by periodically (or continuously) exchanging a synchronization message, in real-time (or near-real-time such as in the time scale of milliseconds). [0061] According to example embodiments, the CM entity 132 may include information of the priority of the xApp(s) implemented within the Near-RT RIC 130. As further described below with reference to the example of FIG. 3, the priority of the xApp(s) may be presented in a priority table. In this case, the CM entity 132 may comprise the priority table that includes the priority information of the xApp(s), and said priority table may be provided by the user (e.g., network operator) and be regularly updated as required.

[0062] In some example implementations, when a new xApp is first implemented in the Near-RT RIC 130 and subscribes to the CM entity 132 (e.g., sending a “Write Request” along with the associated information such as name, application type, assigned priorities, etc.), the CM entity 132 may determine whether or not the new xApp has the same priority(s) as any existing, previously subscribed xApp. Accordingly, based on determining that the new xApp does not have the same priority(s) as any of the existing xApp(s), the CM entity 132 may update the priority table to include the priority information of the new xApp. On the other hand, based on determining that the new xApp has the same priority(s) as any of the existing xApp(s), the CM entity 132 may notify the user (e.g., the network operator) by, for example, presenting an error message, such that the user can reconsider and reassign an appropriate priority(s) to the new xApp or the existing xApp.

[0063] Next, the descriptions of the O-CU 140, the O-eNB 150, the 0-DU 160, and the O-

RU 170 are provided. Generally, the O-CU 140, the 0-DU 160, and the 0-RU 170 may constitute a base station, such as a gNodeB (gNB) of 5G NR, a node in Next Generation Radio Access Network (NG-RAN), a base station of a 6G network, and the like. On the other hand, the O-eNB 150 may refer to a 4G LTE version of the O-RAN-compliant node (e.g., an eNB that adheres to the O-RAN architecture).

[0064] The communication between the O-CU 140 and the 0-DU 160 may be performed via an Fl interface, while the communication between the 0-DU 160 and the O-RU 170 may be performed via one or more O-FH Control (C), User (U), Synchronization (S), and Management (M) plane interfaces. In some example implementations, the C, U, and S planes may be consolidated and referred to as the “CUS-plane”. According to example embodiments, the system may include a plurality of O-DUs 160, and the O-CU 140 may be communicatively coupled to the plurality of O-DUs via the Fl interface. Similarly, the system may include a plurality of O-RUs 170, and the O-DU(s) 160 may be communicatively coupled to the plurality of O-RUs via one or more of the O-FH C/U/S/M plane interfaces.

[0065] According to example embodiments, the O-CU 140 and the O-DU 160 may be defined in software form and may be deployed in one or more network nodes. For instance, the O- CU 140 and the O-DU 160 may be deployed in one or more servers in the form of virtualized network function (VNF), containerized and/or cloud-native function (CNF), and the like. According to example embodiments, the O-CU 140 and the 0-DU 160 may be deployed in the same network node (e.g., same server) and/or may be located at a similar geographical location

(e.g., be deployed in different servers in the same data center). According to example embodiments, the O-CU 140 and the O-DU 160 may be deployed in different network nodes and/or may be located at different geographical locations. For instance, the O-CU 140 may be deployed in one or more central servers (i.e., servers in one or more central data centers), and the O-DU 160 may be deployed in one or more edge servers (i.e., servers in one or more edge data centers).

[0066] The O-DU 160 may receive radio signals from an end user (via one or more UEs and one or more cells) and may provide operation or support for lower layers of protocol stacks (e g., RLC layer, MAC layer, Physical Layer, etc.) accordingly. As an example, the O-DU 160 may perform one or more scheduling operations. The O-CU 140 may communicatively couple the O-DU 160 to a core network (e.g., 4G Evolved Packet Core (EPC) network, 5G Core network, etc.) and may receive the radio signals from the O-DU 160, thereby providing operation or support for higher layers of protocol stacks (e.g., PDCP layer, RRC layer, etc.) accordingly.

[0067] According to example embodiments, the O-CU 140 may include an O-CU control plane (O-CU-CP) 141 and an O-CU user plane (O-CU-UP) 142. The O-CU-CP 141 may refer to the logical node that hosts or implements the RRC and the control plane part of the PDCP protocol, and may be responsible for managing the signaling between the core network and the radio network, handling tasks such as session management, radio bearer control, and mobility management. On the other hand, the O-CU-UP 142 may refer to the logical node that hosts or implements the user plane part of the PDCP protocol and the SDAP protocol, and may be responsible for managing the data traffic and the transmission of user data packets. The O-CU-CP 141 and the O-CU-UP 142 may be coupled to each other via the El interface. [0068] Further, a single O-DU 160 may host or serve multiple network cells formed by multiple O-RUs 170. According to example embodiments, the O-DU 160 may implement various radio technologies, such as massive multiple-input multiple-output (MEMO), beamforming, and the like, to optimize radio communication among the multiple cells and the O-CU 140. In some example implementations, the O-DU 160 may concurrently host or serve hundreds (e.g., 512, etc.) of cells at a time.

[0069] The O-RU(s) 170 may be a physical node that converts radio signals from antennas to digital signals that can be transmitted over the Front Haul to the O-DU 160. In this regard, a network cell described herein may correspond to one or more radio units responsible for providing wireless coverage and signal transmission within the network cell. The network cell may include a macro cell, a micro cell, a pico cell, a femto cell, and/or any other suitable type of network cell. Each of the cells may have an associated coverage area, in which at least one O-RU 170, at least one antenna system, and any other suitable type of transport network element (TNE), may be deployed therein.

[0070] According to example embodiments, the O-DU 160 may be configured to control or instruct the associated O-RU(s) via one or more of the O-FH C/U/S/M plane interfaces. For instance, the O-DU 160 may instruct the O-RU(s) 170 to shut down or enter sleep mode via the O-FH C/U/S plane interfaces. On the other hand, the capability exchange between the O-DU 160 and the O-RU(s) 170 may be performed via the O-FH M-plane interface. As an example, the O- RU(s) 170 may inform the O-DU 160 of the amount of time it requires to maintain in sleep mode (or off mode) in order to save an amount of energy, and the like.

[0071] In view of the above, example embodiments of the present disclosure provide effective and efficient solutions to resolve the conflicts between RIC applications (e.g., rApp and xApp) in O-RAN. Specifically, the CM entities in the RICs may effectively and efficiently share or publish the information of the rApp(s) and xApp(s), and the rApp(s) and xApp(s) may utilize the shared information to determine potential conflict(s) and appropriately resolve the conflict(s) thereafter. Accordingly, by leveraging the CM entities in the RICs, an effective and efficient resolution of the conflicts in O-RAN can be provided, while reducing the exposure of internal working (i.e., ‘Know-How’ of operations) of each rApp/xApp to other network components (which is not desirable in O-RAN since the rApp and xApp may be provided by different vendors) and reducing the utilization of central resource to judge and resolve conflicts (since the conflicts are now being detected and resolved by the rApp/xApp themselves, instead of being detected or resolved by a centralized conflict mitigation functionality as suggested in the related art).

Example Operations and Use Cases

[0072] As described above, example embodiments of the present disclosure implement at least one conflict management (CM) entity in each of the Non-RT RIC and Near-RT RIC, thereby providing conflict resolution for the O-RAN RICs. In the following, descriptions of the example operations and use cases associated therewith are provided.

[0073] FIG. 2 illustrates a block diagram of an example configuration of the interaction between the rApp, xApp, and the respective CM entity, according to one or more example embodiments. In the example of FIG. 2, the Non-RT RIC 120 (and the rApp 121 and CM entity 122 implemented therein) and the Near-RT RIC 130 (and the xApp 131 and CM entity 132 implemented therein) in FIG. 1 are involved. For descriptive purposes, the CM entity 122 may also be referred to as the “first CM entity” and the CM entity 132 may also be referred to as the

“second CM entity”. [0074] As illustrated in FIG. 2, the first CM entity 122 may be configured to collect information of the rApp 121, and then communicate with the second CM entity 132 to provide information of the rApp 121 thereto and to obtain information of the xApp 131 therefrom. On the other hand, the second CM entity 132 may be configured to collect information of the xApp 131, and then communicate with the first CM entity 122 to provide the information of the xApp 131 thereto and to obtain information of the rApp 121 therefrom.

[0075] According to example embodiments, the information of the rApp 121 may include the name of the rApp 121, information associated with a first operation performed or to be performed by the rApp 121, and information associated with the priority of the rApp 121. In this regard, the information associated with the first operation may include information associated with one or more of: the type of the first operation (e.g., energy saving, configuration management, policy management, network optimization, etc.), the name of the first operation, the timing for performing the first operation, the target network node to which the first operation is applied or to be applied, and the like. In some example embodiments, the information associated with the rApp 121 may include a main priority associated with the type of rApp 121 and a secondary priority associated with one or more characteristics of the rApp 121, such as vendor information, resource consumptions (e.g., CPU, memory, etc.), performance (e g., efficiency, latency, throughput, etc.), and the like.

[0076] On the other hand, the information of the xApp 131 may include the name of the xApp 131, information associated with a second operation performed or to be performed by the xApp 131, and information associated with the priority of the xApp 131. In this regard, the information associated with the second operation may include information associated with one or more of: the type of the second operation (e.g., energy saving, handover optimization, mobility management, radio link monitoring, traffic steering, load balancing, policy management, interference management, etc.), the name of the second operation, the timing for performing the second operation, the target network node to which the second operation is applied or to be applied, and the like. In some example embodiments, the information associated with the xApp 131 may include a main priority associated with the type of xApp 131 and a secondary priority associated with one or more characteristics of the xApp 131, such as vendor information, resource consumptions (e.g., CPU, memory, etc.), performance (e.g., efficiency, latency, throughput, etc.), and the like.

[0077] The exchanging of the rApp/xApp information may be performed in any suitable sequence (e.g., information of xApp 131 being shared with the rApp 121 first, information of both rApp 121 and xApp 131 being concurrently shared to each other, etc.) According to example embodiments, the xApp 131 may operate in a time scale or time window shorter than the rApp 121 (e.g., xApp 131 operates in the time scale of milliseconds, while the rApp 121 operates in the time scale of seconds). Thus, the second CM entity 132 may provide or update the information of the xApp 131 to the rApp 121 more frequently than the first CM entity 131.

[0078] After receiving the information of other active applications, the rApp 121 and xApp 131 may initiate the respective operation based thereon. Example operations associated therewith are described below with reference to FIG. 4.

[0079] Next, referring to FIG. 3, which illustrates an example of a priority table, according to one or more example embodiments. In this example, the priority table includes priority information of three rApps (i.e., rApps 1 to 3) and three xApps (i.e., xApps 1 to 3).

[0080] As illustrated in FIG. 3, the rApp 1 and xApp 1 have been assigned the same main priority “1”, since both of them are applications associated with energy saving. Further, the rApp 1 has been assigned with a secondary priority “1.1” while the xApp 1 has been assigned with a secondary priority “1.2”. As a result, although rApp 1 and xApp 1 have the same main priority, rApp 1 has a higher priority than xApp 1 since it has a higher secondary priority. In this example, the rApp 1 has been assigned a higher secondary priority since the user (i.e., the network operator) is prioritizing the performance of the applications in energy saving (e.g., efficiency, etc.) instead of resource consumption (e.g., CPU usage, etc.) Both rApp 1 and xApp 1 have higher priority than other applications since the user is most prioritizing the energy saving of the network.

[0081] Similar explanations are applicable to the remaining rApps and xApps. Accordingly, the priority of the applications in FIG. 3 are as follows: rApp 1 has the highest priority among all rApps and all xApps, followed by the xApp 1, the rApp 2, the rApp 3, the xApp 2, and the xApp 3 (i.e., Priority: rApp 1> xApp l>rApp2>rApp3>xApp2>xApp3).

[0082] It is contemplated that the priority table in FIG. 3 are merely an example simplified for descriptive purposes. In actual implementations, the priority table may include more/lesser rApp and xApp, the number of main priority and secondary priority may be more/less, the priority of each application may be configured and assigned by the user (e.g., network operator) as per the respective requirements, the secondary priority may be presented in the form of “1A” instead of in the form of “1.1”, and the like.

[0083] Referring next to FIG. 4, which illustrates a flow diagram of an example method 400 for initiating an operation, according to one or more example embodiments. One or more operations of the method 400 may be performed by the rApp 121 and/or the xApp 131 (described above with reference to FIG. 1 and FIG. 2), after receiving the information of other active applications. In some example implementations in which the rApp 121/xApp 131 is implemented in a hardware (e.g., a server), one or more operations of the method 400 may be performed by a component of the hardware (e.g., a processor of the server upon executing computer-readable instruction stored in a memory of the server, etc.)

[0084] Referring to FIG. 4, at operation S410, the rApp/xApp may be configured to determine whether or not performing the associated operation on the target network node will cause a conflict with the operation(s) of other applications. As an example, the rApp 121 may determine whether or not performing the first operation on a network node will cause a conflict with a second operation performed by or to be performed by the xApp 131. Similarly, the xApp 131 may determine whether or not performing the second operation on the network node will cause a conflict with the first operation performed by or to be performed by the rApp 121.

[0085] Specifically, the rApp/xApp may first determine whether or not their intended operation(s) is applied (or to be applied) to the same network node. Accordingly, based on determining that the operation(s) is applied (or to be applied) to the same network node, the rApp/xApp may determine whether or not the operation(s) will result in an unwanted impact. For instance, the rApp/xApp may determine whether or not performing their operation(s) will disobey the objective of other ongoing operation(s) on the network node or other scheduled operation(s) to be applied to the network node. Subsequently, based on determining that performing the associated operation(s) will result in unwanted impact, the rApp/xApp may determine that the potential conflict(s) occurs. According to example embodiments, the rApp/xApp may perform operation S410 based on the information of the xApp/rApp provided by the respective CM entity.

[0086] Based on determining that performing the associated operation on the target network node will cause the conflict, the method 400 may proceed to operation S420. Otherwise, the method 400 may proceed to operation S430, at which the rApp/xApp may be configured to perform their associated operation(s) since there is no potential conflict. For example, based on determining that performing the first operation will not cause the conflict, the rApp 121 may perform the first operation on the network node. Similarly, based on determining that performing the second operation will not cause the conflict, the xApp 131 may perform the second operation on the network node. In this case, both of the first operation and the second operation will be performed on the network node without resulting in any conflict.

[0087] On the other hand, based on determining that performing the associated operation on the target network node will cause the conflict, at operation S420, the rApp/xApp may be configured to determine whether or not the associated priority is higher than the conflicting application(s). For instance, based on determining that performing the first operation will cause the conflict with the second operation performed by or to be performed by the xApp 131, the rApp 121 may determine whether or not the rApp 121 has a higher priory than the xApp 131. Similarly, based on determining that performing the second operation will cause the conflict with the first operation performed by or to be performed by the rApp 121, the xApp 131 may determine whether or not the xApp 131 has a higher priority than the rApp 121. According to example embodiments, the rApp/xApp may perform operation S420 based on the priority information of the conflicting application(s) provided by the respective CM entity.

[0088] Based on determining that the associated priority is higher than the conflicting application(s), the method 400 may return to operation S430, at which the rApp/xApp may be configured to perform their associated operation(s) on the target network node. Otherwise, the method 400 may be ended or terminated, and the rApp/xApp will not perform their associated operation(s).

[0089] In this regard, when the first operation of the rApp 121 has a potential conflict with the second operation of the xApp 131, based on determining that the rApp 121 has the higher priority than the xApp 131, the rApp 121 may perform the first operation to the network node while the xApp 131 will not perform the second operation. Similarly, based on determining that the xApp 131 has the higher priority than the rApp 121, the xApp 131 may perform the second operation to the network node while the rApp 121 will not perform the first operation. In this way, the rApp/xApp that has a higher priority can perform the associated operation(s), without causing any conflict.

[0090] According to alternative embodiments, based on determining that the associated priority is not higher than the conflicting application(s), the method 400 may proceed to operation S440, at which the rApp/xApp (that has lower priority than the conflicting application(s)) may be configured to determine an alternative network node to which the associated operation(s) can be performed. For example, based on determining that performing the first operation on the network node will cause the conflict and that the rApp 121 has a lower priority than the xApp 131, the rApp 121 may determine an alternative network node to which the first operation can be performed. Similarly, based on determining that performing the second operation on the network node will cause the conflict and that the xApp 131 has a lower priority than the rApp 121, the xApp 131 may determine an alternative network node to which the second operation can be performed.

[0091] The operation of determining an alternative network node may involve obtaining information of available network node(s), selecting a new target network node from among the available network node(s), obtaining information of active applications to determine whether or not performing the operation(s) on the new target network node will cause any conflict, and then performing the operation(s) on the new target network node (if no conflict is detected or if the rApp/xApp has a higher priority than the conflicting application(s)) or reselecting another alternative network node (if conflict is detected and the rApp/xApp has a lower priority than the conflicting application(s)). In this way, whenever the application(s) detects a potential conflict(s) that requires the application(s) to change the target network node, the application(s) can iteratively determine an alternative network node to which the associated application s) can be performed.

[0092] Next, descriptions of several use cases in which the example embodiments of the present disclosure can be implemented are provided. For descriptive purposes, descriptions of these use cases may include the components described above with reference to FIG. 1 to FIG. 4. Further, the following use cases taken into assumption that the rApp 121 is an application associated with energy saving and the xApp 131 is an application associated with traffic steering, and the rApp 121 and the xApp 131 are assigned with the priority according to the priority table in FIG. 3 (i.e., the rApp 121 has a priority higher than the xApp 131).

[0093] In the first use case, the xApp 131 has already triggered and performed one or more traffic steering operations on a network node A (e.g., E2 node, etc.) The actions and status of the xApp 131 are provided to the second CM entity 132, and the second CM entity 132 has synced this information with the first CM entity 122. In this case, the rApp 121 determines, based on the information published by the first CM entity 122, that the same network node A may be a candidate for energy-saving operations.

[0094] Accordingly, the rApp 121 may publish a request to the first CM entity 122, such as a request message of “Network Node A, Energy Saving, Priority-1, Action to trigger: Operation X, Time to trigger operation: T+5”. Here, T is the current Time, and “+5” is the preconfigured force action time (i.e., the time in which the action needs to be performed) and can be measured in any suitable unit (for descriptive purposes, it may be assumed that the Time to trigger the operation in this example use case is “T+5s”). [0095] Subsequently, the first CM entity 122 may sync this information with the second

CM entity 132, and the second CM entity 132 may provide these information to the xApp 131. In this regard, since the rApp 121 is assigned with a higher priority (since it is associated with energy saving), the xApp 131 will understand that, after 5s, the same network node A can no longer be the candidate for “Traffic Steering” operation, until it receives new notification for same node (notifying that the operations associated with the rApp 121 have ended, etc.), or when this internal threshold reach to “X%” to force and trigger a request to override the operation of the rApp 121. Since the xApp 131 operates in a time scale smaller than the rApp 121 (i.e., xApps 131 operates in the time scale of milliseconds, while the rApp 121 operates in the time scale of seconds), the xApp 131 may still perform the traffic steering operation(s) within 5 seconds from the current time, since the rApp 121 will not be performing the energy saving operation(s) until the next 5 seconds and no conflict will occur within these 5 seconds.

[0096] In the next use case, both rApp 121 and xApp 131 wanted to perform the associated operation(s) on the same network node A at the same time. For example, the xApp 131 is requesting to steer the traffic towards the network node A since the associated network traffic is low, while the rApp 121 is requesting to reduce the number of cores in the network node A since the associated network traffic is low. This information is collected and published by both the first CM entity 122 and the second CM entity 132 and is provided to both rApp 121 and xApp 131. In this case, since the rApp 121 has a higher priority, the rApp 121 may override the first CM entity 122 (and eventually override the second CM entity 132) with a “Configuration Lock” request to lock the current configuration of the network node A (i.e., network node A can only be configured by the rApp 121) and to notify the xApp 131 not to apply any changes to the network node A (e.g., by sending a “Cancel Request Order” with the information of the network node A). [0097] In view of the above, the rApp 121 and xApp 131 may obtain the information of other active applications from the respective CM entity, before performing any action or operation.

Accordingly, the rApp 121 and xApp 131 may effectively and efficiently anticipate or detect any potential conflicts before performing their operation(s), and may identify potential resolution (e.g., perform the intended operation on other network nodes, cancel the scheduled operation such that the operation of higher priority would not be affected, etc.) to mitigate any potential or existing conflicts.

Examples of System Hardware Components

[0098] One or more components of the system of the example embodiments (e.g., rApp 121, first CM entity 122, xApp 131, second CM entity 132, etc.), as well as the operations associated therewith, may be implemented in one or more devices or hardware components, such as one or more servers, and the like. In the following, descriptions of a device in which the example embodiments may be implemented are provided.

[0099] FIG. 5 illustrates an embodiment of a device 500. As shown in FIG. 5, the device 500 may include a processor 510, a memory 520, a storage component 530, an input component 540, an output component 550, a communication interface 560, and a bus 570.

[0100] The processor 510, as used herein, means any type of computational circuit that may comprise hardware elements and software elements. The processor 510 may be embodied as a multi-core processor, a single core processor, or a combination of one or more multi-core processors and/or one or more single core processors, a distributed processing system, or the like. The processor 510 may be a Central Processing Unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), an application-specific integrated circuit (ASIC), or another type of processing component. [0101] Memory 520 includes a non-transitory computer readable medium. Memory 520 includes a random-access memory (RAM), a read only memory (ROM), and/or another type of dynamic or static storage device (e.g., a flash memory, a magnetic memory, and/or an optical memory) that stores information and/or instructions for use by processor 510. The memory 520 comprises machine-readable instructions which are executable by the processor 510. These machine-readable instructions when executed by the processor 510 cause the processor 510 to perform one or more method steps of an embodiment described above.

[0102] Storage component 530 stores information and/or software related to the operation and use of the device 500. For example, storage component 530 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, and/or a solid-state disk), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, a magnetic tape, and/or another type of non-transitory computer-readable medium, along with a corresponding drive.

[0103] Input component 540 is configured to receive information, such as user input. For example, the input component 540 may include, but not be limited to, a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, and/or a microphone. Additionally, or alternatively, the input component 540 may include a sensor for sensing information (e.g., a global positioning system (GPS), an accelerometer, a gyroscope, and/or an actuator).

[0104] Output component 550 is configured to provide output information from the device 500. For example, the output component 550 may be, but not limited to, a display, a speaker, instructions to an external device, and/or one or more light-emitting diodes (LEDs).

[0105] Communication interface 560 is an interface that provides a communication connection to other devices, such as external devices and internal devices. The connection by the communication interface 560 can be a wired connection, a wireless connection, or a combination of wired and wireless connections, and can be a direct connection or an indirect connection via a communication network that exists between the device 500 and other devices. In other words, the standard of the communication interface 560 is not limited.

[0106] The bus 570 acts as an interconnect between the processor 510, the memory 520, the storage component 530, the input component 540, the output component 550, and the communication interface 560 of the device 500. The bus 570 may include a wired interconnection or a wireless interconnection.

[0107] The number and arrangement of components shown in FIG. 5 are provided as an example. In practice, device 500 may include additional components, fewer components, different components, or differently arranged components than those shown in FIG. 5. Additionally, or alternatively, a set of components (e.g., one or more components) of device 500 may perform one or more functions described as being performed by another set of components of device 500. Further, one or more method steps described in any of the embodiments may be performed utilizing a plurality of devices 500 in communication with one another.

Various Aspects of Embodiments

[0108] It is contemplated that the example embodiments described hereinabove with reference to FIG. 1 to FIG. 5 are merely examples of possible embodiments of the present disclosure, and are not intended to limit or restrict the scope of the present disclosure.

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

[0110] Some embodiments may relate to a device (e.g., network node, server, etc.), a system, a method, and/or a computer-readable medium at any possible technical detail level of integration. Further, one or more of the above components described above may be implemented as instructions stored on a computer-readable medium and executable by at least one processor (and/or may include at least one processor). The computer-readable medium may include a computer-readable non-transitory storage medium (or media) having computer-readable program instructions thereon for causing a processor to carry out operations.

[OHl] The computer-readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), electrically erasable programmable read-only memory (EEPROM), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer-readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

[0112] Computer-readable program instructions described herein can be downloaded to respective computing/processing devices from a computer-readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing/processing device.

[0113] Computer-readable program code/instructions for carrying out operations may be assembler instructions, instmction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, including an object-oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the "C" programming language or similar programming languages.

[0114] The computer-readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer-readable program instructions by utilizing state information of the computer- readable program instructions to personalize the electronic circuitry, in order to perform aspects or operations.

[0115] These computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer- readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer-readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.

[0116] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer-implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.

[0117] The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer- readable media according to various embodiments. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). The method, computer system, and computer-readable medium may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in the Figures. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed concurrently or substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

[0118] It will be apparent that systems and/or methods, described herein, may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and/or methods is not limited to the implementations. Thus, the operation and behavior of the systems and/or methods were described herein without reference to specific software code — it is understood that software and hardware may be designed to implement the systems and/or methods based on the description herein.

[0119] In view of the above, various further respective aspects and features of embodiments of the present disclosure may be defined by the following items:

Item [1]: A system includes: a non-real-time (Non-RT) radio access network intelligent controller (RIC) and a near-real-time (Near-RT) RIC; wherein the Non-RT RIC may include at least one application (rApp) and a first conflict management (CM) entity; wherein the Near-RT RIC may include at least one application (xApp) and a second CM entity; wherein the first CM entity may be configured to collect information of the rApp, and the first CM entity may be configured to communicate with the second CM entity to provide information of the rApp thereto and to obtain information of the xApp therefrom; wherein the second CM entity may be configured to collect information of the xApp, and the second CM entity may be configure to communicate with the first CM entity to provide the information of the xApp thereto and to obtain information of the rApp therefrom; wherein the rApp may be configured to obtain the information of the xApp from the first CM entity and to initiate a first operation thereafter; and wherein the xApp may be configured to obtain the information of the rApp from the second CM entity and to initiate a second operation thereafter.

Item [2]: The system according to item [1], wherein the rApp may be configured to initiate the first operation by: determining, based on the information of the xApp, whether or not performing the first operation on a network node will cause a conflict with the second operation; based on determining that performing the first operation will not cause the conflict, performing the first operation on the network node; based on determining that performing the first operation will cause the conflict, determining whether or not the rApp has a higher priority than the xApp; and based on determining that the rApp has the higher priority than the xApp, performing the first operation on the network node.

Item [3]: The system according to item [1], wherein the xApp may be configured to initiate the second operation by: determining, based on the information of the rApp, whether or not performing the second operation on a network node will cause a conflict with the first operation; based on determining that performing the second operation will not cause the conflict, performing the second operation on the network node; based on determining that performing the second operation will cause the conflict, determining whether or not the xApp has a higher priority than the rApp; and based on determining that the xApp has the higher priority than the rApp, performing the second operation on the network node.

Item [4]: The system according to item [2], wherein the rApp may be further configured to: based on determining that performing the first operation on the network node will cause the conflict and that the rApp has a lower priority than the xApp, determine an alternative network node to which the first operation can be performed.

Item [5]: The system according to item [3], wherein the xApp may be further configured to: based on determining that performing the second operation on the network node will cause the conflict and that the xApp has a lower priority than the rApp, determine an alternative network node to which the second operation can be performed.

Item [6]: The system according to any one of items [ l]-[5], wherein the information of the rApp may include a name of the rApp, information associated with the first operation, and information associated with the priority of the rApp; and wherein the information associated with the first operation may include information of one or more of: a type of the first operation, a name of the first operation, a timing for performing the first operation, and a target network node to which the first operation is to be applied.

Item [7]: The system according to any one of items [ l]-[6], wherein the information of the xApp may include a name of the xApp, information associated with the second operation, and information associated with the priority of the xApp; and wherein the information associated with the second operation may include information of one or more of: a type of the second operation, a name of the second operation, a timing for performing the second operation, and a target network node to which the second operation is to be applied.

Item [8]: A method includes: collecting, by a first conflict management (CM) entity associated with a non-real-time (Non-RT) radio access network intelligent controller (RIC), information of at least one application (rApp) associated with the Non-RT RIC; providing, by the first CM entity, information of the rApp to a second CM entity associated with a near-real-time (Near-RT) RIC; collecting, by the second CM entity, information of at least one application (xApp) associated with the Near-RT RIC; providing, by the second CM entity, information of the xApp to the first CM entity; obtaining, by the rApp from the first CM entity, information of the xApp; initiating, by the rApp, a first operation after receiving the information of the xApp; obtaining, by the xApp from the second CM entity, information of the rApp; and initiating, by the xApp, a second operation after receiving the information of the rApp.

Item [9] : The method according to item [8], wherein the initiating the first operation may include: determining, based on the information of the xApp, whether or not performing the first operation on a network node will cause a conflict with the second operation; based on determining that performing the first operation will not cause the conflict, performing the first operation on the network node; based on determining that performing the first operation will cause the conflict, determining whether or not the rApp has a higher priority than the xApp; and based on determining that the rApp has the higher priority than the xApp, performing the first operation on the network node. Item [10]: The method according to item [8], wherein the initiating the second operation may include: determining, based on the information of the rApp, whether or not performing the second operation on a network node will cause a conflict with the first operation; based on determining that performing the second operation will not cause the conflict, performing the second operation on the network node; based on determining that performing the second operation will cause the conflict, determining whether or not the xApp has a higher priority than the rApp; and based on determining that the xApp has the higher priority than the rApp, performing the second operation on the network node.

Item [11]: The method according to item [9], the method may further include: based on determining that performing the first operation on the network node will cause the conflict and that the rApp has a lower priority than the xApp, determining an alternative network node to which the first operation can be performed.

Item [12]: The method according to item [10], the method may further include: based on determining that performing the second operation on the network node will cause the conflict and that the xApp has a lower priority than the rApp, determining an alternative network node to which the second operation can be performed.

Item [13]: The method according to any one of items [8]-[12], wherein the information of the rApp may include a name of the rApp, information associated with the first operation, and information associated with the priority of the rApp; and wherein the information associated with the first operation may include information of one or more of: a type of the first operation, a name of the first operation, a timing for performing the first operation, and a target network node to which the first operation is to be applied. Item [14]: The method according to any one of items [8]-[13], wherein the information of the xApp may include a name of the xApp, information associated with the second operation, and information associated with the priority of the xApp; and wherein the information associated with the second operation may include information of one or more of: a type of the second operation, a name of the second operation, a timing for performing the second operation, and a target network node to which the second operation is to be applied.

Item [15]: A non-transitory computer-readable recording medium having recorded thereon instructions executable by a device to cause the device to perform a method comprising: collecting, by a first conflict management (CM) entity associated with a non- real-time (Non-RT) radio access network intelligent controller (RIC), information of at least one application (rApp) associated with the Non-RT RIC; providing, by the first CM entity, information of the rApp to a second CM entity associated with a near-real-time (Near-RT) RIC; collecting, by the second CM entity, information of at least one application (xApp) associated with the Near-RT RIC; providing, by the second CM entity, information of the xApp to the first CM entity; obtaining, by the rApp from the first CM entity, information of the xApp; initiating, by the rApp, a first operation after receiving the information of the xApp; obtaining, by the xApp from the second CM entity, information of the rApp; and initiating, by the xApp, a second operation after receiving the information of the rApp.

Item [16]: The non-transitory computer-readable recording medium according to item [15], wherein the initiating the first operation may include: determining, based on the information of the xApp, whether or not performing the first operation on a network node will cause a conflict with the second operation; based on determining that performing the first operation will not cause the conflict, performing the first operation on the network node; based on determining that performing the first operation will cause the conflict, determining whether or not the rApp has a higher priority than the xApp; and based on determining that the rApp has the higher priority than the xApp, performing the first operation on the network node.

Item [17]: The non-transitory computer-readable recording medium according to item [15], wherein the initiating the second operation may include: determining, based on the information of the rApp, whether or not performing the second operation on a network node will cause a conflict with the first operation; based on determining that performing the second operation will not cause the conflict, performing the second operation on the network node; based on determining that performing the second operation will cause the conflict, determining whether or not the xApp has a higher priority than the rApp; and based on determining that the xApp has the higher priority than the rApp, performing the second operation on the network node.

Item [18]: The non-transitory computer-readable recording medium according to item [16], wherein the method may further include: based on determining that performing the first operation on the network node will cause the conflict and that the rApp has a lower priority than the xApp, determining an alternative network node to which the first operation can be performed.

Item [19]: The non-transitory computer-readable recording medium according to item [17], wherein the method further comprises: based on determining that performing the second operation on the network node will cause the conflict and that the xApp has a lower priority than the rApp, determining an alternative network node to which the second operation can be performed.

Item [20]: The non-transitory computer-readable recording medium according to any one of items [ 15]-[ 19], wherein the information of the rApp may include a name of the rApp, information associated with the first operation, and information associated with the priority of the rApp; and wherein the information associated with the first operation may include information of one or more of: a type of the first operation, a name of the first operation, a timing for performing the first operation, and a target network node to which the first operation is to be applied.

Item [21]: The non-transitory computer-readable recording medium according to any one of items [15]-[20], wherein the information of the xApp may include a name of the xApp, information associated with the second operation, and information associated with the priority of the xApp; and wherein the information associated with the second operation may include information of one or more of: a type of the second operation, a name of the second operation, a timing for performing the second operation, and a target network node to which the second operation is to be applied.

[0120] It can be understood that numerous modifications and variations of the present disclosure are possible in light of the above teachings. It will be apparent that within the scope of the appended clauses, the present disclosures may be practiced otherwise than as specifically described herein.

Claims

What is claimed is:

1. A system comprising: a non-real-time (Non-RT) radio access network intelligent controller (RIC); and a near-real-time (Near-RT) RIC, wherein the Non-RT RIC comprises at least one application (rApp) and a first conflict management (CM) entity; wherein the Near-RT RIC comprises at least one application (xApp) and a second CM entity; wherein the first CM entity is configured to collect information of the rApp, and the first CM entity is configured to communicate with the second CM entity to provide information of the rApp thereto and to obtain information of the xApp therefrom; wherein the second CM entity is configured to collect information of the xApp, and the second CM entity is configured to communicate with the first CM entity to provide the information of the xApp thereto and to obtain information of the rApp therefrom; wherein the rApp is configured to obtain the information of the xApp from the first CM entity and to initiate a first operation thereafter; and wherein the xApp is configured to obtain the information of the rApp from the second CM entity and to initiate a second operation thereafter.

2. The system according to claim 1, wherein the rApp is configured to initiate the first operation by: determining, based on the information of the xApp, whether or not performing the first operation on a network node will cause a conflict with the second operation; based on determining that performing the first operation will not cause the conflict, performing the first operation on the network node; based on determining that performing the first operation will cause the conflict, determining whether or not the rApp has a higher priority than the xApp; and based on determining that the rApp has the higher priority than the xApp, performing the first operation on the network node.

3. The system according to claim 1, wherein the xApp is configured to initiate the second operation by: determining, based on the information of the rApp, whether or not performing the second operation on a network node will cause a conflict with the first operation; based on determining that performing the second operation will not cause the conflict, performing the second operation on the network node; based on determining that performing the second operation will cause the conflict, determining whether or not the xApp has a higher priority than the rApp; and based on determining that the xApp has the higher priority than the rApp, performing the second operation on the network node.

4. The system according to claim 2, wherein the rApp is further configured to: based on determining that performing the first operation on the network node will cause the conflict and that the rApp has a lower priority than the xApp, determine an alternative network node to which the first operation can be performed.

5. The system according to claim 3, wherein the xApp is further configured to: based on determining that performing the second operation on the network node will cause the conflict and that the xApp has a lower priority than the rApp, determine an alternative network node to which the second operation can be performed.

6. The system according to claim 1, wherein the information of the rApp comprises a name of the rApp, information associated with the first operation, and information associated with the priority of the rApp; and wherein the information associated with the first operation comprises information of one or more of: a type of the first operation, a name of the first operation, a timing for performing the first operation, and a target network node to which the first operation is to be applied.

7. The system according to claim 1, wherein the information of the xApp comprises a name of the xApp, information associated with the second operation, and information associated with the priority of the xApp; and wherein the information associated with the second operation comprises information of one or more of: a type of the second operation, a name of the second operation, a timing for performing the second operation, and a target network node to which the second operation is to be applied.

8. A method comprising: collecting, by a first conflict management (CM) entity associated with a non-real- time (Non-RT) radio access network intelligent controller (RIC), information of at least one application (rApp) associated with the Non-RT RIC; providing, by the first CM entity, information of the rApp to a second CM entity associated with a near-real-time (Near-RT) RIC; collecting, by the second CM entity, information of at least one application (xApp) associated with the Near-RT RIC; providing, by the second CM entity, information of the xApp to the first CM entity; obtaining, by the rApp from the first CM entity, information of the xApp; initiating, by the rApp, a first operation after receiving the information of the xApp; obtaining, by the xApp from the second CM entity, information of the rApp; and initiating, by the xApp, a second operation after receiving the information of the rApp.

9. The method according to claim 8, wherein the initiating the first operation comprises: determining, based on the information of the xApp, whether or not performing the first operation on a network node will cause a conflict with the second operation; based on determining that performing the first operation will not cause the conflict, performing the first operation on the network node; based on determining that performing the first operation will cause the conflict, determining whether or not the rApp has a higher priority than the xApp; and based on determining that the rApp has the higher priority than the xApp, performing the first operation on the network node.

10. The method according to claim 8, wherein the initiating the second operation comprises: determining, based on the information of the rApp, whether or not performing the second operation on a network node will cause a conflict with the first operation; based on determining that performing the second operation will not cause the conflict, performing the second operation on the network node; based on determining that performing the second operation will cause the conflict, determining whether or not the xApp has a higher priority than the rApp; and based on determining that the xApp has the higher priority than the rApp, performing the second operation on the network node.

11. The method according to claim 9, further comprises: based on determining that performing the first operation on the network node will cause the conflict and that the rApp has a lower priority than the xApp, determining an alternative network node to which the first operation can be performed.

12. The method according to claim 10, further comprises: based on determining that performing the second operation on the network node will cause the conflict and that the xApp has a lower priority than the rApp, determining an alternative network node to which the second operation can be performed.

13. The method according to claim 8, wherein the information of the rApp comprises a name of the rApp, information associated with the first operation, and information associated with the priority of the rApp; and wherein the information associated with the first operation comprises information of one or more of: a type of the first operation, a name of the first operation, a timing for performing the first operation, and a target network node to which the first operation is to be applied.

14. The method according to claim 8, wherein the information of the xApp comprises a name of the xApp, information associated with the second operation, and information associated with the priority of the xApp; and wherein the information associated with the second operation comprises information of one or more of: a type of the second operation, a name of the second operation, a timing for performing the second operation, and a target network node to which the second operation is to be applied.

15. A non-transitory computer-readable recording medium having recorded thereon instructions executable by a device to cause the device to perform a method comprising: collecting, by a first conflict management (CM) entity associated with a non-real- time (Non-RT) radio access network intelligent controller (RIC), information of at least one application (rApp) associated with the Non-RT RIC; providing, by the first CM entity, information of the rApp to a second CM entity associated with a near-real-time (Near-RT) RIC; collecting, by the second CM entity, information of at least one application (xApp) associated with the Near-RT RIC; providing, by the second CM entity, information of the xApp to the first CM entity; obtaining, by the rApp from the first CM entity, information of the xApp; initiating, by the rApp, a first operation after receiving the information of the xApp; obtaining, by the xApp from the second CM entity, information of the rApp; and initiating, by the xApp, a second operation after receiving the information of the rApp.

16. The non-transitory computer-readable recording medium according to claim 15, wherein the initiating the first operation comprises: determining, based on the information of the xApp, whether or not performing the first operation on a network node will cause a conflict with the second operation; based on determining that performing the first operation will not cause the conflict, performing the first operation on the network node; based on determining that performing the first operation will cause the conflict, determining whether or not the rApp has a higher priority than the xApp; and based on determining that the rApp has the higher priority than the xApp, performing the first operation on the network node.

17. The non-transitory computer-readable recording medium according to claim 15, wherein the initiating the second operation comprises: determining, based on the information of the rApp, whether or not performing the second operation on a network node will cause a conflict with the first operation; based on determining that performing the second operation will not cause the conflict, performing the second operation on the network node; based on determining that performing the second operation will cause the conflict, determining whether or not the xApp has a higher priority than the rApp; and based on determining that the xApp has the higher priority than the rApp, performing the second operation on the network node.

18. The non-transitory computer-readable recording medium according to claim 16, wherein the method further comprises: based on determining that performing the first operation on the network node will cause the conflict and that the rApp has a lower priority than the xApp, determining an alternative network node to which the first operation can be performed.

19. The non-transitory computer-readable recording medium according to claim 17, wherein the method further comprises: based on determining that performing the second operation on the network node will cause the conflict and that the xApp has a lower priority than the rApp, determining an alternative network node to which the second operation can be performed.

20. The non-transitory computer-readable recording medium according to claim 15, wherein the information of the rApp comprises a name of the rApp, information associated with the first operation, and information associated with the priority of the rApp; wherein the information associated with the first operation comprises information of one or more of: a type of the first operation, a name of the first operation, a timing for performing the first operation, and a target network node to which the first operation is to be applied; wherein the information of the xApp comprises a name of the xApp, information associated with the second operation, and information associated with the priority of the xApp; and wherein the information associated with the second operation comprises information of one or more of: a type of the second operation, a name of the second operation, a timing for performing the second operation, and a target network node to which the second operation is to be applied.