signetlab 2 : a modular management architecture for wireless sensor networks a note on the use of...

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


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


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


SignetLab testbedSignetLab testbed


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)


Management Tool: SignetLab ManagerManagement Tool: SignetLab Manager


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


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


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


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


ApplicationApplication

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


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


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


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


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



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



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


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


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


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!


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%


Some resultsSome results


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


ThankingThanking

That’s all FolksThat’s all FolksLet’s have limoncello now!Let’s have limoncello now!

signetlab 2 : a modular management architecture for wireless sensor networks a note on the use of...

Documents

ppt slides

slide content

unaltered form

andrea zanella hardware

andrea zanella goals

powerpoint form

permanent structure

research easy