5G Network Slicing: S-NSSAI, Slice Selection, and What Actually Gets Reserved

Network slicing is the 5G feature most likely to be oversold in a slide deck and misunderstood in a design review. The pitch — multiple logical networks on shared infrastructure, each with its own performance profile — is accurate. What's usually missing is that selecting a slice and reserving resources for it are two entirely different mechanisms, and only one of them is specified in the slice selection procedure.

Let's build it properly from the identifier upward.

---

Slice vs slice instance

Two terms that get used interchangeably and shouldn't be:

A Network Slice is the logical concept — a defined set of characteristics and capabilities.

A Network Slice Instance (NSI) is a deployed set of network function instances and resources that realises it.

The relationship isn't one-to-one in either direction. One S-NSSAI can map to multiple NSIs — for example, the same slice type deployed regionally. One NSI can serve multiple S-NSSAIs where the operator chooses to share the deployment.

---

S-NSSAI: the slice identifier

S-NSSAI — Single Network Slice Selection Assistance Information — is the identifier everything else hangs off.

Two fields:

SST (Slice/Service Type) is 8 bits and describes expected behaviour. 3GPP standardises the low values so they mean the same thing across operators and roaming partners:

Above the standardised range, operators define their own values — but those only have meaning inside that operator's network.

SD (Slice Differentiator) is optional and 24 bits when present. It exists because SST alone can't distinguish two slices of the same type.

An operator running three eMBB offerings — consumer, enterprise, premium — can't tell them apart with SST=1 alone. Adding SD gives each a distinct identity:

So an S-NSSAI is either SST alone (a standardised type, no further differentiation) or SST plus SD (a specific operator slice).

---

NSSAI and its three forms

An NSSAI is simply a set of S-NSSAIs — up to eight in the signalled forms. What matters is that 3GPP defines several distinct NSSAIs with different meanings, and confusing them causes real debugging pain:

Configured NSSAI — provisioned into the UE for a given PLMN, either by the home operator or through prior signalling. This is what the UE knows about before it asks for anything.

Requested NSSAI — what the UE actually asks for during registration, derived from its Configured and Allowed NSSAI.

Allowed NSSAI — what the network grants, based on subscription, policy, location, and slice availability. This is authoritative.

Rejected NSSAI — slices explicitly refused, with a cause indicating whether the rejection applies across the PLMN or only in the current registration area. The distinction tells the UE whether retrying elsewhere is worthwhile.

The critical property:

Requested does not mean allowed. The network decides, and it can decide differently in a different tracking area.

---

Slice selection at registration

Slicing becomes visible during registration, before any PDU Session exists.

The sequence:

The UE sends a Registration Request carrying its Requested NSSAI.

The gNB uses it for initial AMF selection. The RAN can route to an AMF that supports the requested slices — this is why Requested NSSAI appears in RRC signalling and not only in NAS.

The initial AMF evaluates subscription data, the Requested NSSAI, local configuration, serving PLMN, and slice availability in the current area.

The AMF may query the NSSF where the decision needs network-wide slice knowledge. The NSSF determines the set of Network Slice Instances that can serve the UE, and returns candidate AMF information.

AMF relocation may occur. If the initial AMF can't serve the required slice set, the registration is redirected to one that can. This is the step people forget exists.

The Allowed NSSAI is returned to the UE in the Registration Accept, along with any Rejected NSSAI and causes.

Where the NRF comes in

Once the slice context is established and the UE requests a PDU Session, the AMF needs an SMF inside the selected slice. It discovers one through the NRF, using S-NSSAI, DNN, NSI-ID where available, and subscription data as discovery criteria.

---

Slices and PDU Sessions

A hard constraint worth committing to memory:

A PDU Session belongs to exactly one Network Slice Instance per PLMN. Slice instances never share a PDU Session.

A UE that needs both eMBB and URLLC treatment needs two PDU Sessions — potentially served by different SMFs and different UPFs. This is why slicing and session management can't be reasoned about separately.

Within a session, QoS Flows provide the finer differentiation. Slice and QoS are complementary layers, not alternatives:

The slice sets the broad context — which network functions, which resource pools, which policies. QoS Flows differentiate traffic classes inside it. A URLLC slice still carries both control and data traffic, and those still want different treatment.

---

Slicing spans three domains

The most common architectural mistake is treating slicing as a Core feature.

In the RAN, NG-RAN supports slice-aware admission control, scheduling, resource allocation, and slice-specific configuration. 3GPP is explicit that a network slice consists of a RAN part and a Core part — slicing without RAN participation isn't slicing.

In transport, slice-aware treatment typically comes from traffic engineering, segment routing, VPNs, hard or soft resource partitioning, and QoS. This is where "end-to-end" claims most often quietly fail, since transport is frequently a separate organisation with separate tooling.

In the Core, functions can be shared, dedicated, or hybrid:

The hybrid model — shared AMF, dedicated SMF and UPF per slice — is the common production choice. The AMF is naturally shared because a UE registers once regardless of how many slices it uses, while SMF and UPF separation is where isolation and performance differentiation actually come from.

---

Isolation is a spectrum, not a property

"Slices are isolated" is the claim that sells slicing, and it is true only in a carefully qualified sense. Isolation exists at several levels, and deployments choose among them by cost.

Shared everything. Slices differ only by QoS treatment and policy. The radio, transport and compute are common. This is cheap, it is what most commercial slicing actually is, and its isolation is entirely a matter of scheduler weighting. A slice under load can affect its neighbours.

Shared radio, dedicated core functions. Each slice gets its own SMF and UPF, sometimes its own AMF. Control-plane faults no longer propagate across slices, and user-plane traffic takes genuinely separate paths through the core. The radio remains shared.

