Short introduction to perla middleware
This presentation is the property of its rightful owner.
Sponsored Links
1 / 68

SHORT INTRODUCTION TO PerLa MIDDLEWARE PowerPoint PPT Presentation


  • 89 Views
  • Uploaded on
  • Presentation posted in: General

SHORT INTRODUCTION TO PerLa MIDDLEWARE. M. Fortunato, M. Marelli Politecnico di Milano, Dipartimento di Elettronica e Informazione, Milano, Italy. LOW LEVEL QUERIES (LLQ). HIGH LEVEL QUERIES (HLQ). ACTUATION QUERIES (AQ). A DATA LANGUAGE FOR PERVASIVE SYSTEMS. FULL DECLARATIVE SQL-LIKE

Download Presentation

SHORT INTRODUCTION TO PerLa MIDDLEWARE

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Short introduction to perla middleware

SHORT INTRODUCTION TO PerLa MIDDLEWARE

M. Fortunato, M. MarelliPolitecnico di Milano, Dipartimento di Elettronica e Informazione, Milano, Italy


Short introduction to perla middleware

LOW LEVEL QUERIES(LLQ)

HIGH LEVEL QUERIES(HLQ)

ACTUATION QUERIES(AQ)

A DATA LANGUAGE FOR PERVASIVE SYSTEMS

FULL DECLARATIVE SQL-LIKE

HIGH LEVEL LANGUAGE

to query

PERVASIVE SYSTEMS

hiding the complexity

of handling

DIFFERENT TECHNOLOGIES


Short introduction to perla middleware

PILOT JOIN OPERATION

A DATA LANGUAGE FOR PERVASIVE SYSTEMS

  • The PILOT JOIN operation was introduced to activate the execution of a certain low level query on a device, only when some conditions on DATA SAMPLED BYOTHER NODES are satisfied.

  • The pilot join operation seems to be strictly related to the concept of CONTEXT AWARE DATA TAILORING.

    M.Marino, PILOT JOIN ANALYSIS


Short introduction to perla middleware

LOGICAL OBJECT ABSTRACTION

Events

Metadescription

Attributes

LOGICAL OBJECT

CHANNEL(Serial, Socket)

Physicaldevice

A DATA LANGUAGE FOR PERVASIVE SYSTEMS

  • The LANGUAGE SEMANTICS is defined on the concept of LOGICAL OBJECT

  • Each device is abstracted as a logical object:

    • ATTRIBUTES (id, temperature, pressure, power level, last sensed RFID reader, …)

    • EVENTS (last sensed RFID reader changed, …)

    • META-DESCRIPTION (name, data type, … for each attribute)


Short introduction to perla middleware

MIDDLEWARE

Textual queries

Queries results

Upper interface

QUERY PARSER

QUERY ANALYZER

LOGICAL OBJECTS REGISTRY

HIGH LEVEL QUERY EXECUTOR

A DATA LANGUAGE FOR PERVASIVE SYSTEMS

LOW LEVEL QUERY EXECUTOR

LOW LEVEL QUERY EXECUTOR

LOW LEVEL QUERY EXECUTOR

LOGICAL OBJECT IMPLEMENTATION

LOGICAL OBJECT IMPLEMENTATION

LOGICAL OBJECT IMPLEMENTATION

Lower interface

Physical device

Physical devices

WSN

  • A MIDDLEWARE is needed to provide an implementation of the logical object abstraction.


Short introduction to perla middleware

MIDDLEWARE GOALS (1)

A DATA LANGUAGE FOR PERVASIVE SYSTEMS

  • The main goals of the middleware are:

    • providing an ABSTRACTION for each device

    • supporting the EXECUTION OF PERLA QUERIES

    • allowing devices to automatically start query execution when they are powered on (PLUG & PLAY)

    • making the DEFINITION and the ADDITION of new devices (and new technologies) easy, reducing the amount of the needed low level code


Short introduction to perla middleware

MIDDLEWARE GOALS (2)

