Page History

Table of Contents

Scope:

              This  This guide will help RDK-B community to port OneWifi on their platforms

Target Audience:

           RDK-B Software Architects and Engineers

Prerequisites:

TBD

Supported platforms:

...

1. Dunfell
2. Kirkstone(supported in rdkb2023q3 kirkstone beta release and planned for rdkb2023q4 official release)from rdkb2023q4 official release)

High level architecture:

Image Added

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

Image Added

Core Functional Blocks/Subsystem

Image Added

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

Image Added

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.

Image Added

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

@startuml
skinparam defaultTextAlignment center
!pragma useVerticalIf on
start
:core_thread_start_function;
:rbus_register\n(rbus_message_cb)|
:read_wifi_ps_db|
:wifi_hal_init|
:wifi_hal_events_register\n(wifi_hal_cb)|
repeat :for_each_radio
:wifi_hal_setRadioOperatingParams|
:wifi_hal_createVAP|
repeat while()
repeat :event_queue_wait;
split
    :rbus_event\n(web_config_message)<
    :decode_message|
    if (msg eq webconfig_msg) then (yes)
        if (validate_msg() eq SUCCESS) then (yes)
            :rbus_send_to_webconfig(ACK)>
        else (no)
            :rbus_send_to_webconfig(NACK)>
            stop
        endif
        if (wifi_hal_func() eq SUCCESS\n(HAL Wrapper)) then (yes)
            :write_wifi_ps_db|
            :rbus_send_to_webconfig(SUCCESS)>
        else (no)
            :rbus_send_to_webconfig(FAILURE)>
        endif
    elseif (msg eq ovdsbmgr_msg) then (yes)
        if (validate_msg() eq SUCCESS) then (yes)
            :rbus_send_to_ovsdbmgr(ACK)>
        else (no)
            :rbus_send_to_ovsdbmgr(NACK)>
            stop
        endif
        if (wifi_hal_func() eq SUCCESS\n(HAL Wrapper)) then (yes)
            :write_wifi_ps_db|
            :rbus_send_to_ovsdbmgr(SUCCESS)>
        else (no)
            :rbus_send_to_ovsdbmgr(FAILURE)>
        endif
    endif
split again
    :dml_event\n(web_config_message)<
    :decode_message|
    if (validate_msg() eq SUCCESS) then (yes)
        if (wifi_hal_func() eq SUCCESS) then (yes)
            :write_wifi_ps_db|
        endif
    endif
split again
    :hal_event\n(hal_cb_event)<
    if (event eq assoc_event) then (yes)
        :create_ovsdb_state_blob)|
        :rbus_send_to_ovsdbmgr(json_blob)>
    elseif (event eq disassoc_event) then (yes)
        :create_ovsdb_state_blob)|
        :rbus_send_to_ovsdbmgr(json_blob)>
    elseif (event eq vap_up_event) then (yes)
        :create_ovsdb_state_blob)|
        :rbus_send_to_ovsdbmgr(json_blob)>
    elseif (event eq vap_down_event) then (yes)
        :create_ovsdb_state_blob)|
        :rbus_send_to_ovsdbmgr(json_blob)>
    elseif (event eq bsal_event) then (yes)
        if (bsal_event eq bsal_event_probe_req) then (yes)
            :handle_bm_probe|
        elseif (bsal_event eq bsal_event_client_connect) then (yes)
            :handle_bm_client_connect|
        elseif (bsal_event eq bsal_event_client_disconnect) then (yes)
            :handle_bm_client_disconnect|
        elseif (bsal_event eq bsal_event_rssi_xing) then (yes)
            :handle_bm_rssi_xing|
        endif
    endif
split again
    :timeout<
    :stats_collection|
end split
repeat while()
:core_thread_end;
stop

start
:rbus_message_cb;
:create_rbus_event|
:event_queue_push(rbus_event)>
stop

start
:wifi_hal_cb;
:create_hal_event|
:event_queue_push(hal_event)>
stop

@enduml

Message Sequence Diagrams

Initialization

@startuml
hide footbox
skinparam SequenceMessageAlign center
participant AGENT as "Core Thread"
participant HAL as "WiFi HAL Wrapper"
participant HOSTAP as "hostap"
participant DRIVER as "WiFi Driver"
participant LINUX as "Linux System"

