PaperlayerView exact revision on arXiv

Source-linked AI summary

Intent Interpretation at RIC Timescales: Jev Decision Models versus Large Language Models in 6G Open RAN

Delong Li, Xu Wang, Haochen Gong, Rui Lang, Guangsheng Yu

arXiv:2609.23136v2cs.NI

TL;DR

Intent-based Open RAN needs interpreters that translate intents into A1 policies within RIC control-loop timing, raising the question of whether LLM delay affects deadlines, capacity, or radio performance. The paper compares decision models and LLMs using RANIntent v1, closed-loop simulation, and a real A1/E2 path; Jev-1.13.0 meets the 1 s budget on 99.8% of calls, compared with 17.9% and 0% for two hosted LLMs.

  • Problem

    How interpreter waiting fits the shared delay budget for intent delivery and radio scheduling remains a central question in Open RAN intent control.

    Source: §1 · pp. 1–2

  • Method

    The study compares interpreters using RANIntent v1, an O-RAN-aligned closed-loop ns-3 evaluation, and a real A1/E2 path.

    Source: §1 · p. 2

  • Results

    Median interpretation takes 0.286 to 2.35 s; Jev-1.13.0 meets the 1 s near-RT budget on 99.8% of calls, versus GLM-5.3-Flash on 17.9% and Qwen3.8-Flash on 0%.

    Source: §1 · p. 2

  • Takeaways & Limitations

    At the tested base point, slow interpreters miss the 1 s budget and can saturate queues at 2 intents/s, while a general radio penalty was not resolved.

    Source: §1 · p. 2, §7 · p. 21

    Radio-simulation inferences are conditional on one common-random-number realization; the bootstrap does not quantify variation across independently generated realizations.

    Source: §6.3 · p. 21

Abstract

from arXiv · show

Intent-based Open RAN needs an interpreter that turns intents into A1 policies within the loop of the RAN intelligent controller (RIC). Decision models such as Jev-1.13.0 return typed policy fields, whereas generative large language models (LLMs) produce the policy token by token. We ask whether the extra delay of LLMs costs control deadlines, RIC capacity, or radio performance. We compare Jev-1.13.0 and two other decision models with LLMs on the RANIntent v1 benchmark, in closed-loop ns-3 simulation and on a real A1 and E2 path. Median interpretation takes 0.286 to 2.35 s, against under 25 ms for A1 and E2 transfer. Jev-1.13.0 meets the 1 s near-real-time budget on 99.8% of calls, while two hosted LLMs meet it on 17.9% and 0%. In the radio network, ideal enforcement moves the affected-class service-level agreement (SLA) violation by 3.96 percentage points in the direction each intent requests, against no update at the base point. No hosted LLM showed a resolved increase over Jev-1.13.0 at that point. At the same point, per-second direct control gave no resolved SLA reduction over a numerical xApp. Slow interpreters miss the 1 s budget, and two interpreters saturate their queues at 2 intents/s, whereas no radio penalty of slow interpreters was resolved at the base point.

1. Introduction

This paper compares typed decision models with token-generating LLMs as A1 policy interpreters, asking which RIC loop can host each and how interpretation delay affects radio control. Its findings connect interpreter latency and capacity to closed-loop SLA outcomes, while separating policy interpretation from radio-state tracking.

Contributions

  • The study introduces RANIntent v1 and evaluates three decision models against three hosted LLMs, using closed-loop ns-3 simulation and a real A1/E2 software-gNB path.RANIntent v1 maps intents to A1 policy fields and pairs them with 3-to-57-cell telemetry; latency-only, accuracy-only, and net simulation arms separate delay effects from policy-error effects.Source: §1 · p. 2

