News, views and contacts from the global telecommunications industry

The virtual reality: Current Analysis's NFC Catalog report

10 December 2015

Peter Jarich from Current Analysis outlines the key points from the company’s ‘NFV Catalog: System Vendors Offerings Circa Late 2015’ report on the state of play in terms of vendors’ network functions virtualisation developments and commercial offerings.

Despite the name, it's well understood that network functions virtualisation (NFV) is about more than just virtualised network functions (VNFs). In order to deploy, integrate, manage and monetise NFV effectively, a whole host of solutions are required, from NFV infrastructure platforms and SDN products to OSS/BSS assets, and management and orchestration (MANO) tools. Current Analysis (CA) has outlined these components on numerous occasions in 2015 in 'Market Assessment: NFV MANO', 'Assessing Strategies for Solving NFV MANO Complexity', 'Using an IMS Simplification Benchmark' and 'NFV Platforms: The Mid-Year Update - NFV PoCs and Trials Move to Production'.

A focus on NFV solutions - versus individual NFV components - fits with today's market requirements and operator demands. Beyond CA's own survey work pointing to the importance of end-to-end NFV solutions, consider the 'OpenDaylight' (ODL) user base survey from earlier this year. The fact that NFV was called out as the number-one ODL use case points to the intimate connection between SDN and NFV. Likewise, where 'increased interoperability' was cited as the top ODL business driver, the importance of solutions - multivendor ones, ideally - is called out, at least among those engaged with ODL-based SDN.

Of course, without VNFs, the concept of an NFV solution would be meaningless. Whether bundled with a larger NFV solution or sold individually on a best-of-breed basis, their importance as a part of any vendor's NFV solution and strategy is undeniable. Against this backdrop, a vendor's VNF catalogue is a critical part of NFV messaging and solution capabilities.

"A focus on NFV solutions - versus individual NFV components - fits with today's market requirements and operator demands."

The key takeaway points are that: NFV solutions include many components (MANO, NFV platforms, OSS/BSS assets), with individual VNFs being one of the most important; in Q4 of 2015, commercial availability of most key VNFs was much improved over late 2014; and, as the VNF portfolios across vendors begin to normalise, competitive dynamics will need to focus on solutions - as well as go-to market strategies and messaging.


The current view

A vendor's VNF catalogue is an important part of its NFV-solution messaging, sales efforts and competitive positioning. The VNFs a vendor has ready for sale or trial, along with those that are under development or have been commercially deployed, shed insight into the breadth and depth of a vendor's offering. They also point to a vendor's R&D priorities. As part of efforts to evaluate vendor NFV portfolios, then, CA reached out to leading network system vendors and more narrowly focused telecoms specialists for the availability details around key VNFs in Q3 2015. VNFs were categorised into four groups - commercially available, available for trial, under development and not developing - with effective dates asked for where available. In this first report, the leading network system vendors were analysed.

Building off the responses, insights can be divided along two lines: vendor insights and industry ones.


Vendor insights

When the report was first compiled at the end of 2014, there was considerable variation across the different vendor portfolios - enough to draw some clear conclusions. Today, there is much less diversity in commercial VNF availability across vendors. Regardless, there are still insights to be gleaned from the diverse offerings.

Alcatel-Lucent's understandable focus on virtualised routing functions has largely been matched by key competitors, but it's important to realise that there is a broad array of functions that can fit into this category. For example, on the routing front, Alcatel-Lucent has virtualised its SR OS (VSR), and offers commercial versions of its virtual route reflector and simulator, but it's still in the trial phase with virtual versions of its PE, BNG, NAT, AA and SEGW.

"Across the board, EPC, VoLTE and policy-enforcement functions are all supported commercially."

Regardless, its virtual RAN (vRAN) trial work still differentiates it somewhat, if only because it can point to public demonstrations as well as a solution that goes beyond the BBU to include RNC functions. With a history in the field, and a strategy to target extra-large enterprises, it is surprising that the company hasn't made progress on virtualising functions like firewalls or NAT.

Cisco, meanwhile, has made virtualisation and NFV a cornerstone of its service-provider marketing, and it shows in the company's portfolio, which is one of the broadest claimed, including many functions not considered in CA's survey, such as analytics, DDoS, load balancing and application policy. While it's surprising that any vendor with a commercial vIMS solution wouldn't have vMRF plans, the fact that Cisco continues to leave Altiostar out of its VNF story highlights that it's not necessarily including partnered VNFs. All of this, however, might be overlooked, given its NFV sales and marketing strategy.

