City Edge Gateway Multi-Device WiFi 6 Module Case Study

Project Background

A city municipality was deploying edge gateways in public parks, each gateway serving 40-60 concurrent devices: 30-40 public WiFi users (phones, tablets — web browsing, social media, messaging) and 8-12 security cameras (Hikvision DS-2CD2T47G2, 4 MP, H.265+, streaming at 8 Mbps each). The gateway hardware used a Qualcomm QCA6391 802.11ax 2×2 module (M.2 Key E, PCIe interface) with an IP55 outdoor enclosure. Power was supplied via PoE+ (IEEE 802.3at, 25.5 W max at the power sourcing equipment). The gateway was mounted on a 6 m streetlight pole in the center of the park, with the cameras connected to the gateway’s 4-port PoE+ switch (internal, not pass-through).

Figure 1: City edge gateway deployment topology — QCA6391 module on a 6 m streetlight pole serving 60+ concurrent devices (public WiFi users + security cameras) via PoE+

The 3-site pilot revealed three problems during the first week. First: at 60 clients, the gateway stopped accepting new associations — the 61st client (a Samsung Galaxy S23) showed “WiFi connected but no internet” because the association request was queued in the Linux netlink socket buffer (default rmem_max = 208 kB), which overflowed at ~18,000 packets/sec. The ath11k driver communicates with hostapd via netlink socket (nl80211), and with 60 clients each sending ~300 pps (protocol: ARP, DHCP renew every 24 hours, DNS to the gateway’s upstream resolver, and frequent TCP keepalive to various cloud services), the total netlink data rate was 18,000 pps. At ~100 bytes per netlink message, the buffer filled 208 kB / (60 clients * 300 pps * 100 bytes) = ~115 ms. Once full, the kernel dropped subsequent messages via the `NETLINK_DROP` mechanism, and the driver interpreted the drop as “no more association requests” — stopping all new client associations until the buffer drained. Second: during peak hours (6-9 PM), camera feeds froze every 4-8 seconds. The QCA6391’s OFDMA RU scheduler in the ath11k driver (default: `ieee80211_txq_airtime_check`) allocates RUs proportionally to client count, not traffic priority. With 60 clients, the scheduler cycled through all 60 before returning to the same camera stream — a cycle time of 60 * 16 ms (RU allocation interval) = 960 ms. Each camera needs an RU allocation every 16-32 ms for jitter-free playback; a 960 ms cycle caused 30-60 frame buffer underruns per second. Third: the PoE+ power budget was tight. At peak (60 clients active, 8 cameras streaming, internal switch fully loaded), the gateway drew 21.8 W from the 25.5 W PoE+ budget. On a cold morning (5°C), the enclosure’s 40 mm fan spun at 100% duty cycle, drawing 2 W more, pushing total to 23.8 W — only 1.7 W of headroom. The QCA6391’s +20 dBm TX power per chain at full MCS contributed 3.8 W of the module’s total power draw. Reducing the TX power cap from +20 dBm to +17 dBm saved 1.2 W (from 3.8 W to 2.6 W), bringing peak draw to 20.6 W (vs. 21.8 W) and restoring 4.9 W of headroom — sufficient for the fan at 100% duty cycle.

Core Challenges

