5G Network Slicing Workbench

Explore how 5G uses S-NSSAI, policy, and resource isolation to serve different IoT traffic needs

animation
5g
network-slicing
cellular-iot
qos
architecture
Interactive 5G network slicing animation for learning eMBB, URLLC, massive IoT, S-NSSAI, SST values, slice selection, and SLA tradeoffs.
Interactive animation 5G core and RAN S-NSSAI

5G Network Slicing Workbench

Pick an IoT workload, tune its service targets, and watch how the requested slice steers traffic through shared radio, transport, edge, and 5G core resources. The goal is not to memorize labels. It is to see which target breaks first when the wrong slice is selected.

Massive IoTSelected slice intent
94%Current fit score
Density protectedPrimary lesson
Goal
Connect each slice to the IoT requirement it protects: density, latency, bandwidth, reliability, or isolation.
Try
Switch scenarios, then deliberately choose the wrong slice and inspect the failing constraint.
Watch
Use Play or Step to trace the path from requested S-NSSAI to RAN scheduling, UPF placement, policy, and app delivery.
Check
Use the comparison cards to decide whether a service needs MIoT, URLLC, eMBB, or a redesigned requirement.

Shared 5G Infrastructure, Separate Slice Intent

Smart meter city sends small readings from a dense device population. Massive IoT is the natural starting point because the dominant constraint is connection density, not bandwidth.

Running: Smart Meter City loaded
UE request
S-NSSAI
NG-RAN
scheduler
Transport
isolation
Edge UPF
placement
5GC policy
AMF/NSSF/SMF
MIoTSST 3, dense low-rate devices
Scale first900k devices/km2
URLLCSST 2, strict delay and reliability
Time first3 ms target
eMBBSST 1, high-throughput streams
Rate first650 Mbps demand
1. RequestUE includes a requested S-NSSAI when the service asks for a slice.
2. SelectAMF and NSSF steer the request to an allowed slice and network functions.
3. ScheduleRAN and transport policy protect resources according to the selected slice.
4. AnchorSMF chooses a UPF path, often near the edge for low-latency workloads.
5. MonitorPolicy and telemetry check whether the service target is being met.

Fit Diagnosis

94

Massive IoT is a strong fit because this workload has many devices, small payloads, and relaxed delay.

ProtectedDensity
RelaxedLatency
Low demandBandwidth
99.9%Reliability

S-NSSAI Inspector

SST3 - Massive IoT
SDOptional differentiator: city-metering-a
PolicyPrioritize scale, efficient control-plane handling, and small periodic payloads.
RiskIf placed on a throughput-first slice, dense attach and signalling behavior becomes the planning risk.

Slice Comparison

Slice Quick Reference
  • eMBB, SST 1: high-throughput mobile broadband or video-heavy IoT.
  • URLLC, SST 2: ultra-reliable, low-latency control where delay and availability dominate.
  • MIoT, SST 3: massive IoT, often taught as mMTC-style dense low-rate device populations.
How To Read This Animation

The colored lanes are logical service paths over shared infrastructure. A good fit means the selected slice intent has enough planning headroom for the workload. It does not mean every packet is guaranteed regardless of coverage, congestion, backhaul, device capability, or operator policy.

Technical Accuracy Notes
  • An S-NSSAI identifies a network slice and includes an SST plus an optional SD.
  • Slice selection affects allowed slices, AMF/NSSF/SMF choices, PDU session handling, RAN scheduling, and user-plane placement.
  • Isolation is modeled here as policy and resource headroom. Real deployments must still dimension radio, transport, core, and edge capacity.
Source Links