## 4 Results
Therefore, as the multiple jumps in the cluster increase, there is also an increase in the distance of an SM to its associated UDAP. This translates into an increased time required to add and merge the data in each UDAP. In addition, in Figure 5a, it can be seen that the average delays while maintaining the capacity are similar in each increment of density of the deployed SMs. This is because these are partial averages of each cluster, which demonstrates that the heuristics is capable of building, through appropriate topologies, balanced graphs, which in turn directly contributes to decreasing technical losses in a wireless network. Therefore, the amount of required UDAPs responds to three variables in particular: Density of SMs, capacity and coverage (in terms of the technical characteristics available for the UDAP). If we verify the behavior of the metrics in Figure 5a, in the populations of 32 and 128 with capacities of 20-27 and 27-32, respectively, there is no need to implement a UDAP since the proposed algorithm searches in each capacity increment to include (if the capacity allows it) the nodes that were not included (due to the restrictions of the problem); thereby completing the clusters without the need of adding UDAPs. On the other hand, in Figure 5a, it is clear that as the SMs' density increases, the slope of the delays is stabilized. This happens because, as it has a larger number of SMs, the algorithm manages to build clusters mostly balanced in terms of the following: distances, radio coverage and number of elements for each group. Therefore, the higher the density of SMs, the better the results obtained in terms of optimization due to the closeness of the SMs. Therefore, when varying the capacities of a UDAP, the following is modified: the topology, the average number of traversed links by the package to reach its destination, the length of the cluster, the end to end delay, the link capacity and the coverage distance. \begin{table}
\begin{tabular}{c c c c c c} \hline \hline
**Scenario** & **Density of SMs** & **UDAPs** & **Delay without ODB Algorithm** & \multicolumn{2}{c}{**Delay with ODB Algorithm**} \\ \cline{2-6} \# & \(n\) & **Units** & **Average End to End (ms)** & **Average End to End (ms)** & **Reduce \%** \\ \hline
1 & 512 & 18 & 67.17 & 55.60 & 17.25 \\
2 & 256 & 11 & 53.96 & 46.73 & 14 \\
3 & 128 & 4 & 75.37 & 65.09 & 13.65 \\
4 & 64 & 2 & 82.61 & 62.88 & 23.88 \\
5 & 32 & 1 & 72.98 & 57.89 & 20.68 \\ \hline \hline \end{tabular}
\end{table} 
Table 5: \(L\) = 200 bit/packet, Lambda = 0.1 packet/s, capacity = 32. Source: the authors. In Figure 5b, significant variations in the global delay are depicted for the data aggregation as the traffic generated by each SM increases. Therefore, the higher the traffic generated, the greater the FiWi network delay. This is because the increase in delay is directly proportional to the increase in capacity. If the capacity of the UDAP increases, the greater will be the length of the cluster, and therefore, the greater will be the traffic generated in each cluster; resulting in an increase in the global end to end delays. Accordingly, the delay is directly proportional to the traffic generated by each SMs, whereas the number of UDAPs \(k\) required is inversely proportional to the capacity and coverage of the UDAP. In Figure 6, it is shown that the greater the amount of average links that a data package must go through from an SM source to a UDAP, the greater the increase in the delays of each scenario. This happens due to the following reason: if the average number of links that a data package must go through increases, this is because the package was generated by a node that is located at a greater distance than the maximum radio coverage allowed for the UDAP. That is, if a node is very distant, it increases the global delays of the wireless network. Due to this, the data package has to carry the information through jumps, supported on the SMs of transition, to bring the information to the UDAP. Each trend in Figure 6 corresponds to a different scenario.