URN

Uniform Resource Name

Identifier →
Introduced in Rel-6 Also in: Core Network

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.

Category
Identifier
Introduced
Rel-6
Where
Services › Codecs
Also touches
1 segments
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 (48 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Studied in Rel-6, normative work from Rel-15.

Rel-15 9 changes

In Release 15, the URN (Uniform Resource Name) function was newly introduced to support emergency numbers lists with specific URN formats. This included work on the encoding of characters for the sub-services of associated emergency service URNs. These enhancements provided a structured framework for identifying emergency services through standardized resource names.

  • Emergency numbers list with URN formats TS 24.301CR2998
  • Encoding of characters of the sub-services of the associated emergency service URN TS 24.301CR3167
  • Correction for establishment of user-plane resources TS 24.501CR0013
  • UAC information and establishment cause when uplink user data packet is to be sent for a PDU session with suspended user-plane resources TS 24.501CR0027
  • Clarification on activation of UP resources of PDU session TS 24.501CR0192
  • Reactivation result indicating insufficient resources during service request procedure TS 24.501CR0277

+ 3 more changes

Rel-16 10 changes

In Release 16, the URN (Uniform Resource Name) function was explicitly defined and its abbreviation formally expanded within the specifications to provide clarity. This was part of enhancements supporting Mission Critical Data (MCData) emergency alert and communications, where precise resource identification is crucial. The release also reinforced the role of URNs in enabling restricted local operator services for unauthenticated UEs, aligning with regulatory needs.

  • Pre-established session – General and PF use of resource sharing TS 24.282CR0081
  • 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
  • PDU session ID usage when the UE is a 5G-RG and requests establishment of a PDN connection as a user-plane resource of a MA PDU session TS 24.301CR3326
  • Configuration of resource priority for MCData emergency TS 24.484CR0137
  • Access stratum connection and user-plane resources for trusted non-3GPP access and wireline access TS 24.501CR1685
  • Handling of user-plane resources for NB-IoT UEs having at least two PDU sessions TS 24.501CR1672

+ 4 more changes

Rel-17 13 changes

In Release 17, the URN function itself was not directly modified by the listed Change Requests. The updates focused on refining resource management procedures for services like Mission Critical Data (MCData), Multicast/Broadcast Services (MBS), and V2X communications over PC5. These enhancements included new triggers for the Service Request procedure when requesting 5G ProSe resources and mechanisms for local deactivation of user-plane resources in Multi-Access PDU sessions.

  • Resource sharing aspects in MCData TS 24.282CR0326
  • C2 pairing authorization at bearer resource modification TS 24.301CR3532
  • Addition to UE requested bearer resource modification procedure TS 24.301CR3634
  • Local deactivation of UP resource for an MA PDU session with PDN leg - 24301 Part TS 24.301CR3657
  • Local deactivation of UP resource for an MA PDU session with PDN leg - 24501 Part TS 24.501CR3860
  • UE MBS session local leave when the 3GPP access UP resources are released TS 24.501CR4029

+ 7 more changes

Rel-18 13 changes

In Release 18, the URN (Uniform Resource Name) function was enhanced to support the provision of restricted local operator services, enabling UEs to access these services without authentication to comply with FCC regulations. This specifically involved defining the procedures and mechanisms for UEs to utilize URNs to reach operator-provided services in a restricted local context. The updates ensure the network can correctly handle and prioritize these special service requests.

  • Request resources for A2X communication over PC5 TS 24.501CR5357
  • DC resource release due to a CANCEL request TS 24.186CR0024
  • Fix references to application/resource-lists+xml MIME body TS 24.282CR0343
  • Fix references to application/resource-lists+xml MIME body (mcdata) TS 24.282CR0380
  • MCData QoS - Resource Management TS 24.282CR0419
  • EPS bearer handling after CPSR with active flag not having bearer resource (24.301) TS 24.301CR3941

+ 7 more changes

Rel-19 3 changes

In Release 19, the URN function was enhanced to provide restricted local operator services without requiring UE authentication, a capability driven by FCC regulations. The updates specifically introduced new procedures for handling user plane resource requests when they are associated with an S-NSSAI not allowed for the current location or for an always-on PDU session, ensuring proper network control. Additionally, a mechanism for UE state indication within the bearer resource modification request procedure was defined.

  • UE STATE INDICATION in BEARER RESOURCE MODIFICATION REQUEST with QoS update procedure TS 24.301CR4163
  • User plane resource request PDU associated with S-NSSAI not in the allowed S-NSSAI for the current TA TS 24.501CR6506
  • User plane resource request is prohibited for an always-on PDU session associated with an S-NSSAI not allowed by S-NSSAI location validity information TS 24.501CR6945

Explore further

Broader topics and technologies where URN plays a role.

Topics
SON (Self-Organizing Networks)OAM (Operations & Maintenance)IMS & Voice (VoLTE, VoNR)Roaming & InterconnectMEC (Edge Computing)Emergency Services

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