1 Introduction↩︎

Fifth-generation New Radio (5G NR) and emerging sixth-generation (6G) networks are evolving toward increasingly autonomous and AI-native architectures. The Open RAN (O-RAN) architecture has made this evolution explicit by separating control logic across two distinct timescales: non-real-time applications (rApps) hosted on the Non-RT RIC that reason over policies and objectives over seconds to minutes, and near-real-time applications (xApps) hosted on the Near-RT RIC that act on the radio over tens to hundreds of milliseconds [1]. This separation is attractive because it places slow, deliberative reasoning and fast, deterministic actuation in distinct functional roles.

Vehicle-to-everything (V2X) communications is one of the most demanding environments in next generation networks. A single cell must simultaneously serve several use cases, such as teleoperated driving (ToD) with strict low-latency requirements, cooperative awareness messages, HD map distribution, and sensor sharing, each with highly different reliability, latency, and throughput needs [2], [3]. Configuring a scheduler to satisfy the strict latency needs of critical services while preserving background services’ throughput is a well researched problem and has seen several works applying AI methods, most notably Reinforcement Learning, in order to optimize and balance this tradeoff.

Large language models (LLMs) have recently attracted attention for network management and orchestration, because they can interpret natural-language objectives, reason over heterogeneous service descriptions, and create structured configurations [4], [5]. However, they are not suitable for direct integration into the near-real-time scheduling loop. Their inference latency is high and variable, and most importantly, their outputs are non-deterministic. They cannot offer guarantees of validity, safety, or bounded behavior. Using an LLM as the packet scheduler would couple the most safety-critical control loop in the RAN to the least predictable component in the architecture.

The key idea of this paper is therefore not to use the LLM as the scheduler. Instead, the LLM operates at the non-real-time policy layer, in a manner inspired by an rApp of the O-RAN architecture. It interprets a V2X service objective together with a periodic telemetry summary and produces a structured, actionable policy. A faster, deterministic xApp-like controller then executes this policy by adapting scheduler weights within predefined bounds, every 100 ms, while the LLM is consulted only on a slow timescale (every 10 s). All evaluation is performed in a simulation environment built on ns-3, 5G-LENA, SUMO, and ns3-ai. Because this setup is not a real deployed O-RAN rApp or xApp, we describe the components as rApp-inspired and xApp-like throughout this paper.

The central argument is that this division of labour is a more realistic and deployable use of LLMs in 5G/6G networks than direct online scheduling. LLMs are well suited to reason over service objectives, priorities, and policy trade-offs, while deterministic controllers are better suited to fast, repeated scheduling decisions with hard timing and safety requirements. The question we study is not whether an LLM can beat a hand-tuned controller on every metric, but whether a small, locally deployable LLM can generate valid, safe, executable, and competitive scheduling policies, and whether its integration is competitive to deployed and highly researched baselines.

Contributions↩︎

This paper makes the following contributions.

1. We propose Agentic-V2X, a simulation-based framework for small-LLM-assisted scheduler configuration in 5G NR V2X networks, in which a small local LLM acts as an rApp-inspired policy agent.

2. We design a structured, rApp-inspired YAML policy interface together with validation, repair, and fallback mechanisms that prevent malformed or unsafe LLM outputs from directly affecting the scheduler.

3. We implement a deterministic xApp-like executor that translates validated service-level policies into per-UE uplink/downlink scheduler weights through ns3-ai, operating at a 100 ms control period while the LLM is updated and generates the new (or keeps the existing) policy only every 10 s.

4. We evaluate the framework across multiple V2X densities and seeds against proportional fair (PF), expert static baselines, a heuristic xApp, and static LLM-generated policies, analysing deadline-constrained PRR, reliability, deadline violations, background throughput, fairness, and policy validity/safety as an explicit trade-off rather than a single-winner comparison.

We do not claim that the LLM universally outperforms deterministic baselines, as supported by the results, or that the system constitutes a certified or deployed O-RAN component. The contribution is the specific V2X-focused architecture and its reproducible evaluation.

2 Related Work↩︎

2.1 V2X Scheduling and Radio Resource Management↩︎

Radio resource management for V2X has been studied extensively under both cellular (Uu) and sidelink (PC5) interfaces, with a recurring emphasis on meeting latency and reliability requirements for safety-critical traffic while sharing resources with best-effort flows [2], [3]. Classical schedulers such as proportional fair (PF) operate by balancing throughput and fairness but are not deadline-aware, and QoS-aware extensions typically introduce per-flow weighting, priority queues, or delay-sensitive metrics [2]. In the 5G NR setting, the introduction of flexible numerologies and configurable schedulers has increased the configuration space and motivated automated or policy-driven weight selection [3]. Our work sits at this configuration layer: rather than proposing a new scheduling discipline or algorithm, we study how service-level priorities (or policies) can be turned into per-UE UL/DL weights for an otherwise standard PF-based scheduler with weight adaptation capabilities.

2.2 AI/RL for V2X Resource Allocation↩︎

Machine learning, and reinforcement learning (RL) in particular, has been applied to V2X resource allocation, power control, and mode selection, often demonstrating gains over static heuristics in simulation [6]–[8]. These approaches, however, generally require substantial training, careful reward shaping, and retraining when the service mix or environment changes, and they can be difficult to constrain for safety [7], [8]. The framework proposed here is complementary: the deterministic xApp-like controller occupies the fast control loop where learned online control is most risky, while the slow, language-model policy layer supplies objectives and bounds without requiring task-specific online training.

2.3 LLMs and Agentic Methods for RAN/O-RAN Management↩︎

