Evaluating

The State of the State

of Virtualization

Welcome to The State of the State a special report from Light Reading and
Heavy Reading providing original insights into the changes taking place as
CSPs plan their migration to next-generation communications infrastructure.
We know that the entire communications industry is entering a period of
incredible disruption one driven by virtualization, open-source standards,
white-box deployments and OTT service delivery.
The information in this package provides both qualitative and quantitative
analysis of how these technology change agents are impacting CSPs,
including changes to the way they are planning their network configuration,
the impact to their investment and supplier choices and how service
providers specific procurement criteria is changing in the face of new
service requirements.
As Patrick Donegan, Heavy Readings chief analyst, points out in his report,
New Requirements for Network Equipment Vendors, many of the attributes
of next-gen CSP networks already exist in high-end cloudified enterprise
networks. This is prompting CSPs to look for new attributes in their
equipment suppliers, including both IT and systems integration experience.
Our survey of more than 130 service providers contains some genuinely
fascinating insights into their plans. For example, we now know from the
service provider survey that more than half of all CSPs are still at the stage of
researching virtualization, but 100% of them know they have no choice other
than to make the move to NFV eventually.
The payoff for doing so will be agile, virtualized networks that allow them to
reinvent themselves as services innovators, building and launching profitable
new applications and services at will. And the pressure is on them to make
this move before their last-generation networks and business models are
rendered obsolete by new competitors. At the same time, our report shows
that CSPs clearly recognize the migration must be made in an orderly fashion,
and in a way that doesnt disrupt or destroy existing revenue streams.
Disruptors come in various sizes and forms and some from perhaps
unlikely places. Im hoping these findings start some very interesting
conversations this week.

Steve Saunders
Founder & CEO, Light Reading

New Requirements for Network Equipment Vendors

Communications service providers (CSPs) have wrestled with the problem of flattish revenues and rising costs
for many years. As colossal increases in data traffic, particularly video, have laid siege to the CSP network
infrastructure, waves of technology innovation in optical networks, L2 and L3 IP/ Ethernet technologies, high-speed
broadband, as well as 3G and 4G mobile networks, have repeatedly succeeded in averting looming crises on the cost,
as well as the revenue side of the equation.
But however critical these and other technology innovations have been in the fortunes of CSPs over the last decade,
management in these companies, as well as investors, are keenly aware that, for the most part, what they have
done is enable CSPs to avoid a marked decline in their financial performance. Generally speaking, these innovations
have enabled CSPs to sustain their mainly flat business trajectories. These innovations typically have not served as
a platform for CSPs to accelerate their way out of their current predicament and onto a significantly higher level of
financial performance.
In the meantime, over-the-top (OTT) providers have captured the lions share of new revenue from new content and
applications. Bearing a fraction of the huge capital costs and regulatory obligations that the CSPs are shackled with,
these companies have enjoyed very much better revenue and margin performance.

A New Trajectory for CSPs

Hopes of breaking free from the current flat trajectory are increasingly being pinned on a root and branch
transformation in the way that CSPs use the communications hardware and software that supports their businesses.
CSPs are looking to leverage software-defined networking (SDN) and network functions virtualization (NFV) to provide
a sharp and sustainable uplift to revenues via greater service agility. They also expect SDN and NFV to radically reduce
network costs via commodity hardware and software-driven automation. Some leading CSPs go as far as to describe
this NFV and SDN-led transformation in their business as nothing short of becoming a software company.
Figure 1: Status of NFV Deployments in CSPs Worldwide (December 2014)

17%

Proof -of-concept
(PoC) stage

54%

Early stages of
learning about
NFV (pre-PoC)

19%

In trials

10%

Already
deploying NFV
Source: n=79 service providers. Heavy Reading Survey on Carrier SDN, December 2014

Not interested in NFV

0%

The Opportunity to Build on Trends & Achievements in Enterprise IT

