Wireless Sensor Networks for High Fidelity Sampling

Sukun KimQualifying Examination

Dec 1, 2005

High Fidelity Sampling Three classes of WSN applications

Monitoring environments Great duck island [11], Redwood forest [12] Focus on low-duty cycle and low power consumption

Monitoring objects – High Fidelity Sampling machine health monitoring [13], condition-based

monitoring, earthquake monitoring [14], structural health monitoring [15]

Focus on fidelity (quality) of sample Interactions with space and objects

Lighting control [16] Focus on control

Structural Health Monitoring

High Fidelity Data High Frequency Sampling

with Low Jitter Time Synchronized

Sampling Large-scale Multi-hop

Network Reliable Command

Dissemination Reliable Data Collection

FTSP [8]

Mint [9]

Drip [10]

Challenges

Reliable Data Collection- Problem Statement Every data from every node needs be

collected to PC over a multi-hop network without loss High throughput Small number of packet injections to network Overcome interference

Assumptions Powerful receiver, resource constrained sender Receiver (PC) can arbitrate flow

Low congestion Low loss rate

Hypothesis (Proposed Solution) High Fidelity Data – Low-cost low-power

MEMS accelerometer board with proper signal processing and calibration, produces data of meaningful fidelity

High Frequency Sampling with Low Jitter – WSN mote and TinyOS with guaranteed worst-case jitter, provide real time operation of meaningful level

Reliable Data Collection – Rate-based alternating-flow protocol with complex receiver and simple sender and pipelining, achieve reliable collection efficiently

Table of Contents Related Work

High Fidelity Data

High Frequency Sampling with Low Jitter

Reliable Data Collection

Future Work

Structural Health Monitoring System

Spencer, et al [5]

Lynch, et al [6]

Wisden [7]

High Fidelity Data 2.0μG/√Hz *

0.5mG/√Hz

?

High Frequency Sampling with Low Jitter

? 977Hz 160Hz

Time Synchronized Sampling ? <1μs no

Large-scale Multi-hop Network ? no yes

Reliable Command Dissemination ? yes N/A

Reliable Data Collection ?B/s ?B/s 250B/s

Preliminary customized systems: Kruger, et al [1],Qiang, et al [2], Engel, et al [3], Caicedo, et al [4]

TCP on Wireless Networks Blind link-level-retransmission (LLR) can

decrease throughput – DeSimone, et al [17]

Support for mobile host I-TCP, Balakrishnan, et al [18]

Support for wireless ad-hoc network – WTCP, ATP Rate-based transmission Selective ACK contains congestion information No sender timeout for retransmission – WTCP

Reliable Transfer on WSN Reliable diffusion

PSFQ, RMST, Garuda, Drip, Deluge Congestion Control

ESRT, CODA, Fusion, Ee, et al [19] Better best-effort convergence

RBC Reliable convergence

Wisden Sender sends data at static rate In a routing tree, mote sends NACK to get missing packet

from child for efficiency PC sends NACK to source mote for e2e reliability Incorrectly tuned rate and topology change make the

network collapse Compared to hardware, low bandwidth

Table of Contents Related Work

High Fidelity Data In IWSHM ‘05

High Frequency Sampling with Low Jitter

Reliable Data Collection

Future Work

Accelerometer Board

Signal processing: averaging in software Calibration for manufacturing variation and

temperature System noise floor: 30(μG/√Hz) Gives desired quality in static, dynamic test

Silicon Designs 1221LADXL 202E

Two accelerometers for two axis

Thermometer, 16bit ADC, Low-pass filter

Table of Contents Related Work

High Fidelity Data

High Frequency Sampling with Low Jitter In IWSHM ‘05

Reliable Data Collection

Future Work

Analysis of JitterSampling

Other jobs like EEPROM write

Non-preemptible portion Preemptible portion

Probability

Jitter

0 C W T1+CT2+C

P1/T1

P2/T2

1. Remove unnecessary blocking atomic section, interrupts Turn off unnecessary components

2. Verify maximum blocking section is small enough

Time

450 460 470 480 490 500 510 520 530 540 550-1

0

1

2

3

4

5

6

7

8

9

10Interval: 150ms

Sample

Jitt

er (

us)

Verification of Jitter (6.67KHz)

0μs

10μs

-1 0 1 2 3 4 5 6 7 8 9 100

100

