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

1

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

arXiv:2608.28532v1 [cs.NI] 28 Aug 2026

Le Xia, Member, IEEE, Rose Qingyang Hu, Fellow, IEEE, Paul S. Kudyba, Student Member, IEEE, Zhenlin An, Member, IEEE, and Haijian Sun, Senior Member, IEEE

Abstract—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 proposalindependent 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 operatordefined rules above relaxable performance targets, alongside a dual-timescale control action space. A two-stage arbitration mechanism then minimizes target shortfalls in the operatorpriority 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 ORAN 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. Index Terms—Agentic O-RAN, multi-xApp conflict mitigation, large language models (LLMs), Near-RT RIC, safe gNB control.

I. I NTRODUCTION

T

HE open radio access network (O-RAN) architecture is reshaping cellular networks on the road toward 6G, as it replaces closed and monolithic base stations with multi-vendor disaggregated units, open interfaces, and hierarchical RAN intelligent controllers (RICs) [1], [2]. Upon this architecture, network intelligence is implemented as pluggable control applications, among which the xApps hosted by the near-realtime (Near-RT, 10 ms–1 s) RIC close measurement, decision, and action loops directly against the live RAN [3]. Typically, each xApp operates one management objective, e.g., quality of service (QoS) assurance or energy saving, and such data-driven xApps have already been developed and validated at scale on open experimental platforms [4], [5]. Notably, these xApps may be developed and supplied by different vendors, but they Le Xia and Rose Qingyang Hu are with the Bradley Department of Electrical and Computer Engineering, Virginia Tech, Blacksburg, VA 24061, USA (e-mail: {lexia, rosehu}@vt.edu). Paul Kudyba, Zhenlin An, and Haijian Sun are with the School of Electrical and Computer Engineering, University of Georgia, Athens, GA 30602, USA (e-mail: {paul.kudyba, zhenlin.an, hsun}@uga.edu). The source code of xTRUCE will be released on GitHub upon publication.

can observe and steer the same cells, users, and spectrum through the shared E2 interface of the Near-RT RIC layer. Meanwhile, the rapid advancement of large language models (LLMs) is bringing the 6G vision of AI-native networks within reach, and recent studies anticipate that LLMs will undertake management duties ranging from translating operator intents to directly making gNB control decisions [6]–[8]. Specifically, intent-based networking translates high-level operator goals into machine-actionable policies [9], while agentic systems enable LLMs with autonomous reasoning capabilities to interpret these policies and generate the resulting management proposals across O-RAN functions and timescales [10]–[13]. Merging the two trends, the O-RAN ecosystem is evolving toward the agentic O-RAN, where LLM-driven non-real-time (Non-RT, ⩾ 1 s) rApp agents interpret operator intents and multiple LLM-driven Near-RT xApp agents generate proposals of gNB control decisions collaboratively and autonomously. Nevertheless, the multi-xApp proposals may turn out mutually conflicting, physically infeasible, malformed, or simply hallucinated at run time, and the same concern has already arisen in scripted, learned, and third-party xApps [14]. In fact, inter-xApp conflicts have been a long-standing concern in the O-RAN even before the agentic evolution [15], since a closed single-vendor stack reconciles its control logic at design time, whereas the xApps of O-RAN cannot be coengineered due to their multi-vendor origins. Being aware of this, the O-RAN specifications dedicatedly reserve a conflict mitigation function inside the Near-RT RIC platform and outline its architectural considerations [16], [17]. However, they do not prescribe a per-decision method that jointly admits conflicting targets, relaxes the infeasible ones according to operator priorities, and certifies the resulting action. Therefore, governing such untrusted intelligent agents at run time, instead of blindly trusting them, becomes the prerequisite for the agentic evolution to be deployable in the real-world O-RAN. Lately, conflict handling in the O-RAN has attracted several noteworthy research efforts. Adamczyk et al. [18] categorized inter-xApp conflicts into direct, indirect, and implicit types, and devised a detection-centric mitigation framework for the Near-RT RIC. Similarly, del Prever et al. [15] developed PACIFISTA, a framework that profiles candidate xApps on an experimental platform and statistically evaluates their conflicts before deployment, and their latest follow-up further predicted the key performance indicators (KPIs) impact of such conflicts from the same profiles [19]. For run-time reconciliation, Wadud et al. developed QACM in [20] to select the values of conflicting parameters according to the QoS requirements of

2

the involved xApps, and further mitigated a concrete conflict between energy saving and mobility management in the same spirit in [21]. From the orchestration perspective, D’Oro et al. [22] proposed OrchestRAN to decide which intelligence runs where, preventing two models from steering the same parameter by construction. All these efforts confirm both the severity and the industrial relevance of the problem. In parallel, there have been some related works addressing the safety control issue of data-driven, standalone xApps in O-RAN. Nagib et al. [23] stabilized a deep reinforcement learning (DRL)-based slicing xApp against unseen network conditions through hybrid transfer learning, and their followup SafeSlice [24] further added a safety layer that projects each resource-allocation action onto the nearest latency-safe one. Hossen et al. [25] replayed the closed control loop on a digital twin, such that an xApp is exercised against realistic KPIs before it touches the live RAN. In addition, Fiandrino et al. [26] attached graph-based explanations to the decisions of DRL xApps, letting the operator inspect and steer a running agent. However, these safeguards only target singlexApp O-RAN scenarios and are not capable of arbitrating conflicting proposals from multiple xApps at runtime, let alone handling LLM-driven agents that might generate hallucinated proposals. To the best of our knowledge, no existing work delivers a unified solution that turns conflicting and infeasible multi-xApp proposals into a verified safe gNB action while balancing operator priorities and Near-RT latency budget. In summary, we are encountering the following three fundamental challenges when pursuing such a realization: Challenge 1: How to guarantee gNB control safety under arbitrary, untrusted, and possibly hallucinated proposals from LLM-driven xApp agents? The content of multiple xApp proposals may be well-formed and authorized yet remain infeasible or mutually conflicting [20]. Hence, safety must be enforced in the Near-RT RIC platform and be entirely independent of the proposal contents, while ensuring that every executed gNB action satisfies the physical limits and operator-defined rules simultaneously. • Challenge 2: How to reconcile jointly infeasible KPI targets in alignment with operator priorities and provide actionable feedback for proposal renegotiation? When multi-xApp proposals conflict, their KPI targets may not be jointly feasible under the current RAN capacity and operating constraints, and some targets must therefore be relaxed according to operator-defined priorities. Especially for some hard targets, their resulting shortfalls and limiting constraints are essential to be reported in a machine-readable form to guide proposal renegotiation. • Challenge 3: How to issue a safe gNB action within the Near-RT latency budget over a mixed discrete and continuous action space? Configuration gNB control decisions, such as cell activation and user re-association, evolve on a slower timescale than the regular radio resource decisions, which makes the joint optimization combinatorial. Moreover, the solver of action arbitration may overrun the required delay demand, and thus a safe action must be decided by the decision deadline.

•

To address the above challenges for agentic O-RAN, in this paper, we propose the xApp Target Relaxation Under Conflicts with delay-safe Execution, namely xTRUCE, in the Near-RT RIC with provable guarantees. With xTRUCE, xApp agents influence the gNB control exclusively through structured proposals, and the core arbiter computes a safe executed action and a conflict certificate at each decision epoch. In tests with multiple conflicting xApps, xTRUCE preserves all physical and operator-defined rigid limits, while allocating inevitable KPI-target shortfalls according to operator priority. It also guides live LLM xApp agents to successfully correct infeasible intents within only 3 rounds of certificate feedback, leaving targets unmet in only 24–29% of rounds versus 79–99% for the benchmark modes. Further on the over-the-air (OTA) ORAN testbed, a safe action is always output in every 100ms runtime epoch, even when arbitration occasionally exceeds the time threshold under severely hallucinated proposals. In a nutshell, our main contributions are summarized below. We first place xTRUCE in the conflict-mitigation path of the Near-RT RIC, where a structured proposal gateway confines every untrusted xApp to machine-readable proposals rather than direct RAN control. We further organize physical limits, operator-defined rules, and xApps’ KPI targets into a three-layer constraint hierarchy, in which every executed gNB action obeys the two rigid layers and only the KPI-target layer is relaxable. • We then develop a two-stage priority-aware arbitration to reconcile conflicting KPI targets. Specifically, Stage I sequentially minimizes hard-target relaxations according to operator-defined priorities, while Stage II finalizes a safe gNB action via the E2 control loop. Here, we theoretically prove this priority guarantee and show that Stage I introduces no relaxation whenever all hard targets are jointly feasible by Theorem 1. Afterward, the resulting target shortfalls and limiting-constraint prices are collected in a machine-readable conflict certificate and returned to guide xApps and the operator on proposal renegotiation. These address Challenges 1 and 2. • We identify a dual-timescale action rule and devise a delay-safe action execution mechanism that always retains a verified action to support slow configuration updates and fast resource control under the Near-RT delay limit. As such, even when the two-stage arbitration does not finish in time, a safe action remains available for RAN control. We further instantiate a multi-cell O-RAN control use case, in which xTRUCE is theoretically proved to provision safe actions and certificates with exact prices by Theorem 2. These tackle Challenge 3. • To validate the deployability of xTRUCE, we evaluate its multi-process prototype in Python-based simulations with independently attached live ChatGPT-5.6 and ClaudeSonnet-5 agents, and on an OTA O-RAN-compliant testbed supported by OpenAirInterface (OAI) gNB and Flexible RIC (FlexRIC). The results verify its proposalindependent gNB control safety, priority-consistent KPI satisfaction, certificate-guided LLM renegotiation, and Near-RT-delay-safe execution over the E2 interface loop. •

3

An exemplification of intent

Policies

Certificates

A1

Targets Priorities

Energy

Load

xApp

xApp

xApp

xApp agents’ proposals

-party … 3 xApps rd

⟲ Slow renegotiation loop

Conflict certificates

xTRUCE A provably safe arbiter for mitigating conflicts among xApp agents Priority-aware · Delay-safe · Explainable

