Conflict Mitigation in O-RAN: Conflict Detection, Resolution, and Avoidance

Our previous post on this topic [1] focused on conflict categorization between O-RAN RIC Applications. A classification into direct, indirect, and implicit conflicts was introduced. Direct conflicts occur when two xApps have different objectives and each attempts to achieve its own goals, resulting in contradictory actions. An indirect conflict occurs when decisions from xApps do not involve conflicting commands of the same type but instead involve different types of decisions that still affect the same part of the network. Implicit conflicts are more complex because they do not stem solely from contradictory commands. It can be triggered by an outdated decision that affects current network behavior, leading to offloading or degradation of Quality of Service (QoS). Knowledge about the various types of conflicts provides a solid background that allows for the design of Conflict Mitigation (CM), which aims to deal with them to minimize their impact on the underlying network.

This blog post delves into Conflict Mitigation, as outlined in the O-RAN ALLIANCE’s Technical Report (TR) [2], which serves as a research study exploring available solutions, ideas, and recommendations. It indicates the direction in which a target solution can be developed. Based on the TR, the following CM modules are described: Conflict Detection (CD), Conflict Resolution (CR), and Conflict Avoidance (CA). The next sections present each of these three modules in detail, along with potential solutions and examples.

Conflict Mitigation Modules

As mentioned above, the O-RAN ALLIANCE TR suggests a CM framework consisting of three modules: CD, CR, and CA (see Fig. 1). These modules belong to the Near-RT RIC architecture and utilize its functionalities, such as collecting metrics or sending control commands through the E2 interface. Moreover, the CM framework should coordinate xApps’ operation by analyzing, filtering, or adjusting their decisions before execution, to ensure stable and uninterrupted network operation. These modules follow a hierarchical coordination model: CD identifies conflicts and forwards relevant insights to CR, while CA acts as a supervisory function, overseeing decisions and message flows to guide overall network performance optimization.

The CM components’ functionality is detailed below:

• Conflict Detection (CD) is a function aimed at detecting potential and actual direct, indirect, and implicit conflicts. Accurate CD is a key component for conflict resolution and prevention. To design an effective CD, comprehensive context information and metrics are required. As an example, ping-pong handover count can serve as an indicator of potential—even implicit—conflicts [6]. Another example involves analyzing E2AP control messages – if two xApps issue contradictory commands (e.g., conflicting transmission power adjustments), this may signal a control conflict [7]. The CD module should have insight into messages exchanged over the E2 interface, like E2SM-RC/CCC/KPM, with a specific emphasis on control messages [3]. Since conflicts most often arise from or occur between control procedures, these messages should be carefully monitored.
• Conflict Resolution (CR) is a module responsible for resolving conflicts between xApps. Each xApp may have different logic and objectives, which may drive collisions between them and lead to inconsistent network behavior. CR should collaborate closely with the CD module in a way that when a conflict is detected, the CR module analyzes its impact on network performance and determines a strategy to resolve it. CR can prioritize xApps [6], adjust control parameters, or suspend conflicting xApps, if needed.  
• Conflict Avoidance (CA) is a proactive mechanism within the Near-RT RIC designed to prevent conflicts between xApps before they occur. The CA module facilitates simultaneous work by gathering metrics, analyzing historical data, and drawing conclusions about how xApps can influence network behavior. After processing this information, it provides guidance and recommendations to xApps to ensure their coordinated and consistent actions. For example, an xApp that has previously generated many conflicts can be suspended to avoid similar issues in the future. Alternatively, historical data can be used to predict the potential impact of decisions made by a given xApp on the generation of conflicts.

To sum up, CD identifies issues between xApps, the CR solves them to maintain stable network behavior, and the CA module prevents future conflicts through proactive analysis and guidance. The next sections explain each of these components in more detail, including possible solutions and implementation approaches.

Example Solutions for Conflict Detection

This section introduces selected approaches and suggested solutions based on [2], providing general methods and ideas for implementing CD mechanisms. The basic feature of the CD module is presented in Fig. 2.

