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

LTE NR SCG Failure Information Call Flow

call-flow LTE | Failure | Troubleshooting

LTE NR SCG Failure Information 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

NR SCG Failure Information is the LTE-side report used when the failing secondary branch is specifically on the NR side. It is the dual-connectivity failure-report page for an NR secondary context.

Use this page when the LTE master side still exists, but the NR secondary branch has failed and the UE later reports that failure explicitly.

What Is LTE NR SCG Failure Information in Simple Terms?

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

Why this procedure matters

NR secondary failures can look like vague EN-DC instability unless the report is tied properly to the earlier NR-side break. This message is often the cleanest proof.

Quick Fact Sheet

Procedure name	LTE NR SCG Failure Information
Domain	LTE-to-NR secondary branch failure reporting
Main trigger	The UE detects failure on the NR secondary cell group side and later reports it to the LTE master side.
Start state	A wider LTE procedure is already in progress and something has gone wrong or become invalid
End state	The LTE master side receives a UE-side report about the failing NR 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 NR r15
Main specs	TS 36.331

LTE NR SCG Failure Information — 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                    LTE master side
|--NR SCG fails--------|
|--later report------->|
|--SCG Failure Info NR->|

Major Phases

Phase	What happens
1. NR secondary failure	The NR-side secondary branch breaks first.
2. Later report opportunity	The UE reaches a point where reporting is possible.
3. NR SCG failure upload	The UE reports the NR-side failure back to LTE master side.

Step-by-Step Breakdown

Step 1: Track the earlier NR secondary break

Sender -> receiver: UE and LTE master side

Message(s): Earlier NR-side secondary failure branch

Purpose: Identify the NR-side break before the later report appears.

State or context change: The NR SCG is already failed before the report is sent.

Note: This earlier branch is what makes the later report meaningful.

Step 2: Regain reporting ability

Sender -> receiver: UE

Message(s): Later reporting readiness

Purpose: Reach a state where the UE can send explicit NR SCG failure evidence.

State or context change: The UE can now return the NR-secondary failure report.

Note: Not every NR-side issue produces an immediate report; timing matters.

Step 3: Send the NR SCG report

Sender -> receiver: UE -> LTE master side

Message(s): SCG Failure Information NR r15

Purpose: Tell the LTE master side that the NR secondary branch failed.

State or context change: The master side now has direct UE-side evidence about the failing NR branch.

Note: This is often the strongest UE-side proof that the NR side was the actual problem.

Important Messages

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
SCG Failure Information NR r15	RRC	UE -> LTE master side	Reports NR-secondary failure to the LTE master side.	Check the timing against the earlier NR-side instability or break.
MCG Failure Information r16	RRC	UE -> LTE master side	Useful comparison if the master side also later shows a separate failure report.	Check whether the problem stayed on the NR-secondary side or spread to the master side.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
NR secondary branch identity	The exact NR-side branch that failed.	Earlier event and later report	Shows which NR side the report belongs to.	The report is correlated to the wrong secondary branch.
Report timing	The gap between the NR-side failure and the later report.	NR SCG report timing	Useful when the report appears well after the visible NR problem.	The later report is assumed unrelated.
Master-side continuity	Whether the LTE master side stayed alive through the NR failure.	Dual-connectivity context	Important because the master side may look stable while the NR branch fails.	The stable master side hides the NR failure.
NR-specific evidence	What the message says about the NR-side failure.	SCG Failure Information NR payload	Explains why this report is the strongest NR-specific evidence point.	The report is present but not used to classify the failure correctly.
Subsequent correction path	What the network did after the report arrived.	Later messages	Shows whether the report led to release, recovery, or reconfiguration of the NR branch.	The report is found, but the later correction path is ignored.

Successful Completion

Success here means the NR-secondary failure report is present and clearly explains the earlier NR-side break.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
EN-DC is unstable, but no NR SCG report appears	The UE may not have reached a valid later reporting point or the report was not captured.	The period after the visible NR-side break.	Earlier NR issue only	Dual-connectivity context	Do not assume the absence of the report means the NR side never failed.
NR SCG report exists, but the master side is blamed instead	The failure classification was not kept NR-specific.	Earlier NR-side events and the later report timing.	SCG Failure Information NR r15	LTE Uu	Separate NR secondary failure from later master-side effects.

What to Check in Logs and Traces

Correlate the NR SCG report with the earlier NR-side instability.
Check whether the LTE master side stayed alive while the NR branch failed.
Read the report before deciding whether the failure was master-side or secondary-side.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

Notes

This page is specific to an NR secondary branch under LTE master control. Keep the analysis NR-secondary first unless later evidence proves the master side also failed.

FAQ

What is LTE NR SCG Failure Information?

It is the UE-side report sent to the LTE master side when the NR secondary branch has failed.

How is this different from generic SCG failure reporting?

This page is specific to the NR secondary branch rather than a more general secondary-cell-group context.