2 Service Communication Proxy Architecture

This section explains the Oracle Communications Cloud Native Core, Service Communication Proxy (SCP) system architecture.

SCP is a decentralized solution composed of control plane and data plane. This solution is deployed with 5G Network Functions (NFs) for providing routing control, resiliency, and observability to the core network.

Figure 2-1 Service Communication Proxy Architecture


Service Communication Proxy Architecture

The SCP solution is deployed either as a default outbound proxy to NF instances or as a router model, where SCP is configured as HTTP2 outbound proxy at each NF in cloud native environments.

SCP Microservices

The list of SCP microservices is as follows:

Table 2-1 SCP Microservices

Microservices Description
SCPC-Notification

It configures routing rules as per 5G NF topology information obtained from NRF, or as result of audit. It tracks the 5G NF topology for any change and updates in the route rules or configuration. It translates the topology into low-level SCP-Worker configuration and provides the configuration to the Worker when requested.

SCPC-Audit It performs periodic audit with NRF to synchronize the 5G NF topology information and updates routing rules through notifications if required.
SCPC-Configuration It provides an interface for SCP configuration.
SCPC-Subscription It performs NRF management and NRF discovery service operation for SCP registration and subscription for NF change notification.
SCPC-Alternate-Resolution It finds an alternate NF service by performing DNS SRV queries with the DNS server and receives the DNS SRV responses.
  • Refreshes DNS SRV records to get update in DNS SRV records.
  • Provides DNS SRV records to scp-worker when required.
SCP-Worker

It receives 5G signaling traffic and controls communication and routing among 5G NFs and services.

  • 5G NF selection for routing and rerouting across available 5G NFs
  • Endpoint selection based on NF profile information registered with NRF
  • Congestion control and traffic throttling using Ingress and Egress
  • Load balancing and overload control
  • 5G SBI message priority assignment
  • 5G SBI Mediation
  • 5G Observability data
SCP-NrfProxy It operates as an intermediate proxy between SCP-Worker and NRF for NF Discovery service requests originated by SCP.
  • It stores NF Discovery responses received from NRF through SCP-Worker.
  • It receives NF Discovery requests, along with query parameters from SCP-Worker, and forwards the created NF Discover requests to NRF through SCP-Worker. After receiving the NF Discovery responses from NRF through SCP-Worker, the nrfproxy service sends the response to SCP-Worker and stores the response for subsequent use.
SCP-Cache It maintains the present status of ingress and egress traffic rate limiting and serves to the SCP-Worker microservice by storing the keys of rate limiting when required.
SCP-Mediation It allows the modification of 5G SBI message content such as HTTP2 header values or JSON message body or the both, based on user-defined mediation rule sets to solve any inter-op issues. It applies user configured message mediation policy rules on ingress 5G SBI messages to execute message mediation transformation.
SCP-Mediation-Test It enables to test the user configured message mediation policy test rules on ingress 5G SBI messages without actual execution on messages and mediation transformation.
SCP-LoadManager It manages the load and overload control information of peer NFs and SCPs on its own. It determines the latest load information from NRF or the LCI header using timestamp and shares the updated information with SCP-Worker pods using distributed cache. SCP-Worker pods process the received LCI information, update the routing rules, and use it for 5G SBI request routing and selection.
SCP-NrfProxy-Oauth It is an intermediary proxy between SCP-Worker and NRF for processing OAuth2.0 access token service requests. It caches the OAuth2.0 access token received from NRF through SCP-Worker. It receives the OAuth2.0 access token request from SCP-Worker and forwards the created OAuth2.0 access token service request to NRF through SCP-Worker. After receiving the Oauth2.0 access token response from NRF through SCP-Worker, SCP-nrfProxy-Oauth sends the response to SCP-Worker and caches the response for subsequent use.

Ingress and Egress Gateway Traffic Management

For more information about Ingress and Egress Gateway Traffic Management, see Oracle Communications Cloud Native Core, Cloud Native Environment User Guide.

2.1 5G SBI Message Processing and Trigger Points

The following image represents how SCP processes ingress 5G SBI message requests from consumer NFs.

Figure 2-2 5G SBI Message Processing and Trigger Points


5G SBI Message Processing and Trigger Points