6 How one function finds another

6.1 Why anything has to be found at all

A 5G core is not a fixed set of boxes with fixed addresses. There are many instances of each function, they are placed in different data centres, they are scaled up and down, and some of them exist only for one network slice.

On top of that, most of them are not interchangeable: the function holding one subscriber's data is not the one holding another's.

So a core function that wants a service has two questions to answer, and they are different questions. First: which instances out there could do this at all? Second: which one of them should serve this particular request, right now?

Clause 6.3 answers both. The first is discovery and it goes through the NRF — the directory that every core function registers with — unless the answer is already configured locally §6.3.1. The second is selection, and it is different for every kind of function, which is why §6.3 is so long.

6.2 Register, discover, select, then talk

The whole shape is four steps:

• R1 Register. An instance sends one message to the NRF carrying its NF profile, typically when it first comes into service §6.3.1.

• R2 Discover. A requester asks the NRF for a function type, optionally naming the services it wants, plus narrowing parameters such as slice information §6.3.1.

• R3 Select. From the profiles that come back, the requester picks one instance, and one service instance inside it §6.3.1.

• R4 Talk. It sends the service request to the endpoint address it now has.

The important detail is in step R2. The NRF's answer is not personal. It matches the criteria you sent, so it is good for any subscriber that fits the same criteria, and it comes with a validity period saying how long you may cache it §6.3.1.

Instead of polling, a requester can subscribe to the NRF and be told when a profile changes or an instance comes and goes §6.3.1.

6.3 What is in an NF profile

The profile is what makes a function findable, and it is more than an address. The entries fall into a handful of kinds §6.2.6.2:

• Who it is — instance ID, function type, the network it belongs to, and for a private network the network identifier as well.

• How to reach it — an address or name for the function, plus a separate endpoint address for each service instance it offers.

• How much it can take — capacity, priority and current load.

• What it belongs to — NF Set ID and NF Service Set ID. An NF Set is a group of instances of the same function that stand in for one another, which is what makes failover possible.

• How far it reaches — location or serving scope, and lists of tracking areas (a tracking area is a group of cells the network treats as one place).

• What it is good for — the names of the services it supports, plus keys that only make sense for one function type: the AMF registers its GUAMIs, the UDM and AUSF register a Routing Indicator, several types register a group ID and ranges of subscriber identities.

A profile may also carry energy-related attributes, so that a consumer can take power into account when choosing §5.51.7. The SCP — a message router that sits between core functions — has a profile of its own shape §6.2.6.3.

6.4 Who does the choosing

There are three arrangements, and they differ in how much work the requester keeps §6.3.1. The message paths themselves are drawn in §Annex E.

• Direct. The requester discovers, selects the instance and the service instance, and sends the request itself.

• Indirect, without delegated discovery. The requester still discovers and picks the instance; the SCP may pick the service instance and does the routing.

• Indirect, with delegated discovery. The requester skips the NRF entirely and attaches its discovery and selection parameters to the request. The SCP queries the NRF, picks, and forwards §6.3.1.1.

Across network boundaries the pattern repeats one level up: the local NRF forms a query aimed at the other network's NRF, using the PLMN identity the requester supplied, and gets profiles back that way §6.3.1.

Hiding what your network looks like from the other side is a separate matter, handled by the SEPP §6.2.17.

6.5 Coming back to the same instance

Discovery gets you to a function. Staying with it matters just as much, because a resource created inside a producer — a session context, a subscription — lives somewhere specific.

That is what a binding indication is for. The producer tells the consumer how tightly it is bound, and the level of the binding is exactly the width of the allowed reselection §6.3.1.0:

Binding level	You select	If that fails you may go to
NF Service Instance	that one service instance	an equivalent one in the service set, the instance, or the NF Set
NF Service Set	any service instance in that service set	an equivalent service set inside the NF Set
NF Instance	any equivalent service instance in that instance	a different instance inside the NF Set
NF Set	any equivalent service instance in that NF Set	anywhere inside the same NF Set

When an SCP is in the path, the same information travels in the message as a routing binding indication, so the router can honour it. If a recipient gave you a binding indication once, later related requests have to carry it §6.3.1.1.

Bindings run both ways: a consumer gives one too, so that notifications can find it again if its endpoint has moved §6.3.1.0.

6.6 Choosing an AMF

The AMF keeps track of where a device is and whether it is reachable, so choosing it is the first choice made about a device, and it is made twice over.

The radio side chooses first. A base station picks an AMF Set — the group of AMFs that can serve in each other's place — and then an AMF inside it.

It does this when the device gave no temporary identity, when the identity it gave does not point anywhere usable, when the AMF has announced itself unavailable or has failed, or when the identity points at an AMF serving a different country from where the device now is §6.3.5.

To pick the set it uses region and set identifiers from the temporary identity, the slices the device asked for, operator policy, and hints from radio signalling about the kind of device: small-device optimisations, narrowband radio, reduced-capability radio, relay and onboarding indications §6.3.5.

To pick a member of the set it uses only availability and load balancing across weight factors §6.3.5.

The core side chooses later. Another function that has lost its AMF asks the NRF using the GUAMI — the AMF's name inside the device's temporary identity — or a tracking area.

If that AMF is being taken out of service on purpose, the NRF hands back the profile of the backup registered for planned removal; if it failed, the backup registered for failure; if neither exists, candidates from the same AMF Set §6.3.5.

During mobility the search runs on set, region, the target location and the allowed slices; across networks, the source NRF reaches the target network's NRF §6.3.5. Slice-driven AMF choice is set out separately in §5.15.5.2.1.

6.7 Choosing an SMF

The SMF sets up and runs one data connection. The AMF chooses it, or hands the parameters to an SCP to choose §6.3.2. The inputs are a long list; what matters is the five kinds they fall into.

