Skip to content

ByteBrigand/wifi-smart-mesh

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

4 Commits
 
 
 
 

Repository files navigation

Smarter Wi-Fi Mesh: Energy-Efficient, Secure, and ACK-Less Networking for Wi-Fi 8+


As Wi-Fi networks become more dense, mobile, and power-sensitive, it's time to rethink how devices interact — not just with access points, but with each other. What if client devices could form an intelligent, power-efficient mesh network on their own? What if we could cut unnecessary overhead, improve coverage, and save battery — all without breaking the standards?

Here’s a set of ideas that could help shape the future of Wi-Fi (8 and beyond) — particularly in mesh and client-to-client communication.


🔗 Client Devices as Mesh Nodes

In a next-gen Wi-Fi network, stations (clients) should be able to:

  • Act as lightweight mesh relays for each other
  • Enable traffic to hop across 1–2 neighboring devices to reach the router or AP
  • Improve coverage and resiliency without needing extra hardware

🔋 Low-Bandwidth, Battery-Efficient Relays

Client mesh nodes should:

  • Use a max bandwidth of 1 Mbps for mesh forwarding
  • Operate on narrow 5 MHz channels
  • Beacon infrequently (2 Hz) to stay low power

This approach balances usability with energy constraints — ideal for mobile phones, IoT, and wearables.


🔐 Privacy-Preserving Relaying

End-to-end encryption should be handled between the endpoint and the router. Intermediate mesh nodes:

  • Relay traffic without decrypting it
  • Have no access to encryption keys
  • Function as "dumb pipes" to preserve privacy

🔁 Limited-Hop Forwarding

To keep the mesh predictable and efficient:

  • Limit relaying to 2 hops maximum
  • Avoid excessive routing complexity
  • Reduce delay and battery use

This model favors localized micro-meshes rather than sprawling, multi-hop topologies.


🧠 Smarter ACK Strategy Based on Protocol

Not all traffic needs MAC-layer ACKs. For example:

  • TCP traffic already handles reliability and retransmissions
  • UDP-based real-time traffic (e.g. VoIP, video) prefers low latency over reliability

By disabling Wi-Fi MAC ACKs for certain traffic types, we can:

  • Reduce latency
  • Save airtime
  • Cut power use

🧪 Introducing a "Do Not ACK" Bit in TCP/UDP

A single transport-layer flag could tell Wi-Fi whether MAC ACKs are needed:

  • One bit in TCP or UDP headers
  • If set: "Skip MAC-layer ACKs, let me handle it"
  • Survives NAT and is visible end-to-end, unlike DSCP/TOS which is often not preserved end to end

This would give applications and protocols explicit control over how their traffic is handled at lower layers.


⚖️ Adaptive ACK Behavior Based on Latency

Why stop at static configuration? TCP can:

  • Dynamically monitor RTT
  • If RTT < 5ms, disable MAC ACKs (likely on a LAN)
  • If RTT ≥ 5ms, re-enable MAC ACKs to avoid costly retransmissions

This creates an adaptive reliability model that adjusts to network conditions in real-time.


📄 Licensed under CC BY 4.0 — use freely with attribution.