6lowpan/ROLL support on 802.15.4 radios


 * Summary: 6lowpan/ROLL support on 802.15.4 radios


 * Proposer: Jon Smirl

Description
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 1

Scope
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

Comments
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. Jon Smirl

> 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