|
After finishing the simple routing simulator that I wrote in C, I was confident that my implementation of the routing algorithm would work. So I then started to integrate the code into the main Zigbee NWK layer. I had to make a couple of decisions, and as usual, there were tradeoffs associated with the decisions. One of the decisions I had to make was how to handle route discovery. According to the spec, there are two methods to initiate route discovery. The first is that the route discovery service is invoked by a higher layer (APS). The second is that a frame arrives with the route discovery option set (in the NWK frame control header) and the destination address of the frame does not exist in that device's routing table. My problem mostly dealt with the second option, which is a frame with an unknown destination arrives. How should it be handled? There were a couple of options, but the two most obvious ones were: - Keep the frame and initiate route discovery. Don't forward the frame until the route reply arrives (giving the route) or the route discovery times out.
- Advantage: Simplest method. Consumes least resources (RAM, code size).
- Disadvantage: Performance suffers. Cannot process other frames until current one is finished. Route discovery can potentially take up to 10 seconds.
- Buffer the frame in a waiting queue and initiate route discovery. Continue processing other frames until a route reply arrives.
- Advantage: No hit in performance. Seriously, 10 seconds is tooooo long.
- Disadvantage: More complexity. Yet another queue that needs to be implemented. RAM and flash required to implement.
Okay, that decision was a no-brainer. There's no way in hell that user's would tolerate a 10 second lag when you're trying to find the route for a frame. I mean a 10 second lag is the difference between me surfing a site and pushing the stop button on my Firefox browser. I decided to create a queue called a pending queue where I would put frames pending route discovery. So if a frame with an unknown destination arrives, I would simply store it in the queue along with its headers and start the route discovery process. When a route reply arrives, then I will forward it, or if not, I will timeout the discovery and forward using tree routing. Buffering the frame has another advantage. I didn't really need the route discovery service anymore. Before, you would do a route discovery from the APS before you sent out a transmission to make sure that either the route existed in the table, or if not, it would by the time the frame was transmitted. However, we can simplify things by just sending all frames, local and non-local frames to the same network forwarding function. The nwk forwarding function would make the decision to buffer the frame or not based on whether the route exists. It doesn't matter if the frame was generated by the device or came from the outside since the decision to buffer is only dependent on whether the route exists (whether route discovery is needed). Not bad! So to make a long story short, I went along with this ...ahem... route. There were other decisions that needed to be made for the nwk layer data path as well, such as whether or not I should use a process to handle the buffering and forwarding. Many TCP/IP stacks do this in the IP layer, but I decided that at this point, I would not use a process (thread). I want to minimize my usage of processes since it will make porting to a different OS more difficult, as well as potentially complicate things. For now, I'd like to keep things as simple as possible, with tweaks made after I can establish basic functionality.
Trackback(0)
 |
TrackBack URI for this entry
Subscribe to this comment's feed
Show/Hide comment form