Cloud-Enabled Deployment of 5G Core Network with Analytics Features

Abstract

The ongoing evolution of network softwarization is particularly evident in mobile networks. The 5G standard defines core network functions as discrete processes, facilitating seamless virtualization. The next crucial step is to enable cloud-based deployments independent of specific hardware and hypervisors. In this work, we propose a testbed designed for cloud-based 5G network deployment. Our primary objective is to create an environment conducive to experimenting with cloud-based 5G core deployments and facilitating future research in this domain. We rigorously verified the deployment’s correctness, identified key issues, and developed effective solutions to create a robust environment for emerging applications. Additionally, we introduce an innovative extension to a widely used 5G core network implementation by creating a network function that replicates the functionalities of the Network Exposure Function (NEF). This new component facilitates advanced analytics and AI-based optimization, significantly enhancing cloud-based deployments of virtualized 5G networks.

1. Introduction

The rapid evolution of mobile communication technologies has driven an unprecedented demand for fast and reliable connectivity, making the deployment of mobile 5G Core Networks (5GCN) crucial. To support the scalability and flexibility demanded by modern 5G networks, cloud infrastructure has emerged as a promising solution. Virtualization, in particular, enables operators to effectively meet user demands while reducing costs [1]. Furthermore, collaboration between network service providers and device manufacturers has accelerated the availability and adoption of 5G-capable devices [2].

Global trends emphasize the development of cloud-based applications, data hosting, and complete network deployments as the new standard [3]. Mobile network providers and operators recognize the advantages of integrating cloud solutions with mobile telecommunications, reinforcing the synergy between 5G networks and the cloud [4,5].

The primary aim of this paper is to address the practical challenges and issues associated with the cloud-based deployment of virtualized 5G networks. Motivated by the need to advance cloud-based 5G core network deployments, our testbed serves as an experimental platform designed to facilitate future research in this area [6]. By integrating a previously missing network function into a widely used 5GCN implementation, our work addresses a critical gap and provides significant benefits to the community. This contribution is especially important for the development of open-source 5G solutions, a timely and essential research topic [7].

The contribution of our work can be summarized as follows:

• We propose a testbed for 5G network deployment in a virtualized environment with support for network slicing (Section 4).
• We conduct a verification process for the testbed, which reveals an error-prone scenario stated in Section 5.
• We propose an original solution to the identified problem (Section 5.2).
• Based on these findings, we design and develop a network function that mirrors the functionalities of the Network Exposure Function (NEF) and can be easily integrated with virtualized cloud-based deployments.

The NEF enhances the flexibility and utility of 5G networks by enabling external applications to access monitoring, provisioning, and policy/charging capabilities. Thus, the proposed quasi-NEF component can significantly benefit mobile network administrators, as detailed in Section 6. By providing a structured and accessible framework for data collection and processing, our quasi-NEF component enables real-time analysis and decision-making. This capability allows for the optimization of network resources, predictive maintenance, and enhanced user experiences through AI-driven insights. Integrating this quasi-NEF not only improves the operational efficiency of the network but also supports the development of innovative applications and services that leverage data analytics and AI to deliver superior performance and reliability and improve the efficiency of cloud-based virtualized 5G network deployments [8].

2. State of the Art

Cloud computing and network slicing are pivotal elements of 5G wireless networks. Network slicing involves creating virtual segments of computing and connectivity resources, tailored and allocated for specific services based on their unique requirements. The effectiveness of these elements depends on the efficient distribution of virtual resources and the optimal deployment of Virtualized Network Functions (VNFs) that constitute the network slices. The authors in [9] discuss challenges that can impede the deployment of VNFs and Virtual Machines (VMs). They categorize existing VM placement solutions by their nature, distinguishing between dynamic and static placements, and evaluate them based on their objectives and metrics. Additionally, the paper introduces a classification of VNF placement strategies.

Lake et al. [10] conduct a comprehensive survey focusing on the virtualization of 5G network functions. The authors provide a detailed overview of existing technologies and tools that facilitate the deployment of 5G networks, encompassing both core and radio aspects. They conclude that it is critical to balance the efficiency and flexibility of 5G deployments, highlighting the complexity inherent in designing and implementing these networks. The survey also emphasizes a wide variety of tools that can be utilized for this purpose.

Several works in the literature focus on providing tools and solutions that facilitate the automated deployment and orchestration of 5G mobile networks. For example, in [11], the authors consider network virtualization as the primary driving factor enabling topology discovery in a multi-tenant 5G environment. An interesting testbed was introduced in a recent study [12], which offers a valuable dataset and proposes a framework for obtaining such datasets to facilitate future experiments conducted on 5G infrastructure. The authors utilize a container-based deployment to integrate the emulation of the 5G Radio Access Network (RAN) and the mobile core network with the simulation of User Equipment (UE). Chun et al. [13] present several enhancements for Kubernetes that have the potential to improve the performance of the 5GCN. The authors recognize the benefits of orchestrating Kubernetes with 5G network functions.

The authors in [14] propose a testbed dedicated to experiments on network slicing. This testbed comprises open-source tools to implement slicing and facilitates the implementation, management, and orchestration of network slices. It offers several interesting features, including dynamic slice provisioning, real-time monitoring of VMs, and the ability to onboard VNFs onto different Virtual Infrastructure Managers (VIMs). Similarly, the authors of [15] introduce an innovative testbed that utilizes open-source solutions for 4G and 5G mobile networks. Several deployments are compared with respect to throughput, latency, and received signal strength, allowing for a comprehensive analysis of the performance characteristics of the network.

Wiranata et al. [16] propose a framework that includes the radio and core components of the network, aiming to automate a 5G network utilizing Kubernetes and the Mosaic 5G Operator. The study focuses on the orchestration of deployment and the evaluation of throughput. Additionally, the work provides a GitHub repository [17] that contains Helm charts for automatically deploying Free5GC with UERANSIM and My5G-RANTester. This repository should be considered a supplementary tool for 5GCN deployments.

3. Background

3.1. Virtualization of a 5G Core Network

As the evolution of mobile networks progressed, one aspect remained unchanged: the reliance on ‘black-box’ solutions regarding mobile network components. Vendors provided integrated hardware with dedicated software that could interact properly only with other proprietary equipment.

To overcome these limitations, 5G networks utilize the virtualization of their core components and commercial off-the-shelf (COTS) hardware. Virtualization allows for greater flexibility, as Network Functions (NFs) can be dynamically scaled in or out according to the network state [18], while computing tasks can be executed in a cost-effective manner [19,20]. Furthermore, it reduces the time to market for new services, as the adaptation time of the network architecture is shortened [21]. In principle, virtualization significantly impacts both operational (OPEX) and capital (CAPEX) expenses. The CAPEX associated with deploying 5GCN is greatly reduced because NFs no longer need to run on dedicated and costly hardware. Additionally, OPEX related to maintaining this aggregation of virtualized resources and adjusting them to provide new services is also minimized.

5G networks have been designed to support deployments that utilize the concept of Network Function Virtualization (NFV) [21,22]. This virtualization framework describes network node functions as software entities that can run independently of the underlying hardware. There are three main components of the NFV framework:

