5G E1AP - Bearer Context Modification Request

Message Fact Sheet

Protocol	e1ap	Network	5g
Spec	3GPP TS 37.483	Spec Section	Bearer Context Modification procedure and related IE definitions (Release 18 baseline)
Direction	gNB-CU-CP -> gNB-CU-UP initiatingMessage	Message Type	UE-associated bearer-context change control

Full message name	5G E1AP - Bearer Context Modification Request
Protocol	E1AP
Technology	5G
Direction	gNB-CU-CP -> gNB-CU-UP initiatingMessage
Interface	E1 between gNB-CU-CP and gNB-CU-UP
Signaling bearer / channel	UE-associated E1AP signaling / SCTP carried E1AP initiatingMessage
Typical trigger	The CU-CP needs to change an established bearer context because of DRB reconfiguration, QoS adjustment, path change, forwarding control, handover preparation, or other user-plane evolution.
Main purpose	Updates an already existing CU-UP bearer context so the user plane follows new DRB, QoS, forwarding, or transport requirements without rebuilding the whole bearer context from scratch.
Main specification	3GPP TS 37.483, Bearer Context Modification procedure and related IE definitions (Release 18 baseline)
Release added	Release 17
Procedures where used	DRB reconfiguration, QoS change handling, User-plane path adjustment, Forwarding control

What is Bearer Context Modification Request in simple terms?

Bearer Context Modification Request is the E1AP message the gNB-CU-CP sends to the gNB-CU-UP to change an existing bearer context, including DRB, QoS, forwarding, and transport-related user-plane updates.

Updates an already existing CU-UP bearer context so the user plane follows new DRB, QoS, forwarding, or transport requirements without rebuilding the whole bearer context from scratch.

Why this message matters

Bearer Context Modification Request is the CU-CP telling the CU-UP to change bearer state that already exists.

Where this message appears in the call flow

Existing bearer-context reconfiguration

5G E1AP flow showing the gNB-CU-CP sending Bearer Context Modification Request to change existing bearer state at the gNB-CU-UP — Reconfiguration branch: the CU-CP changes an already established bearer context instead of creating a new one.

Call flow position: The bearer context already exists at the CU-UP and the CU-CP needs to change it in place.

Typical state: The CU-UP must preserve bearer continuity while applying the requested change set.

Preconditions:

Both CU-CP and CU-UP UE E1AP IDs are known.
A bearer context already exists at the CU-UP.

Next likely message: Bearer Context Modification Response

Bearer-context delta handling

5G E1AP flow showing Bearer Context Modification Request applying bearer-context deltas at the gNB-CU-UP — Delta branch: the modification request changes selected parts of existing bearer state at the CU-UP rather than rebuilding the whole context.

Call flow position: The modification request updates one or more parts of the existing bearer context without rebuilding the whole CU-UP branch.

Typical state: The CU-UP must reconcile the new control-plane intent with the already active bearer state.

Preconditions:

The CU-CP has identified the bearer items to be changed.
The requested user-plane update fits the CU-UP capabilities and current bearer state.

Next likely message: Bearer Context Modification Response or Bearer Context Modification Failure

Call flow position

Previous message(s): Bearer Context Setup Response, Earlier Bearer Context Modification Request

Next message(s): Bearer Context Modification Response, Bearer Context Modification Failure, Bearer Context Release Command

Message direction and transport

Sender and receiver: gNB-CU-CP -> gNB-CU-UP initiatingMessage

Interface: E1 between gNB-CU-CP and gNB-CU-UP

Domain: CU-CP / CU-UP bearer maintenance and user-plane evolution

Signaling bearer: UE-associated E1AP signaling

Logical channel: SCTP carried E1AP initiatingMessage

Transport / encapsulation: E1AP over SCTP/IP between gNB-CU-CP and gNB-CU-UP

Security context: Bearer Context Modification Request updates bearer and user-plane handling at the CU-UP. It does not itself create NAS security.

Message Structure Overview

Bearer Context Modification Request updates an existing bearer context rather than creating a new one.
Both UE E1AP identifiers are mandatory because the CU-UP bearer context already exists.
The main decoding task is to identify exactly which parts of the bearer model are being changed.

