Experimental Classification of xApp Conflicts in O-RAN: Slicing vs. Per-UE Scheduling

Experimental Classification of xApp Conflicts in O-RAN: Slicing vs. Per-UE Scheduling Rashmi Sharan Sinha∗ , Merim Dzaferagic† , Marco Ruffini† , and Nima Afraz∗ ∗ School of Computer Science, University College Dublin, Dublin, Ireland

arXiv:2610.32254v1 [cs.NI] 23 Oct 2026

† School of Computer Science and Statistics, Trinity College Dublin, Dublin, Ireland

Abstract—Concurrent applications (xApps) in the Near-RealTime RAN Intelligent Controller (Near-RT RIC) of the Open Radio Access Network (O-RAN) can issue control intents that are jointly infeasible when they act on hierarchically coupled radio resources. This paper experimentally studies an interaction between slice-level physical resource block (PRB) allocation and per-user-equipment (UE) scheduling. We implement a utilisationaware slicing control (the spectral-efficiency xApp) that reclaims a fixed fraction of the baseline allocation from under-utilised slices and redistributes pooled capacity to saturated slices. The control logic is exercised in simulation and on a 5G testbed comprising an OCUDU-based next-generation NodeB (gNB), an Open5GS core, a Universal Software Radio Peripheral (USRP) X310, and five commercial off-the-shelf (COTS) UEs. Because the gNB counters available in this testbed are UE-keyed but not slicelabelled, the slicing control derives a per-slice throughput proxy from core-side traffic measurements. A command-bus detector evaluates explicitly defined control-intent conditions: a per-UE floor above its parent-slice cap, aggregate UE floors above the cell budget, and repeated slice-target changes within a specified window. Over a 276-cycle continuous run, the detector logged 147 per-slice floor–cap violations, 49 shared-budget over-subscription episodes, and 11 allocation-oscillation episodes. Against the conventional static slice split replayed on the same load trace, the slicing control reduces unmet demand by 12–33 % and idle allocation by 21–23 %. The results demonstrate reproducible cross-granularity control-intent interactions on real hardware and provide an experimental basis for analysing conflict detection in O-RAN. Index Terms—O-RAN, network slicing, xApp, resource allocation, conflict, spectral efficiency, physical resource block, simulation, testbed.

I. I NTRODUCTION The Open Radio Access Network (O-RAN) architecture enables independently developed applications (xApps) to monitor and control RAN functions through the Near-Real-Time RAN Intelligent Controller (Near-RT RIC) using standardised interfaces [1], [2]. This programmability supports flexible, multi-vendor control and forms part of the broader evolution towards artificial-intelligence (AI)-powered network control, in which autonomous decisions must eventually be coordinated across multiple network domains, functions, and control timescales [3]. However, this programmability also creates a feasibility problem when xApps issue decisions over shared radio resources at different control granularities. In particular, a slice-level xApp can configure the physical resource block (PRB) budget of a network slice while a per-user-equipment (UE) scheduling xApp assigns a PRB guarantee to a UE within that slice. Because each UE-level allocation must remain

xApp A Equal Slicing

xApp B Spectral Efficiency

xApp C UE Scheduler

baseline setup

dynamic slice control

per-UE guarantee

dynamic

initial

Slice-level PRB baseline

dynamic

Slice-level PRB target

per-slice load

Per-UE PRB floor

slice policy slice policy N2/N3

5G gNB OCUDU + USRP X310

5G Core Open5GS

UE policy RF

COTS UEs 3 slices

Command bus

logged xApp control intents

Conflict Detector classify control intents

Fig. 1. Experimental architecture.

feasible within the budget of its parent slice, a UE floor above the corresponding slice cap produces an incompatible control state. Concurrent UE floors can also exceed the shared cellwide PRB budget. Experimental studies have demonstrated xApp conflicts on physical O-RAN testbeds where applications act at the same resource-management level, but cross-granularity interactions between slice-level allocation and per-UE scheduling remain insufficiently characterised experimentally. In this paper, we implement and evaluate cross-granularity interaction between slice-level reallocation and per-UE scheduling, first in simulation and then on a physical ORAN testbed. A command-bus detector evaluates the resulting control-intent conditions, while a core-derived throughput proxy provides per-slice load information when slice-labelled measurements from the next-generation NodeB (gNB) are unavailable. Our contributions are as follows. • We implement and evaluate a cross-granularity O-RAN control scenario that combines slice-level reallocation with per-UE scheduling in simulation and on a physical 5G testbed. • We define and evaluate a command-bus detector for parent-slice floor–cap violations, shared-budget oversubscription, and allocation-oscillation events, and show that the budget-conserving slice policy cannot create shared-budget over-subscription in isolation. II. R ELATED W ORK Platforms such as SCOPE [4] and OpenRAN Gym [5], with open-source stacks such as srsRAN [6] and Open5GS [7],

