From: Roland Hieber Date: Mon, 23 Dec 2013 19:24:20 +0000 (+0100) Subject: finish additional XEPs X-Git-Tag: final~4 X-Git-Url: https://git.rohieb.name/skm-ma-ws1314.git/commitdiff_plain/f0fb3f3f678d8fe10cad4ff3920a60248a93a077?hp=fa6284da96446dd4a438bfb72d0e51c367dd3647 finish additional XEPs --- 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 +% + + %\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{} 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{} stanza. If it has +accepted the request, it reads out the requested data and returns it in a +subsequent \code{} 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{} or \code{} 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{} 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{} 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 :