In the traditional real-time communication, voice sessions have a one-to-one relationship between signaling and media, either with or without transcoding. The service provider defines the application that runs on the device; hence, network element, gateway, or SBC requires single dimensional scaling.

An Integrated Signaling and Media network element (I-SBC) scales horizontally and runs on a custom hardware to provide the required scaling and capacity. The I-SBCs dominates 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 services evolve to support multimedia, the change in traffic turns out to be more dynamic.

As the traditional communication has one session for every media (S1:M1) relation with or without transcoding; the next generation communication has one session with no media (S1:M0), or one session with multiple media (S1:Mn) relation with or without transcoding. Due to this dynamic relation, the next generation communication service requires the following three planes:

  • 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?

The services offered by an I-SBC into individual functions that can scale based on traffic needs. The implementation of distributed functions in the network infrastructure provides SBC applications the ability to distribute more functionalities throughout the network and to utilize network 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 scales independently within its cluster depending on the call and traffic requirements.

Example: Signaling component scales if the traffic requires high signaling such as presence without the media component. Similarly, traffic with high media requirements like video calls, instantiates 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 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 cost. The custom hardware coexists with the 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 to the network in a cluster resulting in switching media at the network's edge rather than backhauling from the core, and reducing media latency and backhauling costs with increased quality of experience. Also, multiple media instances provide resilience by selecting media components from different site.

Sonus Distributed SBC Solution

The D-SBC uses the required Sonus network elements. The SBC function is considered as a cluster providing a specific service:

  • The S-SBC cluster terminates signaling and provides only DoS protection for signaling traffic. This is referred as OpenStack VM instance.
  • The M-SBC cluster acts as a policer or rate limiter for media traffic. This is referred as SBC hardware or OpenStack VM instance.
  • The T-SBC cluster provides media inter-working or transcoding. This is referred as SBC hardware series or OpenStack VM instance.

These clusters coordinate with each other and are linked by S-SBC using the Sonus Media Control protocol on a per-call basis to provide SBC as a service.

Sonus D-SBC Functions

 

 

D-SBC Application as Cluster

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 but with limited capacity. The Cloud service uses one or more cluster applications each running one or more nodes providing a specific service. The D-SBC architecture breaks all the services into separate functions known as clusters (S-SBC cluster, M-SBC cluster and T-SBC cluster). For more information on creating D-SBC SWe clusters on the EMS, refer to Creating an SBC SWe Cluster.

  • No labels