TOC 
WSN OpenAPIJ. Suhonen, Ed.
 O. Kivela
 Department of Computer Systems,
 Tampere University of Technology
 September 14, 2012


Sensor Information Data Format (SIDF)

Abstract

The description of the interface used to send measurement data from WSN regardless of the WSN technology.



Table of Contents

1.  Document information
2.  Introduction
    2.1.  Terminology
3.  Content
    3.1.  Addressing
    3.2.  Data structures
    3.3.  Messages
    3.4.  XML
        3.4.1.  Measurements
        3.4.2.  Request
        3.4.3.  Response
    3.5.  CSV
        3.5.1.  Measurements
        3.5.2.  Request
        3.5.3.  Response
        3.5.4.  Request-response ABNF
4.  Informative References
§  Authors' Addresses




 TOC 

1.  Document information

Document version: 1.6

XML namespace: urn:wsn-openapi:sadf



 TOC 

2.  Introduction

The interface described in this document is to be used for sending measurement data of a Wireless Sensor Network OpenAPI Introduction (DACI Research Group, Department of Computer Systems, Tampere University of Technology, “OpenAPI Introduction,” 2010.) [OPEN API INTRO], regardless of the WSN implementation technology.

Goal is to keep messages as simple as possible to reduce network traffic nevertheless as informative as possible.

OGC has XML format OGC O&M (Open Geospatial Consortium Inc., “Observations and Measurements - Part 1 - Observation schema,” 2007.) [OGC O&M] of transmitting measurement data. This format encompasses all the required elements, although it is too verbose for the proposed use-case. The interface described in this document intends to be the format of the first step in the messaging from network gateway to first client that is interested in measurement data. From this client the measurement data could be enriched with meta data described by MEDF (DACI Research Group, Department of Computer Systems, Tampere University of Technology, “Node Datasheet,” 2010.) [MEDF] if desired. Enriched data could then be transmitted forward as e.g. OGC O&M (Open Geospatial Consortium Inc., “Observations and Measurements - Part 1 - Observation schema,” 2007.) [OGC O&M] or OGC TML (Open Geospatial Consortium Inc., “OpenGIS Transducer Markup Language (TML) Implementation Specification,” 2007.) [OGC TML].

This document covers contents of messages. Current version of SIDF is 1.4.



 TOC 

2.1.  Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].



 TOC 

3.  Content



 TOC 

3.1.  Addressing

The components of a WSN can be generally seen as sensors, nodes and networks. The network consists of wirelessly communicating nodes that observe their environment using sensors. Usually only this three level addressing is all that is needed: network.node.sensor. Each id in each level must be unique to make unambiguous addressing possible.

Constructing the addressing is application domain specific and should be decided what to use as network, node, and sensor IDs. E.g. for mobilephone's operator name could be used as network id and mobilephone's serial number could be used as node id. For software components acting as sensors e.g. program name could be used as sensor id or it could be surrogate id, device name or serial number or IP address could be node id, and network name could be network id.



 TOC 

3.2.  Data structures

Two structures for messages sent from WSN are defined here. The first is a verbose XML representation of messages and the second a more compact structure in CSV, defined here in ABNF. Events can also be transmitted with both formats.

When transmitting large amounts of data the usage of the XML format causes a large amount of overhead in the form of XML tags and elements. To avoid this the usage of the CSV (CSV) format is recommended.



 TOC 

3.3.  Messages

SIDF contains three message types. These are measurement message, request message and response message. Measurement data and events are transported with SIDF measurement messages. Creating and canceling of subscription for SIDF measurement messages is done with Request and Response messages.

Creation of SIDF subscription is presented in Figure 1. A client sends a SIDF Request message, receives a SIDF Response message as a response and starts to receive SIDF measurement messages.



 Client                                    Gateway
+-------+                                 +-------+
|       |                                 |       |
+-------+                                 +-------+
    |                                         |
    |  SIDF:Request                           |
    |---------------------------------------->|
    |                                         |
    |                                         |
    |  SIDF:Response                          |
    |<----------------------------------------|
    |                                         |
    |                                         |
    |                                         |
    |  SIDF                                   |
    |<----------------------------------------|
    |                                         |
    .                                         .
    .                                         .
    .                                         .
    .                                         .
    .                                         .

 Figure 1 

Canceling of SIDF subscription is presented in Figure 2. A client sends an empty SIDF Request message, receives a SIDF Response message. The client stops receiving SIDF measurement messages.



 Client                                    Gateway
