NSSF Supported Features

4.1 Support for Automated Certificate Lifecycle Management

NSSF uses secure protocols, such as HTTPS and Secure Socket Layer (SSL) or Transport Layer Security (TLS), to establish and manage secure connections. This is achieved using Public and Private Keys and the presence of trusted authorities such as Certificate Authorities (CA), which create and issue certificates. These certificates have validity. You must renew these certificates before they expire. These certificates can be revoked when the CA or its keys are compromised

Starting with NSSF 25.1.2xx, you can integrate NSSF with Oracle Communications Cloud Native Core, Certificate Management (OCCM) to support automation of certificate lifecycle management. OCCM manages TLS certificates stored in Kubernetes secrets by integrating with Certificate Authority (CA) using the Certificate Management Protocol Version 2 (CMPv2) protocol in the Kubernetes secret. OCCM obtains and signs TLS certificates within the NSSF namespace. For more information about OCCM, see Oracle Communications Cloud Native Core, Certificate Management User Guide.

Support for Automated Certificate Lifecycle Management

The above diagram indicates that OCCM writes the keys to the certificates and NSSF reads these keys to establish a TLS connection with other NFs.

OCCM can automatically manage the following TLS certificates:

5G Service Based Architecture (SBA) client TLS certificates
5G SBA server TLS certificates
Message Feed TLS certificates

Install Guide Considerations

Upgrade: When NSSF is deployed with OCCM, follow the specific upgrade procedure. For information about the upgrade strategy, see "Upgrading NSSF" in Oracle Communications Cloud Native Core, Network Slice Selection Function Installation, Upgrade, and Fault Recovery Guide.
Rollback: For more information on migrating the secrets from NSSF to OCCM and removal of Kubernetes secrets from the yaml file, see "Postupgrade Task" in Oracle Communications Cloud Native Core, Network Slice Selection Function Installation, Upgrade, and Fault Recovery Guide.

Managing DNS SRV Based Selection of NRF in NSSF

This section provides information about Helm, REST API, and Cloud Native Configuration Console (CNC Console) configurations required to configure this feature.

Configure

There are no additional configuration changes required at NSSF.

Observe

Metrics

The following metric is available for this feature:

oc_egressgateway_connection_failure_total
oc_ingressgateway_connection_failure_total

For more information about metrics, see NSSF Metrics section.

KPIs

There are no new KPIs for this feature.

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:

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

4.2 DNS SRV Based Selection of NRF in NSSF

Currently, the NSSF selects the NRF for communication based on static configurations set by the operator. However, there are scenarios where the NRF may go down for various reasons. In such cases, the NSSF, which relies on the NRF for specific communications, may experience service disruptions.

The DNS SRV based selection of NRF in NSSF feature enhances network resilience by utilizing the NRF's georedundancy capabilities to handle potential site failures. This setup enables Network Functions (including NSSF) to continue operating smoothly by redirecting traffic from a primary NRF to a secondary NRF when a failure occurs at the primary site.

This feature allows the NSSF to dynamically select NRF instances based on real-time availability and site redundancy through DNS SRV configurations. In addition to the static configurations by operators, the NSSF can now resolve NRFs using DNS SRV-based Fully Qualified Domain Names (FQDNs). The NSSF is configured with a primary NRF and multiple fallback NRFs, which take over if the primary NRF becomes unreachable.

The nrf-client uses the Alternate Route Service, which helps the Network Slice Selection Function (NSSF) find and select different Network Repository Functions (NRFs) by using DNS SRV-based lookups. This service allows the NSSF to translate Fully Qualified Domain Names (FQDNs) or virtual FQDNs into alternate NRF addresses. This setup enables the NSSF to prioritize and adjust connections to different NRFs based on specific service needs.

How Alternate Routing Works

Figure 4-1 Call Flow of DNS SRV Based Selection of NRF in NSSF

DNS SRV Record Lookup: The NSSF starts by using DNS SRV records to fetch information about the FQDN of the primary NRF and alternate NRFs.
DNS Query: The DNS server receives a query from the NSSF to resolve the FQDN of the primary NRF or alternate NRFs.
DNS Resolution: The DNS server resolves the FQDN and returns the resolved address for the primary NRF or one of the alternate NRFs.
NRF Identification by NSSF: Based on the FQDN provided by DNS, the NSSF identifies the primary NRF to communicate with. If the primary NRF is unavailable, the NSSF uses one of the alternate NRFs.
Static Configuration Option: Alternatively, the NSSF can rely on a static configuration of the primary and alternate NRFs instead of querying DNS.
Request Preparation: Once an NRF (primary or alternate) is identified, the NSSF prepares the request to be sent to the selected NRF.
Communication with NRF: The NSSF sends the request to the identified NRF, enabling further processing or service access.

The Alternate Route Service utilizes DNS SRV records to look up virtual FQDNs. The Egress Gateway queries this service to retrieve a list of alternate NRFs along with their priorities. Based on these priorities, the Egress Gateway reroutes requests to other NRF instances as required.

Key Operations of nrf-client for High Availability

The NSSF uses a component called nrf-client to facilitate communication with NRFs. The nrf-client performs critical functions to ensure NRFs remain available and responsive:

Traffic Routing: The nrf-client directs all requests (for example, registration, updates, heartbeats, and discovery) to the primary NRF.
Failure Detection: If the primary NRF cannot be reached, the nrf-client detects the failure either through routing errors or by receiving a "503 Service Unavailable" response, which may include a "Retry-After" interval.
Failover and Retry: If the primary NRF fails, the nrf-client temporarily marks it as unavailable and reroutes traffic to a secondary NRF based on DNS SRV priority. The retry interval, specified in the "Retry-After" header or a preset interval, determines when the nrf-client reattempts contact with the primary NRF.
- During this interval, all requests are routed to the secondary NRF.
- Once the retry interval expires, the nrf-client resumes attempts to communicate with the primary NRF.

Note:

The nrf-client only tries to connect with each NRF once. If it cannot send a request to an NRF, it returns a "503 Service Unavailable" response to the NSSF. This one-time attempt helps avoid repeated failures and ensures alternate routing to secondary NRFs when needed.

Managing DNS SRV Based Selection of NRF in NSSF

This section provides information about Helm, REST API, and Cloud Native Configuration Console (CNC Console) configurations required to configure this feature.

Enable:

You can enable this feature using Helm configurations. To enable this feature, it is mandatory to configure the following Helm parameters as given below:


enableVirtualNrfResolution=true
virtualNrfFqdn=nrfstub.changeme-ocats.svc
virtualNrfScheme=http

Note:

If enableVirtualNrfResolution is set to false, the nrf-client uses primaryNrfApiRoot and secondaryNrfApiRoot configurations to register with the NRF. However, if enableVirtualNrfResolution is set to true and an incorrect virtualNrfFqdn is configured, the nrf-client does not fallback to primaryNrfApiRoot and secondaryNrfApiRoot for registration, resulting in a registration failure.

Apart from this, for more information on other Helm parameters supported for this feature, see Helm section below.

Configure

Helm

To enable this feature, configure the following nrf-client Helm parameters in ocnssf_custom_values_25.1.200.yaml file.


nrf-client:
  # This config map is for providing inputs to NRF-Client
  configmapApplicationConfig:
    &configRef
    profile: |-
      [appcfg]
      primaryNrfApiRoot=nrf-stubserver.changeme-ocats:8080
      secondaryNrfApiRoot=nrf-stubserver.changeme-ocats:8080
      nrfScheme=http
      retryAfterTime=PT120S
      nrfClientType=NSSF
      nrfClientSubscribeTypes=
      appProfiles=[{
  "nfInstanceId": "9faf1bbc-6e4a-4454-a507-aef01a101a01",
  "nfType": "NSSF",
  "nfStatus": "REGISTERED",
  "heartBeatTimer": 30,
  "fqdn": "ocnssf-nsgateway.ocnssf.svc",
  "priority": 1,
  "capacity": 1,
  "load": 2,
  "plmnList": [
    {
      "mcc": "311",
      "mnc": "480"
    }
  ],
  "nfSetIdList": [
    "setEast.nssfset.5gc.mnc480.mcc311"
  ],
  "locality": "rcnltxekloc1",
  "nfServices": [
    {
      "serviceInstanceId": "92d59bfc-e5d6-47f5-a26b-3a03facdebcc",
      "serviceName": "nnssf-nsselection",
      "versions": [
        {
          "expiry": null,
          "apiFullVersion": "1.0.0",
          "apiVersionInUri": "v1"
        }
      ],
      "scheme": "http",
      "nfServiceStatus": "REGISTERED",
      "fqdn": "ocnssf1-ingress-gateway.ocnssf.svc",
      "interPlmnFqdn": null,
      "ipEndPoints": [
        {
          "ipv4Address": "10.224.45.178",
          "transport": "TCP",
          "port": 80
        }
      ],
      "allowedNfTypes": [
        "AMF",
        "NSSF"
      ],
      "priority": 1,
      "capacity": 1,
      "load": 2
    },
    {
      "serviceInstanceId": "d33728cd-6e21-434b-bc5a-ed69bc612377",
      "serviceName": "nnssf-nssaiavailability",
      "versions": [
        {
          "expiry": null,
          "apiFullVersion": "1.0.0",
          "apiVersionInUri": "v1"
        }
      ],
      "scheme": "http",
      "nfServiceStatus": "REGISTERED",
      "fqdn": "ocnssf2-ingress-gateway.ocnssf.svc",
      "interPlmnFqdn": null,
      "ipEndPoints": [
        {
          "ipv4Address": "10.224.45.179",
          "transport": "TCP",
          "port": 80
        }
      ],
      "allowedNfTypes": [
        "AMF",
        "NSSF"
      ],
      "priority": 1,
      "capacity": 1,
      "load": 2
    }
  ]
}]
      enableF3=true
      enableF5=true
      renewalTimeBeforeExpiry=3600
      validityTime=30
      enableSubscriptionAutoRenewal=true
      nfHeartbeatRate=80
      acceptAdditionalAttributes=false
      retryForCongestion=5
      enableVirtualNrfResolution=true
      virtualNrfFqdn=nrfstub.changeme-ocats.svc
      virtualNrfScheme=http