Operational rules

SMO ---Non-RT RIC

QoS

A1 termination

Shared data & messages

O1

AMF / UPF / ...

E2 termination O1

NG

RAN states O-RAN

⟲ Fast control loop

rApp

5G Core

xApps = Multiple live API-backed LLM agents

High-level intent

Intent orchestration

Near-RT RIC

E2

Control actions

Co-located OTA testbed realization

O-RAN operator Operator console

gNB O-CU F1 O-DU

USRP 2901

DGX Spark Host: OAI 5GC + OAI gNB + FlexRIC with xTRUCE

Physical RAN measurement and control

O-FH

O-RU

UE-2

UE-1 RPi

Fig. 1. An overview of xTRUCE-enabled agentic O-RAN control architecture, alongside its co-located OTA testbed realization.

The remainder of this paper is organized as follows. Section II first introduces xTRUCE to the O-RAN alongside its design requirements. Section III then establishes its system model and mathematical guarantees. In Section IV, xTRUCE is instantiated for multi-cell O-RAN control. Finally, simulation and OTA experimental results are demonstrated and analyzed in Section V, followed by the conclusions in Section VI. II. X TRUCE FOR AGENTIC O-RAN A. Agentic O-RAN Control Path Fig. 1 elaborates the deployment of xTRUCE within an end-to-end control path of agentic O-RAN. It begins with the O-RAN operator expressing a high-level intent in natural language through the operator console, which is processed by the service management and orchestration (SMO) framework. The SMO hosts the Non-RT RIC, which has an intent-orchestration rApp to precisely translate this intent into machine-actionable policy guidance that specifies the KPI targets, operator priorities, and operational rules. Then, data regarding these policies are shared with multiple xApps in the Near-RT RIC via the A1 termination [27]. To be agentic and intelligent, the rApp and xApps employ the authorized APIs to access live LLM agents (e.g., Claude-Sonnet-5 [28] and ChatGPT-5.6 [29]), and they also support local scripting- and learning-based agents. Meanwhile, the Near-RT RIC communicates with the open central unit (O-CU) and distributed unit (O-DU) via the E2 interface and controls the open radio unit (O-RU). Specifically, E2 indication entering the Near-RT RIC carries the measurements of RAN states, while E2 control leaving it delivers the gNB control decisions through applicable E2 service models (E2SMs) [30]. Additionally, the O1 interface serves management and persistent configuration, and the NG interface connects the gNB to the 5G Core [1]. Besides hosting the xApps, the Near-RT RIC platform also provides a series of shared functions, among which the O-RAN specifications explicitly identify multi-xApp conflict mitigation as a core platform capability and outline its architectural considerations [16], [17]. However, its standards still leave open which limits are never relaxed, how infeasible targets degrade along the operator priorities, what gNB action goes

out if the arbitration hits the Near-RT latency budget, or what should be reported back to the xApps. In view of this, xTRUCE fills exactly this gap as an indispensable conflictarbitration stage standing before the E2 control decision is made. Note that xTRUCE’s scope only covers the E2 controlrelated conflicts among agentic xApps based on the same operator intent, whereas the issues outside this, such as xApp authentication or multi-rApp conflicts, are not considered. B. xTRUCE Workflow and Design Goals Before xTRUCE works, each xApp first performs inference on the Non-RT policies received via A1 and the RAN states received via E2 in order to generate a proposal for a certain gNB management objective, e.g., QoS assurance, energy saving, or load balancing [25]. Herein, no xApp directly makes any control decisions, and instead, each xApp submits a machine-readable proposal through a proposal gateway, which is essentially an intra-RIC interface distinct from both A1 and the E2SMs. In detail, the proposal gateway checks the identity, authorized scope, schema, and validity period of the proposals of each xApp, and any malformed, expired, or out-of-scope requests will be discarded before arbitration. It is also worth pointing out that whatever proposal passes these checks still remains untrusted and must be subsequently arbitrated through xTRUCE, since it may be individually infeasible, mutually conflicting, or simply wrong due to agentic hallucination. Within each arbitration epoch of xTRUCE, the latest valid xApp proposals are first collected, and one best safe action is then computed and issued via E2. In parallel, xTRUCE returns a structured conflict certificate to xApps and the operator, stating which KPI targets were met, which were relaxed and by how much, and which limits were hindering further improvement. As such, two closed loops emerge in the xTRUCE workflow, as marked in Fig. 1. The fast control loop starts with receiving RAN states and ends with emitting gNB control actions in each arbitration epoch. The slow renegotiation loop is an asynchronous feedback path, where the certificates let the xApp agents revise unrealistic targets and give the operator a concise account of persistent conflicts. For delay-safe consideration, an accepted xApp proposal stays

4

Intent orchestration rApp

Non-RT RIC

Near-RT RIC ⟲ Slow renegotiation loop

QoS xApp

𝑠" Structured proposals 𝒫'"

Energy xApp

Interference xApp

xTRUCE

xApps’ targets over ℛ" Proposal gateway

Operator policies

…

⟲ Fast control loop

O-RAN gNB

C oper: Operator rules

(ℋ" ,𝑠" )

Conflict certificate 𝑍"

Certificate Stage I assembler Lexicographic Delay-safe minimization- 𝑷𝟏 control (𝝃∗" , 𝝁" , ℱ" ) 𝑣ℓ∗

C phys: Physical limits RAN state 𝑠"

Load xApp

Stage II Safe action arbitration- 𝑷𝟐

Verified 𝑎"∗ Action Finalized Executed action 𝑎"$%$

E2 control

Fig. 2. The proposed xTRUCE for safe multi-xApp arbitration, delay-safe RAN control, and certificate-guided conflict renegotiation in the Near-RT RIC.

valid over a declared time window, and xTRUCE always decides based on the latest valid proposals and never waits for an LLM response on delay-sensitive services. Accordingly, the design and development of xTRUCE in agentic O-RAN aims at four specific goals as follows: • Proposal-independent gNB control safety: Every gNB control action output from the arbiter must not violate the modeled physical limits and operator-defined rules, independently of the contents of all admitted xApp proposals. • Priority-consistent KPI satisfaction: When KPI targets cannot all be met under overload, their shortfalls are minimized based on operator-assigned priorities to satisfy high-priority performance targets as much as possible. • Multi-xApp conflict certificate feedback: At each arbitration epoch, xTRUCE must return a machine-readable conflict certificate for renegotiation. The certificate reports the target relaxations and limiting constraints when a new arbitration result is available, or indicates that no new optimality information is available after a timeout. • Near-RT RIC delay-safe action execution: A verified control action must be available and issued within each epoch, even when the complete arbitration does not finish within the Near-RT latency budget (less than 1s). III. P ROPOSED X TRUCE S YSTEM This section details the xTRUCE system design in Fig. 2, covering its control abstraction, constraint hierarchy, two-stage arbitration, certificate feedback, and delay-safe guarantee. A. Control Actions and Structured xApp Proposals Time is equally divided into discrete, consecutive epochs t = 0, 1, 2, · · · , and at each epoch t, the physical RAN state1 , denoted as st , is known to the Near-RT RIC layer via the E2 interface. Let N = {1, · · · , N } be the set of xApp agents deployed, where each agent i ∈ N operates towards a specific KPI and generates a corresponding proposal when needed. 1 The state encompasses channel gains, queue backlogs, and traffic arrivals,

etc., which are objective conditions that can be measured in near real time.

After processing the valid proposals, xTRUCE issues a gNB control action, denoted as at ∈ A, where A is an action space containing finite numbers of control variables, covering transmit power/spectrum allocation, cell on/off states, and cellto-user steering. To accommodate control timescales,
different cfg rt . Here, a we split at into at = acfg , a t is the set of slowly t t reconfigured variables that are updated every T cfg (T cfg > 1) epochs and stay constant in between, while art t stands for the set of variables that should be redetermined at every epoch t. In addition, let M = {1, · · · , M } index the KPIs exposed by the O-RAN, and their realized values are given by
T ϕ(at , st ) = ϕ1 (at , st ), · · · , ϕM (at , st ) , (1) where ϕm (at , st ) is the performance value regarding KPI m resulting from executing action at under RAN state st . Consider that at epoch t, each xApp agent i submits its requests only through a structured proposal in the form of 
Pit = θi,m , typei,m m∈Mi . (2) Specifically, Mi ⊆ M confines the scope of KPIs for which agent i is responsible, θi,m ∈ R is its requested performance target of KPI m, and typei,m ∈ {hard, soft} identifies a hard target or a soft preference. For illustration, let Rt collect the set of (i, m) pairs covered by valid proposals at epoch t. Notably, each proposal expires unless renewed, and any malformed, expired, or out-of-scope proposals will be discarded by the proposal gateway,2 as shown in Fig. 2. We further assume that the operator assigns each hard KPI target (i.e., θi,m with typei,m = hard) a fixed priority class ℓi,m ∈ L = {1, · · · , L}, where a smaller ℓi,m denotes a higher priority for target satisfaction and no xApp can change the ordering. Given Pit at epoch t, xTRUCE outputs action at in the current RAN state st , thus yielding a performance shortfall function gi,m (at , st ) to measure the gap between the expected and the actual performance of KPI m. That is, ∀(i, m) ∈ Rt ,
gi,m (at , st ) = dm θi,m − ϕm (at , st ) . (3) 2 Agent identity and authorization metadata can be attached to (2) and checked by the same gateway [31]. Relevant agentic security research is beyond the scope of this paper and will not be discussed in depth.

5

Here, dm ∈ {1, −1} is the preference direction, where dm = 1 means that a larger ϕm (at , st ) is better (e.g., rate) and dm = −1 the opposite (e.g., energy). Obviously, gi,m (at , st ) ⩽ 0 holds only when the KPI target is met, while a positive gi,m (at , st ) equals the shortfall by which the target is missed. Different from existing agentic O-RAN designs, which implicitly trust the agentic reasoning of xApps, our framework is built on the opposite premise by the following assumption: Assumption 1 (Untrusted agentic proposals): No condition is imposed on xApp proposals admitted by the gateway. They may be individually unachievable, mutually contradictory, or wrong, and xTRUCE never relies on their quality. B. Three-Layer Constraint Hierarchy The action at output from xTRUCE at epoch t must obey three layers of constraints. The first layer contains physical RAN constraints, such as a transmit power budget, that cannot be relaxed by any xApp or operator intent. In this case, given any network state st , we define the set of admitted actions as  Cphys (st ) = at ∈ A | cj (at , st ) ⩽ 0, ∀j ∈ Jphys , (4) where Jphys indexes all preset physical constraints, and cj (at , st ) is the formulation of j-th constraint rewritten by moving all its terms to the left-hand side, thus a positive cj (at , st ) is exactly the shortfall at limit j. The second-layer constraint is derived from rigid operational rules of O-RAN to maintain network availability, such as a guaranteed rate for protected users, which can only be modified by the operator and may involve the action executed at the previous epoch, denoted as aexec t−1 . Likewise, its admitted action set is exec Coper (st , aexec t−1 ) = {at ∈ A | ej (at , st , at−1 ) ⩽ 0, ∀j ∈ Joper }, (5) where Joper indexes all preset operational constraints, and ej (at , st , aexec t−1 ) indicates the shortfall of its j-th constraint. Together, the two rigid layers confine a safe action set

Ht = Cphys (st ) ∩ Coper (st , aexec t−1 ),

(6)

such that each action at ∈ Ht satisfies the physical and operator limits independently of the xApp proposals. Here, Ht is assumed to be compact. In addition, we recognize the thirdlayer constraints by incorporating the KPI targets of xApps. Under Assumption 1, their target inequalities need not be jointly feasible and are therefore not included in Ht , but will be taken into account during subsequent processing. Clearly, the first two layers decide which actions are admissible, while the third determines which admissible action is preferred. To ensure that a valid E2 control action exists at every epoch, we define a baseline action as abase = πbase (st , aexec t t−1 ), which retains the configuration component of aexec and comt−1 putes a conservative real-time component art satisfying both t rigid layers in observation of st . In this way, abase is easy t to obtain and serves as the floor action whenever xTRUCE cannot output a better action in time. Furthermore, we make the following assumption: Assumption 2 (Certified baseline action): At each epoch t, let abase ∈ Ht , which also implies that Ht ̸= ∅. t By Assumption 2, the joint action feasibility between the physical limits and the operator rules is guaranteed.

C. Two-Stage Priority-Aware Arbitration When conflicts happen, the hard targets of multiple xApps may no longer be jointly met within Ht , hence xTRUCE must decide how much intent to give up following the operator’s preset priorities. To this end, we devise a two-stage arbitration mechanism, where Stage I determines the extent to which the hard targets need to be relaxed from highest to lowest priority (i.e., ℓi,m ), and Stage II finalizes which safe action to execute. 1) Stage I: For each hard-target pair (i, m) ∈ Rt , we first introduce a non-negative slack ξi,m through gi,m (at , st ) ⩽ ξi,m , thus ξi,m exactly equals the shortfall forced to accept. With this, the overall shortfall across all hard-target pairs at the ℓ-th priority class (i.e., ℓi,m = ℓ) is now measured by X 2 Vℓ (ξ) = βi,m ξi,m , (7) (i,m)∈Rt : ℓi,m =ℓ, typei,m =hard

