Home Virtual Probe (vProbe): Why it Has to Be “Native”?

Virtual Probe (vProbe): Why it Has to Be “Native”?

Home Virtual Probe (vProbe): Why it Has to Be “Native”?

Virtual Probe (vProbe): Why it Has to Be “Native”?

by Angela Whiteford
Angela Whiteford

Security, health, and performance of the mobile network are critical for operators. Real time access to this information in a quick, intelligent, and cost- effective way is equally important. Traditionally, this is solved by installing a hardware- based TAP/fiber splitter and network probe/packet broker. But with tremendous growth in number of subscribers, devices, and data usage on the network, network operators are turning to NFV to satisfy this exponential demand.

What are the challenges mobile operators will face in using the existing hardware- based network probe/packet broker?

The first major challenge is when other network elements are virtualized, there are no more clear demarcation points in the network architecture where the probes can be inserted. Additionally, some networks elements are consolidated or collapsed, for example: SAE Gateway. Another major hurdle in this virtualized world, network elements are dynamically created instances, across geographically- disparate locations, and migration of the VMs makes it impossible to use physical splitters. It is difficult and inefficient to use physical L2 switch-based port mirrors.

All the above factors clearly point to virtualized probe solution. But does virtualization solve all the issues? Let’s dig a little bit deeper.

In a virtualized solution, if all the packet mirroring is done by the same vSwitch that is also supporting the VNF- its performance is severely impacted. This is a major problem because while 100% packet mirroring, the I/O in and out of the VNF is either cut in half or needs to be doubled to take this performance hit. Another major challenge is the ability to co-relate control and user plane packets again in the probe as in the network elements. This is clearly inefficient with duplication of correlation and processing functions in probe/packet broker, which is not scalable and definitely not cost effective.

These challenges can be overcome by having a “Native” solution, where the probe/packet broker functionality resides within the VNF network element. This approach solves the problems of performance degradation by vSwitch, duplication of functionality, correlation, and scalability. With this native approach, there is also minimal impact to the existing VNF functionality.

Affirmed Networks with millions of subscribers on our Mobile Content Cloud is uniquely positioned to understand and address this problem.The Affirmed solution is the industry’s first native virtualized probe and analytics solution for mobile networks. Affirmed Networks Active Intelligent Virtualized Probe (vProbe) provides mobile operators with greater visibility into and across their virtualized networks, improving service levels, reducing cost of ownership, and enhancing the overall customer experience.