finish additional XEPs
authorRoland Hieber <rohieb@rohieb.name>
Mon, 23 Dec 2013 19:24:20 +0000 (20:24 +0100)
committerRoland Hieber <rohieb@rohieb.name>
Mon, 23 Dec 2013 19:24:47 +0000 (20:24 +0100)
sec-discussion.tex

index 0e4fe59..3133b6e 100644 (file)
@@ -2,6 +2,84 @@
 %\todo
 \pages{3}
 
 %\todo
 \pages{3}
 
+\subsection{Future Work}
+
+In addition to the XEPs covered above, there are a few additional XEPs which can
+be implemented to further increase the effictivity of Chatty Things. Especially
+the documents XEP-0323 through XEP-0326 (which are currently in Experimental
+status) are targeted to the Internet of Things.
+
+\paragraph{Concentrators (XEP-0326)~\cite{xep0326}}
+In contrast to sensor nodes which are focused on collecting data, concentrators
+can be used to control and serve as proxy for a subset of the network. The XEP
+defines messages to query a sensor node for data sources, and subscribing to
+them, while subscription is loosely modeled after the Publish-Subscribe
+mechanism (XEP-0060). It also specifies how clients can request data from or
+control certain nodes over a concentrator.
+
+This approach can be practical in large-scale sensor networks, where usually not
+every sensor node can be reached directly, and where sensor nodes only have a
+very limited amount of storage. Individual concentrators can then be equipped
+with larger storage and serve as a facility to aggregate data from sensor nodes.
+This structure can be implemented on several levels, forming a hierarchy. A user
+interested in specific values then only needs to communicate with a single node
+in the network.
+
+\paragraph{Sensor Data (XEP-0323)~\cite{xep0323}}
+%\begin{figure}
+  %\caption{Example stream between a sensor node and a client}
+  %\label{fig:streamexample}
+  %\begin{verbatim}
+%Client               Device
+%<stream>
+
+  %\end{verbatim}
+%\end{figure}
+This XEP specifies a way of reading out values from a
+sensor node. It allows to specify multiple data sources (e.~g. temperature,
+humidity) as well as multiple types of data (e.~g., momentary values, historical
+values, peak values).
+As a simple use case, the client sends an \code{<iq>} stanza containing the request and a
+sequence number used to identify the request. The sensor node then rejects or
+accepts the request by returning a corresponding \code{<iq>} stanza. If it has
+accepted the request, it reads out the requested data and returns it in a
+subsequent \code{<message>} stanza to the client.
+
+\paragraph{Control (XEP-0325)~\cite{xep0325}}
+In this document, a way of controlling sensor nodes is specified, which allows a
+client to get and set control values on the node over
+\code{<message>} or \code{<iq>} stanzas. As an example, in this way a sensor
+node can be instructed to return data in a different unit or range, or can be put
+into power-safe mode.
+
+\paragraph{Provisioning (XEP-0324)~\cite{xep0324}}
+To protect the integrity of a sensor network and securing the data being
+collected, this document specifies a way of implementing access rights and user
+privileges. Since a single sensor node is usually very restricted in user input and
+output, the approach is very simple and can be implemented e.~g. using a button
+and an LED for interaction, while presentation of data takes places on a
+provisioning server with a rich user interface (which can be, for example, a
+concentrator).
+
+When integrating a new sensor node into the network, the user instructs the
+provisioning server to generate a \term{friendship} request for the new node.
+The node can e.~g. symbolize this request by blinking its LED and requesting a
+button press in the next 30 seconds. If the user presses the button, the node
+confirms the friendship to the server. The server then remembers this sensor
+node and generates a token which must be used in all further communication
+between the server and the sensor node or the communication is rejected.
+
+\paragraph{Efficient XML Interchange Format (EXI, XEP-0322)~\cite{xep0322}}
+Finally, EXI describes how XMPP stanzas sent between nodes can be compressed,
+thereby effectively reducing the overhead in message size introduced by XML.
+XMPP nodes can negotiate a compressed stream inside their existing XMPP streams
+and exchange \code{<compress>} stanzas which then contain the payload. However,
+it is to be noted that this requires further implementation of compression
+algorithms as well as additional CPU and memory resources and thus might
+decrease message throughput and increase power consumption on embedded systems.
+
+
+\todo{example XML stream with sensor data}
 
 \subsection{Related Approaches}
 
 
 \subsection{Related Approaches}
 
@@ -96,23 +174,4 @@ specialized software. In terms of efficiency, it chooses a common ground between
 binary protocols and Web Services, which were originally developed for servers
 with much less resource constraints as embedded systems.
 
 binary protocols and Web Services, which were originally developed for servers
 with much less resource constraints as embedded systems.
 
-Nonetheless, there are a few additional XEPs which can be implemented to further
-increase the effictivity of Chatty Things. XEP-0322 (Efficient XML Interchange
-Format)~\cite{xep0322} describes how XMPP stanzas sent between a server and a
-client can be compressed, therefore effectively reducing the overhead introduced
-by XML. A client and a server can then negotiate a compressed stream inside
-their existing XMPP stream and exchange \code{<compress>} stanzas which contain
-the payload.
-
-The documents XEP-0324 through XEP-0326 contain specifications targeted
-especially to the Internet of Things:
-
-\todo{additional XEPs, example XML stream with sensor data}
-
-\begin{itemize}
- \item asdf
- \item asdfasdf
- \item lkjlkj
-\end{itemize}
-
 % vim: set ft=tex et ts=2 sw=2 :
 % vim: set ft=tex et ts=2 sw=2 :
This page took 0.024908 seconds and 4 git commands to generate.