Scope:

The scope of this activity is to migrate from existing CcspWiFiAgent component to OneWiFi component in RDK-B Reference platform

Target Audience:

• RDK-B Operators
• RDK-B SoC Vendors
• RDK-B OEM's
• RDK-B Application Vendors(Plume/OpenSync)
• RDK-B System Integrators 

High Level Architecture:

The internal functional entities of the OneWifi process are as shown in the above diagram. OneWifi software architecture is essentially a multi-threaded software architecture, the three main threads are 

• Core thread: this thread is the fundamental engine of the process that is responsible for all configuration of WiFi parameters, command/control/status response and WiFi state indications. The core thread is also responsible for steering related activities.
• DML thread: this thread handles the TR-181 set/get handlers. 
• Apps thread: this thread is responsible for supporting all WiFi related application/features such as harvester, motion sensing, blaster, single client measurements etc.

The software architecture of working of each thread is detailed below.

OneWiFi Thread Management, Inter Thread Communication and Data Handling

The diagram below depicts thread management and inter thread communication and data transfer in OneWifi. Threads essentially wait for condition and timeouts. If data needs to be processed, the data is posted into queue and the thread is signaled. The thread retrieves the data from the queue and processes the data

Core Functional Blocks/Subsystem

The core thread waits for events or messages, if there are events or messages in the FIFO queue, the thread retrieves the events or messages one after another and takes appropriate action. Three kinds of messages or events can be enqueued in the Core thread queue

1. South bound messages received from WebConfig Agent or Ovsdb Managervia RBUS callback.
2. South bound messages received from DML thread because of TR-181 set handler invocation
3. North bound asynchronous Wi-Fi events from HAL or driver isuch as
   1. Client associations/disassociations
   2. VAP or interface Up/Down
   3. Registered 802.11mgmt frame reception
   4. Band Steering events

All south bound messages are decoded, parsed and validated by core thread. In case, the messages are successfully validated, the core thread uses Wi-Fi HAL function to configure Wi-Fi driver or baseband accordingly. if successful, core thread is also resonsible for updating the persistent database so that in case of reboot or power failure, the Wi-Fi subsystem of the CPE device maintain previous operating configuration. Core thread also handles Wi-Fi or Factory reset commands that may be triggered by messages enqueued by DML thread or during initialization sequence.

All north bound events are translated to state update in ovddb state tables using WebConfig encoded messages sent by core to ovsdb manager.

Core Thread Software Architecture

Some of the components described are as follows:

• Config Tracker - serves as an internal database for all Radio and VAP attributes. To be consumed by OneWifi internals, eg. stats policies, steering policies, configuration applicator, etc. Intended to be acting as a south bound interface and called by adapters to integrate them into specific systems, eg. rbus+webconfig.
• State Tracker - serves as a layer to shield OneWifi business logic modules from HAL API which is intended to not be fully object oriented.and to simplify its implementation, eg. event buffer overrun recovery handling, event order sanitization (sometimes implementations source events from multiple streams and their processing ordering is undefined).
• Configuration Applicator - uses inputs: Config Tracker and other mutators (coming from, eg. Stats or Steering policies) to generate configuration command(s) and submit them only if the assembled configuration command is out-of-sync with what State Tracker is reporting. Configuration Applicator is triggered for recompute by either Config Tracker, State Tracker or any of the registered mutators.
• Steering/Stats/Other policies - multiple entities implementing specific actions. Mostly interact with State Tracker, Configuration Applicator (as mutators), HAL wrapper (to perform world-visible actions) or between each other modules (Steering modules using some Stats).
• Rbus-webconfig adapter - adaptation logic which feeds Config Tracker based on Webconfig blobs. Essentially a translator to abstract Webconfig away from core logic. Foo thread / foo adapter - approach recommended on integrating other existing, or thread-heavy tasks. The OneWifi core is a single thread expecting no other threads interacting directly with its data structures or control flows, so adapters and their dispatch handlers are expected to be the entry/exit points between threads to simplify locking.
• HAL wrapper - virtually a HAL API that allows multiple backing implementations: Wifi HAL, Target API or other in the future. Intended to be mostly stateless and simple "pass through" - allowing out-of-order event delivery, etc. This allows simpler implementation for vendors. The task of sanitizing is handed to State Tracker for actual business logic consumers. The HAL wrapper API is highly aggregated (big blob call for configuration, singular calls for adequate actions like WPS PBC) with hints on which attributes are out-of-sync allowing implementations to optimize if desired. The wrapper is also capable of supporting multiple backing implementations at the same time (without requiring business logic implementation to be aware of any of that) to accommodate mixed vendor chips (on non-Wifi-Hal platforms) such as Broadcom + Quantenna.

