You have to love the notion that we have “universal CPE” that somehow seems designed to serve one mission. The great majority of uCPE products seem directed at the NFV-related “virtual CPE” or vCPE goal of having a box on premises that can be remotely augmented with endpoint features like firewall, encryption, and perhaps SD-WAN. I never thought vCPE was an application with earth-shaking impact, so as the total mission for uCPE it seems a yawn. Are there other missions, and if so what would uCPE end up looking like?
CPE-edge devices serve two broad missions, one to terminate a connection service and host service-related features, and the other to provide local processing that coordinates in some way with deeper processing capabilities, including perhaps in a cloud. To be “universal” a uCPE strategy has to cover both areas.
Connection-point services are divided less by the service than by the nature of the customer. Business users with carrier Ethernet connections typically have a need for rich service management tools and a number of features associated with the service itself—firewall is the most popular example, but some users (SMBs in particular) would like things like email servers with anti-virus, DNS/DHCP, encryption, SD-WAN, and more. Consumers actually want similar capabilities, but in the consumer space there is an almost automatic presumption that WiFi will be provided by the box. That means that the box itself has to be “real” not virtual, and since user demands for connection-point features are fairly static, there’s less value in having dynamic feature-loading capability.
The enterprises I’ve talked with are interested in uCPE for connection-point services only to the extent that they lower TCO. A significant reduction would be required (25% minimum) to induce a change, and only displaceable assets would be targeted. On the average, these enterprises have about two years of useful life remaining in their current service-edge strategy, so that limits the benefits to be reaped from uCPE replacement.
Operators are mixed on the value of uCPE for consumer termination. Some operators like the idea of having the ability to remotely update features/firmware, but others see that as a source of complaints and perhaps even lawsuits. In established market areas, the prevailing view is that consumers aren’t a target of opportunity at all. For consumerish uCPE, the best target might be branch office locations that utilize consumer-like broadband technology for connection. Since this space is the target of SD-WAN vendors, it’s likely that uCPE’s future for connection services will depend on SD-WAN.
The requirements for uCPE from connection-point services are easy to define; they would logically fit a mixture of P4 programming for flow-handling missions and more traditional function execution, where general-purpose hardware and software would work. You can make Linux or embedded OSs work for that. For symbiotic edge-of-cloud missions it’s harder, because you have to not only understand what the broad mission is, but also how separating some features off to be run at the edge would benefit the application overall. Only then can you say what features would be useful.
If we go beyond connection-point services, things get more complicated rather than getting simpler. We’ve known for some time, because of things that cloud providers like Amazon and Microsoft have done, that there is a role for devices that act as a kind of on-premises agent for cloud services. Amazon’s Greengrass IoT function hosting is a good example of this, but IoT is far from the only example.
IoT is an event-driven service, and event processing is probably the most credible application for edge computing in terms of feature requirements and future potential, but it’s not a strong near-term driver. That doesn’t mean it won’t impact uCPE requirements, though. The useful life of a uCPE box is likely to be three to five years, and by that time IoT could be the largest single driver. The most significant difference with IoT is that you probably don’t need a general-purpose processor and traditional operating system, and if you could trade those two against device cost or event-specialized features, it would likely be worth it.
A nearer-term example of a useful edge mission for uCPE, one applicable in the consumer space, is video and ad caching. We’re moving now from streaming as a library function to streaming as a substitute for linear TV. The latter places a significant restriction on cache delays because if video is held up, or if ads can’t be started on time and kept within the allocated slot, you either drop something or you overrun into the next program. Caching, compression, pre-staging of ads, and other stuff suitable for uCPE support could address these issues. We already have streaming devices to link to these services; could these devices evolve to a form of uCPE?
That may be the real issue with “universalism”. If we look across the consumer and business spaces, the working and entertainment missions, the connection-point and event-based edge-of-cloud roles, we quickly see a very large range of CPE types. If we define a single box targeted at one of perhaps two dozen possible combinations of missions and roles and types, we’re hardly universal. That undermines the accuracy of the term, but worse it undermines the credibility of the whole concept. I have a universal box for you, dear operator, but you’ll need it and twelve other forms of CPE to cover your needs. Not a good sales positioning.
It’s doubtful whether we could shoehorn a streaming stick consumer device and a universal carrier Ethernet termination into the same box, without making one or both the applications a waste of time for cost or functionality reasons. We might see growth in the scope of missions, though. Might consumer devices, for example, absorb things like personal agent features, email and IM clients, caching for video and even video guide features? Clearly that could happen. Might it also absorb IoT features for smart home? Even more likely.
We have all this stuff already, of course, spread around in different boxes or software elements. We did that not because we didn’t have universal CPE, but because we didn’t have universal requirements to converge on a single model that would be cost- and feature-effective in all the missions. We did purpose-built stuff because people typically had one purpose in mind at a time. That’s not true now, and so we have to juggle the timing with which uCPE opportunities will emerge to decide what’s best.
