Upload
alisha-rogers
View
214
Download
1
Tags:
Embed Size (px)
Citation preview
SignetLab2: a modular management architecture
for wireless sensor networks
A note on the use of these ppt slides:We’re making these slides freely available to all, hoping they might be of use for
researchers and/or students. They’re 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 following:If 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
Thanks and enjoy!
A note on the use of these ppt slides:We’re making these slides freely available to all, hoping they might be of use for
researchers and/or students. They’re 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 following:If 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
Thanks and enjoy!
SignetLab2: a modular management architecture for
wireless sensor networksR. Crepaldi, Andrea Zanella, and M. Zorzi
Department of Information Engineering, University of PadovaDepartment of Information Engineering, University of Padova
A. Harris III
Department of Computer Science, University of Illinois at Urbana-Department of Computer Science, University of Illinois at Urbana-ChampaignChampaign
2007 Tyrrhenian Workshop on Digital Communications 2007 Tyrrhenian Workshop on Digital Communications
TIWDC 2007TIWDC 2007
12 September 2007 3 Andrea Zanella
Why a testbed?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
12 September 2007 4 Andrea Zanella
Desired properties of a testbedDesired properties of a testbed
• Productivity– Easy setup
Less time for setup -> 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
12 September 2007 5 Andrea Zanella
Goals in Testbed manager designGoals 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
12 September 2007 6 Andrea Zanella
SignetLab testbedSignetLab testbed
12 September 2007 7 Andrea Zanella
Hardware: the eyesIFX nodeHardware: the eyesIFX node
• 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
Energy Efficient Sensor (UE Project (IST-2001-34734) mar 2002-feb 2005)
12 September 2007 8 Andrea Zanella
Management Tool: SignetLab ManagerManagement Tool: SignetLab Manager
12 September 2007 9 Andrea Zanella
Limits of SignetLab management toolsLimits 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
12 September 2007 10 Andrea Zanella
SolutionSolution
• Modular architecture– General functions provided by SignetLab2 core– API to write application-specific plugins
RelayNode
Relay Node
Serial Fw Serial Fw
Messageserver
Messageserver
Messageserver
Plug-in Plug-in
SignetLab2
NodeNode
12 September 2007 11 Andrea Zanella
Basic featuresBasic 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 September 2007 12 Andrea Zanella
SignetLabSignetLab22 plugins 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
12 September 2007 13 Andrea Zanella
ApplicationApplication
• Graphical network map• Easy visualization of real-time activity
12 September 2007 14 Andrea Zanella
Case study: development of fire detection Case study: development of fire detection applicationapplication
• 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
12 September 2007 15 Andrea Zanella
Fire heat signatureFire heat signature
I) Ignition phase– low rate of temperature
increaseII) Propagation phase
– rapid increase in temperature and area covered by the fire
– lasts for several minutesIII) 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
12 September 2007 16 Andrea Zanella
SFiDe: SignetLab Fire Detection systemSFiDe: SignetLab Fire Detection system
wired network
Remote control station
WSN control center
SignetLab2 server
SignetLab2 client TCP
USB
SINK
Monitored area
12 September 2007 17 Andrea Zanella
SFiDe: state diagramSFiDe: state diagram
• Nodes usually operate in Normal mode and enter Alarm mode whenever a potential fire event is detected
State diagram in Normal modeState diagram in Normal mode
Sleep for TOFF
Activate sensing &
radio
Any alarm?
Listen radio
channel for TS
Received any
transmission?
Yes Yes
No No
Enter Alarm mode as Master
Enter Alarm mode as Slave
12 September 2007 18 Andrea Zanella
SFiDe: state diagramSFiDe: state diagram
Send ALARM_END and enter Normal
mode
Sent NA
ALARM
pcks?
Send WARNING
to sink
Send QUERY
every TQ
Receive REPORT
Sent NQ
queries?
Yes
No
Send ALARM to sink
Yes
No
Alarm mode: Master state diagramAlarm mode: Master state diagram
12 September 2007 19 Andrea Zanella
SFiDe: state diagramSFiDe: state diagram
Listen the channel
QUERY receive
d?
N0
No
Route the pck to the sink
Yes
No ALARM, WARNIN
G?
TC elapsed?
Enter Normal mode
Yes
Yes
Send REPORT on random
slot
Alarm mode: Slave state diagramAlarm mode: Slave state diagram
12 September 2007 20 Andrea Zanella
QUERY
wired network
Remote control station
WSN control center
SignetLab2 server
SignetLab2 client TCP
USB
SINK
Monitored area
SFiDe: SignetLab Fire Detection systemSFiDe: SignetLab Fire Detection system
WARNING
REPORT
REPORT REPORT
12 September 2007 21 Andrea Zanella
Parameters listParameters 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 = TON+TOFF
– 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
12 September 2007 22 Andrea Zanella
Performance IndexesPerformance Indexes
• Tnet: Network lifetime– Time for a node to deplete its battery in normal mode
– Target value: Tnet > 6 months
: average message delivery latency– Average time taken by a WARNING packet to reach the sink
from the farthest zone– Target value: < 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!
12 September 2007 23 Andrea Zanella
Setting TSetting TCC and duty cycle d and duty cycle d
• R = 5 m• D = 100m• N=10• GeRaF routing algorithm
• TC=30 s (reasonable)
Tnet=5000 h>6 month
< 90 s• Duty cycle is fixed at• d = 2%
12 September 2007 24 Andrea Zanella
Some resultsSome results
12 September 2007 25 Andrea Zanella
ConclusionsConclusions
• 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... Didn’t tray
yet)– Different boards supported: ok!
• Future direction– Increase dimensions of the network– Time sharing management
12 September 2007 26 Andrea Zanella
ThankingThanking
That’s all FolksThat’s all FolksLet’s have limoncello now!Let’s have limoncello now!