A DATA LANGUAGE FOR PERVASIVE SYSTEMS

1. providing an ABSTRACTION for each device

  • The FPC (Functionality Proxy Component) is defined as a Java object representing a physical device.

  • The FPCmust be instantiated on a node:

    • running a Java Virtual Machine (JVM)

    • connected to the TCP-IP network

  • The middleware should manage the COMMUNICATION PROTOCOL between FPC and physical device

FPC

JAVA + TCP/IP

Physical device


Short introduction to perla middleware

MIDDLEWARE GOALS (3)

A DATA LANGUAGE FOR PERVASIVE SYSTEMS

2. supporting the EXECUTION OF PERLA QUERIES

  • TheLLQE (Low Level Queries Executor) is a Java component placed on the FPC.

  • It is charged to retrieve needed data from the underlying FPC and to compute QUERY RESULTS.

  • An LLQE should support the simultaneous execution of all the low level queries running on the node.

    D. Viganò, Low Level Query Executor architecture

LLQE

FPC


Short introduction to perla middleware

MIDDLEWARE GOALS (4)

A DATA LANGUAGE FOR PERVASIVE SYSTEMS

3. allowing devices to automatically start query execution when they are powered on (PLUG & PLAY)

  • A PLUG & PLAY behavior at device start-up requires that:

    • An FPC object (providing a Java proxy to interact with the physical node) have to be DYNAMICALLY GENERATED and instantiated

    • The CONNECTION between FPC and physical node have to be established

    • The generated FPC have to be REGISTERED in the FPC registry, in order to allow the parser to consider also the new device

G. Rota, FPC Factory and devices self-description


Short introduction to perla middleware

MIDDLEWARE GOALS (5)

A DATA LANGUAGE FOR PERVASIVE SYSTEMS

4. making the DEFINITION and the ADDITION of new devices (and new technologies) easy, reducing the amount of the needed low level code

  • A device SELF-DESCRIPTION file can be introduced to allow a complete automatic generation of the Java FPC

  • A low level C LIBRARYcan be introduced to reduce the amount of required C code needed to manage the new technology

    • HLD: middleware provided C code (FPC-device communication, timer multiplexing, sampling scheduling, …)

    • LLD: user provided C code (low level sampling routines, communication channel initialization, …)

G. Rota, FPC Factory and devices self-description


Short introduction to perla middleware

MIDDLEWARE ARCHITECTURE

LLQE

FPC

R. Camplani: A proposal for the Low Level C library architecture

SELF-DESCRIPTION

A DATA LANGUAGE FOR PERVASIVE SYSTEMS

FPC

REGISTRY

FPC FACTORY

JAVA + TCP/IP

HLD

LLD

Physical device


Perla middleware architecture

PerLa MIDDLEWARE ARCHITECTURE

G. RotaPolitecnico di Milano, Dipartimento di Elettronica e Informazione, Milano, Italy


Short introduction to perla middleware

PerLa MIDDLEWARE ARCHITECTURE

  • PerLa Middleware Goals

  • Global overview of the PerLa middleware

  • Logical objects and FPC

  • Boundaries of the Middleware: HLD and LLD

  • Factory and FPC assembling

  • Device multiplexing

  • Network heterogeneity

  • Open points


Short introduction to perla middleware

PerLa MIDDLEWARE GOALS

  • Ensure the PerLa language can work in spite of the underlying hardware heterogeneity

    • Provide a REGULAR APPROACH to access different devices

    • Provide a REGISTRY to keep track of the devices’ state

  • Enable the system to automatically recognize and hook-up new devices in a PLUG & PLAY FASHION

    • The system adapts itself to new devices

    • Reduce the end user’s programming effort as much as possible

  • Support for new modules and extensions


Short introduction to perla middleware

PerLa MIDDLEWARE GOALS


Short introduction to perla middleware