TABLE I C OMPARISON WITH PRIOR WORK ON X A PP CONFLICTS . SDR: SOFTWARE - DEFINED RADIO ; OTA: OVER THE AIR ; MRO: MOBILITY ROBUSTNESS OPTIMISATION ; Q O S: QUALITY OF SERVICE . Work

Platform

Interacting xApps

Conflict classes

Scope

[9]

Analytical example

Direct, indirect

Detection, mitigation (game-theoretic)

[10]

Simulation

Same parameter, same level Same parameter, same level MRO vs. energy saving 5–50 synthetic xApps Two, same control target

Direct, indirect, implicit Direct

QoS-aware mitigation

Direct, indirect, implicit Direct

AI detection, classification

Two, slice-level PRB Slice-level and per-UE (crossgranularity)

Direct

Detection, mitigation

Direct, indirect, implicit

Detection; core-derived load proxy; static-split comparison

[11]

Simulation

[12]

Simulation

[13]

Testbed, SDR, 1 COTS UE [14] Testbed, OTA, 3 COTS UEs Our work Testbed, OTA, 5 COTS UEs

3. The total downlink PRB budget of the cell is normalised to 100 %. Let cs denote the PRB share assigned to slice s ∈ S, and let Us denote the set of UEs associated with that slice. At the slice level, the slicing xApp configures the minimum and maximum PRB shares of each slice; here mins = maxs = cs , so the configured value acts as a fixed allocation during a control cycle, subject to X cs ≤ 100. (1) s∈S

Detection, mitigation

Detection, mitigation (demo)

At the UE level, the scheduling xApp assigns a guaranteed PRB floor gu to UE u, which belongs to a parent slice s(u) ∈ S and is addressed by its gNB distributed-unit F1 Application Protocol (gNB-DU-UE-F1AP) identifier. Since UE-level guarantees are realised within the parent-slice budget, X gu ≤ cs , ∀s ∈ S. (2) u∈Us

have enabled xApp evaluation on software-defined radios [8]. Conflict management among xApps has received increasing attention: Wadud et al. formulated xApp coordination in the Near-RT RIC as a game-theoretic problem [9], introduced quality-of-service (QoS)-aware mitigation through QACM [10], studied xApp-level mitigation for interacting mobility and energy-saving loops [11], and considered AIassisted detection, classification, and mitigation [12]. These works address mechanisms for resolving conflicting objectives in simulation or on analytical examples. Closest to this work, Sultana et al. demonstrated directconflict detection and mitigation with a single UE on an endto-end testbed with an O-RAN SC Near-RT RIC, srsRAN, Open5GS, and a USRP X310, comparing xApp control messages that address the same target [13], and later evaluated detection and mitigation over the air with three UEs and two xApps independently modifying slice-level PRB allocations [14]. Their interactions concern xApps acting on the same slice-level target. Table I positions the present work. It addresses a different gap: xApps operating at different but hierarchically coupled granularities, where a slice-level control sets the PRB budget of a slice and a per-UE scheduler requests a floor for a UE within it, so that the control intents must satisfy both a parentslice feasibility condition and the shared cell budget. We reproduce these cross-granularity conditions on hardware with a core-derived per-slice load proxy that survives UE radioidentifier changes, and distinguish the budget-conserving slice policy from the over-subscription introduced by concurrent per-UE floors. III. S YSTEM M ODEL AND BACKGROUND We consider a single 5G cell serving a set of network slices S = {1, 2, 3}, identified by Slice/Service Type (SST) 1, 2, and

which, with one scheduled UE per slice as here, reduces to gu ≤ cs(u) .

(3)

Interpreted as simultaneous guarantees, the floors are also coupled through the cell budget, X gu ≤ 100. (4) u∈U

