You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

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: 
  • 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.iniRFC environment variablesContains environment-level variables derived from RFC config
    /opt/secure/RFC/tr181store.iniRFC namespace TR-181 parametersContains TR-181 parameters managed within the RFC namespace
    /opt/secure/RFC/bootstrap.iniBootstrap TR-181 parametersContains TR-181 parameters with the bsUpdate attribute
    Profile-specific storageNon-RFC TR-181 parametersManaged 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 presentBootstrap handlersHandles bootstrap get/set requests
    RFC namespaceRFC handlersManages parameters controlled by RFC
    Other (non-RFC) parametersProfile 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:

rfc


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

tbd


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

tbd


  • 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: 

tbd


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

tbd


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

tr181 -s -v invalidate Device.DeviceInfo.X_RDKCENTRAL-COM_RFC.Control.ConfigSetHash




  • No labels