OneWifi was developed to address the architectural challenges encountered during the development of Wi-Fi features and the field deployment of its predecessor, CcspWifiAgent. The earlier Wi-Fi stack was an overlay of multiple Wi-Fi processes, as illustrated on the left side of Figure 1. The CcspWifiAgent and Wireless Manager processes functioned as independent configuration components of Wi-Fi parameters, leading to significant synchronization issues between states and data. A dedicated process, the Mesh Agent, served as the synchronizing entity. If any detrimental events affected the Mesh Agent, the two processes would often become misaligned. In addition to these synchronization challenges, the Stats Manager and Band Steering Manager introduced further complexity within the Wi-Fi stack. The numerous interfaces between the Wi-Fi driver and the baseband resulted in reentrancy issues. Beyond synchronization and reentrancy challenges, other serious problems included persistent storage difficulties, a substantial amount of vendor-specific proprietary code, and inadequate debugging and triaging tools.

Wi-Fi Driver

The Wi-Fi driver, depicted in [1] of Figure 2: OneWifi Internal Architecture, is provided by the SoC vendor as part of the SDK. It primarily interacts with the baseband hardware to perform lower MAC functionalities, including:

• Downlink scheduling
• Frame acknowledgements and retransmissions
• Frames Integrity checks and Encryption/Decryption

Wi-Fi HAL

The Wi-Fi HAL Layer, depicted in [2] of Figure 2: OneWifi Internal Architecture, implements abstraction functionalities that allows upper-layer software entities to execute SoC independent function calls. Most of the layer's implementation is architected using open-source software such as HostAp and cfg80211/netlink80211 libraries. If the vendor provided driver is cfg80211 compliant, the existing HAL implementation should work seamlessly to provide all abstraction functionalities to upper layer. In case the driver is not compliant, the vendor must implement the HAL functions specified in HAL Specifications 3.0.

Wi-Fi Core Controller

The Wi-Fi Core Controller, depicted in [3] of Figure 2: OneWifi Internal Architecture, serves as the core component of the OneWifi stack. This entity is responsible for interacting with Wi-Fi driver via HAL abstraction layer for both the control and stats planes. The layer serializes all configuration and stats related queries to the driver, ensuring a serialized access and thus preventing multiple reentrancy related issues.

Services Framework

Services framework, depicted in [4] of Figure 2: OneWifi Internal Architecture, provides ability to create, configure and modify Wi-Fi Virtual Access Point Services (Wi-Fi Networks). The types of network services that can be created are listed below.

• Private for typical consumer usages
• Public Hotspot for café or public venues
• Configurator for onboarding client devices onto the Wi-Fi network
• Special Services like operator-controlled client devices like streaming devices
• Backhaul for Mesh Extenders

Wi-Fi Apps Framework

The Wi-Fi Applications framework, depicted in [5] of Figure 2: OneWifi Internal Architecture, is a registrar for Wi-Fi applications that can register their requirements for events, stats, periodicity of stats etc. The framework facilitates easy access to:

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

The high-level architecture of the technology is depicted in Figure 3: OneWifi Applications Framework. Applications can register with the framework specifying their capabilities and start receiving events and statistics from core components of OneWifi stack. This enables the algorithms within the applications to take appropriate actions based on real-time data. A wide of variety of application types are currently supported and tested, including:

• Device onboarding & provisioning
• Wi-Fi health monitoring
• Device finger printing
• Motion detection
• Client connections management
• Mesh technologies application

Applications can either be integral part of OneWifi process or can be executing as a process running in the CPE external to OneWifi in which case the framework creates a virtual adapter that facilitates seamless data communication between the stack and the application.

In case, the Wi-Fi application executes as a process outside OneWifi process, as the above Figure 4: External Apps and OneWifi Communication depicts, RBUS facilitates all categories of data exchanges between OneWifi stack and the application.

Data Model Manager

Data model manager, depicted in [6] of Figure 2: OneWifi Internal Architecture is an abstraction of various Wi-Fi data model specifications such as TR-181 or WFA MultiAP Data Elements or BBF Data models. This module also abstracts database technology used by OneWifi for persistent storage purposes.

Data Model Abstraction

Two main data model specifications are supported by OneWifi.

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

Database Abstraction

OneWifi needs to store configuration, RFC and some other operational parameters persistently. To achieve that, OneWifi uses a database abstraction layer that hides the intricacies of use of different relational database. This abstraction layer can work with any database like MySQL, OVS or Postgress that might be the deployed database technology of customer. OneWifi uses OVS database as its persistent storage mechanism.

Platform Manager

Platform manager, depicted in [6] of Figure 2: OneWifi Internal Architecture abstracts platform specific intricacies and differences.

BUS Abstraction

Bus abstraction enables OneWifi run on multiple bus technologies. Current supported bus technologies are

RBUS

RBUS is the default working bus technology in OneWifi. All RDK builds automatically include RBUS as default unless overridden by macro definitions like USE_UBUS or USE_HEBUS in make files or build scripts.

DBUS

Enable macro definition namely USE_DBUS in make file or build script to build and run OneWifi version on DBUS.

UBUS

Enable macro definition namely USE_UBUS in make file or build script to build and run OneWifi version on UBUS.

HEBUS

This is a high efficiency bus that enables high throughput data transfer mechanism between OneWifi and any application that requires high volume of Wi-Fi events data for its operating algorithm (e.g. Motion application). This can be enabled by using macro definition namely USE_HEBUS.

OS Abstraction

Abstracting OS specific functionalities allows OneWifi to run on multiple Operating Systems. Currently supported Operating Systems are

• RDK
• OpenWrt
• Linux

OneWifi process is multi-threaded. A color-coded model of the different threads is depicted in Figure 5: Threads in OneWifi. The different threads communicate with each other via a priority-enabled events queue.

Core Thread

The main thread is the Core thread (color-coded in green) that is responsible for interacting with lower layer entities (drivers etc.). This thread serializes all interactions with the driver whether the interaction is in the control plane or the stats plane. This thread is also responsible for publishing stats data to Wi-Fi applications at periodicity required by the applications.

Stats Orchestration Thread

The stats orchestration thread (color-coded in yellow) manages the orchestrating of stats and event requirements across all registered Wi-Fi applications. It maintains a stats cache that is periodically updated by the Core thread and organizes stats data into buckets as specified by the registered applications.

Data Model Thread

The data model thread (color-coded in pink) is responsible for maintaining a data model cache that is updated by the Core Thread whenever operational data changes. The cache is also updated in response to any changes in stats. This thread implements the handler function 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 occurs, or a management frame is received. Upon activation, it submits the event or frame to the Core Thread for further processing.

Operating Modes & Data Model