O-RAN RIC XAPP / RAPP competitive solution

Abstract

According to an exemplary embodiment, the system may include a non-RT RIC and a quasi-RT RIC. The non-RT RIC includes an rApp and a first conflict management (CM) entity, and the quasi-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 it with rApp information and to retrieve it with xApp information. Similarly, the second CM entity may be configured to communicate with the first CM entity to provide it with xApp information and to retrieve it with rApp information. The rApp and xApp may be configured to retrieve xApp information and rApp information from the relevant CM entities, respectively, and then initiate the relevant operations.

Description

TECHNICAL FIELD

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of priority of U.S. Provisional Patent Application No. 63 / 613,344, filed on December 21, 2023, the entire content of which is incorporated herein by reference.

[0002] The present disclosure relates to conflict resolution between xApps and / or rApps of a Radio Access Network (RAN) Intelligent Controller (RIC) in an Open Radio Access Network (O-RAN). BACKGROUND ART

[0003] The information disclosed in this Background Art section is only for the purpose of enhancing general understanding of the present disclosure and shall not be construed as an admission or any form of suggestion that this information forms prior art already known to those skilled in the art.

[0004] A Radio Access Network (RAN) is a critical component in telecommunication systems for connecting end user devices (or user equipment) to other parts of the network. The RAN includes a combination of various Network Elements (NE) that connect end users to a core network. Conventionally, the hardware and / or software of a specific RAN is vendor-specific.

[0005] Open RAN (O-RAN) technology emerged to enable multiple vendors to provide hardware and / or software to telecommunications systems. Because different vendors are involved, the types of hardware and / or software provided may also differ. That is, different types of Network Entities (NEs) may be provided by different vendors, and depending on the specific service, NEs may be virtualized and / or containerized in software form (e.g., virtual machine (VM) based, containerized network function (CNF) based, etc.) or in physical hardware form (e.g., non-VM based, non-CNF based, etc.). Therefore, O-RAN separates RAN functions into different entities such as central units (CUs), distributed units (DUs), and radio units (RUs). These entities can be developed by different vendors because they have open protocols and interfaces between them.

[0006] In an O-RAN architecture, RAN operation or functionality can be controlled and optimized by a RAN Intelligent Controller (RIC). The RIC may be a software-defined component that not only automates and optimizes RAN operation but also implements modular applications to facilitate the multi-vendor operability required by the O-RAN system. Generally, RICs can be divided into two types: non-real-time RICs (non-RT RICs) and quasi-real-time RICs (quasi-RT RICs). Both non-RT RICs and quasi-RT RICs can implement one or more applications to perform one or more desired operations. Applications implemented in non-RT RICs are referred to as rApps, and applications implemented in quasi-RT RICs are referred to as xApps. rApps and xApps can be developed by independent parties or vendors and then deployed on non-RT RICs and quasi-RT RICs. [Overview of the project] [Means for solving the problem]

[0007] Exemplary embodiments of this disclosure provide systems, apparatus, methods, etc., that effectively and efficiently resolve conflicts between the xApp and rApp of an O-RAN RIC.

[0008] According to an exemplary embodiment, the system includes a non-real-time (non-RT) radio access network intelligent controller (RIC) and a quasi-real-time (quasi-RT) RIC, wherein the non-RT RIC may include at least one application (rApp) and a first conflict management (CM) entity, and the quasi-RT RIC may include at least one application (xApp) and a second CM entity, the first CM entity may be configured to collect information of an rApp, the first CM entity may be configured to communicate with the second CM entity to provide information of the rApp to the second CM entity and to obtain information of the xApp from the second CM entity, the second CM entity may be configured to collect information of the xApp, the second CM entity may be configured to communicate with the first CM entity to provide information of the xApp to the first CM entity and to obtain information of the rApp from the first CM entity, the rApp may be configured to obtain information of the xApp from the first CM entity and then start a first operation, the xApp may be configured to obtain information of the rApp from the second CM entity and then start a second operation.

[0009] According to an exemplary embodiment, the method includes: a first conflict management (CM) entity associated with a non-real-time (non-RT) radio access network intelligent controller (RIC) collecting information of at least one application (rApp) associated with the non-RT RIC; the first CM entity providing the rApp information to a second CM entity associated with a quasi-real-time (quasi-RT) RIC; the second CM entity collecting information of at least one application (xApp) associated with the quasi-RT RIC; the second CM entity providing the xApp information to the first CM entity; the rApp obtaining the xApp information from the first CM entity; the rApp initiating a first operation after receiving the xApp information; the xApp obtaining the rApp information from the second CM entity; and the xApp initiating a second operation after receiving the rApp information.

[0010] According to an embodiment, a non-temporary computer-readable recording medium may record instructions executable by a device, the instructions causing the device to perform a method including: collecting information of at least one application (rApp) associated with a non-RT RIC by a first conflict management (CM) entity associated with a non-real-time (non-RT) radio access network intelligent controller (RIC); providing the rApp information to a second CM entity associated with a quasi-real-time (quasi-RT) RIC by the first CM entity; collecting information of at least one application (xApp) associated with the quasi-RT RIC by the second CM entity; providing the xApp information to the first CM entity by the second CM entity; obtaining the xApp information from the first CM entity by the rApp; initiating a first operation by the rApp after receiving the xApp information; obtaining the rApp information from the second CM entity by the xApp; and initiating a second operation by the xApp after receiving the rApp information.

[0011] Additional embodiments are partially described in the following description, partially evident from the description, or may be implemented by implementing the embodiments presented in this disclosure.

[0012] Features, aspects, and advantages of embodiments of this disclosure are described below with reference to the accompanying drawings, where similar reference numerals indicate similar elements. [Brief explanation of the drawing]

[0013] [Figure 1] This figure shows an O-RAN architecture to which one or more exemplary embodiments may be applied. [Figure 2] A block diagram shows an exemplary configuration of the interaction between rApp, xApp and their respective CM entities, according to one or more exemplary embodiments. [Figure 3] An example of a priority table is shown, based on one or more exemplary embodiments. [Figure 4] A flowchart shows an exemplary method for initiating operation, according to one or more exemplary embodiments. [Figure 5] This document illustrates exemplary embodiments of a device for implementing one or more exemplary embodiments. [Modes for carrying out the invention]

[0014] A detailed description of exemplary embodiments follows with reference to the accompanying drawings. The foregoing disclosure provides examples and descriptions, but is not intended to be exhaustive or to limit implementations to the exact forms disclosed. Modifications and variations are possible in light of the foregoing disclosure or can be obtained from implementations. Furthermore, 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). In addition, the flowcharts and descriptions of operation 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 correspond to the flowcharts and descriptions thereof. In other embodiments, it will be understood that one or more operations may be omitted, one or more operations may be added, and one or more operations may be performed (at least partially) simultaneously.

[0015] It will be apparent that the systems and / or methods described herein may be implemented in different forms of hardware, firmware, or combinations of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods is not limited to the implementation forms described. Therefore, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It should be understood that software and hardware may be designed to implement the systems and / or methods based on the descriptions herein.

[0016] While specific combinations of features are disclosed in the claims and / or herein, these combinations do not limit the disclosure of implementations. In fact, many of these features can be combined in ways not specifically described in the claims and / or disclosed herein. Each of the dependent claims listed below may depend directly on only one claim, but the disclosure of implementations includes each dependent claim combined with all other claims in the set of claims.

[0017] Any element, action, or instruction used herein should not be construed as important or essential unless expressly stated otherwise. Furthermore, where 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, where used herein, terms such as “has,” “have,” “having,” “include,” and “including” are intended to be open-ended terms. Furthermore, the phrase “based on” should mean “at least partially based on” unless otherwise specified. Additionally, expressions such as “at least one of [A] and [B],” “[A] and / or [B],” or “at least one of [A] or [B]” should be understood as including only A, only B, or both A and B.

[0018] It should be noted that the description of exemplary embodiments in this disclosure may include terms and names defined by one or more standardization bodies, such as the Third Generation Partnership Project (3GPP®), the European Telecommunications Standards Institute (ETSI), and the Open Radio Access Networks (O-RAN) Alliance. For example, terms such as “rApp,” “xApp,” “A1 interface,” “A1 policy,” “E2 interface,” “O1 interface,” and “O2 interface,” as well as related features and behaviors, should be interpreted as being consistent with those specified in one or more technical specifications.

[0019] Furthermore, while the exemplary embodiments of the Disclosure described herein relate to resolving conflicts between rApps and xApps, it is conceivable that these exemplary embodiments could also be used to resolve conflicts between multiple rApps and between multiple xApps without departing from the scope of the Disclosure.

