Routing/AODV

Papers referenced:
"Ad-hoc On-Demand Distance Vector Routing" by Perkins and Royer
"A Review of Current Routing Protocols for Ad-Hoc Mobile Wireless Networks" by Royer and Toh

Overview

Goal: identify routes from source to destination.

Challenges:

Mobility
Energy management

Recall, there are two flavors of Internet routing protocols: link state and distance vector. How might you develop an OSPF-style or RIP-style algorithm to address the challenges of sensor networks?

Routing in Wireless/Mobile Environments

There are two styles of routing protocols for wireless networks: table driven and on demand.

Table driven - Similar to Internet routing protocols, table-driven protocols are proactive and attempt to maintain a routing table and use it to calculate routes from source to destination.
On demand - On-demand protocols are reactive and identify routes when a message needs to be sent. They typically flood the network to explore and find destinations.

Flooding and gossiping are two very simple approaches to routing. Using flooding, messages are broadcast until the reach the destination. To avoid loops and ensure that messages do not live forever, typically nodes do not forward messages they have already forwarded and messages have a TTL that indicates the number of times the message should be forwarded.

Gossiping, also referred to as epidemic routing, is similar to flooding, though rather than broadcasting a message, a node will select a subset of one or more of its neighbors and forward messages to that set.

What are some of the advantages and disadvantages to flooding and/or gossiping?

AODV

The Ad-hoc On-Demand Distance Vector (AODV) routing protocol is a the default mobile ad-hoc network (MANET) routing protocol used by the Sun SPOTs. The protocol was designed for wireless environments, but not necessarily sensors. You could, for example, use this protocol over 802.11 for routing in an infrastructureless network of laptops.

Goals:

Minimize broadcasts
Minimize transmission latency when new routes are needed

Features:

Nodes that are not on active routes do not maintain routing table state
Nodes do not need to discover/maintain routes until they need to communicate
Local broadcasts (hello messages) are used to discover neighbors
Discovery packets are broadcast only when necessary

Path Discovery

Initiated when a source needs to communicate with another node not in its routing table
Nodes maintain 2 counters: node sequence number and broadcast id
Source sends route request (RREQ) packet to neighbors

<source_addr, source_seq_no, bcast_id, dest_addr, dest_seq_no, hop_cnt>
source_addr + bcast_id uniquely identifies a request
bcast_id is incremented for each RREQ

Neighbors reply with route reply (RREP) or rebroadcast RREQ

redundant RREQs are dropped

If a node cannot satisfy the request, it maintains the following info for reverse path setup

dest_addr, source_addr, bcast_id, expiration time, source_seq_no

Reverse Path Setup

source_seq_no maintains freshness about reverse route to source
dest_seq_no indicates how fresh a route to the dest must be before being accepted by the source

e.g., a node with path to dest with seq no 1 would not reply to request with dest seq no 2

Each node sets up a reverse path with the address of the neighbor from which it received the RREQ

Forward Path Setup

If the RREQ arrives at a node that has a route to the destination, the node checks the dest seq no to determine whether its route is fresh enough. If the RREQ dest seq no is greater than the dest seq no for the intermediate node, the intermediate node rebroadcasts the RREQ.
If the intermediate node's route has dest seq no less than or equal to that of the RREQ, it will unicast a RREP to the neighbor from which it received the request. The RREP contains the following information:

<source_addr, dest_addr, dest_seq_no, hop_cnt, lifetime>

Each node receiving the RREP sets up a forward pointer to the node from which the reply was sent and propagates the RREP toward the source.
A source can begin transmitting data as soon as it receives an RREP, but may later receive another RREP with a better route and begin using that route.

Route Table Management

Routing table entries contain the following:

Destination
Next Hop
Number of hops (metric)
Sequence number for destination
Active neighbors for the route
Expiration time for the entry

A neighbor is active if it has relayed a packet for the destination within the most recent active_timeout period.

Path Maintenance

If a source moves during a session it can reinitiate route discovery.
If the destination or intermediate node moves during a session, a special RREP can be sent.

The node upstream of the break sent an RREP with a fresh sequence number and hop count infinity.
A source receiving this RREP can reinitiate route discovery.

Periodic hello messages are used to maintain a list of neighbors.

Sami Rollins

Date: 2008-01-15