engineering sensor networks for long-term environmental...

ENGINEERING SENSOR

NETWORKS FOR LONG-

TERM ENVIRONMENTAL

MONITORING

Guest lecturer: Doug Carlson

Hi. Who are you?

• I’m Doug Carlson, one of Dr. Terzis’s PhD students.

• I have been doing research on wireless sensing systems

and communication protocols at JHU here since 2008.

• You guys are going to be discussing my paper on

Thursday.

2

What are you doing here?

• Dr. Chang is out of town this week.

3

What are we doing here?

More specifically, answering the question:

How can we build efficient and scalable systems for

long-term environmental monitoring (LTEM)?

Learning stuff?

4

The Plan

• Discuss the LTEM application area and some usage

scenarios we have encountered.

• Talk about the inherent challenges of this application.

• Discuss potential HW/networking approaches to tackle

them.

• Present the solutions that me and my collaborators have

developed in this area.

5

BACKGROUND Background. Hardware. Networking.

Background 6

What are we working with?

• Limited hardware budget, favors mote-class devices

• Battery powered

• Radio range of 10’s to 100’s of meters

• Tends to be largest contributor to power budget

• Local data buffering in flash

• Some fixed number of ADC inputs

Background 7

LTEM Application Requirements

• Sample periodically (~O(minutes))

• Collect data wirelessly

• Loose latency requirements (hours or days)

• High yield requirements (>99%)

• Survive on batteries for months or years

8 Background

(Actually

clusters of

4-32

analog

sensors)

What challenges do you foresee?

(Actually

clusters of

2-8

sensors)

Background 9

Hardware Challenges

1. Necessary radio

communication ranges

vary widely across the

network.

2. Some deployments favor

uniform sensor coverage,

some favor dense

clusters.

3. In a large deployment,

how do you keep track of

what goes where?

Background 10

Networking Challenges

1. Coordinating a large,

patchy network.

2. Low power disconnected

operation.

3. Link state collection and

routing.

Background 11

HARDWARE Background. Hardware. Networking.

Hardware 12

HW problem 1: Variable Communication

Range Requirements 1. What options do we have?

2. What are the costs/benefits of

adding a second communication

channel (wifi, cell modem, etc)?

3. How might each of these options

impact our energy budget?

(Actually

clusters of

4-32

analog

sensors)

Hardware 13

Our Solution: modular RF front-end

• Leaf configuration

• +10 dBm output

power

• -90 dBm RX

threshold

• ~3 dB gain with PCB

antenna

• Router configuration-

PA/LNA, external

antenna.

• +26 dBm output

• -98 dBm RX

threshold

• Free-space range of

700m – 24km

Hardware 14

Problem 2: Sensor Allocation

• MCU has a fixed

number of ADC

inputs.

• How can you

effectively support

both sparse and

dense sensor

needs?

Node Relay Uplink

Hardware 15

20 Telos motes, most within ~5 m groups

Our solution: digital, chainable MUX board

• Connects up to 8 analog

sensors to each slave

MCU.

• I2C digital communication

• Automatic device

discovery

Hardware 16

HW Problem 3: Sensor metadata and

provenance • How do you interpret raw voltage measurements?

• How do you keep track of sensor calibrations?

• How do you associate data streams with physical

locations?

Hardware 17

Our Solution: Store types/IDs on MCU’s

• Barcode ALL THE THINGS

• Reflect this information in

flash.

• Send this information back

with sensor samples

• Android app to scan

barcodes and record their

physical locations

Hardware 18

NETWORKING Background. Hardware. Networking.

Networking 19

Networking Problem 1: Coordinating

large, patchy networks. • Given the hardware we’ve discussed, how might you

structure your network? Your collection protocol?

• How does the addition of a new node affect the duty cycle

of the rest of the network?

Networking 20

Larger Networks: More Data Forwarding

15

7

3

1 1

3

1 1

7

3

1 1

3

1 1

Networking 21

Larger Networks: More Data Forwarding

Networking 22

16

7

3

1 1

3

1 1

8

3

1 1

4

1 2

1

Larger Networks: More Data Forwarding

Networking 23

17

7

3

1 1

3

1 1

9

3

1 1

5

1 3

2

1

Our solution: separate router tier from leaf

tier • Leaves buffer data in

flash.

• Leaves push

outstanding data to

router when woken up.

• Routers buffer leaf data

in flash.

• Routers push

outstanding data to

base station when

woken up.

Separate channel for each patch.

Separate channel for routers.

Networking 24

Networking Problem 2: Disconnected

Operation • What should leaf nodes do when their router disappears?

• What should routers do when the base station

disappears?

• How can you re-associate nodes to the network?

Networking 25

Low Power Probing

• You guys talked about this, right?

TX

RX

TX

TX

RX TX

RX

RX

TX

TX

TX

RX TX

0 1

2

3

1

2

3

0

RX

TX RX

TX

Why don’t 1 and 2 collide?

Networking 26

How can we get the most out of this?

• What factors dictate the selection of a probe interval?

