Wireless Sensor networks: a data centric overview Politecnico di Milano Joint work with: C. Bolchini F.A. Schreiber other colleagues and students Wireless embedded sensor networks Thousands of tiny low power devices spread over large physical areas monitor the environment, possibly predicting potential faults in buildings, bridges, roads, railways etc. The devices must be small, unobtrusive, and cheap The network must be unexpensive to develop, deploy, program, utilize and maintain 1
A sensor network Comprises a number of sensor nodes and a base station Sensor networks involve three areas: sensing, communications, and computation Applications: Monitoring contaminated land areas or waters Monitoring animal behaviour Fire, earthquake emergencies Vehicle tracking, traffic control Surveillance of city districts, defense related networks, alerts to terroristical threats MOTES: HW Tiny microcontroller-based systems with embedded sensors and wireless communication Key constraints: Battery power Power is the most precious resource: it is often impossible to replace or recharge batteries once a mote has been deployed Limited system resources RAM Processing power Non-volatile storage Bandwidth Software needs to take these into account 2
MOTES: HW (2) Further constraints: May have thousands of nodes Nodes do not have a notion of node proximity Nodes trasmission may intefer with one another: collisions Battery failures Sensor calibration Software needs to take these into account Properties of Sensor Networks Nodes have a general-purpose CPU to perform computation and some storage space Since: communication consumes more energy than computations, and Communication links may break frequently due environmental interferences and noise we want to reduce amount of traffic flow between nodes by local computation. 3
Motes: the Mica2 platform Developed at UC Berkeley Powered by two AA batteries Atmel ATmega128L µc 8 MHz 4KB EEPROM 4KB RAM 128KB Program Flash memory Chipcon CC1000 multichannel radio Range of up to 150-300 m. Motes: the Mica2 platform Mica2Dot Basically same features, smaller size, fewer sensor options Different sensor boards for Mica2 and Mica2Dot 4
Motes: available sensors Part of the Crossbow development kit: MTS310 Sensor Board (for Mica2): includes Acceleration, Magnetic, Light, Temperature, Acoustic sensors. MDA500, Mica2DOT data acquisition board: allows easy access to the microcontroller I/O pins to hook up sensors Other sensors: MTS420A: offers weather monitoring sensors such as humidity, barometric pressure, temperature and light, in addition to a GPS module. MTS500: Weather monitoring module for Mica2DOT: offers temperature, humidity, barometric pressure, and light sensors. SOME NUMBERS NODE TYPE SAMPLE AND SIZE APPLICATION MEMORY OTHER SPECIALIZED SENSING PLATFORM SPEC (mm 3 ) RF tag or specialized sensor 3K RAM GENERIC SENSING PLATFORM MOTE (1-10 c m 3 ) General purpose sensor and commun. 4K RAM 128K FLASH TinyOS HIGH- BANDWIDTH SENSING IMOTE (1-10 c m 3 ) High bandwidth sensor (video, acoustic, etc.) 64KB RAM 512KB FLASH TinyOS, BLUETOOTH, CONNECTIVITY WITH CELL PHONES GATEWAY STARGATE (> 10 c m 3 ) High bandwidth sensor plus gateway <512KB RAM <32MB FLASH LINUX OR WINDOWS, SERIAL CONNECTION TO SENSOR NETWORK 5
A hierarchical architecture A FEW GATEWAY NODES DOZENS OF HIGH BANDWDTH SENSORS HUNDREDS OF GENERIC SENSOR NODES THOUSANDS OF SPECIAL PURPOSE SENSORS TinyDB TinyOS TinyOS TinyOS is a sort of OS, which is simply a library that provides a number of convenient software abstractions, including components to modulate packets over the radio, read sensor values for different sensor hardware, synchronize clocks between a sender and receiver and put the hardware into a low-power state. 6
TinyOS Application = scheduler + graph of components Event-driven architecture Single shared stack NO kernel, process/memory management, virtual memory Downward arrows: Commands Upward arrows: Events TinyOS - Components Commands: Request a service from a component Non-blocking, they post tasks to carry out intensive work Can call lower level commands, but not signal events Events Can call commands, signal events, post tasks Can preempt running tasks Low-level events are triggered by hardware interrupts (e.g. timer) Scheduler No real concurrency, only one task runs at a time Posted tasks are run sequentially in a FIFO fashion Any task runs to completion, but can be preempted by an event Component Commands Tasks Frame Events 7
Languages nesc: extension of the C language aimed at networked embedded systems, such as motes. TinyOS is written in nesc, its structure is closely related to nesc s features Maté: A tiny bytecode interpreter that runs on top of TinyOS. A tiny communication-centric virtual machine designed for sensor networks. An high level interface allowing complex programs to be very short reducing cost of code transmission TinyDB TinyOS nesc used to provide hardware abstraction & interface with TinyDB TinyDB s/w arch of a mote nesc TinyOS 8
SW FSM of a MOTE Snooze/idle Receive Generate/Scan Transmit Network Topology Network Topology Static Dynamic Peer-Peer Parent-Child Aggregation Cluster 9
DB view of sensor networks Traditional: Procedural addressing of individual sensor nodes: user specifies how task is executed, data is processed centrally DB-style approach: Declarative querying: user is not concerned about how the network works : in-network distributed processing TinyDB TinyDB is a query processing system for extracting information from a network of TinyOS sensors. Reduced SQL interface (with some additional constructs) Queries issued from a PC Collects data from motes in the environment, filters it, aggregates it together, and routes it out to a PC Exploits power-efficient in-network processing algorithms. Multiple persistent queries with different sample time 10
Sensor Architecture Sensors Table in ACQP Sensors table is an unbounded, continuous data stream. Physically, the sensors table is partitioned across all of the devices in the network, with each device producing and storing its own readings. Operations such as sort and symmetric join are not allowed on streams. They are allowed on bounded subsets of the stream (windows) Columns are sensor data Rows are individual sensors 11
TinyDB Network Topology: TinyDB manages the underlying radio network by tracking neighbors, maintaining routing tables, and ensuring that every mote in the network can efficiently and (relatively) reliably deliver its data to the user. Incremental Deployment via Query Sharing: To expand a TinyDB sensor network, you simply download the standard TinyDB code to new motes, and TinyDB does the rest. TinyDB motes share queries with each other. No programming or configuration of the new motes is required beyond installing TinyDB. Offers logging capapilities: Logs on PostgreSQL on the base station TinyDB SQL (implements active capabilities) SELECT roomno, AVG(light), AVG(volume) FROM sensors GROUP BY roomno HAVING AVG(light) > l AND AVG(volume) > v EPOCH DURATION 5min ON evttest: SELECT light FROM sensors WHERE light>threshold TRIGGER ACTION SetSnd(512) Fire the query on a defined Event Activate an action, here sounds the beeper The query runs Delivering information Every 5 minutes 12
TinySQL: : Limitations FROM clause must always list exactly one table sensors (unless from flash-logged query) No support for NOT and OR boolean operators in WHERE and HAVING clauses No nested query support Renaming not supported (AS) Reduced Arithmetic expressions (only column op constant) TinySQL: : extensions TRIGGER ACTION clause (optional) specifies an action to be performed after query execution on every mote. EPOCH DURATION <int< int> clause is used to specify time between the repetitions of a query (the query is fired every <int> milliseconds ) On <event>: is used to have a query firing in response to some (hw) event, for example the cross of a threshold of a sensor or packet arrival on the radio. INTO clause is used to log a query into an on-mote flash memory (you can drop it with DROP ALL) 13
How different WSN Queries are from General Queries Sensor data Time stamped Sensors deliver data in streams: they produce data continuously, often at well defined time intervals, without having been explicitly asked for that data. Queries over those streams need to be processed in near real-time Expensive to save all data to disk Data streams represent real-world events (e.g., traffic accidents and attempted network break-ins), which need to be responded to Not all sensor readings are of interest Uncertainty, incomplete information Phases of Power Consumption in TinyDB 14
Some Types of Queries BroadCast Query LandMark Query Aggregation Query Sliding Window Query Event Based Query Life Time Based Query Types of Queries - TinyDB Broadcast Query : The Query from the Root is broadcasted to all the clients in the network irrespective of the architecture with a definite sampling period. root motes 15
Types of Queries - TinyDB SELECT ALL [light, temp] FROM sensors SAMPLE PERIOD 1s FOR 10s Types of Queries (contd) - TinyDB Aggregation Query :The Query from the Root is transmitted to all parent motes and parent motes transmits query to child motes with a definite sampling Period. root Parent Mote Child Mote 16
TinyDB Example SELECT AVG (volume), room_no FROM sensors WHERE floor = 6 GROUP BY room_no HAVING AVG (volume) > threshold SAMPLE PERIOD 30s Types of Queries (contd) - TinyDB Sliding Window Query (Temporal Aggregate) : This is similar to Aggregate Query with sampling interval being divided into windows. SELECT WINAVG (volume, 30s, 5s) FROM sensors SAMPLE PERIOD 1s 17
Types of Queries (contd) - TinyDB Event Based Query: This is an Asynchronous Query mechanism in which events are used as a triggering medium for initiating data collection. ON EVENT bird detect (loc) : SELECT AVG (light), AVG (temp), event.loc FROM sensors AS s WHERE dist (s.loc, event.loc) < 10m SAMPLE PERIOD 2s FOR 30s Types of Queries (contd) - TinyDB Life Time Based Query : This query mechanism runs for definite lifetime and the rate of sampling will be as quick as possible in order to satisfy the goal of data collection. Eg:-If a mote has two ends. Using the lifetime parameter we can use two ends alternatively to decrease rear & tear (improve performance) Exit Point A For first 30 days Parent Mote Child Mote Exit Point B For the next 30 days 18
Types of Queries (contd) - TinyDB SELECT node_id, accel FROM sensors LIFETIME 30 days The above Query will Use exit point A of a parent mote and similar query will Use exit point B (Depending on expiration of Lifetime, TinyOS is responsible for changing the exit points) Response to Queries Parent/Root Child Mote/ Mote 19
Queue Challenges (priority Query) - Overflow When does OverFlow occur? NAIVE : No tuple is considered more valuable than any other, so the queue is drained in a FIFO manner and tuples are dropped if they do not fit in the queue. WINAVG : It works similar to NAIVE, except for the fact that instead of dropping results when the queue fills, the two results at the head of the queue is now an average of multiple records, we associate a count with it. DELTA : When the queue overflows, the packet which has been sent most recently is retrieved and the older packet is discarded. But further useful database functionalities are still lacking One VSDB should reside at least on every generic sensing device (e.g. Mica2) To compose a distributed/federated database Each VSDB should be context aware Each VSDB should be able to appropriately redirect queries to neighbours (P2P) because of an internal fault or a generic unavailability because it does not possess the information because the other node knows something more, in order to complete the information because the other node has a less power-consuming sensor onboard design appropriate, optimized query processing plans (e.g. redirect subquery, cache subquery result, etc.) 20