LOGICAL OBJECTS AND FPCs

  • The LOGICAL OBJECTS are a HIGH-LEVEL ABSTRACTION of the physical devices. They have to provide:

    • A list of the supported attributes and events

    • An interface to set or retrieve attributes on the device

    • Notifications to the system in response to events sensed by the devices

  • The FPC (Functional Proxy Component) is a JAVA IMPLEMENTATION of the Logical Object functionalities

    • The communication between the Low Level Query Executor and the hardware devices are mediated by the FPC

    • Every FPC is tailored to fit a single sensor (or a group of them)

    • The system is provided with a FPC Factory, which automatically assembles FPCs on behalf of the user


Short introduction to perla middleware

BOUDARIES OF THE MIDDLEWARE: HLD and LLD (1)

PerLa

SWORD

User level

PerLa Language

XML over HTTP

Network level

Support for network

heterogeneity

Device level

HLD

LLD


Short introduction to perla middleware

BOUDARIES OF THE MIDDLEWARE: HLD and LLD (2)

  • PerLa Middleware C portable library (HLD, High Level Driver)

    • Communications with other PerLa Middleware components

    • General device management components (Timers, signal handling, Input/Output management…)

  • The user is just required to write the missing software needed to access his device’s hardware (LLD, Low Level Driver)

    • Standard library of device drivers (CAN bus, Digital-IO, …)


Short introduction to perla middleware

FACTORY AND FPCs ASSEMBLING (1)

FPC Factory

Register

Java environment

Desc.

Desc.

HLD

Device

Device Binding process: PLUG & PLAY

Once started up the HLD sends its DEVICE DESCRIPTOR towards the nearest Java device suitable to host a FPC


Short introduction to perla middleware

FACTORY AND FPCs ASSEMBLING (2)

Message format for an idraulic actuator

  • The device descriptor is a text file which describes CAPABILITIES and FEATURES of a device

  • Main sections of the descriptor:

    • Attributes and events of the device

    • Device features (available memory, uptime, available commands)

    • Network features (contact method, uptime, address format)

    • Message format expected by the LLD


Short introduction to perla middleware

FACTORY AND FPCs ASSEMBLING (3)

FPC Registration

FPC Registration

FPC Factory

Register

FPC

FPC

Java environment

Desc.

Desc.

HLD

Device

The Factory proceed assembling the FPC and registering it in the Register


Short introduction to perla middleware

FACTORY AND FPCs ASSEMBLING (4)

FPC Factory

Register

FPC

Java environment

Desc.

HLD

Device

The newly created FPC acknowledges the device of its creation

The device is ready to be used


Short introduction to perla middleware

FACTORY AND FPCs ASSEMBLING (5)

  • The FPC is AD-HOC CREATED for every physical device

    • The Factory, after parsing the Descriptor, combines different modules and configures them

    • New modules can be added if not present in the default library

  • The Low Level Query Executor communicates with the FPCs of the nodes to be queried

    • Every FPC is responsible for translating the requests in the format accepted by the controlled device

    • Given the device’s capabilities, the FPC has to check whether a particular request is feasible or not

  • The FPC tries to DELEGATE as much elaboration as possible to the physical device

    • The results of the partial ELABORATION need to be added to the outcome of the Low Level Query Executor


Short introduction to perla middleware

DEVICE MULTIPLEXING

  • Multiple devices can communicate over the same physical communication link

  • All network components in the PerLa Middleware implement a 2 layer stack

    • CHANNEL MANAGER: manages a point-to-point communication between two devices

    • ADAPTER: multiplexes different virtual channels on a physical one


Short introduction to perla middleware

NETWORK HETEROGENEITY

  • Network heterogeneity is a feature of WSNs

  • PerLa Middleware supports network heterogeneity by means of PerLa enabled Gateway

    • Every gateway replicates the Adapter – Channel Manager stack

    • At the moment just static routing is possible

    • The path between FPC and the device is created during the binding procedure


Short introduction to perla middleware

OPEN POINTS

The FPC Factory has yet to be implemented

