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
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (156 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-8, normative work from Rel-15.
In Release 15, the specification introduced clarifications and corrections for the handling of the 5GS mobile identity IE, including the resolution of an editor's note on its maximum length and the completion of its definition in messages. This ensured consistent procedures for identity management within the 5GMM protocol, such as during the service request procedure where the temporary identity is used.
- How to determine the maximum number of established PDU sessions TS 24.501CR0077
- UE configuration for AC 11-15 and MCS (access identity 2) TS 24.501CR0083
- MCS Indicator and Access Identity 2 TS 24.501CR0614
- RRC version handling TS 38.473CR0105
- Clarify the method of configuring the UE to use Access Identity 1 TS 24.501CR0255
- Pass (Extended) Emergency Number List to upper layers TS 24.501CR0003
+ 35 more changes
In Release 16, a key enhancement for the IMEISV function was the explicit support for requesting the IMEISV via the security mode control procedure, providing the network with a standardized method to retrieve the software version. Furthermore, the release clarified that the IMEI is not required for user equipment that connects exclusively via non-3GPP access networks, refining identity requirements for different access types. These changes were part of a broader update that also included formalizing support for both IMEI and IMEISV formats within the 5G system specifications.
- Usage of PDU session identity for the PDU sessions requested by the TWIF TS 24.501CR1686
- UE radio capability ID deletion upon Version ID change TS 24.501CR1888
- Signalling UE capability identity (The CR is not implemented. The CR was marked agreed by mistake while the WI is not yet complete) TS 36.413CR1746
- Signalling UE capability identity TS 36.413CR1746
- Shared network broadcasting PLMN identity(ies) or SNPN identity(ies) TS 24.501CR1460
- Correction of typos in octet numbering for AMF Set ID TS 24.501CR1038
+ 24 more changes
In Release 17, specific clarifications and corrections were made regarding the handling of the rejected Network Slice Selection Assistance Information (NSSAI) for the maximum number of UEs reached. This included procedures to stop or remove the associated back-off timer for a rejected Single NSSAI (S-NSSAI) under this condition, both during interworking with EPC and in general handling. The updates ensured clearer UE behavior when a network slice is unavailable due to subscriber capacity limits.
- S-NSSAI rejected due to maximum number of UEs reached and BO timer value TS 24.501CR3123
- Maximum number of established PDU sessions already reached for a NW slice TS 24.501CR3213
- Introducing access identity 3 for disaster roamer TS 24.501CR3679
- Update of emergency number list using Configuration Update Command TS 24.501CR2248
- Correction to the octet number in 5GS network feature support TS 24.501CR2489
- Fix of encoding errors in 5GS mobile identity IE TS 24.501CR2597
+ 37 more changes
In Release 18, specific enhancements were made to the IMEISV function concerning UE identity handling during registration procedures. This included defining new UE behavior for scenarios where the UE identity cannot be derived, requiring the network to treat a Mobility Registration Update as an initial registration. Additionally, clarifications were provided for UE identity handling in the specific case of a USIM removal occurring during an ongoing registration procedure.
- Equivalent SNPN usage for mobile identity selection TS 24.501CR4840
- Equivalent SNPNs: NSSAIs, network-assigned UE radio capability ID, maximum number of established PDU sessions and 5GMM parameters in annex C stored per selected entry TS 24.501CR5027
- (CR to 38.413) Support for mobile IAB TS 38.413CR0988
- Support for mobile IAB TS 38.423CR1102
- (CR to 38.473): Support for mobile IAB TS 38.473CR1176
- UE handling on local emergency numbers TS 24.501CR4595
+ 30 more changes
In Release 19, the changes to the IMEISV function were limited to administrative upgrades without technical modifications, as indicated by the multiple "Upgrade to Rel-19 version without technical change" items. The release also included corrections to the 5GS mobile identity, which encompasses identifiers like the IMEISV, refining their specification for clarity and accuracy. No new procedures or capabilities specific to the IMEISV were introduced beyond these maintenance and correction activities.
- Correction of faulty bit number for NSAG TS 24.501CR6617
- Clarification of the mobile reachable tmer to avoid an expired timer in the unavailability period TS 24.501CR6542
- Corrections to the 5GS mobile identity TS 24.501CR7042
- Upgrade to Rel-19 version without technical change TS 43.318
- Upgrade to Rel-19 version without technical change TS 43.902
- Upgrade to Rel-19 version without technical change TS 44.318
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 |