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
Detected Changes Across Releases
from 3GPP Change RequestsSpecific 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.
- 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
- 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
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 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 |