• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
QuadraSpace Protocol
 

QuadraSpace Protocol

on

  • 4,753 views

Draft of QuadraSpace protocol specification

Draft of QuadraSpace protocol specification

Statistics

Views

Total Views
4,753
Views on SlideShare
3,504
Embed Views
1,249

Actions

Likes
2
Downloads
45
Comments
0

7 Embeds 1,249

http://www.quadraspace.org 1115
http://www.gerdavax.it 116
http://translate.googleusercontent.com 11
http://www.365dailyjournal.com 3
http://www.slideshare.net 2
http://www.google.com 1
http://www.docshut.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    QuadraSpace Protocol QuadraSpace Protocol Presentation Transcript

    • 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, traffic 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 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
    • 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 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
    • 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-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
    • 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
    • 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)
    • 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 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
    • 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
    • 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
    • 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 specification)
    • 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)
    • 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 <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...
    • 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)
    • 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 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)
    • 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
    • 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 <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>
    • 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>
    • 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 401 Unauthorized: user credential are not valid 500 Internal Server Error 503 Service Unavailable
    • /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 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
    • 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 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)
    • 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
    • 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
    • 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
    • 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)
    • 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”> <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
    • 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
    • /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 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
    • 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 identifier) 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 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
    • <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
    • 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/)
    • 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 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>
    • 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>
    • 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 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
    • /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
    • /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
    • /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
    • /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
    • 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 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”
    • 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.
    • 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.