Home / Call Flows / 5G / Slice-Aware Registration Rejection / Retry

5G Slice-Aware Registration Rejection / Retry

call-flow 5G NR | Slice Admission | Registration Reject | NSSAI

5G Slice-Aware Registration Rejection / Retry is the recovery path used when a UE requests slice context that the serving network cannot admit as sent.

The important engineering task is to understand why the original slice request failed and whether the retry really corrected the mismatch or only produced a reduced result.

Introduction

This page is most useful when registration problems appear tied to Requested NSSAI, local area restrictions, roaming policy, or changed slice availability.

The central risk is blind retry behavior: the UE or engineer repeats the same request without fixing the actual mismatch, so the failure just loops.

What Is Slice-Aware Registration Rejection / Retry in Simple Terms?

What starts the procedure: The UE requests registration with slice intent the serving network cannot admit.
What the UE and network want to achieve: Converge on a slice-aware registration result the network can actually support.
What success looks like: The UE reaches a valid registration state after correcting or reducing the slice request.
What failure means: The UE loops, keeps failing, or reaches a reduced result that still does not support service.

Why this procedure matters

This procedure turns a confusing registration failure into a tractable slice-admission problem. Without that framing, retries become noise instead of progress.

Quick Fact Sheet

Procedure name	5G Slice-Aware Registration Rejection / Retry
Domain	5G registration admission handling when requested slices are unavailable or not permitted
Main trigger	A registration attempt requests slice access that the serving network cannot accept as requested
Start state	UE attempts registration with Requested NSSAI that does not fit current entitlement, availability, or serving policy
End state	The UE is rejected, retries with corrected context, or continues with a reduced slice set
Main nodes	UE, gNB, AMF, UDM / UDR, NSSF
Main protocols	Registration Request, Registration Reject or Accept, Requested NSSAI retry logic
Main success outcome	The UE converges on a valid registration path after understanding the slice-related rejection reason
Main failure outcome	The UE loops or repeatedly fails because slice mismatch is never corrected
Most important messages	Registration Request, Registration Reject, Registration Accept, Allowed NSSAI
Main specs	TS 23.501, TS 23.502, TS 24.501

5G Slice-Aware Registration Rejection and Retry

Preconditions

The UE is attempting registration with Requested NSSAI.
The serving environment cannot accept that request as originally sent.
The network can return enough result information to drive retry behavior.
Later service can validate whether the retry result is actually useful.

Nodes and Interfaces

Nodes involved

Node	Role in this procedure
UE	Attempts registration, interprets the rejection or reduced result, and retries with corrected slice context when needed.
gNB	Carries the registration signaling and any retry attempt toward the core.
AMF	Evaluates slice-aware registration admission and returns rejection or reduced authorization outcome.
UDM / UDR and NSSF	Support entitlement and slice-selection decisions that explain why the registration branch failed or was reduced.

Interfaces used

Interface	Path	Role
N1	UE <-> AMF	Carries the original registration attempt, rejection, and any retry attempt.
N2	gNB <-> AMF	Relays the registration context for both the first try and the follow-on retry.
Subscription and slice-selection path	AMF <-> UDM / NSSF	Determine why the requested slice could not be admitted as originally requested.

End-to-End Call Flow

UE                gNB                AMF
|-- Registration Request (Requested NSSAI) -------->|
|<-- Registration Reject / reduced result ----------|
|-- Retry Registration Request --------------------->|
|<-- Registration Accept with usable slice result --|
|==== later service validates the retry outcome =====>|

Major Phases

Phase	What happens
1. First registration attempt	The UE requests registration with slice intent that does not fit the serving conditions.
2. Slice-aware decision	The network determines whether to reject, reduce, or remap the request.
3. Retry or fallback behavior	The UE retries with corrected slice assumptions or continues with a narrower allowed set.
4. Stable registration outcome	The UE either reaches a valid slice-aware registration state or keeps failing until the requested context changes.

Step-by-Step Breakdown

UE sends Registration Request with unsupported or disallowed slice intent

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

Message(s): Registration Request with Requested NSSAI

Purpose: Attempt registration using the slice set the UE currently expects to use.

State or context change: The network now has to judge whether the requested slice set is acceptable in the current context.

Note: The most useful early question is whether the UE asked for the wrong thing, or the network environment changed underneath a previously valid request.

The network returns rejection or a reduced result

Sender -> receiver: AMF -> UE

Message(s): Registration Reject or Registration Accept with a reduced slice result

