OpenWiFi AP NOS Architecture Explained

As WiFi continues to evolve from traditional consumer use to enterprise-grade, carrier-managed infrastructure, OpenWiFi—a Telecom Infra Project (TIP) initiative—emerges as a game-changer. It offers a fully open-source, disaggregated stack for WiFi networks, combining whitebox hardware with a flexible, cloud-native Network Operating System (NOS) architecture.

In this blog, we dive deep into the AP NOS architecture of OpenWiFi and explore how it enables seamless cloud control, customization, and scalability.

What is an OpenWiFi AP NOS?

An Access Point Network Operating System (AP NOS) is the software stack that runs on wireless APs, managing everything from bootloaders and network services to advanced control and telemetry mechanisms. In the case of OpenWiFi, this NOS is built on OpenWrt, augmented by the uCentral client, specialized scripts, and OpenWiFi-specific extensions. You can think of it as an OpenWrt-based network operating system.

Layered Architecture of the OpenWiFi AP NOS

The architecture is modular and layered, which allows developers to customize components based on hardware and use case requirements. Here’s a breakdown of the layers:

1. Bootloader Layer

• Typically uses U-Boot or CFE.

• Responsible for initializing hardware and loading the kernel.

• Can include recovery mode and secure boot features.

2. Kernel Layer

• Based on a Linux kernel, often optimized for embedded devices.

• Manages memory, scheduling, and low-level networking tasks.

• Includes support for WiFi chipsets like MediaTek, Qualcomm, etc.

3. Root Filesystem (RootFS)

• Built on OpenWrt, using BusyBox, UCI, and procd.

• UCI (Unified Configuration Interface) handles structured configs (/etc/config).

• Offers robust CLI tools and scripting capabilities via ucode.

4. Networking & Services Layer

• Includes hostapd, dnsmasq, firewall, netifd, and iptables.

• Manages:

  • Wireless radios

  • IP assignment

  • DHCP/DNS

  • NAT and firewall rules

• Extensions like qosify, atfpolicy, rrmd, and usteer offer enhanced network control.

5. uCentral Agent (NOS Control Core)

• The beating heart of the OpenWiFi AP NOS.

• Communicates with the cloud via secure WebSockets.

• Handles commands like:

  • configure: Apply full JSON-based configurations

  • telemetry: Send stats and health data

  • rrm: Radio Resource Management (e.g., channel changes, client steering)

• Scripts like ucentral.uc, cmd.uc, telemetry.uc execute commands via ubus, uci, and system services​​.

How Configuration Propagation Works in OpenWiFi

The cloud sends a JSON-RPC command, such as configure, over WebSocket. The ucentral-client:

1. Stores the config in /etc/ucentral/ucentral.cfg.<UUID>

2. Runs the ucentral.uc script:

   • Validates config against a schema

   • Renders it into a UCI batch file

   • Applies it using uci CLI

   • Restarts necessary services

   • Syncs state using ubus call state reload

3. Responds back with success or failure over WebSocket.

This process allows real-time, zero-touch provisioning and updates​.

Telemetry & Monitoring Built In

OpenWiFi telemetry and monitoring uses scripts like telemetry.uc and state.uc, the NOS collects:

• CPU, memory, temperature

• Client stats

• Signal strength, channel utilization

• VLAN, interface, and LLDP data

• PoE, captive portal, and mesh status

It stores this in /tmp/ucentral.telemetry and periodically transmits it to the controller for monitoring and analytics​.

Security and Certificate Management

The OpenWiFi AP NOS handles secure WiFi provisioning using a preloaded certificate bundle:

• /certificates/key.pem: Private key

• /certificates/cert.pem: Device certificate

• /certificates/gateway.json: Controller configuration

This bundle is validated on boot or factory reset, and plays a central role in secure device onboarding​.

uCentral Feed Packages

Here’s a sample of the packages that make up the AP NOS:

These integrate with OpenWrt using the feeds system, allowing you to include or exclude components during build time​​.

Building and Extending the NOS

The NOS can be customized using the OpenWiFi build system:

• Clone wlan-ap repo

• Use gen_config.py to apply your device profile

• Apply patches if needed (e.g., for GL-MT6000 support)

• Build firmware using make -j$(nproc) after setting your .config​

Final Thoughts

OpenWiFi’s AP NOS architecture is cloud-native, disaggregated, and extensible—designed for modern WiFi deployments that require flexibility, telemetry, and open control. Our OpenWiFI Solution is a great way for any ISP or enterprise to roll out managed WiFi.

Whether you’re an OEM integrating new hardware, a system integrator deploying large-scale networks, or a developer hacking on new features, OpenWiFi’s AP NOS gives you full stack visibility and control, from bootloader to cloud dashboard.