In the past when CSPs have started plotting the course of new network transformations, they have tended to do
so largely amongst themselves, within their own frame of reference and according to their own assumptions and
beliefs largely isolated from the rest of the global ICT community.
This time around, with the transformation to SDN and NFV, there is a huge body of experience and an ecosystem of
equipment vendors for CSPs to draw on in the form of the enterprise IT sector. The transformation that has taken
place in the enterprise data center in the last few years, sometimes referred to as the cloudification of enterprise
IT, has been, and continues to be, based on essentially the same architectural principles and software-driven
building blocks that CSPs are now looking to incorporate into their SDN and NFV strategies.
Virtualization of IT applications on commodity compute and storage hardware has been com-monplace in the IT
industry for years. And SDN, the physical separation of control and forwarding planes, enabling the control plane
to control multiple devices with open programmability at multiple layers, is already widely commercial deployed,
notably by some of the big Internet companies like Google and Facebook.
While theres a whole ecosystem of IT vendors with a breadth experience in building enterprise clouds, and a whole
ecosystem of telecom vendors with a breadth of experience in building telecom networks, the number of vendors
with substantial experience in both these worlds is relatively small. Therefore, some of the best among them
have the potential be key strategic partners as CSPs look to SDN and NFV to provide a bridge between the IT and
communications worlds.

The Beginning of a Journey

This paper sets out to highlight some of the key new requirements that CSPs are formulating for their equipment
vendors as they undergo this transformation. As CSPs seek to understand and navigate how much of the enterprise
IT model they can port directly into their network architecture and operating model, and how much of it requires
adaptation and fine-tuning to their unique requirements, several challenges arise for CSPs.
One of the key things that is quite well, although still imperfectly, understood about this transfor-mation is that it
will have a knock-on transformative effect on the relationship between CSPs and their network equipment vendors.
It will transform what CSPs buy from their vendors, how and on what terms; and it will transform opportunities, risks
and relationships across the entire ecosys-tem of vendors.
The opportunity for vendors is substantial. According to our December 2014 NFV Market Tracker, Heavy Reading
estimates that the market in NFV equipment and software will grow from a base of $485 million in 2014 to $12.7 billion
in 2019. This paper provides Heavy Readings guidelines for what CSPs should be looking for from their equipment
vendors, and thus how vendors can best position themselves for success in this emerging market opportunity.
To give a most basic example, its no longer sufficient for vendors to deliver networking functions as discrete
software modules onto their own hardware platforms. They must be able to demon-strate the ability for their
virtual network functions (VNFs) to run and perform well on the NFV infrastructure (NFVI) of other vendors. And
vice versa, a vendors own NFVI needs also to be able to support the VNFs of other vendors, including independent
software vendors (ISVs).
The communications industry as a whole is only at the beginning of this long-term transformation toward softwarecentric networking. As shown in Figure 1 (above), very few CSPs claim to have NFV up and running on a meaningful
scale today. Other than a small handful of large industry leaders that are at the leading edge, the vast majority of
CSPs are still at an early stage of trialing SDN and NFV technologies.

Nevertheless, the outlook of some of these leaders shows the level of commitment they have to this transformation
and just how driven they are to execute on it as rapidly as possible. As shown in Figure 2 (below), for example,
AT&Ts CTO, John Donovan, told the Mobile World Congress event in Barcelona in March 2015 about AT&Ts plans for
NFV. He stated that AT&T plans to migrate 5 percent of its 150 relevant network functions from a classic hardwarebased architecture to VNFs running on virtualized hardware by the end of 2015. He foresees this rising to no less
than 75 percent of these network functions by 2020. Telefonica has comparable objectives, targeting being able to
run 30 percent of its new deployments on its virtualized UNICA execution environment by 2016.
Figure 2: AT&Ts Plans for Virtualizing 150 Network Functions

150
130
110
90
70
50
30
10
-10

2014

2015

2016

2017

Network Functions Running on Classic Hardware

2018

2019

2020

Network Functions running VNFs

Source: Heavy Reading

In the sections that follow we identify some of the critical capabilities and competencies that vendors will need
to demonstrate if they are to succeed in capturing a share of this emerging opportunity. At first glance, these
requirements have a very familiar, almost motherhood-and-apple-pie, ring to them. But this paper will soon dispel
that impression. What each of the following terms means from a CSP perspective in the modern era, and how the
requirements associated with each one differs fundamentally from what they have meant to CSPs up until now, is
then discussed in detail throughout the remainder of this paper.
Modularity
Openness
Innovation
Availability
Analytics

Network Integration

New Requirements for Software-Driven Modularity

Modularity is a well-established key principle in IT, as well as in networking. Making a function modular reduces the
complexities of large, multi-functional products so that CSPs need only buy the functions they want, adding to these
as and when needed. Upgrading can be done at a modular level, which is potentially faster as regression testing is
easier: There is no need to re-test the entire product, for example. The same also applies in the case of new function
develop-ment.

