1 Introduction

This document provides information about the role of Oracle Communications Cloud Native Core, Network Repository Function (NRF) in 5G Service Based Architecture, how to configure, and use NRF.

NRF is a key component of the 5G Service Based Architecture. NRF maintains an updated repository of all the Network Functions (NFs) available in the operator's network. It also maintains the services provided by each of the NFs in the 5G core that is expected to be instantiated, scaled, and terminated with minimal to no manual intervention. In addition to serving as a repository of the services, NRF also supports discovery mechanisms that allow NFs to discover each other and get the updated status of the desired NFs.

Note:

The performance and capacity of the NRF system may vary based on the call model, Feature or Interface configuration, and underlying CNE and hardware environment.

The NRF installation is supported over the following platforms:

  • Oracle Communications Cloud Native Core, Cloud Native Environment (CNE)
  • Oracle Communications Cloud Native Core OCI Adaptor, NF Deployment in OCI

For more information, see Oracle Communications Cloud Native Core, Network Repository Function Installation, Upgrade, and Fault Recovery Guide.

NRF supports the following functions:

  • Maintains the profiles of the available NF instances and their supported services in the 5G core network.
  • Allows consumer NF instances to discover other provider's NF instances in the 5G core network.
  • Allows NF instances to track the status of other NF instances.
  • Provides Oauth2 based Access Token service for consumer NF authorization.
  • Provides specific NF Type selection based on subscriber identity like SUPI, GPSI.
  • Supports forwarding of messages from one NRF to another NRF.
  • Supports georedundancy to ensure service availability.
  • Supports roaming to serve 5G subscribers roaming in a non-home network also known as visited or serving networks, consumer network functions in visited or serving networks need to access the NF Profiles located in the home network of 5G subscribers.

NRF interacts with every other NF in the 5G core network and it supports the above functions through the following services:

  • Management Service
  • Discovery Service
  • AccessToken Service

NRF Availability

NRF availability is dependent on many factors. NRF applications are designed to achieve 99.999% availability, according to the applicable Telecommunications Industry Association TL9000 standards, with the following deployment requirements:
  • Deploy on a Cloud Native Environment with at least 99.999% Availability.
  • Deploy with n + k application redundancy, where k is greater than or equal to one.
  • Maintain production software within n-3 software releases, where n is the current general availability release.
  • Apply bug fixes, critical patches, and configuration recommendations provided by Oracle promptly.
  • Maintain disaster recovery procedures external to the applications for the reconstruction of lost or altered files, data, programs, or Cloud Native environment.
  • Install, configure, operate, and maintain NRF as per Oracle’s applicable installation, operation, administration, and maintenance specifications.
  • Maintain an active support contract and provide access to the deployed NRF and your personnel to assist Oracle in addressing any outage.
NRF availability is measured for each calendar year and is calculated as follows:

Table 1-1 Measuring NRF Availability

Availability Description
Planned Product Availability (Product available time in each month) less (Excluded Time (defined below) in each month).
Actual Product Availability (Planned Product Availability) less (any Unscheduled Outage)
Product Availability Level (Actual Product Availability across all Production instances divided by Planned Product Availability across all Production instances) x 100

Note:

Excluded Time means:
  • Scheduled maintenance time.
  • Lack of power or backhaul connectivity, except to the extent that such lack of backhaul connectivity was caused directly by the CNC NF.
  • Hardware failure.
  • Issues arising out of configuration errors or omissions.
  • Failures caused by third-party equipment or software not provided by Oracle.
  • Occurrence of any event under Force Majeure.
  • Any time associated with failure to maintain the recommended architecture and redundancy model requirements above.

1.1 References

Following are the reference documents:

  • Oracle Communications Cloud Native Core, Cloud Native Environment Installation, Upgrade, Fault Recovery Guide
  • Oracle Communications Cloud Native Core, Network Repository Function Installation, Upgrade, and Fault Recovery Guide
  • Oracle Communications Cloud Native Core, Network Repository Function REST Specification Guide
  • Oracle Communications Cloud Native Core, Network Repository Function Network Impact Report
  • Oracle Communications Cloud Native Core, cnDBTier User Guide
  • Oracle Communications Cloud Native Configuration Console User Guide
  • Oracle Communications Cloud Native Core Automated Test Suite Guide
  • Oracle Communications Cloud Native Core, Network Function Data Collector User Guide
  • Oracle Communications Cloud Native Core, OCI Deployment Guide
  • Oracle Communications Cloud Native Core, OCI Adaptor User Guide