Violations of (2)–(4) indicate incompatible control intents between the slice-level and UE-level xApps. IV. P ROPOSED X A PPS Fig. 1 summarises the three xApps and their corresponding control targets. A. xApp A: Equal Slicing Divider xApp A initialises the slice-level PRB allocation as B = [34, 33, 33]. setting mins = maxs = Bs for each slice, and is then disabled, leaving xApp B as the sole writer of the slice-level policy. B. xApp B: Spectral-Efficiency Reallocation xApp B performs periodic slice-level PRB reallocation with a configured inter-cycle sleep of 2 s. Because each cycle also contains a one-second byte-count sampling window and three policy pushes to the gNB, the achieved control period on the testbed is about 3.7 s (median 4 s); all durations reported in Section VII are measured from log timestamps, while cycle counts are exact. Each cycle it (i) estimates the utilisation of each slice, (ii) computes target shares by the policy below, reclaiming from under-utilised slices and feeding saturated ones, and (iii) applies them at the gNB. Utilisation relative to the baseline. For slice i with baseline allocation Bi and measured usage ui , both expressed as percentages of the total cell capacity, we define the normalised utilisation as ui . (5) ρi = Bi

TABLE II D ECISION RULES OF THE SPECTRAL - EFFICIENCY X A PP. ρi

TABLE III O PERATIONAL INTERPRETATION OF THE CONFLICT CLASSES USED BY THE DETECTOR , AND EPISODES DETECTED OVER THE 276- CYCLE CONTINUOUS RUN (20 S DE - DUPLICATION ).

Action on slice i

State

ρi < 0.5 Under-utilised Target 0.75Bi ; reclaim 0.25Bi to pool. 0.5 ≤ ρi < 1 Nominal Retain baseline Bi . ρi ≥ 1 Saturated Target Bi +5 if pool ≥ 5 pts.

Class

Count 147 49 11

(extract)

(feed)

The utilisation is referenced to the fixed baseline Bi rather than the current reallocated share, so that the control decision itself does not change the reference in the next cycle; normalising against a recently reduced allocation would make an underutilised slice appear immediately more loaded and induce unnecessary switching between allocation states. Decision rules. The reallocation policy is summarised in Table II. A slice with ρi < 0.5 is classified as under-utilised, and 25 % of its baseline allocation is reclaimed into a shared resource pool. For 0.5 ≤ ρi < 1, the baseline allocation is retained. A slice with ρi ≥ 1 is classified as saturated and is assigned an additional five percentage points, provided that the shared pool contains at least five percentage points of available capacity. Smoothing. Because real traffic is bursty, the xApp averages the last three readings before applying the rules. Budget conservation. An important property of the rules is that the sum of the targets plus the pool always equals 100 %. Reclaiming moves PRBs from a slice into the pool without changing the total, and feeding moves PRBs from the pool to a slice, again without changing the total. Formally, if Ti is the target of slice i and P is the pool, X X Ti + P = Bi = 100 %. (6) i

Condition

A UE-level floor exceeds the cap of its gu > cs(u) parent slice P Indirect Aggregate UE guarantees exceed the u gu > 100 % shared cell budget Implicit Repeated changes in a slice target oc- ≥ 4 target changes cur within the detector window

Algorithm 1: Spectral-efficiency xApp (one cycle) 1: read baseline B1 , . . . , Bn from file 2: ui ← smoothed measured usage of slice i 3: Ti ← Bi for all i; P ← 0 4: for each slice i do 5: if ui /Bi < 0.5 then 6: Ti ← 0.75 Bi ; P ← P + 0.25 Bi 7: for each slice i with ui /Bi ≥ 1.0 do 8: if P ≥ 5 then Ti ← Ti + 5; P ← P − 5 9: write Ti to the gNB for every slice

Interpretation

Direct

i

The xApp therefore never allocates more PRBs than the cell contains; Section V shows that this property determines which conflicts the design can create. The full procedure is listed in Algorithm 1. C. xApp C: Per-UE Scheduling xApp C implements UE-level resource control by assigning a guaranteed PRB floor gu to a selected UE u. In the experimental configuration, one instance of xApp C is associated with each slice, and each instance sets gu = 40 %. The resulting UE-level constraint is evaluated against the PRB cap cs(u) of the UE’s parent slice, as defined in Section III. Thus, whenever gu > cs(u) , the UE-level guarantee and slice-level allocation are not jointly feasible.

