# Bluetooth Low Power Modes Applied to the Data Transportation Network in Home Automation Systems
## 5 Discussion of the Results  
This paper analyzes the latency in multi-hop networks with Bluetooth standard, so the time that the ping type data packet takes from source to destination node, as well as the time that the pingback data packet does, were measured. The amount of intermediate nodes in the network, and hence the amount of hops, was changed. In addition, several periods of inactivity (from 0.1 to 2 s) of two Bluetooth low power link policies were considered (park and sniff). An average of 320 samples per situation under test was considered in the park mode, and 270 samples per situation in sniff. Several data tables with the results of the tests are available to analyze the latency in Bluetooth multi-hop networks. Table 1 summarizes the results of the latency tests vs. amount of hops for the master-to-slave communication (\(\delta_{\text{PING}}\)) when links in the network are always in the park mode, as well as the results when the communication is from slave to master (\(\delta_{\text{PINGBACK}}\)). Four inactivity intervals (T\({}_{\text{PARK}}\)) are considered, namely 0.1, 0.5, 1 and 2 s. The table includes the values properly identified from the results of the tests. A monotonically increase of the latency when the amount of hops is increased can be seen in Table 1. Moreover, as expected, the results of latency when the nodes are operating in the park mode show higher values in the pingback case (i.e., data packets going from slave to master) when compared to the ping case (i.e., data packets going from master to slave). In addition, the latency from end-to-end in Bluetooth multi-hop wireless communications when links are always in the park mode exhibits linear dependence with the inactivity period of the nodes. \begin{table}
\begin{tabular}{c c c c} \hline \hline
**N** & **T\({}_{\text{PARK}}\)** & \(\delta_{\text{PING}}\) & \(\delta_{\text{PINGBACK}}\) \\ \hline
0 & 2 & 0.20 & 0.30 \\
1 & 2 & - & 1.10 \\
2 & 2 & 1.50 & - \\
3 & 2 & 2.65 & 2.70 \\
4 & 2 & 3.70 & 3.70 \\
5 & 2 & 4.50 & 4.70 \\
6 & 2 & 5.40 & - \\
0 & 1 & 0.20 & 0.30 \\
1 & 1 & - & 1.10 \\
2 & 1 & 1.50 & 1.95 \\
3 & 1 & 2.30 & 2.70 \\
4 & 1 & 3.00 & 3.30 \\
5 & 1 & 3.60 & 4.20 \\
6 & 1 & 4.30 & - \\
7 & 1 & 4.90 & - \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Latency vs. amount of hops (links always in the park mode). Inactivity interval (T\({}_{\text{PARK}}\)) ranges from 2 s to 0.1 s.  
On the other hand, Table 2 summarizes the results of the latency tests vs. amount of hops for the master-to-slave communication when links in the network are always in the sniff mode, as well as the results when the communication is from slave to master. As in the park mode, four cases of inactivity intervals were considered, namely 0.1, 0.5, 1 and 2 s. \begin{table}
\begin{tabular}{c c c c} \hline
**N** & **T\({}_{\text{SNRIF}}\)** & \(\delta\)**ping** & \(\delta\)**pingback** \\ \hline  
60 & 0.70 \\ \hline \end{tabular}
\end{table} 
Table 2: Latency vs. amount of hops (links always in the sniff mode). Inactivity interval (T\({}_{\text{SNIFF}}\)) ranges from 2 s to 0.1 s. \begin{table}
\begin{tabular}{c c c c} \hline
**N** & **T\({}_{\text{PARK}}\)** & \(\delta\)**ping** & \(\delta\)**pingback** \\ \hline
0 & 0.5 & 0.20 & - \\
1 & 0.5 & - & 0.60 \\
2 & 0.5 & - & 0.90 \\
3 & 0.5 & - & 1.20 \\
4 & 0.5 & 1.90 & 1.60 \\
5 & 0.5 & 2.40 & 2.20 \\
6 & 0.5 & 2.90 & 2.50 \\
7 & 0.5 & 3.40 & - \\
0 & 0.1 & 0.20 & 0.20 \\
1 & 0.1 & 0.40 & 0.50 \\
2 & 0.1 & - & 1.20 \\
4 & 0.1 & - & 1.50 \\
5 & 0.1 & 1.50 & - \\
6 & 0.1 & 1.70 & - \\
7 & 0.1 & 1.90 & - \\
8 & 0.1 & 2.10 & - \\
9 & 0.1 & 2.40 & - \\ \hline \end{tabular}
\end{table} 
Table 1: _Cont._Table 2 shows that the latency with ping data-packets when links are in the sniff mode is very close to the latency with pingback data-packets, i.e., there is no major difference between these two latencies. The reason is that the sniff mode can be exited by either the master or the slave sending a specific request command so that the requested device replies with the according acceptance command.