1 Mate Mate: Architecture Architecture Instruction Set Capsules - - PDF document

1

1

Mate: A Tiny Virtual Machine for Sensor Networks

Philip Levis and David Culler Presented by Mark Tamola CSE 521 Fall 2004

2

Outline

Motivation Mate Code Propagation

Trickle

Simulation Results Conclusions & Critiques

3

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

4

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

5

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

6

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

2

7

Mate

Architecture Instruction Set Execution Code Propagation

8

Mate: Architecture

1 capsule = 24 bytes Capsules Heap

9

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)

10

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)

11

Mate: Instruction Set

12

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

3

13

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

14

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

15

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 Trickle algorithm

16

Trickle

What is it? How is Mate using it?

17

Trickle

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

18

Trickle

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

• ne node and its neighbors allows gossip to

“trickle” through the network, much like a virus infection

4

19

Trickle

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

• therwise, it transmits its metadata

20

Trickle

To start the Trickle 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

21

Trickle

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 τ

22

Trickle

c = 0 k = 2 t = 0 v1.1; t = 3

23

Trickle

I’ve got v1.1

c = 1 k = 2 t = 1 v1.1; t = 3

24

Trickle

c = 1 k = 2 t = 2 v1.1; t = 3

5

25

Trickle

c = 1 k = 2 t = 3 v1.1; t = 3

I’ve got v1.1

26

Trickle

I’ve got v1.1

c = 1 k = 2 t = 4 v1.1; t = 3

27

Trickle

c = 0 k = 2 t = 0 v1.1; t = 3

28

Trickle

I’ve got v1.1

c = 1 k = 2 t = 1 v1.1; t = 3

29

Trickle

I’ve got v1.1

c = 2 k = 2 t = 4 v1.1; t = 3

30

Trickle

c = 1 k = 2 t = 3 v1.1; t = 3

Yay! I don’t need to broadcast!

6

31

Trickle

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

32

Trickle: 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

33

Trickle: Challenges

If the nodes are

unsynchronized, Trickle can suffer from the “short-listen” problem

This also causes

unnecessary transmissions

34

Trickle: Challenges

Trickle was modified slightly to handle the problem

• f 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)

35

Trickle: Challenges

In very dense, multi-

hop networks, Trickle suffers from the “hidden terminal” problem, due to the default CSMA MAC layer of TinyOS

36

Trickle: 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 Trickle counter (c)

7

37

Trickle: Challenges

Fortunately, in practice, τ is usually in the

• rder 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)

38

Trickle: 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 τ

39

Trickle: Challenges

However, since the number of receptions is

much greater than the number of transmissions, the overall network communication is smooth

40

Trickle: Notes

One parameter that can definitely tweak the

performance of Trickle 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

41

Trickle: Notes

42

Trickle: Notes

Remember that a node’s t value is randomly

chosen within τ

8

43

Trickle: 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

44

Simulation Results

Mate’s instruction set incurs the most

• verhead for simple TinyOS operations (i.e.

and, add, etc.)

Complex operations in Mate had almost the

same overhead as TinyOS

45

Simulation Results

46

Simulation Results

The above shows that τH doesn’t play as

much a role as node density & distribution

47

Simulation Results

The above shows that improving capsule

forwarding rate has limited improvement

48

Simulation Results

9

49

Simulation Results

50

Simulation Results

51

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 high-

level functionality into compact bytecodes

52

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)

53

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

54

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 user-

friendly enough for widespread usage

Promise of scalability is hampered by TinyOS’

CSMA MAC layer (hidden terminal problem)

Trickle doesn’t address the problem of load

balancing sufficiently