Maté: A Tiny Virtual Machine for Sensor Networks Philip Levis and David Culler Presented by: Michele Romano

Outline Sensor Networks Virtual Machines Maté Details Evaluation Conclusion

Sensor Networks Composed of 1000’s of tiny devices (Motes) with limited resources

Berkeley Mote Specifications

TinyOS OS designed for sensor networks Split-phase non-blocking execution Not suited well to non-expert programmers

Reprogramming Motes Reprogramming is desirable as: Environmental conditions change Analysis techniques evolve Examples: Great Duck Island Building instrumentation

Reprogramming Motes To change the behaviour of a TinyOS program, either: 1. Hardcode a state transition OR 2. Modify source code, recompile a TinyOS image and place image on mote

Sensor Networks Challenges Energy –Recharging is difficult or impossible –Deterministic network lifetime desirable Communication –Lossy wireless networks –Bandwidth conservation Programming –Motes unreachable in deployed networks –Difficult for a non-programmer to program TinyOS

System Requirements Small Expressive Concise Resilient Efficient Tailorable Simple

Virtual Machine Easier programming Short VM programs A VM can provide a safe program execution environment

Maté VM Overview Bytecode interpreter that runs on TinyOS Single TinyOS component that sits on top of several system components Code fits in capsules of 24 instructions Built-in ad-hoc routing algorithm AND mechanisms for writing new ones

Code Capsules There are four types of capsules –Message send capsules –Message receive capsules –Timer capsules –Subroutine capsules

Maté Architecture

Instruction Set There are three classes of Maté instructions: 8 instructions reserved for users to define basic00iiiiiii = instruction s-class01iiixxxi = instruction, x=argument x-class1ixxxxxxi = instruction, x=argument

Code Execution Execution of code begins in response to an event These three contexts can run concurrently Each instruction is executed as a TinyOS task

Code Security Bound checks prevent overrun and underrun Heap addressing is not a problem because there is only a single shared variable Unrecognized instructions result in no- ops

Code Infection Reprogramming is easy: Each capsule contains a type and version number When a capsule with a more recent version is received, it is installed forw or forwo is used to broadcast the capsule for network neighbours to install

Maté Evaluation Ad-hoc routing algorithm was implemented to measure: 1.Rate of instruction 2.CPU overhead 3.Network infection rates

1. Rate of InstructionTest Maté Bytecode vs. Native Code OperationMaté Clock CyclesNative Clock CyclesCost Simple: and :1 Downcall: rand :1 Quick Split: sense :1 Long Split: sendr685+~20000~ :1

2. CPU Overhead Given the energy cost of an execution and the energy cost of installation: –Mate is preferable for a small number of executions –For large number of executions, Native code is preferable

3. Network Infection Percentage of Motes Running New Program Over Time

Case Study Great Duck Island Application Spends most of its time in deep sleep mode – draws 50 μA Reads several sensors and sends a packet Maté proves to save energy if only run for 5 days or less

Conclusion Maté met all of the defined requirements Maté can conserve energy in domains of frequent reprogramming VM can provide user-land guarantees

References rch/mate.htmlhttp:// rch/mate.html brown-7-02.pdfhttp:// brown-7-02.pdf cs851/mate_damon_jo.ppthttp:// cs851/mate_damon_jo.ppt