Can rApps resolve their own conflicts? Research insights from Ericsson

An energy-saving rApp reduces transmit power. A capacity rApp increases it. A load-balancing rApp shifts traffic toward the same cells on which the energy rApp is trying to reduce power. Each application has correctly identified a beneficial change from its own perspective. Executed together, their changes can leave the network worse off than it was before any of them acted.

This is the multi-rApp coordination problem, and the O-RAN Alliance has identified it as a critical gap requiring architectural solutions. It grows with the expanding ecosystem. Network automation succeeds precisely when operators can deploy applications from many vendors and across many technologies, but that success is capped if those applications keep undoing each other's work.

Figure 1: Deployment of TACIT + ORACLE

These are insights from research in Ericsson exploring potential approaches to this gap. Two recent publications from our team, TACIT, published in IEEE Access with collaborators at the Technological University of the Shannon, and ORACLE, presented at EuCNC & 6G Summit 2026, investigate how conflicts between self-interested rApps might be resolved without an all-knowing centralized function, and how that arbitration might be wrapped in a verifiable enforcement layer, so that trust in the outcome does not depend on the rApps trusting the Service Management and Orchestration (SMO) platform to adjudicate fairly.

Why rApp conflict seems to demand omniscience

Conventional approaches to conflict management assume a coordinator that understands every application it supervises. To detect that two proposals conflict, classify the conflict type, and rank the proposals, a central function would need to replicate the internal logic of every rApp. That logic is highly complex, can change significantly with every software release, and, in a multi-vendor scenario, proprietary.

Conflicts can also be intrinsically difficult to detect. O-RAN specifications classify three different conflict types. Direct conflicts, where two rApps target the same parameter, are the easy case. Indirect and particularly implicit conflicts, where changes interact through the radio environment rather than through shared parameters, resist enumeration in advance. A detection-and-classification pipeline has to anticipate every interaction pattern before it occurs. 

The alternative is to stop requiring a centralized model to understand everything.

TACIT: conflict arbitration without a central referee

TACIT (Trustworthy Arbitration through Calibrated Inference Tracking) inverts the flow of knowledge. When an rApp proposes a configuration change, the mechanism asks every affected rApp a single question: how do you expect this change to affect your own Key Performance Indicators (KPIs)? Each application answers from what it already knows best, its own objective. No rApp models another rApp, and no central function models any of them.

The mechanism aggregates these self-interested assessments using reputation-weighted Nash Social Welfare (NSW) optimization. Proposals that the affected applications collectively expect to be harmful do not pass the gate. And because each rApp's influence is weighted by its track record in predicting the effects of parameter changes on network performance, the arbitration mechanism learns whose predictions to trust. 

An asymmetric reputation update penalizes incorrect predictions more heavily than it rewards correct ones, so unreliable applications lose influence quickly and regain it slowly. This allows faulty or unreliable rApps to be identified and neutralized.

Three properties follow from this design:

• Conflicts resolve without being detected or classified. Direct, indirect, and implicit conflicts all pass through the same assessment gate. Nothing needs to be enumerated in advance.
• The mechanism scales linearly. Computational complexity is O(N) in the number of rApps and independent of the size of the parameter space.

Unreliable rApps isolate themselves. Continuous online learning suppresses the influence of applications whose predictions degrade, without operator intervention.

Video 1: TACIT

What the evaluation showed

We evaluated TACIT in an ns-3 simulation of a 19-cell network with 7 concurrent rApps, each optimizing a distinct KPI, processing 771 configuration proposals over the evaluation period.

Key findings: Compared to unconstrained operation, where every proposal is accepted, the reputation-weighted gate improved throughput by 3.2%, energy efficiency by 3.0%, and edge user experience by 11.7%. It also outperformed static priority ordering and other aggregation methods across the same metrics.

Self-healing in practice: When one rApp's underlying prediction model degraded during the evaluation, its reputation dropped within a single reporting period. Its influence on subsequent decisions was suppressed automatically, before any human would have noticed the malfunction.

ORACLE: extending trust across vendor boundaries

