## 6 Results and Discussion
### Comparison with the Application's QoS Requirements
#### 6.2.1 Metric Calculation Rate (MCR)
Concerning the data delay, Figure 10a shows that in the case of a single application, the delay requirement, which is 900 ms, is ensured for network sizes up to 144 nodes for all scenarios. For larger networks, the obtained delay values are a little higher than 900 ms. For a network size of 196 nodes, the delay values were 0.94 ms and 0.97 ms for Scen 1 and Scen 3, respectively. Figure 10b shows that for two applications, the delay requirement is ensured for network sizes up to 100 nodes, compared with the 144 nodes in the case of a single application. This happens because more applications mean more data messages. This increases, in turn, the time the message waits in the buffer to be processed. Concerning the second application, reducing the MCR value did not enhance the obtained values  
Figure 9: Data delivery rate, changing the MCR value. considerably. This is justified by the DTR value of the second application, which is 4 min. This, in turn, demonstrates a significant trade-off between the chosen MCR and DTR values. Concerning the case of three applications running simultaneously depicted in Figure 10c, the delay requirement of the first application is ensured for network sizes of up to 100 nodes when the MCR value varies between 1 and 4 min. However, the AA approach ensures the delay requirement only for network sizes up to 64 nodes when MCR is higher (6 and 8 min). This occurs because the higher MCR values could delay ensuring the requirement. The requirement is unsatisfied for a longer period during the run-time, which affects the final delay result. For the third application, the requirement keeps ensuring up to network sizes of 100 nodes for all scenarios, except for Seen 4, where the MCR value is 8 min. For four applications, as depicted in Figure 10d, and for the first application, the delay values are lower than 900 ms for up to 144 nodes in Seen 1 and Seen 2, and up 100 nodes in the Seen 3 and Seen 4, where the MCR values are 6 and 8 min, respectively. For the second application, the delay requirement is ensured for network sizes up to 100 nodes for all the considered scenarios, including Seen 3 and Seen 4, where the MCR values are 6 and 8 min, respectively. This is justified via the DTR value of the second application, which is 4 min. There is, thus, no difference in the number of the second application's messages every 1 or 3 min. Seen 1 and Seen 2 did not, therefore, present better delay values than Seen 3 and Seen 4. Similarly to the case of the delivery rate, the fourth application presents the worst delay values, since it is accommodated in a single timeslot and without any priority. Figure 11 shows the control overhead for up to four applications. For all network sizes and scenarios, regardless of the number of applications, the MCR value is inversely proportional to the control overhead. Seen 2, which has the lower MCR value (1 min),  
Figure 10: Data delay, changing the MCR value. presents the highest control overhead values. For three applications running and for a network size of 144 nodes, the control overhead values presented were 23,736.2 messages, 27,736.1 messages, 18,796.6 messages, and 17,296.4 messages for Scen 1, Scen 2, Scen 3, and Scen 4, respectively. This occurs since the lower MCR values mean more exchanged control messages. Concerning energy consumption, Figure 12 shows that for all cases, the energy consumption increases with the number of applications. The lower values of MCR led to more energy consumption in most cases. In the case of four applications, as in Figure 12d and for a network size of 64 nodes, the presented values were 65,281.3 mj, 68,423.7 mj, 64,079.1 mj, and 62,819.8 mj for Scen 1, Scen 2, Scen 3, and Scen 4, respectively. This occurs since lower MCR values mean more activities concerning the control messages. Figure 13 shows that for all cases, the control delivery rate is inversely proportional to the number of nodes.