# On-Demand Scheduling of Command and Responses for Low-Power Multihop Wireless Networks +
## 6 Discussion and Future Work
### Coping with Packet Losses  
Although collisions between command-phase and response-phase packets are completely eliminated by SCoRe's relative scheduling, there are various other causes that may incur a packet loss. (e.g., colliding with routing control packet, CTI problems, multipath fading, etc.) Losses trigger link retransmissions, and the retransmissions may trespass on other's timeslots as they are not accounted for in the schedule. In addition, SCoRe's assigned slot information is built by the root of each subtree, and carried into command  
Figure 11: Results from the testbed experiments with \(M=3\), \(T_{C}=200\) ms, \(K=5\), and varying \(T_{R}\).  
messages. Therefore, each SCoRe node can only accept the command message if and only if the sender is its parent. In other words, a node cannot receive command packets from nodes other than its parent even though it can hear it from other neighbors. If a command packet from its parent is lost, then the descendants of the node will never receive the command. Therefore, this command reception restriction of SCoRe can lead to performance degradation.  
Potential future improvements to address these challenges are as follows.  
**Recurrent slot assignment.** When a SCoRe root generates a command message, it can set a recurrent bit and omit the scheduling info if the routing topology and \(N_{\text{dslot}}\) information has not changed since last command dissemination. A node receiving this command can use timeslots in the same way as the previous command. This method enables each node to be able to receive a command not only from its parent but also neighbors, and thus reduces overhead and improves downward PRR. As a result, recurrent slot assignment makes SCoRe more efficient.  
**ETX based timeslot.** A SCoRe node demands \(H\), its hop count, for its own response packet transmissions since this is the number of transmissions required to reach the root assuming 100% successful link PRR. However, link retransmissions due to losses may extend beyond its assigned slot, resulting in invading and violating other's timeslots which will again cause packet collisions. Therefore, careful estimation of the number of retransmissions can help SCoRe to avoid such collisions. ETX [55], expected transmission count, is a very well-known network metric, and RPL also supports ETX based routing called ETXOF [56]. SCoRe can use this metric to request and allocate \(N_{\text{dslot}}\) rather than hop count.  
**Permeate into lower-layer protocol.** SCoRe's packet can collide with other protocol's packets because its on-demand scheduling accounts for only the commands and responses within SCoRe protocol without considering, for example, routing control packets. In fact, most of SCoRe's packet losses in our evaluations come from packet collisions with RPL routing protocol, the DIO and DAO packets. To avoid this collision, SCoRe may be implemented \"jointly\" together with the lower-layer protocols. For example, SCoRe can reserve an extra slot within its schedule for other control messages (such as routing) to use. We leave this as our future work.