4 NSSF Supported Features

This section explains about the NSSF supported features.

Note:

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

4.1 LCI and OCI Headers

Within the complex 5G architecture, network overload scenarios are common. The exchanges of data between producer and consumer Network Functions (NFs) often involve significant message and notification volumes, necessitating a precise approach to load balancing. This is imperative to prevent network failures triggered by overload conditions.

In such demanding scenarios, it becomes crucial for consumer NFs to be promptly informed when the producer NF approaches an overloaded state. This awareness enables consumer NFs to implement corrective actions proactively.

To address these challenges, the introduction of LCI and OCI Headers plays a pivotal role in optimizing communication between NSSF and its consumer NFs. They provide consumer NFs with real-time insights into the operational status of the NSSF resources, facilitating efficient traffic management.

These headers provide essential load and overload information for consumer NFs to optimize traffic distribution and take proactive measures during network overload scenarios.

The headers are integrated into outgoing responses, based on load levels at the Ingress Gateway. Serving as communication tools, they allow Network Functions (NFs) to share crucial load information, ensuring an architecture where 5G Core Network remains stable and high performing even during heavy load conditions.

LCI Header

The LCI header comprises overall load related information such as the timestamp of load data generation, the current load of the NF, and the scope of the load information. For example, there are two LCI headers:

• NF scope LCI header
• NF-service scope LCI header

Examples of LCI Headers

NF Scope LCI Header:

3gpp-sbi-lci: Timestamp: "Tue, 19 Sep 2023 13:47:41 UTC"; Load-Metric: 1%; NF-Instance: 9faf1bbc-6e4a-4454-a507-aef01a101a01

Service Scope LCI Header:

3gpp-sbi-lci: Timestamp: "Mon, 25 Sep 2023 11:30:17 UTC"; Load-Metric: 0%; NF-Service-Instance: ae870316-384d-458a-bd45-025c9e748976

OCI Header

The OCI header communicates information about overload conditions. This information encompasses the timestamp at which the overload condition was detected, the type of overload condition (such as, resource exhaustion), and the recommended action to be taken. For example, reducing the number of requests.

Both the LCI and OCI headers are incorporated in HTTP response messages without triggering additional signaling, ensuring a more efficient communication process. Here is how they help:

• The LCI header conveys the overall load of an NF, assisting in decisions regarding the acceptance or rejection of new requests to prevent further overload.
• In contrast, the OCI header communicates specific overload conditions, helping NFs take informed actions to mitigate these conditions.
• The LCI and OCI headers complement each other, allowing an NF to reduce the number of requests it sends to other NFs in response to an OCI header, even if its overall load is not yet overloaded.
• This proactive measure prevents overload conditions from spreading.

Examples of OCI Headers

NF Scope OCI Header:

3gpp-Sbi-Oci:Timestamp: "Mon, 02 May 2022 07:43:48 UTC"; Period-of-Validity: 30s; Overload-Reduction-Metric: 5.0%; NF-Instance: 5a7bd676-ceeb-44bb-95e0-f6a55a328b03

Service Scope OCI Header:

3gpp-Sbi-Oci:Timestamp: "Mon, 02 May 2022 07:43:48 UTC"; Period-of-Validity: 30s; Overload-Reduction-Metric: 5.0%; NF-Service-Instance: 5a7bd676-ceeb-44bb-95e0-f6a55a328b03

Use Cases

• As of now, LCI and OCI Headers are supported at the Ingress Gateway only; not at the Egress Gateway.
• NSSF can utilize the LCI header to signal its load information to the AMF (Access and Mobility Management Function). This information allows the AMF to make informed decisions about directing new User Equipment (UE) connections to the NSSF.
• Conversely, the NSSF can employ the OCI header to notify the Radio Access Network (RAN) of overload conditions, enabling the RAN to reduce the number of UEs it routes to NSSF.

Managing LCI and OCI Headers

Enable:

You can enable LCI and OCI Headers by performing the following Helm configurations globally and at the Ingress Gateway:

• Global Helm Configuration
  • Enable: You can enable LCI and OCI Headers globally at the Network Function (NF) level by setting the values of nssfLciEnabled and nssfOciEnabled parameters as true, respectively.

    global:
    #=======================LCI/OCI header Global  Values============================================
      #Enabling LCI
      nssfLciEnabled: &lcienable true
      #Enabling OCI
      nssfOciEnabled: &ocienable true
     #====================================================================

• Ingress Gateway Helm Configuration
  • Enable: You can enable LCI and OCI Headers globally at Ingress Gateway level by setting the lciHeaderConfig.enabled and ociHeaderConfig.enabled parameters as true, respectively.
  • Configure: You can configure LCI and OCI Headers at Ingress Gateway using the Helm based configuration:

    ## This is mandatory for LCI and OCI feature as this is required by perf-info service to get the load information of the services from prometheus
    perf-info:
      configmapPerformance:
          prometheus: http://occne-prometheus-server.occne-infra
      
      
    ingress-gateway:
     #To remove the Producer header from Ingress Response when LCI is enabled
      globalRemoveResponseHeader:
      - name: *producer
      # ********  Sub-Section Start: LCI/OCI Ingress Gateway Parameters ************
      #**************************************************************************
    
      # Engineering Parameter Start
      global:
        lciHeaderConfig:
          enabled: *lcienable
          # difference between previous threshold and current threshold for lci header will be added when the difference crosse the mentioned value
          loadThreshold: 30
          # Validity period after which lci header will be added to reponse header if delta of threshold is not breached
          localLciHeaderValidity: 60000 #(value in milliseconds)
          ## This header needs to be same which is being sent along with  request in microservice
          producerSvcIdHeader: *producer
    
        ociHeaderConfig:
          enabled: *ocienable
          ## This header needs to be same which is being sent along with reuest  microservice
          producerSvcIdHeader: *producer
          validityPeriod: 10000 #(value in milliseconds)
          ## The range of the cpu load for which the ingress gateway will get notified regarding the criticality of the load.
          overloadConfigRange: #Note - minor, major and critical conditions should cover complete range of 0 to 100 both inclusive for it to be a valid config
            minor: "[75-80]"
            major: "[81-90]"
            critical: "[91-100]"
          ## The range of the cpu load which needs to be decreased from the consumer when a particular criticality has reached.
          reductionMetrics:
            minor: 5  #(Possible values 1 to 9 both inclusive)
            major: 15  #(Possible values 5 to 15 both inclusive)
            critical: 25 #(Possible values 10 to 50 both inclusive)
    
        nfInstanceId:  "9faf1bbc-6e4a-4454-a507-aef01a101a01"
          ## This is a mapping for service name to service instance id for which service the LCI and OCI headers needs to be enabled. Default values are given with 'ocnssf' as release name. It must be  configured by operator in case release name is changed.
          ## only nsselection and nsavailability services should be configured. As these are the two services for which  LCI/OCI headers is supported.
          ## Format is <releaseName>-<serviceName> . Eg: if release name is given 'ocnssf-test' then svc name should be 'ocnssf-test-nsselection' and 'ocnssf-test-nsavailability'
        svcToSvcInstanceIdMapping:
          - svcName: ocnssf-nsselection
            serviceInstanceId: "ae870316-384d-458a-bd45-025c9e748976"
          - svcName: ocnssf-nsavailability
            serviceInstanceId: "ae870316-384d-458a-bd45-025c9e748996"
    
        perfInfoConfig:
          ## the interval when perf-info will fetch the cpu load from prometheus
          pollingInterval: 5000 #(value in milliseconds)
          serviceName: "ocnssf-perf-info"
          port: 5905
          perfInfoRequestMap: "/load"
      # Engineering Parameter End
    
      # ********  Sub-Section End: LCI/OCI Ingress Gateway Parameters ************
    
      # ********  Sub-Section Start: DB credentials Ingress Gateway Parameters ************
      #**************************************************************************
      dbConfig:
        dbHost: *dbHost
        dbPort: *dbPort
        secretName: *privDbSecret
        dbName: *provDB
        # Name of the Key configured for "DB Username" in Secret with following name: "<dbConfig.secretName>"
        dbUNameLiteral: mysql-username
        # Name of the Key configured for "DB Password" in Secret with following name: "<dbConfig.secretName>"
        dbPwdLiteral: mysql-password
        # Default is NDBCLUSTER
        dbEngine: *dbEngine
    
      # ********  Sub-Section End: DB credentials Ingress Gateway Parameters ************
      #**************************************************************************

For more information about the Helm parameters, see "Customizing NSSF" section in Oracle Communications Cloud Native Core, Network Slice Selection Function Installation, Upgrade, and Fault Recovery Guide.

Observe

Metrics

There are no new metrics for this feature.

KPIs

There are no new KPIs for this feature.

Alerts

There are no alerts generated for this feature.

Maintain

To resolve any alerts at the system or application level, see NSSF Alerts section. If the alerts persist, perform the following:

1. Collect the logs: For more information on how to collect logs, see Oracle Communications Cloud Native Core, Network Slice Selection Function Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

4.2 Server Header in NSSF

One of the core functionalities of the Network Slice Selection Function (NSSF) is to manage the security aspects of the 5G network. As part of this role, NSSF handles various requests from other network functions (NFs) and network entities over the HTTP protocol. On receiving these requests, NSSF validates and processes them before issuing responses to the requesting NFs or network entities.

In such scenarios, NFs and other network entities may encounter issues resulting in error responses. It becomes imperative for consumer NFs to pinpoint the source of the error, so they can undertake troubleshooting and corrective measures. The integration of this feature at NSSF helps to determine the originator of the error response.

This feature offers the support for Server Header in NSSF responses, which contain crucial information about the origin of an error response and the type of the error encountered. Thus, the Server Header enhances the behavior of NSSF while responding to requests, particularly the error responses.

Note:

This feature is applicable in scenarios where NSSF generates error responses. It does not affect normal response behavior.

A Server Header starts with the value of NF Type, followed by a “-” and any other specific information, if needed, afterward. It is expected to be present in all NSSF responses in the following format:

<NF Type>-<Instance-Id>

Where,

• <NF Type> is the type of the NF.
• <NF Instance-Id> is the unique identifier of the NF instance generating the response.

For example, the following combinations are applicable to NSSF:

NSSF-<NSSF's Instance-Id>

Where,

• NSSF is the <NF Type>.
• <NSSF's Instance-Id> is the unique identifier of the NSSF instance generating the response.

Managing Server Header in NSSF

Enable:

By default, this feature is disabled. To enable it, REST API needs to be invoked and the enabled flag needs to be updated to true in the following URI:

/{nfType}/nf-common-component/v1/{serviceName}/serverheaderdetails

Example

Example of Request or Response Body to Enable Server Header:

{
  "enabled": true,
  "errorCodeSeriesId": "E1",
  "configuration": {
    "nfType": "NSSF",
    "nfInstanceId": "9faf1bbc-6e4a-4454-a507-aef01a101a01"
  }
}

Example of Request or Response Body to Disable Server Header:

{
  "enabled": false,
  "errorCodeSeriesId": "E1",
  "configuration": {
    "nfType": "NSSF",
    "nfInstanceId": "9faf1bbc-6e4a-4454-a507-aef01a101a01"
  }
}

Note:

• enabled is used to enable or disable the feature.
• nfType and nfInstanceId are used to form Server Header.
• In the mentioned configuration, when sending a response to AMF, the Server Header will be appended by the NSSF with the value "NSSF-9faf1bbc-6e4a-4454-a507-aef01a101a01"
• The values in the above example are samples. Ensure that you update the values of the following parameters according to your deployment:
  • nfType must be NSSF.
  • errorCodeSeriesId: A valid configured value.
  • nfInstanceId: NSSF's valid instance value. It must be same as NSSF's instance ID.

Configure

Perform the REST API configurations in the following sequence to configure this feature:

1. Configure serverheaderdetails to enable the feature.
2. Configure routesconfiguration to map route ID and its corresponding route-level configuration.
3. Configure errorcodeserieslist to update the errorcodeserieslist that are used to list the configurable exception or error for an error scenario in Ingress Gateway.

For more details about REST APIs, see "REST API Configurations for Server Header Feature" in Oracle Communications Cloud Native Core, Network Slice Selection Function REST Specification Guide.

Observe

Metrics

There are no new metrics for this feature.

KPIs

There are no new KPIs for this feature.

Alerts

There are no alerts generated for this feature.

Maintain

To resolve any alerts at the system or application level, see NSSF Alerts section. If the alerts persist, perform the following:

1. Collect the logs: For more information on how to collect logs, see Oracle Communications Cloud Native Core, Network Slice Selection Function Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

4.3 Support for User-Agent Header

In 5G networks, producer Network Functions (NFs) cannot identify or validate a consumer on their own. To overcome this, 3GPP has introduced User-Agent headers, which are added to consumer service requests. This field is included in the HTTP (Hypertext Transfer Protocol) request that a consumer sends to the producer to identify itself and provide information about the NF making the request.

This feature enables the usage of the User-Agent Header in NSSF.

NSSF support the following inter-NF communication and service request functionalities:

• NSSF sends notifications to AMF.
• NSSF sends registration and heartbeat request to NRF.

This enhancement enables NSSF to include the User-Agent Header in every HTTP/2 request that it sends over any Service Based Interface (SBI) to a producer NF (for example, AMF and NRF). The User-Agent Header in NSSF's HTTP/2 requests helps a producer NF to identify NF type of client that has sent a request. Here, it helps:

• AMF in identifying the NSSF that sent the notification.
• NRF in identifying the NSSF that sent the subscription, registration, or heartbeat request to NRF.

Structure of an User-Agent Header

An User-Agent Header starts with the value of NF type, followed by a "-" and any other specific information, if needed afterwards. It is expected to be present in all the service requests and notification in the following formats:

• <NF Type>
• <NF Type>-<Instance-Id>
• <NF Type>-<Instance-Id> <FQDN>

Where,

• <NF Type> is the type of the NF.
• <Instance-Id> is the instance ID of the NF.
• <FQDN> is the FQDN of the NF.

For example: The following combinations are applicable to NSSF:

NSSF

NSSF-<NSSF's Instance-Id>

NSSF-<NSSF's Instance-Id> <NSSF's FQDN>

When the User-Agent Header is not included in the incoming requests sent to AMF or NRF, the corresponding metric cannot gather information about the origin of the service request. Nevertheless, the request is still processed successfully without any problems, but the AMF or NRF are not able to identify the NSSF from which the request has originated.

Note:

The onus is on operator to configure the values correctly as defined in the syntax explained above.

Managing the Support for User-Agent Header

Enable:

1. Use the following API path:

   /{nfType}/nf-common-component/v1/{serviceName}/useragentheader

2. Set enabled as true.
3. Run the API using PUT method with the proposed values given in the Rest API. For more information about API path, see "Configurations to Enable or Disable User-Agent Header" section of "Egress Gateway REST APIs" in Oracle Communications Cloud Native Core, Network Slice Selection Function REST Specification Guide.
   Given below is a sample REST API configuration to enable this feature:

   {
      "enabled": true,
      "nfType": "NSSF",
      "nfInstanceId": "9faf1bbc-6e4a-4454-a507-aef01a101a01",
   "nfFqdn": "nssf.oracle.com",
   "addFqdnToHeader": true,
    "overwriteHeader": true
   }

Note:

• In the mentioned configuration, when sending notifications to AMF, the User-Agent Header will be appended by the NSSF with the value NSSF-9faf1bbc-6e4a-4454-a507-aef01a101a01 nssf.oracle.com.
• The nfInstanceId and nfFqdn values in the above example are samples. Ensure that you update the values of the nfInstanceId and nfFqdn parameters accordingly.

Observe

Metrics

The following metric is used to provide information about this feature:

• oc_egressgateway_user_agent_consumer_total: This metric is applicable whenever the feature is enabled and User-Agent Header is getting generated.

For information about the metrics, see Egress Gateway Metrics.

Alerts

There are no alerts generated for this feature.

Maintain

To resolve any alerts at the system or application level, see NSSF Alerts section. If the alerts persist, perform the following:

1. Collect the logs: For more information on how to collect logs, see Oracle Communications Cloud Native Core, Network Slice Selection Function Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

4.4 Ingress Gateway Pod Protection

This feature protects the Ingress Gateway pods from overloading due to uneven traffic distribution, traffic bursts, or congestion. During overload conditions, the Ingress Gateway pods may undergo stability issues. As a front end microservice for HTTP traffic, it is important for Ingress Gateway to have pod protection implemented.

The pod protection is performed based on the CPU consumption of the Ingress Gateway Pods as explained in the Congestion State Parameters. It is measured at different load states mentioned in the Ingress Gateway Load States.

Congestion State Parameters

In the Pod Protection feature, each Ingress Gateway microservice pod monitors its congestion state. This state is tracked in terms of CPU consumption, measured in nanoseconds, using Kubernetes cgroup (cpuacct.usage).

It is periodically monitored and calculated using the following formula. Then, it is compared against the CPU thresholds configured through the Rest API to determine the congestion state. For more information about the parameters, see Oracle Communications Cloud Native Core, Network Slice Selection Function REST Specification Guide.

Where,

CurrentCpuUsage is the counter reading at current periodic cycle.

LastCpuUsage is the counter reading at previous periodic cycle.

CurrentTime is the current time snapshot.

LastSampletime is the previous periodic cycle time snapshot.

CPUs is the total number of CPUs for a given pod.

Ingress Gateway Load States

The following states are used to detect overload conditions. This ensures the protection and mitigation of pods from entering an overload condition, while also facilitating necessary actions for recovery.

Note:

The transition can occur between any states based on the congestion parameters. The threshold for these congestion parameters is preconfigured and must not be changed.

• Congested State: This is the upper bound state where the pod is congested. This means one or more congestion parameters are above the configured thresholds for the congested state. For more information about the configuration using REST API, see Oracle Communications Cloud Native Core, Network Repository Function REST Specification Guide. The pod can be transitioned to the Congested State either from the Normal State or the DoC state. When the pod reaches this state, the following actions are performed:
  • new incoming HTTP2 connection requests are not accepted.
  • the pod gradually decrements the number of concurrent streams by updating SETTINGS_MAX_CONCURRENT_STREAMS parameter in a SETTINGS frame to the configured maxConcurrentStreamsPerCon value at a regular interval. The concurrent streams are decremented based on the value configured in decrementBy parameter. And, the regular interval is configured in the decrementSamplingPeriod parameter.
