Description
Evolved Mobility Management (EMM) is a core protocol and state management entity defined for the Evolved Packet System (EPS) and continued into the 5G System (5GS). It operates in the control plane between the User Equipment (UE) and the core network's Mobility Management Entity (MME) in 4G or the Access and Mobility Management Function (AMF) in 5G. EMM is responsible for establishing, maintaining, and releasing the mobility management context of a UE, which is essential for the network to know the UE's location (at the tracking/routing area level) and its connection state (EMM-REGISTERED or EMM-DEREGISTERED). This context is crucial for enabling the network to page the UE for incoming sessions and to authenticate the device for network access.
The protocol defines specific EMM procedures, which are initiated by either the network or the UE. Key UE-initiated procedures include the initial Attach, which registers the UE with the network and establishes a default bearer, and the Tracking Area Update (TAU), which updates the network when the UE moves into a new tracking area. Network-initiated procedures include Authentication and Security Mode Control to establish ciphering and integrity protection, and Detach to gracefully remove the UE's context. EMM works in conjunction with the ESM (EPS Session Management) protocol, which handles bearer management; EMM procedures often carry ESM messages as payload.
EMM states are central to its operation. The primary states are EMM-DEREGISTERED, where the UE is not known to the MME/AMF, and EMM-REGISTERED, where a context exists. Within the EMM-REGISTERED state, sub-states like EMM-IDLE and EMM-CONNECTED indicate whether a signaling connection to the radio access network is active. Transitions between these states are triggered by specific events, such as successful attach (deregistered to registered) or connection release (connected to idle). The protocol ensures that security keys are established during registration and are used to protect all subsequent NAS (Non-Access Stratum) signaling messages, providing a secure foundation for mobility management.
Purpose & Motivation
EMM was created as part of the System Architecture Evolution (SAE) in 3GPP Release 8 to provide a unified, IP-based mobility management framework for the new Evolved Packet Core (EPC). Previous 3GPP systems like GPRS and UMTS had mobility management (GMM) that was more tightly coupled with the circuit-switched domain and the legacy network architecture. The purpose of EMM was to design a cleaner, more efficient protocol optimized for all-IP networks, supporting seamless mobility between 3GPP and non-3GPP access networks (like Wi-Fi).
It solved the problem of managing mobility in a flatter network architecture where the control plane (handled by the MME) was separated from the user plane. EMM provides a standardized way for the UE and network to negotiate capabilities, establish security, and maintain location information without the overhead of the older circuit-switched paradigms. Its creation was motivated by the need for higher data rates, lower latency, and simplified network architecture required for LTE, and it laid the groundwork for the mobility management in 5G, where it evolved into the NAS protocol for Registration and Connection Management handled by the AMF.
Classification
Release Timeline
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (93 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.
In Release 15, the EMM function was updated with specific clarifications and corrections for procedures including Tracking Area Updates (TAU) and service request handling, particularly for rejections with defined EMM cause values. Enhancements were made to the coordination between EMM and 5GMM for UEs in Dual Registration Mode (DRM) and to the handling of parameters for EPC interworking. The release also introduced corrections for extended EMM cause usage in NB-IoT and refined behaviors for UEs in EMM-IDLE mode, such as the handling of UE radio capability changes with suspend indication.
- Extended EMM cause for NB-IoT TS 24.301CR3035
- 5GMM parameter handling for TAU rejected with EMM cause #9 TS 24.301CR3047
- Correction of inconsistency in EMM timers table TS 24.301CR2897
- Correction to EMM/GMM coordination TS 24.301CR2981
- Non-semantical mandatory information element errors for EMM TS 24.301CR3050
- Handling of change of UE radio capability information in EMM-IDLE mode with suspend indication TS 24.301CR3095
+ 6 more changes
In Release 16, the EMM function was enhanced with specific clarifications and corrections for various EMM causes, such as #3, #6, #8, #10, #12, #13, #15, #22, and #31, including their handling in procedures like SERVICE REJECT. The release also introduced detailed stage 3 specifications for EMM substates related to RLOS (Restricted Local Operator Services) and provided corrections to UE behavior in specific EMM states, such as EMM-REGISTERED.ATTEMPTING-TO-UPDATE-MM and EMM-DEREGISTERED.ATTEMPTING-TO-ATTACH, to ensure proper procedure execution.
- Adding the stage 3 detail on EMM substates for attaching for access to RLOS. TS 24.301CR3179
- RLOS storage of EMM information TS 24.301CR3268
- Types of EMM procedures for RLOS TS 24.301CR3269
- Clarification for EMM cause #3, #6, and #8 in the SERVICE REJECT message TS 24.301CR3211
- Correction on UE handling for EMM cause #8 and #10 TS 24.301CR3216
- EMM causes handled as 5GMM causes received over 3GPP access TS 24.301CR3228
+ 21 more changes
In Release 17, key enhancements to EMM included improved handling of specific reject causes like #78, clarifications for service recovery on NR after a network-triggered detach, and the addition of a Service Request procedure for non-integrity protected reject messages. The release also introduced refinements for state coordination between 5GMM and EMM, and better defined parameter handling for various EMM causes to ensure consistent UE behavior.
- Handling of reject cause #78 in EMM procedures TS 24.301CR3620
- Recovering service on NR after network triggered detach indicating "re-attach not required" without EMM cause TS 24.301CR3445
- Miss local detach procedure before entering EMM-DEREGISTERED state TS 24.301CR3480
- 5GMM registration attempt counter reset for EMM reject causes TS 24.301CR3488
- Obtaining voice services for EMM cause #2 (IMSI unknown in HSS) TS 24.301CR3586
- Starting T3440 for EMM cause #22 with T3346 value TS 24.301CR3584
+ 13 more changes
In Release 18, key enhancements to EMM included refined state management for emergency attached UEs, ensuring their EMM context is stored and a mobile reachable timer is used instead of periodic TAU procedures. The release also provided corrections and clarifications for state transitions, such as the conditions for initiating a detach in the EMM-REGISTERED.ATTEMPTING-TO-UPDATE and UPDATE-NEEDED substates, and improved coordination between 5GMM and EMM states in single registration mode. Furthermore, specific procedures were updated, including the handling of the EMM ATTACH process after IRAT from 2G/3G/5G and the management of reject messages containing EMM cause value #78.
- Clarification of EMM ATTACH procedure after IRAT from 235G TS 24.301CR3904
- EMM state for discontinuous coverage TS 24.301CR3903
- EMM context storage when emergency attached TS 24.301CR3908
- Coordination between 5GMM and EMM states in single registration mode TS 24.301CR3918
- Handling of a reject message including EMM cause value #78 without integrity protection TS 24.301CR3945
- Release of the NAS signalling connection established from EMM-IDLE TS 24.301CR3907
+ 5 more changes
In Release 19, enhancements to the Evolved Mobility Management (EMM) function focused on refining the EMM Transport procedure and associated state management. Key updates included allowing the sending of ESM TRANSPORT messages in EMM-IDLE mode with a suspend indication, clarifying UE behavior upon receiving specific EMM cause codes like #42 and #83, and enabling exception data reporting via EMM TRANSPORT even when a Control Plane data back-off timer is running. The release also introduced corrections and alignments for the EMM TRANSPORT message, such as handling invalid EPS bearer identities in its Data container and clarifying its classification for ciphering.
- Update EMM procedures to support the storage of the information TS 24.301CR4159
- NAS signalling connection release after EMM cause 83 TS 24.301CR4402
- Handling of inactive PDP context in EMM TRANSPORT message TS 24.301CR4517
- Alignment of EMM Transport message TS 24.301CR4459
- Invalid EPS bearer identity in the Data container IE in the EMM TRANSPORT message TS 24.301CR4494
- UE behaviour upon reception of EMM cause #42 TS 24.301CR4106
+ 18 more changes
Explore further
Broader topics and technologies where EMM plays a role.
Defining Specifications
3GPP specifications that define or reference EMM, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 23.401 vj50 | Evolved Packet System (EPS) Stage 2 Description | Rel-19 |
| TS 24.301 vj60 | NAS protocol for Evolved Packet System | Rel-19 |
| TS 24.501 vj50 | 5G NAS Protocols Specification | Rel-19 |
| TS 24.801 v810 | CT1 SAE NAS Aspects for EPC | Rel-8 |
| TS 24.890 vg00 | 5G NAS Protocol for 5GS Stage 3 | Rel-16 |
| TS 26.851 vb20 | Enhancements to Multimedia (EMM) for PSS, MMS, MBMS | Rel-11 |
| TS 31.121 vi50 | UICC-terminal interface test specification | Rel-18 |
| TS 33.401 vj10 | EPS Security Architecture | Rel-19 |
| TS 36.300 vj00 | E-UTRAN Radio Interface Protocol Architecture Overview | Rel-19 |
| TS 36.401 vj00 | E-UTRAN Overall Architecture Description | Rel-19 |
| TS 36.509 vh40 | EPC Special UE Conformance Testing Functions | Rel-17 |