The Device Descriptor needs to be completed


Low level query executor llqe

LOW LEVEL QUERY EXECUTOR (LLQE)

D. ViganòPolitecnico di Milano, Dipartimento di Elettronica e Informazione, Milano, Italy


Short introduction to perla middleware

LOW LEVEL QUERY EXECUTOR

A DATA LANGUAGE FOR PERVASIVE SYSTEMS

  • Brief introduction to LLQ Executor (LLQE)‏

    • GOALS, FUNCTIONALITIES and positioning within PerLa infrastructure

  • LLQE: PROPOSED ARCHITECTURE and future developments

    • Testing of expressions


Short introduction to perla middleware

LOW LEVEL QUERY EXECUTOR

A DATA LANGUAGE FOR PERVASIVE SYSTEMS

LLQ Executor


Short introduction to perla middleware

LLQE: GOALS AND FUNCTIONALITIES

A DATA LANGUAGE FOR PERVASIVE SYSTEMS

  • It receives a PARSED LOW LEVEL QUERY (Java Objects) as input

  • It has to allocate proper structures to manage received queries:

    • LOCAL BUFFER: in order to store sampled data, needed to execute the query

    • OUTPUT BUFFER: in order to store query results before they're sent to the application level

  • 3. It finally computes QUERY RESULTS using the above mentioned structures


Short introduction to perla middleware

HOW LLQE WORKS

A DATA LANGUAGE FOR PERVASIVE SYSTEMS


Short introduction to perla middleware

LLQE PROPOSED ARCHITECTURE (1)

A DATA LANGUAGE FOR PERVASIVE SYSTEMS


Short introduction to perla middleware

LLQE PROPOSED ARCHITECTURE (2)

A DATA LANGUAGE FOR PERVASIVE SYSTEMS

SINGLE QUERY

Pointer to QUERY DATA STRUCTURE, as received from the parser.

LOCAL BUFFERRECORDSTRUCTURE

LOCAL

BUFFER

OUTPUT

BUFFER

OUTPUT BUFFER RECORD STRUCTURE

Buffer records are Java Classes


Short introduction to perla middleware

LLQE PROPOSED ARCHITECTURE (3)

A DATA LANGUAGE FOR PERVASIVE SYSTEMS

QUERY REGISTER

  • The Query Register is the set of Query objects currently running in the node

  • A Query object must be created for each query received from upper levels:

    • How many records the local buffer should be able to store?

    • How is every local buffer record composed?

    • When every query needs to be executed?


Short introduction to perla middleware

EXAMPLE

A DATA LANGUAGE FOR PERVASIVE SYSTEMS

Output record structure

Information to compute query results

Time information needed to compute query results


Short introduction to perla middleware

TESTING OF EXPRESSION CLASSES (1)

A DATA LANGUAGE FOR PERVASIVE SYSTEMS

Thus LLQ has to deal with statements composed of SQL-like OPERATORS and EXPRESSIONS

While operators classes has been already tested, this work still had to be completed on expressions classes.


Short introduction to perla middleware

TESTING OF EXPRESSION CLASSES (2)

Every expression is composed of single elements called “nodes” which are Java Classes.


Short introduction to perla middleware

TESTING OF EXPRESSION CLASSES (3)

A test tool has been developed and implemented in order to quickly and efficiently test the existing expressions nodes.


Short introduction to perla middleware

EXAMPLE

N NodeAddition ConstantInteger 2 ConstantInteger 4 ConstantInteger ConstantInteger 6

N NodeDivision ConstantInteger 50 ConstantInteger 0 ConstantInteger ConstantInteger -


Short introduction to perla middleware

CONCLUSION

All expressions nodes have been tested and some errors have been detected and corrected

LLQExecutor architecture has been defined

The next steps will be the implementation of the proposed architecture and the testing of its functionalities (within the rockfall scenario).


Pilot join analysis state of art step 1

PILOT JOIN ANALYSISState of art – Step 1

