Originally published on 4GNation, October 2015 — republished here as part of the Telco & Beyond Engineering Archive.
This was originally one of my longer technical write-ups, and I’ve kept it largely intact because the level of detail is exactly what made it useful at the time — anyone debugging a detach-related issue in the field needs to know precisely which entity triggered it and what state each network element ends up in afterward. It’s a good example of documentation written for engineers actually doing the troubleshooting, not just passing an exam.
I. Detach Case 1: UE-Initiated Detach
A UE can initiate detach if:
- The UE is turned off
- A USIM card is removed from the UE
- The UE is attempting to use a non-EPS service (e.g., CS fallback, SMS)
II. Detach Case 2: MME-Initiated Detach
MME-initiated detach further divides into explicit and implicit detach.
In explicit detach, the MME notifies the UE of its intent to detach in advance via a Detach Request message, and informs the UE whether it needs to re-attach afterward. The MME can initiate explicit detach:
- For an operator’s O&M purposes
- If re-authentication fails
- If it can no longer provide the resources allocated to a user
In implicit detach, the MME initiates detach without sending a Detach Request message, because the UE is no longer capable of communicating with the MME — typically due to poor radio link quality (e.g., radio link failure).
III. Detach Case 3: HSS-Initiated Detach
The HSS can initiate detach if:
- The user profile provisioned in the HSS changes, requiring the MME’s saved copy to update as well
- An operator is restricting access by an illegal UE (e.g., a stolen device)
In all three cases, the UE is assumed to be in EMM-Registered, ECM-Connected, and RRC-Connected state before detach, with services provided through the default EPS bearer only. Before detach, a default EPS bearer and its related control connections are established. After detach, the default EPS bearer and all signaling connections are released, and the user enters EMM-Deregistered, ECM-Idle, and RRC-Idle state.
IV. UE-Initiated Detach — Full Procedure
Detach begins when triggering is detected at the UE, which sends a Detach Request. The procedure ends when the UE receives a Detach Accept from the MME — unless the UE is turned off, in which case no accept is sent or expected.
1. [UE → MME] Detach Request — the UE requests detach.
2. [UE] Handling Security and Bearer Contexts — after sending the request, the UE stores its current NAS security context, GUTI, and TA information, then deletes its EPS bearer context.
3. [MME] Noticing Detach Intent — the MME stores the user’s current NAS security context and checks the detach type (normal vs. device switch-off) to determine whether a Detach Accept is required.
EPS Session Termination (Steps 4–13):
- MME requests EPS session release from the S-GW (Delete Session Request over S11/GTP-C)
- MME deletes its EPS bearer context
- S-GW forwards the release request to the P-GW (over S5)
- S-GW deletes its EPS bearer context
- P-GW notifies the PCRF of session termination (CCR over Gx/Diameter)
- PCRF deletes the user’s PCC rule
- PCRF acknowledges via CCA
- P-GW responds to the S-GW’s release request; deletes its own bearer context
- S-GW responds to the MME’s original release request
14. [UE ← MME] Acknowledging Detach — once the MME confirms resource release was approved by the PCRF, it sends the UE a Detach Accept (only when detach wasn’t triggered by device switch-off).
S1 Signaling Connection Release (Steps 15–18):
- MME sends the eNB a UE Context Release Command
- eNB sends the UE an RRC Connection Release
- eNB deletes all UE-related context
- eNB confirms via UE Context Release Complete back to the MME
V. MME-Initiated Detach — Full Procedure
Same overall shape as UE-initiated detach, with two key differences:
- In explicit detach, the MME sends the Detach Request to the UE (with parameters indicating whether re-attach is required); in implicit detach, no request is sent at all — the MME proceeds directly to EPS session termination.
- If the user is in Idle state when detach triggers, the MME performs paging first to re-establish the S1 signaling connection before proceeding.
The remaining EPS Session Termination and S1 Release steps mirror the UE-initiated case, with implicit detach skipping the Detach Request/Accept exchange entirely.
VI. HSS-Initiated Detach — Full Procedure
The HSS sends the MME a Cancel Location Request (CLR) over S6a/Diameter when detach is triggered by subscriber withdrawal. The MME then runs the same resource-release procedure as MME-initiated detach, with one addition: after receiving the Detach Accept from the UE and the Delete Session Response from the S-GW, the MME sends the HSS a Cancel Location Answer confirming completion.
VII. What’s Kept vs. Deleted After Detach
After detach, most session-specific state is deleted — NAS security context, GUTI, and TAI information are cleared, except for the information needed to make the next attach faster and more secure:
At the UE:
- UE ID: GUTI allocated at initial attach or last TA update
- UE Location: last TA visited before detach
- Security: NAS security context used before detach
At the MME:
- UE ID: IMSI from initial attach, plus GUTI from initial attach or last TA update
- UE Location: last TA visited (TAI list may also be retained)
- Security: NAS security context used before detach
- EPS Session/Bearer: subscribed profile from HSS, plus UE-AMBR and APN-AMBR values, which may be retained to speed up the next bearer establishment
At the HSS:
- UE Location: last MME the UE was registered at before detach
Looking back at this now, what strikes me most isn’t the protocol detail itself — it’s how much of this discipline (knowing exactly which entity holds which piece of state, and why) carried over directly into how I later approached enterprise IT delivery and CRM implementation oversight. The layer changes; the instinct to trace state precisely across every system boundary doesn’t.
References: Netmanias Technical Documents, “Eleven EMM Cases in an EMM Scenario” (Oct 2013) and “LTE EMM Procedure 1: Initial Attach” (Jan 2014).