There’s no doubt now that the broadband industry is taking a serious look at open-source software for broadband gateways and Wi-Fi CPE. Testing your products that are based on these solutions is vitally important to ensure that your integration is robust, interoperable, and will work well in the field. This article explores some of the best practices for testing these kinds of devices, and what you can do to incorporate them into your development process.
There are a number of reasons that broadband internet providers are moving towards standardized, open-source operating systems for their CPE. These include:
Cost-effectiveness and reduced vendor lock-in: the use of open-source software in CPE can mitigate vendor lock-in, providing operators with more flexibility and the freedom to choose between different vendors or even to switch vendors if needed, without incurring prohibitive costs.
Customizability and innovation: Operators adopting open-source CPE can tailor the software to meet their specific needs and requirements. This level of customizability can be particularly beneficial in addressing unique challenges or in deploying specialized services. Moreover, the collaborative nature of open-source communities encourages a culture of innovation. Operators can benefit from the collective expertise and innovative solutions generated by these communities, staying at the forefront of technological advancements and improving their service offerings.
Accelerated deployment of new services and security patches: Open-source CPE solutions can significantly expedite the deployment of new services and the discovery and patching of vulnerabilities. Moreover, the modular and flexible nature of open-source software allows for quicker integration and rollout of new features and services. Additionally, the availability of pre-built modules, third-party applications, and the collective expertise within open-source communities can further accelerate the development and deployment processes.
There are several open-source solutions that have been developed in recent years through the collaboration of key players in the broadband industry.
The parent of most open-source CPE solutions today, OpenWRT began in 2004 under the GNU GPL. Developers can customize OpenWRT-based firmware to a high degree, including choosing which features and applications to install, using OpenWRT’s package management system. OpenWRT provides a wide range of networking features, including Quality of Service (QoS) controls, network monitoring, and traffic shaping capabilities, which are typically found in more expensive, enterprise-level routers.
RDK-B, or the “Reference Design Kit” for Broadband devices, is an open-source solution spearheaded originally by cable broadband providers to develop a common platform to ensure interoperability, quick deployment, and consistent user experiences. It’s currently maintained by a consortium of participating companies through RDK Management, LLC. RDK-B boasts its modularization, standards-based protocols, and flexibility to reduce development time for broadband device manufacturers.
The prpl Foundation manages several open-source projects all focused on “carrier-grade” broadband and Wi-Fi CPE, including a core operating system (prplOS) and Wi-Fi mesh based on Wi-Fi Alliance EasyMesh (prplMesh). These solutions are focused on providing ISPs with the tools to quickly develop and deploy new features to their CPE including containerized applications specific to the service needs of the consumer.
While the above operating system solutions contain many of the default protocol libraries in any embedded linux-based system, there are always additional open-source options for applications and protocols that enhance the capabilities of the CPE. One example of this is Broadband Forum OB-USP-Agent, an open-source reference implementation of a User Services Platform (TR-369/USP) agent for device management.
No matter which open-source platform you’re using for your products, there are some common tips for testing your implementation. For a more detailed dive into building this kind of testing into your overall development process, we have an in-depth look with Sophie Pool from the RDK testing team at DT.
Start with testing the most basic installation of the open-source software you’re using, running them against the same CDRouter test cases you plan on running against your final product. Both RDK-B and prpl Foundation rely on CDRouter to test revisions and improvements to the official open-source stacks. In the case of RDK-B, they publish their CDRouter test results with each public release in the RDK wiki, giving you a baseline to use right away.
Very few open-source solutions are designed to be complete right out of the box. They are meant to either act as a reference for your own solutions, or as a set of building blocks for you to tailor your CPE to the needs of your network and your customers.
It’s during this stage that unit testing and pipelines that incorporate automated protocol and feature testing are important when developing from an open-source solution. Isolate your own code in these cases and look for outliers.
When you’re ready to test your system as a whole, take your results and compare them to your baseline testing or to the official test results published by the open-source community or standards organization. This will easily illustrate any deltas that occurred when integrating the solution or adding your own features.
This is the best time to consider automation within your entire test process, particularly when integrated with a continuous integration/continuous deployment regime.
If you find something wrong with the open-source code or are finding it difficult to implement for your own use cases, consider giving feedback to the community or joining one of the organizations that develop these solutions for the industry! This is the best way to get your changes incorporated into the underlying code and lets you take advantage of the expertise that has already been developed through the community’s collective experience.
Since the final result of any CPE is a combination of the open-source code it’s built on, the customization process, and the underlying hardware, the baseline testing done by open-source developers isn’t comprehensive enough to qualify any particular solution. Even when building an open-source solution, it’s important to test still:
Performance - How well will your complete product pass high-speed traffic at line rate with low latency? How will it handle quality of service features and prioritization?
Stability - Will your device hold up to strenuous user activity over time? Can you reveal issues that might occur in the field long after a device is deployed ahead of time?
Your custom features - What additional features have you added beyond those supplied by the open-source solution?
QA Cafe is deeply involved in the open-source CPE community. It is used extensively by the RDK-B team and is the official test platform for prpl Foundation high-level API certification and Broadband Forum certification for TR-069, USP/TR-369, and TR-181. In addition, its comprehensive test coverage that includes performance, stability, and hundreds of additional applications and features makes it ideal for anyone developing CPE based on open-source software.
Further resources