M. MarinoPolitecnico di Milano, Dipartimento di Elettronica e Informazione, Milano, Italy


Short introduction to perla middleware

WHAT IS THE PILOT JOIN?

“A special operation that allows dynamic changes in the set of logical objects executing a specific Low Level Query, based on the results produced by another running query.”

...

“...it forces each involved logical object to start (or stop) the query execution if the joined stream contains (or not) a record that matches the current value of logical object attributes...” [1]

<Pilot Join Clause> PILOT JOIN <Correlated Table List>

<Correlated Table List> <Correlated Table> { ‘,’ <Correlated Table> }*

<Correlated Table> <Data Structure Name> ON <Condition>

E.g.:

PILOT JOIN BaseStationList ON

currentBaseStation = baseStationList.baseStationID


Short introduction to perla middleware

PILOT JOIN EXAMPLE

Suppose we want to monitor the temperature of some containers inside a container ship [2]

BUT

We are more interested in those containers exposed at direct sunlight

(sampled every hour)

Photo by Patrick Boury (CC)

Every container has a light sensor on the outside, and a temperature sensor in the inside, not directly connected to each other.

Light sensor

Temperature sensor


Short introduction to perla middleware

PILOT JOIN EXAMPLE

CREATE SNAPSHOT UnderTheSun (sensorID ID, light FLOAT, containerID ID)

WITH DURATION 1 h AS

LOW:

SELECT ID, light, containerID

SAMPLING EVERY 1 h

WHERE light > [threshold]

EXECUTE IF deviceType = “LightSensor”

CREATE OUTPUT STREAM Temperatures (sensorID ID, temp FLOAT, containerID ID) AS

LOW:

EVERY ONE

SELECT ID,temp, containerID

SAMPLING EVERY 1 m

PILOT JOIN UnderTheSun ON UnderTheSun.containerID = containerID

EXECUTE IF EXISTS (ALL)


Short introduction to perla middleware

PILOT JOIN DEFINITION

“PILOT JOIN is the key feature enabling the execution of context dependent queries: the content of the joined stream is a description of the current environmental situation, while the join condition defines the context-aware data tailoring the user is interested in.” [1]

  • This function adds context-awareness to the system, but some questions arise:

  • Is it the best way to model context-awareness?

  • Is it easy to be used in some complex cases?

  • Is there another (more powerful) way to implement a context-aware

  • WSN using a declarative language?

  • > Is someone else working on the same topic? <


Short introduction to perla middleware

WHO IS WORKING ON THE TOPIC?

An extended survey was made, analyzing about 15 related papers from 2004 to 2008 coming from different research laboratories around the world.

An analysis of similarities with PerLa was also performed.


W r t integration of context awareness and intelligence level e g context discovery

BRIEF COMPARISON

5

1

3

2

6

4

8

9

10

11

12

7

w.r.t. Integration of context-awareness and Intelligence level (e.g. Context Discovery)

Intelligence level

PerLa

Context-awareness integration level

TinyDB


Short introduction to perla middleware

KEY IDEAS

  • Context Reification

    • Explicit location for context information enables a reliable cross-context usage (e.g. Context node [2][3])

  • Context Nesting

    • The capability of nesting different contexts allows to define subcontexts which validity depends on the upper context

  • Context Temporal Management

    • A context may be valid only in a given time interval, keeping it explicit allows an easier management of time

  • Context Discovery

    • By analyzing sensor data it is also possible to discover new contexts,

    • not previously defined

  • Multiple Contexts per sensor

    • A sensor may join different contexts at the same time (eg. low battery sensor and exposed to sunlight) [4]

  • Context Priority

    • When orders to sensors interfere for active contexts, use priority information for each context


Short introduction to perla middleware

KEY IDEAS

The Pilot Join operation could be rethought in terms of explicit context, allowing PerLa to become a full context-aware system

But how to practically implement such a system?


Short introduction to perla middleware

IMPLEMENTATION

