Hi Ron,

On 11 Mar 2009, at 09:38, Ron Goldman wrote:

If we understand the 802.15.4 standard correctly, you have to do a random back-off in order to avoid collisions in the CSMA scheme. This seems like a good idea, to avoid simultaneous channel access when multiple nodes react to the same event and to avoid synchronization.

To us, it seems a bit strange to solve the hidden node problem at the LowPan layer, as 802.15.4 already defines the random back-off. Would it be possible to move this improvement to the MAC layer? Then also any other implementations of higher layers will be able to use regular 802.15.4, which seems like a good feature.

What do you mean by the delay being based on the number of hops the packet is sent? Would a larger number of hops imply a larger delay? Based on our experience, taking the transmission of a packet over 3 hops into account should be enough. A good estimate could be 3 times the transmission delay of the packet + some milliseconds to allow processing.

If I understand this correctly, perhaps you could combine this part with the previous optimisation and split the delay in a fixed delay (based on the back-off status, to get around the hidden node problem) and a random delay (to avoid synchronization from happening).

Why do no ACKs cause a route to be dropped? AODV should work fine for rather static topologies, if you completely implement layer 2 feedback. Chapter 6.2 of the RFC reads:

Each time a route is used to forward a data packet, its Active Route   Lifetime field of the source, destination and the next hop on the   path to the destination is updated to be no less than the current   time plus ACTIVE_ROUTE_TIMEOUT.  Since the route between each   originator and destination pair is expected to be symmetric, the   Active Route Lifetime for the previous hop, along the reverse path   back to the IP source, is also updated to be no less than the current   time plus ACTIVE_ROUTE_TIMEOUT.  The lifetime for an Active Route is   updated each time the route is used regardless of whether the   destination is a single node or a subnet.

So each time a route is used, it should become fresh afterwards. (I guess the data interval was smaller than ACTIVE_ROUTE_TIMEOUT.) However, I do realize this can create a risk that routes never change because they are considered perfect. That's why chapter 6.10 reads:

A node can maintain accurate information about its continued   connectivity to these active next hops, using one or more of the   available link or network layer mechanisms, as described below.

  -  Any suitable link layer notification, such as those provided by      IEEE 802.11, can be used to determine connectivity, each time a      packet is transmitted to an active next hop.  For example, absence      of a link layer ACK or failure to get a CTS after sending RTS,      even after the maximum number of retransmission attempts,      indicates loss of the link to this active next hop.

...

  If a link to the next hop cannot be detected by any of these methods,   the forwarding node SHOULD assume that the link is lost, and take   corrective action by following the methods specified in Section 6.11.

So you could implement an algorithm that counts the number of subsequent lost ACKs at the MAC layer and then marks the route as invalid if e.g. 3 or more ACKs in a row were dropped. My guess is that this will substantially lower the AODV overhead as less RREQs are needed. The difficulty is of course choosing the right number of lost ACKs before a route is considered invalid, I guess 3 would be fine.

Of course these are just my 2 eurocents, so feel free to react.

Regards, Bart