Why I Like Thread for IoT
Source: Larry Mittag

The Thread protocol represents the future for networking the Internet of Things, according to a veteran embedded-systems consultant.

Early IoT devices generally have had to compromise their ambitions. Most connected products to date have either used WiFi connectivity for networking and paid the cost in terms of power or moved to Zigbee or Insteon for lower-power networking and have lived with the more restricted connectivity available on those networks. For IoT to reach its full potential, however, there is going to have to be a truly ubiquitous and robust networking standard.

The networks for these early products are mostly those described in my last blog. Their hallmarks are either one-to-many connectivity with a defined central controller or relatively static forwarding paths within the local network segment. These networks tend to be locally optimized for a specific set of tasks but limited in terms of being able to scale to the next level that is anticipated for the IoT.

That next level is going to require much more robust networking that is standardized. There are a number of networking suites that are trying to make the case for being that standard, but so far none of them has been able to meet all of the requirements to be accepted as the 800-pound gorilla of this Internet expansion.

One recent entrant that has been popular is Bluetooth Low Energy. This protocol set has very strong industry acceptance, but it still has a relatively local concept of networking. Bluetooth tends to be strongest at point-to-point communications.

There are options to build small networks of Bluetooth devices, as well as the Internet Protocol Support Profile (IPSP) which will allow the use of full IPv6 protocols. But IPSP really doesn’t seem to be designed to create a general-purpose network that can support more than a few dozen devices and provide robust routing into the Internet.

The strongest entry that I have seen for filling that niche is the Thread group. This organization consists of some major players such as ARM, Google (via their Nest subsidiary), and Samsung and built its technology on IEEE standards such as 6LowPAN. The result is a robust network base that can scale very effectively while also supporting very low-power devices.

It is worth pointing out that this is a networking stack, not an operating system. Just among the founding members of this group there are several potential IoT operating systems represented, and the Thread stack can be used with each of them as well as others.

Thread’s robustness really comes into play when you consider mobility. If nodes in an IoT network are moving around locally then the intranet forwarding paths must be constantly updated. If the local network itself is mobile (in a car or truck, for example) then the connectivity points to the Internet will be changing and need to be smoothly updated. If nodes within the local network are mobile across multiple local networks then the routing protocols must adjust to that.

Ideally all of these adjustments must take place without the applications using the network having to be aware of the changing connectivity environment. This can be done using the Thread protocols.

Some may ask if we need all this functionality. I think to go to the next stage we do. Others may question why we should pay to use IEEE standards. I think their value is primarily in strong interoperability testing. Predictable some will wonder if Thread even works. I would think there’s a pretty good bet it does given the players involved.

To my mind this is the strongest solution to bring clarity to this corner of the confusing IoT universe. There are still other questions about the choice of an operating system and hardware vendor that are far from settled, but the Thread Group can provide the lingua franca that can tie it all together and provide the scale that will be required.
-- Larry Mittag, a consultant on connected embedded systems, can be reached at lfmittag@mittagstuff.com