{"id":"7b18202c-c655-4ea8-ac0b-d19b5a5e9e05","arxiv_id":"2607.04290","paper_version":1,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":5.5,"correctness_risk":"medium","formal_verification":"none","parameter_count":6,"one_line_summary":"A validated small-LLM rApp-style policy layer plus a 100 ms deterministic xApp produces executable deadline-aware V2X scheduler weights that are competitive at high density but not best overall.","lead":"A small local language model can safely write scheduler policies for vehicle networks if a validator and a fast deterministic controller sit between it and the radio. The paper shows this hierarchical design works in simulation and is competitive in some dense traffic cases, without claiming it beats every baseline.","discovery_kind":"new_application","skeptic_critique":{"model":"grok-4.5","headline":"High-density 'improved mean critical reliability' rests on a non-significant n=7 paired difference, while frequent runtime rollbacks show safety is mostly non-LLM.","rationale":"The paper is careful overall (no universal-dominance claim, full paired stats reported, Limitations explicit). The reader's external-validity concern (single-cell ns-3, fixed rates, no real A1/E2) is real and already justifies CONDITIONAL. The more immediate load-bearing soft spot inside the stated regime is the statistical fragility of the single positive operating point that the Abstract and strongest claim advertise, together with the high rate of runtime overrides. That does not falsify the modest architectural claim ('safe executable policy generator rather than dominant scheduler'), but it does make the evidence for 'competitive' thinner than presented and shows that safety/executability is carried by the deterministic layers. Hence the verdict stays CONDITIONAL (more seeds or ablation of the shield would be required before upgrading), and agreement with the reader is only partial because the weakest link is the internal evidence for the highlighted density-specific gain rather than solely transfer to multi-cell O-RAN.","tokens_in":20321,"tokens_out":611,"duration_ms":39652,"concrete_test":"Re-run only the 30-vehicle density for adaptive LLM-rApp/xApp and PF with ≥20 additional independent seeds (total n≥27 matched pairs). Recompute the paired mean difference, bootstrap CI and Wilcoxon p for critical DC-PRR. If the mean remains positive, CI excludes zero and p<0.05, the operating-point claim is retained; otherwise remove 'improved mean critical reliability over PF at the highest density' from Abstract and strongest claim.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"The strongest claim and Abstract highlight that adaptive LLM-rApp/xApp 'remains competitive... including improved mean critical reliability over PF at the highest density' (Table VIII: 65.4% vs 59.8% at 30 veh). That directional claim is load-bearing for treating the architecture as useful (not merely valid). Yet Table XVIII shows the matched paired difference is only +5.6 pp (win rate 71.4%), Wilcoxon p=0.156, and the 95% bootstrap CI includes negative values; n=7 is under-powered for density-specific inference (Limitations). Aggregate paired tests (Table XVI) are negative vs PF/static LLM/expert. Concurrently Table XIV records 229.3 rollback rows and ~84 directional interventions per run, so Alg. 1's runtime shield frequently overrides the LLM policy. Validity is therefore almost entirely supplied by the constrained YAML schema + validator + deterministic xApp, not by the quality of LLM content. The 'competitive architecture' reading therefore rests on a statistically fragile operating-point mean plus heavy non-LLM shielding.","agreement_with_reader":"partial"},"referee_report":{"model":"grok-4.5","summary":"The paper proposes Agentic-V2X, a hierarchical control architecture for deadline-aware 5G NR V2X scheduling in which a small local LLM (qwen2.5:7b) acts as a slow, rApp-inspired policy generator (10 s) that emits constrained YAML policies (priorities, weight bounds, safety constraints), while a deterministic xApp-like controller enforces validated policies via PF scheduler-weight adaptation every 100 ms in ns-3/5G-LENA/SUMO/ns3-ai. A validator with repair/fallback plus a runtime performance shield (rollback and directional UL/DL guards) is intended to keep stochastic LLM outputs out of the near-real-time loop. Over a full factorial of 126 matched-seed runs (3 densities × 7 seeds × 6 methods), the authors report 100% policy acceptance (210/210 adaptive updates), density-specific competitiveness (e.g., higher mean critical DC-PRR than PF at 30 vehicles), and honest paired Wilcoxon/bootstrap analysis showing that the adaptive method is not the best aggregate critical-reliability method. The central claim is architectural: a safe, executable small-LLM policy-generation design rather than a universally dominant scheduler.","tokens_in":20695,"tokens_out":1603,"duration_ms":29896,"significance":"If the result holds, the work is a useful and timely contribution to LLM-for-RAN research: it argues against putting LLMs in the near-real-time scheduling loop and instead demonstrates a practical O-RAN-inspired timescale separation with explicit validation, repair, fallback, and runtime shielding. Strengths that should be credited include the full 126-run matched-seed campaign, explicit policy-validity and safety-intervention metrics, paired statistical analysis that refuses aggregate dominance, and an auditable appendix (system/user prompts, validated YAML schema, and an accepted example policy). These make the paper more reproducible and more carefully framed than much of the adjacent LLM-agent networking literature. The significance is primarily architectural and methodological rather than a new scheduling algorithm or a claim of state-of-the-art reliability.","major_comments":[{"comment":"Abstract and §VI-B/Table VIII highlight that adaptive LLM-rApp/xApp obtains improved mean critical reliability over PF at 30 vehicles (65.4% vs 59.8%). Table XVIII shows this is a non-significant n=7 paired difference (+5.6 pp, Wilcoxon p=0.156, 95% bootstrap CI includes negative values, win rate 71.4%). Aggregate paired tests (Table XVI) are negative versus PF, static LLM, and static expert. The high-density mean is therefore an operating-point observation, not a statistically supported superiority claim. The Abstract and contribution language should be revised so that this point is not presented as established improvement without the paired-test caveat already present later in the paper.","section":null},{"comment":"Table XIV reports 229.3 rollback rows per run plus ~84 directional UL/DL interventions per run for the adaptive method, while schema-level rejections are zero (Table VII). Algorithm 1 and §IV-D make clear that much of the safety and corrective behaviour is supplied by the deterministic runtime shield and xApp bounds rather than by the content of the LLM policy. The paper’s claim that the design is a “small-LLM-assisted” competitive architecture is still defensible, but §VI-E/§VII currently under-analyse how often and under what conditions the LLM policy is overridden. A load-bearing clarification is needed: either quantify the fraction of control time spent under the original LLM policy versus rolled-back/fallback policies, or temper language that attributes density-specific gains primarily to LLM policy generation.","section":null},{"comment":"The evaluation isolates static LLM vs adaptive LLM-rApp/xApp and heuristic xApp vs adaptive, but does not cleanly ablate (i) LLM-generated bounds/baselines with the runtime shield disabled, or (ii) the same adaptive xApp rules driven by a fixed expert policy rather than LLM updates. Without that, it remains hard to attribute the 30-vehicle critical-DC-PRR mean and the 25-vehicle throughput/latency operating points to the LLM versus the shared deterministic machinery. Given that the central claim is architectural usefulness of the LLM policy layer, §V-C/§VI-E should either add a minimal ablation or explicitly state that current evidence supports the full stack more than the LLM content alone.","section":null},{"comment":"Limitations (§VIII) correctly note single-cell simulation, three densities, seven seeds, one model, and fixed 10 s/100 ms cadences. These constraints are acceptable for a systems paper, but they interact with the weakest transfer assumption: that validity and density-specific competitiveness under a hand-crafted YAML schema transfer toward real multi-cell V2X and A1/E2 O-RAN deployments. The Discussion should more sharply separate what is demonstrated (safe executable policy generation in this ns-3 setup) from what is hypothesized (deployable rApp/xApp pattern), so the architectural claim is not over-read as deployment readiness.","section":null}],"minor_comments":[{"comment":"Table XIV footnote notes that static-LLM generation latency was not separately logged; reporting it would complete the practicality comparison with the adaptive path.","section":null},{"comment":"Figure 4/5/6 captions and axis labels should state units and whether error bars are SEM over seeds (as claimed in the text) so the plots are self-contained.","section":null},{"comment":"Terminology oscillates between “rApp-inspired/xApp-like” and shorter “LLM-rApp/xApp”; a single consistent short form after first definition would improve readability.","section":null},{"comment":"In Table II and the service mix (Table VI), briefly justify why ToD UL is 16 Mbps while ToD DL is 0.048 Mbps for readers less familiar with 5GAA teleoperated-driving models.","section":null},{"comment":"Appendix Listing A.4 shows ToD bounds [4,8] while safety_constraints.min_critical_weight is 5; a one-line note on how the validator reconciles baseline/bounds with min_critical_weight would avoid confusion.","section":null},{"comment":"A few typos and hyphenation inconsistencies appear (e.g., “Y AML” spacing, “RELATEDWORK” heading concatenation in the source); a copy-edit pass is needed.","section":null}],"recommendation":"major_revision","confidential_remarks":"The manuscript is more careful and less hype-driven than much of the LLM-for-networking literature, which is a positive fit for a serious networking venue. The main risk is abstract/claim inflation around the non-significant 30-vehicle mean and under-discussed runtime overrides; if the authors revise framing and add a short attribution/ablation discussion, this could become a solid systems contribution. I would not reject for lack of real O-RAN interfaces given the explicit simulation scope, but I would push hard on statistical honesty in the Abstract."},"author_rebuttal":null,"desk_editor":{"model":"grok-4.5","letter":"The useful takeaway is architectural, not a new scheduler: put a small local LLM on a 10 s rApp-like loop, force it into a tight YAML schema, validate/repair, then let a 100 ms deterministic weight adapter (with rollback and UL/DL guards) do the radio work. That split is the real contribution, and they evaluate it honestly.\n\nWhat is new is the concrete V2X packaging—deadline-aware multi-service mix (ToD, awareness, HD map, sensor), structured policy with bounds and runtime_safety, ns-3/5G-LENA/SUMO/ns3-ai execution, and a full 3×7×6 factorial of 126 matched-seed runs. They report policy validity cleanly (210/210 adaptive updates accepted), keep LLM latency out of the control loop, and refuse to claim aggregate dominance. Aggregate tables and paired Wilcoxon/bootstrap tests put adaptive LLM-rApp/xApp below PF and the stronger static policies on critical DC-PRR; the paper says so. That restraint is a strength.\n\nSoft spots are real but proportional. The high-density critical-reliability edge over PF (65.4% vs 59.8%) is only n=7, mean +5.6 pp, p=0.156, CI that includes negatives—so treat it as directional, not settled. Table XIV’s ~229 rollback rows and dozens of directional interventions per run show the runtime shield and validator carry a lot of the safety load; executability is mostly the constrained schema plus deterministic xApp, not free-form LLM judgment. Scope is single-cell simulation, one model (qwen2.5:7b), fixed rates/densities, no public code, and no real A1/E2. Citations look standard for O-RAN, V2X RRM, and LLM-for-telecom; no circular math.\n\nThis is for people building AI-for-RAN or O-RAN policy stacks who need a reproducible pattern for keeping LLMs out of the near-RT loop. It is not a universal scheduler paper. I would send it to peer review: the experiment design and self-limiting claims are serious enough to deserve referee time, with pressure on stats power, ablation of the shield, and code release. Worth engaging if you work in that lane; not a must-read outside it.","headline":"Solid hierarchical template for small-LLM V2X policy generation; validity is real, high-density win is directional and under-powered, and the xApp shield does a lot of the safety work.","tokens_in":21355,"tokens_out":595,"would_cite":true,"duration_ms":5762,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"grok-4.5","headline":"A small local language model can safely write V2X scheduler policies if a validator and a fast controller keep it out of the radio loop.","keywords":["5G NR","V2X","O-RAN","rApp","xApp","small language models","deadline-aware scheduling","ns-3"],"falsifier":"Re-run the identical service mix and seeds with a multi-cell handover-capable 5G-LENA setup or a real Non-RT/Near-RT RIC and A1/E2 path; if policy validity falls below 100 percent or the high-density critical-reliability edge over proportional fair disappears under the same paired analysis, the central architectural claim fails.","tokens_in":21178,"feed_emoji":"📡","tokens_out":675,"duration_ms":11617,"temperature":0.7,"pith_summary":"Large language models are too slow and too unpredictable to run a near-real-time packet scheduler, especially for mixed critical and background vehicle traffic. This paper proposes Agentic-V2X: a small local model acts only as a slow policy writer (every 10 seconds), producing a structured YAML document of service weights, bounds, and safety limits. A validator repairs or rejects the document, and a deterministic controller then adapts scheduler weights every 100 ms inside those bounds. Across 126 matched simulation runs that include teleoperated driving, cooperative awareness, HD maps, and sensor sharing, every generated policy stayed valid and executable. The adaptive path improved mean critical reliability over plain proportional fair at the densest load and offered useful medium-density latency and throughput trade-offs, yet it did not beat the strongest static expert policies in aggregate. The claim is therefore architectural: small models can serve as safe policy assistants for deadline-aware V2X scheduling when the fast loop remains deterministic and bounded.","feed_headline":"Small LLMs write safe V2X policies when kept out of the radio loop","feed_subtitle":"Validator plus 100 ms controller keeps every policy executable; gains appear mainly at high density","key_machinery":"Agentic-V2X hierarchical control: an rApp-inspired small-LLM policy agent that emits a constrained YAML weight-and-bound document every 10 s, paired with a validator-plus-runtime-shield and a 100 ms xApp-like weight adapter that never exceeds the validated limits.","core_discovery":"When a small local language model is confined to slow, schema-constrained policy generation and its outputs are validated, repaired, and executed by a bounded deterministic controller, it produces fully executable V2X scheduler policies that stay competitive at selected operating points (notably high-density critical reliability) without ever becoming a universal scheduler replacement.","pith_inferences":[],"forward_implications":[],"fun_headline_variants":["Small LLMs write executable V2X policies when kept out of radio loop","Validated small-LLM rApp policies stay competitive in dense V2X scheduling","Isolated small LLMs generate safe deadline-aware V2X scheduler weights","Schema-constrained LLM policies beat PF on high-density V2X reliability","Bounded controller plus validator turns small LLMs into safe V2X policy agents"],"cache_read_input_tokens":16512,"weakest_assumption_plain":"The single-cell simulator with fixed service rates, three vehicle densities, seven seeds, a 10-second refresh, and a hand-crafted YAML schema is representative enough that the observed validity and density-specific gains would still hold in multi-cell hardware and real O-RAN interfaces.","fun_headline_variants_meta":{"raw":{"variants":["Small LLMs write executable V2X policies when kept out of radio loop","Validated small-LLM rApp policies stay competitive in dense V2X scheduling","Isolated small LLMs generate safe deadline-aware V2X scheduler weights","Schema-constrained LLM policies beat PF on high-density V2X reliability","Bounded controller plus validator turns small LLMs into safe V2X policy agents"]},"model":"grok-4.5","effort":"low","cost_usd":0.005236,"raw_usage":{"total_tokens":1484,"prompt_tokens":869,"num_sources_used":0,"completion_tokens":103,"cost_in_usd_ticks":52360000,"prompt_tokens_details":{"text_tokens":869,"audio_tokens":0,"image_tokens":0,"cached_tokens":128},"completion_tokens_details":{"audio_tokens":0,"reasoning_tokens":512,"accepted_prediction_tokens":0,"rejected_prediction_tokens":0}},"tokens_in":869,"tokens_out":103,"duration_ms":6054,"temperature":1.0,"reasoning_tokens":512,"cache_read_input_tokens":128,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-07-11T20:19:02.813254+00:00","model_set":{"reader":"grok-4.5"},"falsifier":"Re-run the identical service mix and seeds with a multi-cell handover-capable 5G-LENA setup or a real Non-RT/Near-RT RIC and A1/E2 path; if policy validity falls below 100 percent or the high-density critical-reliability edge over proportional fair disappears under the same paired analysis, the central architectural claim fails.","supporting_citations":[],"review_version":1}