The primary failure mode is Linux netlink socket buffer overflow in the ath11k driver. The netlink socket between the kernel’s cfg80211 (via ath11k) and userspace’s hostapd (via nl80211) has a default receive buffer (`rmem_max = 208 kB` per the Linux kernel’s `net.core.rmem_max` sysctl). With 60 clients, each generating ~300 packets per second of management traffic (probe requests, association frames, EAPOL, DHCP, ARP, DNS), the total netlink data rate = 60 * 300 * 100 bytes = 1.8 MB/s. The 208 kB buffer fills in 208 kB / 1.8 MB/s = ~115 ms. The kernel’s netlink message handler (`net/netlink/af_netlink.c`, `netlink_rcv_skb()`) checks `sk_rcvbuf` against the buffer size and, if full, drops the message via `netlink_overrun()` (kernel 5.15+). The ath11k driver’s nl80211 callback (`ath11k_mac_op_sta_state()`) reads the dropped socket status and returns `-ENOBUFS` (no buffer space available) to hostapd, which then rejects the NEW_STATION command. The 61st client sees “association rejected” via MLME-DEAUTH.ind reason code 17. Fix: increase `net.core.rmem_max` to 16 MB (`sysctl -w net.core.rmem_max=16777216`) and enable GRO (Generic Receive Offload) on the wireless interface (`ethtool -K wlan0 gro on`). GRO coalesces multiple small packets into one SKB, reducing the netlink message rate by ~4-8x for TCP traffic — dropping the effective pps from 18,000 to ~3,000-4,500.

The second challenge is OFDMA RU scheduling unfairness between traffic classes. The ath11k driver uses `ieee80211_txq_airtime_check` to schedule OFDMA RUs. In default mode, it allocates RUs proportional to the number of active traffic queues (txqs), without distinguishing between DSCP-marked priority. With 60 clients, each with one active txq, the scheduler cycles through 60 txqs. The RU allocation interval per txq is 16 ms (802.11ax specification: each RU allocation is a trigger frame + HE TB PPDU, ~2.4 ms for the entire MU transmission; with 60 txqs, the scheduler issues a new trigger frame every 16 ms to fill all 60 allocations). Total cycle = 60 * 16 ms = 960 ms. A Hikvision camera with DSCP EF frame marking sends 8 Mbps of video = ~670 frames/second at 1500-byte MTU = 6.7 ms per frame transmission time. The camera’s txq needs an RU allocation every 16-32 ms to maintain the stream. With a 960 ms cycle, the camera’s txq is scheduled once every 60 repeats of the cycle — the camera buffer grows by 8 Mbps * 960 ms = 7.68 Mb between allocations, causing a frame buffer underrun after ~4-8 seconds (the camera’s internal buffer is ~30 frames at 25 fps = 1.2 seconds).

Figure 2: OFDMA RU scheduling comparison — default round-robin (960 ms cycle, camera freezes every 4-8 s) vs. WMM AC priority fix (32 ms cycle, smooth video)

Fix: configure WMM Access Categories (AC) in hostapd with different `txop_limit` for AC_VI (video, DSCP EF) = 3.008 ms vs. AC_BE (best effort, DSCP 0) = 0 (no TXOP). Then set `wmm_ac_vo_aifsn=2` and `wmm_ac_vo_cwmin=3` to give video traffic priority. In the ath11k driver, enable `IEEE80211_HW_AIRTIME_FAIRNESS` but configure it to respect WMM AC priorities: set `airtime_weight` to 128 for AC_VI and 64 for AC_BE. This ensures the camera txq gets RU allocation every 32 ms vs. the public WiFi txqs every 128 ms.

The third challenge is PoE+ power budget. The IEEE 802.3at standard provides 25.5 W at the PSE, with 57 V nominal and 0.6 A max. The cable drop (50 m Cat5e, 12.5 Ω round-trip) loses ~5% = 1.3 W at full load. Available to the gateway: 24.2 W. The gateway’s peak measured draw (60 clients, 8 cameras, internal switch, fan at 50% duty) = 21.8 W, leaving 2.4 W headroom. On a cold morning, the fan at 100% duty adds 2 W = 23.8 W — only 0.4 W headroom, below the recommended 5 W headroom for PoE+ designs (IEEE 802.3at-2009 Section 4.2.4: “The PD design should maintain at least 5 W of headroom to account for cable aging and thermal derating”). The QCA6391’s +20 dBm TX power per chain (2×2:2) draws 3.8 W at max MCS (1024-QAM, 80 MHz). Reducing to +17 dBm (MCS 9 256-QAM) draws 2.6 W — a savings of 1.2 W. Combined with adjusting the fan curve to start at 55°C instead of 40°C (room temp + 15°C transition) reduces average fan duty from 50% to 10% during non-peak hours, saving another 0.8 W. Total headroom restored: 4.9 W.

