gNB-DU Configuration Update Failure is the F1AP unsuccessful outcome sent by the gNB-CU to the gNB-DU when the CU cannot accept a DU configuration update.
Message Fact Sheet
Protocol
f1ap
Network
5g
Spec
3GPP TS 38.473
Spec Section
gNB-DU Configuration Update Failure message and gNB-DU Configuration Update procedure
Direction
gNB-CU -> gNB-DU
Message Type
gNB-DU Configuration / F1 Interface Management Message
The gNB-CU receives a gNB-DU Configuration Update but rejects served cell changes, cell status changes, TNL association updates, or other DU-side configuration information.
Main purpose
Rejects a DU configuration update, reports the failure reason using Cause, may prevent retry storms using Time to Wait, keeps CU/DU configuration consistent, and helps engineers identify cell, PLMN, slice, TNL, or protocol mismatches.
DU-side configuration synchronization, gNB-DU Configuration Update unsuccessful outcome, Served cell configuration rejection, TNL association update troubleshooting, Transaction ID and Cause correlation
What is gNB-DU Configuration Update Failure in simple terms?
gNB-DU Configuration Update Failure is the F1AP unsuccessful outcome sent by the gNB-CU to the gNB-DU when the CU cannot accept a DU configuration update.
Rejects a DU configuration update, reports the failure reason using Cause, may prevent retry storms using Time to Wait, keeps CU/DU configuration consistent, and helps engineers identify cell, PLMN, slice, TNL, or protocol mismatches.
Why this message matters
gNB-DU Configuration Update Failure means the CU rejected a DU configuration change after F1 setup. Match Transaction ID, read Cause first, and respect Time to Wait before retry.
Where this message appears in the call flow
gNB-DU Configuration Update
Failure branch: the CU rejects the DU configuration update and returns Cause, optional Time to Wait, and diagnostics.
Call flow position: The gNB-CU sends Failure after receiving a gNB-DU Configuration Update it cannot accept.
Typical state: The proposed DU configuration update is rejected and is not applied as an accepted update.
Preconditions:
The F1 interface is already established.
The DU sent gNB-DU Configuration Update.
The CU found a condition that prevents accepting the proposed update.
Next likely message: Configuration correction or delayed retry after Time to Wait
Configuration rejection diagnostics
Decode order: match Transaction ID, read Cause, then apply retry timing and diagnostics when present.
Call flow position: Transaction ID identifies the rejected update; Cause identifies the rejection domain.
Typical state: Trace analysis should inspect the original served-cell, cell-status, and TNL update content.
Preconditions:
Transaction ID is present in the update and failure.
Cause is decoded by the analyzer.
Criticality Diagnostics may be present for IE-level detail.
Next likely message: Corrected gNB-DU Configuration Update
Failure versus accepted update with cell activation issues
Outcome distinction: Failure rejects the update; ACK with failed cells accepts the update but reports cell-level activation exceptions.
Call flow position: Failure is a procedure-level rejection, while Acknowledge with failed cell activation is an accepted update with operational exceptions.
Typical state: The engineer should not treat a Failure as the same branch as Acknowledge carrying Cells Failed to be Activated List.
Preconditions:
The response PDU type is checked.
The original update transaction is matched.
Next likely message: Correct outcome classification
Call flow position
Previous message(s):gNB-DU Configuration Update, F1 interface is already established, gNB-CU validates served cells, cell status, TNL association changes, and DU-side configuration fields
Transport / encapsulation: F1AP over SCTP/IP between gNB-CU and gNB-DU
Security context: gNB-DU Configuration Update Failure does not establish a UE security context. It is a non-UE-associated unsuccessful outcome rejecting a DU-side configuration update after F1 setup.
Message Structure Overview
gNB-DU Configuration Update Failure is the unsuccessfulOutcome for the DU configuration update procedure.
It is sent from gNB-CU to gNB-DU after a matching gNB-DU Configuration Update.
Transaction ID ties the failure to the exact update attempt.
Cause is mandatory and is the main troubleshooting field.
Time to Wait and Criticality Diagnostics are optional but important when present.
ASN.1 for gNB-DU Configuration Update Failure
GNBDUConfigurationUpdateFailure ::= SEQUENCE {
protocolIEs ProtocolIE-Container { {GNBDUConfigurationUpdateFailure-IEs} },
...
}
GNBDUConfigurationUpdateFailure-IEs F1AP-PROTOCOL-IES ::= {
{ ID id-TransactionID CRITICALITY reject TYPE TransactionID PRESENCE mandatory } |
{ 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
Decode Transaction ID first to match the rejected update, then read Cause. Time to Wait controls retry behavior when present, and Criticality Diagnostics can point to a problematic IE or procedure condition.
gNB-DU Configuration Update Failure - Example Dump
Treat this as a teaching example based on the expected message structure, not as a captured network trace.
Failure means the update procedure was rejected, not accepted with partial cell activation issues.
Always correlate Transaction ID with the original gNB-DU Configuration Update.
If Time to Wait is present, the DU should not retry before the indicated delay.
Important Information Elements
IE
Presence
Description
Message Type
Mandatory
Identifies the F1AP PDU as gNB-DU CONFIGURATION UPDATE FAILURE.
Transaction ID
Mandatory
Correlates the failure with the original gNB-DU Configuration Update request.
Cause
Mandatory
Explains why the gNB-CU rejected the DU configuration update.
Time to Wait
Optional
Optional retry delay before the gNB-DU sends another configuration update.
Criticality Diagnostics
Optional
Optional protocol-level diagnostics for problematic IEs, procedure handling, or criticality behavior.
Detailed field explanation
Message Type
Identifies the F1AP PDU as gNB-DU CONFIGURATION UPDATE FAILURE.
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 failure with the original gNB-DU 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.
Cause
Explains why the gNB-CU rejected the DU configuration update.
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.
Time to Wait
Optional retry delay before the gNB-DU sends another configuration update.
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 protocol-level diagnostics for problematic IEs, procedure handling, or criticality behavior.
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 Failure follows a matching gNB-DU Configuration Update.
Check that Transaction ID matches the original update.
Decode Cause before diagnosing surrounding symptoms.
Verify Time to Wait is respected before retry.
Decode Criticality Diagnostics if present.
Validate served cell add, modify, and delete lists in the original update.
Validate cell status and TNL association changes.
Confirm previous accepted configuration remains consistent after rejection.
Common Issues and Troubleshooting
The DU repeatedly sends the same update and receives Failure.
Likely cause: The DU may be retrying before Time to Wait expires or resending an unchanged invalid configuration.
What to inspect: Compare Transaction ID sequence, retry timestamps, repeated Cause values, and original update content.
Next step: Respect retry backoff and correct the served cell, PLMN/TAC/slice, TNL, or IE problem indicated by Cause.
The failure points to cell configuration.
Likely cause: The update may contain invalid served cell add/modify/delete combinations, duplicate NR CGI, unsupported cell status, or PLMN/TAC/slice mismatch.
What to inspect: Decode Served Cells to Add/Modify/Delete lists, Cells Status List, NR CGI, PLMN ID, TAC, slice support, and OAM state.
Next step: Correct the DU-side cell inventory or cell parameters, then send a new update.
The failure appears after TNL changes.
Likely cause: The DU may have advertised invalid, stale, duplicate, or unsupported transport association information.
What to inspect: Check gNB-DU TNL Association to Add/Remove/Update lists, IP endpoints, SCTP state, and transport reachability.
Next step: Fix the transport association data and confirm the CU can accept the new TNL state.
Engineers confuse Failure with ACK containing failed activation list.
Likely cause: Both can appear after gNB-DU Configuration Update, but one is procedure rejection and the other is accepted update with operational exceptions.
What to inspect: Check F1AP PDU type: unsuccessfulOutcome for Failure, successfulOutcome for Acknowledge.
Next step: Use Cause for Failure; use Cells Failed to be Activated List only when the response is Acknowledge.
LTE / 5G / Variant Comparison
Compared with Acknowledge
Acknowledge accepts the update procedure. Failure rejects the update procedure and carries Cause.
Compared with F1 Setup Failure
F1 Setup Failure rejects initial F1 setup. gNB-DU Configuration Update Failure rejects a later update after the F1 interface already exists.
Compared with ACK containing failed cells
ACK with Cells Failed to be Activated List is an accepted procedure with cell-level activation exceptions; Failure is procedure-level rejection.
FAQ
What is gNB-DU Configuration Update Failure in F1AP?
It is the F1AP unsuccessful outcome sent by the gNB-CU to the gNB-DU when the CU rejects a DU configuration update.
Who sends this message?
The gNB-CU sends gNB-DU Configuration Update Failure to the gNB-DU.
What message triggers it?
It is triggered by a gNB-DU Configuration Update that the gNB-CU cannot accept.
What does the Cause IE mean?
Cause explains why the CU rejected the update, such as invalid cell configuration, PLMN/TAC/slice mismatch, transport problem, protocol error, or another unsupported condition.
What is Time to Wait used for?
Time to Wait tells the DU how long to wait before retrying the configuration update, helping avoid repeated failed update attempts.
Does this failure mean the F1 interface is down?
Not necessarily. It rejects the proposed update, but the F1 interface may remain established using the previous accepted configuration.
How is this different from F1 Setup Failure?
F1 Setup Failure rejects initial F1 interface establishment. gNB-DU Configuration Update Failure rejects a later DU configuration change after setup exists.
How is this different from Acknowledge with failed cell activation?
Failure means the update procedure was rejected. Acknowledge means the update was accepted, even if it includes Cells Failed to be Activated List for selected cells.
How do you troubleshoot repeated configuration update failures?
Match Transaction ID, decode Cause first, inspect the original update lists and TNL changes, respect Time to Wait, check Criticality Diagnostics if present, and correct the DU configuration before retry.
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.
