SCP

Service Communication Proxy

Core Network →
Introduced in R99 Also in: Services, Security

SCP is a core network function that acts as a centralized, secure proxy for service-based communications between network functions, enabling discovery, load balancing, and security in 5G networks.

Category
Core Network
Introduced
R99
Where
Core Network › 5G Core
Also touches
2 segments
Specifications
23 specs
SCP Description Purpose Detected Changes Specifications

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

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

Specific 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.

Rel-16 11 changes

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

Rel-18 2 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.

  • SCP trust assumptions TS 33.501CR1544
  • SCP requirements update related to source PLMN-ID TS 33.501CR1577
Rel-19 4 changes

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.

  • Add SCP as the analytics data source of NWDAF TS 29.552CR0157
  • Service request rejected by SCP due to missing parameter in Access Token Request TS 29.500CR0467
  • Requester's PLMN IDs in service request to SCP TS 29.500CR0474
  • Correction of SCP event report TS 29.570CR0003

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.

SpecificationTitleRelease
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
Patrick Zandl

About the author: Patrick Zandl (b. 1974)

Telecommunications specialist, technology journalist (founder of the Mobil server), and developer who has been running since 2025 — the largest Czech-language resource on AI-assisted programming. Formerly Chief Wizard Architect at Prusa3D and head of development for Turris at CZ.NIC; currently a consultant and instructor on AI implementation in companies.