The context awareness in WSN is implemented in very different ways, but the key factor is to keep it work under a declarative language.

As an example, in [4][8][9][5] the concept of a declarative language is present, in other works is mentioned but no further detail is given (e.g. [10][7])


Short introduction to perla middleware

SOME EXAMPLE

Some conceptual schemata of various systems are presented here:

From [2]


Short introduction to perla middleware

SOME EXAMPLE

Some conceptual schemata of various systems are presented here:

From [4]


Short introduction to perla middleware

SOME EXAMPLE

Some conceptual schemata of various systems are presented here:

From [3]


Short introduction to perla middleware

SOME EXAMPLE

Some conceptual schemata of various systems are presented here:

From [7]


Short introduction to perla middleware

CONTEXT-AWARE EXAMPLE

  • Monitor the tampering sensor of the accessible containers when the ship is docked (GPS): if tampering is detected monitor nearby containers at higher frequency

  • (Four contexts may be involved, but the last one is created only after the other ones)

Photo by Patrick Boury (CC)

Tampering sensor


Short introduction to perla middleware

CONTEXT-AWARE EXAMPLE

  • Every container with low sensor batteriesmust be monitored at a lower frequency, but if it is exposed to direct sunlight, it must be monitored at a higher frequency

  • (Two concurrent contexts are involved, but the last one has a higher priority and overrides the sampling frequency defined by the first one)

Photo by Patrick Boury (CC)

  • Every container with fresh food must be monitored after one hoursince direct sunlight is detected, for a maximum time of three hours. Every 30 sec.

  • (Temporal dependent context is involved: the context is created after the sunlight detection, but it is activated after one hour)


Short introduction to perla middleware

CONTEXT-AWARE EXAMPLE

  • Monitor the data correlation between temperatures, if an unexpected situation is detected (e.g. outliers detection) create a new contextand raise an alarm

  • (e.g. a fire is spreading on the ship, but this event wasn’t defined!)

Photo by Patrick Boury (CC)


Short introduction to perla middleware

IMPLEMENTATION IN PERLA

  • How would it be possible to extend the Pilot Join in PerLa to enhance context-awareness, given the results of the other research teams?

  • Some ideas:

  • Add data structures for explicit context (just like the SNAPSHOT)

  • Create a Context Managerwhich enables active management of contexts

  • Formally define the behavior of context tables

  • Think about intelligent Context Discovery(for the future)


Short introduction to perla middleware

FUTURE WORKS

This presentation was just the first step

The next step will deal about the definition of suitable data structures to enable the context awareness in PerLa, in order to enhance the PILOT JOIN with a more powerful and general approach

BUT

...always keeping in mind the trade-off between a simple implementation and a powerful, yet usable, system


Future works

FUTURE WORKS

R. CamplaniPolitecnico di Milano, Dipartimento di Elettronica e Informazione, Milano, Italy


Short introduction to perla middleware

FUTURE WORKS

To achieve this we need a common, PORTABLE, Low Level framework

  • Current situation: the Java implementation of the Low Level Query Executor takes completely care of the query

    • The FPC is just used as a proxy to the end device, transmitting sampling commands and receiving the data

  • Improvements: DELEGATE PART OF THE COMPUTATION to the sensor devices

    • The FPC recomputes Low Level Queries in nanoQueries, accordingly to the capabilities of the single device

    • Every nanoQuery is executed directly by the device

    • The results, partially elaborated by the sensor itself, are transmitted back to the FPC and joined to obtain the outcome of the original Low Level Query


Short introduction to perla middleware

HLD and LLD

  • PerLa provides a portable framework which completely abstract the hardware of the single device called HLD (High Level Driver)

  • HLD is a set of common components which takes care of:

    • Timer

    • Communications with the FPC

    • Scheduling

  • The LLD (Low Level Driver) is the software needed by the HLD to access the hw features of the sensor

    • It has to be written by the user


Short introduction to perla middleware

nanoQUERY EXECUTOR (1)

HLD

