Home / Call Flows / 5G / Session Reactivation after Idle/Inactive Return

5G Session Reactivation after Idle / Inactive Return Call Flow

call-flow 5G NR | 5GC | Idle/Inactive Recovery | NAS | SMF | UPF

5G Session Reactivation after Idle / Inactive Return explains how a previously established session becomes usable again when the UE returns to active service.

The real engineering question is whether the prior session was truly reused cleanly or whether the network had to repair or recreate more than expected.

Introduction

This page covers the restoration path for a dormant session after the UE returns from idle or inactive behavior.

The clearest troubleshooting pattern is to anchor on the old PDU Session ID, inspect Service Request or paging recovery, then validate the first resumed packets on the reused path.

What Is Session Reactivation after Idle/Inactive Return in Simple Terms?

What starts the procedure: The UE or network needs to use an already-established session again after idle or inactive return.
What the UE and network want to achieve: Reactivate the old session quickly without full new setup.
What success looks like: The existing session resumes traffic correctly and predictably.
What failure means: Reachability returns but session reuse is stale, partial, degraded, or replaced by hidden rebuild.

Why this procedure matters

A lot of real-world service trouble happens in the gap between idle recovery and true session usability. If you stop at Service Request success, you miss the actual problem.

Quick Fact Sheet

Procedure name	5G Session Reactivation after Idle / Inactive Return
Domain	5G NR + 5GC reachability recovery and session reuse
Main trigger	UE returns from idle or inactive state and needs to use previously established session context again
Start state	UE has dormant or suspended session context but no fully active service path
End state	Previously established session context is active again and traffic resumes
Main nodes	UE, gNB, AMF, SMF, UPF
Main protocols	Paging or resume-related signaling, NAS Service Request, NGAP, PFCP as needed
Main success outcome	The UE resumes service and the existing session becomes usable again without full re-establishment
Main failure outcome	Reachability returns but the prior session cannot be reused cleanly, forcing repair or re-establishment
Most important messages	Paging, Service Request, resume-related signaling, session resource setup updates
Main specs	TS 23.502, TS 24.501, TS 38.300

5G Session Reactivation after Idle or Inactive Return procedure flow

Preconditions

A prior PDU session already exists in dormant or suspended form.
The UE can return from idle or inactive behavior when service is needed.
The network still has enough session context to reuse or repair the old path.
Traffic validation is available after reactivation.

Nodes and Interfaces

Nodes involved

Node	Role in this procedure
UE	Returns from idle or inactive behavior and tries to use existing session context again.
gNB	Restores access-side resources needed for the resumed session.
AMF	Coordinates the return to active service from the core-control perspective.
SMF	Confirms or repairs the session resources needed for reactivation.
UPF	Provides the user-plane path once the session becomes active again.

Interfaces used

Interface	Path	Role
NR-Uu	UE <-> gNB	Carries restored access signaling and resumed traffic.
N1	UE <-> AMF	Carries Service Request or related signaling for service restoration.
N2	gNB <-> AMF	Restores access-side session resources.
N11	AMF <-> SMF	Checks or updates session state during reactivation.
N4 / N3	SMF <-> UPF and gNB <-> UPF	Re-enable or validate the user-plane resources for the resumed session.

End-to-End Call Flow

UE                gNB                AMF                SMF / UPF
|                  |                  |                    |
|.... idle or inactive with dormant session context ...... |
|-- Service Request / resume ------------>|                |
|                  |--------------------->|---------------->|
|                  |<-- resource restore -|<---------------|
|==== resumed traffic on existing session =================>|

Major Phases

Phase	What happens
1. UE needs service again	A UE in idle or inactive state needs to send or receive traffic using an existing session.
2. Signaling restoration	Paging or Service Request restores the control path toward active service.
3. Session resource reactivation	The network brings back the access and core resources needed for the existing session.
4. User-plane validation	Traffic proves the reused session is really active again.
5. Stable resumed service	The prior session resumes normal behavior without a full new setup.

Step-by-Step Breakdown

The dormant session becomes needed again

Sender -> receiver: UE application or incoming service trigger

Message(s): Need for data on an existing session

Purpose: Start service restoration without assuming a brand-new session is required.

State or context change: The UE has valid session context but lacks an active path.

Note: This is the main distinction from PDU Session Establishment: the goal is reuse, not brand-new creation.

The UE or network restores active reachability

Sender -> receiver: Paging or UE-originated signaling

Message(s): Service Request and related restoration signaling

Purpose: Move the UE back into an active state where the session can carry traffic again.

