Skip to content
Docs / dflux TinyCore
ContactGet started

NF discovery

How the NRF lets network functions register, find each other, and stay alive through heartbeats — the registry at the center of the service-based architecture.

Overview

The NRF (Network Repository Function) is the registry at the center of the 5G service-based architecture. Every other NF registers its profile with the NRF on startup, and any NF that needs to reach another — say the SMF looking for a UPF — asks the NRF to discover it. The NRF keeps the live view of which NFs exist, where they are, and what they serve.

Registration

An NF registers by sending its profile to the NRF with a PUT to nf-instances/{id}. The same call updates an existing profile. The profile describes the NF: its instance ID and type (AMF, SMF, UPF, NRF, …), status, addresses (IPs/FQDN/port), the services it offers, the PLMNs and slices it serves, and the heartbeat interval it expects.

Discovery

Discovery is a GET on nf-instances filtered by the target NF type (plus optional filters like service names, S-NSSAIs, DNN, or PLMN). The NRF returns the matching profiles so the requester can pick an endpoint and call it directly. Discovery responses are cacheable so clients don't have to re-query on every call.

Heartbeat lifecycle

Registration isn't permanent — an NF must prove it's still alive by sending periodic heartbeats (a PATCH that resets its timer). The NRF runs a small state machine over each NF:

text

The heartbeat interval comes from the NF's profile (default 60 seconds). An NF that goes quiet is suspended and then deregistered, so discovery only ever returns NFs that are actually reachable.

Status subscriptions

Rather than polling, an NF can subscribe to status changes. The NRF then delivers asynchronous notifications — NF_REGISTERED, NF_DEREGISTERED, and NF_PROFILE_CHANGED — to the subscriber's callback URI as NFs come and go or change their profile.

OAuth2 access tokens

Optionally, the NRF can act as an OAuth2 authorization server. When enabled, an NF requests a token (client-credentials grant) and presents it as a Bearer token on NF-management and discovery calls; the NRF issues and verifies RS256-signed JWTs. This is off by default — the lab runs cleartext SBI — and is enabled for securing NF-to-NF communication.

Turning it on
See Securing NF communication for enabling OAuth2 (and TLS), and the d3x-core-nrf CLI reference for the exact flags and defaults.
Lab scope
dflux TinyCore's NFs auto-register with the NRF on startup (the four required functions, plus NSSF and SMSF when you start them), so in a typical lab discovery just works. The NRF can also stand in as a drop-in replacement for an open5gs NRF for interop testing.