## 5 Method  
We adopt IT-SDN [6] as the SDWSN framework, whereby the simulations were carried out using Contiki OS [21] and a COOJA simulator [22]. Each application is represented by a set of sensor nodes that periodically send data messages to a single sink. To execute up to 4 applications with different DTR values, each sensor node periodically sends a data message to all the sinks. Hence, each sensor executes up to 4 applications simultaneously. Both the IT-SDN controller and the TSCH coordinator (which controls join and departure operations within the TSCH network) run on the same node. We consider up to 4 application types with different DTR values and network sizes of up to 225 nodes. Each experiment is repeated 10 times, and its duration is set to be 1 h. The shown simulation results are the average of these repetitions. To evaluate the AA approach, we compare it in two different strategies: (i) adopting the application traffic isolation (ATI) [16] approach as a reference case for comparison and (ii) comparing the application's QoS requirements with the obtained metrics. For all the simulation results, we show the performance for each of the considered applications in both control and data planes. It is important to define two parameters related to the AA approach: (i) metric calculation rate (MCR), which is the frequency of metric's (delivery rate and delay) calculations during the run-time, and (ii) difference rate, which is the percent of the difference between the calculated metrics and the application's QoS requirements. Table 3 shows the default simulation settings. To compare the ATI approach, which assigns a single timeslot per application, with the AA approach, we consider the case of 4 applications running simultaneously. Figure 6 depicts the simulation scenario for each approach. Figure 5: The new calculated scheduling (three-application case). Figure 6: Simulation scenarios for ATI and AA approaches. To investigate the ability of the proposed approach to ensure the application's QoS requirements, we compare the results with the application's requirements. Six different scenarios were considered for this evaluation strategy, varying both MCR and DTR values. Table 4 shows the parameters' values for these scenarios, indicating the default values with \"DV\", \begin{table}
\begin{tabular}{l l} \hline Topology & Square grid \\ \hline Distance between neighbors & 50 m \\ \hline Compiling mote & Z1 \\ \hline Radio environment & UDGM \\ \hline Simulation duration & 3600 s \\ \hline Simulation repetition & 10 times for each case \\ \hline Radio module power & 0 dB \\ \hline ContikiMAC channel check rate & 16 Hz \\ \hline IT-SDN version & 0.4.1 \\ \hline Controller re-transmission timeout & 2 s \\ \hline ND protocol & Collect-based \\ \hline CD protocol & None \\ \hline Link metric & Expected Transmission Count (ETX) \\ \hline Route recalculation threshold & 20\% \\ \hline Size of the flow table & 10 entries \\ \hline Neighbor report max frequency & 1 packet per minute \\ \hline Route calculation algorithm & Dijkstra \\ \hline Flow setup & Source routed \\ \hline Data payload size & 10 bytes \\ \hline Number of TSCH channels & 4 channels \\ \hline Timeslot length & 15 ms \\ \hline Enhanced beacon (EB) & 2 s \\ transmission rate & \\ \hline Number of nodes & 16,36,64,100,144,196,225 \\ \hline Number of applications (sinks) & 1,2,3,4 \\ \hline Data traffic rate & 1 packet per \\ \(1/4/8/10\) min \\ \hline Metric calculation rate & 180 s \\ \hline Difference rate & 20\% \\ \hline \multicolumn{2}{c}{Application’s requirements (1 st App, 2 nd App, 3 rd App, 4 th App)} \\ \hline Delivery rate & 92\%, —, 90\%, — \\ \hline Delay & 900 ms, 950 ms, —, — \\ \hline Number of nodes, & (16,73) (36,96) (64,117) (100,171) \\ convergence time (s) & (144,196) (196,233) (225,329) \\ \hline \end{tabular}
\end{table} 
Table 3: Default simulation settings.