NRF — NF Repository Function in 5G NR
The service registry of the SBA — every NF registers its services and discovers others (including slice-specific instances) through the NRF.
Every network function in the 5G core needs to answer one question constantly: "given what I need right now, which instance of which peer do I call, and am I even allowed to call it?" The NRF is the one function whose entire job is to answer that. It is the phone book, the front-desk registry and the ticket office of the Service-Based Architecture rolled into one — the place every other NF checks in with, looks others up in, and collects its access passes from.
Introduction
The NF Repository Function, the NRF, is the service registry and discovery service of the 5G core's Service-Based Architecture (SBA). It is itself a control-plane network function, defined in TS 23.501 and detailed in the stage-3 API specification TS 29.510, and it is the connective tissue that lets a set of independently deployed, dynamically scaled network functions find and trust one another at runtime.
You meet the NRF at three moments in every other NF's life. When an NF instance starts up, its very first act is to register itself with the NRF. Throughout its life it heartbeats the NRF to prove it is still alive. And whenever it needs a peer — an AMF needing an SMF, an SMF needing a PCF or UDM — it discovers that peer through the NRF and collects an access token from it before calling. Almost every interaction in the core therefore begins with a trip through the NRF.
What makes it worth studying is that it is where 5G's cloud-native design is most visible. There are no hard-wired peer addresses as there were in earlier cores; instead there is a live catalogue and an authorization server. Understand the NRF's three jobs — register, discover, authorize — and the rest of SBA falls into place.
On this page
Why the NRF is needed
In plain words: think of a large office building full of contractors who come and go. Instead of everyone memorising each other's desk numbers, there is a front desk. Every contractor signs in when they arrive and periodically waves to show they are still around; when you need "an electrician on the third floor" you ask the front desk, which hands you the right person's location; and before you can actually enter their room, the desk gives you a visitor badge that proves you were cleared. The NRF is that front desk — sign-in book, directory and badge office in one.
The concrete purpose is to make a dynamic set of network functions workable. In SBA an NF is a software service that can be spun up, scaled out, upgraded or torn down at runtime, and different vendors' implementations may come and go — so the set of instances that exists at any moment is fluid. Static configuration cannot track that: you cannot hard-code the address of "the SMF" when there may be three of them one minute and seven the next. The NRF solves this by being a single, always-current source of truth for what is running, where, serving which slices, and who is permitted to call whom — so consumers find producers at runtime and producers advertise themselves the moment they come up.
The NRF as the backbone of the Service-Based Architecture
In the 5G core, control-plane functions are not wired together with fixed cables. An AMF does not have a hard-coded address for "the SMF" the way an LTE MME had a configured S-GW. Instead every NF is a software service that can be spun up, scaled out, upgraded or torn down at runtime — which means the set of instances that exists at any moment is fluid. Something has to keep an up-to-date map of what is running, where it lives, and what it can do. That something is the NF Repository Function, the NRF.
The NRF is the 5GC's service registry and discovery service. It holds a live catalogue of every registered NF instance — its type, the slices it serves, the services it offers and the endpoints to reach them — and it hands out the OAuth2 tokens that authorize one NF to call another.
Because SBA is dynamic. Instances appear and disappear, scale horizontally and get replaced by other vendors' implementations. Static configuration cannot track that. A central registry lets consumers find producers at runtime, and lets producers advertise themselves the moment they come up.
NFs register a profile with the NRF, keep it alive with heartbeats, discover peers by querying it, and request access tokens from it before calling those peers. Three service operations, one function, defined in TS 23.501 and detailed in TS 29.510.
Think of the NRF as a microservices service-discovery component (Consul or Eureka) combined with an OAuth2 authorization server — an analogy 3GPP intended, having modelled the 5GC control plane on cloud-native patterns. Get the NRF straight and the rest of SBA falls into place, because almost every interaction in the core begins with a trip through it.
One function, three jobs: the NRF is (1) the registry NFs check into, (2) the directory they look each other up in, and (3) the authorization server that issues access tokens. Everything else in SBA leans on those three.
SBA context: producers, consumers and HTTP/2
To see where the NRF fits, hold the SBA model in mind. Each control-plane NF plays two roles depending on the interaction: it is a service producer when it exposes operations for others to call, and a service consumer when it calls someone else's. The SMF produces the Nsmf_PDUSession service; the AMF consumes it when setting up a session. Moments later the roles flip for a different exchange. There is no fixed client/server hierarchy — just producers and consumers, transaction by transaction.
All of these interactions ride the same transport: HTTP/2 with JSON payloads, structured as RESTful APIs over a service-based interface (SBI). A producer advertises operations at well-known resource URIs; a consumer issues ordinary HTTP requests against them. That uniformity is what makes a single registry viable — because every NF speaks the same web protocol, the NRF only has to store and return endpoint metadata (API root URI, IP or FQDN, port, service names) and any consumer turns that straight into a call.
The NRF itself is just another producer on this bus; its interface is Nnrf. The bootstrap problem — how an NF finds the NRF before it can discover anything else — is solved out of band: the NRF's address is locally configured or resolved via DNS. Once an NF knows where the NRF is, it finds everything else through it.
Producer vs consumer is per-transaction. The same SMF is a producer toward the AMF (offering Nsmf_PDUSession) and a consumer toward the PCF and UDM. The NRF does not care about the roles — it just tracks who is running and who is allowed to call whom.
NF registration and the NFProfile
When an NF instance starts, its first act in the core is to register with the NRF by sending its NFProfile — a structured JSON document that describes everything a would-be consumer needs to know about it. Registration is a PUT of the profile to the NRF; the NRF stores it and marks the instance REGISTERED. From that moment the instance is discoverable. When the NF changes — scales its capacity, adds a service, changes load — it updates the profile; when it shuts down cleanly it deregisters.
The NFProfile is the heart of the whole mechanism, so it is worth knowing its key fields. These are the same fields a consumer later filters on during discovery, so registration and discovery are really two sides of one data model.
| NFProfile field | Meaning |
|---|---|
nfInstanceId | Globally unique identifier (a UUID) for this NF instance. The primary key by which the NRF tracks and addresses the registration. |
nfType | The kind of NF — AMF, SMF, UPF, PCF, UDM, and so on. The coarsest discovery filter ("find me an SMF"). |
nfStatus | Operational state: REGISTERED, SUSPENDED or UNDISCOVERABLE. Controls whether the instance is returned to discoverers. |
plmnList | The PLMN(s) — mobile network(s) by MCC/MNC — this instance serves. Central to roaming, where home and visited PLMNs must be distinguished. |
sNssais | The list of network slices (S-NSSAI values) the instance supports. The field that makes discovery slice-aware. |
nfServices / nfServiceList | The services this NF produces, each with a service name (e.g. nsmf-pdusession), version, supported schemes and its own endpoint list. |
ipEndPoint / fqdn | The reachable addresses — FQDN, IPv4/IPv6 addresses, transport and port — a consumer uses to actually send requests to the service. |
capacity / load | Static relative capacity and dynamic current load. Consumers (or the NRF) use these to spread traffic across equivalent instances. |
priority | Relative selection priority among candidate instances, letting an operator prefer some instances over others. |
allowedNfTypes / allowedPlmns | Authorization hints declaring which NF types or PLMNs may consume this instance — used to scope discovery and access. |
Once registered, an NF must prove it is still alive. It does this with a periodic heartbeat — an NFUpdate (a PATCH of the profile, often just refreshing nfStatus/load) sent at the interval the NRF specifies via heartBeatTimer. If the NRF stops hearing heartbeats, it assumes the instance has failed and marks it SUSPENDED or removes it, so it stops handing that dead endpoint to consumers. This is exactly how the registry stays truthful in the face of crashes: liveness is asserted continuously, not assumed once at startup.
Spec pointer: the Nnrf_NFManagement service — register, update, deregister, heartbeat and status-subscription operations — is defined in TS 29.510, with the SBA framework and NFProfile concepts introduced in TS 23.501.
NF discovery and selection assistance
Discovery is the operation everyone pictures when they think of the NRF. A consumer that needs a peer sends a query and gets back a list of matching NF instances with everything needed to call them. The classic example: an AMF has just accepted a UE's PDU-session request and needs an SMF to handle it. It does not know which SMF instances exist right now, so it asks the NRF: find me an SMF that serves this S-NSSAI and this DNN, in this PLMN.
Mechanically this is a GET to the NRF's nf-instances resource with query parameters: target-nf-type=SMF, requester-nf-type=AMF, plus filters such as snssais, dnn and plmn. The NRF matches those against stored NFProfiles and returns candidates — each with nfInstanceId, endpoints, services, capacity, load and priority — cacheable via validityPeriod so the consumer need not re-query per transaction.
Two refinements make this powerful. First, slice-awareness: because S-NSSAI is a first-class filter and every producer advertises its sNssais, discovery returns only instances in the right slice — a URLLC slice and an eMBB slice can run entirely different SMF/UPF instances, kept apart automatically. Second, selection assistance: by including priority, capacity and current load in each candidate, the NRF hands the consumer the material to load-balance and prefer instances. The final pick is the consumer's, but an informed one.
NRF lifecycle: producers register and heartbeat; a consumer discovers a producer and obtains an access token; then it calls the producer directly, with the NRF off the data path.The crucial thing the diagram shows is that the NRF is a broker, not a proxy. It tells the AMF where the SMF is and confirms it is allowed to call it, but the actual Nsmf_PDUSession request flows straight from AMF to SMF. The NRF never sits on the working path of a transaction, which is exactly why one registry can serve a very large core without becoming a bottleneck.
OAuth2 access-token authorization
Discovery answers "where is it?" — but SBA also needs to answer "am I allowed to call it?". Because SBIs are ordinary HTTP/2 APIs, 3GPP secures NF-to-NF authorization with a mainstream web mechanism: OAuth2, with the NRF acting as the authorization server. This is the third face of the NRF, exposed as the Nnrf_AccessToken service.
The flow is the OAuth2 client-credentials grant. Before calling a producer, the consumer requests a token from the NRF, presenting its identity and the service it wants (requester nfInstanceId, the targetNfType/service, often target S-NSSAI and PLMN). The NRF validates the entitlement and returns a signed JSON Web Token — the access_token. The consumer attaches it in the HTTP Authorization: Bearer header of its service request; the producer validates the token's signature and claims (audience, scope, expiry) and serves only if it checks out.
A signed, short-lived JWT that proves a specific consumer NF is authorized to invoke a specific producer service, issued by the NRF as OAuth2 authorization server.
On an open HTTP/2 bus you cannot trust the network alone. Tokens give producers a cryptographic way to reject calls from NFs that were never authorized — vital in roaming, where a visited network's NFs must be gated.
Consumer requests a token via Nnrf_AccessToken, receives a bearer JWT, and includes it on every call until it expires; the producer verifies it locally without calling back to the NRF.
Note that the producer verifies the token locally using the NRF's signing key — it does not phone the NRF on every request. That keeps the authorization check off the hot path just as discovery caching does, so security scales alongside the rest of the architecture.
The Nnrf service interface
Everything above is delivered through a single service-based interface, Nnrf, which the specifications break into three named services. Knowing which operation belongs to which service is a common interview checkpoint, and it maps cleanly onto the three jobs discussed so far.
| Service | Purpose | Key operations |
|---|---|---|
Nnrf_NFManagement | Lifecycle of NF registrations: register, keep alive, update, remove, and let others subscribe to status changes. | NFRegister, NFUpdate (incl. heartbeat), NFDeregister, NFStatusSubscribe / NFStatusNotify |
Nnrf_NFDiscovery | Let a consumer find producer instances matching its needs (type, slice, DNN, PLMN), with selection metadata. | NFDiscover (a filtered GET returning candidate NFProfiles) |
Nnrf_AccessToken | Issue OAuth2 access tokens so a consumer can prove it is authorized to invoke a producer's service. | AccessToken_Get (OAuth2 client-credentials token request) |
The symmetry is the point: Nnrf_NFManagement is how producers make themselves known, Nnrf_NFDiscovery is how consumers find them, and Nnrf_AccessToken is how the two are permitted to interact. Management also offers a subscribe/notify pattern so a consumer can be told when a producer's status changes rather than polling — useful for an AMF that wants to know the instant an SMF it uses goes down.
Hierarchical NRFs and roaming
A single logical NRF is the mental model, but real deployments distribute the function. NRFs can be organized hierarchically and by scope: there may be a PLMN-level NRF, shared-slice NRFs and slice-instance-specific NRFs, so that a discovery query can be delegated up or across when the local registry does not hold the answer. An NRF that cannot satisfy a query itself can forward or redirect it to another NRF that can, which keeps each registry's scope manageable while still presenting a coherent directory.
Roaming is where this becomes essential. When a UE roams, its serving (visited) network and its home network each run their own NRF. Discovery that must cross the boundary — for example a visited SMF needing to reach the home UDM — is brokered between the two: the visited NRF (vNRF) forwards the request to the home NRF (hNRF), which returns home-network producers, typically reached through the SEPP at the network edge. The two NRFs each own their own PLMN's registrations, and the plmnList field in every NFProfile is what lets each one keep home and visited instances straight.
| Scenario | Which NRF answers |
|---|---|
| Non-roaming discovery | The single serving-PLMN NRF handles the query end to end. |
| Roaming, home producer needed | vNRF forwards to hNRF; home instances returned, reached via the SEPP. |
| Slice-scoped discovery | A slice-specific NRF may be consulted; a higher-level NRF delegates to it. |
Home vs visited: in roaming there is no single global registry. The vNRF knows the visited network; the hNRF knows the home network; cross-PLMN discovery is a controlled hand-off between them, with the SEPP guarding the interconnect.
LTE ↔ NR: LTE's EPC had no registry like the NRF. Peer selection was done with statically provisioned peers and DNS/DIAMETER routing — an MME found an S-GW/P-GW largely through DNS APN/TAI resolution, and Diameter agents (DRA) routed signalling. The NRF replaces that patchwork with a single runtime registry plus OAuth2 authorization, which is only possible because SBA put every NF on the same HTTP/2 RESTful bus.
Summary
The NRF is the service registry, discovery service and authorization server of the 5G SBA, specified in TS 23.501 and TS 29.510. It does three jobs through one interface, Nnrf: registration and liveness (Nnrf_NFManagement — an NF PUTs its NFProfile, is marked REGISTERED, and heartbeats via NFUpdate); discovery (Nnrf_NFDiscovery — a filtered GET by nfType, sNssais, dnn and plmn that returns candidate profiles with priority/capacity/load); and authorization (Nnrf_AccessToken — an OAuth2 client-credentials grant issuing a signed bearer JWT).
The two ideas to keep are that the NFProfile is one data model used both to advertise and to filter, and that the NRF is a broker, not a proxy — it tells a consumer where a producer is and confirms it may call, but the actual service request goes consumer→producer directly, and tokens are verified locally, keeping the NRF off the hot path. In roaming, the vNRF and hNRF each own their PLMN and hand off cross-boundary discovery through the SEPP. Unlike LTE, which had no such registry, the NRF is what makes a fluid, cloud-native core coherent.
Quick Q&A
The questions that separate reciting "it's the registry" from actually understanding how the NRF holds SBA together.
Q. What exactly does an NF send to the NRF when it starts, and what happens next?
A. It registers by sending its NFProfile (via Nnrf_NFManagement NFRegister) containing nfType, plmnList, supported sNssais, nfServices, endpoints and capacity. The NRF stores it, marks the instance REGISTERED, and thereafter expects periodic heartbeats (NFUpdate) to confirm it is still alive.
Q. How does an AMF find an SMF for a particular slice and DNN?
A. It calls Nnrf_NFDiscovery NFDiscover with target-nf-type=SMF plus snssais and dnn filters. The NRF matches these against registered NFProfiles and returns candidate instances with endpoints, priority, capacity and load, from which the AMF selects one and calls it directly.
Q. Is the NRF on the path of the AMF-to-SMF service call?
A. No. The NRF is a broker: it returns the producer's location and issues the access token, but the Nsmf_PDUSession request flows straight from AMF to SMF. Keeping the NRF off the working path is what lets it scale.
Q. What role does OAuth2 play, and who is the authorization server?
A. It authorizes NF-to-NF service access. The NRF is the OAuth2 authorization server: via Nnrf_AccessToken it issues a signed bearer JWT that the consumer attaches to its request; the producer verifies the token locally before serving. This gates calls on the open HTTP/2 bus.
Q. How does NRF-based discovery work when a UE is roaming?
A. The visited network's vNRF and the home network's hNRF each own their PLMN's registrations. Cross-PLMN discovery is forwarded from vNRF to hNRF, and home producers are reached through the SEPP. The plmnList in each NFProfile keeps home and visited instances distinct.
Q. Which three services make up Nnrf, and what does each do?
A. Nnrf_NFManagement (register, heartbeat/update, deregister, status subscribe), Nnrf_NFDiscovery (find matching producer instances), and Nnrf_AccessToken (issue OAuth2 tokens). They correspond to registering, finding, and being permitted to call.
Where to go next
You now know how NFs announce themselves, find each other and prove they are allowed to talk — the connective tissue of the whole control plane. Next, watch a real consumer put the NRF to work, or go deeper on the slicing identifiers and secure interconnect that discovery depends on: