Semantics in Sensor Networks

Semantics in Sensor Networks Workshop on Semantics and Future Internet Berlin, 1 Sep 2009 Oscar Corcho Facultad de Informática Universidad Politécnica de Madrid Campus de Montegancedo sn 28660 Boadilla del Monte, Madrid http://www.oeg-upm.net [email_address] Phone: 34.91.3366605 Fax: 34.91.3524819

Sensor Networks
Increasing availability of cheap, robust, deployable sensors as ubiquitous information sources
Dynamic and reactive, but noisy, and unstructured data streams
Source: Antonis Deligiannakis

Parts of a Sensor
Sensing equipment (sensor and data acquisition boards)
Internal (“built-in”) vs external sensing capabilities
CPU
Memory
Battery
Radio to transmit/receive data from other sensors

Some examples of sensors and sensor parts
Maximizing network lifetime is the main target
Cost-effective only if sensor networks last long
Sensor-based applications without power constraints are much easier to handle
Source: Antonis Deligiannakis Passive RFID tag Berkeley Mica2 Stargate (Intel PXA255 cpu) Constraint Battery -- 2 ΑΑ Li-Ion Conserve to increase network lifetime CPU -- 7.38 MHz 400 MHz Computationally cheap algorithms Memory 1Kb 4KB SRAM, 512 KB EEPROM up to 256 MB FLASH Algorithms with low memory requirements Radio A few feet 30 0 μέτρα Depends on radio model Transmission range, bandwidth (bits/sec)

The Sensor Web
Sensor networks may be networked, mostly wireless, hence global and integrated
Universal, web-based access to sensor data
Each network with some kind of authority and administration
Sensor networks vs robust networks
Source: Adapted from Alan Smeaton’s invited talk at ESWC2009

Sensor Web: Is this part of the Web/Internet? Source: SemsorGrid4Env consortium

You haven’t done sensor networks research until...
You have fallen in the river/mud/glacier/...
You have felt the excitement of data arriving. And uncertainty when it stops.
The data has had an impact.
Methodologically, this research must be conducted in the wild.
Well, yes and no: there is a need for all types of research (pure, basic, applied, cross-discipline, etc.)
But the first three bullets have to be kept in mind all the time.
Source: Adapted from Dave de Roure

Energy Constraints
3-5% battery yearly increase
CPU speed increases much faster
However, energy per cpu instruction decreases
Some applications: unattended deployment
Eg: Disaster scenarios, military environments…
Often hard or impossible to replace batteries
Maximizing network lifetime is the main target
Cost-effective only if sensor networks last long
Applications with sensors without power constraints are much easier to handle

Sources of Energy Drain
CPU computations
Measurements from sensing equipments (cost depends on what you sense)
Very small energy consumption in sleep mode
Radio is main source
cost(Transmitting) > cost(Receiving) ≥ cost(idle listening)
Popular goal: reduce #transmitted bits
Synchronization + communication protocols equally important
I.e., cost of transmitting K bits depends on duty cycle (percentage of time sensor is awake to listen for data)
Idle listening for too long is extremely costly

Assumptions and Goals in Subsequent Algorithms
Research Emphasis on more constrained environments
Wireless communication, short transmission ranges
One or more base stations with increased capabilities may exist
Candidates for gateways to the semantic sensor web
Energy limitations (battery powered sensors)
Goal of algorithms:
Preserve Energy
Organize sensors and their schedules
Good schedules allow sensors to power down their radios/cpus and go into a sleep mode
Reduce size of transmitted data
Processing (esp, aggregation) focuses on numeric measurements
Implication of having a strict schedule on when to collect data: base stations knows when quantities are collected
Such metadata may not even need to be transmitted

Who are the end users of sensor networks? Source: Dave de Roure The climate change expert, or a simple citizen

And what do these users want?
Long lived sensors
Real time readings and prediction
Integration across sensors and sensor sources
Events

But why is it worth falling in mud?
Sensor networks address an important set of “grand challenge” Computer Science issues including:
Scale, scalable
Autonomic behaviour versus control
Persistent, heterogeneous, evolving
Holistic approach including information systems
Deployment challenge
Some mobile devices
Source: Dave de Roure

A set of challenges in sensor data management
Provisioning
Complexity of acquisition: distributed sources, data volumes, uncertainty, data quality, incompleteness
Pre-processing incoming data: calibration on instruments (specific), lack of re-grid, calibration, gap-filling features
Tools for data ingestion needed: generic, customizable, provide estimates, uncertainty degree, etc.
Spatial/temporal
Analysis, modeling
Discovery: identify sources, metadata
Data quality: gaps, faulty data, loss, estimates
Analysis models
Republish analytic results, computations,
Workflows for data stream processing
Source: Data Management in the WorldWide Sensor Web. Balazinska et al. IEEE Pervasive Computing, 2007

