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
Release Timeline
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (3 CRs across 2 releases). Complements the general historical overview above with the evidence-based evolution of this function.
In Release 15, the specification introduced support for emergency numbers lists using Uniform Resource Name (URN) formats. This included defining the specific encoding of characters for the sub-services of an associated emergency service URN. These changes facilitate the provision of restricted local operator services, enabling User Equipments (UEs) to access such services without prior authentication.
In Release 16, the new URN (Uniform Resource Name) function was introduced to support MCData emergency alert and communications, specifically to enable the provision of restricted local operator services. This allows User Equipments (UEs) to access these operator-provided services without requiring authentication, addressing a need based on FCC regulations. The release formally defined the abbreviations URN, UUID, and IMPU within the 3GPP specifications in this context.
- 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 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.
| Specification | Title | Release |
|---|---|---|
| TS 22.820 vf00 | Restricted Local Operator Services for Unauthenticated UEs | Rel-15 |
| TS 23.167 vj11 | IMS Emergency Sessions | Rel-19 |
| 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 vj60 | IMS Data Channel applications | Rel-19 |
| TS 24.229 vj50 | IMS call control protocol based on SIP and SDP | Rel-19 |
| TS 24.259 vj00 | Personal Network Management (PNM) Protocol Details | Rel-19 |
| TS 24.282 vj50 | MCData Signalling Control Protocols | Rel-19 |
| TS 24.301 vj60 | NAS protocol for Evolved Packet System | Rel-19 |
| TS 24.483 vj20 | Mission Critical Services Management Object | Rel-19 |
| TS 24.484 vj30 | MCS Configuration Management | Rel-19 |
| TS 24.501 vj50 | 5G NAS Protocols Specification | Rel-19 |
| TS 24.524 vj00 | Hosted Enterprise Services Architecture | Rel-19 |
| TS 26.117 vj00 | 5G Media Streaming Speech/Audio Capabilities | Rel-19 |
| TS 26.142 vj00 | 3GPP TS 26.142: Dynamic and Interactive Multimedia Scenes (DIMS) | Rel-19 |
| TS 26.247 vj00 | 3GPP Progressive Download & DASH over HTTP | Rel-19 |
| TS 26.804 vj10 | 5G Media Streaming Extensions Study | Rel-19 |
| 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 |