extract XEP outlook to separate section
[skm-ma-ws1314.git] / sec-outlook.tex
diff --git a/sec-outlook.tex b/sec-outlook.tex
new file mode 100644 (file)
index 0000000..8e3eb6c
--- /dev/null
@@ -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{<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 :
This page took 0.02606 seconds and 4 git commands to generate.