1. Mate: A Tiny Virtual Machine for Sensor Networks Philip Levis and David Culler Presented by: Damon Jo

2. The Origin of MATE Mate(mah-tay): A tea like beverage consumed mainly in Argentina, Uruguay, Paraguay and southern Brazil…

3. Outline Problem Statement Sensor Network TinyOS Mate Evaluation Mate Customization Bombilla Summary Discussion

4. Roadmap Problem Statement Sensor Networks TinyOS Mate Evaluation Mate Customization Bombilla Summary Discussion

5. Why Do We Need VM in WSN? Large number (100’s to 1000’s) of nodes in a coverage area Some nodes will fail during operation Change of function during the mission Almost impossible to manually recollect and reprogram Need for viral program

6. Sensor Network in Operation (Great Duck Island?)

7. Roadmap Problem Statement Sensor Networks TinyOS Mate Evaluation Mate Customization Bombilla Summary Discussion

8. Berkley TOS Motes

9. Roadmap Problem Statement Sensor Networks TinyOS Mate Evaluation Mate Customization Bombilla Summary Discussion

10. TinyOS – Software Architecture Component based programming model Three computational abstraction: commands(down), events(up) non-blocking split phase asynchronous(hardware interrupt) tasks blocking FIFO queue

11. TinyOS – Network Active message in TOS handles MAC single hop communication unreliable data link protocol 30 byte payload 16-bit mote ID, 0xffff: broadcast 8-bit type; selects software handler 8-bit AM group; logical network separation

12. Roadmap Problem Statement Sensor Networks TinyOS Mate Evaluation Mate Customization Bombilla Summary Discussion

13. Related Works PicoJava Java bytecode execution hardware K Virtual Machine requires 160 – 512 KB of memory XML too complex and not enough RAM Scylla VM for mobile embedded system Suggested solution Mate: A Tiny Virtual Machine for Sensor Network

14. System Requirements Small(16KB inst mem, 1KB RAM) Expressive(versatile) Concise(limited memory & bandwidth) Resilience(memory protection) Efficient(bandwidth) Tailorable(user defined instructions) Simple(viral programming)

15. Mate in a Nutshell Built on TinyOS, runs on rene and mica Stack Architecture Three concurrent execution contexts Execution triggered by predefined events Tiny code capsules; self-propagate into network Built in communication and sensing instructions

16. Component Breakdown Mate runs on rene2 and mica 7286 bytes code, 603 bytes RAM

17. Mate Architecture Stack based architecture Single shared variable gets/sets Three events: Clock timer Message reception Message send Hides asynchrony Simplifies programming Less prone to bugs

18. Instruction Set One byte per instruction Three classes: basic, s-type, x-type basic: arithematic, halting, LED operation s-type: messaging system x-type: pushc, blez  8 instructions reserved for users to define Instruction polymorphism ex) add(data, message, sensing)

19. Code Example(1) Display Counter to LED

20. Code Example(2) Sense and Send

