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

5 Configuring OCNRF

OCNRF can be configured using HELM and REST configuration. Some configuration are performed during installation using HELM and few are modified using REST. For HELM configuration refer to OCNRF Cloud Native Installation and Upgrade Guide. The REST configurations can also be performed using Cloud Native Core (CNC) Console. Refer to Configuring OCNRF using CNC Console for more details.

Mandatory Configurations

Following are the mandatory parameter, which must be configured before using OCNRF:
  • nrfPlmnList: PLMN(s) served by OCNRF. This must be configured before using any OCNRF Services.
  • ocnrfHost: OCNRF Host's FQDN.
  • ocnrfPort: OCNRF Host's Port.

Subscriber Location Function Configuration

SLF Host Configuration attribute (slfHostConfig) allows the user to configure the details of SLF/UDR Network Functions.

The slfHostConfig configuration consists of attributes like apiVersion, scheme, FQDN, port, priority, etc. OCNRF allows to configure more than two host details. However the host with highest priority is considered as Primary Host. The host with second highest priority is considered as Secondary Host.

Note:

  • Refer 29.510, release 15.5 for definition and allowed range for slfHostConfig attributes (apiVersion, scheme, FQDN, port, priority, etc).
  • Apart from priority attribute, no other attributes plays any role in Primary/Secondary host selection.
  • Apart from Primary/Secondary host, other configured hosts (if any) are not used during any message processing.
  • When more than one host is configured with highest priority, then two of them will be picked as Primary/Secondary host randomly.
In Subscriber Location Function (SLF) feature, SLF request is first sent to Primary SLF. In case of error from Primary SLF, request is sent to Secondary SLF based on below configuration:
  1. rerouteOnResponseHttpStatusCodes: This configuration is used to determine if the SLF request message can be sent to Secondary SLF or not. After getting response from primary SLF, if response status code from primary SLF matches with this configuration, then OCNRF reroutes the request to the secondary SLF. Refer slfHostConfig attribute for Primary and Secondary SLF details.
  2. maximumHopCount: This configuration is used to determine Maximum number of hops (SLF/NRF) that OCNRF can forward a given service request. This configuration more useful during NRF Forwarding and SLF feature interaction.

NRF Forwarding

NRF Host Configuration attribute (nrfHostConfig) allows the user to configure the details of another NRF to which forwarding will happen.

Note:

For NRF-NRF forwarding feature to work, nrfHostConfig attribute must be configured in both NRFs with each other values.

For example: OCNRF1 is forwarding requests towards OCNRF2, then nrfHostConfig configuration attribute of OCNRF1 shall have OCNRF2 details and similarly nrfHostConfig configuration attribute of OCNRF2 shall have OCNRF1 details. These configurations are used while handling different service operations of OCNRF.

The nrfHostConfig configuration consists of attributes like apiVersion, scheme, FQDN, port, priority, etc. OCNRF allows to configure more than two host details. However the host with highest priority is considered as Primary Host. The host with second highest priority is considered as Secondary Host.

Note:

  • Refer 29.510, release 15.5 for definition and allowed range for NfHostConfig attributes (apiVersion, scheme, FQDN, port, priority, etc).
  • Apart from priority attribute, no other attributes plays any role in Primary/Secondary host selection.
  • Apart from Primary/Secondary host, other configured hosts (if any) are not used during any message processing.
  • When more than one host is configured with highest priority, then two of them will be picked as Primary/Secondary host randomly.
In NRF forwarding feature, request is first forwarded to Primary NRF. In case of error, request is forwarded to Secondary NRF based on below configuration:
  1. nrfRerouteOnResponseHttpStatusCodes: This configuration is used to determine if the service operation message can be forwarded to Secondary NRF or not. After getting response from primary NRF, if response status code from primary NRF matches with this configuration, then OCNRF reroutes the request to the secondary NRF. Refer nrfHostConfig attribute for Primary and Secondary NRF details.
  2. maximumHopCount: This configuration is used to determine Maximum number of hops (SLF/NRF) that OCNRF can forward a given service request. This configuration more useful during NRF Forwarding and SLF feature interaction.

Configuring Access Token Request Authorization