Since the focus is detection and classification rather than resolution, xApp C applies its UE-level control independently of xApp B, without any mitigation, so that the crossgranularity interactions can be observed and classified from the logged intents. V. C ONFLICT TAXONOMY AND D ETECTION Building on the established O-RAN conflict categories, we define the detector-observable conditions of Table III, tailored to the interaction between slice-level PRB allocation and perUE scheduling, and identify conflict events from the logged xApp control intents. Each xApp records its control intent (timestamp, source xApp, control target, slice and UE identifiers, requested PRB value) on the shared command bus of Fig. 1; commands within one observation interval are evaluated jointly against the conditions in Table III. A consequence of the conservation property (6) is that the proposed spectral-efficiency xApp cannot create an indirect conflict on its own. Because its perslice targets always sum to at most 100 %, the shared budget is never over-subscribed, and the indirect condition is never met. To register an indirect conflict one needs an actuator that guarantees, across several slices, more than the whole budget—for example, the per-UE scheduler guaranteeing floors on three slices that sum beyond 100 %, together with a detector that counts per-UE floors toward the shared-budget check. We construct exactly this situation in Section VII. VI. E XPERIMENTAL S ETUP The testbed comprises an Ettus Universal Software Radio Peripheral (USRP) X310 software-defined radio (SDR) driven by an OCUDU-based gNB (a centralised unit/distributed unit (CU/DU) running on a server; OCUDU is the opensource continuation of the srsRAN CU/DU), an Open5GS 5G standalone (SA) core, and commercial off-the-shelf (COTS) smartphones acting as UEs across the three slices. Fig. 2 shows the physical setup: the radio is ceiling-mounted about 3.5 m above the table holding the core/RIC laptop and the five handsets. The radio operates in band n78 with a 40 MHz channel. xApps communicate with the gNB over its remotecontrol interface. Table IV lists the main parameters.

(a) Simulation

(b) Testbed (5 COTS UEs)

175

utilisation (%)

150 125 100 75 50 25 0

0

2

4

6

8

control cycle (2 s each) slice 1

slice 2

slice 3

162 direct conflict

164

166

control cycle (2 s each)

indirect conflict

168

170

implicit conflict

Fig. 3. Spectral-efficiency xApp over ten control cycles: (a) simulation, cycles 0–9, with synthetic load; (b) testbed, cycles 161–170 (33 s), with five COTS UEs. Fig. 2. Testbed setup. TABLE IV T ESTBED PARAMETERS . Parameter

Value

Radio gNB Core User equipment Slices Baseline split Reclaim / feed Control cadence

USRP X310, band n78, 40 MHz OCUDU-based CU/DU Open5GS 5G SA 5 COTS smartphones (UEs across 3 slices) SST 1, 2, 3 34 / 33 / 33 % 25 % of baseline / +5 points 2 s sleep (≈3.7 s achieved); smoothing over 3 cycles

A. Core-Based Per-Slice Measurement The gNB exposes UE-level PRB counters, but they are not slice-labelled and are indexed by radio identifiers that change after UE re-attachment, so a persistent mapping to slices cannot be assumed. We therefore measure at the core, where a subscriber’s slice and address are stable across radio re-attachments. Each phone’s slice is read from the subscriber database (subscriber identity to SST) and its current address from the session-management logs (subscriber identity to IP), giving an address-to-slice map. Downlink bytes per address are counted at the core over a one-second window and summed per slice, yielding a per-slice throughput that serves as a proxy for PRB usage. Concretely, let ri be the measured downlink rate of slice i over the sampling window and C the cell’s deliverable capacity. We express the slice’s usage as a percentage of the whole cell, ri ui = 100 , (7) C and feed ui into the utilisation ρi = ui /Bi used by the rules of Section IV. C is set to the achievable rather than the nominal capacity, since the throughput of a software-defined radio is bounded well below the theoretical maximum. This is a throughput proxy, not a PRB measurement, but it is immune to the radio-identifier churn that defeats the gNBside counters. The map is rebuilt every 10 s, so a phone that re-attaches with a new address is picked up automatically. VII. R ESULTS AND D ISCUSSION We evaluate the design first in simulation and then on the hardware testbed.

