Home / Call Flows / slice-authentication

5G Slice Authentication Procedure Explained

call-flow 5G NR | 5GC | NSSAI | UDM | NSSF

Introduction

Slice Authentication is the authorization step that determines whether a UE is allowed to use a requested S-NSSAI in the current network and service context.

Engineers usually see this as part of a larger registration and slice-selection chain rather than as a standalone message sequence. In practice, the network evaluates the requested slice against subscription data, policy rules, roaming constraints, and sometimes NSSF guidance before the slice is accepted.

This page is most useful when read together with Network Slice Selection, 5G Initial Registration, and PDU Session Establishment.

The relevant behavior is primarily defined in:

3GPP TS 23.501 - System Architecture for the 5G System
3GPP TS 23.502 - 5G System Procedures
3GPP TS 24.501 - NAS Protocol

5G slice authentication procedure diagram showing UE, AMF, UDM, and NSSF authorization flow

What Slice Authentication Means in Practice

There is no single “slice authentication message” that solves everything. Instead, slice access is validated by combining Requested NSSAI, subscriber data, service policy, and serving-network constraints.

Check point	Why engineers care
Requested S-NSSAI	Shows what the UE is asking for during registration or service access.
Subscription authorization	Determines whether the subscriber is allowed to use that slice at all.
Serving-network policy	Explains why a slice may be blocked in a specific PLMN, TAC, or roaming case.
NSSF-assisted selection	Helps decide slice or AMF suitability where network architecture uses that function.
Allowed or rejected NSSAI outcome	Shows the final authorization result visible to the UE.

Network Functions Involved

Network Function	Role in slice authentication
UE	Requests slice access through Requested NSSAI and later attempts service use on the selected slice.
AMF	Coordinates registration context, checks slice handling logic, and returns allowed slice information.
UDM / UDR	Provides subscription data used to validate whether the requested slice is permitted.
NSSF	Supports slice selection and authorization decisions where deployed in the operator architecture.
SMF	Later enforces whether the selected slice can actually support the requested PDU session and DNN.

Slice Authentication Call Flow Position

UE             gNB              AMF             UDM / NSSF
 |               |                |                  |
 |-- Registration Request ------->|                  |
 |   (Requested NSSAI)            |                  |
 |               |--------------->|                  |
 |               |                |-- authz checks ->|
 |               |                |<-- authz result -|
 |<-- Registration Accept --------|                  |
 |   (Allowed / Rejected NSSAI)   |                  |

In logs, slice authentication usually appears as a decision path rather than a dedicated standalone exchange. The visible evidence is often the difference between the requested and allowed slice set.

Step-by-Step Slice Authentication Flow

Step 1: UE Requests Slice Access

The UE includes slice information, typically in the form of Requested NSSAI, as part of registration or a registration update.

What to inspect

Requested S-NSSAI values
PLMN and roaming context
Configured NSSAI already stored by the UE

Step 2: Subscription and Policy Validation

The AMF checks whether the subscriber is authorized for the slice and whether the requested slice is valid in the current serving network context.

What to inspect

Subscription profile in UDM
Roaming restrictions
Serving-area or TAC-specific policy
NSSF selection result if present

Step 3: Allowed or Rejected Slice Outcome

The network returns the allowed slice set, and may implicitly or explicitly indicate that one or more requested slices are not available.

What to inspect

Allowed NSSAI
Rejected NSSAI or unavailable S-NSSAI entries
Mapped NSSAI values in roaming cases

Step 4: Session Procedures Confirm the Result

Even if registration completes, the practical proof comes later. When the UE starts PDU Session Establishment, the requested DNN and selected S-NSSAI must still match what the network allows.

What to inspect

Requested S-NSSAI in PDU session setup
DNN and slice compatibility
SMF and policy outcome

Common Failure Patterns

Failure pattern	Typical engineering meaning
Slice requested but not returned in Allowed NSSAI	The subscriber or serving network is not authorizing that slice.
Registration succeeds but session setup fails	The slice looked acceptable at registration time, but later DNN or SMF logic rejected service use.
Works in one area, fails in another	Slice authorization may be constrained by local serving area, TAC, or deployment readiness.
Roaming user sees different slice behavior	Mapped NSSAI or visited-network policy is changing the expected result.

What to Check in Logs and Traces

Requested NSSAI in the UE-originated registration signaling.
Allowed NSSAI returned by the network.
Any rejected or unavailable slice indicators.
Subscription data and policy alignment for the subscriber profile.
Whether the same slice is reused later during PDU session establishment.
Whether the issue is true slice authorization failure or a later DNN / policy / SMF mismatch.

Related Procedures

Recommended Reference Specifications

3GPP TS 23.501 - System Architecture for the 5G System
3GPP TS 23.502 - 5G System Procedures
3GPP TS 24.501 - NAS Protocol
3GPP TS 29.531 - NSSF Services and APIs