An arbitration mechanism is only as trustworthy as its execution. In a multi-vendor deployment, that raises an uncomfortable question: who runs the arbitration? If the platform provider supplies it, every other participant must take it on faith that the platform is not treating rApps supplied by the platform vendor preferentially in conflict evaluation.

ORACLE (Open RAN Arbitration via Consensus Ledger Enforcement) removes that leap of faith. It employs a technology with strong potential for resolving coordination issues in 6G: blockchain, a role mapped out in Blockchains in 6G. Proposals, predictions, and outcomes are recorded on a permissioned distributed ledger as immutable shared state. Smart contracts execute the agreed decision function deterministically, so the same inputs always produce the same outcome. 

Every participant follows a uniform workflow, and any participant can independently verify that the agreed process was followed. No party, including the infrastructure operator, can unilaterally manipulate decision inputs or selectively omit results.

The design integrates with existing automation platform control loops, including the O-RAN Non-Real-Time RAN Intelligent Controller (Non-RT RIC), without requiring changes to existing interfaces. We evaluated it through integration with the same ns-3 simulation, demonstrating decision latency within Non-RT RIC timing constraints and ledger costs that scale linearly with the number of participants.

Video 2: ORACLE

What this means for operators

Together, the two mechanisms turn conflict management from a barrier into an enabler of vendor diversity:

• Vendor autonomy is preserved. No application exposes its objectives, models, or internal logic. Participation requires only self-assessment.
• Coordination scales with the ecosystem. Linear complexity and unchanged interfaces mean adding rApps does not require re-engineering the arbitration.
• Trust is earned continuously. Influence follows demonstrated prediction accuracy rather than static priority assignments.
• Every party can verify the outcome. The immutable record and auditable, deterministic execution give all vendors, and the operator, the same evidence trail.

Toward self-coordinating networks

We did not start with this philosophy. We built the opposite first, a central coordinator that learned more and more about the network, its intents, and its operating environment. That work was published as CAMINO, and it showed us where the approach runs out. The interactions behind the hardest conflicts are the ones nobody can observe. TACIT began when we stopped trying to build a smarter referee and started designing a mechanism that does not need one.

The pattern behind these results extends beyond conflict management. As networks take on more autonomous applications, coordination cannot rest on any single function understanding everything in the system. It has to emerge from well-designed local incentives, and it has to be verifiable by everyone with a stake in the result. TACIT shows that self-interested applications can reach coordinated decisions that improve throughput, energy efficiency, and user experience simultaneously. ORACLE shows that the arbitration itself can be made transparent enough that multi-vendor deployments don't need a privileged referee. That combination, coordination without omniscience and trust without unilateral control, is what autonomous multi-vendor networks require as they scale toward 6G.

If you are building rApps, you do not need a multi-vendor deployment to test this. Pick your two rApps that compete the most, implement the two-method interface and simple arithmetic decision function in each, and watch what happens to your rollback rate. The full mechanism is in the papers below. If you want to take it further, the O-RAN Alliance WG2 study on A1 policy conflict mitigation is the open forum for this work.

Acknowledgement: This work was supported by the Smart Networks and Services Joint Undertaking (SNS JU) under the European Union's Horizon Europe research and innovation programme, Grant Agreement No 101192462 (FLECON-6G project). Views and opinions expressed are those of the author only.

Read more

• TACIT: Trustworthy Arbitration through Calibrated Inference Tracking for O-RAN Conflict Resolution, IEEE Access 2026
• Blockchains in 6G: A Standardized Approach To Permissioned Distributed Ledgers, Dohler, Lopez and Wang (2024)
• ORACLE: Open RAN Arbitration via Consensus Ledger Enforcement, EuCNC & 6G Summit 2026
• Intelligent RAN automation at Ericsson
• Ericsson rApps
• O-RAN Study on A1 Policy Conflict Mitigation, O-RAN Alliance Working Group 2, Jun. 2026.
• CAMINO - Contextually Aware Mediation of Intent for Network Orchestration, Telecommunication Systems (2025)