QuadraSpace Protocol

QS
T
AF
QuadraSpace
DR
Open Sensor Network Services
http://www.quadraspace.org
Introduction and XML Protocol
version 0.4 DRAFT - 2009.05.10

This is...

IN
K S!
RS

T
OE
W GR
AF O
R
DR
P

Outline

T
It all began with a sensor...

AF
The QuadraSpace Project
QuadraSpace protocol and services
DR
Roadmap
Contacts

Sensors
Sensors are changing the user experience in many
embedded, pervasive and mobile products

T
AF
They are the new revolution in gaming console
(Nintendo Wii), mobile devices (Apple iPhone),
automotive safety (ABS, ESP, night vision, side and
DR
park assist...), in-house computers

“sensing the world” is the key feature for Earth
environment monitoring, industrial automation,
urban safety and security, trafﬁc control

Sensors for all
Beside industrial, professional, and military
applications, sensors are becoming widely adopted in

T
civil, semi-professional and homebrew applications
Microcontrollers, communication modules, sensors

AF
and development environments are getting more
powerful yet cheaper
DR
The Web shows that activities in this ﬁeld are
growing:
SunSPOT, Arduino, Makezine, TinyOS are products and initiatives that bring
motes and sensor to a enormous potential community
Interaction designers and handcrafter embed sensors and logic in their
product to give them intelligence; homebrew entustiasts use sensors to make
their house smarter and more funny

Fill the gap
Motes and sensors are just the first step: protocols
and services are key elements to exploit sensor

T
networks potential
Once a sensor platform has been chosen as suitable

AF
for his project, the developer has to set-up the back-
end: communication protocol, server, database, event
manager and web application
DR
In a certain sense, every time we define a
communication protocol and set-up a back-end for
data collection and trigger management, we
reinvent the wheel
QuadraSpace project tries to fill the gap!

Project “QuadraSpace”
An open protocol for sensor registration, data
collection, remote communication and activation

T
A set free services based on such a protocol for

AF
managing motes and collecting their data

A set of libraries for different programming
DR
languages and development environment

A low-cost computing project, which aims to
encourage adoption of sensor network infrastructure
using inexpensive hardware and software

QuadraSpace Protocol
Simple

T
Based on HTTP/HTTPS and XML, it can be implemented on a wide range of
hardware and software
Scaled-down extensions allow connection to simpler transports (e.g.: SMS)

AF
Open
protocol and developer libraries published under the Apache 2.0 license
DR
Free
can be adopted without having to pay royalties
can be exploited signing-up for a free-of-charge account on the QuadraSpace
server to start managing events and data acquired by sensors (services are
still under development: see Roadmap)

QuadraSpace Protocol
XML Data Model
RESTful HTTP/HTTPS with Basic Authentication

T
http://SERVER/motes
GET: read list of motes

AF
POST: register a new mote

http://SERVER/motes/ID
GET: read info of an existing mote
PUT/DELETE: update/remove registration of an existing mote
DR
http://SERVER/motes/ID/events
GET: read all events for that mote (with optional parameters)
POST: notify a new event for the mote with ID moteID

http://SERVER/triggers/
GET: read list of triggers
POST: register a new trigger

http://SERVER/triggers/ID
GET: read info of an existing trigger

HTTP client limitations
Unfortunately, some simple HTTP client
implementations (such as the default provided with

T
Java ME CLDC/MIDP devices) support only GET and
POST methods

AF
Although is it possible to open low-level TCP sockets
and to implement the HTTP protocol from scratch, if
network trafﬁc is done through HTTP Proxy on well-
DR
known ports (80 and 8080) the runtime may limit
connectivity unless the application is digitally signed
In order to support this kind of devices, QuadraSpace
deﬁnes a set of REST Exceptions, that map missing
HTTP features on extended request headers

QuadraSpace REST Ex
The mote using any QuadraSpace REST Exception
must include following header in HTTP request:

T
X-QuadraSpace-Ex: enable

AF
Missing method (PUT, DELETE...)
DR
X-QuadraSpace-Method: MISSING_METHOD

For instance:
X-QuadraSpace-Method: PUT
X-QuadraSpace-Method: DELETE

Devices
Core QuadraSpace protocol has been designed for
devices equipped with TCP/IP networking and able to
send data using HTTP/HTTPS POST sessions

T
Devices with other kind of communication interfaces

AF
can access QuadraSpace using a set of gateways
DR
Hi-end Device
HTTP/HTTPS POST + Basic Authentication (and OAuth)

Mid-end
HTTP GET (no buffering) + Basic Authentication

Low-end
Non-IP connectivity: USB, SMS, Bluetooth, ZigBee...

QuadraSpace
Hi-end devices Mid-end devices Low-end devices

T
QuadraSpace QuadraSpace Gateway to
Protocol
XML tiny QuadraSpace

AF
Basic Basic
Custom
Authentication
Authentication Authentication
DR HTTPS HTTP Custom
Transport

IP/Mixed IP/Mixed Non-IP
Network

RSS

Quadra
Web XHT
ML

T
AF
QuadraSpace
QuadraServer
Other protocol
DR
Quadra Quadra
Gate Box

