cs542 seminar sensor os a virtual machine for sensor networks n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
CS542 Seminar – Sensor OS A Virtual Machine For Sensor Networks PowerPoint Presentation
Download Presentation
CS542 Seminar – Sensor OS A Virtual Machine For Sensor Networks

Loading in 2 Seconds...

play fullscreen
1 / 33

CS542 Seminar – Sensor OS A Virtual Machine For Sensor Networks - PowerPoint PPT Presentation


  • 91 Views
  • Uploaded on

CS542 Seminar – Sensor OS A Virtual Machine For Sensor Networks. R. Muller, G. Alonso, and D. Kossmann. Oct. 28, 2009 Seok Kim Eugene Seo. Contents. Motivation SwissQM Overview System Architecture QM Program Network Summary. Motivation. Introduction

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'CS542 Seminar – Sensor OS A Virtual Machine For Sensor Networks' - josef


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
cs542 seminar sensor os a virtual machine for sensor networks

CS542 Seminar – Sensor OSA Virtual Machine For Sensor Networks

R. Muller, G. Alonso, and D. Kossmann

Oct. 28, 2009

Seok Kim

Eugene Seo

contents
Contents
  • Motivation
  • SwissQM
    • Overview
    • System Architecture
    • QM Program
    • Network
  • Summary
motivation
Motivation
  • Introduction
    • Wireless sensor networks are increasingly being used today.
    • Re-programming sensor networks is difficult.
  • TinyOS
    • Integrate OS and application as single unit

Application

OS

motivation1
Motivation
  • Surge
    • Basic application
      • Sample one specific sensor periodically and send it to a sink node
  • Low level abstraction
    • nesC code

Parameter or Program

task void SendData()

{SurgeMsg *pReading;    uint16_t Len;dbg(DBG_USR1, "SurgeM: Sending sensor reading\n");  if (pReading = call Send.getBuffer(&gBuffer,&Len))

{

:

: }

 }

App.

OS

motivation2
Motivation
  • Surge
    • Basic application
      • Sample one specific sensor periodically and send it to a sink node
  • Low level abstraction
    • Advantage
      • Efficiency
      • Full control of the node
    • Disadvantage
      • Platform dependent
      • Limited update at runtime
      • Expensive reprogramming of whole application

Parameter or Program

App.

OS

motivation3
Motivation
  • TinyDB
    • Use a declarative system
      • Data acquisition task expressed as a query
  • High level abstraction
    • SQL-like Query
    • Query Processor (QP)
      • Use table

Query

SELECT nodeid FROM sensors

WHERE light>100

SAMPLE PERIOD 30s

QP

OS

motivation4
Motivation
  • TinyDB
    • Use a declarative system
      • Data acquisition task expressed as a query
  • High level abstraction
    • Advantage
      • Platform independent
      • Change query  Change application
    • Disadvantage
      • Too abstract
      • Limited expressiveness

Query

QP

OS

overview
Overview
  • Main idea
    • User interface
      • Language independent
    • Gateway
      • Do everything that can be done at the gateway
        • The sensors only process capturing, aggregating, forwarding data.
    • Program processing
      • Increase of concurrency limit
    • Network
      • Reduction of messages sent in the network
  • Solution
    • Use virtual machine (VM) at sensor node
      • SwissQM (Scalable WirelesS Sensor network Query Machine)
overview1
Overview
  • SwissQM sensor network
    • Use 33kB Flash memory and 3kB SRAM
overview2
Overview
  • SwissQM virtual machine
    • VM is on each sensor node
  • QM program
    • Bytecode: set of instructions
  • VM instruction set
    • Provide 59 instructions
      • 40 VM instructions (stack, arithmetic, control)
      • 19 core instructions (buffer, sensor, transmission)
system architecture
System Architecture
  • Convert of the query language
    • Advantage
      • Easy to extend the number of supported query language
      • Reduce the workload of sensor compared to TinyDB

Query Type1

Query Type2

Translation

Translation

Various Queries

Virtual Query

Virtual Query

QM Program

Gateway

Query Complier,

Query Optimiser

QM Program

system architecture1
System Architecture
  • Bytecode interpreter
    • Execute code section
  • Operand stack
    • Store the operands of its bytecode instructions
  • Transmission buffer (array)
    • Buffer the data received and sent
  • Synopsis (table)
    • Store the aggregation state
    • Merge the data from its children and itself
  • SwissQM on the sensor node
  • Integer-based virtual machine
  • Components
