Those of you with kids, or those of you who were kids in the ‘60s with access to Disney movies, may recall the classic 101 Dalmatians. It’s a story about puppies stolen in the interest of a puppy-fur garment. Rough stuff, actually… Specifically, when the puppies are taken, the puppy’s parents engage a communication mechanism called, “The Twilight Bark.”

The parent dogs start barking, and the dogs within earshot hear the message and start barking it themselves. And those within earshot of that second message relay further relay the message. Until, finally, dogs in the area where the stolen puppies have been taken get the message, and, well, so starts the action.

The parents could never have barked loud enough for those rural dogs to get the message – especially since no one knew where they were. In fact, no one knew anything about any of the dogs that participated in relaying the message. Each dog acted autonomously, hearing the message and repeating it.

That’s Meshed Up!

And so we, or perhaps your kids, were introduced, at a tender age, to the notion of the mesh network. At a high level, this is how the mesh works: a node receives a wireless message and repeats it; the relaying continues until either the desired destination node receives the message or everyone gives up.

The benefits can be many, but, at the highest levels, this allows one node to transmit a message to a node that is much farther away than the first node’s signal can reach. Rather than boosting the power to transmit to greater distances, intermediate nodes handle the job of passing the message along.

In addition, most meshes can be self-healing – that is, if a node in the network goes down, and, if that node was involved in passing notes along, then the network can figure out a way around that offline node so that the rest of the network can continue.

This can be attractive for extensive Internet-of-Things (IoT) installations – particularly of the industrial persuasion, where networks can span large distances. It would be nice if designers and integrators could simply say, “I think I’ll use a mesh network” and be done with it. But, of course, it’s not that simple. There are several to choose from. The most prominent three are Thread, ZigBee, and, most recently, Bluetooth Low Energy.

Thread and ZigBee, both based on the 802.15.4 radio standard for the lowest layers, have had mesh capability built in from the beginning. By contrast, Bluetooth has only recently been amended to allow a mesh configuration. So meshing didn’t figure into the early Bluetooth planning details – you might say meshing has been retrofitted on.

So, given this choice, which one is best?

Mesh Performance

Choosing a network is never cut-and-dried. If it were, then one would always be the best and the rest would disappear. That hasn’t happened. There are always trade-offs. But, at least with respect to performance, throughput and latency are the big parameters that can be compared – if only someone would take the time to run the experiments.

Well, at least one company has. Silicon Labs has published four app notes on mesh network performance: one each for the performance of each of the three networks alone and one comparing the three. The first three notes summarize the network characteristics, and they’re all different. While Thread and ZigBee share a radio, Thread is an IP-centric network with 6LoWPAN (IPv6 over Low-power Wireless Personal Area Network) above it. ZigBee, by contrast, defines everything above the 802.15.4 stuff, all the way to profiles at the application layer. Meanwhile, Bluetooth is its own thing top to bottom.

If you look at the different networks, you can find many differences, but, from a meshing standpoint, the biggest is how routing is handled. Conceptually, there are two extremes: flood routing, where the message simply spreads blindly until it hits its destination (less efficient but easier to manage), and routing, where each node maintains next-hop tables that help to direct an incoming message on its way to the destination (more efficient once the tables are in place, but a greater management burden).

Some variant of these is used by each of the networks, and they’re all different. The way routing or flooding is managed does affect performance; you can decide, for example, how many nodes are designated for relaying messages, cutting down the amount of flood noise. Optimizing that number and spacing of nodes is part of tuning the network (and it’s handled automatically and dynamically by Thread).

Even though this might be the biggest obvious mesh-related difference among the three, it turns out not to be the thing that makes the biggest difference in performance. That thing turns out to be much more basic: payload size. Thread and ZigBee have similar sizes, both being based on the same radio standard: 63 bytes for Thread, 68 bytes for ZigBee. By contrast, Bluetooth has an 11-byte payload.

So what happens if you blow the payload size – as many data-carrying messages may do? Then you have to segment the big payload and send it via multiple messages, to be reassembled at the destination. Instead of one big message, you have multiple small messages. You may see where this is going: Bluetooth will require many more messages to carry a big payload than will Thread or ZigBee.

Performance Results

Silicon Labs tested a number of scenarios – small, medium, and large networks carrying small and medium payloads over a varying number of hops to a destination. They measured throughput and latency over many of these configurations, detailing the tests for each of the networks in each of the first three app notes.

There’s plenty to chew on in the results, but one trend is pretty clear: Thread typically performs best, and Bluetooth Low Energy typically performs worst – sometimes by a lot. For example, measuring overall throughput for a 100-byte payload and plotting vs. the number of hops bears this out – especially for a low number of hops (which is typical). With one hop, Thread gives about 47,000 bits per second (bps – not to be confused with bpm, for you ravers…), ZigBee gives about 21,000 bps, and Bluetooth gives a number that’s hard to resolve on the chart – maybe 2000 bps.

The throughput comes down as you add more hops. With 4 hops, Thread degrades to about 12,000 bps, ZigBee to about 6000 bps, and Bluetooth stays somewhere around 2000 bps (it looks like it’s insensitive to the number of hops, but that’s just a figment of the scaling, since its throughput is so much lower).

Meanwhile, looking at latency vs. packet size, the segmentation penalty is particularly noticeable. Running from 10 to 300 bytes, Thread latency increases from about 40 to about 120 ms; ZigBee goes from about 50 to 230 ms (stopping at 250 bytes*); and Bluetooth goes from 80 to 800 ms (stopping at 128 bytes*).

Latency also isn’t simply one number; it varies from packet to packet. They ran histograms of a number of configurations, and Thread consistently had the lowest spread, with Bluetooth having by far the biggest spread. That said, all three (Bluetooth less so) mostly stayed within a specified 200-ms specified limit.

It’s easy to declare Thread the winner and Bluetooth the loser, but these are but one set of characteristics that must be traded off against others. It does, however, raise the question as to whether the addition of meshing to Bluetooth will really pay off in increased Bluetooth installations at the expense of Thread and ZigBee.

* This is the limit of what was tested, not necessarily an intrinsic limit associated with the network.

More info:

Silicon Labs application notes (all behind registration walls):

Bluetooth Mesh Network Performance

Thread Network Performance

ZigBee Network Performance

Mesh Network Performance Comparison