A growing body of work explores the integration of LLMs in telecom and RAN management, from standards question answering and retrieval-augmented generation over specifications [4], [9], intent translation for intent-based networking [5], [10], configuration generation, troubleshooting, to broader O-RAN orchestration [11]. Several efforts frame the LLM as an agent that plans, calls tools, or coordinates network functions [12], [13]. Most of this literature targets management-plane reasoning and human-facing automation rather than the scheduling control loop. Where LLMs have been considered closer to control, the high and variable inference latency and the lack of output guarantees are widely recognised obstacles [4], [12]. We adopt the same diagnosis and respond architecturally: the LLM is confined to slow policy generation, and a separate deterministic component performs all fast actuation.

2.4 rApps, xApps, and Hierarchical Control↩︎

The O-RAN architecture formalises a separation between non-real-time control on the Non-RT RIC (rApps, operating over seconds to minutes) and near-real-time control on the Near-RT RIC (xApps, operating over tens to hundreds of milliseconds), connected through the A1 and E2 interfaces [1]. This hierarchical structure is a natural fit for combining deliberative reasoning with fast actuation. Our design integrates this structure conceptually: the LLM plays an rApp-inspired role as a slow policy creator, and the deterministic controller plays an xApp-like role as a fast policy executor. We emphasize that our implementation is simulation-based and does not implement A1/E2 interfaces, a real Non-RT or Near-RT RIC, or a conformant rApp/xApp; the terminology is used to describe the timescale separation, not a deployment.

2.5 Positioning of This Work↩︎

This paper evaluates whether a small, locally deployable LLM can act as an rApp-inspired policy creator whose structured outputs are validated, repaired if necessary, and enforced by a deterministic xApp-like controller. Table 1 contrasts this direction with adjacent lines of work.

3 System Model and Problem Formulation↩︎

3.1 5G NR V2X Scenario↩︎

We evaluate our architecture using a single 5G NR cell served by one, centrally placed gNB, with vehicular mobility generated by SUMO [14] on a Manhattan-style grid, as shown in Figure 2. The radio layer is simulated using ns-3 with the 5G-LENA module [15], [16], and the external control processes are connected to the simulator through ns3-ai [17]. Three vehicle densities are studied: 20, 25, and 30 vehicles, and each density experiment is repeated over seven random seeds. The offered load per vehicle is fixed and compliant to the V2X 5GAA application definitions, so increasing vehicle density increases aggregate offered load and channel contention because more vehicles generate traffic according to the same fixed service models.

3.2 V2X Service Classes and Deadlines↩︎

Four V2X services are evaluated, with two critical and two background classes. Teleoperated driving (ToD) is a critical, strict low-latency service whose uplink carries a high-rate video/telemetry stream and whose downlink carries low-rate control. Cooperative awareness (referred to as Awareness/AIC) is a critical, low-rate, bidirectional service. HD map distribution (HDMap/HDM) is a background service dominated by a high-rate downlink. Sensor sharing (RTSA) is a background, moderate-rate bidirectional service. Table 2 lists the per-service traffic rates, criticality, direction, and the deadline used to classify a packet as on-time. The deadline values are scenario design parameters used to compute deadline-constrained reception and are not experimental outcomes.

The per-density service mixes (number of flows of each type) are summarised in Table 6 and increase with density, so that higher densities stress both the critical and background classes more heavily.

3.3 Scheduler-Weight Configuration↩︎

The scheduler is PF-based with configurable per-service weights, which are mapped to per-UE UL/DL scheduler weights inside ns-3. The control problem is hierarchical and operates at two timescales. A slow rApp-inspired policy agent produces a policy \(\pi_{\mathrm{rApp}}\) containing baseline weights, allowed weight ranges, service priorities, and safety constraints. A fast xApp-like executor produces \(\pi_{\mathrm{xApp}}\), the sequence of concrete weight settings applied over time, by adapting weights within the validated bounds in response to observed telemetry. The scheduler then applies the resulting weights to dynamically handle resource allocation. Crucially, the LLM output is not a direct scheduler action, and the xApp action is always bounded by the validated policy constraints.

3.4 Objective↩︎

The design goal is to maximise critical-service reliability (ToD and Awareness deadline-constrained reception) and minimize deadline violations, while preserving background (HDMap/Sensor) throughput, avoiding resource starvation of any service, and avoid ever applying an unsafe or invalid policy. These goals are partly conflicting: prioritising the high-rate critical flows consumes resources that would otherwise serve background traffic. We do not combine them into a single scalar objective, instead each goal corresponds to one or more of the metrics reported in Section 5.5 (critical DC-PRR, deadline-violation rate, background throughput, fairness as a starvation indicator, and safety interventions), on which the methods are compared individually, so that the resulting trade-offs are visible rather than collapsed into a single metric.

4 Agentic-V2X Framework↩︎

4.1 Framework Overview↩︎

Agentic-V2X separates slow policy reasoning from fast policy execution, as shown in Fig. 1. The pipeline is: operator objective and scenario summary \(\rightarrow\) small local LLM (rApp-inspired agent) \(\rightarrow\) structured YAML policy \(\rightarrow\) validator (with repair and fallback) \(\rightarrow\) deterministic xApp-like controller \(\rightarrow\) ns3-ai \(\rightarrow\) ns-3/5G-LENA scheduler \(\rightarrow\) telemetry, optionally fed back to the next policy update. The LLM-based agent receives an operator objective and a compact scenario summary and produces a policy specifying baseline service weights, allowed ranges, adaptation hints, and safety constraints. This policy is validated before being handed to the controller. The controller uses no natural language: it observes telemetry such as latency, deadline-violation rate, throughput degradation, and congestion indicators, and adjusts scheduler weights within the bounds set by the validated policy. If the policy is invalid, unsafe, or missing required fields, the controller falls back to the last known safe policy or to a static expert baseline.

