Maté. Presentation Outline. Presentation Outline. Introduction - Why? Introduction Mate VM. Introduction - Requirements

Transcription

1 Maté Maté: : A Tiny Virtual Machine for Sensor Networks Introduction Implementation Evaluation Discussion and Critique Authors: Philip Levis and David Culler Presenter: Fernando Zamith Introduction - Why? Sensor Networks need to be dynamic and be able to adapt to changes. Cannot require physical contact for reprogramming. Some possibilities: Ideal if motes could learn. Native code where etraneous functionality is implemented to account for all possible behaviour. Mote reprogramming through upload of entire binary. Virtual Machines. Introduction Mate VM Current VM designs not suitable due to memory and energy constraints. Mate is a bytecode interpreter that runs on motes. Provides abstraction layer between the application and the operating system. Applications are interpreted by the VM and eecuted as native code. Introduction - Requirements Requirements targeted by Mate: Small, allowing code to fit into older motes. Epressive, supporting a wide range of applications. Concise, short applications, that conserve network bandwidth. Resilient, no crashing. Energy efficient. Tailorable, supporting specialized operations. Simple, in-situ, fast, mostly autonomous. Mate does not meet all of these requirements. Introduction Implementation Evaluation Discussion and Critique

2 Implementation Mate Component Implementation Architecture Mate is a bytecode interpreter for TinyOS. It is a component that sits atop of other TinyOS components. Designed with the rene2 and mica motes in mind. Thus, must fit in KB or RAM and 6KB of instruction memory. Stack-based architecture. Three eecution contets, each containing: An operand stack (ma depth of 6), A return stack (ma depth of 8). One shared variable. Implementation Eecution Contets Implementation Instruction Set Cloc k The architecture specifies three eecution contets: Clock, Receive, and Send. Eecution upon reception of three events: clock timer, message reception, and message transmission. The three contets can run concurrently at the instruction level (scheduled as s). pushc copy add FIFO Queue pushc 7 inv pushm Recv Mate contains an instruction set of 58 instructions, Divided into 3 classes: Simple Class. No arguments. 48 instructions. S-Class. Operates upon message structure. 8 instructions. y y y X-Class. 2 instructions, pushc and blez. y y y y y y Eight instructions are reserved for user definition. Implementation - Capsules Programs are broken up into capsules. Up to 24 instructions in length (fits into single network packet). Includes version and type information. Version specifies whether mote should install packet. Type can be one of four: Send, Receive, Time, or Subroutine. Used to know where to install code. Subroutine capsules allow a program to be larger than a single capsule in size. Eecuted through call and ret instructions. Code infection through use of forw and forwo commands to broadcast capsules. Implementation - Infection Capsule Capsule Mote 2

3 Implementation Sample Program Sample Program: pushc call copy pushc 7 and putled halt Introduction Implementation Evaluation Discussion and Critique pushc add ret Subroutine # 7 Operand Return Evaluation Epressiveness, IIR Evaluation - IIR Tests designed to measure epressiveness, behaviour, and performance of Mate. Epressiveness: BLESS Ad-hoc routing algorithm. Part of TinyOS release, implemented in 6 lines of C code, and in 8 instructions for Mate. Instruction Issue Rate: Different classes of instructions: simple, downcall, quick split, and long split. Overhead of, IPS. Program written that eecutes si simple instructions in loop for five seconds. Instruction Issue Rate (cont): To measure overhead of Mate code over native code, programs were eecuted both natively as well as in Mate code. Instructions that encapsulate higher level TinyOS functionality perform better than those that encapsulate lower level functionality. Approimately /3 of overhead due to separate task for each instruction. Evaluation - Energy Energy: Etra CPU cycles imposed by Mate are costly in terms of energy, but can be offset by the cost of full binary uploads. Given the CPU overhead of Mate, the duty cycle of the application, and the size of the application, it can be decided what is best. GDI eample: if running for < 6 days, Mate is a good alternative. Otherwise, Mate overhead eceeds cost of installing new binary image. Evaluation Infection Part I Network Infection: Network of 42 nodes deployed (34 grid). Transmission radius = 3 hops. Part I: Clock capsule ran every 2 seconds. Node introduced with a self-forwarding forwarding clock capsule. Network monitored every 2 seconds to check the number of nodes running the new clock capsule. Eperiment ran times, averaged results. 3

4 Evaluation Infection Part I Evaluation Infection Part II Network Infection (cont): Part II: Capsules had varying forwarding probability rates and ran once per second. Increasing probability increased rate of infection, but only up to a certain point. Network congestion takes over after that. Evaluation Infection Part II Introduction Implementation Evaluation Discussion and Critique Discussion and Critique Discussion and Critique Mate was designed with old hardware in mind (small stack sizes, single shared variable). Infleible, due to fact that it only eecutes upon three types of events. Eight additional user instructions are part of the binary image of Mate. Language is not high-level. Overhead of instruction eecution is too great. Infection is done through broadcasts, and requires handlers to be coded by application to take care of it. Infection of one mote means infection of possibly all motes. No protection mechanism in terms of evil code could set the version of capsule to its maimum and infect entire network. ASVM fies many of these problems (fleibility, concurrency, and infection). 4

5 Questions?? 5