Telecom IQ
Showing results for 
Search instead for 
Did you mean: 

NFV As Viewed By Its Adopters - Part I



NFV As Viewed By Its Adopters - Part I

NFV, or Network Function Virtualization is a recent technology that is deeply affecting the way CSPs manage their networks. To understand what NFV is, and what it offers, it is useful to understand where it comes from.

NFV takes a page from the IT departments of large enterprises, who learned in the last decade that by using virtual computers instead of individual and specialized computer hardware, they could run their companies on much cheaper common-off-the-shelf hardware. The IT sector also found that by running virtual machines, they could be extremely responsive and flexible to real-time computing needs.

CSPs, for their part, have been building networks on very expensive, and narrowly defined dedicated hardware boxes. This "box-based" architecture was rigid, expensive, and forced vendor lock-in – and CSPs are eager for a change. Adding to the pent-up pressure is the fact that CSPs need to adapt and launch new services at a much faster pace in this century, particularly in response to competition from OTT (Over The Top) services. NFV can solve this. Once deployed, it becomes a flexible and agile platform for launching new offerings quickly and with low risk, on virtual machines.

Because the target market of CSPs is eager, and new and existing vendors are also clamoring to provide the next generation solutions, NFV faces little resistance. Every stakeholder agrees NFV will eventually dominate, and the only question is: when? For that reason, NFV adoption is occurring faster than any other telecom innovation at the network's core (an area that doesn't generally welcome change).

Throughout 2015, Hewlett Packard Enterprise has been among the firms developing the open standards that will make NFV a success. At HPE, we've been fortunate to be both participants and leaders at the conferences, plugfests, standards bodies, and meetups around NFV. And we've worked closely with our customers on building solutions. And at each step, we've been measuring the market. We've performed a number of surveys through the year at industry events, and hosted quarterly thought leadership meeting. With this document, we're sharing some of our findings on what the key users of NFV technology have reported to us. NFV is moving fast. Even just looking at one calendar year, 2015, we tracked a notable progression in attitudes around NFV. In this paper, we provide some insights into the question:

How has the thinking around NFV shifted through 2015 among CSPs, vendors, standards bodies, and software developers? And what do they expect of NFV for 2016?


Issues through the quarters:

2015 was an amazing year to track the progress of NFV, because with each passing quarter, the content of NFV discussions progressed so obviously from one of limited familiarity, to one of pragmatic discussions around adoption.


Quarter 1: Defining the relationship between NFV and SDN

In Q1, the various communities were trying to sort out the differences between the two new hot acronyms, NFV and SDN. These complementary technologies often get mentioned together, and the community was working through understanding, defining, and then differentiating the two.

The lessons learned were that, while the two are complementary, NFV is likely to arrive sooner, and SDN will build on the benefits of NFV to transform the fabric of a CSP network into a software-controlled layer.

NFV was defined as using virtualization and cloudification to deliver CSP network functions more efficiently, cost effectively , and without vendor lock-in. NFV would enable:

  • Better scalability. More linear, less jagged resource allocation. Less wasted capacity
  • Off-the-Shelf hardware, reduced CapEx
  • Simpler maintenance, greater manageability, reduced OpEx
  • Faster new service launches / better agility, faster time to revenue
  • Open standards / Diversified vendors ecosystem

NFV, as we've learned, is expected to be able to replace formerly dedicated hardware with virtual   instances of: Firewalls, Routers, Switches, Base Stations, Premise Equipment, Session Border Controllers, and others.

If NFV is the notion of running individual functions in software, SDN is the notion of turning the entire CSP network into a software program. Instead of dedicated routes, fixed hardware roles, and set rules, SDN allows the network of NFV equipment to run like an application. A CSP's network ops staff will eventually be able to alter the network in real-time to suit the current demand loads or operational requirements, SDN will be a key requirement to extract more value from the NFV investment.

The Parts of NFV

