Issues: Routing in Ad-hoc
Networks
 Mobility
 Bandwidth constraint
 Error-prone and shared channel
 Location-dependent contention
 Other resource constraints
TDDD36: Routing
Issues: Multicas routing ...
 Robustness
 Efficiency
 Control overhead
 Quality of service
 Efficient group management
 Scalability
 Security
TDDD36: Routing
Unicast Routing Protocols
 Many protocols have been proposed
 Some have been invented specifically for
MANET
 Others are adapted from previously
proposed protocols for wired networks
 No single protocol works well in all
environments

some attempts to develop adaptive protocols
TDDD36: Routing
The ideal protocol (p303)
 Distributed
 Localized (and scalable)
 Adaptive
 Minimal maintenance and overhead
 Loop free (and free from stale routes)
 Balance scares resources usage against
performance (and/or QoS)
TDDD36: Routing
Routing protocol classification
 Route information mechanism
Proactive (table-driven)
 Reactive (demand-driven)
 Hybrid
 Temporal information
 Past vs. Future information
 Routing toplogy
 Flat vs. hierarchical
 Specific reources
 Geography or Power

TDDD36: Routing
Route update mechanism
 Proactive (or table-drive) protocols:
 Determine routes independent of traffic pattern
 Traditional link-state and distance-vector routing protocols
• Destination Sequenced Distance Vector (DSDV)
• Optimized Link State Routing (OLSR)
 Reactive (or demand-drive) protocols
 Route is only determined when actually needed
 Protocol operates on demand
• Dynamic Source Routing (DSR)
• Ad hoc On-demand Distance Vector (AODV)
• Temporally Ordered Routing Algorithm (TORA)
 Hybrid Protocols:
 Combine these behaviors (e.g., table in limited zone, and demand
drive otherwise)
• Zone Routing Protocol (ZRP)
• Greedy Perimeter Stateless Routing (GPSR)
TDDD36: Routing
Routing protocols for wireless ad
hoc networks
Sensor networks
Mobile ad hoc networks
Response time,
bandwidth
Proactive
protocols
Optimized LinkDestination-Sequenced
State Routing
Distance-Vector (DSDV)
(OLSR)
Energy
Reactive
protocols
Dynamic
Ad Hoc On-Demand
Source
Distance-Vector
Routing
(AODV)
(DSR)
Geography- Cluster-based
based routing (or hierarchical)
routing
GPSR
TDDD36: Routing
Some general trade-offs
 Latency of route discovery
 Proactive protocols may have lower latency
• Routes are maintained at all times

Reactive protocols may have higher latency
• Route from X to Y will be found only when X attempts to send to Y
 Overhead of route discovery/maintenance
 Proactive protocols can (but not necessarily) result in
higher overhead due to continuous route updating
 Reactive protocols may have lower overhead
• Routes are determined only if needed
 Which approach achieves a better trade-off
depends on the traffic and mobility patterns
TDDD36: Routing
Ad hoc networks: terminology
 Broadcast: message sent to all neighbors
within range
 Flooding: message sent to all nodes in the
network by neighbors forwarding message
to their neighbors etc.
 Different from wired network!
TDDD36: Routing
Dynamic Source Routing (DSR)
[Johnson96]
 When node S wants to send a packet to
node D, but does not know a route to D,
node S initiates a route discovery
 Source node S floods Route Request
(RREQ)
 Each node appends own identifier when
forwarding RREQ
TDDD36: Routing
Reactive protocols – DSR
 In a reactive protocol, how to forward a packet to
destination?



Initially, no information about next hop is available at all
One (only?) possible recourse: Send packet to all
neighbors – flood the network
Hope: At some point, packet will reach destination and an
answer is sent pack – use this answer for backward
learning the route from destination to source
 Practically: Dynamic Source Routing (DSR)
 Use separate route request/route reply packets to
discover route
• Data packets only sent once route has been
established
• Discovery packets smaller than data packets
 Store routing information in the discovery packets
TDDD36: Routing
Dynamic source routing (DSR)
 Reactive routing protocol
 2 phases, operating both on demand:
 Route discovery
• Used only when source S attempts to to send a packet
to destination D
• Based on flooding of Route Requests (RREQ)

