Enabling smart, secure signaling in the 5G Core
With nearly 100 standalone 5G Core deployments worldwide, one reality is becoming clear: without intelligent signaling control, scaling 5G will cost operators more than just bandwidth, it could cost them agility. Central to this is the Service Communication Proxy (SCP), a key innovation that takes signaling well beyond the roles played by legacy routing nodes like the STP (SS7) and DRA (Diameter).
What is the SCP and why is it important?
The SCP is a central intermediary acting as a smart signaling proxy for all service-to-service communication in the 5G Core. Instead of routing messages based on static tables, it dynamically discovers services through the Network Repository Function (NRF) and optimizes communication across distributed Network Functions (NFs) using HTTP/2.
Leveraging concepts from cloud-native and IT environments, the SCP provides operators with:
- Dynamic service discovery and smart routing
- Built-in load balancing and traffic prioritization
- Security through mTLS and token-based access
- Observability with native logging, tracing
- Network resilience
These capabilities reduce operational overhead, improve robustness, and simplify NF onboarding, which is critical in fast-evolving, multi-vendor 5G environments.
How the SCP is evolving like STP and DRA did
Just as the STP and DRA emerged to manage increasingly complex signaling in 2G/3G and 4G mobile networks, the SCP is evolving to meet the demands of service-based 5G networks. But it will be relevant in many more ways than its predecessors, as it is a policy-aware, service-oriented controller with advanced roles in:
- Service authentication and authorization
- Overload protection and policy enforcement
- Parameter harmonization across vendors and interfaces where feasible
- Interworking between legacy (4G) and new (5G) functions
- Protocol translation, supporting HTTP/2, Diameter, and even SS7
Without the SCP, operators risk a growing complexity and higher signaling costs, as they scale 5G and bridge it with legacy systems. Furthermore, the SCP will likely remain a key signaling hub for 6G as well, as the NGMN announced 6G should be viewed as a seamless evolution – fully compatible with 5G and propelled by continuous software innovation.
Understanding SCP Deployment Models
For the communication between Network Functions (NF), 3GPP has defined four models (A, B, C and D) encompassing direct and indirect scenarios between a Consumer NF and a Producer NF. In Release 15, 3GPP introduced a direct communication mode between Consumers and Producers NFs. This model of communication does not necessitate any proxy between NFs (no SCP is used). Within this direct mode of communication, there are two distinct options. Model A operates without involving the NRF (Network Repository Function), while Model B utilizes the NRF to handle service discovery and registration processes, maintaining updated records of NF status and their profiles.
Indirect communication between NFs was introduced in 3GPP Release 16 to shift discovery and selection responsibilities away from NFs. Here the SCP comes into play, as an intermediary to proxy and mediate signaling between service consumers and producers. The role of the SCP in this architecture is conceptually similar to that of the STP and DRA in 2G/3G and 4G mobile core networks. In Model C, NFs need to communicate with the NRF for service discovery and producer instance or set selection. For the latter, the SCP performs the producer instance selection and load balancing based on the optional NF set discovery parameter included in the HTTP/2 request message from the NFs. Within Model D, the SCP acts as a full-service broker, where all discovery tasks are delegated to the SCP; it communicates with the NRF, applies NF instance selection and load balancing based on real time NRF response data.
Put simply, Model C relies on the NF to discover its target via the NRF and uses the SCP solely for routing, whereas in Model D, the SCP manages both discovery and routing on the NF’s behalf.
Real-world deployment lessons
BroadForward’s initial SCP deployments across various Tier-1 and Tier-2 operators show several recurring realities:
- Our SCP deployments rarely follow “Model D only” deployment – and our SCP has been deployed to support both Model C and D.
- Some 5G Core Network Equipment Providers (NEPs) mandate Model D deployment, limiting SCP vendor options as not all support Model D yet.
- Approximately half of our SCP deployments are initially deployed on Virtual Machines. Many deployments typically start with either VMs or bare metal, offering the option to scale up or transition to the cloud (in containers) later, as and when desired.
- Not all Network Equipment Providers (NEPs) permit the deployment of third-party network elements within the 5G private clouds they offer with their 5G Cores. Operators should assess if such limitation aligns with their multi-vendor strategy and migration and expansion plans.
- Integration across technologies is a major aspect of SCP deployments, as coexisting 4G-5G network environments are the norm for the foreseeable future, rather than an exception.
- Almost all operators require our SCP to perform message manipulation and multi-protocol interworking. A notable recent case involved a national operator using the SCP to extend 4G OCS and PCRF systems into the 5G Core, preserving existing investments while enabling 5G features.
- In multiple cases operators use our SCP to apply intelligent business logic, for instance to perform external database lookups.
Conclusion: SCP as a core intelligence layer
The SCP is not just another signaling router; it’s the evolving intelligence layer of the 5G Core. It enables smart routing, NF discovery, load management, security, and legacy interworking functions that are crucial for vendor interoperability and cost-efficient scaling.
BroadForward’s experience shows that the first real-world SCP deployments are far more diverse than the standardization guidelines suggest. This is not unexpected, as we have learned over the decades of network evolution that once new technologies are first deployed, standardization will start to trail vendors’ continuous innovation and adaptation to market realities.
Just as the STP and DRA evolved to meet the needs of previous network generations, the SCP is poised for continual advancement. Operators should consider what they need beyond basic compliance. Our experience shows that no two SCP deployments are alike, as each operator faces unique challenges at different stages of their network’s lifecycle. Some may initially need a bare-bones SCP deployment, while others will require the SCP from day one to perform complex multi-technology (legacy) interworking and business logic to enable advanced service scenarios.
Interested in reading more about the BroadForward SCP? Click here