arXiv CSopen access

Agentic-V2X: Small Language Model Agents for Deadline-Aware V2X Scheduling in 5G/6G Networks

Agentic-V2X: Small Language Model Agents for Deadline-Aware V2X Scheduling in 5G/6G Networks Gerasimos Papanikolaou-Ntais∗ , Alexandros Kaloxylos† , and Athanasios Kanavos† ∗ Department of Informatics, University of Piraeus, 185 34 Piraeus, Greece

[email protected] † Department of Informatics and Telecommunications, University of Peloponnese, 221 31 Tripoli, Greece

arXiv:2607.04290v1 [cs.NI] 5 Jul 2026

{kaloxyl, kanavosa}@uop.gr

Abstract—Large Language Models (LLMs) are increasingly proposed as control interfaces for next-generation networks. However, their latency, occasional hallucinations, and lack of control guarantees make them unsuitable for direct near-realtime packet schedulers. The problem is intensified in the highly dynamic environment of V2X communications. This paper studies a more practical architecture in which a small, locally deployed language model acts as a periodic non-real-time rAppinspired policy creator, while a lightweight xApp-like controller executes validated policies at much faster intervals suitable for scheduling. The proposed framework targets deadline-aware 5G NR V2X scheduling with heterogeneous services, including teleoperated driving, cooperative awareness, HD map sharing, and sensor sharing. Given a scenario summary, service objective, and telemetry metrics, the LLM generates a structured scheduler policy containing service priorities, weight bounds, and safety constraints. A validator checks and repairs the policy before the xApp-like controller enforces it through scheduler-weight adaptation in ns-3/ns3-ai. The evaluation compares proportional fair scheduling, static expert policies, a heuristic xApp, static LLM-generated policies, and LLM-rApp policies with xApplevel enforcement over 126 completed runs. Metrics include deadline-constrained packet reception ratio, tail latency, deadline violations, throughput, fairness, policy validity, and safety interventions. Results show that the adaptive LLM-rApp/xApp design generates valid and executable policies throughout the campaign and remains competitive in several operating points, including improved mean critical reliability over PF at the highest density and favourable medium-density latency/throughput trade-offs. However, paired statistical analysis shows that the adaptive method is not the best aggregate critical-reliability method and remains below the strongest static policies overall. These results support Agentic-V2X as a safe and executable small-LLMassisted policy-generation architecture rather than a universally dominant scheduler. Index Terms—5G NR, V2X, O-RAN, rApp, xApp, small language models, ns-3, ns3-ai, scheduling, QoS, deadline-aware communication, network configuration.

I. I NTRODUCTION Fifth-generation New Radio (5G NR) and emerging sixthgeneration (6G) networks are evolving toward increasingly autonomous and AI-native architectures. The Open RAN (ORAN) architecture has made this evolution explicit by separating control logic across two distinct timescales: non-realtime 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 NearRT 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-realtime 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 xApplike 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 handtuned 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. II. R ELATED W ORK A. 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. B. 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. C. 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 ORAN 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 managementplane 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. D. 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 rAppinspired 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 NearRT RIC, or a conformant rApp/xApp; the terminology is used to describe the timescale separation, not a deployment.

Non-RT RIC Domain (Slow Control Loop) Simulation Domain

ns3-ai Interface (IPC)

ns-3 / 5G-LENA Environment Virtual Mobility (SUMO) Packet Transmission Loop

Telemetry Summary Fast Telemetry

RAN Scheduler (Weight-Adapted PF)

rApp-inspired Agent SLM Policy Generation qwen2.5:7b (Ollama)

Every 10 s

Scheduler Weights

Validated YAML Policy (Bounds & Constraints)

xApp-like Controller Deterministic Actuation Control Period: 100 ms

Near-RT RIC Domain (Fast Actuation Loop) Fig. 1. Proposed Agentic-V2X architecture. The system establishes strict timescale separation, isolating the stochastic small language model inside a slow non-real-time policy-generation loop while a deterministic xApp controller handles near-real-time scheduler adaptation via the ns3-ai module.

TABLE I P OSITIONING OF THE PROPOSED WORK AGAINST RELATED LLM- FOR - NETWORKING DIRECTIONS . Direction

Typical Focus

Difference Work

of

This

