SDSR – “Superior” DSR

Jay Chen

Siddharth Gidwani

Christopher Yap

Mobile Ad-Hoc Networks - MANETS

Mobile Ad-Hoc Networks– A collection of wireless mobile nodes forming a communication

network without centralized administration or existing network infrastructure

– Nodes perform both host and routing duties in order to transmit packets across the network

Applications– Wireless computing– Sensor networks– Security infrastructure– Military– Search and rescue operations

MANET Routing Protocol Overview

Destination Sequenced Distance Vector (DSDV)– Nodes maintain next-hop information– Periodic broadcast routing updates

Temporally Ordered Routing Algorithm (TORA)– Broadcast-determined routes; errors backflow packets– Periodically transmitted heartbeats to maintain neighbor list

Ad-Hoc On-Demand Distance Vector (AODV)– Uses on-demand DSR route discovery/maintenance– Hop by hop routing and periodic beacons like DSDV

Dynamic Source Routing (DSR)– Packets carry the entire hop by hop source route to the destination– No setup overhead, everything done on-demand (no periodic

broadcasts for neighbor connectivity)

MANET Routing Protocols - Continued

MANET protocols present a spectrum of choices varying from on-demand routing to shortest-path routing (periodic updates)

Turns out DSR is the most popular of the lot, as it offers superior performance under common applications and various deployment scenarios

A major reason DSR is preferred in MANETS is due to the elimination of the overhead from periodically updating state

DSR Routing Mechanisms

Route discovery– DSR nodes perform a flooding route request, which is

propagated through the network– Eventually it will be propagated to a node that knows a path

to the destination (ultimately the destination node)– This node returns a route reply containing the source route

to the requested destination Route maintenance

– Should a sent packet be unable to progress due to link failure, a route error is generated and propagated back to the sender

– The sender will then resort to either other cached routes, or perform a route discovery as a last resort

DSR - Weakness

Even though route requests are on demand, each request is a propagated broadcast

Results in unnecessary congestion both from the route requests and the associated route replies

The Approach

Considerations– Trend of mobile computing is that of more

powerful nodes– This is the not the case in sensor networks

Idea– Add some hierarchy – Reduce route flooding by limiting route request

functionality to a subset of nodes– Interaction with the proxy should be unicast

Related Work - Spine Routing

Spine Routing– Adds a level of hierarchy to the routing– Select a set of nodes to perform the bulk of the

routing operations– Non-spine nodes communicate through spine

nodes in order to interact with the network Exactly what we wanted, but…

– Optimal spine networks require global knowledge of the topology – very difficult in MANETs where nodes are mobile

The Goal

Maintain the demand-based attractiveness of DSR and leverage the advantages of Spine Routing without the overhead of maintaining a highly consistent spine

Maintaining some extra state at each node to lift some network overhead caused by flooding route requests

SDSR – Protocol Description

Selective Dynamic Source Routing – (SDSR)– Maintain the on-demand advantages of DSR, we’ll maintain

a “weakly consistent” spine that is also demand determined– Elect a few nodes in the network to serve as proxies– These proxies perform route request on behalf of their

clients– Re-election of proxies as needed– All other operations fall back on standard DSR– Our lower bound for routing overhead if all nodes act as

proxies is the same as DSR

Implementing & Testing the Protocol

NS-2 network simulator– Modified the DSR implementation available in ns-2 to add the

concept of proxies Traffic model

– We generate simple all pairs random traffic scenarios Mobility model

– Research area in itself• Random waypoint• Random direction• Terrain mappings• Structured group mobility• Flocking/swarming groups

– We spend some effort implementing “interesting” and more realistic mobility models

Mobility Models

Random waypoint– Most previous work done on this topic involved the random

waypoint model and it is a point of basis for validating results

Structured group mobility– Probably of use to military/disaster recovery efforts– May be a good fit with SDSR versus DSR since each group

operates in close proximity with each other and we can reduce the out of group traffic to a single node ideally

Simulation Parameters

Simulation Area – 500m x 500m

Number of Nodes – 10, 25, 50 nodes

Motion – uniform/non-uniform speed– 1-20, 20-25, 1-50, 20-50 m/s

Pause selection – constant/uniform– 1, 10 s

Number of connections– 1, 10, 100 connections/s

– TCP connections instead of CBR (constant bit rate) since CBR seems to be geared more towards sensor networks

Structured Group Mobility Parameters

Group Mobility– Number of groups

• 1-4

• 10 nodes per group

– Kept every parameter constant and varied one

iNSpect - Visualization tool

Performance Metrics

Routing overhead– Route request packets sent/forwarded– Route replies sent/forwarded

Route availability– Performance ratio defined as the number of resend attempts

on data packets vs the number actually sent• Note that a single packet may be attempted to be resent many

times or zero times before it is actually sent out

• This is essentially a measure of the standard concept of availability negatively weighted by the duration of each un-available route

Performance Metrics - Continued

Route lengths– We expect to be worse, since for non-proxy nodes the routes will

contain an extra hop corresponding to the proxies

Performance Results

Preliminary Results

Cases where we do worse

Cases where we do better

Group mobility model

Parameter tweaking

SDSR Flexibility – Parameter tweaking

SDSR performance is tied to five very important parameters that are set– Proxy request timeout (client)

• Maximum time to wait for a get proxy response before declaring itself as the proxy

– Get request timeout (client)• Time to wait for a proxy route response before attempting to find a new

proxy

– Client list timeout (proxy)• Time to wait before purging a non-communicating client

– Client threshold (proxy)• Number of clients proxy must maintain to continue being a proxy

– Initial proxy timeout (proxy)• Grace period for new proxies before being subjected to the client

threshold

SDSR Flexibility – Parameter tweaking

By tweaking these parameters we can greatly influence the performance of our protocol– Preliminary experimentation shows that we can improve the

performance of certain test cases over DSR

A point of future work might be to investigate determining these parameters dynamically, in order to optimally fit the situation at hand

Conclusion

Random waypoint model– 50% fewer routing related messages in some

cases

Structured group mobility model– Differences in performance are minimal

Parameter tweaking– Control knob for tradeoff between individual node

load and network congestion

Future work

Microbenchmarks of actual CPU load and memory usage– Not possible in ns-2

More runs for statistical significance of our test simulations

Investigation of other topologies and mobility models Actual implementation and testing

Questions?

Questions?