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

2. This is...
IN
K S!
RS
T
OE
W GR
AF O
R
DR
P

3. Outline
T
It all began with a sensor...
AF
The QuadraSpace Project
QuadraSpace protocol and services
DR
Roadmap
Contacts

4. 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, traffic control

5. 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 field 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

6. 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!

7. 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

8. 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)

9. 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

10. 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 traffic 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
defines a set of REST Exceptions, that map missing
HTTP features on extended request headers

11. 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

12. 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...

13. 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

14. RSS
Quadra
Web XHT
ML
T
AF
QuadraSpace
QuadraServer
Other protocol
DR
Quadra Quadra
Gate Box
Bluetooth
SMS ZigBee USB
TCP

15. 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

16. 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-defined 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

17. QuadraWeb
It is the web front-end of the QuadraServer
T
It provides:
AF
web application for user registration, mote registration, event management,
triggers configuration
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

18. QuadraGate
It is the module responsible for accessing the
QuadraServer using public networks and protocols
T
other than HTTP REST
AF
It receives event notification 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)

19. 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

20. QuadraServer
T
Internet
AF
QuadraBox
DR
Bluetooth
USB

21. 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 configured to support custom protocols
Installation
QuadraGate (and QuadraServer) installation will be made available by the
QuadraSpace Project Team
Once extended and configured, QuadraBox is to be installed close to the
sensors and connected to the Internet using local router

22. 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 satisfies a
certain condition

23. 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 notification
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 satisfied, the QuadraServer can
perform actions, such as sending messages or activating remote devices

24. 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

25. 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 specification)

26. 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, float...), 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)

27. 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

28. 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>

29. 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

30. 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

31. Mote XML: sensor
<sensor id=quot;SENSOR_IDquot; context=quot;DEVICE|USER|AMBIENTquot; type=quot;SENSOR_TYPEquot;>
Each Sensor has a ID (unique within the mote)
T
Sensor’s context identifies 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 identifies the family of the sensor
Valid types are termometer, accelerometer, GPS...

32. Mote XML: sensor
<sensor id=quot;SENSOR_IDquot; context=quot;DEVICE|USER|AMBIENTquot; type=quot;SENSOR_TYPEquot;>
<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 specified 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)

33. 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

34. 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 identifies the class of communication module (e.g.: Bluetooth
RFCOMM, IrDA OBEX, ZigBee serial, GSM, SMS, email, TCP, UDP...)
a boolean attribute that specifies 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)

35. 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 specifies 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 notification
message

36. 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

37. 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

38. 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).

39. 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
<data quantity=quot;TEMPERATUREquot;>
<channels>
AF
<channel id=quot;temp1quot; type=quot;floatquot; unit=quot;celsiusDegreequot;
min=quot;2quot; max=quot;150quot; resolution=quot;1quot; />
</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>

40. 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;
min=quot;0quot; max=quot;100quot; resolution=quot;1quot; />
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>

41. 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

42. /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

43. /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
401 Unauthorized: user credential are not valid
500 Internal Server Error
503 Service Unavailable

44. /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

45. /motes/ID Status Codes
GET
T
200 OK: required mote is returned by the server
401 Unauthorized: user credential are not valid
AF
500 Internal Server Error
503 Service Unavailable
PUT and DELETE
DR
200 OK: mote entry has been updated/deleted in/from the QuadraServer
400 Bad Request: the XML submitted is not correct
401 Unauthorized: user credential are not valid
500 Internal Server Error
503 Service Unavailable

46. 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

47. 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

48. 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>

49. Event XML: head
<event type=”sample|heartbeat” timestamp=”MY_TIMESTAMP” delay=”DELAY”>
The event has a type, that specifies 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 configuration
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)

50. Event XML: source
<source moteID=”MY_MOTE_ID” sensorID=”MY_SENSOR_ID”/>
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 identifies a single mote
DR
If the event type is heartbeat the sensorID
attributed is forbidden

51. Event XML: location
<location latitude=quot;LATquot; longitude=quot;LONquot; altitude=quot;ALTquot; heading=quot;HEADquot; speed=quot;SPDquot;/>
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

52. 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 specified later

53. Event notification
A mote notifies 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)

54. 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>

55. 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>

56. Arduino Ethernet event
IN
<event timestamp=”MY_TIMESTAMP” type=”sample”>
<source moteID=”MY_MOTE_ID” sensorID=”MY_SENSOR_ID”/>
K S!
<location latitude=quot;LATquot; longitude=quot;LONquot; altitude=quot;ALTquot; heading=quot;HEADquot; speed=quot;SPDquot;/>
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

57. End-points for events
T
Event described with Event XML instances are
managed with RESTful HTTP/HTTPS end-points
AF
All calls have to include Basic Authentication
DR
http://SERVER/motes/ID/events
POST: notify a new event for the mote with ID moteID
GET: read all events for that mote

58. /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

59. /motes/ID/events
Status Codes
GET
T
200 OK: the list of events 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 event entry has been created in the QuadraServer
400 Bad Request: the XML submitted is not correct
401 Unauthorized: user credential are not valid
500 Internal Server Error
503 Service Unavailable

60. 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

61. 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

62. Trigger structure
TRIGGER
T
ID TYPE
AF
CONDITIONS ACTIONS
CONDITION ACTION
MOTE EVENT
DR

63. 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>

64. 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

65. 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

66. 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 identifier)
Once the context is ready, XPath expressions are
applied to mote and event sections

67. 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

68. XPath on Mote XML
XPath expression on Mote XML is used to evaluate
conditions against the properties of the mote which
T
notified 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

69. <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;>
<data quantity=quot;TEMPERATUREquot;>
<channels>
<channel id=quot;temp1quot; type=quot;floatquot; unit=quot;celsiusDegreequot;
min=quot;2quot; max=quot;150quot; resolution=quot;1quot; />
</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

70. XPath examples
T
Next slides will show some examples on how to use
XPath to express conditions for motes and events
AF
DR
Current specification 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/)

71. 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>

72. 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 notified 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>

73. 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 notified 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>

74. 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

75. 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

76. 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>

77. End-points for triggers
Motes described with Triggers XML instances are
managed with RESTful HTTP/HTTPS end-points
T
All calls have to include Basic Authentication
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

78. /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
All methods require HTTP Basic-Authentication

79. /triggers 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 trigger entry has been created in the QuadraServer
400 Bad Request: the XML submitted is not correct
401 Unauthorized: user credential are not valid
500 Internal Server Error
503 Service Unavailable

80. /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
All methods require HTTP Basic-Authentication

81. /triggers/ID Status Cds
GET
200 OK: required trigger is returned by the server
T
401 Unauthorized: user credential are not valid
500 Internal Server Error
AF
503 Service Unavailable
PUT and DELETE
DR
200 OK: trigger entry has been updated/deleted in/from the
QuadraServer
400 Bad Request: the XML submitted is not correct
401 Unauthorized: user credential are not valid
500 Internal Server Error
503 Service Unavailable

82. 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

83. 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

84. 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 specification
DRAFT 3 (2009.05.02)
DR
Minor errata fixed, 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”

85. 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 file 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 specific
language governing permissions and limitations under the
License.

86. 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 identification and example
DR
purposes only.