Note:

This is a sample configuration. Modify the parameters as per your setup. For detailed information about the Helm parameters, see the "Customizing NSSF " section in the Oracle Communications Cloud Native Core, Network Slice Selection Function Installation, Upgrade, and Fault Recovery Guide.

REST API

There are no REST API configurations required for this feature.

CNC Console

There is no option to enable or disable this feature using CNC Console.

Observe

Metrics

The following metric is available for this feature:

nrfclient_nrf_operative_status
nrfclient_dns_lookup_request_total

For more information about metrics, see NSSF Metrics section.

KPIs

There are no new KPIs for this feature.

Alerts

The following alerts are available 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:

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

4.3 Deleting All Slices in a TAI Using PATCH Remove Operation

In the context of 5G networks, network slicing is a crucial feature. It allows the network to be divided into multiple virtual slices, each optimized for a specific type of service or use case. These slices are defined by S-NSSAIs (Single Network Slice Selection Assistance Information) and are associated with specific geographical areas, referred to as Tracking Areas (TAIs).

The Access and Mobility Function (AMF) is responsible for managing these slices and ensuring that these devices connect to the appropriate slices. The Network Slice Selection Function (NSSF) assists the AMF in managing and selecting these slices.

Currently, when the AMF needs to update or delete slices for specific areas, there are limitations in how the NSSF responds to such requests. This new feature addresses those limitations, improving flexibility and compliance with certain operational requirements.

This feature enhances the NSSF to support specific behaviors for managing network slices through the PATCH operation. This includes the ability to:

delete all slices for specific areas (TAI, TAIList, TAIRange) using PATCH.
improve responses for better clarity and compliance, including the use of 204 No Content when all slices in an area are removed.
allow slices to be added back later through PATCH operations.

Old Behavior

Slice Management with PATCH Operations:
- The NSSF responded with 200 OK to all PATCH requests, even if slices were only partially deleted.
- 204 No Content responses were not supported for PATCH operations.
- If no authorized slices were found in a PATCH request, the NSSF returned a 403 Forbidden response.
Deletion Constraints:
- The AMF could only delete all slices across all areas using a DELETE request, which was not always practical.
- The NSSF required at least one slice to remain in a TAI/TAIList/TAIRange, in accordance with existing specifications.

Enhanced Behavior (When the feature is enabled):

Enhanced Deletion Using PATCH:
- The AMF can now issue a PATCH request to delete all slices for a specific TAI/TAIList/TAIRange.
  - If all slices are successfully deleted for the specified area(s), the NSSF responds with 204 No Content.
  - If some slices remain after the deletion, the NSSF responds with 200 OK, including the list of remaining slices.
Support for Full Deletion Scenarios:
- If a NssaiAvailability PATCH request results in deletion of all slices within a specific TAI:
  - The response can be 200 OK (if other TAIs still have SNSSAIs that are supported by the AMF and authorized by NSSF), or
  - 204 No Content (if none of the SNSSAIs supported by the AMF are authorized by NSSF).
- If all slices are deleted across all TAIs, the NSSF responds with 204 No Content.
Adding Back Slices: After a full deletion, the AMF can re-add slices for the same area using a PATCH operation.
Oracle NSSF Specific Handling:
- When processing a PATCH request that removes all slices, the NSSF verifies compliance with the 3GPP specification, which requires at least one slice in an area.
- To support the new feature, the NSSF uses a flag:
  - If the flag is enabled, the NSSF can handle and store areas with no slices (for example, storing a null value or a placeholder).
  - This ensures the system behaves as expected while complying with 3GPP standards and supporting this feature.

Enhanced Behavior (When the feature is disabled):

Enhanced Deletion Using PATCH:
- The system first checks the size of the supportedSnssais list. If it is greater than 1, NSSF responds with 200 OK, including the list of remaining slices.
- Otherwise, deletion is not allowed, and NSSF returns a 400 Bad Request response.

This feature provides flexibility for the AMF to manage slices with greater granularity, targeting specific areas without affecting others, thereby improving efficiency and control. It aligns with 3GPP standard operations for PATCH while introducing flexibility for specific use cases (e.g., FOA). Additionally, returning 204 No Content for full deletions offers a clearer indication that all slices were successfully removed, enhancing system transparency.

Managing Deletion of All Slices in a TAI Using PATCH Remove Operation

This section provides information about Helm, REST API, and Cloud Native Configuration Console (CNC Console) configurations required to configure this feature.

Enable:

You can enable this feature using REST API or CNC Console.

Configure

Helm

There are no Helm configurations required for this feature.

REST API

A new boolean parameter, enhancedPatchBehaviour, is added to enable or disable this feature using NSSF System Option API. Update this parameter value as true or false to enable or disable this feature, respectively. By default, it is set to false.

For more information about the REST API configuration, see "NSSF System Options" section in "NSSF REST Specifications" chapter of Oracle Communications Cloud Native Core, Network Slice Selection Function REST Specification Guide.

CNC Console

The value of enhancedPatchBehaviour parameter can also be updated using CNC Console interface for NSSF System Option.

Observe

Metrics

There are no new Metrics for this feature. However, this feature uses the following metric to count the success response messages sent by NSSF for requests for the Nnssf_NSSAIAvailability service.

ocnssf_nssaiavailability_success_tx_total

For more information about metrics, see NSSF Metrics section.

KPIs

There are no new KPIs for this feature.

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:

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

4.4 Support for TLS

NSSF uses Hypertext Transfer Protocol Secure (HTTPS) to establish secure connections with Consumer NFs and Producer NFs, respectively. These communication protocols are encrypted using Transport Layer Security (TLS). TLS comprises the following components:

Handshake Protocol: Exchanges the security parameters of a connection. Handshake messages are supplied to the TLS record layer.
Record Protocol: Receives the messages to be transmitted, fragments the data into multiple blocks, secures the records, and then transmits the result. Received data is delivered to higher-level peers.

TLS Handshake

This section describes the differences between TLSv1.2 and TLSv1.3 and the advantages of TLSv1.3 over TLSv1.2 and earlier versions.

TLSv1.2

The connection or handshake starts when the client sends a “client hello” message to the server. This message consists of cryptographic information such as supported protocols and supported cipher suites. It also contains a random value or random byte string.
To respond to the “client hello” message, the server sends the “server hello” message. This message contains the CipherSuite that the server has selected from the options provided by the client. The server also sends its certificate along with the session ID and another random value.
The client verifies the certificate sent by the server. When the verification is complete, it sends a byte string and encrypts it using the public key of the server certificate.
When the server receives the secret, both the client and server generate a master key along with session keys (ephemeral keys). These session keys are used to symmetrically encrypt the data.
The client sends an “HTTP Request” message to the server to enable the server to switch to symmetric encryption using the session keys.
To respond to the client’s “HTTP Request” message, the server does the same and switches its security state to symmetric encryption. The server concludes the handshake by sending an HTTP response.
The client-server handshake is completed in two round-trips.

TLSv1.3

The connection or handshake starts when the client sends a “client hello” message to the server. The client sends the list of supported cipher suites. The client also sends its key share for that particular key agreement protocol.
To respond to the “client hello” message, the server sends the key agreement protocol that it has chosen. The “Server Hello” message comprises the server key share, server certificate, and the “Server Finished” message.
The client verifies the server certificate, generates keys as it has the key share of the server, and sends the “Client Finished” message along with an HTTP request.
The server completes the handshake by sending an HTTP response.

The following digital signature algorithms are supported in TLS handshake:

Table 4-1 Digital Signature Algorithms

Algorithm	Key Size (Bits)	Elliptic Curve (EC)
RS256 (RSA)	2048	NA
RS256 (RSA)	4096 This is the recommended value.	NA
ES256 (ECDSA)	NA	SECP384r1 This is the recommended value.

Comparison Between TLSv1.2 and TLSv1.3

The following table provides a comparison of TLSv1.2 and TLSv1.3:

Table 4-2 Comparison of TLSv1.2 and TLSv1.3

Feature	TLS v1.2	TLS v1.3
TLS Handshake	The initial handshake was carried out in clear text. A typical handshake in TLSv1.2 involves the exchange of 5 to 7 packets.	The initial handshake is carried out along with the key share. A typical handshake IN TLSv1.3 involves the exchange of up to 3 packets.
Cipher Suites	Less secure Cipher suites. Use SHA-256 and SHA-384 hashing TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256	More secure Cipher suites. Apart from all the ciphers supported for TLSv1.2, the following additional ciphers are supported for only TLSv1.3: TLS_AES_128_GCM_SHA256 TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256
Round-Trip Time (RTT)	This has a high RTT during the TLS handshake.	This has low RTT during the TLS handshake.
Perfect Forward Secrecy (PFS)	This doesn't support PFS.	TLSv1.3 supports PFS. PFS ensures that each session key is completely independent of long-term private keys, which are keys that are used for an extended period to decrypt encrypted data.
Privacy	This is less secure, as the ciphers used are weak.	This is more secure, as the ciphers used are strong.
Performance	This has high latency and a less responsive connection.	This has low latency and a more responsive connection.

Advantages of TLSv1.3

The TLSv1.3 handshake offers the following improvements over earlier versions:

All handshake messages after the ServerHello are encrypted.
It improves efficiency in the handshake process by requiring fewer round trips than TLSv1.2. It also uses cryptographic algorithms that are faster.
It provides better security than TLSv1.2, addressing known vulnerabilities in the handshake process.
It eliminates data compression.

