LTE Detach Accept | NAS Message

Message Fact Sheet

Protocol	nas	Network	lte
Spec	3GPP TS 24.301	Spec Section	5.5.2, 8.2.10
Direction	MME to UE or UE to MME	Message Type	EMM signaling

Full message name	LTE Detach Accept
Protocol	NAS
Technology	LTE
Direction	MME to UE or UE to MME
Interface	N1 over LTE access / S1-MME control path
Signaling bearer / channel	NAS signaling / Commonly carried on an existing protected NAS signaling path during normal detach completion handling.
Typical trigger	Triggered when a normal detach branch reaches its completion point after Detach Request and the receiving side confirms the detach result.
Main purpose	Closes the normal detach branch, stops the relevant detach supervision timer, and confirms that the current EPS registration context is being left.
Main specification	3GPP TS 24.301, 5.5.2, 8.2.10
Release added	Release 8
Procedures where used	UE Initiated Detach Procedure, Network Initiated Detach Procedure, Combined EPS / IMSI Detach
Related timers	T3421, T3422

What is LTE Detach Accept in simple terms?

Detach Accept is the EPS NAS message used to confirm that the detach procedure has been completed, either as the network response to a UE-originated detach or as the UE response to a network-initiated detach.

Closes the normal detach branch, stops the relevant detach supervision timer, and confirms that the current EPS registration context is being left.

Why this message matters

Detach Accept is the LTE NAS message that confirms the detach procedure has been completed.

Where this message appears in the call flow

UE-initiated EPS detach completion

LTE NAS flow showing UE initiated detach completed by network Detach Accept — In a normal UE-initiated EPS detach, Detach Accept is the network message that closes the detach branch and lets the UE leave the registered EPS state.

Call flow position: Network completion message sent after the UE initiated a normal EPS detach and the detach branch reaches its acceptance point.

Typical state: The network is confirming that EPS detach is complete and the UE can leave the registered EPS state.

Preconditions:

The UE sent Detach Request.
The detach branch was a normal detach rather than switch-off detach.

Next likely message: Local detach completion and EMM-DEREGISTERED continuation

UE-initiated combined EPS / IMSI detach completion

LTE NAS flow showing combined EPS IMSI detach completed by Detach Accept — In combined detach, Detach Accept closes the broader mobility-release branch after the UE requested combined EPS / IMSI detach.

Call flow position: Completion message sent after the UE requested combined detach and the network acknowledges the broader mobility release.

Typical state: The detach branch is closing with combined mobility-context release rather than only EPS release.

Preconditions:

The UE sent Detach Request with combined detach type.
The procedure is not the switch-off case.

Next likely message: Detached continuation or later combined re-registration behavior

Network-initiated detach completion

LTE NAS flow showing network initiated detach completed by UE Detach Accept — In a network-initiated detach, the UE sends Detach Accept to confirm that the network-forced detach branch has been completed.

Call flow position: UE completion message sent after the MME initiated detach and the UE confirms that the detach procedure has been completed.

Typical state: The UE is confirming that it will leave the current registered EPS state because the network forced detach.

Preconditions:

The MME sent network-initiated Detach Request.
The UE is completing the requested detach branch.

Next likely message: Local detach completion, bearer cleanup, or re-attach if required by detach type

Call flow position

Previous message(s): Detach Request, Network-initiated detach continuation, UE-initiated detach continuation

Next message(s): EMM-DEREGISTERED continuation, Attach Request, Combined tracking area update with IMSI attach

Message direction and transport

Sender and receiver: MME to UE or UE to MME

Interface: N1 over LTE access / S1-MME control path

Domain: Core-side EPS mobility management signaling that confirms completion of the detach procedure.

Signaling bearer: NAS signaling

Logical channel: Commonly carried on an existing protected NAS signaling path during normal detach completion handling.

Transport / encapsulation: EPS NAS message exchanged between UE and MME through the eNodeB as the completion message for detach handling.

Security context: Detach Accept normally appears after a valid EMM context already existed, so it is usually part of protected NAS continuation rather than early access signaling.

Message Structure Overview

Detach Accept is an EPS mobility-management message rather than an ASN.1 LTE RRC structure.
It is structurally simple because the message mainly signals detach completion rather than carrying a detailed IE set.
The practical reading path starts with who sent it, which detach branch it closes, and which timer it stops.

ASN.1 Message Syntax for LTE Detach Accept

Detach Accept

How to read this message syntax

Detach Accept is a NAS layer-3 message, not an ASN.1 LTE RRC message. It is mainly a completion signal: the meaning comes from the detach branch around it, not from a large IE payload.

LTE Detach Accept - Example Dump

Detach Accept
  Protocol discriminator: EPS mobility management
  Security header type: Integrity protected and ciphered
  Message type: Detach Accept

How to read this dump

Start by confirming whether this Detach Accept came from the network or from the UE.
Then correlate it with the earlier Detach Request to decide whether it closes UE-initiated or network-initiated detach.
The real value of this message is the detach branch it closes and the timer it stops, not optional payload fields.

What to check in logs and traces

Confirm which Detach Request this Detach Accept belongs to.
Check sender direction first.
Confirm whether the branch is UE-initiated detach or network-initiated detach.
Correlate the message with T3421 or T3422 stopping.
Check whether the next branch is local detach completion only or immediate re-attach behavior.

Common Issues and Troubleshooting

Detach Request is seen but the procedure never looks cleanly completed.

Likely cause: Detach Accept may be missing, delayed, or suppressed because the branch was switch-off detach instead of normal completion.

What to inspect: Check whether the detach branch should produce Detach Accept at all, and correlate with T3421 or T3422 behavior.

Next step: Separate normal detach from switch-off detach before assuming protocol failure.

The UE leaves service after a network detach and immediately starts re-attach.

Likely cause: The network-initiated Detach Accept closed the detach branch cleanly, and the earlier detach type may require re-attach.

What to inspect: Read Detach Accept together with the earlier network-initiated Detach Request and detach type context.

Next step: Treat the re-attach as part of the detach outcome rather than a separate unexpected branch.

Combined detach traces look different from EPS-only detach traces.

Likely cause: Detach Accept may close a broader combined mobility release rather than only EPS release.

What to inspect: Compare the earlier Detach type and the later registration behavior.

Next step: Read the full detach pair before deciding whether the UE only left EPS service or left broader mobility context.

LTE / 5G / Variant Comparison

Compared with Detach Request

Detach Request starts the detach procedure. Detach Accept confirms that the normal detach branch has been completed.

Compared with Attach Request

Detach Accept ends an existing registration context. Attach Request starts building a new one.

Compared with Tracking Area Update Request

Tracking Area Update Request preserves and refreshes existing EPS context. Detach Accept confirms the end of the current EPS registration context.

FAQ

What is Detach Accept in LTE?

It is the EPS NAS message that confirms detach procedure completion.

Who sends Detach Accept?

That depends on the branch. In UE-initiated detach it is sent by the network, and in network-initiated detach it is sent by the UE.

Does switch-off detach always have Detach Accept?

No. Switch-off detach does not follow the same normal detach-completion behavior, so you should not expect the same accept pattern.

What should I inspect first in Detach Accept?

Start with sender direction, then correlate it with the earlier Detach Request and the detach type that shaped the branch.

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.