200

300

400

500

600

700

800

900

1000Interval: 150ms

Jitter (us)

Sam

ple

0μs 10μs

Jitter is within 10µs (6.67%), 0.2% at 200Hz Tradeoff: turning off radio WSN mote and TinyOS are not inherently limited in

real time operation It is a matter of the hardness of real time requirement and

the tradeoff for the loss of functionality

Time Series Histogram

Table of Contents Related Work

High Fidelity Data

High Frequency Sampling with Low Jitter

Reliable Data Collection Straw

Future Work

Overview

Application

PC Mote

Application

Straw Straw

Multi-hop Routing

PC application arbitrates flow Determines who sends when Triggers one flow at a time

Adjust RTT, adjust transmission rate to avoid interference Cross-layer information

read(dest, *start, size)

Routing layer is assumed to deliver packets end-to-end

ProtocolPC Mote

Straw Straw

Selective NACK No need for flow control, rate-based transmission No congestion control Pipelining, no link level retransmission

Alternating flow, no concurrent bidirectional flow

Complex Simple1. Data Request2. Data Transfer

3. Request missing holes

4. Transfer missing holesSelective NACK

Rate = if (Depth < Interference Radius)then (UART Delay) + Depth * (Radio Delay)else (Interference Radius) * (Radio Delay)

Optimization

Read

Send

Transfer the checksum of the whole data to guarantee the integrity

Parallelize reading from the memory and sending to the network

MemoryNetwork

95.6%560B/s96.6%

576B/s

91.4%296B/s

91.8%304B/s

93.2%299B/s

* End-to-end Raw Reliability Effective Bandwidth (Byte/s)

10KB of data 500 packets

Mica2dot, 36 bytes/pkt Comparison to routing layer

630B/s for 1 hop Up to 91.4% efficiency

352B/s for 2 hops Up to 86.4% efficiency

Test Result

Channel Capacity Utilization Hardware capacity limit

UART: 57.6Kbps Radio: 19.2Kbps 1 hop: 14.4Kbps

Measured actual capacity usage UART: 27.8Kbps Radio: 9.74Kbps Routing: 5.46Kbps (1 hop) Reliable: 4.7Kbps (1 hop)

Mica2, 36bytes/pkt33%

Mica2, 36bytes/pkt

Packet Time (for 1bit)

8%

25%

5%

14%13%

0%

21%

5%9% UART Channel

Radio ChannelUART OverheadRadio OverheadGenericComm HeaderRouting OverheadRouting HeaderReliable OverheadReliable Header

43% header transfer & overhead

212.7μs

33%data transfer

24%overhead for transferring data

Effect of Packet Size on Bandwidth Doubled packet size: 36B 72B Payload: 20B 56B (2.8 times) Packets/sec: 29.4 20.9 (71%) Bandwidth doubled: 588B/s 1172B/s*

(1.99 times)

RAM usage jump from 3437B to 4733B for SHM application (Sentri) 36 packet buffers Basic services (Comm + TimeSync + Routing +

Bcast + Reliable) can go beyond 4KB of RAM

*Loss rate was 0.2%

RAM

GenericComm

QueuedSend

Routing Cmpnt1DripBcast

Cmpnt2

Cmpnt5

Cmpnt3Cmpnt4 Straw

Cmpnt6

Forward Forward

Forward

Forward

1. At least oneat each endComponent(12 out of 36)

2. Forwarding Queue(20 out of 36)

Sharing packet buffer?

Reliability of system versus Efficient use of resource

Why so much RAM (packet buffer)?

Sensornet Network Layer

Reliable Data Collection- Problem Statement Every data from every node needs be

collected to PC over a multi-hop network without loss High throughput Small number of packet injections to network Overcome interference

Assumptions Powerful receiver, resource constrained sender Receiver (PC) can arbitrate flow

Low congestion Low loss rateIF

Revisited

Destination

Source

5 hops, 26.28% link loss rate (78.23% E2E),300 packets, separated by 1 sec, on BVR

Testbed In SECON ‘04

Reliability

0

0.2

0.4

0.6

0.8

1

1.2

none 1 2 3 4 5 5+RFMaximum number of retransmission

Suc

cess

Rat

e

0 1 2

3 4 5

6 7 8

8 original messages

Transmission Stretch

0

0.5

1

1.5

2

2.5

3

3.5

