6LoWPAN Goes Where ZigBee Can't
Many “standard” and proprietary protocols use the media-access controller (MAC) and the physical circuits (PHY) associated with IEEE 802.15.4 radios. Those protocols use their own arrangements of bits and bytes to transfer information between nodes, but none of them use the Internet Protocol (IP). So they cannot directly communicate with Internet-based devices and Web servers/browsers. The IPv6 over Low power Wireless Personal Area Networks (6LoWPAN) standard offers an alternative because it employs the IPv6 protocol and can operate equally well over wireless and wired connections.
To find out more about 6LowPAN, I talked with Geoff Mulligan, the chairman of the IP for Smart Objects (IPSO) Alliance and 6LoWPAN Working Group Chair. "When I worked for Invensys, we started a project to put wireless IPv6 communications in smoke alarms and appliances. The header and address information for IPv6 amounts to 40 bytes. But the 802.15.4 packets have only 127 bytes, so IPv6 would take much of the available space. Some bright engineers came up with the idea of compressing the IPv6 header information so it needs only three or four bytes on average."
The compression is completely stateless, which means that it creates no binding state between the compressor-decompressor pair. Stateless compression gives nodes the flexibility to communicate with any neighbor in compact form at all times.(Ref 1.) In addition, the stateless compression gives a network multiple entry and exit points, whereas a "stateful" network is susceptible to single-point failures.
"As a result of stateless compression, the 6LoWPAN community has software 'stacks' that require less RAM and ROM than a ZigBee stack, for example," added Mulligan. "Instead of having a monolithic header, you only add the bits and bytes you need for, say, fragmentation or mesh routing. If you don't need those capabilities, the packet doesn't carry that type of information, thus reducing the overhead."
The Internet Engineering Task Force (IETF) oversees the 6LoWPAN standardization and specification work under Request for Comments (RFC) 4944. The specifications are open and developers can buy 6LoWPAN code, use open-source code, or write their own. But 6LoWPAN communications don't require a complete rewrite of an IEEE 802.15.4 radio stack. Instead, 6LoWPAN adds an adaptation layer that lets the radio stack and IPv6 communications operate together.
"The beauty of 6LoWPAN communications is that they let people communicate with devices across the Internet without having to go through, say, a ZigBee-to-IP translation step," explained Mulligan. "If they have a network of sensors in Antarctica the Internet will connect them directly to it. When the sensor bridge-network connects to Internet, it 're-inflates' the compressed headers and puts back all the needed IPv6 information."
The lack of gateways that translate protocols also improves end-to-end communication security. If you use a gateway to connect a proprietary network to the Internet, you have two security "spheres;" one for the Internet and one for the proprietary network. That arrangement provides a potential point of attack that could destroy the integrity of the end-to-end link.
"Work on the 6LoWPAN specifications continues," stressed Mulligan. "Engineers are working to answer questions such as how do users commission a network and how do they establish good security so their network doesn't connect to a neighbor’s network?"
The 6LoWPAN hardware relies on the IEEE 802.15.4 radio-communication standard and although IPv6 is relatively new, the Internet Protocol has over 30 years of history behind it. So, 6LoWPAN equipment should not encounter any problems with the other type of IP--intellectual property. Large companies such as IBM, Sun, Cisco, and Microsoft have invested heavily in IP-based communications and would not have done so unless the believed the IP had no hidden patent liabilities. Unfortunately, proprietary or emerging network hardware and software standards might run up against existing patents that engineers have yet to uncover.
Companies offer development kits that can help developers kick start a 6LoWPAN project or just investigate its capabilities. Sensinode (www.sensinode.com) offers a K210 6LoWPAN Devkit and Atmel (www.atmel.com) provides its 2.4 GHz Evaluation and Starter Kit (ATAVRRZRAVEN) that runs a port of the Contiki 2.2.2 OS, which contains the small uIPv6 stack and SICSlowpan 802.15.4-over-IPv6 compression (http://www.sics.se/contiki). Arch Rock (www.archrock.com) has a PhyNet OEM Development Kit (IE version) that comes configured with the PhyNet IE Engine that lets developers use direct C API calls to the Arch Rock IP/6LoWPAN linkable kernel library to access operating-system services and standard TCP/UDP/IP-based networks. Jennic (www.jennic.com) also offers a 6LoWPAN Network Protocol stack that operates with the company's JN5139 wireless microcontrollers and modules.
If 6LoWPAN sounds interesting, but you have a ZigBee or other 802.15.4 project in the works you can still implement 6LoWPAN communications later. Just ensure you can "reflash" your firmware in the field so it can accept code for a 6LoWPAN stack. According to Mulligan, at least one utility company will take this approach with its first meter-reading equipment.
1. Abeille, Julien, et al., "Lightweight IPv6 Stacks for Smart Objects," IPSO Alliance White Paper 2. www.ipso-alliance.org.
For further reading
Culler, David, "Secure, low-power, IP-based connectivity with IEEE 802.15.4 wireless networks," Industrial Embedded Systems, 2007. www.archrock.com/downloads/resources/ArchRock.Sum07.pdf
Mulligan, Geoff, “The 6LoWPAN Architecture," EMNETS2007 http://portal.acm.org/citation.cfm?id=1278972.1278992
For IETF RFC-4944 and RFC-4919 documents, visit:
www.ietf.org/rfc/rfc4944.txt and www.ietf.org/rfc/rfc4919.txt