A Virtual Machine for Sensor Net-works

이상훈 , 허 윤 (Dept. of CS)

René Müller , Gustavo Alonso , Donald Kossmann, “A virtual machine for sensor networks”, ACM

SIGOPS Operating Systems Review, v.41 n.3, June 2007

2

INTRODUCTION SYSTEM ARCHITECTURE NETWORK CONTRIBUTIONS DISCUSSION APPENDEX

CONTENTS

3

Convenient Interface

Power of Virtualization

4

Resource Utilization

Power of Virtualization

5

Interoperability

Power of Virtualization

INTRODUCTION

7

Wide Variety of Tasks in WSN Development, Deployment and Main-tenance are largely ad-hoc

Background

8

Low-level Programming High-level Programming

Adv. • Full flexibility• Full control of the node

• Platform independent• Declarative Approach• Queries relatively small • Reprogrammable - Cheap Update

Dis. • Cumbersome to program• Strongly Platform dependent• Lack of Reprogrammability - update = binary image

• Limited Expressiveness and Extensibility - none of user-defined function - based on query language after all

Background Advantages/Disadvantages of Low-level and High-

level

9

Problem Definition

Full Controllable

But, less SW ab-straction

Good Abstraction,

But, insufficient expressiveness and extensibility

Low-level Programming High-level Programming

Take advantage of low-level features Take advantage of high-level features

GAP• Reprogramming is expensive

• Programming is cumbersome • Existing approach is less extensible and expressive

10

Solution Approach

Full Controllable

But, less SW abstraction

Good Abstraction,

But, insufficient expressiveness

and extensibility

Low-level Programming High-level Programming

SwissQM canfill the GAPGAP

SYSTEM ARCHITEC-TURE

Overall Architecture System Inside

QM Program

12

WSN with SwissQMOverall Architecture

13

System Inside

Compact Code Size

Static Data (To Keep states through invocations)

- Raw mode and Managed Mode

Multi-Program Model

Incoming and Out-going Data buffer

14

Bytecode Interpreter Operand Stack Transmission buffer

◦ For Incoming and Outgoing Data◦ Application Specific Feature?

Synopsis◦ A table used for data aggregation◦ To keep state between different invocations of

the same program

Components >Virtual Machine

15

program descriptors◦ QM Bytecode◦ Stack ◦ Synopsis ◦ Transmission buffer

Static Memory All-cocation◦ Gateway program

admission control.

Memory Layout

16

JVM Instructions◦ Essential Instructions

SwissQM “core” In-structions:◦ Buffer / Sensor /

Sysnopsis Application-specific

◦ In-network Data Ag-gregation(merge)

Instruction Set

17

Consist 3 Code Sections◦ Init

When the program is loaded◦ Delivery

When time period is due◦ Reception

When a message is received

Code Execution

18

EWMA Graph imple-mented by Six Concur-rent QM Program◦ P0: Raw Light◦ P4: EWMA Filter◦ P5: Window Average

Example: Keeping State

19

Example: Keeping State

20

Example: Keeping State

21

Example: MergePreparing

TR buffer for Merge

Parameter of Merge Function

In-Network DATA PROCESSING

23

A fixed size buffer of 16 bytes Two ways of usage

◦ Raw mode An array of 16-bit elements(transition buffer) Accessed over an element index Load/store data from/into synopsis

iload_sy and istore_sy◦ Managed mode

Accessed through the merger Combines data from transfer buffer with the synopsis

Synopsis

24

Express a complex operation with a single bytecode in-struction

Parameterized instruction implements the aggregate opera-tions

Aggregation involves three functions◦ Initialiser

Create initial aggregation state◦ Merger

Merge with the aggregation state ◦ Finalizer

Computes the final value of the aggregation

Merge Instruction

Table 2: Aggregate operations for merge in-struction

25

Return the maximum light value among all nodes have the same parent node

Intermediate nodes send a synopsis includes◦ Own parent and light value◦ Pair node ID

Merge Example