Key insights

  • Interpretation medians were 0.286–2.35 s; Jev-1.13.0 met the 1 s near-RT budget on 99.8% of calls, versus 17.9% for GLM-5.3-Flash and 0% for Qwen3.8-Flash.A1 transfer took 15.5–19.1 ms and E2 control 2.4–3.1 ms, so interpretation dominated the measured control path.Source: §1 · p. 2
  • Ideal enforcement moved affected-class SLA violation by 3.96 percentage points in the requested direction against no update at the base point, with no resolved hosted-LLM increase over Jev-1.13.0.UE speed and intent rate moved affected-class SLA violation by up to 17 pp; a general radio penalty of interpreter choice was not resolved.Source: §1 · p. 2
  • At 2 intents/s, Jev-1.13.0 occupied at most 14.9% of interpretation slots, while AnyJev-L0 and Qwen3.8-Flash exceeded full utilization.Their p95 queue waits reached 34.5 s and 20.3 s, respectively.Source: §1 · p. 2
  • Per-second direct per-cell priority control gave no resolved SLA reduction over the policy-and-xApp split, and five of 28 contrasts were resolved increases.The interpreter can instead set intent policy once while a numerical near-RT xApp tracks changing radio state.Source: §1 · p. 2
  • On 57-cell tables, GLM-5.3-Flash and DeepSeek-V4.1-Flash reached 0.967 and 0.960 against 0.907 for Jev-1.13.0, but neither paired difference was resolved.GLM-5.3-Flash met the near-RT budget on only 17.9% of calls; Jev-1.13.0 was least expensive at 0.207 USD per 1,000 correct policies.Source: §1 · p. 2

2. Related Work

Related work studies intent translation, O-RAN control, radio testbeds, and telecom benchmarks, but the paper identifies a gap in jointly connecting interpreter latency to O-RAN loop budgets, comparing decision models with LLMs, and measuring radio outcomes under handover. The paper’s evaluation combines these dimensions across A1/E2 paths and moving UEs.

Intent-based O-RAN control with LLM agents

  • Table 1 organizes O-RAN intent-control studies by research line and reports which of twelve evaluation dimensions each measures; prior agents compile, validate, or dispatch policies [15] [28].CAIF takes 11.8 s for a one-shot intent, while ORION attributes most of its end-to-end latency to the LLM.Source: §2 · p. 2, Table 1 · p. 3

Real radio equipment

  • Prior radio testbeds connect LLM agents to OAI, X5G, or srsRAN, while this study pairs real-stack validation with multi-cell NR simulation, handovers, and radio outcomes [16, 17, 26, 27].The cited testbeds serve two to five UEs; ALLSTaR measures execution against a 400 µs budget, and LLM-xApp compares slice allocation with random and equal allocation.Source: §2 · pp. 3–4

LLM intent translation in core and cloud networks

  • Core, cloud, and service-orchestration work evaluates intent translation quality, time, validation, and cost, whereas this study places interpretation in the O-RAN hierarchy and measures its effects on radio scheduling [11].Reported examples include translation exceeding two minutes for requests with more than three applications and token consumption treated as operational cost.Source: §2 · p. 4

Telecom LLM benchmarks

  • Telecom benchmarks assess network question-answering, reasoning, or configuration output; this evaluation scores each policy against typed ground truth and the radio outcomes following enforcement.6G-Bench models above 30B parameters exceed 20–40 s per question, and NetLLM reports token-based prediction can exceed a 1 s deadline without guaranteeing valid answers.Source: §2 · p. 4

Decision-model interpreters

  • Decision-model work reports typed choices or scores and compares readouts or admission decisions with LLMs, while this study asks which O-RAN loop can host each interpreter [20].AnyJev reports milliseconds per decision on one H100 NVL; the paper identifies no prior work jointly covering O-RAN loop budgets, interpreter comparisons, and radio outcomes under handover.Source: §2 · p. 4

3. Intent-Driven Control in Open RAN

This section specifies how intent interpretation fits O-RAN control loops and defines the policy, enforcement-timing, stale-exposure, and outcome measures used to evaluate it.

3.1. O-RAN Control Loops and Interpreter Placement

  • The non-RT RIC rApp sends interpreted policies over A1 for near-RT xApp enforcement over E2; the proposed xApp-hosted interpreter must fit the 1 s loop budget.Real-stack E2 acknowledgement took 2.5–6.9 ms, leaving almost the full budget for interpretation; an interpreter with a latency tail exceeding 1 s fits only the non-RT modes.Source: §3.1 · pp. 4–5