• Netlink buffer sizing: Calculate the required rmem_max as: (expected_client_count * expected_pps_per_client * avg_message_size_bytes) * 2 (for safety margin). For 60 clients at 300 pps, 100 bytes each, target = 60 * 300 * 100 * 2 = 3.6 MB. Set `net.core.rmem_max=4194304` (4 MB). For 100+ clients, set to 16 MB.
• OFDMA RM scheduling: Configure WMM AC parameters in hostapd: set `wmm_ac_vo_aifsn=2`, `wmm_ac_vo_cwmin=3`, `wmm_ac_vo_txop_limit=3008` (3.008 ms TXOP). Set `wmm_ac_vi_aifsn=2`, `wmm_ac_vi_cwmin=3`, `wmm_ac_vi_txop_limit=1504` (1.504 ms TXOP). Map DSCP EF (46) to AC_VI and DSCP AF41 (34) to AC_VO in the hostapd `dscp_map` configuration.
• PoE+ budget: Calculate the QCA6391’s TX power power draw at the target TX power cap: at +20 dBm, P_radio = 3.8 W; at +17 dBm, P_radio = 2.6 W. Savings of 1.2 W. Ensure total gateway draw + cable drop + 5 W headroom < 25.5 W. If not, reduce the TX power cap or increase the PoE PSE power (PoE++ 802.3bt = 60 W for Type 3, 100 W for Type 4).
• Diagnostics: Log netlink buffer drop counter via `cat /proc/net/netlink` (look at `sk_drops` field), OFDMA scheduling cycle time via tracepoints (`trace:mac80211:mac80211_tx_status`), and PoE+ power draw from the PSE’s LLDP power-over-ethernet TLV.

Failure Modes to Design Around

Solution Selection

We evaluated three configurations of the same Qualcomm QCA6391-based gateway at the 3-site trial. All three used the same hardware — QCA6391 M.2 Key E module on an IP55 outdoor enclosure with dual 5 dBi omni antennas, PoE+ powered. Configuration A was the default Linux kernel + hostapd settings (net.core.rmem_max=208 kB, WMM AC default, TX power cap = +20 dBm). Configuration B applied the netlink buffer fix (rmem_max=4 MB + GRO enabled) and WMM AC priorities (AC_VI txop_limit=3008) but left TX power at +20 dBm. Configuration C applied all three fixes: netlink buffer = 16 MB + GRO, WMM AC priorities, and TX power cap reduced to +17 dBm.

Configuration C was selected. The three fix decisions were: (1) increase `net.core.rmem_max` to 16 MB from 208 kB — this provides an 8x safety margin for netlink buffer overflow risk even at 100+ client loads. GRO further reduces netlink message rate by 4-8x for TCP traffic, effectively eliminating the overflow scenario. (2) Configure WMM Access Categories with AC_VI txop_limit=3008 us and AC_BE txop_limit=0, mapping DSCP EF (46) to AC_VI. This changes the OFDMA RU scheduler behavior from round-robin across 60 txqs to priority-based: AC_VI txqs get allocated within 32 ms (2 trigger frames), while AC_BE txqs get allocated every 128 ms. Camera stream latency dropped from 960 ms max to 32 ms max — no more frame buffer underruns. (3) Reduced TX power cap from +20 dBm to +17 dBm. The 3 dB reduction saves 1.2 W on the QCA6391 (3.8 W → 2.6 W), but reduces the cell radius by ~7% (14 dB path loss for a 3 dB power reduction at the cell edge — but for a park deployment where 95% of clients are within 50 m of the gateway, the cell edge effect is negligible). Measured client RSSI at 50 m went from -68 dBm to -71 dBm — still well above the -82 dBm CCA threshold.

Key Specifications

