Anish Arora Mohamed Gouda Ted Herman Sandeep Kulkarni Mikhail Nesterenko

1. Self-Stabilization in NESTNetworked Sensor Development Tools:Hybrid Simulation and Network Reprogramming Anish Arora Mohamed Gouda Ted Herman Sandeep Kulkarni Mikhail Nesterenko Charleston, SCJune 28, 2004

2. Outline • Simulation ToolsMikhail Nesterenko and David Watson Kent State University • MULE: hybrid debugging and simulation • TDB: visual TinyOS debugger • Other: Secure Location Verification & Geometric Routing • Network ReprogrammingSandeep Kulkarni, Limin Wang, and Mahesh Arumugam Michigan State University • MNP: multihop network reprogramming • TDMA-based reprogramming

3. MULE: Debugging with Hybrid Simulation • Applications running on real motes are hard to debug • TOSSIM is a good debugger, but low fidelity • Low power radios are hard to model • Sensor data is just random values • Idea: use real motes for radio communication and sensing, do debugging in the simulator • Real motes: • accurate radio communication • accurate sensor readings • Simulator ― easy interface for debugging and monitoring

4. Host PC SurgeM MultiHopRouter Leds Photo Bcast GenericCommPromiscuous AMPromiscuous RadioCRCPacket MulePhotoM MulePacketM TCP or Serial Connections Mote Mote MuleApp MuleApp Sensors Radio Sensors Radio MULE Architecture • MULE on PC implements modules for radio and sensors • Synchronizes simulated and real time • Communicates with real motes • MULE on physical motes handles • communications with host PC • radio transmissions and sensor readings TOSSIM MULE

5. Simulation Real Time Mote 1 Mote 2 Mote 3 Mote 1 Mote 2 Mote 3 Send m1 Request to send m1 Send m2 Send m3 Request to send m2 Request to send m3 Time Simulation Freeze Receive SendDone Receive Simulation Freeze (m2, m3) Send time, packets received MULE:Interaction of Real & Simulated Events MULE collects simulated messages, freezes simulation, sends same messages in realspace to implement concurrent transmission

6. Sensor Request Sensor Data Sensor Reading MULE: Sensing Experiment • TOSSIM runs Oscilloscope(standard TinyOS app) • Real mote takes photosensor readings • Oscilloscope visualizer (TinyOS sample program) displays readings Host PC Oscilloscope App TOSSIM

7. MULE: Tiling • Note: 1 to 1 relation between virtual and physical motes is not necessary • MULE can map a large number of virtual motes onto a small set of physical motes • Tile – a repeated region of physical network composing virtual network • Physical motes are used to represent the tile and interference zone • At simulation freeze, MULE maps virtual motes onto physical motes, and has them send messages to model interference • The larger the interference zone, the greater the fidelity, but the slower the simulation Physical Motes Virtual Motes

8. Message Message TOSSIM Tile Physical Motes Interference Zone MULE: Tiling Experiment • Linear topology • 12 virtual motes mapped onto 4 physical motes • Tile size is 2, with interference zone width of 1 • Two messages sent, starting from left and right ends • Red LED on: message from left received • Yellow LED on: message from right received • Routing code runs on the virtual motes, physical motes only send messages

9. MULE: Future Work & Further Information • Extensions • Use timing information returned by motes to add fidelity to TOSSIM's time simulation • Extract data from real motes to debug and fine-tune simulation • Number of collisions, backoffs, time spent transmitting, topology, statistics on link quality • Work on more precise time synchronization between motes and TOSSIM • Network latency is an issue with timing fidelity • Potentially an issue when used at scale • Component Migration from simulator to real motes • Gradual Debugging- move components to motes as they are debugged • For more information: • Tech report TR-KSU-CS-2004-02: http://deneb.cs.kent.edu/mule/TR-KSU-CS-2004-02.pdf • MULE homepage: http://deneb.cs.kent.edu/mule/

10. Outline • Simulation ToolsMikhail Nesterenko and David Watson Kent State University • MULE: hybrid debugging and simulation • TDB: visual TinyOS debugger • Other: Secure Location Verification & Geometric Routing • Network ReprogrammingSandeep Kulkarni, Limin Wang, and Mahesh Arumugam Michigan State University • MNP: multihop network reprogramming • TDMA-based reprogramming

11. TDB: TinyOS Debugger • TDB is a visual debugger for TOS applications running under TOSSIM • Features include • Set breakpoints specific to one mote • Step through code line-by-line • Set watchpoints for global variables on one mote • Watched variables can be graphically displayed next to motes in TinyViz main display • Runs on top of GDB, so all GDB commands available • TDB Homepage: http://deneb.cs.kent.edu/mule/tdb/

13. Outline • Simulation ToolsMikhail Nesterenko and David Watson Kent State University • MULE: hybrid debugging and simulation • TDB: visual TinyOS debugger • Other: Secure Location Verification & Geometric Routing • Network ReprogrammingSandeep Kulkarni, Limin Wang, and Mahesh Arumugam Michigan State University • MNP: multihop network reprogramming • TDMA-based reprogramming

