Learning Center
Plans & pricing Sign in
Sign Out




  Top-Level Description of AODV Functionalities in
              the New rt2570 Driver
I. Introduction
This document provides a top level description of AODV protocol functionalities that
should be implemented and integrated into the current rt2570 driver [5]. We will call the
new driver rt2570.AODV.

The functionalities of the AODV protocol [1] will be implemented and integrated into the
current driver [5]. However, an improved version of AODV -- the so-called Radio Metric
AODV protocol as described in [2], a proposal for 802.11s draft -- will be used. The
reason is that the radio metric AODV improves the original AODV protocol by taking a
radio metric cost of the links into account.
We also note that the original AODV protocol cannot be used without modification for
our purposes; an obvious modification is that IP addresses (contained in routing table or
in protocol messages) should be replaced by MAC addresses,…

The number of nodes is limited to 32 nodes.

Standards Compliance
Because the AODV protocol is implemented in the driver, i.e. routing is done in layer 2
of the OSI reference model, nodes running the new driver may not interoperate with
nodes that run AODV in layer 3 (network layer), e.g. AODV-UU.
In implementing AODV protocol in the driver, we will closely follow:
    - Appendix A of [2]
    - Clause of [2]. In case of inconsistencies, we will choose the most
        appropriate specification.

II. Driver Interface
The wireless driver creates a virtual network interface (usually wlan0) that is used for ad
hoc network traffic. It is also used for some driver control operations.
Userspace Controls
There are several system calls available to examine and modify the behavior of the
rt2570.AODV driver. These calls are implemented as ioctl’s, and can be invoked via
"iwconfig" or "iwpriv" commands.
New commands via ioctl’s may be implemented. For example, a useful command might
be an iwpriv fwt_* family of commands. With these commands one might examine and
modify the routing table of the new driver.
Another useful feature for debugging and testing that might be implemented in the new
driver is the blinding table. Incoming traffic from any address that exists in the blinding
table will be silently discarded. This might be useful to test specific ad hoc network
topologies that would otherwise be hard to setup. The blinding table might be accessed

       iwpriv bt_[add, del, reset, list].

There might be additional ioctl calls that will change values of configuration parameters
of AODV protocol (such as NODE_TRAVERSAL_TIME, NET_DIAMETER,… [1]) to
support testing or to tune performance of the ad hoc network.
Finally, there are ad hoc network specific statistics available through ethtool -S. The
following counters might be implemented:
        (only as suggestions)


III. A Scenario
In the following we describe a simple scenario to see how the ad hoc network should
behave in a simple situation (This description is based on [4]). We will need 3 laptops (or
PC’s), a, b and c, with IP addresses IPa and IPc (Does b need an IP for this scenario? To
be clarified). After setup of individual machines,

1. Bring all three laptops together:

a b c ------------------------------------------------
2. At the terminal of laptop c type

ping IPa

3. Move c away from a and b, until pings start failing. Mark that location (L1): that will
indicate the so-called direct range limit.

a b --------------------------------- c ----------------

4. Move c closer to a and b. As soon as pings become successful, mark that location (L2).

                          L2          L1
a b --------------------- c ----------------------

5. Pick up b and move it to L2.

                          L2          L1
a --------------------- b c -----------------------

6. Move c to L1, you should now be able go substantially beyond L1 and successfully
ping a.

                          L2          L1
a --------------------- b ---------------------- c

7. Move b back to a, you should find that c will no longer be able to ping a.

                          L2          L1
a b -------------------------------------------- c

[1] RFC 3561 -- Ad hoc On-Demand Distance Vector (AODV) Routing
[2] Joint SEE-Mesh/Wi-Mesh Proposal to 802.11 TGs
[3] ANSI/IEEE Std 802.11, 1999
[4] OLPCWiki
[5] rt2570-1.1.0-b2.tar.gz

To top