One of the basic methods provided by [2] for detecting direct conflicts is based on E2AP. In this approach, the Near-RT RIC relies only on general message details such as E2 Node ID, RAN Function ID, and Action Type ID [3]. This limited scope, however, often leads to false conflict detections, especially when different xApps configure the same RAN Function using different service models or parameters. In other words, a conflict may be detected simply because two xApps interact with the same network element, even if their actions do not interfere. To improve accuracy and reduce such false positives, the use of E2SM information is introduced, as it provides deeper insight into the specific configurations and control actions performed by each xApp.

Another example is a post-action solution. In this approach, the CD module observes Key Performance Indicators (KPIs) after actions are taken by xApps. This enables detection of hidden and indirect conflicts; however, it requires more advanced logic and analysis, often involving AI/ML techniques, and can be implemented either as a CD xApp with analytical capabilities that performs the analysis and returns the results, or by a dedicated module within the Near-RT RIC. Applying this approach does not require knowledge of the internal logic of xApps; subject to analysis, providing the relevant KPIs is sufficient.

Another solution described in [2] involves detecting indirect conflicts preemptively. In this approach, the user provides the Near-RT RIC or CD xApp with configuration data that describes dependencies between RAN parameters, typically using a table or a graph. In cases where two different xApps modify different parameters via subscription or control procedures, their action may influence the same KPI, even if the parameters are directly unrelated. The CD module compares the received parameters against the predefined dependency configurations. Results are reported to xApps with information about potential conflicts. The key advantage of this solution is that it does not require KPI monitoring to detect a conflict, making it well-suited for identifying multiple indirect conflicts at once. However, its main limitation lies in the reliance on user-defined configuration data, which may be incomplete or subjective. 

Finally, a solution for detecting conflicts utilizing AI/ML algorithms or a digital twin is proposed in [2]. It can simulate the future impact of changing parameters on network conditions in real time. For example, a parameter set by xApp 1 may not degrade the KPI on its own, but when xApp 2 modifies other parameters, the combined effect leads to a degradation of the KPI. The AI/ML-based CD detects this interaction as a real conflict before execution, enabling proactive avoidance of conflicts.

Example Solutions for Conflict Resolution

Now that we have the conflicts detected and the responsible xApps identified, CR comes into play (see Fig. 3). This step focuses on analyzing the detected conflicts and selecting a strategy to resolve them. CR may be applied proactively or post-action, and can be generalized or tailored to specific conflict types.

Based on [2], CR can follow two approaches: xApps may reach an agreement independently or with assistance from the CR module, or the CR module may enforce a resolution at the E2AP or E2SM level and supervise its implementation.

At the E2AP level, agreements may define that multiple xApps must not use the same RIC service types for a given node or function. At the E2SM level, xApps may be ordered to avoid accessing certain conflicting RAN parameters or resources. Guidance-based agreements can also be introduced, requiring platform approval before accessing them. All agreements can be stored for reuse in future conflict scenarios.

One of the solutions for direct parameter conflict resolution involves indirect coordination: the platform or a CR xApp collects preferences from conflicting xApps and calculates a shared parameter value. This can be achieved using game-theoretic approaches that balance fairness and efficiency (see, e.g., [4]). This approach enables fair, privacy-preserving conflict resolution without revealing the internal logic of each xApp.

However, several challenges remain, such as whether the CR can enforce resolutions, how to handle failed negotiations, and how to protect the sensitive business logic of xApps during coordination. Additionally, the CM may not be able to resolve conflicts at the E2SM level independently, without access to xApp-specific knowledge. These issues highlight the need for further study and standardization. A promising direction could be the adoption of manifest-based coordination [8], where each xApp publishes a manifest explicitly declaring:

• RAN parameters it reads and modifies,
• events it subscribes to,
• and dependencies or conflicts it has with other applications.

Example Solutions for Conflict Avoidance

While CD and CR focus on active conflict detection and management, the CA module serves a proactive role (see Fig. 4). In detail, CA aims to prevent future conflicts before they occur, that is, before sending control messages (e.g., RIC Control Request) to the E2 Node. To support this process, CA utilizes information from the CD and CR modules.

