# Time Slotted Channel Hopping and ContikiMAC for IPv6 Multicast-Enabled Wireless Sensor Networks
## Appendix A  
ContikiMAC is an RDC protocol that regularly turns on the radio transceiver of the motes to check for packet transmissions. The time between two consecutive checks is called the channel check interval (CCI). The channel check rate (CCR) is the inverse of the CCI. When a sender transmits a packet using broadcast on the LL (see Figure 11), Contiki-MAC transmits it during at least one CCI. This ensures that each mode within its transmission range wakes up at least once and gets a chance to receive the packet. When using unicast (with ACK option set) in combination with ContikiMAC, the number of transmissions is generally lower because the sender stops sending when an ACK is received. As an additional optimization, the sender can from now on predict when the intended receiver wakes up in the future (see Figure 12). However, this prediction cannot remain accurate due to differences in clocks between motes caused by clock drift. If this drift results in the sender starting late, it must send during almost an entire CCI to find the receiver awake again. To reduce the occurrence of this flaw, the sender incorporates a safety margin and starts 10 milliseconds before the receiver is estimated to wake up. The chosen value for this margin results in the sender using, on average, four-to-five transmissions (for 40 bytes packets). In case the minimum margin cannot be met, the sender delays its transmission to the receiver's next wake up. Below, the theoretical model for delay and energy consumption is presented. * Delay ContikiMAC Unicast: A theoretical model for the delay in ContikiMAC was presented in [8]. This was done by investigating the delay of the link between all motes in the network and calculating the average for each hop. For example, the delay of a multicast packet with BMRF in unicast mode for hop 1 (\(\hat{d}d_{hop1}\)) and hop 2 (\(\hat{d}d_{hop2}\)) are given in a network where each mote has three children (the topology can be seen in Figure 11): \[d_{hop1}=\frac{\sum_{i=1}^{3}\sum_{k=1}^{i}d_{link}(0\to k)}{3}+d_{PR}\] (11) \[\hat{d}d_{hop2}=\frac{\sum_{i=1}^{3}\sum_{k=1}^{i}d_{link}(0\to k)}{3}+ \frac{\sum_{i=1}^{3}\sum_{j=1}^{3}\sum_{k=1}^{j}d_{link}(i\to i.k)}{3^{2}}+d_{PR}\] (12)where: \[d_{link}(i\to i.k)=d_{ndc+phy}+d_{con}(i\to i.k)\] \[for\ i=\{1,2,3\}\ and\ k=\{1,2,3\}\] (A3) with \(i\) and \(k\) representing notes in the network and \(ik\) being a child of more \(i\). The delay caused by RDC and physical layer is represented by \(d_{ndc+phy}\), and the delay caused by the link layer's contention is represented by \(d_{con}\). Each of these delays was discussed in detail in [8]. However, that model was developed for ContikiOS 2.6. With the migration to ContikiOS 3.x, a change was made to the ContikiMAC mechanism. As a result, the order of packets in the queue could change, so the packet for the more that wakes up first is also sent first. This means that when using LL unicast transmissions, \(d_{rdc}\) is no longer \(\frac{CCI}{2}\) but depends on the number of packets that need to be sent. Consequently, \(d_{ndc}\) becomes \(\frac{CCI}{p+1}\), where \(p\) is the number of packets to be sent. * Delay ContikiMAC Broadcast: The calculations for the delay for broadcasts in ContikiMAC are less complicated because retransmissions have no effect on the delay (if collisions happen, the packet is simply dropped). However, this means an artificial random delay has to be added in BMRF to prevent routes starting to forward a packet at the same time.