What is RFC?

RFC stands for RDK Feature Control.
It provides a mechanism to remotely enable, disable, or configure software features on RDK-based devices (CPEs).

RFC is primarily used by Release Management for controlled, staged rollouts of new features across production devices — ensuring stability and gradual deployment.

Source code

rdkcentral/rfc at main

How does RDK receive the RFC configuration?

The RFC configuration process involves multiple RDK components working together to fetch, process, and apply configuration updates.

The flow is summarized below:

1. Maintenance Manager

• Periodically evaluates when to start the RFC task.

• When conditions are met, it launches the RFC Manager to begin the configuration process.

2. RFC Manager → XConf

• RFC Manager sends an HTTP request to the configured XConf URL, including key device identifiers:

  • STB MAC Address

  • Account ID

  • Partner ID

  • Firmware Version

• XConf uses these identifiers to locate the appropriate configuration and returns it as a JSON payload.

3. Configuring the xconf server url

• Usually the xconf server url is read from rfc.properties file. Since this is a generic file, community xconf server url is not set from here.
• At startup (especially on first run or after device recovery), the code uses Device.DeviceInfo.X_RDKCENTRAL-COM_RFC.Bootstrap.XconfUrl to get the xconf url.
  • Bootstrap.XconfUrl is configured in tr69hostif/partners_defaults.json at main · rdkcentral/tr69hostif for specific partnerID.
    • If no partnerID is set, the value from "default_boot" is used.
    • If  partnerID is set, but not available in the partners_default.json, then "default" block is used.
    • If partnerID is set, and the corresponding partnerID is available in partners_default.json, then that partnerID block is used.
• For community devices, partnerID is set as "community" from sysint-hal repository. Example for RPI: 
  • rdkvhal-sysint-raspberrypi4/scripts/oem-first-boot.sh at main · rdkcentral/rdkvhal-sysint-raspberrypi4
• For Comcast devices, this is set from AuthService. 

4. RFC Manager Processing

• Parses the JSON response to extract all configuration parameters.

• Updates TR-181 parameters by invoking tr181 set commands for each relevant RFC value.

• tr181 set uses RFC API which in turn calls the tr69hotif API to store these environment variables and TR-181 parameters.

4. tr181 Set and RFC API

• The tr181 set commands internally call the RFC API to perform parameter get/set operations.

• The RFC API communicates with the local HTTP server running within tr69hostif using HTTP GET or POSTrequests.

• tr69hostif uses the below files for storing the configuration:

  /opt/secure/RFC/rfcVariable.ini	RFC environment variables	Contains environment-level variables derived from RFC config
  /opt/secure/RFC/tr181store.ini	RFC namespace TR-181 parameters	Contains TR-181 parameters managed within the RFC namespace
  /opt/secure/RFC/bootstrap.ini	Bootstrap TR-181 parameters	Contains TR-181 parameters with the bsUpdate attribute
  Profile-specific storage	Non-RFC TR-181 parameters	Managed by respective profile handlers with their own storage mechanism

  
  

5. tr69hostif Request Routing

• The tr69hostif component routes incoming parameter requests based on their namespace or attributes:

  bsUpdate attribute present	Bootstrap handlers	Handles bootstrap get/set requests
  RFC namespace	RFC handlers	Manages parameters controlled by RFC
  Other (non-RFC) parameters	Profile handlers	Routed to profile-specific get/set implementations

6. mTLS support

• RDKE expects xconf connections to be secure. This expects RFC to use MTLS by default.
• Support to add MTLS to RDKM xconf server is under investigation.
• Until then, we are disabling MTLS support by not enabling rdkcertselector
  • mTLS is enabled in the RFC code when the macro LIBRDKCERTSELECTOR is defined.

Architecture Diagram:

• Example curl command sent from an RDK device to XConf:

• Example response json received from XConf. This is stored in /tmp/rfc-parsed.txt as part of the curl request's response.

• The file /tmp/rfc-parsed.txt is later parsed in the RFC script and the parsed output is stored in the same file and looks like below: 

• The tr181store.ini contains all the RFC namespace configuration that is configured at XConf. It also contains all the local RFC settings that are done using the "tr181 -s" command.

• To force retrieving a new RFC configuration from XConf even when there is no change, invalidate the hash value with the below command.