Home / Call Flows / 5G / RRC Inactive Resume with Mobility Context Change

RRC Inactive Resume with Mobility Context Change Call Flow

call-flow 5G NR | RRC Inactive | Resume | Mobility Context

RRC Inactive Resume with Mobility Context Change is the resume branch used when a UE returns from inactive state but the mobility context it expected to reuse no longer fully matches reality.

The core engineering question is whether the network can adapt the resume cleanly instead of letting the stale context break service restoration.

Introduction

This page focuses on the harder resume case where the UE is not starting from scratch, but also cannot rely on the old inactive assumptions as-is.

In troubleshooting, compare the stored inactive context, the changed serving reality, the resume outcome, and the first packets after service restoration.

What Is RRC Inactive Resume with Mobility Context Change in Simple Terms?

What starts the procedure: The UE in RRC Inactive needs service again after its mobility context changed.
What the UE and network want to achieve: Resume service cleanly without full failure recovery.
What success looks like: The UE resumes and real service works under the updated context.
What failure means: The old inactive assumptions are too stale and the resume branch cannot deliver stable service.

Why this procedure matters

This is one of the easiest 5G recovery branches to misread because it looks similar to ordinary resume until the changed mobility context starts breaking the expected reuse path.

Quick Fact Sheet

Procedure name	RRC Inactive Resume with Mobility Context Change
Domain	5G RRC Inactive recovery with changed mobility context
Main trigger	UE returns from RRC Inactive after mobility context changed while inactive
Start state	UE has inactive-state context, but serving mobility assumptions are no longer the same as before
End state	UE resumes active service under the updated mobility context without full recovery failure
Main nodes	UE, last known serving gNB, new serving gNB or target context, AMF
Main protocols	RRC Resume, context lookup, mobility-aware resume handling, service restoration
Main success outcome	UE resumes service successfully even though the inactive mobility context had changed
Main failure outcome	Resume branch fails because stale inactive assumptions no longer match the current mobility reality
Most important messages	RRC Resume Request, RRC Resume, RRC Resume Complete, Service Request when needed
Main specs	TS 38.331, TS 23.502, TS 38.300

RRC Inactive Resume with Mobility Context Change procedure flow

Preconditions

The UE previously entered RRC Inactive with reusable context.
Service is needed again before that stored context became fully invalid.
Some serving or mobility assumption changed while the UE was inactive.
The network can still attempt a context-aware resume instead of immediate full new access.

Nodes and Interfaces

Nodes involved

Node	Role in this procedure
UE	Attempts to resume service from RRC Inactive using previously stored context.
Resume-serving node	Tries to honor the resume request under the changed mobility conditions.
Prior serving context	Represents the older inactive assumptions that may now be stale.
AMF	Supports service restoration and mobility continuity where needed.

Interfaces used

Interface	Path	Role
NR-Uu	UE <-> serving node	Carries the resume attempt and later active service.
N2	gNB <-> AMF	Aligns resumed service with updated mobility context.

End-to-End Call Flow

UE                Serving Node              AMF
|                     |                        |
|-- RRC Resume Request ----------------------->|
|                     |.. mobility context changed ..|
|<-- RRC Resume -------------------------------|
|-- RRC Resume Complete ---------------------->|
|==== traffic resumes under updated context ==>|

Major Phases

Phase	What happens
1. Inactive UE needs service again	The UE tries to return to active service from RRC Inactive.
2. Resume request under changed context	The network detects that mobility assumptions changed while the UE was inactive.
3. Resume adaptation or recovery	The serving side tries to honor or repair the resume path under the new context.
4. Resume completion and service validation	The UE resumes and traffic is checked under the updated mobility state.
5. Stable post-resume mobility state	The UE continues active service without falling back into broader failure recovery.

Step-by-Step Breakdown

The UE attempts to resume from inactive state

Sender -> receiver: UE -> serving node

Message(s): RRC Resume Request

Purpose: Restore active service using the stored inactive context.

