RDK Resources
[*RDK Preferred*]
Code Management Facility
RDK Forums
[RDK Conferences]
RDK Support
Archives
Papers & Presentations Archive
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).
...
Traditional code download were using eCM interface which had some limitations like URL resolution not supported. XCONF way of code download allows Code download from the Embedded STB (eSTB) interface and provides set-top with
draw.io Diagram | ||||
---|---|---|---|---|
|
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 download code from server.
...
The following table lists some of the parameters which may be sent.
Name | Example value | Description |
---|---|---|
capabilities | rebootDecoupled , downloadScheduled , etc | 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 |
env | PROD | VBN | QA | DEV | The environment this box is sitting in. |
eStbMac | ab:e7:55:4d:cc:95 | MAC address of the STB. |
firmwareVersion | abcd | STB current firmware version. |
ipAddress | For testing only. Overrides the source ip address of the HTTP request. | |
logLevel | FATAL | ERROR | WARNING | INFO | The STB is echoing back a command it received from another path, such as SNMP or local control. A customer assistance engineer needs more diagnostic detail from this box's log files. Xconf Server should set the logLevel parameter of the JSON response with this value, regardless of the configuration returned from the data store. |
logLevelDuration | 0 0 0/1 1/1 * ? * | The STB is echoing back a command it received from another path, such as SNMP or local control. A customer assistance engineer needs more diagnostic detail from this box's log files. Xconf Server should set the logLevelDuration parameter of the JSON response with this value, regardless of the configuration returned from the data store. |
mocaMac | MAC Address of the MoCA interface; currently ignored by xconf | |
model | abcd | STB model. |
proxy | true | Inidcates that this request is coming from another service on behalf of a STB. The STB is identified by the eStbMac and the ipAddress (required in this case). Xconf Server should send a series of SNMP set requests indicating the firmwareVersion, firmwareFilename, firmwareLocation. XPM already does this, so use those SNMP MIBS. |
rebootImmediately | true|false | |
timeZoneOffset | -04:00 | Offset from UTC time. See http://joda-time.sourceforge.net/timezones.html If time parameter is sent this offset is assumed to have already been applied. So "time" parameter is always wall clock time. If timeZoneOffset is not sent, it defaults to UTC and "time" parameter if sent will be assumed to be UTC time. |
uploadImmediately | true|false |
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.
Capability | Description |
---|---|
rebootDecoupled | lets Xconf know that reboot has been decoupled from firmware download. If not specified in the rebootImmediately response, the STB will still reboot immediately after firmware download. |
downloadScheduled | lets Xconf know that STB is able to schedule firmware download based on information received from Xconf. ?? do we still want this ?? |
RCDL | 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. |
supportsFullHttpUrl | lets Xconf know that the STB can accept a full URL specifier (http://hostname.com); initially, the STB only accepted a hostname and prepended the hostname with the protocol, then appended it with a port and resource path. Xconf should specify the entire URL |
...
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).
Service Name : /lib/systemd/system/swupdate.service
Helper Script : /lib/rdk/swupdate_utility.sh
Main Script : /lib/rdk/deviceInitiatedFWDnld.sh