Freaklabs - Open Source Wireless - Zigbee Network Lay...

http://freaklabs.org/index2.php?option=com_content&t...

Zigbee Network Layer Tutorial - Part 2: The Rx Data Path

Written by Akiba Wednesday, 13 May 2009

| Print |

I left o last time explaining the transmit data path side of the Zigbee networking layer. The receive data path is fairly similar, but there are some minor complications. When a frame arrives over the air, the radio driver will take it out of the buer and store it somewhere. It should then signal the next higher layer (in this case the MAC) to retrieve the frame. Incidentally, this part of incoming data handling is common to just about every protocol stack. I refer to it as the launch although I dont know what the formal term is. I call it the launch because its the entry point of data into your stack. In general, most stacks that Ive encountered handle things the same way where the hardware signals data arrival with an interrupt, the data is read out of the hardware buers by the driver, its put into a holding area (list, queue, circular buer), and then the next layer is signaled to pick it up when it can. This way, the ISR is kept short and frame dropping is minimized in the case of heavy trac. Anyways, back to the story. After the launch, the MAC layer would pick the frame up from its holding area, strip o and decode the MAC header, and then if its a MAC data frame, pass it up to the NWK layer. The frame reaches the NWK layer via the MACs Data Indication service. Once in the network layer, the network header will get stripped o and processed. This is kind of the generic way to handle an incoming Zigbee frame and I think most stacks will do something fairly similar. From here, it pretty much depends on the implementation so Ill describe how I handle the network frame processing in the FreakZ stack. After I have the network header parsed and tucked away neatly inside a structure, the rst thing that happens is that the frame needs to be decoded according to its type. There are only two frame types at the network layer: data frames and command frames. The frame type is contained in the header information so its easy to gure out what it is. In the case of a data frame, there are three cases that need to be handled: The rst case is the easiest one where the frame is meant for us. To determine this, you need to check the destination network address and see if it matches the devices network address. As I mentioned in part 1, the destination address in the network header is absolute. So if the destination network address matches our network address, then we can be sure that were the nal destination for this frame and just send it up to the next layer. If the destination address doesnt match our address, then the next thing I do is check to see if its a broadcast. If its a broadcast, then we need to initiate a special sequence of events because broadcasts need to be handled carefully. The dangerous thing about them is that broadcasts can grow exponentially if theyre not handled properly and theyll quickly overwhelm the memory of your devices, causing your network to crash. Ill be discussing broadcasts in more detail in the later parts where I examine each of the network services. Also, since a broadcast hop is still considered a hop, we need to decrement the frame's radius value. If you remember from part 1, the radius is used to limit the max number of hops a frame can travel. Basically any time a frame needs to be re-transmitted, the radius value will be decremented. And nally, if were not the nal destination for the frame, and its not a broadcast frame, that means that were just a hop on its way to the nal destination. From there, the sequence of events is similar to the transmit data path discussed in part 1. We need to nd the next hop address to send the frame, forward it there, and decrement the radius counter. Since we have a commonality like this, I made a simple optimization where both the transmit and the receive side share the same forwarding function.

1 of 5

Friday 28 September 2012 05:35 PM

Freaklabs - Open Source Wireless - Zigbee Network Lay...

http://freaklabs.org/index2.php?option=com_content&t...

In the case that the incoming frame is a command frame, then I just decode it based on the command ID. This will always be the rst byte of the payload so its fairly easy to get this value. From there, its just handled according to the management function that it needs to accomplish. The command frames in the network layer handle common network maintenance tasks like mesh route discovery, link maintenance, and rejoining and leaving the network. Ill be going into this in more detail later on as well. Hmmmthat went by a lot quicker than I expected. That's disappointing because it seemed much more dicult when I was writing it... Updated 2009-05-13: Thanks to some of the feedback from the readers as well as certain Zigbee spec authors, I changed how I discussed the radius handling. I previously had the radius decremented and checked at the entry point of the NWK rx function. However I changed it so that the radius is only checked if the frame will be re-transmitted. This is in compliance with the wording in the Zigbee specication on how the radius should be handled. The code was modied as well to reect this.

Hits: 13117

Email This

2 of 5

Friday 28 September 2012 05:35 PM

Freaklabs - Open Source Wireless - Zigbee Network Lay...

http://freaklabs.org/index2.php?option=com_content&t...

Trackback(0)
TrackBack URI for this entry

Comments (11)
Subscribe to this comment's feed

