Description
The IP Multimedia Public User Identity (IMPU) is the public-facing identifier used to route sessions and messages to a user within the IMS. It takes the form of a SIP Uniform Resource Identifier (SIP URI), like sip:user@domain.com, or a TEL URI for telephone numbers, like tel:+1234567890. Unlike the private IMPI, the IMPU is used for all public communications, such as being placed in the From and To headers of SIP INVITE requests. A single user subscription, anchored by one IMPI, can be associated with multiple IMPUs, allowing for different aliases, service types (e.g., business, personal), or group identities. During IMS registration, the UE registers one or more IMPUs by associating them with the authenticated IMPI. This registration is stored in the S-CSCF, which downloads the user's service profile from the HSS, including the list of allowed IMPUs and their associated filter criteria for triggering application servers. When a session is initiated to an IMPU, the I-CSCF queries the HSS to find the serving S-CSCF for that identity, which then executes the user's service logic. IMPUs can be in different states: registered, unregistered, or barred. They are also the key enabler for features like implicit registration sets, where registering one IMPU automatically registers others, and for identity hiding services. The management of IMPUs, including their barring and service profile linkage, is central to IMS service delivery and personalization.
Purpose & Motivation
The IMPU was created to provide a flexible, user-friendly addressing scheme for the new generation of IP-based multimedia services in IMS, moving beyond the circuit-switched era's reliance solely on E.164 telephone numbers. It addresses the need for a rich set of identities that can represent a user in various contexts (personal, work, device-specific) and for different service types (voice, video, messaging, presence). The separation of public identity (IMPU) from private identity (IMPI) is a core IMS design principle that enhances security and privacy by ensuring the permanent authentication key is never used in routing. This model solves the problem of how to support both traditional telephony (via TEL URI) and native Internet communication (via SIP URI) under a unified architecture. It was motivated by the vision of convergence, allowing users to be reachable via multiple identifiers while maintaining a single subscription and consistent service experience, thereby enabling advanced services like multimedia telephony, instant messaging, and presence over any IP access network.
Classification
Release Timeline
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (1 CRs across 1 releases). Complements the general historical overview above with the evidence-based evolution of this function.
In Release 16, the IP Multimedia Public User Identity (IMPU) function was newly introduced to support MCData emergency alert and communications. The release formally defined the IMPU abbreviation and introduced related terms such as "Group identity," UUID, and URN within this context. These additions were made to enable specific emergency service capabilities for Mission Critical Data systems.
- Support for MCData emergency alert and communications MCC note: This CR introduces the abbreviation IMPU; MCC has added this in the list of abbreviations, choosing the most appropriate of the five variations appearing in other 3GPP Specs. Similarly, MCC has provided the expansions of abbreviations UUID and URN introduced, but not defined by, this CR. The newly introduced term "Group identity" has a circular definition. In §D.1.3,, "can" has been changed to "may" in newly introduced bullet points 11 c), 11 c) i), and 11 e). TS 24.282CR0126
Explore further
Broader topics and technologies where IMPU plays a role.
Defining Specifications
3GPP specifications that define or reference IMPU, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TR 21.905 vj00 | 3GPP Technical Terms and Definitions | Rel-19 |
| TS 23.179 vd50 | MCPTT Functional Architecture | Rel-13 |
| TS 23.280 vk10 | Common Architecture for Mission Critical Services | Rel-20 |
| TS 23.379 vk00 | MCPTT Functional Architecture | Rel-20 |
| TS 23.806 v1700 | Voice Call Continuity between CS and IMS | Rel-7 |
| TS 24.109 vj00 | HTTP Digest AKA & GAA Stage 3 | Rel-19 |
| TS 24.282 vj50 | MCData Signalling Control Protocols | Rel-19 |
| TS 26.237 vj00 | IMS for PSS and MBMS Control | Rel-19 |
| TS 29.109 vj00 | GAA Bootstrapping Interfaces (Zh, Dz, Zn, Zpn) | Rel-19 |
| TS 31.103 vj00 | ISIM Application Specification | Rel-19 |
| TS 31.111 vj30 | USIM Application Toolkit (USAT) Specification | Rel-19 |
| TS 31.829 vd00 | ISIM Conformance Requirements Technical Report | Rel-13 |
| TS 32.182 vj00 | UDC Common Baseline Information Model (CBIM) | Rel-19 |
| TS 33.107 vj00 | Lawful Interception Architecture & Functions | Rel-19 |
| TS 33.141 vj00 | Security for Presence Service (Ut reference point) | Rel-19 |
| TS 33.203 vj10 | IMS Security Specification | Rel-19 |
| TS 33.222 vj00 | Secure HTTP Access in GAA | Rel-19 |
| TS 33.790 vj10 | Security for Next-Gen Real-Time Communication Phase 2 | Rel-19 |
| TR 33.978 v1800 | Interim Security for Early IMS | Rel-8 |