In my last blog, we explored the advantages of virtualizing network and gateway functions to reduce CAPEX and OPEX using virtual customer premises equipment (vCPE). But this raised a new question: Should service providers virtualize the entire network and gateway, or is it better to adopt a hybrid approach? Additionally, how long should you wait to transition to a virtual approach?
History has shown that with each extreme of the spectrum, specific advantages can be achieved. Typically, the ideal placement is somewhere on the spectrum that affords you the opportunity to choose the attributes that are ideal for the problem you are trying to solve.
Over the last decade we have seen successive advancements in the types of gateways being deployed, from the days of simple Ethernet Access Devices (EAD) to complex gateways that support media streaming, parental controls, time blocking, multiple WiFi radios, advanced diagnostics, and even embedded MTA capabilities. In this timespan, we have seen essentially both ends of the spectrum surface. While rigid single-purpose CPEs can be more efficient than their virtual counterparts, they lack the flexibility that allows operators to increase time-to-market for new services and scale operations to accommodate newer, better customer service models.
The philosophy of the network function virtualization (NFV) movement is to move as much of the software stack as possible off the end-of-line device and into a virtualized environment, which can be leveraged to quickly provision and add new functional capabilities without the need for firmware updates.
A more traditional approach to the virtualized gateway would see it adopting virtualization for only new or undefined functionality. This gateway would still be a complex embedded device with all the modern-day capabilities, but with arbitrary functionality that can be dynamically loaded remotely. The challenge of continuing on that path is that you are left with a costly, non-standard platform with divergent offerings and software capabilities. The optimal approach would be to isolate and decouple as much software from hardware, while still retaining today’s advanced capabilities.
There are many benefits to this strategy:
- Vendor-agnostic with common functional software stack
- Standardization reduces yearly CAPEX and OPEX budgets
- Operator control over creating and deploying new software capabilities to any/all gateways
- Future-proof platform with programmable, configurable capabilities, without having to wait for an updated firmware
- Ability to deploy virtualized functionality where it is most cost-effective and derives economies of scale
- Consolidation reduces power consumption for outside plant
- Reduce the amount of truck rolls and customer complaints to replace legacy devices with ones capable of supporting current offerings
Adopting these optimal strategic goals, we see the picture of an ultimate gateway: an EAD with advanced hardware capabilities — including multiple wireless radios, remote diagnostics, and other differentiating capabilities — with the software stack for the gateway being virtualized, including everything from DHCP to time blocking and CPE usage stats. Best of all, this approach to vCPE works with existing deployed gateways, virtually eliminating the barrier to adopting vCPE today and abolishing the need to wait any longer for adoption.
If you have legacy devices that cannot run arbitrary loaded functionality remotely, the choice is clear. With a comprehensive virtualization solution, you can essentially hit the virtual turbo button on your legacy devices — maximizing your sunk CAPEX, enabling you to add advanced functionality to end-of-life (EOL), unsupported, legacy devices without having to modify the firmware. Doesn’t that sound nice?