Home / Call Flows / LTE / LTE SCG Failure Information Procedure

LTE SCG Failure Information Procedure Call Flow

call-flow LTE | Failure | Troubleshooting

LTE SCG Failure Information Procedure is the LTE failure-handling branch used when a procedure cannot continue normally and the network or UE has to reject, report, or classify the problem.

This page focuses on the failure path itself rather than the earlier success flow that should have happened before it.

Introduction

SCG Failure Information is the LTE report used when the secondary cell group has failed and the UE later returns that failure context to the network.

Use this page when the secondary branch failed and the main question is whether the UE later reported that failure clearly.

What Is LTE SCG Failure Information Procedure in Simple Terms?

What starts the procedure: The UE detects a secondary cell group failure and later reports it back to the controlling side.
What the UE and network want to achieve: Return clear UE-side evidence that the SCG branch failed.
What success looks like: The UE sends SCG Failure Information and it lines up with the earlier SCG-side break.
What failure means: The SCG branch failed, but the later report is missing or is not tied back to the right earlier event.

Why this procedure matters

Secondary-branch failures can be easy to miss if the master side stays alive. This report is often the cleanest proof that the SCG branch really broke.

Quick Fact Sheet

Procedure name	LTE SCG Failure Information Procedure
Domain	LTE secondary cell group failure reporting
Main trigger	The UE detects a secondary cell group failure and later reports it back to the controlling side.
Start state	A wider LTE procedure is already in progress and something has gone wrong or become invalid
End state	The network receives a UE-side SCG failure report for the failing secondary branch
Main nodes	UE, eNB, MME / network side
Main protocols	RRC, NAS, procedure context
Main success outcome	The failure branch is clearly identified and the next corrective action is possible
Main failure outcome	The real break point stays unclear or the wrong failure branch is assumed
Most important messages	SCG Failure Information r12
Main specs	TS 36.331

LTE SCG Failure Information Procedure — Click the diagram to open the full-size in a new tab.

Preconditions

A wider LTE procedure is already underway or has just failed.
The network and UE still have enough context to reject, report, or classify the failure.
The trace includes the messages immediately before and after the failure branch.

Nodes and Interfaces

Nodes involved

Node	Role in this procedure
UE	Detects the condition, rejects the invalid branch, or reports failure context after the earlier problem.
eNB	Carries the LTE radio side and receives failure or reject behavior from the UE.
MME / network side	Interprets the reject, timeout, or failure report and decides the next correction or release step.

Interfaces used

Interface	Path	Role
LTE Uu	UE <-> eNB	Carries the reject or failure-report signaling seen on the radio side.
S1-MME	eNB <-> MME	Carries the wider procedure context behind the failure or reject branch.

End-to-End Call Flow

UE                   network side
|--SCG branch fails----|
|--later report------->|
|--SCG Failure Info---->|

Major Phases

Phase	What happens
1. SCG branch failure	The secondary cell group side breaks first.
2. Later report opportunity	The UE becomes able to send the SCG failure report.
3. UE-side failure upload	SCG Failure Information is sent.

Step-by-Step Breakdown

Step 1: Track the earlier SCG break

Sender -> receiver: UE and network side

Message(s): Earlier SCG-side failure branch

Purpose: Identify the branch that actually failed before the later report appears.

State or context change: The SCG side is already in trouble before the report is sent.

Note: This is the context that gives the later SCG report its value.

Step 2: Reach report readiness

Sender -> receiver: UE

Message(s): Later failure reporting readiness

Purpose: Reach a state where the UE can send the SCG failure report.

State or context change: The UE can now return explicit SCG-side evidence.

Note: The report does not replace the earlier failure; it explains it.

Step 3: Send SCG Failure Information

Sender -> receiver: UE -> network side

Message(s): SCG Failure Information r12

Purpose: Return explicit evidence that the SCG branch failed.

State or context change: The network now has a direct UE-side SCG failure message.

Note: This is often the cleanest proof that the secondary branch was the real failure point.

Important Messages

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
SCG Failure Information r12	RRC	UE -> network side	Reports the SCG-side failure after the earlier break.	Check the timing against the earlier secondary-branch failure.
Failure Information r15	RRC	UE -> network side	Useful comparison message when the failure path also reports a more generic later failure.	Check whether SCG-specific reporting or generic failure reporting best explains the event.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
SCG branch identity	The secondary branch that failed.	Earlier branch and later report	Shows which secondary-side context the report belongs to.	The wrong secondary branch is assumed.
Report timing	The gap between the SCG failure and the later report.	SCG Failure Information arrival	Useful when the report appears later than the visible radio issue.	The later report is treated as unrelated because of timing.
Secondary-side evidence	What the message says about the SCG failure.	SCG Failure Information payload	Explains why the message is the key SCG evidence point.	The report is found but not actually read against the earlier SCG event.
Master-side continuity	Whether the main branch stayed alive while SCG failed.	Wider dual-branch context	Important because SCG failure can hide under a still-working main branch.	The overall connection looks alive, so the SCG failure is missed.
Subsequent recovery action	What the network did after the SCG report.	Later messages	Shows whether the report led to release, recovery, or reconfiguration.	The report is identified, but later action is never checked.

Successful Completion

Success here means the SCG failure report is present and clearly tied to the earlier secondary-branch break.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
The secondary branch looks unstable, but no SCG failure report is found	The UE may not have reached a later reporting point, or the report was not captured.	The period after the visible SCG break.	Earlier SCG failure only	Dual-connectivity context	Do not assume the absence of the report means the SCG branch never failed.
SCG report is present, but the wrong branch is blamed	The earlier secondary-side failure was not correlated correctly.	Earlier secondary-side events and the report timing.	SCG Failure Information r12	LTE Uu	Correlate the report strictly with the failing SCG-side branch.

What to Check in Logs and Traces

Correlate the SCG report with the earlier secondary-branch problem.
Check whether the master side stayed alive while the SCG side failed.
Follow what the network did after receiving the SCG report.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

Notes

This page is about the SCG-specific failure report. The actual secondary-branch failure happens earlier and should be correlated first.

FAQ

What is LTE SCG Failure Information?

It is the UE-side LTE report used to tell the network that the secondary cell group failed.

Can the main branch stay alive while this report appears?

Yes. That is one reason this message is so useful in dual-branch analysis.