Lecture 13:

Mobile Ad Hoc Networks

Contents

Introduction
Ad-Hoc typical applications
Characteristics and requirements
Routing Protocols
Ad-Hoc performance
Conclusion

2
Introduction

Two types of wireless networks:

Infrastructured network:
base stations are the bridges
a mobile host will communicate with
the nearest base station
handoff is taken when a host roams
from one base to another

3
 Ad hoc network:
infrastructureless: no fixed base stations
without the assistance of base stations for
communication
Due to transmission range constraint,
two MHs need multi-hop routing for
communication
quickly and unpredictably changing
topology

4
 Infrastructured network

5
 MANET = Mobile Ad Hoc Networks
a set of mobile hosts, each with a transceiver
no base stations; no fixed network infrastructure
multi-hop communication
needs a routing protocol which can handle changing
topology

6
 Single-Hop Ad Hoc

7
 Multi-hop Ad Hoc

8
 Single-hop Vs. Multi-hop systems

9
Ad-Hoc typical applications
Personal area networking
cell phone, laptop, ear phone, wrist watch
Military environments
soldiers, tanks, planes
Civilian environments
car network
meeting rooms
sports stadiums
boats, small aircraft
Emergency operations
search-and-rescue
policing and fire fighting

10
Peer-to-Peer

11
Multi-hop Peer-to-Peer

12
Multi-hopping via Wireless Router

13
Hopping on the Network

14
Supports Mobility

15
Supports Non Line-of-Sight

16
 Military applications
Situational Awareness (SA) and Command and
Control (C2) for military.

17
 Nokia RoofTop Wireless Routing
A wireless broadband solution for residential
markets, based on a multihop Ad-Hoc (mesh)
networking.

18
 Related Research
IEEE 802.11 for Wireless LANs
MAC
PHY

IETF manet group

to stimulate research and discuss possible standards in
this area

Routing Protocols:
unicast AODV, DSR, ZRP, TORA, CBRP, CEDAR
multicast AMRoute, ODMRP, AMRIS
19
Characteristics and requirements

Distributed operation
Dynamic network topology
Fluctuating link capacity
Low-power devices

20
 Challenges
Broadcast nature of the wireless medium
Hidden terminal problem
Packet losses due to transmission errors
Mobility-induced route changes
Mobility-induced packet losses
Battery constraints
Potentially frequent network partitions
Ease of snooping on wireless transmissions
(security hazard)
Quality of Service
21
Routing Protocols
We need a new routing and multicasts protocols
that perform the following functions :
Ensure routing in a dynamic, Ad-Hoc network
through automatic detection of new or missing links.
Automatically select the highest quality, least
congested paths.
Provide an efficient multicast mechanism across the
wireless broadcast channel.

22
Overview of Current Routing Protocols

23
On-demand vs. Table-driven
Table-Driven Routing Protocol:
proactive!!
continuously evaluate the routes
attempt to maintain consistent, up-to-date routing
information
when a route is needed, one may be ready
immediately
when the network topology changes
the protocol responds by propagating updates
throughout the network to maintain a consistent view
Example DSDV

24
 On-Demand Routing Protocol:
reactive!!
on-demand style: create routes only when it is desired
by the source node
route discovery: invoke a route-determination
procedure
the procedure is terminated when
a route has been found
no route is found after all route permutations are
examined
longer delay: sometimes a route may not be ready for
use immediately when data packets come
Example AODV
25
Table-Driven Routing Protocols
DSDV (Destination Sequence Distance Vector)

Highly Dynamic Destination-Sequence Distance-

Vector Routing (DSDV) for Mobile Computers
Charles E. Perkins & Pravin Bhagwat
Dated: 1994
Computer Communications Review, 94
pp. 234-244

26
DSDV

Based on the Bellman-Ford algorithm

Each node keeps a routing table to all other
nodes.
based on next-hop routing
Path discovery through packet caching and
header examination.
Entries have a sequence number.
Incremental updates possible.

27
A 3 >C A 3 >C Routing Table broadcast
B 2 >C B 2 >C
C 1 >C C 1 >C Node
E 2 >C D E D 2 >C

C A 2 >B
A 1 >A
B 1 >B
C 1 >C B
D 1 >D
D 2 >C
E 1 >D
E 2 >C B 1 >B
A C 2 >B
D 3 >B
E 3 >B

28
 Once its routing table changes, a node
broadcasts its table to other nodes.

29
30
31
On-Demand Routing Protocol

Ad-Hoc On-Demand Distance Vector

(AODV) Routing
Protocol overview and objectives
Path Discovery
Reverse Path Setup
Forward Path Setup
Route Table Management
Path Maintenance
Local Connectivity Management

32
 Outline of Basic Functions of a Node

AODV Nodes
Status

Intermediate Node Source Node Destination Node

33
 AODV UNICSAT ROUTE ROUTE
ESTABLISHMENT

Source Node
Initiate a path discovery process by broadcasting a
RREQ packet to its neighbors.
Reinitiate the path discovery process when it moves.
Reinitiate the path discovery process when it receives
a failure notification message from nodes along the
path to the destination.