Telecom RAG

Standards Q&A

Intent-based RAN

Intent translation

LLM agents

General network automation

RL scheduling

Learned online control

O-RAN xApps

Near-real-time control

Executable V2X scheduler policies evaluated in ns-3 rApp-inspired LLM policy creation with xApplike enforcement Small local LLM with constrained policy validation Fast deterministic controller; LLM only creates policies LLM supplies validated policy bounds/objectives Fig. 2. Manhattan-style Urban grid

E. 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 I contrasts this direction with adjacent lines of work. III. S YSTEM M ODEL AND P ROBLEM F ORMULATION A. 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. B. 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 II lists the perservice traffic rates, criticality, direction, and the deadline

TABLE II V2X SERVICE CLASSES , TRAFFIC RATES , CRITICALITY, AND DEADLINE RELEVANCE . Service

Criticality

Dir.

Rate

Deadline

ToD (UL) ToD (DL) Awareness/AIC HDMap (DL) HDMap (UL) Sensor/RTSA

Critical Critical Critical Background Background Background

UL DL UL/DL DL UL UL/DL

16 Mbps 0.048 Mbps 0.032 Mbps 16 Mbps 0.008 Mbps 0.048 Mbps

20 ms 20 ms 100 ms 1000 ms 1000 ms 500 ms

used to classify a packet as on-time. The deadline values are scenario design parameters used to compute deadlineconstrained reception and are not experimental outcomes. The per-density service mixes (number of flows of each type) are summarised in Table VI and increase with density, so that higher densities stress both the critical and background classes more heavily. C. 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 πrApp containing baseline weights, allowed weight ranges, service priorities, and safety constraints. A fast xApp-like executor produces π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. D. 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 highrate 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 V-E (critical DCPRR, 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. IV. AGENTIC -V2X F RAMEWORK

repair and fallback) → deterministic xApp-like controller → ns3-ai → ns-3/5G-LENA scheduler → 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. B. 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-billionparameter 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. C. Structured YAML Policy Schema The agent emits a structured YAML policy whose fields are summarised in Table III. 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.

A. Framework Overview

D. Policy Validation, Repair, Fallback, and Runtime Shielding

