# Whisper: Programmable and Flexible Control on Industrial IoT Networks
## 5 Whisper Specifications
### Injecting Fake DIOs  
The fake DIO injection is one of the key procedures in Whisper. In RPL, there is an hysteresis phenomenon introduced by the threshold value T used in order to make links more stable. Whisper leverages from this threshold in order to create an stable parent switch. By sending a DIO with a higher or lower artificial rank, the target node \(t\) can switch to the desired parent. Due to this hysteresis, only 1 DIO will suffice since, although after some time node \(t\) will receive a legitimate DIO from the old parent, \(t\) will not switch back due to the rank difference not being high enough. This is the concept that is behind the four available DIO primitives:  
* **Primitive 1:** Fake DIO sent in unicast from the root to the \(t\) node remotely. It is considered as a normal DATA IPv6 packet in order to reach the remote destination, so it has the local MAC destination address of the next hop and the IP destination address of the remote node \(t\). This type of fake DIO can only be used for supplanting the previous parent of \(t\), but it has the advantage of being able to remotely trigger a parent switch in a node several hops away with only one message and without the need of modifying the rank of an entire branch, controlling the root node or using a Whisper node.
* **Primitive 2:** Fake DIO sent periodically in unicast from the root (MAC and IP source address) to the first node of the branch of \(t\) (MAC and IP destination address). When these types of DIOs are present, all DIOs sent from the root are sent in unicast, customizing the rank that each branch needs to have and replacing the normal DIOs sent in broadcast. Since these DIOs are sent periodically, the value of the rank in that branch will be constantly updated and propagated along the branch. Although this primitive is normally used in combination with Primitive 1 to make \(d_{t}\) the most preferable parent, it can also trigger parent switches by itself.
* **Primitive 3:** Fake DIO sent in unicast from a Whisper node to \(t\) node locally. This DIO has the MAC and IP source address of the node that the Whisper node is supplanting and the MAC and IP destination address of the \(t\) node. This primitive can also be used for both switching a parent or in combination with Primitive 1. It is used for finding feasible solutions for some cases such as Example 2 in Figure 4.
* **Primitive 4:** Fake DIO sent in unicast from the Whisper node to the local \(t\) node periodically, the Whisper node being the desired parent of \(t\). This type of DIO is equivalent to Primitive 2, with a Whisper node instead. This primitive is used when it is necessary to announce the presence of a Whisper node enabled for active traffic forwarding in the network.  
The DIOs have to be consistent with the DODAG version used in the current DODAG instance, so that when changes in the topology happen, DODAG versions become updated as well. We address this by having always at least one node controlled by whisper being an active part of the network, either the root node or a Whisper node, for tracking the DODAG version.  
Unlike standard DIO messages, our \"well-crafted\" Whisper DIOs are sent in unicast. This allows for reaching any node in the network that is part of the DODAG and not interfering in the Trickle Algorithm [52] in nodes other than \(t\). In addition, since they are sent in unicast, IEEE 802.15e specifies that their frames have to be acknowledged (_Ack Request_ bit to 1). This provides Whisper with more reliable control since it allows for re-transmitting fake DIOs in case of failure.  
Finally, depending on how lossy the network is, the increments in the primitives can be complemented with a rank margin value M that would make the network more stable under ETX fluctuations on the links.  
In order to show how the process of the parent switch happens through fake DIOs, we illustrate in Figure 4(a) a sequence diagram of the first use case showed in Figure 3(a) and explained in Section 3.1.