4

none 1 2 3 4 5 5+RFMaximum number of retransmission

Num

ber

of P

acke

ts

0 1 23 4 56 7 8

8 original messages

OverheadEnd-to-end retransmission (Straw): 8.6% at 96.6%(1hop) success rate 13.6% at 91.8%(2hops) success rateErasure code: 12.5%, 25%, …

Table of Contents Related Work

High Fidelity Data

High Frequency Sampling with Low Jitter

Reliable Data Collection

Future Work

Link Level Retransmission + Pipelining Link level retransmission is effective when

loss rate is high

Pipelining is effective for long path

Combining two can intensify interference- higher correlated losses

Throughput = (e2e success rate) * (pkts/s at sender)

Congestion Control In case Straw is used together with

constant upstream traffic, congestion control will be needed

Congestion control from the receiver Include congestion information in NACK packet Sender adjusts rate using congestion

information

Using Sentri (structural health monitoring toolkit)Berkeley SF Bay

mid-spanquarter-span

59

Base Station

260ft

16ft27 1

1310 38 4

121114

L3L5 L1L4 L2

Deployment at Footbridge

V9 V7

V13 V4

V2

Berkeley SF Bay

0 1 2 3 4 5 6 7 8 9 10

-8

-6

-4

-2

0

2

4

6

8

Time (sec)

Acc

eler

atio

n (

mg)

Time plot, vertical sensors at L1-L5

V2

V4

V13V7

V9

Plots of calibrated data

0 2 4 6 8 10 12 14 16 18 20

10-2

100

102

104

Frequency (Hz)

abs(

FF

T(.

))Frequency plot, vertical sensors at L1-L5

V2

V4

V13

V7

V9

-0.99

0.19-0.73

1.000.74

Model Properties

First Vertical Modeof Vibration

Match with SAP bridge model

Timeline Mar 2006 for SenSys – Deployment on the

Golden Gate Bridge April 2006 – Study correlation between

(link level retransmission + pipelining) and interference

Jul 2006 – Implement link level retransmission + pipelining

Dec 2006 – Congestion control with rate adjustment

Questions and Discussions

Backup Slides

References[1] M. Kruger and C. U. Grosse. Structural health monitoring with wireless sensor

networks. Otto-Graf-Journal, 15:77–90, 2004.[2] P. Qiang, G. Xun, and Z. Chang-you. A wireless structural health monitoring system in

civil engineering. The Third International Conference on Earthquake Engineering (3ICEE), Nanjing, China, October 18-20, 2004.

[3] J. M. Engel, L. Zhao, Z. Fan, J. Chen, and C. Liu. Smart brick - a low cost, modular wireless sensor for civil structure monitoring. International Conference on Computing, Communications and Control Technologies (CCCT 2004), Austin, TX USA, August 14-17, 2004.

[4] J. M. Caicedo, J. Marulanda, P. Thomson, and S. J. Dyke. Monitoring of bridges to detect changes in structural health. the Proceedings of the 2001 American Control Conference, Arlington, Virginia, June 2527, 2001.

[5] B. S. Jr., M. Ruiz-Sandoval, and N. Kurata. Smart sensing technology: Opportunities and challenges. Journal of Structural Control and Health Monitoring, in press, 2004.

[6] J. P. Lynch. Overview of wireless sensors for real-time health monitoring of civil structures. Proceedings of the 4th International Workshop on Structural Control (4th IWSC), New York City, NY, USA, June 10-11, 2004.

[7] N. Xu, S. Rangwala, K. Chintalapudi, D. Ganesan, A. Broad, R. Govindan, and D. Estrin. A wireless sensor network for structural monitoring. the Proceedings of the ACM Conference on Embedded Networked Sensor Systems, November 2004.

References (continued)[8] A. DeSimone, M. C. Chuah, O. Yue, Throughput performance of transport-layer

protocols over wireless LANs. In Proceedings of IEEE Globecom 93, Houston, USA, 1993.