Agentic-V2X separates slow policy reasoning from fast policy execution, as shown in Fig. 1. The pipeline is: operator objective and scenario summary → small local LLM (rAppinspired agent) → structured YAML policy → validator (with

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

TABLE III S TRUCTURED R A PP - INSPIRED POLICY SCHEMA FIELDS . Field

Meaning

Unique identifier for the generated policy Per-service starting weights (ToD, Awareness, HDMap, Sensor) bounds Per-service [min, max] weight ranges the controller may use safety_constraints Min critical weight, max background degradation, anti-starvation xapp_rules Optional guarded adaptation hints for the controller update_period Slow policy refresh cadence (10 s) fallback_policy Named safe policy used if validation fails runtime_safety Rollback and critical UL/DL balancing parameters enforced by the xApp

policy_id baseline_weights

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 LLMrApp/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 highdensity 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.

Algorithm 1 Validation, Runtime Shielding, and xApp Enforcement Require: LLM-generated policy p, telemetry zt , previous safe policy pprev Ensure: scheduler weights wt 1: Parse p against the YAML policy schema 2: if p is incomplete or violates a recoverable rule then 3: Repair p deterministically; log repair 4: end if 5: if p is invalid or violates a structural safety constraint then 6: if pprev exists then 7: Load previous validated policy pprev 8: else 9: Load static expert fallback policy 10: end if 11: else 12: Store current validated policy as pprev 13: Accept new validated policy p 14: Record current critical-flow performance baseline 15: end if 16: Observe telemetry zt 17: if critical violation rate, critical DC-PRR, or critical p95 latency degrades for 3 consecutive windows then 18: if pprev exists then 19: Roll back to pprev 20: else 21: Load static expert fallback policy 22: end if 23: end if 24: if |DC-PRRcrit,UL − DC-PRRcrit,DL | > 0.05 then 25: Temporarily boost weights of the weaker critical direction 26: end if 27: Apply xApp adaptation within validated bounds and hysteresis limits 28: Enforce minimum critical weights and anti-starvation constraints 29: return scheduler weights wt

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. 3. V. E XPERIMENTAL M ETHODOLOGY

E. Deterministic xApp-Like Execution

A. ns-3 / 5G NR Setup

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

Experiments use ns-3 with the 5G-LENA NR module [15], [16], SUMO mobility on a Manhattan grid [14], and ns3ai for external control [17]. The scheduler is PF-based with configurable per-UE UL/DL weights. The xApp-like control

TABLE V C OMPARED METHODS AND THEIR CONTROL BEHAVIOUR .

rApp-inspired LLM: policy generation and validation every 10 s

0s

10 s

20 s

30 s

xApp-like executor: deterministic weight adaptation every 100 ms

Method

Description

PF

True PF baseline; all service weights equal to 1 with no prioritisation Deterministic, manually selected static service weighting favouring critical traffic Deterministic, manually selected static weighting balancing critical and background Deterministic adaptive xApp-like controller, no LLM policy generation LLM generates one validated policy before the run, static weights throughout LLM generates/updates a validated policy every 10 s, deterministic xApp-like controller executes it every 100 ms

static expert balanced expert

100 xApp steps per 10 s policy interval Fig. 3. Control timescales in Agentic-V2X. The LLM policy agent operates every 10 s; the deterministic xApp-like controller actuates every 100 ms, keeping LLM inference out of the scheduling loop.

heuristic xApp static LLM LLM-adaptive

TABLE IV S IMULATION PARAMETERS . Parameter Simulator External control Mobility Densities Seeds Scheduler xApp control period rApp update period LLM serving Policy format Primary metric

Value ns-3 / 5G-LENA ns3-ai SUMO Manhattan grid 20, 25, 30 vehicles 7 seeds per density PF with configurable per-UE UL/DL weights 100 ms 10 s (adaptive method) Ollama, qwen2.5:7b YAML (validated/repaired) Critical DC-PRR

period is 100 ms; the rApp-inspired LLM update period is 10 s for the adaptive method. Table IV lists the main simulation parameters. B. Traffic and Service Mix The four services of Table II are instantiated according to the per-density mixes in Table VI. 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. C. Baselines We compare six scheduler-control methods, summarised in Table V. 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. D. Experiment Matrix The campaign is a full factorial of 3 densities × 7 seeds × 6 methods = 126 runs, all of which completed successfully and

TABLE VI E XPERIMENT MATRIX AND PER - DENSITY SERVICE MIXES . Density

HDM

AIC

ToD

RTSA

20 vehicles 25 vehicles 30 vehicles

1 2 3

5 6 7

1 2 3

13 15 17

Seeds: 1, 2, 3, 4, 5, 6, 7 Methods: PF, static expert, balanced expert, heuristic xApp, static LLM, adaptive LLM-rApp/xApp Total runs: 3 × 7 × 6 = 126

are included in the analysis. Table VI lists the densities, perdensity 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 × seven seeds). E. Metrics We report network-level and control-level metrics. Network metrics: critical deadline-constrained packet reception ratio (critical DC-PRR, combining ToD and Awareness), perservice 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 weightchange actions, number of safety interventions, LLM policygeneration 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. VI. R ESULTS This section reports results from the complete 126-run experimentation process (3 densities × 7 seeds × 6 methods). All figures are computed from the per-run telemetry described in Section V-E; per-method aggregates are means over the seven seeds at each density. Because the same density/seed

TABLE VII P OLICY VALIDITY AND SAFETY OUTCOMES (21 RUNS PER LLM- BASED METHOD ; ADAPTIVE LLM- R A PP / X A PP ISSUES 10 POLICY UPDATES PER RUN , 210 TOTAL ). Method

Valid/accepted

Repaired

Rejected

Fallback

static LLM LLM-adaptive

21/21 (100%) 210/210 (100%)

0 0

0 0

6/21 5/21

TABLE VIII C RITICAL DC-PRR (%) BY METHOD AND DENSITY ( MEAN OVER 7 SEEDS ). Method

20 veh.

25 veh.

30 veh.

PF static expert balanced expert heuristic xApp static LLM LLM-adaptive

95.1 94.5 97.9 98.6 90.5 84.4

70.2 64.7 65.2 59.6 69.2 62.1

59.8 62.1 54.9 61.1 63.7 65.4

