# NexSlice: towards an open and reproducible network slicing testbed for 5G and Beyond

Badii Jouaber, Brahmi Abdenour Yasser, Aba Massinissa Ait, Bouasker

Hadil, Hind Castel-Taleb

► To cite this version:

Badii Jouaber, Brahmi Abdenour Yasser, Aba Massinissa Ait, Bouasker Hadil, Hind Castel-Taleb. NexSlice: towards an open and reproducible network slicing testbed for 5G and Beyond. International Conference on Modeling, Analysis and Simulation of Wireless and Mobile Systems (MSWiM), IEEE, Oct 2025, Barcelona, Spain. hal-05338739

HAL Id: hal-05338739

https://hal.science/hal-05338739v1

Submitted on 30 Oct 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# NexSlice: Towards an Open and Reproducible Network Slicing Testbed for 5G and Beyond

Abdenour Yasser Brahmi

SAMOVAR, Telecom SudParis,
Institut Polytechnique de Paris
Paris, France

abdenour-yasser.brahmi@telecom-sudparis.eu

Massinissa Ait Aba

Davidson Consulting
Paris, France
Massinissa.ait-aba@davidson.fr

Hadil Bouasker

SAMOVAR, Telecom SudParis,
Institut Polytechnique de Paris
Paris, France

hadil.bouasker@telecom-sudparis.eu

Badii Jouaber

SAMOVAR, Telecom SudParis,
Institut Polytechnique de Paris
Paris, France

badii.jouaber@telecom-sudparis.eu

Hind Castel-Taleb

SAMOVAR, Telecom SudParis,
Institut Polytechnique de Paris
Paris, France

hind.castel@telecom-sudparis.eu

**Abstract**—5G and beyond networks aim to support heterogeneous services with strict QoS and isolation requirements. Network slicing addresses these challenges by creating multiple virtual networks over shared infrastructure, each tailored for specific service types. However, despite its potential, the lack of practical, open, and reproducible testbeds for 5G slicing remains a major barrier to experimentation and adoption. In this demo, we present NexSlice, an open-source, Kubernetes-native testbed that enables the deployment and orchestration of 5G core network slices using open-source components like OpenAir-Interface (OAI) and UERANSIM. Our platform supports SST-based slicing, integrates different Radio Access Networks (RANs), enables auto-scaling of user plane functions, and provides real-time monitoring with Prometheus and Grafana. NexSlice aims to bridge the gap between theoretical slicing frameworks and practical, reproducible experimentation, paving the way toward adaptive and automated slice management in future 6G networks.

**Index Terms**—5G; Network Slicing; Kubernetes; OAI; UERANSIM

## I. INTRODUCTION

As network demands increase, 5G and upcoming 6G technologies aim to deliver flexible, scalable connectivity for applications like autonomous vehicles, industrial automation, and immersive AR/VR. These use cases require strict QoS guarantees, achieved through native service differentiation mechanisms such as enhanced Mobile Broadband (eMBB), Ultra-Reliable Low-Latency Communication (URLLC), and massive Machine-Type Communications (mMTC). Network slicing has emerged as a key architectural feature, allowing multiple isolated virtual networks to coexist over shared infrastructure, each tailored to specific performance needs using VNFs like AMF, SMF, and UPF. Despite the growing interest, practical slicing testbeds remain scarce. As noted by Otieno et al. [1], most existing solutions are either closed and commercial, such as Open5GCore or 5G Facility [2], excessively complex when relying on OpenStack-based infrastructures [3], or limited in orchestration capabilities due to the use of

lower-performance environments compared to Kubernetes, as in the case of ORANSlice [4]. To address these gaps, we introduce NexSlice [5], a modular, open-source, Kubernetes-native testbed for 5G and beyond. It provides Helm charts for seamless deployment of all components, from the OAI 5G core and UERANSIM [6] to the disaggregated RAN, along with integrated monitoring via Prometheus and Grafana. For lightweight setups, we also provide a Docker Compose version [7], which lowers entry barriers for experimentation. NexSlice bridges the gap between conceptual frameworks and deployable platforms, enabling reproducible and SST-based slicing experimentation. A demonstration video of NexSlice is available online at [8]. The remainder of this paper describes the testbed, its components, slicing capabilities, and concludes with perspectives.

## II. PROPOSED TESTBED

