NFV: Making Networks More Agile

Release Date:2015-03-24 By Zhou Yuxiang Click:

 

 

With the development of intelligent terminals and mobile internet, telecommunications is no longer confined to traditional voice calling and SMS. People are more connected, and in the future, we can expect more and more inanimate things to be connected also. Operators are challenged by emerging OTT services and new business models. Traditional telecom networks are deployed using private platforms and dedicated devices. This means that it takes a long time to deploy a traditional telecom network and network O&M is complicated. Some operators are learning from ISPs and are reforming their deployment and O&M practices to make their networks agile. In October 2012, AT&T, BT Group, and Deutsche Telekom established the Network Functions Virtualization Industry Specification Group (NFV ISG) at the European Telecommunications Standards Institute (ETSI) to promote network function virtualization (NFV). The NFV ISG has released NFV white papers and has put forward its objectives and plans.

 

What Is NFV?
NFV is the migration of telecom devices from existing dedicated platforms to commercial off-the-shelf (COTS) ×86 servers. In existing telecom networks, all devices are deployed on private platforms. All network elements (NEs) are enclosed boxes, and hardware cannot be shared. Each device requires additional hardware for increased capacity, but this hardware is idle when the system is running below capacity. This is time-consuming, inflexible, and costly. With NFV, however, NEs are independent applications that are flexibly deployed on a unified platform comprising standard servers, storage devices, and switches. In this way, software and hardware are decoupled, and capacity for each application is increased or decreased by adding or reducing virtual resources (Fig. 1).



NFV is based on cloud computing and virtualization technologies. Virtualization technologies are break down general COTS computing, storage, and network hardware into virtual resources and decouple applications from hardware so that upper-layer applications can make full use of these resources. Decoupling reduces the amount of time needed to supply resources from days to minutes. Cloud technologies make it much easier to allocate resources according to service load. This improves resource usage efficiency and ensures system responsiveness.


 
A virtual 4G EPC system (Fig. 2) comprises four virtual NEs: two PGWs or SGWs, one MME, and one HSS. Each of these virtual NEs is deployed within a data center and provides the functions specified by the EPC network. In their white paper, the NFV ISG states that NFV
● reduces purchase, development, and O&M costs.
● reduces power consumption.
● enables fast service deployment and innovation.
● enables more efficient testing and integration.
● substitutes hardware deployment with software installation.
● enables different applications, users and tenants to share the same platform.
● facilitates service customization for different physical areas and user groups.
● enables services to be quickly scaled. 
● promotes network openness and service innovation to create new revenue sources.

 

Current NFV
NFV ISG has developed rapidly since it was established. Six plenary conferences have been held; phase one was completed at the end of 2014; and phase two has begun in 2015.
NFV ISG comprises the Technical Steering Committee as well as work groups for architecture of the virtualization infrastructure, management and orchestration, software architecture, reliability and availability, performance and portability, and security. 
The TSC has formulated four general standards, and other work groups have drafted NFV definitions for their areas. The four general standards encompass use cases, architecture framework, terminology for main NFV concepts, and virtualization requirements. A number of vendors and operators have worked together to complete 18 PoCs that verify NFV technologies.
With existing network architecture, the service network and OSS are independent. However, with NFV network architecture, the network is deconstructed both vertically and horizontally. 
Vertically, an NFV network comprises infrastructure, virtual network layer, and operation support layer (Fig. 3).



The NFV infrastructure (NFVI) is a pool of cloud-based resources. It includes multiple geographically separate data centers that are connected by high-speed telecom networks and mapped to the physical infrastructure. NFVI virtualizes physical computing, storage, and switching and places them into resource pools.
The virtual network layer corresponds to the existing telecom service network. Each physical NE is mapped as a virtualized network function (VNF) or virtual NE. Resources that require VNF need to be broken down into virtual computing, storage, and switching resources. Traditional 3GPP and ITU-T network interfaces are used to interconnect VNFs as usual, and the VNF service network management system (NMS) still uses the NE-EMS-NMS mechanism.
The operation support layer acts as the existing OSS/BSS and must be altered for virtualization.
Horizontally, the NFV network comprises service network domain and MANO domain. 
The service network domain acts as the existing telecom service network.
The MANO domain differentiates the NFV network from traditional networks. It manages and orchestrates all NFVI resources, maps and associates service networks and NFVI resources, and implements OSS service resource procedures.
A service network includes a VNF forwarding graph (VNF-FG) comprising a group of VNFs and VNF links (VNFLs). Each VNF includes a group of VNF components (VNFCs) and internal connection graphs. Each VNFC is mapped as a VM, and each VNFL corresponds to an IP connection for which certain link resources (traffic, QoS, and route parameters) need to be allocated.
A service network can be broken down level by level according to the MANO. Then, NFVI allocates related resources in the same manner as VMs. VNFL resources need to interact with the bearer network NMS and are allocated by the IP bearer network (Fig. 4).


 
Many vendors have performed PoC tests on the NFV architecture and verified systems such as vIMS, vEPC, vCPE, and vCDN. NFV architecture was demonstrated at the WRC2014 annual conference, where it was shown that NFV technologies are feasible.

 

