5GC-Bench: 5G Core Benchmarking Framework

• 5GC-Bench is a modular, open-source framework that benchmarks 5G Core VNFs by jointly emulating signaling and user-plane traffic.
• The framework profiles individual VNFs and complete service chains, exposing resource bottlenecks and cross-VNF dependencies.
• Deployment with OpenAirInterface on a real 5G testbed validates its reproducibility and practical impact on capacity planning.

5GC-Bench is a modular, open-source framework for stress-testing and benchmarking 5G Core (5GC) virtual network functions (VNFs) under realistic and diverse workloads. It is designed for a disaggregated, cloud-native 5GC in which control-plane procedures involve complex interactions across multiple VNFs and the user plane must sustain diverse and resource-intensive traffic. Its distinguishing feature is joint emulation of signaling and service traffic, enabling both fine-grained VNF profiling and end-to-end service-chain analysis. The framework was integrated with the OpenAirInterface (OAI) 5GC and deployed on a real 5G testbed, where it was used to uncover resource constraints and cross-VNF dependencies under scenarios that mirror operational 5G deployments; all artifacts were publicly released to support reproducibility (Panitsas et al., 22 Sep 2025).

1. Problem setting and benchmark scope

The design rationale for 5GC-Bench follows directly from the structure of the 5G Core. The cloud-native decomposition of the core into multiple VNFs improves flexibility and scalability, but it also complicates evaluation because control-plane performance is not reducible to a single function and user-plane behavior is not adequately captured by a single synthetic throughput test. The paper identifies three recurring shortcomings in earlier tooling: benchmarking control and user planes in isolation, reliance on synthetic workloads, and limited visibility into fine-grained resource usage (Panitsas et al., 22 Sep 2025).

Within this setting, 5GC-Bench targets two levels of analysis. At the first level, it profiles individual VNFs by observing how resource consumption changes as specific procedures or traffic mixes intensify. At the second level, it evaluates complete service chains, including signaling chains such as registration and PDU session setup, to expose compounded bottlenecks and cross-VNF dependencies. This dual scope is central to its role as a benchmarking framework rather than a narrowly scoped load generator (Panitsas et al., 22 Sep 2025).

The framework sits within a broader measurement landscape but addresses a distinct combination of concerns. One line of work benchmarks 5G MEC and Cloud infrastructures for IoT messaging using end-to-end application latency, packet loss, network RTT, and 5G throughput, with scenarios varied by platform type, number of producers, and anonymization scheme (Mogollón et al., 2023). Another line compares open-source 5GC platforms such as Free5GC, OAI, and Open5GS on control-plane latencies, data-plane throughput and latency, and CPU/RAM usage (Barbosa et al., 2024). A third line, represented by my5G Tester, emphasizes NAS and NGAP conformance and robustness through black-box testing of open-source 5GCs (Dominato et al., 2021). 5GC-Bench is distinguished by combining concurrent control-plane and user-plane stress generation with per-VNF telemetry in a real 5G testbed (Panitsas et al., 22 Sep 2025).

2. Framework architecture

The architecture comprises five named components that together define the benchmark lifecycle, from scenario specification to synchronized telemetry collection.

Component	Function
Scenario Manager	User-facing interface for defining benchmarks
Orchestrator	Manages experiment lifecycle and scenario realization
Control-Plane Load Injector (CPLI)	Generates standards-compliant signaling procedures
User-Plane Load Injector (UPLI)	Tunnels realistic or synthetic service traffic through the 5GC
Telemetry Collector	Monitors and records per-VNF metrics

The Scenario Manager is the entry point for benchmark definition. It allows specification of which VNFs to stress, which workload types to use, and which experiment parameters to apply. The Orchestrator translates this configuration into concrete scenarios, controls timing, initializes VNFs, and sets up the emulation environment. In effect, it binds workload generation and deployment control into a reproducible experiment workflow (Panitsas et al., 22 Sep 2025).

The Control-Plane Load Injector generates standards-compliant signaling procedures and can target either individual VNFs or end-to-end signaling chains. The examples provided include targeting AMF or SMF directly, and exercising multi-VNF chains such as user registration and PDU session setup. The User-Plane Load Injector carries service traffic through the 5GC and supports statistical multiplexing, so that diverse application mixes and burstiness can be emulated rather than approximated by constant-rate flows (Panitsas et al., 22 Sep 2025).

