Home / Call Flows / LTE / LTE SCG Failure Recovery

LTE SCG Failure Recovery Call Flow

call-flow LTE | SCG Failure | Recovery | RRC

LTE SCG Failure Recovery is the recovery path used after the secondary cell group fails while the master side is still present.

The main trace anchors are SCG Failure Information r12, SCG Failure Information NR r15, and the follow-on reconfiguration or release behavior that decides whether the branch is recovered or removed.

Introduction

This procedure begins only after an SCG-capable context already existed. The UE reports the secondary-branch failure, and the master side decides whether to recover that branch, change it, or remove it.

The practical trace question is whether the branch failed because of the secondary side itself, because of an NR secondary branch under LTE master control, or because the wider master connection was already unstable.

What Is LTE SCG Failure Recovery in Simple Terms?

What starts the procedure: The UE detects failure on the secondary cell group after advanced connected-mode behavior was already active.
What the UE and network want to achieve: Keep the master connection alive while recovering or cleanly removing the failed secondary branch.
What success looks like: The branch is recovered or removed without losing the whole master connection.
What failure means: The branch remains unstable, recovery loops, or the wider connection degrades further.

Why this procedure matters

SCG recovery is one of the main places where advanced LTE traces become hard to read. The master link may look fine while the secondary branch repeatedly fails and reshapes the user experience underneath.

Quick Fact Sheet

Procedure name	LTE SCG Failure Recovery
Domain	Secondary branch recovery
Main trigger	UE reports SCG failure after dual-connectivity or related advanced branch use
Start state	Master connection is active and a secondary branch has failed
End state	Secondary branch is recovered, reconfigured, or released
Main nodes	UE, MeNB, SeNB
Main protocols	RRC, inter-node coordination
Main success outcome	Master connection survives and the failed branch is handled cleanly
Main failure outcome	Branch instability repeats or spreads into wider service impact
Most important messages	SCG Failure Information, RRC Connection Reconfiguration, RRC Connection Reconfiguration Complete
Main specs	TS 36.331, TS 36.300

LTE SCG Failure Recovery Call Flow — Click the diagram to open the full-size in a new tab.

Preconditions

A secondary branch was active earlier in the trace.
The UE can still report the failure to the master side.
The master connection remains available long enough for recovery or release action.

Nodes and Interfaces

Nodes involved

Node	Role in this procedure
UE	Maintains the master LTE connection and applies the added or changed secondary branch configuration.
MeNB / master eNB	Keeps the main LTE control anchor and decides when the secondary branch is added, changed, recovered, or removed.
SeNB / secondary node	Provides the secondary cell group resources used for extra throughput, split bearer handling, or EN-DC continuation.
Core transport	Carries the user-plane or control continuation behind bearer movement and branch release.

Interfaces used

Interface	Path	Role
LTE Uu	UE <-> MeNB / SeNB	Carries the LTE radio-control and user-plane behavior seen by the UE.
X2 / inter-node	MeNB <-> SeNB	Carries secondary-node preparation, coordination, and release handling.
S1-U / transport	eNB side <-> EPC	Carries the user-plane continuation behind bearer distribution and release.

End-to-End Call Flow

UE                  MeNB                  SeNB
|--SCG Failure------>|                        |
|                    |--recovery / release-->|
|<--RRC Reconfig-----|                        |
|--Reconfig Complete>|                        |

Major Phases

Phase	What happens
1. Detect and report failure	The UE detects that the secondary branch failed and reports it to the master side.
2. Choose the recovery branch	The master side decides whether to recover, reconfigure, or release the branch.
3. Apply the recovery action	The UE receives the connected-mode update that reflects the recovery decision.
4. Validate the outcome	The trace shows either stable fallback, successful branch return, or repeated failure.

Step-by-Step Breakdown

Report the failed secondary branch

Sender -> receiver: UE -> MeNB

Message(s): SCG Failure Information r12 or SCG Failure Information NR r15

Purpose: Expose the secondary-branch failure to the master side so the next action can be chosen.

State or context change: The connection is now in a branch-recovery state rather than in normal multi-branch continuation.

Note: This report is the main line between ordinary DC use and explicit SCG recovery handling.

