Home arrow Blog arrow Zigbee arrow Zigbee Alliance Aiming at IPv6 Support
Zigbee Alliance Aiming at IPv6 Support | Print |
Written by Akiba   
Saturday, 01 March 2008

The Zigbee Alliance announced that they're forming an "Internet Solutions Initiative" to investigate ways of integrating IP networking into Zigbee. Translation: They're forming a new IP6 group.

Looks like they've taken notice of the work thats going on over at 6LowPAN and Adam Dunkel's Contiki/uIP project . Anyone thats familiar with the Zigbee spec knows that its almost a one to one correspondence with TCP/IP. The Zigbee NWK layer is analogous to the IP layer, the NWK routing protocol, AODV, is analogous to IP's RIP or OSPF, and the Zigbee Application Framework is analogous to the TCP layer (without the TCP state machine and the weird sequence space thing). Zigbee has endpoints, TCP has ports. Zigbee has endpoint grouping, TCP has port binding. The list goes on and on.

One of the main benefits of Zigbee is that the protocol is designed for operation over wireless networks and was basically designed to fit 802.15.4. 6LowPAN on the other hand is doing double-back-handsprings-with-a-twist to get IPv6 to fit into the 802.15.4 frames.

The problem that arises is that IP wasn't meant to be packaged into a 128 byte frame. The IPv6 header alone is a whopping 40 bytes or almost 1/3 of the frame size. If they integrate TCP, they'll have even more overhead to deal with. TCP/IP fits better into ethernet frames where the max frame size is 1580 bytes (I think). In that case, the protocol overhead is a much lower percentage of the overall traffic and they can transport larger amounts of data. In fact, that hits on an important point. TCP/IP is designed for data intensive communications. Zigbee/802.15.4 is designed with the low power/low duty cycle requirements of wireless sensor networking in mind. So thats one of the big challenges of integrating Zigbee and IP, or even IP and 802.15.4. I don't think I will need to access all of my nodes from Firefox. So would it be bad to just use a Zigbee/IP bridge or gateway at the coordinator?

p.s. I wonder how 6LowPAN and ArchRock respond to this?  

Hits: 11464
Trackback(0)
Comments (2)Add Comment
Zigbee and IP
written by 6lowpanner, March 04, 2008
I find it funny that Zigbee claims that they can already gateway IP. This is not true. The Zigbee alliance has had a gateway working group since its inception that was supposed to define an IP gateway and in the past 6 years they have not been able to figure out how to gateway zigbee to IP - each vendor must define their own proprietary gateway. This is due to the 1,2,7 architecture that zigbee defined. It means that you must create a gateway for each and ever profile and as the profile changes so must the gateway.

Contrary to what you say in your blog, the zigbee layers do not at all match with IP. The zigbee network layer is a layer 2 mesh network. It has a huge monolithic header to deal with mesh routing, fragmentation, ... The modified aodv routing that Zigbee uses (it is not standard AODV - zigbee needed to make gratuitous changes) is not akin to rip or ospf or aodv routing known in the IP world because Zigbee is a mesh (and a mesh it is) at layer 2 (layer 2 routing - not layer 3 routing like rip or IP routing) and as a result it is an integral part of the layer 2 frame format.

If you take a close look at 6lowpan, there were no handstands or backflips to put IPv6 into 15.4. In fact the most common 6lowpan header to carry IP and UDP is just 5 bytes compared to at least 14 bytes for the standard zigbee header! And the 6lowpan header can be expanded into a standard ipv6 header extremely easily at a simple bridge between the wired and wireless world. With Zigbee you need to translate (a much more complex task) when you want to talk to an IP network.

I don't know why you would compare zigbee with using TCP. No one, even 6lowpan, expects anyone to use tcp to transport packets. UDP, which makes more sense for sensors and small data packets, is the most likely protocol, which is why the 6lowpan RFC defines a way to compress the udp header. (if you want or need tcp, it is available - again unlike zigbee where a reliable ordered protocol would need to be designed.

Perhaps you don't want to talk to your nodes from Firefox, but perhaps you do want to use the tools and knowledge that you might already have with IP based networks rather than have to learn and invent everything from scratch, as with Zigbee.

So in the end, 6lowpan headers are actually smaller than Zigbee, 6lowpan is easier to interconnect with existing IP networks, 6lowpan nodes can use existing IP based tools and protocols and devices rather than having to event everything from scratch.
report abuse
vote down
vote up
Votes: +3
Zigbee and IP
written by Akiba, March 06, 2008
Hiya.
Thanks for being the second person to post on my blog.

Hmmm...Last place I want to be is in a protocol war. Actually, I'm not a diehard supporter of any technology or protocol. I'm more like a jaded implementer. However ...

"The zigbee network layer is a layer 2 mesh network."
According to Wikipedia:
OSI Layer 1 = PHY
OSI Layer 2 = MAC LLC
OSI Layer 3 = NWK

Maybe I got blinded by the fact that the IEEE 802.15.4 layer specs are called MAC and PHY and the Zigbee layer above it is called NWK.

"The modified aodv routing that Zigbee uses (it is not standard AODV - zigbee needed to make gratuitous changes)"

Okay, now you're just being picky.

"If you take a close look at 6lowpan, there were no handstands or backflips to put IPv6 into 15.4. "

Maybe no handstands or backflips. But some contortionism to compress the IPv6 header.

The modified aodv routing that Zigbee uses ... is not akin to rip or ospf

Umm...RIP and AODV are both distance vector based routing algorithms. Also, I think my meaning was... AODV:NWK :: RIP:IP (in old SAT terminology), not AODV = RIP.

UDP, which makes more sense for sensors and small data packets, is the most likely protocol, which is why the 6lowpan RFC defines a way to compress the udp header. (if you want or need tcp, it is available - again unlike zigbee where a reliable ordered protocol would need to be designed.

UDP is basically unacknowledged transport. TCP uses ordered (that weird sequence space thing), aknowledged transport, along with the state machine. Zigbee also supports unack'd as well as ack'd frames from the Application SubLayer (APS) although it does not support ordering.

Perhaps you don't want to talk to your nodes from Firefox, but perhaps you do want to use the tools and knowledge that you might already have with IP based networks rather than have to learn and invent everything from scratch, as with Zigbee.

I agree with you. The learning curve will be higher with Zigbee, whereas we can just recycle all of the CCNAs out there if its IP based.

So in the end, 6lowpan headers are actually smaller than Zigbee, 6lowpan is easier to interconnect with existing IP networks, 6lowpan nodes can use existing IP based tools and protocols and devices rather than having to event everything from scratch.

Hmmm...you should be the marketing guy for 6LowPAN.

Anyways, as imitation is the highest form of flattery, you should be pleased that Zigbee is trying to travel down the same road. As for me, I'm neither an alliance member (I can't afford the dues) nor a WSN expert. I just call it as I implement it.

Akiba
report abuse
vote down
vote up
Votes: +5

Write comment

busy
  No Comments.

Discuss...
< Prev   Next >