1. CRI Group Shu Chen| Dr. Yan Huang| The University of North Texas

2. OVERVIEW XNP MOAP Deluge

3. INTRODUCTION –PROGRAMMING WIRELESS SENSORS In-System Programming (ISP) – A sensor node is plugged to the serial / parallel port. – But, it can program only one sensor node at a time. Network Programming – Delivers the program code to multiple nodes over the air with a single transmission. – Saves the efforts of programming each individual node.

4. INTRODUCTION –PROGRAMMING WIRELESS SENSORS Some basic concepts: In UC Berkeley sensor platform, the souce code is written in nesC programming language. The source code is compiled to the binary code (main.exe) after several intermediate steps. This file is further converted to Motorola SREC format (main.srec) which is an ASCII representation of binary code to make the postprocessing easier. UISP is used as a host programming tool. UISP starts ISP by setting RESET to 0, which makes Atmega128 microcontroller in MICA2 or MICA2DOT sensor node go to the programming mode. Then, UISP reads each record of the SREC file and sends it to the microcontroller.

5. INTRODUCTION – NETWORK PROGRAMMING FOR TINYOS Network programming for TinyOS (XNP) – Has been available since release 1.1 – Originally made by Crossbow and modified by UCB. – Provides basic network programming capability. – Has some limitations. No support of multi-hop delivery. No support of incremental update. Goal: – Fast code delivery by incremental update – Multi-hop delivery (Deluge (UCB), MOAP(UCLA))

6. BACKGROUND – MECHANISMS OF XNP (1)Host: sends program code as download msgs. (2)Sensor node: stores the msgs in the external flash. (3)Sensor node: calls the boot loader. The boot loader copies the program code to the program memory. User app SREC file External Flash Network Programming Host Program Boot loader User Application Section Program Memory Boot loader Section Network Programming Module Radio Packets Host MachineSensor Node (2) (3) (1)

7. FIRST APPROACH – FIXED BLOCK COMPARISON (DIFFERENCE GENERATION) The host program – Generates the difference of the two program versions. – Compares the corresponding blocks of the two program images. – Sends “copy” for the matching blocks, “download” for the unmatched ones.

8. FIRST APPROACH – FIXED BLOCK COMPARISON (STORAGE ORGANIZATION AND CODE REBUILD) The sensor node – Keeps new and previous sections in the external flash. – For “copy”, copies the records from the prev section to new section. – For “download”, stores the code bytes in the new section.

9. EXPERIMENT SETUP Test Applications – Wrote simple network programmable applications, XnpBlink and XnpCount. – XnpBlink and XnpCount are modifications of TinyOS applications Blink and CntToLedsAndRfm for network programming. Test Scenarios – Case 1: Changing a constant ( XnpBlink ) – Case 2: Modifying implementation file ( XnpCount ) – Case 3: Major change ( XnpBlink  XnpCount ) – Case 4 and 5: Modifying configuration file ( XnpCount )

10. EXPERIMENT SETUP – TEST SCENARIOS Case 1: Changing a constant ( XnpBlink ) Case 2: Modifying implementation file ( XnpCount )

11. EXPERIMENT SETUP – TEST SCENARIOS Case 3: Major change ( XnpBlink  XnpCount ) Case 4: Modifying configuration file ( XnpCount )  Commented out IntToLeds component. Case 5: Modifying configuration file ( XnpCount )  Commented out IntToRfm component.

12. CODE COMPARISON Compared the two program images in different block sizes. – The level of sharing in bytes is much higher than that in blocks. – However, using smaller block size means more copy messages – increasing xmit time. Block Size Case 1Case 2Case 3 Flash page 256 Bytes 97.2 % ( = )21.9 % ( = )2.7 % ( = ) SREC record 16 Bytes 98.3 % ( = )40.8 % ( = )12.0 % ( = ) byte 1 Byte 100.0 % ( = )98.3 % ( = )90.5 % ( = )

13. RESULTS – FIXED BLOCK COMPARISON The transmission time (T) with the non-incremental delivery time (T xnp ). There is almost no speed up except when modifying the co nstant in the source code (case 1). 0.00 1.00 2.00 3.00 4.00 5.00 6.00 7.00 Case 1Case 2Case 3Case 4Case5 Speed up Estimated Speed Up (Fixed) Measured Speed Up (Fixed)

