Home / Call Flows / 5G / Slice Authentication

5G Slice Authentication Procedure

5G Slice Authentication is the authorization side of slice handling, where the network decides whether a subscriber is really allowed to use a requested slice.

It is usually visible not as one isolated message, but as the combination of Requested NSSAI, subscription checks, and the final Allowed NSSAI outcome.

Introduction

This procedure is most useful when the UE requests a valid-looking slice but the network still does not return the expected result, or when registration seems fine but later service fails on slice-specific grounds.

The key challenge is separating true authorization failure from later service mismatch, because both can look like “slice not working” from the outside.

What Is Slice Authentication in Simple Terms?

What starts the procedure: The UE requests a slice and the network must validate entitlement and policy.
What the UE and network want to achieve: Return a slice result that matches both subscriber entitlement and serving-network constraints.
What success looks like: The slice is authorized and later service can use it cleanly.
What failure means: The slice is denied, remapped unexpectedly, or later service shows the authorization was not enough.

Why this procedure matters

Without clean slice authorization, the rest of the slice-aware service chain becomes noisy and hard to diagnose because registration and service failures blur together.

Quick Fact Sheet

Procedure name	5G Slice Authentication
Domain	Slice authorization and entitlement checks in 5G registration and service handling
Main trigger	The network must validate whether a subscriber is allowed to use a requested slice
Start state	UE has requested slice access and the network must evaluate entitlement and policy
End state	The requested slice is allowed, remapped, or effectively denied for the current context
Main nodes	UE, AMF, UDM / UDR, NSSF, SMF
Main protocols	NAS registration signaling, subscription retrieval, slice-selection support
Main success outcome	The subscriber is authorized for the intended slice and later service can continue cleanly
Main failure outcome	The slice is not authorized or later service reveals that entitlement and service intent do not align
Most important messages	Registration Request, Registration Accept, Requested NSSAI, Allowed NSSAI
Main specs	TS 23.501, TS 23.502, TS 24.501, TS 29.531

Preconditions

The UE has requested one or more slices during registration or update handling.
The network can retrieve subscriber entitlement and serving policy information.
Slice-selection assistance and subscription data are available where the architecture uses them.
Later service procedures can verify whether the slice was practically usable.

Nodes and Interfaces

Nodes involved

Node	Role in this procedure
UE	Requests slice access and later attempts to use the resulting allowed slice context.
AMF	Coordinates registration and evaluates slice entitlement against serving-network policy and subscription data.
UDM / UDR	Provide the subscriber data that constrains which slices are permitted.
NSSF	Supports slice-selection assistance and AMF suitability decisions when used.
SMF	Later proves whether the authorized slice is compatible with the intended DNN and session behavior.

Interfaces used

Interface	Path	Role
N1	UE <-> AMF	Carries the Requested NSSAI and final allowed slice outcome.
Subscription path	AMF <-> UDM / UDR	Provides entitlement data used for slice authorization.
N22	AMF <-> NSSF	Supports slice-selection decisions when the deployment uses NSSF.
N11	AMF <-> SMF	Later shows whether the selected slice can support requested session behavior.

End-to-End Call Flow

UE                AMF              UDM / NSSF
|-- Registration Request (Requested NSSAI) ------->|
|                              |-- authz checks -->|
|                              |<-- authz result --|
|<-- Registration Accept (Allowed NSSAI) ---------|
|==== later service validates slice usability =====>|

Major Phases

Phase	What happens
1. Requested slice arrives	The UE asks to use one or more slices during registration or update handling.
2. Authorization evaluation	The network checks subscription, roaming constraints, and serving policy.
3. Allowed slice outcome	The network returns a slice result that reflects what is really permitted.
4. Service confirmation	Later session procedures prove whether the authorized slice supports the intended service.

Step-by-Step Breakdown

UE requests access to a slice

Sender -> receiver: UE -> AMF

Message(s): Registration Request with Requested NSSAI

Purpose: Start the slice-authorization decision using the UE’s requested service intent.

State or context change: The network now has to decide whether the subscriber can use the requested slice.

Note: Engineers often call this slice authentication even though the visible evidence is spread across registration and later service use.

The network validates subscription and policy

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

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

Purpose: Confirm whether the requested slice is allowed in the current serving and subscriber context.

State or context change: The subscriber’s requested slice intent is reduced to a policy-approved result.