3.2. Intents, Policies, and Versions

  • Each intent versions a target defined by traffic class and cell scope and yields a schema-bounded A1 policy, with telemetry needed to resolve state-dependent scopes.A shared validator checks format and supported values, while semantic correctness is scored separately against canonical policies.Source: §3.2 · p. 5

3.3. Division of Labor Between Interpreter and xApp

  • Policy interpretation installs a weight map through one E2 control and leaves 1 s numerical adjustments to a shared xApp, whereas direct control recomputes priorities each second.A structured-input reference applies the canonical policy after E2 acknowledgement alone and uses the same xApp.Source: §3.3 · pp. 5–6

3.4. Enforcement Time and Stale-Policy Exposure

  • In mode X, intent-to-enforcement meets the 1 s budget only when interpretation plus E2 acknowledgement does, while delayed enforcement extends stale-policy exposure for requests.Latency is measured from invocation through response while mobility, traffic, and scheduling continue; class latency targets of 5–100 ms are short relative to the loop budget.Source: §3.4 · p. 6

3.5. Quality and Radio Metrics

  • Radio evaluation tracks affected-class and network-wide SLA violations against canonical class targets, primarily over 2 s, alongside throughput, delay, PRB, mobility, and outage KPIs.Semantic correctness is scored separately from radio outcomes; the KPI set includes UE throughput percentiles, packet-delay percentiles and jitter, handovers, radio link failures, and outage share.Source: §3.5 · pp. 6–7

4. Evaluation Methodology · 4.1. Research Questions and Evidence Design

The evaluation frames six research questions across three platforms, pairing interpretation-quality tests with closed-loop radio simulation and a real A1/E2 path. It separates interpretation accuracy from radio outcomes and controls simulation comparisons by holding the run conditions fixed.

4.1. Research Questions and Evidence Design

  • Every RANIntent v1 case is evaluated by every interpreter against typed policy truth, alongside closed-loop multi-cell NR simulation and a live A1/E2 path to a software gNB.The six research questions are summarized in Table 2.Source: §4.1 · p. 7
  • RQ1 asks which O-RAN loop can host each interpreter within its latency budget and how placement changes SLA violation after an intent change.Source: §4.1 · p. 7
  • RQ2 tests whether interpretation latency affects SLA violation across intent rates and UE speeds, and examines handover and cell-edge throughput.Source: §4.1 · p. 7
  • RQ3 examines how intent load and a larger UE population affect policy-enforcement time and resulting SLA violation.Source: §4.1 · p. 7
  • RQ4 tests how interpretation accuracy changes with the size and quality of KPM telemetry needed to determine the correct policy.Source: §4.1 · p. 7
  • RQ5 compares a policy interpreted once and enforced by a numerical xApp with an interpreter choosing per-cell controls at every step.Source: §4.1 · p. 7
  • RQ6 measures how delay on a real A1/E2 control path divides among interpretation, policy transfer, and E2 control.Source: §4.1 · p. 7
  • Interpretation cases are paired across interpreters, while each simulation run fixes its design point, intent stream, and radio realization; arms vary only policy and enforcement time.Interpretation accuracy and radio outcomes use separate measurement units, so accuracy differences do not enter latency claims.Source: §4.1 · p. 7

4.2. The RANIntent v1 Benchmark

RANIntent v1 pairs fixed intent-label tuples with generated text, retaining only cases that pass blind field-by-field verification. Its controlled conditions vary telemetry size and quality while defining how interpreters should read each table.

