{"id":"931f8b31-c9b8-47ac-af60-29f58ff9f1ec","arxiv_id":"2502.02842","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"CPU limits on non-priority 5G slices improved throughput for the priority slice in an Open5GS/Kubernetes testbed, and combining CPU limits with nice priority gave the best results.","lead":"This paper tests whether standard cloud tools, such as CPU limits and process priority, can keep one 5G network slice from stealing resources from another in a private 5G network built with open-source software. In a simulated hospital video-call scenario, limiting CPU for lower-priority slices helped the priority slice, while memory limits and bandwidth caps were less reliable.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The claimed CPU-contention mechanism is not established: the testbed saturates a 1 Gbps path while baseline aggregate throughput is only ~20% of link capacity, and §5.4 itself attributes the bottleneck to the network, so CPU limits may only be throttling emulator traffic.","rationale":"The paper's practical recommendation rests entirely on the causal story: a non-priority slice steals CPU from the priority UPF on the shared edge node, and Kubernetes CPU limits restore isolation. The reader's verdict is CONDITIONAL, and my stress-test targets the same weakest link. The experiments do not isolate the CPU mechanism. The offered load is deliberately above 1 Gbps, so the network path is saturated; nevertheless baseline aggregate throughput is only ~20% of link capacity, which points to a software/emulation bottleneck. The authors' own explanation for the null result with nice (§5.4) invokes a network bottleneck, which is in tension with the CPU-contention story. Without CPU utilization/throttling data, the observed improvements from CPU limits could be caused by the limits making the non-priority UPFs drop packets earlier (thereby reducing load on the shared link/simulator), an effect that may not reproduce with real gNBs or with UPFs on separate nodes. I therefore keep the CONDITIONAL verdict: the empirical trend is plausible and the provided IaC/scripts are a genuine asset, but the mechanism must be verified before operators should rely on it. The concrete check is to re-analyze the existing Prometheus data (or run one additional experiment) for per-UPF CPU throttling and node-level network drops.","tokens_in":33079,"tokens_out":6257,"duration_ms":60367,"concrete_test":"Re-analyze the existing Prometheus data (or run one additional 20-minute run of Experiments 5 and 25) and extract per-UPF cgroup cpu.stat (throttled_time, nr_throttled) and container CPU usage, plus netdev rx/tx drop and pause counters on the UPF node. If in Experiment 5 the priority UPF is not CPU-throttled and the node's total CPU utilization remains below ~100%, the bandwidth loss cannot be attributed to CPU contention and the paper's mechanism is unsupported. If, instead, the non-priority UPFs show sustained throttling and the priority UPF's CPU share rises in Experiment 25, the CPU-contention explanation is corroborated.","verdict_should_be":"UNCHANGED","load_bearing_attack":"To support the central claim that CPU limits (plus nice) on non-priority UPFs protect priority-slice throughput, the interference in the testbed must be caused by CPU contention among the five UPFs co-located on one edge node (§4.4). The paper does not demonstrate this. §5.1 sets total offered load at t=1200s to 1080 Mbps, above the 1 Gbps link, so the shared switch/up-link is saturated by construction. Yet in baseline Experiment 5 the aggregate received throughput is only ~234 Mbps (Slice 1 ≈119 + others ≈115), far below link capacity, indicating a bottleneck in the software UPF or the my5G-RANTester emulator, not the physical link alone. Critically, §5.4 states that the null effect of nice 'can be explained by the fact that the bottleneck lies in the network, which limits the availability of packets for processing by the network function.' If the bottleneck is the emulated gNB/UE or the single node's total forwarding capacity, then CPU limits may simply cause the non-priority UPFs to drop packets or back-pressure, reducing their offered load on the shared path without establishing a CPU-scheduling mechanism that would transfer to real RAN or multi-node edge deployments. No CPU-utilization, cgroup throttling, or packet-drop data are reported to confirm that the UPF node was CPU-saturated in Experiments 5–8 or that the 250m/500m limits actually throttled the non-priority UPFs.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper reports an experimental study of network-slice isolation in a private 5G network built from Open5GS, Kubernetes, Cilium, and the my5G-RANTester emulator. The authors place five UPFs on a single edge node, generate medical-video-like traffic with iPerf, and run 26 experiments (10 runs each) that apply CPU limits, Linux nice values, and bandwidth limits to non-priority slices, individually and in combination. The headline findings are that CPU limits on non-priority UPFs improve priority-slice throughput, memory limits have no observable effect, and a combination of CPU limiting with prioritization keeps the priority slice within about 5% of its single-slice reference throughput, with Experiment 25 identified as the best configuration. The paper contributes a reproducible testbed, public scripts, and a dataset.","tokens_in":33399,"tokens_out":8321,"duration_ms":74663,"significance":"If the causal mechanism behind the reported results were established, the paper would provide practical, low-cost guidance for private 5G operators using open-source cores on Kubernetes, and the public scripts and data would be a useful community resource. The experimental design is systematic, and the authors deserve credit for making the artifacts available and for reporting per-experiment statistics. However, the significance is conditional: the central claim requires evidence that the observed interference is caused by CPU contention among co-located UPFs, and that evidence is not present in the paper as written.","major_comments":[{"comment":"The central causal claim—that CPU limits on the non-priority UPFs protect priority-slice throughput—is not supported by mechanism evidence. The testbed's offered load is set to 1080 Mbps (§5.1), but in baseline Experiment 5 the aggregate received throughput is only about 234 Mbps (119.12 + 114.59 Mbps in Figure 9), far below the 1 Gbps link; this indicates that the bottleneck is in the software UPF or in the my5G-RANTester emulator, not the physical link. §5.4 itself attributes the null effect of nice to the fact that 'the bottleneck lies in the network, which limits the availability of packets for processing by the network function.' Under that reading, CPU limits on a UPF could simply throttle the traffic that the emulator is able to inject, without establishing a CPU-scheduling isolation mechanism that would transfer to a real RAN or to multi-node edge deployments. No CPU-utilization, cgroup-throttling, or packet-drop measurements are reported (the CPU metrics mentioned in §5.1 are never analyzed), so the experiment cannot distinguish CPU contention among the five co-located UPFs from emulator-side saturation. This is load-bearing for the paper's operational recommendation, and it needs to be addressed with either additional measurements or a substantially qualified claim.","section":"§5.1, §5.3, §5.4"},{"comment":"The abstract's claim that 'memory restrictions have minimal impact' is not supported by the experiments as reported. §5.1 states that memory limits were tried during initial configuration, found to have 'no significant impact,' and then 'excluded from subsequent experiments,' but no controlled experiment, table, or quantitative result for memory limitation is presented anywhere in Section 5. Either the memory experiments need to be reported with the same detail as the CPU and bandwidth experiments, or the claim should be removed from the abstract and conclusions.","section":"§5.1, Abstract"},{"comment":"The ranking of configurations, in particular the statement that 'Experiment 25 is superior to the other experiments' (§5.9), is based on differences that appear to be within the noise of the measurements. In Figure 21, the priority-slice means for Experiments 23-26 are 137.50, 140.40, 145.83, and 142.14 Mbps with standard deviations between 17 and 20 Mbps; in §5.3, the CPU-limit progression 138→142→151 Mbps is reported with comparable dispersion. No confidence intervals, hypothesis tests, or effect sizes are given, and the 10 runs per experiment are not analyzed as repeated measurements. The 'approximately 5% variation' headline in the conclusion therefore needs statistical support before it can be treated as a substantive finding.","section":"§5.3, §5.9, Figure 21"},{"comment":"The conclusion states that 'the combined use of CPU limitation and prioritization provides better performance,' but the data in Figures 17 and 23 show that CPU limitation alone (Experiment 8: 147.09 Mbps) and CPU limitation with bandwidth-control activation (Experiment 19: 149.08 Mbps) achieve priority-slice throughput at least as high as the combined CPU+nice experiments (Experiment 15: 146.52, Experiment 16: 145.74). The incremental contribution of nice over CPU limits is therefore not demonstrated; the paper should compare the combined configurations against their CPU-only counterparts explicitly and quantify any improvement.","section":"§5.9, Conclusion"}],"minor_comments":[{"comment":"Several figures contain corrupted labels (e.g., '/uni00000014 ...') and tables contain typos such as 'T able' and 'milicpu'; these should be cleaned before publication.","section":"Figures 8-24, Tables 1-6"},{"comment":"The statement in §5.4 that 'the bottleneck lies in the network' conflicts with the §4.4 premise that resource contention among the co-located UPFs is the dominant effect; the text should be made internally consistent.","section":"§5.4, §4.4"},{"comment":"The Data Availability section says the data are 'accessible upon request,' while the abstract and §4.4 state that the scripts and data are publicly available on GitHub; these statements should be reconciled.","section":"§7, Abstract, §4.4"},{"comment":"Several latency tables have missing IQR cells (e.g., Experiments 2-4 in Figure 10, Experiment 7 in Figure 12), and Figure 24's table appears to copy throughput values into a latency table (Experiment 1 shows 154.04 in a latency-only figure); these need correction.","section":"Figures 10, 12, 24"},{"comment":"Several references are incomplete or inconsistently formatted (e.g., [1] and [13] lack publication years, and some venue fields are missing); the reference list should be checked against the journal style.","section":"References"}],"recommendation":"major_revision","confidential_remarks":"The paper's main contribution rests on an empirical correlation rather than a demonstrated mechanism, but the public artifacts and systematic experimental design are genuine strengths. The missing mechanism evidence is in principle obtainable, since the authors report that CPU metrics were collected, so I see major revision rather than rejection as the proportionate outcome. I would also ask the editor to ensure that the memory-limitation claim is either supported by data or removed."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Maiko's paper is a practical measurement study: it applies Kubernetes CPU limits, nice, and Cilium bandwidth shaping to Open5GS UPFs and measures slice isolation in a hospital-style video scenario. The experimental matrix (26 experiments, 10 runs each) and the public repo are genuinely new and useful. The finding that CPU limits on non-priority UPFs raise priority-slice throughput (from ~119 to ~151 Mbps in the best cases) is plausible and consistent across Experiments 6-8 and 14-16.\n\nWhat it does best: it treats the problem as an engineering trade-off, not a protocol invention. It reports throughput and latency for both priority and background slices, and it flags that bandwidth shaping can devastate low-priority slices. The choice to prefer Experiment 25 (CPU limit plus nice, no bandwidth cap) is reasonable given the data.\n\nThe soft spots are real. The abstract claims memory restrictions have minimal impact, but the paper admits in Section 5.1 that memory limits were dropped after initial observations; no controlled memory experiments are shown. That claim should be retracted or supported. Second, Section 7 says data are available 'upon request' while the abstract and Section 4.4 say they are public. That contradiction matters for reproducibility. Third, no statistical significance tests are reported; the differences between experiments (e.g., 136 vs 142 Mbps) could be noise given the standard deviations. Fourth — and this is the stress-test point I think is valid — the paper never shows CPU utilization, cgroup throttling, or packet-drop data, so it does not directly demonstrate that CPU contention among the co-located UPFs is the mechanism. The baseline aggregate throughput is only ~230 Mbps against a 1 Gbps link, so the bottleneck is in software, and Section 5.4's remark that the bottleneck 'lies in the network' is confusing. Still, the fact that CPU limits on secondary UPFs improve priority throughput is hard to explain unless CPU contention on the UPF node is a factor. The missing metric is a gap, not a refutation.\n\nBottom line: this is a useful contribution for practitioners building private 5G edges on Open5GS/Kubernetes. It deserves peer review, but a referee should push for the memory claim to be fixed, the dataset to be pinned, significance tests to be added, and CPU utilization/cgroup data to be reported to confirm the mechanism.","headline":"Useful empirical matrix on Kubernetes-based slice isolation for Open5GS, but the unsupported memory claim, missing significance tests, and unverified CPU-contention mechanism mean it needs major revision before publication.","tokens_in":33921,"tokens_out":4047,"would_cite":true,"duration_ms":37853,"reading_group":"yes","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 argues that combining CPU limits with scheduler priority keeps a priority 5G slice within about 5 percent of its uncontended throughput.","keywords":["5G","network slicing","slice isolation","edge computing","Kubernetes","CPU resource limits","bandwidth limitation","network function virtualization"],"falsifier":"Rerun the five-slice workload with all UPFs on separate edge nodes or with a link faster than 1 Gbps; if the priority slice still loses roughly 20 percent of its throughput as slices are added, CPU contention is not the cause. Alternatively, log host CPU utilization at the UPF node during the runs: if the node is not CPU-saturated at the moments priority throughput drops, the mechanism the paper attributes the gain to is not the one doing the work.","tokens_in":32879,"feed_emoji":"📶","tokens_out":7611,"duration_ms":63432,"temperature":0.7,"pith_summary":"The paper argues that slice isolation in private 5G networks can be improved using resource-control knobs that already exist in container-orchestrated edge clouds, without adding 5G-specific isolation hardware or protocols. In a hospital telemedicine scenario, the authors run one high-priority video slice against four background slices whose user-plane functions share a single edge node, and they vary CPU limits, Linux scheduler priorities, and egress bandwidth caps individually and in combination. Their central finding is that capping the CPU of the non-priority user-plane functions while giving the priority function a higher scheduler priority keeps priority-slice throughput within roughly 5 percent of the single-slice ideal, at the cost of the background slices. Memory limits show no measurable effect, CPU priority alone is ineffective, and severe bandwidth caps protect the priority slice but can push background latency into seconds. A sympathetic reader would take away a practical, reproducible recipe for protecting a priority slice in a low-cost private 5G deployment.","feed_headline":"CPU caps keep priority 5G slices within 5% of peak","feed_subtitle":"A 26-experiment edge-cloud study finds CPU limits plus scheduler priority protect a medical video slice.","key_machinery":"The load-bearing object is the user-plane function (UPF), the packet-forwarding network function where all slices' data traffic converges; in the testbed all five UPFs run on one resource-constrained edge node, so the CPU scheduler is the shared resource through which slices interfere. Three native control mechanisms are applied to the UPFs: CPU limits and requests expressed in millicpu and enforced by cgroups through the container orchestrator; the Linux nice value, which changes the scheduler's time-slice fraction according to the formula $\\mathrm{fraction}(i) = \\frac{\\mathrm{timeslice}(i)}{\\sum_j \\mathrm{timeslice}(j)}$; and egress bandwidth shaping using Earliest Departure Time (EDT) in the eBPF-based network plugin chosen for its lower latency overhead. The key comparison metric is the priority slice's average throughput during the last five minutes of each 20-minute run, measured against Experiment 1 (154.04 Mbps, single slice) as the ideal-isolation reference and Experiment 5 (119.12 Mbps, five slices without controls) as the worst case.","core_discovery":"The authors claim that interference between network slices sharing an edge node is primarily CPU contention among the user-plane functions (UPFs), and that native mechanisms—container-orchestrator CPU quotas backed by cgroups, the Linux nice value, and egress bandwidth shaping—can enforce isolation under that contention. In their best configuration (Experiment 25, which limits non-priority UPFs to 500 millicpu, sets their nice value to 5, assigns the priority UPF a nice value of -5, and activates bandwidth control without a hard cap), the priority slice sustains an average of 145.83 Mbps, a 5.33% reduction from the 154.04 Mbps single-slice best case, while the background slices collectively lose only 6.58% relative to the five-slice worst case. They also report that lowering non-priority CPU limits from none to 500m to 250m progressively restores priority throughput in the isolated CPU experiments, that memory limits have negligible effect because UPF memory usage is flat, and that combining CPU limits with nice outperforms either mechanism alone. The paper frames this as a methodology and a dataset rather than a new protocol: the same scripts and measurements are released for reproduction and for machine-learning studies.","pith_inferences":["If the CPU-contention mechanism is general, the same native knobs should isolate any pair of containerized data-plane functions sharing a node, not just 5G UPFs, which would extend the recipe to other virtualized network functions.","The observation that bandwidth adjustments do not require application restarts suggests a control loop could tune egress caps dynamically; the released dataset is a plausible training set for such a controller, though the paper does not build one.","The 5 percent figure is tied to the testbed's 1 Gbps link and single-CPU edge nodes; on multi-core nodes with hardware multi-queue NICs, EDT-based shaping may interact differently, so the quantitative result should be revalidated before transfer to larger deployments.","The paper's explanation that nice alone fails because the bottleneck is the network link is testable: repeating the nice-only experiments with a faster link should make scheduler priority visible again if the explanation is right."],"forward_implications":["Operators of private 5G networks can protect a priority slice by capping the CPU of non-priority UPFs, with no changes to the 5G core protocol stack.","Combining a CPU cap with a scheduler priority boost is more effective than either alone, since CPU priority alone shows no benefit in these tests.","Memory limits can be left out of isolation configurations for this class of workload, because UPF memory usage stays flat.","A 150 Mbps egress cap protects the priority slice but can make low-priority slices nearly unusable and drive their latency to seconds, so bandwidth caps should be applied cautiously.","The public experimental data and scripts turn the result into a baseline for reproducing the scenario and for training data-driven slice controllers."],"supporting_citations":[{"why":"Defines the isolation property used as the paper's goal: services in one slice must operate without direct or indirect influence from other slices.","marker":"[3]"},{"why":"Provides the tutorial and background on connecting access networks to the 5G core that underpins the testbed's use of the open-source core and the UE/RAN simulator.","marker":"[5]"},{"why":"Supplies the comparative evaluation of open-source 5G core implementations that motivated the choice of tools for the experiments.","marker":"[6]"},{"why":"Documents the open-source 5G core as a Release-17-compliant implementation on which the experimental slices are deployed.","marker":"[15]"},{"why":"Provides the CNI performance comparison that informed the choice of the eBPF-based network plugin with efficient bandwidth management.","marker":"[33]"},{"why":"Supplies the Earliest Departure Time (EDT) bandwidth-management mechanism used to limit UPF egress bandwidth.","marker":"[37]"},{"why":"Provides the Linux scheduler time-slice and nice-value model used to compute the CPU-prioritization mechanism.","marker":"[38]"}],"fun_headline_variants":["CPU limits, not memory, keep 5G slices isolated","Edge CPU quotas protect priority 5G slices","Scheduler nice plus CPU caps: 5G slice fix","26-experiment study: CPU contention breaks 5G slices","Open data: CPU limits improve 5G slice performance"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that the interference the experiments measure comes from CPU contention among the UPFs on the shared edge node, rather than from the 1 Gbps switch link or from artifacts of the UE/RAN simulator used to generate traffic.","fun_headline_variants_meta":{"raw":{"variants":["CPU limits, not memory, keep 5G slices isolated","Edge CPU quotas protect priority 5G slices","Scheduler nice plus CPU caps: 5G slice fix","26-experiment study: CPU contention breaks 5G slices","Open data: CPU limits improve 5G slice performance"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000484,"raw_usage":{"total_tokens":2363,"prompt_tokens":892,"completion_tokens":1471,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":508,"completion_tokens_details":{"reasoning_tokens":1389}},"tokens_in":508,"tokens_out":1471,"duration_ms":11049,"temperature":1.0,"reasoning_tokens":1389,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-09T10:54:34.765602+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Rerun the five-slice workload with all UPFs on separate edge nodes or with a link faster than 1 Gbps; if the priority slice still loses roughly 20 percent of its throughput as slices are added, CPU contention is not the cause. Alternatively, log host CPU utilization at the UPF node during the runs: if the node is not CPU-saturated at the moments priority throughput drops, the mechanism the paper attributes the gain to is not the one doing the work.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides the tutorial and background on connecting access networks to the 5G core that underpins the testbed's use of the open-source core and the UE/RAN simulator."},{"cited_title":"IEEE Access PP, 1–1 https://doi.org/10.1109/access.2024.3367120","cited_arxiv_id":null,"evidence_quote":"Documents the open-source 5G core as a Release-17-compliant implementation on which the experimental slices are deployed."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides the CNI performance comparison that informed the choice of the eBPF-based network plugin with efficient bandwidth management."},{"cited_title":"https://isovalent.com/blog/post/ addressing-bandwidth-exhaustion-with-cilium-bandwidth-manager/","cited_arxiv_id":null,"evidence_quote":"Supplies the Earliest Departure Time (EDT) bandwidth-management mechanism used to limit UPF egress bandwidth."},{"cited_title":"John Wiley and Sons, Hoboken, NJ (2013) 44","cited_arxiv_id":null,"evidence_quote":"Provides the Linux scheduler time-slice and nice-value model used to compute the CPU-prioritization mechanism."}],"review_version":1}