Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Lets see how the event notification mechanism works. Basically all the event related activity are done through a D-Bus messaging extension known as IARM. In our case the network manager will register few event names and their corresponding event handler function. When an application is interested to receive that event, he will be register as a listen to that event. Whenever the event occurs all the register listener that are connected to IARM will be able to receive the notification.

IARMBus IARM CallDescriptions

IARM_BUS_WIFI_MGR_API_getAvailableSSIDs

Retrieves the List of available APs

IARM_BUS_WIFI_MGR_API_getConnectedSSID

Returns the properties of the currently connected SSID

IARM_BUS_WIFI_MGR_API_setEnabled

Enable the WIFI adapter on the box

IARM_BUS_WIFI_MGR_API_connect

Connect with given or saved SSID and passphrase

IARM_BUS_WIFI_MGR_API_getConnectionType

Retrieves the type based on active network interface

IARM_BUS_WIFI_MGR_API_getRadioStatsProps

Retrieve the get radio stats properties

...


IARM Call implementation:

...

  • In the above table we can see that for each of the possible Wi-Fi Events, we have defined a IARM Call.

...

  • For example, we

...

  • have some remote procedure calls, which can be invoked from any application to perform some Wi-Fi related operation.

...

  • These operation may be to get the list of available network or to connect to a particular

...

  • Wi-Fi network, etc.

...

IARM Events Notificaiton:

•Basically Basically we have 2 types of events for Wifi Manager notifications.
1.

State change notifications events:

...

  • WIFI_CONNECTING : When a connection is initiated the state will change from IDEAL to CONNECTING.

...

  • WIFI_FAILED : When a connection attempt is failed.

...

  • WIFI_DISCONNECTED : When a AP is disconnected from client.

...

  • WIFI_CONNECTED : This will be notified after a successful connection.

...

Error events:

...

  • WIFI_NO_SSID: The Access point we wanted to connect is no longer available.

...

  • WIFI_UNKNOWN : Unknown error has happened.

...

  • WIFI_CONNECTION_LOST : connection is lost, this may indicate that an AP is no longer in range.

...

  • WIFI_SSID_CHANGED : this indicates that we have connected to another SSID

...

  • WIFI_CONNECTION_FAILED : When the connection is failed, it may be because of invalid credential or any other issue.

...

  • WIFI_CONNECTION_INTERRUPTED : Connection is cancelled by user when it was in progress.

Wi-Fi

...

Communication Workflow

In the below sequence diagram, we will see how an HTML application will interact with Wifi manager through Service manager. We can see that for each functionality we have an uniform API name across different component, which enable simplicity in development and the set off APIs can be mapped easily. For example, If we take one API that is getConnectionType(), which we can use to get the active interface type which may be Wifi or LAN interface.

Image Added

In first place, we will have Java Script functions registered with Service manager. Then Service manager will have an internal implementation for that API with error handling and managing result.
When the call is propagated, to the actual handler daemon (Wifi manager) through message bus, it will be translated to a IARM RPC call. 

On the receiving side, Wifi manager will invoke actual Wi-Fi HAL API to get the result.So, we have seen a similar set of API are presented by different components to achieve the task.

An example, we have an user interface application where we want to show an icon based on whether Wi-Fi network is up. In that case we can take the help of service manager API to get the current state. Here service manager will internally call an RPC call with the Wifi manager to invoke the specific function. Then the wifi manager will invoke the actual HAL API to retrieve all the details and returns to the caller in a JSON formatted string. This status string will be then return to the application for displaying the appropriate icon based on UP/DN status.

Use Case: AP Discovery & Establishing Wi-Fi connection with AP

Here we will walkthrough the different RDK component involved in the process and starting from Application which is the imitator, ending with Wi-Fi HAL which is the provider of the functionality. We will also see the messaging formats in which the RDK components communicate. 


Image Added

Initiating the connection: Here application may need to enable the WiFi if required. In which case he has call the initialization routine and network manager will handle the further operation

Getting a list of connection: When the WiFi system is up, application can request for a scan operation and then the neighbor scan API will be called by network manager. Which intern calls a Wi-Fi HAL API and return the result in JSON formatted string.

Selecting a preferred network: User can select a network from the list of Available AP.

Providing credential for the preferred network: Application has to handle the prompts for passphrase, network security Key, etc. and initiate the connection process. 

Validation of the credential: Wifi manager will take the parameter and select the appropriate method to pass credential to WPA supplicant via an Wi-Fi HAL function. WPA supplicant will perform the actual sequence of operation to validate and establish the connection which will be an asynchronous process. i.e whenever the connection is established an appropriate event will be generated and notify to the caller.

Results: Application when receive the connection establish/failed event can show a visual confirmation.

Wi-Fi Integration Requirement

For integrating Wifi feature in a new RDK platform, following basic requirement can be kept in mind,

  • First we need to have the OEM or SOC provider driver and firmware available with us so that we can integrate with our platform.
  • There are Generic linux wireless packages need to be integrated with the platform.
  • Most importantly, all the compatibility issues regarding Wifi driver and platform need to be addressed before hand, so that there is no issues regarding performance or connection glitches.
  • We will need build support files for integration.
  • A new HAL has to be written for the platform.

Image Added

RDK Wifi Specification mentions, all communication from network manager to the Wifi Driver has to be through WPA supplicant. So the basic requirement is to add WPA supplicant and its related packages such as netlink library and wireless tools. When all the dependency are added to the platform, we have to write a Wi-Fi HAL customized in our platform. Then we have to add the Wifi support in build framework via adding appropriate packages in image recipe as well as machine configuration file.

Code Walk-through

Looking at the below folder structure of the wifi HAL code in reference wifi & device specific wifi, We can see both follow similar naming conventions. We have 2 common files: wifi_common_hal.c and wifi_client_hal.c


In wifi_common_hal.c:

  • Here we have defined most of the diagnostic APIs and utility functions.

In wifi_client_hal.c:

  • It Mainly defines the internal state management functions, threads for monitoring the events coming from wpa_supplicant and connection related functions.
  • It also defines call back functions for sending back the state changes and error events to wifi manager
  • In generic wifi HAL, we have 3 header functions for defining AP, client & common APIs.
  • In Raspberry Pi, the device specific HAL has dependency of WPA client library and libnl.

Image Added

Wi-Fi HAL APIs

Debugging and Log analysis