mate: a tiny virtual machine for sensor networks
DESCRIPTION
Mate: A Tiny Virtual Machine for Sensor Networks. Philip Levis and David Culler Presented by: Damon Jo. Mate(mah-tay): A tea like beverage consumed mainly in Argentina, Uruguay, Paraguay and southern Brazil…. The Origin of MATE. Outline. Problem Statement Sensor Network TinyOS Mate - PowerPoint PPT PresentationTRANSCRIPT
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