14. RF signal prover B A sensors a c b edge_change edge_change d edge_selection h g e f traversaldirection i void k j Other Secure location verification • stated by Sastry, Shankar and Wagner [SSW2003] • (potentially malicious) prover required to confirm itspresence within designated zone to sensors • our solution exploits broadcast nature of RF signal • we cover arbitrary shaped zones, estimate the upper bound on sensors, counteract provers with directional antennas, work with arbitrary sensor placement, require logarithmic number of tries • details: www.cs.kent.edu/~mikhail/Research/tr-ksu-cs-2004-1.pdf Geometric routing • sensor know coordinates, very scalable • GFG (GPSR) works on planar graphs –traverses faces, requires unit-disk graphsfor construction • our solution – traverses voids, workson arbitrary graphs • details www.cs.kent.edu/~mikhail/Research/tr-ksu-cs-2004-4.pdf

15. Outline • Simulation ToolsMikhail Nesterenko and David Watson Kent State University • MULE: hybrid debugging and simulation • TDB: visual TinyOS debugger • Other: Secure Location Verification & Geometric Routing • Network ReprogrammingSandeep Kulkarni, Limin Wang, and Mahesh Arumugam Michigan State University • MNP: multihop network reprogramming • TDMA-based reprogramming

16. Reprogramming Requirements • Reliability • Each mote needs to receive the code in entirety • Memory usage • Use as little as possible so that other applications are not affected • Energy • Reprogramming is energy-hungry • But not as important since reprogramming is done rarely • Need to distribute load evenly if reprogramming is done many times • Speed • As long as within reasonable time

17. Protocols • MNP: Multihop network programming • Based on the goal of reducing memory usage • TDMA based reprogramming • Based on the goal of reducing energy

18. MNP: Need for Sender Selection • Suppose that the base station forwards the code to receivers R1 … R5 • Who should forward the code next • Undesirable if all (many of them) transmit simultaneously • Some receivers are a better choice than others • Need for sender selection • Reduce collision by ensuring that only one sender transmits in any neighborhood. • Select a sender that is likely to have the most impact Base R1 R2 R3 R4 R5

19. Sender Selection Algorithm • Each node sends an advertisement about the availability of the code • Advertisement contains the number of followers (initially 0) that are expected to get the code from this sender • Each node that wants the new code sends download request • This message also contains the number of followers for that sender • Enables us to deal with hidden terminal effect • A node defers code transmission if it encounters a node with more followers • We find that with this protocol, collisions are virtually eliminated as only one sender is active in a neighborhood

20. Issue: Memory Usage • Keeping track of lost packets in memory is expensive • Use of EEPROM to save information about lost packets • Necessary to ensure that the task that needs to be completed between two consecutive messages is fixed • Number of writes to EEPROM in any step should be small • Developed a simple linked list algorithm for EEPROM

21. Protocol Overview

22. Sample Results

23. Sample Results

24. Demo Setup (Used on May 1, 2004) • 6x8 grid • 2000 Capsule program • Initially, all motes were running Blink and reprogramming component • They were reprogrammed with LITeS code used in the August 2003 demo • Initially, only one mote has the new code (Think mote attached to Stargate) • Approximate time: 30 minutes

25. Outline • Simulation ToolsMikhail Nesterenko and David Watson Kent State University • MULE: hybrid debugging and simulation • TDB: visual TinyOS debugger • Other: Secure Location Verification & Geometric Routing • Network ReprogrammingSandeep Kulkarni, Limin Wang, and Mahesh Arumugam Michigan State University • MNP: multihop network reprogramming • TDMA-based reprogramming

26. TDMA Reprogramming – Ideal Case Based on the TDMA protocol presented at previous PI meeting: When j receives a mr from k if mr is start-multihop-download message // prepare for download setup flash, pointers, signal download to app else if mr contains a program capsule (cl) store cl in appropriate address if cl is the last capsule start a reboot timer when the timer fires, load new program end if forward mr in the next TDMA slot end

27. TDMA Service: Dealing With Link Errors • Link errors are small due to TDMA • Caused by change in communication characteristics • TDMA slot assignment prevents most collisions • Back pressure mechanism used to deal with lost capsules • A node can transmit capsule nth capsule if its successor has transmitted (n-W)th capsule • A successor that falls behind can request retransmission • Implicit acknowledgments are used to track the successors

28. TDMA Reprogramming – Current Status • Theoretical code propagation time due to pipelining for a program with ctot capsules in a nxn network: • (ctot – 1) Pb + 2 (n – 1) Pb, where Pb is the TDMA period • Implemented in TinyOS release 1.1.5 for MICA-2 motes

29. Simulation Results • Time to reprogram is almost independent of the network size • Energy can be saved by listening to radio only when a neighbor transmits

30. Conclusion • MNP is implemented on TinyOS-1.1.5 platform • Demonstrated on May 1, 2004 • Virtually eliminates collisions based on sender selection protocol • Energy can be saved by turning of radio when someone in the neighborhood is transmitting the portion of the code that a mote has already received • Promising preliminary results for TDMA reprogramming • TDMA reprogramming does not use any explicit messages to recover from lost capsules • Implicit acks and back pressure mechanism is used to recover from link errors (or lost capsules)

31. Future Tasks • Reducing delay • Current design is conservative in several aspects • Updating of motes sleeping throughout reprogramming • Extending reprogramming for XSMs • Implementing pipelining for MNP • Improving TDMA performance for dense networks • Allow only a subset of sensors to transmit • Energy considerations during reprogramming • MNP already allows a sensor to choose its participation based on remaining energy