Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

Gliffy Diagram
macroIdad388365-ec47-44d8-a8bd-2a909d92a91c
nameRFC-working
pagePin1
Image Removed

  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.

...