A Virtual Machine for Sensor Networks

1. A Virtual Machine for Sensor Networks René Müller , Gustavo Alonso , Donald Kossmann, “A virtual machine for sensor networks”, ACM SIGOPS Operating Systems Review, v.41 n.3, June 2007 이상훈, 허 윤(Dept. of CS)

2. CONTENTS • INTRODUCTION • SYSTEM ARCHITECTURE • NETWORK • CONTRIBUTIONS • DISCUSSION • APPENDEX

3. Power of Virtualization • Convenient Interface

4. Power of Virtualization • Resource Utilization

5. Power of Virtualization • Interoperability

6. INTRODUCTION

7. Background • Wide Variety of Tasks in WSN • Development, Deployment and Maintenance are largelyad-hoc

8. Background • Advantages/Disadvantages of Low-level and High-level

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

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

11. SYSTEM ARCHITECTURE Overall Architecture System Inside QM Program

12. Overall Architecture • WSN with SwissQM

13. System Inside Static Data (To Keep states through invocations) - Raw mode and Managed Mode Incoming and Outgoing Data buffer Compact Code Size Multi-Program Model

14. >Virtual Machine Components • 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

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

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

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

18. Example: Keeping State • EWMA Graph implemented by Six Concurrent QM Program • P0: Raw Light • P4: EWMA Filter • P5: Window Average

19. Example: Keeping State

20. Example: Keeping State

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

22. In-Network DATA PROCESSING

23. Synopsis • 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

24. Merge Instruction • 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 Table 2: Aggregate operations for merge instruction

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

26. Managing Aggregation • 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

27. NETWORK

28. Topology Management • 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)

29. Program Dissemination • QM programs are split into fragment messages • Identification number of program • Enumeration number or fragment Figure 7: Message mapping: fragment messages -> broadcast messages -> TinyOS messages

30. Program Dissemination • 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

31. Experiment Program Distribution • 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 Figure 8: Program coverage during program distribution over time

32. CONTRIBUTION

33. Application-Specific Virtual Machine • Flexible Application Boundary • User-defined Functions • Compact Code Size • By Well-defined Instruction Set • Support Application-specific Function • Data Aggregation • Merge Function

34. Interoperability • Platform Independency

35. Small Footprint • Borrows many ideas from TinyDB, but improved a lot due to the design

36. DISCUSSION

37. cf. What should you come out of your research? • Show your opinion-Wisdom Implication of the conclusion, new insights, new theory, new paradigm Thesis, Doctrine Wisdom To draw conclusion from information Knowledge Report To use data Information Data Outcome of the recording

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

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

40. Pros. • No Evaluation Work • But, RedefineExisting Problem by their own way

41. Pros. • An Aspect of Problem Definition • Dealing with a well-known Problem • But, RedefineExisting Problem by their own way 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

42. Pros. • 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) • Separation between sensors and external interface • Multi-programming environment • Small Footprint • Extensibility • Easy program dissemination • Easy Program Environment • Keeping State • Concurrency • Data Aggregation

43. Ask to discuss • Think of better implication from conclusion of this paper • They see another dimension of availability to meet system requirements(Hardly see trade-off)

44. APPENDEX Instruction Set

45. Instruction Set