PEI

Permanent Equipment Identifier

Identifier →
Introduced in Rel-15 Also in: Radio Access Network, Security

PEI is a globally unique, permanent identifier for 3GPP User Equipment, used for device identification, registration, security, and authentication.

Category
Identifier
Introduced
Rel-15
Where
Core Network › 5G Core
Also touches
2 segments
Specifications
26 specs
PEI Description Purpose Related Classification Detected Changes Specifications

Description

The Permanent Equipment Identifier (PEI) is a fundamental identifier within the 3GPP system, designed to uniquely and permanently identify the physical User Equipment (UE) hardware. It is defined as a separate entity from subscriber-based identities like the SUPI, ensuring a clear distinction between the device and the user. The PEI is provisioned into the UE's non-volatile memory during manufacturing and is intended to remain unchanged for the lifetime of the device, barring hardware replacement. Its primary architectural role is within the core network, specifically in interactions with the Access and Mobility Management Function (AMF) and the Unified Data Management (UDM) for registration and authentication procedures.

In operation, the PEI is used during initial network registration and authentication. For 5G systems, the PEI can be included in the Registration Request message sent from the UE to the AMF. The AMF may then use this identifier, particularly for UEs that do not have a Universal Subscriber Identity Module (USIM), to authenticate the device itself. The PEI is also a key parameter for network functions like the Equipment Identity Register (EIR), which uses it to check the device's status (e.g., blacklisted, grey-listed, or white-listed) to prevent the use of stolen or unauthorized devices on the network. This check helps in mitigating fraud and protecting network resources.

The identifier itself can take different forms depending on the device type. For traditional cellular devices, it is typically the International Mobile Equipment Identity (IMEI) or IMEISV. For IoT and other devices, it may be defined differently as per 3GPP specifications. The PEI is a critical element for security, management, and regulatory compliance. It supports functions such as device authentication for network access (especially for non-USIM based authentication in IoT scenarios), lawful interception mandates, and equipment theft deterrence. Its handling is governed by strict privacy and security specifications to prevent unauthorized tracking, with protocols ensuring it is not transmitted unnecessarily over the air.

Purpose & Motivation

The PEI was created to provide a standardized, permanent, and globally unique method for identifying telecommunications equipment independent of the subscriber. This solves several critical problems: it enables network operators to authenticate devices, not just subscribers, which is vital for IoT deployments and scenarios without USIMs. It addresses the issue of device theft and fraud by allowing networks to blacklist stolen devices via an Equipment Identity Register (EIR), preventing their use. Historically, before standardized permanent equipment identifiers, tracking stolen devices or managing device-specific access policies was inconsistent and less effective across different networks and regions.

Its introduction and formalization in 3GPP specifications, particularly from Release 15 onward with 5G, were motivated by the expanding Internet of Things (IoT) ecosystem and the need for more robust device management. IoT devices often use simplified authentication schemes or may not use a traditional SIM card, making a reliable device identifier essential for network security and access control. The PEI also fulfills regulatory requirements for lawful interception and equipment registration in many jurisdictions. It provides a stable anchor for network management functions, charging systems, and security protocols that need to correlate activities with a specific physical device over time.

Classification

