RDK components can be used to create a standardized software stack for broadband gateways and routers providing common functionalities such as routing, WiFi, DNS, remote management, etc.

RDK for Broadband distinguishes itself

Silicon independence
Independent of the underlying platform/SoC
Kernel independence
Silicon vendors can provide their own version of optimized kernel
Hardware independence
Independent of the underlying hardware like WiFi, MoCA, Voice, etc
Supports multiple WAN types
OEMs can use their choice of WAN type
Open source
RDK for Broadband is licensed under Apache 2.0 license and is available free for licensees
Huge community user base
RDK for Broadband is used and supported by major MSOs , OEMs and SoC vendors across the globe
Vast device management capability
Supports a vast number of device management as well as proactive device monitoring options
Easy software deployments
Due to its modular nature, components can be added/removed easily to make different target builds
Software modularity
Each RDK for Broadband component is independent of each other so that teams can work independently
In-built test suite( TDK )
Provides its own in-house test setup – the TDK-B

RDK Device Structure

An RDK device mainly consists of 3 layers

SOC Layer :
This layer will contain the kernel optimized for the SoC platform , the patches for open-source components modified for the platform, the WAN/ MTA / MoCA stacks which are part of the platform, the drivers for hardware components , like WiFi chips, that are part of the stack etc
OEM Layer :
This layer will contain the bootloader, device security related changes, the MIBs and patches specific for the device for SoC, RDK components as well as the stack for WAN/ MTA/ MoCA and drivers for hardware all that are not part of the SoC platform
RDK Layer :
This layer has mainly two divisions
  • CCSP components – These are the core CCSP components
  • Open Source components – These are some core opensource networking related components that is used by RDK and are controlled by CCSP components
Head end
Open source
Open source
Drivers/ MTA/WAN
Open source
OEM patches

All the CCSP components communicate each other via a common message bus ( based on DBus ) using TR-181 data model format and hence are independent of each other( unless for some very core components ). The components interface with the hardware using either generic HAL calls or approved Linux system calls there by making the components independent of underlying platform. For the communication with management servers, the corresponding components acts as agents to convert the communications from headend to TR-181 format ( and the other way on their way back ) there by making the components independent of the protocol used by head end server.

The communication of a normal CCSP component will look like below

Go To Top