Evaluating, buying and deploying modular solutions from vendors is one of the core competen-cies of planners,
engineers and operations teams in the CSPs not to mention their procurement teams. Hence, designing products
that fulfil changing requirements around modularity is one of the core competences of the vendors serving them.
As well as hardware-based modularity, CSPs are increasingly looking for software-driven modu-larity because it is
much faster to add functions or capacity as software modules rather than as hardware modules. Software modules
can be instantly and programmatically on-boarded rather than needing a long procurement and (physical) installation
cycle. In itself, however, even software-based modularity doesnt protect a CSP from being locked-in to a specific
vendors product line. After all, its possible to have a modular product and still be locked into a particular vendor.
As discussed further below, software-driven modularity also needs to be supported by openness i.e., the
functionality must be clearly scoped and exposed through an open (i.e., published) application programming
interface (API). This allows the functionality to be integrated with other modules, not necessarily from the same
vendor. Only if these APIs are standard will the modules that are written to them be truly plug and play. And this
will help drive the cost reductions and service agility that the CSPs are targeting.

A New Definition of Openness for a New Era

Requirements for openness are undergoing a profound transformation. The term features prominently in many
of the new multi-vendor organizations and ecosystems that are driving NFV and SDN forward, such as OpenStack,
OpenDaylight and Open Platform for NFV (OPNFV).
Compliance to Industry-Standard Open Network Interfaces
As far as openness is concerned, there was a time, until recently, when all a vendor had to do to win favor with a
CSP was to be at the forefront of promoting and implementing open network interfaces as specified by industry
standards bodies 3GPP-specified SGi, S1 and X2 interfaces in the case of 4G LTE, for example. A vendor that put
a lot of effort into standardization, and was among the first to support those standards in commercial product and
then demonstrate interop-erability with other vendors, could legitimately claim to be at least in line with if not a
leader in supporting open standards consistent with the conventional definition.
That kind of openness at the level of the network interface is still a key requirement in the new era of softwaredriven communications services, but it now represents little more than the most basic table stakes. Its no longer
enough for a vendor to deliver a black box that delivers functionality and provides a standards-compliant pipe out
into the rest of the network and for that approach to be considered open.
There are at least two other proof-points relating to openness that CSPs are increasingly looking for from their
vendor partners, and they are every bit as important as a commitment to open network interfaces. These are a
commitment to open APIs and a commitment to open source software.
Open (APIs)
Providing open APIs is an increasingly core aspect of openness against which CSPs are going to rank their vendor
partners. Its a key enabler of the service agility that CSPs are targeting with the transformation to more softwarecentric networking. Rather than just transmitting and receiving data in compliance with the protocols and procedures
mandated by industry standards, vendors now need to expose large parts of the data that underlies those functions.
This is so that end customers be they the CSP itself, the CSPs customers or a network integrator or managed
services partner can better understand, manipulate and modify the products configuration to meet their
requirements. There is no longer much point in a vendor delivering a software programmable product if it can only
be programmed by the vendors own employees it now needs to be openly programmable by third parties, as well.

