RDK Resources
[*RDK Preferred*]
Code Management Facility
RDK Forums
[RDK Conferences]
RDK Support
Archives
Papers & Presentations Archive
Before RFC, the only way to disable a new feature in the field was to rollback to the older firmware. This led to a lot of operational overhead. Also there were lack of options to do a feature deployment in a subset of devices (for eg: only in 100 devices). Also there was lack of options to deliver dynamic configurations to the box Eg: Whitelist of SSH /SNMP servers, Details of downloadable modules..etc
...
An RFC transaction begins with the initiation event that causes the rules engine to evaluate a given rule set. In conjunction with the existing telemetry initialization, which is a HTTP GET sent directly from the client to DCM, the RFC request will be sent at a specific point in the client startup process. The response from XCONF/DCM will include the new JSON data structure that defines the feature control data for that specific client.
HTTP Get to XCONF/DCM requesting RFC settings
The primary use case for RFC is the enable/disable of a specific settop feature (e.g. XB Smart Cloud, or LSA on settops), providing a remote control capability to support a progressive roll-out of a feature, as well as roll-back of an already enabled feature. The execution layer supporting the enable/disable can take one of two forms: using a system agent to run a specific process in a linux/Yocto model directly (using systemd or the like), or to signal an existing process to control the behavior of feature specific processing. The Smart Cloud feature in RDKB is a stand-alone process, and the client-side processing of the enable flag in TR-181 will use systemd to start that process. Alternatively, the LSA feature is an extension of the RMF component, and therefore, doesn't fit the stand-alone process model, and so will use a feature-specific method for executing the enable function.
...