mate: a tiny virtual machine for sensor networks

Mate: A Tiny Virtual Machine for Sensor Networks

Philip Levis and David CullerPresented by: Damon Jo

The Origin of MATE

Mate(mah-tay): A tea like beverage consumed mainly in Argentina, Uruguay, Paraguay and southern Brazi

l…

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

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

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

Sensor Network in Operation(Great Duck Island?)

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

Berkley TOS Motes

2850

Alk/ 2AA

225

Li/ CR2032

Battery Power

Alk/ 2AALi/ CR2450Type/ Size

2850575Capacity (mAh)

OOK/ ASKOOKModulation Type

10/ 4010Rate (Kbps)

RFM TR1000Radio

Communication

410.5RAM (KB)

128168Prog. mem. (KB)

ATMega103/ 128ATMega163AT90LS8535Type

Microcontroller (4MHz)

Feb-02Aug-01Jun-01Oct-00Sep-99Date

MicaDotRene2ReneWeCMote Type

2850

Alk/ 2AA

225

Li/ CR2032

Battery Power

Alk/ 2AALi/ CR2450Type/ Size

2850575Capacity (mAh)

OOK/ ASKOOKModulation Type

10/ 4010Rate (Kbps)

RFM TR1000Radio

Communication

410.5RAM (KB)

128168Prog. mem. (KB)

ATMega103/ 128ATMega163AT90LS8535Type

Microcontroller (4MHz)

Feb-02Aug-01Jun-01Oct-00Sep-99Date

MicaDotRene2ReneWeCMote Type

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

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

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

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

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 solutionMate: A Tiny Virtual Machine for Sensor Network

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)

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 networ

k Built in communication and sensing instructio

ns

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

Mate Architecture

0 1 2 3

Subroutines

Clock

Send

Receive

Events

gets/sets

0 1 2 3

Subroutines

Clock

Send

Receive

Events

gets/sets

Code

OperandStack

ReturnStack

PC

Code

OperandStack

ReturnStack

PC

Stack based architecture Single shared variable

•gets/sets Three events:

•Clock timer•Message reception•Message send

Hides asynchrony•Simplifies programming•Less prone to bugs

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)

Code Example(1) Display Counter to LED

gets # Push heap variable on stackpushc 1 # Push 1 on stackadd # Pop twice, add, push resultcopy # Copy top of stacksets # Pop, set heappushc 7 # Push 0x0007 onto stackand # Take bottom 3 bits of valueputled # Pop, set LEDs to bit patternhalt #

Code Example(2) Sense and Send

pushc 1 # Light is sensor 1sense # Push light reading on stackpushm # Push message buffer on stackclear # Clear message bufferadd # Append reading to buffersend # Send message using built-inhalt # ad-hoc routing system

TinyOS Sense and Sendevent 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;

}

Code Capsules

One capsule = 24 instructions Fits into single TOS packet Atomic reception Code Capsule

Type and version information Type: send, receive, timer, subroutine

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

Propagation Example

Node Enters the Network

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

Evaluation Metrics

- CPU cycles- Bandwidth- Energy- Infection rate- Propagation time

Bytecodes vs. Native Code Mate IPS: ~10,000 Mate overhead: Every instruction is

executed as separate TOS task

Installation Costs Bytecodes have computational overhead But this can be compensated by using small pack

ets on upload(to some extent)

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 eng

ine

Code Propagation Evaluation Environment

42 node network in 3 by 14 grid Radio transmission: 3 hop network Cell size: 15 to 30 motes

Network Infection Rate Every mote runs

its clock capsule every 20 seconds

Self-forwarding clock capsule

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

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

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

Howto Select a language

-> defines VM bytecodes Select execution events

-> execution context, code image Select primitives

-> beyond language functionality

Constructing a Mate VM

This generatesa set of files-> which are used to buildTOS applicationandto configure script program

Compiling and Running a Program

Write programs in the scripter

VM-specific binary code

Send it over the network to a VM

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

Bombilla Next version of Mate?

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

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

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

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

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

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

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?

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?

References P. Levis and D. Culler. Mate: A Virtual Machine for Sensor Netwo

rks. 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/

Thank You