While this is undoubtedly the direction that CSPs need their vendors to go in to drive service agility, there are
also aspects of opening up APIs to third parties that are contentious both for vendors and for the CSPs. An
important corollary of investing in open APIs is therefore that the right security logic has to be built into the API
from the outset so as to protect against abuse. Depending on the use case, additional layers of security can also be
considered, such as a monitoring solution on the interface or a means of enforcing specific access rights for specific
third parties.
A Commitment to Open Source Software
Vendors need to demonstrate a commitment to open source software as they position them-selves for CSP business.
OpenStack is perhaps the most obvious example of an open source software community that is featuring at the
heart of the transformation toward a more software-centric network architecture and operating model for CSPs. It
is now the fastest-growing open source project in history, involving thousands of developers keen to create an open
source alternative to commercial programmable infrastructure managers, such as AWS and VMware. With so much
support within the CSP community for leveraging OpenStack for NFV, it is now rapidly becoming the clear favorite of
all possible candidates for the virtualized infrastructure manager (VIM) in the NFV management and orchestration
(MANO) stack.
What CSPs like about open source software is that it transforms their relationship with their vendors, making the
relationship a lot more transparent and further loosening the vendors grip on the CSPs network infrastructure.
Traditionally, telecom equipment vendors have built product using proprietary software. Those same products
may have been deployed across multiple other CSP networks, but many of their individual CSP customers have also
invested in proprietary extensions to that code either to accommodate unique aspects of the network or local
market requirements or for competitive differentiation.
This model has served CSPs well enough for the last 20 years, but its no longer fit for purpose. This is because it
results in the vendor developing a monopoly-like position in the network, rendering it ever more difficult to displace
and ever more difficult to negotiate pricing with, with every additional proprietary extension to the code that is added.
In this traditional model, of course, the vendors software starts out as proprietary and remains proprietary until it
reaches end of life. Throughout that time, the CSP is entirely reliant on that vendor extending its software roadmap in
a direction that complies with the companys strategy. They are also reliant on that vendor pricing those proprietary
extensions reasonably in the absence of any direct competition from other vendors, which just isnt practicable.
The only alternative to this unhealthy dependency is usually the threat of a large scale rip and replace exercise. The
problem with that is that it can sometimes be very expensive and is always very disruptive to the CSPs operations.
The open source model is wholly different in that software extensions developed by vendors get integrated into the
trunk code by the community and become open standard over time. So what Vendor A brings to the open source
code can be freely replicated by Vendor B down the line. This is how open source development ensures openness
with respect to the long-term availability at reasonable cost of software developed by vendors that use it. Because
community edition code can be freely downloaded, its worth noting that open source software isnt truly free
to the CSP. There will always be a cost involved in implementing and maintaining it. Users pay either for in-house
expertise to do this or for a vendor implementation that guarantees a reliable, supported code base.
Because of the transparency of the open source community, CSPs are also assured of unparal-leled, real-time insight
and proof-points of a vendors long term strategic intent as regards their software development roadmap. Open
source software also gives them the opportunity to see and experiment with code early in the process. This allows
them not only to see the quality of the code, but also to anticipate potential integration challenges early on, which
helps drive service agility.

Due to the transparent way in which the contributions of participants into an open source devel-oper community
can be viewed, CSPs can monitor the extent to which specific vendors are truly committing themselves to the open
source model rather than just offering token participation to give the appearance of a commitment.
There is a world of difference between a vendor that merely downloads and scripts in open source software, while
making a few contributions, and another vendor that contributes substan-tially to the common source pool. One
merely demonstrates a willingness to use whats there, whereas the other demonstrates greater willingness to
invest a substantial part of its own code therefore its whole strategic direction to the open source model with the
result that whatever the vendor contributes will be re-usable by others over time.

Vendors Still Innovate in an Open, Modular Environment

Its a misconception that a more open, modular ecosystem necessarily means nothing but the commoditization of
telecom software in which vendors have little or no scope left to differentiate. What actually happens is that the
model for competition between vendors changes.
Open source communities may have the merit of being open, but the highly democratic process of reviewing
contributions and up-streaming contributions into the core code inevitably and necessarily takes a lot of time. In
practice, therefore, what is already being seen in the early stages of NFV roll-out is that vendors using open source
software are already competing fiercely to be first to market with leading edge software. Many of the largest CSPs
are happy to take these products on the basis that they want to get something that is not yet standardized into the
network now rather than wait 12 months or more for the code to be reviewed and accepted as part of the core code.
In other words, and consistent with best practices in the IT industry, vendors still have the cherished and much
needed ability to innovate and differentiate based on proprietary software and to be rewarded for that innovation.
Its just that by embracing the open source model, the window of opportunity for vendors becomes much more
front-ended.
Vendors now derive a competitive advantage for the duration of the time that their code isnt formally accepted into
the communitys code once it is, the differentiator expires. And CSPs can then be comfortable that when they are
buying proprietary extensions of software, they are doing so in the knowledge that while it may be proprietary at
the time of purchase they, and others, can participate in the upstreaming process so that the software subsequently
becomes standardized over time. So, in an open source environment, todays premium-priced, competitive
differentiator becomes tomorrows free software.

Availability: Neither Holy Grail nor Dispensable Baggage

The new requirements surrounding end-to-end network availability and performance in an NFV/ SDN environment
are multifaceted. Solutions do need to be found to harden cloud platform implementations so that they are capable
of stepping up and meeting conventional CSP require-ments for carrier-grade availability and performance, which
have not been factored into enterprise cloud deployments.
Experience in building enterprise cloud platforms certainly has inherent value to CSPs. But vendors also need to
demonstrate development activity in building carrier-grade performance into CSP-ready NFVI platforms and VNF
software. As discussed further on, trusted integrators also need to demonstrate an ability to support CSP servicelevel agreement (SLA) requirements across a decomposed multi-vendor environment that is home to more
potentially many more different vendors across the network than has traditionally been the case.
At the same time, however, a truly agile service creation environment, driven by opening APIs to third parties,
mandates that conventional CSP standards of performance and availability no longer need to be upheld for every

