Skip to end of metadata
Go to start of metadata


RDK-B software stack provides networking interfaces such as Wi-Fi. WiFi Agent provides support for Home Wi-Fi, Hotspot and HomeSecurity AP functions.


Wi-Fi component implements Wi-Fi functionality of the device, it supports all the parameters which are defined in the TR-181 data-model and CCSP specific Wi-Fi extensions.
Figure 1 shows the architecture diagram of Wi-Fi module in the gateway stack. Here, Access Layer takes care of call to/from D-Bus. It provides all API’s for GET/SET parameters based on request from various other modules (components/PAs) in the gateway.

Data-model Management Layer (DML) loads all data model access APIs through a pre-defined XML file TR181-Wi-Fi-USGV2.XML. An XML description of data model objects and parameters is given for Data Model Management Layer to load. Subsequently, Data Model Management Layer loads the shared library ( which contains data model implementation, specified in the XML file.
The data model implementation in shared library interacts with HAL Integration Layer by calling component specific HAL APIs. These calls covert the user space calls to system level calls and takes the necessary action at driver level.

Code Flow

Initialization sequence of Wi-Fi

Once the Wi-Fi driver comes up at platform layer there are a sequence of operations carried at different layers of Wi-Fi subsystem of the gateway. Wi-Fi initialization is carried out by different layers.

During gateway boot-up, the XML file which has all information of the objects, parameters and the GET/SET handlers will be registered using common component library. TR181-Wi-Fi-USGV2.XML has the information related to Wi-Fi objects and parameters.

Once the component specific library is loaded (, the APIs are registered and then the component specific initialisation happens.

During the process of component specific data-model initialisation when Wi-Fi gets the component specific plugin initialisation command from CCSP data-model library, corresponding back end manager is called to initialise the Wi-Fi. Procedure flow of Wi-Fi initialisation is depicted in Figure-3 below.

Wi-Fi driver initialisation is carried by the component specific API layer, which will try to fetch the parameters from PSM and apply them to the driver if needed and reinitialise the Access Points.

Wi-Fi follows the layered approach for interaction. Middle layer provides the necessary APIs to the common component so as to interact with the component specific layer.

Middle layer then interact with the Integration layer whose responsibility is to mainly deal with the data-model APIs, driver specific APIs or dbus APIs to manage Wi-Fi specific parameters.

Integration layer will act as a gluing layer between the driver/dbus/PSM databases and the upper layers.

Figure 2: Wi-Fi Agent Boot-up Flow

During startup, Wi-Fi Agent initializes the parameter tree and retrieves the existing persistent configuration and related static or dynamic info from HAL integration layer API.

Figure 3: Wi-Fi Initialization 

Code flow for getting a Wi-Fi parameter

During initialisation phase of gateway, all the necessary APIs related to an object mentioned in the data-model USG file will be registered with the data-model management system. So if a query comes for a particular parameter of an object, the registered API for that particular parameter type will be called so that the information can be retrieved from the Wi-Fi module.

Once the query comes from UI/SNMP/TR69, the PA accesses corresponding D-BUS API. Later the object is identified from the registry and the corresponding API call specific to the parameter being queried is accessed. API to be accessed is determined by the data-model XML which is used for the library. Then the parameter retrieval process end up in retrieving the value for the parameter either from a centralized database maintained by Persistent Storage Manager (PSM) or from a Wi-Fi HAL.

Figure 4: Code flow of Wi-Fi subsystem

Code details of RDK-B implementations

Wi-Fi subsystem is made as part of a shared library

Interactions of Wi-Fi libraries are as below:

Figure 5: Library Interactions Involved


Objects supported by WiFi:

Note: The RDK data model naming convention prefix was changed in March 2020 to “X_RDK_”. We request you use this new prefix going forward.




$ dmcli eRT getv Device.WiFi.AccessPoint.
CR component name is:
subsystem_prefix eRT.
getv from/to component( Device.WiFi.AccessPoint.
Execution succeed.
Parameter 1 name: Device.WiFi.AccessPoint.1.Enable
type: bool, value: true
Parameter 2 name: Device.WiFi.AccessPoint.1.Status
type: string, value: Enabled
Parameter 3 name: Device.WiFi.AccessPoint.1.Alias
type: string, value: AccessPoint1
Parameter 4 name: Device.WiFi.AccessPoint.1.SSIDReference
type: string, value: Device.WiFi.SSID.1.
Parameter 5 name: Device.WiFi.AccessPoint.1.SSIDAdvertisementEnabled
type: bool, value: true
Parameter 6 name: Device.WiFi.AccessPoint.1.RetryLimit
type: uint, value: 16
Parameter 7 name: Device.WiFi.AccessPoint.1.X_CISCO_COM_LongRetryLimit
type: uint, value: 16
Parameter 8 name: Device.WiFi.AccessPoint.1.WMMCapability
type: bool, value: true
Parameter 9 name: Device.WiFi.AccessPoint.1.UAPSDCapability
type: bool, value: true
Parameter 10 name: Device.WiFi.AccessPoint.1.WMMEnable
type: bool, value: true
Parameter 11 name: Device.WiFi.AccessPoint.1.UAPSDEnable
type: bool, value: true
Parameter 12 name: Device.WiFi.AccessPoint.1.AssociatedDeviceNumberOfEntries
type: uint, value: 0
Parameter 13 name: Device.WiFi.AccessPoint.1.X_CISCO_COM_WmmNoAck
type: int, value: 0
Parameter 14 name: Device.WiFi.AccessPoint.1.X_CISCO_COM_MulticastRate
type: int, value: 123
Parameter 15 name: Device.WiFi.AccessPoint.1.IsolationEnable
type: bool, value: false
Parameter 16 name: Device.WiFi.AccessPoint.1.X_CISCO_COM_BssMaxNumSta
type: int, value: 30
Parameter 17 name: Device.WiFi.AccessPoint.1.X_CISCO_COM_BssCountStaAsCpe
type: bool, value: true
Parameter 18 name: Device.WiFi.AccessPoint.1.X_CISCO_COM_BssUserStatus
type: int, value: 1
Parameter 19 name: Device.WiFi.AccessPoint.1.X_CISCO_COM_BssHotSpot
type: bool, value: false
Parameter 20 name: Device.WiFi.AccessPoint.1.X_RDKCENTRAL-COM_BeaconRate
type: string, value:
Parameter 21 name: Device.WiFi.AccessPoint.1.X_CISCO_COM_KickAssocDevices
type: bool, value: false
Parameter 22 name: Device.WiFi.AccessPoint.1.MaxAssociatedDevices
type: uint, value: 5
Parameter 23 name: Device.WiFi.AccessPoint.1.X_COMCAST-COM_AssociatedDevicesHighWatermarkThreshold
type: uint, value: 50
Parameter 24 name: Device.WiFi.AccessPoint.1.X_COMCAST-COM_AssociatedDevicesHighWatermarkThresholdReached
type: uint, value: 3
Parameter 25 name: Device.WiFi.AccessPoint.1.X_COMCAST-COM_AssociatedDevicesHighWatermark
type: uint, value: 3
Parameter 26 name: Device.WiFi.AccessPoint.1.X_COMCAST-COM_AssociatedDevicesHighWatermarkDate
type: uint, value: 1578311709
Parameter 27 name: Device.WiFi.AccessPoint.1.X_COMCAST-COM_InterworkingServiceCapability
type: bool, value: false
Parameter 28 name: Device.WiFi.AccessPoint.1.X_COMCAST-COM_InterworkingServiceEnable
type: bool, value: false
Parameter 29 name: Device.WiFi.AccessPoint.1.X_COMCAST-COM_MAC_FilteringMode
type: string, value: Allow-ALL
Parameter 30 name: Device.WiFi.AccessPoint.1.X_RDKCENTRAL-COM_ManagementFramePowerControl
type: int, value: 0
Parameter 31 name: Device.WiFi.AccessPoint.1.X_RDKCENTRAL-COM_rapidReconnectCountEnable
type: bool, value: true
Parameter 32 name: Device.WiFi.AccessPoint.1.X_RDKCENTRAL-COM_rapidReconnectMaxTime
type: int, value: 180
Parameter 33 name: Device.WiFi.AccessPoint.1.X_COMCAST-COM_TXOverflow
type: uint, value: 0
Parameter 34 name: Device.WiFi.AccessPoint.1.X_RDKCENTRAL-COM_StatsEnable
type: bool, value: false
Parameter 35 name: Device.WiFi.AccessPoint.1.X_RDKCENTRAL-COM_WirelessManagementImplemented
type: bool, value: false
Parameter 36 name: Device.WiFi.AccessPoint.1.X_RDKCENTRAL-COM_BSSTransitionImplemented
type: bool, value: false
Parameter 37 name: Device.WiFi.AccessPoint.1.X_RDKCENTRAL-COM_BSSTransitionActivated
type: bool, value: false
Parameter 38 name: Device.WiFi.AccessPoint.1.X_RDKCENTRAL-COM_NeighborReportActivated
type: bool, value: false
Parameter 39 name: Device.WiFi.AccessPoint.1.X_CISCO_COM_MacFilterTableNumberOfEntries
type: uint, value: 0


wifi_hal.h provides the function prototypes and structure definitions used for the RDK-Broadband Wifi HAL

Git repo:

Some example APIs are listed below:





To see the API specfification. Please refer Wifi HAL API Secifications

  • No labels


  1. Could you inform what was the prefix that is deprecated? I am asking because of this text:

    Note: The RDK data model naming convention prefix was changed in March 2020 to “X_RDK_”. We request you use this new prefix going forward.

    1. Hi Z-Thiago Navarro

      The deprecated/discouraged prefix was "X_RDKCENTRAL-COM" . 

      For eg: one data model in the above document "Device.WiFi.X_RDKCENTRAL-COM_BandSteering." , if it was developed & contributed post March 2020, it would be "Device.WiFi.X_RDK_BandSteering."

      1. NB: X_RDK is not a legal prefix for a vendor specific extension according to TR-106 section 3.3, X_RDKCENTRAL-COM was.

  2. Regarding this information:

    it supports all the parameters which are defined in the TR-181 data-model and CCSP specific Wi-Fi extensions

    I would like to know what version of the specification the CcspWifiAgent supports? Thank you in advance.

    1. Hi Z-Thiago Navarro If you are looking for the data models supported by CcspWifiAgent, they are available in corresponding TR-181 data model ( a version is available at ). 

      1. Thank you for the reply. This file will be nice to check deeply. I dont know if I am missing something, but I am curious what version of the TR-181 did you use in order to mapping to  the  TR181-WIFI-EXT-USGv2.XML data model (i.e. the starting point)? (e.g. TR 181 v2.10,  TR 181 v2.14)

        1. Hello Z-Thiago Navarro We are still waiting for a reply from dev team on this. We will let you know the details as soon as we hear from them

          1. Hi, would you have any update about this issue? Thank you.

  3. Why not use the modern Wi-Fi data model developed by Wi-Fi Alliance directly?

    1. Hello Stephen [kiwin] PALM

      The existing data models were part of initial code drop and has been amended/updated later during the course of time to add/enhance features

      1. Is there a plan to adapt TR181-2-14 or 2-15 which has Wifi.DataElements?

        Is there EasyMesh controller/Agent part or any discussions pointers related to that is present?

        1. Hi Ramesh,

          Currently there is no plan to adapt Wifi.DataElements  and  MultiAP data model (for Easymesh ) in RDKB. Adapting to EasyMesh is in future roadmap but not targeted for any release yet.

  4. In WiFi initialization, the daemon startup process is through systemctl service files only or there are other ways of Initializations too?

    1. Hello Z-Manish

      The current system is  via systemctl only( though some very older platforms were known to run with init.d-where systemd was not present )

  5. As far as I can tell, ccspwifiagent does not have PSM support. Why is it documented as if it does?

  6. Hi Z-Lars Feyaerts ,

    WiFiAgent component supports PSM query. All the CCSP data model  value in CcspWiFiAgent are stored in  PSM data base.  When the device comes up during Wifi Init all the data are fetched from PSM and populated in data model table. Please look for all PSM_Get_Record_Value2() and PSM_Set_Record_Value2() call in Wifi Agent component.

    Thank You. 

  7. I am confused that can CcspWifiAgent support WiFi STA mode or how can RDK-B support WiFi STA mode?

  8. Hi Stone Zhang , in RDKB the gateway usually runs in AP mode. STA mode is not supported yet in RDKB, where gateway will behave like a wireless client may be called a station. 

  9. hi,can web-PA/TR181-PA skip CcspWifiAgent and directly call wifi Hal API to interact with wifi driver  

    1. Hi wenjun.guan 

      In RDK-Broadband Design ,CcspWifiAgent is responsible for loading of pre-defined XML file (TR181-Wi-Fi-USGV2.XML) and shared library ( which contains data model API implementation ,CcspWifiAgent loads all data model access APIs from the Datamodel XML file. skipping CcspWifiAgent and directly calling HAL API's will impact the internal data model communication .Also the dm mapping between web-PA/TR181-PA and hal layer is not available. 

  10. Hi,

    We want to enable DFS via macro CONFIG_DFS. Seems we need to implement HAL API wifi_setRadioDfsAtBootUpEnable(). However we don't find it's defined or described

    in wifi_hal.h. Is wifi_setRadioDfsAtBootUpEnable() a HAL API or something else?  Thank you!

  11. Hi Z-Tony He ,

    To enable macro CONFIG_DFS, the distro feature needs to be enable for your platform - DISTRO_FEATURES_append = "dfs"

    The mentioned hal API is vendor specific and defined in SoC layer, not part of generic halinterface.

    Thank you.

    1. Hi Sipra,

      Thanks for your reply. May I know how where to find the document like generic halinterface to describe the vendor specific API or an example to implement our own API?

    2. Hi sipra samantray ,

      In case you missed my reply, may I know if you have any idea about my question? I am blocked by this vendor specific API.

  12. Hello,

    Could anyone help me, How the associated device would update whenever new WIFI client connected to the CM. Is that from WIFI driver or anything else ?

    what was the flow for WIFI client connection ?

    WiFi Driver → Associated Devices(WiFI Agent) → Host Table(LMLite). is this correct please correct me if am wrong .

  13. Hi Emandi Naga Srikanth ,

    You are correct, the associated and disassociated device call back is from HAL -> CcspWifiAgent -> CcspLMLite
    "Wifi_Hosts_Sync_Func()"  - to sync the Host table in LMLite.

    Thank you.

    1. Thank you for reply sipra samantray

      One thing, Have two WiFi clients connected to CM , If CM got the Disassociated Message for disconnect client but Still LMLite have information with two associated devices.

      It might be problem with WiFI Driver(Hal) or WiFi Agent , could you help me on this.

      Thanks in Advance.   

  14. Hi Emandi Naga Srikanth ,

    The Host table in LMLite will list all connected/disconnected clients detail. For clients which are disconnected, that will be marked as Active=false. It can be seen in Device.Hosts.Host.{i}.Active data model. If this is not "false" for a disconnected client, that may be because HAL is not sending the disconnect callback.

    Thank you.

  15. Hello,

    A question about the macro "WIFI_HAL_VERSION_3" in WifiAgent:  Looks like the code in this "WIFI_HAL_VERSION_3" could manage the wifi radios in a flexible way to support 3 more radios. 

    Is there any extended functions in Version3., Or in other words, what's the main purpose of the this Macro "WIFI_HAL_VERSION_3"? 

    For my 2-radio device, Is still ok if we Unuse this macro?  thansk! 

    1. Hi qiting ,

      HAL 3.0 is for tr-band support in RDK-B . The code is protected using WIFI_HAL_VERSION_3 flag. If your device is supporting 2 radios, then yes it need not to be enabled

      Priyankaa KVB