Using Session Routing Engine as a load balancer

This post, whilst it may at first glance look like a bit of a sales pitch for the Netaxis Session Routing Engine, looks at some very valid scenarios in the modern telecoms network where using SRE makes a lot of sense.

As the world of virtual networking matures many telecoms network operators are realising the benefits and adopting virtual solutions. Most vendors in this space now offer their products as Virtual Network Functions. The advantages of virtualization are clear, both from an operational and financial perspective. For example the speed with which new servers can be turned up drives big economies.

The problem is often one of performance. Classically a traditional hardware appliance based solution will have a higher functionality specification than a VM especially in instances where media is involved: a Session Border Controller or Media Gateway for example. In such circumstances, where anything up to 5 VMs may be required instead of a single appliance, load balancing is needed to efficiently distribute traffic across the multiple SBCs.

Most available load balancers work in same way employing predefined algorithms to determine routing and using statistical data based on criteria such as source IP addresses, VLAN tagging and interface information. This is fine but does lack an element of flexibility – who knows what your network will evolve to look like in five years time?

In fact load balancers, because they have to handle signalling, become a cornerstone of a voice network and need to be able to cope with the evolution of this network. Think adding corporate customers, think Fixed Mobile Convergence and VoLTE. Enter Netaxis Session Routing Engine stage right.

SRE is natively design to be highly flexible. SRE simplifies the job of interfacing with 3rd Party equipment and with its Service Logic Editor offers a fully customisable load balancing algorithm and uses a fully customisable data model where the internal database is built on a project basis.

SRE is natively designed to gather information from external platforms via APIs (and cache mechanism). SRE can collect useful subscriber information from user databases such as a HSS or Applications Server for subscriber based load balancing.

VoLTE is an example. Picture a temporary event at a specific location where a telco opts to deploy a new virtualized SBC close to that location. SRE can use subscriber location information obtained by querying the HSS in determining how to accommodate the temporary SBC in the traffic plan.

Using SRE allows telcos to define with database parameters can be used in making routing decisions, eg customer contract information, PBX type (number of simultaneous calls, transcoding capacity, location specific information to name but a few) or even smartphone brand. There are many inputs that could contribute to the load balancing decision. Data contained in the SIP header for example or type of codec being used. Even the CPU usage of a given SBC (driven perhaps by how much transcoding is being processed at a given point in time).

All this points to the need for intelligent load balancing and this, like I said, is where Session Routing Engine comes in.