2 Feature Descriptions

This chapter provides a summary of new features and updates to the existing features for network functions released in Cloud Native Core release 3.24.3.

2.1 Automated Testing Suite (ATS) Framework

Release 24.3.0

Oracle Communications Cloud Native Core, Automated Test Suite (ATS) framework 24.3.0 includes the following enhancements:

  • ATS Custom Abort: This feature allows you to gracefully abort the ongoing build directly from the Graphical User Interface (GUI). For more information, see "ATS Custom Abort" section in Oracle Communications Cloud Native Core, Automated Test Suite Guide.
  • ATS Health Check: This feature allows you to evaluate the health of the ATS deployment by performing several checks after installation to ensure that all components are functioning properly. For more information, see "ATS Health Check" section in Oracle Communications Cloud Native Core, Automated Test Suite Guide.

2.2 Binding Support Function (BSF)

Release 24.3.0

Oracle Communications Cloud Native Core, Binding Support Function (BSF) 24.3.0 includes the following enhancements:

  • Logging Support for Error Response in BSF: BSF sends error responses to consumer NFs due to some exceptions, such as signaling, validations, and internal errors. These error responses have payloads containing the problem title, status, details, and cause of the error that are used to investigate the error. BSF has been enhanced to support logs for the error responses. For more information, see "Logging Support for Error Response in BSF" section in Oracle Communications Cloud Native Core, Binding Support Function User Guide.
  • Support for TLS in Diameter Gateway: BSF uses Diameter Gateway to establish secured connections with consumer NFs and producer NFs, respectively. These communication protocols are encrypted using Transport Layer Security (TLS). For more information, see "Support for TLS Using Diameter Gateway" section in Oracle Communications Cloud Native Core, Binding Support Function User Guide.
  • BSF Message Feed for Monitoring: In order to enable correlation of the internal and external (request/response) messages for all the transactions initiated by the producer and consumer NFs, BSF allows to copy the messages at Ingress and Egress Gateways. The analysis of these messages enable NFs to integrate with external 5G SBI monitoring system for call tracing/tracking and live debugging. For more information, see "BSF Message Feed for Monitoring" section in Oracle Communications Cloud Native Core, Binding Support Function User Guide.

2.3 Cloud Native Environment (CNE)

Release 24.3.3

Oracle Communications Cloud Native Core, Cloud Native Environment (CNE) 24.3.3 has been updated with the following enhancement:

CNLB: Multus Thick Plugin: In this release, Multus thin plugin is replaced with Multus thick plugin. As part of this change, for all new CNE installations with CNLB-enabled option, Multus thick plugin also gets installed. It is highly recommended to use Multus thick plugin based release for CNLB-based CNE deployments.

CNE release 24.3.3 and above support Multus Thick Plugin.

Release 24.3.2

There are no new features or feature enhancements in this release.

Release 24.3.1

There are no new features or feature enhancements in this release.

Note:

This is a maintenance release to incorporate code changes to support seamless upgrade from this release. These code changes do not have any impact on the performance or functioning of CNE.

Release 24.3.0

