{"id":"85424a2a-6dc9-4de7-aec4-3768ef5e15a1","arxiv_id":"2509.07242","paper_version":1,"verdict":"REJECT","confidence":"MODERATE","novelty_score":3.0,"correctness_risk":"high","formal_verification":"none","parameter_count":4,"one_line_summary":"DORA applies PPO reinforcement learning to slice-level PRB allocation in an OAI-based Open RAN testbed and reports balanced, not best-per-metric, performance versus simple baselines.","lead":"An engineering paper proposes DORA, a reinforcement learning xApp that assigns radio resource blocks to three 5G service slices (URLLC, eMBB, mMTC) in an Open RAN simulator. The authors claim it is the first fully online deep-RL slice scheduler; that claim conflicts with the paper's own method and the prior work it cites.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Reported results contradict the abstract's claim that DORA outperforms all baselines on all three slice KPIs.","rationale":"The reader's verdict of REJECT is well-founded, but the weakest assumption they identify—that the offline-trained policy generalizes to the online environment—is not the most load-bearing issue. A more direct and fatal problem is that the paper's own experimental results contradict its headline performance claims. Even if the offline-to-online transfer were perfect, the reported comparisons show DORA is not the best in any single slice: Hard Slicing has better URLLC SLA compliance, DQN has slightly better eMBB throughput, and Priority/DQN achieve better mMTC coverage. Thus, the central claim of 'outperforms' on all three KPIs is internally inconsistent with the results presented in Section VII. This is a correctness risk that does not depend on external assumptions about reproducibility or baseline strength. Additionally, the 'first fully online' claim conflicts with the paper's own pipeline description (offline pretraining) and with the cited REAL system, which is described as an online PPO xApp. These contradictions make the central claims untenable as written. The concrete test of recomputing the three KPI comparisons from the CDFs would settle whether the qualitative statements in the text are accurate; if the figures actually show DORA leading on all metrics, the rejection would be premature, but based on the textual descriptions, the claims are not supported.","tokens_in":8801,"tokens_out":2513,"duration_ms":29738,"concrete_test":"Re-analyze the data behind Figures 2–4 and compute, for each algorithm, the three headline metrics: (1) P(latency ≤ 400 ms) for URLLC, (2) median (or mean) eMBB throughput and P(throughput ≥ requested), and (3) average number of concurrently serviced mMTC devices. Then test whether DORA is strictly better than every baseline on each metric. If any baseline (e.g., Hard Slicing for URLLC, DQN for eMBB or mMTC) is statistically superior, the abstract's 'outperforms... lower URLLC latency, higher eMBB throughput... broader mMTC coverage' claim is false. Additionally, re-read Section II where REAL is described as an 'online PPO-based xApp' and compare with the abstract's 'first fully online' claim; if REAL performs online training, the novelty claim requires qualification.","verdict_should_be":"REJECT","load_bearing_attack":"The central performance claim in the abstract and introduction is that DORA 'outperforms three non-learning baselines and a DQN agent, achieving lower URLLC latency, higher eMBB throughput with fewer SLA violations, and broader mMTC coverage.' The paper's own results section contradicts this. Section VII-A states that at the 400 ms SLA threshold, 'the Hard Slicing baseline exhibits the highest probability, indicating superior compliance,' with DORA's PPO agent 'follow[ing] closely.' Section VII-B states that for eMBB throughput, the DRL agents are 'very similar, with DQN holding a slight edge.' Section VII-C states that 'the Priority-based and DQN agents achieve the best performance' in mMTC coverage, while DORA delivers only 'comparable and effective coverage.' Thus, DORA is not the best on any individual KPI; it is the most balanced. The claim of simultaneous superiority is therefore not supported by the presented evidence. Furthermore, the novelty claim of being 'fully online' is internally inconsistent: the abstract says DORA 'supports online training and adapts continuously,' but Section IV-A and IV-B describe offline pretraining using a lookup table, followed only by online evaluation. Section II even states 'training is performed offline.' This is not a matter of external consensus; the manuscript's own text and figures contradict its headline statements. The load-bearing assumption that the offline-trained policy transfers to the online environment is secondary: even if perfect transfer is assumed, the reported online results do not show DORA outperforming all baselines on all three slices.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes DORA, a PPO-based DRL framework for slice-level PRB allocation in O-RAN, targeting URLLC, eMBB, and mMTC slices. The agent allocates PRBs based on observed traffic and channel conditions, while intra-slice scheduling is deterministic round-robin. Training is performed offline with an OAI-derived throughput lookup table, followed by online evaluation in OpenAirInterface. The paper compares DORA with three non-learning baselines (Hard Slicing, Priority-based, Fair Active-User) and a DQN agent, reporting URLLC latency, eMBB throughput, and mMTC coverage. The headline claims are that DORA is the first fully online DRL framework for adaptive slice-aware PRB allocation and that it outperforms all baselines on all three slice KPIs.","tokens_in":9039,"tokens_out":3955,"duration_ms":48269,"significance":"If the claims were fully supported, DORA would be a useful contribution: an OAI-integrated, slice-level DRL xApp with a reduced-complexity scheduling interface and a comparison against multiple baselines. The paper's strengths include the use of a realistic OAI stack, explicit treatment of a 14-UE scenario, and distributional KPI reporting (CDFs). However, as detailed below, the paper's own results contradict the central superiority claim: DORA is not best on any single slice KPI, but rather a balanced compromise. In addition, the 'fully online' claim is internally inconsistent with the offline-training description. The significance of the contribution is therefore substantially weaker than the abstract and introduction suggest, though the underlying framework and experimental setup could support a revised, less overreaching narrative.","major_comments":[{"comment":"The central claim that DORA 'achieves lower URLLC latency, higher eMBB throughput with fewer SLA violations, and broader mMTC coverage' is not supported by the results. Section VII-A states that at the 400 ms SLA threshold 'the Hard Slicing baseline exhibits the highest probability,' with DORA following closely. Section VII-B says the DRL agents are 'very similar, with DQN holding a slight edge.' Section VII-C says 'the Priority-based and DQN agents achieve the best performance' for mMTC, while DORA provides only 'comparable and effective coverage.' Thus DORA is best on no individual KPI; it is the most balanced. The headline must be revised to the supported claim, and the authors should provide a quantitative multi-objective comparison (e.g., a single utility metric) if they wish to claim superiority in trade-off handling.","section":"Abstract and §VII"},{"comment":"The 'fully online' characterization is internally inconsistent. The abstract says DORA 'supports online training and adapts continuously,' and the introduction claims 'the first fully online DRL framework.' However, Section II states that 'training is performed offline,' and Section IV-A describes a hybrid pipeline with 'Offline Training' followed by 'Online Evaluation.' No online policy updates or fine-tuning are performed. This is a load-bearing inconsistency because the stated novelty depends on online training. Please clarify whether the contribution is online evaluation of an offline-trained policy, and if online training is actually supported, provide the mechanism and evidence.","section":"Abstract, §I, §II, §IV-A"},{"comment":"The offline-to-online transfer of the pretrained policy is a key unvalidated assumption. Section VI-C lists stochastic fading, measurement noise, and cross-slice contention as differences 'absent from offline approximations,' but the paper provides no evaluation of how representative the offline lookup table is, no comparison of offline vs. online reward or KPI distributions, and no online adaptation. Consequently, the reported online KPIs do not isolate the quality of the learned policy from possible lookup-table inaccuracies. An ablation (e.g., training with perturbed tables, or measuring the offline-online performance gap) is needed before the online results can be interpreted as validating the DORA agent.","section":"§VI-C"},{"comment":"The reward weights (w_U, w_E, w_M) = (0.5, 0.4, 0.1) are fixed, and Section VII-D attributes DORA's balanced behavior to these weights. The paper presents no sensitivity analysis, so the conclusion that DORA 'intelligently balances' the objectives is partly forced by construction. Also, Eq. (6) with N_serv = floor(PRB_mMTC/5) makes the mMTC reward a deterministic affine function of the allocated PRBs; 'coverage' is therefore just a relabeled PRB count, not a device-level QoS measure. These limitations should be stated, and the interpretation of Figure 4 should be adjusted accordingly.","section":"Eq. (3)–(6), §IV-C, §VII-D"}],"minor_comments":[{"comment":"There are several typos and spacing errors, e.g., 'aDQNagent' in the abstract and 'aDQN agent' in Section VII. Please proofread the text.","section":"Throughout"},{"comment":"The paper claims 'standards-compliant' integration but then says DORA uses a Python-based 'E2-like' control architecture with memory-mapped files, not full E2AP. This should be clarified: is the implementation E2-compliant or only E2-inspired? The wording in the abstract and introduction may overstate compliance.","section":"§IV-A"},{"comment":"The paper states DORA supports 'fully online evaluation with up to four software-based UEs running in parallel' while also describing a 14-UE scenario. Table I's 'Online' column is ambiguous. Please specify what 'online' means in each context (training vs. evaluation vs. UE concurrency).","section":"§I and Table I"}],"recommendation":"major_revision","confidential_remarks":"The paper has a solid systems component and could be salvaged by rewriting the central claims to match the results (balanced trade-off rather than universal superiority), resolving the offline/online inconsistency, and adding a transfer-gap analysis. I therefore recommend major revision rather than rejection, though the current version's headline statements are not supported by the evidence."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Two things to know before you read this one. The abstract claims DORA is the first fully online DRL framework for slice-aware PRB allocation in O-RAN and that it outperforms three baselines plus DQN on all three slice KPIs. Neither claim survives contact with the paper's own text. Section II describes training as offline with online evaluation only, and the cited REAL system is an online PPO xApp. Section VII reports that Hard Slicing has the best URLLC SLA compliance, DQN has a slight edge in eMBB throughput, and Priority-based/DQN lead mMTC coverage. DORA's actual contribution is 'most balanced,' not 'best at everything.'\n\nWhat is genuinely here: a complete, careful PPO-based slice-level PRB allocator paired with round-robin intra-slice scheduling, pretrained on an OAI-derived throughput lookup table and evaluated closed-loop in the OAI RFsim stack. That pipeline is a plausible, reusable template for O-RAN xApp development. The decoupling of slice-level control from per-UE scheduling is sensible and well motivated. The evaluation is detailed, with CDFs for latency and throughput and explicit discussion of trade-offs. The authors also acknowledge the hard-slicing trade-off and the priority baseline's mismatch, which suggests they understand their own results.\n\nThe soft spots are real but mostly claim-level rather than implementation-level. The reward weights (0.5, 0.4, 0.1) are hand-picked, and the 'intelligent balance' is largely a consequence of those weights, not emergent learning. mMTC coverage is defined as floor(PRB/5), so the metric is a direct arithmetic consequence of allocation. There are no error bars or multiple seeds, no released code or data, and only one congested regime against weak baselines. The biggest issue is that the paper's selling points are contradicted by its own evaluation. That is not a minor copyediting problem; the framing needs to change substantially.\n\nWho should read it: anyone building an OAI-based slice scheduler will find the integration details useful. It is a solid engineering report, but as a novelty claim about being first, it doesn't hold up.\n\nRecommendation: The empirical work is real enough that I would not desk-reject it; I'd send it to review with a note to the referee to check the claims against Section VII. The authors should be pushed to revise the abstract and introduction to describe DORA as a balanced trade-off engine with a reproducible OAI implementation, not as a universal winner.","headline":"DORA is a genuine OAI engineering effort, but its headline 'first fully online' and 'outperforms on all KPIs' claims collapse under its own results.","tokens_in":9716,"tokens_out":2200,"would_cite":false,"duration_ms":24439,"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":"A single PPO agent can split 5G radio blocks across three slices live","keywords":["O-RAN","network slicing","physical resource block allocation","deep reinforcement learning","PPO","OpenAirInterface","5G resource management","service-level agreements"],"falsifier":"Re-run DORA's online evaluation while replacing the lookup table with live OAI throughput measurements, or add fading and measurement noise during pretraining. If the reported URLLC latency, eMBB throughput, and mMTC coverage margins over the baselines collapse or reverse, the transfer-from-table assumption is the load-bearing failure.","tokens_in":8553,"feed_emoji":"📡","tokens_out":7478,"duration_ms":85941,"temperature":0.7,"pith_summary":"Network operators slice one 5G cell into three service classes—ultra-reliable low-latency, mobile broadband, and massive IoT—that compete for the same 106 physical resource blocks (the smallest schedulable radio resource) every transmission interval. The paper claims that a single PPO-based reinforcement-learning agent, trained offline on an OAI-derived throughput table and evaluated online in the OpenAirInterface stack, allocates these blocks better than three fixed or heuristic baselines and a DQN agent: lower URLLC latency, higher eMBB throughput with fewer SLA violations, and wider mMTC coverage, all under deliberate congestion. The key design choice is decoupling slice-level allocation from per-user scheduling—the RL agent decides slice totals, then a deterministic round-robin assigns blocks inside each slice. If the claim holds, DORA is a deployable O-RAN xApp that lets operators adapt slicing in real time without sacrificing any one service class.","feed_headline":"PPO agent splits 5G radio blocks across three slices live","feed_subtitle":"DORA keeps ultra-reliable latency, broadband throughput, and IoT coverage balanced under congestion","key_machinery":"Key machinery: (1) a discrete-control MDP whose action space is every integer triple (a,b,c) with a+b+c=106 PRBs—3,003 actions; (2) a PPO policy trained offline against a throughput lookup table indexed by (pathloss, PRBs) so training avoids expensive PHY simulation; (3) a weighted reward that maps SLA violations into bounded costs; (4) deterministic round-robin inside each slice, so the RL agent only decides slice totals, not user-level schedules; (5) an E2-like Python bridge to the OAI stack for closed-loop telemetry and control.","core_discovery":"DORA's central claim: one PPO agent can perform adaptive slice-level PRB allocation entirely online in O-RAN, without jointly scheduling individual users. It observes slice type, normalized demand, and pathloss for each URLLC/eMBB user, picks one of 3,003 integer PRB triples summing to 106, and earns a weighted reward (0.5 URLLC latency, 0.4 eMBB throughput, 0.1 mMTC coverage). Offline pretraining uses an OAI-derived throughput lookup table; online evaluation closes the loop in the OAI simulator, adding fading, noise, and contention. The paper reports DORA beats three non-learning baselines and DQN under congestion while preserving URLLC priority.","pith_inferences":["The transfer from lookup-table pretraining to live OAI is the paper's unmeasured risk; a natural next experiment is to compare table-expected vs OAI-measured throughput per (pathloss, PRB) pair and to test online fine-tuning.","Because the action space enumerates every integer split of 106 PRBs, the same MDP could be re-run with different reward weights to trace the operator's Pareto frontier among the three slices; DORA reports only one weighting (0.5/0.4/0.1).","The E2-like Python bridge with memory-mapped files is a simplification of the O-RAN E2AP standard; production deployment would require replacing that bridge with a full E2 interface, which the paper does not implement."],"forward_implications":["If DORA is right, operators can run slice-level PRB allocation as a closed-loop xApp on a near-real-time RIC without dedicated PHY hardware, using software UEs for testing.","Decoupling slice-level decisions from per-UE scheduling means the agent design can scale to more UEs inside a slice: the RL action space stays at slice granularity.","Under overload, the learned policy will occasionally miss the URLLC latency target by a small margin to free resources for eMBB and mMTC—a deliberate trade-off that static allocations cannot encode.","The reported results make DORA a stronger online alternative to offline-trained DRL xApps, since it is pretrained quickly on a table and then evaluated against live OAI dynamics."],"supporting_citations":[{"why":"Closest prior online PPO-based xApp; DORA's differentiator is running on a 3GPP PHY/MAC stack rather than a GNU Radio emulator.","marker":"[8]"},{"why":"Supplies automated design and benchmarking of DRL xApps; DORA positions its design choices against this prior art.","marker":"[4]"},{"why":"Comparative evaluation of DRL-based xApps that motivates DORA's multi-baseline comparison.","marker":"[5]"},{"why":"Shows practical xApp deployment and online training in O-RAN, a capability DORA extends to slice-level allocation.","marker":"[6]"},{"why":"OAI-based slicing platform providing the standards-aligned infrastructure a DORA-type xApp would run on.","marker":"[12]"}],"fun_headline_variants":["DORA: PPO agent allocates 5G PRBs across three slices live","Online DRL allocates radio blocks to URLLC, eMBB, and mMTC slices","DORA's PPO learns to split 5G resources among three service types","PPO-based DORA dynamically assigns PRBs for multi-slice 5G networks","DORA uses PPO to allocate PRBs live across URLLC, eMBB, and mMTC"],"cache_read_input_tokens":2688,"weakest_assumption_plain":"The whole evaluation assumes that the offline lookup table, built from controlled OAI runs, captures the throughput the online OAI environment will actually deliver; the paper lists fading, measurement noise, and cross-slice contention as differences but never measures the gap.","fun_headline_variants_meta":{"raw":{"variants":["DORA: PPO agent allocates 5G PRBs across three slices live","Online DRL allocates radio blocks to URLLC, eMBB, and mMTC slices","DORA's PPO learns to split 5G resources among three service types","PPO-based DORA dynamically assigns PRBs for multi-slice 5G networks","DORA uses PPO to allocate PRBs live across URLLC, eMBB, and mMTC"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000226,"raw_usage":{"total_tokens":1353,"prompt_tokens":843,"completion_tokens":510,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":587,"completion_tokens_details":{"reasoning_tokens":406}},"tokens_in":587,"tokens_out":510,"duration_ms":6405,"temperature":1.0,"reasoning_tokens":406,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-04T22:35:24.839152+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Re-run DORA's online evaluation while replacing the lookup table with live OAI throughput measurements, or add fading and measurement noise during pretraining. If the reported URLLC latency, eMBB throughput, and mMTC coverage margins over the baselines collapse or reverse, the transfer-from-table assumption is the load-bearing failure.","supporting_citations":[{"cited_title":"PandORA: Automated Design and Comprehensive Evaluation of Deep Reinforce- ment Learning Agents for Open RAN,","cited_arxiv_id":null,"evidence_quote":"Supplies automated design and benchmarking of DRL xApps; DORA positions its design choices against this prior art."},{"cited_title":"A Comparative Analysis of Deep Reinforcement Learning-Based xApps in O-RAN,","cited_arxiv_id":null,"evidence_quote":"Comparative evaluation of DRL-based xApps that motivates DORA's multi-baseline comparison."},{"cited_title":"ColO- RAN: Developing Machine Learning-Based xApps for Open RAN Closed-Loop Control on Programmable Experimental Platforms,","cited_arxiv_id":null,"evidence_quote":"Shows practical xApp deployment and online training in O-RAN, a capability DORA extends to slice-level allocation."},{"cited_title":"ORANSlice: An Open Source 5G Network Slicing Platform for O-RAN,","cited_arxiv_id":null,"evidence_quote":"OAI-based slicing platform providing the standards-aligned infrastructure a DORA-type xApp would run on."}],"review_version":1}