---
## 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.
| Component | Description |
| --------------------------- | --------------------------|
| **Component Registry** | Central registry where components announce their presence and capabilities at startup. Maintains a mapping of TR-181 namespaces to component names (e.g., `Device.WiFi.*` → `OneWifi`), performs health monitoring through periodic heartbeat checks, provides discovery services for components to locate each other without hardcoded dependencies, and supports namespace conflict resolution when multiple components claim the same parameters. |
| **CcspPandM** | Manages device-level provisioning and parameter management, including first-boot configuration, factory reset handling, and TR-181 namespaces such as `Device.DeviceInfo.*`, `Device.Time.*`, and `Device.UserInterface.*`. Acts as the TR-181 gateway, receiving requests from XCONF or WebPA agents and routing them to the appropriate components via Component Registry lookups. |
| **CcspPsm** | Persistent Storage Manager providing database services (XML or SQLite) for parameter storage, with in-memory caching for fast access. Handles configuration persistence across reboots, backup and restore operations, and transactional support for atomic multi-parameter updates. |
| **CcspCommonLibrary** | Shared library suite that simplifies IPC operations with wrapper functions, provides a data model framework with TR-181 type conversions, offers component infrastructure for registration and message handling, and supplies utility functions for logging, memory management, and string operations. |
| **CcspEthAgent** | Manages Ethernet wired networking operations including physical port configuration, link state management, and statistics collection. Monitors interface status, tracks traffic metrics, and configures port-level parameters such as duplex mode and speed. |
| **CcspCMAgent** | Interfaces with cable modem hardware to monitor DOCSIS WAN connectivity and provide modem diagnostics. Tracks signal quality metrics, channel bonding status, downstream/upstream channel details, and modem operational state. |
| **CcspLMLite** | Discovers and tracks LAN-connected devices through active monitoring of ARP tables and DHCP lease information. Maintains a real-time inventory of connected hosts including MAC addresses, IP addresses, hostnames, and connection timestamps. |
| **CcspDmCli** | Command-line utility for TR-181 operations, enabling parameter get/set, table operations, component discovery, and runtime debugging during development. |
| **RDK WAN Manager** | Central orchestrator for WAN connectivity, managing multiple interface types (Ethernet, DOCSIS, DSL, GPON, LTE, PPPoE) with multi-WAN support. Implements automatic failover using ping/HTTP/DNS health checks, load balancing across connections, and policy-based routing for application-aware traffic decisions. |
| **RDK VLAN Bridge Manager** | Configures VLANs and bridges for service segmentation across IPTV, VoIP, data, guest networks, and IoT. Supports 802.1Q tagging, QinQ nested VLANs, dynamic VLAN creation, and service-to-VLAN mapping. |
| **OneWiFi** | Unified Wi-Fi management component replacing CcspWiFiAgent, CcspHotspot, and vendor-specific Wi-Fi managers. Manages all radios and SSIDs from a single process with Wi-Fi 6/6E support (OFDMA, TWT, BSS coloring, WPA3), client steering across 2.4 GHz/5 GHz/6 GHz bands, and mesh networking capabilities. |
| **RDK GPON Manager** | Controls GPON/EPON optical interfaces for fiber broadband deployments. Manages ONU/ONT operations including optical signal monitoring, ranging, registration, power control, OMCI protocol handling, and service provisioning from the OLT. |
| **RDK PPP Manager** | Establishes PPPoE/PPPoA connections with PAP/CHAP/MS-CHAP authentication, dynamic IP and DNS configuration, automatic reconnection on failure, and support for VLAN-tagged sessions. |
| **RDK Telco Voice Manager** | Manages VoIP services including SIP registration, codec handling (G.711, G.729, G.722), call features (call waiting, forwarding, caller ID), RTP/SRTP media with QoS enforcement, and FXS/FXO port control. |
| **RDK Cellular Manager** | Controls LTE/5G modems for cellular WAN connectivity. Handles modem power and firmware management, SIM operations (PIN/PUK, eSIM), network registration (2G/3G/LTE/5G), PDP context activation, and data usage tracking.|
---
## 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:
```mermaid
%%{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
```mermaid
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
```mermaid
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
```mermaid
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.
---
|