ASN.1 for 5G E1AP - Bearer Context Modification Request

BearerContextModificationRequest ::= SEQUENCE {
  protocolIEs ProtocolIE-Container { {BearerContextModificationRequest-IEs} },
  ...
}

BearerContextModificationRequest-IEs E1AP-PROTOCOL-IES ::= {
  { gNB-CU-CP UE E1AP ID, mandatory } |
  { gNB-CU-UP UE E1AP ID, mandatory } |
  { System Bearer Context Modification Request, mandatory } |
  { Bearer Context Status Change, optional },
  ...
}

How to read this ASN.1

Read modification as a delta-control message. The exact operational meaning depends on what the nested bearer payload is trying to add, remove, or adjust.

5G E1AP - Bearer Context Modification Request - Example Dump

E1AP-PDU
  initiatingMessage
    procedureCode: id-bearerContextModification
    criticality: reject
    value: BearerContextModificationRequest
      protocolIEs:
        - id: id-gNB-CU-CP-UE-E1AP-ID
          value: 0x00004192
        - id: id-gNB-CU-UP-UE-E1AP-ID
          value: 0x00000087
        - id: id-System-BearerContextModificationRequest
          value:
            pdu-session-list:
              - pdu-session-id: 10
                drb-to-modify-list:
                  - drb-id: 4
                    qos-flow-list:
                      - qfi: 9
        - id: id-BearerContextStatusChange
          value: modified

How to read this dump

Modification only makes sense relative to existing bearer state, so correlate it with the earlier setup result first.
Focus on which branch is being changed: DRB, QoS, forwarding, or transport handling.
A successful modification outcome does not guarantee every requested bearer item changed in the way the CU-CP expected.

Important Information Elements

IE	Required	Description
`gNB-CU-CP UE E1AP ID`	Yes	Mandatory CU-CP side UE identifier used to correlate the modification request with the existing bearer context.
`gNB-CU-UP UE E1AP ID`	Yes	Mandatory CU-UP side UE identifier because the modification operates on an already existing bearer context.
`System Bearer Context Modification Request`	Yes	Mandatory bearer payload that describes which bearer, QoS, forwarding, or transport branches must change at the CU-UP.
`Bearer Context Status Change`	Optional	Optional status-oriented control that can influence how the CU-UP interprets or reports the bearer state transition.

Detailed field explanation

`gNB-CU-CP UE E1AP ID`

Mandatory CU-CP side UE identifier used to correlate the modification request with the existing bearer context.

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-CU-UP UE E1AP ID`

Mandatory CU-UP side UE identifier because the modification operates on an already existing bearer context.

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.

`System Bearer Context Modification Request`

Mandatory bearer payload that describes which bearer, QoS, forwarding, or transport branches must change at the CU-UP.

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.

`Bearer Context Status Change`

Optional status-oriented control that can influence how the CU-UP interprets or reports the bearer state transition.

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 E1AP IDs before reading the modification payload.
Compare the modification payload with the previously established bearer context.
Identify whether the request is primarily changing QoS, DRB state, or transport / forwarding behavior.

Common Issues and Troubleshooting

The bearer remains active, but the expected user-plane change never appears.

Likely cause: The modification request may not have carried the intended bearer delta, or the CU-UP may not have accepted the requested change fully.

What to inspect: Compare the modification request against the earlier setup state and the later modification response.

Next step: Drive debugging from the requested delta and the returned result rather than from the old baseline alone.

LTE / 5G / Variant Comparison

Compared with Bearer Context Setup Request

Setup creates bearer state. Modification changes bearer state that already exists at the CU-UP.

FAQ

What is Bearer Context Modification Request in 5G E1AP?

It is the E1AP message the gNB-CU-CP sends to the gNB-CU-UP to change an already existing bearer context.

What is mandatory in Bearer Context Modification Request?

The key mandatory fields are the CU-CP UE E1AP ID, the CU-UP UE E1AP ID, and the system bearer context modification payload.

Related message pages

Related Procedures

Related Tools

Use This Reference in Practice

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.