/
Hardware, Software, and Protocols for the next generation of Environmental Monitoring Hardware, Software, and Protocols for the next generation of Environmental Monitoring

Hardware, Software, and Protocols for the next generation of Environmental Monitoring - PowerPoint Presentation

clustik
clustik . @clustik
Follow
344 views
Uploaded On 2020-06-30

Hardware, Software, and Protocols for the next generation of Environmental Monitoring - PPT Presentation

Johns Hopkins University Department of Computer Science Graduate Board Oral Presentation May 23 2012 Advisor Dr Andreas Terzis Chair Dr Alex Szalay Doug Carlson Outline Background Problem statement ID: 789798

data hardware flood network hardware data network flood figure problem packet node work background related nodes transmissions routing statement

Share:

Link:

Embed:

Download Presentation from below link

Download The PPT/PDF document "Hardware, Software, and Protocols for th..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.


Presentation Transcript

Slide1

Hardware, Software, and Protocols for the next generation of Environmental Monitoring Networks

Johns Hopkins University Department of Computer ScienceGraduate Board Oral PresentationMay 23, 2012Advisor: Dr. Andreas TerzisChair: Dr. Alex Szalay

Doug Carlson

Slide2

Outline

BackgroundProblem statementThe Breakfast hardware suiteCX: leveraging concurrent transmissions for multipath data collection

2

Outline

Slide3

Background

Background. Problem Statement. Hardware. CXBackground3

Slide4

WSNs for

Environmental MonitoringSample periodically (~O(minutes))Collect data wirelesslyLoose latency

requirements (hours or days)

High yield

requirements (>99%)

Survive on batteries for months or years

4

150 m

Background

Slide5

Current Approach

HardwareTelosB “Mote”Microcontroller, radio, storageUp to 4 analog inputsSoftwareKoala [Musaloiu et al, 2008]Radios off except for batch downloads

Centralized source routing

Offline timestamp reconstruction [EWSN 2010]

Delta compression, storage stack [REALWSN 2011]

Background

5

Slide6

Problem statement

Background. Problem Statement. Hardware. CXProblem Statement6

Slide7

Larger Networks: More Data Forwarding

Problem Statement7

Slide8

Standard Protocols Don’t Scale Well

Problem Statement8Source: Does Wireless Sensor Network Scale? A Measurement Study on

GreenOrbs

. Liu et al, INFOCOM 2011

Slide9

Route Selection

is Hard9Problem StatementHard-to-capture effects present

Link quality freshness matters

Figure 1

Slide10

Problem: Technical Approach Doesn’t Match Usage Patterns

10High deployment and maintenance effortEnergy usage and routing failures grow with network size

New hardware: efficient allocation, automate tasks.

Hierarchical networks, robust multi-path data collection

Problem Statement

Problem

Solution

Slide11

Hardware

Background. Problem Statement. Hardware. CXHardware11

Slide12

Matching Hardware to

Deployment Patterns12HardwareFigure 4

Slide13

13

More efficient allocation

Automate tracking tasks

Decoupling

: energy savings, SW design

improvements

Hardware

Figure 4

Slide14

Reduce Deployed and Maintained Hardware

USDA deployment20 TelosB nodes Replaceable with 2 Bacon + 10 Toast<50% of HW cost1/10th of the monitored/maintained devices14Hardware

Node

Relay

Uplink

Slide15

Eliminate Manual Tracking Tasks

15Hardware

Field

Database

Lab

Data

Calibrate

Toast

Register sensors

Sensor associations

Record sensor associations

Enter sensor associations

Deploy

Deploy

Slide16

Hardware Status

Hardware is in productionDrivers written for peripheralsToast auto-discovery and metadata storage written End user analog sensor setup Integration with existing data pipeline16Hardware

Slide17

CX

Background. Problem Statement. Hardware. CXCX17

Slide18

Routing Revisited

Hardware alleviates bottleneck nodes and reduces network depth.Route selection and maintenance is still hard in low-power setting.Route-free data collection: possible with network floodsNetwork floods can be made efficient with concurrent transmissions [Ferrari et al, 2012]18CX

Bacon hardware lets us schedule concurrent transmissions better than existing hardware does.

This lets us build more efficient techniques than flooding.

Slide19

Slot

Cycle

0

1

2

100

101

102

5000

5001

5002

Frame