+-------+                                 +-------+
|       |                                 |       |
+-------+                                 +-------+
    |                                         |
    .                                         .
    .                                         .
    |  SIDF                                   |
    |<----------------------------------------|
    |                                         |
    |                                         |
    |  SIDF:Request (empty)                   |
    |---------------------------------------->|
    |                                         |
    |                                         |
    |  SIDF:Response                          |
    |<----------------------------------------|
    |                                         |
    |                                         |

 Figure 2 

For sending in SIDF measurements no subscription is needed. If a client is authenticated to the gateway it can send in SIDF measurement messages. Sending of SIDF measurement message is presented in Figure 3.



 Client                                    Gateway
+-------+                                 +-------+
|       |                                 |       |
+-------+                                 +-------+
    |                                         |
    |  SIDF                                   |
    |---------------------------------------->|
    |                                         |
    .                                         .
    .                                         .

 Figure 3 



 TOC 

3.4.  XML

The goal of XML representation is to be structural and easy to parse as much as possible. Therefore data types of attributes are set corresponding to semantic types of addressing of network components. Data types of id attributes of elements node, and sensor are string but using integer is strongly recommended. Attribute name of network element is optional human readable descriptive name for network. Attribute name of node element is optional human readable descriptive name for node. Recommended values for network id is UUID RFC4122 (Leach, P., Mealling, M., and R. Salz, “A Universally Unique IDentifier (UUID) URN Namespace,” July 2005.) [RFC4122] or some other globally registered value i.e. domain name.

Data types of attribute id and content of element component are xs:string to allow any type of data to be transmitted as measurement component depending measurement type and component name. This allows that theoretically any type of data can be transmitted as content of measurement component e.g. piece of another XML document or some other format can be placed in measurement components content using CDATA section. Binary data transported as component value is encoded with Base 64 algorithm. Default value for attribute id of element component is "value".

Both the Measurement and the Component elements have an unit attribute. The unit attribute of the Measurement element is common for all the measurement components. It is valid for all the components unless a component element itself has an unit attribute in which case the Component elements unit attribute overrides the corresponding of the measurement element.

Units are correspondingly set with tolerance and tolerance components. Both the Tolerance and the Component elements have an unit attribute. The unit attribute of the Tolerance element is common for all the tolerance components. It is valid for all the components unless a component element itself has an unit attribute in which case the Component elements unit attribute overrides the corresponding of the tolerance element.



 TOC 

3.4.1.  Measurements



Example of an measurement message in XML:

<SIDF version="1.3" xmlns="urn:wsn-openapi:sidf">
	<Network id="1">
		<Node id="2">
			<Sensor id="3" >
				<Measurement quantity="Temperature" unit="C"
	                           time="2009-07-03T11:24:46+00:00" >
	                           <Component id="value">23.0</Component>
				</Measurement>
			</Sensor>
		</Node>
	</Network>
</SIDF>

Single temperature measurement.

 Figure 4 