single application or every single service running across the CSPs infrastructure. CSPs need to get comfortable
with making responsible compromises on performance or availability metrics in the case of those applications and
services that dont need them.
Consistent with that, they need to learn how to be able to isolate those applications and services from others
that do require conventional standards of performance and availability. Unless CSPs make that leap from the
well-entrenched telco tradition of universal availability and performance requirements to requirements that are
tailored per service or per application, they will fail to capture all of the opportunities of the shift to softwarecentric networking. The onus is also on vendors to help CSPs differentiate those use cases that do require five-nines
availability from those that dont; for example, where a VNF has been architected in a highly available way or where
a lag in performance wont affect customer experience significantly, such as in the case of a free voice service.
As depicted in Figure 3, in the coming years, CSP networks will become less reliant on platform hardware and more
reliant on both platform software and network application software to meet their requirements for network or
service availability. The traditional approach with network equipment used in the CSP infrastructure has been to rely
on availability being guaranteed in terms of approaches such as 1+1 hot standby of the chassis; 1+N failover so that
a pool of hardware platforms picks up the load from any platform that fails; and card-based resiliency so that if a
card fails another card picks up its traffic instantly.
Figure 3: The Road From Hardware-Defined to Software-Defined Availability

Classic/Legacy

One vendor delivers

all & provides SLA

Proprietary network
application SW
(All Vendor A)

NFV State Of The Art

SLAs provided by - and for ecosystem partners

Vendor As VNFs
Ecosystem partner
of Vendor C

Vendor Bs VNFs
Ecosystem partner
of Vendor C

SL A provided by Vendor
A or a n int eg ra t or

S L A p rov i d ed by an d
fo r - ecosy st em par t n er s

Proprietary hardware
platform
(Vendor A)

Open NFVI platform

(Vendor C)
Ecosystem partner of Vendor A & Vendor B

Reliability is HW driven

Reliability is HW driven & SW driven

NFV Future Target

Architecture

SLAs supported for all VNFs

Any Vendors VNFs

S L As are s u p po r t ed
fo r al l V N Fs

Open NFVI platform

(Vendor X)
Reliability is SW driven

Source: Heavy Reading

As shown in Figure 3, the conventional model in the CSP environment assumes a hardware-driven SLA guaranteed
either by the vendor, by the vendor acting as a broader network integrator or by an independent integrator. Theres
no question that standard servers have nowhere near the internal redundancy and failover capabilities built into
them that purpose-built telecom equipment have. So to capture the cost saving and revenue generating potential of
SDN and NFV, CSPs have to embrace new ways of achieving traditional objectives, albeit in a way that allows more
granular variability in the unique performance attributes required to support different applications and services.

10

What that requires of vendors is to design network platforms and applications that evolve so that they no longer
rely on the hardware providing the reliability but instead are designed to assume the probability of hardware
failures and perform failover in software instead. Hence when a server fails, the cloud management software is
intelligent enough to determine that the network function that was running on it just gets moved onto another
platform elsewhere in the cloud quickly enough to maintain network or service availability targets. Consistent
with this, section 4.2, Network Function Virtualisation Resiliency Objectives, of the ETSI Group Specification NFV
Release 001 V1.1.1 published in January 2015, states: The key objective is to ensure service continuity, rather than
focusing on platform availability.
Software-Based Failover Isnt New
Software-based failover isnt new and is widely used in the IT environment. The unique challenge in the CSP
environment, however, is that most CSP applications are stateful so if there is a failure in failover, connections
are lost together with other state information, such as whether the user is logged in and where they are. There
is certainly still a lot of work to be done here, but there is little doubt that this is the direction CSP networks are
wanting to head in where assuring availabil-ity is concerned. Hence there is also little doubt also that vendors that
demonstrate strong commitment to delivering failover in software either through their own development activity
or by bringing in high availability software modules from third parties will find favor with CSPs.
Uncertainty does remain with respect to the optimal balance between extending the capability of network
application software to support failover on the one hand and extending the capability of network platform software
on the other. Work in both areas is clearly required, but the jury is out as to exactly where that balance will fall.
There is also uncertainty with respect to how quickly, and in what stages, different CSPs are going to be able to
migrate their approach to availability from a highly hardware-centric to a highly software-centric model.
The procurement teams in the CSPs are used to performing quality assurance on network equipment according to
their own conventional model. They must undergo a profound overhaul in the way that they evaluate and approve
vendor solutions from an availability or reliability stand-point in order to become comfortable with a highly
software-centric model.
Figure 3 points to an intermediary phase in the evolution of the NFV roadmap, whereby unique ecosystem partners
join forces to guarantee performance of one anothers products, such as one vendors VNF operating well on another
vendors NFVI. This is largely in accordance with much the same principles as conventional integrator models in the
CSP space, albeit in a far more modular, multi-vendor environment.
We define this phase as state of the art because we see evidence of this approach taking hold in the market today.
We view it as a very important interim phase of the markets development, pending a future, fully mature state of
the market, when carrier-grade requirements, including availability, have been fully developed across the vendor
ecosystem and any and all applications can deliver good performance on any infrastructure.

