Download presentation
Presentation is loading. Please wait.
Published byChristal Crawford Modified over 9 years ago
1
A Remote Code Update Mechanism for Wireless Sensor Networks Thanos Stathopoulos, John Heidemann and Deborah Estrin CEG 790 Presentation By: Trevor Smith
2
Outline ● Introduction ● Problem Description ● Design Decisions ● Evaluation ● Conclusions ● Future Work Outline
3
What is Wireless Sensor Network ● Sensor networks integrate sensing, computing and communication ● Can be used for monitoring environmental changes, water contamination, seismic activity or structural building integrity ● Sensor resource constraints – Low Power – Limited Memory – Short range, low power radios Intro
4
Once Deployed What Happens? ● After deployment, motes might not be accessible again? ● Also, we can’t always predict full range of sensor actions or might not have a full set of environment knowledge. ● What is the solution? Reprogram! ● How do we handle post deployment reprogramming? ● How do we deal with the limited mote resources (battery, memory, etc.)? Intro
5
Solution ● Remote Code Distribution Mechanism ● Author proposes MOAP (Multihop Over-the-Air Programming) – Discuss different design alternatives: Data Dissemination protocols, retransmission policies and storage management – Design Goals? Focus on energy consumption, memory usage and latency ● Compare with flooding Intro
6
Outline ● Introduction ● Problem Description ● Design Decisions ● Evaluation ● Conclusions ● Future Work Outline
7
Code Distribution Properties ● 100% of image must reach all nodes – Reliability mechanism required ● If image cannot fit into single packet, it must be kept in stable storage until the transfer is complete ● Network lifetime should not be severely affected ● Memory and storage requirements should not severely affect the space required by the normal operations of the device Prob Desc.
8
Resource Prioritization ● Energy is most important resource – Radio transmission is expensive ● Transmit 3x cost of Recieve – Stable storage access ● Write is 1/8 the cost of transmitting the same number of bytes ● EEPROM is optimized for read operations and read is an order of magnitude cheaper than write Prob Desc.
9
Resource Prioritization ● Memory Utilization is a close second – Static RAM in specific ● Only about 4K on current gen. Motes – Must keep in mind reprogramming isn’t the motes only operation ● Main Goal: Limit energy consumption – Optimizations aren’t free – Trade latency for battery optimization – Is latency that important in reprogramming? Prob Desc.
10
Outline ● Introduction ● Problem Description ● Design Decisions ● Evaluation ● Conclusions ● Future Work Outline
11
Dissemination Protocol ● How is the data propagated ● All nodes must be reached ● Concurrently – Flooding ● Minimal state requirements ● Low energy prioritization ● Step by Step – Ripple (neighborhood-by-neighborhood) ● Slow Design Decisions
12
Assumptions
13
Definitions
14
Flooding Dissemination Protocol ● Flooding does a receive and forward type of mechanism – Once packet is received the node retransmits it ● Expected # of transmissions for the network is: ● The average time for node i at distance h i from the source is: Design Decisions
15
Flooding Dissemination Protocol Design Decisions 1 1 2 2 2 3 3 2 3 4 5 4 5 4 5
16
Ripple Dissemination Protocol ● Transfer data Neighborhood-by-Neighborhood – Neighborhood is all nodes in the broadcast domain – Single hop – Multihop handled recursively ● Receiver will attempt to become a source after entire image is received – Use PUBLISH-SUBSCRIBE mechanism ● Since a source is in the same network – Require all repairs to be local (one hop away) Design Decisions
17
Ripple Dissemination Protocol Design Decisions
18
Ripple Dissemination Protocol ● Expected # of transmissions for the network is: ● k i can be no more than (o i / 2) + 1 ● The average time for node i at distance h i from the source is: Design Decisions
19
Reliability Mechanism ● Requires 100% of image delivery ● Who is responsible for detecting loss – Sender (ACK) – Receiver (NACK) ● NACK based approach cuts down on control traffic ● Require repairs local – Neighbors will have entire image in due time – Reduce complexity by not routing NACKs ● What is our Retransmission Policy? – Broadcast or Unicast Design Decisions
20
Retransmission Policy ● Broadcast RREQ, no suppression – Simple – High Probability of Reception – Highly Inefficient – Zero Latency ● Broadcast RREQ, suppression based on randomized timers – Efficient – Complex – Reply if timer interval expires and no one else has replied Design Alts
21
Retransmission Policy (cont’d) ● Broadcast RREQ, fixed reply probability – Simple – Good Probability of Reception – Latency depends on probability of reply – Avg efficiency ● Broadcast RREQ, adaptive reply probability – More complex than static case – Latency and reception similar Design Alts
22
Retransmission Policy (cont’d) ● Unicast RREQ, single reply – Has the smallest prob. of successful reception – Highest Efficiency – Simple, as long as source doesn’t fail – Zero latency, if source doesn’t fail Design Alts
23
Segment Management ● No Indexing – Read EEPROM to find if segment is missing ● Full Indexing – Bitmap in RAM, if entry i in RAM is empty, segment i is missing Design Alts RAM EEPROM
24
Segment Management (cont’d) ● Partial Indexing – Bitmap kept in RAM – i/k and check if entry in RAM is empty or full – If empty, need to do k consecutive reads to find missing segment Design Alts RAM EEPROM
25
Segment Management (cont’d) ● Hierarchical Full Indexing – First level map kept in RAM, points to a page in EEPROM – Consider EEPROM data to be same as physical page size – i div m finds page, i mod m in particular page finds segment Design Alts RAM
26
Segment Management (cont’d) ● Sliding Window – Bitmap of up to w segments kept in RAM – Limited out of order tolerance – Last segment received starting point of window Design Alts BaseOffset
27
Segment Management Comparison Design Alts
28
Outline ● Introduction ● Problem Description ● Design Decisions ● Evaluation ● Conclusions ● Future Work Outline
29
Emulation ● EmStar emulation environment ● 30 Mica1 Motes – Attached via serial cables ● Transmitted image consists of 100 segments – 1 segment per packet ● Methods using sliding window – Window size = 16bits Eval
30
Emulation ● Neighborhood size vs Power setting Design Alts
31
Energy Consumption ● Ripple w/ Sliding Window ● Flooding w/ Sliding Window ● Ripple w/ Full Indexing Eval
32
Energy Consumption ● Flooding hangs around 100 transmissions – Changes to power settings doesn’t affect it ● Ripple produces large power savings in terms of transmissions...WHY? ● Ripple w/ Full Indexing performs better for sparse networks – Dense networks savings isn’t sufficient to justify using Full Indexing Eval
33
Latency ● As we stated earlier – We will trade latency for power efficiency Eval
34
Latency ● Tx rate of 2 packets/sec ● A faster Tx rate will note saturate the channel for ripple – However it would increase the number of collisions in flooding, resulting in more retransmissions ● Again Ripple w/ Full Indexing performs better than Ripple w/ Sliding Window Eval
35
Retransmission Policies ● Using ripple w/ sliding window – Compare broadcast vs unicast ● Why is Unicast less than Broadcast Eval
36
Retransmission Policies ● Unicast performs better than Broadcast ● But what happens if the link fails in Unicast – Receiver must locate another source – Author proposes MAC to do link level retransmissions Eval
37
Mote Implementation ● 15 Mica2 Motes ● 100 segments, 1 segment per packet ● Mica2 Motes have a stronger radio than the Mica1 motes – This results in better link qualities, fewer retransmissions and more rapid change in neighborhood size ● No Full Indexing scheme in TinyOS Eval
38
Mote Implementation ● Retransmissions significantly smaller than emulation ● Power settings not as high either Eval
39
MOAP Implementation ● Ripple disseminations, Unicast retransmission and Sliding Window segment Management ● Code is split up via packetizer ● Nodes use link statistics mechanism – Don’t subscribe to sources that are lossy, intermittent or unreliable ● Once complete image is stored, send PUBLISH messages – If no SUBSCRIBERS commit code with bootloader to program memory Eval
40
MOAP Implementation (cont’d) ● Active sources – After predetermined time has passed and retransmissions have been handled – Commit the code ● Nodes detect lost segments with sliding window – Retransmission have higher priority than Data packets – Duplicate request suppressed ● Node keeps track of sources activity with a keep alive timer Eval
41
MOAP Implementation (cont’d) ● Node keeps track of sources activity with a keep alive timer – Solves NACK’s “Last Packet Problem” – If source dies the keep alive timer will broadcast a repair request ● Late joiner mechanism allows nodes that have just recovered from a failure to get the new version of code – This requires that nodes advertise their version periodically Eval
42
Outline ● Introduction ● Problem Description ● Design Decisions ● Evaluation ● Conclusions ● Future Work Outline
43
Conclusions ● As sensor networks grow remote programmability will become a more critical service ● MOAP is designed to be more energy and memory efficient – While trading latency ● Ripple dissemination achieves significant reductions in traffic – 60-90% better ● Sliding Window performs adequately compared to more complex solutions Conclusions
44
Outline ● Introduction ● Problem Description ● Design Decisions ● Evaluation ● Conclusions ● Future Work Outline
45
Future Work ● Sending differences between code versions – Only transmit the differences between the code – Need a bootloader to reconstruct the image in EEPROM before committing it – Results in an even larger amount of energy savings ● Support for selective node updates – Don’t require every node to commit the code after receiving it. – Intermediate nodes that are not interested just forward the image on. Future Work
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.