Schema of SIDF messages:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
	elementFormDefault="qualified" attributeFormDefault="unqualified"

	targetNamespace="urn:wsn-openapi:sidf" xmlns="urn:wsn-openapi:sidf">

	<!-- Types -->
	<xs:complexType name="EventComponentType">
		<xs:simpleContent>
			<xs:extension base="xs:string">
				<xs:attribute name="id" type="xs:string" use="required" />
			</xs:extension>
		</xs:simpleContent>
	</xs:complexType>

	<xs:complexType name="EventType">
		<xs:sequence>
			<xs:element name="Component" type="EventComponentType"
				minOccurs="0" maxOccurs="unbounded" />
		</xs:sequence>
		<xs:attribute name="type" type="xs:string" use="optional" default="alert" />
		<xs:attribute name="time" type="xs:dateTime" use="optional" />
		<xs:attribute name="id" type="xs:string" use="required" />

	</xs:complexType>

	<xs:complexType name="ToleranceComponentType">
		<xs:simpleContent>
			<xs:extension base="xs:string">
				<xs:attribute name="id" type="xs:string" use="required" />
				<xs:attribute name="unit" type="xs:string" use="optional" >
				<xs:annotation><xs:documentation>If not set the unit attribute of the parent
				 tolerance is considered as unit of this component.</xs:documentation></xs:annotation>
				</xs:attribute>
			</xs:extension>
		</xs:simpleContent>
	</xs:complexType>

	<xs:complexType name="ToleranceType">
		<xs:sequence>
			<xs:element name="Component" type="ToleranceComponentType"
				minOccurs="0" maxOccurs="unbounded" />
		</xs:sequence>
		<xs:attribute name="for" type="xs:string" use="required" />
		<xs:attribute name="type" type="xs:string" use="required" />
		<xs:attribute name="unit" type="xs:string" use="optional" />

	</xs:complexType>

	<xs:complexType name="ComponentType">
		<xs:simpleContent>
			<xs:extension base="xs:string">
				<xs:attribute name="id" type="xs:string" use="optional"
					default="value" />
				<xs:attribute name="unit" type="xs:string" use="optional" >
				<xs:annotation><xs:documentation>If not set the unit attribute of the parent
				measurement is considered as unit of this component.</xs:documentation></xs:annotation>
				</xs:attribute>
        		<xs:attribute name="ref" type="xs:anyURI" use="optional" >
				<xs:annotation><xs:documentation>If set the ref points to the actual data.
				If omitted the component data is inline as the element value.
				</xs:documentation></xs:annotation>
        		</xs:attribute>
			</xs:extension>
		</xs:simpleContent>
	</xs:complexType>

	<xs:complexType name="MeasurementType">
		<xs:sequence>
			<xs:choice minOccurs="1" maxOccurs="unbounded">
				<xs:element name="Component" type="ComponentType" />
				<xs:element name="Event" type="EventType" />
			</xs:choice>
			<xs:element name="Tolerance" type="ToleranceType" minOccurs="0"
				maxOccurs="unbounded" />
		</xs:sequence>
		<xs:attribute name="quantity" type="xs:string" use="optional" />
		<xs:attribute name="unit" type="xs:string" use="optional" >
			<xs:annotation><xs:documentation>Common for all components unless a component
			has set the unit attribute itself.</xs:documentation></xs:annotation>
		</xs:attribute>
		<xs:attribute name="time" type="xs:dateTime" use="required" />
	</xs:complexType>

	<xs:complexType name="SensorType">
		<xs:choice minOccurs="1" maxOccurs="unbounded">
			<xs:element name="Event" type="EventType"  />
			<xs:element name="Measurement" type="MeasurementType" />
		</xs:choice>
		<xs:attribute name="id" type="xs:string" use="required" />
	</xs:complexType>

	<xs:complexType name="NodeType">
		<xs:choice minOccurs="1" maxOccurs="unbounded">
			<xs:element name="Event" type="EventType"  />
			<xs:element name="Sensor" type="SensorType"  />
		</xs:choice>
		<xs:attribute name="id" type="xs:string" use="required" />
		<xs:attribute name="name" type="xs:string" use="optional" />
	</xs:complexType>

	<xs:complexType name="NetworkType">
		<xs:choice>
			<xs:sequence>
					<xs:element name="Event" type="EventType" minOccurs="1"
						maxOccurs="unbounded" />
					<xs:element name="Node" type="NodeType" minOccurs="0"
						maxOccurs="1" />
			</xs:sequence>
			<xs:sequence>
					<xs:element name="Node" type="NodeType" minOccurs="1"
						maxOccurs="1" />
					<xs:element name="Event" type="EventType" minOccurs="0"
						maxOccurs="unbounded" />
			</xs:sequence>
		</xs:choice>
		<xs:attribute name="id" type="xs:string" use="required" />
		<xs:attribute name="name" type="xs:string" use="optional" />
	</xs:complexType>

	<xs:complexType name="SIDFType">
		<xs:sequence>
			<xs:element name="Network" type="NetworkType" minOccurs="1"
				maxOccurs="1" />
		</xs:sequence>
		<xs:attribute name="version" type="xs:double" use="required" />
		<xs:attribute name="messageId" type="xs:string" use="optional" />
		<xs:attribute name="responseRequired" type="xs:boolean" use="optional" default="false">
			<xs:annotation>
				<xs:documentation>If response is needed to ensure that the measurement has been
				                  correctly sent and received.
				</xs:documentation>
			</xs:annotation>
		</xs:attribute>
	</xs:complexType>

	<!-- Elements -->
	<xs:element name="SIDF" type="SIDFType" />
</xs:schema>

 Figure 5 



Example of an measurement message in XML:

<SIDF version="1.3" xmlns="urn:wsn-openapi:sidf">
	<Network id="1">
		<Node id="2">
		      <Sensor id="3" >
	                 <Measurement quantity="Acceleration" unit="mg"
	                            time="2009-07-25T14:24:46+00:00" >
	                            <Component id="x">142.0</Component>
	                            <Component id="y">46.0</Component>
	                            <Component id="z">895.0</Component>
	                            <Component id="roll" unit="degree">8.0</Component>
	                            <Component id="pitch" unit="degree">2.0</Component>
	                            <Component id="total">907.36156</Component>
	                 </Measurement>
		      </Sensor>
		</Node>
	</Network>
</SIDF>