The following table describes the TLS versions supported on the client and server sides. The last column indicates which version will be used.

TLS Version Used

When NSSF is acting as a client or a server, it can support different TLS versions.

The following table provides information about which TLS version will be used when various combinations of TLS versions are present between the server and the client.

Table 4-3 TLS Version Used

Client Support	Server Support	TLS Version Used
TLSv1.2, TLSv1.3	TLSv1.2, TLSv1.3	TLSv1.3
TLSv1.3	TLSv1.3	TLSv1.3
TLSv1.3	TLSv1.2, TLSv1.3	TLSv1.3
TLSv1.2, TLSv1.3	TLS v1.3	TLSv1.3
TLSv1.2	TLSv1.2, TLSv1.3	TLSv1.2
TLSv1.2, TLSv1.3	TLSv1.2	TLSv1.2
TLS v1.3	TLSv1.2	Sends an error message. For more information about the error message, see "Troubleshooting TLS Version Compatibilities" section in Oracle Communications Cloud Native Core, Network Slice Selection Function Troubleshooting Guide.
TLSv1.2	TLSv1.3	Sends an error message. For more information about the error message, see "Troubleshooting TLS Version Compatibilities" section in Oracle Communications Cloud Native Core, Network Slice Selection Function Troubleshooting Guide.

Note:

If Egress Gateway is deployed with both the versions of TLS that is TLSv1.2 and TLSv1.3, then Egress Gateway as client will send both versions of TLS in the client hello message during the handshake and the server needs to decide which version to be used.
If Ingress Gateway is deployed with both the version of TLS that is with TLSv1.2 and TLSv1.3, then Ingress Gateway as the server will use the TLS version received from the client in the server hello message during the handshake.
This feature does not work in ASM deployment.

Managing Support for TLSv1.2 and TLSv1.3

Enable:

This feature can be enabled or disabled at the time of NSSF deployment using the following Helm parameters:

enableIncomingHttps: This flag is used for enabling/disabling HTTPS/2.0 (secured TLS) in the Ingress Gateway. If the value is set to false, NSSF will not accept any HTTPS/2.0 (secured) traffic. If the value is set to true, NSSF will accept HTTPS/2.0 (secured) traffic.
Note: Do not change the &enableIncomingHttpsRef reference variable. For more information on enabling this flag, see the "Enabling HTTPS at Ingress Gateway" section in the Oracle Communications Cloud Native Core, Network Slice Selection Function Installation, Upgrade, and Fault Recovery Guide.
enableOutgoingHttps: This flag is used for enabling/disabling HTTPS/2.0 (secured TLS) in the Egress Gateway. If the value is set to false, NSSF will not accept any HTTPS/2.0 (secured) traffic. If the value is set to true, NSSF will accept HTTPS/2.0 (secured) traffic.
For more information on enabling this flag, see the "Enabling HTTPS at Egress Gateway" section in the Oracle Communications Cloud Native Core, Network Slice Selection Function Installation, Upgrade, and Fault Recovery Guide.

Configure

You can configure this feature using Helm parameters.

The following parameters in the Ingress Gateway and Egress Gateway microservices must be customized to support TLSv1.2 or TLSv1.3:

Generate HTTPS certificates for both the ingress and egress gateways. Ensure that the certificates are correctly configured for secure communication. After generating the certificates, create a Kubernetes secret for each gateway (egress and ingress). Then, configure these secrets to be used by the respective gateways. For more information about HTTPS configuration, generating certificates, and creating secrets, see the "Configuring Secrets for Enabling HTTPS" section in the Oracle Communications Cloud Native Core, Network Slice Selection Function Installation, Upgrade, and Fault Recovery Guide.
After configuring the secret and applying it to the namespace where NSSF is deployed, perform the following Helm changes for Ingress and Egress gateways in the ocnssf_custom_values_25.1.200.yaml file:
- Parameters required to support TLSv1.2:
  - service.ssl.tlsVersion indicates the TLS version.
  - cipherSuites indicates supported cipher suites.
  - allowedCipherSuites indicates allowed cipher suites.
- Parameters required to support TLSv1.3:
  - service.ssl.tlsVersion indicates the TLS version.
  - cipherSuites indicates the supported cipher suites.
  - allowedCipherSuites indicates the allowed cipher suites.
  - clientDisabledExtension is used to disable the extension sent by messages originating from clients during the TLS handshake with the server.
  - serverDisabledExtension is used to disable the extension sent by messages originating from servers during the TLS handshake with the client.
  - tlsNamedGroups is used to provide a list of values sent in the supported_groups extension. These are comma-separated values.
  - clientSignatureSchemes is used to provide a list of values sent in the signature_algorithms extension.
For more information about configuring the values of the above-mentioned parameters, see the "Ingress Gateway Microservice" and "Egress Gateway Microservice" sections in the Oracle Communications Cloud Native Core, Network Slice Selection Function Installation, Upgrade, and Fault Recovery Guide.
Save the ocnssf_custom_values_25.1.200.yaml file.
Install NSSF. For more information about the installation procedure, see the Oracle Communications Cloud Native Core, Network Slice Selection Function Installation, Upgrade, and Fault Recovery Guide.
Run Helm upgrade if you are enabling this feature after NSSF deployment. For more information about the upgrade procedure, see the Oracle Communications Cloud Native Core, Network Slice Selection Function Installation, Upgrade, and Fault Recovery Guide.

Note:

NSSF does not prioritize cipher suites based on priority. To select a cipher based on priority, you must list the cipher suites in decreasing order of priority.
NSSF does not prioritize supported groups based on priority. To select a supported group based on priority, you must list the supported group values in decreasing order of priority.
If you want to provide values for the signature_algorithms extension using the clientSignatureSchemes parameter, the following comma-separated values must be provided to deploy the services:
- rsa_pkcs1_sha512
- rsa_pkcs1_sha384
- rsa_pkcs1_sha256
Note:
By default, it is null.
The mandatory extensions as listed in RFC 8446 cannot be disabled using the clientDisabledExtension attribute on the client or using the serverDisabledExtension attribute on the server side. The following is the list of the extensions that cannot be disabled:
- supported_versions
- key_share
- supported_groups
- signature_algorithms
- pre_shared_key

Observe

Metrics

The following metrics are available for this feature:

oc_ingressgateway_incoming_tls_connections
oc_egressgateway_outgoing_tls_connections
security_cert_x509_expiration_seconds

For more information about metrics, see NSSF Metrics section.

KPIs

There are no new KPIs for this feature.

Alerts

The following alerts are available for this feature:

Note:

Alert gets raised for every certificate that will expire in the above time frame. For example, NSSF supports both RSA and ECDSA. So, we have configured two certificates. Accordingly, let us suppose RSA certificate is about to expire in 6 months in this situation only one alert will be raised and if both are about to expire then two alerts will be raised.

Maintain

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

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

4.5 Traffic Segregation

This feature provides end-to-end traffic segregation to NSSF based on traffic types. Within a Kubernetes cluster, traffic segregation can divide applications or workloads into distinct sections such as OAM, SBI, Kubernetes control traffic, etc. The Multus CNI container network interface (CNI) plugin for Kubernetes enables attaching multiple network interfaces to pods to help segregate traffic from each NSSF microservice.

This feature addresses the challenge of logically separating IP traffic of different profiles, which are typically handled through a single network (Kubernetes overlay). The new functionality ensures that critical networks are not cross-connected or sharing the same routes, thereby preventing network congestion.

With traffic segregation, operators can segregate traffic to external feeds and applications more effectively. Previously, all external traffic was routed through the same external network, but now, egress traffic from the NSSF pods can be directed through non-default networks to third-party applications. This separation is achieved by leveraging cloud-native infrastructure and the load balancing algorithms in OCCNE.

The feature supports the configuration of separate networks, Network Attachment Definitions (NADs), and the Cloud Native Load Balancer (CNLB). These configurations are crucial for enabling cloud native load balancing, facilitating ingress-egress traffic separation, and optimizing load distribution within NSSF.

Note:

The Traffic Segregation feature is only available in NSSF if OCCNE is installed with CNLB.

Cloud Native Load Balancer (CNLB)

CNE provides Cloud Native Load Balancer (CNLB) for managing the ingress and egress network as an alternate to the existing LBVM, lb-controller, and egress-controller solutions. You can enable or disable this feature only during a fresh CNE installation. When this feature is enabled, CNE automatically uses CNLB to control ingress traffic. To manage the egress traffic, you must preconfigure the egress network details in the cnlb.ini file before installing CNE.

For more information about enabling and configuring CNLB, see Oracle Communications Cloud Native Core, Cloud Native Environment User Guide, and Oracle Communications Cloud Native Core, Cloud Native Environment Installation, Upgrade, and Fault Recovery Guide.

Network Attachment Definitions for CNLB

A Network Attachment Definition (NAD) is a resource used to set up a network attachment, in this case, a secondary network interface to a pod. NSSF supports two types of CNLB NADs:

Ingress Network Attachment Definitions
Ingress NADs are used to handle inbound traffic only. This traffic enters the CNLB application through an external interface service IP address and is routed internally using interfaces within CNLB networks.
- Naming Convention:nf-<service_network_name>-int
Egress Only Network Attachment Definitions
Egress Only NADs enable outbound traffic only. An NF pod can initiate traffic and route it through a CNLB application, translating the source IP address to an external egress IP address. An egress NAD contains network information to create interfaces for NF pods and routes to external subnets.
- Requirements:
  - Ingress NADs are already created for the desired internal networks.
  - Destination (egress) subnet addresses are known beforehand and defined under the cnlb.ini file's egress_dest variable to generate NADs.
  - The use of an Egress NAD on a deployment can be combined with Ingress NADs to route traffic through specific CNLB apps.
