\section{System Architecture of ``Chatty Things''}
+
+After the underlying techniques have been explained, we can have a look at the
+system architecture which Klauck and
+Kirsche~\cite{Klauck:2012:BCC:2352852.2352881} use to build Chatty Things.
+
\todo
\pages{3}
\subsection{Service Provisioning Sublayer}
+
+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}
+
\subsection{Bootstrapping}
-\subsection{Presence Subscription}
+In a distributed context like the Internet of Things, devices need to be ready
+to use out of the box. Users often do not want to set up configurations for each
+device they use, and when using several of those devices, it is often not
+reasonable having to configure every single one.
+
+With the given approach, bootstrapping new Chatty Things is easy and no
+configuration is neccessary: on the network layer, IP addresses can simply be
+obtained using IPv4 Link-Local Addressing or IPv6 Stateless Address
+Autoconfiguration. On the transport layer, all needed ports can be obtained over
+DNS-Based Service Discovery. Finally, on the application layer, host names can
+be resolved over Multicast DNS; and for the actual communication between devices
+it is possible to use auto-generated JIDs with the ANONYMOUS login method on an
+existing XMPP server, or if no server is found, use peer-to-peer communication
+over XMPP Serverless Messaging.
+
+Bootstrapping a Chatty Thing therefore incorporates three steps:
+
+\begin{enumerate}
+ \item Activate uBonjour and try to discover an XMPP server
+ \item If a server is found, connect to it using ANONYMOUS login, join
+ topic-based Multi-User Chats, deactivate the uBonjour client
+ \term(Infrastructure mode).
+ \item If no server is found, activate the XEP-0174 client \term{Ad-hoc mode}.
+\end{enumerate}
+
+During runtime, a device can then react to changes in network infrastructure:
+
+\begin{itemize}
+ \item In Infrastructure mode: when connection to the server is lost, enable
+ the uBonjour client, try to find a server, and when none is found, enable
+ Serverless Messaging.
+ \item In Ad-hoc mode: if uBonjour detects a new XMPP server joining the
+ network, try to connect to it. If this succeeds, disable Serverless
+ Messaging and uBonjour and join topic-based Multi-User Chats.
+\end{itemize}
+
+\todo[short conclusion?]
+
+\subsection{Temporary Subscription for Presence}\label{sec:tsp}
+
+To further reduce the message overhead and allow more fine-grained controls over
+information filtering, \term{Temporary Subscription for Presence} is introduced.
+This technique builds on top of presence stanzas as defined in core XMPP. These
+presence stanzas are sent without a \code{to} or \code{from} attribute, and
+therefore fit into a single TCP/IP packet over IEEE~802.15.4. However, to be
+able to receive these stanzas, a client must manually subscribe to those
+information in their roster, which requires further communication between nodes. As the network
+can change rapidly, subscriptions would be often outdated, and there would be
+much overhead of subscriptions and unsubscription packets, which would inhibit
+the flow of the actual information.
+
+To solve this problem, a dynamic, topic-based roster is implemented on top of
+Multi-User Chats (XEP-0045). Every topic corresponds with a chat room, and nodes
+join the chat rooms which they are interested in. This allows nodes to inform
+only interested nodes about updates. This has the advantage that existing
+clients supporting Multi-User Chats can be used by a user, but Chatty Things and
+XMPP servers need to be adapted to the new subscription model. Also, this
+mechanism does not work with Serverless Messaging.
+
+% vim: set ft=tex et ts=2 sw=2 :
projects / skm-ma-ws1314.git / blobdiff