• VNF, which is a software implementation of a network component, capable of running on various platforms.
• Network Function Virtualization Infrastructure (NFVI) denotes the COTS hardware on which VNFs are deployed.
• NFV Management and Orchestration (NFV-MANO) framework to administer VNFs and NFVI [23,24].

There are two primary methods for deploying NFs. The first method involves deploying NFs using containerized network services [23]. A container is a lightweight, standalone unit of software that encapsulates the runtime environment along with all required dependencies. Implementing core network components as containerized functions in clustered worker nodes facilitates straightforward vertical scaling, increased reliability, and rapid fault recovery [25].

The second method of virtualizing network functions is through the use of virtual machines (VMs). In this deployment model, an NF runs as a process on the guest operating system within a VM. A VM-based NF requires a commodity hardware server and an operating system with its dependencies. Similar to other NFs in a 5GCN, it may contain redundant operating system features that are unnecessary for its operation [26]. Generally, VM-based VNFs require more disk space because they include an operating system needed to host the NF process. The size of the NF implemented as a VM-based VNF affects both the deployment and migration time. Additionally, hardware virtualization consumes a significant portion of physical resources, such as the CPU.

To ensure proper isolation of network functions hosted in virtual machines, VNF VMs are restricted from accessing the resources of the deployment platform. Instead, a hypervisor [23,27], also known as a virtual machine monitor (VMM), is responsible for scheduling CPU, memory access, and networking for guest virtual machines [28]. Despite the drawbacks of the virtual machine approach, VNFs have been successfully deployed on VMs in many commercial implementations. As the adoption of network function virtualization concepts in mobile networks has increased, containerized network functions are increasingly replacing VM-based VNFs [29].

The complexity of 5G mobile networks must be distributed across multiple NFs so that each NF serves a specific purpose. For example, one NF may handle authorization for network access, while another NF facilitates the actual access itself. Consequently, the 5GCN comprises numerous NFs [21], each responsible for a distinct subset of functionalities. In the event of an NF failure, only a limited subset of services becomes unavailable until the affected NF is recovered.

To achieve granularity and scalability, 5GCNs employ a new approach for interactions between core components. Service-Based Architecture (SBA) defines a model in which a set of network functions provides services to other eligible NFs. This can be represented as a reference-point view, where a reference point signifies point-to-point links between NFs that exchange services [30]. Alternatively, SBA can be represented through a service-based representation, in which network functions are interconnected by the services they provide. This representation is applicable only to the control plane (CP). The interfaces between the CP and the user plane (UP) are implemented via reference points (e.g., the interface between the User Plane Function (UPF) and the Session Management Function (SMF) [21]). SBA is commonly implemented using service-based representation, as reference-point interfaces are replaced with corresponding Service-Based Interfaces (SBIs) wherever possible. Figure 1 illustrates the architecture of the 5GCN.

The Network Exposure Function, as defined in 3GPP 23.501 [21], provides external exposure of CP NFs’ capabilities to third-party applications. This functionality can be particularly advantageous for 5G cloud-based deployments in a virtualized environment that supports network slicing. However, NEF is not included in the most popular open-source implementations of the 5GCN. Moreover, many unimplemented network functions are based on NEF. Therefore, we decided to design and develop a network function that mirrors the functionalities of NEF to benefit the community of researchers and developers focused on applications utilizing 5G networks.

Mobile network operators expect NEF to provide internal data from the 5G core for broad analysis. This analysis, based on live on-demand data from the network, would be used to anticipate undesired events, such as overloads and service request rejections. Slice-specific data can be valuable for predicting the resources required to ensure uninterrupted service provisioning. For instance, summary data showing the total aggregated maximum bitrate for a given Data Network (DN) may indicate the need to increase the number of UPF instances in the user plane to alleviate the utilization of existing NFs [31]. If the 5GCN control plane needs to be scaled, information about the Session and Service Continuities (SSCs) supported by UEs for a specific DN can help ensure PDU session continuity as the generated traffic is offloaded onto newly deployed UPFs. Additionally, the total bitrate per DN may be a critical factor when adjusting virtualized resources to the state of the network, enabling efficient cloud-based deployment [32]. If the 5GCN infrastructure is at risk of overload, additional network resources must be deployed [33]. It is essential to reduce pressure on physical hardware to ensure the continuous delivery of critical 5G services. However, physical constraints may limit the deployment of additional NFs on a given platform. In such cases, the last resort may be to release a subset of non-critical services, such as low-priority PDU sessions, to reduce the load on the network.

3.2. Network Slicing

As the 5G network supports diversified services, it must meet a wide range of requirements for capacity, latency, isolation, and resilience. These requirements are often impossible to achieve simultaneously. Therefore, the mechanism responsible for network isolation, known as slicing, has been introduced.

A slice is a logical network with components customized to meet the needs of a specific service. It uses a dedicated core network architecture and provides access to services located in external DNs. A DN can provide operator services, internet access, or third-party services [34].

A network slice is uniquely identified by a Single Network Slice Selection Assistance Information (S-NSSAI). S-NSSAI consists of two values:

• Slice/Service Type (SST), which describes the expected behavior of a slice in terms of services.
• The Slice Differentiator (SD), which is used to distinguish slices belonging to the SST.

The optional SD is represented by a combination of 24 bits, while the mandatory SST is described using 8 bits. The differentiator allows Public Land Mobile Network (PLMN) operators to provide the same features to different groups of customers, such as groups of UE. Certain values for Service Types must be consistent within all deployed 5GCNs.

S-NSSAIs are not required to have a dedicated subset of resources, as they might be served by the same Network Slice Instance (NSI). Simultaneously, there may be numerous NSIs associated with an S-NSSAI. This is useful when a subset of resources in a 5GCN becomes inaccessible, for instance, if a platform hosting NFs of an NSI fails. In such cases, another NSI serves as a fallback instance to provision the service [21].

UEs may request access to a specific slice based on the S-NSSAI. Upon registration, UEs configured with different S-NSSAIs should access the corresponding network slice and establish PDU sessions accordingly. This enables slicing during the initial registration and service request, which are key operations that should be supported by the 5G network. Joint procedures can be used to determine whether a deployed 5G network operates correctly, making them a starting point for verifying the proposed testbed. Regarding these procedures, the 5GCN should allow for:

• Requesting a PDU session establishment by the common AMF to an adequate SMF instance based on the configured S-NSSAI.
• Creating a policy for the PDU session by the Policy Control Function (PCF).
• Establishing an N4 link between UPF and SMF for a given PDU session.
• Issuing Next-Generation Application Protocol (NGAP) (i.e., the message over the N2 link between AMF and gNodeB (gNB)) message to request establishing UP for the PDU session between 5G Access Network (5GAN) (namely gNB) and UPF.
• Verifying that the UP creation has been successful, i.e., whether an N3 link has been established.
• Tunneling UE-generated traffic to the outbound DN (i.e., public internet) through UPF.