• How do probe interval and wakeup frequency affect duty cycle?

• When should a node send probes? When shouldn’t it?

• How would you adapt LPP to support multiple channels?

0.00

0.01

0.02

0.03

0.04

0 10 20 30

Probe Interval (s)

Base

line

Ra

dio

Du

ty C

ycle

[0

, 1

.0]

Wakeups per day

None

Weekly

Daily

12/day

1/hour

Networking 27

Networking Problem 3: Link state

collection and routing • What information do you need to figure out where to send

data?

• How does the idle radio behavior impact collecting this

data?

• What factors may lead to a mismatch between link quality

and route reliability?

• What impact does bad routing information have on the

network?

Networking 28

Impact of link quality assessment on the

bottom line

0.0

00

.04

0.0

8

Du

ty C

ycle

(0−

1)

Estimated DC: 1.67%

01

May 1

0

30 J

un

10

29

Aug

10

28 O

ct 1

0

26 D

ec 1

0

24

Feb

11

26 A

pr

11

Cub Hill Duty Cycle and Contacts

01

02

030

40

50

# o

f N

ode

s R

ea

ch

ed

Batteries Replaced Download Script Replaced

Hard-to-capture effects

present

Link quality freshness

matters

Figure 1

Networking 29

Impact of instability on route selection

10/28 10/31 11/03 11/06 11/09 11/12 11/15 11/18 11/21 11/24 11/27 11/300

0.2

0.4

0.6

0.8

1

Faile

d C

on

nectio

ns [0

1]

Period of Network : 10/28/2009 to 11/30/2009

Routes using "Healthy" motes Routes using "Rebooting" motes

Networking 30

How can we deal with poor link quality

assessment? • “Plan B is to make Plan A work”

• Moar data

• …?

What is the minimum amount of link quality information that

we can get by with?

Networking 31

Do we even need link quality information?

• How would you get data from a leaf to a router without

knowing local LQ or distances?

• What are the issues associated with this?

• Can we do better, perhaps by using some… trickery?

Networking 32

Networking approach: Non-destructive

Concurrent Transmissions • Recall the LPP example!

• This worked because hardware-generated acks are very

deterministic and interfere non-destructively.

Networking 33

0 1 0 1

Networking 34

How can we do the same with data

packets? • Careful timing

• We have access to a 26 MHz crystal

• We can use a timer capture module to record the time that the

packet preamble is sent or received

• Modify packet contents deterministically

• OK to increment hop-count, decrement TTL, compute checksums,

and apply forward error correction.

Networking 35

Solution 1: Try ALL paths at the same time

Related: Ferrari et al, 2012, 2011. Lu and Whitehouse, 2009

Networking 36

Solution 1: Try ALL paths at the same time

Related: Ferrari et al, 2012, 2011. Lu and Whitehouse, 2009

Networking 37

Solution 1: Try ALL paths at the same time

Related: Ferrari et al, 2012, 2011. Lu and Whitehouse, 2009

Networking 38

Solution 1: Try ALL paths at the same time

Related: Ferrari et al, 2012, 2011. Lu and Whitehouse, 2009

Networking 39

Solution 1: Try ALL paths at the same time

Related: Ferrari et al, 2012, 2011. Lu and Whitehouse, 2009

Networking 40

Solution 1: Try ALL paths at the same time

Related: Ferrari et al, 2012, 2011. Lu and Whitehouse, 2009

Networking 41

Can we do better than flooding?

• NO!

• jk yeah

Networking 42

Which of these nodes are actually useful?

B

E

A

F

D C

G

S

Networking 43

To me End-to-end

Solution 2: Identify Useful Forwarders

with CXFS

w is on some shortest path from S to D if

d(S,w) + d(w,D) = d(S,D)

SOURCE

DESTINATION

Burst Setup

S Floods

D measures d(S,D)

w measures d(S,w)

Setup

Acknowledgement

D Floods

D tells d(S,D) to w, S.

w measures d(D,w)

w assumes d(w,D)

Data Forwarding

S Floods

w forwards if

d(S,W) + d(w,D) <= d(S,D)

OTHERWISE

w sleeps.

To

Dest

Networking 44

Distance Metrics: "You go to war with the

army you have"

Augment with "boundary zone," optionally

smooth it.

Low-State (one number per node)

Mostly-Symmetric

Obeys triangle inequality (on a given flood)

Must Fit Multi-TX Context What does RSSI mean? How do you get local

information?

Why not use hop count?

Thursday’s paper has details and evaluation.

Networking 45

Close Source

Our Testbed

Red:

Forwards

more

frequently

Networking 46

Our Testbed

Red:

Forwards

more

frequently

Networking 47

Distant Source

Implementation Details

Each node gets a "slot” for their data.

Each slot is broken into “frames” where data may be sent.

Networking 48

What else is left?

• Somewhere for the data to go

• Recovery for lost packets

• Tools to configure nodes

• Tools for end users (setup, download, monitoring)

Networking 49

Questions/comments?

50