[9] A. Bakre, B. R. Badrinath, I-TCP: indirect TCP for mobile hosts, Proceedings of the 15th International Conference on Distributed Computing Systems (ICDCS'95).

[10] H. Balakrishnan, S. Seshan, and R. H. Katz, Improving reliable transport and handoff performance in cellular wireless networks. ACM Wireless Networks, December 1995.

Reliable Data Collection- Problem Statement Every data from every node needs be

collected to PC over a multi-hop network without loss in a way that gives high throughput with small number of packet injections

The collection must overcome interference with the flow in the same and the opposite direction

Reliable Data Collection- Problem Statement Every data from every node needs be

collected to PC over a multi-hop network without loss in a way that gives high throughput with small number of packet injections

The collection must overcome interference with the flow in the same and the opposite direction

Data ACK or NACK

Accelerometer Board Design

ADXL 202E Silicon Designs 1221L

Range -2G ~ 2G -0.1G ~ 0.1G

System noise floor 200(μG/√Hz) 30(μG/√Hz)

Price $10 $150

Two accelerometers for two axis

Thermometer 16bit ADC

Silicon DesignsADXL

Signal Processing As an analog signal processing low-pass

filter is used, which filters high frequency noise Low-pass filter with threshold frequency 25Hz

is used As a digital signal processing, averaging is

used If noise follows Gaussian distribution, by

averaging N numbers, noise decreases by a factor of sqrt(N)

Sensor Calibration

Temperature Calibration

Temperature

Acceleration

27.3

3.9

11.7

19.5

81.1

67.1

53.0

39.0

0

F C

mG

27.5

-27.5

Thanks to Crossbow

Power ConsumptionOperation Mode Consumption (mW)

Board Only 240.3

Idle 358.2

One LED On 383.4

Erasing Flash 672.3

Sampling 358.2

Transferring Data 388.8

3 of Tadiran 5930 (lithium-ion, 3.6V, 19Ah, $17, D size) are used

Power Consumption (cont) With optimal sleeping, 30 days

Board itself consumes significant amount of energy

Power source

Sensor

ADC

Mote

Switch

Power source

Sensor ADC

Mote

Switch

Verification of Jitter – Time Series (1KHz, 5KHz, 6.67KHz)

450 460 470 480 490 500 510 520 530 540 550-1

0

1

2

3

4

5

6

7

8

9

10Interval: 1000ms

Sample

Jitt

er (

us)

450 460 470 480 490 500 510 520 530 540 550-1

0

1

2

3

4

5

6

7

8

9

10Interval: 200ms

Sample

Jitt

er (

us)

450 460 470 480 490 500 510 520 530 540 550-1

0

1

2

3

4

5

6

7

8

9

10Interval: 150ms

Sample

Jitt

er (

us)

Peak to Peak is time to fill up buffer

Spiky portion is time to write buffer to flash

Can sample as long as the former is larger than the latter

0μs

10μs

Verification of Jitter – Histogram (1KHz, 5KHz, 6.67KHz)

-1 0 1 2 3 4 5 6 7 8 9 100

100

200

300

400

500

600

700

800

900

1000Interval: 1000ms

Jitter (us)

Sam

ple

-1 0 1 2 3 4 5 6 7 8 9 100

100

200

300

400

500

600

700

800

900

1000Interval: 200ms

Jitter (us)

Sam

ple

-1 0 1 2 3 4 5 6 7 8 9 100

100

200

300

400

500

600

700

800

900

1000Interval: 150ms

Jitter (us)

Sam

ple

Jitter is within 10µs Peak at 625ns – Wakeup

time from sleep mode

0μs 10μs

Real-time System Use separate MCU for sensor board, or two

motes

Sensor MCU

Buffer

MCU

Radio

Constraints and Options

Sources of Failure• Link Failure• Mote Failure• …

How to obtain reliability? (possible options)1. Add redundancy of information

1. Retransmission – link-level, end-to-end2. Data redundancy – duplication, erasure code3. Path redundancy – Use thick path

2. Increase success rate1. Alternative Route2. Congestion Control

(# of pkts received) = Psuccess × (# of pkts sent)

Problem Statement Goal

Reliable communication in multi-hop Wireless Sensor Networks

Assumption Wireless communication Resource-constrained mote

Erasure CodeEncoding Channel Decoding

M8 msgs

N

21 code words

N’≥8 code words

M

8 original msgs

Systematic Code

Benefit: if receiver has codes containing original messages• Encoding, Decoding are faster• Even if receiver get less than 8 packets, we don’t lose

every message

Systematic Code

Encoding one code word takes 1.7msDecoding time varies from 0 to 27msReal time processing is possible

In MICA2

Alternative Route Discovery

Find Alternative Route

What if

Get 6 best candidates for the next hop from routing table. And try from the best

And if

Effect of Erasure Code

0

0.2

0.4

0.6

0.8

1

1.2

0 0.2 0.4 0.6 0.8 1 1.2

Raw Loss Rate

Fin

al L

oss

Rat

e

12481664247

8 original messages

Effect of Systematic Code

0

0.2

0.4

0.6

0.8

1

1.2

0 0.2 0.4 0.6 0.8 1 1.2

Raw Loss Rate

Fin

al L

oss

Rat

e

12481664247

8 original messages

Encoding Speed

0

2

4

6

8

10

12

14

16

0 2 4 6 8 10

Number of Redundant Codes

Tim

e (

ms)

Decoding Speed

0

5

10

15

20

25

30

0 2 4 6 8 10

Number of Non-Original Message Code

Tim

e (

ms)

Decoding Time versus Loss Rate

0

5

10

15

20

25

30

0 0.2 0.4 0.6 0.8 1

Loss Rate

Tim

e (

ms)

Histogram of Decoding Time

0

0.1

0.2

0.3

0.4

0.5

0.6

11 12 13 14 15 16

Decoding Time (ms)

Fre

quen

cy

Design Space – Routing Layers

Point-to-point Convergence Divergence

Implementation on Beacon Vector RoutingHowever, solutions are applicable to all routing layers

Overhead versus Reliability (zoom)

0.9

0.91

0.92

0.93

0.94

0.95

0.96

0.97

0.98

0.99

1

1 2 3 4Overhead

Rel

iab

ility

123455+RF

8

7

6

87

4

3

2

1

1

23

0

4 51

0

8 original messages

Overhead versus Reliability

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

1 2 3 4Overhead

Rel

iabi

lity

0123455+RF

8

02

1 2 30 4 5

10

1

3

8

0

8 original messages

Given a threshold reliability requirement, what is the retransmission and redundancy combination that has the smallest overhead?

Decomposing causes of failures (5 ret, no RF)

Findings Link-level retransmission – efficiently

handle transient link failure Route fix – cure stale routing table

problem, increase usefulness of erasure code

Erasure code – relieve the burden of last a few packets, which is very expensive

Some options addresses some problems efficiently, but not all failures Combining options would provide a sweet spot

Run Length Encoding (RLE) 94720, 94704, 94715, 94708 becomes 947

+ 20, 04, 15, 08 Exception

94720, 94704, 92345, 94708 becomes 947 + 20, 04, \92345, 08

Run simulation on footbridge vibration data

Fragment Size: 4

Threshold: 2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

5

40

3200

20

40

60

80

100

120

140

160

Threshold

Fragment Size

Compression Ratio

High ResolutionFootbridge data

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

5

40

3200

20

40

60

80

100

120

140

Threshold

Fragment Size

Compression Ratio

Low ResolutionFootbridge data

AnalysisHigh Resolution Low Resolution

RLE 66% 45%

gzip * 68% 49%

Theory 56.25%(9 dynamic bits)

37.5%(6 dynamic bits)

Algorithm of RLE fits better to sensor data Basic algorithm of gzip utilizes repetition of same pattern

Compression ratio is sensitive to parameters (even go above 100%) Selecting RLE parameter (either statically or dynamically)

is critical

* Windows zip showed 0.64% increase

Analysis (continued) There exists room for lossless or lossy

compression

Compression ratio is sensitive to parameters (even go above 100%)

Selecting RLE parameter (either statically or dynamically) is critical

33789679201Similar

CompressRandom garbage Drop

State Diagram of Sender

More

Start

Request / Set Timer

Yes / Read

Timer Fired /Send

No / Stop Timer

Simple (intelligence in receiver) Interface is simple

read(start, size, *buffer)

Send everything once, and fill holes

Read depth in routing tree, and adjust transmission rate, packet interval, RTT estimate

State Diagram of ReceiverStart

More

Send Network-Info Request

Receive / Send Transfer Request, Set Timer

Receive & Last || Timeout / count = 0

Timeout / FAIL

Receive & not Last / Set Timer

Yes / Send ReadRequest, Set Timer

Receive / count = 0

More in Round

count < threshold

Yes

No

Yes /++count

No /FAIL

No / SUCCESS

Timeout

Mica2, 36bytes/pkt

Routing

75%

80%

85%

90%

95%

100%

28 29 30 31Interval (ms)

Su

cce

ss R

ate

Channel Capacity Utilization Hardware capacity limit

UART: 57.6Kbps = 200pkts/s Radio: 19.2Kbps = 66.7pkts/s 1 hop: 14.4Kbps = 50pkts/s

Measured actual capacity usage UART: 27.8Kbps = 120pkts/s Radio: 9.74Kbps = 42pkts/s Routing: 5.46Kbps = 31pkts/s (1 hop) Reliable: 4.7Kbps = 29.4pkts/s (1 hop)

Mica2, 36bytes/pkt

Mica2, 36bytes/pkt

Packets per second (Out of 50pkts/s)

14%

24%

0%

3%

59%

UARTRadioRoutingReliableCapacity

Mica2, 36bytes/pkt

Effect of header is considered here

Bandwidth (Out of 14400bps)

31%

19%12%

5%

33%UARTRadioRoutingReliableCapacity

For Mica2, packet size = 36 bytes

Top, Left: Packet SizeBottom, Right: pkts/sec

0 10 20 30 40

CapacityReliableRoutingGenericComm

0 20 40 60

CapacityReliableRoutingRadioUART

RAM space From 3437 to 4733 (SHM application – Sentri)

36Bytes RAM increase per 1Byte increase in packet size Reason – Packet buffer space

4 below GenericComm 3 in TimeSync 16 in Routing 4 in Bcast 2 + 5 in Reliable 2 in application

Basic services (Comm + TimeSync + Routing + Bcast + Reliable) can go beyond 4KB RAM with packet size = 72Bytes

Findings Reliable Data Collection (Straw)

5.2% decrease in packet throughput 13.8% decrease in bandwidth

Packet is small compared to the size of header, so doubling packet size doubles bandwidth RAM limit due to many packet buffers –

Reliability of system versus Efficient use of resource

Loss Rate at FootbridgeLoss Rate versus Distance

0.00%

1.00%

2.00%

3.00%

4.00%

5.00%

6.00%

0 10 20 30 40 50 60 70 80 90Distance (ft)

Loss

Rat

e

Loss Rate

Mica2, 36bytes/pkt

Loss Rate at Golden Gate Bridge

Loss Rate vs Distance

0

0.2

0.4

0.6

0.8

1

1.2

0 50 100 150 200Distance (ft)

Loss

Ra

te

0.5ft3ft

Mica2, 36bytes/pkt

V9 V7

V13 V4

V2

Berkeley SF Bay

0 50 100 150 200 250-15

-10

-5

0

5

10

15

Time (sec)

Acc

eler

atio

n (

mg)

Time plot, vertical sensors at L1-L5

V2

V4

V13V7

V9

0 1 2 3 4 5 6 7 8 9 10

-8

-6

-4

-2

0

2

4

6

8

Time (sec)

Acc

eler

atio

n (

mg)

Time plot, vertical sensors at L1-L5

V2

V4

V13V7

V9

50 51 52 53 54 55 56 57 58 59 60-15

-10

-5

0

5

10

15

Time (sec)

Acc

eler

atio

n (

mg)

Time plot, vertical sensors at L1-L5

V2

V4

V13V7

V9

Time-plots of calibrated data

0 2 4 6 8 10 12 14 16 18 200

1

2

3

4

5

6

7

8

x 104

Frequency (Hz)

abs(

FF

T(.

))

Frequency plot, vertical sensors at L1-L5

V2

V4

V13V7

V9

0 2 4 6 8 10 12 14 16 18 20

10-2

100

102

104

Frequency (Hz)

abs(

FF

T(.

))Frequency plot, vertical sensors at L1-L5

V2

V4

V13

V7

V9

Frequency-plots of calibrated data

0.940.330.681.00

0.41

Frequency: 1.78 HzDamping Ratio: 1%

Second Vertical Mode of Vibration

Custody Transfer Efficient for unreliable media Benefit from small packet header Pipelining gets complicated How to do custody transfer without

interfering pipelining?

Low-power Reliable Transfer Lessons from NEST FE

Duty cycle affects retransmission timeout – timeout should consider duty cycle

Aggressive transfer depletes battery – mote stop responding, causes transfer failure

Power information from lower layer are very useful for proper and efficient operation Power stack – duty cycle info, warning for low

energy budget