The Network Repository Function, or NRF, is a key element of the 5G core. It essentially acts as an index that can be consulted by other NFs, so they can discover information regarding other entities present in the core, as well as service capabilities that may be required. Our emulation function enables NF registration and discovery functions to be validated – supporting multi-vendor environments.

An index of network functions

The new standalone 5G core is designed to support new classes of highly differentiated, dynamic services. Many such services will require interaction with multiple functional entities within the service-based architecture (SBA) and, because of the potential dynamic, volatile nature of such services, the entities involved may change during a session.

As such, we need to know what entities and resources – the Network Functions – are available for the delivery of any given service. Similarly, the service elements need to be aware of the entities that may be required to participate in a session. A service request may need to be checked against user or device profiles so that access can be authenticated, and specific capabilities requested; it may need different resources (even at different times), and so on. There may be multiple UPFs, for example – which one is required and how can it be accessed? Is it available, or should an alternative be used?

All of this, of course, requires complex orchestration. To support this dynamic environment, you need something that can act as a central registry, holding information about every NF, which can then be shared with any NF, when required. Enter the Network Repository Function, or NRF.

This acts as a sort of index, which can be interrogated by any of the connected NFs (AMF, SMF, PCF and so on), to provide the information they need to discover the NFs that are needed to support the service in question. The relationship of the NRF to the other elements of the 5G core is shown in Figure 1.

Figure 1: 5GC reference architecture[1]

So, that’s fine in principle. Let’s look at the specific functions of the NRF. It basically fulfils four key tasks:

1. Network function management;
2. Network function discovery;
3. Authorisation; and
4. Bootstrapping.

Network Function management

This enables each NF to register with the NRF. So, any NF available for service delivery can be listed in the centralised resource – but, even more importantly, each NF can subscribe to notifications from the NRF. As a result, each registered NF can be notified of any changes to any other NF – or when others are added or removed. This also extends to some other elements, such as the SEPP (required for roaming), or SCPs.

Network function discovery

Each registered NF can also interrogate the NRF to discover other NF and the services they offer. Again, this is important for understanding capabilities. But such requests can also be made via the NRF to other NRFs in different networks – so, enabling services to be delivered to roaming users, which such arrangements have been put in place. It’s early days, but this could enable a host of new, cross-border and inter-network functions and services.

Authorisation

Not just any entity can request information from the NRF. Network security and integrity must be respected at all times. Consequently, there are strict authorisation processes in place. Several different RFCs (e.g., 3986, 6749 and 7519) have been adopted for this purpose, but the basic principles are based on the request for, and exchange of, tokens.

For example, there is a service request (which must be authenticated), while the token itself is similarly protected. Encoding is required, and tokens can be valid for limited periods. Where there are multiple NRFs to consider (for example, when requesting information from another network), security is maintained across the complete chain. The upshot is that there is a secure mechanism that ensures that only authorised entities can interact with the NRF and obtain the information they need.

Bootstrapping

Finally, there is also a ‘Bootstrapping’ service, which enables an NRF to notify associated NFs of service endpoints that are supported. This process can be used when information needs to be shared between different mobile networks, as well as within the same network, to avoid storing data in individual NFs.

How do we help?

Clearly, any NF must be capable of interacting successfully with the NRF. It must be able to support all necessary procedures, together with the required security protocols. In multi-vendor networks, there may be different NFs from different suppliers, so these must be tested appropriately, to ensure that they can registered with the NRF and, in turn, that they can discover other NFs that may be deployed.

To assist with this process, we delivered an NRF emulator, which handles core functionality, according to the 29.510. This enables solution vendors and MNOs to launch test environments with NRF emulation, so that correct registration can be validated, followed by the evaluation of specific functionality. This can be achieved at scale and with multiple NFs, so that the desired multi-vendor environment can be enabled.

To find out more, This email address is being protected from spambots. You need JavaScript enabled to view it. – or read on, here.

[1] 3GPP TS 29.510 V17.5.0