Route maintenance
• Makes S able to detect, while using a source route to
D, if it can no longer use its route (because a link
along that route no longer works)
TDDD36: Routing
DSR: Route discovery (1)
Q
F
A
E
S
B
G
R
C
K
H
D
J
P
M
I
L
N
TDDD36: Routing
DSR: Route discovery (2)
Q
F
A
S
(S)
E
B
G
R
C
K
H
D
J
P
M
I
L
N
TDDD36: Routing
DSR: Route discovery (3)
(S,A)
Q
A
E
S
B
F
(S,E)
G
R
C
K
H
D
J
P
M
I
L
N
TDDD36: Routing
DSR: Route discovery (4)
Q
F
A
E
S
B
K
H
G
R
(S,E,G)
D
J
P
M
I
L
C
(S,B,C)
N
TDDD36: Routing
DSR: Route discovery (5)
Q
F
A
H
E
S
B
G
R
C
(S,A,F,H)
J
K
(S,E,G,J)
D
P
M
I
L
N
TDDD36: Routing
DSR: Route discovery (6)
Q
F
A
E
S
B
G
R
C
K
H
(S,A,F,H,K)
D
J
P
M
I
L
N
TDDD36: Routing
DSR: Route discovery (7)
Q
F
A
E
S
B
G
R
C
K
H
D
J
P
(S,A,F,H,K,P)
M
I
L
N
TDDD36: Routing
DSR: Route discovery (8)
Q
F
A
E
S
B
G
R
C
K
H
P
D
RREP(S,E,G,J,D)
J
M
I
L
N
TDDD36: Routing
DSR: Route Discovery (9)
 Route reply by reversing the route (as
illustrated) works only if all the links along
the route are bidirectional
 If unidirectional links are allowed, then
RREP may need a reverse route discovery
from D to S
 Note: IEEE 802.11 assumes that links are
bidirectional
TDDD36: Routing
DSR: Data delivery
Q
F
A
DATA(S,E,G,J,D)
E
S
B
G
R
C
K
H
D
J
P
M
I
L
N
TDDD36: Routing
DSR: Route maintenance (1)
Q
F
A
DATA(S,E,G,J,D)
E
S
B
G
R
C
K
H
X
D
J
P
M
I
L
N
TDDD36: Routing
DSR: Route maintenance (2)
Q
F
A
E
S
B
RERR(G-J)
G
R
C
K
H
X
D
J
P
M
I
L
N When receiving the Route Error message (RERR),
S removes the broken link from its cache.
It then tries another route stored in its cache;
if none, it initializes a new
route Routing
discovery
TDDD36:
Route Discovery in DSR
 Destination D on receiving the first RREQ,
sends a Route Reply (RREP)
 RREP is sent on a route obtained by
reversing the route appended to received
RREQ
 RREP includes the route from S to D on
which RREQ was received by node D
TDDD36: Routing
Route Reply in DSR
Y
Z
S
E
RREP [S,E,F,J,D]
F
B
C
M
J
A
L
G
H
K
I
D
N
Represents RREP control message
TDDD36: Routing
Route Reply in DSR
 Route Reply can be sent by reversing the route in
Route Request (RREQ) only if links are guaranteed
to be bi-directional

To ensure this, RREQ should be forwarded only if it
received on a link that is known to be bi-directional
 If unidirectional (asymmetric) links are allowed,
then RREP may need a route discovery for S from
node D


Unless node D already knows a route to node S
If a route discovery is initiated by D for a route to S,
then the Route Reply is piggybacked on the Route
Request from D.
 If IEEE 802.11 MAC is used to send data, then
links have to be bi-directional (since Ack is used)
TDDD36: Routing
Dynamic Source Routing (DSR)
 Node S on receiving RREP, caches the
route included in the RREP
 When node S sends a data packet to D, the
entire route is included in the packet
header

hence the name source routing
 Intermediate nodes use the source route
included in a packet to determine to whom
a packet should be forwarded
TDDD36: Routing
Data Delivery in DSR
Y
DATA [S,E,F,J,D]
S
Z
E
F
B
C
M
J
A
L
G
H
K
I
D
N
Packet header size grows with route length
TDDD36: Routing
When to Perform a Route
Discovery
 When node S wants to send data to node D,
but does not know a valid route node D
TDDD36: Routing
DSR modifications, extensions
 Intermediate nodes may send route replies in case
they already know a route

Problem: stale route caches
 Promiscuous operation of radio devices – nodes can
learn about topology by listening to control messages
 Random delays for generating route replies


Many nodes might know an answer – reply storms
NOT necessary for medium access – MAC should take care
of it
 Salvaging/local repair
 When an error is detected, usually sender times out and
constructs entire route anew
 Instead: try to locally change the source-designated route
 Cache management mechanisms
 To remove stale cache entries quickly
 Fixed or adaptive lifetime, cache removal messages, …
TDDD36: Routing
DSR: Optimization of route
discovery: route caching
 Principle: each node caches a new route it learns