A set of challenges in sensor data management
Interoperability
Data aggregation/integration
Uncertainty, data quality
Noise, failures, measurement errors, confidence, trust
Distributed processing
High volume, time critical
Fault-tolerance
Load management
Stream processing features
Continuous queries
Live & historical data
Source: Data Management in the WorldWide Sensor Web. Balazinska et al. IEEE Pervasive Computing, 2007

A semantic perspective on these challenges
Sensor data querying and (pre-)processing
Data heterogeneity
Data quality
New inference capabilities required to deal with sensor information
Sensor data model representation and management
For data publication, integration and discovery
Bridging between sensor data and ontological representations for data integration
Ontologies: Observations and measurements, time series, etc.
Event models
User interaction with sensor data

Final Discussion: Hot Topics and Open Problems

Challenges. A 1000-feet architectural perspective http://www.semsorgrid4env.eu/

Challenge 1: Querying and (pre-)processing
For a model of surface water drainage, every 15 minutes, and within 24 hours of their being taken, we wish to obtain time-correlated measurements of the river depth now and the rainfall at the top of the hill 15 minutes before, provided that it is now raining less in the river than it was in the hill top and that the rainfall in the hill top was above 5mm.
Assume that:
sink (0)
river (rain : int, depth : int) at sites (5, 6, 7, 9)
hilltop (rain : int) at sites (4)
Then:
SELECT RSTREAM
river.time, hilltop.rain, river.depth
FROM river[NOW],
hilltop[AT NOW-15 MINUTES]
WHERE hilltop.rain > 5
AND river.rain < hilltop.rain
ACQUISITION RATE=EVERY 15 MINUTES, MAX DELIVERY TIME=24 HOURS
29-30 Sep 2008 SemsorGrid4Env, Kick-Off, Madrid 0 2 1 3 4 5 6 7 8 9

SNEE as a Decision-Making Sequence
Is the query well-formed and well-typed?
Which algebraic translation of the query is, heuristically, most efficient?
Which algorithms will reduce the evaluation cost?
Which physical routes should be used to transport tuples from sources to sink?
Given the logical data flow paths, are there sites where the amount of data flowing through is getting smaller?
Given the transport paths, which sites should get which fragments, given that acquisition, (some) processing and delivery must be carried out in specific places?
Given the space and time estimation models, when should each fragment in each site execute, when should communication take place, and when should the node go to sleep?
Given a target language, how to generate node-specific source code that correctly executes the distributed computation specified in the agenda?
SemsorGrid4Env, Kick-Off, Madrid routing parsing/type checking translation/rewriting algorithm assignment partitioning where-scheduling when-scheduling code generation <query, QoS-expectations>, <schemas, description(node,network), cost parameters> <N 1 , …, N m > nesC code abstract-syntactic tree logical-algebraic form physical-algebraic form PAF routing tree RT fragmented-algebraic form agenda 1 2 3 4 5 6 7 8 RT distributed-algebraic form RT DAF single-site phase multi-site phase

Collecting all data ( SELECT * queries)
Entire network or a subregion, periodically or frequently
Collect aggregates of data
Report AVG, SUM, MAX quantities in an area/network
Data Reduction based on user-specified data quality
In all types of queries: (historical, aggregate…)
Minimize bandwidth based on quality (or the dual problem)
Detecting Outliers
“ Strange” readings: Interesting phenomenon or malfunction?
Joins
Report information based on combined readings of sensors (i.e., report when a lion is close to a deer)
Harder to optimize. Naïve solution of sending potential joining tuples (or projected attributes of them) to base station is often not far from best case

Requires additional information ( metadata ) for collected data
Location/orientation of sensor, time, authority, measured quantities, units, errors etc
Some of them are static, some may change (time, location…)
Additional info may significantly impact volume of transmitted data
Query execution still needs to be optimized within each network
Tradeoff between the logical correctness of results and statistical models
Deliver the right information at the right time

Challenge 2: Sensor Data Modelling and Management
The “easy” part
Agree on a network of sensor network ontologies
Use these ontologies to annotate SensorML readings
Use registries to publish available sensor networks

Challenge 2: Sensor Data Modelling and Management
Data publication and integration
SensorLocation:stored ( id:int , locx:int, locy:int) TreeSensor:sensed ( id:int , ts:time , smoke:boolean, temperature:float, relHumidity:float) SoilSensor:sensed ( id:int , ts:time , moisture:float) WindSensor:sensed ( id:int , ts:time , speed:float, direction:float) RainGauge:sensed ( id:int , ts:time , level:float) Streaming SPARQL, C-SPARQL, etc. Linked Stream Data (ISWC2009 semantic sensor wokshop) http://www.linkeddatastreams.org/sensor/heartrate/1/50.60242,-2.5225/1

