Home / Call Flows / LTE / LTE Failure Information Procedure

LTE Failure Information Procedure Call Flow

call-flow LTE | Failure | Troubleshooting

LTE 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

Failure Information is the UE-side LTE report sent after an earlier failure, when the UE is still able to return extra context to the network. It is not the original failure itself. It is the later evidence message about that failure.

Use this page when the visible problem has already happened and the next question is whether the UE later sent a Failure Information message that helps explain it.

What Is LTE Failure Information Procedure in Simple Terms?

What starts the procedure: The UE has recovered enough after an earlier problem to report extra failure context back to the network.
What the UE and network want to achieve: Return useful UE-side evidence about the earlier failure so the network can interpret the break more accurately.
What success looks like: Failure Information is sent and can be correlated clearly with the earlier failed branch.
What failure means: The failure happened, but the later report is missing, ambiguous, or read without the earlier failure context.

Why this procedure matters

Failure Information is one of the clearest UE-side evidence messages in LTE failure analysis. It is much more valuable when tied directly to the earlier failing branch.

Quick Fact Sheet

Procedure name	LTE Failure Information Procedure
Domain	LTE UE-side failure reporting
Main trigger	The UE has recovered enough after an earlier problem to report extra failure context 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 additional failure evidence that can be correlated with the earlier break
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	Failure Information r15 or r16
Main specs	TS 36.331

LTE 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                 eNB / network
|--earlier failure----|
|--later recovery---->|
|--Failure Information->|

Major Phases

Phase	What happens
1. Earlier failure occurs	The real break happens first in another branch.
2. UE recovers enough to report	The UE reaches a point where uplink reporting is possible again.
3. Failure evidence upload	Failure Information is sent back to the network.

Step-by-Step Breakdown

Step 1: Follow the earlier failed branch

Sender -> receiver: UE and network side

Message(s): Earlier failing procedure

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

State or context change: The system is already on a failure path before Failure Information is sent.

Note: This earlier branch is the context that gives Failure Information its meaning.

Step 2: Regain enough uplink capability to report

Sender -> receiver: UE

Message(s): Later reporting readiness

Purpose: Reach a state where the UE can send failure evidence back to the network.

State or context change: The UE is now able to return a clear failure-report message.

Note: Not every failure leads to a later report; the UE still needs a usable reporting opportunity.

Step 3: Send the failure report

Sender -> receiver: UE -> eNB

Message(s): Failure Information r15 or Failure Information r16

Purpose: Deliver extra failure context after the earlier problem.

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

Note: This is one of the cleanest LTE-side indicators that the UE recognized and reported the break.

Important Messages

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
Failure Information r15	RRC	UE -> eNB	Reports UE-side failure context after an earlier problem.	Check which earlier branch this report belongs to and why it appeared at this later point.
Failure Information r16	RRC	UE -> eNB	Release 16 variant of the later failure report.	Check whether the release-specific variant matches the deployed feature context.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
Release variant	Whether the UE sent r15 or r16 failure information.	Failure Information message	Explains which message variant and IE set applies.	The wrong release variant is assumed.
Earlier failed branch	The procedure that actually broke before the later report.	Correlation with previous messages	This is the most important correlation point for the message.	Failure Information is read in isolation.
Report timing	The gap between the original failure and the later report.	Failure Information arrival time	Useful when the report appears much later than the visible break.	The later timing makes the report look unrelated.
UE-side evidence value	What failure-specific context the message returns.	Failure Information payload	Shows why this message is worth reading after the main failure.	The message is treated as generic noise instead of concrete evidence.
Subsequent correction path	What the network did after receiving the report.	Later messages	Shows whether the report triggered any recovery or logging action.	The report is found, but no one checks what followed.

Successful Completion

Success here means the later Failure Information message can be tied clearly to the earlier failing branch and used as real evidence.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
Failure Information appears, but no one knows what it belongs to	The earlier failing branch was never identified first.	The messages immediately before Failure Information and the earlier failure timeline.	Failure Information r15/r16	LTE Uu	Go backward and find the original branch that failed.
The report never appears even though the failure was obvious	The UE may not have reached a state where later failure reporting was possible.	The period after the failure and any attempted recovery.	Earlier failure only	Procedure-specific	Do not assume the absence of Failure Information means the earlier failure never happened.

What to Check in Logs and Traces

Always correlate Failure Information with the earlier branch that failed.
Check whether the report is r15 or r16 before interpreting the IEs.
Use the later report as evidence, not as the original failure itself.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

Notes

Failure Information is a later evidence message. It should almost always be read side by side with the earlier procedure break that caused it.

FAQ

What is LTE Failure Information?

It is the UE-side RRC failure report sent after an earlier problem when the UE can still return useful failure context.

Is Failure Information the failure itself?

No. It is later evidence about an earlier failure.