by any means
 Examples
 When node S finds route (S, E, G, J, D) to D, it
also learns route (S, E, G) to node G
 In the same way, node E learns the route to D
 Same phenomenon when transmitting route
replies
 Moreover, routes can be overheard by nodes in the
neighbourhood
 However, route caching has its downside: stale
caches can severely hamper the performance of
the network
TDDD36: Routing
DSR Optimization:
Route Caching
 Each node caches a new route it learns by
any means
 When node S finds route [S,E,F,J,D] to node D, node S




also learns route [S,E,F] to node F
When node K receives Route Request [S,C,G] destined
for node, node K learns route [K,G,C,S] to node S
When node F forwards Route Reply RREP [S,E,F,J,D],
node F learns route [F,J,D] to node D
When node E forwards Data [S,E,F,J,D] it learns route
[E,F,J,D] to node D
A node may also learn a route when it overhears Data
packets
TDDD36: Routing
Use of Route Caching
 When node S learns that a route to node D
is broken, it uses another route from its
local cache, if such a route to D exists in
its cache. Otherwise, node S initiates
route discovery by sending a route request
 Node X on receiving a Route Request for
some node D can send a Route Reply if node
X knows a route to node D
 Use of route cache
can speed up route discovery
 can reduce propagation of route requests

TDDD36: Routing
Use of Route Caching
[S,E,F,J,D]
[E,F,J,D]
S
[F,J,D],[F,E,S]
E
F
B
[J,F,E,S]
C
J
[C,S]
A
M
L
G
H
[G,C,S]
D
K
I
N
Z
[P,Q,R] Represents cached route at a node
(DSR maintains the cached routes in a tree format)
TDDD36: Routing
Use of Route Caching:
Can Speed up Route Discovery
[S,E,F,J,D]
[E,F,J,D]
S
[F,J,D],[F,E,S]
E
F
B
C
[G,C,S]
[C,S]
A
[J,F,E,S]
M
J
L
G
H
I
[K,G,C,S] K
When node Z sends a route request
for node C, node K sends back a route
reply [Z,K,G,C] to node Z using a locally
cached route
D
RREP
N
RREQ
Z
TDDD36: Routing
Use of Route Caching:
Can Reduce Propagation of Route Requests
[S,E,F,J,D]
Y
[E,F,J,D]
S
[F,J,D],[F,E,S]
E
F
B
C
[G,C,S]
[C,S]
A
[J,F,E,S]
M
J
L
G
H
I
[K,G,C,S] K
D
RREP
N
RREQ
Z
Assume that there is no link between D and Z.
Route Reply (RREP) from node K limits flooding of RREQ.
In general, the reduction may be less dramatic.
TDDD36: Routing
Route Error (RERR)
Y
RERR [J-D]
S
Z
E
F
B
C
M
J
A
L
G
H
K
I
D
N
J sends a route error to S along route J-F-E-S when its attempt to
forward the data packet S (with route SEFJD) on J-D fails
Nodes hearing RERR update their route cache to remove link J-D
TDDD36: Routing
DSR: Strengths
 Routes are set up and maintained only
between nodes who need to communicate
 Route caching can further reduce the
effort of route discovery
 A single route discovery may provide
several routes to the destination
TDDD36: Routing
DSR: Weaknesses
 Route requests tend to flood the network and
generally reach all the nodes of the network
 Because of source routing, the packet header size
grows with the route lengh
 Risk of many collisions between route requests by
neighboring nodes  need for random delays
before forwarding RREQ
 Similar problem for the RREP (Route Reply storm
problem), in case links are not bidirectional
Note: Location-aided routing may help reducing the
number of useless control messages
TDDD36: Routing
Destination Sequenced Distance
Vector Algorithm (DSDV)
DSDV is based on idea of classical BellmanFord Routing Algorithm
Each node maintains a routing table listing all available
destinations. The attributes of each destination are the
next hop, the number of hops to reach to the destination,
and a sequence number, which is originated by the
destination node.
Both periodic and triggered routing updates to
maintain table
Destination Sequenced
Distance Vector Algorithm
(DSDV)
1.
2.
Based on Bellman-Ford Next Hop Routing.
Each Node Maintains Tables for :
A. Next Hop on Path
B. Distance (in hops) to destination.
C. Sequence Number ( keep current route)
3. Nodes Exchange Updates With Neighbours
•

Full Routing Updates
Incremental Updates
Problems of Distance Vector
Pro-active routing based on Distance Vector
 Topology changes are slowly propagated

Count-to-infinity problem
 Moving nodes create confusion:
 they carry connectivity data which are wrong at
new place
 Table exchange eats bandwidth