group ctrl-plane
AGENT -> HAL: wifi_init
group Interfaces Enumeration
HAL -> LINUX: nl_80211cmd(NL80211_CMD_GET_WIPHY, NLM_F_DUMP, wiphy_dump_handler)
LINUX -> HAL: wiphy_dump_handler(NL80211_ATTR_WIPHY = 0, NL80211_ATTR_WIPHY_NAME, NL80211_ATTR_SUPPORTED_COMMANDS)
LINUX -> HAL: wiphy_dump_handler(NL80211_ATTR_WIPHY = 1, NL80211_ATTR_WIPHY_NAME, NL80211_ATTR_SUPPORTED_COMMANDS)
LINUX -> HAL: wiphy_dump_handler(NL80211_ATTR_WIPHY = 2, NL80211_ATTR_WIPHY_NAME, NL80211_ATTR_SUPPORTED_COMMANDS)
end
group for each Interface
HAL -> LINUX: HAL -> LINUX: nl_80211cmd(NL80211_CMD_GET_WIPHY, NL80211_ATTR_WIPHY = i, wiphy_get_info_handler)
LINUX -> HAL: wiphy_get_info_handler(NL80211_ATTR_CIPHER_SUITES, NL80211_ATTR_WIPHY_BANDS)
group for each band in NL80211_ATTR_WIPHY_BANDS
HAL -> HAL: phy_info_frequencies
HAL -> HAL: phy_info_ht_capa
HAL -> HAL: phy_info_vht_capa
HAL -> HAL: phy_info_rates
end group
end
HAL -> HOSTAP: eloop_init
HAL -> HOSTAP: eap_server_register_methods
HAL --> AGENT: Success
AGENT -> HAL: wifi_getHalCapability
HAL <-> DRIVER: get phy device capabilities
HAL --> AGENT: Success
group for each Radio
AGENT -> HAL: wifi_setRadioOperatingParameters(index, radio_param)
HAL <-> DRIVER: set radio parameters
HAL -> HOSTAP: update_hostap_config_params (update struct hostapd_config for this radio)
HAL --> AGENT: Success
AGENT -> HAL: wifi_createVAP(radio, vap_map)
group for each VAP
HAL --> LINUX: create interface
group vap_mode_ap
HAL -> LINUX: nl80211_cmd(NL80211_CMD_SET_INTERFACE, NL80211_IFTYPE_AP)
HAL -> HOSTAP: update_hostap_data (update struct hostapd_data for this interface)
HAL -> HOSTAP: update_hostap_bss (update struct hostapd_bss_config for this interface)
HAL -> HOSTAP: update_hostap_iface (update struct hostapd_iface for this interface)
HAL -> HOSTAP: setup_driver(wpa_drv_ops)
HAL -> HOSTAP: drv_init
HAL -> HOSTAP: hostapd_setup_bss(hostapd_data)
HOSTAP -> HAL: flush
HAL -> DRIVER: wifi_drv_flush
HOSTAP -> HAL: sta_deauth
HAL -> DRIVER: wifi_drv_sta_deauth
HOSTAP -> HAL: set_key
HAL -> DRIVER: wifi_drv_set_key
HOSTAP -> HAL: set_ap
HAL -> DRIVER: wifi_drv_set_ap
HOSTAP -> HAL: set_operstate
HAL -> DRIVER: nl80211_register_mgmt_frames(NL80211_CMD_FRAME, process_mgmt_frame)
HAL -> LINUX: bridge_rx(raw socket listen)
end
group vap_mode_sta
HAL -> LINUX: nl80211_cmd(NL80211_CMD_SET_INTERFACE, NL80211_IFTYPE_STA)
HAL -> LINUX: nl80211_start_scan(NL80211_CMD_TRIGGER_SCAN)
HAL -> LINUX: interface_rx(raw socket listen)
end
end
HAL --> AGENT: Success
end
AGENT -> HAL: wifi_run
HAL -> HOSTAP: eloop_run
HOSTAP -> HOSTAP: eloop
end

@enduml

Client Authentication

@startuml
hide footbox
skinparam SequenceMessageAlign center
participant HAL as "WiFi HAL Wrapper"
participant HOSTAP as "hostap"
participant DRIVER as "WiFi Driver"
participant LINUX as "Linux System"
participant STA as "Client Device"

group client authentication (WPA2 and WPA3 handshakes)
group mlme
STA -> DRIVER: Auth Frame
DRIVER -> HAL: process_mgmt_frame(NL80211_ATTR_FRAME, frame = auth)
HAL -> HOSTAP: wpa_supplicant_event(EVENT_RX_MGMT, event.frame = frame)
HOSTAP -> HAL: send_mlme(auth)
HAL -> DRIVER: wifi_drv_send_mlme(auth)
DRIVER -> STA: Auth Frame
STA -> DRIVER: Assoc Req Frame
DRIVER -> HAL: process_mgmt_frame(NL80211_ATTR_FRAME, frame = assoc req)
HAL -> HOSTAP: wpa_supplicant_event(EVENT_RX_MGMT, event.frame = assoc req)
HOSTAP -> HAL: send_mlme(assoc resp)
HAL -> DRIVER: wifi_drv_send_mlme(assoc resp)
DRIVER -> STA: Assoc Resp Frame
DRIVER -> HAL: nl80211_event(NL80211_CMD_FRAME_TX_STATUS)
HAL -> HOSTAP: wpa_supplicant_event(EVENT_TX_STATUS)
end
group non-mlme
STA -> DRIVER: Auth Frame
DRIVER -> STA: Auth Frame
STA -> DRIVER: Assoc Req Frame
DRIVER -> STA: Assoc Resp Frame
DRIVER -> HAL: nl80211_event(NL80211_CMD_NEW_STATION)
HAL -> HOSTAP: wpa_supplicant_event(EVENT_TX_ASSOC)
end
note over HOSTAP
    start 802.1x authentication
