Two Critical Features Service Providers Need to Unleash Real-Time Communication Services in the Cloud

June 15th, 2016

What’s holding service providers back from making a more complete migration of real-time communication services to the Cloud? Is it concerns about how to deploy and manage these services in the Cloud? Fear of the unknown? Or how about simply a slow start on the eventual migration path? It could be a combination of the above or a number of other legitimate reasons. However, as we look at our customer’s POCs, field trials and live networks, it shouldn’t be because it’s too difficult to dynamically deploy and manage a virtual Session Border Controllers (SBC).

A virtual SBC is an integral part of any real-time communication service in the Cloud. By using service orchestration, it’s now possible to have on-demand instantiation of an SBC as a Virtual Network Function (VNF). One significant advantage of this virtualized, Cloud environment is the ease and speed with which a VNF can be deployed. With the ability to instantiate a VNF on-demand, it becomes possible to very closely match service sizing with actual demand, scaling up when load increases and scaling down when load subsides. This is what we call cloud elasticity.

When I think about the benefits of cloud elasticity in the context of a virtual SBC, I think about how it enables rapid support of new services or enhancement of existing ones. I also think about how it enables the handling of temporary bursts in high traffic volumes, such as those that might be seen during Mother’s Day. By capitalizing on the flexibility of virtualized SBCs, service providers can reinvent how they deliver their real-time communication services in the Cloud.

However, in order to become truly cloud elastic and derive the greatest benefit from on-demand scaling, the instantiation of SBC VNFs need to be automated and each SBC instance needs to be turned-up as run-time ready.

So, how would this work? Let’s get a bit technical.

When a new SBC VNF is instantiated, there needs to be a mechanism for automatic registration with its associated management domain to support a seamless notification to discover and register each newly created SBC instance. This means that each newly created SBC instance will automatically show up in the management domain and get provisioned without any user intervention.

More specifically, when an SBC VNF is instantiated, its IP networking information, such as network interface IPs, default gateways and DNS servers, must be provided by the management domain to the SBC without manual intervention. Because dynamic startup and shutdown is possible, the size of an SBC cluster can be transparently and dynamically increased and decreased from a service orchestration solution in order to match variable traffic demand.

Yet, automated registration and discovery is only the first step. In addition to IP network information, achieving a run-time ready SBC means the instantiation of an SBC VNF must also have access to its feature configuration information. Because there could be multiple cloud environments, platforms and SBC feature configurations, it’s imperative to have support for a configuration catalog so the necessary configurations are created offline and pre-associated with a given cloud or SBC cluster.

When an SBC VNF is instantiated within a given cluster, it’s provided the name of its configuration object and the parameters necessary for communicating with the configuration catalog. As part of the boot up process, the SBC will automatically receive the appropriate configuration from the configuration catalog.

The end result: the instantiation of a running, configured SBC that is immediately capable of call processing requiring no operator intervention.

For Sonus, it has been our priority to ensure our virtual cloud-based SBC delivers this automatic configuration capability so customers can maximize the achievable value of cloud elasticity. Without these automatic configuration capabilities, instantiating a virtual SBC would require manual processing that consumes time and resources. This would substantially reduce the value of the dynamic, virtualized cloud deployment model. With Sonus, it’s possible to unleash real-time communications in the Cloud and finally free the SBC deployment model from hardware constraints.