# Whisper: Programmable and Flexible Control on Industrial IoT Networks
## 7 Whisper Roadmap  
Our current Whisper system implements a precise design choice, that is, to exert centralized control compatible with (more precisely, through) _unmodified open-standard distributed protocols_. Throughout the paper, we argued for the several advantages of this design choice for SDN in IoT networks: pros range from compliance with both per-device and network-wide resource limitations to ease of deployment. We are aware that Whisper's design choice also has drawbacks. One of them is the inability of Whisper to cope with arbitrary levels of granularity--e.g., to control routing at a per-flow or at a per-packet level, as enabled by SDN protocols in wired networks [19; 72; 73]. Although RPL limits the use of differentiated services and traffic engineering techniques, there is still an open research space to exploit them by using different RPL instances [74]. Whisper's full support for the use cases discussed in Section 3.1, however, suggests that this limitation might not be so critical in many practical SDN-over-IoT applications. In other words, Whisper might both leverage and demonstrate that the level of expressivity of IoT routing and scheduling protocols can be sufficient for SDN in IoT. Nevertheless, we also contemplate the possibility that future research might find new use cases for SDN in IoT networks. We believe that the overall Whisper's architecture might be useful in such cases. For example, our system can be easily adapted to _support_ new SDN-specific protocols or enablers. While technically not full SDN, the research community is currently investigating several management interfaces (e.g., COMI [75], LWM2M [76]), network operating systems (e.g., ONOS [77]) and configuration languages (e.g., YANG [53]) for enabling management and control on top of LLNs. One example of this is shown in [PERSON] et al. [78], where the feasibility of evolving ONOS for supporting SDN-WISE is proved. Many other solutions often focus on application oriented configuration, while Whisper focuses on the network management aspects. However, we do not see Whisper as a competitor of these solutions but rather as a complementary solution. Several of the commands of those languages can be expressed through Whisper as well via in-band signaling. As such, Whisper can provide a solution for enabling COMI-based management on top of legacy networks. Future research will therefore be focused on integrating Whisper with such management solutions. An evolved Whisper can as such piggyback SDN protocol messages in RPL/6P messages, and hence offer a reliable and overhead-effective substrate for delivering finer-grained commands. \begin{table}
\begin{tabular}{c c c c c c c c c c} \hline Network Size (\# nodes) & 10 & 25 & 50 & 75 & 100 & 125 & 150 & 175 & 200 \\ Avg \# Hops & 1.75 & 2.18 & 2.43 & 2.63 & 2.77 & 2.87 & 2.91 & 3.02 & 3.11 \\ Avg \# Neigh per node & 3.58 & 5.55 & 7.65 & 8.99 & 10.13 & 10.63 & 11.73 & 12.34 & 12.88 \\ \hline Without W nodes (\%) & 93.6 & 83.9 & 75.0 & 65.4 & 61.2 & 57.7 & 54.0 & 52.1 & 50.1 \\ Primitives per Switch & 1.55 & 2.26 & 2.88 & 3.14 & 3.43 & 3.46 & 3.72 & 3.84 & 3.85 \\ Primitive 1 (\%) & 73.4 & 53.1 & 42.3 & 39.1 & 35.8 & 35.2 & 33.2 & 31.9 & 32.13 \\ Primitive 2 (\%) & 26.6 & 46.9 & 57.7 & 60.9 & 64.2 & 64.8 & 66.8 & 68.1 & 67.86 \\ Computation Time (\(\mu\)s) & 6.7 & 36.0 & 114.2 & 230.6 & 396.6 & 552.9 & 802.4 & 1044.24 & 1446.2 \\ \hline \end{tabular}
\end{table} 
Table 4: Results of running the algorithm for different network sizes in the “_sparse networks_” group.