MATE A VM for Sensor Nets

1
MATE A VM for Sensor Nets

• Brian Blum
• Sept 11th, 2002
• OS Middleware

2
Mate - Outline

• The world of sensor networks
• Related Work (VMs)
• Mate Details
• Mate Evaluation
• Discussion and Questions

3
Assumptions and Generalities

• 100s to 1000s of motes
• Significant failure rate
• Redundancy through high density
• Impossible to collect and re-program
• Necessitate mission critical reprogramming

4
Example Application

• Great Duck Island1
• Distribute Sensors to Monitor Wildlife
• Disturbing birds reduce reproduction rates
• No prior data makes parameters difficult to tune
• Remote re-programming allows un-interruption,
  less disturbance, lower cost

5
Another Example
fire
Sensor Network
6
Related Work

• PicoJava JAVA byte code chip
• K Virtual Machine
• (160 - 512 KB memory)
• XML Configuration
• Much too complex
• swarmOS (in the works)

7
Programming Requirements

• Small (128KB insn, 4KB RAM)
• Expressive (versatile)
• Concise (limited space, bandwidth)
• Resilient (memory protection, error handling)
• Efficient (energy and bandwidth)
• Tailorable (specialized instructions)
• Simple (program dissemination)

8
Mate A Viral Solution

• Virtual Machine atop tinyOS components, sensors,
  memory
• TargetCompact Programs (
• Broken into capsules (24 insn1 byte each)
• Identification and versioning information
• Self-forwarding / self-propagating
• Three execution contexts (clock, send, receive)
• FeaturesHide Asynchrony and Race Conditions

9
Mate Architecture and Context

• Context (2 stacks)
• Clock (persistent)
• Send (not persistent)
• Receive ( not )
• Subroutines
• Use return stack
• Shared Variable (use?)
• 1 word
• gets, sets
• Message Buffer

Instruction
Data
shared var
T
Clock
V
Mate VM
T
Send
V
T
Receive
V
T
Sub-0
V
T
Network
Sub-1
V
T
Sub-2
V
Logger
T
Sub-3
V
Hardware
msg buffer
Boot/Scheduler
10
Mate Instructions / Memory

• Instructions
• 1 byte each (operands on stack)
• 8 user defined (default noops)
• Polymorphic (example add)
• VM controlled memory
• Stack bound checking
• Shared state limited to shared variable

11
Mate Capsules (Example)

• Event (packet arrival)

Instruction
Data
shared var

• Mate sets PC to Receive

Clock

• Subroutine Call

Mate VM
Mate VM
Send
Send

• Sendr invokes send
• Copies msg buffer onto op stack
• Executes concurrent to calling context

Receive
Receive
Sub-0
Network
Sub-1
Sub-2
Sub-2
Sub-2
Logger
Sub-3
msg buffer
12
Mate Capsule Infection

• Capsule packet arrives
• Perform type/version check

Instruction
Data
shared var
T
Clock
Clock
V

• Mate Installs Capsule

Mate VM
Mate VM
Send
Receive

• Mate Forwards Capsule
• forw continually propagating

Sub-0
Network
Sub-1
Sub-2
Logger
Sub-3
Hardware
msg buffer
13
Mate Evaluation

• Compare Mate vs. native byte code performance
• Costs
• Simple manipulate operand stack (and 33.51)
• Down call call tinyOS components (rand 9.51)
• Quick split event handler latency (sense
  3.41)
• Long split event handler latency (send
  1.031)
• Task en/dequeue accounts for 35 overhead
• Energy (execution and installation)
• Mate favored for small of executions
• Great Duck Island code 5 days dont use Mate

14
Mate Evaluation cont.

• Network Infection
• New Self-forwarding capsule
• New/Network probabilistically forwarded capsule

15
Mate Discussion

• Programming
• What is/isnt feasible?
• Meta-Programming
• Heterogeneity
• React to additional contexts
• Sensors
• Abstract objects
• Healing or self- properties
• Centralized (Base Station)
• Self-replication (controlled propagation)
• Unified data/instruction memory

16
Mate questions/issues

• Reliability of capsule delivery
• Security (Byzantine code)
• Forwarding by flooding (better solution?)
• Mate utility not for long lived programs
• How could Mate be improved?
• Anything else?