# DYNASTI--Dynamic Multiple RPL Instances for Multiple IoT Applications in Smart City
## 5 Performance Evaluation and Results
### Results
#### 5.5.3 Varying the Application Message Send Intervals
Table 7 shows scheduling for the _No Variation_ approach using one message per node in every five minutes as the application message send interval. Only application 1 (electric current monitoring) is active in scheduling 11 and 12. Both applications are active in scheduling 12. Figure 11(a) presents the achieved results in the average total control messages for _Adaptive Interval_ and _No Variation_ approaches. The average of sum of the total control messages (DIO and DAO) in all simulations was used to calculate the results. There was a slight difference between the two interval variations of the _Adaptive Interval_ approach. The number of control messages for the _Adaptive Interval_ approach increase, yielding about 11.49% more control messages than the _No Variation_ approach. This behavior is due to a couple of reasons--first, the fact that, in _Adaptive Interval_ approach, there are three instances, while, in the _No Variation_ approach, there are only two instances. Second, it is important to note that the management of control messages for instances 10 and 30 of the same regular application are effected by changing the _status_ of these instances, and these _status_ need to be propagated on the network. Therefore, the scheduling change does not occur immediately on all nodes and, consequently, the control messages from both instances are being transmitted for a period of time. Still, the increase of the number of control messages (about 11.49%) was not proportional to the number of instances in the network (33.3%) due to the more optimized management provided by DYNASTI. Figure 11(b) is used to compare results between sent and received application message averages. The _Adaptive Interval_ approach sends and receives more application messages than _No Variation_ approach for both variations; the variation of 7 min sends more 6.7% and receives more 9.87% and the variation of 15 min sends more 3.14% and receives more 6.10% than a _No Variation_ approach. The slight and higher number of application messages sent and received is justified by the same reason as the increase in the control messages, i.e., due to the time taken for the RPL control messages to propagate and to stop instance 10 when the sporadic application arises. In addition, while the variations of _Adaptive Interval_ approach result in 2666 and 2585 lost messages for the 7 min and 15-minute intervals, respectively, the _No Variation_ approach results in 2644 lost messages. These results show that the \begin{table}
\begin{tabular}{c c c c c c} \hline \hline
**Application** & **Instance** & \begin{tabular}{c} **Traffic** \\ **Pattern** \\ \end{tabular} & \begin{tabular}{c} **Traffic** \\ **Type** \\ \end{tabular} & \
\begin{tabular}{c} **Messages** \\ **Interval** \\ \end{tabular} &
\begin{tabular}{c} **Scheduling** \\ \end{tabular} \\ \hline
1 & 10 & Regular & Normal & 5 & 11, 12 \\
2 & 20 & Sporadic & Critical & 3 & 12 \\ \hline \hline \end{tabular}
\end{table} 
Table 7: Scheduling for DYNASTI for the _No Variation_ approach. Figure 12: The average number of control messages and sent and received application messages. smallest number of lost messages was achieved when using the greatest application message interval (15 min), which may be justified by freeing resources from the regular application instance that employs this greater interval, favoring messages of the critical application though a smaller loss. Hence, it is worth noting that the 15-minute variation lost fewer messages and could provide more QoS for your critical application; thus, critical application receives more packets and generally loses fewer application messages than the _Adaptive Interval_ approach with a 7-minute variation and the _No Variation_ approach. A comparison is carried out between the average delay for _Adaptive Interval_ and _No Variation_ approaches, as it is shown in Figure 12(a). In this case, only messages successfully received in sink are considered.