Location Reporting Failure Indication is the NGAP location reporting message sent by the NG-RAN node to the AMF when requested UE location reporting cannot be configured, executed, or continued.
Message Fact Sheet
Protocol
ngap
Network
5g
Spec
3GPP TS 38.413
Spec Section
Location reporting procedures and Location Reporting Failure Indication message
NG-RAN cannot configure, execute, or continue the location reporting requested through Location Reporting Control.
Main purpose
Reports failure of location reporting, identifies the affected UE, provides the failure reason using Cause, prevents silent failure when Location Report is missing, and enables troubleshooting and corrective action.
Location Reporting Failure Indication, Location reporting troubleshooting, Area presence reporting, Emergency or priority service support, Mobility validation
What is Location Reporting Failure Indication in simple terms?
Location Reporting Failure Indication is the NGAP location reporting message sent by the NG-RAN node to the AMF when requested UE location reporting cannot be configured, executed, or continued.
Reports failure of location reporting, identifies the affected UE, provides the failure reason using Cause, prevents silent failure when Location Report is missing, and enables troubleshooting and corrective action.
Why this message matters
Location Reporting Failure Indication is the gNB telling the AMF that requested location reporting failed. The Cause IE tells why.
Where this message appears in the call flow
Location Reporting Failure Indication
Failure Indication reports that requested location reporting could not be configured or performed.
Call flow position: NG-RAN sends this UE-associated initiatingMessage when requested location reporting cannot be applied or continued.
Typical state: AMF learns that the reporting request has failed and should not wait for a normal Location Report for that attempt.
Preconditions:
Location Reporting Control was sent, or reporting context was expected.
AMF UE NGAP ID and RAN UE NGAP ID identify the affected UE context.
Cause explains why reporting failed.
Next likely message: AMF retry, fallback, or reporting cleanup
Cause analysis
Cause separates request problems, context problems, and RAN-side limitations.
Call flow position: Cause is the primary troubleshooting field.
Typical state: Engineers separate unsupported request type, stale UE context, RAN limitation, and protocol handling issues.
Preconditions:
Cause IE is decoded before expecting Location Report.
Next likely message: Corrective action
Failure versus delayed report
Do not treat every missing Location Report as failure; look for the failure indication and request type.
Call flow position: Failure Indication confirms failure; a missing Location Report alone can mean the configured trigger has not occurred yet.
Typical state: Trace analysis avoids treating every delayed or absent report as a confirmed failure.
Preconditions:
Original Location Reporting Control and request type are visible or known.
Next likely message: Correct reporting-state interpretation
Transport / encapsulation: NGAP over SCTP/IP between NG-RAN and AMF
Security context: Location Reporting Failure Indication is tied to UE-specific location reporting. It should be correlated with the original authorized reporting request and handled according to operator privacy and regulatory policy.
Message Structure Overview
Location Reporting Failure Indication is an NG-RAN-to-AMF UE-associated initiatingMessage.
AMF UE NGAP ID and RAN UE NGAP ID bind the failure to the UE context.
Cause is the key troubleshooting payload.
The message is normally correlated with a previous Location Reporting Control.
After confirmed failure, engineers should not expect a Location Report for the same reporting attempt.
ASN.1 for 5G NGAP - Location Reporting Failure Indication
LocationReportingFailureIndication ::= SEQUENCE {
protocolIEs ProtocolIE-Container { {LocationReportingFailureIndication-IEs} },
...
}
LocationReportingFailureIndication-IEs NGAP-PROTOCOL-IES ::= {
{ ID id-AMF-UE-NGAP-ID CRITICALITY reject TYPE AMF-UE-NGAP-ID PRESENCE mandatory } |
{ ID id-RAN-UE-NGAP-ID CRITICALITY reject TYPE RAN-UE-NGAP-ID PRESENCE mandatory } |
{ ID id-Cause CRITICALITY ignore TYPE Cause PRESENCE mandatory },
...
}
How to read this ASN.1
Decode UE identifiers first, then Cause. Cause is the operational field that explains why the requested reporting failed.
5G NGAP - Location Reporting Failure Indication - Example Dump
Treat this as a teaching example based on the expected message structure, not as a captured network trace.
Cause is the first field to inspect.
Correlate the failure with the original Location Reporting Control.
Important Information Elements
IE
Required
Description
Message Type
Yes
Identifies the NGAP PDU as LOCATION REPORTING FAILURE INDICATION.
AMF UE NGAP ID
Yes
Mandatory UE identity at the AMF.
RAN UE NGAP ID
Yes
Mandatory UE identity at the NG-RAN node.
Cause
Yes
Mandatory reason why location reporting could not be configured, executed, or continued.
Detailed field explanation
Message Type
Identifies the NGAP PDU as LOCATION REPORTING FAILURE INDICATION.
Presence: Required
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.
AMF UE NGAP ID
Mandatory UE identity at the AMF.
Presence: Required
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
Mandatory UE identity at the NG-RAN node.
Presence: Required
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
Mandatory reason why location reporting could not be configured, executed, or continued.
Presence: Required
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
Confirm Failure Indication follows Location Reporting Control or an active reporting context.
Match AMF UE NGAP ID and RAN UE NGAP ID correctly.
Decode Cause before retrying or expecting Location Report.
Check whether the reporting request type is supported.
Check UE context state and mobility around the failure.
Check whether Location Report was expected or whether the trigger had not occurred.
Confirm the original Location Reporting Control is present in the trace window.
Common Issues and Troubleshooting
Failure Indication appears immediately after Location Reporting Control.
Likely cause: The reporting request type or area-of-interest configuration may be unsupported or invalid.
What to inspect: Decode Cause and compare with Location Reporting Request Type.
Next step: Retry with a supported request type or corrected area configuration.
Failure is linked to the wrong UE.
Likely cause: UE ID correlation may be stale after mobility or context release.
What to inspect: Compare AMF UE NGAP ID and RAN UE NGAP ID with handover, path switch, and release messages.
Next step: Rebuild UE context mapping before interpreting the failure.
No Location Report appears but no Failure Indication exists.
Likely cause: The reporting trigger may not have occurred yet, or reporting may still be pending.
What to inspect: Check Location Reporting Request Type and event timing.
Next step: Do not mark it as confirmed failure unless Failure Indication or another error is present.
Cause points to UE context unavailable.
Likely cause: UE may have been released, moved, or no longer owned by the reporting NG-RAN node.
What to inspect: Check UE Context Release, handover, path switch, and current RAN UE NGAP ID mapping.
Next step: Reissue reporting control only against the current valid UE context if needed.
Failure repeats after retry.
Likely cause: Node configuration or feature support may not allow the requested reporting.
What to inspect: Check NG-RAN feature support, area-presence configuration, and operator policy.
Next step: Use supported reporting behavior or fix node configuration.
LTE / 5G / Variant Comparison
Compared with Location Reporting Control
Location Reporting Control configures reporting. Failure Indication reports that NG-RAN could not perform that request.
Compared with Location Report
Location Report is the successful reporting path. Failure Indication is the unsuccessful path.
Compared with missing Location Report
A missing report can be delayed or pending; Failure Indication confirms an actual reporting failure.
FAQ
What is Location Reporting Failure Indication in NGAP?
It is the NG-RAN-to-AMF message used to report that requested UE location reporting could not be configured, executed, or continued.
Who sends this message?
The NG-RAN node sends Location Reporting Failure Indication to the AMF.
When is it triggered?
It is triggered after Location Reporting Control when NG-RAN cannot perform or continue the requested reporting.
What does the Cause field represent?
Cause explains why location reporting failed and is the first field to inspect during troubleshooting.
Will Location Report be sent after failure?
For the same failed reporting attempt, engineers should not expect a normal Location Report unless reporting is retried or reconfigured.
How is it different from missing Location Report?
Failure Indication confirms reporting failure. A missing Location Report alone may mean the configured trigger has not occurred yet.
What are common failure reasons?
Common reasons include unsupported request type, invalid area configuration, UE context unavailable, RAN resource limitation, node configuration, or protocol handling error.
How do you troubleshoot it?
Match UE IDs to the original Location Reporting Control, decode Cause, verify request type support, check UE context and mobility state, and avoid expecting Location Report after confirmed failure.
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.
