6lowpan/ROLL support on 802.15.4 radios

From eLinux.org
Revision as of 00:36, 7 January 2011 by Tim Bird (Talk | contribs)

Jump to: navigation, search
6lowpan/ROLL support on 802.15.4 radios
Jon Smirl


802.15.4 is the radio layer of Zigbee. Zigbee is being deployed in smart meters all over the world with most of the activity in California. The next generation of Zigbee is being converted to run on TCP/IP instead of the proprietary Zigbee protocol. TCP/IP over 802.15.4 is the subject of two IEFT working groups - 6lowpan and ROLL. 6lowpan and ROLL are targeted to be GPL compatible unlike the exisiting proprietary Zigbee protocol. COAP is the application layer protocol used on top of 6lowpan/ROLL.

I'd like to buy a wireless router incorporating wifi and 802.15.4 but they don't exist yet. That's probably because there is no 802.15.4 support in Linux yet. I've been playing with writing this code in my spare time but I'm not making much progress. Proposal is for 6lowpan/ROLL to be implemented in the kernel. A user space library would implement COAP.

Primary beneficiary of this work is the Linux based router manufactuers - Linksys, DLink, Netgear, Buffalo, Trendnet, Asus, Belkin, Cisco, etc... Once the code is in the kernel is becomes simple to produce a router that bridges from Ethernet to wifi to 802.15.4.

RF4CE is 802.15.4 based remote controls. Once the ground work for 802.15.4 support is laid it should be possible to support these devices. Target for this is set top boxes.

This is not a proposal to implement the existing Zigbee protocols. Zigbee licensing is GPL incompatible. The Zigbee Alliance board has been asked to fix their GPL compatibility issues in the same manner that Bluetooth fixed them, but the Zigbee board declined to make the changes.

Related work

Linux Zigbee project - http://sourceforge.net/apps/trac/linux-zigbee/ 6lowpan at IETF - http://datatracker.ietf.org/wg/6lowpan/charter/ ROLL at IETF - https://datatracker.ietf.org/wg/roll/charter/ COAP at IETF - https://datatracker.ietf.org/doc/draft-ietf-core-coap/ GE Nucleus - http://www.geappliances.com/home-energy-manager/power-usage-monitor.htm Redwire hacker site - http://mc1322x.devl.org


My estimate is 26 person weeks for the initial implementation and testing. Another 13 person weeks (half-time) to support CELF members who incorporate the code. Possible need for travel budget to go to IETF meetings. This is too big for a spare time project.

Contractor Candidates

Redwire LLC - http://www.redwirellc.com


Just to make it clear. There is ieee 802.15.4 support in linux. One part of it
is already in mainline: net/ieee802154 but the MAC layer part is still missing
and only available in the linux-zigbee git repository together with several
drivers based on it. I would not say the code is production quality but at least
reasonable to work with.

This covers only 802.15.4. In terms of Zigbee this are only the two lowest
layers and everything Zigbee specific is missing due to the reasons you already
listed. So the project name, zigbee-linux, is a bit misleading at best as it
only covers IEEE 802.15.4 :)
      Stefan Schmidt
The 802.15.4 part that is already in the kernel is from the
linux-zigbee project referenced in the original post. That's just
enough code to get the packets out of the hardware and push them up to
user space. I suspect there are private user space ZIgbee
implementations using this code.  They're in user space because of the
GPL incompatibility of Zigbee.
The linux-zigbee project was started by Siemens as a in-kernel implementation of
Zigbee. When they discovered the GPL incompatibility the switched to
MAC only. Have they built a private Zigbee implementation on top of
this? I suspect they have because Dmitry complained which I tried to
change the interface to user space.
Maybe the Linux Foundation could convince the Zigbee board to fix
their licensing. Bluetooth originally had the identical problem. The
Zigbee license requires all developers to pay $3000/yr. Putting the
Zigbee code into the kernel would subject all kernel developers to
this $3000/yr requirement plus the GPL doesn't allow that. Bluetooth
had a fee like this originally and then later dropped it.  The GPL
compatible way of doing this is to put the fee on use of the brand -
the Zigbee name and logos. I suspect the companies selling Zigbee
stacks were behind blocking this switch.
> 1) Does this proposal also cover the task of bringing the outstanding mac802154
> bits into mainline? They are needed for a lot of drivers and interaction with
> the 6lowpan stack.
I just made a first attempt at the proposal. If it is under serious
consideration it needs to be fleshed out a lot more.  Yes, it would
make sense to include the MAC support.

Another missing part is interoperability testing. That may require
some travel (IETF plugfest) and equipment purchases.

Obviously the top requirement is to get the code into the kernel. I
know of five half finished projects building Linux support for
6lowpan/ROLL. None of them are close to be production ready. 

> 2) Would the code be based on the contiki 6lowpan implementation or would it be
> a fresh start?
In my effort I started from the Contiki code. It is not a straight
port, the Linux networking architecture is very different than
Contiki's. I got halfway into it and figured out that I had made
design mistakes in the architecture. One of the network gurus needs to
advise us on how to correctly hook into the existing TCP/IP stack;
snitching the BSD licensed code from Contiki is the easy part.

BTW, the Contiki 6lowpan/ROLL implementation is only about 80% there -
a lot of the hard bits are missing. For example no one has implemented
a line of link level security code.
> Especially 1 seems to be a dependency if the 6lowpan code would be targeted for
> mainline. I worked on the ieee802154 linux stack and drivers and will do it
> again next year. While Dmitry does a good job in keeping the linux-zigbee tree
> up to date wrt mainline it is still somewhat frustrating to work against it
> instead of mainline where all the other stuff lands.
> I don't want to open up a can or worms here with these questions just want to
> get a better understanding what this proposal would cover.
I proposed Redwire as a contractor since they are actively developing
the ROLL support for Contiki. They are primarily familiar with
6lowpan/ROLL and less familiar with the kernel. One the plus side they
are reasonably priced and should be available. There are several other
firms than are better suited to do the work but they are selling
Zigbee implementations.

One mystery to me is why no one from the router manufacturers is
working on this. Cisco is quite active in the 6lowpan/ROLL IETF group.
   Jon Smirl