This page explains the Wi-Fi subsystem of RDK-B stack.

Introduction

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

Architecture of Wi-Fi subsystem

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 (libWi-Fi.so) 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.

Figure 1: Architectural view of Wi-Fi sub-system

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 (libWi-Fi.so), 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 libWi-Fi.so

Component Specific HAL

Component Specific APIs defined in RDK-B architecture will be interacting with the driver through these APIs.

Interactions of Wi-Fi libraries are as below:

Figure 5: Library Interactions Involved

Objects

Objects supported by WiFi:

Device.WiFi.Radio.
Device.WiFi.SSID.
Device.WiFi.AccessPoint.

Device.WiFi.NeighboringWiFiDiagnostic.
Device.WiFi.X_RDKCENTRAL-COM_BandSteering.
Device.WiFi.X_RDKCENTRAL-COM_ATM.

WiFi HAL

wifi_hal.c provides the function prototypes and structure definitions used for the RDK-Broadband Wifi HAL
Some example APIs are listed below:

wifi_init
wifi_initRadio
wifi_down
wifi_reset
wifi_factoryReset
wifi_factoryResetRadio
wifi_setApEnable / wifi_getApEnable
wifi_getApStatus
wifi_getSSIDName