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, 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:
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.
