IMEISV

International Mobile station Equipment Identity and Software Version number

Identifier →
Introduced in Rel-8 Also in: Core Network

IMEISV is a 16-digit identifier that combines a mobile device's unique hardware IMEI with a Software Version Number to precisely identify both the model and its specific software revision.

Category
Identifier
Introduced
Rel-8
Where
Radio Access Network › NG-RAN (5G)
Also touches
1 segments
Specifications
10 specs
IMEISV Description Purpose Related Classification Detected Changes Specifications

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

Part ofIMEI
Related approachesEIR

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

Specific 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.

Rel-15 2 changes

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.

  • Correction to the length of the IMEISV TS 24.501CR0917
  • Introduce IMEISV to addition request to Xn TS 38.423CR0050
Rel-16 2 changes

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.

  • Request of IMEISV via the security mode control procedure TS 24.501CR1547
  • IMEI and IMEISV formats support TS 24.501CR1732
Rel-17 2 changes

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.

  • Addition of Masked IMEISV for UEs using CP CIoT EPS optimisation TS 36.413CR1898
  • Addition of Masked IMEISV for UEs using CP CIoT 5GS optimisation TS 38.413CR0875

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.

SpecificationTitleRelease
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
Patrick Zandl

About the author: Patrick Zandl (b. 1974)

Telecommunications specialist, technology journalist (founder of the Mobil server), and developer who has been running since 2025 — the largest Czech-language resource on AI-assisted programming. Formerly Chief Wizard Architect at Prusa3D and head of development for Turris at CZ.NIC; currently a consultant and instructor on AI implementation in companies.