• Danger of Congestion (DOC): This is the intermediate state where the pod is approaching a congested state. This means if CPU is above the configured thresholds for the DoC state.
  • any new incoming HTTP2 connection requests are not accepted.
  • if the pod is transitioning from the Normal State to the DoC state, the pod gradually decrements the number of concurrent streams by updating SETTINGS_MAX_CONCURRENT_STREAMS parameter in a SETTINGS frame to the configured maxConcurrentStreamsPerCon value at a regular interval. The concurrent streams are decremented based on the value configured in decrementBy parameter. And, the regular interval is configured in the decrementSamplingPeriod parameter.
  • if the pod is transitioning from the Congested State to the DoC state, the pod gradually increments the number of concurrent streams by updating SETTINGS_MAX_CONCURRENT_STREAMS parameter in a SETTINGS frame to the configured maxConcurrentStreamsPerCon value at a regular interval. The concurrent streams are incremented based on the value configured in incrementBy parameter. And, the regular interval is configured in the incrementSamplingPeriod parameter.
• Normal State: This is the lower bound state where all the congestion parameters for the pod are below the configured thresholds for DoC and Congested states. When the pod reaches this state, the following actions are performed:
  • the pod will continue accepting new incoming HTTP2 connection requests.
  • the pod will continue accepting requests on the existing HTTP2 connections.
  • in case the pod is transitioning from the Congested or DoC state to Normal state, the pod gradually increments the number of concurrent streams by updating SETTINGS_MAX_CONCURRENT_STREAMS parameter in a SETTINGS frame to the configured maxConcurrentStreamsPerCon value at a regular interval. The concurrent streams are incremented based on the value configured in incrementBy parameter. And, the regular interval is configured in the incrementSamplingPeriod parameter.

To avoid toggling between these states due to traffic pattern, it is required for the pod to be in a particular state for a given period before transitioning to another state. The below configurations are used to define the period till which the pod has to be in a particular state:

• stateChangeSampleCount
• monitoringInterval

Formula for calculating the period is as follows:

(stateChangeSampleCount * monitoringInterval)

For more information about the configuration using REST API, see Oracle Communications Cloud Native Core, Network Slice Selection Function REST Specification Guide.

Managing Ingress Gateway Pod Protection

This section explains the procedure to enable and configure the feature.

Enable:

You can enable this feature using REST API. Perform the REST API configurations as explained below:

1. Use the API path as {apiRoot}/nf-common-component/v1/{serviceName}/podprotection.
2. Set enabled as true.
3. Set congestionControl.enabled to true.
4. Run the API using PUT method with the proposed values given in the Rest API. For more information about API path, see "Configurations to enable Ingress Gateway Pod Protection" section of "Ingress Gateway REST APIs" in Oracle Communications Cloud Native Core, Network Slice Selection Function REST Specification Guide.

   Given below is a sample REST API configuration to enable this feature:

   {
           "enabled": true,
           "monitoringInterval": 100,
           "congestionControl": {
               "enabled": true,
               "stateChangeSampleCount": 10,
               "actionSamplingPeriod": 3,
               "states": [
                   {
                       "name": "Normal",
                       "weight": 0,
                       "entryAction": [
                           {
                               "action": "MaxConcurrentStreamsUpdate",
                               "arguments": {
                                   "incrementBy": 30,
                                   "incrementByActionSamplingPeriod": 3,
                                   "maxConcurrentStreamsPerCon": 100
                               }
                           },
                           {
                               "action": "AcceptIncomingConnections",
                               "arguments": {
                                   "accept": true
                               }
                           }
                       ]
                   },
                   {
                       "name": "DoC",
                       "weight": 1,
                       "resourceThreshold": {
                           "cpu": 60,
                           "memory": 60,
                           "pendingMessage": 5000
                       },
                       "entryAction": [
                           {
                               "action": "AcceptIncomingConnections",
                               "arguments": {
                                   "accept": false
                               }
                           },
                           {
                               "action": "MaxConcurrentStreamsUpdate",
                               "arguments": {
                                   "incrementBy": 30,
                                   "incrementByActionSamplingPeriod": 3,
                                   "decrementBy": 30,
                                   "decrementByActionSamplingPeriod": 1,
                                   "maxConcurrentStreamsPerCon": 50
                               }
                           }
                       ]
                   },
                   {
                       "name": "Congested",
                       "weight": 2,
                       "resourceThreshold": {
                           "cpu": 75,
                           "memory": 75,
                           "pendingMessage": 7000
                       },
                       "entryAction": [
                           {
                               "action": "AcceptIncomingConnections",
                               "arguments": {
                                   "accept": false
                               }
                           },
                           {
                               "action": "MaxConcurrentStreamsUpdate",
                               "arguments": {
                                   "decrementBy": 30,
                                   "decrementByActionSamplingPeriod": 1,
                                   "maxConcurrentStreamsPerCon": 5
                               }
                           }
                       ]
                   }
               ]
           }
   }

Observe

Metrics

The following metrics are used to provide information about this feature:

• oc_ingressgateway_pod_congestion_state: It is used to track congestion state of a pod.
• oc_ingressgateway_pod_resource_stress: It tracks CPU, memory, and queue usage (as percentages) to determine the congestion state of the POD that is performing the calculations.
• oc_ingressgateway_pod_resource_state: It tracks the congestion state of individual resources, which is calculated based on their usage and the configured threshold.
• oc_ingressgateway_incoming_pod_connections_rejected_total: It tracks the number of connections dropped in the congested or Danger Of Congestion (DOC) state.

For information about the metrics, see Ingress Gateway Metrics.

Alerts

The following alerts generated for this feature:

• OcnssfIngressGatewayPodCongestionStateWarning
• OcnssfIngressGatewayPodCongestionStateMajor
• OcnssfIngressGatewayPodResourceStateWarning
• OcnssfIngressGatewayPodResourceStateMajor

For more information about alerts, see NSSF Alerts.

Maintain

To resolve any alerts at the system or application level, see NSSF Alerts section. If the alerts persist, perform the following:

1. Collect the logs: For more information on how to collect logs, see Oracle Communications Cloud Native Core, Network Slice Selection Function Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

4.5 Monitoring the Availability of SCPs using SCP Health APIs

With the introduction of this feature, NSSF determines the availability and reachability status of all the SCPs configured either statically by the operator or through DNS SRV based selection of the SCP sets. With this feature, NRF determines the availability and reachability status of all SCPs irrespective of the configuration types. This feature is an enhancement to the existing SBI routing functionality. Egress Gateway microservice interacts with SCP on their health API endpoints using HTTP2 OPTIONS method. It monitors the health of configured SCP peers to ensure that the traffic is routed directly to the healthy peers. This enhancement avoids routing or rerouting towards unhealthy peers, thus minimizing the latency time.

Egress Gateway microservice maintains the health status of all available and unavailable SCPs. It maintains the latest health of SCPs by periodically monitoring and uses this data to route egress traffic to the healthy SCP.

Note:

• This is not a standalone feature but an add-on to the existing SBI Routing feature, which means this feature is activated only if the SBI Routing feature is enabled.
• Health monitoring can only be enabled for the peers which belong to a peerset associated with a SBI Routing filter.

Managing Monitoring the Availability of SCPs using SCP Health APIs

Prerequisites

1. This feature works only when the SBI Routing feature is enabled. Health monitoring can only be enabled for the SCP peers which belong to a peer set associated with a SBI Routing filter. Not all peers are eligible for peer health monitoring.

   Note:

   For more information, see DNS SRV based selection of the SCP sets.
2. Set the value of sbiRoutingDefaultScheme as http.
3. Configure peerconfiguration to define the list of peers to which Egress Gateway can send request.
4. Configure peerSetConfiguration to logically group the peers into sets.

   Note:

   • peerIdentifier must be the value of SCP peer configured in peerConfiguration.
   • You cannot configure multiple virtual hosts as peers in the same peer set.
5. Configure or update errorcriteriasets.
6. Configure or update erroractionsets.
7. Configure the priority for each SCP peer in the set. Depending on the priority, it selects the primary, secondary, or tertiary SCP peers to route requests.
8. Configure RoutesConfiguration to add or update list of routes.

   Note:

   • The ID of each route must match the route ID present in Helm chart only if routeConfigMode is configured as HELM and sbiRoutingConfigMode is configured as REST.
   • The configuration under sbiRoutingConfiguration corresponds to the SBI-Routing specific configuration.
9. After above configurations, configure peermonitoringconfiguration to enable peer monitoring.

   Note:

   By default, peermonitoringconfiguration is set to false in ocnssf_custom_values_23.4.0.yaml file. Configure the value as true through REST API to enable peer monitoring.

Note:

For more information about the parameters, see "Egress Gateway Parameters" under "Customizing NSSF" in Oracle Communications Cloud Native Core, Network Slice Selection Function Installation, Upgrade, and Fault Recovery Guide, or see "Egress Gateway REST APIs" in Oracle Communications Cloud Native Core, Network Slice Selection Function REST Specification Guide for REST API based configurations.

Configure or Enable

Configure Using Helm

To enable this feature using Helm, configure the following Helm parameters in the ocnssf_custom_values_23.4.0.yaml file:

• peerConfiguration.healthApiPath
• peerMonitoringConfiguration.enabled
• peerMonitoringConfiguration.timeout
• peerMonitoringConfiguration.frequency
• peertMonitoringConfiguration.failureThreshold
• peerMonitoringConfiguration.successThreshold

Here is a snippet from the ocnssf_custom_values_23.4.0.yaml file for configuring this feature:

peerConfiguration:
      - id: peer1
        host: ocats-amf-stubserver.changeme-ocats
        port: 8080
        apiPrefix: "/"
        healthApiPath: "/health/v1"
...
peerMonitoringConfiguration:
     enabled: true
     timeout: 1000
     frequency: 20000
     failureThreshold: 3
     successThreshold: 4

Caution:

If you have enabled peermonitoringconfiguration using Helm by setting its value as true in the ocnssf_custom_values_23.4.0.yaml file, you cannot make any REST API configurations related to this feature.

For more information about the Helm parameters, see Oracle Communications Cloud Native Core, Network Slice Selection Function Installation, Upgrade, and Fault Recovery Guide.

Configure Using REST API

You can also enable this feature using the REST API configurations in the following sequence:

1. This feature works only when the SBI Routing feature is enabled. Health monitoring can only be enabled for the SCP peers which belong to a peer set associated with a SBI Routing filter. Not all peers are eligible for peer health monitoring.

   Note:

   For more information, see DNS SRV based selection of the SCP sets.
2. Configure peerconfiguration to define the list of peers to which Egress Gateway can send request.

   Note:

   peerconfiguration must consist of healthApiPath even though peermonitoringconfiguration is set to false in ocnssf_custom_values_23.4.0.yaml file by default.
3. Configure peersetconfiguration to logically group the peers into sets.

   Note:

   peerIdentifier must be the value of SCP peer configured in peerconfiguration.
4. Configure the priority for each SCP peer in the set. Depending on the priority, it selects the primary, secondary, or tertiary SCP peers to route requests.
5. Configure or update errorcriteriasets.
6. Configure or update erroractionsets.
7. Configure routesconfiguration to add or update list of routes.

   Note:

   • The ID of each route must match the route ID present in Helm chart only if routeConfigMode is configured as HELM and sbiRoutingConfigMode is configured as REST.
   • The configuration under sbiRoutingConfiguration corresponds to the SBI-Routing specific configuration.
8. After above configurations, configure peermonitoringconfiguration as true to enable peer monitoring. By default, peermonitoringconfiguration is set to false in Helm.

For more information about REST API configurations, see "Egress Gateway REST APIs" in Oracle Communications Cloud Native Core, Network Slice Selection Function REST Specification Guide.

Observe

Metrics

The following metrics are used to provide information about this feature:

• oc_egressgateway_peer_health_status
• oc_egressgateway_peer_health_ping_request_total
• oc_egressgateway_peer_health_ping_response_total
• oc_egressgateway_peer_health_status_transitions_total
• oc_egressgateway_peer_count
• oc_egressgateway_peer_available_count

For information about the metrics, see NSSF Metrics.

Alerts

The following alerts are applicable for this feature:

• OcnssfScpMarkedAsUnavailable
• OcnssfAllScpMarkedAsUnavailable

For more information about the alerts, see NSSF Alerts.

Maintain

To resolve any alerts at the system or application level, see NSSF Alerts section. If the alerts persist, perform the following:

1. Collect the logs: For more information on how to collect logs, see Oracle Communications Cloud Native Core, Network Slice Selection Function Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

4.6 Support for Kubernetes Resource

4.6.1 Network Policies

Network Policies are an application-centric construct that allows you to specify how a pod is allowed to communicate with various network entities. To control communication between the cluster's pods and services and to determine which pods and services can access one another inside the cluster, it creates pod-level rules.

Previously, NSSF had the privilege to communicate with other namespaces, and pods of one namespace could communicate with others without any restriction. Now, namespace-level isolation is provided for the NSSF pods, and some scope of communications is allowed between the NSSF and pods outside the cluster. The network policies enforces access restrictions for all the applicable data flows except communication from Kubernetes node to pod for invoking container probe.

Managing Support for Network Policies

Enable

To use this feature, network policies need to be applied to the namespace in which NSSF is deployed.

Configure

You can configure this feature using Helm. For information about configuring Network Policy, see Oracle Communications Cloud Native Core, Network Slice Selection Function Installation, Upgrade, and Fault Recovery Guide.

Observe

here is no specific metrics and alerts required for the Network Policy feature.

4.7 Validation of WWW-Authenticate Response Header 4xx with NSSF

When access token validation is enabled, NSSF performs access-token validation of the access token that comes with service requests to it. With this enhancement, NSSF has added supports 3GPP specified 4XX application error codes for these access token checks.

The access token validation include the following checks:

1. Validating if access token is present in the service request: If the access token is not present, NSSF returns 401 unauthorized error code together with the "WWW-Authenticate" header as specified in 3GPP 16.5 29.531.
2. Validating if access token does not have the required scopes to invoke the service operation: NSSF validates the scope IE in AccessTokenClaims (which is the name of the NSSF services for which the access token is authorized) against the NSSF Service that are accessed in this service request. If the validation fails, NSSF returns a 403 Forbidden error code together with the "WWW-Authenticate" header as specified in 3GPP 16.5 29.531.

Managing Validation of WWW-Authenticate Response Header 4xx with NSSF

Enable

This feature does not require any configuration. It is enabled by default when the NSSF is installed.

Maintain

To resolve any alerts at the system or application level, see NSSF Alerts section. If the alerts persist, perform the following:

1. Collect the logs: For more information on how to collect logs, see Oracle Communications Cloud Native Core, Network Slice Selection Function Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

4.8 Deleting Subscription on 404 SUBSCRIPITON_NOT_FOUND Response from AMF

This feature is an enhancement to the existing behavior of NSSF Notify Service Operation, which is used to update the NF Service Consumer (for example, AMF) of any change in status. It is done on a per TA basis for the S-NSSAIs available (unrestricted and restricted) per PLMN in the TA of a UE's serving PLMN.

Upon receiving a failure, the NF service consumer (AMF) returns some HTTP status codes and NSSF retries the notification until it reaches the value of the httpMaxRetries or a success response is received from the AMF. However, this behavior is not suitable when it comes to '404 Subscription Not Found' failure. Waiting for the value of the httpMaxRetries to get exhausted will only create an unproductive delay.

When this feature is enabled, it eliminates the delay by simply logging the error and deleting the subscription when the AMF sends a '404 Subscription Not Found' response.

Note:

This behavior is applicable only when AMF responds with the '404 Subscription Not Found' error. It is not applicable to other failure scenarios.

Managing Deleting Subscription on 404 SUBSCRIPITON_NOT_FOUND Response from AMF

Enable

To enable this feature, set the value of deleteOnSubscriptionNotFound parameter to true under the NSSubscription section in the ocnssf_custom_values_23.4.0.yaml file.

Observe

Metrics

The following metrics are used to provide information about this feature:

• ocnssf_nssaiavailability_notification_delete_on_subscription_not_found
• ocnssf_nssaiavailability_notification_db_error

For information about the Metrics, see NSSF Metrics.

Error Scenarios

The following error logs are generated for this feature:

Table 4-1 Error Scenarios