To validate our slicing approach and facilitate reproducible experimentation, we developed NexSlice, an open-source 5G testbed built entirely on Kubernetes using only open-source components. The platform provides a complete, modular deployment of a full-stack 5G Standalone (SA) system, encompassing the core network, multiple RAN options, and flexible UE simulation. Helm charts are used throughout to automate installation and ensure consistency across deployments. NexSlice also includes integrated observability tools and a custom slice-aware scheduler for advanced orchestration. Figure 1 presents the overall architecture and summarizes the main acronyms used throughout the paper. The following subsections describe each component in detail.

### A. Kubernetes Cluster

Our platform operates on a Kubernetes cluster comprising one master node and two worker nodes, each equipped with a 16-core Intel Xeon Gold 5222 processor and 32 GB of RAM, running Ubuntu 24.04.2 LTS. The cluster uses Kubernetes
<figure><img src="image_2.png" /><figcaption>Fig. 1. NexSlice's Kubernetes-based architecture illustrating the 5G core, RANs, and the network slicing framework, along with main acronyms.</figcaption></figure>

v1.31, Containerd as the container runtime, and Flannel as the CNI. All components including the 5G core, RANs, and UEs are deployed using Helm v3 charts, ensuring modularity and reproducibility. We monitor the system with Prometheus and Grafana, which provide real-time metrics for CPU, memory, and network slice behavior. Cluster management and inspection can be managed either via the CLI (`kubectl`) or through the GUI (`Lens`), enabling real-time control, visualization of pod activity, and dynamic scaling during slicing experiments. Although evaluated on a medium-scale bare-metal cluster, the same Helm charts can also be deployed on lightweight Kubernetes distributions such as k3s or Minikube for smaller setups, ensuring reproducibility across heterogeneous environments.

## B. RANs and UEs

We integrate two RAN types to demonstrate the compatibility of our core slicing framework with both realistic and simulated access networks. First, the disaggregated OAI RAN [9], composed of CU-CP, CU-UP, and DU components, reflects a 3GPP-compliant split architecture. Unlike monolithic RANs, this setup offers modularity, flexibility, and alignment with O-RAN principles. OAI NR-UEs are used with RFsim for simplicity, though real SDRs can also be integrated. Second, we use UERANSIM [6], an open-source simulator for both gNodeB and 5G UEs, capable of emulating traffic and mobility behavior. This dual-RAN support enables comparative experiments between simulated and real radio environments, paving the way for heterogeneous access integration and mixed

deployment scenarios where OAI and UERANSIM coexist. Multiple instances of each RAN can be deployed, and both support slice-aware traffic routing based on Single Network Slice Selection Assistance Information (S-NSSAI). UEs can be assigned to different slices, enabling the evaluation of isolation and differentiated performance.

## C. Core Network and Slicing

We deploy the OAI 5G SA Core [9] v2.1.0 as a set of cloud-native, containerized network functions (NFs) running in individual Kubernetes pods. The deployment follows the 3GPP Release 16 architecture, comprising AMF, SMF, AUSF, NRF, LMF, NSSF, UDM, and UDR for the control plane, and UPF for the user plane. The connection sequence begins with the AMF, which manages UE registration and mobility. It interacts with the AUSF for authentication, using subscription data provided by the UDM/UDR, backed by a MySQL database. All NFs register and discover each other via the NRF. Once authentication is successful, the SMF handles session creation and control, while the UPF forwards traffic between the RAN and external data networks.

We adapted the OAI core to support SST-based slicing, since its default Helm charts only allowed a fixed value of `sst=1`. Core slicing in our platform is enabled by deploying multiple instances of SMF, UPF, and optionally NRF components. Each slice is identified by a unique S-NSSAI, consisting of an SST and an SD (Slice Differentiator). In our setup,
<table><caption>TABLE I
S-NSSAI CONFIGURATION WITH CORRESPONDING DNNs AND UE SUBNETS</caption><thead><tr><td>Color</td><td>SST</td><td>SD</td><td>DNN</td><td>UE IP Subnet</td></tr></thead><tbody><tr><td>Blue</td><td>1</td><td>x</td><td>oai</td><td>12.1.1.0/24</td></tr><tr><td>Red</td><td>2</td><td>x</td><td>oai2</td><td>12.1.2.0/24</td></tr><tr><td>Yellow</td><td>3</td><td>x</td><td>oai3</td><td>12.1.3.0/24</td></tr></tbody></table>