system architecture2
System Architecture
  • 33kB Flash memory
  • 3kB SRAM

: Bytecode interpreter & static memory allocator

23kB

10kB

16 byte

64 byte

384 byte

16 byte

16 byte

Sampling period, Length of the program,point to the program’s data structure, …

system architecture3
System Architecture
  • QM program structure
    • .section init
      • Initialize QM program when the QM program is loaded
    • .section delivery
      • Is invoked periodically
    • .section reception
      • Is called when data received from children node
example 1 basic sampling and sending
Example 1: Basic Sampling and Sending
  • Query:
  • SELECT s.nodeid FROM sensors
  • WHERE temp > 60
  • SAMPLE PERIOD 10s

Event:

Timer fires

Transmission buffer:

  • QM program:
  • section delivery, “@10s”
  • get_temp # read temperature sensor
  • ipushb 60
  • if_icmple end # skip if temp<=60
  • get_nodeid # read node’s ID
  • istore 0 # store it at pos. 0
  • send_tb # send transmission buffer
  • end:
  • .section reception
  • send_tb # forward tuple from child

Stack:

example 1 basic sampling and sending1
Example 1: Basic Sampling and Sending
  • Query:
  • SELECT s.nodeid FROM sensors
  • WHERE temp > 60
  • SAMPLE PERIOD 10s

Event:

Transmission buffer:

  • QM program:
  • section delivery, “@10s”
  • get_temp # read temperature sensor
  • ipushb 60
  • if_icmple end # skip if temp<=60
  • get_nodeid # read node’s ID
  • istore 0 # store it at pos. 0
  • send_tb # send transmission buffer
  • end:
  • .section reception
  • send_tb # forward tuple from child

Stack:

example 1 basic sampling and sending2
Example 1: Basic Sampling and Sending
  • Query:
  • SELECT s.nodeid FROM sensors
  • WHERE temp > 60
  • SAMPLE PERIOD 10s

Event:

Transmission buffer:

  • QM program:
  • section delivery, “@10s”
  • get_temp # read temperature sensor
  • ipushb 60
  • if_icmple end # skip if temp<=60
  • get_nodeid # read node’s ID
  • istore 0 # store it at pos. 0
  • send_tb # send transmission buffer
  • end:
  • .section reception
  • send_tb # forward tuple from child

Stack:

example 1 basic sampling and sending3
Example 1: Basic Sampling and Sending
  • Query:
  • SELECT s.nodeid FROM sensors
  • WHERE temp > 60
  • SAMPLE PERIOD 10s

Event:

Transmission buffer:

  • QM program:
  • section delivery, “@10s”
  • get_temp # read temperature sensor
  • ipushb 60
  • if_icmple end # skip if temp<=60
  • get_nodeid # read node’s ID
  • istore 0 # store it at pos. 0
  • send_tb # send transmission buffer
  • end:
  • .section reception
  • send_tb # forward tuple from child

Stack:

example 1 basic sampling and sending4
Example 1: Basic Sampling and Sending
  • Query:
  • SELECT s.nodeid FROM sensors
  • WHERE temp > 60
  • SAMPLE PERIOD 10s

Event:

Transmission buffer:

  • QM program:
  • section delivery, “@10s”
  • get_temp # read temperature sensor
  • ipushb 60
  • if_icmple end # skip if temp<=60
  • get_nodeid # read node’s ID
  • istore 0 # store it at pos. 0
  • send_tb # send transmission buffer
  • end:
  • .section reception
  • send_tb # forward tuple from child

Stack:

example 1 basic sampling and sending5
Example 1: Basic Sampling and Sending
  • Query:
  • SELECT s.nodeid FROM sensors
  • WHERE temp > 60
  • SAMPLE PERIOD 10s

Event:

Transmission buffer:

  • QM program:
  • section delivery, “@10s”
  • get_temp # read temperature sensor
  • ipushb 60
  • if_icmple end # skip if temp<=60
  • get_nodeid # read node’s ID
  • istore 0 # store it at pos. 0
  • send_tb # send transmission buffer
  • end:
  • .section reception
  • send_tb # forward tuple from child

Stack:

