Description
The Service Communication Proxy (SCP) is a fundamental architectural element within the 5G Core (5GC) network, operating within the service-based architecture (SBA). It acts as an intermediary for all HTTP/2-based service-based interface (SBI) communications between producer and consumer Network Functions (NFs). The SCP provides a centralized communication layer, abstracting the direct point-to-point connectivity. Its primary role is to manage service discovery and selection. When a consumer NF needs to invoke a service, it sends a request to the SCP. The SCP then consults the Network Repository Function (NRF) to discover suitable producer NF instances that offer the required service, considering factors like load, location, and network slice context. After discovery, the SCP can perform load balancing by selecting an appropriate producer NF instance and securely forwarding the request. This decouples service consumers from the need for direct knowledge of producer NF instances and their locations.
Architecturally, the SCP is defined as an independent network function with its own service-based interface. It supports both the request-routing model, where it acts as a proxy for all messages, and the indirect communication model, where it provides discovery information to the consumer NF, which then communicates directly. The SCP implements critical security functions such as transport layer security (TLS) termination and re-initiation, ensuring end-to-end security across the service mesh. It can also enforce access control policies, validate messages, and provide topology hiding by masking the internal network structure from external entities or between different network slices.
Beyond discovery and security, the SCP enhances network reliability and scalability. It supports message routing and forwarding based on policies, subscriber information, and network slice identifiers. It can provide resilience through mechanisms like retransmissions and alternative routing if a producer NF fails. The SCP's centralized nature simplifies network operations, as policies for load balancing, traffic steering, and security can be managed in one logical point rather than distributed across every NF. This is crucial for large-scale, cloud-native deployments where NFs are dynamically instantiated and scaled. The SCP is a key enabler for efficient network slicing, as it can route requests to NF instances belonging to a specific slice, ensuring isolation and tailored service levels.
Purpose & Motivation
The SCP was introduced to address the complexities of direct service-to-service communication in the 5G Service-Based Architecture (SBA). In earlier 3GPP architectures, like the 4G Evolved Packet Core (EPC), interfaces were primarily point-to-point and protocol-specific (e.g., GTP, Diameter). The shift to a cloud-native, microservices-based 5GC with HTTP/2-based APIs created a dynamic environment where Network Functions (NFs) are ephemeral and scalable. Direct communication would require every NF consumer to continuously discover and manage connections to all potential NF producers, leading to significant signaling overhead, complex mesh management, and reduced agility.
The SCP solves these problems by providing a centralized communication fabric. It abstracts service discovery and routing, allowing NFs to be developed and deployed independently without hard-coded dependencies. This solves the problem of NF discovery in a dynamically changing environment. Furthermore, it addresses critical security and operational needs. It provides a central point for implementing security policies (like mutual TLS), access control, and topology hiding, which is essential for operator security and when exposing network capabilities to third parties. Its creation was motivated by the need for a scalable, manageable, and secure interconnection model that supports automation, network slicing, and the efficient operation of a disaggregated, software-defined core network.
Architecture
In the Network Map
- Mobile Network → 5G Core → SCP (Signaling)
Release Timeline
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (17 CRs across 3 releases). Complements the general historical overview above with the evidence-based evolution of this function.
In Release 16, the Service Communication Proxy (SCP) function was enhanced with new capabilities including delegated discovery and selection for specific Network Functions (CHF and SMSF), NF group resolution, and clarifications for registration, discovery, and selection procedures to support multi-SCP deployments. The update also formalized SCP's role in performing token-based authorization on behalf of NFs and introduced support for service-mesh-based and virtualized deployment options. Furthermore, the specifications were aligned to consistently use the "SCP" abbreviation.
- Update the support of virtualized deployment with SCP distribution and the NF/NF service instance Set TS 23.501CR0926
- SCP Function Update TS 23.501CR1171
- NF Group resolution by SCP TS 23.501CR1563
- Delegated discovery and selection in SCP for CHF and SMSF TS 23.501CR1715
- Clarifications on SCP registration and discovery procedures TS 23.501CR2444
- Clarification on SCP selection to support multi-SCPs TS 23.501CR2447
+ 5 more changes
In Release 18, the specifications for the Service Communication Proxy (SCP) were updated with new requirements and clarified trust assumptions. These changes specifically addressed the handling and verification of the source PLMN-ID within the SCP's procedures.
In Release 19, the Service Communication Proxy (SCP) function was enhanced with new capabilities for network analytics and improved service request handling. Specifically, the SCP was introduced as a formal analytics data source for the Network Data Analytics Function (NWDAF), and procedures were defined for when the SCP rejects a service request due to a missing parameter in an Access Token Request. Additional updates included the handling of the requester's PLMN IDs in service requests to the SCP and corrections to SCP event reporting.
Explore further
Broader topics and technologies where SCP plays a role.
Defining Specifications
3GPP specifications that define or reference SCP, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TR 21.905 vj00 | 3GPP Technical Terms and Definitions | Rel-19 |
| TS 23.094 vj00 | Follow Me (FM) Feature Stage 2 | Rel-19 |
| TS 23.127 v1600 | Virtual Home Environment Stage 2 Specification | Rel-6 |
| TS 23.501 vk00 | 5G System Architecture Stage 2 | Rel-20 |
| TS 23.540 vj20 | 5G Service Based SMS Stage 2 | Rel-19 |
| TS 24.524 vj00 | Hosted Enterprise Services Architecture | Rel-19 |
| TR 28.840 vi10 | Technical Report | Rel-18 |
| TS 29.078 vj00 | CAMEL Phase 4 CAP Specification | Rel-19 |
| TS 29.198 v1900 | OSA API Overview Specification | Rel-9 |
| TS 29.278 vj00 | CAMEL Application Part (CAP) for IMS Phase 4 | Rel-19 |
| TS 29.500 vj50 | 5GC Service Based Architecture Specification | Rel-19 |
| TS 29.513 vj40 | 5G PCC Signalling Flows & QoS Mapping | Rel-19 |
| TS 29.520 vj40 | 5G Network Data Analytics Services Stage 3 | Rel-19 |
| TS 29.552 vj40 | 5G Network Data Analytics Signalling Flows | Rel-19 |
| TS 29.570 vj10 | SCP Nscp Service Based Interface Stage 3 | Rel-19 |
| TS 29.574 vj40 | 5G Data Collection Coordination Services Stage 3 | Rel-19 |
| TR 29.843 vg00 | 5GC Load and Overload Control Study | Rel-16 |
| TS 32.255 vk10 | Telecom Management; Charging for 5G Data Connectivity | Rel-20 |
| TS 32.808 v1800 | Common User Profile Storage Framework | Rel-8 |
| TS 33.117 vk00 | Catalogue of General Security Assurance Requirements | Rel-20 |
| TS 33.501 vk00 | 5G Security Architecture and Procedures | Rel-20 |
| TS 33.776 vj00 | Study of ACME for 5G SBA | Rel-19 |
| TS 33.794 vj10 | Study on Zero Trust Security Enablers for 5G | Rel-19 |