Network slicing is one of the defining capabilities of 5G — the ability to carve a single physical radio and core network infrastructure into multiple independent logical networks, each with its own performance characteristics. For organizations deploying private 5G networks, getting slicing right before going live is not optional. Slice negotiation failures, misconfigured quality-of-service (QoS) mappings, or unexpected device behaviour under multiple simultaneous slices can undermine the entire deployment. 5G network slicing testing in a controlled lab environment is how those problems get caught early.
This article walks through what network slicing is, how it is structured at the standards level, what device-side and configuration-level test scenarios matter most, and how the Pico5G Series supports that testing workflow.
What Is 5G Network Slicing?
Network slicing allows a single shared physical infrastructure — radio access network (RAN), transport, and core — to support multiple virtualized, logically independent networks simultaneously. Each slice can be configured with distinct QoS parameters, security policies, and resource priorities, making it possible to serve fundamentally different use cases over the same hardware.
Network slicing was standardized in 3GPP (3rd Generation Partnership Project) Release 15, the first full 5G specification. Release 16 extended the framework by introducing NSSAA (Network Slice-Specific Authentication and Authorization), which gives enterprises more granular control over which devices and subscriptions are permitted on a given slice — an important consideration for private network operators managing mixed device populations.
A practical example: a private 5G factory network might simultaneously run a URLLC (Ultra-Reliable Low-Latency Communication) slice for robotic control arms, an eMBB (enhanced Mobile Broadband) slice for high-definition video surveillance cameras, and an mMTC (massive Machine-Type Communication) slice for low-power environmental sensors — all sharing the same physical base station and core. Each slice behaves as if it has its own dedicated network.
How Slices Are Identified: S-NSSAI, SST, and SD
Every network slice is identified by an S-NSSAI (Single Network Slice Selection Assistance Information), a standardized identifier composed of two fields:
- SST (Slice/Service Type): An 8-bit value indicating the intended service category. The 3GPP-standardized values are: 1 = eMBB, 2 = URLLC, 3 = mMTC.
- SD (Slice Differentiator): An optional 24-bit value used to distinguish between multiple slices of the same SST — for example, two eMBB slices operated by different departments within the same enterprise.
When a UE (user equipment — i.e., the device under test) registers on the network, it requests specific slices via the NSSAI in its registration request. The AMF (Access and Mobility Management Function) in the 5G core evaluates the request and returns an allowed NSSAI. This negotiation process — slice selection, authorization, and PDU (Protocol Data Unit) session establishment per slice — is one of the first things that must be verified in a lab before production deployment.
Configuring Network Slicing in Pico5G
The Pico5G Series runs on the Amarisoft software stack, which supports network slicing at the bearer and core network level via QoS mapping. Configuration requires alignment between two layers:
- gNB (next-generation Node B — the 5G base station): The `nssai` parameter under `plmn_list` defines which slices the RAN will advertise and support.
- Core network (AMF/MME config): The `nssai` block in the core configuration defines slice authorization and PDU session handling.
Both layers must reference the same S-NSSAI values. A mismatch between the gNB and core configuration is a common source of slice negotiation failures — and exactly the type of issue lab testing is designed to surface before field deployment.
Multiple slices can be configured simultaneously. For example, a configuration with SST:1/SD:1 (eMBB), SST:2 (URLLC), and SST:3/SD:50 (mMTC) running concurrently allows engineers to test multi-slice device behaviour in a single session.
QoS Mapping Per Slice
One of the more technically precise aspects of slicing configuration is QoS (Quality of Service) flow mapping. In 5G, QoS flows are identified by 5QI (5G QoS Identifier) values, each carrying defined priority, packet delay budget, and packet error rate characteristics.
In the Pico5G / Amarisoft stack, slices map to specific 5QI values. As a concrete example: SST:1/SD:1 can be mapped to 5QI 6 (priority 9), while SST:3/SD:50 maps to 5QI 7 (priority 8). This means a PDU session established over one slice will be handled with materially different scheduling priority than one established over another slice — even though both traverse the same physical RAN hardware.
It is important to note a technical boundary in the current implementation: PHY/MAC (physical layer / medium access control) level slicing is not supported. It is not possible to assign dedicated PHY/MAC radio resources to individual slices. Slicing operates at the bearer and core network level. This is a relevant constraint to document when testing devices that may assume stricter radio-layer isolation between slices.
For a detailed walkthrough of network slicing configuration on the Amarisoft stack, the Amarisoft Tech Academy provides a step-by-step tutorial.
Key Test Scenarios for 5G Network Slicing Testing
When validating a device or a private network deployment, the following test scenarios cover the core slice-related behaviours:
- Basic slice negotiation (default settings): Verify that the UE can register and receive an allowed NSSAI from the AMF using default slice configuration. Confirms baseline signalling works before adding complexity.
- Single-slice registration: Register the UE on one specific slice (e.g., SST:1) and establish a PDU session. Validates that slice selection, session establishment, and QoS enforcement function correctly end to end.
- Multiple simultaneous slices: Register the UE on two or more slices concurrently (e.g., SST:1/SD:1 and SST:3/SD:50). Confirms the device handles multiple NSSAI entries correctly and that QoS differentiation between slices is applied as configured.
- URSP (UE Route Selection Policy) enforcement: URSP rules define which slice a UE should use for specific application traffic. Testing verifies that the UE correctly applies URSP rules to route traffic to the intended slice rather than a default bearer.
- RAN-level slice resource allocation: Validate how the gNB handles competing traffic across slices under load — confirming that priority differentiation via 5QI mapping behaves as expected within the bearer-level implementation boundary.
Why Test in a Lab Before Deploying?
A private 5G deployment is not a configuration that gets corrected easily after go-live. Slice negotiation failures that appear only under specific device firmware versions, URSP mismatches that route critical control traffic over a best-effort bearer, or QoS misconfiguration that collapses latency guarantees for URLLC traffic — these are the categories of defect that structured lab testing is designed to catch.
The Pico5G Series is built for this workflow: preconfigured test profiles, a web-based interface, and the ability to replicate realistic network conditions in a controlled environment. The platform supports 3GPP Releases 17 through 19 and is compatible with commercial UEs as well as devices under development — making it usable at both early device validation stages and pre-deployment network testing.
Conclusion
5G network slicing is a mature, standardized capability, but its correct operation depends on precise alignment across the gNB, core network, and device layers. Lab validation of slice negotiation, QoS mapping, URSP enforcement, and multi-slice behaviour is a practical prerequisite for any private 5G deployment that relies on slice-based traffic isolation.
The Pico5G Series supports that testing workflow at the bearer and core network level, with configurable S-NSSAI, 5QI mapping, and multi-slice concurrency — within the documented constraints of the Amarisoft implementation.
To learn more about the Pico5G Series and its network slicing test capabilities, visit nutaq.com/pico5g-series/. To discuss your specific test requirements, contact the Nutaq team.
________________________________________________________________________________________________________________
Frequently Asked Questions
Q: What is 5G network slicing and why does it require dedicated testing?
Network slicing is a 5G capability that allows a single physical network infrastructure — radio, transport, and core — to be partitioned into multiple independent logical networks, each with distinct QoS parameters and service characteristics. Testing is required because correct slice operation depends on precise alignment between the RAN configuration, core network authorization policies, and device-side behaviour. Failures in slice negotiation, QoS mapping, or URSP enforcement may not be apparent until specific device types, firmware versions, or traffic conditions are exercised — conditions that structured lab testing is designed to reproduce and verify.
Q: What is an S-NSSAI and how is it used to identify a network slice?
S-NSSAI (Single Network Slice Selection Assistance Information) is the standardized identifier for a network slice. It consists of two fields: SST (Slice/Service Type), an 8-bit value indicating the service category (1 = eMBB, 2 = URLLC, 3 = mMTC), and an optional SD (Slice Differentiator), a 24-bit value used to distinguish between multiple slices of the same type. When a device registers on the network, it includes its requested NSSAI in the registration message; the core network responds with an allowed NSSAI based on subscription and policy.
Q: Does the Pico5G Series support PHY/MAC level slicing with dedicated radio resources per slice?
No. The Pico5G Series runs on the Amarisoft software stack, which implements network slicing at the bearer and core network level via QoS mapping. It is not possible to assign dedicated PHY/MAC (physical layer / medium access control) radio resources to individual slices in the current implementation. This is a known architectural boundary, not a configuration limitation. For most device validation and private network pre-deployment testing scenarios, bearer and core-level slicing coverage is sufficient to verify the device-side and network-side behaviours that matter most.
Q: How are QoS flows mapped to network slices in Pico5G?
QoS (Quality of Service) flows in 5G are identified by 5QI (5G QoS Identifier) values, each with defined priority, packet delay budget, and packet error rate parameters. In the Pico5G / Amarisoft configuration, each slice (identified by its S-NSSAI) is associated with a specific 5QI. For example, SST:1/SD:1 (eMBB) can be mapped to 5QI 6 with priority 9, while SST:3/SD:50 (mMTC) maps to 5QI 7 with priority 8. This means traffic on different slices is handled with different scheduling priorities, even over the same physical RAN.
Q: What 3GPP releases are relevant for network slicing, and which does the Pico5G support?
Network slicing was first standardized in 3GPP Release 15. Release 16 added NSSAA (Network Slice-Specific Authentication and Authorization), extending enterprise control over device and subscription access per slice. The Pico5G Series supports 3GPP Releases 17 through 19, covering current and near-future slicing specifications. This range is relevant for teams validating devices against the latest standards or conducting pre-deployment testing for private networks intended to align with current operator and enterprise requirements.