Network slicing, when integrated with cloud-based deployments, offers new opportunities while also presenting new challenges [35,36].

4. The Testbed

In this section, we introduce the testbed for cloud-enabled 5GCN deployment, supporting network slicing and virtualization of NFs. This testbed represents a significant technical contribution to our work. Its primary objective is to create an environment conducive to experimenting with cloud-based 5G core deployments and to facilitate future research in this domain.

The 5GCN network functions are deployed as separate processes on virtual machines. NFs of a 5GCN are hosted on virtualized nodes using a type-2 hypervisor. In this study, we opted for VirtualBox as the hypervisor due to its straightforward setup and configuration. Its user-friendly nature enabled us to focus on the core research aspects without being encumbered by complex infrastructure setup. Additionally, VirtualBox is widely utilized in academic and experimental settings due to its flexibility, making it well-suited for rapid prototyping and testing. Furthermore, the use of VirtualBox does not limit the adaptability of our testbed. The deployment is designed to be easily transferable to other hypervisors, including server-level virtualization platforms and cloud-based environments. This flexibility ensures that future enhancements can incorporate more advanced features and achieve improved performance for large-scale deployments.

The platform for hosting 5G Core and Access Networks consists of three VMs. Each virtual machine is equipped with a northbound interface for remote access by the host. The actual communication related to 5GCN is handled via data interfaces, with traffic routed through an internal virtual router. This networking architecture is typical for cloud environments. The separation of interfaces is purely illustrative, as both types employ the same networking type: a host-only network. This network emulates a physical Ethernet switch, enabling bidirectional communication between VMs while dropping all traffic routed to the internet [37].

Open5GS has been chosen as the fifth-generation mobile core network framework due to its suitability for deploying private 5G networks, particularly in cloud environments. Its architecture facilitates automated deployments across heterogeneous infrastructures without imposing restrictions on the operating system kernel version, additional kernel modules, or the deployment order of network functions. Such limitations are present in other popular open-source 5G core implementations like Free5GC. Furthermore, Open5GS benefits from active development and community support, making the configuration of network functions more straightforward compared to Free5GC. The decision to use Open5GS is also driven by its comprehensive and precise documentation, the extensive range of services provided by its network functions, and robust community backing for the project [38].

By default, 5GCN functions are designed to run as programs in the Linux environment. Currently, Open5GS has been tested and verified to function properly on several operating systems, including Debian, Ubuntu, CentOS, openSUSE, Fedora, and Mac OSX [23]. The framework can also be implemented on virtual machines hosted by a hypervisor of choice. Depending on the test scenario, NFs may be distributed across multiple virtual machines. In such cases, proper routing between them must be ensured, meaning the IP addresses of NFs’ SBI should be accessible. The Open5GS implementation of the 5G Core requires an ordered execution of NFs; specifically, the NRF must be operational before deploying other network functions to facilitate NF and service discovery.

Each NF shares and consumes services using a dedicated SBI interface [21], which Open5GS by default exposes via the loopback interface of the commodity server on which it runs. If the NFs are distributed across multiple VMs for virtualization, the SBIs’ IP addresses should be accessible through either the hypervisor or an external router. The Unified Data Repository (UDR) is of high significance regarding service exposure through SBI. The UDR implemented by Open5GS does not store subscriber data directly. Instead, it interacts with MongoDB, a NoSQL document-oriented database that stores data in a JavaScript Object Notation (JSON) structure [39].

Since an emulated Access Network (AN) and UE are necessary for the proper verification of the 5GCN, an additional virtualized node is deployed for the 5GAN. UERANSIM is an open-source framework that provides 5GAN functionality, offering a software implementation of the gNB, which serves as the base station for the fifth-generation AN, along with a 5G-enabled UE. In the deployed 5G network, SBA communication through SBI interfaces and message exchanges over the N2/N1/N4 links are routed through a private address space. This setup requires minimal effort when utilizing public cloud network services, such as Azure Virtual Network [3] or Amazon VPC [40].

In summary, the architecture depicted in Figure 2 has been meticulously designed to ensure repeatability and support cloud migration. As a result, both the 5GCN and 5GAN can be fully deployed in a public cloud environment. To establish this reliable setup, we addressed several challenges detailed in the paper and proposed effective solutions, which are outlined below.

4.1. Setup Parameters and Networking

The parameters of the setup and the networking configuration are crucial components of the testbed proposed in our work. The solutions presented in this section should be regarded as a solid foundation for establishing a research environment focused on cloud-based 5G core deployments.

The testbed for the deployment of the 5G network (5GCN + 5GAN) via VirtualBox is based on a personal laptop. Its physical parameters are listed in Table 1. The virtual machines deployed under VirtualBox have the following roles assigned:

• vm_5GC-CP hosts the CP NFs.
• vm_5GC-UPF hosts 5GC UP functions.
• vm_5G-UERANSIM hosts the 5GAN together with UEs.

Table 1. VirtualBox host platform: Apple MacBook Pro 13-inch originating from Germany (2019) specification.

CPU	1.4 GHz Quad-Core Intel Core i5 Turbo Boost up to 3.9 GHz
GPU	Intel Iris Plus Graphics 645 1536 MB
Disk Size	128 GB SSD
RAM	8 GB 2133 MHz LPDDR3
Operating System	macOS Monterey

Table 1. VirtualBox host platform: Apple MacBook Pro 13-inch originating from Germany (2019) specification.

CPU	1.4 GHz Quad-Core Intel Core i5 Turbo Boost up to 3.9 GHz
GPU	Intel Iris Plus Graphics 645 1536 MB
Disk Size	128 GB SSD
RAM	8 GB 2133 MHz LPDDR3
Operating System	macOS Monterey

The configuration of these VMs is presented in

Table 2. VirtualBox guest platforms parameters.

VM Name	RAM	Disk Space
vm_5GC-CP	2048 MB	6 GB
vm_5GC-UPF	1024 MB	6 GB
vm_5G-UERANSIM	1024 MB	6 GB

. To accommodate more NFs deployed on vm_5GC-CP compared to the other VMs, its physical resources (i.e., RAM) have been doubled. Each VM has been equipped with the 64-bit version of Debian 11 Bullseye OS.

When a VM generates outbound traffic, the NAT adapter of the hypervisor’s NAT engine extracts the TCP/IP data and forwards it through the host operating system to a remote network (e.g., the internet). Networking between VM-VNFs is managed by the VirtualBox internal switch (Oracle VM VirtualBox networking engine [37]), which ensures connectivity between the VMs and the host platform. Each VM is equipped with three network adapters.

The first adapter, labeled as enp0s3 for Debian distributions, is configured as a NAT adapter to enable internet access from within the virtual machine. This NAT interface serves as the default gateway device. The IP address of the NAT interface in the guest VM is bound to the loopback interface of the host OS, acquired from the hypervisor’s DHCP engine, and resides within a NAT address pool (10.0.2.0/24). The remaining two interfaces of each VM are configured as host-only networking type, which is easily reproducible in a cloud environment.

