1 Introduction

This document provides information about how to use Oracle Communications Cloud Native Core, Service Communication Proxy (SCP) in the cloud native 5G core network.

SCP is a 3GPP-defined network entity that works as an HTTP/HTTPs proxy in the 5G SBA control plane. 5G NFs communicate indirectly via the SCP in the indirect communication models.

Figure 1-1 Service Based Architecture(SBA) for 5G Core


Service Based Architecture(SBA) for 5G Core

The core network in 5G follows a service-based architecture, where network functions provide services that can be utilized using REST APIs by other functions. This allows the adoption of web-scale technologies and software that are used by different organizations in the telecommunications network.

SCP provides the following functionalities in the 5G core:

  • Routing/Selection: Routing rules, refresh cache, and handle application failures and redirects.
    • Dynamic Discovery: The 5G topology is learned from Network Repository Function (NRF) and routing rules are created automatically based on the learned NF profiles.
    • Static Configuration: SCP allows the configuration of NF profiles.
  • Load Balancing: Load balancing based on NF set, priority, and capacity published in the NF profile.
  • NF Subscription: Subscription for all NF types to learn the network topology.
  • Circuit Breaking: Pro-active method to detect the degraded producer NF instances in the network. Implemented on a per FQDN basis when outstanding transactions exceed a configurable value.
  • Message Priority: Message Priority assignment and override based on the 3GPP-SBI-Message-Priority header.
  • Congestion Control: Congestion control for producer NF instances based on their published NF load.
  • Overload Control: Avoids SCP failures by providing overload control for SCP-worker pods based on CPU usage. Uniform load balancing and routing strategy across the network and protects the pod from overload related to various system resources.

SCP Availability

Oracle Communications Cloud Native Core, Service Communication Proxy (SCP) availability depends on many factors. SCP applications are designed to achieve 99.999% availability according to the applicable Telecommunications Industry Association TL9000 standards with the following deployment requirements:
  • Deploy on a Cloud Native Environment with at least 99.999% availability.
  • Deploy with n + k (up to 2) application redundancy, where k is greater than or equal to one.
  • Maintain production software within n-3 software releases, where n is the current general availability release.
  • Apply bug fixes, critical patches, and configuration recommendations provided by Oracle promptly.
  • Maintain fault recovery procedures external to the applications for the reconstruction of lost or altered files, data, programs, or Cloud Native environment.
  • Install, configure, operate, and maintain SCP as per Oracle’s applicable installation, operation, administration, and maintenance specifications.
  • Maintain an active support contract and provide access to the deployed SCP and your personnel to assist Oracle in addressing any outage.

Note:

The performance and capacity of the SCP system may vary based on the call model, feature or interface configuration, network conditions, and underlying CNE and hardware environment.

SCP availability is measured for each calendar year and is calculated as follows:

Table 1-1 Measuring SCP Availability

Availability Description
Planned Product Availability (Product available time in each month) less (Excluded Time (defined below) in each month).
Actual Product Availability (Planned Product Availability) less (any Unscheduled Outage)
Product Availability Level (Actual Product Availability across all Production instances divided by Planned Product Availability across all Production instances) x 100

Note:

Excluded Time means:
  • Scheduled maintenance time.
  • Lack of power or backhaul connectivity, except to the extent that such lack of backhaul connectivity was caused directly by the CNC NF.
  • Hardware failure.
  • Issues arising out of configuration errors or omissions.
  • Failures caused by third-party equipment or software not provided by Oracle.
  • Occurrence of any event under Force Majeure.
  • Any time associated with failure to maintain the recommended architecture and redundancy model requirements above.

1.1 References

  • Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide
  • Oracle Communications Cloud Native Core, Service Communication Proxy Installation, Upgrade, and Fault Recovery Guide
  • Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide
  • Oracle Communications Cloud Native Core, Automated Test Suite Guide
  • Oracle Communications Cloud Native Configuration Console Installation, Upgrade, and Fault Recovery Guide
  • Oracle Communications Cloud Native Core, Network Repository Function User Guide
  • Oracle Communications Cloud Native Core, Network Repository Function Installation, Upgrade, and Fault Recovery Guide
  • Oracle Communications Cloud Native Core, Cloud Native Environment User Guide
  • Oracle Communications Network Analytics Data Director User Guide
  • Oracle Communications Cloud Native Core, Certificate Management Installation, Upgrade, and Fault Recovery Guide
  • Oracle Communications Cloud Native Core, Certificate Management User Guide
  • https://github.com/k8snetworkplumbingwg/multus-cni.