- Naming Convention:nf-<service_network_name>-egr

Managing Ingress and Egress Traffic Segregation

Enable:

This feature is disabled by default. To enable this feature, you must configure the network attachment annotations in the ocnssf_custom_values_25.1.200.yaml file.

Configuration

For more information about Traffic Segregation configuration, see " Configuring Traffic Segregation" section in Oracle Communications Cloud Native Core, Network Slice Selection Function Installation, Upgrade, and Fault Recovery Guide..

Observe

There are no Metrics, KPIs, or Alerts available 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:

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

4.6 Support for Common Service APIs in CNC Console

The configuration for common service APIs was supported only using REST. With the implementation of this feature, NSSF now supports the configuration of Ingress Gateway and Egress Gateway parameters using the CNC Console. You can perform HTTP methods such as GET and PUT using the Console.

For more information about the common service APIs, see "Common Services REST APIs" section in the Oracle Communication Cloud Native Core, Network Slice Selection Function REST Specification Guide.

Managing common service APIs in the CNC Console

Enable

This feature is enabled automatically along with the NRF instance deployment.

Configure

You can configure the common services APIs in the CNC Console. For more information, see Common Services Configuration section.

Maintain

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

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

4.7 Enhanced Computation of AllowedNSSAI in NSSF

As per 3GPP specification, NSSF utilizes AMF (Access and Mobility Management Function) to manage the slice selection criteria. Here, if a newly configured NSSAI is not supported by the Radio Access Network (RAN), the AMF designates it as the Rejected-NSSAI. To allow the newly configured NSSAI, UE needs to request for a re-registration. It allows the AMF to disregard a UE's Requested NSSAI and formulate the AllowedNSSAI based on subscription details and support from the RAN

The objective of this feature is to maintain a consistent approach to handling slice subscription changes between AMF and NSSF. Recognizing the need for adaptive and subscriber centric configurations of NSSAI, this feature allows NSSF to generate AllowedNSSAI based on individual user equipment (UE) subscriptions and Tracking Area characteristics.

When this feature is enabled, NSSF generates AllowedNSSAI based on User Equipment (UE) subscription details and the supported configuration within the Tracking Area. Conversely, when the feature is disabled, the NSSF adheres to the 3GPP specification 29.531, constructing AllowedNSSAI based on the intersection of Requested and Subscribed NSSAI and also operator policy.

NSSAI Configuration (When the feature is enabled):

Subscriber-Driven Configuration: The NSSF will dynamically build AllowedNSSAI based on the UE subscription information. This ensures that network slices are aligned with the specific requirements and preferences of individual subscribers.
Tracking Area Considerations: The NSSF takes into account the supported configuration within the Tracking Area, optimizing the network slice selection based on the geographical location and network capabilities in real time.

Static NSSAI Configuration (When the feature is disabled):

Compliance with 3GPP Specification 29.531: When the feature is disabled, the NSSF follows the guidelines outlined in the 3GPP specification 29.531. This involves creating AllowedNSSAI based on the intersection of Requested and Subscribed NSSAI, providing a standardized approach to network slice configuration.
Maintaining Compatibility: Disabling the dynamic NSSAI configuration ensures compatibility with industry standards and facilitates interoperability across different network elements and vendors.

Managing Enhanced Computation of AllowedNSSAI in NSSF

Enable:

You can enable this feature using REST API or CNC Console.

Enable using REST API

Use the following API path:
{apiRoot}/nnsf-configuration/v1/nssfSystemOptions/
To enable the feature for a specific PLMN, set the EnableEnhancedAllowedNSSAIComputation parameter to true. The default value for this parameter is false.
Run GET service method to get the EnableEnhancedAllowedNSSAIComputation value for the PLMN.
Run PUT service method to update the EnableEnhancedAllowedNSSAIComputation value for the PLMN.

For more information about API path, see "NssfSystemOptions" section in Oracle Communications Cloud Native Core, Network Slice Selection Function REST Specification Guide.

Enable using CNC Console

For more information, see NSSF System Option section.

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:

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

4.8 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 scenarios, it becomes crucial for consumer NFs to be promptly notified when the producer NF approaches an overloaded state. This 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. They server as communication tools and 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 when the overload condition was detected, Overload-Reduction-Metric, and Overload Validity period.

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

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 it's not yet overloaded.
This proactive measure prevents overload conditions from replicating.

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 share its load information with 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 AMF to reduce the number of UEs it routes to NSSF.

Note:

Currently, this feature supports LCI-OCI headers at Ingress Gateway. The support for LCI and OCI headers in outgoing messages from Egress Gateway will be enabled in the future.

This following diagram depicts the LCI and OCI workflow:

LCI Headers and Their Workflow

LCI Headers are dedicated to providing real-time load information, using the identifier "3gpp-Sbi-Lci." This information provides consumer NFs with the essential knowledge needed to make informed decisions about distribution of network traffic efficiently. When specific conditions are met, LCI headers are included in the messages and notifications (notifications will be supported in future releases; not supported yet), extending the scope to network function, backend service, or both. The condition states that user-agent/via/oauth header should be present in the request so that LCI is included in the response header.

When NSSF receives a request from an NF (for example, AMF), Ingress Gateway at NSSF checks if LCI is enabled. If it is not enabled, LCI header is not added as part of response. If it is enabled, LCI header is computed as follows:

Ingress Gateway fetches the previous LCI Header from the cache.

Note:
If no data is fetched regarding LCI Header from the cache, it indicates that LCI Header was not sent more than N seconds ago. In this case, a fresh LCI Header with the current information is included.
If the current load metric is within the load metric threshold, LCI Header is not included in the message.
If it is beyond the threshold, LCI Header is included in the message. The LCI Header information is updated in the coherence cache for the current destination and further processing is done.

Table 4-4 LCI header fields

Fields	Description
Load Control Timestamp	Human readable timestamp (date and time) indicating time when LCI header is sent.
Load Metric	Current load level for the scope of LCI, in terms of percentage, ranging from 0 to 100. 0 indicated 0% or no load, and 100 indicates 100% or maximum load.
Scope of LCI	The scope of LCI are NF Instance ID, NF Set ID, NF Service Instance ID or NF Service Set ID. This scope depends on the scope of load info received from perf-info. The same scope is conveyed to the consumer NF.

OCI Headers and Their Workflow

OCI Headers operate under the identifier "3gpp-Sbi-Oci" and are designed to convey current overload information. This information is critical for consumer NFs, enabling them to take preemptive actions to reduce the traffic directed toward overloaded NFs. Like LCI headers, OCI headers are included in messages and notifications when specific conditions are met, spanning the NF scope, the backend service, or both.

When NSSF receives a request from an NF (for example, AMF), Ingress Gateway at NSSF checks if OCI is enabled. If it is not enabled, OCI header is not added as part of response. If it is enabled, OCI header is computed as follows:

Ingress Gateway checks if the NF is overloaded as per the configured range. Then, it fetches the previous OCI Header sent from the cache.

Note:
If no data is fetched regarding OCI Header, however, the NF is overloaded, even then OCI Header is prepared.
If the overload is different from the previously computed value, the Ingress Gateway changes the overload reduction metric value and prepares a new OCI Header.
If the overload is the same as the previous reported value, but the period of validity has expired, the OCI Header is included in the message.
If the period of validity has not expired, the Ingress Gateway continues with further processing. The OCI Header information is updated in the coherence cache for the current destination and further processing is done.

Overload Control based on OCI Header

Overload information need to be sent from producer NF to consumer NF in "3gpp-Sbi-Oci" header. The fields included in this header are described below:

Table 4-5 OCI header fields

Fields	Description
Overload Control Timestamp	Human readable timestamp (date and time) indicating time when OCI header is sent.
Overload Reduction Metric	Indicates the percentage of traffic reduction that this NF expects from the receiver of OCI Header. The value ranges from 0-100, 0 indicating no traffic reduction towards sender of OCI.
Overload Control Period of Validity	Indicates a timer within which the information conveyed in OCI Header shall be considered valid (unless overridden by a newer OCI Header)
Scope of OCI	The scope of OCI can be one of below: NFInstanceID or NF-SET or NF-Service-instance or NF-Service-Set ( if NF is a producer) NFInstanceID or NF-SET or NF-Service-instance or NF-Service-Set or Call-Back URI ( if NF is a consumer) The scope depends on the scope of load info received from perf-info. The same scope is conveyed to the destination NF.

Load Computation

The Ingress Gateway features a configurable polling interval used to retrieve service-level load information from perf-info. The Ingress Gateway conducts load aggregation for supported NSSF services at the NF (Network Function) level, using a straightforward averaging logic. The supported services are decided based on the NF service to instance ID mapping, which is done through Helm. For example, in NSSF, the mapping is done for NsSelection and NsAvailability services. Hence, only these two services are supported in NSSF.

For instance, when the Ingress Gateway receives two pieces of load information for a particular service, it adds these values together and then divides the sum by two to calculate the average load at the NF level.

Peer Identity

If multiple fields are available to extract peer identity, the priority to extract this identity will be in below order:

OAuth token
User Agent header
VIA header

Validity Period

If the same peer sends multiple requests within the validity period and there no breach of configured thresholds, then NSSF will not add LCI or OCI headers.

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

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

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

You can enable this feature using REST API or CNC Console.

Enable using REST API

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.

Enable using CNC Console

For more information, see Server Header Details.

Configure

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

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

Note:
If this configuration is done for Server Header, then for this particular route, it will take precedence over the serverheaderdetails configuration.

Note:

If routesconfiguration is done without errorCodeSeriesId then errorCodeSeriesId configured at serverheaderdetails is picked up, if Server Header is enabled there.
If Server Header is enabled without configuring errorCodeSeriesId then it will be applied for all error codes. This is not a recommended configuration.

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:

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

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

You can enable this feature using REST API or CNC Console.