end note
HOSTAP -> HAL: hapd_send_eapol(EAPOL 1/4)
HAL -> DRIVER: bridge_tx(EAPOL 1/4)
DRIVER -> STA: EAPOL 1/4
STA -> DRIVER: EAPOL 2/4
DRIVER -> HAL: bridge_rx (EAPOL 2/4)
HAL -> HOSTAP: wpa_supplicant_event(EVENT_EAPOL_RX, event.frame = eapol)
HOSTAP -> HAL: hapd_send_eapol(EAPOL 3/4)
HAL -> DRIVER: bridge_tx(EAPOL 3/4)
DRIVER -> STA: EAPOL 3/4
STA -> DRIVER: EAPOL 4/4
DRIVER -> HAL: bridge_rx (EAPOL 4/4)
HAL -> HOSTAP: wpa_supplicant_event(EVENT_EAPOL_RX, event.frame = eapol)
HOSTAP -> HAL: set_key
HAL -> DRIVER: wifi_drv_set_key
HOSTAP -> HAL: set_sta_flags
HAL -> DRIVER: wifi_drv_set_sta_flags
end

@enduml

Epic details:

• Jira
  server JIRA - 2 serverId 11deff04-0380-3a3d-a916-0849d4e573f7 key REFPLTB-2020

...

Integration segments:

Dependencies to build build OneWifi

Systemd Service file:

• •    onewifi.service

Create platform layer for mediatek platform,please consider raspberry pi as reference

• • https://code.rdkcentral.com/r/plugins/gitiles/rdkb/components/opensource/ccsp/hal/rdk-wifi-hal/+/refs/heads/rdk-next/platform/
  • https://code.rdkcentral.com/r/c/rdk/components/generic/rdk-oe/meta-cmf-raspberrypi/+/85744/1/meta-rdk-broadband/recipes-ccsp/hal/files/0002_onewifi_process_bringup_changes.patch

           Manifest entries:

• • Onewifi component entry in manifest file (OneWifi) and rdk-wifi-hal component entry in manifest (rdk-wifi-hal)

Layers to consider:

           1.meta-raspberrypi ( Or )meta-cmf-soc-<soc name>  ------- Firmware/drivers/kernel to be available

• • For proposing a new component,please create a bb file here

           2.meta-cmf-raspberrypi (Or) meta-cmf-<platformname> --------- RDK-B changes to specific to SOC platform 

• • All changes that need to be done for the primary recipe are handled in the form of bbappend 
  • Patches: Patches are recommended if the changes are very specific and tied with SOC platform code.

           3.meta-cmf-broadband ----------- RDK-B changes which are common for all RDK-B community members

• • All changes that need to be done for the primary recipe are handled in the form of bbappend
  • Patches: Patches are recommended if the changes are very specific and tied with SOC platform code.
  • All existing reference patches in Raspberry pi may not be applicable for real targets,Because of hardware limitation & functionality limitation we have added patches.

           Bug fixing or feature enhancement:

• • Bug fixing or feature enhancement done as part of OneWifi which are generic enough should come to OneWifi generic repo 

Flags defined in Onewifi:

• • Raspberry Pi has certain limitations on the driver side to support end to end use case of OneWifi and Build dependencies which are specific to comcast.to avoid such issues we have introduced a flag (_PLATFORM_RASPBERRYPI_) to keep it under conditional compilation.for Real targets we dont really need this flags

Bulk atomic HAL apis for common configuration

Stats implementation:

• • • This is vendor specific.we can use vendor based implementation from device specific HAL.pls refer this ticket for reference(

      Jira
      server JIRA - 2 serverId 11deff04-0380-3a3d-a916-0849d4e573f7 key REFPLTB-2510

      )

wifi database:

• • • rdkb-wifi.db

64 bit build support:

• • • Comcast doesnt have 64 bit support in the current platforms.from RDK team side we have Raspberrypi 4 platform which support 64bit.we have supported Onewifi as part of this platform and fixed lot of alignment issues and warning treated as errors

Difference Between CcspWifiAgent and OneWiFi Apply settings

 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 &

Wi-Fi 7 segment:

                              Initial Headers: https://code.rdkcentral.com/r/plugins/gitiles/rdkb/components/opensource/ccsp/halinterface/+/490e08dc0edc9180a18c60eb4d6d3b0c85a1ebe3

                           Below things will be supported by Onewifi as part of Wi-Fi 7 which includes changes in onewifi ,rdk-wifi-hal & libhostap(for Wi-Fi 7 we use libhostap 2.11 version )

1. 1. 1. 320 MHZ
      2. 4kQAM
      3. MLO