Mat: A Tiny Virtual Machine for Sensor Networks

1
Maté A Tiny Virtual Machine for Sensor Networks

• Philip Levis and David Culler
• Presented by Michele Romano

2
Outline

• Sensor Networks
• Virtual Machines
• Maté Details
• Evaluation
• Conclusion

3
Sensor Networks

• Composed of 1000s of tiny devices (Motes) with
  limited resources

4
Berkeley Mote Specifications
5
TinyOS

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

6
Reprogramming Motes

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

7
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

8
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

9
System Requirements

• Small
• Expressive
• Concise
• Resilient
• Efficient
• Tailorable
• Simple

10
Virtual Machine

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

11
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

12
Code Capsules

• There are four types of capsules
• Message send capsules
• Message receive capsules
• Timer capsules
• Subroutine capsules

13
Maté Architecture
14
Instruction Set

• There are three classes of Maté instructions
• 8 instructions reserved for users to define

15
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

16
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

17
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

18
Maté Evaluation

• Ad-hoc routing algorithm was implemented to
  measure
• Rate of instruction
• CPU overhead
• Network infection rates

19
1. Rate of InstructionTest

• Maté Bytecode vs. Native Code

20
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

21
3. Network Infection

• Percentage of Motes Running New Program Over Time

22
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

23
Conclusion

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

24
References

• http//www.cs.berkeley.edu/pal/research/mate.html
  
• http//www.cs.berkeley.edu/pal/pubs/brown-7-02.pd
  f
• http//www.cs.virginia.edu/qc9b/fall03cs851/mate_
  damon_jo.ppt