where βi,m > 0 is the operator-assigned target weight, stating the relative importance of different targets within the same priority class. Clearly, Vℓ (ξ) = 0 holds only when each hard target in class ℓ is met, while the design of squared slacks can discourage concentrating unavoidable shortfall on one target. At each epoch t, Stage I then solves a lexicographic violation optimization problem as follows:
P1 : lex min V1 (ξ), V2 (ξ), · · · , VL (ξ) (8) at ∈Ht , ξ⩾0

s.t.

gi,m (at , st ) ⩽ ξi,m , ∀ hard (i, m) ∈ Rt . (8a)

Lexicographic minimization stipulates that V1 (ξ) is minimized first, then holding that value while proceeding to solve V2 (ξ), and so on, until VL (ξ) [32]. When minimizing Vℓ (ξ), each higher-priority j < ℓ is constrained by Vj (ξ) ⩽ vj⋆ , and the attained optimum is recorded as vℓ⋆ . Note that Ht is never relaxed at any point in the above process, and only xApps’ KPI targets are relaxed via ξ. Moreover, solving P1 does not ensure a unique optimal action, as many at ∈ Ht may reach the optimum at the same time, e.g., in a case where all hard targets jointly fit, the corresponding actions yield Vℓ (ξ) = 0. 2) Stage II: In this stage, xTRUCE is to select a best control action from the action solutions to P1 by minimizing the shortfalls of all soft targets from xApp proposals as well as the inter-epoch action change. Its optimization problem becomes X  2 P2 : min βi,m gi,m (at , st ) + at ∈Ht , ξ⩾0

(i,m)∈Rt : typei,m =soft

+ η D at , aexec t−1 s.t.

(9)

gi,m (at , st ) ⩽ ξi,m , ∀ hard (i, m) ∈ Rt , (9a) Vℓ (ξ) ⩽ vℓ⋆ + ϵℓ , ∀ℓ ∈ L.

(9b)

Here, [ · ]+ = max{· , 0} extracts the shortfall of each softtarget pair (i, m) ∈ Rt , D(at , aexec t−1 ) ⩾ 0 measures the action change,3 and η ⩾ 0 is an operator-assigned weight to control the magnitude of action change. Constraints (9a) and (9b) require each priority’s shortfall to stay within vℓ⋆ up to a nonnegative tolerance ϵℓ , thereby preserving the Stage-I priority 3 The explicit form of D(a , aexec ) may vary in different use cases, e.g., it t t−1 is instantiated as the squared Euclidean distance in the following Section IV.

6

ordering. Under Assumption 2 and continuity of the functions in P1 and P2 on the compact set Ht , both stages can attain their optima, and the Stage-II action is denoted by a⋆t . Moreover, xTRUCE keeps the configuration acfg fixed bet tween configuration epochs, while at every T cfg -th epoch, it evaluates the operator-prescribed configuration candidates through P1 and selects the one with the lexicographically ⋆ smallest (v1⋆ , · · · , vL ). Then, ∀at ∈ Ht , let Vℓ (at ) denote (7) with ξi,m substituted by ξi,m = [gi,m (at , st )]+ . The resulting priority behavior of the two-stage arbitration is stated below: Theorem 1 (Two-stage lexicographic minimization): The ⋆ Stage-I output (v1⋆ , · · · , vL ) is the unique lexicographically minimal vector over Ht , and ∀at ∈ Ht , either Vℓ (at ) = vℓ⋆ , ∀ℓ, or Vℓ (at ) > vℓ⋆ at the highest priority class ℓ where they differ. Moreover, for arbitrary ϵℓ ⩾ 0, the Stage-II output satisfies Vℓ (a⋆t ) ⩽ vℓ⋆ + ϵℓ , ∀ℓ, where equality holds if all ϵℓ = 0. Proof: Please see Appendix A. Theorem 1 points out that reducing any Vℓ below vℓ⋆ necessarily increases the shortfall of a higher-priority class above its optimum, and Stage II selects the final action within the class bounds of (9b). Furthermore, if some actions jointly satisfy all hard targets, clearly we have vℓ⋆ = 0. D. Conflict Certificates and Delay-Safe Execution As shown in Fig. 2, at each epoch, xTRUCE ultimately returns a machine-readable conflict certificate for xApp agent renegotiation and selects a verified gNB control action, thereby ensuring that no delayed or unverified arbitration results will be executed. The two outcomes are elaborated below. 1) Conflict Certificate with Prices: At each epoch, the certificate flows along the slow loop to the operator and the relevant xApps (each reading only the entries for its own targets), capturing two key points: the extent to which each hard target was relaxed and which limits of Ht result in such relaxation. The former is the realized shortfall at a⋆t of P2, denoted as ξt⋆ = [gi,m (a⋆t , st )]+ . For the latter, we associate each constraint of P2 with a Lagrange multiplier. When P2 is convex and satisfies a constraint qualification such as Slater’s condition [33], an optimal multiplier measures the local change in the optimum caused by relaxing its constraint, and here we refer to it as a price. Such conditions, combined with complementary slackness, further guarantee that a positive price identifies a binding constraint. Without these, the returned prices are only heuristic local diagnostics without a global guarantee. By carefully examining P2, let µi,m ⩾ 0 denote the price of constraint (9a) and µj ⩾ 0, j ∈ Jphys ∪Joper , that of the j-th limit defining Ht , which together form the price set µt . With these, the conflict certificate is given as
Zt = ξt⋆ , µt , Ft , t , (10) where Ft is produced only at every T cfg -th epoch, collect⋆ ing (v1⋆ , · · · , vL ) at each operator-prescribed candidate acfg t , thereby explaining the choice of the best one. The epoch stamp t prevents an expired certificate from affecting later decisions. In short, Zt provides the information, in machine-readable form, regarding three issues of concern to an xApp or the operator about what was missed, why, and what would help.

