1. Network Repository Function (NRF) Cloud Native User's Guide
  2. OCNRF Architecture

3 OCNRF Architecture

OCNRF comprises of various microservices deployed in Kubernetes based Cloud Native Environment (CNE, example: OCCNE). Some common services like logs or metrics data collection, analysis and graphs or charts visualization, and so on are provided by the environment. The microservices integrate with them and provide them necessary data.

Following are the components of OCNRF product:

  • NF Registration Microservice

    This microservice receives and handles the following service operations:

    • NFRegister service requests from the NFs
    • NFUpdate service requests from the NFs
    • NFDeregister service requests from the NFs
    • NFListRetrieval service requests from the NFs
    • NFProfileRetrieval service requests from the NFs
    • Heart-beat messages from the NFs
  • NF Subscription Microservice

    This microservice performs the following service operations:

    • receives and handles NFStatusSubscribe service requests from the NFs
    • receives and handles NFStatusUnsubscribe service requests from the NFs
    • sends NFStatusNotify service requests towards the subscribed NFs
  • NF Discover Microservice

    This microservice receives and handles the following service operations:

    • NFDiscover service requests from the NFs
  • NF AccessToken Microservice

    This microservice handles 3GPP defined AccessToken service operations. Oauth2.0 based token is provided by OCNRF according to inputs provided by consumer network function in access token request.

  • OCNRF Auditor Microservice

    This microservice is internal to OCNRF. This microservice performs the following tasks:

    • finds and deletes the expired subscription records
    • finds and deletes the profile records which have been SUSPENDED for a very long time
    • monitors the heart-beat expiry, mark the NF profiles as suspended and act appropriately on the suspended NF profiles
  • OCNRF Configuration Microservice

    This microservice is used to configure OCNRF. These configuration can be changed dynamically by a operator/user using REST based interface. This configuration data is managed by the OCNRF configuration service and is stored in a separate data store.

  • OCNRF Ingress Gateway Microservice

    This microservice is entry point for accessing OCNRF supported service operations.

  • OCNRF Egress Gateway Microservice

    This microservice is responsible to route OCNRF initiated egress messages to other NFs.

  • App Info Microservice

    This microservice is responsible to get the status of microservices related to NFManagement Service operations (i.e. NF Registration microservice, NF Subscription microservice, NRF Auditor microservice). In case any of them are down, status of NF Management combined together will be down.

    This microservice is also responsible to fetch DB replication status whether it is active or not-active. This happens only if geoRedundancyFeatureStatus is ENABLED.

OCNRF Features

Following are the OCNRF features:

NF Screening

NF Screening supports the functionality to screen the service requests received from 5G Network Functions (NFs) before allowing access to OCNRF services.

In this feature, OCNRF screens the incoming service operations from NFs on the basis of some attributes against set of rules configured at OCNRF. OCNRF processes the required services only if screening is successful.

This feature provides extra security by restricting the NF that can use the service of OCNRF. Operator can decide which NF with required attributes can access the services provided by OCNRF. To implement this, operator can configure various screening lists in which attributes can be configured to tell which attribute is allowed or not.

Note:

By default, NF Screening feature is globally disabled. This feature can be enabled by setting the nfScreeningRulesListStatus attribute as "ENABLED" using REST based Interface.

For configuring NF Screening feature, see Configuring NF Screening.

The screening can be in the form of Whitelist or Blacklist.

  • When a screening list is configured to operate as a whitelist, the request is allowed to access the service only if the corresponding attribute value is present in the whitelist.
  • When a screening list is configured to operate as a blacklist, the request is allowed to access the service only if the corresponding attribute value is not present in the blacklist.
Screening Lists can have rules for global and per NF type:
  • The global level screening lists allows operators to configure screening that is common to all NFs.
  • Per NF Type level rules provides additional flexibility/granularity for screening that can be controlled on a per NF type basis.

Note:

  • The rules can be configured at both Global level and Per NF Type level.
  • "NF type list allowed to Register" is available at Global level only.

Subscriber Location Function (SLF)

OCNRF supports SLF feature which identifies specific NF Type selection based on subscriber identity. For NF selection based on subscriber identity, OCNRF performs the following:

  • Identifies (if received) NFDiscover service request requires NF selection based on subscriber identity.
  • Discovers the NF Group Id(s) using Nudr_GroupIDmap (aka SLF) Query service operation.
  • Generates NFDiscover service response using NF Group Id(s) and other parameters.

OCNRF Forwarding Feature

This feature is about forwarding the service operation messages if OCNRF is not able to fulfill the required service operation.

Note:

Service operations with specific cases/scenarios are eligible for forwarding.

An consumer NF Instance can perform the following:

  • Subscribe to changes of NF Instances registered in an NRF to which it is not directly interacting. The NF subscription message is forwarded by an intermediate NRF to another NRF.
  • Retrieve the NF Profile of the NF Instances registered in an NRF to which it is not directly interacting. The NF profile retrieval message is forwarded by an intermediate NRF to another NRF.
  • Discover the NF Profile of the NF Instances registered in an NRF to which it is not directly interacting. The NF discover message is forwarded by an intermediate NRF to another NRF.
  • Request OAuth 2.0 access token for the NF Instances registered in an NRF to which it is not directly interacting. The OAuth 2.0 access token service request is forwarded by an intermediate NRF to NRF (which may issue the token).

OCNRF Geo-Redundancy Feature

OCNRF supports two site Geo-Redundancy to ensure service availability when one OCNRF site is down. When OCNRF deployed as Geo-Redundant NRF, both the OCNRFs works in Active state. The NFs in a given site needs to configure one of the Geo-Redundant OCNRF as the primary NRF and the other one as secondary NRF. If the primary OCNRF is available, the NFs shall send service requests to the primary OCNRF. In case the primary OCNRF is down, the NF shall redirect its traffic to the secondary OCNRF till the primary OCNRF is unavailable.

The OCNRF's State data gets replicate between the Geo-Redundant sites by using DB tier's replication service.

With OCNRF Geo-Redundant feature, availability of OCNRF's Services will work as below:
  • Unavailability of any one of NFRegistration, NFSubscription and NrfAuditor micro-services will result in Unavailability of NFManagement service operations at OCNRF.
  • NFDiscovery and NFAccessToken services of OCNRF will continue to work as independent service operation.

Following are the requirements for geo-redundancy:

  1. Both geo-redundant sites must have helm and rest based configuration (except NRF Instanced Id, OCNRF Endpoint and port)
  2. Geo-Redundant sites must be time synchronized.
  3. Geo-Redundant OCNRF sites must be reachable from NFs on both sites.
  4. NFs needs to configure Geo-Redundant OCNRF details as Primary and Secondary NRFs.
  5. NFs must not communicate to both Geo-Redundant OCNRF sites at same time

Automated Test Suite Support

OCNRF provides Automated Test Suite for validating the functionalities. ATS allows you to execute OCNRF test cases using an automated testing tool and then, compares the actual results with the expected or predicted results. In this process, there is no intervention from the user. Refer to ATS User Manual for more information.