4.2. The RANIntent v1 Benchmark

  • RANIntent v1 fixes each case’s label tuple before generating its text, then retains only cases a blind, roster-external verifier labels correctly on every field.Gemini-3.8-Flash generates the text; accepted cases from fallback Claude-Opus-5.5 are reported separately. Lint checks also reject prohibited identifiers, out-of-range lengths, and repeated openings or 5-grams.Source: §4.2 · p. 7
  • Texts span six wording families; half come from operators and half from four tenants, each owning a subset of the eight traffic classes.The families range from operator tickets and operations-center chat to exposure-API notes and voice-assistant utterances.Source: §4.2 · p. 7
  • The 16 conditions cross four telemetry sizes with fresh, stale, noisy, and contradictory tables; each has 300 test and 60 development cases, yielding 4,800 test cases per interpreter.Tests split evenly between state-dependent and named-scope cases; named-scope tests from the 21-cell fresh condition supply simulation and real-stack intents.Source: §4.2 · p. 7
  • A fixed 57-cell universe keeps each state-dependent target cluster unchanged across telemetry sizes, so only the amount of telemetry to read grows.Every telemetry table includes two extreme cells in different clusters; the intent metric’s extreme lies in the target cluster and other cells trail by a fixed margin.Source: §4.2 · p. 7
  • Reading rules define fresh rows as network state, ignore stale rows older than 10 s, and resolve contradictions by prioritizing E2 KPM over O1 reports.Noise bounds cannot change scope under the construction margin; stale and contradictory tables add a row per cell, with 0.8 probability of a decoy outside the target cluster whose value beats the true extreme.Source: §4.2 · p. 7

4.3. Interpreters and Serving

The section defines a controlled comparison of decision models and LLMs for intent interpretation, then documents how hosted and self-hosted interpreters are served.

4.3. Interpreters and Serving

  • The comparison includes three decision models, three hosted LLMs, and a Qwen3.5-4B-JSON reference that separates generation from readout at fixed weights and deployment.The decision models are Jev-1.13.0, SemIf-Qwen3.5-4B, and AnyJev from Nokia Applied Research; the hosted LLMs are DeepSeek-V4.1-Flash, GLM-5.3-Flash, and Qwen3.8-Flash.Source: §4.3 · pp. 7–8
  • Every interpreter receives the same intent, telemetry, reading rules, and policy fields; outputs are validated against the A1 policy schema, with each case answered once.Source: §4.3 · p. 8
  • Hosted calls use pinned providers, strict JSON-schema output at temperature zero, disabled reasoning where possible, 30-second timeouts, and interleaved seeded case order.GLM-5.3-Flash runs reasoning at the minimal setting because it cannot be disabled; latency is reported with and without client-measured provider round-trip time.Source: §4.3 · p. 8
  • Self-hosted interpreters run separately, one at a time, on one NVIDIA H100 NVL GPU, using a reference server or vLLM configurations.AnyJev uses vLLM with prefix caching and processed log-probabilities, reads each field at L0, and costs 57 prefills per intent; serving versions accompany reported latency.Source: §4.3 · p. 8

4.4. Radio Simulation and Control Loop

The section specifies an ns-3/5G-LENA radio simulation and an O-RAN-aligned policy-control loop in which scheduler weights are actuated while interpretation latency elapses. It also defines the traffic, timing, and matched-radio-run conditions used for evaluation.

4.4. Radio Simulation and Control Loop

  • 21 radio cells model a 7-site, 3-sector urban macro layout with a shared 10 MHz carrier at 4 GHz.Each cell starts with 5 UEs; the RQ3 scale level uses 20 per cell. UEs attach to the closest gNB and move at the design speed, while shadowing is disabled because its redraw frequency would vary with scheduled transmissions.Source: §4.4 · p. 8
  • Four downlink QoS classes emulate slices and map the eight RANIntent classes; scheduler weight is the only simulated actuator.The pilot calibrates each class’s offered load, throughput floor θk, and 95th-percentile delay target Dk. 5G-LENA v5.1 does not support QoS-flow or 5QI changes during a run, so other policy fields are scored only in the interpretation layer.Source: §4.4 · p. 9
  • Each policy sets priority bases to 10, 30, 50, or 70; an E2 update installs them, then the numerical xApp adjusts β by 2 each second based on target misses or 10%-above-target readings.β remains within ±10 of the active policy’s base and within 1–99, and a new policy resets it. In a two-UE check, a priority change shifts the throughput split from 50/50 to 90/10 within 100 ms.Source: §4.4 · p. 9
  • E2 enforcement uses δE2 = 5 ms, while the hosted-interpreter median A1 acknowledgement of 4.3 ms yields δA1 = 9.3 ms in modes P-T and E.Each enforcement is a scheduled event, and the simulation continues while interpreter latency elapses; mode X differs from mode E only by δA1 and is characterized by near-RT feasibility ϕ.Source: §4.4 · p. 9
  • Each design point uses 100 intent events, with run length max(100/λ, 100 s) and a 10 s tail after the final event.The 100 s floor provides ten 10 s blocks, and disjoint RNG stream assignments give every arm of a design point the same radio realization.Source: §4.4 · p. 9

