AODV Protocol

29/11/2021
─

Vishvesh Muthu
118CS0181
 1

Introduction
A wireless ad hoc network (WANET) or mobile ad hoc network (MANET) is a
decentralized type of wireless network. The network is ad hoc because it does not
rely on a pre-existing infrastructure, such as routers in wired networks or access
points in wireless networks. Instead, each node participates in routing by
forwarding data for other nodes, so the determination of which nodes forward data
is made dynamically on the basis of network connectivity and the routing algorithm
in use.
In the Windows operating system, ad hoc is a communication mode (setting)
that allows computers to directly communicate with each other without a router.
Wireless mobile ad hoc networks are self-configuring, dynamic networks in which
nodes are free to move.
Such wireless networks lack the complexities of infrastructure setup and
administration, enabling devices to create and join networks "on the fly".
Each device in a MANET is free to move independently in any direction, and
will therefore change its links to other devices frequently. Each must forward traffic
unrelated to its own use, and therefore be a router. The primary challenge in
building a MANET is equipping each device to continuously maintain the
information required to properly route traffic.This becomes harder as the scale of
the MANET increases due to
1) the desire to route packets to/through every other node,
2) the percentage of overhead traffic needed to maintain real-time routing status,
3) each node has its own goodput to route independent and unaware of others
needs, and
4) all must share limited communication bandwidth, such as a slice of radio
spectrum.
Such networks may operate by themselves or may be connected to the larger
Internet. They may contain one or multiple and different transceivers between
nodes. This results in a highly dynamic, autonomous topology. MANETs usually
have a routable networking environment on top of a link-layer ad hoc network.
 2

AODV Protocol
The AODV protocol builds routes between nodes only if they are
requested by source nodes. AODV is therefore considered an on-demand
algorithm and does not create any extra traffic for communication along links.
The routes are maintained as long as they are required by the sources. They also
form trees to connect multicast group members. AODV makes use of sequence
numbers to ensure route freshness. They are self-starting and loop-free besides
scaling to numerous mobile nodes.

In AODV, networks are silent until connections are established. Network

nodes that need connections broadcast a request for connection. The remaining
AODV nodes forward the message and record the node that requested a
connection. Thus, they create a series of temporary routes back to the
requesting node.

A node that receives such messages and holds a route to a desired node
sends a backward message through temporary routes to the requesting node.
The node that initiated the request uses the route containing the least number
of hops through other nodes. The entries that are not used in routing tables are
recycled after some time. If a link fails, the routing error is passed back to the
transmitting node and the process is repeated.

Routing tables
Each routing table entry contains the following information [2] as destination,
next hop, number of hops, destination sequence number, and active
neighbors for this route and expiration time for this route table entry.
Expiration time, also called lifetime, is reset each time the route has been
used. The new expiration time is the sum of the current time and a
parameter called active route timeout. This parameter, also called route
caching timeout, is the time after which the route is considered as invalid,
and so the nodes not lying on the route determined by RREPs delete their
 3

reverse entries. If active route timeout is big enough, route repairs will
maintain routes. RFC 3561 defines it to 3 seconds.

Control Messages
Routing Request: Control messages Routing request When a route is not
available for the destination, a route request packet (RREQ) is flooded
throughout the network.The request ID is incremented each time the source
node sends a new RREQ, so the pair (source address, request ID) identifies a
RREQ uniquely. On receiving a RREQ message each node checks the source
address and the request ID. If the node has already received a RREQ with the
same pair of parameters the new RREQ packet will be discarded. Otherwise
the RREQ will be either forwarded (broadcast) or replied (unicast) with a RREP
message: if the node has no route entry for the destination, or it has one but
this is no more an up-to-date route, the RREQ will be broadcasted with
incremented hop count and if the node has a route with a sequence number
greater than or equal to that of RREQ, a RREP message will be generated and
sent back to the source. The number of RREQ messages that a node can send
per second is limited.
Routing reply: If a node is the destination, or has a valid route to the
destination, it unicasts a route reply message (RREP) back to the source.The
reason one can unicast RREP back is that every node forwarding a RREQ
message caches a route back to the source node.
HELLO messages: Each node can get to know its neighbourhood by using
local broadcasts, so-called HELLO messages. Node neighbors are all the
nodes that it can directly communicate with. Although AODV is a reactive
protocol it uses these periodic HELLO messages to inform the neighbors that
the link is still alive. The HELLO messages will never be forwarded because
they are broadcasted with TTL = 1. When a node receives a HELLO message it
refreshes the corresponding lifetime of the neighbour information in the
routing table. This local connectivity management should be distinguished
from general topology management to optimize response time to local
changes in the network.
 4

