5G RRC Release Procedure Call Flow

call-flow 5G NR | RRC | State Control | Paging | Resource Release

5G RRC Release is the procedure that ends an active connected-state radio session when the network no longer needs to keep dedicated radio resources allocated.

It is where a UE leaves active radio handling and returns to a reachability model based on paging, resume, or fresh setup later.

Introduction

This procedure is normal and useful, but it is also a common place where engineers first notice bad timer tuning or poor return-to-service behavior.

That is why release should be read together with what happens next: paging, RRC Resume, or a new RRC Setup.

What Is RRC Release in Simple Terms?

What starts the procedure: The network decides active connected-mode radio resources are no longer required.
What the UE and network want to achieve: End dedicated radio use while keeping the UE reachable for future service.
What success looks like: The UE exits connected mode cleanly and can later return to service when needed.
What failure means: Release happens prematurely or the later reachability and recovery path does not work.

Why this procedure matters

RRC Release is a state-control checkpoint, not just a teardown message. It strongly influences latency, paging success, service continuity perception, and how often the network must rebuild access later.

Quick Fact Sheet

Procedure name	5G NR RRC Release Procedure
Domain	5G NR connected-state exit and radio resource cleanup
Main trigger	The network decides the active RRC connection is no longer needed or wants the UE to leave connected mode
Start state	UE is in RRC Connected with active or recently active context
End state	UE leaves connected mode and moves to idle or inactive behavior depending on the release design
Main nodes	UE, gNB, optionally AMF as part of the broader service state
Main protocols	RRC, NGAP, paging context
Main success outcome	Radio resources are released cleanly and the UE transitions into the intended lower-activity state
Main failure outcome	Release comes unexpectedly, the UE cannot continue service afterward, or repeated setup loops follow
Most important messages	RRC Release, Paging, later RRC Resume or RRC Setup
Main specs	TS 38.331, TS 38.300, TS 23.502

Preconditions

The UE is already in connected mode.
The network believes active radio resources can be reduced safely.
Later reachability methods such as paging remain available.
The service pattern permits leaving connected mode or the network accepts the tradeoff.

Nodes and Interfaces

Nodes involved

Node	Role in this procedure
UE	Receives the release, applies the new lower-activity behavior, and later follows paging or fresh access procedures if needed.
gNB	Decides that the connected-state radio context should be released and signals the state change to the UE.
AMF	May indirectly influence the later reachability model through paging and service-restoration behavior after release.

Interfaces used

Interface	Path	Role
NR-Uu	UE <-> gNB	Carries the release command and the last connected-state radio exchange.
N2	gNB <-> AMF	Carries the access-side context impact of moving the UE away from connected mode.

End-to-End Call Flow

UE                    gNB                    AMF
|                     |                       |
|<- RRC Release ------|                       |
|==== Connected mode ends ====|              |
|<----------- later Paging if needed --------|
|-- Resume or fresh Setup when service returns -->

Major Phases

Phase	What happens
1. Connected-mode inactivity or policy decision	The network decides that the UE no longer needs active radio resources.
2. Release delivery	The gNB sends the release command and the UE exits connected mode.
3. Reachability transition	The UE returns to idle or inactive-style behavior and later depends on paging, resume, or fresh setup.

Step-by-Step Breakdown

Network decides to end active radio use

Sender -> receiver: gNB internal logic

Message(s): Inactivity timer expiry, policy action, session-completion logic, or mobility optimization

Purpose: Free active radio resources when the UE no longer needs continuous connected-mode handling.

State or context change: The UE is still connected, but the network is preparing a state reduction.

Note: Unexpected release often reflects timer policy or service inactivity, not necessarily a fault in itself.

gNB sends RRC Release

Sender -> receiver: gNB -> UE

Message(s): RRC Release

Purpose: Tell the UE to leave connected mode and apply the post-release behavior.

State or context change: The active connected-state radio leg is torn down.

Note: Check whether the release was expected by the service lifecycle or arrived while traffic was still needed.

