This article is by Francis DaCosta as published on his blog Net of Things.
When contemplating how the Internet of Things will communicate, it helps to forget everything you know about traditional networking schemes – especially wide area networking and wireless networking. In traditional wide area and wireless networking, the bandwidth or spectrum is expensive and limited; and the amount of data to be transmitted is large and always growing. While over-provisioning data paths in wiring the desktop is commonplace, this isn’t usually practical in the WAN or wireless network – it’s just too expensive.
Besides cost, there’s the matter of potential data loss and (in the wireless world) collisions. Traditional networking needs lots of checks and double-checks on message integrity and order to minimize costly retransmissions. These constraints led to the protocol stacks with which we are familiar today such as TCP/IP and 802.11.
In most of the Internet of Things, however, the situation is completely different. Oh, the costs of wireless and wide-area bandwidth are still high, to be sure. But the amounts of data from most devices will be almost immeasurably low and the delivery of any single “chirp” or message completely uncritical. As I keep saying, the IoT is lossy and intermittent, so the end devices will be designed to function perfectly well even if they miss sending or receiving data for a while – even a long while. It’s this self-sufficiency that eliminates the criticality of any single “chirp”.
It might be worthwhile at this point to contrast my view of the IoT with traditional IP. First, IP is fundamentally oriented toward large packets. With large packets, the IP overhead is a relatively small percentage of the overall transmission. But in the IoT, IP overhead is much larger than the typical payload of a chirp.
In addition, a significant amount of the overhead in IP is dedicated to security, encryption, and other services, none of which matter at the very edges of the Internet of Things where the simplest devices predominate (if my view of the IoT is correct).
By contrast, IoT chirps are like pollen – lightweight, broadly propagated, and with meaning only at the “interested” Integrator functions. The IoT is receiver-centric, not sender-centric, as is IP. Because IoT chirps are so small and no individual chirp is critical, we have no concern over retries and resulting broadcast storms, which are a danger in IP.
It’s true that efficient IoT propagator nodes will prune and bundle broadcasts, but seasonal or episodic broadcast storms from end devices are much less of a problem because the chirps are small and individually uncritical. Like nature treats pollen, the IoT may treat any single chirp as truly “best effort” – so heavy broadcast storms caused by an external event will die out pretty quickly.
In my view of the IoT, this means that huge packets, security at the publisher, and assured delivery of any single message are passé. This will allow us to mirror nature with massive networks based on lightweight components. In my technical imagination, this makes the IoT more “female” (receiver-oriented) than the “male” structure of IP (sender-oriented).
But having said all that, what’s the point in having an IoT if nothing ever gets through? How can we deal with the unpredictable nature of connections? The answer, perhaps surprisingly, is over-provisioning. That is, we can resend these short simple chirps over and over again as a brute force means of ensuring that some get through.
Because the chunks of data are so small, the costs of this over-provisioning at the very edge of the IoT are infinitesimal. But the benefits of this sort of scheme are huge. Since no individual message is critical, there’s no need for any error-recovery or integrity-checking overhead (except for the most basic checksum to avoid a garbled message). Each message simply has an address, a short data field, and a checksum. In some ways, these messages are what IP Datagrams were meant to be. The cost and complexity burden on the end devices will be very low, as it must be in the IoT.
The address will incorporate the “arrow” of transmission I mentioned earlier, identifying the general direction of the message: whether toward end devices or toward integrator functions. Messages moving to-or-from end devices will only need the address of the end device – where it is headed or where it is from is unimportant to the vast majority of simple end devices. They’re merely broadcasting and/or listening.
So the end devices are awash in the ebb and flow of countless transmissions. But replicating this traffic willy-nilly throughout the IoT would clearly choke the network, so we must apply intelligence at levels above the individual devices. For this, we’ll turn to the propagator nodes I’ve referenced in past posts.
Propagator nodes will use their knowledge of adjacencies to form a near- range picture of the network, locating end devices and nearby propagator nodes. The propagator nodes will intelligently package and prune the various data messages before broadcasting them to adjacent nodes. Using the simple checksum and the “arrow” of transmission (toward end devices or toward integrator functions), redundant messages will be discarded. Groups of messages that are all to be propagated via an adjacent node may be bundled into one “meta” message for efficient transmission. Arriving “meta” messages may be unpacked and re-packed.
Propagator nodes will be biased to forward certain information in particular directions based on routing instructions passed down from the integrator functions interested in communicating with a particular functional or geographic neighborhood of end devices. It is the integrator functions that will dictate the overall communications flow based on their needs to get data or set parameters in a neighborhood of IoT end devices.
Discovery of new end devices, propagator nodes, and integrator functions will be again similar to my architecture for wireless mesh. When messages from-or-to new end devices appear, propagator nodes will forward those and add the addresses to their tables. Appropriate age-out algorithms will allow for pruning the tables of adjacencies for devices that go off-line or are mobile and are only passing through.
One other aspect of communication to be addressed within the Internet of Things is the matter of wireless networking. It’s likely that many of the end device connections in the IoT will be wireless, using a wide variety of frequencies. This fact seems to suggest a need for something like CSMA/CD (Carrier Sense Multiple Access with Detection), as used in 802.11 WiFi. But that’s another aspect of traditional networking that we need to forget.
Again, data rates will be very small and most individual transmissions completely uncritical. Even in a location with many devices vying for airtime, the overall duty cycle will be very low. And most messages will be duplicates, from our earlier principle of over-provisioning. With that in mind, an occasional collision is of no significance. All that we must avoid is a “deadly embrace” in which multiple devices, unaware of one another’s presence, continue transmitting at exactly the same time and colliding over and over.
The solution is a simple randomization of transmission times at every device, perhaps with continuously varying pauses between transmission based on prime numbers, hashed end device address or some other factor that provide uniquely varying transmission events.
While the resulting communication scheme is very different from traditional networking protocols, it will be all that we need for the IoT. Providing just enough communication at very low cost and complexity will be good enough for the Internet of Things.
Many of the ideas I’m developing for the Internet of Things are inspired by the interactions of beings in nature. Next time, a look at the way aggregations of creatures become highly-functioning colonies and “SuperOrganisms” – and the lessons this provides for the IoT.
