Page History

...

• Enables quicker roll out of features
• Enables a secure channel for delivering run-time configurations to the device
• Ability to control when the feature needs to be enabled/disabled ? Disable now/ Disable during reboot

Image RemovedImage Added

This approach breaks down the RFC control flow into segments that have specific responsibilities, in accordance with their component design.

...

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. 

How it works

Image Added

1. The RFC process is controlled through rfc-config service
2. RFCBase.sh communicates with xconf server and fetches the predefined feature data.
3. After parsing the feature control JSON messages, RFCBase.sh will create system level & individual configuration files with the key and values.
4. RDK modules pick the environment variables using RFC API or using the script and toggle the relevant feature.