Scenario	Microservice	Request URL	Response Code/ Error Title	Log Snippet
Parameter deleteOnSubscriptionNotFound is true but unable to delete NssaiSubscription	NsSubscription	/nnssf-nssubscription/v1/nssai-availability/autoconfignotifications /nnssf-nssubscription/v1/nssai-availability/notifications	404 SUBSCRIPTION_NOT_FOUND	{ "instant": { "epochSecond": 1661327119, "nanoOfSecond": 10456886 }, "thread": "thread-1", "level": "ERROR", "loggerName": "com.oracle.cgbu.cne.nssf.nsselection.service.NsSubscriptionServiceImpl", "message": "Failed to delete NssaiSubscribtion with ID: 1830762826", "endOfBatch": false, "loggerFqcn": "org.apache.logging.log4j.spi.AbstractLogger", "contextMap": {}, "threadId": 54, "threadPriority": 5, "ts": "2022-08-24 07:45:19.010+0000", "ocLogId": "${ctx:ocLogId}", "pod": "ocnssf-nssubscription-5f7bbbffbc-hxsfc", "processId": "1", "vendor": "Oracle", "application": "ocnssf", "engVersion": "22.3.0", "mktgVersion": "22.3.0.0.0", "microservice": "nssubscription", "namespace": "ocnssf", "node_name": "jazz-k8s-node-8" }
NsSubcription recieves 404 SUBSCRIPTION_NOT_FOUND from client, Param deleteOnSubscriptionNotFound is true hence NssaiSubscription is deleted	NsSubscription	/nnssf-nssubscription/v1/nssai-availability/autoconfignotifications OR /nnssf-nssubscription/v1/nssai-availability/notifications	404 SUBSCRIPTION_NOT_FOUND	{ "instant": { "epochSecond": 1679654802, "nanoOfSecond": 234222276 }, "thread": "task-3", "level": "ERROR", "loggerName": "com.oracle.cgbu.cne.nssf.nssubscription.service.NsSubscriptionService", "message": "Recieved 404 SUBSCRIPTION_NOT_FOUND from http://ocats-amf-stubserver.ocnssf:8080/notification/amf404/, subscriptionId = 402778803, deleteOnSubscriptionNotFound = true, response = NssfRestClientResponse{response=Response{protocol=h2_prior_knowledge, code=404, message=, url=http://ocnssf-egress-gateway:8080/OC_Notify/notification/amf404/}, responseBody='{\"type\": \"NOT_FOUND\", \"title\": \"SUBSCRIPTION_NOT_FOUND\", \"status\": 404, \"detail\": \"subscription not found\", \"cause\": \"SUBSCRIPTION_NOT_FOUND\"}', messageCode=REMOTE_SERVER_EXCEPTION, eventTriggerSubMapId=0, attemptNum=0}", "endOfBatch": false, "loggerFqcn": "org.apache.logging.log4j.spi.AbstractLogger", "contextMap": {}, "threadId": 760, "threadPriority": 5, "ts": "2023-03-24 10:46:42.234+0000", "ocLogId": "${ctx:ocLogId}", "pod": "ocnssf-nssubscription-6d86c4d686-jbxjz", "processId": "1", "vendor": "Oracle", "application": "ocnssf", "engVersion": "23.1.1-rc.2", "mktgVersion": "23.1.1-rc.2.0.0", "microservice": "nssubscription", "namespace": "ocnssf", "node_name": "100.77.28.82" } { "instant": { "epochSecond": 1679654802, "nanoOfSecond": 408253432 }, "thread": "XNIO-1 task-1", "level": "INFO", "loggerName": "com.oracle.cgbu.cne.nssf.nssubscription.helper.HelperFunctions", "message": "Successfully deleted Subscription with ID: 402778803", "endOfBatch": false, "loggerFqcn": "org.apache.logging.log4j.spi.AbstractLogger", "contextMap": {}, "threadId": 39, "threadPriority": 5, "ts": "2023-03-24 10:46:42.408+0000", "ocLogId": "${ctx:ocLogId}", "pod": "ocnssf-nssubscription-6d86c4d686-jbxjz", "processId": "1", "vendor": "Oracle", "application": "ocnssf", "engVersion": "23.1.1-rc.2", "mktgVersion": "23.1.1-rc.2.0.0", "microservice": "nssubscription", "namespace": "ocnssf", "node_name": "100.77.28.82" }
NsSubcription recieves 404 SUBSCRIPTION_NOT_FOUND from client, Param deleteOnSubscriptionNotFound is false hence NssaiSubscription is not deleted	NsSubscription	/nnssf-nssubscription/v1/nssai-availability/autoconfignotifications OR /nnssf-nssubscription/v1/nssai-availability/notifications	404 SUBSCRIPTION_NOT_FOUND	{ "instant": { "epochSecond": 1679655373, "nanoOfSecond": 880206537 }, "thread": "task-1", "level": "ERROR", "loggerName": "com.oracle.cgbu.cne.nssf.nssubscription.service.NsSubscriptionService", "message": "Recieved 404 SUBSCRIPTION_NOT_FOUND from http://ocats-amf-stubserver.devnssf-hrithik:8080/notification/amf404/, subscriptionId = 1871925794, deleteOnSubscriptionNotFound = false, response = NssfRestClientResponse{response=Response{protocol=h2_prior_knowledge, code=404, message=, url=http://ocnssf-egress-gateway:8080/OC_Notify/notification/amf404/}, responseBody='{\"type\": \"NOT_FOUND\", \"title\": \"SUBSCRIPTION_NOT_FOUND\", \"status\": 404, \"detail\": \"subscription not found\", \"cause\": \"SUBSCRIPTION_NOT_FOUND\"}', messageCode=REMOTE_SERVER_EXCEPTION, eventTriggerSubMapId=0, attemptNum=0}", "endOfBatch": false, "loggerFqcn": "org.apache.logging.log4j.spi.AbstractLogger", "contextMap": {}, "threadId": 40, "threadPriority": 5, "ts": "2023-03-24 10:56:13.880+0000", "ocLogId": "${ctx:ocLogId}", "pod": "ocnssf-nssubscription-9f68d8bc9-xsm22", "processId": "1", "vendor": "Oracle", "application": "ocnssf", "engVersion": "23.1.1-rc.2", "mktgVersion": "23.1.1-rc.2.0.0", "microservice": "nssubscription", "namespace": "ocnssf", "node_name": "100.77.50.225" } { "instant": { "epochSecond": 1679655373, "nanoOfSecond": 908894025 }, "thread": "XNIO-1 task-1", "level": "ERROR", "loggerName": "com.oracle.cgbu.cne.nssf.nssubscription.service.NsSubscriptionService", "message": "Not deleted NssaiSubscribtion with ID: 1871925794", "endOfBatch": false, "loggerFqcn": "org.apache.logging.log4j.spi.AbstractLogger", "contextMap": {}, "threadId": 39, "threadPriority": 5, "ts": "2023-03-24 10:56:13.908+0000", "ocLogId": "${ctx:ocLogId}", "pod": "ocnssf-nssubscription-9f68d8bc9-xsm22", "processId": "1", "vendor": "Oracle", "application": "ocnssf", "engVersion": "23.1.1-rc.2", "mktgVersion": "23.1.1-rc.2.0.0", "microservice": "nssubscription", "namespace": "ocnssf", "node_name": "100.77.50.225" }

Maintain

To resolve any alerts at the system or application level, see NSSF Alerts section. If the alerts persist, perform the following:

1. Collect the logs: For more information on how to collect logs, see Oracle Communications Cloud Native Core, Network Slice Selection Function Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

4.9 DNS SRV Based Selection of SCP in NSSF

NSSF selects Service Communication Proxy (SCP) for indirect communication of notifications using the static configurations done by the operator. This enhancement enables NSSF to learn SCP configuration from DNS SRV based FQDN, in addition to the already existing static manual configuration by the operator.

Egress Gateway (Egress Gateway) supports AlternateRoute Service, which NSSF is using to support DNS SRV based selection of SCP. It enables NSSF to resolve FQDN or Virtual FQDN to alternate FQDNs of SCP. Egress Gateway uses the virtual FQDN of SCP instances to query the AlternateRoute Service and get the list of alternate FQDNs with priorities assigned to each of them. Based on the priorities, Egress Gateway picks up the SCP instances for rerouting attempts.

The AlternateRoute Service allows the configuration of multiple sets of SCP instances in NSSF in contrast to only one static configuration in the previous scenario.

Managing DNS SRV Based Selection of SCP in NSSF

Enable

To enable DNS SRV, set the dnsSrvEnabled parameter to true under the alternate-route section in the ocnssf_custom_values_23.4.0.yaml file.

Configure

Configure Using Helm Parameters:

DNS SRV is enabled using the Helm configurations in the ocnssf_custom_values_23.4.0.yaml as shown below:

• dnsSrvEnabled: true
• dnsSrvFqdnSetting.enabled: false

  Note:

  Flag to enable or disable the usage of custom patterns for the FQDN while triggering DNS-SRV query.
• dnsSrvFqdnSetting.pattern: "_{scheme}._tcp.{fqdn}."
• sbiRoutingConfigMode: HELM
• routeConfigMode: HELM

Note:

By default, the values of sbiRoutingConfigMode and routeConfigMode are set to REST in the ocnssf_custom_values_23.4.0.yaml file. To configure this feature using Helm, ensure that the values are set to HELM as shown above.

For more information about Helm parameters to configure DNS SRV and Alternate Routing Service, see "Alternate Route Microservice Parameters section" in Oracle Communications Cloud Native Core, Network Slice Selection Function Installation, Upgrade, and Fault Recovery Guide.

Configure Using REST API:

The feature related REST API configurations are performed at NSSF and Egress Gateway.

1. Ensure that the value of routeConfigMode and sbiRoutingConfigMode is set to REST in the ocnssf_custom_values_23.4.0.yaml file, as shown below:

   
   sbiRoutingConfigMode: REST
   routeConfigMode: REST

   Note:

   By default, it is set to REST.
2. Perform REST API configurations at Egress Gateway in the following sequence:
   1. Configure peerconfiguration to define the list of peers to which Egress Gateway can send request.

      Note:

      It is mandatory to configure peerconfiguration with healthApiPath if you want to enable peermonitoringconfiguration.
   2. Configure virtualHost under peerconfiguration where the AMF query is sent.
   3. Configure peersetconfiguration to logically group the peers into sets.

      peerIdentifier must be the value of peer configured in peerconfiguration

      Note:

      You cannot configure multiple virtual hosts as peers in the same peer set.
   4. Configure the Priority for each peer in the set. Depending on the priority, it selects the primary, secondary, or tertiary peers to route requests.
   5. Configure or update errorcriteriasets.
   6. Configure or update erroractionsets.
   7. Configure routesconfiguration to define the route and reroute parameters. If SBIRouting functionality is required, then configure SBIRoutingFilter. If reroute mechanism is required for that route, then configure SBIReroute filter with retries, methods, and statuses.

      Note:

      peerSetIdentifier must be the value configured during peersetconfiguration.
   8. Set the value of enabled under sbiRoutingConfiguration to true to route the AMF queries through SCP configured in the id attribute.

      Note:

      peerconfiguration and peersetconfiguration can be either set to empty list or populated with values. These attributes are used for routing only if sbiRoutingConfiguration is enabled for a particular route.
   9. <Optional> You can also configure peermonitoringconfiguration using REST API. For more information about enabling or configuring peermonitoringconfiguration, see Monitoring the Availability of SCPs using SCP Health APIs.

      Note:

      It is mandatory to configure peerconfiguration with healthApiPath if peermonitoringconfiguration is enabled.
3. Perform the following REST API configurations at NSSF:
   1. Configure the nssaiauth Managed Object to enable the configuration of network slice authentication rules by configuring Grant status (Allowed_PLMN, Rejected_PLMN, or Rejected_TAC) for S-NSSAI on a per TAI basis.

For more information about REST API parameters and configuration, see Oracle Communications Cloud Native Core, Network Slice Selection Function REST Specification Guide.

Observe

Metrics

No new Metrics or KPIs were added to NSSF. However, the following Egress Gateway metrics for Alternate Route Service are used to provide the information about this feature:

• oc_fqdn_alternate_route_total
• oc_dns_srv_lookup_total
• oc_alternate_route_resultset
• oc_configclient_request_total
• oc_configclient_response_total

For information about the Metrics, see Egress Gateway Metrics in NSSF Metrics.

Error Scenarios

No new logs are generated for this feature. However, it uses the following Egress Gateway error scenarios:

Table 4-2 Error Scenarios

Scenario	Microservice	Request URL	Response Code/ Error Title	Log Snippet
Sending Subscription notification failed due to UnknownHost exception	ocnssf-egress-gateway	/nnssf-configuration/v1/nssaiauth	503 Service Unavailable Encountered unknown host exception at Egress Gateway	{ "instant": { "epochSecond": 1676964069, "nanoOfSecond": 986866249 }, "thread": "@6c8fe7a4-217", "level": "ERROR", "loggerName": "ocpm.cne.gateway.jettyclient.DnsResolver", "message": "UnExpected error occured :: {}", "thrown": { "commonElementCount": 0, "localizedMessage": "ocats-amf-stubserver.ocnssf: Name or service not known", "message": "ocats-amf-stubserver.ocnssf:Name or service not known", "name": "java.net.UnknownHostException", "extendedStackTrace": [ { "class": "java.net.Inet6AddressImpl", "method": "lookupAllHostAddr", "file": "Inet6AddressImpl.java", "line": -2, "exact": false, "location": "?", "version": "?" }, { "class": "java.net.InetAddress$PlatformNameService", "method": "lookupAllHostAddr", "file": "InetAddress.java", "lin e": 933, "exact": false, "location": "?", "version": "?" } ] }, "endOfBatch": false, "loggerFqcn": "org.apache.logging.log4j.spi.AbstractLogger", "contextMap": {}, "threadId": 217, "thread Priority": 5, "messageTimestamp": "2023-02-21T07:21:09.986+0000", "ocLogId": "${ctx:ocLogId}", "pod": "${ctx:hostname}", "processId": "1", "instanceType": "prod", "egressTxId": "${ctx:egressTxId}" }

Maintain

To resolve any alerts at the system or application level, see NSSF Alerts section. If the alerts persist, perform the following:

1. Collect the logs: For more information on how to collect logs, see Oracle Communications Cloud Native Core, Network Slice Selection Function Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

4.10 OAuth Access Token Based Authorization

NSSF supports Oauth 2.0, which is a security feature that NSSF uses to validate and authorize requests from allowed or valid consumers NFs. The consumer NF requests for access token from the issuer NRF, and uses this access token to send the request to NSSF. NSSF validates the requests and approves or discards it based on access token authorization received in the request. The access token is validated with the configured public key certificate in NSSF.

Before this enhancement, NSSF used NRF Instance ID to validate the access token, where Ingress Gateway stored public keys against NRF instance Id. This enhancement allows NSSF to use multiple public certificates for validating access tokens by adding support for Key-ID (K-ID) based access token validation, in addition to the existing NRF Instance ID based access token validation.

This enhancement now allows Ingress Gateway to operate in the following three different modes:

1. K-ID based ONLY
   1. Ingress Gateway validates access token based on public keys indexed with key-id only.
2. Instance ID based ONLY (DEFAULT)
   1. Ingress Gateway validates access token based on public keys indexed with NRF Instance ID in the issuer field.
3. K-ID based with Instance ID based as fallback (KID_PREFERRED)
   1. Ingress Gateway validates access token based on public keys indexed with Key-ID. If Key-ID is not FOUND in Access token, Ingress Gateway attempts token validation using public keys indexed with NRF instance ID in the issuer field.
   2. Fallback happens only if the received access token is structured as follows:
      1. Does not contain Key-ID
      2. Contains Key-ID but does not have public keys configured against the Key-ID

Managing OAuth Access Token Based Authorization Using Key-ID and NRF Instance ID

Prerequisites

This section describes the configurations required to enable access tokens before deploying NSSF.

Generating KeyPairs for NRF Instances

Note:

It is at the discretion of the user to create private keys and certificates, and it is not in the scope of NSSF. This section lists only samples to create KeyPairs.

Using the OpenSSL tool, the user can generate private key and public certificates. The commands to generate the KeyPairs are as follows:

Example Command to generate KeyPair for NRF Instance

openssl ecparam -genkey -name prime256v1 -noout -out ec_private_key1.pem

openssl pkcs8 -topk8 -in ec_private_key1.pem -inform pem -out ec_private_key_pkcs8.pem -outform pem -nocrypt

openssl req -new -key ec_private_key_pkcs8.pem -x509 -nodes -days 365 -out 4bc0c762-0212-416a-bd94-b7f1fb348bd4.crt -subj "/C=IN/ST=KA/L=BLR/O=ORACLE/OU=CGBU/CN=ocnrf-endpoint.ocnrf.svc.cluster.local"

Note:

For ATS configuration details, see Configurations to Enable Access Token in Preinstallation Tasks of Cloud Native Core Network Slice Selection Function Installation and Upgrade Guide.

Enabling and Configuring Access Token

To enable access token validation, configure both Helm-based and REST-based configurations on Ingress Gateway.

Configuration using Helm:

For Helm-based configuration, perform the following steps:

1. Create a secret that stores NRF public key certificates using the following commands:

   kubectl create secret generic <secret name> --from-file=<filename.crt> -n <Namespace>

   For Example:

   kubectl create secret generic oauthsecret --from-file=4bc0c762-0212-416a-bd94-b7f1fb348bd4.crt -n ocnssf

   Note:

   In the above command:

   • oauthsecret is the secret name
   • ocnssf is the namespace
   • 4bc0c762-0212-416a-bd94-b7f1fb348bd4.crt is the public key certificate
2. Enable the oauthValidatorEnabled parameter on Ingress Gateway by setting its value to true. Further, configure the secret and namespace on Ingress Gateway in the OAUTH CONFIGURATION section of the ocnssf_custom_values_23.4.0.yaml file using the following fields:
   • oauthValidatorEnabled
   • nfType
   • nfInstanceId
   • producerScope
   • allowedClockSkewSeconds
   • enableInstanceIdConfigHook
   • nrfPublicKeyKubeSecret
   • nrfPublicKeyKubeNamespace
   • validationType
   • producerPlmnMNC
   • producerPlmnMCC
   • oauthErrorConfigForValidationFailure
   • oauthErrorConfigForValidationFailure.errorCode
   • oauthErrorConfigForValidationFailure.errorTitle
   • oauthErrorConfigForValidationFailure.errorDescription
   • oauthErrorConfigForValidationFailure.errorCause
   • oauthErrorConfigForValidationFailure.redirectUrl
   • oauthErrorConfigForValidationFailure.retryAfter
   • oauthErrorConfigForValidationFailure.errorTrigger
   • oauthErrorConfigForValidationFailure.errorTrigger.exceptionType

   Note:

   4bc0c762-0212-416a-bd94-b7f1fb348bd4.crt is the public key certificate and we can have any number of certificates in the secret.
   The following snippet represents the location of the mentioned parameter in the Helm file:

   Note:

   The following snippet represents only the sample values. For more information on parameters and their supported values, see Ingress Gateway Parameters from Customizing NSSF chapter in Oracle Communications Cloud Native Core, Network Slice Selection Function Installation, Upgrade, and Fault Recovery Guide.

   #OAUTH CONFIGURATION
   
     oauthValidatorEnabled: true
   
     nfType: NSSF
   
     nfInstanceId: 9faf1bbc-6e4a-4454-a507-aef01a101a01
   
     producerScope: nnssf-configuration
   
     allowedClockSkewSeconds: 0
   
     enableInstanceIdConfigHook: true
   
     nrfPublicKeyKubeSecret: oauthsecret
   
     nrfPublicKeyKubeNamespace: ocnssf
   
     validationType: strict
   
     producerPlmnMNC: 14
   
     producerPlmnMCC: 310
   
     oauthErrorConfigForValidationFailure:
   
       errorCode: 401
   
       errorTitle: "Validation failure"
   
       errorDescription: "UNAUTHORIZED"
   
       errorCause: "oAuth access Token validation failed"
   
       redirectUrl:
   
       retryAfter:
   
       errorTrigger:
   
       - exceptionType: OAUTH_CERT_EXPIRED
   
         errorCode: 408
   
         errorCause: certificate has expired
   
         errorTitle:
   
         errorDescription:
   
         retryAfter:
   
         redirectUrl:- exceptionType: OAUTH_MISMATCH_IN_KID
   
         errorCode: 407
   
         errorCause: kid configured does not match with the one present in the token
   
         errorTitle:
   
         errorDescription:
   
         retryAfter:
   
         redirectUrl:
   
       - exceptionType: OAUTH_PRODUCER_SCOPE_NOT_PRESENT
   
         errorCode: 406
   
         errorCause: producer scope is not present in token
   
         errorTitle:
   
         errorDescription:
   
         retryAfter:
   
         redirectUrl:
   
       - exceptionType: OAUTH_PRODUCER_SCOPE_MISMATCH
   
         errorCode: 405
   
         errorCause: produce scope in token does not match with the configuration
   
         errorTitle:
   
         errorDescription:
   
         retryAfter:
   
         redirectUrl:
   
       - exceptionType: OAUTH_MISMATCH_IN_NRF_INSTANCEID
   
         errorCode: 404
   
         errorCause: nrf id configured does not match with the one present in the token
   
         errorTitle:
   
         errorDescription:
   
         retryAfter:
   
         redirectUrl: - exceptionType: OAUTH_PRODUCER_PLMNID_MISMATCH
   
         errorCode: 403
   
         errorCause: producer plmn id in token does not match with the configuration
   
         errorTitle:
   
         errorDescription:
   
         retryAfter:
   
         redirectUrl:
   
       - exceptionType: OAUTH_AUDIENCE_NOT_PRESENT_OR_INVALID
   
         errorCode: 402
   
         errorCause: audience in token does not match with the configuration
   
         errorTitle:
   
         errorDescription:
   
         retryAfter:
   
         redirectUrl:
   
       - exceptionType: OAUTH_TOKEN_INVALID
   
         errorCode: 401
   
         errorCause: oauth token is corrupted
   
         errorTitle:
   
         errorDescription:
   
         retryAfter:
   
    redirectUrl:oauthErrorConfigOnTokenAbsence:
   
       errorCode: 400
   
       errorTitle: "Token not present"
   
       errorDescription: "UNAUTHORIZED"
   
       errorCause: "oAuth access Token is not present"
   
       redirectUrl:
   
       retryAfter:

