1

Reprogramming/Re-tasking in Wireless Sensor Networks

Part of slides are from Jonathon Hui, David A. Olsen and Jaein Jeong

Reprogramming/Re-tasking in Wireless Sensor Networks

Part of slides are from Jonathon Hui, David A. Olsen and Jaein Jeong

2

OverviewOverview

Background and motivations for Deluge

Deluge Design

Evaluation

Limitation of Deluge

Conclusion and sources

3

Worst Case Scenario Worst Case Scenario

10,000 nodes are deployed in the mushy field with 10 meters apart

Start the network. NO data is coming !!!! ;(

A graduate student finds out that a small bug in the code that only shows up when a network scales up?

The demonstration shall start in two hours.

Option one: A quick calculation reveals that it taks 2.7 hours to

just collect motes with 10 students.Plan B???

Avon Park, FL, Deployment Site

4

Network Tasking is EssentialNetwork Tasking is Essential

Why network tasking is needed?

Application requirement would change

A necessity in debugging and testing cycle

Code would be upgraded to a better & newer version.

Retasking over wireless is crucial

Embedded nature of sensor networks

Network scales reaching thousands of nodes

Inaccessibility of hostile environments

5

Discussion: Techniques for RetaskingDiscussion: Techniques for Retasking

6

Techniques for ReTasking (1)Techniques for ReTasking (1)

1. Parameter reconfiguration

2. Wired Reprogramming: Uisp

3. Single-hop Network Reprogramming : XNP

4. Multi-hop network Reprogramming : Deluge, MOAP

5. Incremental network programming: Reijers / Kapur

6. Virtual machine programming: Maté / Trickle

7

Techniques for Reprogramming (2)Techniques for Reprogramming (2)

In System Programming

Most Common.

Programming time is in proportion to # nodes.

Network Programming

Sending whole code over radio still takes time.

Either single hop or multiples hopes

HostMachine

ProgramCode

Sensor nodeSerial orparallel

port

In system programming

Network programming

HostMachine

ProgramCode

RadioChannel

Sensor nodes

…

8

Techniques for Reprogramming (3)Techniques for Reprogramming (3)

IEEE SECON 2004 “Incremental Network Programming for Wireless Sensors”

Program source code is changed in small amounts.

Reduce programming time by sending the difference.

Incremental Network programming

HostMachine

Program CodeVersion 1

Radio Channel

Sensor nodes

…

Program CodeVersion 2+

Difference

9

Techniques for Reprogramming (4)Techniques for Reprogramming (4)

Stack based architecture

Single shared variable

gets/sets

Three events:

Clock timer

Message reception

Message send

Hides asynchrony

Simplifies programming

Less prone to bugs

0 1 2 3

SubroutinesC

lock

Sen

d

Receiv

e

Events

gets/sets

0 1 2 3

SubroutinesC

lock

Sen

d

Receiv

e

Events

gets/sets

Co

de

OperandStack

ReturnStack

PC

Co

de

OperandStack

ReturnStack

PC

10

Comparison Comparison

Cost Flexibility Energy Speed

Reconfiguraton

Single Hop

Multi-Hop

Incremental

VM

The need for a high flexible and generic solution

11

Comparison Comparison

Cost Flexibility Energy Speed

Reconfiguraton Low Low Low Fast

Single Hop High High- High- Median

Multi-Hop High High+ High+ Slow

Incremental High Median + Low Fast

VM Median Median - Median Median

The need for a high flexible and generic solution

12

What is Deluge?What is Deluge?

A reliable data dissemination protocol for large data objects over a multi-hop network.

Combined with a bootloader (TOSBoot)

Network Programming

“Your nodes can communicate wirelessly, so why don't you? “ ---- Jonathan Hui

13

Design Issues for the Deluge Protocol

Discussion

Design Issues for the Deluge Protocol

Discussion

14

Deluge OverviewDeluge Overview

Maintain

Request

Transmit

Epidemic

State-machine strictly local rules

Nodes advertise, request data, and broadcast

Considers many subtle issues

Density-awareness

Robust to asymmetric links

Dynamic adjustment of advertisements

Minimize set of concurrent data broadcasts

Spatial multiplexing

15

How Does Deluge Work?(Glossing over many details)

How Does Deluge Work?(Glossing over many details)

Nodes periodically advertise

Version 2 here.

I only have version 1.

I only have version 1.

16

How Does Deluge Work?(Glossing over many details)

How Does Deluge Work?(Glossing over many details)

Neighboring nodes request data

Send me page 1!

Send me page 1!

suppressed

17

How Does Deluge Work?(Glossing over many details)

How Does Deluge Work?(Glossing over many details)

Requested data is sent

Packet 12of page 1!

unicast

overhear

18

How Does Deluge Work?(Glossing over many details)

How Does Deluge Work?(Glossing over many details)

Dropped packets are NACKed

Repeat packet 4 of page 1!

Repeat packet 32 of page 1!

19

How Does Deluge Work?(Glossing over many details)

How Does Deluge Work?(Glossing over many details)

Dropped packets are sent again

Packet 4 of page 1!

20

How Does Deluge Work?(Glossing over many details)

How Does Deluge Work?(Glossing over many details)

Advertise for propagation to next hop

Version 2 here.

I only have version 1.

21

Each version has a unique version number

Program image divided into contiguous pages, each consisting of N packets.

Page structure advantages

Reduced RAM requirements for maintaining state of which packets are needed

Allows for spatial multiplexing

Data RepresentationData Representation

Program Image

Packets

1234 N

22

Data RepresentationsData Representations

1. Serialized version numbers: V

2. Aging Schedules: a=<a0,a1,…,ap-1>

Calculating the version when a page last changed: (V-ai)

A nibble (4 bits) is used to store the age of each page.

3. Object profiles: (V, a)

Example: (V, a) = (23, <1,2,3,0,1,0,5,1>)

First page version is 22 = 23-1 Fourth page

version is 23

Six page version is 18

8 Pages program

Version 23

23

An ExampleAn Example

1. Node A: (23, <1,2,3,0,1,0,5,1>)

2. Node B: (23, <1,2,3,0,1,0,0,1>)

3. Node C: (23, <1,2,3,0,1,2,5,1>)

4. Node D: (22, <0,1,2,4,0,1,4,0>)

5. Node E: (20, <3,7,0,2,1,3,2,3>)

6. Node F: ( 6, <3,5,4,2,1,0,2,0>)

7. Node G: (23, <1,2,3,0,1,0,0,0>)

Question: Which node has the latest version?

24

An ExampleAn Example

1. Node A: (23, <1,2,3,0,1,0,5,1>)

2. Node B: (23, <1,2,3,0,1,0,0,1>)

3. Node C: (23, <1,2,3,0,1,2,5,1>)

4. Node D: (22, <0,1,2,4,0,1,4,0>)

5. Node E: (20, <3,7,0,2,1,3,2,3>)

6. Node F: ( 6, <3,5,4,2,1,0,2,0>)

7. Node G: (23, <1,2,3,0,1,0,0,0>)

25

Something About TrickleSomething About Trickle

1. Trickle is a self-regulating, epidemic maintenance, polite gossip protocol.

2. The algorithm controls the send rate so that each node hears only a small trickle of packets, just enough to stay up to date.

3. Nodes periodically broadcast a code summary to neighbors but stay quiet if they have recently heard a summary identical to theirs.

4. When a node hears a summary older than its own, it broadcasts an update.

26

MaintainMaintain Request

Transmit

Maintain Advertise

Contains version and fraction of image complete• Nodes request pages in sequential order

Use Trickle • Duplicate suppression

• Dynamically adjust advertisement rate

Transition to:

Transmit on receiving a request

Request on receiving an advertisement with newer data (i.e. from a node with a larger fraction of the complete image)• Unless a request or data packet was recently overheard

27

RequestRequest

Maintain

Transmit

Request

Transmit a request

Using a random backoff

Suppress if any similar requests are overheard during backoff period

Not receiving a data packet for some time

Minimize senders by unicasting requests to the node that advertised

Transition to Maintain

After receiving all packets of a page

After k requests to protect against asymmetric links

28

TransmitTransmit

Transmit all requested packets

May receive requests when transmitting

Round Robin schedule to provide fairness

Transition to Maintain when all requested packets are transmitted

Maintain

Request

Transmit

29

Other DetailsOther Details

Page level CRCs

Redundant data integrity checks at packet and page level

Multiple image support

Not limited to the dissemination of a single object

Allows multiple programs to exist in the network• Great for debugging!

O

1

Exte

rnal Fl

ash

30

MethodologyMethodology

Simulation (TOSSIM)

Up to 400 nodes

Empirically derived loss rates

Very pessimistic in interference model

Highly sensitive to simulation parameters, but helps in guiding development

Real world deployment in office building (mica2dots)

Up to 77 nodes

Limited in scale

Not able to see effects shown in simulation

31

Simulation AnalysisSimulation Analysis

Pipelining improves performance

Linear with size

Time increases with density

Tim

e T

o

com

ple

tio

n

Network Size Object Size

Node Density

32

Hidden Terminal ProblemHidden Terminal Problem

33

Hidden Terminal ProblemHidden Terminal Problem

Node(2,2)

Node(5,5)

Edge

Center

34

Slow Down PropagationSlow Down Propagation

Slowing down traffic reduces contention

But also slows down overall!Original

Quarter Request Rate

Half Request Rate

Slowing down traffic reduces contention

But also slows down overall!

35

Discussion: Issues with DelugeDiscussion: Issues with Deluge

36

Weaknesses in the Deluge DesignWeaknesses in the Deluge Design

High Cost

No selective dissemination

The entire network must remain powered on to get the full benefit of spatial multiplexing.

It takes a long time to converge into a network-wide stable state. Especially when a node has weak connectivity

Advertise messages are needed even all nodes have latest version

Slower propagation in central areas of a network because of hidden terminal collisions. CSMA cannot prevent all of these.

37

ConclusionConclusion

Deluge = polite gossip with ear dropping

Deluge is very flexible but has a very high cost (compared with reconfiguration etc)

Deluge involves many design choice trade-offs, e.g. CRC v. FEC, nibble sized age cells, suppression values and rules and the use of CSMA

Breaking objects into pages has benefits such as spatial multiplexing.

38

Sources and WebsitesSources and Websites

A. Chlipala et al., “Deluge: Data Dissemination for Network Programming at Scale”

J. Hui et al., “Data Dissemination with Geometric Structure”

J. Hui et al., “The Dynamic Behavior of a Data Dissemination Protocol for Network Programming at Scale”

P. Levis, et al., “Trickle: A Self-Regulating Algorithm for Code Propagation and Maintenance in Wireless Sensor Networks”

www.cs.berkeley.edu/~jwhui/research/deluge

39

Q&A and DiscussionQ&A and Discussion