As you are reading more about NFV and the ETSI Framework, you will notice the high amount of acronyms which all relate to Network Functions Virtualisation. These for many are new terms and relate to the new skillset required in understanding NFV and the industry in general.

That of course is not the only challenge and I am over simplifying. The main challenge in my view is the lack of understanding on how big the potential transformation of the network will be and how long this can take, both from the vendor and the operator. Some operators see the challenge as quite high, and often get nervous when deadlines are being applied to make a % of the network virtualised using NFV Architecture.

This inevitably leads to operators reaching out to the large single stack vendors for guidance and ultimately being chosen to provide the entire stack, or even if the budget is there, for multiple large vendor NFV silos for each of their own product portfolio, being told that their own products work best within their own NFV stack.

If this is the case, the operator has missed a chance to transform their network into a best of breed network function offering. The benefits of this transformation cannot be understated if done right, it is the chance to move away from bare metal legacy equipment, standardise the SLA commitments, centralise the management capabilities from a number of different vendors, and with the rise of automation the ability for self-healing and other lifecycle events will greatly improve the network resilience and deliver Service Agility. Many of the big operators can clearly see this next generation network leveraging NFV is where they need to go to deliver the kind of services to meet the explosion in demand from them and with that, everyone should take note of the efforts underway with them and how they can apply their approach to benefit them.

Finally with this approach, it will allow the introduction of smaller vendors into an operator’s network which can be trialled easily in a NFV lab environment and deliver capability much more quickly than the big single stack vendors as they would have adhered to open APIs by needing to work with as many ecosystems as possible.