NFV Evolution: Defining the Missing Link

While ETSI’s framework offers a nice overview of NFV, there are many pieces left out of the equation.
As you can see, although ETSI has defined a framework for NFV, there are numerous elements and challenges that arise in real-world implementation that are beyond the scope of ETSI’s architecture. These challenges are particularly painful in multi-vendor environments, such as mobile networks, and the reason the technology is not coming online as fast as operators demand.

In the ETSI architecture, the interface between element management systems (EMSs) and virtualized network functions (VNFs) is classified as out of scope by ETSI, with the expectation that NFV vendors will supply this interface. ETSI’s framework does not address the management and orchestration of the actual VNFs being deployed on that infrastructure (beyond starting and stopping VNFs). The various VNFs are controlled by closed and static vendor-specific EMSs that do not support automation.  The following problems arise:

  1. EMS sprawl: no single console to the VNFs, learning curve for various EMS systems, no automation, OPEX/CAPEX cost of EMS
  2. Amplification of existing bottlenecks: assuming closed EMS systems in place, manual work and OSS integration efforts will increase since the requirements for dynamic services are increasing with NFV.
  3. Orchestration sprawl (on the north side): automation requirements ripples to the orchestrator on the top which will be a very complex integration task.
Ultimately this short-circuits the promises of NFV. Instead of increased agility, faster time to market, reduced complexity, and cost reduction, service providers are bogged down by more complexity and costly, time-consuming data transformation projects—headaches they know all too well. The fundamental problem, which at least 13 service providers recognized in 2012,  is that for NFV to truly deliver, orchestration of all functions must be automated and, in current implementations, this is not the case.

What is required is a network service orchestration system providing a service-oriented northbound API based on data models and transactions. This removes the need for EMSs and it provides automated real-time service provisioning.

Service orchestration

Network Control System (NCS) from Tail-f Systems is one of the products available today that addresses these issues. NCS is a software solution for provisioning multi-vendor services and configuring network devices in a virtualized network environment. As you can see in figure 3, NCS functions as a service orchestration system between network functions and the BSS.

Source: Tail-f Systems

Currently, vendors take different approaches to service orchestration. Single-vendor solutions typically focus on making their existing physical solutions work with NFV. NCS accommodates multi-vendor service provisioning and offers a clear path from existing networks. This is the key to accelerating new service delivery, as it accommodates the way networks and service provider organizations exist today, in addition to what they may look like in the future.


Latest Updates