Configuration using REST API

After Helm configuration, send the REST requests to use configured public key certificates. Using REST-based configuration, you can distinguish between the certificates configured on different NRFs and can use these certificates to validate the token received from a specific NRF.

For more information about REST API configuration, see OAuth Validator Configuration section in Oracle Communications Cloud Native Core, Network Slice Selection Function REST Specification Guide.

Observe

• Added the following success measurements:
  • oc_oauth_nrf_request_total
  • oc_oauth_nrf_response_success_total
  • oc_oauth_token_cache_total
  • oc_oauth_validation_successful_total
  • oc_oauth_cert_expiryStatus
  • oc_oauth_cert_loadStatus
  • oc.oauth.keyid.count
• Added the following error measurements:
  • oc_oauth_nrf_response_failure_total
  • oc_oauth_request_failed_internal_total
  • oc_oauth_request_invalid_total
  • oc_oauth_validation_failure_total
  • oc.oauth.request.failed.cert.expiry

For information on Metrics and KPIs of NSSF, see NSSF Metrics and NSSF KPIs sections respectively.

Maintain

To resolve any alerts at the system or application level, see NSSF Alerts section. If the alerts persist, perform the following:

1. Collect the logs: For more information on how to collect logs, see Oracle Communications Cloud Native Core, Network Slice Selection Function Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

4.11 Overload Control based on Percentage Discards

The Overload Control feature protects the system from overload and maintains the overall health of NSSF. The system needs to not only detect overload conditions but also protect against the same. Further, it needs to mitigate against and avoid the system from entering into an overload condition by taking necessary actions for recovering from overload.

NSSF provides the following means for overload management:

• Predefined threshold load levels
• Tracks number of pending messages
• Tracks CPU and memory usage
• Enforce load shedding during various overload levels

Perf-info performs overload calculations based on the indicators:

• CPU Utilization
• Memory Utilization
• Pending Message Count
• Failure Count

The overload level is configured for the following NRF microservices:

• NSSelection
• NSAvailability

The Overload Manager module in Perf-info is configured or updated with the threshold value for services. A configurable flag is available for sampling interval as ocPolicyMapping.samplingPeriod based on which Ingress Gateway calculates rate per service in the current sampling period and applies appropriate discard policies and actions in the subsequent sampling period.

Overload Manager triggers Rate Calculator to start calculating the rate of incoming requests per service per sampling period. Ingress Gateway receives a notification event per service with the calculated rates to the Overload Manager filter at the end of every sampling period. It applies an appropriate configured discard policy for a particular service based on the rate of requests.

Ingress Gateway calculates the number of requests to be dropped in the current sampling period based on configured percentage discard.

Overload Thresholds for each service is evaluated based on four metrics namely cpu, svc_failure_count, svc_pending_count, and memory. Overload control is triggered if the thresholds for any one metrics are reached.

Managing Overload Control based on Percentage Discards

Enable

To enable this feature, set the global.performanceServiceEnable parameter to true in the ocnssf_custom_values_23.4.0.yaml file.

The following snippet represents the location of the mentioned parameter in the Helm file:

#Flag to Enable or Disable Performance Service. The flag is set to true to enable the overload control feature by default.
  performanceServiceEnable: true

Configure

Configure using Helm Parameters:

1. Set the perf-info.overloadManager.enabled parameter to true in the ocnssf_custom_values_23.4.0.yaml file.
   The following snippet represents the location of the mentioned parameter in the Helm file:

   overloadManager:
      ingressGatewayPort: *httpSignalPort
      #Flag to Enable or Disable overloadManager
      enabled: true

2. Configure the Prometheus URI in perf-info.configmapPerformance.prometheus
   The following snippet represents the location of the mentioned parameter in the Helm file:

   perf-info
     configmapPerformance:
       prometheus: http://occne-prometheus-server.occne-infra:80

3. Save the ocnssf_custom_values_23.4.0.yaml file.
4. Run helm upgrade, if you are enabling this feature after NSSF deployment. For more information on upgrade procedure, see Oracle Communications Cloud Native Core, Network Slice Selection Function Installation and Upgrade Guide.

Configure using REST API:

The Overload Control feature related configurations are performed at Ingress Gateway and Perf-info. For more information about APIs, see Oracle Communications Cloud Native Core, Network Slice Selection Function REST Specification Guide

Note:

There are no REST configurations required at NSSF.

Configure using CNC Console:

There are no CNC Console configurations for this feature.

Observe

Metrics

No new metrics added to NSSF for the Overload Control feature. However, the following Perf-info metrics are used to provide the information about overload control feature:

• cgroup_cpu_nanoseconds
• cgroup_memory_bytes
• load_level

For information about Metrics, see Perf-info metrics for Overload Control in NSSF Metrics.

For information on Metrics and KPIs of NSSF, see NSSF Metrics and NSSF KPIs sections respectively.

Alerts

The following alerts are added for the Overload Control feature:

• OcnssfOverloadThresholdBreachedL1
• OcnssfOverloadThresholdBreachedL2
• OcnssfOverloadThresholdBreachedL3
• OcnssfOverloadThresholdBreachedL4

Maintain

To resolve any alerts at the system or application level, see NSSF Alerts section. If the alerts persist, perform the following:

1. Collect the logs: For more information on how to collect logs, see Oracle Communications Cloud Native Core, Network Slice Selection Function Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

4.12 Autopopulation of Configuration Using NRF Content

NSSF responds with CandidateAMFList (list of possible AMFs ) to Initial Registration request. Currently, the computation of active AMFs in AMF Set is done by one of the following methods:

• Discovery: For each registration NSSF sends a discovery message to NRF to get all active AMFs in a AMF-Set.
• Operator configuration: The operator has to ensure that all active AMFs are mapped to the AMF Set.

NSSF must maintain the information about AMF Set to AMF mapping in the database as it uses this information while responding to NSSelection initial registration query.

Before this enhancement, the operator was required to maintain this information manually in the database. This enhancement removes the need for the manual configuration by allowing NSSF to autoconfigure AMF information using NRF (Network Repository Function) whenever there is an update in the AMF Set data. NSSF automatically determines AMF information in a AMF-Set and autopopulate NSSF configuration using the information from NRF.

1. For each initial registration, NSSF sends a discovery message to NRF to get AMFs in a AMF-Set.
2. NSSF maintains AMF-Set (MCC-MNC-SetId-RegionId) to AMF list (List of AMFs, which belong to a AMF-Set in NSSF DB) mapping.
   1. Subscription based on AMF-Set: NSSF sends a discovery and subscribe request to NRF based ontheAMF-Set configured by the operator and maintain AMF-Set to AMFs mapping in NSSF Database.

Hence, operator is now required to configure only AMF set. The information about active amfs are maintained by NSSF, as it is autoconfigured using NRF content. This resolves the issue of stale configuration and NSSF does not have to send discovery for each initial registration request, saving CPU and network bandwidth.

Managing Autopopulation of Configuration Using NRF Content

Enable

This section provides the procedure to enable this feature:

1. Set the nsconfig.nrf.subscription parameter to true in the ocnssf_custom_values_23.4.0.yaml file.
   The following snippet represents the location of the mentioned parameter in the Helm file:

   nsconfig:
       nrf:
       subscription: false # Flag to enable Subscriptions towards NRF for AmfSet

2. Set the nsselection.features.candidateResolution parameter to true in the ocnssf_custom_values_23.4.0.yaml file.
   The following snippet represents the location of the mentioned parameter in the Helm file:

   nsselection:
       features:
       candidateResolution : false #Flag to true and false to enable or disable Candidate Resolution feature

Note:

• When this feature is set to false, NSSF returns TargetAMFSetId and TargetAMFRegionId for NSSelection GET request for Initial Register message and UE-Config update.
• When this feature is set to true, NSSF computes and returns Candidate AMF list for NSSelection GET request for Initial Register message and UE-Config update.

Configure

Configure using Helm Parameters:

No additional helm configuration is required to enable this feature.

Configure using REST API:

There is no option to enable or disable this feature using REST API configuration.

However, this feature will use existing AMF set and NSI-Profile REST APIs configurations if nsconfig.nrf.subscription is set to true in the ocnssf_custom_values_23.4.0.yaml file.

Note:

• When nsconfig.nrf.subscription is set to true ocnssf_custom_values_23.4.0.yaml file, even if corresponding AMF set is not configured for an NSI-Profile, this feature will work.
• For more information on REST APIs, see Oracle Communications Cloud Native Core, REST API Guide.

Configure using CNC Console:

There are no CNC Console configurations for this feature.

Observe

Metrics

Added the following success measurements:

• ocnssf_nsconfig_nrf_disc_success
• ocnssf_subscription_nrf_tx

Added the following error measurements:

• ocnssf_nsconfig_nrf_disc_error
• ocnssf_discovery_nrf_tx_failed
• ocnssf_subscription_nrf_tx_failed

For information on Metrics and KPIs of NSSF, see NSSF Metrics and NSSF KPIs sections respectively.

Alerts

There are no new alerts for this feature.

Maintain

To resolve any alerts at the system or application level, see NSSF Alerts section. If the alerts persist, perform the following:

1. Collect the logs: For more information on how to collect logs, see Oracle Communications Cloud Native Core, Network Slice Selection Function Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

4.13 Auto-Population of Configuration Based on NSAvailability Update

AMF updates supported S-NSSAI for NSSF on a per TA basis using NSAvailability data. NSSF uses this data to update its configuration as per operator's configuration.

Currently, the data received from Nnssf_NSSAIAvailability update is not replicated to the provisional configuration (site-specific database). However, the data are crucial, as they are used in Nnssf_NSSelection service's operations. It is mandatory for an operator to configure NSAvailability data for each location that NSSF supports, or all S-NSSAIs that NSSF supports or restricts. The operator is required to configure not only the allowed S-NSSAI information from the AMF but also the restricted S-NSSAIs per TAC per PLMN. It can be done using CNC Console or REST based methods.

After this enhancement, the operator need not to configure the allowed S-NSSAIs, as it will be updated automatically based on the NSAvailability update from the AMF. However, the operator still needs to configure the restricted S-NSSAI information per TAC per PLMN, as it is not a part of the NSAvailability update.

Further, it allows NSSF to do following tasks in the NSAvailability update:

• Configure nssai_auth: If S-NSSAI is not already configured in nssai_auth table for that TAI, irrespective of the Grant Allowed, NSSF creates S-NSSAI entry on nssai_auth table.
• Configure nss_rule: If S-NSSAI is supported in one TAI, NSSF it configures an nssai_auth. Otherwise, NSSF configures an nss_rule for the accessType 3GPP.
• Delete S-NSSAI entry: When an AMF sends a delete request on NSAvailability update, NSSF checks if the AMF in the particular region supports the given S-NSSAI. If no AMFs in the particular geographical region supports a given S-NSSAI, NSSF deletes the corresponding nssai_auth and all nss_rule corresponding to that nssai_auth.

NSSF adds nssai_auth and the only one kind of nss_rule, which is accessType 3GPP. If an operator needs to support an S-NSSAI for a accessType Non 3GPP, then they must add an nss_rule.

Managing Auto-Population of Configuration Based on NSAvailability Update

Enable

There is no option to enable or disable this feature. If all the prerequisites are met, it will be autoenabled at the time of installation or after upgrade to the target version.

Configure

Operator must configure the following for this feature to work:

• Configure PLMN Level NSI Profile for each supported PLMN, as nssai_auth autoconfiguration happens only when default profile is configured for the PLMN. For more information on REST based configuration, see PLMN Level NSI Profile in Oracle Communications Cloud Native Core, Network Slice Selection Function REST Specification Guide. For more information on CNC Console based configuration, see PLMN Level NSI Profile in 'Configuring NSSF using CNC Console'.

• Configure nss_rule for SNSSAIs supported for Non 3GPP accessType. For more information on REST based configuration, see NSS Rule in Oracle Communications Cloud Native Core, Network Slice Selection Function REST Specification Guide. For more information on CNC Console based configuration, see NSS Rule in 'Configuring NSSF using CNC Console'.

Observe

No new metrics or KPIs are generated for this feature. For information on other Metrics and KPIs of OCNSSF, see OCNSSF Metrics and OCNSSF KPIs sections respectively.

Error Scenarios

For Auto-Population of Configuration Based on NSAvailability Update, logs are generated for NSAvailability, when error is due to configuration in the PLMN Level NSI Profile.

Table 4-3 Error Scenarios

Scenario	Microservice	Response Code/ Error Title	Log Snippet
PLMN Level NSI Profile is not configured	Nnssf_NSSAIAvailability	Configuration issue: PLMN Level Profile is not configured for <MCC> <MNC> Unable to process nsavailability request 500 Response with details missing configuration. Unable to find PLMN level profile for <MCC> <MNC>	{ "instant": { "epochSecond": 1661325081, "nanoOfSecond": 495990110 }, "thread": "XNIO-1 task-1", "level": "ERROR", "loggerName": "com.oracle.cgbu.cne.nssf.nsavailability.dataservicehelper.AmfTaiSnssaiMapDataPopulation", "message": "CONFIGURATION_ERROR: Unable to find Plmn Level Profile", "endOfBatch": false, "loggerFqcn": "org.apache.logging.log4j.spi.AbstractLogger", "contextMap": { "ocLogId": "1661325081404_2998_ocnssf-ingress-gateway-fd65885d6-lppss" }, "threadId": 234, "threadPriority": 5, "ts": "2022-08-24 07:11:21.495+0000", "ocLogId": "1661325081404_2998_ocnssf-ingress-gateway-fd65885d6-lppss", "pod": "ocnssf-nsavailability-65466b5f48-xtvgz", "processId": "1", "vendor": "Oracle", "application": "ocnssf", "engVersion": "22.2.0", "mktgVersion": "22.2.0.0.0", "microservice": "nsavailability", "namespace": "ocnssf", "node_name": "k8s-node-8.bulkhead.lab.us.oracle.com" }

Maintain

To resolve any alerts at the system or application level, see NSSF Alerts section. If the alerts persist, perform the following:

1. Collect the logs: For more information on how to collect logs, see Oracle Communications Cloud Native Core, Network Slice Selection Function Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

4.14 Handover from EPS to 5G

The current market retains a broad mix of UEs in both 4G and 5G networks. These UEs move from one network to another network in multiple ways:

1. From one 5G PLMN to another 5G PLMN (VPLMN), that is from one 5G network to another 5G network (also known as 5G to 5G roaming).
2. From 4G network to 5G network inside the same "PLMN" (also known as EPS to 5G).

In both the scenarios, a slice mapping mechanism is required on the NSSF of a visited PLMN (VPLMN). This feature implements the support for EPS to 5G slice mapping in NSSF, that is the second case in the list given above.

When a UE moves from 4G network to a 5G network (EPS to 5G), a registration of UE is triggered in the 5G network. The AMF, which caters to UE in 4G, requests to MAP and figure out Authorized 5G S-NSSAIs for the UE. However, the EPS to 5G move is only possible when there are converged 4G-5G nodes on operator network.

Following are high-level scenarios for EPS to 5G movement of a UE:

Scenario 1: UE is moving from EPS to 5G of a VPLMN (For example: Customer of Network-1 is moving from EPS of Network-2 to 5G of Network-2).

Scenario 2: UE is moving from EPS to 5G of the UE's HPLMN (For example: Customer of Network-1 is moving from EPS of Network-1 to 5G of Network-1).

This movement of UE from EPS to 5G is similar to that of a roaming handover, because there is a change in PLMN in both the scenarios.

The following call flow takes places in the entire process of EPS to 5G handover:

1. AMF sends a SliceInfoForRegistration GET request to NSSF. Only the following three parameters are considered for this feature when requestMapping is set to true:
   • sNssaiForMapping
   • requestedNssai
   • requestMapping
2. The query parameters may also contain:
   • Mapping to the Configured NSSAI for the HPLMN
   • PLMN ID of the Subscription Permanent Identifier (SUPI)
   • UE's current Tracking Area
   • NF type of the NF service consumer
   • AMF ID
3. NSSF identifies from the messages if AMF or UE requires EPS to 5G handover.
4. If yes, NSSF sends selected NSSAI based on below conditions:
   1. If mapping is already provided, NSSF uses the mapped S-NSSAI and applies the policy.
   2. If requestMapping is enabled, NSSF takes the 4G slice and maps it to 5G S-NSSAI by sending the corresponding NSSAI in the allowedNssaiList after policy check and confirms the same by responding with AuthorizedNetworkSliceInfo.
   3. If the mapping is not available, the NSSF responds with 4XX status.

The following tables provide the details of the request (SliceInfoForRegistration) and the response (AuthorizedNetworkSliceInfo), respectively:

Table 4-4 Request: SliceInfoForRegistration