combinations are reused across all methods, the main comparisons are paired rather than treated as independent samples. A. 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 VII correspond to controllerlevel 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. B. Critical-Service Reliability Table VIII 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 IX 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

TABLE IX T O D UL DC-PRR (%) BY METHOD AND DENSITY ( MEAN OVER 7 SEEDS ). Method

20 veh.

25 veh.

30 veh.

PF static expert balanced expert heuristic xApp static LLM LLM-adaptive

95.1 94.4 98.0 98.7 90.0 83.4

69.4 63.3 64.2 58.2 68.1 60.3

59.1 60.9 53.6 60.1 62.8 65.3

TABLE X AWARENESS UL DC-PRR (%) BY METHOD AND DENSITY ( MEAN OVER 7 SEEDS ). Method

20 veh.

25 veh.

30 veh.

PF static expert balanced expert heuristic xApp static LLM LLM-adaptive

90.0 91.3 92.9 92.8 88.8 87.9

86.0 81.7 82.6 88.7 91.0 91.1

77.8 83.5 79.1 78.4 76.5 75.7

TABLE XI C RITICAL DEADLINE - VIOLATION RATE (%) BY METHOD AND DENSITY, COMPUTED AS 1 − DC-PRR ( MEAN OVER 7 SEEDS ). Method

20 veh.

25 veh.

30 veh.

PF static expert balanced expert heuristic xApp static LLM LLM-adaptive

4.9 5.5 2.1 1.4 9.5 15.6

29.8 35.3 34.8 40.4 30.8 37.9

40.2 37.9 45.1 38.9 36.3 34.6

across all regimes, but rather that it becomes more competitive when the network is most congested. Awareness UL DC-PRR, shown in Table X, 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. C. Deadline Violations and Tail Latency Deadline-violation trends mirror the critical DC-PRR results because the violation rate is computed as one minus the ontime 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

Fig. 4. Reliability trends by density. The left panel reports critical DC-PRR, while the right panel isolates ToD UL DC-PRR. Error bars show the standard error of the mean across seven seeds.

Fig. 5. Overall critical-service DC-PRR components across all densities and seeds. Bars show means and error bars show the standard error of the mean across runs.

TABLE XII C RITICAL P 95 MAXIMUM LATENCY ( MS ) BY METHOD AND DENSITY ( MEAN OVER 7 SEEDS ).

TABLE XIII BACKGROUND THROUGHPUT (M BPS ) BY METHOD AND DENSITY ( MEAN OVER 7 SEEDS ).

Method

20 veh.

25 veh.

30 veh.

Method

20 veh.

25 veh.

30 veh.

PF static expert balanced expert heuristic xApp static LLM LLM-adaptive

30.4 16.3 125.6 57.7 16.7 16.1

2038.4 1725.4 2536.7 3252.2 2474.6 1329.3

2465.9 1406.2 2195.4 1675.0 1726.8 3825.8

PF static expert balanced expert heuristic xApp static LLM LLM-adaptive

16.272 16.359 16.175 16.224 16.425 16.425

12.930 13.116 12.398 11.915 13.081 14.510

11.118 12.936 11.840 12.399 11.973 9.537

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.

Fig. 6. Selected operating points where adaptive LLM-rApp/xApp is strongest or especially competitive: high-density critical reliability, high-density ToD UL reliability, medium-density background throughput, and medium-density critical p95 maximum latency.

D. Background-Service Preservation Table XIII reports background throughput. Adaptive LLMrApp/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. E. Benefit of xApp-Level Execution

TABLE XIV C ONTROL OVERHEAD AND PRACTICALITY, LLM- BASED METHODS ( MEAN ACROSS 21 RUNS UNLESS NOTED ). Metric LLM generation latency, mean (s) LLM generation latency, max observed (s) Policy generations per run Policy updates accepted per run Policy updates rejected per run Fallback invocations per run Rollback rows per run Directional UL interventions per run Directional DL interventions per run xApp mean step latency (ms)

static LLM

LLM-adaptive

–a –a

8.36 16.80 10 10 0 0.24 229.3 46.2 37.8 0.028

1 1 0 0.29 – – – 0.014

a static LLM issues a single generation call before the run; its per-call

latency was not separately logged.

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 DCPRR 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.

