Network Slicing Explained Interview Prep

Frequently asked questions

What is a 5G network slice?

A network slice is a logical, end-to-end network instance that runs over shared physical infrastructure and is tailored to a specific service profile. Each slice spans the RAN, the 5G Core (its own dedicated or shared AMF/SMF/UPF set), and ideally the transport network in between, so that one operator can run, for example, a high-throughput consumer broadband slice, a low-latency industrial-automation slice, and a massive-IoT slice on the same gNBs at the same time. A slice is identified by an S-NSSAI (Single Network Slice Selection Assistance Information). The slicing framework is defined in 3GPP TS 23.501 (architecture), TS 23.502 (procedures), and TS 28.530/28.531/28.533 (management). The interview-relevant point is that slicing is an architectural construct with its own end-to-end selection, isolation, and lifecycle-management machinery spanning the RAN, Core, and transport.

What is an S-NSSAI, and what are SST and SD?

S-NSSAI (Single Network Slice Selection Assistance Information) is the identifier of a single slice. It has two parts: SST (Slice/Service Type), a mandatory 8-bit value describing the expected slice behaviour, and SD (Slice Differentiator), an optional 24-bit value that distinguishes multiple slices of the same SST (e.g., two URLLC slices for two different enterprise tenants). 3GPP reserves the SST range 1–127 for standardized values (currently only SST 1–5 are defined) so they mean the same thing across operators and roaming partners; values 128–255 are operator-specific. The defined standardized SST values are SST=1 (eMBB), SST=2 (URLLC), SST=3 (MIoT / massive IoT), SST=4 (V2X), and SST=5 (HMTC, high-performance machine-type communications). An NSSAI is a set of S-NSSAIs; the Requested and Allowed NSSAI carry at most eight S-NSSAIs each per registration.

What is the difference between Requested, Allowed, Configured, and Subscribed NSSAI?

These four NSSAI flavours appear in the slice-selection flow and candidates routinely confuse them. Configured NSSAI is provisioned to the UE per PLMN (a default Configured NSSAI may also apply); the UE derives its Requested NSSAI from it. Requested NSSAI is what the UE sends to the network in the Registration Request to ask for slices. Subscribed S-NSSAIs come from the UE subscription in the UDM and bound what the user is entitled to. Allowed NSSAI is what the network returns in the Registration Accept — the slices the UE may actually use in the current registration area, after the AMF reconciles the Requested NSSAI against the subscription and serving-PLMN policy (with help from the NSSF). Slices the network refuses appear as Rejected S-NSSAIs with a cause.

What is the NSSF and when is it invoked?

The NSSF (Network Slice Selection Function) is the 5G Core control-plane function that assists the AMF in slice selection. The AMF queries the NSSF (via the Nnssf_NSSelection service) when it cannot resolve slice selection locally — typically during UE registration, during PDU session establishment, and on UE configuration updates. The NSSF returns the Allowed NSSAI for the registration area, can return a Configured NSSAI for the serving PLMN, and can indicate the target AMF set or candidate AMFs when the initially-selected AMF cannot serve all the requested slices (AMF re-selection / re-routing). It also maps requested S-NSSAIs to the network-internal slice instances. In smaller deployments the AMF may handle slice selection without a separate NSSF, but the standardized division of labour puts cross-AMF and cross-slice resolution in the NSSF.

How does slice selection work during registration versus PDU session establishment?

They are two distinct decision points. At registration, the UE sends a Requested NSSAI; the AMF checks it against the Subscribed S-NSSAIs (from the UDM) and serving-PLMN policy, consults the NSSF if needed, and returns an Allowed NSSAI (and any Rejected S-NSSAIs) in the Registration Accept. Registration establishes which slices the UE may use, not the user-plane path. At PDU session establishment, the UE requests a session for one specific S-NSSAI (which must be in the Allowed NSSAI) plus a DNN (Data Network Name); the AMF then selects an SMF, and the SMF selects a UPF, that serve that slice. So registration grants slice eligibility; PDU session establishment actually instantiates a user-plane path inside a chosen slice. A single UE can have simultaneous PDU sessions on different slices.

How is slicing realized in the RAN, Core, and transport — and how is isolation achieved?

Slicing is end-to-end, so it has to be realized in three segments. In the Core, slices map to dedicated or shared network-function instances (AMF can be shared across slices; SMF/UPF are commonly slice-specific) selected via S-NSSAI. In the RAN, the gNB is made slice-aware: it enforces per-slice radio-resource policies — RRM partitioning, prioritization, and admission control per S-NSSAI — which can range from soft (shared resources with per-slice quotas and scheduler weights) to hard (reserved PRBs). In the transport network, slice traffic is separated using techniques such as VLANs, VPNs, segment routing, or FlexE. Isolation is the property that one slice cannot consume another slice's committed resources or observe its traffic; it ranges from logical/soft isolation (statistical separation, quotas) to physical/hard isolation (dedicated hardware), traded off against multiplexing efficiency. SLA enforcement is what makes isolation meaningful in production.

How is the lifecycle of a network slice managed?

Slice management is specified in the 3GPP TS 28.5xx series (notably TS 28.530 for concepts and use cases, and TS 28.533 for the management architecture). It defines three management functions: the CSMF (Communication Service Management Function) translates a customer communication-service requirement into network-slice requirements; the NSMF (Network Slice Management Function) handles management and orchestration of the end-to-end Network Slice Instance (NSI); and the NSSMF (Network Slice Subnet Management Function) manages a Network Slice Subnet Instance (NSSI), e.g., a RAN subnet, a Core subnet, or a transport subnet. TS 28.530 frames the NSI lifecycle in phases — preparation, commissioning (creation), operation (activation, supervision, modification), and decommissioning. This management/orchestration layer is what distinguishes a deployed, SLA-backed slice from a static configuration.

How does network slicing differ from QoS flows and 5QI?

They operate at different granularities and a strong candidate keeps them separate. A slice (S-NSSAI) is a logical end-to-end network instance with its own selected network functions and isolation; QoS flows operate inside a slice. Within a UE's PDU session on a given slice, traffic is split into QoS flows, each tied to a 5QI that specifies resource type (GBR vs non-GBR), priority, packet delay budget, and packet error rate (see /topics/5g-qos-and-5qi). So slicing answers "which logical network and resource partition serves this service," while 5QI/QoS flows answer "how is each traffic class scheduled within it." A URLLC slice and a URLLC 5QI are related in intent but are different mechanisms — you can have multiple 5QIs inside one slice, and you can run the same 5QI across different slices.

Related topics