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.

• 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.

CCSP High Level Architecture

Introduction

This document provides a high level view of how CCSP components communicate with each other and fit together to form larger device profiles. It provides overview information on the CCSP Message Bus and CCSP Component Registry and other core infrastructural framework components.

CCSP High Level Architecture Overview

CCSP High Level Architecture

Above figure illustrates the core building blocks of the CCSP Platform at a high level along with the IPC mechanism used to communicate with each other. These core components are explained in later sections.

The architecture is structured into two layers:

1. CCSP Services Layer
2. 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 D-Bus.

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

CCSP components in the CCSP Services Layer call into OS primitives via POSIX interfaces. Since the CCSP platform is implemented and optimized for Linux OS, there is no need for an additional RTOS abstraction Layer. The necessary abstraction is provided by POSIX.

Below figure illustrates various components of the RDKB stack.

RDKB Component Diagram

CCSP Component Model  defines the Component model used in CCSP Framework and lays the foundation of what a component is. CCSP Framework takes a deep dive into defining each of the architectural elements shown in Figure-1

CCSP Component Model

A CCSP component is one or more run-time processes, which consist of a reusable set of software to provide a defined set of service(s). A CCSP component can send and/or receive and handle requests via the CCSP Message Bus. All CCSP components extend from a Base CCSP Component that defines the core methods common to all CCSP components.

For performance optimization, more than one CCSP components can combine into a single run time process or decoupled into individual processes, without requiring any software change to the component. Having this capability allows each Component to be instantiated and work in its own process during testing and verification but later combined with other components into a single process (for performance optimization) in production environments. It also aids in resolving and isolating issues such as crashes, memory clobbers etc.

Component Interfaces

All components implement the base component interface as described in CCSP Base Component Interfaces.

The base interface defines core APIs that are common to all CCSP components. In addition each component provides well defined and abstracted APIs to expose component specific functionality based on the guidelines