sec-discussion.tex

   1 \section{Discussion}\label{sec:discussion}
   2
   3 \subsection{Future Work}
   4
   5 In addition to the XEPs covered above, there are a few additional XEPs which can
   6 be implemented to further increase the effectivity of Chatty Things. Especially
   7 the documents XEP-0323 through XEP-0326 (which are currently in Experimental
   8 status) are targeted to the Internet of Things.
   9
  10 \paragraph{Concentrators (XEP-0326)~\cite{xep0326}}
  11 In contrast to sensor nodes which are focused on collecting data, concentrators
  12 can be used to serve as a proxy and control a subset of the network. The XEP
  13 defines messages to query a sensor node for data sources, and subscribing to
  14 them, while subscription is loosely modeled after the Publish-Subscribe
  15 mechanism (XEP-0060). It also specifies how clients can request data or
  16 control certain nodes over a concentrator.
  17
  18 This approach can be practical in large-scale sensor networks, where usually not
  19 every sensor node can be reached directly, and where sensor nodes only have a
  20 very limited amount of storage. Individual concentrators can then be equipped
  21 with larger storage and serve as a facility to aggregate data from sensor nodes.
  22 This structure can be implemented on several levels, forming a hierarchy. A user
  23 interested in specific values then only needs to communicate with a single node
  24 in the network.
  25
  26 \paragraph{Sensor Data (XEP-0323)~\cite{xep0323}}
  27 This XEP specifies a way of reading out values from a
  28 sensor node. It allows to specify multiple data sources (e.~g. temperature,
  29 humidity) as well as multiple types of data (e.~g., momentary values, historical
  30 values, peak values).
  31 As a simple use case, the client sends an IQ stanza containing the request and a
  32 sequence number used to identify the request. The sensor node then rejects or
  33 accepts the request by returning a corresponding IQ stanza. If it has
  34 accepted the request, it reads out the requested data and returns it in a
  35 subsequent message stanza to the client.
  36
  37 An example of this protocol can be seen in Figure~\ref{fig:examplexmpp}: after
  38 both clients have opened their streams, the client requests the momentary values
  39 for power and energy from the node named \emph{Device04}. The device first
  40 acknowledges this request, and, after retrieving the values, sends them back
  41 to the client.
  42
  43 \input{fig-example-xmpp-stream.tex}
  44
  45 \paragraph{Control (XEP-0325)~\cite{xep0325}} In this document, a way of
  46 controlling sensor nodes is specified, which allows a client to get and set
  47 control values on the node over message or IQ stanzas. As an example, in this
  48 way a sensor node could be instructed to return data in a different unit or
  49 range, or be put into power-safe mode.
  50
  51 \paragraph{Provisioning (XEP-0324)~\cite{xep0324}}
  52 To protect the integrity of a sensor network and securing the data being
  53 collected, this XEP specifies a way of implementing access rights and user
  54 privileges. Since a single sensor node is usually very restricted in user input and
  55 output, the approach is very simple and can be implemented e.~g. using a button
  56 and an LED for interaction, while presentation of data takes places on a
  57 provisioning server with a rich user interface (which can be, for example, a
  58 concentrator).
  59
  60 When integrating a new sensor node into the network, the user instructs the
  61 provisioning server to generate a \term{friendship} request for the new node.
  62 The node can e.~g. symbolize this request by blinking its LED and requesting a
  63 button press in the next 30 seconds. If the user presses the button, the node
  64 confirms the friendship to the server. The server then remembers this sensor
  65 node and generates a token which must be used in all further communication
  66 between the server and the sensor node, else communication is rejected.
  67
  68 \paragraph{Efficient XML Interchange Format (EXI, XEP-0322)~\cite{xep0322}}
  69 Finally, EXI describes how XMPP stanzas sent between nodes can be compressed,
  70 thereby effectively reducing the overhead in message size introduced by XML.
  71 XMPP nodes can negotiate a compressed stream inside their existing XMPP streams
  72 and exchange \code{<compress>} stanzas which then contain the payload. However,
  73 it is to be noted that this requires further implementation of compression
  74 algorithms as well as additional CPU and memory resources and thus might
  75 decrease message throughput and increase power consumption on embedded systems.
  76
  77 \subsection{Related Approaches}
  78
  79 ``Chatty Things'' is not the only approach to implement communication in
  80 embedded networks. This section gives a short overview of related protocols for
  81 the Internet of Things and shows their advantages and disadvantages, which are
  82 summarized in Table~\ref{tab:comparison}.
  83
  84 \begin{table}
  85 \small\centering
  86 \caption{Comparison of related approaches}
  87 \label{tab:comparison}
  88 \begin{tabular}{|l||l|l|l|l|}
  89   \hline
  90   Feature & Chatty Things & CoAP & MQTT & WS4D \\
  91   \hline\hline
  92   application gateways necessary & - & yes & yes & - \\ \hline
  93   usable with standard clients & yes & - & - & (yes) \\ \hline
  94   discovery support & yes & yes & - & yes\\ \hline
  95   IPv6/6LoWPAN ready & yes & yes & ? & partial \\ \hline
  96   asynchronous messages & yes & yes & & \\ \hline
  97   protocol overhead & moderate & small & small & high \\ \hline
  98 \end{tabular}
  99 \end{table}
 100
 101 \paragraph{Constrained Application Protocol (CoAP)}
 102
 103 The Constrained Application Protocol~\cite{draft-ietf-core-coap-18} focuses on
 104 machine-to-machine communication and originates from the IETF Constrained
 105 Resources Working Group\footnote{\url{http://datatracker.ietf.org/wg/core/}},
 106 but still has been only in draft status since 2010.\ It allows a mapping to
 107 HTTP, and is therefore stateless, but it specifies a binary protocol, which
 108 makes it necessary to deploy application-level gateways and special client
 109 software to communicate with its environment. It relies on UDP, but emulates
 110 congestion control, message confirmation and message IDs, since – in contrast to
 111 HTTP – messages can be sent asynchronously. Discovery is also specified and done
 112 over multicast, service discovery is then done over a well-known URI on the
 113 host. Since it is a binary protocol and mostly self-contained, it has low
 114 protocol overhead and parsing complexity.
 115
 116 \paragraph{MQ Telemetry Transport (MQTT)}
 117
 118 Specified by IBM as a binary protocol, the MQ Telemetry Transport~\cite{mqtt}
 119 has been proposed as an OASIS standard for machine-to-machine communication. It
 120 also relies on TCP/IP, and its fixed message header is only 2 bytes in size, but
 121 can contain further variable headers. Since it is also only used in embedded
 122 networks, application gateways and appropriate client software are necessary.
 123 Its main feature is a publish-subscribe mechanism with topic names, discovery is
 124 not specified.
 125
 126 \paragraph{Web Service for Devices (WS4D)}
 127
 128 As a different approach to avoid application-level gateways, WS4D has been
 129 specified as a Devices Profile for Web Services~\cite{zeeb-moritz-ws4d}. Since
 130 Web Services are wide-spread in the business world, this approach can probably
 131 be used in existing infrastructures, and is also focused on multiple platforms
 132 like embedded systems and servers. Web Services can be very flexible and
 133 composable, and discovery is already specified, however, this also comes at a
 134 cost: messages are enclosed in SOAP, which is enclosed in HTTP, which is
 135 transported over TCP, which introduces a substantial overhead, especially with
 136 SOAP being based on verbose XML. IPv6 support is only partially implemented.
 137 For communication, standard APIs can be used.
 138
 139 \subsection{Conclusion}
 140
 141  With the XMPP
 142 protocol, there is the need to implement at least an XML parser on each node,
 143 which comes with protocol overhead and increased code size. However Klauck and
 144 Kirsche show that with good optimization (in the code as well as in the
 145 protocol), a complete stack can be implemented in 12 kBytes of ROM, which leaves
 146 enough space for other applications to be built onto it. As compared to Web
 147 Services, Chatty Things are probably not as flexible, but they have less
 148 overhead, even when using XML, while MQTT and CoAP provide less flexibility for
 149 future enhancement, but less protocol overhead and easier parsing.
 150
 151 With TCP, mDNS, DNS-SD and XMPP as foundation, the proposed architecture builds
 152 on reliable and established standards, which allows it to reuse Chatty Things in
 153 various contexts without the need for central infrastructure.
 154
 155 Nonetheless, a drawback is the virtual dependency from a centralized XMPP
 156 server in order to use Temporary Subscription for Presence for topic filtering,
 157 which is caused by the lack of support for Multi-User Chats in XEP-0174
 158 (Serverless Messaging). If this gap can be closed, or a different way for topic
 159 filtering in distributed networks is found, the server can be
 160 eliminated and what remains is a highly distributed network without the need for
 161 much central infrastructure, therefore eliminating most single points of failure
 162 in the system.
 163
 164 It is always hard to trade flexibility and accessibility for efficiency. The
 165 Chatty Things approach is probably not one of the most efficient, and not the
 166 most flexible, but it has the big advantage that users can interact with their
 167 things using standard chat clients, without the need for application gateways or
 168 specialized software. In terms of efficiency, it chooses a compromise between
 169 binary protocols and Web Services, latter which were originally developed for
 170 servers with much less resource constraints as embedded systems. However, with
 171 additional XEPs focusing on the Internet of Things, enough flexibility can be
 172 achieved for this use case.
 173
 174 % vim: set ft=tex et ts=2 sw=2 :