# 3 MSF: A Multi-Modal Adaptation of the 6 TiSCH Minimal Scheduling Function for the Industrial IoT
## 4 The Multi-Modal Minimal Scheduling Function
### 6P Transactions
Additionally, we require (1) all subcell groupings in a RELOCATE request's relocation CellList, as well as those in the response's CellList (if non-empty), to match actual supercells; (2) NumCells to be an integer multiple of the required supercell length; and (3) the subcell groupings in a RELOCATE request's candidate CellList to each have a length greater than or equal to the supercell length and together be able to accommodate greater than or equal to the integer multiple of supercells specified in (2). Figure 10 shows an example of a possible (successful) RELOCATE transaction for 3 MSF. Figure 9: Example of a successful 6P ADD transaction used by 3 MSF, based on the fictitious setup depicted in Figure 5. Node #2 sends an ADD request to its preferred parent #1, providing it with a CellList containing two subcell groupings. From these groupings, node #1 picks two supercells in the negotiated slotframe following the request’s NumCells value and the supercell length corresponding to the TSCH mode specified by node #2 in the 3 MSBs of the CellOptions. CLEAR transactions work nearly identically between 3 MSF and MSF, with one small caveat. A CLEAR request with a Metadata field value of zero removes all supercells (towards the same neighbor) from the negotiated, probing, and shadow slotframes. Such a \"general\" CLEAR request/transaction is used if there is any risk of an inconsistent negotiated slotframe. Otherwise, a slotframe-specific CLEAR request is used. Finally, this leaves us with the sequence of 6P transactions we call shadow operations, which can only be initiated by a node towards its preferred parent under the following conditions:  
1. Shadow operations initiated by said node are not already ongoing (previous operations need to be terminated first; further details on this are discussed later);
2. A non-shadow 6P transaction is not currently ongoing with the preferred parent in any direction;
3. A non-shadow 6P transaction is not already scheduled to be initiated at some point in the future (e.g., because of a retry);
4. There is not already a maximum number of concurrent 6P transactions ongoing;
5. The node has a probing Tx supercell towards its preferred parent. During shadow operations, a node first determines how many negotiated Tx supercells it has towards its preferred parent before sending it an ADD request for (at most) the same number of shadow Tx supercells. Upon successfully installing at least one shadow Tx supercell (a maximum number of retries is allowed until at least one such supercell is added), the node may do the same for negotiated Rx supercells (if there are any, the same rules apply for retries). Finally, the node initiates a custom two-step SIGNAL transaction (e.g., see Figure 11). When this transaction completes successfully (with the same rules applying for retries) and not at any other point in time, all negotiated supercells involved are removed, new negotiated supercells are derived from the shadow supercells towards said neighbor, those shadow supercells are removed, and shadow operations terminate (in that order). Figure 10: Example of a successful 6P RELOCATE transaction used by 3 MSF, based on the fictitious setup depicted in Figure 5.  
Since the interface-mode used in negotiated supercells performed poorly, all traffic belonging to shadow operations must be sent using probing supercells only. Unfortunately, this creates a minor bottleneck due to the MAC sequence number consistency requirements mentioned in Section 4.2. During shadow operations, the following rules apply (besides any rules mentioned previously):  
1. The windowed counter mechanism for negotiated supercell management (see Section 4.2) is halted, and its counters are reset;
2. No non-shadow 6P transactions towards the preferred parent (with the exception of CLEAR transactions under appropriate circumstances) may be initiated towards the preferred parent or be scheduled for future initiation.