[0020] As described above, in an open radio access network (O-RAN) architecture, RAN functionality can be decomposed into multiple logical nodes or entities, such as central units (CUs), distributed units (DUs), and radio units (RUs). For this purpose, the decomposed entities have open protocols and interfaces between them, and therefore can be developed by different vendors. Furthermore, RAN functionality may be controlled and optimized by RAN intelligent controllers (RICs), such as non-real-time RICs (non-RT RICs) and quasi-real-time RICs (quasi-RT RICs). A non-RT RIC may implement one or more applications referred to as rApps, and a quasi-RT RIC may implement one or more applications referred to as xApps. Each of the rApps and xApps may be developed and provided by different vendors.

[0021] Nevertheless, while the open architecture of O-RAN allows for flexibility among participants or vendors of RAN components or entities, it also introduces complexity and challenges in controlling the RAN. In particular, because multiple entities or components can be involved in configuring and executing RAN operations, control action conflicts can occur at many levels between different RAN components. Within a RIC, these conflicts can occur between rApps in a non-RT RIC, between xApps in a quasi-RT RIC, and between rApps(s) in a non-RT RIC and xApps(s) in a quasi-RT RIC. Furthermore, these conflicts can be categorized into different types, such as direct, indirect, and implicit conflicts.

[0022] Direct conflicts can be directly observed by the network system and can be mitigated by pre-operation adjustment. As an example, an rApp and an xApp may request different configurations for the same configuration of one or more parameters of a control target such as the same network node (a similar conflict may occur when two or more rApps / two or more xApps request different configurations for the same configuration of one or more parameters of the same control target). In this regard, the system may detect the conflict and determine a resolution (e.g., determining the order in which changes are applied).

[0023] Indirect conflicts cannot be directly observed, but can be anticipated by the network system. Specifically, the system may observe the parameters and resources of the target rApp(s) / xApp(s), and take actions to mitigate the indirect conflict when the conflict is anticipated. As an example, an indirect conflict may occur when a change required by an rApp (or xApp) has a system impact equivalent to a parameter change targeted by another rApp (or another xApp). In this regard, indirect conflicts can be resolved by post-action verification. Specifically, an action is performed, and the impact on the target component is observed. Based on the observation, the system may determine a potential correction (e.g., rolling back one of the actions).

[0024] Implicit conflicts cannot be directly observed, and even the dependencies between rApps and / or xApps are not obvious. As an example of an implicit conflict, rApps / xApps may optimize different metrics and manage different parameters. Nevertheless, optimizing one metric may have an implicit unintended side effect on one of the metrics optimized by another rApp / xApp. Because implicit conflicts are difficult (if not impossible) to observe, implicit conflicts are the most difficult to mitigate, and their solutions are difficult to model.

[0025] In view of the above, there is a need to provide a solution for all conflicts of the type described above, particularly implicit conflicts. Nevertheless, at the present time, methods for detecting or resolving all types of conflicts are not defined and specified in the ORAN technical specifications, as they are reserved for future research. Furthermore, while concepts and requirements for resolving conflicts between rApps and conflicts between xApps are recognized in the related art, resolution of conflicts between rApps and xApps has remained undefined and unspecified.

[0026] Exemplary embodiments of the present disclosure provide systems, methods, devices, and the like that efficiently and effectively provide resolution of all types of conflicts between rApps and xApps. Specifically, exemplary embodiments of the present disclosure introduce a Conflict Management (CM) entity in each of the non-RT RIC and the near-RT RIC, and each CM entity may be configured to continuously (or periodically) monitor active rApp(s) and xApp(s), and expose relevant information to the active (or selected) rApp(s) and xApp(s). Therefore, before taking any action, the rApp(s) and xApp(s) may refer to information of other active applications to determine or detect any potential conflict between the action to be performed and actions being performed by, or scheduled to be performed by, other applications, which effectively and efficiently mitigates conflicts therebetween. Further, in some exemplary embodiments, the rApp(s) and xApp(s) may determine an appropriate solution for any detected conflict(s) (e.g., determining an alternative network node that is capable of performing the intended action / operation, canceling / delaying the action to avoid conflict with a higher priority operation, etc.).

[0027] The features, advantages, and significance of the exemplary embodiments described above are only a part of this disclosure and are not intended to be exhaustive or to limit the scope of this disclosure. Further descriptions of the features, components, configurations, operations, and implementations of the exemplary embodiments of this disclosure are provided below. Exemplary system architecture

[0028] Figure 1 shows an O-RAN architecture to which one or more exemplary embodiments may be applied. As shown in Figure 1, the system architecture may include at least one service management and orchestration (SMO) framework 110, which includes at least one non-real-time RAN intelligent controller (non-RT RIC) 120, at least one quasi-real-time RIC (quasi-RT RIC) 130, at least one O-RAN central unit (O-CU) 140, at least one open evolutionary node B (O-eNB) 150, at least one O-RAN distributed unit (O-DU) 160, a plurality of O-RAN radio units (O-RU) 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, and the quasi-RT RIC 130 may further include at least one xApp 131 and a second CM entity 132. As will be further explained below, components can be coupled in a communicative manner to other components(s) via their respective interfaces(s).

[0029] The system architecture is intended to include more / fewer components than those illustrated and / or be configured in a different manner, without departing from the scope of this disclosure. For example, in some implementations, the system architecture may include multiple O-DU160s, each communicably coupled to an O-CU140, a non-RT RIC120 may include multiple rApps, a quasi-RT RIC130 may include multiple xApps, and so on.

[0030] Generally, an RIC may be a software-defined component that implements modular applications to facilitate multi-vendor operability and automate and optimize RAN operation. As shown in Figure 1, RICs can be divided into two types: non-RT RIC120 and quasi-RT RIC130. Below, the non-RT RIC120 will be described, followed by the quasi-RT RIC130.

[0031] The non-RT RIC120 can refer to a logical function within the SMO framework 110 that drives content delivered via the A1 interface to enable non-real-time control and optimization of RAN elements and resources. The A1 interface can refer to a logical interface between the non-RT RIC120 and the quasi-RT RIC130, enabling the non-RT RIC120 to provide policy-based guidance to the quasi-RT RIC130, and enabling the quasi-RT RIC130 to provide one or more feedbacks to the non-RT RIC120, thereby enabling the non-RT RIC120 to monitor the status or implementation form of one or more policies.

[0032] In some exemplary implementations, the non-RT RIC120 may be a control point in a non-real-time control loop and may operate on a timescale longer than one second within the SMO framework 110. Generally, the functions of the non-RT RIC120 may include, for example, providing policy-based guidance and enrichment via the A1 interface, performing data analysis, training and inference of artificial intelligence / machine learning (AI / ML) models for RAN optimization, and / or recommending configuration management actions. As further described below, the non-RT RIC120 may access or communicate with other SMO framework functions or components via the A1 interface, the O1 interface, the O2 interface, and one or more interfaces associated with one or more open fronthaul (O-FH) planes.

[0033] According to exemplary embodiments, the functionality of the non-RT RIC 120 may be implemented via at least one modular non-RT RIC application, such as rApp 121. rApp 111 can leverage the capabilities 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 analysis, and enrichment information provision. In some exemplary implementations, the non-RT RIC 120 may implement multiple rApp 121s.

[0034] According to an exemplary embodiment, a non-RT RIC120 (or its associated rApp121) may be configured to generate one or more policies and provide them to a quasi-RT RIC130 via the A1 interface, and may be configured to manage one or more policies provided to the quasi-RT RIC130 via the A1 interface. Such policies may be referred to herein as “A1 policies” and are declarative policies containing information applicable to one or more network nodes (e.g., one or more UEs, one or more network cells, etc.). One or more A1 policies may consist of a range identifier and one or more policy statements. The range identifier may represent the network node(s) (e.g., cell, UE, DU, etc.) to which the policy statement applies. 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. A non-RT RIC120 (or its associated rApp121) may provide one or more A1 policies to a quasi-RT RIC230, thereby providing the quasi-RT RIC230 with guidance toward one or more objectives or goals defined in the RAN intent. A RAN intent may refer to a high-level operational or business objective(s) that the RAN is to achieve, which may be defined by one or more desired service level agreements (SLAs) that the RAN is to satisfy for all users or subsets of users in a given area over a predetermined period of time.

