이상훈, 허 윤 (dept. of cs) rené müller, gustavo alonso, donald kossmann, “a virtual...

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 GAP

GAP

SYSTEM ARCHITEC-TURE

Overall Architecture System Inside

QM Program

12

WSN with SwissQM

Overall 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: Merge

PreparingTR 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

information 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 infor-mation◦ Avoids the cost of separate time-synchronization

message◦ Timestamp of received message minus an aver-

age 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 identi-

fier 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 TinyDB

Core 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

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

41

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

42

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

44

Instruction Set