Source-linked AI summary
Evolving Inspectable O-RAN Slicing xApps with LLMs
Faezeh Dehghan Tarzjani, Bhaskar Krishnamachari
TL;DR
O-RAN slicing controllers must adapt allocations to changing channels and demand, but learned allocation rules can remain encoded in neural-network parameters. This paper uses offline LLM-guided evolution to produce readable Python controllers. On POWDER, mean best-effort throughput was 44.5% higher than the static comparator.
Problem
O-RAN slicing needs adaptive allocations, but DRL policy rules remain encoded in learned parameters rather than directly inspectable source code.
Source: §I · p. 1Method
The paper evolves compact Python slicing controllers offline with LLM proposals and fitness feedback, then deploys the selected decision module unchanged in the O-RAN control path.
Source: §I · p. 1, B. Near-RT RIC Control-Path Integration · p. 5Results
On POWDER, mean best-effort throughput was 44.5% higher than the static comparator; in four-slice simulation, evolution scored higher than independent prompting at the same proposal budget.
Source: §VII · p. 9Takeaways & Limitations
Source inspection predicted release behavior and exposed a state-update defect; a one-line calibration edit reduced SLA misses from 79.9% to 2.2%.
Source: §VII · p. 9
Abstract
from arXiv · showhide
Open RAN (O-RAN) slicing xApps must adapt resource allocations to changing channel conditions and traffic demands while meeting service-level agreements (SLAs). Deep reinforcement learning can produce adaptive policies, but their allocation rules remain encoded in neural-network parameters. Our goal is to retain this adaptability while making the controller's decision logic directly inspectable and editable by operators. We use a large language model (LLM) to evolve slicing controllers as compact Python programs whose decision logic remains readable and editable after optimization. The LLM proposes and revises candidates offline, while a calibrated simulator scores them, and the selected decision module runs unchanged in the O-RAN control path. On the NSF POWDER 5G testbed, the evolved controller releases resources from a guaranteed slice whose throughput target becomes unattainable under a sustained channel fade, improving best-effort throughput from 158.2 to 228.6 Mbps, a 44.5% gain over the best static allocation. Since the controllers are readable source code, their behavior can be predicted from their equations, defects can be diagnosed by reading the code, and calibration errors can be corrected with one-line edits, reducing SLA misses from 79.9% to 2.2% in one case and more than doubling fitness in another. In a four-slice trace-driven simulation calibrated to the same testbed, evolutionary search achieves higher average evaluation scores than independent prompting at a matched proposal budget, with mean normalized gains on held-out traces of 16.3% for prompting alone, 32.1% for evolution from scratch, and 51.0% for evolution from a starting program.
I. INTRODUCTION
O-RAN slicing must adapt to changing demand and channel quality, including fades that can make a guaranteed slice’s throughput target unattainable. The paper proposes LLM-guided evolution of editable Python controllers and frames allocation around SLA attainment and best-effort throughput.
I. INTRODUCTION
- A sustained fade can make a guaranteed slice’s target unattainable even at its maximum share, while competing guarantees require choices about funding and service restoration.Releasing a slice above its minimum share can benefit best-effort traffic.Source: §I · p. 1
- LLM-guided evolutionary search produces compact Python slicing controllers whose allocation logic operators can read, trace, and edit after optimization.The selected decision module executes unchanged in an external process connected to an xApp.Source: §I · p. 1
- The framework is validated in a two-slice POWDER 5G testbed experiment and a four-slice simulation using channel traces and a delivery model calibrated to that testbed.The hardware controller transfers unchanged through the O-RAN control path.Source: §I · pp. 1–2
II. RELATED WORK
- DRL slicing approaches – encode allocation rules in neural-network parameters, while EXPLORA adds post-hoc explanations; this work makes rules directly editable source code.LLM-xApp places an LLM in the control loop, whereas this paper uses LLMs during offline search.Source: §II · p. 2
A. Slice Allocation and Utility Objective
- The objective rewards minimum viable shares when all targets fit, utility-maximizing target selection under contention, and releasing individually infeasible slices to best effort.The preferred allocation depends on the utility, constraints, and switching cost; the stated scoring rule gives no partial credit for a missed target.Source: §I · p. 1, A. Slice Allocation and Utility… · p. 3
A. Evolutionary Search Procedure
The search evaluates LLM-proposed Python controllers in a calibrated simulator, then iteratively mutates and selects candidates under a fixed proposal budget. Invalid mutations preserve their parent in the population, while final selection returns the highest-fitness valid archived program.
A. Evolutionary Search Procedure
- Each proposal is one LLM-generated candidate, either from the task prompt or by revising a parent, and invalid proposals still count toward the budget.Candidates are scored by execution in the calibrated simulator.Source: A. Evolutionary Search Procedure · p. 4
- Evolution samples mutations from elite programs, retains the top four each round, and selects the highest-fitness valid record from the full archive.A seeded run cannot return a program with lower fitness on the search traces than its starting program.Source: A. Evolutionary Search Procedure · p. 4
- Invalid mutations consume proposal allowance and reinsert the complete parent record, while valid children are archived and added to the next population.The evaluation process also seals and hashes prompts, predeclares runs and success criteria, and invalidates failed or malformed candidates.Source: A. Evolutionary Search Procedure · p. 4
- A trusted parent process owns the environment, random state, reward, and accounting; sandboxed workers return only actions, and responses are journaled before evaluation.The same traces support controller selection and four-slice results, with a separate sealed trace set reserved for post-hoc evaluation.Source: A. Evolutionary Search Procedure · p. 4
B. Near-RT RIC Control-Path Integration
The synthesized decision module runs unchanged alongside an xApp in the near-RT RIC control path, while a calibrated testbed and simulator provide the evaluation setting. The controller operates from channel and throughput observations, whereas the evaluator has access to true demand and channel state.
B. Near-RT RIC Control-Path Integration
- The decision module runs in an external process, queries KPMs and CQI, computes allocations, and sends commands through the xApp to the gNB scheduler.The module is verified at load against the offline champion; the adapter is platform-specific, and periodic re-synthesis remains future work.Source: B. Near-RT RIC Control-Path Integration · p. 5
V. HARDWARE TRANSFER AND INSPECTABLE DECISIONS
- The hardware-transfer study inspects source code to predict release behavior and a state-update defect, checks predictions against fixed-CQI and hardware observations, and tests a calibration repair in simulation.This section presents one cycle of calibrate, evolve, predict, deploy, and confirm.Source: §V · p. 5
A. Hardware Testbed Setup
- The POWDER setup uses two cabled UEs, with an 80 Mbps guaranteed-slice target; channel runs lasted about 120 seconds and averaged about 110 samples.The guaranteed slice averaged 37.1 Mbps at a commanded 90% share in the static deep-null run, below target; the comparison static allocation is 35/65.Source: A. Hardware Testbed Setup · p. 5, Figure 4 · p. 5
B. POMDP Formulation and Testbed Calibration
- The controller observes CQI and prior throughput, while the evaluator accesses true demand and channel state; the calibrated two-slice simulator models best-effort delivery from the guaranteed-slice allocation.Its fitness averages two demand profiles and 16 seeds at each of three CQI floors, then takes the lowest floor average across 96 episodes.Source: B. POMDP Formulation and Testbed… · pp. 5–6
C. Search Statistics
Evolutionary search produced a controller scoring above the static baseline, while zero-shot proposals did not. The paper also compares PPO and examines how source-level rules predict release behavior and reveal defects.
C. Search Statistics
- Gemini voided 65% of generated programs and Claude 5%; neither prompt framing placed the threshold correctly, while evolution selected an effective release threshold.Claude improved by 0.034 over generations; confident framing yielded release rules in 13 of 20 initial programs, versus 3 of 20 under hedged framing.Source: C. Search Statistics · p. 6
D. PPO Comparator
- 0.9534±0.0208 was the PPO agents’ fitness across seeds, exceeding the 0.9300 static baseline in four of five runs.All five PPO agents learned release behavior, settling at a 5.0% guaranteed share during the deep null.Source: D. PPO Comparator · p. 6
E. Selected Program and Source-Based Predictions
- 0.9398 was the evolutionary controller’s score, above the 0.9300 static baseline; none of 144 zero-shot programs exceeded the baseline, and the best scored 0.9054.The evaluation uses three CQI floors and takes the lowest of their averages.Source: E. Selected Program and Source-Based… · p. 6
- The selected controller releases at its minimum share during a deep null, then estimates efficiency from smoothed CQI and applies SLA bounds and channel-dependent hysteresis.Its release predicate uses channel telemetry but ignores delivered throughput, so provisioning trusts the calibrated efficiency estimate and cannot correct a delivery-model error from measurement.Source: E. Selected Program and Source-Based… · p. 6
- Six low-CQI observations trigger release from the CQI-15 steady state, and the first recovered observation restores a share above the floor.Both behaviors were confirmed on the deterministic CQI fixture; there is no separate exit threshold or latched release state.Source: E. Selected Program and Source-Based… · p. 6
- A comparison controller’s state-update defect overwrites its release state each tick, so it never releases even at a CQI floor of 2.The defect is visible in source inspection but not from the low fitness score alone.Source: E. Selected Program and Source-Based… · p. 7
F. Hardware Confirmation
The testbed controller released resources during a sustained fade, while a direct source edit compensated for a calibration mismatch. The four-slice simulation then examined allocation under offset fades and an oversubscribed resource cap.
F. Hardware Confirmation
- 228.6 Mbps mean best-effort throughput on POWDER was 44.5% above the static 35/65 allocation; the PPO controller achieved 235.6 Mbps.The evolved controller released resources during the deep null and ran through the xApp bridge and E2SM-RC to the gNB scheduler.Source: F. Hardware Confirmation · p. 7
G. Editability: Repairing a Calibration Error
- A 10% efficiency-estimate correction reduced SLA misses from 79.9% to 2.2%, at a 6.3 Mbps reduction in mean best-effort throughput, without re-evolution.The original estimate caused under-provisioning after actual good-channel efficiency fell 10%.Source: G. Editability: Repairing a… · p. 7
VI. EVOLVING COORDINATION IN TRACE-DRIVEN SIMULATION
- The four-slice simulation used testbed-calibrated delivery and offset fade schedules, with privileged true-channel policies as references.The scenario introduced contention by fading guaranteed slices on different schedules.Source: §VI · p. 7
A. Environment
- Four guaranteed slices shared a 70-point cap despite requiring 80 minimum shares even at the best channel condition, so all targets could not be met simultaneously.Controllers acted on channel observations delayed by one tick; evaluations used 16 episodes of 360 ticks each.Source: A. Environment · p. 7
C. What Search Adds at a Matched Proposal Budget
At a matched proposal budget, evolution outperformed prompting on held-out traces, and seeded evolution could improve strong starting programs. Source inspection also exposed a rate-estimation defect whose one-parameter repair improved performance.
C. What Search Adds at a Matched Proposal Budget
- On held-out traces, evolution from scratch scored 0.327 versus prompting’s 0.158; expert-seeded and champion-seeded evolution scored 0.677 and 0.712, above the expert rule’s 0.613.The comparison used 64 proposals per run and ten search runs per configuration.Source: C. What Search Adds at a Matched… · p. 8, Table III · p. 8
D. How the Starting Program Affects Search
- Expert seeding rose from 0.541 to 0.617 and champion seeding from 0.678 to 0.681; the 40-line greedy seed evolved further than a 134-line prompting seed, though the comparison is confounded.The greedy seed rose from 0.204 to 0.564, while the prompting seed rose from 0.297 to 0.394.Source: D. How the Starting Program Affects… · p. 9
E. Understanding Controller Behavior
- Correcting the CQI-15 rate coefficient from 11.8 to 2.19 raised worst-episode fitness from 0.3226 to 0.7255 across all 16 traces, while best-effort throughput fell 3 Mbps.The coefficient had predicted 12 Mbps per share point at CQI 15, versus the simulator’s 2.39 Mbps maximum.Source: E. Understanding Controller Behavior · p. 9
VII. CONCLUSION
- On POWDER, the controller ran unchanged through the O-RAN control path and delivered 44.5% more mean best-effort throughput than the static comparator.Hardware validation with more UEs and a four-slice configuration is future work.Source: §VII · p. 9
- Source inspection also identified a state-update defect in a comparison controller, and a one-line calibration edit reduced SLA misses from 79.9% to 2.2% without re-evolving.The conclusion also reports that one-parameter repair corrected a five-fold rate overestimate and more than doubled fitness.Source: §VII · p. 9
AI USE STATEMENT
The statement identifies the models used in the search and comparison, as well as Claude’s manuscript-editing role.
AI USE STATEMENT
- Claude (Anthropic) was the proposal model in the evolutionary search pipeline.The authors state that they accept full responsibility for the paper’s contents.Source: AI USE STATEMENT · pp. 9–10
- Gemini (Google) was used as the comparison model in the two-slice search.Source: AI USE STATEMENT · p. 9
- Claude also assisted with manuscript editing.The human authors accept full responsibility for the contents.Source: AI USE STATEMENT · p. 10
APPENDIX A FOUR-SLICE PROMPTS AND CONTROLLER CODE
The appendix provides the shared task prompt, mutation template, and an example evolved controller.
APPENDIX A FOUR-SLICE PROMPTS AND CONTROLLER CODE
- The appendix presents the fixed system prompt alongside prompts for initial generation and mutation.Source: Appendix A · p. 10
- Initial generation uses the request in Listing 2.Source: Appendix A · p. 10
- Mutation replaces that request with the parent program and feedback in Listing 3.Source: Appendix A · p. 10
A. Task Prompt
The task asks for a four-slice controller that chooses guaranteed-slice shares under a capped shared pool, maximizing a score that balances SLA attainment, best-effort throughput, and allocation stability.
A. Task Prompt
- It returns four guaranteed-slice shares; the harness caps their sum at 70 of 100 PRBs and assigns the remainder to best effort.The harness clamps negative shares to zero and scales allocations down if their sum exceeds the guaranteed cap.Source: A. Task Prompt · p. 10
- Each guaranteed slice’s delivered throughput is the lesser of its demand and its rate per share multiplied by its allocation.The task states that demand remains at or above each guaranteed target.Source: A. Task Prompt · pp. 10–11
- The controller maximizes average per-tick score, rewarding guaranteed-slice attainment and best-effort throughput while penalizing share changes.Attainment is binary with a 0.5 Mbps tolerance; the score also weights best-effort throughput and churn.Source: A. Task Prompt · p. 10
- The scenario includes independent channel variation, periods when the pool cannot fund all four targets, and deep nulls where a target is unattainable at any share.In a deep null, CQI is approximately 5 and delivered throughput per share approaches zero; good-channel CQI saturates near 15.Source: A. Task Prompt · pp. 10–11
B. Mutation Template
The mutation template gives the LLM a parent controller and evaluation diagnostics, then asks it to return an improved variant.
B. Mutation Template
- Diagnostics report per-slice attainment, violation percentage, best-effort Mbps, and share changes per episode.Attainment is reported separately for the four guaranteed slices.Source: B. Mutation Template · p. 11
- The template supplies the parent controller source together with its worst-case fitness.The fields are filled with the parent program and its evaluation results.Source: B. Mutation Template · p. 11
- The prompt asks for a variant that scores higher on the average score.It requests the response as a fenced Python code block.Source: B. Mutation Template · p. 11
C. Controller Code
The evolved controller tracks recent channel and attainment history, estimates per-slice rates, and allocates guaranteed shares within the cap using viability checks and weighted distribution.
C. Controller Code
- It estimates rates from CQI, computes minimum shares, and selects viable slices subject to the guaranteed-share cap.The snippets show CQI-based rates, minimum-share calculations, an adaptive-threshold check, and a cap check before assignment.Source: C. Controller Code · p. 11
- After assigning viable slices, it distributes remaining capacity among them in proportion to their weights.The code checks for remaining capacity and a positive weight sum before distributing shares.Source: C. Controller Code · pp. 11–12
- The controller limits share changes using CQI movement, trims allocations to the cap, and saves previous shares and histories in persistent state.The code compares CQI changes with a threshold, bounds share changes, and stores allocation and history state.Source: C. Controller Code · p. 12