Inside RDK

A Unique Feature of RDK-B: WebPA

(Excerpted from the Spring/Summer 2016 RDK Report exclusively for RDKCentral.com)

It’s difficult to take many steps into the language of the RDK-B before running into a recent mainstay: “WebPA.” (Perhaps you, too, have Googled it, only to conclude that the RDK definition probably has very little to do with web-based Peer Assessment.)

The “PA” in WebPA stands for “Protocol Adapter.” It’s a component used to connect devices to clouds in a way that RDK licensees call “trivially scalable.”

As evidence, there’s a planned expansion of WebPA across 20-30 million RDK device types by year-end. WebPA is currently shipping on RDK-B, and is expected to ship in RDK-V as well, as early as the third quarter of this year.

One active use case for WebPA within the RDK community focuses on pre-emptive troubleshooting, by automatically associating customer call-in logs regarding RDK-B devices, with the near-real-time connectivity data (gathered via WebPA) about all RDK-B devices.

As a result, RDK-based multichannel video providers (MVPDs) can start seeing correlations between the two — which counts as early-stage momentum around what can be accomplished, when machine data gets correlated with call-in data.

Unlike TR-69, which polls wide-and-deep across a device landscape, on a less frequent basis, WebPA can precision-poll for the most useful data, much more quickly. That’s mainly because it’s lightweight, and because the load can be redistributed into all the apps needing to access the data.

Specifically, WebPA is a lightweight connectivity socket, with lower-level protocol connectivity between devices, and the cloud — much like a websocket. It works by each client registering with the cloud, so that it maintains a socket connection to the cloud. On the cloud side, APIs enable polls through which other cloud components could receive events, or translate them in to a TR-181 device data model for further analysis.

And, because WebPA is an “always on” connection (websocket), asynchronous notifications for a change in device data are a straightforward exercise, where the application “listens” for webhook events.

RDK community members familiar with the websocket model praise it for its horizontal scalability, in that there’s no rendezvousing or message routing. Because of that, they said, WebPA is easy to use, and powerful.

As for security, WebPA provides a simple REST interface that is accessible from anywhere on the open Internet, with tokenized/encrypted security built-in. In fact, the entire WebPA ecosystem will be open-sourced, including Talaria, Petasos, and Scytale.

Ultimately, TR69 was solving for a different set of problems than what MVPD/broadband providers need, RDK community members said. Not needed were the proprietary and “northbound” ACS (Automatic Configuration Server) interfaces, for instance, managed by the telecom vendor eco-system.

WebPA will be open-sourced on Comcast’s Github page, and the TR-069-to-webPA transition roadmap will start with its XFINITY X1 devices. The transition to tools based on TR-069 will follow in Q2, via a license that enables RDK members to access and use the code.