NSSF — Network Slice Selection Function in 5G NR

Introduction

The NSSF (Network Slice Selection Function) is the 5G core control-plane function that owns the logic of which network slices a UE may use and who should serve them. It is invoked during the registration procedure (TS 23.502): after the AMF has the UE's Requested NSSAI and has fetched the Subscribed S-NSSAIs from the UDM, it may call the NSSF to turn that request-plus-context into a concrete grant.

Slicing is a defining feature of 5G, and slice selection is not a decision any single AMF can always make locally: an AMF instance serves only a subset of the operator's slices, a slice may exist in some Tracking Areas and not others, and when the UE roams the visited and home networks name their slices with different identifiers. The NSSF centralises the map of slice-to-area-to-AMF so every AMF does not have to carry it.

It matters because a wrong slice decision cascades: the UE lands on an AMF that cannot serve its slices, a requested slice is silently refused, or a roaming UE cannot correlate visited and home slices. Understanding what the NSSF takes in, what it returns, and how it drives AMF re-routing is what makes registration-time slicing behaviour predictable.

Why the NSSF is needed

Concretely, three problems force slice selection out of the local AMF and into a shared authority. First, partial coverage per AMF: an AMF serves only a set of slices, so a UE that requests a slice the serving AMF cannot support has to be steered to one that can. Second, per-TA availability: a slice may be offered in some Tracking Areas and not others, so "allowed" is a function of where the UE is, not just who it is. Third, roaming translation: visited and home PLMNs use their own S-NSSAI values, so someone must produce a consistent mapping. The NSSF concentrates exactly this logic.

What the NSSF Is For

The NSSF (Network Slice Selection Function) is the 5GC control-plane function that owns network-slice selection logic. It exists because slice selection is not a purely local decision the serving AMF can always make: an AMF only serves a set of slices, slice availability varies per Tracking Area, and — when roaming — the visited and home networks name their slices differently. Centralising that logic in one function keeps every AMF from having to hold the operator's entire slice-to-area-to-AMF map.

Keep the terminology from the slicing model straight, because the NSSF speaks it fluently. A slice is identified by an S-NSSAI = SST (Slice/Service Type, 8 bits) + optional SD (Slice Differentiator, 24 bits). The SST field is one octet (values 0–255); values 1–5 are standardised for interworking (1 = eMBB, 2 = URLLC, 3 = MIoT, 4 = V2X, 5 = HMTC per TS 23.501), while the rest are operator-specific. The optional SD is three octets (24 bits) that differentiate multiple slices sharing the same SST (e.g. two enterprise eMBB tenants). A set of S-NSSAIs is an NSSAI, and an Allowed/Requested/Configured NSSAI may contain at most 8 S-NSSAIs. The UE requests slices (Requested NSSAI, built from its Configured NSSAI), the subscription entitles slices (Subscribed S-NSSAIs), and the network grants slices (Allowed NSSAI, with refusals in the Rejected NSSAI). The NSSF's job is to turn the first three, plus context, into the last two — and to say which functions should serve them.

Inputs and Outputs of Slice Selection

The cleanest way to understand the NSSF is as a pure function: a defined set of inputs in, a defined set of outputs out. The AMF gathers the inputs, calls Nnssf_NSSelection, and applies the outputs.

The Rejected NSSAI is not a single flag — each rejected S-NSSAI carries a rejection cause so the UE knows whether to retry. Two causes matter most: "S-NSSAI not available in the current PLMN" (the slice is refused network-wide, so the UE stops requesting it in this PLMN) and "S-NSSAI not available in the current registration area" (the slice exists elsewhere in the PLMN, so the UE may request it again after moving). This is the per-TA availability knowledge in action.

Note the division of labour with the AMF. The AMF always computes the Allowed NSSAI that it returns to the UE in the Registration Accept; it may do so locally when it has enough information (its own configuration covers the requested slices in this TA), and it invokes the NSSF when it does not — for example when a requested slice is unknown to it, when it cannot serve all requested slices, or when roaming requires slice mapping. So the NSSF is the authority the AMF defers to, not a mandatory hop on every registration.

NSSAI Types Recap

The NSSF manipulates several flavours of NSSAI, each set by a different node at a different moment. This recap keeps them straight — it is the same taxonomy used on the network-slicing page.

How the AMF Calls the NSSF: Nnssf_NSSelection

The NSSF is an SBA producer: it exposes its capabilities as services on the service bus, and the AMF is the consumer. The service-based interface is Nnssf, and it offers two services. The one that runs during registration is NSSelection.

During a UE registration, once the serving AMF has the Requested NSSAI from the Registration Request and the Subscribed S-NSSAIs from the UDM, it invokes Nnssf_NSSelection_Get, passing the requested slices, the subscribed slices, the TAI, the access type and (when roaming) mapping information. The NSSF evaluates slice availability for that TA, intersects request with subscription and with what the network offers, and returns the Allowed NSSAI, any Rejected NSSAI with causes, the target AMF Set (or a candidate AMF list, possibly obtained via the NRF), the mapping to home S-NSSAIs if applicable, and the NSI ID(s). The AMF then puts the Allowed NSSAI into the Registration Accept and uses the rest of the answer to steer subsequent function selection.

