Description
The Internet Assigned Numbers Authority (IANA) is a function, historically performed by ICANN, that coordinates key technical elements of the global Internet to ensure its stable and secure operation. Its core responsibilities include the allocation of IP address blocks to Regional Internet Registries (RIRs), the administration of the AS Number space, and the management of the DNS root zone. Crucially for protocol development, IANA maintains registries of "protocol parameters" – the code points, numbers, and identifiers used in Internet protocols (e.g., IP protocol numbers, TCP/UDP port numbers, enterprise numbers for SNMP and RADIUS).
In the context of 3GPP standards, IANA's role is referential. 3GPP technical specifications (TSs) do not define new global protocol numbers arbitrarily. Instead, when a 3GPP-defined protocol needs a unique identifier for use on IP networks (e.g., a new GTP extension, a DIAMETER application, or a protocol type in a packet header), the specification mandates that the value must be assigned by IANA. For example, TS 29.060 (GTP) specifies that GTPv1-C message types must be registered with IANA, and TS 29.272 (E-UTRAN DIAMETER interfaces) defines DIAMETER Application-Ids that require IANA assignment. This ensures global interoperability and prevents conflicts with other standards bodies.
The process involves 3GPP submitting a request to IANA via an IETF RFC or through direct liaison, following IETF guidelines (RFC 5226). Once assigned, these numbers are published in IANA's online registries. 3GPP equipment and network nodes (e.g., PGWs, MMEs, PCRFs) are then implemented using these globally unique, IANA-assigned values. This dependency highlights the deep integration of 3GPP architectures with the broader Internet protocol ecosystem, ensuring that 5G and LTE networks can seamlessly exchange data and signaling with servers and networks on the public Internet.
Purpose & Motivation
IANA exists to provide a central, neutral coordination point for the technical parameters that underpin the global Internet's interoperability. Without such a central authority, different vendors, operators, and standards bodies might independently assign the same number for different purposes, leading to protocol conflicts, packet misrouting, and service failures. The creation of IANA (originally managed by Jon Postel) was motivated by the need for order in the early, rapidly expanding ARPANET and Internet, ensuring that fundamental resources like IP addresses and protocol numbers were allocated in a fair and consistent manner.
For 3GPP, referencing IANA solves the problem of how to integrate mobile-specific protocols into the global Internet infrastructure. 3GPP networks are not isolated; they connect to the Internet and interwork with IETF-defined protocols daily. By using IANA-assigned numbers, 3GPP ensures that its protocols (e.g., GTP, DIAMETER, PFCP) are uniquely identifiable on IP networks worldwide. This approach addresses the limitations of proprietary or organization-specific number spaces, which would cause interoperability nightmares in multi-vendor, multi-operator environments. The historical context is the convergence of telecommunications and Internet technologies, where 3GPP adopted IP as its core transport, necessitating adherence to the Internet's established coordination mechanisms.
Classification
Release Timeline
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (7 CRs across 4 releases). Complements the general historical overview above with the evidence-based evolution of this function.
In Release 15, the newly introduced IANA function involved the completion of registrations for Mission Critical services, specifically for MCPTT (Mission Critical Push-To-Talk) from Release 13 and MCData (Mission Critical Data) from Release 14. These registrations ensured the global uniqueness of application identifiers, which are specified as IANA-registered MIME types or composed to include the application developer's URL. This process formalized the use of standards-tree and vendor-tree MIME types for these critical communications services.
In Release 16, the new IANA-related work included the allocation of a specific SCTP port number and the completion of IANA registrations for MCVideo services. These actions ensured that the necessary protocol parameters and service identifiers were formally registered for global interoperability. This continued the established practice of using IANA-registered MIME types or developer URLs to guarantee the global uniqueness of application identifiers.
In Release 18, the IANA function was updated to include new registrations for specific attribute types. This included the registration for the AT_HPA_INFO attribute and the assignment of a value for the AT_DEVICE_IDENTITY attribute. These actions ensure the global uniqueness of these identifiers as per the established procedures.
In Release 19, the new IANA-related work introduced a formal registration template for "Location user configuration data document." This establishes a standardized format for registering location-based service configuration data with IANA. The update leverages the existing IANA framework for guaranteeing global uniqueness through registered MIME types or developer URLs, as specified in the foundational RFCs.
- IANA Registration Template - Location user configuration data document TS 24.484CR0291
Explore further
Broader topics and technologies where IANA plays a role.
Defining Specifications
3GPP specifications that define or reference IANA, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 23.140 v1600 | MMS Non-Realtime Service Definition | Rel-6 |
| TS 23.816 v1700 | IMS Communication Service Identifier | Rel-7 |
| TS 24.302 vj00 | Access to EPC via non-3GPP networks; Stage 3 | Rel-19 |
| TS 24.484 vj30 | MCS Configuration Management | Rel-19 |
| TS 26.142 vj00 | 3GPP TS 26.142: Dynamic and Interactive Multimedia Scenes (DIMS) | Rel-19 |
| TS 26.143 vj00 | 5G Messaging Media Types and Codecs | Rel-19 |
| TS 26.346 vj20 | MBMS User Services Media Codecs & Protocols | Rel-19 |
| TS 26.804 vj10 | 5G Media Streaming Extensions Study | Rel-19 |
| TS 26.841 vj00 | Study on Media Messaging Enhancements | Rel-19 |
| TS 29.060 vj00 | GPRS Tunnelling Protocol (GTP) version 1 | Rel-19 |
| TS 29.173 vj00 | Diameter-based SLh Interface for LCS | Rel-19 |
| TS 29.229 vj10 | Diameter Protocol for Cx/Dx Interfaces | Rel-19 |
| TS 29.230 vj30 | 3GPP Diameter Protocol Codes Specification | Rel-19 |
| TS 29.329 vj10 | Diameter Protocol for Sh Interface | Rel-19 |
| TS 29.336 vj10 | HSS Diameter Interfaces for PDN Interworking | Rel-19 |
| TS 29.337 vj00 | Diameter T4 Interface for MTC Device Triggering | Rel-19 |
| TS 29.338 vj30 | Diameter protocols for SMS in MME/5GS | Rel-19 |
| TS 29.414 vj00 | Nb Interface Bearer Transport & Control Protocols | Rel-19 |
| TR 29.835 vh10 | Study on Port Allocation for 3GPP Interfaces | Rel-17 |
| TS 31.113 v1800 | USAT Interpreter Byte Code Specification | Rel-8 |
| TS 32.272 vj00 | Charging for Push-to-Talk over Cellular (PoC) | Rel-19 |
| TS 36.422 vj00 | X2 Signalling Transport Specification | Rel-19 |
| TS 36.462 vj00 | Xw Interface Signalling Transport | Rel-19 |
| TS 37.472 vj00 | W1 Interface Signalling Transport Specification | Rel-19 |
| TS 37.482 vj00 | E1 Signalling Transport Specification | Rel-19 |
| TS 38.412 vj00 | NG Signalling Transport | Rel-19 |
| TS 38.422 vj00 | Xn Signalling Transport Specification | Rel-19 |
| TS 38.462 vj00 | E1 Signalling Transport Specification | Rel-19 |
| TS 38.472 vj00 | F1 Interface Signalling Transport Specification | Rel-19 |
| TR 38.825 vg00 | Study on NR Industrial IoT | Rel-16 |