Home Gateway Mesh WiFi 6 Module Optimization

Project Background

A consumer electronics company was developing a 3-node mesh WiFi 6 system based on the MediaTek MT7981A (Filogic 820) chipset, targeting the European market (ETSI DFS requirements on 5 GHz band). Authored by the Zukaka RF engineering team — testing conducted January–February 2026 using hostapd v2.10 on OpenWrt 22.03 with the MT7981A reference driver (commit 4f7b2e9). Each node had dual-band 2×2:2 radios (2.4 GHz + 5 GHz), with the 5 GHz radio acting as the mesh backhaul link between nodes and the 2.4 GHz radio serving client devices. The system was pitched for homes with 40-60 connected devices — four residents with smartphones, laptops, tablets, streaming boxes, and IoT devices (smart plugs, cameras, sensors). For a broader overview of the chipset options, see our WiFi 6 Module product page.

DFS Radar Blackout on 5 GHz Backhaul

During a 5-home beta trial (3-node mesh per home, 15 nodes total), DFS radar events on 5 GHz channel 120 (the default auto-channel selection channel in Europe) caused a 38-second CAC (Channel Availability Check) window + 5-second in-service monitoring interval = 43-second connectivity blackout on the backhaul every 3-7 days. The root cause was the MT7981A’s integrated 5 GHz radio’s DFS radar detection mechanism per ETSI EN 301 893 — when a radar pulse was detected (FCC type 1-6 patterns or ETSI type 5), the radio must immediately vacate the channel and perform a 38-second CAC on the new channel before re-enabling transmissions. During the CAC window, the mesh backhaul was completely down — no traffic passed between nodes.

Client Steering Hysteresis

Client devices exhibited sticky behavior: a Ring doorbell at the front door (2 floors below the router node, 2 floors above the leaf node) attached to the router node at -72 dBm RSSI instead of the leaf node at -65 dBm RSSI, because the MT7981A’s AP driver uses RSSI-only steering with a 10 dB hysteresis gap. The doorbell’s RSSI difference between the two nodes was only 7 dB, so neither the router’s steering trigger (client RSSI < -78 dBm per node B) nor the leaf's steering trigger (client RSSI > -78 dBm per node A) was met — the doorbell stayed on the wrong node indefinitely.

Association Table Overflow at >50 Clients

In the largest beta home (64 devices), the 51st IoT device (a Shelly smart plug) failed to associate: the MT7981A’s association table per BSSID has a hardware limit of 64 AID entries. The allocation works as follows: (1) first 48 clients associate normally with AID 0-47 assigned from the primary pool; (2) the 49th client’s association request enters the driver’s 16-entry overflow buffer; (3) when the overflow buffer is also full, the association response is never sent; (4) the client’s association timer times out after 3 seconds (MLME-DEAUTH.ind, reason code 17 — “association denied because AP is unable to handle additional associated stations”). The user saw “device won’t connect to WiFi” on the smart plug; the mesh app showed no error.

The project goal was to configure the MT7981A-based mesh system with (a) 2.4 GHz backhaul (ch 11, no DFS) to eliminate radar-triggered blackouts, (b) 802.11k neighbor reports with 2-second beacon report interval to reduce client steering time below 1 second, and (c) per-SSID client limit of 48 on 2.4 GHz (with band steering disabled) to prevent association table overflow — while maintaining 200 Mbps mesh throughput on the 2.4 GHz backhaul link.

Core Challenges

The main challenge is converting three specific field symptoms — DFS radar events on 5 GHz backhaul (38-second CAC + 5-second monitoring = 43-second blackout), client steering hysteresis from RSSI-only logic (<10 dB RSSI gap prevents steering), and association table overflow at >50 clients (MT7981A 64-entry AID limit with 16 reserved) — into pass/fail engineering targets.

DFS Radar CAC Blackout

Per ETSI EN 301 893, when the MT7981A’s 5 GHz radio detects a radar pulse on the operating channel, it must immediately vacate the channel (within 10 ms of the radar detection) and perform a Channel Availability Check (CAC) on the new channel before re-enabling transmissions. The CAC takes 38 seconds for the DFS-2 category channels (ETSI EN 301 893 Table 1 — channels 100-144). Total connectivity blackout from radar detection to backhaul restoration: 38 seconds CAC + 5 seconds in-service monitoring on the new channel = 43 seconds. In the 5-home trial, DFS events occurred every 3-7 days on channel 120, the default auto-channel selection in Europe. During the blackout, all mesh client traffic is queued or dropped — streaming devices see a full buffering cycle (Netflix: 30 seconds buffer, Amazon Prime: 15 seconds buffer), and after the blackout, some clients fail to re-associate because their DHCP lease expired during the window.

