5G RRC Suspend Procedure Call Flow

call-flow 5G NR | RRC | Inactive State | Paging | Context Preservation

5G RRC Suspend is the state-transition procedure that lets the network stop active radio use while still preserving enough context for a fast later return.

It is one of the core mechanisms behind RRC Inactive and the low-latency, low-overhead behavior expected from modern 5G access.

Introduction

Suspend is not just a lighter release. It is a deliberate decision to preserve resumable context because the network expects the UE may need service again soon.

That makes it tightly linked to RRC Resume, paging, and service patterns with short idle gaps.

What Is RRC Suspend in Simple Terms?

What starts the procedure: The network wants to leave connected mode but keep fast return capability.
What the UE and network want to achieve: Reduce radio overhead while preserving resumable inactive-state context.
What success looks like: The UE becomes inactive, stays reachable, and later resumes quickly when needed.
What failure means: Stored context is not useful later or the state model becomes unstable and noisy.

Why this procedure matters

Suspend is a practical optimization point for latency, battery life, and signaling efficiency. It is also a common place where policy choices decide whether the user experience feels smooth or full of short reconnects.

Quick Fact Sheet

Procedure name	5G NR RRC Suspend Procedure
Domain	5G NR connected-to-inactive state transition
Main trigger	The network wants to stop active radio use but preserve context for a faster later return
Start state	UE is in RRC Connected
End state	UE moves to RRC Inactive with resumable context preserved
Main nodes	UE, gNB, optionally AMF through broader context behavior
Main protocols	RRC, NGAP, paging context
Main success outcome	Active radio resources are released while the UE remains resumable through inactive-state context
Main failure outcome	Suspend context is unusable later, the UE cannot resume cleanly, or the state model becomes unstable
Most important messages	RRC Suspend, later RRC Resume Request, Paging
Main specs	TS 38.331, TS 38.300, TS 23.502

Preconditions

The UE is currently in connected mode.
The network and UE support inactive-state behavior.
Preserving resumable context is operationally more useful than forcing full fresh setup later.
Paging and later service-restoration paths remain available after inactive entry.

Nodes and Interfaces

Nodes involved

Node	Role in this procedure
UE	Leaves connected mode while keeping the information needed for a later resume attempt.
gNB	Chooses inactive-state entry, sends suspend information, and stores resumable context.
AMF	Supports later reachability and service-restoration behavior after inactive entry.

Interfaces used

Interface	Path	Role
NR-Uu	UE <-> gNB	Carries the suspend command and defines the transition out of connected mode.
N2	gNB <-> AMF	Supports the broader reachability model once the UE is no longer actively connected.

End-to-End Call Flow

UE                    gNB                    AMF
|                     |                       |
|<- RRC Suspend ------|                       |
|==== UE enters RRC Inactive ====|           |
|<----------- later Paging if needed --------|
|-- RRC Resume when service returns -------->|

Major Phases

Phase	What happens
1. Inactive-state suitability decision	The network decides that full connected mode is no longer needed but fast return should remain possible.
2. Suspend delivery	The gNB tells the UE to leave connected mode while keeping resumable context.
3. Inactive-state monitoring	The UE becomes reachable through paging and can later use resume instead of full setup.

Step-by-Step Breakdown

Network chooses inactive entry instead of full release

Sender -> receiver: gNB internal policy and traffic evaluation

Message(s): Inactivity decision and context-preservation choice

Purpose: Balance low signaling overhead with quick future return to service.

State or context change: The UE is still connected, but the network is preparing an inactive-state transition.

Note: Suspend is most useful for bursty traffic patterns where full setup each time would be inefficient.

gNB sends suspend information

Sender -> receiver: gNB -> UE

Message(s): RRC Suspend

Purpose: Tell the UE to enter inactive state and preserve the identifiers needed for resume.

State or context change: Active radio resources are removed, but resumable context remains.

