UE Context Modification Failure is the F1AP unsuccessful outcome the gNB-DU sends when a UE Context Modification Request cannot be accepted at procedure level, meaning none of the requested UE-context changes can be successfully performed or an essential mobility or SpCell condition makes the request invalid for execution.
Message Fact Sheet
Protocol
f1ap
Network
5g
Spec
3GPP TS 38.473
Spec Section
Section 8.3.4 and sections 9.2.2.7 to 9.2.2.9 (Release 18 baseline)
The gNB-DU cannot perform any of the requested UE context modifications, cannot accept the requested SpCell ID, or detects mobility-specific precondition failures such as missing SpCell information for CHO or LTM-related modification.
Main purpose
Reports that the gNB-DU could not accept the requested UE context modification procedure and returns the cause information the gNB-CU needs to retry, correct the request, fall back, or abort the modification branch.
Main specification
3GPP TS 38.473, Section 8.3.4 and sections 9.2.2.7 to 9.2.2.9 (Release 18 baseline)
Release added
Release 15
Procedures where used
Failed UE context modification, SpCell rejection during modification, CHO and CPAC target-cell failure handling, LTM-related modification rejection, F1AP request semantic failure recovery
What is UE Context Modification Failure in simple terms?
UE Context Modification Failure is the F1AP unsuccessful outcome the gNB-DU sends when a UE Context Modification Request cannot be accepted at procedure level, meaning none of the requested UE-context changes can be successfully performed or an essential mobility or SpCell condition makes the request invalid for execution.
Reports that the gNB-DU could not accept the requested UE context modification procedure and returns the cause information the gNB-CU needs to retry, correct the request, fall back, or abort the modification branch.
Why this message matters
UE Context Modification Failure means the gNB-DU rejected the whole modification procedure, so the CU must inspect the cause and fix or abandon the request instead of expecting resource result lists.
Where this message appears in the call flow
Whole-procedure rejection
Procedure branch: the DU rejects the modification at procedure level and returns Cause instead of any result lists.
Call flow position: The request reached the gNB-DU, but the modification cannot be accepted at procedure level, so the DU returns unsuccessfulOutcome instead of a successful response.
Typical state: The UE-associated F1 signaling context still exists, but the requested modification branch did not take effect.
Preconditions:
UE Context Modification Request was received for an already active UE context.
The DU concluded that none of the requested modifications can be successfully performed or that a mandatory acceptance condition is missing.
Next likely message: Corrected UE Context Modification Request or alternate recovery handling
SpCell or mobility acceptance failure
Mobility branch: target-cell acceptance problems, missing SpCell dependencies, or LTM-triggered conflicts force the unsuccessful outcome.
Call flow position: The request carries SpCell, CHO, CPAC, or LTM semantics that the DU cannot accept consistently.
Typical state: The modification fails because the target-cell anchor is unacceptable, absent when required, or conflicts with an ongoing LTM-driven state.
Preconditions:
The request included SpCell-related or Conditional Intra-DU Mobility Information content.
The DU detected a blocking mobility rule or target-cell acceptance problem.
Next likely message: Retry with corrected target-cell context or abandon the attempted mobility branch
Request semantic or decoding issue
Diagnostics branch: Cause and optional Criticality Diagnostics tell the CU whether to correct the request, retry later, or abandon the branch.
Call flow position: The request includes missing or logically inconsistent information that prevents safe execution and may justify Criticality Diagnostics.
Typical state: The DU rejects the procedure and reports the root cause instead of attempting a partial modification at procedure level.
Preconditions:
At least one critical request element was missing, not comprehended, or semantically inconsistent for the requested branch.
The error blocked the procedure itself rather than only one bearer item.
Next likely message: Corrected request after CU-side validation
Transport / encapsulation: F1AP over SCTP/IP between gNB-CU and gNB-DU
Security context: UE Context Modification Failure does not establish or refresh NAS security. It reports that the DU could not accept the requested radio, bearer, or mobility change for the already active UE context.
Message Structure Overview
UE Context Modification Failure is the unsuccessfulOutcome branch of UE Context Modification and is sent by the gNB-DU to the gNB-CU.
The practical mandatory core is both UE F1AP IDs plus Cause. Everything else is supplemental failure detail.
Failure means procedure-level rejection, not per-resource failure inside an otherwise successful modification.
If none of the requested modifications can be successfully performed, the DU sends this message instead of UE Context Modification Response.
The message can optionally include Criticality Diagnostics for IE-level problems and Requested Target Cell ID for CHO-initiation failure cases.
There is no modification result list in this message. If the DU can keep the procedure successful and report per-item failures, that belongs in UE Context Modification Response instead.
ASN.1 for 5G F1AP - UE Context Modification Failure
The message is intentionally small because failure is reported at procedure level. If you see bearer-by-bearer success and failure lists, you are looking at UE Context Modification Response instead.
5G F1AP - UE Context Modification Failure - Example Dump
Read Cause first. It tells you whether the failure is a radio acceptance problem, a protocol error, a transport issue, or a miscellaneous system problem.
If Requested Target Cell ID is present, interpret the failure in the mobility branch. The DU is identifying the target cell associated with the rejected CHO-initiation request.
If Criticality Diagnostics is present, compare it directly with the original request to find the exact missing or not-understood IE.
Important Information Elements
IE
Required
Description
gNB-CU UE F1AP ID
Yes
Mandatory CU-side UE identifier that correlates the failure with the original UE Context Modification Request.
gNB-DU UE F1AP ID
Yes
Mandatory DU-side UE identifier for the already established UE context whose modification failed.
Cause
Yes
Mandatory F1AP cause that explains why the DU rejected the procedure, typically using radio network, protocol, transport, or miscellaneous cause families.
Criticality Diagnostics
Optional
Optional diagnostics used when the DU needs to report missing, not understood, or logically inconsistent information elements in the triggering request.
Requested Target Cell ID
Optional
Optional NR CGI returned when the failed request carried Conditional Intra-DU Mobility Information set to CHO-initiation. In that case the DU echoes the received SpCell ID as the requested target cell in the failure.
Detailed field explanation
gNB-CU UE F1AP ID
Mandatory CU-side UE identifier that correlates the failure with the original UE Context Modification Request.
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.
gNB-DU UE F1AP ID
Mandatory DU-side UE identifier for the already established UE context whose modification failed.
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.
Cause
Mandatory F1AP cause that explains why the DU rejected the procedure, typically using radio network, protocol, transport, or miscellaneous cause families.
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.
Criticality Diagnostics
Optional diagnostics used when the DU needs to report missing, not understood, or logically inconsistent information elements in the triggering request.
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.
Requested Target Cell ID
Optional NR CGI returned when the failed request carried Conditional Intra-DU Mobility Information set to CHO-initiation. In that case the DU echoes the received SpCell ID as the requested target cell in the failure.
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
Correlate both UE F1AP IDs with the exact UE Context Modification Request before diagnosing the failure.
Read Cause before anything else and classify the failure domain.
Check whether the request was attempting whole-procedure mobility handling, especially SpCell replacement, CHO, CPAC, or LTM.
If Requested Target Cell ID is present, compare it with the request-side SpCell ID to confirm which target-cell branch failed.
If Criticality Diagnostics is present, inspect the missing or not-understood IE rather than retrying the same malformed request.
Common Issues and Troubleshooting
The DU rejects UE Context Modification immediately after receiving the request.
Likely cause: A mandatory procedure-level condition is missing or unacceptable, such as an invalid SpCell branch, inconsistent UE IDs, or a semantic issue in the request itself.
What to inspect: Check Cause first, then compare SpCell, Conditional Intra-DU Mobility Information, and any criticality diagnostics against the original request.
Next step: Correct the blocking semantics before retrying. Repeating the same request will usually produce the same failure.
The CU expected partial bearer failures in a response but received failure instead.
Likely cause: The DU determined the procedure itself could not be accepted, not just one bearer item.
What to inspect: Verify whether none of the requested modifications could be successfully performed or whether a mandatory mobility condition blocked the whole request.
Next step: Treat this as a branch-level rejection and rebuild the request rather than looking for DRB result lists that cannot exist in this message.
Modification fails only for CHO or LTM-related requests.
Likely cause: The request may be missing required SpCell context, the DU may not accept the target SpCell, or an LTM command may already be triggered.
What to inspect: Review Conditional Intra-DU Mobility Information, SpCell ID presence, Requested Target Cell ID, and cause values such as cell-not-available or ltm-command-triggered.
Next step: Reissue the request only after the mobility prerequisites and DU state are aligned with the intended target-cell operation.
LTE / 5G / Variant Comparison
Compared with UE Context Modification Response
Response means the procedure succeeded at procedure level and can still include partial per-resource failures. Failure means the DU rejected the procedure itself.
Compared with UE Context Modification Request
The request expresses intended changes. Failure is the DU's negative verdict that those changes cannot be accepted under current state or request semantics.
Compared with UE Context Modification Required
Failure is a DU response to a CU-initiated request. UE Context Modification Required is a separate DU-initiated message asking the CU to change the context.
FAQ
What is UE Context Modification Failure in 5G F1AP?
It is the unsuccessful outcome the gNB-DU sends to the gNB-CU when a UE Context Modification Request cannot be accepted at procedure level.
Who sends UE Context Modification Failure?
The gNB-DU sends it to the gNB-CU over F1-C.
What is mandatory in UE Context Modification Failure?
The mandatory IEs are Message Type, gNB-CU UE F1AP ID, gNB-DU UE F1AP ID, and Cause. In practical trace reading, the two UE IDs and Cause are the core fields to inspect.
When does the DU send failure instead of response?
The DU sends failure when none of the requested modifications can be successfully performed or when required SpCell or mobility conditions make the procedure unacceptable. If the procedure can still succeed and only some items fail, the DU uses UE Context Modification Response instead.
Why would Requested Target Cell ID appear in the failure?
For the CHO-initiation branch, the spec says the DU includes the received SpCell ID as Requested Target Cell ID in the failure so the CU can identify the rejected target-cell context.
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.
