With the deployment of long-term evolution (LTE), faster connections have meant carrier networks have faced an unprecedented tsunami of data traffic. For certain markets such as India, where the VoLTE service is provided free of charge for the masses, voice traffic has also increased exponentially.
Consumers are increasingly becoming data native and embracing technology not only as a means of communication – but as part of their digital lifestyles.
Even though the rate of change in customer needs and consumption trends have been disruptive, the digital transformation journey for carriers has not kept up pace with these trends.
NFV to the ‘rescue’, or is it?
Network function virtualization (NFV) and software-defined networking (SDN) are positioned as the next wave of transformation for carrier networks. NFV promises a more efficient and cost effective means to deploy and operate complex networks, as well as automate operational processes to deliver agility.
SDN on the other hand aims to create a programmable IP (IP SDN) and transport fabric (T-SDN) for carrier networks to reduce operational and achieve automation.
SDN also promises to enable new service creation in conjunction with NFV and SD-WAN – so that networks are no longer ‘behemoths’ of disconnected hardware and software, but a fluid and programmable ecosystem as depicted below.
These objectives are headed in the right direction – but to realize them, substantial work is still needed.
Defining SDN and NFV maturity
Any new technology is associated with a suite of glamorous use cases as well as a complete manifesto of promises. However, there is often a significant gap between the promises made and the ground realities. It therefore becomes crucial to define ‘maturity’ means in the context of NFV and SDN, and how we can bridge the gap and achieve economies of scale by leveraging this technology.
SDN and NFV maturity centers on the following key architectural tenets:
- Service assurance and network slicing
Service assurance needs to be examined from the perspective of network slicing and network functions chaining. With NFV and SDN, the paradigm of service assurance has undergone a complete transformation. Visibility into potential service issues need to cut-across VNFs and their overlay networks to provide a complete view, especially when network slicing and service chaining can lead to the creation of new services and use cases. To achieve this, traditional service assurance siloes need to be broken down and a more holistic and integrated view is required for NFV service assurance.
- Resource assurance as an extension to service assurance
To pinpoint the root cause of a service issue, a resource assurance drill-down is required. Every NFV function slice would represent a unique service, each with its own KPIs. For the “network slice” to meet these KPIs, each and every individual resource (VNF) would need to comply with the optimal resource KPI parameters.
- Re-imagining fault and service quality management – enrichment and correlation
One of the most radical shifts in NFV and SDN is how we approach fault management and service quality management for virtual network functions (VNFs) and for the services delivered by them. Traditional carrier networks collect fault data from physical network functions over simple network management protocol (SNMP) and other legacy protocols. This data is then stored in the fault management system, and enrichment happens as a supplementary step. For services, the KPI data flows through another web of complex systems that post-process the physical network function (PNF) counters and applies KPI formulae to comprehend the service experience. There is poor or no correlation between the performance metrics and the fault management traps.
Correlation and enrichment for metric data and fault data is critical to understand the true service experience. Moreover, this correlation needs to take place between the hypervisor, virtual network function component (VNFC) and VNF as a whole, and the network slice the VNF belongs to.
- Leveraging machine learning for NFV elasticity
The concept of elasticity is a central architectural tenet for NFV, but different depending upon the context. Elasticity in the context of a single VNF would entail VNF provider-specific policies for scaling of the VNF as a whole (either horizontally or vertically).
Some VNF providers would have a diverse elasticity policy set for individual VNFCs. Elasticity can also be triggered due to faults at the VNF level – where recovery is not possible, and to preserve network capacity – elastic scaling may be needed.
Apart from VNFs and VNFCs, the elasticity requirements for the virtualized infrastructure manager (VIM) resources also need to be predicted well in advance to automate traditional network engineering functions.
These diverse use cases can only be realized if we implement supervised and unsupervised machine learning in addition to the MANO architecture that ETSI defines. Without basic machine learning, operational processes for SDN and NFV would fall short of carrier expectations.
- VIM management and multi-access edge computing (MEC)
With the advent of MEC, the way VIMs have to be managed and operated needs a re-look. MEC allows the network to extend till the edge (in some cases – even the tower site can be the edge hosting a slice of the cloud RAN architecture for example).
From a NFV standpoint, this requires an end to end process of VIM design, on-boarding of resources (physical and virtual) – metering of hypervisor parameters from potentially hundreds of thousands of MEC VIMs as well as the VNF lifecycle management across this infrastructure.
This presents a completely disruptive scalability challenge for NFV – which has to be architected right the first time.
For carrier-class NFV deployments with effective service and resource assurance – these five architectural tenets need to be implemented at scale. This requires a MANO strategy for carriers that addresses mission critical operational needs of the network.
These architectural constructs also ensure that once networks evolve to 5G – where network functions would be far more elastic and fluid, the NFV architecture does not need a complete transformation.