Attribute name	Data type	Description
sNssaiForMapping	array(Snssai)	This IE is included if the requestMapping IE is set to true. When included, the IE may contain any of the following: The set of S-NSSAIs obtained from PGW+SMF in the HPLMN for PDU sessions that are handed over from EPS to 5GS. The set of HPLMN S-NSSAIs obtained from source AMF during handover procedure within 5GS. The S-NSSAIs for the HPLMN received from the UE during EPS to 5GS idle mode Mobility Registration Procedure using N26 interface or idle state mobility registration procedure in 5GS.
requestedNssai	array(Snssai)	This IE contains the set of S-NSSAIs requested by the UE. During EPS to 5GS handover procedure using N26 interface, this IE contains the set of S-NSSAIs in the serving PLMN obtained from PGW+SMF in VPLMN or mapped from the set of S-NSSAIs obtained from PGW+SMF in the HPLMN. During handover procedure within 5GS, the IE contains the set of S-NSSAIs in the serving PLMN obtained from the source AMF, or mapped from the set of HPLMN S-NSSAIs obtained from source AMF.
requestMapping	boolean	This IE may be present when the Nnssf_NSSelection_Get procedure is invoked during EPS to 5GS Mobility Registration Procedure (Idle State) using N26 interface or during EPS to 5GS handover procedure using N26 interface. This IE may also be present when Nnssf_NSSelection_Get procedure is invoked during idle state Mobility Registration Procedure or handover procedure in 5GS. When present this IE indicates to the NSSF that the NSSF returns the VPLMN specific mapped SNSSAI values for the S-NSSAI values in the sNssaiForMapping IE.

Table 4-5 Response: AuthorizedNetworkSliceInfo

Attribute name	Data type	Description
allowedNssaiList	array(AllowedNssai)	This IE is included one of the following conditions is true: The NSSF received the Requested NSSAI and the subscribed S-NSSAI(s). The requestMapping flag in the corresponding request is set to true. When present, this IE may contain any of the following: The allowed S-NSSAI(s) authorized by the NSSF in the serving PLMN per access type if the Requested NSSAI and the Subscribed S-NSSAI(s) received. The mapping of S-NSSAI(s) of the VPLMN to corresponding HPLMN S-NSSAI(s) if requestMapping flag is set to true. NSSF considers load level information of a Network Slice Instance, provided by the NWDAF, to exclude slices that are overloaded.

Managing Handover from EPS to 5G

Enable

This feature is driven by 3GPP specifications. There is no option to enable or disable this feature. If all the prerequisites are met, it will be auto enabled at the time of installation or after upgrade to the target version.

Configure

Operator must configure MappingOfNssai for each PLMN for this feature to work. For more information on REST based configuration, see MappingOfNssai in Oracle Communications Cloud Native Core, Network Slice Selection Function REST Specification Guide.

Observe

No new metrics or KPIs are generated for this feature. For information on other Metrics and KPIs of OCNSSF, see OCNSSF Metrics and OCNSSF KPIs sections respectively.

Error Scenarios

For the EPS to 5G Handover Feature, logs are generated for NSSelection mapping, when error is due to slice mapping determination or assignment to a UE or PDU session.

Table 4-6 Error Scenarios

Scenario	Microservice	Response Code/ Error Title	Log Snippet
Mapping is not found for any S-NSSAI in sNssaiForMapping.	NSSelection	No mapping 5G SNSSAI found for SnssaiList in PLMN Error: RequestMappingFailed 403 Forbidden SNSSAI_NOT_SUPPORTED	{ "instant": { "epochSecond": 1661327119, "nanoOfSecond": 10456886 }, "thread": "nf-mediation-thread-1", "level": "ERROR", "loggerName": "com.oracle.cgbu.cne.nssf.nsselection.service.NsPolicyServiceImpl", "message": "No mapping 5G snssai found for[3:EABB03, 4:EABB04]inPlmn [mcc=100, mnc=101]", "endOfBatch": false, "loggerFqcn": "org.apache.logging.log4j.spi.AbstractLogger", "contextMap": {}, "threadId": 54, "threadPriority": 5, "ts": "2022-08-24 07:45:19.010+0000", "ocLogId": "${ctx:ocLogId}", "pod": "ocnssf-nsselection-5bb7bb7799-gcs5r", "processId": "1", "vendor": "Oracle", "application": "ocnssf", "engVersion": "22.3.0", "mktgVersion": "22.3.0.0.0", "microservice": "nsselection", "namespace": "ocnssf", "node_name": "jazz-k8s-node-8" }
Mapping not found for one or more S-NSSAIs and found for others.	NSSelection	NSSF logs error for S-NSSAI for which mapping is not found	{ "instant": { "epochSecond": 1661327653, "nanoOfSecond": 516132707 }, "thread": "nf-mediation-thread-2", "level": "ERROR", "loggerName": "com.oracle.cgbu.cne.nssf.nsselection.service.NsPolicyServiceImpl", "message": "No mapping 5G snssai found for3:EABB03", "endOfBatch": false, "loggerFqcn": "org.apache.logging.log4j.spi.AbstractLogger", "contextMap": {}, "threadId": 55, "threadPriority": 5, "ts": "2022-08-24 07:54:13.516+0000", "ocLogId": "${ctx:ocLogId}", "pod": "ocnssf-nsselection-5bb7bb7799-gcs5r", "processId": "1", "vendor": "Oracle", "application": "ocnssf", "engVersion": "22.3.0", "mktgVersion": "22.3.0.0.0", "microservice": "nsselection", "namespace": "ocnssf", "node_name": "jazz-k8s-node-8" }
No allowed S-NSSAI are found for accessType = 3GPP	NSSelection	Error: RequestMappingFailed 403 Forbidden SNSSAI_NOT_SUPPORTED	{ "instant": { "epochSecond": 1661327653, "nanoOfSecond": 609737045 }, "thread": "nf-mediation-thread-2", "level": "ERROR", "loggerName": "com.oracle.cgbu.cne.nssf.nsselection.service.NsPolicyServiceImpl", "message": "No allowed snssai with access type 3GPP for request mapping=true. Throwing ForbiddenException.", "endOfBatch": false, "loggerFqcn": "org.apache.logging.log4j.spi.AbstractLogger", "contextMap": {}, "threadId": 55, "threadPriority": 5, "ts": "2022-08-24 07:54:13.609+0000", "ocLogId": "${ctx:ocLogId}", "pod": "ocnssf-nsselection-5bb7bb7799-gcs5r", "processId": "1", "vendor": "Oracle", "application": "ocnssf", "engVersion": "22.3.0", "mktgVersion": "22.3.0.0.0", "microservice": "nsselection", "namespace": "ocnssf", "node_name": "jazz-k8s-node-8" }

Maintain

To resolve any alerts at the system or application level, see NSSF Alerts section. If the alerts persist, perform the following:

1. Collect the logs: For more information on how to collect logs, see Oracle Communications Cloud Native Core, Network Slice Selection Function Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

4.15 Feature Negotiation

This feature negotiates optional features applicable between NSSF and NF Service Consumer (AMF/V-NSSF) for the NSSF supported services. The NF Service Consumer indicates the optional features it supports for the Nnssf_NSSAIAvailability or Nnssf_NSSElection service by including the supported feature attributes.

The following optional supported features are defined for NSSF as per 3GPP:

1. Nnssf_NSSAIAvailability service supportedFeatures attributes:
   • Subscription Modification (SUBMOD): This feature allows the operator to modify subscriptions by supporting HTTP Patch on NSAvailability (/nssai-availability/subscriptions/). When Subscription Modification in Subscribe Service Operation (SUMOD) is supported, the operator can modify the subscription of NSSAI availability by implementing the HTTP Patch method.
   • Empty Authorized NSSAI Availability Notification (EANAN): When this feature is supported, an NF Consumer that supports EANAN accepts an empty array of Authorized NSSAI Availability Data in a notification from NSSF and deletes locally stored Authorized NSSAI Availability Data that was received previously.
   • Optimized NSSAI Availability Data Encoding (ONSSAI): ONSSAI is one of the optional features supported by NSSF. NSSF, this feature is described in 3GPP TS 29.531. When ONSSAI is supported by AMF and NSSF, NSSAI Availability data may be signaled per list or per range(s) of Tracking Area Identifiers(TAIs).

Supported Feature Information Element (IE): Supported Feature is a hexadecimal string that contains a bitmask indicating supported features. Each character in the string can take a value of "0" to "9", "a" to "f" or "A" to "F". The character representing the highest-numbered features appears first in the string, and the character representing features 1 to 4 appears last in the string. The list of features and their numbering (starting with 1) are defined separately for each API. If the string contains a lower number of characters, then there are defined features for an API.

Note:

Features represented by the characters that are not present in the string are not supported.

Table 4-7 SupportedFeatures for NSAvailability

Supported Feature based on supported feature set	ES3XX	EANAN	SUMOD	ONSSAI
"0"	no	no	no	no
"1"	no	no	no	yes
"2"	no	no	yes	no
"3"	no	no	yes	yes
"4"	no	yes	no	no
"5"	no	yes	no	yes
"6"	no	yes	yes	no
"7"	no	yes	yes	yes
"8"	yes	no	no	no
"9"	yes	no	no	yes
"A"	yes	no	yes	no
"B"	yes	no	yes	yes
"C"	yes	yes	no	no
"D"	yes	yes	no	yes
"E"	yes	yes	yes	no
"F"	yes	yes	yes	yes

Table 4-8 SupportedFeatures for NSSelection

Supported Feature based on supported feature set	ES3XX
"0"	no
"1"	yes

Managing Feature Negotiation

Enable

To enable this feature, set the global.SupportedFeatureNegotiationEnable parameter to true under the global section in the ocnssf_custom_values_23.4.0.yaml file.

The following snippet represents the location of the mentioned parameter in the Helm file:

global: 
 SupportedFeatureNegotiationEnable: true

Configure

There are no additional configurations required.

Observe

No new metrics or KPIs are generated for this feature. For information on other Metrics and KPIs of OCNSSF, see OCNSSF Metrics and OCNSSF KPIs sections respectively.

Error Scenarios

Table 4-9 Error Scenarios

Scenario	Helm Configuration	Output
NSSelection Get with supported feature. That is, '1'	SupportedFeatureNegotiationEnable:"true" 3gppFeatures: NsSelection: ES3XX: "true" NsAvailability: ONSSAI: "true" SUMOD: "true" EANAN: "true" ES3XX: "true"	Response with supported feature i.e. '1'
NSSelection Get with supported feature. That is, '2'	SupportedFeatureNegotiationEnable:"true" 3gppFeatures: NsSelection: ES3XX: "true" NsAvailability: ONSSAI: "true" SUMOD: "true" EANAN: "true" ES3XX: "true"	Response without supported feature Unsupported value provided for the Supported Feature. Maximum supportedFeatured value is : 1
NSAvailability request with supported feature. That is, '2'	SupportedFeatureNegotiationEnable:"true" 3gppFeatures: NsSelection: ES3XX: "true" NsAvailability: ONSSAI: "true" SUMOD: "true" EANAN: "true" ES3XX: "true"	Response with supported feature i.e. '2'
NSAvailability request with supported feature. That is, '2'	SupportedFeatureNegotiationEnable:"true" 3gppFeatures: NsSelection: ES3XX: "true" NsAvailability: ONSSAI: "true" SUMOD: "false" EANAN: "true" ES3XX: "true"	Bad request 400 Error: All requested supported features are not enabled on NSSF. Enable features from NSSF are:ONSSAI,EANAN,ES3XX
NSAvailability request with supported feature. That is, '7'	SupportedFeatureNegotiationEnable:"true" 3gppFeatures: NsSelection: ES3XX: "true" NsAvailability: ONSSAI: "false" SUMOD: "true" EANAN: "false" ES3XX: "false"	Bad Request 400 Error: All requested supported features are not enabled on NSSF. Enable features from NSSF are:SUMOD

Maintain

To resolve any alerts at the system or application level, see NSSF Alerts section. If the alerts persist, perform the following:

1. Collect the logs: For more information on how to collect logs, see Oracle Communications Cloud Native Core, Network Slice Selection Function Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

4.16 Subscription Modification Feature

This feature allows operator to modify subscription by supporting HTTP Patch on NsAvailability subscribe service operation (/nssai-availability/subscriptions/). Supported operations on HTTP Patch are ADD, REMOVE, and REPLACE. Whereas, COPY, MOVE, and TEST are not supported.

Managing Subscription Modification

Enable

To enable this feature, set the global.SupportedFeatureNegotiationEnable and global.threegppFeatures.NsAvailability.SUMOD parameters to true under the global section in the ocnssf_custom_values_23.4.0.yaml file.

The following snippet represents the location of the mentioned parameters in the Helm file:

global:
 SupportedFeatureNegotiationEnable: true
 threegppFeatures:
   NsAvailability:
   SUMOD: true

Configure

There are no additional configurations required.

Observe

• Added the following success measurements:
  • ocnssf_nssaiavailability_submod_rx
  • ocnssf_nssaiavailability_submod_success_response_tx
• Added the following error measurements:
  • ocnssf_nssaiavailability_submod_error_response_tx
  • ocnssf_nssaiavailability_submod_unimplemented_op
  • ocnssf_nssaiavailability_submod_patch_apply_error

For information about other Metrics and KPIs of NSSF, see NSSF Metrics and NSSF KPIs sections respectively.

Error Scenarios

Table 4-10 Error Scenarios

Scenario	Microservice	Request URL	Response Code/ Error Title
Patch request processing failed due to invalid path	Nnssf_NSSAIAvailability	nnssf-nssaiavailability/v1/nssai-availability/subscriptions/	422 Bad Request Error Jason "Patch Req processing failed"
Subscription with HTTP Patch (Option ADD). Subscription present and TAI addition not supported in PLMN.	Nnssf_NSSAIAvailability	nnssf-nssaiavailability/v1/nssai-availability/subscriptions/	HTTP 403 Unsupported PLMN Error Details must specify supported PLMN list
SUBMOD is set to false	Nnssf_NSSAIAvailability	nnssf-nssaiavailability/v1/nssai-availability/subscriptions/	HTTP 405 Method not allowed
Subscription ID is not found	Nnssf_NSSAIAvailability	nnssf-nssaiavailability/v1/nssai-availability/subscriptions/	HTTP 404 Not Found

Maintain

To resolve any alerts at the system or application level, see NSSF Alerts section. If the alerts persist, perform the following:

1. Collect the logs: For more information on how to collect logs, see Oracle Communications Cloud Native Core, Network Slice Selection Function Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

4.17 Empty Authorized NSSAI Availability Notification

Empty Authorized NSSAI Availability Notification (EANAN) feature provides support for sending an empty array of Authorized NSSAI Availability Data when a notification trigger leads to a situation of no Tracking Area (TA) with Authorized NSSAI by the NSSF. An Access and Mobility Management Function (AMF) that supports this feature accepts the empty array of Authorized NSSAI Availability Data in a notification from NSSF and deletes locally stored Authorized NSSAI Availability Data that was received previously.

Managing EANAN

Enable

To enable this feature, set the global.SupportedFeatureNegotiationEnable and global.threegppFeatures.NsAvailability.EANAN parameters to true under the global section in the ocnssf_custom_values_23.4.0.yaml file.

The following snippet represents the location of the mentioned parameters in the Helm file:

global:
 SupportedFeatureNegotiationEnable: true
 threegppFeatures:
  NsAvailability:
    EANAN: true

Configure

There are no additional configurations required.

Observe

No new metrics or KPIs are generated for this feature. For information on other Metrics and KPIs of OCNSSF, see OCNSSF Metrics and OCNSSF KPIs sections respectively.

Scenarios

Table 4-11 Scenarios

Scenario	Helm Configuration	Subscription Details	Output
Send empty notification when EANAN is supported by both NSSF and Consumer NF for delete as notification trigger	global.SupportedFeatureNegotiationEnable: true global.threegppFeatures.NsAvailability.EANAN : true	Configure nssai_auth to allow S-NSSAI-1 in TAI-1 Send a subscribe for TAI-1 with supportedFeatures flag with EANAN bit set to true Delete nssai_auth	Configuration of nssai_auth must be successful Subscription response must contain Authorized NSSAI Availability Data as S-NSSAI-1 for Tai-1 with EANAN bit in supportedFeaturesset to true Delete nssai_auth must be done Notification from NSSF must contain empty Authorized NSSAI Availability Data
Do not send empty notification when EANAN is supported by NSSF and not by Consumer NF	global.SupportedFeatureNegotiationEnable: true global.threegppFeatures.NsAvailability.EANAN : true	Configure nssai_auth to allow S-NSSAI-1 in TAI-1 Send a subscribe for TAI-1 with supportedFeatures flag with EANAN bit set to false Delete nssai_auth	Configuration of nssai_auth must be successful Subscription response must contain Authorized NSSAI Availability Data as S-NSSAI-1 for Tai-1 with EANAN bit in supportedFeaturesset to false Delete nssai_auth must be done.
Do not send empty notification when EANAN is not supported by NSSF and supported by Consumer NF	global.SupportedFeatureNegotiationEnable: true global.threegppFeatures.NsAvailability.EANAN : false	Configure nssai_auth to allow S-NSSAI-1 in TAI-1 Send a subscribe for TAI-1 with supportedFeatures flag with EANAN bit set to true Delete nssai_auth	Configuration of nssai_auth must be successful Subscription response must contain Authorized NSSAI Availability Data as S-NSSAI-1 for Tai-1 with EANAN bit in supportedFeaturesset to false Delete nssai_auth must be done
Do not send empty notification when EANAN is not supported by NSSF and supported by Consumer NF	global.SupportedFeatureNegotiationEnable: true global.threegppFeatures.NsAvailability.EANAN : false	Configure nssai_auth to allow S-NSSAI-1 in TAI-1 Send a subscribe for TAI-1 with supportedFeatures flag with EANAN bit set to true Delete nssai_auth	Configuration of nssai_auth must be successful Subscription response must contain Authorized NSSAI Availability Data as S-NSSAI-1 for Tai-1 with EANAN bit in supportedFeaturesset to false Delete nssai_auth must be done

Maintain

To resolve any alerts at the system or application level, see NSSF Alerts section. If the alerts persist, perform the following:

1. Collect the logs: For more information on how to collect logs, see Oracle Communications Cloud Native Core, Network Slice Selection Function Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

4.18 Optimized NSSAI Availability Data Encoding and TAI Range

Support for TAI range and Optimized NSSAI Availability Data Encoding(ONSSAI) is introduced in NSSF as per 3GPP TS 29.531 (Release 16):

NSSF supports Optimized NSSAI Availability Data Encoding (ONSSAI), which further extends support for TAI ranges. These two features work together to provide multiple benefits to NSSF. Listed below are the benefits of this feature:

