Description
The International Mobile station Equipment Identity and Software Version number (IMEISV) is an extended identifier for mobile equipment. It is a 16-digit number that builds upon the standard 15-digit IMEI by appending a two-digit Software Version Number (SVN). The first 14 digits are the Type Allocation Code (TAC, 8 digits) and Serial Number (SNR, 6 digits), identical to the IMEI. The 15th digit is a check digit (CD) calculated using the Luhn algorithm. The critical addition is the 16th digit, the SVN, which identifies the software or firmware version loaded on the device. This identifier is reported by the User Equipment (UE) to the network and is utilized by various network functions.
Within the network architecture, the IMEISV is processed by core network elements and, in some cases, the Radio Access Network (RAN). As per specifications like 24.501 (NAS) and 33.401 (security), the UE can provide the IMEISV during registration or security procedures. The core network, such as the Mobility Management Entity (MME) or Access and Mobility Management Function (AMF), can forward this information to an Equipment Identity Register (EIR) or other management systems. The EIR can maintain policies based not only on the hardware TAC but also on the SVN, allowing for granular control. For instance, a network could restrict access for devices running outdated, vulnerable software versions.
The SVN component transforms the IMEI from a static hardware identifier into a dynamic one that reflects the device's current software state. This is crucial for modern device management. Operators and manufacturers use it to track firmware rollout compliance, ensure devices have critical security updates before allowing access to sensitive services, and enable or disable specific features based on software capabilities. In the RAN, as referenced in specs like 36.413 and 38.423, the IMEISV may be used for radio resource management optimizations tailored to specific device-software combinations. The IMEISV provides a complete picture of the device's identity, encompassing its manufacturing origin, unique unit, and operational software layer, making it a powerful tool for security, provisioning, and network optimization.
Purpose & Motivation
The IMEISV was introduced to address the limitation of the standard IMEI, which only identifies hardware. As mobile devices became more complex with updatable firmware and software, network operators and manufacturers needed a way to identify the exact software version running on a device. This was driven by the need for precise remote device management, security vulnerability mitigation, and ensuring service compatibility.
Historically, without the SVN, a network could only know the device model (via TAC) but not whether it had been updated with a patch that fixed a critical security flaw or enabled a new protocol feature. This gap made it difficult to enforce security policies or guarantee quality of service. The IMEISV solves this by binding the software state to the device's permanent identity. It allows for policies that can, for example, bar devices with known vulnerable software versions from accessing the network or redirect them to a service portal for mandatory updates.
Its purpose expanded with the rise of Over-The-Air (OTA) updates and the Internet of Things (IoT). For IoT deployments with thousands of devices, managing firmware versions is paramount. The IMEISV provides the necessary identifier for automated management systems to inventory software versions and target updates. In later releases like Rel-17 and Rel-18, its role is reinforced in the context of 5G security (33.501) and network automation, where understanding the device's software capabilities is integral to dynamic policy enforcement and network slice selection.
Classification
Release Timeline
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (6 CRs across 3 releases). Complements the general historical overview above with the evidence-based evolution of this function.
In Release 15, the IMEISV was formally introduced as a distinct identity type within the 5GS mobile identity information element, with its own specific encoding. The release specified a procedure where an AMF can request a UE to provide its IMEISV within the Security Mode Complete message. Furthermore, it defined the format for the IMEISV using BCD coding and established rules for devices without an IMEISV, such as a 5G-RG using its MAC address as a PEI in the non-IMEISV PEI information element.
In Release 16, the key new feature for the IMEISV function was the ability for the AMF to explicitly request a UE to provide its IMEISV via the security mode control procedure, specifically within the SECURITY MODE COMMAND message. Furthermore, the specifications formally defined the IMEISV as a distinct identity type within the 5GS mobile identity information element and detailed its encoding format. The release also introduced procedures for devices like 5G-RGs to provide alternative identifiers, such as a MAC address in a "non-IMEISV PEI" information element, when an IMEISV is requested but not available.
In Release 17, the key novelty for the IMEISV function was the introduction of a Masked IMEISV capability for User Equipment (UEs) using Control Plane (CP) Cellular Internet of Things optimisations, specifically for both EPS and 5GS. This enhancement allows these IoT devices to provide a masked version of their identity when requested by the network, such as within the Security Mode Control procedure where the AMF may request the IMEISV. The update provides a privacy-preserving mechanism for equipment identification in constrained IoT deployments.
Explore further
Broader topics and technologies where IMEISV plays a role.
Defining Specifications
3GPP specifications that define or reference IMEISV, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 24.501 vj50 | 5G NAS Protocols Specification | Rel-19 |
| TS 32.808 v1800 | Common User Profile Storage Framework | Rel-8 |
| TS 33.401 vj10 | EPS Security Architecture | Rel-19 |
| TS 36.413 vj10 | S1 Application Protocol (S1AP) | Rel-19 |
| TS 38.413 vj10 | NG Application Protocol (NGAP) | Rel-19 |
| TS 38.423 vj10 | Xn Application Protocol (XnAP) specification | Rel-19 |
| TS 38.473 vj10 | 5G F1 Application Protocol (F1AP) | Rel-19 |
| TS 43.318 vj00 | Generic Access Network (GAN) Stage 2 | Rel-19 |
| TR 43.902 vj00 | GAN Enhancements Feasibility Study | Rel-19 |
| TS 44.318 vj00 | Generic Access Network (GAN) Interface Procedures | Rel-19 |