Advanced Analytics for Performance & Monetization

Advanced analytics both network analytics and customer analytics will play an increasingly important role in
networking equipment in conjunction with the roll out of SDN and NFV. A significant part of the value proposition of
a more software-centric network is that it enables CSPs to respond much more rapidly to both network conditions
and customer demands. As CSPs increasingly understand, the insight provided by advanced analytics is critical in
enabling deci-sions to be taken and action taken. Network analytics provide CSPs with a view of how the network is
performing and, hence, what decisions to take in software with respect to optimal routing, for example.

11

Customer analytics are equally important. They enable better understanding of what applications and services
customers are using as a means of automating the generation of customer profiles as a platform for offering them
new capabilities that are customized to their unique behaviors and requirements. Vendors that demonstrate an
ability to appropriately compose the right kind of advanced analytics either in house or from third parties into
their products will also be well positioned for emerging CSP requirements.

Integration of a Multi-Vendor Network in the New Era

One of the biggest challenges in a multi-vendor network based on SDN and NFV is integrating multiple vendors. As
already alluded to, this isnt a new requirement for CSPs. But in addition to being a lot more rewarding in terms of
revenue generation and cost reduction, the network integration requirements in the SDN and NFV era also become a
lot more complex, and thus challenging.
This is because of the greater variety of different vendors, the separation of hardware and software functions
and the transformation required in the CSPs organization and business processes to take full advantage of
the new operating model. Further, each CSP will also have its own unique requirements not just with the new
infrastructure, but also with respect to integra-tion with their legacy infrastructure.
Ultimately, the responsibility for fulfilling all of the requirements and opportunities outlined above modularity,
openness, innovation and availability all rests with the integrator. The integrators ability to pull all these
elements and requirements together in a way that aligns optimally with the CSPs business objectives will be critical
in determining the success or failure of this transfor-mation.
Figure 4: The Network Integration Preferences of CSPs With NFV

43%

Integrate a mix of vendor solutions

using a specialist integrator
Integrate a mix of
vendor solutions ourselves

34%
19%

Integrate a mix of vendor and

in-house solutions ourselves
Integrate a single-vendor
solutions ourselves

2%

Use a turnkey single-vendor solutions

integrated by that vendor

2%

Source: Heavy Reading survey of 57 mobile operators on virtual EPC, October 2014

As shown in Figure 4 (above), there is strong Heavy Reading survey evidence that CSPs are also very interested in
having an independent, specialist integrator bring together the mix of hardware and software components in the
emerging software-oriented network. In Heavy Readings October 2014 survey on virtual EPC, 43 percent of CSP
respondents stated that they will likely prefer a mix of vendor solutions using a specialist integrator to bring them
all together, while 53 percent had in mind carrying out the integration role themselves. Tellingly, only 4 percent of
respondents have in mind a single-vendor solution.

12

Heavy Reading believes that the role of network integrator will be highly sought after in the vendor community. We
expect many of the Leading Lights in telecom and IT worlds to prioritize the network integrator as a key strategic
platform for their own future growth in the networking hardware and software businesses. There arent many
vendors that can demonstrate core competencies in building cloudified enterprise IT network, as well as capabilities
in the telecom networking space. Those that can will be well positioned for this type of integrator business.

