The Thread Internet-of-Things stack

The latest entrant into the race to dominate the Internet of Things (IoT) is Thread, which is primarily the creation of Google's Nest division. As one would expect from thermostat-and-smoke-alarm-maker Nest, Thread targets home and environmental IoT devices—rather than, say, the industrial and utility deployments that are central to the Industrial Internet Consortium's (IIC) IoT work. But even ignoring IIC, the Thread Group is hardly the only player to have announced an IoT framework it believes will achieve widespread acceptance. There are already two direct competitors in the AllSeen Alliance and Open Interconnect Consortium (OIC), not to mention scores of smaller projects. The Thread Group announced the first publicly available release of its specification on July 14. While of potential interest to many developers, its chief obstacle may be differentiating itself in the increasingly crowded IoT specification arena.

The Thread Group itself is an industry consortium with a membership made up of hardware and software companies. Interestingly enough, those members include Qualcomm, Samsung, Atmel, and quite a few other companies who are also OIC, AllSeen Alliance, or IIC members. The announcement said that a Thread compliance program will launch in September, with the first certified products to arrive shortly thereafter.

The bigger news, however, was the publication of a set of white papers describing the Thread platform. Fundamentally, Thread is a wireless network-protocol stack that defines every layer from the physical up to the transport layer (leaving the application layer, it seems, undefined). Thread devices will create a mesh network of routers that forward messages to and from every node. The meshes can quickly recover from the sudden disappearance of a router (including the gateway router responsible for the connection to the outside world), and they will employ encryption and authentication across the board—providing the ability to implement network-wide security as well as application-specific security measures. The targeted devices include low-power nodes that may run off of a single AA battery for years at a time by going into sleep mode for long periods of time.

The stack

The Thread stack is largely standards-based; it uses IPv6 addressing, UDP datagrams, and a number of other pre-existing IETF standards (RIP routing, DHCP, ICMP, and so forth). The low-power functionality comes from using IEEE 802.15.4 "6LoWPAN" for the physical and Media Access Control (MAC) layers. 6LoWPAN adapts IPv6 for optimal use by low-power devices by defining shorter packets, using smaller (16bit) link-local addresses, and optimizing transport-layer parameters to conserve energy at the expense of other factors (such as transmission bitrate). Thread uses the 2006 revision of 6LoWPAN, operating in the 2.5GHz band at 250kbps.

Each Thread network requires at least one router device, although multiple routers seem to be assumed—perhaps because the majority of the other devices are expected to be low-power nodes that sleep when idle and communicate solely with the router that they pair with. Since these low-power nodes may have limited range, multiple routers may be required to cover a given geographical area.

When configured on the same network, all Thread routers hold an election to determine a "leader" router. The leader has just a few responsibilities, such as picking the IPv6 /64 network prefix that the devices will use. If the leader disappears, the remaining routers simply hold another election. In a multi-router network, the routers periodically update a mesh-routing table for the Thread network, taking into account the signal strengths of the other devices.

Whenever a new non-router node appears on the network, it establishes a "commissioning" session with the nearest router, requests permission to join, and (if allowed) gets information about the network in return: the network prefix, the 16-bit 6LoWPAN link-local address it should use, and the addresses of neighboring devices. In return, it sends a set of device capabilities to the router. Thread uses the Message Link Establishment (MLE) protocol for these exchanges. The Thread specification also notes that the commissioning step can be skipped if the node device can be pre-configured with the right settings.

The commissioning step introduces the first security measure in the Thread stack. Each Thread network uses a network-wide encryption key (which, since it is network-wide, only guards against casual eavesdropping). When a new node petitions to join the network, the decision to accept or reject it belongs to a Commissioner node (which may or may not be the leader router; the specification indicates that an external Internet service can be the Commissioner). Ultimately, whether or not a new device is permitted onto the Thread network may come down to an application or end user.

However that decision is made, once the new device is accepted, it can then request its own application-level encryption key to ensure better, per-device security. Key exchange is done with DTLS (the datagram-based variant of TLS) handshakes.

The competition

At this point, the Thread stack specification ends by saying that UDP is used as the transport layer. Individual device nodes will, presumably, implement their own application-layer protocols to exchange thermostat information, light status, or any of the other standard IoT functions. Which is to say that Thread is, more or less, a standard IP protocol stack, with some specific choices pre-made that will (hopefully) optimize performance for the low-power device nodes.

The real question is how Thread compares to the IoT specifications produced by the AllSeen Alliance and OIC. Both of those projects focus on defining a transport-neutral application layer. AllSeen's AllJoyn and OIC's IoTivity are each designed to support an API that works transparently over WiFi, Bluetooth, Z-Wave, ZigBee, or any number of other network layers. That makes them, in a sense, orthogonal to Thread—if available, Thread would be just one more transport for AllJoyn or IoTivity to function over.

But both AllJoyn and IoTivity also seek to define a suite of standard device-type definitions for IoT hardware, and the corresponding status and management APIs for those device types. That is a tall order even today, and whether or not either framework can keep pace with the development of new IoT products in the real world is something of an open question.

AllJoyn and IoTivity also tackle security and authorization as part of their device-management APIs. Those features would probably conflict the most with elements from the Thread specification. AllJoyn, notably, uses access-control lists (ACLs) managed by a dedicated Security Manager service to track which device nodes have access to which AllJoyn APIs. As defined, it is a more top-heavy solution than Thread's security model—but Thread also avoids a lot of hard questions by leaving the application layer up to the device maker.

Perhaps in the coming months we will see interested parties work on bridging the gap between Thread and the other, existing IoT standardization projects. But it is hard not to be somewhat cynical about such things when there seems to be a new IoT consortium every year.