The certificate shapes the slow renegotiation loop of Section II-B in two modes. In the autonomous mode, it is returned to the xApp agents to revise their unmet targets, while in the human-in-the-loop mode, it is reported to the operator to adjust priorities or, exceptionally, the operational limits, which is the only way to change Coper . Notably, whether and how fast the renegotiation converges depends on the agentic capabilities. 2) Delay-Safe Action Execution: Solving P1 and P2 may exceed the fixed per-epoch time threshold, denoted as τ . To handle this, the arbiter maintains a standby action astb t , first initialized with abase of Assumption 2 and then updated at t each T cfg -th epoch by the verified Stage-I action associated with the best configuration candidate available by τ . Incorporating all potential cases, the E2 action ultimately output from xTRUCE for execution, denoted as aexec , is determined by t  ⋆ at , if a Stage-II action is available by τ ,    astb , else, if updated at T cfg -th epoch, t aexec = t exec exec  a  t−1 , else, if at−1 ∈ Ht still holds,   base at , otherwise. (11) Note that every action selected by (11) always belongs to Ht , since the first two are verified, aexec t−1 is rechecked, and satisfies Assumption 2. Most importantly, the physical abase t and operational limits are completely decoupled from the quality of the agents, and only the achievability of their intents degrades by priority as proposals worsen or conflicts arise. If no verified a⋆t is available by τ , ξt⋆ and µt are set to ∅ to indicate that no new Stage-II optimality is available, while Ft retains any configuration evaluations completed by then. E. Algorithm and Complexity Analysis To better demonstrate the full picture of xTRUCE for Agentic O-RAN, we summarize its relevant technical points and enclose them in Algorithm 1, as shown on the next page. In terms of the computational complexity of Algorithm 1, line 3 processes at most |Rt | ⩽ N M targets per epoch in O(N M ) time and assembles Ht in time linear in the number of limits in (4) and (5). The dominant cost lies in the optimization calls, i.e., the baseline solve in line 4, the L class solves behind each solve of P1 in line 7 or line 12, and the single solve of P2 in line 14, hence requiring (L + 2) solves per regular epoch and (CL+2) per configuration epoch, where C is the size of the configuration candidate set Ωcfg . Once instantiated into convex programs, every such call is solvable to any fixed accuracy in polynomial time [33]. Meanwhile, verifying an action against Ht in lines 9, 14, and 16 takes one linear pass over the limits and targets, keeping the delay-safe rule (11) affordable at any interruption instant. As such, denoting Qsol as the cost of one solve, running Algorithm 1 over all the T epochs has a polynomial-time overall complexity
of O T N M + (L + 2) T Qsol + (C − 1) L ⌊T /T cfg ⌋ Qsol . IV. U SE C ASE : M ULTI -C ELL AGENTIC O-RAN C ONTROL This section instantiates our xTRUCE for multi-cell agentic O-RAN control by specifying its state, dual-timescale actions, KPI map, rigid constraints, and four xApp roles.

7

Algorithm 1 The Proposed xTRUCE for Agentic O-RAN Input: A, N , ϕ, {dm }m∈M , πbase , T , τ , T cfg , Ωcfg = C {acfg (n) }n=1 , and the operator policies (L, {ϵℓ }, ℓi,m , βi,m ) Output: {aexec , Zt }Tt=1 t 1: Set a certified initial action aexec 0 2: for t ← 1 to T (i.e., the fast control loop) do 3: Obtain st and valid proposals, form Rt , calculate gi,m by (3), and build Ht using aexec t−1 by (4)–(6) exec 4: Start a timer, set astb ← π base (st , at−1 ) and Ft ← ∅ t cfg 5: if t mod T = 0 then 6: for n ← 1 to C do if completed by τ , add 7: Solve P1 under acfg (n) and,
cfg ⋆ ⋆ a(n) , (v1,(n) , . . . , vL,(n) ) to Ft 8: end for 9: If Ft ̸= ∅, set astb to the verified Stage-I action t associated with its lexicographically
best entry ⋆ ⋆ 10: If |Ft | = C, set acfg t , (v1 , . . . , vL ) to the lexicographically best entry of Ft 11: else 12: Retain the previously executed configuration action ⋆ and solve P1 for (v1⋆ , . . . , vL ) 13: end if 14: If Stage I finishes by τ , attempt to solve P2 once and accept (a⋆t , µt ) only if returned and verified by τ 15: Evaluate ξt⋆ at an accepted a⋆t , or set (ξt⋆ , µt ) ← (∅, ∅) otherwise 16: Select aexec by (11), assemble Zt by (10), and return t the relevant entries to each xApp and the full certificate to the operator (i.e., the slow renegotiation loop) 17: end for

epoch t. Let Gb,u,k (t) ⩾ 0 denote the channel power gain from cell b to user u on RB k, and write Gu,k (t) = Gzu (t),u,k (t) for the serving-cell gain. Then, let Iu,k (t) ⩾ 0 be the fixed interference power received by user u on RB k (measured at epoch t − 1 and treated as known at epoch t, which is updated between epochs). Further, Qu (t) ⩾ 0 and λu (t) ⩾ 0 denote the downlink queue backlog and per-epoch traffic-arrival amount for user u, respectively, both in bits. In the meantime, the KPI map ϕ of (1) contains five KPI families, including user rate with dm = 1 plus queue backlog, per-cell energy consumption, caused interference, and load use with dm = −1. First, the bit rate at user u in bits/s is given by   X Gu,k (t)pu,k (t) , Ru (at , st ) = xu,k (t)W log2 1+ xu,k (t)(σ 2 + Iu,k (t)) k∈K (14) where σ 2 is the noise power over one RB. Note that Ru (at , st ) is defined as zero when xu,k (t) = 0, while pu,k (t)/xu,k (t) is the transmit power used when user u is scheduled. The queue update over an epoch of length τ , in bits, is   Qu (t + 1) = Qu (t) − τ Ru (at , st ) + + λu (t). (15) This reflects the queuing delay, since a bounded queue at a given arrival rate implies a bounded delay by Little’s law [35]. The remaining per-cell KPIs of power consumption and interference in W, and dimensionless resource load, are X Eb (at ) = Pbcir αb (t) + Pb,k (t), (16) k∈K

Ibout (at , st ) =

Gb,u,k (t)Pb,k (t),

(17)

k∈K u∈U / b (t)

ρb (at ) = A. Network and E2 Control Actions

X X 1 K

X X

xu,k (t),

(18)

u∈Ub (t) k∈K

Consider B cells indexed by B = {1, · · · , B} serving U users indexed by U = {1, · · · , U } over K RBs indexed by K = {1, · · · , K}, each with bandwidth W Hz. Then, we instantiate the configuration and fast components of at as
acfg (12) t = {αb (t)}b∈B , {zu (t)}u∈U ,
rt at = {xu,k (t)}u∈U ,k∈K , {pu,k (t)}u∈U ,k∈K . (13)

respectively. Among them, Pbcir is a fixed circuit power of an active cell b, and ρb (at ) is its average RB utilization. Unlike the measured Iu,k (t), Ibout (at , st ) depends on the selected transmit powers and can therefore be targeted by an xApp.

Here, αb (t) ∈ {0, 1} is the cell activation/sleep state (1 means activation), while zu (t) ∈ B identifies the active cell serving user u, with αzu (t) (t) = 1 and Ub (t) = {u | zu (t) = b}. At the fast timescale, xu,k (t) ∈ [0, 1] is the fraction4 of epoch t for which RB k is allocated to user u, while pu,k (t) ⩾ 0 is its average transmit power. Notably, the components of (12) and (13) are RAN controls managed at the Near-RT RIC side, where the cell activation, cell-to-user steering, and RB shares are already exposed by existing E2SMs [2], [34]. P Naturally, the cell-level transmit power on RB k is Pb,k (t) = u∈Ub (t) pu,k (t).

In the context of (12) and (13), the physical layer of Section III-B is instantiated by the following four limits:  X  c : Pb,k (t) − αb (t)Pbmax ⩽ 0,  1    k∈K    c : X x (t) − 1 ⩽ 0, 2 u,k (19) u∈Ub (t)      c3 : −xu,k (t) ⩽ 0, xu,k (t) − 1 ⩽ 0,     c4 : −pu,k (t) ⩽ 0, pu,k (t) − xu,k (t)P rb ⩽ 0.

B. RAN State and KPI Models In this use case, the RAN state st contains channel gains, inter-cell interference, queue backlogs, and traffic arrivals at 4 Here, we assume that multiple users can reuse one RB at one time, and multiple RB shares used by one user do not need to be adjacent in frequency.

C. Physical and Operator Limits

Here, Pbmax and P rb are the per-cell and per-RB power limits, respectively. Moreover, constraints c1 –c4 bound the total cell power, total share of each RB, individual RB shares, and the transmit power assigned with each share, respectively. Then, for the operational layer, let N act (t) and N str (t) count the cells changing activation state and the users changing serving cell between epochs t−1 and t, respectively. Likewise,

8

for all (b, u, k) at epoch t, the operator rules are instantiated by the following five limits:  e1 : Rumin − Ru (at , st ) ⩽ 0, ∀u ∈ U prot ,     e2 : |pu,k (t) − pu,k (t − 1)| − ∆p ⩽ 0,   (20) e3 : |xu,k (t) − xu,k (t − 1)| − ∆x ⩽ 0,   act act  e4 : N (t) − ∆ ⩽ 0,     e5 : N str (t) − ∆str ⩽ 0, where the last two only apply at configuration epochs. Constraint e1 enforces the committed rate floor Rumin for each user in the operator-designated protected user group U prot , while e2 –e5 limit consecutive-epoch changes in power by ∆p , RB shares by ∆x , cell activation state by ∆act , and cell-touser steering by ∆str , respectively. Together, (19) and (20) determine Cphys (st ) and Coper (st , aexec t−1 ), and hence Ht in (6). For Stage II, D(at , aexec ) in P2 is computed by the t−1 squared Euclidean distance between P two consecutive fast actions, given by D(at , aexec ) = t−1 u,k xu,k (t) − xu,k (t −
2 P
2 1) + u,k (pu,k (t) − pu,k (t−1))/P rb , where the power differences are normalized by P rb . The baseline action abase t retains the configuration of aexec t−1 and obtains P (xu,k (t), pu,k (t)) from one convex solve that minimizes u,k pu,k (t) subject to c1 –c4 and e1 –e3 . Since only one linear objective is involved without any slacks, it is cheap and fast to solve at each epoch. D. Roles of Four xApp Agents Each agent acts as an xApp running in the Near-RT RIC, empowered by either an external LLM in real-time or a scripted rule, and in this use case, a total of 4 agents (i.e., N = 4) are instantiated targeting different tasks. The first agent, namely QoS assurance agent, targets improving the rate KPI Ru (at , st ) in (14) only for the protected users in U prot , which is set as a hard target with a priority class of 1 (i.e., ℓ = 1). As for each non-protected user, the same QoS agent has a soft rate target by controlling Ru (at , st ) to reduce the backlog Qu (t) of (15). Apart from this, an energy saving agent focuses on a soft target of reducing power consumption Eb (at ) in (16) for each cell, while an interference coordination agent exists aiming at a soft target of caused interference Ibout (at , st ) in (17). Finally, we assume that there is a load balancing agent posting per-cell caps on a soft target of load ρb (at ) in (18). Note that none of these four agents directly commands any
rt RAN-control action variables acfg in (12) and (13), and t , at they only affect the action results via the generated proposals. E. xTRUCE Arbitration and Exact Prices By substituting (14)–(18) into gi,m (at , st ) of (3), P1 and P2 reduce to programs over the fast variables (xu,k (t), pu,k (t)) and the slacks ξ, with acfg fixed between t configuration updates. From Section IV-D, the hard targets are only the protected-rate instances at ℓ = 1, thereby P1 reduces to solving V1 (ξ) only. Building further upon (7), P1 becomes X v1⋆ = rtmin βu ξu2 (21) at , ξ⩾0

