Mate: A Tiny Virtual Machine for Sensor Networks

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

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

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 Send it over the network to a VM VM-specific binary code Write programs in the scripter

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. Discussion • 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