1 / 60

System Design Issues In Sensor Databases

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/. Wireless Sensor Networks (WSNs). Limited on-node resource Multi-hop communication.

ayame
Download Presentation

System Design Issues In Sensor Databases

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related