[0035] According to an exemplary embodiment, a non-RT RIC120 (or its associated rApp121) may be configured to receive one or more feedbacks (hereinafter referred to as "A1 policy feedback") associated with one or more A1 policies from a quasi-RT RIC130 via the A1 interface. Similarly, a non-RT RIC120 (or its associated rApp121) may be configured to receive one or more observables (e.g., events, counters, etc.) provided by one or more of the O-CU140, O-DU160, and / or O-RU170 via the O1 interface. Thus, a non-RT RIC120 (or its associated rApp121) may be configured to manage one or more A1 policies sequentially (or periodically) based on the A1 policy feedback and / or observables provided via the O1 interface. For example, a non-RT RIC120 (or its associated rApp121) may continuously (or periodically) evaluate the impact or effectiveness of one or more A1 policies on achieving a RAN intent, and then configure or update one or more A1 policies accordingly.

[0036] According to an exemplary embodiment, rApp121 may include any appropriate type of application, such as an application associated with energy saving, an application associated with network configuration management, an application associated with policy management, or an application associated with network optimization. When rApp121 is first deployed or implemented, rApp121 may subscribe to or register with CM entity 122 and be assigned one or more priorities (e.g., by the network operator) when performing related actions or operations.

[0037] According to an exemplary embodiment, a non-RT RIC 120 may implement at least one conflict management (CM) entity 122. The CM entity 122 may include a database or a dashboard application (or a component implementing a dashboard application), or it may be implemented in the form of an rApp. The CM entity 122 may be configured to collect information associated with an rApp 121 (e.g., application name, current / past status, actions received, scheduled actions, action type, action name, policy change decision, associated priority, next update time, etc.) and then provide this information to other nodes or applications in a standardized manner. For example, the CM entity 122 may collect information from an rApp 121 and provide that information to a quasi-RT RIC 130.

[0038] In an exemplary embodiment, CM entity 122 may be configured to broadcast information of rApps that have subscribed to CM entity 122 or have exposed their information (e.g., existing tasks, priority / policy changes, scheduled actions, etc.). In this regard, CM entity 122 may be configured to broadcast or expose rApp information only to all rApps that have subscribed to it or to selected rApps (e.g., specific types of rApps). In this way, CM entity can be accessed by rApps (e.g., via an A1 interface) as part of a hardening procedure.

[0039] Furthermore, in exemplary embodiments where a non-RT RIC120 includes multiple rApps and / or a quasi-RT RIC130 includes multiple xApps, the CM entity 122 can share information of rApp 121 with the multiple rApps and / or multiple xApps in a standardized manner, so that all rApps / xApps can understand the content of the shared information and use it appropriately to determine potential conflicts with their own current / future actions(s).

[0040] According to an exemplary embodiment, CM entity 122 may receive requests from rApp 121 to publish or update relevant information. For example, CM entity 122 may receive a “write request” along with relevant information, such as priority, change request, expiration time, and override status. CM entity 122 may also similarly receive other types of requests, such as “read requests” to access and view information published by CM entity 122, “configuration lock requests” (described further below) to notify other network nodes that the configuration of a target network node should be locked, “cancel action requests” to cancel scheduled / pending actions, “cancel request orders” to define the order in which requests are canceled, and “configuration update requests” to update the configuration of a target network node. Furthermore, CM entity 122 may also receive one or more combinations of the above requests, such as “read / write requests” to publish relevant information and read the published information. Additionally, CM entity 122 may optionally publish requests to other network nodes. For example, CM entity 122 can expose a "configuration lock request" for the configured gNB / eNB / VNF / PNF level.

[0041] In an exemplary embodiment where the non-RT RIC120 includes multiple rApps, the CM entity 122 may receive requests from some (or all) of the existing rApps. In response, the CM entity 122 may provide responses only to the rApp that provided the request(s). For example, suppose the non-RT RIC120 includes three rApps A-C, and rAppA provides the CM entity 122 with a “write request” along with relevant information, and rApps B and C each provide the CM entity 122 with “read requests”. In this regard, the CM entity 122 can collect the information from rApp A and make that information available to rApps B and C.

[0042] According to exemplary embodiments, CM entity 122 may be configured to communicate (via an A1 interface, etc.) with CM entity 132 implemented in a quasi-RT RIC 130 (further described below) to provide information to rApp 121 and to obtain information to xApp 131 from there. In some exemplary implementations, CM entities 122 and 132 may synchronize with each other by periodically (or continuously) exchanging synchronization messages in real time (or near real time, such as on a millisecond timescale). The synchronization messages may include new or updated information collected by the CM entities, as well as requests from rApp / xApp, such as "configuration lock requests," if any.

[0043] According to exemplary embodiments, the CM entity 122 may include priority information for rApps implemented within the non-RT RIC 120. As further described below with reference to the example in Figure 3, the rApp priorities may be presented in a table format (which may be referred to herein as the “priority table”). In this case, the CM entity 122 may include a priority table containing rApp priority information, which may be provided by a user (e.g., a network operator) and updated periodically as needed. In some exemplary implementations, when a new rApp is first implemented in the non-RT RIC 120 and subscribes to the CM entity 122 (e.g., by sending a “write request” with relevant information such as name, application type, and assigned priority), the CM entity 122 may determine whether the new rApp has the same priority as any existing previously subscribed rApp. Therefore, based on the determination that the new rApp does not have the same priority as any of the existing rApps, CM entity 122 can update the priority table to include the priority information of the new rApp. On the other hand, based on the determination that the new rApp has the same priority as any of the existing rApps, CM entity 122 can notify the user (e.g., a network operator) by, for example, displaying an error message, so that the user can reconsider and reassign an appropriate priority to the new rApp or an existing rApp.

[0044] Referring further to Figure 1, in addition to communication with the quasi-RT-RIC130 via the A1 interface, the SMO framework 110 (and the non-RT RIC120 and / or rApp121 and CM entity 122 implemented therein) can communicate with the quasi-RT RIC130, O-CU140, O-eNB150, O-DU160, and / or O-RU170 (or more) via the O1 interface. In this regard, the O1 interface can refer to a logical interface between the SMO framework 110, the quasi-RT RIC 130, the O-CU 140, the O-eNB 150, the O-DU 160, and the O-RU(or O-RU) 170, thereby enabling the SMO framework 110 (and the non-RT RIC 120 and rApp 121 implemented therein) to provide the quasi-RT RIC 130, the O-CU 140, the O-eNB 150, the O-DU 160, and the O-RU(or O-RU) 170 with Fault, Configuration, Accounting, Performance, and Security (FCAPS), as well as other management operations such as network monitoring and network discovery. Additionally, the O1 interface enables quasi-RT RIT120 (or its associated rApp121) to provide information or observables that can be used by non-RT RIT120 (or its associated rApp121), such as for managing one or more A1 policies or for training one or more AI / ML models.

[0045] Furthermore, the SMO framework 110 (and the non-RT RIC 120 and / or rApp 121 and CM entity 122 implemented therein) can communicate with the O-cloud 180 via the O2 interface. In this regard, the O2 interface can refer to a logical interface between the SMO framework 110 and the O-cloud 180, which may be a collection of physical RAN nodes hosting the non-RT RIC 120, quasi-RT RIC 130, O-CU 140, and O-DU 160, supporting software components (e.g., operating system and runtime environment), and the SMO framework 110 itself. In other words, the SMO framework 110 can manage the O-cloud 180 from within, and the O2 interface can be the interface between the SMO framework 110 and the O-cloud 180 in which it resides. Through the O2 interface, the SMO framework 110 (and the non-RT RIC 120 and / or rApp 121 implemented therein) can provide infrastructure management services (IMS) and deployment management services (DMS) to the O-cloud 180.

[0046] Furthermore, the SMO framework 110 (and the non-RT RIC 120 and / or rApp 121 and CM entity 122 implemented therein) can also communicate with the O-RU(or O-RU) 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 (and the non-RT RIC 120 and / or rApp 121 implemented therein) to perform one or more FCAPS operations on the O-RU(or O-RU) 170.

[0047] Next, we will describe the quasi-RT RIC130. The quasi-RT RIC130 can refer to a logical function that enables near real-time control and optimization of RAN elements and resources. For example, the quasi-RT RIC130 can provide near real-time control and optimization through fine-grained (e.g., UE-based, cell-based, etc.) data acquisition and actions via the E2 interface. In some exemplary implementations, the quasi-RT RIC130 may operate on a timescale between 10 milliseconds and 1 second and may be coupled to the O-CU140, O-eNB150, and O-DU160 via the E2 interface. The quasi-RT RIC130 may use the E2 interface to control lower-level network nodes or RAN elements (e.g., E2 nodes, network functions (NFs), etc.) via a quasi-real-time control loop.