4.5. Interpreter Arms and Controls

The section separates interpreter latency from policy accuracy using three arms, then uses independent controls to validate design points before confirmatory analysis. It also specifies live-trace workloads and how direct-control latency is charged in simulated time.

4.5. Interpreter Arms and Controls

  • The three arms isolate latency, accuracy, and net effects by applying true or recorded policies at distinct delays.L applies the true policy after measured interpreter latency plus mode path delays; A applies the recorded policy after δE2 alone; N applies the recorded policy after measured latency. N−L is the accuracy cost at the interpreter's latency, while N−A is the latency cost at its accuracy.Source: §4.5 · pp. 9–10
  • For RQ3, each interpreter processes 300-intent traces at λ ∈{0.1, 0.5, 1, 2} intents/s through four interpretation slots and an unbounded FIFO queue.For RQ5 direct control, simulation exports a throughput, delay, and PRB-share snapshot every 1 s of simulated time; the interpreter's per-cell class priorities take effect at snapshot time plus measured latency, charging that latency in simulated time.Source: §4.5 · p. 10
  • The oracle, fixed-latency, and no-update controls support four eligibility checks before confirmatory analysis.C-1 requires a resolved positive, intent-direction-signed difference in affected-class SLA violation at W = 2 s between no-update and oracle; C-2 requires resolved greater violation at ℓfix = 5 s than at 0.1 s, with point estimates non-decreasing across the three latencies. C-3 requires stale-policy exposure Sj at the lowest rate to grow linearly with ℓfix, with slope within ±10% of mean UEs in scope; C-4 requires byte-identical UE positions and traffic arrivals in oracle and no-update. The pre-registered network-wide 5 percentage-point C-1 margin was shifted to the affected class and then removed as operationally meaningless.Source: §4.5 · p. 10
  • A base-point pilot calibrates loads and class targets until C-1 and C-2 pass, and fixes its values before interpreter arms run.The pilot also measures SLA-series autocorrelation time; failing design points are recalibrated during the pilot or reported as ineligible after main runs, and eligibility never depends on an interpreter arm.Source: §4.5 · p. 10

4.6. Real-Stack Validation

The real-stack validation demonstrated that an interpreter’s A1 policy could drive slice-level PRB-quota control through an open-source 5G stack. It validates the control path at small scale, not the radio trends observed in simulation.

4.6. Real-Stack Validation

  • The real stack validated bidirectional PRB-quota control, with δE2 of 2.5–6.9 ms and first KPM change 1.25–1.88 s serving only as an actuation upper bound.The Docker stack used srsRAN, srsUE, Open5GS, the OSC near-RT RIC and A1 simulator, and an xApp mapping A1 policies to E2SM-RC controls. It served one cell; the first KPM change interval also includes scheduler convergence, the KPM window, and TCP ramp-up.Source: §4.6 · p. 10

4.7. Metrics

Section 4.7 defines a layered measurement framework combining interpreter quality, latency, feasibility and cost with radio SLA, control-loop and queue metrics. It also specifies the rules used to compute radio outcomes.

