Overview

Device Management is an indispensable requirement to support large scale deployment. This helps in:

• Controlled bulk operations/data retrievals
• Firmware(code) download
• Dynamically enable/disable features
• Retrieving field matrices

Device Management feature is horizontally scaled between different RDK profiles (like RDK-V, RDK-B and RDK-C) as shown in the below diagram. This means that the same code can be shared between different RDK profiles.

Image Removed

Device Management features include:

1. Code Download (Xconf, DCM)
2. Log Upload
3. Telemetry
4. RDK Feature Control (RFC)
5. SNMP
6. TR-69
7. webPA

Code Download (Xconf, DCM)

XCONF/DCM is a management service that delivers certain configuration details to set-top-boxes (STB). Remote devices like set top boxes and DVRs have settings to control certain activities. For instance, STBs need to know when to upload log files, or when to check for a new firmware update. In order to remotely manage a large population of devices, we need a solution that lets support staff define instructions and get the instructions to the devices. These are Device Configuration Manager (DCM) and Xconf (X1 Configuration Manager). DCM and Xconf are management services that delivers certain configuration details to set-top-boxes (STB). 

Xconf (X1 Configuration Manager) and Device Configuration Manager (DCM) began as separate solutions. Both the server and STB implementations evolved separately. Yet , yet both have had overlapping functionality. RecentlyNow, engineers have made some progress in consolidating consolidated the server modules. But the STB modules remain discreet. And the server components still could benefit from more consolidation.

RDK Code Download (RCDL)

Image Removed

Server side (Business logic) identifies which version of code need to be provided for download. Xconf download is triggered by the device ie: device reaches out to server sending information like current firmware and capabilities. It asks for which firmware version to download and from where to download. RCDL (RDK Code Download or Remote Code Download) uses eSTB interface to downlaod code from server.

Xconf Code Download Highlights:

• Users can set download protocol
  • HTTP as preferred method
  • Provide HTTP and TFTP endpoints
  • Default to TFTP if no HTTP support
• Ability to publish capabilities from CPE device
  • rebootDecoupled (no need to reboot soon after firmware download. Reboot later or at a scheduled time)
  • supportsFullHttpUrl
• Ability to decouple downloads from reboot
• Ability to schedule firmware checks (During bootup/Later), Configurable based on timezones, quiet times
• Ability to redirect to secure download end points

Get Configuration

An STB makes an HTTP request to Xconf to get firmware information. The request may be an HTTP POST or GET. The response is a JSON string. An example GET for the production Xconf instance would look like this.

https://<xconf server url>/xconf/stb?eStbMac=14:D4:FE:55:86:0A&env=PROD&model=abcd&DRfirmwareVersion=abc123

The following table lists some of the parameters which may be sent. 

...

Specifies capabilities of the STB that Xconf needs to know about. See capabilities table below for details. This is a multi-valued parameter. More than one capability may be sent. Separate the values using url?capabilities=value1&capabilities=value2&capabilities=value3

...

mocaMac

...

...

MAC Address of the MoCA interface; currently ignored by xconf

...

Capabilities

The following table lists the different values for the capabilities parameter that may be send in request to Xconf. This is a multi-valued parameter. More than one capability may be sent.

 These capabilities should not live forever. Once all boxes are known to support a given capability, Xconf should deprecate/delete code that handles STBs that don't support the capability and STB should stop sending the capability value.

...

STB is capable of performing HTTP firmware downloads using DNS resolved URIs. The download will run in the eSTB. Until this, the eCM performed the download. eCM does not have DNS and thus requires an IP address.

...

The single name of the device configuration management service is XCONF. In the client side, the scripts and components are still named as DCM.

Device Management feature is horizontally scaled between different RDK profiles (like RDK-V, RDK-B and RDK-C) as shown in the below diagram. This means that the same code can be shared between different RDK profiles.

XCONF has client component ie CPE device component and server side component. XCONF's primary purpose is to tell STBs where to send their log files and what telemetry metrics they should be sending. XCONF does not receive logs or telemetry from the boxes. It simply tells the STB where to send log files or telemetry and what specific metrics it should be sending. XCONF also tells STBs when, where (host), and how (protocol) to send this data.

XCONF server consists of two web applications: the Data Service part and Angular-admin (UI). STBs query the XCONF Data Service to get their configuration details. Angular-admin (UI) allows administrators to create targeting rules and enter all the necessary configuration details for a rule.

The Xconf-Angular-Admin(UI) provides the web interface for the user. It lets the user define different types of Model, Environment, MAC Address, firmware configuration, Device setting configuration and telemetry rules. The rest controllers handle the request from UI and modify the data in Cassandra through dataservice. Xconf-dataservice is the main component of Xconf-OSS which communicates with the STB. The Firmware Configurations, Common data sets (MAC list, Model and Environment), telemetry profile, Download location, RFC and feature that are created, updated or deleted in Admin-UI is stored in cassandra. Dataservice is responsible to fetch the data from the Cassandra database and send it as a Response when a STB makes a request to Xconf-dataservice for the configuration. 

Device Management features (using XCONF) include:

1. Code Download (Xconf, DCM)
2. Log Upload
3. Telemetry
4. RDK Feature Control (RFC)
   
   

Device Management using WebPA is covered here:  WebPA

Returned JSON Firmware Information

Xconf returns firmware information as a JSON string as follows (just a sample).

{
"firmwareDownloadProtocol": "tftp",
"firmwareFilename": "<filename>sd-signed",
"firmwareLocation": "<ip_address>",
"firmwareVersion": "1.0.1.0.8",

"firmwareIDK": "[TBD]",

"firmwareDownloadSchedule": "[TBD]" 

"rebootImmediately":false,
}

Xconf should be able to add new values and STB should still be able to process the JSON string. STB should ignore any values it doesn't understand.

Error Handling

500 Internal Server Error

On server error STB may implement retry logic or not. Most 500 errors will be caused by bad requests, but some may be temporary conditions.

Timeout

If the request to Xconf times out, STB should implement retry logic.

404 / Empty JSON

There are times when Xconf does not wish to respond to the STB. In these cases it will send an HTTP 404 (not found) response and a prose text reason for why the response was not handled. The STB should ignore these responses (and not retry the request to Xconf).

RDK Telemetry

RDK Feature Control (RFC)

Boot/Startup

Logging

Log Upload

Memory Card Firmware upgrade

States and Diagnostics

Power State Management

SNMP

TR69 

WebPA

Device Management