Oracle Communications Cloud Native Core, Cloud Native Environment (CNE) 24.3.0 includes the following enhancements:

  • Traffic Segregation: Cloud Native Load Balancer (CNLB) Support for BareMetal: In the previous release, CNE provided Cloud Native Load Balancer (CNLB) for managing networks used for ingress and egress traffic, as an alternate to the existing LBVM, lb-controller, and egress-controller solution. This feature was supported for vCNE deployments (OpenStack and VMware). In this release, CNE extends CNLB support for BareMetal deployments. CNLB supports two ways to achieve network segregation in BareMetal deployments:
    • Using bond0 on hosts
    • Using VLANs on hosts

    CNE continues to support MetalLB and ToR based network segregation in BareMetal deployments. You can enable or disable this feature only at the time of a fresh CNE installation. For more information about enabling and configuring this feature for BareMetal, 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.

  • Floating IP Support for OpenStack API: Floating IPs are additional public IP addresses that are associated to instances such as control nodes, worker nodes, Bastion Host, and LBVMs. Floating IPs can be quickly re-assigned and switched from one instance to another using API, thereby ensuring high availability and less maintenance. In the previous releases, CNE supported only fixed IP addresses for OpenStack deployments. With this feature, CNE provides an option to associate floating IP addresses to all control nodes, worker nodes, Bastion Host, and LBVMs. For more information about this feature, see the "Enabling or Disabling Floating IP" section Oracle Communications Cloud Native Core, Cloud Native Environment Installation, Upgrade, and Fault Recovery Guide.
  • Support for TLS: With this feature, CNE extends its support for Transfer Layer Security (TLS) 1.3. In this release, the minimum supported TLS version for CNE internal and external communication is TLS 1.2. This means that CNE 24.3.0 will support both TLS 1.2 and TLS 1.3. However, in the upcoming releases, CNE will end its support for TLS 1.2 and support only TLS 1.3 for security and governance compliance.
  • New Versions of Common Services: The following common services are upgraded in this release:
    • Helm - 3.15.2
    • Kubernetes - 1.30.0
    • containerd - 1.7.16
    • Calico - 3.27.3
    • Prometheus - 2.52.0
    • HAProxy - 3.0.2
    • Jaeger - 1.60.0
    • Istio - 1.18.2
    • Kyverno - 1.12.5
    • Prometheus Operator: 0.76.0
    To get the complete list of third-party services and their versions, refer to the dependencies_24.3.0.tgz file provided as part of the software delivery package.

    Note:

    CNE constitutes a number of third-party services. For information about these third-party services, refer to the documents of the respective third-party services.
  • GRUB Password Customization: CNE provides the capability to customize the GRUB password to perform maintenance tasks on the boot in every host or member of the cluster. Depending on the type of cluster, you must add or modify the occne_grub_passwordvariable in the hosts.ini or occne.ini file during an installation or upgrade. This variable is mandatory for installation and upgrade. When you customize the GRUB password, ensure that the GRUB password meets the following conditions:
    • Contains at least eight characters.
    • Contains uppercase and lowercase characters.
    • Contains at least one special character: \, %, &, and $. The password can be enclosed with single or double quotes (" or '), however quotes cannot be a part of the password.
    • Contains at least two digits.

    For more information about this functionality, see Oracle Communications Cloud Native Core, Cloud Native Environment Installation, Upgrade, and Fault Recovery Guide.

  • Container Security Enhancement: In this release, CNE has improved the container security by enhancing securityContext values, adding new policy controls through Kyverno, and removing exec access to containers. A new Kyverno policy, require-emptydir-requests-and-limits, is added in audit mode to provide insight about policy violations in pods. This policy will be enforced in the up coming releases. For more information about Kyverno policy management, the "Managing Kyverno" section in Oracle Communications Cloud Native Core, Cloud Native Environment User Guide.

Operations Services Overlay

Release 24.3.1

Oracle Communications Operations Services Overlay 24.3.1 has been updated with the following enhancement:

Support for new versions: 24_3_common_pod is replaced with 24_3_common_oso. For more information, see Oracle Communications Operations Services Overlay Installation and Upgrade Guide.

Release 24.3.0

Oracle Communications Operations Services Overlay 24.3.0 has been updated with the following enhancement:

Support for new versions:

24_2_common_pod is replaced with 24_3_common_pod.

For more information, see Oracle Communications Operations Services Overlay Installation and Upgrade Guide.

2.4 Cloud Native Core cnDBTier

Release 24.3.1

There are no new features or feature enhancements in this release.

Release 24.3.0

Oracle Communications Cloud Native Core, cnDBTier (cnDBTier) 24.3.0 includes the following enhancements:
  • Transparent Data Encryption (TDE): cnDBTier uses Transparent Data Encryption (TDE) to encrypt the data at the storage layer (the files stored in the disk or PVC of data nodes). TDE encrypts and decrypts data dynamically as it is written to or read from the storage, without requiring any modifications to the application’s code. This guarantees that the sensitive data stored in the database files on disk remains encrypted while at rest, offering a crucial security layer against unauthorized access, particularly in situations where physical security controls fail. For more information, see Oracle Communications Cloud Native Core, cnDBTier User Guide and Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.
  • Enhancement to Georeplication Recovery: With this enhancement, cnDBTier has improved the rate at which the backup files are transferred between sites during a georeplication recovery. This improvement is achieved by:
    • using Secure File Transfer Protocol (SFTP) instead of CURL to transfer backup files between sites.
    • configuring a separate parameter (numberofparallelbackuptransfer) to perform the parallel transfer of backups in the data nodes. For more information about this parameter, see the "Customizing cnDBTier" section in Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.
  • Oracle Cloud Infrastructure (OCI) Enablement: In this release, cnDBTier has validated the proper functioning of the following procedures on OCI:
    • TLS support for georeplication.
    • Horizontal and vertical scaling of cnDBTier pods.

      For more information about these procedures, see Oracle Communications Cloud Native Core, cnDBTier User Guide.

  • Support for New Versions of Software: Oracle MySQL Cluster Database version has been updated to 8.4.2.

Note:

The following APIs are used to fetch cnDBTier status in a cached mode. This means that, the data returned by these APIs are from cached memory and are not dynamic. In previous releases, cnDBTier provided APIs which can fetch real-time status of cnDBTier clusters and replace the cached APIs. Therefore, cnDBTier plans to deprecate these APIs in a future release.
Cached API Purpose Replacement API
http://<base-uri>/db-tier/status/local To fetch local cluster status http://<base-uri>/ocdbtier/status/cluster/local/realtime
http://<base-uri>/db-tier/status/replication/{mate-site-name} To fetch site-specific replication status http://<base-uri>/ocdbtier/status/replication/realtime/{remoteSiteName}
http://<base-uri>/db-tier/status/replication To fetch overall replication status http://<base-uri>/ocdbtier/status/replication/realtime

2.5 Cloud Native Configuration Console (CNC Console)

Release 24.3.0

Oracle Communications Cloud Native Configuration Console (CNC Console) 24.3.0 includes the following enhancements:

  • Support for TLS with Automated Certificate Management: CNC Console supports automation of certificate lifecycle management in integration with Oracle Communications Cloud Native Core, Certificate Manager (OCCM). This allows you to automatically create, renew, and delete certificates for a given CA, with the possibility to track previously created certificates and renew or delete them when required. For more information about OCCM, see the "Support for Automated Certificate Lifecycle Management" section in Oracle Communications Cloud Native Configuration Console User Guide, Oracle Communications Cloud Native Configuration Console Installation, Upgrade, and Fault Recovery Guide, and Oracle Communications Cloud Native Core, Certificate Management User Guide.
  • Support for Traffic Segregation: CNC Console supports network segregation using Cloud Native Load Balancer (CNLB) to effectively manage ingress and egress traffic flows. CNE provides Cloud Native Load Balancer (CNLB) for managing networks used for ingress and egress traffic, as an alternate to the existing LBVM, lb-controller, and egress-controller solution. When this feature is enabled, CNE automatically uses CNLB to control ingress traffic. For managing the egress traffic, you must preconfigure the egress network details in the cnlb.ini file before installing CNE. This feature implements a least connection algorithm for IP Virtual Server (IPVS) based ingress distribution. For more information, see Oracle Communications Cloud Native Configuration Console User Guide and Oracle Communications Cloud Native Configuration Console Installation, Upgrade, and Fault Recovery Guide.
  • Support for Dual Stack (IPv6 preferred) on Dual Stack IPv4 preferred Infrastructure: CNC Console can be deployed with IPv4 or IPv6 or both simultaneously. For more information, see Oracle Communications Cloud Native Configuration Console User Guide and Oracle Communications Cloud Native Configuration Console Installation, Upgrade, and Fault Recovery Guide.
  • Support the Latest Version of NFs: CNC Console provides support for the following NFs, OCCM, and Data Director:
    • SCP 24.3.x
    • NRF 24.3.x
    • UDR 24.3.x
    • Policy 24.3.x
    • BSF 24.3.x
    • OCCM 24.3.x
    • SEPP 24.3.x
    • NSSF 24.3.x
    • NEF 24.2.x
    • CAPIF 24.3.x
    • Data Director 24.3.x
    • NWDAF 24.3.x

    For more information, see Oracle Communications Cloud Native Configuration Console Installation, Upgrade, and Fault Recovery Guide and Oracle Communications Cloud Native Configuration Console User Guide.

2.6 Oracle Communications Cloud Native Core, Certificate Management (OCCM)

Release 24.3.0

Oracle Communications Cloud Native Core, Certificate Management (OCCM) 24.3.0 includes the following enhancements:

  • Improvements to Certificate Monitoring: The monitoring certificates functionality enables you to monitor and manage previously created certificates. It enables you to identify and take action if certificates are modified or deleted manually, without experiencing loss of service. Certificate monitoring is performed in the following scenarios:

    • The certificate or the Kubernetes secret holding the certificate is deleted. An alert is raised and recreation of the certificate is triggered.

    • If the certificate is manually updated, then OCCM detects the change in the certificate and resets the monitoring. OCCM also validates if the manually filled certificate meets the certificate parameters, that is, Subject, Extended Key Usage, and so on. If the certificate does not match the requirements, an alert is raised. For more information, see Oracle Communications Cloud Native Core, Certificate Management User Guide.

  • Support for Traffic Segregation: OCCM supports traffic segregation to specifically manage and control egress traffic, meaning all outgoing data and communication from OCCM to Certificate Authorities (CAs). This ensures that the traffic directed towards CAs is properly segregated and managed to maintain security and efficiency. In contrast, any incoming traffic, that is, REST API requests, is handled separately via the CNC Console. The CNC Console is responsible for managing and processing these incoming requests, ensuring that they are appropriately routed and secured. For information about enabling traffic segregation for OCCM deployment, see Oracle Communications Cloud Native Core, Certificate Management Installation, Upgrade, and Fault Recovery Guide.
  • Support for Certificate and Certificate Chain in the Same Kubernetes Secret or Key: OCCM certificate configuration is enhanced to provide an option to fill certificate and certificate chain into a single file. For more information, see Oracle Communications Cloud Native Core, Certificate Management User Guide.

2.7 OCI Adaptor

Release 24.3.0

Oracle Communications Cloud Native Core, OCI Adaptor 24.3.0 includes the following enhancements:
  • Uplifted the OCI Adaptor Components: The following OCI Adaptor components have been uplifted:
    • Management-agent is uplifted from 1.3.0 to 1.5.0.
    • Fluentd is uplifted from 1.4.1 to 1.5.0.
    • Metric-Server is uplifted from 0.6.4 to v0.7.2.
    • OTEL Collector is uplifted from 0.84.0 to 0.108.0.

2.8 Policy

Release 24.3.0

Oracle Communications Cloud Native Core, Converged Policy 24.3.0 includes the following enhancements:
  • Enhancements to Pending transaction Gx: Policy has been enhanced to support configuration change for response timeout. The diameter configuration response timeout must be configured till the retry exhausts. The response timeout must be updated in the CNC Console. For more information, see "Pending Transactions on Gx Interface" section in Oracle Communications Cloud Native Core, Converged Policy User Guide.
  • Logging Support for Error Response in Policy: Policy sends error responses to consumer NFs due to some exceptions, such as signaling, validations, and internal errors. These error responses have payloads containing the problem title, status, details, and cause of the error that are used to investigate the error. This feature enhances the logging mechanism to support detailed and enhanced logging. For more information, see "Logging Support for Error Response in Policy" section in Oracle Communications Cloud Native Core, Converged Policy User Guide.
  • Support for TLS: Policy supports TLS 1.3 for all functions and interfaces that are supported by TLS 1.2. With this feature, Policy supports the creation of TLS 1.3 and TLS 1.2 connections and mandatory ciphers and extensions. These communication protocols are encrypted using Transport Layer Security (TLS). For more information, see "Support for TLS" section in Oracle Communications Cloud Native Core, Converged Policy User Guide.
  • PCRF Core Pod Congestion Control: The PCRF Core service supports Pod Congestion Control mechanism that helps to handle heavy traffic of incoming requests. It considers every incoming request and decides to either reject or accept it based on a defined request priority and the status of service congestion level. For more information, see "PCRF Core Pod Congestion Control" section in Oracle Communications Cloud Native Core, Converged Policy User Guide.
  • UE Service Pod Congestion Control: The UE service supports Pod Congestion Control mechanism that helps to handle heavy traffic of incoming requests. It considers every incoming request and decides to either reject or accept it based on a defined request priority and the status of service congestion level. For more information, see "UE Service Pod Congestion Control" section in Oracle Communications Cloud Native Core, Converged Policy User Guide.
  • Support for Diameter Message Response Time Latency Metrics: The support for timer latency metrics in Diameter Gateway service provides the time taken to service a request/response in Diameter call flows. This ensures that the cnPolicy meets the required service level agreements (SLAs) for latency by the customer. For more information, see "Support for Diameter Message Response Time Latency Metrics" section in Oracle Communications Cloud Native Core, Converged Policy User Guide.
  • PDS Performance Improvement: The PDS service supports primary key based searches in its database. With this PDS service search, speed and performance are significantly improved, thereby streamlining operations and improving user experience. For more information, see "PDS Settings" section in Oracle Communications Cloud Native Core, Converged Policy User Guide.
  • Support for cnDBTier APIs in CNC Console: The Policy CNC Console GUI supports integration of read-only Georeplicaiton Recovery (GRR) cnDBTier APIs. This functionality allows users to have specific information on cnDBTier statuses on the CNC Console. For more information, see "Support for cnDBTier APIs in CNC Console" section in Oracle Communications Cloud Native Core, Converged Policy User Guide.
  • Traffic Segregation: Policy supports end-to-end traffic segregation based on traffic types. This ensures that critical networks are not cross-connected or share the same routes, thereby preventing network congestion. For more information, see "Traffic Segregation" section in Oracle Communications Cloud Native Core, Converged Policy User Guide.
  • Stale request cleanup for PCRF-Core service: A request is considered as stale if the time taken for a request to be received by PCRF Core is more than the maximum timeframe mentioned in the request header. Similarly, if the time taken by the PCRF Core to process the received request and send its response back to the requestor such as Diameter Gateway or Ingress Gateway is more than the timeframe specified, such a response is considered as stale response. PCRF Core stops further processing of such stale requests and responses and sends a 13002 (DIAMETER_ERROR_TIMED_OUT_REQUEST) error to Diameter Gateway. For more information, see "Support for Stale Requests Cleanup" section in Oracle Communications Cloud Native Core, Converged Policy User Guide.
  • Stale request cleanup for SM service: A request is considered as stale if the time taken for a request to be received by the SM service is more than the maximum timeframe mentioned in the request header. Similarly, if the time taken by SM service to process the received request and send its response back to the requestor such as Diameter Gateway or Ingress Gateway is more than the timeframe specified, such a response is considered as stale response. SM service stops further processing of such stale requests and responses and sends a 504 error to the requested NF. For more information, see "Support for Stale Requests Cleanup" section in Oracle Communications Cloud Native Core, Converged Policy User Guide.
  • Signaling and DB access processing latency histogram metrics for PCRF-Core service: New histogram metrics on signaling and DB access processing latency are added to PCRF Core metrics. These new histogram metrics allow the monitoring of latency on PCRF Corecall flows such as response to diameter requests, HTTP incoming and outgoing connections, and DB requests. For more information, see "PCRF Core Metrics" section in Oracle Communications Cloud Native Core, Converged Policy User Guide.
  • Signaling and DB access processing latency histogram metrics for PDS service: New histogram metrics on signaling and DB access processing latency are added to PolicyDS metrics. These new metrics allow to monitor latency distribution for the HTTP services inside PCF. Also, these metrics helps to get a variety of information, which enable to easily track the different transactions through PDS and measuring their performance. This is helpful in debugging and tracking of the PDS flows. For more information, see "PolicyDS Metrics" section in Oracle Communications Cloud Native Core, Converged Policy User Guide.
  • Support for End-to-End Log Identifier across Policy Services: This feature allows to use a unique identifier to every log message, which can be used to identify the set of logs belonging to a given session across all Policy services. For more information, see "Support for Unique Log Identifier Across Policy Services" section in Oracle Communications Cloud Native Core, Converged Policy User Guide.

2.9 Network Repository Function (NRF)

Release 24.3.0

Oracle Communications Cloud Native Core, Network Repository Functions (NRF) 24.3.0 includes the following enhancements:
  • Support for Georeplication Recovery APIs in CNC Console: With this enhancement, NRF can mark the disrupted cnDBTier cluster as failed, initiate georeplication recovery, and continuously monitor their status, ensuring seamless disaster recovery operations using CNC Console. For more information, see "Support for cnDBTier APIs in CNC Console" in Oracle Communications Cloud Native Core, Network Repository Function User Guide.
  • Upgrade and Rollback Enhancement: NRF now supports N-2 releases upgrade and rollback, where N indicates the current release version of NRF. For NRF release 24.3.0, the upgrade paths can be from 24.1.x or 24.2.x. Similarly, for NRF release 24.3.0, the rollback paths can be 24.2.x or 24.1.x. For more information about this enhancement, see “Supported Upgrade Paths” and “Supported Rollback Paths” in Oracle Communications Cloud Native Core, Network Repository Function Installation, Upgrade, and Fault Recovery Guide.
  • Enhancements for dnn NFProfile Attribute and Discovery Query Parameter: As per 3GPP TS 29.571 v16.7, from 24.3.x release, NRF supports additional validations for the dnn attribute during NFManagement and NFDiscover service operations. NRF also supports exact or partial matching of dnn query attribute value with the dnn attribute present in the registered NFProfile for NFDiscover service operation. For more information, see "NRF Compliance Matrix and Enhancements for dnn NFProfile Attribute and Discovery Query Parameter" section in Oracle Communications Cloud Native Core, Network Repository Function User Guide.
  • Support for servingClientTypes in LMFInfo and GMLCInfo: As per 3GPP TS 29.510 v16.7, NRF supports servingClientTypes attribute in NF Profiles for Location Management Function (LMC) (LmfInfo) and Gateway Mobile Location Center (GMLC) (GmlcInfo). NRF supports client-type discovery query parameter to discover NFs based on servingClientTypes. If the above mentioned attributes are present in the NF Profile, then the GMLC and LMF NFs are considered as dedicated to serve the listed external client type. The listed external client types are mentioned in 3GPP TS 29.572 v16.7. If this attribute is not present in the NF Profile for the mentioned NFTypes, then NFs are not considered as dedicated to serve any external client type. For more information, see "NRF Compliance Matrix and Support for servingClientTypes in LMFInfo and GMLCInfo" section in Oracle Communications Cloud Native Core, Network Repository Function User Guide.
  • Support for Server Header: NRF handles various requests from Consumer Network Functions (NFs) and other network entities over HTTP protocol. Upon receiving these requests, NRF validates and processes these requests before responding to Consumer NFs. If NRF sends an error response, then the consumer NFs need to know the source of the error for troubleshooting and to take corrective measures. This feature adds server headers to the error response generated by NRF, which is useful in identifying the origin of an error. This enhancement improves NRF’s error handling for better troubleshooting and corrective actions by the consumer NFs. For more information, see the "Support for Server Header" section in Oracle Communications Cloud Native Core, Network Repository Function User Guide.

2.10 Network Slice Selection Function (NSSF)

Release 24.3.2

There are no new features or feature enhancements in this release.

Release 24.3.1

There are no new features or feature enhancements in this release.

Release 24.3.0

Oracle Communications Cloud Native Core, Network Slice Selection Function (NSSF) 24.3.0 includes the following enhancements:

  • Support for TLS in NSSF: In addition to TLS 1.2, NSSF now supports TLS 1.3 encryption to establish secure HTTPS connections. TLS 1.3 simplifies the handshake process by reducing round trips and enhancing security with improved encryption, compared to TLS 1.2. This version also supports Perfect Forward Secrecy (PFS), which secures session keys independently of long-term private keys and uses stronger cipher suites for improved privacy. While TLS 1.3 is prioritized, TLS 1.2 remains supported to ensure compatibility. For more information, see the "Support for TLS in NSSF" section in the Oracle Communications Cloud Native Core, Network Slice Selection Function User Guide.
  • Traffic Segregation: This feature provides end-to-end traffic segregation to NSSF based on traffic types. It addresses the challenge of logically separating IP traffic of different profiles, which are typically handled through a single network (Kubernetes overlay). The Multus CNI container network interface (CNI) plugin for Kubernetes allows to attach multiple network interfaces to pods to help segregate traffic from each NSSF microservice. The new functionality ensures that critical networks are not cross-connected or sharing the same routes, thereby preventing network congestion. For more information, see the "Traffic Segregation" section in the Oracle Communications Cloud Native Core, Network Slice Selection Function User Guide.

2.11 Service Communication Proxy (SCP)

Release 24.3.0

Oracle Communications Cloud Native Core, Service Communication Proxy (SCP) 24.3.0 includes the following enhancements:

  • SCP Response Timeout Extension: With this enhancement, SCP allows users to extend the maximum response timeout to 50 seconds. This improvement provides configuration options to support response timeouts for NFs that require more time to serve a request. For more information, see the "SCP Response Timeout Extension" section in Oracle Communications Cloud Native Core, Service Communication Proxy User Guide.
  • Verbose Logging for SCP: This enhancement introduces verbose logging specifically for the SCPC-Audit microservice within the control plane. For more information, see the "Verbose Logging for SCP" section in Oracle Communications Cloud Native Core, Service Communication Proxy User Guide.
  • Log Enhancement for 5G SBI Error Responses Generated by SCP: SCP has enhanced the error logs by including information, such as sender details, subscriber ID, error status code, error title, error details, and error cause. These details, along with the problem details, identify the cause of the error responses generated by SCP. For more information, see the "Log Enhancement for 5G SBI Error Responses Generated by SCP" section in Oracle Communications Cloud Native Core, Service Communication Proxy User Guide.

2.12 Security Edge Protection Proxy (SEPP)

Release 24.3.2

No new features or feature enhancements have been introduced in this release.

Release 24.3.1

No new features or feature enhancements have been introduced in this release.

Release 24.3.0

Oracle Communications Cloud Native Core, Security Edge Protection Proxy (SEPP) 24.3.0 includes the following enhancements:

  • Security Countermeasure Non-Verbose Error Responses: With this enhancement, SEPP's security countermeasure features have been improved to provide either detailed (verbose) or concise (non-verbose) error responses, depending on user configurations. In this release, the error response configurations of 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

    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.

    For more information about the feature, see "Security Countermeasure Non-verbose Error Responses" section in Oracle Communications Cloud Native Core, Security Edge Protection Proxy User Guide, Oracle Communications Cloud Native Core, Security Edge Protection Proxy REST API Guide, and Oracle Communications Cloud Native Core, Security Edge Protection Proxy Troubleshooting Guide.

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

    Using a shared cnDBTier for multiple SEPP instances can save a significant amount of CPU resources compared to having a separate database for each instance. This shared cnDBTier is built with security features that restrict data access for each SEPP instance by using unique logins and credentials during deployment. This allows each SEPP instance to securely access its own database while using the same cnDBTier within the Kubernetes cluster. For example, deploying four SEPP instances in the same cluster can lead to considerable increase resource efficiency compared to giving each instance 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.

    For more information about the feature, see "Multiple SEPP Instances on Shared cnDBTier Cluster" section in Oracle Communications Cloud Native Core, Security Edge Protection Proxy User Guide, Oracle Communications Cloud Native Core, Security Edge Protection Proxy REST API Guide, and Oracle Communications Cloud Native Core, Security Edge Protection Proxy Troubleshooting Guide.

  • Proactive Status Updates on SEPP: In the previous releases, consumer NFs sent Service Based Interface (SBI) message requests to SEPP without checking the status of SEPP because there was no health check mechanism implemented at SEPP.
    Using this feature, consumer NFs can determine the health or connection status of SEPP before forwarding any SBI message request to SEPP. This feature allows consumer NFs or consumer SEPPs to perform the following health check verification at SEPP:
    • Determines if SEPP is reachable through the transport path.
    • Determines if SEPP is available to respond to SBI message requests.

    For more information about the feature, see the "Proactive Status Updates on SEPP" section in Oracle Communications Cloud Native Core, Security Edge Protection Proxy User Guide, Oracle Communications Cloud Native Core, Security Edge Protection Proxy REST API Guide, and Oracle Communications Cloud Native Core, Security Edge Protection Proxy Troubleshooting Guide.

  • 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, and so on. The Multus CNI container network interface (CNI) plugin for Kubernetes allows to attach 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. For more information about the feature, see the "Traffic Segregation" section in Oracle Communications Cloud Native Core, Security Edge Protection Proxy User Guide.

2.13 Unified Data Repository (UDR)

Release 24.3.0

Oracle Communications Cloud Native Core, Unified Data Repository (UDR) 24.3.0 includes the following enhancements:

  • IMSI Fallback Lookup Enhancement: This feature enables Equipment Identity Register (EIR) to return user equipment status as WHITELISTED, BLACKLISTED, or GREYLISTED for the matched International Mobile Equipment Identity (IMEI) in the EIR database. For more information, see "IMSI Fallback Lookup Enhancement" section in Oracle Communications Cloud Native Core, Unified Data Repository User Guide.
  • Diameter S13 Interface: This feature supports diameter interface between EIR and Mobility Management Entity (MME) to retrieve the User Equipment (UE) status of the subscriber from the EIR database. For more information, see "Diameter S13 Interface" section in Oracle Communications Cloud Native Core, Unified Data Repository User Guide.
  • Secure File Transfer Support for Subscriber Bulk Import Tool Enhancement: This feature is enhanced to support separate file paths for PDBI files and result log files. For more information, see "Secure File Transfer Support for Subscriber Bulk Import Tool Enhancement" section in Oracle Communications Cloud Native Core, Unified Data Repository User Guide.