For all of our projects, Linx relies on in-depth, double-blinded interviews with key executives at leading and niche players in the industry including vendors, service providers, customers and systems integrators / channel partners. Every study we complete is based on specific and detailed interview protocols established together with our clients that drive toward producing actionable intelligence.
The initial movers into the NFV space, typical of most emerging technologies, have been incumbent vendors such as Cisco, Juniper, Alcatel-Lucent and HP, and smaller start-ups seeking to capitalize on their advantage of not having legacy businesses. M&A activity has rapidly increased as the technology is progressively inching toward eventual maturity. Established Tier-1 vendors have been acquiring new players after a lengthy road of partnering to strengthen their portfolio. As a result of the initial activity in the market, 2015 has seen a more tangible shift to advanced Proof of Concepts (POCs) and solutions ready for commercial shipment.
The combined factors of cloud computing, NFV and SDN markets are all driven by service providers’ need for service agility, and to reduce costs (CAPEX and OPEX) and improve operational flexibility. Spending in the NFV market is expected to increase at a faster rate than in the SDN market because NFV technology is leveraging established cloud computing hypervisor technologies and maturing more quickly. Currently, as the NFV market is still in a nascent stage, proof-of-concept (PoC) projects and trials are the main revenue source and this will continue in the next 18–24 months, in our view.
NFV in the service layer is expected to drive the highest growth in this market, primarily due to the relative ease of virtualizing SDP and related network functions such as Policy and Charging Rules Function (PCRF), Telecoms Application Servers (TAS), IP Networks (IN), IP Multimedia Subsystems (IMS) (particularly for new VoLTE implementations), content management (head-end systems) and content delivery network (CDN) functions. Another important area for CSP investment is expected to be virtualizing Customer Premise Equipment (vCPE) as the cost savings for CSPs and enterprises from the supply chain management of CPEs is much more tangible than any potential revenue growth that may be realized from virtualizing other network functions (such as security services, etc.).
In the current market state, we see CSPs isolating NFV projects to "contained domains" of their networks to test the waters before widespread deployment. The focus areas for deployment, and hence the areas which are observing most traction from vendor-side innovation and offerings, are within data centers; between data centers; operations and management; CDNs; cloud services, and optical transport networks
One of the key NFV use cases is virtual network function as a service (VNFaaS), which moves the virtualization of the CPE functionality into the carrier network. The virtual enterprise CPE (vE-CPE) solution is one of the most important implementations of VNFaaS and one that many CSPs are evaluating because it enhances the CSP's ability to easily offer managed enterprise virtualized service offerings by replacing dedicated hardware appliances with NFV-compliant virtual appliances that support virtual functions such as routing or firewalls in software. These NFV appliances are managed by carriers from their managed NFV network infrastructure, which can easily provide new functions via software downloads to these virtualized appliances at enterprise sites. VNF services provided by the vE-CPE may include a router providing quality of service (QoS) and other high-end services such as L7 stateful firewall, intrusion detection and prevention, WAN acceleration, application delivery control, and other value-added services.
For CSPs, the driver for a vCPE solution is the promise of a standard hardware appliance, likely an x86-based CPU platform or an open network device. This appliance would be capable of running VMs, supporting general packet processing and basic L2/L3 switching, and also becoming a premise platform that can support a variety of orderable, software based VNFs. Network capabilities include LAN ports, fiber WAN ports, WiFi, and 4G/LTE. Server capabilities, which can be virtualized, include a high-performance CPU, memory, and storage. CSPs intend to ship the network appliance to enterprise sites, power up the appliance, and complete the installation process within minutes compared with days and weeks and without the requirement for processes like truck rolls, for instance. CSPs will then be able to offer software feature sets (i.e., VNFs) for each application (vFirewall, VPN, WAN optimization, IDT, ADC) from a customer self-service portal or set of feature packs that can be automatically downloaded to the appliance once the device is registered and part of the network.
For CSPs, the implementation of a vCPE strategy for delivering broadband and enterprise communication services represents one of the largest business opportunities to reduce CAPEX and OPEX, retain customers, and potentially add revenue.
NFV software development is expected to accelerate during 2015–2018. Established OSS is expected to be re-used using OSS abstraction to perform service orchestration above the software layer of NFV orchestrators and SDN controllers that controls NFV and SDN infrastructure. Also, the number of VNFs will increase gradually because CSPs will not replace network functions that are not end-of-life. These factors would accelerate CSP spending and live deployments due to the availability of an expanded set of solution portfolios from vendors.
In the immediate future of the market, certain drivers are expected to kick-start material revenues trickling in from commercial NFV implementations from CSPs, including but not restricted to:
The need for telco applications themselves to be virtualized. That includes functions such as the wireless Evolved Packet Core (EPC), IP Multimedia Systems (IMS), and many others. While possibilities for virtualization of a broad scope of network functions is being assessed, it is clear that some lend themselves more readily to immediate virtualization than others.
The need for a class of cloud management systems that is tuned to the exacting needs of telco apps and the service provider operational environment. This includes aspects of workload placement and OSS integration that ensures the performance of services in the virtualized environment, and that SLAs are met. NFV cloud management systems will also provide a level of open-ness that allows a broader scope of applications to be readily integrated from the application developer community, extending the range of services that can be made available.
The need for well-defined policies for telco apps in the NFV world, it remains critical for the network connectivity to be instantaneously established in accordance to those policies for those applications and their users.
What does our research show?
There is a lack of a market standard for NFV-O, as vendors are currently tweaking their pricing models and providing a high level of flexibility and negotiable initial offerings.
This is because there is a significant lack of CSP takers for offerings that are largely perceived to be incomplete as per carrier-grade requirements. While vendors with perpetual licensing models are conforming to CSP requirements, they do not have the expected level of CSP demand yet due to the lack of a clear idea of expected scale-up in carrier-grade system size / capacity. Vendors like HP, Oracle, and Alcatel-Lucent are positioning their Orchestrators on the basis of a perpetual license.
The capacity restrictions of growth factors (CPUs / VMs) for current perpetual models pose limitations to CSPs: the current lack of actual VNFs in deployment negate the need for an initial investment of this scale. Hence, vendors are keeping their pricing models flexible and loosely defined, presumably until their offerings have matured for carrier-grade use, and there is a clearer CSP-side intent and readiness to allocate the required spend.
Vendors currently have more capabilities in developing and providing VNFs and the corresponding hardware and software (Orchestration) layer components in the NFV platform to orchestrate these VNFs / other vendors’ VNFs. However, northbound integration capability into legacy OSS/BSS is still lacking.
While most vendor offerings claim to be able to integrate into the existing OSS/BSS of vendors, they lack a clear strategy of how to facilitate the integration: would they simply provide connectivity to the legacy OSS/BSS or would there be a full integration with changes made to the same? Due to this lack of maturity, despite the range of VNFs and ROI potential of the same offered by vendors, CSPs are hence contemplating other avenues such as developing their own in-house orchestration components or using a multi-vendor orchestration system to develop and build on, to bridge these functional gaps themselves.
CSPs have stark differences in their preference for pricing models for the NFV platform (software and hardware) and the NFV Orchestrator.
For the NFVI, CSPs prefer a pay-as-you-go model because they are not in a mature implementation stage yet. They are currently trialing a few VNFs amongst different BUs, and since their capacity requirements are low now and may scale up as their maturity in this area grows; they prefer being able to pay as they scale up instead of investing in a one-time NFVI platform now despite having fewer virtualized appliances. So until a clearer idea of long-term capacity requirements emerges, they would prefer to lease the NFV platform and pay for what they use. For the pay-as-you-go model in question, the number of VMs is the most common growth factor preference, where the throughput of the VM would be the primary measure of the capacity of the NFV deployment to support the selected VNFs. A per-VM pricing model would allow CSPs to pay for only the number of virtual machines that are managed, as opposed to taking licenses for every server deployed. This would be ideal in the initial phases of NFV. With increased maturity, CSPs would consider other growth factors such as a per CPU model. In this case, a perpetual license would be preferred as CSPs would rather make a one-time investment in the hardware platform on a per-CPU basis and have the flexibility of ramping up the capacity of their hardware with future multi-fold increase in the number of sockets per CPU.
Currently, CSPs are primarily operating from initial, pre-project NFV budgets that are in the $0.5 – $1 million range.
A large number of initial CSP budgets today are being used on an as-needed basis for testing, R&D, evaluation of NFV vendors and offerings, and pre-project foundation building for actual, eventual implementations for use cases that would be selected. For a majority of CSPs, the initial budgets of $0.5 – $1 million do not cover actual project expenses such as hardware purchases, software licenses and professional services, especially since CSPs typically do not expect to pay material amounts to vendors for POCs themselves. While exact price points are not known at this stage of market readiness, price-points from our available CSP-side resources suggest that project budgets would see a two/three/fourfold increase over initial POC/trial budgets.
Initial use cases for NFV revolve around the EPC, CDNs and Access Networks, while future areas of focus are load balancing and virtual routing.
For larger CSPs with more active in-house NFV talent, the current focus of NFV is around content provision (CDNs and access networks) and the Evolved Packet Core, while the future focus areas are Layer 3 routing and Layers 4 – 7 applications such as load balancing. The current focus on EPC and content provisioning are aligned with CSPs’ priority to derive a strong CapEx reduction potential with the gradual virtualization of more critical network components, before OpEx reduction from virtualization of Layer 3 – 7 components. In practice, initial adoption of the former will be piecemeal and initially focused on less-critical, smaller-scale use cases. For instance, EPC will tend to be deployed in parallel to the main production EPC. Smaller CSPs with slower adoption cycles are displaying the reverse trend, where CPE and Layer 4 – 7 applications are the low-risk initial NFV use cases.
CSPs have largely prefer a multi-vendor environment, where they expect their NFV vendors to onboard /integrate their VNFs.
Our survey results show that a majority of CSP respondents place a low level of importance on packaged solutions, prefer a best-of-breed approach, and would perform the Systems Integrator role themselves - concurs with interview insights, indicating that CSPs have a strong preference for a multi-vendor NFV strategy. Flexibility from their vendors is required, and solutions that enable vendor lock-in would not be considered. Although this is more typical of Tier 0/1 CSPs, it is also a preferred requirement from Tier 2/3/4 CSPs, where more cautious adoption requires the ability to allocate their network resources flexibly between inter-operable VNFs with open interfaces to a vendor-agnostic MANO and VIM.
How can Linx help?
Invest 30 minutes of your time with us on a complimentary webinar where we can determine together if our unique approach to actionable intelligence can have an impact on your organization. For a no obligation webinar appointment, e-mail us at: email@example.com
Network Function Virtualization
THE Bottom Line
Linx has undertaken multiple strategy research projects in the Network Functions Virtualization (NFV) space. We have specific project experience in NFV platform models, operator virtualization strategies, enterprise NFV-readiness and adoption, NFV architecture, Virtual Network Function (VNF) pricing models, deployment strategies, and enterprise needs.
The focus of our research in the NFV domain has spanned three key parts of this ecosystem: vendors who create NFV solutions and products, operators who use VNFs for their enterprise customers, and enterprises who use operators and/or Systems Integrators (SIs) to manage and deploy their next-generation architectures.