Single acceleration measurement.

 Figure 6 



Example of an measurement message in XML:

<SIDF version="1.3" xmlns="urn:wsn-openapi:sidf">
	<Network id="operator">
		<Node id="phoneSerial">
		      <Sensor id="acc" >
		                 <Measurement quantity="Acceleration" unit="mg"
		                            time="2009-07-25T14:24:46+00:00" >
		                            <Component id="x">142.0</Component>
		                            <Component id="y">46.0</Component>
		                            <Component id="z">895.0</Component>
		                            <Component id="roll" unit="degree">8.0</Component>
		                            <Component id="pitch" unit="degree">2.0</Component>
		                            <Component id="total">907.36156</Component>
		                 </Measurement>
		                 <Measurement quantity="Acceleration" unit="mg"
		                            time="2009-07-25T14:24:47+00:00" >
		                            <Component id="x">142.0</Component>
		                            <Component id="y">46.0</Component>
		                            <Component id="z">895.0</Component>
		                            <Component id="roll" unit="degree">8.0</Component>
		                            <Component id="pitch" unit="degree">2.0</Component>
		                            <Component id="total">907.36156</Component>
		                 </Measurement>
		      </Sensor>
		</Node>
	</Network>
</SIDF>


Two acceleration measurements sent by mobilephone. Operator id is used as network id and mobilephone's serial number is used as node id.

 Figure 7 



Example of an measurement message in XML:

<SIDF version="1.3" xmlns="urn:wsn-openapi:sidf">
	<Network id="homenetwork">
		<Node id="192.168.0.2">
		      <Sensor id="acc" >
		                 <Measurement quantity="Acceleration" unit="mg"
		                            time="2009-07-25T14:24:46+00:00" >
		                            <Component id="x">142.0</Component>
		                            <Component id="y">46.0</Component>
		                            <Component id="z">895.0</Component>
		                            <Component id="roll" unit="degree">8.0</Component>
		                            <Component id="pitch" unit="degree">2.0</Component>
		                            <Component id="total">907.36156</Component>
		                 </Measurement>
		                 <Measurement quantity="Acceleration" unit="mg"
		                            time="2009-07-25T14:24:47+00:00" >
		                            <Component id="x">142.0</Component>
		                            <Component id="y">46.0</Component>
		                            <Component id="z">895.0</Component>
		                            <Component id="roll" unit="degree">8.0</Component>
		                            <Component id="pitch" unit="degree">2.0</Component>
		                            <Component id="total">907.36156</Component>
		                 </Measurement>
		      </Sensor>
		</Node>
	</Network>
</SIDF>


Two acceleration measurements sent by computer program. Network name is used as network id and computer's IP address is used as node id.

 Figure 8 



Example of an measurement message in XML:

<SIDF version="1.3" xmlns="urn:wsn-openapi:sidf">
	<Network id="1">
		<Node id="2">
		      <Sensor id="3" >
		                 <Measurement quantity="Temperature" unit="C"
		                            time="2009-07-25T14:24:46+00:00" >
		                            <Component>23.0</Component>
		                 </Measurement>

		      </Sensor>
		      <Sensor id="5" >
		                 <Measurement quantity="Temperature" unit="C"
		                            time="2009-07-25T14:24:46+00:00" >
		                            <Component>25.0</Component>
		                 </Measurement>

		      </Sensor>
		</Node>
	</Network>
</SIDF>

Two temperature measurements by two sensors of one node.

 Figure 9 



Example of an measurement message in XML:

<SIDF version="1.3" xmlns="urn:wsn-openapi:sidf">
	<Network id="1">
		<Node id="2">
		      <Sensor id="3" >
		                 <Measurement quantity="Location" unit="WGS84"
		                            time="2009-07-25T14:24:46+00:00" >
									<Component id="latitude">52.686</Component>
									<Component id="longitude">2.193</Component>
									<Component id="altitude" unit="m">100</Component>

		                 </Measurement>
		      </Sensor>
		</Node>
	</Network>
</SIDF>


Single location measurement.

 Figure 10 



Example of an measurement message in XML:

<SIDF version="1.3" xmlns="urn:wsn-openapi:sidf">
	<Network id="1">
		<Node id="2">
			<Sensor id="3" >
				<Measurement quantity="Location"
					time="2009-07-25T14:24:46+00:00" unit="GML">
					<Component id="value">
						<![CDATA[
						<gp:geopriv xmlns:gp="urn:wsn-openapi:pidf:geopriv10"
										xmlns:gml="http://www.opengis.net/gml">
							<gp:location-info>
								<gml:location>
									<gml:Point>
										<gml:pos>60.128445 24.420510</gml:pos>
									</gml:Point>
								</gml:location>
							</gp:location-info>
						</gp:geopriv>
						]]>
					</Component>
				</Measurement>
			</Sensor>
		</Node>
	</Network>