CX Principles

In a given frame, all nodes transmitting a packet transmit the same packet.

Each slot

is “owned” by one node.

In a given frame, all nodes which transmit do so at the start of the frame.

19

Single

TDMA schedule

, disseminated by root

node

CX

Slide20

Flood

CX20

Slide21

Scoped Flood

One-to-one communication2 ACK frames to every Data frameAcks “catch up” and suppress flood.21

CX

Figure 6

Slide22

Scoped Flood

CX

22

Slide23

Scoped Flood

Learn distance, establish forwarders

Send first packet via

(pre-routed) flood

Delay based on distance

D

A

F

F

Send next packet

Transport Layer- Unreliable Burst

23

CX

Slide24

Initial Results: Link/

Phy Layer24CXFigure 7(a)

Figure 7(b)

Slide25

Initial Results:

Network/Transport LayerPower: 7.2mW (16% of always-active)Average goodput: 17.6B/min/nodeCompetitive with Koala when corrected for goodput25

CX

Figure 8

Slide26

Improving CX Performance: Delivery

Forward Error CorrectionMeasure/validate burst packet spacingInclude shortest paths +1 in burstIncorporate retransmissions26CX

Figure 7 (b)

50K

100K

125K

250K

FEC Off

96.2%

75.2%

88.8%

11.9%

FEC On

99.5%

95.9%

94.9%

15.8%

Slide27

Improving CX Performance: Duty

CycleIncorporate transport layer information27CXNo burst transfer detected

Not on shortest path

One Slot

Sender

On shortest path

TX

RX

Off

Slide28

Possible Expansions

Adapting TX power and symbol rate to trade energy for rangePerformance in high-mobility scenariosApplications to relay placement in partially-connected areasCX28

Slide29

To Recap

Problem: Mismatches between hardware, networking, and real-world deployment patterns limit scalability.Breakfast hardware suite: reduce cost, ease deployment effort, improve maintainability.Hierarchical network structure: limit impact of deployment size on sensing node lifetime.In-patch data collection: Energy-efficiency and robustness possible with CX.29Conclusion

Slide30

Acknowledgements

Andreas Terzis, Kathy Szlavecz, and Alex Szalay for guidance and motivation.Razvan M-E, Jayant Gupchup, Mike Liang for laying the foundations for our work in EM.Marcus Chang for help/guidance on the intricacies of developing for new platforms.Yin Chen and Marcus Chang for nurturing the ideas in CX, running experiments, and generally working really, really, really hard.Scott Pitz, Lijun Xia, Chih-han

Chang, Mike Bernard, and many others that made deployments possible.

The GBO Committee for your time in a very busy day.

30

Conclusion

Slide31

Current Approach- Software

KoalaSample/store data periodicallyCentral basestation wakes up networkBasestation uses local network connectivity information to build source-routed paths to each nodeDownload outstanding data from each node, one at a timeReturn network to sleep31Background

Slide32

WSNs for Environmental Monitoring

Wirelessly collect sensor data.Sensors at sites of interest.Survive on batteries for months or years.

32

Background

Slide33

Table 1: Summary of Deployments

Background33

Slide34

Why is Bacon better at this than Telos?

Access to accurate and precise high frequency timer (26 MHz)Flexible symbol rate (< 2 Mchip/S on Telos)Permits delays of many mS between receiving and retransmittingLacks coding redundancy (e.g. Direct Sequence Spread Spectrum)34

CX

Slide35

Principle of concurrent transmissions

35CX

Slide36

CX Network Stack

36CXFigure 5

Slide37

Figure 6: Flood v. Scoped Flood

CX37

Slide38

Flood

One-to-many(Ideally) reaches all nodesCompletion time bounded by network diameter38

CX

Figure 6

Slide39

Figure 7: Single-hop CX tests

CX39

Slide40

Eliminate Manual Tracking Tasks

40

Enter Metadata

Record sensors and associations

Store Calibration Results

Upload Metadata

Record sensors

Hardware

Slide41

Decouple sensing, storage, and communication

Reduce powerCentralize energy consumptionImprove SW design41Toast

Sensing, compression, signal processing

Bacon (Leaf)

Storage, forwarding within patch

Bacon (Router)

Storage, forwarding to sink

TelosB

Node

Sensing, compression, signal processing,

storage, forwarding to sink

Energy Consumption

