## 3 Design, Implementation and Test of the DXN Engine
### DXN Tests Scenarios and Experiments
#### 3.4.3 Nodes Transmission Scheduling Optimisation Algorithm  
To enhance the communication of any IoT network further is to make all its SNs work in a synchronised schedule. DXN is designed to achieve this by including synchronisation data in the downlink messages from the host server to all the SNs. Effectively, DXN is overriding the duty cycle restriction in LoRaWAN networks (implemented on the 868 MHz band). This way, no \"intelligent SNs\" are needed.  
DXN set up \"continuously updated timers\" that will be included at each rescue message to be used by the SNs to schedule their waking up and sleeping behaviour as follows. DXN will decide on the rescue message intervals in an optimum way by balancing between increasing the interval for as long as possible and ensure the minimum wake-up time by the ENs. MNs will repeat sending the rescue message to all blocked nodes it is serving (meaning, when an EN replies to a rescue message and failed to receive an Ack, it will try again after this timer is finished. DXN predicts this timer based on analysing the  
Figure 8: Tx interval adjustment for messages by DXN.  
\begin{table}
\begin{tabular}{c c c c c c} \hline \hline \multirow{2}{*}{**Group9**} & \multirow{2}{*}{**Nodes**} & \multicolumn{2}{c}{**Tx Interval**} & \multirow{2}{*}{**MN Score**} & \multicolumn{2}{c}{**New Tx Interval**} & \multirow{2}{*}{**New MN Score**} \\  & & **(Hours)** & & & **(Hours)** & **Score** \\ \hline \multirow{3}{*}{Group1} & MN1 & 12 & & & & \\ \cline{2-6}  & EN1 & 3 & & & & \\ \cline{2-6}  & EN2 & 10 & & & & \\ \hline \multirow{3}{*}{Group2} & MN2 & 6 & & & & \\ \cline{2-6}  & EN3 & 11 & & & & \\ \cline{2-6}  & EN4 & 5 & & & & \\ \cline{2-6}  & EN5 & 4 & & & & \\ \hline \hline \end{tabular}
\end{table}
Table 3: Tx interval adjustment by DXN.  
communication information). This is to overcome the duty cycle limitations (predicting when the channel will be available again).  
The scenario in Figure 5 is also used to test this scheduling mechanism. To ensure successful communication between the SNs in each group, MNs were set to a five-minute rescue message interval. The GW Ack message will include this timer which will keep being updated by DXN and the new rescue message repeat timer. ENs, on the other hand, at the first cycle, was set to the maximum timer (5 min) to ensure the reception of the rescue message. Once they receive a rescue message and their packet is acknowledged by the GW, the Ack will include the new rescue message interval as per the previous step. Further, on the following cycles, each EN will report its waiting time, and DXN will ensure the minimum waiting time while maintaining a successful connection. The goal is to reduce the waiting time of EN to the minimum, and so for this test, we chose the waiting time for each EN to be 30 s (the time from waking up until receiving the rescue message is 30 s). To ensure a successful packet delivery, the change is set to be gradual rather than immediate. Figure 9 details the waiting time at each of the two groups in Figure 5. Note that group1 and group2 were set to 3 h and 4 h uplink intervals, respectively. In this case, DXN changes group2 timers more gradually than group1 since each node in group2 has more sleeping time, leading to a higher chance of miscommunicating.  
As shown in the figure above, after around 10 cycles of scheduling by DXN, the ENs in each group were settled on the waiting time goal of around 30-40 s based on the groups' Tx interval, with a staggering reduction of around 86% in group2 and 90% in group1, compared to the first cycle with the initial rescue message interval of 5 min.