The gNB-DU detects a radio, resource, bearer, scheduling, transport, or configuration condition that requires the gNB-CU to modify the existing UE context.
Main purpose
Informs the CU that UE context update is needed, reports DU-side inability to maintain the current UE configuration as-is, enables controlled modification handling, supports radio and resource adaptation, and avoids silent DU-side resource inconsistencies.
DU resource rebalancing, QoS adaptation, DRB or SRB parameter update, Mobility-related reconfiguration, Radio optimization, Scheduler and resource coordination updates
What is UE Context Modification Required in simple terms?
UE Context Modification Required is the F1AP initiating message sent by the gNB-DU to the gNB-CU when the DU needs changes to an existing UE context.
Informs the CU that UE context update is needed, reports DU-side inability to maintain the current UE configuration as-is, enables controlled modification handling, supports radio and resource adaptation, and avoids silent DU-side resource inconsistencies.
Why this message matters
UE Context Modification Required means the DU is asking the CU to modify an existing UE context. It is a trigger, so read Cause first and then look for the CU's UE Context Modification Request.
Where this message appears in the call flow
DU-triggered UE context adaptation
Trigger branch: the DU reports that the active UE context needs modification, then the CU decides and sends the formal request.
Call flow position: The UE context already exists and the gNB-DU sends UE Context Modification Required when it needs the gNB-CU to initiate a controlled context change.
Typical state: The current UE configuration can no longer be maintained as-is, but the context is not directly modified by this message.
Preconditions:
The F1 interface is operational.
Both gNB-CU UE F1AP ID and gNB-DU UE F1AP ID identify an existing UE context.
The DU has detected a radio, bearer, resource, or configuration condition requiring a CU decision.
Next likely message: UE Context Modification Request
Cause and affected bearer analysis
Troubleshooting branch: decode Cause first, then inspect bearer lists and resource coordination information.
Call flow position: Cause explains why modification is needed, while optional DRB/SRB required-to-be-modified lists identify the affected bearers.
Typical state: The CU has enough DU-side context to evaluate whether to modify bearers, adjust resource coordination, or use another recovery path.
Preconditions:
Cause is present.
Optional DRB, SRB, or resource coordination details may identify what needs to change.
Next likely message: UE Context Modification Request with updated bearer or resource parameters
Required versus failure distinction
Outcome distinction: Required is a DU-triggered request for change; Failure is a negative response after a CU modification attempt.
Call flow position: Modification Required appears before a CU-initiated modification attempt, while Modification Failure appears after a CU request could not be accepted.
Typical state: The message is a DU-originated trigger, not a negative response to a request.
Preconditions:
The DU is requesting adaptation rather than rejecting a just-received modification request.
Next likely message: CU-side evaluation, then UE Context Modification Request or release handling
Transport / encapsulation: F1AP over SCTP/IP between gNB-CU and gNB-DU
Security context: UE Context Modification Required does not establish NAS or AS security. It reports a DU-side need to modify an already existing UE context and normally leads the CU to initiate the formal modification procedure.
Message Structure Overview
UE Context Modification Required is sent by the gNB-DU to the gNB-CU for an already established UE context.
It requests CU-controlled modification; it does not directly modify the DU-side UE context by itself.
Both UE F1AP IDs are mandatory because the message applies to an existing UE-associated context.
Cause is mandatory and should be decoded first because it explains why the DU needs the change.
Optional DRB and SRB required-to-be-modified lists identify bearer-specific changes the DU wants the CU to address.
The typical follow-up is UE Context Modification Request from the CU to the DU.
The message is compact because it is a trigger for a later CU-controlled modification. The practical decode order is both UE IDs, Cause, then optional resource coordination and bearer lists.
Treat this as a teaching example based on the expected message structure, not as a captured network trace.
Cause is the first troubleshooting field because it tells the CU why the DU is requesting adaptation.
The presence of DRB or SRB required-to-be-modified lists narrows the follow-up modification request to affected bearers.
This message does not itself update the context; look for a later UE Context Modification Request.
Important Information Elements
IE
Presence
Description
Message Type
Mandatory
Identifies the F1AP PDU as UE CONTEXT MODIFICATION REQUIRED.
gNB-CU UE F1AP ID
Mandatory
Mandatory UE identifier allocated by the gNB-CU and used to correlate this message with the existing UE context.
gNB-DU UE F1AP ID
Mandatory
Mandatory UE identifier allocated by the gNB-DU for the existing DU-side UE context.
Cause
Mandatory
Mandatory reason why the DU requires UE context modification. Decode this field first in troubleshooting.
Resource Coordination Transfer Container
Optional
Optional resource coordination information related to the requested modification.
DRBs Required To Be Modified List
Optional
Optional list identifying data radio bearers that need modification.
SRBs Required To Be Modified List
Optional
Optional list identifying signalling radio bearers that need modification.
Detailed field explanation
Message Type
Identifies the F1AP PDU as UE CONTEXT MODIFICATION REQUIRED.
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 UE identifier allocated by the gNB-CU and used to correlate this message with the existing UE context.
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 UE identifier allocated by the gNB-DU for the existing DU-side UE context.
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
Mandatory reason why the DU requires UE context modification. Decode this field first in troubleshooting.
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 related to the requested modification.
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.
DRBs Required To Be Modified List
Optional list identifying data radio bearers that need modification.
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.
SRBs Required To Be Modified List
Optional list identifying signalling radio bearers that need modification.
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 UE context already exists before UE Context Modification Required appears.
Verify gNB-CU UE F1AP ID and gNB-DU UE F1AP ID match the active UE context.
Decode Cause first and classify the DU-side reason for modification.
Inspect DRBs Required To Be Modified List and SRBs Required To Be Modified List if present.
Decode Resource Coordination Transfer Container if present.
Check whether a follow-up UE Context Modification Request appears.
Verify the resulting UE configuration becomes consistent after the modification procedure.
Common Issues and Troubleshooting
UE Context Modification Required repeats for the same UE.
Likely cause: The CU may not be sending a corrective modification request, or the modification does not address the DU-side resource or bearer condition.
What to inspect: Compare Cause values, DRB/SRB lists, follow-up modification requests, and DU resource state across repeated messages.
Next step: Adjust the CU-side modification parameters or resolve the underlying DU resource condition before the loop continues.
No UE Context Modification Request follows.
Likely cause: The CU may be suppressing the requested change, waiting for another procedure, or choosing release/recovery handling instead.
What to inspect: Check CU policy logs, procedure collisions, Cause, and any later UE Context Release Command or Error Indication.
Next step: Confirm whether CU logic intentionally ignored, delayed, or replaced the requested modification.
Bearer mismatch remains after modification.
Likely cause: The follow-up request may not have included the DRBs or SRBs identified by the DU, or the response may have partial failures.
What to inspect: Compare required-to-be-modified lists with the later UE Context Modification Request and Response or Failure.
Next step: Align the requested bearer changes with the DU-provided required lists and verify the response outcome.
LTE / 5G / Variant Comparison
Compared with UE Context Modification Request
Modification Required asks the CU to start a modification. Modification Request is the CU command that actually executes the selected changes at the DU.
Compared with UE Context Modification Failure
Modification Required appears before modification execution. Modification Failure appears after a CU-initiated modification request could not be accepted.
Compared with UE Context Release Request
Modification Required tries to preserve and adapt the UE context. Release Request asks to remove the UE context entirely.
FAQ
What is UE Context Modification Required in F1AP?
It is the F1AP message the gNB-DU sends to the gNB-CU when an existing UE context needs modification due to DU-side radio, resource, bearer, or configuration conditions.
Who sends UE Context Modification Required?
The gNB-DU sends UE Context Modification Required to the gNB-CU over F1-C.
What causes this message?
Common causes include radio condition changes, resource optimization, DRB or SRB reconfiguration needs, QoS or resource mismatch, mobility-related adaptation, transport limitations, interference, or scheduling changes.
Does this message directly modify the UE context?
No. It requests the CU to initiate modification. The actual context change is normally executed later through UE Context Modification Request.
What does the Cause IE mean?
Cause explains why the DU requires modification and should be the first field decoded in troubleshooting.
What are DRBs Required To Be Modified?
They are data radio bearers that the DU identifies as needing modification in the existing UE context.
How is this different from UE Context Modification Failure?
Modification Required is a DU-triggered request before modification execution. Modification Failure reports that a CU-initiated modification request could not be accepted.
How is this different from UE Context Release Request?
Modification Required attempts to preserve and adapt the UE context, while UE Context Release Request asks to remove the UE context entirely.
How do you troubleshoot repeated modification-required messages?
Check that the UE IDs match, decode Cause first, compare DRB and SRB required-to-be-modified lists with the follow-up Modification Request, and verify whether the resulting response actually corrected the DU-side condition.
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.
