5G Network Slicing: what it is and how it works

Picture an industrial port where surveillance drones stream real-time data, high-resolution cameras monitor the docks, and hundreds of environmental sensors send small packets every few minutes. All of these devices run on the same 5G infrastructure.

How can a single network guarantee a few milliseconds of latency for the drone while, at the same moment, delivering tens of megabits per second to the camera, without one slowing down the other? The technical answer is network slicing.

Network slicing is the ability to split a single physical 5G infrastructure into multiple independent logical networks, called slices. Despite sharing a common physical infrastructure, each slice is deployed to provide specific capabilities and characteristics to meet its own service requirements.

Think of it as building dedicated lanes on a single highway: traffic in the fast lane isn't held up by traffic in the ordinary lanes, even though everyone is driving on the same asphalt. Network slicing was standardized as part of the 5G System in 3GPP Release 15, making it one of the key features that distinguishes standalone 5G (SA) from earlier generations, which lacked the mechanisms to truly isolate traffic at this level.

For a slice to successfully meet its service requirements, the required service characteristics must be maintained across three main domains: RAN, core network, and transport network.

In the RAN (Radio Access Network), radio resources are allocated among slices by frequency and time, so a low-latency device doesn't have to compete for spectrum with a high data-rate one. In the core network, network functions are virtualized using NFV (Network Functions Virtualization), while SDN (Software-Defined Networking) dynamically steers traffic and enforces policies. Together, these technologies allow each slice to operate as an independent logical network with its own authentication, routing, and quality-of-service rules. The transport network, the part that connects the antennas to the core, also has to guarantee distinct paths and priorities.

Every device that wants to use a specific network slice needs to identify it precisely. That information is carried in a field called S-NSSAI (Single Network Slice Selection Assistance Information), which consists of two parts:

• a mandatory SST (Slice/Service Type): an 8-bit value that identifies the type of service the slice is designed to support. It can refer to one of the standardized SST values defined by 3GPP, or to an operator-specific value.
• and an optional SD (Slice Differentiator): a 24-bit value used to distinguish between multiple slices that share the same SST.

Put simply: SST is like choosing a class of postal service, standard, express, registered. But what happens if two customers want the same class of service, but need different levels of service?

That's where SD comes in. If two customers need separate slices with the same SST, different SD values can be used to distinguish those slices. Both may request an eMBB slice, for example, but their S-NSSAIs can still be different because they use different SD values.

The 3GPP specification (TS 23.501, section 5.15.2.2) defines seven standardized Slice/Service Types (SST), each identified by an 8-bit numeric value that forms part of the S-NSSAI used to request a slice. These standardized values provide a common way to identify widely used slice types and support interoperability between networks, including in roaming scenarios.

The three best known are:

• eMBB (enhanced Mobile Broadband, SST 1), built for high throughput such as high-definition video;
• URLLC (Ultra-Reliable Low-Latency Communications, SST 2), for applications that can't tolerate delay, think of controlling a drone or a robotic arm;
• and MIoT (Massive IoT, SST 3), for managing a huge number of sensors that transmit small amounts of data infrequently.

These three correspond closely to the three main usage scenarios defined by ITU-R for IMT-2020: eMBB, URLLC and mMTC. That's why they appear in almost every introduction to 5G.

The standard goes further, though.

• V2X (SST 4) covers vehicle-to-everything communications.
• HMTC (High-Performance Machine-Type Communications, SST 5) targets demanding industrial IoT traffic that needs more than basic MIoT can offer.
• HDLLC (High Data rate and Low Latency Communications, SST 6), added with Release 18, addresses services such as extended reality and cloud gaming that need both bandwidth and speed at once.

The most recent addition, GBRSS (Guaranteed Bit Rate Streaming Service, SST 7), introduced in Release 19, is built for services that need continuous, guaranteed throughput, such as live broadcasting or virtual presence.

A single operator, or a single private network, can support several of these slice types side by side without building separate infrastructures for each.

Before slicing, an operator that wanted to offer different guarantees to different customers had two unappealing options: overbuild the entire network for the most demanding case, wasting resources for everyone else, or build physically separate infrastructures, with costs that climb fast.

Slicing removes that trade-off. It allows an operator to offer differentiated service levels (SLAs) on the same physical infrastructure, isolating traffic so that a spike on one slice doesn't degrade performance on the others. For whoever runs the network, this means being able to launch new services quickly, without laying new equipment every time a requirement changes. Why build three networks when you can carve three out of one?

In the world of private networks, the term slicing gets used in two different ways worth telling apart.

The first is a slice carved out of a carrier's public network: a company gets a dedicated, isolated portion of the operator's infrastructure, with guaranteed QoS, without owning any antennas or spectrum itself. It's a convenient option for anyone who needs wide coverage without infrastructure investment.

The second, more relevant for organizations building standalone private networks such as NGCI (Next-Generation Communication Infrastructure), is slicing applied internally, within the organization's own perimeter. On a factory floor, for example, an autonomous guided vehicle (AGV) system can run on a dedicated URLLC slice, while quality-control cameras sit on an eMBB slice and environmental sensors on an mMTC slice, all on the same private network. In coastal or maritime surveillance settings, the same principle separates the command traffic sent to drones, which can't tolerate delay, from the high-resolution video stream sent back in real time. In defense and other critical environments, slice isolation can also contribute to security by limiting the impact of problems or compromised traffic within one slice.

The two are often presented as alternatives, but in practice they work well together. A standalone private network already provides a dedicated network domain and direct control over its infrastructure: adding slicing on top of it means being able to handle use cases with opposite requirements at the same time, without multiplying the equipment.

That combination is what makes an infrastructure like NGCI adaptable to different scenarios, from a factory floor to a security site, without needing to be redesigned every time the application changes.

None of this argues that commercial networks are unfit for every purpose. Plenty of defense-adjacent activity doesn't require this level of control, and building standalone infrastructure everywhere would be neither practical nor necessary.

The value of a standalone private network isn't simply that it makes an organization independent from everything. It's that it lets the organization decide which dependencies it's willing to accept, and which ones it isn't, rather than having that decision determined by a commercial contract.

For organizations operating in critical environments, the real question is therefore how much control over the network is actually required and which approach, on-premises or commercial, provides it. For a deeper look at the trade-off between on-premises and commercial operator networks, and what it means for network sovereignty, see our dedicated article.