In our previous blogs we have discussed the need for Service Providers to offer more enhanced end-user services and the unique advantages in using the home router as a hardware platform for their deployment. In this blog, we will have a closer look at how this may be done today and what types of challenges it raises.
The number one issue facing a Service Provider wishing to add services to the home router is software integration.
Reality is that Service Providers have and will continue to have multiple generations of home routers deployed throughout their infrastructure, supplied by multiple vendors. This means that there is nearly always going to be a whole range of router software packages into which the services need to be integrated. Let’s first have a closer look at the different generations of routers currently out there.
Past generations have seen router software packages evolve from largely proprietary solutions through several generations of open-source distributions. Requirements for more functionality, upgrades and scalability have driven distributions to become more powerful and more adaptable in each regard. Early open-source packages were heavily based on fairly basic Linux distributions to which vendors added their own applications. Later projects such as buildroot and OpenWrt created rich distributions specifically targeted at home routing functions along with flexible packaging schemes. And in recent years we have seen the emergence of RDKB which adds a new level of modularity and scalability to the system. From a hardware perspective, the first generation of devices had very limited memory, subsequent generations saw more and more memory added per generation.
What sort of challenges face Service Providers or their OEM’s in integrating services into these software bases?
Software integration and subsequent QA testing is no doubt one of the bigger nightmares. Router software is complex and integrating new functionality is fraught with risks. New software flows are introduced, timing may change and hidden bugs may be unwittingly exposed. All this needs to be tested carefully. And given the wide variety of versions that are likely to be involved, this effort is replicated for each vendor and each software version.
Another issue is free memory. While it is true that newer routers have more memory (flash and RAM) it is always finite. How many services can be squeezed into the available free memory budget? And how much room does this leave for future services? These are questions that hamper the scalability of a solution.
And finally, there is little re-use of code between different services. The services come from different vendors and each has its own operating requirements. Each integrate with system functions such as user authentication, logging, communications and security in its own way – typically, all will be different.
Some vendors adopt a server-client architecture to address at least part of these issues. In our experience, these clients are frequently still quite large – too large for equipment that is already deployed unless it is very recent or high-end (which most equipment is not). And deploying multiple services means multiple clients so memory restrictions remains a big problem.
A client/server architecture does not improve sharing of functionality either. This means that the Service Providers are still faced with scalability issues of the offering, the complexity of managing multiple clients per single device and with the need to maintain multiple software revisions. In fact, since the server may need to support large networks of users, they need to support clustering, redundancy and switch-over on failure. As along as services are integrated as independent silos, all of this functionality will be replicated as well.
The software complexities will lead to a reduction of stability but will also impact feature and service deployment velocity. This has a negative impact on the customer experience, exactly the thing that Service Providers are looking to improve with end-user services.
More often than not, a router-based portfolio of end-user services results in an offering that is rigid, complex and not scalable. The Service Providers again become a plumber of bandwidth without a lot of competitive differentiation other than the size of the pipe.
So, is it possible to get the best of both worlds? To benefit of the real advantages of the router on one hand and yet free ourselves from its restrictions on the other? Inango Virtual Services is all about delivering on exactly that. But more about that in the next Blog!