4.2 Small Language Model Policy Agent↩︎

We use the term agent in the sense of an autonomous reasoning component that ingests a telemetry summary and service objective and emits an actionable, structured policy within a closed perceive–decide–act loop, rather than in the stronger sense of a tool-calling or multi-step planning agent. Richer forms of agency, such as tool invocation or iterative planning, are natural extensions that we do not pursue here, in part because the ns-3/5G-LENA control environment does not expose a tool-calling interface to the policy layer, so we leave them to future work. We use qwen2.5:7b as a representative small local model. It is not claimed to be optimal, but rather, it was selected as a practical trade-off between local deployability and reliable generation of structured YAML policies. In preliminary tests, very small models such as qwen2.5:0.5b produced unreliable or poorly structured outputs. In addition, the output latency of larger models, such as a 14-billion-parameter model, would be prohibitive for deployment. The agent is queried on a slow, non-real-time interval, specifically once before the run for the static configuration, and afterwards, every 10 s for the adaptive configuration, so that LLM inference is never inside the scheduling loop. Its input includes the V2X service descriptions and deadlines, the current scenario telemetry summary (density and recent performance), and the operator objective. After inference, the xApp receives its output as a machine-checkable policy.

4.3 Structured YAML Policy Schema↩︎

The agent emits a structured YAML policy whose fields are summarised in Table 3. The schema constrains the LLM to a bounded, validatable action space: baseline weights and explicit per-service min/max bounds, safety constraints (such as a minimum weight for critical services and a maximum tolerated degradation of background throughput), optional adaptation rules expressed as guarded hints for the controller, an update period, and a named fallback policy.

4.4 Policy Validation, Repair, Fallback, and Runtime Shielding↩︎

Because LLM outputs are non-deterministic, no generated policy can be trusted directly. Each policy is first parsed against the YAML schema and checked for structural completeness, admissible service and metric names, valid action types, weight and bound ranges, consistency between baseline weights and bounds, and satisfaction of safety constraints such as minimum critical-service weight and non-zero background weights. Recoverable problems, such as clampable out-of-range values or missing optional fields, are repaired deterministically and logged. Unrecoverable schema violations or unsafe policies are rejected before they can affect the scheduler.

In addition to structural validation, the adaptive LLM-rApp/xApp path includes a runtime performance-aware shield. When a new validated LLM policy is accepted, the xApp stores the previous validated policy and records the current critical-flow performance as a baseline. During subsequent control windows, the xApp monitors critical violation rate, critical DC-PRR, and critical p95 latency. If critical-service performance degrades for three consecutive windows relative to the baseline, the xApp rolls back to the previous validated policy. If no previous validated policy is available, the controller falls back to the static expert policy. This mechanism protects against policies that are syntactically valid and within bounds but harmful under the current traffic and channel state.

The xApp also applies a directional critical-flow guard. If the gap between critical UL and DL DC-PRR exceeds 0.05, the controller temporarily boosts the scheduler weights of the weaker critical direction until the imbalance improves. This guard is intended to avoid over-protecting one critical direction while allowing the other to degrade, especially under high-density congestion.

Thus, the safety design has two levels. The validator prevents malformed or out-of-bounds YAML policies from reaching the scheduler, while the runtime shield protects against validated but performance-harmful policies. In the worst case, the system degrades to either the last validated safe policy or the static expert fallback.

4.5 Deterministic xApp-Like Execution↩︎

The xApp-like executor is a lightweight deterministic controller that runs every 100 ms. It enforces the validated policy by adjusting scheduler weights within the validated bounds in response to telemetry. For example, it may raise the ToD weight when ToD UL latency exceeds a threshold, restore HDMap weight when critical traffic is stable, and prevent any background service from being driven to zero resources. Hysteresis and rate limiting are applied to avoid oscillatory behaviour, and all actions are clamped to the policy bounds, so the controller cannot exceed the constraints supplied by the policy agent. The two control timescales, LLM policy updates every 10 s versus deterministic weight adaptation every 100 ms, are depicted in Fig. 4.

5 Experimental Methodology↩︎

5.1 ns-3 / 5G NR Setup↩︎

Experiments use ns-3 with the 5G-LENA NR module [15], [16], SUMO mobility on a Manhattan grid [14], and ns3-ai for external control [17]. The scheduler is PF-based with configurable per-UE UL/DL weights. The xApp-like control period is 100 ms; the rApp-inspired LLM update period is 10 s for the adaptive method. Table 4 lists the main simulation parameters.

5.2 Traffic and Service Mix↩︎

The four services of Table 2 are instantiated according to the per-density mixes in Table 6. Per-flow rates are fixed across densities, so aggregate offered load and contention scale with the number of vehicles. The high-rate flows (ToD UL and HDMap DL, each 16 Mbps) dominate the resource demand and create the principal tension between critical reliability and background throughput that the scheduler-configuration policies must manage.

5.3 Baselines↩︎

We compare six scheduler-control methods, summarised in Table 5. The first four are deterministic references while the last two use the LLM policy agent, differing in whether the policy is static or adaptively re-generated and executed.

For readability, the exact implementation identifiers are mapped to reader-friendly method names as follows: static expert (static_expert), balanced expert (balanced_expert), heuristic xApp (heuristic_xapp), static LLM (llm_static), and adaptive LLM-rApp/xApp (llm_rapp_xapp). We use the reader-friendly method names in the remainder of the paper.

5.4 Experiment Matrix↩︎

