Introduction<\/span><\/h2>\n\n\nRemote Feature Control (RFC) refers to a specific framework and mechanism incorporated within RDK middleware to enable the remote management and control of features in RDK-based Customer Premise Equipment (CPE)<\/span><\/span> platforms. <\/span><\/span>It allows operators or service providers to remotely enable, disable, configure, or update specific functionalities without physically accessing each device. RFC provides a standardized method for managing features, reducing operational overhead and enabling selective feature deployments<\/span><\/span>.<\/span><\/p>\nBefore RFC, disabling and enabling a feature in the field required rolling back to older firmware, resulting in operational challenges. There was no option to selectively deploy features to a subset of devices or dynamically configure devices. This lack of flexibility limited the efficiency of feature rollouts and customization in RDK-based CPE platforms.
<\/span><\/span><\/p>\nRFC offers several benefits for managing features in RDK-based CPE platforms:<\/span><\/p>\n\n- It provides a solution by enabling quicker feature rollouts. <\/span><\/li>\n
- Establishing<\/span> a secure channel for delivering runtime configurations. <\/span><\/li>\n
- Allows<\/span> control over feature enablement\/disabling at runtime or during reboot. <\/span><\/li>\n<\/ul>\n
RFC works in conjunction with XConf, which serves as a central repository for configurations and feature flags. XConf stores the settings and feature data, while RFC facilitates communication and feature control between RDK-based CPE platforms and XConf. This integration ensures a seamless flow of configurations, enabling remote management and control of features.<\/span><\/p>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n
<\/div>\n<\/div>\n<\/div>\n\n\n\n\n\nArchitecture<\/h2>\n\n\nRFC Mechanism<\/h3>\n\n<\/div>\n![\"RFC_drawio\"](\"https:\/\/developer.rdkcentral.com\/documentation\/wp-content\/uploads\/sites\/16\/2024\/10\/RFC_drawio.png\" "\\"RFC_drawio\\"")
<\/div>\n<\/div>\nThis approach breaks down the RFC control flow into segments that have specific responsibilities, <\/span>in accordance with<\/span> their component design.<\/span><\/p>\n\n- Rules Engine – a passive platform that responds to a specific request, running a defined set of rules against the incoming set of parameters, and<\/span> <\/span>providing generic data results based on the application of the rules.<\/span><\/li>\n
- Transport – provides the conduct of signaling and data parameters from client to cloud and back.<\/span><\/li>\n
- Execution – application of the RFC parameters on the client.<\/span><\/li>\n<\/ul>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n
RFC Control Flow<\/span><\/span><\/h3>\nAn 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 an HTTP GET sent directly from the client to Device Configuration Manager (DCM), the<\/span><\/span> 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.<\/span><\/p>\n<\/div>\n<\/div>\n<\/div>\n\n\n\nKey aspects of the client RFC processing<\/span><\/h3>\n\n- \n
HTTP GET to XConf\/DCM requesting RFC settings<\/span><\/p>\n<\/li>\n- \n
Response from DCM is parsed and the configuration data <\/span>extracted<\/span><\/p>\n\n- \n
includes “<\/span><\/span>featureControl<\/span><\/span>” data block<\/span><\/span><\/p>\n<\/li>\n- \n
looks for <\/span><\/span>“<\/span><\/span>effectiveImmediate<\/span><\/span>“<\/span><\/span> flag, evaluates if a change in the corresponding enable state, triggers reboot<\/span><\/span><\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
The JSON config data supports 2 modes for the client control: Environment Variable, or TR-181 data parameters<\/span><\/p>\n<\/li>\n- \n
At feature startup, the feature modules will check the Environment Variable or the TR-181 parameter to determine the enable\/disable state.<\/span><\/p>\n<\/li>\n- \n
Example-“Device.DeviceInfo.X_RDKCENTRAL-COM_RFC.Feature.FireboltRefUI.Enable” to determine the enable\/disable state of the Ripple feature.<\/span><\/p>\n<\/li>\n<\/ul>\n<\/div>\n<\/div>\n<\/div>\n\n\n\nSteps of the RFC Process<\/span><\/h3>\n<\/span><\/p>\n\n<\/div>\n![\"RFC-working_drawio\"](\"https:\/\/developer.rdkcentral.com\/documentation\/wp-content\/uploads\/sites\/16\/2024\/10\/RFC-working_drawio.png\" "\\"RFC-working_drawio\\"")
<\/div>\n<\/div>\nThe RFC process is controlled through the rfc-config service. RFCBase.sh communicates with the XConf server to fetch predefined feature data.
<\/p>\n
On the device side, RFCBase.sh parses the feature control JSON messages and creates system-level and individual configuration files with the key and values. RDK modules then pick the environment variables using the RFC API or the script to toggle the relevant feature.<\/p>\n<\/div>\n<\/div>\n<\/div>\n
\n\n\nUse cases<\/span><\/h3>\nThe primary use case for RFC is to enable or disable a specific set-top feature, providing remote control capabilities to support a progressive rollout or rollback of features. In this example, we will focus on the TR-181 parameter “Device.DeviceInfo.X_RDKCENTRAL-COM_RFC.Feature.FireboltRefUI.Enable” to enable or disable the Ripple feature within the FireboltRefUI. Enabling the Ripple feature enhances the user interface by adding interactive and visually appealing elements. It introduces fluid animations, smooth transitions, and visual effects that respond to user interactions, making the interface more intuitive and engaging.<\/p>\n
If the “Device.DeviceInfo.X_RDKCENTRAL-COM_RFC.Feature.FireboltRefUI.Enable” parameter is set to “true”, the system agent can initiate the necessary processes or components to enable the Ripple feature within the FireboltRefUI. On the other hand, if the parameter is set to “false”, the system agent can disable the Ripple feature.<\/p>\n\n
\nExample<\/b><\/div>\n\nTo enable the Ripple feature, you can use the following command: \ntr181 -s -t boolean -v true Device.DeviceInfo.X_RDKCENTRAL-COM_RFC.Feature.FireboltRefUI.Enable \n\nTo disable the Ripple feature, you can use the following command: \n tr181 -s -t boolean -v false Device.DeviceInfo.X_RDKCENTRAL-COM_RFC.Feature.FireboltRefUI.Enable <\/pre>\n<\/div>\n<\/div>\nBy utilizing these tr181 commands, you can easily control the enablement or disablement of the Ripple feature within the FireboltRefUI, allowing for flexible and dynamic management of set-top features.
Note: To enable this change on the fly, the “effectiveImmediate” flag should be set to true; by default, this flag is set to false.<\/p>\n<\/div>\n<\/div>\n<\/div>\n
\n\n\n
<\/div>\n<\/div>\n<\/div>\n\n\n\n\n\nConfiguration Details<\/span><\/h2>\n\n\nRFC-Related Files and their Descriptions<\/span><\/span><\/span><\/h3>\n\n\n\nOutput file<\/span><\/th> Description<\/span><\/th><\/tr>\/tmp\/rfc-parsed.txt<\/span><\/td> If validation is success, contains parsed feature control data<\/span><\/td><\/tr>$PERSISTENT_PATH\/rfcVariable.ini<\/span><\/td> Aggregated configuration variables of al features<\/span><\/td><\/tr>$PERSISTENT_PATH\/.RFC_<FEATURENAME>.ini<\/span><\/td> If validation is success, contains feature specific configured parameters<\/span><\/td><\/tr>\/opt\/logs\/rfcscript.log<\/span><\/td> Contains feature control logs<\/span><\/td><\/tr>\/etc\/rfcdefaults\/rfcdefaults.ini<\/span><\/span><\/td> It mentions default rfc values<\/span><\/span><\/td><\/tr><\/tbody><\/table>\n\n\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n\n\nSupported RFC Features
<\/span><\/h3>\n
Before RFC, disabling and enabling a feature in the field required rolling back to older firmware, resulting in operational challenges. There was no option to selectively deploy features to a subset of devices or dynamically configure devices. This lack of flexibility limited the efficiency of feature rollouts and customization in RDK-based CPE platforms. RFC offers several benefits for managing features in RDK-based CPE platforms:<\/span><\/p>\n RFC works in conjunction with XConf, which serves as a central repository for configurations and feature flags. XConf stores the settings and feature data, while RFC facilitates communication and feature control between RDK-based CPE platforms and XConf. This integration ensures a seamless flow of configurations, enabling remote management and control of features.<\/span><\/p>\n<\/div>\n<\/div>\n<\/div>\n This approach breaks down the RFC control flow into segments that have specific responsibilities, <\/span>in accordance with<\/span> their component design.<\/span><\/p>\n 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 an HTTP GET sent directly from the client to Device Configuration Manager (DCM), the<\/span><\/span> 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.<\/span><\/p>\n<\/div>\n<\/div>\n<\/div>\n HTTP GET to XConf\/DCM requesting RFC settings<\/span><\/p>\n<\/li>\n Response from DCM is parsed and the configuration data <\/span>extracted<\/span><\/p>\n includes “<\/span><\/span>featureControl<\/span><\/span>” data block<\/span><\/span><\/p>\n<\/li>\n looks for <\/span><\/span>“<\/span><\/span>effectiveImmediate<\/span><\/span>“<\/span><\/span> flag, evaluates if a change in the corresponding enable state, triggers reboot<\/span><\/span><\/p>\n<\/li>\n<\/ul>\n<\/li>\n The JSON config data supports 2 modes for the client control: Environment Variable, or TR-181 data parameters<\/span><\/p>\n<\/li>\n At feature startup, the feature modules will check the Environment Variable or the TR-181 parameter to determine the enable\/disable state.<\/span><\/p>\n<\/li>\n Example-“Device.DeviceInfo.X_RDKCENTRAL-COM_RFC.Feature.FireboltRefUI.Enable” to determine the enable\/disable state of the Ripple feature.<\/span><\/p>\n<\/li>\n<\/ul>\n<\/div>\n<\/div>\n<\/div>\n <\/span><\/p>\n The RFC process is controlled through the rfc-config service. RFCBase.sh communicates with the XConf server to fetch predefined feature data. On the device side, RFCBase.sh parses the feature control JSON messages and creates system-level and individual configuration files with the key and values. RDK modules then pick the environment variables using the RFC API or the script to toggle the relevant feature.<\/p>\n<\/div>\n<\/div>\n<\/div>\n The primary use case for RFC is to enable or disable a specific set-top feature, providing remote control capabilities to support a progressive rollout or rollback of features. In this example, we will focus on the TR-181 parameter “Device.DeviceInfo.X_RDKCENTRAL-COM_RFC.Feature.FireboltRefUI.Enable” to enable or disable the Ripple feature within the FireboltRefUI. Enabling the Ripple feature enhances the user interface by adding interactive and visually appealing elements. It introduces fluid animations, smooth transitions, and visual effects that respond to user interactions, making the interface more intuitive and engaging.<\/p>\n If the “Device.DeviceInfo.X_RDKCENTRAL-COM_RFC.Feature.FireboltRefUI.Enable” parameter is set to “true”, the system agent can initiate the necessary processes or components to enable the Ripple feature within the FireboltRefUI. On the other hand, if the parameter is set to “false”, the system agent can disable the Ripple feature.<\/p>\n\n By utilizing these tr181 commands, you can easily control the enablement or disablement of the Ripple feature within the FireboltRefUI, allowing for flexible and dynamic management of set-top features.
<\/span><\/span><\/p>\n\n
<\/div>\n<\/div>\n<\/div>\nArchitecture<\/h2>\n\n\n
RFC Mechanism<\/h3>\n
<\/div>\n<\/div>\n\n
RFC Control Flow<\/span><\/span><\/h3>\n
Key aspects of the client RFC processing<\/span><\/h3>\n
\n
\n
Steps of the RFC Process<\/span><\/h3>\n
<\/div>\n<\/div>\n
<\/p>\nUse cases<\/span><\/h3>\n
To enable the Ripple feature, you can use the following command: \ntr181 -s -t boolean -v true Device.DeviceInfo.X_RDKCENTRAL-COM_RFC.Feature.FireboltRefUI.Enable \n\nTo disable the Ripple feature, you can use the following command: \n tr181 -s -t boolean -v false Device.DeviceInfo.X_RDKCENTRAL-COM_RFC.Feature.FireboltRefUI.Enable <\/pre>\n<\/div>\n<\/div>\n
Note: To enable this change on the fly, the “effectiveImmediate” flag should be set to true; by default, this flag is set to false.<\/p>\n<\/div>\n<\/div>\n<\/div>\n
<\/div>\n<\/div>\n<\/div>\nConfiguration Details<\/span><\/h2>\n\n\n
RFC-Related Files and their Descriptions<\/span><\/span><\/span><\/h3>\n
Output file<\/span><\/th> Description<\/span><\/th><\/tr> \/tmp\/rfc-parsed.txt<\/span><\/td> If validation is success, contains parsed feature control data<\/span><\/td><\/tr> $PERSISTENT_PATH\/rfcVariable.ini<\/span><\/td> Aggregated configuration variables of al features<\/span><\/td><\/tr> $PERSISTENT_PATH\/.RFC_<FEATURENAME>.ini<\/span><\/td> If validation is success, contains feature specific configured parameters<\/span><\/td><\/tr> \/opt\/logs\/rfcscript.log<\/span><\/td> Contains feature control logs<\/span><\/td><\/tr> \/etc\/rfcdefaults\/rfcdefaults.ini<\/span><\/span><\/td> It mentions default rfc values<\/span><\/span><\/td><\/tr><\/tbody><\/table>\n\n\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n Supported RFC Features
<\/span><\/h3>\n