Telecom engineering reference for protocols, messages, call flows, troubleshooting, releases, and tools.
Menu
NASLTEUE to MME or MME to UE3GPP TS 24.301
LTE Detach Request
Detach Request is the EPS NAS message used to release EPS mobility-management context, either when the UE starts detach itself or when the network orders the UE to detach.
Message Fact Sheet
Protocol
nas
Network
lte
Spec
3GPP TS 24.301
Spec Section
5.5.2, 8.2.11
Direction
UE to MME or MME to UE
Message Type
EMM signaling
Full message name
LTE Detach Request
Protocol
NAS
Technology
LTE
Direction
UE to MME or MME to UE
Interface
N1 over LTE access / S1-MME control path
Signaling bearer / channel
NAS signaling / Commonly carried on an existing protected NAS signaling path during registered-state detach handling.
Typical trigger
Triggered when the UE disables EPS service, powers off with detach signaling, requests combined detach, or when the network decides the UE must be detached.
Main purpose
Lets the detach procedure start with the detach type, identity context, and cause context that decide whether EPS services, non-EPS services, or both are being released and whether re-attach is expected later.
Detach Request is the EPS NAS message used to release EPS mobility-management context, either when the UE starts detach itself or when the network orders the UE to detach.
Lets the detach procedure start with the detach type, identity context, and cause context that decide whether EPS services, non-EPS services, or both are being released and whether re-attach is expected later.
Why this message matters
Detach Request is the LTE NAS message that starts release of EPS registration context, either because the UE wants to leave service or because the network tells it to detach.
Where this message appears in the call flow
UE-initiated EPS detach
In a UE-initiated EPS detach, the UE sends Detach Request to release EPS service and the network completes the branch with Detach Accept.
Call flow position: UE-originated detach-start message sent when the UE wants to release EPS service context from an already registered state.
Typical state: The UE has valid EPS registration context but is intentionally ending EPS service availability.
Preconditions:
The UE is already EPS-registered.
The UE selected a detach type that releases EPS service.
Next likely message: Detach Accept or local detach completion in switch-off handling
UE-initiated combined EPS / IMSI detach
In a combined EPS / IMSI detach, Detach Request tells the network that both EPS and non-EPS mobility context are being released together.
Call flow position: UE-originated detach-start message sent when the UE is releasing both EPS and non-EPS mobility context together.
Typical state: The UE is asking the network to end the broader mobility context rather than only EPS service.
Preconditions:
The UE is in a mode where combined detach is relevant.
The selected detach type indicates combined EPS / IMSI detach.
Next likely message: Detach Accept or detach completion depending on switch-off handling
UE switch-off detach
In switch-off detach, the UE sends Detach Request with switch-off indication and does not wait through the same detach-completion path as a normal detach.
Call flow position: UE-originated detach-start message sent with switch-off indication when the UE powers down and does not wait for normal detach completion signaling.
Typical state: The UE is leaving service because of power-off and does not continue normal signaling the same way as a non-switch-off detach.
Preconditions:
The UE is powering off.
The detach type indicates switch off.
Next likely message: No normal Detach Accept wait on the UE side
Network-initiated detach
In a network-initiated detach, the MME sends Detach Request and the UE responds with Detach Accept before moving into the detach result state.
Call flow position: Network-originated detach-start message sent when the MME tells the UE that existing EPS context must be released.
Typical state: The network is ending the current registration context rather than accepting normal service continuation.
Preconditions:
The UE already has an established EMM context.
The network decided that detach is required.
Next likely message: Detach Accept from the UE, bearer release, and deregistered continuation
Interface: N1 over LTE access / S1-MME control path
Domain: Core-side EPS mobility management signaling that moves the UE out of the current EPS registration context.
Signaling bearer: NAS signaling
Logical channel: Commonly carried on an existing protected NAS signaling path during registered-state detach handling.
Transport / encapsulation: EPS NAS message exchanged between UE and MME through the eNodeB as part of UE-initiated or network-initiated detach handling.
Security context: Detach Request normally appears after a valid EMM context already exists, so it is usually part of protected NAS continuation rather than early unauthenticated access.
Message Structure Overview
Detach Request is an EPS mobility-management message rather than an ASN.1 LTE RRC structure.
It has dual significance in TS 24.301: a UE-originated form and a network-originated form.
The practical reading path starts with who sent the message, then Detach type, then any identity or cause context that explains whether re-attach is expected.
ASN.1 Message Syntax for LTE Detach Request
Detach Request (UE originating detach)
Detach type
NAS key set identifier
EPS mobile identity
Detach Request (network initiated detach)
Detach type
EMM cause OPTIONAL
How to read this message syntax
Detach Request is a NAS layer-3 message, not an ASN.1 LTE RRC message. Read it first by variant: UE-originated detach carries identity context, while network-initiated detach carries detach type and may carry EMM cause.
LTE Detach Request - Example Dump
Detach Request
Protocol discriminator: EPS mobility management
Security header type: Integrity protected and ciphered
Message type: Detach Request
Detach type: EPS detach
NAS key set identifier: 7
EPS mobile identity: GUTI
How to read this dump
Start by deciding whether this is the UE-originated or network-initiated form.
Detach type is the highest-value field because it tells you what kind of mobility context is being released.
If the message came from the network, inspect any EMM cause next because it explains why detach was forced.
Important Information Elements
IE
Required
Description
Detach type
Yes
Tells the receiver whether the detach is EPS only, IMSI only, combined EPS / IMSI, switch-off related, or network initiated with re-attach implications.
NAS key set identifier
Optional
References the stored NAS security context in the UE-originated detach variant.
EPS mobile identity
Optional
Carries UE identity context when the UE starts the detach procedure.
Appears in the network-initiated detach variant to explain why the network is forcing detach.
Detailed field explanation
Detach type
Tells the receiver whether the detach is EPS only, IMSI only, combined EPS / IMSI, switch-off related, or network initiated with re-attach implications.
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.
NAS key set identifier
References the stored NAS security context in the UE-originated detach variant.
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.
EPS mobile identity
Carries UE identity context when the UE starts the detach procedure.
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.
EMM cause
Appears in the network-initiated detach variant to explain why the network is forcing detach.
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 who sent the message: UE or MME.
Inspect Detach type first.
If UE-originated, check NAS key set identifier and EPS mobile identity.
If network-initiated, inspect EMM cause and whether re-attach is required.
Correlate the message with Detach Accept, bearer cleanup, and the later deregistered or re-attach branch.
Common Issues and Troubleshooting
The UE suddenly leaves EPS service even though radio access looked healthy.
Likely cause: A network-initiated Detach Request may have forced the UE out of the registered state.
What to inspect: Check the sender, Detach type, and any EMM cause returned by the network.
Next step: Treat it as a detach branch first, not as a radio failure.
The UE powers off and no Detach Accept appears.
Likely cause: The UE may have used switch-off detach, where normal detach-completion signaling is not followed in the same way.
What to inspect: Check whether the Detach type indicates switch off.
Next step: Do not expect a normal Detach Accept wait if the trace is a switch-off detach case.
The network detach is followed by fast re-attach in one case but not another.
Likely cause: The Detach type and any EMM cause may indicate whether re-attach is required or not required.
What to inspect: Compare network-initiated Detach Request values across working and failing traces.
Next step: Read the detach branch together with the later Attach Request or the absence of it.
LTE / 5G / Variant Comparison
Compared with Attach Request
Attach Request builds or rebuilds EPS registration context. Detach Request starts releasing that context.
Compared with Tracking Area Update Reject
Tracking Area Update Reject blocks a mobility refresh path. Detach Request explicitly ends the current EPS registration context.
Compared with Service Reject
Service Reject can deny immediate service restoration while keeping broader context assumptions in play. Detach Request starts a real detach branch that ends the current EPS registration state.
FAQ
What is Detach Request in LTE?
It is the EPS NAS message that starts release of EPS registration context, either from the UE side or from the network side.
Why does Detach Request have dual significance?
Because TS 24.301 defines both a UE-originated Detach Request and a network-initiated Detach Request.
What should I inspect first in Detach Request?
Start with who sent the message, then read Detach type, then any identity or EMM cause information.
What usually comes after Detach Request?
That depends on the variant: normal detach often continues with Detach Accept, while switch-off detach and some network-forced cases move directly into local release behavior.
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.
