Page History

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

OneWifi Internal ArchitectureArchitecture 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 SDK and interacts the Software Development Kit (SDK). It primarily interfaces with the baseband hardware primarily for to perform lower MAC functionalities such as(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 for upper layer software entities to execute SoC the above diagram, provides an abstraction layer that enables upper-layer software components to perform SoC-independent function calls. Most of the implementation of this layer is architected with OpenSource software like This layer is largely built using open-source software such 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 needs to 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, is the heart and soul of OneWifi stack. This entity is responsible for interacting with the above diagram, acts as the central component of the OneWifi stack. It interfaces with the Wi-Fi driver via through the HAL abstraction layer as far as the control plane and stats plane is concerned. The layer for both control and statistics planes. The Core Controller serializes all configuration and stats statistics-related queries to the driver, ensuring a serialized driver 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 of the above diagram, serves as a registry for Wi-Fi applications that can register with requirements of events, stats, periodicity of stats etc. The framework facilitates easy access to. 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
• Synchronous Both synchronous and asynchronous events
• Statistics, counters, and telemetry data

OneWifi Applications Framework

The high-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 capability their capabilities, and start begin receiving events and statistics from the core components of the OneWifi stack and thereby algorithms in application can take appropriate course of actions. A wide of variety type of applications . 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, some of the categories areincluding:

• 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 that . This layer 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:

• RDK
• OpenWrt
• Linux

Multi-Threaded Model

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 priority enabled events queue, 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 (, such as the drivers etc. ). This thread serializes all interactions with the driver, whether they occur in the interaction is in control plane or stats the 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) is responsible for orchestrating stats and events requirements across handles the orchestration of statistics and event requirements for all registered Wi-Fi applications. The thread It maintains a stats cache that , which is periodically updated by the Core thread. The thread is responsible for organizing stats data in buckets as required by registered Wi-Fi Thread, and organizes the stats data into 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 Thread whenever a change in operational data occurschanges. The cache is also updated as and when some stats changein response to any changes in statistics. This thread is implements the handler implementation of functions for the data model's SET and GET functions operations.

HAL Events Thread

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

Operating Modes & Data Model