s.t.

u∈U prot

θu − Ru (at , st ) ⩽ ξu , ∀u ∈ U prot ,
rt at = acfg ∈ Ht , t , at

(21a) (21b)

where (θu , βu , ξu ) abbreviates the requested rate target, weight, and slack of the corresponding hard pair (i, m) ∈ Rt . As for the instantiation of P2, the soft rate, energy, interference, and load targets of the four agents enter (9) as the terms [gi,m (at , st )]2+ by the same substitution, thus giving: X  2 βu θu − Ru (at , st ) + + η D(at , aexec min t−1 ) rt at , ξ⩾0

u∈U \U prot

+

X  2  2 βbE Eb (at ) − θbE + +βbI Ibout (at , st ) − θbI + b∈B

 2  + βbρ ρb (at ) − θbρ + X s.t. (21a), (21b), βu ξu2 ⩽ v1⋆ + ϵ1 .

(22) (22a)

u∈U prot

Herein, θbE , θbI , θbρ and βbE , βbI , βbρ are the per-cell soft caps and their weights posted by the energy saving, interference coordination, and load balancing agents on (16), (17), and (18), respectively. Constraint (22a) corresponds to constraint (9b) under this instance, using the single output v1⋆ of (21). To address these two instantiated problems, we give the following theorem to establish the solution rationale: Theorem 2 (Guarantee on convexity and exact prices): For any given st and acfg t , both (21) and (22) are convex w.r.t.
cfg rt art t , ξ . If ϵ1 > 0 and there exists an action āt = (at , āt ) ∈ Ht , such that Ru (āt , st ) > Rumin , ∀u ∈ U prot , then both problems hold strong duality with the dual optima attained, and µt in (10) are the exact Lagrange multipliers of (22). Proof: Please see Appendix B. Theorem 2 ensures that (21) and (22) can be directly handed to some off-the-shelf convex programming tools (such as CVXPY [36]) to finalize v1⋆ and a⋆t in polynomial time. Especially, at every T cfg -th epoch, xTRUCE solves (21) under each candidate acfg t , records every completed evaluation in Ft , and solves (22) once under the lexicographically best candidate if all candidates finish by τ . As such, xTRUCE then assembles Zt as the feedback to xApps via (10) and outputs a safe action aexec via (11). It should be emphasized that Theorem 2 only t characterizes the properties of this specific use case rather than of general O-RAN scenarios. Even in non-convex or delayexceeded cases, the actions would still stay on the verified outcome of (11), thereby only the intent-layer optimality is lost, yet without compromising any gNB control safety. V. E XPERIMENTAL E VALUATION In this section, xTRUCE is evaluated exactly in line with the four design goals outlined in Section II-B: i) xApp proposalindependent safety, ii) priority-consistent target satisfaction, iii) certificate-guided LLM renegotiation, iv) delay-aware safe execution. To this end, we conduct multi-cell Python-based simulations and OTA experiments on an OAI/FlexRIC-based O-RAN testbed, using the same xTRUCE implementation. A. Simulation and OTA Setup In the simulations, we instantiate the full control chain of Fig. 1, from the policy output of the SMO/Non-RT RIC, through the xApps and xTRUCE at the Near-RT RIC, to a

9

TABLE I D EFAULT PARAMETERS IN S IMULATION AND OTA E VALUATION Parameters

Simulation

OTA Testbed

Number of cells / users (B / U )

4 / 20 (hexagonal, 500-m ISD)

1 / 4 (single indoor cell, 5G modules)

Spectrum (K × W )

12 × 360 kHz

24 × 360 kHz

Protected users (|U prot |) min ) / Rate floor (Ru

3 protected users / 2 Mbps

1 protected user / 0.5 Mbps

Change limits (∆x , ∆p , ∆act , ∆str )

0.25, 0.25 W, 1 cell, 3 users

0.25, 0.25 W, N/A, N/A

Channel model

UMa path loss [38] + 8-dB shadowing; AR(1) Rayleigh (ρ = 0.349) [39]

Indoor n48 OTA link (SNR ≈ 21 dB); per-RB rate calibrated from measurement

Traffic per user (E[λu (t)]/τ )

6 Mbps (exponential 3.2 Mbps (payload arrivals) offered)

Epoch length (τ )

1s

Powers (Pbmax /Pbcir /P rb ) Noise power (σ 2 ) Optimality tolerance (ϵℓ ) Target weight (βi,m )

0.1 s 10/50/2 W 1.15 × 10−14 W 10−4 (1 + vℓ⋆ ) 1 for all (i, m) ∈ Rt

multi-cell RAN. A configured operator policy represents the A1 policy of the intent-orchestration rApp, which by default enforces the protected-user rate floors as the rigid limit e1 and ranks the protected-rate targets at ℓ = 1, the non-protected-user rate, energy, and interference targets at ℓ = 2, and the load caps at ℓ = 3. The same four xApp agents of Section IV-D use deterministic rules in the safety, priority, and scalability sweeps, while the certificate-renegotiation simulations connect live ChatGPT-5.6 Terra to the QoS xApp and ClaudeSonnet-5 to the energy xApp through their respective vendor APIs. All xApp realizations reuse one structured schema over ZeroMQ [37], which carries the RAN observations, JSON proposals, and their own certificate. In addition, each accepted proposal stays valid for two epochs unless renewed, decoupling LLM generation from per-epoch arbitration. Afterward, we implement Algorithm 1 in Python and formulate its two arbitration stages as parameterized exponentialcone programs in CVXPY, solved at each epoch through a warm-started fallback chain of CLARABEL, ECOS, and SCS. All simulation trials run on a single 2.6-GHz sixcore Intel i7 CPU, and each setting uses 20 screened seeds whose network realizations keep the protected-user rate floors physically reachable. Below xTRUCE, a pair of replaceable state and actuation adapters connects the arbitration core to a custom epoch-level gNB simulator that implements the channel, queue, and power models of Section IV, and rebinding this pair to the live testbed reuses the whole upper chain in the OTA experiments. For practical consistency, the simulations do not differentiate the fast actions of (13) over individual RBs, so that xTRUCE arbitrates one overall spectrum share and one total transmit power per user, while each committed floor is planned against the measured interference plus the maximum one-epoch interference increase allowed by e2 . All gNBrelated parameters of the simulations and OTA experiments are summarized in Table I unless otherwise stated. As for the OTA experiments, we replace the simulated

RAN environment with a live OAI/FlexRIC adapter while keeping the xTRUCE arbitration core unchanged, where deterministic realizations of the same four xApp roles are used for repeatable comparisons. As shown on the right side of Fig. 1, xTRUCE runs as a standalone Dockerized arbitration service co-located with the FlexRIC Near-RT RIC [40] on an NVIDIA DGX Spark [41]. On top of the Python SDK of FlexRIC, the live adapter collects the RAN-state input st from the E2 MAC/RLC/PDCP telemetry and maps the spectrum-share component of aexec into integer quotas over t 24 RBs, which are submitted to the OAI gNB [42] through the FlexRIC Slice SM. Herein, we measure the rate delivered by one RB once in advance, enabling xTRUCE to relate each rate target to an RB quota. Note that the OTA experiments only test the RB allocation rather than the power allocation of xTRUCE, since the deployed FlexRIC Slice SM path carries no power command [40]. The same host runs the OAI 5G Core (v2.1.10), while an NI USRP-2901 SDR [43] operates the OTA cell on band-n48 at 3.61 GHz with a 30-kHz subcarrier spacing. Meanwhile, four commercial 5G user equipment modules simultaneously attach over the air, each carrying a continuous 3.2-Mbps downlink payload offered from the corenetwork side. Accordingly, the OTA experiments focus on evaluating the live E2 measurement-and-control loop, whether every RB-allocation action delivered to the gNB satisfies the applicable constraints under conflicting xApp proposals, and whether (11) rejects late or unverified arbitration results. For comparison purposes, both environments replace only xTRUCE with two benchmark schemes of gNB action execution under conflicting xApp proposals: 1) a Direct scheme, which directly turns the most demanding target of each xApp into the corresponding gNB action without checking its joint feasibility; and 2) a Clipping scheme, which further clips the resulting actions from the Direct scheme and proportionally rescales them to satisfy physical constraints c1 –c4 in (19) at the same time. Neither benchmark acts on the interference and load xApp targets,5 operates on the operator priority and limits, or returns conflict certificates, hence their gaps to xTRUCE precisely quantify what the two-stage arbitration contributes. B. Simulation Results (i) Proposal-independent gNB control safety: Fig. 3 evaluates xTRUCE regarding the performance of rigid-constraint violation as the hallucination level of xApp proposals increases from 0 (no hallucination) to 1 (complete hallucination). Here, we set the hallucination level following [44] to jointly control the probability of corrupting each xApp proposal and its deviation from the valid target. Fig. 3(a) first presents the violation ratios for physical limits c1 –c4 over 600 epochs at each hallucination level under the three schemes. It is observed that the gNB control actions output by xTRUCE and Clipping never violate any physical limit, whereas Direct violates at least one physical limit in 99% of the epochs even without injected hallucination and in 85 to 96% once 5 This is because the QoS and energy xApps have a relatively direct targetto-action mapping relationship, whereas the targets of interference and load xApps require joint coordination for gNB action determination.

