Wi-Fi Driver
The Wi-Fi driver, depicted in [1] of Figure 2: OneWifi Internal Architecture, is provided by SoC vendor as part of SDK and interacts with the baseband hardware primarily for lower MAC functionalities such as
- 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 upper layer software entities to execute SoC independent function calls. Most of the implementation of this layer is architected with OpenSource software like 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 implement the HAL functions specified in HAL Specifications 3.0.
Wi-Fi Core Controller
Wi-Fi Core Controller, depicted in [3] of Figure 2: OneWifi Internal Architecture, is the heart and soul of OneWifi stack. This entity is responsible for interacting with Wi-Fi driver via HAL abstraction layer as far as the control plane and stats plane is concerned. 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
Wi-Fi Applications framework, depicted in [5] of Figure 2: OneWifi Internal Architecture, is a registrar of Wi-Fi applications that can register with requirements of 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 level architecture of the technology is depicted in Figure 3: OneWifi Applications Framework. Applications can register with the framework specifying capability and start receiving events and statistics from core components of OneWifi stack and thereby algorithms in application can take appropriate course of actions. A wide of variety type of applications are currently supported and tested, some of the categories are:
- 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 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 control plane or 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 orchestrating stats and events requirements across all registered Wi-Fi applications. The thread maintains a stats cache that is periodically updated by the Core thread. The thread is responsible for organizing stats data in buckets as required by 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 Core thread whenever a change in operational data occurs. The cache is also updated as and when some stats change. This thread is the handler implementation of the data model SET and GET functions.
HAL Events Thread
The HAL events thread (color-coded in sky blue) is a dormant thread that is woken up whenever an event occurs, or a management frame is received. The thread is responsible for submitting the event or frame to Core thread.
