IMUN

International Mobile User Number

Identifier →
Introduced in Rel-4

IMUN is a dialable E.164-based number defined by 3GPP to uniquely identify a mobile user for establishing multimedia communication sessions, like video calls, within IMS networks.

Category
Identifier
Introduced
Rel-4
Where
Services
Specifications
4 specs
IMUN Description Purpose Related Classification Detected Changes Specifications

Description

The International Mobile User Number (IMUN) is a telecommunications identifier defined within the 3GPP framework, specifically for use in IP Multimedia Subsystem (IMS) networks. As outlined in specifications such as TS 22.101 (Service Aspects) and TS 23.003 (Numbering, Addressing, and Identification), the IMUN is a public user identity that conforms to the ITU-T E.164 international numbering plan. This means it appears as a standard, globally routable telephone number (e.g., +441234567890). Its primary purpose is to address a user for multimedia session establishment, like Voice over IP (VoIP) calls, video calls, and other IMS-based services.

Within the IMS architecture, a user can have multiple public user identities. The IMUN is one type, alongside SIP URIs (like [email protected]). The IMUN is stored in the user's subscription profile within the Home Subscriber Server (HSS). When a user registers with the IMS network, their assigned public user identities (including any IMUNs) are registered and become reachable. The IMUN is used in the signaling path, particularly in protocols like SIP (Session Initiation Protocol). For instance, when initiating a video call, the calling party would use the callee's IMUN as the Request-URI in the SIP INVITE message. The IMS core, including the Serving-Call Session Control Function (S-CSCF), uses this E.164 number to perform number analysis, routing, and service triggering based on the user's profile.

The IMUN plays a crucial role in interworking and interoperability. Because it follows the globally understood E.164 format, it allows IMS users to be called from, and to call to, users in traditional circuit-switched telephone networks (PSTN, PLMN) via appropriate breakout gateways (e.g., MGCF). This bridges the gap between all-IP IMS networks and legacy telephony. Furthermore, for services like Video Telephony, the IMUN provides a familiar dialing experience for users accustomed to entering phone numbers.

The lifecycle and management of an IMUN are tied to the subscriber's IMS subscription. It can be provisioned by the operator, and a single user may have both an IMUN and a SIP URI, allowing flexibility in how they are contacted. The Tel URI format (which also encodes an E.164 number) is often used in SIP signaling to carry the IMUN. The continued relevance of the IMUN lies in the enduring need for E.164-based addressing in a world where many communication services still rely on telephone numbers, even as they migrate to packet-switched, IMS-based delivery.

Purpose & Motivation

The IMUN was created to provide a standardized, E.164-compliant addressing scheme for users within the IP Multimedia Subsystem (IMS), the core network architecture for delivering multimedia services in 3GPP networks. As 3GPP evolved circuit-switched voice to packet-switched Voice over IP (VoIP) and multimedia, a key challenge was maintaining interoperability with the existing global telephone network (PSTN/PLMN) and providing a user-friendly identifier.

The problem it solved was twofold. First, users and existing business processes were (and still are) deeply familiar with telephone numbers. Introducing a completely different addressing scheme (like SIP URIs only) for new multimedia services would create a barrier to adoption. The IMUN allowed new IMS-based services, like video telephony, to be accessed using a familiar phone number. Second, for network operators, seamless interworking between IMS and legacy networks was essential for service continuity. An E.164-based identity like the IMUN allows routing logic and gateway functions (like the MGCF) to translate between SIP-based IMS signaling and ISUP/BICC-based circuit-switched signaling using a common number format.

Historically, as IMS was developed from Release 5 onwards, the IMUN was defined alongside SIP URIs to offer a dual addressing capability. It addressed the limitations of relying solely on device-centric identifiers (like IMSI) or non-dialable identifiers, ensuring that IMS users could be integrated into the global numbering plan. This was a critical factor for the commercial success of IMS-based services, enabling them to replace and enhance traditional telephony rather than exist as a separate, incompatible silo.

Classification

Part ofIMS
Related approachesMSISDN

Detected Changes Across Releases

from 3GPP Change Requests

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

Studied in Rel-4, normative work from Rel-16.

Rel-16 1 change

In Release 16, the primary new introduction for the International Mobile User Number (IMUN) function was the addition of new general abbreviations to the specification's terminology. This update served to formally define and standardize the abbreviated terms used within the technical documentation for this function. The change was documented through a standard Change Request process, ensuring the 3GPP glossaries and related texts reflect the current technical lexicon.

  • Add new general abbreviations MCC Note: CR cover sheet wrongly shows CR number as "1118". TS 21.905CR0118

Explore further

Broader topics and technologies where IMUN plays a role.

Defining Specifications

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

SpecificationTitleRelease
TR 21.905 vj00 3GPP Technical Terms and Definitions Rel-19
TS 22.101 vk00 Service Principles for PLMNs Rel-20
TS 22.105 vj00 Telecommunication Services Framework Rel-19
TR 22.975 v1310 UMTS Numbering and Addressing Requirements Rel-4