The specification profile below was measured with the Qualcomm QCA6391 M.2 Key E 802.11ax 2×2 module in the production gateway enclosure, with dual 5 dBi omni antennas, at the worst-case deployment point (60 concurrent clients, 8 cameras streaming DSCP EF at 8 Mbps each, PoE+ 48 V PSE). All values reflect measured performance with Configuration C (rmem_max=16 MB, WMM AC VI txop=3 ms, TX power cap +17 dBm).

Module Specifications

Implementation Results

The implementation result was evaluated against the three specific field problems: (1) 61st client association failure — eliminated by increasing rmem_max from 208 kB to 16 MB and enabling GRO. Netlink socket drop counter (monitored via `/proc/net/netlink` `sk_drops` field) dropped from an average of 120/sec (overflow constantly) to zero across all 60+ clients for the entire 30-day trial. The 61st client (and clients through ~80) now associate without issue. (2) Camera frame freezes every 4-8 seconds — reduced from ~900/hour to ~3/hour by configuring WMM AC_VI txop_limit=3008 us with DSCP EF mapping. The OFDMA RU scheduler now allocates RUs to camera streams within 32 ms, well within the camera’s 1.2-second frame buffer. The ~3 remaining drops per hour were traced to the camera’s own H.265 encoding glitches (confirmed by pulling the camera feed via RTSP directly to VLC — the glitch appeared on the RTSP stream too). (3) PoE+ headroom — restored from 2.4 W to 4.9 W by reducing TX power cap to +17 dBm. Gateway uptime across the 3-site trial was 100% (no reboots caused by power overload), even during the coldest morning (3°C, fan at 100% duty).

Measured Improvements (3-Site Trial, 30 Days)

These results are specific to the 3-site trial with QCA6391-based edge gateways in open municipal park deployments. Sites with different client densities, camera bitrates, or PoE+ cable lengths will see different absolute numbers. The evaluation methodology — monitoring netlink socket drops (`/proc/net/netlink`), OFDMA scheduling cycle time (tracepoints), and PoE+ power draw (PSE LLDP TLV) — transfers to any multi-client edge gateway deployment.

Production Validation Checklist for City Edge Gateway WiFi Deployments

Use this checklist as the release gate for any QCA6391-based city edge gateway deployment:

• Netlink buffer stress test: Connect 60 parallel client devices (use 60 USB WiFi adapters on a test server with mac80211_hwsim, or staging hardware). Generate 300 pps per client (iperf3 -u -b 300K per flow). Monitor `/proc/net/netlink` for `sk_drops`. If any drops are observed, increase `net.core.rmem_max` to 16 MB and enable GRO on the wireless interface.
• OFDMA scheduling validation: With 60 clients generating mixed traffic (30 x DSCP BE iperf TCP, 8 x DSCP EF UDP at 8 Mbps each), capture `trace:mac80211:mac80211_tx_status` and measure the interval between consecutive DSCP EF RU allocations. Target: p95 < 50 ms. If p95 exceeds 50 ms, reduce AC_BE txop_limit to 0 and increase AC_VI txop_limit to 3008 us.
• PoE+ thermal test: Run the gateway at full load (60 clients, 8 cameras streaming) in a temperature chamber at -10°C to +50°C. Monitor PSE power draw via LLDP. Verify peak draw < 24.2 W (25.5 W - 1.3 W cable drop) across the full temperature range. If exceeded (e.g., fan at 100% duty below 0°C), reduce TX power cap by 3 dB (save ~1.2 W).
• Evidence package: Store `/proc/net/netlink` sk_drops counter at peak load, tracepoint capture of OFDMA RU allocation cycle time, PSE LLDP power TLV logs across 48 hours, and camera frame drop count per stream (extract from camera’s RTSP stream metadata or ONVIF event log).

Applicable Scenarios

