Powerful forces are steering the development of the CPE, explains Pravin Mirchandani, CMO at service-enabling network access specialist, OneAccess.
As the telecoms industry continues to hack a path toward network virtualization, the terms used to describe future customer premises equipment (CPE) are under almost continuous review. ‘White box’, ‘virtual CPE’ (vCPE) and ‘physical CPE’ (pCPE) each represent their own specific and shifting vision of how the network functions present in today’s CPE will be virtualized. But beneath the jargon, two powerful forces are steering the technology’s development.
1. The need to support non-Ethernet legacy connections
Ethernet is the assumed and, by and large, the only connectivity option for a low-cost white box approach, yet it is far from ubiquitously available as a WAN connectivity option at the customer premises. What’s more, the cost of increasing Ethernet coverage for connecting customer premises (typically by fiber) is growing as the lower cost, high-density deployment options become exhausted. Consequently, one of the key issues that virtualization faces is the need to support legacy connections between TDM-based PBX, alarm and other serial connections to various types of DSL-based WAN access technologies. This means that the bridging technology - the purpose-designed CPE - will be around for some time, especially for network connectivity devices and voice gateways.
2. To work, some functions need to be on the network’s edge
As the guy responsible for products at an access platform CPE vendor, what strikes me about our current work plan and roadmap is the huge amount of additional functionality that our CSP and MSP customers are asking us to deliver in our current-generation CPE. These include link management schemes for failover, bonding and offload; as well as shaping and event-based schemes, to ensure that business-critical Cloud-based applications flow regardless of the state of the network. Additional measurement capability is also being demanded, to remotely diagnose issues and ensure that SLAs are met. Security-hardening is also a request. The list goes on. By their nature, these types of intelligent functions have to reside in the CPE; you can’t failover, offload or measure local service levels remotely from the Cloud.
Given that you can’t economically ‘white-box’ legacy connectivity requirements, nor can you centralize network functions that rightly belong on the customer premises, only part of the CPE is ripe for virtualization. With this in mind, don’t expect today’s CPE appliances to disappear from the network’s edge any time soon.
Strength in options
Different operators have different requirements, so it is unrealistic to expect a one-size-fits-all approach to the CPE. Service providers and equipment vendors that can accommodate the broad range of these requirements will thrive. Pure-play vCPE vendors, it seems, will have a long wait before they become the preferred deployment option for enterprise services.
