Architecture:

RDK-B follows a layered architecture comprising Application, Middleware, and Hardware Abstraction Layer (HAL), which separates application logic from hardware-specific implementation. This design makes RDK-B WAN-agnostic, supporting multiple access technologies such as DOCSIS, DSL, GPON, and LTE. The middleware itself is built as a collection of independent, componentized services, each handling a specific functional domain like Wi-Fi, WAN, or Voice. Components can be selectively included, added, removed, or replaced based on target device requirements without affecting unrelated functionality.

In RDK-B, cross-layer dependencies are minimized through well-defined interfaces and standardized data models that govern communication between components. Standardized managers and HAL interfaces allow the same core middleware stack to operate consistently across different hardware platforms, ensuring portability. This loosely coupled, modular design simplifies platform-specific customization and supports long-term extensibility — enabling tailored builds for devices with varying capabilities without requiring architectural changes.

Device Layers

RDK-B organizes components based on functionality and level of abstraction, with each group having clearly defined responsibilities. Within the middleware layer, components are largely independent and communicate with each other using IPC mechanisms, enabling modularity and selective inclusion based on device requirements. Hardware access is performed through HAL interfaces, with platform-specific implementations translating these interactions to the underlying system.

Application Layer

The Application Layer hosts various caterogies of applications including

• web-based applications for device configuration & monitoring( the web UI of gateway devices )
• operator applications for network management, diagnostics, and CPE provisioning, and
• third-party applications extending functionality with parental controls, security services, and smart home integration.

Middleware Layer

The RDK-B Middleware is composed of independent, domain-specific components that communicate through well-defined interfaces. Several of these components implement the TR-181 data model standard for consistent parameter representation and remote manageability. Key components include:

• RDK WAN Manager — Orchestrates WAN connectivity across Ethernet, DOCSIS, GPON, and LTE interfaces, with support for automatic failover, load balancing, and policy-based routing.
• CCSP PSM (Persistent Storage Manager) — Provides parameter storage with in-memory caching and transactional support for atomic updates that persist across reboots.
• Utopia — Delivers core system infrastructure including configuration management (syscfg), event messaging (sysevent), and network service orchestration for DHCP, firewall, routing, and VLAN.
• OneWifi — Offers unified Wi-Fi management for radios and Virtual Access Points, supporting Wi-Fi 6/6E/7, EasyMesh, and client steering capabilities.
• RBUS — Provides high-performance inter-process communication using a binary protocol with event-driven notifications and a hierarchical data model.

Hardware Abstraction Layer (HAL)

The HAL defines standardized, vendor-neutral interfaces that decouple the middleware from underlying hardware, enabling portability across diverse chipsets and platforms. Defined HAL interfaces — including Wi-Fi, Ethernet, DHCP V4/V6, Platform, Cellular, and VLAN — allow operators to source hardware competitively without impacting middleware functionality. Certain capabilities such as MAP-T support, 6 GHz operation, and multicast handling remain dependent on the specific chipset and vendor implementation beneath the HAL.

Platform Layer

The Platform Layer provides the foundational system software on which all upper layers depend. The Linux kernel incorporates network drivers (Wi-Fi, Ethernet, cellular), USB and flash storage drivers (MTD, UBI), and cryptographic accelerators. Bootloaders — typically U-Boot or vendor-specific alternatives — handle hardware initialization, kernel and device tree loading, and secure boot verification. Vendor libraries supply SoC-specific acceleration for video codec and cryptographic operations, along with Wi-Fi drivers (proprietary or open-source)

Architectural Deep dive

The following diagram provides a detailed view of the RDK Connectivity architecture, showing all components and their relationships:

RDKB Components

CCSP Architecture

CCSP (Common Component Software Platform) is the original framework developed as part of the RDK-B initiative to provide a standardized, component-based approach to implementing broadband device functionality. The CCSP framework relies on several foundational infrastructure services — including a component registry for discovery, persistent storage for parameter management, shared libraries for IPC and data model handling, and a device-level provisioning gateway — which collectively support the operation of functional components implementing specific domains such as Wi-Fi, Ethernet, cable modem, and network management.

Architectural Evolution

Apart from the CCSP components, a set of next-generation middleware components have been developed with a focus on improved performance and simplified design. These modern components provide direct HAL access to reduce abstraction layers between the component and hardware, asynchronous non-blocking I/O to prevent processing stalls, and efficient memory utilization through shared libraries instead of separate processes where appropriate.

The modern architecture emphasizes simplicity — through component consolidation, cleaner C++ interfaces with reduced boilerplate, improved documentation, and simplified code paths for easier debugging. It also emphasizes modularity — through a plugin architecture for feature extensibility, runtime configuration to enable or disable features without recompilation, clear dependency management, and backward-compatible versioning.

