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