34
Intermediate Nodes
Reply to the RREQ packet by unicasting a RREP packet back to
the source, only when they have a route to the destination
whose seq. # is greater or equal to the seq. # contained in the
RREQ packet.
Store in their routing tables the address of the neighbor from
which the RREQ is received, thereby establishing a reverse
path back to the source.
Discard additional copies of the same RREQ latter received (
Broadcast ID and source IP address uniquely specify the RREQ
packet).
Send failure notification messages to the source (route erase )
when moving away.
35
Destination Node

Respond to the RREQ packet by unicasting a route reply

(RREP) packet back to the neighbor it has first received a
RREQ packet. This packet is routed along the already
established reverse path.
Reinitiate the path discovery process when it moves.
Reinitiate the path discovery process when it receives a failure
notification message from nodes along the path to the destination.

36
Basic Functions of a Node

Maintain route information in its route table.

Information obtained through RREQ & RREP
messages is kept with other routing information in
the route table.
Update the Seq. # to eliminate unused routes
Manage aging process of routes with old seq. #

37
 AODV Route Discovery
Initiated by a node wishing to communicate.
Reinitiate the RREQ for rreq_retries incase of a
lost RREQ
Route Request packets are broadcast
RREQ format
< source_addr, current source_sequence-# ,
broadcast_id, dest_addr, dest_sequence_#,
hop_cnt >
RREQ uniquely identified by <source_addr ,
broadcast_id>
38
 Broadcast ID is incremented with every RREQ

Set a timer to wait for a reply.

Neighboring nodes maintain a record of every

RREQ for a specified period of time.

Setup a reverse path entry for the source node.

This entry contains the source IP, Source_Seq.#,
#hops to the source and IPs addresses of neighbor
from which it received the RREQ.
39
 Set a lifetime for the reverse path.
Neighboring nodes satisfy RREQ by sending
RREP or broadcast RREQ after incrementing
hop_cnt
In summary, each intermediate node keeps the
following information for a particular RREQ
Destination Address and Seq.#
Source nodes sequence number and IP address
# hops to the source and the IPs of neighboring
nodes
Broadcast_ID
Expiration time for reverse path entry
40
 Route Discovery Flow Chart (1)

A source wishing to transmit

Check the route table

Forward packet Yes Existence of

No Initiate a Route
active route
to next hop Discovery Process

Create RREQ
packet

Broadcast RREQ &

Set the timer for a reply
41
 (2)
Intermediate node receiving
the RREQ

Check its record to see if

It had seen it.

Yes Did it see the

No
Discard the packet RREQ before? Record the RREQ
Information & broadcast

No
Unicast a REPP Reverse path expired Setup reverse route entry

Yes

Increment hop count

and broadcast

42
UNICAST AODV

X X
X
S

43
 Optimization: Expanding Ring Search
Route Requests are initially sent with small Time-to-Live
(TTL) field, to limit their propagation.

If no Route Reply is received within the ttl_start value,

then larger TTL is tried unlit the threshold value is
reached, beyond which the RREQ is broadcast through
the entire network to rreq_retries.

After the route is established, distance to the destination is

used to reinitiate TTL to this value.

44
 AODV Forward Path Setup
RREQ arrives at a node that has current route to the
destination ( larger/same sequence number).
Unicast request reply (RREP)<source_addr, dest_addr,
dest_sequence_#, hop_cnt,lifetime> to neighbor from
which it has received the RREQ.
Intermediate node respond the same but with hop_cnt
set to its distance from the destination.
RREP travels back to the source along the reverse
path
Each upstream node updates dest_sequence_#, sets up
a forward pointer to the neighbor who transmit the
RREP
45
 Updates information in the forward path entry of
subsequent on reception RREPs.

Multiple arrivals of RREPs at a node will be discarded

provided that their sequence # are less than the
destination seq. of the first RREP or have higher hops
count.

Source can begin transmission as soon as it receives

the first RREP.

46
 Forward Path Setup in AODV

S N7
N2 N8
N4
N10
N1 N6
N3 D
N9
N5
N11

Forward links are setup when RREP travels along

the reverse path

Represents links on Reverse Path

Represents a link on the forward path

47
 AODV Reverse Path Setup
Source sequence number
is used to maintain
freshness about reverse
route to the source

Destination sequence
number specified for
freshness of route before
accepted by source

Reverse path setup by

having link to neighbor
from which it received
RREQ

48
 AODV Route Table Management

Route Request Expiration Timer for purging

reverse paths which do not lie on source-
destination route
Route Caching Timeout for time after which the
route is considered invalid
Active_timeout Period used to determine if
neighboring node is active

49
 AODV Route Table Management Cont.

Route Table entry

Destination
Next Hop
Number of hops (metric)
Sequence numbers of Destination
Active Neighbors for this route
Expiration time for the route table entry

50
 AODV Route Maintenance
