Glossary term · Identifier

URN

Uniform Resource Name

Identifier →

URN is a persistent, location-independent identifier used within 3GPP systems to uniquely name resources like services or network elements, following the syntax urn:namespace:identifier.

Introduced
Rel-6
Specifications
23 specs
Category
Identifier
Introduced
Rel-6
Specifications
23 specs
URN Description Purpose Related Classification Detected Changes Specifications

Description

Within the 3GPP architecture, a Uniform Resource Name (URN) is a specific type of Uniform Resource Identifier (URI) defined by IETF RFC 2141, used as a persistent and location-independent identifier for resources. Unlike a URL (Uniform Resource Locator), which specifies both identity and a network location/access mechanism, a URN is intended to provide a globally unique and persistent name that remains valid even if the resource it identifies moves or becomes unavailable. The syntax follows the structure 'urn:<namespace identifier>:<namespace-specific string>'. 3GPP defines and registers specific URN namespaces for its own use, such as 'urn:3gpp' and 'urn:oma', to avoid collisions with identifiers from other organizations.

In practical operation, URNs are extensively used in the IP Multimedia Subsystem (IMS) and other service delivery platforms. For instance, a Public Service Identity (PSI) used to identify an IMS application server (like a conferencing service) can be expressed as a URN (e.g., urn:service:sos.fire for an emergency service). When a User Equipment (UE) initiates a SIP session, the Request-URI in the SIP INVITE message may contain a URN representing the desired service. The IMS core, specifically the Serving-Call Session Control Function (S-CSCF), uses this URN to perform service triggering. It queries the Home Subscriber Server (HSS) or a dedicated Application Server (AS) to resolve the URN into routable contact information (like a SIP URI or tel URI) or to invoke the appropriate service logic.

The management and resolution of URNs are critical components. 3GPP specifications define procedures for URN comparison (ensuring case-insensitive handling where appropriate) and resolution mechanisms. Resolution often involves ENUM (Telephone Number Mapping) services or dedicated name resolution functions within the network. For example, a URN representing a telephone number in the 'tel' namespace (urn:tel:+1-555-123-4567) can be resolved via DNS/ENUM to a SIP URI for routing over IP. The use of URNs decouples service logic from network topology, enabling features like service portability, federation between different operator networks, and the creation of abstract service identities that are not tied to a specific server IP address or domain name.

Purpose & Motivation

The adoption of URNs within 3GPP, particularly from Release 6 onwards with the full deployment of IMS, was driven by the need for a standardized, flexible, and future-proof naming scheme for resources in an all-IP network. Prior circuit-switched networks relied primarily on E.164 telephone numbers (MSISDN) and IMSI for identification, which are number-space constrained and not inherently suitable for naming abstract services, multimedia content, or devices. As networks evolved to support multimedia services, service discovery, and machine-to-machine communication, a more versatile identifier was required.

URNs solve several key problems: they provide persistence (a service name doesn't change even if the hosting server changes), global uniqueness (managed through registered namespaces), and abstraction from location. This allows for service mobility—a user can access their 'video mailbox' service via the same URN regardless of their geographic location or the network operator they are roaming onto. It also facilitates interoperability between different vendor implementations and between 3GPP networks and other IP-based service platforms (like those defined by the Open Mobile Alliance - OMA). By using a standardized IETF mechanism, 3GPP leveraged an existing, well-understood technology, avoiding the creation of a proprietary and potentially incompatible identification system.

Classification

Part ofURI

Detected Changes Across Releases

from 3GPP Change Requests

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

Rel-15 10 changes
  • Adding subclauses in annexes for deriving an emergency service URN TS 24.229CR6061
  • Emergency service URN derival from Extended Emergency List IE TS 24.229CR6107
  • Enable replacing emergency service URN if unknown TS 24.229CR6133
  • Emergency numbers list with URN formats TS 24.301CR2998
  • Correct procedures due to receiving URN information TS 24.229CR6127
  • Correct annexes due to receiving URN information TS 24.229CR6128

+ 4 more changes

Rel-16 4 changes
  • 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
  • Restricting the use of "urn:service:sos" in some jurisdictions TS 24.229CR6318
  • Deletion of a Note related to "urn:service:sos" TS 24.229CR6323
  • Correct “urn:services:sos" into “urn:service:sos" TS 24.229CR6334
Rel-19 1 change

Explore further

Broader topics and technologies where URN plays a role.

Defining Specifications

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

SpecificationTitleRelease
TS 22.820 vf00 Restricted Local Operator Services for Unauthenticated UEs Rel-15
TS 23.167 vk00 IMS Emergency Services Stage 2 Description Rel-20
TS 23.333 vj00 MRFC-MRFP Mp Interface Requirements Rel-19
TS 23.334 vj00 IMS-ALG to IMS-AGW Interface (Iq) Stage 2 Rel-19
TS 24.109 vj00 HTTP Digest AKA & GAA Stage 3 Rel-19
TS 24.186 vk00 IMS Multimedia Telephony Communication Services with IMS Data Channel Rel-20
TS 24.229 vk00 IMS Call Control Protocol based on SIP Rel-20
TS 24.259 vj00 Personal Network Management (PNM) Protocol Details Rel-19
TS 24.282 vk00 Mission Critical Data (MCData) signalling control protocols Rel-20
TS 24.301 vk00 3GPP TS 24301 vk00: NAS Protocols for EPS Rel-20
TS 24.483 vk00 MCS Management Objects Configuration Rel-20
TS 24.484 vk00 MCS Configuration Management Protocols Rel-20
TS 24.501 vk00 5G System (5GS) Non-Access Stratum (NAS) Protocol Rel-20
TS 24.524 vj00 Hosted Enterprise Services Architecture Rel-19
TS 26.117 vj20 5G Media Streaming (5GMS) Rel-19
TS 26.142 vj00 3GPP TS 26.142: Dynamic and Interactive Multimedia Scenes (DIMS) Rel-19
TS 26.247 vj10 Transparent End-to-End Packet-switched Streaming Rel-19
TS 26.804 vk00 5G Media Streaming Architecture Extensions Rel-20
TR 26.938 vj00 DASH Deployment Guidelines for 3GPP Networks Rel-19
TS 29.162 vj00 IMS-IP Network Interworking Rel-19
TS 29.333 vj00 MRFC-MRFP Mp Interface Protocol Rel-19
TR 29.949 vj00 VoLTE IMS Roaming Architecture & Procedures Rel-19
TS 32.275 vj00 MMTel Charging Specification Rel-19