60

xTRUCE Clipping Direct

40 20 0 0

0.25

0.5

0.75

80 60 40 20

1

0

0.25

0.5

0.75

(b)

0.075

Over-consumed energy (W)

Rate-target shortfall (Mbps)

0.1

Rate-target shortfall (Mbps)

Fig. 3. Rigid-constraint violation ratios vs. varying proposal hallucination levels: (a) ratio of epochs violating c1 –c4 ; (b) ratio of epochs violating e1 . The shaded bands span the 95% confidence intervals over 20 screened seeds.

Flat at ℓ = 1

0.05 0.025 0 1.5

3 6 12 24 Non-protected users' rate target (Mbps)

(a)

0.1

1

Hallucination level of xApp proposals

0.125

QoS target-met line Target-met region

0

(a)

xTRUCE at ℓ = 1

1

0

Hallucination level of xApp proposals

0.15

10

xTRUCE at ℓ = 2

20

Flat at ℓ = 2

10

Sonnet-5-driven Energy xApp

Over-consumed energy (W)

80

ChatGPT-5.6-driven QoS xApp

100

Rate-target shortfall (Mbps)

100

Proportion of target-unmet rounds (%)

Operational-limit violation ratio (%)

Physical-limit violation ratio (%)

10

Certificate Binary Blind

1 0.1 0.01

Energy target-met line

0.001

5 10 15 Renegotiation round

0

(a)

5 10 15 Renegotiation round

(b)

100

50 ChatGPT-QoS case Sonnet-Energy case

0 Certificate

Binary

Blind

(c) Fig. 5. Certificate-guided renegotiation performance of two live LLMs under three conflict feedback modes: (a) rate-target shortfall w.r.t. ChatGPT-5.6driven QoS xApp; (b) over-consumed energy w.r.t. Sonnet-5-driven energy xApp; (c) proportion of target-unmet rounds with per-run points and means.

0 5 2.5

xTRUCE at ℓ = 3 Flat at ℓ = 3

0 1.5

3 6 12 24 Non-protected users' rate target (Mbps)

(b)

Fig. 4. Realized KPI-target shortfall comparisons under resource overload, induced by raising the non-protected-user rate target: (a) protected-user ratetarget shortfalls (ℓ = 1); (b) non-protected-user rate-target shortfalls (ℓ = 2) (top), and over-consumed energy beyond caps (ℓ = 3) (bottom). Curves and shaded bands show the mean and 95% confidence intervals, respectively.

hallucinated. Under the same settings, Fig. 3(b) then measures the violation ratios of the service-level operational limit e1 (i.e., a committed rate floor of 2 Mbps for each protected user in (20)). It shows that xTRUCE still keeps zero violation, and Direct violates e1 in 30 to 86% of the epochs. Clipping performs even worse here, leaving at least one user below the rate floor in 65 to 92% of the epochs, which means its action stays physically legal as in Fig. 3(a), but its committed services are lost. Therefore, xTRUCE is the only scheme that preserves both physical feasibility and operator-committed rate floors across all tested proposal hallucination levels, thereby demonstrating its proposal-independent gNB control safety. (ii) Priority-consistent KPI satisfaction: Next, Fig. 4 evaluates xTRUCE’s capability of priority-consistent KPI target satisfaction as resource contention intensifies across three operator priority classes (i.e., ℓ = 1, 2, 3). In this test, we declare three hard targets, i.e., offering a 3-Mbps protecteduser rate target at ℓ = 1, a non-protected-user rate target at ℓ = 2, and a 53-W per-cell energy cap at ℓ = 3, whereas the resource contention sweep is controlled by raising the ℓ = 2 rate target from 1.5 to 24 Mbps. Moreover, a dedicated benchmark scheme, namely Flat, is devised that uses the same arbitration mechanism as xTRUCE but assigns all

targets the same priority. Fig. 4(a) first depicts the shortfall performance of ℓ = 1 under the two schemes. It is seen that the gNB control action derived from xTRUCE always keeps the highest-priority rate-target shortfall near zero regardless of the resource overload intensity, whereas the shortfall of Flat grows with the resource contention, up to about 0.1 Mbps. Fig. 4(b) then tests the shortfall performance at ℓ = 2 (top) and ℓ = 3 (bottom) under the same overload levels. With xTRUCE, the rate-target shortfall at non-protected users grows to 21.7 Mbps and the over-consumed energy reaches 4.1 W at the most intensive resource contention, which are precisely the priority concession results described in Theorem 1. In contrast, the Flat curves show that disregarding KPI priorities buys little in return, for instance, the shortfall at ℓ = 2 shrinks by no more than 0.7 Mbps and the over-consumed energy at ℓ = 3 even exceeds our xTRUCE by up to 0.8 W. The above results prove that, however far the resource demand scales, xTRUCE ensures the protection of higher-priority targets before considering lower-priority ones, thereby showcasing its ability to meet KPIs in accordance with operator-assigned priorities. (iii) Certificate-guided renegotiation with live LLM xApps: Further, Fig. 5 validates the conflict renegotiation effectiveness guided by xTRUCE’s certificates, where we study two live LLM-xApp cases, i.e., a ChatGPT-5.6 Terra-driven QoS xApp and a Claude-Sonnet-5-driven energy xApp, each aiming to revise an initially infeasible KPI intent. For comparison, two feedback benchmarks are employed: a Binary mode returning only a one-bit indication of whether the KPI target is met and a Blind mode returning no arbitration feedback to xApps. Together with xTRUCE’s Certificate mode, all three feedback modes observe the same E2-telemetry fields and share the same arbitration process, testing over a total of 16 renegotiation rounds (taking the median of 20 runs for each round). Here, a round is regarded as target-met if its performance

1000

Near-RT delay line

100 Near-RT window

Average case Worst 5% case

10

Epoch ratio of execution action (%)

xTRUCE arbitration time (ms)

11

100 80

100

98

94

88

82 71

60 40 20

The case of atexec = at⋆ Remaining cases in (11)

0

1/5 2/10 3/15 4/20 5/25 6/30

1/5 2/10 3/15 4/20 5/25 6/30

Number of cells/users

Number of cells/users

(a)

(b)

Fig. 6. xTRUCE arbitration timing and action selection under varying physical RAN capacities: (a) medians and min–max ranges over 20 seeds for two timing measures; (b) ratio of epochs executing different execution action cases.

gap does not exceed 0.2 Mbps in the ChatGPT-QoS case or 0.005 W in the Sonnet-Energy case, i.e., the red lines in the figures. With an initial 20-Mbps rate target while keeping a 5.5-Mbps rate floor, Fig. 5(a) first depicts the renegotiation effectiveness of the three modes in the ChatGPT-QoS case. It is observed that Certificate guides the ChatGPT-5.6 agent to adjust its proposal and successfully meet the rate target using only one round, clearly outperforming Binary and Blind. Then, with an initial 50-W energy cap, Fig. 5(b) examines the Sonnet-Energy case. Similarly, Certificate reaches the energyconsumption line within three rounds, while Binary and Blind consistently fail to effectively guide LLM agents. Note that the round-2 rebound is because Sonnet-5 adjusts the energy cap to exactly the energy consumption at round-1, so the naturally fluctuating power consumption briefly exceeds the line. Moreover, Fig. 5(c) counts the proportion of target-unmet rounds, where Certificate yields the minimum in both cases with a mean of 24% against 79 and 99% (ChatGPT-QoS) and 29% against 82 and 96% (Sonnet-Energy), since only Certificate reveals to LLMs where the feasibility boundary lies and how it should be relaxed across its requests. The above demonstrates that xTRUCE can replace these vendor-dependent trial-anderror methods with explicit per-target certificates, enabling rapid, low-overhead recovery from infeasible xApp proposals and ensuring consistency across differing LLM intents. (iv) Delay-safe action execution: In Fig. 6, we examine the arbitration time of xTRUCE and the selected case of (11) as the RAN capacity grows from one to six cells with five users each. For accurate measurement, we exclude network realizations in which the protected-user rate floors are physically unreachable, and the retained runs cover 3000 epochs in total. Specifically, Fig. 6(a) first presents the per-epoch xTRUCE arbitration time at each network size, where the average case is derived from taking the median of all per-epoch arbitration times, while the worst 5% case means the top 5% of epochs taking the longest arbitration times. It is seen that the averagecase time stays between 19 and 98 ms, far below 1s at each median point, and the worst 5% case begins to cross the NearRT line at 30 users, which is just because the arbitration complexity increases with the network scale. Fig. 6(b) then