</SIDF>


Single location measurement presented as in GEOPRIV (RFC4119 (Peterson, J., “A Presence-based GEOPRIV Location Object Format,” December 2005.) [RFC4119]).

 Figure 11 



Example of an measurement message in XML:

<SIDF version="1.3" xmlns="urn:wsn-openapi:sidf">
	<Network id="1">
		<Node id="2">
			<Sensor id="3" >
				<Measurement quantity="Location"
					time="2009-07-25T14:24:46+00:00" unit="geo-uri">
					<Component>geo:60.128445,24.420510</Component>
				</Measurement>
			</Sensor>
		</Node>
	</Network>
</SIDF>


Single location measurement. The geolocation is presented as in A Uniform Resource Identifier for Geographic Locations ('geo' URI) draft-mayrhofer-geopriv-geo-uri-01 (GEOPRIV -- Geographic. Location/Privacy Working Group. Mayrhofer A.. Spanring C.., “A Uniform Resource Identifier for Geographic Locations ('geo' URI) draft-mayrhofer-geopriv-geo-uri-01,” 2009.) [GEO]

 Figure 12 

Using geo-uri for location instead of GML is recommended for its more compact form.



Example of an measurement message in XML:

<SIDF version="1.3" xmlns="urn:wsn-openapi:sidf">
	<Network id="1">
		<Node id="2">
		      <Sensor id="3" >
		                 <Measurement quantity="Motion" unit="Boolean"
		                            time="2010-01-25T14:24:46+00:00" >
		                            <Component id="level1">true</Component>
		                 </Measurement>

		      </Sensor>
		      <Sensor id="4" >
		                 <Measurement quantity="Motion" unit="Boolean"
		                            time="2010-01-25T14:24:46+00:00" >
		                            <Component id="level2">true</Component>
		                 </Measurement>

		      </Sensor>
		</Node>
	</Network>
</SIDF>

Motion level measurements.

 Figure 13 



Example of an measurement message in XML:

<SIDF version="1.3" xmlns="urn:wsn-openapi:sidf">
	<Network id="1">
		<Node id="2">
		      <Sensor id="3" >
		                 <Measurement quantity="Temperature" unit="C"
		                            time="2009-07-25T14:24:46+00:00" >
		                            <Component>23.0</Component>
		                 </Measurement>

		      </Sensor>
		      <Sensor id="5" >
		                 <Measurement quantity="Temperature" unit="C"
		                            time="2009-07-25T14:24:46+00:00" >
		                            <Event id="out_of_bounds">
		                            	<Component id="message">Too hot</Component>
		                            </Event>
		                            <Component>25.0</Component>
		                 </Measurement>

		      </Sensor>
		</Node>
	</Network>
</SIDF>

Two temperature measurements by two sensors of one node. This example shows also how event information can be added to SIDF message. Event information can be added in one client software and then passed forward to other clients.

 Figure 14 



Example of an event message in XML:

<SIDF version="1.3" xmlns="urn:wsn-openapi:sidf">
        <Network id="1">
                <Event id="disconnected">
                        <Component id="message">Disconnected</Component>
                </Event>
        </Network>
</SIDF>

An event in the network element.

 Figure 15 



Example of an event message in XML:

<SIDF version="1.3" xmlns="urn:wsn-openapi:sidf">
        <Network id="1">
                <Node id="2">
                        <Event id="disconnected">
                                <Component id="message">Disconnected</Component>
                        </Event>
                </Node>
        </Network>
</SIDF>

An event in the node element.

 Figure 16 



Example of an event message in XML:

<SIDF version="1.3" xmlns="urn:wsn-openapi:sidf">
        <Network id="1">
                <Node id="2">
                        <Sensor id="3">
                                <Event id="too_hot">
                                        <Component id="message">Too hot!</Component>
                                </Event>
                        </Sensor>
                </Node>
        </Network>
</SIDF>

 Figure 17 



 TOC 

3.4.2.  Request

Client sends Request to begin receiving real-time measurements and events with SIDF messages. Request events and measurements from all networks configured at the gateway. Note that the server may have access limitations for clients, in which case client will not receive data from networks to which it has no access rights.



Example of an request message in XML:

<Request version="1.3" xmlns="urn:wsn-openapi:sidf"/>

Empty request to end subscription.

 Figure 18 