Bluetooth
SMS ZigBee USB
TCP

The “Quadra” family
QuadraSpace
the protocol itself and developer libraries for mobile and embedded platforms

T
QuadraServer
the backend which manages motes, events, triggers and actions. It exchanges

AF
data with all other modules using the QuadraSpace protocol

QuadraWeb
The QuadraServer front-end for web administration and event feeds
DR
QuadraGate
a set of adapters between the QuadraServer and other public-network custom
protocols (SMS, MMS, email...)

QuadraBox
a software module to be installed locally as gateway between sensor network
(Bluetooth, ZigBee, ZWave...) and the QuadraServer

QuadraServer
It is the core of the QuadraSpace back-end

T
It is responsible for:
managing user account

AF
managing motes registration
managing event data collection
activating triggers on user-deﬁned event conditions
DR
All communication from and to the QuadraServer is
based on the QuadraSpace protocol
In early stage of the project, the QuadraServer will be
run by the QuadraSpace team and made freely
accessible to all subscribers

QuadraWeb
It is the web front-end of the QuadraServer

T
It provides:

AF
web application for user registration, mote registration, event management,
triggers conﬁguration
export and analysis of data events
RSS/Atom feed to user’s events (feeds subscription is subject to user
DR
authentication)
widgets to made publicly available subsets of data on blogs and websites (e.g.:
“realtime CO2 of my neighborhood”

QuadraWeb is developed as an extension of the
QuadraServer

QuadraGate
It is the module responsible for accessing the
QuadraServer using public networks and protocols

T
other than HTTP REST

AF
It receives event notiﬁcation via SMS, MMS, email,
TCP, UDP and any other protocol over the public
network and encapsulates them in QuadraSpace
DR
events to the QuadraServer

A preliminary implementation QuadraGate will be
made available with the QuadraServer (initial release
will support only SMS)

QuadraBox
The QuadraBox is pretty similar to the QuadraGate,
but acts on a local context: it works as a gateway

T
between local networks (Bluetooth, ZigBee, Zwave,
infrared, proprietary wired and wireless

AF
connections) and the QuadraServer
QuadraBox is a software component to be installed
and customized on a small computer connected to
DR
the Internet and able to communicate with sensor
network in use
QuadraBox will be released as a Java application and
an open API for customizing it to connect to custom
protocols

QuadraServer

T
Internet

AF
QuadraBox
DR
Bluetooth

USB

Gate or Box?
QuadraGate and QuadraBox seem to be similar, but
actually they are pretty different:

T
Scope
QuadraGate works with public networks and services (such as SMS, email...)

AF
QuadraBox works with private PANs (Personal Area Networks, such as
Bluetooth and ZigBee)

Architecture
DR
QuadraGate is ready-to-run and part of QuadraServer
QuadraBox has to be extended and conﬁgured to support custom protocols

Installation
QuadraGate (and QuadraServer) installation will be made available by the
QuadraSpace Project Team
Once extended and conﬁgured, QuadraBox is to be installed close to the
sensors and connected to the Internet using local router

QuadraSpace entities
Mote
the physical board equipped with one or more sensors and one or more
communication module

T
Sensor

AF
the component (installed on a mote) responsible of acquiring data, which can
be described by one or more channels
DR
Event
a single data sample acquired by the sensor, marked with a timestamp and a
location

Trigger
a mechanism that performs an action when an incoming event satisﬁes a
certain condition

Use cases
User Registration
A person creates an account for his motes, his events, his actions

T
Mote Registration

AF
Before pushing events, a board has to register itself on the QuadraSpace
“world”. Registration is a complete description of the mote and includes the
association to a user account
DR
Event notiﬁcation
Once registered, a mote can notify events, which are data samples collected
by its sensors

Actions
When a condition for a certain kind of event is satisﬁed, the QuadraServer can
perform actions, such as sending messages or activating remote devices

Application scenario
Design your mote and write your software using the
QuadraSpace protocol and libraries

T
AF
Register your mote and setup triggers on the
QuadraSpace web site
DR
RUN YOUR APPLICATION!

The QuadraServer will collect data from your motes
and automatically will perform actions on trigger
conditions

QuadraSpace objects

Mote XML

T
describes the mote, with its location, board, sensor and communication
modules

AF
Event XML
describes a single data event pushed by a mote sensor, which its timestamp,
DR
location and value for each sensor channel

Trigger XML
describes the event conditions that execute actions on the server (Trigger
XML is still under speciﬁcation)

Mote
The Mote is an autonomous physical board equipped
with logic, memory, sensors and communication

T
modules
It is described by

AF
An unique ID
Board description (vendor-model string pair)
Location (that may change during operations)
DR
Latitude, longitude, speed, altitude, heading SunSPOT, by Sun Microsystems, is one of
the most powerful motes available
One or more sensors
A sensor manages a type of data (e.g.: temperature, acceleration, humidity...) through one or more
channels (e.g., a 3-axis accelerometer has three channels). A channel contains a scalar value and is
described by type (int, ﬂoat...), unit, range, scale, resolution...

One or more communication interfaces
An interface has a set of properties describing communication module (ethernet, GSM, Bluetooth...),
address type (static, dynamic...) and encapsulation model (e.g. HTTP over ZigBee)

MOTE
BOARD LOCATION

ID VENDOR MODEL LAT LON ALT HEAD SPD FIX

SENSORS

SENSOR
DATA
QUANTITY
ID TYPE

T
CHANNELS

CONTEXT
CHANNEL

AF
VENDOR ID TYPE MIME UNIT MIN MAX RES ACC

MODEL
DR
INTERFACES

INTERFACE

ID TYPE ALWAYSON SERVER CLIENT

ADDRESS
STATIC TYPE VALUE
EXCLUSIVE

Mote XML
<mote id=quot;MY_IDquot;>
<board>
<model>The board model</model>
<vendor>The board vendor</vendor>
</board>

T
<location latitude=quot;LATquot; longitude=quot;LONquot; altitude=quot;ALTquot; heading=quot;HEADquot; speed=quot;SPDquot; fixed=quot;true|falsequot;/>
<sensors>
<sensor id=quot;SENSOR_IDquot; context=quot;DEVICE|USER|AMBIENTquot; type=quot;SENSOR_TYPEquot;>

AF
<model>The sensor model</model>
<vendor>The sensor vendor</vendor>
<data quantity=quot;PHYSICAL_QUANTITYquot;>
<channels>
<channel id=quot;CHANNEL_IDquot; type=quot;INT|FLOAT|BOOLEAN|BINARYquot; mimetype=quot;MIMEquot; unit=quot;UNITquot;
min=quot;MINquot; max=quot;MAXquot; resolution=quot;RESquot; accuracy=quot;SCALEquot;/>
DR
</channels>
</data>
</sensor>
</sensors>
<interfaces>
<interface id=quot;IDquot; type=quot;TYPEquot; alwayson=quot;true|falsequot; client=quot;true|falsequot; server=quot;true|falsequot;>
<address exclusive=quot;true|falsequot; static=quot;true|falsequot; type=quot;TYPEquot;>
<value></value>
</address>
</interface>
</interfaces>
</mote>

Mote XML: mote
<mote id=quot;MY_IDquot;>

<board>
<model>The board model</model>

T
<vendor>The board vendor</vendor>
</board>

AF
ID is the unique identifier of the mote. It will be
automatically generated by the QuadraServer
DR
Board identifies model and vendor name of the
mote’s hardware. It could be useful for motes
manager to identify a specific kind of board being
used

Mote XML: location
<location latitude=quot;LATquot; longitude=quot;LONquot; altitude=quot;ALTquot; heading=quot;HEADquot;
speed=quot;SPDquot; fixed=quot;true|falsequot;/>

T
A mote can be either fixed or mobile, with an
assigned or unknown location

AF
If known, location is expressed by:
latitude, longitude and altitude (float)
heading, that is the “direction the mote is pointing towards”
DR
speed, if the mote is mounted on a vehicle
the boolean attribute fixed, which specifies if the location may change during
operations

If available, the location will be included in event
notification

Mote XML: sensor

Each Sensor has a ID (unique within the mote)

T
Sensor’s context identiﬁes the target of data

AF
acquisition of the sensor itself and can be device,
ambient or user
Device context is for sensors that describe the state of the device (e.g.:
DR
battery or signal level, gyroscope)
Ambient context refers to sensors that read environmental data (e.g.:
temperature, CO2, noise level)
User context is for sensor which data is related to the user, to which the mote
is considered attached (e.g.: blood pressure, speed, location...)

The type identiﬁes the family of the sensor
Valid types are termometer, accelerometer, GPS...

Mote XML: sensor

<model>The sensor model</model>
<vendor>The sensor vendor</vendor>

T
<data quantity=quot;PHYSICAL_QUANTITYquot;>

AF
As for the mote, each sensor has an optional model
and vendor name, useful for users to get info about
the hardware in use
DR
The sensor acquires data of a speciﬁed quantity that
can be:
a physical quantity (e.g.: temperature, acceleration, pressure... )
a state (boolean true or false)
a binary object (such as an image capture by a digital camera)

Mote XML: sensor
<channels>
<channel id=quot;CHANNEL_IDquot; type=quot;INT|FLOAT|BOOLEAN|BINARYquot;
mimetype=quot;MIMEquot; unit=quot;UNITquot;
min=quot;MINquot; max=quot;MAXquot; resolution=quot;RESquot; accuracy=quot;ACCquot;/>
</channels>

T
Data is expressed by one or more channels (e.g.: an
accelerometer may have 3 channels)

AF
Each channel has:
an ID (e.g.: “Y axis” or “temp1”)
DR
a type (integer, floating point, boolean or binary)
the mimetype (plain/text for int, float, boolean and specific type con binary
data, for instance image/png for a picture)
the unit of measure (e.g.: m/s, A, V...)
for integer and float types, the channel has also min, max, resolution and
accuracy, which specify respectively the minimum and maximum value
admitted (e.g.: 0V and 12V), the smallest amount of change (e.g.: 1mV) and
the degree of quality of the measure

Mote XML: interface
<interfaces>
<interface id=quot;IDquot; type=quot;TYPEquot; alwayson=quot;true|falsequot;
client=quot;true|falsequot; server=quot;true|falsequot;>

A mote is equipped with at least one communication

T
modules which provide one or more interfaces

AF
For instance, a GPRS module provides two interfaces, one for SMS and one for
packet-switched data

An interface is described by
DR
an ID
the type, which identiﬁes the class of communication module (e.g.: Bluetooth
RFCOMM, IrDA OBEX, ZigBee serial, GSM, SMS, email, TCP, UDP...)
a boolean attribute that speciﬁes whether the interface channel is always
connected and available
two attributes that specify whether the interface acts as a client, a server or
both (e.g.: it is able to accept connections or not)

Mote XML: address
<address exclusive=quot;true|falsequot; static=quot;true|falsequot; type=quot;TYPEquot;>
<value></value>
</address>

T
An interface has an address associated with these
attributes:

AF
exclusive, if assigned only to this interface, and static, if does not change
(e.g.: a phone number is usually exclusive and static, while an dynamic IP
address is not static but can be considered as exclusive for certain amount of
time)
DR
type, which speciﬁes the addressing schema of the communication interface.
Allowed values include IP addresses, names, BD addresses, MAC, ZigBee
device numbers, phone numbers, email addresses
if static and exclusive, an address may have also a value, which is the actual
interface address (e.g.: phone number associated to the SIM card, IP address
of the network card, BD address of the Bluetooth module and so on). For
dynamic addresses, the value may be included in the event notiﬁcation
message

Mote examples
Let’s try to describe some motes using the
QuadraSpace Mote XML

T
AF
High-end:
SunSPOT wireless temperature sensor
Camera sensor based on Android phone
DR
Mid-end:
Arduino 2009 with Ethernet Shield and LM35DZ temperature sensor

Low-end:
SMS humidity sensor with Arduino Nano and GSM module

SunSPOT
<mote id=quot;My_SunSPOTquot;>
<board><model>SunSPOT</model><vendor>Sun Microsystems</vendor></board>
<sensors>
<sensor id=quot;TEMPSENSORquot; context=quot;AMBIENTquot; type=quot;thermometerquot;>

T
<data quantity=quot;TEMPERATUREquot;>
<channels>
<channel id=quot;temp1quot; type=quot;floatquot; unit=quot;celsiusDegreequot;

AF
min=quot;2quot; max=quot;150quot; resolution=quot;1quot; />
</channels>
</data>
There is no location: it is a freerange SunSPOT,
</sensor> location may change during operation
</sensors>
DR
<interfaces>
<interface id=quot;IDquot; type=quot;802.15.4quot; alwayson=quot;truequot; client=quot;truequot;>
</interface>
Interface may not specify the address, if it not
</interfaces> addressable outside the private network of the wireless
sensors. This is the case of SunSPOTs, which operate in
</mote>
their custom wireless network and use proxy executed by
the basestation to connect the Internet

Android camera
<mote id=quot;My_Android_Cameraquot;>
<board><model>G1</model><vendor>HTC</vendor></board>
<sensors>
<sensor id=quot;CAMERAquot; context=quot;AMBIENTquot; type=quot;CAMERAquot;>

T
<data quantity=quot;IMAGEquot;>
<channels>
<channel id=quot;camera1quot; type=quot;binaryquot; mimetype=”image/png”/>

AF
</channels>
</data>
</sensor>
</sensors>
DR
<location latitude=quot;39.70594quot; longitude=quot;9.316406quot; />
<interfaces>
<interface id=quot;IDquot; type=quot;3Gquot; alwayson=quot;falsequot; client=quot;truequot; />
</interfaces>
</mote>

The data captured by the sensor (a camera) of this mote (an
Android phone) in an image: its type is binary, mimetype is
the format of the image stream (in the example it is PNG).

Arduino Ethernet
<mote id=quot;My_Arduino_Ethernetquot;>
<board><model>Arduino2009 Ethernet Shield</model><vendor>tinker.it</vendor></board>
<sensors>
<sensor id=quot;TEMPSENSORquot; context=quot;AMBIENTquot; type=quot;TERMOMETERquot;>
<model>LM35DZ</model>

T
<channels>

AF
</channels>
</data>
</sensor>
DR
</sensors>
<location latitude=quot;39.70594quot; longitude=quot;9.316406quot; fixed=quot;truequot;/>
<interfaces>
<interface id=quot;IDquot; type=quot;ETHERNETquot; alwayson=quot;truequot; client=quot;truequot;>
<address exclusive=quot;truequot; static=quot;truequot; type=quot;IPquot;>
<value>192.168.2.177</value>
</address>
</interface>
</interfaces>
</mote>

Arduino Nano
<mote id=quot;My_Arduino_Nanoquot;>
<board><model>Arduino Nano</model><vendor>tinker.it</vendor></board>
<sensors>
<sensor id=quot;HUMSENSORquot; context=quot;AMBIENTquot; type=quot;HUMIDITY_SENSORquot;>
<data quantity=quot;HUMIDITYquot;>

T
<channels>
<channel id=quot;hum1quot; type=quot;floatquot; unit=quot;parcentagequot;

AF
</channels>
</data>
</sensor>
</sensors>
DR
<location latitude=quot;39.70594quot; longitude=quot;9.316406quot; fixed=quot;truequot;/>
<interfaces>
<interface id=quot;IDquot; type=quot;SMSquot; alwayson=quot;truequot; client=quot;truequot; server=”true”>
<address exclusive=quot;truequot; static=quot;truequot; type=quot;PHONENUMquot;>
<value>+39123123123</value>
</address>
</interface> Data from this sensor will be collected
through the QuadraGate service
</interfaces>
</mote>

End-points for motes
Motes described with Mote XML instances are
managed with RESTful HTTP/HTTPS end-points

T
All calls have to include Basic Authentication

AF
http://SERVER/motes
POST: register a new mote
DR
GET: read list of motes

http://SERVER/motes/ID
PUT: update registration of an existing mote
DELETE: unregister an existing mote
GET: read info of an existing mote

/motes
Reads the list of motes; add a new mote to the list

T
GET

AF
Returns all motes registered by the user
Root element for the response is <motes>
No parameters
DR
POST
Registers a new mote and return assigned ID in the <mote> root element
Expected response has body: <mote id=”ID_ASSIGNED_BY_THE_SERVER”/>

Request body is an instance of Mote XML

Both methods require HTTP Basic-Authentication

/motes Status Codes
GET

T
200 OK: the list is returned by the server
401 Unauthorized: user credential are not valid

AF
500 Internal Server Error
503 Service Unavailable

POST
DR
201 Created: new mote entry has been created in the QuadraServer
400 Bad Request: the XML submitted is not correct

/motes/ID
Reads/writes the Mote XML instance of mote “ID”
GET

T
Returns the mote “ID”
No parameters

AF
Response body is an instance of Mote XML

PUT
Updates the mote “ID”
DR
No parameters
Request body is an instance of Mote XML

DELETE
Deletes the mote “ID”
No parameters, no response body

All methods require HTTP Basic-Authentication

/motes/ID Status Codes
GET

T
200 OK: required mote is returned by the server

AF

PUT and DELETE
DR
200 OK: mote entry has been updated/deleted in/from the QuadraServer

Events
An event is a data sample of a sensor or an heartbeat
notified by a mote to the QuadraServer. An event may

T
trigger an action
An event consist of:

AF
a type, that specified if the event is a data sample or an hearbeat
a source identifier, defined by the ID of the mote and the ID of the sensor (a
mote may have more than one sensor!)
DR
a timestamp
location (if the mote has been moved from position specified during
registration)
the data payload, which contains the value read by each channel of the sensor

Event are notified via HTTP POST with Basic
Authentication

Event structure

EVENT

T
SOURCE LOCATION
TIMESTAMP

MOTE_ID SENSOR_ID LAT LON ALT HEAD SPD

AF
DELAY TYPE

DATA

CHANNEL
DR
ID NEEDSTOKEN VALUE

Event

T
<event timestamp=”MY_TIMESTAMP” delay=”DELAY” type=”sample|heartbeat”>
<source moteID=”MY_MOTE_ID” sensorID=”MY_SENSOR_ID”/>

AF
<location latitude=quot;LATquot; longitude=quot;LONquot; altitude=quot;ALTquot; heading=quot;HEADquot; speed=quot;SPDquot;/>
<data>
<channels>
<channel id=quot;MY_CHANNEL_IDquot; needstoken=”true|false”>
DR <value>THE_VALUE_READ_BY_THIS_CHANNEL</value>
</channel>
</channels>
</data>
</event>

Event XML: head
<event type=”sample|heartbeat” timestamp=”MY_TIMESTAMP” delay=”DELAY”>

The event has a type, that speciﬁes whether it
contains a data sample or it is the heartbeat to

T
inform the QuadraServer that the mote is alive and
connected

AF
sample events have source, location and data sections; heartbeat events
have only source and location sections, while data is forbidden
Event frequency for sample and heartbeat is part of mote conﬁguration
DR
The event has a timestamp, which should represent
the time when the data was collected by the sensor
(expressed in epoch).
If the mote is not able to determine absolute time, the delay attribute can be
used to specify the time gap between data sample and network connection
(the server will assign an eximated timestamp)

Event XML: source

T
The event has a source information, that consist of

AF
the moteID and the sensorID
Since moteID is unique in QuadraSpace and sensorID is unique in a mote,
this pair can’t be ambiguous and identiﬁes a single mote
DR
If the event type is heartbeat the sensorID
attributed is forbidden

Event XML: location

T
Nearly identical to mote’s element, location specifies
where the event happened (the fixed attribute is

AF
missing, because it is related to mote’s configuration
and not to realtime event)
DR
If available, location is expressed by:
latitude, longitude and altitude (float)
heading, that is the “direction the mote is pointing towards”
speed, if the mote is mounted on a vehicle

Event XML: data
<data>
<channels>
<channel id=quot;MY_CHANNEL_IDquot; needstoken=”true|false”>
<value>THE_VALUE_READ_BY_THIS_CHANNEL</value>
</channel>

T
</channels>
</data>

AF
The data element contains the value read by each
channel. It is present only it event type is sample,
otherwise it is forbidden
DR
If needed, the source mote can request a token used
to send channel’s value using a separate HTTP POST.
This is useful to notify an event that has binary data,
such as an image or an audio sample, without having
to include it as Base64 in the Event XML
Token management in QuadraSpace protocol will be speciﬁed later

Event notiﬁcation
A mote notiﬁes a new event posting the QuadraSpace
Event XML to the QuadraServer:

T
http://quadraspace.org/motes/MOTE_ID/events

AF
The ID of the mote which generated the event is
included also in the event itself: this way the Event
DR
XML can be forwarded using transports different
from HTTP, such as email, OBEX and others through
the QuadraGate
Basic authentication is used to associate the mote to
a user account (for HTTP connections)

SunSPOT events
<event timestamp=”1239674463” type=”heartbeat”>
<source moteID=”My_SunSPOT” /> The SunSPOT announces that it
is alive and connected; therefore
</event>
data section is missing

T
AF
The SunSPOT pushes the
<event timestamp=”1239874463” type=”sample”> data sample of the
TEMPSENSOR
<source moteID=”My_SunSPOT” sensorID=”TEMPSENSOR”/>
DR
<data>
<channels>
<channel id=quot;temp1quot;>
<value>22</value>
</channel>
</channels>
</data>
</event>

Android camera event The image capture by the embedded camera (the
sensor of this mote) is encoded in Base64 and
embedded in event notification
<event timestamp=”1239874463” type=”sample”>
<source moteID=”My_Android_Camera” sensorID=”CAMERA”/>
<data>
<channels>

T
<channel id=quot;camera1quot;>
<value>
/9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAPAAA/

AF
+4ADkFkb2JlAGTAAAAAAf/bAIQABgQEBAUEBgUFBgkGBQYJCwgGBggLDAoKCwo
KDBAMDAwMDAwQDA4PEA8ODBMTFBQTExwbGxscHx8fHx8fHx8fHwEHBwcND
A0YEBAYGhURFRofHx8fHx8fHx8fHx8fHx8fHx8fHx8
fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f/8AAEQgBQAFAAwERAAIRAQMRAf/
DR EAMEAAAEEAwEBAAAAAAAAAAAAAAABAwQFAgYHCAkBAQEBAQ
EBAQEAAAAAAAAAAAABAgMEBQYHEAACAQMCAwQFBgkGCgcFCQABAgMAE
QQSBSExBkFREwdhcSIyFIGRsdEjFaHBQlJicrIzCIKSosIkFtJDY4
Ojs8M0RGThU3OT01U28CU1RSbxVHSElGVGFxgRAQACAgEDAwIDBwQCAwAAAA
...
</value>
</channel>
</channels>
</data>
</event>

Arduino Ethernet event

IN
<event timestamp=”MY_TIMESTAMP” type=”sample”>

K S!

RS
<data>

T
OE
<channels>
<channel id=quot;MY_CHANNEL_IDquot;>

W GR
<value>THE_VALUE_READ_BY_THIS_CHANNEL</value>

AF
</channel>
</channels>
</data>

O
</event>

R
DR
P
GET /motes/moteID/events HTTP/1.0
X-QS-Timestamp: MY_TIMESTAMP
X-QS-MoteID: MY_MOTE_ID
X-QS-SensorID: MY_SENSOR_ID
X-QS-ChannelID: MY_CHANNEL_ID
X-QS-Value: THE_VALUE_READ
X-QS-Location: LAT,LON,ALT,HEADING,SPEED

End-points for events

T
Event described with Event XML instances are

AF
DR
http://SERVER/motes/ID/events
POST: notify a new event for the mote with ID moteID
GET: read all events for that mote

/motes/ID/events
Reads the list of events notifies by a mote
Notifies a new event for a mote

T
GET

AF
Returns all events registered for mote “ID”
Root element for the response is <events>
Optional parameters: starttime and endtime, used to filter events notified in a
DR
time interval

POST
Registers a new event for mote “ID”
Request body is an instance of Event XML

Both methods require HTTP Basic-Authentication

/motes/ID/events
Status Codes
GET

T
200 OK: the list of events is returned by the server

AF

POST
DR
201 Created: new event entry has been created in the QuadraServer

Triggers
Triggers are used to automatically execute
procedures (called actions) when one or more
conditions on incoming events are satisfied

T
AF
Conditions can be: “the event has been notified by a
specific sensor and its value is over an assigned
value” or “the event has been notified overnight”...
DR
Actions can be: sending an SMS or an email,
contacting a web site, invoking a Web Service
procedure, generating a new event...

Triggers are managed and executed by the
QuadraServer

Triggers

IN
A trigger can be executed as soon as the event

K S!
arrives (realtime trigger) or on a regular basis

RS

T
(scheduled trigger), for instance once per hour

OE
W GR
AF
[insert here details on scheduled triggers]

O
R
DR
P

Trigger structure

TRIGGER

T
ID TYPE

AF
CONDITIONS ACTIONS

CONDITION ACTION

MOTE EVENT
DR

Trigger XML
<trigger ID=”trigger_ID” type=”realtime|scheduled”>
<conditions>

T
<condition>
<mote>
THE_XPATH_EXPRESSION_OF_THE_CONDITION_IN_MOTEXML

AF
<mote>
<event>
THE_XPATH_EXPRESSION_OF_THE_CONDITION_IN_EVENTXML
<event>
DR
</condition>
</conditions>
<actions>
<action>
THE_EXPRESSION_OF_THE_ACTION
</action>
</actions>
</trigger>

Trigger XML
<trigger ID=”trigger_ID” type=”realtime|scheduled”>
<conditions>
</conditions>
<actions>

T
</actions>
</trigger>

AF
A QuadraSpace trigger has:
a unique ID (uniqueness is needed in the user account)
DR
a type, that can be realtime (the conditions are evaluated as soon as the
event is notified) or scheduled (the conditions are evaluated at a fixed rate on
all events notified since the last execution)
a set of conditions to be checked
a set of actions to execute when all conditions are satisfied

Trigger XML: condition
<condition>
<mote>
THE_XPATH_EXPRESSION_OF_THE_CONDITION_IN_MOTEXML
</mote>

T
<event>
THE_XPATH_EXPRESSION_OF_THE_CONDITION_IN_EVENTXML
</event>

AF
</condition>

A condition consist of two XPath expression applied
respectively to the trigger context, that consist of
DR
Mote XML of the event source (mote) and to the
Event XML (event)
The two expression are considered in boolean AND:
in order to trigger the actions they must return
simultaneously true

Trigger context
Before evaluating XPath expression, the trigger
context is being created by the QuadraServer that:

T
gets moteID and sensorID from the source element in Event XML

AF
gets a copy of the Mote XML description (using moteID) from the
QuadraSpace register
DR
removes all sensors from the Mote XML copy and keeps only the sensor child
that generated the event (i.e., with sensorID identiﬁer)

Once the context is ready, XPath expressions are
applied to mote and event sections

1 - Event is notified to
the QuadraServer EVENT

2 - A copy of Mote
XML is found using
moteID in event
source

T
TRIGGER CONTEXT:
EVENT+MOTE

X
AF
3 - Sensor description

X
in Mote XML is found
using sensorID in
DR
event source

4 - Sensor that
originated the event is
kept in Mote XML, other
sensors are deleted

MOTE

XPath on Mote XML
XPath expression on Mote XML is used to evaluate
conditions against the properties of the mote which

T
notiﬁed the event. For instance:
the ID

AF
the initial location
type of sensor
DR
XPath expression on Event XML is used to evaluate
conditions against the properties of the current
event. For instance:
timestamp
event data value (for each channel of the sensor)
event location

<mote id=quot;My_SunSPOTquot;>
<board><model>SunSPOT</model><vendor>Sun Microsystems</vendor></board>
<sensors>
<sensor id=quot;TEMPSENSORquot; context=quot;AMBIENTquot; type=quot;thermometerquot;>
<channels>
</channels>
</data>
</sensor>

T
</sensors>
<interfaces>
<interface id=quot;IDquot; type=quot;802.15.4quot; alwayson=quot;truequot; client=quot;truequot;>

AF
</interface>
</interfaces>
</mote>
MOTE
<mote>
DR
/mote//sensor[@type=’thermometer’]
<mote>
<event timestamp=”1239874463” type=”sample”>
<event>
<source moteID=”My_SunSPOT” sensorID=”TEMPSENSOR”/>
/event//channel(1)[value>12] <data>
<event> <channels>
TRIGGER CONDITION <channel id=quot;temp1quot;>
<value>22</value>
</channel>
</channels>
</data>
</event>

EVENT

XPath examples

T
Next slides will show some examples on how to use
XPath to express conditions for motes and events

AF
DR
Current speciﬁcation of QuadraSpace is based on:
XML Path Language (XPath) 2.0 (http://www.w3.org/TR/xpath20/)
XQuery 1.0 and XPath 2.0 Functions and Operators (http://www.w3.org/TR/
xpath-functions/)

XPath examples
Scenario: there is a set of motes installed on a
building. Each mote has some sensors. We want to
trigger an action if the event comes from a specific

T
mote and a specific sensor of it, and the value read
on second channel of this sensor is 57

AF
Criteria:
the event has been notified by the mote MY_MOTE_X
DR
the event data has been read by the sensor MY_SENSOR_Y
the value reported in channel 2 is 57
<mote>
/mote[@ID=’MY_MOTE_X’]//sensor[@ID=’MY_SENSOR_Y’]
<mote>
<event>
/event//channel[2][value=57]
<event>

XPath examples
Scenario: there are some temperature sensors
installed on rooms, devices and users. We want to
trigger an action when any of those attached to the

T
user reports a temperature over 38° Celsius

AF
Criteria:
the event has been notiﬁed by any mote
the event data has been read by a temperature sensor
DR
the sensor is attached to (i.e.: its context is) the user
the value reported by the event is over 38
<mote>
/mote//sensor[@type=’thermometer’ and @context=’user’]
<mote>
<event>
/event//[value>38]
<event>

XPath examples
Scenario: there is a mote with a temperature sensor
that sends regularly its data. We want to trigger an
action if the event value is over 30 and it happens

T
between the 23:00 and the the 5:00 of next day

AF
Criteria:
the event has been notiﬁed by any mote
the event happened in the time range 23:00-5:00
DR
the value reported in the event is over 30

<mote/>
<event>
time-less-than(/event[@timestamp], time(“5:00”))
&&
time-greater-than(/event[@timestamp], time(“23:00”))
&&
/event//[value>30]
<event>

Trigger XML: actions
<action forward=”true|false”>
ACTION_URI
</action>

T
An action has:

AF
a forward boolean attribute, that specifies whether the event has to be
an action URI element to be invoked when conditions are satisfied
DR
Current version of the protocol does not define
message dispatching to motes: therefore, actions are
simple messages or HTTP invocations to entities
external to the QuadraSpace service

Action URI schemas
Key $event refers the Event XML of current event

T
Currently allowed schemas are:

AF
sms://RECIPIENT?text=THE_TEXT
sends a SMS to RECIPIENT

mms://RECIPIENT
sends a MMS to RECIPIENT ?text=THE_TEXT&attach=$event
DR
mailto:RECIPIENT@HOST?subject=THE_SUBJECT&body=$event
sends an email to RECIPIENT

http://HOST/RESOURCE
performs an HTTP GET to that URL. If forward is true, an HTTP POST is performed and request
body is the Event XML

feed://HOST/FEED
pushes the event to the feed

SunSPOT Trigger
<trigger ID=”My_SunSPOT_Trigger” type=”realtime”>
<conditions>
<condition>
<mote>

T
/mote[@ID=’My_SunSPOT’]//sensor[@ID=’TEMPSENSOR’]
<mote>
<event>

AF
/event//data[value>30]
<event>
</condition>
</conditions>
DR
<actions>
<action>
sms://+39123123123?text=’Message from your SunSPOT!’
</action>
</actions>
</trigger>

End-points for triggers
Motes described with Triggers XML instances are

T

AF
http://SERVER/triggers
POST: register a new trigger
DR
GET: read list of triggers

http://SERVER/triggers/ID
PUT: update registration of an existing trigger
DELETE: unregister an existing trigger
GET: read info of an existing trigger

/triggers
Reads the list of triggers; adds a new trigger

T
GET

AF
Returns all trigger registered by the user
Root element for the response is <triggers>
No parameters
DR
POST
Registers a new trigger and return assigned ID in the <mote> root element
Expected response has body: <trigger id=”ID_ASSIGNED_BY_THE_SERVER”/>

Request body is an instance of Trigger XML


/triggers Status Codes
GET

T
200 OK: the list is returned by the server

AF

POST
DR
201 Created: new trigger entry has been created in the QuadraServer

/triggers/ID
Reads/writes the Trigger XML instance of “ID”
GET

T
Returns the trigger “ID”
No parameters

AF
Response body is an instance of Trigger XML

PUT
Updates the trigger “ID”
DR
No parameters
Request body is an instance of Trigger XML

DELETE
Deletes the trigger “ID”
No parameters, no response body


/triggers/ID Status Cds
GET
200 OK: required trigger is returned by the server

T

AF

PUT and DELETE
DR
200 OK: trigger entry has been updated/deleted in/from the
QuadraServer

QuadraSpace Roadmap
April 2009

T
first protocol draft published on the web site http://www.quadraspace.org

June 2009

AF
first release of QuadraServer and QuadraGate
first release of Java ME developer library (for Sun SPOT and mobile phones)
first release of Arduino library
DR
September 2009
first release of QuadraBox for Java SE
first release of iPhone OS and Android libraries

October 2009
first release of Sentilla and BUG libraries

Participate!
QuadraSpace has been conceived and designed by
Stefano Sanna and Roberto Fraboni and it is being
implemented and played by a small team of

T
enthusiasts who do believe that the “Internet of

AF
Things” is coming!

QuadraSpace is open! If you want to participate or
DR
just like to have more information about the project,
join us:

http://www.quadraspace.org
info@quadraspace.org
http://groups.google.com/quadraspace

Document history

DRAFT 1 (2009.04.20)

T
QuadraSpace protocol appears on the web!

DRAFT 2 (2009.04.26)

AF
Trigger have been included in the speciﬁcation

DRAFT 3 (2009.05.02)
DR
Minor errata ﬁxed, some details about QuadraBox added, Android camera
event added, new XPath example added

DRAFT 4 (2009.05.10)
Full endpoints description and status-code added
Event type has been introduced for “sample” and “hearbeat”

License
Copyright 2009 Stefano Sanna and Roberto Fraboni

T
Licensed under the Apache License, Version 2.0 (the quot;Licensequot;);
you may not use this ﬁle except in compliance with the License.

AF
You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0
DR
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an quot;AS
ISquot; BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the speciﬁc
language governing permissions and limitations under the
License.

Trademarks

T
AF
All technologies, products, company names, brand names,
trademarks and logos not related to the QuadraSpace project
are the property of their respective owners. They have been
used in this document for identiﬁcation and example
DR
purposes only.

QuadraSpace Protocol

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie QuadraSpace Protocol

Ähnlich wie QuadraSpace Protocol (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

QuadraSpace Protocol