## 6 Results and Discussion
### Comparison with the Application's QoS Requirements
#### 6.2.1 Metric Calculation Rate (MCR)  
In this section, we investigate the impact of the MCR value considering various scenarios. It should be noted that the low values of MCR could speed up ensuring the application's QoS requirements. This, however, results in a large control overhead. High values of MCR, conversely, may postpone ensuring the application's QoS requirements, because the AA approach needs more time to discover the unsatisfied application. However, this reduces the control overhead. Figure 9 depicts the data delivery rate for up to four applications, considering four different scenarios. For the case of a single application (Figure 9a), the delivery rate's requirement is ensured for most of the considered scenarios and the number of nodes, except the case of Scen 4. This occurs since the MCR value is relatively high, and the metrics are calculated every 8 min during the run-time. Concerning two applications, Figure 9b shows that the first application is always satisfied for most of the considered scenarios. However, for the network size of 225 nodes, the obtained delivery rate values are a little lower than the requirement for all the considered scenarios. The second application presents a delivery rate value not lower than 90% for most cases, although the second application does not have a delivery rate requirement. This is justified by the delay requirement of the second application, which induces the AA approach to be active. This, in turn, improves the delivery rate. Figure 9c depicts the case of three applications. The delivery rate requirement of the first application of all scenarios and for up to 100 nodes is always satisfied. For a higher number of nodes, the delivery rate is a little lower than the requirement for the rest of the cases. This is justified by the probability of packet drop resulting from the high traffic of \begin{table}
\begin{tabular}{l l l} \hline \hline \multicolumn{1}{c}{**Evaluation Metric**} & \multicolumn{2}{c}{AA Vs ATI} \\ \hline \multirow{4}{*}{Data delivery rate} & ✓ & AA outperformed \\ \cline{2-3}  & & Similar \\ \cline{2-3}  & & ATI outperformed \\ \hline \multirow{4}{*}{Data delay} & ✓ & AA outperformed \\ \cline{2-3}  & & Similar \\ \cline{2-3}  & & ATI outperformed \\ \hline \multirow{4}{*}{Control overhead} & & AA outperformed \\ \cline{2-3}  & & Similar \\ \cline{2-3}  & ✓ & ATI outperformed \\ \hline \multirow{4}{*}{Energy consumption} & & AA outperformed \\ \cline{2-3}  & & AMT outperformed \\ \hline \multirow{4}{*}{Control delivery rate} & & AA outperformed \\ \cline{2-3}  & ✓ & Similar \\ \cline{2-3}  & & ATI outperformed \\ \hline \multirow{4}{*}{Control delay} & & AA outperformed \\ \cline{2-3}  & ✓ & Similar \\ \cline{2-3}  & & ATI outperformed \\ \hline \hline \end{tabular}
\end{table} 
Table 5: AA approach versus ATI approach. the three applications. For the third application, the delivery rate requirement is satisfied for all the numbers of nodes and scenarios. This occurs since, in addition to the efficiency of the AA approach, the data traffic rate of the third application is 8 min. Therefore, the probability of a packet drop resulting from the buffer fullness is low. Concerning four applications running simultaneously as Figure 9d shows, we notice that increasing the MCR value resulted in a lower delivery rate, especially for network sizes larger than 144 nodes. For the first application, the sole scenario capable of ensuring the delivery rate requirement for all the network sizes is Scen 2, where the MCR value is 1 min. For the remaining cases, the AA approach was able to ensure the requirement for up to 144 network sizes. For the third application case, the AA approach ensured the requirement for all cases. This mainly occurs since the DTR value of the third application is low (one data message every 8 min). The fourth application presents the worst values for all scenarios since this application has no priority and is accommodated using only one timeslot.