Diapositiva 1 - PowerPoint PPT Presentation

1 / 26
About This Presentation
Title:

Diapositiva 1

Description:

Thanks and enjoy! SignetLab2: a modular management architecture for wireless sensor networks ... Time sharing management. Thanking. That's all Folks. Let's have ... – PowerPoint PPT presentation

Number of Views:47
Avg rating:3.0/5.0
Slides: 27
Provided by: TEO94
Category:

less

Transcript and Presenter's Notes

Title: Diapositiva 1


1
SignetLab2 a modular management architecture
for wireless sensor networks
A note on the use of these ppt slidesWere
making these slides freely available to all,
hoping they might be of use for researchers
and/or students. Theyre in PowerPoint form so
you can add, modify, and delete slides
(including this one) and slide content to suit
your needs. In return for use, we only ask the
followingIf you use these slides (e.g., in a
class, presentations, talks and so on) in
substantially unaltered form, that you mention
their source.If you post any slides in
substantially unaltered form on a www site, that
you note that they are adapted from (or perhaps
identical to) our slides, and put a link to the
authors webpage www.dei.unipd.it/zanella Thank
s and enjoy!
2
2007 Tyrrhenian Workshop on Digital
Communications TIWDC 2007
SignetLab2 a modular management architecture for
wireless sensor networks
R. Crepaldi, Andrea Zanella, and M.
Zorzi Department of Information Engineering,
University of Padova A. Harris III Department of
Computer Science, University of Illinois at
Urbana-Champaign
3
Why a testbed?
  • Simulator
  • Propagation model too simple
  • Hard to predict fading, shadowing, multi-path,
    time variance
  • Simulated code not always the same installed on
    the nodes
  • Real network deployment
  • Network deployment expensive
  • Energy constraints
  • Not a permanent structure

4
Desired properties of a testbed
  • Productivity
  • Easy setup
  • Less time for setup -gt More time for research
  • Easy to maintain
  • Repeatability
  • Confirm results
  • Compare different algorithms
  • Isolated control plane
  • Debug and log data not on the shared channel
  • Test of the actual algorithm
  • Manageable Network configuration
  • Test multiple topologies
  • Test on multiple boards

5
Goals in Testbed manager design
  • Management
  • Full control of the network
  • Full control of each node
  • Easy access from local and remote
  • Provide an abstraction to the hardware
  • Provide data collection and analysis functions
  • Flexibility
  • Large variety of experiments
  • Easy to upgrade

6
SignetLab testbed
7
Hardware the eyesIFX node
Energy Efficient Sensor (UE Project
(IST-2001-34734) mar 2002-feb 2005)?
  • Based on MSP430 µC by Texas
  • Instruments
  • Adjustable TX power
  • 2 antennae
  • Sensors
  • Temperature
  • Light intensity
  • RSSI (Received Signal Strength Indicator)?
  • USB interface
  • Programming
  • Offline communication

8
Management Tool SignetLab Manager
9
Limits of SignetLab management tools
  • Pros simple and non intrusive
  • compilation
  • node reprogramming
  • code debugging
  • data collection
  • Cons require USB backbone!
  • Cost of cables and hubs
  • Heating problems
  • Limited scalability
  • Deployment issues
  • Challenges
  • No wired backbone
  • Control and monitoring data must be passed over
    the wireless links
  • control data may interfere with the applications
  • low data rate demands minimal control
  • Control management data drain battery supply
  • Applications may have drastically different
    management demands
  • Need for fine-grained control over the network

10
(No Transcript)
11
Basic features
  • The main application interface includes a
    topology map that allows researchers to easily
    visualize the sensor network
  • Through plugins, users can display various data
    from each of the nodes on the map
  • SignetLab2 accepts simple topology files that
    define the locations of nodes and can be updated
    via localization algorithms during runtime.
  • Other panes can be rapidly developed by users
    through use of the API to match the monitoring
    needs of specific applications.
  • Nodes can be programmed and controlled via
    SignetLab2
  • there is no separate control plane
  • control may interfere with any data being
    collected at the sinks
  • Server use some sensors as relays towards the
    sensor network