The Telemetry Collector records per-VNF metrics for CPU, memory, and network I/O at fine, 1 s granularity. These measurements are timestamped and aligned with workload events, which is essential for associating workload phases with resource spikes, persistent state retention, and cross-VNF propagation effects. A plausible implication is that the framework is intended not merely to report endpoint performance but to support causal diagnosis of bottlenecks across a service chain (Panitsas et al., 22 Sep 2025).

3. Workload emulation model

5GC-Bench supports both control-plane and user-plane workload emulation, and it can run them concurrently. For the control plane, it emulates procedures such as registration and authentication involving AMF, SMF, AUSF, UDM, UDR, and NRF. The framework supports bursty and random arrival patterns sourced from real datasets, with Telecom Italia explicitly cited. This emphasis on empirical arrival structure is important because it replaces purely synthetic request generation with traces intended to resemble operational signaling behavior (Panitsas et al., 22 Sep 2025).

For the user plane, the framework models dominant mobile service profiles including YouTube, Instagram, Browsing, and Gaming. These profiles are derived from empirical traces, with NetMob23 and TelecomTS cited, and are replayed at scale with session distributions matching real base-station activity. The User-Plane Load Injector can use realistic or synthetic service traffic, but the benchmark focus is on traffic that reflects observed service mixes and burstiness rather than simplified uniform loads (Panitsas et al., 22 Sep 2025).

Configurability is explicit. Benchmark users can specify stress test mode—control, user, or joint—the number of simulated UEs, session durations, arrival rates, and the datasets or traffic profiles to be used. Both targeted VNF stress and end-to-end chain analysis are supported. This means that the same framework can be used to isolate the behavior of a single function such as AMF or UPF, and also to measure the interaction of multiple control-plane functions under procedures such as registration or PDU session establishment (Panitsas et al., 22 Sep 2025).

A common misconception in 5GC evaluation is that realistic traffic automatically follows from high request volume or high throughput. The design of 5GC-Bench indicates a narrower and more technical definition of realism: standards-compliant signaling, empirical burst distributions, empirical service traces, and statistical multiplexing of application profiles. This suggests that realism is treated as a property of temporal structure and service composition, not only of aggregate load (Panitsas et al., 22 Sep 2025).

4. Measurement methodology and profiling workflow

The benchmarking workflow is organized into five stages. First, an experiment is defined through the Scenario Manager, including the selection of control-plane and user-plane workloads and the choice of VNFs or service chains. Second, the Orchestrator provisions the required VNFs, such as OAI 5GC, along with emulated gNodeBs, UEs, and the surrounding environment. Third, CPLI and UPLI execute their respective workloads concurrently, following real-world base-station or service-level arrival patterns. Fourth, the Telemetry Collector gathers metrics per VNF and aligns them with workload phases. Fifth, the resulting trace and log data are analyzed to localize bottlenecks, study cross-VNF impacts, and model resource demand (Panitsas et al., 22 Sep 2025).

The collected metrics cover both per-VNF and experiment-level observations. Computation metrics include CPU usage in millicores and cycles consumed per event or type. Memory is reported as memory footprint in MB. Network I/O includes packet rates in and out per interface and per service. Temporal correlation is preserved through event and metric timestamping. This metric set goes beyond headline measures such as throughput and latency by exposing the resource footprint associated with specific procedures, service mixes, and burst intervals (Panitsas et al., 22 Sep 2025).

The framework supports two profiling modes that recur throughout the reported experiments. In control-plane profiling, a single VNF can be stressed—for example, AMF under user registration requests based on Telecom Italia burst distributions—or an end-to-end signaling chain can be exercised, such as PDU session setup across AMF, SMF, AUSF, UDM, UDR, and NRF during a 200-session burst. In user-plane profiling, the UPLI replays YouTube, Browsing, Instagram, and Gaming profiles for 100–500 sessions and also constructs mixed workloads through statistical multiplexing (Panitsas et al., 22 Sep 2025).

The methodological significance of this workflow lies in the alignment of traffic generation and telemetry. Because metrics are gathered at 1 s granularity and synchronized with workload events, it becomes possible to distinguish transient spikes from persistent post-burst elevation, and local VNF stress from service-chain propagation. This suggests that 5GC-Bench is designed for explanatory benchmarking, not merely comparative scorekeeping (Panitsas et al., 22 Sep 2025).

5. Empirical findings on resource behavior and bottlenecks