14. RESULTS – FIXED BLOCK COMPARISON In most cases (other than case 1), much of program code is sent as download messages rather than copy and this contributes the not-so- good performance.

15. OPTIMIZING DIFFERENCE GENERATION USING RSYNC ALGORITHM Needs an algorithm that can capture the shared data even when the program is shifted. Use Rsync algorithm to compare the two program images at an arbitrary byte position. Rsync was originally made to transfer the incremental update of arbitrary binary file over a low bandwidth Internet connection.

16. DIFFERENCE GENERATION USING RSYNC ALGORITHM (DIFF GENERATION) (1)Build the hash table for the previous image. Calculate the checksum pair (checksum, hash) for each block. The checksum is for the fast match. The hash is for more accurate match.

17. DIFFERENCE GENERATION USING RSYNC ALGORITHM (DIFF GENERATION) (2) Scan the current image and find the matching block. Calculate the checksum for the block at each byte. Calculate the hash only if the checksum matches. Moves to the next byte and recalculates the checksum if the block doesn’t match.

18. DIFFERENCE GENERATION USING RSYNC (REBUILDING THE CODE IMAGE) Storage Organization – Two sections (current & previous) in the external flash memory. Building the program image using the difference – Download: data bytes are written to the current program section. – Copy: lines of the prev section are copied to the current section. – Copy blocks are set as multiple of SREC lines to avoid additional flash memory read/write due to partial SREC lines.

19. RESULTS – USING RSYNC The performance got better than Fixed Block Comparison. Speed up of 2 to 2.5 for a small change. – 2.5 for adding a few lines in implementation file (case 2). – 2.0 for commenting out IntToLeds in the configuration file (case 4). Still limited speed up for big changes. – Major change (case 3). Commenting out IntToRfm (case 5). 0.00 1.00 2.00 3.00 4.00 5.00 6.00 7.00 Case 1Case 2Case 3Case 4Case5 Speed up Estimated Speed Up (Fixed) Measured Speed Up (Fixed) Estimated Speed Up (Rsync) Measured Speed Up (Rsync)

20. PROBLEMS – USING RSYNC Sends a number of copy messages even though the two program images are very close. – The maximum block size of a copy message is limited. – This is to bound the running time of a copy message. Inefficient handling of missing packets.  The script commands are not stored.  Checks the rebuilt program image for verification.  In case a copy message is lost, it requests the retransmission of each missing record rather than the copy message itself.

21. OPTIMIZING DIFFERENCE DELIVERY (1) The network programming module stores the difference script first.

22. OPTIMIZING DIFFERENCE DELIVERY (2) And then, it starts building the program image only after the host program sends decode message.

23. RESULTS – USING RSYNC WITH DECODE The performance of using Rsync algorithm with decode command is similar to just using Rsync. But, the performance for changing a constant has improved (speed up of 9.0). 0.00 1.00 2.00 3.00 4.00 5.00 6.00 7.00 8.00 9.00 10.00 Case 1Case 2Case 3Case 4Case5 Speedup Fixed Block Comparison Rsync Rsync + decode

24. FUTURE WORK Combine Incremental Program Update with multihop delivery. – Deluge or MOAP Study on nesC compiler support to further increase the level of sharing.

25. MOAP- MULTHOP OVER THE AIR PROGRAMMING What MOAP is MOAP (Multhop Over the Air Programming) is a set of components and tools whose purpose is to allow motes to be reprogrammed 'over the air'. This means that the radio, instead of the parallel, or serial port, is used as a means to transfer the code. In addition, MOAP works for multiple hops (hence MOAP).

26. RELATED WORK- CODE DISTRIBUTION IN SENSOR NETWORKS TinyOS has included In-Network Programming support for the Mica-2 motes since its 1.0 release. The mechanism is single-hop only: the basestation (source) transmits code capsules to all nodes within a broadcast domain. After the entire image has been transmitted, the basestation polls each node for missing capsules. Nodes scan the contents of EEPROM to find gaps and then reply with NACKs if necessary.The basestation unicasts missing capsules as required.

27. RELATED WORK- CODE DISTRIBUTION IN SENSOR NETWORKS Difference-based mechanism--only the differences between the new and old code are sent LOBcast--a node first requests content (and repairs) from its immediate neighborhood but moves toward the source Bombilla--a stack-based Virtual Machine consist of capsules, special instructions that can forward capsules, Nodes will install a capsule that has a newer version number than the one currently used.

