# DYNASTI--Dynamic Multiple RPL Instances for Multiple IoT Applications in Smart City
## 4 DYNAATIC Multiple RPL Instances for Multiple IoT ApplicatIons (DYNASTI)
### Dissemination and Storing Information of RPL Instance Scheduling  
After the instances are scheduled due to the detection of a sporadic application, the status of the scheduled instances must be updated in the local database of the sensor node that detected the event. The next step is to disseminate these status updates across the network. This information must be propagated to the other nodes of the network so that they can change the instances information. This spread of information scheduling depends on the _sink_ node, as the other nodes have a restricted view of the network in RPL. When a node's scheduler detects the need for update, it uses DAO messages to update the _sink_, informing what the new status of each instance is. Upon receiving the DAO message, _sink_ employs the DIO messages to disseminate the status of the instances to the entire network.  
DYNASTI defines three types of status for the instances, two of which were previously described as transmission (enabled) and interruption of sending (disabled) instance data, and the third type that is used in the network initialization phase. Each type of status controls the sending of application and control messages required for each phase, as listed below:  
* _Status_ 1: Instance communicates only control messages.
* _Status_ 2: Instance communicates both control and application messages.
* _Status_ 3: Instance is deactivated, it does not communicate control or application messages.  
The state diagram is presented in Figure 5 for sporadic and regular applications demonstrating the status transition. At first, the instance enters in _status_ 1 during the network boot period (_bootstrap_) for all predefined instances. The initialization phase aims to create the DODAGs for each instance, assembling the network graph.  
Figure 5: State diagram for instances status.  
Then, the instance is changed to _status_ 2, if a sporadic or regular application is started and associated with an instance, when the nodes communicate control and application messages. After, if there is an interruption of the instance due to the emerging of another sporadic application or, if the sporadic application has stopped running, the instance is changed to _status_ 3 and remains in this status until it is selected by the Scheduler and returns to _status_ 2. Alternatively, instances that have not yet been scheduled can do the transition from _status_ 1 to _status_ 3.  
The sequence diagram is presented in Figure 6 with the functions that are responsible for disseminating the status of the instances and thus allowing flexible management of the instances. In the initial phase, a network initialization period (_bootstrap_) is performed. This period is required to share instance information between the _sink_ and the sensor nodes on the network.  
The closed loop (_loop_) is initiated in step 1, identifying the emergence of the sporadic application and scheduling the instances, including the sporadic application instance. Step 2 changes the _status_ of the instances in the database of the sensor node that detected the event. In other words, the instances will be changed to _status_ 2 (activated) or _status_ 3 (deactivated). In step 3, it is sent the activated and deactivated _status_ of the sensor node instances to the _sink_, through the DAO control message, disseminating information about the new scheduling of instances. Step 4 updates the database in _sink_'s memory, where the scheduling of the instances actually takes effect. These updates will be included in a DIO message in the next step (step 5), which is the transmission of the DIO message to synchronize all sensor nodes with the instances' _status_ changes and, consequently, the completion of the procedure of scheduling of the instances. Thus, the database of all sensor nodes and the _sink_ are synchronized. Closing step 5 returns to step 1 to identify whether other sporadic applications have appeared or closed, and to carry out further scheduling.