# DYNASTI--Dynamic Multiple RPL Instances for Multiple IoT Applications in Smart City
## 3 Related Work
In this sense, if the value of \(alpha\) is prioritized, the metric chooses routes through link quality and delay information. On the other hand, if \(beta\) is the priority, then the metric behaves considering node battery levels. However, communication on the network occurs in an orderly manner, i.e., each application is associated with a single instance on a static basis and employs a kind of queue for transmission: the first application in the queue transmits all its application messages and goes to the end of the queue, turning to the next application. RPL control messages do not follow this rule, all instances continue to send these control messages freely. This procedure occurs throughout the network's lifetime, statically and without any interruption of instance control messages that are not transmitting messages. Thus, this approach can lead to unnecessary overhead as application messages are transmitted alternately. However, the solutions presented by the authors support differentiation service for applications with different requirements through the association of routing metrics and instances. The solution does not support sporadic applications that appear on the network eventually with critical low delay or high reliability requirements in lost packets. It is important to stress out that the support for sporadic applications could enable them to send messages on the network more quickly, and there is no need to wait for other applications to terminate their transmissions by following the transmission queue order. Therefore, the approach in [21; 22] does not allow regular and sporadic instances to coexist by sharing network resources differently. Table 1 provides a comparison between DYNASTI and the related work addressing the use of multiple instances and the RPL routing protocol. The comparison is made through the following fields:  
* Metric: Which metrics were used to generate the results. * Number of instances per application: Number of instances per application. * Service differentiation for applications: Modified instance settings, for instance routing metric, to prioritize applications. * Traffic Pattern: Existence of sending messages in different patterns. Approaches of multiple instances by [21; 22; 23; 24; 25; 26] have some limitations. These approaches employ only one instance per application and there is no instance management, which results in static instances. An application is associated, for example, with a single routing metric and a single interval between application messages at all times. In addition, implementations do not support sporadic applications that send occasional messages. Importantly, RPL control messages and application messages are generated and sent at intervals \begin{table}
\begin{tabular}{c c c c c} \hline \hline
**Approach** & **Metric** & \
\begin{tabular}{c} **Number of** \\ **Instances per** \\ **Application** \\ \end{tabular} &
\begin{tabular}{c} **Differentiation of** \\ **Services for** \\ **Applications** \\ \end{tabular} & **Traffic Pattern** \\ \hline [PERSON] et al. [23] & ETX & 1 & No & Regular \\ [PERSON] et al. [24] & ETX e HC & 1 & No & Regular \\ [PERSON] et al. [25] & ETX e HC & 1 & No & Regular \\ [PERSON] et al. [26] & ETX, PDR e HC & 1 & Yes & Regular \\ [PERSON] et al. [21; 22] & _mOFQS_ & 1 & Yes & Regular \\ DYNASTI & _Multiple Metrics_ & multiple & Yes & Regular and Sporadic \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Comparison between the related work against our proposal. throughout the lifetime of the network. Thus, the above approaches do not reflect a network with different traffic patterns.