Support for ONSSAI as per 3GPP Specifications 29.531 release 16

ONSSAI is one of the 3GPP Specification 29.531 supported optional features that NSSF negotiates using Feature Negotiation. When ONSSAI is supported by AMF and NSSF, NSSAI Availability data may be signaled per list or per range(s) of Tracking Area Identifiers(TAIs).

The feature bit of ONSSAI is exchanged between NSSF and NF Service Consumer, indicating the support for taiList and taiRangeList. With this support, NSSF and NF Service Consumers can exchange the capabilities in which the support of taiList and taiRangeList is also communicated. NSSF can now expose APIs and store the supported NSSAIs with respect to taiList and taiRangeList. This enables the operator to provide data with minimal entries, which reduces the effort while system configuration.

Support for TAI range in NSSF.

With the advent of 5G and the three types of 5G network slices (MIoT, eMBB, and URLLC), there could be millions of TAIs ( and TACs) in a PLMN. As per current standards, the maximum number of slice instances in a 5G network can reach hundreds. Although the number of slice identifiers (SNSSAIs) in a PLMN is operator-dependent, there is a scope to scale this in thousands, and corresponding slice instance (NSI) in tens of thousands. Since there is a many-to-many mapping between TAIs and SupportedSNSSAIs, and this information is shared and authorized between NSSF and NF Service Consumer of nssai_availability service, the number of TAIs supported by an AMF can range in millions. This can lead to a massive increase in the number of messages with replicated data across NSSF and AMF.

The support for TAI ranges reduces the memory consumption at NSSF by eliminating the need for redundant data storage. Apart from this, the size of supported NSSAI towards NF Service Consumer is also reduced, which further improves the overall network throughput.

For Example:

Consider a case with PLMN 100,101, which constitutes of 1000000 TACs; (1,10,00,000).

If the AMF Supports 300000 TACs, for TAC (1 - 300000):

• Supported SNSSAIs in TAC (1 -100000) are SNSSAI-1,SNSSAI-2,SNSSAI-3,
• supported SNSSAIs in TAC (100001 - 200000) are SNSSAI-2,SNSSAI-3,SNSSAI-4, and
• supported SNSSAIs in TAC (200001 - 300000) are SNSSAI-3, SNSSAI-4, SNSSAI-5.

Each AMF supports multiple TAIs and S-NSSAIs, as shown in the diagram below:

Figure 4-1 Association of AMF and TAI with S-NSSAI

The list of supported TAIs will be almost the same, but for different S-NSSAIs, NSSF requires huge storage space for the redundant data. This results in a substantial increase in the size of the notifications and hassles for managing such a huge configuration, as explained below:

Case 1: nssaiAvailabilityInfo without ONSSAI

Here, the list size of supportedNssaiAvailabilityData would be 300,000 with 3 unique and 299997 repeated SNSSAI list, here is a sample snippet:

{
    "supportedNssaiAvailabilityData": [
        {
            "tai": {
                "plmnId": {
                    "mcc": "100",
                    "mnc": "101"
                },
                "tac": "000001"
            },
            "supportedSnssaiList": [
                {
                    "sd": "000001",
                    "sst": 1
                },
                {
                    "sd": "000002",
                    "sst": 1
                },
                {
                    "sd": "000003",
                    "sst": 1
                }
            ]
        },
        {
            "tai": {
                "plmnId": {
                    "mcc": "100",
                    "mnc": "101"
                },
                "tac": "000002"
            },
            "supportedSnssaiList": [
                {
                    "sd": "000001",
                    "sst": 1
                },
                {
                    "sd": "000002",
                    "sst": 1
                },
                {
                    "sd": "000003",
                    "sst": 1
                }
            ]
        }...the list will go on for 3 unique and 299997 repeated SNSSAI list.
    ]
}

Case 2: nssaiAvailabilityInfo with ONSSAI 

With the support for TAI range, there is an overlapping of TAIs. So, a TAI list of size 3 is enough to contain all 300,000 SNSSAI lists.

Following is a sample snippet:

{
    "supportedNssaiAvailabilityData": [
        {
            "tai": {
                "plmnId": {
                    "mcc": "100",
                    "mnc": "101"
                },
                "tac": "000001"
            },
            "supportedSnssaiList": [
                {
                    "sd": "000001",
                    "sst": 1
                },
                {
                    "sd": "000002",
                    "sst": 1
                },
                {
                    "sd": "000003",
                    "sst": 1
                }
            ],
            "taiRangeList":[
            	{
            		"plmnId": {
                    "mcc": "100",
                    "mnc": "101"
                },
                "tacRangeList":[
                	{
                	"start": "000001",
                	"end": "100000"
                	}
                	]
            		
            	}
            	]
        },
         {
            "tai": {
                "plmnId": {
                    "mcc": "100",
                    "mnc": "101"
                },
                "tac": "000001"
            },
            "supportedSnssaiList": [
                {
                    "sd": "000002",
                    "sst": 1
                },
                {
                    "sd": "000003",
                    "sst": 1
                },
                {
                    "sd": "000004",
                    "sst": 1
                }
            ],
            "taiRangeList":[
            	{
            		"plmnId": {
                    "mcc": "100",
                    "mnc": "101"
                },
                "tacRangeList":[
                	{
                	"start": "100001",
                	"end": "200000"
                	}
                	]
            		
            	}
            	]
        },
        {
            "tai": {
                "plmnId": {
                    "mcc": "100",
                    "mnc": "101"
                },
                "tac": "000001"
            },
            "supportedSnssaiList": [
                {
                    "sd": "000003",
                    "sst": 1
                },
                {
                    "sd": "000004",
                    "sst": 1
                },
                {
                    "sd": "000005",
                    "sst": 1
                }
            ],
            "taiRangeList":[
            	{
            		"plmnId": {
                    "mcc": "100",
                    "mnc": "101"
                },
                "tacRangeList":[
                	{
                	"start": "200001",
                	"end": "300000"
                	}
                	]
            		
            	}
            	]
        }
    ]
}

Managing ONSSAI and TAI Range

Enable

To enable ONSSAI, set the global.SupportedFeatureNegotiationEnable and global.threegppFeatures.NsAvailability.ONSSAI parameter to true under the global section in the ocnssf_custom_values_23.4.0.yaml file.

The following snippet from the yaml file represents the location of the mentioned parameters in the Helm file:

global:
 SupportedFeatureNegotiationEnable: true
 threegppFeatures:
  NsAvailability:
    ONSSAI: true

Configure

Configuration using Helm Parameters:

There are no additional configurations required in the helm parameters.

Configuration using Managed Objects:

TacRange managed object, and tacrange parameter under NSSAI Auth and NSS Rules provide the support required to use TAI range feature. To perform the feature configuration, see NssRule, NssaiAuth, and TacRange managed objects in the chapter NSSF Managed Objects of Oracle Communications Cloud Native Core, Network Slice Selection Function REST Specification Guide.

Observe

No new metrics or KPIs are generated for this feature. For information on other Metrics and KPIs of OCNSSF, see OCNSSF Metrics and OCNSSF KPIs sections respectively.

Maintain

To resolve any alerts at the system or application level, see NSSF Alerts section. If the alerts persist, perform the following:

1. Collect the logs: For more information on how to collect logs, see Oracle Communications Cloud Native Core, Network Slice Selection Function Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

4.19 Georedundancy

NSSF supports up to three-site Georedundancy to ensure service continuity when one of the NSSF sites is down. When NSSF is deployed as georedundant NSSF instances, then:

• All the sites that register with NRF work independently and are in Active state.
• Based on the Rank, each NSSF site subscribes to NRF for any state change of other NSSF sites and gets notified when an NSSF site goes down.
• The NFs in a given site need to configure one of the georedundant NSSF as the primary NSSF and others as secondary NSSF and tertiary NSSF, respectively.
• When the primary NSSF is available, the NFs send service requests to the primary NSSF. When the NSSF at the primary site is unavailable, the NFs redirect service requests to the secondary NSSF or tertiary NSSF, until the primary NSSF's Active status is restored.
• Priority based NSSF selection (at NF Consumer or SCP) can be implemented to ensure route traffic based on which NSSF site is up.

The NSSF's data gets replicated between the georedundant sites by using DB tier's replication service.

With NSSF georedundant feature, the NSSF Services (NSSelection and NSAvailability) will continue to work as independent service operations.

Following are the prerequisites for georedundancy:

• Each site must configure remote NSSF sites as georedundant mates.
• The configurations at each site must be same. The NSSF at all sites must handle the NFs in the same manner.
• Once the Georedundancy feature is enabled on a site, it cannot be disabled.
• If the Time Of the Day (TOD) feature is enabled, georedundant sites are time synchronized.
• NFs need to configure georedundant NSSF details as Primary, Secondary, and Tertiary NSSFs.
• Georedundant sites must have REST based configuration as explained in Oracle Communications Cloud Native Core, Network Slice Selection Function REST Specification Guide.
• At any given time, NFs must communicate with only one NSSF. That is, NFs must register services and maintain heartbeats with only one NSSF. The data must be replicated across the georedundant NSSFs, allowing seamless NF mobility across NSSFs as required.

Managing NSSF Georedundancy Feature

Prerequisites

Following are the prerequisites to enable georedundancy feature in NSSF:

• cnDBTier must be installed and configured for each site. For the installation procedure, see Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.
• The Database Replication Channels between the sites must be up.
• Configure MySQL Database, Users and Secrets. For the configuration procedure, see Preinstallation Tasks in Oracle Communications Cloud Native Core, Network Slice Selection Function Installation an Upgrade Guide.

Enable Georedundancy Feature

Configure the following to enable the georedundancy feature:

Note:

Configuring these attributes during deployment is mandatory before enabling the georedundancy feature. Otherwise, georedundancy cannot be enabled, and NSSF at the site will act as a stand-alone NSSF.

Helm Configuration for Database:

Configure the following parameters in the ocnssf_custom_values_23.4.0.yaml file for all three sites:

• global.stateDbName
• global.provisionDbName
• global.releaseDbName
• global.nameSpace
• global.mysql.primary.host

At Site 1:

global:
  

 # Mysql NSSF Database Names
  stateDbName: 'nssfStateDB'
  provisionDbName: &provDB 'nssfProvSite1DB'



  # Mysql Release Database Name used to maintain release version
  releaseDbName: 'ocnssfReleaseDB'



  # NameSpace where secret is deployed
  nameSpace: &ns ocnssf1
  

  # Database configuration
  mysql:
    primary:
      host: &dbHost "mysql-connectivity-service.site1"

At Site 2:

global:  

 # Mysql NSSF Database Names
  stateDbName: 'nssfStateDB'
  provisionDbName: &provDB 'nssfProvSite2DB'

  # Mysql Release Database Name used to maintain release version
  releaseDbName: 'ocnssfRelease2DB'

  # NameSpace where secret is deployed
  nameSpace: &ns ocnssf2 


  # Database configuration
  mysql:
    primary:
      host: &dbHost "mysql-connectivity-service.site2"

At Site 3:

global:      

 # Mysql NSSF Database Names
  stateDbName: 'nssfStateDB'
  provisionDbName: &provDB 'nssfProvSite3DB'

  # Mysql Release Database Name used to maintain release version
  releaseDbName: 'ocnssfRelease3DB'

  # NameSpace where secret is deployed
  nameSpace: &ns ocnssf3
 

  # Database configuration
  mysql:
    primary:
      host: &dbHost "mysql-connectivity-service.site3"

Helm Configuration of Parameters:

Configure the following parameters in the ocnssf_custom_values_23.4.0.yaml file for all three sites:

• global.grEnabled
• global.nfInstanceId
• global.siteId
• If global.grEnabled is set to true, Configure the following parameters as well:
  • global.grEnv.maxSecondsBehindRemote
  • global.grEnv.dbMonitorServiceUrl
  • global.grEnv.peerGRSitesList.siteId
  • global.grEnv.peerGRSitesList.nfInstanceId

For more information about configuring the parameters, see Oracle Communications Cloud Native Core, Network Slice Selection Function Installation, Upgrade, and Fault Recovery Guide.

Following is the sample configuration at Site named "site1" (nfInstanceId: 9faf1bbc-6e4a-4454-a507-aef01a101a01), which is georedundant with Sites, "site2" (NssfInstanceId: 9faf1bbc-6e4a-4454-a507-aef01a101a02) and "site3" (NssfInstanceId: 9faf1bbc-6e4a-4454-a507-aef01a101a03):

global:
  #Only applicable for NSSF microservices
  #===================================================================
  # GR params
  #tag to enable GR
  grEnabled: true
  #InstanceId of NSSF used in case of GR
  nfInstanceId: "9faf1bbc-6e4a-4454-a507-aef01a101a01"
  #SiteID of NSSF used in case of GR
  siteId: "site1"
  #All parameters under this section are valid only if grEnabled is true
  grEnv:
    #Maximum allowed seconds behind remote site for replication
    maxSecondsBehindRemote: 5
    #URL to check db-replication status
    dbMonitorServiceUrl: "http://mysql-cluster-db-monitor-svc.site1:8080/db-tier/status/replication/realtime"
    #GR sites list
    peerGRSitesList:
      - siteId: "site2"
      - nfInstanceId: "9faf1bbc-6e4a-4454-a507-aef01a101a02"
      - siteId: "site3"
      - nfInstanceId: "9faf1bbc-6e4a-4454-a507-aef01a101a03"

Following is the sample configuration at Site named "site2" (NssfInstanceId: 9faf1bbc-6e4a-4454-a507-aef01a101a02), which is georedundant with Sites, "site1" (NssfInstanceId: 9faf1bbc-6e4a-4454-a507-aef01a101a01) and "site3" (NssfInstanceId: 9faf1bbc-6e4a-4454-a507-aef01a101a03):

global:
   #Only applicable for NSSF microservices
  #===================================================================
  # GR params
  #tag to enable GR
  grEnabled: true
  #InstanceId of NSSF used in case of GR
  nfInstanceId: "9faf1bbc-6e4a-4454-a507-aef01a101a02"
  #SiteID of NSSF used in case of GR
  siteId: "site2"
  #All parameters under this section are valid only if grEnabled is true
  grEnv:
    #Maximum allowed seconds behind remote site for replication
    maxSecondsBehindRemote: 5
    #URL to check db-replication status
    dbMonitorServiceUrl: "http://mysql-cluster-db-monitor-svc.site2:8080/db-tier/status/replication/realtime"
    #GR sites list
    peerGRSitesList:
      - siteId: "site1"
      - nfInstanceId: "9faf1bbc-6e4a-4454-a507-aef01a101a01"
      - siteId: "site3"
      - nfInstanceId: "9faf1bbc-6e4a-4454-a507-aef01a101a03"

Following is the sample configuration at Site named "site3" (NssfInstanceId: 9faf1bbc-6e4a-4454-a507-aef01a101a03), which is georedundant with Sites, "site1" (NssfInstanceId: 9faf1bbc-6e4a-4454-a507-aef01a101a01) and "site2" (NssfInstanceId: 9faf1bbc-6e4a-4454-a507-aef01a101a02)

global:
  # GR params
  #tag to enable GR
  grEnabled: true
  #InstanceId of NSSF used in case of GR
  nfInstanceId: "9faf1bbc-6e4a-4454-a507-aef01a101a03"
  #SiteID of NSSF used in case of GR
  siteId: "site3"
  grEnv:
    #Maximum allowed seconds behind remote site for replication
    maxSecondsBehindRemote: 5
    #URL to check db-replication status
    dbMonitorServiceUrl: "http://mysql-cluster-db-monitor-svc.site3:8080/db-tier/status/replication/realtime"
    #GR sites list
    peerGRSitesList:
      - siteId: "site1"
      - nfInstanceId: "9faf1bbc-6e4a-4454-a507-aef01a101a01"
      - siteId: "site2"
      - nfInstanceId: "9faf1bbc-6e4a-4454-a507-aef01a101a02"

Observe

No new metrics or KPIs are generated for this feature. For information on other Metrics and KPIs of OCNSSF, see OCNSSF Metrics and OCNSSF KPIs sections respectively.

Maintain

To resolve any alerts at the system or application level, see NSSF Alerts section. If the alerts persist, perform the following:

1. Collect the logs: For more information on how to collect logs, see Oracle Communications Cloud Native Core, Network Slice Selection Function Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

4.20 Time of the Day Based Network Slice Instance Selection

5G Traffic rate is not constant at all times, there might be spike in the traffic rate at certain busy hours. There can be occasional spikes based on holiday season. To manage these spikes and avoid traffic loss or over utilization of resources, operators may create network slice instance on need basis, or operators may create specific additional network slices to manage spikes in busy hours. The NSSF feature TOD (time of day based slice selection) allows operator to configure policy to select slice based on the time spans. Operator can provide date spans, day spans, time spans, or any combination of above to provide a policy to select network slice different catering to same SNSSAI based on date. This makes operator able to provide additional slices and enhances NSSF to select different slices based on another parameters. (apart from TAI + SNSSAI).

Managing Time of the Day Feature

Enable

This feature is enabled by default. If time spans are configured, NSSF selects network slice based on local NSSF. time.

Configure

Using helm parameters

If reqnftime flag is set to true, the time provided in Requester-NF-Time will the time considered. If reqnftime flag is set to false, local NSSF time will be considered.

Using Managed Objects

This sample configuration shows a way to configure 2 time profiles and a rule to ensure time based selection of network slice instance profile.

Table 4-12 Sample configuration

Time profile	Network Slice instance profile
Week day rush hour	NSI-PROFILE-1
Christmas	NSI-PROFILE-2
Default fall back	NSI-PROFILE-3

Sample Time Profiles

The following sample allows operator to configure a time profile for Weekdays busy hours. For more information on time profile configuration, see Oracle Communication Cloud Native Core, Network Slice Selection Installation, Upgrade, and Fault Recovery Guide.

{
    "name": "WEEKDAY_BUSY",
    "startDate": "2019-01-01",
    "endDate": "2020-12-31",
    "daysOfWeek": [
        "MONDAY",
        "TUESDAY",
        "WEDNESDAY",
        "THURSDAY",
        "FRIDAY"
    ],
    "timeSpans": [
        {
            "startTime": "07:00:00",
            "endTime": "12:00:00"
        },
        {
            "startTime": "17:00:00",
            "endTime": "22:00:00"
        }
    ]
}

{
    "name": "CHRISTMAS-DAY",
    "startDate": "2019-12-24",
    "endDate": "2019-12-25",
    "daysOfWeek": [],
    "timeSpans": []
}

