Introduction

Remote 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) platforms. 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.

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:

• It provides a solution by enabling quicker feature rollouts. 
• Establishing a secure channel for delivering runtime configurations. 
• Allows control over feature enablement/disabling at runtime or during reboot. 

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.

Architecture

RFC Mechanism

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

• Rules Engine - a passive platform that responds to a specific request, running a defined set of rules against the incoming set of parameters, and providing generic data results based on the application of the rules.
• Transport - provides the conduct of signaling and data parameters from client to cloud and back.
• Execution - application of the RFC parameters on the client.

RFC Control Flow

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 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.

Key aspects of the client RFC processing

• HTTP GET to XConf/DCM requesting RFC settings

• Response from DCM is parsed and the configuration data extracted

  • includes "featureControl" data block

  • looks for "effectiveImmediate" flag, evaluates if a change in the corresponding enable state, triggers reboot

• The JSON config data supports 2 modes for the client control: Environment Variable, or TR-181 data parameters

• At feature startup, the feature modules will check the Environment Variable or the TR-181 parameter to determine the enable/disable state.

• Example-"Device.DeviceInfo.X_RDKCENTRAL-COM_RFC.Feature.FireboltRefUI.Enable" to determine the enable/disable state of the Ripple feature.

Steps of the RFC Process

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.

Use cases

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.

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.

To enable the Ripple feature, you can use the following command: 
tr181 -s -t boolean -v true Device.DeviceInfo.X_RDKCENTRAL-COM_RFC.Feature.FireboltRefUI.Enable 

To disable the Ripple feature, you can use the following command: 
 tr181 -s -t boolean -v false Device.DeviceInfo.X_RDKCENTRAL-COM_RFC.Feature.FireboltRefUI.Enable 

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.
Note: To enable this change on the fly, the "effectiveImmediate" flag should be set to true; by default, this flag is set to false.

Configuration Details

RFC-Related Files and their Descriptions

Supported RFC Features

Refer https://github.com/rdkcentral/tr69-datamodel/ data model xml data for supported RFC Features. This repository holds the generic data model defined by CPE WAN Management Protocol (CWMP).

RFC using Community XConf server

⁠To know how XConf configuration and feature validation are done please click here.