UE Context Modification Response is the successful outcome the gNB-DU returns after applying an F1AP UE Context Modification Request, confirming which requested SRBs, DRBs, SCells, relay channels, multicast resources, or sidelink resources were established or modified successfully, which ones failed, what DU-to-CU RRC information the CU must use next, and which mobility or transmission-control related results such as Requested Target Cell ID, C-RNTI, or SCG Activation Status were produced.
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)
Direction
gNB-DU -> gNB-CU successfulOutcome
Message Type
UE-associated context modification confirmation and result reporting
The gNB-DU successfully applied enough of UE Context Modification Request to keep the procedure successful and now has to report which requested changes were realized, which failed, and what DU-generated RRC or mobility feedback the gNB-CU must consume.
Main purpose
Confirms that the gNB-DU successfully handled UE context modification at procedure level and reports the exact resulting bearer, transport, RRC, and mobility state the gNB-CU must use next.
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
Post-setup bearer reconfiguration over F1, DRB establishment and modification confirmation, DU-side downlink F1-U anchor return, Conditional mobility and LTM feedback, SCG activation confirmation, RLC reestablishment and lower-layer update reporting
What is UE Context Modification Response in simple terms?
UE Context Modification Response is the successful outcome the gNB-DU returns after applying an F1AP UE Context Modification Request, confirming which requested SRBs, DRBs, SCells, relay channels, multicast resources, or sidelink resources were established or modified successfully, which ones failed, what DU-to-CU RRC information the CU must use next, and which mobility or transmission-control related results such as Requested Target Cell ID, C-RNTI, or SCG Activation Status were produced.
Confirms that the gNB-DU successfully handled UE context modification at procedure level and reports the exact resulting bearer, transport, RRC, and mobility state the gNB-CU must use next.
Why this message matters
UE Context Modification Response is the DU’s successful result message telling the CU what the live UE context looks like after modification, not just whether the request was accepted.
Where this message appears in the call flow
Procedure-level modification succeeded
Acceptance branch: the DU keeps the procedure successful and returns the updated UE context result instead of a modification failure.
Call flow position: The gNB-DU could perform the request at procedure level, so it returns a successful outcome instead of UE Context Modification Failure.
Typical state: The UE-associated F1 signaling context remains alive and the CU can continue using the updated DU-side state.
Preconditions:
At least some requested modification work succeeded sufficiently for the overall procedure to be accepted.
The DU accepted the essential context, including any required SpCell or mobility semantics.
Next likely message: DL RRC Message Transfer or later UE Context Modification
Per-resource result reporting
Bearer branch: the response separates successful setup, successful modification, and failed results while returning DU-side downlink tunnel anchors.
Call flow position: The DU reports setup, modified, failed-to-setup, and failed-to-modify results separately for the requested resources.
Typical state: The CU must inspect the response lists item-by-item before assuming a bearer, SCell, relay channel, or multicast resource is usable.
Preconditions:
The request included at least one establish, modify, or release action for DRBs, SRBs, BH RLC channels, relay channels, SL DRBs, or multicast resources.
The DU finished enough bearer work to return precise result lists.
Next likely message: CU-side continuation using the confirmed setup and modified lists while respecting failed items
RRC and mobility feedback to the CU
Control branch: the response tells the CU how the DU actually realized the requested reconfiguration, including lower-layer, identity, and mobility-significant output.
Call flow position: The DU returns DU-to-CU RRC information, requested-target-cell feedback, SCG activation status, or reestablishment information that affects CU behavior.
Typical state: The response is both a result report and a control input to the CU’s next RRC or mobility decision.
Preconditions:
The request included RRC, measurement, SCG, conditional mobility, CPAC, or LTM-related content that requires DU feedback.
The DU generated the corresponding lower-layer or mobility output.
Next likely message: RRC delivery to the UE or a follow-up mobility-related procedure
Transport / encapsulation: F1AP over SCTP/IP between gNB-CU and gNB-DU
Security context: UE Context Modification Response does not create NAS security. It confirms the resulting DU-side UE radio and bearer state after a modification request and returns the control information the gNB-CU needs for subsequent RRC, transport, and mobility actions.
Message Structure Overview
UE Context Modification Response is the successfulOutcome of the modification procedure and confirms the resulting DU-side state after the requested changes were applied.
The message starts with both UE F1AP IDs, then may include Resource Coordination Transfer Container and DU To CU RRC Information before the detailed result lists.
Result reporting is richer than setup alone because modification can return both setup and modified success lists plus failed-to-setup and failed-to-modify lists in the same message.
Successful DRB items are operationally critical because they return the gNB-DU side downlink F1-U tunnel endpoints for both newly established and modified DRBs.
Optional feedback such as C-RNTI, RLC Status, Requested Target Cell ID, SCG Activation Status, and Full Configuration changes how the CU interprets the response and what it does next.
A successful response still does not mean every requested change worked. The CU must check each relevant success and failure list before continuing.
ASN.1 for 5G F1AP - UE Context Modification Response
The response is large because it can report results for newly established resources, modified resources, and failed items across several bearer families in the same successful outcome. For trace reading, focus on the IDs, DU-to-CU RRC information, DRB setup or modified lists, failure lists, and mobility-significant feedback.
5G F1AP - UE Context Modification Response - Example Dump
Read modification response at two levels: first confirm the procedure succeeded, then separate successful setup, successful modification, failed setup, and failed modification results.
For each successful DRB or modified DRB, the most important returned payload is usually the DL UP TNL information because it is the DU-side anchor for downlink F1-U transport.
If RLC Status, Requested Target Cell ID, or SCG Activation Status is present, treat the response as more than a bearer report because it changes what the CU should do next.
Important Information Elements
IE
Required
Description
gNB-CU UE F1AP ID
Yes
Mandatory CU-side UE identifier used to correlate the successful outcome with the original UE Context Modification Request.
gNB-DU UE F1AP ID
Yes
Mandatory DU-side UE identifier for the already established UE context being modified.
DU To CU RRC Information
Optional
Optional but often operationally central DU-originated RRC container. It always includes CellGroupConfig when present and can also return MeasGapConfig, DRX values, MUSIM gap information, ServCellInfoList, SDT-related configuration, and other lower-layer outputs.
DRB Setup List
Optional
Optional list of DRBs that were successfully established during modification. Each successful item returns the DU-side downlink F1-U tunnel endpoints.
DRB Modified List
Optional
Optional list of DRBs that were successfully modified. Each item can return new DL tunnel anchors, LCID, RLC reestablishment state, and optional traffic or congestion feedback.
DL UP TNL Information to Be Setup List
Yes
Mandatory inside successful DRB setup or modified items. It identifies the gNB-DU endpoint for downlink F1-U transport using transport address and GTP TEID.
RLC Status
Optional
Optional indication that RLC has been re-established at the gNB-DU for the affected DRB, which may trigger PDCP data recovery at the CU side.
SRB Setup List / SRB Modified List
Optional
Optional lists of successfully established or modified SRBs. LCID is included for the primary path when PDCP duplication or multi-path relay behavior is relevant.
SRB Failed to be Setup List
Optional
Optional list of SRBs that failed to be established, each with SRB ID and optional cause.
DRB Failed to be Setup List / DRB Failed to be Modified List
Optional
Optional failure lists for DRB establishment and modification results, each carrying the DRB ID and optional precise cause.
C-RNTI
Optional
Optional C-RNTI allocated at the gNB-DU. If present, the CU shall consider that the DU allocated it for this UE context.
Associated SCell List
Optional
Optional list that can be returned when RLC failure or related reestablishment handling causes the DU to report SCells associated with the affected RLC entity.
Full Configuration
Optional
Optional indicator that the DU generated CellGroupConfig using full configuration rather than a delta-like update.
Requested Target Cell ID
Optional
Optional target-cell echo returned for conditional mobility, CPAC, LTM, or related path-preparation cases where the request carried target-cell meaning.
SCG Activation Status
Optional
Optional status telling the CU whether SCG resources are activated or deactivated after a request that included SCG activation control.
Detailed field explanation
gNB-CU UE F1AP ID
Mandatory CU-side UE identifier used to correlate the successful outcome 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 being modified.
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.
DU To CU RRC Information
Optional but often operationally central DU-originated RRC container. It always includes CellGroupConfig when present and can also return MeasGapConfig, DRX values, MUSIM gap information, ServCellInfoList, SDT-related configuration, and other lower-layer outputs.
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 Setup List
Optional list of DRBs that were successfully established during modification. Each successful item returns the DU-side downlink F1-U tunnel endpoints.
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 that were successfully modified. Each item can return new DL tunnel anchors, LCID, RLC reestablishment state, and optional traffic or congestion feedback.
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.
DL UP TNL Information to Be Setup List
Mandatory inside successful DRB setup or modified items. It identifies the gNB-DU endpoint for downlink F1-U transport using transport address and GTP TEID.
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.
RLC Status
Optional indication that RLC has been re-established at the gNB-DU for the affected DRB, which may trigger PDCP data recovery at the CU side.
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 Setup List / SRB Modified List
Optional lists of successfully established or modified SRBs. LCID is included for the primary path when PDCP duplication or multi-path relay behavior is relevant.
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 Failed to be Setup List
Optional list of SRBs that failed to be established, each with SRB ID and optional cause.
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 Failed to be Setup List / DRB Failed to be Modified List
Optional failure lists for DRB establishment and modification results, each carrying the DRB ID and optional precise cause.
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.
C-RNTI
Optional C-RNTI allocated at the gNB-DU. If present, the CU shall consider that the DU allocated it for this UE context.
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.
Associated SCell List
Optional list that can be returned when RLC failure or related reestablishment handling causes the DU to report SCells associated with the affected RLC entity.
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.
Full Configuration
Optional indicator that the DU generated CellGroupConfig using full configuration rather than a delta-like 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.
Requested Target Cell ID
Optional target-cell echo returned for conditional mobility, CPAC, LTM, or related path-preparation cases where the request carried target-cell meaning.
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.
SCG Activation Status
Optional status telling the CU whether SCG resources are activated or deactivated after a request that included SCG activation control.
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
Match both UE F1AP IDs with the original request before inspecting resource results.
Read DU To CU RRC Information early because it carries the DU-generated lower-layer output the CU must consume before further RRC actions.
For every affected DRB, compare DRB Setup List, DRB Modified List, DRB Failed to be Setup List, and DRB Failed to be Modified List before deciding what the UE can use.
If C-RNTI, Full Configuration, or RLC Status is present, verify the CU-side handling reflects those returned values instead of assuming the previous state still applies.
When mobility or path preparation was involved, inspect Requested Target Cell ID and SCG Activation Status directly rather than inferring the result from the original request.
Common Issues and Troubleshooting
The procedure succeeded, but a bearer still behaves as if nothing changed.
Likely cause: The requested DRB may have landed in a failed-to-be-modified list, or the CU may not have consumed the returned DL tunnel or RLC reestablishment information correctly.
What to inspect: Check DRB Modified List first, then read DL UP TNL information and RLC Status for the affected DRB and compare them with the previous live state.
Next step: Treat the response as the authoritative DU-side declaration of the resulting bearer state and update CU-side assumptions accordingly.
The overall modification looks successful, but one new resource is missing later.
Likely cause: The DU may have succeeded at procedure level while reporting partial failure in SRB Failed to be Setup List, DRB Failed to be Setup List, SCell Failed To Setup List, or the corresponding relay-channel lists.
What to inspect: Review both success and failure lists, not just the existence of a successfulOutcome.
Next step: Proceed only with confirmed items and correct or retry the failed request elements separately if needed.
The CU continues with the wrong mobility or SCG assumption after modification.
Likely cause: Requested Target Cell ID or SCG Activation Status may show a different realized state than the request intended.
What to inspect: Read Requested Target Cell ID, SCG Activation Status, and any DU To CU RRC Information related to the mobility or SCG change.
Next step: Drive post-modification CU behavior from the returned outcome, not from the original request intent.
LTE / 5G / Variant Comparison
Compared with UE Context Modification Request
The request describes the intended changes. The response reports which changes were actually established or modified, which ones failed, and which DU-generated control outputs the CU must use next.
Compared with UE Context Modification Failure
The response means the modification procedure succeeded at procedure level. Failure means none of the requested modifications could be successfully performed or the essential mobility or SpCell conditions could not be accepted.
Compared with UE Context Setup Response
Setup response confirms initial context creation. Modification response reports ongoing evolution of an already active context and therefore includes both setup and modified result lists plus optional reestablishment feedback.
FAQ
What is UE Context Modification Response in 5G F1AP?
It is the successful outcome the gNB-DU sends after it successfully applies UE Context Modification Request and needs to report the resulting bearer, RRC, and mobility state back to the gNB-CU.
Who sends UE Context Modification Response?
The gNB-DU sends it to the gNB-CU over F1-C.
What is mandatory in UE Context Modification Response?
The mandatory core is gNB-CU UE F1AP ID and gNB-DU UE F1AP ID. DU To CU RRC Information is optional in the message table, but often operationally important when present.
What does the response return for modified DRBs?
It returns successful modified DRBs in DRB Modified List, including the DU-side downlink F1-U endpoint information and optional feedback such as RLC Status, TSC feedback, or ECN reporting status.
Can UE Context Modification Response still contain failures?
Yes. The procedure can succeed while the response still reports individual DRBs, SRBs, SCells, BH RLC channels, relay channels, or sidelink resources in failed-to-setup or failed-to-be-modified lists.
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.
