Dehems/Papers/External

Queue

• Full TCP/IP for 8-bit architectures (by A. Dunkels);

• http://www.sics.se/contiki/publications-and-talks.html;

• http://www.jlhlabs.com/TinyOS.htm;

Query Processing for Sensor Networks

Links

• CiteSeerX link;

• original paper;

• cached paper;

Notes

• it proposes to design and implement a distributed query processor;
• the main goals are:
  • provide a declarative method to express the queries;
  • focus the query planner to be power efficient, over time efficient;
• as a technical approach they want to tightly couple the query planner / executor with the network (transport) layer;
• again it uses a special node / device --- the gateway;
• each sensor reading is considered as a tuple (record) that contains: identifier, location, timestamp, and reading;
• all the tuples from the same class of sensors constitute a distributed (global) table;
• thus the entire sensor network becomes a collection of tables for each sensor type;

• it mentiones the ideea of data fusing --- a way to "clean" the raw data, to remove the possible noise;

• it makes a distinction between long running and periodic queries and event driven queries and triggers;

• the paper focuses, and optimizes the language for long running and periodic queries, mainly on aggregate queries;

• it presents three ways to integrate data aggregation and communication:
  • direct delivery --- each packet is sent individually and data is aggregated at the aggregation leader node;
  • packet merging --- multiple packets are sent at the same time (in the same frame), the data is still aggregated at the leader;
  • partial aggregation --- data is aggregated at each node (as it arrives), and pushed upwards until it reaches the leader;
• it presents a way to synchronize the data aggregation at sensor nodes;
• it discusses the AODV --- Ad Hoc on Demand Distance Vector Routing --- in the context of query processing;

Query Processing in Sensor Networks

Links

• CiteSeerX link;

• DOI link;

• cached paper;

QueryAgent: A General Query Processing Tool for Sensor Networks

Links

• DOI link;

• cached paper;

Notes

• presents the general usage patterns for sensor networks:
  • active querying (pull);
  • passive monitoring (push);
  • combined;
• presents the main communication models in sensor networks:
  • unicast;
  • area multicast;
  • area anycast;
  • broadcast;
• proposes a general programmable interface (one set of operations per communication model):

  • open (query_id, measurement, destination) => transport_protocol;

  • listen (query_id, data) => data;

  • start (query, transport_protocol, measurement, destination);

  • finish (query, data) => data;

• proposes a subset of SQL for sensor interrogation:
  • it has three main query classes, based on syntax:
    • simple queries (select like);
    • complex queries (select like, but with aggregates or joins);
    • event driven queries;
  • it allows to express:
    • active queries;
    • passive queries;
    • event driven queries;
• it proposes a way to map between the SQL language and programmable interface;

• it has a nice introduction to sensor programming model --- see section 2;

• it has a comparison between the proposed programming model, and existing models in different embedded operating systems --- see section 3;

Design and Implementation of a Framework for Efficient and Programmable Sensor Networks

• CiteSeerX link;

• original paper;

• cached paper;

Querying and Tasking in Sensor Networks

Links

• CiteSeerX link;

• cached paper;

Notes

• classifies the operations in a sensor network into:
  • querying;
  • tasking;
• it introduces the idea of a special node --- frontend:
  • that is used as an interface to the entire sensor network;
  • everything that goes in or out the network passes through it;
  • it acts as a gateway;
• querying:
  • it consideres a query as a synchronous operation;
• tasking:
  • activities that involve coordination among sensor nodes;
  • they are considered asynchronous;
• they propose:
  • SQTL --- Sensor Querying and Tasking Language;
  • SEE --- Sensor Execution Environment;

• the nodes are seen as distributed set of collaborating nodes with active, programmable capability;

• sensor model:

  • a device is called a sensor node:

    • on each sensor node we can instantiate a sensor class that represents all the actual physical sensors on that node that is able to detect a certain phenomenon;

• each SQTL program packaged as an SQTL wrapper:

  • the SQTL wrapper can be seen as a service that can be deployed into the sensor network (stopped, started, installed, etc.);
