arXiv CSopen access

GENESIS: Harnessing AI Agents for Autonomous 6G RAN Synthesis, Research, and Testing

1

G ENESIS: Harnessing AI Agents for Autonomous 6G RAN Synthesis, Research, and Testing

arXiv:2605.27360v1 [cs.NI] 26 May 2026

Tamerlan Aghayev, Maxime Elkael, Michele Polese, Minh Dat Nguyen, Gabriele Gemmi, Andrea Lacava, Ali Saeizadeh, Reshma Prasad, Paolo Testolina, Angelo Feraudo, Soumendra Nanda, Pedram Johari, Salvatore D’Oro, Tommaso Melodia

Abstract—Cellular research and development (R&D) is throttled by six structural processes that each consume months of manual engineering work per iteration: (i) synthesizing new features from standards or research papers into production code; (ii) conformance and interoperability testing; (iii) hardening against field anomalies and diverse deployment environments; (iv) datadriven optimization of network functionalities; (v) discovering and prototyping novel waveforms, functionalities, and capabilities for future standards; and (vi) securing the stack against vulnerabilities. Although Large Language Models (LLMs) have compressed comparable R&D work in general software engineering from days to minutes, their known pitfalls worsen on Radio Access Network (RAN) use cases: they hallucinate Application Programming Interfaces (APIs) and mis-read specifications, which kills interoperability of RAN components at the first mistake, and they heavily rely on simulations for designing algorithms, which is notorious for breaking when transferred to real hardware. To address these challenges, we present G ENESIS, an agentic Artificial Intelligence (AI) framework that converts intents (e.g., a specification clause, a telemetry anomaly, or a research hypothesis) into solutions validated with over-the-air experiments, fed back into a persistent knowledge base. G ENESIS is built on three composable primitives (agents, skills, hooks) and a knowledge layer (S YNAPSE) that doubles as the source of ground truth and the recipient of every artifact the framework produces, making capabilities compound across runs. To prototype G ENESIS, we developed 6 agentic-driven pipelines that synthesize, test, harden, optimize, discover, and secure a network. The design of G ENESIS uniquely anchors each agentic step in observations and automated tests that (i) are autonomously executed on heterogeneous cellular infrastructure and testbeds (from RAN simulators to over-theair O-RAN and 5G stacks) and (ii) provide critical feedback to the agents’ decisions. This allows agents to quickly understand errors and shortcomings in their strategies, and converge to implementations that actually work on real-world 5G systems. We present three case studies that together exercise the full R&D lifecycle: (i) synthesizing and testing the implementation of the 3GPP RRC.ConnMean Key Performance Measurement (KPM); (ii) synthesizing, testing, and hardening Conditional Handover (CHO) with a closed-loop xApp over E2SM-RC; and (iii) researching new RAN scheduling variants, by taking a research hypothesis through code, integration, and comparison with the state of the art. Across multiple statistically independent experiments, G ENESIS has a 100% success rate in implementing new stack features, while The authors are with the Institute for Intelligent Networked Systems at Northeastern University, Boston, MA. Email: [email protected] This work is partially supported by OUSD(R&E) through Army Research Laboratory Cooperative Agreement Number W911NF-24-2-0065. The views and conclusions contained in this document are those of the authors and should not be interpreted as representing the official policies, either expressed or implied, of the Army Research Laboratory or the U.S. Government. The U.S. Government is authorized to reproduce and distribute reprints for Government purposes notwithstanding any copyright notation herein. This work is also partially supported by the U.S. NSF under award TI-2449452 and under award CNS-2112471.

our baseline (Claude Code with Opus 4.7) consistently fails at each attempt. This paper introduces the G ENESIS architecture, implementation, and an extensive set of experimental results that profile the harness (e.g., token utilization, cost across different LLMs) and validate the features that G ENESIS synthesized. Index Terms—Agentic AI, AI-RAN, Open RAN, 6G.

I. I NTRODUCTION Cellular networks research and development is structurally slow. This stems from months-long engineering cycles to bring ideas to products, through research, prototyping, testing, hardening, optimization, evaluation, and standardization. Those stages recur and together form the typical Radio Access Network (RAN) R&D life-cycle. To address this bottleneck, this paper proposes G ENESIS, an agentic framework that reduces this effort from months to hours. In this introduction, we discuss the structural bottlenecks and discuss how G ENESIS addresses these limitations. A. Challenges in RAN R&D Six bottlenecks dominate RAN R&D: (i) synthesizing new features, from standards clauses or research papers into prototype and production code; (ii) testing, including conformance and interoperability across vendor stacks; (iii) hardening against field anomalies and diverse deployment environments; (iv) optimizing network functionalities through data-driven policies; (v) discovering novel waveforms, functionalities, and capabilities and preparing them for future standards; and (vi) securing the stack while identifying vulnerabilities. Each of these is today a separate engineering arc, burdened with the cost of research, development, and integration with complex multivendor systems, RAN infrastructure, testbeds, and eventually field deployments, even when the underlying intent is small. While the transition from monolithic, hardware-based appliances to software-driven systems has introduced openness and programmability in the RAN, it has also exacerbated these issues. A feature today crosses more interfaces, more vendors, and compute platforms than in the appliance/black box era. This breadth, more than any single component, is what shapes the engineering work necessary to carry a feature from a specification clause, or research idea, to a working radio. An analysis of commits and merge requests for the 5G stack in [1] reveals that the interval between a first code change to a substantial feature merged in the repository’s stable branch is

2

I N T E N T “Implement RRC.ConnMean per TS 28.552" - Spec clause - KPI anomaly - Research hypothesis

Knowledge Layer - Synapse Hybrid retrieval

AGENT ORCHESTRATOR · Routing - Plan Synthesis TEST

HARDEN

DevOps

RAN

AGENT SPECIALISTS

OPTIMIZE Radio

UE

Testbed

Emulation

23 deterministic procedures · sample shown

build

run

configure

deploy

experiment

← RAN

← RAN

← Radio

← DevOps

← Testbed

HOOKS

Observability - Policy gates - Audit

RFSim Single gNB

EMULATION

Reasoning Layer

Colosseum/Keysight Hardware-in-the-loop

OVER-THE-AIR

AI Accelerators - Connectivity - Radios - Virtualization

Claude Opus 4.7 Claude Sonnet 4.6

Open Weight Served locally

Substrate Layer - Testbeds and Infrastructure SIMULATION

O-RAN/3GPP

SECURE

Commercial Cloud-based

Deterministic Execution Layer SKILLS

DISCOVER

Telco Specs

X5G/Arena Production env

Ingest & traceability

SYNTHESIZE

pgvector + BM25

gpt-oss llama 4 phi gemma

LLM inference

Data flow Traces Logs Experiment results

Six autonomous capability pipelines

spec → code → evidence

Agentic Layer

Monitoring

Fig. 1. G ENESIS architecture, organized as four horizontal layers tied together by the S YNAPSE knowledge plane and a pluggable LLM backend. A single intent (a specification clause, a KPI anomaly, or a research hypothesis) enters at the top. The agentic framework routes it through one of six capability pipelines (S YNTHESIZE, T EST, H ARDEN, O PTIMIZE, D ISCOVER, S ECURE), composed at run-time from a pool of agent specialists (DevOps, RAN, Radio, UE, Testbed, Emulation, among others). The deterministic execution layer hosts ∼23 parameterized skills (build, run, configure, deploy, experiment, . . .) and hooks for observability, policy gates, and audit. The substrate layer provides a three-tier validation continuum from RFSIM through emulation (Colosseum with hardware-in-the-loop) to OTA deployment on production-grade testbeds (X5G, Arena). S YNAPSE serves as both source of ground truth (3GPP/O-RAN specs via hybrid retrieval) and recipient of every artifact each run produces (traces, logs, code diffs with spec-to-code traceability). LLM instances are pluggable, mixing commercial cloud models (e.g., Claude Opus 4.7, Sonnet 4.6) with open-weight models served locally (e.g., gpt-oss, Llama 4, Phi, Gemma). The whole system runs as a closed loop in which the testbed and the knowledge plane co-evolve with the agentic framework.

74 days on average, and 207 in the 90th percentile (excluding However, those wins do not yet transfer to RAN engineering. bug fixes, documentation). As we will show later in this paper, the same agentic This complexity delays standardized features from reaching frameworks hallucinate Application Programming Interfaces production stacks. Vendors carry most of the engineering cost, (APIs), misinterpret ambiguous specifications, and produce and they spend it on what operators are willing to pay for. code that may compile, or even run in simulation, but breaks Network slicing, Ultra Reliable and Low Latency Communi- once it attempts at interoperating with other standard devices cations (URLLC), and Integrated Access and Backhaul (IAB) and interfaces with physical systems such as radios, RF test illustrate this: extremely promising in the early 5G era for equipment, commercial User Equipments (UEs), and over-theindustrial automation [2], disaster recovery [3], and similar air testbeds. Closing this gap is not a pure prompt-engineering problem. applications, they are rarely deployed today [4]. These are high-value, low-volume features: each matters in real industrial Having a closed-loop testing harness is critical: agents may or defense scenarios, but none is justified by the multi-billion- fail, and thus need to be able to test and iterate autonomously dollar market that drives traditional telco economics. Openness on multiple environments with increasing degree of realism. was supposed to bypass that gate: RAN Intelligent Controllers The agents thus need RAN-specific scaffolding: deterministic (RICs) would let operators add control features without changes procedures to, e.g., run experiments, assist in troubleshooting, to the vendor RAN stack [5]. In practice, this potential has not and operate testbeds, step-by-step pipelines that incorporate materialized: production stacks expose only limited telemetry verified domain knowledge, and a testbed-based loop that and control, severely constraining the use-case-tailored AI validates every change against real radio behavior. optimization that the recently formed AI-RAN Alliance [6] has put on the industry agenda. C. G ENESIS G ENESIS is that scaffolding. Figure 1 shows its architecture, with four horizontal layers tied together by a shared knowledge For traditional software development, LLM agents have plane and the LLM backend. the potential to revert this dynamic by lowering engineering Intent layer. Every run starts from a high-level intent. lead time and cost. Multi-agent frameworks (AutoGen [7], The figure illustrates three examples of forms the intent can MetaGPT [8], CrewAI [9], Claude Code [10]) split work take across the RAN R&D life-cycle: a specification clause across specialized personas and produce strong results on SWE- (“implement RRC.ConnMean per Technical Specification bench [11], web automation, and code competitions [12], [13]. (TS) 28.552”), an anomaly on telemetry or KPIs observed B. Software Engineering and LLMs

3

in production, or a research hypothesis to evaluate. All three enter the framework through the same interface and are routed to the appropriate capability pipeline. Agentic Layer. Below the intent sits the orchestration plane. An agent orchestrator performs routing and defines the plan that maps the intent onto one of six capability pipelines. Together, these cover the full R&D life-cycle: S YNTHESIZE (specificationto-code), T EST (conformance, interoperability, and regression testing), H ARDEN (anomaly-to-fix loops), O PTIMIZE (datadriven algorithmic training and deployment), D ISCOVER (novel capabilities or features), and S ECURE (adversarial analysis of the stack). Each pipeline is assembled at run-time from a pool of agent specialists (e.g., DevOps, RAN, Radio, UE, Testbed, Emulation) whose personas encode expertise in a specific domain, decision authority, and the subset of tools they may invoke. Agents reason, and leverage the execution layer to take procedural steps. Deterministic Execution Layer. This layer hosts the skills, i.e., a set of two dozen parameterized, deterministic procedures with explicit success criteria (build, run, configure, deploy, experiment, and more). Skills execute based on reasoning provided by the agents. In the same layer, hooks are event-driven shell commands that fire around every action and provide three cross-cutting planes: observability (structured event logs that bypass the agent’s context window), policy gates (non-bypassable safety checks on actions that touch critical components, e.g., radios), and audit (provenance records for every change). The agent/skill/hook split is what makes G ENESIS composable, observable, and portable across agentic runtimes. Substrate Layer: the Agentic Infrastructure. The same agents and skills that write the code also drive the infrastructure on which the code runs. Three tiers form a validation continuum: pure simulation (RFSIM with a single Next Generation Node Base (gNB)); emulation (Colosseum [14], Keysight instruments, or other hardware-in-the-loop emulators); and OTA deployment on production-grade testbeds (X5G [15], Arena [16]). The continuum spans a vast compute infrastructure, including AI accelerators, fronthaul connectivity, real radios, and a virtualization fabric. Every test outcome at every tier is fed back to the agent’s next decision, so an autonomously generated change is not merely written but exercised under increasingly realistic conditions. The agentic testbed leverages automation and virtualization capabilities based on our AutoRAN framework [17]. With this, G ENESIS skills tap into an OpenShift-based system to manage system configuration, deployment, and life cycle of agentic validation. Knowledge Plane: S YNAPSE. The right edge of Fig. 1 shows S YNAPSE, the persistent knowledge layer that the four horizontal layers all read from and write to. S YNAPSE plays three roles: (i) source of ground truth, presenting curated 3GPP and O-RAN specifications, a curated corpus of research papers, reference implementations, and lab inventory, exposed through hybrid retrieval, verified by human experts, and organized according to a telecom-specific ontology that composes a technical and institutional knowledge graph; (ii) recipient of generated knowledge, with every G ENESIS run writing back code diffs with spec-to-code traceability, traces, logs, and full

