As the telecom world moves closer and closer to software- based infrastructure, many questions are being asked about scalability of these software-based infrastructure solutions. After all, when there are hardware cards full of Digital Signal Processors (DSPs) you could simply plug in more boards or add more systems (at greater cost) to get to the scalability desired. In the software world, when using a single machine, the scalability is directly related to the power of the processor used in the box.
One model to obtain higher scalability with software would be to use software-based infrastructure software to start, and then use DSP assist to get higher scalability. But this defeats the purpose of going with software in the first place. First of all it’s no longer software running on Commercial off-the-shelf (COTS) hardware so expensive hardware will need to be deployed. Using COTS servers with software running on them, where on premise or in cloud, costs less than specialized hardware solutions. And employing virtualization even on the same server means even more efficiency because multiple software programs can share the same COTS environment. These are core tenets of the move to Network Function Virtualization (NFV). Additionally, time to innovation is much faster with software. New features and enhancements can be added to a software- based solution more easily via a software upgrade as opposed to trying to upgrade a piece of hardware.
What is the alternative though? There are software mechanisms for scaling that have been tried and true with many software programs in the past. As an ex UNIX System product manager (yes, a long, long time ago) I am very familiar with software-based clustering techniques. Bringing these techniques to software-based communications network infrastructure enables these programs to scale as well.
One such network infrastructure that can scale in this way is the media server. Historically chock full of DSPs because of the intense media resource requirements such as voice and video transcoding and video transrating/transizing, huge inroads have been made with software-based media servers over the past few years that allow them to run in service provider environments. For one, Moore’s Law has now enabled 2,000 channels of voice to run comfortably on a single machine. That will continue to contribute going forward. But those kinds of densities are not good enough for the movement to software- based infrastructure and cloud-based infrastructure.
The media server in the Internet Protocol Multimedia Subsystem (IMS) network is referred to as a Media Resource Function (MRF). The MRF spec calls out an element called the Media Resource Broker (MRB), which is a media resource controller and software load balancer that provides scalability, resiliency and redundancy of media services in the network. The MRB is described in Internet Engineering Task Force (IETF) RFC 6917 as well as the 3GPP specification for IP Multimedia session handling (TS 23.218).
The MRB essentially controls multiple media servers at one time and in this way scalability is achieved. Additionally, the presence of the MRB in the network ensures that media service requests are handled in the most efficient manner possible. The MRB has visibility into both the capabilities (e.g., codec support) and availability of each media server in the network, and routes media service requests to the most appropriate media server accordingly. As such, the current Dialogic MRB can control up to 30,000 sessions at a time. We know how to get higher sessions as well and continue to work on that.
Another benefit is high availability since the MRB can be used to manage multiple media servers in different locations. A software MRB can be deployed in a standalone configuration or as a redundant pair for high availability/scalability scenarios.
When large numbers of media sessions are required, software-based media servers can meet your needs. The era of the hardware-based media server is over.
