1
Kernel-Level Per-Slice UPF Latency Measurement in Containerised 5G Core Networks
arXiv:2605.28185v1 [cs.NI] 27 May 2026
Akhil Dev Mishra and Mayank Pandey
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 µs 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 µs 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. Index Terms—5G Core, User Plane Function, network slicing, eBPF, TC-BPF, PFCP, forwarding delay, measurement, open5GS, UERANSIM
Each network function runs inside a dedicated Linux network namespace. Standard host-level eBPF probes cannot be scoped to individual containers because the interfaces inside a container are not visible from the host namespace. This is the key reason no published measurement study has reported perslice forwarding delay distributions from a containerised 5GC deployment with simultaneous multi-slice traffic. This paper makes four contributions. First, a namespaceaware TC-BPF instrumentation framework that attaches measurement programs to each UPF network namespace via nsenter, resolving the container attribution problem without modifying 5GC software. Second, documentation of nineteen instrumentation obstacles encountered during development and their resolutions, providing a reproducible methodology for the community. Third, a dataset of approximately 28 million matched N3 to N6 forwarding delay pairs across three slice types and three load conditions on open5GS v2.7.6 with UERANSIM v3.2.7. Fourth, empirical characterisation of N4 PFCP session modification latency suggesting a sub-200 µs lower bound with substantial headroom relative to the twomillisecond budget assumed by AI-driven UPF orchestration designs. The instrumentation framework, experiment scripts, analysis code, and dataset schema are released publicly at https://github.com/MP-Akhil-5G/open5gs-slice-measurement. II. R ELATED W ORK
UPF performance has been studied primarily from a throughput and acceleration perspective. Bose et al. [2] evaluated The 5G Core is designed as a Service Based Architecture DPDK-based and SmartNIC-based UPF prototypes and rewhere the User Plane Function (UPF) sits at the centre of ported mean forwarding latency of 176 µs for synthetic traffic. every data session. In a network slicing deployment, the AccelUPF [3] offloaded PFCP processing to Intel Tofino Session Management Function (SMF) assigns each traffic hardware, achieving 4.3 million messages per second. A class to a dedicated UPF instance and may dynamically re- community benchmark [4] compared open5GS, free5GC, eUPF, anchor sessions via the Uplink Classifier (ULCL) architecture and UPG-VPP under single-slice synthetic traffic. None of to steer traffic toward Multi-access Edge Computing (MEC) these works report per-slice forwarding delay distributions hosts [1]. These capabilities require the SMF to make UPF under simultaneous multi-slice realistic workloads. selection decisions within tight latency budgets. How long Cloud-native 5GC deployment has been studied by Paul et those decisions can take depends on how long PFCP session al. [5], who evaluated a Kubernetes-based 5GC and quantified modification itself takes. This value has not been empirically control-plane registration overhead. Deshpande and Bera [6] measured in open-source 5G Core deployments. analysed eBPF-based vulnerability surfaces in containerised Measuring UPF behaviour in a containerised 5G Core (5GC) open5GS. MakeMyTechnology MMT Studio [7] is a recent deployment presents a fundamental instrumentation obstacle. open-source 5G Core written in Go with 545 control plane test cases and a DPDK UPF. It provides no data plane forwarding A. D. Mishra and M. Pandey are with the Department of Computer Science and Engineering, Motilal Nehru National Institute of Technology Allahabad, delay measurement capability. Prayagraj, India (e-mail: {akhil.2025rcs22, mayankpandey}@mnnit.ac.in). NWDAF-driven observability has been studied by Moreira This work was conducted at the GoI 5G Use-Case Laboratory, MNNIT et al. [8], who measured application round-trip time for Allahabad. Manuscript received May 2026. edge gaming slices. Chakraborty [9] developed RAN-layer I. I NTRODUCTION
2
TABLE I P LATFORM C ONFIGURATION Container
IP
Slice
DNN
Traffic
upf1 upf2 upf3 amf-smf gnb-ue
10.45.0.11 10.45.0.12 10.45.0.13 10.45.0.10 10.45.0.14
eMBB URLLC mMTC — —
internet voip streaming — —
iperf3 UDP SIPp → Asterisk curl → Nginx open5GS CP UERANSIM
telemetry using OAI and FlexRIC. Neither work measures UPF forwarding delay at the kernel level. Ardestani et al. [10] note that the UPF Event Exposure Service is largely absent from existing NWDAF deployments, further motivating independent kernel-level instrumentation. Network slicing theory for concurrent eMBB, URLLC, and mMTC has been characterised by Popovski et al. [11] and Liu et al. [12] but without empirical UPF forwarding delay validation. The indigenous Indian 5G testbed [13], [14] demonstrates 5GC operation but reports no forwarding delay or PFCP latency measurements. To the best of our knowledge no existing work simultaneously measures per-slice N3 to N6 forwarding delay distributions under simultaneous eMBB, URLLC, and mMTC traffic, resolves the container namespace attribution problem for per-UPF measurement, and establishes N4 PFCP modification latency as an empirical budget for AI-driven orchestration on a reproducible open-source platform.
Fig. 1. Measurement platform. Five Incus containers on br5gc. TC-BPF probes M1 (eth0 ingress) and M3 (ogstun ingress) attach inside each UPF namespace via nsenter. Probe M2 measures N4 PFCP RTT on open5gs-smfd. Dotted lines denote N4 control path.
is M3.ts − M1.ts on the same CLOCK_MONOTONIC_RAW source. M2 is a bpftrace program on the open5gs-smfd sendto and recvfrom syscalls measuring N4 PFCP roundtrip time. B. The Container Namespace Problem
The fundamental obstacle is that each container runs in an isolated Linux network namespace. Host-level probes cannot reach container interfaces. We resolve this by using nsenter -t <UPF_PID> -n to enter each UPF network namespace before attaching TC-BPF programs. This requires no III. M EASUREMENT P LATFORM The platform deploys open5GS v2.7.6 and UERANSIM modification to the container runtime or open5GS source code. v3.2.7 as Incus containers on a single host running Ubuntu The BPF object upf_measure_v2.c contains six sections: 22.04.5 LTS with kernel 6.8.0-111-generic. Five containers are m1_upf1/2/3 on eth0 ingress and m3_upf1/2/3 on interconnected via a Linux bridge br5gc at 10.45.0.0/24. ogstun ingress. Three UPF containers are deployed with dedicated slice assignments as shown in Table I. Each UPF runs a separate C. Instrumentation Overhead open5gs-upfd process and exposes two interfaces. eth0 Each TC-BPF hook executes bpf_ktime_get_ns() and faces the gNB over N3 GTP-U. ogstun serves as the TUN bpf_trace_printk() per packet. This incurs approxidevice for N6 IP delivery. Traffic generators run inside the mately 300 CPU cycles on the Xeon Gold 5218R, bounding the gnb-ue container over GTP-U tunnels on three UE tunnel theoretical per-packet overhead below 90 ns. To validate this interfaces (uesimtun0, uesimtun1, uesimtun2). The bound empirically, we conducted a controlled experiment under complete platform architecture is depicted in Fig. 1. worst-case conditions: 50 Mbps eMBB load over 600 s, with Three load conditions are evaluated. Light load sets iperf3 and without M1 and M3 probes attached to upf1. End-to-end at 5 Mbps and SIPp at 2 calls/s. Medium load sets iperf3 ping RTT was 1.379 ms mean without probes and 1.411 ms at 20 Mbps and SIPp at 4 calls/s. Heavy load sets iperf3 mean with probes. This is a delta of 32 µs (2.3%), consistent at 50 Mbps and SIPp at 8 calls/s. Each experiment runs for with normal run-to-run variation on a software platform. iperf3 600 seconds. All measurements are uplink direction only (UE throughput remained at 50.0 Mbps in both conditions with → UPF). zero packet loss increase. These results confirm that TC-BPF instrumentation introduces no measurable perturbation to the IV. I NSTRUMENTATION F RAMEWORK forwarding path under worst-case load conditions. A. Measurement Points The framework instruments three measurement points. M1 is a TC-BPF program attached to the eth0 ingress hook inside each UPF network namespace. It timestamps GTP-U packet arrival using bpf_ktime_get_ns. M3 is a TC-BPF program attached to the ogstun ingress hook in the same namespace. It timestamps decapsulated IP packet delivery. Forwarding delay
D. Instrumentation Obstacles We encountered and resolved nineteen instrumentation obstacles during development, grouped into five clusters: kernel attachment, interface discovery, timestamp matching, trafficspecific, and runtime stability. Representative examples from each cluster are as follows.
3
TABLE II P ER -S LICE N3→N6 F ORWARDING D ELAY S TATISTICS (600 S RUNS )
Fig. 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.
Slice
Load
N
P50 (µs)
P99 (µs)
eMBB eMBB eMBB
Light Medium Heavy
281 428 1 126 235 2 814 633
66 38 30
574 325 1 243
URLLC URLLC URLLC
Light Medium Heavy
3 624 7 302 14 592
77 61 63
517 314 404
mMTC mMTC mMTC
Light Medium Heavy
4 655 720 10 722 385 9 188 335
23 21 22
2 533 1 934 2 401
Kernel attachment: The BPF verifier rejected pointer arithmetic on GTP-U header fields without explicit bounds checks. This was resolved by adding bounds checks before every pointer dereference, as required for TC programs accessing packet data. Interface discovery: The ogstun interface index changes on each open5gs-upfd restart. This was resolved by reading the current index from /proc/net/if_inet6 inside the UPF namespace at experiment start rather than caching it between runs. Timestamp matching: Five-tuple matching is ambiguous for concurrent UDP flows sharing the same source and destination. Fig. 3. N4 PFCP session establishment (left) and modification (right) latency CDFs. The dashed vertical line marks the 2 ms orchestration budget. All This was resolved by extracting the GTP-U TEID from the modification measurements complete well below 250 µs on this platform. outer header at M1 and using it as the correlation key with a 10 ms matching window. The URLLC forwarding delay is load-insensitive. The P99 Traffic-specific: The default UERANSIM RLS heartvaries between 314 and 517 µs across all load conditions beat threshold of 2000 ms caused UE3 to declare radio link failure under mMTC curl traffic, truncating the without systematic trend. This is consistent with effective formMTC dataset. This was resolved by rebuilding nr-ue warding path isolation provided by per-UPF process separation with HEARTBEAT_THRESHOLD increased to 10 000 ms in from eMBB congestion on this platform. This isolation is architectural. It reflects separate UPF processes rather than src/ue/rls/udp_task.cpp. Runtime stability: The trace_pipe buffer overflowed under intra-UPF QoS scheduling, as the open5GS v2.7.6 UPF does 50 Mbps eMBB load. This was resolved by setting the kernel not enforce Quality Enforcement Rules. The mMTC slice exhibits wide-tail behaviour characteristic trace buffer to 32 MB and processing the trace_pipe as a of TCP traffic. The median remains near 22 µs while the P99 continuous stream rather than in batch mode. The complete obstacle table is available in the repository reaches 1 934 to 2 533 µs across load conditions. This reflects documentation. The parse_tcbpf.awk script matches M1 TCP retransmission behaviour rather than UPF queuing. and M3 events using a per-namespace circular buffer of 500 entries keyed on TEID with a 10 ms matching window. The B. N4 PFCP Session Latency overall match rate exceeds 99.2% across all experiments. Fig. 3 shows the PFCP session latency CDFs. Table III summarises modification latency statistics. V. R ESULTS The PFCP modification P99 is consistently below 200 µs A. Per-Slice Forwarding Delay and insensitive to data-plane load across all three conditions. Fig. 2 shows the forwarding delay CDFs for each slice On this single-host platform this value is approximately ten under all three load conditions. Table II summarises per-slice times below the two-millisecond budget assumed by AI-driven statistics. orchestration designs. This suggests that closed-loop UPF reThe eMBB forwarding delay is load-sensitive. The P99 grows anchoring is timing-feasible within a single PFCP modification from 574 µs under light load to 1 243 µs under heavy load. This round-trip. We note that the single-host loopback deployment is consistent with queuing saturation as throughput approaches represents a lower bound. Distributed deployments with real 50 Mbps on the software UPF. The falling median with N4 network transport will exhibit higher modification latency. increasing load reflects more continuous packet arrival reducing idle time between packets at the UPF. The nonmonotonic P99 VI. C ONCLUSION behaviour (P99 decreases from light to medium before growing sharply at heavy load) is most likely attributable to packet This paper presented a kernel-level measurement study batching, GRO/GSO coalescing, and interrupt moderation in of per-slice UPF forwarding delay and N4 PFCP session the Linux kernel at higher packet rates. latency on a containerised open5GS deployment. We designed
4
TABLE III N4 PFCP S ESSION M ODIFICATION L ATENCY (600 S RUNS ) Load
N
Mean (µs)
P99 (µs)
Light Medium Heavy
41 36 66
125 115 142
197 199 197
and implemented a namespace-aware TC-BPF instrumentation framework. We resolved nineteen instrumentation obstacles and collected a dataset of approximately 28 million matched forwarding delay pairs. The gathered results establish that perUPF process separation provides effective URLLC isolation from eMBB congestion. eMBB forwarding delay exhibits nonmonotonic P99 behaviour consistent with software UPF queuing saturation. PFCP modification latency remains well below the two-millisecond orchestration budget on this platform. The instrumentation framework and dataset are released at https: //github.com/MP-Akhil-5G/open5gs-slice-measurement to enable reproducible research by the community. R EFERENCES [1] 3GPP, “System architecture for the 5g system (5GS),” 3rd Generation Partnership Project, Tech. Rep. TS 23.501, 2024, release 18. [2] S. Bose et al., “Leveraging programmable dataplanes for a high performance 5G user plane function,” in Proc. ACM APNet, 2021. [3] ——, “AccelUPF: Accelerating the 5G user plane using programmable hardware,” in Proc. ACM SOSR, 2022. [4] T. J. Podobnik, “Rewiring the 5G data plane: XDP/eBPF in the fast lane of UPF,” eBPFChirp Newsletter, Aug. 2025. [5] S. Paul et al., “A scalable and fault-tolerant 5G core on Kubernetes,” in Proc. IEEE COMSNETS, 2025. [6] Y. Deshpande and S. Bera, “Vulnerability analysis of eBPF-enabled containerized deployments of 5G core networks,” arXiv:2603.19867, 2026. [7] MakeMyTechnology, “MMT Studio — 5G core + tester + orchestration,” https://github.com/Makemytechnology/mmt-studio-5g6g, 2026. [8] R. Moreira et al., “Optimizing edge gaming slices through an enhanced UPF and analytics in beyond-5G networks,” arXiv:2507.17843, 2025. [9] A. Chakraborty, “Inside 5G: Monitoring and fast chaining,” IIT Bombay, Tech. Rep., 2025, r&D-II Report. [10] 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. [11] P. Popovski et al., “5G wireless network slicing for eMBB, URLLC, and mMTC: A communication-theoretic view,” IEEE Access, vol. 6, pp. 55 765–55 779, 2018. [12] Y. Liu et al., “Network slicing for eMBB, URLLC, and mMTC: An uplink rate-splitting multiple access approach,” IEEE Trans. Wireless Commun., vol. 23, 2024. [13] B. N. Koonampilli et al., “Demonstration of 5G core software system in India’s indigenous 5G test bed,” in Proc. IEEE COMSNETS, 2021. [14] A. A. Kherani et al., “Development of MEC system for indigenous 5G test-bed,” in Proc. IEEE COMSNETS, 2021.