experimental campaigns via the I NGEST stage, also behind a human-reviewer gate; and (iii) cross-capability substrate. Here, an artifact produced by one capability (a H ARDEN patch, an O PTIMIZE dataset, an D ISCOVER dApp) becomes an input the next capability can consume. LLM Backend. G ENESIS runs against commercial cloudhosted models (Claude Opus 4.7 and Sonnet 4.6 in our current deployment), and against open-weight models served locally (gpt-oss, Llama 4, Phi, Gemma), with the orchestrator matching appropriate models for the tasks at hand. The closed loop. Reading the figure from top to bottom, an intent enters at the top, is routed by the orchestrator, planned and executed by specialists composing skills under hook supervision, validated on the substrate’s three tiers, and the resulting traces, logs, and experiment results flow back up into S YNAPSE and into the agents’ next decision. The entire system is a closed loop in which the testbed and the knowledge plane co-evolve with the agentic framework. D. Contributions and Paper Structure This paper discusses the design of G ENESIS, rooted in the closed-loop agentic harness discussed above, and of three use cases, including the evaluation of the performance of G ENESIS in generating a valid output from the use-case intent, and the validation of the synthesized solution. G ENESIS Use Cases. We develop three illustrative use cases for G ENESIS. In the first, G ENESIS implements the RRC.ConnMean Key Performance Measurement (KPM) from 3GPP TS 28.552 [18] in an open-source 5G stack using the S YNTHESIZE pipeline, to demonstrate the spec → code → OTA propagation on a single feature. The second, Conditional Handover (CHO) with a closed-loop E2SM-RC xApp, is a cross-capability example that exercises S YNTHESIZE, T EST, and H ARDEN together. CHO is a multi-specification feature, with the additional closed-loop control. In this case, synthesis, conformance testing, and field hardening are more effective when executed jointly. The third showcases the D ISCOVER capability, and how it connects to S YNTHESIZE and T EST. We leverage the autonomous research loop we discussed in [19], which takes high-level intents and generates new schedulers, both from an algorithmic point of view (i.e., combining different rewards and allocation policies into a comprehensive scheduler) and implementation (the scheduler is functional and deployed on the G ENESIS infrastructure). Our Contribution. This paper makes three key contributions, introducing G ENESIS as the first agentic framework that drives the full RAN R&D life-cycle from intent to OTA evidence on real radios: 1) The first end-to-end demonstration that an agentic framework can synthesize, test, and discover RAN functionalities on production-grade radios. Across multiple statistically independent runs, G ENESIS achieves 100% success on the implementation of the RRC.ConnMean KPM and of CHO with a closed-loop E2SM-RC xApp, and maps the ALLSTaR autonomous scheduling loop [19] as the D ISCOVER anchor. The off-the-shelf baseline (Claude Code with Opus 4.7) produces no working

4

TABLE I C OMPARISON OF G ENESIS WITH THE CLOSEST ANALOG IN EACH RESEARCH THREAD . ✓: FEATURE IS CENTRAL TO THE CITED WORK ; •: PARTIALLY SUPPORTED OR OUT OF SCOPE OF THE WORK ’ S PRIMARY CONTRIBUTION ; ✗: FEATURE IS ABSENT. System

Primary Target

Reasoning & Knowledge

Validation Reach

Multiagent

Specgrounded

Closed loop

Real radio

Spec-toOTA

MetaGPT [8] Voyager [20] Glia [21] Navidan et al. [22] Jiang et al. [23] Ferrag et al. [24] Dev et al. [25] Gajjar & Shah [26] ComAgent [27] AI Telco Engineer [28] Zota et al. [29] 5GReasoner [30] ALLSTaR [19] AgentRAN [31]

Software engineering Open-ended skill learning GPU-cluster systems design O-RAN operations (runtime) Intent-based networking (runtime) Agentic AI-native 6G (architecture) Agentic 6G architectures (V2X exp.) AI-RAN cognitive OS (vision) Wireless optimization design PHY-algorithm design (sim.) Enterprise IT operations Protocol security analysis MAC Scheduling r/x/dApp-based RAN optimization

✓ ✗ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ • ✗ ✗ ✓

✗ ✗ ✗ ✗ • • • • • ✗ ✗ ✓ ✗ ✗

• ✓ ✓ • ✓ • ✓ ✗ ✓ ✓ ✗ ✗ ✓ ✓

✗ ✗ • ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✓ ✓

✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ • ✗

G ENESIS (this work)

End-to-end RAN engineering (eng. life-cycle)

✓

✓

✓

✓

✓

implementation on any attempt for either of the first two performance, and Sec. XI concludes the paper. case studies (Sec. X). 2) An agentic architecture that closes the RAN R&D II. R ELATED W ORK loop end-to-end, anchored in a staged validation G ENESIS lies at the intersection of three research areas, continuum. G ENESIS composes three portable primitives (agents, skills, hooks) with a persistent knowledge plane discussed in the following paragraphs: multi-agent LLM frame(S YNAPSE) into six capability pipelines that together works, LLM-assisted software engineering, and specificationcover the full life-cycle. The same primitives drive driven code generation and protocol testing. Table I summaa three-tier validation continuum (RFSIM → emula- rizes the differences between G ENESIS and state of the art tion → X5G) where every test outcome is routed back into approaches in this area. Multi-Agent LLM Frameworks. A growing body of work the agent’s next decision via hooks, which also enforce non-bypassable safety gates on actions that touch live decomposes complex tasks across specialized LLM agents. hardware. Every artifact produced by one capability flows General-purpose runtimes span conversational message passing through the knowledge plane to become an input that (AutoGen [7]), role-specific software pipelines (MetaGPT [8], compounds over time, and the primitives are portable ChatDev [32]), role/goal task backlogs (CrewAI [9]), stategraph orchestration (LangGraph [33]), open-ended skill learning across the major agentic runtimes (Secs. IV–V). 3) A non-obvious model-selection tradeoff for agentic (Voyager [20]), and Software Development Kits (SDKs) such as RAN engineering. Per-stage profiling over statistically Claude Agents [10] and OpenAI Agents [34]. Zhou et al. [35] independent trials reveals that two of the six S YNTHESIZE unify these under externalization—relocating state, procedural stages (implementing the feature and executing the tests) know-how, and interaction structure from inside the model dominate both cost and wall-clock, and that once cost is into external memory, skills, and a coordinating harness— normalized by success rate a mid-tier LLM matches a which maps directly onto G ENESIS’s agent/skill/hook split frontier one on cost-per-successful-feature while trading (Sec. IV). The closest non-wireless analog to G ENESIS, wall-clock for throughput, which turns the model selection Glia [21], couples a reasoning/experiment/analysis loop to a into a deployable latency/throughput decision rather than simulator–emulator–testbed continuum for Graphics Processing Unit (GPU)-cluster scheduling, paralleling our staged validation a strict cost or quality dominance (Sec. X). (Sec. V-D) and hooks (Sec. IV-C), but without integration of The remainder of the paper is organized as follows. Sec. II technical specifications or wireless components. surveys related work, and Sec. III maps the G ENESIS primA second line applies these techniques to network optimizaitives onto the capability pipelines. Sec. IV describes the tion [36]. At runtime, Navidan et al. [22] bind agent capacity agent/skill/hook architecture. Sec. V describes the agentic to control-loop latency in O-RAN (with different models sizes testbed and validation continuum. Sec. VI dives into the across rApps, xApps, and RAN), while Jiang et al. [23] build S YNTHESIZE pipeline. Secs. VII–IX present three end-to-end an agentic Intent-Based Networking (IBN) orchestrator over case studies, including the validation of the G ENESIS-generated RAN/core specialists and observe that prompt variations induce solutions. Sec. X reports the numerical evaluation of G ENESIS compounding biases in the operations. This directly motivates

5

our externalization of deterministic, procedural guidance as PRINCIPAL STAGE 1 SpecAnalyzer skills and of policy as hooks. At the architecture layer, 2 CodeAnalyzer CAPABILITY Ferrag et al. [24] cast LLMs as bounded, policy-governed 5 SYNTHESIZE Analyzer reasoning entities above deterministic 3GPP infrastructure, IN Spec clause / 1 SpecReader OUT Spec-to-code and Gajjar and Shah [26] promote them to a “cognitive OS”. 6 2 TestDesigner Dev et al. [25] use three LLaMA-2 agents in crewAI with a TEST 3 ScenarioAgent IN Feature stack, Retrieval-Augmented Generation (RAG) corpus (arXiv, telecom 455 TestRunner OUT Conformance matrix 6 Q&A, 3GPP) to jointly tune V2X power/modulation/retrans1 AnomalyDetector HARDEN IN: KPI anomaly alert 2 RootCauseAnalyzer mission in ns-3 and SUMO. Our recent AgentRAN [31] OUT: Bug, patch 6 4 RegressionAgent work proposes a O-RAN-based hierarchical framework which OPTIMIZE 34324 CodeWriter distributes agents over rApps and xApps which control dApps IN: KPI target + 1 DataAgent OUT: Dataset, policy 6 in the RAN. 2 Profiler DISCOVER For numerical and PHY design, Li et al.’s ComAgent [27] 3 TrainingAgent IN: Research coordinates Literature/Planning/Coding/Scoring agents that 4 OUT: KG branch Deployer 6 match expert non-AI baselines for wireless power transfer 5 A/B Tester SECURE IN: Threat model 1 HypothesisEngine case. NVIDIA’s AI Telco Engineer [28] evolves containerized OUT: Threat report, patch 6 3 ExperimentDesigner agents over Sionna [37] via a leaderboard loop to design 4 SpecWriter channel estimators, link adaptation, and Low-Density ParityHuman Review Gate 1 ThreatModeler Check (LDPC) decoders. Both papers share with G ENESIS 2 VulnScanner the conviction that agentic correctness must be established Synapse KB 3 ExploitAgent through execution, but differing in substrate (numerical/linklevel simulation vs. OTA behavior on production radios). Fig. 2. Summary of the six G ENESIS capabilities, including the input and Where prior agentic work operates O-RAN [22], [23], output for each one, the stages in which they unfold (in the order indicated by architects 6G [24], orchestrates narrow ML [26], tunes pa- the numbers, color-coded to the capability), and the ingestion of the outcome in the knowledge base, after a human review. rameters [25], designs algorithms in simulation [27], [28], or designs cluster schedulers [21], G ENESIS engineers and evolves the software stack itself, propagating features from focusing on a foundational model, G ENESIS develops agentic specification text through code, compilation, deployment, and components that can leverage different LLMs and test benches. OTA validation, with abstractions that can propagate to multiple Summary. To our knowledge, G ENESIS is the first end-toruntime environments. end framework that (i) applies multi-agent LLMs to the full LLM-Assisted Software Engineering. A second thread life-cycle of RAN software generation and testing, including treats LLMs as software-engineering assistants: SWE- real-world over-the-air deployment, (ii) exposes the design bench [11] and derivatives benchmark repository-scale bug as portable agent/skill/hook primitives with an explicit crossfixing, SWE-agent [38] designs the agent-computer tool surface, runtime mapping, and (iii) addresses the end-to-end R&D and self-repair/planning techniques [39] iterate on failing tests. life cycle, across multiple open-source repositories, from G ENESIS shares the iterate-to-acceptance philosophy, but its specification text to OTA validation on real radios. Table I acceptance criterion is not a test suite—it is validation on compares G ENESIS with the closest analog in each thread along real radio infrastructure, a gap that motivates our staged- five axes (multi-agent reasoning, spec-grounded outputs, closedvalidation continuum (Sec. V-D) and the policy/audit role of loop validation, real-radio reach, and spec-to-OTA propagation); hooks (Sec. IV-C). AI5GTest [40] leverages three LLMs to G ENESIS is the only system combining all five. generate tests, validate stack functionality, and debug failures. Compared to this, G ENESIS focuses on a more generic agentic III. G ENESIS C APABILITIES approach, where different LLMs are autonomously selected by As shown in Fig. 1, G ENESIS provides a coordination and agents according to their functionality and needs, and on the reasoning layer that turns a federation of specifications, testbeds, sythesis of protocol stack features, besides testing harness. Specification-Driven Code Generation and Protocol and operator infrastructure into a coherent, autonomous agentic Testing. A third thread bridges specifications and code directly, engineering engine, organized in six autonomous capabilities either for analysis or implementation. Early work on machine- (i.e., S YNTHESIZE, T EST, H ARDEN, O PTIMIZE, D ISCOVER, readable 3GPP specifications [41] explored structured clause and S ECURE). Figure 2 connects the capabilities (and their representations, while structured fuzzing of LTE/5th generation input/output relationship) to the G ENESIS agents, and illustrates (5G) Non-Access Stratum (NAS) [30] discovers conformance how they share a common step: after a human review gate, the gaps through test generation. More recently, LLMs have been outcome of each pipeline is ingested in the knowledge base. shown as effective in translating Requests for Comments Next, we summarize the role of each capability. (RFCs) into code [42]. G ENESIS generally deals with more S YNTHESIZE: A spec-to-code pipeline. Given a 3GPP complex 3GPP and O-RAN specifications, which are usually or O-RAN clause, or a research paper, an orchestrator drives an order of magnitude longer compared to IETF RFCs. a six-stage pipeline that queries the knowledge base, maps Multiple foundational models and test benches related to RAN requirements onto the stack codebase, writes the change, specifications have also been proposed [43]–[45]. Rather than validates it across the tiered continuum, and ingests the result.

