We had the opportunity to speak with Steen Garbers Enevoldsen, head of Net Research and Development at Fullrate, and blogger, columnist and youtuber in his spare time. Fullrate is a service provider in Denmark who uses of CDRouter for their CPE testing.
In this article, Steen tells us why testing CPE is vitally important, why CDRouter is a must have for any service provider, and how he built a 3-D printed robot controlled by CDRouter.
The need for CPE testing
As an Internet Service Provider I deliver Internet services to my customers, but you don’t just show up on people’s doorstep, handing over a portion of “internet”. Delivering Internet implies that the ISP delivers a device capable of terminating the Internet connection at the customer premises, affectionately called “The CPE”, “The Router” or (at least in Denmark) most commonly: The “Wi-Fi Router”.
An alternative, albeit less desirable, term sometimes used by both customers and helpdesk is “that piece of crap”.
How to avoid excessive use of this term is the scope of this article.
An ISP can deliver Internet via the most stable and well-built access network in the world, but the end-user experience is never better than the weakest link in the chain, and very often the weakest link is indeed the Wi-Fi router.
Why is this?
"AN ABSOLUTELY INDISPENSABLE TOOL FOR AN ISP!" - Steen Garbers Enevoldsen, head of Net Research and Development at Fullrate
The home/Wi-Fi router is complex
Well first of all, of all different devices that comprise a typical ISP, the CPE is the device that must support most different features, and as a consequence the software is very complex.
Consider how services and features are handled in the core network: Routing, Switching, DHCP, DNS, VoIP etc. are typically all taken care of by several different dedicated pieces of (high-cost) hardware in the datacenter, but all these services and features are terminated/handled by one single piece of hardware at the customer: the CPE. An extremely cost-sensitive “consumer-grade” device with limited CPU and memory resources.
The Wi-Fi router sent to the customer will face an unpredictable number and types of client devices and usage, spanning from a single iPad to 30+ devices. The customer expects 10-year old Wi-Fi devices to still work flawlessly on the very same Wi-Fi router that must support the latest state-of-the-art smartphone.
So how does the ISP minimize the risk of errors in the Wi-Fi router? Testing. Lots of testing!
Complex testing requires automation
Manually performing all these tests is a daunting task, and besides being extremely time-consuming, the human element introduces risk of errors and potential oversights.
This is where an automated test tool such as CDRouter from QA Cafe comes into play, offering thousands of automated test cases covering all nooks and crannies of the RFCs at the click of a button. An absolutely indispensable tool for an ISP!
To make the tests truly automated, you need a way of turning off/on the CPE prior to testing, and I thought it could be fun to build a device myself to handle this task. Then I thought “Hm, it would be nice to be able to interact with the buttons on the CPE during testing”, and things kind of escalated from there.
Why not build a robot controlled by CDRouter scripts?
After a whole lot of 3d modelling, 3d printing, soldering and coding this is what I came up with:
The test-jig is tailor-made for the Sagemcom Fast5353 CPE which is one of the current CPE’s we’re shipping today, and when introducing a new model, I will build a jig specific to this CPE model. The jig could be made generic, but it’s not needed for my purposes. At least not yet!
The test-jig controlled by a Raspberry Pi and is capable of interacting with the reset, Wi-Fi, and WPS buttons of the CPE using standard R/C servos, and turning on/off the power using a relay.
The strangely looking funnel below the CPE is actually a camera-mount used to keep a real-time status on the LED-behaviour of the CPE during testing. The funnel prevents unwanted light from affecting the image.
Monitoring the LED’s is really useful when used to enrich the logs coming from CDRouter tests. This way we can see if the CPE actually crashed during a test. We can verify how the CPE handles unwanted input during firmware upgrades, test Wi-Fi and WPS behavior, make sure DSL is in “Showtime” before test, etc.
An alternative to the camera would be individual RGB sensors, but this would increase the cost of the solution, and it would make it a more time-consuming task to switch out the CPE to be tested. On this jig, swapping the CPE only takes a few seconds.
The current design consists of approximately 35 different parts all printed in PLA and is specific to the Fast 5353 CPE.
The jig is working nicely now, but I am considering a few improvements for a future release. Especially the way I control the servos is a bit too primitive. Currently I apply a PWM signal corresponding to the exact position of the servo needed to press a button. Instead of specifying the position, I would prefer to specify a torque. This can be done by adding current sensing to each servo, since the current draw of the servo is directly proportional to the torque exercised. But that’s for when I have some more time.
About Fullrate:
Fullrate is a subsidiary of YouSee (the ILEC in Denmark). We offer 3-play services to ~150,000 customers on a mixture of DSL and COAX, and cellular services to 350,000 customers across Denmark.
About the author:
Steen Garbers Enevoldsen, M.Sc is head of Net Research and Development at Fullrate, and blogger, columnist and youtuber in his spare time, writing and talking about technology and geeky stuff.
Find Steen on Twitter: @steenenevoldsen
YouTube (note: Danish content)
Email: steen@ieee.org