Route error: All nodes monitor their own neighbourhood. When a node in
an active route gets lost, a route error message (RERR) is generated to notify
the other nodes on both sides of the link of the loss of this link.

Implementation of AODV
There are many AODV routing protocol implementations, including Mad-hoc,
AODVUCSB, AODV-UU, Kernel-AODV, and AODV-UIUC [11]. Each
implementation was developed and designed independently, but they all
perform the same operations. The first publicly available implementation of
AODV was Mad-hoc. The Mad-hoc implementation resides completely in
user-space and uses the snooping strategy to determine AODV events.
Unfortunately, it is known to have bugs that cause it to fail to perform
properly. Mad-hoc is no longer actively researched.

Code:
#include "ns3/command-line.h"

#include "ns3/config.h"

#include "ns3/uinteger.h"

#include "ns3/double.h"

#include "ns3/string.h"

#include "ns3/log.h"

#include "ns3/yans-wifi-helper.h"

#include "ns3/mobility-helper.h"

#include "ns3/ipv4-address-helper.h"

#include "ns3/yans-wifi-channel.h"

#include "ns3/mobility-model.h"

#include "ns3/aodv-module.h"

#include "ns3/ipv4-static-routing-helper.h"
 5

#include "ns3/ipv4-list-routing-helper.h"

#include "ns3/internet-stack-helper.h"

#include "ns3/core-module.h"

#include "ns3/applications-module.h"

#include "ns3/network-module.h"

#include "ns3/internet-module.h"

#include "ns3/point-to-point-module.h"

#include "ns3/ipv4-global-routing-helper.h"

#include "ns3/netanim-module.h"

using namespace ns3;

NS_LOG_COMPONENT_DEFINE ("WifiSimpleAdhocGrid");

