Skip navigation
Like what you’re reading?

Stuck in a traffic jam: easing congestion in 5GC SA networks

All things in this world have their upper limit: cars, humans, even telecom networks. This makes maximizing throughput a complex challenge. Removing one bottleneck doesn’t guarantee you won’t just hit another one – after all, the money you are willing to invest is always limited. How do you find a good balance? To maximize return on investment each component should be equally capable, with the weakest link in the chain defining the overall throughput.

Strategic Product Manager

Stuck in a traffic jam: easing congestion in 5GC SA networks

Strategic Product Manager

Strategic Product Manager

One can think of 5G Core standalone (5GC SA) as having an onion architecture: the traffic first traverses through client nodes before hitting the service communication proxy (SCP), with the server node serving as the final destination. The most ideal place to perform throttling is as close to the source of the overload as possible. In the 5GC SA context that is through the client nodes. However, applying rate limits doesn't offer network-wide protection nor provide any dynamic behavior. How can we overcome this to maximize throughput? I believe the 3 Protection Lines model provides the answer.

Figure 1: Maximize network throughput by applying the 3 protection lines model

Figure 1: Maximize network throughput by applying the 3 protection lines model

This solution sees the server nodes convey information about their load situation. The 3GPP has standardized the overload/load control information (OCI/LCI) mechanism. In that way, one can move away from static limits to dynamic load control where servers signal overload when the load exceeds their actual capabilities. The same can be achieved by sharing the load status via the network repository function (NRF). The server load reporting to the NRF is done in configurable intervals so this approach comes with some delay. When the OCI/LCI is combined with the SBI message priority then we have gotten already pretty far protecting networks from signaling spikes. What is the value add coming from the Service Communication Proxy (SCP)?

The SCP can harmonize the load balancing and failure behavior and can also compensate for incomplete client support. If a client lacks the OCI/LCI support, the SCP can take a reacting role and start throttling based on the instructions coming from the servers. Additionally, the SCP has one great benefit: it knows the overall traffic volumes on the network level and how the traffic is distributed across different interfaces. We see overload situations in the 5GC SA where, for example, sudden signaling spikes from the packet core domain eats up all UDM bandwidth, leaving nothing left to the voice traffic – the IMS network that is taking care of the voice traffic goes completely silent. The SCP provides the means to guarantee certain bandwidth to each interface. When you combine that with the service-based interfaces (SBI) message priorities, you’ll have a network that rocks!

Another obvious benefit from the SCP is that it simplifies the network architecture. This is especially important for large size 5GC SA deployment. This simplification contributes to the green light wave in various ways.

Figure 2: The SCP transforms complex architecture to well-defined structures

Figure 2: The SCP transforms complex architecture to well-defined structures

Big 5GC SA deployments consist of hundreds or even thousands of client nodes. Client nodes from different suppliers can handle the load balancing and error scenarios slightly differently. But when those actions are centralized to the SCP, the behavior is always consistent. The risk of human configuration mistakes is also minimized. Configuring the centralized SCP is easier then distributing and configuring the functionality of more than a thousand client nodes. Localizing faults becomes faster since consolidating monitoring and tracing to the SCP provides a better view to the network.

In addition to well thought out network architecture, the network functions’ (NF) internal architecture should be designed or provisioned so that it doesn’t introduce internal NF bottlenecks. You can read more about that topic in our next upcoming blog post publish on July 21, where our chief architect, Sven Steinacker shares his thoughts. Until then, we wish you many successful signaling transactions in high traffic load scenarios!

For more information about DSC and SC, please visit the Ericsson Portfolio:

Diameter Signaling Controller

Signaling Controller

More about 5G Signaling:

5G Signaling strategy

On-demand webinar: Be prepared for the unexpected - Ericsson Signaling Controller

Read more:

Discover how 5G core unleashes a new era of scalable and service-rich cloud-native networks.

Explore 5G core solutions that make it possible for you to deploy, scale and evolve your operations across multiple deployment scenarios.

Explore the fundamentals of modern network architecture and how it is driving a new era of agile, cloud-native network operations. 

The Ericsson Blog

Like what you’re reading? Please sign up for email updates on your favorite topics.

Subscribe now

At the Ericsson Blog, we provide insight to make complex ideas on technology, innovation and business simple.