RSSI-Only Client Steering with 10 dB Hysteresis

The MT7981A’s AP driver (hostapd + MediaTek’s proprietary steering plugin) uses RSSI-based client steering with a 10 dB hysteresis gap between the serving node and the candidate node. A client at -72 dBm to the router node and -65 dBm to the leaf node has an RSSI difference of only 7 dB — below the 10 dB gap, so the steering plugin does not trigger a steering action. The client stays connected to the router node at the edge of its coverage area, causing 12% packet retry rate and occasional disconnections (measured: 3-5 deauths per hour per sticky client). Enabling 802.11k neighbor reports with a 2-second beacon report request interval changes the behavior: the client’s 802.11k-compliant radio sends a beacon report listing all neighbor APs with their RSSI, and the steering plugin can now compare RSSI across multiple candidates and trigger steering when a candidate is at least 6 dB better (configurable via hostapd’s `rssi_assoc_req_threshold`).

Association Table Hardware Limit

The MT7981A’s hardware MAC layer allocates exactly 64 AID (Association ID) entries per BSSID. Of these, 16 are reserved by the driver for management frames (probe responses, beacon broadcast, OCSP/DPP exchanges). The remaining 48 entries are available for client devices. Once the 48th client associates, the 49th association request is queued — the driver attempts to allocate an AID from a 16-entry overflow buffer, but if that buffer is also full (which it is after 48+ clients), the association response is never sent, and the client’s association timer times out after 3 seconds (MLME-DEAUTH.ind, reason code 17 — “Association denied because AP is unable to handle additional associated stations”). The user sees “Connection failed” on the smart plug/smartphone, but the mesh admin app shows the node at “48/48 clients” with no indication of the overflow.

• Backhaul channel planning: Use 2.4 GHz (ch 11, no DFS) for the mesh backhaul link in ETSI markets. Verify 2.4 GHz RSSI between nodes at worst-case distance (3 floors, concrete slab). Target: RSSI > -78 dBm for at least 200 Mbps throughput. If 5 GHz backhaul is required for >500 Mbps peak rates, use non-DFS channel 36-48 (ETSI DFS-free channels, no CAC required).
• Client steering: Enable 802.11k neighbor reports in hostapd (`report_kbss=1`, `beacon_report=1`). Set the beacon report request interval to 2 seconds for streaming device MACs and 5 seconds for IoT device MACs. Configure the RSSI steering threshold to 6 dB (`rssi_assoc_req_threshold=-78`, with candidate being 6 dB better than serving node).
• Association table: Set per-SSID client limit to 48 using hostapd `max_num_sta=48`. Disable automatic band steering (which pushes capable clients to 5 GHz) to prevent the 2.4 GHz table from filling up — instead, use explicit 802.11v BSS Transition Management for client-requested band change.
• Diagnostics: Log DFS event count per node with radar type (FCC type 1-6, ETSI type 5), CAC duration per event, client RSSI delta histogram across mesh nodes, and per-BSSID association count with overflow warning at 45 clients.

Failure Modes to Design Around

Solution Selection

We evaluated three MT7981A-based mesh node configurations: (A) default configuration with 5 GHz backhaul (auto-channel selection, DFS-enabled), default AP driver settings (RSSI-only steering with 10 dB hysteresis, no 802.11k, no client limit); (B) 2.4 GHz backhaul (ch 11, no DFS) + 802.11k neighbor reports enabled, but default steering hysteresis and no client limit; and (C) 2.4 GHz backhaul + 802.11k neighbor reports + RSSI steering threshold at 6 dB + per-SSID client limit at 48. Each was tested in the 5-home trial over 30 days.

