## 2 Literature Review  
The current expansion of the IoT SN devices and the communication technologies to support them necessitates the emergence of more scalable IoT networks. Current IoT networks/applications are limited because the \"things\"/SN devices have to be low-power and cheap. Moreover, the LPWAN technologies suffer from a limited data bandwidth due to duty cycle restrictions. Furthermore, most IoT networks are deployed as a star network (in a one-way communication). This is limiting, in that they lack the feedback mechanism that is used for application data purposes and can be used for enhancing the networking QoS. We found that the literature contains attempts of researchers in LPWAN to improve IoT networks by inserting relay/repeater nodes in the network to improve their connectivity. Much of the literature focuses on the limitations of the LPWAN in general and LoRaWAN in particular. When in some deployment scenarios, certain SNs fall out of the GW's reach due to reasons such as communication range and/or signal blockage due to obstacles or interference. The following is of a subset of the papers that we reviewed which have contributed to the design of our DXN solution. Utilising the communication between the SNs and the host server was addressed by proposing a clustering technique for Machine-to-Machine (M2M) devices in an IoT network [5]. The technique was based on forming the clusters and selecting the Cluster Heads (CH) based on three factors: the node's energy availability, interest ties (the relation strength between the M2M devices), and physical ties (the physical proximity and the communication link quality of the M2M devices). Once the cluster and the CH are formed and selected, these factors and sensor readings will be transmitted to the network host server via the CH. The host server (User) can use this information to make new decisions if necessary. This idea is similar to our DXN solution in the sense of creating a two-way relationship between the network and the host server where the collected information can be used to generate feedback to the network. Proposing a relay mechanism is not something new; many proposals [6] have suggested using special devices such as repeaters (mostly are mains powered) in a fixed architecture deployment scenario. Others suggest deploying extra GWs. This makes it challenging to implement such solutions efficiently using regular LoRa SNs (small battery-powered expected to last for many years). Because these SNs have limited resources, there is no synchronisation between them, and they are sending/receiving at different times using different channels that are selected randomly. However, there was an attempt to facilitate a regular relay node dedicated to helping other SNs (end SNs) that are struggling to reach the GW [7]. These relay SNs are responsible for synchronising and forwarding messages from end SNs when they fail to reach the GW directly. To achieve this, two channels will be defined for every SN in the network. The relay SNs will be scanning these two channels every 500 ms separately. Before an end SN sends its packet, it will send a \"wake-up sequence\" (WS) message transmitted in an implicit header mode (no PHY header to minimise the overhead) on one of these channels. The WS message includes the randomly selected channel and data rate that the end SN will be using for the upcoming packet transmission, plus the time of the transmission. Once this WS message is received by a relay node, it can go back to sleep mode and later wakes up to the right channel/data rate just before the arrival of the end SN packet. When that packet arrives, the relay SN will acknowledge it first and then will encapsulate and forward it to the GW. The end SN will go back to sleep mode as well and open a receive window after 17 s to receive the acknowledgement (Ack) from the GW through the relay SN. The authors claim that the relay SN's Ack message will include timing correction information to sync the end SN clock.