21. TinyOS Sense and Send event result_t Timer.fired() { if (state == IDLE && call Photo.sense()) {state = SENSE;} return SUCCESS; } event result_t Photo.dataReady(uint16_t data) { if (state == SENSE) { packet->reading = data; if (call SendMsg.send(packet, sizeof(DataBuf)) { state = SENDING; } else {state = IDLE;} } return SUCCESS; } event result_t SendMsg.sendDone(TOS_MsgPtr msg) { if (state == SENDING) {state = IDLE;} return SUCCESS; }

22. Code Capsules One capsule = 24 instructions Fits into single TOS packet Atomic reception Code Capsule Type and version information Type: send, receive, timer, subroutine

23. Viral Code Capsule transmission: forw Forwarding other installed capsule: forwo(use within clock capsule) Mate checks on version number on reception of a capsule -> if it is newer, install it Versioning: 32bit counter(lasts a long time, centuries) Easily disseminates new code over the network

24. Propagation Example

25. Node Enters the Network

26. Roadmap Problem Statement Sensor Networks TinyOS Mate Evaluation Mate Customization Bombilla Summary Discussion

27. Evaluation Metrics - CPU cycles - Bandwidth - Energy - Infection rate - Propagation time

28. Bytecodes vs. Native Code Mate IPS: ~10,000 Mate overhead: Every instruction is executed as separate TOS task

29. Installation Costs Bytecodes have computational overhead But this can be compensated by using small packets on upload(to some extent)

30. When is Mate Preferable? For small number of executions GDI example: Bytecode version is preferable for a program running less than 5 days In energy constrained domains Use Mate capsule as a general RPC engine

31. Code Propagation Evaluation Environment 42 node network in 3 by 14 grid Radio transmission: 3 hop network Cell size: 15 to 30 motes

32. Network Infection Rate Every mote runs its clock capsule every 20 seconds Self-forwarding clock capsule

33. Roadmap Problem Statement Sensor Networks TinyOS Mate Evaluation Mate Customization Bombilla Summary Discussion

34. Customizing Mate We have already discussed usefulness of VM in the beginning Mate is general architecture; user can build customized VM User can select bytecodes and execution events

35. Customizing Issues Flexibility vs. Efficiency Customizing increases efficiency on the cost of changing the requirements Java’s solution: General computational VM + class libraries Mate’s approach: More customizable solution -> let user decide

36. Howto Select a language -> defines VM bytecodes Select execution events -> execution context, code image Select primitives -> beyond language functionality

37. Constructing a Mate VM This generates a set of files -> which are used to build TOS application and to configure script program

38. Compiling and Running a Program Write programs in the scripter VM-specific binary code Send it over the network to a VM

39. Roadmap Problem Statement Sensor Networks TinyOS Mate Evaluation Mate Customization Bombilla Summary Discussion

40. Bombilla Next version of Mate?

41. Bombilla Architecture Once context: perform operations that only need single execution 16 word heap sharing among the context; setvar, getvar Buffer holds up to ten values; bhead, byank, bsorta

42. Bombilla Instruction Set basic: arithmetic, halt, sensing m-class: access message header v-class: 16 word heap access j-class: two jump instructions x-class: pushc

43. Enhanced Features of Bombilla Capsule Injector: programming environment Synchronization: 16-word shared heap; locking scheme Provide synchronization model: handler, invocations, resources, scheduling points, sequences Resource management: prevent deadlock Random and selective capsule forwarding Error State

44. Roadmap Problem Statement Sensor Networks TinyOS Mate Evaluation Mate Customization Bombilla Summary Discussion

45. Summary Mate is a context based, event driven Virtual Machine Stack architecture Three instruction type Instructions are kept in capsules Viral program Prefer short CPU tasks

46. Roadmap Problem Statement Sensor Networks TinyOS Mate Evaluation Mate Customization Bombilla Summary Discussion

47. Comparing to traditional VM concept, is Mate platform independent? Can we have it run on heterogeneous hardware? Security issues. How can we trust the received capsule? Is there a way to prevent version number race with adversary?

48. Cont. In viral programming, is there a way to forward messages other than flooding? After a certain number of nodes are infected by new version capsule, can we forward based on need? Bombilla has some sophisticated OS features. What is the size of the program? Does sensor node need all those features?

49. References P. Levis and D. Culler. Mate: A Virtual Machine for Sensor Networks. ASPLOS, Oct. 2002 P. Levis and D. Culler. A Case for Infectious Virtual Programs in Sensor Networks P. Levis. Bombilla: A Tiny Virtual Machine for TinyOS P. Stanley-Marbell and L. Lftode. Scylla: A Smart Virtual Machine for Mobile Embedded Systems http://www.cs.berkeley.edu/~pal/research/mate.html http://www.cs.berkeley.edu/~pal/pubs/asplos02.pdf http://webs.cs.berkeley.edu/

50. Thank You