Dsr vs tinyos beaconing
Sponsored Links
This presentation is the property of its rightful owner.
1 / 24

DSR vs. TinyOS Beaconing PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

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.

Download Presentation

DSR vs. TinyOS Beaconing

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

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 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

  • 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):

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:

    • 7 participating nodes (including root)

    • Complete binary tree topology

    • No node mobility/failure

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


  • 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?!

  • Login