# On-Demand Scheduling of Command and Responses for Low-Power Multihop Wireless Networks +
## 1 Introduction  
Emerging Internet of Things (IoT) technology is being applied to a variety of fields such as smart factory [1], smart grid AMI [2, 3], smart market [4, 5], and smart hospitals [6]. Most such IoT applications require a mechanism to control and collect data from multiple embedded devices deployed in the field of interest. For this purpose, they usually employ wireless networks to disseminate commands and receive responses, possibly over multihop [1, 2, 3, 4, 5, 6, 7, 8]. However, if a large number of nodes respond simultaneously over a wireless network, severe collisions may occur--a phenomenon well known as the \"ACK/feedback implosion\" problem [9, 10, 11]. Furthermore, if the nodes respond promptly upon reception of a command, the responses will also interfere with the dissemination of commands. On the other hand, if the nodes respond slowly (e.g., wait for some time for command dissemination to hopefully finish), then the responses will be delayed, increasing the overall latency of the system. This problem can be more critical on applications that have large numbers of devices or are latency/loss sensitive. There are a number of prior works that attempt to mitigate congestion in low-power wireless networks in order to improve reliability and/or latency. However, most of themfocus only on one side of the problem: they either tried to improve either the downward command dissemination phase [12; 13; 14; 15; 16; 17; 18; 19; 20; 21; 22] or the upward response collection phase [23; 24; 25; 26; 27; 28; 29; 30; 31]. As both command-phase packets and response-phase packets collide not only among themselves, but also with each other, focusing only on one side is not enough for sufficient performance; they must be considered \"jointly\" and in parallel for real-world IoT applications. To this end, we propose SCoRe, an \"on-demand scheme for joint Scheduling of Command and Responses\" on multihop low-power wireless networks to improve both reliability and latency simultaneously. SCoRe assigns dedicated \"relative\" transmission timeslots to each node to completely eliminate packet collisions. (Later in Section 4.3, we develop a concurrent/parallel transmission feature based on spatial reuse for improved latency.) To do this, SCoRe gathers \"the number of desired timeslots for both command dissemination and response collection\" (\(N_{\text{dslot}}\)) from each node in the network. Then, upon reception of a command, SCoRe allocates subtree-aggregate timeslots to each next hop child node according to the their requirements recursively, layer-by-layer, as the command disseminates. Each node will transmit a response (if any) and re-disseminate the command message according to the assigned relative schedule. As a new relative schedule is calculated on-demand for each command and assigned asynchronously without time synchronization, SCoRe is adaptive to routing topology changes with minimal overhead. SCoRe is a cross-layer scheme that requires information from the network layer (i.e., route and hop info) and controls the transmission time at the link layer, and it can be used by IoT applications to resolve collision across \"multihop\" low-power wireless networks. We implement SCoRe on a low-power embedded platform [32], and evaluate it through both real-world testbed experiments and simulations with 30 embedded devices and 1 gateway on various topologies. Our evaluation results show that SCoRe improves both round trip time (RTT) and packet reception ratio (PRR) with little packet retransmissions on all tested scenarios without tuning the parameters for one metric nor one topology. Parameters of the legacy schemes can be configured to match either the PRR or RTT of SCoRe, but never both. SCoRe achieves this by scheduling command and responses jointly. The contributions of this work are as follows. * Identify and demonstrate the problem of severe collisions between command dissemination and response collection because they were not considered \"jointly\".