Configuration for OCNRF Access Token Request Authorization

With nfAccessTokenOptions API, authFeatureConfig attribute provides the support required to use OCNRF Access Token Request Authorization Feature. Refer to OCNRF Configuration REST APIs for more details.

Sample configuration to use the feature
{
   "oauthTokenExpiryTime": "1h",
   "authorizeRequesterNf": "ENABLED",
   "logicalOperatorForScope": "AND",
   "audienceType": "NF_INSTANCE_ID",
   "authFeatureConfig": {
      "featureStatus": "DISABLED",
      "authRulesConfig": [
            {
               "targetNfType":"PCF",
               "requesterNfType":"AMF",
               "serviceNames":[
                  "npcf-am-policy-control",
                  "npcf-eventexposure"   
               ]
            },
            {
               "targetNfType":"UDM",
               "requesterNfType":"AMF",
               "serviceNames":[
                  "*"
               ]
            }
         ],
      "errorResponses": [{
         "errorCondition": "RequesterNf_Unauthorized",
         "responseCode": 400,
         "errorResponse": "The Consumer NfType is not authorized to receive access token for the requested Nftype.",
         "retryAfter": "5m",
         "redirectUrl": ""
     }]
   },
   "tokenSigningDetails": {
        "currentKeyID": "a14ef8e1bc5c",
        "addkeyIDInAccessToken": true,
        "defaultK8SecretDetails": {
            "k8SecretName": "ocnrf",
            "k8SecretNameSpace": "ocnrf"
        },
        "keyDetailsList": [
            {
                "keyID": "a14ef8e1bc5c",
                "algorithm": "ES256",
                "privateKey": {
                    "k8SecretName": "ocnrf",
                    "k8SecretNameSpace": "ocnrf",
                    "fileName": "ec_private_key_pkcs8.pem"
                },
                "certificate": {
                    "k8SecretName": "ocnrf",
                    "k8SecretNameSpace": "ocnrf",
                    "fileName": "ecdsa_ocnrfapigatewayTestCA.cer"
                }
            }
        ]
    },
   "errorResponses": [
        {
            "errorCondition": "Invalid_Key_Details",
            "responseCode": 500,
            "errorResponse": "Configured Key ID details are invalid and cannot be used",
            "retryAfter": "5m",
            "redirectUrl": ""
        },
        {
            "errorCondition": "Current_Key_Id_Not_Configured",
            "responseCode": 500,
            "errorResponse": "Current Key ID is not configured",
            "retryAfter": "5m",
            "redirectUrl": ""
        }
    ]
}

Configuring NF Authentication using TLS certificate

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

OCNRF provides configuration to enable/disable the feature dynamically. Refer to xfccHeaderValidation attribute in User Configurable Section of OCNRF Installation Guide to enable the feature on Ingress API gateway in OCNRF deployment.

Note:

  • This feature is disabled by default. Feature needs to be enabled at API-GW and OCNRF levels both to make this feature work. At OCNRF level, feature enabling/disabling can be done using mentioned configuration below.
  • Once this feature is enabled. All of NFs must re-register with FQDN in NF Profile or NFs can send NFUpdate with FQDN. For Subscription Service Operations, Network Functions need to register with OCNRF, even NFs has taken Subscription Prior to enabling the feature, need to Register with NRF for further service operations.

Configuration Required to use OCNRF NF Authentication using TLS certificate feature

Refer to attributes under nfAuthenticationSystemOptions in NF Authentication Options for more details.

Sample configuration to use the feature

Enable the following attributes:
{

    "nfRegistrationStatus": "DISABLED",
    "nfSubscriptionStatus": "DISABLED",
    "nfDiscoveryStatus": "DISABLED",
    "accessTokenStatus": "DISABLED",
    "nfProfileStatus": "DISABLED",
    "nfListRetrievalStatus": "DISABLED",
    "checkIfNfIsRegistered": "DISABLED",
    "errorResponses": [{
    "errorCondition": "Nf_Fqdn_Authentication_Failure",
       "responseCode": 403,
       "errorResponse": "Failed to authenticate NF using FQDN",
       "retryAfter": "5m",
       "redirectUrl": ""
   }]
}