The reported control-plane experiments show that CPU usage scales linearly with signaling volume, while memory increases when session or context state is retained after a burst. In end-to-end service-chain experiments, load amplifies across the chain rather than remaining confined to the VNF that first receives the request stream. During a 200-session PDU session setup burst, the chain involving AMF, SMF, AUSF, UDM, UDR, and NRF exhibited this amplification effect, illustrating that control-plane stress must be interpreted as a distributed phenomenon rather than a single-node event (Panitsas et al., 22 Sep 2025).

The reported user-plane experiments isolate the UPF under both single-application and mixed-application traffic. For 100–500 sessions, memory usage is described as nearly flat at 4–5 MB, whereas CPU increases proportionally with session count and is highest for video-heavy workloads. In scenarios mirroring multiple adjacent busy cells, UPF CPU usage exceeded 800 millicores with approximately 2,000 connections. The paper therefore identifies CPU, not memory, as the primary bottleneck for high-throughput, video-heavy user-plane workloads (Panitsas et al., 22 Sep 2025).

The framework also exposes cross-VNF dependencies. AMF, SMF, and UDM are identified as CPU-bound VNFs, especially under high signaling or during session bursts. UDR is identified as memory-bound because of subscription data caching. Stress in one function, such as AMF during a registration storm, cascades into heavy CPU and memory spikes in chained VNFs including AUSF, UDM, UDR, and NRF. High concurrent signaling or data sessions can saturate host CPU even when memory or I/O remain underutilized, which indicates that aggregate host utilization can be misleading if bottlenecks are diagnosed only from coarse system-level summaries (Panitsas et al., 22 Sep 2025).

Another reported effect is post-burst persistence. After a signaling or traffic storm, CPU and memory utilization do not always subside immediately, because session or context persistence keeps resource demand elevated. This matters for capacity planning because short bursts may produce longer-lived resource pressure than their duration alone would suggest. The paper also reports placement implications: collocating multiple CPU-heavy VNFs on the same node risks contention, whereas combining memory-bound and CPU-bound functions may optimize host utilization and reduce contention. These are presented as operational implications derived from observed resource asymmetries across functions (Panitsas et al., 22 Sep 2025).

6. Deployment, reproducibility, and relation to adjacent evaluation approaches

The implementation described in the paper integrates 5GC-Bench with the OpenAirInterface 5GC. OAI’s containerized 5GC version 2.1.0 is run as Docker containers per VNF and interconnected over a bridge. The testbed uses a dual-server setup based on AMD EPYC 7352 with 24 cores and 128 GB RAM, with one server operating as the core and the other as the RAN. Traffic is generated using gNBSIM for UEs, with both OTA and emulated traffic considered. No modifications are required to OAI 5GC; 5GC-Bench functions as an external plugin that controls and monitors the deployment through APIs and shell scripts (Panitsas et al., 22 Sep 2025).

This implementation choice is noteworthy when viewed alongside comparative studies of open-source 5GC platforms. In a separate evaluation, OAI delivered the highest data rates and the lowest latency among Free5GC, OAI, and Open5GS, while also exhibiting the highest CPU consumption; Open5GS had the best control-plane latencies, and Free5GC had the lowest CPU and RAM usage (Barbosa et al., 2024). This suggests that using OAI as the substrate for 5GC-Bench is consistent with an interest in stressing user-plane performance and exposing CPU-centric bottlenecks, although that interpretation remains inferential rather than directly stated in the 5GC-Bench paper.

The framework’s benchmark orientation is also complementary to protocol-level test systems. The tutorial and tooling around my5G Tester emphasize NAS and NGAP message flows, conformance tests with valid messages, robustness tests with malformed or out-of-sequence messages, and black-box evaluation of open-source 5GCs (Dominato et al., 2021). By contrast, 5GC-Bench emphasizes realistic workload emulation, per-VNF telemetry, and service-chain stress. A plausible implication is that these approaches address different layers of assurance: protocol correctness and robustness on one side, and capacity, bottleneck localization, and resource-performance characterization on the other.

Reproducibility is treated as a first-class property. The paper states that all artifacts, code, datasets, and deployment scripts are publicly released, and the abstract likewise notes public release of all artifacts to foster further research (Panitsas et al., 22 Sep 2025). In the context of 5G benchmarking, where deployment choices, workload realism, and instrumentation often limit comparability, this release policy is itself part of the contribution.