Home / Call Flows / LTE / RRC Re-establishment Procedure

LTE RRC Re-establishment Procedure Call Flow

call-flowLTE | E-UTRAN | RRC

LTE RRC Re-establishment is the recovery branch used when the UE loses the current connected radio path but still tries to restore the connection without starting a completely fresh access attempt. It is built around RRC Connection Reestablishment Request, RRC Connection Reestablishment, and RRC Connection Reestablishment Complete.

If this branch fails, the UE usually falls back to release, idle return, or a fresh setup attempt.

Introduction

The LTE RRC Re-establishment procedure restores the radio-control path after radio link failure, handover-related break, or similar context disruption. It is a recovery procedure, not a normal access entry procedure.

The main nodes are the UE and eNB. The earlier context matters because the request references the lost connection rather than starting from zero.

What Is LTE RRC Re-establishment in Simple Terms?

What starts the procedure: The UE loses the connected radio path and tries to recover it.
What the UE and network want to achieve: Restore the radio connection quickly enough to continue later signaling.
What success looks like: The UE sends Reestablishment Request, the eNB returns Reestablishment, and the UE confirms with Reestablishment Complete.
What failure means: The request is rejected, the restore branch does not complete, or the UE falls back to fresh access.

Why this procedure matters

This branch explains why some failures recover without a full new attach or service entry path, and why others collapse back to idle behavior.

Quick Fact Sheet

Procedure name	LTE RRC Re-establishment Procedure
Domain	Radio recovery after connected-path failure
Main trigger	Radio link failure, handover-related break, or similar connected-path loss
Start state	UE had a connected context but the active radio path is no longer stable
End state	Connected radio signaling is restored or the UE falls back to another branch
Main nodes	UE, eNB
Main protocols	RRC
Main success outcome	Re-establishment completes and later signaling can continue
Main failure outcome	Re-establishment is rejected or abandoned and recovery moves elsewhere
Most important messages	RRC Connection Reestablishment Request, RRC Connection Reestablishment, RRC Connection Reestablishment Complete
Main specs	TS 36.331, TS 36.300

LTE RRC Re-establishment procedure call flow across UE and eNB — Click the diagram to open the full-size in a new tab.

Preconditions

The UE had a valid earlier connected context.
The failure scenario still allows re-establishment rather than immediate fresh setup.
The eNB can map the request to a recoverable earlier context.

Nodes and Interfaces

Nodes involved

Node	Role in this procedure
UE	Detects the break, sends the recovery request, and confirms restore success if accepted.
eNB	Decides whether the earlier context can be recovered and either restores or rejects it.

Interfaces used

Interface or channel context	Path	Why it matters here
LTE Uu	UE <-> eNB	Carries the full recovery branch.
CCCH / DCCH transition	UE <-> eNB	Shows the move from early recovery signaling into restored dedicated control.

End-to-End Call Flow

UE                          eNB
|                            |
|-- Reestablishment Request ->|
|                            |
|<- Reestablishment ---------|
|                            |
|-- Reestablishment Complete ->|
|                            |
|   later resumed signaling   |

Major Phases

Phase	What happens
1. Failure detection	The UE detects loss of the connected radio path.
2. Recovery request	The UE asks the eNB to restore the earlier context.
3. Context restoration	The eNB either restores the context or rejects the recovery attempt.
4. Completion	The UE confirms the restored branch if recovery succeeded.

Step-by-Step Breakdown

Step 1: Failure detected

Sender -> receiver: UE internal processing

Message(s): No RRC message yet

Purpose: Decide whether recovery through re-establishment is possible.

State or context change: The connected branch is no longer stable enough for normal continuation.

Note: This is usually the first point where radio link failure becomes operationally important.

Step 2: Reestablishment Request

Sender -> receiver: UE -> eNB

Message(s): RRC Connection Reestablishment Request

Purpose: Ask the eNB to recover the earlier radio context.

State or context change: The eNB now decides whether the request matches a recoverable connection.

Note: Cause and earlier context relation are the most useful checks.

Step 3: Reestablishment or reject

Sender -> receiver: eNB -> UE

Message(s): RRC Connection Reestablishment or RRC Connection Reestablishment Reject

Purpose: Accept or deny the recovery branch.

State or context change: The UE either moves into restoration or falls back to another recovery path.

Note: A reject usually means the earlier context was no longer usable.

Step 4: Reestablishment Complete

Sender -> receiver: UE -> eNB

Message(s): RRC Connection Reestablishment Complete

Purpose: Confirm that the recovered branch is usable.

State or context change: Later dedicated signaling can continue through the restored branch.

Note: This is the best proof that recovery succeeded formally.

Important Messages in This Flow

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
RRC Connection Reestablishment Request	RRC	UE -> eNB	Starts the recovery branch.	Failure cause and earlier context relation.
RRC Connection Reestablishment	RRC	eNB -> UE	Restores the radio path.	Whether the restore branch was really accepted.
RRC Connection Reestablishment Complete	RRC	UE -> eNB	Confirms formal recovery completion.	Completion timing and later continuation.
RRC Connection Reestablishment Reject	RRC	eNB -> UE	Rejects the recovery branch.	Whether the UE must move to fresh access instead.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
Re-establishment cause	The reason the UE gives for the recovery attempt.	Reestablishment Request	Explains whether the branch is due to radio failure, handover failure, or another recovery trigger.	Wrong scenario assumption.
Earlier context reference	The identity relation to the lost connection.	Reestablishment Request	Lets the eNB decide whether recovery is possible.	Stale or mismatched context.
Completion continuity	The first later message after Reestablishment Complete.	After recovery completes	Confirms that the restored branch remained usable.	Formal recovery succeeded, but later signaling still breaks.

Successful Completion

Success means the eNB accepts the recovery branch and the UE returns RRC Connection Reestablishment Complete with stable later signaling.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
Request appears, but no accept returns	The earlier context is no longer recoverable.	Context relation and later fallback behavior.	Reestablishment Request	LTE Uu	Check whether the UE moved into fresh setup.
Reject branch appears	The network cannot restore the lost context.	Reject timing and next access branch.	Reestablishment Reject	LTE Uu	Move into fresh-access analysis.
Complete is missing	The UE could not finish the restored branch or uplink transport failed again.	Restore content and radio stability right after acceptance.	Reestablishment, Reestablishment Complete	LTE Uu	Treat it as incomplete recovery.

What to Check in Logs and Traces

Confirm that the scenario really used recovery rather than fresh setup.
Inspect the re-establishment cause first.
Check whether the branch ended with Reestablishment Complete or fallback to another path.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

Notes

Re-establishment is a recovery branch, not a fresh-entry branch. The message set is the quickest way to separate the two.

FAQ

What is LTE RRC Re-establishment?

It is the radio recovery procedure used after loss of the connected path.

What confirms success?

RRC Connection Reestablishment Complete is the main success checkpoint.

What happens if recovery fails?

The UE usually falls back to another branch such as fresh setup or idle return.