The campaign is a full factorial of 3 densities \(\times\) 7 seeds \(\times\) 6 methods \(=\) 126 runs, all of which completed successfully and are included in the analysis. Table 6 lists the densities, per-density service mixes, seeds, and methods. The same seven mobility seeds are reused across all six methods within each density, so that comparisons are made on identical vehicle trajectories and traffic instantiations, and every method is evaluated over the same 21 runs (three densities \(\times\) seven seeds).

5.5 Metrics↩︎

We report network-level and control-level metrics. Network metrics: critical deadline-constrained packet reception ratio (critical DC-PRR, combining ToD and Awareness), per-service DC-PRR (ToD downlink/uplink, Awareness downlink/uplink), deadline-violation rate, background (HDMap + Sensor/RTSA) throughput and degradation, 95th-percentile (p95) latency, and the Jain fairness index over per-service throughput. Control/policy metrics: policy validity, repair, and rejection counts, fallback invocations, number of xApp weight-change actions, number of safety interventions, LLM policy-generation latency, and xApp per-step execution overhead. The primary metric is critical DC-PRR; the others characterise the reliability–throughput–fairness trade-off and the practicality of the policy agent.

6 Results↩︎

This section reports results from the complete 126-run experimentation process (3 densities \(\times\) 7 seeds \(\times\) 6 methods). All figures are computed from the per-run telemetry described in Section 5.5; per-method aggregates are means over the seven seeds at each density. Because the same density/seed combinations are reused across all methods, the main comparisons are paired rather than treated as independent samples.

6.1 Policy Validity and Safety↩︎

The LLM policy path remained executable throughout the campaign. For static LLM, one policy is generated before each run. For adaptive LLM-rApp/xApp, the policy layer is queried on the slow 10 s interval, producing 10 policy updates per 100 s run and 210 attempted updates across 21 runs. All adaptive updates were accepted and no update was rejected. The fallback counts in Table 7 correspond to controller-level fallback/heuristic events observed during execution, not malformed YAML policies. This distinction is important: the schema-level policy-generation path remained valid, while the xApp-level safety logic still recorded bounded corrective behaviour.

6.2 Critical-Service Reliability↩︎

Table 8 reports mean critical DC-PRR by method and density. At 20 vehicles, deterministic and static policies remain in a high-reliability region, while adaptive LLM-rApp/xApp is weaker in mean critical DC-PRR. At 25 vehicles, PF and static LLM are stronger than the adaptive method on this aggregate critical metric, although adaptive LLM-rApp/xApp still remains within the same broad performance band. At 30 vehicles, adaptive LLM-rApp/xApp obtains the highest mean critical DC-PRR among the evaluated methods, reaching 65.4%, compared with 59.8% for PF and 63.7% for static LLM. This supports a high-load directional benefit, while the paired tests below show that it should not be overstated as statistically definitive.

Table 9 isolates ToD UL DC-PRR, the highest-rate critical uplink flow. Adaptive LLM-rApp/xApp again performs best at the highest density, reaching 65.3% at 30 vehicles. However, it is weaker at 20 and 25 vehicles, especially compared with PF, static LLM, and the deterministic baselines. The result is therefore not that the adaptive policy dominates ToD UL across all regimes, but rather that it becomes more competitive when the network is most congested.

Awareness UL DC-PRR, shown in Table 10, reveals a different pattern. Adaptive LLM-rApp/xApp is strongest at 25 vehicles among the listed methods for this component, but it is not strongest at 20 or 30 vehicles. This confirms that the adaptive policy does not improve all critical directions uniformly. It can protect selected components effectively, but the high-density aggregate result depends on the balance across ToD and Awareness flows.

6.3 Deadline Violations and Tail Latency↩︎

Deadline-violation trends mirror the critical DC-PRR results because the violation rate is computed as one minus the on-time critical packet reception ratio. Adaptive LLM-rApp/xApp has the lowest violation rate at 30 vehicles, but the highest violation rate at 20 and 25 vehicles among the main static/LLM alternatives. This density-dependent reversal is central to the interpretation of the method: the adaptive architecture is useful in stressed regimes, but unnecessary or insufficiently calibrated at lighter operating points.

Critical p95 maximum latency is high variance under congestion. At 25 vehicles, adaptive LLM-rApp/xApp gives the lowest mean critical p95 maximum latency among all methods, at 1329.3 ms, compared with 2038.4 ms for PF and 3252.2 ms for heuristic xApp. At 30 vehicles, however, it has the worst value, showing that the high-density reliability gain comes with a tail-latency cost. This is why latency claims are reported as operating-point evidence rather than a universal improvement.

6.4 Background-Service Preservation↩︎

Table 13 reports background throughput. Adaptive LLM-rApp/xApp preserves the highest background throughput at 25 vehicles, reaching 14.510 Mbps, but it is weaker at 30 vehicles. This is one of the clearest medium-density strengths of the adaptive method: it improves the throughput side of the reliability–throughput trade-off at 25 vehicles. At 30 vehicles, static expert and heuristic xApp preserve substantially more background throughput, indicating that the adaptive method prioritizes critical traffic more aggressively under high congestion.

6.5 Benefit of xApp-Level Execution↩︎

Comparing static LLM against adaptive LLM-rApp/xApp isolates the contribution of periodic policy refresh and deterministic xApp-level execution. The adaptive method is not uniformly better than the static LLM policy: static LLM is stronger in aggregate critical DC-PRR and background throughput. However, adaptive LLM-rApp/xApp is better in several important operating points, particularly critical DC-PRR and ToD UL DC-PRR at 30 vehicles, background throughput at 25 vehicles, and critical p95 maximum latency at 25 vehicles. These results suggest that xApp-level execution is most useful in specific traffic-density regimes rather than as a universal replacement for well-calibrated static policies.

