Pith. sign in

REVIEW 2 major objections 2 minor 14 references

Kernel-Level Per-Slice UPF Latency Measurement in Containerised 5G Core Networks

T0 review · 2 major / 2 minor · reviewed 2026-06-29 · grok-4.3

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Containerised 5G UPF isolates URLLC forwarding delay from load while eMBB delay grows at the 99th percentile.

desk verdict 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. read the letter →

arxiv 2605.28185 v1 pith:KC5WGG6Q submitted 2026-05-27 cs.NI

Akhil Dev Mishra , Mayank Pandey This is my paper · ORCID
classification cs.NI
keywords 5GCoreUPFLatencyMeasurementNetworkSlicingContainerisationBPFopen5GSURLLC
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

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.

What carries the argument

The namespace-aware TC-BPF instrumentation framework that attributes latency observations to individual containerised network functions.

What would settle it

A measurable increase in URLLC forwarding delay under heavy load on the same open5GS platform would falsify the load-insensitivity claim.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

  • 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.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • 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.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

2 major / 2 minor

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.

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 (2)
  1. [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.
  2. [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.
minor comments (2)
  1. [Methods] The exact matching criteria and timestamp sources used to produce the 28 million delay pairs should be stated explicitly rather than summarized as 'approximately'.
  2. [Figures] 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.

Simulated Author's Rebuttal

2 responses · 0 unresolved

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.

read point-by-point responses

  1. Referee: [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.

    Authors: 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: yes

  2. Referee: [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.

    Authors: 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: yes

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: pure observational measurement study with no fitted models or self-referential derivations.

full rationale

The paper reports empirical latency measurements from a containerised 5G testbed using a custom TC-BPF framework. It collects ~28 million delay pairs under varying loads and reports observed trends (e.g., URLLC delay load-insensitive). No equations, parameters fitted to subsets of the data, predictions, or uniqueness theorems appear. The central claim (per-UPF isolation) is presented as an interpretation of the raw observations rather than a quantity derived from any internal definition or prior self-citation. The instrumentation framework is described as a tool, not a model whose accuracy is proven by the same measurements it produces. This is a standard empirical study whose results stand or fall on external validation of the measurement method, not on internal circular reduction.

Assumptions & free parameters 0 free parameters · 1 assumptions · 0 invented entities

No free parameters or invented entities; the work rests on the domain assumption that the open5GS container deployment plus the new measurement tool faithfully captures production-like slice behavior.

assumptions (1)
  • domain assumption The open5GS containerized deployment with three concurrent slices accurately models the isolation and scheduling behavior of production 5G core UPFs.
    All latency and isolation claims are conditioned on this platform choice.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Kernel-Level Per-Slice UPF Latency Measurement in Containerised 5G Core Networks." pith.science (2026). https://pith.science/paper/KC5WGG6Q

@misc{pith2026260528185,
  author       = {Pith},
  title        = {Pith review of: Kernel-Level Per-Slice UPF Latency Measurement in Containerised 5G Core Networks},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/KC5WGG6Q}},
  note         = {Machine review of arXiv:2605.28185}
}
read the original abstract

The 5G Core User Plane Function is responsible for packet forwarding, GTP-U decapsulation, and quality of service enforcement for every user data session. How the UPF behaves under simultaneous multi-slice workloads remains empirically uncharacterised in the open literature. Specifically, how its forwarding latency responds to load, how well it isolates one slice from another, and what timing budgets remain available for intelligent control are all open questions. This paper presents a measurement study conducted on a containerised open5GS deployment with three concurrent network slices. We design and implement a namespace-aware TC-BPF instrumentation framework that resolves the fundamental obstacle preventing existing tools from attributing latency observations to individual containerised network functions. We deploy eMBB, URLLC, and mMTC slices with realistic application traffic under light, medium, and heavy load conditions and collect approximately 28 million matched N3 to N6 forwarding delay pairs. The gathered results reveal that eMBB forwarding delay is load-sensitive with the 99th percentile growing from 574 to 1,243 microseconds across load conditions. URLLC delay is load-insensitive, confirming per-UPF process isolation. mMTC exhibits wide-tail TCP behaviour. On this platform, N4 PFCP session modification latency remains consistently below 200 microseconds regardless of data-plane load, suggesting substantial timing headroom within the two-millisecond budget assumed by AI-driven UPF orchestration designs. The instrumentation framework, experiment scripts, and dataset schema are released at https://github.com/MP-Akhil-5G/open5gs-slice-measurement.

Figures

Figures reproduced from arXiv: 2605.28185 by the authors.

Figure 1
Figure 1. Measurement platform. Five Incus containers on [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. N3→N6 UPF forwarding delay CDFs under three load conditions. eMBB exhibits load-sensitive tail growth. URLLC curves overlap closely across load conditions, consistent with per-UPF slice isolation. mMTC shows wide-tail TCP behaviour. Kernel attachment: The BPF verifier rejected pointer arith￾metic on GTP-U header fields without explicit bounds checks. This was resolved by adding bounds checks before every pointer der… view at source ↗
Figure 3
Figure 3. N4 PFCP session establishment (left) and modification (right) latency [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

14 extracted references · 3 canonical work pages

  1. [1]

    System architecture for the 5g system (5GS),

    3GPP, “System architecture for the 5g system (5GS),” 3rd Generation Partnership Project, Tech. Rep. TS 23.501, 2024, release 18

    2024

  2. [2]

    Leveraging programmable dataplanes for a high performance 5G user plane function,

    S. Boseet al., “Leveraging programmable dataplanes for a high performance 5G user plane function,” inProc. ACM APNet, 2021

    2021

  3. [3]

    AccelUPF: Accelerating the 5G user plane using programmable hardware,

    ——, “AccelUPF: Accelerating the 5G user plane using programmable hardware,” inProc. ACM SOSR, 2022

    2022

  4. [4]

    Rewiring the 5G data plane: XDP/eBPF in the fast lane of UPF,

    T. J. Podobnik, “Rewiring the 5G data plane: XDP/eBPF in the fast lane of UPF,”eBPFChirp Newsletter, Aug. 2025

    2025

  5. [5]

    A scalable and fault-tolerant 5G core on Kubernetes,

    S. Paulet al., “A scalable and fault-tolerant 5G core on Kubernetes,” in Proc. IEEE COMSNETS, 2025

    2025

  6. [6]

    Vulnerability analysis of eBPF-enabled containerized deployments of 5G core networks,

    Y . Deshpande and S. Bera, “Vulnerability analysis of eBPF-enabled containerized deployments of 5G core networks,”arXiv:2603.19867, 2026

    work page arXiv 2026

  7. [7]

    MMT Studio — 5G core + tester + orchestration,

    MakeMyTechnology, “MMT Studio — 5G core + tester + orchestration,” https://github.com/Makemytechnology/mmt-studio-5g6g, 2026

    2026

  8. [8]

    Optimizing edge gaming slices through an enhanced UPF and analytics in beyond-5G networks,

    R. Moreiraet al., “Optimizing edge gaming slices through an enhanced UPF and analytics in beyond-5G networks,”arXiv:2507.17843, 2025

    work page arXiv 2025

Show all 14 references
  1. [9]

    Inside 5G: Monitoring and fast chaining,

    A. Chakraborty, “Inside 5G: Monitoring and fast chaining,” IIT Bombay, Tech. Rep., 2025, r&D-II Report

    2025

  2. [10]

    Towards NWDAF-enabled analytics and closed-loop automation in 5G networks,

    F. S. Ardestani, N. Saha, N. Limam, and R. Boutaba, “Towards NWDAF-enabled analytics and closed-loop automation in 5G networks,” arXiv:2505.06789, 2025

    2025

  3. [11]

    5G wireless network slicing for eMBB, URLLC, and mMTC: A communication-theoretic view,

    P. Popovskiet al., “5G wireless network slicing for eMBB, URLLC, and mMTC: A communication-theoretic view,”IEEE Access, vol. 6, pp. 55 765–55 779, 2018

    2018

  4. [12]

    Network slicing for eMBB, URLLC, and mMTC: An uplink rate-splitting multiple access approach,

    Y . Liuet al., “Network slicing for eMBB, URLLC, and mMTC: An uplink rate-splitting multiple access approach,”IEEE Trans. Wireless Commun., vol. 23, 2024

    2024

  5. [13]

    Demonstration of 5G core software system in India’s indigenous 5G test bed,

    B. N. Koonampilliet al., “Demonstration of 5G core software system in India’s indigenous 5G test bed,” inProc. IEEE COMSNETS, 2021

    2021

  6. [14]

    Development of MEC system for indigenous 5G test-bed,

    A. A. Kheraniet al., “Development of MEC system for indigenous 5G test-bed,” inProc. IEEE COMSNETS, 2021

    2021

Pith tools

Reviewed June 29, 2026 · model on record in the stance chip above.