Local Autonomy

Cloud-based is the new normal and it works most of the time. The problem, however, is when it does not. And these things tend to happen when we need them the most. Not long ago Tesla went down preventing people from opening their cars. Then Amazon outage kept people out in the cold as they could not enter their (dis)connected homes.

Cloud is nice and solves a lot of problems. Provided it is available. This is why features considered foundational should run autonomously without any cloud connectivity. It is a bad idea to connect switches and sensors to lights via cloud. But people are doing it, as from the integration perspective this often is simply easier. But latency is introduced, which contributes to bad user experience. And worst of all, the Cloud becomes the point of failure for even the most basic functions.

Bluetooth mesh has been winning the markets since it became available in 2017 and the most prominent feature is the resilience of this system. This is due to the groundbreaking distributed architecture which makes a day-and-night difference in how it works compared to everything else. In Bluetooth mesh decision-making and execution is on a node level, in every node. There is no central authority nor controller in the system. Ed Lees from Sylvania has a great article on that on Bluetooth.com. And for those interested in exploring this deeper, there is also this 30-minute video.

We have recently made available another very powerful local-autonomy feature for Bluetooth mesh. This is called in-node scheduling (INS) and enables real-time-based events and functions in a fully distributed (yet collectively coordinated) fashion.

INS consists of two related features:

1. Time, which is maintained ans synchronized among all nodes in the network. Each node maintains its own clock and therefore is fully autonomous in terms of time keeping and executing time-based events. Time is also synchronized. The synchronization is important, as local clocks drift away, each in its own direction, while at the same time (pun intended) we want the "group" actions executed without any "popcorn" effects. The mesh network, which by nature is fully autonomous and disconnected from the Cloud, needs to be told the time once, and it continues the timekeeping functionality on its own, even while devices are down or disconnected. When a device is back up again it synchronizes the time with the rest of the network.
2. Scheduler, which is an event execution engine, based on pre-configured actions, which typically are recurring. Such as dimming the lights outside of business hours or lighting up spaces during maintenance windows. What is important here, there is again no central coordinator. Each node keeps the time and changes the behavior based on the locally pre-programmed schedules and the local time. Of course because the nodes are interconnected, they behave fully synchronously, down to a milliseconds level. But even when the local connectivity is disrupted (say, as a result of a strong interference denial-of-service attack), they will continue doing their jobs uninterrupted.

There is a short tutorial on the INS feature on YouTube. We like building unbreakable systems, as we believe in the end they prove to be fundamentally better.