If you pay much attention to the futurists on the Web these days, no doubt you’re familiar with the term “Internet Of Things.” It may be yet-another-buzzword, but the central concept is quite real: the spread of low power, Internet-connected devices that use wireless networks to communicate with our PCs and servers. After all, you don’t need a computer in your water heater or electric meter: you just need a sensor, and way to read it remotely. Linux will be a major player in this space, but most developers still aren’t familiar with the network standards that make it work, like IEEE 802.15.4.
80-What?
802.15.4 is a specification from the IEEE’s 802.15 working group, which tackles wireless “personal area” networks, or WPANs. The standard defines a physical-layer and media access control specification, meaning that it covers the frequencies and negotiation options of the connection, but not the protocols that run above it. This is essentially the “link layer” of the Internet protocol stack; akin to raw Ethernet frames or to the more-familiar 802.11* WiFi specifications.
The standard is designed to run on very low-voltage hardware, such as you might find in an embedded device that needs to run on battery power for months or even years at a time. Such a WPAN is designed to function with a roughly 10 meter antenna range, and various transfer speeds are defined, from 20 kbps up through 250 kbps. In addition to working with low-power hardware, the standard was written to accommodate very easy-to-manufacture (and thus very inexpensive devices).
One way that this is done by defining two classes of nodes: full-function devices such as PCs, and reduced-function devices (RFDs) like embedded sensor devices. RFDs can only communicate directly with full-function devices, so that the beefier hardware can shoulder the burden of managing the network, routing messages, and other overhead. Such a network-coordinator node can also define a synchronization schedule, which helps keep the RFDs from colliding with each other by defining fixed, predictable slots for transmitting data packets. The coordinator node sends out regular beacon messages to help the RFDs keep time by simply listening for the beacon whenever they need to transmit.
There are several frequency bands available to 802.15.4 devices, including the global 2.4 GHz band, the 868 MHz band in Europe, and the 902 MHz band in North America. There are emerging standards for China and Japan as well, in concert with those regions existing spectrum allocations. Given the short ranges and embedded uses of most low-power sensors, it is not expected that RFDs will need to migrate between bands, but this could potentially be a concern for full-function devices.
To make any of this low-level communication meaningful, of course, other layers need to be stacked on top, to handle IP packets, TCP connections, important features like security and authentication, and eventually actual application protocols.
Protocols and Software
This, however, is where things get tricky, because 802.15.4 is most widely recognized in concert with the ZigBee protocol suite. ZigBee hardware is relatively inexpensive (in fact, you may have seen it for sale for Arduino projects and other DIY electronics), but the software is a proprietary protocol stack that is incompatible with Linux’s GPLv2 license. There are other proprietary offerings as well, but more importantly, there are uses for 802.15.4 that build on open standards.
Not all protocol stacks are applicable to the hobbyist, of course. WirelessHART and ISA100.11a, for example, are both intended for industrial automation. The simplest option, however, is 6LoWPAN (which is short for IPv6 over Low-power Wireless Personal Area Networks); an official IETF project to adapt IPv6 network to low-power hardware. When you think about it, the two are a natural fit — the low cost and irregular field deployment of autonomous smart sensors virtually demands the increased addressing and simplified routing of IPv6.
6LoWPAN is defined in RFC 4944. The specification details how to split standard IPv6 packets up into the shorter frames used by 802.15.4, how a full-function node coordinating a WPAN can assign IP addresses to RFDs, and how to route packets through a mesh-network of low-power nodes. Some of these problems run up against peculiar challenges not encountered by IPv6 on other network types — for instance, the low-power hardware may not listen constantly for network traffic, which can make it difficult to discover the topology of the network.
Consequently, new routing algorithms like the 6LoWPAN AD-hoc routing protocol (LOAD) have resulted. There is also work on bringing service discovery to 6LoWPAN, and on optimizing the higher-level IETF protocols like TCP and UDP for the frame sizes and transmission speeds of 802.15.4. Simple electronic sensors might not need the full use of TCP/IP, of course, but supporting the standard Internet infrastructure on embedded devices paves the way for other interesting 802.15.4-based possibilities, such as remote controls that natively speak TCP/IP.
802.15.4 support was merged into the mainline Linux kernel at version 2.6.31, but 6LoWPAN support did not land until January 2012 with version 3.2. For the curious, the code lives in net/ieee802154/ in the standard tree.
The Linux ZigBee project (which is admittedly a confusing name, considering that it does not implement ZigBee itself for the aforementioned licensing reasons) is the epicenter for both 802.15.4 and 6LoWPAN support. As of kernel 3.2, the project reports that basic 6LoWPAN support is working now, but that kernel 3.3 will bring important improvements like fragmentation. There are a number of work-in-progress points to the underlying 802.15.4 layer as well, including message queuing and status messages.
However, the project is alive and well. There are even userspace tools to locate and connect to nearby devices, to perform basic network coordination, and to monitor an 802.15.4 network with patched versions of existing tools like tcpdump and Wireshark.
What Can You do Today, and With What Hardware
That said, it is unlikely that your standard desktop distribution compiles in 802.15.4 support in it standard packages; thus if you are interested in experimenting with low-power devices or 6LoWPAN, you will probably need to compile your own modules and device drivers.
The list of devices supported by the project is short, but it includes both serial dongles and SPI boards.
One of the 802.15.4 chips on the Linux ZigBee project’s supported list is the Atmel AT86RF231, which transmits and receives on the globally-available 2.4GHz band. This chip is also used in a new USB dongle called the Ben WPAN, an open source hardware design manufactured by Qi Hardware — the same folks who make the ultra-small Ben Nanonote that we covered in 2010. A version of the dongle that plugs directly into the Nanonote is also available.
Qi Hardware has the Ben WPAN working with a modified version of the upstream 802.15.4 stack (which will presumably get merged back in somewhere down the line). They have demonstrated that two Ben WPAN-equipped Nanonotes can establish a network connection and talk to each other. Moving forward, a working USB option will certainly open the door for more coders simply because of the bus’s ubiquity.
The situation on the embedded device side of the fence is not quite as simple. As you might expect, most commercial sensor manufacturers are more interested in producing ZigBee-certified products than they are with maintaining a fully open source environment. However, there are smaller manufacturers interested in producing usable hardware without the constraints of the licensing certification process used by ZigBee, and we are beginning to see movement towards open protocols there too. A good place to watch is Freaklabs, which produces Arduino-compatible hardware.
802.15.4 certainly has not yet hit the “tipping point” required for mass adoption to take off — if it had, we would no doubt see Linux companies investing more heavily in device drivers and networking code for the kernel implementation. However, arguably the best news on this front is that the rumor mill suggests that the ZigBee Alliance is shifting its attention from its current proprietary design to an open standard based on the IETF TCP/IP stack — and in all likelihood on 6LoWPAN itself.
That the ZigBee Alliance would focus on an open standard makes sense from a business standpoint. You can certainly find examples in the past of a closed model opening up to accommodate Linux and open source (e.g., Bluetooth). What that will mean for us is a lot more new hardware to experiment with, based on embedded, smart devices where there is plenty of new excitement to be uncovered.
(Image from the Qi wiki, under CC-by-SA 3.0)
