gNB-CU Configuration Update Acknowledge is the F1AP successful outcome sent by the gNB-DU to the gNB-CU to confirm successful processing of a CU configuration update.
Message Fact Sheet
Protocol
f1ap
Network
5g
Spec
3GPP TS 38.473
Spec Section
gNB-CU Configuration Update Acknowledge message and gNB-CU Configuration Update procedure
Direction
gNB-DU -> gNB-CU
Message Type
gNB-CU Configuration / F1 Interface Management Message
The gNB-DU receives a gNB-CU Configuration Update, validates CU-side configuration or transport changes, and accepts the update procedure.
Main purpose
Confirms acceptance of CU configuration updates, completes the update procedure, synchronizes the DU-side understanding of CU configuration, confirms that updated transport or configuration information was accepted, and prevents unnecessary retries or rollback actions.
CU-side configuration synchronization, gNB-CU Configuration Update successful outcome, CU TNL association acceptance, Post-F1-setup configuration lifecycle, Transaction ID correlation
What is gNB-CU Configuration Update Acknowledge in simple terms?
gNB-CU Configuration Update Acknowledge is the F1AP successful outcome sent by the gNB-DU to the gNB-CU to confirm successful processing of a CU configuration update.
Confirms acceptance of CU configuration updates, completes the update procedure, synchronizes the DU-side understanding of CU configuration, confirms that updated transport or configuration information was accepted, and prevents unnecessary retries or rollback actions.
Why this message matters
gNB-CU Configuration Update Acknowledge means the DU accepted the CU configuration update. Match Transaction ID first, then verify the accepted CU transport or configuration changes behave as expected.
Where this message appears in the call flow
gNB-CU Configuration Update
Procedure close: the DU accepts the CU update and returns the same Transaction ID.
Call flow position: The gNB-DU sends Acknowledge after accepting the gNB-CU Configuration Update.
Typical state: The update procedure is complete and the DU-side view of CU configuration should be synchronized.
Preconditions:
The CU sent gNB-CU Configuration Update.
The DU validated the update and did not reject it with Failure.
Transaction ID is available for correlation.
Next likely message: Normal F1AP operation using accepted CU configuration
CU TNL association acceptance
Transport acceptance: the ACK confirms DU-side acceptance of CU TNL association or endpoint changes.
Call flow position: The acknowledgement confirms that CU-side transport association changes were accepted by the DU.
Typical state: The DU should use the accepted CU transport information consistently after the update.
Preconditions:
The original update included CU TNL association or transport endpoint changes.
The DU accepted the transport/configuration change for the same Transaction ID.
Next likely message: Transport path validation and stable F1 operation
CU ACK versus DU ACK
Direction distinction: CU update ACK is DU-to-CU; DU update ACK is CU-to-DU.
Call flow position: This ACK is the DU-to-CU response for CU-owned configuration changes.
Next message(s): Normal F1AP operation using accepted CU configuration, CU and DU remain synchronized after the accepted change, Later CU-side change if configuration changes again
Message direction and transport
Sender and receiver: gNB-DU -> gNB-CU
Interface: F1-C
Domain: F1 interface management and CU-side configuration synchronization
Transport / encapsulation: F1AP over SCTP/IP between gNB-DU and gNB-CU
Security context: gNB-CU Configuration Update Acknowledge does not establish a UE security context. It is a non-UE-associated successful outcome confirming that the DU accepted CU-side configuration information after F1 setup.
Message Structure Overview
gNB-CU Configuration Update Acknowledge is the successfulOutcome for the CU configuration update procedure.
It is sent from gNB-DU to gNB-CU.
Transaction ID is mandatory and ties the ACK to the original CU update.
Criticality Diagnostics may provide optional protocol-level details.
Failure is the alternative response when the DU rejects the CU configuration update procedure.
The main decode path is Transaction ID for correlation, then Criticality Diagnostics if present. Interpret the ACK together with the original gNB-CU Configuration Update.
gNB-CU Configuration Update Acknowledge - Example Dump
Treat this as a teaching example based on the expected message structure, not as a captured network trace.
Acknowledge means the DU accepted the CU configuration update procedure.
Always correlate Transaction ID with the original gNB-CU Configuration Update.
If Criticality Diagnostics is present, inspect it for non-fatal IE or procedure handling details.
Important Information Elements
IE
Presence
Description
Message Type
Mandatory
Identifies the F1AP PDU as gNB-CU CONFIGURATION UPDATE ACKNOWLEDGE.
Transaction ID
Mandatory
Correlates the acknowledge message with the original gNB-CU Configuration Update request.
Criticality Diagnostics
Optional
Optional protocol-level diagnostics for IE handling, semantic interpretation, or non-fatal procedure issues.
Detailed field explanation
Message Type
Identifies the F1AP PDU as gNB-CU CONFIGURATION UPDATE ACKNOWLEDGE.
Presence: Mandatory
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.
Transaction ID
Correlates the acknowledge message with the original gNB-CU Configuration Update request.
Presence: Mandatory
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 protocol-level diagnostics for IE handling, semantic interpretation, or non-fatal procedure issues.
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 ACK follows a matching gNB-CU Configuration Update.
Check that Transaction ID matches the original update.
Verify CU TNL association or transport changes are reflected correctly after the ACK.
Decode Criticality Diagnostics if present.
Confirm no Failure appears for the same transaction.
Verify the F1 interface remains stable after the accepted update.
Do not confuse this with gNB-DU Configuration Update Acknowledge.
Common Issues and Troubleshooting
The ACK cannot be matched to the original CU update.
Likely cause: Transaction ID mismatch, missing trace messages, or overlapping configuration procedures may be confusing correlation.
What to inspect: Compare Transaction ID, timestamps, SCTP stream/order, and the immediately preceding gNB-CU Configuration Update.
Next step: Do not infer acceptance until the ACK is matched to the correct update transaction.
Transport issues appear after the ACK.
Likely cause: The CU-side TNL association or transport endpoint change may have been accepted but still points to an unreachable, stale, or incorrectly referenced endpoint.
What to inspect: Check the original update, CU TNL association lists, IP reachability, SCTP endpoint state, and DU logs.
Next step: Validate the accepted transport path before chasing UE-level symptoms.
The CU repeats the same configuration update after ACK.
Likely cause: The CU may not have processed the ACK, a later OAM delta may have retriggered the procedure, or trace correlation may be incomplete.
What to inspect: Check Transaction ID sequence, duplicate update content, SCTP continuity, CU logs, and timing of OAM changes.
Next step: Separate duplicate retry behavior from intentional later CU-side configuration changes.
Engineers confuse this with gNB-DU Configuration Update Acknowledge.
Likely cause: Both messages are successful outcomes, but the original request direction and configuration ownership are opposite.
What to inspect: Check sender, procedureCode, and whether the original request was gNB-CU Configuration Update or gNB-DU Configuration Update.
Next step: Use this page for DU acceptance of CU-originated configuration changes; use DU Configuration Update ACK analysis for CU acceptance of DU-originated changes.
LTE / 5G / Variant Comparison
Compared with Failure
Acknowledge accepts the CU update procedure. Failure rejects it and should be interpreted through Cause and any retry guidance.
Compared with gNB-DU Configuration Update Acknowledge
gNB-CU Configuration Update Acknowledge is DU-to-CU and accepts CU-owned changes. gNB-DU Configuration Update Acknowledge is CU-to-DU and accepts DU-owned changes.
Compared with F1 Setup Response
F1 Setup Response accepts initial F1 onboarding. gNB-CU Configuration Update Acknowledge confirms post-setup configuration synchronization.
FAQ
What is gNB-CU Configuration Update Acknowledge in F1AP?
It is the F1AP successful outcome sent by the gNB-DU to the gNB-CU to confirm that a gNB-CU Configuration Update was successfully processed.
Who sends this message?
The gNB-DU sends gNB-CU Configuration Update Acknowledge to the gNB-CU.
What does Transaction ID do?
Transaction ID links the acknowledge message to the original gNB-CU Configuration Update request.
What is the response to gNB-CU Configuration Update?
The gNB-DU responds with gNB-CU Configuration Update Acknowledge if it accepts the update or gNB-CU Configuration Update Failure if it rejects the update.
What is Criticality Diagnostics?
Criticality Diagnostics is an optional IE that can provide protocol-level details about IE handling, semantic interpretation, or non-fatal procedure issues.
How is this different from gNB-DU Configuration Update Acknowledge?
gNB-CU Configuration Update Acknowledge is sent by the DU to accept CU-owned changes. gNB-DU Configuration Update Acknowledge is sent by the CU to accept DU-owned changes.
How is this different from F1 Setup Response?
F1 Setup Response accepts initial F1 interface setup. gNB-CU Configuration Update Acknowledge confirms a post-setup CU configuration update.
How do you troubleshoot configuration update acknowledgement issues?
Match Transaction ID with the original update, inspect the original CU TNL association or transport changes, decode Criticality Diagnostics if present, verify no Failure exists for the same transaction, and check F1 stability afterward.
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.
