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.
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.
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.
Network APIs: Unlocking new value in the telco cloud
Network APIs may offer an answer to the question of how to monetise recent and upcoming telco cloud deployments. Virtualised networks upgrade APIs and enhance the value they offer to developers and customers. To unlock their potential, telcos should focus on optimising their commercial models.
Network Futures overview pack
Our Network Futures Service provides a roadmap for new network ownership, regulation and partnership models, and insights. into new technologies, industry dynamics and new players.
Core-as-a-Service since 2018: Wgtwo
Core-as-a-Service is not a brand new concept. Working Group Two, aka wgtwo – a smaller Scandinavian outfit, has been offering Core-as-a Service since 2018. We spoke to their CEO Erlend Prestgard about why wgtwo’s original mission to help telcos extract more value from connectivity remains as relevant in 2022.