There is a fair amount of buzz around network functions virtualization (NFV) and which use cases provide the most benefit. The ETSI ISG NGV has documented a specific set of use cases that are of special interest to the operator community. Some analyst firms have also conducted surveys to determine the top NFV use cases. There seems to be a general consensus that vEPC, vIMS, and vCPE offer the greatest advantages in terms of innovation and financials.

Why is virtualized testing missing from these NFV use case lists? Considering that CSPs pride themselves on performance and SLAs, I would think that virtualized testing would be high on the interest list. To help make the case for virtualized testing, let me relate two anecdotes.

I was recently having trouble with my internet connection from a Tier 1 cable ISP. I promptly logged a ticket with the provider. As is typical, after a few days, they sent a technician out with the truck and a bunch of test equipment. The technician plugged the test equipment into my cable router/modem and ran some throughput, packet latency, and drop tests. The problem was diagnosed, fixed to my satisfaction, and then he left.

Sounds good, right?

Well, it took a few days to get the technician out to my home. He had to lug a bunch of equipment, and he was fortunate that the equipment was sufficient to diagnose and fix my problem during that visit. And, by the way, it costs a few hundred dollars each time the “truck rolls,” as we say in the industry.

Using NFV, the cable provider could have spun up an appropriate virtual testhead on my premises; run the same set of tests; diagnosed the problem remotely; and even fixed it instantly. This test and resolution could have been done while I was on the phone reporting the problem. I believe we could have avoided the service call all together.

Here is my second anecdote. Recently I was talking with the vice president of engineering for a Tier 2 service provider. This CSP is primarily a tech follower, passively monitoring the activity in the SDN/NFV space but not really doing much yet. I brought up the previously mentioned NFV use cases. He was not very impressed and said he would wait until some Tier 1s commercialize NFV.

That’s when I brought up virtualized testing and the opportunities to reduce time and costs to repair among other benefits. That piqued his interest in NFV, but he mentioned a few concerns that I will address below.

Physical testing and test equipment provide a number of advantages and are still necessary in a number of cases. But there are limitations to physical testing that can be overcome with NFV. These include:

• Dedicated hardware that is used only occasionally (for service turn-up and troubleshooting).
• Hardware has to be present at the location where testing is needed. This requires either big stockpiles of equipment and/or extra cost associated with shipping test equipment to various locations as needed.
• Limited ability to troubleshoot due to the limitations of equipment availability. Troubleshooting is often carried out by placing test equipment at multiple locations in order to isolate the problem. When test equipment is limited, the ability to isolate problems is consequently limited.
• Inventory of test equipment for different testing needs and/or capacity.
• With virtual network functions (VNFs), there is a need to test network to VNF, VNF to VNF, and VNF to network performance, and we need to plug into virtual ports, which is not possible with purely physical appliances.

With virtual testing many of the above issues go away. Virtual testheads and probes can be spun up on demand or placed in multiple locations without the challenges of their equivalent physical counterparts.

Inventory then consists of software images of different software VNFs. Virtual testheads can be connected to the virtual ports of the VNFs to enable true NFV environment performance benchmarking. Virtual testers are spun up on shared NFV infrastructure, so no dedicated hardware is necessary. When the task is done, testheads can be spun down and resources released back to other workloads.

So why does virtualized testing get so little attention?

To be fair, we do have some challenges associated with realizing the full benefit of virtualized testing. On the technical side, there are vendors providing virtualized testers that can address a number of the testing use cases. However, when the tester itself is a VNF running in a non-deterministic hypervisor scheduling environment, measuring performance metrics such as latency and jitter can become more challenging. Did jitter arise because the test VNF itself was not scheduled or because the tested VNF was not performing? Was a high latency value reported because the originating and terminating test VNFs were not perfectly synched with each other?

At a broader level, we also need to consider how virtualized testing becomes an integral part of the NFV service lifecycle management, fault detection, and fault mitigation functions and processes.

We also have challenges on the business side. The licensing models for test VNFs have to be tuned to their usage so customers are charged only for use rather than at a flat rate. This will unlock the full benefit of a software-based test VNF.

I believe these challenges can be overcome easily if we as an industry focus on this use case.

Virtual testing can make NFV profitable by providing a full suite of capabilities for certification, activation testing, and ongoing service assurance in a much more dynamic, flexible, and cost-effective way than is currently possible with physical testing.