How to design a wireless network for efficient multicast or broadcast communications?

Question

First, a little bit of background information: I'm working on some custom software that allows a group of computers on the same LAN to co-operate on a real-time task in a distributed, fault-tolerant manner. In particular, each of the computers sends out a multicast (IPv6/UDP) "heartbeat" packet several times a second, which the others receive, and based on their knowledge of who else is on-line at the time, they self-organize to divvy up a task amongst themselves. If any peers go offline, their parts of the task are automatically re-assigned to the remaining computers. In addition, a peer will sometimes use multicast to communicate a one-to-many data-update to the group.

This all works nicely on a wired Ethernet network; but at some point I'd like to make it able to work well on a wireless network too, e.g. to allow for a self-organizing swarm of drones and other fun experiments like that.

The problem is that Wi-Fi is notoriously bad at multicast -- in particular, multicast packets are usually transmitted at the AP's slowest and least efficient rate, and they are often delayed or dropped. That means that unless I dial my software's tolerances way back, running it over a Wi-Fi network means I occasionally get "false positives" where the system thinks a particular computer has gone away but actually it's just that the Wi-Fi network isn't delivering its heartbeats in a timely manner. The lack of timeliness also makes it difficult to co-ordinate behaviors precisely in time, since without a near-constant speed network, synchronizing clocks is difficult.

My question is, is Wi-Fi simply not the right tool for this application? If it's not, is there some other wireless networking technology that I should be looking into using instead? (it seems that, in principle at least, radio ought to lend itself to efficient multicast/broadcast, since it's inherently a shared medium) Or if Wi-Fi really is the only game in town for wireless networking, how should I go about tweaking the Wi-Fi settings (on the AP and/or the clients) to get the best multicast performance possible?

Answer 1

The effective bandwidth and reliability of wireless networks (Wi-fi or any other) is highly dependent on the RF environment. In order to have some predictable performance, each installation needs to be tuned for the particular environment. That means a site survey to determine proper AP numbers and placement, antenna configuration, as well as configuring the APs for transmitter power, channel frequency, and data rates.

It sounds like you need some minimum performance from your wireless networks. The only way to guarantee that is to tune each installation individually. Some places may be just too noisy (RF) to work at all.

Answer 2

I haven't found any reliable information on how to make multicast-over-WiFi work better, so what I did in order to work around the problem was write a multicast-simulator-layer that greatly reduces the amount of multicast traffic my system needs to send and receive over WiFi, without requiring a significant redesign of the application itself.

On each node, the multicast-simulator-layer periodically sends out a very small multicast packet, simply to announce its presence to the world. Whenever another node receives one of these packets it adds the packet's source IP address to a list, and sends back a unicast reply to the sender (just to make sure the sender is aware of the receiver's existence also).

Then whenever the application wants to "send a multicast packet" containing actual application-data, instead of just sending the packet directly via multicast, it hands the packet over to the multicast-simulator-layer, which "multicasts" the packet by sending a separate copy (via unicast) to each of the IP addresses in its list. This wouldn't scale up very well on a WiFi network with many participants, but for smaller WiFi-based systems this performs better than real multicast.

There is also some keepalive/timeout logic so that nodes that haven't been heard from in a long time get dropped from everybody's nodes-list, but that's pretty much all there is to it.

One other interesting "feature" I discovered during this process was that (on Mac laptops, anyway), the WiFi hardware is set to power itself down after about 250 milliseconds of inactivity, and once powered down it will take an indeterminate amount of time (anywhere from 30mS to 250mS) to make itself usable again so that the next packet can be sent. The upshot was, if I send a packet over WiFi every 300mS, the latency of the transmission would be all over the map due to the WiFi hardware constantly going to sleep and then waking up again. If I instead sent a packet every 150mS, the latency was much steadier as the WiFi hardware stayed online consistently (at the cost of increased energy consumption, of course)