DSDV
How DSDV addresses the problems?
 Tagging of distance information:
The destination issues increasing sequence
number
 Other nodes can discard old/duplicate updates

 Changes are not immediately propagated

Wait some setting time
 Incremental updates instead of full table
exchange
GPSR
 Separate slides …
TDDD36: Routing
More stuff …
TDDD36: Routing
TDDD36: Routing
Ad Hoc On-Demand Distance
Vector Routing (AODV)
 As it is based on source routing, DSR includes




source routes in data packet headers
Large packet headers in DSR  risk of poor
performance if the number of hops is high
AODV uses a route discovery mechanism similar to
DSR, but it maintains routing tables at the nodes
AODV ages the routes and maintains a hop count
AODV assumes that all links are bi-directional
TDDD36: Routing
AODV
 Route Requests (RREQ) are forwarded in a manner
similar to DSR
 When a node re-broadcasts a Route Request, it
sets up a reverse path pointing towards the source

AODV assumes symmetric (bi-directional) links
 When the intended destination receives a Route
Request, it replies by sending a Route Reply
 Route Reply travels along the reverse path set-up
when Route Request is forwarded
TDDD36: Routing
Reactive protocols – AODV
 Ad hoc On Demand Distance Vector routing
(AODV)
Very popular routing protocol
 Essentially same basic idea as DSR for
discovery procedure
 Nodes maintain routing tables instead of source
routing
 Sequence numbers added to handle stale caches
 Nodes remember from where a packet came
and populate routing tables with that
information

TDDD36: Routing
Ad Hoc On-Demand Distance
Vector Routing (AODV)
[Perkins99Wmcsa]
 DSR includes source routes in packet headers
 Resulting large headers can sometimes degrade
performance

particularly when data contents of a packet are small
 AODV attempts to improve on DSR by maintaining
routing tables at the nodes, so that data packets
do not have to contain routes
 AODV retains the desirable feature of DSR that