Dedicated radio resources. A slice receives reserved PRBs, or a dedicated carrier. Now radio load in one slice cannot starve another — at the cost of stranding capacity when the slice is idle.

Physical separation. Separate hardware end to end. Total isolation, and the economics of a private network rather than a slice.

The important consequence is that a guarantee written against one level does not hold at another. An enterprise buying "an isolated slice" and receiving the first option has bought priority, not isolation, and the distinction shows up precisely when the network is congested — which is exactly when the guarantee was supposed to matter.

RAN slicing is the hard part

Core network slicing is largely a matter of instantiating separate network functions, which virtualisation makes straightforward. RAN slicing is harder because the radio resource is genuinely shared and physically finite.

Approaches divide into three families. Reservation dedicates a fixed share of PRBs per slice — strong isolation, poor efficiency. Prioritisation weights the scheduler per slice — efficient, weak isolation. Quota with borrowing guarantees a minimum while allowing unused capacity to be lent out — the usual compromise, and the one that requires the most careful tuning.

None of these is specified in detail by 3GPP. The standard defines how slice identity reaches the RAN; what the scheduler does with it is an implementation matter, which is why RAN slicing behaviour differs sharply between vendors.

---

The misconception that matters most

Here it is, stated plainly:

Selecting an S-NSSAI does not reserve radio resources.

Slice selection establishes context — which network functions serve this UE, which policies apply, which resource pools are relevant. Turning that context into guaranteed performance requires separate mechanisms in each domain: RAN scheduler policy and admission control, transport path engineering and reservation, Core capacity planning and UPF placement.

This is why isolation is a spectrum rather than a property. An operator can implement a slice as full physical separation with dedicated PRB partitions, or as a shared pool with priority weighting, or anything in between. Both are conformant. They deliver very different guarantees under load — and a traffic surge on the eMBB slice will tell you which one you bought.

---

Orchestration ties it together

Because a slice spans domains, instantiating one means coordinated configuration across all of them.

The orchestrator's job is translating service intent into domain-specific configuration. "Low-latency industrial slice" becomes a RAN priority and resource policy, a low-latency transport path, and an edge UPF with matching QoS rules. This is where slicing meets automation — and it's the practical reason slicing took longer to deploy than the specifications suggested.

Slice availability varies by location. A slice isn't necessarily supported everywhere in the PLMN, so a UE's Allowed NSSAI can legitimately change as it moves between tracking areas. That's expected behaviour, particularly for enterprise and industrial slices with limited geographic footprints — and it's a common source of confusion in field testing.

---

What a slice costs to run

Slicing is often presented as a way to monetise existing infrastructure. The costs are real and land in places that are easy to underestimate at design time.

Signalling. Slice selection happens at registration and again at every PDU session establishment. The NSSF is consulted, allowed NSSAI is computed and delivered, and the UE stores configured and allowed lists that must be kept coherent across registration areas. More slices means more of this, and it scales with mobility rather than traffic.

Fragmentation. Reserved capacity that a slice is not using is capacity nobody can use. Ten slices each guaranteed 5% of a cell have collectively locked half the cell whether or not any of them are active. The stronger the isolation guarantee, the worse the fragmentation.

Operational surface. Every slice is a service with its own SLA, monitoring, assurance and lifecycle. A hundred slices is a hundred things that can be individually misconfigured, and the failure modes are combinatorial rather than additive.

Device support. A UE can maintain at most eight simultaneous slices, and the network must fit its offering inside that limit alongside whatever else the device needs.

This is why commercial slicing has converged on a small number of broad slices — an eMBB slice, a low-latency slice, an IoT slice, perhaps a public-safety slice — rather than the per-customer slicing early marketing suggested. The economics favour few, well-defined slices over many bespoke ones.

---

Slicing and roaming

Roaming is where slicing gets genuinely difficult, because a slice identifier is only meaningful within the network that defined it.

Standardised SST values — 1 for eMBB, 2 for URLLC, 3 for mMTC, 4 for V2X — carry the same meaning everywhere, which is precisely why they exist. But the slice differentiator that distinguishes one operator's enterprise slice from another's is purely local, so a home-network S-NSSAI generally means nothing in a visited network.

The specification handles this with mapped S-NSSAI: the visited network operates its own slices, and a mapping translates between the two. The device holds both its home S-NSSAI and the visited equivalent.

Whether the visited network offers a comparable slice at all is a commercial question, not a technical one. A roaming agreement covering eMBB says nothing about whether the visited operator runs a URLLC slice, or whether its characteristics resemble the home one. In practice a device roaming onto a network without an equivalent slice falls back to default connectivity — which is the correct behaviour, and a poor outcome for anything that depended on the guarantee.

---

Key takeaways

S-NSSAI = SST (8-bit service type) + optional SD (24-bit differentiator)

Configured → Requested → Allowed — the UE proposes, the network disposes, per registration area

NSSF supports slice selection; NRF discovers network functions within the selected slice

One PDU Session = one slice instance. Multiple slices means multiple sessions.

Slicing spans RAN, transport, and Core. Any one of them can be your bottleneck.

Selection ≠ reservation. Isolation comes from resource management, not from the S-NSSAI.

Network slicing is genuinely powerful, but the power lives in the orchestration and resource management underneath. The identifier framework is just how the network agrees on what it's talking about.

---

Further reading

• 3GPP TS 23.501 — System architecture, network slicing concepts and S-NSSAI definition
• 3GPP TS 23.502 — Registration and slice selection procedures
• 3GPP TS 23.503 — Policy and charging framework
• 3GPP TS 38.300 — NG-RAN slicing support
• GSMA NG.116 — Generic Network Slice Template