The QCA6391 is a standard Qualcomm 802.11ax WiFi 6 module used across many edge gateways and consumer APs. The three fixes (netlink buffer, WMM AC priorities, TX power cap) are Linux kernel / hostapd configuration changes that apply to any ath11k-based gateway — not just this specific QCA6391 implementation. For each deployment, recalculate the rmem_max based on expected client pps, adjust WMM AC txop_limit based on the target latency for DSCP-marked traffic, and calculate the PoE+ budget with the actual cable length and TX power cap.

• Multi-tenant Office WiFi (Ubiquiti UniFi/Linux-based AP, 50-100 clients): The netlink buffer overflow is a known issue on Linux-based APs running hostapd with 50+ clients. The fix is the same: increase rmem_max to 16 MB and enable GRO. Most enterprise APs (Ubiquiti, MikroTik, Ruckus) run Linux — check whether the vendor exposes `net.core.rmem_max` sysctl; if not, request it as a firmware feature. The OFDMA RU scheduling fix (WMM AC txop_limit) is supported by OpenWrt and upstream hostapd v2.10+.
• Smart City Poles (IoT gateways on streetlight poles, 30-50 clients, mixed IoT + camera traffic): Same netlink buffer issue applies. The DSCP-based WMM AC priorities are especially critical: IoT traffic (small, bursty MQTT/CoAP packets) is mapped to AC_BE (or AC_VI if time-critical), while camera streams need AC_VI. Configure the IoT device firmware to set DSCP AF41 (34) for time-critical sensor data or DSCP CS3 (24) for normal data. The PoE+ budget calculation should account for the gateway’s internal PoE switch draw (4 cameras on PoE+) — budget 7 W for the gateway + 4 * (camera draw + cable loss).
• Rural WISP CPE (single AP serving 20-40 clients over 5 GHz PtMP): The QCA6391’s +20 dBm TX power may be needed for the 5 GHz PtMP link (vs. reduced to +17 dBm for power savings). In this case, PoE+ headroom is less critical because the CPE is typically PoE-powered at 30-60 W (802.3af/at/bt). The netlink buffer fix still applies. The OFDMA RU scheduling fix may require DSCP marking from the CPE’s clients — if clients don’t mark DSCP, configure the gateway’s WMM AC to trust DSCP from the wired VLAN (upstream router) instead.

References

1. Qualcomm QCA6391 Product Brief. Qualcomm product brief for the QCA6391 2×2 802.11ax WiFi 6 module with PCIe interface. Referenced for module specifications, TX power, and power draw figures.
2. Linux ath11k Driver Source (Mainline Kernel). Mainline Linux kernel ath11k driver source including nl80211 callbacks, netlink socket management, and OFDMA RU scheduling via ieee80211_txq_airtime_check. Referenced for the netlink buffer overflow analysis and WMM AC airtime_weight configuration.
3. hostapd Configuration File Reference. hostapd configuration reference for WMM Access Category parameters (wmm_ac_vo/vi_aifsn, cwmin, txop_limit) and DSCP mapping configuration. Referenced for the WMM AC VI txop_limit=3008 configuration.
4. IEEE 802.3at-2009: Power over Ethernet Plus Standard. IEEE standard for PoE+ (25.5 W at PSE), referenced for the power budget calculation including the 5 W headroom recommendation (Section 4.2.4) and cable drop estimation.
5. IEEE 802.11ax-2021: OFDMA and MU-MIMO Amendment. IEEE standard defining OFDMA RU allocation, trigger frames, and HE TB PPDU timing. Referenced for the 16 ms RU allocation interval calculation.
6. Linux netlink(7) Man Page. Linux man page for netlink socket configuration including rmem_max sysctl and NETLINK_DROP error handling. Referenced for the netlink buffer sizing analysis.

Frequently Asked Questions

Related Resources

• Smart City WiFi Module Case Studies
• WiFi 6 Module Product Page
• Environmental Monitoring Terminal Wireless Access with WiFi Module
• Industrial gateway remote communication reference
• Long-range WiFi module coverage enhancement reference