In a 5G core network, an AMF does not need to keep a static list of every AUSF or UDM instance before it can initiate a procedure. Instead, it can query the NRF, submit the required selection context, and obtain the profile of a suitable target function. This change may look procedural on the surface, but it reflects a much deeper architectural shift: 5GC moves from static node lookup to dynamic, service-based discovery.
Architectural Shift: From DNS-Based Lookup to NRF Service Discovery
In 4G EPC, network element discovery and selection mainly revolved around MME-related procedures. Different signaling scenarios relied on different forms of FQDN resolution through DNS. For example, a new MME could find an old MME during attach or TAU using GUMMEI-FQDN. During handover, a source MME could locate a target MME through TAI-FQDN. Likewise, an MME could select an SGW based on TAI-FQDN and a PGW based on APN-FQDN.
This model worked well for EPC, but it depended heavily on static configuration. DNS records had to be prepared in advance, and changes in network function address, capability, or deployment status required manual updates. When a node was removed, the related DNS data also had to be cleaned up. In other words, lifecycle changes and discovery data were connected, but mostly through preconfigured operational work.
| Comparison Item | 4G EPC | 5GC |
|---|---|---|
| Discovery method | DNS query | NRF query |
| Interface protocol | DNS | HTTP/2 |
| Registration method | Static preconfiguration | NF self-registration |
| Information updates | Modify DNS records | NF sends profile updates to NRF |
| Deregistration | Delete DNS records | NF actively deregisters |
| Service scope | Mainly MME-related selection | All major core NFs such as AMF, SMF, AUSF, and UDM |
With the service-based architecture introduced in 5GC, network functions are no longer treated only as fixed nodes in a topology. They become service providers that expose capabilities through SBI. The NRF serves as the repository and discovery point for available NF instances and their supported services. As a result, selection is no longer tied to static DNS planning alone. It becomes a dynamic process driven by the current NF profiles registered in the core.
NF Registration and Discovery: Core Operating Mechanism
The operating logic of 5GC discovery can be understood as a sequence of registration, profile maintenance, and discovery. When a new NF instance is created, it first registers itself to the NRF. The NRF stores the instance profile. Later, when another NF requires a service, it queries the NRF and retrieves a suitable target instance.
Registration is typically triggered when a new virtualized or cloud-native NF instance comes online. The instance uses the Nnrf_NFManagement service and sends an HTTP PUT request containing its NF Profile. Once accepted, the NRF returns a successful response and records that instance as discoverable. The stored profile can include the NF type, IP address, FQDN, supported services, PLMN information, priority, capacity, and slice-related attributes.
Discovery is triggered by actual signaling procedures. A common example is AMF selecting AUSF during the registration and authentication flow. In that case, the AMF calls the Nnrf_Discovery service and sends an HTTP GET request with the relevant selection conditions. The NRF then searches among registered NF profiles and returns one or more matching candidates. The requesting NF can use the returned profile data to establish direct service interaction with the chosen target.
An important strength of this model is that it supports the full lifecycle of an NF instance. If a function changes its address, expands capacity, or updates its supported capabilities, it can send a profile update using HTTP PATCH. If the instance is withdrawn for maintenance, scaling adjustment, or service retirement, it can deregister itself through HTTP DELETE. This keeps the discovery database aligned with the real-time state of the network instead of relying on delayed manual record maintenance.
NF Selection Logic: Key Parameters and Matching Rules
The NRF does not return a target instance randomly. The result depends on the selection input provided by the requesting NF. These parameters reflect the service context, subscriber context, and network deployment logic associated with the procedure. Different target network functions use different key conditions.
| Target NF | Main Selection Inputs |
|---|---|
| SMF | DNN, S-NSSAI, PLMN ID, and related context |
| AUSF | MCC, MNC, and Routing Indicator from SUCI |
| AMF | GUAMI and TAI |
| PCF | DNN, SUPI range, and session-related S-NSSAI |
| UDM | SUPI and Routing Indicator from SUCI |
These inputs are not arbitrary. They exist because different network functions serve different purposes. When selecting an SMF, the network must consider which data network is being accessed, which slice the session belongs to, and which PLMN context applies. When selecting an AUSF or UDM, user identity and routing-related information become far more important. AMF selection, meanwhile, is closely tied to mobility and area-related identifiers such as GUAMI and TAI.
This parameter-based mechanism is one of the reasons 5GC can scale more gracefully than earlier static models. The NRF maintains a structured view of available service providers, while the requester expresses what kind of function it actually needs. Discovery then becomes a context-aware matching process rather than a simple name-resolution step.
Architectural Value and Key Takeaways
The move from DNS-based node selection in EPC to NRF-based service discovery in 5GC is more than a protocol change. It is a redesign of how core network functions are introduced, updated, located, and used. Registration, discovery, update, and deregistration all become part of a unified operational model.
From an engineering perspective, the NRF does not perform the service on behalf of other functions. Its role is to maintain discoverable NF profiles and return the right candidates when queried. The actual service interaction still happens directly between the requesting NF and the selected target NF.
That separation of roles matters. It allows 5GC to support dynamic deployment, elastic scaling, and more automated lifecycle management while keeping service invocation efficient and standards-based. In practical terms, the NRF is the coordination point that turns the service-based architecture from a concept into an operational reality.
FAQ
Does the NRF store only addresses, or does it keep richer information?
The NRF stores much more than addresses. A typical NF Profile can include NF type, FQDN, supported services, capacity, priority, PLMN data, slice-related information, and other attributes used for discovery and policy-aware matching.
Can more than one candidate be returned during discovery?
Yes. Depending on the request and deployment policy, the NRF may return multiple matching NF instances. The requesting function or local policy logic can then choose the most suitable candidate.
Why is HTTP/2 important in this mechanism?
HTTP/2 supports the service-based interface model used in 5GC. It enables standardized service invocation between network functions and aligns the discovery process with the broader SBA communication framework.
Is NRF-based discovery useful only in large cloud-native cores?
No. The benefits also apply in smaller deployments because centralized discovery improves consistency, reduces static configuration effort, and simplifies future scaling or architectural evolution.
