## 2 System Model
### Time-Slotted Channel Hopping  
Further, TSCH is a MAC protocol for low-power and lossy networks based on multichannel and time-slotted access standardized in IEEE 802.15.4-2015 [26]. In addition, TSCH supports reliability and deterministic communication between nodes by using a slotframe structure. The slotframe consists of multiple cells and repeats over time. Each cell is identified by the timeslot and channel offset. The cell is long enough to exchange a maximum-size data frame and its _Ack_ frame, typically 10 ms long.  
Figure 1: System architecture of MCSS.  
The cell can be classified as a dedicated or shared cell. The dedicated cell guarantees transmission between a pair of nodes. In contrast, the shared cell allows multiple nodes to access the same channel simultaneously. In each cell, the nodes communicate on the channel determined by channel hopping as follows:  
\[Channel=channelHoppingSequence[(ASN+offset_{ch})\%n_{availableCh}], \tag{2}\]  
where the _channelHoppingSequence_ represents a list of channels to be hopped; \(ASN\) denotes the absolute slot number, indicating the total number of timeslots that increase every timeslot since the network started; \(offset_{ch}\) refers to the channel offset; and \(n_{availableCh}\) indicates the number of available channels in the TSCH network.  
In the TSCH network, all nodes are globally synchronized to the network through the EB. The EB includes information, such as the slotframe structure, \(ASN\), and _channelHoppingSequence_. After the TSCH network formation is completed, cell allocation is performed. The IPv6 over the TSCH mode of the IEEE 802.15.4e (6 TiSCH) operation sublayer (6 top) protocol (6P) defined by the IETF 6 TiSCH working group provides 6P transaction for TSCH cell allocation [34].  
The 6P transaction is a mechanism that enables neighboring nodes to add, delete, and relocate cells to their TSCH schedule. In particular, the 6P transaction can be composed of two or three steps. In a two-step 6P transaction, a candidate cell list consists of cells that can be allocated by the node sending a 6P request message. However, in a three-step 6P transaction, the list contains cells that can be allocated by the node receiving the 6P request message.  
Figure 2 depicts an example of two-step and three-step 6P transactions. In Figure 1(a), node A transmits a 6P ADD request message to node B to allocate the required cells. The number of cells to be added (i.e., NumCells), and the list of candidate cells (i.e., CellList) determined by node A are included in the 6P ADD request message. Node B compares the CellList of the received 6P ADD request message to its TSCH schedule to identify which cells are available and selects two available cells. The list of selected cells becomes a CellList to be included in the 6P response message.  
Node B informs two selected cells by transmitting the 6P response message to node A. Upon successful completion of the 6P transaction, nodes A and B allocate two selected cells to their TSCH schedule. In Figure 1(b), node A transmits a 6P ADD request message to node B, including an empty CellList. When node B receives the 6P ADD request message,  
Figure 2: Example of two-step and three-step 6P transactions.  
node B composes the CellList, including NumCells or more candidate cells available in its TSCH schedule, and transmits the 6P response message to node A.  
Node A constructs a CellList by selecting only available candidate cells from the CellList of the 6P response message and transmits a 6P confirmation message containing the CellList to Node B. As a result, the 6P transaction is completed, and nodes A and B allocate the selected cells to their TSCH schedules. In MCSS, we used the three-step 6P transaction to allow each HAP, which knows the schedule (i.e., the results of cell allocation) for all sensor nodes included in the HAP cluster, to construct a candidate cell list.