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

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
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.
|
SCP-Worker |
It receives 5G signaling traffic and controls communication and routing among 5G NFs and services.
|
SCP-NrfProxy | It operates as an intermediate proxy between
SCP-Worker and NRF for NF Discovery service requests originated
by SCP.
|
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.