Summary
Heavy Reading believes that the criteria against which vendor selections are made in the CSP environment are
undergoing a significant transformation. While many of the same terms will continue to be used, what these terms
actually mean and the requirements for how vendors will deliver on them is becoming markedly different.
Vendors that support modularity, openness, innovation and availability according to the increas-ingly softwaredefined requirements of CSPs as already driven in the IT market will succeed. Those that dont, or those that are
behind the curve, will lose out. Analytics will play an increas-ingly important role, too. And we believe that the role
of network integrator will be highly sought after among vendors because of the strategic relationship it will bring
with CSP customers in navigating both the challenges and the opportunities in front of them.

About HP
HPs objective is to help CSPs thrive in this disruptive environment by accelerating their journey to NFV. Its OpenNFV
Program which includes an open standardsbased NFV reference archi-tecture, HP OpenNFV Labs, and the HP
OpenNFV partner ecosystem, helps CSPs speed interoperability and time-to-market of new services.
One of the key tenets of the OpenNFV architecture is that its based on open standards and leverages open source
technology projects such as OpenStack and OpenDaylight (ODL). This approach gives other ecosystem players the
ability to bring in new innovations. We do not believe that NFV is an environment where one vendor will do it all.
For more information follow @hpnfv and visit www.hp.com/go/nfv.

13

Light Reading CSP Technology Investment Survey

Methodology: In May 2015, Light Reading undertook an online survey of CSPs as part of a package of research into
how the need to deploy next-generation communications technology is impacting service provider investment
strategies. We received 139 valid responses from service providers around the world.
Light Readings recent survey of CSP investment strategies reveals many telling insights into the state of flux that
the communications industry currently finds itself in.
The survey data makes it clear that the need to upgrade networks to support agile, open, virtualized services is
already forcing the majority of CSPs to make sweeping changes to their procurement processes. Over 90% of survey
respondents said that their approach to procurement has changed over the last three years; 46% report that it has
changed a lot (see figure 1).
Not surprisingly, the purchasing criteria that have increased most dramatically in importance relate to software
agility; specifically, virtualization and support for open source code. Seventy percent of survey respondents said
that software has increased in importance for their organization over the last three years (see table 2).
The two other purchasing criteria that have increased most in importance over the last three years are
interoperability and integration a clear sign that CSPs are looking to move away from the single vendor lock-in
model that has prevailed in telecom for the last 30 years, where CSPs pay one or two dominant manufacturers to
design and install their products end-to-end (including proprietary features that locked the service provider into
those vendors manufacturers solution in the long term).
Open standards-based white box networks leveraging open software free up CSPs from having to engage in this model
by allowing them to mix and match products from different vendors; 62% of CSPs expect to spend more on open source
software and 37% expect to increase spending on white box hardware over the next three years (see table 7).
The advent of open, virtualized, white box networks will increase the need for CSPs to pay for systems integration
services to manage and maintain their networks (services they get today from their single vendor suppliers). This
fact is also reflected in the survey results, with almost 40% of respondents reporting that they will increase their
spending on SI over the next three years (see table 8). Almost three quarters of CSPs say they will buy these services
from existing hardware vendors rather than new or independent SI organizations (see table 9).
The increasing importance of IT skills in building telecom networks is also clear in several places within the survey.
Thirty-five percent of CSPs expect to add more IT experts than network/telecom experts over the next three years
(table 10). Almost half say that their CIO is now more involved in technology procurement than they were three
years ago (table 3).
Its not surprising to see a newfound recognition of the value of IT in the survey, since many CSPs have now realized
that many of the challenges that they face in creating large-scale virtual cloud services have already been overcome
in the cloud networks that exist in large enterprise IT networks.
Overall, the Light Reading CSP Technology Investment Survey shows that CSPs plan to invest heavily in nextgen communications infrastructure over the next few years. Sixty percent expect to be spending more, vs. 10%
who hope to spend less (table 4). By far the largest increase will take place in software spending; almost 70% of
respondents see their software spending increasing (table 6).

14

1. How much have your companys technology procurement processes changed over the
past three years?

9%

Value

Percent

Count

A lot

46.4%

64

A little

44.2%

61

Not at all

9.4%

13

Total

46%

138

44%

2. How has the importance of these criteria changed in your companys technology
procurement decision-making over the past three years?
Has become more
important

Has become less

important

No change in importance Responses

Hardware performance
(capacity, data rates)

84

62.7 %

23

17.2 %

27

20.1 %

134

Reliability
(MBTF, SLAs)

83

62.4 %

18

13.5 %

32

24.1 %

133

Software agility
(virtualization, opensource support)

91

70.0 %

17

13.1 %

22

16.9 %

130

