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 • Motivation • SwissQM • Overview • System Architecture • QM Program • Network • Summary

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

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

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

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

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 • 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)

Overview • SwissQM sensor network • Use 33kB Flash memory and 3kB SRAM

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 • 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 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 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 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 • 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 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 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 • 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

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 • 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 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 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 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 • 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 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 • 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

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

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

CS542 Seminar – Sensor OSThank you for your attention

CS542 Seminar – Sensor OS A Virtual Machine For Sensor Networks