an overview of data management in pervasive systems fabio a

AN OVERVIEW OF DATA MANAGEMENT IN PERVASIVE SYSTEMS FABIO A. SCHREIBER ROMOLO CAMPLANI

Politecnico di Milano

Dipartimento di Elettronica ed Informazione

Schreiber - Camplani An Overview of Data Management in Pervasive Systems

OUTLINE 1

ABSTRACTING WIRELESS SENSOR NETWORKS FROM THE PHYSICAL TO THE CONCEPTUAL LEVEL

PERVASIVE SYSTEMS REVIEW RFID WIRELESS SENSOR NETWORKS

PERVASIVE SYSTEMS AND APPLICATIONS: MOVING FROM REACTIVE TO PROACTIVE FEATURES THE ROLE OF CONTEXT IN DATA MANAGEMENT


PERVASIVE SYSTEMS 2

THE COMPUTER BECOMES PART OF THE INFRASTRUCTURE THE MIDDLEWARE OF A PERVASIVE SYSTEM HIDES THE

HETEROGENEITY OF HUNDREDS OF DEVICES MAKING THEM TRANSPARENT TO THE APPLICATION

THE PERCEPTION OF THE ENVIRONMENT MAKES THE SYSTEM AUTONOMIC AND PROACTIVE CONTEXT-AWARE REACTIVE SELF-ADAPTING


3

PERVASIVE PER – VADERE

THROUGH TO GO

Webster Dictionary TO PERVADE, TO PERMEATE TO BE DIFFUSED THROUGHOUT

Devoto – Oli Dictionary (translated from Italian) ABLE TO DIFFUSE IN DOMAINS AND ASPECTS WHICH

WERE ONCE ALIENS TO DIFFUSE IN ORDER TO MODIFY AND CHARACTERIZE

THE ATMOSPHERE OR THE PHYSIOGNOMY OF A WHOLE DETERMINED AMBIENT

PERVASIVE


DATA MANAGEMENT SYSTEMS AND ARCHITECTURES

4

DISTRIBUTED

UBIQUITOUS

MOBILE

CENTRALIZED

PERVASIVE


PERVASIVE SYSTEMS COMPONENTS 5

APPLICATION DOMAINS

… …

MIDDLEWARE AND SERVICES

PERVASIVE INFORMATION SYSTEM

ENABLING TECHNOLOGIES

DEVICES TRANSMISSION NETWORKING


PERVASIVE SYSTEMS IN REAL WORLD: WIRELESS SENSOR NETWORKS

6

WIRELESS SENSOR NETWORKS (WSN) CONSTITUTE THE BACKBONE OF PERVASIVE SYSTEMS

COMPONENTS THOUSANDS OF TINY LOW POWER DEVICES SPREAD OVER

(POSSIBLY LARGE) PHYSICAL AREAS

THE DEVICES MUST BE SMALL, UNOBTRUSIVE, AND CHEAP

NETWORK

THE NETWORK MUST BE UNEXPENSIVE TO DEVELOP, DEPLOY, PROGRAM, AND EASY TO UTILIZE AND MAINTAIN

COMPRISE A NUMBER OF SENSOR NODES AND A BASE STATION



THE WSN AS A DATABASE 7

DATABASE ALARM GENERATION

NETWORK AS DATA PROCESSOR

NETWORK AS DATA STORAGE

(DATA STREAMS)

SENSORS

DATA ANALYSIS TOOLS (dw, dm, …)

THRESHOLDS

INFORMATION

SYSTEM


WSN CONCEPTUALIZATION PROBLEMS 8

HIDING THE DEVICES HETEROGENEITY TO THE APPLICATION USER

USING A HIGH-LEVEL DECLARATIVE LANGUAGE TO SEND QUERIES AND COMMANDS TO THE DEVICES


A REAL LIFE SENSOR DATA SHEET 9

Functional attributes

Non Functional Attributes


ABSTRACTING PHYSICAL DEVICES 10

Generic meta-device [Non Functional Attributes + unique placeholder for Functional Attributes]

Meta-device [NFA + FA of each sensor type (light, humidity, etc.)]

Device specification

System requirements

[value ranges specification for NFA e FA] 5 gr<w<10gr, …, -40°C<T<+85°C, …

Physical device

Manufacturer data sheets

[device identification (Manuf., part no., cost, etc.)] MicroStrain, TC-Link®-1CH-LXRS™, xx $, ….

Schema-level


ABSTRACTING PHYSICAL DEVICES: AN XML DTD (1)

11