State or context change: The network starts by assuming the previous inactive context may still be reusable.

Note: This differs from fresh access because the UE expects context reuse first, not full new setup.

The serving side realizes the mobility context has changed

Sender -> receiver: Serving node and mobility logic

Message(s): Resume-context lookup and mobility reconciliation

Purpose: Figure out whether the stored inactive assumptions still fit the UE’s current location and serving conditions.

State or context change: The resume branch becomes mobility-sensitive rather than a straightforward reuse case.

Note: This is the heart of the procedure and the main reason the flow is harder than ordinary resume.

The network adapts the resume path

Sender -> receiver: Serving node <-> AMF as needed

Message(s): RRC Resume

Purpose: Resume service while aligning the UE to the updated mobility context.

State or context change: The UE gets a resume outcome that reflects current serving reality rather than stale stored assumptions.

Note: If the adaptation cannot be made cleanly, the resume branch often degrades into broader recovery behavior.

The UE confirms resumed service

Sender -> receiver: UE -> serving node

Message(s): RRC Resume Complete

Purpose: Confirm active service was restored successfully under the updated context.

State or context change: The inactive UE becomes active again.

Note: Resume Complete is the main control-plane success point, but traffic still must be checked.

Traffic validates the resumed path

Sender -> receiver: UE <-> user plane

Message(s): First packets after resume

Purpose: Prove that the updated mobility context still allows real service to continue.

State or context change: The resume branch ends in stable active service.

Note: A resume that completes but carries no usable service is still only a partial success.

Important Messages in This Flow

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
RRC Resume Request	RRC	UE -> serving node	Starts the inactive-to-active return using stored context.	Primary trigger for the branch.
RRC Resume	RRC	Serving node -> UE	Carries the resumed service outcome under the changed context.	Key adaptation point of the procedure.
RRC Resume Complete	RRC	UE -> serving node	Confirms successful control-plane resume.	Main control-plane success signal.
First resumed packets	User plane	UE <-> network	Validate real service under the updated mobility state.	Best final proof of success.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
Stored inactive context	What the UE expected to reuse.	Resume Request and context lookup	Defines the baseline assumption of the resume branch.	Important to compare against the new reality.
Changed mobility condition	What is now different from the earlier inactive assumption.	Resume reconciliation stage	Explains why ordinary resume is no longer simple.	This is the main root-cause area.
Resume outcome	Whether the network could honor the resume cleanly.	Resume and Resume Complete	Main control-plane result.	Not enough by itself without service validation.
Post-resume traffic	Whether the UE can actually use service after resume.	Validation stage	Best indicator of real success.	A common hidden failure point.

Success Criteria

The stored inactive context is reconciled with current mobility reality.
The UE receives a usable resume outcome rather than failing into broader recovery.
Resume Complete is reached cleanly.
Traffic works under the updated serving context afterward.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
Stored inactive context is too stale	The UE tries to resume against assumptions that no longer match serving reality.	Resume Request and mobility reconciliation.	Context lookup stage	RRC / mobility logic	This is the defining failure mode of the procedure.
Resume completes poorly under changed conditions	The control plane restores, but service quality or usability is weak afterward.	Resume Complete plus first packets.	Validation stage	User plane	Treat this as a real resume problem, not a clean success.
The branch falls into broader recovery	The mobility-aware resume path cannot be honored cleanly.	Absence of smooth resume and later recovery behavior.	Post-failure branch	RRC	This shows the resume path broke under the changed context.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

FAQ

What is RRC Inactive Resume with Mobility Context Change?

It is the resume procedure used when the UE returns from inactive state but the serving mobility context changed while it was inactive.

Why is it harder than ordinary RRC Resume?

Because the network must reconcile stored inactive assumptions with the UE’s current mobility reality.

What proves success?

The UE resumes active service and real traffic works afterward under the updated context.

What should I inspect first?

Start with the stored inactive context, then what changed during inactivity, then the Resume Request and first packets.