the SST is not used because we only define one instance of each slice type, making differentiation unnecessary. During PDU session establishment, the NSSF selects the appropriate slice and routes the request to the corresponding SMF and UPF pair. Control-plane functions (AMF, UDM, AUSF, and NSSF) are shared across all slices to optimize resource usage, while each SMF/UPF pair remains dedicated to a single slice, ensuring traffic isolation. UEs obtain IP addresses from the SMF, which allocates them based on the corresponding subnet, as summarized in Table I.

As shown in Fig. 2, UEs attach to different slices based on their SST values, with each slice mapped to a distinct subnet and associated Data Network Name (DNN). It is worth noting that in this context, SSTs serve only as numerical identifiers and do not correspond directly to standardized service categories such as eMBB, URLLC, or mMTC.

## D. Slice Orchestration

To enable intelligent orchestration of slices and their associated VNFs, NexSlice integrates SetpodNet [10], a Kubernetes-native, slice-aware scheduler. Unlike the default Kubernetes scheduler, which makes placement decisions pod by pod, SetpodNet considers an entire slice as a holistic unit. Each slice is represented as a virtual graph of VNFs and their communication links, with constraints on CPU, memory, latency, and bandwidth. This graph is then embedded onto the physical cluster topology while minimizing inter-node latency and optimizing resource usage. SetpodNet addresses the Virtual Network Embedding (VNE) problem by incorporating network performance into scheduling decisions. Specifically, it measures latency and bandwidth between nodes and uses these metrics as constraints or soft requirements when placing pods. This ensures that intra-slice affinity is preserved and that communication-intensive VNFs are co-located whenever possible. By doing so, SetpodNet improves QoS compliance and reduces wasted resources from partial or infeasible deployments.

At its core, SetpodNet employs the reinforcement learning algorithm DL-ViNE [11], designed to efficiently solve the VNE problem. DL-ViNE maps virtual nodes and links onto physical infrastructure by prioritizing co-location of connected VNFs and minimizing mapping costs. It refines placement decisions using a recursive rollout strategy, adapting to dynamic slice arrivals and departures. Experimental evaluations have shown that this approach significantly reduces latency (up to 75% compared to default schedulers) and improves slice acceptance ratios, while still maintaining scalability.

<figure><img src="image_3.png" /><figcaption>Fig. 2. UE-to-slice mapping based on SST, each UE gets a different DNN and subnet.</figcaption></figure>

## E. Scalability Experiments

Scalability is a critical feature for validating the robustness of network slicing platforms. On the data plane, the Kubernetes Horizontal Pod Autoscaler (HPA) is leveraged to dynamically scale UPFs based on traffic load. As shown in Fig. 3, iPerf3 traffic generation automatically triggers UPF autoscaling events, which can be monitored in real time through Grafana dashboards, Lens UI, or `kubectl` commands. This highlights the platform’s ability to elastically adapt slice resources according to dynamic service demands.

Beyond autoscaling, NexSlice also supports large-scale UE deployments using UERANSIM. By enabling the multi-UE mode in our Helm charts, hundreds of UEs can be instantiated to stress-test slice isolation and resource allocation. Each UE is mapped to a specific slice (via S-NSSAI), enabling experiments on how latency, throughput, and fairness behave under high load and multi-slice scenarios. Scripts included in the repository allow automated large-scale performance testing across slices, covering metrics such as end-to-end latency, per-slice throughput, and resource utilization.

Together, these scalability experiments demonstrate that NexSlice is not limited to small-scale proofs of concept. Instead, it provides a reproducible framework for benchmarking how slicing mechanisms, HPA-driven scaling, slice-aware scheduling, and multi-UE traffic, interact in realistic conditions. This makes NexSlice a practical platform to study elasticity, performance isolation, and policy-driven adaptation in future 5G/6G networks.

# III. CONCLUSION AND FUTURE WORK

