NFV Architectural Framework: The ETSI architectural framework explained

Why does NFV need an architectural framework?

Existing telecoms networks are made up of many different types of hardware. Each time a new service is introduced, new equipment must be installed on-site and the network must be reconfigured, which is a timely and costly task that requires trained staff to visit the premises. Network Functions Virtualization (NFV) was introduced as a way to tackle these problems.

The European Telecommunications Standards Institute (ETSI) is a European standards organisation in the telecoms industry. They took the lead on NFV in 2012, and subsequently created the Industry specification group (ISG) to provide a forum for the industry to collaborate on establishing the required standards and supporting the implementation of network virtualisation.

With NFV the software is able to run on generic hardware, which enables networks to become more flexible and agile, and to be run more cheaply. Traditional networks are comprised of network functions that are statically connected in a particular way so they provide a desired overall function.

Virtualisation allows you to connect the network functions using dynamic methods as well as just static ones. However, multiple touch points for management are required, resulting in a more complex architecture than that of traditional networks. Additionally, future network services could be very different to current ones, as they will be made up of both non-virtualised and/or virtualised network functions. This will require legacy network domains to be able to operate in conjunction with NFV-based network domains.

In order for this to be possible, an architecture needed to be established that supported the virtualisation of diverse sets of network functions, and encouraged the standardisation of NFV by addressing interoperability and enabling VNFs to be used in a way that is independent of the vendor supplying them.

High-Level ETSI NFV Framework

As part of their work on defining requirements for NFV, ETSI established the reference architectural framework for NFV. The scope of the framework does not include the aspects of network functions/infrastructure that are common to Physical and Virtualised Functions, such as the specifics of the network functions, the control of the physical network infrastructure, or packet flow and control of the E2E (exchange-to-exchange) network service. Instead it focuses on the changes likely to occur in networks due to the NFV process i.e. the new functional blocks and reference points resulting from the virtualisation of the network.

Figure 1 shows a high-level view of the NFV framework, as established by ETSI.

High Level ETSI Framework

Figure 1- High-level ETSI NFV Framework 

ETSI identified three main working domains:

1) Virtual Network Functions (VNFs)

These are individual functions of a network that have been virtualised. Possibilities are endless – firewalls, Evolved Packet Core, etc.

2) NFV infrastructure (NFVI)

The infrastructure required to run the VNFs. This is made up of hardware resources (computing servers and network switches), and virtual resources (“abstractions” of the hardware on which the VNFs run, known as “virtual machines” (VMs). A virtualisation layer (the “hypervisor”) exists to abstract between the two.

3) NFV management & orchestration (MANO)

MANO is the framework for management and orchestration of all the resources in the NFV environment. It is where the management of resources in the infrastructure layer takes place, and is also where resources are created and delegated and allocation of VNFs is managed.

Full Architectural Framework

For each of the three higher-level working domains, ETSI established individual functional blocks that each have a specific role. These are shown in the full NFV reference architectural framework in Figure 2. It depicts both the functional blocks and the main reference points between these blocks (shown as solid lines linking the blocks together). The functionalities that are necessary for the virtualisation and operation of a network are included in the framework, but it does not stipulate which functions should be virtualised, as this is down to the owner of the network to decide.

 

Full ETSI Framework

Figure 2- ETSI NFV reference architectural framework 

Overall, defining the purpose of each functional block within the ETSI framework has played a key role in creating standards in virtualisation, resulting in NFV solutions that are more homogenous and reusable and can take advantage of economies of scale. However there is still work to be done, and the architecture is continually being built upon as NFV continues to develop.

About Matt Pooley

Virtualisation practice lead

Matt leads STL Partners’ consulting and research activity around virtualisation. He works with leading operators and tech companies across the globe on understanding the telco cloud opportunity, strategies and routes to deployment. He is a regular speaker at industry events, who has authored research on topics as broad as innovation, network experience, and SD-WAN deployment models. Matt holds an MA in Modern Languages from Cambridge, and speaks fluent Portuguese and Spanish.

Read more about Virtualisation, SD-WAN & NFV

Research

NFV Deployment Tracker: North America update

The latest update to our NFV deployment tracker that monitors all commercial deployments globally. New deployments in N America are increasingly driven by 5G, with a striking role for open source and telco self-builds.

Published: June 2019

Read more

Webinar

Virtualisation: Reaching tipping point

A webinar on NFV and SDN. What operators are deploying, what this means, and how 5G is likely to accelerate progress. Based on our unique data on NFV deployments

Live event: May 2019

Register now

Webinar

Edge business models and how to execute them

A joint webinar with MobiledgeX and STL Partners exploring edge cloud business models and the value proposition for application developers in augmented reality

Read more