OCNRF Features

Subscriber Location Function

OCNRF supports Subscriber Location Function (SLF) feature which identifies specific NF Producer selection based on Subscriber Identity (like SUPI and GPSI) as explained below:

Checks if SLF lookup needs to be performed before processing the discovery request
- If GroupId is already present in the Discovery Query, even if SLF feature is ENABLED. OCNRF will use the received Group Id and will not perform SLF lookup.
- Supported NF Types for which SLF lookup will be performed can be configured using "supportedNfTypeList" attributes in SLF Options. OCNRF supports the below NF Type(s) for performing SLF lookup:
  - UDM
  - UDR
  - AUSF
Finds the NF Group Id by sending SLF query (that is, Nudr_GroupIDmap service operation) with the received Subscriber Identity (like SUPI and GPSI).
Generates NFDiscover service response using the NF Group Id received in SLF response and other parameters.
- The received Subscriber Identifier will not be used during NF Producer selection.

Key points:

SLF function on UDR network function will be configured with details of subscribers mapped to group identifiers. Producer network functions will be deployed in network belonging to group identifiers
Producer network functions will not publish the range of subscriber identities in their network profile while registering with OCNRF
While discovering the producer network functions, consumer Network functions will send discover query parameters including the subscriber identities like SUPI, GPSI. Note mandatory attributes of NFDiscover service operation will be in discovery query as per 3GPP specification 29.510 v 15.5.0. Consumer may provide additional query parameters provided in 3GPP specification 29.510 v 15.5.0
OCNRF will need to send query to UDR with subscriber identity received in NF Discover service operation
UDR will provide group id mapped to subscriber identity
OCNRF will do discovery of network function using the group id provided by UDR/SLF and send response back to consumer network function with discovered producer network function profiles

Refer to SLF Options for more information on REST APIs.

For metrics, alerts and KPIs, refer to NRF-SLF Metrics, OCNRF Alerts and OCNRF KPIs sections respectively.

See SLF Options to know how to configure SLF using CNC Console.

OCNRF Forwarding

OCNRF Forwarding feature forwards the service operation messages if OCNRF is not able to fulfill the required service operation.

Note:

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

A 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).

Refer to NRF-NRF Forwarding Options for more information on REST APIs.

For metrics, alerts and KPIs, refer to NRF Forwarding Metrics, OCNRF Alerts and OCNRF KPIs sections respectively.

See Forwarding Options to know how to configure OCNRF forwarding feature using CNC Console.

OCNRF Geo-Redundancy

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 replicated 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:

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

Refer to Geo Redundancy Options for more information on REST APIs.

For metrics, alerts and KPIs, refer to GeoRedundancy metrics, OCNRF Alerts and OCNRF KPIs sections respectively.

See Geo Redundancy Options to know how to configure OCNRF geo-redundancy feature using CNC Console.

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 keeps its operative status alive by sending NF heartbeat 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 will 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 must 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 heartbeat for the heartbeat interval, NRF must mark the NFProfile as SUSPENDED. The NFProfile and its services may not longer be discoverable by the other NFs through the NfDiscovery Service. Further, the NRF will 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.

Refer to NF Authentication Options for more information on REST APIs.

For metrics, alerts and KPIs, refer to NF Authentication Metrics, OCNRF Alerts and OCNRF KPIs sections respectively.

See NF Authentication Options to know how to configure OCNRF authentication feature using CNC Console.

Access Token Request Authorization

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

NRF 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 obtains an OAuth2 access token from the NRF. NRF performs the required authorization, and if successful, will issue the token with the requested claims. Using this feature, OCNRF provides an option to the user to tailor the authorization of the Producer-Consumer NF Types along with the Producer NF's services.

User can configure mapping of the Requester NF Type, Target NF Type, and the allowed services 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 OCNRF when an Access Token request is rejected.

Access Token configurable attribute "logicalOperatorForScope" is 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 will be present in the allowed services. If it is set to "AND", all the services in the scope will be present in the allowed services.

Refer to NF Access Token Options for more information on REST APIs.

For metrics, alerts and KPIs, refer to NF AccessToken Authorization Metrics, OCNRF Alerts and OCNRF KPIs sections respectively.

See NF Access Token Options to know how to configure OCNRF AccessToken feature using CNC Console.

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.

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.

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.

Refer to NF Screening Configuration for more information on REST APIs.

For metrics, alerts and KPIs, refer to NF Screening Metrics, OCNRF Alerts and OCNRF KPIs sections respectively.

See NF Screening Options to know how to configure OCNRF AccessToken feature using CNC Console.

Rest based OCNRF state data retrieval feature

Rest based OCNRF state data retrieval feature provide options for Non-Signaling APIs to access OCNRF state data. It helps operator/user to access the OCNRF state data to understand and debug in the event of failures.

This feature provides various queries which can help to get data as per the need. Different query attributes helps to achieve the required data.

Refer to OCNRF state data retrieval REST APIs for more information on REST APIs.

KeyID for Access Token

Key-ID feature is about to add "kid" header in Access Token Response generated by OCNRF. As per RFC 7515 section 4.1.4, the use of Key-ID (KID) is to hint indicate which key was used to secure JWS.

Each OCNRF and NF producer(s) will have multiple keys with algorithm indexed with "kid" configured. OCNRF Rest based configuration provides options to configure different key-ids and corresponding OCNRF private keys and public certificates along with corresponding oauth signing algorithms. One of the configured key-ids, can be set as current key-id.While generating the oauth access token, OCNRF uses the keys, algorithm and certificates corresponding to current key-id.

OCNRF configuration provides "addkeyIDInAccessToken" attribute which tells to add key-id as header in Access Token Response or not. If value is true, then currentKeyID value will be added in "kid" header in AccessToken Response. If value is false, then "kid" header will not be added in AccessToken Response.

Refer to NF Access Token Options for more information on REST API configuration.

Refer to OCNRF configuration status REST APIs for more information on how to check AccessToken Signing Key Status.

Refer to OCNRF Alerts and OCNRF KPIs sections for more information on alerts and KPIs.

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.