RDK Resources

[*RDK Preferred*]

Code Management Facility

Code Releases

RDK Forums

[RDK Conferences]

RDK Support

Archives

Papers & Presentations Archive

In the News!

Skip to end of metadata
Go to start of metadata

RDK-B is developed as a modular software stack built from a collection of individually reusable software components and is based on the following design considerations:

  • Software modularity
  • Abstraction of external management protocols
  • Independence from wide area network type
  • Silicon independence
  • Linux kernel independence
  • Software structure that allows multiple organizations and teams to work in parallel

The architecture supports pluggable component modules which communicate over the CCSP message bus. RDK-B uses a collection of protocol agent components and supports multiple device management protocols(TR-069, SNMP etc). Protocol agents process the protocol specific details and provide abstraction to the common internal data model.

TR-181 data model is the common internal data model used by all RDK-B components to communicate over the message bus. RDK-B also supports multiple SoC vendors through component level hardware abstraction layers.



RDK-B-Architecture


  • RDKB is architected with “Software Components” . A software component is a software package that delivers a set of features or services.  Examples: Cable Modem (CM) Agent, EPON Agent, DSL Agent, WiFi AP Manager, TR-069 Protocol Adapter, WebPA, DMCLI.
  • RDK-B is Yocto based and it can run on any modern Linux kernel and can easily be ported/customised by developers.
  • Also, RDK-B is not dependent on WAN type and supports DOCSIS and EPON.

RDKB Goals

High Software Velocity

  • Architecture supports plugin component modules for all using Linux DBus
  • Teams can create components in parallel
  • Leverages open source within Architecture Framework and within   components

Easily create product variants

  • Choose which components are needed for each product
  • Architecture supports run time service discovery and component registration

Support multiple management protocols and data models

  • Simultaneously support multiple  Device Management  protocols and interfaces through plugin “Protocol Agents". Adding a new management protocol or data model doesn’t change existing components
  •  TR-069 with TR-181, SNMP, WebUI, TR069 with TR-098, CLI via UART/SSH, easily extensible

Support single and multi-core CPU architectures

  • No component level code change needed to repartition  software
  • D-Bus extends common architecture across CPUs

Easily portable to support multiple SoC vendors 

  • Supported through component level  abstraction layers
  • Leverages the ability to re partition  across single core, multi-core and multi-CPU
  • Tested on multiple platforms


RDKB is architected with “Software Components. It supports pluggable component modules which communicate over the CCSP message bus. The architecture is structured into  two layers:

  • CCSP Services Layer
  • Core Device Platform

The CCSP components in the CCSP Services Layer communicate among each other via the CCSP internal message bus. The CCSP message bus is based on DBus.

The Core Device Platform includes the Linux OS libraries, Free and Open Source Software (FOSS) and drivers accessible via Hardware Abstraction Layers (HAL).

To know more about CCSP architecture please go to CCSP High Level Architecture.



  • No labels