NF Set ID and NF Region ID: what they are actually for
The 5G core gives every network function four different identifiers. Here is what each one is for, and why Set and Region exist at all.
A 5G network function carries more identifiers than most engineers expect. There is the NF Instance ID, the NF Set ID, sometimes an NF Region, and an FQDN on top of all of it. It looks redundant until you try to make a core survive an instance failure.
NF Instance ID
The NF Instance ID is a UUID. It identifies exactly one running instance of a network function, globally and unambiguously, for as long as that instance exists. When an AMF registers with the NRF, this is the primary key of its profile. Nothing else identifies the instance itself.
If the instance restarts with a fresh identity, it is a new instance as far as the NRF and every peer is concerned. That is the point - it is deliberately narrow.
NF Set ID
Here is the problem the Instance ID cannot solve. A UE is registered on AMF-1. AMF-1 dies. The UE's context - its security keys, its registration state, its active PDU sessions - was held by AMF-1. If nothing else knows about that context, the UE has to register again from scratch, and so does every other UE on that AMF.
An NF Set is a group of NF instances that are interchangeable for exactly this reason. Members of a set share access to the same context, usually through a shared storage layer such as the UDSF, so any member can take over a UE from any other. The NF Set ID names that group.
So when an SMF wants to reach the AMF serving a UE, it does not have to hold the specific instance. It can address the set, and any healthy member answers. This is what makes stateless-ish 5G network functions work in practice rather than in slideware.
The format is structured rather than a UUID:
set<Set ID>.<nftype>set.5gc.mnc<MNC>.mcc<MCC>
NF Region ID
Region groups sets geographically. A large operator does not run one flat pool of AMFs across a country; it runs regional pools, and traffic should stay inside its region unless something has gone wrong. The Region ID lets discovery and selection prefer local instances, and lets you reason about failover domains that match your actual data centre topology.
You will not see it in every deployment. Small cores and private networks often skip it entirely, because with two data centres there is nothing to region.
NF FQDN
The FQDN is the addressable name. Instance, Set and Region are identity; the FQDN is how you actually open a connection. In a well-built core the FQDN resolves through DNS to whichever instances are currently healthy, which is why the FQDN and the Set ID are usually aligned.
Putting it together
Think of it as four questions:
- Which running process is this? NF Instance ID
- Who else can do this job for the same UE? NF Set ID
- Where in the network is this pool? NF Region ID
- How do I connect to it? NF FQDN
Miss the Set ID and your core is a collection of single points of failure with a service based interface bolted on. That is the whole reason it exists.