RAN Configuration Update Acknowledge is the AMF-to-NG-RAN successful-outcome message used to confirm that a previously received RAN Configuration Update has been accepted and applied for the NG-C interface instance.
Message Fact Sheet
Protocol
ngap
Network
5g
Spec
3GPP TS 38.413
Spec Section
Section 8.7.2.2 and section 9.2.6.5 (Release 18 baseline)
The AMF successfully validates and applies a received RAN Configuration Update and needs to confirm completion of the procedure back to the NG-RAN.
Main purpose
Confirms that the AMF successfully processed the previously received RAN Configuration Update and that the AMF-side stored view of the NG-C interface now reflects the accepted node-level changes.
RAN Configuration Update successful operation, NG-C interface maintenance, AMF and NG-RAN configuration synchronization, Supported TA List replacement confirmation, TNL association-removal confirmation path
What is RAN Configuration Update Acknowledge in simple terms?
RAN Configuration Update Acknowledge is the AMF-to-NG-RAN successful-outcome message used to confirm that a previously received RAN Configuration Update has been accepted and applied for the NG-C interface instance.
Confirms that the AMF successfully processed the previously received RAN Configuration Update and that the AMF-side stored view of the NG-C interface now reflects the accepted node-level changes.
Why this message matters
RAN Configuration Update Acknowledge is the AMF saying the configuration refresh was accepted and applied; it confirms success but does not repeat the configuration data.
Where this message appears in the call flow
Successful confirmation of node-level refresh
Success branch: the request carries the changed configuration, and the AMF uses the acknowledge to confirm that the update has been accepted and applied.
Call flow position: The NG-RAN already sent RAN Configuration Update and the AMF accepted the requested configuration refresh.
Typical state: The AMF has validated the update and is ready to confirm successful application at the NG-C interface level.
Preconditions:
RAN Configuration Update reached the AMF successfully.
The AMF accepted the included node-level changes.
The AMF has applied or committed the accepted configuration update.
Next likely message: Normal non-UE-associated or UE-associated NGAP procedures under the updated interface view
AMF-side state synchronization completed
Design pattern: the initiating message carries the configuration payload, while the acknowledge only signals successful completion.
Call flow position: The acknowledge marks the point where the NG-RAN can treat the AMF view as synchronized with the accepted update.
Typical state: The procedure is ending on the successful branch.
Preconditions:
The request-side configuration data was already in operational use at the NG-RAN.
The AMF processed the update without returning failure.
Next likely message: No immediate follow-up message required by the procedure itself
Success branch versus failure branch
Abnormal-condition branch: if no acknowledge and no failure arrive, the NG-RAN may retry only with identical RAN Configuration Update content.
Call flow position: The AMF chooses the successful outcome instead of RAN Configuration Update Failure.
Typical state: The refresh procedure ends with acceptance rather than rejection.
Preconditions:
The update content did not trigger a rejection condition.
No Time to Wait or Cause-based failure handling is needed.
Next likely message: Configuration remains synchronized until a later interface-management change
Call flow position
Previous message(s):RAN Configuration Update, AMF evaluation of node-level configuration refresh
Transport / encapsulation: NGAP over SCTP/IP between AMF and NG-RAN
Security context: RAN Configuration Update Acknowledge does not create, release, or modify UE-specific security context. It confirms successful processing of node-level configuration refresh and does not affect existing UE-related contexts.
Message Structure Overview
RAN Configuration Update Acknowledge is a non-UE-associated successfulOutcome in the Interface Management family.
The message is intentionally minimal and carries no configuration payload of its own.
All node-level configuration data belongs to the initiating RAN Configuration Update message, while the acknowledge only confirms successful processing.
The absence of payload is part of the protocol design, not a missing decode.
After the acknowledge, the NG-RAN can treat the AMF view as synchronized with the accepted update.
ASN.1 for 5G NGAP - RAN Configuration Update Acknowledge
This is one of the cleanest examples of a successfulOutcome with no service-content IE payload. The operational meaning comes from the procedure state: the request carried the configuration, and the acknowledge confirms success.
5G NGAP - RAN Configuration Update Acknowledge - Example Dump
Treat this as a teaching example based on the spec structure, not as a captured network trace.
The acknowledge is intentionally empty at the configuration-content level.
Do not expect the AMF to echo Supported TA List, paging values, or TNL removal details back in this message.
Important Information Elements
IE
Required
Description
Message Type
Yes
Identifies the NGAP PDU as RAN Configuration Update Acknowledge in the successfulOutcome branch.
Detailed field explanation
Message Type
Identifies the NGAP PDU as RAN Configuration Update Acknowledge in the successfulOutcome 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.
What to check in logs and traces
Confirm the acknowledge follows a RAN Configuration Update on the same non-UE-associated interface path.
Verify no RAN Configuration Update Failure was returned for the same attempt.
Do not misread the empty payload as decode loss or parser truncation.
Validate the original RAN Configuration Update payload if you need to understand what the AMF accepted.
If no acknowledge and no failure arrive, check the abnormal-condition retry rule before resending.
Common Issues and Troubleshooting
The acknowledge looks empty and seems incomplete.
Likely cause: That is expected. The message is intentionally minimal and does not carry the configuration payload back from the AMF.
What to inspect: Compare the successfulOutcome with the earlier RAN Configuration Update instead of expecting configuration IEs in the acknowledge.
Next step: Use the initiating message to understand the accepted update content and use the acknowledge only as proof of successful processing.
The NG-RAN resends RAN Configuration Update even though acknowledge should have completed the procedure.
Likely cause: The acknowledge may not have been received, may have been delayed, or the sender may be assuming the acknowledge should contain configuration payload.
What to inspect: Check the signaling sequence, timing, and whether the successfulOutcome was received and decoded.
Next step: Treat the acknowledge as a pure completion signal and only retry according to the abnormal-condition rule if no acknowledge or failure is received.
There is uncertainty about what changed after the acknowledge.
Likely cause: The message itself does not describe the accepted update, so the state change must be inferred from the earlier RAN Configuration Update payload.
What to inspect: Review the original Supported TA List, paging parameters, Global RAN Node ID, and TNL association-removal content in the request.
Next step: Interpret the acknowledge as confirmation that the AMF accepted those request-side changes.
LTE / 5G / Variant Comparison
Compared with RAN Configuration Update
RAN Configuration Update carries the actual node-level configuration changes. RAN Configuration Update Acknowledge carries no configuration payload and only confirms successful processing.
Compared with RAN Configuration Update Failure
The acknowledge is the success branch. The failure message is the rejection branch and can include Cause and Time to Wait.
Compared with NG Setup Response
NG Setup Response returns AMF-side support information during setup, while RAN Configuration Update Acknowledge is intentionally minimal and only confirms a previously carried update.
FAQ
What is RAN Configuration Update Acknowledge in NGAP?
It is the AMF-to-NG-RAN successful-outcome message that confirms a previously received RAN Configuration Update was accepted and successfully processed.
Who sends this message?
The AMF sends RAN Configuration Update Acknowledge to the NG-RAN node.
Does this message contain configuration data?
No. The configuration data is carried in RAN Configuration Update. The acknowledge only confirms successful processing.
What happens after ACK is received?
The NG-RAN can treat the AMF view as synchronized with the accepted update and continue normal NGAP procedures under the refreshed node-level configuration.
What is the difference between ACK and FAILURE?
ACK means the configuration refresh was accepted and applied. FAILURE means the refresh was rejected and may include Cause and Time to Wait.
Can NG-RAN retry if ACK is not received?
If neither acknowledge nor failure is received, the NG-RAN may reinitiate the procedure toward the same AMF, but only with identical message content.
Does this message affect UE contexts?
No. The procedure is non-UE-associated and does not affect existing UE-related contexts.
Why is the message empty?
Because the request already carried the configuration payload. The successful outcome only needs to confirm that the AMF accepted and applied it.
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.
