# TSCH Multiflow Scheduling with QoS Guarantees:
## 3 Results
### End-to-End Delay and Packet Delivery Ratio  
The size of the queues in each scheduler is directly related to the end-to-end delays and the PDR, since it is the number of packets waiting to be sent. The default capacity is 8 packets, which in this case is the one used by SDN WISE-TSCH and AMUS. For Orchestra and MSF a capacity of 64 packets is used. This queue capacity reduces the memory available to each node, therefore, schedulers that require less memory usage are more efficient. Figure 4, shows the end-to-end delay for the first 500 packets where there is already a stable operation that allows us to clearly observe the behaviour of each scheduler. Because the centralised schedulers achieve in all cases a lower end-to-end delay, a different scale has been used in Figure 4a,b,e,f,i,j which allows the differences between these schedulers to be observed. \begin{table}
\begin{tabular}{c c c} \hline \hline
**Parameter** & **Value** & **Units** \\ \hline Radio Medium & MRM (\(n=2.04\), \(\sigma=6.7\)) & \\ \hline Timeslot & 10 & ms \\ \hline \# Channels & 4 & channels \\ \hline EB Period & 16 & s \\ \hline Slotframe Length & 7 & timeslots \\ \hline \# Packets & 500 & packets \\ \hline Packet Period & 70, 140, 500 & ms \\ \hline Packet Payload & 110 & Bytes \\ \hline Max retransmissions & 10 & retransmissions \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Simulation parameters. The transmissions of each flow are performed independently, from the source at node 9, to the sink at node 1, for the four types of schedulers. In Figure 4a-d, a packet is sent every 70 ms. The centralised schedulers, such as SDN WISE-TSCH and AMUS, achieve the lowest delay, 50 ms for SDN WISE-TSCH and for AMUS a variation between 50 ms and 120 ms. The AMUS changes are due to the control traffic that accumulates in the same queue as the data flow, and in this case the queue is never more than 2 packets. However, with Orchestra there is an average delay of 2300 ms, due to the fact, that by default, Orchestra only allocates one unicast transmission slot in each slotframe. Therefore, this sending period (70 ms) is the maximum that Orchestra can have with a slotframe length of 7 timeslots. Because it must also send RPL control packets, there is an accumulation of packets in the queues, which is observed as a progressive rise from the 100 th packet. In this case the queues reach a size of up to 40 packets, which causes an increase in the end-to-end delays. The most critical case is that of the MSF, which has the same drawback as Orchestra: 1 transmission slot per slotframe. In addition, at the beginning of transmissions, a timeslot shared with other nodes is used, which causes collisions. As retransmissions are enabled, the number of packets in queue grows faster than in Orchestra, as colliding packets accumulate, resulting in long delays and a large number of (network) losses. Increasing the sending period to 140 ms results in the graphs Figure 4e,f, which shows that for the centralised schedulers there is no variation and the 50 ms for SDN WISE-TSCH and the 50 ms to 120 ms for AMUS are still maintained. In Figure 4g for Orchestra, a more stable behaviour is observed because there are fewer packets in queue, as seen in Figure 4h, where a clear improvement in packet loss and end-to-end delay is observed, since a higher available bandwidth allows unicast cells with the other nodes to be negotiated with the other nodes. For a 500 ms period, there are no significant changes in the centralised schedulers Figure 4i SDN and Figure 4j AMUS. Orchestra in Figure 4k improves due to fewer packets in queue and its average end-to-end delay is 330 ms. In Figure 4l MSF has no more losses and the average delay of 230 ms is lower than Orchestra's, since with a less saturated network the shared slots have a lower probability of collisions and allow traffic to be sent from the unicast queues. Figure 4: End-to-End Delay for different transmission periods.