Decide the recovery path

Sender -> receiver: MeNB -> SeNB / internal handling

Message(s): Recovery, branch change, or release decision

Purpose: Choose whether the failed branch should be rebuilt, changed, or removed.

State or context change: The network now has a specific response to the reported secondary-branch problem.

Note: Without this decision point, later reconfiguration can be hard to interpret.

Deliver the chosen action

Sender -> receiver: MeNB -> UE

Message(s): RRC Connection Reconfiguration

Purpose: Tell the UE how to continue after the secondary-branch failure.

State or context change: The UE moves toward recovered branch use or master-only fallback.

Note: The same reconfiguration container can mean recovery, simplification, or release depending on context.

Confirm the new state

Sender -> receiver: UE -> MeNB

Message(s): RRC Connection Reconfiguration Complete

Purpose: Confirm the UE applied the recovery or release action.

State or context change: The connection now continues in its post-failure branch design.

Note: If instability continues immediately, the branch probably was not truly recovered.

Important Messages

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
SCG Failure Information r12	RRC	UE -> MeNB	Reports LTE-side secondary branch failure.	Check the failure type and the exact advanced branch context that existed just before it.
SCG Failure Information NR r15	RRC	UE -> MeNB	Reports NR-side secondary branch failure under LTE master control.	Check whether the failure belongs to the NR secondary side rather than to LTE-only SCG context.
RRC Connection Reconfiguration	RRC	MeNB -> UE	Carries the chosen recovery, simplification, or release action.	Check whether the post-failure action rebuilt the branch or removed it.
MCG Failure Information r16	RRC	UE -> MeNB	Useful contrast when the issue is broader than SCG-only failure.	Check whether the trace also shows master-side failure and not only secondary-branch trouble.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
Failure family	Whether the failed branch is LTE-side SCG, NR-side SCG, or broader MCG behavior.	Failure report	Keeps recovery analysis on the correct branch family.	The wrong branch is recovered because the failure family was misread.
Pre-failure branch state	The exact branch design that existed before the report.	Immediately before failure reporting	Explains what the network is trying to recover or remove.	The branch is treated as if it had already changed before the failure.
Recovery action type	Whether the network tried branch rebuild, branch simplification, or full release.	Post-failure reconfiguration	Explains the meaning of the follow-on reconfiguration.	A release action is misread as a recovery action or the reverse.
Post-recovery stability	Whether the new state held after recovery or fallback.	After reconfiguration complete	Shows whether the branch problem was really resolved.	The trace stops before proving whether recovery actually worked.
Master-link continuity	Whether the master branch stayed healthy during SCG recovery.	Across the whole recovery window	Separates SCG-only failure from broader connection collapse.	A master-link issue is hidden under SCG-only analysis.

Successful Completion

Success means the SCG failure is handled without losing the whole master connection, either by stable recovery or by clean fallback to a simpler branch design.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
Recovery action is sent but failure repeats quickly	The branch problem was not truly corrected, or the wrong branch family was targeted.	Failure report type, reconfiguration intent, and the next stability window.	SCG Failure Information r12, SCG Failure Information NR r15, RRC Connection Reconfiguration	LTE Uu	Check whether the next failure matches the same branch or a newly changed one.
SCG recovery looks reasonable but service still collapses	The master side may also be unstable, or the bearer path may not tolerate the fallback.	MCG signs, bearer behavior, and the full post-failure period.	MCG Failure Information r16, later reconfiguration	LTE Uu, transport	Expand the analysis beyond SCG-only recovery.

What to Check in Logs and Traces

Use the first failure report as the recovery anchor.
Separate LTE-side SCG failure, NR-side SCG failure, and master-side failure before reading the follow-on action.
Check whether the post-recovery state really held after reconfiguration complete.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

Notes

SCG recovery should always be read together with the pre-failure branch design. Without that context, the recovery action is easy to misclassify.

FAQ

What starts LTE SCG Failure Recovery?

It starts when the UE reports that the secondary branch failed while the master side is still present.

Does SCG failure always mean the whole LTE connection is lost?

No. Many traces keep the master connection alive and only recover or remove the secondary branch.