Home / Call Flows / 5G / Slice-Aware PDU Session Establishment

5G Slice-Aware PDU Session Establishment

call-flow 5G NR | Slice-Aware Session | S-NSSAI | DNN | SMF

5G Slice-Aware PDU Session Establishment explains what happens when a UE tries to create a session on a slice selected during registration.

The key engineering question is whether the selected slice, the requested DNN, and the service intent actually fit together well enough for the core to build the session.

Introduction

This page is especially useful when registration looked healthy but the service still never came up, or when a slice appears present in Allowed NSSAI but session setup is rejected anyway.

The underlying pattern is common in real networks: the registration branch selected a slice context, but the later session branch reveals that the requested service still does not match it.

What Is Slice-Aware PDU Session Establishment in Simple Terms?

What starts the procedure: The UE requests a PDU session using a selected slice and DNN.
What the UE and network want to achieve: Build a session on a slice that truly supports the intended service.
What success looks like: The session is accepted on the expected slice and real traffic works afterward.
What failure means: The slice-service pairing is wrong, incomplete, or only partially usable.

Why this procedure matters

This procedure is where slice theory turns into service reality. A slice that looks correct in registration can still fail when real session semantics arrive.

Quick Fact Sheet

Procedure name	5G Slice-Aware PDU Session Establishment
Domain	5G session setup constrained by slice selection and Allowed NSSAI
Main trigger	The UE tries to establish a PDU session on a slice selected during registration
Start state	UE is registered and has a current Allowed NSSAI, but service still needs a valid slice and DNN combination
End state	The session is established on a valid slice or rejected because the slice-service combination is not allowed
Main nodes	UE, AMF, SMF, UPF, NSSF, policy functions
Main protocols	PDU Session Establishment Request, Allowed NSSAI correlation, slice-aware policy and session selection
Main success outcome	The requested session is created on a slice that matches the UE’s allowed slice context and service intent
Main failure outcome	Session setup fails because the selected slice does not support the intended DNN, SMF, or policy path
Most important messages	PDU Session Establishment Request, PDU Session Establishment Accept, PDU Session Establishment Reject
Main specs	TS 23.501, TS 23.502, TS 24.501, TS 29.531

5G Slice-Aware PDU Session Establishment

Preconditions

The UE is already registered and has current Allowed NSSAI context.
The intended service requires a new or validated PDU session on a selected S-NSSAI.
The requested DNN and slice pairing are known and can be evaluated by the core.
Real traffic can be used to validate the outcome after Accept.

Nodes and Interfaces

Nodes involved

Node	Role in this procedure
UE	Requests a session using an S-NSSAI it believes is allowed after registration.
AMF	Relays the request and ensures it is handled in the context of the current registration and slice state.
SMF	Evaluates whether the DNN, policy, and service intent can be supported on the requested slice.
UPF	Provides the user-plane anchor if the slice-aware session is accepted.
NSSF / policy functions	Support slice-aware service decisions where the architecture uses them.

Interfaces used

Interface	Path	Role
N1	UE <-> AMF	Carries the slice-aware PDU Session Establishment Request and its result.
N11	AMF <-> SMF	Builds the session in the context of the selected slice and requested service.
N4 / N3	SMF <-> UPF and gNB <-> UPF	Create the user-plane path when the requested slice-service combination is valid.
Slice-selection and policy path	AMF / SMF <-> NSSF / policy	Help confirm whether the requested session can run on the chosen slice.

End-to-End Call Flow

UE                AMF                SMF / policy            UPF
|-- PDU Session Establishment Request (S-NSSAI, DNN) ----------->|
|                                |-- slice-aware checks --------->|
|                                |<-- service decision -----------|
|<-- Accept / Reject --------------------------------------------|
|==== traffic validates slice-aware session usability ==========>|

Major Phases

Phase	What happens
1. Registered slice context exists	The UE already has Allowed NSSAI from registration.
2. Slice-aware session request	The UE asks for a PDU session on a specific S-NSSAI and DNN combination.
3. Service compatibility check	The core decides whether that slice can actually support the requested session.
4. Accept or reject outcome	The network either creates the session or rejects it with a slice-related mismatch.

Step-by-Step Breakdown

UE requests a PDU session using the selected slice context

Sender -> receiver: UE -> AMF -> SMF

Message(s): PDU Session Establishment Request with S-NSSAI and DNN

Purpose: Ask the network to create a session on the slice the UE believes is currently usable.

State or context change: The session path becomes slice-aware rather than generic session setup.

Note: The critical comparison is between the S-NSSAI in the session request and the Allowed NSSAI returned earlier during registration.

The core evaluates whether the requested service fits the slice

Sender -> receiver: AMF <-> SMF <-> policy / NSSF

