by Ashish Jain, Director of Solutions Marketing, GENBAND
The move to Network Functions Virtualization is certainly gaining steam. Increasingly, communications service providers are evolving their hardware-based infrastructure to new, next-generation communications networks. The rationale is simple – because of the many benefits offered by the virtualization of network functions including, but certainly not limited to, time-to-market for introducing new services and operational efficiencies.
One of the most critical network functions that communication service providers (CSPs) are looking to virtualize is the Session Border Controller (SBC), which is a vital element in today’s IP communication networks. The SBC is a software function that provides session security, interworking, and advanced session control for real time voice and video communications. Considering their standalone nature, SBCs have minimal dependencies on other key network functions and can evolve independently in terms of network infrastructure. They can also continually interface with other network elements using standard protocols such as SIP.
SBC virtualization provides CSPs with several benefits including:
• Cost efficiencies by leveraging general purpose datacenter platforms and shared infrastructure across multiple applications
• Service agility and faster time-to-market for new services and or new markets
• Operational simplicity for deploying and managing SBCs
• Evolution to cloud-based deployments to achieve dynamic scalability
• Removal of SBC vendor dependencies on hardware lifecycle
• Creation of virtual test environments
But even though the benefits of SBC virtualization are numerous, as with any new technology, there are considerations and challenges that CSPs should be aware of as well.
Make Sure You Have Clearly Defined Virtualization Goals
First and foremost, CSPs should have a clearly defined strategy and goals and know what they want to achieve with SBC virtualization. For instance, are they simply looking to virtualize the SBC function to leverage general purpose platforms in datacenters to reduce dependency on their SBC vendor’s hardware lifecycle and reduce costs? Or do they intend to fully embrace NFV cloud infrastructure to gain a broader set of benefits such as service agility, operational simplicity, dynamic scalability and more?
Given these questions, simple virtualization versus cloud virtualization is the first key decision CSPs need to make. That should be closely followed with the type of infrastructure they will need. The infrastructure requirements will be different for a simple virtualization strategy compared to NFV cloud virtualization.
Understand the Nitty Gritty of SBC Virtualization
The next important set of considerations is to understand how to run SBC as a virtual network function within a virtual or cloud infrastructure. It takes time and planning when considering an SBC virtualization strategy.
There are several things to consider, including:
• Readiness of datacenters to handle real time applications
• Performance assurance in shared infrastructure
• Carrier-grade Five 9’s reliability
• Infrastructure characteristics in terms of type of hardware, hypervisors and cloud
• Deployment strategy – (private, public, or hybrid cloud?)
• SBC virtualization framework
• Characteristics such as integrated versus distributed SBC architecture
• Service characteristics such as consumer, enterprise, mobile, wholesale or interconnect
• Scalability strategy of SBC in a virtualized environment
• Troubleshooting and management
• Cloud Infrastructure ecosystem support
Not all Virtual SBCs are Created Equally
One of the most important components of an SBC virtualization strategy is selecting the right solution and partner. There are several key considerations operators should make before selecting a virtual SBC. If CSPs want to leverage the full potential of cloud NFV deployments, the selection of an SBC must take into consideration whether the SBC is architected for cloud infrastructure such as NFV OpenStack or other similar implementations or if it is architected for just a simple virtualization to run on any general purpose server. Virtual SBC doesn’t always mean cloud NFV support. Make sure you clarify that in the vendor evaluation process.
CSPs should also consider the ecosystem support needed to run the virtual SBC in a multi-vendor cloud environment. It must seamlessly interface with the virtual infrastructure managers and cloud orchestrators that have been selected. In addition, it is important that a cloud infrastructure and virtual SBC solution is carrier-grade, one which ensures Five 9’s or greater reliability when carrying real-time traffic.
Another major consideration is deployment flexibility. The SBC should provide the flexibility to be deployed either as an integrated SBC with both signaling and media functions, or with distributed and separated signaling and media processing functions. Distributing the signaling and media independently brings several benefits in SBC virtualization strategy enabling operators to 1) make a step-wise evolution to the cloud by virtualizing signaling first, and media second, for better economies of scale for media processing such as transcoding functions; 2) gain datacenter optimization by maintaining separate networking infrastructure for signaling (1G) and media (10G); 3) gain cost efficiencies by sharing media resources across multiple signaling instances; and 4) improve quality and reliability by centralizing signaling control and localizing media closer to the customer.
The final major consideration is performance and scalability. One of the major adjustments CSPs have to make in the virtualization environment is a shift from receiving high scalability on a dedicated SBC platform to achieving similar scalability by running multiple smaller virtual SBC instances on a farm of general purpose servers – a recommended strategy for cloud deployment. But vertical scaling (rack and stack) of virtual SBC instances can introduce numerous new operational challenges in a large scale deployment. The virtual SBC should support cloud managers to provide the intelligence to dynamically scale up or down based on network traffic demands – a concept that is generally called elastic scalability in cloud deployments.
From a CSP’s perspective the benefits of deploying virtual SBCs in the cloud far outweigh any potential challenges. From providing consistency in services across geographic locations, to improving the quality of service and service availability, to operational simplicity, to service agility, SBC virtualization offers a great business case. We’re already seeing quite a bit of movement in the market to virtual cloud SBC environments - and that pace should only increase.
Ashish Jain is Director of Solutions Marketing at GENBAND. He brings over 12 years of telecommunications industry experience with expertise in the areas of Real Time Communications for fixed and mobile networks, Wireless Security, Mobile OTT, and enterprise social media applications. In his current role as Director of Solutions Marketing at GENBAND, Ashish drives planning and strategy for mobile security products covering session border controller (SBC), Wireless Access Gateway, Diameter Signaling product line and manages IP based Real Time Communication solution portfolio covering VoLTE, VoWi-Fi, Small Cell, Carrier Wi-Fi, SIP Trunking, and IP Interconnect. Ashish holds a bachelor degree in Electronics Engineering and a Masters in Computer Science, with specialization in networks and communications, from The University of Texas.
The move to Network Functions Virtualization is certainly gaining steam. Increasingly, communications service providers are evolving their hardware-based infrastructure to new, next-generation communications networks. The rationale is simple – because of the many benefits offered by the virtualization of network functions including, but certainly not limited to, time-to-market for introducing new services and operational efficiencies.
SBC virtualization provides CSPs with several benefits including:
• Cost efficiencies by leveraging general purpose datacenter platforms and shared infrastructure across multiple applications
• Service agility and faster time-to-market for new services and or new markets
• Operational simplicity for deploying and managing SBCs
• Evolution to cloud-based deployments to achieve dynamic scalability
• Removal of SBC vendor dependencies on hardware lifecycle
• Creation of virtual test environments
But even though the benefits of SBC virtualization are numerous, as with any new technology, there are considerations and challenges that CSPs should be aware of as well.
Make Sure You Have Clearly Defined Virtualization Goals
First and foremost, CSPs should have a clearly defined strategy and goals and know what they want to achieve with SBC virtualization. For instance, are they simply looking to virtualize the SBC function to leverage general purpose platforms in datacenters to reduce dependency on their SBC vendor’s hardware lifecycle and reduce costs? Or do they intend to fully embrace NFV cloud infrastructure to gain a broader set of benefits such as service agility, operational simplicity, dynamic scalability and more?
Given these questions, simple virtualization versus cloud virtualization is the first key decision CSPs need to make. That should be closely followed with the type of infrastructure they will need. The infrastructure requirements will be different for a simple virtualization strategy compared to NFV cloud virtualization.
Understand the Nitty Gritty of SBC Virtualization
The next important set of considerations is to understand how to run SBC as a virtual network function within a virtual or cloud infrastructure. It takes time and planning when considering an SBC virtualization strategy.
There are several things to consider, including:
• Readiness of datacenters to handle real time applications
• Performance assurance in shared infrastructure
• Carrier-grade Five 9’s reliability
• Infrastructure characteristics in terms of type of hardware, hypervisors and cloud
• Deployment strategy – (private, public, or hybrid cloud?)
• SBC virtualization framework
• Characteristics such as integrated versus distributed SBC architecture
• Service characteristics such as consumer, enterprise, mobile, wholesale or interconnect
• Scalability strategy of SBC in a virtualized environment
• Troubleshooting and management
• Cloud Infrastructure ecosystem support
Not all Virtual SBCs are Created Equally
One of the most important components of an SBC virtualization strategy is selecting the right solution and partner. There are several key considerations operators should make before selecting a virtual SBC. If CSPs want to leverage the full potential of cloud NFV deployments, the selection of an SBC must take into consideration whether the SBC is architected for cloud infrastructure such as NFV OpenStack or other similar implementations or if it is architected for just a simple virtualization to run on any general purpose server. Virtual SBC doesn’t always mean cloud NFV support. Make sure you clarify that in the vendor evaluation process.
CSPs should also consider the ecosystem support needed to run the virtual SBC in a multi-vendor cloud environment. It must seamlessly interface with the virtual infrastructure managers and cloud orchestrators that have been selected. In addition, it is important that a cloud infrastructure and virtual SBC solution is carrier-grade, one which ensures Five 9’s or greater reliability when carrying real-time traffic.
Another major consideration is deployment flexibility. The SBC should provide the flexibility to be deployed either as an integrated SBC with both signaling and media functions, or with distributed and separated signaling and media processing functions. Distributing the signaling and media independently brings several benefits in SBC virtualization strategy enabling operators to 1) make a step-wise evolution to the cloud by virtualizing signaling first, and media second, for better economies of scale for media processing such as transcoding functions; 2) gain datacenter optimization by maintaining separate networking infrastructure for signaling (1G) and media (10G); 3) gain cost efficiencies by sharing media resources across multiple signaling instances; and 4) improve quality and reliability by centralizing signaling control and localizing media closer to the customer.
The final major consideration is performance and scalability. One of the major adjustments CSPs have to make in the virtualization environment is a shift from receiving high scalability on a dedicated SBC platform to achieving similar scalability by running multiple smaller virtual SBC instances on a farm of general purpose servers – a recommended strategy for cloud deployment. But vertical scaling (rack and stack) of virtual SBC instances can introduce numerous new operational challenges in a large scale deployment. The virtual SBC should support cloud managers to provide the intelligence to dynamically scale up or down based on network traffic demands – a concept that is generally called elastic scalability in cloud deployments.
From a CSP’s perspective the benefits of deploying virtual SBCs in the cloud far outweigh any potential challenges. From providing consistency in services across geographic locations, to improving the quality of service and service availability, to operational simplicity, to service agility, SBC virtualization offers a great business case. We’re already seeing quite a bit of movement in the market to virtual cloud SBC environments - and that pace should only increase.
About the Author
Ashish Jain is Director of Solutions Marketing at GENBAND. He brings over 12 years of telecommunications industry experience with expertise in the areas of Real Time Communications for fixed and mobile networks, Wireless Security, Mobile OTT, and enterprise social media applications. In his current role as Director of Solutions Marketing at GENBAND, Ashish drives planning and strategy for mobile security products covering session border controller (SBC), Wireless Access Gateway, Diameter Signaling product line and manages IP based Real Time Communication solution portfolio covering VoLTE, VoWi-Fi, Small Cell, Carrier Wi-Fi, SIP Trunking, and IP Interconnect. Ashish holds a bachelor degree in Electronics Engineering and a Masters in Computer Science, with specialization in networks and communications, from The University of Texas.
