PaperlayerView exact revision on arXiv

Source-linked AI summary

xTRUCE: A Provably Safe Arbiter for Multi-xApp Conflict Mitigation in Agentic O-RAN

Le Xia, Rose Qingyang Hu, Paul S. Kudyba, Zhenlin An, Haijian Sun

arXiv:2608.28532v1cs.NIeess.SY

TL;DR

Agentic O-RAN must arbitrate conflicting, infeasible, or hallucinated LLM-driven xApp proposals without compromising gNB safety. xTRUCE uses structured proposals, hierarchical constraints, priority-aware two-stage arbitration, and conflict certificates; simulations and OTA experiments show safe control, priority-consistent satisfaction, renegotiation guidance, and delay-safe execution.

  • Problem

    Agentic O-RAN lacks a joint mechanism for proposal-independent safety, priority-aware reconciliation of conflicting targets, and traceable feedback for renegotiation.

  • Method

    xTRUCE confines xApps to structured proposals, places physical and operator rules above relaxable KPI targets, arbitrates in priority order, and returns certificates with verified E2 actions.

  • Results

    xTRUCE preserves protected services under severe hallucinations, satisfies priority-consistent targets under overload, guides LLM renegotiation, and maintains delay-safe E2 execution.

  • Takeaways & Limitations

    xTRUCE provides a provably safe and traceable multi-xApp conflict-arbitration stage for agentic O-RAN control.

Abstract

from arXiv · show

The open radio access network (O-RAN) is evolving toward agentic operation, where large language model (LLM)-driven xApps/rApps generate control proposals under operator intents. However, such proposals may be conflicting, infeasible, or hallucinated, and no existing system jointly provides proposal-independent safety, priority-aware reconciliation, and traceable feedback. To this end, we propose a provably safe arbiter, namely xTRUCE, in the near-real-time (Near-RT) RAN intelligent controller for mitigating multi-xApp conflicts in gNB control. We first develop a structured xApp proposal interface and a three-layer constraint hierarchy that places physical limits and operator-defined rules above relaxable performance targets, alongside a dual-timescale control action space. A two-stage arbitration mechanism then minimizes target shortfalls in the operator-priority order to finalize safe E2 actions within the Near-RT latency budget, while returning conflict certificates to xApps and the operator for renegotiation. Finally, we implement xTRUCE in a multi-cell O-RAN use case, and evaluate its multi-process prototype through simulations with live API-backed LLM xApps and over-the-air experiments on OpenAirInterface/FlexRIC-based O-RAN stacks. Results show that xTRUCE ensures gNB control safety with $100\%$ protected services despite severe proposal hallucinations, achieves priority-consistent performance satisfaction under overload, efficiently guides LLM intent renegotiation via certificates, and keeps a delay-safe E2 control loop.

I. INTRODUCTION

Agentic O-RAN introduces conflicting and potentially hallucinated xApp proposals into Near-RT RIC control, while existing conflict-mitigation standards leave per-decision safety, prioritization, deadline handling, and feedback unspecified. xTRUCE addresses these challenges with proposal-independent arbitration, structured constraints, priority-aware relaxation, certificates, and delay-safe execution.

  • Motivation: LLM-driven xApps generate control proposals across O-RAN functions and timescales, creating an agentic O-RAN control setting.The Near-RT RIC closes measurement, decision, and action loops against the live RAN.
  • Research gap: Existing O-RAN specifications reserve conflict mitigation but do not prescribe how to protect rigid limits, relax infeasible targets, meet deadlines, or report conflicts.These gaps concern per-decision arbitration within the Near-RT RIC.
  • Approach: xTRUCE guarantees safety independently of proposal contents by requiring structured proposals and enforcing physical limits and operator-defined rules before relaxable KPI targets.Only the KPI-target layer is relaxable; executed actions obey the two rigid layers.
  • Approach: xTRUCE sequentially minimizes hard-target relaxations according to operator priorities, then finalizes a safe gNB action and returns a machine-readable conflict certificate.Certificates report target satisfaction, relaxations, and limiting constraints for renegotiation.
  • Execution guarantee: xTRUCE outputs a safe action within the control deadline, including when arbitration exceeds the time threshold under severely hallucinated proposals.The system uses delay-safe execution to prevent delayed or unverified results from being executed.
  • Scope: The system scope covers E2 control-related conflicts among agentic xApps pursuing the same operator intent, excluding authentication and multi-rApp conflicts.This scope boundary is explicit in the system design.

III. PROPOSED XTRUCE SYSTEM

