From 9d21dccc2fd73cc36a0ea2527608bfd146912497 Mon Sep 17 00:00:00 2001 From: Roland Hieber Date: Wed, 15 Jan 2014 03:29:14 +0100 Subject: [PATCH] extract XEP outlook to separate section --- main.tex | 1 + sec-discussion.tex | 74 --------------------------------------------- sec-intro.tex | 9 +++--- sec-outlook.tex | 75 ++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 81 insertions(+), 78 deletions(-) create mode 100644 sec-outlook.tex diff --git a/main.tex b/main.tex index cd97214..ba0b733 100644 --- a/main.tex +++ b/main.tex @@ -41,6 +41,7 @@ communication protocol used in Chatty Things. \input{sec-dns-extensions.tex} \input{sec-xmpp.tex} \input{sec-chatty-things.tex} +\input{sec-outlook.tex} \input{sec-discussion.tex} \bibliographystyle{plain} 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{} 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 diff --git a/sec-intro.tex b/sec-intro.tex index f952099..a9ededc 100644 --- a/sec-intro.tex +++ b/sec-intro.tex @@ -17,9 +17,10 @@ This paper gives an overview of the ``Chatty Things'' approach as presented by 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 : diff --git a/sec-outlook.tex b/sec-outlook.tex new file mode 100644 index 0000000..8e3eb6c --- /dev/null +++ b/sec-outlook.tex @@ -0,0 +1,75 @@ +\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{} 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 : -- 2.20.1