How Network Repository Function Plays a Critical Role in Cloud Native 5G SA Network

NRF (Network Repository Function) facilitates cloud-native 5G networks by enabling dynamic and efficient discovery of peer Network Functions, enhancing scalability.

Ajay Lotan Thakur


DNS (Domain Name Service) has been widely used by networks to discover 3G and 4G Network Functions (NFs). Every time there is a change in the network, this entails adding or updating records in the DNS server. This solution was not cohesive. The 5G Network Repository Function (NRF), which was introduced in the 5G specification, addresses this issue. Every Network Function needs to register its profile with NRF when it’s ready to service the APIs. Every NF type contains unique information in the NF profile. For example, Session Management Function (SMF) might provide the set of Data Network Names (DNN) it serves.

It’s important to note is that SMF may still choose User Plane Function (UPF) using proprietary logic because the UPF interface to NRF is still optional. In this article we shall see various advantages provided by 3GPP’s NRF network function over traditional 3G/4G networks.

Advantages of 5G NRFs:

Using 5G Network Resource Function (NRF) for discovering peer Network Functions (NFs) compared to relying on DNS servers in 4G networks brings several advantages:

  1. Efficiency in Resource Discovery: NRF offers a more efficient and dynamic way of discovering peer NFs within the network. Unlike DNS servers, which rely on static records and hierarchical lookup mechanisms, NRF enables direct discovery of available NFs, reducing latency and enhancing resource utilization. NRF can search the NFs based on many parameters like load, slice Ids, DNN name etc.
  2. Enhanced Security: NRF can incorporate security features such as authentication and authorization mechanisms, ensuring that only authorized NFs can be discovered and accessed. This helps in mitigating security threats such as DNS spoofing or cache poisoning, which are concerns in traditional DNS-based architectures.
  3. Support for Network Slicing: NRF is well-suited for 5G network slicing, where multiple virtualized networks coexist on the same physical infrastructure. It allows for efficient discovery and allocation of NFs specific to each network slice, enabling tailored services and resource optimization.
  4. Service Orchestration: NRF facilitates service orchestration by providing real-time information about the available NFs and their capabilities. This enables dynamic service composition and adaptation based on changing network conditions and application requirements. NRF can be used to put some of the NFs under maintenance mode as well.
  5. Low Latency: With NRF, the latency in discovering and connecting to peer NFs is significantly reduced compared to DNS-based approaches. This is crucial for applications requiring real-time communication or low-latency services, such as edge computing or autonomous vehicles. In case NRF is overloaded then it can scale-out to bring down the latency.
  6. Scalability: NRF architecture is designed to handle the scalability demands of 5G networks, where the number of NF instances and their dynamic nature can be high. It allows for efficient scaling of network resources without relying on centralized DNS servers, which may face scalability challenges under heavy loads.  This allows Network Functions to implement dynamic scale in & scale out without touching any DNS servers.
  7. Dynamic Network Updates: NRF supports dynamic updates of network information, allowing for real-time changes in the availability and status of NF instances. These are NRF notifications supported as per 3gpp specification.  In contrast, DNS records may require time to propagate changes across the network, leading to potential inconsistencies or delays in service discovery. Each NF can update its profile as and when it sees changes.


Overall, leveraging NRF for NF discovery in 5G networks offers improved efficiency, scalability, low latency, security, and support for advanced network functionalities compared to relying solely on DNS servers in 4G networks.


3GPP TS 23.501 – System Architecture for the 5G System

3GPP TS 29.510 – Network Function Repository Services

Building and Operating a Cloud Native 5G SA Core Network

GSA: More 5G SA devices, but commercial 5G SA deployments lag

Global 5G Market Snapshot; Dell’Oro and GSA Updates on 5G SA networks and devices

Ericsson Mobility Report touts “5G SA opportunities”

Analysys Mason: 40 operational 5G SA networks worldwide; Sub-Sahara Africa dominates new launches

Samsung and VMware Collaborate to Advance 5G SA Core & Telco Cloud

5G SA networks (real 5G) remain conspicuous by their absence

GSM 5G-Market Snapshot Highlights – July 2023 (includes 5G SA status)


About the Author:

Ajay Lotan Thakur, Senior IEEE Member, IEEE Techblog Editorial Board Member, BCS Fellow, TST Member of ONF’s open source Aether (Private 5G) Project, Cloud Software Architect at Intel Canada.

Blog post edited by Alan J Weissberger

6 thoughts on “How Network Repository Function Plays a Critical Role in Cloud Native 5G SA Network

    1. Each record I.e NF profile has expiry field. Each NF is supposed to send keep alive message to NRF to keep the record active

  1. I’m grateful that Alan and Ajay produced such an amazing work for the 5G community. It is recommended that you hold a webinar to provide attendees with additional information regarding this and other aspects of the 5G architecture. I appreciate you also for directing me to the IEEE ComSoc website, which has a ton of other really smart pieces.

  2. The way you have emphasized the importance of NRF in 5G architecture is remarkable. I have frequently read papers about network slicing, but I have never come across any articles about NRF or issues with the older 3G and 4G architecture.

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>