Page History

Overview of OneWifi's Architecture and Design Evolution

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

A dedicated process, the Mesh Agent, was the synchronizer entity. In case of anything detrimental happening to used to synchronize these components. However, if any adverse events impacted the Mesh Agent, the two synchronization between the processes would often become misaligned.

In addition to these synchronization challenges be frequently out of sync. Along with that, the Stats Manager and Band Steering Manager being the other two entities of introduced further complexity to the Wi-Fi stack, the interfaces to and from . The numerous interfaces between the Wi-Fi driver and baseband were manyfold and thus caused the baseband also led to reentrancy issues. Apart from the

Beyond synchronization and reentrancy issues, there were other serious problems related to persistent storage, huge amount of vendor proprietary code and poor debugging, triaging toolings.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

• 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

• 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