Page History

OneWifi was created developed to resolve address the architectural problems and issues challenges encountered during the development of Wi-Fi features development and the field deployment of its predecessor, CcspWifiAgent. The earlier Wi-Fi stack was an overlay of multiple Wi-Fi processes, as seen in illustrated on the left side of the above Figure 1. The CcspWifiAgent and Wireless Manager processes being functioned as independent configuration components of Wi-Fi parameters, posed leading to significant synchronization issues in synchronizing the between states and data. A dedicated process, the Mesh Agent was , served as the synchronizer synchronizing entity. In case of anything detrimental happening to If any detrimental events affected the Mesh Agent, the two processes would be frequently out of sync. Along with thatoften become misaligned. In addition to these synchronization challenges, the Stats Manager and Band Steering Manager being the other two entities of introduced further complexity within 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 resulted in reentrancy issues. Apart from the Beyond synchronization and reentrancy issueschallenges, there were other serious problems related to included persistent storage difficulties, huge a substantial amount of vendor-specific proprietary code, and poor inadequate debugging , and triaging toolingstools.

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 and . It primarily interacts with the baseband hardware primarily for to perform lower MAC functionalities such as, 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 for that allows upper-layer software entities to execute SoC independent function calls. Most of the layer's implementation of this layer is architected with OpenSource software like 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 needs to 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, is the heart and soul of serves as the core component of the OneWifi stack. This entity is responsible for interacting with Wi-Fi driver via HAL abstraction layer as far as for both the control plane and stats plane is concernedplanes. The layer serializes all configuration and stats related queries to the driver, ensuring a serialized driver 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 of for Wi-Fi applications that can register with their requirements of 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

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

• 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) is responsible for manages the orchestrating of stats and events event requirements across all registered Wi-Fi applications. The thread It maintains a stats cache that is periodically updated by the Core thread . The thread is responsible for organizing and organizes stats data in into buckets as required specified by the registered Wi-Fi 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 Thread whenever a change in operational data occurschanges. The cache is also updated as and when some stats changein response to any changes in stats. This thread is implements the handler implementation of function for the data model's SET and GET functionsoperations.

HAL Events Thread

The HAL 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, it submits the event or frame to the Core threadThread for further processing.

Operating Modes & Data Model