A. Simulation Before deploying on hardware, we ran the spectralefficiency xApp in simulation, driving the real decision logic of Algorithm 1 with a synthetic per-slice load model and the same three per-UE scheduler floors. Fig. 3(a) shows ten control cycles. In simulation the synthetic load crosses the 50 % and 100 % thresholds smoothly, so every reclaim and feed is a clean step in the targets, and the three floors produce direct and indirect conflicts every cycle. On the testbed (Fig. 3(b)) the same reclaim-and-feed pattern appears over the same number of cycles, but utilisation jumps by tens of percentage points between cycles; this is why the three-cycle smoothing exists and why the pool fills and empties faster than in simulation. The simulation therefore validates the control logic, and the testbed validates it under real load; the two are not expected to agree numerically. B. Testbed: Spectral-Efficiency Behaviour Fig. 4 shows the spectral-efficiency xApp reallocating PRB capacity through the shared pool: under-utilised slices are reduced toward 0.75Bi , and saturated slices receive five percentage points only when the pool holds at least five. In one control cycle, slice 1 reached 116 % utilisation relative to its baseline and was increased from 34 % to 39 %, while slice 2, at 34 % utilisation, was reduced from 33 % to 24.8 %. Slice 3 remained within the nominal utilisation range and retained its 33 % allocation. Table V compares the 36-cycle window of Fig. 4 with the first 150 cycles of the continuous run in Fig. 5. The two are different load regimes rather than the same scenario at two time scales: the median utilisation rises from 68.5 % to 93.0 %, the share of slice-cycles in the saturated state doubles from 23.1 % to 44.9 %, and the share in the under-utilised state falls from 35.2 % to 20.7 %. Because the pool is filled only by under-utilised slices, the policy’s reach collapses with load: a feed was possible (pool ≥ 5 points) in 47.2 % of cycles in the short window but in only 18.7 % of cycles in the continuous run. The feed rate is therefore bounded by the pool rather than by demand, and highly loaded slices can remain above their baseline utilisation after reallocation. The policy redistributes available capacity without eliminating overload. Table V also compares the dynamic policy with the conventional static split of xApp A (34/33/33 %, no reallocation), obtained by replaying the static allocation on the load trace

Control cycles (measured duration) 36 (134 s) 150 (561 s) Median / 90th-pct. utilisation ρi 68.5 / 121.0 % 93.0 / 154.0 % Slice-cycles saturated (ρi ≥ 1) 23.1 % 44.9 % Slice-cycles under-utilised (ρi < 0.5) 35.2 % 20.7 % Mean pool 6.9 % 3.3 % Cycles with pool ≥ 5 pts (feed possible) 47.2 % 18.7 %

180 160 140 120 100 80 60 40 20 0

77.5 / 75.8 12.0 / 13.7 19.2 / 24.2

full (100%)

reclaim (<50%)

50 0

feed needs pool

10

5%

0 35 30 25

0

20

40

60

80

100

120

control cycle (2 s each)

140

Fig. 5. Sustained operation over the first 150 cycles (561 s) of the continuous run: utilisation (top), pool (middle) and PRB target (bottom).

slice 1

slice 2

slice 3

direct conflict

indirect conflict

implicit conflict

175 150

5%

utilisation (%)

feed needs pool

10 0

37.5 35.0 32.5 30.0 27.5 25.0

125 100 75 50 25 0

0

50

100

150

control cycle

200

250

175 150

5 slice 1

slice 3

full (100%)

100

10 slice 2

15 slice 3

20

25

control cycle (2 s each) direct conflict

30

indirect conflict

35

utilisation (%)

PRB target (%)

pool (%)

utilisation (%)

Per cycle, dynamic / static (% of cell budget) Demand served 65.1 / 63.7 Unmet demand 2.8 / 4.2 Idle allocation 28.0 / 36.3

utilisation (%)

Fig. 5

slice 2

150

pool (%)

Fig. 4

slice 1 200

PRB target (%)

TABLE V Q UANTITATIVE COMPARISON OF THE SHORT WINDOW (F IG . 4) AND THE CONTINUOUS RUN (F IG . 5), AND OF THE DYNAMIC POLICY AGAINST THE STATIC 34/33/33 % SPLIT REPLAYED ON THE SAME LOAD TRACE .

125 100 75 50 25

implicit conflict

Fig. 4. Spectral-efficiency xApp on the testbed over a 36-cycle (134 s) window. Top: per-slice utilisation with conflicts at their time of occurrence. Middle: the shared pool. Bottom: PRB targets.