Cisco might, from time to time, quote the number of commercial VNFs it offers, but it leads with a service story, selling services that are powered by VNFs - cloud security or mobile video, for example. The result should be a greater ability to sell to multiple levels of an operator's organisation.

As a leading mobile broadband infrastructure vendor, the virtual functions most important to Ericsson's core customer base should include VoLTE and the EPC. It only makes sense, then, that Ericsson would claim to have some of these functions commercialised from the end of last year. Likewise, where Ericsson has made its push on the IT market clear, it's good to see the vendor claim commercial firewall, NAT, SBC and routing assets - though, as noted, it's not always clear what vendors mean on that front.

However, Ericsson has also made the media space a strategic priority, but why it still has a vCDN offer in the trial phase then is confusing. Perhaps more confusing is the limited progress on a vCPE solution. The fact that this has been in trial since Q4 2014 suggests either a lingering supply (product) or demand (customer interest) problem; as one of the most talked about VNFs, lack of demand seems unlikely.

After collecting the VNF portfolio data at the end of last year, CA noted, "the most striking thing about Huawei's VNF catalog is the lack of commercially available functions as we close out 2014". Fast forward to today and it's a very different story;

Huawei reports one of the most complete VNF portfolios of any major infrastructure vendor. It matches each commercial claim with a customer deployment when pressed for verification. While important for fighting back against expectations of exaggerated momentum, this also fits with the survey results, which perennially point to Huawei as a perceived SDN and NFV leader.

"The speed with which operators have moved forward on VNF trials and deployments is encouraging, especially when compared with prior technology introductions and network evolutions."

Nokia has made considerable progress on the NFV front since the end of last year. Most importantly for the mobile broadband specialist, EPC and WLAN gateway VNFs have been taken commercial, and it's moved into vPCRF trials, a product it reported no plans for earlier and is partnering with Redknee for.

While still coming up short in the vCPE and routing spaces, this should be remedied next year when its acquisition of Alcatel-Lucent takes place. Unfortunately, that will not remedy a lack of enterprise-focused VNFs. Should the vendor look to push apps closer to the enterprise or network edge, however, its work with Liquid Apps, which drove its support for mobile-edge computing, could be an asset.

If many major system vendors saw significant progress with VNF commercialisation since last year, ZTE stands out as an exception. It's true that some key VNFs - PCRF, RAN and WLAN Gateway - have moved from developing to trialling.

Many, however, remain in the development state, including some of the most in-demand (such as vCPE and CDN) and VNFs that should play into ZTE's enterprise business, like Firewall and NAT. The good news is that commercialisation of foundational VNFs touching the mobile packet core, IMS and VoLTE, should put ZTE in a solid position to meet the demands of many operators in the near term.


Industry insights

Individual VNF portfolios can tell us a lot about competitive positioning and vendor priorities. Looking across the various portfolios, however, provides broader market insights into how the NFV space is evolving and what's likely to come.

When CA first started collecting this data, there was no single VNF sitting at the same level of development - no function that was commercial for everyone or just in the development stage across vendors. It is a very different story this time around: across the board, EPC, VoLTE and policy-enforcement functions are all supported commercially.

Likewise, a majority of the vendors looked at had commercially virtualised PCRF, IMS, MRF, routing, SBC and WLAN gateway offerings. The enterprise remains somewhat of a mixed story, but Ericsson, Cisco and Huawei are all prioritising it.

With VNFs touching many diverse and distinct parts of the carrier network, it's clear that thinking about NFV as a single market, or a single solution, isn't necessarily easy or logical. Yet, if vendors want to sell end-to-end NFV solutions and operators want to buy end-to-end NFV solutions, then marketing needs to be holistic in representing all of these diverse network areas and messaging them as a whole. From Cisco's marketing of 'services' built upon VNFs to the general improvement in getting vendors to respond with meaningful feedback, it's clear that the market is moving in this direction.

When CA data first started being collected, many vendors had plans for taking lots of VNFs commercial in the 2015 time frame. As a result, it said, "To the extent that vendor VNF marketing efforts have relied on availability claims, the strategy will obviously need to evolve over the next 12 months."

With many more VNFs commercially available in Q4 2015, the need for NFV messaging evolutions is more acute than ever. From one perspective, we see this evolution in Cisco's efforts to sell service-based use cases built on various VNFs. Other evolutions should include differentiation based on performance, management, end- to-end solutions and virtualised versus truly 'cloudified' VNFs.

