Self-Stabilization in NEST

Networked Sensor Development Tools:Hybrid Simulation and Network Reprogramming

Anish AroraMohamed GoudaTed HermanSandeep KulkarniMikhail Nesterenko

Charleston, SCJune 28, 2004

Outline Simulation Tools Mikhail Nesterenko and David Watson Kent State University MULE: hybrid debugging and simulation TDB: visual TinyOS debugger Other: Secure Location Verification & Geometric Routing

Network Reprogramming Sandeep Kulkarni, Limin Wang, and Mahesh Arumugam Michigan State University MNP: multihop network reprogramming TDMA-based reprogramming

MULE: Debugging with Hybrid SimulationApplications running on real motes are hard to debugTOSSIM is a good debugger, but low fidelityLow power radios are hard to modelSensor data is just random valuesIdea: use real motes for radio communication and sensing, do debugging in the simulatorReal motes:accurate radio communication accurate sensor readingsSimulator easy interface for debugging and monitoring

MULE ArchitectureMULE on PC implements modules for radio and sensorsSynchronizes simulated and real timeCommunicates with real motesMULE on physical motes handlescommunications with host PCradio transmissions and sensor readingsMULETOSSIM

MULE:Interaction of Real & Simulated EventsMULE collects simulated messages, freezes simulation, sends same messages in realspace to implement concurrent transmission

MULE: Sensing ExperimentTOSSIM runs Oscilloscope (standard TinyOS app)Real mote takes photosensor readingsOscilloscope visualizer (TinyOS sample program) displays readingsHost PCOscilloscope AppTOSSIM

MULE: TilingNote: 1 to 1 relation between virtual and physical motes is not necessaryMULE can map a large number of virtual motes onto a small set of physical motes

Tile a repeated region of physical network composing virtual networkPhysical motes are used to represent the tile and interference zoneAt simulation freeze, MULE maps virtual motes onto physical motes, and has them send messages to model interferenceThe larger the interference zone, the greater the fidelity, but the slower the simulationPhysicalMotesVirtualMotes

MULE: Tiling ExperimentLinear topology12 virtual motes mapped onto 4 physical motesTile size is 2, with interference zone width of 1Two messages sent, starting from left and right endsRed LED on: message from left receivedYellow LED on: message from right receivedRouting code runs on the virtual motes, physical motes only send messages

MULE: Future Work & Further InformationExtensions Use timing information returned by motes to add fidelity to TOSSIM's time simulation Extract data from real motes to debug and fine-tune simulationNumber of collisions, backoffs, time spent transmitting, topology, statistics on link qualityWork on more precise time synchronization between motes and TOSSIMNetwork latency is an issue with timing fidelityPotentially an issue when used at scaleComponent 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.pdfMULE homepage: http://deneb.cs.kent.edu/mule/

Outline Simulation Tools Mikhail Nesterenko and David Watson Kent State University MULE: hybrid debugging and simulation TDB: visual TinyOS debugger Other: Secure Location Verification & Geometric Routing

Network Reprogramming Sandeep Kulkarni, Limin Wang, and Mahesh Arumugam Michigan State University MNP: multihop network reprogramming TDMA-based reprogramming

TDB: TinyOS DebuggerTDB is a visual debugger for TOS applications running under TOSSIMFeatures includeSet breakpoints specific to one moteStep through code line-by-lineSet watchpoints for global variables on one moteWatched variables can be graphically displayed next to motes in TinyViz main displayRuns on top of GDB, so all GDB commands availableTDB Homepage: http://deneb.cs.kent.edu/mule/tdb/

Outline Simulation Tools Mikhail Nesterenko and David Watson Kent State University MULE: hybrid debugging and simulation TDB: visual TinyOS debugger Other: Secure Location Verification & Geometric Routing

Network Reprogramming Sandeep Kulkarni, Limin Wang, and Mahesh Arumugam Michigan State University MNP: multihop network reprogramming TDMA-based reprogramming

OtherSecure location verificationstated by Sastry, Shankar and Wagner [SSW2003] (potentially malicious) prover required to confirm its presence within designated zone to sensors our solution exploits broadcast nature of RF signalwe 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.pdfGeometric routingsensor know coordinates, very scalableGFG (GPSR) works on planar graphs traverses faces, requires unit-disk graphs for constructionour solution traverses voids, works on arbitrary graphsdetails www.cs.kent.edu/~mikhail/Research/ tr-ksu-cs-2004-4.pdf

Outline Simulation Tools Mikhail Nesterenko and David Watson Kent State University MULE: hybrid debugging and simulation TDB: visual TinyOS debugger Other: Secure Location Verification & Geometric Routing

Network Reprogramming Sandeep Kulkarni, Limin Wang, and Mahesh Arumugam Michigan State University MNP: multihop network reprogramming TDMA-based reprogramming

Reprogramming RequirementsReliabilityEach mote needs to receive the code in entiretyMemory usageUse as little as possible so that other applications are not affectedEnergyReprogramming is energy-hungryBut not as important since reprogramming is done rarelyNeed to distribute load evenly if reprogramming is done many timesSpeedAs long as within reasonable time

ProtocolsMNP: Multihop network programmingBased on the goal of reducing memory usageTDMA based reprogrammingBased on the goal of reducing energy

MNP: Need for Sender SelectionSuppose that the base station forwards the code to receivers R1 R5Who should forward the code nextUndesirable if all (many of them) transmit simultaneouslySome receivers are a better choice than othersNeed for sender selectionReduce collision by ensuring that only one sender transmits in any neighborhood.Select a sender that is likely to have the most impact

