The Problem

Mobile networks are designed to be redundant and resilient, with N+1 for everything.

Every network element connects to multiple other network elements.

The idea being the network is architected so a failure of any one network element will not impact service.

To take an LTE/EPC example, your eNodeBs connect to multiple MMEs, which in turn connect to multiple HSSs, multiple S-GWs, multiple EIRs, etc.
The problem is when each eNodeB connects to 3 MMEs, and you want to add a 4th MME, you have to go and reconfigure all the eNodeBs to point to the new MME, and all the HSSs to accept that MME as a new Diameter Peer, for example.

The more redundant you make the network, the harder it becomes to change.

This led to development of network elements like Diameter Routing Agents (DRAs) and DNS SRV for service discovery, but ultimately adding and removing network elements in previous generations of mobile core, involved changing a lot of config on a lot of different boxes.

The Solution

The NRF – Network Repository Function serves as a central repository for Network Functions (NFs) on the network.

In practice this means when you bring a new Network Function / Network Element online, you only need to point it at the NRF, which will tell it about other Network Functions on the network, register the new Network Function and let every other interested Network Function know about the new guy.

Take for example adding a new AMF to the network, after bringing it online the only bit of information the AMF really needs to start placing itself in the network, is the details of the NRF, so it can find everything it needs to know.

Our new AMF will register itself to the NRF, advertising what Network Functions it can offer (ie AMF service), and it’ll in turn be able to learn about what Network Functions it can consume – for example our AMF would need to know about the UDMs it can query data from.

It is one of the really cool design patterns usually seen in modern software, that 3GPP have adopted as part of the 5GC.

In Practice

Let’s go into a bit more detail and look at how it looks.

The NRF uses HTTP and JSON to communicate (anything not using ASN.1 is a winner), and looks familiar to anyone used to dealing with RESTful APIs.

Let’s take a look at how an AMF looks when registering to a NRF,

NF Register – Providing the NRF a profile for each NF

In order for the NRF to function it has to know about the presence of all the Network Functions on the network, and what they support. So when a new Network Function comes online, it’s got to introduce itself to the NRF.

It does this by providing a “Profile” containing information about the Network Functions it supports, IP Addresses, versions, etc.

Going back to our AMF example, the AMF sends a HTTP PUT request to our NRF, with a JSON payload describing the functions and capabilities of the AMF, so other Network Functions will be able to find it.

Let’s take a look at what’s in the JSON payload used for the NF Profile.

• Each Network Function is identified by a UUID – nfInstanceId, in this example it’s value is “f2b2a934-1b06-41eb-8b8b-cb1a09f099af”
• The nfType (Network Function type) is an AMF, and it’s IP Address is 10.0.1.7
• The heartBeatTimer sets how often the network function (in this case AMF) sends messages to the NRF to indicate it’s still alive. This prevents a device registering to an NRF and then going offline, and the NRF not knowing.

The nfServices key contains an array of services and details of those services, in the below example the key feature is the serviceName which is namf-comm which means the Namf_Communication Service offered by the AMF.

The NRF files this info away for anyone who requests it (more on that later) and in response to this our NRF will indicate (hopefully) that it’s successfully created the entry in its internal database of Network Functions for our AMF, resulting in a HTTP 201 “Created” response back from the NRF to the AMF.

NRF StatusSubscribe – Subscribe & Notify

Simply telling the NRF about the presence of NFs is one thing, but it’s not much use if nothing is done with that data.

A Network Function can subscribe to the NRF to get updates when certain types of NFs enter/leave the network.

Subscribing is done by sending a HTTP POST with a JSON payload indicating which NFs we’re interested in.

Whenever a Network Function registers on the NRF that related to the type that has been subscribed to, a HTTP POST is sent to each subscriber to let them know.

For example when a UDM registers to the network, our AMF gets a Notification with information about the UDM that’s just joined.

NRF Update – Updating NRF Profiles & Heartbeat

If our AMF wants to update its profile in the NRF – for example a new IP is added to our AMF, a HTTP PATCH request is sent with a JSON payload with the updated details, to the NRF.

The same mechanism is used as the Heartbeat / keepalive mechanism, to indicate the NRF is still there and working.

Summary

The NRF acts as a central repository used for discovery of neighboring network functions.