The quiet progress of Network Functions Virtualisation

Network Functions Virtualisation (NFV) is a term less often heard these days.

Yet the technology framework that kickstarted a decade of network transformation by the telecom operators continues to progress.

Bruno Chatras

The working body specifying NFV, the European Telecommunications Standards Institute's (ETSI) Industry Specification Group (ISG) Network Functions Virtualisation (NFV), is working on the latest releases of the architecture.

The releases add AI and machine learning, intent-based management, power savings, and virtual radio access network (VRAN) support.

ETSI is also shortening the time between NFV releases.

“NFV is quite a simple concept but turning the concept into reality in service providers’ networks is challenging,” says Bruno Chatras, ETSI’s ISG NFV Chairman and senior standardisation manager at Orange Innovation. “There are many hidden issues, and the more you deploy NFV solutions, the more issues you find that need to be addressed via standardisation.”

NFV’s goal

Thirteen leading telecom operators published a decade ago the ETSI NFV White Paper.

The operators were frustrated. They saw how the IT industry and hyperscalers innovated using software running on servers while they had cumbersome networks that couldn’t take advantage of new opportunities.

Each network service introduced by an operator required specialised kit that had to be housed, powered, and maintained by skilled staff that were increasingly hard to find. And any service upgrade required the equipment vendor to write a new release, a time-consuming, costly process.

The telcos viewed NFV as a way of turning network functions into software. Such network functions - constituents of services - could then be combined and deployed.

“We believe Network Functions Virtualisation is applicable to any data plane packet processing and control plane function in fixed and mobile network infrastructures,” claimed the authors in the seminal NFV White Paper.

A decade on

Virtual network functions (VNFs) now run across the network, and the transformation buzz has moved from NFV to such topics as 5G, Open RAN, automation and cloud-native.

Yet NFV changed the operators’ practices by introducing virtualisation, disaggregation, and open software practices.

A decade of network transformation has given rise to new challenges while technologies such as 5G and Open RAN have emerged.

Meanwhile, the hyperscalers and cloud have advanced significantly in the last decade.

“When we coined the term NFV in the summer of 2012, we never expected the cloud technologies we wanted to leverage to stand still,” says Don Clarke, one of the BT authors of the original White Paper. “Indeed, that was the point.”

NFV releases

The ISG NFV’s work began with a study to confirm NFV’s feasibility, and the definition of the NFV architecture and terminology.

Release 2 tackled interoperability. The working group specified application programming interfaces (APIs) between the NFV management and orchestration (MANO) functions using REST interfaces, and also added ‘descriptors’.

A VNF descriptor is a file that contains the information needed by the VNFM, an NFV-MANO functional block, to deploy and manage a VNF.

Release 3, whose technical content is now complete, added a policy framework. Policy rules given to the NFV orchestrator determine where best to place the VNFs in a distributed infrastructure.

Other features include VNF snapshotting for troubleshooting and MANO functions to manage the VNFs and network services.

Release 3 also addressed multi-site deployment. “If you have two VNFs, one is in a data centre in Paris, and another in a data centre in southern France, interconnected via a wide area network, how does that work?” says Chatras.

The implementation of a VNF implemented using containers was always part of the NFV vision, says ETSI.

Initial specifications concentrated on virtual machines, but Release 3 marked NFV’s first container VNF work.

The NFV architecture. The colored boxes are additions to the original architecture to support cloud-native functions. Source: ETSI

Release 4 and 5

The ISG NFV working group is now working on Releases 4 and 5 in parallel.

Each new release item starts with a study phase and, based on the result, is turned into specifications.

The study phase is now limited to six months to speed up the NFV releases. The project is earmarked for a later release if the work takes longer than expected.

Two additions in NFV Release 4 are container management frameworks such as Kubernetes, a well-advanced project, and network automation: adding AI and machine learning and intent management techniques.

Network automation

NFV MANO functions already provide automation using policy rules.

“Here, we are going a step further; we are adding a management data analytics function to help the NFV orchestrator make decisions,” says Chatras. “Similarly, we are adding an intent management function above the NFV orchestrator to simplify interfacing to the operations support systems (OSS).”

Intent management is an essential element of the operators’ goal of end-to-end network automation.