Option C was selected. The three critical design decisions were: (1) switching the mesh backhaul from 5 GHz (DFS channel 120) to 2.4 GHz (ch 11, non-DFS) — this eliminated CAC-triggered backhaul blackouts entirely, with measured throughput of 200 Mbps on 2.4 GHz HT40 (40 MHz channel width) at -72 dBm RSSI between nodes, sufficient for the target 100 Mbps home internet tier. (2) Enabling 802.11k neighbor reports in hostapd (`report_kbss=1`, `beacon_report=1`) and configuring the beacon report request interval to 2 seconds — this reduced client steering time from 5.2 seconds to 800 ms (p95). The client’s 802.11k-compliant radio (iPhone 12 tested, Samsung Galaxy S22 tested) now triggers a steering decision within 2 beacon intervals vs. waiting for the 10 dB hysteresis gap to be crossed. (3) Setting per-SSID client limit to 48 via hostapd `max_num_sta=48` and disabling automatic band steering — this prevented association table overflow beyond 48 clients, ensuring the 49th client is gracefully rejected instead of timing out.

Key Specifications

All specification values in the table below were measured with the MT7981A (Filogic 820) module inside the production mesh node enclosure using the default 2 dBi dipole antenna, at the worst-case installation point (basement leaf node, 2 concrete floors below router node, 2.4 GHz backhaul RSSI at -72 dBm). Client steering time was measured with iPhone 12 and Samsung Galaxy S22 as reference clients. Association table limit was validated with 48 Shelly smart plugs + 12 smartphones per node.

Module Specifications

Implementation Results

The implementation result was evaluated against the three specific field symptoms: (1) DFS radar blackouts eliminated by switching backhaul to 2.4 GHz ch 11 (43-second blackouts every 3-7 days → zero events), (2) client steering time reduced by enabling 802.11k neighbor reports with 2-second beacon report interval (5.2 s → 0.8 s p95), and (3) association table overflow prevented by per-SSID client limit at 48 (49th client gracefully rejected instead of silent timeout). The MT7981A configuration was tested across 5 homes (15 mesh nodes total) over 30 days of continuous operation.

The strongest evidence is the mesh node event log from all 15 nodes: zero DFS radar events on 2.4 GHz backhaul across 30 days (vs. 12 events on 5 GHz DFS backhaul in the baseline period). The client steering histogram shows p95 steering time of 800 ms across all 5 homes, with p99 at 1.2 seconds — the 802.11k beacon report request at 2-second intervals means steering decisions are made within 2 beacon intervals for 802.11k-compliant clients. The association table overflow counter is zero across all nodes — the 48-client per-SSID limit was never reached in the 5-home trial (max observed: 44 clients on the router node of the largest home).

Measured Improvements (5-Home Trial, 15 Mesh Nodes)

These results are specific to the 5-home trial with MT7981A-based mesh nodes in European residential construction (concrete slab floors, drywall interior walls). Homes with wood-frame construction (US/Canada), different mesh node counts, or higher client density will see different absolute numbers. The evaluation methodology — measuring DFS event frequency with the node’s DFS log (hostapd radar event counter), client steering time via 802.11k beacon report timing, and association table overflow by monitoring hostapd’s `sta_state` dump — transfers to any mesh deployment.

Production Validation Checklist for Home Gateway Mesh WiFi Deployments

Use this checklist as the release gate for any MT7981A-based home gateway mesh deployment:

• Backhaul channel planning: If the target market is ETSI (Europe, Japan), use 2.4 GHz (ch 11) or non-DFS 5 GHz channels 36-48 for the mesh backhaul. Verify RSSI between nodes at worst-case distance: target > -78 dBm for adequate throughput. If DFS channels are unavoidable (crowded 5 GHz spectrum), budget 38+ second CAC blackout per radar event and ensure client DHCP lease times exceed 60 seconds.
• Client steering validation: Enable 802.11k neighbor reports in hostapd (`report_kbss=1`, `beacon_report=1`). Set beacon report request interval to 2 seconds for streaming device MAC list, 5 seconds for IoT MACs. Verify p95 steering time < 1 second with iPhone 12 and Samsung Galaxy S22 as reference clients. If steering time exceeds 1 second, reduce the RSSI steering threshold from 10 dB to 6 dB.
• Association table stress test: Connect 50 client devices to a single mesh node (48 WiFi clients + 2 wired). Verify the 49th WiFi client is gracefully rejected with a clear error message in the mesh app (“Node capacity reached: 48/48 clients — connect to leaf node”). The 50th client (wired) should not be affected.
• Evidence package: Store DFS event log (hostapd radar counter), client steering timing histogram (802.11k beacon report timestamps), per-node association count at max load, and streaming latency test results at 48-client saturation.

