NRF — NF Repository Function — the register every function looks the others up in

5G Systems Notes · Concept map · NRF Route · Hierarchy · Index · All concepts · Hub

The core network

Where it sits

Sits atLevel 5 of the hierarchy · The core network · explained
Learn firstNF service — 5 concepts in the full chain, see the paths
UnlocksNothing else depends on it directly.
Primary clauseTS 23.501 §6.2.6
Used inref-core 6 · index 1 · ref-session 1
Scanned from the notes at page load and joined with terms.json; nothing on this card is typed by hand.

What it is

What it is. The NF Repository Function — the register that every other network function publishes itself into and looks the others up in. TS 23.501 §6.2.6. Its functionality list is short and every line is about the same job:

Supports service discovery — receives an NF Discovery Request and returns the discovered NF instances · maintains the NF profile of available NF instances and their supported services · maintains SCP profiles and supports SCP discovery · notifies subscribers about newly registered, updated and deregistered NF instances · maintains the health status of NFs and SCPs · supports discovery of NRF services themselves through the NRF bootstrapping service.

It is the one address in the core that is configured. Everything else is discovered, which means the NRF is the root of the whole naming scheme: lose it and no function can find another; have it and nothing else needs configuring. The bootstrapping service in the first line exists precisely so that even the NRF's own service endpoints can be fetched rather than assumed.

Health status is in the list, and that is a design statement. A register that only stored profiles would happily hand out the address of a function that died an hour ago. Because the NRF tracks liveness, discovery doubles as availability filtering — a consumer that asks for a producer gets one that is up. Registration is a lease, not a permanent entry.

Notification, not just query. A consumer can subscribe to changes rather than re-querying, so a new instance coming up is pushed to the functions that care.

Slicing changes where it sits, not what it does. TS 23.501 §6.2.6 notes that in the context of network slicing, multiple NRFs may be deployed at three levels: PLMN level (information for the whole network), shared-slice level (a set of slices), and slice-specific level (one S-NSSAI). A discovery query may therefore be answered by a hierarchy — which keeps a slice's internal topology private to the slice.

Read on

This concept is read as part of one argument in ref-core, alongside the rest of its group.

Widget not found: sim_status

Before this concept, the hierarchy says to learn the following — the full chain, in order:

To understand NRF (level 5) you first need 5 other concepts. Read them in this order — everything on one line can be read in any order, but no line before the one above it:
Level Learn these
0 5G Core
1 Network function
2 Service-based architecture
3 SBI
4 NF service
Immediately before NRF: NF service.
Keep going — where this sits on the route
◀EVMstep 55 · level 5
Step 56 of 118level 5 · The core network
GTP-Ustep 57 · level 5▶
Nothing depends on this one directly
It is a leaf of the graph — follow the route rather than the branch.
↳ all 11 concepts at level 6 · level 5 in full · the whole route
The route is every concept in the folder ordered by level, so nothing here needs anything after it. Computed at page load from terms.json; the same numbering as the route page.
5G Systems Notes · Concept map · NRF Top · Concept map · Hub