In Q1, Stakeholders wanted to better understand the various parts of NFV. A complete NFV solution involves not just a virtual machine replacing a dedicated box. There is more complexity to a full-blown solution, including

  • Off-the-shelf hardware
  • Software running a VNF (Virtualized Network Function)
  • An Orchestration solution that links and syncs different VNFs to create a consumable service

The first two are obvious, but through the course of Proof of Concept projects at various CSPs, the importance of the third bullet has become abundantly clear. An efficient management layer is needed atop the disparate VNFs.

The Benefits and the Risks

As the interest in NFVs grew, people in the telecom space naturally wanted to fully understand the benefits and risks associated with NFV. The benefits have already been discussed, but include scalability, agility, and lower costs. But the more we spoke to, and polled stakeholders, the more we understood that the driving benefit most sought from NFV was agility.

Service agility means the ability to rapidly launch and offer new services to subscribers. Whether that service is a conference bridge service, encrypted communications, more pricing options, self-serve provisioning, or something completely new doesn't matter – CSPs want to be able to quickly create and offer new services to their customers, and more rapidly succeed and fail with those services.

The "agility" factor is existential – the CSPs are under constant competitive attack these days from OTT vendors using the CSP's own networks, but with innovative services, relegating the  CSP to just the pipe. Netflix,, VoIP providers, IPPBX…the list goes on. CSPs need to be able to quickly offer their own competing services in order to respond, stay relevant and even get ahead of OTT competition.

The risks from NFV are few. It is possible – or even likely – that a CSP will have new VNFs that fail both in the market and in service uptake. But those failures can be managed by staged roll-outs in the usual fashion. What is becoming abundantly clear in this era of competition, is that the risk of doing nothing far exceeds the risks of NFV.


Quarter 2: What are the First VNFs?

By the second quarter of 2015, CSPs had essentially acknowledged that NFV was in their future. Now the tone of the conversation had shifted to more tactical questions. Stakeholders and delegates were most interested in knowing what network functions should be among the first to be virtualized.

There is no definitive list of what network functions should be virtualized. Eventually, they will all go. But some of the earlier targets identified in our many discussions are:

  • Virtualized mobile core (Evolved Packet Core)
  • Voicemail and other simple media servers
  • IP Multimedia Subsystem
  • Infrastructure as a Service
  • Customer Premise Equipment
  • Session Border Controllers
  • Content Deliver Networks
  • Security Firewalls

How Many VNFs to Have at Launch?

Another interesting question considered by delegates was how many VNFs did it make sense to start with? Just one to minimize risk? More? The answers turned out to be more about business than technology.

The majority of our survey and meeting participants indicated that they would prefer to launch NFV with at least 5 VNFs, the reasoning being one of fixed costs. In order to launch a single NFV, CSPs would need to commit to the technology, hire or train their engineering staff to be familiar with NFVs, choose vendors or build solutions in-house, and choose some orchestration solution for their VNFs. Put together, that fixed-cost investment makes much better sense when amortized across a handful of useful VNFs. The business preference came down to the old saying: In for a penny, in for a pound.

Impact on OSS?

Our industry partners were also concerned about the impact that NFV would have on Operation Support Systems at the CSPs. And the concern was not unfounded. As NFV transforms networks, it also decouples functions from infrastructure. This increases complexity in the network: before, you knew a customer's voicemail was stored on a dedicated media server nearest their service address…but now, that function may be served from a virtual server running in a datacenter across the nation as part of a temporary load balancing. The OSS needs to augment its level of sophistication significantly in order to orchestrate all the moving pieces.

NFV solutions need to have management and orchestration (MANO) software to manage them. This additional expense has an negative impact on the overall OpEx cost savings we expect from virtualization. They key is that the new complexity caused by software-based machines has to be managed, itself, in software.


Want to read more? Check out Part 2 of our "NFV As Viewed By Adopters" piece for more information on MANO solutions for CSPs (Chapter 3) and ETSI PoCs (Chapter 4).


Learn more at our HPE OpenNFV website, and follow us on Twitter at @HPE_NFV and @HPE_CSP.

0 Kudos
About the Author