Introduction to Conflict Mitigation in O-RAN: Categorization of Conflicts

O-RAN architecture consists, among other building blocks, of RAN Intelligent Controllers (RICs). The RICs are divided into near-real-time and non-real-time versions where third-party apps may be implemented. xApps are applications dedicated to Near Real-Time RIC (being part of the RAN) and rApps for Non Real-Time RIC (hosted in the management plane). The installation of multiple xApps and rApps within a single RIC introduces some challenges. Both xApps and rApps may be developed by multiple vendors, potentially yielding issues in the compatibility and proper functioning of the network. One App can influence the overall environment and disrupt the decision-making process of another App. This situation occurs because they may have different objectives. Thus, a Conflict Mitigation (CM) functionality was introduced to minimize this kind of impact. One of the key parts of CM is conflict detection. Based on observation, it can decide whether the conflict will be resolved, a compromise will be made, or the conflict can persist if it does not affect the network significantly. To mitigate conflicts properly, the advanced detection and classification conflict approach is typically used.

This blog post introduces the topic of conflict mitigation in O-RAN. At first, we discuss possible scenarios of conflicts, between decisions from Apps located at different or the same RIC. We then zoom into the Near-RT RIC and analyze types of conflicts between xApps. Finally, we discuss the impact of conflicts on the O-RAN network.

Category of Conflicts

Within the RICs, the conflicts can be divided into different categories. Higher-level conflicts may occur between messages from Apps located in different RICs, and lower-level conflicts can occur within a single Near-Real Time RIC or Non-Real Time RIC. Each type of conflict carries potential challenges, like unpredictable behavior of RAN or worsening the performance of the network. However, not all conflicts are equally severe, and in some cases, they can be left unaddressed.

The first type of classification divides the conflicts into vertical and horizontal. Vertical conflicts appear between decisions from Apps installed in RICs located at different levels in the architecture. Namely, this type of conflict occurs between decisions of an xApp and rApp. As an example, an xApp located at the Near-RT RIC acts against a policy or works contradictory to a decision of an rApp located in the Non-RT RIC.

Conflicts that occur at the same level in the O-RAN architecture (i.e., within the same RIC) are called horizontal. For example, conflicts in a decision can arise between xApps within the same Near-RT RIC or across two Near-RT RICs. Conflict between decisions from xApps located in different RICs is possible when RAN nodes are located nearby [1]. Based on horizontal conflicts we can recognize intra-RIC-conflicts (e.g., xApp 1 and xApp 2 are deployed inside the same Near-RT RIC or rApp 1 and rApp 2 deployed inside the same Non-RT RIC) or inter-RIC conflicts involving conflicting Apps in same-level RICs but in different parts of the network located close to each other [2]. Potential conflicts between the Apps decisions are shown in the picture shown below (Fig. 1).

Type of Conflicts

Zooming in the Near-RT RIC only, another classification of conflicts between xApps categorized by the O-RAN ALLIANCE [3] splits them into: direct, indirect, and hidden.

Direct Conflicts – These can be observed directly. A direct conflict occurs when two or more xApps want to change the same control parameters. Undetached contradictory control commands lead to the RAN’s unpredictable behavior. For example, in the context of handovers, xApp 1 wants to assign UE 1(User Equipment) to cell 1, simultaneously, xApp 2 decides to assign the same user to cell 2 (see Fig. 2). In such a case, one option may be that both decisions will be executed, both only the latest decision will be taken into account [1].

Another potential conflict occurs with the execution of policy, where one xApp aims to achieve a load lower than some threshold, while another xApp has set a different threshold.  A potential source of conflict can invoked by the limited resources available, as each cell has a finite amount of resources. For example, a cell has 100 PRB (Physical Resource Blocks). In this case, xApp 1 wants to assign 50 PRB to slice 1, meanwhile xApp 2 wants to assign 60 PRB to slice 2. However, the total available resources in the cell are limited to 100 PRBs, which makes this allocation impossible and leads to a resource conflict. In the presence of undetected conflicts, incorrect conclusions about xApps works may be drawn [3]. Potentially the simplest solution to conflicting decisions is prioritization, i.e., a preaction resolution, but this approach is not optimal. A more appropriate approach suggests trying to get closer to optimal configuration, based on higher-level metrics such as outage or power consumption, which help estimate impact on the solution used [4].

Indirect Conflicts – a situation with this type of conflict occurs when modifying parameters that are completely different but may have an impact on the same metrics. Even if two xApps control different parameters, their actions can indirectly impact each other. For instance, xApp 1 modifies parameters with antenna tilt, while xApp 2 changes Cell Individual Offset (CIO). Both xApps have an impact on the handover boundary, which leads to contradicting work of xApps.

Another example is the tandem of Interference Management xApp (IM) and Load Balancing xApp (LB). IM xApp is designed to minimize co-channel interference between neighboring cells. LB xApp leads to offload traffic to neighboring cells to achieve better Quality of Service (QoS). Meanwhile, IM xApp aims to minimize interference, reduce power, and change frequency, which can weaken the signal level. LB xApp detects a lower signal level and will try to assign a user to another cell with a better signal. It leads to “ping-pong” effects – users may be transferred between cells back and forth [2].

