+
+Considering the application in deeply embedded systems and the special needs of
+the Internet of Things on the one hand, the protocol stack needs to fulfil
+certain technical requirements.
+
+First, memory, computing resources and bandwith on embedded systems are limited,
+which demands for a lightweight protocol stack without too much overhead and
+predictable memory consumption, while also retaining enough flexibility for
+future development. The authors therefore provide only the most essential
+functions of XMPP (presence and message exchange, multi-user chats) to achieve
+basic communication, grouping of devices, and information filtering to prevent
+information overflow.
+
+Their solution builds on the \term{Contiki} operating system on an MSP430 board,
+and uses the \term{uXMPP} project, which already implements core XMPP features
+and serves as a starting point for implementing further XEPs. However, as the
+uXMPP project was still in early development, they first needed to enhance its
+functionality to comply with the limited resources. In particular, they
+optimized the message flow and enabled uXMPP to fully use the available payload
+instead of sending one TCP packet per message and reduced the code footprint
+through compiler flags and refactoring.
+
+Furthermore, Klauck and Kirsche implemented new features for uXMPP, which were
+realized as separate modules to allow enabling and disabling them at runtime,
+thus further reducing the memory footprint of a running system:
+
+\todo[minimize space between list item]
+\begin{itemize}
+ \item support for IPv6
+ \item support for Multi-User Chats (XEP-0045), which are used for information
+ filtering
+ \item support for SASL ANONYMOUS login for XMPP servers \ref{xep-0175}
+ \item a new publish-subscribe mechanism called Temporary Subscription for
+ Presence (see \ref{sec:tsp})
+ \item XMPP Serverless Messaging (XEP-0174), using \term{uBonjour} as
+ underlying mDNS/DNS-SD implementation for Contiki.
+\end{itemize}
+
+The resulting implementation (uXMPP and uBonjour) gets by with 12{.}2\ kBytes of
+ROM and 0{.}63\ kBytes of RAM, which was about the size of the original,
+unoptimized uXMPP implementation while also implementing new features.
+
+\todo[figure of example network structure with and without central server]
+
+In order to react to different network infrastructures, their implementation
+allows both communication with a central XMPP server as well as peer-to-peer
+communication over XMPP Serverless Messaging. When a central XMPP server is
+detected over uBonjour, it is used instead with the ANONYMOUS login method, and the
+XEP-0174 module is disabled. The ANONYMOUS login method is chosen since TLS
+encryption is not yet implemented, and it assigns random JID to the client,
+which do not need to exist on the server. However, a server must exist and must
+be configured in order to use this method.
+
+With a server, information filtering is achieved by creating topic-based
+Multi-User Chats where multiple devices can be grouped. A user can then simply
+join the chat with a standard XMPP client on her machine and interact with all
+devices of a topic, or she can also interact with them directly.
+
+In scenarios without an XMPP server, the XEP-0174 module is activated and
+devices talk directly with the user or with other devices. This method has the
+drawback that Multi-User Chats cannot be used for topic filtering, since no
+method is specified to do XEP-0045 and XEP-0174 at the same time. \todo[temporary subscription presence here?]
+In this case,
+a user must have an XEP-0174-compliant chat client, but it also gives her the
+opportunity to interact with things spontaneously on an ad-hoc basis (e.~g. when
+entering a room) without need for any additional gateway on the application
+level.
+
+%low bandwith in IEEE~802.15.4 (less than 250 kib/s at a maximum of 122 byte per
+%packet\footnote{according to the maximum MAC payload size in the IEEE~802.15.4-2011
+%specification}
+
projects / skm-ma-ws1314.git / commitdiff