[0048] According to an exemplary embodiment, the quasi-RT RIC130 may be configured to perform one or more energy-saving operations, such as switching cells / carriers on / off or handing over users from one cell to another, based on one or more A1 policies provided by the non-RT RIC120. Furthermore, the quasi-RT RIC130 can monitor, interrupt / stop, override, and control E2 nodes (e.g., O-CU140, O-DU160, etc.) by utilizing one or more A1 policies. For example, the quasi-RT RIC230 can receive one or more A1 policies (e.g., energy-saving policies) from the non-RT RIC120 (or its associated rApp121), and then interpret the received A1 policies to determine one or more control operations (e.g., energy-saving operations) or one or more policy commands. In some exemplary implementations, upon receiving an A1 policy(s), the quasi-RT RIC130 can collect one or more measurement data from one or more E2 nodes (e.g., O-CU140, O-eNB150, O-DU160, etc.) via the E2 interface, and then determine one or more subsequent control actions (e.g., by performing artificial intelligence (AI) / machine learning (ML) inference based on the received A1 policy(s) and the collected measurement data, etc.). The quasi-RT RIC130 may then generate one or more control messages (e.g., cell / carrier switch on / off messages) and send them to one or more E2 nodes and / or O-RU170. Thus, the E2 nodes and / or O-RU(s) may be configured to update their associated configurations to perform one or more actions to switch cells or carriers on / off.

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

[0050] According to an exemplary embodiment, xApp131 may include any appropriate 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 wireless link monitoring, an application associated with traffic steering, an application associated with load balancing, an application associated with policy management, or an application associated with interference management. Similar to rApp121, when xApp131 is first deployed or implemented, xApp131 may subscribe to or register with CM entity 132 and be assigned one or more priorities (e.g., by the network operator) when performing related actions or operations.

[0051] According to an exemplary embodiment, a quasi-RT RIC 130 may implement at least one CM entity 132. Similar to CM entity 122, CM entity 132 may include a database or dashboard application (or a component that implements a dashboard application), or may be implemented in the form of an xApp. CM entity 132 may be configured to collect information associated with xApp 131 (e.g., application name, current / past status, actions received, scheduled actions, action type, action name, policy change decision, associated priority, next update time, etc.) and then provide that information to other nodes or applications in a standardized manner. As an example, CM entity 132 may collect information from xApp 131 and then provide that information to a non-RT RIC 120.

[0052] In an exemplary embodiment, CM entity 132 may be configured to broadcast information of xApps that have subscribed to CM entity 132 or have exposed their information (e.g., existing tasks, priority / policy changes, scheduled actions, etc.). In this regard, CM entity 132 may be configured to broadcast or expose xApp information to all xApps that have subscribed to it, or to selected xApps (e.g., specific types of xApps) only. Thus, CM entity 132 can be accessed by xApps (e.g., via the A1 interface) as part of a hardening procedure.

[0053] Furthermore, in exemplary embodiments where a non-RT RIC120 includes multiple rApps and / or a quasi-RT RIC130 includes multiple xApps, the CM entity 132 may share information of xApp 131 with the multiple rApps and / or multiple xApps in a standardized manner so that all rApps / xApps can understand the content of the shared information and use it appropriately to determine any potential conflicts with their own current / future actions(s).

[0054] According to an exemplary embodiment, CM entity 132 may receive requests from xApp 131 to publish or update relevant information. For example, CM entity 132 may receive a “write request” along with relevant information, such as priority, change request, expiration time, and override status. CM entity 132 may also similarly receive other types of requests, such as “read requests” to access and view information published by CM entity 132, “configuration lock requests” (described further below) to notify other network nodes that the configuration of a target network node should be locked, “cancel action requests” to cancel scheduled / pending actions, “cancel request orders” to define the order in which requests are canceled, and “configuration update requests” to update the configuration of a target network node. Furthermore, CM entity 132 may also receive one or more combinations of the above requests, such as “read / write requests” to publish relevant information and read the published information. Additionally, CM entity 132 may optionally publish requests to other network nodes. For example, CM entity 132 can expose a "configuration lock request" for the configured gNB / eNB / VNF / PNF level.

[0055] In an exemplary embodiment where the quasi-RT RIC 130 includes multiple xApps, the CM entity 132 may receive requests from some (or all) of the existing xApps. In response, the CM entity 132 may provide responses only to the xApp that provided the request(s). For example, suppose the quasi-RT RIC 130 includes three xApps D through F, and xApp D provides the CM entity 132 with a “write request” along with relevant information, and xApps E and F each provide the CM entity 132 with “read requests”. In this case, the CM entity 132 can collect the information from xApp D and make that information available to xApps E and F.

[0056] According to exemplary embodiments, CM entity 132 may be configured to communicate (via the A1 interface, for example) with CM entity 122 implemented on a non-RT RIC 120 to provide information on xApp 131 and to obtain information on rApp 121. As described above, in some exemplary implementations, CM entities 132 and 122 may synchronize with each other by periodically (or continuously) exchanging synchronization messages in real time (or near real time, such as on a millisecond timescale).

[0057] According to an exemplary embodiment, the CM entity 132 may include priority information for xApps implemented within the quasi-RT RIC 130. As further described below with reference to the example in Figure 3, the priority of xApps may be presented in a priority table. In this case, the CM entity 132 may have a priority table containing the priority information of xApps, which may be provided by a user (e.g., a network operator) and updated periodically as needed.

[0058] In some exemplary implementations, when a new xApp is first implemented on the quasi-RT RIC130 and subscribes to the CM entity 132 (for example, by sending a “write request” along with relevant information such as name, application type, and assigned priority), the CM entity 132 may determine whether the new xApp has the same priority(s) as any existing previously subscribed xApp. Therefore, based on the determination that the new xApp does not have the same priority(s) as any of the existing xApps, the CM entity 132 can update the priority table to include the priority information of the new xApp. On the other hand, based on the determination that the new xApp has the same priority(s) as any of the existing xApps, the CM entity 132 can notify the user (e.g., a network operator) by, for example, presenting an error message, so that the user can reconsider and reassign an appropriate priority(s) to the new or existing xApp.

[0059] Next, we will describe O-CU140, O-eNB150, O-DU160, and O-RU170. Generally, O-CU140, O-DU160, and O-RU170 can be used to configure base stations such as 5G NR gNodeB (gNB), Next Generation Radio Access Network (NG-RAN) nodes, and 6G network base stations. On the other hand, O-eNB150 may refer to a 4G LTE version of an O-RAN compliant node (for example, an eNB compliant with the O-RAN architecture).

[0060] Communication between O-CU140 and O-DU160 may be performed via the F1 interface, and communication between O-DU160 and O-RU170 may be performed via one or more O-FH control (C), user (U), synchronization (s), and management (M) plane interfaces. In some exemplary implementations, the C, U, and S planes are integrated and referred to as the “CUS plane”. According to exemplary embodiments, the system may include multiple O-DU160s, and O-CU140 may be communicably coupled to multiple O-DUs via the F1 interface. Similarly, the system may include multiple O-RU170s, and O-DU(plural)160 may be communicably coupled to multiple O-RUs via one or more of the O-FH C / U / S / M plane interfaces.

[0061] According to exemplary embodiments, O-CU140 and O-DU160 may be defined in software form and deployed on one or more network nodes. For example, O-CU140 and O-DU160 may be deployed on one or more servers in the form of virtualized network functions (VNFs), containerized and / or cloud-native functions (CNFs). According to exemplary embodiments, O-CU140 and O-DU160 may be deployed in the same network node (e.g., the same server) and / or located in similar geographical locations (e.g., deployed in different servers in the same data center). According to exemplary embodiments, O-CU140 and O-DU160 may be deployed in different network nodes and / or located in different geographical locations. For example, the O-CU140 may be deployed in one or more central servers (i.e., servers in one or more central data centers), and the O-DU160 may be deployed in one or more edge servers (i.e., servers in one or more edge data centers).

[0062] The O-DU160 can receive radio signals from end users (via one or more UEs and one or more cells) and, accordingly, provide operation or support to lower layers of the protocol stack (e.g., RLC layer, MAC layer, physical layer, etc.). As an example, the O-DU160 can perform one or more scheduling operations. The O-CU140 can communicatively couple the O-DU160 to a core network (e.g., a 4G evolved packet core (EPC) network, a 5G core network, etc.), receive radio signals from the O-DU160, and thereby provide operation or support to higher layers of the protocol stack (e.g., PDCP layer, RRC layer, etc.).

[0063] According to an exemplary embodiment, 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 a logical node that hosts or implements the control plane portions of the RRC and PDCP protocols and may be responsible for managing signaling between the core network and the wireless network, session management, wireless bearer control, and mobility management. The O-CU-UP 142, on the other hand, may refer to a logical node that hosts or implements the user plane portions of the PDCP and SDAP protocols and may be responsible for managing data traffic and the transmission of user data packets. The O-CU-CP 141 and the O-CU-UP 142 may be connected to each other via an E1 interface.

