UE Context Modification Confirm is the F1AP message the gNB-CU sends to the gNB-DU to report successful update of the UE context after UE Context Modification Required.
Message Fact Sheet
Protocol
f1ap
Network
5g
Spec
3GPP TS 38.473
Spec Section
Section 8.3.5 and UE Context Modification Confirm message
Direction
gNB-CU -> gNB-DU successfulOutcome
Message Type
UE-associated confirmation of DU-triggered context modification handling
Full message name
UE Context Modification Confirm
Protocol
F1AP
Technology
5G
Direction
gNB-CU -> gNB-DU successfulOutcome
Interface
F1-C
Signaling bearer / channel
UE-associated F1AP signaling / SCTP carried F1AP successfulOutcome for the UE Context Modification Required procedure
Typical trigger
The gNB-DU sends UE Context Modification Required and the gNB-CU successfully updates or accepts the resulting UE context handling, then reports that outcome in UE Context Modification Confirm.
Main purpose
Reports successful UE context update after a DU-triggered modification requirement, tells the DU that CU-side handling has completed, synchronizes CU and DU UE context state, returns successful DRB modification and resource coordination details when present, and prevents unnecessary retry or refuse handling.
What is UE Context Modification Confirm in simple terms?
UE Context Modification Confirm is the F1AP message the gNB-CU sends to the gNB-DU to report successful update of the UE context after UE Context Modification Required.
Reports successful UE context update after a DU-triggered modification requirement, tells the DU that CU-side handling has completed, synchronizes CU and DU UE context state, returns successful DRB modification and resource coordination details when present, and prevents unnecessary retry or refuse handling.
Why this message matters
UE Context Modification Confirm is the CU saying the DU-triggered modification requirement was handled successfully. Match it to UE Context Modification Required, then inspect optional DRB and coordination details.
Where this message appears in the call flow
Successful follow-up to Modification Required
Procedure branch: Modification Confirm is the CU successful outcome after the DU initiates Modification Required.
Call flow position: After the gNB-DU sends UE Context Modification Required, the gNB-CU uses UE Context Modification Confirm to report successful update of the UE context.
Typical state: The DU-triggered modification path is accepted and the CU/DU UE context view should now be synchronized.
Preconditions:
The UE context already exists.
The gNB-DU sent UE Context Modification Required.
Both UE F1AP IDs identify the same UE-associated signaling connection.
Next likely message: Normal UE-associated operation or a later modification/release procedure
Resource and bearer confirmation
Resource branch: inspect DRB Modified List, returned UL tunnel details, and coordination data when present.
Call flow position: The confirm may return successful DRB modification information, UL UP TNL details, resource coordination information, and optional diagnostics.
Typical state: The DU can apply the confirmed CU-side update details for the active UE context.
Preconditions:
The required message included bearer, tunnel, or resource coordination details that need CU-side confirmation.
Next likely message: Traffic continues using the confirmed resources
Confirm versus Required and Failure
Branch distinction: Required starts DU-triggered handling, Confirm reports CU success, and Failure belongs to a different CU-initiated branch.
Call flow position: Confirm is the successful outcome to a DU-triggered Required procedure. It is not the same branch as UE Context Modification Failure, which rejects a CU-initiated request.
Typical state: Trace analysis should separate DU-triggered required/confirm handling from CU-initiated request/response/failure handling.
Preconditions:
A UE context modification event is in progress, and direction/procedure code must be checked.
Next likely message: No retry for the same Required transaction unless later state changes
Sender and receiver: gNB-CU -> gNB-DU successfulOutcome
Interface: F1-C
Domain: CU-DU UE context modification confirmation and resource coordination
Signaling bearer: UE-associated F1AP signaling
Logical channel: SCTP carried F1AP successfulOutcome for the UE Context Modification Required procedure
Transport / encapsulation: F1AP over SCTP/IP between gNB-CU and gNB-DU
Security context: UE Context Modification Confirm does not establish NAS security. It confirms CU-side handling of a DU-triggered UE context modification requirement for an already existing UE context.
Message Structure Overview
UE Context Modification Confirm is the successfulOutcome of the UE Context Modification Required procedure.
The direction is gNB-CU to gNB-DU because the CU reports successful update after the DU initiated Modification Required.
The mandatory core is Message Type plus both UE F1AP IDs.
DRB Modified List and Resource Coordination Transfer Container are optional details that identify confirmed bearer or coordination handling.
This message is distinct from UE Context Modification Response, which is the DU response to a CU-initiated UE Context Modification Request.
This page follows the TS 38.473 mapping used by the site templates: Required is DU to CU; Confirm is CU to DU successfulOutcome.
Implementation note: this page uses the TS 38.473 UE Context Modification Required mapping, where UE Context Modification Confirm is the gNB-CU to gNB-DU successful outcome. It should not be parsed as the gNB-DU response to UE Context Modification Request; that branch uses UE Context Modification Response or Failure.
Treat this as a teaching example based on the expected message structure, not as a captured network trace.
Confirm follows UE Context Modification Required, not the ordinary UE Context Modification Request branch.
Match both UE F1AP IDs before interpreting DRB Modified List or resource coordination details.
If the CU cannot perform the requested modification, the paired unsuccessful branch is UE Context Modification Refuse.
Important Information Elements
IE
Presence
Description
Message Type
Mandatory
Identifies the F1AP PDU as UE CONTEXT MODIFICATION CONFIRM.
gNB-CU UE F1AP ID
Mandatory
Mandatory CU-side UE identifier used to correlate the confirm with the active UE context and the preceding UE Context Modification Required message.
gNB-DU UE F1AP ID
Mandatory
Mandatory DU-side UE identifier for the existing UE context being confirmed.
Resource Coordination Transfer Container
Optional
Optional resource coordination information transferred by the CU for EN-DC, NGEN-DC, NE-DC, or MR-DC coordination handling when applicable.
DRB Modified List
Optional
Optional list of DRBs successfully modified, including returned UL UP TNL information where applicable.
RRC-Container
Optional
Optional RRC container included when the confirm needs the DU to deliver related RRC content to the UE.
SRB ID
Optional
Conditionally relevant when RRC-Container is present, identifying the SRB used for the carried RRC message.
Execute Duplication
Optional
Optional indication asking the DU to perform configured duplication for the SRB carrying the included RRC container.
Criticality Diagnostics
Optional
Optional protocol diagnostics for non-fatal IE handling or procedure interpretation details.
Detailed field explanation
Message Type
Identifies the F1AP PDU as UE CONTEXT MODIFICATION CONFIRM.
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.
gNB-CU UE F1AP ID
Mandatory CU-side UE identifier used to correlate the confirm with the active UE context and the preceding UE Context Modification Required message.
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.
gNB-DU UE F1AP ID
Mandatory DU-side UE identifier for the existing UE context being confirmed.
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.
Resource Coordination Transfer Container
Optional resource coordination information transferred by the CU for EN-DC, NGEN-DC, NE-DC, or MR-DC coordination handling when applicable.
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.
DRB Modified List
Optional list of DRBs successfully modified, including returned UL UP TNL information where applicable.
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.
RRC-Container
Optional RRC container included when the confirm needs the DU to deliver related RRC content to the UE.
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.
SRB ID
Conditionally relevant when RRC-Container is present, identifying the SRB used for the carried RRC message.
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.
Execute Duplication
Optional indication asking the DU to perform configured duplication for the SRB carrying the included RRC container.
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 diagnostics for non-fatal IE handling or procedure interpretation details.
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 follows a matching UE Context Modification Required message.
gNB-CU UE F1AP ID and gNB-DU UE F1AP ID match the active UE context.
DRB Modified List is consistent with the bearer details requested by the DU.
Resource Coordination Transfer Container is decoded if present.
No UE Context Modification Refuse exists for the same required transaction.
Resulting UE resource state is synchronized between CU and DU.
Common Issues and Troubleshooting
No confirm appears after UE Context Modification Required.
Likely cause: The CU may be delaying, refusing, or failing to process the DU-triggered modification requirement.
What to inspect: Check for UE Context Modification Refuse, Error Indication, procedure collisions, CU policy logs, and SCTP ordering around the Required message.
Next step: Determine whether the CU should send Confirm, Refuse, or another recovery procedure.
DRB state remains inconsistent after confirm.
Likely cause: The DRB Modified List or returned UL tunnel information may not match the DU-side requested bearer change.
What to inspect: Compare UE Context Modification Required, DRB Modified List, UL UP TNL information, and later user-plane behavior.
Next step: Correct the bearer or tunnel parameters and trigger a new modification flow if needed.
Engineers confuse Confirm with Modification Response.
Likely cause: Both are successful outcomes in UE context modification families, but they answer different initiating messages.
What to inspect: Check the preceding message: Modification Required for Confirm, Modification Request for Response.
Next step: Classify the procedure branch before comparing fields or declaring the trace successful.
LTE / 5G / Variant Comparison
Compared with UE Context Modification Required
Required is the DU asking for a modification. Confirm is the CU reporting successful update after that request.
Compared with UE Context Modification Response
Response is the DU success answer to a CU-initiated Modification Request. Confirm is the CU success answer to a DU-initiated Modification Required.
Compared with UE Context Modification Failure
Failure rejects a CU-initiated modification request. Confirm reports success on the DU-initiated required branch.
FAQ
What is UE Context Modification Confirm in F1AP?
It is the successful outcome the gNB-CU sends to the gNB-DU after UE Context Modification Required to report successful UE context update.
Who sends UE Context Modification Confirm?
The gNB-CU sends UE Context Modification Confirm to the gNB-DU.
What message triggers this confirm?
UE Context Modification Required from the gNB-DU triggers this confirm on the successful branch.
What does DRB Modified List contain?
It identifies DRBs successfully modified and may include returned UL UP TNL information for the confirmed bearer handling.
Does Confirm mean the modification succeeded?
Yes, it reports successful CU handling of the DU-triggered UE context modification requirement.
How is this different from UE Context Modification Failure?
Modification Failure is the DU's unsuccessful outcome to a CU-initiated Modification Request. Modification Confirm is the CU's successful outcome to a DU-initiated Modification Required.
How is this different from UE Context Modification Required?
Modification Required is sent by the DU to request a change. Modification Confirm is sent by the CU to report that the requested update was handled successfully.
How do you troubleshoot missing Modification Confirm messages?
Check whether the preceding Required message was received, whether UE IDs match, whether the CU sent Refuse or Error Indication instead, and whether procedure collisions or transport ordering delayed the outcome.
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.
