# Whisper: Programmable and Flexible Control on Industrial IoT Networks
## 3 Whisper Framework: SDN without SDN  
### Central IoT Control by Whisper-Ing  
The Sixtop subayer describes the technical means for nodes to communicate with their neighbors, and RPL provides the basic information for forwarding packets. They both implement statically defined decisions--e.g., parent preference in RPL through a predefined objective function. Dynamics, however, are an important aspect of networks, especially IoT ones, where resources can suddenly deplete and network conditions change. This calls for a more flexible network management system. Whisper aims at realizing such a system while also exposing a high-level interface for operators to define their management objectives (programmability). Whisper's centralized controller (e.g., a server) is at the root of the RPL DODAG, or directly controls the messages received and sent by the root. The controller can therefore communicate with root's neighbors, exchanging 6P and RPL messages with them; and it uses this possibility to craft messages that conveniently influence routing and scheduling decisions of nodes which are potentially far away. For example, by disseminating untruthful information about its rank to some of its neighbors, the controller can modify the RPL DODAG. Consider again Figure 1, and suppose that the Whisper controller positioned in R sends a DIO to 3 \"whispering\" that [PERSON]'s rank is higher than 256. This will increase the rank of 3, which in turn will locally broadcast its new increased rank. Depending on the rank value whispered to 3, this single message can induce a subset of 3 and its children (8 and 9,in the example) to change their respective parents. Whisper exploits this mechanism for implementing high-level policies (see Section 3.3). We now present a few illustrative examples of Whisper's ability to implement practical policies. **Whispering for better routing**  
Currently, human operators and network management systems cannot dynamically adapt routing to unexpected events, such as depletion of the battery of a given network node. Consider again the example network in Figure 1, and suppose that node 3 starts running out of battery. The ideal response to this event would be to switch the parents of nodes 8 and 9, from 3 to 10 for node 9 and from 3 to 9 for node 8, as shown in Figure 2a. This would re-route traffic from 8 and 9 around the low-battery device (node 3) while also not overloading node 2 (which already has to carry traffic from nodes 5, 6 and 7). However, this is impossible to achieve in standard RPL networks. Some RPL OFs could optimize the routing in terms of energy and load balancing. However, these OFs are executed independently in different RPL instances, so that different traffic can follow different paths regarding how it is tagged. However, combining both OF would require developing another specific OF explicitly for this task. In contrast, we argue that by just using the default stand-alone RPL OF0 in a the network, Whisper can achieve the desired parent changes without modifying any bit in the firmware of the already deployed nodes. Whisper achieves this behaviour by replacing standard root's DIOs with periodic unicast fake DIOs with an artificial high rank (e.g., 2599) that will be propagated to nodes 8 and 9 through node 3. Due to this propagation, they will switch their parents to 2 and 4, respectively. In order to make 8 pick 9 as its preferred parent, the root can propagate as well through node 2 an artificial high rank (e.g., 1000). Both nodes 8 and 9 will keep their newly selected parents since the difference for changing back to other tentative parents is not large enough. **Whispering for better scheduling**  
Whisper can also be used for managing the scheduling plane. Consider the network in Figure 2b which runs 6 TiSCH. Suppose that a malicious node starts a jamming attack that selectively interferes with the cell (7,3) between 2 and 4.