Patrik Rokyta I CTO I 17 April 2024
With the growing number of 5G SA deployments, addressing the increased usage of 5G SA services and, consequently, the surge in traffic within the 5G core has made centralizing traffic control one of the key points of discussion. The initial version of the 3GPP standards for 5G (R15) outlined a fully-meshed service-based architecture, promoting direct communication among network functions. Consequently, this blueprint influenced the implementation of 5G core network products by various suppliers. However, the evolution to the next 3GPP release (R16) introduced a groundbreaking enhancement – the 5G Service Communication Proxy (SCP). This innovation brings a paradigm shift by facilitating indirect communication among network functions, positioning the 5G SCP as a central hub component all 5G core signaling traffic is routed through.
The utilization of a star (or hub-and-spoke) topology is a familiar concept in telco networks, where centralized components such as the Signal Transfer Point (STP) in 2G/3G networks and the Diameter Routing Agent (DRA) in 4G/LTE networks have historically played crucial roles in routing. Therefore, the introduction of the 5G SCP as a centralized component for signaling and routing in the 5G core naturally represents a logical architectural progression. It's important to acknowledge that centralized routing in legacy networks was necessitated partly by the use of the stream control transmission protocol, which demanded a highly granular (endpoint-level) configuration of the network components. However, with the advent of HTTP/2 in 5G core networks, this complexity diminishes significantly. HTTP/2 inherently supports full-mesh service topologies through the combination of the domain name system, TCP/TLS transport protocol and network address translation providing for virtually unlimited web-scale networking widely adopted by the IT industry. Yet, despite this shift, the prospect of routing all 5G core traffic through a centralized component like the 5G SCP remains highly appealing due to the myriad benefits it offers. Examples of the benefits include, but are not limited to:
- Serving as a single point of contact for all consumer network functions within the 5G core.
- Acting as a single PLMN-ingress/-egress point (in conjunction with local or outsourced SEPP).
- Providing access to the unencrypted content of all messages within the 5G core.
- Centralizing the execution of service discovery and retrieval of service access tokens.
- Facilitating centralized routing and re-routing across network function producer sets.
- Enabling routing to/from chained SCPs between different SCP domains or data centers.
- Implementing centralized prioritization of traffic.
- Managing load, overload, and congestion centrally.
- Enforcing security policies centrally.
- Introducing and removing network functions transparently to external PLMNs.
- Concealing the 5G core configuration from the external PLMNs.
Centralizing service delivery at the 5G SCP eliminates the necessity of implementing these services separately across all network functions within the 5G core, thus obviating the need to synchronize the product roadmaps of multiple suppliers for each new discovery, routing, or security policy feature. Together with the 5G SEPP, the 5G SCP assumes a pivotal role in enhancing the performance, scalability, security, and manageability of 5G core networks, establishing itself as a critical component in unlocking the full potential of 5G technology.
Titan.ium 5G Service Communication Proxy (SCP)
Titan.ium is a leader in signaling, routing, subscriber data management, and security software and services. Its portfolio encompasses a variety of 2G/3G, 4G and 5G core network functions, including the 5G Service Communication Proxy (SCP), Security Edge Protection Proxy (SEPP), Network Repository Function (NRF), Binding Support Function (BSF) and Network Slice Selection Function (NSSF). All Titan.ium’s 5G products are designed following the best practices for cloud-native microservices-based architectures and associated processes such as continuous integration, testing, delivery, and deployment. Titan.ium's 5G SCP boasts auto-scaling capabilities, ensuring efficient handling of fluctuations in traffic volume while maintaining optimal performance and reliability. Additionally, it employs caching mechanisms for discovered network function profiles, reducing the number of delegated discovery requests sent to the NRF. Leveraging consumer/producer bindings further enhances the benefits provided in conjunction with the Titan.ium's SCP, ultimately outweighing any potential increase in latency associated with routing all 5G core traffic through a centralized component.
Another distinctive feature of Titan.ium’s 5G SCP is the ability to screen any parameter within received messages and alter their content, providing for seamless integration and interoperability with the network functions inside the 5G core. The ability to append content to messages holds particular significance in facilitating information exchange between PLMNs, enabling Security Edge Protection Proxies (SEPPs) to authenticate both the source and destination PLMN IDs, as well as the intended purpose of the connection between the PLMNs. Similarly, the SCP can augment network slice, location, or SCP domain-specific information to the network function profiles registered in the 5G Network Repository Function (NRF), thereby enabling a more refined approach to service discovery.
Robust security and operational efficiency are crucial in the successful delivery of 5G Stand-Alone (SA) services. Titan.ium’s SCP ensures interoperability by strictly adhering to 3GPP standards and by undergoing rigorous module and systems tests. As a cloud-native implementation, Titan.ium’s SCP leverages the inherent robustness and resiliency of the underlying container orchestration platform. Comprising of individual components (containers) deployed across distributed compute nodes, each component is continuously screened for its liveness and readiness ensuring that the communication service is always delivered at required resiliency level. Self-healing, auto-scaling, canary roll-outs and rolling updates enhance the operational experience driven by fully automated rollouts leveraging GitOps and continuous deployment best practices.
A critical aspect of delivering telco services is ensuring uninterrupted service even in the event of a complete site failure. This challenge can be effectively addressed by extending the Container as a Service (CaaS) layer across multiple availability zones at the infrastructure level. In such a setup, the failure of one availability zone doesn't disrupt the deployed solution. However, if the underlying CaaS layer lacks this capability or introduces unacceptable latency to the service, Titan.ium's SCP, like the other 5G products in the Titan.ium’s portfolio, can be deployed across multiple geographically dispersed data centers, each with its own CaaS layer. In this scenario, 5G Network Repository Functions (NRFs) can efficiently share the information about the registered network functions via a high-throughput, low-latency data replication service inherent in Titan.ium's cloud-native platform while the service discovery at Titan.ium’s SCP will prioritize locally registered network functions, ensuring optimal performance. This combination positions the Titan.ium’s SCP as a robust solution for meeting the stringent requirements of the telco industry.
Summary
As the telecommunications industry evolves, the 5G Service Communication Proxy (SCP) stands out as a central hub component, facilitating indirect communication among network functions, thereby optimizing network traffic control within 5G core networks. The 5G SCP streamlines service delivery by consolidating critical functions such as service discovery, routing, and policy enforcement. By serving as a single point of contact for all consumer network functions within the 5G core and facilitating centralized load, overload, and congestion management, it eliminates the need for separate implementations across multiple network functions. With this, the 5G SCP assumes a pivotal role in unlocking the full potential of 5G technology, empowering Communications Service Providers (CSP) to deliver superior services to their customers.
Titan.ium's Service Communication Proxy (SCP) offers a myriad of benefits tailored for Communications Service Providers (CSP), distinguishing it as a leading solution in controlling the 5G Stand-Alone (SA) core network traffic. Leveraging its cloud-native architecture, Titan.ium's SCP ensures scalability, resilience, and security during fluctuations in traffic volume and in the event of a complete site failure. In 5G core deployments, where all traffic is TLS-encrypted, the Titan.ium's SCP mirrors the routed traffic to external traffic monitoring and network data analytics systems, enabling services that can no longer be delivered using traditional probing solutions. Its ability to screen and modify message parameters enhances interoperability and facilitates seamless integration with network functions, ensuring optimal and uninterrupted delivery of 5G SA services. Examples of real-life use cases include:
- Advanced selection and re-selection of the producer network functions following customer-specific (i.e., user-defined) routing policies applied centrally at the Titan.ium’s SCP.
- Immediate mitigation of implementation gaps on the consumer network functions to enable delegated service discovery by adding any missing mandatory headers at the Titan.ium’s SCP.
- Inserting information (HTTP header) on the Titan.ium's SCP to enable the validation of the source PLMN ID by the Security Edge Protection Proxy (SEPP) in situations where the consumer network functions of the 5G core do not comply with or implement 3GPP R17.
- Override of the URL of the discovered producer network functions, e.g., based on the UE ID, by utilizing override data provisioned on the Titan.ium’s SCP to send traffic across distributed producer network functions that do not register their network function profiles at the required granularity level..
