{"id":"f5c1c3bb-4727-4986-aabc-7bd4761b65ea","arxiv_id":"2510.05255","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":12,"one_line_summary":"A 0.70M-parameter multi-scale state-space mixture predicts next-step RSRP on an O-RAN testbed with RMSE 0.29 dB and R2=0.993, running 3-10x faster than the tested Transformers.","lead":"This paper proposes MS3M, a compact neural forecaster that predicts the next radio KPI (RSRP) using mixed multi-scale state-space filters instead of attention. On a custom O-RAN testbed it reports accuracy close to Transformer baselines while running 3-10x faster with only 0.70M parameters.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The 0.057 s 'per-inference' latency claim conflicts with the stated measurement protocol ('a single forward pass over the test tail'), making the central latency/speedup claim not yet well-defined.","rationale":"The reader's weakest assumption was that the untuned Transformer baselines are a fair proxy, and that concern is legitimate. However, it is partly mitigated by the fact that MS3M also outperforms FEDformer, Informer, TFT, and ETSformer on accuracy, and only Crossformer is better on RMSE; even if PatchTST/iTransformer are repaired, the 'competitive accuracy' claim might survive. The latency-definition conflict is more load-bearing because the 0.057 s per-inference figure is the paper's headline engineering contribution and is stated unambiguously in the abstract and C3, while §IV-F describes a different measurement ('single forward pass over the test tail'). This ambiguity contaminates the speedup ratios, which are all derived from the same ill-defined latency column. The Nseq=28 vs W=32 discrepancy and the suspicious ETSformer parameter count (10,376) are additional reproducibility red flags, but the latency semantics is the single most decisive issue for the central claim. The paper has real independent strengths—the stability proof is self-contained, the leakage-safe pipeline is carefully described, and the code is released—so the appropriate disposition remains conditional rather than rejection: the authors need to clarify and re-measure the latency figure.","tokens_in":20653,"tokens_out":12137,"duration_ms":95155,"concrete_test":"Run the released inference script on the same hardware under two conditions: (1) measure median single-window latency over 1000 forward passes after warm-up (no batching), and (2) measure wall-clock for one batched forward over the entire test tail. Compare both to the reported 0.057 s in Table III. If 0.057 s equals the total batched time, recompute per-inference latency and re-derive all speedups; if the single-window latency is materially higher than 0.057 s, the Near-RT RIC latency claim must be revised. Report batch size, device (CPU/GPU), and whether the released timing script uses the same protocol.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central quantitative claim is the 0.057 s 'per-inference' latency and the resulting 3–10× speedup over Transformers (abstract, C3, Table III). But the measurement definition in §IV-F contradicts the label: 'reported inference latency is for a single forward pass over the contiguous test tail (data already in memory), after a short warm-up.' If 0.057 s is the total wall-clock for the whole test tail of ~59k windows processed as one batch, then it is a throughput number, not a per-inference latency; a single online inference request in an xApp would include per-sample kernel launches, data movement, and possibly CPU/GPU transfer, and could be far larger. If 0.057 s is instead meant to be one window, then 'over the test tail' is the wrong protocol, and the value is implausibly high for a 0.7M-parameter depthwise-convolutional model on a 32×13 input, suggesting a different batching or overhead regime. Every speedup ratio in Table III is computed from these ambiguous latency values, so the '3–10× lower latency' headline—the main O-RAN readiness argument—cannot be verified as stated. This is independent of baseline tuning: even if the Transformer baselines are fairly configured, the latency number itself is not well-defined.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"MS3M is a lightweight multi-scale structured state-space forecaster for one-step-ahead RSRP prediction in O-RAN. It mixes HiPPO-LegS kernels with Tustin discretization, per-channel depthwise convolutions, Squeeze-and-Excitation gating, and a GLU channel mixer. The paper contributes a stability proposition (Schur stability under bilinear discretization), a leakage-safe training protocol, a bespoke testbed dataset (59,441 windows, 13 KPIs), and a comparison against seven Transformer baselines. Headline claims are 0.057 s per-inference latency with ~0.70M parameters, 3.4–10.3× lower latency than baselines, and RMSE 0.292 dB, MAE 0.170 dB, R2 = 0.993 on the test tail.","tokens_in":21012,"tokens_out":6066,"duration_ms":48106,"significance":"If the empirical claims hold, MS3M would be a practical contribution for near-RT RIC analytics: it combines a provably stable SSM construction with a compact, causal architecture and a carefully specified leakage-safe evaluation protocol. The paper includes a self-contained proof (Prop. 1) and releases source code, which strengthens reproducibility; the diagnostics (bootstrap CIs, residual analysis, permutation importance) are unusually thorough. The skeptical concern about circularity does not, on reading, land: the stability proof is independent, and the leakage-safe pipeline is standard supervised learning. However, the central latency/speedup claim is not well-defined as written, and the baseline tuning protocol may understate Transformer performance; the significance therefore hinges on these points being resolved.","major_comments":[{"comment":"The headline latency number is not well-defined. §IV-F states 'inference time is for a single forward pass over the contiguous test tail (data already in memory), after a short warm-up.' The Abstract and C3 report '0.057 s per-inference latency.' If the test tail is processed as one batch, 0.057 s is aggregate batch time, not per-inference latency; with a 15% test split of 59,441 windows (~8,900 windows), per-window latency would be ~6 µs, which is implausible for a 0.7M-parameter model. If 0.057 s is a single window, the stated protocol is wrong. Because every speedup ratio in Table III is computed from these values, the central O-RAN readiness claim (C3) cannot be verified. Please report the test-tail size, batching, hardware, and separate per-window/request latency.","section":"Section IV-F vs. Abstract/Table III"},{"comment":"Baseline tuning undermines the 'rivaling Transformers' claim. All baselines share one hyperparameter set (Adam LR=2e-3, batch 256, max 60 epochs, patience 20) with no per-model sweeps, while MS3M is selected via ablations (Section V). PatchTST and iTransformer achieve only +15.3% and +10.0% RMSE skill over persistence (RMSE 3.197 and 3.396 vs persistence ~3.78), suggesting these baselines are far from their achievable performance on this task. Since the accuracy comparison is a central claim, the paper should either tune each baseline (or use each method's published recommended hyperparameters) and report MS3M's validation-based selection; otherwise the claimed superiority may be an artifact of under-tuned baselines.","section":"Sections IV-C/IV-D/IV-G"}],"minor_comments":[{"comment":"RMSE/MAE values differ between Table V (0.290/0.169) and Table III (0.292/0.170). Please reconcile or clarify the source of the discrepancy.","section":"Table V vs Table III"},{"comment":"Section III uses Nseq=28 for sequential samples, while Section IV-B and Table III state W=32 for all models. Clarify the actual window length used in the experiments.","section":"Section III vs Section IV-B"},{"comment":"The MS3M row 'drop 0.12×10−3/20' is ambiguous; specify dropout, learning rate, and patience separately to match the other baseline rows.","section":"Table IV"}],"recommendation":"major_revision","confidential_remarks":"The core technical contribution—a stable, leakage-safe SSM forecaster—is sound and well presented. The main risk is empirical: the latency definition is ambiguous, and the baseline hyperparameter protocol is likely unfair to the Transformers. Both issues are fixable within the manuscript's scope. I would encourage the editor to request a revision that clarifies the inference measurement and strengthens the baseline tuning before acceptance."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nThe thing to know: this is an honest, useful engineering paper that overclaims one number. The model — a multi-scale mixture of HiPPO-LegS kernels via Tustin discretization, with SE gating and GLU mixing — is a sensible lightweight sequence forecaster. The stability proposition is clean: Hurwitz A maps to Schur-stable A(Δt) under the bilinear transform, and the exponential kernel decay bound follows. The leakage-safe pipeline (train-only scalers, shifted covariates, contiguous tail splits) is correctly described and the code and data are public. That's real value.\n\nThe accuracy results are plausible and competitive: RMSE 0.292 dB, R² 0.993 on the test tail, with bootstrap CIs. Crossformer edges it on raw error but at 10x the latency, so the Pareto claim is fine.\n\nNow the soft spots, in order of size.\n\nFirst, the \"0.057 s per-inference latency\" is not what the protocol measures. §IV-F says inference time is \"a single forward pass over the contiguous test tail.\" That's batch throughput across ~59k windows, not a per-inference latency. For a single xApp inference you'd pay kernel launch and data movement overhead; the real per-query number could be an order of magnitude higher. All the speedup ratios in Table III inherit this ambiguity. This is a load-bearing issue for the O-RAN readiness headline, and it needs fixing before the claim is accepted as stated.\n\nSecond, the Transformer baseline comparison is weaker than the abstract suggests. One shared hyperparameter set, no per-model sweeps, and PatchTST/iTransformer land at RMSE ~3.2-3.4, barely above persistence. That's a strong hint those models are misconfigured for one-step-ahead with a 32-step lookback. The paper does disclose this in §IV-G as \"conservative,\" but the \"rivaling Transformers\" framing is more confident than the evidence supports.\n\nThird, a smaller inconsistency: the data section says Nseq=28, the baseline section uses W=32, and Table III says W/H=32/1 for everyone. It's probably a leftover, but it makes the exact input length unclear. Minor, but annoying for reproduction.\n\nBottom line: the architecture is sound, the proof is fine, and the leakage-safe methodology is a model for this subfield. The paper deserves a serious referee; the fixes are a rewritten latency section, a tempered or better-supported baseline comparison, and reconciling the window length. I'd take it in its current form only with those revisions.\n\nRecommendation: send to peer review — it will survive contact, and the reviewer feedback will improve the claims.","headline":"Solid engineering paper with a real stability proof and a careful data pipeline, but the headline 0.057 s 'per-inference' latency is actually a batched throughput number, and the Transformer baselines look undertuned.","tokens_in":21528,"tokens_out":2906,"would_cite":true,"duration_ms":22648,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper claims that a multi-scale structured state-space forecaster, MS3M, can match Transformer-level accuracy for next-step RSRP prediction while running 3–10x faster, making it suitable for near-real-time O-RAN control loops.","keywords":["state-space models","time-series forecasting","KPI prediction","O-RAN","RIC","HiPPO-LegS","latency-efficient inference","RSRP"],"falsifier":"Run PatchTST and iTransformer on the same leakage-safe W=32, H=1 RSRP task with per-model hyperparameter sweeps, and check whether either drops below MS3M's 0.292 dB RMSE or closes the 0.057 s latency gap; then measure MS3M's latency on an actual near-RT RIC platform with E2-interface traffic in the loop, since the reported 0.057 s is a single forward pass without I/O.","tokens_in":20539,"feed_emoji":"📡","tokens_out":7671,"duration_ms":57147,"temperature":0.7,"pith_summary":"MS3M is a forecaster built from multi-scale structured state-space kernels: it takes a window of multivariate radio KPIs, embeds them, applies per-channel causal convolutions whose taps come from bilinear-discretized HiPPO-LegS dynamics at several learned time scales, and mixes channels with squeeze-and-excitation gating and a gated linear unit. The paper's central claim is that this design gives Transformer-competitive accuracy for next-step RSRP prediction—RMSE 0.292 dB, MAE 0.170 dB, R2 0.993 on a 59,441-window O-RAN testbed dataset—while running in 0.057 s per inference with ~0.70M parameters, 3–10x faster than the tested Transformers on the same hardware. The reason this matters is that near-real-time RIC loops have tight latency and memory budgets, and attention-based models with quadratic cost and large footprints are hard to fit there; a stable, linear-time forecaster makes control-grade prediction practical inside an xApp. The paper also formalizes a leakage-safe training pipeline (past-only covariates, chronological splits, train-only standardization) that is reusable for fair benchmarking.","feed_headline":"0.057s per inference: state-space forecaster rivals Transformers","feed_subtitle":"A 0.70M-parameter multi-scale SSM predicts next-step RSRP at R2 = 0.993, fitting near-real-time 6G O-RAN control loops.","key_machinery":"The load-bearing object is the MS3M layer: a depthwise causal convolution whose finite impulse response is constructed from a Tustin-discretized HiPPO-LegS state-space model. HiPPO-LegS is a continuous-time memory operator that optimally projects the history of an input onto Legendre polynomials; bilinear (Tustin) discretization turns it into a discrete transition that is Schur-stable whenever the continuous operator is Hurwitz, so every kernel decays geometrically and finite truncation is bounded. Summing M such kernels with learned step sizes creates a multi-scale dictionary of fading-memory filters, giving O(L) sequence mixing per layer. Squeeze-and-excitation gating and a gated linear un","core_discovery":"On its own terms, MS3M is a strict-causal sequence model that approximates fading-memory radio dynamics by summing stable exponentials: the HiPPO-LegS continuous-time operator is discretized with the bilinear (Tustin) transform, which maps a Hurwitz A to a Schur-stable discrete transition for any positive step size, and the resulting impulse responses are used directly as depthwise causal convolution kernels. A mixture of M such kernels with learned per-component step sizes captures fast and slow dynamics within one receptive field; squeeze-and-excitation gating reweights channels, and a compact GLU layer models cross-feature nonlinearities. The paper reports that on the test tail this model","pith_inferences":["The 3–10x latency advantage is measured against Transformers run with one shared, untuned hyperparameter set; per-model tuning, especially for PatchTST and iTransformer on this specific W=32/H=1 task, could narrow the accuracy gap, though the linear-time complexity advantage would remain.","Since the architecture is KPI-agnostic, the same kernel-mixing recipe could be extended to multi-horizon and probabilistic forecasting (the paper tests only one-step point forecasts); a distributional head or conformal wrapper would be a direct next step.","The SSM core is channel-independent, so cross-UE and inter-cell couplings (handover graphs, interference, PRB contention) are not modeled; injecting such structure is the most plausible route to better extrapolation in dense mobility.","The paper stops at open-loop forecasting; the end-to-end claim that these predictions improve closed-loop RIC policies remains untested, and a real xApp integration on a near-RT RIC platform would be the decisive validation."],"forward_implications":["Near-real-time RIC xApps can run per-UE RSRP forecasts at 0.057 s per inference while leaving most of the near-RT latency budget for control decisions.","The accuracy–efficiency Pareto result implies that one-step KPI forecasting does not require self-attention; a linear-time state-space mixer suffices on this task class.","Stability is guaranteed by construction: bilinear discretization of a Hurwitz operator yields Schur-stable transitions, so bounded inputs produce bounded outputs and truncation error decays geometrically.","The leakage-safe pipeline (past-only covariates, chronological tail splits, train-only standardization) is a reusable protocol that prevents optimistic bias in O-RAN KPI benchmarks.","With ~0.70M parameters and O(L) inference, the model fits memory-constrained near-RT and edge deployments where Transformers' activation footprint is prohibitive."],"fun_headline_variants":["State-space mixture rivals Transformers at 10x lower latency","0.7M-param SSM predicts RSRP in 57ms, matches Transformers","3-10x faster than Transformers: SSM forecaster for 6G","Multi-scale SSM: 0.7M params, 57ms inference for 6G O-RAN"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The load-bearing premise is that the Transformer baselines' fixed, untuned hyperparameter configuration is a fair proxy for their realistic performance on this one-step-ahead task; the 'rivaling Transformers' accuracy comparison depends on that premise.","fun_headline_variants_meta":{"raw":{"variants":["State-space mixture rivals Transformers at 10x lower latency","0.7M-param SSM predicts RSRP in 57ms, matches Transformers","3-10x faster than Transformers: SSM forecaster for 6G","Multi-scale SSM: 0.7M params, 57ms inference for 6G O-RAN"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.001065,"raw_usage":{"total_tokens":4387,"prompt_tokens":916,"completion_tokens":3471,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":660,"completion_tokens_details":{"reasoning_tokens":3376}},"tokens_in":660,"tokens_out":3471,"duration_ms":18485,"temperature":1.0,"reasoning_tokens":3376,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-04T11:20:35.410312+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run PatchTST and iTransformer on the same leakage-safe W=32, H=1 RSRP task with per-model hyperparameter sweeps, and check whether either drops below MS3M's 0.292 dB RMSE or closes the 0.057 s latency gap; then measure MS3M's latency on an actual near-RT RIC platform with E2-interface traffic in the loop, since the reported 0.057 s is a single forward pass without I/O.","supporting_citations":[],"review_version":1}