XML schema of the SIDF request message:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
 elementFormDefault="qualified"
 attributeFormDefault="unqualified"
 targetNamespace="urn:wsn-openapi:sidf"
 xmlns="urn:wsn-openapi:sidf"
 >
	<!-- Types -->
	<xs:complexType name="NodeType">
		<xs:attribute name="id" type="xs:string" use="required" />
	</xs:complexType>

	<xs:complexType name="MeasurementType">
		<xs:sequence>
			<xs:element name="Node"
			 type="NodeType"
			 minOccurs="0"
			 maxOccurs="unbounded" />
		</xs:sequence>
		<xs:attribute name="quantity" type="xs:string" use="required" />
		<xs:attribute name="interval" type="xs:integer" use="optional" default="0" >
			<xs:annotation><xs:documentation>Interval is the minimum time period from the last
			measurement in milliseconds. If 0 the measurements are conveyed as soon as they arrive.
			</xs:documentation></xs:annotation>
		</xs:attribute>
	</xs:complexType>

	<xs:complexType name="NetworkType">
		<xs:sequence>
			 <xs:element name="Measurement"
			 type="MeasurementType"
			 minOccurs="0"
			 maxOccurs="unbounded" />
			 <xs:element name="Node"
			 type="NodeType"
			 minOccurs="0"
			 maxOccurs="unbounded" />
		</xs:sequence>
		<xs:attribute name="id" type="xs:string" use="optional" >
			<xs:annotation>
	  			<xs:documentation>
	  				If attribute id is not given it is considered as all networks.
	  			</xs:documentation>
	  		</xs:annotation>
		</xs:attribute>
		<xs:attribute name="interval" type="xs:integer" use="optional" default="0" >
			<xs:annotation><xs:documentation>Interval is the time period after which
			the latest measurement must be send. If 0 the measurements are conveyed as soon
			 as they arrive.</xs:documentation></xs:annotation>
		</xs:attribute>
	</xs:complexType>

	<xs:simpleType name="ResponseFormatType">
		<xs:restriction base="xs:string">
			<xs:enumeration value="XML"/>
			<xs:enumeration value="CSV"/>
		</xs:restriction>
	</xs:simpleType>

	<xs:complexType name="SIDFRequestType">
		<xs:sequence>
			<xs:element name="Network"
			 type="NetworkType"
			 minOccurs="0"
			 maxOccurs="unbounded" />
		</xs:sequence>
		<xs:attribute name="version" type="xs:double" use="required" />
		<xs:attribute name="messageFormat" type="ResponseFormatType" use="optional" default="XML" />
		<xs:attribute name="eventsOnly" type="xs:boolean" use="optional" default="false" />
		<xs:attribute name="messageId" type="xs:string" use="optional" />
		<xs:attribute name="inlineThreshold" type="xs:integer" use="optional" default="0" >
			<xs:annotation><xs:documentation>If the size of the measurement component is less than
			or equal inlineThreshold the component is returned as inline.
			If inlineThreshold is 0 or is not given results are always inline.
			Otherwise results are returned as URIs.</xs:documentation></xs:annotation>
		</xs:attribute>
	</xs:complexType>


	 <!-- Elements -->
	<xs:element name="Request" type="SIDFRequestType" />

</xs:schema>

 Figure 19 



Example of an request message in XML:

<Request version="1.3" xmlns="urn:wsn-openapi:sidf" messageId="1">
     <Network id="1"/>
</Request>

Request is limited to certain network.

 Figure 20 



Example of an request message in XML:

<Request version="1.3" xmlns="urn:wsn-openapi:sidf" messageId="1">
      <Network id="1">
           <Measurement quantity="Temperature"/>
      </Network>
</Request>

Request is limited to specific types of sensors.

 Figure 21 



Example of an request message in XML:

<Request version="1.3" eventsOnly="true" xmlns="urn:wsn-openapi:sidf" messageId="1"/>

Requesting events only.

 Figure 22 



 TOC 

3.4.3.  Response



Example of an response message in XML:

<Response version="1.3" responseCode="200" messageId="1"/>

 Figure 23 



XML schema of the SIDF response message:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
 elementFormDefault="qualified"
 attributeFormDefault="unqualified"
 targetNamespace="urn:wsn-openapi:sidf"
 xmlns="urn:wsn-openapi:sidf"
  >
	<!-- Types -->

	<xs:simpleType name="ResponseCodeType">
		<xs:restriction base="xs:integer">
			<xs:enumeration value="200"/>
			<xs:enumeration value="400"/>
			<xs:enumeration value="403"/>
		</xs:restriction>
	</xs:simpleType>

	<xs:complexType name="SIDFResponseType">
		<xs:sequence>
		</xs:sequence>
		<xs:attribute name="version" type="xs:double" use="required" />
		<xs:attribute name="responseCode" type="ResponseCodeType" use="required" />
		<xs:attribute name="messageId" type="xs:string" use="optional" />
	</xs:complexType>

	<!-- Elements -->
	<xs:element name="Response" type="SIDFResponseType" />

