Toward the next frontier in networking
Thread goes open source, offering a viable de facto standard for IoT communications.
The next frontier. (source: Pexels)
Last week, Nest announced that they were releasing an open source implementation of Thread, their low-level connectivity technology. Open source has a long history of helping to establish de facto standards, especially in the networking community. There’s a fun bit of personal validation here for me: When Jon Bruner first started Solid, I submitted a proposal for a talk that was essentially “lessons from packet networking for IoT,” with a plea for developing a common language for communication between devices.
There are several points in the “stack” for IoT that would benefit from having a reference implementation, and this release could address one of the biggest pain points. Many IoT companies have an idea of the type of device they want to build, and they assume that connectivity is easy to do because wireless networking has been around for well more than a decade. While that is true, the dominant wireless networking—Wi-Fi—is built for high-speed networking and has consequently high power consumption. In many ways, Wi-Fi is unsuitable for use with sensors. What the IoT industry could use is something that turns connectivity into the commodity it is viewed as, so that a sensor vendor can use open source code and standard hardware, adopt it, and then move on to providing value on top of that connectivity. Making Thread a de facto standard supports the industry as a whole by reducing the complexity of creating new radio technologies to support low-powered devices.
Learn faster. Dig deeper. See farther.
Like many innovations in networking, Thread builds on an underlying framework; in this case, the IETF’s 6LoWPAN (IPv6 over Low-power Wireless Personal Area Networks), a concluded working group. 6LoWPAN rests on the belief that new networks aren’t necessary because the Internet works fine even at small scale, and that low-power devices are capable of running a meaningful set of Internet protocols without compromising connectivity.
Running the Internet suite in small devices was once thought impossible. Many sensors cost only a few dollars to the end user, meaning that the manufacturing cost is even lower. Before 6LoWPAN, the idea that a meaningful IP stack could run with only 32 KB of flash memory was the subject of intense debate. And, in fact, several alternatives to using IP “natively” on sensors have been proposed, but as with so many other areas, IP has proven to be conceptually robust. In addition to its legacy of obvious interoperability and scale, IP has established expertise to run networks, and engineers know how to manage, monitor, and configure addressing on IP networks. IP networks also have well-understood security properties and protocols as well as—probably most importantly for IoT—a data transfer model in REST.
One of the most common radio links used with 6LoWPAN is 802.15.4, a PHY and MAC for personal area networks. It provides a simple MAC that supports ZigBee, WirelessHART, ISA100.11a in addition to 6LoWPAN. As networking has been increasingly dominated by Internet technologies, the community has produced a variety of specifications to assist implementers. When considering how to use a new link layer with IP networking, one of the first documents to consult is RFC 3819, titled “Advice for Subnetwork Designers,” which includes advice for framing, adaptation to links that support only small packets, QoS and fairness, congestion and flow control, routing, and security. Many of these techniques needed to be used in putting IPv6 on top of 802.15.4. The results of that project are found in RFC 4944, which specifies the transmission of IPv6 over IEEE 802.15.4. IPv6 specifies a minimum MTU of 1280 bytes, which is much larger than 802.15.4’s 127 byte payloads. Fragmentation and reassembly are therefore a key consideration. Header compression is also important; IPv6 has 16 byte addresses, and the IPv6 header alone requires 40 bytes. Header compression shrinks that into one byte in many cases.
6LoWPAN was designed in part around energy management. Most sensors are battery powered, and looking at the raw capacity of batteries illustrates the severe constraints that many devices operate under. A standard AA battery has a capacity of about 2,000 milliamp-hours (mAh), or, if we convert to seconds, about 7.2 million milliamp-seconds (mAs). That means that a battery-powered device that is expected to provide a year of battery life must consume no more than about a quarter of a milliamp per second for each of the 31 million seconds in a year—and that is the total power consumption of the device, not merely the wireless interface!
In addition to reducing the power required to run the wireless interface on sensors, Thread adds mesh connectivity. With the target 6LoWPAN device as something like a battery-powered sensor, the underlying connections are often intermittent to conserve power. Gateways between the sensor network and the rest of the Internet are likely to be continuously powered, but there are no guarantees that the individual sensors are. Mesh connections give sensors a way to deliver data without needing extensive network administrator intervention. The core Thread code includes, among other files, mesh_forwarder.cpp and mle_router.cpp.
By using open source code to establish a de facto standard, Nest has taken a big step to commoditizing the raw connectivity necessary to make networked sensors work well. If successful, the next step will be to move up the protocol stack and define standard ways of communicating information and events, shifting networking from moving low-level packets to moving high-level concepts, which is in many ways the next frontier in networking.