{"id":"99618362-833a-452c-b3fa-cb03f4761844","arxiv_id":"2508.21783","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":3.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"An extended Simu5G with per-QFI modeling and a weighted proportional-fairness scheduler reduces deadline violations and improves fairness in a simulated private 5G smart factory.","lead":"A research team added per-flow, multi-QFI support to the Simu5G 5G simulator and built a deadline-aware proportional fairness scheduler. In a simulated six-device smart factory, their scheduler met more packet deadlines and distributed bandwidth more evenly than two baseline schedulers.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Missing per-flow PF baseline prevents attributing gains to QoS-awareness; all performance evidence is affected.","rationale":"The reader identified the baseline granularity as the weakest assumption, which is closely related to my concern. However, I believe the more fundamental issue is the absence of any per-flow PF baseline, which is necessary to isolate the effect of QoS-awareness. Without such a baseline, the evidence only shows that QoS-PF outperforms two non-PF schedulers, not that its QoS-aware utility is what makes the difference. This is a load-bearing gap for the central claim, but it is addressable by adding a PF baseline and clarifying the baselines' granularity. The reader's conditional verdict already captures that the paper needs revision, so I do not move the verdict. I partially agree with the reader because their weakest_assumption focuses on granularity while my concern extends to the missing PF baseline, which they mention only in the rationale.","tokens_in":9984,"tokens_out":5489,"duration_ms":61574,"concrete_test":"Run the same 6-UE/3-flow scenario with a plain per-flow PF scheduler defined as M_i(t)=1/Rbar_i(t) (i.e., U_i=1) in the same extended Simu5G, and compare deadline violation ratio, Jain's fairness, and per-flow throughput to QoS-PF. If plain PF matches QoS-PF within statistical error, the QoS-aware utility adds no measurable benefit; if QoS-PF significantly improves QFI 1 violations, the advantage is attributable to the utility. Also report whether the stock Max C/I and Static Priority baselines operate per-UE or per-flow, and rerun them at per-QFI granularity if needed.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim is that the QoS-aware utility (Eq. 2) drives the reported improvements. Section IV.B compares QoS-PF only against Max C/I and Static Priority; no standard per-flow Proportional Fairness (PF) baseline is included. Since QoS-PF reduces to a weighted PF when U_i=1, the reported gains (e.g., <2% vs >20% violation in Fig. 5) may stem from the PF mechanism itself—which already favors low-throughput flows—rather than from the delay/GBR/priority terms in U_i. Without a PF baseline at the same per-QFI granularity, the specific contribution of QoS-awareness is unidentified. Additionally, if the baselines operate per-UE rather than per-flow (as the ambiguous description of Max C/I in Section IV.B suggests), the comparison conflates per-flow granularity with QoS-awareness. Table III's QFI labels (5,8) contradict the scenario's QFIs (1–3), obscuring which flows the results refer to. These gaps affect Figures 4–6 and Table III, i.e., all performance evidence for the central claim.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper extends the Simu5G simulator to model multiple QoS flows per UE with QFI/5QI tagging and introduces a QoS-aware proportional fairness (QoS-PF) scheduler. The scheduling metric (Eq. 1) is M_i(t) = U_i(t) / Rbar_i(t), where U_i(t) (Eq. 2) combines delay urgency, GBR deficit, and a priority scalar with tunable weights. The evaluation uses a 6-UE, three-flow smart-factory scenario (control, sensor, video) and compares QoS-PF against Max C/I and Static Priority. The authors report lower delays and deadline violations, higher GBR satisfaction, and improved Jain's fairness for QoS-PF, plus a sensitivity analysis and a scalability study. The central claim is that QoS-PF improves deadline adherence and fairness without compromising throughput.","tokens_in":10262,"tokens_out":5810,"duration_ms":59615,"significance":"If validated, the contribution would be useful to the industrial-5G simulation community: the open-source Simu5G extensions for per-QFI modeling and SDAP-like tagging address a real gap, and the scheduler design is plausible and modular. The paper explicitly promises reproducibility through public code and configuration files. However, the current evaluation does not isolate the QoS-aware component of the scheduler. Because Eq. (2) reduces to standard proportional fairness when U_i is constant, the absence of a per-QFI non-QoS PF baseline means the reported gains could come from the PF mechanism rather than from the delay/GBR/priority utility. In addition, several internal inconsistencies in QFI labels, baseline granularity, and the channel model prevent the reported numbers from supporting the abstract's claim as written. The core ideas are worth pursuing, but the evidence needs substantial strengthening.","major_comments":[{"comment":"The central attribution of the gains to QoS-awareness is not identified. Eq. (2) defines U_i(t) = α_i D_i(t) + β_i G_i(t) + γ_i P_i(t), and Eq. (1) is M_i = U_i / Rbar_i. When U_i is constant, this is exactly standard proportional fairness. The evaluation in §IV.B compares QoS-PF only against Max C/I and Static Priority; no per-QFI non-QoS PF baseline is included. Since PF itself favors low-throughput flows, the reported differences (e.g., <2% vs >20% violation in Fig. 5, fairness >0.9 in Fig. 6) may be due to the PF denominator rather than to the delay/GBR/priority utility. Add a standard per-QFI PF baseline (U_i = 1) at the same scheduling granularity, and ideally also a per-UE PF baseline, to separate the effects of granularity and QoS-awareness. This affects all performance evidence in Figs. 4–6 and Table III.","section":"§III.C and §V"},{"comment":"The baseline configuration is under-specified, and one assumption contradicts the results. Section IV.B says Max C/I assigns resources to 'the flow or UE' without stating which. If the stock Simu5G baselines operate per-UE while QoS-PF operates per-QFI, the comparison conflates scheduling granularity with QoS-awareness. Furthermore, §IV.A states 'All UEs operate under the same channel conditions with fixed LoS propagation', yet §V.A says 'Max C/I heavily favors high-SINR users' and Fig. 6 reports fairness below 0.6 for Max C/I. With identical channel conditions, Max C/I has no user-level channel differentiation and would not produce the stated fairness gap. Specify the exact objects (QFI or UE) that each baseline schedules, and reconcile the channel model with Figure 6.","section":"§IV.B and §V.A"},{"comment":"The results are not tied to the simulated traffic classes. Table II defines the scenario as QFI 1/2/3 with 5QI 85/6/9, but §V.A begins 'Figure 4 shows ... QFIs 5, 7, and 8' and later refers to 'QFIs 7 and 8'. Table III lists only QFI 5 and QFI 8, and reports GBR satisfaction only for QFI 5—not for QFI 1, which is the control flow at the center of the deadline claims. The reader cannot map the reported delays, violations, and throughputs to the described applications. Renumber all tables and figure captions to match the scenario QFIs, and report per-QFI metrics for all three flows.","section":"§V.A and Table III"},{"comment":"The sensitivity analysis in Fig. 7 reports percentage changes (18% average-latency reduction for the Delay-Tuned configuration, 9% fairness improvement for Fairness-Tuned) without confidence intervals or a statistical test. Since §IV.A claims 20 Monte Carlo runs, error bars should be feasible. This issue is secondary to the main comparison, but as presented the trade-off between Delay-Tuned and Fairness-Tuned is not statistically supported.","section":"§V.B"}],"minor_comments":[{"comment":"The text says a robotic arm 'may transmit sub-millisecond motion control commands (QFI 1) alongside periodic telemetry updates (QFI 1)'. Both flows should not share the same QFI if they have different QoS profiles; the telemetry flow should use a distinct QFI (e.g., QFI 5).","section":"§II"},{"comment":"The text reports 'over 20%' deadline violation for Max C/I, but the y-axis of Fig. 5 ends at 14%. The figure and text need to be reconciled, or the bar is truncated.","section":"§V.A and Fig. 5"},{"comment":"The Jain's fairness index formula has a formatting problem: J = (∑x_i)^2 / (n · ∑x_i^2) is the intended expression; the current rendering is ambiguous.","section":"§IV.C, Eq. (3)"},{"comment":"The scalability claim says per-TTI runtime 'remained under 2 ms' for 40 UEs and is 'well within real-time scheduling budgets'. A 5G TTI is typically 1 ms, so a 2 ms scheduling time would not fit in a real-time budget. Clarify whether the reported time is wall-clock simulation time or a normalized scheduling time, and compare against the relevant TTI.","section":"§V.C and Fig. 8"}],"recommendation":"major_revision","confidential_remarks":null},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Short version: the paper ships a real artifact — a Simu5G extension with per-QFI-per-UE support and a QoS-aware weighted-PF scheduler — and that part looks worth having. The evaluation, though, doesn't quite nail the claim that QoS-awareness, rather than finer scheduling granularity, drives the improvements.\n\nWhat's genuinely new: the SDAP-inspired QFI tagging and per-flow context propagation down to the MAC scheduler, implemented modularly in Simu5G. The scheduler is a weighted PF variant with delay, GBR, and priority utility terms; that formula is known from prior LTE/5G literature, and the authors don't cite any of it, so the novelty is modest. But the combination of multi-QFI support plus an open-source implementation is a real contribution for the industrial 5G simulation community. The sensitivity analysis and per-TTI runtime scaling test are also good practice.\n\nThe soft spots. The big one is the missing baseline. QoS-PF is compared only against Max C/I and Static Priority. If you set U_i(t) to a constant, QoS-PF becomes ordinary per-flow PF, which already protects low-throughput flows. Without a same-granularity PF baseline, the reported gains (e.g., <2% vs >20% violation for QFI 1) could come from the PF mechanism or from per-flow vs per-UE scheduling granularity, not from the delay/GBR/priority terms. Section IV.B is ambiguous about whether the baselines schedule per-UE or per-flow. All of Section V inherits this problem. That's a load-bearing gap.\n\nThere's also a concrete internal inconsistency: Section V.A and Table III refer to QFIs 5, 7, 8, while the scenario (Table II) uses QFIs 1, 2, 3. That's a labeling error that needs fixing before the results can be trusted.\n\nThe circularity concern is weaker. The scheduler optimizes delay, GBR, and fairness, and the KPIs measure exactly those; that's true of any controlled evaluation. It doesn't invalidate the results, but it does mean the improvements are somewhat built-in.\n\nBottom line: the artifact deserves a serious referee — the extension is useful and reproducible, and the identified gaps are fixable. But the central claim of QoS-awareness needs a per-flow PF baseline and consistent QFI labels before it's convincing. I'd send it to review with a request for major revision, not desk-reject it.","headline":"A useful open-source Simu5G extension for multi-QFI scheduling, but the evaluation lacks the per-flow PF baseline needed to attribute gains to QoS-awareness.","tokens_in":10756,"tokens_out":2804,"would_cite":true,"duration_ms":27320,"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 per-flow 5G scheduler keeps control-loop deadline misses under 2 percent while staying fair to video and telemetry traffic.","keywords":["5G","QoS Flow Identifier","proportional fairness","smart factory","URLLC","deadline compliance","Simu5G","resource allocation"],"falsifier":"Run the identical traffic mix with Max C/I and Static Priority modified to operate per QFI with the same QFI tagging and context; if their QFI-1 violation rates fall to the same roughly 2 percent level, the utility-weighting mechanism is not what produces the headline result.","tokens_in":9898,"feed_emoji":"🏭","tokens_out":5511,"duration_ms":57761,"temperature":0.7,"pith_summary":"The paper tries to establish that one private 5G base station can serve the mixed traffic of a smart factory—tight-deadline robot control, live video, and background telemetry—without starving any flow. To test this, the authors extend an existing 5G network simulator so that each user device can carry several QoS flows at once, each tagged with its QoS Flow Identifier, and they add a MAC-layer scheduler that scores every flow by a weighted mix of delay urgency, guaranteed-bit-rate shortfall, and priority, divided by that flow's recent throughput. In a simulated six-device factory cell, the scheduler keeps deadline violations for the most time-critical class below 2 percent, maintains flow-level fairness above 0.9, and satisfies guaranteed bit rates above 95 percent, while comparison schedulers either miss deadlines or starve low-priority flows. If these numbers hold, the contribution is a practical recipe for testing and provisioning private 5G for industrial workloads, plus a scheduler design that could generalize beyond factories.","feed_headline":"New scheduler keeps 5G deadline misses under 2 percent","feed_subtitle":"QoS-aware proportional fairness balances delay, bitrate, and priority across multiple flows per device in industrial cells.","key_machinery":"The central object is the QoS-flow-aware proportional-fairness score: M_i(t) = U_i(t)/Rbar_i(t), a utility-per-recent-throughput ratio computed for every active QFI. The numerator U_i(t) is a tunable weighted sum of delay urgency, guaranteed-bit-rate shortfall, and priority, while the denominator is the flow's averaged throughput; this combination gives time-critical flows a boost when they fall behind while still letting well-served flows yield resources. The paper implements this score inside the simulator's MAC scheduler, supported by newly added SDAP-layer tagging, per-QFI PDCP/RLC instances, and a centralized QFI context manager that feeds flow state into each scheduling decision.","core_discovery":"The central claim is that per-flow QFI awareness can be combined with proportional fairness to satisfy heterogeneous industrial QoS without sacrificing throughput or fairness. The scheduler's metric is M_i(t) = U_i(t)/Rbar_i(t), where U_i(t) = alpha_i*D_i(t) + beta_i*G_i(t) + gamma_i*P_i(t); D_i is delay urgency, G_i is GBR fulfillment, P_i is the flow's priority scalar, and Rbar_i is the flow's exponential moving average throughput. At each transmission time interval the scheduler ranks active QFIs by this score and allocates resource blocks in that order. The paper reports that under high contention this keeps deadline violations for the strictest URLLC flow below 2 percent, compared with","pith_inferences":["A controlled ablation that runs the comparison schedulers at the same per-QFI granularity as QoS-PF would separate the contribution of the utility weighting from the contribution of finer-grained scheduling itself; the paper does not report that comparison.","The three utility weights are static in this paper; an obvious extension is to adapt alpha, beta, and gamma online from measured violations and fairness, turning the sensitivity analysis into a closed-loop controller.","Because the QFI context lives at the MAC layer, the same score could be lifted to uplink scheduling, where each device must decide how to split its transmission grants among its own flows.","The modular utility function can host non-linear urgency models, such as learned deadline predictors, without touching the proportional-fairness denominator that enforces long-term sharing."],"forward_implications":["A single private 5G cell can carry URLLC control loops, eMBB video, and best-effort telemetry without hard slicing, as long as flows carry QFI tags and are scheduled by their utility scores.","Factory designers can use the open simulator extensions to check whether a proposed traffic mix meets its delay budgets before deployment, instead of relying on costly live trials.","The reported near-linear runtime growth—under 2 ms per TTI at 40 UEs with three flows each—suggests per-flow QoS scoring is cheap enough for realistic cell sizes.","Operators can shift the scheduler from delay-first to fairness-first behavior by retuning three weights, without changing the underlying allocation mechanism.","The same scheduler logic is claimed to carry over to other multi-flow verticals such as tele-surgery, connected vehicles, and AR/VR, where URLLC and eMBB traffic share one device."],"supporting_citations":[{"why":"Supplies the 3GPP QFI/5QI QoS model, including delay bounds and GBR semantics that the scheduler enforces.","marker":"[5]"},{"why":"Describes the base Simu5G simulator architecture and its scheduler interfaces that the paper extends.","marker":"[6]"},{"why":"The Simu5G library paper, which provides the OMNeT++-based standalone 5G NR simulation environment the extensions build on.","marker":"[16]"},{"why":"Companion work introducing SDAP-based QoS flow multiplexing that the paper integrates for per-QFI tagging and bearer mapping.","marker":"[17]"},{"why":"A prior QoS-aware 5G-TSN simulation framework that tagged QFIs, motivating the paper's unified multi-QFI modeling.","marker":"[18]"}],"fun_headline_variants":["Per-QFI 5G scheduler keeps URLLC misses under 2% in smart factories","Smart factory 5G: QoS-aware scheduler hits <2% deadline miss rate","Multi-flow 5G scheduling: fairness without throughput loss or missed deadlines","Industrial 5G: new scheduler balances delay, bitrate, and priority per flow","5G scheduler trims URLLC deadline misses to under 2% with per-flow fairness"],"cache_read_input_tokens":2688,"weakest_assumption_plain":"The comparison assumes the baseline schedulers are applied at the same per-flow granularity as QoS-PF; if they schedule per device instead, the reported deadline gains could come from finer resource granularity rather than from QoS awareness.","fun_headline_variants_meta":{"raw":{"variants":["Per-QFI 5G scheduler keeps URLLC misses under 2% in smart factories","Smart factory 5G: QoS-aware scheduler hits <2% deadline miss rate","Multi-flow 5G scheduling: fairness without throughput loss or missed deadlines","Industrial 5G: new scheduler balances delay, bitrate, and priority per flow","5G scheduler trims URLLC deadline misses to under 2% with per-flow fairness"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000241,"raw_usage":{"total_tokens":1353,"prompt_tokens":732,"completion_tokens":621,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":476,"completion_tokens_details":{"reasoning_tokens":510}},"tokens_in":476,"tokens_out":621,"duration_ms":7954,"temperature":1.0,"reasoning_tokens":510,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-05T13:56:28.194750+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the identical traffic mix with Max C/I and Static Priority modified to operate per QFI with the same QFI tagging and context; if their QFI-1 violation rates fall to the same roughly 2 percent level, the utility-weighting mechanism is not what produces the headline result.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the 3GPP QFI/5QI QoS model, including delay bounds and GBR semantics that the scheduler enforces."},{"cited_title":"Nardini, G","cited_arxiv_id":null,"evidence_quote":"Describes the base Simu5G simulator architecture and its scheduler interfaces that the paper extends."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"The Simu5G library paper, which provides the OMNeT++-based standalone 5G NR simulation environment the extensions build on."},{"cited_title":"SDAP-based QoS Flow Multiplexing Support in Simu5G for 5G NR Simulation","cited_arxiv_id":"2508.12785","evidence_quote":"Companion work introducing SDAP-based QoS flow multiplexing that the paper integrates for per-QFI tagging and bearer mapping."}],"review_version":1}