Delivery and
integration timeframe

89

68.5 %

17

13.1 %

24

18.5 %

130

Energy consumption

79

59.8 %

22

16.7 %

31

23.5 %

132

Physical size of
deployed hardware

60

46.2 %

26

20.0 %

44

33.8 %

130

64.3 %

16

12.4 %

30

23.3 %

129

Interoperability with
technology from other
suppliers

83

15

3. How has the level of involvement of the following C-level executives changed in your
companys technology procurement process over the past three years?
Has become more
involved

Has become less

involved

No change in
involvement

Responses

CEO

31

23.3 %

25

18.8 %

77

57.9 %

133

CFO

43

31.9 %

23

17.0 %

69

51.1 %

135

CIO

61

45.5 %

17

12.7 %

56

41.8 %

134

CMO

36

27.1 %

26

19.5 %

71

53.4 %

133

CTO

73

53.7 %

17

12.5 %

46

33.8 %

136

4. Overall, how do you expect your companys technology spending to change over the next
three years?
Value

Percent

Count

Our spending will increase by 5% or

32.1%
more each year

44

Our spending will increase by less

than 5% each year

27.0%

37

Our spending will remain relatively

flat

31.4%

43

Our spending will decrease by less

than 5% each year

5.1%

Our spending will decrease by 5%

or more each year

4.4%

Total

5%

4%

32%

31%

137

27%

5. How do you expect your companys spending on hardware to change over the next
three years?
Value

Percent

Count

Spending on hardware will

increase

34.3%

47

Spending on hardware will

decrease

38.7%

53

Spending on hardware will remain

roughly the same

27.0%

37

Total

27%

34%

137

39%
16

6. How do you expect your companys spending on software to change over the next
three years?
Value

Percent

Spending on software will increase 67.2%

92

Spending on software will

decrease

11.0%

15

Spending on software will remain

roughly the same

21.9%

30

Total

22%

Count

11%

67%

137

7. How will your companys spending on the following change over the next three years?
Spending will
increase

Spending will
decrease

Spending will remain

the same

Responses

Proprietary hardware

41

31.1 %

57

43.2 %

34

25.8 %

132

White-box hardware

50

37.3 %

35

26.1 %

49

36.6 %

134

Proprietary software

39

29.1 %

53

39.6 %

42

31.3 %

134

Open-source software

84

62.2 %

19

14.1 %

32

23.7 %

135

SDN

84

63.6 %

17

12.9 %

31

23.5 %

132

Virtualization
(VNFs, NFV)

99

76.2 %

6.2 %

23

17.7 %

130

Security

102

76.7 %

6.8 %

22

16.5 %

133

Analytics

84

64.6 %

15

11.5 %

31

23.8 %

130

17

8. How will your companys use of systems integrators change over the next three years?
Value

Percent

Count

We will use systems integrators

for more projects

37.2%

51

We will use systems integrators

for fewer projects

19.7%

27

Our use of systems integrators

wont change much

34.3%

47

We havent used systems

integrators in the past, and we
dont plan to use them in the
future

8.8%

12

Total

9%

37%
34%

20%

137

9. How does your company source its systems integration partners?

Value

Percent

Count

We work mainly with SI teams

from our technology suppliers

71.3%

97

We work mainly with SI

organizations outside of our
technology suppliers

28.7%

39

Total

29%

71%

136

10. How do you expect your companys internal technology expertise to change over the
next three years?
Value

Percent

Count

We will add more network

experts than IT experts

24.1%

33

We will add more IT experts than

35.0%
network experts

48

Our mix of network and IT

experts will remain about where
it is now

56

Total

18

40.9%

137

24%

41%

35%

11. What type of communications service provider do you work for?

Value

Percent

Count

Wireline network operator

14.4%

20

Mobile network operator

25.9%

36

Converged network operator

(wireline and mobile)

40.3%

56

Cable network operator

11.5%

16

OTT service provider

2.2%

I don't work for a CSP

0.0%

Other (please specify)

5.8%

Total

14%

26%

6%
2%
12%

40%

137

11. In what region is your company headquartered?

Value

Percent

Count

U.S.

70.5%

98

Canada

6.5%

Central/South America
(including Mexico & the
Caribbean)

5.0%

Western Europe

10.1%

14

Central/Eastern Europe

0.0%

Middle East

1.4%

Africa

0.0%

Asia/Pacific
(including Australia)

6.5%

Total

10%

6%

5%
6%

71%

139

19