NetSim Support Portal

AODV routing in MANET

Consider the simple MANET network where Node 1 has to communicate with Node 5 using AODV protocol as shown below (associated experiment configuration is attached herewith):

Figure:1

The AODV route table entries discussed in the following explanation were obtained from  AODV route table log files which can be generated by modifying the source codes as explained in the article: 

https://support.tetcos.com/en/support/solutions/articles/14000112927-how-to-obtain-a-log-for-aodv-route-table-updates-in-netsim-

The Route Table is created or updated only when RREQ, RREP, or RRER messages are received by the corresponding nodes.

1.Node 1 wants to communicate with the destination Node 5. Since Node 1 does not have a route entry for Node 5 in its route cache, it sends a Route Request broadcast message RREQ as shown in Figure with its own sequence number to the neighboring nodes, here Node 2.

Before broadcasting the RREQ, the originating node buffers the RREQ ID and the Originator IP address (its own address) of the RREQ for PATH_DISCOVERY_TIME.  In this way, when the node receives the packet again from its neighbors, it will not reprocess and re-forward the packet

Figure: 2

2. The Node 2 receives the RREQ message from the Node 1.Since Node 2 is not the destination Node, it makes note of the reverse route to reach Node 1 in its Route table as shown in TABLE and it changes the Hop Count value to 1 in RREQ and broadcasts the message to its neighbor nodes Node 1 and Node 3 as shown in Figure below.

Wireless_Node_2:

Figure:3

Table:1

3. Node 1 receiving the RREQ from Node 2 identifies that it is the same RREQ sent by its own Node hence it does not broadcast it to other Nodes. Similarly, Node 3 creates its Route Table as shown in TABLE noting the reverse route to reach the source Node and changes the Hop count in the RREQ message and broadcasts it to its neighboring Nodes, Node 4 and Node.

Wireless_Node_3:

Figure:4

Table:2

4. Node 2 receiving the RREQ from Node 3 identifies that it is the same RREQ sent by its own Node hence it does not broadcast it to other Nodes. Similarly, Node 4 receives and creates its Route Table as shown in TABLE noting the reverse route to reach the source Node and changes the Hop count in the RREQ message and broadcasts it to its neighboring Nodes, Node 5 as shown in Figure below.

Wireless_Node_4:

Figure:5

Table:3

5. Node 5 receives RREQ from Node 4. Node 5 identifies that its IP Address is the same as the Destination IP Address field in RREQ. The Destination Node when generating an RREP message copies the Destination IP Address and the Originator Sequence Number from the RREQ message into the corresponding fields in the RREP message. Hence Node 5 sends its RREP to Next Hop Node 4 as shown in Figure and creates its Route Table as shown in Table.

Wireless_Node_5:

Figure:6

Table:4

6. When a node receives an RREP message, it searches for a route to the previous hop. If needed, a route is created for the previous hop. The Node 4 receives RREP and updates its Route Table with the reverse route to reach Node 5 notes the Destination Seq No and forwards the RREP to Next Hop Node 3

Wireless_Node_4:

Figure:7

Table:5

7. Node 3 receives the RREP and updates its Route Table with the reverse route to reach Node 5, notes the Destination Seq No and forwards the RREP to the Next Hop Node 2

Wireless_Node_3:

Figure:8

Table:6

8. Node 2 receives the RREP and updates its Route Table with the reverse route to reach Node 5, notes the Destination Seq No and forwards the RREP to the Next Hop Node 1

Wireless_Node_2:

Figure:9

Table:7

9. Originator Node 1 receives the RREP from the Next Hop Node 2 and creates the entries in the Route Table and starts the data transmission through the Route thus established

Wireless_Node_1:

Table:8

10. The data transmissions can be seen in Figure 10-Figure 13

Figure:10

Figure:11

Figure:12

Figure:13