Overview

In traditional real-time communication, voice sessions have a one-to-one relationship between signaling and media (S1:M1), either with or without transcoding. A traditional, integrated signaling and media network element (integrated SBC, or I-SBC) effectively meets the requirements of this type of session. I-SBCs often run on custom hardware and are scaled horizontally to provide a deployment of its required capacity. 

As services evolve to support multimedia sessions, the traffic becomes more dynamic. Next-generation communication may have one session with no media (S1:M0) or one session with multiple media (S1:Mn) relationships, with or without transcoding. Effective handling requires considering the following three planes independently:

  • Signaling plane: for more IM presence status

  • Media plane: for video, MSRP, multiple streams per session

  • Transcoding plane: for transcoding / transrating / transizing of audio or video

Ribbon Distributed SBC Solution

The D-SBC architecture breaks the main SBC functions into separate services and assigns them to clusters. A cluster consists of multiple discrete nodes supporting one main function, such as signaling or media, with all nodes providing the same service. A virtual environment supports multiple clusters simultaneously, each providing a specific SBC function:

  • The S-SBC cluster terminates signaling and provides only DoS protection for signaling traffic.
  • The M-SBC cluster acts as a policer or rate limiter for media traffic.
  • The T-SBC cluster provides media inter-working or transcoding.

These clusters coordinate with each other and are linked by the S-SBC using the Ribbon Media Control protocol on a per-call basis. A cluster contains one or more SBC redundancy groups (RGs).

SBC Redundancy Groups

An SBC redundancy group (RG) consists of one or more SBC SWe node instances. All the instances in an RG must have homogeneous resource allocation, configuration and personality. All RGs in a cluster must be of the same SBC type (signaling SBC or media SBC), which dictates the cluster type such as a signaling cluster or a media cluster.

D-SBC Deployment Model Example


Why Distribute the SBC?

The D-SBC architecture distributes functions throughout the network to utilize network resources effectively.

The advantages of decomposing include:

  • Flexibility to Scale: In an I-SBC, all the components use the same hardware to service incoming calls on the SBC instance. But, in a distributed SBC (D-SBC) each component can scale independently within its cluster depending on the traffic requirements.

Example: Signaling components can be scaled if the traffic requires high signaling, such as presence without the media component. Similarly, traffic with high media requirements, like video calls, can be served by instantiating more instances in the media cluster. Traffic that needs high transcoding requires instantiating more instances in the transcoding cluster.

  • Service Chaining: The SBC includes call control, routing and policy, signaling normalization, IP firewall and policy, and media transcoding (or trans-rating). Each component of the D-SBC logically provides one or more such functions instantiated in a cluster to support scaling based on the traffic requirement. The signaling component of the SBC chains one or more such functions per call without knowing the media cluster details.
  • Investment Protection: Reusing existing custom hardware for media interworking saves costs. Custom hardware can coexist with software media components providing media interworking services. Also, when required, it can be invoked as an external media server.
  • High Resilience with Low Media Latency: Geographically separated media clusters can be deployed closer to the network's edge. This results in switching media at the edge instead of backhauling to the core, reducing media latency and backhaul costs while increasing the quality of experience. Multiple media instances provide resiliency, enabling selecting media service components from different sites.