bachelor-thesis/thesis/chapters/fitlab.tex
2018-09-21 11:45:21 +02:00

593 lines
28 KiB
TeX

\chapter{FIT IoT-LAB}
\label{chap:hardware}
\fitlab \cite{adjih2015fit} is part of a an open testbed for \ac{WSN} and is
composed of more than 2000 nodes. It is part of a larger federation of \ac{WSN}
testbeds called \emph{OneLab} \cite{baron2015onelab}, which also includes
\emph{CorteXlab}\footnote{\url{http://www.cortexlab.fr/}},
\emph{NITLab6}\footnote{\url{ http://nitlab.inf.uth.gr/}} and \emph{FIT
NITOS-Lab}\footnote{\url{http://fit-nitos.fr/}}, \emph{PlanetLab
Europe}\footnote{\url{http://planet-lab.eu/}}, \emph{FUSECO
Playground}\footnote{\url{http://fuseco-playground.org/}} and
\emph{w-iLab.t}\footnote{\url{http://ilabt.iminds.be/wilabt}}. \fitlab provides
a large scale test network for educational, scientific and industrial purposes
to end users which can be used for obtaining reproducible results since experiments
can run fully automated and all hardware and software is freely available under
open source licenses.
\section{Sensor Nodes}
\label{sec:architecture}
\usetikzlibrary{shapes,shapes.misc,positioning,circuits.ee.IEC}
\tikzstyle{system}=[shape=rounded rectangle,fill=tubsBlueLight20,text centered,draw]
\tikzstyle{sensor}=[rectangle,fill=tubsOrangeLight20,text centered,draw]
\tikzstyle{processor}=[rectangle,fill=tubsBlueLight20,text centered,draw]
\tikzstyle{connector}=[rectangle,fill=tubsGreenLight20,text centered,draw]
\tikzstyle{memory}=[rectangle,fill=tubsGreenLight20,text centered,draw]
\tikzstyle{radio}=[rectangle,fill=tubsBlue20,text centered,draw]
\tikzstyle{bus}=[<->,color=black,draw]
\tikzstyle{buslabel}=[near end,color=black,font=\tiny,auto]
\tikzstyle{vcc}=[->,color=tubsRed,font=\tiny,draw,text=black]
Each node in the testbed is itself assembled from three individual nodes: The
\ac{ON}, the \ac{GW}, and the \ac{CN} (see also \autoref{fig:fitnode}). The
\ac{ON}, which in this setup is the actual sensor node, is controlled and
programmed by the \ac{CN} via the \emph{Open Node Connector}, In the case of the
\emph{M3} (see \autoref{subsec:m3}) \ac{ON}, the \ac{GW} and \ac{CN} are both
implemented on the same node, called the \emph{Host Node}.
\begin{figure}[h]
\centering
\begin{tikzpicture}[node/.style={circle,draw}]
\begin{scope}[node distance=2cm]
\node (a) {ON};
\node (b) [right=of a] {CN};
\node (c) [right=of b] {GW};
\end{scope}
\begin{scope}[<->,>=stealth',auto]
\path (a) edge[bend left] (b)
(b) edge (c);
\end{scope}
\node[draw,dotted,fit=(b)(c)](group){};
\draw[line width=1pt,black,decorate,decoration={amplitude=7pt,brace,mirror}]
(group.south west) -- (group.south east);
\node[below=of group,anchor=center]{Host Node};
\end{tikzpicture}
\caption{Architecture of a \fitlab node in the testbed}
\label{fig:fitnode}
\end{figure}
\subsection{The Open Node}
The \ac{ON} is either based on the
\emph{WSN430}\footnote{\url{https://www.iot-lab.info/hardware/wsn430/}}, an
\emph{M3}\footnote{\url{https://www.iot-lab.info/hardware/m3/}} or an
\emph{A8}\footnote{\url{https://www.iot-lab.info/hardware/a8/}} microprocessor,
and a different number of nodes of each type are available depending on the test
site. All nodes except the \emph{A8} node can run \emph{RIOT}
\cite{baccelli2013riot}, \emph{OpenWSN} \cite{watteyne2012openwsn},
\emph{FreeRTOS}\footnote{\url{http://www.freertos.org/}} and \emph{Contiki},
The \emph{A8} only supports
Linux. In addition, the \emph{WSN430}
also has support for \emph{TinyOS} \cite{levis2005tinyos}. Some of the nodes are
mobile and can be configured to move on specified paths through the network.
Their movements can be tracked using \ac{GPS} and are available to the user.
In this evaluation, the \emph{M3} node has been selected for use as the \ac{ON}.
(see \autoref{subsubsec:reasonsm3}).
\subsection{The M3 Node}
\label{subsec:m3}
All experiments in this work have been performed using the \emph{M3} open node.
A simplified block diagram of this node can be seen in
\autoref{fig:m3node}\footnote{\url{https://github.com/iot-lab/iot-lab/wiki/Hardware_M3-node}}.
None of the external peripherals are used in the experiment and can therefore be
disabled to conserve energy.
\begin{figure}
\centering
\begin{tikzpicture}
\node[processor] (cpu)[minimum width=50,minimum height=50] {M3}; %STM32F103RKEY
\node[memory] (flash) [below of=cpu,below=0.5] {Flash}; %N25Q128A
\draw[bus,transform canvas={xshift=-10}] (flash) edge node[buslabel] {GPIO} (cpu);
\draw[bus,transform canvas={xshift=10}] (flash) edge node[buslabel] {SPI} (cpu);
\node[radio] (wireless) [right of=cpu,above of=cpu,right=0.4] {Radio}; %AT86RF231
\path[bus] (wireless.240) |- node[buslabel,above] {GPIO} (cpu.10);
\path[bus] (wireless) |- node[buslabel] {SPI} (cpu);
\node[system] (usbb) [above of=cpu,above=1] {USB Bridge};
\path[bus] (usbb) edge node[buslabel] {JTAG} (cpu);
\path[bus,transform canvas={xshift= 20}] (usbb) edge node[buslabel] {UART} (cpu);
\node[connector] (oc) [above of=usbb,above=1,minimum width=100] {Open Node Connector};
\path[bus] (usbb) edge node[buslabel]{USB} (oc) ;
\path[bus] (oc.190) |- node[buslabel]{GPIO} (cpu.160) ;
\node[connector] (usb) [right of=oc,below of=oc,right=0.5] {USB};
\path[bus] (oc) |- (usb);
\node[processor] (pm) [below of=usb] {Power};
\node[sensor] (light) [minimum width=80,below left of=oc,left=1.5] {Light Sensor}; %ISL29020
\node[sensor] (pressure)[minimum width=80,below of=light] {Pressure Sensor}; %LPS331AP
\node[sensor] (gyro) [minimum width=80,below of=pressure] {Gyroscope}; %L3G4200D
\node[sensor] (magneto) [minimum width=80,below of=gyro] {Magnetometer}; %LSM303DLHC
\path[bus] (oc.188) |- (light);
\path[bus] (oc.188) |- (gyro);
\path[bus] (oc.188) |- (magneto);
\path[bus] (oc.188) |- (pressure);
\path[bus] (oc.188) |- node[buslabel,below] {I2C} (cpu.190);
\path[bus] (gyro) -| node[buslabel,below] {GPIO} (cpu.120);
\path[bus] (magneto.10)-| (cpu.120);
\path[vcc] (pm.210) |- node[below] {+3.3 V} (usbb);
\path[vcc,orange,text=black] (pm) -- node[auto] {+3.3 V mon.} (wireless);
\path[vcc] (usb) -- node[left] {+5} (pm);
\path[vcc] (oc.340) |- node[near start,auto] {+3.3} (pm.165);
\path[vcc,orange,text=black] (oc.330) |- node[near start,left] {+5} (pm.175);
\path[vcc,orange,text=black] (pm) |- (1,1.8) -| (cpu.70);
\path[vcc,orange,text=black] (pm) |- (1,1.8) -- (0.5,1.8);
\node[rounded rectangle,right of=pm,right=0.1] (gnd) {GND};
\path[vcc,<->] (pm) -- (gnd);
\end{tikzpicture}
\caption{Simplified block diagram of the M3 node}
\label{fig:m3node}
\end{figure}
% better than wsn430: more diversity, closer to real world deployments in modern iot
\subsubsection{CPU}
The \emph{M3} node features a 32-bit ARM Cortex-M3 based CPU (STM32F103REY)
\cite{stm32f103re} with a maximum clock frequency of 72 MHz. The external clock
runs the \ac{CPU} at this maximum clock frequency, which is to be considered
when evaluating the energy consumption. With all peripherals enabled, this
results in a maximum of 70 mA at 3.3 V \ac{VCC}.
The \ac{CPU} has support for low power modes. When in the \emph{Sleep} mode, the
\emph{CPU} is stopped and all peripherals continue working, in the \emph{Stop}
mode all clocks are stopped and only the contents of \ac{SRAM} and \ac{CPU}
registers are preserved. When in the \emph{Standby} mode the contents of the
registers and \emph{SRAM} are not preserved and the \emph{CPU} can only be woken
up by alarms from the \ac{RTC} or an external reset.
The \ac{JTAG} and \ac{UART} are bridged over \ac{USB} and exposed through the
\emph{Open Node Connector}.
\subsubsection{Flash Memory}
The external \emph{N25Q128} \cite{N25Q128} NOR flash is connected to the
\ac{SPI} of the \ac{CPU} and has a storage capacity of 128 MByte and supports a
maximum frequency of 100 MHz. The \ac{CPU} uses a maxium of 18 MHz for the
\ac{SPI} which results in a maximum 18 Mb/s read / write speed. The
current consumption for page size read / write access is 20 mA.
\subsubsection{Wireless Radio Transceiver}
The \emph{M3} has an ATMEL AT86RF231 2.4 GHz radio \cite{AT86RF231}, which is
connected through \ac{SPI} and \ac{GPIO} and are supplied with 3.3 V. It consumes up to
14 mA when transmitting with a maximum \ac{TX} gain of 3 dBm. For this work, the
\ac{TX} has been set to -7 dBm and the \ac{RX} threshold has been set to -60 dBm
(see \autoref{subsec:rssi}). As such, \ac{TX} needs less than 11 mA when transmitting and
10 mA while receiving. The \emph{6LowPAN} network \cite{rfc4944} stack of \emph{Contiki}
uses the IEEE 802.15.4 support of the transceiver.
\subsubsection{Rationale for Choosing the M3 Node}
\label{subsubsec:reasonsm3}
Instead of the \emph{WSN430}, the \emph{M3} node has been selected for the
evaluation. While the \emph{WSN430} has the advantage of having almost the same processor
(\emph{MSP430}) as the \emph{Z1} node, driver support for the \emph{WSN430}
peripherals like the NOR Flash is based on an an outdated version of
\emph{Contiki}. Moreover, only a very limited amount of nodes of this type had
been available at the time of writing and also not in the linear topology
desirable for the evaluation \autoref{sec:ptopo}.
While the drivers for the \emph{M3} do not support energy estimations using
\emph{Energest} \cite{dunkels2011powertrace}, in-case of the \emph{M3} node,
\emph{Host Node} can record the voltage, current and power consumption of the
\ac{ON} in real time. In doing so, even more accurate and realistic measurements
of the energy consumption are available compared to the profiling done using
\emph{Powertrace}. The \emph{WSN430} for one is not controlled by the \emph{Host
Node} so not all variables that would be desirable for the evaluation, such as
\ac{PCAP} files, can be recorded with it.
Another reason for selecting the \emph{M3} node instead of the \emph{WSN430}
was, that a more powerful processor is available, as will likely be the case in
most modern \ac{IoT} applications, and as such it better models the energy
consumption of these use-cases.
\subsubsection{Considerations for Power Consumption}
One thing to keep in mind when measuring the power consumption at the \ac{ON} is
that only the consumption of the components that can be controlled by the
firmware is monitored. For this, the power management unit monitors the voltage
and current of a separate output besides the one supplying the \ac{USB} bridge. The
power management unit can be supplied both through the open node connector (3.3
V) or directly via \ac{USB} (+5 V).
The core components, on which the experiments in this work have an effect in
terms of power consumption,, are the flash memory, because of the persistence
layer for \ac{RPL}, the \ac{CPU} because the restoring needs some amount of
cycles to complete and the radio, as additional / fewer routing messages may be
sent in the individual modes of the hardened implementation.
The peripheral components, such as the different sensors are not of interest for
the evaluation, since they are not differently depending on whether there are
resets occurring or if the hardened implementation is being used.
\begin{table}
\centering
\caption{Consumption estimates for monitored components}
\begin{tabular}{lr}
\toprule
Component & Current Consumption (3.3 V) \\
\midrule
CPU & 70 mA \\
Radio & SLEEP 20 $\mu$A | OFF 0.4 mA | RX 10.3 mA | TX 10 mA\\
Flash & 20 mA
\end{tabular}
\label{tab:consum}
\end{table}
\autoref{tab:consum} shows the different consumption estimates as they were
obtained from the data sheets of the components. It should be noted, that the
consumption of the \ac{CPU} and the wireless radio could be further reduced by
reducing the clock rate the \ac{CPU} is initialized with and reducing the
transmission power of the radio. Both can be configured using software. For the
evaluation, it was sufficient to keep these values, since a relative comparison
between networks with and without resets should be made.
\subsection{Host Node}
For the \emph{M3} and \emph{A8} nodes, the \ac{HN} serves as both the \ac{GW}
and the \ac{CN}. Each \ac{HN} is directly connected to one or more \ac{ON} using
the \emph{Open Node Connector} and serves the purpose of controlling and
recording the experiment on the \ac{ON}. A simplified block diagram of the
\emph{Host Node} is shown in \autoref{fig:hnblock}.
The \ac{CN} is used for starting and stopping the \ac{ON}, flashing the firmware
and providing a remote \ac{JTAG} debugger via the \ac{USB} bridge on the \ac{ON}
and powering the \ac{ON} from battery or the an external power supply. It also
can monitor the power consumption and record the \ac{RSSI} at the \ac{ON}. As an
alternative to monitoring the \ac{RSSI} the \ac{CN} can record \acp{PCAP} of the
network at the \ac{ON}. For this it has its own radio, similar to the one
supplying the \emph{M3} \ac{ON}. It can also be used for recording sensor data from the
peripherals of the \ac{ON} using \ac{I$^2$C}.
The \ac{GW} part of the \ac{HN} features a more powerful \emph{A8} application
processor and is connected to the site server using a wired
\emph{Ethernet} connection. It is running \emph{Linux} and can provide the
\ac{HN} with network access for applications such as running a remote debugger,
flashing the firmware and starting and stopping the node. It also stores the
measured data from the \ac{CN} which then periodically is fetched by the
site server.
Both the \ac{CT} and the \ac{AM} of the power management unit are configurable
in the profile of the experiment so that a range of different \ac{PM} can be
used for sampling the consumption.
\begin{equation}
PM = CT \times AM \times 2
\end{equation}
\begin{figure}
\pgfdeclarelayer{background}
\pgfdeclarelayer{foreground}
\pgfsetlayers{background,main,foreground}
\centering
\begin{tikzpicture}
% CN part
\node[processor] (cpu)[minimum width=50,minimum height=50] {M3};
\node[radio] (wireless) [right of=cpu,right=0.5] {Radio};
\node[system] (bridge) [below of=cpu,below=0.5] {USB Bridge};
\path[bus] (bridge.120) -- node [buslabel,left] {JTAG} (cpu.260);
\path[bus] (bridge.60) -- node [buslabel,right] {SPI} (cpu.280);
\path[bus] (wireless.north west) -- node [buslabel,above] {SPI} (cpu.19);
\path[bus] (wireless.south west) -- node [buslabel,below] {GPIO} (cpu.-19);
\begin{pgfonlayer}{background}
\node [draw,fit=(cpu)(wireless)(bridge),label=above:\tiny{Control Node},fill=tubsGray20] (cn) {};
\end{pgfonlayer}
\node[processor] (a8) [minimum width=100,minimum height=100,left of=cn,left=4,above of=cpu] (a8) {A8};
\node[system] (eth) [below of=a8,below=1] {ETH SW};
\node[connector] (eth0) [below of=eth,right of=eth,below=0.001] {ETH};
\node[connector] (eth1) [below of=eth,below=0.001] {ETH};
\node[connector] (eth2) [below of=eth,left of=eth,below=0.001] {ETH};
\path[bus] (eth) -- node[buslabel,above] {ETH} (a8);
\path[bus] (eth1) -- (eth);
\path[bus] (eth0) |- (eth);
\path[bus] (eth2) |- (eth);
\node[system] (uhub) [above of=a8,above=2,left of=a8] {USB Hub};
\path[bus] (uhub) -- node[buslabel,below] {USB} (a8.120);
\node[connector] (usb0) [above of=uhub] {USB};
\node[connector] (usb1) [above of=uhub,left of=uhub] {USB};
\node[connector] (usb2) [above of=uhub,right of=uhub] {USB};
\path[bus] (usb2) |- (uhub);
\path[bus] (usb0) -- (uhub);
\path[bus] (usb1) |- (uhub);
\node[system] (ubridge2) [right of=uhub,right=2,above of=a8,above=1] {USB Bridge};
\path[bus] (ubridge2) -- node[buslabel,below] {UART} (a8.60);
\node[connector] (onc) [minimum width=200,right of=usb2,right=0.5] {Open Node Connector};
\node[connector] (pwr) [right of=onc,right=3] {Power};
\node[processor] (pwrmgnt) [below of=pwr,below=1] {Power Mgnt};
\node[processor] (cmsr) [below of=pwrmgnt,left of=pwrmgnt,left=2] {Current Msr};
\path[bus] (ubridge2) |- node[buslabel] {USB} (onc.south west);
\path[bus] (eth.north east) -| node[buslabel] {ETH} (onc.187);
\path[bus] (bridge.north west) -| node[buslabel] {UART} (onc.190);
\path[bus] (cpu.160) -| node[buslabel,left] {GPIO} (onc.192);
\path[bus] (cpu.north west) -| node[buslabel,right] {I2C} (onc.194);
\path[vcc,<-] (usb2.south east) |- (3.55,4) -- (pwrmgnt.north west);
\node[label=above left:\tiny{5V}] at (3.55,4) {};
\path[vcc] (3.55,4) -| (cmsr.100);
\path[vcc] (pwrmgnt.north west) -- (onc.south east);
\path[vcc] (pwr) -- node[buslabel,right] {+3.3V to 5V} (pwrmgnt);
\path[vcc,<->] (cmsr.north east) |- (pwrmgnt);
\path[vcc] (pwrmgnt) |- node[buslabel] {+48V} (4.5,-2.4) -| (eth0.east);
\path[vcc,orange] (pwrmgnt.160) |- (onc.east);
\path[vcc,orange] (pwrmgnt.160) |- node[buslabel,below] {+3.3V} (1,3.5) -- (cmsr.28);
\node[draw,rounded rectangle] (gnd) at (2.8,2) {GND};
\path[vcc] (gnd) |- (pwrmgnt);
\end{tikzpicture}
\caption{Simplified block diagram of the Host Node}
\label{fig:hnblock}
\end{figure}
\section{Physical Topology of the Testbed}
\label{sec:ptopo}
When looking at previous studies, the influence of the physical topology of a
network on the routing topology came to attention. This can be used to
affect the routing decisions of \ac{RPL} and reliably create certain \acp{DAG}
in some cases. Nevertheless, with such a large test network of linearly
distributed, we can study the full range of possible outcomes resulting from
\ac{RPL} being applied to it.
For the evaluation, a large network of 44 nodes that are approximately linearly
distributed inside the test lab has been selected. A map of the test network at
\emph{Inria}\footnote{\url{https://www.iot-lab.info/deployment/lille/}} in
France is shown in \autoref{fig:testbed}, where the red nodes are selected for
our experiment, the grey nodes are mounted at the ceiling over a 1.2 $\times$
1.2 m grid at a height of 2.5 m, yellow nodes are attached to vertical poles at
2.4 m, 1.5 m and 0.6 m high and the green square represents the position of the
server cabinet. Additionally, the floor-plan is shown as an outline.
Nodes participating in the experiment are marked as blue circle. Node \emph{157}
has been statically selected as the root of the \ac{DAG}.
\tikzstyle{cnode}=[circle,fill=tubsLightOrange100,text centered,font=\tiny,fill
opacity=0.5,draw opacity=0.5,text opacity=1.0]
\tikzstyle{snode}=[circle,fill=tubsGray20,text centered,font=\tiny,fill
opacity=0.2,draw opacity=0.2,text opacity=1.0]
\tikzstyle{pnode}=[circle split,draw,text centered,fill=tubsLightOrange20,draw opacity=0.1,text opacity=1.0,fill opacity=0.1,font=\tiny]
%TODO latex number vs strings wtf
\newcommand{\fitnode}[3]{%
\ifthenelse
{#3 = 47 \OR #3 = 49 \OR #3 = 51 \OR #3 = 53 \OR #3 = 57 \OR #3 = 59 \OR #3 = 83 \OR #3 = 85 \OR #3 = 87 \OR #3 = 89 \OR #3 = 91 \OR #3 = 93 \OR #3 = 95 \OR #3 = 123 \OR #3 = 127 \OR #3 = 131 \OR #3 = 133 \OR #3 = 151 \OR #3 = 153 \OR #3 = 155 \OR #3 = 157 \OR #3 = 159 \OR #3 = 161 \OR #3 = 192 \OR #3 = 194 \OR #3 = 196 \OR #3 = 198 \OR #3 = 200 \OR #3 = 202 \OR #3 = 204 \OR #3 = 218 \OR #3 = 220 \OR #3 = 222 \OR #3 = 224 \OR #3 = 226 \OR #3 = 228 \OR #3 = 230 \OR #3 = 244 \OR #3 = 246 \OR #3 = 248 \OR #3 = 250 \OR #3 = 252 \OR #3 = 254 \OR #3 = 256}%\isin{47}{ \OR #3 = 47 \OR #3 = 49 \OR #3 = 51 \OR #3 = 53 \OR #3 = 57 \OR #3 = 59 \OR #3 = 83 \OR #3 = 85 \OR #3 = 87 \OR #3 = 89 \OR #3 = 91 \OR #3 = 93 \OR #3 = 95 \OR #3 = 123 \OR #3 = 127 \OR #3 = 131 \OR #3 = 133 \OR #3 = 151 \OR #3 = 153 \OR #3 = 155 \OR #3 = 157 \OR #3 = 159 \OR #3 = 161 \OR #3 = 192 \OR #3 = 194 \OR #3 = 196 \OR #3 = 198 \OR #3 = 200 \OR #3 = 202 \OR #3 = 204 \OR #3 = 218 \OR #3 = 220 \OR #3 = 222 \OR #3 = 224 \OR #3 = 226 \OR #3 = 228 \OR #3 = 230 \OR #3 = 244 \OR #3 = 246 \OR #3 = 248 \OR #3 = 250 \OR #3 = 252 \OR #3 = 254 \OR #3 = 256}}
{\node at (#1,#2) [cnode] {#3};}
{\node at (#1,#2) [snode] {#3};}
}
\begin{figure}
\centering
\usetikzlibrary{shapes}
\begin{tikzpicture}
\draw [black!20] (-0.3,13) -- (7.5,13) -- (7.5,4.8) -- (8.7,4.8) -- (8.7,0.8) -- (4.2,0.8) -- (4.2,-0.6) -- (-0.3,-0.6) -- cycle;
\draw [tubsBlack!20] (8.7,13) -- (13.2,13) -- (13.2,-0.6) -- (8.7,-0.6) -- cycle;
\fill [tubsLightGreen] (4.7,12.4) rectangle (5.3,12.9);
\fill [tubsBlack!20] (-0.3,9.2) rectangle (-0.2,11.9);
\fill [tubsBlack!20] (-0.3,0.2) rectangle (-0.2,2.6);
\fill [tubsBlack!20] (0,13) rectangle (2.2,13.1);
\draw [tubsBlack!20] (-0.4,3.95) rectangle (-0.3,4.1);
\draw [tubsBlack!20] (-0.4,7.95) rectangle (-0.3,8.10);
\draw [tubsBlack!20] (4.05,3.75) rectangle (4.2,3.9);
\draw [tubsBlack!20] (4.05,8.05) rectangle (4.2,8.2);
\draw [tubsBlack!20] (7.40,8.05) rectangle (7.55,8.2);
\draw [tubsBlack!20] (8.65,3.75) rectangle (8.80,3.9);
\foreach \x in {0,1,...,4} {
\foreach \y in {0,1,...,12} {
\pgfmathparse{int(29+\x*18+(12-\y))}
\edef\p{\pgfmathresult}
\fitnode{\x}{\y}{\p}
}
}
\foreach \x in {0,1,...,2} {
\foreach \y in {1,2,...,12} {
\pgfmathparse{int(123+\x*14+(12-\y))}
\edef\p{\pgfmathresult}
\fitnode{\x+5}{\y}{\p}
}
}
\foreach \y in {1,2,...,7} {
\pgfmathparse{int(190-\y)}
\edef\p{\pgfmathresult}
\fitnode{8}{\y}{\p}
}
\foreach \y in {9,10,...,12} {
\pgfmathparse{int(191-\y)}
\edef\p{\pgfmathresult}
\fitnode{8}{\y}{\p}
}
\foreach \x in {0,1,...,4} {
\foreach \y in {0,1,...,12} {
\pgfmathparse{int(256-(4-\x)*13-\y)}
\edef\p{\pgfmathresult}
\fitnode{\x+9}{\y}{\p}
}
}
\foreach \y in {0,2,...,24} {
\pgfmathparse{int(25-\y)}
\edef\p{\pgfmathresult}
\pgfmathparse{int(\p+1)}
\edef\q{\pgfmathresult}
\node at (-0.3,\y/2) [pnode] {\p \nodepart{lower} \q};
}
\node at (0,13) [pnode] {27 \nodepart{lower} 28};
\node at (1,13) [pnode] {45 \nodepart{lower} 46};
\node at (2,13) [pnode] {63 \nodepart{lower} 64};
\node at (3,13) [pnode] {81 \nodepart{lower} 82};
\node at (4,13) [pnode] {99 \nodepart{lower} 100};
\node at (0,-1) [pnode] {42,43 \nodepart{lower} 44};
\node at (1,-1) [pnode] {60,61 \nodepart{lower} 62};
\node at (2,-1) [pnode] {78,79 \nodepart{lower} 80};
\node at (3,-1) [pnode] {96,97 \nodepart{lower} 98};
\node at (4,-1) [pnode] {114,115 \nodepart{lower} 116};
\node at (4.3,0.8) [pnode] {\nodepart{lower} 121,122};
\node at (5,0.8) [pnode] {\nodepart{lower} 135,136};
\node at (6,0.8) [pnode] {\nodepart{lower} 149,150};
\node at (7,0.8) [pnode] {\nodepart{lower} 163,164};
\node at (8,0.8) [pnode] {\nodepart{lower} 190,191};
\foreach \y in {0,2,4,6,8} {
\pgfmathparse{int(177-\y)}
\edef\p{\pgfmathresult}
\pgfmathparse{int(\p+1)}
\edef\q{\pgfmathresult}
\node at (7.5,\y/2+5) [pnode] {\p \nodepart{lower} \q};
}
\foreach \y in {12,14} {
\pgfmathparse{int(179-\y)}
\edef\p{\pgfmathresult}
\pgfmathparse{int(\p+1)}
\edef\q{\pgfmathresult}
\node at (7.5,\y/2+5) [pnode] {\p \nodepart{lower} \q};
}
\node at (4.2,3.9) [pnode] {\nodepart{lower} 119,120};
\node at (4.2,8.1) [pnode] {117,118};
\end{tikzpicture}
\caption{Positions of nodes inside the Lille testbed}
\label{fig:testbed}
\end{figure}
\subsection{Radio Distances and RSSI}
\label{subsec:rssi}
Another important consideration when selecting the number of nodes has been the
distance between the nodes. When performing preliminary testing on the formation
of the network, it has been observed that the network quickly broke down after a
larger number of nodes had been started. By default, the \ac{RX} threshold and
the \ac{TX} power of each nodes radio transceiver are configured to such values
that all nodes are within radio distance of each other. When the network starts
up, each node attempts to announce its presence to its neighbors using
\ac{ICMPv6} messages. With the selected number of nodes this causes a sufficient
number of collisions for the back-off procedure of \emph{ContikiMAC} to fail and
thus no messages can be transmitted successfully.
For such a problem, multiple resolutions can be thought of including increasing
the distance between the nodes, reducing the number of nodes and reducing
\ac{TX} power and increasing the \ac{RX} threshold. Since the positions
of the nodes are fixed and the area of the test lab is limited, increasing the
distance between the nodes is not an option. Reducing the number of nodes would
decrease the size of the resulting routing topology, which also is not
desirable. In this case, it has been sufficient to follow the recommended
method\footnote{\url{https://github.com/iot-lab/iot-lab/wiki/Limit-nodes-connectivity}}
for controlling node connectivity and to reduce the transmission gain from 0 dBm
to -3 dBm and increase the sense threshold from -101 dBm to -60 dBm.
\subsection{Maintenance Status of Nodes}
The status of all nodes inside the test lab can be viewed using the \ac{API} of
\fitlab. When observing the set of available nodes, a significant amount of
nodes was not available for experimentation and marked as \emph{down}, which
amounted for about half of all nodes.
\section{Accessing to the Testbed}
\fitlab offers programmable interfaces for setting up and controlling
experiments, and obtaining the results. These interfaces are accessible over the
internet using either the \ac{REST}-\ac{API}. Measurement results can be
obtained through \ac{SSH} from a server that is located at the site. The
different interfaces are depicted in \autoref{fig:access}.
\begin{figure}
\centering
\usetikzlibrary{fit}
\begin{tikzpicture}
\node (U) at (0,0) [shape=circle,draw,fill=tubsLightGreen20] {User};
\node (A) at (3,0) [fill=tubsLightOrange20,shape=rounded rectangle,draw] {API};
\node (S) at (6,0) [fill=tubsLightOrange20,shape=rectangle,draw] {Site Server};
\path (U) edge [arrows=<->,auto,swap] node {REST} (A);
\path (U) edge [arrows=<->,bend left] node [auto,swap] {SSH} (S);
\path (A) edge [arrows=<->] (S);
\node (n1) at (8.5,-1) [fill=tubsLightBlue20,shape=ellipse,draw] {HN};
\node (n2) at (8.5,0) [fill=tubsLightBlue20,shape=ellipse,draw] {HN};
\node (n3) at (8.5,1) [fill=tubsLightBlue20,shape=ellipse,draw] {HN};
\foreach \n in {n1,n2,n3} \path (\n) edge [arrows=<->,auto,swap] (S);
\path (A) edge [arrows=<->] (S);
\begin{pgfonlayer}{background}
\node [label=above:Intranet,fill opacity=0.2,shape=rounded rectangle,fill=tubsLightViolet80,fit=(n1)(n2)(n3)(S)] {};
\node [label=below left:Internet,fill opacity=0.2,shape=rounded rectangle,fill=tubsLightBlue80,fit=(U)(A)(S)] {};
\end{pgfonlayer}
\end{tikzpicture}
\caption{Accessing the testbed}
\label{fig:access}
\end{figure}
\subsection{REST API}
The \ac{REST} \ac{API} is provided by an \ac{HTTP} server that and can access
all site servers and as such can send commands to and query all \ac{HN} at
each side. This section describes methods of \ac{API} that have been used in the
experiments.
The \ac{API} for controlling experiments supports the creation and deletion of
experiments. All previous experiments can be queried for a description of their
settings and resources. Also, the state of each experiment can be monitored.
Each configuration of an experiment includes a unique number by which the
experiment will be identified, a list of resources (e.g. firmwares) and nodes.
Each experiment also includes an association of each node with a firmware file
and a profile.
Profiles are managed independently of experiments, although for each experiment a
different profile can be selected. Profiles describe how the \ac{HN} of a node
will be configured during the experiment. These settings include the whether the
node will be powered from battery of from an external power supply, the settings
for the current measurement unit, and the settings for monitoring the radio of
the \ac{CN}.
New firmware files can be uploaded through the \ac{API} and flashed to either a
selection of nodes or all nodes associated with the experiment. This way it is
possible to assign different firmwares for the \ac{DAG} root and all other
nodes.
\subsection{Site Server}
At each site, a central server takes care of coordinating all nodes
participating in an experiment. It is accessed by the \ac{API} for executing the
functions it exposes through the its \ac{REST} interface. Besides through the
\ac{API}, the site server can also be accessed directly using \ac{SSH}. Both the
server and each \ac{HN} are part of the same \emph{Ethernet} network and
communicate using \ac{TCP}/\ac{IP}.
Measurement data is periodically collected from the different \ac{HN} and stored
inside the home directory of the user running the associated experiment. This
data can then be transferred or examined by the user by executing commands on
the server.