28. RELATED WORK- RELIABILITY IN SENSOR NETWORKS PSFQ--uses broadcast repair requests and suppression mechanisms to reduce the number of duplicates. RMST--missing fragments requests are unicast from the sink to the source and Caches in intermediate nodes allow for fast recovery. ESRT—a congestion control protocol that tries to meet reliability requirements set by the application, while conserving energy.

29. RESOURCE PRIORITIZATION OF MOAP Energy Memory usage Latency

30. DISSEMINATION PROTOCOL OF MOAP Ripple IDEA: transfer the data in a neighborhood-by-neighborhood, when the receivers have the entire image they can become sources for their own neighborhoods. Sources publish their newer version of the code image and all interested nodes subscribe. If a source has no subscribers it will be silent. Advantage: guarantees the source is only one hop away when transmission Disadvantage: slower

31. RELIABILITY MECHANISM OF MOAP NACK-based approach and Unicast retransmission policy IDEA: assume that given enough time, the missing packet will be only one hop away. Advantage: significant reduction in control traffic Disadvantage: time cost

32. SEGMENT MANAGEMENT OF MOAP Sliding Window At any point, the receiver knows it has successfully received packets up to the beginning of the window(base). It can then receive and successfully store and retrieve up to the size of the window(offset).

33. PROCESS First, the programmer builds the new code, using the standard TinyOS tools. The binary image is then passed to a packetizer that divides the Motorola SREC-format binary into actual segments.A segment has a 2-byte address field indicating its address in program memory and a 16-byte data field.In the current version of MOAP, each packet contains one segment.One mote attached to the PC becomes the original source (a basestation). It sends PUBLISH messages,advertising the new version of the code. Nodes check their version number and send SUBSCRIBE messages if it is smaller than the advertised versions. Nodes also use a link statistics mechanism so as to not subscribe to sources that have very lossy, intermittent, or otherwise unreliable links. Once the original source receives a subscribe message, it waits for a small amount of time to allow other nodes to send in their subscriptions as well and then starts the data transfer.

34. RESULT 1 Emulation in EmStar on a 32-bit platform with dynamic memory support

35. RESULT 2 Implementation of MOAP in order to evaluate it in its target platform. The setup consisted of 15 Mica 2 motes.

36. RESULT 3 Interesting findings 1. latency was evaluated against a choice of energy consumptions. 2. Networks with more nodes per hop should perform significantly better using this choice of ripple propagation.

37. RESULT 4 Mean and standard deviation with data points of time (in seconds) versus number of hops reprogrammed.

38. FUTURE WORK Sending differences between versions Support for selective node updates

39. REFERENCES 1.Crossbow Technology, "Mote In Network Programming User Reference," TinyOS document, http://webs.cs.berkeley.edu/tos/tinyos-1.x/doc/Xnp.pdf. 2.N. Reijers and K. Langendoen, "Efficient Code Distribution in Wireless Sensor Networks," WSNA, 2003. T. Stathopoulos, J. Heidemann, and D. Estrin, A Remote Code Update Mechanism for Wireless Sensor Networks, CENS Technical Report, #30, http://lecs.cs.ucla.edu/~thanos/moap-TR.pdf. 3.A. Chlipala, J. Hui, and G. Tolle, Deluge: Data Dissemination in Multi-Hop Sensor Networks, UC Berkeley CS294-1 Project Report, December 2003, http://www.cs.berkeley.edu/~jwhui/research/projects/deluge/deluge_poster.ppt. 4.T. Yeh, H. Yamamoto, and T. Stathopolous, Over-the-air Reprogramming of Wireless Sensor Nodes, UCLA EE202A Project Report, December 2003, http://lecs.cs.ucla.edu/~thanos/EE202a_final_writeup.pdf. http://webs.cs.berkeley.edu/tos/tinyos-1.x/doc/Xnp.pdfhttp://lecs.cs.ucla.edu/~thanos/moap-TR.pdf http://www.cs.berkeley.edu/~jwhui/research/projects/deluge/deluge_poster.ppt http://lecs.cs.ucla.edu/~thanos/EE202a_final_writeup.pdf