UE enters a lower-activity reachability state

Sender -> receiver: UE internal transition

Message(s): Post-release cell camping or inactive-style reachability behavior

Purpose: Continue conserving resources while remaining reachable for future service.

State or context change: The next access event will depend on paging, resume, or fresh setup.

Note: When users complain about dropped sessions, the real question is whether the release happened too early or the later recovery path failed.

Important Messages in This Flow

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
RRC Release	RRC	gNB -> UE	Ends the active connected-state radio leg.	Inspect release timing, linked inactivity logic, and the intended post-release state.
Paging	RRC	Network -> UE	May be the next major event after release when downlink service is needed again.	Use it to understand whether reachability still works after release.
RRC Resume or RRC Setup	RRC	UE <-> gNB	Represents the later recovery path back into active service.	A release issue may only become visible when the UE tries to return to active mode.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
Inactivity timer	How long the network waits before releasing connected mode.	gNB policy and release timing	Explains whether the release was expected or overly aggressive.	Short timers can create repeated setup or resume churn.
Release reason or policy context	The operational reason behind the release.	Release decision logic	Separates normal cleanup from suspicious early release.	If absent from logs, engineers may misread normal behavior as failure.
Post-release state behavior	Whether the UE should behave more like idle or preserve faster return capability.	Release handling and later trace behavior	Predicts whether paging, resume, or setup should follow.	Wrong expectation here causes confusing troubleshooting later.
Paging reachability context	How the network will find the UE after release.	AMF and gNB context after release	Critical for mobile-terminated traffic after connected mode ends.	Stale TAC or wrong reachability data leads to later paging failure.
Service continuity expectation	Whether user traffic was really complete when release occurred.	Application, session, and access traces	Helps decide whether the release was correct or premature.	Premature release can look like intermittent app failure.

Success Criteria

Release occurs at the right service moment rather than during needed traffic.
The UE transitions cleanly into lower-activity reachability behavior.
Later paging or service return works without abnormal delay or repeated failures.
The network reduces radio overhead without harming the user journey.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
Release happens too early	The network exits connected mode while the service still needed stable access.	Timer policy, traffic pattern, and session continuity expectations.	RRC Release and later traffic interruption	NR-Uu, N2, N3	This often appears as user-plane instability rather than a raw RRC defect.
UE cannot recover after release	The later paging, resume, or setup path is broken.	Post-release reachability and the next access attempt.	Paging, RRC Resume, RRC Setup	NR-Uu, N2	Do not blame the release message alone if the real fault is in return-to-service handling.
Frequent release and reconnect loops	Timer tuning or service pattern mismatch is causing churn.	Release interval, resume success, and application behavior.	RRC Release and repeated follow-on access	NR-Uu	This is often a policy-optimization issue rather than a protocol decode issue.
Mobile-terminated traffic is missed after release	The network released correctly but lost effective reachability afterward.	Paging context, UE camping behavior, and TA alignment.	Paging after release	N2, NR-Uu	Track the full paging-to-service journey, not only the release point.

What to Check in Logs and Traces

Correlate the release with actual traffic inactivity rather than assuming it was premature.
Inspect the next event after release: paging, resume, or fresh setup.
If churn exists, compare inactivity timer policy with the real app traffic pattern.
Treat user complaints after release as an end-to-end reachability question, not a single-message question.

Related sub-procedures

Related message reference pages

5G Paging

Related troubleshooting pages

FAQ

What is 5G RRC Release?

It is the procedure that ends the active connected-state radio leg and returns the UE to a lower-activity reachability state.

Does RRC Release always mean the UE goes to idle?

Not always. The exact operational behavior depends on how the network manages post-release reachability.

Is RRC Release always bad?

No. It is a normal resource-optimization procedure when active service is no longer needed.

What should I inspect if users see intermittent drops?

Check whether release happened too early and whether the later paging or service-restoration path worked.

How is RRC Release different from RRC Suspend?

Suspend is designed around inactive-state context preservation for faster resume, while release is the broader connected-mode exit procedure.