Page History

Overview of OneWifi's Architecture and Design Evolution

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

A dedicated process, the Mesh Agent, served as the synchronizing entity. If any detrimental events affected was used to synchronize these components. However, if any adverse events impacted the Mesh Agent, the synchronization between the two processes would often become misaligned.

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

Beyond synchronization and reentrancy challenges, other serious problems included persistent storage difficulties, a substantial amount 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, depicted shown in [1] of Figure 2: OneWifi Internal Architecturethe above diagram, is provided by the SoC vendor as part of the Software Development Kit (SDK). It primarily interacts interfaces with the baseband hardware to perform lower MAC (Medium Access Control) functionalities, including:

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

Wi-Fi HAL (Hardware Abstraction Layer)

The Wi-Fi HAL Layer, depicted represented in [2] of Figure 2: OneWifi Internal Architecture, implements abstraction functionalities that allows the above diagram, provides an abstraction layer that enables upper-layer software entities components to execute perform SoC-independent function calls. Most of the layer's implementation is architected This layer is largely built using open-source software such as as HostAp and cfg80211/netlink80211 libraries.

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

Wi-Fi Core Controller

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

Services Framework

The Services frameworkFramework, depicted illustrated in [4] of Figure 2: OneWifi Internal Architecturethe above diagram, provides ability the capability to create, configure, and modify manage Wi-Fi Virtual Access Point Services (VAP) services, also known as Wi-Fi Networks)networks. The types of network services that can be created are listed below.include:

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

Wi-Fi Apps Applications Framework

The Wi-Fi Applications frameworkFramework, depicted shown in [5] of Figure 2: OneWifi Internal Architecture, is a registrar the above diagram, serves as a registry for Wi-Fi applications that can applications. It allows applications to register their requirements for events, stats, periodicity of stats etc. The framework facilitates easy , such as event notifications, statistics, and periodicity of data collection. This framework provides access to:

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

OneWifi Applications Framework

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

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

• Device onboarding & and provisioning
• Wi-Fi health monitoring
• Device finger printingfingerprinting
• Motion detection
• Client connections connection management
• Mesh technologies applicationtechnology applications

Applications can either be an integral part of the OneWifi process or can be executing as a process running in the CPE external to OneWifi in which case 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.

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 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 managerModel Manager, depicted in [6] of Figure 2: OneWifi Internal Architecture is an abstraction of shown in first diagram, abstracts various Wi-Fi data model specifications such as , including TR-181 or , WFA MultiAP Data Elements or , and BBF Data modelsModels. This module also abstracts manages the database technology used by OneWifi for persistent storage purposes.

Data Model Abstraction

Two OneWifi supports 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 To manage persistent storage of configuration, RFC, and some other operational parameters persistently. To achieve that, OneWifi uses utilizes a database abstraction layer. This layer that hides the intricacies complexities of use of using different relational database. This abstraction layer can databases, allowing OneWifi to work with any database like various database technologies, such as MySQL, OVS or Postgress that might be the deployed database technology of customer, or PostgreSQL. OneWifi uses the OVS database as its primary persistent storage mechanism.

Platform Manager

The Platform managerManager, depicted in [6] of Figure 2: OneWifi Internal Architecture first diagram, abstracts platform-specific intricacies and differences, enabling OneWifi to operate on various platforms.

BUS Abstraction

The Bus abstraction enables OneWifi run Abstraction layer allows OneWifi to operate on multiple bus technologies. Current The supported bus technologies areinclude:

• 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

• 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

Abstracting The OS specific functionalities Abstraction layer allows OneWifi to run on across multiple Operating Systemsoperating systems. Currently supported Operating Systems areoperating systems include:

• RDKOpenWrt
• Linux

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

Stats Orchestration Thread

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

Data Model Thread

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

HAL Events Thread

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

Operating Modes & Data Model