xTRUCE converts untrusted xApp outputs into structured, time-bounded proposals and selects actions from a dual-timescale gNB control space using measured RAN state and KPI shortfalls. Its design explicitly treats proposals as potentially unachievable, contradictory, or wrong.

  • Control abstraction: At each epoch, xTRUCE observes the physical RAN state and collects current proposals from multiple KPI-specific xApp agents.The control loop is organized over discrete consecutive epochs.
  • Control actions: The action space includes transmit power and spectrum allocation, cell activation, and cell-to-user steering across control variables.These variables support both radio-resource decisions and slower configuration changes.
  • Control actions: xTRUCE separates slowly reconfigured variables updated every T_cfg epochs from variables redetermined at every epoch.This dual-timescale representation accommodates configuration and regular radio-resource control.
  • Structured proposals: Each proposal specifies an xApp’s KPI scope, requested target, and hard-versus-soft target type, with hard targets assigned operator-controlled priority classes.Malformed, expired, or out-of-scope proposals are discarded by the gateway.
  • KPI evaluation: xTRUCE measures KPI shortfall from the realized performance, where nonpositive values indicate a met target and positive values quantify the missed amount.The formulation supports KPIs whose preference direction may favor larger or smaller values.
  • Trust model: The framework assumes no quality condition on admitted proposals: they may be individually unachievable, mutually contradictory, or wrong.Agent identity and authorization metadata can be checked separately by the proposal gateway.

B. Three-Layer Constraint Hierarchy

xTRUCE defines admissibility through two rigid constraint layers and uses KPI targets only to rank admissible actions. A certified baseline guarantees a valid fallback action when a better action cannot be produced in time.

  • Physical constraints: The first constraint layer contains physical RAN limits, such as transmit-power budgets, that neither xApps nor operator intents may relax.These limits define the physically admissible action set.
  • Operational constraints: The second layer contains rigid O-RAN operational rules, including network-availability requirements such as protected-user rate guarantees.Operational constraints may depend on the action executed at the previous epoch.
  • Safe action set: Together, the two rigid layers define a safe action set whose actions satisfy physical and operator limits independently of xApp proposals.The resulting set is assumed compact and jointly feasible under the paper’s baseline assumptions.
  • KPI targets: The third layer contains xApp KPI targets, which need not be jointly feasible and therefore influence preference among admissible actions rather than admissibility itself.Rigid layers determine which actions are allowed; KPI targets determine which allowed action is preferred.
  • Delay-safe fallback: A baseline action satisfying both rigid layers serves as the fallback whenever xTRUCE cannot output a better action in time.This design ensures a valid E2 control action can exist at every epoch.

C. Two-Stage Priority-Aware Arbitration

xTRUCE resolves conflicting KPI targets in two stages: it first minimizes hard-target shortfalls by operator priority, then selects a safe action while preserving that ordering.

  • Stage I: Stage I determines required hard-target relaxations from highest to lowest operator priority.Nonnegative slacks represent the shortfalls accepted for hard-target pairs.
  • Stage I: Lexicographic minimization constrains each lower-priority optimization to retain the best values already achieved for higher priorities.The process minimizes V1 first, then V2, through VL.
  • Stage I: The feasible action set Ht remains rigid throughout arbitration; only xApp KPI targets are relaxed through slack variables.Physical and operator-defined constraints are not relaxed.
  • Theoretical guarantee: When all hard targets are jointly feasible, Stage I introduces no relaxation.The corresponding priority shortfalls are zero.
  • Stage II: Stage II selects among Stage-I solutions by minimizing soft-target shortfalls and inter-epoch action changes, while configuration candidates are reevaluated periodically.The action-change term is weighted by η, and configuration actions remain fixed between configuration epochs.
  • Theoretical guarantee: Theorem 1 establishes a unique lexicographically minimal Stage-I priority vector and bounds Stage-II shortfalls by v⋆ℓ + ϵℓ.Equality holds when all tolerances ϵℓ are zero.

D. Conflict Certificates and Delay-Safe Execution

At each epoch, xTRUCE returns a machine-readable certificate alongside a verified control action, enabling target renegotiation and identifying the constraints behind shortfalls.

  • Certificate output: Each epoch produces a verified gNB action and a machine-readable conflict certificate, preventing delayed or unverified results from execution.The certificate supports xApp renegotiation while the action enters the E2 control path.
  • Certificate contents: The certificate records each hard target’s relaxation amount and the limits responsible for that relaxation.The former is the realized shortfall; the latter is represented through constraint prices.
  • Certificate contents: Under convexity and a constraint qualification such as Slater’s condition, a positive optimal multiplier identifies a binding constraint.Without those conditions, prices are heuristic local diagnostics rather than globally guaranteed indicators.
  • Renegotiation loop: Certificates flow through the slow loop to relevant xApps and the operator, supporting autonomous target revision or human priority adjustment.Changing operational limits requires operator intervention, while renegotiation convergence depends on agentic capabilities.
  • Delay handling: A standby action is maintained because solving the arbitration problems may exceed the fixed per-epoch threshold τ.This mechanism supports deadline-safe execution when optimization does not finish in time.