• in fact:
  • SQTL is a device independent language;
  • SEE is an application container, that also mediates all the inputs and outputs between nodes (or applications);

Sensor Information Networking Architecture and Applications

• CiteSeerX link;

• cached paper;

A Lightweight Sensor Network Management System Design

Links

• DOI link;

• cached paper;

Notes

• it focuses on the management tasks of a wireless sensor network;
• it has a comprehensive list of other management protocols:
  • ANMP --- Ad Hoc Network Management Protocol;
  • MANNA --- Management Architecture for Wireless Sensor Networks;
  • sNMP --- Sensor Network Management Protocol;
  • SNMS --- Sensor Network Management System;
• it achieves its goals by employing a lightweight RPC system, through which the user can call any procedure on a node, and inspect any variable; (only for applications written in nesC for TinyOS);

Computing Aggregates for Monitoring Wireless Sensor Networks

• cached paper;

Emstar: A Software Environment for Developing and Deploying Heterogeneous Sensor-Actuator Networks

• cached paper;

Fjording the Stream: An Architecture for Queries over Streaming Sensor Data

Links

• DOI link;

• CiteSeerX link;

• cached paper;

Programming Models for Sensor Networks: A Survey

• cached paper;

SSI Protocol Specification

Links

• original paper;

• cached paper;

Notes

• Foreword section:

  • used to transfer data between sensor unit(s) and a terminal;

• Requirements section:

  • The wireless sensor units must operate long period on a small battery. Thus the protocol must not be too complex.;

• SSI Protocol section:

  • The SSI protocol is asynchronous and stateless.;

• Payload section:

  • address field (1 byte) -- used to identify different sensors bound to the same communication channel;
  • command field (1 byte)
  • command dependent data;
• commands:
  • query -- SSI protocol version, message delay, etc.;
  • discover -- determines the sensor identifier (2 bytes), type (1 byte), min value (4 bytes), max value (4 bytes), value scale (1 byte);
  • reset;
  • configuration -- get / set sensor attributes (type (1 byte), value (variable length));
  • request -- sensor data (list of sensor identifier, value pair);
  • observers:
    • asks the sensor to automatically send notifications with sensor values;
    • it allows to specify notifications interval, count, and even the update threshold;

ZigBee Specification

• cached paper;

Service Oriented Sensor Web

• original paper;

• cached paper;

SensorGrid: Integrating Sensor Networks and Grid Computing

• original paper;

• cached paper;

Open Sensor Web Architecture: Core Services

• original paper;

• cached paper;

Using SensorML to describe a Complete Weather Station

• original paper;

• cached paper;

SensorML for Grid Sensor Networks

• original paper;

• cached paper;

Creation of Specific SensorML Process Models

• original paper;

• cached paper;

OpenGIS Sensor Model Language (SensorML) Implementation Specification

• original paper;

• cached paper;

An Adaptive Communication Architecture for Wireless Sensor Networks

Links

• original paper;

• cached paper;

Notes

• it raises the problem of heterogenuos sensor networks:
  • mainly the mismatch between the different protocol stacks;
  • the difficulty to bridge between one network and another;
  • the difficulty in implementing portable application protocols on-top of existing stacks;
• presents the two main classes of protocols:
  • address free --- usually used for data dissemination;
  • name based --- usually used for data collection;
• provides an insight on MAC protocols;
• it proposes two solutions: Chameleon and Rime;
• Chameleon:
  • it contains header transformation modules;
  • each packet is composed from some attributes (instead of the protocol-dependent header) and data;
  • we could say it provides an abstract data-link protocol;
  • some (header transformation) modules should also implement additional logic (such as retransmission);