• What the connection is — the data network name, the slice, the access technology in use, whether it has to survive a move to 4G.

• Where the user is — the tracking area, matched against the service area or preferred locality of each candidate.

• What the subscription permits — read from the UDM, per data network and per slice: may this be handled in the visited network, is 4G interworking supported, must every session to this pair use one and the same SMF.

• How busy the candidates are — reported load, and load predictions from the analytics function if one is deployed.

• What each candidate can do — multi-access sessions, small-device optimisations, remote provisioning during onboarding, the local exit points it supports.

The full list is in §6.3.2, and two of its consequences are worth carrying around.

The first is stickiness: if the subscription says 4G interworking is supported for this data network and slice, or that one SMF must serve them all, a second session must go to the same SMF.

When neither applies a different one may be chosen, which is how load spreading and graceful shutdown happen at all §6.3.2.

The second is roaming. Home-routed traffic needs two: an SMF in the visited network chosen on the visited slice, and one in the home network chosen on the home slice.

Afterwards the AMF fetches the visited SMF's service area from the NRF, so it knows later whether the device has moved out from under it §6.3.2. Emergency sessions follow the same function with an emergency data network name, or bypass it using configured data §5.16.4.5.

6.8 Choosing a UPF

The UPF is the box the user's packets actually pass through, and choosing it is two separate jobs §6.3.3.1.

Which UPFs exist at all. The SMF may be configured with them, or learn about one when that UPF opens an N4 association, or ask the NRF using data network name, slice, an SMF Area Identity and required capabilities §6.3.3.2. The SMF Area Identity is a fence: it limits an SMF to the UPFs it is allowed to control.

Which one for this session. The inputs group into topology (where the radio's user-plane termination sits, where the local exit points are, which paths exist between UPFs) and load (dynamic load, relative static capacity, analytics).

Then the shape of the session: data network, slice, session type, continuity mode, a fixed address if there is one.

Last come capability matching and plain delay figures — measured or configured, both towards the data network and towards the radio §6.3.3.3. Energy attributes can be weighed in as well §6.3.3.3.

Stickiness appears again: another session to the same data network and slice should reuse the same UPF when 4G interworking applies and that UPF can still do everything the new session needs §6.3.3.3.

6.9 Choosing a PCF

The PCF decides the rules — what a subscriber may do and at what quality. Two PCF choices happen, and they are independent.

The AMF picks a PCF for the device, and the same instance then serves both the access-and-mobility policy and the device policy §6.3.7.1. The SMF picks a PCF for the session. The two may land on the same instance or not §6.3.7.1.

The inputs are subscriber-shaped rather than location-shaped: the subscriber identity or the range it falls in, the group ID, the slice, a set identifier, and capability flags such as being able to replace a data network name or a slice §6.3.7.1.

The UDM can also hand the AMF a list of PCFs already serving established sessions, together with the data network and slice each one covers, so the same PCF is reused. When the AMF passes its PCF on to the SMF with a "same PCF" indication, the SMF has no choice left §6.3.7.1.

The reason all this care exists is stated first, before any mechanism: a PCF has to be able to tie an application's request coming in from outside to the right session, and a session has to be uniquely identifiable from the subscriber and the data network, or from the address and the data network §6.3.7.0.

Requests that apply to many devices at once do not use discovery at all. They are validated by the NEF, stored in the UDR, and every PCF that cares subscribes to the UDR for changes §6.3.7.2.

6.10 The rest, briefly

AUSF and UDM are found by home-network identity: the Routing Indicator the device carries in its concealed identity, a group ID, or the range its permanent identity falls in §6.3.4 §6.3.8. The UDM can also be found from an external identity, which is how functions that never see a permanent identity reach it.

UDR deployments are segmented, so the consumer must land on the instance holding the right data set — subscription data, policy data, exposure data §6.3.9.

CHF, which handles charging, is unusual: its address may come from the UDR as part of subscription data, from local configuration, or from the NRF, and what the UDR says wins over the other two §6.3.11.

NEF is the door for outside applications, so it is also found from outside: an untrusted application resolves it by DNS from an external identity, while a trusted one may ask the NRF §6.3.14. Local instances are chosen by nearness.

SCP is configured, not discovered: every function knows its own SCPs, and an SCP finds its next hop from the NRF or from configuration §6.3.16.

NRF and NSSF have the bootstrap problem — you cannot look up the thing you look things up with. The answers are configured addresses, a configured discovery service, a version-independent bootstrapping service, or asking the slice selection function which NRF serves a given slice §6.3.26 §6.3.28.

The analytics family — NWDAF, DCCF, ADRF, MFAF — is chosen on a serving area expressed as a list of tracking areas, plus what each one is trained or built to handle §6.3.13 §6.3.19 §6.3.21.

Nearness cases — EASDF for DNS near the edge, NSACF for slice admission counting, TSCTSF for time synchronisation — each add one narrow key of their own on top of slice and data network §6.3.23 §6.3.22 §6.3.24.

And the ones the device decides. Picking a gateway for untrusted Wi-Fi, or picking a trusted non-3GPP access network at all, is done by the phone from configuration it was given and from what the access network advertises. No NRF is involved §6.3.6 §6.3.12.

6.11 Where this sits in the system

Discovery only makes sense because functions are services with names, which is Services instead of interfaces. What each function does, and the NRF's own description, are in What each network function does.

The identities that do the narrowing — slice names, subscriber identities, the GUAMI — are collected in Every name the system uses.

The choices themselves show up as steps inside Registration, reachability and paging and The connection to a data network, are constrained by One network, many networks, are doubled up by Being served by somebody else's network, and decide the shape of Where the packets actually go and Rules, and paying for them.