# Bluetooth Low Energy Mesh Networks: A Survey
## 4 BLE Mesh Networks: Academic Solutions
### Flooding-Based Solutions  
We next examine two different academic solutions that are based on flooding to allow end-to-end data transmission in a BLE mesh network [9; 10]. Note that several proprietary solutions also use flooding as the fundamental principle (see Section 5.1, Section 5.5, Section 5.7, Section 5.8, and Section 5.10). A first flooding-based BLE mesh network proposal is provided in [9]. The authors studied how Packet Delivery Ratio (PDR) and latency can be bounded, while keeping energy consumption low. To this end, the authors devised a mechanism over Bluetooth 4.0 based on the Trickle algorithm [40]. Their approach follows gossiping [41], whereby traffic is propagated based on a given probability. This probability is determined by a node as a function that decreases with the node's number of neighbors. In addition, the Trickle algorithm operates based on its own parameters to further filter the decision to rebroadcast traffic. The authors measured the current consumption of BLE nodes, as well as end-to-end packet latency. On the other hand, a bounded flooding mechanism for BLE mesh networking, called BLEmesh, is presented in [10]. Bounded flooding limits rebroadcasting in intermediate nodes by only allowing a subset of these to participate in broadcasting operations. In BLEmesh, packets carrying data from a specific sender-destination couple are aggregated in batches. Data, together with control fields, which are used to decide which nodes will participate as broadcasters, are carried in the payload of advertisements. The control fields include two lists, namely, the Forwarder List and the Batch Map. \begin{table}
\begin{tabular}{c c c c} \hline \hline \multirow{2}{*}{**Proposal**} & \multirow{2}{*}{**Multi-Hop Paradigm**} & \multirow{2}{*}{**Evaluation Platform**} & \multicolumn{2}{c}{**Performance**} \\ \cline{3-4}  & & & **Metrics** & **Results/Conclusion** \\ \hline
[9] & Trickle + gossiping & \
\begin{tabular}{c} nRF51822 SoC based \\ on ARM Cortex M0 \\ \end{tabular} &
\begin{tabular}{c} Latency \\ \end{tabular} & 20 s (3 hops) \\ \hline
[10] & Bounded flooding & TI CC2540 & Packet overhead &
\begin{tabular}{c} 16 packets (BLEmesh), 25 packets (source \\ routing), 96 packets (flooding) Note: packet \\ transmission over 5 hops \\ \end{tabular} \\ \hline
[11] & Tree-based routing & \begin{tabular}{c} TI CC2540, \\ SMARTF05 EB \\ \end{tabular} & \
\begin{tabular}{c} Latency \\ \end{tabular} &
\begin{tabular}{c} 1.0 s (1 hop), 1.3 s (2 hops), 2.1 s (3 hops) \\ \end{tabular} \\ \hline
[12] & Static routing & \
\begin{tabular}{c} X-NUCLEO-IDB05A1 \\ (STM) \\ \end{tabular} & Latency &
\begin{tabular}{c} 202 days (peripheral), 60 days (central with \\ 3 connected peripherals) \\ \end{tabular} \\ \hline
[13] & On-demand routing & TI CC2540 & Latency &
\begin{tabular}{c} 25 s (first packet), 0.79 s (rest of packets) \\ Note: 22-byte packet over 3 hops \\ \end{tabular} \\ \hline
[14; 15] & DAG-based routing & Smartphone & Latency &
\begin{tabular}{c} 20.9 s (2 hops), 2.90 s (3 hops), 3.54 s \\ (4 hops), 4.00 s (5 hops) \\ \end{tabular} \\ \hline
[16] & On-demand routing & \begin{tabular}{c} Broadcom BCM434x \\ (if Phone 6) \\ \end{tabular} & \
\begin{tabular}{c} Throughput \\ Latency \\ \end{tabular} &
\begin{tabular}{c} -6 kbit/s (10-node network) \\ \end{tabular} \\ \hline
[17] & Named Data &
\begin{tabular}{c} S130 Nordic, TI \\ CC2540, custom \\ prototype \\ \end{tabular} & N/A & N/A \\ \hline
[18] & DAG-based routing & \
\begin{tabular}{c} MSP430 \\ microcontroller, TI \\ CC2420, Broadcom \\ BCM4356 \\ \end{tabular} &
\begin{tabular}{c} PDR \\ (_committered_ = 200 ms) \\ \end{tabular} \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Performance reported for BLE mesh network academic solutions. The Forwarder List is a prioritized set of intermediate nodes in the path towards the destination, which is determined by the sender. The Batch Map identifies the last nodes that have broadcasted data corresponding to a specific batch.