X-Git-Url: https://git.rohieb.name/skm-ma-ws1314.git/blobdiff_plain/2c0161afb1c6a586eab897af57d3288f74c3ddb5..9d21dccc2fd73cc36a0ea2527608bfd146912497:/sec-discussion.tex

diff --git a/sec-discussion.tex b/sec-discussion.tex
index 534bb25..0c3838d 100644
--- a/sec-discussion.tex
+++ b/sec-discussion.tex
@@ -1,79 +1,5 @@
 \section{Discussion}\label{sec:discussion}
 
-\subsection{Future Work}
-
-In addition to the XEPs covered above, there are a few additional XEPs which can
-be implemented to further increase the effectivity 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 serve as a proxy and control 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 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}}
-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 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 IQ stanza. If it has
-accepted the request, it reads out the requested data and returns it in a
-subsequent message stanza to the client.
-
-An example of this protocol can be seen in Figure~\ref{fig:examplexmpp}: after
-both clients have opened their streams, the client requests the momentary values
-for power and energy from the node named \emph{Device04}. The device first
-acknowledges this request, and, after retrieving the values, sends them back
-to the client.
-
-\input{fig-example-xmpp-stream.tex}
-
-\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 message or IQ stanzas. As an example, in this
-way a sensor node could be instructed to return data in a different unit or
-range, or 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 XEP 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, else 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.
-
 \subsection{Related Approaches}
 
 ``Chatty Things'' is not the only approach to implement communication in