{"id":"95bbc67c-509f-4dcc-80e5-3e63d38d18e3","arxiv_id":"2605.28185","paper_version":1,"verdict":"ACCEPT","confidence":"LOW","novelty_score":7.0,"correctness_risk":"low","formal_verification":"none","parameter_count":0,"one_line_summary":"Measurement study on containerized 5G UPF shows eMBB latency rises with load while URLLC stays stable, with N4 control latency under 200us and full code/dataset released.","lead":"This paper measures per-slice forwarding latency in a containerized open5GS 5G UPF using a new kernel-level TC-BPF tool across eMBB, URLLC, and mMTC slices under varying loads. Smart generalists might read it to see concrete timing data that affects whether AI systems can safely manage 5G networks in real time.","discovery_kind":"new_method","skeptic_critique":{"model":"grok-4.3","headline":"TC-BPF framework's per-slice attribution accuracy and zero-overhead claim lack independent validation, making load-insensitivity of URLLC potentially an artifact.","rationale":"The reader's weakest_assumption is exactly the load-bearing precondition for any latency-based isolation claim in this containerised setting; the empirical nature of the paper makes independent validation of the measurement layer the decisive missing step.","tokens_in":1796,"tokens_out":312,"duration_ms":15469,"concrete_test":"Re-run the released instrumentation on a two-namespace testbed with a synthetic UDP generator that emits known per-namespace inter-arrival times; compare BPF-reported N3-N6 delays against simultaneous kernel tracepoints on the same packets. If median or 99th-percentile difference exceeds 20 µs under any load, the isolation conclusion is unsupported.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"The headline result (URLLC forwarding delay insensitive to eMBB/mMTC load, taken as proof of per-UPF isolation) requires that the namespace-aware TC-BPF tool correctly tags and timestamps only the intended slice traffic, adds negligible latency, and does not alter container scheduling. The abstract states the framework \"resolves the fundamental obstacle\" but supplies no overhead micro-benchmarks, ground-truth comparison against raw skb timestamps, or cross-namespace leakage test. If any of those three properties fail, the observed flat URLLC tail and the <200 µs N4 numbers cannot be attributed to isolation rather than measurement bias.","agreement_with_reader":"agree"},"referee_report":{"model":"grok-4.3","summary":"The paper reports an empirical measurement study of forwarding latencies in a containerized open5GS 5G UPF under concurrent eMBB, URLLC, and mMTC slices. A custom namespace-aware TC-BPF framework is introduced to attribute N3-to-N6 delays to individual slices; approximately 28 million matched delay pairs are collected across light/medium/heavy loads. Results show eMBB 99th-percentile delay rising from 574 µs to 1243 µs with load, URLLC delay remaining load-insensitive (taken as evidence of per-UPF isolation), mMTC exhibiting wide TCP tails, and N4 PFCP session-modification latency staying below 200 µs independent of data-plane load. Code, scripts, and dataset schema are released publicly.","tokens_in":1923,"tokens_out":582,"duration_ms":20004,"significance":"If the instrumentation framework is shown to be accurate and overhead-free, the work supplies one of the first open, large-scale characterizations of multi-slice UPF behavior in containerized deployments. The 28-million-pair sample size, the concrete timing headroom result for AI-driven orchestration, and the public release of artifacts are clear strengths. The isolation finding for URLLC would directly inform 5G slice design and control-plane budgets.","major_comments":[{"comment":"Abstract and framework description: the central claim that the namespace-aware TC-BPF framework 'resolves the fundamental obstacle' of per-slice attribution is load-bearing for all subsequent results, yet the manuscript supplies no overhead micro-benchmarks, no ground-truth comparison against raw skb timestamps, and no cross-namespace leakage or scheduling-interference tests. Without these, the observed flat URLLC tail cannot be attributed to isolation rather than measurement artifact.","section":"Abstract / Methods (TC-BPF framework)"},{"comment":"Results section on URLLC delay: the conclusion that 'URLLC delay is load-insensitive, confirming per-UPF process isolation' rests entirely on the unvalidated attribution accuracy of the TC-BPF tool under concurrent slice traffic. A concrete validation experiment (e.g., known single-slice ground truth or synthetic cross-namespace injection) is required before the isolation interpretation can be accepted.","section":"Results (URLLC latency analysis)"}],"minor_comments":[{"comment":"The exact matching criteria and timestamp sources used to produce the 28 million delay pairs should be stated explicitly rather than summarized as 'approximately'.","section":"Methods"},{"comment":"Figure captions and axis labels for the delay distributions should include the precise load definitions (light/medium/heavy) and the number of samples per condition.","section":"Figures"}],"recommendation":"major_revision","confidential_remarks":null},"author_rebuttal":{"model":"grok-4.3","summary":"We thank the referee for the detailed and constructive review. The two major comments both highlight the need for explicit validation of the TC-BPF framework's accuracy and overhead. We agree these elements are necessary to support the isolation interpretation and will add the requested experiments and benchmarks in the revised manuscript.","responses":[{"response":"We acknowledge that the current manuscript does not include dedicated overhead micro-benchmarks, ground-truth comparisons against raw skb timestamps, or explicit cross-namespace leakage and scheduling-interference tests. While the framework is built on standard TC-BPF primitives whose low overhead is documented in the kernel literature, the absence of these targeted validations in the paper leaves the attribution accuracy open to question. In the revised version we will add a dedicated validation subsection that reports: (1) micro-benchmark overhead (instrumented vs. uninstrumented forwarding latency under identical loads), (2) ground-truth comparison using single-slice traffic with known synthetic delays, and (3) cross-namespace injection and leakage tests. These additions will allow readers to assess whether the flat URLLC tail reflects isolation or measurement artifact.","revision_made":"yes","referee_comment":"[Abstract / Methods (TC-BPF framework)] Abstract and framework description: the central claim that the namespace-aware TC-BPF framework 'resolves the fundamental obstacle' of per-slice attribution is load-bearing for all subsequent results, yet the manuscript supplies no overhead micro-benchmarks, no ground-truth comparison against raw skb timestamps, and no cross-namespace leakage or scheduling-interference tests. Without these, the observed flat URLLC tail cannot be attributed to isolation rather than measurement artifact."},{"response":"The referee is correct that the isolation claim for URLLC depends on the accuracy of the per-slice attribution. The 28-million-pair dataset and the observed load-insensitivity are consistent with isolation, yet without the validation experiments noted above we cannot rule out measurement artifacts. We will therefore revise the Results section to present the new validation data first, then re-state the isolation conclusion only after those results are shown. This will also include a brief discussion of any residual limitations of the TC-BPF approach under heavy concurrent load.","revision_made":"yes","referee_comment":"[Results (URLLC latency analysis)] Results section on URLLC delay: the conclusion that 'URLLC delay is load-insensitive, confirming per-UPF process isolation' rests entirely on the unvalidated attribution accuracy of the TC-BPF tool under concurrent slice traffic. A concrete validation experiment (e.g., known single-slice ground truth or synthetic cross-namespace injection) is required before the isolation interpretation can be accepted."}],"tokens_in":1554,"tokens_out":559,"duration_ms":15747,"standing_objections":[]},"desk_editor":{"model":"grok-4.3","letter":"This paper reports the first open measurements of forwarding latency for multiple 5G slices in a containerized UPF. They use a custom TC-BPF tool to attribute delays to individual slices and run tests with eMBB, URLLC, and mMTC under different loads.\n\nThe new part is the namespace-aware instrumentation that lets them do per-container timing, which prior tools couldn't handle. Collecting 28 million matched delay pairs gives them a good basis for the results: eMBB delay increases with load at the tail, URLLC does not, and N4 latency stays low. Releasing the framework, scripts, and dataset schema is useful for others who want to replicate or extend this.\n\nThe soft spot is the lack of visible validation for the measurement tool. The isolation claim for URLLC rests on the BPF code correctly identifying slice traffic and not changing the observed delays. The abstract does not mention overhead measurements or tests for missed packets or scheduling interference. That detail matters because if the tool has any bias, the load-insensitivity result could be affected.\n\nReaders working on 5G core performance, network slicing, or AI-based orchestration will find the numbers and the released artifacts directly useful. The paper is a solid observational study with no circular reasoning, so it deserves a serious referee to check the implementation details and suggest any missing controls.\n\nI would recommend sending it out for peer review.","headline":"This paper gives the first open per-slice UPF latency numbers from a containerized open5GS setup plus a released TC-BPF tool for attribution, but the tool's accuracy and overhead are not shown to be validated.","tokens_in":2378,"tokens_out":375,"would_cite":true,"duration_ms":22091,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"grok-4.3","headline":"Containerised 5G UPF isolates URLLC forwarding delay from load while eMBB delay grows at the 99th percentile.","keywords":["5G Core","UPF","Latency Measurement","Network Slicing","Containerisation","BPF","open5GS","URLLC"],"falsifier":"A measurable increase in URLLC forwarding delay under heavy load on the same open5GS platform would falsify the load-insensitivity claim.","tokens_in":2697,"feed_emoji":"","tokens_out":636,"duration_ms":13367,"temperature":0.7,"pith_summary":"This paper measures forwarding and control latencies in a containerised open5GS User Plane Function running three concurrent slices under light, medium, and heavy loads. It introduces a namespace-aware TC-BPF instrumentation framework to attribute observed delays to individual slices. The results establish that URLLC delay remains load-insensitive, confirming per-UPF process isolation, whereas eMBB delay is load-sensitive and mMTC exhibits wide-tail behaviour. N4 PFCP session modification latency stays below 200 microseconds across all conditions. The framework, scripts, and dataset are released publicly.","feed_headline":"URLLC delay stays load-insensitive in containerised 5G UPF","feed_subtitle":"Measurements on open5GS with three slices show stable URLLC tails and N4 latency below 200 us while eMBB grows with load.","key_machinery":"The namespace-aware TC-BPF instrumentation framework that attributes latency observations to individual containerised network functions.","core_discovery":"In a containerised open5GS deployment with eMBB, URLLC, and mMTC slices, the UPF shows load-insensitive URLLC forwarding delay and N4 PFCP latencies consistently below 200 microseconds regardless of data-plane load, while eMBB 99th-percentile delay grows from 574 to 1,243 microseconds; these observations are obtained via a namespace-aware TC-BPF framework that resolves latency attribution across container namespaces.","pith_inferences":["The observed isolation suggests containerised UPF deployments can meet URLLC timing targets without additional inter-slice scheduling mechanisms.","The released dataset enables direct comparison against other container runtimes or orchestration algorithms.","Similar per-slice attribution could be applied to measure control-plane functions beyond the N4 interface."],"forward_implications":["URLLC traffic can be managed within the two-millisecond budget assumed by AI-driven UPF orchestration because control latency remains below 200 microseconds.","Per-UPF process isolation holds for URLLC slices under simultaneous multi-slice workloads.","eMBB slice performance requires explicit accounting for load-dependent tail latencies.","mMTC slice behaviour follows wide-tail TCP patterns independent of the other slices."],"fun_headline_variants":["UPF latency measured per slice in containerised 5G setup","URLLC remains load-insensitive in open5GS with three slices","eMBB delay grows with load while URLLC stays stable","N4 PFCP latency below 200us independent of data plane load","BPF instrumentation attributes UPF delays to individual slices"],"cache_read_input_tokens":2112,"weakest_assumption_plain":"The namespace-aware TC-BPF framework accurately attributes observed latencies to individual slices without introducing measurable overhead, missing cross-namespace traffic, or altering container scheduling behavior.","fun_headline_variants_meta":{"raw":{"variants":["UPF latency measured per slice in containerised 5G setup","URLLC remains load-insensitive in open5GS with three slices","eMBB delay grows with load while URLLC stays stable","N4 PFCP latency below 200us independent of data plane load","BPF instrumentation attributes UPF delays to individual slices"]},"model":"grok-4.3","cost_usd":0.005264,"raw_usage":{"total_tokens":2593,"prompt_tokens":760,"num_sources_used":0,"completion_tokens":84,"cost_in_usd_ticks":52637000,"prompt_tokens_details":{"text_tokens":760,"audio_tokens":0,"image_tokens":0,"cached_tokens":256},"completion_tokens_details":{"audio_tokens":0,"reasoning_tokens":1749,"accepted_prediction_tokens":0,"rejected_prediction_tokens":0}},"tokens_in":760,"tokens_out":84,"duration_ms":13215,"temperature":1.0,"reasoning_tokens":1749,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-06-29T09:49:00.958489+00:00","model_set":{"reader":"grok-4.3"},"falsifier":"A measurable increase in URLLC forwarding delay under heavy load on the same open5GS platform would falsify the load-insensitivity claim.","supporting_citations":[],"review_version":1}