6

T EST: Regression-grade conformance testing against system and standard specifications. The pipeline generates test cases, configures testing scenarios, runs the full campaign on simulation/Colosseum/X5G, and flags regressions against spec-derived acceptance criteria. The knowledge-base artifact is a conformance pass/fail matrix indexed by specification section plus a reproducible scenario bundle. H ARDEN: Bug-to-fix loop. An anomaly detector watches KPM counters (e.g., a Hybrid Automatic Repeat reQuest (HARQ) retransmission spike under high UE load), a root-cause analyzer traces the anomaly to a code path, a C ODE W RITER produces a targeted patch, a T EST RUNNER validates under the same conditions that triggered the bug, and a R EGRESSIONAGENT runs the full regression suite before the patch reaches production. O PTIMIZE: Data-driven adaptation and sim-to-real transfer. An instantiation of this workflow is the AI-RAN data factory discussed in our prior work [31]. An example is learning Channel Quality Information (CQI)-to-Modulation and Coding Scheme (MCS) mapping: Colosseum emulation campaigns generate a dataset, a training agent fits an Machine Learning (ML) policy, a deployer pushes it as an xApp/rApp via the non-RT RIC, and an A/B tester evaluates against the baseline on X5G with statistical significance. D ISCOVER: From research hypothesis to implementation and experimental validation, with paper or standard contribution. A researcher elaborates an hypothesis to be developed and tested (e.g., a learned waveform-adaptation scheme for 6th generation (6G) [46]); a C ODE W RITER implements a candidate feature on a 6G branch; a T EST RUNNER produces emulation and OTA evidence; a S PEC W RITER drafts the corresponding 3GPP document or change request bound to that evidence. S ECURE: Adversarial security analysis of RAN signaling paths (Radio Resource Control (RRC), NAS, M-Plane) with non-bypassable safety gates. A threat modeler applies the STRIDE taxonomy [47] to the relevant security specifications (TS 33.501/511); a vulnerability scanner combines static analysis and protocol fuzzing; attacks run only in a sandboxed Colosseum instance; a C ODE W RITER generates patches that must pass conformance regression. Policy enforcement, rollback triggers, and audit trails are implemented as hooks (Sec. IV-C).

A. Agents: Reasoners with a Tool Surface

Classically, an agent is an entity that perceives its environment through sensors, maintains internal state, and acts on the environment through actuators in service of a goal [48]. The present generation of LLM-based agents [10] follow the same pattern: an LLM serves as the reasoning core, its context window as internal state, and tool calls as both sensors and actuators. We define an agent in G ENESIS as a triple: (persona, tool surface, control loop). The persona describes the nature of the agent: its identity, expertise, decision authority, constraints, and preferred reasoning style. This makes it possible to create the specialists introduced in Fig. 1 and Sec. I, i.e., agents with different personas, to drive the autonomous loop, while separating concerns and keeping a manageable context. The tool surface is the set of actions the model may take, together with their input schemas. For example, a DevOps specialist is equipped with information on how to interact with system automation. The control loop is a ReAct-style alternation of thought and action [49]: at each step the model emits a naturallanguage reasoning trace (the thought) followed by a single tool invocation (the action). The runtime executes the call and appends its result (the observation) to the context, and the model is re-invoked to produce the next thought. The loop terminates when the model emits a final response in place of an action, or when a runtime budget (tokens, wall time, step count) is exhausted. Concretely, agents in G ENESIS are represented as markdown files and are referred to as specialists. Each file contains at minimum a description, and a list of tools/skills (Sec. IV-B) the specialist may invoke. The description field is the routing grammar with which the orchestrator decides when to dispatch a specialist. A specific, action-oriented description (“returns an EXPERIMENT_PLAN for the X5G testbed given constraints”) yields reliable routing while a vague one (“knows about X5G”) does not. Examples of specialists included in G ENESIS are: • a DevOps specialist, which manages OpenShift and pod lifecycle; • the RAN specialist, taking care of building, configuring, and running the RAN stack (OpenAirInterface (OAI), in the first G ENESIS implementation); • the Radio specialist, which can configure O-RAN Radio Although their goals differ, the six capabilities share the Units (RUs) (e.g., a Foxconn RU part of X5G) via SSH/Msame architectural skeleton—orchestrator, specialists, staged Plane; validation, Gatekeeper—because they are the structural conse• a UE specialist, which can interact with Sierra Wireless quence of the design primitives presented next. UEs and OAI softUE deployed in X5G; • the Testbed specialist, which covers planning of experiments and tests on the OTA or emulated testbeds. IV. S YSTEM A RCHITECTURE Additional specialists can include stage-specific agents, e.g., an xApp specialist to interact with the O-RAN Near-RT RIC, G ENESIS rests on a small number of primitives chosen and KPM specialists to analyze performance evaluation. to be composable, observable, and portable across different agentic frameworks. In this section, we first describe the agent/skill/hook triad and their orchestration (Secs. IV-A–IV-D). B. Skills: Agent-Invoked Instruction Packages We then formalize inventory as code (Sec. IV-E), the knowledge Agents reason using LLMs. To execute deterministic, probase (Sec. IV-F), and discuss how the abstraction maps onto cedural steps, the agent’s persona file directs it to invoke a the major agentic runtime available today (Sec. IV-G). Figure 1 skill whose own body in turn may delegate to a script. For summarizes the architecture. complex, frequent, and scriptable procedures, the agent chooses

7

TABLE II T HE G ENESIS PRIMITIVE TRIAD .

I. Infrastructure tier <openshift/deploy-oai-pod> never sees: testbed identity, RU details, owns: pod manifest, SRIOV, performance profile II. Testbed tier <testbed/configure> never touches: pod-runtime values owns: RU address, fronthaul MAC, MIMO, PLMN III. Runtime tier <oai/run> never encodes: which testbed it runs on owns: CPU affinity, DPDK PCI, gNB IP, AMF IP Fig. 3. Tiered skill invocation chain. Each tier owns a disjoint set of inputs. Tiers above never see what tiers below depend on.

what to do and when, the skill specifies how. This grounds the agent in precise capabilities, avoiding the need to re-think through common procedures, and increasing the likelihood that an intent is successfully implemented. A G ENESIS skill is also represented as a markdown file, i.e., SKILL.md. The body of the file is adaptive “guidance”, meaning that the specialist may skip steps, reorder them, or improvise. For any step where that behavior would be unacceptable, or that is completely deterministic, the skill’s markdown delegates to a script and instructs the specialist to invoke it with a specific argument shape. This layering keeps the interpretive surface (agent reasoning) separate from the deterministic one (script execution). Thanks to this design choice, each surface can be reviewed and hardened independently, and specialist regressions on one surface do not silently rewrite the other. It also avoids compounding of probabilistic errors generated by the stochastic nature of the agents reasoning. Fig. 3 illustrates a concrete example of composition for running a gNB on X5G. It is realized as a chain of three skills, each in its own SKILL.md and specific elements that are within scope of the skill. Each one is invoked only when its inputs change, i.e., when the agent decides to update the parameters that are within the scope of the skill. This minimizes the range of commands that need to be run for each agentic action and increases the speed of convergence for G ENESIS flows. C. Hooks: Observability, Policy, and Audit Agents and skills specify what is done, whereas hooks specify what happens around every action. Hooks execute deterministically and out-of-band from the reasoning loop, do not consume context tokens, and are invariant to the specialist or skill in scope at the moment they fire. The portability of hooks is the weakest of the three primitives, since the set of available events and the contract for blocking an action vary by runtime. A Claude Code implementation, for instance, currently exposes 29 such events, of which G ENESIS subscribes to five: UserPromptSubmit, PreToolUse, PostToolUse, Notification, and Stop [50]. These five suffice to anchor three cross-cutting concerns. • Observability. The agent’s context window is a finite resource whose consumption competes directly with

Plane Behavior Artifact Example

Agent

Skill

Hook

Reasoning Adaptive .md persona Specialists

Execution Guided .md + script oai/run

Observability Reactive Event binding Gatekeeper gate