The network space created within VirtualBox is logically divided to reflect the responsibilities of each part and ensure data separation. Two virtual interfaces created by VirtualBox on the host platform correspond to the logical network space summarized in

Table 3. Logical network configuration.

Name	Data Networking Space	Northbound Networking Space
Address pool	192.168.56.0/24	192.168.58.0/24
Virtual interface on the host OS	vboxnet0	vboxnet1
IP address	192.168.56.101	192.168.58.101
Purpose	host-to-VM access via SSH	traffic related to SBA and reference-point communication of the deployed 5G network

.

Interfaces of each of the VMs, named enp0s8 and enp0s9, are assigned to one networking space. Interface enp0s8 is attached to a northbound networking space and is used by the host platform to remotely configure the NFs on the VM. Enp0s9 binds to the data networking space, in which all 5GC and 5GAN traffic is handled. The OS of vm_5GCN-UPF, which hosts the 5G CP functions, must support Network Address Port Translation (NAPT) to enable data tunneling to an outbound network. Furthermore, it must support IPv4 forwarding and be equipped with TUN interfaces for each of the PDU sessions [41].

4.2. Slicing Configuration

To implement the testbed, the configuration files of the 5GCN and 5GAN need to be tailored. This involves modifying the configuration files of the 5GCN network functions. In this section, we present the most critical aspects of these configurations as a result of our work. With these contributions, one can configure a cloud-based 5G core network deployment with slicing enabled.

For Open5GS and UERANSIM, these files are formatted in YAML. Both emulated UEs must be aware of the assigned S-NSSAI. The Data Network Name (DNN) associated with an S-NSSAI should be consistent within the deployed 5GCN. Additionally, the International Mobile Subscription Identity (IMSI) of the UEs must be unique. Each UE’s IMSI, along with a complete Subscriber Profile, should already exist in the UDR to facilitate successful authentication via the Authentication Server Function (AUSF). In practice, this requires a corresponding entry in the MongoDB database, which is part of the Open5GS framework.

In the proposed testbed, the 5GCN is logically divided into two slices: internet and ims. Both slices are dedicated to provisioning data services. The S-NSSAI describing these slices is presented in

Table 4. Network slices in the implemented 5GCN.

SST Value	SD Value	DNN	UE Identity
1	0x000001	internet	UE1
2	0x000002	ims	UE2

. As illustrated in Figure 2, each slice is assigned a dedicated SMF function in the CP and a UPF in the UP. The slices can be distinguished by their respective colors (pink for the internet slice and green for the ims slice) of the network function (NF) blocks and the S-NSSAI mentioned within the NFs. The remaining NFs of the 5G CP are shared among the two slices, including the Network Repository Function (NRF), UDR, Unified Data Management (UDM), Binding Support Function (BSF), PCF, AUSF, Network Slice Selection Function (NSSF), and AMF. The configuration presented below is critical for deploying a slice-enabled and virtualized 5GCN in a cloud environment. We provide examples of the configuration files, all of which are published in the repository [42], to which we refer in the following explanations.

To successfully deploy an AMF, it has been configured to support both slices, as shown in Listing 1. The Globally Unique AMF ID (GUAMI) reflects the common PLMN identity and the Tracking Area Identity (TAI) component. The Tracking Area Code (TAC) is shared by AMF and gNB. The ngap interface of AMF, responsible for the handling of Non-Access Stratum (NAS) signaling, is bound to the physical interface enp0s9 of the vm_5GC-UP. The SBI interface of the AMF is used for service exposure and access. A default Open5GS configuration is used since the 5GCN CP is deployed on a single VM. Therefore, the use of a loopback interface with unique port numbering simplifies the scenario and reduces the risk of failure due to a routing error.

Listing 1. Listing presenting the AMF configuration to support multi-slice network topology.

SMF1, deployed on vm_5GC-CP, binds its Packet Forwarding Control Protocol (PFCP) interface (the N4 interface in reference-point architecture) to enp0s9 physical interface, with an IP address of 192.168.58.111. The same line is present in UPF1 configuration to alter the default PFCP address and ensure that a N4 link is established and PFCP peering has been achieved. The PFCP address is bound to the enp0s9 physical interface on vm_5GC-UPF VM, and equals 192.168.58.121. The GTP-U interface, i.e., the N3 reference point for data transfer, also points to the 192.168.58.121 address. The subnet values reflect the SMF1 configured IP address pool and DNN. The dev value denotes the tunnel interface name, which is used for data tunneling via the N6 interface to DN, i.e., public internet. The SMF1 configuration file is presented in Listing 2.

Listing 2. Listing showing the SMF1 configuration to provision internet slice.

The configuration of SMF2 and UPF2 handling the second slice (SST:2) is similar to the SMF1/UPF1. The changes reflect the fact that both SMF1/SMF2 and UPF1/UPF2 are deployed on the same VM: vm_5GC-CP and vm_5GC-UPF, respectively. Therefore, the IP addresses of the PFCP and GTP-U interfaces, although bound to the same interfaces as addresses SMF1/UPF1, are changed. These addresses are configured to 192.168.58.112 and 192.168.58.122 for SMF2 and UPF2, respectively.

Since the NFs in the 5GCN CP are deployed on one virtual machine, the SMF2 SBI interface cannot point to the same IP address as the loopback interface of the vm_5GC-CP. The SMF2 SBI address has been changed to 127.0.0.24 (port remains intact). This change is later reflected upon NF registration in the NRF, thus the SMF2 services are accessible via the altered SBI. Furthermore, the freeDiameter configuration file has been swapped to indicate the distinction between SMF1 and SMF2 in terms of SBI addresses. This file is used to configure the freeDiameter server, which implements the Diameter protocol, used for carrying the Authentication, Authorization and Accounting (AAA) payload. Key ListenOn defines an endpoint, on which the NF will listen for authorization requests, and was configured to 127.0.0.24.

In the UPF2 configuration file presented in Listing 3, the key pfcp, responsible for establishing the N4 link, has been set to the IP address of the SMF2 PFCP interface. The subnet values for this interface differ from the UPF1 settings. To route data traffic from UEs belonging to different PDU sessions to the appropriate destination, the device (dev) responsible for forwarding UE2 data traffic points to the ogstun2 interface on the vm_5GC-UPF virtual machine.

Listing 3. Listing depicting the UPF2 configuration to provision ims slice.

According to 3GPP Release 15 [43], the AMF obtains information about the configuration of the slices from the NSSF. Therefore, the NSSF YAML file must be customized for the specific test scenario to include the necessary slice information (Table 4). Both slices are associated with one NRF, which means that both pairs of SMF/UPF are registered with the same NRF. Therefore, the AMF can request service from proper SMFs for a particular slice. The procedure is described as the SMF selection process [43].

The syntax of UERANSIM configuration files differs from those used by the Open5GS framework. However, the key parameters are still recognizable. In the verification scenario, a single common gNB is used to support a multi-slice infrastructure and to relay PDU session establishment requests to a shared AMF.