Figure 6: Merging aggregation state from the transmission buffer to the local synop-sis

26

Delivery section only for synopsis sending◦ Deeper node must be scheduled to activate earlier

than parent Position recognition by constant exchange of routing in-

formation Use simple algorithm for schedule shifting

In case of a node running out of space and not able to store the aggregation state◦ Merge operation notice a full synopsis and forwards ◦ Perform final aggregation at the gateway

Reduces the number of messages invoked by nodes at lower layers

Managing Aggregation

NETWORK

28

Using Mint routing protocol A link quality estimator based on

WMEWMA(window mean with exponential weighted moving average)of the success rate

Embedding of clock synchronization informa-tion◦ Avoids the cost of separate time-synchronization

message◦ Timestamp of received message minus an average

transmission delay (18 ms)

Topology Management

29

QM programs are split into fragment mes-sages◦ Identification number of program◦ Enumeration number or fragment

Program Dissemination

Figure 7: Message mapping: fragment messages -> broadcast messages -> TinyOS messages

30

Two mechanisms for message lost◦ Timeout for program reception

Compute number of outstanding fragments Allocate dynamic program structures on the heap and start

timer Send a “program request” message to neighbor and

restarts timer Includes program ID and bit-mask encoded missing fragment

Generate requested fragment Sends fragment in a “program reply” message

◦ Snooping result messages Snoop for lately joined node and judge by program identifier Request for all fragments

Program Dissemination

31

Run in the TinyOS simulator Measure time for program distribution which fits into a sin-

gle message Best case: all nodes get in about 5 seconds Worst case: only 2% of nodes get and 53.6 seconds

Experiment Program Distribu-tion

Figure 8: Program coverage during program distribution over time

CONTRIBUTION

33

Flexible Application Boundary◦ User-defined Functions

Compact Code Size◦ By Well-defined Instruc-

tion Set Support Application-

specific Function ◦ Data Aggregation◦ Merge Function

Application-Specific Virtual Ma-chine

34

Platform Independency

Interoperability

35

Borrows many ideas from TinyDB, but improved a lot due to the design

Small Footprint

SwissQM TinyDBCore size

33kB Flash3kB SRAM

65kB Flash3kB SRAM

Message size 36 bytes 49 bytes

Expressions in query

Translated to a short

sequence of bytecode

instructions(Short

message)

Part of query

evaluation(Long

message)

DISCUSSION

37

Show your opinion-Wisdom

cf. What should you come out of your research?

Thesis,Doctrine

Report

Wisdom

Implication of the con-clusion, new insights,

new theory, new para-digm

KnowledgeTo draw conclusion from

information

InformationTo use data

DataOutcome of the recording

38

Authors’ Conclusion◦Filling the Gap between Low-level and High-level layers

◦etc. Flexibility Eases Program Dissemination

Conclusion

39

Beyond Conclusion◦ There is no discussion session◦ No implication, No insights

cf. Mate Case

Cons.

40

No Evaluation Work◦ But, Redefine Existing Problem by their own

way

Pros.

41

An Aspect of Problem Definition◦ Dealing with a well-known Problem

◦ But, Redefine Existing Problem by their own way

Pros.

Philip Levis, David Culler, Maté: a tiny virtual machine for sensor networks, 10th annual conference on Architec-tural Support for Programming Languages and Operating

Systems , Pages: 85 – 95, 2002

42

Introduce remarkable contribution with negligible trade-off

Easy to understand by Examples◦ Describing their program architecture by introducing highly relevant and

practical examples◦ Easily Motivate readers to understand System Architecture (and Even the

Need for system)

Pros.

• Separation between sensors and external inter-face

• Multi-programming environment• Small Footprint• Extensibility• Easy program dissemination• Easy Program Environment

• Keeping State• Concurrency• Data Aggregation

43

Think of better implication from conclusion of this paper◦ They see another dimension of availability

to meet system requirements(Hardly see trade-off)

Ask to discuss

APPENDEXInstruction Set

45

Instruction Set