reasoning capacity, which makes in-loop telemetry collection incompatible with the duration of an end-toend S YNTHESIZE run that may exceed an hour and span dozens of pod-level interactions. Hooks resolve this contention by externalizing observability. For example, a PostToolUse hook serializes each tool call and its result to a structured event log. • Policy. Hooks are also a safety plane and a way to enforce policies. When autonomous agents interact with physical RF infrastructure, deterministic safety guardrails are mandatory. Hooks act as a non-bypassable policy plane. By binding a hook to a given event, G ENESIS can intercept and evaluate an action’s payload before it touches the testbed. If a specialist attempts an unsafe operation the hook terminates the call and returns a hard block (e.g., "decision":"block"). • Audit. Features destined for production networks require strict provenance. Because hooks run as ordinary shell commands outside the LLM’s control, they serve as an objective witness to the pipeline. They capture the exact sequence of tool calls, code diffs, and testbed configurations. This ensures that every action G ENESIS takes could be audited. D. Orchestration Overall, the combination of agents, skills, and hooks constitutes the G ENESIS primitive triad summarized in Table II. Each component covers different functionality planes, comes with different behaviors, and is represented by different artifacts. On top of this triad, an orchestrator (shown in Fig. 1) is implemented by the specific agentic framework adopted in G ENESIS (e.g., Claude Code in this first iteration, see Sec. IV-G). The orchestrator coordinates the activities of the triad. The hierarchy is as follows: an orchestrator may dispatch specialists, and specialists in turn rely on skills (but not on other specialists). In our implementation, the parent conversation acts as the orchestrator and specialists cannot dispatch one another by design. Therefore, only the orchestrator dispatches the specialists, preserving a clear call graph (also shown in Fig. 2). Specialists are run on models selected by the orchestrator for reasoning depth: top-tier (e.g., Opus) for orchestration and for complex reasoning, mid-class models (e.g., Sonnet) for specialists. Cost and latency are thus managed explicitly, as we discuss in Sec. X. Further, G ENESIS agentic pipelines halt on failure and surface logs rather than attempting autonomous recovery across stages, allowing a human review of evidence before resumption. This is both a guardrail (autonomous cross-stage recovery

8

TABLE III M APPING THE G ENESIS PRIMITIVES ONTO CONTEMPORARY AGENTIC RUNTIMES . Runtime

Agent (persona)

Skill (procedure)

Hook (event)

Orchestrator

AutoGen [7] CrewAI [9] LangGraph [33] OpenAI Agents SDK [34] Claude Code [10], [50]

AssistantAgent Role-based Agent StateGraph node Agent class .claude/agents/*.md

FunctionTool BaseTool ToolNode @function_tool SKILL.md

@message_handler BaseEventListener BaseCallbackHandler RunHooks / AgentHooks .claude/settings.json

Swarm Crew with Process.sequential Supervisor StateGraph Agent with handoffs; Runner.run() Parent session

would risk compounding errors) and a design choice with human review as quality gate. Within a stage, bounded local retry loops are permitted.

standardization, commercialization, and the general telecom ecosystem. In the context of G ENESIS, S YNAPSE plays three roles simultaneously: Source of ground truth. S YNAPSE hosts the corpus that every S PEC A NALYZER and C ODE A NALYZER step queries: ingested 3GPP and O-RAN technical specifications, reference open-source implementations (OAI [51], srsRAN [52] [53], OSC RIC [54], FlexRIC [55]), prior experimental campaigns, and the lab inventory described in Sec. IV-E. Crucially, this corpus is expert-verified rather than randomly scraped from the open web: human curators sign off on each ingested specification version, so that downstream agents can ground their outputs in artifacts whose provenance is auditable. The knowledge graph is based on a curated ontology that describes technical and institutional relationships in the telecom ecosystem. • Recipient of generated knowledge. Every G ENESIS run terminates with the I NGEST stage writing back to S YNAPSE (Fig. 2): code diffs with spec-to-code traceability (measurement name → specification clause → source files and line numbers), gNB and xApp logs, E2 indication traces, A NALYZER verdicts, and complete experimental campaigns including the inventory snapshot used. • Cross-capability substrate. The artifacts that one capability produces become the input that another consumes. A H ARDEN bug-fix patch enriches the regression suite that T EST re-runs on every future change; an O PTIMIZE training dataset and the trained policy that ships with it become a reusable benchmark for the next O PTIMIZE run; a D ISCOVER result (novel dApp [56], evaluation campaign, paper draft) becomes a candidate feature for a future S YNTHESIZE run when the corresponding clause is standardized. •

E. Inventory as Code All hardware, network, and device information lives in YAML files and is consumed by relevant specialists at planning time. For each testbed, we define a list of available RUs, UEs, core networks and a distance matrix that records measured Reference Signal Received Power (RSRP) values between UE and every reachable RU (Listing 1). This information is then ingested by relevant specialists on demand. This design keeps the specialists themselves stable as the lab or deployment environments evolve: moving a UE between rooms, provisioning a new network slice, or replacing a failed RU changes a YAML entry rather than any specialist logic. It also enables reproducibility: the exact physical state of the lab at the time of an experiment can be serialized into the knowledge base together with the experimental results. F. The Knowledge Base: S YNAPSE Beyond autonomous reasoning/action loops, G ENESIS relies on a long-term memory for ground truth (technical specifications, papers, documents) and G ENESIS’ output. As shown in Fig. 2, agents within the G ENESIS capabilities query the knowledge base to retrieve information, and the outcome of G ENESIS’ experiments is stored in S YNAPSE. Therefore, this represents the long-term memory of the framework, and what provides connectivity and shared knowledge across the G ENESIS capabilities. S YNAPSE is based on an ingestion pipeline that maps information into a vector and keyword index (hybrid pgvector/BM25), and builds a knowledge graph based on a rich, human-generated ontology. This ontology describes complex relationships across the RAN technical domain, as well as institutional notions related to

G. Portability Across Agentic Frameworks

A legitimate concern with any agentic system is lock-in to a specific runtime and/or LLM. This would prevent adopting state-of-the-art reasoning tools whose performance changes in a matter of weeks. The G ENESIS primitives are designed to be portable. Our implementation targets the most capable agentic systems available at the time of writing, but the underlying directives (specialist personas, SKILL.md files, and orchestration prompts) are expressed entirely in markdown and natural language. Substituting the underlying agent therefore reduces to mapping agent-specific entry points onto the same Listing 1. Distance matrix of the X5G testbed inventory. The file is the single directives, rather than rewriting the workflows. Table III maps source of truth read by the specialist to resolve parameters at planning time. the abstraction onto the major frameworks in use today. - sierra_ue - plmn: "00105" - foxconn01: distance: close avg_rsrp_dBm: -75 ru_attn_dB: 10 - foxconn02: distance: far avg_rsrp_dBm: -110 ru_attn_dB: 10 - samsung_ue

9

six SMC GH200 nodes and eight Gigabyte E251-U70 servers (GPU-equipped) alongside Dell R750/R760/XR5610 CPU SIMULATION EMULATION OVER-THE-AIR servers (their grouping into OpenShift node classes is described RAN in Sec. V-B). Eight Foxconn RPQN-series RUs (n78/n48/n77) Software Stacks RIC/SMO DU Micro services, Core CU DU UE plus VVDN/LITEON/Benetel/Eridan radios cover indoor cells, multi vendor DevOps and a Qulsar QG2 Precision Time Protocol (PTP) grandVirtualization - OpenShift - Automation - LLM serving - Monitoring X5G Infrastructure Colosseum Data Center master disciplined by GPS provides synchronization. The UE Burlington side extends this with outdoor Foxconn, Amplitech, Solid, Airspan, and Benetel RUs. Endpoints include thirteen Radio Sierra Wireless Commercial Off-the-Shelf (COTS) modems (some dual-SIM), OnePlus/iPhone/Samsung handsets, and OAI Emulation softUE instances. Testbed Network Testbed AI Accelerators - Connectivity - Radios Channel emulation sits between simulation and OTA, still relying on hardware in the loop, and has three components, which share infrastructure with X5G but can operate indeFig. 4. G ENESIS agentic testbed and relationships between specialist agents pendently, from a logical point of view. (i) Colosseum [14] and testbed components. is a large-scale channel emulator with software-defined radio connected across a matrix of FPGA-emulated RF channels Three properties make the abstraction portable in practice. modeled on real-world propagation scenarios. (ii) Keysight First, markdown ”specialist” personas translate to the system RuSIM/UeSIM/CoreSIM provide instrument-grade UE, RU, prompt and tool list that every agentic runtime consumes, the and core-network emulation for standards-conformant protocol only adapter required is a loader that parses the frontmatter and interface stress tests. (iii) A custom, single-RU, three-UE into the framework’s agent-selection mechanism. Second, hardware-in-the-loop emulation platform uses using the same SKILL.md files delegate to scripts rather than embed logic, so RU/UE hardware family as the X5G testbed, but with emulated porting a skill between frameworks is a matter of wrapping the rather than OTA channels. same script with a framework-specific tool declaration. Third, modern agentic frameworks are converging on shared conven- B. Virtualization, Automation, and Software Stacks tions for top-level instruction files (e.g., AGENTS.md), which Above the physical layer, Fig. 4 shows a cloud-native further reduces the cost of moving a G ENESIS deployment plane (virtualization, OpenShift, automation, LLM serving, across runtimes to a mapping between conventions rather than monitoring) that schedules the AI-RAN software stacks on top a re-implementation of workflows. of it. All workloads run as OpenShift pods scheduled on worker nodes labeled by hardware class, based on the AutoRAN V. T HE AGENTIC T ESTBED The G ENESIS capabilities presented in Secs. III-IV are only framework [17], or as Colosseum LXC containers. CPU as useful as the physical and software infrastructure they can nodes with SR-IOV Network Interface Cards (NICs) carry 7.2actually drive. Agents need a rich, closed-loop harness in split and CPU-based gNBs (OAI and OCUDU stacks); GPUwhich to test implementations, research hypotheses, and bug equipped nodes carry GPU-accelerated Distributed Units (DUs) fixes. Figure 4 shows the resulting substrate as a layered stack: (NVIDIA Aerial), with Multi-Instance GPU (MIG) slicing compute and testbeds at the bottom (Sec. V-A), a virtualization each accelerator across pods; and general-purpose x86 nodes and automation plane carrying the AI-RAN software stacks carry spectrum sensing, automation, and OpenShift services. above it (Sec. V-B), system-level capabilities that connect each Each class of software services is mapped to an OpenShift layer to the GENESIS specialist agents on the right of the figure performance profile that pins isolated Central Processing Unit (Sec. V-C), and an orthogonal three-tier validation continuum (CPU) cores, configures hugepages and the real-time kernel, that selects the operational mode for the RF channel on every and declares SR-IOV resource pools. The AI-RAN stacks scheduled on this plane (the green tier run (Sec. V-D). in Fig. 4) integrate: • NVIDIA Aerial cuBB [57] for the Artificial Intelligence A. Compute and Testbeds (AI)-accelerated L1, connected via the Functional AppliThe bottom band of Fig. 4 aggregates two co-located physical cation Platform Interface (FAPI) over shared memory to testbeds (X5G [15] and Colosseum [14]), together with their the OAI L2 in a multi-container pod. AI accelerators, fronthaul/connectivity, and radios, exposed to • OAI [58], built in one of three profiles—7.2 (Open G ENESIS through a shared testbed network. Fronthaul), monolithic (e.g., for RFSIM), or aerial X5G is the primary OTA target: a multi-campus private (Aerial FAPI)—depending on the target hardware path. 5G spanning two buildings on separate Northeastern camOCUDU [53] provides a monolithic or 7.2 gNB. puses (Boston and Burlington, MA) connected through a • Open5GS for the 5G core, with twelve independent campus network, giving a single logical deployment that deployments (different PLMN IDs) segmented across mirrors the multi-site character of commercial private 5G OpenShift namespaces, enabling core-network isolation rollouts [15]. The Boston side hosts the production compute: between experiments. Substrate Layer - Testbeds and Infrastructure Validation Tier Operational modes for the RF channel

GENESIS Agents

OAI / Aerial specialist

OpenShift specialist

COTS + softUE

specialist

specialist

specialist

X5G

specialist

10

O-RAN Software Community (OSC) near-RT RIC [54] and FlexRIC [55] for xApp execution, together with a Service Management and Orchestration (SMO) layer for non-RT RIC/rApp hosting and AI/ML pipelines. • M-Plane and NETCONF/YANG clients for Open Fronthaul RU configuration, exposed to agents through a dedicated MCP server. • Support services: ClickHouse for in-pod time-series capture alongside cuBB, and a WebSocket daemon for scripted Sierra-UE control.

•

C. System-Level Capabilities Exposed to GENESIS Specialists

parameterized by inventory and isolated by namespace and SR-IOV virtual function, multiple X5G OTA and channelemulation experiments can run concurrently with no sharedresource contention—G ENESIS can validate one feature on the channel-emulation tier while a previous one is still being regressed OTA. The lab state itself lives in an inventory YAML file (Sec. IV-E), so the exact physical configuration at the time of a S YNTHESIZE run is serialized and ingested into the knowledge base alongside the result, closing the provenance loop. The same specialists drive the channel-emulation and OTA tiers through configure and experiment skills that follow the same contract and parameter schema used in simulation.

The dashed lines on the right of Fig. 4 connect each G ENESIS D. Staged Validation Continuum specialist (Sec. IV-A) to the layer it acts on. The following The top band of Fig. 4 marks the three operational modes paragraphs describe the system-level capability behind each for the RF channel that T EST RUNNER targets in sequence— of those edges, which specialists compose through skills simulation, emulation, OTA—each trading speed for fidelity (Sec. IV-B) into the end-to-end experiments that back the and catching a different class of defect. Simulation runs RFSIM T EST RUNNER stage. (for OAI) or ZMQ with the OAI UE (for OCUDU) on a single DevOps specialist—cluster and pod lifecycle: A two-phase gNB-UE pair in seconds to minutes, catching compilation deployment contract (generate → apply) produces reviewable errors, ASN.1 encoding bugs, E2-setup misconfigurations, and OpenShift manifests before any workload is scheduled. Skills logical defects. Emulation runs the same binaries on Colosseum, manage deploy/scale/delete operations, inspect node affinity, Keysight, or the HIL platform in minutes to hours, catching bind SR-IOV resources, claim GPU slices, and stage perforfronthaul timing violations, FAPI interoperability bugs, realmance profiles. This is the loop invoked during S YNTHESIZE’s time scheduler constraints, and multi-UE protocol edge cases infrastructure bring-up. that pure software cannot reproduce. Over-the-air on X5G is Radio specialist—RU configuration and health: The X5G the ground-truth tier, exercising real RF (antennas, fronthaul RUs are configured either through Open Fronthaul M-Plane timing sensitivity, channel dynamics), scale behavior (multi-UE (NETCONF/YANG) or through an SSH-based fallback that applies XML patches directly. Each configuration change iperf, mobility), and the production DU/RU hardware path. returns a confirmed RU MAC, fronthaul sync status, and PTP VI. F ROM P RIMITIVES TO C APABILITIES : S YNTHESIZE lock state—the information T EST RUNNER needs to validate that the radio is ready before launching the gNB. As suggested by Figs. 1 and 2, the agent/skill/hook primitives, RAN specialist—gNB bring-up and observability: The running on agentic testbed of Sec.V, compose into a full OAI gNB startup is driven by a set of skills that patch capability. In this section, we describe an example of such the configuration file according to the desired deployment composition by focusing on S YNTHESIZE. This, together with conditions, rebuild and launch the process, and monitor the log H ARDEN, T EST, and D ISCOVER, is then showcased end-to-end for a fixed milestone sequence (Initializing → NGAP in Secs. VII—IX. connected → Cell Active → PRACH received), Given a published specification and a target measurement which brings the gNB from inactive to connected to core or feature name, S YNTHESIZE produces a validated change to and radio and a UE connection attempt. Milestone successes or a production-grade O-RAN stack. The same stages and skills failures are presented as structured status back to the G ENESIS can be leveraged by T EST, H ARDEN, and O PTIMIZE. orchestrator. As shown in Figure 2, S YNTHESIZE decomposes the spec-toUE specialist—orchestration and traffic: Sierra Wireless OTA path into six sequential stages, each owned by a specialist COTS modems are controlled through a WebSocket daemon agent. (1) S PEC A NALYZER grounds the work in a specification: exposing connect/disconnect, SIM-slot switch, PDU-session it queries the G ENESIS knowledge base S YNAPSE using lifecycle, ping, and iperf operations. SoftUEs are driven through the synapse-retrieve skill (Sec. IV-F) and dispatches the same skill surface with different APIs. An inventory- a SpecResearcher that uses a spec-mapping skill to maintained UE-RU proximity matrix (measured RSRP) lets the understand the practical components associated to translating testbed and emulation specialists select physically reasonable the specification into code. For example, for KPMs, it infers UE-RU pairs for the S YNTHESIZE OTA validation runs the KPM report style and node scope [59]. Every field written (Sec. IV-E). into /specs/<name>.md must be grounded in a retrieved Testbed and Emulation specialists—isolation, concurrency, chunk; otherwise the agent is instructed to escalate to the and reproducibility: The system provides access to Open5GS human operator. This is to ensure that the starting point for network functions with dedicated PLMNs; subscriber provi- the implementation is actually based on real specifications. sioning and per-namespace log inspection are wrapped as (2) C ODE A NALYZER maps the specification onto the target skills, giving S YNTHESIZE an isolated control-plane slice O-RAN codebase (OAI in our experiments; the pipeline per experiment. Because pods, RUs, cores, and UEs are also applies to other stacks, e.g., OCUDU) and emits an

11

Knowledge Loop

IMPLEMENTATION_PLAN. Continuing with the example TABLE IV S UMMARY OF THE RRC.C O N N M E A N MEASUREMENT USED IN C ASE A. of KPM features, C ODE A NALYZER queries two subagents, i.e., KPM-Implementer, which classifies the KPM into Property Value one of four canonical O-RAN patterns (instantaneous scalar, Mean number of users in RRC CONcumulative counter with delta, ratio/percentage, histogram with Description NECTED mode per NR cell during the label bins), and a KPM-E2Advertiser, which is responsible granularity period TS 28.552, clause 5.1.1.4.1 [18] for the identification of the fields necessary to the E2 Setup. 3GPP reference O-RAN reference O-RAN.WG3.E2SM-KPM [60] The plan is gated by human approval before the next step. Collection method SI (sampling + arithmetic mean) (3) C ODE W RITER implements the change. A RAN spe- Data type Single integer NRCellCU cialist agent drives the compile and build skills, iterating Measured object node types ngran_gNB, ngran_gNB_CU against the compiler log until success or a bounded retry budget Applicable KPM report style [59] Style 1 (E2 Node Measurement) is exhausted; each specialist verifies its own changes before Action / Indication formats [59] Format 1 / Format 1 the next begins. (4) T EST RUNNER validates the implementation along the Implement the KPM measurement RRC.ConnMean three-tier continuum of Sec. V-D (RFSIM, then channel using synthesize capability. You can find more emulation, then OTA on X5G), reusing the same branch, information in TS 28.552 and O-RAN.WG3.E2SM-KPM. configuration template, and skill set at every tier. Listing 2. End-to-end S YNTHESIZE invocation for Case 1. (5) A NALYZER is a generic metric extractor: given a list of metrics (name, extractor, aggregation, threshold) and a report path, it parses T EST RUNNER’s artifacts into a pass/fail verdict KB and a structured findings report. (1) SpecAnalyzer RRC.ConnMean spec summary, NRCellCU measured object (6) I NGEST closes the knowledge loop by staging every pipeline artifact (code diff with spec-to-code traceability map, (2) CodeAnalyzer* IMPLEMENTATION_PLAN : Style 1 cell-level read path, gNB-CU-CP meas. advertisement logs, E2 trace, A NALYZER verdict, Gatekeeper signature) into (3) CodeWriter S YNAPSE, after a human approval gate. Future runs retrieve targeted edits to OAI RRC, E2AP/KPM… these artifacts through the same synapse-retrieve skill (4) TestRunner* used at S PEC A NALYZER time. Rfsim 4-UE up/down, OTA with Sierras. ”xApp: Format 1 indications at 1000 ms gran..” Two boundaries deserve emphasis. S YNTHESIZE is not a (5) Analyzer “RRC.ConnMean tracks ground truth at 7/7 transitions.” Data analytics, insights. drop-in replacement for an engineer. Its goal is to reduce (6) Ingest the marginal cost of adding a feature from weeks to hours, spec + plan + code diff + logs + trace while keeping a human reviewer at the points where judgment matters: initial specification fields, stage failures, and Fig. 5. Per-stage S YNTHESIZE pipeline trace for Case Study 1 and the ingestion. S YNTHESIZE is also not a monolithic LLM prompt: RRC.ConnMean-specific artifact each produced. Stages marked by an asterisk each stage is owned by a distinct agent or skill, can be require a human approval. inspected in isolation, and can be replaced (e.g., swapping the KPM-Implementer for a different codebase) without disrupting the rest of the pipeline. Two end-to-end case protocol stack and exposure over the O-RAN E2 interface. It is studies for S YNTHESIZE (an E2SM-KPM measurement and the simplest of the three G ENESIS use cases in this paper: two a cross-stack Conditional Handover with E2SM-RC xApp) specifications (one 3GPP, one O-RAN), one OAI subsystem are presented as qualitative results in Sec. VII and Sec. VIII. (the measurement collector), leading to an O-RAN controlOther capabilities are implemented according to the same logic, plane addition in which the gNB reports a new value but keeping the separation between steps (as shown in Fig. 2) and nothing reaches back into the radio stack. RRC.ConnMean measures the mean number of users in human reviews to avoid hallucinations. RRC CONNECTED mode (i.e., users with an active controlplane association to the cell) per NR cell, averaged over VII. C ASE S TUDY 1: M EASURING AND R EPORTING KPM S a configurable reporting period. Its definition spans two We demonstrate G ENESIS on three use cases. For each one, specifications: 3GPP TS 28.552, clause 5.1.1.4.1, which defines we declare success when the pipeline runs to completion under the measurement semantics (description, collection method, a single natural-language prompt with the human reviewer data type, measured object, applicable node types), and Oaccepting at the documented gates, the synthesized code RAN.WG3.E2SM-KPM [60], which defines the reporting compiles and passes the milestone sequence on every targeted envelope (report style and action/indication formats) used tier, and the A NALYZER-emitted verdict matches the acceptance to expose it over the E2 interface. Both are summarized in criteria distilled from the specifications. In the following three Table IV. The user-side invocation is a single natural-language sections, we discuss each use case, including results that prompt to the orchestrator (Listing 2). validate the output of the G ENESIS pipeline on the use case. Pipeline trace: Figure 5 summarizes the perThe G ENESIS pipeline itself is evaluated in Sec. X. stage trace for this case. S PEC A NALYZER writes For the first use case, we prompt the system to implement /specs/RRC_ConnMean.md grounded against TS 28.552. the RRC.ConnMean KPM, including its computation in the C ODE A NALYZER dispatches KPM-Implementer, which

12

UE ID

RRC.ConnMean

RRC.ConnMean

UE attached

TARGET

SOURCE

UE

UE

TARGET

SOURCE

3 RRC Reconfig. for Meas.

RRC Reconfig. for Meas.

2 1

Meas. Report for specified Event

Meas. Report for specified Event

0 4 3 2 1 0

gNB decides HO exec.

gNB determines HO condition and target cell candidates

RRC Reconfig. for HO w/ single target cell

RRC Reconfig. for HO w/ up to 8 target cells RRC Reconfig. Complete

10 20 30 40 50 60 70 80 90 100 110 120 130 140 Time since gNB start (s)

VIII. C ASE S TUDY 2: C ONDITIONAL H ANDOVER WITH O PTIMIZATION X A PP The second use case involves a more complex procedure. The implementation, testing, and optimization of Conditional Handover with a closed-loop E2SM-RC xApp draws on four 3GPP/O-RAN specifications, touches several OAI subsystems, and terminates in an xApp (an application running in the ORAN Near-RT RIC and controlling the stack through E2) that writes back into the gNB to steer handover behavior at runtime. CHO, introduced in 3GPP Release 16 [61], is a mobility procedure in which the network prepares a handover command in advance, and the UE executes it only when its measurements satisfy a triggering condition. We illustrate this procedure in Fig. 7, where we also compare it with the classical procedure. In the latter, the network decides when the handover happens and the UE follows this decision. The main advantage of CHO is

RRC Reconfig. Complete

RRC Reconfig. Complete

Fig. 7. Traditional Handover vs. Conditional Handover in 5G NR [61], [62]. In the traditional procedure, the network commits to a single target cell and the UE executes the reconfiguration immediately. In CHO, the network pre-arms several candidate cells and defers the execution to the UE.

UE: NR RRC

classifies the target as a snapshot value reported per cell at each tick (the simplest of the four canonical measurement shapes the implementer recognizes), and KPM-E2Advertiser, which extends the list of measurements the gNB advertises when it first joins the RIC. C ODE A NALYZER emits an IMPLEMENTATION_PLAN, and the session pauses for user approval. On approval, C ODE W RITER applies the plan paired with the RAN specialist for the compile loop. Based on our experiments (see Sec. X), the resulting patch modifies three files in the OAI measurement subsystem. T EST RUNNER then runs the simulation tier and replays the same flow at channel emulation and OTA using the configuration contract of Sec. V-D. A NALYZER parses the bring-up milestones in the gNB log, the stream of values reported to the RIC, and the delivery-latency distribution, and emits a pass verdict. I NGEST stages the artifacts into S YNAPSE. Outcome: The new measurement is advertised by the gNB and observed in the reporting stream on all three validation tiers. The numerical value tracks a hand-computed ground truth within sampling tolerance as shown in Fig. 6. The per-stage wall-clock breakdown and token cost appear in Sec. X, where we evaluate G ENESIS itself.

UE exec-s HO when condition is met

Near-RT RIC + xApp

OAI (2026.w21)

GENESIS

A2 , A3 meas. events*

Conditional reconfig. cache

A2, A3 meas. timers*

A4 meas. event

L3 meas. framework*

CHO evaluate and execute Detach and RACH upon condition

RRC.Reconfig.

FlexRIC + RC SM

Anti-pingpong xApp C on FlexRIC, INSERT Style 3

Meas. report (event A4) RIC Control POLICY Style 3

RIC Indication INSERT Style 3

gNB CU: RRC + F1AP + E2

Fig. 6. Time series plot of RRC.ConnMean. The trace climbs 0-1-2-3 as UE 1–UE 3 attach, falls back to 1 as UE 2 and UE 1 detach, recovers to 2 when UE 4 attaches, and falls again to 1 when UE 3 detaches and matches the hand-computed ground truth (the number of active nr-uesoftmodem processes shown in the bottom panel) at every one of the seven transitions within one granularity period.

UE decides HO

UE exec-s HO immediately

Traditional F1 handover

CHO state machine

A3 event, execute immediately

Per-UE context, up to 8 candidates

Meas-report → HO dispatch

F1AP conditional mobility emit

F1AP CHO ASN.1 codecs

Event A4 prep dispatcher

E2 RC service model agent

E2 RC POLICY + INSERT services

A3 case only, no A4 handling

REPORT styles 1 and 4 only

UE Context Mod with CHO-initiation Per-UE optimization and target

Service style 3

Fig. 8. Logical architecture of the end-to-end CHO use case. Solid boxes (left) mark baseline OAI 2026.w21 components. Dashed boxes (right) mark modules synthesized by G ENESIS. Components marked by an asterisk are contributed by OAI MR !3879 and not part of the 2026.w21 baseline. The additions span three layers: a UE-side conditional- reconfiguration cache with an A4 evaluator, a CU-side CHO state machine that emits the F1AP CHO ASN.1 sequence and exposes new E2SM-RC POLICY/INSERT Style 3 endpoints, and a FlexRIC-hosted anti-ping-pong xApp that closes the loop over E2.

that the reduced overhead makes it workable in situations where regular handover fails, such as high-speed situations. Here, quick decisions from the UE are more successful compared to a lengthy exchange with the network. To realize CHO end-to-end, S YNTHESIZE must read across four specifications, which we sum up in Table V (3GPP’s RRC, F1, and overall NR-NG-RAN descriptions, plus ORAN’s E2SM-RC service model that defines the control surface exposed to xApps), and implement code across several OAI subsystems (the CU, the DU, the UE-side evaluator), as illustrated in Fig. 8. In this use case, we also instruct G ENESIS to exercise CHO from an xApp which suppresses ping-pong handovers. This ping-pong phenomenon arises when

13

TABLE V S UMMARY OF THE S PECIFICATIONS FOR CHO

Description

A mobility procedure where the handover command is prepared in advance by the network but executed by the UE only when specific radio conditions are met TS 38.300 [62]; TS 38.331 [61]; TS 38.473 [63] O-RAN.WG3.E2SM-RC-R003-v03.00 [64] RRC + F1AP + E2SM-RC + UE Event A3/A4/A5. insert Style 3 Indication ID 2 for mobility events; policy Style 3 Action 2 for CHO control

3GPP references O-RAN reference Feature class Trigger / execute E2 service style

Implement Conditional Handover over F1 end-to-end together with a closed-loop E2SM-RC anti-ping-pong xApp. Design relevant simulation experiments to test yourself and handoff to me for the OTA test. You can find more information in TS 38.300, TS 38.331, TS 38.473, and O-RAN.WG3.E2SM-RC-R003.

(2) CodeAnalyzer* IMPLEMENTATION_PLAN: CHO A4-prep + A3-execute MeasConfig, F1AP IE 373 (3) CodeWriter targeted edits to OAI RRC,F1AP,GNB-APP, E2AP, NR UE… (4) TestRunner* Rfsim sweep 3-200 km/h, OTA on Sierra. “xApp: A3 offset 5à10 dB due to 5 PPs.” (5) Analyzer “CHO 5/5 at every speed (3-200 km/h)”. Data analytics, insights. (6) Ingest spec + plan + code diff + logs

Fig. 9. Per-stage S YNTHESIZE pipeline trace for Case Study 2 and the CHOspecific artifact each produced. Stages marked by an asterisk require a human approval.

RSRP DU0 ∆ (first HO) −42 −45 −48 −51 −54

RSRP DU1 ∆ (PP HO)

Wobble peak A3 offset 10 9 8 7 6 5

A3 offset (dB)

Listing 3. End-to-end S YNTHESIZE invocation for Case 2.

(1) SpecAnalyzer CHO procedure, candidate trigger events (A3/A4/A5), F1AP CHO IE on UE Context Mod

Knowledge Loop

Value

RSRP (dBm)

Property

KB

Serving

a UE is in between two cells, and alternatively crosses KPI thresholds for triggering a handover, which makes it perform DU 1 multiple handovers between the cells in a row, yielding to DU 0 0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 poor performance. The xApp itself is based on the OAI tsim (s) FlexRIC implementation, showing how G ENESIS can work across different code bases. This whole process is triggered by Fig. 10. xApp anti-ping-pong loop. UE wobbles between x = 4 m and a single natural-language prompt (Listing 3), augmented only x = 16 m on a 20 m straight line at 12 km/h. The A3 offset rises by 1 dB per detected ping-pong. Once the offset reaches 10 dB, the corresponding threshold by pointers to the specifications. exceeds the wobble’s maximum gap and the UE remains on its last serving What G ENESIS produced: Figure 9 traces the six S YN - cell. Blue / red arrows distinguish the first HO of each mirror pair from the THESIZE stages and the CHO-specific artifact each produced. back HO that completes the ping-pong. The rest of this paragraph walks through them in order. S PEC A NALYZER queries each specification in turn and writes /specs/cho-e2sm-rc.md, capturing four artifacts: a plain (an INSERT-style indication on every handover event and description of the conditional-handover procedure, the trigger a POLICY-style control accepting an updated A3 offset); condition the UE must evaluate (G ENESIS always queries and (iv) the xApp itself, hosted on the open-source FlexRIC the human reviewer for the trigger to use, and we always runtime. The xApp subscribes to the INSERT endpoint; on chose a signal-strength inequality known in 3GPP as “Event each handover event it appends to a per-UE ring buffer and A4” in all runs), the message shape that carries the prepared applies a pair-wise ping-pong rule. The xApp flags a ping-pong command between gNB units, and the control surface the whenever two consecutive handovers form an A-B-A pattern xApp will use to push commands into the gNB. DevOps within Tpp = 10 s. On detection, the xApp pushes a control then brings up the gNB CU pod and builds the relevant message back to the gNB that raises the signal-strength margin container image. C ODE A NALYZER locates the insertion surface required to trigger another handover (A3 offset) between the in the OAI source (the existing non-conditional handover code, affected cells by +1 dB, damping the oscillation. the data structures the gNB uses to advertise its capabilities Closed-loop validation in simulation: T EST RUNNER first to the RIC, the UE-side measurement evaluator, and the stress-tests the xApp in a two-cell RFSIM deployment: two pre-compiled codec for the inter-unit messages) and emits DUs placed 20 m apart on a 1-D corridor, with the simulated an IMPLEMENTATION_PLAN that designs the architecture UE wobbling between x = 4 m and x = 16 m at 12 km/h. shown in Fig. 8. Figure 10 depicts the trial. Every crossing of the cell boundary The architecture identified by G ENESIS and synthesized fires a handover and the return leg of the wobble produces the contribution spans four layers: (i) a CU-side CHO module mirror handover an instant later. The xApp detects five such on the order of a dozen new functions and supporting data pairs in succession and, after each, pushes a +1 dB marginstructures that prepares, arms, and emits the conditional bumping update back to the gNB, walking the A3 offset from reconfiguration over F1AP; (ii) a UE-side evaluator that fires 5 dB up to 10 dB. With the 2 dB hysteresis added on top, the once the cached conditional reconfiguration’s trigger is met; effective trigger threshold reaches 12 dB. The next boundary (iii) two new E2SM-RC service points on the gNB E2 agent crossing no longer satisfies the A3 entry condition and the

14

CHO

HO

HO Succ (%)

100 80

TARGET

60 40 20

SOURCE

0 3

30

60

120

200 UE

Speed (km/h)

Fig. 11. Handover success rate as a function of UE speed. For each (mode, speed) pair, five independent experiments were conducted. HO is considered successful when the UE completes RACH on the target cell and the CU logs handover completion.

RSRP (dBm)

UE stays on its last serving cell. The trial confirms that the Fig. 12. Over-the-air CHO testbed setup. The source DU and target DU are synthesized control loop closes correctly: events from the gNB deployed at opposite corners of the lab. A Sierra Wireless EM9191 UE on a are decoded by the xApp, ping-pongs are classified accurately, mobile cart is walked along the dashed path from the source’s coverage zone and control messages land back at the gNB in time to influence into the target’s. the next decision. A4 threshold A4 fires A3 fires CHO execute High-speed two-cell deployment: To evaluate the benefits Target DU Candidate DU Source DU ∆ ≥A3 offset of CHO, T EST RUNNER next builds scenarios with increasing −65 UE speeds: two cells on the same NR frequency (band 78), one −70 CU, two DUs, and one softUE, all connected over RFSIM. The −75 −80 DU cell sites are 200 m apart. The UE moves from one to the −85 other in a loop, and completes one handover per transit leg. The −90 −95 scenario is replayed at five speeds, from 3 km/h (pedestrian) −100 0 3 6 9 12 15 18 21 24 27 30 to 200 km/h (high-speed train). G ENESIS then compares the Time since UE attach to source DU (s) handover success rate for each condition and handover style by running each experiment five times. Figure 11 reports the Fig. 13. Over-the-air CHO result captured during one walk of the testbed in handover success rate as a function of UE speed. We observe Fig. 12. The CU logs per-link RSRP for the serving cell (source DU2, PCI 1, that the CHO implemented by G ENESIS successfully improves red) and the candidate (target DU1, PCI 0, green). Three events mark the conditional-handover chain: A4 fires (t ≈ 15 s) when the candidate crosses the the reliability of the RAN for high speed scenarios: in all A4 threshold and the network arms the conditional reconfiguration; A3 fires conditions, CHO always succeeds, while at 60 km/h, 20% of (t ≈ 17 s) when the candidate exceeds the source by the A3 offset so the UE’s classic handovers fail. This rises to 60% of failure at 120 km/h local trigger is met; and CHO execute (t ≈ 18 s) when the UE autonomously fires the prepared handover. and 100% at 200 km/h. Over-the-air validation: To rule out artefacts specific to RFSIM, the same two-cell band-78 deployment was brought up running natively. The remaining three (D ISCOVER, O PTIMIZE, on real radio units on the G ENESIS testbed and validated OTA S ECURE) are part of the same architectural design but have not with a commercial Sierra Wireless EM9191 modem. Figure 12 yet been driven end-to-end inside G ENESIS. For D ISCOVER, shows the lab setup. Unlike the RFSIM trials, this experiment however, we have a close empirical reference point in our involves a human in the loop, with G ENESIS prepping and prior work ALLSTA R [19], which built a problem-specific, monitoring the experiment and prompting the human reviewer procedural LLM-based pipeline for MAC scheduler synthesis to move the UE between the two cells’ coverage zones. using LLM agents on the same X5G testbed G ENESIS uses. Figure 13 shows the resulting per-link received-signal-strength This section uses ALLSTA R to do two things: trace how its two timeline collected from the CU’s measurement reports during procedural pipelines map onto G ENESIS’s agentic S YNTHESIZE one such walk: the UE attaches to DU2 (PCI 1), the preparedand D ISCOVER capabilities (Fig. 14), and identify the manual but-deferred handover toward DU1 (PCI 0) is held until the steps in ALLSTA R that G ENESIS could now automate. cached trigger condition is satisfied, and the UE executes the ALLSTA R in brief: MAC scheduling is a well-studied transition on its own. This validation against a COTS UE topic in academia, with new algorithms published every year confirms that G ENESIS implemented CHO in a spec-compliant for different intents: delay-awareness, bursty traffic, fairness, way. slicing, etc. Each work typically benchmarks in simulation, with its own unique set of assumptions and input metrics, which IX. C ASE S TUDY 3: S CHEDULER D ISCOVERY makes extracting the algorithm, re-implementing it inside a The two preceding case studies exercise G ENESIS end-to- production MAC stack, adapting it to the KPIs and controls end on a fresh intent. The third looks at the framework from that stack exposes, and validating it on real radios a slow and a different angle. Of the six capabilities introduced in Sec. III, cumbersome process. ALLSTA R closes this gap by ingesting this paper has shown S YNTHESIZE, T EST, and H ARDEN 18 scheduler papers, and, using LLM pipelines, generating

15

ALLSTaR: Procedural

GENESIS: Agentic

maps to

Scheduling Papers Paper Title • Abstract •…

LLM Code Generator Tests

ALLSTaR Schedulers Library

Network Operator Intent

Synthesis

ALLSTaR: Papers to Schedulers

LLM Intent Parser

Intent Sched Generator

KB

(4) Analyzer Analyze and assess research hypothesis (3) TestRunner Run DU with new research artifact, collect KPIs (2) CodeWriter Implement scheduler (or variants) if necessary

G ENESIS

Monolithic

Metric

Opus 4.7 Sonnet 4.6 Opus 4.7 Sonnet 4.6

Wall-clock Success rate Cost per trial (USD)

44 min. 100% $28.36

93 min. 60% $17.18

78 min. 0% $43.76

113 min. 0% $18.73

(1) HypothesisEngine Map research question to scheduler design, identify is scheduler is in KB

Tests

ALLSTaR: Intent to Schedulers

TABLE VI C OMPARISON OF G ENESIS AND A MONOLITHIC SINGLE - AGENT BASELINE ON THE SAME FEATURE - IMPLEMENTATION TASK .

Discovery

Research Hypothesis Sched A > Sched B

Fig. 14. Mapping of ALLSTaR scheduling synthesis and discovery capabilities into the G ENESIS agentic discovery pipeline.

Code). All metrics reported in this section are the median over N = 5 independent trials. As frontier-model capabilities change on a timescale of weeks, the absolute numbers reported here are best read as a snapshot of mid-2026 model behavior, with the architecture rather than the absolute numbers as the durable contribution.

working scheduler code to be tested inside OAI on the X5G testbed (top left, Fig. 14). The schedulers are then assembled as A. Comparison with State-of-the-Art Coding Agent a library, which, combined with test results, can be leveraged by We start by evaluating G ENESIS against Claude Code as a second LLM pipeline. This second pipeline takes an operator “monolithic” baseline. Compared to G ENESIS, the monolithic intent as input and generates new schedulers adapted to the approach has access to the same set of scripts (that are called by operators’ intent (bottom left, Fig. 14). the skills of G ENESIS) and testbeds. However, instead of having Mapping ALLSTA R onto G ENESIS primitives: ALL- access to our agents, skills, hooks, and staged validation, the STA R consists of two procedural pipelines (left of Fig. 14) monolithic baseline has to directly use its built-in tool calling that line up with two G ENESIS capabilities, mediated by routines to discover and leverage them. the same scheduling element library that here plays the role We evaluate both G ENESIS and the baseline using Claude of S YNAPSE. The per-paper ingestion pipeline (Papers to Code with Opus 4.7 and Sonnet 4.6 models. This comparSchedulers) is an instance of S YNTHESIZE. The Intent to ison is performed on the simplest of our use cases, e.g., Schedulers pipeline is the one that maps onto D ISCOVER. RRC.ConnMean KPM implementation. A trial is classified as In G ENESIS, this loop becomes the four-stage agentic pipeline a failure if the LLM performs destructive actions (e.g., deleting on the right of Fig. 14, driven by a research hypothesis of the critical OpenShift deployments, which makes it unable to keep form “scheduler A outperforms scheduler B under workload W ” running experiments) or fails to converge before the exhaustion (i.e., the operator intent restated comparatively, or as a research of its context window. question). H YPOTHESIS E NGINE (1) translates the hypothesis We report the results in Table VI. As shown in the table, into a concrete scheduler design and queries S YNAPSE to check G ENESIS significantly improves over the baseline, which is whether an artifact that already satisfies the claim exists; if so, not able to perform the task with any of the models. We also the run skips ahead to validation. Otherwise, C ODE W RITER (2) note that Opus 4.7’s success rate is of 100% against 60% implements the missing scheduler or a variant of one already in for Sonnet 4.6, while also requiring less time to run. This the library by using the same code-generation skills exercised poses an interesting tradeoff: if wall-clock time is the prime in the previous case studies. T EST RUNNER (3) deploys the concern, Opus brings significant benefits, however, if one is artifact on the X5G DU and collects the KPIs the hypothesis more interested in implementing a large number of features depends on, and A NALYZER (4) compares those measurements quickly, G ENESIS, combined with a slightly less capable but against the hypothesis and against library baselines drawn also less expensive model (e.g., Sonnet) can have its merits, as from S YNAPSE, then writes the run (artifact, traces, verdict) the cost of a trial normalized by the success rate comes down back to S YNAPSE for future D ISCOVER or S YNTHESIZE to 1.4 × 17.18 = $24.05 for Sonnet, against $28.36 for Opus. calls. Unlike ALLSTA R’s pipeline, where the four steps are hard-wired against a fixed library schema, and specific to B. Per-stage Cost and Time Breakdown scheduling, in G ENESIS they are agent specialists driven by We now profile the operational cost of G ENESIS itself. the same orchestrator that runs S YNTHESIZE, so each step can Figures 15 and 16 report token usage with dollar cost and be skipped, retried, or substituted depending on what S YNAPSE wall-clock time, broken down by the six S YNTHESIZE stages already contains, and applied to other domains (e.g., handover and color-coded by configuration: KPM/Opus, KPM/Sonnet, optimization, as discussed in Sec. VIII). and CHO/Opus. Two stages dominate. Across all three configurations, X. P ERFORMANCE E VALUATION AND C OMPARISONS C ODE W RITER and T EST RUNNER together account for roughly We now evaluate G ENESIS’s operational overhead in terms two-thirds of both wall-clock time and token cost. Both of time and token cost, and how its capabilities compare to are iteration-heavy: C ODE W RITER loops against compiler existing state-of-the-art agentic LLM approaches (i.e. Claude output until the patch builds, and T EST RUNNER replays the

KPM (Opus)

KPM (Sonnet)

Feature (Opus)

Cost (Opus)

Cost (Sonnet)

Cost (Feature)

2

10

101 100 10−1

er er ner iter alyz Run eWr eAn Test Cod Cod

alyz

cAn

Spe

r

lyze

Ana

gest

In

Fig. 15. Per-stage token usage and USD cost across two pipelines. Light dotted bars: RRC.ConnMean S YNTHESIZE on Opus (median). Mid striped bars: same pipeline on Sonnet (median). Dark cross-hatched bars: CHO + E2SM-RC S YNTHESIZE on Opus. Color encodes token category; bar saturation and fill pattern encode the run. Cost markers (right axis) use distinct shapes per run. Total run cost incl. parent session: $28.36 (KPM/Opus), $17.18 (KPM/Sonnet), $102.91 (Feature/Opus).

KPM (Opus) Wall-clock time (min.)

Tokens (M) / Cost (USD)

16

KPM (Sonnet)

Feature (Opus)

102

101

100

er er ner iter alyz alyz Run eWr eAn cAn Test Cod Spe Cod

r lyze Ana

t

s Inge

Fig. 16. Median wall-clock time per S YNTHESIZE stage. Light dotted bars: RRC.ConnMean pipeline on Opus. Mid striped bars: same pipeline on Sonnet. Dark cross-hatched bars: CHO + E2SM-RC pipeline on Opus. Solo totals: 44 min. (Opus KPM), 93 min. (Sonnet KPM), 226 min. (Opus Feature).

The operating point that follows: if wall-clock latency drives the deployment, Opus dominates; if the goal is to amortize a fixed budget across many features run in parallel, Sonnet is competitive on cost-per-success and trades latency for throughput. This is the tradeoff the agent/skill/hook split is designed to enable: because each specialist’s reasoning budget is bounded by its persona, swapping the underlying model is a configuration change rather than a re-implementation.

same bring-up flow at each tier of the validation continuum. S PEC A NALYZER and C ODE A NALYZER are dominated by grounded retrieval against S YNAPSE and are inexpensive by comparison. A NALYZER and I NGEST have the lowest expenses. Cache reads dominate the long-running stages. Cache reads account for 94% of all tokens consumed across the XI. C ONCLUSION AND F UTURE W ORK pipeline and are billed at 10% of the base input price per token [65]. This is the visible signature of two design decisions: In this paper, we presented G ENESIS, an agentic framework the SKILL.md progressive-disclosure pattern reuses the same that compresses the cellular R&D life-cycle into a closed, procedural body across iterations, and the specialist-isolation intent-driven loop grounded in real-radio observations and discipline (Sec. IV-D) keeps the same persona on the same a persistent knowledge plane. We built G ENESIS on three context for the duration of its sub-conversation. Without these portable primitives (agents, skills, and hooks) coordinated by choices the per-trial cost would be several times higher than an orchestrator and unified by S YNAPSE, a hybrid-retrieval the reported $28.36 / $17.18 / $102.91. knowledge base that serves as both ground truth and artifact Complexity scales with feature scope, not framework sink. G ENESIS drives a three-tier validation continuum (RFSIM, overhead. The CHO configuration costs roughly 3.6× what channel emulation, OTA on X5G) and six capability pipelines RRC.ConnMean costs in dollars and 5.1× in wall-clock, on (S YNTHESIZE, T EST, H ARDEN, O PTIMIZE, D ISCOVER, S E the same six stages and the same orchestrator. The blow- CURE) spanning the full RAN R&D life-cycle. We instantiated up concentrates in C ODE W RITER and T EST RUNNER, which three end-to-end case studies, i.e., RRC.ConnMean as a are the stages whose work is bounded by the feature, not S YNTHESIZE anchor, conditional handover with a closedby the framework. S PEC A NALYZER and C ODE A NALYZER loop E2SM-RC xApp, and the ALLSTaR scheduler-discovery rise modestly (more specs to read, more insertion sites to pipeline. For synthesis, G ENESIS achieved a 100% success rate map). A NALYZER and I NGEST are essentially unchanged. The across statistically independent trials, while the off-the-shelf framework overhead is therefore approximately fixed and the Claude Code baseline (Opus 4.7 and Sonnet 4.6) produced no marginal cost of harder features is paid in the stages that have working implementation on any attempt. Next steps include to do more actual work. further development of agentic capabilities, especially around D ISCOVER and S ECURE instantiations, deeper cross-capability compounding through S YNAPSE, and closing the standards C. Model Selection: Speed vs. Cost per Success Analyzing Table VI alongside the per-stage figures surfaces feedback loop with G ENESIS-driven 3GPP contributions. a counter-intuitive operating point. Opus 4.7 is faster (44 min vs. 93 min), succeeds more often (100% vs. 60%), and costs more per trial ($28.36 vs. $17.18). Naively, Opus dominates. But once we normalize cost by success rate the expected cost of producing one working implementation, the picture inverts. For Sonnet, the expected cost per success is $17.18/0.60 ≈ $28.63, essentially identical to Opus’s per-trial cost. Wall-clock to one expected success is 93/0.60 ≈ 155 min for Sonnet against 44 min for Opus (a 3.5× Opus advantage on latency, but parity on cost).

R EFERENCES [1] OpenAirInterface Software Alliance, “OpenAirInterface 5G source code repository,” 2026, accessed: May 2026. [Online]. Available: https://gitlab.eurecom.fr/oai/openairinterface5g [2] J. Sachs, G. Wikstrom, T. Dudda, R. Baldemair, and K. Kittichokechai, “5G radio network design for ultra-reliable low-latency communication,” IEEE Netw., vol. 32, no. 2, pp. 24–31, Apr. 2018. [3] C. Madapatha, B. Makki, C. Fang, O. Teyeb, E. Dahlman, M.-S. Alouini, and T. Svensson, “On integrated access and backhaul networks: Current status and potentials,” IEEE Open J. Commun. Soc., vol. 1, pp. 1374– 1389, Sep. 2020.

17

[4] A. Maghsoudnia, E. Vlad, A. Gong, D. M. Dumitriu, and H. Hassanieh, “Ultra-reliable low-latency in 5G: A close reality or a distant goal?” in Proc. 23rd ACM Workshop Hot Topics Netw., Irvine, CA, USA, Nov. 2024, p. 111–120. [5] M. Polese, L. Bonati, S. D’oro, S. Basagni, and T. Melodia, “Understanding O-RAN: Architecture, interfaces, algorithms, security, and research challenges,” IEEE Commun. Surveys Tuts., vol. 25, no. 2, pp. 1376–1411, 2nd Quart. 2023. [6] AI-RAN Alliance, “AI-RAN alliance,” 2026, accessed: May 2026. [Online]. Available: https://ai-ran.org/ [7] Q. Wu, G. Bansal, J. Zhang, Y. Wu, B. Li, E. Zhu, L. Jiang, X. Zhang, S. Zhang, J. Liu, A. H. Awadallah, R. W. White, D. Burger, and C. Wang, “AutoGen: Enabling next-gen LLM applications via multi-agent conversations,” in Proc. First Conf. Lang. Model. (COLM), Aug. 2024, p. 1–43. [Online]. Available: https://openreview.net/forum?id=BAakY1hNKS [8] S. Hong, M. Zhuge, J. Chen, X. Zheng, Y. Cheng, C. Zhang, J. Wang, Z. Wang, S. K. S. Yau, Z. Lin, L. Zhou, C. Ran, L. Xiao, C. Wu, and J. Schmidhuber, “MetaGPT: Meta programming for a multi-agent collaborative framework,” in Proc. 12th Int. Conf. Learn. Represent. (ICLR), Apr. 2023. [Online]. Available: https://openreview.net/forum?id=VtmBAGCN7o [9] CrewAI Inc., “CrewAI: Framework for orchestrating role-playing autonomous AI agents,” 2026. [Online]. Available: https://github.com/ crewAIInc/crewAI [10] Anthropic, “Claude code: Agents and sub-agents,” 2026, accessed: 202605-20. [Online]. Available: https://code.claude.com/docs/en/sub-agents [11] C. E. Jimenez, J. Yang, A. Wettig, S. Yao, K. Pei, O. Press, and K. Narasimhan, “SWE-bench: Can language models resolve real-world GitHub issues?” Nov. 2024. [Online]. Available: https: //arxiv.org/abs/2310.06770 [12] H. Yu, B. Shen, D. Ran, J. Zhang, Q. Zhang, Y. Ma, G. Liang, Y. Li, Q. Wang, and T. Xie, “CoderEval: A benchmark of pragmatic code generation with generative pre-trained models,” in Proc. IEEE/ACM 46th Int. Conf. Softw. Eng., Lisbon, Portugal, Apr. 2024, pp. 428–439. [13] S. Daniotti, J. Wachs, X. Feng, and F. Neffke, “Who is using AI to code? Global diffusion and impact of generative AI,” Science, vol. 391, no. 6787, pp. 831–835, Jan. 2026. [14] L. Bonati, P. Johari, M. Polese, S. D’Oro, S. Mohanti, M. TehraniMoayyed, D. Villa, S. Shrivastava, C. Tassie, K. Yoder, A. Bagga, P. Patel, V. Petkov, M. Seltser, F. Restuccia, A. Gosain, K. R. Chowdhury, S. Basagni, and T. Melodia, “Colosseum: Large-scale wireless experimentation through hardware-in-the-loop network emulation,” in Proc. IEEE Int. Symp. Dyn. Spectr. Access Netw. (DySPAN), Dec. 2021, pp. 105–113. [15] D. Villa, I. Khan, F. Kaltenberger, N. Hedberg, R. S. da Silva, S. Maxenti, L. Bonati, A. Kelkar, C. Dick, E. Baena, J. M. Jornet, T. Melodia, M. Polese, and D. Koutsonikolas, “X5G: An open, programmable, multivendor, end-to-end, private 5G O-RAN testbed with NVIDIA ARC and OpenAirInterface,” IEEE Trans. Mobile Comput., vol. 24, no. 11, pp. 11 305–11 322, Nov. 2025. [16] L. Bertizzolo, L. Bonati, E. Demirors, A. Al-Shawabka, S. D’Oro, F. Restuccia, and T. Melodia, “Arena: A 64-antenna SDR-based ceiling grid testing platform for sub-6 GHz 5G-and-beyond radio spectrum research,” Comput. Netw., vol. 181, pp. 1–17, Nov. 2020. [17] 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 Trans. Mobile Comput., pp. 1–18, Jan. 2026, early access. [18] “5G; Management and orchestration; 5G performance measurements, version 17.7.1,” 3rd Gener. Partnership Project (3GPP), TS 28.552, Jul. 2022. [Online]. Available: http://www.3gpp.org/DynaReport/28552.htm [19] M. Elkael, M. Polese, R. Prasad, S. Maxenti, and T. Melodia, “ALLSTaR: Automated LLM-driven scheduler generation and testing for intent-based RAN,” Oct. 2025. [Online]. Available: http://arxiv.org/abs/2505.18389 [20] G. Wang, Y. Xie, Y. Jiang, A. Mandlekar, C. Xiao, Y. Zhu, L. Fan, and A. Anandkumar, “Voyager: An open-ended embodied agent with large language models,” Oct. 2023. [Online]. Available: https://arxiv.org/abs/2305.16291 [21] P. Hamadanian, P. Karimi, A. Nasr-Esfahany, K. Noorbakhsh, J. Chandler, A. ParandehGheibi, M. Alizadeh, and H. Balakrishnan, “Glia: A human-inspired AI for automated systems design and optimization,” Oct. 2025. [Online]. Available: https://arxiv.org/abs/2510.27176 [22] H. Navidan, M. Cheraghinia, J. Fontaine, M. Seif, E. D. Poorter, H. V. Poor, I. Moerman, and A. Shahid, “Toward autonomous O-RAN: A multi-scale agentic AI framework for real-time network

control and management,” Feb. 2026. [Online]. Available: https: //arxiv.org/abs/2602.14117 [23] G. Jiang, K. Wang, X. Chen, and Y. Huang, “Agentic AI empowered intent-based networking for 6G,” Jan. 2026. [Online]. Available: https://arxiv.org/abs/2601.06640 [24] M. A. Ferrag, A. Lakas, and M. Debbah, “6G needs agents: Toward agentic AI-native networks for autonomous intelligence,” May 2026. [Online]. Available: https://arxiv.org/abs/2605.01546 [25] K. Dev, S. A. Khowaja, E. Zeydan, K. Singh, and M. Debbah, “Advanced architectures integrated with agentic AI for next-generation wireless networks,” IEEE Commun. Standards Mag., pp. 1–8, Nov. 2025, early access. [26] P. Gajjar and V. K. Shah, “Agents should replace narrow predictive AI as the orchestrator in 6G AI-RAN,” May 2026. [Online]. Available: https://arxiv.org/abs/2605.11516 [27] H. Li, M. Xiao, K. Wang, R. Schober, D. I. Kim, and Y. L. Guan, “ComAgent: Multi-LLM based agentic AI empowered intelligent wireless networks,” Jan. 2026. [Online]. Available: https: //arxiv.org/abs/2601.19607 [28] F. A. Aoudia, J. Hoydis, S. Cammerer, L. Maggi, G. Marti, and A. Keller, “The AI telco engineer: Toward autonomous discovery of wireless communications algorithms,” Apr. 2026. [Online]. Available: https://arxiv.org/abs/2604.19803 [29] R. D. Zota, C. Bărbulescu, and R. Constantinescu, “A practical approach to defining a framework for developing an agentic AIOps system,” Electronics, vol. 14, no. 9, Apr. 2025. [Online]. Available: https://www.mdpi.com/2079-9292/14/9/1775 [30] S. R. Hussain, M. Echeverria, I. Karim, O. Chowdhury, and E. Bertino, “5GReasoner: A property-directed security and privacy analysis framework for 5G cellular network protocol,” in Proc. ACM SIGSAC Conf. Comput. Commun. Security, Nov. 2019, pp. 669–684. [31] 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,” IEEE Commun. Mag., pp. 1–7, May 2026, early access. [32] C. Qian, W. Liu, H. Liu, N. Chen, Y. Dang, J. Li, C. Yang, W. Chen, Y. Su, X. Cong, J. Xu, D. Li, Z. Liu, and M. Sun, “ChatDev: Communicative agents for software development,” in Proc. 62nd Annu. Meeting Assoc. Comput. Linguistics (Long Papers), Jun. 2024, pp. 15 174–15 186. [33] LangChain Inc., “LangGraph: Building stateful, multi-agent applications with LLMs,” 2026, accessed: 2026-04-26. [Online]. Available: https://github.com/langchain-ai/langgraph [34] OpenAI, “OpenAI agents SDK,” 2026, accessed: 2026-05-20. [Online]. Available: https://github.com/openai/openai-agents-python [35] C. Zhou, H. Chai, W. Chen, Z. Guo, R. Shan, Y. Song, T. Xu, Y. Yang, A. Yu, W. Zhang, C. Zheng, J. Zhu, Z. Zheng, Z. Zhang, X. Lou, C. Zhang, Z. Fu, J. Wang, W. Liu, J. Lin, and W. Zhang, “Externalization in LLM agents: A unified review of memory, skills, protocols and harness engineering,” Apr. 2026. [Online]. Available: https://arxiv.org/abs/2604.08224 [36] F. Jiang, C. Pan, K. Wang, P. Michiardi, O. A. Dobre, and M. Debbah, “From large AI models to agentic AI: A tutorial on future intelligent communications,” IEEE J. Sel. Areas Commun., vol. 44, pp. 3507–3540, Feb. 2026. [37] J. Hoydis, S. Cammerer, F. A. Aoudia, A. Vem, N. Binder, G. Marcus, and A. Keller, “Sionna: An open-source library for next-generation physical layer research,” Mar. 2023. [Online]. Available: https://arxiv.org/abs/2203.11854 [38] J. Yang, C. E. Jimenez, A. Wettig, K. Lieret, S. Yao, K. Narasimhan, and O. Press, “SWE-agent: Agent-computer interfaces enable automated software engineering,” Proc. Adv. Neural Inf. Process. Syst. (NeurIPS), vol. 37, pp. 50 528–50 652, Dec. 2024. [39] T. X. Olausson, J. P. Inala, C. Wang, J. Gao, and A. Solar-Lezama, “Is self-repair a silver bullet for code generation?” in Proc. 12th Int. Conf. Learn. Represent. (ICLR), Jan. 2024. [40] A. Ganiyu, P. Gajjar, and V. K. Shah, “DEMO: AI5GTest: LLM based automation for 5G O-RAN testing,” in Proc. 18th ACM Conf. Secur. Privacy Wireless Mobile Netw. (WiSec), Jun. 2025, p. 298–299. [41] R. Nikbakht, M. Benzaghta, and G. Geraci, “TSpec-LLM: An opensource dataset for LLM understanding of 3GPP specifications,” in Proc. IEEE Globecom Workshops (GC Wkshps), Dec. 2024, pp. 1–6. [42] P. Sharma and V. Yegneswaran, “PROSPER: Extracting protocol specifications using large language models,” in Proc. 22nd ACM Wkshps. Hot Topics Netw. (HotNets), Nov. 2023, pp. 41–47. [43] P. Gajjar and V. K. Shah, “ORANSight-2.0: Foundational LLMs for ORAN,” IEEE Trans. Machine Learn. Commun. Netw., vol. 3, pp. 903–920, Jul. 2025.

18

[44] P. Gajjar, E. Ojo, and V. K. Shah, “TeleResilienceBench: Quantifying resilience for LLM reasoning in telecommunications,” May 2026. [Online]. Available: https://arxiv.org/html/2605.09929v1 [45] F. Rezazadeh, R. Zhao, J. Dai, A. A. Gargari, H. Chergui, and L. Liu, “An experimental reservoir-augmented foundation model: 6G O-RAN case study,” in Proc. 2nd Int. Gener. AI Comput. Lang. Model. Conf. (GACLM), Aug. 2025, pp. 338–342. [46] T. O’Shea and J. Hoydis, “An introduction to deep learning for the physical layer,” IEEE Trans. Cognit. Commun. Netw., vol. 3, no. 4, pp. 563–575, Dec. 2017. [47] S. Hernan, S. Lambert, T. Ostwald, and A. Shostack, “Threat modeling: Uncover security design flaws using the STRIDE approach,” MSDN Mag., Nov. 2006, Microsoft Corporation. [Online]. Available: https://learn.microsoft.com/en-us/archive/msdn-magazine/2006/ november/uncover-security-design-flaws-using-the-stride-approach [48] S. Russell and P. Norvig, Artificial Intelligence: A Modern Approach, 4th ed. Hoboken, NJ: Pearson, 2020. [49] S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, and Y. Cao, “ReAct: Synergizing reasoning and acting in language models,” in Proc. 11th Int. Conf. Learn. Represent. (ICLR), Mar. 2023. [50] Anthropic, “Hooks reference - claude code documentation,” 2026, accessed: May 2026. [Online]. Available: https://docs.claude.com/en/ docs/claude-code/hooks [51] F. Kaltenberger, G. De Souza, R. Knopp, and H. Wang, “The OpenAirInterface 5G New Radio Implementation: Current Status and Roadmap,” in ITG WS, 2019. [52] I. Gomez-Miguelez, A. Garcia-Saavedra, P. D. Sutton, P. Serrano, C. Cano, and D. J. Leith, “srsLTE: An open-source platform for LTE evolution and experimentation,” in Proc. ACM Int. Wkshps. Wireless Netw. Testbeds, Exper. Eval. Charac. (WiNTECH), Oct. 2016, pp. 25–32. [53] Linux Foundation, “Blog: Introducing the Initial OCUDU Technical Project Release, 26.04,” 2026, accessed: May 2026. [Online]. Available: https://ocudu.org/news/ blog-introducing-the-initial-ocudu-technical-project-release-26-04/ [54] O-RAN Software Community, “Near-Realtime RAN Intelligent

Controller (RIC),” 2024, Linux Foundation Project. [Online]. Available: https://wiki.o-ran-sc.org/display/RICP [55] R. Schmidt, M. Irazabal, and N. Nikaein, “FlexRIC: An SDK for nextgeneration SD-RANs,” in Proc. 17th Int. Conf. Emerging Netw. Exper. Technol., Dec. 2021, p. 411–425. [56] A. Lacava, L. Bonati, N. Mohamadi, R. Gangula, F. Kaltenberger, P. Johari, S. D’Oro, F. Cuomo, M. Polese, and T. Melodia, “dApps: Enabling real-time AI-based open RAN control,” Comput. Netw., vol. 269, p. 111342, Sep. 2025. [57] NVIDIA Corporation, “NVIDIA Aerial CUDA-accelerated RAN documentation,” 2026, accessed: 2026-05-20. [Online]. Available: https://docs.nvidia.com/aerial/cuda-accelerated-ran/latest/index.html [58] N. Nikaein, M. K. Marina, S. Manickam, A. Dawson, R. Knopp, and C. Bonnet, “OpenAirInterface: A flexible platform for 5G research,” SIGCOMM Comput. Commun. Rev., vol. 44, no. 5, p. 33–38, Oct. 2014. [59] A. Feraudo, S. Maxenti, A. Lacava, L. Bonati, P. Bellavista, M. Polese, and T. Melodia, “xDevSM: An open-source framework for portable, AI-ready xApps across heterogeneous O-RAN deployments,” Feb. 2026. [Online]. Available: https://arxiv.org/abs/2602.03821 [60] O-RAN Alliance, “O-RAN working group 3, Near-RT RIC and E2 interface, E2 service model (E2SM), KPM, version 07.00,” O-RAN Alliance, Tech. Spec. O-RAN.WG3.TS.E2SM-KPM-R004-v07.00, 2026. [61] “5G; NR; Radio Resource Control (RRC); Protocol specification, version 16.1.0,” 3rd Gener. Partnership Project (3GPP), TS 38.331, Jul. 2020. [Online]. Available: http://www.3gpp.org/DynaReport/38331.htm [62] “5G; NR; NR and NG-RAN overall description; Stage-2, version 16.4.0,” 3rd Gener. Partnership Project (3GPP), TS 38.300, Jan. 2021. [Online]. Available: http://www.3gpp.org/DynaReport/38300.htm [63] “5G; NG-RAN; F1 Application Protocol (F1AP), version 17.6.0,” 3rd Gener. Partnership Project (3GPP), TS 38.473, Oct. 2023. [Online]. Available: http://www.3gpp.org/DynaReport/38473.htm [64] O-RAN Alliance, “O-RAN working group 3, Near-RT RIC and E2 interface, E2 service model (E2SM), RAN control, version 03.00,” ORAN Alliance, Tech. Spec. O-RAN.WG3.E2SM-RC-R003-v03.00, 2023. [65] Anthropic, “API pricing,” Open standard, online documentation, 2026, accessed: May 2026. [Online]. Available: https://claude.com/pricing#api