X-Git-Url: http://git.rohieb.name/skm-ma-ws1314.git/blobdiff_plain/fa6284da96446dd4a438bfb72d0e51c367dd3647..f0fb3f3f678d8fe10cad4ff3920a60248a93a077:/sec-discussion.tex?ds=sidebyside

diff --git a/sec-discussion.tex b/sec-discussion.tex
index 0e4fe59..3133b6e 100644
--- a/sec-discussion.tex
+++ b/sec-discussion.tex
@@ -2,6 +2,84 @@
 %\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}
 
@@ -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.
 
-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 :
