\input{sec-dns-extensions.tex}
\input{sec-xmpp.tex}
\input{sec-chatty-things.tex}
+\input{sec-outlook.tex}
\input{sec-discussion.tex}
\bibliographystyle{plain}
\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
Klauck and Kirsche~\cite{klauck-kirsche-chattythings}, which proposes solutions
for information filtering, auto-configuration of devices and service discovery,
while using standard chat clients for human-to-machine communication.
-Section~\ref{sec:prereq} introduces the used techniques,
-Section~\ref{sec:arch} describes the proposed system architecture for Chatty
-Things, and Section~\ref{sec:discussion} discusses possible future enhancements
-and compares Chatty Things to similar approaches.
+Section~\ref{sec:prereq} introduces the used techniques, Section~\ref{sec:arch}
+describes the proposed system architecture for Chatty Things, while
+Section~\ref{sec:outlook} gives an outlook how this approach can be further
+enhanced. Finally, Section~\ref{sec:discussion} compares Chatty Things to
+related techniques and wraps this paper up.
% vim: set ft=tex et ts=2 sw=2 :
--- /dev/null
+\section{Outlook}\label{sec:outlook}
+
+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. Afterwards, both sides close their streams.
+
+\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.
+
+% vim: set ft=tex et ts=2 sw=2 :
projects / skm-ma-ws1314.git / commitdiff