6.6 Control Overhead and Practicality↩︎

The measured control overhead confirms the intended timescale separation. The LLM operates on the slow policy-generation interval and remains outside the 100 ms xApp loop. The reported LLM latency is wall-clock time, whereas the 10 s policy refresh interval is simulation time; therefore, the LLM generation latency should not be interpreted as a real-time scheduler latency. The deterministic xApp-like controller remains lightweight, with sub-millisecond mean execution overhead in the logged runs.

6.7 Aggregate Comparison↩︎

Table 15 aggregates the headline metrics across all densities and seeds. PF has the highest aggregate critical DC-PRR in this seven-seed campaign, followed by static LLM, static expert, heuristic xApp, balanced expert, and adaptive LLM-rApp/xApp. Therefore, the adaptive method is not the best aggregate critical-reliability method. Its aggregate background throughput is competitive but not the strongest, and its aggregate p95 maximum latency is also not the best. The aggregate view therefore supports the conservative framing of the paper: Agentic-V2X demonstrates a validated and competitive architecture for LLM-assisted policy generation, but it does not establish universal scheduler dominance.

6.8 Paired Statistical Analysis↩︎

To avoid treating repeated simulation runs as independent observations, we performed paired statistical analysis over matched density/seed combinations. For each comparison, paired differences are computed as adaptive LLM-rApp/xApp minus the baseline on the same density and seed. The aggregate paired tests therefore use 21 matched pairs, while density-specific tests use seven matched pairs. Positive differences indicate improvements for DC-PRR and throughput metrics, whereas negative differences indicate improvements for latency metrics. For each comparison, we report the mean paired difference, median paired difference, 95% paired bootstrap confidence interval for the mean difference, two-sided Wilcoxon signed-rank \(p\)-value, and paired win rate.

Table 16 shows that adaptive LLM-rApp/xApp is not the best aggregate method for critical DC-PRR. The mean paired difference is negative against PF, heuristic xApp, static LLM, and static expert, and all bootstrap confidence intervals include zero. The Wilcoxon signed-rank tests are also not significant. Interestingly, the paired win rate against PF is 61.9%, even though the mean difference is negative, which indicates that a small number of large negative cases dominate the aggregate mean. This supports a competitive but not dominant interpretation.

Table 17 extends the aggregate analysis to the main secondary metrics. The adaptive method is not statistically superior in aggregate critical reliability. For latency and background throughput, the signs of the mean paired differences are mixed across baselines, and most confidence intervals include zero. We therefore interpret these metrics as evidence of trade-off behaviour rather than universal dominance.

Table 18 reports the density-specific claim checks. At 30 vehicles, adaptive LLM-rApp/xApp improves mean critical DC-PRR over PF by 5.6 percentage points, with a 71.4% paired win rate, but the Wilcoxon test does not reach significance. At 25 vehicles, adaptive LLM-rApp/xApp reduces critical p95 maximum latency relative to all four selected baselines and improves background throughput most clearly against heuristic xApp, where the paired Wilcoxon result is favourable (\(p=0.047\)). At 20 vehicles, adaptive LLM-rApp/xApp is directionally worse in mean critical DC-PRR, especially against heuristic xApp and static expert. These checks show that the adaptive architecture has density-dependent strengths, but the aggregate claim must remain conservative.

6.9 Summary of Findings↩︎

Three main findings come out of this work. First, the LLM policy path remained executable across the seven-seed campaign, with all adaptive policy updates accepted and no rejected updates. Second, adaptive LLM-rApp/xApp is not the best aggregate reliability method, but it shows useful density-specific strengths: critical DC-PRR and ToD UL DC-PRR at 30 vehicles, background throughput at 25 vehicles, and critical p95 maximum latency at 25 vehicles. Third, paired statistical analysis over matched density/seed pairs confirms that the strongest defensible conclusion is architectural competitiveness rather than universal dominance.

7 Discussion↩︎

7.1 LLM as a Real-Time Scheduler↩︎

The architecture deliberately keeps the LLM out of the scheduling loop. Three properties of LLM inference make it unsuitable for near-real-time scheduling: latency at a multi-second wall-clock scale in this configuration, non-deterministic outputs that complicate reproducibility and verification, and the absence of native guarantees of validity, boundedness, or safety. By confining the LLM to slow policy generation and assigning all fast actuation to a deterministic, bounded controller, the design uses the LLM for reasoning over objectives, priorities, and trade-offs without exposing the radio control loop to its weaknesses. The measured LLM generation latency supports this design choice, and it must be interpreted separately from the 10 s simulation-time policy interval.

7.2 Small LLMs as rApp-Inspired Policy Creators↩︎

The validity results show that qwen2.5:7b, prompted with the constrained weight-policy schema used in this study, produced executable, in-bounds policies across all static and adaptive policy-generation/update attempts. This supports the claim that a small local model can act as an rApp-inspired policy creator for this constrained task. We are careful, however, not to over-generalise this finding: a high validity rate on a deliberately constrained schema does not imply that arbitrary LLM outputs are safe. The validation, repair, fallback, and xApp-level bounding layers remain essential to the architecture.

7.3 Trade-off Interpretation↩︎

The results show a more nuanced picture than a simple ranking. Adaptive LLM-rApp/xApp is strongest in selected operating points, especially at 30 vehicles for critical reliability and ToD UL reliability, and at 25 vehicles for background throughput and critical p95 maximum latency. In aggregate, however, it remains below the strongest methods on critical DC-PRR. We therefore interpret the adaptive method as a competitive policy-generation architecture with useful density-specific strengths, not as a universally best scheduler.

