Unless you’re 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 that are often used in low power IoT. 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 5 reasons:
1) 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 low power IoT … low power. Bad sync = bad battery life.
2) 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.
3) 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.
4) Indoor Location
A growing part of 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.
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.