Purpose: Tell the UE that the original slice request could not be admitted as sent.

State or context change: The registration flow becomes slice-aware error handling rather than a clean first-pass success.

Note: In many real cases, the practical clue is not just the reject itself but the mismatch between requested and allowed slice context afterward.

The UE retries with corrected or narrower slice assumptions

Sender -> receiver: UE -> AMF

Message(s): Follow-on Registration Request or updated registration behavior

Purpose: Converge on a slice set that the serving network will actually admit.

State or context change: The UE moves from failed admission toward a corrected registration path.

Note: Repeated retries with identical slice assumptions often mean the real rejection cause is still not being interpreted correctly.

Later service confirms whether the retry result is truly usable

Sender -> receiver: UE -> AMF / SMF

Message(s): PDU Session Establishment Request after successful retry or reduced registration outcome

Purpose: Validate that the new slice context supports real service after the retry.

State or context change: The retry outcome becomes a true operational result rather than only a registration status.

Note: A successful retry that still cannot support service usually means the slice mismatch was only partially corrected.

Important Messages in This Flow

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
Registration Request	NAS	UE -> AMF	Starts the slice-aware registration attempt or retry.	Compare the retry request to the original one.
Registration Reject	NAS	AMF -> UE	Signals that the requested registration context could not be admitted as sent.	Use the reject cause together with Requested NSSAI to avoid blind retry loops.
Registration Accept	NAS	AMF -> UE	May return a reduced but usable registration outcome after slice-aware adjustment.	Check Allowed NSSAI carefully rather than assuming full success.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
Requested NSSAI	The slice set the UE originally tried to register with.	Original Registration Request	This defines what the network is rejecting or narrowing.	The retry is meaningless if this baseline is not understood.
Reject cause	The NAS-level reason the registration could not proceed as requested.	Registration Reject	Helps separate slice mismatch from unrelated registration trouble.	Ignoring the cause usually creates repeated retry loops.
Allowed NSSAI after retry	The slice set returned once the UE or network converges on a valid result.	Registration Accept after retry or reduced outcome	Shows whether the retry actually fixed the slice mismatch.	A “successful” retry can still hide that the expected slice is gone.
Serving-area or roaming context	The environment that may have changed the slice result.	Whole retry scenario	Explains why a previously valid request now fails.	This is especially important in area-specific or roaming-specific cases.
Post-retry service behavior	Whether the resulting registration state supports actual service.	After retry	Proves the retry solved the real operational problem.	Registration success alone does not guarantee service success.

Success Criteria

The reject is interpreted in the context of the original slice request.
The retry differs meaningfully from the failed first attempt when needed.
The resulting registration state provides a usable Allowed NSSAI.
Later service validates that the retry solved the real problem.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
The UE keeps retrying and keeps failing	The real slice mismatch is not being corrected between attempts.	Original request, reject cause, and retry request differences.	Registration Request, Registration Reject	N1	Compare the first and second attempts directly instead of reading them in isolation.
The retry succeeds but the expected slice is still gone	The network admitted a narrower result, not the originally desired slice set.	Allowed NSSAI after retry.	Registration Accept after retry	N1	This is a reduced-success outcome, not full recovery.
The problem only happens in one serving context	Area-specific or roaming-specific slice policy is driving the reject.	Serving-area and policy context around the reject.	Original attempt and retry	Policy / roaming domain	This often explains “works there, fails here” reports.
Later session setup still fails after a successful retry	The retry fixed registration admission but not actual service compatibility.	Post-retry PDU session request.	PDU Session Establishment Request	N11	The retry solved only part of the end-to-end problem.

What to Check in Logs and Traces

Compare the first Registration Request and the retry directly.
Read the reject cause together with Requested NSSAI and serving context.
Check whether the retry led to full recovery or only a reduced slice result.
Validate the outcome with later PDU session behavior, not just Registration Accept.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

FAQ

What is Slice-Aware Registration Rejection / Retry?

It is the 5G registration recovery path used when the UE requested slice context that the serving network could not admit as sent.

Does a retry always mean success?

No. A retry may converge on a reduced slice set rather than the originally intended one.

What should I inspect first?

Start with the original Requested NSSAI, the reject cause, and how the retry differs from the first attempt.

Why can the same subscriber succeed later?

Because the retry may use corrected slice context or the serving environment may have changed.

Why is later service still important?

Because a corrected registration result is only useful if it also supports the intended session and service behavior.