The following time span enables user to configure a time profile for Christmas irrespective of day.

{
    "name": "CHRISTMAS-DAY",
    "start Date": "2019-12-24",
    "end Date": "2019-12-25",
    "weekday": [],
    "time Spans": []
}

Configure NSSF rule to select different profiles based on time of day

{
    "name": "IR-RULE-TOD",
    "amfId": "22345678-abcd-efAB-CDEF-123456789012",
    "plmnId":
    {
        "mcc": "102",
        "mnc": "102"
    },
    "tac": "100002",
    "snssai":
    {
        "sst": "1",
        "sd": "EABB01"
    },
    "salience": "0",
    "behavior":
    {
        "accessType": "3GPP_ACCESS",
        "nsiProfiles":
        [
            {
                "name": "NSI-PROFILE-2",
                "timeProfile": "CHRISTMAS_DAY",
                "salience": 3
            },
            {
                "name": "NSI-PROFILE-1",
                "timeProfile": "WEEKDAY_BUSY",
                "salience": 2
            }
            {
                "name": "NSI-PROFILE-3",
                "salience": 1
            }
        ]
    },
 
}

Note:

In above rule configuration of Salience field for each time profile is to ensure that Christmas profile gets highest priority ( "salience": 3), then Week day rush hour and then fallback which is default profile.

Network slice profiles must be preconfigured. To configure slice profiles see, Oracle Communication Cloud Native Core, Network Slice Selection Installation, Upgrade, and Fault Recovery Guide.

Observe

Following are the metrics related to Time of the Day feature :

ocnssf_nsselection_rx

ocnssf_nsselection_success_response_tx

ocnssf_nsselection_policy_match

ocnssf_nsselection_time_match

ocnssf_nsselection_nsi_selected

For further information about the Metrics and KPIs, see NSSF Metrics and NSSF KPIs sections respectively.

Maintain

• There must be a default fall back while configuring rule if none of the time profiles match.
• Salience of time profile within behavior section must be different for different time profiles; this it to have proper behavior if there is an overlap of time spans.

To resolve any alerts at the system or application level, see NSSF Alerts section. If the alerts persist, perform the following:

1. Collect the logs: For more information on how to collect logs, see Oracle Communications Cloud Native Core, Network Slice Selection Function Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

4.21 Multiple PLMN Support

This feature enables single NSSF instance to cater to multiple PLMNs. This enables operator to define slice selection policies for multiple PLMNs, and gives the option for operator to span a network slice across PLMNs.

NSSF allows the user to add the supported PLMN list which must be used for registering with NRF. Any change in supported PLMN list must trigger a Register request towards NRF with updated profile. Requests which have TAI containing other PLMN will be treated as roaming.

Managing Multiple PLMN Support

Enable

If the global.supportedPlmnList has valid parameter values, then multiple PLMN feature is enabled.

To enable this feature, open the ocnssf_custom_values_23.4.0.yaml file and set global.supportedPlmnList to valid values as shown the example below:

#Sample to enable
#Multiple PLMN support Following is the way to ensure only (100,101) and (100,02)
  supportedPlmnList:
    - mcc: 100
      mnc: 101
    - mcc: 100
      mnc: 02

Disable

If the global.supportedPlmnList is empty, then multiple PLMN feature is disabled. To disable this feature, open the ocnssf_custom_values_23.4.0.yaml file and set global.supportedPlmnList to empty in Helm file, as shown the example below:

#Sample to disable multiple PLMN
supportedPlmnList: []

Observe

Following are the metrics related to Multiple PLMN Support:

ocnssf_nsselection_unsupported_plmn

ocnssf_nsavailability_unsupported_plmn

ocnssf_nsselection_rx

ocnssf_nsselection_success_response_tx

ocnssf_nsselection_policy_match

ocnssf_nsselection_time_match

ocnssf_nsselection_nsi_selected

ocnssf_nsselection_policy_not_found

For further information about the Metrics and KPIs, see NSSF Metrics and NSSF KPIs sections respectively.

Error Scenarios

Table 4-13 Error Scenarios

Scenario	Micro service and URL	Request URL	Response code / Error Title	Notes
Request comes from unknown PLMN	NSSelection	/nnssf-nsselection/v1/network-slice-information/	403 PLMN_NOT_SUPPORTED	No query sent to DB. Look into configured parameters and respond
Request comes from known PLMN	NSSelection	/nnssf-nsselection/v1/network-slice-information/	200 OK based on policy match
Subscription request for unknown PLMNs only	NSAvailability	/nnssf-nssaiavailability/v1/nssai-availability/subscriptions	403 PLMN_NOT_SUPPORTED	No query sent to DB. as none of the PLMNs are supported
Subscription request for unknown PLMNs and known PLMNs	NSAvailability	/nnssf-nssaiavailability/v1/nssai-availability/subscriptions	204	Subscription done for TAIs for which PLMN is supported Query sent to DB only for TAIs with PLMNs which are supported by NSSF
AMF tries to store session data for unknown PLMNs only	NSAvailability	nnssf-nssaiavailability/v1/nssai-availability	403 PLMN_NOT_SUPPORTED	No query sent to DB. as none of the PLMNs are supported
AMF tries to store session data for unknown PLMNs and known PLMNs	NSAvailability	nnssf-nssaiavailability/v1/nssai-availability	200 OK based on Match	Session Data is stored only for the supported PLMNs
AMF tries to update session data for unknown PLMNs only	NSAvailability	nnssf-nssaiavailability/v1/nssai-availability	403 PLMN_NOT_SUPPORTED	No query sent to DB. as none of the PLMNs are supported
AMF tries to update session data for unknown PLMNs and known PLMNs	NSAvailability	nnssf-nssaiavailability/v1/nssai-availability	200 OK based on Match	Session Data is stored only for the supported PLMNs
Operator tries to configure nsi_auth for unsupported PLMN	NSConfig	nnssf-configuration/v1/nssaiauth/ nnssf-configuration/v1/nssrules/ /nnssf-configuration/v1/configurednssais	403 PLMN_NOT_SUPPORTED "	Currently as we are not supporting roaming scenario Operator must not be allowed to add policy configuration for unknown PLMNs

Maintain

To resolve any alerts at the system or application level, see NSSF Alerts section. If the alerts persist, perform the following:

1. Collect the logs: For more information on how to collect logs, see Oracle Communications Cloud Native Core, Network Slice Selection Function Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

4.22 Support Indirect Communication

3GPP TS 29.531 Release 16 has introduced a new NF SCP which enables reliability and resiliency within network.

In indirect mode of communication consumers and producers interact through SCP. There are two communication models as described below:

Model C - Indirect communication without delegated discovery: Consumers do discovery by querying the NRF. Based on discovery result, the consumer does the selection of an NF Set or a specific NF instance of NF set. The consumer sends the request to the SCP containing the address of the selected service producer pointing to a NF service instance or a set of NF service instances. In the later case, the SCP selects an NF Service instance. If possible, the SCP interacts with NRF to get selection parameters such as Location, capacity, etc. The SCP routes the request to the selected NF service producer instance.

Model D - Indirect communication with delegated discovery: Consumers do not perform any discovery or selection. The consumer adds any necessary discovery and selection parameters required to find a suitable producer to the service request. The SCP uses the request address and the discovery and selection parameters in the request message to route the request to a suitable producer instance. The SCP can perform discovery with an NRF and obtain a discovery result

Once this feature is enabled on NSSF, it allows consumer NFs (AMF) to perform routing and rerouting to NSSF through SCP leveraging following 3GPP headers "3gpp-Sbi–Binding" and "3gpp-Sbi--Routing-Binding".

Note:

• This feature's scope involves the manipulation and updating of headers and values.
• It does not mandate that Notifications must go through SCP. The responsibility for configuring SCP to route the notifications is on the operator. For more information, see DNS SRV Based Selection of SCP in NSSF.
• NSSF only supports the following pattern of 3gpp-Sbi-Binding Header:

  bl=nf-set; nfset=set<setId>.region<regionId>.amfset.5gc.mnc<mnc>.mcc<mcc>

• NSSF only accepts subscription with 3gpp-Sbi-Binding from AMF, provided AMF must be a part of the AMF-Set.

.

Managing Indirect Communication

Enable

To enable this feature, set the value of indirectCommunicationSupportEnable to true in the ocnssf_custom_values_23.4.0.yaml file.

# Indirect communication support 
indirectCommunicationSupportEnable: true

The scope of this feature is Subscription and Notification flow.

When this feature is enabled:

• When AMF sends a NsAvailability Subscribe with 3gpp-Sbi-Binding header, NSSF validates if the header Supported Format is:

  bl=nf-set;
  nfset=set<setId>.region<regionId>.amfset.5gc.mnc<mnc>.mcc<mcc>

  • Only the following format is supported:

    bl=nf-set;
    nfset=set<setId>.region<regionId>.amfset.5gc.mnc<mnc>.mcc<mcc>

  • In case of a successful validation, the NSSF responds with a 201 status code. The response includes a "3gpp-Sbi-Binding" header containing NSSF's binding information.
  • The NSSF computes its binding information by matching the NSSF set details for the corresponding PLMN.
  • The NSSF stores the Binding header of the AMF set in the database.
  • When sending a notification for the subscription, the same value from the AMF's binding header is included in the notification as the "3gpp-Sbi-Routing-Binding" header.
  • Additionally, the NSSF adds a "3gpp-Sbi-Callback" header with the value Nnssf_NSSAIAvailability_Notification.
• If the AMF sends a NsAvailability Subscribe request without the "3gpp-Sbi-Binding" header:
  • The NSSF responds without including the "3gpp-Sbi-Binding" header in the response.
  • The NSSF does not add the "3gpp-Sbi-Routing-Binding" header in the notification.
  • The processing of the request remains unchanged, and there is no impact on the processing and response, except that the mentioned headers are not computed or included as specified above.

Disable

To disable this feature, set the value of indirectCommunicationSupportEnable to false in the ocnssf_custom_values_23.4.0.yaml file.

• When indirectCommunicationSupportEnable is set to false:
  • When AMF sends a NsAvailability Subscribe with 3gpp-Sbi-Binding header:
    • NSSF ignores the header and process the request.
    • NSSF does not add 3gpp-Sbi-Routing-Binding header in the notification.

# Indirect communication support 
indirectCommunicationSupportEnable: false

Observe

• Added the following success measurements:
  • ocnssf_nssaiavailability_indirect_communication_rx
  • ocnssf_nssaiavailability_indirect_communication_tx
  • ocnssf_nssaiavailability_notification_indirect_communication_tx
  • ocnssf_nssaiavailability_notification_indirect_communication_rx
• Added the following error measurements:
  • ocnssf_nssaiavailability_indirect_communication_subscription_failure
  • ocnssf_nssaiavailability_indirect_communication_notification_failure

For more information on above metrics and KPIs, see NSSF Metrics and NSSF KPIs.

Error Scenarios

Table 4-14 Error Scenarios

Scenario	Input Details	Output
Subscription with binding, global.indirectCommunicationSupportEnable is set to true, NSSF is part of nfSet.	Input message: Subscribe with header 3gpp-Sbi--Binding: bl=nf-set; nfset=set1.region48.amfset.5gc.mnc012.mcc345 Helm Parameters and Values: global.indirectCommunicationSupportEnable: true global.nfSet: set1.nssfset.5gc.mnc012.mcc345 global.nssfApiRoot: http://10.178.246.56:30075/	Subscription Response Status: 201 Created Headers Location: http://10.178.246.56:30075/nnssf-nssaiavailability/v1/nssai-availability/subscriptions/1 3gpp-Sbi-Binding: bl=nf-set; nfset=set1.nssfset.5gc.mnc012.mcc345 Notification with headers 3gpp-Sbi-Routing-Binding: bl=nf-set; nfset=set1.region48.amfset.5gc.mnc012.mcc345 3gpp-Sbi-Callback: Nnssf_NSSAIAvailability_Notification
Subscription without binding, global.indirectCommunicationSupportEnable is set to true, NSSF is part of nfSet.	Input message: Subscribe without Header (Direct) Helm Parameters and Values: global.indirectCommunicationSupportEnable: true global.nfSet: set1.nssfset.5gc.mnc012.mcc345 global.nssfApiRoot: http://10.178.246.56:30075/	Subscription Response Status: 201 Created Location: http://10.178.246.56:30075/nnssf-nssaiavailability/v1/nssai-availability/subscriptions/1
Subscription with binding, global.indirectCommunicationSupportEnable is set to false, NSSF is part of nfSet.	Input message: Subscribe with header 3gpp-Sbi-Routing-Binding: bl=nf-set; nfset=set1.region48.amfset.5gc.mnc012.mcc345 Helm Parameters and Values: global.indirectCommunicationSupportEnable: false global.nfSet: set1.nssfset.5gc.mnc012.mcc345 global.nssfApiRoot: http://10.178.246.56:30075/	Subscription Response Status: 201 Created
Subscription without binding, global.indirectCommunicationSupportEnable is set to false, NSSF is part of nfSet.	Input message: Subscribe without Header (Direct) Helm Parameters and Values: global.indirectCommunicationSupportEnable: false global.nfSet: set1.nssfset.5gc.mnc012.mcc345 global.nssfApiRoot: http://10.178.246.56:30075/	Subscription Response Status: 201 Created
Subscription with binding, global.indirectCommunicationSupportEnable is set to true, NSSF is not part of nfSet.	Input message: Subscribe with Header 3gpp-Sbi-Binding: bl=nf-set; nfset=set1.region48.amfset.5gc.mnc012.mcc345 Helm Parameters and Values: global.indirectCommunicationSupportEnable: true global.nfSet: Not part of nf-set but part of GR global.nssfApiRoot: http://10.178.246.56:30075/	Subscription Response Status: 201 Created Headers Location: http://10.178.246.56:30075/nnssf-nssaiavailability/v1/nssai-availability/subscriptions/1 3gpp-Sbi-Routing-Binding: bl=nf-instance; nfinst=54804518-4191-46b3-955c-ac631f953ed7; backupnfinst=54804518-4191-46b3-955c-ac631f953ed8 Notification with headers 3gpp-Sbi-Routing-Binding: bl=nf-set; nfset=set1.region48.amfset.5gc.mnc012.mcc345 3gpp-Sbi-Callback: Nnssf_NSSAIAvailability_Notification ERROR Log
Subscription with binding, global.indirectCommunicationSupportEnable is set to true, NSSF is not part of nfSet.	Input message: Subscribe with Header 3gpp-Sbi-Binding: bl=nf-set; nfset=set1.region48.amfset.5gc.mnc012.mcc345 Helm Parameters and Values: global.indirectCommunicationSupportEnable: true global.nfSet: Not part of nf-set and not part of GR global.nssfApiRoot: http://10.178.246.56:30075/	Subscription Response Status 500 Internal Server Error Cause: CONFIGURATION_ERROR { "type": "INTERNAL_SERVER_ERROR", "title": "CONFIGURATION_ERROR", "status": 500, "detail": "Indirect Communication is true but NFset is null and GR is also not enabled.", "instance": "null", "cause": "CONFIGURATION_ERROR" }
Subscription with binding, global.indirectCommunicationSupportEnable is set to true, NSSF is part of nfSet.	Input message: Subscribe with Header 3gpp-Sbi-Binding: bl=nf-set; nfset=set1.region48.amfset.5gc.mnc012.mcc345 Helm Parameters and Values: global.indirectCommunicationSupportEnable: true global.nfSet: set1.nssfset.5gc.mnc012.mcc345 global.nssfApiRoot: Invalid URL(Empty)	Subscription Response Status: 500 Internal Server Error Cause: CONFIGURATION_ERROR { "type": "INTERNAL_SERVER_ERROR", "title": "INVALID_LOCATION_URL", "status": 500, "detail": "Invalid location/nssfApiRoot url", "instance": "null", "cause": "CONFIGURATION_ERROR" }
NSSF supports multiple PLMNSubscription with binding, global.indirectCommunicationSupportEnable is set to true, NSSF is part of nfSet. NSSF supports PLMN from which AMF is requesting	Input message: Subscribe with Header3gpp-Sbi-Binding: bl=nf-set; nfset=set1.region48.amfset.5gc.mnc100.mcc101 Helm Parameters and Values: global.indirectCommunicationSupportEnable: true global.nfSet: set1.nssfset.5gc.mnc012.mcc345 global.nfSet: set1.nssfset.5gc.mnc100.mcc101 global.nssfApiRoot: http://10.178.246.56:30075/	Subscription Response Status: 201 Created Headers Location: http://10.178.246.56:30075/nnssf-nssaiavailability/v1/nssai-availability/subscriptions/1 3gpp-Sbi-Binding: bl=nf-set; nfset=set1.nssfset.5gc.mnc100.mcc101 Notification with headers 3gpp-Sbi-Routing-Binding: bl=nf-set; nfset=set1.region48.amfset.5gc.mnc100.mcc101 3gpp-Sbi-Callback: Nnssf_NSSAIAvailability_Notification
NSSF supports multiple PLMNSubscription with binding, global.indirectCommunicationSupportEnable is set to true, NSSF is part of nfSet. NSSF do not support PLMN from which AMF is requesting	Input message: Subscribe with Header 3gpp-Sbi-Binding: bl=nf-set; nfset=set1.region48.amfset.5gc.mnc200.mcc201 Helm Parameters and Values: global.indirectCommunicationSupportEnable: true global.nfSet: set1.nssfset.5gc.mnc012.mcc345 global.nfSet: set1.nssfset.5gc.mnc100.mcc101 global.nssfApiRoot: http://10.178.246.56:30075/	Subscription Response Status: 403 Cause: PLMN_NOT_SUPPORTED { "type": "FORBIDDEN", "title": "PLMN_NOT_SUPPORTED", "status": 403, "detail": "Unsupported PLMN/S received , supported plmn list: [Plmn [mcc=100, mnc=101], Plmn [mcc=100, mnc=02], Plmn [mcc=310, mnc=14], Plmn [mcc=345, mnc=012]]", "instance": "null", "cause": "PLMN_NOT_SUPPORTED" }
Subscription with invalid binding header, global.indirectCommunicationSupportEnable is set to true, NSSF is part of nfSet.	Input message: Subscribe with Header 3gpp-Sbi-Binding: bl=nfserviceset; nfset=set1.region48.amfset.5gc.mnc012.mcc345 Helm Parameters and Values: global.indirectCommunicationSupportEnable: true global.nfSet: set1.nssfset.5gc.mnc012.mcc345 global.nssfApiRoot: http://10.178.246.56:30075/	Subscription Response Status: 400 Bad Request Cause: INVALID_INPUT_DATA { "type": "BAD_REQUEST", "title": "INVALID_INPUT_DATA", "status": 400, "detail": "Invalid 3gpp-Sbi-Binding Header, Only following pattern is supported bl=nf-set; nfset=set<setId>.region<regionId>.amfset.5gc.mnc<mnc>.mcc<mcc>", "instance": "null", "cause": "INVALID_INPUT_DATA" }
Subscription with invalid binding header, global.indirectCommunicationSupportEnable is set to true, NSSF is part of nfSet.	Input message: Subscribe with Header3gpp-Sbi-Binding: bl=nf-set nfset=set1.amfset.5gc.mnc012.mcc345 Helm Parameters and Values: global.indirectCommunicationSupportEnable: true global.nfSet: set1.nssfset.5gc.mnc012.mcc345 global.nssfApiRoot: http://10.178.246.56:30075/	Subscription Response Status: 400 Bad Request Cause: INVALID_INPUT_DATA { "type": "BAD_REQUEST", "title": "INVALID_INPUT_DATA", "status": 400, "detail": "Invalid 3gpp-Sbi-Binding Header, Only following pattern is supported bl=nf-set; nfset=set<setId>.region<regionId>.amfset.5gc.mnc<mnc>.mcc<mcc>", "instance": "null", "cause": "INVALID_INPUT_DATA" }
Subscription with invalid binding header, global.indirectCommunicationSupportEnable is set to true, NSSF is part of nfSet.	Input message: Subscribe with Header 3gpp-Sbi-Binding: bl=nf-set; nfset=set1.region48.amfset.5gc.mnc8120.mcc345 Helm Parameters and Values: global.indirectCommunicationSupportEnable: true global.nfSet: set1.nssfset.5gc.mnc012.mcc345 global.nssfApiRoot: http://10.178.246.56:30075/	Subscription Response Status: 400 Bad Request Cause: INVALID_INPUT_DATA { "type": "BAD_REQUEST", "title": "INVALID_INPUT_DATA", "status": 400, "detail": "Invalid mnc 8120 in 3gpp-Sbi-Binding Header", "instance": "null", "cause": "INVALID_INPUT_DATA" } Description: Invalid mnc 8120 in 3gpp-Sbi-Binding Header
Subscription with invalid binding header, global.indirectCommunicationSupportEnable is set to true, NSSF is part of nfSet.	Input message: Subscribe with Header 3gpp-Sbi-Binding: bl=nf-set; nfset=set1.region48.amfset.5gc.mnc8120.mcc345; scope=callback; scope=other-service Helm Parameters and Values: global.indirectCommunicationSupportEnable: true global.nfSet: set1.nssfset.5gc.mnc012.mcc345 global.nssfApiRoot: http://10.178.246.56:30075/	Subscription Response Status: 400 Bad Request Cause: INVALID_INPUT_DATA { "type": "BAD_REQUEST", "title": "INVALID_INPUT_DATA", "status": 400, "detail": "Invalid 3gpp-Sbi-Binding Header, Only following pattern is supported bl=nf-set; nfset=set<setId>.region<regionId>.amfset.5gc.mnc<mnc>.mcc<mcc>", "instance": "null", "cause": "INVALID_INPUT_DATA" } Description: After 3 digits of MCC, there are other characters