Two factors plausibly explain the mixed outcome. First, the 10 s policy-refresh period is coarse relative to how quickly contention builds and dissipates as vehicles move through the Manhattan grid. Second, the xApp adaptation rules are deliberately conservative to avoid oscillation and safety violations, which may limit their ability to correct a suboptimal policy quickly in the highest-density case. Faster refresh, richer telemetry summaries, or more targeted critical-flow balancing may widen the benefit.

7.4 Role of the xApp↩︎

Because the deterministic xApp-like controller is shared in design between heuristic xApp and adaptive LLM-rApp/xApp, their differences reflect the policy bounds and baseline weights supplied by the LLM versus the hand-coded heuristic rule set. The adaptive method is strongest at specific load points rather than uniformly across the full campaign. This suggests that the xApp execution layer is useful, but that the policy-generation layer still requires better calibration for low-load operation and for balancing multiple critical-flow directions under heavy congestion.

7.5 Safety and Validation↩︎

The validation, repair, and fallback layer is what makes delegating policy creation to a stochastic model defensible. Because every policy is checked and bounded before execution, and because the worst case degrades to a known deterministic policy, a malformed or unsafe LLM output cannot directly reach the scheduler. The seven-seed campaign did not produce rejected policy updates, but the controller did record bounded fallback/rollback behaviour during execution, showing the importance of runtime safety checks in addition to schema validation.

7.6 Failure Cases↩︎

The main failure case for adaptive LLM-rApp/xApp appears at low density and in aggregate performance. At 20 vehicles, the adaptive method is directionally worse on critical DC-PRR, suggesting that adaptation may be unnecessary or even harmful when the network is not strongly congested. At 30 vehicles, the adaptive method improves critical reliability and ToD UL reliability, but this comes with poor tail latency and weaker background throughput. These two failure modes show that valid LLM-generated policies are not automatically well calibrated; the schema and validator ensure safety and executability, but performance still depends on the content and timing of the generated policy.

8 Limitations↩︎

This study has several limitations. First, it is entirely simulation-based. Results from ns-3/5G-LENA/SUMO may not transfer directly to hardware. The rApp/xApp terminology is conceptual: we do not implement the A1/E2 interfaces, a real Non-RT or Near-RT RIC, or a conformant rApp/xApp, and the generated policy is a validated structured policy in an rApp-inspired framework, not a certified rApp. The evaluation uses a single 5G NR cell, three densities, and a single fixed traffic regime determined by the service models. We study one representative small local model (qwen2.5:7b). The work is not a model benchmark and does not claim this model is optimal. The control action space is limited to per-service scheduler weights mapped to per-UE UL/DL weights over a PF-based scheduler, and the LLM update cadence (10 s) and control period (100 ms) are fixed. The campaign uses seven seeds per density-method cell, which provides a cleaner paired comparison than a minimal pilot design but is still modest for density-specific hypothesis testing. Aggregate paired tests use 21 matched density/seed pairs, while density-specific tests use only seven matched pairs; therefore small numerical differences and high-variance tail-latency metrics should be interpreted cautiously. Finally, results may depend on the prompt and schema design, while robustness to alternative prompts, schemas, and models is left to future work.

9 Conclusion↩︎

We presented Agentic-V2X, a simulation-based framework in which a small, locally deployable language model acts as an rApp-inspired policy agent that generates structured, validated scheduler-configuration policies for deadline-aware 5G NR V2X traffic, while a deterministic xApp-like controller executes those policies through ns3-ai at a 100 ms cadence. Across the full 126-run campaign (3 densities \(\times\) 7 seeds \(\times\) 6 methods), the small local LLM (qwen2.5:7b) produced executable adaptive policies with all 210 policy updates accepted and no rejected updates. On network performance, adaptive LLM-rApp/xApp was strongest in several important operating points, including critical DC-PRR and ToD UL DC-PRR at 30 vehicles, background throughput at 25 vehicles, and critical p95 maximum latency at 25 vehicles. At the same time, it remained below the strongest methods on aggregate critical reliability. The main lesson is therefore balanced: small LLM agents can safely generate executable V2X scheduler policies and can be competitive in specific density regimes, but they should be treated as policy assistants within a validated hierarchical control architecture rather than as replacements for well-calibrated deterministic control.

10 Future Work↩︎

Future work includes integration with a real O-RAN Non-RT/Near-RT RIC and A1/E2 interfaces, multi-cell scenarios when handover becomes available in 5G-LENA ns3, a richer policy schema and broader model and prompt studies to test whether the observed policy validity holds under harder conditions, faster or telemetry-triggered policy refresh to widen the density-specific gains identified here, and targeted prompt or training interventions to improve low-load stability and high-density critical-flow balance without sacrificing ToD uplink protection.

11 LLM-rApp Policy Generation Artifacts↩︎

This appendix reports the main artifacts used by the rApp-inspired LLM policy generator. It includes the prompt structure, the constrained YAML policy interface accepted by the deterministic xApp-like validator, and one complete policy generated and accepted during the ns-3 campaign. These artifacts are included to make the LLM-to-controller interface auditable and reproducible. In the implementation, the runtime prompt is constructed by concatenating the system prompt and the user prompt after substituting the scenario identifier, telemetry summary, objective identifier, model name, and policy identifier.

11.1 Prompt Structure↩︎

The LLM is not used as a real-time scheduler. Instead, it generates a bounded service-level policy that is validated and then executed by the deterministic xApp-like controller. The system prompt constrains the model to return YAML only, restricts the admissible services, metrics, actions, and scheduler-weight ranges, and specifies the safety requirements that must hold before a policy can be accepted.

