1. 이상훈, 허 윤 (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 2

3.  Convenient Interface 3

4.  Resource Utilization 4

5.  Interoperability 5

7.  Wide Variety of Tasks in WSN  Development, Deployment and Maintenance are largely ad-hoc 7

8. Low-level ProgrammingHigh-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 8  Advantages/Disadvantages of Low-level and High-level

9. 9 Full Controllable But, less SW abstraction Good Abstraction, But, insufficient expressiveness and extensibility Low-level ProgrammingHigh-level Programming Take advantage of low-level featuresTake advantage of high-level features GAP Reprogramming is expensive Programming is cumbersome Existing approach is less extensible and expressive Reprogramming is expensive Programming is cumbersome Existing approach is less extensible and expressive

10. 10 Full Controllable But, less SW abstraction Good Abstraction, But, insufficient expressiveness and extensibility Low-level ProgrammingHigh-level Programming SwissQM can fill the GAP GAP

11. Overall Architecture System Inside QM Program

12.  WSN with SwissQM 12

13. 13 Compact Code Size Static Data (To Keep states through invocations) - Raw mode and Managed Mode Static Data (To Keep states through invocations) - Raw mode and Managed Mode Multi-Program Model Incoming and Outgoing 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 14 >Virtual Machine

15.  program descriptors ◦ QM Bytecode ◦ Stack ◦ Synopsis ◦ Transmission buffer  Static Memory Allcocation ◦ Gateway program admission control. 15

16.  JVM Instructions ◦ Essential Instructions  SwissQM “core” Instructions: ◦ Buffer / Sensor / Sysnopsis  Application-specific ◦ In-network Data Aggregation (merge) 16

17.  Consist 3 Code Sections ◦ Init  When the program is loaded ◦ Delivery  When time period is due ◦ Reception  When a message is received 17

18.  EWMA Graph implemented by Six Concurrent QM Program ◦ P 0 : Raw Light ◦ P 4 : EWMA Filter ◦ P 5 : Window Average 18

19. 19

20. 20

21. 21 Preparing TR buffer for Merge Preparing TR buffer for Merge Parameter of Merge Function

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 23

24.  Express a complex operation with a single bytecode instruction  Parameterized instruction implements the aggregate operations  Aggregation involves three functions ◦ Initialiser  Create initial aggregation state ◦ Merger  Merge with the aggregation state ◦ Finalizer  Computes the final value of the aggregation 24 Table 2: Aggregate operations for merge instruction

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 25 Figure 6: Merging aggregation state from the transmission buffer to the local synopsis

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 26

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 information ◦ Avoids the cost of separate time-synchronization message ◦ Timestamp of received message minus an average transmission delay (18 ms ) 28

29.  QM programs are split into fragment messages ◦ Identification number of program ◦ Enumeration number or fragment 29 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 30

31.  Run in the TinyOS simulator  Measure time for program distribution which fits into a single message  Best case: all nodes get in about 5 seconds  Worst case: only 2% of nodes get and 53.6 seconds 31 Figure 8: Program coverage during program distribution over time

33.  Flexible Application Boundary ◦ User-defined Functions  Compact Code Size ◦ By Well-defined Instruction Set  Support Application- specific Function ◦ Data Aggregation ◦ Merge Function 33

34.  Platform Independency 34

35.  Borrows many ideas from TinyDB, but improved a lot due to the design 35 SwissQMTinyDB Core size 33kB Flash 3kB SRAM 65kB Flash 3kB SRAM Message size 36 bytes49 bytes Expressio ns in query Translated to a short sequence of bytecode instructions (Short message) Part of query evaluation (Long message)

37.  Show your opinion-Wisdom 37 Thesis, Doctrine Report Wisdom Implication of the conclusion, new insights, new theory, new paradigm Knowledge To draw conclusion from information Information To use data Data Outcome of the recording

38.  Authors’ Conclusion ◦ Filling the Gap between  Low-level and High-level layers ◦ etc.  Flexibility  Eases Program Dissemination 38

39.  Beyond Conclusion ◦ There is no discussion session ◦ No implication, No insights  cf. Mate Case 39

40.  An Aspect of Problem Definition ◦ Dealing with a well-known Problem ◦ But, Redefine Existing Problem by their own way 40 Philip Levis, David Culler, Maté: a tiny virtual machine for sensor networks, 10th annual conference on Architectural 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) 41 Separation between sensors and external interface Multi-programming environment Small Footprint Extensibility Easy program dissemination Easy Program Environment Separation between sensors and external interface Multi-programming environment Small Footprint Extensibility Easy program dissemination Easy Program Environment Keeping State Concurrency Data Aggregation 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) 42

43. Instruction Set

44. 44