As vendors rack up more commercial VNF references, we approach a point in which it may no longer make sense to refer to the virtualisation of network functions. After all, the concept of NFV implies that virtualised functions are not the default mode of deployment.

While physical and virtual functions will likely live side by side for years to come, selling them as distinct offerings may not make sense in the long term. Put another way, once most vendors offer a full portfolio of VNFs, with commercial references, will we still be talking about 'virtual' functions or just 'functions'?


What should the vendor do?

While it's likely that many vendors are already selling VNFs in terms of broader services, more need to make this an explicit part of their messaging. Cisco's strategy on this front may not be the only reason the vendor fares well in the survey of operator sentiment but, as operators move forwards on deeper NFV commercialisation, understanding how VNFs play into revenue-generating or saving services can't hurt. Yes, vendors must be ready to call out specific VNFs for people who will buy in this way; however, they must also be ready to sell services and solutions wrapped around VNFs.

The speed with which operators have moved forward on VNF trials and deployments is encouraging, especially when compared with prior technology introductions and network evolutions. Yet, to the extent that this evolution is still in its infancy, vendors need to engage in constant, aggressive market education. From the importance of complete solutions, to the role of professional services and everything in between, there's an opportunity for vendors to shape service-provider thinking. However, the window to do so is quickly closing as operators gain more experience with virtualisation.

The number of operator trials and commercial VNF deployments cited by vendors underscores the notion that the market is moving quickly, especially when compared with the previous iteration of CA's data. Yet, it's often held that the market isn't moving fast enough, justifying a wait-and-see approach from some service providers. To that end, vendors need to work to make their references, and commercial deployments, as visible as possible. Where it's not possible to announce specific customers, reminders of broader momentum are a solid option.

Vendors need to sell the concept of the vRAN holistically. The fact that vRAN isn't yet commercial from any vendor, and many aren't event pursuing it, contributes to the notion that it's somehow a different category of VNF. However, scaling and managing vRAN deployments will require the same sort of solutions needed for other VNFs, especially if vRAN is sold alongside vEPC or vRNC implementations, and if the servers running RAN at the network edge (or core) also run other VNFs. While there are very real technical reasons for vRAN to be looked at differently from other VNFs, vendors will be missing out if they treat it as a completely different beast.

With 2016 fast approaching, no vendor should claim "no plans" for any VNF. Meeting operator demands will require a broad set of virtualised functions and, while it's not possible to develop every single VNF in house, a core promise of NFV is to integrate partnered solutions. A broad set of partners and VNFs needs to be a part of every vendor's VNF catalogue offering.

As noted earlier, many people see NFV as a primary SDN use case. At the same time, however, SDN controllers are sometimes positioned as VNFs. While vendors such as Cisco have taken the strategy of calling them out as such, others need to consider following their lead. If nothing else, it points to the linkages between SDN and NFV from a sales and R&D perspective.


And the user...?

There is no need for operators to go slow with their NFV evaluations. While still maturing, NFV solutions are ready to be deployed, and operators around the world are doing just that; CA's latest survey of operators suggests that some of the top NFV use cases - EPC, Gi-LAN, CDN and IP routing - are in the process of commercialisation by at least two thirds of all operators. With plenty of examples to learn from, there is no excuse for any operator to extend their NFV investigations.

Operators deploying NFV solutions need to understand that VNF availability is not a proxy for feature completeness, solution completeness or performance. VNF development may allow a vendor to include specific functions in its sales and marketing efforts, but it does not ensure that the products perform as needed. To this end, specific customer references are important in vetting any vendor's solution.

It is well understood that service-provider culture remains one of the biggest obstacles to broader NFV deployment. Part of this culture has involved building networks in silos - with specific functions being deployed and managed individually by distinct business units.

Buying VNFs in silos, however, ignores the importance of larger orchestration and management synergies, as well as platform infrastructure synergies, which is one of the key benefits of NFV. Rather than buying VNFs, NFV should be approached as a solution, with solution-providing vendors responsible for sourcing specific VNFs, whether they be their own or from third parties.

NFV has been accompanied by an evolution in thinking about network architectures, with potential impact for the siting of VNF deployments. Whether framed within the concept of distributed NFV or mobile-edge computing, the broader distribution of functions that NFV enables should have implications for function performance and management. Beyond initial NVF investigations and deployments, operators need to engage with their VNF vendors to ensure that these vendors are ready to support siting and VNF placement diversity.