Automating 5G network slice management for industrial applications

Contents lists available at ScienceDirect Computer Communications journal homepage: www.elsevier.com/locate/comcom Automating 5G network slice management for industrial applications André Perdigão∗, José Quevedo, Rui L. Aguiar Instituto de Telecomunicações, Aveiro, Portugal Universidade de Aveiro, Aveiro, Portugal ARTICLE INFO Keywords: Private 5G networks Testbed Network slicing Industry 4.0 Industrial IoT ABSTRACT The transition to Industry 4.0 introduces new use cases with unique communication requirements, demanding wireless technologies capable of dynamically adjusting their performance to meet various demands. Leveraging network slicing, 5G technology offers the flexibility to support such use cases. However, the usage and deployment of network slices in networks are complex tasks. To increase the adoption of 5G, there is a need for mechanisms that automate the deployment and management of network slices. This paper introduces a design for a network slice manager capable of such mechanisms in 5G networks. This design adheres to related standards, facilitating interoperability with other software, while also considering the capabilities and limitations of the technology. The proposed design can provision custom slices tailored to meet the unique requirements of verticals, offering communication performance across the spectrum of the three primary 5G services (eMBB, URLLC, and mMTC/mIoT). To access the proposed design, a Proof-of-Concept (PoC) prototype was developed and evaluated. The evaluation results demonstrate the flexibility of the proposed solution for deploying slices adjusted to the vertical use cases. Additionally, the slices generated by the PoC maintain a high TRL (Technology Readiness Level) equivalent to that of the commercial-graded network used. 1. Introduction The industry is expected to experience the Fourth Industrial Revolution named Industry 4.0 (I4.0). This revolution is expected to impact the entire production line by increasing the connectivity between equipment through the application of the Internet of Things (IoT) directly in industrial processes, which was named Industrial IoT (IIoT). Consequently, this can lead to substantial cost reduction, heightened production efficiency, improved worker safety, higher customization of products, and enhanced material quality. Since 5G is one of the technologies capable of providing the necessary connectivity for the revolution, the industry has become actively engaged in advancing and standardizing this technology. This has led to the integration of old and new technologies such as TSN (Time Sensitive Networking) [1] and 5G-NPN (5G Non-Public Network) [2], and the development of novel use cases based on diverse technologies within 5G, such as Edge computing [3] and Sidelink [4]. Industries must optimize all equipment and processes in their production to remain competitive and maximize resource usage. In this optimization journey, 5G will become one of the key assets, with network slicing emerging as a crucial mechanism. Network slicing enables network customization to accommodate various communications needs, thereby optimizing network resource usage. ∗Corresponding author at: Universidade de Aveiro, Aveiro, Portugal. E-mail addresses: [email protected] (A. Perdigão), [email protected] (J. Quevedo), [email protected] (R.L. Aguiar). Therefore, for wide adoption of 5G, it is crucial to deploy network slices aligned with the communication requirements, enforcing a slice tailored to the specific needs of the use case, thereby optimizing resource usage. However, configuring 5G is complex and requires expertise. Manual configuration of network slices is time-consuming and error-prone. Therefore, an automation mechanism capable of converting high-level requirements into low-level configurations is necessary. There are numerous works in the literature that enable various QoS configurations and other 5G features to optimize resource usage, such as those presented in [5–9], and [10]. The extensive research on resource optimization using network slices highlights the importance of optimizing network slice resource usage. Additionally, authors in [10] conclude that resource optimization is extremely important for the deployment of the different use cases evaluated. Despite the significant importance of network slicing, previous work highlighted in [11] revealed the absence of a widely available mechanism for deploying and managing network slices in 5G networks. With no existing mechanism or network function to provide and manage 5G slices, the focus shifted towards developing a network slice manager, as presented in this paper. The work examined industry requirements for leveraging 5G technology in their processes, highlighting the crucial role of network https://doi.org/10.1016/j.comcom.2024.107991 Received 29 May 2024; Received in revised form 30 September 2024; Accepted 28 October 2024 Computer Communications 229 (2025) 107991 Available online 4 November 2024 0140-3664/© 2024 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY license ( http://creativecommons.org/licenses/by/4.0/ ). A. Perdigão et al. slicing in providing mechanisms for verticals to control communication performance according to their requirements. Subsequent efforts focused on analyzing and understanding existing mechanisms within the 5G network capable of adapting network performance to meet industrial requirements. The analysis started with [11], which introduced the Quality of Service (QoS) model and assessed the available Release 15 (R15) QoS configurations, emphasizing their predominant impact on throughput. This initial investigation prompted a deeper examination of 5G features and technologies. [12] analyzed standardized features of Release 17 (R17) 5G Radio Access Network (RAN), while [13] focused on 5G features tailored to emulate performance similar to a massive Machine Type Communication (mMTC) slice. Building upon these insights, [14] mapped the 5G features to industrial use cases and network slice attributes. The resulting mapping was assessed to demonstrate its effectiveness in optimizing network performance according to requirements, with limitations imposed by available resources and network capabilities. This comprehensive study provided the foundational knowledge essential for automating network slice deployment. The analysis presented in previous work [11–14] was important for understanding the functioning of the 5G network. This knowledge is essential for designing and developing an automated system that deploys and manages network slices. Since it is not possible to design and develop a slice manager solution without a complete understanding of the 5G network, it was necessary to first understand the operational details and how they can be controlled to effectively manage network slices. The accumulated knowledge is then leveraged in this paper to design the network slice manager presented in this document. This proposed solution enables the programmatic reconfiguration of a 5G network to ensure it supports the slices demanded by industrial users while adhering to slice manager standards. To achieve this, the network slice manager maps network slice requirements to low-level network configurations and provides these configurations to a Digital Twin (DT). The DT then enforces the necessary configurations on the network to ensure the required slice is supported. The low-level configurations used include the QoS mechanism, 5G features, and other technologies assessed in previous work. The design was implemented in a Proof-of-Concept (PoC) prototype, developed specifically to configure the 5GAIner network [15]. This document assesses the capabilities of the proposed solution, aiming to demonstrate its effectiveness. The main contributions of the developed solution are outlined below: (1) The network slice manager generates slices tailored to one of the three primary 5G services [eMBB (enhanced Mobile Broadband), prioritizing throughput and spectral efficiency, URLLC (Ultra Reliable Low Latency Communication), focusing on low latency and high reliability, and mMTC/mIoT (massive Internet of Things), aiming for low device energy consumption and high connection density] based on provided network Key Performance Indicators (KPIs). (2) Within each service type, the network slice manager offers complete customization of slice construction to meet specific requirements. (3) The slices configured by the network slice manager preserve the network Technology Readiness Level (TRL), being the produced slices representative of a commercial-graded solution. (4) The slice manager provides dynamic slicing enabling the adaptation of the slice performance in real time without communication disruption. The remaining sections of the document are as follows: Section 2 briefly analyses related work. Section 3provides a summarized list of requirements for a slice manager and compares the proposed solution with existing solutions. Section 4introduces the standards involved in 5G network slice automation and describes the proposed design for a network slice manager. Section 5presents 5GAIner and provides an overview of the developed PoC, including a brief discussion of each component of the solution. Section 6introduces the parameters of three network slices used to evaluate the solution and describes how the performance assessment was executed. Section 7presents and discusses obtained results. Section 8has the final discussion and conclusions of the document. 2. Related work In light of the potentially transformative impact of 5G technology, the industry has actively engaged in its development, leading to the establishment of various industrial organizations such as 5G-ACIA,16GIA,2and 5G-DNA.3These organizations play key roles in 5G technology standardization, promotion, and evaluation. Through their interactions with the technology, industrial organizations have developed and promoted numerous use cases that leverage the capabilities of 5G networks. Examples of these use cases can be found in [3,4,16], and [17]. Several projects leverage numerous 5G testbeds, such as [18–22], and [15], as well as those developed by European projects like 5GEVE,45G-VINNI,5and 5GENESIS.6These testbeds are used for developing, testing, and validating numerous industrial use cases. In different research projects, among these projects are: •5GASP,7which, while capable of providing limited configurability of eMBB slices on the 5G network, primarily relies on default network configurations. •5G-ERA,8allowing the selection of pre-configured network profiles tailored to the specific requirements of the use case. •Smart5Grid,9which implements a slice manager for logical isolation between slices in the core. In the RAN, slice management involves direct allocation of physical resources, with limited configuration options for network features affecting prioritization and resource sharing. •5GMediaHUB10 uses slices to manage services and Virtual Network Functions (VNFs), although specific details regarding their 5G configurations are not publicly available; •Imagine-B5G,11 divided into four facilities, each employing specific mechanisms for slice deployment and management. The French facility allocates RAN physical resources into each slice. The Norwegian Facility configures different User Plane Functions (UPF) and control plane functions for each slice, with some QoS configurability in the Policy Control Function (PCF). Domain A of the Portuguese facility uses the network slice manager outlined in this document, while Domain B offers eMBB and URLLC slices with limited QoS configurations. The Spanish facility allows one UPF per slice and offers limited QoS configuration options. Besides the work on projects related to managing network slices in the 5G network, there is also some research. In [23], the authors analyzed the usage of Network Function Virtualization (NFVs) to support network slices, demonstrating that the NFV platform is robust for this 1https://5g-acia.org/, (April 2024). 2https://6g-ia.eu/, (April 2024). 3https://www.5gdna.org/?_l=en&_l=en, (April 2024). 4https://www.5g-eve.eu/, (March 2023). 5https://www.5g-vinni.eu/, (March 2023). 6https://5genesis.eu/, (March 2023). 7https://www.5gasp.eu/, (December 2023). 8https://5g-era.eu/, (December 2023). 9https://smart5grid.eu/, (December 2023). 10 https://www.5gmediahub.eu/, (December 2023). 11 https://imagineb5g.eu/, (December 2023). Computer Communications 229 (2025) 107991 2 A. Perdigão et al. purpose. In [24], the authors developed a solution to manage and orchestrate network slices in an OpenAirInterface 4G network. Similarly, the authors in [25] devised solutions for Non-3GPP networks, which can adjust network slice performance and deploy multiple network slices in their testbed. While surveying the current state of the art, we identified already extensive work around network slices, such as [5–8], and [9], that do not explicitly focus on the development of the slice management model already provide some differentiated Quality of Service. Other articles, such as [26,27], and [28], are focused on the algorithms and resource allocation in network slicing. Some articles, like [29,30], and [31], research on the coexistence between eMBB and URLLC slices. Other articles focus on orchestrating network slices, such as [32,33], and [34]. However, no research was found addressing the development of a network slice manager capable of translating Network Slice Descriptor (NSD) parameters into low-level 5G configurations while ensuring the realistic performance aligns with the specified NSD parameters. Since there is a lack of research on the management level of slices, and considering the importance of a network slice manager capable of adjusting the 5G network to provide a custom network slice that ensures required use case performance while fulfilling the demanded SLAs, the following section analyzes the requirements that a network slice manager should fulfill and discusses the capabilities of the existing slice managers. 3. Slice manager requirements Industrial organizations proposed many use cases with completely distinct requirements, demanding extreme network flexibility to accommodate them. However, existing network slice managers supported by projects and research have limitations in configuration. They cannot adjust the 5G network to ensure the required performance for each use case. The proposed use cases necessitate a more flexible network slice manager capable of configuring the 5G network to support the required network slice, ensuring the necessary performance for each use case. Over the past few years, several open-source and proprietary solutions have been researched and developed. To characterize the network slice manager solutions, the standard documentation has been reviewed to define the requirements list that a network slice manager needs to fulfill. The main standard documents used to extract the requirements are [35–37]. A large number of requirements are defined in these documents. Several requirements have been summarized and aggregated from this list to produce the most important network slice manager requirements identified by the authors. The resulting list of requirements is as follows: •E2E (End-to-End) Slice Support: The solution enables authorized users to manage the complete slice by interacting with the necessary slice and slice subnet instances in the RAN, CN, and TN, ensuring the required slice capacities across the communication link. •Manage Slice Lifecycle: The solution supports the different stages of the slice lifecycle, including activation, deactivation, modification, and termination. •Network Slice Mapping: The solution uses slice requirements provided in a GST template, service profile, or slice profile to decide whether to use an existing or create a new network slice. It generates slice configurations necessary for the network to meet performance requirements and adjust slice resource access according to slice priorities. •Network Configuration: The solution configures NF (Network Function) instances (New Generation-RAN [NG-RAN] functions, TN functions, and 5G core functions [User and Control Plane 5G functions]), applying the necessary configurations provided by the mapping, thus ensuring the support of the required slice on the network. •Policy and QoS Management for SLA Enforcement: The solution can adjust communication rules (e.g., PCC [Policy and Charging Control] rule) and QoS configurations to enforce the required slice Service Level Agreements (SLAs). •Dynamic Slicing: The solution can seamlessly adjust QoS configurations and communication rules, changing slice communication performance without interfering with end device communications. •Custom Slices: The solution supports the deployment of any slice on the available network, allowing for the deployment of custom slices tailored to specific user requirements. •Network Slice Monitoring: The solution can monitor resources used by the provided network slices and report KPIs to authorized consumers. •Location-based Slicing: The solution enforces the required slice only in the specified coverage area, configuring the NFs responsible for that designated area. UEs accessing areas outside the coverage have no service or use a default eMBB slice. •Performance Assurance: The solution collects and analyzes relevant data and KPIs, using thresholds to verify the fulfillment of slice requirements for charging policies and performance adjustment. •Manage Multiple Slices: The solution possesses management capabilities for deploying and managing multiple independent slices. It can manage different slices in various stages of the slice lifecycle and differentiate communication among different slices. •Monitor Network Resources: The solution can monitor available and used network resources. •Evaluate Slice Feasibility: In the case of multi-slicing, the solution should verify the feasibility of deploying a new slice without impacting existing slices, ensuring the existence of adequate available network resources. •Generic Network Support: The solution can support any standardized network function from any network provider. Beyond the above-compiled list of requirements, exists numerous other crucial requirements for a complete network slice manager solution, such as support for Multi-Access Edge Computing (MEC), network services, and multiple domains. These requirements were omitted from the list for two reasons: firstly, the document centers on network slice provision in a 5G network, and secondly, the provided solution can be integrated with OSM and OpenSlice, which already fulfill most of the omitted requirements. While searching for tools capable of managing 5G networks the following were found: Openslice,12 OPEN BATON,13 Open Source MANO (OSM),14 SliMANO [38], Nokia Network as Code (NaC),15 Open Air Interface (OAI) Operation and Maintenance (OAM),16 and 5GrowthVS [39]. But while reading the tools documentation became clear that: Openslice is a vertical portal; OPEN BATON and OSM are network service managers and orchestrators, not addressing any management or orchestration of network slices, so these tools are not further discussed. SliMANO is a proposed framework that has not been developed. Nokia NaC and 5Growth-VS are network slice orchestrators, which use a network slice manager to interact with the network. OAI OAM operates and maintains the 5G infrastructure, not specifically focused on deploying and managing network slices. In Table 1, the functionalities of tools interacting with the 5G network are summarized, compared to the Proposed Solution. In the 12 https://openslice.readthedocs.io/en/latest/ (December 2023). 13 https://openbaton.github.io/features.html (December 2023). 14 https://osm.etsi.org/ (December 2023). 15 https://www.nokia.com/networks/network-as-code/ (December 2023). 16 https://openairinterface.org/projects/oam-project-group/ (December 2023). Computer Communications 229 (2025) 107991 3 A. Perdigão et al. Table 1 Network slice managers. hhhhhhhhhh h Functionality Automation tool SliMANO Nokia NaC OAI OAM 5Growth-VS Proposed solution E2E slice support ✓ ✓ ✓ ✓ Manage slice lifecycle ✓ ✓ ✓ ✓ Network slice mapping ✓ Network configuration ✓ ✓ ✓ ✓ Policy and QoS management for SLA Enforcement ✓ ✓ ✓ Dynamic slicing ✓ Custom slices ✓ Network slice monitoring ✓ ✓ ✓ ✓ ✓ Location-based slicing ✓ Performance assurance ✓ Manage multiple slices ✓ ✓ ✓ ✓ Monitor network resources ✓ Evaluate slice feasibility ✓ Generic network support ✓ table, a ‘‘✓’’ denotes that the tool supports the functionality, while blank entries indicate functionalities not mentioned in the tool’s documentation. SliMANO, Nokia Nac, and 5Growth-VS primarily focus on orchestration and high-level management aspects of 5G, lacking comprehensive management capabilities and detailed insights into the intricacies of the 5G network. As a result, many important management-level functionalities are left unaddressed, leading to numerous empty cells in the table. Among the reviewed tools, only OAI OAM offers capabilities to adjust the low-level configuration of a 5G network. However, it lacks integration with high-level management and orchestration of network slices, further highlighting the gap in comprehensive 5G network management solutions. Given the significant absence of solutions capable of managing 5G networks to provide slices tailored to end-user requirements, this document proposes the design of a network slice manager. This manager aims to bridge the gap between low-level 5G network configurations and high-level Network Service Descriptor (NSD) parameters. Based on this design, a PoC was developed, more focused on vertical use cases. The objective is to provide E2E slices that meet user requirements while considering the realistic impact of each configuration. The developed network slice manager can configure a commercial Standalone (SA) 5G network with multiple network slices, adjusting communication performance based on user requirements outlined in a slice or service profile. 4. Standards and slice manager design Compliance with existing standards was essential to develop a network slice manager capable of configuring the 5G network to support desired network slices. Section 4.1 introduces the 3GPP standards considered in the design and development of the slice manager. Section 4.2 presents the overall design of the slice manager. 4.1. Network slice automation standards Standardization bodies such as 3GPP and .541 IETF have established various standard definitions for network slice managers. Therefore, when developing any slice manager, it is crucial to adhere to these standards to facilitate interoperability and interaction with other software. The standards considered in the design are the following: •3GPP TS 28.531 [40]: This document outlines the essential Network Functions for a standardized network slice manager, including Communication Service Management Function (CSMF), Network Slice Management Function (NSMF), and Network Slice Subnet Management Function (NSSMF) of the different segments of the network Core Network (CN), Transport Network (TN), and RAN. Fig. 1. Proposed network slice manager design. •3GPP TR 28.824 [41]: It identifies the Tele Management Forum standards (TMFs) required for the slice manager. It specifies that CSMF should adhere to TMF622_ProductOrder,17 and NSMF should support TMF641_ServiceOrder.18 •3GPP TS 28.541 [42]: This document delineates the profiles associated with network slices, including ServiceProfile, TOPSliceSubnetProfile, CNSliceSubnetProfile, RANSliceSubnetProfile, NsacfInfoSnssai, and the NSACFFunction. •3GPP TS 28.530 [35]: It presents the Network Slice Management Lifecycle. 4.2. Network slice manager design The proposed network slice manager design is shown in Fig. 1, using the knowledge gathered from previous analyses and considering the standards. This design has three main components: the Slice Manager, the Mapping, and the Digital Twin. 4.2.1. Slice manager Taking into account what 3GPP defines for the Slice Manager presented in Section 4.1. In the design of the slice manager, it is considered the maximum number of standards possible to increase interoperability with other software. Therefore, the design comprises the distinct network functions identified in the standards, containing the CSMF, NSMF, NSSMF-CN, NSSMF-TN, NSSMF-RAN, and Network Slice Admission Control Function (NSACF). Within the CSMF and NSMF, the endpoints identified in the TMFs should be included. Additionally, the 17 https://github.com/tmforum-apis/TMF622_ProductOrder/tree/master, (December 2023). 18 https://github.com/tmforum-apis/TMF641_ServiceOrder/tree/master, (December 2023). Computer Communications 229 (2025) 107991 4 A. Perdigão et al. Fig. 2. Components of proposed network slice manager. network slices within each network function are identified with the following profiles: ServiceProfile in CSMF, TOPSliceSubnetProfile in NSMF, CNSliceSubnetProfile in NSSMF-CN, RANSliceSubnetProfile in NSSMF-RAN, and a list composed of NsacfInfoSnssai in NSACF. The NSACF is responsible for anything related to the association of User Equipments (UEs) with the network slices, such as linking UEs to slices and limiting the number of UEs per slice. The NSSMF-TN is currently being standardized by IETF, as described in [43]. However, since this work primarily focuses on optimizing 5G technology and the transport network uses technologies such as Software-defined networking (SDN), where extensive development has already been done on NSSMF-TN, as evidenced by the work presented in [44]. Therefore, this document will no longer discuss NSSMF-TN, remaining here solely for the completion of the design. Fig. 2presents the different components expected in a final version of a network Slice Manager. This image is based on the requirements discussed in Section 3. At its core, the slice Manager must provide multiple network slices and convert slice parameters into network configurations. This requires support for managing multiple slices, E2E slice support, and network slice mapping to convert slice requirements into network configurations. A simple implementation can offer a set of preconfigured network slices. Dynamic Slicing capability can enhance this base component, allowing for more adaptable network slices. Dynamic slicing can be used for performance assurance or to adjust slice performance as required by a vertical application, potentially due to traffic changes. The effective function of these core components necessitates network resource monitoring and the capacity to evaluate slice feasibility. To fully manage the slice lifecycle, the slice manager needs network slice monitoring for slice supervision. This enables it to generate necessary reports when slice performance is not assured. With supervision and reporting capabilities, the slice manager can use dynamic slicing to adjust and assure slice performance. 4.2.2. Mapping As mentioned earlier, the simplest implementation of slice mapping involves selecting a pre-configured slice. However, the network slice mapping can be enhanced with the capability to provide slice customization, as illustrated in Fig. 2. This customization is enabled by location-based slicing and adjustment to Policy and QoS management enforcing the required SLAs. For comprehensive slice customization, the Mapping should consist of three separate components: RAN Mapping, a part of NSSMF-RAN; CN Mapping, a part of NSSMF-CN; and UE Mapping, a component of NSACF. The CN and RAN mappings handle the conversion between Slice subnet profiles and standard 5G network functionalities, involving QoS configurations and other 5G features. The UE mapping converts end device parameters to network functionalities, manages the association between UE and slice, and extracts slice parameters necessary for UE configuration. The different mapping components must interact to ensure that the configurations provided to the DT will properly configure the E2E slices. 4.2.3. Digital twin The Digital Twin (DT) is a digital replica of the 5G network, encompassing a digital copy of the entire 5G infrastructure. It includes the 5G RAN, TN, and the 5G Core Twin, each containing comprehensive information about its corresponding component. The DT tracks network status, alarms, resources, and configurations and monitors devices and network configurations. Consequently, the DT will know available, allocated, and used resources, the status of different network components, and details of connected UEs, including used slices, communication performance, and resource consumption. All these capabilities provide additional functionalities to the DT. However, in this design, the primary purpose of the DT is to standardize interaction with the 5G network. This enables the Slice Manager to access standard APIs and use standard configurations and monitoring capabilities, making the Slice Manager generic enough to support any network. Even though the 5G network functions are standardized, their implementation, limitations, and interactions may vary across network implementations. The DT grants the slice manager access to all network capabilities while maintaining its generic nature to support Network Functions from any provider. This ensures that the slice manager can effectively manage network slices, regardless of potential differences in network implementations. One example of the importance of DT is translating standard QoS configurations and 5G features to the configurations available in the network. Since each implementation of a 5G network can have different names and slightly different implementations for each of the 5G features, the DT needs to make a secondary mapping between the standard and actual functionalities of the network implementation. 5. Developed network slice manager prototype To validate the proposed design for a network slice manager, a Proof-of-Concept (PoC) has been developed based on the proposed design. This was mainly developed to interact and configure a Computer Communications 229 (2025) 107991 5 A. Perdigão et al. Fig. 3. Slice manager PoC final integration to Imagine-B5G Portuguese facility. commercial-graded SA 5G network, ensuring it can support custom network slices and dynamic slicing. This section provides an overview of the developed network slice manager PoC. The developed solution adheres to the design presented in Section 4.2, with slight adaptations made for various reasons. These include enhanced configurability for the user, improved security, and smoother interaction between functions. The current capabilities and adaptations of the developed PoC are outlined in the following subsections. The current PoC accepts REST requests to configure the 5G network, allowing it to work with Postman19 and any software capable of sending REST commands. The PoC can be converted into a container for easy deployment, management, and replication. The final integration of the slice manager PoC into the Imagine-B5G Portuguese facility is represented in Fig. 3, as described in [45]. It is essential to note that this software represents an initial version developed for PoC demonstrations of proposed functionalities. Future iterations will integrate enhancements and additional features. The current version of the software exhibits expected design limitations and areas marked for improvement, partly due to constraints in interacting with the 5G network used. One of the anticipated improvements will involve the DT by modifying its interaction with the 5G network and enhancing it with more functionalities. 5.1. Slice manager The developed solution includes all standard network functions. The external endpoints of CSMF and NSMF, as identified in the TMFs, are currently limited to create, update, delete, and get. These endpoints are open as a REST request, enabling the end user to interact with the PoC to implement and configure the necessary network slices. Considering the requirements imposed on a Slice Manager discussed in Section 3,Fig. 4presents the components implemented in the PoC. In blue and orange, the component is already implemented and presented in this document; in yellow, the component is implemented but not presented here; and in gray, the component is not implemented. The image illustrates that the current PoC already supports the base components of a slice manager: managing multiple slices, supporting E2E slices, mapping network slices to network configurations, and enabling dynamic slicing. It also includes the essential capabilities of network resource monitoring and slice feasibility evaluation, which are crucial for the operation of the other components. As expected, the PoC supports only part of the slice lifecycle management, lacking 19 https://www.postman.com/, (May 2024). supervision and reporting. As a result, dynamic slicing can only be triggered by external requests. In addition to the profiles identified for different functions, the solution incorporates additional variables aimed at providing enhanced control of network slices to end-users or facilitating slice management between functions. For example, the ‘‘DNN’’ (Data Network Name) and ‘‘Name’’ parameters in CSMF and NSMF serve the former purpose. Meanwhile, the ‘‘fiveQI’’ parameter was introduced in NSSMF functions to facilitate the interconnection of RAN and CN mapping, ensuring end-to-end slice control and interoperability. The DNN parameter within CSMF and NSMF empowers end-users by granting them complete control over the slice. This control involves defining the SNSSAI (Single–Network Slice Selection Assistance Information) [SST (Slice/Service Type) +SD (Slice Differentiator)] and the DNN, which leads to a more isolated network slice for the end user. Assigning unique DNN and SNSSAI ensures that the slice remains exclusive to the user, creating unique network configurations tailored to the required slice. The ‘‘Name’’ parameter enables dynamic slicing by the network slice manager. This parameter specifies the slices used in dynamic slicing, and these slices share user profiles, which reduces isolation between them. However, sharing user profiles across slices with different purposes introduces security vulnerabilities, prompting the inclusion of this parameter. Dynamic slicing relies on specific network functionalities that may not be present in other 5G network implementations. In this case, during the dynamic slice transition, in UPF, old slice rules are removed from the user profile while new slice rules are added, and in UDM, the UEs are associated with the new slice. Due to the absence of certain network functions in the utilized network and the intricate nature of the 5G network, not all profile parameters were thoroughly explored in this initial version of the software. The parameters currently employed by the CSMF and NSMF in the slice creation are outlined in Table 2, along with their expected values. The expected values vary depending on standard requirements, network configurations, or implementation decisions. To differentiate between restrictions stemming from network configuration (⊛) and implementation decisions (⋇), symbols are placed before the restriction. In [40], concrete values for N6protection were not specifically defined. Therefore, it was utilized to establish UPF Rules, which currently support the PCC (Policy and Charging Control) rules and their corresponding filters. The filter parameters are described in Appendix A.1. The current software aligns with the instances depicted in Fig. 5 reflecting the Network Slice Life Cycle Management defined in [35]. Thus, the software is currently configured to support various stages of the Network Slice Lifecycle, including Creation, Activation, Modification, Deactivation, and Termination. The slice manager also includes a simplified version of the NSACF with the UE mapping, which facilitates the linkage between UEs and slices while extracting essential values from the slice profiles required for the UE configurations within the 5G network. This NSACF contains a simplified list of parameters compared to the ones defined in the standard; the supported parameters can be seen in Appendix A.2. 5.2. Mapping The mapping of slice parameters to network configurations is a pivotal aspect of the developed solution addressed here. All components of this mapping process have been implemented, enabling the support for custom slice through location-based slicing and policy and QoS management for SLA enforcement and ultimately converting everything into network configurations. As mentioned earlier, the Mapping is segmented into three parts: RAN mapping, CN mapping, and UE mapping. The mapping involves diverse network configurations, a concise impact description for each configuration is provided in Appendix A.3. Computer Communications 229 (2025) 107991 6 A. Perdigão et al. Fig. 4. PoC implemented components. Table 2 Supported profile parameters. Parameter name Expected value Slice identification str (any value ⊛not allowed [,;="’]) Name str (any value ⊛not allowed [,;="’]) Administrative state str (LOCKED - UNLOCKED - SHUTTINGDOWN) Operational state str (ENABLED - DISABLED) Coverage area list of strings with names of selected areas SST (Slice/Service Type) int (0-255) SD (Slice Descriptor) str ⊛with six numbers DNN ⋇str of DNN used Priority label int ⋇(0-100) UE mobility level str (stationary - nomadic - restricted_mobility - fully_mobility) Reliability float (0-100) Uplink max packet size int ⊛bytes Downlink latency int milliseconds Uplink latency int milliseconds Delay tolerance str (SUPPORTED - NOT_SUPPORTED) Downlink deterministic communication str (SUPPORTED - NOT_SUPPORTED) Downlink deterministic periodicity int ⋇milliseconds Uplink deterministic communication str (SUPPORTED - NOT_SUPPORTED) Uplink deterministic periodicity int ⋇milliseconds Downlink guaranteed throughput per UE int ⋇kbit/s Uplink guaranteed throughput per UE int ⋇kbit/s Downlink maximum throughput per UE int ⋇kbit/s Uplink maximum throughput per UE int ⋇kbit/s Downlink guaranteed throughput per slice int ⋇kbit/s Uplink guaranteed throughput per slice int ⋇kbit/s Downlink maximum throughput per slice int ⋇kbit/s Uplink maximum throughput per slice int ⋇kbit/s Terminal density int ⊛UEs per antenna Maximum number of PDU (Protocol Data Unit) sessions int ⊛UEs per UPF Maximum number of UEs int ⊛UEs registered in slice N6Protection ⋇list of PCC rules Fig. 5. Program supported instances in network slice lifecycle. Since mapping is an essential part of the PoC that has been developed, the following subsections provide a pseudo-code representative of the code used in the PoC. It is important to note that the developed PoC is technology-specific and depends on the equipment used, based on a network characterization made in previous work, as seen in [11–14]. Additionally, the following pseudocode uses standardized parameter names whenever possible, which may have a different performance impact than the equivalent functionality of the used network solution. Therefore, the mapping requires adjustments when using a different 5G network solution. The code used was Python, and the pseudocode provided considers Python mathematical operators. The variables provided by the user are characterized by a‘slice.‘‘parameter name’’’, while the other variables are provided to the DT to configure the network. Table 3extends some of the abbreviations used in the following code. 5.2.1. RAN mapping The pseudocode in Appendix A.4 gives an overview of how mapping in the PoC is done. The missing configurations use predefined testbed values or are directly mapped from user-provided values. The Computer Communications 229 (2025) 107991 7 A. Perdigão et al. Table 3 Glossary. ARP Allocation and Retention Priority PDU Packet Data Unit SSC Session and Service Continuity AMBR Aggregate Maximum Bit Rate MICO Mobile Initiated Connection Only DRX Discontinuous Reception PDCP Packet Data Convergence Protocol BLER Block Error Rate code defines a variety of RAN configurations, including 5QI configurations, protocol configurations (MAC, RLC, and PDCP), scheduling configurations, and DRX configurations. 5.2.2. CN mapping The pseudocode in Appendix A.5 represents only part of the features and QoS used in the CN mapping. The PoC code also includes the configuration of PCC rules, which is a direct mapping from Appendix A.1 to network parameters, as well as the configuration of user profiles, DNNs, IP Pools, and SNSSAIs. These configurations use specific integer numbers and the slice ID. Since these values are technology-specific or implementation-specific, they are not presented here. 5.2.3. UE mapping The UE mapping involves using configurations defined in Appendix A.2 directly mapped to UE network settings. Additionally, it is necessary to obtain the following values from the selected network slice to configure the UE network settings: Mission Critical Service, High Latency Communication, MICO, SNSSAI, and DNN. 5.3. Digital twin The developed DT is a simplified version of the proposed one with limited capabilities. The developed version focuses on providing the necessary functionalities for the slice manager’s operation. As the work aims to develop a PoC of a generic network slice manager capable of deploying and managing custom network slices rather than creating a comprehensive digital twin of a specific 5G network. The developed system uses the digital twin layer, but for the PoC, only the interfaces provided by the digital twin are essential. The details of the digital twin’s implementation are not critical for the proposed work. The current version of the DT can convert network functionalities derived from mappings into network configurations. The produced network configurations are enforced on the respective 5G network functions, including RAN, UPF, SMF (Session Management Function), AMF (Access and Mobility Management Function), and UDM (Unified Data Management). The interaction with these different network functions is done through proprietary interfaces. Additionally, the DT already has monitoring capabilities, documented in [46]. The monitoring will be later integrated with the slice manager to provide more functionalities and complete network slice lifecycle management. 6. Solution evaluation To assess the developed PoC, its capability to provide the primary three services within a 5G network (eMBB, URLLC, and mMTC) was verified. Each evaluated slice focuses on the performance of its respective service type, with significantly different requirements from one another. This approach ensures a more robust evaluation of the developed slice manager. The section begins by introducing the 5GAIner network used for the evaluation, followed by an outline of the configured values for each tested slice. Subsequently, the section presents and discusses how the tests were performed. Table 4 gNodeB Technical specifications. Specification Values Maximum bandwidth 20 MHz with 30 kHz subcarrier spacing Frequency band Center frequency of 3790.02 MHz (n78 band) Output power per port 24 dBm Demultiplexing TDD DL Modulation BPSK; QPSK; 16/64/256QAM UL Modulation BPSK; QPSK; 16/64QAM MIMO 4T4R Slot assignment Dual-period 7 Downlink: 3 Uplink (Slot structure 102) 6.1. 5GAIner network 5GAIner is a commercial-graded real-world infrastructure supporting some Release 17 (R17) functionalities. This platform is at the core of Portuguese facility infrastructure. This 5G network spans various geographical locations, including the Instituto de Telecomunicações (IT) of Aveiro and the University of Aveiro. Primarily, IT and its partners utilize this infrastructure for research, development, testing, and validation of diverse use cases and 5G technologies. Presently, the network supports eMBB and URLLC slices and encompasses several features facilitating the provision of mMTC slices. Operating within a reserved band of Altice, a Portuguese operator, the network’s antenna configurations used in the evaluations are detailed in Table 4, providing essential insights into the network’s performance. For further details, refer to [15]. While the document discusses the network in Release 15, it currently operates with full support for Release 16 and includes some R17 functionalities. However, there have been no significant alterations in the network’s baseline performance or hardware. Therefore, the presented results and descriptions remain an accurate network representation. 5GAIner network does not have a simplified method for machine-tomachine communication to directly transmit the commands generated in the Digital Twin (DT). Therefore, the DT uses Selenium to access the network configuration interface of each network function. 6.2. Evaluated network slices The chosen values for each network slice were not specifically tailored to any specific use case. Instead, they aimed to reflect possible performance characteristics of the respective slice type, considering the constraints specified in Table 2. The selected values for each slice are detailed in Table 5. The significant distinctions in the defined values are intended to enforce different configurations in each slice, showcasing the versatility and robustness of the developed solution. This approach also serves as a valuable test for the slice manager, demonstrating its ability to manage diverse network configurations. The selected network slices serve distinct primary purposes: (1) eMBB focuses on achieving high throughput with relatively high reliability and priority. To achieve this, it employs high throughput and packet size, medium reliability and priority, mediumlow latency, high communication frequency, and guaranteed throughput per UE. (2) URLLC prioritizes high reliability and low latency, featuring medium-low throughput and packet size, maximum reliability and priority, low latency, medium communication frequency, and assured throughput per UE and slice. The guaranteed and maximum throughput values are much higher than necessary to ensure enough resources for low latency with high reliability. (3) mMTC aims at high connection density and low energy consumption, employing low throughput, reliability, priority and communication frequency, medium packet size, and high latency and terminal density. The number of PDU sessions is undefined Computer Communications 229 (2025) 107991 8 A. Perdigão et al. Table 5 Network slices evaluated. Parameter name eMBB URLLC mMTC Slice identification eMBB URLLC mMTC Administrative state UNLOCKED Operational state ENABLED Coverage area IT SST 1 2 3 SD 123456 DNN eMBB URLLC mMTC Priority label 70 100 10 UE mobility level Stationary Reliability 99.9 99.999 99 Uplink max packet size 2000 150 500 Downlink latency 20 10 500 Uplink latency 20 10 500 Delay tolerance NOT_SUPPORTED SUPPORTED Downlink deterministic communication SUPPORTED Downlink deterministic periodicity 5 10 500 Uplink deterministic communication SUPPORTED Uplink deterministic periodicity 5 10 500 Downlink guaranteed throughput per UE 2100 240 – Uplink guaranteed throughput per UE 2100 240 – Downlink maximum throughput per UE 3000 600 – Uplink maximum throughput per UE 3000 600 – Downlink guaranteed throughput per slice – 2000 – Uplink guaranteed throughput per slice – 2000 – Downlink maximum throughput per slice – 6000 – Uplink maximum throughput per slice – 6000 – Terminal density 5 10 500 Maximum number of PDU sessions 15 20 – Maximum number of UEs 30 25 106 N6Protection Default rule due to the 5GAIner’s value limit set at 255. The terminal density refers to the anticipated number of active UEs transmitting per antenna at each moment. In all evaluated network slices, the N6protection is defined with the default rule, allowing unrestricted communications without throughput limitations. This evaluation primarily focuses on performance rather than restricting end device connectivity or other functionalities configurable via PCC rules. Although it was possible to define guaranteed throughput and maximum throughput in the PCC rules, the RAN’s limitation of 20 MHz spectrum constraints its maximum throughput, reaching around 160 Mbps downlink and 40 Mbps uplink-far below the UPF’s limitation, which exceeds 1 Gbps in both directions. 6.3. Performed tests The tests performed are an adaptation of the 3GPP and 5G-ACIA recommendations presented in [47,48]. The adaptations were made to better reflect the focus of our use cases, which have been shaped by different scenarios and verticals while experimenting with and deploying a variety of industrial use cases in the testbed used. The performance evaluation of each selected slice was conducted under three distinct scenarios: (1) Packet size of 1400 bytes with a periodicity of 5 ms. Objective ensure 99.9% reliability by delivering packets with less than 20 ms latency. (2) Packet size of 150 bytes with a periodicity of 10 ms. Objective ensure 99.999% reliability by delivering packets with less than 10 ms latency. (3) Packet size of 500 bytes with a periodicity of 500 ms. Objective ensure 99% reliability by delivering packets with a maximum latency of 500 ms, supporting 500 active end devices on the same antenna, and reducing UE energy consumption. Each test was conducted separately, focusing on either uplink transmission or downlink transmission. These evaluations aim to measure the end device energy consumption, latency, and packet loss of 5G communication for each slice in each scenario. Additionally, latency and packet loss are assessed while other devices utilizing the default eMBB slice are active on the network. By conducting tests in various scenarios, it becomes feasible to demonstrate how each slice’s performance aligns with the specified communication criteria. Even though the network used supports some R17 features, currently, R17 5G end devices are not commercially available. The end devices used only support R15, which impacts the performance obtained since some functionalities enabled are not supported by the UE used. This limitation restricts their performance compared to what has been configured. The following subsections describe how the tests were performed to measure each of the communication KPIs, detailing the test setup and the methods used to obtain each metric. The tests were divided into Latency and Packet Loss measurements, with UE Throughput also recorded. Energy measurements were conducted separately. 6.3.1. Latency and packet loss measurement Latency and packet loss measurements are conducted using the UE2 configuration depicted in Fig. 6. Downlink latency is measured by transmitting packets from the server through the 5G network to the UE (Huawei CPE2 pro), which then forwards the packets through an Ethernet connection to a single-board computer connected to the 5G network’s outer router, subsequently delivering the packets back to the server. Consequently, uplink latency measurements involve the opposite direction of packet transmission. Latency values are determined by calculating the time difference between the moment a packet is sent from the server and the moment it arrives back at the server. Packet Loss is assessed by counting the number of lost packets during the tests. Each test is performed by sending exactly 30000 packets. 6.3.2. Throughput measurement To measure throughput, it is used the 5G network traces that provide individual throughput measurements for each end device. The results were taken during the Latency and Packet Loss measurements. Computer Communications 229 (2025) 107991 9 A. Perdigão et al. Table 11 UE mapping network configurations. Network configuration standard name Configuration impact IMSI Contains the International mobile subscriber identity (IMSI) of the end device. IP version 4 Define UE static IPv4. IP version 6 Define UE static IPv6. AMBR Define the maximum uplink/downlink throughput that UE can simultaneously send/receive across all slices. SNSSAI Slice SNSSAI (Single Network Slice Selection Assistance Information). DNN Slice DNN (Data Network Name). MPS (Multimedia Priority Service) Specifies the provision of MPS (Multimedia Priority Services). MCS (Mission Critical Service) Specifies the provision of MCS (Mission Critical Services). High latency communication Specifies the provision of High Latency Communication services. MICO Determines whether MICO (Mobile Initiated Connection Only) is enabled. Enable PDCP Duplication Service Typpe = URLLC Calculate Transmission IBLER based on slice.Reliability if slice.reliability higher than 99.9%: PDCCH BLER = Transmission IBLER Packet Delay Budget = minimum of slice.UL Latency and slice.DL Latency UL Discard Timer = slice.UL Latency DL Discard Timer = slice.DL Latency if slice.Delay Tolerance is supported: DRX long_cycle = 5 * slice.DL Latency DRX short_cycle = slice.DL Latency DRX short_timer = 5 Inactive Timer = slice.DL Latency * 100 // 1000 + 1 reordering Timer = maximum value Discard Timer = None RLC Reassembly Timer = maximum value Scheduling Option = Scheduling Request Scheduling Request Period = Maximum value Transmission Mode = Acknowledge Mode else if slice.DL Latency higher than 30: DRX long_cycle = slice.DL Latency MAC Scheduling Priority = 10 * slice.Priority Label Logical Channel Prioritization Restrictions = 1 + ( 106 - slice.Priority Label ) * 15 // 100 Priority Level = 1+ ( 100 - slice.Priority Label ) * 126 // 100 Calculate the Slice resource allocation percentage based on available antenna resources and slice resources requested DL Guaranteed Bit Rate = slice.DL Guaranteed Throughput per UE UL Guaranteed Bit Rate = slice.UL Guaranteed Throughput per UE A.5. CN pseudocode Listing 2gives an overview of how CN mapping is performed in the PoC. Listing 2: CN mapping ARP priority = 1+(107-slice.Priority Label)*14//100 User Priority = 65534-640*Priority Label Mission Critical Service = True if slice.Priority Label equals 100 PDU Type = slice.PDUType[0] Allowed PDU Type = slice.PDUType[1:] SSC Mode = SSC_Mode_1 if slice.UEmobilityLevel is not stationary if slice.reliability lower than 99 and UE requires guaranteed throughput: Allowed SSC Mode = SSC_Mode_3 else if slice.reliability lower than 99: Allowed SSC Mode = SSC_Mode_2 else: Allowed SSC Mode = SSC_Mode_3 else: Allowed SSC Mode = SSC_Mode_2 UL slice AMBR = slice.UL maximum Throughput per UE DL slice.AMBR = slice.DL maximum Throughput per UE Enable high-latency communication and MICO if slice.Delay tolerance is Supported A.6. Experimental results This section presents the results obtained in the performance evaluation of each slice in the three different scenarios. The results obtained in each scenario are presented next. A.6.1. Scenario 1 This scenario evaluates the performance of each slice when a UE sends a packet of 1400 bytes every 5 ms. The throughput and packet loss obtained by each slice are presented in Table 12. As expected, the URLLC slice, with its limitation in throughput per UE, restricts the throughput to around 600 kbps, making it unsuitable to support this scenario. The other two slices, as seen in terms of throughput and packet loss, show minimal difference in their ability to support the scenario on these KPIs. The communication latency and end device energy consumption in this scenario are depicted in Fig. 9. As expected, the URLLC slice cannot ensure latency due to congestion and packet drops. The mMTC slice shows lower energy consumption in uplink communications but fails to ensure packet latency for 99.9% of the packets. Meanwhile, the eMBB slice only fails to ensure the 20 ms latency for 99.9% of the packets in uplink communication with other UEs creating noise in the antenna, but it achieves a percentage close to the desired. The higher energy consumption in the eMBB slice is caused by the increased control information exchanged with the network, resulting in higher uplink MAC layer throughput, as shown in Table 12. A.6.2. Scenario 2 This scenario evaluates the performance of each slice when a UE sends a packet with 150 bytes every 10 ms. From Table 13, it can be observed that all slices exhibit similar throughput in terms of the RLC layer and the downlink of the MAC layer. However, each slice demonstrates a significantly different throughput in terms of uplink in the MAC layer. This discrepancy is caused by the uplink configured grants for communication in the eMBB and URLLC slices. The eMBB slice is expected to handle 1400-byte packets every 5 ms, resulting in close to 2 Mbps in MAC layer uplink throughput, similar to the Computer Communications 229 (2025) 107991 16 A. Perdigão et al. Table 12 Scenario 1 throughput and packet loss results with different slices. Network slice RLC throughput (kbps) MAC throughput (kbps) Packet loss (%) Downlink Uplink Downlink Uplink Without noise With noise Downlink Uplink Downlink Uplink eMBB 2196.621 ±4.734 2194.822 ±11.339 2733.859 ±80.043 3369.067 ±701.887 0.003 0 0 0.13 URLLC 617.017 ±33.406 600.310 ±5.620 773.203 ±49.579 605.453 ±73.645 71.89 72.59 71.88 72.59 mMTC 2195.339 ±5.346 2195.410 ±8.158 2860.915 ±64.081 2325.176 ±376.783 0.170 0 0 0 Fig. 9. Scenario 1 results with the different slices. Table 13 Scenario 2 throughput and packet loss results with different slices. Network slice RLC throughput (kbps) MAC throughput (kbps) Packet loss (%) Downlink Uplink Downlink Uplink Without noise With noise Downlink Uplink Downlink Uplink eMBB 141.576 ±0.605 141.774 ±0.814 224.028 ±3.657 2233.840 ±191.836 0 0 0 0 URLLC 141.610 ±0.582 141.898 ±0.758 223.825 ±2.733 943.134 ±27.133 0 0 0 0 mMTC 141.572 ±0.608 141.782 ±0.737 228.202 ±2.843 482.320 ±166.273 0 0 0 0 throughput observed in scenario 1. Conversely, URLLC requires more than twice the uplink throughput for low latency with higher reliability, leading to much higher throughput in the uplink of the MAC layer. In Fig. 10, the latency and UE energy consumption obtained in this scenario are presented. In the downlink, all slices exhibit similar latency performance, with URLLC showing the best performance in terms of downlink latency and energy consumption. In the uplink communication, the URLLC slice also has the best performance. The performance of the mMTC slice aligns with expectations, as it is not tailored for this scenario. However, URLLC performs worse than required, attributed to the UE’s having R15 software, which does not support URLLC configurations introduced in R16 onwards, essential for this scenario. A.6.3. Scenario 3 This scenario evaluates the performance of slices when UE sends a packet with 500 bytes each 500 ms. Table 14 presents throughput and reliability. As expected, in this scenario there is no packet drop, and the eMBB slice exhibits higher MAC layer throughput. In the results presented in Fig. 11, there is a noticeable difference, with the mMTC slice exhibiting much higher latency compared to the other slices. However, since latency is not critical in this scenario, the results are acceptable. The increase in latency is attributed to features aimed at reducing energy consumption and increasing connection density. As observed, the mMTC slice consumes less energy most of the time compared to the other slices. It is worth noting that some packets in the downlink arrived after the 500 ms mark, partly due to the supported delay tolerance. In this case, the network slice manager was configured to provide less strict configurations in an attempt to reduce energy consumption, despite the potential for some packets arriving after the required latency. Data availability Data will be made available on request. Computer Communications 229 (2025) 107991 17 A. Perdigão et al. Fig. 10. Scenario 2 results with different slices. Table 14 Scenario 3 throughput and packet loss results with different slices. Network slice RLC throughput (kbps) MAC throughput (kbps) Packet loss (%) Downlink Uplink Downlink Uplink Without noise With noise Downlink Uplink Downlink Uplink eMBB 8.484 ±0.224 8.684 ±0.570 10.856 ±1.103 438.935 ±84.118 0 0 0 0 URLLC 8.484 ±0.224 8.688 ±0.506 11.007 ±1.064 291.151 ±56.701 0 0 0 0 mMTC 8.484 ±1.720 8.692 ±1.302 11.194 ±2.506 317.979 ±37.896 0 0 0 0 Fig. 11. Scenario 3 results with different slices. Computer Communications 229 (2025) 107991 18 A. Perdigão et al. References [1] 5G-ACIA, Integration of 5G with Time-Sensitive Networking for Industrial Communications, Tech. Rep., 2021. [2] 5G-ACIA, 5G Non-Public Networks for Industrial Scenarios, Tech. Rep., 2019. [3] 5G-ACIA, Industrial 5G Edge Computing – Use Cases, Architecture and Deployment, Tech. Rep., 2023. [4] 5G-ACIA, Using 5G Sidelink in Industrial Factory Applications, Tech. Rep., 2023. [5] Karim Boutiba, Adlen Ksentini, Bouziane Brik, Yacine Challal, Amar Balla, NRflex: Enforcing network slicing in 5G new radio, Comput. Commun. 181 (2022) 284–292. [6] Saibharath S., Sudeepta Mishra, Chittaranjan Hota, Joint QoS and energyefficient resource allocation and scheduling in 5G network slicing, Comput. Commun. 202 (2023) 110–123. [7] Adian Rasmi Alkhafaji, Firas Sabah Salih Al-Turaihi, Traffic-aware QoS guaranteed SDN/NFV-5G network with multi-layer network slicing and resource allocation, in: 2022 8th International Conference on Contemporary Information Technology and Mathematics, ICCITM, 2022, pp. 273–277. [8] Adian R. Alkhafaji, Firas S. Al-Turaihi, Multi-layer network slicing and resource allocation scheme for traffic-aware QoS ensured SDN/NFV-5G network, in: 2021 1st Babylon International Conference on Information Technology and Science, BICITS, 2021, pp. 327–331. [9] Mark Roddy, Thuy Truong, Paul Walsh, Mustafa Al Bado, Yanxin Wu, Michael Healy, Sean Ahearne, 5G network slicing for mission-critical use cases, in: 2019 IEEE 2nd 5G World Forum, 5GWF, 2019, pp. 409–414. [10] Min Xie, Andres J. Gonzalez, Pål Grønsund, Håkon Lønsethagen, Patrick Waldemar, Christos Tranoris, Spyros Denazis, Ahmed Elmokashfi, Practically deploying multiple vertical services into 5G networks with network slicing, IEEE Netw. 36 (1) (2022) 32–39. [11] André Perdigão, José Quevedo, Rui L. Aguiar, Is release 15 ready for the industry? IEEE Access (2024) 1. [12] André Perdigão, José Quevedo, Rui L. Aguiar, 5G slicing under the hood: An in-depth analysis of 5G RAN features and configurations, submitted for publication. [13] André Perdigão, José Quevedo, Daniel Corujo, Rui L. Aguiar, Massively Flexible Mobile Systems, submitted for publication. [14] André Perdigão, José Quevedo, Rui L. Aguiar, Toward the realization of vertical slices: Mapping 5G features to industrial requirements, IEEE Access 12 (2024) 77687–77706. [15] José Quevedo, André Perdigão, David Santos, Rui Silva, Rui L. Aguiar, 5Gainer: Taking the verticals into the 5G road, in: 2023 Joint European Conference on Networks and Communications & 6G Summit (EuCNC/6G Summit), 2023, pp. 514–519. [16] 5G-ACIA, Key 5G Use Cases and Requirements, Tech. Rep., 2020. [17] 5G-DNA, 5G Network Slicing Business Opportunities for Multimedia, Tech. Rep., 2019. [18] Mona Ghassemian, Paul Muschamp, Dan Warren, Experience building a 5G testbed platform, in: 2020 IEEE 3rd 5G World Forum, 5GWF, 2020, pp. 473–478. [19] Ying Wang, Adam Gorski, Aloizio Pereira da Silva, Development of a datadriven mobile 5G testbed: Platform for experimental research, in: 2021 IEEE International Mediterranean Conference on Communications and Networking (MeditCom), 2021, pp. 324–329. [20] Ying Rao Wei, Anil S Keshavamurthy, Ralph Wittmann, Antonio R. Zahonero, A standalone 5G industrial testbed design considerations for industry 4.0, in: 2022 52nd European Microwave Conference, EuMC, 2022, pp. 884–887. [21] Aleksei Fjodorov, Ali Masood, Muhammad Mahtab Alam, Sven Pärand, 5G testbed implementation and measurement campaign for ground and aerial coverage, in: 2022 18th Biennial Baltic Electronics Conference, BEC, 2022, pp. 1–6. [22] Hisham A. Kholidy, Andrew Karam, Jeffrey H. Reed, Yusuf Elazzazi, An experimental 5G testbed for secure network slicing evaluation, in: 2022 IEEE Future Networks World Forum, FNWF, 2022, pp. 131–138. [23] Bruno Chatras, U. Steve Tsang Kwong, Nicolas Bihannic, NFV enabling network slicing for 5G, in: 2017 20th Conference on Innovations in Clouds, Internet and Networks, ICIN, 2017, pp. 219–225. [24] Khizar Abbas, Talha Ahmed Khan, Muhammad Afaq, Wang-Cheol Song, Network slice lifecycle management for 5G mobile networks: An intent-based networking approach, IEEE Access 9 (2021) 80128–80146. [25] Antonio Oliveira-Jr, Kleber Cardoso, Filipe Sousa, Waldir Moreira, A lightweight slice-based quality of service manager for IoT, IoT 1 (1) (2020) 49–75. [26] Spyridon Vassilaras, Lazaros Gkatzikis, Nikolaos Liakopoulos, Ioannis N. Stiakogiannakis, Meiyu Qi, Lei Shi, Liu Liu, Merouane Debbah, Georgios S. Paschos, The algorithmic aspects of network slicing, IEEE Commun. Mag. 55 (8) (2017) 112–119. [27] Taihui Li, Xiaorong Zhu, Xu Liu, An end-to-end network slicing algorithm based on deep Q-learning for 5g network, IEEE Access 8 (2020) 122229–122240. [28] Phuong Luu Vo, Minh N.H. Nguyen, Tuan Anh Le, Nguyen H. Tran, Slicing the edge: Resource allocation for RAN network slicing, IEEE Wirel. Commun. Lett. 7 (6) (2018) 970–973. [29] Anupam Kumar Bairagi, Md. Shirajum Munir, Madyan Alsenwi, Nguyen H. Tran, Sultan S. Alshamrani, Mehedi Masud, Zhu Han, Choong Seon Hong, Coexistence mechanism between eMBB and uRLLC in 5G wireless networks, IEEE Trans. Commun. 69 (3) (2021) 1736–1749. [30] Yaping Cui, Xisheng Yang, Peng He, Ruyan Wang, Dapeng Wu, URLLC-eMBB hierarchical network slicing for internet of vehicles: An aoi-sensitive approach, Veh. Commun. 43 (2023) 100648. [31] Wanxian Liu, Xiuli He, Hongbo Xu, Ze Wang, Aizhi Zhou, Online deep learning based energy efficient optimization for IRS-assisted eMBB and URLLC services, Phys. Commun. 61 (2023) 102193. [32] Nazih Salhab, Rami Langar, Rana Rahim, 5G network slices resource orchestration using machine learning techniques, Comput. Netw. 188 (2021) 107829. [33] Francesco Tusa, Stuart Clayman, End-to-end slices to orchestrate resources and services in the cloud-to-edge continuum, Future Gener. Comput. Syst. 141 (2023) 473–488. [34] Sai Zou, Junrui Wu, Haisheng Yu, Wenyong Wang, Lisheng Huang, Wei Ni, Yan Liu, Efficiency-optimized 6G: A virtual network resource orchestration strategy by enhanced particle swarm optimization, Digit. Commun. Netw. (2023). [35] 3GPP, Aspects; management and orchestration; concepts, use cases and requirements; 28.530 version 17.4.0, 2023. [36] 3GPP, Management and orchestration; 5G network resource model (NRM); 28.540 version 17.3.0, 2022. [37] 3GPP, Policy and charging control framework for the 5G system (5GS); 23.503 version 17.11.0, 2024. [38] Flávio Meneses, Manuel Fernandes, Daniel Corujo, Rui L. Aguiar, Slimano: An expandable framework for the management and orchestration of end-to-end network slices, in: 2019 IEEE 8th International Conference on Cloud Networking (CloudNet), 2019, pp. 1–6. [39] Xi Li, Thomas Deiss, Josep Mangues-Bafalluy, Jorge Baranda, Xavier Costa-Perez, Giada Landi, Carlos J. Bernardos, Paola Iovanna, Arturo Zurita, Philippe Bertin, Automating vertical services deployments over the 5GT platform, IEEE Commun. Mag. 58 (7) (2020) 44–50. [40] 3GPP, Management and orchestration; provisioning; 28.531 version 18.3.0, 2023. [41] 3GPP, Study on network slice management capability exposure; 28.824 version 18.0.1, 2023. [42] 3GPP, Management and orchestration; 5G network resource model (NRM); 28.541 version 18.4.1, 2023. [43] Xuesong Geng, Jie Dong, Ran Pang, Liuyan Han, Tomonobu Niwa, Jaehwan Jin, Chang Liu, Nikesh Nageshar, 5G end-to-end network slice mapping from the view of transport network, 2020. [44] Kibeom Park, Sangmo Sung, Hokeun Kim, Jae il Jung, Technology trends and challenges in SDN and service assurance for end-to-end network slicing, Comput. Netw. 234 (2023) 109908. [45] André Perdigão, David Santos, João Fonseca, Rui Silva, Marco Correia, Fatma Marzouk, Paulo Soeiro, Daniel Corujo, José Quevedo, Rui L. Aguiar, ULTRAFAB5g: Unleashing the potential of 5G for industrial digitalization, in: 2024 Joint European Conference on Networks and Communications & 6G Summit, EuCNC/6G Summit, 2024. [46] Rafael Direito, Dário Matos, Daniel Gomes, Diogo Gomes, Rui Aguiar, A monitoring system to measure the impact of a network application in a 5G network, in: 2023 IEEE Conference on Network Function Virtualization and Software Defined Networks, NFV-SDN, 2023, pp. 72–78. [47] 3GPP, Management and orchestration; 5G performance measurements; 28.552 version 18.7.0, 2024. [48] 5G-ACIA, Performance testing of 5G systems for industrial automation, 2021, White Paper. Computer Communications 229 (2025) 107991 19