3 SEPP Functionalities and Features

SEPP includes the following core functionalities, features, and deployment support features:

Note:

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

3.1 Core Functionalities

The following are the core functionalities of SEPP:

3.1.1 SEPP MNO functionality Support

Feature Description

When mobile network operators (MNOs) need to connect with each other, they must ensure that their communication is secure and well-managed. Security Edge Protection Proxy (SEPP) plays an important role in protecting and controlling these exchanges. SEPP acts as a protective gateway, allowing operators to safely exchange data while preventing direct access to their internal network functions.

SEPP is designed to enhance security and optimize efficiency in inter-operator communication.

1. Single point of entry for network traffic

   SEPP serves as a central gateway for all external traffic entering or leaving an operator’s network. By consolidating access points into a single controlled entry and exit, SEPP eliminates potential security risks associated with multiple access points. This approach simplifies network management while enhancing security.

2. Improved security and network protection

   By routing all external traffic through SEPP, operators can safeguard their internal network functions from potential threats. Without SEPP, these functions might be directly exposed, increasing vulnerability to attacks. SEPP ensures that only authorized and encrypted communications are exchanged between networks, maintaining the security of the core network.

3. Connecting with multiple roaming partners

   SEPP streamlines roaming and interconnectivity between different operators. Instead of establishing separate connections for each roaming partner, operators can utilize SEPP as a single, unified interconnect point. This allows secure communication with multiple networks at the same time, making it easier to manage roaming agreements.

SEPP has been enhanced to manage multiple connections across various operators and core networks, as outlined below:

1. Multiple SEPP connections to other operators

   Operators often need to connect with several different networks for roaming and data exchange. The improved SEPP can now communicate with multiple SEPPs from different roaming partners at the same time. This allows for secure interconnection with many operators without needing separate systems for each one.

2. SEPP as a shared security gateway for multiple core networks

   Many operators run multiple core networks.Instead of using a separate SEPP for each core, the enhanced SEPP can now act as a shared security gateway for multiple core networks. This reduces complexity and improves efficiency by centralizing security controls.

3. Enhanced N32-c handshake for secure communication

   The N32-c interface manages secure communication between SEPPs in different networks. Previously, SEPP could only establish a single connection at a time. Now, it can perform multiple N32-c handshakes with different roaming partner SEPPs at the same time. This helps operators handle roaming connections more efficiently and improves overall network performance.

4. Support for multiple N32-f interfaces

   The upgraded SEPP can now establish multiple N32-f connections with different roaming partners. This ensures that encrypted communication can be securely managed across several different operators, improving network security and reliability.

SEPP supports the following interfaces:

• N32-c interface ( TLS mode only)
• N32-f interface (TLS mode only)
• TLS v1.2 and v1.3

Figure 3-1 SEPP MNO functionality Support Architecture

This diagram illustrates the SEPP MNO Functionality Support feature, demonstrating how different mobile network operators (MNOs) securely communicate over N32 interfaces using SEPPs. The IPX functions as a bridge between SEPPs, facilitating secure and controlled interconnectivity between the home and visited PLMNs. This configuration simplifies roaming agreements, boosts security, and enhances scalability, enabling operators to manage multiple roaming partners effectively while maintaining a single, controlled entry and exit point for all external traffic.

Managing MNO Functionality

Enable

This feature is the core functionality of SEPP. You do not need to enable or disable this feature. It is enabled by default.

Configure

You can configure the SEPP MNO functionality using REST API, CNC Console, or helm parameters:

• Configure SEPP MNO functionality using REST API: Perform the feature configurations as described Remote SEPP section in Oracle Communications Security Edge Protection Proxy Rest API Guide.
• Configure SEPP MNO functionality using CNC Console: Perform the feature configurations as described in Configuring SEPP using CNC Console.

Configuring using Helm parameters

Set the local profile for the SEPP Instance.

ocalProfile:
  name: "SEPP-SVC"
  #Size of PLMN list can be configured through Helm parameter. The default value for minimum is 1 and maximum is 30 for SEPP mode and 900 for IPX mode
  plmnIdList: [{"mcc":"333","mnc":"222"},{"mcc":"444","mnc":"555"},{"mcc":"444","mnc":"55"}]
  # Do not change this value, this will be always true
  sbiTargetApiRootSupported: true
  # Enable PLMN ID List Validation in Exchange Capability Request, Default set to true
  n32cHandshakePlmnIdListValidationEnabled : true
  # PLMN ID List Validation Type in Exchange Capability Request, can be SUBSET or STRICT only
  n32cHandshakePlmnIdListValidationType: "SUBSET"
  # Enable PLMN ID List sending to Remote SEPP in Exchange Capability Request, Default set to true for SEPP Mode and false for RH Mode
  n32cHandshakePlmnIdListSend: true
  sanValidationRequired: true
  domain: "svc.cluster.com"
  seppViaVersion: "2.0"
  viaHeaderSeppViaInterFqdn: "2.0 SEPP-sepp2.inter.oracle.com"
  viaHeaderSeppViaIntraFqdn: "2.0 SEPP-ocsepp-plmn-ingress-gateway.seppsvc"
  interPlmnFqdn: *nfFqdnRef
  intraPlmnFqdn: "ocsepp-plmn-ingress-gateway.seppsvc"
  supportedSecurityCapabilityList:
   - "TLS"
  apiPrefix:  ""
  retryInterval: 300000
  maxRetry: -1
  nfInstanceId: *nfInstIdRef

To make this functionality work, we would require the following:

• Remote SEPP
• Remote SEPP Set
• NRF Registration

For more details, see Oracle Communications Security Edge Protection Proxy Rest API Guide.

Observe

For more information on support of N32-c and N32-f interface feature metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following:

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

3.1.2 NF Authentication using TLS certificate

HTTPS support is a minimum requirement for 5G NFs as defined in 3GPP TS 33.501.

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 SEPP

Certificate Creation

To create certificate user must have the following files:

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

Secret Creation

Execute the following command to create secret:

$ kubectl create secret generic ocseppaccesstoken-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_ocsepp_certificate.crt--from-file=desertification -n
    ocsepp

Certificate and Key Exchange

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

• Hello
• Certificate Exchange
• Key Exchange

1. Hello: The handshake begins with the client sending a ClientHello message. This contains all the information the server needs in order to connect to the client via SSL, including the various cipher suites and maximum SSL version that it supports. The server responds with a ServerHello, which contains similar information required by the client, including a decision based on the client’s preferences about which cipher suite and version of SSL will be used.
2. Certificate Exchange: Now that contact has been established, the server has to prove its identity to the client. This is achieved using its SSL certificate, which is a very tiny bit like its passport. An SSL certificate contains various pieces of data, including the name of the owner, the property (Example: domain) it is attached to, the certificate’s public key, the digital signature and information about the certificate’s validity dates. The client checks that it either implicitly trusts the certificate, or that it is verified and trusted by one of several Certificate Authorities (CAs) that it also implicitly trusts. The server is also allowed to require a certificate to prove the client’s identity, but this only happens in very sensitive applications.
3. Key Exchange: The encryption of the actual message data exchanged by the client and server will be done using a symmetric algorithm, the exact nature of which was already 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/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/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.

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

Sample values.yaml to enable HTTPS on SEPP:

 #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: ocsepp-n32-secret
   k8NameSpace: ocsepp
   rsa:
   fileName: rsa_private_key_pkcs1.pem
     
   certificate:
   k8SecretName: ocsepp-n32-secret
   k8NameSpace: ocsepp
   rsa:
   fileName: ocsepp.cer
   
   caBundle:
   k8SecretName: ocsepp-n32-secret
   k8NameSpace: ocsepp
   fileName: caroot.cer
     
   keyStorePassword:
   k8SecretName: ocsepp-n32-secret
   k8NameSpace: ocsepp
   fileName: key.txt
   
   trustStorePassword:
   k8SecretName: ocsepp-n32-secret
   k8NameSpace: ocsepp
   fileName: trust.txt
    
   initialAlgorithm: RS256
  

3.1.3 Dedicated Gateways for IntraPLMN and InterPLMN Traffic

In the earlier releases, a single gateway was used to support both intraPLMN and interPLMN traffic. This led to performance related issues in supported capacity and error handling procedures. To overcome these issues, the architecture was modified. The modification involves establishing dedicated set of gateways for intraPLMN traffic and interPLMN traffic. It also involves optimization of resources to prevent utilization of more resources by these dedicated gateways.This brings in flexibility of scaling the resources independently based on either intraPLMN traffic or interPLMN traffic.

The following diagram depicts the topology for dedicated gateways for IntraPLMN InterPLMN traffic.

Figure 3-2 Dedicated gateways for IntraPLMN InterPLMN traffic

Managing Dedicated Gateways for IntraPLMN and InterPLMN traffic

Enable

This feature is the core functionality of SEPP. You do not need to enable or disable this feature. It is enabled by default.

Configure

You can configure the Dedicated Gateways for IntraPLMN and InterPLMN traffic using helm parameters.

Observe

For more information on dedicated gateways for IntraPLMN and InterPLMN traffic feature metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following:

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

3.1.4 Support for Core Networks with or without SCP/ Routing Proxy

The SEPP can be deployed in networks where SCP or Routing Proxy is deployed. Routing rules in such scenarios changes. To handle such deployments, a configuration is now provided at the Home SEPP to assist in identifying if the SEPP must route the message to the intended producer or just forward it to the SCP (if deployed in the network) such that the SCP could take the decision to route to the right producer.

Managing Support for Core Networks with or without SCP/ Routing Proxy

Enable

This feature can be enabled or disabled though REST API. The configuration must be set in PLMN Egress gateway section.

Configure

You can configure the Support for Core Networks with or without SCP/ Routing Proxy using REST API:

Route Configuration with SCP and NRF with both Deployed in the Network

Following is the sample configuration provided for the mandatory routes that needs to be created on plmn-egress-gateway microservice.

Routing inter-plmn NRF requests to NRF present in the network and SBI traffic through SCP deployed in the network.

Routes Configuration

[
    {
        "id": "default_route",
        "uri": "egress://request.uri",
        "order": 100,
        "filters": [
            {
                "name": "DefaultRouteRetry"
            }
        ],
        "metadata": {
            "configurableErrorCodes": {
                "enabled": false,
                "errorScenarios": []
            }
        },
        "predicates": [
            {
                "args": {
                    "pattern": "/**"
                },
                "name": "Path"
            }
        ]
    },
    {
        "id": "route-scp",
        "uri": "http://scp.com",
        "order": 2,
        "filters": [
            {
                "args": {
                    "errorHandling": [
                        {
                            "priority": 1,
                            "actionSet": "actionats_0",
                            "errorCriteriaSet": "criteriaats_0"
                        }
                    ],
                    "peerSetIdentifier": "set0",
                    "customPeerSelectorEnabled": false
                },
                "name": "SbiRouting"
            }
        ],
        "metadata": {
            "httpRuriOnly": true,
            "httpsTargetOnly": true,
            "sbiRoutingEnabled": true
        },
        "predicates": [
            {
                "args": {
                    "pattern": "/**"
                },
                "name": "Path"
            }
        ]
    },
    {
        "id": "route-nrf",
        "uri": "http://nrf.com",
        "order": 1,
        "filters": [
            {
                "args": {
                    "errorHandling": [
                        {
                            "priority": 1,
                            "actionSet": "actionats_0",
                            "errorCriteriaSet": "criteriaats_0"
                        }
                    ],
                    "peerSetIdentifier": "set1",
                    "customPeerSelectorEnabled": false
                },
                "name": "SbiRouting"
            }
        ],
        "metadata": {
            "httpRuriOnly": true,
            "httpsTargetOnly": true,
            "sbiRoutingEnabled": true
        },
        "predicates": [
            {
                "args": {
                    "pattern": "/nnrf-*/**"
                },
                "name": "Path"
            }
        ]
    }
]

Note:

Peer configuration and Peerset configuration also needs to be added for SCP and NRF. For more information, see Egress Gateway REST APIs in Oracle Communications Cloud Native Core, Security Edge Protection Proxy REST Specification Guide.

Observe

For more information on Support for Core Networks with or without SCP/ Routing Proxy feature metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alerts still persists, perform the following:

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

3.1.5 DNS Support for Remote SEPP Resolution

SEPP to SEPP communication was enforced through configuring the IP address for the far end SEPP. Operators may choose to use a DNS instead and so the SEPP must use the DNS and resolve the IP address of the far end SEPP. This feature allows configuring only the FQDN for the far end SEPP and subsequently needing DNS resolution for identifying the IP address. This feature enhances flexibility to operators now use DNS instead of providing a static IP address.

Managing DNS Support for Remote SEPP Resolution

Enable

This feature is the core functionality of SEPP. You do not need to enable or disable this feature. It is enabled by default.

Configure

DNS configuration can be done in Kubernetes DNS of the cluster. No HELM or REST based configurations are required.

Observe

For more information on DNS support for remote SEPP resolution feature metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following:

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

3.2 SEPP Features

The following are SEPP features:

3.2.1 NRF Selection Mechanisms using nrf client

Overview

In previous releases, the SEPP selects the Network Repository Function (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 SEPP, which relies on the NRF for specific communications, may experience service disruptions.

This feature allows the SEPP 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 SEPP can now resolve NRFs using DNS SRV-based Fully Qualified Domain Names (FQDNs). The SEPP 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 SEPP find and select different Network Repository Functions (NRFs) by using DNS SRV-based lookups. This service allows the SEPP to translate Fully Qualified Domain Names (FQDNs) or virtual FQDNs into alternate NRF addresses. This setup enables the SEPP to prioritize and adjust connections to different NRFs based on specific service needs.

Figure 3-3 Architecture Diagram of NRF Selection Mechanisms Using nrf client

All Inter-PLMN SBI requests follow the same call flow route through the SEPP, except for Inter-PLMN NRF requests, specifically, discovery and subscription requests. These are redirected to the nrf-client microservice.

The selection of the target NRF is determined by configurations set by the operator within the nrf-client. This selection can be:

• Static-based, using primary and secondary apiRoot values, or
• DNS-SRV-based, leveraging service discovery mechanisms.

Once all target NRFs have undergone health checks, the final route list is updated accordingly.

Call Flow of NRF Selection Mechanisms Using nrf client

Figure 3-4 Call Flow of NRF Selection Mechanisms Using nrf client

1. DNS SRV Record Lookup: The SEPP starts by using DNS SRV records to fetch information about the FQDN of the primary NRF and alternate NRFs.
2. DNS Query: The DNS server receives a query from the SEPP to resolve the FQDN of the primary NRF or alternate NRFs.
3. DNS Resolution: The DNS server resolves the FQDN and returns the resolved address for the primary NRF or one of the alternate NRFs.
4. NRF Identification by SEPP: Based on the FQDN provided by DNS, the SEPP identifies the primary NRF to communicate with. If the primary NRF is unavailable, the SEPP uses one of the alternate NRFs.
5. Static Configuration Option: Alternatively, the SEPP can rely on a static configuration of the primary and alternate NRFs instead of querying DNS.
6. Request Preparation: Once an NRF (primary or alternate) is identified, the SEPP prepares the request to be sent to the selected NRF.
7. Communication with NRF: The SEPP 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 SEPP uses a component called nrf-client to facilitate communication with NRFs. The nrf-client performs critical functions to ensure NRFs remain available and responsive:

1. Traffic Routing: The nrf-client directs all requests (for example, registration, updates, heartbeats, and discovery) to the primary NRF.
2. 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.
3. 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 SEPP. This one-time attempt helps avoid repeated failures and ensures alternate routing to secondary NRFs when needed.

• When using nrf-client for NRF requests, note the following:

  • Messages with Content-Encoding: gzip are not supported.
  • Messages with Content-Type: multipart are not supported.

Managing Static Based Selection of NRF in SEPP

This section provides information about Helm configurations required to configure static based selection of NRF in SEPP.

If enableVirtualNrfResolution is set to false, the nrf-client will use the configured values of primaryNrfApiRoot and secondaryNrfApiRoot to register with the NRF (Network Repository Function) directly.

You can enable this feature using Helm configurations. To do so, you must set the following Helm parameters:

primaryNrfApiRoot= ocnrf-ingressgateway.ocnrf:80
secondaryNrfApiRoot= ocnrf-2-ingressgateway.ocnrf-sepp:80
nrfScheme=http

If the primaryNrfApiRoot is unavailable, then nrf-client shall retry to the configured secondaryNrfApiRoot FQDN. The parameter nrfScheme determines whether connection to NRF will be establish over HTTP or HTTPs.

The nrfRetryConfig parameter defines the conditions under which nrf-client will attempt retries with alternate NRFs. .

nrfRetryConfig=[{"serviceRequestType":"ALL_REQUESTS","primaryNRFRetryCount":1,"nonPrimaryNRFRetryCount":1,"alternateNRFRetryCount":-1,"errorReasonsForFailure":["503","504","500","SocketTimeoutException","JsonProcessingException","UnknownHostException","NoRouteToHostException","IOException"],"gatewayErrorCodes":["503"],"requestTimeout":10},{"serviceRequestType":"AUTONOMOUS_NFREGISTER","primaryNRFRetryCount":1,"nonPrimaryNRFRetryCount":1,"alternateNRFRetryCount":-1,"errorReasonsForFailure":["503","504","500","SocketTimeoutException","JsonProcessingException","UnknownHostException","NoRouteToHostException","IOException"],"gatewayErrorCodes":["503"],"requestTimeout":10}]

Note:

For ASM setups, scheme would always be set to 'http.'

Managing NRF Selection Mechanisms Using nrf client

This section provides information about Helm configurations required to configure DNS SRV based selection of NRF in SEPP.

Enable

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

enableVirtualNrfResolution=true
virtualNrfFqdn=nrf.oracle.com
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.

The parameter nrfScheme determines whether connection to NRF will be establish over HTTP or HTTPs.

Note:

For ASM setups, scheme would always be set to 'http.'

For more details on additional Helm parameters related to this feature, refer to the Helm configuration section below.

Managing Health Check of NRF in SEPP

The NRFClient performs health checks on all configured NRFs and keeps a list of healthy ones to use for service requests. NRFs can be configured in two ways:

• Statically (using direct FQDNs), or
• Dynamically (through DNS query using a virtual FQDN).

If the HealthCheck feature is enabled, it starts after the NF has successfully registered with an NRF. To ensure there is at least one healthy NRF available for session-based requests, the NRF used for the successful registration is automatically treated as healthy.

Enable

You can enable this feature using Helm configurations. To do so, you must set the following mandatory Helm parameters:

healthCheckConfig={"healthCheckCount":1,"healthCheckInterval":5,"requestTimeout":10,"errorReasonsForFailure":["503","504","500","SocketTimeoutException","IOException"],"gatewayErrorCodes":[]}

Configure

Helm Configurations

To enable this feature, configure the following nrf-client Helm parameters in ocsepp_custom_values_<versions>.yaml file.

pn32f-svc:
nrfTrafficRedirection: true

profile: |-       
           [appcfg]
           primaryNrfApiRoot= ocnrf-ingressgateway.ocnrf:80
           secondaryNrfApiRoot=
           nrfScheme=http
           retryAfterTime=PT120S
           nrfClientType=SEPP
           nrfClientSubscribeTypes=
           appProfiles= [{"nfInstanceId":"9faf1bbc-6e4a-4454-a507-aef01a101a06","nfType":"SEPP","nfStatus":"REGISTERED","heartBeatTimer":30,"fqdn":"ocsepp-plmn-ingress-gateway.DEPLOYMENT_NAMESPACE","plmnList": [{"mcc": "333","mnc": "222"},{"mcc": "444","mnc": "555"},{"mcc":"444","mnc":"55"}],"capacity":500,"locality":"delhi","priority":1 ,"nfSetIdList":["set001.seppset.5gc.mnc444.mcc555","set001.seppset.5gc.mnc222.mcc333"]}]
           registrationRetryInterval=5000
           subscriptionRetryInterval=5000
           enableDiscoveryRefresh=false
           discoveryRetryInterval=5000
           discoveryRefreshInterval=10
           discoveryDurationBeforeExpiry=90
           renewalTimeBeforeExpiry=3600
           validityTime=30
           enableSubscriptionAutoRenewal=true
           nfHeartbeatRate=80
           acceptAdditionalAttributes=false
           retryForCongestion=5
           supportedDataSetId=
           enableVirtualNrfResolution=false
           virtualNrfFqdn=nrf.oracle.com
           virtualNrfScheme=http
           subscriberNotificationInterval=1000
           requestTimeoutGracePeriod=2
           nrfRetryConfig=[{"serviceRequestType":"ALL_REQUESTS","primaryNRFRetryCount":1,"nonPrimaryNRFRetryCount":1,"alternateNRFRetryCount":-1,"errorReasonsForFailure":["503","504","500","SocketTimeoutException","JsonProcessingException","UnknownHostException","NoRouteToHostException","IOException"],"gatewayErrorCodes":["503"],"requestTimeout":10},{"serviceRequestType":"AUTONOMOUS_NFREGISTER","primaryNRFRetryCount":1,"nonPrimaryNRFRetryCount":1,"alternateNRFRetryCount":-1,"errorReasonsForFailure":["503","504","500","SocketTimeoutException","JsonProcessingException","UnknownHostException","NoRouteToHostException","IOException"],"gatewayErrorCodes":["503"],"requestTimeout":10}]
           healthCheckConfig={"healthCheckCount":1,"healthCheckInterval":5,"requestTimeout":10,"errorReasonsForFailure":["503","504","500","SocketTimeoutException","IOException"],"gatewayErrorCodes":[]}

# Flag to determine if honoring Requester-Nf-Type is to be taken from query parameter or not
  discoveryHonoringRequesterNfTypeEnabled: true

Note:

This is a sample configuration. Modify the parameters as per your setup. For detailed information about the Helm parameters, see the "Customising SEPP " section in the Oracle Communications Cloud Native Core, Security Edge Protection Proxy Installation, Upgrade, and Fault Recovery Guide.

.

Table 3-1 NRF Retry Configuration Parameters

Name	Description	Details
serviceRequestType	This is a mandatory parameter. The NRF service request type.	Data Type: String Range: ALL_REQUESTS, AUTONOMOUS_NFREGISTER, AUTONOMOUS_NFSTATUS_SUBSCRIBE, AUTONOMOUS_NFUNSUBSCRIBE, AUTONOMOUS_NFSUBSCRIBE_UPDATE, AUTONOMOUS_NFDISCOVER, AUTONOMOUS_NFHEARTBEAT, AUTONOMOUS_NFPATCH(, NFREGISTER, NFUPDATE, NF_STATUS_SUBSCRIBE, NFDISCOVER, NF_SUBSCRIBE_UPDATE, NF_UNSUBSCRIBE, NFDEREGISTER, NF_PROFILE_RETRIEVAL, NF_LIST_RETRIEVAL, Note: ALL_REQUESTS is mandatory service type. All additional service types can be appended to the list based on requirement. Default Value: NA
primaryNrfRetryCount	This is an optional parameter. Number of times a service request shall be retried to the primary NRF in case of failure.	Data Type: Integer Range: NA Default Value: NA
nonPrimaryNrfRetryCount	This is an optional parameter. Number of times a service request shall be retried to the non-primary NRF in case of failure.	Data Type: Integer Range: NA Default Value: NA
alternateNRFRetryCount	This is an optional parameter. Number of alternate NRFs that shall be retried in case of failure.	Data Type: Integer Range: NA Default Value: NA Note: A value of -1 indicates all available NRF instances are to be tried.
errorReasonsForFailure	This is an optional parameter. The http status codes or exceptions for which retry shall be applied.	Data Type: Array[String] Range: [ (All non 2xx HTTP status codes),"SocketTimeoutException","JsonProcessingException","UnknownHostException","NoRouteToHostException"] Default Value: NA
requestTimeout	TThis is an optional parameter. Indicates the timeout period where no response is received from the Egress Gateway. Unit: seconds	Data Type: Integer Range: NA Default Value: 10 seconds
gatewayErrorCodes	This is an optional parameter. The http status codes sent by the egress-gateway for which retry shall be applied.	Data Type: Array[String] Range: All HTTP Status codes Default Value: NA

Table 3-2 Health Check Parameters

Name	Description	Details
healthCheckCount	This is an optional parameter. The number of consecutive success or failures required to mark an NRF healthy or unhealthy.	Data Type: Integer Range: -1,Values greater than 0. -1 (denotes that the feature is disabled) Default Value: NA
healthCheckInterval	This is an optional parameter. The interval at which a health check of an NRF shall be performed. Unit: seconds.	Data Type: Integer Range: 5 seconds Default Value: NA
requestTimeout	This is an optional parameter. The timeout period where no response is received from the egress-gateway. Unit: seconds	Data Type: Integer Range: 10 seconds Default Value: NA
errorReasonsForFailure	This is an optional parameter. The http status codes or exceptions for which retry shall be applied.	Data Type: Array[String] Range: ["503","500",504","SocketTimeoutException","JsonProcessingException","UnknownHostException","NoRouteToHostException"] Default Value: NA
gatewayErrorCodes	This is an optional parameter. The http status codes sent by the Egress Gateway for which retry shall be applied.	Data Type: Array[String] Range: ["503","500",504","SocketTimeoutException","JsonProcessingException","UnknownHostException","NoRouteToHostException"] Default Value: NA

REST API

There are no REST API configurations required for this feature.

CNC Console

There are no CNC Console configurations required for this feature.

Observe

Metrics

The following metric is available for this feature:

• nrfclient_nrf_operative_status
• nrfclient_dns_lookup_request_total

For more information about metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following:

1. Collect the logs and Troubleshooting Scenarios: For more information on how to collect logs and troubleshooting information, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

3.2.2 Integrating SEPP with 5G Network Intelligence Fabric (5G NIF)

To route traffic to a Network Function (NF), SEPP traditionally relied on configurations or destination headers received in the incomingSBI request. For integration with the 5G Network Intelligence Fabric (5GNIF), in networks which have a custom Roaming Value Added Service Network Function (RVAS NF), routing has to be done based on certain information contained in the NRF. SEPP has to discover this NF and then route accordingly.

The 5GNIF, which provides value-added services, also requires the ability to analyze errors generated by SEPP microservices, particularly those caused by security mechanisms such as SCM (Security Countermeasures), TH (Topology Hiding) or Mediation. To support this, any rejected message at SEPP will be encapsulated in a predefined format and forwarded to 5GNIF for analytical purposes.

5G NIF is an inline network function and resides in the home network. All requests and responses to home network functions will pass through the 5G NIF for roaming scenarios.

Feature Overview

The 5G Network Intelligence Fabric (5GNIF) is a vital component, enabling essential capabilities such as Steering of Roaming (SoR), mobility management, and threat intelligence.

These features ensure that subscribers enjoy seamless, secure connectivity when accessing partner networks, delivering both a superior user experience and strong protection against evolving threats.

Below are the key functionalities enabled through 5GNIF integration:

Enabling NIF

When SEPP needs to route traffic, it begins by querying the NRF (Network Repository Function) to discover the 5GNIF. Once the 5GNIF is identified, SEPP manages incoming N32f/SBI traffic by setting routing headers—such as scheme, authority, and path, to ensure all messages pass securely and efficiently through the 5GNIF. This routing ensures secure and efficient message handling in both outbound and inbound communication communications.

Figure 3-5 Enabling NIF

Error message forwarding to 5GNIF

When features like Security Countermeasures (SCM), Mediation, or Topology Hiding (TH) are enabled, SEPP performs strict validation on incoming SBI requests. If a request fails these checks, for example, due to an invalid header, incorrect URI, or malformed message body, SEPP rejects the request using a predefined error code and response.

In deployments where the 5GNIF is integrated, SEPP also sends a copy of both the rejected message and its corresponding error response to the 5GNIF. This enables the 5GNIF to analyze these messages for analytics, diagnostics, and operational optimization, supporting smarter decision-making and improved network performance.

Figure 3-6 Error message forwarding to 5GNIF

Detailed Description

To integrate 5GNIF with SEPP and enable dynamic discovery of 5GNIF instances, users must first enable the integration feature. Once enabled, the config-mgr-svc service periodically sends an NFDiscovery request (/nnrf-disc/*), with requester-nf-type set to SEPP and target-nf-type set to CUSTOM_5GNIF. Optionally, users can include a preferred-locality query parameter to prioritize specific regions.

This request is passed to the nrf-client-nfdiscovery microservice, which manages retrieving the configuration NRF (Network Repository Function). If a virtual FQDN is configured, the microservice first consults the alternate-route service to perform DNS resolution.

After successfully resolving the FQDN, the nrf-client-nfdiscovery forwards the request to the PLMN Egress Gateway, which selects the appropriate route based on the request and directs it to the correct NRF instance.

The NRF then returns an NFProfile, completing the discovery and enabling SEPP to dynamically configure routing to the available 5GNIF instances.

The NRF responds with an NFProfile response.

Example for NFProfile for NIF

{
    "nfInstanceId": "cd2c976c-ba95-4d45-b71d-d68a3e761885",
    "nfType": "CUSTOM_5GNIF",
    "nfStatus": "REGISTERED",
    "heartBeatTimer": 30000,
    "plmnList": [
        {
            "mcc": "311",
            "mnc": "480"
        }
    ],
    "fqdn": "5gnif.mnc480.mcc311.3gppnetwork.org",
    "priority": 1,
    "capacity": 1000,
    "load": 10,
    "locality": "SouthLake",
    "customInfo": {
        "port": 8000,
        "scheme": "http"
    },
    "nfSetIdList": [
        "set001.nifset.5gc.mnc480.mcc311"
    ]
}

NIF Instance Selection and Traffic Routing

The following diagram provides a high level view of NIF Instance selection and traffic routing process:

Figure 3-7 NIF Instance Selection and Traffic Routing

NIF Selection and Routing Logic

After receiving one or more NFProfile responses from the NRF, the config-mgr-svc selects the appropriate NIF (Network Intelligence Fabric) instances based on the priority field in each profile. NIF peers and their corresponding routes are then established using a primary, secondary, and, tertiary hierarchy to ensure high availability and failover support.

Peer configuration is based on the following logic:

• If multiple NFProfiles are received, the priority field is used to determine the order of peers in the peer set.
• The fqdn field in the profile is used to populate the host field in the peer configuration.
• Port information is extracted from the customInfo block:
  • If the scheme is HTTP and no port is specified, port 80 is used by default.
  • If the scheme is HTTPS, the NFProfile is rejected, and an error is logged, as HTTPS is not supported for NIF peer connections.

Once the peers are configured, this information is forwarded to the PLMN Egress Gateway.

Traffic Routing via PLMN Egress Gateway

When an SBI request is received, the PLMN Egress Gateway selects the appropriate route to the NIF, starting with the primary peer:

• If the primary peer is unavailable or down, traffic is automatically rerouted to the secondary peer.
• If both primary and secondary are unavailable, the traffic is sent to the tertiary peer.

This hierarchical fallback mechanism ensures continued service availability and reliability.

Handling NIF Discovery Failures

If SEPP fails to discover any NIF instance from the NRF, or if all discovered instances transition into a SUSPENDED or UNDISCOVERABLE state, then all incoming SBI traffic is rejected with a configured error code.

Once the NIF instances become discoverable again, SEPP resumes normal processing of SBI traffic without requiring manual intervention.

Routing Information:

The following table contains summary for routes created for each event:

Table 3-3 Routing Information

S.No.	Event	Routes Present
1	Fresh installation	default_route
2	NIF feature enabled/NIF not discovered	nrf_route nif_reject
3	NIF Discovered	nrf_route nifPeer
4	NIF Disable	default_route
5	NFDiscovery returns 200 OK Empty for NIF profile.	nrf_route nif_reject
6	NRF change in NIF instances.	Only Peer Configuration change, No route change
7	Cat-3 feature is enabled when NIF is enabled (previous location or velocity).	nrf_route nifPeer cat3_udr_route cat3_udm_route

Rejected Message Handling and Forwarding to 5GNIF

When features such as Security Countermeasure (SCM), Topology Hiding (TH), or Mediation are enabled, or if any SAN validation failures occur, SEPP performs strict validation on all incoming SBI requests. If a request contains invalid information in the header, URI, or body, SEPP rejects it using a configured error code and response.

If the 5GNIF has already been discovered in the deployment, SEPP also generates a copy of the rejected request and the corresponding error response. This copy is forwarded to the 5GNIF, which then processes the information for analytics, diagnostics, and other operational insights.

Managing Integration of SEPP with 5G NIF

This feature can be enabled by using the Helm parameters, CNC Console, or REST API.

Enable using Helm Parameter

Set the sepp.headerAbsentPredicate parameter to true in the PLMN Egress Gateway section of ocsepp_custom_values_<version>.yaml file.

sepp.headerAbsentPredicate: true

Set the nif.enableNif parameter to true in the Config Manager section of ocsepp_custom_values_<version>.yaml file.

nif.enableNif: true

For more information about the Helm parameters, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy Installation, Upgrade, and Fault Recovery Guide.

Enable using REST API

Enable the NIF feature:

Set enabled to true in /sepp-configuration/v1/nif/options REST API.

curl 'http://<config-mgr-svc>:<port>/sepp-configuration/v1/nif/options -XPUT -H 'Content-type: application/json' -d '{"enabled": "true"}'

Enable the Rejected Message copy feature:

Set enabled to true in /sepp-configuration/v1/nif/options REST API.

curl 'http://<config-mgr-svc>:<port>/sepp-configuration/v1/nif/msg-copy/options -XPUT -H 'Content-type: application/json' -d ' {"enabled" : "true"}'

For more information about API path, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy REST Specification Guide.

Enable using CNC Console

Enable the NIF feature:

1. From the left navigation menu, navigate to SEPP and then click NIF.
2. Click NIF Option under NIF. The System Option page appears at the right pane.
3. Click Edit icon to modify the Option. The Edit System Option page appears.
4. Set the Enable NIF route selection to True.

Enable the Rejected Message copy feature:

1. From the left navigation menu, navigate to SEPP and then click NIF.
2. Click Message Copy Option under NIF. The System Option page appears at the right pane.
3. Click Edit icon to modify the Option. The Edit System Option page appears.
4. Set the Enable Error Message Copy to True.

For more details about CNC Console configurations, see Configuring SEPP using CNC Console section in the Oracle Communications Cloud Native Core, Security Edge Protection Proxy User Guide.

Configure

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

• Configure using REST API: Perform the feature configurations as described in NIF REST APIs in Oracle Communications Cloud Native Core, Security Edge Protection Proxy REST Specification Guide.
• Configure using CNC Console: Perform the feature configurations as described NIF section in Configuring SEPP using CNC Console.

Observe

Following are the Integrating SEPP with 5G Network Intelligence Fabric (5G NIF) feature specific metrics:

• ocsepp_nif_discovery_requests_total
• ocsepp_nif_discovery_responses_total
• ocsepp_nif_registration_status
• ocsepp_pn32f_nif_error_copy_requests_total
• ocsepp_pn32f_nif_error_copy_responses_total

Following are the Integrating SEPP with 5G Network Intelligence Fabric (5G NIF) feature specific KPIs:

• Discovery Requests Sent Towards NRF for NIF
• Response Received from NRF for NIF Discovery
• Rejected Message Copied towards NIF
• Responses Received from NIF for Copied Messages

Following is the Integrating SEPP with 5G Network Intelligence Fabric (5G NIF) feature specific alert:

• configMgrNoHealthyNIFAlert

For more information on Support for Originating Network Id Header Validation, Insertion, and Transposition feature related SEPP Metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following:

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

3.2.3 LCI and OCI Headers in 5G Architecture

Background

In 5G architecture, network overloads can happen frequently because of the high volume of data exchange between producer and consumer Network Functions (NFs). This communication includes many messages and notifications, making efficient load balancing critical to prevent network failures. To manage this, it's important that consumer NFs or the Security Edge Protection Proxy (SEPP) are quickly notified in outgoing responses when a producer NF or SEPP is approaching an overload condition. This early notification allows consumer NFs or SEPP to take preventive actions and reduce the risk of service disruption.

Overview

To address these challenges, Load Control Information (LCI) and Overload Control Information (OCI) headers plays a critical role in optimizing communication between SEPP instances and their consumer Network Functions (NFs). These headers give consumer NFs and SEPPs real-time information about the current load and status of SEPP or peer SEPP resources, making traffic management more efficient.

By including important load and overload data, the headers help consumer NFs or SEPPs better distribute traffic and respond early to potential overloads. These headers are added to responses sent from the SEPP and show the load status at the Ingress Gateway (N32/PLMN). They allow SEPPs to share key load details, helping the 5G Core Network stay stable and perform reliably, even when traffic is high.

Architecture

Figure 3-8 Architecture

In the above diagram, the LCI/OCI Header support feature is enabled on the consumer SEPP over the PLMN-Ingress-gateway and towards the producer SEPP over the N32-Ingress-gateway.

The request and response flow:

1. Request Flow:
   • The request is initiated from the consumer NF at the Initiator Side.
   • The request passes through the Initiator SEPP, reaching the Responder SEPP, and finally the producer NF.
2. Response Flow:
   • Once the producer NF processes the message, a response is generated and sent back to the consumer NF.
   • The response passes through the Responder SEPP and then the Initiator SEPP.
3. LCI/OCI Header Integration:
   • At the producer SEPP, the LCI and OCI headers are added to the outgoing response, carrying load information for the Responder SEPP. This load information is essential for the consumer SEPP to help with load balancing and traffic adjustments.
   • As the response passes through the Initiator SEPP, the Initiator SEPP may add (depending on configurations) its load information in the LCI Header and overload reduction metrics in the OCI Header with SEPP Scope.
   • The LCI/OCI headers added by the Initiator SEPP can be utilized by the consumer NF for load adjustments.

Example for the LCI header (Entire message body is not shown here):

 HTTP/2 201
         content-length: 3953 
         content-type: application/3gppHal+json
         3gpp-sbi-lci: Timestamp: “Fri, 07 Mar 2025 11:16:12 UTC”; Load-Metric: 14%; SEPP-FQDN:
         sepp1.example.com
         

Example for the OCI header (Entire message body is not shown here):

 HTTP/2 201
         content-length: 3953 
         content-type: application/3gppHal+json
         3gpp-sbi-oci: Timestamp: “Fri, 07 Mar 2025 11:16:12 UTC”; Period-of-Validity: 5s;
      Overload-Reduction-Metric: 5.0%; SEPP-FQDN: sepp1.example.com 

Note:

When reporting OCI header, the LCI header may also be included.

This feature can be enabled either on the N32-Ingress-gateway, PLMN-Ingress-gateway, or on both gateways. Load computation for SEPP is carried out by the ingress gateway using the perf-info load collection functionality. This approach helps in ensuring that load information is shared effectively between SEPPs.

LCI Header

The LCI header shares the current load status of the SEPP. This helps the consumer NF or consumer SEPP manage and balance network traffic more effectively. The header is called 3gpp-Sbi-Lci. When the conditions for generating LCI Header are met, the SEPP adds this header at the SEPP-level scope. The LCI header comprises overall load related information such as the timestamp of load data generation, the current load of the SEPP, and the scope of the load information.

Example of LCI Headers

SEPP Scope LCI Header:

3gpp-Sbi-Lci: Timestamp: "Tue, 04 Apr 2021 08:36:42 GMT"; Load-Metric: 25%; SEPP-FQDN: sepp1.example.com

• SEPP scope LCI header: The Ingress Gateway has a configurable polling interval for retrieving service-level load information from perf-info. It conducts load aggregation for supported SEPP services at the SEPP level, utilising a straightforward averaging logic. The determination of supported services relies on the NF service to instance ID mapping, carried out through Helm. When this feature is enabled over plmn-ingress-gateway, SEPP core service cn32f-svc is considered for load computation and when this feature is enabled over n32-ingress-gateway, SEPP core service pn32f-svc is considered for load computation. The load aggregation needs to be configured in NF service to instance ID mapping for both n32-ingress-gateway and plmn-ingress-gateway.

  In SEPP, load mapping is specifically supported only for the cn32f-svc and pn32f-svc services. This means SEPP handles load information only for these two services. For example, when the Ingress Gateway receives load data for one of these services, it includes that information in the LCI or OCI header, specifically under the SEPP scope LCI header. The Ingress Gateway uses a configurable polling interval to regularly collect service-level load data from perf-info, which is then used to generate these headers.

OCI Header

The OCI header communicates information about overload conditions. This header sends the current overload information so that the Consumer NF or peer SEPP can reduce the traffic towards the overloaded NF. 3gpp-Sbi-Oci denotes OCI Header. When the conditions for generating OCI Header are met, the SEPP includes this header at the SEPP scope.

The OCI header includes important details such as:

• The time the overload was detected
• The type of overload (for example, resource exhaustion)
• The recommended action, like reducing the number of incoming requests.

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

• The LCI header conveys the overall load of a SEPP, 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 consumer NFs/consumer SEPP take informed actions to mitigate these conditions.
• The LCI and OCI headers complement each other, allowing a consumer NF/SEPP to reduce the number of requests it sends to other SEPPs in response to an OCI header, even if its overall load is not yet overloaded.
• This proactive measure prevents overload conditions from spreading.

Examples of OCI Headers

SEPP Scope OCI Header:

Overload Control Information sent by an SEPP:

3gpp-Sbi-Oci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Period-of-Validity: 120s; Overload-Reduction-Metric: 25%; SEPP-FQDN: sepp1.example.com

Note:

For both LCI and OCI headers, load reporting is based on two factors: localLciHeaderValidity and loadThreshold. The localLciHeaderValidity determines how long the load information is valid. Once the validity period expires, the loadThreshold value is no longer considered. The threshold value will be validated only within the validity period.

Use Cases

• Currently, LCI and OCI headers are only supported at the Ingress Gateway.
• The Initiator SEPP can use the LCI header to share its load information with the consumer NF. This helps the consumer NF decide whether to send new inter-PLMN requests to other available SEPPs, if any, or reduce the number of requests sent to the Initiator SEPP.
• The Responder SEPP can use the LCI header to share its load information with the Initiator SEPP. This helps the Initiator SEPP decide whether to route new requests to other available peer SEPPs, if any, or to reduce the number of requests sent to the Responder SEPP.
• On the other hand, the SEPP can use the OCI header to inform the consumer NF or Initiator SEPP about an overload condition. This allows them to reduce the number of requests being sent to the overloaded SEPP.

Overload Reduction Metric

The Overload-Reduction-Metric value (which indicates the percentage of traffic the OCI sender wants the receiver to reduce) is calculated based on the current load of the SEPP’s core microservices.

When this feature is enabled on the n32-Ingress-Gateway, it monitors the load of the pn32f-svc microservice to report the metric to the consumer SEPP. Similarly, when enabled on the plmn-Ingress-Gateway, it monitors the load of the cn32f-svc microservice for the same purpose.

The following tables indicates the overload config range and Overload-Reduction-Metric:

Table 3-4 Feature Enabled on n32-ingress-gateway

SEPP core service monitored for load/overload condition	overload config range	overload reduction metric	Details
pn32f-svc	minor: "[60-70]" major: "[70-80]" critical: "[80-100]"	minor: 5 major: 10 critical: 30	When SEPP is acting as a Responder SEPP during live traffic, it monitors the CPU load of the pn32f-svc microservice. If an overload is detected, it is reported using the OCI header with an appropriate Overload-Reduction-Metric based on the load level: 60% to 70% load → Minor overload: 5% traffic reduction is requested. 70% to 80% load → Major overload: 10% traffic reduction is requested. 80% to 100% load → Critical overload: 30% traffic reduction is requested. 0% to 60% load → No overload: OCI header is not sent.

Table 3-5 Feature Enabled on plmn-ingress-gateway

SEPP core service monitored for load/overload condition	overload config range	overload reduction metric	Details
cn32f-svc	minor: "[60-70]" major: "[70-80]" critical: "[80-100]"	minor: 5 major: 10 critical: 30	When SEPP acts as an Initiator SEPP during live traffic, it monitors the CPU load of the cn32f-svc microservice. If an overload is detected, it is reported using the OCI header with the following Overload-Reduction-Metric based on the load level: 60% to 70% load → Minor overload: 5% traffic reduction is requested. 70% to 80% load → Major overload: 10% traffic reduction is requested. 80% to 100% load → Critical overload: 30% traffic reduction is requested. 0% to 60% load → No overload: OCI header is not sent.

LCI and OCI Header Priorities

The SEPP must extract the consumer NF identity from one of the following request headers at the n32 or plmn ingress gateway:

1. oAuth token (1st priority)
2. User-Agent (2nd priority)
3. Via (3rd priority)

If multiple headers are available, the consumer NF identity should be extracted based on the priority order listed above.

The nf Instance id is extracted from these headers, and this Instance id serves as the key to identify the consumer NF. Below are examples of how to extract the nf Instance id:

oAuth Token Header

• Authorization: NF instance ID is extracted by decoding the following token:

  eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiJ9.eyJpc3MiOiI2ZmFmMWJiYy02ZTRhLTQ0NTQtYTUwNy1hMTRlZjhlMWJjMTEiLCJzdWIiOiJmZTdkOTkyYi0wNTQxLTRjN2QtYWI4NC1jNmQ3MGIxYjAxYjEiLCJhdWQiOiJTTUYiLCJzY29wZSI6Im5zbWYtcGR1c2Vzc2lvbiIsImV4cCI6MTY0NDQ5MjExOH0.xGud7dIwEugyXV-I8M-xld9OAr_rKbB3y4_SWVVAwHyb6DxtWUz5uB-KtXwozbRJorMNkF6rwz5D0G6VAm9WLw
  

User-Agent Header

• User-Agent: NF Type and Instance ID are extracted in the format:

  NFType-NFInstanceId fqdn SEPP-9faf1bbc-6e4a-4454-a507-aef01a101a06 sepp1.example.com
  

Via Header

• Via: NF instance ID isn’t part of the Via header, so the fqdn is used as the required key:

  2.0 via: 2.0 sepp1.example.com
  

In this case, the fqdn (Fully Qualified Domain Name) from the Via header acts as the identifying key.

Managing LCI and OCI Headers

Enable

The LCI and OCI Headers feature can be enabled by performing the following Helm configurations globally.

Global Helm Configuration

User can enable LCI and OCI headers globally at the SEPP level for the gateways by setting specific configuration parameters:

• To enable them at the n32-ingress-gateway level, set:

  seppLciEnabledN32Ingress = true

  seppOciEnabledN32Ingress = true

• To enable them globally at the plmn-ingress-gateway level, set:

  seppLciEnabledPlmnIngress = true

  seppOciEnabledPlmnIngress = true

Th following settings control whether LCI and OCI headers are included in messages handled by each gateway.

#===LCI/OCI header Global Values====
  #Enabling LCI over N32-Ingress
  seppLciEnabledN32Ingress: &n32IngressLciEnable true

  #Enabling OCI over N32-Ingress
   seppOciEnabledN32Ingress: &n32IngressOciEnable true

  #Enabling LCI over PLMN-Ingress
  seppLciEnabledPlmnIngress: &plmnIngressLciEnable true

  #Enabling OCI over PLMN-Ingress
  seppOciEnabledPlmnIngress: &plmnIngressOciEnable true
 #=====================================

Configure

In the perf-info section, modify the parameter configmapPerformance.prometheus according to the prometheus service deployed in the cluster.

If the Prometheus UI has cluster-name appended to it, modify the parameter as follows:

http://occne-kube-prom-stack-kube-prometheus.occne-infra:80/<clustername>

Example:

http://occne-kube-prom-stack-kube-prometheus.occne-infra:80/cluster1

Note:

Perform a Helm upgrade after applying the above customizations, if SEPP has already been deployed.

N32 Ingress Gateway Helm Configuration

OCI configuration
  
    ociHeaderConfig:
      enabled: *n32IngressOciEnable
      validityPeriod: 5000 #(value in milliseconds)
      overloadConfigRange: #Note - minor, major and critical conditions should be broken down in buckets of range [0 to 100] only both inclusive for it to be a valid config
        minor: "[60-70]"
        major: "[70-80]"
        critical: "[80-100]"
      reductionMetrics:
        minor: 5 #(Possible values 1 to 9 both inclusive)
        major: 10 #(Possible values 5 to 15 both inclusive)
        critical: 30 #(Possible values 10 to 50 both inclusive)
           
    nfInstanceId: *nfInstIdRef  #Producer NF Instance ID
    nfType: "SEPP"
    nfFqdn: *nfFqdnRef
           
    svcToSvcInstanceIdMapping:
      - svcName: "pn32f-svc"
        serviceInstanceId: *nfInstIdRef
  
LCI configuration
  
  lciHeaderConfig:
      enabled: *n32IngressLciEnable
      loadThreshold: 40
      localLciHeaderValidity: 10000 #(value in milliseconds)
 
  
 perf info configuration
  
   perfInfoConfig:
      pollingInterval: 5000 #(value in milliseconds)
      serviceName: ""
      host: <release-name>-sepp-perf-info # it should be replaced by correct release name
      port: 5905
      perfInfoRequestMap: "/load"

PLMN Ingress Gateway Helm Configuration

OCI configuration
  
    ociHeaderConfig:
      enabled: *plmnIngressOciEnable
      validityPeriod: 5000 #(value in milliseconds)
      overloadConfigRange: #Note - minor, major and critical conditions should be broken down in buckets of range [0 to 100] only both inclusive for it to be a valid config
        minor: "[60-70]"
        major: "[70-80]"
        critical: "[80-100]"
      reductionMetrics:
        minor: 5 #(Possible values 1 to 9 both inclusive)
        major: 10 #(Possible values 5 to 15 both inclusive)
        critical: 30 #(Possible values 10 to 50 both inclusive)
     
    nfInstanceId: *nfInstIdRef  #Producer NF Instance ID
    nfType: "SEPP"
    nfFqdn: *nfFqdnRef
     
    svcToSvcInstanceIdMapping:
      - svcName: "cn32f-svc"
        serviceInstanceId: *nfInstIdRef
  
LCI configuration
  
  lciHeaderConfig:
      enabled: *plmnIngressOciEnable
      loadThreshold: 40
      localLciHeaderValidity: 10000 #(value in milliseconds)
  
  
 perf info configuration
 
   perfInfoConfig:
      pollingInterval: 5000 #(value in milliseconds)
      serviceName: ""
      host: <release-name>-sepp-perf-info #it should be replaced by correct release name
      port: 5905
      perfInfoRequestMap: "/load"

Note:

When configuring the minor, major, or critical overload ranges, make sure the ranges do not overlap. For example, overlapping ranges like 75–85 and 80–90 can cause incorrect behavior or results in overload detection and response.

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

Observe

Following are the LCI and OCI Headers specific metrics:

• oc_ingressgateway_headers_lci_total
• oc_ingressgateway_headers_oci_total

For more information about metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following steps:

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

3.2.4 SEPP Dashboard Support for Detecting Vulnerable Messages

In earlier releases, SEPP metrics could not be filtered using the originating PLMN ID, making it difficult to segregate and identify the source of messages. This feature enhances the metrics by enabling segregation based on PLMN ID, thereby improving operational efficiency in tracking message origins.

At CSEPP, the existing metric ocsepp_cn32f_requests_total has been enhanced to include source_plmn_id as a new dimension. If the source PLMN ID is not present in the incoming header fields, either 3gpp-sbi-originating-network-id or 3gpp-sbi-asserted-plmn-id, it is recorded with the value 'Unknown'.

At PSEPP, a new metric ocsepp_originating_network_id_validation_success_total has been introduced. This metric is updated only after successful Cat -2 header validation.

Managing SEPP Dashboard Support for Detecting Vulnerable Messages feature.

Prerequisites:

• The 3gpp-Sbi-Originating-Network-Id shall be present in the ingress message, populated either by the VPLMN or by the SEPP.
• The Cat -2 Network ID Validation feature must be enabled.

Enable

This feature is enabled by default.

Observe

Following are the SEPP Dashboard Support for Detecting Vulnerable Messages feature specific metrics:

• ocsepp_cn32f_requests_total (existing metrics updated)
• ocsepp_originating_network_id_validation_success_total (new metrics)

For more information about metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following steps:

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

3.2.5 Security Countermeasure Features

The SEPP security countermeasure features are classified into the following:

• Stateless Countermenasure features
• Stateful Countermeasure features

3.2.5.1 Security Countermeasure Nonverbose Error Responses

Introduction

In earlier releases, SEPP's security countermeasure features (Cat-0, Cat-1, Cat-2, and Cat-3) provided detailed error messages explaining the reason for rejection and other information while rejecting an invalid request. The details in the error messages can weaken the effectiveness of the security countermeasures. Hence, the details should be reduced to prevent attackers from gaining useful information.

With the implementation of this feature, the user can configure whether the details in the error messages can either be detailed (verbose) or simplified (nonverbose). The error responses for the following features are enhanced:

• Cat-0 SBI Message Schema Validation Feature
• Cat-1 Service API Validation Feature
• Cat-2 Network ID Validation Feature
• Cat-3 Previous Location Check Feature

Note: Verbose error responses are disabled by default.

• When verbose error responses are disabled, attributes such as title, detail, and cause in the error response are filled with less detailed, user-configured values. By default, these attributes are set to "Rejected" for title, "Server Error" for detail, and "Unknown" for cause. Http status code remains same as earlier. Additionally, attributes like invalidParams and instances are not included in the generated error responses.
• When verbose error responses are enabled, all security countermeasure features display verbose (detailed) error responses, similar to those in previous SEPP releases.

Note:

Nonverbose error response in error reason header of Egress Gateway:

Earlier, when n32-egress-gateway or plmn-egress-gateway encountered exceptions or errors, it added a custom "error-reason" header to the responses. This header contained verbose (detailed) information about the exceptions and errors.

With this enhancement, SEPP's Ingress Gateway has been configured to remove the "error-reason" header at the route level, which was generated by Egress Gateway.

Cat-0 SBI Message Schema Validation Feature

The following are the verbose and nonverbose error response examples:

Table 3-6 SCM Error Responses

Cat 0 Error Responses Attributes	Attribute Value with Verbose (Detailed) Error Responses Enabled	Attribute Default Value with Verbose Error Responses Disabled (Concise Error Message)
title	"Message validation failed at P-SEPP"	"Rejected"
detail	"Message validation for request /nnrf-disc/v1/nf-instances failed for remote sepp set: SEPP-3"	“Server Error”
cause	"Error in Request Parameter(s)"	“Unknown”
status	406	406
invalid Params	["parameters.requester-plmn-list: Invalid JSON syntax", "parameters.target-plmn-list: Invalid JSON syntax", "service-names[0]: integer found, string expected", "parameters.target-nf-type: is missing but it is required"] ................................. ................................	This attribute is not part of error response.
instance	"/nnrf-disc/v1/nf-instances"	This attribute is not part of error response.

For more information about Cat-0 SBI Message Schema Validation Feature, see Cat-0 SBI Message Schema Validation feature.

Cat-1 Service API Validation Feature

The following are the verbose and nonverbose error response examples:

Error Response Examples:

Table 3-7 SCM Error Responses

Cat 1 Error Responses Attributes	Attribute Value with Verbose (Detailed) Error Responses Enabled	Attribute Default Value with Verbose Error Responses Disabled (Concise Error Message)
title	"Service API not in allowed list"	"Rejected"
detail	“Service API /namf-evts/v1/subscriptions/73ce9152d6bc4033bfc9296190c62--394 from Remote SEPP SEPP-4 is not in allowed list”	“Server Error”
cause	"Service API=/namf-evts/v1/subscriptions/73ce9152d6bc4033bfc9296190c62--394,remoteSepp=SEPP-4"	“Unknown”
status	406	406
instance	“/namf-evts/v1/subscriptions/73ce9152d6bc4033bfc9296190c62--394"	This attribute is not part of error response.

For more information about Cat-1 Service API Validation Feature, see Cat-1 Service API Validation Feature section.

Cat -2 Network ID Validation Feature

The following are the verbose and nonverbose error response examples:

Table 3-8 SCM Error Responses

Cat 2 Error Responses Attributes	Attribute Value with Verbose (Detailed) Error Responses Enabled	Attribute Default Value with Verbose Error Responses Disabled (Concise Error Message)
title	"Network ID Validation Failed"	"Rejected"
detail	"Service API /namf-loc/v1/imsi-987654300000001/provide-loc-info from Network ID Validation List Name \'default\' is not having expected Network ID in header"	“Server Error”
cause	"Service API= /namf-loc/v1/imsi-987654300000001/provide-loc-info , Network ID Validation List Name = default”	“Unknown”
status	406	406
instance	"/namf-loc/v1/imsi-987654300000001/provide-loc-info,POST”	This attribute is not part of error response.

For more information about Cat -2 Network ID Validation Feature, see Cat -2 Network ID Validation Feature section.

Cat-3 Previous Location Check Feature

The following are the verbose and nonverbose error response examples:

Table 3-9 SCM Error Responses

Cat 3 Error Responses Attributes	Attribute Value with Verbose (Detailed) Error Responses Enabled	Attribute Default Value with Verbose Error Responses Disabled (Concise Error Message)
title	"CAT 3 Previous Location check failed due to exception"	"Rejected"
detail	"Service API /nsmf-pdusession/v1/pdu-sessions Allowed List Name \'newcustomlist4\' is not authenticated due to exception :UDR Response Is Not Success"	“Server Error”
cause	"Service API= /nsmf-pdusession/v1/pdu-sessions , Allowed List Name = newcustomlist4”	“Unknown”
status	406	406
instance	"Service API= /nsmf-pdusession/v1/pdu-sessions , Allowed List Name = newcustomlist4”	This attribute is not part of error response.

For more information about Cat-3 Previous Location Check Feature, see Cat-3 Previous Location Check Feature section.

Managing Security Countermeasure Nonverbose Error Responses

Enable

You can enable or disable the feature using the CNC Console or REST API.

Note:

This feature is enabled by default. If the user has to see the verbose error response, the feature must be disabled at global and Remote SEPP Set level.

To enable or disable the feature, perform the following steps:

CNC Console

1. In the CNC Console GUI, from the left navigation menu, navigate to SEPP and click Security Countermeasure.
2. Click Non Verbose Error Measure Configuration under Security Countermeasure, the Option appears.
3. The Security countermeasure Nonverbose Configuration feature details are available on the Option screen.
4. Click Edit icon to modify the Option. The Edit Option page appears.
5. Set Verbose Error Response Enabled to True or False on the right pane.

REST API

Set VerboseScmErrRspConfigEnabled as true or False using the Verbose Error Response Configuration Options REST API.

{
  "VerboseScmErrRspConfig": {
    "enabled": false,
    "title": "Rejected",
    "cause": "Unknown",
    "detail": "Server Error"
  }

Enabling and Configuring Security countermeasure Nonverbose Error Responses in Remote SEPP Set

The user selects the Remote SEPP Set screen on CNC Console and can set the Verbose Error Response Enabled parameter to true or false, and configure Security Counter Measure (SCM) - Non Verbose Error Response Configuration.

Configure

You can configure the feature using REST API and CNC Console.

• Configure using REST API: Perform the feature configurations as described in Verbose Error Response Configuration Options REST APIs in Oracle Communications Cloud Native Core, Security Edge Protection Proxy REST Specification Guide.
• Configure using CNC Console: Perform the feature configurations as described in the Nonverbose Error Response Configuration and Remote SEPP Set sections of Configuring SEPP using CNC Console chapter.

Observe

There are no new metrics and KPIs added or updated for this feature.

For more information about metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following:

1. Collect the logs and Troubleshooting Scenarios: For more information on how to collect logs and troubleshooting information, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

3.2.5.2 Stateless Countermeasure Features

The following are the SEPP stateless countermeasure features:

3.2.5.2.1 Cat-1 NRF Service API Query Parameters Validation

Background

In the existing implementation of the Cat-1 feature, the SEPP cannot filter the traffic based on the NF type in the discovery request. This limitation makes it difficult to manage access to services based on specific NF types. For example, while allowing an AMF from a foreign network to request UDM services may be necessary, it may not be suitable for a Policy to access those services.

Currently, the SEPP enforces Cat-1 rules on an API-wide basis. It can either block the entire API or allow its verification, but it lacks the flexibility to apply filtering using the NF type information included in the query parameters of incoming discovery requests. This results in limited control for network operators, preventing them from applying specific access control rules based on the requesting and target NF types.

Overview

This feature is designed to address the gap in the current implementation by leveraging the NF Type details provided in the discovery request. By integrating the requester-nf-type and target-nf-type information, the feature allows filtering of requests based on the specific NF Type combination configured by the user. This enhancement provides finer control, enabling operators to refine Cat-1 rules based on specific NF Type information.

Key benefits of the feature include:

• Controlled access: Provides NF types specific access to nnrf-disc service, blocking any unauthorized requests.
• Improved security: Blocks unapproved access, it improves security and protects the system from unwanted or harmful interactions.
• Targeted filtering: Operators can set rules based on NF Types, allowing for more specific control over which network functions can access the service.
• Reduced risk: The firewall reduces the chances of untrusted network functions connecting to important APIs, making the system safer.

This feature enhances the security by allowing only trusted network functions to access the nnrf-disc service.

Feature Description

The Cat-1 NRF Service API Query Parameters Validation enhancement in SEPP adds a filtering system for NRF discovery requests. With this feature, SEPP checks the requester-nf-type and target-nf-type parameters in incoming discovery requests to see if they match with a preconfigured list of allowed NF-Type combinations. This helps to ensure that only authorized network functions (NFs) can access the NRF, blocking unauthorized requests and improving network security.

SEPP processes the discovery incoming requests as follows:

• SEPP extracts the requester-nf-type and target-nf-type from the incoming request.
• It compares these extracted values with the list of allowed combinations that the users have configured.
• For example, a valid request could look like this:

  /nnrf-disc/v1/nf-instances/.*target-nf-type=SMF.$ & requester-nf-type=AMF.$

SEPP uses these validation rules to check if the request matches the allowed combinations. If it does, the request is processed; if not, SEPP rejects it and sends an error message. This feature makes firewall rules more specific and effective in managing network traffic.

If the requester-nf-type and target-nf-type are not configured in SEPP, the system will continue with its default behavior and allow the request without additional validation. However, if these parameters are missing from a request and SEPP is set to check for them, SEPP will treat the request as invalid and return an error.

This feature can be controlled by the Enable CAT1-Query Parameter Validation parameter. Operators can choose to enable or disable it as needed. When enabled, SEPP enforces NF-Type validation along with the existing Cat-1 firewall rules. The system checks whether the request is allowed based on the service and roaming partner, and if the additional NF-Type validation is enabled. If everything matches with the request is allowed; otherwise, SEPP responds with an error message or problem details, depending on the verbosity setting.

Managing Cat-1 NRF Service API Query Parameters Validation

This section provides information about the configurations required to enable and configure this feature.

Enable

You can enable the Cat-1 NRF Service API Query Parameters Validation feature using the CNC Console or REST API.

Enable using REST API

Set queryParamValidationEnabled to true in /sepp-configuration/v1/security-counter-measure/feature REST API.

{
     "messageFilteringOnResourceUriAndHttpMethodEnabled": 
     {
     "queryParamValidationEnabled": true,
     "enabled": true
      }
         }

For more information about API path, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy REST Specification Guide.

Enable using CNC Console

1. From the left navigation menu, navigate to SEPP and then click Security Countermeasure.
2. Click Cat 1 -Service API Validation under Security Countermeasure. Option, Service API Allowed List , and Query Parameter Validation List appears.
3. Click Option, the Options page appears on the right pane.
4. Set Enable Cat 1-Query Parameter Validation parameter to True to enable the feature.

Note:

Enable Cat 1-Service API Validation parameter must be set to True to enable this feature.

For more details about CNC Console Configurations, see Configuring SEPP using CNC Console section in Oracle Communications Cloud Native Core, Security Edge Protection Proxy User Guide.

Configure

You can configure the Cat-1 NRF Service API Query Parameters Validation using REST API and CNC Console.

• Configure Cat-1 NRF Service API Query Parameters Validation using REST API: Perform the feature configurations as described Security Counter Measure Service API Validation, Security Countermeasure Service API Allowed List Name, and Supported Service API's sections in Oracle Communications Cloud Native Core, Security Edge Protection Proxy REST Specification Guide.
• Configure Cat-1 NRF Service API Query Parameters Validation using CNC Console: Perform the feature configurations as described in Configuring SEPP using CNC Console.

Observe

For more information about metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following:

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

3.2.5.2.2 Cat-0 SBI Message Schema Validation Feature

Overview

The Cat-0 SBI Message Schema Validation feature intends to support stateless security counter measures, which enhance the security measures of roaming partners by allowing only valid requests to be processed at SEPP. Cat-0 SBI Message Schema Validation feature supports the checks that are carried out to investigate if a message is valid or not. It also checks for the correctness of the message format.

This feature is designed to support the following:

• Validating the headers present in the SBI Message. Example, it checks whether the header name spelling is correct.
• Verifying the combination of request body and query parameters and compare it with the respective schema.
• Routing of only valid SBI messages to egress or ingress the network.

Feature Description

The Cat-0 SBI Message Schema Validation feature intends to support stateless security counter measures, which enhance roaming partners to handle security (Example: only valid requests are allowed to be processed at SEPP).

This feature is to support request validation at N32F.

As many requests traverse the SEPP, there is a security concern that a spoofing NF or an NF, which may cause not forming the messages as per specification. In such a scenario, the SEPP, which is at the boundary of the network could do a first pass for malformed or incorrect messages.

Malformed messages can be of following types:

• The JSON message may contain data that is malformed. A formatted JSON could still contain malformed data that can cause errors in the server code.
• The JSON message may contain repeated IEs or missing IEs that make the message noncompliant with its schema.

This feature intends to support message validation in the following two ways.

• Request's body value is validated against the corresponding schema as provided in 3GPP OpenAPI specifications or configured by user.
• Request's query parameters values are validated against their corresponding schema(s) as provided in 3GPP OpenAPI specifications or configured by user.

Traffic needs to be rejected or forwarded from C-SEPP or P-SEPP based on the validation results as configured by the user.

As part of the message validation feature, the following major scenarios are getting validated:

• If any SBI request JSON schema's mandatory parameter is missing, it is validated.
• If any SBI request JSON schema's mandatory parameter under an optional parameter is missing, it is validated.
• In SBI request, the regex of both the mandatory and optional parameters are validated against the regex defined in the given schema configurations.
• The data types of the IEs in SBI request are validated against the given schema configurations.
• SBI request's additional attribute is allowed or disallowed as provided in the given schema configurations.
• Any invalid JSON structure (syntax) either present in SBI request body or in request query parameters value is validated.
• Repeated IEs, either present in SBI request body or in request query parameters value, are validated.

Design and Architecture

This feature can be enabled on C-SEPP and P-SEPP. For all the supported default resource URI and HTTP methods, SEPP provides the corresponding default schema(s) (JSON format) as per 3GPP OpenAPI specifications, which is used to validate the request at run time. The user is also allowed to add or update the default schema. As per the error configurations done by the user, traffic is rejected or forwarded from SEPP based on the validation results.

Note:

In SEPP Mode, the Egress and Ingress requests (as per configured egress/ingress rules) are validated against the configured schema at C-SEPP and P-SEPP. In roaming hub mode, only the Ingress requests (as per configured Ingress rules) are validated.

Figure 3-9 Cat-0 Functionality

Feature Configurations

The following diagram specifies the CNC Console options available for Cat-0 SBI Message Schema Validation feature.

Figure 3-10 CNC Console options available for Cat-0 SBI Message Schema Validation feature in SEPP Mode

Figure 3-11 CNC Console options available for Cat - 0 SBI Message Schema Validation feature in Roaming Hub Mode

The following section explains the configurations in detail:

Options

• Message Validation on Body Enabled enables or disables the feature on request body.
• Message Validation on Query Parameters Enabled enables or disables the feature on request query parameters.
• Maximum Request Size(kb) provides the maximum allowed request body size (Default is 40 KB)
• Maximum Number Of Query Parameters provides the maximum number of allowed query parameters (Default is 100).

Message Validation List

• As part of this feature configuration, multiple Message Validation Lists can be configured.
• Default Message Validation List with the name Default is configured during SEPP installation which can used as a sample to visualize the rules.
• Default list uses exhaustive number of rules, and its usage impacts the performance.
• Ingress and Egress Rules define the SBI requests to be validated.
• SEPP in Roaming Hub mode supports Ingress Rules only.
• Ingress and Egress Action defines the Action (Forward or Reject), Status Code, and Title to be used in case message validation gets failed for C-SEPP or P-SEPP.
• Any one of the existing Message Validation Lists can be configured for a Remote SEPP Set. By default, the default Message Validation List is configured and the feature is disabled.

Message Validation Configuration in Remote SEPP Set

The user needs to associate the required message validation list to the Remote SEPP Set for which the feature has to be applied.

Note:

To enable the feature, the user needs to enable the Message Validation on Body Enabled and Message Validation on Query Parameters Enabled options available at Option screen and Remote SEPP Set CNC Console screens or REST APIs.

Message Schema Configurations

For the supported resource URI and HTTP methods, SEPP provides the default JSON schemas (application or json) that are used to do the message schema validation. The user can do any changes in the default schema or delete it using CNC Console or REST APIs. Before overwriting the default schema, creating a backup of existing schema is advisable, as once overwritten, SEPP will not provide the default schema. User provided custom schema should be fully resolved, that is, it should not have any internal references to other schemas.

To add a new resource URI, HTTP method and corresponding schema, resource URI, and HTTP method need to be present in SEPP's default service APIs.

Sample Request Body Schema

Request body schema must be provided in the valid JSON format.

Example:

{
  "required" : [ "amfStatusUri" ],
  "type" : "object",
  "properties" : {
    "amfStatusUri" : {
      "type" : "string"
    },
    "guamiList" : {
      "minItems" : 1,
      "type" : "array",
      "items" : {
        "required" : [ "amfId", "plmnId" ],
        "type" : "object",
        "properties" : {
          "plmnId" : {
            "required" : [ "mcc", "mnc" ],
            "type" : "object",
            "properties" : {
              "mcc" : {
                "pattern" : "^\\d{3}$",
                "type" : "string"
              },
              "mnc" : {
                "pattern" : "^\\d{2,3}$",
                "type" : "string"
              },
              "nid" : {
                "pattern" : "^[A-Fa-f0-9]{11}$",
                "type" : "string"
              }
            }
          },
          "amfId" : {
            "pattern" : "^[A-Fa-f0-9]{6}$",
            "type" : "string"
          }
        }
      }
    }
  }
}

Sample Query Parameters Schema

Query parameter and corresponding schema should be provided in the form of JSON array where each array element will provide information for one query parameter. This information must have the following mandatory attributes:

name: name of the query parameter as used in the request URI.

in: type of parameter, it should be 'query' to indicate that its is a query parameter, any other type will not be supported.

required: true/false, provides mandatory or optional parameter information.

content or schema:

• JSON objects and arrays of JSON objects: They shall be formatted using the JSON syntax, by including a "content:" block, and specifying the "application/json" media type, followed by the json schema of the object.
• Arrays of simple types: They shall be formatted using the OpenAPI "style" set as "form" and the "explode" set as "false", and specifying the schema of the object.

The following example shows content and schema of two query parameters, that is, 'supported-features' and 'plmn-id':

[ {
  "name" : "supported-features",
  "in" : "query",
  "required" : false,
  "schema" : {
    "pattern" : "^[A-Fa-f0-9]*$",
    "type" : "string"
  }
}, {
  "name" : "plmn-id",
  "in" : "query",
  "required" : false,
  "content" : {
    "application/json" : {
      "schema" : {
        "required" : [ "mcc", "mnc" ],
        "type" : "object",
        "properties" : {
          "mcc" : {
            "pattern" : "^\\d{3}$",
            "type" : "string"
          },
          "mnc" : {
            "pattern" : "^\\d{2,3}$",
            "type" : "string"
          }
        }
      }
    }
  }
} ]

Managing Cat-0 SBI Message Schema Validation Feature

Enable

You can enable the Cat-0 SBI Message Schema Validation feature using the CNC Console or REST API.

Enable using REST API

Set MessageValidationOnBodyEnabled and MessageValidationOnQueryParametersEnabled to true in Message Validation REST API.

curl -X 'PUT' \
  'http://<SEPP- Configuration IP>:<PORT>/sepp-configuration/v1/security-counter-measure/message-validation/options' \
  -H 'accept: */*' \
  -H 'Content-Type: application/json' \
  -d '{
  "messageValidationOption": {
    "messageValidationOnBodyEnabled": true,
    "messageValidationOnQueryParametersEnabled": true,
    "maxRequestSize": 0,
    "maxNumberOfQueryParams": 0
  }
}'

For more information about API path, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy REST Specification Guide.

Enable using CNC Console

1. From the left navigation menu, navigate to SEPP and then click Security Countermeasure.
2. Click Cat 0 - SBI Message Validation under Security Countermeasure. The Option appears underneath.
3. Click Option, the option screen appears at the right pane. The Cat 0 - SBI Message Validation feature details are available in the screen.
4. Click Edit icon to modify the Option. The Edit Option page appears.
5. Set the Message Validation on Body Enabled and Message Validation on Query Parameters Enabled to True.

For more details about CNC Console configurations, see Configuring SEPP using CNC Console section in the Oracle Communications Cloud Native Core, Security Edge Protection Proxy User Guide.

Note:

To enable the feature, the user also needs to enable the Message Validation on Body Enabled and Message Validation on Query Parameters Enabled options available at Remote SEPP Set, using CNC Console screen or REST APIs.

Observe

The following are the Cat-0 SBI Message Schema Validation feature specific metrics:

• ocsepp_message_validation_applied_total
• ocsepp_message_validation_on_body_failure_total
• ocsepp_message_validation_on_header_failure_total

The following are the Cat-0 SBI Message Schema Validation feature specific KPIs:

• Message validation applied requests on cn32f
• Cn32f message validation failure on request body
• Cn32f message validation failures on request query parameter(s)
• Message validation applied requests on pn32f
• Pn32f message validation failure on request body
• Pn32f message validation failures on request query parameter(s)

For more information on Cat-0 SBI Message Schema Validation feature related SEPP Metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following:

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

3.2.5.2.3 Cat-1 Service API Validation Feature

Overview

Interface blocking refers to checks for a type of a message to investigate whether it is allowed on a specific reference point. Typically based on the combination of path and operation type and sometimes operation Id for 5GC messages.

In 5G interconnect scenarios, the operator may prohibit certain interfaces from traversing the networks. In 5G interconnect, the recommended practice for Category 1 filtering is to block all 5G interconnect messages except those explicitly required for a given interface, and to allow/activate on the SEPP only the required interface(s) needed for roaming scenarios. This avoids the risk of roaming partners extending the roaming services or features unilaterally by using interfaces and sending messages that are not covered by an existing roaming agreement. In general, the SEPP needs to be able to differentiate between the different interfaces and methods encapsulated in the N32f packets and treat them separately. This is achieved by using a combination of “Method Types” and URIs in Cat -1 feature.

The Cat-1 Service API Validation feature allows the operator to configure the stateless security measures at the SEPP. This feature intends to support this in two ways:

• Check of combination of HTTP Method and Service requested (Example: POST cannot be used in combination with a particular service).
• Allows only certain SBI messages to either egress or ingress the network (Example: AMF to UDM messages)

Design and Architecture

SEPP allows a list of allowed Resource URIs and HTTP Method to be configured. Every Ingress and egress messages is validated against the configured allowed list on P-SEPP and C-SEPP.

The configuration is available at both C-SEPP and P-SEPP. If the Resource URI and HTTP Method matches with the configured one, that Service API is allowed to pass through the SEPP and if the Resource URI and Method in the ingress and egress messages does not matches, then as per the configured action in the error configuration by the user, the Service API is rejected.

Figure 3-12 Security Counter Measure Service

To add a new Resource URI along with HTTP Method which is not present in the Allowed List, add the new Resource URI first in Service API section (on the Main Menu of SEPP in CNC Console GUI) and add it in the Allowed List. The newly added Resource URI and Method automatically be updated in the drop down of Ingress Rule and Egress Rule.

By default the Resource URI list in CNC Console Screen will be populated with some default Resource URIs and HTTP Methods which is user configurable and can be added or deleted as required.

User can consider the following points while configuring the Cat-1 Service API Validationfeature:

• Multiple Allowed List can be configured by the user.
• Default Allowed List with name Default is configured during SEPP installation.
• An allowed list needs to be configured for a Remote SEPP Set mandatorily.
• Ingress and Egress Rules define the combination of allowed Resource URIs and HTTP Methods.
• Ingress and Egress Action defines the Action, Status Code, and Title to be used in case the Service API is not allowed.

Managing Cat-1 Service API Validation Feature

Enable

You can enable Cat-1 Service API Validation feature using the REST API or CNC Console.

• Enable using REST API: Set Enable Security Counter Measure to True in Security Counter measure Service API Validation Feature State API. For more information about API path, see Oracle Communications Cloud Native Core Security Edge Protection Proxy REST Specification Guide.
• Enable using CNC Console: Set Enable Service API Validation to True on the Security Counter Measure page. For more information about enabling the feature using CNC Console, see Security Counter Measure Options.

Configure

You can configure the Cat-1 Service API Validation using REST API and CNC Console.

• Configure Cat-1 Service API Validation using REST API: Perform the feature configurations as described Security Counter Measure Service API Validation, Security Countermeasure Service API Allowed List Name, and Supported Service API's sections in Oracle Communications Security Edge Protection Proxy Rest API Guide.
• Configure Cat-1 Service API Validation using CNC Console: Perform the feature configurations as described in Configuring SEPP using CNC Console.

Observe

For more information about metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following:

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

3.2.5.2.4 Cat -2 Network ID Validation Feature

Overview

Cat -2 Network ID Validation feature refers to the checks carried out to investigate if a message is sent from home or the allocated network (for example, in case of a shared infrastructure). This feature also determines if there are any inconsistencies between the information in the lower level and in the embedded packets and IEs.

An example of this is the MCC/MNC combination in the incoming SUPI/SUCI that could be validated against Home PLMN IDs that are supported by the P-SEPP. Also, any message configured to validate CSEPP PLMN ID, that contains the servingNetworkName Body IE parameter could be validated against Visited network PLMN ID supported by C-SEPP.

Cat- 2 Network ID Validation feature allows the user to validate the PLMN ID of Producer SEPP and Consumer SEPP in the SBI Request Messages over N32 Interface in SEPP Mode as well as in Roaming Hub Mode.

This feature is not applicable to SBI responses that is, only SBI requests are validated.

This feature can be used for:

• The validation of subscribers that are allowed into the home network.
• Validation of PLMN ID of Ingress messages.

Design and Architecture

The following diagram represents the Cat-2 Network ID validation feature in SEPP mode.

SEPP Mode

Figure 3-13 SEPP Mode

In SEPP Mode, this feature can be applied on Producer SEPP (P-SEPP) as well as on Consumer SEPP (C-SEPP). At Producer SEPP, this feature validates the P-SEPP PLMN ID against the configured Local SEPP PLMN IDs in the N32 Ingress SBI requests (header and JSON IE) and C-SEPP PLMN ID against the configured Remote SEPP PLMN IDs.

Where as, at Consumer SEPP, this feature validates the P-SEPP PLMN ID against the configured Producer Remote SEPP PLMN IDs in the N32 Egress SBI requests (header and JSON IE) and C-SEPP PLMN ID against Local SEPP PLMN IDs configured at C-SEPP.

When the feature is enabled at C-SEPP:

• If the user wants to validate the PLMN ID in 3gpp-sbi-target-apiroot header, then user can add a configuration for this header in Header Configuration for ALL Service APIs or for a particular Service API. Once the configuration is done, and if it is configured for ALL Service APIs, then for every SBI request message containing 3gpp-sbi-target-apiroot header, PLMN ID is extracted from MCC and MNC part of this header and is compared with the Remote SEPP PLMN IDs. If a match is found, then that request is allowed and if a match is not found, then that request is rejected or forwarded as per user configured Error Configuration.
• If the user wants to validate the PLMN ID in 3gpp-Sbi-Originating-Network-Id or 3gpp-Sbi-Asserted-Plmn-Id headers, then user can add a configuration for this header in header configuration for all Service APIs or for a particular Service API. Once the configuration is done, and if it is configured for all Service APIs, then for every SBI request message containing 3gpp-Sbi-Originating-Network-Id or 3gpp-Sbi-Asserted-Plmn-Id header, PLMN is extracted from this header value and is compared with the local SEPP PLMN IDs. If a match is found, then that request is allowed and if a match is not found, then that request is rejected or forwarded as per user configured error configuration.

  Note:

  It is recommended to use the Regex (\d{3})-(\d{2,3}) for configuring 3gpp-Sbi-Originating-Network-Id and 3gpp-Sbi-Asserted-Plmn-Id headers.
• If user wants to validate supiOrSuci value in UE Authentication SBI request message, then user can add a configuration for this JSON IE in Body Configuration for UE Authentication SBI request API. Once the configuration is done, then for every UE Authentication SBI request message, PLMN ID is extracted from supiOrSuci IE and is compared with the Remote SEPP PLMN IDs. If a match is found, then that request is allowed and if a match is not found then that request is rejected or forwarded as per user configured Error Configuration.
• If user wants to validate servingNetworkName value in UE Authentication SBI request message, then user can add a configuration for this JSON IE in Body Configuration for UE Authentication SBI request API. Once the configuration is done, then for every UE Authentication SBI request message, PLMN ID is extracted from servingNetworkName IE and is compared with the Local SEPP PLMN IDs. If a match is found, then that request is allowed and if a match is not found, then that request is rejected or forwarded as per user configured Error Configuration.

When the feature is enabled at P-SEPP:

• If the user wants to validate the PLMN ID in 3gpp-sbi-target-apiroot header, then user can add a configuration for this header in Header Configuration for all Service APIs or for a particular Service API. Once the configuration is done, and if it is configured for all Service APIs, then for every SBI request Message containing 3gpp-sbi-target-apiroot header, PLMN ID is extracted from MCC and MNC part of this header and is compared with the Local SEPP PLMN IDs. If a match is found, then that request is allowed and if a match is not found, then that request is rejected or forwarded as per user configured Error Configuration.
• If the user wants to validate the PLMN ID in 3gpp-Sbi-Originating-Network-Id or 3gpp-Sbi-Asserted-Plmn-Id headers, then the user can add a configuration for this header in Header Configuration for all Service APIs or for a particular Service API. Once the configuration is done, and if it is configured for all Service APIs, then for every SBI request Message containing 3gpp-Sbi-Originating-Network-Id or 3gpp-Sbi-Asserted-Plmn-Id header, PLMN is extracted from this header value and is compared with the remote SEPP PLMN IDs. If a match is found, then that request is allowed and if a match is not found, then that request is rejected or forwarded as per user configured error configuration.

  Note:

  It is recommended to use the Regex (\d{3})-(\d{2,3}) for configuring 3gpp-Sbi-Originating-Network-Id and 3gpp-Sbi-Asserted-Plmn-Id headers.
• If the user wants to validate supiOrSuci value in UE Authentication SBI request message, then the user can add a configuration for this JSON IE in Body Configuration for UE Authentication SBI request API. Once the configuration is done, then for every UE Authentication SBI request message, PLMN ID is extracted from supiOrSuci IE and is compared with the Local SEPP PLMN IDs. If a match is found, then that request is allowed and if a match is not found, then that request is rejected or forwarded as per user configured Error Configuration.
• If the user wants to validate servingNetworkName value in UE Authentication SBI request message, then user can add a configuration for this JSON IE in Body Configuration for UE Authentication SBI request API. Once the configuration is done, then for every UE Authentication SBI request message, PLMN ID is extracted fromservingNetworkName IE and is compared with the Remote SEPP PLMN IDs. If a match is found, then that request is allowed and if a match is not found then that request is rejected or forwarded as per user configured Error configuration.

In Roaming Hub mode

The following diagram represents the Cat 2 – Network ID validation feature in Roaming Hub mode.

Figure 3-14 Roaming Hub mode

In Roaming Hub mode, this feature validates the P-SEPP PLMN ID (received in the incoming message in 3gpp-sbi-target-apiroot and supiOrSuci) against the configured Producer Remote SEPP PLMN IDs in the N32 Egress SBI requests (header and JSON IE) and C-SEPP PLMN ID against the Consumer Remote SEPP PLMN IDs. In this mode, only Egress SBI requests are validated. Ingress SBI requests are not validated. So, user is not allowed to add Ingress Rules in Network ID Validation List of the feature.

When the feature is enabled at Roaming Hub:

• If the user wants to validate the PLMN ID in 3gpp-sbi-target-apiroot header, then user can add a configuration for this header in Header Configuration for all Service APIs or for a particular Service API. Once the configuration is done, and if it is configured for all Service APIs then for every SBI request Message containing 3gpp-sbi-target-apiroot header, PLMN ID is extracted from MCC and MNC part of this header and is compared with the Producer SEPP PLMN IDs. If a match is found, then that request is allowed and if a match is not found then that request is rejected or forwarded as per user configured Error Configuration.
• If the user wants to validate the PLMN ID in 3gpp-Sbi-Originating-Network-Id or 3gpp-Sbi-Asserted-Plmn-Id headers, then user can add a configuration for this header in Header Configuration for all Service APIs or for a particular Service API. Once the configuration is done, and if it is configured for all Service APIs then for every SBI request Message containing 3gpp-Sbi-Originating-Network-Id or 3gpp-Sbi-Asserted-Plmn-Id header, PLMN ID is extracted from the header and is compared with the consumer SEPP PLMN IDs. If a match is found, then that request is allowed and if a match is not found then that request is rejected or forwarded as per user configured error configuration.

  Note:

  It is recommended to use the Regex (\d{3})-(\d{2,3}) for configuring 3gpp-Sbi-Originating-Network-Id and 3gpp-Sbi-Asserted-Plmn-Id headers.
• If the user wants to validate supiOrSuci value in UE Authentication SBI request message, then user can add a configuration for this JSON IE in Body Configuration for UE Authentication SBI request API. Once the configuration is done, then for every UE Authentication SBI request message, PLMN ID is extracted from supiOrSuci IE and is compared with the Producer SEPP PLMN IDs. If a match is found, then that request is allowed and if a match is not found then that request is rejected or forwarded as per user configured Error Configuration.
• If user wants to validate servingNetworkName value in UE Authentication SBI request message, then user can add a configuration for this JSON IE in Body Configuration for UE Authentication SBI request API. Once the configuration is done, then for every UE Authentication SBI request message, PLMN ID is extracted fromservingNetworkName IE and is compared with the Consumer SEPP PLMN IDs. If a match is found, then that request is allowed and if a match is not found then that request is rejected or forwarded as per user configured Error Configuration.

Configurations

The following diagram specifies the CNC Console options available for Cat 2 – Network ID Validation.

Figure 3-15 CNC Console options available for Cat 2 – Network ID Validation

The list of options available in CNC Console is as follows:

• Options
• JSON IEs
• Headers
• Network ID Validation List
• Remote SEPP Set

Feature Configuration –Network ID Validation List

Figure 3-16 Feature Configuration – Network ID Validation List

• As part of this feature configuration, multiple Network ID Validation Lists can be configured for a Remote SEPP Set.
• Default Network ID Validation List with the name Default is configured during SEPP installation which can used as a sample to visualize the rules.
• Default list uses exhaustive number of rules, and it is usage impacts the performance.
• A Network ID Validation List is configured for a Remote SEPP Set if the feature is enabled.
• By default, the feature is disabled and the default Network ID Validation List is configured.
• Ingress and Egress Rules define the SBI requests to be validated.
• SEPP in Roaming Hub mode supports Egress Rules only.
• Ingress and Egress Action defines the Action (Forward/Reject), Status Code, and Title to be used in case SEPP fails to validate the SBI request for the C-SEPP or P-SEPP PLMN ID.

Feature Configuration –Options,Headers, JSON IEs

• Options Configuration
  • Allows feature to be enabled for validating Network ID in Header or Body.
• Headers Configuration
  • SBI request is identified by Resource URI and HTTP Method.
  • Header is identified by name.
  • Regular Expression extracts the PLMN from the header value.
• JSON IEs Configuration
  • SBI request is identified by Resource URI and HTTP Method.
  • JSON Body IE key is identified by name.
  • Regular Expression extracts the PLMN from the IE value.

Note:

If JSON IE name is present in the root path of the JSON as well as present in the nested object, then it is recommended to keep the JSON IE which is present in the root if we want to validate it. If the child JSON IE has to be validating, it is recommended to configure it is own parent JSON IE.

Example:

{"plmnId": {
          "mcc": "111",
          "mnc": "111"
        }
"ueLocation": {
    "eutraLocation": {
      "tai": {
        "plmnId": {
          "mcc": "111",
          "mnc": "111"
        },
        "tac": "string",
        "nid": "string"
      }}}}

In the above example, if a user wants to validate plmnId which is present inside taiobject, then the user has to give identifier name as tai in Body IE Configuration. If the user has configured plmnId in Body IE Configuration, then as per this example, the toplevel plmnId gets validated.

Note:

• From 25.1.200 onwards, in CSEPP and PSEPP, the length of mnc will be used from PLMN table where mnc length is configured according to the PLMNs given in Remote SEPP.
• The configured regex uses the length of the mnc configured in the PLMN table for forwarding or rejecting the traffic.
• From 25.1.200 release onwards, for the list of given headerNames ( supi, suci, supiOrSuci, ueId, ueContextId, and 3gpp-Sbi-Correlation-Info), the user can configure two rows, given that associated SEPP type (PSEPP or CSEPP) remains same and the regex is different for the combination of resourceURI, headerName, and httpMethod.
• From 25.1.200 release onwards, for the list of given identifiers ( supi, suci, supiOrSuci, ueId, and ueContextId), the user can configure two rows, given that associated SEPP type (PSEPP or CSEPP) remains same and the regex is different for the combination of resourceURI, identifier, and httpMethod.

Managing Cat -2 Network ID Validation Feature

Enable

You can enable the Cat -2 Network ID Validation feature using the CNC Console or REST API.

• Enable using REST API: Set messageFilteringOnPlmnHeaderValidation and messageFilteringOnPlmnBodyValidation to true in Security Counter Measure REST API.

  curl -X 'PUT' \
    'http://<SEPP- Configuration IP>:<PORT>/sepp-configuration/v1/security-counter-measure/network-id-validation/options' \
    -H 'accept: */*' \
    -H 'Content-Type: application/json' \
    -d  '{
    "networkIdValidationEnabled": {
      "messageFilteringOnNetworkIdHeaderValidation": true,
      "messageFilteringOnNetworkIdBodyValidation": true
    }
  }'

  For more information about API path, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy REST Specification Guide.
• Enable using CNC Console:
  1. In the CNC Console GUI, from the left navigation menu, navigate to SEPP and then click Security Countermeasure.
  2. Select Cat 2 – Network ID Validation.
  3. The Option appears underneath.
  4. Click Option, the option screen appears at the right pane. The Cat 2 – Network ID Validation Feature details are available in the screen.
  5. Click Edit icon to modify the Option. The Edit Option page appears.
  6. Set Network ID in Header Validation Enabled and Network ID in Body Validation Enabled to True or False on the right pane.

Configure

You can configure the feature using REST API and CNC Console:

• Configure using REST API: Perform the feature configurations as described in Cat 2–Network ID Validation System Option section in Oracle Communications Cloud Native Core, Security Edge Protection Proxy REST Specification Guide.
• Configure using CNC Console: Perform the feature configurations as described in Configuring SEPP using CNC Console.

Observe

Following are the CAT 2- Network ID Validation feature specific metrics:

• ocsepp_network_id_validation_header_failure_total
• ocsepp_network_id_validation_body_failure_total

For more information on CAT 2- Network ID Validation feature related SEPP Metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following steps:

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

3.2.5.3 Stateful Countermeasure Features

The following are the SEPP stateful countermeasure features:

3.2.5.3.1 Cat-3 Previous Location Check Feature

Cat-3 Previous Location Check feature is a part of stateful security countermeasures. This feature verifies that only messages from an authenticated user equipment (UE) and originating from the same location where the UE was previously authenticated are permitted to traverse the network.

The authentication status is retrieved from the UDR in the home network for a particular User Equipment (UE) and the same is verified for every incoming message reaching the Producer SEPP (P-SEPP). When the UE is verified from the UDR response, that message is allowed to pass through P-SEPP. If the UE is not authenticated or the location of the incoming message do not match with the location registered in UDR at the time of UE authentication process, the message is rejected and displays the user configurable error response.

Note:

This feature is available only on P-SEPP.

Design and Architecture

Figure 3-17 Design and Architecture

The diagram shows the functionality of Cat-3 Previous Location Check feature.

At the INIT time of SEPP, or when the SEPP is up and running, PN32F microservice sends a trigger to nrf-client microservice to discover the UDR profile registered with the NRF of home network (P-SEPP) through the PLMN Egress Gateway. The UDR registers its profile with NRF where SEPP is in the allowedNFtype list. Once the UDR profile is received by nrf-client, PN32F microservice stores the details (UDR profile details like FQDN, SUPI range, Port Number, Scheme (HTTP or HTTPS) so on) in coherence cache.

Whenever an incoming Ingress request message reaches P-SEPP, the PN32F microservice fetches the UE ID and the serving network ID from the Ingress request (from the Header or Body JSON) and searches for the UDR FQDN in UDR profile received in the UDR Discovery response. Once UDR FQDN is found in coherence cache map, PN32F microservice sends a request to UDR through PLMN Egress Gateway for finding the authentication status of the UE ID received in the ingress request message. UDR responds with the authentication status of the UE along with the previously authenticated location. PN32F now checks for the authentication status received from UDR. If the UE is authenticated, it then matches the serving network PLMN received in the Ingress request message along with the PLMN in Serving Network Name received in UE authentication message response. If both match, then the request is forwarded to the target NF. SEPP also subscribes for UDR profile change in NRF.

Note:

After the upgrade, the Cat-3 Previous Location Check feature must be restored to its previous state, if the feature was enabled previously.

Managing Cat-3 Previous Location Check Feature

You can enable the Cat-3 Previous Location Check feature using the Helm parameters, CNC Console, or REST API.

Enable using Helm Parameter

Set the seppCoherenceServiceEnabled parameter to true in the N32 Ingress Gateway section of ocsepp_custom_values_<version>.yaml file.

seppCoherenceServiceEnabled: true

For more information about the Helm parameters, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy Installation, Upgrade, and Fault Recovery Guide.

Enable using REST API

Set messageFilteringOnPreviousLocationCheckValidation to true in Previous Location Check REST API.

curl -X 'PUT' \
  'http://<SEPP- Configuration IP>:<PORT>/sepp-configuration/v1/security-counter-measure/previous-location-validation/options' \
  -H 'accept: */*' \
  -H 'Content-Type: application/json' \
  -d '{
  "previousLocationCheckValidationEnabled": {
    "cacheRefreshTimer": 120000,
    "messageFilteringOnPreviousLocationCheckValidation": false
  }
}'

For more information about API path, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy REST Specification Guide.

Enable using CNC Console

1. From the left navigation menu, navigate to SEPP and then click Security Countermeasure.
2. Click Cat 3 - Previous Location Check under Security Countermeasure. The Option appears underneath.
3. Click Option, the option screen appears at the right pane. The Cat 3 - Previous Location Check feature details are available on the screen.
4. Click Edit icon to modify the Option. The Edit Option page appears.
5. Set the Previous Location Check Enabled to True.

For more details about CNC Console configurations, see Configuring SEPP using CNC Console.

Observe

Following are the Cat-3 Previous Location Check feature specific metrics:

• ocsepp_previous_location_exception_failure_total
• ocsepp_previous_location_validation_success_total
• ocsepp_previous_location_validation_failure_total
• ocsepp_previous_location_validation_requests_total
• ocsepp_pn32f_notification_total

For more information on Cat-3 Previous Location Check feature related SEPP Metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following:

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

3.2.5.3.2 Cat-3 Time Check for Roaming Subscribers

Overview

In roaming scenarios, customers enter different time zones or regions, which must be verified. To ensure the same, SEPP uses PLMN-IDs (Public Land Mobile Network identifiers) to check if the subscriber has entered a new time zone.

The SEPP compares the last recorded PLMN-ID from the subscriber's previous registration with the new PLMN-ID. By doing this, the SEPP can confirm if the subscriber has moved to a new time zone or area. This process ensures accurate monitoring and verification of subscriber movements while roaming. The process starts with the P-SEPP checking if the feature is enabled for the specified consumer Remote SEPP Set. This feature is specifically for AUSF UE Authentication messages and only works when the Subscription Permanent Identifier/Subscription Concealed Identifier (SUPI/SUCI) is included in the incoming message. When the SEPP receives the SBI request, it extracts key information, such as the SUPI/SUCI (UE ID), the Serving PLMN, and the Sender Timestamp.

The Sender Timestamp is taken from the 3gpp-Sbi-Sender-Timestamp value in the header, if available. If unavailable, the timestamp is set to the exact time when the message reaches the SEPP.

First, the SUPI and SUCI are extracted from the incoming message. If the SUCI is present, the SEPP queries the UDM to get the corresponding SUPI. Once the SUPI is retrieved, the SEPP queries the UDR to check the subscriber’s authentication status. If the SUPI is already in the incoming message, the SEPP directly queries the UDM for the authentication status.

For better performance, the SEPP caches results from the UDR and UDM in the Coherence Cache. A configurable timeout ensures that frequently requested data is quickly available. If the extracted Serving PLMN is different from the previously authenticated PLMN, an extra check is made: the Sender Timestamp is compared with the Authentication Timestamp.

The minimum transition time is the shortest time it takes for a UE device to travel from one location to another. This estimate considers configurable factors like distance and average flight velocity, providing a baseline for the minimum time the device would need to make a legitimate move.

This comparison ensures that the time difference between the Sender Timestamp and the Authentication Timestamp is equal to or greater than the minimum transition time, thereby confirming a legitimate transition. The minimum transition time is calculated using the Haversine formula, which calculates the distance between two geographical points based on their latitude and longitude. The result is combined with the average flight velocity (configured by the user) to estimate the time needed for the transition. If this check passes, the request proceeds; if it fails, the request is rejected.

Assumptions

The following are the assumptions for the feature:

• The subscriber has already authenticated in the home network before entering the foreign network.

• UDM and UDR must be accessible.
• The Cat-3 time check for roaming subscribers will only apply to the /nausf-auth/v1/ue-authentications API.
• The UDM and UDR must register their profiles with NRF, and SEPP must be added to the allowed NF type list.

Architecture

The following diagram represents the detailed architecture of this feature.

Figure 3-18 Cat-3 Time Check for Roaming Subscribers Feature

Note:

This feature is available only on P-SEPP.

The diagram shows the functionality of Cat-3 Time check for Roaming Subscribers.

Initial Setup and UDR/UDM Discovery

1. Initialization: When the system starts up, the PN32F microservice triggers the nrf-client to discover the UDR and UDM profiles registered with the home network's NRF via the PLMN Egress Gateway.
2. Profile Registration: The UDR and UDM register their profiles with the NRF, ensuring that the SEPP is included in the allowed NF types list.
3. Profile Reception: The nrf-client receives the UDR and UDM profiles from the NRF.
4. Storing Profile Details: The nrf-client stores the following details in the coherence cache:
   • UDR Profile: FQDN, SUPI range, port number, scheme (HTTP/HTTPS), etc.
   • UDM Profile: SUPI-SUCI mapping, routing indicators, UDM FQDN, etc.

The coherence cache ensures that these critical details are readily available for quick lookup and further processing as the system handles incoming requests.

Incoming Ingress Request Processing

1. Extracting UE ID and Serving Network ID:

• The PN32F microservice extracts the UE ID (SUPI) and the serving network ID from the incoming UE Authentication request.

2. Handling SUCI (if present):

• If a SUCI is present in the request:
  • The PN32F retrieves the SUCI and its associated routing indicator from the coherence cache.
  • The UDM FQDN is fetched based on the routing indicator from the UDM profile in the cache.
  • The PN32F then queries the UDM using the /nudm-ueau/v1/{supiOrSuci}/security-information-rg API to retrieve the corresponding SUPI.

3. Retrieving Authentication Status:

• Once the SUPI is obtained, the UDR FQDN is fetched from the UDR profile in the coherence cache.
• The PN32F then queries the UDR using the /nudr-dr/v2/subscription-data/{ueId}/authentication-data/authentication-status API to retrieve the authentication status and the previously authenticated location for the UE.

4. Authentication Status Check:

• The PN32F verifies the UE's authentication status.
  • If the UE is authenticated, the microservice compares the serving network PLMN from the ingress request with the PLMN in the UE authentication response.
    • If the PLMNs match, the Cat-3 Time Check is not applied, and the request is forwarded to the target NF.
    • If the PLMNs do not match, the Cat-3 Time Check is applied.

5. Cat- 3 Time Check:

• The Sender Timestamp is extracted from the 3gpp-Sbi-Sender-Timestamp header, or it is set to the current time if the header is missing.
• The Minimum Transition Time is calculated using the Haversine formula, which computes the distance between two geographical points based on their latitude and longitude. This is combined with the average flight velocity, a user-configured parameter, to estimate the time needed for the UE to move from the previous location to the new one.

6. Validating the Transition Time:

• The PN32F compares the calculated time (Authentication Timestamp – Sender Timestamp) with the Minimum Transition Time:
  • If the calculated time exceeds the Minimum Transition Time, the Cat-3 Time Check passes, and the request is forwarded to the target NF.
  • If the calculated time is less than the Minimum Transition Time, the request is either:
    • Rejected, or
    • Forwarded based on the user-configured error action.

This process ensures that only legitimate transitions based on geographical movement are allowed, preventing fraud or invalid requests from being processed.

Detailed Description

At the start (INIT) of the SEPP, or when the SEPP is running, the PN32F microservice sends a trigger to the nrf-client microservice to discover the UDM and UDR profiles registered with the NRF of the home network (P-SEPP) through the PLMN Egress Gateway. The UDM and UDR register their profiles with the NRF, ensuring that SEPP is included in the allowedNFtype list.

Once the nrf-client receives the UDR profile, the PN32F microservice stores the details (such as FQDN, SUPI range, port number, and scheme type—HTTP or HTTPS) in the coherence cache. After the UDM profile is received, the PN32F microservice also stores the UDM profile details (like SUPI/SUCI mapping, routing indicator, and UDM FQDN) in the coherence cache.

When an incoming Ingress request message reaches the P-SEPP, the PN32F microservice retrieves the UE ID (SUPI) and the serving network ID from the UE Authentication request (/nausf-auth/v1/ue-authentications) in the Body JSON. If a SUCI is present in the request, the PN32F microservice extracts the SUCI and looks for the routing indicator associated with the SUCI in the coherence cache for UDM details.

The PN32F microservice then searches for the UDM FQDN in the UDM profile received in the UDM Discovery response. Once it finds the UDM FQDN in the coherence cache, it sends a request to the UDM using the /nudm-ueau/v1/{supiOrSuci}/security-information-rg API through the PLMN Egress Gateway to retrieve the SUPI associated with the SUCI.

The UDM then responds with the SUPI for the SUCI provided in the ingress request.

Once the SUPI is available, the PN32F microservice searches for the UDR FQDN in the UDR profile received from the UDR Discovery response. When the UDR FQDN is found in the coherence cache, the PN32F microservice sends a request to the UDR through the PLMN Egress Gateway to get the authentication status of the UE ID from the incoming request message. This is done using the /nudr-dr/v2/subscription-data/{ueId}/authentication-data/authentication-status API.

The UDR responds with the authentication status of the UE, along with the previously authenticated location and timestamp. The PN32F microservice then checks the authentication status received from the UDR.

• If the UE is authenticated, PN32F compares the serving network PLMN from the Ingress request message with the PLMN from the Serving Network Name in the UE authentication response from the UDR.
  • If both PLMNs match, the Cat-3 Time check for the Roaming Subscribers feature is not applied, and the request is forwarded to the target NF.
  • If the PLMNs do not match, the Cat-3 Time check for the Roaming Subscribers feature is applied, and additional checks are performed before proceeding with the request.

To apply the Cat-3 Time check for Roaming Subscribers feature, the PN32F microservice validates whether the calculated timestamp (Authentication Timestamp – Sender Timestamp) is greater than the Minimum Transition Time.

• If the calculated timestamp is greater than the Minimum Transition Time, the Cat-3 Time check passes, and the request is forwarded to the target NF.
• If the calculated timestamp is less than the Minimum Transition Time, the Cat-3 Time check fails. Depending on the user configuration in the Error Action, the request is either rejected or forwarded.

The PN32F microservice extracts the Sender Timestamp from the 3gpp-Sbi-Sender-Timestamp header. If this header is not present, the Sender Timestamp is set to the exact time when the message reaches the SEPP. The Authentication Timestamp is retrieved from the UDR Response.

To calculate the Minimum Transition Time, the MCC (Mobile Country Code) is extracted from both the serving network PLMN in the Ingress request and the PLMN in the Serving Network Name from the UE authentication response. Once both MCCs are available, their location coordinates (latitude and longitude) are retrieved from the configuration.

Using the Haversine formula and the average flight velocity (a user-configured parameter), the Minimum Transition Time is calculated.

Once the Cat-3 Time check for Roaming Subscribers feature fails for a UE, the UE is added to a blocklist for a configured period, during which all subsequent requests for this UE will be rejected. The blocklist check is applied based only on the SUPI/SUCI information found in the path, query parameters, or message headers. If the SUPI/SUCI is found in the message body, given it is not present in path or query, it will not be considered for the blocklist check. Once the blocklist timer expires or the UE passes the Cat-3 Time check, the UE is removed from the blocklist, and future requests will be forwarded as usual.

Additionally, the SEPP subscribes to receive notifications for any changes to the UDR and UDM profiles in the NRF.

Note:

The default value of average flight velocity is set as 12,000 km/hr.

Managing Cat-3 Time Check for Roaming Subscribers Feature

You can enable the Cat-3 Time Check for Roaming Subscribers feature using CNC Console or REST API.

Enable using REST API

Set messageFilteringOnUnAuthLocationEnabled to true in /sepp-configuration/v1/security-counter-measure/time-location-check/unauthenticated-location REST API.

{
  "timeUnAuthenticatedCheckValidationEnabled": {
    "unAuthLocationId": 1,
    "messageFilteringOnUnAuthLocationEnabled": true,
    "avgFlightVelocity": 70,
    "blockListRefreshTimer": 11,
    "timeUnit": "SECONDS",
    "cacheRefreshTimer": 11,
    "errorAction": {
      "title": "Unauthenticated location check failed",
      "statusCode": 406,
      "action": "REJECT"
    },

For more information about API path, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy REST Specification Guide.

Configure

Enable using CNC Console

1. From the left navigation menu, navigate to SEPP and then click Security Countermeasure.
2. Click Cat-3 Time Location Check under Security Counter Measure, Unauthenticated Location page appears underneath.
3. Click Unauthenticated Location under Security Countermeasure. The Option appears underneath.
4. Click Option, the option screen appears at the right pane. The Cat 3 - Previous Location Check feature details are available on the screen.
5. Click Edit icon to modify the Option. The Edit Option page appears.
6. Set the Cat 3 Time Check Unauthenticated Location Enabled to True.

Note:

To enable the feature, the user also needs to enable the Cat3-Time Location Check - Unauthenticated Location Enabled parameter available at Remote SEPP Set, using CNC Console screen or REST APIs.

For more details about CNC Console configurations, see Configuring SEPP using CNC Console section in the Oracle Communications Cloud Native Core, Security Edge Protection Proxy User Guide.

You can configure the feature using REST API and CNC Console:

• Configure using REST API: Perform the feature configurations as described in the Cat-3 Time Check for Roaming Subscribers section in Oracle Communications Cloud Native Core, Security Edge Protection Proxy REST Specification Guide.
• Configure using CNC Console: Perform the feature configurations as described in the Cat-3 Time Check for Roaming Subscribers section in Configuring SEPP using CNC Console.

Observe

Following are the Cat-3 Previous Location Check feature specific metrics:

• ocsepp_time_unauthenticated_location_validation_requests_total
• ocsepp_time_unauthenticated_location_validation_success_total
• ocsepp_time_unauthenticated_location_validation_failure_total
• ocsepp_time_unauthenticated_location_exception_failure_total
• ocsepp_time_unauthenticated_location_blocklist_requests_total

For more information on Cat-3 Previous Location Check feature related SEPP Metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following:

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

3.2.6 IPv6 Dual Stack Support

Using the dual stack mechanism, applications or NFs can establish connections with pods and services in a Kubernetes cluster using IPv4 or IPv6 or both simultaneously. Dual stack provides:

• coexistence strategy that allows hosts to reach IPv4 and IPv6 simultaneously.
• IPv4 and IPv6 allocation to the Kubernetes clusters during cluster creation. This allocation is applicable for all the Kubernetes resources unless explicitly specified during the cluster creation.

SEPP can be deployed on CNE that supports dual stack networking. In case both IPv4 and IPv6 addresses are present in the DNS response, the IPv6 interface will be preferred over IPv4 over external interfaces. Several REST API configurations have been modified to cater to the IPv6 configuration, For more information , see Oracle Communications Cloud Native Core, Security Edge Protection Proxy REST Specification Guide.

The SEPP now supports dual stack communication, that is, it can handle both IPv4 and IPv6 on its external interfaces. However, it still uses IPv4 exclusively for communication with internal microservices.

• SEPP supports both IPv4 and IPv6 for external communications, allowing the SEPP to connect with external entities such as Remote SEPPs and other network functions (NFs).
• Communication with internal microservices within the SEPP cluster is limited to IPv4 only.
• SEPP still uses IPv4 to communicate with common cluster services, including the cnDBTier and CNC Console, even in a dual stack environment.
• When SEPP needs to interface with Remote SEPPs or other intra-NFs, it checks the DNS response. If the DNS response contains both IPv4 and IPv6 addresses, SEPP prefers the IPv6 address for communication. If the DNS response contains only one address family (either IPv4 or IPv6), SEPP uses that address to connect to the endpoint.

IP Address Allocation to Pods

IP address allocation to pods depends on the IP address preference set in the Kubernetes cluster. Pods do not have the privilege to choose an IP address. For example, if the Kubernetes cluster has IPv4 preferred configuration, both IPv4 and IPv6 are allocated to the pod, but the primary IP address is IPv4.

Example of a pod deployed in an IPv4 preferred infrastructure:

Status: Running
IP: 10.233.105.175
IPs: 
IP: 10.233.105.175 
IP: fd00::1:1c6b:9742:b7f1:f1a6

IP address allocation to pods depends on the IP address preference set in the Kubernetes cluster. Pods do not have the privilege to choose an IP address. For example, if the Kubernetes cluster has IPv6 preferred configuration, both IPv4 and IPv6 are allocated to the pod, but the primary IP address is IPv6.

Example of a pod deployed in an IPv6 preferred infrastructure:

Status: Running 
IP: fd00::1:1c6b:9742:b7f1:f1a6 
IPs: 
IP: fd00::1:1c6b:9742:b7f1:f1a6 
IP: 10.233.105.175

.

The following table describes how IP address allocation, IP Family Policy, and IP Families vary based on the DeploymentMode Helm parameter configuration for services:

Table 3-10 IP Address Allocation

Infrastructure Preference	Application Preference (DeploymentMode Helm Parameter)	IP Family Policy Attribute	IP Families Attribute	Pod IP	Service IP	Endpoints
IPv4 Preferred	IPv4	SingleStack	IPv4	IPv4, IPv6	IPv4	IPv4
IPv6 Preferred	IPv4	SingleStack	IPv4	IPv6, IPv4	IPv4	IPv4
IPv4 Preferred	IPv6	SingleStack	IPv6	IPv4, IPv6	IPv6	IPv6
IPv6 Preferred	IPv6	SingleStack	IPv6	IPv6, IPv4	IPv6	IPv6
IPv4 Preferred	IPv4_IPv6 (IPv4Preferred)	RequireDualStack	IPv4 Preferred	IPv4, IPv6	IPv4, IPv6	IPv4
IPv6 Preferred	IPv4_IPv6 (IPv4Preferred)	RequireDualStack	IPv4 Preferred	IPv6, IPv4	IPv6, IPv4	IPv4
IPv4 Preferred	IPv6_IPv4 (IPv6Preferred)	RequireDualStack	IPv6 Preferred	IPv4, IPv6	IPv4, IPv6	IPv6
IPv6 Preferred	IPv6_IPv4 (IPv6Preferred)	RequireDualStack	IPv6 Preferred	IPv6, Pv4	IPv6, IPv4	IPv6

Upgrade Impact

In a dual stack environment, all the SEPP backend services are configured as Single Stack. As per Kubernetes limitation, SEPP upgrade is not supported when there is a mismatch in ipFamilies configured between SEPP backend microservices and the deployment mode ipFamilies configuration. In this case, SEPP recommends a fresh installation to change the preferred ipFamilies. However, this is not applicable for the edge microservices (Ingress Gateway microservice) as they can choose to increase the list of ipFamilies by setting it as dual stack according to the cluster preference.

Managing Dual Stack Support

Enable

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

• CNE or any CNE cloud network with Dual Stack Support ( IPv4 preferred) must be enabled.
• All cluster nodes must come with IPv6 address.

Configure

Helm Configuration

Note:

SEPP now supports dual stack communication, but this support is only applicable to external communication interfaces. Internal communication continues to use IPv4 only.

Configure the following in N32-ingress-gateway and Plmn-ingress-gateway:

Single Stack IPv4

#deployment mode for dual stack support >> Possible values : IPv6_IPv4 (Dual Stack Mode) and IPv4 (Non-dual stack/RH mode )
deploymentMode: IPv4

Dual Stack IPv4 preferred

#deployment mode for dual stack support >> Possible values : IPv6_IPv4 (Dual Stack Mode) and IPv4 (Non-dual stack/RH mode )
deploymentMode: IPv6_IPv4

For more information about above mentioned Helm parameters, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy Installation, Upgrade, and Fault Recovery Guide.

Configure

You can configure the feature using REST API and CNC Console:

• Configure using REST API: Perform the feature configurations as described in the Remote SEPP section in Oracle Communications Cloud Native Core, Security Edge Protection Proxy REST Specification Guide.
• Configure using CNC Console: Perform the feature configurations as described in the Remote SEPP section in Configuring SEPP using CNC Console.

Observe

Following are the IPv6 Dual Stack Support specific Gateway metrics:

• Egress Gateway metrics:
  • oc_egressgateway_incoming_ip_type
  • oc_egressgateway_outgoing_ip_type
  • oc_egressgateway_dualstack_ip_rejected_total
• Ingress Gateway metrics:
  • oc_ingressgateway_incoming_ip_type
  • oc_ingressgateway_outgoing_ip_type

For more information on IPv6 Dual Stack Support feature related SEPP Metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following steps:

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

3.2.7 Multiple SEPP Instances on Shared cnDBTier Cluster

Oracle Communications Cloud Native Core, Security Edge Protection Proxy (SEPP) now supports a new deployment model that allows multiple SEPP instances to be deployed on a shared cnDBTier cluster. This approach optimizes resource utilization, as SEPP is a stateless service, and the existing cnDBTier often operates below capacity.

By leveraging a shared cnDBTier for multiple SEPP instances, significant savings in CPU resources can be achieved, compared to maintaining separate databases for each instance. This shared cnDBTier is designed with security in mind, restricting data access for each SEPP instance through the use of distinct logins and credentials during deployment. As a result, each SEPP instance can securely access its dedicated database while utilising the same cnDBTier within the Kubernetes cluster. For instance, deploying four SEPP instances within the same cluster can lead to considerable resource efficiency compared to deploying each instance with its own database.

In this deployment model, 1+1 GR redundancy only supported with maximum four SEPP instances in one cluster to avoid operational scaling issues. This deployment model can only be used for SEPP instances deployed on the same CNE cluster.

Detailed Description

In this deployment model, multiple SEPPs are deployed on a shared cnDBTier cluster. The following diagram illustrates the comprehensive architecture of the deployment model.

Figure 3-19 Multiple SEPP instances on shared cnDBTier cluster architecture

This deployment model supports a two-site georeplication setup with four SEPP instances deployed per site and per cluster. Each cnDBTier is configured with a single replication channel.

The Key Concepts of the feature are the following:

• Shared cnDBTier in the same Cluster: A single database cluster is used to streamline data storage and management across multiple SEPP instances.

• Credential-based Segregation: Seamlessly segregate data access and permissions based on unique credentials or access keys assigned to each NF user.

Shared cnDBTier in the same Cluster:

• cndb-cluster-site1

The MySQL databases for SEPP-INSTANCE-1, SEPP-INSTANCE-2, SEPP-INSTANCE-3, and SEPP-INSTANCE-4 are configured on the cndb-cluster-site1 in a shared mode, separated by SEPP user credentials. The databases of SEPP-INSTANCE-5, SEPP-INSTANCE-6, SEPP-INSTANCE-7, and SEPP-INSTANCE-8 are replicated on this cluster.

• cndb-cluster-site2

The MySQL databases for SEPP-INSTANCE-5, SEPP-INSTANCE-6, SEPP-INSTANCE-7, and SEPP-INSTANCE-8 are configured on the cndb-cluster-site2 in shared mode, separated by SEPP user credentials. The databases of SEPP-INSTANCE-1, SEPP-INSTANCE-2, SEPP-INSTANCE-3, and SEPP-INSTANCE-4 are replicated on this cluster.

Credential-based Segregation:

Access control for each SEPP database is managed by the root user on the cnDBTier cluster. All SEPP databases are replicated to another configured site to enable recovery in case the database becomes corrupted. All SEPP instances are configured on CNC Console, and users can be assigned instance-specific roles to restrict access to other SEPP instances.

Installing and Managing multiple SEPP instances on shared cnDBTier cluster

Multiple SEPP instances on the shared cnDBTier cluster deployment model is enabled by default on SEPP. To enable the access restriction per SEPP instance on CNC Console, do the following:

1. Set the CNC Console parameter instanceLevelAuthorizationEnabled to true in the occncc_custom_values_.yaml file.
2. Run Helm upgrade command to upgrade CNC console.
3. When Helm upgrade completes, all existing users will have a new role "INSTANCE_ALL" assigned by default.

To assign a NF-specific role, the admin must unassign the "INSTANCE_ALL" role from the user and map the user to the desired NF role.

cnDBTier Resource Profile Updates

The following profile updates are required in the occndbtier_custom_values_<version>.yamlfile for this feature.

• Install the cnDBTier using the 'New Values' mentioned in the following table. The 'New Values' must be updated in the occndbtier_custom_values_<version>.yaml file.
• If the cnDBTier is already installed, perform an upgrade using the procedure mentioned in the Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.

Table 3-11 cnDBTier Parameter Values

Parameter	Default Values (in CV file)	New Values (to be Updated in CV file)
MaxNoOfTables	1024	3000
MaxNoOfAttributes	5000	24000
MaxNoOfOrderedIndexes	1024	3700

Configure

The following are the configurations for the multiple SEPP instances on shared cnDBTier cluster deployment model:

Helm Configuration

This section provides the multiple SEPP instances on shared cnDBTier cluster deployment model related Helm configurations.

The following timeout parameter must be configured to check whether database connectivity with Service is healthy or not in the microservices such as cn32f-svc, cn32c-svc, pn32f-svc, pn32c-svc and config-mgr-svc:

configs:
    domainLabels: 3
    rateLimitingConfigMap: rss-ratelimit-map
    egressRateLimitingConfigMap: egress-ratelimit-map
    dbCheckRefreshTimeout: 30000

Table 3-12 Details of Helm Parameter

Parameter	Description	Details
dbCheckRefreshTimeout	This is a mandatory parameter. This value represents time interval that checks whether database connectivity with Service is healthy or not.	Data Type: Integer Default Value: 30000ms

MySQL Configurations

This section provides the information about the MySQL configurations required to configure this deployment model.

While configuring SEPP, user has to create MySQL credential secrets. The user can configure unique credentials while creating MySQL secrets, followed by configuring unique credentials for every SEPP instance.

Note:

SEPP database and SEPP BACKUP DB can be created with NF_INSTANCE_ID in db name, whereas "-" is replaced by "_".

To create the user and the database, see Configuring database, Creating Users, and Granting Permissions section of Oracle Communications Cloud Native Core, Security Edge Protection Proxy Installation, Upgrade, and Fault Recovery Guide.

Observe

CNC Console IAM Configurations

This section provides the information about the CNC Console IAM configurations required to configure this deployment model.

Log in to the CNC Console using admin credentials to create user and assign NF specific roles to the user.

The following roles are predefined in the CNC Console IAM:

• SEPP_READ: The assigned user can perform the read operation for NFs with this permission. If the user has a SEPP_READ role, then the user can only read configurations of any MOs configurations within the Policy and cannot write or update or delete any record.
• SEPP_WRITE: With this permission, the assigned user can perform create, read, update, and delete operations for NFs. If the user has SEPP_WRITE then the user can read, write, update, or delete any MOs configurations within the NF.
• Admin: The user assigned this role has access to all resources (NF resources and CS resources) within the CNC Console application.

  The user can create, read, update, and delete MO configurations for all NFs supported by CNC Console.

• INSTANCE_ALL: A user with INSTANCE_ALL role can access all instances, provided they have ADMIN, <NF>_READ, or <NF>_WRITE role, and Cluster level role in case it is a multicluster deployment. This role is automatically assigned to all local users during the first upgrade when this deployment model is enabled. If an operator wants to restrict a user to a particular instance, then they have to unassign INSTANCE_ALL role and assign any of the instance level roles to the user.
• Instance specific role: Instance Level roles allow users to have access to specific NF instances. A user can be associated with single or multiple instance roles. Instance Role name must match the instance ID of that particular instance given in Helm configuration inglobal.instances[i].id.

Combinations of SEPP user roles

• ADMIN/SEPP_READ/SEPP_WRITE + INSTANCE_ALL: Here user will have access to all SEPP Instances.
• ADMIN/SEPP_READ/SEPP_WRITE + sepp_instance_specific role: Here user will have access to a specific SEPP instance.

For more details about CNC Console Configurations, see "Types of Roles in CNC Console" section in the Cloud Native Configuration Console User Guide.

Following are the deployment model specific metrics:

• ocsepp_cn32f_database_connectivity_healthy
• ocsepp_pn32f_database_connectivity_healthy
• ocsepp_cn32c_database_connectivity_healthy
• ocsepp_pn32c_database_connectivity_healthy
• ocsepp_configmgr_database_connectivity_healthy

For more information about metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following:

1. Collect the logs and Troubleshooting Scenarios: For more information on how to collect logs and troubleshooting information, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

3.2.8 Proactive Status Updates on SEPP

Oracle Communications Cloud Native Core, Security Edge Protection Proxy (SEPP) supports Proactive Status Updates on SEPP feature.

In the previous releases, consumer NFs sent Service Based Interface (SBI) message requests to Remote SEPP without checking the status of Remote SEPP because there was no health check mechanism implemented at SEPP.

Using this feature, consumer NFs can determine the health or connection status of Remote SEPP before forwarding any SBI message request to it. This feature allows consumer NFs or Consumer SEPPs to perform the following health check verification on Remote SEPPs:

• Determines if SEPP is reachable.
• Determines if SEPP is available to respond to SBI message requests.

Assumptions

The following are the assumptions of the feature:

• This feature applies only to the N32 Egress gateway and N32 Ingress gateway.
• The user can enable or disable the feature for each Remote SEPP Peer. If the healthAPIURI and healthAPIMethod fields are blank in the Remote SEPP configuration, the feature will be disabled for that peer.
• On N32 Ingress Gateway, the response codes allowed are 200,201,202,203,204,205,206,207,208, and 226.
• On N32 Egress Gateway, the response codes that will be used to mark peers as healthy are 200,204,400, 401,403,404, 405, 501, and 503.

Detailed Description

The following diagram represents the detailed architecture of this feature.

Figure 3-20 Proactive Status Updates on SEPP Architecture

1. The initiator SEPP has 4 Remote Peer SEPPs configured; Primary, Secondary, and Tertiary - (associated with the Responder SEPP-1 Remote SEPP set), and Peer-4, associated with Responder SEPP-2.
2. In the default case, when the feature is not present or is disabled, the initiator SEPP communicates with the Primary SEPP. If the Primary SEPP goes down for some reason, it retries on the Primary SEPP and then reroutes to the Secondary SEPP. If the Secondary SEPP also goes down, the initiator SEPP retries traffic on both the Primary and Secondary SEPPs before rerouting traffic to the Tertiary SEPP, and so on.
3. The above process introduces latency for the outbound traffic of the SEPP due to the failed peer SEPPs.
4. With the proactive status feature enabled, the N32 Egress gateway sends a health check request using a configured Health API URI and method combination (GET and OPTIONS methods supported) towards the Peer SEPPs. The response code received will be compared against a list of pre-configured response codes to determine the health status of each Remote Peer SEPP. These messages will be sent at a configured periodic interval.
5. The N32 Ingress gateway will receive the URI and method and compare them against the configured settings. It will then respond with the configured response code, which the N32 Egress Gateway will use to proactively determine the health status of each peer SEPP. The user can configure the response sent from the N32 Ingress gateway within the range of 2xx.
6. If the feature is enabled as described in point 2, initially the traffic will be routed to the Primary SEPP. If the Primary SEPP goes down, the health API will receive a response code not configured on the N32 Egress gateway, and the Primary SEPP will be marked as UNHEALTHY.
7. Considering the Responder SEPP-1 peers in this example, as soon as the Primary SEPP is marked as UNHEALTHY, the initiator SEPP reroutes the traffic towards the next healthy peer (Secondary SEPP) without retrying on the Primary SEPP. If the Secondary SEPP also goes down, it will be marked as UNHEALTHY and traffic will be rerouted to the Tertiary SEPP without retrying on the other peer SEPPs. This reduces latency and improves the overall efficiency of the system.

Managing Proactive Status Updates on SEPP Feature

Proactive Status Updates on the SEPP feature is disabled by default. It is enabled using Helm and CNC Console or REST based configurations on N32 Egress Gateway and N32 Ingress Gateway.

To enable the feature, do the following:

1. Set the healthCheckMonitoring.enabled parameter to true in the N32 Ingress Gateway section of ocsepp_custom_values_<version>.yaml file.

   
   #To enable feature on IGW
   healthCheckMonitoring:
     enabled: true

2. Set the seppPeerHealthCheck parameter to true in the N32 Egress Gateway section of ocsepp_custom_values_<version>.yaml file.

   #To enable featue on EGW for
            seppPeerHealthCheck: true  
   #Response codes that will be considered to mark peer healthyseppPeerHealthCheckCodes: "200,204,400,401,403,404,405,501,503"

At CNC Console:

Note:

To enable the feature at the CNC console, ensure that the feature parameters on Helm are set to true.

Perform the following procedure to enable the support for the Proactive Status Updates on the SEPP feature:

1. In the CNC Console GUI, from the left navigation menu, navigate toSEPP and then click Configurations.
2. The Gateway and cnDBTier appear underneath. Select Gateway and navigate to the IGW option to configure the Ingress Gateway APIs. The PLMN Ingress Gateway and N32 Ingress Gateway appear underneath.
3. Click Health Check Configuration under N32 Ingress Gateway. The Health Check Configuration page is displayed.
4. Click the Edit icon to modify the Health Check Configuration. The Health Check ConfigurationOptions page appears.
5. Set Enabled to True.

Perform the following procedure to configure the Remote SEPP:

1. In the CNC Console GUI, from the left navigation menu, navigate toSEPP and then click Remote SEPP.
2. The list of all the Remote SEPPs configured along with the parameters appears on the right pane.
3. Click the Edit icon to modify a specific parameter. The page is enabled for modification.
4. Add the healthApiPath and healthApiMethod in the Remote SEPP. The healthApiMethod drop-down has only GET and OPTIONS.

For more details about CNC Console Configurations, see Configuring SEPP using CNC Console section in the Oracle Communications Cloud Native Core, Security Edge Protection Proxy User Guide.

At REST API:

• To enable on N32 Ingress Gateway, Set enabled to true in healthCheckConfigOptions REST API.

   curl http://<release-name>-config-mgr-svc:<port>/sepp/nf-common-component/v1/igw/n32/healthCheckConfigOptions -XPUT -H 'Content-type: application/json' -d '{
  
    "enabled":true,
    "healthCheckConfigObject": {
      "healthCheckResponseCode": 200,
      "healthCheckRequestMethod":"OPTIONS",
      "healthCheckResourceUri": "/health-check/v1/status"
    }
  }'

  or

  
  curl http://<release-name>-config-mgr-svc:<port>/sepp/nf-common-component/v1/igw/n32/healthCheckConfigOptions -XPUT -H 'Content-type: application/json' -d '{
   
    "enabled":true,
    "healthCheckConfigObject": {
      "healthCheckResponseCode": 200,
      "healthCheckRequestMethod":"GET",
      "healthCheckResourceUri": "/health-status/v1/status"
    }
  }'

• To enable the feature on the N32 Egress gateway for a particular Remote SEPP, add the parameters healthApiPath and healthApiMethod in the Remote SEPP. The healthApiMethod parameter supports only GET and OPTIONS.

Note:

By default, these parameter values are null. After enabling the "seppPeerHealthCheck" Helm parameter, the user needs to add the above parameters to the Remote SEPP for the peer whose health status they want to monitor.

 
curl http://<release-name>-config-mgr-svc:<port>/sepp-configuration/v1/remotesepp -XPOST -H 'Content-type: application/json' -d '{
"name":"SEPP-2",
"plmnIdList":[{"mcc":"111","mnc":"345"}],
"domain":"mnc345.mcc111.3gppnetwork.org",
"seppFqdn":"sepp-ats-rel-stubserver",
"securityCapabilityList":["TLS"],
"remoteSeppIpAddress":"10.233.52.22",
"port":8443,
"apiPrefix":"",
"isEnabled":"TRUE",
"apiVersion":"v1",
"healthApiPath": "/health-check/v1/status"
"healthApiMethod": "OPTIONS"}'

or

curl http://<release-name>-config-mgr-svc:<port>/sepp-configuration/v1/remotesepp -XPOST -H 'Content-type: application/json' -d '{
"name":"SEPP-2",
"plmnIdList":[{"mcc":"311","mnc":"345"}],
"domain":"mnc345.mcc311.3gppnetwork.org",
"seppFqdn":"sepp-rel-stubserver",
"securityCapabilityList":["TLS"],
"remoteSeppIpAddress":"10.233.52.255",
"port":443,
"apiPrefix":"",
"isEnabled":"TRUE",
"apiVersion":"v1",
"healthApiPath": "/health-status/v1/status"
"healthApiMethod": "GET"}'

The user can also configure the feature during runtime (i.e. without deleting the Remote SEPP Set). To do so, run the following command:

 
curl http://<release-name>-config-mgr-svc:<port>/sepp-configuration/v1/remotesepp/SEPP-2 -XPUT -H 'Content-type: application/json' -d '{
"name":"SEPP-2",
"plmnIdList":[{"mcc":"111","mnc":"345"}],
"domain":"mnc345.mcc111.3gppnetwork.org",
"seppFqdn":"sepp-ats-rel-stubserver",
"securityCapabilityList":["TLS"],
"remoteSeppIpAddress":"10.233.52.22",
"port":8443,
"apiPrefix":"",
"isEnabled":"TRUE",
"apiVersion":"v1",

#######Add the below 2 parameters if not present#######
"healthApiPath": "/health-check/v1/status"
"healthApiMethod": "OPTIONS"}'

Note:

To disable the feature on a Remote SEPP Peer, run the following steps:

1. Delete the Remote SEPP Set associated with the Peer.
2. Run the following command to modify the Remote SEPP Peer:

    
   curl http://<release-name>-config-mgr-svc:<port>/sepp-configuration/v1/remotesepp/SEPP-2 -XPUT -H 'Content-type: application/json' -d '{
   "name":"SEPP-2",
   "plmnIdList":[{"mcc":"111","mnc":"345"}],
   "domain":"mnc345.mcc111.3gppnetwork.org",
   "seppFqdn":"sepp-ats-rel-stubserver",
   "securityCapabilityList":["TLS"],
   "remoteSeppIpAddress":"10.233.52.22",
   "port":8443,
   "apiPrefix":"",
   "isEnabled":"TRUE",
   "apiVersion":"v1"
   }'

3. Create the Remote SEPP Set again.

Run the following command to modify frequency, timeout, failureThreshold, or SuccessThreshold parameters of the health check requests being sent:

curl http://127.0.0.1:9090/sepp/nf-common-component/v1/egw/n32/peermonitoringconfiguration -XPUT -H 'Content-type: application/json' -d '{
"enabled":false,"timeout":1000,"frequency":6000,"failureThreshold":3,"successThreshold":3}'

Note:

Do not change the value for enabled for this feature. It must remain as false.

Configure

You can configure the feature using REST API and CNC Console.

• Configure using REST API: Perform the feature configurations as described in Health Check Configuration (N32 IGW), Peer monitoring configuration and Remote SEPP REST APIs in Oracle Communications Cloud Native Core, Security Edge Protection Proxy REST Specification Guide.
• Configure using CNC Console: Perform the feature configurations as described in Configuring SEPP using CNC Console.

Observe

Following are the feature specific metrics:

• 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_ingressgateway_health_check_incoming_ping_total

For more information about metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following:

1. Collect the logs and Troubleshooting Scenarios: For more information on how to collect logs and troubleshooting information, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

3.2.9 Traffic Segregation

This feature provides end-to-end traffic segregation to SEPP 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 SEPP 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 SEPP 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 SEPP.

Prerequisites

The CNLB feature is only available in SEPP if OCCNE is installed with CNLB and Multus.

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. SEPP supports two types of CNLB NADs:

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

Ingress Traffic Segregation

The following diagram represents the traffic ingressing from the external cluster (different NFs like AMF) to Plmn-ingress-gateway.

Figure 3-21 Ingress Traffic Segregation

Here AMF-1 and AMF-2 send messages to the Plmn-ingress-gateway of the SEPP. Internal traffic between cn32f and the n32-egress-gateway travels through the default interface, eth0, which is connected to the pods. The signaling traffic between AMF-1 and SEPP, as well as between AMF-2 and SEPP, travels through a new interface, veth1, created using the Multus plugin. The Ingress service IPs and ports will be set up in Cloud Native Edge Load Balancers (CNE LBs), which will direct traffic to the plmn-ingress-gateway. This gateway will then handle the requests and route them to the SEPP. The certificate management procedure will remain unchanged. CN load balancers support TLS versions 1.2 and 1.3.

Egress Traffic Segregation

The following diagram represents the traffic egressing from n32-egress-gateway to multiple Remote SEPPs.

Figure 3-22 Egress Traffic Segregation

Here CSEPP is connected to two different PSEPPs, which are on different PLMNs and different networks. Internal traffic between cn32f and the n32-egress-gateway passes through the default interface, eth0, which is connected to the pods. The signaling traffic between CSEPP and PSEPP1, as well as between CSEPP and PSEPP2, travels through a new interface, veth1, created using the Multus plugin. Egress IPs will be defined at the CNE load balancers (LBs), which will perform SNAT on the IP addresses in requests sent to PSEPP1 and PSEPP2. The certificate management procedure will remain unchanged. CN load balancers support TLS versions 1.2 and 1.3.

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 custom values file.

Configuration

For more information about Traffic Segregation configuration, see " Configuring Traffic Segregation" section in Oracle Communications Cloud Native Core, Security Edge Protection Proxy Installation, Upgrade, and Fault Recovery Guide..

Observe

There are no Metrics, KPIs, or Alerts available for this feature.

3.2.10 Support for Originating Network Id Header Validation, Insertion, and Transposition

This feature enables the insertion or transposition of either the 3gpp-Sbi-Originating-Network-Id header or the 3gpp-Sbi-Asserted-Plmn-Id header into SBI request messages. It is expected that the originator of a request can be easily identified, but there are some scenarios where the originating network information may not be conveyed in the SBI requests to the home network. In such scenarios, this feature infer the originating PLMN ID and populates the required header in the SBI request.

Feature Overview

The feature supports the following three functionalities:

• Header Value Validation using Cat 2 Network ID Validation feature
• Header Addition
• Header Transposition

Header Value Validation

If 3gpp-Sbi-Originating-Network-Id or 3gpp-Sbi-Asserted-Plmn-Id header is already present in the incoming request and the user wants to validate the PLMN ID in this header, then the user has to enable and configure the Cat 2 - Network ID validation feature.

• At C SEPP (consumer SEPP), Cat 2 feature validates the PLMN ID value present in the header against the configured local SEPP PLMN IDs.
• At P SEPP (producer SEPP), Cat 2 feature validates the PLMN ID value present in the header against the configured remote SEPP PLMN IDs.

Request is either allowed and forwarded or discarded as per the validation result and the Cat 2 error configurations.

Note:

• The user must enable the Cat 2 feature at global and Remote SEPP Set level.
• The user must add the required headers (3gpp-Sbi-Originating-Network-Id or 3gpp-Sbi-Asserted-Plmn-Id) in the Cat 2 header configurations.
• If the Cat 2 is disabled or required header configuration is not done, header validation will not be performed.

  For more details about the Cat 2 - Network ID Validation feature, refer to Cat 2 - Network ID Validation feature section.

Header Addition

The 3gpp-Sbi-Originating-Network-Id header or 3gpp-Sbi-Asserted-Plmn-Id header is added to the request according to the user configuration. The header addition occurs on both P SEPP and C SEPP when the incoming request does not have any header present.

Header Transposition

If the incoming request at producer SEPP has a header (3gpp-Sbi-Originating-Network-Id header or 3gpp-Sbi-Asserted-Plmn-Id) but the producer SEPP's supported header name is different from this request header, then the original header present in the request is replaced with the header supported by producer SEPP. SEPP supported header name is user configurable.

For example, if the header in the incoming request is 3gpp-Sbi-Asserted-Plmn-Id, but the user has configured the 3gpp-Sbi-Originating-Network-Id header at producer SEPP, then request header 3gpp-Sbi-Asserted-Plmn-Id header is replaced with the 3gpp-Sbi-Originating-Network-Id header.

Note:

• After the header name transposition, its value will be the same as the value that was present in the original request header.
• If the request header is 3gpp-Sbi-Originating-Network-Id and its value is in the format MCC-MNC";src:"srctype"-"srcfqdn (Here srcType = "SCP"/"SEPP"), then during transposition to 3gpp-Sbi-Asserted-Plmn-Id header, the value will only have MCC-MNC and remaining part from the header value will be stripped off.

Example:

Header before transposition: 3gpp-Sbi-Originating-Network-Id:123-456;src:SEPP sepp001.sepp.5gc.mnc333.mcc222.3gppnetwork.org

Header after transposition: 3gpp-Sbi-Asserted-Plmn-Id:123-456

Detailed Description

Functioning at C SEPP

If the 3gpp-Sbi-Originating-Network-Id or 3gpp-Sbi-Asserted-Plmn-Id header is present in the incoming request, the header value validation is performed using the Cat 2 - Network ID Validation feature. This functionality extracts the PLMN ID value from the header and matches it against the local SEPP PLMN IDs supported by the C SEPP. The user has to enable and configure the Cat 2 feature functionalities through CNC Console or REST API to do the validation.

If the 3gpp-Sbi-Originating-Network-Id or 3gpp-Sbi-Asserted-Plmn-Id header is missing in the request, it will be added in the request by C SEPP. The user has to enable and configure the feature through CNC Console or REST API.

C SEPP adds the header that its Remote SEPP (P SEPP) supports, so the header name will be taken from user's configured header name at Remote SEPP Set level. Header value will be populated with the user configured local PLMN ID at C SEPP. If the user has not configured the local PLMN ID, then one of the local PLMN ID's values supported by the C SEPP will be used to populate the missing header.

The following diagram represents the functionality of the feature on the C SEPP side.

Figure 3-23 C SEPP side functionality

Instance 1: Request comes with 3gpp-Sbi-Originating-Network-Id: 987-654

In this example, the user has enabled the Cat 2 feature and done the header configuration for '3gpp-Sbi-Originating-Network-Id' header. Request comes at CSEPP and as the PLMN ID value (987-654) extracted from the header is not present in the SEPP local PLMMN ID List (101-100 to 130-100), request is discarded.

Instance 2: (Sbi request comes without any of the 3gpp-Sbi-Originating-Network-Id or 3gpp-Sbi-Asserted-Plmn-Id headers)

In this example, the user has enabled the Cat 2 feature and done the header configuration for '3gpp-Sbi-Originating-Network-Id' and '3gpp-Sbi-Asserted-Plmn-Id' headers. As request is not having any of the headers, Cat 2 feature bypasses the validation here. The user has enabled the feature, configured the '111-100' as local PLMN Id and header name as '3gpp-Sbi-Originating-Network-Id' at Remote SEPP Set level.

Header '3gpp-Sbi-Originating-Network-Id' with value '111-100;src:SEPP-<seppfqdn>' is added successfully in the request as per this header 3gpp specification.

Note:

If the user configures the '3gpp-Sbi-Asserted-Plmn-Id' header here, then '3gpp-Sbi-Asserted-Plmn-Id' header is added with just having the PLMN ID value i.e. '111-100' as per this header 3gpp specifications.

Functioning at P SEPP

The following diagram represents the functionality of the feature on the P SEPP side.

Figure 3-24 P SEPP side functionality

If the 3gpp-Sbi-Originating-Network-Id or 3gpp-Sbi-Asserted-Plmn-Id header is present in the incoming request, the header value validation is performed using the Cat 2 - Network ID Validation feature. This functionality extracts the PLMN ID value from the header and matches it against the remote SEPP PLMN IDs supported by the P SEPP. The user has to enable and configure the Cat 2 feature functionalities through CNC Console or REST API to do the validation.

If the 3gpp-Sbi-Originating-Network-Id or 3gpp-Sbi-Asserted-Plmn-Id header is missing in the request, it will be added in the request by P SEPP. The user has to enable and configure the feature through CNC Console or REST API.

P SEPP adds the header supported by the producer SEPP network, and the header name will be the SEPP supported header name, configured by the user. Header value will be populated with the user configured remote PLMN ID value per Remote SEPP Set level. If this PLMN ID is not configured, then SEPP takes one of the PLMN ID value from the remote list of supported PLMN IDs per Remote SEPP Set.

If the incoming request at producer SEPP has one header (3gpp-Sbi-Originating-Network-Id header or 3gpp-Sbi-Asserted-Plmn-Id) but the producer SEPP supported header name is different from this request header, then the original header present in the request is replaced with the header supported by producer SEPP. SEPP supported header name is user configurable.

Instance 1: Request comes with '3gpp-Sbi-Originating-Network-Id: 987-654'

In instance 1, the user has enabled the Cat 2 feature and done the header configuration for 3gpp-Sbi-Originating-Network-Id header. The request comes at P SEPP and as the PLMN ID value (987-654) extracted from the header is not present in the Remote PLMN ID List (201-200 to 230-200), request is discarded.

Instance 2: (Sbi request comes without 3gpp-Sbi-Originating-Network-Id or 3gpp-Sbi-Asserted-Plmn-Id)

In this example, the user has enabled the Cat 2 feature and performed the header configuration for 3gpp-Sbi-Originating-Network-Id and 3gpp-Sbi-Asserted-Plmn-Id headers. As the request does not have any of the headers, Cat 2 features bypass the validation here.

Here, user has enabled the feature, configured the '201-200' as remote PLMN ID and set 3gpp-Sbi-Asserted-Plmn-Id as SEPP supported header name.

Header 3gpp-Sbi-Asserted-Plmn-Id with value '201-200' is added successfully in the request as per the format defined in the 3gpp specification of '3gpp-Sbi-Asserted-Plmn-Id' header.

Note:

If the user configures the '3gpp-Sbi-Originating-Network-Id' header, then '3gpp-Sbi-Originating-Network-Id' header is added as '201-200';src:SEPP-<seppfqdn>' as per the format defined in the 3gpp specifications of the header.

Instance 3: (Sbi request comes with 3gpp-Sbi-Originating-Network-Id: 201-200)

In this instance, the request comes with 3gpp-Sbi-Originating-Network-Id but the header supported at the PSEPP is 3gpp-Sbi-Asserted-Plmn-Id. Hence, header transposition occurs and the incoming original header, which is 3gpp-Sbi-Originating-Network-Id: 201-200 is replaced by 3gpp-Sbi-Asserted-Plmn-Id: 201-200.

Note:

• The headers 3gpp-Sbi-Originating-Network-Id and 3gpp-Sbi-Asserted-Plmn-Id wont be present in the incoming sbi request at the same time.
• If the Cat 2 feature is disabled or not configured for the 3gpp-Sbi-Originating-Network-Id or 3gpp-Sbi-Asserted-Plmn-Id headers, the no validation will be performed for the PLMN ID in these headers.
• If an incoming Sbi request does not have either of the 3gpp-Sbi-Originating-Network-Id or 3gpp-Sbi-Asserted-Plmn-Id headers, then the Cat 2 validation will be bypassed and the header is added by feature as per the user's configurations.
• When the SEPP is deployed in the roaming hub mode, header Addition or transposition is not performed.
• SNPN-ID in 3gpp-Sbi-Originating-Network-Id is presently not supported.

Managing the Support for Originating Network Id Header Validation, Insertion, and Transposition Feature

You can enable the Support for Originating Network Id Header Validation, Insertion, and Transposition feature using the CNC Console, or REST API.

Enable using REST API

Set originatingNetworkIdSupportEnabled to true in Originating Network Id Header Support Option REST API.

	{ "originatingNetworkIdHeaderSupportOption": {
    "originatingNetworkIdSupportEnabled": true,
    "seppSupportedLocalPlmnId": "444-555",
    "seppSupportedOrigNetworkIdHeader": "3gpp-Sbi-Asserted-Plmn-Id"
  }
}

For more information about the API path, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy REST Specification Guide.

Enable using CNC Console

Perform the following procedure to enable the support for the 3gpp-Sbi-Originating-Network-Id header feature:

1. From the left navigation menu, navigate to SEPP and click Originating Network ID Header Support. The Option appears underneath.
2. Click Option, the options screen appears on the right pane with parameters to enable the feature.
3. Click the Edit icon to modify the Option. The Edit Option page appears.
4. Set Enabled to True or False.

For more details about CNC Console configurations, see Configuring SEPP using CNC Console.

Configure

You can configure the feature using REST API and CNC Console.

• Configure using REST API: Perform the feature configurations as described in 3gpp-SBI-Originating-Network-Id Header Support Options REST API and Originating Network Id Header Support Option Parameters REST API in Oracle Communications Cloud Native Core, Security Edge Protection Proxy REST Specification Guide.
• Configure using CNC Console: Perform the feature configurations as described in Configuring SEPP using CNC Console.

Observe

Following are the Support for Originating Network Id Header Validation, Insertion, and Transposition feature specific metrics:

• ocsepp_originating_network_id_header_added_total
• ocsepp_originating_id_header_transposed_total
• ocsepp_originating_header_addition_failed
• ocsepp_originating_header_add_or_transpose_failed

For more information on Support for Originating Network Id Header Validation, Insertion, and Transposition feature related SEPP Metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following:

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

3.2.11 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, SEPP now supports the configuration of Ingress Gateway and Egress Gateway parameters using the CNC Console. You can perform HTTP methods using the Console.

Managing common service APIs in the CNC Console

Enable

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

Configure

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

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

1. Collect the logs: For more information on how to collect logs, see Oracle Communications Cloud Native Core, Security Edge Protection ProxyTroubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

3.2.12 Support for TLS

Network Functions (NFs) or peers can use Hypertext Transfer Protocol Secure (HTTPS) to establish secured ingress and egress 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.

From Release 24.1.0 onwards, SEPP supports TLS 1.3 for all functions and interfaces that are supported by TLS 1.2. With this feature, SEPP supports creation of TLS 1.3 and TLS 1.2 connections and mandatory ciphers and extensions.

The following table provides comparison of TLS 1.2 with TLS 1.3:

Table 3-13 Comparison of TLS 1.2 with TLS 1.3

Feature	TLS 1.2	TLS 1.3
TLS Handshake	This is less efficient as it requires more round-trips to complete the handshake process.	This is more efficient as it requires less round-trips to complete the handshake process.
Cipher Suites	This has less secured Cipher suites.	This has more secured Cipher suites. They supports the following ciphers: TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 TLS_AES_256_GCM_SHA384 TLS_AES_128_CCM_8_SHA256: This Cipher is not supported by Java library. TLS_AES_128_CCM_SHA256: This Cipher is not supported by Java library.
Round-Trip Time (RTT)	This has higher RTT during TLS handshake.	This has low RTT.
Performance	This has higher latency during TLS handshake.	This has low latency during TLS handshake.

The following digital signature algorithms of TLS 1.2 and TLS 1.3 are supported in TLS handshake:

Table 3-14 Digital Signature Algorithms

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

Note:

The following functionalities from TLS 1.3 specifications are not supported:

• Zero round-trip time (0-RTT) mode.
• Pre-Shared Key (PSK) exchange.

Enable

This feature is enabled by default at the time of Gateway Services deployment by completing the configurations as described in the Helm Parameters section.

Configure

You can configure this feature using Helm parameters. The following parameters in the Gateway Services microservices such as n32-egress-gateway and PLMN-egress-gateway, must be customized to support TLS 1.3.

The following table describes the newly introduced and updated parameters for TLS 1.3:

Table 3-15 Helm Parameters

Parameter Name	Description	Mandatory/Optional/Conditional	Details
clientDisabledExtension	Disables the extension sent by messages originated by clients (ClientHello).	O	Data Type: String Range: NA Default Value: ec_point_formats
serverDisabledExtension	Disables the extension sent by messages originated by servers (ServerHello).	O	Data Type: String Range: NA Default Value: null
tlsNamedGroups	Provides a list of values sent in the supported_groups extension. These are comma-separated values.	O	Data Type: String Range: NA Default Value: null
clientSignatureSchemes	Provides a list of values sent in the signature_algorithms extension. These are comma-separated values.	O	Data Type: String Range: NA Default Value: null
service.ssl.tlsVersion	Indicates the TLS version.	M	Data Type: String Range: TLSv1.2, TLSv1.3 TLSv1.2 TLSv1.3 Default Value: TLSv1.2, TLSv1.3
allowedCipherSuites	Indicates allowed Ciphers suites.	O	Data Type: String Range: NA Default Values: 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 TLS_AES_256_GCM_SHA384 TLS_AES_128_GCM_SHA256 TLS_CHACHA20_POLY1305_SHA256
cipherSuites	Indicates supported cipher suites.	O	Data Type: String Range: NA Default Values: 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 TLS_AES_256_GCM_SHA384 TLS_AES_128_GCM_SHA256 TLS_CHACHA20_POLY1305_SHA256
messageCopy.security.tlsVersion	Indicates the TLS version for establishing communication between Kafka and NF when security is enabled.	C	Data Type: String Range: TLSv1.3 TLSv1.2 Default Value: TLSv1.3

The following sample Helm configuration is required for TLS 1.3:

clientDisabledExtension: ec_point_formats #comma-separated-values To disable extension being sent in ClientHello
serverDisabledExtension: null #comma-separated-values To disable extension being sent from server originated messages
tlsNamedGroups: null #comma-separated-values to whitelist the supported_groups extension values
clientSignatureSchemes: null #comma-separated-values to whitelist the signature_algorithms extension values
service:
  ssl:
    tlsVersion: TLSv1.2,TLSv1.3
allowedCipherSuites:
  - 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
  - TLS_AES_256_GCM_SHA384
  - TLS_AES_128_GCM_SHA256
  - TLS_CHACHA20_POLY1305_SHA256
cipherSuites:
  - 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
  - TLS_AES_256_GCM_SHA384
  - TLS_AES_128_GCM_SHA256
  - TLS_CHACHA20_POLY1305_SHA256
messageCopy:
  security:
    tlsVersion: TLSv1.2

Note:

• SEPP does not prioritize cipher suites on the basis of priorities. To select cipher on the basis of priorities, you must write the cipher suites in the decreasing order of priority.
• SEPP does not prioritize supported groups on the basis of priorities. To select supported group on the basis of priorities, you must write the supported group values in the 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 pods:

  • rsa_pkcs1_sha512
  • rsa_pkcs1_sha384
  • rsa_pkcs1_sha256
• The mandatory extensions as listed in RFC 8446 cannot be disabled on the client or 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

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 SEPP Metrics section.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following:

1. Collect the logs and Troubleshooting Scenarios: For more information on how to collect logs and troubleshooting information, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

3.2.13 Support for Automated Certificate Lifecycle Management

In SEPP 23.4.x and earlier, X.509 and Transport Layer Security (TLS) certificates were managed manually. When multiple instances of NFs were deployed in a 5G network, certificate management, such as certificate creation, renewal, removal, and so on, became tedious and error-prone.

Starting with SEPP 24.1.x, you can integrate 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 SEPP namespace. For more information about OCCM, see Oracle Communications Cloud Native Core, Certificate Management User Guide.

Figure 3-25 Support for OCCM

The above diagram indicates that OCCM writes the keys to the certificates and SEPP 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

This feature allows to monitor, create, recreate, and renew TLS certificates using OCCM, based on their validity. For information about enabling HTTPS, see "NF Authentication using TLS certificate" in Oracle Communications Cloud Native Core, Security Edge Protection Proxy Installation, Upgrade, and Fault Recovery Guide.

Install Guide Considerations

• Upgrade: When SEPP is deployed with OCCM, follow the specific upgrade procedure. For information about the upgrade strategy, see "Upgrade Strategy" in Oracle Communications Cloud Native Core, Security Edge Protection Proxy Installation, Upgrade, and Fault Recovery Guide.
• Rollback: For more information on migrating the secrets from SEPP to OCCM and removal of Kubernetes secrets from the yaml file, see "Postupgrade Task" in Oracle Communications Cloud Native Core, Security Edge Protection Proxy Installation, Upgrade, and Fault Recovery Guide.

Configure

There are no additional configuration changes required at SEPP.

Maintain

If you encounter any OCCM-specific alerts, see the "OCCM Alerts" section in Oracle Communications Cloud Native Core, Certificate Management User Guide.

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following:

1. Collect the logs and Troubleshooting Scenarios: For more information on how to collect logs and troubleshooting information, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

3.2.14 Load Sharing among Multiple Remote SEPP Nodes

Introduction

Until the current release, SEPP could only redirect traffic to the secondary remote SEPP when the primary SEPP was unavailable, allowing for the use of only one SEPP at a time.

With load sharing among multiple Remote SEPP nodes feature, SEPP can now efficiently distribute incoming traffic among multiple remote SEPPs. To enable this, the operator needs to configure a single virtual FQDN for the remote SEPPs. SEPP retrieves multiple Remote SEPP records from the DNS server and distributes the traffic according to the priority and weight associated with each record. Hence, SEPP can simultaneously route the incoming requests to multiple Remote SEPPs.

Feature Overview

This feature enables SEPP to perform DNS SRV Query to discover Remote SEPPs. This enhances the capability of DNS SRV which already supports DNS Query capability. This feature eases the operation and maintenance for the customer when the failover nodes are configured in the DNS server for different SEPPs. Previously, users were configuring the FQDNs locally for each SEPP. This configuration also allows the operator to establish a backup/failover pair of a notify consumer or producer within DNS. In case of a notify or service request failure, SEPP can then choose this backup configuration for retry purposes.

The following is the format of SRV records defined at DNS server:

_Service._Proto.Name TTL Class SRV Priority Weight Port Target

_http._tcp.example.com 86400 IN SRV 1 10 80 blr.example.com

In this example, the virtual FQDN "example.com" returns the single FQDN record "blr.example.com" with priority 1 and weight 10.

Similarly, multiple records can be defined against the single virtual FQDN. Each FQDN returned can be resolved to multiple IP address in the DNS server.

Assumptions

• SEPP FQDN and Virtual FQDN should be mapped to a valid IP address or multiple IP addresses. SEPP FQDN is used for the N32c handshake procedure.
• The load sharing feature is only used for the N32F traffic at N32-egress-gateway.
• Remote SEPP Set cannot have multiple peers with different Virtual FQDNs.
• Only a single Remote SEPP from the multiple Remote SEPPs with the same virtual FQDNs needs to be associated with Remote SEPP Set.
• SEPPs sharing the same Virtual FQDN should belong to the same set of PLMNs.
• Deployment of Alternate Route Service is mandatory for using load sharing feature at both the Egress Gateways.
• Correct DNS configuration is up to the discretion of the user. It is possible that the SEPP may or may not have handshake established within its database.
• Selective routing to Remote SEPPs based on server header is currently not supported.

Detailed Description

The following diagram represents the load sharing among multiple Remote SEPP nodes feature:

Figure 3-26 Architecture

Oracle SEPP supports load sharing of incoming 5G traffic to multiple Remote SEPPs with the help of load sharing feature at Egress Gateway. Single virtual host is configured for all the Remote SEPPs that share the same PLMN ID list. Virtual Host is mapped to the Remote SEPPs' FQDN records, and each having its own priority and weight values. Egress Gateway retrieves the records from the DNS server and arranges them in the order of priority and weight. If the priorities of all the fetched records against the virtual host are same, then the requests are load-shared among the Remote SEPPs on the basis of weight value assigned to each record. If any of the peers are unavailable, then the load gets redistributed to the remaining peers based on their priority and weight factor. This redistribution depends on whether the error code received from the peer is correctly configured in the database.

Managing Load Sharing among Multiple Remote SEPP Nodes Feature

Enable

This section describes the procedure to enable the feature.

Prerequisites

The following are the prerequisites to enable and configure the feature:

Configure the following Helm parameters in the ocsepp_custom_values_<version>.yaml file.

dnsSrvEnabled: true
alternateRouteServiceEnable: true
dnsSrvFqdnSetting.enabled: false
dnsSrvFqdnSetting.pattern: "_{scheme}._tcp.{fqdn}."

Note:

Scheme must be always be "http".

The following parameter must be enabled at the nrf-client section under global parameters:

alternateRouteServiceEnable: true

For more information, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy Installation, Upgrade, and Fault Recovery Guide.

Enabling

You can enable the load sharing among multiple Remote SEPP nodes feature using the CNC Console or REST API by adding the Virtual Host parameter at the Remote SEPP Profile.

Note:

If the Virtual Host parameter is left blank, then the feature is disabled.

Remote SEPP (with virtual host configuration) must be associated with the Remote SEPP Set.

For more details about CNC Console Configurations, see Configuring SEPP using CNC Console section in the Oracle Communications Cloud Native Core, Security Edge Protection Proxy User Guide.

For more information about API path, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy REST Specification Guide.

Configure

You can configure the feature using REST API and CNC Console.

• Configure using REST API: Perform the feature configurations as described in the Remote SEPP REST API in Oracle Communications Cloud Native Core, Security Edge Protection Proxy REST Specification Guide.
• Configure using CNC Console: Perform the feature configurations as described in the Remote SEPP in the Configuring SEPP using CNC Console section.

Observe

Following are the feature specific metrics:

• oc_egressgateway_sbiRouting_http_responses_total

For more information about metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following:

1. Collect the logs and Troubleshooting Scenarios: For more information on how to collect logs and troubleshooting information, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

3.2.15 Separate Port Configurations for N32c and N32f on the Egress Routes

In some deployments, there is a need to have different service IPs and ports for n32c and n32f interfaces although the endpoint SEPP may have the same name. Separate ports for n32c and n32f interfaces provide the flexibility to configure different IP address or port for the n32c and n32f interfaces.

SEPP was previously configured to support a single port or connection for both the control plane interface (n23c) and the forwarding interface (n32f). The Egress Gateway was set up to establish the connection of n32c and n32f on the same port, making it challenging to segregate the traffic. This also prevented SEPP from initiating connections to Remote SEPPs that required a different address for the n32c and n32f interfaces.

To improve traffic segregation, the Egress Gateway is enhanced by configuring different ports for the n32c and n32f connections on both the Remote SEPP Set and its local configurations.

Design and Architecture

The following diagram represents the separate port configurations for n32c and n32f on the Egress routes feature:

Figure 3-27 Separate Port Configurations Design Diagram

As represented in the diagram, the n32 Egress Gateway in the Oracle SEPP is configured to use different IP addresses or ports for connecting on the n32c and n32f interfaces on the same Remote SEPP. The n32f configuration in the Remote SEPP profile initiates separate connections toward the forwarding pane and control pane of the Remote SEPP. The forwarding plane can have the distinct FQDN and port.

If the n32f configuration is not present, then it is assumed that the control plane and forwarding plane have the same FQDN, IP address, and port combination.

Managing Separate Port Configurations for N32c and N32f on the Egress Routes

Enable

This section describes the procedure to enable the feature.

You can enable separate port configurations for n32c and n32f on the egress routes feature using the CNC Console or REST API by adding the n32 configuration parameters at the Remote SEPP profile. The parameters are N32F FQDN, N32F IP Address, and N32F Port.

Note:

If the N32F FQDN, N32F IP Address, and N32F Port parameters are left blank, then the feature is disabled.

For more details about CNC Console Configurations, see Configuring SEPP using CNC Console section in the Oracle Communications Cloud Native Core, Security Edge Protection Proxy User Guide.

For more information about REST API path, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy REST Specification Guide.

Configure

You can configure the feature using REST API and CNC Console.

• Configure using REST API: Perform the feature configurations as described in the Remote SEPP REST API in Oracle Communications Cloud Native Core, Security Edge Protection Proxy REST Specification Guide.
• Configure using CNC Console: Perform the feature configurations as described in the Remote SEPP in the Configuring SEPP using CNC Console section.

Observe

For more information about metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following:

1. Collect the logs and troubleshooting scenarios: For more information on how to collect logs and troubleshooting information, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

3.2.16 Support for cnDBTier APIs in CNC Console

With the implementation of this feature, cnDBTier APIs are integrated into the CNC Console. SEPP users can view specific cnDBTier APIs such as checking the cnDBTier version, status of cnDBTier clusters, and georeplication status on the CNC Console.

The following cnDBTier APIs can be viewed (read only) from the CNC Console:

Table 3-16 Georeplication Recovery

Console Parameter	cnDBTier API name	Description	Supported cnDBTier Version
Update Cluster As Failed	http://<base-uri>/ocdbtier/markcluster/failed	This API is used to mark a cnDBTier cluster as failed.	24.2.x onwards
Start Georeplication Recovery	http://<base-uri>/ocdbtier/faultRecovery/start	This API is used to start the georeplication recovery.	24.2.x onwards
Georeplication Recovery Status	http://<base-uri>/ocdbtier/faultrecovery/status	This API is used to monitor the georeplication recovery status of FAILED and ACTIVE cnDBTier sites.	24.2.x onwards

Table 3-17 cnDBTier Health http://base-uri/{unique_prefix}/ocdbtier/health-info

Console Parameter	cnDBTier API name	Description	Supported cnDBTier Version
Backup Manager Health Status	http://base-uri/{unique_prefix}/ocdbtier/health-info/backup-mgr-svc/status	This is a read-only API. This API displays the health status of the backup manager service. It checks the following: if the backup manager service is up or not if the service can connect to database or not	24.1.x onwards
Monitor Health Status	http://base-uri/{unique_prefix}/ocdbtier/health-info/monitor-svc/status	This is a read-only API. This API displays the health status of the monitor service. It checks the following: if the monitor service is up or not if the service can connect to database or not if the metrics are fetched or not (the metrics are fetched when the service is up and vice versa)	24.1.x onwards
NDB Health Status	http://base-uri/{unique_prefix}/ocdbtier/health-info/ndb-svc/status	This is a read-only API. This API displays the health status of the network database. It checks the following: if the pod is connected to PVC or not if the pods status is up or not Note:PVC is not applicable to some of the pods.	24.1.x onwards
Replication Health Status	http://base-uri/{unique_prefix}/ocdbtier/health-info/replication-svc/status	This is a read-only API. This API displays the health status of the replication service. It checks the following: if the replication service is up or not if the service can connect to database or not	24.1.x onwards
cnDBTier Version	http://<base-uri>/ocdbtier/version	This is a read-only API. This API displays the cnDBTier version.	23.4.x onwards
Backup List	http://<base-uri>/ocdbtier/list/backups	This is a read-only API. This API displays the details of completed backups along with backup ID, backup creation timestamp, and backup size.	23.4.x onwards
Database Statistics Report	http://<base-uri>/ocdbtier/statistics/report/dbinfo	This is a read-only API. This API displays the number of available databases.	23.4.x onwards

Table 3-18 Geo Replication Status

Console Parameter	cnDBTier API name	Description	Supported cnDBTier Version
Real Time Overall Replication Status	http://<base-uri>/ocdbtier/status/replication/realtime	This is a read-only API. This API displays the overall replication status in multisite deployments. For example, in a four-site deployment, it provides the replication status between the following sites: site1-site2, site1-site3, site1-site4. This is applicable for all other sites, such as, site 2, site 3, and site 4.	23.4.x onwards
Site Specific Real Time Replication Status	http://<base-uri>/ocdbtier/status/replication/realtime/{remoteSiteName}	T This is a read-only API. his API displays the site-specific replication status.	23.4.x onwards
HeartBeat Status	http://<base-uri>/ocdbtier/heartbeat/status	This is a read-only API. This API displays the connectivity status between the local site and the remote site name to which SEPP is connected.	23.4.x onwards
Local Cluster Status	http://<base-uri>/db-tier/status/cluster/local/realtime	This is a read-only API. This API displays the status of the local cluster.	23.4.x onwards
On Demand Backup	http://<base-uri>/ocdbtier/on-demand/backup/initiate	This API can be edited to create a new backup. This API displays the status of initiated on-demand backups and helps to create a new backup.	23.4.x onwards

Table 3-19 Georeplication Recovery

Console Parameter	cnDBTier API name	Description	Supported cnDBTier Version
Update Cluster As Failed	http://<base-uri>/ocdbtier/markcluster/failed	This API is used to mark a cnDBTier cluster as failed.	24.2.x onwards
Start Georeplication Recovery	http://<base-uri>/ocdbtier/faultRecovery/start	This API is used to start the georeplication recovery.	24.2.x onwards
Georeplication Recovery Status	http://<base-uri>/ocdbtier/faultrecovery/status	This API is used to monitor the georeplication recovery status of FAILED and ACTIVE cnDBTier sites.	24.2.x onwards

Note:

This feature works when cnDBTier is configured as an instance during the CNC Console deployment. For more information about integrating cnDBTier APIs in CNC Console, see Oracle Communications Cloud Native Core, cnDBTier User Guide.

You can view the cnDBTier GUI in the CNC Console. For more information, see cnDBTier in the CNC Console.

Managing cnDBTier APIs in CNC Console

Enable

This feature is available by default, when cnDBTier is configured as an instance during the CNC Console deployment. For more information about integrating cnDBTier APIs in CNC Console, see the "NF Single Cluster Configuration With cnDBTier Menu Enabled" section in the Oracle Communications, Cloud Native Configuration Console Installation, Upgrade, and Fault Recovery Guide.

There is no option to disable this feature.

Configure

You can view the cnDBTier APIs in the CNC Console. For more information, see cnDBTier APIs in the CNC Console.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following:

1. Collect the logs and Troubleshooting Scenarios: For more information on how to collect logs and troubleshooting information, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

3.2.17 5G SBI Message Mediation Support

In the earlier releases, SEPP supports Mediation as an independent service to modify 5G Service Based Interface (SBI) message content, which includes HTTP2 header values and JSON message body, based on the user-defined mediation rule sets.

The message mediation feature at SEPP allows MNOs to resolve the inter-op issues between PLMNs by manipulating the inter PLMN messages. SEPP uses the mediation service to support message mediation. The MNO relies on mediation service capabilities to provide the mediation rules.

SEPP is enhanced to include mediation as a microservice, that applies user-configured message mediation rules to ingress 5G SBI messages to perform message mediation transformation. Mediation is a common microservice reused across Oracle NFs. The mediation feature allows user-defined business rules to filter or manipulate headers, Query Parameters and Body Parameters in SBI request and response messages. Mediation is invoked by CN32f and PN32f microservices when the request and response matches the configured trigger rules. Trigger Rule Configuration is managed by SEPP. Mediation Rule Configuration used by Mediation microservice is managed by Mediation microservice.

Mediation Representation with SEPP

Figure 3-28 Mediation Representation with SEPP

Managing Mediation

Enable

• To deploy this service, set the mediationService parameter to true in the global parameters section of the custom value file.

  Example:

  
  nf-mediation:
    # mediation Global configuration
    global:
      mediationService: true

  For more information about this parameter, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy Installation, Upgrade, and Fault Recovery Guide.

You can enable the feature using REST API and the CNC Console.

To enable the feature, set the Enable Mediation parameter to true in the Options screen under the Mediation section of the CNC Console GUI.

Following Configuration are required at SEPP to apply 5G SBI Message Mediation Support feature:

• Trigger Rule Configuration
• Mediation Rule Configuration

Trigger Rule Configuration

Mediation Trigger Rule List for SEPP

SEPP allows user to configure Trigger Rule List as a filtering criteria, based on which the mediation functionality is invoked. 5G SBI Message Mediation Support functionality can be applied on a Local SEPP and on a Remote SEPP Set, hence Trigger Rules can be configured for Local and Remote SEPP Set. That is, the user can apply mediation rule on a request going out or a response coming in for this particular local SEPP or the user can apply mediation rule on a request going out or a response coming in for this particular Remote SEPP Set. Every Trigger Rule List must contain a unique name.

SEPP also extends its functionality for the user to apply 5G SBI Message Mediation Support functionality on every request and response that is received on SEPP by selecting Match All option on the console.

Filtering Criteria for Message Mediation functionality to be invoked

SEPP allows user to configure Multiple Trigger Rules in Trigger Rule List which then includes Trigger Points, Resource URI, HTTP Method, and Group ID. In this Trigger Points, Resource URI, and HTTP Method are used as a filtering Condition by SEPP to select if a particular request needs Message Mediation functionality invocation or not. Here User is allowed to configure unique combination of Trigger points, Resource URI, and HTTP Method for every Trigger Rule in a Trigger Rule list.

Mediation Trigger Points for SEPP

SEPP supports the following mediation trigger points to invoke mediation service:

• Ingress inter-PLMN and core network messages
• Egress inter-PLMN messages

Hence, Trigger Point can be any of the following:

• N32 EGRESS REQUEST
• N32 INGRESS RESPONSE
• N32 INGRESS REQUEST
• N32 EGRESS RESPONSE

The Trigger Points are available only in the context of the N32 interface/traffic.

Resource URI

There are certain SBI messages which traverse through networks. On the basis of the default list of all the Inter PLMN SBI Messages, SEPP Message Mediation feature allows the user to configure only the allowed Inter PLMN SBI Messages. User is allowed to add any new Resource URI as per their requirement. To add any new Resource URI and HTTP Method, user can add the same in SEPP Service APIs section in CNC Console. Once an API is added, the same can be reflected under Resource URI of Trigger Rule.

HTTP Method

SEPP allows the user to configure the following predefined HTTP Methods for Message Mediation feature:

• POST
• PUT
• GET
• PATCH
• DELETE
• OPTIONS

Group ID

SEPP uses Group ID for which mediation configuration is to be done. This is passed to the Mediation Service for grouping similar rules. It is of type string.

Agenda Group Naming

User can combine mediation rules by using Agenda Group in the mediation rule definition.

Agenda group is the combination of Group id and Trigger Point (configured in Trigger Rule in Configuring SEPP using CNC Console).

Agenda group name in mediation rules should be <Group Id>-<triggerpoint> as shown in the following example:

agenda-group "AUSF-N32_Ingress_Request"

function String modifySupiOrSuci(String str) {
        String supiOrSuci = str.substring(0,15)+"0000"+str.substring(16);
        return supiOrSuci;
}
 
 
rule "Match SUPI_SUCI Modify"
    agenda-group "AUSF-N32_Ingress_Request"
when
    req : Request(body.has("$.supiOrSuci"))
then
    req.body.put("$","supiOrSuci",modifySupiOrSuci(req.body.get("$.supiOrSuci").toString()))
end 

User can refer the Mediation Service Rule Book in the Appendix to configure the Mediation Rules.

Examples of Use Cases supported by SEPP

• Incoming SUCI (Subscription Concealed Identifier) format modification and then using modified SUPI (Subscription Permanent Identifier) for selection:
  • Example: "supiOrSuci": "suci-0-310-260-0-0-0-173416067 is first modified to "supiOrSuci": "suci-0-310-260-0000-0-0-173416067
  • Example: "imei-9844312345123456" is modified to "imei-984431234512345"

• Validating SUCI for format and sending Custom error code
  • Example: "supiOrSuci": "suci-0-310-260-0-0-0-173416067 is checked and instead of 404 Not found, error sent to AMF is modified to 403 “invalid SUCI format”.

• When ingress request doesn't come in a supported scheme
  • Example: Visited Network works only with http, but home network requires https.

Only following combination are allowed to be configured in 5G SBI Message Mediation Support feature for local and Remote SEPP with Match All Configuration.

Table 3-20 Match All Configurations

Match ALL	Local/ Remote	Description
True	Local	This combination is used for applying mediation rules for all the inter PLMN SBI requests or responses for all the peer SEPPs.
True	Remote	This combination is used for applying mediation rules for all the inter PLMN SBI requests or responses for a particular peer SEPP for which trigger rule list is configured.
False	Local	This combination is used for applying mediation rules on selected (using Trigger points, Resource URI, and HTTP Method) inter PLMN SBI requests or responses for all the peer SEPPs.
False	Remote	This combination is used for applying mediation rules on selected (using Trigger points, Resource URI, and HTTP Method) inter PLMN SBI requests or responses for a particular peer SEPP for which trigger rule list is configured.

Configuring Trigger Rule List in Remote SEPP Set

Once a Trigger Rule list is created with Trigger Rules, user is allowed to associate a Trigger Rule List with the Configured Remote SEPP Sets.

User can select the Remote SEPP Set screen on CNC Console and can select Trigger Rule List under Trigger Rule List Name field.

Note:

The user can associate a Trigger Rule list created exclusively for the Remote SEPP Set but is not permitted to associate a Trigger Rule list created for a Local SEPP with the Remote SEPP Set.

Error Configuration

Error action (Reject or Continue) with status code and title is configurable and used for error response. When an error response is received from Mediation microservice the configured error action by user is applied on message.

User is allowed to configure Error action with status code and title to be used with Errors. When an error response is received from the Mediation microservice, the configured error action is applied on message.

Error Action can be:

• Continue: SEPP persists in processing the message, even if an error response is received from the Mediation microservice.
• Reject: SEPP will decline the message and provide a user-configured status code and title.

Mediation Rule Configuration

You can configure the Mediation rules either using config map, or using REST API and CNC Console.

Configuring Mediation Rules using ConfigMap

The following are the steps to configure the rules:

1. Download the configMap into a file using the following command:

    kubectl get configmap ocsepp-release-nf-mediation-config-active -n sepp-med3 -oyaml > rule_configmap.txt

2. At the end of the file rule_configmap.txt , append the below data block along with needed rules:

   data:
     rule.drl: |
       package com.oracle.cgbu.ocmediation.nfmediation;
     
       import com.oracle.cgbu.ocmediation.nfruleengine.NFDroolsRuleEngine;
       import com.oracle.cgbu.ocmediation.factdetails.Request;
       import com.oracle.cgbu.ocmediation.factdetails.Response;
       import java.util.Map;
       import java.util.HashMap;
     
       dialect "mvel"
         
       //rules

   Example of updated file:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     annotations:
       meta.helm.sh/release-name: ocsepp-release
       meta.helm.sh/release-namespace: sepp-med3
     creationTimestamp: "2022-08-21T09:37:03Z"
     labels:
       app.kubernetes.io/managed-by: Helm
     name: ocsepp-release-nf-mediation-config-active
     namespace: sepp-med3
     resourceVersion: "15059111"
     uid: 10baf42f-3582-49a7-8cd1-7228357c9a54
   data:
     rule.drl: |
       package com.oracle.cgbu.ocmediation.nfmediation;
     
       import com.oracle.cgbu.ocmediation.nfruleengine.NFDroolsRuleEngine;
       import com.oracle.cgbu.ocmediation.factdetails.Request;
       import com.oracle.cgbu.ocmediation.factdetails.Response;
       import java.util.Map;
       import java.util.HashMap;
     
       dialect "mvel"
     
       rule "Rule_show_add_header"
       when
          req : Request(headers.has("3gpp-Sbi-Message-Priority") == true)
       then
          req.headers.add("3gpp-Sbi-Message-Priority","10")
          req.headers.del("x-test-req-header1")
       end
     
       rule "Rule_Request_body_add_delete"
       when
          req : Request(headers.has("x-forwarded-NF","NRF"))
       then
          req.body.put("$","nfId","ccc5ccbb-5bb9-465f-9ace-0faf08cb4223")
          req.body.del("$.supiOrSuci")
       end

3. Run the following command to update the configmap with the updated rules:

   kubectl replace ocsepp-release-nf-mediation-config-active -n sepp-med3 -f rule_configmap.txt

   Note:

   • If rules changed on nf active mediation then use "$releaseName-nf-mediation-config-active" as the name of the configmap.
   • It is recommended to maintain the back up of the rules as it can lead to rule loss if the config map deleted.

Mediation Rules using CNC Console and Rest APIs

The above process of creating mediation rules in mediation-nf using a configmap with Kubernetes has several limitations, such as configuring the code to create and update the mediation rules using a configmap, whose size is limited to 1 MB.

With this feature enhancement in release 23.4.0, mediation rules are being stored in the database, these rules can be retrieved, modified, deleted, new rules can be added and applied to mediation microservice using the CNC Console or REST API, leveraging improved database storage capacitiy.

The following are the user configurable Mediation Rules Parameters:

• Rule Name: Unique mediation rule name for identification.
• Status: APPLIED or DRAFT. New mediation rule(s) are always created and stored with DRAFT status into the database. Once the rules are saved again using Apply state, they will be applied to the mediation microservice and the status will be APPLIED.
• State: Possible rule state values are Save, Compile, Apply, Clone, and Draft. New rule(s) are always created using Save state. Once created, user can select the other states.
• Mediation Mode: Possible values of mode are MEIDATION_ACTIVE and MEIDATION_TEST. The user is required to configure the mediation rules using MEDIATION_ACTIVE mediation mode. MEDIATION_TEST mode is only for internal purpose.
  • MEIDATION_ACTIVE: It is applicable only to mediation microservice active mode.
  • MEDIATION_TEST: It is applicable only to mediation microservice test mode.

• Code: Mediation rule code. The user needs to perpend the following data block along with the needed rules. User will be restricted to apply a rule that is having any compilation or syntax error in it. Any special character in code results in a rule compilation error.

    package com.oracle.cgbu.ocmediation.nfmediation;
   
    import com.oracle.cgbu.ocmediation.nfruleengine.NFDroolsRuleEngine;
    import com.oracle.cgbu.ocmediation.factdetails.Request;
    import com.oracle.cgbu.ocmediation.factdetails.Response;
    import java.util.Map;
    import java.util.HashMap;
   
    dialect "mvel"
       
    //rules

• Format: Rule format. Only DRL is supported currently.
• New Rule Name: New mediation rule name is to be given only when an existing rule is cloned using Clone state.

The following diagram represents the rule state and status flow:

Figure 3-29 Rule Status Flow

Mediation Rules States for DRAFT status rules

• Save: It saves an existing rule into the database.
• Compile: It only compiles the rule and saves it again into the data base.
• Clone: It works same as "save as". That is, saves an existing rule with a new given name into the database.
• Apply: It compiles the rule, saves it again in APPLIED status into the database, and applies the rule to mediation microservice.
• Draft: Its not supported as rule status is already DRAFT.

Mediation Rule States for APPLIED status rules

• Save: It applies the rule with changed mediation mode to the mediation microservice. While using this state, user can only change the rule mode, that is, MEDIATION_ACTIVE to MEDIATION_TEST and vice versa. Modification in rules code is not allowed.
• Compile: Its not allowed as rule had been already compiled while applying it earlier.
• Clone: It works same as "save as", that is, saves an existing rule with a new given name into the database in DRAFT status.
• Apply: Its not allowed as rule is already in APPLIED status.
• Draft: It removes the APPLIED rule from mediation microservice, and saves again the rule in database in DRAFT status. While using this state, any change in the rule code is not allowed. Any code changes can be done once the rule status has been successfully changed to DRAFT status.

Note:

1. In SEPP release 23.4.0, the user is recommented to configure the mediation rules using CNC Console or REST APIs. However, configuring the mediation rules using config map is still supported and might be removed in the future releases.
2. The mediationConfig.ruleApi.enabled helm flag is used to enable or disable the CNC Console or REST API based rules configurations feature implementation. If the flag value is true, mediation microservice uses the rules from the database configured using CNC Console or REST APIs. If the flag value is false, mediation microservice uses the rules configured in the config map. The default value of the flag is true.
3. If an upgrade is performed from earlier SEPP releases to 23.4.0 release, the earlier releases' mediation rules that are available in the config map will be copied into the database table in APPLIED state and that can be viewed, modified, or deleted using CNC console or REST APIs in 23.4.0 release.
4. After an upgrade, if a rollback is performed from SEPP release 23.4.0 to earlier releases, the config map will have the same rules that were present before the upgrade.

For more information on creating mediation rules using CNC Console or REST API, see the Mediation Rules Configuration or Cloud Native Core, Security Edge Protection Proxy REST Specification Guide.

Custom Headers

Custom headers can be used if the user want to apply any mediation ruels on the service request message headers. The following are the custom headers supported by the mediation service.

Table 3-21 Custom Headers

CustomHeader	Original Message Header
x-original-method	":method"
x-original-scheme	":scheme"
x-original-authority	":authority"
x-original-path	URI of original message
x-original-status	":status"
x-message-type	value can be "request" or "response" Default value :"request"

Note:

In case of invalid http status code configured in x-original-status header in Mediation rule, the original status code will be returned from SEPP response.

Mediation Header

In cn32f and pn32f section, user can set mediation Request timeout time. N32f service wait for mediation svc response for mediationRequestTimeout time before sending the error message, if mediation service is unreachable.

In mediation rules,user can reject any incoming request. To reject request, user has to add some headers in mediation response which helps n32f services in making the decision. Two header Parameters are user configurable for this purpose.

• mediationRequestRejectStatusCodeHeaderName: The name of the header added in response to depict that n32f service has to reject this request and the value of this header indicates the error code to be returned.
• mediationRequestRejectReasonHeaderName: The name of the header added in response to depict that n32f service has to reject this request and the value of this header indicates the error reason to be returned.

  Example:

  mediation:
     mediationRequestTimeout: 900
     header:
       mediationRequestRejectStatusCodeHeaderName: "ocsepp-reject-status"
       mediationRequestRejectReasonHeaderName: "ocsepp-reject-reason"

Note:

SEPP mediation service does not support multipart messages.

Observe

For more information the Metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following:

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

3.2.18 Topology Hiding

Oracle Communications Security Edge Protection Proxy (SEPP) is a proxy network function (NF) which is used for secured communication between inter-Public Land Mobile Network (PLMN) messages. SEPP provides message filtering and policing on inter-PLMN control plane interfaces and topology hiding.

Topology hiding is a security feature in 5G that secures the address of the network elements and can prevent the attacks intended for unauthorized access to network element or interruption of the network service. The purpose of the feature is to enable topology hiding of information from the home or visited PLMN to the visited or Home PLMN. Topology Hiding conceals identity information from all messages leaving a PLMN.

Design and Architecture

The following diagram represents the detailed architecture of the Topology Hiding feature.

Figure 3-30 Topology Hiding Architecture

If the Topology Hiding feature is enabled, based on the header, body, and path table configuration named as header, topology_body, and topology_path respectively, either the message will be masked with the hidden value ( if the operation is Topology Hiding (TH) ) or the message will be represented by the actual value ( if the operation is Topology Recovery (TUH)), where the hidden value is mapped to the actual value.

Hidden traffic: The traffic is marked as hidden traffic, if the message (header,body, and path) is masked with the hidden value (operation is TH) or the message is represented by the actual value (operation is TUH).

Clear traffic: The traffic is marked as clear traffic, if the request or response does not have any of the header, body, and path configurations mentioned in the header, body, or path configuration table.

Note:

Topology Hiding is applicable only to N32f and not to N32c.

Note:

Only FQDN, NF_INSTANCE_ID, and NF_SERVICE_INSTANCE_ID format values are supported and they can be updated or modified for hiding or recovery in the message header, body, and path identifiers.

Actual to Pseudo Mapping

User can perform actual to pseudo mapping through CNC Console GUI. While configuring the pseud values, user has to add the specific unique prefix and suffix to make pseudo names globally unique. This is necessary to make topology hiding functionality efficient.

Figure 3-31 Actual to Pseudo Mapping

The actual values and pseudo values are mapped and stored in the actual_values and pseudo_values tables.

The Helm parameter, maxPseudoValue is by default set to 7. This parameter defines the maximum number of pseudo values that can be associated with a single actual value in the system.

Pseudo Value Mapping Rules

The following are the pseudo value mapping rules:

• For each actual value, the user can configure a minimum of 1 and a maximum of 7 pseudo values.
• If an actual value needs to be hidden, one of the configured pseudo values is selected randomly for hiding or recovery.
• The mapping between actual and pseudo values is used during the TH (Topology Hiding) and TUH (Topology Recovery) operations.
• These operations rely on the configured actual-to-pseudo mappings to determine the appropriate substitution.

Constraints

The following are the constraints:

• A pseudo value must be unique across all actual values, that is, the same pseudo value cannot be reused for multiple actual values.
• An actual value cannot be used for any pseudo value.
• Duplicate pseudo values for the same actual value are also not allowed.

Supported Actual Value Types

The following actual value types are currently supported for mapping:

• FQDN (Fully Qualified Domain Name)
• NF_INSTANCE_ID (Network Function Instance ID)
• NF_SERVICE_INSTANCE_ID (Network Function Service Instance ID)

Header, Body, and Path Configurations

Header, body, and Path configuration tables contain the information that is used for Topology hiding and recovery. The four types of configured traffic are:

• Egress Request
• Egress Response
• Ingress Request
• Ingress Response

Ingress response has a clear traffic, as any messages for TH or TUH are not defined in the ingress response.

Note:

In Topology Hiding feature, each request and response are considered as separate operations. Each header, body identifiers, and path identifiers cannot be related to each other in any of the operations. Both request (Ingress/Egress) and response (Ingress/Egress) should be treated as separate isolated transactions.

The following is the default header configuration that is available to the user:

Table 3-22 Topology Hiding Header Configurations

Header Name	Regular Expression	Trigger Point	Operation
via	(?<=SCP-).*	Request Egress	Topology Hiding
via	(?<=SCP-).*	Response Egress	Topology Hiding
location	(?<=http://|https://)[^:/?]+	Response Egress	Topology Hiding
server	(?<=SCP-|UDM-)([^ ]*)	Response Egress	Topology Hiding
3gpp-sbi-target-apiroot	(?<=http://|https://)[^:/?]+	Request Ingress	Topology Recovery
3gpp-sbi-routing-binding	(?<=nfinst=|nfservinst=|backupamfinst=|backupnf=)([^;]+)	Request Ingress	Topology Recovery
3gpp-sbi-binding	(?<=nfinst=|nfservinst=|backupamfinst=|backupnf=)([^;]+)	Request Egress	Topology Hiding
3gpp-sbi-binding	(?<=nfinst=|nfservinst=|backupamfinst=|backupnf=)([^;]+)	Response Egress	Topology Hiding

Note:

The user must configure the actual to pseudo mappings for the all the headers mentioned in the above table. The above mentioned are the default header configuration that is added by default and user must configure the actual to pseudo mappings for the all the headers mentioned in the above table.

Messages passing through the system check all the above configured conditions. The direction and the message type for the header configured in the table are validated and perform the TH or TUH based on the operation configured in the table.

When the incoming message or outgoing message has the header that is eligible for performing TH/TUH, the actual or pseudo value of that specific header is extracted and compared it with the actual to pseudo mapping. Once the mapping operation to be performed is identified, if it is TH, the actual value is masked from the pseudo mapping and if it is TUH, recover the pseudo value with the actual value received from mapping.

Query Parameters

When making a request, the request URL may include query parameters. These parameters can be of types such as FQDN, NF_INSTANCE_ID, or NF_SERVICE_INSTANCE_ID, and should be eligible for TH/ TUH operations. To support TH/TUH operations on query parameters, the system allows users to configure query parameters in header table only. Query parameters are part of the URL, the header mechanism treats them as headers internally, enabling consistent handling across different parts of the message. Users can define a query parameter entry in the header table with the following configuration:

• Header Name: Logical name used to refer the query parameter.
• Direction: Specifies the message flow (Example: Ingress or Egress).
• Regular Expression: To extract the value from the URL.
• MessageType: Type of message.
• Operations: TH, TUH

Note:

If the key is added as header in the header table, then every request will be processed for these keys as header (if available in request). Configuration done at header table configuration is applicable for all request and response.

Note:

User must do the actual to pseudo mapping, else hiding and recovery operations fails.

Example:

curl -v --http2-prior-knowledge 'http://127.0.0.1:9090/nnrf-disc/v1/nf-instances?service-names=nausf-auth&target-nf-type=AUSF&requester-nf-type=NRF&target-plmn-list=%5B%7B%22mcc%22%3A%22310%22%2C%20%22mnc%22%3A%22300%22%7D%5D&requester-plmn-list=%5B%7B%22mcc%22%3A%22310%22%2C%22mnc%22%3A%22310%22%7D%2C%7B%22mcc%22%3A%22311%22%2C%22mnc%22%3A%22490%22%7D%5D&routing-indicator=0000&requester-nf-instance-fqdn=https://pseudo.mnc330.mcc310.BE4NRF06.rs.nokia.com:9090' -H 'Content-Type: application/json' -H 'x-forwarded-host:ausf.default.mnc444.mcc444.3pnetwork.org' -H 'x-forwarded-port:8080' -H '3gpp-sbi-target-apiroot: http://ausf.default.mnc444.mcc444.3pnetwork.org'

In the above request if the user wants to hide or recover the requester -nf-instance-fqdn, then this parameter can be added as a header in the header table configuration and based on that hiding or recovery performed.

For the above example, the Header table will be as follows:

Table 3-23 Example of Header Table

Header Name	Regular Expression	Trigger Point	Operation
requester-nf-instance-fqdn	((?<=http://|https://)[^:/?]+)	Request Egress	Topology Hiding

Topology Hiding Body Configurations

When the request or response message is passing through the system then the request body or response body is processed and its identifiers are hidden or unhidden based on the rules defined in the topology body table.

Every message passing through the system is having a unique apiUrl. Based on that rules for TH/TUH are defined. For every apiUrl, there are a list of identifiers that can be part of request or response based on that user can define the identifiers eligible for TH/TUH. User can configure like what operation needs to be performed when that body is processed.

Table 3-24 Example Body Configurations

Method	API Response	Identifier	Regular Expression	Trigger Point	Operation
POST	/nnrf-nfm/v1/subscriptions	reqNfInstanceId	^[0-9A-Fa-f]{8}-[0-9A-Fa-f]{4}-4[0-9A-Fa-f]{3}-[0-9A-Fa-f]{4}-[0-9A-Fa-f]{12}$	N32_Egress_Request	Topology Hiding
POST	/nnrf-nfm/v1/subscriptions	nfStatusNotificationUri	(?<=http://|https://)[^:/?]+	N32_Egress_Request	Topology Hiding
POST	/nnrf-nfm/v1/subscriptions	reqNfFqdn	^(?!://)(?=.{1,255}$)((.{1,63}.){1,127}(?![0-9]*$)[a-z0-9-]?)	N32_Egress_Request	Topology Hiding
POST	/nnrf-nfm/v1/subscriptions	reqNfInstanceId	^[0-9A-Fa-f]{8}-[0-9A-Fa-f]{4}-4[0-9A-Fa-f]{3}-[0-9A-Fa-f]{4}-[0-9A-Fa-f]{12}$	N32_Ingress_Response	Topology Recovery
POST	/nnrf-nfm/v1/subscriptions	nfStatusNotificationUri	(?<=http://|https://)[^:/?]+	N32_Ingress_Response	Topology Recovery
POST	/nnrf-nfm/v1/subscriptions	reqNfFqdn	^(?!://)(?=.{1,255}$)((.{1,63}.){1,127}(?![0-9]*$)[a-z0-9-]?)	N32_Ingress_Response	Topology Recovery
POST	/nnrf-nfm/v1/subscriptions	hnrfUri	(?<=http://|https://)[^:/?]+	N32_Ingress_Request	Topology Recovery
POST	/nnrf-nfm/v1/subscriptions	hnrfUri	(?<=http://|https://)[^:/?]+	N32_Egress_Response	Topology Hiding

If the same apiUrl having more than one identifiers then the separate rows of each identifiers must be in the database. One row always corresponds to single identifier configuration. If in case user enters the wrong or inappropriate configuration for any identifier then that particular configuration needs to be deleted and reenter back into the system

Note:

If the user wants to add the apiUrl and that is not present in the default table, exception or error occurs. Ensure to add the default configuration before configuring topology body.

Note:

The actual to pseudo mapping should be done as mentioned in the above mentioned table. All the configuration related to actual pseudo mapping should apply in the same way.

Topology Hiding Path Configurations

As messages (requests or responses) pass through the system, their paths are evaluated using regular expressions configured in the topology path table. These expressions are used to extract specific values from the request or response, which can then be hidden (TH) or recover (TUH) based on the predefined rules. Each message is uniquely identified by an API URL, which acts as the basis for determining the applicable TH/TUH rules. For every API URL, corresponding regular expressions are configured to target relevant parts of the request or response payload. Customers can define which operation (TH/TUH) should be applied when a specific path is processed. This flexible configuration allows better control over data visibility as messages traverse the system.

Table 3-25 Example Path Configurations

Method	API Response	Regular Expression	Trigger Point	Operation
POST	/nnrf-nfm/v1/subscriptions	^[0-9A-Fa-f]{8}-[0-9A-Fa-f]{4}-4[0-9A-Fa-f]{3}-[0-9A-Fa-f]{4}-[0-9A-Fa-f]{12}$	N32_Egress_Request	Topology Hiding
POST	/nnrf-nfm/v1/subscriptions	(?<=http://|https://)[^:/?]+	N32_Egress_Request	Topology Hiding

Example for Topology Path:

curl --noproxy "*" --http2-prior-knowledge -X GET -H '3gpp-sbi-target-apiRoot: http://pseudo-perfgo-mnc100-mcc111-3gppnetwork-org.user-sepp2:9814' -H "Content-type: application/json" 'http://ocsepp-release-user-plmn-ingress-gateway:80/npcf-ue-policy-control/v1/policies/54804518-4191-46b3-955c-ac631f953ed8?service-names=nnrf-disc&target-nf-type=NRF&req-nf-type=NRF&target-plmn-list=%5B%7B%22mcc%22%3A%22310%22%2C%20%22mnc%22%3A%22300%22%7D%5D&requester-plmn-list=%5B%7B%22mcc%22%3A%22310%22%2C%22mnc%22%3A%22310%22%7D%2C%7B%22mcc%22%3A%22311%22%2C%22mnc%22%3A%22490%22%7D%5D&routing-indicator=0000&req-nf-instance-id=44804518-4191-46b3-955c-ac631f953ed8&nrf-disc-uri=http://nrf.5gc.mnc222.mcc333.3gppnetwork.org:80/nnrf-disc/v1/nf-instances&req-nf-instance-fqdn=https://nrf.5gc.mnc330.mcc310.BE4NRF06.rs.oracle.com:7070'

In the above request, if the user wants to hide 54804518-4191-46b3-955c-ac631f953ed8 value present in the path which is in valid format ( NF_INSTANCE_ID), then the path configuration for this URI is required in the path table and based on that, hiding or recovery will be performed along with actual-pseudo configuration.

Example for Topology Body:

Consider the message request body going out from the system from CN32F (Ingress response) and having the apiUrl as /namf-evts/v1/subscriptions and containing eventNotifyUri identifier as http://udm1.5gc.mnc340.mcc313.3gppnetwork.org:8080/eventNotify and api method is of type POST. In this case, topology body table has the identifier eventNotifyUri configured for INGRESS RESPONSE as operation TH. This table checks the apiUrl which is actually called exists as a configuration in the table. Also, this method should be POST, so extract the eventNotifyUri from this message and consider this for TH.

Then look up the actual to pseudo mappings and try to find actual value as udm1.5gc.mnc340.mcc313.3gppnetwork.org and retrieve all the possible pseudo values associated with it. Once seven pseudo values against this actual value are identified, the system randomly select any one value and mask eventNotifyUri with pseudo value like eventNotifyUri: http://pseudo.default.mnc444.mcc444.3pnetwork.org:8080/eventNotify.

Figure 3-32 Example for Hiding the message

In the example via header is configured as hidden in the header table configuration and also eventNotifyUri as Body identifier for resource URI /namf-evts/v1/subscriptions in topology body configuration for the POST response. For the Egress Request message, via header is passed as actual value and eventNotifyUri as body identifier is passed as actual value. Since we have configured that TH operation should be performed therefore as per the actual/pseudo mapping mapped, TH should happen and actual values should convert into pseudo value. In the below example, it explains how we look up the database and convert the actual to pseudo value.

Example of Recovery

Consider the message request body going out from the system from CN32F (Egress Request) and having the apiUrl as /namf-evts/v1/subscriptions and containing eventNotifyUri identifier as http://pseudo.default.mnc444.mcc444.3pnetwork.org:8080/eventNotify and api method is of type POST. In this case, topology body table has the identifier eventNotifyUri configured for EGRESS REQUEST as operation TUH further this table checks that apiUrl which is actually called exists as a configuration in the table. Also, this method should be POST, so extract the eventNotifyUri from this message and consider this for TUH.

Look up the actual to pseudo mappings and find pseudo value as pseudo.default.mnc444.mcc444.3pnetwork.org and retrieve the actual value associated with it. System replaces the pseudo value with actual value udm1.5gc.mnc340.mcc313.3gppnetwork.org

Figure 3-33 Example of Recovery

In the example, 3gpp-sbi-target-apiroot header is configured as recovered in the header table configuration and also eventNotifyUri as Body identifier for resource URI /namf-evts/v1/subscriptions in topology body configuration for the POST request. For the Ingress Request message, 3gpp-sbi-target-apiroot header is passed as pseudo value and eventNotifyUri as body identifier is passed as pseudo value. Since we have configured that TUH operation should be performed therefore as per the actual/pseudo mapping mapped, TUH should happen and psuedo values should convert into actual value. In the below example, it explains how we look up the database and convert the pseudo to actual value.

Default Configuration

The following is the default table that have all the resource URIs supported by the SEPP.

Table 3-26 Default Configuration

id	resourceURI	method	regex
1	/nudm-sdm/v2/{supi}	GET	^/nudm-sdm/v2/(imsi-[0-9]{5,15}|nai-.+|gci-.+|gli-.+|.+)/?$
2	/nausf-auth/v1/ue-authentications/{authCtxId}/5g-aka-confirmation	PUT	^/nausf-auth/v1/ue-authentications/([0-9a-zA-Z-]+|.+)/5g-aka-confirmation/?$
3	/nudm-sdm/v2/{ueId}/sdm-subscriptions	POST	^/nudm-sdm/v2/(imsi-[0-9]{5,15}|nai-.+|msisdn-[0-9]{5,15}|extid-[^@]+@[^@]+|gci-.+|gli-.+|.+)/sdm-subscriptions/?$
4	/oauth2/token	POST	^/oauth2/token/?$
5	/nsmf-pdusession/v1/pdu-sessions/{pduSessionRef}/transfer-mo-data	POST	^/nsmf-pdusession/v1/pdu-sessions/([0-9a-zA-Z-]+|.+)/transfer-mo-data/?$
6	/nudm-sdm/v2/{supi}/smf-select-data	GET	^/nudm-sdm/v2/(imsi-[0-9]{5,15}|nai-.+|gci-.+|gli-.+|.+)/smf-select-data/?$
7	/nnrf-nfm/v1/subscriptions	POST	^/nnrf-nfm/v1/subscriptions/?$
8	/nudm-uecm/v1/{ueId}/registrations/smsf-3gpp-access	GET	^/nudm-uecm/v1/(imsi-[0-9]{5,15}|nai-.+|msisdn-[0-9]{5,15}|extid-[^@]+@[^@]+|gci-.+|gli-.+|.+)/registrations/smsf-3gpp-access/?$
9	/nudm-sdm/v2/{supi}/sms-mng-data	GET	^/nudm-sdm/v2/(imsi-[0-9]{5,15}|nai-.+|gci-.+|gli-.+|.+)/sms-mng-data/?$
10	/nudm-sdm/v2/{supi}/sm-data	GET	^/nudm-sdm/v2/(imsi-[0-9]{5,15}|nai-.+|gci-.+|gli-.+|.+)/sm-data/?$
11	/namf-mt/v1/ue-contexts/{ueContextId}	GET	^/namf-mt/v1/ue-contexts/(imsi-[0-9]{5,15}|nai-.+|gli-.+|gci-.+|.+)/?$
12	/namf-evts/v1/subscriptions/{subscriptionId}	DELETE	^/namf-evts/v1/subscriptions/(([0-9]{5,6}-)?[^-]+)/?$
13	/namf-evts/v1/subscriptions/{subscriptionId}	PATCH	^/namf-evts/v1/subscriptions/(([0-9]{5,6}-)?[^-]+)/?$
14	/namf-evts/v1/subscriptions	POST	^/namf-evts/v1/subscriptions/?$
15	/nudm-sdm/v2/{supi}/am-data/sor-ack	PUT	^/nudm-sdm/v2/(imsi-[0-9]{5,15}|nai-.+|gci-.+|gli-.+|.+)/am-data/sor-ack/?$
16	/nudm-uecm/v1/{ueId}/registrations/amf-3gpp-access	PUT	^/nudm-uecm/v1/(imsi-[0-9]{5,15}|nai-.+|msisdn-[0-9]{5,15}|extid-[^@]+@[^@]+|gci-.+|gli-.+|.+)/registrations/amf-3gpp-access/?$
17	/namf-loc/v1/{ueContextId}/provide-loc-info	POST	^/namf-loc/v1/(imsi-[0-9]{5,15}|nai-.+|gli-.+|gci-.+|imei-[0-9]{15}|imeisv-[0-9]{16}|.+)/provide-loc-info/?$
18	/nausf-auth/v1/ue-authentications/{authCtxId}/5g-aka-confirmation	POST	^/nausf-auth/v1/ue-authentications/([0-9a-zA-Z-]+|.+)/5g-aka-confirmation/?$
19	/nsmf-pdusession/v1/pdu-sessions/{pduSessionRef}/transfer-mt-data	POST	^/nsmf-pdusession/v1/pdu-sessions/([0-9a-zA-Z-]+|.+)/transfer-mt-data/?$
20	/nudm-sdm/v2/{ueId}/sdm-subscriptions/{subscriptionId}	PATCH	^/nudm-sdm/v2/(imsi-[0-9]{5,15}|nai-.+|msisdn-[0-9]{5,15}|extid-[^@]+@[^@]+|gci-.+|gli-.+|.+)/sdm-subscriptions/(([0-9]{5,6}-)?[^-]+)/?$
21	/nudm-sdm/v2/{supi}/sms-data	GET	^/nudm-sdm/v2/(imsi-[0-9]{5,15}|nai-.+|gci-.+|gli-.+|.+)/sms-data/?$
22	/namf-comm/v1/subscriptions/{subscriptionId}	DELETE	^/namf-comm/v1/subscriptions/(([0-9]{5,6}-)?[^-]+)/?$
23	/nnssf-nsselection/v2/network-slice-information	GET	^/nnssf-nsselection/v2/network-slice-information/?$
24	/nudm-uecm/v1/{ueId}/registrations/amf-3gpp-access	GET	^/nudm-uecm/v1/(imsi-[0-9]{5,15}|nai-.+|msisdn-[0-9]{5,15}|extid-[^@]+@[^@]+|gci-.+|gli-.+|.+)/registrations/amf-3gpp-access/?$
25	/nudm-uecm/v1/{ueId}/registrations/smsf-3gpp-access	DELETE	^/nudm-uecm/v1/(imsi-[0-9]{5,15}|nai-.+|msisdn-[0-9]{5,15}|extid-[^@]+@[^@]+|gci-.+|gli-.+|.+)/registrations/smsf-3gpp-access/?$
26	/nsmf-pdusession/v1/pdu-sessions/{pduSessionRef}/modify	POST	^/nsmf-pdusession/v1/pdu-sessions/([0-9a-zA-Z-]+|.+)/modify/?$
27	/nnrf-nfm/v1/subscriptions/{subscriptionID}	PATCH	^/nnrf-nfm/v1/subscriptions/(([0-9]{5,6}-)?[^-]+)/?$
28	/nudm-sdm/v2/shared-data	GET	^/nudm-sdm/v2/shared-data/?$
29	/npcf-ue-policy-control/v1/policies	POST	^/npcf-ue-policy-control/v1/policies/?$
30	/nnrf-disc/v1/nf-instances	GET	^/nnrf-disc/v1/nf-instances/?$
31	/nudm-sdm/v2/{supi}/am-data/upu-ack	PUT	^/nudm-sdm/v2/(imsi-[0-9]{5,15}|nai-.+|gci-.+|gli-.+|.+)/am-data/upu-ack/?$
32	/npcf-ue-policy-control/v1/policies/{polAssoId}	GET	^/npcf-ue-policy-control/v1/policies/([0-9a-zA-Z-]+|.+)/?$
33	/nudm-sdm/v2/{ueId}/sdm-subscriptions/{subscriptionId}	DELETE	^/nudm-sdm/v2/(imsi-[0-9]{5,15}|nai-.+|msisdn-[0-9]{5,15}|extid-[^@]+@[^@]+|gci-.+|gli-.+|.+)/sdm-subscriptions/(([0-9]{5,6}-)?[^-]+)/?$
34	/nudm-sdm/v2/{supi}/am-data	GET	^/nudm-sdm/v2/(imsi-[0-9]{5,15}|nai-.+|gci-.+|gli-.+|.+)/am-data/?$
35	/nudm-uecm/v1/{ueId}/registrations/smsf-non-3gpp-access	GET	^/nudm-uecm/v1/(imsi-[0-9]{5,15}|nai-.+|msisdn-[0-9]{5,15}|extid-[^@]+@[^@]+|gci-.+|gli-.+|.+)/registrations/smsf-non-3gpp-access/?$
36	/nnrf-nfm/v1/subscriptions/{subscriptionID}	DELETE	^/nnrf-nfm/v1/subscriptions/(([0-9]{5,6}-)?[^-]+)/?$
37	/nudm-uecm/v1/{ueId}/registrations/amf-non-3gpp-access	GET	^/nudm-uecm/v1/(imsi-[0-9]{5,15}|nai-.+|msisdn-[0-9]{5,15}|extid-[^@]+@[^@]+|gci-.+|gli-.+|.+)/registrations/amf-non-3gpp-access/?$
38	/nudm-uecm/v1/{ueId}/registrations/amf-non-3gpp-access	PUT	^/nudm-uecm/v1/(imsi-[0-9]{5,15}|nai-.+|msisdn-[0-9]{5,15}|extid-[^@]+@[^@]+|gci-.+|gli-.+|.+)/registrations/amf-non-3gpp-access/?$
39	/nudm-uecm/v1/{ueId}/registrations/smsf-non-3gpp-access	PUT	^/nudm-uecm/v1/(imsi-[0-9]{5,15}|nai-.+|msisdn-[0-9]{5,15}|extid-[^@]+@[^@]+|gci-.+|gli-.+|.+)/registrations/smsf-non-3gpp-access/?$
40	/namf-comm/v1/subscriptions/{subscriptionId}	PUT	^/namf-comm/v1/subscriptions/(([0-9]{5,6}-)?[^-]+)/?$
41	/namf-comm/v1/subscriptions	POST	^/namf-comm/v1/subscriptions/?$
42	/nausf-auth/v1/ue-authentications	POST	^/nausf-auth/v1/ue-authentications/?$
43	/nausf-auth/v1/ue-authentications/{authCtxId}/5g-aka-confirmation	DELETE	^/nausf-auth/v1/ue-authentications/([0-9a-zA-Z-]+|.+)/5g-aka-confirmation/?$
44	/nudm-sdm/v2/{supi}/nssai	GET	^/nudm-sdm/v2/(imsi-[0-9]{5,15}|nai-.+|gci-.+|gli-.+|.+)/nssai/?$
45	/npcf-ue-policy-control/v1/policies/{polAssoId}	DELETE	^/npcf-ue-policy-control/v1/policies/([0-9a-zA-Z-]+|.+)/?$
46	/nsmf-pdusession/v1/pdu-sessions/{pduSessionRef}/release	POST	^/nsmf-pdusession/v1/pdu-sessions/([0-9a-zA-Z-]+|.+)/release/?$
47	/nudm-uecm/v1/{ueId}/registrations/smsf-3gpp-access	PUT	^/nudm-uecm/v1/(imsi-[0-9]{5,15}|nai-.+|msisdn-[0-9]{5,15}|extid-[^@]+@[^@]+|gci-.+|gli-.+|.+)/registrations/smsf-3gpp-access/?$
48	/nsmf-pdusession/v1/pdu-sessions	POST	^/nsmf-pdusession/v1/pdu-sessions/?$
49	/nudm-uecm/v1/{ueId}/registrations/smsf-non-3gpp-access	DELETE	^/nudm-uecm/v1/(imsi-[0-9]{5,15}|nai-.+|msisdn-[0-9]{5,15}|extid-[^@]+@[^@]+|gci-.+|gli-.+|.+)/registrations/smsf-non-3gpp-access/?$
50	/nudm-sdm/v2/{supi}/ue-context-in-smsf-data	GET	^/nudm-sdm/v2/(imsi-[0-9]{5,15}|nai-.+|gci-.+|gli-.+|.+)/ue-context-in-smsf-data/?$
51	/nudm-uecm/v1/{ueId}/registrations/amf-non-3gpp-access	PATCH	^/nudm-uecm/v1/(imsi-[0-9]{5,15}|nai-.+|msisdn-[0-9]{5,15}|extid-[^@]+@[^@]+|gci-.+|gli-.+|.+)/registrations/amf-non-3gpp-access/?$
52	/nudm-uecm/v1/{ueId}/registrations/smf-registrations/{pduSessionId}	DELETE	^/nudm-uecm/v1/(imsi-[0-9]{5,15}|nai-.+|msisdn-[0-9]{5,15}|extid-[^@]+@[^@]+|gci-.+|gli-.+|.+)/registrations/smf-registrations/(([01]?[0-9][0-9]?|2[0-4][0-9]|25[0-5])+)/?$
53	/nudm-sdm/v2/{supi}/ue-context-in-smf-data	GET	^/nudm-sdm/v2/(imsi-[0-9]{5,15}|nai-.+|gci-.+|gli-.+|.+)/ue-context-in-smf-data/?$
54	/npcf-ue-policy-control/v1/policies/{polAssoId}/update	POST	^/npcf-ue-policy-control/v1/policies/([0-9a-zA-Z-]+|.+)/update/?$
55	/nudm-uecm/v1/{ueId}/registrations/amf-3gpp-access	PATCH	^/nudm-uecm/v1/(imsi-[0-9]{5,15}|nai-.+|msisdn-[0-9]{5,15}|extid-[^@]+@[^@]+|gci-.+|gli-.+|.+)/registrations/amf-3gpp-access/?$
56	/nudm-uecm/v1/{ueId}/registrations/smf-registrations/{pduSessionId}	PUT	^/nudm-uecm/v1/(imsi-[0-9]{5,15}|nai-.+|msisdn-[0-9]{5,15}|extid-[^@]+@[^@]+|gci-.+|gli-.+|.+)/registrations/smf-registrations/(([01]?[0-9][0-9]?|2[0-4][0-9]|25[0-5])+)/?$

• If the user wants to create any rules base on the resource URI check, then the resource URI should be present in the above table.
• If in case, the resource URI does not exist and user wants that SEPP should support that resource URI from topology hiding perspective then using the CNC Console GUI, the user must first enter the resource URI in this table and then only start the body configuration of topology body as explained in the topology body configuration.
• If in case resource URI is not present in the default table and user wants to add the resource URI in topology configuration, then user to see the api URI in the dropdown menu of CNC Console.

This table is populated from the set of identified resource URIs at the time of start-up and if any additional resource URI needs to be added then user can add that resource URI from the CNCC Screen.

Managing Topology Hiding

Enable

Topology Hiding feature is disabled by default. You can enable Topology Hiding feature using the REST API or CNC Console.

• Enable using REST API: Set ENABLED to True in Topology Hiding API. For more information about API path, see Oracle Communications Cloud Native Core Security Edge Protection Proxy REST Specification Guide.
• Enable using CNC Console: Set ENABLED to True on the Topology Hiding page. For more information about enabling the feature using CNC Console, see Configuring SEPP using CNC Console.

Configure

You can configure the Topology Hiding using REST API and CNC Console.

• Configure Topology Hiding using REST API: Perform the feature configurations as described Topology hiding section in Oracle Communications Security Edge Protection Proxy Rest API Guide.
• Configure Topology Hiding using CNC Console: Perform the feature configurations as described in Configuring SEPP using CNC Console.

Observe

For more information about metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following:

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

3.2.19 Global Rate Limiting on Egress Gateway of SEPP

Feature Overview

Global rate limiting is a feature provided by Egress Gateway. There are cases where the messages flood into SEPP. With this feature, SEPP secures the network when aggregated egress traffic exceeds the allowed traffic rate limit. If the traffic exceeds the allowed traffic rate limit, SEPP does not process the traffic and responds with an error code. Egress global rate limiting functionality of the SEPP allows the user to configure the acceptable egress traffic rate to any registered NF instance. SEPP enables users to configure the maximum number of outgoing messages at a given duration.

Algorithm

Global Rate limiting on Egress Gateway is implemented using Bucket4j which uses Token Bucket Algorithm. The token bucket algorithm is as follows:

Figure 3-34 Algorithm Overview

Token bucket algorithm process messages only if there are tokens in the bucket. The bucket is asynchronously filled with a configurable rate and tokens are removed from the bucket on message processing.

Three configurations are required for this algorithm:

• Bucket size in which capacity to handle traffic burst is defined.
• Duration to decide how frequently to refill bucket.
• Tokens (number of) which should be added to refill the bucket.

Design and Architecture

Using Egress global rate limiting, the user can configure capacity for SEPP. The incoming traffic management at the gateway level and any traffic beyond the capacity of the backend service get rejected with the error response as configured by the user. The rules for global rate limiting apply to all traffic, irrespective of headers

Figure 3-35 Architecture

The following diagram represents the functionality of the global rate limiting feature with the example:

Figure 3-36 Example

In the above diagram, the global rate limiting feature is enabled on the Responder SEPP Egress Gateway with a capacity of 1500 requests with one second duration. The requests are initiated from the customer NF at initiator side which passes through the initiator SEPP and reach to the responder SEPP Egress Gateway.

If the incoming requests on Egress Gateway of Responder SEPP are more than the configured capacity of 1500 request per second, the requests above the configured value are rejected with an error response as configured by the user . In the above example, the consumer NF is generating 1800 TPS and as per the capacity set at Egress Gateway, 300 requests are rejected with an configured error response. Similarly, if requests are initiated from producer NF at responder side, then the Egress Gateway at responder SEPP will discard the excess request and allow only the configured limit.

Managing Global Rate Limiting on Egress Gateway of SEPP

Enable

The Egress Rate Limiting feature is disabled by default in SEPP at the time of deployment. To enable the feature, set egressRateLimiting.enabled to true in the PLMN Egress Gateway and/or N32 Egress Gateway of ocsepp-custom-values-<version>.yaml file.

ocsepp-custom-values-<version>.yaml

The following parameters are to be configured:

###In the EGW section
egressRateLimiting:
    enabled: true
    duration: 1 # in seconds
    burstCapacity: 4000
    refillRate: 4000
    errorCodeOnRatelimit: 429

Configure

Configure the following parameters to configure the given range of min and max token requests into equal separated intervals.

ocsepp-custom-values-<version>.yaml

###In the EGW section of custom-values
egressRateLimiting:
    enabled: true
    duration: 1
    bucketCapacity: 4000
    refillRate: 4000
    errorCodeOnRateLimit: 429
  ###In the EGW section for egressRateLimiting of values.yaml
    minTokenRequest: 5
    maxTokenRequest: 10
    rangePoint: 6

Observability

There are no new metrics and KPIs are added or updated in as part of this feature.

For more information on SEPP Metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following:

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

3.2.20 Global Rate Limiting on Ingress Gateway of SEPP

Feature Overview

Global rate limiting is a feature provided by Ingress Gateway. There are cases where the messages floods into SEPP. With this feature, SEPP secures the network when aggregated ingress traffic from any registered NF instance exceeds the allowed traffic rate limit. If the traffic exceeds the allowed traffic rate limit, SEPP does not process the traffic and responds with an error code. Ingress global rate limiting functionality of the SEPP allows the user to configure the acceptable traffic rate from a consumer NF instance. SEPP enables users to configure the maximum number of incoming messages at a given duration.

Algorithm

Global Rate limiting on ingress gateway is implemented using Bucket4j which uses Token Bucket Algorithm. The token bucket algorithm is as follows:

Figure 3-37 Algorithm Overview

Token bucket algorithm process messages only if there are tokens in the bucket. The bucket is asynchronously filled with a configurable rate and tokens are removed from the bucket on message processing.

Three configurations are required for this algorithm:

• Bucket size in which capacity to handle traffic burst is defined.
• Duration to decide how frequently to refill bucket.
• Tokens (number of) which should be added to refill the bucket.

Design and Architecture

Using Global rate limiting, the user can configure capacity for backend service (n32f service). The incoming traffic management at the gateway level and any traffic beyond the capacity of the backend service get rejected with the error response as configured by the user. The rules for global rate limiting apply to all traffic, irrespective of headers

Figure 3-38 Architecture

The following diagram represents the functionality of the global rate limiting feature with the example:

Figure 3-39 Example

In the above diagram, the global rate limiting feature is enabled on the Responder SEPP Ingress Gateway with a capacity of 1500 requests with one second duration. The requests are initiated from the customer NF at initiator side which passes through the initiator SEPP and reach to the responder SEPP Ingress Gateway.

If the incoming requests on Ingress Gateway of Responder SEPP are more than the configured capacity of 1500 request per second, the requests above the configured value are rejected with an error response as configured by the user . In the above example, the consumer NF is generating 1800 TPS and as per the capacity set at Ingress Gateway, 300 requests are rejected with an configured error response. Similarly, if requests are initiated from producer NF at responder side, then the Ingress Gateway at responder SEPP will discard the excess request and allow only the configured limit.

Managing Global Rate Limiting on Ingress Gateway of SEPP

Enable

The Ingress Rate Limiting feature is a core functionality of SEPP. This feature is automatically enabled in SEPP at the time of deployment.

ocsepp_custom_values_<version>.yaml

The following parameters are to be configured:

###In the IGW section
rateLimiting:
    enabled: true
 
  globalIngressRateLimiting:
    enabled: true
    duration: 1 # in seconds
    burstCapacity: 4000
    refillRate: 4000
  errorCodeOnRatelimit: 429

Configure

Configure the following parameters to configure the given range of min and max token requests into equal separated intervals.

ocsepp/values.yaml

###In the IGW section
    minTokenRequest: 5
    maxTokenRequest: 10
    rangePoint: 6

Observability

This section describes the information about the KPIs and metrics.

Metrics

The following table describes the newly introduced metrics as part of this feature.

For PLMN Ingress Gateway and N32 Ingress Gateway:

Table 3-27 oc_ingressgateway_global_ratelimit_total

Metric Type	Tags Available
oc_ingressgateway_global_ratelimit_total	Method Route_path Scheme InstanceIdentifier Status

KPIs

The following tables describe the newly introduced KPIs as part of this feature:

Table 3-28 N32 IGW Global Rate limit Traffic Rejected

Field	Details
KPI Detail	Measures the N32 IGW Global rate limit traffic rejected
Metric Used for KPI	sum(irate(oc_ingressgateway_global_ratelimit_total{namespace=~"$Namespace",app="n32-ingress-gateway", Status="dropped"}[2m])) No. of messages rejected for traffic initiated from consumer side

Table 3-29 PLMN IGW Global Rate limit Traffic Rejected

Field	Details
KPI Detail	Measures the PLMN IGW Global rate limit traffic rejected
Metric Used for KPI	sum(irate(oc_ingressgateway_global_ratelimit_total{namespace=~"$Namespace",app="plmn-ingress-gateway", Status="dropped"}[2m])) No. of messages rejected for traffic initiated from producer side

For more information on Global Rate Limiting on Ingress Gateway of SEPP Metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following:

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

3.2.21 Multiple PLMN Support for Local and Remote SEPP

In earlier releases, the local SEPP could route to only a single roaming partner and a particular PLMNID for that roaming partner.

Generally, it is preferred to use a single SEPP to route to multiple roaming partners and to support a list of PLMN IDs. This feature allows the local SEPP to communicate with multiple remote partners simultaneously. With this feature, SEPP can route to a minimum of 1 and a maximum of 30 PLMN IDs at the same time.

Feature Overview

The purpose of implementing this feature is to configure a single SEPP instance to support multiple PLMNs.

Design and Architecture

In this feature, one SEPP instance supports multiple PLMNs. The following diagram represents the detailed architecture of the Multiple PLMN Support for Local and Remote SEPP.

Figure 3-40 Multiple PLMN Support

Configuration

The SEPP can be configured as Local SEPP (the SEPP at the consumer side, cSEPP) and as Remote SEPP (the SEPP at the producer side, pSEPP). To initiate the communication between a Local SEPP and Remote SEPP, the Local and Remote SEPP sides must be configured to have the list of SEPPs that are assigned as primary, secondary, or tertiary SEPPs to support the alternate routing as per the availability of SEPPs. Each Remote SEPP Set must have unique list of PLMNs supported by that particular set.

In the above diagram the SEPPs, Remote SEPP Sets, and PLMNs are configured as follows:

• Local SEPP supports PLMN0 and PLMN1.
• Remote SEPP11, SEPP12, and SEPP13 shares the PLMN2 and PLMN3 networks.
• The Remote SEPP11, Remote SEPP12, and Remote SEPP13 are working as primary, secondary and tertiary SEPPs, as they are part of the same remote SEPP set.
• Remote SEPP21 and Remote SEPP22 belongs to the remote operator 2. Remote SEPP 21 supports PLMN4 and PLMN5. Remote SEPP 22 supports PLMN 6.
• Remote SEPP 21 and 22 belongs to same operator, but they are not sharing the same PLMN list. So they are reachable through different remote SEPP sets.

Functioning and Routing

Once the SEPPs are installed and configured, the communication between the two SEPPs are through two interfaces, N32c and N32f:

• N32c is interface between the SEPPs for performing initial handshake and negotiating the parameters to be applied for the actual N32 message forwarding. The handshake initiation is modified to support the Multiple PLMN For Local and Remote SEPP.
• N32f is the interface between the SEPPs for forwarding the communication between the NF service consumer and the NF service producer. While sending the request, the plmnid configured at handshake must be validated by comparing the plmnid in the fqdn of the 3gpp-sbi-target-apiRoot or Authority header. Once the plmnid is validated, then the messages are forwarded to the destined NFs.

Note:

The following table lists the Range of RemoteSepp Set and PLMN ID:

Table 3-30 Range of RemoteSepp Set and PLMN ID

Mode/Parameter	PLMN ID per RemoteSepp	RemoteSepp Set	Local PLMN ID List (Self PLMN)
SEPP Mode	Minimum = 1 Maximum = 30	Minimum = 1 Maximum = 1000	Minimum = 1 Maximum = 30

RemoteSepp = SEPP in Remote PLMN

RemoteSepp Set =RemoteSepp sets are created per PLMN. It consists of minimum 1 and maximum 3 RemoteSepp in Primary-Secondary-Tertiary mode and used for N32F SBI message routing.

Managing Multiple PLMN support for local and remote SEPP

Enable

This feature is the core functionality of SEPP. You do not need to enable or disable this feature. It is enabled by default.

Note:

If plmnList is updated in NrfClient: profile: appProfiles section, after performing the helm-upgrade user needs to restart the NF Management pods (nfmanagement and nfdiscovery) to load the latest profile in NRF.

Configure

You can configure the Multiple PLMN support for local and remote SEPP using REST API and CNC Console.

• Configure Multiple PLMN support for local and remote SEPP using REST API: Perform the feature configurations as described Remote SEPP Set and Remote SEPP section in Oracle Communications Security Edge Protection Proxy Rest API Guide.
• Configure Multiple PLMN support for local and remote SEPP using CNC Console: Perform the feature configurations as described in Configuring SEPP using CNC Console.

Observe

For more information about metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following:

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

3.2.22 Support of TLS for Roaming Hubs and IPX Providers

Oracle SEPP is deployed by both Mobile Network Operators (MNO) and Roaming Hub providers. MNOs deploy SEPP acting as 3GPP 5GC SEPP NEF which enables inter PLMN communication between two networks via N32 interface.

Roaming Hub providers deploy SEPP acting as Roaming Hub enabling inter PLMN communication between MNOs through N32 interface supporting Application Layer Security (ALS) as specified in TS 33.501. Roaming Hub provider is able to deploy SEPP in either of one mode i.e. functionality of 5GC SEPP NF or Roaming Hub. Roaming Hub providers are able to host 5GC SEPP NF functionality for few of the MNO's and host Roaming Hub functionality for rest of the MNOs.

There are scenarios where the user wants to deploy an intermediate proxy. Currently, for SEPP to be a viable proxy 3GPP specifies that a mode is known as PRINS be supported on the Roaming Hub.

PRINS mode has implementation challenges. To overcome this, there is an option where SEPP can be deployed as an interconnect proxy without the use of PRINS. This is commonly called as the Supporting Roaming Hub using TLS mode.

The following diagram represents a high-level overview of Support of TLS for Roaming Hubs and IPX Providers.

Figure 3-41 Roaming Hub Overview

SEPP supports inter PLMN traffic for both SEPP MNO and Roaming Hub modes.

Detailed Description

Figure 3-42 Detailed Description

In previous releases, when operators require to have interconnect with other operators, a Security Edge Protection Proxy allows for the following:

• A single point of entry into and out of the network
• This single point of entry can help in having a single point of interconnect
• Security to networks (not exposing all the NF's to the external network)

With the Support of TLS for Roaming Hubs and IPX Providers feature,

• The interconnect operators functions as an aggregator for roaming interconnects.
• The Operators can scale out as interconnect and can enable interconnects to become a roaming HUB.
• To support this, multiple SEPPs can be deployed by a Roaming Hub.
• Each SEPP within the Roaming Hub Provider needs to implement complex routing feature in order to route message from one consumer SEPP to a producer SEPP within the Roaming Hub.

Note:

The following table lists the Range of RemoteSepp Set and PLMN ID:

Table 3-31 Range of RemoteSepp Set and PLMN ID

Mode/Parameter	PLMN ID per RemoteSepp	RemoteSepp Set	Local PLMN ID List (Self PLMN)
Roaming Hub Mode	Minimum = 1 Maximum = 20	Minimum = 1 Maximum = MaxRSS The value can be derived from : MaxRSS == (400 – total number of PLMNs used) / Maximum PLMN per RemoteSeppSet	Minimum = 1 Maximum = 400 Local PLMN is consolidate list of PLMN IDs of all the RemoteSepp(s) associated with this Roaming Hub

RemoteSepp = SEPP in Remote PLMN

RemoteSepp Set =RemoteSepp sets are created per PLMN. It consists of minimum 1 and maximum 3 RemoteSepp in Primary-Secondary-Tertiary mode and used for N32F SBI message routing.

Managing Support of TLS for Roaming Hubs and IPX Providers

Enable

This feature is the core functionality of SEPP. You do not need to enable or disable this feature. It is enabled by default.

Configure

You can configure the Support of TLS for Roaming Hubs and IPX Providers feature using REST API, and CNC Console.

• Configure Support of TLS for Roaming Hubs and IPX Providers feature using REST API: Perform the feature configurations as described logging Configurations section in Oracle Communications Security Edge Protection Proxy Rest API Guide.
• Configure Support of TLS for Roaming Hubs and IPX Providers feature using CNC Console: Perform the feature configurations as described in Configuring SEPP using CNC Console.

Observe

For more information about metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following:

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

3.2.23 Overload Control

Overview

SEPP processes 5G Service Based Interface (SBI) messages using its microservices. To protect the microservices from the overload, SEPP supports Overload Control feature. The feature provided by Ingress Gateway and Perf-Info. This section describes the SEPP support for this feature.

Overload occurs when 100% of the planned capacity is exhausted. It can be due to uneven distribution of traffic towards a given SEPP service instance, network fluctuations leading to traffic bursts, or unexpected high traffic volume at any given point of time. During overload conditions, the service's response time may grow to unacceptable levels, and exhaustion of resources may force service to unexpected behavior or even downtime. Overload control helps to control services downtime and ensures service availability during extreme overload conditions. Using Ingress Gateway and perf-info microservices, SEPP provides options to control network congestion and handle the overload scenarios.

Detailed Description

The perf-info calculates CPU and memory usage. Based on the configured threshold levels, the Perf info applies the threshold level defined. The Ingress Gateway allows or discards incoming requests, based on the overload threshold applied.There are 2 types of discard policies supported; Percentage based and Priority based.

In percentage based discard policy, discard the certain percentage of messages once the traffic is reached threshold level. In priority based discard policy, if SEPP is overloaded, only the high priority messages are processed. Low priority traffic is discarded with the configured error code.

SEPP allows the user to configure the threshold overload levels.

Setting the Threshold Level

User can configure the threshold level for CPU and Memory usage.

Threshold levels defined are Warning , Minor, Major, and Critical. When values for CPU and Memory reach the configured limits, data is discarded on the basis of configured values for the threshold level defined.

The following table represents the example for threshold set for CPU and memory and the discard values.

Table 3-32 Threshold Level

Threshold Level	CPU onset	CPU abatement	Memory onset	Memory abatement	Percentage Discard	Priority threshold
Warning	65	60	50	45	0%	30
Minor	75	70	70	65	5%	24
Major	85	80	80	75	10%	15
Critical	95	90	90	85	25%	10

Percentage based discard policy

The percentage based discard policy is applied on the incoming traffic. When SEPP is overloaded and if the discard scheme is Percentage based, the number of messages discarded corresponds to the threshold percentage level defined.

Figure 3-43 Percentage based discard policy

In the above diagram, percentage threshold level is set as 10%. Therefore for incoming traffic rate at 100 TPS, 10 messages will be discarded with the configured error code.

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.

Priority Based Discard Policy

The priority based discard policy is applied on the incoming traffic . When application is overloaded and if the discard scheme is priority based, the messages are discarded on the basis of the priority threshold defined. The priority is determined by the "3gpp-sbi-message-priority" header present in the incoming message.

Higher the value of "3gpp-sbi-message-priority" lower is the priority and vice-versa.

Figure 3-44 Priority Based Discard Policy

In the above diagram, the threshold priority set is 20. The incoming message has 3gpp-sbi-message-priority header value as 10. As it is a high priority message, the message will be processed.

Figure 3-45 Priority Based Discard Policy

In the above diagram, the threshold priority set is 20. The incoming message has 3gpp-sbi-message-priority header value as 24 . As it is a low priority message, the message will be discarded.

Managing Overload Control Feature

Enable

This feature is disabled by default.

Note:

This feature is supported only on inter PLMN traffic, that is N32 Ingress Gateway and PN32F-svc.

You can enable the Overload Control feature using the Helm and REST API.

• In Helm configuration: In the perf-info section, set overloadManager.enabled to true.
• In REST API: Set svcName to <release-name>-pn32f-svc and set enabled to true in Overload Control REST API. For more information about API path, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy REST Specification Guide.

Configure

You can configure the feature using REST API:

• Configure using Helm: Refer the Steps to configure overload control section for configuring using Helm parameters.
• Configure using REST API: Perform the feature configurations as described in Oracle Communications Cloud Native Core, Security Edge Protection Proxy REST Specification Guide.

Configuring Overload Control

1. In the N32 Ingress gateway section of ocsepp_custom_values_<version>.yamlfile, set the parameter enableIncomingHttp to true.
   1. This is required as https communication is not allowed between the perf-info and the n32-ingress-gateway service.
   2. Network policy can be applied on the namespace to restrict external http incoming traffic through n32-ingress-gateway.
2. In the perf-info section, modify the parameter configmapPerformance.prometheus according to the prometheus service deployed in the cluster. If the Prometheus UI has cluster-name appended to it, modify the parameter as follows:

   http://occne-kube-prom-stack-kube-prometheus.occne-infra:80/<clustername>

   Example: http://occne-kube-prom-stack-kube-prometheus.occne-infra:80/cluster1

   Note:

   Perform the Helm upgrade after the above customizations, if OCSEPP has already been deployed.
3. By default, the feature will be disabled. To enable the feature run the Overload Control REST API to change the svcName to <release-name>-pn32f-svc and enabled to true.

   
   curl -X PUT http://<config-server>:port/sepp/nf-common-component/v1/igw/n32/ocpolicymapping -H 'Content-type: application/json' -d '
   {
       "enabled": true,
       "mappings": [
           {
               "svcName": "ocsepp-release-pn32f-svc",
               "policyName": "Policy2"
           }
       ],
       "samplingPeriod": 5000
   }'

4. To define CPU and Memory threshold limits, run the following code. Change the svcname as done as step 1:

   curl -X PUT http://<config-server>:port/sepp/nf-common-component/v1/perf-info/overloadLevelThreshold -H 'Content-type: application/json' -d '
   [{
       "svcName": "ocsepp-release-pn32f-svc",
       "metricsThresholdList": [{
           "metricsName": "memory",
           "levelThresholdList": [{
               "level": "Warning",
               "onsetValue": 50,
               "abatementValue": 45
           }, {
               "level": "Minor",
               "onsetValue": 70,
               "abatementValue": 65
           }, {
               "level": "Major",
               "onsetValue": 80,
               "abatementValue": 75
           }, {
               "level": "Critical",
               "onsetValue": 90,
               "abatementValue": 85
           }]
       }, {
           "metricsName": "cpu",
           "levelThresholdList": [{
               "level": "Warning",
               "onsetValue": 65,
               "abatementValue": 60
           }, {
               "level": "Minor",
               "onsetValue": 75,
               "abatementValue": 70
           }, {
               "level": "Major",
               "onsetValue": 85,
               "abatementValue": 80
           }, {
               "level": "Critical",
               "onsetValue": 95,
               "abatementValue": 90
           }]
       }]
   }]'

   Note:

   The above mentioned values are the recommended values for each threshold level. User can configure them as required.
5. By default the discard policy is Percentage Based. To change the discard policy to Priority based, run the following code with svcName same as in step1:

   curl -X PUT http://<config-server>:port/sepp/nf-common-component/v1/igw/n32/ocpolicymapping -H 'Content-type: application/json' -d '
   {
       "enabled": true,
       "mappings": [
           {
               "svcName": "ocsepp-release-pn32f-svc",
               "policyName": "Policy1"
           }
       ],
       "samplingPeriod": 5000
   }'
    
   #Policy1 is PriorityBased

6. By default the error code configured is 429. To change the error code, change the errorCode and run the following code:

   curl -X PUT http://<config-server>:port/sepp/nf-common-component/v1/igw/n32/errorcodeprofiles -H 'Content-type: application/json' -d '
   [
       {
           "name": "error429",
           "errorCode": 503,
           "errorCause": "",
           "errorTitle": "",
           "errorDescription": ""
       }
    ]

7. To get the details of discard policy defined, run the following command:

   curl -X GET http://<config-server>:port/sepp/nf-common-component/v1/igw/n32/ocdiscardpolicies

   Example:

   DiscardPolicies.json:

   [{
   "name": "Policy1",
   "scheme": "PriorityBased",
   "policies": [{
   "level": "Warning",
   "value": 30,
   "action": "RejectWithErrorCode",
   "errorCodeProfile": "error429"
   },
   {
   "level": "Minor",
   "value": 24,
   "action": "RejectWithErrorCode",
   "errorCodeProfile": "error429"
   },
   {
   "level": "Major",
   "value": 15,
   "action": "RejectWithErrorCode",
   "errorCodeProfile": "error429"
   },
   {
   "level": "Critical",
   "value": 10,
   "action": "RejectWithErrorCode",
   "errorCodeProfile": "error429"
   }
   ]
   },
   {
   "name": "Policy2",
   "scheme": "PercentageBased",
   "policies": [{
   "level": "Warning",
   "value": 0,
   "action": "RejectWithErrorCode",
   "errorCodeProfile": "error429"
   },
   {
   "level": "Minor",
   "value": 5,
   "action": "RejectWithErrorCode",
   "errorCodeProfile": "error429"
   },
   {
   "level": "Major",
   "value": 10,
   "action": "RejectWithErrorCode",
   "errorCodeProfile": "error429"
   },
   {
   "level": "Critical",
   "value": 25,
   "action": "RejectWithErrorCode",
   "errorCodeProfile": "error429"
   }
   ]
   }
   ]

   Note:

   • The above are recommended values. The user can change them as per their preference.
   • value for Percentage Based policy indicates the percentage of incoming traffic that will be discarded.
   • value for Priority Based policy indicates the threshold priority value, equal to or higher which the incoming traffic will be discarded.
8. To change the discard policies, run the following command with your changes in DiscardPolicies.json:

   curl -X PUT http://<config-server>:port/sepp/nf-common-component/v1/igw/n32/ocdiscardpolicies -H 'Content-type: application/json' -d @DiscardPolicies.json

Observe

Following are the overload control feature specific metrics:

• oc_ingressgateway_route_overloadcontrol_discard_total
• service_resource_overload_level

Following are the overload control feature specific KPIs:

• PercentageDiscard
• PriorityDiscard

For more information on Overload Control feature related SEPP Metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following:

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

3.2.24 Alternate Routing Across Remote SEPPs

In earlier SEPP releases, Consumer SEPP could communicate with single Producer SEPP and if this single Producer SEPP was not available for any reason, n32f traffic would drop and not reach its home PLMN.

The SEPP cannot route to an alternate SEPP when the primary path is down. The reasons for the primary path being down can vary from routing path having issues, to the actual P-SEPP not being up and running. Some of the reasons can be as follows:

• Remote SEPP or NF is not reachable due to network issue
• Remote SEPP or NF unavailable
• There is an internal server error
• Bad request
• FQDN/IP or port is incorrect
• HTTP2 Error codes, 400, 404, 500, 503, and 504

With Alternate Routing Across Remote SEPPs feature, the consumer SEPP routes the n32f traffic messages based on the availability of Primary or Secondary or Tertiary producer SEPPs present in a Remote SEPP Set (sets will be uniquely identified based on the home PLMN).

Feature Overview

The purpose of implementing this feature is to support and provide a reliable path always between two PLMNs through the SEPPs.

Design and Architecture

In this feature, the consumer SEPP end routes the n32f traffic messages based on the availability of Primary or Secondary or Tertiary producer SEPPs present in a set. The following diagram represents the detailed architecture of the Alternate Routing Across Remote SEPPs.

Figure 3-46 Architecture

• The remote SEPP sets are created per PLMN. In this diagram there are two remote sets, remote SEPP set for Home PLMN1 and remote SEPP set for Home PLMN2.
• These Remote SEPP sets can vary from 1 to N (unique for each PLMN).
• Each set can have up to three producer SEPP's based on their priority as primary, secondary, or tertiary.
• N32 EGW routes each n32f traffic message to the producer based on the priority assigned in the Remote SEPP.
• N32 EGW first routes each n32f traffic message towards primary SEPP, if it is not available it then routes to secondary SEPP, and similarly towards the tertiary SEPP.
• The call will be dropped only if primary, secondary, and tertiary SEPPs are not available. This increases the reliability of the calls.

The following configuration is mandatory and needs to be done through CNC console or REST APIs.

Managing Alternate Routing Across Remote SEPPs

Enable

This feature is the core functionality of SEPP. You do not need to enable or disable this feature. It is enabled by default.

Configure

You can configure the Alternate Routing Across Remote SEPPs using REST API, and CNC Console.

• Configure Alternate Routing Across Remote SEPPs using REST API: Perform the feature configurations as described in Remote SEPP Set section in Oracle Communications Cloud Native Core, Security Edge Protection Proxy REST Specification Guide.

Default Routes

When SEPP is installed, the following three default routes are created on n32-egress-gateway. These routes are for internal use only. They aren't available in the custom values, and users don't need to modify them.

• N32c with path set to /n32c-handshake/**: This route helps in the routing of n32c handshake exchange-capability message without apiPrefix.
• N32d with path set to /*/n32c-handshake/**: This route helps in the routing of n32c handshake exchange-capability message with apiPrefix.
• ocseppRejectAll (default route): This is the default route. If any message except Handshake and n32f arrives, it is dropped at Egress Gateway and is not routed towards the Producer SEPP.

The following diagram represents the default routes:

Figure 3-47 Default Routes

Example of the default route created automatically on n32-egress-gateway:

routesconfiguration": [{"id": "ocseppRejectAll", "uri": "https://ocsepp.com", "order": 903, "filters": [{"args": {"errorCodeOnInvalidRoute": "500", "errorCauseOnInvalidRoute": "No Matching Route.", "errorTitleOnInvalidRoute": "No Matching Route.", "errorDescriptionOnInvalidRoute": "No Matching Route."}, "name": "InvalidRouteFilter"}], "predicates": [{"args": {"pattern": ""}, "name": "Path"}]}, {"id": "n32c", "uri": "https://ocsepp.com", "order": 901, "predicates": [{"args": {"pattern": "/n32c-handshake/**"}, "name": "Path"}]}, {"id": "n32d", "uri": "https://ocsepp.com", "order": 902, "predicates": [{"args": {"pattern": "/*/n32c-handshake/**"}, "name": "Path"}]},

Routes for SBI Message (n32f interface)

• Remote SEPP is added at initiator and responder side. Once security capability procedure is successful, Peer is added at n32-egress-gateway.
• Remote SEPP Set is added to SEPP having information about primary, secondary, and tertiary SEPPs. Based on the Remote SEPP Set information, n32-egress-gateway also configures the Peer Set at its end, and tries to route the N32f messages based on the priority configured in the Peer Set.
• N32f route helps in routing of n32f traffic messages towards producer SEPP based on the PLMN of the Producer SEPP.

The user configurable Helm parameters and can be configured through ocsepp/charts/config-mgr-svc/values.yaml file.

For more information on the Helm parameters, see the config-mgr-svc section of Oracle Communications Cloud Native Core, Security Edge Protection Proxy Installation, Upgrade, and Fault Recovery Guide.

Example for n32f routes automatically created on n32-egress-gateway:

{"id": "plmn-357", "uri": "https://ocsepp.com", "order": 357, "filters": [{"args": {"errorHandling": [{"priority": 2, "actionSet": "action_0", "actionSet": "criteria_1"}, {"priority": 1, "actionSet": "action_0", "errorCriteriaSet": "criteria_0"}], "peerSetIdentifier": "RS-1", "customPeerSelectorEnabled": true}, "name": "SbiRouting"}, {"args": {"name": "OC-SEPP-PLMN-ID"}, "name": "RemoveRequestHeader"}], "metadata": {"httpRuriOnly": false, "httpsTargetOnly": false, "sbiRoutingEnabled": true}, "predicates": [{"args": {"header": "OC-SEPP-PLMN-ID", "regexp": "RS-1"}, "name": "Header"}]}], "forwardheaderdetails": {"enabled": false, "forwardHeaderValue": ""}

Alternate Routing Flow

When the SBI message reached n32-egress-gateway, the relevant route is selected. The traffic is routed towards the primary peer mentioned in the peerset associated with the route. On receiving the response from primary peer:

• If the response is successful, message is routed towards Remote SEPP.
• If the response is an error response, the response is validated against the errorCriteriaSet mentioned in the route. If the error received matched the criteria mentioned in the criteria set, action is performed on the basis of actionSet.

The following diagram represents the Alternate Routing flow:

Figure 3-48 Alternate Routing Flow Chart Representation

Response Validation against the Error Handling

The error handling section within the SbiRouting filter is an array of mapping between criteriaset and actionset, tagged with a priority. It is similar to peer and peerset configurations tagging. The criteriaset and actionset ids are tagged in the error handling section along with a priority for each mapping. The actual criteriaset and actionset configuration has to be done in sbiRoutingErrorCriteriaSets and sbiRoutingErrorActionSets respectively.

sbiRoutingErrorCriteriaSets

It is a combination of HTTP method and HTTP status code or HTTP method and exception. When an error response is received, HTTP status code and HTTP method or exception is received in the response is validated with the configured values.

• If the match is found, action is taken on the basis of erroractionset configuration.
• If the match is not found, error response is sent to the originating NF.

Example of SbiRoutingErrorCriteriaSets automatically created through Helm configuration on n32-egress-gateway:

"sbiroutingerrorcriteriasets": [{"id": "criteria_1", "method": ["GET", "POST", "PUT", "DELETE", "PATCH"], "response": {"statuses": [{"status": [400, 404], "statusSeries": "4xx"}, {"status": [500, 503, 504], "statusSeries": "5xx"}]}}, {"id": "criteria_0", "method": ["GET", "POST", "PUT", "DELETE", "PATCH"], "exceptions": ["java.util.concurrent.TimeoutException", "java.net.SocketException", "java.net.SocketTimeoutException", "java.net.UnknownHostException", "java.net.ConnectException", "java.net.NoRouteToHostException"]}

SbiRoutingErrorActionSets

After the criteriaset conditions is validated and met, the corresponding actionset is selected to decide what will be the next course of action.

• action: SEPP currently supports only reroute action which means try secondary or tertiary peer when the error is received from primary or secondary peer.
• attempts: Maximum no of retries to either same or different peer in case of errors or failures from received backend.
  • The action is reroute and no of reroute attempts is 2. Hence, the request would be rerouted to the secondary peer of peerset and then the same steps would be repeated for tertiary once the error response from secondary peer is recieved.
  • If only primary peer is configured and if an error is received, three retries are attempted on the primary peer.
  • If the primary and secondary peers are configured and if an error is received, the retries are attempted on the secondary peer.

  Note:

  To enable alternate routing feature, change alternateRoute.sbiReRoute.sbiRoutingErrorActionSets[].Attempts parameter value to 2. This will allow switching from primary to secondary to tertiary remote SEPPs.
• blacklist: At present, this is not used on n32-egress-gateway.

Example of SbiRoutingErrorActionSets automatically created through Helm configuration on n32-egress-gateway:

"sbiroutingerroractionsets": [{"id": "action_0", "action": "reroute", "attempts": 2, "blacklist": {"enabled": false, "duration": 60000}}]

Observe

For more information about metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following:

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

3.2.25 Server Header Support

SEPP supports server header in the error responses generated for SEPP services. Using the server header, the user can find out if the error is generated either by the SEPP or some other NF. As per 3gpp specs, format of server-header is SEPP-<fqdn>.

If an error condition occurred at SEPP, SEPP services adds the server header in the error response message. This is added to inform the user that error is generated by SEPP. All the intra PLMN traffic in SEPP is received by plmn-ingress-gateway and inter PLMN traffic is handled by N32-ingress-gateway. If any of the ingress-gateway in SEPP is not reachable or in error state, error response would not contain server-header parameter.

Gateways also support adding server-header for which user has to enable server-header through helm configuration.

Error scenario examples: n32f-context not found, 3gpp-header is not in correct format, Ingress Gateway is down.

Helm Configuration

Configure using helm: To configure server header at Egress Gateway, you need to perform the helm configurations:

# All attributes under "serverHeaderDetails" will need to be configured only if "serverHeaderConfigMode" is set as "HELM"
  serverHeaderDetails:
    # If enabled at Global level, Global conf will be used by default if no conf exists at Route level.
    enabled: true
    # Mandatory attribute if not defined at Route level. By default used for Global level conf. Value need to be one among "errorCodeSeriesList" resource defined below.
    errorCodeSeriesId: E1
    configuration:
       # Mandatory attribute. This value is common across Global and Route level conf. If not defined, server header will not be included in response.
      nfType: SEPP
      # Optional attribute. This value is common across Global and Route level conf. If not defined, only "nfType" will be used for server header value.
      nfInstanceId: 9faf1bbc-6e4a-4454-a507-aef01a101a06

  # Use below configuration to define errorCodeSeries list
  errorCodeSeriesList:
    # Value of "id" attribute will need to used for assigning "errorCodeSeriesId" either at Global or Route level conf for Server header.
  - id: E1
    errorCodeSeries:
      # Possible values for "errorSet" attribute: 5xx, 4xx, 3xx, 2xx, 1xx
    - errorSet: 4xx
      # Possible values include all error codes in the respective HttpSeries(Ex: 4xx) value assinged for "errorSet". Use single value of -1 if all error codes are to be considered.
      errorCodes:
      - 400
      - 408
      - 404
    - errorSet: 5xx
      errorCodes:
      - 500
      - 503
      - 504
  - id: E2
    errorCodeSeries:
    - errorSet: 4xx
      errorCodes:
      - -1

Note:

Egress Gateway wont add the server header in self generated error responses. Example: The server header wont be added if the error is generated due to DNS SRV records not present in the DNS.

3.2.26 Support for Networks with/without 3GPP-SBI-Target-API-Root Header

There are some networks which may not be supporting the Rel 16 header 3GPP-SBI-Target-Apiroot header. In such scenarios, SEPP being deployed at the edge of the network is required to make the routing possible in the core network. SEPP modifies the respective headers such that routing doesn't fail in the core network.

Note:

When an incoming message doesn't have the 3gpp-sbi-target-apiroot header but the PLMN network needs it, SEPP uses the information in the authority header to populate the 3gpp-sbi-target-apiroot header.

There are two possible scenarios:

1. Network that is sending in the request does not use the 3GPP-SBI-Target-Apiroot header, however the core Network behind the SEPP will require this header.

   In this case the SEPP sets the 3GPP-SBI-Target-Apiroot header to the intended producer by using the value presented to it in the authority header.

   The following diagram represents this scenario:

   Figure 3-49 SEPP sets the 3GPP-SBI-Target-Apiroot header

   
2. Network that is sending in the request uses the 3GPP-SBI-Target-Apiroot header, however the core network behind the SEPP will not be able to understand this header.

In this case the SEPP removes the 3GPP-SBI-Target-Apiroot header and set the intended producer in the authority header.

The following diagram represents this scenario:

Figure 3-50 SEPP removes the 3GPP-SBI-Target-Apiroot header

Managing Support for networks with/without 3GPP-SBI-Target-API-Root header

Enable

This feature is enabled by default. This is on the basis of query consumer NF is sending to producer NF.

Configure

You can configure the Support for networks with/without 3GPP-SBI-Target-API-Root header using helm parameters:

Configuring using Helm parameters

sbiRouting:
# Default scheme applicable when 3gpp-sbi-target-apiroot header is missing
sbiRoutingDefaultScheme: https

In pn32f svc -> 

configs:
is3gppSbiTargetApiRootSchemeHttp: true

Observe

For more information on Support for networks with/without 3GPP-SBI-Target-API-Root header feature metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following:

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

3.2.27 NRF Interface Registration and Deregistration

The Network Repository Function (NRF) stores all the information about NFs. SEPP supports registering into the NRF and deregistering from the NRF when required. This allows for NFs to discover the SEPP when required for routing interPLMN traffic.

The following diagram depicts the topology for NRF Interface Registration & Reregistration.

Figure 3-51 NRF Interface Registration and Reregistration

Managing NRF Interface Registration and Deregistration

Enable

 nfName: sepp
# Global control to enable/disable deployment of NF Discovery service, enable it if on demand discovery of NF is required.
nrfClientNfDiscoveryEnable: true
# Global control to enable/disable deployment of NF Management service.
nrfClientNfManagementEnable: true

Configure

You can configure the NRF Interface Registration and Deregistration using helm parameters:

Configuring using Helm parameters

profile: 

[appcfg]
primaryNrfApiRoot= http://10.75.236.102:31294  #NRF Ingress Gateway IP
secondaryNrfApiRoot=
nrfScheme=http
retryAfterTime=PT120S
nrfClientType=SEPP
nrfClientSubscribeTypes=
appProfiles= [{"nfInstanceId":"9faf1bbc-6e4a-4454-a507-aef01a101a06","nfType":"SEPP","nfStatus":"REGISTERED","fqdn":"ocsepp-release-plmn-ingress-gateway.DEPLOYMENT_NAMESPACE","scheme":"http"}]

deploymentNrfClientService:
    # Services to be monitored by performance service
    # If no services are to be monitored, envNfNamespace,envNfType,envConsumeSvcName can be left blank
    envNfNamespace: csepp
    envNfType: 'sepp'
    envConsumeSvcName: 'appinfo'

# Service to be monitored by appinfo. We can add a specific SEPP service name 
core_services:
sepp: []

Observe

For more information on NRF Interface Registration and Deregistration metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following:

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

3.2.28 Subject Alternate Name(SAN) Validation

SAN ( Subject Alternate Names) validation validates whether the SAN in the SEPP certificate matches with the FQDN in the Remote SEPP.

In earlier releases, the SAN Validation is a mandatory configuration for the regular SEPP deployments.

With this enhancement, the SAN validation is made optional. By making SAN validation option, user get the flexibility to bypass this check.

The following procedures can be used to make it optional :

• sanValidationRequired is set to false in the roaming partner configuration. This disables san validation for the specific roaming partner.
• sanValidationRequired is set to false in helm configuration. This disables san validation for all the Remote SEPPs.

Managing Subject Alternate Name(SAN) Validation Feature

Enable

Subject Alternate Name(SAN) Validation Feature is enabled by default.You can disable Subject Alternate Name(SAN) Validation feature using the helm parameters and REST API or CNC Console .

• To disable the feature, set sanValidationRequired to False in the ocsepp-custom-values-<version>.yaml file.
• Disable using REST API: Set sanValidationRequired to False in Remote SEPP. For more information about API path, see Oracle Communications Cloud Native Core Security Edge Protection Proxy REST Specification Guide.
• Disable using CNC Console: Set sanValidationRequired to False on the Remote SEPP page. For more information about enabling the feature using CNC Console, see Configuring SEPP using CNC Console.

• SAN Validation Enable/Disable Table

  Value of sanValidationRequired in HELM	Value of sanValidationRequired in REST API/ CNC Console (Remote SEPP )	SAN Validation of incoming N32C handshake request
  TRUE	TRUE	SAN Validation occurs
  TRUE	FALSE	No SAN Validation
  FALSE	TRUE	No SAN Validation
  FALSE	FALSE	No SAN Validation

Observe

For more information about metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following:

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

3.2.29 SEPP Message Feed

Overview

SEPP supports copying of the incoming and outgoing messages passing through Ingress and Egress Gateways to a Data Director. Data Director receives the messages from Gateways with a correlation-id and feeds the data securely to an external monitoring system.

The correlation-id in the messages is used as a unique identifier for every transaction. If the request does not have the correlation-id, the Gateway generates the correlation-id and then passes it to Data Director.

Upon receiving an Ingress Gateway request containing a correlation-Id, the SEPP microservices include this correlation-Id in upcoming related Egress Gateway requests that may be generated by the SEPP based on the Ingress Gateway transaction.

From Gateway Services 25.1.100, Gateway Services is enhanced to capture all messages within a transaction on to the same Kafka partition based on the keybasedKafkaProducer Helm configuration. If keybasedKafkaProducer is set to true, correlation-id metadata is used as the message key for the key based Kafka producer. This ensures that the same transaction messages are routed to the same partition. If keybasedKafkaProducer is set to false, all the messages are distributed across all the available partitions in a round robin order.

Note:

This feature is not applicable for ASM deployments.

Detailed Description

In order to capture incoming and outgoing traffic, there are four tapping points for Ingress Gateway and Egress Gateway.

Figure 3-52 Overview of Message Feed

Ingress Gateway Tapping point

1. As soon as the request arrives at Ingress Gateway, but before passing through the chain of filters for post-processing.
2. When the response is about to be sent by Ingress Gateway to the consumer NF, after all the post-processing is done by the chain of filters on the response.

   Egress Gateway Tapping point

3. After the request is received at Egress Gateway and and has undergone preprocessing and before the request is sent out of Egress Gateway to the producer NF.
4. As soon as the response is received at Egress Gateway and before passing it through the chain of filters for post-processing.

In above diagram, 1, 2, 3, and 4 indicate the tapping points at which gateways copy the messages. The message copy can be configured and enabled/disabled in pairs for points (1, 2) and points (3, 4).

The following diagram represents the SEPP representation of Message feed feature:

Figure 3-53 SEPP representation of Message Feed feature

Detailed Description

The following diagram indicates the detailed view of message feed feature in SEPP:

Figure 3-54 Detailed view of message feed feature in SEPP

• When SEPP receives an incoming message at the Ingress Gateway, before processing the message, the data sends to the DD.
• After processing the request at DD, the request is sent towards the SEPP microservices which forward to the Egress Gateway.
• After the message has been processed at the Egress Gateway, the data is again sent to DD before being sent to the consumer NF.
• Similarly, when a response is received from end consumer NF, it is received at the Egress Gateway.
• When the Egress Gateway receives the response, it sends the message to DD, which processes it and sends to the SEPP microservice.
• The response, when received at Ingress Gateway is processed and then sent towards DD before before it is sent to the consumer NF.
• The messages received at DD are correlated against the correlation-id parameter that gateways add.
• The correlation-id parameter is either extracted from the "x-request-id" header present in the incoming request/response or is autogenerated by gateways, if the header is not present.

When an incoming request or response is received at the gateway, the header details and body of the message are copied to the DD. Along with these details, additional details about the message (Example: timestamp) are also copied as part of the metadata list.

The following diagram represents the enhancement of selecting the same Kafka partition for the messages of the same transaction type:

Figure 3-55 Same Kafka partition for the messages of the same transaction type

The following are the descriptions of the attributes that are copied to the DD (Data Director) as part of metadata:

Table 3-33 Attributes Copied to DD

Attribute name	Data type	Description	Source of data
correlation-id	String	This is a mandatory parameter. This is a unique identifier for the message (both request and response). Below are the possibilities to populate this field in the metadata: If the x-request-id header is present in the message, then the correlation id shall be extracted from this field. If this header is not present, then the below processing shall be done: At IGW: As soon as the message is received and the x-request-id header is not present, then IGW shall generate a UUID, and set correlation-id to this UUID. Copy the message towards DD with correlation id in metadata, but no x-request-id header. After copying the message to DD, this custom header shall be added by IGW to the incoming request. For response coming from the backend, IGW shall again pick the same UUID as set in the request from its context and set in the metadata. For response, it does not matter if the x-request-id header is present or not, as IGW already has it in its request context which is re-used while processing the corresponding response. At EGW: After receiving a request from the backend, if the x-request-id header is not present, EGW shall first generate a UUID and set correlation-id metadata to this UUID, and also add the x-request-id header to the request message. Then it should copy the message to DD and then send it out on the wire. In the response received from outside NF, EGW shall reuse the UUID it generated during the request and set it to correlation-id of response metadata. EGW need not check or add the x-request-id header in the response.	x-request-id header or autogenerate
consumer-id	String	This is an optional Parameter. 5G NF Instance ID of the NF originated the received message For IGW, this should be peer-nf-id For EGW, this should be self-nf-id For Notifications at EGW, this should be peer-nf-id	peer-nf-id for IGW is the NF-Instance ID extracted from the user-agent header if available in the request. User-Agent: <NF Type>-<NF Instance ID> <NF FQDN> self-nf-id will be extracted from Helm configurations (nfInstanceId).
producer-id	String	This is an optional Parameter. 5G NF Instance ID of the next destination NF	self-nf-id will be extracted from Helm configurations (nfInstanceId). Note: EGW doesnt populate producer-id.
consumer-fqdn	String	This is an optional parameter. It is the FQDN of the orginating NF. For IGW, this should be peer-nf-fqdn. For EGW, this should be self-nf-fqdn. For Notifications at EGW, this should be peer-nf-fqdn.	peer-nf-fqdn for IGW is the NF-FQDN extracted from user-agent header. User-Agent: <NF Type>-<NF Instance ID> <NF FQDN> self-nf-fqdn will be extracted from Helm configurations (nfFqdn). peer-nf-fqdn for EGW is extracted from 3gpp-sbi-target-apiroot header.
producer-fqdn	String	This is an optional parameter. FQDN of the destination NF For EGW, this should be peer-nf-fqdn For IGW, this should be self-nf-fqdn For Notifications at EGW, this should be self-nf-fqdn	peer-nf-fqdn is extracted from3gpp-sbi-target-apiroot header. self-nf-fqdn will be extracted from Helm configurations (nfFqdn).
hop-by-hop-id	String	This is an optional parameter. This should be set if it is present in the request/response headers.	hop-by-hop-id header (this header is added by SCP).
source-ip	String	This is an optional parameter. The origination IP address of the message.	NA
destination-ip	String	This is an optional parameter. The destination IP address of the message.	NA
source-port	String	This is an optional parameter. The port that receives the message or response from the destination. TCP port of the NF on the origination IP address.	NA
destination-port	String	This is an optional parameter. The port that delivers the message or response to the source. TCP port of the NF on the destination IP address.	NA
timestamp	String	This is a mandatory parameter. Identifies the timestamp when the message arrives at the producer.The timestamp format would be long and in nanoseconds.	The time at which the message is created with nanoseconds precision. Example: 1656499195571109210 nanoseconds
message-direction	String	This is a mandatory parameter. The direction of the message can be either incoming or outgoing.	Parameter to indicate whether a message is an ingress to or egress from NF. It can be indicated by putting the traffic feed trigger point name. RxRequest (Ingress Request) TxRequest (Egress Request) RxResponse (Egress Response) TxResponse (Ingress Response)
feed-source	FeedSource	This is a mandatory parameter. Information about the NF details. Note: The details are given in the following table.	The details are given in the following table.

FeedSource

Table 3-34 FeedSource

Attribute name	Data type	Description	Source of data
nf-type	String	This is a mandatory parameter. Identifies a type of producer NF.	The information from the Helm configuration from the parameter global.nfTypeMsgCpy. If the NFs haven't configured this, then unknown would be attached as a value.
nf-instance-id	String	This is an optional Parameter. Identifies a producer NF Instance.	The information from Helm configuration from the parameter global.nfTypeMsgCpy.
nf-fqdn	String	This is an optional Parameter. Identifies a producer NF FQDN.	The information from Helm configuration from the parameter global.nfFqdn.
pod-instance-id	String	Identifies a producer NF's pod. This is the unique identifier or name assigned to the pod. This is an optional parameter.	NA

Managing SEPP Message Feed Feature

Enable

You can enable SEPP Message Feed feature using the following Helm configuration:

1. Open the ocsepp_custom_values_<version>.yaml file.
2. To enable feature on PLMN Ingress Gateway, in the PLMN Ingress Gateway section, set messageCopy.enabled to true.
3. To enable feature on N32 Ingress Gateway, in the N32 Ingress Gateway section, set messageCopy.enabled to true.
4. To enable feature on PLMN Egress Gateway, in the PLMN egress Gateway section, set messageCopy.enabled to true.
5. To enable feature on N32 Egress Gateway, in the N32 Egress Gateway section, set messageCopy.enabled to true.
6. To enable copy message payload as well, in the sections mentioned in steps 2-4, set messageCopy.copyPayload to true.
7. If you want to disable security protocol settings on messageCopy set messageCopy.security.enabled to false.
8. set Kafka.bootstrapAddress to DD service and port, where port will be 9092 (security disabled).
9. set keybasedKafkaProducer to true on all or required gateway if we want to enable the functionality of message copy on same partition.
10. Skip to step 12 if security is disabled.
11. If messageCopy.security.enabled is true, do the following steps:
    1. Ensure DD is deployed prior to deploying SEPP.
    2. Follow the NF Integration Steps for generating Gateway secrets.
       1. Copy the certificate from ssl_certs/demoCA/cacert.pem ( BEGIN CERTIFICATE to END CERTIFICATE).
       2. Copy the sepp-certificates in a temperory new folder.
       3. Edit the existing caroot.cer to append the cacert.pem in the following manner:

          
          -----BEGIN CERTIFICATE-----
          <existing caroot-certificate content>
          -----END CERTIFICATE-----
          --------
          -----BEGIN CERTIFICATE-----
          <DD caroot-certificate content>
          -----END CERTIFICATE-----

       4. Create a new file sasl.txt in the seppcertificates folder and run the following:

          echo (JAAS secret password) > sasl.txt

       5. Run the following command to generate the Gateway secret:

          
          kubectl create secret generic ocsepp-plmn-secret --from-file=ecdsa_private_key.pem --from-file=rsa_private_key_pkcs1.pem --from-file=trust.txt --from-file=key.txt --from-file=sasl.txt --from-file=caroot.cer --from-file=rsa_certificate.crt --from-file=ecdsa_certificate_pkcs1.crt --from-file=ocsepp.cer -n <namespace>
           
          kubectl create secret generic ocsepp-n32-secret --from-file=ecdsa_private_key.pem --from-file=rsa_private_key_pkcs1.pem --from-file=trust.txt --from-file=key.txt --from-file=sasl.txt --from-file=caroot.cer --from-file=rsa_certificate.crt --from-file=ecdsa_certificate_pkcs1.crt --from-file=ocsepp.cer -n <namespace>

    3. Set security.saslConfiguration.username to username used to configure DD.
    4. Set the security.saslConfiguration.password.k8NameSpace where DD is deployed.
    5. set the parameter security.protocol to SSL or SASL_SSL.
    6. Set the parameter Kafka.bootstrapAddress to DD service and port which have port number 9093(security enabled, SSL mode) or 9094 ( security enabled SASL_SSL mode).
12. Save the file.
13. Run Helm install. For more information about installation procedure, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy Installation, Upgrade, and Fault Recovery Guide.

Note:

Currently SEPP does not support dynamic reloading of certificates for Kafka.

If you are enabling this parameter after SEPP deployment, run helm upgrade. For more information about the upgrade procedure, see Oracle Communications Cloud Native Core Security Edge Protection Proxy Installation, Upgrade, and Fault Recovery Guide.

Configure

You can configure the feature using Helm:

Configure the following SEPP parameters to configure nfType, nfFQDN, and nfInstanceId.

You can configure the feature using Helm:

Configure the following SEPP parameters to configure nfType, nfFQDN, and nfInstanceId.

ocsepp_custom_values_<version>.yaml file.

global:  
nfType:SEPP
  nfFQDN: <FQDN address>
    nfInstanceId: < NF Instance ID>

Sample Ingress Gateway Configuration:

messageCopy:
    enabled: false
    copyPayload: false
    topicName: message.copy
    ackRequired: false
    retryOnFailure: 0
    retryBackoffTime: 100 #in milliseconds
    requestTimeout: 100 #in milliseconds
    keybasedKafkaProducer: false
    security:
      enabled: true
      protocol: SASL_SSL
      tlsVersion: TLSv1.3
      saslConfiguration:
        userName: test
        password:
          k8SecretName: message-copy-secret #relevant n32 or plmn secret
          k8NameSpace: ocegress
          fileName: password.txt
    threadPoolConfigurations:
      coreSize: 16
      maxSize: 16
      queueCapacity: 4200
  #kafka-details
  kafka:
    bootstrapAddress: 10.75.175.246:30608

Sample Egress Gateway Configuration:

messageCopy:
    enabled: false
    copyPayload: false
    topicName: message.copy
    ackRequired: false
    retryOnFailure: 0
    retryBackoffTime: 100 #in milliseconds
    requestTimeout: 100 #in milliseconds
    keybasedKafkaProducer: false
    security:
      enabled: false
      protocol: SASL_SSL
      tlsVersion: TLSv1.3
      saslConfiguration:
        userName: test
        password:
          k8SecretName: message-copy-secret
          k8NameSpace: ocegress
          fileName: password.txt
    threadPoolConfigurations:
      coreSize: 16
      maxSize: 16
      queueCapacity: 4200
  #kafka-details
  kafka:
    bootstrapAddress: 10.75.175.246:30608

Observe

Following are the SEPP Message Feed feature specific metrics:

• oc_ingressgateway_msgcopy_requests_total
• oc_ingressgateway_msgcopy_responses_total
• oc_ingressgateway_dd_unreachable
• oc_egressgateway_msgcopy_requests_total
• oc_egressgateway_msgcopy_responses_total
• oc_egressgateway_dd_unreachable

Following are the SEPP Message Feed feature specific KPIs:

• Total Requests Data sent towards DD for Ingress Gateway
• Total Ack received from DD for Requests for Ingress Gateway
• Total Requests Data sent towards DD for Egress Gateway
• Total Ack received from DD for Requests for Egress Gateway

For more information on SEPP Message Feed feature related SEPP Metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following:

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

3.2.30 Hosted SEPP Feature

General Description

This section provides a general overview of the Hosted SEPP Feature.

Background

SEPP is deployed by both Mobile Network Operators (MNO) and Roaming Hub providers. MNOs deploy SEPP acting as 3GPP 5G SEPP NF which enables inter-PLMN communication between two networks through N32 interface. Oracle SEPP can be deployed in either of the two modes, that is, functionality of 5GC SEPP NF or Roaming Hub. Roaming Hub providers are able to host 5GC SEPP NF functionality for few of the MNOs and host Roaming Hub functionality for rest of the MNOs. All the Remote SEPPs that are connected to the Roaming Hub are allowed to communicate with each other.

Figure 3-56 Remote SEPPs Connected to Roaming Hub

Hosted SEPP

Selective routing was not supported by Roaming Hub phase 1. The Hosted SEPP functionality supports selective routing between Remote SEPP Sets. There are operators who do not have a dedicated SEPP for each of the roaming partners. They can approach an aggregator to enable them to have bilateral roaming agreements on their behalf with the roaming partner. These SEPPs are for the aggregator and may be shared with other MNOs and can connect to multiple partners. Smaller operators who have roaming agreements with a lot of partners have a challenge in managing roaming connections. Additionally, they would prefer to have a lesser OPEX by not having to invest in multiple SEPPs. They would reach out to aggregators who would assist in managing the connections. This brings the following simplification for them, by delegating roaming traffic to external Roaming Hub provider (shown as HO1 in picture below). HO1 hosts all the roaming agreements on behalf of PLMNs.

Figure 3-57 Hosted SEPP

Feature Overview

The following diagram represents the overview of Hosted SEPP functionality.

Figure 3-58 Hosted SEPP Overview

Connectivity Between Remote SEPP Sets Allowed by Hosted SEPP:

Table 3-35 Connectivity Between Remote SEPP Sets Allowed by Hosted SEPP

Consumer Remote SEPP Set	Producer Remote SEPP Set	Allowed – Yes/No
Remote SEPP Set 1	Remote SEPP Set 2	YES
Remote SEPP Set 1	Remote SEPP Set 3	YES
Remote SEPP Set 1	Remote SEPP Set 4	YES
Remote SEPP Set 1	Remote SEPP Set 5	NO
Remote SEPP Set 2	Remote SEPP Set 1	YES
Remote SEPP Set 2	Remote SEPP Set 3	NO
Remote SEPP Set 2	Remote SEPP Set 4	YES
Remote SEPP Set 2	Remote SEPP Set 5	YES
Remote SEPP Set 3	ANY	NO
Remote SEPP Set 4	ANY	NO
Remote SEPP Set 5	ANY	NO

• Hosted SEPP can connect to multiple Remote SEPP Sets.
• Selective routing is allowed from cSEPP (Remote SEPP Set 1, Remote SEPP Set 2) to pSEPP ((Remote SEPP Set 3, Remote SEPP Set 4, and Remote SEPP Set 5).
• Hosted SEPP, while not in the physical network of the partner, or can be in the trust boundary of the partner.
• Global Error Response can be configured on the Hosted SEPP, if routing is not allowed to remote SEPP.

You can configure the Remote SEPP Set in accordance with the connectivity mentioned in the table. Each of the Remote SEPPs should have an associated Remote SEPP Set. Consumer Remote SEPP Set should be configured with the "AllowedProducerRemoteSEPPSets". This field should contain the list of the Producer Remote SEPP Sets which are allowed from the consumer. For example : PSEPP-1 Remote SEPP Set should have the list containing (PSEPP-3 and PSEPP-4) Remote SEPP Sets.

Configuration limit for Hosted SEPP:

The following table indicates the configuration limit for Hosted SEPP:

Table 3-36 Configuration Limit for Hosted SEPP

Deployment	Max Remote PLMNs	Max PLMNs per Remote SEPP	Max Local PLMNs (Self PLMN)
Hosted SEPP	900	900	900

Configuration Work flow

Hosted SEPP feature can be enabled through REST APIs or through CNC Console Allowed P-RSS Validation feature option. Hosted SEPP provides the flexibility to selectively route from one SEPP to the other SEPP. A new attribute has been introduced in the RemoteSEPPSets configuration, that is "AllowedProducerRemoteSeppSets", to decide if the source Remote SEPP Set can send the traffic to destination Remote SEPP Set or not. If the destination Remote SEPP Set is in the list of the source RSS "AllowedProducerRemoteSEPPSets", then only source SEPP can send the traffic to the destination Remote SEPP Set. For example:

curl -v http://127.0.0.1:9090/sepp-configuration/v1/remoteseppset -d '{
    "name": "csepp", "primary": "remote", "allowedListName": "Default",
    "allowedProducerRemoteSeppSets" : ["psepp1,psepp2"] }' -H 'Content-Type:application/json' -X
    POST

Source Remote SEPP Set

Here, Remote SEPP Set (csepp) has two allowedProducerRemoteSeppSets "psepp1,psepp2" in the list. Therefore, Remote SEPP Set-csepp can send the traffic to the Remote SEPP Set(psepp1) and Remote SEPP Set (psepp2) only. Note that vice-versa is not applicable in this scenario. Remote SEPP Set(psepp), still cannot send the traffic to the Remote SEPP Set(csepp) if not configured.

Note:

Remote SEPP Operators (in SEPP mode) need to configure the combined (incoming and outgoing) PLMN-ID List in the remote profile while establishing TLS handshake with Hosted SEPP.

In case of Hosted SEPP, consumer Remote SEPP shall be a part of a Remote SEPP Set as the selective routing is applicable between Remote SEPP Sets.

Managing Hosted SEPP Feature

Enable

You can enable the Hosted SEPP feature using the CNC Console or REST API.

Prerequisite: The parameter nrfClientEnabled must be set to false in the custom values.

• Enable using REST API: Set enabled to true in Hosted SEPP REST API.

  '{
    "hostedSepp": {
      "enabled": true
   
        }
  }'

  For more information about API path, see Oracle Communications Cloud Native Core Security Edge Protection Proxy REST Specification Guide.
• Enable using CNC Console: In the CNC Console GUI, from the left navigation menu, navigate to SEPP and then click System Options. Select Allowed P-RSS Validation Options. Set Enable Allowed P-RSS Validation as True or False on the right pane.
  More details about CNC Console Configurations, see Configuring SEPP using CNC Console section.

Note:

nrfClientEnabled parameter is used to enable the Roaming Hub Mode as Hosted SEPP is applicable for Roaming Hub Mode only.

Configure

You can configure the feature using REST API and CNC Console:

• Configure using REST API: Perform the feature configurations as described in the Remote SEPP Set section in Oracle Communications Cloud Native Core Security Edge Protection Proxy REST Specification Guide.
• Configure using CNC Console: Perform the feature configurations as described in Configuring SEPP using CNC Console.

Observe

Following are the Hosted SEPP feature specific metrics:

• ocsepp_allowed_p_rss_routing_failure_total

Following are the Hosted SEPP feature specific KPIs:

• CN32F Allowed P-RSS Validation Failure Count
• PN32F Allowed P-RSS Validation Failure Count

For more information on Hosted SEPP feature related SEPP Metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following steps:

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

3.2.31 Steering of Roaming (SOR) feature

SOR is deployed as a roaming management solution intended for optimizing roaming cooperation between operators. It allows flexible network selection management for outbound roamers to stimulate an appropriate roaming network choice for subscribers.

SEPP supports the SOR feature to provide better roaming experience to the customers. With this feature, instead of connecting to the required NF, SEPP sends the request to SOR. SOR either connects to the required subscriber or returns the location of the required subscriber to the home SEPP.

Note:

This feature is not applicable to ASM based deployments

The following diagram represents the overview of SOR functionality:

Figure 3-59 SOR Functionality

Here,

1. AMF initiates request towards vSEPP for roaming subscriber.
2. vSEPP forwards the request towards the hSEPP.
3. Hsepp checks method type and RURI (request URI) and if it matches, then forwards the request to the SOR platform.
4. Based on the response, hSEPP forwards the request to the UDM.

The SOR platform receives the standard SBI messages as the input to decide the redirection. The SOR platform responds with a standard HTTP/2 defined response code for redirection.

The SOR platform can either send a response to the SEPP or can directly forward the request to the required UDM. The customer can choose one of the two modes.

Based on the redirection of response from SOR platform, the two modes are:

• Redirection Disabled Mode (Passive Mode)
• Redirection Enabled Mode (Active Mode)

Redirection Disabled Mode

In this mode, SOR automatically connects to the required subscriber. In this case, producer SEPP receives the required response from the SOR Server and there is no redirection logic is applied at SEPP level. In this mode SEPP does not support redirection codes 3xx.

Figure 3-60 Redirection Disabled Mode

Here, SOR platform is acting as a front end. Hence, the search time is less and the SOR platform does the load balance.

Redirection Enabled Mode

In this mode, SOR returns the location of the required subscriber to the home SEPP. In this mode, the producer SEPP receives the 3xx redirection http status code. If it matches the redirection code configured at CNC Console or REST API, then producer SEPP reads the location header and connects to the producer NF. In this mode, configuring SOR is easier.

Figure 3-61 Redirection Enabled Mode

Managing Steering of Roaming (SOR) Feature

Enable

You can enable the SOR feature using the CNC Console or REST API.

Enable using REST API

Set enabled to true in SOR REST API.

{
  "enabled": true,
  "retryToProducer": true,
  "redirection": {
    "enabled": true,
    "codes": "308"
  },
  "servers": [
    {
      "priority": "PRIMARY",
      "httpScheme": "http",
      "sorFqdn": "service-nodejs-2-mnc100-mcc111-3gppnetwork-org.adity-sepp2",
      "sorPort": "7070",
      "apiPrefix": "sor",
      "serverHeader": "SOR-service-nodejs-2-mnc100-mcc111-3gppnetwork-org.adity-sepp2"
    }
  ],
  "retryWait": {
    "retryAltSor": false,
    "retryTime": 1000,
    "retryCount": 0
  },
  "httpCodes": {
    "errorCodes": "501",
    "exceptions": "java.util.concurrent.TimeoutException"
  },
  "errorConfiguration": {
    "errorCodesToConsumer": "408",
    "errorMessageToConsumer": "Timeout at SOR"
  }
}

For more information about API path, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy REST Specification Guide.

Enable using CNC Console

1. In the CNC Console GUI, from the left navigation menu, navigate to SEPP and then click SOR.
2. The Option appears underneath.
3. Click Option, the option screen appears at the right pane. The SOR Feature details are available in the screen.
4. Click Edit icon to modify the Option. The Edit Option page appears.
5. Set SOR Enabled to True on the right pane.

More details about CNC Console Configurations, see Configuring SEPP using CNC Console section.

Configure

You can configure the feature using REST API and CNC Console.

• Configure using REST API: Perform the feature configurations as described in SOR and SOR Config Allowed List REST APIs in Oracle Communications Cloud Native Core, Security Edge Protection Proxy REST Specification Guide.
• Configure using CNC Console: Perform the feature configurations as described in Configuring SEPP using CNC Console.

Observe

Following are the SOR feature specific metrics:

• ocsepp_pn32f_sor_requests_total
• ocsepp_pn32f_sor_responses_total
• ocsepp_pn32f_sor_retry_to_producer_requests_total
• ocsepp_pn32f_sor_back_to_consumer_responses_total
• ocsepp_pn32f_sor_failure_total
• ocsepp_pn32f_sor_timeout_failure_total

Following are the SOR feature specific KPIs:

• Pn32f to SoR Request count total
• SoR to Pn32f Response count total

For more information about metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following:

1. Collect the logs and Troubleshooting Scenarios: For more information on how to collect logs and troubleshooting information, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

3.2.32 Rate Limiting for Ingress Roaming Signaling per Remote SEPP Set

Overview

This feature provides ingress request rate limiting on N32 Interface based on Remote SEPP Set to throttle messages from the Remote SEPP sending more than configured limit for the Remote SEPP Set.

There can be scenarios where the flood of messages at Remote SEPP Set level need to be controlled. With this feature, SEPP secures the network when aggregated traffic at the Remote SEPP level exceeds the allowed traffic rate limit.

If the traffic exceeds the allowed traffic rate limit, SEPP does not process the traffic and responds with an error code. The rate limiting functionality at the SEPP allows an operator to configure the acceptable traffic rate from a consumer NF instance.

SEPP enables users to configure the maximum number of incoming messages at a given duration.

Algorithm

The Rate Limiting for Ingress Roaming Signaling per Remote SEPP Set feature is implemented using customised Bucket4j which uses TokenBucket Algorithm.

The following is the token bucket algorithm:

• Token bucket algorithm processes messages only if there are tokens in the bucket.
• Bucket is filled with a configurable rate during token consumption or asynchronously.
• Tokens are removed from bucket on message processing.
• The following four configurations are required:
  • Bucket Capacity - Bucket size defined the capacity to handle traffic burst.
  • Refill Rate - Tokens (number of) which should be added to refill the bucket.
  • Refill Duration - to decide how frequently to refill bucket.
  • Request Token - to define the batch size of token requested from the corresponding bucket. It is recommented to have the Request Token value between 3 to 5% of the refill rate.
• Tokens and duration defines the traffic rate.

Figure 3-62 Token Bucket Algorithm

The above algorithm shows Ingress Rate limiting for message received from three RSS; RSS 1, RSS 2, and RSS 3.

When the message is received at N32 Ingress Gateway, if the Ingress rate limiting feature is not enabled for any RSS, then message is simply forwarded from that RSS. In our example, Ingress rate limiting feature is not enabled for RSS 3 and enabled for RSS 1 and RSS 2, So message coming from RSS 3 will be forwarded.

Now different buckets will be created for both RSS 1 and RSS 2 as per user configuration of bucket capacity and request token.

In above case, request token is set to 2 and from request token, RSS to token remaining mapping is filled. In this mapping one message is processed (shown in pink colour with a cross inside) and one token (with red colour) in RSS to token remaining mapping for RSS 1 is still remaining. When message from RSS 1 is processed, It is checked if there are enough tokens present in RSS to token remaining mapping for RSS 1. Since there are 2 tokens available, the message is forwarded.

When message from RSS 2 is processed, It is checked if there are enough tokens present in RSS to Token remaining mapping for RSS 2. Since there no tokens available for RSS 2, this message will be rejected with user configurable status code and title.

Detailed Description

The Rate limiting for Ingress Roaming Signaling per Remote SEPP Set feature protects the network from unsecured NF consumers that flood the SEPP microservices with excessive requests.

The following diagram represents the rate limiting for ingress roaming signaling per Remote SEPP Set feature:

Figure 3-63 Rate limiting for Ingress Roaming Signaling per Remote SEPP Set Architecture

In the above diagram, the ingress rate limiting per Remote SEPP Set feature is enabled on the Producer SEPP (PSEPP) N32 Ingress Gateway with a capacity of 1500, 1000, and 500 requests with one second duration for Consumer SEPP (CSEPP 1), CSEPP 2, and CSEPP 3. The requests are initiated from the customer NF at initiator side which passes through the Consumer SEPP and reach to the Producer SEPP N32 Ingress Gateway.

If the incoming requests from CSEPP 1, CSEPP 2, and CSEPP 3 on N32 Ingress Gateway of Producer SEPP are more than the configured capacity of 1500, 1000 and 500 request per second, the requests above the configured value are rejected with an error response as configured by the user. In the above example, the consumer NFs are generating 2000 TPS, 1800 TPS and 500 TPS and as per the capacity set at Producer SEPP N32 Ingress Gateway, 500 and 800 requests are rejected respectively with an configured error response.

Managing Rate Limiting for Ingress Roaming Signaling per Remote SEPP Set Feature

Enable

You can enable the feature using the Helm parameter and CNC Console or REST API.

Note:

Rate Limiting for Ingress Roaming Signaling per Remote SEPP Set feature is disabled by default.

To enable the feature, perform the following steps:

1. In the Yaml file:
   Set the rssRateLimiting.enabled parameter to true in the N32 Ingress Gateway section of ocsepp-custom-values- <version>.yaml file.

   The following parameters are to be configured:
   ###In the IGW section 
    
   rateLimiting:
   enabled: true 
     rssRateLimiting:
     enabled: false

2. To configure using CNC Console or REST API:

CNC Console

1. In the CNC Console GUI, from the left navigation menu, navigate to SEPP and then click Ingress Rate Limiting.
2. Select Remote SEPP Set which is defined under Ingress Rate Limiting screen.
3. The Option appears underneath.
4. Click Option, the option screen appears at the right pane. The Ingress Rate Limiting Feature details are available in the screen.
5. Click Edit icon to modify the Option. The Edit Option page appears.
6. Set RSS Ingress Rate Limiting Enabled to True on the right pane.

REST API

Set ingressRateLimitingEnabled as True at the Ingress Rate Limiting REST API. Set ingressRateLimitingEnabled as true in the Remote SEPP Set REST API.

Note:

In CNC Console and REST API, Ingress Rate Limiting feature can be enabled or disabled globally for the complete system at runtime. The Ingress Rate Limiting feature can be enabled for a particular RSS.

• If the Helm parameter rssRateLimiting is set to false, then Ingress Rate Limiting feature is globally disabled.
• If the Ingress Rate Limiting feature is disabled on CNC Console Option screen of Ingress Rate Limiting, then Ingress Rate Limiting feature is globally disabled.
• If it is required to disable or enable Ingress Rate Limiting feature for a particular RSS, then the helm parameter rssRateLimiting and Enable Ingress Rate Limiting option in CNC Console Ingress Rate Limiting feature Option screen must be enabled.

Configure

You can configure the feature using REST API and CNC Console.

• Configure using REST API: Perform the feature configurations as described in Ingress Rate Limiting System Option and Remote SEPP Set REST APIs in Oracle Communications Cloud Native Core, Security Edge Protection Proxy REST Specification Guide.
• Configure using CNC Console: Perform the feature configurations as described in Configuring SEPP using CNC Console.

Observe

Following are the feature specific metrics:

• oc_ingressgateway_rss_ratelimit_total ( Added with three different metric filter status)

Following are the feature specific KPIs:

• Average No of messages discarded for a particular RSS
• Average No of messages accepted for a particular RSS
• Average No of messages for which feature not applied
• Average of all messages by Status
• List of Average number of messages accepted for all RSS
• List of Average number of messages dropped for all RSS

For more information about metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following:

1. Collect the logs and Troubleshooting Scenarios: For more information on how to collect logs and troubleshooting information, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

3.2.33 Georedundancy

Oracle Communications Cloud Native Core, Security Edge Protection Proxy (SEPP) supports georedundancy to ensure high availability and redundancy. It offers a two, three, or four-sites georedundancy to ensure service availability when one of the SEPP sites is down. When SEPP is deployed as georedundant site, all the sites work in an active state and the same data is available at all the sites.

The NFs send service requests to their primary SEPP. When the primary SEPP site is unavailable, the NFs redirect the service requests to the alternate SEPP site. In this case, NFs get the same information from alternate SEPP, and each site maintains and uses its set of configurations.

Figure 3-64 Georedundancy Overview

The prerequisites for georedundancy feature are as follows:

• Each site must configure the remote georedundant SEPP sites' details.
• Georedundancy feature cannot be disabled once enabled on a site.
• Georedundant sites must be time synchronized.
• Georedundant sites must be reachable from NFs or peers on all the sites.

Detailed Description

The specifications for georedundancy feature are as follows:

• All the georedundant sites must have same Helm and REST based configurations except NF Instanced Id, SEPP Endpoint, and port.
• The georedundant SEPP sites must be reachable from NFs or peers on all the sites.
• The same NFs or peers must not communicate to other georedundant SEPP sites simultaneously for the same session.
• When SEPP is deployed in three-site georedundant mode:
  • In case of three-site georedundant mode, NFs or peers can configure the three SEPP instances in Remote SEPP Set as primary, secondary, and tertiary. When the primary instance is available, the NFs send service requests to the primary instance.
  • All the sites register with NRF independently and work in an active state.
  • All SEPP instances share the context data by using the replication service of cnDBtier. This enables service continuity during the failure of any of the sites.
  • The NFs in a given site can discover SEPP instances through NRF.
• When SEPP is deployed in four-site georedundant mode:
  • All the four SEPP instances need to be configured using DNS mechanism in communication between different SEPPs.
  • All the sites work in an active state.
  • All instances share context data using the cnDBTier's replication service to enable service continuity during site failure.
  • When the peer detects the failure of the primary instance, the peer redirects its traffic to the secondary instance while the primary instance remains unavailable until it becomes available again.
  • If the priorities are same for all the SEPP instances, then load sharing can be done between SEPP-SEPP communication on the basis of weight factor.

SEPP supports the following types of georedundant deployments:

3.2.33.1 Two-Site Georedundancy

The following diagram depicts the topology for two-site georedundant SEPP deployment:

Figure 3-65 Two-Site Georedundancy

The two-site georedundancy is established when the cnDBTier at both sites is configured with georedundancy configurations. The cnDBTier provides bi-directional replication between both sites. When the two-sites replication is up and running, the updates done in the database at one site are replicated to the other sites in real time. The changes include creating, changing, or deleting a record.

The benefits of two-site georedundancy are:

• In case of a single site failure, the alternate site takes up the load of the failed site.
• In case of single or dual site failure (or connection failure or any other failure), the SEPP at the active site(s) serves the consumer NFs. For example, in a two-site redundant system with Site 1 and Site 2,
  • If Site1 fails, SEPP at Site 2 serves the Consumer NF of Site 1.
  • If Site2 fails, SEPP at Site 1 serves the Consumers NF of Site 2.

3.2.33.2 Three-Site Georedundancy

The following diagram depicts the topology for three-site georedundant SEPP deployment:

Figure 3-66 Three-Site Georedundancy

In case of three-site georedundancy, bi-directional replication is established from each site to the other two sites. The database updates from each site are replicated to the other two sites over the replication channel.

The benefits of three-site georedundancy are:

• In case of a single site failure, the remaining two sites take up the load of the failed site.
• Each site uses the SQL nodes for active and standby replication channels for high availability of the replication channels.
• In case of single or dual site failure (or connection failure or any other failure), the SEPP in active state serves the consumer NFs. For example, in a three-site redundant system with Site 1, Site 2, and Site 3,
  • If Site 1 fails, SEPP at Site 2 and Site 3 serve the Consumer NF of Site1.
  • If Site 1 and Site 2 fail, SEPP at Site 3 serves Consumer NF of Site 1 and Site 2.

When the three-sites replication is up and running, the updates done in the database at one site are replicated to the other sites in real time. The changes include creating, changing, or deleting a record.

3.2.33.3 Four-Site Georedundancy

The following diagram depicts the topology for four-site georedundant SEPP deployment:

Figure 3-67 Four-site Georedundancy

SEPP supports the four-site georedundant deployment. In case of four-site georedundancy, each site participates in a 4-way replication. The database updates from each site are replicated to the other three sites over the replication channels.

The advantages of four-site georedundancy are:

• In case of a single site failure, the remaining three sites keep establishing the bi-directional replication.
• Requires 6 SQL pods and 3 db-rep-svc at each site.
• Each site uses two SQL nodes for active and standby replication channels for high availability of the replication channels.
• In case of single or dual site failure (or connection failure or any other failure), the SEPP in active state serves the consumer NFs. For example, in a 4-site redundant system with Site 1, Site 2, Site 3, and Site 4,
  1. If Site 1 fails, SEPP at Site 2, Site 3, and Site 4 serve the Consumer NF of Site1.
  2. If Site 1 and Site 2 fail, SEPP at Site 3 and Site 4 serve the Consumer NF of Site 1 and Site 2.
  3. If , Site 2, and Site 3 fail, SEPP at Site4 serves the Consumer NF of Site 1, Site 2, and Site 3.

When the four-site replication is up and running, the updates done in the database at one site are replicated to the other sites in real time. The changes include creating, changing, or deleting a record.

3.2.33.4 Managing the Feature

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

3.2.33.4.1 Prerequisites

To deploy SEPP in a georedundant environment:

1. 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.
2. The Database Replication Channels between the sites must be up. For information about installing cnDBTier and parameters required for setting the Database replication in cnDBTier custom values.yaml, see "Installing cnDBTier" and "Customizing cnDBTier" in Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.
3. Configure MySQL Database, Users, and Secrets. For the configuration procedure, see "Preinstallation Tasks" in Oracle Communications Cloud Native Core, Security Edge Protection Proxy Installation, Upgrade, and Fault Recovery Guide.
4. Deploy SEPP over the replicated cnDBTier sites. For information about installing and deploying SEPP, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy Installation, Upgrade, and Fault Recovery Guide.

3.2.33.4.2 Enable

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 SEPP at the site will act as a standalone SEPP.

Helm Configuration for Database:

Configure the following parameters in the ocsepp-custom values-<version>.yaml file for all four sites:

• global.seppDbName
• global.seppBackupDbName
• global.mysql.primary.host
• global.mysql.primary.port
• global.nameSpace
• global.mysql.primary.host
• global.localProfile.name
• global.localProfile.nfInstanceId

At Site 1:

global:
  # Kubernetes Secret containing DB credentials
 dbCredSecretName: &dbCredSecretNameRef 'ocsepp-mysql-cred'
 
 # NameSpace where secret is deployed
 nameSpace: DEPLOYMENT_NAMESPACE
 mysql:
    primary:
      host: &mySqlHostRef "mysql-connectivity-service.site1"
      port: &mySqlPortRef 3306
  # Name of Sepp database
  seppDbName: &dbNameRef "seppdbSite1DB"
  # Name of Sepp backup database
  seppBackupDbName: "seppbackupdbSite1DB"
 
  nfFqdn: &nfFqdnRef "site1sepp1.inter.oracle.com"
 
 localProfile:
    name: "SEPP-1"
    nfInstanceId: "9faf1bbc-6e4a-4454-a507-aef01a101a06"

At Site 2:

global:
    
  # Kubernetes Secret containing DB credentials
 dbCredSecretName: &dbCredSecretNameRef 'ocsepp-mysql-cred'

 # NameSpace where secret is deployed
 nameSpace: DEPLOYMENT_NAMESPACE  

 mysql:
    primary:
      host: &mySqlHostRef "mysql-connectivity-service.site2"
      port: &mySqlPortRef 3306
  # Name of Sepp database
  seppDbName: &dbNameRef "seppdbSite2DB"
  # Name of Sepp backup database
  seppBackupDbName: "seppbackupdbSite2DB"
 
  nfFqdn: &nfFqdnRef "site2sepp2.inter.oracle.com"
 
 localProfile:
    name: "SEPP-2"
    nfInstanceId: "9faf1bbc-6e4a-4454-a507-aef01a101a07"

At Site 3:

global:
    # Kubernetes Secret containing DB credentials
 dbCredSecretName: &dbCredSecretNameRef 'ocsepp-mysql-cred'

 # NameSpace where secret is deployed
 nameSpace: DEPLOYMENT_NAMESPACE  
 mysql:
    primary:
      host: &mySqlHostRef "mysql-connectivity-service.site3"
      port: &mySqlPortRef 3306
  # Name of Sepp database
  seppDbName: &dbNameRef "seppdbSite3DB"
  # Name of Sepp backup database
  seppBackupDbName: "seppbackupdbSite3DB"
 
  nfFqdn: &nfFqdnRef "site3sepp3.inter.oracle.com"
 
 localProfile:
    name: "SEPP-3"
    nfInstanceId: "9faf1bbc-6e4a-4454-a507-aef01a101a08"

At Site 4:

global:   
         # Kubernetes Secret containing DB credentials  
         dbCredSecretName: &dbCredSecretNameRef 'ocsepp-mysql-cred'    
        # NameSpace where secret is deployed  
         nameSpace: DEPLOYMENT_NAMESPACE  
        mysql:     
          primary:
          host: &mySqlHostRef "mysql-connectivity-service.site4"       
          port: &mySqlPortRef 3306   
# Name of Sepp database   
seppDbName: &dbNameRef "seppdbSite4DB"   
# Name of Sepp backup
      database   seppBackupDbName: "seppbackupdbSite4DB"     
      nfFqdn: &nfFqdnRef "site4sepp4.inter.oracle.com"    
      localProfile:    
         name: "SEPP-4"
         nfInstanceId: "9faf1bbc-6e4a-4454-a507-aef01a101a09"

For more information about configuring the parameters, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy Installation, Upgrade, and Fault Recovery Guide.

Following is the sample configuration at Site named "site1" (SEPPInstanceId: 99faf1bbc-6e4a-4454-a507-aef01a101a07), which is georedundant with Sites, "site2" (SEPPInstanceId: 99faf1bbc-6e4a-4454-a507-aef01a101a07) and "site3" (SEPPInstanceId: 9faf1bbc-6e4a-4454-a507-aef01a101a08):

3.2.33.5 Adding a Site to an Existing SEPP Georedundant Site

This section describes the procedure to add a site to an existing SEPP site.

Prerequisites

1. SEPP connected to a cnDBTier is up and running. This is referred as Site 1 or Site 2.
2. SEPP and cnDBTier versions used for Site 1 and Site 2 installation must be identified and same must be used for adding another site.

Adding a site

1. Install a new cnDBTier. This cnDBTier must act as a georedundant database to the cnDBTier in Site-1 or Site-2. For more information to install a cnDBTier, see Oracle Communications Cloud Native Core cnDBTier User Guide.
2. Verify the replication channel between the cnDBTier sites by sending the following request to the dbMonitor service of both the cnDBTier sites. The responses from both the cnDBTier sites must show the status of replication channel as up:

   curl http://<mysql-db-monitor-service>:8080/db-tier/status/replication/realtime

   Sample command:

   curl http://mysql-cluster-db-monitor-svc:8080/db-tier/status/replication/realtime

   Sample output:

   [{"localSiteName":"Site-1","remoteSiteName":"Site-2","remoteSiteName":"Site-3","replicationStatus":"UP","secondsBehindRemote":
         0}]

3. Create the required secrets to install the Site-2 or Site-3 SEPP in the same namespace as the new cnDBTier installed in step-1, by following the steps described in the "Configuring Kubernetes Secret for Accessing SEPP Database" subsection from "Installing SEPP" chapter in Oracle Communications Cloud Native Core Security Edge Protection Proxy Installation, Upgrade, and Fault Recovery Guide.
4. Run the following command to verify the secret created:

   $ kubectl describe secret <database secret name> -n <Namespace of SEPP deployment>
   

5. Install the Site-2 or Site-3 SEPP using the updated ocsepp-custom values-<version>.yaml file. For more information on installation procedure, see Oracle Communications Cloud Native Core Security Edge Protection Proxy Installation, Upgrade, and Fault Recovery Guide.

   Verify the installation as mentioned in Oracle Communications Cloud Native Core Security Edge Protection Proxy Installation, Upgrade, and Fault Recovery Guide.

6. After the installation is complete, make sure that the "DbReplicationStatusInactive" alert is not raised in the alert dashboard. If the alert exists, verify the above configuration steps. If the alert is not present, it means the DBReplication is up and the georedundant deployment of all sites is successful.

3.2.33.6 Removing a Site from an Existing Georedundant Deployment

This section describes the procedure to remove a site from an existing SEPP deployment.

Prerequisites

1. SEPP connected to a cnDBTier is up and running. This is referred as Site 1 (SEPP-1 and SEPP-2).

Procedure

This section describes the procedure to remove a site (Site1 or Site 2) from an existing georedundant SEPP deployment.

1. Uninstall the SEPP instance from the site to be removed.

   For more information on uninstallation procedure, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy Installation, Upgrade, and Fault Recovery Guide.

2. Remove the DB Replication and the NDBCluster on the site to be removed. For more information on this procedure, see Oracle Communications Cloud Native Core, cnDBTier User Guide.

3.2.33.7 Recovering a Failed Site

This section describes the procedure of recovering a failed site in SEPP deployment.

When any of the four sites is down or replication is broken with other sites, then perform the following procedure to restore the failed site from healthy remote site backup.

Mark the site as FAILED in remote healthy cluster

curl -i  -X POST http://<failed site replication svc IP: port>/db-tier/gr-recovery/remotesite/<failed site name>/failed

HTTP/1.1 200 
Vary: Origin
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
X-Content-Type-Options: nosniff
X-XSS-Protection: 0
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Content-Length: 0
Date: Fri, 19 Apr 2024 08:14:48 GMT

Start recovery of failed site from healthy cluster

curl -i -X POST http://<failed site replication sec IP:port>/db-tier/gr-recovery/site/<failed site name>/grbackupsite/<remote Healthy site name>/start

HTTP/1.1 200 
Vary: Origin
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
X-Content-Type-Options: nosniff
X-XSS-Protection: 0
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Content-Length: 0
Date: Fri, 19 Apr 2024 08:46:13 GMT

Monitor the fault recovery state

curl -i -X GET http://<failed site replication sec IP:port>/db-tier/gr-recovery/site/<failed site name>/status

HTTP/1.1 200 
Vary: Origin
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
X-Content-Type-Options: nosniff
X-XSS-Protection: 0
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Content-Type: application/json
Transfer-Encoding: chunked
Date: Fri, 19 Apr 2024 09:04:41 GMT

{"localSiteName":"<failed site name>","geoReplicationRecoverystatus":"COMPLETED","geoReplicationRecoverystate":"COMPLETED","remotesitesGrInfo":[{"remoteSiteName":"<remote site name1>","replchannel_group_id":"1","gr_state":"COMPLETED"},{"remoteSiteName":"<remote site name2>","replchannel_group_id":"1","gr_state":"COMPLETED"},{"remoteSiteName":"<remote site name3>","replchannel_group_id":"1","gr_state":"COMPLETED"}]}[

For more information about installation and recovery procedures, see Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.

3.2.34 Support for Kubernetes Resource

3.2.34.1 Support for 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, SEPP 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 SEPP pods, and some scope of communications is allowed between the SEPP and pods outside the cluster. The network policies enforce 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 SEPP is applied.

Configure

You can configure this feature using Helm. For information about configuring Network Policy for SEPP Deployment, see Oracle Communications Cloud Native Core, Cloud Native Environment Installation, Upgrade, and Fault Recovery Guide.

Observe

There are no specific metrics, KPIs, and alerts required for the Support of Network Policy functionality.

3.2.34.2 Pod Disruption Budget

Background

Pods are the basic units of Kubernetes and are used to deploy Cloud Native Core (CNC) Network Functions (NFs).

Pod disruption occurs due to voluntary and involuntary disruptions.

Voluntary Disruptions

Voluntary pod disruption occurs when:

• pods are removed from a cluster.
• SEPP worker nodes are drained at the time of cluster upgrade and running pods are evicted from these nodes.
• load balancing of worker nodes is performed by evenly distributing pods among worker nodes.

Involuntary Disruptions

Involuntary pod disruption occurs when:

• the system hardware or software fails.
• SEPP worker nodes are removed accidentally.
• pods are evicted due to insufficient resources on SEPP worker nodes.

Kubernetes has introduced the PodDisruptionBudgets (PDB) concept to manage pod disruption outages in the clusters. PDB is applicable only for voluntary disruptions. It is used to avoid service impact due to voluntary disruption and ensures high availability of NF.

PodDisruptionBudget SEPP Implementation Overview

PodDisruptionBudget (PDB) is a Kubernetes resource that allows you to achieve high availability of scalable application services when the cluster administrators perform voluntary disruptions to manage the cluster nodes. PDB restricts the number of pods that are down simultaneously from voluntary disruptions. Defining PDB is helpful to keep the services running undisrupted when a pod is deleted accidentally or deliberately. PDB can be defined for high available and scalable SEPP services such as cn32f-svc, pn32f-svc, cn32c-svc, pn32c-svc, n32-ingress-gateway, n32-egress-gateway, plmn-ingress-gateway, plmn-egress-gateway, nfmanagement-svc, nfdiscovery-svc, and perf-info services.

It allows safe eviction of pods when a Kubernetes node is drained to perform maintenance on the node. It uses the maxUnavailable parameter specified in the Helm chart to determine the maximum number of pods that can be unavailable during a voluntary disruption. For example, when a maxUnavailable is 25%, pod evictions are allowed as long as no more than 25% of the desired pods are in unhealthy state.

For more information about this functionality, see https://kubernetes.io/docs/concepts/workloads/pods/disruptions/#pod-disruption-budgets.

Default PodDisruptionBudget for SEPP Deployment

Table 3-37 Default PodDisruptionBudget for SEPP Deployment

Microservice	PDB Value Specified (maxUnavailable)
cn32c-svc	25%
pn32c-svc	25%
cn32f-svc	25%
pn32f-svc	25%
config-mgr-svc	Not Applicable
plmn-ingress-gateway	25%
plmn-egress-gateway	25%
n32-ingress-gateway	25%
n32-egress-gateway	25%
app-info	25%
config-server	50%
perf-info	25%
nf-mediation	25%

Managing Pod Disruption BudgetEnable

This feature is enabled automatically if you are deploying SEPP with Release 16.

Configure

You can configure this feature using Helm. For information about configuring PDB, see Oracle Communications Cloud Native Core, Cloud Native Environment Installation, Upgrade, and Fault Recovery Guide.

Observe

There are no specific metrics, KPIs, and alerts required for the support of PDB functionality.

3.2.35 Alternate Routing and Load Sharing based on the DNS SRV Record for Home Network Functions

Overview

SEPP selects SCP and NRF for indirect communication of 5G messages using the static configurations done by the operator. This feature enables SEPP to route the messages to the SCP, NRF or Producer NFs using DNS SRV records, in addition to already existing static manual configuration by the operator.

SEPP supports DNS SRV based selection of SCP, NRF or Producer NFs through Egress Gateway (EGW), which supports Alternate Route Service (ARS). It enables SEPP to resolve the FQDN or Virtual FQDN to alternative FQDNs of 5G NFs. EGW uses the virtual FQDN of NF instances to query the Alternate Route Service and retrieve the list of alternative FQDNs with priorities and weight assigned to each of them. Based on the priorities, EGW selects the NF instances for rerouting attempts and distributes the incoming traffic in proportion to the weight value assigned. If the priorities of the records are same, then the traffic will be load shared among the FQDNs received based on the weight factor.

Using this feature, SEPP performs alternate routing of messages by querying SRV records with the DNS server to find an alternate producer NF and route the service request. SEPP supports load sharing among multiple NRF, SCP, and Producer NFs' records using DNS SRV queries at plmn-egress-gateway. SEPP uses either NF Set or DNS SRV records to perform alternate routing.

Support for Direct and Indirect Communication

The Consumer NF messages are routed through plmn-egress-gateway based on the 3gpp-sbi-target-apiroot header.

In the case of direct communication, the gateway service routes the messages to the FQDN or IP defined in the header. In the case of indirect communication, static peers are defined on the gateway service and the incoming requests are routed to the defined hosts if they match the routing criteria.

Figure 3-68 Direct Communication

Routing to NRF, SCP, and Producer NFs Through DNS SRV

SEPP supports priority and weight based load sharing of the Consumer NFs requests through plmn-egress-gateway. SEPP sends a DNS SRV query request based on the virtual FQDN configured to identify peer NF instances. The DNS server returns the response with the multiple FQDNs associated with the virtual FQDN, and each FQDN can have multiple IP addresses associated to each. Further based on the DNS SRV algorithm defined at the plmn-egress-gateway, it selects the peer with the highest priority. If the priorities are same for multiple FQDN records, then the incoming requests are load shared based on the weight value assigned to them.

Below is the format of SRV records defined at DNS server:

_Service._Proto.Name TTL Class SRV Priority Weight Port Target

_http._tcp.example.com 86400 IN SRV 1 10 80 blr.example.com

In this example, the virtual FQDN "example.com" will return the single FQDN record "blr.example.com" with priority 1 and weight 10.

Similarly, multiple records can be defined against the single virtual FQDN. Each FQDN returned can be resolved to an IP address in the DNS server.

Figure 3-69 Routing to Producer NFs Through DNS SRV

The above diagram represents the routing to Producer NFs Through DNS SRV. The flow of routing is represented by the numbering.

SEPP supports multiple deployments for NFs (Example:SCP) for routing of Consumer NF queries. When SEPP receives a request, it processes the request from Consumer NF based on the API root header configuration. PLMN Egress Gateway (EGW) performs the routing based on the SbiRouting functionality at plmn-egress-gateway and forwards the requests to the peer configuration defined in the route. This process of routing the request between SEPP through SCP is known as indirect communication.

SEPP supports alternate routing and weight based routing (load sharing) for virtual peer instances. In the case of virtual peer instances, SEPP identifies peer SCP instances based on the virtual FQDN and distributes the 5G traffic to NF instances based on DNS SRV algorithm defined at plmn-egress-gateway. Lower the priority, higher is the chance of selection and if multiple instances have same priority, then distribution or load sharing will be based on the weight factor assigned to each of the records. In the case of failures, SEPP also supports alternate routing to the peers based on their priority.

Alternate Route Service uses the DNS SRV records for the resolution of virtual FQDN. PLMN Egress Gateway uses the virtual FQDN of peer instances to query the Alternate Route Service and get the list of alternate FQDNs with a priority and weight assigned to each one of them. The Egress Gateway selects the peer instances for routing or re-routing attempts based on this priority value assigned to the peers and distribute the traffic based on weight value if priorities are same.

The routing can be:

• Priority Based
• Weight Based

Priority Based Routing

In priority based routing, the virtual FQDN configured for SCP instances with different priorities.

Figure 3-70 Priority Based Routing

1. PLMN Egress Gateway (EGW) receives a request from the backend microservice.
2. PLMN EGW maps the request to a route configured with virtual FQDN of SCP. Since the route is configured with virtual FQDN of SCP, the virtual FQDN is resolved to the list of alternate FQDNs.
3. PLMN EGW gets the list of FQDNs from cache data. If cached data has not expired, Step 3 (a) and Step 4 are skipped. If the cache has expired data in it, EGW continues with the Step 3 (a).
   1. EGW calls the Alternate Route Service to resolve virtual FQDN to alternate FQDNs and puts it in the cached memory.
4. PLMN EGW performs the DNS-SRV query using the virtual FQDN & scheme.
   1. EGW caches the resolved virtual FQDN details.
5. PLMN EGW selects the SCP instance based on the priority, and it calls the primary SCP.
6. The call fails if the primary SCP is unavailable.
7. Based on the error codes configured in the route, EGW selects the SCP instance with next priority to initiate a call.
   1. PLMN EGW repeats this step for all available SCP instances in the order of their priority as per the number of reroute attempts configured by the operator.
8. PLMN EGW receives the response.
9. PLMN EGW forwards the response to the backend micro-service as it is received.

Note:

In Step 2, if Static SCP instances are configured instead of virtual FQDN, then Step 3 & Step 4 are skipped and Steps 5 through 9 are followed.

Weight Based Routing or Load Sharing

In weight based routing (Load Sharing) , virtual FQDN configured for SCP instances with same priorities and different weights.

Figure 3-71 Weight Based Routing or Load Sharing

1. PLMN Egress Gateway (EGW) receives a request from the backend microservice.
2. PLMN EGW maps the request to a route configured with virtual FQDN of SCP. Since the route is configured with virtual FQDN of SCP, the virtual FQDN is resolved to the list of alternate FQDNs.
3. PLMN EGW gets the list of FQDNs from cache data. If cached data has not expired, Step 3 (a) and Step 4 are skipped. If the cache has expired data in it, EGW continues with the Step 3 (a).
   1. EGW calls the AlternateRoute Service to resolve virtual FQDN to alternate FQDNs and puts it in the cached memory.
4. PLMN EGW performs the DNS-SRV query using the virtual FQDN and scheme.
   1. EGW caches the resolved virtual FQDN details.
5. PLMN EGW selects the SCP instances based on the weight factor because priorities are same, and it load shares the traffic to SCP instances in proportion to the weight factor defined.
6. The traffic is redistributed to next available peer if the primary SCPs are unavailable.
7. Based on the error codes configured in the route, EGW selects the SCP instance with next priority to initiate a call.
   1. PLMN EGW repeats this step for all available SCP instances in the order of their priority as per the number of reroute attempts configured by the operator.
8. PLMN EGW receives the response.
9. PLMN EGW forwards the response to the backend microservice as it is received.

Note:

In Step 2, if Static SCP instances are configured instead of virtual FQDN, then Step 3 and Step 4 are skipped and Steps 5 through 9 are followed.

Managing Alternate Routing and Load Sharing based on the DNS SRV Record for Home Network Functions

Enable

This section describes the procedure to enable the feature.

This feature is enabled by setting the following helm parameters configurations in the ocsepp_custom_values_<version>.yaml file.

dnsSrvEnabled: true
alternateRouteServiceEnable: true
dnsSrvFqdnSetting.enabled: false
dnsSrvFqdnSetting.pattern: "_{scheme}._tcp.{fqdn}."
configureDefaultRoute: true
sbiRoutingConfigMode: REST
routeConfigMode: REST

The following parameter must also be enabled at nrf-client section under global parameters:

alternateRouteServiceEnable: true

The following parameter must also be enabled at plmn-egress-gateway section under global parameters:

checkAltRouteSvcReady: true

For more information, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy Installation, Upgrade, and Fault Recovery Guide.

Configure

You can configure the feature using REST API.

• Configure using REST API: Perform the feature configurations as described in Egress Gateway REST APIs in Oracle Communications Cloud Native Core, Security Edge Protection Proxy REST Specification Guide.
• Configure using CNC Console: Perform the feature configurations as described in the PLMN Egress Gateway section under Configuring SEPP using CNC Console chapter.

Note:

NRF virtual path route is mandatory to route the intra-plmn request to NRF.

Observe

Following are the feature specific metrics:

• oc_fqdn_alternate_route_total
• oc_dns_srv_lookup_total
• oc_alternate_route_resultset
• oc_configclient_request_total
• oc_configclient_response_total
• oc_egressgateway_sbiRouting_http_responses_total

For more information about metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following:

1. Collect the logs and Troubleshooting Scenarios: For more information on how to collect logs and troubleshooting information, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

3.2.36 Rate Limiting for Egress Roaming Signaling per PLMN

Overview

In some scenarios, SEPP may be forwarding more traffic towards a particular PLMN ID resulting in the producers of that PLMN ID getting overloaded. To control this excess traffic, SEPP has been enhanced to provide egress rate limiting based on PLMN ID, which ensures that the core network is not overloaded with traffic. Using PLMN ID to filter the number of messages limits the traffic towards the network. It prevents network congestion and improves the overall network performance.

This feature allows to configure the egress request rate on N32F interface based on the destination PLMN IDs. This controls the messages sent out from the local SEPP to a Remote SEPP.

With this feature, the number of egress requests to one or more PLMN IDs is restricted based on a configured count using token bucket algorithm. The same bucket is applicable to one or more configured PLMN IDs. The messages are counted based on the destination PLMN ID only and not destination Remote SEPP or Remote SEPP Set.

SBI Messages are discarded based on the 3gpp-Sbi-Message-Priority. Only low priority messages are subject to being discarded. The high priority messages are not discarded even if they breach the egress rate limiting priority threshold. The user can configure the threshold for 3gpp-Sbi-Message-Priority to be used for discarding.

PLMN is identified from 3gpp-Sbi-Target-apiRoot header or :authority header. The :authority header is used only in absence of 3gpp-Sbi-Target-apiRoot header.

Token Bucket Algorithm

This feature is implemented using Bucket4j, which uses Token Bucket Algorithm.

The token bucket algorithm can be described as the following:

• Token bucket algorithm processes messages only if there are tokens in the bucket.
• Bucket is filled with tokens at a user configurable rate during token consumption asynchronously.
• Tokens are removed from the bucket once the messages are processed.
• The following four configurations are required:
  • Bucket Capacity - Bucket size defines the capacity to handle traffic burst.
  • Refill Rate - The number of tokens which should be added to refill the bucket.
  • Refill Duration - It decides how frequently the bucket needs to be refilled.
  • Request Token - It defines the batch size of token requested from the corresponding bucket.
• Tokens divided by refill duration defines the traffic rate.

Detailed Description

The following diagram represents how the egress rate limiting is implemented using token bucket algorithm.

Figure 3-72 Token Bucket Algorithm

The above diagram represents the egress rate limiting for the messages received from four different PLMNS, that is, PLMN 1, PLMN 2, PLMN 3, PLMN 4.

In the above diagram, the user has configured the Bucket Capacity, Refill Rate, Refill Duration, and Request Token for the two Egress Rate Limit lists; Egress Rate Limit1 (ERL1) and ERL2. Two separate buckets are created corresponding to each list.

The "ERL List to Remaining Token Mapping" is populated from the corresponding bucket (for ERL List1 and ERL List2) using number of configured request tokens.

The PLMNs are configured as follows:

• PLMN 1 is configured under ERL List 1; the list has 6 tokens and number of request tokens is set to 2. When the request for PLMN 1 arrives, the "ERL List to Remaining Token Mapping" is populated with 2 tokens and the request consumes one of the available tokens and gets forwarded. One token remains in the mapping.
• PLMN 2 and PLMN 3 are configured under ERL List 2 where corresponding mapping or bucket has no token available. When the requests for PLMN 2 and PLMN 3 are raised, as there are no tokens available, the messages are checked for their priority as follows:
  • Message priority for PLMN 2 (configured as 23 in the example) is less than the configured discard message priority threshold for ERL2 (configured as 24), it is a high priority message and thus it gets forwarded.
  • Message priority for PLMN 3 (configured as 25 in the example) is greater than or equal to the configured discard message priority threshold for ERL2 (configured as 24), it is a low priority message and thus it gets rejected by the rate limit feature with the user configured status code and title.
• PLMN 4 is not configured under any of the ERL lists and thus when the request for PLMN 4 arrives, the rate limit feature is considered as false for this request and thus it gets forwarded.

The following table represents the summary of the algorithm:

Table 3-38 Summary

PLMN	Tokens in ERL List	Message Priority	Rejected/Forwarded
PLMN 1	Token available in ERL1's bucket	Ignore priority	Forwarded
PLMN 2	No token available in ERL2's bucket	High	Forwarded
PLMN 3		Low	Rejected
PLMN 4	No corresponding ERL list is configured	Ignore priority	Forwarded

Note:

The request message priority is derived as follows:

• Check the request for 3gpp-Sbi-Message-Priority header.
• If not present, check for helm configured route message priority.
• If not present, take the default priority.

Implementation

This feature is implemented at PLMN IGW in SEPP mode at the C-SEPP side. This provides egress rate limiting for all the messages originating from Local SEPP based on PLMN IDs. The diagram shows two separate token buckets applicable for Remote SEPP Set 1 and Remote SEPP Set 2. One Remote SEPP Set can cater to multiple PLMNs.

Figure 3-73 Implementation at C-SEPP

Note:

This feature is not applicable to P-SEPP in SEPP mode. The feature is implemented at N32 IGW in Roaming Hub mode.

Managing Rate Limiting for Egress Roaming Signaling per PLMN Feature

Enable

This section describes the procedure to enable the feature. You can enable the feature using the Helm parameters and REST API or CNC Console.

The feature is disabled by default.

This feature is enabled by setting the following Helm parameters configurations in the Ingress Gateway section:

rateLimiting:
  enabled: true
  egressRateLimiter:
    enabled: true

Note:

• In SEPP mode, set the egressRateLimiter.enabled parameter to true in the PLMN Ingress Gateway section of ocsepp_custom_values_<version>.yaml file.
• In Roaming Hub mode, set the egressRateLimiter.enabled parameter to true in the N32 Ingress Gateway section of ocsepp_custom_values_roaming_hub_<version>.yaml file.

For more information, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy Installation, Upgrade, and Fault Recovery Guide.

Perform the following procedure to enable this feature using CNC Console or REST API:

CNC Console

1. In the CNC Console GUI, from the left navigation menu, navigate to SEPP and then click Rate Limiting.
2. Select Engress Rate Limiting which is defined under Rate Limiting screen.
3. The Option and EgressRateLimitingList appears underneath.
4. Click Option the option screen appears at the right pane. The Egress Rate Limiting Feature details are available in the screen.
5. Set Egress Rate Limiting Enabled to True on the right pane.

REST API

Set the egressRateLimitingEnabled as Enabled at the Egress Rate Limiting REST API.

Note:

In CNC Console or REST API, Egress Rate Limiting feature can be enabled and disabled globally for the complete system at run time and this can be enabled or disabled for a particular Egress Rate Limiting List also.

• If the Helm parameters rateLimiting and egressRateLimiter are set to false, then the feature is globally disabled.
• If feature is disabled on CNC Console Option screen or REST API, then the feature is globally disabled.
• If feature is disabled on CNC Console EgressRateLimitingList screen or REST API, then Egress Rate Limiting feature is disabled for that ERL list (group of PLMN IDs).

Configure

You can configure the feature using REST API and CNC Console.

• Configure using REST API: Perform the feature configurations as described in Egress Gateway REST APIs in Oracle Communications Cloud Native Core, Security Edge Protection Proxy REST Specification Guide.
• Configure using CNC Console: Perform the feature configurations as described in Configuring SEPP using CNC Console.

Observe

Following are the feature specific metrics:

• oc_ingressgateway_plmn_egress_ratelimit_total (Added with six different metric filter status)

Following are the feature specific KPIs:

• Average Number of Messages Rejected for a Particular PLMN
• Average Number of Messages Accepted for a Particular PLMN
• Average Number of Messages for which Feature not Applied
• Average of all Messages by Status
• Average Number of Messages Rejected per PLMN
• Average Number of Messages Accepted per PLMN

For more information about metrics and KPIs, see SEPP Metrics and SEPP KPIs sections.

Maintain

If you encounter alerts at system or application levels, see SEPP Alerts section for resolution steps.

In case the alert still persists, perform the following:

1. Collect the logs and Troubleshooting Scenarios: For more information on how to collect logs and troubleshooting information, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

3.3 Deployment Support

The following are the deployment support functionalities of SEPP:

3.3.1 Helm Validation Framework

SEPP supports helm validation framework enhancement.This enahancement is supported to validate the values in a custom_values.yaml file with JSON schemas.

It allows the user to perform the following validations:

Table 3-39 Types of Validation checks

Types of Validation checks	Example
Requirement checks	An API_KEY environment variable is set
Type validation	The image tag is a string such as "1.5" and not the number 1.5
Range validation	The value for a CPU utilization percentage key is between 1 and 100
Constraint Validation	The pullPolicy is IfNotPresent, Always, or Never. The URL has the format http(s)://<host>:<port> custom_values.yaml

The schema is automatically validated while running the following commands:

• helm install
• helm upgrade
• helm lint
• helm template

With Helm 3, user can create a file called values.schema.json which allows to set value requirements and constraints in a single location.

The values.schema.json file is written using the JSON Schemavocabulary. According to json-schema.org, JSON Schema is a vocabulary that allows you to annotate and validate JSON documents.

Example for values.schema.json file.

{
   "$schema": "http://json-schema.org/draft-07/schema",
   "required": [
       "image",
       "serviceType",
       "port"
   ],
   "properties": {
       "image": {
           "type": "object",
           "required": [
               "repository",
               "tag"
           ],
           "properties": {
               "repository": {
                   "type": "string"
               },
               "tag": {
                   "type": "string"
               }
           }
       },
       "serviceType": {
           "type": "string",
           "enum": ["ClusterIP", "LoadBalancer"]
       },
       "port": {
           "type": "integer",
           "minimum": 8080
       }
   }
}

This example provides a schema for the values image.repository, image.tag, serviceType, and port. This can be seen by reviewing the keys under the properties keyword.

This example also uses the required, type, enum, and minimum keywords, which are explained in the following sections.

Required

The required keyword is used to fail chart rendering if specific values are not provided.

Example:

"required": [
       "image",
       "serviceType",
       "port"
   ],

The values listed (“image”, “serviceType”, and “port”) must be provided in order to install or upgrade the chart. If you are try to install this chart without any of these values, you get the following error:

$ helm template validation-test test-chart
Error: values don't meet the specifications of the schema(s) in the following chart(s):
test-chart:
- (root): image is required
- (root): serviceType is required
- (root): port is required

Validating User Input against Constraints

JSON Schema provides several different keywords which can be used for validating user inputs against specific constraints. One common keyword is type, which is used to ensure that the input is a String, Integer, Boolean, Object, or another type.

"image": {
    "type": "object",

 - image: Invalid type. Expected: object, given: string

Another useful keyword to validate user input is enum. This keyword is used for validating against a list of supported inputs. In the values.schema.json example, enum is used to restrict the serviceType to “ClusterIP” and “LoadBalancer”:

   "serviceType": {
          "type": "string",
          "enum": ["ClusterIP", "LoadBalancer"]
      },

If the wrong serviceType is provided, you can see the following error:

$ helm template validation-test test-chart --set serviceType=NodePort
Error: values don't meet the specifications of the schema(s) in the following chart(s):
test-chart:
- serviceType: serviceType must be one of the following: "ClusterIP", "LoadBalancer"

minimum. This keyword is a good way to ensure that integer values are not set below a certain threshold. The below example shows how you can set a minimum value for a port number:

"port": {
    "type": "integer",
    "minimum": 8080
}

If you attempt to install the chart with a port number smaller than 8080, you’ll see the following error:

$ helm template validation-test test-chart --set port=8000
Error: values don't meet the specifications of the schema(s) in the following chart(s):
test-chart:
- port: Must be greater than or equal to 8080/1

There are other keywords which can be used for validating input, including (but not limited to):

• maximum: Set a maximum threshold for a numeric value
• pattern: Set a regex that a value must conform to
• additionalProperties: Determines if the user can provide values that are not defined in the values.schema.json file. By default, users can provide any additional value without restriction, but this would not impact chart rendering if the additional value isn’t used in your templates.

Note:

The helm validation framework is enabled by default for helm v3. To disable the feature, the user has to delete values.schema.json file from the charts folder.

3.3.2 Automated Testing Suite Support

SEPP 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 the 5G NFs. Refer to Oracle Communications Automated Testing Suite User Guide for more information.

3.3.3 Service mesh for intra-NF communication

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

For more information on configuring ASM, see Oracle Communications Cloud Native Core, Security Edge Protection Proxy Installation, Upgrade, and Fault Recovery Guide.