Home arrow Blog arrow Zigbee arrow Zigbee Network Layer Tutorial - Part 2: The Rx Data Path
Zigbee Network Layer Tutorial - Part 2: The Rx Data Path | Print |
Written by Akiba   
Tuesday, 12 May 2009

I left off 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 buffer 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 don’t know what the formal term is. I call it the launch because it’s the entry point of data into your stack. In general, most stacks that I’ve encountered handle things the same way where the hardware signals data arrival with an interrupt, the data is read out of the hardware buffers by the driver, it’s put into a holding area (list, queue, circular buffer),  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 traffic.

Anyways, back to the story. After the launch, the MAC layer would pick the frame up from its holding area, strip off and decode the MAC header, and then if it’s a MAC data frame, pass it up to the NWK layer.

The frame reaches the NWK layer via the MAC’s “Data Indication” service. Once in the network layer, the network header will get stripped off 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 I’ll 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 first 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 it’s easy to figure out what it is. In the case of a data frame, there are three cases that need to be handled:

The first 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 device’s 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 we’re the final destination for this frame and just send it up to the next layer.

If the destination address doesn’t match our address, then the next thing I do is check to see if it’s a broadcast. If it’s 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 they’re not handled properly and they’ll quickly overwhelm the memory of your devices, causing your network to crash. I’ll 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 finally, if we’re not the final destination for the frame, and it’s not a broadcast frame, that means that we’re just a hop on it’s way to the final destination. From there, the sequence of events is similar to the transmit data path discussed in part 1. We need to find 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. 

Zigbee Rx Data Path

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 first byte of the payload so its fairly easy to get this value. From there, it’s 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. I’ll be going into this in more detail later on as well.

Hmmm…that went by a lot quicker than I expected. That's disappointing because it seemed much more difficult 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 specification on how the radius should be handled. The code was modified as well to reflect this.
Hits: 21900
Trackback(0)
Comments (11)Add Comment
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.
report abuse
vote down
vote up
Votes: +0
...
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.
report abuse
vote down
vote up
Votes: +0
...
written by Michael Stovenour, May 13, 2009
From the 12/1/2006 ZigBee Specification (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 specification."

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 off 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.
report abuse
vote down
vote up
Votes: +0
...
written by Akiba, May 13, 2009
Ha ha ha...I can take a hint. I'll be adding the modification. 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 smilies/wink.gif
report abuse
vote down
vote up
Votes: +0
...
written by Akiba, May 13, 2009
Just an FYI. I attached an update to the article and modified how I discussed the radius handling. I also modified 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.
report abuse
vote down
vote up
Votes: +0
...
written by Duckyduck, May 13, 2009
Hi Akiba, I was just wondering how you handle the InterPAN traffic. 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 figure 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!
report abuse
vote down
vote up
Votes: +0
...
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 different PAN IDs. If that's the case, then the automatic hardware filtering 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 0xffff which normally shouldn't occur.
report abuse
vote down
vote up
Votes: +0
...
written by Duckyduck, May 13, 2009
Unfortunately a destination PAN ID of 0xffff will be used in some applications (like ours) :-(
report abuse
vote down
vote up
Votes: +0
...
written by Akiba, May 13, 2009
Hmmm...if you want to try a dirty little trick, you can use one of the reserved fields in the MAC header's frame control field. This would be bits 7-9. You can encode the frame type in that field 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 fields, but for now, they're open and you can use these fields and still maintain interoperability. That is, unless someone else had the same idea as you and is using these fields smilies/wink.gif
report abuse
vote down
vote up
Votes: +0
...
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 difficult without sufficient knowledge of the inner workings (ESPECIALLY the NWK layer). So thanks for these posts, they are awesome.
report abuse
vote down
vote up
Votes: +0
...
written by Akiba, May 14, 2009
No problem. I'm glad everyone is finding them helpful. Too bad that they should have been written earlier...
report abuse
vote down
vote up
Votes: +0

Write comment

busy
  No Comments.

Discuss...
< Prev   Next >