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