F. Control Overhead and Practicality The measured control overhead confirms the intended timescale separation. The LLM operates on the slow policygeneration 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 realtime scheduler latency. The deterministic xApp-like controller remains lightweight, with sub-millisecond mean execution

TABLE XV AGGREGATE PERFORMANCE COMPARISON ACROSS ALL 126 RUNS ( MEAN OVER 3 DENSITIES × 7 SEEDS = 21 RUNS PER METHOD ). Method PF static expert balanced expert heuristic xApp static LLM LLM-adaptive

Crit DC-PRR

ToD UL

AIC UL

Viol. Rate

Bg. Mbps

Mean Delay

p95 Max

75.1 73.8 72.7 73.1 74.4 70.6

74.5 72.9 71.9 72.4 73.7 69.7

84.6 85.5 84.9 86.6 85.4 84.9

24.9 26.2 27.3 26.9 25.6 29.4

13.440 14.137 13.471 13.513 13.826 13.490

79.4 46.6 80.3 88.2 75.3 96.5

1511.6 1049.3 1619.2 1661.6 1406.0 1723.7

Fig. 7. Aggregate performance trade-offs across all densities and seeds. Higher is better for critical DC-PRR and background throughput, while lower is better for deadline-violation rate and latency metrics.

overhead in the logged runs. G. Aggregate Comparison Table XV aggregates the headline metrics across all densities and seeds. PF has the highest aggregate critical DCPRR 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.

H. 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, twosided Wilcoxon signed-rank p-value, and paired win rate. Table XVI shows that adaptive LLM-rApp/xApp is not the best aggregate method for critical DC-PRR. The mean

TABLE XVI AGGREGATE PAIRED STATISTICAL COMPARISON FOR CRITICAL DC-PRR. D IFFERENCES ARE LLM- ADAPTIVE MINUS BASELINE OVER MATCHED DENSITY / SEED PAIRS ; POSITIVE VALUES FAVOUR LLM- ADAPTIVE . Baseline

n

Mean diff. (pp)

Median diff. (pp)

95% bootstrap CI (pp)

Wilcoxon p

Win rate

PF heuristic xApp static LLM static expert

21 21 21 21

-4.4 -2.5 -3.8 -3.1

+0.1 +0.0 +0.0 -0.3

[-14.4, +4.2] [-12.3, +5.7] [-10.9, +2.9] [-12.0, +4.2]

0.759 0.973 0.585 0.683

61.9% 52.4% 52.4% 42.9%

TABLE XVII AGGREGATE PAIRED STATISTICS FOR THE PRIMARY RELIABILITY METRIC AND KEY SECONDARY METRICS . D IFFERENCES ARE ADAPTIVE LLM- R A PP / X A PP MINUS BASELINE OVER 21 MATCHED DENSITY / SEED PAIRS .

Metric

Baseline

Unit

n

Mean diff.

Median diff.

95% bootstrap CI

Wilcoxon p

Win rate

Critical DC-PRR

PF heuristic xApp static LLM static expert PF heuristic xApp static LLM static expert PF heuristic xApp static LLM static expert

pp pp pp pp ms ms ms ms Mbps Mbps Mbps Mbps

21 21 21 21 21 21 21 21 21 21 21 21

-4.4 -2.5 -3.8 -3.1 +212.2 +62.1 +317.7 +674.4 +0.050 -0.022 -0.336 -0.646

+0.1 +0.0 +0.0 -0.3 +0.0 +0.3 +1.3 +0.1 -0.000 +0.000 -0.000 -0.000

[-14.4, +4.2] [-12.3, +5.7] [-10.9, +2.9] [-12.0, +4.2] [-524.0, +997.3] [-921.3, +1106.0] [-879.3, +1438.4] [+2.2, +1431.0] [-0.877, +1.083] [-1.424, +1.289] [-1.711, +1.043] [-1.797, +0.449]

0.759 0.973 0.585 0.683 0.812 0.658 0.393 0.473 0.794 0.865 0.502 0.391

61.9% 52.4% 52.4% 42.9% 47.6% 38.1% 42.9% 47.6% 47.6% 52.4% 38.1% 38.1%

Critical p95 max

Background throughput