These components are progressively replacing their CCSP counterparts in an ongoing transition, with both architectures coexisting in current deployments.

Component Reference

The table below provides a consolidated view of all major RDK-B middleware components, encompassing both legacy CCSP components and their modern replacements.

Inter-Process Communication (IPC)

RDK-B uses RBUS as the RDK IPC mechanism. RBUS was developed to address performance and complexity issues of D-Bus, and is progressively replacing it as components transition from CCSP to the modern architecture. During this transition, both mechanisms coexist to maintain compatibility.

RBUS uses a three-layer architecture: the RBUS API Layer provides TR-181-aligned APIs for properties, methods, events, and table operations; the RBUS-Core Layer handles RPC, event publish/subscribe, registration, and discovery; and the rtMessage Layer provides lightweight binary protocol over Unix domain sockets or TCP.

The protocol uses direct point-to-point communication with binary protocol, enabling faster operations compared to legacy mechanisms. RBUS provides event-driven communication where value change notifications automatically update subscribers when parameters change, eliminating polling. Wildcard subscriptions support patterns ("Device.Wi-Fi.Radio.*.Enable") and namespace matching ("Device.Wi-Fi.**"), with event filtering to deliver only events matching specified criteria.

TR-181 Data Model Integration

RDK-B uses TR-181 as the common data model across all management protocols and interfaces, providing vendor interoperability through consistent parameter naming and enabling operational efficiency with common tools across device fleets.

Structure:

• Objects: Containers grouping related parameters (Device.Wi-Fi., Device.Wi-Fi.Radio.{i}.)
• Parameters: Individual data values with types (Device.Wi-Fi.Radio.1.Channel as int, Device.Wi-Fi.Radio.1.Enable as boolean)
• Multi-instance Objects: Tables denoted by {i} with numbered instances (Device.Wi-Fi.SSID.{i}. → Device.Wi-Fi.SSID.1., Device.Wi-Fi.SSID.2.)
• Commands: Executable operations (Device.Wi-Fi.Radio.1.Reset(), Device.Reboot())

Component Ownership in RDK-B:

• CcspPandM: Device.DeviceInfo., Device.Time., Device.UserInterface., Device.Users.
• OneWi-Fi: Device.Wi-Fi.*
• CcspEthAgent: Device.Ethernet.*
• RDK WAN Manager: Device.X_RDK_WanManager.*, coordinates WAN interfaces
• RDK VLAN Bridge Manager: Device.X_RDK_Vlan.*
• RDK GPON Manager: Device.X_RDK_PON.*
• RDK Cellular Manager: Device.Cellular.*

TR-181 Request Flow

The following diagram illustrates a typical TR-181 request flow using an Ethernet port configuration example:

%%{init: { "config": { "useMaxWidth": false } }}%%
sequenceDiagram
    participant Cloud as Cloud ACS
    participant Agent as Protocol Agent
    participant Registry as Component Registry/RBUS
    participant Component as CcspEthAgent
    participant HAL as Ethernet HAL
    participant HW as Hardware
    participant PSM

    Cloud->>Agent: SetParameterValues<br/>Device.Ethernet.Interface.1.Enable=true
    Agent->>Agent: Validate auth/authz
    Agent->>Registry: Lookup component for<br/>Device.Ethernet.Interface.1.Enable
    Registry-->>Agent: CcspEthAgent
    Agent->>Component: IPC request
    Component->>Component: Validate value<br/>Check interface state
    Component->>HAL: HAL API for platform operation
    HAL->>HW: Vendor-specific commands
    HW-->>HAL: Success
    HAL-->>Component: Return 0
    Component->>PSM: Persist value
    Component->>Registry: Publish value change event
    Component-->>Agent: Success response
    Agent->>Cloud: 200 OK

Flow Steps:

1. Request Initiation: Cloud sends device management requests via TR‑369 (USP over MQTT/WebSocket) and WebPA (REST over HTTPS).
2. Protocol Agent: Receives request, validates authentication and authorization, extracts parameter path and value
3. Namespace Resolution: For CCSP, Component Registry queries component ownership; RBUS has built-in discovery
4. IPC Communication: Marshal parameter and value, route to owning component via IPC
5. Component Processing: Validate input against state and regulatory rules, prepare HAL call
6. HAL Invocation: Execute standardized vendor-neutral API, translate to chipset-specific commands
7. Hardware Execution: Driver sends commands to chip, firmware executes changes
8. Response: Component receives HAL confirmation, updates state, publishes event, persists via PSM, returns success to agent, agent confirms to cloud

Component Interactions