[0064] Furthermore, a single O-DU160 may host or service multiple network cells formed by multiple O-RU170s. According to exemplary embodiments, the O-DU160 can implement various wireless technologies, such as multiple-input multiple-output (MIMO) and beamforming, to optimize wireless communication between multiple cells and the O-CU140. In some exemplary implementations, the O-DU160 may simultaneously host or service hundreds (e.g., 512) cells at once.

[0065] O-RU(or O-RU)170 may be a physical node that converts radio signals from an antenna into digital signals that can be transmitted to an O-DU160 via the fronthaul. In this regard, the network cell described herein may correspond to one or more radio units that play a role in providing radio coverage and signal transmission within the network cell. The network cell may include macrocells, microcells, picocells, femtocells, and / or any other suitable type of network cell. Each cell may have an associated coverage area in which at least one O-RU170, at least one antenna system, and any other suitable type of transport network element (TNE) may be deployed.

[0066] According to an exemplary embodiment, O-DU160 may be configured to control or instruct the associated O-RU(or O-RU) via one or more O-FH C / U / S / M plane interfaces. For example, O-DU160 can instruct O-RU(or O-RU)170 to enter shutdown or sleep mode via the O-FH C / U / S plane interface. On the other hand, capability exchange between O-DU160 and O-RU(or O-RU)170 can be performed via the O-FH M plane interface. As an example, O-RU(or O-RU)170 can inform O-DU160 of the amount of time required to maintain sleep mode (or off mode) to conserve energy.

[0067] In consideration of the foregoing, exemplary embodiments of this disclosure provide an effective and efficient solution for resolving conflicts between RIC applications (e.g., rApps and xApps) in an O-RAN. Specifically, a CM entity within the RIC may effectively and efficiently share or expose information about rApps and xApps, and the rApps and xApps may use the shared information to determine potential conflicts and then appropriately resolve them. Thus, by leveraging a CM entity within the RIC, it is possible to provide an effective and efficient resolution of conflicts within the O-RAN while reducing the exposure of each rApp / xApp's internal work (i.e., operational "know-how") to other network components (which is undesirable in an O-RAN because rApps and xApps may be provided by different vendors) and reducing the use of central resources for determining and resolving conflicts (since conflicts are detected and resolved by the rApps / xApps themselves, rather than by centralized conflict mitigation functions as proposed in related technologies). Exemplary operation and use cases

[0068] As described above, exemplary embodiments of this disclosure implement at least one conflict management (CM) entity in each non-RT RIC and quasi-RT RIC, thereby providing conflict resolution for the O-RAN RIC. The following provides a description of exemplary operation and associated use cases.

[0069] Figure 2 shows a block diagram of an exemplary configuration of interactions between rApps, xApps, and their respective CM entities, according to one or more exemplary embodiments. The example in Figure 2 involves the non-RT RIC120 (and rApp121 and CM entity 122 implemented therein) and the quasi-RT RIC130 (and xApp131 and CM entity 132 implemented therein) from Figure 1. For illustrative purposes, CM entity 122 may also be referred to as the “first CM entity,” and CM entity 132 may also be referred to as the “second CM entity.”

[0070] As shown in Figure 2, the first CM entity 122 may be configured to collect information on rApp121, then communicate with the second CM entity 132 to provide the information on rApp121, and from there retrieve information on xApp131. On the other hand, the second CM entity 132 may be configured to collect information on xApp131, then communicate with the first CM entity 122 to provide the information on xApp131, and from there retrieve information on rApp121.

[0071] According to one embodiment of the present invention, the information of rApp121 may include the name of rApp121, information associated with a first operation performed or to be performed by rApp121, and information associated with the priority of rApp121. In this regard, the information associated with the first operation may include information associated with one or more of the following: 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, and the target network node to which the first operation is applied or to which it should be applied. In some exemplary embodiments, the information associated with rApp121 may include a primary priority associated with the type of rApp121 and a secondary priority associated with one or more characteristics of rApp121, such as information, resource consumption (e.g., CPU, memory, etc.), and performance (e.g., efficiency, latency, throughput, etc.).

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

[0073] The exchange of rApp / xApp information can be performed in any appropriate order (for example, information from xApp131 is shared with rApp121 first, or information from both rApp121 and xApp131 is shared with each other simultaneously). According to an exemplary embodiment, xApp131 may operate on a shorter time scale or time window than rApp121 (for example, xApp131 may operate on a millisecond time scale, while rApp121 operates on a seconds time scale). Thus, the second CM entity 132 may provide or update information from xApp131 to rApp121 more frequently than the first CM entity 131.

[0074] After receiving information about other active applications, rApp121 and xApp131 can initiate their respective operations based on that information. Illustrative operations associated with this are described below with reference to Figure 4.

[0075] Next, Figure 3 shows an example of a priority table according to one or more exemplary embodiments. In this example, the priority table includes priority information for three rApps (i.e., rApp1-3) and three xApps (i.e., xApp1-3).

[0076] As shown in Figure 3, both rApp1 and xApp1 are applications associated with energy saving and are therefore assigned the same primary priority of "1". Additionally, rApp1 has a secondary priority of "1.1", and xApp1 has a secondary priority of "1.2". As a result, although rApp1 and xApp1 have the same primary priority, rApp1 has a higher secondary priority and therefore a higher priority than xApp1. In this example, rApp1 is assigned a higher secondary priority because the user (i.e., the network operator) prioritizes application performance in terms of energy saving (e.g., efficiency) rather than resource consumption (e.g., CPU usage). Since the user prioritizes network energy saving above all else, both rApp1 and xApp1 have higher priority than other applications.

[0077] A similar explanation applies to the remaining rApps and xApps. Therefore, the application priorities in Figure 3 are such that rApp1 has the highest priority among all rApps and xApps, followed by xApp1, rApp2, rApp3, xApp2, and xApp3 (i.e., priority: rApp1 > xApp1 > rApp2 > rApp3 > xApp2 > xApp3).

[0078] The priority table in Figure 3 is intended to be merely a simplified example for illustrative purposes. In actual implementations, the priority table may contain more / fewer rApps and xApps, the number of primary and secondary priorities may be more / fewer, the priority of each application may be configured and assigned by the user (e.g., network operator) according to their respective requirements, and secondary priorities may be presented in the format "1A" instead of "1.1," and so on.

[0079] Referring next to Figure 4, which shows a flowchart of an exemplary method 400 for initiating an operation according to one or more exemplary embodiments. One or more operations of method 400 may be performed by rApp121 and / or xApp131 (as described above with reference to Figures 1 and 2) after receiving information from other active applications. In some exemplary implementations in which rApp121 / xApp131 is implemented in hardware (e.g., a server), one or more operations of method 400 may be performed by a hardware component (e.g., the server's processor when executing computer-readable instructions stored in the server's memory).

[0080] Referring to Figure 4, in operation S410, the rApp / xApp may be configured to determine whether performing a related operation on the target network node will cause a conflict with the operation(s) of another application. For example, rApp121 can determine whether performing a first operation on the network node will cause a conflict with a second operation that is performed or will be performed by xApp131. Similarly, xApp131 can determine whether performing a second operation on the network node will cause a conflict with a first operation that is performed or will be performed by rApp121.

[0081] Specifically, the rApp / xApp can first determine whether those intended actions(s) apply to (or will apply to) the same network node. Therefore, based on the determination that the actions(s) apply to (or will apply to) the same network node, the rApp / xApp can determine whether the actions(s) will have an undesirable effect. For example, the rApp / xApp can determine whether performing those actions(s) would be contrary to the purpose of other ongoing actions(s) on the network node or other scheduled actions(s) applied to the network node. Subsequently, based on the determination that performing the relevant actions(s) would have an undesirable effect, the rApp / xApp can determine that a potential conflict(s) will occur. According to an exemplary embodiment, the rApp / xApp can perform action S410 based on the xApp / rApp information provided by each CM entity.

[0082] Based on the determination that performing the relevant operations on the target network node would cause a conflict, method 400 can proceed to operation S420. Otherwise, method 400 can proceed to operation S430, where, because there is no potential conflict, rApp / xApp can be configured to perform those related operations(s). For example, based on the determination that performing the first operation would not cause a conflict, rApp121 may perform the first operation on the network node. Similarly, based on the determination that performing the second operation would not cause a conflict, xApp131 may perform the second operation on the network node. In this case, both the first and second operations are performed on the network node without causing a conflict.