11.1.1 System Prompt↩︎

Listing A.1: System prompt used by the rApp-inspired LLM policy generator.

You are a 5G NR V2X rApp policy generator.

Your task is to generate one structured scheduler policy for a deterministic xApp controller.

You are not the online scheduler.
You do not output immediate runtime actions.
You only output a policy that the xApp can validate and execute.

Return only valid YAML.
Do not include explanations.
Do not include Markdown fences.
Do not include comments.
Do not include text before or after the YAML.

# V2X service criticality and latency requirements

ToD (Time-critical Operational Data) and Awareness (AIC) are safety-of-life services.
They must always receive high scheduler priority.

ToD carries operator command downlink and sensor/video uplink.
- The DL direction is the tightest control path.
- Violation of the DL deadline directly impairs safety-critical vehicle control loops.
- ToD must receive the highest baseline weight and must never be starved under congestion.

Awareness (AIC) carries cooperative awareness messages between vehicles.
- Deadline: 100 ms p95 in both UL and DL directions.
- Violation impairs situational awareness and collision avoidance.
- Awareness must be protected under congestion.
- Awareness must not be sacrificed to free bandwidth for HDMap or Sensor.

HDMap carries high-definition map data.
- This is a background throughput service.
- Degradation up to 35- HDMap must not receive zero weight but can be deprioritised under congestion.

Sensor (RTSA) carries real-time sensor data at low rates.
- This is a background service.
- It must not receive zero weight but can be trimmed under congestion.

Under congestion, the correct priority order is:
ToD > Awareness > HDMap approximately Sensor.

# Allowed services

- ToD
- Awareness
- HDMap
- Sensor

# Allowed telemetry metrics

- tod_p95_latency_ms
- tod_dc_prr
- tod_violation_rate
- awareness_p95_latency_ms
- awareness_dc_prr
- awareness_violation_rate
- hdmap_throughput_degradation
- sensor_throughput_degradation
- congestion_ratio

# Allowed actions

- set_weight
- increase_weight
- decrease_weight

Allowed scheduler weights are integers from 1 to 10.

Telemetry values use the following numeric ranges:
- dc_prr metrics are ratios from 0.0 to 1.0.
- violation_rate metrics are ratios from 0.0 to 1.0.
- throughput_degradation metrics are ratios from 0.0 to 1.0, not percentages.
- congestion_ratio is a ratio from 0.0 to 1.0.
- latency metrics are expressed in milliseconds.

The policy must follow this exact YAML schema:

policy_id: string
description: string
scenario_id: string
objective_id: string
baseline_weights:
  ToD: integer
  Awareness: integer
  HDMap: integer
  Sensor: integer
bounds:
  ToD: [integer, integer]
  Awareness: [integer, integer]
  HDMap: [integer, integer]
  Sensor: [integer, integer]
safety_constraints:
  min_critical_weight: integer
  max_background_degradation: float
  forbid_zero_weight: true
  critical_services:
    - ToD
    - Awareness
xapp_rules:
  - name: string
    condition:
      metric: one allowed telemetry metric
      operator: one of ">", ">=", "<", "<="
      value: number
    action:
      service: one allowed service
      type: one allowed action
      value: integer
fallback_policy: static_expert
runtime_safety:
  rollback_enabled: true
  degradation_windows: integer
  monitored_metrics:
    - critical_violation_rate
    - critical_dc_prr
    - critical_p95_latency_ms
  directional_guard_enabled: true
  max_ul_dl_dc_prr_gap: float
metadata:
  source: llm_rapp
  model_name: string
  generation_time: null

# Safety requirements

- ToD and Awareness are critical services. Their baseline weights must be high.
- ToD must have the highest baseline weight.
- ToD and Awareness must not drop below the minimum critical weight.
- HDMap and Sensor must not receive zero weight.
- Baseline weights must be within their bounds.
- Bounds must be within 1 and 10.
- Lower bounds must not exceed upper bounds.
- Do not invent services.
- Do not invent telemetry metrics.
- Do not invent action types.
- Do not use nested conditions.
- Do not use mathematical expressions.
- Do not output Python code.
- If runtime_safety is included, degradation_windows must be 3 and max_ul_dl_dc_prr_gap must be 0.05.

A good policy is conservative, valid, and executable.

11.1.2 User Prompt Template↩︎

The user prompt provides the scenario-specific telemetry and identifiers. The telemetry block is generated by the simulator-side logging pipeline and summarises the recent network state available to the slow policy-generation loop.

Listing A.2: User prompt template used to instantiate a scenario-specific LLM-rApp policy request.

Create one rApp scheduler policy for the scenario and objective below.
The deterministic xApp will execute the policy at runtime using only validated simple rules, bounds, and safety constraints.

{telemetry_summary}

Use these identifiers exactly:
scenario_id: {scenario_id}
objective_id: {objective_id}
model_name: {model_name}

Use this policy_id format:
policy_id: {policy_id}

Return only YAML. Do not use Markdown fences.
Use ratios, not percentages, for DC-PRR, violation-rate, throughput-degradation, and congestion thresholds.

A valid conservative example shape is:

policy_id: {policy_id}
description: Conservative rApp policy for V2X scheduler weights
scenario_id: {scenario_id}
objective_id: {objective_id}
baseline_weights:
  ToD: 7
  Awareness: 6
  HDMap: 3
  Sensor: 2
bounds:
  ToD: [5, 10]
  Awareness: [5, 10]
  HDMap: [1, 8]
  Sensor: [1, 8]
safety_constraints:
  min_critical_weight: 5
  max_background_degradation: 0.35
  forbid_zero_weight: true
  critical_services:
    - ToD
    - Awareness