• Rime:
  • it addnotates the application data with attributes;
  • it defines a set of attributes:
    • the attributes stick as the packet moves upward into the stack --- they enable cross-layer information sharing;
  • it introduces the concept of channels --- each channel is a protocol stack, thus allowing for multiple protocol stacks to coexist;
  • it exposes a set of communication primitives:
    • abc --- anonymous best-effort single-hop broadcast --- no addresses;
    • ibc --- identified best-effort single-hop broadcast --- adds sender address;
    • uc --- best-effort single-hop unicast --- adds receiver address;
    • suc --- stubborn single-hop unicast --- repeatedly sends a message until stopped;
    • ruc --- reliable single-hop unicast;
    • polite --- polite single-hop broadcast --- it doesn't forward the same packet if it was sent previously;
    • ipolite --- identified polite;
    • mh --- best-effort multi-hop unicast --- it implies routing or route discovery;
    • rmh --- reliable mh;
    • nf --- best-effort network flooding;

Miscellaneous

Embedded Web Services --- Making Sense out of Diverse Sensors (may 2007):

• integration requirements:
  • object and data representation;
  • semantics and service discovery;
• BACnet:

  • specified 23 standard object types, and represented a device as a collection of objects supporting application-level services (for data sharing, alarm and event management, trending, scheduling, and remote device and network management);

  • the representation of all of the data objects that can be sent over BACnet is defined in abstract syntax notation (ASN.1);

  • to represent intended behaviors, specific device and object definitions are collected into application profiles;

• CIP --- see below;

• ZigBee:

  • seeks to provide integration at the application level over IEEE 802.15.4 by creating application profiles;

• embedded web-services:

  • In the realm of wireless sensor networks, can we have the best of both worlds? Can we retain the compact binary representations and finely crafted application profiles that we demand for embedded devices and still have automated service discovery, composition, and the ability to deal with diverse information sources that we expect in enterprise applications? --- a very good question;

EtherNet/IP --- An Application-Layer Protocol for Industrial Automation (may 2003):

• PDF version;

• CIP (Control Information Protocol):

  • is a communication protocol for transferring automation data between two devices;

  • every network device represents itself as a series of objects;

  • each object is simply a grouping of related data values in the device;

  • All CIP devices with the same device type must contain an identical series of application objects, known as the device profile;

  • Supporting a device profile lets you easily understand and switch from a vendor of one device type to another vendor with that same device type;

  • a device vendor can also group application-layer objects into assembly objects;

  • data access: polled, cyclic, change-of-state;

IEEE-1451.2 Update (january 2000):

• smart sensors + smart actuators === smart transducers;
• characteristics:
  • self-identification;
  • self-testing;
  • adaptive calibration;
• STIM (Smart Transducer Interface Module):
  • STIM === transducer + communication component;
  • it provides the identification;
• NCAP (Network Capable Application Processor);
• TII (Transducer Independent Interface);
• STIM is linked to NCAP by TII;
• transducer blocks:
  • functional blocks that can be pluged into a logical backplane (what is a backplane?);
  • it runs on the NCAP;
  • each block is connected to a STIM;

• the normal data format for a smart transducer is an IEEE-754 floating point number using standard SI units;

• it describes the physical wired communication;

• software protocol:

  • from the point of view of the NCAP, the STIM looks like a memory device;

  • the address is composed of a channel (1 byte) and service (1 byte?);
• correction engine;

JSR 256: Mobile Sensor API:

• SensorConnection:

  • represents a connection to a real sensor device;

  • it takes an URL;

• SensorInfo:

  • provides:
    • quantity (ex. temperature, voltage, etc.);
    • context type (where is the measurement taken):
    • connection type (ex. embedded, wired, etc.);
    • model;
    • URL;
    • description;
    • channel information;
    • generic properties;

• SensorManager, SensorListener;

• Channel:

  • a way to structure the data;

• ChannelInfo:

  • provides: name, accuracy, data type (int, double, Object), ranges, scale, unit;
• Data:

  • the measured data is returned as an array of Data objects;

  • each Data object encapsulates the data of one channel;

  • each Data object can contain an array of values;

  • each Data object has an ChannelInfo property;

  • provides: value, timestamp, validity, uncertainty;

• Condition, ConditionListener --- used to filter data;