<!ELEMENT gmd: GenericMetaDevice (gmd: weight, gmd: size, gmd: MTBF, gmd: envcond, gmd: precision, gmd: metadevice) – non functional properties of every metadevice-- > <!ELEMENT gmd: weight (#PCDATA)> <!ELEMENT gmd: size (gmd: length, gmd: width, gmd: height)> <!ELEMENT gmd: length (#PCDATA)> <!ELEMENT gmd: width (#PCDATA)> <!ELEMENT gmd: height (#PCDATA)> <!ELEMENT gmd: MTBF (#PCDATA)> <!ELEMENT gmd: precision (#PCDATA)> ………………………………………….

<!ELEMENT gmd: envcond (gmd: tempmax, gmd: tempmin, gmd: relhummax, gmd: relhummin)> <!ELEMENT gmd: tempmax (#PCDATA)> <!ELEMENT gmd: tempmin (#PCDATA)> <!ELEMENT gmd: relhummax (#PCDATA)> <!ELEMENT gmd: relhummin (#PCDATA)> ………………………………..

NON FUNCTIONAL ATTRIBUTES OF WHICHEVER DEVICE TO BE USED IN THE SYSTEM

ENVIRONMENTAL ATTRIBUTES OF WHICHEVER DEVICE TO BE USED IN THE SYSTEM


ABSTRACTING PHYSICAL DEVICES: AN XML DTD (2)

12 <!ELEMENT gmd: metadevice (md: light | md: humidity | md: temperature | md: waterlevel) – specific metadevices functional properties -- >

<!ELEMENT md: light (md: lightmax, md: lightmin, md wavelenghtmax, md: wavelenghtmin> <!ELEMENT md: lightmax (#PCDATA)> <!ELEMENT md: lightmin (#PCDATA)> <!ELEMENT md: wavelenghtmax (#PCDATA)> <!ELEMENT md: wavelenghtmin (#PCDATA)> <!ELEMENT md: humidity (md: relhummax, md: relhummin)> <!ELEMENT md: relhummax (#PCDATA)> <!ELEMENT md: relhummin (#PCDATA)> <!ELEMENT md: temperature (md: tempmax, md: tempmin)> <!ELEMENT md: tempmax (#PCDATA)> <!ELEMENT md: tempmin (#PCDATA)> <!ELEMENT md: waterlevel (md: watlevmax, md: watlevmin)> <!ELEMENT md: watlevmax (#PCDATA)> <!ELEMENT md: watlevmin (#PCDATA)>

FUNCTIONAL ATTRIBUTES OF A SPECIFIC DEVICE


HIGH LEVEL DM LANGUAGES FOR WSN 13

Tiny DB had the merit of being the first proposal of a declarative language for sensors data manipulation “TinyDB is a query processing system for extracting

information from a network of TinyOS sensors.” Other approaches, e. g. DSN – a completely declarative approach based on Snlog, a logic language Logic languages not easy for the systems practitioners GSN middleware completely developed in Java and it is executed on the

computers composing the backbone of the acquisition network.


THE PerLa LANGUAGE 14

The PerLa language is a declarative SQL-like language inspired by TinyDB, whose goal is to relax its constraints. The main aspects that have been considered during the design phase of PERLA language are: Data representation and abstraction Physical devices management Functional language features Non Functional language features http://perlawsn.sourceforge.net/index.php


PerLa LANGUAGE AND MIDDLEWARE 15

Low Level Interface

LLQ/HLQ/AQ analyzer and

executors

High Level Interface SELECT temperature, humidity

WHERE temp>20 SAMPLING EVERY 1h EXECUTE IF device_id > 2

LLQs: define the behaviour of every device HLQs: perform SQL operations on sensors streams AQs: allow to define the behaviour of actuators

The LLI allows for a runtime plug and play integration of heterogeneous sensors. Each device type is wrapped by a customized component built accordingly a device description XML file.


PerLa: KEY FEATURES 16

High level interface: the language

SQL-like syntax Three levels of queries

High level query (HLQ) Equivalent to SQL for

streaming DB Actuation query (AQ)

Executes commands, set parameters on devices

Low level query (LLQ) Defines the behaviour of a

single or of a group of devices

Low level interface: the hardware abstraction layer

Devices as a Functionality Proxy Component (FPC)

An FPC provides: Attribute reading (id,

temperature, pressure, power level, last sensed RFID reader, …)

Event notification (last sensed RFID reader changed, …)

Meta-description (name, data type, …)


PerLa LOW LEVEL QUERIES: AN EXAMPLE

17

INSERT INTO STREAM Table (sensorID, temperature) LOW: EVERY 10 m

SELECT ID, COUNT(temp, 10 m)

SAMPLING

EVERY 30 s WHERE temp > 100

EXECUTE IF powerLevel > 0.2 AND EXISTS (temp)

SAMPLING SECTION

DATA MANAGEMENT SECTION

EXECUTION CONDITIONS SECTION

Event based activation

Time based activation

Event based sampling

Time based sampling

Sample the temperature every 30 seconds and, every 10 minutes, report the number of samples that exceeded a given threshold, only for nodes with a temperature sensor and a battery level higher than 20%


PLUG&PLAY SUPPORT 18

PLUG & PLAY at device start-up requires: Dynamic generation of the FPC On the fly binding mechanism to handle connections

between the FPC and the physical device Insertion of new FPCs into the Registry How to build an FPC to handle a new device?

By means of an xml-based DEVICE DESCRIPTION Sent by the device itself Defines available data streams and events raised Specifies the message protocol used by the device

Commands format Data format


PLUG&PLAY SUPPORT(2) 19

Physical device

JAVA + TCP/IP

FPC

LLQE

HLD

LLD

FPC REGISTRY

SELF-DESCRIPTION

FPC FACTORY


PLUG & PLAY – FPC FACTORY 20

XML descriptor validated by a formerly defined XML Schema

Run time mapping XML – Java JAXB Generated code

compilation Wrapping

JAXB XML

.CLASS LOAD PerLa FPC


PLUG & PLAY – MAPPING 21

<perlaDeviceElement name="esempio"> <perlaSingleDevice nodeId="1"> <parameterStructure name="e"> <parameterElement name="param"> <length>2</length> <type nameType="int"> <sign>signed</sign> </type> </parameterElement> <type>EsempioXML</type> <size>2</size> <endianess>BigEndian</endianess> </parameterStructure> </perlaSingleDevice> </perlaDeviceElement>

package org.dei.perla.sys.device.fpc.esempio; /* IMPORT */ @StructInfo(endianness = Endianness.BIG_ENDIAN, totalStructSize = 2) public class EsempioXML extends AbstractData{ public EsempioXML() { super(); }

@SimpleField(size = 2, sign = Sign.SIGNED) private int param; public int getparam() { return param; } public void setparam(int param) { this.param = param; } }

Root element. It specifies the name of the package in which the generated classes will reside


PLUG & PLAY – MAPPING 22

<perlaDeviceElement name="esempio"> <perlaSingleDevice nodeId="1"> <parameterStructure name="e"> <parameterElement name="param"> <length>2</length> <type nameType="int"> <sign>signed</sign> </type> </parameterElement> <type>EsempioXML</type> <size>2</size> <endianess>BigEndian</endianess> </parameterStructure> </perlaSingleDevice> </perlaDeviceElement>

package org.dei.perla.sys.device.fpc.esempio; /* IMPORT */ @StructInfo(endianness = Endianness.BIG_ENDIAN, totalStructSize = 2) public class EsempioXML extends AbstractData{ public EsempioXML() { super(); }

@SimpleField(size = 2, sign = Sign.SIGNED) private int param; public int getparam() { return param; } public void setparam(int param) { this.param = param; } }

A parameter is represented as a Java variable.


OUTLINE 23

ABSTRACTING WIRELESS SENSOR NETWORKS FROM PHYSICAL TO CONCEPTUAL LEVEL




RADIO FREQUENCY IDENTIFICATION TAGS (RFID)

24

LOW END IN THE SENSOR CAPABILITIES SCALE TWO-COMPONENT SYSTEMS READER ENERGY SOURCE R/T ACTIVE DEVICE

TRASPONDER (TAG) UNIQUE ID SMALL PROCESSING CAPABILITY SMALL ON-CHIP STORAGE R/T ANTENNA


RFID DATA CENTRIC APPLICATIONS 25

GOODS LOGISTICS ANIMALS TAGGING PRODUCTION CONTROL PRODUCT TRACKING

AIRPORT LUGGAGE MANAGMENT WAREHOUSES MANAGEMENT

ACCESS CONTROL AND TICKETING ELECTRONIC TICKETING

SKIPASS TELEPASS PUBLIC TRANSPORTATION

SECURITY APPLICATIONS PEOPLE IDENTIFICATION ELECTRONIC PASSPORT

TECHNOLOGY ENHANCEMENT PRODUCT MAINTENANCE


SENSOR SIZE COMPARISON 26


27

READER TAG

READER TAG

READER TAG

READER TAG

RFID SYSTEM OPERATION


MODELING AND QUERYING AN RFID SYSTEM 28

READER TAG 0:n 0:n SEES

R_id T_id

R_id T_id time

R1 T15 t1

R1 T54 t5

R1 T15 t7

R2 T22 t2

R2 T15 t3

R2 T81 t4

R3 T15 t5

R3 T22 t6

time

rfidsys

SELECT T_id FROM rfidsys WHERE R_id=R1 AND time IN (SELECT(time,T_id) FROM rfidsys WHERE (t-time) < 10)

Which Tags passed under Reader R1 in the last ten minutes?


PerLa MODELING AND QUERY STYLE

In PerLa the RFID system can be modeled in two equivalent ways: RFID readers as data stream generators, RFID tags as

data (“Which Tags passed under Reader R1?”) Limited number of data streams (one per reader) Adding new tags does not modify the PerLa internal state

RFID Tags as (virtual) data stream generators (“Which Reader read tag #1 in the last hour?”) Many short data streams Adding a new tag affects PerLa internal state (new FPC

required)

29


RFID READERS AS DATA SOURCES

Q1 Which Tags passed under Reader R1 more than once?

First: device attributes and events definition

Which Tags passed under Reader R1 in the last ten minutes? 31



First: device attributes and events definition

RFID Reader attributes

Attribute Role Data Type

R_id Reader identifier (static attribute) ID

deviceType Device type identifier(static attribute) STRING

Tag_id Last RFID tag identifier read ID

Time Last reading Timestamp TIMESTAMP

Events

tagRead Notifies when a tag is read

Which Tags passed under Reader R1 in the last ten minutes? 32



Second: output stream definition


Attribute

R_id

deviceType

Tag_id

Time

Events

tagRead

Tag_id Time

Output stream

33



Tag_id Time


Attribute

R_id

deviceType

Tag_id

Time

Events

tagRead

Output stream

Second: output stream definition 34




Attribute

R_id

deviceType

Tag_id

Time

Events

tagRead

Tag_id Time

Output stream




CREATE OUTPUT STREAM Readings(Tag_id ID, Time TIMESTAMP)

Tag_id Time

Output stream




Third: feed the output stream

READER R1

Tag_id Time

Output stream

37



READER R1 TAG

1


Tag_id Time

1 t1

Output stream

39



READER R1 TAG

1

tagRead()


Tag_id Time

1 t1

Output stream

40



INSERT INTO STREAM Readings(Tag_id, Time) EVERY ONE SELECT Tag_id, Time SAMPLING ON EVENT tagRead() EXECUTE IF deviceType = “RFID_READER” AND R_id = “R1”


Tag_id Time

1 t1

Output stream

41



Tag_id Time

1 t1

... ...

READER R1

LLQ

Fourth: create a fixed width (in terms of time) output snapshot table

42


RFID READERS AS DATA SOURCES Tag_id Time

1 t1

1 t2

2 t3

.... ....

M tR

Snapshot table time constraints |tR-t1| <= 10min

HLQ

LLQ

43

Tag_id Time

1 t1

... ...

READER R1


Tag_id Time

1 t1

... ...

READER R1

RFID READERS AS DATA SOURCES Tag_id Time

1 t1

1 t2

2 t3

.... ....

M tR

Snapshot table time constraints |tR-t1| <= 10min

HLQ

LLQ CREATE OUTPUT SNAPSHOT Last_ten_minutes_readings(Tag_id ID, Time TIMESTAMP) WITH DURATION 10 min INSERT INTO STREAM Last_ten_minutes_readings(Tag_id, Time) SELECT Tag_id, Time FROM Readings

44


WSNs: PUTTING DEVICES TOGETHER 45

SENSOR NETWORKS INVOLVE THREE AREAS: SENSING COMMUNICATION COMPUTATION

WSN APPLICATIONS: ENVIRONMENTAL MONITORING

AIR, LAND, WATER, FORESTS, … ANIMAL BEHAVIOUR EMERGENCIES PREVENTION AND CONTROL (fires, earthquakes, avalanches,

etc.) HEALTHCARE

PATIENT MONITORING COMMERCIAL

VEHICLE TRACKING LOGISTICS

MILITARY AND DEFENSE SURVEILLANCE OF CITY DISTRICTS TERRORISTIC THREATS PREVENTION

…………………………………….

45



WSN HARDWARE 46

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 UNRELIABLE, ENERGY CONSUMING TRANSMISSION CHANNELS

Software needs to take these limits into account


WSN HARDWARE 47

FURTHER CONSTRAINTS:

WSNs MAY HAVE THOUSANDS OF NODES NODES THEMSELVES DO NOT HAVE A NOTION OF

NODE PROXIMITY NODES’ TRASMISSION MAY INTEFER: COLLISIONS BATTERY FAILURES SENSOR CALIBRATION Software needs to take these

constraints into account


WSN HARDWARE EVOLUTION 54

1999 2000 2004 2002 2004 2008

weC Rene Mica2 Tmote SKY Sun Spot Imote2

Clock (MHz) 4 4 8 8 180 13-416

CPU Atmel 8bit Atmel 8bit Atmel 8bit TI 16bit ARM 32bit ARM 32bit

Flash (KB) 8 8 128 48 4096 32M

RAM (KB) 0.5 0.5 4 10 512 256k+ 32M(ext)

Baud Rate (Kbps) 10 10 38.4 250 250 250


OTHER SENSORS 55

The University of Michigan has squeezed a solar cell, rechargeable battery, and CPU-based data acquisition system into 9mm³ (2.5x3.5x1mm).

Program Flash Memory 48 kB on chip Acoustic Piezzo Microphone Data RAM 10 kB on chip Electret Microphone Flash Measurement 1 MB external Magnetic 3 axis Inductive Serial Communications 2 × USART Seismic/Vibration ± 1.2 g accelerometer SenseNode® -

Genetlab® Node support V-Link®-mXRS™, SG-Link®-mXRS™, G-Link®-MXRS™, DVRT-Link™-mXRS™, TC-Link®-6CH-mXRS™, TC-Link®-1CH-mXRS™, EH-Link®, SG-Link® OEM-S, TC-Link® OEM all legacy 2.4 GHz wireless nodes

Power consumption 65.6 mA - 8 active node channels operating at 256 Hz Legacy Low Duty Cycle with analog outputs active 45.7 mA - Idle

Radio frequency (RF) transceiver carrier

2.4 GHz direct sequence spread spectrum, license free worldwide (2.405 to 2.480 GHz) – up to 16 channels, radiated power programmable from 0 dBm (1 mW) to 16 dBm (39 mW)

Range for bi-directional RF link

16 dBm (39 mW) Extended Power with range up to 2 kilometers (not available in Europe) 10 dBm (10 mW) Standard Power with range up to 1 kilometer 0 dBm (1 mW) Low Power with range up to 70 meters

Dimensions 88 mm x 70 mm x 20 mm without antenna

Weight 126 grams

http://www.umich.edu/

http://www.umich.edu/


WSN SOFTWARE EVOLUTION 59

YEAR OS Architecture Multitasking Real-time Memory Manag. Progr. Paradigm Progr.

Language

2000 TinyOS Monolithic No No Static Event driven NesC

2004 Contiki Modular Yes No Dynamic Threads and events C

2005 Nano-RK Monolithic Yes Yes Static Threads C

2005 SOS Modular No No Dynamic Event driven C

2005 Mantis Modular Yes No Dynamic Threads C

2008 LiteOS Modular Yes No Dynamic Threads and events LiteC++

From simple implementation towards feature-rich operating system (thanks to parallel hardware evolution)


A DB VIEW OF SENSOR NETWORKS 60

WSN TRADITIONAL: PROCEDURAL ADDRESSING OF INDIVIDUAL SENSOR

NODES THE USER SPECIFIES HOW THE TASK IS EXECUTED, DATA IS

PROCESSED CENTRALLY

DB-STYLE APPROACH: DECLARATIVE QUERYING THE USER IS NOT CONCERNED ABOUT “HOW THE NETWORK

WORKS” IN-NETWORK DISTRIBUTED PROCESSING


THE WSN AS A DATABASE 61

DATABASE ALARM GENERATION

NETWORK AS DATA PROCESSOR

NETWORK AS DATA STORAGE

(DATA STREAMS)

SENSORS

DATA ANALYSIS TOOLS (dw, dm, …)

THRESHOLDS

INFORMATION

SYSTEM


CONCEPTUAL SCHEMA OF A GEOPHYSIC MONITORING SYSTEM

62

SENSOR BOARD SENSOR

MEASURE DATA

SITE IS IN BELONGS TO

COLLECTION

[1,1]

[0,n]

[1,1] [1,1] [1,n] [0,n]

DATE TIME

MEAS_UNIT

VALUE

S_ID

S_TYPE MODEL

NAME MUNICIPALITY

ZONE

MONITORING NETWORK

EMERGENCY PLAN

GB COORDINATES

ACTIVATION DATE

TYPE OF GROUND BD_ID

LINK TO MAP NOTES

DISTRICT

LINK TO MAP

PHENOMENON

LOCATION

TYPE

OBJECTS AT RISK

NOTES

[0,n]

[1,1] HARMED

BY

OB_TYPE OB_ID

BELONGS TO

[0,n] [1,n]

[1,n]

[1,1]

MN_NAME

NUMBER OF

STATIONS

ACTIVATION YEAR


HOW DIFFERENT WSN QUERIES ARE FROM GENERAL DB QUERIES

63

SENSOR DATA

TIME STAMPED

SENSORS DELIVER DATA IN STREAMS CONTINUOUS DATA PRODUCTION OFTEN AT WELL DEFINED TIME INTERVALS NO EXPLICIT REQUEST FOR THAT DATA.

QUERIES NEED TO BE PROCESSED IN NEAR REAL-TIME EXPENSIVE TO SAVE ALL DATA TO DISK DATA STREAMS REPRESENT REAL-WORLD EVENTS WHICH NEED TO BE

RESPONDED TO (e.g., traffic accidents and attempted network break-ins),

NOT ALL SENSOR READINGS ARE OF INTEREST

UNCERTAIN, INCOMPLETE INFORMATION


QUERY PROCESSING IN WSNs 64

WHEN SHOULD SAMPLES FOR A PARTICULAR QUERY BE TAKEN (acquisitional issue)

WHICH SENSOR NODES HAVE DATA RELEVANT TO A PARTICULAR QUERY (indexing/optimization)

IN WHAT ORDER SHOULD SAMPLES BE TAKEN AND HOW SHOULD IT BE INTERLEAVED WITH OTER OPERATIONS (indexing/optimization)

IT IS WORTH EXPENDING COMPUTATIONAL POWER OR BANDWIDTH TO PROCESS AND RELAY A SAMPLE (stream processing/approximate answering)


QUERIES IN WSNs STORAGE / TRANSMISSION OPTIMIZATION

65

QUERY DISSEMINATION PHASE BROADCASTING – QUERIES ARE DOWNLOADED TO ALL NODES

SIMPLE FLOODING – EVERY NODE RETRANSMITS THE RECEIVED MESSAGE TO ALL ITS NEIGHBOURS, ONLY DISCARDING DUPLICATES

TREE FLOODING – BUILD A SPANNING TREE (ONCE), SEND ALONG THE TREE BRANCHES, DISCARD DUPLICATES

ENERGY EFFICIENT FLOODING – REQUIRES THE KNOWLEDGE OF TWO-HOP NEIGHBOURS

SELECTIVE BROADCASTING – ONLY RELEVANT NODES ARE AFFECTED SEMANTIC ROUTING TREES – EACH NODE IN THE TREE KNOWS THE ATTRIBUTES OF ITS

CHILDREN AND THEIR CAPABILITY TO ANSWER A CERTAIN QUERY

GEOGRAPHIC ROUTING – EACH NODE HAS LOCATION INFORMATION AND QUERYES ARE SPATIALLY BOUNDED

CONTEXT/CONTENT BASED ROUTING – MESSAGES ARE ROUTED ON THE BASIS OF THEIR SEMANTICS AND NOT ON A PREDEFINED ADDRESS


QUERIES IN WSNs STORAGE / TRANSMISSION OPTIMIZATION

66

RESULT-COLLECTION PHASE – PROCESSING AND DISSEMINATION ARE DISTRIBUTED AMONG THE NODES ALLOWING CROSS-LAYER OPTIMIZATION WHICH HEAVILY DEPENDS ON THE APPLICATION

IN-NETWORK PROCESSING AGGREGATION, COMPRESSION, APPROXIMATION MODEL DRIVEN DATA ACQUISITION – EXPLOIT TEMPORAL AND SPATIAL

CORRELATIONS AMONG DATA

PLACING OPERATORS IN THE NETWORK – EXPLOIT THE DISTRIBUTIVITY OF OPERATORS TO PLACE THEM AS NEAR AS POSSIBLE TO THE SENSOR NODES

INTERPLAY BETWEEN ROUTING AND QUERY PROCESSING TRY TO SHAPE THE COMMUNICATION PATH IN ORDER TO OPTIMIZE CLASSES OF

(SUB)QUERIES

INTERPLAY BETWEEN MAC, ROUTING, AND QUERY PROCESSING TDM-LIKE ACCESS PROTOCOLS TO AVOID (RE)TRANSMISSION COLLISIONS

DATA STREAM MANAGEMENT 67

http://www.123rf.com/photo_6855723


DATA STREAMS AND DSMS 68

UNBOUNDED, RAPID, TIME-VARYING STREAMS OF DATA ELEMENTS, CONTINUOUS FLOWING ON THE WSN

DATA STREAM MANAGEMENT SYSTEMS (DSMS) ARE DESIGNED TO PROCESS THEM CONTINUOUSLY, SINCE A STORE NOW AND PROCESS LATER APPROACH WILL NOT WORK DUE TO: Response requirements: real time or quasi real-time Streams are too massive, and also bursty. Online filtering of interesting data for in-depth analysis later.

MANY APPLICATIONS SIMILAR TO THOSE OF DBMS. MOST DSMS USE SOME FORM OF SQL

COMPUTING ENVIRONMENTS QUITE DIFFERENT

PERSISTENT QUERIES ON TRANSIENT DATA, VS. TRANSIENT QUERIES ON PERSISTENT DATA

"A STREAM IS THE TIME DIFFERENTIAL OF A TABLE “ (J. Hyde)


DATA STREAMS AND DSMS APPLICATIONS

69

COMPLEX EVENT PROCESSING (CEP): A CEP QUERY LOOKS FOR PATTERNS AMONG INDIVIDUAL EVENTS IN A SINGLE OR IN MULTIPLE STREAMS TELECOM CALL RECORDS: FRAUD DETECTION FINANCIAL APPLICATIONS: E.G. ALGORITHMIC TRADING SECURITY APPLICATIONS: INTRUSION DETECTION, HOMELAND SECURITY

MONITORING QUERIES: AGGREGATE LARGE NUMBERS OF RECORDS AND LOOK FOR TRENDS NETWORK MONITORING AND TRAFFIC MANAGEMENT WEB LOGS AND CLICK-STREAMS

PUBLISH/SUBSCRIBE SERVICES

SENSOR NETWORKS, RFID TAGS

Extract, Transform, Load (ETL) TOOL FOR DATA WAREHOUSES IMPROVES CURRENCY w.r.t. THE BATCH TOOL


DBMS VS. DSMS 70

DBMS DSMS Model persistent data transient data Table set|bag of tuples Infinite sequence of tuples Updates all append only Query transient persistent Query Answer exact often approximate Query Eval multi-pass one-pass Operator blocking OK unblocking only Query Plan fixed adaptive Data processing synchronous asynchronous Concurr. control overhead

high low


QUERIES OVER DATA STREAMS 71

APPROXIMATE QUERIES TIMELINESS OFTEN REQUIRES LOW-LATENCY ANSWERS OVERLOADS CAN BE DEALT WITH BY LOAD SHEDDING

2 SEC/TUPLE 1 TUPLE/SEC 0.5 TUPLE/SEC

INPUT STREAM

OUTPUT STREAM

OUTPUT STREAM WITH TUPLE SHEDDING


QUERIES OVER DATA STREAMS 72

WINDOWING FIXED

SLIDING

INPUT BUFFER 1

INPUT BUFFER 2 OUTPUT

BUFFER

PROCESSING

DATA


OUTLINE 73

ABSTRACTING WIRELESS SENSOR NETWORKS FROM PHYSICAL TO CONCEPTUAL LEVEL




PERVASIVE DATA MANAGEMENT 74

INSTANTANEOUS AND COMPLETE ACCESS TO ANY INFORMATION AT ANYTIME AND ANYWHERE HIGHLY DYNAMIC ENVIRONMENTS WHERE BOTH DATA AND SOURCE

AVAILABILITY VARY OVER LOCATION AND TIME

REVERSED PARADIGM WITH RESPECT TO DISTRIBUTED DATABASES NO MORE PASSIVE DB AND ACTIVE USERS DEVICES ARE BOTH PRODUCERS AND CONSUMERS OF DATA

DATA OBJECTS STORED ON MOBILE DEVICES WHICH PROCESS THE INCOMING DATA WHILE LOOKING FOR INFORMATION OF INTEREST TO ITS USER


PERVASIVE DATA MANAGEMENT 75

MOBILITY SPATIO-TEMPORAL VARIATIONS OF DATA AND DATA-

SOURCES AVAILABILITY

LACK OF GLOBAL CATALOG AND SCHEMA

NO GUARANTEE OF RECONNECTION

NO GUARANTEE OF COLLABORATION

MOBILE SYSTEMS 76

HELP!


MOBILE APPLICATIONS 77

TRADITIONAL APPLICATIONS ON MOBILE DEVICES

NEW APPLICATIONS EXPLOITING THE DYNAMIC FEATURES OF THE MOBILE ENVIRONMENT TO PROVIDE CONTEXT-AWARE FEATURES LOCATION-BASED SERVICES AND LOCATION-DEPENDENT

QUERIES EMERGENCY SERVICES NAVIGATION AND INFORMATION SERVICES LOCATION-DEPENDENT ADVERTISING TRACKING SERVICES


MOBILITY ISSUES IN INFO SYSTEMS 78

WHICH IS THE APPLICATION WORKING MODE WITH RESPECT TO SPACE

LOCATION DEPENDENT DATA LOCATION AWARE TRANSACTIONS

WITH RESPECT TO SPACE-TIME SENSIBLE OF EXTERNAL EVENTS (ACTIVE) NOMADIC ROAMING (QUASI STATIC) FULL-FEATURED MOBILE (REAL-TIME)

QUERY ANSWERING SEMANTICS (????) ^ AS OF WHERE ISSUED ^ AS OF WHERE PROCESSED ^ AS OF WHERE RECEIVED

ACCURATE AND COHERENT SPATIO-TEMPORAL VIEW OF THE DISTRIBUTED STATE AND OF THE QoS


AN EXERCISE 79

DATABASE

Proc. time - 5 s

X = ??

1000 km/h 280 m/s 1500 m

100 km/h 28 m/s 150 m

5 km/h 1.4 m/s 7.3 m

Tot.=5.22 s


MOBILE-OBJECT DATABASES 80

EXAMPLE APPLICATIONS

CELLULAR PHONE NETWORKS UPDATE THE USER POSITION (CELL) LOCATE A USER (CELL) TO FORWARD A CALL

AIR TRAFFIC CONTROL DATA CONTINUOUSLY TRACK THE POSITION OF EACH OBJECT IN A

GIVEN AREA

ACTIVE (FAST) OBJECTS STORED IN MAIN MEMORY (HARD RT)

INACTIVE (SLOW) OBJECTS STORED ON DISK (FIRM/SOFT RT)


QUERIES IN MOBILE OBJECTS DATABASES 81

COORDINATE-BASED QUERIES SPATIO/TEMPORAL

Find all objects within a given area during a given time interval

TIMESLICE Find all objects’ locations within a given area at a certain time instant

NEAREST NEIGHBOUR Find the nearest moving object to a given object during a given time interval


QUERIES IN MOBILE-OBJECT DATABASES 82

t

y

x

timeslice point nearest neighbour

trajectory nearest neighbour

range

Q3

Q1 Q2 Q4

Q5

t1

t2

t3

t4

t5

t6


QUERIES IN MOBILE OBJECTS DATABASES 83

TRAJECTORY-BASED QUERIES TOPOLOGICAL QUERIES ENTER, LEAVE … A GIVEN AREA

NAVIGATIONAL QUERIES AVERAGE OBJECT SPEED, COVERED DISTANCE …

COMBINED QUERIES

Which trajectories followed, in the next hour, the objects leaving via Ponzio 34 between 5 p.m. and 8 p.m. today

Which is the nearest gas station at each instant during my whole trip


NEW APPLICATION ARCHITECTURES 84

PEER-TO-PEER INFORMATION SOURCES COINCIDE WITH USER DEVICES

PURE P2P: FLAT ARCHITECTURE, NO DIFFERENCE AMONG THE NODES (Gnutella)

HYBRID AND MIXED P2P: FLAT ARCHITECTURE FOR DATA, CLIENT-SERVER ARCHITECTURE FOR META-DATA (Napster, eMule, BitTorrent)

USED FOR MULTIMEDIAL INFORMATION EXCHANGE

CONTEXT-AWARENESS: ESSENTIAL IN SOLVING PARTNERS HETEROGENEITY

ONTOLOGY: ESSENTIAL IN INFORMATION SEARCHING FORMULATING QUERIES AGAINST UNKNOWN PARTIES RECONCILING ANSWERS FROM DIFFERENT SOURCES

MOBILITY: NOT A NECESSARY ISSUE

CONTEXT COMES INTO THE PLAY 85

?


Autonomic Pervasive Systems 86

Pervasive systems are widely adopted to monitor many kinds of physical phenomena.

Context-awareness plays a fundamental role since it allows, through the perception of the environment, to make the system autonomic w.r.t. environmental situations and changes.

Context must be managed both at design and run

time.


Context management at design time 87

Context modelling

Application domain modelling (data, functions)

Design of the relationship between the context model and the application domain.



CONTEXT MODEL


CDT model 89

The environment is modelled in terms of dimension nodes, concept (or value) nodes, attributes, and possibly constraints

A context element is defined as Dimension = Value and a context is a conjunction of context elements

A context can be represented as a particular subtree of the CDT

Farmer

Overheat

Driver Oenologist

Role

Disease

Growth Ageing

Type

$Square_meters $ID

Affected hectares

Risk Phase

Transport


CDT model 90

phenomenon Site Topography

environment season time

earthquake landslide avalanche plain steep glacier desert forest winter

spring summer

autumn day night

CONTEXT MODEL

REAL WORLD

A CONTEXT



It is important to separate between NUMERIC OBSERVABLES

SYMBOLIC OBSERVABLES

Example: temperatures

- 20 °C – 10 °C COLD

11 °C – 25 °C MILD

26 °C – 50 °C WARM


Context management at runtime 92

Observable, numerical variables gathered from sensors

Symbolic variables (context dim. values)

Context activation (through the association between contexts and “relevant system parts”)

Context-aware behavior

Other sources

of context elements


Context management at runtime 93

Context sensing (numeric observables)

Context recognition (symbolic observables)

Context activation

Context-aware behaviour: extending


PerLa Context language and manager 94

Context Language (CL): to define the CDT, i.e. to describe the dimensions and the concepts in terms of numeric observables and of the symbolic observables defined on them, and the desired actions.

Context manager (CM): detects active contexts and performs the defined actions accordingly


Contextual block structure 95

ACTIVATION COMPONENT

ENABLE COMPONENT

DISABLE COMPONENT

REFRESH COMPONENT


Context Language (1/3) 96

CREATE DIMENSION <Dimension Name>

[CHILD OF <Parent Node >]

[CREATE ATTRIBUTE $<Attribute Name >] |

{CREATE CONCEPT <Concept Name> WHEN <Condition >

[CREATE ATTRIBUTE $<Attribute Name >]∗

[EVALUATED ON <Low Level Query >]}∗

CREATE CONTEXT <Context Name>

ACTIVE IF <Dimension>= <Value>

[AND <Dimension>= <Value >]∗

ON ENABLE (ContextName) <PerLa Query>

ON DISABLE (ContextName) <PerLa Query>

REFRESH EVERY <Period>

CDT declaration in terms of numeric and symbolic observables

Context creation and specification of the actions to be performed using LLQs, HLQs and AQs Syntax (the “hooks”)


Context language (2/3) 97

CREATE DIMENSION Role CREATE CONCEPT Farmer WHEN get_user_role()=‘farmer’ CREATE CONCEPT Oenologist WHEN get_user_role()=‘oenologist’ CREATE CONCEPT Driver WHEN get_user_role()=‘driver’ CREATE DIMENSION Risk CREATE CONCEPT Disease WHEN get_interest_topic()=‘disease’ CREATE CONCEPT Overheat WHEN temperature > 30 AND brightness > 0.75; …..

Farmer

Overheat

Driver Oenologist

Role

Disease

$ID $square_ meters

Type Affected hectares

Risk

Example: Given the previous CDT


Context Language (3/3) 98

CREATE CONTEXT Growth_Monitoring ACTIVE IF phase = ‘growth' AND role=‘farmer’ AND Risk='overheat' ON ENABLE(Growth_Monitoring): SELECT temperature,humidity SAMPLING EVERY 120 s EXECUTE IF location = ‘vineyard' SET PARAMETER 'alarm' = TRUE; ON DISABLE(Growth_Monitoring): SET PARAMETER 'alarm' = FALSE; REFRESH EVERY 24 h;

Farmer Growth

Risk

Overheat

Role Phase


The Context Manager 99

ID Temperature Brightness

1 28 0.60

3 31 0.71

4 33 0.80

OVERHEAT: temperature > 30 AND brightness > 0.75

The CM associates to every dimension of the CDT a table that contains the values of every numeric observable sampled from the environment In the previous example we declared a context that includes the observable “overheat” (declared using the numeric temperature and brightness):

The context can be considered as active for all the sensors for which the rule is true, and the context-aware actions will be performed only on them.

Farmer Overheat

Risk Role

Growth

Phase


Comparison with Active DB 100

ACTIVE DATABASES PerLa FOR CONTEXT

EVENT data modification: insert, delete, update

EVENT general system events, clock, …

CONDITION (optional) SQL predicate

CONDITION context definition formula

ACTION sequence pf SQL statements (or extensions, e.g. PL/SQL in Oracle)

ACTION Data, code, services tailoring, whatever action on the physical system


Comparison with Active DB 101

ACTIVE DATABASES PerLa FOR CONTEXT

COUPLING (immediate/deferred)

ONLY IMMEDIATE

ATOMIC/INTERRUPTIBLE ACTIONS ONLY ATOMIC

EVENT CONSUMPTION (never, local, global)

EVENT CONSUMPTION (never, only at context change)

CONFLICT RESOLUTION (serial/parallel)

CONFLICT RESOLUTION (serial, managed by priority policies)


Performance evaluation 102

In its original configuration, PerLa’s middleware scales linearly w.r.t. the operations (i.e.: LLQs, HLQs, AQs) that are performed on the deployed devices.

The creation of the CDT and the search for active contexts scale linearly too (simple lookup control in every table) and thus do not impact PerLa’s linear behaviour.


REFERENCES (1)

!  • B. Babcock et Al. – Models and Issues in Data Stream Systems – Proc. ACM PODS, pp. 1-16, Madison 2002

!  • Y. Bai, H. Thakkar, C. Luo, H. Wang, C. Zaniolo – A Data Stream Language and System Designed for Power and Extensibility – Proc. of the ACM 15th Conference on Information and Knowledge Management (CIKM'06), 2006

!  • G. Bernard et Al. – Mobile Databases: a Report on Open Issues and Research Directions - ACM SIGMOD, (2003) http://lpd.epfl.ch/site/publications/

!  • C. Cappiello, F.A. Schreiber - Experiments and analysis of quality and Energy-aware data aggregation approaches in WSNs - 10th International Workshop on Quality in Databases QDB 2012 (Co-located with VLDB 2012), Istanbul, Aug. 26, pp. 1-8, http://www.purdue.edu/discoverypark/cyber/qdb2012/papers/7data%20aggregation.pdf, 2012..

!  • M. Cherniack, M. Franklin, S. Zdonik – Data Management for Pervasive Computing – 27th VLDB Conference tutorial, Roma, Sept. 2001

!  • C.A. da Costa, A. Corrêa Yamin, C.F.R. Geyer – Toward a General Software Infrastructure for Ubiquitous Computing – Pervasive Computing, Vol. 7, No. 1, 2008

!  • P. Di Sanzo et Al. - On the analytical modeling of concurrency control algorithms for Software Transactional Memories: The case of Commit-Time-Locking - Performance Evaluation, Vol. 69, No. 5, pp. 187–205, May 2012

103


REFERENCES (2) 104

• L. Golab and M. Tamer Özsu – Issues in Data Stream Management – SIGMOD Record, Vol. 32, No. 2, June 2003

• J. Hyde – Data in Flight – Communications of ACM, Vol. 53, n.1, Jan 2010

• P. E. Kourouthanassis, G. M. Giaglis – A Design Theory for Pervasive Information Systems – Proc. Int. Workshop on Ubiquitous Computing (ICEIS 2006), pp. 62-70, 2006

• Y. Law, H. Wang, C. Zaniolo – Query Languages and Data Models for Database Sequences and Data Streams – Proc. 30° VLDB Conf., pp. 492-503, 2004

• K. Liu – Pervasive informatics in intelligent spaces for living and working – IEEE Int. Conf. On ServiceOperations and Logistics, and Informatics, 1, pp. XVIII-XIX, 2008

• L. Mottola, G.P. Picco – Programming Wireless Sensors Networks: Fundamental Concepts and State of the Art – ACM Computing Surveys, Vol. 43, n. 3, Article 19, (2011)

• D. A. Norman – The Invisible Computer – MIT Press, Cambridge 1998

• M. A. Olson - Selecting and Implementing an Embedded Database System - IEEE Computer, vol. 33, n. 9, pp. 27-34, (2000)

• A. Pentland – Society’s Nervous System: Building Effective Government, Energy, and Public Health Systems – IEEE Computer, Vol. 45, n. 1, pp.31-38, (2012)

• F. Perich, A. Joshi, T. Finin, Y. Yesha – On Data Management in Pervasive Computer Environments – IEEE TKDE, Vol. 16, No. 5, pp.621-633, 2004


REFERENCES (3) 105

• D. Pfoser, C.S. Jensen, Y. Theodoridis – Novel Approaches to the Indexing of Mobile Objects trajectories – Proc. VLDB 2000, pp. 395-406

• F. A. Schreiber, R. Camplani, M. Fortunato, M. Marelli, G. Rota, - PerLa: A Language and Middleware Architecture for Data Management and Integration in Pervasive Information Systems - IEEE Transactions on Software Engineering, IEEE-CS Digital Library 02 Mar. 2011, Vol. 38, n. 2, pp. 478-496 (DOI: 10.1109/TSE.2011.25), 2012

• F. A. Schreiber, L. Tanca, R. Camplani, D. Viganò - Pushing context-awareness down to the core: more flexibility for the PerLa language - Electronic Proceedings of the 6th PersDB 2012 Workshop (Co-located with VLDB 2012), Istanbul, Aug. 31, pp. 1-6, http://persdb2012.cs.umn.edu/papers/4.Schreiber-PersDB12.pdf, 2012

• M. Tamer Özsu, P. Valduriez – Principles of Distributed Database Systems – 3rd ed., Springer, pp. 1- 845, 2011 (a comprehensive textbook, dealing with all facets of distributed data processing, including Data Streams, Grids and Clouds)

• N. Trigoni, A. Guitton, A. Skordylis – Querying of Sensor Data – in J. Gama, M. M. Gaber – Learning from Data Streams, Springer, 2007

• M. Weiser – The Computer for the 21th Century – Scientific American, Vol. 265, No. 3, pp. 94-104, 1991

• O. Wolfson – Moving Objects Information Management: The Database Challenge – http://www.cs.uic.edu/%7Ewolfson/mobile_ps/ ngits02.pdf

• W. Xue, Q. Luo, L. M. Ni – Systems Support for Pervasive Query Processing – Proc. 25° Int. Conf. on Distributed Computing Systems (ICSCS05), IEEE,


ACKNOWLEDGEMENTS 106

Letizia Tanca

Diego Viganò

an overview of data management in pervasive systems fabio a

Documents