</xs:schema>

 Figure 24 



CodeMeaningDescription
200 OK Request accepted
400 Bad request The request had bad syntax or was inherently impossible to be satisfied
403 Forbidden The request is for something forbidden

 Table 1: Return values 



 TOC 

3.5.  CSV



 TOC 

3.5.1.  Measurements

The goal of the CSV representation is to be as compact as possible though containing all the same information as the XML representation. The CSV format contains no information about measurement type of the sensor or the names of the components because that information can be resolved using the meta-data available through MEDF (DACI Research Group, Department of Computer Systems, Tampere University of Technology, “Node Datasheet,” 2010.) [MEDF].



An example message:

SIDF;1.3;1
"1";;"2";;"3";;2009-07-03T11:24:46+00:00;;;23.0;;

Single temperature measurement.

 Figure 25 



The Augmented Backus-Naur Form (ABNF) RFC 5234 (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.) [RFC5234] definition:

MEASUREMENT-MESSAGE = "SIDF" ";" VERSION ";" LINES END-OF-LINE 1*(LF MEASUREMENT) LF
VERSION = Double
LINES = PositiveInteger
MEASUREMENT = NETWORK-ID ";" EVENTS ";" NODE-ID ";" EVENTS ";" [SENSOR-ID] ";" EVENTS ";" [DATE-FORMAT] ";" EVENTS ";" [COMPONENTS] ";" [TOLERANCES] ";" [REFS] END-OF-LINE
EVENTS = [EVENT *("," EVENT)]
EVENT = EVENT-ID "|" DATE-FORMAT "|" KEY-VALUE-PAIR *("|" KEY-VALUE-PAIR)
KEY-VALUE-PAIR = String "=" String
REFS = URI *("," URI)
COMPONENTS = COMPONENT *("," COMPONENT)
COMPONENT = Integer / Double / Boolean / String / URI
TOLERANCES = TOLERANCE *("," TOLERANCE)
TOLERANCE = TOLERANCE-FOR "|" TOLERANCE-TYPE "|" KEY-VALUE-PAIR *("|" KEY-VALUE-PAIR)

DATE-FORMAT = RELATIVE-TIME / ABSOLUTE-TIME
RELATIVE-TIME = ("+" / "-") 1*DIGIT ["." 1*DIGIT]
ABSOLUTE-TIME = DATE "T" TIME TIME-ZONE
DATE = ["-"] 4DIGIT "-" %x30-31 DIGIT "-" %x30-33 DIGIT
TIME = %x30-32 DIGIT ":" %x30-35 DIGIT ":" %x30-35 DIGIT ["." *DIGIT]
TIME-ZONE = ( ("+" / "-") 2DIGIT ":" 2DIGIT ) / "Z"

EVENT-ID  = String
SENSOR-ID  = String
NODE-ID  = String
NETWORK-ID  = String
Integer = ("+" / "-" / "") 1*DIGIT
PositiveInteger = 1*DIGIT
Boolean = BIT
Double = ("+" / "-" / "") 1*DIGIT ["." 1*DIGIT]
String = DQUOTE *VCHAR DQUOTE
END-OF-LINE = *(";")


URI = *VCHAR

Time zone (Z) is represented in 4-digit format as defined in RFC 822 (Crocker, D., “Standard for the format of ARPA Internet text messages,” August 1982.) [RFC0822]

 Figure 26 

The geolocation is presented as in A Uniform Resource Identifier for Geographic Locations ('geo' URI) draft-mayrhofer-geopriv-geo-uri-01 (GEOPRIV -- Geographic. Location/Privacy Working Group. Mayrhofer A.. Spanring C.., “A Uniform Resource Identifier for Geographic Locations ('geo' URI) draft-mayrhofer-geopriv-geo-uri-01,” 2009.) [GEO]



An example message:

SIDF;1.3;1
"1";;"2";;"3";;2009-07-03T11:24:46+00:00;;;"name"="Temperature Alert"|"message"="Too hot";25.0;;

Single temperature measurement with alert information.

 Figure 27 



An example message:

SIDF;1.3;1
"1";;"2";;"3";;2009-07-03T11:24:46+00:00;;;142.0,46.0,895.0,8.0,2.0,,907.36156;;