Message(s): Slice-aware session selection and policy checks

Purpose: Determine whether the requested DNN, service profile, and slice combination can actually be supported.

State or context change: The requested session is either validated as a correct slice-service match or moved toward rejection.

Note: This is where engineers discover that a slice can be allowed at registration time but still be wrong for a specific service request.

The network accepts or rejects the session

Sender -> receiver: SMF -> AMF -> UE

Message(s): PDU Session Establishment Accept or PDU Session Establishment Reject

Purpose: Return the final operational answer for the requested slice-aware session.

State or context change: The UE either gains a usable session or learns that the chosen slice-service pairing cannot continue.

Note: A reject here often explains why registration looked healthy while service still never came up.

Real traffic confirms whether the selected slice session is usable

Sender -> receiver: UE <-> UPF / data network

Message(s): First traffic on the accepted slice-aware session

Purpose: Prove that the accepted session supports actual service beyond the NAS result.

State or context change: The slice result becomes an application- and transport-level reality.

Note: For slice-aware service, real traffic is still the final proof just like in generic PDU session analysis.

Important Messages in This Flow

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
PDU Session Establishment Request	NAS	UE -> core	Starts slice-aware session setup on a chosen S-NSSAI.	Compare its S-NSSAI and DNN to the earlier Allowed NSSAI.
PDU Session Establishment Accept	NAS	Core -> UE	Confirms the selected slice can support the requested session.	Use it to verify that the accepted session really reflects the intended slice-service combination.
PDU Session Establishment Reject	NAS	Core -> UE	Shows that the requested slice-service combination could not be built.	Read the reject together with Allowed NSSAI and DNN rather than in isolation.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
Allowed NSSAI baseline	The slice set that registration said the UE could use.	Before session request	This is the reference point for any slice-aware session analysis.	Without it, you cannot prove whether the session asked for a valid slice.
Requested S-NSSAI	The specific slice chosen for the session request.	PDU Session Establishment Request	Shows whether the UE asked for a currently allowed slice.	A mismatch here often explains rejects immediately.
DNN and service intent	The data-network target and service profile the UE wants on that slice.	PDU Session Establishment Request	A slice can be valid in principle but wrong for the requested DNN.	This is a common hidden mismatch.
Reject cause or Accept profile	The session outcome at NAS level.	Accept or Reject	Best direct result for the slice-aware service decision.	Treat the result as part of a slice chain, not only a generic session result.
First user-plane traffic	Whether the accepted session is operationally useful.	After Accept	The final practical proof of slice-aware session success.	Accept without working traffic is still incomplete success.

Success Criteria

The requested S-NSSAI matches the current Allowed NSSAI context.
The selected slice is valid for the requested DNN and service intent.
The network returns an Accept that reflects the intended slice-aware result.
Real user-plane traffic proves the session is practically usable.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
The slice is allowed at registration but session setup is rejected	The slice-service combination is invalid even though the slice itself looked available.	Allowed NSSAI, requested S-NSSAI, DNN, and reject cause.	PDU Session Establishment Request, Reject	N1, N11	This is the defining slice-aware session failure pattern.
The wrong slice is requested for the service	The UE or service logic chose an S-NSSAI that does not match the intended DNN or policy path.	Requested S-NSSAI and DNN.	PDU Session Establishment Request	N1	The session can fail even though the network’s registration result was reasonable.
The session is accepted but does not behave as expected	The slice-aware service profile is technically accepted but still not usable for the intended application.	Accept contents and first traffic.	Accept and early user-plane packets	N3, N4	Treat this as post-accept slice-aware service validation failure.
Movement changes slice-aware session behavior	The slice remained or changed after movement in a way that affects later session setup.	Pre- and post-mobility Allowed NSSAI.	Registration Accept after movement, later session request	Mobility + session path	This connects slice mobility with slice-aware session outcomes.

What to Check in Logs and Traces

Use the Allowed NSSAI from registration as the baseline.
Compare S-NSSAI and DNN in the session request directly.
Read Accept or Reject as a slice-aware service result, not only generic session signaling.
Validate the decision with the first real traffic on the accepted session.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

FAQ

What is Slice-Aware PDU Session Establishment?

It is the 5G session-setup path where the selected slice context directly affects whether the requested session can be created.

Why is it different from normal PDU Session Establishment?

Because this page focuses on the relationship between Allowed NSSAI, requested S-NSSAI, DNN, and service compatibility.

What should I inspect first?

Start with the Allowed NSSAI from registration, then compare it to the S-NSSAI and DNN in the session request.

Why can the session fail if the slice was already allowed?

Because slice availability at registration time does not automatically guarantee that every service or DNN can run on that slice.

What proves success?

A valid Accept plus real service traffic on the intended slice-aware session.