I blogged a year ago that optimum implementation of NFV could create between 80,000 and 130,000 new data centers, making NFV potentially the largest source of new server and data center component installations. There is little doubt that NFV could touch every aspect of virtually every service, so there’s lots of reasons for operators to plan for it. The big issue in that planning, according to my own research, is just how to get from lab to field. Testing NFV technology doesn’t exercise the business case.
So how can operators make the transition? It’s not an easy question when you consider it in the general sense, because the answer depends on just how opportunity and infrastructure combine to create motivations and inhibitions. One thing is clear, though; NFV has to develop proof points quickly or time will pass it by. That means that what’s important about NFV may be more where to start than where it might take you in the long term. I call this the “first-NFV” position.
There are three motives for NFV; capital equipment savings, operations efficiencies, and service agility enhancements. There are two primary areas of consideration for carriers too. One is the opportunities presented in their geography and the second is the nature of their current infrastructure. Over time, I think it’s likely that all three will be used by operators, but if we stay with our first-NFV theme, we can see how some operators’ mixture of infrastructure and opportunity could make one of these a better starting point.
Let’s start with the two areas of consideration, and the primary one of opportunity. Opportunities depend on both the customer base and the prospect pool. Carriers operating in a mature geography whose prospects are themselves mature in their network and IT plans have a limited ability to exploit new revenue streams. They’d want to focus on making what they can already do more profitable, meaning lowering both capex and opex. Carriers who have significant upside in their primary geographies may want to focus first on new services, to avoid the risk that competitors would step in and sweep all the easy prospects off the table.
Most operators have only a limited notion of the opportunities presented in their own geographies. When I’m asked to evaluate NFV business cases, the first thing I usually ask for is an opportunity analysis, and usually they have to develop one. Without such an analysis it’s impossible to size NFV new-service benefits.
If opportunity presents the whip of change, then the anchor is current infrastructure. Where infrastructure assets are fairly well depreciated, the carrier has the option of making changes quickly without facing major write-downs. That opens the door to lower-cost solutions even for current problems, so capex reduction is an option. It also lets operators optimize operations efficiencies by changing technologies as needed, and it insures that new service opportunities can be properly supported as soon as they’re credible. Where assets have a long residual depreciation period, any changes demanded by NFV may be difficult to justify because the prospective savings will be eroded by the write-down of current gear.
Into this mix we now introduce the three benefit drivers for NFV. In most cases, a carrier’s current NFV project focus should be finding something that can prove out one or more of these three benefit drivers to the extent needed to get a project into field trials and onward into deployment. That means addressing what NFV can do functionally while considering how doing it will impact costs (both long-term and first-cost) and operations practices.
Capital equipment savings through NFV will likely depend largely on the efficiencies of resource hosting. Those efficiencies are easiest to demonstrate if you can justify a large resource pool, meaning that you’d like not to have to distribute stuff too far afield. There seem to be two factors that promote a first-NFV strategy based on capex savings; cloud computing commitment and carrier Ethernet opportunity.
If you have a cloud data center you already have a resource pool to play with, and that will make even your early NFV deployments more capital-efficient. Operators who have several cloud data centers in major metro areas are in even better shape because this will reduce the distances that intra-component connections have to travel. Ideally your NFV deployments would start where you had cloud resource pools available, and that reduces first cost and risk as well.
The carrier Ethernet dimension relates to the use of service chaining to create virtual CPE to offer advanced services, including security and facility monitoring. The best place to start these services are with the high-value customers, meaning those with big data pipes. Carrier Ethernet CPE that can act as a service hosting element initially can be helpful if your accounts are scattered over a lot of central offices, but if you have concentrated customers you may be able to go directly to server hosting.
It’s probably clear by this point that if you are a capex-driven first-NFV thinker, you’re really building an IaaS cloud and you should think of your NFV strategy as an IaaS strategy first and a network strategy second. Get a lot of cloud-planner input here and you’re likely to have a more successful NFV launch.
Skipping to the last driver on our list, most operators find increased service agility a major justification for NFV. “Service agility” means two things—getting functional elements deployed and integrated into cohesive service offerings, and finding the elements in the first place. Service agility is really all about virtual network functions, in short.
The key question to ask NFV platform providers if agility is your driver is just how VNFs are on-boarded. Some NFV strategies are highly parochial in the VNFs they’d run, which means that you may be either limited by the choices your vendor supports or forced to deploy “silo NFV”, meaning multiple NFV platforms, to insure that you can get a rich supply of virtual functions to build services from. That course of action is likely to complicate service creation and deployment considerably.
But what functions? An agility-driven carrier needs to be thinking first and foremost about the opportunity space. Who do they have to sell to? How will the prospects be reached? How long will the sales cycle be? Can you contain your geographic exposure by limiting the marketing scope, or will you have to be prepared to roll out a service anywhere an order comes in? The intersection of what VNFs you can get and who you can sell services to will determine whether service agility is a real driver or one of those field-of-dreams things.
Ultimately, service agility is a form of software-as-a-service (SaaS). It’s a partner and development process, one that will require that you carefully match targets to software in order to build early profits and gain management buy-in. Logically, agile services should even include cloud-application components—VPNs and CRM together are a stronger offering than either would be separately. Above all, it is not a place to go because you can’t really validate other drivers and you need something to justify NFV. Service agility is the most challenging driver to realize, though it’s the one with the largest upside.
For those with aspirations of using NFV to increase operations efficiencies, then you need to be thinking of your NFV strategy more in terms of how it can harmonize and automate service management than in terms of what virtual functions you need or how you’ll build resource pools. If opex is your thing, then you are really building an extension to OSS/BSS, a CIO-type activity.
NFV operations and management is the least mature and least described of all the NFV capabilities/features. That means that if you’re after opex advantage you’ll need to do some real digging, not only into how NFV elements (VNFs and resources) are managed but also into how NFV element management is linked into overall management practices.
But first, you’ll need to assess the management scope of your NFV offerings. NFV is easiest to manage where it makes up most of the service logic, where SLAs are not rigorous (best efforts is nice), where service-to-resource management correlation is not a strong requirement. NFV management is also easier where resource-sharing is limited, so too many VNFs and too much interconnection makes it more complicated. Remember that opex and capex present approximately equal costs, so if you introduce too much complication into VNF deployment to reduce capex you’re likely to raise operations costs more than you’ve saved.
So what’s the best approach? Most operators will want to look at three service areas first.
First, business services that enhance Carrier Ethernet through the introduction of access-point services like security or facilities monitoring. If these services are viewed as a combination of edge-hosted features and cloud-hosted features you can control first costs better, and business services offer higher revenues to improve early return. They’re also easier to manage using traditional virtual-device strategies.
Second, multi-tenant services for content delivery and mobility. IMS and EPC can both benefit from the introduction of NFV (and SDN) technology, but here it’s important to look beyond a simple translation of service delivery platform services into hosted services. We need to think about IMS and EPC differently to wring out the benefits we need.
Third, integrated cloud services. This is in my view the big opportunity. Users who want cloud computing want it delivered to the workers, not just whizzing about in the aether. Integrating cloud services with VPN or Carrier Ethernet services not only moves the operator up the revenue chain, it moves infrastructure toward large efficient resource pools, making the capex reduction argument stronger. It also encourages cloud-centric operations and management. Win-win.
In 2015 we’re going to test NFV where it counts. I think focusing tests on these three areas is the strategy most likely to pay off for NFV, and for each carrier thinking about it.