The UERANSIM software implementation of gNB shares the combination of MCC and MNC values with the AMF to indicate that the emulated 5GAN belongs to the same PLMN as the 5GCN. The gNB configuration file also specifies the TAC value (tac: 1), which is present in the AMF and SMF1/SMF2 configuration files, for each of the supported slices. According to the network configuration, the radio link, N2 and N3 interfaces are bound to the enp0s9 with an IP address of 192.168.58.130. The gNB is associated with a single AMF, which is identified by the IP address 192.168.58.110. The gNB also supports both slices, as indicated in Table 4.

UEs are configured with the initial slice according to the topology presented in Figure 2. The configuration files for UE1 and UE2 specify the compliance of PLMN, identify the gNB that provides access to the AN, and describe the default/supported NSSAIs. UE1 and UE2 have been assigned unique IMSIs, which have been registered in the MongoDB subscriber database.

5. Verification of the Testbed

In the deployed 5G network architecture, the following scenario is designed to verify the testbed. Two UEs (UE1, UE2) send a registration request via NAS message to a shared AMF. As the UEs are authorized, the separation related to slicing occurs. The AMF performs the SMF selection procedure and finds an SMF suitable for the particular S-NSSAI and Data Network. If the selection is successful, the AMF requests the creation of a PDU session from the SMF. As a result, the PDU session for a given UE should be created in a respective logical network. That is, the UE1 PDU session request to internet DN should be managed by SMF1, and the data transfer tunnel should be anchored at UPF1. The exact procedure should be repeated for the UE2 PDU session establishment request. Supplementary figures and listings are published in the repository [42].

Our contribution is focused on creating a robust environment for future research rather than benchmarking performance metrics. This means we have prioritized developing a flexible and reliable testbed that researchers can use to explore various aspects of 5G core networks. By validating the functional integrity and practical deployment of network functions within our testbed, we provide a solid foundation for future performance evaluations and optimizations. Our work facilitates further research by enabling the testing, validation, and enhancement of different components and configurations of 5G networks.

The verification of the virtualized 5GCN consists of two subparts: Initial Registration and service request triggered by UE. However, since UEs are configured to initiate the PDU session request immediately after accessing the network, both procedures are combined. To reduce the risk of 5G network initialization error, we propose the following deployment steps:

• 5G Core Network control plane: Start all Open5GS CP NFs in the following order:
  $NRF\to AMF\to UDR\to UDM\to NSSF\to AUSF\to PCF\to BSF\to SMF1\to SMF2$
• 5G Core Network user plane:

  (a)

  Enabling NAT and tunneling.

  (b)

  Starting Open5GS user plane NFs: UPF1 and UPF2.

• 5GAN: Start UERANSIM gNB instance.

Each of the NFs registers with the NRF through its dedicated SBI for NF management. During NF registration, an HTTP/2 PUT request is issued to the /nnrf-nfm/v1/nf-instances/ endpoint of the NRF.

Once the CP functions of the 5GCN are registered, the UP functions can be deployed. Before running the executables for UPF1 and UPF2 on the vm_5GCN-UPF VM, it is essential to set up port forwarding and TUN interfaces for data tunneling. Listing 4 shows the necessary commands for the Debian operating system.

Listing 4. Necessary network configuration of the UPF VM.

The final step in deploying the virtualized 5G network is to execute the UERANSIM software, which emulates the gNB. The gNB then establishes the N2 link with the 5GCN AMF, setting up the SCTP interface between the 5GAN and the 5GCN. The AMF log file will show data received from the gNB, including information about supported slices, TAC, and PLMN, matching the configured values. The 5G network deployment process is considered complete once the gNB is registered and the N2 connection is established.

5.1. Problem Statement

Identified problem. During the initial registration, the UE also requests the establishment of a PDU session. While network registration is successful, session establishment fails. After several attempts to establish a PDU session, UE1 does not receive any response to its InitialUEMessage and switches to the IDLE state.

Context of the problem. This issue was identified in the Open5GS implementation of the 5G core. Open5GS is regarded as the most suitable open-source tool for deploying private 5G networks, especially in cloud environments.

Root cause. The AMF log file helped trace the root cause of this issue. Listing 5 reveals that the AMF is unable to connect to an HTTP/2 server at the 127.0.0.24 address, which corresponds to the SBI interface of SMF2. Consequently, the AMF mistakenly requests the establishment of the PDU session for UE1 through an invalid SMF. This request should be routed to SMF1, as SMF2 is designated to handle a different slice associated with UE2. Thus, the SMF selection process is flawed.

Listing 5. AMF attempt to establish session for UE1 at SMF2.

Further investigation unveiled that the SMF2 crashed due to an unsupported subnet: [family: 2, dnn: internet]. The SMF2 has received a Nsmf_PDUSession_CreateSMContext request for a DN with unsupported slice combination: [SST: 1, SD:0x000001], as shown in Listing 6.

Listing 6. Session request with invalid slice combination received by SMF2.

Upon further verification, the AMF has been found to cause the SMF2 to crash by issuing a request to establish a PDU session to a DN which is unsupported by the targeted SMF2.

Before issuing the faulty request, the AMF executes an internal SMF selection procedure. This procedure can be bypassed if the AMF has local access to SMF information. This explains the absence of an actual SMF selection process, as both SMF1 and SMF2 reside within one NSI and are registered with a common NRF. The AMF retrieves SMF information through notifications sent by the NRF to the /nnrf-nfm/v1/nf-status-notify endpoint and retains this information until deregistration.

Impact of the problem. Unfortunately, the Open5GS documentation does not provide guidance on resolving the SMF selection issue. This abnormal behavior likely stems from the scenario where multiple S-NSSAIs are linked to a single NSI. Given Open5GS’s advantages and its critical role in cloud-based deployments, any fixes, improvements, or enhancements to this tool are invaluable to the community. Therefore, we propose a solution to this issue, which is detailed in the next section.

Ideal solution that did not work. To understand why the AMF fails to anchor the PDU session in the appropriate SMF, we adopted a reverse engineering approach. The issue with the faulty SMF selection may be related to the nf_instance itself. Since SMF2 was called after SMF1, it may have been incorrectly selected as the desired node to request the establishment of the session. To address this issue, we reversed the execution order of the SMFs. Contrary to our expectations, this did not resolve the problem; the AMF continued to issue Nsmf_PDUSession_CreateSM-Context requests for UE1 PDU session establishment to the invalid SMF2.

5.2. Proposed Solution

In this section, we propose an effective solution to address the problem outlined in Section 5.1. We conducted experiments with procedures related to UE-triggered service requests and NF deregistration. Based on these experiments, our solution enables slicing in cloud-enabled and virtualization-based 5G deployments. The procedure is as follows:

• Ensure that NFs have registered on the NRF, with the exclusion of SMF2.
• Trigger a registration with the establishment of the PDU session for the UE1.
• Verify that the PDU session has been anchored in UPF1 and that the NF is capable of tunneling UE traffic to an outbound DN.
• Utilize the UERANSIM-provided CLI or UE1 and trigger the UE-initiated PDU session request.
• Invoke the NF deregister procedure of SMF1 by stopping its process on vm_5GC-CP VM.
• Call the SMF2 executable and trigger UE2 registration.
• Verify that PDU Session for UE2 has been anchored in the correct slice.
• Deploy SMF1 NF.
• Verify that PDU Session for UE1 has been reestablished (i.e., AMF issued the request to SMF1 instead of SMF2), avoiding the crash scenario.