routes are maintained only between nodes which
need to communicate
TDDD36: Routing
AODV : Route discovery (1)
Q
F
A
E
S
B
G
R
C
K
H
D
J
P
M
I
L
N
TDDD36: Routing
AODV : Route discovery (2)
Q
F
A
E
S
B
G
R
C
: Route Request (RREQ)
K
H
D
J
P
M
I
L
N
Note: if one of the intermediate nodes (e.g.,
knows a route to D, it responds
immediately t
TDDD36: Routing
AODV : Route discovery (3)
Q
F
A
E
S
B
G
R
C
K
H
D
J
P
M
I
L
N
: represents a link on the reverse path
TDDD36: Routing
AODV : Route discovery (4)
Q
F
A
E
S
B
G
R
C
K
H
D
J
P
M
I
L
N
TDDD36: Routing
AODV : Route discovery (5)
Q
F
A
E
S
B
G
R
C
K
H
D
J
P
M
I
L
N
TDDD36: Routing
AODV : Route discovery (6)
Q
F
A
E
S
B
G
R
C
K
H
D
J
P
M
I
L
N
TDDD36: Routing
AODV : Route discovery (7)
Q
F
A
E
S
B
G
R
C
K
H
D
J
P
M
I
L
N
TDDD36: Routing
AODV : Route reply and setup
of the forward path
Q
F
A
E
S
B
G
R
C
K
H
D
J
P
M
I
L
N
: Link over which the RREP is transmitted
: Forward path
TDDD36: Routing
Route reply in AODV
 In case it knows a path more recent than
the one previously known to sender S, an
intermediate node may also send a route
reply (RREP)
 The freshness of a path is assessed by
means of destination sequence numbers
 Both reverse and forward paths are purged
at the expiration of appropriately chosen
timeout intervals
TDDD36: Routing
AODV : Data delivery
Q
F
A
S
Data
E
B
G
R
C
K
H
D
J
P
M
I
L
N
The route is not included in the packet
header
TDDD36: Routing
AODV packets
 ROUTE REQUEST
 ROUTE REPLY
TDDD36: Routing
AODV : Route maintenance (1)
Q
F
A
S
Data
E
B
G
R
C
K
H
X
D
J
P
M
I
L
N
TDDD36: Routing
AODV : Route maintenance (2)
Q
F
A
RERR(G-J)
E
G
S
B
R
C
K
H
X
D
J
P
M
I
L
N
When receiving the Route Error message
(RERR),
S removes the broken link from
its cache.
TDDD36:
Routing
It then initializes a new route discovery.
AODV: Route maintenance
TDDD36: Routing
AODV: Destination sequence
numbers
 If the destination responds to RREP, it places its
current sequence number in the packet
 If an intermediate node responds, it places its
record of the destination’s sequence number in the
packet
 Purpose of sequence numbers:
 Avoid using stale information about routes
 Avoid loops (no source routing!)
TDDD36: Routing
1.
AODV : Avoiding the usage of
… Dtables S
stale
routing
…
S
A
A
2.
DSN(D) = 5
DSN(D) = 5
B
B
DSN(D) = 8
: Forward path
3.
S
A
RREQ
B
D
…
D
4.
S
DSN(D) = 5
A
RREP
B
DSN(D) = 8
D
…
DSN(D) = 5
DSN(D) = 8
TDDD36: Routing
AODV : Avoiding loops
A
B
S
X
D
C
: Forward pat
• Assume there is a route between A and D; link S-D breaks; assume A is not aware of this, e.g
RERR sent by S is lost
• Assume now S wants to send to D. It performs a RREQ, which can be received by A via path S
• Node A will reply since it knows a route to D via node B
• This would result in a loop (S-C-A-B-S)
• The presence of sequence numbers will let S discover that the routing information from A is
• Principle: when S discovers that link S-D is broken, it increments its local value of DSN(D). In
the new local value will be greater than the one stored by A.
TDDD36: Routing
AODV (unicast) : Conclusion
 Nodes maintain routing information only
for routes that are in active use
 Unused routes expire even when the
topology does not change
 Each node maintains at most one next-hop
per destination
 Many comparisons with DSR (via simulation)
have been performed  no clear conclusion
so far
TDDD36: Routing
Flooding of Control Packets
 How to reduce the scope of the route
request flood ?
Location Aided Routing LAR [Ko98Mobicom]
 Query localization [Castaneda99Mobicom]

 How to reduce redundant broadcasts ?
 The Broadcast Storm Problem [Ni99Mobicom]
TDDD36: Routing
Location Aided Routing (LAR)
 Advantages
 reduces the scope of route request flood
 reduces overhead of route discovery
 Disadvantages
Nodes need to know their physical locations
 Does not take into account possible existence
of obstructions for radio transmissions

TDDD36: Routing
Geographic Distance Routing
(GEDIR) [Lin98]
 Location of the destination node is assumed known
 Each node knows location of its neighbors
 Each node forwards a packet to its neighbor closest to
the destination
 Route taken from S to D shown below
H
A
S
D
B
E
F
C
G
obstruction
TDDD36: Routing
Geographic Distance Routing
(GEDIR) [Stojmenovic99]
 The algorithm terminates when same edge traversed
twice consecutively
 Algorithm fails to route from S to E
 Node G is the neighbor of C who is closest from
destination E, but C does not have a route to E
H
A
S
D
B
E
F
C
G
obstruction
TDDD36: Routing
Routing with Guaranteed
Delivery [Bose99Dialm]
 Improves on GEDIR [Lin98]
 Guarantees delivery (using location
information) provided that a path exists
from source to destination
 Routes around obstacles if necessary
 GPSR: A similar idea also appears in
[Karp00Mobicom]
TDDD36: Routing
QoS: Network layer solutions
 MAC protocols: bandwidth reservation,
real-time support only for link
 Network layer is host-to-host specific
resource negotiation
 reservation
 reconfiguration

 QoS routing protocols
 search for routes with resources that satisfy
QoS reqs
 find paths that consume minimum resources
TDDD36: Routing
QoS routing in ad-hoc networks
TDDD36: Routing
QoS-enabling routing protocols
h
Si = 1 (Li(m)), Li 
 Additive metrics:
Am =
P
 Concave metrics:
Cm = min(Li(m)), Li  P
 Multiplicative metrics: Mm =
h
P i = 1(Li(m)), Li  P
Two examples follow: ticket-based and QoSenabled AODV
TDDD36: Routing
A distributed ticket-based QoS
routing protocol for MANETs
 Chen and Nahrstedt (1999)
 Tolerates imprecise state information
during QoS route computation
 Probes multiple paths in parallel, limited by
tickets
 Optimality is explored
 Uses primary-backup-based fault tolerance
to reduce service interruption
TDDD36: Routing
QoS-enabled AODV
 QoS extensions in routing table:
 Maximum delay
 Minimum available bandwidth
 List of sources requesting delay guarantees
 List of sources requesting bandwidth
guarantess
TDDD36: Routing
QoS frameworks for MANETs
 Service model
 Routing protocol
 Resource reservation signaling
 Admission control
 Packet scheduling
TDDD36: Routing
QoS framework: Flexible QoS Model
for Mobile ad-hoc networks (FQMM)
TDDD36: Routing