[0083] On the other hand, in operation S420, based on the determination that performing the relevant operation on the target network node would cause a conflict, the rApp / xApp may be configured to determine whether the relevant priority is higher than that of the conflicting application(s). For example, based on the determination that performing the first operation would cause a conflict with a second operation that is performed or will be performed by xApp131, rApp121 can determine whether rApp121 has a higher priority than xApp131. Similarly, based on the determination that performing the second operation would cause a conflict with a first operation that is performed or will be performed by rApp121, xApp131 can determine whether xApp131 has a higher priority than rApp121. According to an exemplary embodiment, the rApp / xApp can perform operation S420 based on the priority information of the conflicting application(s) provided by each CM entity.

[0084] Based on determining that the relevant priority is higher than that of any competing application(s), method 400 can return to operation S430, where the rApp / xApp can be configured to perform those relevant operations(s) on the target network node. Otherwise, method 400 may terminate or be terminated, and the rApp / xApp will not perform those relevant operations(s).

[0085] In this regard, when the first action of rApp121 has a potential conflict with the second action of xApp131, rApp121 can perform the first action on the network node, while xApp131 does not, based on the determination that rApp121 has a higher priority than xApp131. Similarly, xApp131 can perform the second action on the network node, while rApp121 does not perform the first action, based on the determination that xApp131 has a higher priority than rApp121. In this way, the rApp / xApp with the higher priority can perform the relevant action(s) without causing any conflict.

[0086] According to an alternative embodiment, based on the determination that the associated priority is not higher than that of the competing application(s), method 400 can proceed to operation S440, where rApp / xApp (having a lower priority than the competing application(s)) can be configured to determine (determine) an alternative network node on which the associated operation(s) can be performed. For example, based on the determination that performing a first operation on a network node would cause a conflict and that rApp121 has a lower priority than xApp131, rApp121 can determine an alternative network node on which the first operation can be performed. Similarly, based on the determination that performing a second operation on a network node would cause a conflict and that xApp131 has a lower priority than rApp121, xApp131 can determine an alternative network node on which the second operation can be performed.

[0087] The process of determining an alternative network node may include obtaining information about available network nodes, selecting a new target network node from among the available network nodes, obtaining information about active applications to determine whether running an operation on the new target network node would cause a conflict, and then running the operation 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 re-selecting another alternative network node (if a conflict is detected and the rApp / xApp has a lower priority than the conflicting application(s)). In this way, whenever an application(s) detects a potential conflict(s) that requires the application(s) to change its target network node, the application(s) can iteratively determine an alternative network node on which the associated application(s) can run.

[0088] Next, a description of several use cases in which exemplary embodiments of this disclosure may be implemented is provided. For convenience of explanation, these use cases may include the components described above with reference to Figures 1 to 4. Furthermore, consider the following use cases assuming that rApp121 is an application associated with energy saving and xApp131 is an application associated with traffic steering, and that rApp121 and xApp131 are assigned priorities according to the priority table in Figure 3 (i.e., rApp121 has a higher priority than xApp131).

[0089] In the first use case, xApp131 has already triggered and executed one or more traffic steering actions on network node A (e.g., node E2). The actions and state of xApp131 are provided to a second CM entity 132, which synchronizes this information with the first CM entity 122. In this case, rApp121 determines, based on the information published by the first CM entity 122, that the same network node A may be a candidate for an energy-saving action.

[0090] Therefore, rApp121 may expose a request to the first CM entity 122 such as a request message: "Network node A, energy saving, priority 1, trigger action: action X, action trigger time: T+5", where T is the current time and "+5" is a pre-configured mandatory action time (i.e., the time at which the action must be performed), which can be measured in any appropriate unit (for illustrative purposes, we can assume that the time to trigger the action in this exemplary use case is "T+5s").

[0091] Subsequently, the first CM entity 122 may synchronize this information with the second CM entity 132, and the second CM entity 132 may provide this information to xApp 131. In this regard, since rApp 121 is assigned a higher priority (because it is associated with energy saving), xApp 131 understands that it can no longer be a candidate for a "traffic steering" action until 5 seconds later, when the same network node A receives a new notification about the same node (such as a notification that the action associated with rApp 121 has finished), or until this internal threshold reaches "X%" and forces and triggers a request to override the action of rApp 121. Because xApp131 operates on a smaller timescale than rApp121 (i.e., xApp131 operates on a millisecond timescale, while rApp121 operates on a seconds timescale), rApp121 does not perform energy-saving actions for the next 5 seconds, and no contention occurs within these 5 seconds, so xApp131 can still perform traffic steering actions within 5 seconds from the current time.

[0092] In the following use case, both rApp121 and xApp131 wanted to perform related operations (or multiple operations) simultaneously on the same network node A. For example, xApp131 requested that traffic be steered towards network node A because the related network traffic was low, while rApp121 requested that the number of cores in network node A be reduced, also because the related network traffic was low. This information is collected and exposed by both the first CM entity 122 and the second CM entity 132 and provided to both rApp121 and xApp131. In this case, since rApp121 has a higher priority, rApp121 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 network node A (i.e., network node A can only be configured by rApp121) and notify xApp131 not to apply any changes to network node A (for example, by sending a "cancel request command" along with the information about network node A).

[0093] Considering the above, rApp121 and xApp131 can obtain information about other active applications from their respective CM entities before performing any action or operation. Therefore, rApp121 and xApp131 can effectively and efficiently predict or detect potential conflicts before performing their operations, and can mitigate potential or existing conflicts by identifying potential solutions (e.g., performing the intended operation on another network node, canceling a scheduled operation so that a higher-priority operation is not affected). Examples of system hardware components

[0094] One or more components of the system in the exemplary embodiment (e.g., rApp121, first CM entity 122, xApp131, second CM entity 132, etc.) and their associated operations may be implemented in one or more devices or hardware components, such as one or more servers. The following provides a description of devices in which the exemplary embodiment may be implemented.

[0095] Figure 5 shows one embodiment of device 500. As shown in Figure 5, device 500 may include a processor 510, memory 520, storage component 530, input component 540, output component 550, communication interface 560, and bus 570.

[0096] When used herein, processor 510 means any type of computing circuit which may include hardware and software elements. Processor 510 may be embodied as a multicore processor, a single-core processor, a combination of one or more multicore processors and / or one or more single-core processors, a distributed processing system, and so on. Processor 510 may also be a central processing unit (CPU), a graphics processing unit (GPU), an aerial processing unit (APU), an application-specific integrated circuit (ASIC), or other type of processing component.

[0097] Memory 520 includes a non-temporary computer-readable medium. Memory 520 includes random access memory (RAM), read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, and / or optical memory) for storing information and / or instructions used by the processor 510. Memory 520 includes machine-readable instructions that can be executed by the processor 510. When these machine-readable instructions are executed by the processor 510, they cause the processor 510 to perform one or more method steps of the embodiments described above.

[0098] The storage component 530 stores information and / or software related to the operation and use of device 500. For example, the storage component 530 may include hard disks (e.g., magnetic disks, optical disks, magneto-optical disks, and / or solid-state disks), compact disks (CDs), digital multipurpose disks (DVDs), floppy disks, cartridges, magnetic tapes, and / or other types of non-temporary computer-readable media, along with their corresponding drives.

[0099] The input component 540 is configured to receive information such as user input. For example, the input component 540 may include, but is not limited to, a touchscreen display, keyboard, keypad, mouse, buttons, switches, and / or a microphone. Additionally or alternatively, the input component 540 may include sensors for sensing information (e.g., a Global Positioning System (GPS), accelerometer, gyroscope, and / or actuator).

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

[0101] The communication interface 560 is an interface that provides communication connections to other devices, such as external and internal devices. Connections via the communication interface 560 can be wired, wireless, or a combination of wired and wireless connections, and can be direct connections without a communication network between device 500 and other devices, or indirect connections via such a communication network. In other words, the specifications for the communication interface 560 are not limited.

[0102] Bus 570 functions as an interconnection between the processor 510, memory 520, storage component 530, input component 540, output component 550, and communication interface 560 of device 500. Bus 570 may include wired interconnections or wireless interconnections.

[0103] The number and arrangement of components shown in Figure 5 are provided as an example. In practice, device 500 may include additional components, fewer components, different components, or components arranged differently compared to those shown in Figure 5. Additionally or alternatively, a set of components of device 500 (e.g., one or more components) may perform one or more functions described as being performed by another set of components of device 500. Furthermore, one or more method steps described in any of the embodiments may be performed using multiple devices 500 communicating with each other. Various embodiments

