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