Maintain

To resolve any alerts at the system or application level, see NSSF Alerts section. If the alerts persist, perform the following:

1. Collect the logs: For more information on how to collect logs, see Oracle Communications Cloud Native Core, Network Slice Selection Function Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

4.23 IPv6 Support

Oracle supports dual-stack IPv4/IPv6 addressing. IPv6 (Internet Protocol version 6) is the sixth revision of the Internet Protocol and the successor to IPv4. It functions similarly to IPv4 in that it provides the unique IP addresses necessary for Internet-enabled devices to communicate. However, it does have one significant difference, that is, it utilizes a 128-bit IP address.

Managing IPv6 Support

Enable

To enable this feature, the following prerequisites must be satisfied:

• CNE or any CNE cloud network with IPv6 (Single stack) must be enabled.
• All cluster nodes must come with IPv6 address.

Configure

Sample configurations of IPv4 and IPv6 are given below:

Note:

Ensure NRF, DB_Host are either in FQDN format or are in IPv6 to support IPv6.

IPv4

nrfclient:
  # Microservice level control if specific microservice need to be disabled
  nrf-client:
    # This config map is for providing inputs to NRF-Client
    configmapApplicationConfig:
      profile: |-
        [appcfg]
        primaryNrfApiRoot=10.75.225.191:31515
        secondaryNrfApiRoot=10.75.225.191:31515
        nrfScheme=http
        retryAfterTime=PT120S
        nrfClientType=NSSF
        nrfClientSubscribeTypes=NSSF

IPv6

nrfclient:
  # Microservice level control if specific microservice need to be disabled
  nrf-client:
    # This config map is for providing inputs to NRF-Client
    configmapApplicationConfig:
      profile: |-
        [appcfg]
        primaryNrfApiRoot=[fd00:10:96::aa0b]:31515
        secondaryNrfApiRoot=[fd00:10:96::95a]:31515
        nrfScheme=http
        retryAfterTime=PT120S
        nrfClientType=NSSF
        nrfClientSubscribeTypes=NSSF

Observe

NSSF behavior does not change based on underlying IP layer. If the installation and services are running, the NSSF behavior remains the same.

Maintain

To resolve any alerts at the system or application level, see NSSF Alerts section. If the alerts persist, perform the following:

1. Collect the logs: For more information on how to collect logs, see Oracle Communications Cloud Native Core, Network Slice Selection Function Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

4.24 Supports Integration with ASM

NSSF 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.

See Configuring NSSF to support ASM in Oracle Communication Cloud Native Core, Network Slice Selection Function Installation and Upgrade Guide for more details on configuring ASM.

4.25 Supports Compression Using Accept-Encoding or Content-Encoding gzip

HTTP data is compressed before it is sent from the server, to improve transfer speed and bandwidth utilization.

HTTP headers let the client and the server pass additional information with an HTTP request or response.

The Content-Encoding, when present in response, its value indicates which encoding is applied to the entity-body. It lets the client know how to decode in order to obtain the media-type referenced by the Content-Type header.

The Accept-Encoding header is used to find out the encoding supported by the server. The server responds with the type of encoding used, indicated by the Accept-Encoding response header.

Syntax:

Accept-Encoding: gzip

Content-Encoding: gzip

Managing Supports Compression Using Accept-encoding/Content-encoding gzip

Enable

To enable this feature, set the value of nsavailability.contentEncodingEnabled to true in the ocnssf_custom_values_23.4.0.yaml file.

#Sample to enable gzip compression

nsavailability.contentEncodingEnabled: true

Configure

This sample configuration shows minimum response size over which compression of response triggers, if contentEncodingEnabled is set to true.

Helm parameter maxRequestSize is the acceptable size of request.

#Sample configuration gzip compression 
  # Minimum response size required for compression to happen (size is in bytes)
  nsavailability.compressionMinimumResponseSize: 1024
  # Maximum limit for request size
  nsavailability.maxRequestSize: 1MB

Observe

The following measurements are related to Supports compression using Accept-encoding/Content-encoding gzip feature:

ocnssf_nssaiavailability_options_rx

ocnssf_nssaiavailability_options_tx_status_ok

ocnssf_nssaiavailability_options_tx_status_unsupportedmediatetype

For further information about Metrics and KPIs, see NSSF Metrics and NSSF KPIs sections respectively.

Message Scenarios

Table 4-15 Message Scenarios

Scenario	Helm Parameter (server.compression.enabled)	Response code	Response in gzip ?	Response Header
AMF sends an NSAvailability PUT with Request Message size is more than max acceptable size	NA	413 (Request Entity Too Large error)	No	NA
Client sends HTTP OPTIONS with "Accept-encoding" of any value (blank or empty included) other than gzip	Yes	415 (Unsupported Media Type)	NA	Accept-Encoding: gzip Allowed Methods : POST, PUT, PATCH, DELETE Reason: Informs the client to optimize future interactions

Maintain

To resolve any alerts at the system or application level, see NSSF Alerts section. If the alerts persist, perform the following:

1. Collect the logs: For more information on how to collect logs, see Oracle Communications Cloud Native Core, Network Slice Selection Function Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

4.26 Dynamic Log Level Update

Dynamic Log Level Update allows operator to update NSSF log level dynamically without restart.

The log level can be changed by the user at run time. NSSF use common configuration service for dynamically updating Logging Information.

Managing Dynamic Log Level Update

Enable

1. Customize the ocnssf_custom_values_23.4.0.yaml helm file.
2. Set commonCfgClient.enabled to true in the helm file.

Table 4-16 Parameters Configuration

Name	Default	Description
commonCfgClient.enabled	true	Enable/Disable Client.
commonCfgClient.pollingInterval	5000	Set Polling Interval in Milliseconds

Configure

For more information on REST APIs, see Runtime Log Level Update in Oracle Communications Cloud Native Core, Network Slice Selection Function REST Specification Guide.

Observe

No new metrics or KPIs are generated for this feature. For information on other Metrics and KPIs of OCNSSF, see OCNSSF Metrics and OCNSSF KPIs sections respectively.

Maintain

To resolve any alerts at the system or application level, see NSSF Alerts section. If the alerts persist, perform the following:

1. Collect the logs: For more information on how to collect logs, see Oracle Communications Cloud Native Core, Network Slice Selection Function Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

4.27 NF Authentication using TLS Certificate

HTTPS support is a minimum requirement for 5G NFs as defined in 3GPP TS 33.501 Release 15. 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.

HTTPS enables end to end encryption of messages to ensure security of data. HTTPS requires creation of TLS (Mutual TLS by 2 way exchange of ciphered keys).

Managing NF Authentication using TLS Certificate

Steps to Enable HTTPS in NSSF

Certificate Creation

To create certificate user must have the following files:

• ECDSA private key and CA signed certificate of NRF (if initial algorithm is ES256)
• RSA private key and CA signed certificate of NRF (if initial algorithm is RSA256)
• TrustStore password file
• KeyStore password file
• CA certificate

Secret Creation

Execute the following command to create secret:

$ kubectl create secret generic ocnssfaccesstoken-secret --from-file=ecdsa_private_key_pkcs8.pem --from-file=rsa_private_key_pkcs1.pem
      --from-file=trustStorePassword.txt --from-file=keyStorePassword.txt --from-file=ecdsa_ocnssf_certificate.crt--from-file=rsa_ocnssf_certificate.crt -n
    ocnssf

Certificate and Key Exchange

Once the connection is established, both parties can use the agreed algorithm and keys to securely send messages to each other. The handshake has 3 main phases:

• Hello
• Certificate Exchange
• Key Exchange

1. Hello: The handshake begins with the client sending a ClientHello message. This contains all the information the server needs in order to connect to the client via SSL, including the various cipher suites and maximum SSL version that it supports. The server responds with a ServerHello, which contains similar information required by the client, including a decision based on the client’s preferences about which cipher suite and version of SSL will be used.
2. Certificate Exchange: Now that contact has been established, the server has to prove its identity to the client. This is achieved using its SSL certificate, which is a very tiny bit like its passport. An SSL certificate contains various pieces of data, including the name of the owner, the property (For example: domain) it is attached to, the certificate’s public key, the digital signature and information about the certificate’s validity dates. The client checks that it either implicitly trusts the certificate, or that it is verified and trusted by one of several Certificate Authorities (CAs) that it also implicitly trusts. The server is also allowed to require a certificate to prove the client’s identity, but this only happens in very sensitive applications.
3. Key Exchange: The encryption of the actual message data exchanged by the client and server is done using a symmetric algorithm, the exact nature of which was agreed during the Hello phase. A symmetric algorithm uses a single key for both encryption and decryption, in contrast to asymmetric algorithms that require a public or private key pair. Both parties need to agree on this single, symmetric key, a process that is accomplished securely using asymmetric encryption and the server’s public or private keys.

The client generates a random key to be used for the main, symmetric algorithm. It encrypts it using an algorithm also agreed upon during the Hello phase, and the server’s public key (found on its SSL certificate). It sends this encrypted key to the server, where it is decrypted using the server’s private key, and the interesting parts of the handshake are complete. The parties are identified that they are talking to the right person, and have secretly agreed on a key to symmetrically encrypt the data that they are about to send each other. HTTP requests and responses can be sent by forming a plain text message and then encrypting and sending it. The other party is the only one who knows how to decrypt this message, and so Man In The Middle Attackers are unable to read or modify any requests that they may intercept.

NSSF supports following cipher suites

- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

HTTPS Encrypted Communication

Once the HTTPS handshake is complete all communications between the client and the server are encrypted. This includes the full URL, data (plain text or binary), cookies and other headers.

The only part of the communication not encrypted is what domain or host the client requested a connection. This is because when the connection is initiated an HTTP request is made to the target server to create the secure connection. Once HTTPS is established the full URL is used.

This initialization only needs to occur once for each unique connection. This is why HTTP/2 has a distinct advantage over HTTP/1.1 since it multi-plexes connections instead of opening multiple connections.

Helm Configuration to enable HTTPS on NSSF:

Sample values.yaml to enable HTTPS on NSSF:

 #Enabling it generates key and trust store for https support
    initssl: true       (Note: secret has to be created if its set to true)
#If true opens https port on egress gateway
   enableincominghttps: false
#Enabling it egress makes https request outside
   enableoutgoinghttps: true
 (Note: initssl should be set to true if either enableincominghttps or enableoutgoinghttps is enabled )
#KeyStore and TrustStore related private key and Certificate configuration   (Note: The configuration names specified should be same as the     file names specified when creating secret)
      
   privateKey: 
   k8SecretName: accesstoken-secret
   k8NameSpace: ocnssf
   rsa:
   fileName: rsa_private_key_pkcs1.pem
     
   certificate:
   k8SecretName: accesstoken-secret
   k8NameSpace: ocnssf
   rsa:
   fileName: ocnssf.cer
   
   caBundle:
   k8SecretName: accesstoken-secret
   k8NameSpace: ocnssf
   fileName: caroot.cer
     
   keyStorePassword:
   k8SecretName: accesstoken-secret
   k8NameSpace: ocnssf
   fileName: key.txt
   
   trustStorePassword:
   k8SecretName: accesstoken-secret
   k8NameSpace: ocnssf
   fileName: trust.txt
    
   initialAlgorithm: RSA256
  

4.28 Protection from Distributed Denial-of-Service (DDoS) Attack through Rate Limiting

Rate limiting for Ingress and Egress messages helps to prevent the DDoS attack.

NSSF uses Bucket4j which uses Token Bucket algorithm to enable rate limiting.

The token bucket algorithm has following concepts:

burstCapacity: The maximum number of token the bucket can hold.

duration: The amount of time between the refills.

refillRate:The number of tokens that are added to the bucket during a refill.

(where duration: in seconds (M), burstCapacity: (C), refillRate: (N))

• N tokens are added to the bucket every M seconds.
• The bucket can hold at the most C tokens. If a token arrives when the bucket is full, it is discarded.

Ingress Rate Limiting

To avoid unexpected behavior and DOS attacks ,NSSF allows user to enable rate limiting in ingress messages. NSSF allows user to configure a cap on max number of incoming messages at a given duration. User has an option to configure a max cap on number of ingress request per service.

Steps to Enable Ingress Rate Limiting

NSSF allows at the max of {burstCapacity}/ {refillRate} number of messages in a duration signified by parameter {duration}.

To enable ingress rate limiting at NSSF ingress_gateway.rateLimiting.enabled must be set to true.

Global Ingress Rate Limiting

When globalIngressRateLimiting.enabled is set to true then rate limiting is applied for all ingress messages.

Route Based Rate Limiting

NSSF provides option to configure route based rate limiting and method based rate limiting which enables NSSF to throttle messages per Service per method.

In the below example NSSF allows 80 GET requests on NSSelection service for every 2 seconds.

Sample ingress rate limiting configuration:

#Rate limiting configuration
rateLimiting:
  enabled: true
routeRateLimiting:
  enabled: true
# Global rate limiting configuration
globalIngressRateLimiting:
  enabled: true
  duration: 2 # in seconds
  burstCapacity: 100
  refillRate: 1
 
routesConfig:
- id: nsselection_mapping
  uri: http://ocnssf-nsselection:5745
  path: /nnssf-nsselection/**
  order: 1
#Route level limiting configuration enabled for NSSelection
  methodRateLimiting: # specify the list of methods u have to rate limit
  - method: GET
    burstCapacity: 80
    refillRate: 1
    duration: 2
#Route level limiting configuration not enabled for NSAvailability
- id: availability_mapping
  uri: http://ocnssf-nsavailability:5745
  path: /nnssf-nssaiavailability/**
  order: 2
- id: nsconfig_mapping
  uri: http://ocnssf-nsconfig:5755
  path: /nnssf-configuration/**
  order: 3

Egress Rate Limiting

NSSF sends notification messages to AMF based on configuration change of supported SNSSAI/s in a TAI. Notification messages can be throttled by operator by enabling egress message rate limiting.

Steps to Enable Egress Rate Limiting

To enable rate limiting egress-gateway.notificationRateLimit.enabled must be set to true.

As per the below example, NSSF has a max cap on 200 notifications per second:

egress-gateway:
  notificationRateLimit:
    enabled: false
    duration: 1
    bucketCapacity: 200
    refillRate: 1

To Observe Protection from Distributed Denial-of-Service (DDoS) Attack through Rate limiting

The following are the metrics related to Distributed Denial-of-Service (DDoS) Attack through Rate limiting:

• oc_ingressgateway_global_ratelimit
• oc_ingressgateway_route_ratelimit
• oc_egressgateway_notification_ratelimit

For further details of Metrics and KPIs, see NSSF Metrics and NSSF KPIs sections respectively.

Maintain

To resolve any alerts at the system or application level, see NSSF Alerts section. If the alerts persist, perform the following:

1. Collect the logs: For more information on how to collect logs, see Oracle Communications Cloud Native Core, Network Slice Selection Function Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

4.29 Automated Testing Suite Support

NSSF provides Automated Testing Suite for validating the functionalities. Through Automated Testing Suite (ATS), Oracle Communications aims at providing an end-to-end solution to its customers for deploying and testing its 5G-NFs. See Oracle Communications Cloud Native Core, Automated Testing Suite Guide for more information.