Page History

This section describes the basics of the SBC SWe Cloud architecture model.

Distributed SBC 

In traditional real-time communication, voice sessions have a one-to-one relationship between signaling and media (S1:M1), either with or without transcoding. The service provider defines the application that runs on the device; hence, network elements, gateways, or SBCs require single dimensional scaling.An  A traditional, integrated signaling and media network element (integrated SBC, or I-SBC) scales horizontally and runs on a custom hardware to provide the required scaling and capacity. I-SBCs dominate the network traffic in service provider networks. The SBC hardware series is designed to process and transcode more calls, utilizing all the available media resources. But as effectively meets the requirements of this type of session. I-SBCs often run on custom hardware and are scaled horizontally to provide a deployment its required capacity. 

As services evolve to support multimedia sessions, the change in traffic turns out to be traffic becomes more dynamic. As the traditional communication has one session for every media (S1:M1) relation with or without transcoding; the The next generation communication has may have one session with no media (S1:M0), or one session with multiple media (S1:Mn) relation relationships, with or without transcoding. Due to this dynamic relation, the next generation communication service requires 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

Why Distribute the SBC?

Spacevars
0 company

 Distributed SBC Solution

The D-SBC architecture breaks the main SBC functions into separate services and assigns them to separate 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 

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.

Why Distribute the SBC?

The D-SBC architecture distributes functions throughout the network to utilize network resources The implementation of distributed functions in the network infrastructure provides SBC applications the ability to distribute more functionalities throughout the network and to utilize networks 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 distributed SBC (D-SBC) each component scales can scale independently within its cluster depending on the call and 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, requires 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 functions such as 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 protectionProtection: Reusing existing custom hardware for media interworking saves cost. The custom Custom hardware coexists can coexist with the software media components providing media inter-working services. Also, when required it is invoked as an external media server.
• High Resilience with Low Media Latency: Geographically separated media components are deployed closer clusters can be deployed closer to the network in a cluster resulting edge of the network. This results in switching media at the network's edge rather than backhauling from the core, and reducing edge instead of backhauling to the core. This reduces media latency and backhauling backhaul costs with increased quality of experience. Also,  The use of multiple media instances provide resilience by selecting media components from different site.

Sonus Distributed SBC Solution

The D-SBC architecture breaks all the services into separate functions known as clusters. A cluster is a single application consisting of multiple discrete compute elements such as VMs. A cluster includes one application, such as S-SBC or M-SBC, with multiple nodes providing a specific service. The cloud environment supports multiple clusters simultaneously, each providing a specific service:

• 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 Sonus Media Control protocol on a per-call basis to provide SBC as a service.

N:1 Redundancy Architecture

Sonus supports an N:1 mechanism for the SBC SWe Cloud where one standby instance acts as the back up for "N" active SBC instances. In a fail-over scenario, the standby instance takes over and becomes active and the failed active instance becomes standby, once it is up and running.

SBC Redundancy Groups

An SBC Redundancy Group (RG) consists of one or more SBC SWe Cloud instances. All the instances in an RG must have homogeneous resource allocation, configuration and personality. A cluster is a group of one or more SBC RGs. All RGs in a cluster must use the same SBC type (Signaling SBC or Media SBC), which dictates the cluster type such as a Signaling cluster or a Media cluster.

To manage and configure SBC SWe Cloud deployments, you create signaling and media SBC clusters in the EMS GUI just prior to instantiating the SBC nodes. Then when you instantiate the cluster, its nodes register with the EMS so they can be managed and configured using the EMS. Thus the SBC SWe instances in the cluster download their configuration from the EMS.

...

• provides resiliency enabling selection of media service components from different sites.