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 the environment and provide the 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 (that is NF Registration microservice, NF Subscription microservice, NRF Auditor microservice).

    NF Registration, NF Subscription, NRF Auditor microservices uses this microservice to get the status of other two microservices. In case any of service is found as down, status asking microservice will reject the incoming messages. This microservice is also responsible to fetch DB replication status whether it is active or not-active.

OCNRF Features

This section explains 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

OCNRF supports Subscriber Location Function (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

OCNRF Forwarding 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 is 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.

NF Heartbeat enhancement

This feature allows the operator to configure minimum, maximum, default Heartbeat Timers and the maximum number of consecutive heartbeats the NF is allowed to miss. Further, these values can customized per NF type.

According to 3GPP 29.510, every NF registered with the NRF shall keep its operative status alive by sending NF Heart-Beat requests periodically. The NF can optionally send the heartbeatTimer value when it registers its NFProfile or when it wants to update its registered NFProfile.

OCNRF may modify the value of the heartbeatTimer based on its configuration and return the new value to the NF on successful registration. The NF shall thereafter use the heartbeatTimer as received in the registration response as its heartbeat interval.

In case the configuration changes at the OCNRF for the heartbeatTimer, the changed value shall be communicated to the NF in the response of the next periodic NF Heart-Beat request or when it next sends a NFUpdate request to the OCNRF.

OCNRF monitors the operative status of all the NFs registered with it, and when it detects that an NF has missed updating its NFProfile or sending a Heart-beat for the heartbeat interval, NRF shall mark the NFProfile as SUSPENDED. The NFProfile and its services shall not longer be discoverable by the other NFs through the NfDiscovery Service. Further, the NRF shall notify the subscribed NFs of the change of status of the NFProfile.

OCNRF NF Authentication using TLS certificate

HTTPS support is a minimum requirement for 5G NFs as defined in 3GPP TS 33.501. This feature enables extending identity validation from Transport layer to the application layer and also provides a mechanism to validate the NF FQDN presence in TLS certificate as added by the Service Mesh against the NF Profile FQDN present in the request.

This feature is used by OCNRF to authenticate the Network Function before accessing the OCNRF services. In case, authentication fails, service operation request will be rejected. In this feature, some attributes from TLS certificate is challenged against defined attributes.

OCNRF provides configurations to enable/disable the feature dynamically. To enable the feature on Ingress API-GW in OCNRF deployment. Refer to xfccHeaderValidation attribute in User Configurable Section of OCNRF Installation Guide for more details.

OCNRF Access Token Request Authorization Feature

NRF follows and supports the 3GPP 29.510 based verification for Access Token Authorization requests for specific NF-Producer based on the allowednftypes, allowedplmn present in the NFProfiles. Extension to this requirement is to include screening for Access Token requests based on NF Type.

OCNRF plays major role as an OAuth2.0 Authorization server in 5G Service based architecture. When a NF service Consumer needs to access the services of a NF producer of a particular NFType and NFInstanceId, it shall obtain an OAuth2 access token from the NRF. NRF shall perform the required authorization, and if successful shall issue the token with the requested claims. Using this feature, OCNRF provides the user an option to tailor the authorization of the Producer-Consumer NF Types along with the Producer NF's services.

User can configure mapping of the RequesterNfType, TargetNfType and the allowedServices of the Target NF. Access Token request received based on the configuration and is furthered processes the request only if the authorization is successful. Allowed Services can be configured as single wild card '*' which denotes all the TargetNfs services are allowed for the consumer NF. User can also configure the HTTP status code and error description that will be used in the Error Response sent by the NRF when an Access Token request is rejected.

Access Token configurable attribute "logicalOperatorForScope" will be used while authorizing the services in the Access Token Request's scope against the allowed services in the configuration. If the logicalOperatorForScope is set to "OR", at-least one of the services in the scope shall be present in the allowed Services. If it is set to "AND", all the services in the scope shall be present in the allowed services.

Service mesh for intra-NF communication

Oracle NRF leverages the Istio or Envoy service mesh (Aspen Service Mesh) for all internal and external communication. The service mesh integration provides inter-NF communication and allows API gateway co-working with service mesh. The service mesh integration supports the services by deploying a special sidecar proxy in the environment to intercept all network communication between microservices. Refer to OCNRF Installation guide for more details on configuring ASM.