4.7. Metrics

  • Interpreter quality is measured by field, actuated-vector, full-policy, and state-dependent target-cluster accuracy, schema validity, unsafe-policy rate, latency percentiles, near-RT feasibility, and cost.Latency is reported at p50, p95, and p99, retaining the slowest responses. Costs include tokens per decision and API fees per 1,000 correct policies; self-hosted interpreters have no API fee, and energy is integrated from GPU power traces.Source: §4.7 · p. 10
  • Radio and control-loop evaluation centers SLA violation by affected-class and network-wide shares at W = 2 s, with other windows and policy lifetime secondary.It also reports intent-to-enforcement time, stale-policy exposure, and collateral exposure in the A and N arms for other-class UEs or scopes affected by a wrong policy.Source: §4.7 · pp. 10–11
  • RQ3 also reports queue wait, utilization η of four interpretation slots, and intents enforced within 1 s; runs with η ≥1 are non-stationary and receive no interval.Two of the 28 load traces reach this condition.Source: §4.7 · p. 11
  • Radio computations treat best-effort UEs as targetless non-misses, define XR misses by delay or packet absence, and assign windows by slot-end time.Two intents share a target only when mapped traffic class and exact scope match; delay percentiles and jitter are packet-weighted over per-slot values, and outage is reported by class.Source: §4.7 · p. 11

4.8. Statistical Analysis

The analysis fixed H1–H3 and eligibility controls before outcomes were examined, then used paired resampling suited to case-level interpreter comparisons and dependent simulation events. It also distinguishes confirmatory tests from descriptive and exploratory analyses, and requires simulation contrasts to be resolved under two block lengths.

4.8. Statistical Analysis

  • Interpretation contrasts paired each case across interpreters and used 10,000 bootstrap resamples; each simulation design point and arm had one run with a single RNG run number.The hypotheses, decision rules, and eligibility controls were fixed before runs, and the C-1 rule was revised twice before interpreter-arm outcomes were examined.Source: §4.8 · p. 11
  • Simulation outcomes used paired time-block bootstraps because events within a run share radio state, queues, and policies; real-stack results were descriptive over 30 intents per interpreter.All arms at a design point shared block boundaries because their RNG streams were pinned; real-stack summaries report each control-path component’s median and range.Source: §4.8 · p. 11
  • Simulation contrasts counted as resolved only under both block lengths: B = max(10 s, τ) and registered 10 s blocks.At the base point, τ = 48.8 s produced 7 blocks; the main runs measured τ because 60 s pilots were too short to resolve it, and every design point reports its block count.Source: §4.8 · p. 11
  • The event-ordering check tested six arms under three scheduler-event reorderings and flagged contrasts whose sign changed or whose range exceeded the main-run estimate.The check used four realizations per arm, reported the range of C-1 and affected-class H1 contrasts, and kept these realizations outside bootstrap intervals; flagged contrasts were not confirmatory findings.Source: §4.8 · p. 11
  • A contrast was resolved when its 95% bootstrap interval excluded zero and its Holm-adjusted p value was below 0.05; exploratory contrasts required only an interval excluding zero.H1 required resolved comparator increases in both affected-class and network-wide SLA violation; H2 required at least 5 of 9 eligible design points, with the affected-class gap resolved at 80% or more and no resolved reversal. H3 required resolved target-cluster accuracy to be higher at 3 than 57 cells, pairing 150 state-dependent cases by shared tuple.Source: §4.8 · p. 11
  • H1–H3 were confirmatory, while near-RT feasibility, latency, cost, and RQ6 path decomposition were descriptive; other listed analyses were exploratory.Exploratory analyses included mode crossover, UE-speed interaction, N/A/L decomposition, RQ3 load curves, stale/noisy/contradictory RQ4 conditions, energy per decision, and recurring-intent policy reuse; protocol departures were recorded before affected analyses.Source: §4.8 · p. 12

5. Results

At the base point, oracle enforcement shifts affected-class SLA violation in the requested direction, but hosted LLMs show no resolved increase over Jev-1.13.0. Across load, telemetry, and real-stack tests, interpreter latency and telemetry quality constrain operation, while direct control yields no resolved SLA reduction over numerical-xApp enforcement.

5.1. RQ1: Loop Placement and RIC Timescales

  • 3.96 pp is the resolved shift in affected-class SLA violation at W = 2 s when the true policy is enforced immediately rather than never updated.The shift is in the direction each intent requests; the event-ordering check places C-1 between 3.24 and 3.96 pp. No hosted-LLM contrast against Jev-1.13.0 is resolved under both block lengths, and hosted contrasts are event-ordering-sensitive.Source: §5.1 · p. 12, Figure 3 · p. 13, Table 7 · p. 13