In this paper, we introduced NexSlice, an open-source and Kubernetes-native testbed for 5G network slicing. By integrating the OAI 5G Core, UERANSIM, and disaggregated OAI RANs, the platform enables reproducible experimentation with SST-based slicing, multi-UE deployments, and real-time observability via Prometheus and Grafana. Advanced orchestration is supported through SetpodNet and DL-ViNE, while scalability is demonstrated by autoscaling UPFs with Kubernetes HPA and stress-testing multi-slice scenarios. Altogether, NexSlice bridges the gap between theoretical frameworks and
<figure><img src="image_4.png" /><figcaption>Fig. 3. UPF autoscaling triggered by traffic load, observed via Grafana and Lens.</figcaption></figure>

deployable platforms, lowering entry barriers for practical slicing experimentation.

Nevertheless, some limitations remain. The current imple-
mentation relies on OAI, which is still under active develop-
ment and does not yet support the full range of 3GPP network
functions for slicing. Slice creation and teardown are not yet
fully automated, and SST values in our setup act as simple
identifiers rather than reflecting standardized service categories
(eMBB, URLLC, mMTC). Moreover, the scope is currently
limited to core slicing, while RAN slicing and end-to-end
orchestration remain open challenges.

For future work, we plan to extend NexSlice with dynamic
slice lifecycle management, including on-demand instantiation
and release of VNFs (e.g., SMF, UPF) in response to slice
requests and load conditions. We also aim to integrate O-RAN
components to support RAN slicing and enable fine-grained
slice customization based on application requirements such
as latency sensitivity, bandwidth, and isolation. In addition,
the platform will be augmented with stronger security and
reliability mechanisms to ensure slice isolation and resilience
under high load. Finally, we envision providing comprehensive
tutorials and benchmarks to foster adoption by the community
and to establish NexSlice as a reference platform for 5G and
future 6G slicing research.

REFERENCES

[1] H. O. Otieno, B. Malila, and J. Mwangama, “Deployment and management of intelligent end-to-end network slicing in 5g and beyond 5g

networks: A systematic review,” *IEEE Access*, vol. 12, pp. 190411–190433, 2024.

[2] S. Arora, K. Boutiba, M. Mekki, and A. Ksentini, “A 5g facility for trialing and testing vertical services and applications,” *IEEE Internet of Things Magazine*, vol. 5, no. 4, pp. 150–155, 2022.

[3] P. Vanichchanunt, O. Rittruechai, N. Wuttiananchai, P. Thossaporn, L. Wuttisittikulkij, and S. Paripurana, “Implementation of 5g network slicing using open source software,” in *2024 12th International Electrical Engineering Congress (IEECON)*, 2024, pp. 1–6.

[4] H. Cheng, S. D’Oro, R. Gangula, S. Velumani, D. Villa, L. Bonati, M. Polese, T. Melodia, G. Arrobo, and C. Maciocco, “Oranslice: An open source 5g network slicing platform for o-ran,” in *Proceedings of the 30th Annual International Conference on Mobile Computing and Networking*, ser. ACM MobiCom ’24. New York, NY, USA: Association for Computing Machinery, 2024, p. 2297–2302.

[5] AIDY-F2N, “Nexslice,” https://github.com/AIDY-F2N/NexSlice, 2025.

[6] A. Gängör, “Ueransim: 5g sa user equipment and gnnodeb simulator,” https://github.com/aligungr/UERANSIM, accessed: July 2025.

[7] AIDY-F2N, “Nexslice docker compose,” https://github.com/AIDY-F2N/NexSlice-Docker-Compose, 2025.

[8] A. Y. Brahmi, “Nexslice demo,” https://youtu.be/HbOCkVIp-9k, 2025.

[9] OpenAirInterface, "oai-cn5g-fed," https://gitlab.eurecom.fr/oai/cn5g/oai-cn5g-fed, accessed: July 2025.

[10] M. A. Aba, A. Y. Brahmi, H. B. Samovar, C.-T. Samovar, and J. Badii, “Latency and Bandwidth-Aware Orchestrator for QoS-Sensitive Applications Using a Reinforcement Learning-Based Scheduler with Kubernetes,” in *30th IEEE Symposium on Computers and Communications (ISCC)*, Bologna Italy, France, 2025.

[11] A. Y. Brahmi, M. Ait Aba, H. Bouasker, B. Jouaber, and H. Castel-Taleb, “Dl-vine: Reinforcement learning algorithm for efficient virtual network embedding under direct-link constraints,” in *IEEE 11th International Conference on Network Softwareization (NetSoft)*, 2025, pp. 448–452.