void ReceivePacket (Ptr<Socket> socket){

while (socket->Recv ()){

NS_LOG_UNCOND ("Received one packet!");

static void GenerateTraffic (Ptr<Socket> socket, uint32_t pktSize,

uint32_t pktCount, Time pktInterval )

if (pktCount > 0){

socket->Send (Create<Packet> (pktSize));

Simulator::Schedule (pktInterval, &GenerateTraffic, socket,

pktSize,pktCount - 1, pktInterval);

}
 6

else {

socket->Close ();

int main (int argc, char *argv[]){

std::string phyMode ("DsssRate1Mbps");

double distance = 50; // m

uint32_t packetSize = 50; // bytes

uint32_t numPackets = 40;

uint32_t numNodes = 10; // by default, 5x5

uint32_t sinkNode = 0;

uint32_t sourceNode = 9;

double interval = 1.0; // seconds

bool verbose = false;

bool tracing = true;

CommandLine cmd;

cmd.AddValue ("phyMode", "Wifi Phy mode", phyMode);

cmd.AddValue ("distance", "distance (m)", distance);

cmd.AddValue ("packetSize", "size of application packet sent",

packetSize);

cmd.AddValue ("numPackets", "number of packets generated", numPackets);

cmd.AddValue ("interval", "interval (seconds) between packets",

interval);
 7

cmd.AddValue ("verbose", "turn on all WifiNetDevice log components",

verbose);

cmd.AddValue ("tracing", "turn on ascii and pcap tracing", tracing);

cmd.AddValue ("numNodes", "number of nodes", numNodes);

cmd.AddValue ("sinkNode", "Receiver node number", sinkNode);

cmd.AddValue ("sourceNode", "Sender node number", sourceNode);

cmd.Parse (argc, argv);

// Convert to time object

Time interPacketInterval = Seconds (interval);

// Fix non-unicast data rate to be the same as that of unicast

Config::SetDefault ("ns3::WifiRemoteStationManager::NonUnicastMode",
StringValue (phyMode));

NodeContainer c;

c.Create (numNodes);

// The below set of helpers will help us to put together the wifi NICs
we want

WifiHelper wifi;

if (verbose){

wifi.EnableLogComponents (); // Turn on all Wifi logging

YansWifiPhyHelper wifiPhy = YansWifiPhyHelper::Default ();

// set it to zero; otherwise, gain will be added

wifiPhy.Set ("RxGain", DoubleValue (-10) );

// ns-3 supports RadioTap and Prism tracing extensions for 802.11b

 8

wifiPhy.SetPcapDataLinkType (WifiPhyHelper::DLT_IEEE802_11_RADIO);

YansWifiChannelHelper wifiChannel;

wifiChannel.SetPropagationDelay
("ns3::ConstantSpeedPropagationDelayModel");

wifiChannel.AddPropagationLoss ("ns3::FriisPropagationLossModel");

wifiPhy.SetChannel (wifiChannel.Create ());

// Add an upper mac and disable rate control

WifiMacHelper wifiMac;

wifi.SetStandard (WIFI_PHY_STANDARD_80211b);

wifi.SetRemoteStationManager ("ns3::ConstantRateWifiManager",

"DataMode", StringValue (phyMode),

"ControlMode", StringValue (phyMode));

// Set it to adhoc mode

wifiMac.SetType ("ns3::AdhocWifiMac");

NetDeviceContainer devices = wifi.Install (wifiPhy, wifiMac, c);

MobilityHelper mobility;

mobility.SetPositionAllocator ( "ns3::GridPositionAllocator",

"MinX", DoubleValue (0.0),

"MinY", DoubleValue (0.0),

"DeltaX", DoubleValue (distance),

"DeltaY", DoubleValue (distance),

"GridWidth", UintegerValue (5),

"LayoutType", StringValue ("RowFirst"));

mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
 9

mobility.Install (c);

// Enable OLSR

AodvHelper aodv;

Ipv4StaticRoutingHelper staticRouting;

Ipv4ListRoutingHelper list;

list.Add (staticRouting, 0);

list.Add (aodv, 10);

InternetStackHelper internet;

internet.SetRoutingHelper (list); // has effect on the next Install ()

internet.Install (c);

Ipv4AddressHelper ipv4;

NS_LOG_INFO ("Assign IP Addresses.");

ipv4.SetBase ("10.1.1.0", "255.255.255.0");

Ipv4InterfaceContainer i = ipv4.Assign (devices);

TypeId tid = TypeId::LookupByName ("ns3::UdpSocketFactory");

Ptr<Socket> recvSink = Socket::CreateSocket (c.Get (sinkNode), tid);

InetSocketAddress local = InetSocketAddress (Ipv4Address::GetAny (),

80);

recvSink->Bind (local);

recvSink->SetRecvCallback (MakeCallback (&ReceivePacket));

Ptr<Socket> source = Socket::CreateSocket (c.Get (sourceNode), tid);

 10

InetSocketAddress remote = InetSocketAddress (i.GetAddress (sinkNode,

0), 80);

source->Connect (remote);

if (tracing == true)

AsciiTraceHelper ascii;

wifiPhy.EnableAsciiAll (ascii.CreateFileStream ("assgn5.tr"));

wifiPhy.EnablePcap ("assgn5", devices);

// Trace routing tables

Ptr<OutputStreamWrapper> routingStream = Create<OutputStreamWrapper>

("wifi-simple-adhoc-grid.routes", std::ios::out);

aodv.PrintRoutingTableAllEvery (Seconds (2), routingStream);

Ptr<OutputStreamWrapper> neighborStream =
Create<OutputStreamWrapper> ("wifi-simple-adhoc-grid.neighbors",
std::ios::out);

aodv.PrintNeighborCacheAllEvery (Seconds (2), neighborStream);

// To do-- enable an IP-level trace that shows forwarding events

only

AnimationInterface anim("assgn5_anim.xml");

Simulator::Schedule ( Seconds (1.0), &GenerateTraffic,

source, packetSize, numPackets,

interPacketInterval);

// Output what we are doing

 11

NS_LOG_UNCOND ("Testing from node " << sourceNode << " to " << sinkNode
<< " with grid distance " << distance);

Simulator::Stop (Seconds (100.0));

Simulator::Run ();

Simulator::Destroy ();

return 0;

Results:
 12

Discussion:
● Successfully implemented AODV routing protocol for nodes in a grid
topology, simulating for 100sec, with 10 nodes deployed at a distance
of 50meters.
● This program configures a grid (default 2x5) of nodes on an 802.11b
physical layer, with 802.11b NICs in adhoc mode, and by default, sends
one packet of 50
● The default layout is like this, on a 2-D grid.

n5 n6 n7 n8 n9
n0 n1 n2 n3 n4

● Successfully analyzed goodput and throughput using Tracemetrics and

the corresponding assgn5.tr file.
● Simulation of the network grid was successfully demonstrated on
NetAnim-3.108 using corresponding assgn5_anim.xml file.
● Packet capture and analysis was done using the .Pcap files from each
of the 10 nodes through packet tracing and analysis was done through
wireshark.