measured under the dynamic policy; this is a counterfactual on the same trace, not a second live run. Relative to the static split, the dynamic policy reduces unmet demand by 33 % in the short window and by 12.5 % in the continuous run, and idle allocation by 23 % and 21 %, whereas the demand served rises by only about 2 % because the five-point feed is deliberately small. That the decisions reach the radio is confirmed over the full 276-cycle run: a +5-point target change was followed by a mean change in delivered usage of +7.0 % in the next cycle (n = 78), a −8.25-point change by −6.4 % (n = 78), and an unchanged target by −0.02 % (n = 669). Delivered usage nevertheless exceeded its own cap in 13 % (Fig. 4) and 39 % (Fig. 5) of slice-cycles, so the configured max share acts as a weighted share rather than a hard ceiling in this gNB build. C. Testbed: Conflicts We activated one instance of xApp C per slice, each assigning a 40 % PRB floor to one UE, while xApp B continued to update the slice-level caps. Under the operational definitions in Table III, the detector records a Direct event when gu > cs(u) ,

0

162

164

166

control cycle

168

170

Fig. 6. Conflicts over the continuous run. Top: the full run with all conflicts marked. Bottom: a 33 s zoom of the boxed region where individual conflicts are legible.

P an Indirect event when u gu > 100 %, and an Implicit event when the slice target satisfies the defined oscillation criterion. Over the 276-cycle (17.1 min) continuous run the scheduler fired 69 times, once every 15 s. The detector de-duplicates an identical conflict signature within a 20 s cooldown, so it logged 147 Direct, 49 Indirect, and 11 Implicit episodes (Table III); the Direct and Indirect counts are therefore bounded by run length divided by cooldown rather than by how often the condition held, which was every activation. As shown in Fig. 6, Direct and Indirect markers arrive in lock-step because each synchronous activation produces three per-slice floor– cap violations and one shared-budget violation, giving the 147 = 3 × 49 relationship, whereas the Implicit markers cluster where a utilisation trace crosses a threshold repeatedly, which is the visual reason for the caution applied to them in Section VII-D. The counts classify logged control intents and do not quantify UE-level impact; conflict resolution was disabled throughout.

D. Budget Conservation and Robustness Three checks address whether the budget and correct UE-level control hold under delayed, rejected, or identifierperturbed updates. First, conservation (6) holds exactly in all 276 cycles of the policy arithmetic, and also after the integer quantisation applied at the actuator: the pushed slice shares summed to 100 in 127 cycles and to 97, 92, 89, or 84 in the remaining 149, never above 100, the shortfall being the withheld pool. Second, all 1035 commands (828 slice, 207 UE) reached the gNB with zero transport failures or timeouts; each push is a synchronous request–response, and the gap between consecutive commands within a cycle, which bounds the round trip, had a 95th percentile of 1 ms (n = 552, the timestamp resolution), so delayed updates are not a factor here. Third, the gNB rejected 11 of the 207 UE pushes (5.3 %) in five episodes, because xApp C addresses a UE by a static gNB-DU-UE-F1AP index that goes stale when the handset re-attaches; every episode recovered on the next activation, and 59 of the 69 activations had all three floors accepted. No slice push was rejected, since slices are addressed by SST, and the core-side load proxy was unaffected because it is keyed by subscriber and its address-to-slice map is rebuilt every 10 s. UE-level control is thus identifier-fragile on this platform whereas slice-level control and the measurement are not; the detector evaluates logged intents, so the rejected pushes are included in the Direct counts. E. Discussion The spectral-efficiency control performs the intended reclaim-and-feed operation under real traffic, although hardware behaviour is far more variable than in simulation: the testbed exhibits rapid fluctuations and strong load asymmetry across slices, and Table V quantifies how this limits the policy’s reach. Utilisation above 100 % means the usage proxy exceeds the fixed baseline (ρi = ui /Bi ), not physical PRB use beyond the radio resources. Shared-budget violations arise only when the three 40 % UE guarantees are considered jointly, since xApp B itself conserves the budget. The 11 events labelled Implicit should be interpreted more cautiously. They are allocation oscillations satisfying the detector’s operational criterion, but the experiments do not establish that they are caused by inter-xApp interaction, since threshold crossings driven by variable traffic can produce the same behaviour. We therefore report them as Implicit under our operational interpretation rather than as definitive evidence of an O-RAN implicit conflict. Finally, the conflict counts quantify incompatibilities among logged control intents, not their end-user consequences; UE-level throughput, latency, or service degradation per event is not measured here. VIII. C ONCLUSION This work experimentally investigated cross-granularity xApp interaction between slice-level PRB control and per-UE scheduling in O-RAN. The spectral-efficiency xApp reclaimed capacity from under-utilised slices and redistributed it to

