sec-chatty-things.tex

   1 \section{System Architecture of ``Chatty Things''}
   2
   3 After the underlying techniques have been explained, we can have a look at the
   4 system architecture which Klauck and
   5 Kirsche~\cite{Klauck:2012:BCC:2352852.2352881} use to build Chatty Things.
   6
   7 \todo
   8 \pages{3}
   9 \subsection{Service Provisioning Sublayer}
  10
  11 Considering the application in deeply embedded systems and the special needs of
  12 the Internet of Things on the one hand, the protocol stack needs to fulfil
  13 certain technical requirements.
  14
  15 First, memory, computing resources and bandwith on embedded systems are limited,
  16 which demands for a lightweight protocol stack without too much overhead and
  17 predictable memory consumption, while also retaining enough flexibility for
  18 future development. The authors therefore provide only the most essential
  19 functions of XMPP (presence and message exchange, multi-user chats) to achieve
  20 basic communication, grouping of devices, and information filtering to prevent
  21 information overflow.
  22
  23 Their solution builds on the \term{Contiki} operating system on an MSP430 board,
  24 and uses the \term{uXMPP} project, which already implements core XMPP features
  25 and serves as a starting point for implementing further XEPs. However, as the
  26 uXMPP project was still in early development, they first needed to enhance its
  27 functionality to comply with the limited resources. In particular, they
  28 optimized the message flow and enabled uXMPP to fully use the available payload
  29 instead of sending one TCP packet per message and reduced the code footprint
  30 through compiler flags and refactoring.
  31
  32 Furthermore, Klauck and Kirsche implemented new features for uXMPP, which were
  33 realized as separate modules to allow enabling and disabling them at runtime,
  34 thus further reducing the memory footprint of a running system:
  35
  36 \todo[minimize space between list item]
  37 \begin{itemize}
  38   \item support for IPv6
  39   \item support for Multi-User Chats (XEP-0045), which are used for information
  40     filtering
  41   \item support for SASL ANONYMOUS login for XMPP servers \ref{xep-0175}
  42   \item a new publish-subscribe mechanism called Temporary Subscription for
  43     Presence (see \ref{sec:tsp})
  44   \item XMPP Serverless Messaging (XEP-0174), using \term{uBonjour} as
  45     underlying mDNS/DNS-SD implementation for Contiki.
  46 \end{itemize}
  47
  48 The resulting implementation (uXMPP and uBonjour) gets by with 12{.}2\ kBytes of
  49 ROM and 0{.}63\ kBytes of RAM, which was about the size of the original,
  50 unoptimized uXMPP implementation while also implementing new features.
  51
  52 \todo[figure of example network structure with and without central server]
  53
  54 In order to react to different network infrastructures, their implementation
  55 allows both communication with a central XMPP server as well as peer-to-peer
  56 communication over XMPP Serverless Messaging. When a central XMPP server is
  57 detected over uBonjour, it is used instead with the ANONYMOUS login method, and the
  58 XEP-0174 module is disabled. The ANONYMOUS login method is chosen since TLS
  59 encryption is not yet implemented, and it assigns random JID to the client,
  60 which do not need to exist on the server. However, a server must exist and must
  61 be configured in order to use this method.
  62
  63 With a server, information filtering is achieved by creating topic-based
  64 Multi-User Chats where multiple devices can be grouped. A user can then simply
  65 join the chat with a standard XMPP client on her machine and interact with all
  66 devices of a topic, or she can also interact with them directly.
  67
  68 In scenarios without an XMPP server, the XEP-0174 module is activated and
  69 devices talk directly with the user or with other devices. This method has the
  70 drawback that Multi-User Chats cannot be used for topic filtering, since no
  71 method is specified to do XEP-0045 and XEP-0174 at the same time. \todo[temporary subscription presence here?]
  72 In this case,
  73 a user must have an XEP-0174-compliant chat client, but it also gives her the
  74 opportunity to interact with things spontaneously on an ad-hoc basis (e.~g. when
  75 entering a room) without need for any additional gateway on the application
  76 level.
  77
  78 %low bandwith in IEEE~802.15.4 (less than 250 kib/s at a maximum of 122 byte per
  79 %packet\footnote{according to the maximum MAC payload size in the IEEE~802.15.4-2011
  80 %specification}
  81
  82 \subsection{Bootstrapping}
  83
  84 In a distributed context like the Internet of Things, devices need to be ready
  85 to use out of the box. Users often do not want to set up configurations for each
  86 device they use, and when using several of those devices, it is often not
  87 reasonable having to configure every single one.
  88
  89 With the given approach, bootstrapping new Chatty Things is easy and no
  90 configuration is neccessary: on the network layer, IP addresses can simply be
  91 obtained using IPv4 Link-Local Addressing or IPv6 Stateless Address
  92 Autoconfiguration. On the transport layer, all needed ports can be obtained over
  93 DNS-Based Service Discovery. Finally, on the application layer, host names can
  94 be resolved over Multicast DNS; and for the actual communication between devices
  95 it is possible to use auto-generated JIDs with the ANONYMOUS login method on an
  96 existing XMPP server, or if no server is found, use peer-to-peer communication
  97 over XMPP Serverless Messaging.
  98
  99 Bootstrapping a Chatty Thing therefore incorporates three steps:
 100
 101 \begin{enumerate}
 102   \item Activate uBonjour and try to discover an XMPP server
 103   \item If a server is found, connect to it using ANONYMOUS login, join
 104     topic-based Multi-User Chats, deactivate the uBonjour client
 105     \term(Infrastructure mode).
 106   \item If no server is found, activate the XEP-0174 client \term{Ad-hoc mode}.
 107 \end{enumerate}
 108
 109 During runtime, a device can then react to changes in network infrastructure:
 110
 111 \begin{itemize}
 112   \item In Infrastructure mode: when connection to the server is lost, enable
 113     the uBonjour client, try to find a server, and when none is found, enable
 114     Serverless Messaging.
 115   \item In Ad-hoc mode: if uBonjour detects a new XMPP server joining the
 116     network, try to connect to it. If this succeeds, disable Serverless
 117     Messaging and uBonjour and join topic-based Multi-User Chats.
 118 \end{itemize}
 119
 120 \todo[short conclusion?]
 121
 122 \subsection{Temporary Subscription for Presence}\label{sec:tsp}
 123
 124 To further reduce the message overhead and allow more fine-grained controls over
 125 information filtering, \term{Temporary Subscription for Presence} is introduced.
 126 This technique builds on top of presence stanzas as defined in core XMPP. These
 127 presence stanzas are sent without a \code{to} or \code{from} attribute, and
 128 therefore fit into a single TCP/IP packet over IEEE~802.15.4. However, to be
 129 able to receive these stanzas, a client must manually subscribe to those
 130 information in their roster, which requires further communication between nodes. As the network
 131 can change rapidly, subscriptions would be often outdated, and there would be
 132 much overhead of subscriptions and unsubscription packets, which would inhibit
 133 the flow of the actual information.
 134
 135 To solve this problem, a dynamic, topic-based roster is implemented on top of
 136 Multi-User Chats (XEP-0045). Every topic corresponds with a chat room, and nodes
 137 join the chat rooms which they are interested in. This allows nodes to inform
 138 only interested nodes about updates. This has the advantage that existing
 139 clients supporting Multi-User Chats can be used by a user, but Chatty Things and
 140 XMPP servers need to be adapted to the new subscription model. Also, this
 141 mechanism does not work with Serverless Messaging.
 142
 143 % vim: set ft=tex et ts=2 sw=2 :