Fig. 8. Aggregate paired critical DC-PRR differences for adaptive LLMrApp/xApp against selected baselines over matched density/seed pairs.

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. I. Summary of Findings

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 XVII 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 tradeoff behaviour rather than universal dominance. Table XVIII reports the density-specific claim checks. At

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 densityspecific 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. VII. D ISCUSSION A. LLM as a Real-Time Scheduler The architecture deliberately keeps the LLM out of the scheduling loop. Three properties of LLM inference make

TABLE XVIII PAIRED STATISTICAL CHECKS FOR THE MAIN OPERATING - POINT CLAIMS . D IFFERENCES ARE ADAPTIVE LLM- R A PP / X A PP MINUS THE BASELINE ON THE SAME DENSITY AND SEED . P OSITIVE VALUES FAVOUR ADAPTIVE LLM FOR DC-PRR AND THROUGHPUT; NEGATIVE VALUES FAVOUR ADAPTIVE LLM FOR LATENCY. Claim / metric

Baseline

Unit

n

Mean diff.

Median diff.

95% bootstrap CI

Wilcoxon p

Win rate

Critical DC-PRR, 30 veh.

PF heuristic xApp static LLM static expert PF heuristic xApp static LLM static expert PF heuristic xApp static LLM static expert PF heuristic xApp static LLM static expert PF heuristic xApp static LLM static expert

pp pp pp pp ms ms ms ms Mbps Mbps Mbps Mbps pp pp pp pp pp pp pp pp

7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 21 21 21 21

+5.6 +4.3 +1.8 +3.4 -709.1 -1922.9 -1145.3 -396.1 +1.580 +2.595 +1.429 +1.394 -10.8 -14.2 -6.1 -10.2 -4.4 -2.5 -3.8 -3.1

+7.3 +8.6 +0.5 -0.9 -1104.4 -2370.7 -426.1 -671.4 +0.749 +2.248 +1.861 +0.642 +0.0 -0.3 -0.1 -0.3 +0.1 +0.0 +0.0 -0.3

[-1.3, +11.6] [-6.3, +14.9] [-6.3, +10.5] [-6.7, +13.7] [-2007.1, +676.5] [-3413.2, -408.1] [-3858.2, +1621.0] [-1004.3, +257.6] [-0.202, +3.677] [+0.824, +4.419] [-1.503, +4.126] [+0.180, +2.842] [-34.7, +8.8] [-34.7, +2.0] [-17.1, +0.1] [-30.0, +0.5] [-14.4, +4.2] [-12.3, +5.7] [-10.9, +2.9] [-12.0, +4.2]

0.156 0.578 0.688 0.688 0.469 0.109 0.469 0.375 0.375 0.047 0.469 0.219 0.938 0.219 0.375 0.297 0.759 0.973 0.585 0.683

71.4% 57.1% 71.4% 42.9% 57.1% 71.4% 57.1% 71.4% 57.1% 85.7% 57.1% 57.1% 71.4% 28.6% 42.9% 28.6% 61.9% 52.4% 52.4% 42.9%

Critical p95 max, 25 veh.

Background throughput, 25 veh.

Critical DC-PRR, 20 veh.

Aggregate critical DC-PRR

it unsuitable for near-real-time scheduling: latency at a multi-second wall-clock scale in this configuration, nondeterministic 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.

DC-PRR. We therefore interpret the adaptive method as a competitive policy-generation architecture with useful densityspecific 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.

B. Small LLMs as rApp-Inspired Policy Creators

D. Role of the xApp

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.

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. E. Safety and Validation

