Home / Call Flows / LTE / LTE Unknown / Not-Comprehended IE Handling

LTE Unknown / Not-Comprehended IE Handling Call Flow

call-flow LTE | Failure | Troubleshooting

LTE Unknown / Not-Comprehended IE Handling 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

Unknown or not-comprehended IE handling is used when the receiver can parse the message structure, but one or more IEs are not understood or not supported.

This is different from both encoding failure and missing mandatory-field handling because the message is present and decodable, but the receiver still cannot interpret all of its content correctly.

What Is LTE Unknown / Not-Comprehended IE Handling in Simple Terms?

What starts the procedure: A message includes IE content that is decoded structurally but is unknown, unsupported, or not comprehended by the receiver.
What the UE and network want to achieve: Handle the unsupported or not-comprehended IE without confusing it with a structure failure or a missing field.
What success looks like: The unknown IE is identified and the correct ignore, reject, or constrained handling rule is applied.
What failure means: The branch is misread as malformed or incomplete when the real issue is unsupported IE content.

Why this procedure matters

Unknown IE handling is common in mixed releases and partial feature support. If it is read incorrectly, the wrong compatibility or failure conclusion may be drawn.

Quick Fact Sheet

Procedure name	LTE Unknown / Not-Comprehended IE Handling
Domain	LTE unknown or not-comprehended information element handling
Main trigger	A message includes IE content that is decoded structurally but is unknown, unsupported, or not comprehended by the receiver.
Start state	A wider LTE procedure is already in progress and something has gone wrong or become invalid
End state	The receiver ignores, rejects, or constrains the branch according to the IE handling rules
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	Procedure message with unsupported or unknown IE content
Main specs	TS 36.331, TS 24.301

LTE Unknown / Not-Comprehended IE Handling — 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

Sender             Receiver
|--message with IE---->|
|--IE not understood-->|
|--ignore / reject---->|

Major Phases

Phase	What happens
1. Decode the message	The message structure is parsed successfully.
2. Identify the unknown IE	The receiver finds content it does not comprehend or support.
3. Apply the IE handling rule	The procedure continues with constraint, ignore, or reject behavior.

Step-by-Step Breakdown

Step 1: Read the decoded message

Sender -> receiver: Sender -> Receiver

Message(s): Message with unsupported or unknown IE content

Purpose: Deliver a message whose structure is valid but whose content is not fully understood.

State or context change: The receiver can inspect the IE list, unlike pure decode failure.

Note: This branch only makes sense after structural decode succeeds.

Step 2: Identify the unsupported IE

Sender -> receiver: Receiver

Message(s): IE comprehension check

Purpose: Find the exact field or value that is not understood.

State or context change: The receiver knows which part of the message is the compatibility problem.

Note: This is the key compatibility and release-support step.

Step 3: Apply the handling rule

Sender -> receiver: Receiver -> peer or internal handling

Message(s): Ignore, constrain, reject, or later stop behavior

Purpose: Handle the unsupported content according to the LTE rules that apply.

State or context change: The wider procedure either survives in limited form or stops on the failure path.

Note: The output depends on whether the unknown content was optional, critical, or procedure-defining.

Important Messages

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
RRC Connection Reconfiguration	RRC	Network -> UE	Useful example where new or unsupported configuration content can trigger not-comprehended handling.	Check whether the unknown field sits inside otherwise valid reconfiguration content.
Security Mode Reject	NAS	UE -> Network	Useful visible outcome if unsupported content makes the UE reject the wider branch.	Check whether the reject is tied to unsupported content or a different semantic reason.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
Unknown IE name or value	The exact field or value not understood by the receiver.	Decoded message content	Explains the compatibility problem directly.	The trace never names the unsupported field.
Criticality or handling impact	Whether the unsupported content could be ignored or had to stop the branch.	IE handling rule	Explains why one unknown IE was survivable while another was fatal.	All unknown IEs are treated as equally severe.
Release or feature context	Whether the unsupported content belongs to a newer feature or optional capability.	Procedure context	Useful in mixed-release or partial-support networks.	A compatibility problem is misread as corruption or missing content.
Decode success	Proof that the message structure itself was parsed correctly.	Parser stage	Separates this branch from ASN.1 failure.	The message was never parsed correctly to begin with.
Later procedure effect	How the wider procedure behaved after the unknown IE was found.	Later messages	Shows whether the branch survived in part or ended completely.	The visible effect is read without identifying the IE rule behind it.

Successful Completion

Success here means the unsupported IE is identified correctly and the compatibility problem is not confused with another failure type.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
Message is blamed as malformed when the real issue is unsupported content	The trace jumps to encoding conclusions without proving a structural decode failure.	Decoder result and the exact unsupported IE.	Procedure message	Protocol-specific	Prove structural decode success first, then classify the unsupported content.
Later reject happens, but no one checks whether an optional unknown IE could have been ignored	The handling rule for that IE was not reviewed.	Unknown IE, its criticality, and the actual procedure impact.	Procedure message and later reject	Protocol-specific	Check whether the branch should have ignored the IE rather than failed hard.

What to Check in Logs and Traces

Prove that structural decode succeeded before reading this as unknown IE handling.
Identify the exact unsupported IE or value.
Check whether the IE should have been ignored, constrained, or treated as fatal.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

Notes

This branch is mainly about compatibility and comprehension, not payload corruption. The message may be valid but still unusable in full on the receiving side.

FAQ

What is unknown or not-comprehended IE handling in LTE?

It is the branch used when a message decodes correctly but contains content that the receiver does not understand or support.

Is this the same as missing mandatory content?

No. The field is present here; the issue is that the receiver cannot comprehend or support it.