For the CA operation, the standardized E2 Guidance procedure [3] may be used, where the xApp can send an E2 Guidance Request to the Near-RT RIC platform to check if its planned action might cause a conflict. The CA responds with an E2 Guidance Response, providing suggestions to avoid conflict. It can also send an E2 Guidance Modification to inform other xApps that may be involved.

CR analyzes prior requests (e.g., E2 Subscription, E2 Control) to detect potential conflicts at the E2SM level, where multiple xApps may target the same RAN function or parameter within a single E2 Node. Upon identifying a possible conflict, the CA module initiates a negotiation process to agree on a non-overlapping allocation of E2SM services, styles, or actions — either directly between xApps or indirectly through the platform itself. Once an agreement is reached, the outcome is stored by the CA and can be used in future requests to bypass repeated conflict checks. CA helps xApps operate within the Near-RT RIC while ensuring the safety of their actions or adjusting their behavior when necessary. It allows dynamic coordination between xApps and extends E2 Guidance with negotiation support.

Summary

This blog post examined CM mechanisms within the Near-RT RIC, focusing on how xApps can be coordinated through a three-module approach: CD, CR, and CA. These modules can be implemented as a separate CM xApp (or as three cooperating xApps) or integrated into the RIC platform. Effective operation requires interaction with interfaces like A1 and E2 to monitor decisions, adjust behavior, and maintain stability. As networks become more dynamic, CM should evolve from static rules to intelligent, ML-assisted coordination to manage conflicting objectives in real time.

Conflict mitigation within O-RAN is still an evolving part of the standardization process. While this post focused on conflict management at the Near-RT RIC level between xApps developed by WG3, WG2’s work covers conflict handling in the Non-RT RIC, focusing on policy management for the A1 interface [5].

References

[1] P. Skrzypczak, “Introduction to Conflict Mitigation in O-RAN: Categorization of Conflicts,” Rimedo Labs Blog, Mar. 18, 2025. [Online]. Available: https://rimedolabs.com/blog/introduction-to-conflict-mitigation-in-o-ran-categorization-of-conflicts/

[2] O-RAN Alliance, “Conflict Mitigation”, O-RAN.WG3.TR.ConMit-R004-v01.00, Work Group 3, Tech. Rep., October. 2024. [Online]. Available: https://specifications.o-ran.org/download?id=737

[3] O-RAN Alliance, “Near-Real-time RAN Intelligent Controller (Near-RT RIC) Architecture”, O-RAN.WG3.TS.RICARCH-R004-v07.00, Work Group 3, Tech. Spec., February. 2025. [Online]. Available: https://specifications.o-ran.org/download?id=813

[4] A. Wadud, F. Golpayegani, and N. Afraz, „Conflict Management in the Near-RT-RIC of Open RAN: A Game Theoretic Approach,” in Proc. IEEE CPSCom, 2023

[5] O-RAN Alliance, “Policy and Conflict Management”, O-RAN.WG2.TR.PlcCnfMtgt-R004-v01.00, Work Group 2 (Non-Real-time RIC and A1 Interface), Tech. Rep., June. 2025. [Online]. Available: https://specifications.o-ran.org/download?id=875

[6] C. Adamczyk and A. Kliks, „Detection and mitigation of indirect conflicts between xApps in Open Radio Access Networks,” in Proc. IEEE ICNI, May 2023

[7]M. Corici, R. Modroiu, F. Eichhorn, E. Troudt, and T. Magedanz, “Towards efficient conflict mitigation in the converged 6G Open RAN control plane,” Annals of Telecommunications, vol. 79, pp. 621–631, 2024.

[8] A. Kliks, M. Dryjanski, V. Ram, L. Wong, and P. Harvey, “Towards autonomous Open Radio Access Networks,” unpublished manuscript / technical report, 2023. [Online]. Available: itu.int/dms_pub/itu-s/opb/jnl/S-JNL-VOL4.ISSUE2-2023-A19-PDF-E.pdf

Acknowledgment

The author would like to thank Lukasz Kulacz, Marcin Hoffmann, and Marcin Dryjanski for their valuable comments provided during the writing process.

Author Bio