As a result of the proposed procedure, the UE1 Nsmf_PDUSession_CreateSM-Context Request was successfully issued to SMF1, which subsequently registered the PDU session in the PCF. This confirms a positive workflow for the PDU session establishment procedure. Additionally, the correct UPF was selected for the DN requested by UE1 (see Table 4). An N4 link was established between SMF1 and UPF1, meeting the requirements for establishing a slice-aware session. UE1 was assigned an IP address of 10.45.0.2/16, which is reflected in a tunnel interface created on the 5GAN VM. Below, we present indicators of successful execution of the UE-triggered PDU Session establishment for UE1:

• Connection setup and tunnel interface creation (uesimtun0), observed in the console of UE1.
• PDU resource setup for UE1, observed in the console of gNB.
• Connected status of UE1, observed with the use of UERANSIM CLI.
• A successful data transmission over the 5GCN user plane to a remote site: agh.edu.pl.
• GTP-U packets transmitting user data (i.e., the ICMP Ping data), observed in a log file of UPF1.

In the next step, the PDU session for UE1 was released using the UERANSIM CLI. The 5GCN responded appropriately, and the result of the PDU session release can be observed in the AMF log file. Following this, both the SMF2 and UE2 executables were initiated on their respective VMs. At the same time, the SMF1 process on the 5GCN CP platform was stopped to trigger the NF deregistration procedure. The request for a PDU service from UE2 was successfully handled.

Since the AMF session cache had been cleared of the SMF1 entry upon being notified of its deregistration by the NRF, the internal SMF selection process has returned the only one SMF present in the network: SMF2. The PDU session has been successfully established by UE2 in the requested slice. The gNB forwards a resource reservation for the UE2 PDU session to the AMF. The AMF confirms that the data session is available to SMF via the [/nsmf-pdusession/v1/sm-contexts/1/modify] resource. A data service has been provided positively, which has been verified with the use of the UE2 UERANSIM console. The UE2 has been assigned a 10.46.0.2/16 IP address from the SMF2/UPF2 pool for the requested DN (ims).

Having completed another step in the resolution scenario, the SMF1 instance was recalled, making it available for reestablishing the PDU session for UE1. UE1 was successfully registered on the 5G network and established a data session in the slice [SST: 1, SD: 0x000001]. After reestablishing the PDU session, UE1 regained access to the remote site.

The process presented in this section demonstrates that the proposed solution effectively resolves the issue discussed in Section 5.1 within the Open5GS implementation of the 5G core. As Open5GS is recognized as the most suitable open-source tool for deploying private 5G networks, especially in cloud environments, our contribution is anticipated to significantly bolster scientific efforts in this domain.

5.3. Discussion on the Performance Evaluation

Our primary contribution lies in creating a robust environment designed for future research rather than solely focusing on benchmarking performance metrics. The proposed environment is expected to facilitate further research by supporting the testing, validation, and enhancement of different components and configurations of 5G networks, thus contributing significantly to the ongoing development of 5G technologies.

In this subsection, we aim to provide insights into potential performance evaluations that can be conducted within our testbed environment. These evaluations are crucial for understanding how the 5G core network performs under various conditions and for ensuring it meets industry standards. We hope to guide researchers on how to leverage our testbed for comprehensive performance assessments, ultimately advancing the knowledge and capabilities of 5G network deployments.

One of the key performance indicators for 5G networks is latency, which is expected to be at the 1 ms level in selected use cases. Measuring latency on a per-slice basis is crucial, and our testbed enables this through its slicing configuration. From the user’s perspective, end-to-end latency is the most important metric as it directly affects service quality. This can be measured in the testbed using emulated UEs running common latency measurement tools such as iPerf. Network operators may also be interested in specific latency measurements for individual network functions, such as UPF in the data plane or AMF in the control plane. Our distributed environment allows for packet capturing at selected interfaces of different network functions, enabling precise latency measurements. Additionally, profiling tools such as the DPDK Test Suite or Linux perf tool can be utilized within selected network functions to gain deeper insights.

Other critical performance indicators are throughput and scalability. The 5G core network should be capable of handling high data transfer rates and numerous concurrent connections. Our testbed’s virtualized UEs can be effectively used for these purposes. Testing will involve generating high volumes of traffic and monitoring the network’s ability to process this traffic efficiently and without losses. Well-known tools such as iPerf or JMeter are useful also in this context. Scalability concerns may also relate to the control plane capabilities, for instance, when a large number of UEs simultaneously register on the network, which could potentially lead to service degradation. The distributed architecture of the 5G core network should also be evaluated for its ability to support dynamic horizontal scaling by adding more instances of selected network functions. In addition to measurement and load generation tools, an orchestration layer should be introduced to manage these scaling operations.

Although the primary aim of this work is not performance testing, we present some example results to provide a comprehensive verification of the testbed. In this study, we conducted tests using a single UE communicating through an isolated PDU session to ensure the results were unaffected by external factors. We performed eight consecutive measurements for each test and then conducted statistical analyses to calculate and present 95% confidence intervals.

Figure 3 illustrates the end-to-end latency in the user plane of the 5G network. The observed latency performance meets expectations for 5G networks. However, it is important to note that the environment is fully virtualized, with virtual machines deployed on the same host.

Figure 4 presents the throughput achieved during the testbed experiments. The experiment was conducted using iPerf3, which operates in a client-server architecture. In this setup, an additional VM serves as the server, while the UE acts as the client. Traffic is transmitted in both directions between the machines using TCP as the transport protocol, with a datagram size of 128 KB. The achieved results are satisfactory; however, it is important to note that all resources were dedicated to this single session.

6. Extension for Analytics of 5G Deployment

Common open-source implementations of the 5G Core Network include a sufficient number of NFs to meet the specification of Release 16 [21]. However, 5G cloud-based deployments in a virtualized environment with support for network slicing may require additional functions [21]. The NEF, Application Function (AF), Network Slice-Specific Authentication and Authorization Function (NSSAAF), and NetWork Data Analytics Function (NWDAF) are not implemented.

Due to the absence of certain NFs, some procedures defined for 5G systems cannot be executed. Therefore, supplementing Open5GS with one of these missing network functions would greatly benefit the community and represent a significant contribution to the field of open-source 5G implementations. To develop a functional module, a solid foundation of essential services is necessary. After evaluating the dependencies between existing and planned NFs, it was determined that the NEF would be the most advantageous to implement. This is because many planned NFs depend on NEF services. The other unimplemented network functions were excluded as they either require NEF for their operation or would not provide useful services to the rest of Open5GS NFs.

