RAN Configuration Update Failure is the AMF-to-NG-RAN unsuccessful-outcome message used to indicate that the AMF cannot accept a previously received RAN Configuration Update for an NG-C interface instance.
The AMF cannot accept updated NG-C configuration information received in RAN Configuration Update and must reject the procedure back to the NG-RAN.
Main purpose
Rejects the attempted RAN-driven configuration refresh, tells the NG-RAN why the AMF could not accept the update through mandatory Cause, and can control retry timing or expose deeper protocol context through optional Time to Wait and Criticality Diagnostics.
RAN Configuration Update unsuccessful operation, NG-C interface maintenance failure handling, AMF and NG-RAN configuration synchronization rejection, Retry pacing by Time to Wait, Abnormal-condition reinitiation handling
What is RAN Configuration Update Failure in simple terms?
RAN Configuration Update Failure is the AMF-to-NG-RAN unsuccessful-outcome message used to indicate that the AMF cannot accept a previously received RAN Configuration Update for an NG-C interface instance.
Rejects the attempted RAN-driven configuration refresh, tells the NG-RAN why the AMF could not accept the update through mandatory Cause, and can control retry timing or expose deeper protocol context through optional Time to Wait and Criticality Diagnostics.
Why this message matters
RAN Configuration Update Failure is the AMF telling the NG-RAN that the requested node-level configuration update was rejected, here is the failure reason, and here is how long to wait before retrying if a Time to Wait value was included.
Where this message appears in the call flow
AMF rejects RAN-driven configuration refresh
Failure branch: the NG-RAN sends updated configuration, the AMF cannot accept it, and the procedure ends with RAN Configuration Update Failure instead of acknowledgment.
Call flow position: The NG-C interface instance already exists, the NG-RAN has sent updated configuration data, and the AMF determines that it cannot accept the requested update.
Typical state: The procedure is on the unsuccessful branch and the requested refresh is not accepted as sent.
Preconditions:
RAN Configuration Update reached the AMF successfully.
The AMF found a reason it cannot accept the update content.
The procedure remains non-UE-associated and existing UE-related contexts are unaffected.
Next likely message: NG-RAN analyzes Cause and optional retry guidance before deciding whether to reattempt
Failure with retry backoff
Retry-control branch: when Time to Wait is present, the NG-RAN shall wait at least that long before reinitiating RAN Configuration Update toward the same AMF.
Call flow position: The AMF rejects the update and includes Time to Wait, so the NG-RAN is not allowed to retry the same AMF immediately.
Typical state: The failed procedure now includes explicit retry pacing.
Preconditions:
RAN Configuration Update Failure includes Time to Wait.
The NG-RAN intends to retry toward the same AMF.
Next likely message: Retried RAN Configuration Update only after the minimum wait interval expires
No response and identical reattempt
Abnormal-condition branch: if the NG-RAN receives neither acknowledge nor failure, it may reinitiate the procedure toward the same AMF only with identical message content.
Call flow position: After initiating RAN Configuration Update, the NG-RAN receives neither acknowledge nor failure and considers reinitiating the procedure toward the same AMF.
Typical state: The previous update remains unconfirmed, so the abnormal-condition rule controls whether reinitiation is allowed.
Preconditions:
No RAN Configuration Update Acknowledge or Failure was received.
Any reinitiated RAN Configuration Update toward the same AMF uses identical content.
Next likely message: Identical RAN Configuration Update reattempt toward the same AMF
Transport / encapsulation: NGAP over SCTP/IP between AMF and NG-RAN
Security context: RAN Configuration Update Failure does not create, release, or modify UE-specific security context. It is a node-level rejection message in a non-UE-associated interface-management procedure.
Message Structure Overview
RAN Configuration Update Failure is a non-UE-associated unsuccessfulOutcome in the Interface Management family.
The sender is the AMF and the receiver is the NG-RAN node on the N2 or NG-C interface.
The message is compact but operationally important: mandatory Cause plus optional Time to Wait and optional Criticality Diagnostics.
Cause is the primary reason the update was rejected and is the highest-value field in traces.
If Time to Wait is present, the NG-RAN shall wait at least that long before retrying the procedure toward the same AMF.
The abnormal-condition rule is separate from the failure rule: if no acknowledge and no failure arrive, the NG-RAN may reinitiate only with identical RAN Configuration Update content.
ASN.1 for 5G NGAP - RAN Configuration Update Failure
RANConfigurationUpdateFailure ::= SEQUENCE {
protocolIEs ProtocolIE-Container { {RANConfigurationUpdateFailureIEs} },
...
}
RANConfigurationUpdateFailureIEs NGAP-PROTOCOL-IES ::= {
{ ID id-Cause CRITICALITY ignore TYPE Cause PRESENCE mandatory } |
{ ID id-TimeToWait CRITICALITY ignore TYPE TimeToWait PRESENCE optional } |
{ ID id-CriticalityDiagnostics CRITICALITY ignore TYPE CriticalityDiagnostics PRESENCE optional },
...
}
How to read this ASN.1
This is the negative branch of RAN Configuration Update. The operational meaning comes from Cause first, then from whether Time to Wait changes retry timing and whether Criticality Diagnostics adds deeper troubleshooting value.
5G NGAP - RAN Configuration Update Failure - Example Dump
Treat this as a teaching example based on the spec structure, not as a captured network trace.
Start with Cause before reading anything else. Time to Wait and Criticality Diagnostics only become useful after the rejection reason is understood.
If Time to Wait is present, treat it as real retry control toward the same AMF rather than as optional commentary.
Read the failure together with the initiating RAN Configuration Update so you can see which configuration payload triggered the rejection.
Important Information Elements
IE
Required
Description
Message Type
Yes
Identifies the NGAP PDU as RAN Configuration Update Failure in the unsuccessfulOutcome branch.
Cause
Yes
Mandatory failure reason explaining why the AMF rejected the attempted RAN Configuration Update. This is the first field engineers should inspect.
Time to Wait
Optional
Optional minimum wait interval before the NG-RAN may reinitiate RAN Configuration Update toward the same AMF. This IE changes retry timing in the field.
Criticality Diagnostics
Optional
Optional diagnostics that can provide additional protocol-handling or IE-level context relevant to why the configuration refresh was rejected.
Detailed field explanation
Message Type
Identifies the NGAP PDU as RAN Configuration Update Failure in the unsuccessfulOutcome branch.
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 failure reason explaining why the AMF rejected the attempted RAN Configuration Update. This is the first field engineers should inspect.
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.
Time to Wait
Optional minimum wait interval before the NG-RAN may reinitiate RAN Configuration Update toward the same AMF. This IE changes retry timing in the field.
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 that can provide additional protocol-handling or IE-level context relevant to why the configuration refresh was rejected.
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
Confirm the failure follows a RAN Configuration Update on the same non-UE-associated interface path.
Decode Cause first because it is the primary explanation of why the update was rejected.
If Time to Wait is present, verify the NG-RAN did not retry toward the same AMF before the minimum wait interval expired.
If Criticality Diagnostics is present, decode it together with the rejected RAN Configuration Update to find any IE-level or procedure-level clues.
Compare the rejected update contents against AMF expectations, Supported TA List acceptance, TNL removal handling, and current deployment design.
If no acknowledge and no failure were received on an earlier attempt, validate that any reinitiated RAN Configuration Update toward the same AMF used identical content.
Common Issues and Troubleshooting
The NG-RAN retries the configuration update too quickly and the same failure repeats.
Likely cause: Time to Wait may have been ignored or treated as informational instead of as a minimum retry delay toward the same AMF.
What to inspect: Check whether the failure carried Time to Wait and compare the retry timing against that value.
Next step: Honor the minimum wait interval before reattempting toward the same AMF.
Troubleshooting focuses only on transport reachability, but the rejection reason remains unclear.
Likely cause: The main issue may be in the configuration content or protocol handling rather than in SCTP transport itself.
What to inspect: Start with Cause and then read any Criticality Diagnostics before assuming a transport-only problem.
Next step: Debug the rejected RAN Configuration Update content and procedure semantics, not only the underlying transport.
The NG-RAN resends a modified update after silence from the AMF and behavior becomes inconsistent.
Likely cause: The abnormal-condition rule only allows reinitiation toward the same AMF when the new RAN Configuration Update content is identical to the previously unacknowledged one.
What to inspect: Compare the retransmitted message with the original one field by field.
Next step: If the content changed, treat it as a new update attempt after resolving the no-response condition rather than as a compliant reinitiation.
LTE / 5G / Variant Comparison
Compared with RAN Configuration Update Acknowledge
RAN Configuration Update Acknowledge is the successful outcome and confirms that the AMF accepted the configuration refresh. RAN Configuration Update Failure is the rejection branch and returns Cause plus optional Time to Wait and Criticality Diagnostics.
Compared with RAN Configuration Update
RAN Configuration Update carries the actual node-level NG-RAN configuration changes. RAN Configuration Update Failure does not carry new configuration; it reports that the AMF could not accept the attempted update.
Retry control versus no-response reinitiation
Failure with Time to Wait controls when the NG-RAN may retry after an explicit rejection. The abnormal-condition rule covers a different case where there is no acknowledge and no failure, and it allows reinitiation only with identical content.
FAQ
What is RAN Configuration Update Failure in 5G NGAP?
It is the AMF-to-NG-RAN unsuccessful-outcome message used to indicate that the AMF could not accept a previously received RAN Configuration Update.
Who sends RAN Configuration Update Failure?
The AMF sends RAN Configuration Update Failure to the NG-RAN node.
When is RAN Configuration Update Failure used?
It is used when the AMF cannot accept updated NG-C configuration information received in RAN Configuration Update.
What does the Cause IE mean in this message?
Cause is the primary failure reason returned by the AMF and is the first field engineers should inspect when the RAN-driven update is rejected.
What is Time to Wait in RAN Configuration Update Failure?
It is an optional IE that tells the NG-RAN the minimum time it shall wait before reinitiating RAN Configuration Update toward the same AMF.
How long must the NG-RAN wait before retrying?
If Time to Wait is present, the NG-RAN must wait at least that long before retrying. The exact permitted values come from the Time to Wait IE definition.
What is Criticality Diagnostics used for?
It is optional additional diagnostic information that can provide more detailed protocol-handling or IE-level context about the failed update.
What is the difference between RAN Configuration Update Acknowledge and Failure?
Acknowledge means the AMF successfully updated configuration. Failure means the AMF rejected the update and may include Cause, Time to Wait, and Criticality Diagnostics.
What happens if the NG-RAN gets no acknowledge and no failure?
The NG-RAN may reinitiate the procedure toward the same AMF, but only if the new RAN Configuration Update message content is identical to the previously unacknowledged one.
Is this a UE-associated or non-UE-associated NGAP procedure?
It is a non-UE-associated interface-management procedure.
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.