All components are intended to schedule most of the actual work through separate dispatch handlers per object entities. This allows easy batching (to debounce and reduce ping-pong), time occupancy (to provide insight into possible stalls, or aid scheduling), forces idempotency (avoids some ab/ba logic issues, provides failure recovery procedures without additional explicit logic) and makes sure memory resource allocation is bound.

Apps Functional Blocks/Subsystem

Operational Modes

OneWifi can operate in two modes, router and extender. 

Router Mode

In router mode, the stack broadcasts front haul virtual access points that client devices may connect with. Total of seven such virtual access points are created on each radio and provide different kinds of services. 

Extender Mode

TBD

Flow Diagram/Pseudo Code

Core Thread Pseudo Code

Message Sequence Diagrams

Initialization

Client Authentication

Below are the list of logs present in /rdklogs/logs for Debugging OneWiFi Issues

For Additional indepth  Debugging one should enable below commands

check for the respective logs in tmp

Build Instructions for RPI4 32bit

mkdir <workspace dir>
cd <workspace dir>
repo init -u https://code.rdkcentral.com/r/manifests -b dunfell -m rdkb-extsrc.xml
repo sync -j`nproc` --no-clone-bundle
MACHINE=raspberrypi4-rdk-broadband source meta-cmf-raspberrypi/setup-environment
bitbake rdk-generic-broadband-image    

Reference link: RPI 4B Model Reference Platform

Build Instructions for RPI4 64bit

mkdir <workspace dir>
cd <workspace dir>
repo init -u https://code.rdkcentral.com/r/manifests -b dunfell -m rdkb-extsrc.xml
repo sync -j`nproc` --no-clone-bundle

<Cherrypick the below topic changes manually that are still pending for merging>
https://code.rdkcentral.com/r/q/topic:rdkb-64bit-build-errors
https://code.rdkcentral.com/r/q/topic:rdkb-64bit-runtime-errors

MACHINE=raspberrypi4-64-rdk-broadband source meta-cmf-raspberrypi/setup-environment
bitbake rdk-generic-broadband-image

Reference link: RPI 4B Model Reference Platform with 64bit Arch

Supported Wi-Fi Chipsets:

• Broadcom (In built 2.4Ghz Radio in Raspberry Pi4)
• Realtek (5Ghz USB dongle)
• Mediatek (5Ghz USB dongle) (Supported only on RPI4 32bit build)

Feature Enhancements:

•    RDKM team will be starting OneWiFi Working group after RDK Release 2023 Q2.All operator use cases will be discussed,reviewed,planned and implemented as part of OneWiFi Working group and contributed back to RDK

Test Results:

Supported Dongles: 

• TP-Link AC1200(Realtek)​​
• TP-Link AC1300(Realtek)     ​
• Netgear(MediaTek)​ (Supported only on RPI4 32bit build)
  

References:

• REFPLTB-2020 - Getting issue details... STATUS
• REFPLTB-2491 - Getting issue details... STATUS
• Code review link: https://code.rdkcentral.com/r/q/topic:OneWifi

Differences Between CcspWifiAgent and OneWiFi Applysettings:

CcspWifiAgent :

dmcli eRT setv Device.WiFi.Radio.2.X_CISCO_COM_ApplySetting bool true
dmcli eRT setv Device.WiFi.Radio.1.X_CISCO_COM_ApplySetting bool true 

OneWiFi:

#Any dmcli commands specific to SSID and AccessPoint execute the Below Access Point Related apply settings
dmcli eRT setv Device.WiFi.ApplyAccessPointSettings bool true

#Any dmcli executions specific to Radio level use the below Radio apply settings command
dmcli eRT setv Device.WiFi.ApplyRadioSettings bool true

Debugging Tips :

Below are the list of logs present in /rdklogs/logs for Debugging OneWiFi Issues.

For Additional in-depth Debugging one should enable below commands ,

• touch /nvram/wifiMgrDbg
• touch /nvram/wifiDbDbg
• touch /nvram/wifiWebConfigDbg
• touch /nvram/wifiHalDbg
• touch /nvram/wifiCtrlDbg
• touch /nvram/wifiMonDbg
• touch /nvram/wifiDMCLI
• touch /nvram/wifiLib
• touch /nvram/wifiLibhostapDbg

check for the respective logs in /tmp,

• tail -f wifiCtrl &
• tail -f wifiHal &
• tail -f wifiMgr &
• tail -f wifiDMCLI &

• tail -f wifiDb &

• tail -f wifiWebConfig &
• tail -f wifilibhostap &

Contact us:

  For support please reach out to support@rdkcentral.com