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

Compare with Current View Page History

« Previous Version 7 Next »

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

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

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

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.

$ dmcli eRT getv Device.WiFi.NeighboringWiFiDiagnostic.

CR component name is: eRT.com.cisco.spvtg.ccsp.CR
subsystem_prefix eRT.
getv from/to component(eRT.com.cisco.spvtg.ccsp.wifi): Device.WiFi.NeighboringWiFiDiagnostic.
Execution succeed.
Parameter 1 name: Device.WiFi.NeighboringWiFiDiagnostic.Enable
type: bool, value: false
Parameter 2 name: Device.WiFi.NeighboringWiFiDiagnostic.DiagnosticsState
type: string, value:
Parameter 3 name: Device.WiFi.NeighboringWiFiDiagnostic.ResultNumberOfEntries
type: uint, value: 0

HAL APIs

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

Git repo: https://code.rdkcentral.com/r/plugins/gitiles/rdkb/components/opensource/ccsp/halinterface/+/rdk-next/wifi_hal.h

Some example APIs are listed below:

APIs

wifi_init
wifi_initRadio
wifi_down
wifi_reset
wifi_factoryReset
wifi_factoryResetRadio
wifi_setApEnable
wifi_getApEnable
wifi_getApStatus
wifi_getSSIDName

wifi_getWifiChannelStats

wifi_getRadioChannelStats
wifi_getApAssociatedDeviceRxStatsResult
wifi_getHalVersion
wifi_factoryResetRadio
wifi_setLED
wifi_setRadioCountryCode
wifi_pushCountryCode
wifi_getATMCapable
wifi_setATMEnable
wifi_getATMEnable
wifi_setApATMAirTimePercent
wifi_getApATMAirTimePercent
wifi_getApATMSta
wifi_setApATMSta
wifi_getRadioNumberOfEntries
wifi_getSSIDNumberOfEntries
wifi_getRadioIfName
wifi_getRadioMaxBitRate
wifi_getRadioSupportedFrequencyBands
wifi_getRadioOperatingFrequencyBand
wifi_getRadioSupportedStandards
wifi_getRadioMode
wifi_setRadioChannelMode
wifi_setRadioMode
wifi_getRadioPossibleChannels
wifi_getRadioChannelsInUse
wifi_setRadioAutoChannelEnable
wifi_getRadioAutoChannelSupported
wifi_getRadioDCSSupported
wifi_getRadioDCSEnable
wifi_getRadioDCSChannelPool
wifi_getRadioDCSScanTime
wifi_getRadioDcsDwelltime
wifi_getRadioDfsSupport
wifi_getRadioAutoChannelRefreshPeriodSupported
wifi_getRadioAutoChannelRefreshPeriod
wifi_setRadioAutoChannelRefreshPeriod
wifi_setRadioOperatingChannelBandwidth
wifi_getRadioExtChannel
wifi_setRadioExtChannel
wifi_getRadioGuardInterval
wifi_setRadioGuardInterval
wifi_getRadioMCS
wifi_setRadioMCS
wifi_getRadioTransmitPowerSupported
wifi_getRadioTransmitPower
  • No labels