NSSAI Availability per Tracking Area

The NSSF can only answer availability questions if it first knows the answer. That knowledge comes from the second Nnssf service, NSSAIAvailability. Each AMF tells the NSSF which S-NSSAIs it supports in which TAs, and the NSSF maintains the network-wide picture of slice-to-TA-to-AMF support.

Concretely, an AMF uses Nnssf_NSSAIAvailability_Update to register the S-NSSAIs it can serve per TA; the NSSF may in turn use Nnssf_NSSAIAvailability_Notify to tell an AMF when the availability of a slice in a TA changes (for example when the operator restricts a slice in an area). This is what lets the NSSF, at NSSelection time, decide that a requested slice is simply not offered where the UE currently is and put it in the Rejected NSSAI with the "not available in the current registration area" cause — and it is what lets the AMF build a registration area out of TAs that consistently support the Allowed NSSAI.

Per-TA availability also connects to the RAN: a gNB advertises which slices it supports per TA/cell, and the core assigns UEs only to slices the cell can actually serve. The NSSF's TA-level view and the RAN's cell-level support have to agree for a UE to actually use a slice where it stands. If the UE moves into an area where an allowed slice is not supported, that slice can migrate into the Rejected NSSAI and its PDU sessions are released or relocated.

Driving AMF Re-routing and NRF Discovery

Choosing slices is only half the NSSF's contribution; the other half is making sure the UE ends up on an AMF that can serve those slices, and that each slice's sessions are handled by the right function instances.

AMF re-routing. The RAN selects an initial AMF for a registering UE — often a default AMF, because at that instant the gNB only has limited slice assistance information. If that initial AMF cannot serve the UE's Requested NSSAI, it calls Nnssf_NSSelection_Get, and the NSSF returns a target AMF Set (and, if needed via the NRF, a candidate list of AMF instances in that set). The registration is then redirected — either directly (the initial AMF forwards the UE context to a target AMF over the service-based interface) or via the RAN (the initial AMF returns a Reroute NAS message and the gNB re-sends the initial NAS message to an AMF in the target set). Only after this does the UE settle on an AMF supporting its Allowed NSSAI.

Relation to the NRF. The NSSF decides which slice and which NSI; the NRF finds the function instances that belong to it. Once slices are settled, the AMF and SMF discover slice-correct peers — an SMF for a given S-NSSAI, then a UPF — by querying the NRF with the S-NSSAI (and, when applicable, the NSI ID) as discovery parameters. In some deployments the NSSF returns NRF information for the selected NSI so the AMF queries the correct NRF for that slice instance. The clean split is worth memorising: NSSF selects the slice/NSI; NRF discovers the NFs within it.

Roaming: vNSSF and hNSSF

Slice identifiers are PLMN-specific, so roaming needs translation, and the NSSF is where that translation is coordinated. In a visited network (VPLMN) the UE works with visited-PLMN S-NSSAI values, while its subscription and (for home-routed traffic) its slices live in the home network (HPLMN) under home S-NSSAI values.

Two NSSF instances cooperate. The visited NSSF (vNSSF) serves the visited AMF; when it needs the home network's view — for instance to validate requested slices against the subscription's home S-NSSAIs or to obtain the correct mapping — it consults the home NSSF (hNSSF) over the inter-PLMN path. Together they produce a consistent Allowed NSSAI in visited-PLMN values plus the mapping to home S-NSSAIs. The UE stores this mapping (its Configured, Requested and Allowed NSSAI each carry a mapping from serving-PLMN S-NSSAI to home S-NSSAI), so both operators use their own S-NSSAI values underneath while the UE experiences the "same" slice.

Summary

The NSSF is the 5GC's slice-selection authority. Read it as a pure function the AMF calls during registration: in go the Requested NSSAI, the Subscribed S-NSSAIs, the TAI and access type (plus roaming mapping); out come the Allowed NSSAI, the Rejected NSSAI with per-slice causes, the target AMF Set, the NSI ID, and — when roaming — the mapping to home S-NSSAIs.

Two things make that function possible. First, the Nnssf_NSSAIAvailability service builds the (S-NSSAI, TA, AMF) map that Nnssf_NSSelection later queries, which is why availability is always tracked per Tracking Area. Second, a clean division of labour: the NSSF chooses the slice and NSI and the serving AMF set, then drives re-routing to that set, while the NRF discovers the actual SMF/UPF instances within the chosen slice.

When a slice behaves unexpectedly, walk the chain: is it subscribed (UDM)? available in this TA (NSSAIAvailability map)? served by the current AMF (else re-routing)? and, if roaming, correctly mapped between vNSSF and hNSSF? Locating which of those failed usually tells you why the slice ended up in the Rejected or Pending NSSAI.