A Remote Code Update Mechanism for Wireless Sensor Networks Thanos Stathopoulos, John Heidemann and Deborah Estrin CEG 790 Presentation By: Trevor Smith

Outline ● Introduction ● Problem Description ● Design Decisions ● Evaluation ● Conclusions ● Future Work Outline

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

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

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

Outline ● Introduction ● Problem Description ● Design Decisions ● Evaluation ● Conclusions ● Future Work Outline

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.

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.

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.

Outline ● Introduction ● Problem Description ● Design Decisions ● Evaluation ● Conclusions ● Future Work Outline

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

Assumptions

Definitions

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

Flooding Dissemination Protocol Design Decisions

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

Ripple Dissemination Protocol Design Decisions

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

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

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

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

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

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

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

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

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

Segment Management Comparison Design Alts

Outline ● Introduction ● Problem Description ● Design Decisions ● Evaluation ● Conclusions ● Future Work Outline

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

Emulation ● Neighborhood size vs Power setting Design Alts

Energy Consumption ● Ripple w/ Sliding Window ● Flooding w/ Sliding Window ● Ripple w/ Full Indexing Eval

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

Latency ● As we stated earlier – We will trade latency for power efficiency Eval

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

Retransmission Policies ● Using ripple w/ sliding window – Compare broadcast vs unicast ● Why is Unicast less than Broadcast Eval

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

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

Mote Implementation ● Retransmissions significantly smaller than emulation ● Power settings not as high either Eval

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

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

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

Outline ● Introduction ● Problem Description ● Design Decisions ● Evaluation ● Conclusions ● Future Work Outline

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

Outline ● Introduction ● Problem Description ● Design Decisions ● Evaluation ● Conclusions ● Future Work Outline

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