This type of conflict may be hard to observe directly. To detect it, additional information (metrics) from the network will be required such as outage, QoS, energy consumption, etc. [1].

Implicit Conflicts – here, the dependencies between conflicting xApps are not obvious. Different xApps can optimize different metrics and parameters which leads to implicit and unwanted results. The decision of xApp 1 is not favorable for xApp 2. An example of conflicting xApp is described below.

Assume, there are two xApps. The xApps have different optimization goals. There is an Energy Efficiency xApp (EE xApp) that aims to minimize energy consumption depending on optimization goals and requirements provided by the operator. It can be achieved by switching off cells or RF chains in a Massive MIMO panel. Simultaneously, a Slice Management xApp (SM xApp) strives to provide high resource utilization. In Fig. 3 the conflict between the EE xApp and SM xApp is depicted.

Both xApps will influence the throughput experienced by the users. Due to the deactivation of cell 2 and assigning slice 3 to cell 1, SM xApp cannot achieve the appropriate amount of resources. The tandem of these xApps focuses on different objectives but impacts the same KPI – throughput [2].  Implicit conflicts can, e.g., lead to triggering “ping-pong” handovers between cells and inefficient radio resource utilization. This type of conflict is the most difficult to detect and mitigate, it cannot be observed directly [1].

Impact of Conflicts (Why We Need Conflict Mitigation)

The above categorization is an analytical and structural nature of conflicts, it is treated as a starting point for the engineering of detection and mitigation approaches. Below you can find example metrics to evaluate conflicts by the operators [2]:

• Severity – allows operators to evaluate the importance of conflicts.  A key aspect is assessing the severity of the conflicts based on stability, performance, and cost-effectiveness. Depending on timescales, different aspects can be more important. For algorithms operating in real-time or near real-time scales, stability will be the main criterion, while algorithms operating in non-real-time scales focus on overall effectiveness. Operators need to develop appropriate time-solved conflict management to achieve goals e.g., QoS, an appropriate level of interference, or, more importantly, minimize the negative effects of conflicts [2]. It is worth mentioning that not all conflicts must be resolved; if some conflicts do not severely impact the network, they can be left untouched, but constantly monitored because this area is susceptible to conflicts under unfavorable conditions.

• Reach – conflicts in the network should be measured in terms of how they spread and affect different parts of the system. There are two ways to look at this: one focuses on how conflicts impact physical areas served by the network, and the other looks at how they spread through the network’s components, such as radio units (RUs), distributed units (DUs), centralized units (CUs), the RICs, and core network (CN) elements. These conflicts can affect the overall connectivity or performance, impacting communication between components, causing delays, or leading to network congestion. Both perspectives are necessary for operators to create an effective risk management strategy [2].

• Vulnerability creation – conflicts between xApps and rApps can become new vulnerabilities to attack.  AI-based network management routines may be manipulated by malevolent attackers. To avoid these problems operators may apply proactive solutions, for example, AI/ML sensitivity analyzed in Network Digital Twin (NDT) [2].

• Effectiveness of conflict detection – a complex problem, deriving information on how many problems are detected. Another challenge is the accuracy of classification – whether a conflict is truly occurring due to conflicting actions or if a sudden change in metrics is caused by an unexpected event in the network that has destabilized its operation. In case of unexpected events – solved conflicts are impossible because they do not exist. Therefore, it is important to distinguish false positive conflicts (situations where a conflict is detected but does not truly occur).

Summary

Let us summarize the above discussion. In O-RAN, RICs allow the utilization of external Apps to optimize the RAN. The drawback however is the complexity, one form of which may be conflicting decisions. Conflicts may be categorized as horizontal or vertical; they may occur between Apps located in one RIC named intra-RICs, or across Apps located in two or more RICs called inter-RIC conflicts. Conflicts are divided into 3 types: indirect, direct, and implicit. Correctness of conflict classification is important to the next steps of the mitigation approach. To effectively monitor disruptions in the network caused by the conflicts, some metrics were defined, such as severity, reach, vulnerability creation, and effectiveness of conflict detection.

Thanks to good conflict management the efficiency and desired App action can be preserved. Hence the emphasis of the operators and the O-RAN environment on highly developed solutions to avoid and mitigate conflicts. To standardize this challenge, there was a need to create a conflict mitigation framework. This is an important module within O-RAN RIC to avoid the unpredictable behavior of the RAN. (As a continuation of the topic, the next blog post will introduce a conflict mitigation framework based on the O-RAN ALLIANCE specification).

References

[1] Conflict Mitigation Framework and Conflict Detection in O-RAN Near-RT RIC Cezary Adamczyk, Adrian Kliks
[2] Whitepaper RIC-Apps Conflict Management, i14ylab
[3] O-RAN Work Group 3 (Near-Real-time RAN Intelligent Controller and E2 Interface) Conflict Mitigation,  O-RAN.WG3.TR.ConMit-R004-v01.00
[4] Conflict Management in the Near-RT-RIC of Open RAN: A Game Theoretic Approach, Abdul Wadud, Fatemeh Golpayegani, Nima Afraz

Acknowledgment

The author would like to thank Marcin Dryjanski for the valuable comments provided during the writing process.

Author Bio