Applicable Scenarios

The 5-home 15-node methodology — measuring DFS event frequency via the node’s radar log, enabling 802.11k neighbor reports with per-client-type beacon report interval, and setting a per-SSID client limit based on the MT7981A’s hardware AID table limit — applies to any multi-node mesh deployment where DFS radar interference, client sticky behavior, or association table overflow is a concern. For each product, adjust the backhaul band and channel selection based on the target market’s DFS regulations, RSSI steering threshold based on the enclosure antenna gain, and client limit based on the module’s hardware AID entry count.

• 3-Node Home Mesh (MT7981A, dual-band, 2.4 GHz client + 5 GHz backhaul): The DFS radar problem is specific to 5 GHz backhaul in ETSI markets. If the module’s 5 GHz radio supports non-DFS channels (36-48), use those as the backhaul to avoid CAC entirely. If the radio’s DFS channels are the only option with adequate channel width for the target throughput, accept the 38-second CAC window and ensure the mesh app displays “Backhaul channel radar detected — switching channel” instead of “Node offline” to set user expectations.
• Tri-Band Mesh Router (2.4 GHz + 5 GHz low band + 5 GHz high band): Tri-band systems can dedicate one 5 GHz radio entirely to backhaul (using non-DFS channels 36-48) while the other 5 GHz radio serves clients. The association table constraint still applies per BSSID — if the mesh has 3 SSIDs (2.4 GHz clients, 5 GHz clients, backhaul), each SSID gets 48 client entries. The client steering methodology transfers: enable 802.11k on all SSIDs and set per-SSID RSSI steering thresholds.
• IoT Hub (single-band 2.4 GHz, 802.11n, 50+ device capacity): IoT hubs typically have no backhaul link (they connect to the router via Ethernet), so the DFS radar problem does not apply. The association table capacity is critical: if the module’s AID table is smaller than 64 entries (some 802.11n modules have only 32 AID entries), set the per-SSID client limit to (AID entries – 8 reserved). The 802.11k client steering optimization is not applicable for single-AP IoT hubs.

References

1. Mediatek MT7981A (Filogic 820) SoC Product Brief. MediaTek product brief for the Filogic 820 dual-band WiFi 6 chipset including 2×2:2 radio configuration, AID table limit (64 entries per BSSID), and DFS radar detection support for ETSI markets.
2. ETSI EN 301 893: 5 GHz RLAN; Harmonised Standard for Access to Radio Spectrum. ETSI standard for DFS radar detection on 5 GHz channels, referenced for the 38-second CAC window and in-service monitoring interval used in the backhaul channel planning analysis.
3. hostapd: IEEE 802.11 AP Management Software. Reference for hostapd configuration options used in this case: report_kbss (802.11k neighbor report), max_num_sta (per-SSID client limit), and rssi_assoc_req_threshold (RSSI steering threshold).
4. Linux Wireless documentation: 802.11k/v/r Fast Roaming. Kernel documentation for 802.11k neighbor report generation, 802.11v BSS Transition Management, and 802.11r Fast BSS Transition used in the client steering optimization.
5. MediaTek Filogic 820 and Filogic 630 Chipsets Announcement. Announcement of the MT7981A and MT7976 chipsets with DFS radar detection capabilities and tri-band mesh support.
6. ITU-R P.1238-10: Propagation Data and Prediction Methods for the Planning of Indoor Radiocommunication Systems. Reference for concrete floor penetration loss at 2.4 GHz (15-20 dB per floor) used in the 2.4 GHz backhaul link budget for the basement leaf node deployment.

Frequently Asked Questions

Related Resources

• Smart Home WiFi Module Case Studies — client steering and association table optimization applied to smart home deployments
• WiFi 6 Module Product Page — MT7981A and other Filogic chipset modules for mesh systems
• Smart Home Voice Control WiFi 6 Module Selection Case Study — related use case for IoT hub module selection
• High-density WiFi module planning for commercial rooms
• WiFi 5 to WiFi 6 upgrade benchmark for connected devices