Fully Qualified Domain Name

Description

In 3GPP architecture, a Fully Qualified Domain Name (FQDN) is a fundamental identifier used within Uniform Resource Identifiers (URIs) to unambiguously locate resources in an IP network. An FQDN consists of a hostname and its parent domain(s), all the way up to the top-level domain (TLD), written as a dot-separated sequence (e.g., `nrf.epc.mnc001.mcc505.3gppnetwork.org`). It is 'fully qualified' because it leaves no ambiguity about the host's position in the DNS tree; it is an absolute path. Within 3GPP specifications, FQDNs are not just for web servers but are critically embedded in the service-based architecture (SBA) of the 5G Core (5GC) and the IP Multimedia Subsystem (IMS).

Mechanically, FQDNs work in conjunction with the Domain Name System (DNS). When a network function (NF), such as a Session Management Function (SMF), needs to communicate with another NF, like a Policy Control Function (PCF), it often constructs or is configured with a target FQDN. This FQDN follows a standardized naming convention defined by 3GPP (e.g., in TS 23.003). The requesting NF performs a DNS query (typically for NAPTR, SRV, or A/AAAA records) to resolve this FQDN into one or more IP addresses and port numbers where the service is reachable. This process, known as DNS-based Service Discovery, is central to the dynamic, scalable nature of cloud-native 5G cores, allowing for load balancing, redundancy, and seamless scaling of NFs.

The structure of an FQDN in 3GPP is highly organized. For example, an FQDN for a Network Repository Function (NRF) in a 5G network might be: `nrf.5gc.mnc<MNC>.mcc<MCC>.3gppnetwork.org`. This structure encodes the NF type (`nrf`), the network slice/instance (`5gc`), the Mobile Network Code (MNC), Mobile Country Code (MCC), and a dedicated 3GPP top-level domain. This hierarchical naming allows for logical organization and efficient DNS resolution. FQDNs are used in countless 3GPP procedures: for HTTP/2 service endpoints between NFs, for SIP routing in IMS (e.g., the home domain in a SIP URI like `sip:[email protected]`), for connecting to charging systems, policy servers, and for accessing application servers. They provide the essential layer of indirection that decovers the logical service identity from its physical IP location, enabling network agility and automation.

Purpose & Motivation

The adoption of FQDNs within 3GPP was driven by the industry's shift towards all-IP networks and web-based architectures. Early cellular systems relied on static, pre-configured point codes or IP addresses for node addressing, which were inflexible and difficult to manage at scale. As networks evolved towards IMS (3GPP Release 5/6) and later the cloud-native 5G Core, there was a critical need for a dynamic, scalable, and standardized way to discover and communicate with distributed network services. FQDNs, coupled with DNS, solve this problem by providing a globally unique, hierarchical naming system that supports discovery, load balancing, and failover.

The historical motivation lies in overcoming the limitations of hard-coded network topology. In a monolithic network, adding a new server required updating configuration on all peers. In a modern, microservices-based 5G core with auto-scaling and geographic redundancy, NFs can be instantiated and terminated dynamically. FQDNs allow a consumer NF to find a producer NF without knowing its exact IP address beforehand. The DNS resolution layer can return different IPs based on load, location (for edge computing), or service availability. This addresses key requirements for network automation, scalability, and resilience, making FQDNs a cornerstone technology for implementing the Service-Based Architecture (SBA) and enabling efficient network slicing, where different slices might resolve the same NF type (e.g., `smf`) to different instances based on the slice-specific FQDN.

Key Features

• Provides an absolute, unambiguous domain name for a host or network function
• Follows hierarchical 3GPP naming conventions encoding NF type, network, and PLMN
• Used within URIs for HTTP/2-based service interfaces in 5G SBA
• Essential for DNS-based service discovery and load balancing of NFs
• Enables dynamic network topology and cloud-native scalability
• Fundamental for SIP routing in IMS and for identifying application servers

Evolution Across Releases

Defining Specifications