The clocks on your IoT devices are way more important than you think
Unless you are a networking nerd, synchronization is probably more familiar as a term used with wristwatches or iTunes than as an IoT term, but the future of the IoT may actually depend on this topic.
Synchronization — the way an IoT device adjusts its internal clock in order to align with the clocks of other devices in a network — lies (surprisingly) at the center of many of today’s IoT challenges, particularly for low-power IoT. Clocks help devices pinpoint the moment when, for example, a sensor measurement is going to be shared with the network. If your device’s clock is out sync with those of other devices in the network, it will miss messages, collide with other messages being sent by other devices, or waste energy trying to get back in sync.
Clocks drift out of synchronization, especially those using low cost, commodity computing parts like we in the low power IoT like to do. So to keep networking running efficiently, clocks need to be synchronized in order to make the data flow in a reliable way.
More than a few inventors of wireless IoT technologies didn’t focus too intensely on synchronization, perhaps because they were using TCP/IP as their networking model, which while I’m thinking about it reminds me — even if slightly off topic — of this:
Most “low power” IoT protocols implemented something similarly byzantine when they designed their method for network sync. For example, here is a picture of 6lowPAN — which famously claims to be a low power means of implementing IPv6 on a wireless network — initiating the sync process:
For 6lowPAN, this process is repeated many times — let’s refer to it as “strobing” — until the endpoint has synchronized its listening cycle with the host. Unfortunately, with 6lowPAN all this “strobing” takes power, can only be done one endpoint at a time, and if the data rate is low the endpoint will burn up lots of battery life as it listens and strobes.
For 6lowPAN and others in the IoT using “old school” network sync, the cost of not getting it right is high for at least five reasons:
- Battery life. Like politicians promising to change Washington, most low power IoT technologies don’t tell the truth about battery life. Cellular people you already know who you are. ZigBee, Thread and others are also guilty because bad sync processes do to batteries what badly under-inflated tires do to your car’s gas mileage. Multi-year battery life is what makes the low power IoT … low power. Bad sync = bad battery life.
- Connection time. Some wireless technologies can take many seconds or even minutes to connect, due almost entirely to weak synchronization schemes. For an on-demand world where we expect immediate results when it comes to IoT, a bad sync method in a mission critical environment can render obsolete information created only seconds earlier. Smart city or public safety applications, for example, are poorly served with slow-sync technologies. Slow-sync protocols are also a no-go for IoT control apps like implementing a kill switch on a piece of industrial equipment.
- Dense-packed endpoint environments. Environments with lots of endpoints are intimidating to IoT protocols with weak sync schemes. As in, they shouldn’t even get into the ring to pretend to compete. Imagine trying to run a query in a warehouse with 2,000 endpoints and establishing sync with each endpoint— one-by-one — in order to engage in a group broadcast or to query a group of endpoints or to send out a security patch. Industrial IoT environments are particularly sensitive to this issue.
- Indoor location. A growing part of the battery-powered IoT has to do with locating things. Outdoors, we seem to be relying more and more on GPS, but indoors is another matter. Being able to locate something indoors in any kind of real-time way requires fast synchronization with a gateway/access point or, more importantly, with other endpoints on a peer-to-peer basis. Slow-sync protocols are a no-go for these applications.
- Security. IoT technologies with weak sync schemes take longer to exchange keys and are more vulnerable to unwanted discovery and spoofing. Fast-sync protocols are also better able to support two-factor authentication and can remain in a quiet/listen-before-talk mode that protects privacy and inhibits unauthorized discovery.
Solving For Fast Group Synchronization in a Low Power IoT Network
Back in 2011 when we started Haystack, the issue of synchronization was front-and-center as we gathered requirements for the technology we invented, DASH7. Unlike the slow, serial method used by 6lowPAN and others, we employ a different scheme using a flood of “background frames” and the picture looks like this:
Unlike 6lowPAN (sorry to keep picking on them, but trying to keep this brief), any number of endpoints can listen simultaneously for background frames and advertising protocol data. All endpoints can receive the request, all can send responses, and all are then synchronized to each other. This is the fastest, most efficient method of group synchronization available in the low power IoT today.
We are not the first company to attempt fast group synchronization via low power advertising, but we’re the first to do it in a (patented) way that actually works. For more information on how Haystack’s group synchronization works click here.
You can reach me via @patdash7 or via email at pat @ haystacktechnologies dot com.
Get the latest about Haystack by signing up for our newsletter here.