It’s time for operators to define a plan to take away the complexity of NFV deployment

Alan Burkitt-Gray
Published on:

The first commercial deployments of NFV are likely to be live by the end of 2015, opening up new and exciting business opportunities for operators, writes Phil Tilley. Co-sponsored feature: Alcatel-Lucent

Phil Tilley, Alcatel-Lucent

Phil Tilley: We are demonstrating our NFV capabilities to
help operators identify which functions to virtualise
as a first step

If you think about the types of companies that can launch new services quickly, or scale up capacity to match customer demand where and when it’s needed, network operators might not spring to mind immediately. Service agility tends to be associated with nimble start-ups and internet players not long-established operators encumbered with extensive physical hardware. With the arrival of network functions virtualisation (NFV), however, operators can become much more flexible.

Aside from offering at least the same levels of performance and resilience as services delivered on dedicated appliances, in which software and hardware are tied together, an NFV platform – implemented well – will allow services to be launched instantly where they’re needed using virtual machines (VMs) running on commercial generic servers. To reduce latency or avoid hauling traffic back to a central data centre, it will sometimes be necessary to place the software functions within the network.

VMs get closer to customers

CloudBand, Alcatel-Lucent’s NFV platform, uses algorithms developed by Bell Labs to do all this in an optimal way and create a distributed carrier cloud.

Quicker service provisioning and turning up capacity when needed is a clear NFV advantage. With dedicated network appliances it can sometimes take months to configure new services, while ramping up and scaling down capacity in real-time to meet fluctuating demand is near impossible. It helps explain why a growing number of operators are trialling the technology and undergoing proofs of concept. Alcatel-Lucent, is involved in more than 30 NFV projects around the globe which demonstrate that the technology is real and ready for commercial deployment.

For operators, now is the time to move beyond proofs of concept and validity testing of NFV and start to plan how to take network functions virtual. The migration to virtualised network functions will be complex and is expected to happen over an extended period of time starting from now but Alcatel-Lucent has the functions, the platform, the skills, the business cases and the experience to make NFV happen for operators.

The driver for operators to change to virtualised networks may be catalysed by obsolescence of older hardware, the need for more capacity or pressure to launch new services such as VoLTE where it may be advantageous to start with virtualised software right away. The growth in mobile 4G deployments and the Internet of Things is creating opportunities for virtualising IP Multimedia Subsystem (IMS) for VoLTE and the Evolved Packet Core (EPC). One EPC task is to authenticate and manage subscribers on the network, but a virtual version would give mobile operators much greater flexibility in dealing with shifting levels of demand. Temporary extra capacity might even be deployed, perhaps for big sporting events and then taken down afterwards.

Better still for operators, once orchestration and management of VMs are automated – reducing the need for human intervention in the likes of service deployment, failure detection and on-time recovery – then operational costs can be lowered. It helps, too, if operations staff don’t have to travel out to remote locations to deliver, install or repair network elements.

Beware of the complexity

Appealing as all this sounds, moving to NFV requires change. To really take advantage of the benefits of NFV such as service agility and operational simplification, the right tools are needed. To create a virtualised network function (VNF) multiple VMs are usually required, each needing to be launched, connected and managed in the right way. And when scaling up, allocating more computing resources from the same server may only go so far in meeting capacity demand. The ability to scale out – by allowing VNF components to run on additional physical servers placed in different locations – is another key NFV requirement. So too is service chaining, which combines different VNFs on the fly to create on-demand services. Adding to the complexity is that the number of cloud nodes in the distributed NFV infrastructure ultimately, may well run into the hundreds or even thousands.

Ensuring necessary workflow processes are in place to stitch VMs and VNFs together across the network – which can be programmed and run automatically – will then require a software-defined networking (SDN) architecture.

Fortunately, virtualisation of network functions, the homogeneity of NFV platforms and SDN enable a completely new level of automation. Unlike with physical network functions, the complete lifecycle of VNFs can be automated from on-boarding during deployment to scaling, healing, software upgrades and all the way to service phase out. Most operators will not start with a fully autonomous approach and will keep some level of human control but automated lifecycle management certainly is possible and has been demonstrated in the labs.

Operators further demand – understandably – that NFV platforms are based on open standards so vendor lock-ins are avoided. VNFs from different suppliers need to be supported, and the platform should not be tied to a particular SDN controller. Likewise, VNFs should be able to run on a broad range of hypervisors and orchestrators.

Proving NFV works is not the end of the story, either. Operators will be able to adjust their operational teams. In the non-virtual world, specific boxes in the network along with a dedicated team, support a particular application. Operators know who to call when something goes wrong in this scenario. In the multi vendor NFV world, there are shared platforms that serve multiple applications and it may not always be clear where the point of failure lies. Operators need help to work out how to resolve such issues as they will become more pressing as NFV scales up.

Virtually there

Alcatel-Lucent started to address the demands of an open NFV ecosystem more than a year before a group of major network operators laid out their requirements and a call for action in a white paper published October 2012. Much progress has been made since. While the industry is still at the stage of trials and proofs of concept, we expect first commercial NFV launches towards the end of 2015 and momentum to pick up in 2016. The expectation is that the roll out of NFV will start with single functions such as VoLTE running on a platform and this will then grow as more functions are added to the expanding NFV platform.

Alcatel-Lucent has shown it’s possible to work in an open and heterogeneous environment from the start. Of the many NFV projects in which Alcatel-Lucent is involved, some run our own applications on CloudBand - Alcatel-Lucent’s NFV platform, but other projects support VNFs from third parties with orchestration by CloudBand. Alcatel-Lucent’s VNF software has successfully run on different NFV platforms as well. While CloudBand can integrate with the programmable SDN solution from Nuage Networks – an Alcatel-Lucent company – it can also work with other SDN frameworks.

But interoperability, though important, will not be enough to convince operators about NFV. They will need to be assured that performance from general-purpose processors is good enough to make the transition worthwhile.

We have shown this is possible when we announced last November that our entire suite of IP edge router software will run on standard Intel x86 servers with half-duplex throughput of 320 gigabits per second – an industry-best performance for routing functions on off-the-shelf silicon. The software for the Virtualized Service Router (VSR), based on Alcatel Lucent’s well-established Service Router Operating System (SROS), still has the same rich feature set associated with our dedicated appliances, but it has been adapted to run with high performance on COTS servers.

We’re able to demonstrate this functionality and help operators that come to us to identify which functions to virtualise as a first step. One live demonstration we exhibited at Mobile World Congress 2015 generated enormous interest because it shows how NFV will work from an operator’s perspective. The demonstration ran live and demonstrated operational scenarios whilst supporting live services.

The feedback was consistent: ‘amazingly simple to operate and taken away a lot of the complexity of NFV deployment.’ We welcome the opportunity to detail our NFV capabilities to operators by creating specific demonstrations to model the potential virtual functions an operator can commercially deploy.

What is abundantly clear is that NFV is here now and it’s real. The first commercial Alcatel-Lucent NFV deployments are well under way. In addition to EPC, operators are keen to virtualise the IMS, Policy and Charging Rules Function (PCRF), LTE radio access network, DNS and DHCP servers and Diameter Signalling Control (DSC). Alcatel-Lucent has completed proofs of concept for each use case – including LTE RAN – with operators worldwide. NFV will continue to build momentum as operator deployments ramp up throughout 2015 and into 2016.

To request your NFV demonstration visit:
Phil Tilley is senior director for NFV and cloud solutions marketing at Alcatel-Lucent