Sensor networks for the Internet of Things present some unique routing challenges, writes consultant Larry Mittag.
Network routing is one of those things that people tend to think about most when it is not working. Day in and day out the Internet successfully and efficiently routes bazillions of data packets from source to destination, but this only hits the news when “innocent mistakes” are made that do strange things like routing United Kingdom nuclear weapons information through the Ukraine. As we are designing our IoT networks it is worth thinking about how to route the traffic we are creating to avoid making it similarly newsworthy.
The simplest case is a group of nodes that all have direct links to each other, or at least all have direct links to a local master node. Many localized sensor networks organize this way, and the engineers that create them don’t really worry much about routing. All data is transferred via a specific data link from Point A (the sensor) to Point B (the data collector). As long as the data collector can manage the interactions with all of the sensors life is simple and good.
The problems in this simple scenario start showing up when it becomes successful enough that people want to extend it. There are many examples of military networks which work quite well within their designed domain, but they struggle to relay their information outside of that domain because they simply weren’t designed to do so. When the DoD pushed the Network-centric Warfare doctrine it realized how these local networks effectively stovepiped the information in them, which severely limited their vision of the technology and drove several expensive upgrade programs.
Lest we feel too smug on the commercial side, the Internet did not exactly map out smoothly from the beginning either. Companies created internal networks over many years from a variety of technologies that made the Tower of Babel look good. I remember numerous meetings with executives that were actively hostile to the idea of standardization on the scale of the Internet and could see no good coming out of it. Most of them are now either converted or safely retired, and the Internet genie is, for better or worse, entirely out of the bottle.
But let’s get back to our simple sensor network. If the precedents described above are relevant then we have to believe that at some point we are going to have to figure out how to make that information available to a wider audience. One possibility would be to put the data collector on an internetwork while still leaving the sensors as simple local nodes. This is most likely the path that will be taken by many sensor networks, particularly legacy ones, but as sensor nodes become more complex and capable we will begin to see some more interesting architectures.
A simple initial sensor network and first network expansion.
The original network and this expansion are both illustrated above. The original network is a relatively straightforward set of point-to-point links to a central data collector. In the expansion we have added sensors that are out of range of the data links, so it is necessary for some sensor nodes to forward their data. We have also added a single link to the ubiquitous Internet for good measure.
This expansion is still not too stressful on our network. The nodes now have to be able to forward data, but we can do that with statically-defined paths. The Internet connection is also relatively straightforward. The data collector can handle that without having to directly expose the sensors by aggregating the information. Life is still relatively easy for the network designers.
We are, of course, not going to leave it that way. Next month we will begin exploring what happens when our nodes move around, or even when the entire network moves around relative to the Internet connection. That is where things get fun in terms of routing and we get opportunities to make the news.
-- Larry Mittag, a consultant on connected embedded systems, can be reached at firstname.lastname@example.org