# 3 MSF: A Multi-Modal Adaptation of the 6 TiSCH Minimal Scheduling Function for the Industrial IoT
## 3 Related Work
However, they tag cells with an identifier corresponding to a single communication mode, meaning simultaneous transmission on modes of different interfaces is not possible. This works for their design because they define every communication mode to be an independent RPL neighbor (devices remain the addressable entities on the link and routing layers) and assume the use of an Rx-based routing metric. More specifically, their solution does not work with exclusively Tx-based routing metrics because there is no way to keep fresh metrics for all RPL neighbors with autonomous supercells always using the same communication mode and every communication mode being an independent RPL neighbor (like most 6 TiSCH implementations, they assume a node has one preferred parent at a time), whereas with an Rx-based routing metric, the broadcast packets received on the minimal supercells would suffice. The problem is that Rx-based routing metrics are often rather simplistic. Moreover, autonomous supercells are quite important for network performance, as they typically service a large part of 6P traffic, especially in the downstream direction of networks that are, after all, mostly MP2P, meaning negotiated Rx supercells towards preferred parents are not common (nor are they mandatory). Put differently, limiting autonomous supercells to a single communication mode is a huge potential weakness (and we have not even touched yet on their importance when switching to a new preferred parent). Having multiple autonomous supercells towards the same device, each using a single communication mode, is also not an option because that would be extremely inefficient, which further highlights the missed opportunity for simultaneous transmission on communication modes of interfaces that operate in different frequency ranges or are otherwise orthogonal. Recently, [PERSON] et al. (2017) proposed enabling simultaneous multi-band operation for 6 TiSCH by adding a secondary radio interface to devices (one fixed mode per interface), building an independent routing topology for each interface, and sending a duplicate of the same packet in every topology. While this reduces routing layer complexity, building a separate DODAG for each communication mode without the possibility of switching packets between them implies a reduced capability to handle heterogeneous environments compared to single-topology solutions. After all, as a given copy of a packet can only progress within its DODAG, each possible destination must be reachable across at least one path of which each link uses the same communication mode. That is, if you want to achieve full coverage. Additionally, sending a duplicate of each message for every communication mode, combined with the added management traffic associated with maintaining multiple independent routing topologies, means that a multi-topology strategy is less energy efficient. Figure 4: Format of a 6 TiSCH Operation Sublayer (6 top) Protocol (6P) ADD request. The three Most Significant Bits (MSBs) of the CellOptions field indicate the communication mode to use in the supercells/subcells proposed by the CellList. As a counter-argument, the authors claimed that single-topology solutions are inherently non-compliant with 6T3 SCH, which is factually incorrect. Presumably, they failed to recognize that 6 TiSCH does not mandate the use of any specific RPL OF. In summary, Table 1 gives an overview of the TSCH-based solutions for multi-modal IIoT discussed in this section and how they differ (mainly) in terms of the considerations discussed in Section 2.2. Note that the work of [PERSON] et al. (2017) is not included in this table, as it constitutes a fundamentally different (and arguably sub-optimal) approach.