Congestion Bypass

Congestion is a very known problem today. Who has not been stuck in a traffic jam recently? We have cars and streets again as an analogy illustrating the behavior of wireless mesh networks. It is a very good analogy - after all streets form a mesh and have limited capacity which depends on how wide they are and how quickly cars can move. That maps directly to number of wireless channels and the transmission speed of a wireless links. And of course to the size of cars represents the size of network messages. You can move more tiny scooters than heavy trucks through streets.

Congestion is the key problem in mesh networks. It is frequently forgotten in discussions about performance. But the truth is that link congestion is what really limits the performance of a wireless mesh network. When a link between two network nodes saturates, the network cannot handle any more messages. And mesh networks tend to saturate the links very easily. This is due to their topology - messages are forwarded from a node to a node to a node... and very often a link between two nodes has to carry traffic originating or destined to many other nodes. Like a narrow, crowded street in a city.

There are two methods for traffic congestion relief: shortcuts and bypasses. Both greatly increase the efficiency of a transport system. And not only a transport system. Have you ever wondered what mesh networks and jet engines may have in common? Not that much from the architectural perspective. But a lot from a perspective of a trend of architectural changes to improve efficiency. The entire commercial airline industry thrives on engine fuel efficiency. That has been primarily driven over the last 50+ years by one thing: the bypass ratio. Back in the Boeing 707 era, aircraft were powered by turbo-jet engines with 1.4:1 bypass ratio. The current king-of-the-hill PW1000G engine that powers A320Neo and CSeries has an order of magnitude higher bypass ratio of 12:1, delivering unprecedented efficiency.

So can shortcuts and bypasses be used to improve efficiency of a wireless mesh network? The answer is yes. And when evaluating and comparing mesh architectures it is far more important to compare the throughput in a (potentially) highly congested scenario rather than treating them as empty racetracks with just a handful of cars, all moving in the same direction. That involves much more than just the transport layer (the streets). Traffic patterns required by mesh applications become much more fundamental.

Let's take a lighting system with sensors as a model application (this is by far the most popular application for indoor mesh networks). Luminaires and sensors are the mesh nodes. Lighting control typically operates as a closed-loop control system. This means there is a controller that continuously adjusts brightness of luminaires based on readings from ambient light sensors. When a sensor reports the space is too dim, the controller increases the output of the luminaires. And it keeps doing that until the sensor reports it is too bright, at which point the controller starts decreasing the brightness. Until the sensor reports it is too dim, at which point the controller starts increasing the brightness again. The faster the sensor reports to the controller, the smaller the overshoots, to the extent that the oscillations become invisible. The latency of the sensor-to-controller-to-luminaire communication is critical for maintaining a stable ambient light level in a closed loop system. It has to be responsive to changes (the amount of light coming through windows) by reacting quickly, but not fall into annoying oscillations.

Typically today lighting controllers are standalone devices talking to sensors and luminaires via a mesh network. That means the sensors messages must travel through the network to the controllers and then the control messages must travel back to the luminaires via the same mesh network. And the round-trip latency requirement becomes quickly a challenge. What is worse in radio networks, compared to city streets, is the streets allow collision - free traffic in both directions, while radios don't. Transmissions between any given two A-B nodes connected with a single radio link must be one-way at a time. If both A and B transmit at the same time, there is a collision and nothing gets through. Imagine now all streets in a city are single - lane!

One of the most important (and little known) innovations offered by Bluetooth mesh is moving the control function to each lighting node. The central controller is gone. All the closed loop control logic is executed locally at each luminaire. That is a huge shortcut, or a bypass, if you will. The sensors are, after all, located in the same spaces the lights are. They broadcast the readings, the luminaires pick up the messages and react with almost zero latency. And all that traffic is confined locally. The congestion is gone. Completely.

Of course there is some longer-distance traffic involved too. Such as the same sensors reporting the light level to a gateway, which forwards it to other systems (local or cloud-based). Typically such traffic does not have the same frequency and latency requirements as the closed loop lighting control. Therefore the same sensors may publish messages towards the gateway at much slower cadence (say 1 message a minute) and the message could carry the averaged ambient light level for that period. This is plenty enough for a reporting system. So here we arrive at the modern jet turbo fan engine analogy: the "bypass" traffic exceeds the "pass-through" traffic by an order of magnitude or more.

The bottom line is this: the distributed control architecture results in a mesh lighting control network capable of delivering significantly better performance and scalability than competing solutions, while maintaining the low latency requirements that make the lights run smoothly.