New revenue streams from the home won’t come without CPE containers.
It should be hard for ISPs to contain themselves.
Why does the bill ISPs send their customer each month look like this:
And not like this?
Everyone in the industry has thought about at least a few of these use cases. All services that can be put on top of CPEs. ISPs are screaming for new revenue streams and “dumb pipe” remains the industry's worst nightmare. Meanwhile, few ISPs have deployed multiple, if any, new services. ISPs own the software on CPEs in most homes, but to most, it is a cost, not a benefit. Why is this the case?
Applying experimental software on CPE in the wild is next to impossible
CPEs today have a monolithic software stack. Almost everything is baked into the firmware and adding software on top comes with a huge operational risk. Any error is potentially disastrous, resulting in long QA processes (which are warranted). Getting new software on top of the firmware takes, at best, months. Applying experimental software on CPE in the wild is next to impossible. Not being able to quickly test new types of services, both operationally and actual user testing is a major slow down for the industry. GAFA deploys new software multiple times per day, everything is A/B tested on different users and they try and fail (which everyone does) new services constantly. Knowing what services will catch on is next to impossible before it is tested in the wild. Unfortunately, ISPs now have no possible way of quickly testing new services, leaving new (and possibly existing) revenue streams obtainable for those who can.
Introducing containers. Containers are applications encapsulated in its own “operating system”. The application gets a certain amount of resources (CPU, storage, memory, network), certain types of data, and certain possible commands defined by the Container Format. It is managed and run by a Container Engine. There are several competing Container Engines including Docker, CRI-O, Railcar, RKT, LXC, but let’s leave that for another time.
A simple CPE use-case example: A Wi-Fi Band steering module can be implemented in a container. The environment gives the module: 100 kb of memory and storage, 2% CPU, access to data regarding end-user devices signal strength and capabilities only. Finally, the only command made available is to send band-steering requests. There is nothing else possible to do for the container and the container engine handles any faults. On top of that, an ACS can easily do the installation, upgrades, and uninstallation.
The risks associated with adding new software is removed
Let’s stop for a second and think about what that implies. The risks normally associated with adding new software are all removed. If the container crashes, no problem, if it works poorly, it’s easily uninstalled. The operational risks are removed.
Not only the risk of errors and the software crashing. There are also privacy, security and legal concerns normally associated with additional software (especially from 3rd parties). By isolating the container and what data it can access, many concerns are removed. A band steering module does not need to access sensitive data and all data it accesses can be anonymized, removing privacy concerns.
There are of course some cons. Container environments increase complexity and resource usage, but these cons will be far outweighed by the benefits. Some of the other benefits include making devops able to develop, test and deploy at a much higher rate in live environments. The same environment can be run on different chipsets, firmware, and vendors.
Deploying and testing new services on the fly
Some customers want advanced parental controls, some want Wi-Fi optimization, some want cybersecurity. If the CPEs deployed by the ISP has a container environment, they will be able to deploy containers with new services on the fly.
Continuous deployment, QA, and user-testing.
Adopting the internet giants lean software development processes with continuous deployment, QA, and user-testing. Possibly changing ISP business models.
What are the unused compute resources on CPEs worth for an ISP now? Nothing. Having a container environment on the CPEs will make it possible to put a price on the resources and calculate the business case for a possible new service.
Faster and better RFP processes
The last couple of years there has been a surge of ISPs running procurement processes for Wi-Fi management. Going from an RFP to testing and finally, full deployment of these types can take years. A huge process associated with a lot of risks all for something they might have no conclusive evidence works on their own CPEs. This is but one simple example of the slowness and uncertainty associated with processes of adding new software to CPEs.
In a future with container environments on CPEs that will certainly change. An ISP could issue an RFP specifying trial conditions and the container environment. ISPs could then test different vendors on subsets of their actual user-base. This can be done by deploying the container remotely and only giving it access to non-sensitive information. They will probably be able to test the services from different vendors faster than they can write the RFP. It will lead to faster and better RFP processes.
The industry is waking up
Luckily the industry organizations are waking up. With prpl and Broadband Forum (BBF) leading the pack the future looks manageable. In Broadband Forum’s own words about containers and standardized execution environments;
“Devices implementing these more robust platforms are often capable of downloading new applications dynamically, perhaps even from third-party software providers. These new applications might enhance the existing capabilities of the device or enable the offering of new services. This model differs from previous device software architectures that assumed one monolithic firmware that was downloaded and applied to the device in one action” … “offer new services to customers and therefore increase the revenue per customer, help companies differentiate, and reduce churn with “sticky” applications that maintain interest.”
The prpl foundation also takes containerization seriously and defines it as one of their 5 core activities. In their own words about Containerization;
“Several member companies have joined forces to develop a common model for Linux Container-based service distribution and lifecycle management together with a business model that can unlock new revenue streams for ISPs and CPE vendors”
Software Module Management is defined in the Broadband Forums Universal Services Platform (USP / TR-369) which is the evolution of TR-069. SMM defines the commands for installation, uninstallation, upgrading, downgrading, monitoring and fault handling. That means that containers can be managed by any ACS.
BBFs USP and prplWRT will lay the groundworks for a future with standardized data models from different chipsets and vendors, making containerisation simpler. This will also be the case for multi-AP homes with prplMesh and BBFs OB-MAP. The change will allow CPE vendors, ISPs and 3rd party vendors to look forward and remove their focus from operational risk.
What about the hardware vendors
At first glance, it may look like hardware vendors come out on the losing side of a containerised world because it will be harder to lock in ISPs. However, a push for new services will drive a need for new and improved hardware. Whereas before, the pull for new CPEs mostly comes from new 802.11 and Wi-Fi Alliance releases, containers may offer a game changer. As more and more services can be built on top of CPEs, they will be built. The limited compute, memory and storage will increasingly be a problem. Hopefully, the Catch-22 of ISPs not wanting to invest in better hardware before they see that it can generate more revenue, and more revenue from CPEs requiring better hardware can be circumvented by containers.