Don’t believe what you’ve heard, NVF is still on the radar for service providers – and for good reason

Network Functions Virtualisation (NFV) has been championed with varying intensity in the telco industry for the past few years, though many claim the technology has lost its appeal. Bart Salaets, Senior Systems Engineering Director at F5, assesses the latest developments in NFV and why service providers need to stay on the ball. READ MORE…
A_city-3999924 1

Bart Salaets, Senior Systems Engineering Director at F5, assesses the latest developments in NFV and why service providers need to stay on the ball

Network Functions Virtualisation (NFV) has been championed with varying intensity in the telco industry for the past few years, though many claim the technology has lost its appeal.

While it is true that adoption rates have fallen short of initial predictions, there is plenty of evidence to suggest that NFV is as relevant as it’s ever been. Perhaps even more so.

Why uptake has been slower than expected

In an NFV architecture, the hardware is decoupled from the software. A common hardware layer (off-the-shelf servers) is leveraged to host a wide variety of vendor-supplied network functions running in virtual machines. These are known as virtual network functions (VNF).

When used optimally, NFV architectures can speed up the enablement of new services and network functions, as well provide near real-time elastic network scaling to reduce total cost of ownership. 

To date, NFV uptake has been slower than expected due to technological complexity and a closely related skill gap. An industry failure to deliver on projected cost benefits early on has also hit confidence levels. On top of that, deploying, patching and orchestrating VNFs from several vendors has proven both difficult and cost prohibitive, if only in terms of sheer compute volume.

Nevertheless – regardless of industry grumblings and deployment bottlenecks – NFV is still very much on most service provider’s radars. And for good reason.

Why service providers need network virtualisation

The simple fact is that service providers need network virtualisation, and thus NFV, because of 5G.

Irrespective of existing rollout roadblocks, 5G technology will rapidly fuel new service use cases, each imposing different network requirements related to speed, latency and isolation.

In order to deliver at scale, the underlying network needs to be software driven and automated. This is why we need NFV: it is a necessary evolutionary steppingstone on the way to all-encompassing virtualisation.

The COVID-19 pandemic has also intensified telcos’ attention on the technology, as the ability to remotely control, manage, and provision network services in a software-defined way is proving increasingly popular.

According to figures from Research and Markets, the global NFV market is projected to grow from $12,9bn in 2019 to $36,3bn by 2024, which represents a compound annual growth rate of 22.9%.

Elsewhere, a survey by Ovum found that 60% of service providers expect to achieve widespread NFV adoption in the next two years (rising from just 20% today).

The same research also suggests that, while some of today’s virtual machines and VNFs will continue into 2030, the organisations running them will likely operate in a markedly different way. This includes service providers becoming more empowered to enhance and launch new services via automation and orchestration tools. These could be commercial platforms delivered by traditional telecom vendors. They could also be the same open source tools their IT and cloud colleagues use (i.e., Ansible or Terraform).

Interestingly, some service providers are now starting to merge their cloud and NFV teams, which will further prompt industry best practices for tool sharing, service deployment and automation.

A little over a year ago, an alliance of telcos and vendors launched the Common NFVi Telco Task Force (CNTT) to simplify NFV standards. CNTT aims to align the industry around unified network functions virtualisation infrastructure (NFVi) implementations to reduce the friction for onboarding virtual network functions (VNFs) and, eventually, container network functions (CNFs). Clearly, NFV is not dead—it is evolving as we speak.

In the foreseeable future, it is a good bet that we will see both VNFs and CNFs being deployed side by side for different functions. In this scenario, we’re likely to see more and more service providers proactively creating and presiding over their own agile, distributed “telco clouds.”

NFV: Not just a one-trick pony

When we talk about NFV, we shouldn’t think about it in isolation. We should consider how we can use it and the transformational benefits it can bring to the end user (à la Rakuten). NFV is not simply about virtualising network functions, it is about delivering a path towards a full cloud native network.

As more networks evolve to NFV, the abstraction of the control and data-forwarding planes will continue to simplify the creation and management of new services. If done correctly, service providers should be able to leverage a programmable network based on industry standard open APIs that unlock new levels of flexibility and agility.

Ultimately, service providers need to think strategically about NFV in the wider context of an adaptive journey. Increasingly, this will entail being a vital cog in the “telco cloud”: an infrastructure built out to the edge with both VNFs and CNFs, as well as applications and their associated services (e.g. load balancing and security)—irrespective of where they are deployed.

While NFV doesn’t need to be re-hyped as the buzziest acronym in the game, it would be a big mistake for service providers to underestimate its enduring (and continually evolving) merits.

Related Posts

Privacy Preferences
When you visit our website, it may store information through your browser from specific services, usually in form of cookies. Here you can change your privacy preferences. Please note that blocking some types of cookies may impact your experience on our website and the services we offer.