Enable using REST API

Use the following API path:
/{nfType}/nf-common-component/v1/{serviceName}/useragentheader
Set enabled as true.
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.

Enable using CNC Console

For more information, see User Agent Header Generation.

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:

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

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

In a service mesh based deployment, all incoming connections to the pod get terminated at the sidecar container, then the sidecar container creates a new connection toward the application container. These incoming connections from the peer are managed by the sidecar and outside the purview of the application container.

Hence when the Ingress Gateway container reaches DOC or Congested level, in a service mesh based deployment, the Ingress Gateway container will only be able to stop accepting new connections from the sidecar container. Also in this state, the Ingress Gateway container will reduce the concurrency of the existing connections between the sidecar container and the Ingress Gateway container. Any new request received over a new connection may get accepted or rejected based on the sidecar connection management.

In a non-service mesh based deployment, all incoming connections to the pod get terminated at the Ingress Gateway container. Hence when the Ingress Gateway container reaches DOC or Congested level, the Ingress Gateway container will stop accepting new connections. Also in this state, the Ingress Gateway container will reduce the concurrency of the existing connections between the peer and the Ingress Gateway container. Any new request received over a new connection will result in to a request timeout at the peer.

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 or CNC Console.

Enable using REST API

Perform the REST API configurations as explained below:

Use the API path as {apiRoot}/nf-common-component/v1/{serviceName}/podprotection.
Set enabled as true.
Set congestionControl.enabled to true.

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
                            }
                        }
                    ]
                }
            ]
        }
}

Enable using CNC Console

For more information, see Pod Protection.

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:

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

4.12 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, NSSF 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

During the installation, peermonitoringconfiguration is set to false by default. Since this feature is an add-on to the existing SBI Routing feature, it will be activated if the sbirouteconfig is enabled. To enable this feature, perform the following:

Configure Using REST API

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

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 by default. Configure virtualHost under peerconfiguration where the AMF query is sent.

Here is a sample configuration:

PUT Request

curl -v -X PUT "http://{{host}}:{{port}}/nssf/nf-common-component/v1/egw/peerconfiguration" -H  "Content-Type: application/json"  --data-raw '[{"id": "peer1","host": "scp1","port": "8080","apiPrefix": "/","healthApiPath":"/health/v1"},{"id": "peer2","host": "scp2","port": "8080","apiPrefix":"/","healthApiPath":"/health/v2"},{"id": "peer3","host": "scp3","port": "8080","apiPrefix": "/","healthApiPath":"/health/v3"},{"id": "peer4","host": "scp4","port": "8080","apiPrefix": "/","healthApiPath":"/health/v4"},{"id": "peer5","virtualHost": "xyz.test.com","apiPrefix": "/","healthApiPath":"/health/v5"},{"id": "peer6","virtualHost": "abc.test.com","apiPrefix": "/","healthApiPath":"/health/v6"}]'

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

Here is a sample configuration:

PUT Request

curl -v --http2-prior-knowledge -X PUT "http://{{host}}:{{port}}/nssf/nf-common-component/v1/egw/peersetconfiguration" -H  "Content-Type: application/json" -d '[{"id":"set0","httpConfiguration":[{"priority": 1,"peerIdentifier": "peer1"},{"priority": 2,"peerIdentifier": "peer2"},{"priority": 3,"peerIdentifier": "peer3"},{"priority": 4,"peerIdentifier": "peer4"}],"httpsConfiguration":[{"priority": 1,"peerIdentifier": "peer1"},{"priority": 2,"peerIdentifier": "peer2"},{"priority": 3,"peerIdentifier": "peer3"},{"priority": 4,"peerIdentifier": "peer4"}]},{"id":"set1","httpConfiguration":[{"priority": 1,"peerIdentifier": "peer5"}],"httpsConfiguration":[{"priority": 1,"peerIdentifier": "peer6"}]}]'

Configure or update errorcriteriasets.

Here is a sample configuration:

PUT Request

curl -v --http2-prior-knowledge -X PUT "http://{{host}}:{{port}}/nssf/nf-common-component/v1/egw/sbiroutingerrorcriteriasets" -H  "Content-Type: application/json" -d '[{"id":"criteria_0","method":["GET","POST","PUT","DELETE","PATCH"],"exceptions":["java.util.concurrent.TimeoutException","java.net.UnknownHostException"]},{"id":"criteria_1","method":["GET","POST","PUT","DELETE","PATCH"],"response":{"statuses":[{"statusSeries":"4xx","status":[400,404]},{"statusSeries":"5xx","status":[500,503]}]}}]'

Configure or update erroractionsets.

Here is a sample configuration:

PUT Request

curl -v --http2-prior-knowledge -X PUT "http://{{host}}:{{port}}/nssf/nf-common-component/v1/egw/sbiroutingerroractionsets" -H  "Content-Type: application/json" -d '[{"id":"action_0","action":"reroute","attempts":3,"blacklist":{"enabled":false,"duration":60000}},{"id":"action_1","action":"reroute","attempts":3,"blacklist":{"enabled":false,"duration":60000}}]'

Configure routesconfiguration to define the route and reroute parameters.

Note:

The configuration under sbiRoutingConfiguration corresponds to the SBI-Routing specific configuration.
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.
peerSetIdentifier must be the value configured during peersetconfiguration.

Here is a sample configuration:

PUT Request

curl -v --http2-prior-knowledge -X PUT "http://{{host}}:{{port}}/nssf/nf-common-component/v1/egw/routesconfiguration" -H  "Content-Type: application/json" -d '[{"id":"egress_scp_proxy1","uri":"http://localhost:32068/","order":0,"metadata":{"httpsTargetOnly":false,"httpRuriOnly":false,"sbiRoutingEnabled":true},"predicates":[{"args":{"pattern":"/notification/amf2/"},"name":"Path"}],"filters":[{"name":"SbiRouting","args":{"peerSetIdentifier":"set0","customPeerSelectorEnabled":true,"errorHandling":[{"errorCriteriaSet":"criteria_1","actionSet":"action_1","priority":1},{"errorCriteriaSet":"criteria_0","actionSet":"action_0","priority":2}]}}]},{"id": "default_route","uri": "egress://request.uri","order": 100,"filters": [{"name": "DefaultRouteRetry"}],"predicates": [{"args": {"pattern": "/**"},"name": "Path"}]}]'

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.
After above configurations, configure enable in peermonitoringconfiguration as true to enable peer monitoring. By default, enable is set to false.
Note:
- Peer Monitoring can be enabled to use this feature, where Egress Gateway dynamically monitors the health of the peers configured.
- It is mandatory to configure peerconfiguration with healthApiPath if peermonitoringconfiguration is enabled.
Here is a sample configuration:

PUT Request
```
curl -v --http2-prior-knowledge -X PUT "http://{{host}}:{{port}}/nssf/nf-common-component/v1/egw/peermonitoringconfiguration" -H  "Content-Type: application/json"  --data-raw ' {"enabled": true,"timeout": 1000,"frequency": 2000,"failureThreshold": 3,"successThreshold" : 3}'
```

Note:

The IPs and parameter values in the examples are just placeholders. Replace them with your own settings for the cURLs to function correctly.

For detailed information about the REST APIs and parameters, see "Egress Gateway REST APIs" in Oracle Communications Cloud Native Core, Network Slice Selection Function REST Specification Guide.

Configure Using CNC Console

Taking into account the prerequisites criteria and recommended sequence explained in sections above, you can refer to the Egress Gateway Configurations section in Configuring NSSF using CNC Console for configuring this feature using CNC Console.

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:

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

4.13 Support for Kubernetes Resource

4.13.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.14 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:

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

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

4.15 Deleting Subscription on 404 SUBSCRIPITON_NOT_FOUND Response from AMF

This feature implements a mechanism for the Network Slice Selection Function (NSSF) to manage Access and Mobility Management Function (AMF) subscriptions related to Tracking Area (TA) status changes. When enabled, the NSSF attempts to notify the AMF of any status alterations within a specific TA. If the AMF returns a "404 Subscription Not Found" error, indicating the absence of an active subscription, the NSSF proceeds to delete the associated subscription. This ensures the NSSF maintains an accurate record of active subscriptions.

Advantages:

Optimized Notification Flow: By removing inactive subscriptions, the system prevents the transmission of unnecessary notifications to AMFs that are not subscribed to specific TAs.
Resource Efficiency: Eliminating superfluous notifications reduces network traffic and processing overhead.
Reduced Signaling Load: Prevents unnecessary signaling between the NSSF and AMF.

Use Case Flow:

TA Status Change: A status change occurs within a designated Tracking Area.
Notification Attempt: The NSSF attempts to notify the AMF of the status change.
AMF Response: The AMF responds to the notification attempt.
"404 Subscription Not Found" Response: If the AMF returns a "404 Subscription Not Found" error, it indicates there is no active subscription for the specific TA.
Subscription Deletion: Upon receiving the "404" response, the NSSF deletes the subscription associated with the TA.
Notification Cessation: The AMF no longer receives notifications regarding status changes for the deleted subscription's TA.

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_25.1.200.yaml file.

Observe

Metrics

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

ocnssf_nssaiavailability_notification_delete_on_subscription_not_found_total
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-6 Error Scenarios

Scenario Microservice Details

Parameter deleteOnSubscriptionNotFound is true but unable to delete NssaiSubscription

NsSubscription