State or context change: The signaling path becomes live again.

Note: A successful Service Request does not yet prove that the old session resources are usable.

The network reactivates the session resources

Sender -> receiver: gNB <-> AMF <-> SMF <-> UPF

Message(s): Session resource setup or revalidation

Purpose: Reuse the existing session context and restore transport resources quickly.

State or context change: The previously established session becomes operational again.

Note: The main question is whether the old session context was reused cleanly or silently drifted stale.

The UE resumes traffic on the existing session

Sender -> receiver: UE <-> gNB <-> UPF

Message(s): First packets after reactivation

Purpose: Validate that the resumed session really carries traffic again.

State or context change: The resumed session is tested in live service conditions.

Note: First packets matter more than control-plane success here as well.

Fallback behavior is assessed if reuse fails

Sender -> receiver: UE and core session logic

Message(s): Recovery handling or later full session setup

Purpose: Understand whether the network had to fall back to another procedure.

State or context change: The operator can classify the event as clean reactivation or failed reuse.

Note: This step helps separate reactivation success from hidden re-establishment.

Important Messages in This Flow

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
Service Request	NAS	UE -> AMF	Restores service reachability so dormant session context can be used again.	Primary checkpoint for the return to active service.
Paging	RRC / NGAP	Network -> UE	May be needed when the network initiates the return to active service.	Shows how the dormant UE was recovered.
Session resource setup or revalidation	NGAP / control	gNB, AMF, SMF	Restores or validates the resources for the reused session.	Critical for proving reuse instead of accidental new setup.
First resumed packets	User plane	UE <-> UPF	Prove the reactivated session really carries traffic again.	Best final validation step.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
Existing PDU Session ID	Dormant session being reactivated.	All related traces	Ensures the resumed traffic belongs to the prior session.	Wrong ID hides accidental new setup.
Idle or inactive return trigger	Why the UE became active again.	Before Service Request or paging	Explains whether the return was UE-originated or network-originated.	Important for correct call-flow classification.
Service Request outcome	Whether signaling restoration succeeded.	N1 restoration phase	Separates reachability failure from session-resource failure.	Do not skip this distinction.
Session resource reuse state	Whether existing resources were reused or repaired.	gNB/SMF/UPF updates	Core question of this procedure.	A hidden repair path changes the diagnosis.
First resumed traffic	Packets on the reactivated session.	Post-reactivation validation	Best proof that reuse really worked.	Without this, success is still provisional.

Success Criteria

The correct dormant session is reactivated.
Service Request or related recovery signaling restores active service cleanly.
Existing session resources are reused or repaired correctly.
Traffic resumes on the intended session with acceptable quality.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
UE becomes reachable but the old session does not reactivate	Signaling restoration succeeded, but session resources remained stale or incomplete.	Service Request plus session-resource updates.	Restoration signaling	N1, N2, N3	This is the core failure pattern for idle/inactive return.
The network silently rebuilds a new path	Reuse was expected, but the result behaves more like a new setup.	Existing session ID versus new resource behavior.	Post-reactivation state	N11, N4	Important for accurate procedure classification.
Traffic resumes with degraded quality	Reactivation technically worked, but QoS or path state is no longer correct.	First packets, QoS, and bearer behavior.	Post-reactivation traffic	NR-Uu, N3	This is still a real reactivation problem.
Wrong dormant session is resumed	Correlation between old context and resumed service is incorrect.	Session ID and old-context traces.	All related signaling	N1, N11	Always verify identity first in multi-session UEs.

What to Check in Logs and Traces

Anchor all analysis on the existing PDU Session ID that should be reused.
Separate reachability restoration from session reactivation in the trace.
Inspect whether session resources were reused cleanly or silently rebuilt.
Use the first resumed packets as the main proof of success.
If the result behaves like a new setup, verify whether the event was actually reactivation or hidden re-establishment.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

Notes

Reactivation success is traffic success. A dormant session is only truly back when the expected service resumes on the same intended session context.

FAQ

What is Session Reactivation after Idle / Inactive Return?

It is the procedure where a previously established session becomes usable again after the UE returns from idle or inactive behavior.

Is this the same as PDU Session Establishment?

No. The target is to reuse existing session context, not create a brand-new session.

What proves success?

The existing session resumes traffic correctly without requiring hidden full re-establishment.

What should I inspect first?

Start with the existing session ID, the return trigger, the Service Request result, and the first resumed packets.

Why is this procedure easy to misread?

Because the control signaling can look similar to other recovery flows unless you track whether the old session was truly reused.