2) Delay-Safe Action Execution:

xTRUCE enforces delay-safe execution by accepting only verified results available by the deadline and otherwise selecting a certified fallback action.

  • Delay-safe execution: The executed action is chosen from verified results available by the decision deadline, with fallback behavior covering unfinished arbitration cases.Every selected action belongs to the safe set Ht.
  • Safety guarantee: Physical and operational limits remain decoupled from agent quality, while worsening proposals affect only intent achievability by priority.Unverified or unavailable optimality information does not authorize an unsafe action.
  • Complexity: The dominant computational cost is optimization, requiring (L + 2) solves per regular epoch and (CL + 2) solves per configuration epoch.Action verification requires one linear pass over constraints and targets.
  • Complexity: Algorithm 1 has polynomial-time overall complexity when its optimization programs are instantiated as convex problems.The stated complexity also includes linear proposal and constraint processing.
  • Algorithm 1: Algorithm 1 collects valid proposals, builds Ht, periodically evaluates configuration candidates, solves the two arbitration stages, verifies actions, and returns certificates.The regular fast loop and slower configuration loop are handled together.

A. Network and E2 Control Actions

The multi-cell use case combines slower configuration controls with faster radio-resource controls exposed through Near-RT RIC E2 interfaces.

  • Dual-timescale actions: The configuration action includes binary cell activation states and user-to-cell steering assignments.An active cell has αb(t)=1, and each user is associated with an active serving cell.
  • Dual-timescale actions: The fast action allocates RB shares and average transmit powers to users.xu,k(t) is the fraction of an epoch allocated to user u on RB k, while pu,k(t) is average transmit power.
  • E2 control: Cell activation, user steering, and RB-share controls are exposed by existing E2 service models for Near-RT RIC management.The modeled controls therefore map to RAN controls available at the Near-RT RIC side.
  • Network state: The use case models channel gains, measured interference, queue backlogs, and traffic arrivals as RAN state variables.Serving-cell gains are selected according to user association, while interference is carried forward from the preceding epoch.
  • KPI mapping: The KPI model includes user bit rate and queue evolution, with bounded queues corresponding to bounded delay under fixed arrival rates.Power consumption, interference, and resource load are also included as per-cell KPIs.

C. Physical and Operator Limits

The physical and operator layers impose fixed limits on gNB actions, while the execution mechanism preserves a verified baseline across fast control and slower configuration updates.

  • Physical limits: Physical constraints bound total cell power, per-RB shares, individual RB shares, and power assigned to each share.Per-cell and per-RB power limits define the relevant power bounds.
  • Operator limits: Operator rules enforce protected-user rate floors and limit consecutive-epoch changes in power, RB shares, activation state, and user steering.The last two limits apply only at configuration epochs.
  • Action construction: Stage II measures the squared Euclidean distance between consecutive fast actions when finalizing the executed action.This distance links action selection to continuity across fast-control epochs.
  • Action construction: A baseline action retains the previous executed configuration while obtaining fast variables through a single convex solve.The solve minimizes total power subject to the physical and operator constraints and uses no slack variables.

D. Roles of Four xApp Agents

The instantiated use case employs four task-specific xApp agents whose proposals influence outcomes without directly commanding RAN-control variables. The arbitration programs prioritize protected-rate targets before evaluating softer objectives and produce safe execution with machine-readable feedback.

  • Roles of Four xApp Agents: Four Near-RT RIC agents target QoS assurance, energy saving, interference coordination, and load balancing through distinct proposals.The energy, interference, and load-balancing agents post soft targets for power, caused interference, and cell load, respectively.
  • Roles of Four xApp Agents: None of the four agents directly commands RAN-control variables; their influence occurs only through generated proposals.This keeps agent outputs separate from direct action execution.
  • Arbitration instantiation: The instantiated arbitration programs operate over fast action variables and slacks while configuration actions remain fixed between updates.Protected-rate instances form the hard targets in the first-stage problem.
  • Arbitration instantiation: Soft rate, energy, interference, and load targets enter the second-stage objective through squared target deviations.These objectives are supplied by the four agents’ proposals.
  • Arbitration guarantees: Theorem 2 establishes convexity and exact dual prices for the instantiated programs under its stated feasibility condition.The resulting problems can be solved with off-the-shelf convex programming tools in polynomial time.
  • Arbitration guarantees: Theorem 2 is limited to this specific use case, while verified execution preserves gNB safety even in non-convex or delay-exceeded cases.In those cases, the paper states that intent-layer optimality may be lost without compromising control safety.

