Dsr vs tinyos beaconing
Download
1 / 24

DSR vs. TinyOS Beaconing - PowerPoint PPT Presentation


  • 199 Views
  • 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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
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
Dsr vs tinyos beaconing

DSR vs. TinyOS Beaconing

By: Brent Rood


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 MOTE


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



Conclusions
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
C’est fini

  • Questions?!