example 1 basic sampling and sending6
Example 1: Basic Sampling and Sending
  • Query:
  • SELECT s.nodeid FROM sensors
  • WHERE temp > 60
  • SAMPLE PERIOD 10s

Event:

Transmission

Transmission buffer:

  • QM program:
  • section delivery, “@10s”
  • get_temp # read temperature sensor
  • ipushb 60
  • if_icmple end # skip if temp<=60
  • get_nodeid # read node’s ID
  • istore 0 # store it at pos. 0
  • send_tb # send transmission buffer
  • end:
  • .section reception
  • send_tb # forward tuple from child

Stack:

network
Network
  • Messaging in the Network
    • Message Types
      • Program Messages
      • Result Messages
      • Command Messages (Node Reset, Program Stop,…)
    • Traffic Pattern
      • Root to all
        • Program and Command Messages
      • All to Root
        • Result Messages
      • Local Broadcasts
        • Routing updates and time synchronization
network1
Network
  • Routing of Result Messages
    • Topology
      • Spanning tree protocol
        • Every node keeps a link to a parent node closer to the root
      • Link quality calculation
    • Clock synchronization
      • Piggybacking
        • Routing message contains timestamp
          • Set clock with timestamp – transmission delay
in network aggregation
In-network Aggregation
  • Reduce the number of messages sent to the gateway
    • Ex) What is the average temperature in the network?

Basic transmission

Aggregation result

48

<137, 3>

<45, 1>

44

<44, 1>

45

# of message: 3

# of message: 5

in network aggregation1
In-network Aggregation
  • In-network Aggregation in SwissQM
    • Use the synopsis, translation buffer, and merge instruction
    • Use TAG Approach (Tiny Aggregation)
      • Initialiser function
        • Create the initial aggregation state on the synopsis
      • Merger function
        • Merge its own state with the aggregation states received from its children
      • Finaliser function
        • Computes the final value of the aggregation
merge function
Merge Function
  • Merge Instruction
    • Invoke the merge function in stack
    • Structure
      • merge( n, m, aggop1, . . . , aggopm )
        • n : Grouping Expressions
        • m : Aggregate Expressions
        • aggop : aggregate operation
    • Push arguments on stack in the reverse order
    • Example

.section reception

iconst_2 # aggregate type MAX=2

iconst_1 # num. of aggregate expressions

iconst_1 # num. of group expressions

merge

< 1, 1, MAX >

merge function1
Merge Function
  • Merge operation
    • Merging aggregation state from the transmission buffer to the local synopsis
    • Example
      • The merge operation of node 2 when node 2 receives the synopsis of node 3
program dissemination
Program Dissemination
  • Fragment messages approach
    • Split into several fragment messages.
    • 24 bytes Fragment
      • Fragment 0
        • 10 bytes meta-data
          • The length of the sections
          • Sampling period
          • Presence of synopsis
          • Number of fragment
    • Sensor
      • Allocate memory when it receives fragment 0
program dissemination1
Program Dissemination
  • Fragment recovery mechanism
    • Timeout for program reception
      • Request node
        • Timer starts when first fragment message is successfully received
        • When this timer times out, request message to its neighbors
          • Contains the program ID and the missing fragments
      • Reply node
        • Generate the requested fragments when it receives request message
        • Send the reply message back to the requesting node.
experiments
Experiments
  • Compare the program sizes of TinyDB and SwissQM for the queries generating the same data
    • SwissQM not only users less messages, but also smaller messages than TinyDB
slide31
Pros
  • Characteristics
    • Separation between sensors and external interface
      • Language-independent
      • No application specific functionality in sensors
    • Multi-programming environment
      • Running of six different programs concurrently on a single node
    • Optimization of the use of the sensors
      • Three kinds of process; capturing, aggregating, and forwarding data.
    • Extensibility
      • Support of the use of the user defined functions
    • Easy program dissemination
      • Compact programs due to the powerful instruction set
slide32
Cons
  • System problem
    • Is not suite to the networks in which many point-to-point streams are dynamically created between sensors
    • interpretation overhead are required
  • Documentary problem
    • No mention about
      • The technical issue of the bytecode instruction set extension
      • Reprogramming technology the proposed virtual machine model uses
    • Too little evaluations on the performance
      • Require long-term experiment to evaluate the performance to run SwissQM compared with the other low-level abstraction program or TinyDB itself
      • Require evaluation of whether SwissQM is the platform-independent