System Design Issues In Sensor Databases

1. System Design Issues In Sensor Databases Qiong Luo and Hejun Wu Department of Computer Science and Engineering The Hong Kong University of Science & Technology http://www.cse.ust.hk/

2. Wireless Sensor Networks (WSNs) Limited on-node resource Multi-hop communication Energy efficiency is the most crucial performance factor. SensorDB System Design Issues

3. SELECT avg (light) FROM sensors SAMPLE INTERVAL 60s Avg light: (1000+500)/2 σ,π,α σ,π,α σ,π,α σ,π,α Avg light: 300/1 Scheduler Scheduler Scheduler Scheduler light: 500 Sensing & Networking Sensing & Networking Sensing & Networking Networking Avg light: 1000/1 light: 300 light: 1000 In-Network Sensor Query Processing (Sensor Databases, SensorDBs) SELECT temperature FROM sensors WHERE temperature > 900 SAMPLE INTERVAL 60s sink SensorDB System Design Issues

4. Two Representative SensorDBs • Cougar [BGS01, YG03] • Model sensor network data as sequences • Declarative query interface with UDFs • Cross-layer optimization in later versions • TinyDB [MF+02, 03] • Declarative query interface • Efficient and extensible framework • Open-source implementation on real nodes SensorDB System Design Issues

5. Advantages of Sensor Databases • Flexibility • Declarative SQL style queries • Dynamic query injection and removal • Efficiency • Cross-layer optimization • E.g., in-network filtering and aggregation SensorDB System Design Issues

6. Challenges in Sensor Databases • Dynamic data streams • Hardware resource limitations • Limited per-node computing power and storage • Unreliable wireless communication • Battery power supply • Complex, networked, embedded software • Blurred boundaries between components • Plenty of cross-layer optimization opportunities SensorDB System Design Issues

7. Focus of this Tutorial • System design issues in sensor databases • Software architecture • Operating system support • Media Access Control (MAC) • Routing • Scheduling These issues often dominate the overall performance. SensorDB System Design Issues

8. Outline • Introduction • WSN hardware • Computing, sensing, communication, and power supply • Software architecture • Operating system support • MAC protocols • Routing • Scheduling • Summary and future directions SensorDB System Design Issues

9. Current Sensor Node Hardware: Computing and Storage • Low-power microcontroller (CPU of a node) • E.g., Atmega128 (MICA series), MSP430 (Telos series), ARM/THUMB (XYZ sensor), and the latest 180MHz ARM920 (SunSpot). • Limited memory • RAM • ≤ 10KB SRAM (Static RAM) • ROM • Usually ≤ 1MB flash memory SensorDB System Design Issues

10. Current Sensor Node Hardware: Sensing and Radio • Sensing devices • Electronic, mechanic, bio-chemical, … • Radio transceiver • Fixed radio frequency • Omni-direction radio signal • Transmission rate ≤ 200 kbps • Transmission range ≤ 50 meters SensorDB System Design Issues

11. Current Sensor Node Hardware: Power Supply and Consumption • Power supply • Batteries, usually <= 2000 mAh • Electric currents in a node • Sleep 15-20 µA • Radio on • Idle 20-25 mA, compute 25-30 mA • Radio off • Idle 1-5 mA, compute 5-10 mA Sleeping is the most effective means to save energy. SensorDB System Design Issues

12. Outline • Introduction • WSN hardware • Software architecture • Operating system support • MAC protocols • Routing • Scheduling • Summary and future directions SensorDB System Design Issues

13. Common Software Architecture of Sensor Databases Scheduling Operating System Kernel Boundaries between components in a sensorDB are blurred. SensorDB System Design Issues

14. Outline • Introduction • WSN hardware • Common SensorDB software architecture • Operating system support • Hardware management • Application code development and deployment • MAC protocols • Routing • Scheduling • Summary and future directions SensorDB System Design Issues