Node movement affect only the routes containing
these nodes.
Source movement reinitiates the path discovery process
When destination node or intermediate node
moves a Route Error (RERR) message, initiated
from upstream nodes of the source node , is sent to
the affected source nodes.
When next hop become unreachable the upstream
node propagates RERR to neighbor with fresh
sequence number and hop cnt
restart route discovery process from source on
receipt of RERR
51
 Summary of Route Error
When a node is unable to forward packet (from
node S to node D) on link (L), it generates a
RERR message

The node increments the destination sequence

number for D cached at its route information

The incremented sequence number N is included

in the RERR

52
 When node S receives the RERR, it initiates a
new route discovery for D using destination
sequence number at least as large as N

When node D receives the route request with

destination sequence number N, node D will set
its sequence number to N, unless it is already
larger than N

53
 AODV Route Maintenance

N3

RERR N3
RERR N1
N2
D
S

N5 N4

S- Source Node

D- Destination Node
54
 AODV Route Maintenance Cont.

S- Source Node
N3
D- Destination Node
X
N3
N1 X
N2
D
S

N5 N4

New Route Found through Node 4

55
 AODV Local Connectivity Management
Node learn of their neighbors in following way
on receipt of broadcast message, the node
updates the lifetime associated with that
neighbor.
on receipt of hello message
Hello messages are only local (TTL=1) and it contains
<IP_Address, Noed_Sequence_#>
Failure to receive Hello message during (hello_interval)
indicate that the route information of the neighbor need to be
updated.
Hello messages are sent from neighbor during an active path
56
 Local Link Failure Detection

Hello messages: Neighboring nodes periodically

exchange hello message

Absence of
((1+allowed_hello_loss)*hello_lifetime) of hello
message is used as an indication of link failure

57
 AODV Rebooting
To prevent routing loops during node rebooting,
the node will wait for delete_period, during
which it does not respond to any routing
packet.

Update its Seq.# whenever it receives a RREQ

from its neighbor

58
 Link Failure Reporting

A neighbor of node N is considered active for a

routing table entry if the neighbor sent a packet
within active_route_timeout interval

When the next hop link in a routing table entry

breaks, all active neighbors are informed

Link failures are propagated by means of Route

Error messages, which also update destination
sequence numbers

59
 Ad-Hoc performance

Simulation Environment
Simulation tools used: GloMoSim
Size of Network: 50,100,250,500
Fixed area L*L:1*1km:1.5*1.5km: 2.4*2.4:3.45:3.45km
Range: 250 meters
Data rate: 2Mbps
Packet size: 64bytes
Node Speed: 0~10 m/s

60
 Rest period at the random spot: 60~300 second
Carrier sensing is performed by each node prior
to transmission
Simulation time: 300 second

61
 Simulation Results

Fig.1 Neighbors vs. Speed

62
Fig.2 Packets Delivered vs. Speed

63
Fig.2 Packets Delivered vs. Speed

64
Fig.4 Route Acquisition vs. Speed

65
 Comparison Of Table Driven Routing Protocols

Parameters DSDV CGSR WRP

Time Complexity O(d) O(d) O(h)
Route Complexity O(x = N) O(x = N) O(x = N)
Route Philosophy Flat Hierarchical Flat
Loop Free Yes Yes Yes, but
instantenous
Multicast Capability No No No
Required Tables 2 2 4
Freq Of Updated Transmission Periodically and Periodically Periodically and
as needed as needed
Updates Transmitted to Neighbors Neighbors and Neighbors
cluster heads
Utilize Seq. No / Hello Packets Yes/No Yes/No Yes/Yes
Critical Nodes No Yes(cluster head) No

Routing Metric Shortest path Shortest path Shortest path

66
 Comparison Of On Demand Protocols

Performance Parameters AODV DSR TORA ABR

Time Complexity (start) O(2d) O(2d) O(2d) O(d+x)
Time Complexity (after fail) O(2d) O(2d) or O(2d) O(l+x)
0(cache hit)
Communication Complexity O(2N) O(2N) O(2N) O(N+y)
Communication Complexity O(2N) O(2N) O(2x) O(x+y)
Routing / Loop Free Flat / Yes Flat / Yes Flat / Yes Flat / Yes
Multicast Capability Yes No No No
Beaconing Requirements No No No Yes
Multiple Route Possibilities No Yes Yes No
Route Reconfiguration Erase Route, Erase Route, Link reversal, Localized
Notify Source Notify Source route repair broadcast query

Route Maintained in Route table Route cache Route table Route table
Routing Metric Fresh and Shortest Shortest Associativity
shortest and shortest
path

67
 Comparison of On-Demand v/s Table Driven Routing
Parameters On Demand Table Driven

Availability of Routing Available when needed Always available

Information regardless of need
Routing Philosophy Flat Mostly Flat except for
CGSR
Periodic route updates Not Required Yes

Coping with Mobility Using Localized route Inform other nodes to

discovery in ABR achieve consistent routing
tables
Signaling Traffic Grows with increasing Greater than that of On
Generated mobility of active nodes Demand Routing
as in ABR
QoS Support Few Can Support QoS Mainly Shortest Path as
QoS Metric
68