The Network Exposure Function enables the external exposure of CP NFs capabilities to third-party applications, enhancing the flexibility and utility of 5G networks. These capabilities include monitoring, provisioning, and policy/charging functions [21]. The policy/charging capability is related to enforcing QoS policies and enabling charging for a UE in a 5G network. This involves direct interaction between the NEF and the PCF to forward policy and charging requests from external applications. The monitoring capability allows for the exposure of events related to UE mobility, reachability, or loss of connectivity. This feature enables the identification of emerging events and the network functions that generate them, allowing eligible external applications to access such events for purposes such as performing digital communication forensics [44]. The provisioning capability allows authorized external applications to provide 5G NFs with data related to a given UE, which can be used to influence UE behavior in the network. For instance, the NEF can change the Session Management data of a UE upon request from an external application.

In our work, we developed an original extension to a widely used 5G core network implementation, creating a network function that mirrors the functionalities of the NEF. This extension is specifically designed to offer advanced analytics and AI-based optimization capabilities, aggregating 5G-related data to enhance network performance. These features are particularly valuable for cloud-based virtualized 5G network deployments, significantly contributing to the efficiency and functionality of modern 5G networks.

In the following subsections, we verify the feasibility of implementing the NEF, considering the accessibility of other required network function services. We then explain the assumptions and design details of our quasi-NEF and present and discuss the implementation details of the proposed extension. Finally, we discuss the anticipated impact of the proposed extension.

6.1. Verification of the Accessibility of Required NF Services

The first steps in delivering a NEF application are related to the EventExposure capability of Open5GS. According to the 3GPP TS 29.508 specification [45], NEF relays SMF events to third-party applications via the Nsmf_EventExposure service. A code analysis of the Open5GS SMF implementation showed that this service was unavailable. Furthermore, when accessing the Namf_EventExposure service with a proper POST request, a Invalid Resource code is returned. The above steps were repeated for the AMF-related Namf_EventExposure service to check if mobility information could be exposed. Unfortunately, the result was the same. Since it is not possible to access the necessary resources to implement the NEF function, a different approach has been taken. The desired events are related to UE mobility and session management, so an alternative solution is to provide on-demand access to this information instead of using the Subscribe-Notify model. From the perspective of a mobile network operator, such a module would be very useful.

The provided information should include the number and type of established PDU sessions, the anchoring AMF per UE, policy enforcement, QoS statistics, and overall slice capacity. Data related to active PDU sessions and QoS policies are provided by the PCF and can be extracted through the Npcf_SMPolicyControl service API. The data regarding the overall PDU sessions can be accessed through UDR. SessionManagementSubscriptionData is the Session Management data storage. The mobility information of the UE can also be accessed via UDR resource: AccessAndMobilitySubscriptionData.

As stated above, the SMPolicyControl service should be accessible for extraction of an individual Session Management (SM) Policy that is provided by the PCF. The data of a specific SM policy is supposed to be accessible by SMF at the [apiRoot/npcf-smpolicycontrol/v1/sm-policies/smPolicyId] resource. However, issuing the HTTP/2 request returned an unexpected error code: ‘403 Invalid HTTP method’, which is not defined in the PCF specification. However, the error is not relevant, as the GET method is supposed to be used to access a selected SM policy. Further investigation revealed that the PCF code responsible for handling the Npcf interface returns an error for any request that does not comply with the syntax [apiRoot/npcf-smpolicycontrol/v1/sm-policies/smPolicyId/delete]. The PCF allows only for deletion of a given SM policy. Any attempt to extract the SM policy data with the GET method causes the PCF SBI server to return an error.

As defined in UDR specification [46], the Access and Mobility Subscription Data, along with the Session Management Subscription Data, should be accessible through the following endpoints:

• AccessAndMobilitySubscriptionData $\to$
  /subscription-data/ueId/servingPlmnId/provisioned-data/am-data.
• SessionManagementSubscriptionData $\to$
  /subscription-data/ueId/servingPlmnId/provisioned-data/sm-data.

The HTTP/2 GET requests are designed to get the Subscription Data of UE1 and includes its IMSI in the URL:

• AccessAndMobilitySubscriptionData:
  curl -X GET –http2-prior-knowledge ‘http://192.168.58.110:16005/nudr-dr/v1/subscriptiondata/imsi-666010000000001/66601/provisioned-data/am-data’.
• SessionManagementSubscriptionData:
  curl -X GET –http2-prior-knowledge ‘http://192.168.58.110:16005/nudr-dr/v1/subscriptiondata/imsi-666010000000001/66601/provisioned-data/sm-data?single-nssai=URLencoded’.

The attempt to access the AM data was successful using the given query. The returned response was in the form of JSON file and contained the subscribed Aggregate Maximum Bit Rate (AMBR) data and S-NSSAI information. Similarly, an attempt to retrieve the SM subscribed information was successful. Curl request returned a JSON containing the desired Session Management data. One must note that the curl request required an additional URL encoded S-NSSAI parameter of the pair [SST: 1, SD: ‘000001’] for the UE1 slice. According to the 3GPP standard for Nudr SBI [46], the S_NSSAI for the PDU session is a mandatory query parameter in the HTTP/2 URL for a given SM resource.

6.2. Design Details of a Quasi-NEF

The implementation of the NEF has faced challenges due to the limitations in accessing the necessary information from other NFs, such as the PCF. The initial plan to replace event exposure with the scraping of real-time and on-demand information from NFs involved in Session Management and Policing has been abandoned. The misaligned implementation of the PCF makes it currently impossible to retrieve on-demand PDU session policies, and the current release of Open5GS does not allow for access to the network state.

However, it is possible to access UE-specific data, such as subscriber data stored in MongoDB, through the UDR. Therefore, we designed, proposed, and implemented an interface to the Unified Data Repository function. The aim is to propose a quasi-NEF that can be easily integrated with virtualized cloud-based deployments of the 5GCN. The proposed NF is written in Python, a general-purpose scripting language that proved useful during the initial prototyping phase. Additionally, the pycurl module accurately replaced the curl CLI program, ensuring that the SBI services examined in the previous sections would behave in the same manner when accessed via Python scripts. The quasi-NEF’s goal is to aggregate 5G-related data that would be useful for a mobile network operator or a private 5G slice tenant. The implemented function is expected to: list all preemption-vulnerable UEs, list all preemption-capable UEs, and summarize slice data.

Such slice summary consists of the following parts:

• ALL_SUPPORTING_IMSIS, which is a list of UEs that support a given S-NSSAI.
• PER_DNN_AGGREGATED_BITRATE, which denotes the total Uplink/Downlink aggregated bitrate for a DN in a given slice.
• PER_DNN_COMMON_SUPPORTED_SSC, a parameter that outlines all SSC [21] modes present in a DN.
• PER_DNN_DEFAULT_REQUIRED_SSC, a parameter which names the default SSC mode that is common for the UEs within a slice for a DN.
• TOTAL_AMBR_UL, a parameter denoting a total Aggregated Maximum Bitrate for Uplink in the slice.
• TOTAL_AMBR_DL, a parameter denoting a total Aggregated Maximum Bitrate for Downlink in the slice.
• TOTAL_IMSIS, which is a number of UEs that support a given slice.