15. TinyOS (http://www.tinyos.net/) • De facto OS for sensor nodes • Early research effort • Open source development • Wide presence in commercial products • Component-based architecture • Adaptive to hardware changes • Lightweight for various applications • Event-driven processing • Responsive to sensor signals and radio messages SensorDB System Design Issues

16. TinyOS Application TinyOS startup (“Main”) Runable image of a TinyOS application Application Commands Events Lib components TinyOS interface components Kernel: Core system components Hardware manipulation components Abstraction: Sensor devices Hardware: Mote main board A TinyOS application is compiled with TinyOS components. SensorDB System Design Issues

17. Some Limitations of TinyOS • Static code and memory • No virtual memory • No dynamic memory allocation • No dynamic code update • Task execution without priorities • Single thread TinyOS memory allocation Stack Free Global SensorDB System Design Issues

18. Contiki [DGV04] • Multi-threading • Lightweight program loading • Lightweight communication stacks • uIP • A micro-version of RFC-compliant TCP/IP • Rime • A lightweight communication stack for low-power radio #1 #2 core #3 … #n Multi-threading in Contiki SensorDB System Design Issues

19. Dynamic module loading Allows incremental update of binary code Runtime safety mechanisms Memory monitoring Watchdog Restart when system hangs Jump table 1 Module #1 Module #2 … 2 Module #N SOS Kernel SOS [HK+05] System function call Actual function to call SensorDB System Design Issues

20. Multi-threading Remote testing Scheduler for duty-cycle sleeping Small code size Uses less than 500B RAM and 14KB flash memory MANTIS [BC+05] User threads #1 #n Network Stack Command Server … MANTIS System API Kernel / Scheduler Communication Layer Device driver Sensor Node Hardware SensorDB System Design Issues

21. OS protection Separates OS/app space Virtual memory Extends the limited SRAM Preemptive scheduling Allows priorities Fault tolerance Prevents system hang-up from application errors t-kernel [GS06] Application binary code Load Naturalization Run Running an app. in t-kernel SensorDB System Design Issues

22. Query synopsis Transmission buffer QM programs Bytecode interpreter Operand stack Sensors On-Node Virtual Machines • SunSPOT • A compact Java language • Java VM directly runs in on-node flash memory • SwissQM [MAK07] • Combines a powerful gateway with a virtual machine at the sensors • Query Machine (QM) http://www.sunspotworld.com/ SensorDB System Design Issues

23. Snlog compiler Snlog front-end Execution planner NesC backend Declarative Sensor Networks [CP+07] • Snlog language • Datalog-like, declarative • Suitable for polynomial-time programs • Useful in a variety of apps • Snlog compiler • Translate Snlog into NesC • Runtime system • Components of user provided rules • No on-node interpreter Snlog program nesC Templates DSN runtime components Generated NesC program Binary code to be executed NesC Compiler SensorDB System Design Issues

24. Summary on OS Support • Support app. development and deployment • Programming interfaces • Code compilation and generation • Runtime loading and modification • Provide hardware resource management • Sensor signals, radio messages • Memory allocation and virtualization • Scheduling and system safety SensorDB System Design Issues

25. OS and Sensor Databases • Desirable OS features for sensor databases • Multiple applications • Multi-threading • Virtual memory • Priority scheduling • Reliability and fault tolerance SensorDB System Design Issues

26. Outline • Introduction • WSN hardware • Common SensorDB software architecture • Operating system support • MAC protocols • CSMA, STEM, S-MAC, and T-MAC • Routing • Scheduling • Summary and future directions SensorDB System Design Issues

27. CSMA (Carrier Sense Multiple Access) • Random delay before transmission attempt • Node needs to keep idle listening before its communication done • Wireless collision remains a major problem • Reason: no effective coordination between nodes transmitting Collision Sender 1 transmitting Sender 2 SensorDB System Design Issues

28. Power Listening Listening Listening Transmit Sleep time Sparse Topology and Energy Management (STEM) [STS02] • Periodic wake up and listen • Sleep when no packet to send and receive SensorDB System Design Issues

29. Listen Receiver Sleep SYNC RTS Sender S-MAC (Sensor-MAC) [YHE02] • Schedules nodes to periodically sleep • Coordinates the sleeping time of neighbors for reliable transmission SensorDB System Design Issues

30. T-MAC [DL03] • Contention based protocol • Dynamically ends an active period • Adapts to the needs for computation and communication Active time Sleep time S-MAC Active time Sleep time T-MAC Aha, no more to do!, zzz~ TA SensorDB System Design Issues

31. Summary on MAC • Important for performance • Communication quality • Signal errors • Noise • Communication energy • Sleeping nodes • Retransmission • Communication delay • Negotiation for channels • Wireless signal transmission delay Significant to data quality, energy efficiency and response time in query processing! SensorDB System Design Issues

32. MAC and Sensor Databases • MAC behavior of sensor databases • Mostly converge-cast • Periodic data flows • Opportunities of sensor databases for MAC • Sleep scheduling that suits the data flows SensorDB System Design Issues

33. Outline • Introduction • WSN hardware • Common SensorDB software architecture • Operating system support • MAC protocols • Routing • MintRoute, TinyAODV, and Directed Diffusion • Scheduling • Summary and future directions SensorDB System Design Issues

34. Location-Based Routing • Requires location information • Usually finds the shortest, reliable path using location information of each node • Energy aware • Suitable for queries with spatial predicates • Can route queries to some specific regions D Shortest path S Transmission range of S SensorDB System Design Issues

35. Flooding • Every node broadcasts received data • Broadcast can be reduced by hop count • Advantage • Simple • Problems • Message implosion • Many duplicates • Resource inefficiency • Most nodes busy • No sleeping SensorDB System Design Issues

36. Directed Diffusion [IG+00] • Queries are defined as interests. • Sink nodes post interests. • Source nodes generate sensory data. • Source nodes select reliable and efficient routes to the sink nodes to forward data. SensorDB System Design Issues

37. Illustration of Directed Diffusion Sink node Sink node Step 1: Sink node propagates Interest (query) Step 2: Set up gradients Source node Source node Sink node Step 3: Reinforce one path Source node SensorDB System Design Issues

38. MintRoute [WTC03] • Implemented in TinyOS • Can be used in TinyDB • More than simple shortest-path routing • Monitors link connectivity • Decides a route based on both link quality and distance Unreliable, high loss rate 1 1 2 2 3 3 SensorDB System Design Issues

39. TinyAODV (Tiny Ad-hoc On-Demand Distance Vector) • Builds paths only when needed • Uses sequence number in RREQ to avoid cycles Source Destination RREQ: Route Request … RREP: Route Reply RREQ RREP RERR: Route ERR DATA … X RERR SensorDB System Design Issues

40. Summary on Routing • Focus of current routing protocols • Efficient forwarding • Shortest path or least retransmission • Load balancing • Avoid hot spots of heavy traffic • Open issues • Reliability • Node failure • Noise • Communication delay • Find the path of the minimal delay SensorDB System Design Issues

41. Routing and Sensor Databases • Routing characteristics of sensor databases • Mainly converge-casting • Not all nodes satisfy a query all the time. • Opportunities of sensorDBs for routing • Data flow aware routing • Busy nodes get better routes. • Busy queries get better routes. • Query type aware routing • Aggregation, duplicate-sensitivity, join SensorDB System Design Issues

42. Outline • Introduction • WSN hardware • Common SensorDB software architecture • Operating system support • MAC protocols • Routing • Scheduling • FPS, Sichitiu’s Scheme, and DCS • Summary and future directions SensorDB System Design Issues

43. Lost! Data Goal of Scheduling • Communication efficiency and reliability • Coordinate nodes in communication • Wireless collisions among neighbors • No receiving on sleeping nodes Sending… Done! zzz… zzz… SensorDB System Design Issues

44. Centralized Scheduling • The base station specifies schedules for all nodes. • The base station must be aware of the workload and the network topology • Hard to scale • Hard to adapt to changes Sink Schedule SensorDB System Design Issues

45. Distributed Scheduling • Scheduling in TinyDB (query layer) • A node keeps active for 4 seconds and sleeps in the remaining time in a sample interval. • Sichitiu’s Scheduling Scheme [Sic04] • Schedules at the MAC and routing layers • Sets up both routing paths and schedules • Schedule construction is time consuming and unreliable because it needs the sink to confirm. SensorDB System Design Issues

46. FPS (Flexible Power Scheduling) [HDB04] • Routing-layer distributed scheduling • A parent node assigns transmission slots to its children to avoid collision between siblings. • Collisions among non-sibling neighbors are possible. Slots: Time SensorDB System Design Issues

47. DCS (Distributed Cross-Layer Scheduling) [WLX06] • Slot based • Takes query processing cycles into account • Receiving, computing, transmission, and sleep • Not only parents assign schedules to children, but neighbors also negotiate. • Able to avoid the collisions at the receiving nodes • Attempts to assign consecutive transmission slots to each node SensorDB System Design Issues

48. Scheduling Module Query Layer Query Scheduling Selection / Projection / Join / Aggregation Schedule Execution Routing Layer Route Selection Route Maintenance Schedule Construction MAC Layer Time Synchronization Collision Detection Transmission / Receiving DCS Components SensorDB System Design Issues

49. Slot in a Schedule • A slot is a time period of fixed length. • Transmission, Sleeping, PL/R (Processing, Listening / Receiving), and Q/M (Query injection / route Maintenance) • Slot number s at t: • The length of a slot is ls. • The schedule start time is t0. • A sample interval has m slots. SensorDB System Design Issues

50. Routing tree 0 Transmission PL/R 3 Active (sink only) 1 Q/M An Example Schedule Sleeping 2 Leaf Leaf Sink Hop 0 Hop 1 Node3 Hop 2 Node2 Hop 2 Node 1 0 Time SensorDB System Design Issues