Everyone wants NFV to succeed including both vendors and operators, and surely the media and analyst communities will find themselves under revenue pressure if NFV fails and something else doesn’t emerge to hype up. From the first, one of the most-promoted examples of NFV has been virtual CPE (vCPE), which propose to substitute hosted connection-point features like security for appliance-based features. The question is whether there’s really hope for vCPE, and if there is whether it will drive NFV deployment. Both those questions may seem to have been answered, but that’s not the case.
The principle behind vCPE is that there are a bunch of service-edge features that currently would be implemented using separate devices, but that could be hosted via NFV instead. The idea is that the sum of the costs of the appliances would be far greater than the cost of hosting the features, and that the use of hosting could radically reduce the number of truck rolls needed to install and support the features. Some believe that users would be induced to buy more features if they could be delivered and installed instantly.
The most obvious question about vCPE is whether it’s really NFV at all. The vCPE model that prevails today is a smart edge device or board into which features are loaded. This model is a sharp contrast to the cloud-resource-pool model envisioned by the ETSI NFV specifications. You don’t have to decide where to host something; the only option is the service edge device. Management isn’t an issue because you manage a box just like you always did. Orchestration is trivial because everything you deploy is co-located.
To be fair, there is an application of vCPE as an on-ramp to NFV services, a means of addressing the “first-cost” of NFV where you have to deploy a massive resource pool to achieve economy of scale before you have even a single customer. The notion is that you start with vCPE then move to a pool-hosted solution when you gain service mass. That’s fine, but if you’re going to do that then you need to have a real NFV management and orchestration platform in place to control services before and after your move to the cloud, or you don’t have continuity of management practices.
You also have to ask whether you have enough demand to justify a resource pool in the first place. In the US, there are about 150,000 businesses that have multiple sites, perhaps a half-million worldwide. These are the primary targets for vCPE. If we take the US number and look at the distribution by metro area, the average is 50 sites per metropolitan statistical area, or about 20 per central office. About half of all MSAs and COs have less than five business sites. Is there enough here to build a pool? I don’t think so.
That raises the biggest question with vCPE, which is just what CPE we’re talking about. There’s a lovely (and not uncharacteristic) fuzziness about just who the vCPE user might be, perhaps because that’s not an easy question to answer.
Carrier Ethernet is the place where vCPE has been tested and applied most often. Business users do in fact often buy service-edge features by buying appliances. We’ve already talked about the limited number of business sites, so let’s look at the total service revenue opportunity. The global revenue from carrier Ethernet services this year will likely be only about $38 billion. Even if we presumed that these users spent as much on vCPE features as they did on services, we’ve not exactly generated an explosive opportunity for new services. Telecom services overall run well over two trillion dollars, after all.
This raises an important point for vCPE and NFV, which is that there simply isn’t enough money on the business vCPE table to drive significant NFV deployment, even without considering whether there’s a pathway for evolution to a pool of resources from the edge-hosting model. You’d need consumer CPE to make it worthwhile.
OK, why not? Well, remember that what we’re talking about is virtualizing the service features, not the entire box. Consumer broadband needs to terminate the broadband access connection and generate local WiFi connectivity. Those are physical functions you don’t displace with vCPE; we still need a box on premises. Yes, that box has perhaps DNS, DHCP, and firewall support, but those features are basis and rarely change. How many truck rolls do you get because you have to change out a consumer firewall?
Then, for both business and consumer, there’s box cost. You can buy a minimalist Ethernet termination box with firewall, DHCP, etc. for under $500, and a consumer broadband gateway for under $40, retail. Cable terminations are about a hundred bucks. One network operator told me they buy a broadband gateway with WiFi for $17. Most operators say the average installed life for such a consumer device is 5-7 years, and for businesses 4-6 years. Do the amortization math here and you see that the total cost of providing the service-edge features with a custom appliance is perhaps $7 per year per consumer or perhaps $100 per year for a business. Do you think you can provide a feature-hosted alternative for a lot less than that?
So does this prove that vCPE is a bad idea? Not at all. It’s a good way of adding feature agility and dynamism to an existing carrier Ethernet service, and it might be a good way of supporting home-video-broadband gateways. If you can expand the repertoire of features beyond the basic security/connectivity features of today, you can make a case for vCPE. What’s not easy is making a case that vCPE drives NFV deployment.
So am I saying that vCPE is a dead end, NFV-wise? No, but what I’m saying is that vCPE won’t justify it. You can make vCPE an on-ramp to NFV providing that you deploy it within a real NFV framework that can do top-down orchestration that in particular integrates operations (OSS/BSS) and management (NMS, NOC) and some higher-layer service order and support portal. Very few vCPE vendors have the tools to extend their solution to the broad NFV opportunity.
The largest problem vCPE faces today is the risk of being stranded in a silo if you deploy it. Everyone is assuming that we’ll somehow converge on a strong, universal, NFV solution and that everything that purports to be NFV today will fit in it. That is a worthy hope, but not an assumption that we can validate. If you want to do vCPE and you want to evolve from it to real NFV, you’ll need to pick a solution that can make the broad business case first, then fit your vCPE strategy inside it.