dsr vs tinyos beaconing
Skip this Video
Download Presentation
DSR vs. TinyOS Beaconing

Loading in 2 Seconds...

play fullscreen
1 / 24

DSR vs. TinyOS Beaconing - PowerPoint PPT Presentation

  • Uploaded on

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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' DSR vs. TinyOS Beaconing' - amandla

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
topics covered
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
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
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
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
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
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
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
TinyOS Beaconing
  • A Simplified Table Driven Approach
  • Allows for many-to-one sensor network data-centric 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
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
dynamic source routing
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
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
mote implementation
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
The monsters (revisited):

Programming Board


mica2 performance evaluation
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
Performance Comparison Cont’d
  • Given:
    • 7 participating nodes (including root)
    • Complete binary tree topology
    • No node mobility/failure
protocol mobility considerations
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
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
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
  • 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
C’est fini
  • Questions?!