C. 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

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. F. 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 DCPRR, 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. VIII. L IMITATIONS 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. IX. C ONCLUSION 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 × 7 seeds × 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 DCPRR 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. X. F UTURE W ORK Future work includes integration with a real O-RAN NonRT/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 highdensity critical-flow balance without sacrificing ToD uplink protection. R EFERENCES [1] M. Polese, L. Bonati, S. D’Oro, S. Basagni, and T. Melodia, “Understanding O-RAN: Architecture, interfaces, algorithms, security, and research challenges,” IEEE Communications Surveys & Tutorials, vol. 25, no. 2, pp. 1376–1411, 2023. [2] T. T. T. Le and S. Moh, “Comprehensive survey of radio resource allocation schemes for 5G V2X communications,” IEEE Access, vol. 9, pp. 123 117–123 133, 2021. [3] S. Gyawali, S. Xu, Y. Qian, and R. Q. Hu, “Challenges and solutions for cellular based V2X communications,” IEEE Communications Surveys & Tutorials, vol. 23, no. 1, pp. 222–255, 2021. [4] H. Zhou, C. Hu, Y. Yuan, Y. Cui, Y. Jin, C. Chen, H. Wu, D. Yuan, L. Jiang, D. Wu, X. Liu, C. Zhang, X. Wang, and J. Liu, “Large language model (LLM) for telecommunications: A comprehensive survey on principles, key techniques, and opportunities,” arXiv preprint arXiv:2405.10825, 2024. [5] F. A. Bimo, M. A. C. Galdon, C.-K. Lai, R.-G. Cheng, and E. K. P. Chong, “Intent-based network for RAN management with large language models,” arXiv preprint arXiv:2507.14230, 2025. [6] H. Ye and G. Y. Li, “Deep reinforcement learning for resource allocation in V2V communications,” in Proc. IEEE International Conference on Communications (ICC), 2018, pp. 1–6. [7] H. Ye, G. Y. Li, and B.-H. F. Juang, “Deep reinforcement learning based resource allocation for V2V communications,” IEEE Transactions on Vehicular Technology, vol. 68, no. 4, pp. 3163–3173, 2019. [8] L. Liang, H. Ye, and G. Y. Li, “Spectrum sharing in vehicular networks based on multi-agent reinforcement learning,” IEEE Journal on Selected Areas in Communications, vol. 37, no. 10, pp. 2282–2292, 2019. [9] L. Bariah, H. Zou, Q. Zhao, B. Mouhouche, F. Bader, and M. Debbah, “Understanding telecom language through large language models,” in Proc. IEEE Global Communications Conference (GLOBECOM), 2023, pp. 6542–6547. [10] K. Dzeparoska, J. Lin, A. Tizghadam, and A. Leon-Garcia, “LLM-based policy generation for intent-based management of applications,” in Proc. 19th International Conference on Network and Service Management (CNSM), 2023, pp. 1–7. [11] L. Bao, S. Yun, J. Lee, and T. Q. S. Quek, “LLM-guided open RAN: Empowering hierarchical RAN intelligent control,” arXiv preprint arXiv:2504.18062, 2025. [12] M. Xu, D. Niyato, J. Kang, Z. Xiong, S. Mao, Z. Han, D. I. Kim, and K. B. Letaief, “When large language model agents meet 6G networks: Perception, grounding, and alignment,” arXiv preprint arXiv:2401.07764, 2024.

[13] L. Wang, C. Ma, X. Feng, Z. Zhang, H. Yang, J. Zhang, Z. Chen, J. Tang, X. Chen, Y. Lin, W. X. Zhao, Z. Wei, and J.-R. Wen, “A survey on large language model based autonomous agents,” Frontiers of Computer Science, vol. 18, no. 6, p. 186345, 2024. [14] P. A. López, M. Behrisch, L. Bieker-Walz, J. Erdmann, Y.-P. Flötteröd, R. Hilbrich, L. Lücken, J. Rummel, P. Wagner, and E. Wießner, “Microscopic traffic simulation using SUMO,” in Proc. 21st International Conference on Intelligent Transportation Systems (ITSC), 2018, pp. 2575–2582. [15] N. Patriciello, S. Lagén, B. Bojović, and L. Giupponi, “An E2E simulator for 5G NR networks,” Simulation Modelling Practice and Theory, vol. 96, p. 101933, 2019. [16] K. Koutlia, B. Bojovic, Z. Ali, and S. Lagen, “Calibration of the 5GLENA system level simulator in 3GPP reference scenarios,” Simulation Modelling Practice and Theory, vol. 119, p. 102580, 2022. [17] H. Yin, P. Liu, K. Liu, L. Cao, L. Zhang, Y. Gao, and X. Hei, “ns3-ai: Fostering artificial intelligence algorithms for networking research,” in Proc. 2020 Workshop on ns-3 (WNS3), 2020, pp. 57–64.

A PPENDIX 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. A. 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. 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% is tolerable. - 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.

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

B. 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 runtimesafety 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

C. 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