Network Function Virtualisation (NFV) – Testing from 30,000 feet
So NFV is the next big thing in telecommunications … But what is it? Let's discuss the challenges and variables involved with the transition to virtual networking.
Historically, telecommunications networks have been built around a range of hardware platforms, upon which bespoke network applications provide specific network element functionality, such as an MSC, SGSN, GGSN, etc. This equipment is usually located in comms/equipment rooms with significant network connectivity, capacity, power and air conditioning requirements. However, networks are not static, but rather continually evolve to meet new needs or provide new opportunities. For example, the Internet of Things (IoT) will certainly drive further capacity needs and is likely to provide opportunities for new innovative services to be developed. As networks grow and evolve, this results in hardware sourced over time from multiple vendors, creating a complex operations and maintenance landscape that requires extensive multi-vendor platform knowledge and supports contracts consequentially driving significant Operating Expenditure (OPEX).
Network operators desire to reduce both Capital Expenditure (CAPEX) and OPEX, as well as the time to introduce new services. Bespoke hardware-centric solutions are unlikely to be the solution. These are not new challenges in the IT world; data centres have been tackling these challenges for a number of years through the provision of pooled compute, network and storage resources via Commercial Off The Shelf (COTS) hardware platforms upon which servers running as Virtual Machines (VMs) execute. It is this same concept which is the foundation for NFV and which network operators are now considering in order to transform their networks, facilitating a reduction in both OPEX and CAPEX in time. In this new paradigm, network applications, such as SGSN, GGSN, HLR, etc, become Virtual Network Functions (VNF) which execute on NFV infrastructure (NFV-I). The NFV-I provides the pooled compute, network and storage resources shared by the VNFs via a type 1 (bare metal) hypervisor and controlled through a Management and Orchestration (MANO) function as shown in Figure 1.
A network application’s specific Element Manager (EM) may also be virtualised, residing upon the same NFVI with northbound connectivity to Operations Support Systems (OSS) and Business Support Systems (BSS) through the abstracted network resources provided by the hypervisor and underlying hardware platform.
Figure 1 shows that NFV decouples the implementations of the network application from the physical compute, storage and network resources through the virtualisation layer. Consequently each VNF implementation will need to consider how these resources are provided and managed in the virtual world, taking into account a new set of Management and Orchestration (MANO) functions and associated information/data models.
An NFV-I instance will support many VNFs concurrently. Consequently the connectivity between network applications which was previously physical (Ethernet for example) will take place within the NFVI (where the communicating applications reside in the NFVI) and through the underlying NFVI hardware for connectivity with non-virtualised applications.
The movement to a virtualised environment provides a number of challenges. A provider will no longer have direct control over the hardware platform upon which their network application executes; it is likely that a network application shall need to execute across NFVIs from a range of NFVI platform vendors.
Utilisation of a common hardware platform for a range of network applications will mean that all applications executing upon it will be constrained by the common performance characteristics of that underlying platform. It is conceivable that NFVIs, at least initially, may have reduced performance characteristics in comparison with bespoke hardware platforms where specific hardware acceleration techniques may have been utilised. This could potentially lead to re-engineering networks in order to increase the number of instances of a specific network appliance to be able to support the same traffic levels; however this will need to be evaluated on a case by case basis.
Security, Resilience and Availability
With network appliances (VNFs) cohabiting on the same execution environment, ensuring security, resilience and availability will require significant focus prior to the deployment of NFV into a live environment. At a minimum, an NFV solution will need to provide the same level of security, resilience and availability as legacy dedicated hardware solutions.
It is unlikely that an NFV solution will initially be deployed to directly replace existing infrastructure in some form of ‘big bang’ roll out. Rather, NFV is likely be deployed alongside existing infrastructure with traffic/services migrating over time. In the short term, this will increase OPEX and CAPEX, the opposite of the long term goals as infrastructure is run side by side, and thus NFV CAPEX and OPEX savings need to be seen as reducing OPEX only in the longer term once legacy systems are decommissioned.
Whilst it is not anticipated that deployment (Orchestration) of VNF instances will be trivial, it is likely to be less complex and intrusive than deploying a new physical network element, thus facilitating improved agility within the network.
The testing associated with NFV will vary depending upon the organisation performing the testing; an NFVI provider will have different testing goals to that of a VNF provider and an operator’s testing needs will again differ to both of these.
Network operators will not only need to assure themselves of the functional and non-functional aspects of an NFV solution itself but also that the business is able to operate, support and maintain the new infrastructure alongside the existing infrastructure, reviewing and where necessary updating business policies, processes and procedures.
From a pure technology standpoint test organisations will need to consider the impact of virtualisation technologies on their test activities taking into consideration new concepts such as automatic migration of virtual machines between hardware resources within the NFVI by the MANO system as the result of the loss of part of the underlying hardware resource or potentially in order to optimise compute, storage or network performance. They will also need to focus on the migration paths from pure legacy to a hybrid network which will be in flux for some considerable time, limiting service impact which will continue to be a critical goal for any migration strategy.
The provision of multiple VNFs onto an NFVI potentially creates blind spots between VNFs where previously test and operations could access network traffic. This may be mitigated by virtual test equipment or monitoring applications which can be inserted between VNFs within an NFVI to eliminate such blind spots but test organisations will need to consider how to access inter VNF traffic at an early stage and investigate what applications are available.
Wider Network Impact
Mobile Network Operators (MNOs) may provide more than just mobile connectivity, for example Landline, Broadband and TV services. NFV has potential to be a cross service domain solution providing pooled resources in support of multiple service domains leading to reduced infrastructure costs as well as potentially providing the ability to leverage efficiencies in operations and maintenace organisations that a common infrastructure would provide. With the same infrastructure across domains the need for separate domain specific support teams and service contracts could be reduced thus reducing OPEX.
NFV is a disruptive technology bringing in a new age in networking infrastructure which offers service agility, improved innovation and a reduction in CAPEX and OPEX in the longer term. However it will not be without its challenges, requiring all levels in an organisation to grasp new concepts and paradigms, likely challenging existing norms for network design, management and operation as well as likely requiring updates to business policies, methods, processes and procedures.
Progress to date has been slow but from current industry reports it appears to be gathering pace with NFVI hardware vendors creating interoperability labs and Proof of Concept (PoC) trials starting to take place.
The next few years are likely to be key as to whether NFV will progress to the point at which network operators ‘bite the bullet’ and direct significant resources to this area but current industry direction is promising.
Click to Tweet!
So maybe NFV is the next big thing in telecommunications… but what is it? Read more about the challenges and variables. >>tweet<<
During the movement to a virtualized environment, a provider will no longer have direct control over the hardware platform >>tweet<<
Deployment of VNF instances will be less complex and intrusive than deploying a new physical network element >>tweet<<
NFV has the potential to be a cross service domain solution providing pooled resources in support of multiple service domains >>tweet<<
Industry reports show that NFVI hardware vendors are picking up pace with interoperability labs and Proof of Concept (POC) trials >>tweet<<