Home / Call Flows / LTE / LTE MCG Failure Information

LTE MCG Failure Information Call Flow

call-flow LTE | Failure | Troubleshooting

LTE MCG 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

MCG Failure Information is the LTE report used when the master cell group side itself has failed. This is different from secondary-branch failure reporting because the failing side is now the master branch.

Use this page when the earlier problem affects the main branch and the UE later reports that master-side failure explicitly.

What Is LTE MCG Failure Information in Simple Terms?

What starts the procedure: The UE detects a master cell group failure and later reports it back to the network.
What the UE and network want to achieve: Return clear UE-side evidence that the master branch failed.
What success looks like: The UE sends MCG Failure Information and it matches the earlier master-side break.
What failure means: The master-side problem is visible, but the later report is missing or is read as a different branch type.

Why this procedure matters

Master-side failures often have broader impact than secondary-side failures. This message is an important clue that the main branch itself was the real problem.

Quick Fact Sheet

Procedure name	LTE MCG Failure Information
Domain	LTE master cell group failure reporting
Main trigger	The UE detects a master cell group failure and later reports it back to the network.
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 report that the master-side branch failed
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	MCG Failure Information r16
Main specs	TS 36.331

LTE MCG 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                   network side
|--MCG branch fails----|
|--later report------->|
|--MCG Failure Info---->|

Major Phases

Phase	What happens
1. Master-side failure	The main branch breaks first.
2. Later reporting point	The UE becomes able to send the report.
3. Master-side evidence upload	MCG Failure Information is sent back to the network.

Step-by-Step Breakdown

Step 1: Track the earlier master-side break

Sender -> receiver: UE and network side

Message(s): Earlier MCG-side failure branch

Purpose: Identify the main branch failure before the later report appears.

State or context change: The MCG side is already broken before the report is sent.

Note: This earlier branch is the context that makes the later MCG report meaningful.

Step 2: Reach later reporting readiness

Sender -> receiver: UE

Message(s): Later reporting readiness

Purpose: Reach a state where the UE can send a master-side failure report.

State or context change: The UE can now return explicit MCG evidence.

Note: The reporting opportunity can come later than the visible break itself.

Step 3: Send MCG Failure Information

Sender -> receiver: UE -> network side

Message(s): MCG Failure Information r16

Purpose: Tell the network that the master branch failed.

State or context change: The network now has direct UE-side evidence about a master-side failure.

Note: This is one of the clearest signs that the main branch itself was the real failure point.

Important Messages

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
MCG Failure Information r16	RRC	UE -> network side	Reports a master-side failure to the network.	Check the report timing against the earlier main-branch break.
Failure Information r16	RRC	UE -> network side	Useful comparison if the wider branch also returned a more generic later failure report.	Check whether the main branch failure should be read as MCG-specific or more generic.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
Master branch identity	The exact main branch that failed.	Earlier break and later report	Shows which master-side context the report belongs to.	The report is tied to the wrong branch.
Report timing	The gap between the master-side failure and the later report.	MCG Failure Information arrival	Useful when the report appears later than the visible break.	The later report is assumed unrelated.
Main-branch impact	How broad the failure impact was before reporting.	Wider procedure context	Important because master-side failures can destabilize much more than secondary-side failures.	The failure is underestimated because only the report is read.
Master-side evidence	What the report says about the failing main branch.	MCG Failure Information payload	Explains why this message is the key master-side evidence point.	The report is present but not used to classify the branch correctly.
Subsequent network action	What the network did after receiving the master-side report.	Later messages	Shows whether the report led to recovery, release, or later logging action.	The report is found, but the network reaction is ignored.

Successful Completion

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

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
Main branch clearly failed, but no MCG report is found	The UE may not have reached a valid later reporting point or the report was not captured.	The period after the visible master-side break.	Earlier master-side issue only	Wider procedure context	Do not assume the absence of the report means the master side never failed.
The MCG report exists, but the branch is misread as an SCG problem	The earlier break was not correlated to the correct side of the connection.	Earlier branch events and later report timing.	MCG Failure Information r16	LTE Uu	Decide first whether the earlier break was on the master or secondary side.

What to Check in Logs and Traces

Correlate the report with the earlier master-side break.
Decide whether the earlier issue was master-side or secondary-side before classifying it.
Follow what the network did after the report arrived.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

Notes

This page is for master-side failure reporting. The wider impact can be larger than an SCG-only failure, so read the earlier branch context carefully.

FAQ

What is LTE MCG Failure Information?

It is the UE-side report that tells the network the master cell group failed.

How is this different from SCG failure reporting?

MCG failure reporting is about the master side of the branch, not the secondary side.