Error Indication is the NGAP message the receiving node sends when it detects a protocol or semantic error in an incoming message and the problem cannot be reported through the normal unsuccessful outcome defined for that procedure.
UE-associated or non-UE-associated NGAP signaling depending on the message that triggered the error / SCTP carried NGAP initiatingMessage
Typical trigger
The receiving node detects an error in an incoming NGAP message and the issue cannot be reported by the normal unsuccessful outcome of that procedure, or the procedure has no dedicated failure response at all.
Main purpose
Reports protocol handling problems such as incomprehended or missing information elements, logical errors, or state incompatibilities when the peer must be notified but no appropriate failure message can be used for the original procedure.
NGAP protocol error handling, Missing IE reporting, Not comprehended IE reporting, Logical error reporting, Receiver state mismatch handling
What is Error Indication in simple terms?
Error Indication is the NGAP message the receiving node sends when it detects a protocol or semantic error in an incoming message and the problem cannot be reported through the normal unsuccessful outcome defined for that procedure.
Reports protocol handling problems such as incomprehended or missing information elements, logical errors, or state incompatibilities when the peer must be notified but no appropriate failure message can be used for the original procedure.
Why this message matters
Error Indication is the NGAP protocol-level error report used when the receiver found a problem in a message but cannot use the normal failure response for that procedure.
Where this message appears in the call flow
UE-associated protocol error reporting
UE-associated branch: a per-UE procedure fails at protocol level, and the receiver reports the problem with UE IDs plus cause or diagnostics.
Call flow position: The receiver detects an error in a UE-associated NGAP message and cannot report it with the normal unsuccessful outcome of the original procedure.
Typical state: A UE-specific procedure is already in progress or has just been received, but the message cannot be safely processed to completion.
Preconditions:
The triggering message used UE-associated signalling.
The receiver needs to identify the affected UE association in the error report.
At least Cause or Criticality Diagnostics can be supplied in the Error Indication message.
Next likely message: Local recovery, retry, or UE context cleanup depending on the failed procedure
Non-UE-associated protocol error reporting
Interface-level branch: a non-UE-associated procedure cannot return a normal failure message, so the receiver falls back to Error Indication.
Call flow position: The receiver detects an error in a non-UE-associated message such as an interface-management procedure and uses Error Indication without UE IDs.
Typical state: The issue is tied to the original procedure or message semantics, not to one active UE association.
Preconditions:
The triggering message used non-UE-associated signalling or lacked valid UE identity correlation.
A procedure-specific failure message is unavailable or cannot be formed correctly.
Next likely message: Procedure-specific retry or broader interface recovery handling
Clause 10 protocol-error fallback
Clause 10 branch: Error Indication pinpoints the triggering procedure and IE-level fault details through Criticality Diagnostics.
Call flow position: The receiver falls back to Error Indication when clause 10 handling rules require reporting missing or not-comprehended IEs, or a logical error, but the original procedure cannot return a normal unsuccessful outcome.
Typical state: The original request or response has already been deemed non-usable for normal continuation.
Preconditions:
Criticality and presence handling for the original message were evaluated.
The node determined that Error Indication is the correct reporting path instead of a procedure-specific failure response.
Next likely message: The original procedure stops and local error handling continues on the receiver
Transport / encapsulation: NGAP over SCTP/IP between NG-RAN and AMF
Security context: Error Indication does not establish or modify UE security context. It is a protocol-control message used to report decode, presence, semantic, or receiver-state errors. The optional 5G-S-TMSI can carry a masked subscriber identity when needed for correlation without exposing the permanent identity.
Message Structure Overview
Error Indication is a bidirectional NGAP initiatingMessage in the interface-management family.
The message can be very small, but it must contain at least Cause or Criticality Diagnostics.
For UE-associated signalling, AMF UE NGAP ID and RAN UE NGAP ID are expected in the Error Indication message.
Criticality Diagnostics can identify the original procedure, the triggering message type, the procedure criticality, and up to 256 IE-level errors.
Unlike a normal unsuccessful outcome message, Error Indication reports that the receiver found a protocol problem but does not itself define a follow-up acknowledge.
All listed IEs are optional at message-table level, but the successful-operation clause requires that Error Indication contain at least Cause or Criticality Diagnostics. In UE-associated use, both AMF UE NGAP ID and RAN UE NGAP ID shall be included. Criticality Diagnostics is where procedure and IE-level fault detail is carried.
Error Indication is easiest to read when you first identify the original failed procedure inside Criticality Diagnostics.
A message can be valid even if Cause is absent, as long as Criticality Diagnostics is present.
If UE-associated signalling triggered the error, missing UE IDs in the Error Indication itself are a red flag unless the receiver could not trust them.
Important Information Elements
IE
Required
Description
AMF UE NGAP ID
Optional
Optional AMF-side UE identifier. It shall be included when Error Indication is triggered by UE-associated signalling and valid UE-associated reporting is possible.
RAN UE NGAP ID
Optional
Optional NG-RAN-side UE identifier. It shall be included together with AMF UE NGAP ID for UE-associated signalling when those identifiers are the right correlation anchors.
Cause
Optional
Optional cause describing the detected protocol or semantic problem. The procedure requires at least either Cause or Criticality Diagnostics to be present.
Criticality Diagnostics
Optional
Optional diagnostics block used to report which procedure and triggering message caused the issue and which IEs were missing or not understood. When Error Indication is used for clause 10 reporting, this IE becomes the main technical payload.
5G-S-TMSI
Optional
Optional masked UE identity built from AMF Set ID, AMF Pointer, and 5G-TMSI. It can support secure subscriber correlation without exposing permanent identity values.
Detailed field explanation
AMF UE NGAP ID
Optional AMF-side UE identifier. It shall be included when Error Indication is triggered by UE-associated signalling and valid UE-associated reporting is possible.
Presence: Optional
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
RAN UE NGAP ID
Optional NG-RAN-side UE identifier. It shall be included together with AMF UE NGAP ID for UE-associated signalling when those identifiers are the right correlation anchors.
Presence: Optional
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
Cause
Optional cause describing the detected protocol or semantic problem. The procedure requires at least either Cause or Criticality Diagnostics to be present.
Presence: Optional
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
Criticality Diagnostics
Optional diagnostics block used to report which procedure and triggering message caused the issue and which IEs were missing or not understood. When Error Indication is used for clause 10 reporting, this IE becomes the main technical payload.
Presence: Optional
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
5G-S-TMSI
Optional masked UE identity built from AMF Set ID, AMF Pointer, and 5G-TMSI. It can support secure subscriber correlation without exposing permanent identity values.
Presence: Optional
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
What to check in logs and traces
Correlate the Error Indication with the immediately preceding problematic message before looking at the cause text.
Check whether the original procedure had a defined unsuccessful outcome. If it did not, Error Indication is often the expected reporting path.
Inspect Criticality Diagnostics for Procedure Code, Triggering Message, Procedure Criticality, and each missing or not-understood IE.
For UE-associated errors, verify AMF UE NGAP ID and RAN UE NGAP ID are included and check if the Cause points to unknown or inconsistent UE IDs.
Decide whether the receiver terminated the original procedure, ignored specific IEs and notified the sender, or moved into broader local recovery.
Common Issues and Troubleshooting
A procedure ends abruptly with no normal failure response even though the peer clearly detected a problem.
Likely cause: Clause 10 handling may have forced the receiver to terminate the original procedure and send Error Indication because a usable unsuccessful outcome could not be formed.
What to inspect: Check whether the failed procedure lacked a defined failure message or whether mandatory information for building that failure response was itself missing.
Next step: Read Criticality Diagnostics first, then return to the original request to confirm which IE or state condition forced the fallback path.
Error Indication appears on a UE-associated trace with cause values such as unknown or inconsistent UE NGAP IDs.
Likely cause: The receiver could not reconcile the UE identity pair in the triggering message and reported a UE-association problem instead of executing the requested procedure.
What to inspect: Trace AMF UE NGAP ID and RAN UE NGAP ID continuity across prior handover, reset, or release events.
Next step: Treat it as a correlation failure on N2 and inspect for earlier identifier churn before debugging the higher-layer procedure content.
The reported issue is hard to classify because the message body looks structurally complete.
Likely cause: The problem may be semantic or state-related rather than a raw decode failure, which clause 10 treats as a logical error.
What to inspect: Look for cause values such as Semantic Error or Message not compatible with receiver state and check the receiver's procedure state at that time.
Next step: Debug the state machine and message timing, not only ASN.1 presence or ordering.
LTE / 5G / Variant Comparison
Compared with NAS Non Delivery Indication
NAS Non Delivery Indication is a procedure-specific message that reports failed NAS delivery. Error Indication is broader protocol error reporting for NGAP itself.
Compared with NG Setup Failure
NG Setup Failure is the defined unsuccessful outcome for NG Setup. Error Indication is used when a normal failure response is not the right or possible reporting mechanism for the original procedure.
UE-associated versus non-UE-associated use
If the triggering message used UE-associated signalling, Error Indication also uses UE-associated signalling and includes UE IDs. Otherwise it stays non-UE-associated and reports the protocol problem without UE-specific anchors.
FAQ
What is Error Indication in 5G NGAP?
It is the NGAP message used by the receiving node to report a protocol or semantic error in an incoming message when the problem cannot be reported through the normal failure response of that procedure.
What fields can Error Indication contain?
The message can contain AMF UE NGAP ID, RAN UE NGAP ID, Cause, Criticality Diagnostics, and 5G-S-TMSI. At least Cause or Criticality Diagnostics must be present.
When are UE IDs required in Error Indication?
When the error was triggered by UE-associated signalling, the AMF UE NGAP ID and RAN UE NGAP ID shall be included in the Error Indication message.
What is Criticality Diagnostics used for?
It identifies the original procedure and triggering message and can list each missing or not-understood IE, including IE criticality and type of error.
Decode this message with the 3GPP Decoder, inspect the related message database, or open the matching call flow to see where this signaling step fits in the full procedure.
