Skip to end of metadata
Go to start of metadata

Introduction

The complexities originating from the non-standard nature of software stacks that run on most cable set-top boxes considerably impacts new feature rollout and makes it difficult for an MSO to have a uniform branding strategy and theme across their population of set-tops. New feature rollouts fall victim to the delays and problems associated with the regression of these features on existing and planned devices, which often do not share a standard set of software components. Given the proliferation of new user-friendly applications in consumer's living rooms, it is imperative that Comcast and other MSOs settle on a common platform that will enable the rapid development and deployment of these state-of-the-art applications to in-home devices.


The Reference Design Kit (RDK) is a complete, fully integrated software bundle, specified by Comcast to run on QAMIP-Only and Hybrid (QAM+IP) devices. RDK components are available for use on devices used by any operator. It is modular, so MSOs can separately deploy parts of the larger set. However, it is specified and tested by the System on a Chip (SoC) vendor as one bundle. The majority of the RDK software components are available to members of the closed community as shared resources. This enables participants to access any modifications or fixes at the same time.


The RDK is mostly based on open source components and standards, such as the Linux kernel and drivers, Busybox, OpenSSL, OCAP-RI, QT, OpenGL, DirectFB, Gstreamer, UPnP libraries and so on. The small subset of components that are developed by Comcast are made available to the community of RDK users for comments and improvements. While there exists a common set of functionality that is required to be supported by all RDK devices such as tuning, graphics, standard output port requirements and so on, the exact requirements are available as part of a separate set of hardware specifications which are usually made available by the MSO tailored to the type of device being developed.


The table below describes the four high-level partitions that make up a typical RDK-based software stack – these are the RDK, CPC, SoC RDK and OEM software.

 

RDK
(Reference Design Kit)

  • SoC or device independent software components
  • Comprises patches for open source and third-party components
  • Does not include Comcast exclusive or proprietary components

CPC
(Comcast Platform Components )

  • SoC or device independent software components
  • Components that run exclusively on Comcast devices
  • Components that contain information proprietary to Comcast

SoC RDK

  • SoC dependent software components.
  • Comprises SoC patches for Generic, CPC and SDK components.
  • Contains SDK, toolchains and base rootfs

OEM Software

  • Device dependent software components.
  • Comprises device patches for Generic, CPC and SoC components.
  • Comprises tools to generate deployable images

Comcast would release the RDK and CPC source code to its licensees. The SoC RDK is distributed by the SoC vendor. OEM software consists of any complementary software components that are added on by the OEM to create a fully functional set-top box.

RDK Components

The figure below shows components that would typically be part of an RDK-based software stack.

Figure 1: RDK Software Stack


The three different perspectives or views into the RDK software stack help gain a better understanding and appreciations for the RDK software stack.

  1. Viewing the stack as increasing levels of abstraction.
  2. Viewing the stack by the source or component owner.
  3. Viewing the stack in terms of the deployment configuration – IP, QAM or both.

As increasing levels of abstraction

The figure below looks at the stack as increasing levels of abstraction. This is akin to flipping the RDK component diagram on its head. Notice that at the bottom we have generic components (RDK and CPC) that are meant to run across all platforms and all devices. As we move to up to the SoC layer, we obtain all SoC-layer software components such as the SDK and any SoC-level for generic RDK and CPC components. An example, would be the HAL layer implementation for components such as QT, Gstreamer or the OCAP-RI. Further up the stack are device-layer software components. These could be specializations to generic or SoC components at the device layer or complementary software components provided by the OEM to create a fully functional set-top.


 
Figure 2: RDK Software Stack as increasing levels of abstraction

By the source or component owner

Another way to look at the RDK software stack is through the various sources that provide the components that would make up a fully functional set-top. The main sources of RDK components are

  1. Opensource Community – the open source community of software developers.
  2. Comcast or MSO components
    • Components that are developed directly by Comcast.
    • Components developed by third-party vendors but licensed to Comcast for distribution.
  3. SoC vendor
    • Components released by the SoC manufacturer.
    • Typically includes the SDK and patches to RDK components.
  4. Third-Party component owners
    • Components not released by Comcast,
    • Need special licensing arrangements with the component owners
    • Required to achieve full functionality.
  5. OEM
    • Components released by the set-top manufacturer.

In terms of the deployment configuration

A third way to look at the RDK software stack is based on the device type – IP-only versus a hybrid IP+QAM device. An additional option here is a pure QAM but that is not being discussed since a QAM device would typically be able to support IP-based streaming as well.

  1. IP-Only Client
    • Components to execute the RDK in an IP-only video acquisition.
    • No QAM-based tuning.
    • Pure IP set-tops interacting with the Comcast IP gateway devices or home networking clients.
  2. Media Gateway support
    • Support for IP-based video acquisition.
    • Support for QAM-based video acquisition
    • Headed or Headless configuration.
    • Home networking servers

Architectural Overview

Windowing Framework - Qt/Webkit

Graphics Engine - OpenGL/ES
Support for hardware acceleration.

Media Framework - GStreamer
Current – Mix of native SoC pipeline architecture and Gstreamer
Eventual transition to full Gstreamer-based pipeline.
Support for hardware acceleration.
Application layer interface for media operations.

Event Manager - Fusiondale.

Management Subsystem - SNMP and TR-69.

Security Subsystem – Secure Processor support
DRM, Firmware Download, TLS and all crypto functions.

System Integration Scripts for startup and run-time orchestration of resident processes and functionality.

Feature Overview

  • Audio/Video
    • Cablecard
    • Channel Map
    • Closed Captioning
    • Parental Control
    • PPV
    • VOD
    • Timeshift Buffer
    • Audio Language selection
  • Code Download
    • DOCSIS code download
    • HTTP-based code download
  • Copy Protection
    • HDCP
    • Adobe Flash Access 
    • Microsoft Playready
  • Diagnostics
    • Log/Error Management
    • Crash Management
  • Event Management Framework
  • Management 
    • SNMP
    • TR-69
  • Storage Management.
    • Expansion Disk support.
    • Graphics/HTML Rendering
  • Device Settings
    • Front Panel
    • Output Port Settings
  • Home Networking
    • DLNA with VPOP, CVP-1 and CVP-2 support
  • User Input Handling
    • Keyboard
    • RF4CE Remote 
    • IR Remote
    • Mouse
  • Robustness and Security features
  • Development Support Features
    • Simple IP-based code download
    • Executing filesystem from external media.

RDK-based Development

  • RDK Porting Guide provides step-by-step instructions on building a fully functional software stack using the RDK.
  • The main steps in the development process are as follows
    • Setting the host environment where the builds will be performed.
    • Obtaining components for the build. Key components are listed below
      • RDK package and specified Open Source and Third Party software components.
      • CPC* package
      • SoC SDK*, toolchains, rootfs, kernel, docsis images (for a QAM device), SoC vendor libraries and SDK, CPC and RDK patches at the SoC layer.
      • OEM software.
    • Installing toolchains and any other tools required for cross-compilation.
    • Building the SDK. This step usually involves building the kernel, rootf and SDK binaries/libraries.
    • Building RDK and CPC* components.
    • Configuring startup scripts.
    • Validating functionality.

*CPC – Only applicable when developing a stack for Comcast.

*SoC SDK – SoC SDK & all SoC RDK software is provided by the SoC vendor.

  • No labels