[0104] The exemplary embodiments described above with reference to Figures 1 to 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.

[0105] Specifically, the above disclosures provide examples and explanations, but are not intended to be exhaustive or to limit implementations to the exact forms disclosed. Modifications and variations are possible in light of the above disclosures or can be derived from the implementations.

[0106] Some embodiments may relate to devices (e.g., network nodes, servers, etc.), systems, methods, and / or computer-readable media in integration at any possible level of technical detail. Furthermore, one or more of the 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 computer-readable non-temporary storage media (or more media) having computer-readable program instructions for causing a processor to perform an operation.

[0107] A computer-readable storage medium can be a tangible device capable of holding and storing instructions for use by an instruction-executing device. A computer-readable storage medium may, but is not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer diskettes, hard disks, random-access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), electrically erasable programmable read-only memory (EEPROM), static random-access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital multipurpose disks (DVDs), memory sticks, floppy disks, mechanically encoded devices such as punch cards or grooved raised structures on which instructions are recorded, and any suitable combination thereof. The computer-readable storage media used herein should not be construed as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses passing through optical fiber cables), or transient signals themselves, such as electrical signals transmitted through wires.

[0108] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device, or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface within each computing / processing device receives computer-readable program instructions from the network and transfers the computer-readable program instructions for storage on a computer-readable storage medium within each computing / processing device.

[0109] Computer-readable program code / instructions for performing an operation may be either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk® and C++, and procedural programming languages ​​such as the C programming language or similar programming languages.

[0110] Computer-readable program instructions can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or wide area network (WAN), or it may be connected to an external computer (for example, via the Internet using an Internet service provider). In some embodiments, electronic circuits, including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), can execute computer-readable program instructions by personalizing the electronic circuit using state information of the computer-readable program instructions to perform a manner or operation.

[0111] These computer-readable program instructions may be provided to a general-purpose computer, a dedicated computer, or a processor of another programmable data processing device to create a machine, so as to create means for implementing functions / operations specified in one or more blocks of a flowchart and / or block diagram, through instructions executed via the processor of a computer or other programmable data processing device. These computer-readable program instructions may also be stored in a computer-readable storage medium that can instruct computers, programmable data processing devices, and / or other devices to function in a particular way, thereby the computer-readable storage medium on which the instructions are stored constitutes a product containing instructions that implement modes of functions / operations specified in one or more blocks of a flowchart and / or block diagram.

[0112] Computer-readable program instructions may also be loaded into a computer, another programmable device, or another device to create a computer implementation process that executes a set of operational steps on the computer, another programmable data processing device, or another device, so that the instructions executed on the computer, another programmable data processing device, or another device implement a function / operation specified in one or more blocks of a flowchart and / or block diagram.

[0113] The flowcharts and block diagrams in the figures illustrate the architecture, functions, and operation of possible implementations of systems, methods, and computer-readable media according to various embodiments. In this regard, each block in a flowchart or block diagram may represent a module, segment, or part of an instruction containing one or more executable instructions for implementing a specified logical function(s). Methods, computer systems, and computer-readable media may include additional blocks, fewer blocks, different blocks, or blocks arranged differently from those shown in the figures. In some alternative implementations, the functions described in the blocks may be performed in an order different from the order shown in the figures. For example, two consecutively shown blocks may actually be executed simultaneously or substantially simultaneously, or blocks may sometimes be executed in reverse order depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in a block diagram and / or flowchart, may be implemented by a dedicated hardware-based system that performs a specified function or operation, or a combination of dedicated hardware and computer instructions.

[0114] It will be apparent that the systems and / or methods described herein may be implemented in different forms of hardware, firmware, or combinations of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods is not limited to the implementation form. Therefore, although 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 descriptions herein.

[0115] In consideration of the foregoing, various further aspects and features of the embodiments of this disclosure may be defined by the following items. Item [1]: The system includes a non-real-time (non-RT) radio access network intelligent controller (RIC) and a quasi-real-time (quasi-RT) RIC, wherein the non-RT RIC may include at least one application (rApp) and a first conflict management (CM) entity, and the quasi-RT RIC may include at least one application (xApp) and a second CM entity, the first CM entity may be configured to collect information of an rApp, the first CM entity may be configured to communicate with the second CM entity to provide information of the rApp to the second CM entity and to obtain information of the xApp from the second CM entity, the second CM entity may be configured to collect information of the xApp, the second CM entity may be configured to communicate with the first CM entity to provide information of the xApp to the first CM entity and to obtain information of the rApp from the first CM entity, the rApp may be configured to obtain information of the xApp from the first CM entity and then start a first operation, the xApp may be configured to obtain information of the rApp from the second CM entity and then start a second operation. Item [2]: The system described in Item [1], which may be configured to initiate a first operation by: determining, based on information from xApp, whether performing a first operation on a network node would conflict with a second operation; performing a first operation on the network node based on the determination that performing a first operation would not conflict; determining, based on the determination that performing a first operation would conflict, whether rApp has a higher priority than xApp; and performing a first operation on the network node based on the determination that rApp has a higher priority than xApp. Item [3]: The system described in Item [1], which may be configured to initiate a second operation by: determining, based on information from rApp, whether performing a second operation on a network node would conflict with a first operation; performing a second operation on the network node based on the determination that performing a second operation would not conflict; determining, based on the determination that performing a second operation would conflict, whether xApp has a higher priority than rApp; and performing a second operation on the network node based on the determination that xApp has a higher priority than rApp. Item [4]: ​​The system described in Item [2], wherein rApp may be further configured to determine an alternative network node on which the first operation can be performed, based on the determination that performing the first operation on a network node would cause a conflict and that rApp has a lower priority than xApp. Item [5]: The system described in Item [3], wherein the xApp may be further configured to determine an alternative network node on which the second operation may be performed, based on the determination that performing the second operation on a network node would cause a conflict and that the xApp has a lower priority than the rApp. Item [6]: A system described in any one of items [1] to [5], wherein the information of the rApp may include the name of the rApp, information associated with the first action, and information associated with the priority of the rApp, and the information associated with the first action may include the type of the first action, the name of the first action, the timing of when the first action will be performed, and information about one or more of the target network nodes to which the first action will be applied. Item [7]: The system described in any one of items [1] to [6], wherein the xApp information may include the name of the xApp, information associated with the second action, and information associated with the priority of the xApp, and the information associated with the second action may include the type of the second action, the name of the second action, the timing of when the second action will be performed, and information on one or more of the target network nodes to which the second action will be applied. Item [8]: The method includes: a first conflict management (CM) entity associated with a non-real-time (non-RT) radio access network intelligent controller (RIC) collecting information of at least one application (rApp) associated with the non-RT RIC; the first CM entity providing the rApp information to a second CM entity associated with a quasi-real-time (quasi-RT) RIC; the second CM entity collecting information of at least one application (xApp) associated with the quasi-RT RIC; the second CM entity providing the xApp information to the first CM entity; the rApp obtaining the xApp information from the first CM entity; the rApp initiating a first operation after receiving the xApp information; the xApp obtaining the rApp information from the second CM entity; and the xApp initiating a second operation after receiving the rApp information. Item [9]: The method of Item [8], wherein initiating a first operation may include: determining, based on information of xApp, whether performing the first operation on a network node would cause a conflict with a second operation; performing the first operation on the network node based on the determination that performing the first operation would not cause a conflict; determining, based on the determination that performing the first operation would cause a conflict, whether rApp has a higher priority than xApp; and performing the first operation on the network node based on the determination that rApp has a higher priority than xApp. Item

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

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

[12] : The method according to Item

[10] , further comprising determining an alternative network node on which the second operation may be performed, based on the determination that performing the second operation on a network node would cause a conflict and that xApp has a lower priority than rApp. Item

[13] : The method described in any one of items [8] to

[12] , wherein the information of the rApp may include the name of the rApp, information associated with the first action, and information associated with the priority of the rApp, and the information associated with the first action may include the type of the first action, the name of the first action, the timing of when the first action will be performed, and information on one or more of the target network nodes to which the first action will be applied. Item

[14] : The method described in any one of items [8] to

[13] , wherein the information of the xApp may include the name of the xApp, information associated with the second action, and information associated with the priority of the xApp, and the information associated with the second action may include the type of the second action, the name of the second action, the timing of when the second action will be performed, and information on one or more of the target network nodes to which the second action will be applied. Item

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

[16] : The non-temporary computer-readable recording medium described in Item