5.2. RQ2: Radio Conditions

  • 3 of 9 design points pass the C-1 and C-2 eligibility requirements, below the 5 required to test H2.The latency sweep is monotone at all nine points and resolved at eight, while oracle headroom is resolved at four; at the three eligible points, GLM-5.3-Flash and Qwen3.8-Flash each show one resolved increase over Jev-1.13.0.Source: §5.2 · p. 12, Table 8 · p. 14, Figure 5 · p. 18

5.3. RQ3: Load and Scale

  • At 2 intents/s, AnyJev-L0 and Qwen3.8-Flash saturate with η = 1.17 and 1.09, respectively, while Jev-1.13.0 enforces 0.997–1.000 of intents within 1 s from 0.1 to 2 intents/s.At 2 intents/s, the saturated interpreters have p95 queue waits of 34.5 s and 20.3 s; their cells are non-stationary. Replaying load traces in the radio network places interpreters within 3.7 pp of network-wide SLA violation, with intervals overlapping at 0.5 and 1 intent/s and among the five stationary interpreters at 2 intents/s.Source: §5.3 · pp. 12–14, Table 11 · p. 16, Figure 6 · p. 18

5.4. RQ4: Telemetry-Grounded Interpretation

  • 0.093, 0.113, 0.107, and 0.313 are the accuracy decreases from 3 to 57 cells for Jev-1.13.0, Qwen3.8-Flash, SemIf-Qwen3.5-4B, and AnyJev-L0 under fresh telemetry.DeepSeek-V4.1-Flash and GLM-5.3-Flash remain near ceiling at both telemetry sizes. At 57 cells, Jev-1.13.0 is the least expensive hosted interpreter at 0.207 USD per 1,000 correct policies; hosted interpreters cost 0.108–0.270 USD at three cells and 0.207–0.559 USD at 57 cells.Source: §5.4 · pp. 14, 17, Table 12 · p. 17, Table 13 · p. 19

5.5. RQ5: Division of Labor

  • None of the 28 direct-control differences is a resolved SLA decrease relative to the same interpreter’s numerical-xApp policy enforcement.Five differences are resolved increases; against the oracle, every network-wide difference lies between −0.34 and +0.54 pp and is unresolved. Throughput and fairness findings are single-run point estimates.Source: §5.5 · pp. 17–18

5.6. RQ6: Real-Stack Control Path

  • 0.286–2.35 s is the range of median interpreter decision latency on the real stack, compared with 15.5–19.1 ms for A1 and 2.4–3.1 ms for E2.The interpreter takes more time than both protocol components for every row. The KPM-observed median upper bound is 1.247–1.455 s and also includes scheduler convergence, the KPM window, and TCP ramp-up.Source: §5.6 · p. 18, Figure 8 · p. 19

6. Discussion

Interpreter choice for RAN control should account for latency tails, queueing, and accuracy on the telemetry it will receive—not accuracy alone. The discussion finds no resolved general radio penalty from slower interpreters at the base point, while emphasizing limits on how broadly the results can be generalized.

6.1. Implications for RAN Control

  • Across 16 telemetry conditions, hosted Jev-1.13.0 achieved ϕ = 0.998, while hosted GLM-5.3-Flash and Qwen3.8-Flash achieved ϕ = 0.179 and 0.Hosted Jev-1.13.0 had p95 and p99 latencies of 0.371 and 0.472 s; Qwen3.8-Flash had a p95 of 6.37 s. Self-hosted Qwen3.5-4B-JSON and SemIf-Qwen3.5-4B achieved ϕ = 1.000 and 0.999, with p99 latencies of 0.585 and 0.821 s, respectively. Median decision latency across interpreters was 0.286–2.35 s, compared with median δA1 of 15.5–19.1 ms and median δE2 of 2.4–3.1 ms.Source: §6.1 · p. 19
  • At 2 intents/s, Jev-1.13.0 kept four-slot utilization η at or below 0.149, while AnyJev-L0 and Qwen3.8-Flash exceeded η = 1.Their p95 queue waits reached 34.5 and 20.3 s, respectively. Sending every KPM row increased grounding burden for four interpreters; selecting intent-relevant cells or pre-aggregating KPMs can reduce it.Source: §6.1 · p. 19

