LTE NAS EMM and ECM States
LTE NAS EMM and ECM states describe the UE from two different angles inside EPS. EMM states focus on mobility and registration. They tell you whether the UE is registered and whether a NAS mobility procedure such as attach, TAU, or service recovery is in progress. ECM states focus on connection status. They tell you whether the UE currently has active signaling connectivity toward the EPC or whether paging is needed before signaling can resume.
Use this page as a practical reference for state names such as EMM-REGISTERED, EMM-DEREGISTERED, ECM-IDLE, and ECM-CONNECTED. When one of these states appears in a call flow, trace, or message page, this reference helps you understand what it means operationally and what behavior you should expect next.
Quick facts
| Technology | LTE / EPS |
|---|---|
| Protocol scope | EPS NAS mobility and connection-management state models |
| Main specs | 3GPP TS 24.301 and 3GPP TS 23.401 |
| Main use | Attach, TAU, service request, paging, idle-to-connected return, detach, and LTE NAS troubleshooting |
| Common confusion | EMM, ECM, and RRC states describe different parts of UE behavior and should not be mixed together |
Overview
EMM stands for EPS Mobility Management, while ECM stands for EPS Connection Management. On the LTE NAS side, EMM answers registration and mobility-state questions, while ECM answers connection-presence questions between the UE and EPC control plane.
In practice, EMM states are most useful when you need to answer questions like: did attach really finish, is the UE still operating from a valid registered baseline, should this trace show service request or fresh attach, whether the UE should be paged first, and why the UE retries mobility procedures the way it does.
Quick lookup
| State | Model | Practical meaning | Typical use |
|---|---|---|---|
| EMM-NULL | EMM | No EPS mobility context is available and EPS service is not active. | Context creation, initial service build, or complete reset behavior before normal attach logic can proceed. |
| EMM-DEREGISTERED | EMM | The UE is not currently registered for EPS mobility service. | Attach, combined attach, fresh mobility rebuild, and many restart or recovery scenarios begin from here. |
| EMM-REGISTERED-INITIATED | EMM | The UE has started attach-related registration work and is waiting for the network result. | Initial attach, re-attach, and combined attach handling. |
| EMM-REGISTERED | EMM | The UE is registered for EPS mobility service and has usable EPS context. | Tracking Area Update, Service Request, paging response continuation, and ongoing registered idle or connected operation all depend on this state being valid. |
| EMM-DEREGISTERED-INITIATED | EMM | The UE has started detach and is waiting for deregistration completion. | Detach and explicit mobility-context release handling. |
| EMM-TRACKING-AREA-UPDATING-INITIATED | EMM | The UE has started tracking area update and is waiting for the network response. | Normal TAU, periodic TAU, combined TAU, MME change handling, and some recovery paths. |
| EMM-SERVICE-REQUEST-INITIATED | EMM | The UE has started service request and is waiting for service restoration or rejection. | Service Request, paging response service return, uplink pending data restoration, and some connected-service restart paths. |
| ECM-IDLE | ECM | The UE does not currently have active S1 signaling connection context toward the MME. | Idle registered operation, paging, Service Request, Tracking Area Update from idle, and normal mobility while waiting for network reachability triggers. |
| ECM-CONNECTED | ECM | The UE has active signaling connection context toward the EPC and is in connected service handling from core connection-management perspective. | Attach completion, active service restoration, bearer handling, connected TAU, and live signaling exchange between UE, eNB, and MME. |
EMM state model
The easiest way to read the EMM model is to separate stable states from transitional states. Stable states tell you whether the UE currently has usable EPS registration context. Transitional states tell you that a NAS mobility procedure is in progress and the UE is waiting for the network result.
- Stable baseline states: EMM-NULL, EMM-DEREGISTERED, and EMM-REGISTERED.
- Procedure-driven transition states: EMM-REGISTERED-INITIATED, EMM-DEREGISTERED-INITIATED, EMM-TRACKING-AREA-UPDATING-INITIATED, and EMM-SERVICE-REQUEST-INITIATED.
A successful LTE Attach Procedure normally ends with the UE in EMM-REGISTERED. A Tracking Area Update runs from a registered baseline and temporarily enters EMM-TRACKING-AREA-UPDATING-INITIATED. A Service Request uses EMM-SERVICE-REQUEST-INITIATED when stored EPS context is reused to restore active service.
EMM state details
EMM-NULL
No EPS mobility context is available and EPS service is not active.
Entered when: Before usable EPS mobility context exists or after context has been completely cleared.
What it means: This is the non-operational baseline on the EMM side. The UE is not in an EPS registration-capable service state here.
Typical procedures: Context creation, initial service build, or complete reset behavior before normal attach logic can proceed.
Engineer note: This state is less visible in everyday call-flow work than deregistered and registered states, but it matters conceptually when the UE has no usable EPS mobility context at all.
EMM-DEREGISTERED
The UE is not currently registered for EPS mobility service.
Entered when: After power-on before successful attach, after detach completion, after loss of usable EPS context, or after reject and recovery conditions.
What it means: The UE is not known to the network as an active EPS-registered subscriber, so the network cannot treat it as normally reachable through an existing mobility context.
Typical procedures: Attach, combined attach, fresh mobility rebuild, and many restart or recovery scenarios begin from here.
Engineer note: If a UE is stuck repeatedly in deregistered behavior, the real fault is usually in attach, identity, authentication, security, or bearer setup rather than in later service procedures.
EMM-REGISTERED-INITIATED
The UE has started attach-related registration work and is waiting for the network result.
Entered when: After the UE begins attach or combined attach but before successful completion is confirmed.
What it means: This is a transitional registration-building state. The UE has left pure deregistered behavior but has not yet reached stable EMM-REGISTERED service.
Typical procedures: Initial attach, re-attach, and combined attach handling.
Engineer note: When traces stall here, inspect Attach Request, identity resolution, authentication, NAS security, and the attach accept path in order.
EMM-REGISTERED
The UE is registered for EPS mobility service and has usable EPS context.
Entered when: After successful attach or after other procedures return the UE to its steady registered EPS state.
What it means: The network knows the UE in EPS mobility terms, can maintain reachability with the expected location granularity, and the UE can continue with normal packet service behavior.
Typical procedures: Tracking Area Update, Service Request, paging response continuation, and ongoing registered idle or connected operation all depend on this state being valid.
Engineer note: This is the most important anchor state for LTE NAS troubleshooting. If a call flow says attach succeeded, the question becomes whether the UE truly reached stable EMM-REGISTERED behavior and stayed there.
EMM-DEREGISTERED-INITIATED
The UE has started detach and is waiting for deregistration completion.
Entered when: After the UE sends a detach request and waits for the network-side response or release completion.
What it means: This is the controlled tear-down transition out of EPS registration.
Typical procedures: Detach and explicit mobility-context release handling.
Engineer note: If traces stop here unexpectedly, check whether detach was UE-originated, reject-driven, test-driven, or caused by a wider access or power sequence.
EMM-TRACKING-AREA-UPDATING-INITIATED
The UE has started tracking area update and is waiting for the network response.
Entered when: After TAU begins because of movement, periodic update, combined update, or recovery handling.
What it means: The UE is already operating from a registered baseline but is temporarily in a mobility-update transaction.
Typical procedures: Normal TAU, periodic TAU, combined TAU, MME change handling, and some recovery paths.
Engineer note: If the UE repeatedly revisits this state, inspect TAI handling, allowed tracking areas, old GUTI use, reject causes, and whether the UE really keeps a valid registered baseline between attempts.
EMM-SERVICE-REQUEST-INITIATED
The UE has started service request and is waiting for service restoration or rejection.
Entered when: After idle-to-connected service restoration begins using stored EPS context.
What it means: The UE is not doing fresh attach here. It is trying to resume active service from an already registered state.
Typical procedures: Service Request, paging response service return, uplink pending data restoration, and some connected-service restart paths.
Engineer note: If this state fails repeatedly, the core question is whether the UE truly had valid stored EPS context or should have fallen back to attach instead of service request.
ECM state model
ECM is simpler than EMM. In practical LTE reading, the important ECM question is whether the UE is ECM-IDLE or ECM-CONNECTED. This tells you whether the network needs paging before continuing service or whether live EPC signaling context is already available.
- ECM-IDLE: No active EPC signaling connection context is being held for the UE.
- ECM-CONNECTED: Active EPC signaling connection context exists and the UE can continue connected signaling procedures directly.
A successful LTE Attach Procedure commonly ends with the UE reaching EMM-REGISTERED while still being ECM-CONNECTED during completion signaling. Later, the UE may remain EMM-REGISTERED but return to ECM-IDLE after connection release.
ECM state details
ECM-IDLE
The UE does not currently have active S1 signaling connection context toward the MME.
Entered when: After attach returns the UE to idle reachability, after RRC release with preserved registration context, or after service activity ends and the signaling connection is released.
What it means: The UE can still be registered from EMM point of view, but active connection-management context is not kept. The network reaches the UE through paging when service or signaling is needed again.
Typical procedures: Idle registered operation, paging, Service Request, Tracking Area Update from idle, and normal mobility while waiting for network reachability triggers.
Engineer note: ECM-IDLE does not mean the UE is deregistered. A UE can be fully EMM-REGISTERED and still be ECM-IDLE for long periods in normal operation.
ECM-CONNECTED
The UE has active signaling connection context toward the EPC and is in connected service handling from core connection-management perspective.
Entered when: After successful access and signaling setup for attach, service request, TAU in connected mode, paging response continuation, or other active EPC signaling periods.
What it means: The network has live connection-management context for the UE, so NAS and bearer-related procedures can continue without paging the UE first.
Typical procedures: Attach completion, active service restoration, bearer handling, connected TAU, and live signaling exchange between UE, eNB, and MME.
Engineer note: ECM-CONNECTED often coexists with RRC_CONNECTED in practical traces, but ECM and RRC are still different models. One is core connection management, the other is radio control.
How to use this page
Use this page when a procedure, message, or trace mentions an EMM or ECM state and you want to understand what that state means for the UE's next expected NAS behavior.
- Use LTE Attach Procedure with this page when you need to confirm whether attach truly ended in EMM-REGISTERED and whether the UE was still ECM-CONNECTED during completion signaling.
- Use Tracking Area Update with this page when you need to distinguish a registered mobility update from a fresh attach rebuild.
- Use Service Request with this page when you need to decide whether the UE is correctly reusing stored EPS context from EMM-REGISTERED and returning from ECM-IDLE into ECM-CONNECTED, or should have fallen back to attach.
- Use EMM cause values with this page when a reject or failure changed the state outcome and you want to know what the UE should do next.
EMM state vs ECM state vs RRC state
One of the most common LTE troubleshooting mistakes is to mix up EMM state with ECM or RRC state. They are related, but they are not the same.
| State model | What it tells you | Example question |
|---|---|---|
| EMM | Whether EPS mobility registration context exists and what NAS mobility procedure is active | Is the UE registered, deregistered, or mid-attach? |
| ECM | Whether the UE currently has signaling connection context toward the core | Is the UE idle or connected from EPC connection-management perspective? |
| RRC | Whether the radio control connection is established on the access side | Is the UE in RRC_IDLE or RRC_CONNECTED? |
A UE can be EMM-REGISTERED while still moving between idle and connected access behavior. That is why service request and paging analysis often needs EMM, ECM, and RRC to be read together.
References
- 3GPP TS 24.301, Release 18: Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS)
- 3GPP TS 24.301, EMM state-machine clauses and procedure descriptions for attach, TAU, service request, and detach
- 3GPP TS 23.401: EPC architecture and EPS mobility plus ECM behavior context