Home / Call Flows / 5G / Network Slice Selection

5G Network Slice Selection Procedure

5G Network Slice Selection is the registration-time and service-time decision process that determines which slices a UE is actually allowed to use.

It starts with Requested NSSAI, continues through subscription and policy evaluation, and becomes operationally meaningful when later services try to use the selected slice.

Introduction

This procedure is central to 5G service differentiation because the UE can only proceed cleanly if the network returns a slice context that is both authorized and practically usable.

In troubleshooting, the most important task is separating the initial slice-selection decision from later session, DNN, or policy failures that only show up after registration.

What Is Network Slice Selection in Simple Terms?

What starts the procedure: The UE requests one or more S-NSSAIs during registration or update handling.
What the UE and network want to achieve: Return an Allowed NSSAI that accurately reflects the slices the UE can really use.
What success looks like: The expected slice appears in Allowed NSSAI and later service uses it cleanly.
What failure means: The requested slice is denied, remapped unexpectedly, or later proves unusable for service.

Why this procedure matters

Slice selection sits at the boundary between subscription, policy, roaming behavior, and real 5G service use. If it is misread, later session failures are often blamed on the wrong function.

Quick Fact Sheet

Procedure name	5G Network Slice Selection
Domain	5G registration and service authorization for slice-aware access
Main trigger	The UE requests one or more S-NSSAIs during registration or registration update
Start state	UE needs access to specific slice services in the serving PLMN
End state	The UE receives Allowed NSSAI and later service can continue on the selected slice set
Main nodes	UE, gNB, AMF, UDM, NSSF, SMF
Main protocols	NAS registration signaling, slice selection support, policy and subscription checks
Main success outcome	Requested slice intent is evaluated and a usable Allowed NSSAI is returned
Main failure outcome	The requested slice is denied, remapped, or leads to later session failure
Most important messages	Registration Request, Registration Accept, Allowed NSSAI, Requested NSSAI
Main specs	TS 23.501, TS 23.502, TS 24.501, TS 29.531

Preconditions

The UE is attempting registration or update signaling in a 5G serving network.
Requested NSSAI or configured slice context is available to the network.
The subscription and policy environment can evaluate slice entitlement.
Later service procedures can validate the resulting slice context.

Nodes and Interfaces

Nodes involved

Node	Role in this procedure
UE	Supplies Requested NSSAI and later attempts to use the selected slice for service procedures.
gNB	Carries the NAS signaling and later applies radio behavior consistent with the chosen slice context.
AMF	Acts as the main control-plane anchor for registration and coordinates slice selection handling.
UDM / UDR	Provide subscriber and entitlement data that constrain which slices are allowed.
NSSF	Supports slice and AMF selection where the deployment uses dedicated slice-selection assistance.
SMF	Uses the chosen slice context during later PDU session setup and service continuity.

Interfaces used

Interface	Path	Role
N1	UE <-> AMF	Carries Requested NSSAI in Registration Request and Allowed NSSAI in Registration Accept.
N2	gNB <-> AMF	Relays the access-side registration context that slice selection depends on.
N22	AMF <-> NSSF	Supports slice and AMF selection logic where used.
Nudm / subscription path	AMF <-> UDM / UDR	Provides subscriber entitlements that constrain slice authorization.

End-to-End Call Flow

UE                gNB                AMF              UDM / NSSF
|-- Registration Request (Requested NSSAI) --------->|
|                                  |-- checks ----->|
|                                  |<-- result -----|
|<-- Registration Accept (Allowed NSSAI) -----------|
|==== later service uses selected slice context =====>|

Major Phases

Phase	What happens
1. Slice intent appears	The UE includes Requested NSSAI during registration or update signaling.
2. Slice evaluation	The network checks subscription, policy, roaming context, and optional NSSF guidance.
3. Allowed slice result	The UE receives Allowed NSSAI and any practical indication that some slices are not usable.
4. Service confirmation	Later session procedures prove whether the selected slice context is really usable.

Step-by-Step Breakdown

UE sends Registration Request with Requested NSSAI

Sender -> receiver: UE -> gNB -> AMF

Message(s): Registration Request with Requested NSSAI

Purpose: Tell the network which slice or slices the UE wants to use in the serving PLMN.

State or context change: The network moves from generic registration handling into slice-aware access evaluation.

Note: Requested NSSAI is the first place to inspect when the user expects one slice but later gets another.

AMF checks subscription and slice-selection policy

Sender -> receiver: AMF <-> UDM / NSSF

Message(s): Subscription retrieval and slice-selection assistance

Purpose: Decide whether the requested slice set is allowed, partially allowed, mapped, or effectively rejected.