Hardware

Slide42

Table 2: Hardware Comparison

Hardware42

Slide43

Figure 4: Breakfast Overview

Hardware43

Slide44

Coping with Disconnection: Phoenix (EWSN 2010)

44Use set of time references to map mote measurements to global time scaleIncreased yield from < 90% to >99%

Previous Work

Figure 2

Slide45

Adapting to Campaign Deployments (REALWSN 2010)

Delta compression: 70-74% savings vs. uncompressed>99% of total data yield timestamped

45

Previous Work

Figure 3

Slide46

Flip-MAC: Density-adaptive contention reduction (DCOSS 2011)

Previous Work46

Slide47

Flip-MAC results

Previous Work47

Slide48

Impact of instability on route success

Problem Statement48

Slide49

Intentional well-formed collisions

CX- Expansion49

Sender 1

Sender 2

Receiver

Slide50

Relay clustering

CX- Expansion

50

Slide51

Robust one-to-many communication

Disseminate: flood data packetRepair:Alternate NACK and DATA framesNodes without packet send NACK during NACK frameNodes with packet send data if they got a NACK in the previous frame. CX- Expansion51

Slide52

CX and Mobility

No persistent routing statePath discovery completes in << 1 secondCX- Expansion52

Slide53

Adaptive power and data rate

Lower symbol rate: better sensitivityPower consumption constant, duration changesReduce network depthCX- Expansion53

Slide54

Related work: ExOR (

Biswa & Morris, 2005)Attempts to opportunistically exploit long, lossy linksBroadcast, forwarder chosen from pool of receiversChallenge is to get pool of receivers to agree on which is the “closest” to the destinationGoal is to improve throughputRelated Work54

Slide55

RW: Zigbee

Router nodes may not duty cycleStar network: single hop onlyTree network: static routingMesh network: AODV, source routingRelated Work55

Slide56

Related Work- Analaysis of multipath routing Part I: The effect on the packet delivery

ratio (Tsirigos and Haas, 2004)Motivated by link instability in wireless ad hoc networksSplit up/encode data with some redundancySend encoded chunks on different pathsDistributes number of chunks on each path based on that path’s estimated PRR.Related Work56

Slide57

RW: Fully Wireless Implementation of Distributed

Beamforming on a Software Defined Radio Platform (Rahman, Baidoo-Williams 2012)Beamforming: attempt to phase-align transmissions to maximize constructive interference at receiverAccomplished using simple software techniques: senders randomly perturb phase of their transmission, get feedback on whether it increased or decreased RSS from receiverNot applicable to flooding: we want to reach multiple physical locations so we can’t use beam-formingWould be nice to have some support for this in future radio HW

Related Work

57

Slide58

RW: The Capacity of Wireless Networks (Gupta & Kumar, 2000)

Under optimal conditions, throughput for a node is theta(w/sqrt(n)), w = speed n = nodes in networkAt a high level: throughput diminishes as the nodes in a network increaseTry to keep networks small!Related Work58

Slide59

RW: Glossy (Ferrari, Zimmerling, Thiele et al)

Efficient Network Flooding and Time Synch with Glossy (IPSN 2011)The Bus Goes Wireless … (IQ2S 2012)Also advocates a routing-free communication strategyApproaches lower bound on flood latency60 second IPIAchieves > 99% end-to-end PRRDuty cycle < 2% on 85-node 3-hop testbedOur approach has same number of transmissions for flood, fewer for scoped flood. Outperforming this will come down to duty cycle tuning. Related Work

59

Slide60

(7,4) code: Rate = 0.5 when including 2-bit error detection

implemented with relatively small lookup tables, higher coding rates require code/decode routinesRelated Work60

RW: Hamming Codes

(Source: Wikipedia)

Slide61

RW: Trickle (Levis et al, 2004)

“Polite gossip” for disseminating small units of data throughout a networkNodes adaptively increase the delay between retransmitting a packet when it’s been “in the air” for a whileExemplifies the difficulty of coordinating floodsRelatively long propagation delays (10s of seconds/minutes) Related Work61

Slide62

RW: Flash Flooding (Lu, Whitehouse 2009)

Rely on capture effect to survive collisionsAttempts to control number of concurrent transmissions, detect/restart failed floodsEdges of network see poor completion timesNote Naïve Flood completion (X-MAC)Related Work

62