Part ofIMEI
Related approachesSUPI

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (38 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Rel-15 1 change

In Release 15, the Permanent Equipment Identifier (PEI) was newly defined for the 5G System (5GS) to uniquely identify a UE. The specification introduced different PEI types, which, for this release, could indicate an IMEI or IMEISV, a MAC address, or an IEEE EUI-64. This also included provisions for UEs that do not support any 3GPP access technologies.

Rel-16 22 changes

In Release 16, the PEI function was expanded to formally include MAC addresses and IEEE EUI-64 identifiers as valid PEI formats alongside the traditional IMEI/IMEISV. This release specifically introduced support for the PEI for devices like 5G-RG and FN-RG, as well as for UEs that do not support any 3GPP access technologies. Furthermore, the specifications underwent clarifications and alignment to properly handle these new PEI formats and their application for non-3GPP only devices.

+ 16 more changes

Rel-17 5 changes

In Release 17, the PEI function was enhanced to properly support Multi-USIM (MUSIM) devices and UEs not supporting any 3GPP access technologies. The specifications introduced corrections for PEI handling in MUSIM scenarios and for paging procedures involving the PEI. Furthermore, the definition of the PEI was explicitly clarified to include formats like MAC address or IEEE EUI-64 for relevant device types.

  • Correct PEI used for MUSIM and network subscriptions TS 23.501CR3469
  • PEI for UE not supporting any 3GPP access technologies TS 24.501CR2978
  • PEI handling for the MUSIM UE TS 24.501CR4160
  • PEI Information TS 29.503CR0932
  • Correction of Paging with PEI TS 38.300CR0747
Rel-18 2 changes

In Release 18, the PEI function was expanded to enable the identification of a Remote UE by its PEI and to address the specific case of Multi-SIM (MUSIM) UEs and their PEI. These enhancements build upon the existing framework where the PEI can be an IMEI, IMEISV, MAC address, or IEEE EUI-64. The updates provide clearer mechanisms for network handling of these specific UE types and identification scenarios.

Rel-19 8 changes

In Release 19, the PEI function was enhanced to support its explicit request and inclusion within monitoring event configurations and reports, such as for RACS and SUPI-PEI association events which now include a timestamp. The updates also introduced capabilities for querying ID associations using GPSI/PEI and included handling for an "Old PEI" parameter in the Nudm_EE interface, alongside corrections to PEI subgrouping procedures.

  • PEI Requested in monitoring event configuration TS 29.503CR1484
  • Timestamp in EE immediate event report for "SUPI-PEI association" events TS 29.503CR1491
  • Old PEI in Nudm_EE TS 29.503CR1523
  • Enabling GPSI/PEI-based ID Association Query – Stage 2 TS 33.127CR0304
  • PEI Request for RACS TS 24.501CR7106
  • PEI in Monitoring Reports TS 29.503CR1514

+ 2 more changes

Explore further

Broader topics and technologies where PEI plays a role.

Defining Specifications

3GPP specifications that define or reference PEI, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TS 23.003 vj50 Numbering, addressing and identification in 3GPP Rel-19
TS 23.501 vk00 5G System Architecture Stage 2 Rel-20
TS 24.501 vj50 5G NAS Protocols Specification Rel-19
TS 29.256 vj30 UAS-NF Stage 3 Protocol Specification Rel-19
TS 29.503 vj50 UDM Service Based Interface Stage 3 Rel-19
TS 29.507 vj40 5G Access & Mobility Policy Control Service Rel-19
TS 29.511 vj10 5G Equipment Identity Register Service Interface Rel-19
TS 29.514 vj40 5G System; Policy Authorization Service; Stage 3 Rel-19
TS 29.518 vj50 AMF Service Based Interface Protocol Rel-19
TS 29.525 vj40 5G UE Policy Control Service Stage 3 Rel-19
TS 29.571 vj50 Common Data Types for 5G Service Based Interfaces Rel-19
TS 29.890 vg00 CT3 5G System Technical Report Rel-16
TS 32.255 vk10 Telecom Management; Charging for 5G Data Connectivity Rel-20
TS 32.256 vj40 5G Connection & Mobility Charging Spec Rel-19
TS 32.291 vj40 Charging Management: Service-Based Interface Protocol Rel-19
TS 33.126 vj30 Lawful Interception Requirements Rel-19
TS 33.127 vj50 Lawful Interception Architecture and Functions Rel-19
TS 33.501 vk00 5G Security Architecture and Procedures Rel-20
TR 33.857 vh10 Enhanced Security for Non-Public Networks Rel-17
TS 38.300 vj00 NG-RAN Overall Description Rel-19
TS 38.304 vj00 UE RRC_IDLE and RRC_INACTIVE Procedures Rel-19
TS 38.331 vj00 NR Radio Resource Control (RRC) Protocol Specification Rel-19
TS 38.410 vj10 NG Interface Introduction for NG-RAN to 5GC Rel-19
TS 38.470 vj10 F1 Interface Introduction Rel-19
TS 38.523 vj20 5G NR UE Conformance Testing: Idle/Inactive Rel-19
TR 38.869 vi00 Study on low-power wake up signal and receiver for NR Rel-18
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.