Simple Query
SNEEql
RSTREAM SELECT id, speed, direction
FROM wind[NOW];
Streaming SPARQL
PREFIX fire: <http://www.semsorgrid4env.eu/ontologies/fireDetection#>
SELECT ?sensor ?speed ?direction
FROM STREAM <http://…/SensorReadings.rdf> WINDOW RANGE 1 MS SLIDE 1 MS
WHERE {
?sensor a fire:WindSensor;
fire:hasMeasurements ?WindSpeed, ?WindDirection.
?WindSpeed a fire:WindSpeedMeasurement;
fire:hasSpeedValue ?speed;
fire:hasTimestampValue ?wsTime.
?WindDirection a fire:WindDirectionMeasurement;
fire:hasDirectionValue ?direction;
fire:hasTimestampValue ?dirTime.
FILTER (?wsTime == ?dirTime)
}
C-SPARQL
REGISTER QUERY WindSpeedAndDirection AS
PREFIX fire: <http://www.semsorgrid4env.eu/ontologies/fireDetection#>
SELECT ?sensor ?speed ?direction
FROM STREAM <http://…/SensorReadings.rdf> [RANGE 1 MSEC SLIDE 1 MSEC]
WHERE { …
Semantically Integrating Streaming and Stored Data

Challenge 3: User Interaction with Sensor Data Source: SemsorGrid4Env consortium

Vision (after some iterations, and more to come) Source: RWI Working Group on IoT: Networked Knowledge Networked Knowledge Before 2010 2010-2015 2015-2020 Beyond 2020 Today Incremental Incremental-Visionary Visionary Interoperability
Middleware
Sensor ontologies
Intra-network cross-layer integration and optimization
Sensor Internet
Inter-network cross-layer integration and optimization
Information & Context
Relational database integration
Sensor network data warehouses
Stream aggregation
Query processing and reasoning on sensor networks
Event modelling
Database-stream integration
Sensor actuation (In-network processing)
QoS models
QoS-based information integration of DB and streams
Discovery
Centralised non-semantic registries (sensorbase.org)
Semantic discovery of sensors and sensor data
Distributed registries
Sensor network location transparency
Identity & Trust & Privacy
RFID tags
No privacy mgmnt
URIs
User-centric privacy and policies
Virtual sensor networks through dynamic policies
Provenance
Data provenance (where, what and who)
Data transformation processes (how)
Process and problem solving understanding (why)
Problem solving interpretation and explanation

Another list of R&D challenges
Short-term
Sensor network ontologies
Spatio-temporal RDF queries
RDF stream generation (RDB2RDF tools can be “easily” adapted, e.g., R2O/D2R/etc.)
RDF/DB/HTML/Maps Mashup support
Medium-term
Semantic query-based access to sensor networks
In-network processing: real-time SPARQL to [CQL, SNEEql, etc.]
(Ontology-based) relational data and data stream integration
Pay-as-you-go techniques for query planning
Distributed RDF-based query processing and integration
Usability of mashup-supporting technology

Semantics in Sensor Networks Workshop on Semantics and Future Internet Berlin, 1 Sep 2009 Oscar Corcho Facultad de Informática Universidad Politécnica de Madrid Campus de Montegancedo sn 28660 Boadilla del Monte, Madrid http://www.oeg-upm.net [email_address] Phone: 34.91.3366605 Fax: 34.91.3524819

Real World: Where do we talk about this?
Join us at
W3C SSN Incubator Group
rwi.future-internet.eu
OGC Sensor Web Enablement WG
A bunch of (mainly research oriented) workshops
ESWC2009 workshops on stream reasoning and semantic sensor networks
ISWC2009 workshop on semantic sensor networks
Future Internet Symposium series

Development of an integrated information space where new sensor networks can be easily discovered and integrated with existing ones and possibly other data sources (e.g., historical databases),
Rapid development of flexible and user-centric decision support systems that use data from multiple autonomous independently deployed sensor networks and other applications.
SemsorGrid4Env: Objectives http://www.semsorgrid4env.eu Start date: 01/09/2009 Duration: 36 months

SemsorGrid4Env: use cases
Fire Risk Monitoring and Warning in a specific area of Castilla y León
Coastal and Estuarine Flood Warning in Southern UK.

SemsorGrid4Env: Technologies and Expected Results
Distributed RDF-based query processing and integration
Extensions of OGSA-DQP and WS-DAI-RDF
Archival data and data streams ontology-based integration
Sensor network ontologies
Spatio-temporal RDF queries
Query-based access to sensor networks (in-network processing)
SNEEql
Outlier detection algorithms
Mashup support

http://www.slideshare.net	21
http://localhost:8088	2
http://localhost	2
https://bb9.fau.edu	2
http://altarf.dia.fi.upm.es:8088	1
http://www.health.medicbd.com	1
http://static.slidesharecdn.com	1
http://www.linkedin.com	1

Semantics in Sensor Networks

by Oscar Corcho

Accessibility

Categories

Upload Details

Usage Rights

8 Embeds 31

Statistics

Semantics in Sensor Networks Presentation Transcript