Overview of OneWifi's Architecture and Design Evolution

OneWifi was developed to address the architectural challenges faced during the development and field deployment of its predecessor, CcspWifiAgent. The previous Wi-Fi stack utilized an overlay of multiple Wi-Fi processes, as depicted on the left side of below diagram. In this architecture, the CcspWifiAgent and Wireless Manager processes acted as independent configuration components for Wi-Fi parameters, which led to significant synchronization issues between states and data.

A dedicated process, the Mesh Agent, was used to synchronize these components. However, if any adverse events impacted the Mesh Agent, the synchronization between the processes would often become misaligned.

In addition to these synchronization challenges, the Stats Manager and Band Steering Manager introduced further complexity to the Wi-Fi stack. The numerous interfaces between the Wi-Fi driver and the baseband also led to reentrancy issues.

Beyond synchronization and reentrancy concerns, the previous architecture also faced other significant challenges, including:

• Persistent storage difficulties
• A large volume of vendor-specific proprietary code
• Inadequate debugging and triaging tools

These challenges necessitated the development of OneWifi to streamline the architecture, improve reliability, and enhance maintainability.

OneWifi Architecture Overview

The following sections outline the key components of the OneWifi architecture, as depicted in below diagram

Wi-Fi Driver

The Wi-Fi driver, shown in [1] of the above diagram, is provided by the SoC vendor as part of the Software Development Kit (SDK). It primarily interfaces with the baseband hardware to perform lower MAC (Medium Access Control) functionalities, including:

• Downlink scheduling
• Frame acknowledgements and retransmissions
• Frame integrity checks
• Encryption and decryption

Wi-Fi HAL (Hardware Abstraction Layer)

The Wi-Fi HAL, represented in [2] of the above diagram, provides an abstraction layer that enables upper-layer software components to perform SoC-independent function calls. This layer is largely built using open-source software such as HostAp and cfg80211/netlink80211 libraries.

If the vendor’s driver is cfg80211 compliant, the existing HAL implementation will seamlessly provide the required abstraction functionalities to upper-layer components. If the driver is not compliant, the vendor must implement the specified HAL functions as defined in HAL Specifications 3.0.

Wi-Fi Core Controller

The Wi-Fi Core Controller, shown in [3] of the above diagram, acts as the central component of the OneWifi stack. It interfaces with the Wi-Fi driver through the HAL abstraction layer for both control and statistics planes. The Core Controller serializes all configuration and statistics-related queries to the driver, ensuring serialized access and preventing reentrancy issues.

Services Framework

The Services Framework, illustrated in [4] of the above diagram, provides the capability to create, configure, and manage Wi-Fi Virtual Access Point (VAP) services, also known as Wi-Fi networks. The types of network services that can be created include:

• Private Network – Typically for consumer usage
• Public Hotspot – For public venues such as cafés or airports
• Configurator – For onboarding client devices to the Wi-Fi network
• Special Services – For operator-controlled devices, such as streaming devices
• Backhaul – For Mesh Extenders

Wi-Fi Applications Framework

The Wi-Fi Applications Framework, shown in [5] of the above diagram, serves as a registry for Wi-Fi applications. It allows applications to register their requirements, such as event notifications, statistics, and periodicity of data collection. This framework provides access to:

• Wi-Fi stack configuration management data
• Both synchronous and asynchronous events
• Statistics, counters, and telemetry data

OneWifi Applications Framework

The high-level architecture of the OneWifi Applications Framework is illustrated in above diagram. Applications can register with the framework, specifying their capabilities, and begin receiving events and statistics from the core components of the OneWifi stack. This integration allows the applications' algorithms to take real-time actions based on the incoming data.

A variety of application types are currently supported and tested, including:

• Device onboarding and provisioning
• Wi-Fi health monitoring
• Device fingerprinting
• Motion detection
• Client connection management
• Mesh technology applications

Applications can either be an integral part of the OneWifi process or run as external processes on the CPE (Customer Premises Equipment). In the latter case, the framework creates a virtual adapter that facilitates seamless data communication between the OneWifi stack and the application.

For applications running as external processes, as depicted in above diagram, RBUS handles all categories of data exchanges between the OneWifi stack and the external application.

Data Model Manager

The Data Model Manager, shown in first diagram, abstracts various Wi-Fi data model specifications, including TR-181, WFA MultiAP Data Elements, and BBF Data Models. This module also manages the database technology used by OneWifi for persistent storage.

Data Model Abstraction

OneWifi supports two main data model specifications:

• TR-181 Data Model
• Wi-Fi Alliance MultiAP Data Elements

Database Abstraction

To manage persistent storage of configuration, RFC, and other operational parameters, OneWifi utilizes a database abstraction layer. This layer hides the complexities of using different relational databases, allowing OneWifi to work with various database technologies, such as MySQL, OVS, or PostgreSQL. OneWifi uses the OVS database as its primary persistent storage mechanism.

Platform Manager

The Platform Manager, depicted in first diagram, abstracts platform-specific intricacies and differences, enabling OneWifi to operate on various platforms.

BUS Abstraction

The Bus Abstraction layer allows OneWifi to operate on multiple bus technologies. The supported bus technologies include:

• RBUS: The default bus technology in OneWifi. All RDK builds automatically include RBUS unless overridden by specific macro definitions, such as USE_UBUS or USE_HEBUS in makefiles or build scripts.

• DBUS: OneWifi can be built and run on DBUS by enabling the USE_DBUS macro in the makefile or build script.

• UBUS: To build and run OneWifi on UBUS, the USE_UBUS macro should be enabled in the makefile or build script.

• HEBUS: A high-efficiency bus used for high-throughput data transfers between OneWifi and applications that require large volumes of Wi-Fi events data for operating algorithms (e.g., Motion Detection). This can be enabled using the USE_HEBUS macro

OS Abstraction

The OS Abstraction layer allows OneWifi to run across multiple operating systems. Currently supported operating systems include:

• RDK
• Linux

The OneWifi process is multi-threaded, as depicted in below diagram. The various threads communicate with one another through a priority-enabled events queue to manage their interactions.

Core Thread

The primary thread, referred to as the Core Thread (color-coded in green), is responsible for interacting with lower-layer entities, such as the drivers. This thread serializes all interactions with the driver, whether they occur in the control plane or the statistics plane. Additionally, the Core Thread is tasked with publishing statistical data to Wi-Fi applications at the required periodicity, as specified by the applications.

Stats Orchestration Thread

The Stats Orchestration Thread (color-coded in yellow) handles the orchestration of statistics and event requirements for all registered Wi-Fi applications. It maintains a stats cache, which is periodically updated by the Core Thread, and organizes the stats data into specific buckets according to the needs of the registered applications.

Data Model Thread

The Data Model Thread (color-coded in pink) is responsible for maintaining a data model cache, which is updated by the Core Thread whenever operational data changes. The cache is also updated in response to any changes in statistics. This thread implements the handler functions for the data model's SET and GET operations.

HAL Events Thread

The HAL Events Thread (color-coded in sky blue) remains dormant until an event or management frame is received. Upon activation, this thread submits the event or frame to the Core Thread for further processing.

Operating Modes & Data Model