# On-Demand Scheduling of Command and Responses for Low-Power Multihop Wireless Networks +
## 3 Problem  
We first investigate the performance problem when collection packets are (near) synchronized, and when command and response phase packets coexist. We implement a \"Flooding + RPL -collection\" (RPL is the IETF Internet standard IPv6 Routing Protocol for Low-power and Lossy Networks defined in RFC 6550 [24], popular in many IoT applications [38]). application scenario where commands are flooded into the network periodically from a root node, and each embedded node transmits a response to that command over multihop. When transmitting, each node will use random jitter ranges, \(T_{C}\) for command dissemination and \(T_{R}\) for response collection, to delay its transmission slightly. This is in an attempt to avoid synchronization between multiple receivers--the so-called \"ACK/feedback-implosion\" problem [9; 10; 11]. A node receiving a command forwards it and responds to it within \(T_{C}\) and \(T_{R}\) milliseconds, respectively, where the time is chosen uniform randomly. For the commands, a node transmits \(M\) times for reliability (Since there is no link-layer ACK for link broadcasts). We implement this on TinyOS 2.1.2 [39], and conduct simulations using Cooja simulator [40]. We use BLIP and TinyRPL [41] in TinyOS as the UDP/IPv6 stack and RPL implementation, respectively. Each node is a TelosB [32] with an MSP430 microcontroller and a CC2420 radio, and communicate with each other over IEEE 802.15.4 links with CSMA. With this implementation, we run simulations for three cases: \"command dissemination only\" (C), \"response collection only\" (R), and \"command and response together\" (CR) on grid topology as shown in Figure 0(a). \(T_{R}\) and \(T_{C}\) are set to 1000 ms and 200 ms, respectively, and the number of command broadcasts \(M\) is 3. The root generates 1000 command packets, and every node responds with a message for every command. All messages are UDP over IPv6. Figure 0(b),c plot the results of our preliminary experiment. Figure 0(b) shows that downward (from root to embedded node) PRR is much better than upward (from embedded node to root) PRR, and upward PRR performance worsens significantly when command packets exist; downward PRRs are almost 99% in both \(C\) and \(CR\) case, but upward PRRs is 76.7% in \(R\) case and \(CR\) is 66.5%. First part is because dissemination is based on link-layer broadcast, thus every node can receive commands from all neighbors not only their parents, whereas responses are sent via unicast through the routing paths established by the routing protocol. More importantly, when collecting, 30 nodes are generating hundreds of link transmissions to travel over multihop within \(\sim\)1000 ms, i.e., severe link congestion, collisions, and queue overflows are occurring at bottleneck nodes. Command packets make things significantly worse (\(CR\) compared to \(R\) case). Therefore, scheduling both command and response phases in conjunction is essential, not optional, for network performance. Next, we adjusted the parameter \(T_{R}\) to investigate how much latency we would need to sacrifice in order to achieve 99% reliability. Figure 0(c) presents the required minimum random jitter \(T_{R}\) to achieve 99% PRR as the number of network nodes is increased (with fixed \(T_{C}=200\) ms). We ran simulations with 4, 9, 16, 25, and 30 nodes as presented in squares of Figure 0(a). The required \(T_{R}\) increases sharply as the number of nodes increases due to larger network depth and increased number of transmissions, as expected. This naturally leads to increased latency and higher response delay. The real challenge is, in real-world applications and systems, a network manager would need to carefully pre-tune the parameters (e.g., random jitter \(T_{R}\)) depending on the network size and topology to achieve its performance goals. We have learned this the hard way through several real-world implementations and deployments of IoT projects [4; 5; 6; 7].