Scenario	Microservice	Details
Parameter deleteOnSubscriptionNotFound is true but unable to delete NssaiSubscription	NsSubscription	Request URL: /nnssf-nssubscription/v1/nssai-availability/autoconfignotifications /nnssf-nssubscription/v1/nssai-availability/notifications Response Code/ Error Title: 404 SUBSCRIPTION_NOT_FOUND Log Snippet: { "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	Request URL: /nnssf-nssubscription/v1/nssai-availability/autoconfignotifications /nnssf-nssubscription/v1/nssai-availability/notifications Response Code/ Error Title: 404 SUBSCRIPTION_NOT_FOUND Log Snippet: { "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	Request URL: /nnssf-nssubscription/v1/nssai-availability/autoconfignotifications /nnssf-nssubscription/v1/nssai-availability/notifications Response Code/ Error Title: 404 SUBSCRIPTION_NOT_FOUND Log Snippet: { "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" }

Request URL:

/nnssf-nssubscription/v1/nssai-availability/autoconfignotifications

/nnssf-nssubscription/v1/nssai-availability/notifications

Response Code/ Error Title:

404 SUBSCRIPTION_NOT_FOUND

Log Snippet:

{
    "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

Request URL:

/nnssf-nssubscription/v1/nssai-availability/autoconfignotifications

/nnssf-nssubscription/v1/nssai-availability/notifications

Response Code/ Error Title:

404 SUBSCRIPTION_NOT_FOUND

Log Snippet:

{
    "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

Request URL:

/nnssf-nssubscription/v1/nssai-availability/autoconfignotifications

/nnssf-nssubscription/v1/nssai-availability/notifications

Response Code/ Error Title:

404 SUBSCRIPTION_NOT_FOUND

Log Snippet:

{
    "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:

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

4.16 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

Configure

Configure Using Helm Parameters:

DNS SRV is enabled by default at the time of installation. The dnsSrvEnabled parameter is set to true by default in the ocnssf_custom_values_25.1.200.yaml file:

dnsSrvEnabled: true

Note:
The default value of this parameter is set to true by default. It is recommended to keep this value as true only. Disabling it may cause issues with the functioning of this feature and other features that are depended on it.
dnsSrvFqdnSetting.enabled: true

Note:
Flag to enable or disable the usage of custom patterns for the FQDN while triggering DNS-SRV query. It is set to true by default.
dnsSrvFqdnSetting.pattern: "_{scheme}._tcp.{fqdn}."

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.

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.
  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.
  - 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.
4. Configure or update errorcriteriasets.
5. Configure or update erroractionsets.
6. 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.
7. 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.
8. <Optional> You can also configure peermonitoringconfiguration using REST API or CNC Console. 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.
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.

Configure using CNC Console

Taking into account the prerequisites criteria and recommended sequence explained in sections above, you can see Configuring NSSF using CNC Console section for configuring this feature using CNC Console.

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-7 Error Scenarios

Scenario Microservice Details

Sending Subscription notification failed due to UnknownHost exception

ocnssf-egress-gateway

Scenario	Microservice	Details
Sending Subscription notification failed due to UnknownHost exception	ocnssf-egress-gateway	Request URL: /nnssf-configuration/v1/nssaiauth Response Code/ Error Title: `503` `Service Unavailable` `Encountered unknown host exception at Egress Gateway` Log Snippet: { "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}" }

Request URL:

/nnssf-configuration/v1/nssaiauth

Response Code/ Error Title:

503

Service Unavailable

Encountered unknown host exception at Egress Gateway

Log Snippet:

{
  "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:

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

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

K-ID based ONLY
1. Ingress Gateway validates access token based on public keys indexed with key-id only.
Instance ID based ONLY (DEFAULT)
1. Ingress Gateway validates access token based on public keys indexed with NRF Instance ID in the issuer field.
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 Configuring Secrets 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.

Note:

While Helm based configuration is mandatory, you can also perform CNC Console-based configuration instead of REST-based configurations.

Configuration using Helm:

For Helm-based configuration, perform the following steps:

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

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_25.1.200.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
For information about OAuth access token attributes like kid, typ, iss, aud, scope etc., see https://www.rfc-editor.org/rfc/rfc7515.html page.

#OAUTH CONFIGURATION

  oauthValidatorEnabled: true

  nfType: NSSF

  nfInstanceId: 9faf1bbc-6e4a-4454-a507-aef01a101a01

  producerScope: nnssf-nsselection,nnssf-nssaiavailability

  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 or CNC Console

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.

CNC Console

For more information on CNC Console based configuration, see OAuth Validator Configurations.

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:

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

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

Note:

When the percentage-based overload control discarding policy is enabled, the number of requests to be dropped in the current sampling period is computed based on the configured percentage discard and the "rate of requests outgoing of Ingress Gateway" in the previous sampling period for the service.

Once the number of requests to be dropped in the current sampling period is computed, the gateway does not drop all the new traffic to meet the discard count. Instead, Ingress Gateway executes a random function to decide if a request is to be discarded or not. If the random function returns true, the request is discarded in the current sampling period with the discard action "RejectWithErrorCode". This ensures there is a spread of discard requests in a sampling period.

Since we are calculating the number of requests to be dropped in the current sampling period based on the number of requests sent to the backend service in the previous sampling period and not on the total requests received at Ingress Gateway, the percentage dropped is not exactly the percentage configured.

Managing Overload Control based on Percentage Discards

Enable Overload Control Feature

You can enable Overload Control feature using the following Helm configuration:

Open the ocnssf_custom_values_25.1.200.yaml file.
Set the global.performanceServiceEnable parameter to true in the ocnssf_custom_values_25.1.200.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
```
Set the perf-info.overloadManager.enabled parameter to true in the ocnssf_custom_values_25.1.200.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
```
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
```
Note:
Update the URL as per your setup. It should be a valid Prometheus server URL, which is same as data source URL used on the Grafana dashboard.
Save the ocnssf_custom_values_25.1.200.yaml file.
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

You can configure this feature using Helm, REST API, and CNC Console.

Configure using REST API:

The Overload Control feature related configurations are performed at Ingress Gateway and Perf-info.

The following REST APIs must be configured for this feature in the following order:

{apiRoot}/nssf/nf-common-component/v1/igw/errorcodeprofiles

Note:
Dependency: errorcodeprofiles is used in ocdiscardpolicies to define how different overload levels trigger rejection with specific errors.
{apiRoot}/nssf/nf-common-component/v1/igw/ocdiscardpolicies
Note:
Dependency:
- ocdiscardpolicies use errorcodeprofiles to decide the error message when rejecting requests.
- ocdiscardpolicies are used by ocpolicymapping to associate services with specific overload handling policies.
{apiRoot}/nssf/nf-common-component/v1/igw/ocpolicymapping
Note:
Dependency:
- Depends on ocdiscardpolicies to apply the right rejection policy to each service.
{apiRoot}/nssf/nf-common-component/v1/igw/errorcodeserieslist

Note:
Not directly linked to other configurations but enhances error handling by classifying errors.
{apiRoot}/nssf/nf-common-component/v1/igw/routesconfiguration

Note:
routesconfiguration defines routing behaviors and associates services with error code series. It references errorCodeSeriesId which is defined in id attribute in errorcodeserieslist.
{apiRoot}/nssf/nf-common-component/v1/perfinfo/overloadLevelThreshold

Note:
Determines when a service is considered overloaded. It triggers ocdiscardpolicies when thresholds are exceeded, causing requests to be rejected with predefined error responses.

For more information about APIs, see Oracle Communications Cloud Native Core, Network Slice Selection Function REST Specification Guide

Configure using CNC Console:

The above REST APIs can also be configured using CNC Console UI. For more information, see the follwing sections in the Configuring NSSF using CNC Console chapter:

Create or update the Error Code Profiles.
Create or update the Create Overload Control Discard Policies.
Create or update the Discard Policy Mapping.
Create or update the Error Code Series.
Update the Routes Configuration.

Disable Overload Control Feature

You can disable this feature using the following REST and Helm configurations:

In the following REST API change the value of enable parameter to false:
{apiRoot}/nssf/nf-common-component/v1/igw/ocpolicymapping

For more information about the ocpolicymapping REST API, see Oracle Communications Cloud Native Core, Network Slice Selection Function REST Specification Guide.
Open the ocnssf_custom_values_25.1.200.yaml file.
Set the perf-info.overloadManager.enabled parameter to false in the ocnssf_custom_values_25.1.200.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: false
```
Save the ocnssf_custom_values_25.1.200.yaml file.
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.

Note:

If you want to enable the feature again after disabling it, follow the steps mentioned in the Enable Overload Control Feature and Configure sections.

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 KPIs of NSSF, see NSSF KPIs section.

Alerts

The following alerts are added for the Overload Control feature:

Maintain

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

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

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

For each initial registration, NSSF sends a discovery message to NRF to get AMFs in a AMF-Set.
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:

Set the nsconfig.nrf.subscription parameter to true in the ocnssf_custom_values_25.1.200.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
```
Set the nsselection.features.candidateResolution parameter to true in the ocnssf_custom_values_25.1.200.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_25.1.200.yaml file.

Note:

When nsconfig.nrf.subscription is set to true ocnssf_custom_values_25.1.200.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 to enable this feature. However, this feature will use existing AMF set and NSI-Profile configurations, which can be done using REST API or CNC Console. For more information about CNC Console configuration, see AMF Set and NSI Profile.

Observe

Metrics

Added the following success measurements:

ocnssf_nsconfig_nrf_disc_success_total
ocnssf_subscription_nrf_tx_total

Added the following error measurements:

ocnssf_nsconfig_nrf_disc_error_total
ocnssf_discovery_nrf_tx_failed_total
ocnssf_subscription_nrf_tx_failed_total

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:

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

4.20 Auto-Population of Configuration Based on NSAvailability Update

The Auto-Population of Configuration Based on NSAvailability Update feature allows the Network Slice Selection Function (NSSF) to automatically learn and adapt its configuration for supported S-NSSAIs (Network Slice Selection Service Area Identifiers) from trusted Access and Mobility Functions (AMFs). This automation minimizes manual configuration efforts for operators by filling in the gaps where the operator has not specified allowed S-NSSAIs.

Benefits

Reduces Manual Configuration: Focuses operators' efforts on restricted S-NSSAIs.
Minimizes Errors: Reduces potential errors from manual configuration.
Keeps Configurations Up-to-Date: Ensures NSSF configurations align with trusted AMF capabilities.

How It Works?

AMF Sends Availability Update: An AMF sends a message to NSSF about the S-NSSAIs it supports in a specific Tracking Area Identifier (TAI).
NSSF Checks Configuration: NSSF checks its provisional database to determine if the S-NSSAIs are already configured for that TAI.
Automatic Configuration (if enabled and applicable):
- If enabled and the S-NSSAIs are not configured for that TAI:
  - NSSF creates entries in the nssai_auth table for the S-NSSAIs and TAI.
  - NSSF creates an nss_rule for the S-NSSAIs with access type set to 3GPP (if supported in one or more TAIs).
  - NSSF notifies other AMFs subscribed to the TAI about the new S-NSSAIs.
- If the S-NSSAIs are already configured or if the feature is disabled, NSSF takes no action on the AMF's update.

Sample Call Flow Illustration

Scenario

The operator configures NSSF to allow S-NSSAI "S1" in TAI "1".
A trusted AMF sends an NSAvailability Update indicating it supports S-NSSAIs "S1" and "S2" in TAI "1".

Call Flow (With This Feature Disabled)

AMF to NSSF: AMF sends the NSAvailability Update.
NSSF:
1. Stores the update in StateDB (dynamic configuration).
2. Checks ProvisionDB (operator configuration) and finds only "S1" is allowed in TAI "1".
3. Validates and authorizes "S1" based on ProvisionDB.
NSSF to AMF: NSSF responds with "SNSSAI S1 is authorized in TAI-1".

Call Flow (With This Feature Enabled)

AMF to NSSF: AMF sends the NSAvailability Update.
NSSF:
1. Stores the update in StateDB.
2. Checks ProvisionDB and finds only "S1" is allowed in TAI "1".
3. Identifies "S2" as not configured in ProvisionDB for TAI "1".
4. Creates an entry in the nssai_auth table for TAI "1" and S-NSSAI "S2" with grant set to "ALLOWED".
5. Creates an nss_rule associating the nssai_auth entry with the PLMN level profile of TAI "1" (for 3GPP access).
6. Sends notification to other AMFs subscribed to TAI "1" about the new S-NSSAI "S2".
NSSF to AMF: NSSF responds with "SNSSAI S1, S2 is authorized in TAI-1".

Key Differences

With Feature Enabled: NSSF learns about "S2" from the AMF and automatically configures it for TAI "1".
With Feature Disabled: NSSF only authorizes "S1" based on preconfigured operator settings.

Additional Tasks

Delete S-NSSAI Entry: When an AMF sends a delete request, NSSF checks if any other AMF in the region supports the S-NSSAI. If not, NSSF deletes the corresponding nssai_auth and all nss_rule entries.

Managing Auto-Population of Configuration Based on NSAvailability Update

Enable

If the prerequisites are fulfilled, this feature can be enabled or disabled using NSSF System Options REST API by setting AutoConfigurationFromNsAvailability parameter to one of the following possible values:

Disable: This signifies the feature is disabled and is the default value. There will be no configuration update based on NsAvailability data if the value is disabled.
FromTrustedAMFs: This signifies NsAvailability Update only from trusted AMFs may lead to an update in NSSF configuration.
FromAllAMFs: This signifies that NsAvailability Update from any AMF may lead to an update in NSSF configuration.

Note:

Assuming that NsAvailability Update is processed by NSSF. That is, the AMF is authorized to send the availability update.

Steps to Enable

Get NSSF System Options: Retrieve the current system options.
Update NSSF System Options: Change the value of AutoConfigurationFromNsAvailability to FromTrustedAMFs or FromAllAMFs based on the requirement.
Put NSSF System Options: Send an HTTP PUT request with the updated system options.

Note:

Significance of NSSF System Options: This managed object enables the feature only when AutoConfigurationFromNsAvailability is set to FromTrustedAMFs or FromAllAMFs. Based on the set value, NSSF configuration updates based on NSAvailabilityUpdate will either occur from trusted AMFs only or from all AMFs.
For more information, see NSSF System Options in Oracle Communications Cloud Native Core, Network Slice Selection Function REST Specification Guide.
For CNC Console-based configuration, see NSSF System Option section.

Prerequisites

Operator must configure the following for this feature to work:

Configure PLMN Level NSI Profile: 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'.
Note:
- Significance of PLMN Level Profile: If the PLMN level NSI profile is not configured, NSSF cannot create configuration based on NSAvailability Update as the message does not provide slice instance details. NSSF responds with an error if this configuration is missed and a configuration update is required.
- For more information, see PLMN Level NSI Profile in Oracle Communications Cloud Native Core, Network Slice Selection Function REST Specification Guide.
- For CNC Console-based configuration, see PLMN Level NSI Profiles.
Configure AMF Set:
Configure the AMF Set under which the Trusted AMF falls as a prerequisite before creating or updating a Trusted AMF.
Note:
- For more information, see AMF Set in Oracle Communications Cloud Native Core, Network Slice Selection Function REST Specification Guide.
- For CNC Console-based configuration, see AMF Set.
Configure Trusted AMFs:

Note:
This managed object is considered only when the value of AutoConfigurationFromNsAvailability parameter is set to FromTrustedAMFs in NSSF System Options REST API.

This managed object is used to configure a list of AMFs from which the configuration is trusted. If these AMFs support one or more S-NSSAIs in TAI/TAIs, NSSF updates its own configuration and signifies those S-NSSAIs are supported in those TAIs.
Note:
- NSSF accepts and provisions the configuration only when the request is from trusted AMFs. If the Managed Object is not configured, or if all trusted AMFs are not provided as input, the NSAvailability Update from those AMFs will not impact NSSF's provisional configuration. NSSF will not update the provision database based on NSAvailability Update from any AMF and will behave according to the spec without updating the provision configuration.
- NSSF treats the Availability PUT as equivalent to operator configuration, updating its configuration and notifying other AMFs of new S-NSSAIs.
- For more information, see Trusted AMF in Oracle Communications Cloud Native Core, Network Slice Selection Function REST Specification Guide.
- For CNC Console-based configuration, see Trusted Amf.
Configure Nss Rule for SNSSAIs supported for Non 3GPP accessType. This enhancement configures nss_rules for 3GPP AccesType only. Rules for SNSSAIs supported for Non 3GPP accessType must be still configured by Operator.
Note:
- For more information, see Nss Rule in Oracle Communications Cloud Native Core, Network Slice Selection Function REST Specification Guide.
- For CNC Console-based configuration of NSS Rule, see "Configuring NSSF using CNC Console" chapter in Oracle Communications Cloud Native Core, Network Slice Selection Function User Guide.

Caution:

GR Deployment: In a GR deployment, the operator must configure the same set of AMFs on all sites.
Security: Trusted AMFs can update NSSF configuration, so operators must carefully manage which AMFs are given this capability.
Site-Level Configuration: Trusted AMFs and system options are site-level configurations. Operators must ensure consistent configuration across all sites.
Non-3GPP Access Type: This enhancement configures Nss Rule for 3GPP AccessType only. Operators must configure Nss Rule for Non-3GPP AccessType.

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-8 Error Scenarios

Scenario Microservice Details

PLMN Level NSI Profile is not configured

Nnssf_NSSAIAvailability

Scenario	Microservice	Details
PLMN Level NSI Profile is not configured	Nnssf_NSSAIAvailability	Response Code/ Error Title: 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> Log Snippet: { "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" }

Response Code/ Error Title:

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>

Log Snippet:

{
  "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:

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

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

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

Note:

when UE is in roaming, the Get request in URI parameters contains home-plmn-id from table Table 6.1.3.2.3.1-1: 3GPP TS 29.531 version 16.3.0 Release 16.
In the scenarios where home PLMN is not present, UE is not roaming.

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

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
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
NSSF identifies from the messages if AMF or UE requires EPS to 5G handover.
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-9 Request: SliceInfoForRegistration

Attribute name Data type Description

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.

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-10 Response: AuthorizedNetworkSliceInfo

Attribute name Data type Description

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.

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 using REST API or CNC Console

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.

For more information on CNC Console based configuration, see Mapping of Nssai.

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-11 Error Scenarios

Scenario Microservice Details

Scenario	Microservice	Details
Mapping is not found for any S-NSSAI in `sNssaiForMapping`.	NSSelection	Response Code/ Error Title: No mapping 5G SNSSAI found for `SnssaiList` in PLMN `RequestMappingFailed` `403 Forbidden SNSSAI_NOT_SUPPORTED` Log Snippet: { "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	Response Code/ Error Title: NSSF logs error for S-NSSAI for which mapping is not found Log Snippet: { "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	Response Code/ Error Title: `RequestMappingFailed` `403 Forbidden SNSSAI_NOT_SUPPORTED` Log Snippet: { "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" }

Mapping is not found for any S-NSSAI in sNssaiForMapping.

NSSelection

Response Code/ Error Title:

No mapping 5G SNSSAI found for SnssaiList in PLMN

RequestMappingFailed

403 Forbidden SNSSAI_NOT_SUPPORTED

Log Snippet:

{
  "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

Response Code/ Error Title:

NSSF logs error for S-NSSAI for which mapping is not found

Log Snippet:

{
  "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

Response Code/ Error Title:

RequestMappingFailed

403 Forbidden SNSSAI_NOT_SUPPORTED

Log Snippet:

{
  "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:

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

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

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-12 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-13 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_25.1.200.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-14 Error Scenarios

Scenario Helm Configuration Output

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

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:

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

4.23 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_25.1.200.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_total
- ocnssf_nssaiavailability_submod_success_response_tx_total
Added the following error measurements:
- ocnssf_nssaiavailability_submod_error_response_tx_total
- ocnssf_nssaiavailability_submod_unimplemented_op_total
- ocnssf_nssaiavailability_submod_patch_apply_error_total

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

Error Scenarios

Table 4-15 Error Scenarios

Scenario	Microservice	Description
Patch request processing failed due to invalid path	Nnssf_NSSAIAvailability	Request URL: nnssf-nssaiavailability/v1/nssai-availability/subscriptions/ Response Code/ Error Title: 400 400 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	Request URL: nnssf-nssaiavailability/v1/nssai-availability/subscriptions/ Response Code/ Error Title: HTTP 403 Unsupported PLMN Error Details must specify supported PLMN list
SUBMOD is set to false	Nnssf_NSSAIAvailability	Request URL: nnssf-nssaiavailability/v1/nssai-availability/subscriptions/ Response Code/ Error Title: HTTP 405 Method not allowed
Subscription ID is not found	Nnssf_NSSAIAvailability	Request URL: nnssf-nssaiavailability/v1/nssai-availability/subscriptions/ Response Code/ Error Title: 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:

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

4.24 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_25.1.200.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-16 Scenarios

Scenario	Helm Configuration	Details
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	Subscription: 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 Output: 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	Subscription: 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 Output: 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	Subscription: 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 Output: 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	Subscription: 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 Output: 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

Scenario

Helm Configuration

Details

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

Subscription:

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

Output:

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
1. Delete nssai_auth must be done
2. 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

Subscription:

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

Output:

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

Subscription:

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

Output:

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

Subscription:

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

Output:

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:

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

4.25 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-2 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_25.1.200.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 REST API:

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.

Configuration using CNC Console:

For more information, see NSS Rule and NSSAI Auth.

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:

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

4.26 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.
All NSSF sites retry subscription to the NRF for nfType NSSF if the initial attempt fails. The NSSF will continue retrying at fixed intervals until the subscription to the NRF is successful. The alert SubscriptionToNrfFailed has been added to monitor the subscription status. This alert will be triggered until the subscription to the NRF is successful for each NSSF site, provided GR (Geographical Redundancy) is enabled.
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_25.1.200.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_25.1.200.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:

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

4.27 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-17 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_total

ocnssf_nsselection_success_tx_total

ocnssf_nsselection_policy_match_total

ocnssf_nsselection_time_match_total

ocnssf_nsselection_nsi_selected_total

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:

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

4.28 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_25.1.200.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

To disable this feature, open the ocnssf_custom_values_25.1.200.yaml file and set global.supportedPlmnList to empty in Helm file, as shown the example below:


#Sample to disable multiple PLMN
supportedPlmnList: []

Note:

If the global.supportedPlmnList is empty, then the multiple PLMN feature is turned off, indicating that all PLMNs are permitted

Observe

Following are the metrics related to Multiple PLMN Support:

ocnssf_nsselection_unsupported_plmn_total

ocnssf_nsavailability_unsupported_plmn_total

ocnssf_nsselection_rx_total

ocnssf_nsselection_success_tx_total

ocnssf_nsselection_policy_match_total

ocnssf_nsselection_time_match_total

ocnssf_nsselection_nsi_selected_total

ocnssf_nsselection_policy_not_found_total

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

Error Scenarios

Table 4-18 Error Scenarios

Scenario	Microservice	Details
Request comes from unknown PLMN	NSSelection	Request URL: /nnssf-nsselection/v1/network-slice-information/ Response Code / Error Title: 403 - PLMN_NOT_SUPPORTED Notes: No query sent to DB. Look into configured PLMNs and respond
Request comes from known PLMN	NSSelection	Request URL: /nnssf-nsselection/v1/network-slice-information/ Response Code / Error Title: 200 OK based on policy match
Subscription request for unknown PLMNs only	NSAvailability	Request URL: /nnssf-nssaiavailability/v1/nssai-availability/subscriptions Response Code / Error Title: 403 - PLMN_NOT_SUPPORTED Notes: No query sent to DB as none of the PLMNs are supported
Subscription request for unknown PLMNs and known PLMNs	NSAvailability	Request URL: /nnssf-nssaiavailability/v1/nssai-availability/subscriptions Response Code / Error Title: 403 - PLMN_NOT_SUPPORTED Notes: No query sent to DB as none of the PLMNs are supported
AMF tries to store session data for unknown PLMNs only	NSAvailability	Request URL: nnssf-nssaiavailability/v1/nssai-availability Response Code / Error Title: 403 - PLMN_NOT_SUPPORTED Notes: 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	Request URL: nnssf-nssaiavailability/v1/nssai-availability Response Code / Error Title: 403 - PLMN_NOT_SUPPORTED Notes: No query sent to DB as none of the PLMNs are supported
AMF tries to update session data for unknown PLMNs only	NSAvailability	Request URL: nnssf-nssaiavailability/v1/nssai-availability Response Code / Error Title: 403 - PLMN_NOT_SUPPORTED Notes: 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	Request URL: nnssf-nssaiavailability/v1/nssai-availability Response Code / Error Title: 403 - PLMN_NOT_SUPPORTED Notes: No query sent to DB as none of the PLMNs are supported
Operator tries to configure nsi_auth for unsupported PLMN	NSConfig	Request URL: /nnssf-configuration/v1/nssaiauth/ /nnssf-configuration/v1/nssrules/ /nnssf-configuration/v1/configurednssais Response Code / Error Title: 403 - PLMN_NOT_SUPPORTED Notes: Currently, as we are not supporting the roaming scenario, the operator must not be allowed to add policy configuration for unknown PLMNs.

Here’s the updated table with the merged columns under the new "Details" column:

Maintain

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

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

4.29 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".

Indirect Communication

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_25.1.200.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_25.1.200.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_total
- ocnssf_nssaiavailability_indirect_communication_tx_total
- ocnssf_nssaiavailability_notification_indirect_communication_tx_total
- ocnssf_nssaiavailability_notification_indirect_communication_rx_total
Added the following error measurements:
- ocnssf_nssaiavailability_indirect_communication_subscription_failure_total
- ocnssf_nssaiavailability_indirect_communication_notification_failure_total

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

Error Scenarios

Table 4-19 Error Scenarios

Scenario Input Details Output

Subscription with binding, global.indirectCommunicationSupportEnable is set to true, NSSF is part of nfSet.

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

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:

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

4.30 IPv6 Support

Oracle supports single 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:

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

4.31 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.32 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_25.1.200.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-20 Message Scenarios

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

Scenario

Helm Parameter (server.compression.enabled)

Response Details

AMF sends an NSAvailability PUT with Request Message size is more than max acceptable size

NA

Response code:

413 (Request Entity Too Large error)

Response in gzip ?:

No

Response Header:

NA

Client sends HTTP OPTIONS with "Accept-encoding" of any value (blank or empty included) other than gzip

Yes

Response code:

415 (Unsupported Media Type)

Response in gzip ?:

NA

Response Header:

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:

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

4.33 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

Customize the ocnssf_custom_values_25.1.200.yaml helm file.
Set commonCfgClient.enabled to true in the helm file.

Table 4-21 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:

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

4.34 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

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.
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.
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.35 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 the following concepts:

burstCapacity: The maximum number of tokens 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 users to enable rate limiting for ingress messages. Users can configure a cap on the maximum number of incoming messages within a given duration. Additionally, users have the option to configure a maximum cap on the number of ingress requests per service.

Steps to Enable Ingress Rate Limiting

NSSF allows a maximum of {burstCapacity} / {refillRate} messages within the duration specified by the 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, rate limiting is applied to all ingress messages.

Route-Based Rate Limiting

NSSF provides an option to configure route-based rate limiting and method-based rate limiting, enabling NSSF to throttle messages per service per method.

In the example below, NSSF allows 80 GET requests on the NSSelection service 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 changes of supported SNSSAI/s in a TAI. Operators can throttle notification messages 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.

In the example below, NSSF has a maximum cap of 200 notifications per second:

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

Observation

The following are the metrics related to Distributed Denial-of-Service (DDoS) attack prevention 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:

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

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

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

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

4 NSSF Supported Features

4.1 Support for Automated Certificate Lifecycle Management

4.2 DNS SRV Based Selection of NRF in NSSF

4.3 Deleting All Slices in a TAI Using PATCH Remove Operation

4.4 Support for TLS

4.5 Traffic Segregation

4.6 Support for Common Service APIs in CNC Console

4.7 Enhanced Computation of AllowedNSSAI in NSSF

4.8 LCI and OCI Headers

4.9 Server Header in NSSF

4.10 Support for User-Agent Header

4.11 Ingress Gateway Pod Protection

4.12 Monitoring the Availability of SCPs using SCP Health APIs

4.13 Support for Kubernetes Resource

4.13.1 Network Policies

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

4.15 Deleting Subscription on 404 SUBSCRIPITON_NOT_FOUND Response from AMF

4.16 DNS SRV Based Selection of SCP in NSSF

4.17 OAuth Access Token Based Authorization

4.18 Overload Control based on Percentage Discards

4.19 Autopopulation of Configuration Using NRF Content

4.20 Auto-Population of Configuration Based on NSAvailability Update

4.21 Handover from EPS to 5G

4.22 Feature Negotiation

4.23 Subscription Modification Feature

4.24 Empty Authorized NSSAI Availability Notification

4.25 Optimized NSSAI Availability Data Encoding and TAI Range

4.26 Georedundancy

4.27 Time of the Day Based Network Slice Instance Selection

4.28 Multiple PLMN Support

4.29 Support Indirect Communication

4.30 IPv6 Support

4.31 Supports Integration with ASM

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

4.33 Dynamic Log Level Update

4.34 NF Authentication using TLS Certificate

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

4.36 Automated Testing Suite Support

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