counts the ratio of epochs in the case of aexec = a⋆t (i.e., a t verified Stage-II action is available within τ ) against that in the remaining cases of (11) (i.e., Stage I&II are not completed in time). The results show that the epoch ratio executing a⋆t is first 100% at 5 users, and then gradually and slowly declines from 98% at 10 users to 71% at 30 users. Such a downtrend is apparent since the arbitration time grows with the RAN capacity as observed in Fig. 6(a), making more epochs hit the delay limit and thus fall back to the remaining cases of (11). Execution records further certify that all 3000 epochs use either a⋆t or one of the remaining verified cases in (11), which means unavailable or delay-exceeded results are never used as execution actions across different network sizes. C. OTA Testbed Results Beyond the above simulations, we finally validate xTRUCE over the air on the O-RAN-compliant OAI/FlexRIC testbed, as illustrated in Fig. 7, where the same four xApps inject hallucinated proposals into a live E2 control loop. (v) Proposal-independent gNB control safety over the air: We first re-examine the real-world gNB control safety under xTRUCE at three fixed proposal hallucination levels of 0.3, 0.5, and 0.8, and compare the results with the Clipping and Direct benchmarks. Similar to Fig. 3, the ratio of epochs in which the control actions satisfy the physical limits c1 –c4 and the ratio of epochs in which these physically feasible actions still violate the operational limit e1 are shown in Fig. 7(a) and Fig. 7(b), respectively. It is seen that xTRUCE remains at a 100% satisfaction ratio for both checks at each hallucination level, whereas Direct satisfies the physical limits in only 69 down to 38% of the epochs. Particularly, Fig. 7(b) demonstrates that even physically feasible actions can still violate e1 as the hallucination grows, for instance, up to 9.4% for Clipping and 24.7% for Direct at the highest level, whereas xTRUCE stays at zero. The above OTA results reconfirm that physical clipping alone cannot preserve the operator-defined service limit, and only xTRUCE preserves gNB control safety. (vi) Delay-safe execution in the live E2 loop: Fig. 7(c) then tests the cumulative distribution function (CDF) of the perepoch processing time of the whole live E2 loop. Concretely, we break the aforementioned fast E2 control loop into three consecutive stages, i.e., RAN state collection over the E2 interface, xTRUCE arbitration, and gNB control action delivery over E2. It is observed that RAN state collection and E2 action delivery complete within 0.4 and 2.4 ms, respectively, in all 540 epochs, while arbitration dominates with a median of 13.3 ms. Moreover, the arbitration CDF meets the per-epoch time threshold, i.e., the 0.1-s epoch length τ , exactly at 89.3% (the marked dot), leaving 10.7% of xTRUCE calls beyond the threshold. Our execution logs also show that all 58 late calls and all 33 in-time calls without a verified a⋆t still use the remaining verified cases in (11). Hence, consistent with the simulation results in Fig. 6, xTRUCE still preserves its safety checks and late-result rejection on a real O-RAN stack. VI. C ONCLUSIONS In this paper, we proposed the xTRUCE system, a provable realization for a multi-xApp conflict-mitigation function in the

60 40 20 0

xTRUCE Clipping Direct

0.3 0.5 0.8 Hallucination level of xApp proposals

(a)

20

1 xTRUCE Clipping Direct

10.7%

