# DYNASTI--Dynamic Multiple RPL Instances for Multiple IoT Applications in Smart City
## 4 DYNAATIC Multiple RPL Instances for Multiple IoT ApplicatIons (DYNASTI)
### Instance Scheduler  
The Instance Scheduler plays an important role in the DYNASTI solution, as it enables support for sporadic applications while offering service differentiation for applications with different configurations (traffic pattern and requirements). It also has the traffic classes of the instances associated with the applications, such as routing metrics and send interval of the application messages.  
The Scheduler has a predefined set of scheduling of active and disabled instances in order to be able to change the instances, thus to support sporadic applications and their coexistence with regular applications. The scheduling of instances happens when a sporadic application is started, forcing the instance to be activated for that application.  
Figure 4 presents a possible scheduling of instances for the scenario of the two applications. Application 1 has two colors for its timeline: the blue color depicts Instance 10 with a traffic class using, for example, the ETX routing metric and a shorter and original interval for sending application messages. The red line reflects Instance 30 of Application 1, using a greater interval for sending application messages than Instance 10 (blue). In this way, Application 1 gives Application 2 more resources.  
In this case, the scheduling defines that (i) when Application 1 is running in isolation, it will use Instance 10 and (ii) when Applications 1 and 2 are running concurrently, Application 1 will use Instance 30 and Application 2 will use Instance 20. Initially, Instance 10 is activated during the interval from 0 h to 1 h. In 1 h, Application 2 starts, causing the Scheduler to change the status of Instance 10 to deactivated as well as Instances 20 and 30 to activated. This is maintained until time 2 h when the Scheduler changes the status to activated for Instance 10 and deactivated for Instances 20 and 30, as Application 2 is interrupted. This schedule is also made in the interval of 3 h to 4 h.  
Figure 4: Example of four hours of operation of three schedules with two instances associated with the regular application and one critical application with one instance.  
It is worth remembering that the role of the Scheduler is to identify which instances should be active or not. The Message Controller component is responsible for suppressing or activating the application and control messages of the instances, disabling, or enabling them.  
Thus, when there is a demand for more critical sporadic application on the network, regular less critical applications may employ instances with less stringent traffic classes in order to free up resources for the more critical application. In addition, less critical regular applications do not need to interrupt totally the sending of application and control messages, seeking, whenever possible, to use different routes from the most critical applications based on the routing metric of the traffic class of that instance. After the most critical application ends, less critical applications that had switched instances and, consequently, traffic class, can return to their previous instances, that is, return to their previous traffic class and return to using the resources released by the more critical application.