V. EXPERIMENTAL EVALUATION

xTRUCE is evaluated in multi-cell simulations and OTA O-RAN experiments against direct and clipping-based execution schemes. Across hallucinated proposals, overloaded KPI targets, live-LLM renegotiation, and varying RAN capacities, it preserves safety, respects priorities, and maintains verified action execution.

  • Proposal-independent gNB control safety: xTRUCE and Clipping never violate physical limits under increasing proposal hallucination, while Direct violates at least one limit in 99% of epochs without hallucination.With hallucination, Direct violates physical limits in 85–96% of epochs.
  • Proposal-independent gNB control safety: 100% of xTRUCE epochs preserve protected-user rate floors, whereas Direct violates them in 30–86% and Clipping in 65–92% of epochs.Clipping remains physically legal but loses committed services by violating the operational rate floor.
  • Priority-consistent KPI satisfaction: xTRUCE keeps highest-priority shortfall near zero under overload, while lower-priority shortfalls reach 21.7 Mbps and 4.1 W at maximum contention.The overload sweep raises the non-protected-user rate target from 1.5 to 24 Mbps; Flat assigns all targets the same priority.
  • Certificate-guided renegotiation: Certificate feedback lets ChatGPT-5.6 meet its rate target in one round and Sonnet-5 reach the energy line within three rounds.Certificate mode yields target-unmet-round means of 24% versus 79% and 99% for ChatGPT-QoS, and 29% versus 82% and 96% for Sonnet-Energy.
  • Delay-safe action execution: Verified Stage-II actions execute in 100% of epochs at five users, declining from 98% at 10 users to 71% at 30 users as arbitration time grows.Across 3000 epochs, execution uses only verified actions, never unavailable or delay-exceeded results.

C. OTA Testbed Results

OTA experiments on an OAI/FlexRIC testbed show that xTRUCE preserves physical and operator-defined safety under hallucinated xApp proposals while maintaining a delay-safe E2 control loop.

  • Experimental setup: The OTA evaluation uses four hallucinated xApps and measures constraint satisfaction, operational-limit violations, and fast-control-loop processing times.Panels (a) and (b) include error bars from three repeated OTA tests.
  • Proposal-independent gNB control safety: 100% satisfaction holds for both physical limits c1–c4 and operational limit e1 across hallucination levels 0.3, 0.5, and 0.8.Direct satisfies physical limits in 69 down to 38% of epochs; Clipping violates e1 in up to 9.4% and Direct in up to 24.7%.
  • Delay-safe execution: RAN state collection and E2 action delivery finish within 0.4 and 2.4 ms, respectively, across all 540 epochs.Arbitration dominates processing time with a median of 13.3 ms.
  • Delay-safe execution: 89.3% of arbitration calls meet the 0.1-s epoch threshold, while 10.7% exceed it.The execution logs report 58 late calls and 33 in-time calls without a verified action, with remaining verified cases still used.
  • Delay-safe execution: xTRUCE preserves safety checks and rejects late results on a real O-RAN stack.This extends the delay-safe execution behavior observed in simulation to the OTA testbed.

APPENDIX A PROOF OF THEOREM 1

Theorem 1 is proved by showing that Stage I yields a uniquely lexicographically minimal shortfall vector and that both arbitration objectives are convex under the stated constraints.

  • Lexicographic optimality: Stage I recursively restricts the feasible action set to minimize each shortfall class in order, producing a uniquely lexicographically minimal vector.Compactness ensures every minimum is attained and each restricted set remains nonempty.
  • Stage-II feasibility: Any action retained after Stage I with minimal feasible slacks is feasible for Stage II for arbitrary nonnegative relaxation tolerances.Every feasible Stage-II pair has shortfalls bounded by the Stage-I optima.
  • Convexity: The rate function is concave because each resource-allocation term is a concave perspective, making rate-target shortfalls convex.The queue-value term is also convex, while the listed KPI and limit expressions are linear where stated.
  • Convexity: Both arbitration objectives are convex, and every constraint defines a convex set.The Stage-I objective is quadratic in slacks; the Stage-II objective combines weighted squared positive-part terms with a convex action-change penalty.
  • Strong duality: Refined Slater conditions establish strong duality, dual attainment, and the stated multiplier interpretation for both optimization problems.The proof constructs strict-feasibility points for Stage I and Stage II using positive relaxation and perturbation parameters.
Loading 2608.28532v1…