6.2. Choosing and Evaluating an Interpreter

  • At 57 cells under fresh telemetry, GLM-5.3-Flash accuracy was 0.967 and Qwen3.8-Flash accuracy was 0.880, but their near-RT feasibility was 0.179 and 0.From three to 57 cells, Jev-1.13.0 lost 0.093 in accuracy and Qwen3.8-Flash lost 0.113; the 0.020 and 0.027 decreases for DeepSeek-V4.1-Flash and GLM-5.3-Flash did not resolve at Holm-adjusted p = 0.184. Under contradictory telemetry, GLM-5.3-Flash accuracy was 0.853, versus 0.633 for Jev-1.13.0 and 0.620 for Qwen3.8-Flash.Source: §6.2 · pp. 19, 21
  • At 57 cells, AnyJev’s conversion of shared 4B weights reached 0.280 accuracy, while generative Qwen3.5-4B-JSON reached 0.287.Their median latencies were 0.425 and 0.419 s, respectively. Every interpreter returned schema-valid policies at 57 cells under fresh telemetry, with observed errors being semantic; Jev-1.13.0’s accuracy therefore cannot be attributed to a typed interface alone.Source: §6.2 · pp. 19–20
  • At the base point, delaying enforcement from 0.1 to 5 s raised affected-class SLA violation by 3.93 pp, but interpreter differences were not resolved in both SLA metrics.The slower interpreters showed no resolved general radio penalty in the 21-cell network, and direct control gave no resolved SLA reduction over the division of labor using a numerical xApp.Source: §6.2 · pp. 20–21

6.3. Limitations

  • Radio comparisons are conditional on one common-random-number realization per design point, and hosted-LLM event-ordering ranges exceeded their main-run estimates.The simulator used priority weights while the real stack used an E2SM-RC PRB quota; hosted latency included the Sydney client WAN path and provider load. The benchmark was synthetic, and under the amended C-1 rule no design point met the pre-registered 5 pp margin, leaving H1 and H2 untestable.Source: §6.3 · p. 21

7. Conclusion

The conclusion finds that interpretation latency determines which RIC loop can host an interpreter, while no general radio penalty from slow interpreters was resolved at the base point. Jev-1.13.0 reliably meets the near-RT budget, but its accuracy falls as table size grows, motivating telemetry selection.

7. Conclusion

  • Up to 17 pp, UE speed and intent rate move affected-class SLA violation; at the base point, ideal enforcement moves it about 4 pp in the requested direction.At that base point, no slower hosted LLM showed a resolved SLA increase over Jev-1.13.0.Source: §7 · p. 21
  • 0.286 to 2.35 s is the median interpretation time, versus under 25 ms for median A1 transfer and E2 control combined.The conclusion states that decision time determines which RIC loop an interpreter can run in.Source: §7 · p. 21
  • 99.8% of calls meet the 1 s near-RT budget for Jev-1.13.0, which uses at most 14.9% of its slots at 2 intents/s.By contrast, slow interpreters miss the 1 s budget, and Qwen3.8-Flash and AnyJev-L0 saturate their interpretation slots at 2 intents/s.Source: §7 · p. 21
  • 17.9% of all calls meet the near-RT budget for GLM-5.3-Flash.On fresh 57-cell tables, GLM-5.3-Flash reaches 0.967 against 0.907 for Jev-1.13.0, although the paired difference is not resolved.Source: §7 · p. 21
  • 0.093 is the Jev-1.13.0 accuracy fall from 3 to 57 cells, making telemetry selection the next step.The conclusion identifies selecting the telemetry an interpreter receives as future work.Source: §7 · p. 21
  • At the base point, per-second direct control gave no resolved SLA reduction over a numerical xApp.A general radio penalty of slow interpreters was also not resolved.Source: §7 · p. 21

Related papers

Loading 2609.23136v2…