The Network Repository Function (NRF) maintains a registry of Network Function (NF) and Service Communication Proxy (SCP) profiles, with associated operational status. This enables any service consumer in the 5GC, which may be an NF or an SCP, to discover the producers of particular services and features in the network. In order to accomplish this the NRF collects information about the available NFs and SCPs as they register their capabilities and report their operational status. NF service consumers may subscribe to notification of newly registered or de-registered entities and status change notifications. NRFs also provide a bootstrapping service that delivers their service endpoint URLs upon request, and can provide OAuth2 credentials upon request.
NRFs may by deployed in a hierarchical structure in a complex network. One NRF may serve the entire PLMN, a set of network slices, or a single network slice. In the latter cases an NRF hierarchy allows service consumers to discover the NRF for a network slice, for example, by querying the PLMN-level NRF. In addition, NRFs in different PLMNs — the H-NRF and V-NRF — can communicate with each other, enabling NFs in the visited network to discover NFs in the home network. They communicate over the N27 interface, which is the only reference point defined for Nnrf services since they are so ubiquitous.
When NRF services are deployed, NF instances and SCPs register their identities, location, network slice(s) served, service instances and operational status, as well as any other information required by the network operator, with a local NRF. Network entities typically register when they become operative and de-register when they cease to be. As mentioned above, any NF or SCP may subscribe to availability and profile change notifications regarding any NF while SCPs may also subscribe to notifications regarding other SCPs.
dsTest’s NRF emulator and emulated Nnrf_NFManagement clients support the following service operations.
Repository Management Service Operations
NF service consumers must only invoke these operations towards an NRF in the same PLMN.
- NFRegister, NFDeregister — An NF or SCP uses these operations to register their profiles with an NRF or to remove their profiles from an NRF. The profile includes its identity, location, and slice information along with information about the services it exposes, including their operational status. These operations will trigger status notifications towards the affected subscribers.
- NFUpdate — When any of its profile information changes, including the status of the network entity or any of the services it exposes, a registered NF instance or SCP uses this operation to update the information stored by the NRF. NFs may also add or remove a service exposed during an update. This operation may trigger the NRF to generate status notifications towards any subscribed network entities.
- NFListRetrieval — Provides, upon request, a list of NFs and SCPs currently registered with the target NRF that meet the criteria supplied by the requestor.
- NFProfileRetrieval — Enables an NF or SCP to retrieve the profile of a particular NF or SCP instance.
Status Change Subscriptions and Notifications
- NFStatusSubscribe, NFStatusUnsubscribe — NFs and SCPs may use these operations to subscribe to or unsubscribe from status change notifications for an individual NF, a set of NFs, NFs of a particular type, NFs that offer a particular service in a PLMN or network slice, or NFs that serve a particular location. SCPs may also use this operation to subscribe to status change notifications for other SCPs. An NF from another PLMN may invoke this operation via its local NRF, but a foreign SCP may not.
- NFStatusNotify — NRFs use this operation to generate status change notifications towards subscribed NF instances or SCPs when subscribed conditions are met. NRFs may send notifications directly to NF instances in another PLMN without the involvement of the foreign NRF.
In order to enable the flexibility of the 5G Core Network and its ability to spin up new network slices on demand, NF and SCP instances must be able to dynamically discover NFs and the services they offer, and SCPs must be able to discover other SCPs. The Nnrf_NFDiscovery service provides that capability, both within a PLMN and between PLMNs, through the NFDiscover service operation. The NF service consumer queries a local NRF, providing the criteria for NF selection, and the NRF returns the profiles of the NFs that satisfy the criteria given. When a consumer in the V-PLMN attempts to discover an NF in the H-PLMN, the local NRF will communicate with the PLMN-level NRF in the H-PLMN. SCPs may only discover SCPs in the local network.
The selection criteria for NF discovery, in addition to service instances exposed, may include network slice, location, data network name supported, membership in a group or set, and many other criteria.
The NRF offers an Nnrf_AccessToken service, used for OAuth2 authorization, following the Client Credentials authorization grant as specified in TS 33.501. It exposes a Token Endpoint where the Access Token Request service can be requested by NF Service Consumers using the Get operation.
NFs and SCPs discover the services supported by an NRF and the associated endpoints through its Nnrf_Bootstrapping service. A common, version-independent URI endpoint – /bootstrapping – is supported by any NRF that produces this service. When a network entity requests bootstrapping information through the Get operation, an NRF includes in the body of the response message the URLs for all of the services it supports. This service may be used within a PLMN and between NRFs in different PLMNs.
Use our NRF emulator in your test network to provide Nnrf_NFManagement and Nnrf_Discovery services in your lab while also verifying NF service consumer compliance with service APIs.
Test your NRF by surrounding it with our Nnrf client node emulators:
- Configure the node emulators to register their profiles when they start and deregister before they stop.
- Send profile changes while nodes are active.
- Subscribe to and unsubscribe from notifications from the NRF.
- Invoke the NFDiscover operation with a search action.
As with all dsTest products, the node configurations and test scenarios are easily defined and configured with XML files that are validated against a published XML Schema to avoid invalid definitions. With our dsClient Desktop application you can create, run, and archive tests; capture, graph and archive operational measurements; capture real-time data flows and subscriber events; and manage your dsTest platforms and testing scenarios with a standalone application that runs on your PC.
Advanced Testing Features
SmartEvents — Alter application behavior or coordinate multiple interface applications with SmartEvents — our programmable, subscriber-level state machine. All dsTest applications are event-driven, enabling you to easily alter subscribers’ activities. Use our visual composer to draw your state machine and to trace a single subscriber’s path through the state machine while the test is running. Define event handlers that affect a subscriber’s behavior in an application, or that trigger an event in another application. You can also configure event handlers to modify subscriber information during run-time, introduce timers, or randomize subscriber behavior based on configurable probabilities to name just a few of the many options in one of dsTest’s most powerful features.
SmartMessageElement — Insert, delete, or replace elements in Diameter, RADIUS, MAP, LDAP, GTP, REST, or SOAP messages with our SmartMessageElement feature. Define proprietary signaling or corrupt elements to facilitate negative testing. You can specify when your elements are used with SmartEvents.
Traffic Profile — Draw the shape of your test actions across time with Traffic Profile. You can define the rate for any action as a static rate or reference a Traffic Profile configuration, which also means that multiple Traffic Profiles can be running concurrently. Use Traffic Profile in conjunction with the randomizing features in SmartEvents to design a test that more truly simulates real-world network activity.
REST Dictionary — Add conformance testing to your performance or functional test with our REST Dictionary. You can validate message types and JSON structures by simply including our base dictionary. You can also build custom dictionaries to explicitly define required parameter and property values and selectively include the dictionary to be used for a particular test.
dsTest provides rich sets of measurements for Nnrf services:
- Transaction and transport layer attempts, successes, and failures
- Transaction duration, transactions-per-second, and round-trip delay
- Message and byte counters
- Errors encountered and error indications received in messages