State or context change: The serving network resolves the requested slice intent into a policy-approved result.

Note: This is where roaming mapping and serving-area limitations often appear even though the UE only sees the final outcome.

Allowed NSSAI is returned to the UE

Sender -> receiver: AMF -> gNB -> UE

Message(s): Registration Accept with Allowed NSSAI

Purpose: Return the slice result that the UE can actually use from this point onward.

State or context change: The UE now knows which slice context is available in the current serving environment.

Note: Do not stop at the registration result. The practical value is proven only when service later uses the expected slice cleanly.

Later service procedures use the selected slice context

Sender -> receiver: UE -> AMF / SMF

Message(s): PDU Session Establishment Request and related slice-aware service signaling

Purpose: Validate that the selected slice really works for the intended DNN, policy, and service behavior.

State or context change: The registration-time slice result becomes an operational service outcome.

Note: Many slice problems are first visible in session setup, not in the registration exchange itself.

Important Messages in This Flow

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
Registration Request	NAS	UE -> AMF	Carries Requested NSSAI and starts slice-aware registration handling.	Inspect Requested NSSAI, serving PLMN, and registration context.
Registration Accept	NAS	AMF -> UE	Returns Allowed NSSAI and related registration outcome.	Check whether the expected S-NSSAI appears and whether any practical mismatch remains.
PDU Session Establishment Request	NAS	UE -> SMF via AMF	Later proves whether the selected slice is usable for real service.	Correlate the requested S-NSSAI with the Allowed NSSAI returned earlier.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
Requested NSSAI	The slice list the UE asks to use.	Registration Request	This is the starting intent the network evaluates.	Wrong or stale values can make the whole trace look like a network failure.
Allowed NSSAI	The slice set the network actually permits.	Registration Accept	Defines what the UE can use afterward in the current PLMN or area.	Expected slice missing from Allowed NSSAI is the clearest early symptom.
Rejected or unavailable S-NSSAI context	Practical indication that some requested slices are not usable.	Registration outcome and later service attempts	Explains why the requested slice did not survive selection.	This can be implicit rather than obvious in some traces.
Mapped NSSAI	Visited-network representation of a home-network slice.	Roaming slice-selection handling	Important when roaming changes the apparent slice identity.	Roaming mapping confusion is a common operator-side debugging trap.
DNN and S-NSSAI pairing	Whether later service requests match the selected slice result.	PDU Session Establishment Request	The best operational proof that slice selection really worked.	A valid Allowed NSSAI can still fail later if DNN and slice do not align.

Success Criteria

The UE sends the intended Requested NSSAI.
The network returns an Allowed NSSAI consistent with entitlement and policy.
The selected slice stays consistent in later session procedures.
Real service succeeds on the selected slice.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
The requested slice never appears in Allowed NSSAI	The subscriber or serving network did not authorize the requested slice.	Requested NSSAI, Allowed NSSAI, and subscription policy.	Registration Request, Registration Accept	N1, subscription path	Treat this as an authorization or serving-policy issue before blaming session management.
Registration succeeds but session setup fails	The registration path selected a slice context that still does not support the intended DNN or service.	Allowed NSSAI and later PDU session request.	Registration Accept, PDU Session Establishment Request	N1, N11	This is one of the most common slice-selection misunderstandings.
Slice behavior changes in roaming	Mapped NSSAI or visited-network policy changed the result.	Requested versus mapped slice context.	Registration Request, Registration Accept	Roaming slice-selection path	Compare home expectation with visited-network policy before concluding the slice is “missing.”
Slice works in one area and not another	Serving-area slice availability or policy differs by region.	Allowed NSSAI after movement or update.	Registration Accept after movement	Mobility and policy domain	This is often a local deployment or service-area issue rather than a core-wide failure.

What to Check in Logs and Traces

Compare Requested NSSAI against Allowed NSSAI first.
Check whether the case involves roaming or mapped NSSAI.
Use later PDU session requests to prove whether the selected slice really worked.
If the issue is area-dependent, compare the result before and after movement or update.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

FAQ

What is Network Slice Selection?

It is the 5G procedure that determines which requested slices a UE is allowed to use during registration and later service.

Does slice selection end at Registration Accept?

No. The registration result is only the first checkpoint. Later session procedures prove whether the slice is really usable.

What should I inspect first?

Start with Requested NSSAI and Allowed NSSAI, then correlate the later PDU session request with that result.

Why can registration succeed but service still fail?

Because a selected slice can still be incompatible with the requested DNN, SMF policy, or service intent.

Why is roaming harder?

Because mapped NSSAI and visited-network policy can make the slice outcome look different from the home-network expectation.