Development of NFV Technology
NFV technologies are feasible but are still a long way from being put into commercial use.
The demands on NFV technologies are exacting. At the end of phase one, the TSC had formulated only four general standards, and other working groups had not yet completed their definitions. Many issues have been held over to phase two, which means that existing NFV standards are less mature than expected.
NFV is an extensive architecture and with multiple new interfaces. The role of telecom vendors has been redefined so that they are now not only hardware suppliers but also suppliers of virtualized-management software, virtualized telecom network software, and NFV orchestrator (NFVO) software. Telecom vendors will also be NFV system integrators. Now, multiple vendors are responsible for software and hardware integration during network deployment, which increases complexity. NFV itself defines standards only at the architecture level, and open-source and other third-party technical organizations are needed to define and implement specific interfaces. This weakens technical standards to some extent and increases the likelihood of future incompatibility between devices of different vendors.
In the service network, less advanced self-organization network (SON) technologies reduce network flexibility. In an NFV architecture, the MANO automatically deploys resources required by a new VNF. The O&M architecture of the service network, however, still depends on the traditional EMS/NMS mechanism, and connections and traffic routes between VNFs need to be manually configured. Therefore, plug-and-play is not possible in a VNF. Industry needs to develop SON technologies for the service network and decouple them from VNF vendors in order to manage the VNFs of multiple vendors.
Reliability of 99.999% needs to be guaranteed for traditional telecom applications as well as NFV. Traditional hardware is designed for high reliability, but COTS devices used for NFV are less reliable. NFV can be made more reliable by improving the reliability of the software.
Dedicated chips are used for user-plane devices. The x86 devices, however, are less cost-effective in terms of packet processing. This hampers device integration after virtualization. SDN and intelligent network card technologies can be used to address this issue. Specifically, SDN technologies are used to separate control and bearer services for user-plane devices and process packet forwarding on SDN switches. The intelligent network cards of servers have packet in-built processors to reduce packet processing loads.
Compared with computing and storage virtualization technologies, network virtualization technologies are less advanced, and SDN is not mature. It remains a significant challenge to integrate various network virtualization technologies into NFVI. In most cases, the service network is distributed and requires many network resources to be configured to carry services. These resources need to be allocated to LANs within data centers, bearer networks between data centers, and bearer networks between service networks and access networks. Allocating bearer network resources may also involve allocating transport network resources. All resource allocation needs to be virtualized and automatic. However, resources are allocated using the NMS of the bearer or transport network and is far from automatic. It is most likely that SDN technologies will allocate resources automatically by working with NFV.
NFV is designed to resolve automatic deployment issues in the service network. NFV is a large ICT system-integration project within architecture. It encompasses the integration of NFVI, VNFs, and service network and involves many systems, vendors, geographical areas, and interfaces. It involves a higher degree of engineering difficulty than public and private cloud deployment. Automatic deployment includes all the planning, commissioning, upgrading, optimization, and O&M related to a telecom network but increases implementation complexity and is more demanding on the technologies of integrators.

 

Prospects
NFV will reform traditional network deployment models and will expand the scope of operators in terms of infrastructure. NFV converts data center devices, bearer network devices, virtualization software systems, and MANO systems into infrastructure. It replaces service deployment with software deployment and matches in real time service network resources and loads. This makes resource usage much more efficient. Despite its immaturity and issues, NFV is expected to be commercialized within three to five years through common effort of industry.
When NFV architecture is used, telecom networks will improve markedly in terms of automatic management and agility. The deployment timeframe for a telecom device will be hours rather than months, and the time needed to expand capacity will be measured in minutes rather than weeks. New network services will be deployed in weeks, which will help operators become much more agile.