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.
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (85 CRs across 6 releases). Complements the general historical overview above with the evidence-based evolution of this function.
In Release 15, the Service Communication Proxy (SCP) function was newly introduced as part of the architecture enhancements to facilitate communications with packet data networks and applications. The updates specifically included clarifications and enhancements for the Security Edge Protection Proxy (SEPP), ensuring it is fully redundant and can interface with a next-hop IPX proxy. These changes provided a more robust and clearly defined proxy framework for secure inter-network communication.
In Release 16, the Service Communication Proxy (SCP) was enhanced to formally introduce indirect communication with implicit discovery between Network Function services, a key aspect of the Enabler-based Service-Based Architecture (eSBA). This release defined specific communication schemas for the discovery and selection of core network functions like the UDM, UDR, SMF, PCF, AUSF, and AMF when using the SCP. Furthermore, it added crucial security provisions for roaming interfaces in these indirect communication scenarios, including authentication and token-based authorization mechanisms.
- Introduction of indirect communication between NF services and implicit discovery TS 23.501CR0736
- eSBA communication schemas related to general discovery and selection TS 23.501CR0799
- eSBA communication schemas related to UDM and UDR discovery and selection TS 23.501CR0800
- eSBA communication schemas related to SMF discovery and selection TS 23.501CR0801
- eSBA communication schemas related to PCF discovery and selection TS 23.501CR0802
- eSBA communication schemas related to AUSF discovery and selection TS 23.501CR0803
+ 33 more changes
In Release 17, the SCP function was enhanced to support Time Sensitive Communication (TSC) and Time Synchronization for applications other than TSN, based on AF requests. This introduced new architectural support for these capabilities. Additionally, corrections were made to the authorization procedures for indirect communication.
- Introduction of the architectures for Time Sensing Communication other than TSN. TS 23.501CR2573
- Introduction of architecture for AF requested support of Time Sensitive Communication and Time Synchronization TS 23.501CR2833
- Support Time Sensitive Communication other than TSN TS 29.513CR0265
- Support reporting the analytics of the application list used by UE in the UE communication analytics TS 29.520CR0386
- Support reporting N4 session inactivity timer in the UE communication analytics TS 29.520CR0387
- Add the periodic communication indicator to UeCommunication data type TS 29.520CR0393
+ 3 more changes
In Release 18, the SCP function was enhanced with new capabilities for CN-based Mobile Terminated communication handling, including its co-existence with Small Data Transmission for UEs in RRC_INACTIVE state and corrections for its asynchronous type communication. Enhancements were also introduced for AF-based service parameter provisioning for A2X communication and for ordering criterion support in UE communication procedures. Furthermore, the release updated SCP requirements related to source PLMN-ID and defined procedures for PIN communication configuration.
- PIN communication configuration TS 23.501CR3897
- CN based MT communication capability indication TS 23.501CR4081
- KI#4 implementation of cross-SMF VN group communication TS 23.501CR4313
- Enhancement of Time Sensitive Communication TS 29.513CR0440
- Enhancements to AF-based service parameter provisioning for A2X communication TS 29.513CR0461
- Enhancement of UE communication for AnalyticsInfo Service TS 29.520CR0664
+ 13 more changes
In Release 19, the SCP function was enhanced to act as an analytics data source for the NWDAF and to support token-based authorization for indirect communication when a Network Function is selected in a target PLMN. It also introduced clarifications and support for authorization in roaming and interconnect scenarios within indirect communication architectures. Furthermore, the release added procedures for the SCP to include requester's PLMN IDs in service requests and to handle service request rejections due to missing parameters in Access Token Requests.
- Support of UE-Satellite-UE communication TS 23.501CR5583
- Support QoS of proxying IP and Ethernet in HTTP over MPQUIC TS 23.501CR5527
- Support of UE-satellite-UE communications when serving satellite changes TS 23.501CR5518
- Update for support of UE-Satellite-UE communication TS 23.501CR6144
- Add SCP as the analytics data source of NWDAF TS 29.552CR0157
- Token-based authorization for indirect communication scenarios when NF is selected at target PLMN TS 33.501CR2135
+ 8 more changes
In Release 20, the Service Communication Proxy (SCP) function was enhanced to support UE-to-UE communication for non-IMS services, as indicated by the new CR title. This expands the SCP's role in facilitating direct communications between User Equipment beyond the traditional IMS Multimedia Telephony service scope. The enhancement specifically addresses communication between two or more ProSe-enabled UEs, leveraging the ProSe Communication path for non-IMS applications.
- Support of UE-SAT-UE communication for non-IMS services TS 23.501CR6520
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 |