By Charles Cheevers, Chief Technology Officer, Customer Premise Equipment, ARRIS
It’s been a couple of years now since we pointed out the natural one-two punch that is RDK for Broadband (aka RDK-B) and the DOCSIS 3.1 platform. Or, as I like to call it, a marriage made in heaven.
It’s natural, because it’s a Software Solution complement for the introduction of DOCSIS 3.1 based services. DOCSIS 3.1 was developed to give the bandwidth for Multichannel Video Programming Distributors (MVPDs) to transition to IP Video services and to grow into the IoT growth space. We have now started, as an industry, to evolve the MVPD networks to DOCSIS 3.1, so the natural evolution is for the MVPDs to now leverage DOCSIS 3.1 as a way to complete the IP Video transition.
It’s a one-two punch of future-proofing, and tempo: Future-proofing, because of what RDK-B brings to the inevitability of IP-delivered video, Wi-Fi superiority, and the Internet of Things. Tempo, as in faster deployment of new services– and because the “cadence” and “velocity” descriptors are perhaps getting a little long in the tooth! Whatever we call it, DOCSIS 3.1 + RDK-B implementations will be the impetus to move onto new, cloud-based software services with the promise of generating new ARPU and also “stickiness” with customers.
Now, devices based on DOCSIS 3.1 are heading into the industrial mainstream. It’s a big thing (as big as the original DOCSIS 1.0 specification, 20 years ago, if you ask me) because it is a 2.5-5x increase in broadband capacity in the forward and reverse signal directions. RDK-B as the base stack takes you on this DOCSIS 3.1 cadence — with IP Video as a key application. With the work done by Comcast, RDK LLC, silicon partners and OEMs, customizations can cover the specific requirements of the MVPD – because the platform is built to meet the migration to IP video, IoT and Multi-AP Wi-Fi solutions.
So, as we said in 2015 – for best results, use the introduction of DOCSIS 3.1 services and devices to also migrate to the RDK-B stack and get ready to pull in those new enabled services.
IP Video can’t happen without really good Wi-Fi
It wasn’t all that long ago when we were all somewhat startled to learn that half of all Internet connects were Wi-Fi. Get this: Now, when people connect their devices to the Internet, >90% of those connects are happening over Wi-Fi. It’s not a percentage that’s likely to go anywhere but up.
RDK-B addresses the growth of Wi-Fi as the preferred Internet connectivity medium in multiple ways. Topologically, it supports both centralized and distributed in-home Access Point (AP) environments. By that I mean, as we move to IP Video in the bedroom – we need to add in additional Wi-Fi Access Points to make sure that the Wi-Fi based IP Video set-top box (STB) is able to work as good as a wired connection.
This naturally requires good hardware and Wi-Fi physics – but, increasingly, also requires good software, to manage Multiple Access Points and the Wi-Fi STB. RDK-B provides platforming tools to help “onboard” these Multi-APs and Wi-Fi STBs – and companies like, oh, say ARRIS, to name one, can also add elements like steering logic and zero touch onboarding solutions to create a resilient platform for IP Video distribution.
Self-healing is another key focus of Software solutions for Wi-Fi, integrating APIs for Wi-Fi support for features like Band Steering and Client Steering solutions. RDK-B comes in here by offering APIs to support these features, which, in turn, allow companies like the one I work for to create the algorithms and applications that assure Wi-Fi connections in the home under software control.
(Indulge me, please: The ARRIS Home Network Controller solution, for instance, allows low latency Client Steering, and our ECO Cloud Solution allows the ability to develop new healing policies, based on analyzing the TR181 information pulled from the RDK-B based device. This ability to leverage the RDK-B stack, to develop these desired solutions that give MVPDs control and transparency over Wi-Fi performance, is THE key feature going forward in the Wireless home.)
And Then There’s Device Onboarding
While DOCSIS 3.1 does its work to widen the broadband pathways into and out of homes and businesses, RDK-B handles the often-tedious work of recognizing and seamlessly connecting IP devices — PCs, laptops, tablets, smart phones, anything designed to live via an Internet connection. That necessarily includes the IoT ecosystem, too.
A brief anecdote on this topic: As you might imagine, I am the kind of guy who invariably approaches any “misbehaving device” with a “must conquer!” demeanor. I will fiddle and futz with a sensor, IoT gadget, rogue tablet, or otherwise addled IP connection until it works.
Most people, so I’m told, aren’t like this. The more unsuccessful attempts, the less inclination to try again. This is why IoT devices fly almost as quickly back onto the shelves as they flew off of them in the first place. Onboarding failures either go back to the store, or join the other “misfit toys” in that cardboard box in the garage.
RDK-B is attempting to solve this, both in terms of radio (Wi-Fi, Bluetooth, etc.) and device protocol (IoTivity, Thread, ZigBee, BLE). In particular, this involves providing software services to allow both Wi-Fi devices and IoT low-power based devices to be onboarded to the RDK-B Hub device. The MSO or their favorite OEM (think ARRIS 😉 ) can then develop applications quicker.
To this end, RDK-B has added default SSID for easy Wi-Fi onboarding, and is in the process of trying to put together a common IoT onboarding Hub – where all the mainstream protocols can meet. ARRIS has already integrated IoTivity, Thread, BLE and ZigBee into its RDK-B runtime, for instance, so that MVPDs, can take advantage of the standardization and availability of these solutions.
Which brings us to Video Over IP — and Wi-Fi
Last not least, the serendipity of RDK-B, DOCSIS 3.1, and the future of video distribution toward “all-IP.” HD video is big; 4K video is bigger; 8K video is bigger yet. That’s where D3.1 gets to show its strength. RDK-B and RDK-V play their part to track these changes in service delivery, and have been tracking both Unicast and Multicast delivery of these services.
Multicast vs Unicast is an ongoing debate amongst MVPDs, especially as they analyze the viewing behavior for live and time shifted viewing. Whichever way you want to play it, RDK-B based devices and RDK-B feature evolution will be there, with current RDK-B solutions already offering Multicast to Unicast conversion for delivery over Wi-Fi.
It won’t happen overnight, but the trajectory seems pretty clear: Devices based on RDK-V (video), and running on QAM, will sunset. Devices based on RDK-B, running on IP, will expand to absorb and deliver video — and video over Wi-Fi. At the recent CableLabs Winter conference, for instance, panelists (myself included) on an IP Video segment were asked when the last QAM service would be shut off in the MVPD network. The answers ranged from 2023 to 2027 – so, predictions from 6 years from now to 10 years from now! (Not long ago, the answers usually were some shade of “not in my lifetime.”) Swapping out QAM-only CPE takes time – but if you look at much of the QAM based investment now, the devices going in are primarily hybrid QAM-IP devices, which necessarily support DOCSIS IP delivery.
What Still Needs to Happen
Any open source effort, RDK-B necessarily included, is a perpetual work in process, as the code base and roadmap grows — at a tempo that satisfies competitive differentiation.
As I said at this year’s RDK Americas Summit in Denver: The MVPD community, through the launch of DOCSIS 3.1, has an inflection point to migrate to RDK-B based services. This will widen the community of active RDK-B MVPD users and so should also drive the contributions of code to a wider group of OEMs, MVPDs, and other contributors. As we discuss all of this with prospective new RDK-B users, we routinely see that they need some specific and customized elements to transition their IP networks to RDK-B and IP Video in particular. And that’s ok! This will drive opportunities to contribute and re-use these changes to accelerate pull in of services for all users.
In closing: Last year, we did a feature gap analysis between RDK-B and the use of other stacks and features in the MSO community. I’m happy to report that with the ongoing work by the RDK Management LLC and other RDK contributors, that feature gap has slimmed down. ARRIS has been working with the MVPDs to propose solutions to complete the feature gap for their network deployments.
So, with the rollout of DOCSIS 3.1, we believe the MVPD can and will take this inflection point to migrate to RDK-B. And, not to worry — your friendly OEM will ensure a smooth integration into the various different back offices!
This is a promotion by an RDK MSP member and the content is not the responsibility of RDK Management nor do we explicitly endorse the message provided by this MSP member.