DSR vs. TinyOS
Beaconing
By: Brent Rood
Topics Covered
• Routing Protocol Overview
• Routing Protocol Implementation Details
– TinyOS Beaconing
– Dynamic Source Routing
• Performance Comparison
• Mote Implementation
• Java Sensor Network Querier
Ad Hoc Routing Protocols
• Two Basic Types of Ad Hoc Wireless
Routing Protocols used in Sensor
Networks
– Table Driven
• E.g. Dynamic Source Routing
– On Demand
• E.g. TinyOS Beaconing
Table Driven Protocols
• Attempt to maintain consistent up to date routing
information for each node
– In some cases, tables have nodes keep routes to
everyone
• Table number/size varies by protocol
– Sensor Network’s many-to-one communications
paradigm allows smaller tables
• Respond to network changes by propagating
information
– Allows for consistent topology information
On Demand Protocols
• Routes are only created on an as needed basis
• When a node requires a route, it initiates a route
discovery process
– Process completes upon receiving a route found message
– However, various metrics can be used to determine the returned
route that is accepted
• Route discovery process can continue until optimal route is found
• Route information is maintained in route database until:
– Destination is no longer needed
– Route times out
– An error packet indicates that the route has failed
Protocol Characteristics
• Table Driven
– Relies on underlying routing table update mechanism
• Involves constant propagation of information
– Routes always available (possibly useless)
• Resource constraints of sensor networks are sensitive to this
sort of useless energy expenditure for unneeded routes
• On Demand
– Routes only acquired when needed
• Direct result is that routes are not always available
Protocol Comparison
• On Demand protocols increase latency of
packets with unknown destinations
• Table Driven protocols require a constant
(possibly unneeded) overhead
• Balancing act with two factors:
– Desired latency (On Demand: Hi; Table: Low)
• Depending on rate of route changes and the need for routes
to unknown destinations
– Constant energy use (On Demand: Low; Table: Hi)
• Depending on the rate of constant update
TinyOS Implementations
• Two protocols implemented in TinyOS
– TinyOS Beaconing
– Simplified Dynamic Source Routing
• TOSSIM used to test/debug protocols
• MICA2 motes used for final analysis
TinyOS Beaconing
• A Simplified Table Driven Approach
• Allows for many-to-one sensor network datacentric routing paradigm
• Implemented Algorithm:
– Root of network broadcasts a HELLO beacon with it
as the source and hop count as 0
– All those hearing the beacon mark the root down as
their parent
– Node forwards the beacon message with its address
as the source and the hop count incremented
– Recursively, nodes will mark as their parent the node
from which they hear the beacon from and forward on
TinyOS Beaconing Cont’d
• Considerations
– Sequence Numbers
• Nodes avoid rebroadcasting old beacons by
keeping the current beacon sequence number on
hand
– Hop count is used as a metric
• If a node hears a packet with the latest sequence
number, but with a smaller hop count than they
adopt the source of that packet as their parent
– Note: This packet must also be rebroadcast
TinyOS Beaconing Tree (in TinyViz)
Dynamic Source Routing
• Example of a simple On Demand routing
protocol
• This implementation does not include
– Advanced route caching mechanisms
– Optimizations in terms of route selection
– Although it has the ability to maintain routes to
multiple destinations, only a route to the root
is ever obtained/cached
DSR Implemented Algorithm
• Upon a node needing a route to a destination, it creates a Route
Request (RREQ) packet and broadcasts
• All nodes receiving this packet, append their address to the packet
and forward it
• When received by the destination, the node generates a Route
Reply (RREP) packet
• The RREP is then source routed (using the provided list of nodes
addresses) back to the destination
• Now when the node has data to send, it just sends it source routed
(with the entire path attached)
– Each node need only forward the packet to the next address indicated
in the route
• RERR packets are generate upon failure of a link level send
– The node will then forward the RERR back to the source
– The source will generate another RREQ looking for a new route to the
destination
DSR Illustration
Mote Implementation
• Mica2 motes used
• Motes attached to sensor boards
– Programmed to automatically take light intensity
reading every 2 seconds
• DSR
– If a node does not have a route to the root upon
taking a reading, it initiates a route request (RREQ)
• TinyOS Beaconing
– Root node is programmed to initiate a beacon once
every two seconds
The monsters (revisited):
MICA2 MOTE
Programming
Board
Mica2 Performance Evaluation
• Given a sensor network of size N and no
mobility
– Beaconing generates N beacon packets every two
seconds (assuming un-partitioned network)
– DSR generates (assuming a roughly complete binary
tree like topology):
• Approximately (ln (N-1) * (N-1)) RREQ transmissions and
the same number of RREPs needed for all nodes to get route
to the root
– N-1 indicates number of nodes excluding root
– Ln factors in the depth of the binary tree
• 2 * ln(N) * N messages needed total
• After this initial investment, without mobility/failure, no more
routing messages need be generated
Performance Comparison Cont’d
• Given:
Total number of routing packets
– 7 participating nodes (including root)
– Complete binary tree topology
– No node mobility/failure
60
50
40
DSR
30
TinyOS
Beaconing
20
10
0
1
3
5
7
9
11 13 15
Time (seconds)
Protocol Mobility Considerations
• DSR
– RRER mechanism allows it to respond to
failure/mobility as soon as a sensor reading does not
reach the root
• TinyOS Beaconing
– Node continues to send to parent until
• A better route is found (less hops)
• The node doesn’t receive a beacon from its parent within a
timeout period
– Length of timeout dictates ability to adapt to varying degrees of
mobility
• Larger: Less unnecessary parent node timeouts
• Smaller: Able to adapt to mobility and choose new parent
sooner
Java Sensor Network Querier
• Implemented for CS527: Mobile
Networking
• Written in java; Utilizes:
– Java Comm. package to communicate with
mica2 mote over serial connection
– TinyOS included Java classes provide classes
used to create
• Mica2 packet listeners (for receiving readings)
• TOS_Msg and MoteIF objects (for injecting
packets into the network)
Java Sensor Network Querier
Cont’d
• Provides functionality
– Ability to target
• A specific node given address
• All motes
– Provide multiple functions
• Can toggle mote’s green LED
• Inform mote to begin piggy-backing information onto periodic
sensor reading packets such as:
– Current parent in tree
– Remaining power (currently just a static number)
• Tell node to turn on/off monitoring
– Periodic sensor readings will either commence/cease
Querier Image
Conclusions
• TinyOS Beaconing vs. DSR in sensor networks
depends on design considerations
– Mobility?
– Power constraints?
– Desired Latency?
• Overall, I recommend an On Demand protocol
such as DSR in static networks as it will
eliminate needless routing packet overhead
C’est fini
• Questions?!