Without intent management, if the OSS wants to deploy a network service, it sends a detailed request using a REST API to the NFV orchestrator on how to proceed. For example, the OSS details the VNFs needed for the network service, their interconnections, the bandwidth required, and whether IPv4 or IPv6 is used.

“With an intent-based approach, that request sent to the intent management function will be simpler,” says Chatras. “It will just set out the network service the operator wants, and the intent management function will derive the technical details.”

The intent management function, in effect, knows what is technically possible and what VNFs are available to do the work.

The work on intent management and management data analytics has just started.

“We have spent quite a lot of time on a study phase to identify what is feasible,” says Chatras.

Release 5 work started a year ago with the ETSI group asking its members what was needed.

The aim is to consolidate and close functional gaps identified by the industry. But two features are being added: Green NFV and support for VRAN.

Green NFV and VRAN

Energy efficiency was one of the expected benefits listed in the original White Paper.

ETSI has a Technical Committee for Environmental Engineering (TC EE) with a working group to reduce energy consumption in telecommunications.

The energy-saving work of Release 5 is solely for NFV, one small factor in the overall picture, says Chatras.

Just using the orchestration capabilities of NFV can reduce energy costs.

“You can consolidate workloads on fewer servers during off-peak hours,” says Chatras. “You can also optimise the location of the VNF where the cost of energy happens to be lower at that time.“

Release 5 goes deeper by controlling the energy consumption of a VNF dynamically using the power management features of servers.

The server can change the CPU’s clock frequency. Release 5 will address whether the VNF management or orchestration does this. There is also a tradeoff between lowering the clock speed and maintaining acceptable performance.

“So, many things to study,” says Chatras.

The Green NFV study will provide guidelines for designing an energy-efficient VNF by reducing execution time and memory consumption and whether hardware accelerators are used, depending on the processor available.

“We are collecting use cases of what operators would like to do, and we hope that we can complete that by mid-2022,” says Chatras.

The VRAN work involves checking the work done in the O-RAN Alliance to verify whether the NFV framework supports all the requirements. If not, the group will evaluate proposed solutions before changing specifications.

“We are doing that because we heard from various people that things are missing in the ETSI ISG NFV specifications to support VRAN properly,” says Chatras.

Is the bulk of the NFV work already done? Chatras thinks before answering: “It is hard to say.”

The overall ecosystem is evolving, and NFV must remain aligned, he says, and this creates work.

The group will complete the study phases of Green NFV and NFV for VRAN this summer before starting the specification work.

NFV deployments

ETSI ISG NFV has a group known as the Network Operator Council, comprising operators only.

The group creates occasional surveys to assess where NFV technology is being used.

“What we see is confidential, but roughly there are NFV deployments across nearly all network segments: mobile core, fixed networks, RAN and enterprise customer premise equipment,” says Chatras.

VNFs to CNFs

Now there is a broad industry interest in cloud-native network functions. But the ISG NFV group believes that there is a general misconception regarding NFV.

“In ETSI, we do not consider that cloud-native network functions are something different from VNFs,” says Chatras. “For us, a cloud-native function is a VNF with a particular software design, which happens to be cloud-native, and which in most cases is hosted in containers.”

The NFV framework’s goal, says ETSI, is to deliver a generic solution to manage network functions regardless of the technology used to deploy them.

Chatras is not surprised that the NFV is less mentioned: NFV is 10-years-old and it happens to many technologies as they mature. But from a technical standpoint, the specifications being developed by ETSI NFV comply with the cloud model.

Most operators will admit that NFV has proved very complex to deploy.

Running VNFs on third-party infrastructure is complicated, says Chatras. That will not change whether an NFV specification is used or something else based on Kubernetes.

Chatras is also candid about the overall progress of network transformation. “Is it all happening sufficiently rapidly? Of course, the answer is no,” he says.

Network transformation has many elements, not just standards. The standardisation work is doing its part; whenever an issue arises, it is tackled.

“The hallmark of good standardisation is that it evolves to accommodate unexpected twists and turns of technology evolution,” agrees Clarke. “We have seen the growth of open source and so-called cloud-native technologies; ETSI NFV has adapted accordingly and figured out new and exciting possibilities.”

Many issues remain for the operators: skills transformation, organisational change, and each determining what it means to become a ‘digital’ service provider.

In other words, the difficulties of network transformation will not magically disappear, however elegantly the network is architected as it transitions increasingly to software and cloud.