1 reprogramming/re-tasking in wireless sensor networks part of slides are from jonathon hui, david...
Post on 18-Jan-2016
212 Views
Preview:
TRANSCRIPT
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
top related