## 4 Experimental Results and Discussion
### Experimental Results
From Table 4, the comparison between the bandwidth test of the backhaul connection and the stations that are connected to the backhaul connection at each end through two non-overlapping channels, the bandwidth was only degraded by approximately 12.5% to 24.5%. In this scenario, the communication between the two stations at each end involves two additional hops, which indicates that the performance degradation was much lower compared to that of the WDS, which degrades by approximately 50% with each additional hop. An exact comparison is not possible because the FreeBSD WMN implementation does not allow legacy stations to connect to the WMN without the help of the second channel. To determine how the usage of two non-overlapping channels helps the network performance, a second comparison was performed with the same channel for both the wireless mesh interface and the AP interface in test 2 and different channels in test 3. The result is shown in Figure 4.1 The network performance of test 2, which uses the same channel, shows instability: there is an improvement of up to 164% in the data rate when the usage of the same channels was changed to the two non-overlapping channels. With the help of the non overlapping channel, the load balancing ability of the two channels will be maximized. \begin{table}
\begin{tabular}{|c|c|c|c|} \hline \multirow{2}{*}{**Range**} & \multicolumn{3}{c|}{**Average Throughput (Mbps)**} \\ \cline{2-4}  & **MP1–MP3** & **Station 1–station 2** & **Degradation rate** \\ \hline
**15 m** & 3.116 & 2.355 & 24.43\% \\
**30 m** & 2.475 & 1.886 & 23.79\% \\
**45 m** & 2.556 & 1.945 & 23.91\% \\
**60 m** & 1.659 & 1.453 & 12.44\% \\
**75 m** & 1.978 & 1.575 & 20.25\% \\
**82.5 m** & 2.139 & 1.659 & 22.44\% \\
**90 m** & 1.870 & 1.408 & 24.72\% \\
**100 m** & 2.251 & 1.683 & 25.26\% \\ \hline \end{tabular}
\end{table} 
Table 4: A comparison between test 1 and test 3. \begin{table}
\begin{tabular}{|c|c|c|c|} \hline \multirow{2}{*}{**Range**} & \multicolumn{3}{c|}{**Average Throughput (Mbps)**} \\ \cline{2-4}  & **Same channel** & **Different channel** & **Improved rate** \\ \hline
**15 m** & 1.979 & 2.355 & 19.02\% \\
**30 m** & 1.456 & 1.886 & 29.53\% \\
**45 m** & 0.738 & 1.945 & 163.51\% \\
**60 m** & 1.274 & 1.453 & 13.98\% \\
**75 m** & 1.072 & 1.575 & 46.94\% \\
**82.5 m** & 1.141 & 1.659 & 45.43\% \\
**90 m** & 1.366 & 1.408 & 3.02\% \\
**100 m** & 1.460 & 1.683 & 15.89\% \\ \hline \end{tabular}
\end{table} 
Table 5: A comparison between test 2 and test 3. In the last test, which used dynamic routing to analyze the path chosen by the routing protocol implemented in the FreeBSD 802.11s implementation, the embedded systems were placed in a simple mesh topology in which the distance between MP1 and MP4 is approximately 60 m, and the distance between MP2 and MP3 is approximately 10 m. Two trials were performed to analyze whether the path changes over time. The routing information was obtained from each node after they were run with the established paths. This information was then visualized in diagrams, and the path chosen at each node is represented by different line types--the straight line, dotted line or the dashed line--as stated below. The value beside the line represents the metric value obtained from the test. Figure 12: The path selected at each node (Trial 1). Based the result of the first trial in the last test, as shown in Figure 12, some flaws in the metric calculation of the FreeBSD 802.11s implementation can be observed. The metric calculation does not account for the hop count because the more expensive path was chosen at MP3 and MP4. At MP3, the routing protocol actually chose to hop through MP2 to reach MP1 or MP4, even though the direct path to MP1 or MP4 might offer better network performance. The same was true for MP4, where MP4 chose to hop through MP1 to reach MP3. This phenomenon indicates that the metric calculation can be improved by considering the hop count of the path. Figure 13: The path selected at each node (Trial 2).