Note: If the suspend context is not preserved correctly, the later failure often appears during resume rather than here.

UE enters inactive reachability mode

Sender -> receiver: UE internal transition

Message(s): Paging monitoring and stored-context behavior

Purpose: Stay reachable with lower overhead until service is needed again.

State or context change: The UE is no longer connected, but not forced into a full fresh-setup model for the next return.

Note: The health of suspend is really proven later by a successful RRC Resume.

Important Messages in This Flow

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
RRC Suspend	RRC	gNB -> UE	Moves the UE from connected mode into inactive state while keeping resumable context.	Inspect whether the intended inactive behavior is consistent with the later resume path.
Paging	RRC	Network -> UE	Common next-step signal that wakes the UE from inactive reachability.	Use it to confirm that the post-suspend reachability model works.
RRC Resume	RRC	UE <-> gNB	Validates that the preserved suspend context was actually useful.	If resume fails, revisit what happened during suspend and context storage.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
Inactive-state eligibility	Whether the UE and network support suspend-based handling for this scenario.	Suspend decision logic	Explains why the network chose suspend rather than full release.	Wrong assumptions about eligibility can misread normal release behavior.
Resume identity	Stored identifier used later for RRC Resume.	Suspend context	Critical for fast connected-mode return.	Bad or stale identity leads to later resume failure.
Paging reachability settings	How the UE will be located after entering inactive state.	Post-suspend context	Needed for mobile-terminated traffic during inactive operation.	Wrong reachability configuration causes later paging misses.
Traffic pattern suitability	How bursty or intermittent the service really is.	Operational context	Helps justify whether suspend is actually the right optimization.	Bad fit creates churn between suspend and resume.
Stored context lifetime	How long the preserved inactive context remains usable.	gNB context handling	Explains whether later resume should work or not.	Context expiry often surprises troubleshooting teams.

Success Criteria

The UE enters inactive state with valid resumable context.
Radio resources are reduced without losing reachability.
Paging still works while the UE is inactive.
Later resume succeeds with lower latency than fresh setup.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
Suspend seems successful but resume later fails	The stored context was not preserved or was no longer usable.	Suspend context details and later resume identity matching.	RRC Suspend and later Resume Request	NR-Uu	Suspend quality is often judged by the later resume result.
UE enters churn between suspend and resume	The traffic pattern or policy is causing too many state changes.	Timer settings, application behavior, and resume success rate.	RRC Suspend, RRC Resume	NR-Uu	This is usually a tuning issue, not a decoder issue.
Mobile-terminated traffic is slow after suspend	Paging or reachability behavior after inactive entry is not optimal.	Paging timing, DRX behavior, and later service restoration.	Paging and Resume	NR-Uu, N2	Look at the full paging-to-service chain.
The network should have released, not suspended	Inactive optimization was chosen for a scenario that does not benefit from preserved context.	Traffic pattern and later resume usefulness.	Suspend decision behavior	Operational policy	This is a design or tuning issue rather than a single protocol error.

What to Check in Logs and Traces

Confirm why the network chose suspend instead of full release.
Track whether the created resume identity is later used successfully.
Inspect paging behavior after inactive entry rather than stopping at the state transition.
If churn exists, compare traffic pattern with the suspend policy choice.

Related sub-procedures

Related message reference pages

5G Paging

Related troubleshooting pages

FAQ

What is 5G RRC Suspend?

It is the procedure that moves a UE from connected mode into inactive state while preserving resumable context.

How is it different from RRC Release?

Suspend preserves context for faster return, while release is the broader connected-mode exit path without the same inactive-state optimization focus.

When is Suspend useful?

It is most useful for bursty traffic patterns where the UE needs to return to service quickly and often.

How do I know suspend worked well?

The best proof is a later clean RRC Resume and good paging responsiveness.

What should I inspect first when resume fails?

Check whether the suspend-created identity and stored context should still have been valid.