Listing 7 presents a summary of Session Management data for a [SST:1 SD:000001] slice returned by the implemented quasi-NEF. Full source codes are published in [42].

Listing 7. Session Management data returned by the implemented quasi-NEF.

6.3. Implementation Details of the Proposed Extension

The main class that acts as an intermediary between UDR and the rest of quasi-NEF components is PycurlClient. It is a Singleton implementation of an overloaded Curl class provided by the pycurl module. Although the class may seem as a simple replacement of curl CLI utility, it provides additional features useful in our implementation: buffering the HTTP responses, altering the pycurl-defined parameters, custom exception handling.

Listings 8 and 9 highlight the core part of PycurlClient, which interacts with UDR and extracts data. The overridden perform method allows for on-demand buffer initialization, as pycurl does not have a built-in data storing mechanism. While CLI curl by default delivers the query result to the standard output, pycurl requires defining a buffer to store the returned data. It has been implemented by assigning a BytesIO object to which pycurl writes the results of the query. The setop method ensures that any entered configuration parameters (usually the URL) are of the correct type. It also stores the accepted parameters to facilitate access to the pycurl configuration (e.g., for retrieving the type of NFs or the SBI resource).

Listing 8. A PycurlClient perform method to perform HTTP/2 request with custom Exception handling.

Listing 9. An overridden pycurl’s setop method featuring option logging.

BaseClass uses both perform and setopt in its class send_query method. The BaseClass send_query method (see Listing 10) enables dynamic generation of HTTP/2 requests via a common handle (PycurlClient Singleton) and decoding the response into a JSON format. The method is inherited by remaining NFs specific agents: AmfClient, UdrClient and NrfClient.

The BaseClass send_query method provides an acceptable data format for undergoing a feature extraction process. The JSON-encapsulated data are aggregated with the help of map/filter/reduce Python functions and presented in both human and further-processing friendly format.

Listing 10. The use-case of PycurlClient Singleton for HTTP/2 requests issuing.

The quasi-NEF data aggregation methods are called by invoking a Singleton of the AfService class, which mimics a northbound API of a real NEF [47]. Then a selection of methods can be called on the object. For example, to provide the collection of preemption-capable UEs for a particular slice as presented in Listing 11. Other possible methods allow, for example, obtaining aggregated slice data, summarizing data per slice, and obtaining the collection of preemption-vulnerable UEs. Thus, the designed functionalities are provided. The complete implementation of the AfService class is available in the repository [42].

Listing 11. Query to retrieve the collection of preemption-capable UEs for a particular slice.

The implemented quasi-NEF is capable of aggregating session and access management data extracted from the UDR. This method of data access is not typical for an actual 5GCN, as the UDR is not intended to be directly interfaced by a NEF. However, this approach was necessary to implement an NF that emulates NEF functionality using the Open5GS software. This workaround allows us to achieve a level of NEF functionality within the constraints of the current Open5GS implementation.

6.4. Anticipated Impact of the Proposed Extension

The proposed extension creates an opportunity to significantly enhance the functionality and efficiency of 5G networks. The presented integration is anticipated to have several impactful benefits for network operators and improve overall analytics capabilities.

Firstly, the NEF acts as a crucial intermediary that facilitates secure and efficient exposure of network capabilities and data to external applications and services. It enables better management and control over how network resources and data are accessed and utilized. This enhancement allows network operators to expose selected network functions and data to third-party applications in a controlled and secure manner, improving the flexibility and scalability of network services.

The NEF enhances analytics capabilities by providing a more structured and accessible framework for data collection and analysis. It enables operators to gather, process, and analyze data from various network functions and slices, facilitating more informed decision-making and optimization. With improved access to network data, operators can perform advanced AI-based analytics to gain deeper insights into network performance, user behavior, and service quality. This, in turn, allows for more accurate predictions, better resource allocation, and targeted service improvements.

Additionally, the NEF provides robust mechanisms for ensuring data privacy and security. By controlling how and which network data are exposed, it helps mitigate risks associated with unauthorized access and data breaches. Network operators can enforce security policies and compliance requirements more effectively, ensuring that external interactions with the network are secure and aligned with regulatory standards.

In summary, the integration of the NEF into our 5G core network is expected to substantially benefit network operators by enhancing network exposure, improving analytics capabilities, increasing operational efficiency, and ensuring robust security and compliance. This advancement supports more efficient network management and optimization, drives innovation, and ultimately contributes to the overall effectiveness and competitiveness of 5G network deployments.

7. Conclusions

In this work, we presented a testbed for the virtualized cloud-based deployment of the 5G network, designed to facilitate slicing, a configuration that can be particularly challenging. To aid similar deployments, we provide detailed information on our configuration process. We conducted an initial verification of the testbed, identified an error-prone scenario, and proposed an original solution to support similar cloud-based deployments. Additionally, we extended the existing implementation with a new network function, termed quasi-NEF, which serves as an interface to the UDR. This module can be seamlessly integrated into cloud-based deployments and enhances functionality with advanced analytics, a crucial feature in complex, virtualized environments. Specifically, the quasi-NEF aggregates 5G-related data, offering valuable insights for mobile network operators and 5G slice tenants. Configuration files, source code, listings, and additional figures are available in [42].

For future work, we plan to conduct comprehensive performance tests on the prepared deployment, verifying the migration process to the public cloud and comparing the performance of local versus cloud installations. While our current work provides a robust foundation, there are limitations in our performance testing that we acknowledge and plan to address in future work. Key performance indicators such as latency, throughput, and scalability will be measured using our testbed. Latency will be assessed on a per-slice basis, as enabled in the testbed. Throughput and scalability will be also evaluated by generating high volumes of traffic with virtualized UEs and monitoring the network’s ability to handle this traffic efficiently. We will also assess the control plane’s capability to manage large numbers of simultaneous UE registrations and the network’s ability to support dynamic horizontal scaling with an orchestration layer.

In addition to performance evaluations, we aim to develop and automate our solution, focusing on dynamic network function management. Further efforts will explore container-based deployments in comparison to the existing virtual machine-based approach. As we move forward, we will explore container-based deployments to assess their impact on performance and scalability. This will involve adapting our testbed to support container orchestration platforms such as Kubernetes, which will enable more efficient resource management and scalability. It will also be valuable to verify the performance of the testbed deployed using server-level virtualization. Through these future works, we hope to provide a robust and flexible testbed environment that advances the knowledge and capabilities of 5G network deployments.

Recognizing the limitations of the 5GCN software used in the testbed, we designed and implemented the quasi-NEF as an intermediary step towards a full-fledged NEF. The quasi-NEF could be enhanced to support event exposure by enabling external applications to subscribe to 5G network events, such as UE deregistration. The full NEF would allow external applications to receive notifications of specific network events by subscribing to the relevant network functions. Potential future work regarding the NEF function includes conducting comprehensive evaluations to measure its impact on network efficiency and analytics capabilities. Further research could explore integrating advanced machine learning algorithms to enhance data processing and predictive analytics within the NEF framework. Finally, investigating the scalability of the NEF in larger, real-world 5G deployments can provide insights into its practical applications and limitations.