RDK-B components interact using patterns that balance performance, maintainability, and system complexity. Three primary patterns govern component communication.

Request-Response Pattern

sequenceDiagram
    participant App as Application
    participant MW as Middleware
    participant HAL
    participant HW as Hardware

    App->>MW: Get/Set Parameter
    MW->>MW: Validate input<br/>Check state
    MW->>HAL: HAL API call
    HAL->>HW: Vendor command
    HW-->>HAL: Response
    HAL-->>MW: Return value
    MW-->>App: Success/Failure

Synchronous, top-down pattern for simple get/set operations. Requests flow from application through middleware (business logic, validation) to HAL (hardware abstraction) to platform (vendor implementation). Caller blocks waiting for response.

Use Cases: Configuration queries, single parameter updates, status reads that complete in <100ms

Event-Driven Pattern

sequenceDiagram
    participant HW as Hardware
    participant HAL
    participant Pub as Publisher
    participant Bus as RBUS
    participant Sub1 as Subscriber 1<br/>(Telemetry)
    participant Sub2 as Subscriber 2<br/>(WAN Mgr)
    participant Sub3 as Subscriber 3<br/>(Analytics)

    HW->>HAL: Interrupt/Event
    HAL->>Pub: Callback notification
    Pub->>Bus: Publish event
    Bus->>Sub1: Event delivery
    Bus->>Sub2: Event delivery
    Bus->>Sub3: Event delivery
    Note over Sub1,Sub3: Process independently<br/>and asynchronously

Asynchronous publish/subscribe pattern where producers publish events and multiple consumers react independently. Hardware events flow from driver through HAL to middleware, which publishes RBUS events received by subscribers (Telemetry, WAN Manager, Analytics).

Use Cases: Wi-Fi client association/disassociation, WAN link up/down events, DHCP lease changes, system alarms, real-time telemetry

Practical Use Case

WAN Interface Failover

sequenceDiagram
    participant CM as CcspCMAgent
    participant WAN as RDK WAN Manager
    participant Cell as RDK Cellular Manager
    participant Net as Network<br/>(routing/NAT)
    participant Cloud

    Note over CM: DOCSIS link down detected
    CM->>WAN: RBUS event: DOCSISStatus=Down
    WAN->>WAN: Check WAN policy<br/>Cable Pri=1, Cellular Pri=2
    WAN->>WAN: Validate cellular backup<br/>SIM valid, signal OK
    WAN->>Cell: Activate cellular interface
    Note over Cell: Modem power-on: 1-2s<br/>Network registration: 2-5s<br/>PDP context: 1-3s
    Cell->>Cell: Configure wwan0 interface
    Cell->>WAN: RBUS event: Cellular Up
    WAN->>Net: Update default route to wwan0
    WAN->>Net: Update NAT/firewall for wwan0
    WAN->>Net: Configure DNS to cellular servers
    WAN->>WAN: Verify connectivity<br/>ping, DNS, HTTP
    WAN->>WAN: Update TR-181 parameters
    WAN->>Cloud: Publish failover event
    Note over CM,Cloud: Total failover: ~12 seconds
    loop Monitor Primary
        WAN->>CM: Check DOCSIS status every 10s
    end
    Note over WAN: When cable recovers,<br/>wait 60s stability,<br/>then failback

When a primary DOCSIS connection fails, the RDK-B gateway automatically switches to LTE backup. CcspCMAgent detects DOCSIS link down within 2 seconds and publishes RBUS event (Device.X_CISCO_COM_CableModem.DOCSISStatus = "Down"). RDK WAN Manager receives the event, retrieves WAN policy from PSM (Cable Priority 1, Cellular Priority 2 with AUTO failover), and validates cellular backup (SIM validity, signal strength, regulatory status, data plan).

WAN Manager invokes RDK Cellular Manager via RBUS to activate cellular. Cellular Manager powers on modem (1-2s), performs network registration with LTE band scanning (2-5s), and establishes PDP context with carrier gateway (1-3s), totaling 4-10 seconds. After receiving IP configuration (carrier-grade NAT IP, gateway, DNS, MTU), Cellular Manager configures wwan0 interface and publishes "Cellular Up" event.

WAN Manager reconfigures the system: updates routing (default route to wwan0), updates NAT/firewall rules (MASQUERADE for wwan0), and configures DNS forwarder for cellular servers. After connectivity verification (ping, DNS, HTTP), WAN Manager updates TR-181 parameters, persists configuration via PSM, and publishes failover events to cloud for monitoring. Total failover time: ~12 seconds.

WAN Manager monitors primary cable every 10 seconds. On recovery, it verifies 60-second stability before automatic failback to the preferred lower-cost, higher-speed cable connection.