This thread discusses the Content article: Zigbee Mesh routing - Interactive Tutorial

Hi
this was of great help. I had gone through the rfc for AODV and since then i have this doubt. The parameter sender, how is it being transmitted because the message format specified for RREQ does not have a field for sender..it takes care of destination and originator addrs only....cud u explain that part...?
thanks

Yeah, it's kind of tricky. You have to look at how addressing works at the NWK layer and also the MAC layer. The MAC layer specifies the next hop and previous hop addresses. The NWK layer specifies the original source address and the final destination address. From this info, you can get the info you need to find your way back to the source.

I have started to implement the AODV algorithm and i am facing hell lot of problems.

I want to know how the reverse path and forward path maintained.
Is it that there is one route table and there is one entry for forward path and one for reverse path...?
or is it like there is a route table for forward path and another for reverse path.?

also in this concept of precursor...if i have to forward a RREP packet from a intermediate node to the precursor...im not able to decide which precursor i have to send because in my route table there are multiple precursors....

i am totally stuck in this...

Forward and reverse paths are separate entries in the routing table. You can do symmetric links to save the cost of the entry, but in general, you'd need to do a discovery both ways.

For forwarding the route replies (RREP), you should have an entry in the discovery table that will tell you where the sender of the RREQ was. You should only have one entry for the sender, and the code should update the sender if a RREQ comes in with a better path cost. That's where you would forware the RREP.

Thanks for the clarification. i was trying to implement a single route table and a single entry for a route which was causing all sorts of doubts. now i am planning to implement a discovery table that will fix my RREP forwarding problem.

the rfc for adov is a bit confusing. can you tell me if i have covered every thing to take care of forwarding a RREQ.this is what im doin:
1. check if the node which got the RREQ is the destination if so send RREP to precursor
2. if the nde is not destination then,
2.1 decrement TTL
2.2 check if the destination sequence number in the RREQ packet is lesser than what is there at the node.which ever bigger update in packet only not route table
2.3 update discovery table f required
2.4 increase hop count
2.5 broadcast new RREQ packet.

is this fine..?

If it works, do it...

i have this doubt about hello msg. Are hello msgs sent to all the neighbors of the node or only to the nodes in the active path?

Zigbee uses link status messages to ping the links at a specified period. The links are pinged as a one-hop broadcast with no retries hence, they go to everyone within listening range, ie: all neighbors.

Hi
what all would be the entries for a reverse path route entry?

can i maintain discovery table ie precursor address, originator address and RREQ id at every node instead of reverse path entry in the route table?

i will do this while im sending RREQ, and when i reach the destination node, i will start creating route table entry for the destination. is this alright?

Discovery table is implemented on every node and holds a temporary entry for the particular route request. It does not just exist on the reverse path. It is used to find the reverse path and keep track of the path cost.

Im not clear with the what should i update in the route table while dealing with RREQ packets.
my route table has following entries:
dest address
dest seq num
next hop
hop count
lifetime
list of precursors
valid dest seq flag
state flags....

but while i do a path discovery i don't have values for all the entries. what am i suppose to do then. is it enough that i maintain only discovery table while i propagate RREQ and make entries to route table while i create and send back RREP...?

I will be waiting for a reply before i start this implementation....

can i maintain a discovery table and avoid using a reverse path entry in the route table...if im sure that i will always have a single source.

You're going about this the wrong way. When I was first designing the AODV portion of the routing, I wrote a very small application on the PC that would simulate portions of AODV so that I could observe their behavior. It's especially useful to observe through GDB so you can see how your variables are affected.

If you can get AODV working on a small sim/app and actually find your target nodes, then you should move on to implementing full AODV on whatever device you're trying to do it on. If you're trying to do a full implementation without understanding what you're implementing, it's doomed to failure.

hi
Actually we are using a similar style for AODV implementation (first on the PC and then on the board) only thing is that 5 of us are taking up different parts of the algorithm and trying to implement their own part. once that is done then would come the testing part. Only after the testing would the integration start.

Im involved in the path discovery part which takes care of the forward and reverse path setup.

So is it necessary to maintain the reverse path or can i omit that entry in the route table and maintain a discovery table. The RREP packet would take help of the discovery table to get back to the source.

and discovery table would exist as long as the path exists.

can you help me find some flaw in this implementation.?