xapp_rules:
  - name: tod_latency_guard
    condition:
      metric: tod_p95_latency_ms
      operator: ">"
      value: 15
    action:
      service: ToD
      type: increase_weight
      value: 1
  - name: awareness_violation_guard
    condition:
      metric: awareness_violation_rate
      operator: ">"
      value: 0.02
    action:
      service: Awareness
      type: increase_weight
      value: 1
  - name: congestion_sensor_trim
    condition:
      metric: congestion_ratio
      operator: ">"
      value: 0.8
    action:
      service: Sensor
      type: decrease_weight
      value: 1
fallback_policy: static_expert
runtime_safety:
  rollback_enabled: true
  degradation_windows: 3
  monitored_metrics:
    - critical_violation_rate
    - critical_dc_prr
    - critical_p95_latency_ms
  directional_guard_enabled: true
  max_ul_dl_dc_prr_gap: 0.05
metadata:
  source: llm_rapp
  model_name: {model_name}
  generation_time: null

11.2 Validated YAML Policy Interface↩︎

The deterministic validator accepts only the fields and values listed in Listing A.3. Policies that violate the schema are either repaired deterministically, when the error is recoverable, or rejected and replaced by the fallback policy. The runtime-safety block exposes the xApp shield parameters used for rollback and critical UL/DL balancing. This design ensures that the stochastic LLM output is never applied directly to the scheduler.

Listing A.3: Validated YAML policy interface accepted by the xApp-like controller.

Required top-level fields:
  policy_id: string
  description: string
  scenario_id: string
  objective_id: string
  baseline_weights: map[service -> integer]
  bounds: map[service -> [integer, integer]]
  safety_constraints: map
  xapp_rules: list[rule]
  fallback_policy: static_expert
  runtime_safety: map
  metadata: map

Allowed services:
  ToD
  Awareness
  HDMap
  Sensor

Weight domain:
  minimum: 1
  maximum: 10

Default validated bounds:
  ToD: [5, 10]
  Awareness: [5, 10]
  HDMap: [1, 10]
  Sensor: [1, 10]

Default safety constraints:
  min_critical_weight: 5
  max_background_degradation: 0.35
  forbid_zero_weight: true
  critical_services:
    - ToD
    - Awareness

Supported telemetry metrics:
  tod_p95_latency_ms
  tod_dc_prr
  tod_violation_rate
  awareness_p95_latency_ms
  awareness_dc_prr
  awareness_violation_rate
  hdmap_throughput_degradation
  sensor_throughput_degradation
  congestion_ratio

Supported operators:
  >
  >=
  <
  <=

Supported action types:
  set_weight
  increase_weight
  decrease_weight

Supported metadata source values:
  llm_rapp
  manual
  baseline
  repaired

Runtime safety shape:
  rollback_enabled: true
  degradation_windows: 3
  monitored_metrics:
    - critical_violation_rate
    - critical_dc_prr
    - critical_p95_latency_ms
  directional_guard_enabled: true
  max_ul_dl_dc_prr_gap: 0.05

Rule shape:
  name: string
  condition:
    metric: supported telemetry metric
    operator: supported operator
    value: numeric threshold
  action:
    service: supported service
    type: supported action type
    value: integer

11.3 Example Accepted LLM-Generated Policy↩︎

Listing A.4 reports one complete policy generated by qwen2.5:7b, validated by the policy checker, and accepted during the ns-3 campaign. The example corresponds to the first rApp update of the real_100s_llm_rapp_xapp_20veh_seed6 experiment. It illustrates the bounded service-level configuration passed from the slow LLM-rApp layer to the deterministic xApp-like executor.

Listing A.4: Example LLM-generated YAML policy accepted during the ns-3 campaign.

policy_id: qwen2_5_7b_real_100s_20veh_seed6_rapp_policy
description: Conservative rApp policy for V2X scheduler weights
scenario_id: real_100s_20veh_seed6
objective_id: safety_background_balance
baseline_weights:
  ToD: 6
  Awareness: 5
  HDMap: 3
  Sensor: 2
bounds:
  ToD:
    - 4
    - 8
  Awareness:
    - 4
    - 8
  HDMap:
    - 1
    - 7
  Sensor:
    - 1
    - 7
safety_constraints:
  min_critical_weight: 5
  max_background_degradation: 0.35
  forbid_zero_weight: true
  critical_services:
    - ToD
    - Awareness
xapp_rules:
  - name: tod_latency_guard
    condition:
      metric: tod_p95_latency_ms
      operator: ">"
      value: 20
    action:
      service: ToD
      type: increase_weight
      value: 1
  - name: awareness_violation_guard
    condition:
      metric: awareness_violation_rate
      operator: ">"
      value: 0.05
    action:
      service: Awareness
      type: increase_weight
      value: 1
  - name: congestion_hdmap_trim
    condition:
      metric: congestion_ratio
      operator: ">"
      value: 0.7
    action:
      service: HDMap
      type: decrease_weight
      value: 1
  - name: congestion_sensor_trim
    condition:
      metric: congestion_ratio
      operator: ">"
      value: 0.8
    action:
      service: Sensor
      type: decrease_weight
      value: 1
fallback_policy: static_expert
runtime_safety:
  rollback_enabled: true
  degradation_windows: 3
  monitored_metrics:
    - critical_violation_rate
    - critical_dc_prr
    - critical_p95_latency_ms
  directional_guard_enabled: true
  max_ul_dl_dc_prr_gap: 0.05
metadata:
  source: llm_rapp
  model_name: qwen2.5:7b
  generation_time: null

References↩︎