Note: This is where home entitlement, roaming restrictions, and local serving policy can diverge from what the UE expected.

Allowed slice information is returned

Sender -> receiver: AMF -> UE

Message(s): Registration Accept with Allowed NSSAI

Purpose: Provide the slice result the UE can actually use from this registration context onward.

State or context change: The UE now has the network-approved slice set for the current environment.

Note: Missing slices in Allowed NSSAI are often the clearest practical sign of failed authorization.

Later service requests confirm the practical result

Sender -> receiver: UE -> AMF / SMF

Message(s): PDU Session Establishment Request and later session handling

Purpose: Show whether the authorized slice can really support the intended service and DNN.

State or context change: The authorization decision turns into a real service outcome rather than only a registration result.

Note: If the slice looks valid in registration but service later fails, the issue may be entitlement-to-service mismatch rather than total authorization failure.

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-authorization handling.	Inspect the requested slice list and the broader registration context.
Registration Accept	NAS	AMF -> UE	Returns Allowed NSSAI and the effective authorization result.	Check which requested slices survived and which did not.
PDU Session Establishment Request	NAS	UE -> core	Later proves whether the authorized slice really supports the intended service.	Correlate the requested S-NSSAI here with the earlier Allowed NSSAI.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
Requested S-NSSAI	The slice the UE wants to use.	Registration Request	This is the starting authorization input.	If it is wrong or stale, the network may appear to reject a slice the UE never requested properly.
Subscription entitlement	Whether the subscriber is allowed to use the slice at all.	Subscription retrieval path	This is the core authorization question.	Subscriber provisioning mismatches are a common cause of missing slice access.
Serving-network policy	Local restrictions on slice use by PLMN, TAC, or roaming condition.	Authorization evaluation	Explains why a valid subscriber may still not get the requested slice in a specific context.	Local policy causes “works here, fails there” behavior.
Allowed NSSAI	The final allowed slice set returned to the UE.	Registration Accept	This is the visible network decision the UE can act on.	Unexpected differences here are the fastest way to detect an authorization mismatch.
Later DNN / session compatibility	Whether the allowed slice supports the intended service path.	PDU session setup	Shows whether authorization and service behavior are aligned.	A subscriber can be authorized for a slice but still fail later because the service intent is wrong.

Success Criteria

Requested slice intent is received correctly.
The network applies subscriber and serving-context authorization consistently.
Allowed NSSAI reflects the real authorization outcome.
Later service succeeds on the authorized slice without mismatch.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
The slice is requested but never allowed	The requested slice failed entitlement or serving-policy checks.	Requested S-NSSAI, Allowed NSSAI, and subscription result.	Registration Request, Registration Accept	N1, subscription path	This is the cleanest slice-authorization failure signature.
The slice is allowed but service still fails	Authorization succeeded, but the service request does not align with DNN or session policy.	Allowed NSSAI and later session request.	Registration Accept, PDU Session Establishment Request	N1, N11	Do not over-label this as total authentication failure.
Roaming changes the slice result	Mapped or visited-network slice policy changed the outcome.	Requested, mapped, and allowed slice context.	Registration Request, Registration Accept	Roaming authorization path	Roaming cases need special care because the home intent can still be correct.
Authorization differs by area or AMF	Serving context or policy domain changed the authorization outcome.	Mobility update result and Allowed NSSAI changes.	Registration Accept after movement	Mobility + policy	This is a strong clue that the issue is environmental rather than subscriber-global.

What to Check in Logs and Traces

Compare the requested slice to the allowed slice first.
Check whether the issue is really authorization or a later service mismatch.
Use roaming and serving-area context to explain unexpected authorization changes.
Correlate the slice result with later PDU session behavior before drawing conclusions.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

FAQ

What is Slice Authentication?

It is the practical authorization path where the network decides whether a subscriber may use a requested slice in the current context.

Is there a single slice-authentication message?

No. The outcome is usually visible across registration, subscription checks, and later service use rather than in one standalone message.

What should I inspect first?

Start with Requested S-NSSAI, Allowed NSSAI, and the subscriber entitlement behind them.

Why can authorization look successful but service still fail?

Because later DNN, SMF, or session-policy behavior may still not match the allowed slice result.

How is this different from Network Slice Selection?

Slice selection is the broader mechanism. Slice authentication focuses on the entitlement and authorization side of that mechanism.