Telecom engineering reference for protocols, messages, call flows, troubleshooting, releases, and tools.
Menu
NASLTEUE to MME3GPP TS 24.301
LTE Activate Dedicated EPS Bearer Context Accept
Activate Dedicated EPS Bearer Context Accept is the EPS session-management message the UE sends to confirm that the dedicated bearer requested by the network was accepted and activated successfully.
Message Fact Sheet
Protocol
nas
Network
lte
Spec
3GPP TS 24.301
Spec Section
6.4.2.3, 8.3.1
Direction
UE to MME
Message Type
ESM signaling
Full message name
LTE Activate Dedicated EPS Bearer Context Accept
Protocol
NAS
Technology
LTE
Direction
UE to MME
Interface
N1 over LTE access / S1-MME control path
Signaling bearer / channel
NAS signaling / Commonly carried in uplink NAS transport after the UE receives Activate Dedicated EPS Bearer Context Request for an already active PDN connection.
Typical trigger
Sent after the UE receives Activate Dedicated EPS Bearer Context Request, validates the returned bearer definition, and activates the dedicated bearer successfully.
Main purpose
Confirms successful UE-side activation of the dedicated bearer so the network can stop T3485 supervision and mark the bearer active.
What is LTE Activate Dedicated EPS Bearer Context Accept in simple terms?
Activate Dedicated EPS Bearer Context Accept is the EPS session-management message the UE sends to confirm that the dedicated bearer requested by the network was accepted and activated successfully.
Confirms successful UE-side activation of the dedicated bearer so the network can stop T3485 supervision and mark the bearer active.
Why this message matters
Activate Dedicated EPS Bearer Context Accept is the UE telling the network that the requested dedicated bearer was accepted and activated successfully.
Where this message appears in the call flow
Dedicated bearer activation for an active PDN
Once the UE accepts the dedicated bearer definition, Activate Dedicated EPS Bearer Context Accept closes the bearer-activation branch for that active PDN connection.
Call flow position: UE confirmation sent after the network returned a dedicated bearer definition on top of an already active default bearer.
Typical state: The dedicated bearer definition was accepted and the UE is now confirming that the new bearer is active.
Preconditions:
A linked default EPS bearer is already active.
The UE could validate the returned TFT and QoS.
Next likely message: Dedicated bearer active service continuation
IMS or service-specific QoS bearer acceptance
For IMS or another service-specific flow, Activate Dedicated EPS Bearer Context Accept confirms that the UE activated the dedicated bearer returned by the network.
Call flow position: UE acceptance sent after the network creates a dedicated bearer for IMS or another service-specific traffic flow.
Typical state: The service-specific bearer branch is closing and the network can now treat the dedicated bearer as active.
Preconditions:
The relevant PDN connection is active.
The UE accepted the dedicated bearer definition for the service flow.
Next likely message: Service-specific traffic continues over the active dedicated bearer
UE requested bearer resource continuation
After a bearer resource procedure, Activate Dedicated EPS Bearer Context Accept confirms that the returned dedicated bearer was activated successfully and the branch can close.
Call flow position: UE confirmation branch used when a bearer resource allocation or modification procedure resulted in dedicated bearer creation.
Typical state: The network has turned the earlier resource request into a dedicated bearer, and the UE is confirming successful activation.
Preconditions:
A UE requested bearer resource procedure led to dedicated bearer setup.
The UE accepted the linked bearer, QoS, and TFT definition.
Next likely message: Bearer resource procedure completion and dedicated bearer use
Next message(s): Dedicated bearer active service continuation, Protected user-plane service, Bearer resource procedure completion
Message direction and transport
Sender and receiver: UE to MME
Interface: N1 over LTE access / S1-MME control path
Domain: Core-side EPS session management signaling that closes the dedicated bearer activation branch.
Signaling bearer: NAS signaling
Logical channel: Commonly carried in uplink NAS transport after the UE receives Activate Dedicated EPS Bearer Context Request for an already active PDN connection.
Transport / encapsulation: EPS NAS ESM message sent by the UE and delivered to the MME through the eNodeB as part of dedicated bearer activation completion.
Security context: Activate Dedicated EPS Bearer Context Accept appears after PDN connectivity is already active, so it is normally seen in protected NAS continuation rather than in early access signaling.
Message Structure Overview
Activate Dedicated EPS Bearer Context Accept is an EPS session-management message rather than an ASN.1 LTE RRC structure.
The practical reading path starts with the accepted EPS bearer identity and the earlier request it answers.
In real traces, this message tells you the dedicated bearer activation branch closed cleanly and T3485 supervision can stop.
Activate Dedicated EPS Bearer Context Accept is a NAS layer-3 ESM message, not an ASN.1 LTE RRC message. It is structurally small, so the main value is its timing, presence, and relation to the earlier dedicated bearer request.
LTE Activate Dedicated EPS Bearer Context Accept - Example Dump
Start by tying the accepted EPS bearer identity back to the earlier Activate Dedicated EPS Bearer Context Request.
If PTI was present in the request, use it to connect the accept back to the earlier bearer resource procedure.
When the network keeps retransmitting the request, this message is one of the first checkpoints to verify because it stops T3485 supervision.
Important Information Elements
IE
Required
Description
EPS bearer identity
Yes
Identifies the dedicated bearer that the UE accepted and activated.
Protocol configuration options
Optional
May carry additional configuration information associated with the accepted dedicated bearer.
Detailed field explanation
EPS bearer identity
Identifies the dedicated bearer that the UE accepted and activated.
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.
Protocol configuration options
May carry additional configuration information associated with the accepted dedicated bearer.
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 accept follows the expected Activate Dedicated EPS Bearer Context Request.
Check which dedicated bearer identity was accepted.
Correlate the accept with the earlier linked default bearer and TFT/QoS branch.
Verify that request retransmissions stopped after this message.
If the branch still looks unstable, compare it with reject handling or later bearer release behavior.
Common Issues and Troubleshooting
A dedicated bearer appears requested, but service-specific QoS never becomes stable.
Likely cause: The accept may be missing, delayed, or not reaching the network cleanly, so the bearer activation branch never closes.
What to inspect: Check the earlier dedicated bearer request, the accepted bearer identity, and whether the request was retransmitted under T3485.
Next step: Treat the issue as a dedicated bearer completion problem before assuming the QoS policy alone is wrong.
IMS or another prioritized service keeps falling back to the default bearer.
Likely cause: The network may have returned a dedicated bearer definition, but the UE may not have completed activation successfully.
What to inspect: Compare the request and accept timing, bearer identity, and whether repeated requests appear.
Next step: Read the trace as dedicated bearer activation plus service flow mapping, not only as an IMS problem.
A UE requested bearer resource procedure looks accepted but does not produce a usable bearer.
Likely cause: The network may have created the dedicated bearer, but the accept branch may be missing or delayed.
What to inspect: Check the earlier bearer resource context, the PTI in the request, and whether this accept arrives for the same branch.
Next step: Follow the dedicated bearer activation end to end before concluding the resource procedure itself failed.
LTE / 5G / Variant Comparison
Compared with Activate Dedicated EPS Bearer Context Request
Activate Dedicated EPS Bearer Context Request is the network instruction. Activate Dedicated EPS Bearer Context Accept is the UE confirmation that the requested dedicated bearer is now active.
Compared with Activate Default EPS Bearer Context Accept
Activate Default EPS Bearer Context Accept closes setup of the first bearer for a PDN connection. Activate Dedicated EPS Bearer Context Accept closes activation of another bearer linked to that existing default bearer.
Compared with PDN Connectivity Request
PDN Connectivity Request starts PDN access and default bearer setup. Activate Dedicated EPS Bearer Context Accept appears later when the network has added a service-specific bearer on top of that PDN connection.
FAQ
What is Activate Dedicated EPS Bearer Context Accept in LTE?
It is the EPS NAS session-management message the UE sends to confirm that the requested dedicated bearer was accepted and activated.
What should I inspect first in this message?
Start with its timing and EPS bearer identity, then tie it back to the earlier dedicated bearer request.
Why is this message important in troubleshooting?
Because it confirms whether the UE actually completed dedicated bearer activation, which decides whether the network can stop waiting under T3485.
What usually happens after this message?
The network treats the dedicated bearer as active and service-specific traffic can start using it.
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.