Radius written by Robert Cragie, May 13, 2009 I don't think you will ever get a frame with radius 0 in the ether. The rx processing works as follows: Decrement radius. If radius is 0, process frame but do not forward it. If radius >= 1, process frame and forward. Votes: +0 vote up vote down report abuse ... written by Akiba, May 13, 2009 Hmmm...interesting. Looks like I have it opposite where I forward it until the radius reaches zero. Thanks for the tip. Looks like these tutorials are helping me out as well. Votes: +0 vote up vote down report abuse ... written by Michael Stovenour, May 13, 2009 From the 12/1/2006 ZigBee Specication (053474r13) "If, as a result of being decremented, this value falls to 0, the frame shall not, under any circumstances, be retransmitted. It may, however, be passed to the next higher layer or otherwise processed by the NWK layer as outlined elsewhere in this specication." I agree with Robert's paraphrasing of the algorithm. I think zero after decrement should still be delivered to the local apps layer, but not forwarded. Maybe that's what Robert means by "process". I still think checking for zero is OK, since you never know if the other guy is doing the right thing. Question is if you get a zero o the wire do you deliver it to the local apps layer? Delivering it is technically compliant, permissive within reason, and not likely to cause a interoperability issue. Votes: +0 vote up vote down report abuse ... written by Akiba, May 13, 2009 Ha ha ha...I can take a hint. I'll be adding the modication. I'll probably just be changing the position of where I check for the value and decrement. Instead of checking at the beginning, I'll just be checking and decrementing when I forward the frame. If a frame with a 0 radius arrives, then it will still be able to be processed. It just won't be allowed to be forwarded any more. Hmmm....glad this article could stimulate a discussion in this rather arcane subject Votes: +0 vote up ... written by Akiba, May 13, 2009 Just an FYI. I attached an update to the article and modied how I discussed the radius handling. I also modied the code to only check the radius when the frame is re-sent out. This would allow a frame that arrives with zero radius to still get processed, however prevent it from being sent out. Votes: +0 vote up vote down report abuse ...

vote down

report abuse

3 of 5

Friday 28 September 2012 05:35 PM

Freaklabs - Open Source Wireless - Zigbee Network Lay...

http://freaklabs.org/index2.php?option=com_content&t...

written by Duckyduck, May 13, 2009

Hi Akiba, I was just wondering how you handle the InterPAN trac. What I've seen happening is that other 802.15.4 InterPAN messages can sometimes crash a Zigbee stack. After receiving the "data arrived" callback from the MAC, you have to gure out if this is a Zigbee NWK frame or other (e.g. InterPAN or RF4CE or whatever). How do you handle this? According to what I've seen it's not simple do determine w/o "dispatching" the payload in the Zigbee NWK layer. BTW THanks for these great tutorials! Votes: +0 vote up vote down report abuse ... written by Akiba, May 13, 2009 I would normally suspect that if you have a network using Zigbee and a network using something like RF4CE, they would have dierent PAN IDs. If that's the case, then the automatic hardware ltering should remove any frames that don't match the PAN ID of the device. This can also be done manually in software. Basically, non-Zigbee frames shouldn't make it to the NWK layer unless the PAN ID is the universal ID 0x which normally shouldn't occur. Votes: +0 vote up vote down report abuse ... written by Duckyduck, May 13, 2009 Unfortunately a destination PAN ID of 0x will be used in some applications (like ours) :-( Votes: +0 vote up vote down ... written by Akiba, May 13, 2009 Hmmm...if you want to try a dirty little trick, you can use one of the reserved elds in the MAC header's frame control eld. This would be bits 7-9. You can encode the frame type in that eld and check it in either the driver or the MAC to discard if the frame type (ie RF4CE) doesn't match the network type (ie Zigbee). Of course in the future, the IEEE might actually use these elds, but for now, they're open and you can use these elds and still maintain interoperability. That is, unless someone else had the same idea as you and is using these elds Votes: +0 vote up vote down report abuse ... written by Dino Fizzotti, May 14, 2009 Reading this so much easier than navigating through the spec - it can only come from experience in writing your own stack! For the majority of people using ZigBee, the focus will be on the application side. Which makes troubleshooting a buggy stack all the more dicult without sucient knowledge of the inner workings (ESPECIALLY the NWK layer). So thanks for these posts, they are awesome. Votes: +0 vote up vote down report abuse ... written by Akiba, May 14, 2009 No problem. I'm glad everyone is nding them helpful. Too bad that they should have been written earlier... Votes: +0 vote up vote down report abuse report abuse

Write comment
Show/Hide comment form

4 of 5

Friday 28 September 2012 05:35 PM

Freaklabs - Open Source Wireless - Zigbee Network Lay...

http://freaklabs.org/index2.php?option=com_content&t...

Close Window

5 of 5

Friday 28 September 2012 05:35 PM