12
SignetLab2 plugins
  • SignetLab2 provides an API which
  • provides a number of basic functionalities to
    ensure the rapid design of new plugins
  • permits easy development of custom interfaces to
    meet applications needs
  • Example of plug-ins
  • Network programming controller pluging
  • Epidemic nodes reprogramming via wireless
  • Reliability obtained by using fountain coding
    techniques
  • Boot loader in each device run the new program
    once correctly transferred
  • environment monitoring plugin
  • collects information about temperature, light
    intensity and battery level from each node
  • displaying on the network map
  • User can set thresholds for each sensed value if
    exceed the plugin can change the node image on
    the map and alert the user

13
Application
  • Graphical network map
  • Easy visualization of real-time activity

14
Case study development of fire detection
application
  • State of the art fire detectors work in a rather
    simple way
  • Smoke detector
  • ionization and photoelectric detectors
  • prone to false alarm (e.g., when cooking)?
  • Heat detector
  • Trigger an alarm when temperature exceeds a fixed
    threshold
  • Require handmade installation and setting
  • Stand alone working
  • Each sensor works by itself
  • Prone to false alarms due to malfunctioning of
    single devices
  • Desired features of fire detection system
  • promptly detect the start of a fire in different
    environments
  • Use advanced strategies to detect fire ignition
  • e.g., control temperature increase slop instead
    of absolute value
  • Reduce the amount of false alarm
  • Provide support to human and/or automatic
    reactions
  • activating an alarm bell
  • sending an alarm notice to the fire department
  • activating fire sprinklers

15
Fire heat signature
  • I) Ignition phase
  • low rate of temperature increase
  • II) Propagation phase
  • rapid increase in temperature and area covered by
    the fire
  • lasts for several minutes
  • III) Generalized fire phase,
  • all objects in the fire are ignited
  • IV) Estinguishing phase
  • most of the flammable material is burned and the
    fire slows
  • Fire sprinklers shall be activated before
    flashover

Flashover
16
(No Transcript)
17
SFiDe state diagram
  • Nodes usually operate in Normal mode and enter
    Alarm mode whenever a potential fire event is
    detected

State diagram in Normal mode
Listen radio channel for TS
Activate sensing radio
No
No
Sleep for TOFF
Any alarm?
Received any transmission?
Yes
Yes
Enter Alarm mode as Master
Enter Alarm mode as Slave
18
SFiDe state diagram
Alarm mode Master state diagram
Sent NA ALARM pcks?
No
No
Send ALARM to sink
Send QUERY every TQ
Yes
Send WARNING to sink
Receive REPORT
Sent NQ queries?
Yes
Send ALARM_END and enter Normal mode
19
(No Transcript)
20
(No Transcript)
21
Parameters list
  • Uncontrollable parameters
  • R nominal coverage range
  • D maximum network diameter
  • N Node density (nodes per coverage area)?
  • PON energy spent during ON mode
  • POFF energy spent during OFF mode
  • Esw energy spent in switching between ON and OFF
    modes
  • Controllable parameters
  • TC ON-OFF cicle period TC TONTOFF
  • d duty cycle (TON/TC)?
  • Ts sensing interval before becoming MASTER
  • TQ QUERY interval
  • WQ query contention window size
  • NQ number of queries between ALARM pcks

22
Performance Indexes
  • Tnet Network lifetime
  • Time for a node to deplete its battery in normal
    mode
  • Target value Tnet gt 6 months
  • ? average message delivery latency
  • Average time taken by a WARNING packet to reach
    the sink from the farthest zone
  • Target value ? lt 120 sec
  • Aim
  • Reduce TC to speed up fire detection
  • Increase TC to reduce energy consumption in
    switching ON and OFF
  • Increase duty cycle to speed up message delivery
  • Reduce duty cycle to limit energy consumption in
    ON mode
  • Tradeoff!

23
Setting TC and duty cycle d
  • R 5 m
  • D 100m
  • N10
  • GeRaF routing algorithm
  • TC30 s (reasonable)?

Tnet5000 hgt6 month
  • Duty cycle is fixed at
  • d 2

? lt 90 s
24
Some results
25
Conclusions
  • Management
  • Full control of the network done!
  • Full control of each node done!
  • Easy access from local and remote done!
  • Provide an abstraction to the hardware done!
  • Provide data collection and analysis functions
    done (through plugins)!
  • Flexibility
  • Easy management of different topologies ok!
  • Testbed deployable outdoor ok (in principle...
    Didnt tray yet)?
  • Different boards supported ok!
  • Future direction
  • Increase dimensions of the network
  • Time sharing management

26
Thanking
Thats all Folks Lets have limoncello now!
Write a Comment
User Comments (0)
About PowerShow.com