[15] , initiating a first operation may include: determining, based on information from xApp, whether performing the first operation on a network node would cause a conflict with a second operation; performing the first operation on the network node based on the determination that performing the first operation would not cause a conflict; determining, based on the determination that performing the first operation would cause a conflict, whether rApp has a higher priority than xApp; and performing the first operation on the network node based on the determination that rApp has a higher priority than xApp. Item

[17] : The non-temporary computer-readable recording medium described in Item

[15] , initiating a second operation may include: determining, based on information from rApp, whether performing the second operation on a network node would conflict with the first operation; performing the second operation on the network node based on the determination that performing the second operation would not conflict; determining, based on the determination that performing the second operation would conflict, whether xApp has a higher priority than rApp; and performing the second operation on the network node based on the determination that xApp has a higher priority than rApp. Item

[18] : The method further comprises determining an alternative network node on which the first operation may be performed, based on the determination that performing the first operation on a network node would cause a conflict and that rApp has a lower priority than xApp, as described in Item

[16] . Item

[19] : The non-temporary computer-readable recording medium described in Item

[17] , further comprising determining an alternative network node on which the second operation may be performed, based on the determination that performing the second operation on a network node would cause a conflict and that xApp has a lower priority than rApp. Item

[20] : A non-temporary computer-readable recording medium as described in any one of items

[15] to

[19] , wherein the information of the rApp may include the name of the rApp, information associated with a first action, and information associated with the priority of the rApp, and the information associated with a first action may include information about the type of the first action, the name of the first action, the timing of when the first action will be performed, and information about one or more target network nodes to which the first action will be applied. Item

[21] : A non-temporary computer-readable recording medium as described in any one of items

[15] to

[20] , wherein the information of the xApp may include the name of the xApp, information associated with a second action, and information associated with the priority of the xApp, and the information associated with a second action may include information on the type of second action, the name of the second action, the timing of when the second action will be performed, and information on one or more of the target network nodes to which the second action will be applied.

[0116] In light of the above teachings, it can be seen that numerous modifications and variations of this disclosure are possible. Within the scope of the appended claims, it will be apparent that this disclosure may be carried out in ways other than those specifically described herein.

Claims

1. It is a system, Non-real-time (non-RT) wireless access network intelligent controller (RIC), This includes quasi-real-time (quasi-RT) RIC, The non-RT RIC includes at least one application (rApp) and a first conflict management (CM) entity. The aforementioned quasi-RT RIC includes at least one application (xApp) and a second CM entity, The first CM entity is configured to collect information on the rApp, and the first CM entity is configured to communicate with the second CM entity to provide the rApp information to the second CM entity and to obtain the xApp information from the second CM entity. The second CM entity is configured to collect information on xApp, and to communicate with the first CM entity to provide the xApp information to the first CM entity and to obtain the rApp information from the first CM entity. The rApp is configured to obtain the information of the xApp from the first CM entity and then start the first operation. The xApp is configured to obtain information from the rApp from the second CM entity and then initiate a second operation.

2. The aforementioned rApp is, Based on the information of xApp, it is determined whether performing the first operation on the network node will cause a conflict with the second operation. Based on the determination that performing the first operation will not cause the conflict, the first operation is performed on the network node, Based on the determination that performing the first operation causes the conflict, it is determined whether the rApp has a higher priority than the xApp, Based on the determination that rApp has a higher priority than xApp, the first operation is performed on the network node. The system according to claim 1, configured to initiate the first operation by means of the above.

3. The aforementioned xApp is, Based on the information of the rApp, it is determined whether performing the second operation on the network node will cause a conflict with the first operation. Based on the determination that performing the second operation will not cause the conflict, the second operation is performed on the network node, Based on the determination that performing the second operation would cause the conflict, it is determined whether xApp has a higher priority than rApp, Based on the determination that xApp has a higher priority than rApp, the second operation is performed on the network node. The system according to claim 1, configured to initiate the second operation by means of the above.

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

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

6. The information of the rApp includes the name of the rApp, information associated with the first operation, and information associated with the priority of the rApp. The information associated with the first operation includes the type of the first operation, the name of the first operation, the timing of the first operation, and information on one or more target network nodes to which the first operation is applied. The system according to claim 1.

7. The information of xApp includes the name of xApp, information associated with the second operation, and information associated with the priority of xApp. The information associated with the second operation includes the type of the second operation, the name of the second operation, the timing of the second operation, and information on one or more target network nodes to which the second operation is applied. The system according to claim 1.

8. It is a method, A first conflict management (CM) entity associated with a non-real-time (non-RT) radio access network intelligent controller (RIC) collects information about at least one application (rApp) associated with the non-RT RIC, The first CM entity provides the rApp information to a second CM entity associated with a quasi-real-time (quasi-RT) RIC, The second CM entity collects information on at least one application (xApp) associated with the quasi-RT RIC, The second CM entity provides the information of xApp to the first CM entity, The rApp is used to obtain the xApp information from the first CM entity, After receiving the information from xApp via rApp, the first operation is initiated. The xApp is used to obtain the rApp information from the second CM entity. A method comprising: receiving the information from rApp via xApp, and then starting a second operation.

9. The commencement of the first operation is Based on the information of xApp, it is determined whether performing the first operation on the network node will cause a conflict with the second operation. Based on the determination that performing the first operation will not cause the conflict, the first operation is performed on the network node, Based on the determination that performing the first operation causes the conflict, it is determined whether the rApp has a higher priority than the xApp, The method according to claim 8, comprising: performing the first operation on the network node based on the determination that the rApp has a higher priority than the xApp.

10. The commencement of the second operation is Based on the information of the rApp, it is determined whether performing the second operation on the network node will cause a conflict with the first operation. Based on the determination that performing the second operation will not cause the conflict, the second operation is performed on the network node, Based on the determination that performing the second operation would cause the conflict, it is determined whether xApp has a higher priority than rApp, The method according to claim 8, comprising: performing the second operation on the network node based on the determination that xApp has a higher priority than rApp.

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

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

13. The information of the rApp includes the name of the rApp, information associated with the first operation, and information associated with the priority of the rApp. The information associated with the first operation includes the type of the first operation, the name of the first operation, the timing of the first operation, and information on one or more target network nodes to which the first operation is applied. The method according to claim 8.

14. The information of xApp includes the name of xApp, information associated with the second operation, and information associated with the priority of xApp. The information associated with the second operation includes the type of the second operation, the name of the second operation, the timing of the second operation, and information on one or more target network nodes to which the second operation is applied. The method according to claim 8.

15. A non-temporary computer-readable recording medium that records instructions executable by a device, wherein the instructions are recorded on the device, A first conflict management (CM) entity associated with a non-real-time (non-RT) radio access network intelligent controller (RIC) collects information about at least one application (rApp) associated with the non-RT RIC, The first CM entity provides the rApp information to a second CM entity associated with a quasi-real-time (quasi-RT) RIC, The second CM entity collects information on at least one application (xApp) associated with the quasi-RT RIC, The second CM entity provides the information of xApp to the first CM entity, The rApp is used to obtain the xApp information from the first CM entity, After receiving the information from xApp via rApp, the first operation is initiated. The xApp is used to obtain the rApp information from the second CM entity. A non-temporary computer-readable recording medium that causes xApp to perform a method including, after receiving the information from rApp, to start a second operation.

16. The commencement of the first operation is Based on the information of xApp, it is determined whether performing the first operation on the network node will cause a conflict with the second operation. Based on the determination that performing the first operation will not cause the conflict, the first operation is performed on the network node, Based on the determination that performing the first operation causes the conflict, it is determined whether the rApp has a higher priority than the xApp, The non-temporary computer-readable recording medium according to claim 15, comprising: performing the first operation on the network node based on the determination that the rApp has a higher priority than the xApp.

17. The commencement of the second operation is Based on the information of the rApp, it is determined whether performing the second operation on the network node will cause a conflict with the first operation. Based on the determination that performing the second operation will not cause the conflict, the second operation is performed on the network node, Based on the determination that performing the second operation would cause the conflict, it is determined whether xApp has a higher priority than rApp, The non-temporary computer-readable recording medium according to claim 15, comprising: performing the second operation on the network node based on the determination that the xApp has a higher priority than the rApp.

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

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

20. The information of the rApp includes the name of the rApp, information associated with the first operation, and information associated with the priority of the rApp. The information associated with the first operation includes the type of the first operation, the name of the first operation, the timing of the first operation, and information on one or more target network nodes to which the first operation is applied. The information of xApp includes the name of xApp, information associated with the second operation, and information associated with the priority of xApp. The information associated with the second operation includes the type of the second operation, the name of the second operation, the timing of the second operation, and information on one or more target network nodes to which the second operation is applied. The non-temporary computer-readable recording medium according to claim 15.

Images