Outline Mate: A Tiny Virtual Machine for Sensor Networks Philip Levis and David Culler Presented by Mark Tamola CSE 521 Fall 2004 Motivation Mate Code Propagation Conclusions & Critiques 1 2 Motivation Sensors deployed in the field must have a way to easily upgrade software on network nodes There could potentially be thousands of nodes to upgrade Nodes are usually physically unreachable, or impractical to try to reach The software download must consume the least amount of energy as possible Applications Monitoring, surveillance applications Sensor nodes may want to change their sampling frequency on the fly May want to create/modify groups of nodes depending on environment to reduce false alarms Structural engineering Sensor network of seismic monitoring nodes have already shown to be useful The same networks can also be useful for other tasks, such as water damage assessment or testing sound propagation 3 4 Challenges Network must be reprogrammed as fast as possible Useful for data aggregation and adaptive query processing Communication is more costly than sensor reading (downloading is expensive) Power to produce << Power to transmit Reprogramming must not require physical contact Mate Mate is one solution to these problems A tiny, embeddable, event-driven virtual machine The VM can be application-specific Interprets compact bytecodes (1 byte) that compress high-level functionality into single instructions Provides a simple, scalable code propagation mechanism 5 6 1
Mate Architecture Instruction Set Execution Code Propagation Mate: Architecture Capsules Heap 1 capsule = 24 bytes 7 8 Mate: Instruction Set VM interprets assembly language -style instructions Suited for a stack-based architecture 3 classes of instructions (basic, s-class, x- class) S-class instructions are specific for manipulating messages for send/receive/monitoring X-class provides one branch instruction, blez (branch on less than or equal to zero) 3 data types (value, message, sensor read) Mate: Instruction Set Each Mate instruction is implemented as a TinyOS task Mate provides 8 user-definable instructions Provides a mechanism for application-specific, high-level instructions Requires the VM to be rebuilt (in fact, any customization to the VM requires a rebuild) Some instructions can be overloaded (i.e. adding two sensor readings vs. adding two messages vs. adding two values) 9 10 Mate: Instruction Set Mate: Execution 3 execution contexts that can run concurrently Clock Send Receive The clock context s operand stack persists across invocations (makes it easy to do timeouts) The clock s frequency and count can be modified from within a Mate program Send and receive contexts stacks are not persistent Data that is sent or received is expected to be specific to the invocation of the context 11 12 2
Mate: Execution Mate s limited addressing modes ensures that contexts cannot encroach on another s space The only shared space available is the single byte heap Mate: Execution A capsule s execution is initiated by an event Clock and receive capsules are initiated by these external events Send capsules are executed by the sendr instruction Execution starts at the first instruction of the capsule and continues until a halt instruction is reached 13 14 Mate: Code Propagation Capsules are always tagged with a version number If the VM receives a newer version of a capsule, Mate will install it The process of how to send a new code version throughout the network is based on the algorithm What is it? How is Mate using it? 15 16 Provides a maintenance protocol for quickly distributing data among many network nodes The algorithm is based on a polite gossip paradigm: I ll only gossip about new things that I ve heard from my neighbors, but I won t repeat gossip I ve already heard, as that would be rude. Using the protocol, code updates trickle through the network; analogous to a virus A node only hears a trickle of the gossip (available code metadata) present in the network & only sends a trickle of the gossip (only among its neighbors) This trickle of information passing between one node and its neighbors allows gossip to trickle through the network, much like a virus infection 17 18 3
New metadata is transmitted periodically by a node Within a node s time period: If a node hears older metadata, it broadcasts the new code If a node hears newer metadata, it broadcasts its own metadata (which will cause other nodes to send the new code) If a node hears the same metadata, it increments a counter if a threshold is reached, the node doesn t transmit its metadata otherwise, it transmits its metadata To start the algorithm, an infected host must initiate the transfer of the new capsule to another node This initiates a chain reaction of infection/transfer for each node The initiating host can become infected via radio transfer from a nearby base station 19 20 3 main parameters for the algorithm: c: count of how many times identical metadata has been heard k: threshold to determine how many times identical metadata must be heard before suppressing transmission of a node s metadata t: the time at which a node will transmit its metadata τ: the total time period; t is a value within τ c = 0 t = 0 21 22 t = 1 t = 2 23 24 4
t = 3 t = 4 25 26 c = 0 t = 0 t = 1 27 28 c = 2 t = 4 t = 3 Yay! I don t need to broadcast! 29 30 5
All of this can happen assuming these ideal conditions: No packet loss Perfect synchronization between time intervals (all have same initial offset) Single-hop network : Challenges In a lossy network, simulations show that the number of transmissions increases by O(log n) Ideally, it would be O(1), with k being the number of transmissions, no matter how many nodes in the neighborhood 31 32 : Challenges If the nodes are unsynchronized, can suffer from the short-listen problem This also causes unnecessary transmissions : Challenges was modified slightly to handle the problem of unsynchronized initial times Instead of picking t from [0, τ], pick the value from [τ/2, τ] Also, suppress transmission for all nodes from [0, τ/2], and only listen during this period This puts an upper bound of 2k on the number of transmissions Again, with the packet loss rate, this makes it 2k*log(n), which is still O(log n) 33 34 : Challenges In very dense, multihop networks, suffers from the hidden terminal problem, due to the default CSMA MAC layer of TinyOS : Challenges Physical density: determined by radio range The hidden terminal problem causes dropped packets, making a cluster of nodes appear less dense than it actually is (Observed density) If Observed density < Physical density, then this increases the number of transmissions, since certain nodes won t be able to transmit in order to increment the counter (c) 35 36 6
: Challenges Fortunately, in practice, τ is usually in the order of tens of minutes, so the likelihood of the network being saturated within this long time period is unlikely The paper says the number of transmissions due to the hidden terminal problem also increases O(log n) : Challenges Load balancing between nodes can also be a problem i.e. We don t want the same node always being the one to transmit within τ 37 38 : Challenges However, since the number of receptions is much greater than the number of transmissions, the overall network communication is smooth : Notes One parameter that can definitely tweak the performance of is τ A high τ incurs more communication overhead, but faster code discovery A low τ has less overhead, but slower code discovery By defining a lower bound, τ L, and an upper bound, τ H, and dynamically scaling between the two, the algorithm can enjoy the best of both worlds 39 40 : Notes : Notes Remember that a node s t value is randomly chosen within τ 41 42 7
: Mate For Mate, the gossip is a list of all capsule version numbers (the code metadata) for a node Mate s capsule update algorithm compares the version numbers between capsules every time a new capsule is transmitted Mate periodically broadcasts the version numbers of all its capsules to the network Mate s instruction set incurs the most overhead for simple TinyOS operations (i.e. and, add, etc.) Complex operations in Mate had almost the same overhead as TinyOS 43 44 The above shows that τ H doesn t play as much a role as node density & distribution 45 46 The above shows that improving capsule forwarding rate has limited improvement 47 48 8
49 50 Conclusions Mate solves the problem of fast & reliable software upgrades for a network of potentially thousands of nodes deployed in the field Mate uses a code propagation algorithm that is able to spread data quickly and efficiently (in a virus-like fashion), regardless of the network size Mate conserves energy by compressing highlevel functionality into compact bytecodes Conclusions Mate truly allows code to be mobile Using the VM, a code propagation mechanism, and some additional switching logic, a node can reprogram itself or reprogram neighboring nodes as needed The concept of bytecodes allows the code to move quickly among network nodes Mate proves that complex network behavior can be achieved by combining building blocks with distinct functionalities (capsules/complete nodes can be these building blocks) 51 52 Conclusions: Future Work Sensor network VM s can enable users to interact directly with the environment and programmatically manipulate and monitor it but in a much simpler way Brings the programming problem into a more familiar, application-specific domain Allows the possibility of Active Sensors: sensors that are smart enough to reprogram themselves as environment changes Critiques Assembly language -style instructions can be frustrating to learn However, Mate now provides a C-like scripting language that compiles into native Mate Customization of instruction set is still not userfriendly enough for widespread usage Promise of scalability is hampered by TinyOS CSMA MAC layer (hidden terminal problem) doesn t address the problem of load balancing sufficiently 53 54 9