saturated slices while conserving the cell-wide PRB budget in every cycle, before and after actuator quantisation. Against the static slice split replayed on the same load trace, it reduced unmet demand by 12–33 % and idle allocation by 21–23 %, with its reach bounded by the pool under heavy load. On the hardware testbed, the detector consistently identified per-slice floor–cap violations and shared-budget over-subscription (147 and 49 events, the expected 3:1 ratio). Allocation oscillations were observed under variable traffic but not attributed to inter-xApp interaction, and UE-level control proved identifierfragile where slice-level control was not. The reported conflicts are incompatibilities among control intents rather than measured UE-level degradation; future work will measure UElevel impact, isolate the causal interaction between competing xApps, and evaluate mitigation strategies on the testbed. As the RAN moves towards AI-native control, the logged intents and detector labels produced here are the hardware-derived training data that learned conflict detection [12] will require. ACKNOWLEDGMENT This work was supported by Research Ireland CONNECT-2 grant 13/RC/2077-P2. R EFERENCES [1] O-RAN Alliance, “O-RAN Architecture Description,” O-RAN Alliance, O-RAN.WG1 Technical Specification, 2023. [2] 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. [3] M. Dzaferagic et al., “Decentralized ai-control framework for multiparty multi-network 6g deployments,” in 2025 IEEE International Conference on Communications Workshops (ICC Workshops). IEEE, 2025, pp. 1227–1232. [4] L. Bonati, S. D’Oro, S. Basagni, and T. Melodia, “SCOPE: An Open and Softwarized Prototyping Platform for NextG Systems,” in Proc. ACM MobiSys, 2021. [5] L. Bonati et al., “OpenRAN Gym: AI/ML Development, Data Collection, and Testing for O-RAN on PAWR Platforms,” Computer Networks, vol. 220, 2023. [6] I. Gomez-Miguelez et al., “srsLTE: An Open-Source Platform for LTE Evolution and Experimentation,” in Proc. ACM WiNTECH, 2016. [7] S. Lee, “Open5GS: Open-Source Implementation of 5G Core and EPC,” Software. [Online]. Available: https://open5gs.org [8] Ettus Research, “USRP X310 Software Defined Radio,” Product datasheet. [9] A. Wadud, F. Golpayegani, and N. Afraz, “Conflict Management in the Near-RT-RIC of Open RAN: A Game Theoretic Approach,” in Proc. IEEE Cybermatics, 2023, pp. 479–486. [10] ——, “QACM: QoS-Aware xApp Conflict Mitigation in Open RAN,” IEEE Transactions on Green Communications and Networking, vol. 8, no. 3, pp. 978–993, 2024. [11] ——, “xApp-Level Conflict Mitigation in O-RAN, a Mobility Driven Energy Saving Case,” in Proc. IEEE INFOCOM Workshops, 2025, pp. 1–6. [12] ——, “AI-Powered Conflict Management in Open RAN: Detection, Classification, and Mitigation,” Computer Networks, vol. 286, p. 112432, 2026. [13] A. Sultana, F. Bashar, M. R. Chowdhury, and A. P. Da Silva, “A software-defined radio based o-ran platform for xapp conflict detection and mitigation,” in MILCOM 2024 - 2024 IEEE Military Communications Conference (MILCOM), 2024, pp. 686–687. [14] A. Sultana, C. Adamczyk, M. R. Chowdhury, A. Kliks, and A. D. Silva, “Experimental evaluation of xapp conflict mitigation framework in o-ran: Insights from testbed deployment in otic,” in IEEE INFOCOM 2025 IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS), 2025, pp. 1–6.

Related documents

• Experimental Classification of xApp Conflicts in O-RAN: Slicing vs. Per-UE Scheduling#1447621
• Cost-Aware Conflict Triage for xApp Control Conflicts in Open RAN#1326560
• Cost-Aware Conflict Triage for xApp Control Conflicts in Open RAN#1318940
• Coexistence of Push Wireless Access with Pull Communication for Content-based Wake-up Radios#334359
• Local decisions, diffusive influence, and lower bounds for graphical balanced allocation#1143327