nanoQuery

Executor

Hardware Abstraction Layer

MacroOperations

TimerTable

nanoQuery Buffer

Interrupt Manager

Scheduler

LLD

Hardware Drivers

The execution of nanoQueries needs the addition of new components in the HLD


Short introduction to perla middleware

nanoQUERY EXECUTOR (2)

Low Level

Query

Device

capabilities

nano

Query

  • The FPC has full knowledge about the device’s capabilities

    • The nanoQuery is created taking into account the Low Level Query to execute and the functionalities available on the sensor


Short introduction to perla middleware

nanoQUERY EXECUTOR

nanoQuery

I1

Z1

Z

I

Zk

In

nanoQuery

Executor

F

:

S1

S01

Sm

S0m

S

S0

  • nanoQuery Executor can be implemented as a FSM

    • nanoQueries can be thought as a program that describes how to process the inputs

    • Inputs are the data collected by the sensors

    • Outputs are sent back to the FPC


Short introduction to perla middleware

AGGREGATION

Aggregator

Node

N0

N1

N2

N4

N3

  • A node that routes the information coming from different devices can execute nanoQueries to perform aggregations

    • Example: the mean of the temperatures coming from a cluster of different nodes

  • The nanoQuery running on the aggregator node takes as input the outputs of the underlying nodes


Bibliography

[1] A Middleware Architecture for Data Management and Integration in Pervasive Heterogeneous Systems

F.A. Schreiber, R. Camplani, M. Fortunato, M. Marelli

Politecnico di Milano, Dipartimento di Elettronica e Informazione, Milano, Italy

Bibliography

[2] Scoping in Wireless Sensor Networks

Jan Steffan Ludger Fiege Mariano Cilia Alejandro Buchmann

Department of Computer Science, Darmstadt University of Technology

[3] A Context-Aware Approach to Conserving Energy in Wireless Sensor Networks

Chong, Krishnaswamy, Loke

School of Computer Science and Software Engineering

Monash University,Melbourne, Australia

[4] Proactive Context-Aware Sensor Networks

Sungjin Ahn and Daeyoung Kim

Real-time and Embedded Systems Laboratory,

Information and Communications University (ICU)

[5] Energy Efficient Spatial Query Processing in Wireless Sensor Networks

Kyungseo Park, Byoungyong Lee, Ramez Elmasri

Computer Science and Engineering, University of Texas at Arlington

[6] Context-Aware Sensors

Eiman Elnahrawy and Badri Nath

Department of Computer Science, Rutgers University


Bibliography1

Bibliography

[8] A spatial extension of TinyDB for wireless sensor networks

Paolino Di Felice, Massimo Ianni, Luigi Pomante

DlEI DEWS - Universita dell'Aquila, Italy

[9] Efficient and Practical Query Scoping in Sensor Networks

Henri Dubois-Ferri`ere

School of Computer and Communication Sciences

EPFL Lausanne, Switzerland - Department of Computer Science UCLA, Los Angeles, CA

[10] Adaptive middleware for contextaware applications in smarthomes

Markus C. Huebscher DSE Group, Department of Computing Imperial College London

Julie A. McCann DSE Group, Department of Computing Imperial College London

[7] A Self-Adaptive Context Processing Framework for Wireless Sensor Networks

Amirhosein Taherkordi, Romain Rouvoy, Quan Le-Trung, and Frank Eliassen

University of Oslo, Department of Informatics

[11] TinyDB: An Acquisitional Query Processing System for Sensor Networks

SAMUEL R. MADDEN Massachusetts Institute of Technology

MICHAEL J. FRANKLIN and JOSEPH M. HELLERSTEIN UC Berkeley

WEI HONG Intel Research, Berkeley

[12] Context Discovery in Sensor Networks

Chia-Hsing HOU, Hung-Chang Hsiao, Chung-Ta King, Chun-Nan Lu

Computer Science, National Tsing-Wua University, Hsinchu, Taiwan,


  • Login