Single acceleration (x, y, z, pitch, roll, yaw, total) measurement.

 Figure 28 



An example message:

SIDF;1.3;2
"1";;"2";;"3";;2009-07-03T11:24:46+00:00;;;23.0;;
"1";;"2";;"4";;2009-07-03T11:24:46+00:00;;;24.0;;

Two temperature measurements by two sensors of one node.

 Figure 29 



An example message:

SIDF;1.3;1
"1";;"2";;"3";;2009-07-03T11:24:46+00:00;;;geo:60.128445,24.420510;;

Single location measurement.

 Figure 30 



 TOC 

3.5.2.  Request

CSV form of request.



An example message:

SIDF:REQUEST;1.3;CSV;1;;;1
"1";"Temperature";"2";

 Figure 31 



 TOC 

3.5.3.  Response

CSV form of response.



An example message:

SIDF:RESPONSE;1.3;200;1

 Figure 32 



 TOC 

3.5.4.  Request-response ABNF



The Augmented Backus-Naur Form (ABNF) RFC 5234 (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.) [RFC5234] definition:

SIDF-MESSAGE = SIDF-REQUEST / SIDF-RESPONSE

SIDF-REQUEST = "SIDF:REQUEST" ";" VERSION ";" RESPONSE-FORMAT ";" MESSAGE-ID ";" [EVENTS-ONLY] ";" [INLINE-THRESHOLD] ";" LINES END-OF-LINE *(LF REQUEST-LINE) LF
SIDF-RESPONSE = "SIDF:RESPONSE" ";" VERSION ";" RESPONSE-CODE ";" MESSAGE-ID END-OF-LINE LF

VERSION = Double
RESPONSE-FORMAT = "XML" / "CSV"
EVENTS-ONLY = Boolean
LINES = Integer
INLINE-THRESHOLD = Integer
MESSAGE-ID = String
RESPONSE-CODE = "200" / "400" / "403"

REQUEST-LINE = NETWORK-ID ";" [QUANTITY] ";" [NODE-ID] ";" [INTERVAL]

QUANTITY = String

NODE-ID  = String
NETWORK-ID  = String
Integer = 1*DIGIT
Boolean = BIT
Double = 1*DIGIT ["." 1*DIGIT]
String = DQUOTE *VCHAR DQUOTE
END-OF-LINE = *(";")

 Figure 33 



 TOC 

4. Informative References

[RFC0822] Crocker, D., “Standard for the format of ARPA Internet text messages,” STD 11, RFC 822, August 1982 (TXT).
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” RFC 3261, June 2002 (TXT).
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, “Session Initiation Protocol (SIP) Extension for Instant Messaging,” RFC 3428, December 2002 (TXT).
[RFC5234] Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” STD 68, RFC 5234, January 2008 (TXT).
[RFC2817] Khare, R. and S. Lawrence, “Upgrading to TLS Within HTTP/1.1,” RFC 2817, May 2000 (TXT).
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” RFC 2616, June 1999 (TXT, PS, PDF, HTML, XML).
[RFC4119] Peterson, J., “A Presence-based GEOPRIV Location Object Format,” RFC 4119, December 2005 (TXT).
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC4122] Leach, P., Mealling, M., and R. Salz, “A Universally Unique IDentifier (UUID) URN Namespace,” RFC 4122, July 2005 (TXT, HTML, XML).
[GEO] GEOPRIV -- Geographic. Location/Privacy Working Group. Mayrhofer A.. Spanring C.., “A Uniform Resource Identifier for Geographic Locations ('geo' URI) draft-mayrhofer-geopriv-geo-uri-01,” 2009.
[OGC O&M] Open Geospatial Consortium Inc., “Observations and Measurements - Part 1 - Observation schema,” 2007.
[OGC TML] Open Geospatial Consortium Inc., “OpenGIS Transducer Markup Language (TML) Implementation Specification,” 2007.
[OPEN API INTRO] DACI Research Group, Department of Computer Systems, Tampere University of Technology, “OpenAPI Introduction,” 2010.
[MEDF] DACI Research Group, Department of Computer Systems, Tampere University of Technology, “Node Datasheet,” 2010.


 TOC 

Authors' Addresses

  Jukka Suhonen (editor)
  Department of Computer Systems, Tampere University of Technology
  Korkeakoulunkatu 1
  Tampere, 33101
  FI
Phone: 
Email:  tutwsn@cs.tut.fi
  
  Olli Kivela
  Department of Computer Systems, Tampere University of Technology
  Korkeakoulunkatu 1
  Tampere, 33101
  FI
Phone: 
Email:  tutwsn@cs.tut.fi