{

0.8

15 10 5

0.6 0.4

xTRUCE arbitration E2 action delivery RAN state collection

0.2

0 0.3 0.5 0.8 Hallucination level of xApp proposals

(b)

Per-epoch time threshold

80

25

CDF

100 Conditional operational-limit violation ratio (%)

Physical-limit satisfaction ratio (%)

12

0 0.04 1 10 100 Processing time in the fast control loop (ms)

(c)

Fig. 7. OTA evaluation of xTRUCE under four hallucinated xApps: (a) ratios of epochs meeting c1 –c4 ; (b) ratios of epochs violating e1 among those actions meeting c1 –c4 ; (c) empirical CDFs of fast-control-loop processing times across 540 control epochs. Error bars in (a) and (b) span three repeated OTA tests.

emerging agentic O-RAN. It confined untrusted xApp agents to structured proposals, arbitrated these proposals in two stages along the operator priorities in a provably safe way, and returned a verified gNB control action via E2 and an exact conflict certificate for LLM renegotiation. We finally implemented its multi-process prototype and evaluated it through both simulations and OTA experiments. Results demonstrated a variety of guarantees, covering safe gNB control under severely hallucinated proposals, priority-consistent KPI target satisfaction under resource overload, certificate-guided recovery of infeasible LLM intents across model vendors, and delaysafe per-epoch execution. This work can serve as a pioneer in exploring safe multi-xApp control for agentic O-RAN, where the Near-RT RIC enforces physical limits, operator priorities, and timely execution without relying on the correctness of individual xApps. Since xTRUCE addresses only multi-xApp conflicts and treats interference measured in the previous epoch as constant, extending it to LLM-driven multi-rApps at the Non-RT RIC and incorporating dynamic interference drift would be two promising directions for future work. A PPENDIX A P ROOF OF T HEOREM 1 We fix epoch t throughout this proof. For any at ∈ Ht , the smallest feasible slack is ξi,m = [gi,m (at , st )]+ , hence P1 can be analyzed through Vℓ (at ). Let H(0) = Ht , vℓ⋆ = minat ∈H(ℓ−1) Vℓ (at ), and H(ℓ) = {at ∈ H(ℓ−1) | Vℓ (at ) = vℓ⋆ } for every ℓ ∈ L. The stated compactness of Ht ensures that every minimum is attained and every H(ℓ) is nonempty. If any at ∈ Ht yields a lexicographically smaller vector, then at the first differing class ℓ0 , it would belong to H(ℓ0 −1) while satisfying Vℓ0 (at ) < vℓ⋆0 . This contradicts the definition of vℓ⋆0 , thereby the Stage-I vector is uniquely lexicographically minimal. In addition, any action in H(L) with its smallest feasible slacks is feasible for P2 for arbitrary ϵℓ ⩾ 0. Every feasible pair (at , ξ) of P2 satisfies Vℓ (at ) ⩽ Vℓ (ξ) ⩽ vℓ⋆ + ϵℓ , so the same bound holds for a⋆t . If all ϵℓ = 0 ⋆ and (V1 (a⋆t ), · · · , VL (a⋆t )) differs from (v1⋆ , · · · , vL ), its first differing component would be smaller, contradicting the lexicographic minimality proved above. Hence, Vℓ (a⋆t ) = vℓ⋆ for every ℓ when all ϵℓ = 0. This completes the proof.

A PPENDIX B P ROOF OF T HEOREM 2 Convexity: First, given fixed st , the simplified function
f (p) = W log2 1 + Gu,k (t) p/(σ 2 + Iu,k (t)) is obviously concave in p ⩾ 0. Then, each summand of (14) equals the perspective xf (p/x), which is jointly concave in (x, p) for x > 0 and extends concavely by 0 at x = 0, hence the rate Ru (at , st ) is concave. In this  case, every rate-target  shortfall function is convex, while Qu (t) − τ Ru (at , st ) + + λu (t), i.e., the queue value in (15), is also convex. Meanwhile, the KPIs (16), (17), and (18) are clearly linear w.r.t. art t , as are all limits in (19) and e2 –e3 in (20), while the rate limit Ru ⩾ Rumin defines a convex set by the concavity of Ru . Based on the above, the objective of (21) is a convex quadratic w.r.t. ξ, whereas the objective of (22) is a weighted sum of squared positive-part terms of convex functions and the convex quadratic action-change term D. Therefore, both objectives are convex and every constraint defines a convex set. Strong duality and exact prices: After expressing e2 –e3 as affine inequality pairs, meeting Slater’s condition requires strictness only for e1 , (21a), and the last constraint in (22a). Choosing ξ¯u > [θu −Ru (āt , st )]+ establishes refined Slater for (1) (21). For (22), let at be a Stage-I minimizer with its minimal (1),rt slacks, and define at (ρ) = (acfg + ρārt t , (1 − ρ)at t ). Convexity of the fixed-configuration feasible set and concavity of Ru make at (ρ) feasible with e1 strict. As ϵ1 > 0, sufficiently small (ρ, δ) > 0 with ξu = [θu − Ru (at (ρ), st )]+ + δ make all remaining non-affine inequalities strict. Thus, refined Slater holds [33], proving strong duality, dual attainment, and the stated multiplier interpretation, which ends the proof. R EFERENCES [1] M. Polese, L. Bonati, S. D’Oro, S. Basagni, and T. Melodia, “Understanding O-RAN: Architecture, interfaces, algorithms, security, and research challenges,” IEEE Communications Surveys & Tutorials, vol. 25, no. 2, pp. 1376–1411, 2023. [2] M. Polese, M. Dohler, F. Dressler, M. Erol-Kantarci, R. Jana, R. Knopp, and T. Melodia, “Empowering the 6G cellular architecture with Open RAN,” IEEE Journal on Selected Areas in Communications, vol. 42, no. 2, pp. 245–262, Feb. 2024. [3] L. Bonati, S. D’Oro, M. Polese, S. Basagni, and T. Melodia, “Intelligence and learning in O-RAN for data-driven NextG cellular networks,” IEEE Communications Magazine, vol. 59, no. 10, pp. 21–27, Oct. 2021.

13

[4] M. Polese, L. Bonati, S. D’Oro, S. Basagni, and T. Melodia, “ColORAN: Developing machine learning-based xApps for Open RAN closedloop control on programmable experimental platforms,” IEEE Transactions on Mobile Computing, vol. 22, no. 10, pp. 5787–5800, Oct. 2023. [5] M. Tsampazi, S. D’Oro, M. Polese, L. Bonati, G. Poitau, M. Healy, M. Alavirad, and T. Melodia, “PandORA: Automated design and comprehensive evaluation of deep reinforcement learning agents for Open RAN,” IEEE Transactions on Mobile Computing, vol. 24, no. 4, pp. 3223–3240, Apr. 2025. [6] K. B. Letaief, W. Chen, Y. Shi, J. Zhang, and Y.-J. A. Zhang, “The roadmap to 6G: AI empowered wireless networks,” IEEE Communications Magazine, vol. 57, no. 8, pp. 84–90, Aug. 2019. [7] H. Zhou, C. Hu, Y. Yuan, Y. Cui, Y. Jin, C. Chen, H. Wu, D. Yuan, L. Jiang, D. Wu, X. Liu, J. Zhang, X. Wang, and J. Liu, “Large language model (LLM) for telecommunications: A comprehensive survey on principles, key techniques, and opportunities,” IEEE Communications Surveys & Tutorials, vol. 27, no. 3, pp. 1955–2005, Jun. 2025. [8] L. Bariah, Q. Zhao, H. Zou, Y. Tian, F. Bader, and M. Debbah, “Large generative AI models for telecom: The next big thing?” IEEE Communications Magazine, vol. 62, no. 11, pp. 84–90, Nov. 2024. [9] A. Leivadeas and M. Falkner, “A survey on intent-based networking,” IEEE Communications Surveys & Tutorials, vol. 25, no. 1, pp. 625–655, 2023. [10] F. Jiang, Y. Peng, L. Dong, K. Wang, K. Yang, C. Pan, D. Niyato, and O. A. Dobre, “Large language model enhanced multi-agent systems for 6G communications,” IEEE Wireless Communications, vol. 31, no. 6, pp. 48–55, Dec. 2024. [11] J. Shao, J. Tong, Q. Wu, W. Guo, Z. Li, Z. Lin, and J. Zhang, “WirelessLLM: Empowering large language models towards wireless intelligence,” Journal of Communications and Information Networks, vol. 9, no. 2, pp. 99–112, Jun. 2024. [12] S. Maxenti, R. Shirkhani, M. Elkael, L. Bonati, S. D’Oro, T. Melodia, and M. Polese, “AutoRAN: Automated and zero-touch Open RAN systems,” IEEE Transactions on Mobile Computing, vol. 25, no. 7, pp. 10 112–10 129, Jul. 2026. [13] M. Elkael, S. D’Oro, L. Bonati, M. Polese, Y. Lee, K. Furueda, and T. Melodia, “AgentRAN: An agentic AI architecture for autonomous control of open 6G networks,” 2025, arXiv:2508.17778. [Online]. Available: https://arxiv.org/abs/2508.17778 [14] M. Hoffmann, S. Janji, A. Samorzewski, Ł. Kułacz, C. Adamczyk, M. Dryjański, P. Kryszkiewicz, A. Kliks, and H. Bogucka, “Open RAN xApps design and evaluation: Lessons learnt and identified challenges,” IEEE Journal on Selected Areas in Communications, vol. 42, no. 2, pp. 473–486, 2023. [15] P. B. del Prever, S. D’Oro, L. Bonati, M. Polese, M. Tsampazi, H. Lehmann, and T. Melodia, “PACIFISTA: Conflict evaluation and management in Open RAN,” IEEE Transactions on Mobile Computing, vol. 24, no. 10, pp. 10 590–10 605, 2025. [16] O-RAN Alliance, “O-RAN Working Group 3, Near-Real-Time RAN Intelligent Controller and E2 Interface: Near-RT RIC Architecture,” O-RAN Alliance e.V., Technical Specification ORAN.WG3.TS.RICARCH-R004-v07.00, Release 4, Feb. 2025. [Online]. Available: https://specifications.o-ran.org/download?id=813 [17] O-RAN Alliance, “O-RAN Conflict Mitigation,” O-RAN Alliance e.V., Technical Report O-RAN.WG3.TR.ConMit-R004-v01.00, Oct. 2024. [Online]. Available: https://specifications.o-ran.org/specifications [18] C. Adamczyk and A. Kliks, “Conflict mitigation framework and conflict detection in O-RAN Near-RT RIC,” IEEE Communications Magazine, vol. 61, no. 12, pp. 199–205, Dec. 2023. [19] P. Brach del Prever, N. Mohamadi, S. D’Oro, L. Bonati, M. Polese, Ł. Kułacz, P. Jaworski, A. Kliks, H. Lehmann, and T. Melodia, “Predicting conflict impact on performance in O-RAN,” in Proc. IEEE INFOCOM Workshops, 2026, pp. 1–6. [20] A. Wadud, F. Golpayegani, and N. Afraz, “QACM: QoS-aware xApp conflict mitigation in Open RAN,” IEEE Transactions on Green Communications and Networking, vol. 8, no. 3, pp. 978–993, Sep. 2024. [21] A. Wadud, F. Golpayegani, and N. Afraz, “xApp-level conflict mitigation in O-RAN, a mobility driven energy saving case,” in Proc. IEEE INFOCOM Workshops, May 2025, pp. 1–6. [22] S. D’Oro, L. Bonati, M. Polese, and T. Melodia, “OrchestRAN: Orchestrating network intelligence in the Open RAN,” IEEE Transactions on Mobile Computing, vol. 23, no. 7, pp. 7952–7968, Jul. 2024. [23] A. M. Nagib, H. Abou-Zeid, and H. S. Hassanein, “Safe and accelerated deep reinforcement learning-based O-RAN slicing: A hybrid transfer learning approach,” IEEE Journal on Selected Areas in Communications, vol. 42, no. 2, pp. 310–325, 2024.

[24] A. M. Nagib, H. Abou-Zeid, and H. S. Hassanein, “SafeSlice: Enabling SLA-compliant O-RAN slicing via safe deep reinforcement learning,” in Proc. IEEE International Conference on Machine Learning for Communication and Networking (ICMLCN), 2025, pp. 1–7. [25] M. S. Hossen, Z. Zhang, D. Ron, Y. Liu, and V. K. Shah, “OpenTwin: Digital twin driven closed loop KPM inference and control for Open RAN,” 2026. [Online]. Available: https://arxiv.org/abs/2605.24662 [26] C. Fiandrino, L. Bonati, S. D’Oro, M. Polese, T. Melodia, and J. Widmer, “EXPLORA: AI/ML explainability for the Open RAN,” Proceedings of the ACM on Networking, vol. 1, no. CoNEXT3, pp. 1–26, 2023. [27] ETSI, “Publicly Available Specification (PAS); A1 Interface: General Aspects and Principles (O-RAN.WG2.A1GAP-R004-v04.00),” European Telecommunications Standards Institute, Tech. Rep. ETSI TS 103 983 V4.0.0, May 2025. [Online]. Available: https: //www.etsi.org/deliver/etsi ts/103900 103999/103983/04.00.00 60/ [28] Anthropic, “Introducing Claude Sonnet 5,” [Online]. Available: https:// www.anthropic.com/news/claude-sonnet-5, Jun. 2026, accessed: Jul. 29, 2026. [29] OpenAI, “GPT-5.6 Terra Model,” [Online]. Available: https://developers. openai.com/api/docs/models/gpt-5.6-terra, 2026, accessed: Aug. 6, 2026. [30] ETSI, “Publicly Available Specification (PAS); E2 Interface: General Aspects and Principles (O-RAN.WG3.E2GAP-R003-v04.01),” European Telecommunications Standards Institute, Tech. Rep. ETSI TS 104 038 V4.1.0, Oct. 2024. [Online]. Available: https://www.etsi.org/deliver/ etsi ts/104000 104099/104038/04.01.00 60/ [31] ETSI, “Publicly Available Specification (PAS); O-RAN Security Requirements and Controls Specifications (O-RAN.WG11.SecReqSpecsR003-v09.01),” European Telecommunications Standards Institute, Tech. Rep. ETSI TS 104 104 V9.1.0, Jun. 2025. [Online]. Available: https://www.etsi.org/deliver/etsi ts/104100 104199/104104/ 09.01.00 60/ts 104104v090100p.pdf [32] M. Ehrgott, Multicriteria Optimization. Springer, 2005. [33] S. Boyd and L. Vandenberghe, Convex Optimization. Cambridge University Press, 2004. [34] A. Lacava, M. Polese, R. Sivaraj, R. Soundrarajan, B. S. Bhati, T. Singh, T. Zugno, F. Cuomo, and T. Melodia, “Programmable and customized intelligence for traffic steering in 5G networks using Open RAN architectures,” IEEE Transactions on Mobile Computing, vol. 23, no. 4, pp. 2882–2897, Apr. 2024. [35] J. D. Little and S. C. Graves, “Little’s law,” Building Intuition: Insights from Basic Operations Management Models and Principles, pp. 81–100, 2008. [36] S. Diamond and S. Boyd, “CVXPY: A Python-embedded modeling language for convex optimization,” The Journal of Machine Learning Research, vol. 17, no. 1, pp. 2909–2913, 2016. [37] P. Hintjens, ZeroMQ: Messaging for Many Applications. O’Reilly Media, 2013. [38] 3GPP, “Evolved Universal Terrestrial Radio Access (E-UTRA); Further Advancements for E-UTRA Physical Layer Aspects,” 3rd Generation Partnership Project (3GPP), TR 36.814 V9.0.0, 2010. [39] K. E. Baddour and N. C. Beaulieu, “Autoregressive modeling for fading channel simulation,” IEEE Transactions on Wireless Communications, vol. 4, no. 4, pp. 1650–1662, 2005. [40] R. Schmidt, M. Irazabal, and N. Nikaein, “FlexRIC: An SDK for next-generation SD-RANs,” in Proc. 17th ACM Int. Conf. Emerging Networking Experiments and Technologies (CoNEXT), Dec. 2021, pp. 411–425. [41] NVIDIA, “NVIDIA DGX Spark User Guide,” [Online]. Available: https://docs.nvidia.com/dgx/dgx-spark/index.html, 2026, accessed: Jul. 29, 2026. [42] F. Kaltenberger, G. de Souza, R. Knopp, and H. Wang, “The OpenAirInterface 5G new radio implementation: Current status and roadmap,” in Proc. 23rd Int. ITG Workshop Smart Antennas (WSA), Apr. 2019, pp. 134–138. [Online]. Available: https://www.eurecom.fr/ publication/5822 [43] National Instruments, USRP-2901 Specifications, Jul. 2017, [Online]. Available: https://download.ni.com/support/manuals/374925c.pdf. Accessed: Jul. 29, 2026. [44] J.-T. Huang, J. Zhou, T. Jin, X. Zhou, Z. Chen, W. Wang, Y. Yuan, M. R. Lyu, and M. Sap, “On the resilience of LLM-based multiagent collaboration with faulty agents,” in Proceedings of the 42nd International Conference on Machine Learning, ser. Proceedings of Machine Learning Research, vol. 267. PMLR, 2025, pp. 26 202–26 226. [Online]. Available: https://proceedings.mlr.press/v267/huang25ay.html

Related documents

• Reduce Once, Verify Many: Verifying Isolation Guarantees via Hierarchical Abstractions#441776
• CVE-2026-88806 — HIGH 7.5#1040053
• OpenComputer: Verifiable Software Worlds for Computer-Use Agents#204842
• ClawGuard: A Runtime Security Framework for Tool-Augmented LLM Agents Against Indirect Prompt Injection#10250
• CLOADER: Evading Security Mobile Defenses via Runtime Obfuscation and Adaptive Hooking Tactics#1049137