Base R1 R2R3 R4R5

Sender Selection AlgorithmEach node sends an advertisement about the availability of the codeAdvertisement contains the number of followers (initially 0) that are expected to get the code from this senderEach node that wants the new code sends download requestThis message also contains the number of followers for that senderEnables us to deal with hidden terminal effectA node defers code transmission if it encounters a node with more followersWe find that with this protocol, collisions are virtually eliminated as only one sender is active in a neighborhood

Issue: Memory UsageKeeping track of lost packets in memory is expensiveUse of EEPROM to save information about lost packetsNecessary to ensure that the task that needs to be completed between two consecutive messages is fixedNumber of writes to EEPROM in any step should be smallDeveloped a simple linked list algorithm for EEPROM

5

...

...

DATA

MissingPacketID: 6

1

...

...

DATA

Packet ID

Type

Data

2

Section Length: 1

Previous: 0

LOST

3

...

...

DATA

4

Section Length: 1

Previous: 2

LOST

6

Section Length: 3

Previous: 4

LOST

7

8

9

...

...

DATA

(In RAM)

Protocol Overview

Sample Results

Sample Results

Demo Setup (Used on May 1, 2004)6x8 grid2000 Capsule programInitially, all motes were running Blink and reprogramming componentThey were reprogrammed with LITeS code used in the August 2003 demoInitially, only one mote has the new code (Think mote attached to Stargate)Approximate time: 30 minutes

Outline Simulation Tools Mikhail Nesterenko and David Watson Kent State University MULE: hybrid debugging and simulation TDB: visual TinyOS debugger Other: Secure Location Verification & Geometric Routing

Network Reprogramming Sandeep Kulkarni, Limin Wang, and Mahesh Arumugam Michigan State University MNP: multihop network reprogramming TDMA-based reprogramming

TDMA Reprogramming Ideal CaseBased on the TDMA protocol presented at previous PI meeting:

When j receives a mr from kif mr is start-multihop-download message// prepare for downloadsetup flash, pointers, signal download to appelse if mr contains a program capsule (cl)store cl in appropriate addressif cl is the last capsulestart a reboot timerwhen the timer fires, load new programend ifforward mr in the next TDMA slotend

TDMA Service: Dealing With Link ErrorsLink errors are small due to TDMACaused by change in communication characteristicsTDMA slot assignment prevents most collisionsBack pressure mechanism used to deal with lost capsulesA node can transmit capsule nth capsule if its successor has transmitted (n-W)th capsuleA successor that falls behind can request retransmissionImplicit acknowledgments are used to track the successors

TDMA Reprogramming Current StatusTheoretical 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 periodImplemented in TinyOS release 1.1.5 for MICA-2 motes

Simulation ResultsTime to reprogram is almost independent of the network sizeEnergy can be saved by listening to radio only when a neighbor transmits

Chart2

0.87558.525542.525568.0255

0.90958.559542.559568.0595

0.99458.644542.644568.1445

1.16458.814542.814568.3145

1.56 KB

15.625 KB

78.125 KB

125 KB

Network Size

Time to code dissemination (in minutes)

Time to code dissemination (in ideal scenario)

Sheet1

Inteference range3

Period17

Time slot30

Period in ms510

No. of CapsulesProgram Size3x35x510x1020x20

"n"351020

1001.56 KB0.87550.90950.99451.1645

100015.625 KB8.52558.55958.64458.8145

500078.125 KB42.525542.559542.644542.8145

8000125 KB68.025568.059568.144568.3145

Sheet1

1.56 KB

15.625 KB

78.125 KB

125 KB

Network Size

Time to code dissemination (in minutes)

Time to code dissemination (in ideal scenario)

Sheet2

Sheet3

ConclusionMNP is implemented on TinyOS-1.1.5 platformDemonstrated on May 1, 2004Virtually eliminates collisions based on sender selection protocolEnergy can be saved by turning of radio when someone in the neighborhood is transmitting the portion of the code that a mote has already receivedPromising preliminary results for TDMA reprogrammingTDMA reprogramming does not use any explicit messages to recover from lost capsulesImplicit acks and back pressure mechanism is used to recover from link errors (or lost capsules)

Future TasksReducing delayCurrent design is conservative in several aspectsUpdating of motes sleeping throughout reprogrammingExtending reprogramming for XSMsImplementing pipelining for MNPImproving TDMA performance for dense networksAllow only a subset of sensors to transmitEnergy considerations during reprogrammingMNP already allows a sensor to choose its participation based on remaining energy

MULE allows running of unmodified applications on host PC example: surgeUses real motes for sensor readings and radioOne of the crucial components of MULE is synchronization of real and simulated eventsMULE does this thru sim freezestarget reliability 95% first to focus on memory size reduction MNP 190 BytesDeluge uses 1.5KB memory (reduced it down to 150Bytes)network target size 100/200 motes

Goal of MNP was to reduce memory usage whereas the goal of TDMA was to save energy.Our protocol is the first protocol that reduced the memory requirement considerably. Since then, Berkeley has new results where memory is reduced to comparable levels.senders are indeed unique in each neighborhood shown in experimentscapsule size 16 bytes BLINK to LITEsone mote time programming 5 minutescan deal with failure of successor by keeping track of how many times you have to come backcode undergoing testing, working consistently for small-size networkthis is energy efficient graph is theoretical results