# Time Slotted Channel Hopping and ContikiMAC for IPv6 Multicast-Enabled Wireless Sensor Networks
## Appendix A
This results in a delay of \(PT+\frac{CCI}{2}\) at the first hop and in the following equation for the delay at any subsequent hop \(i\): \[d_{hopi}=PT+\frac{CCI}{2}+(i-1)\bigg{(}\frac{CCI}{2}+\frac{CCI*spread+1}{2} \bigg{)}+d_{PR}\] (A4) where \(PT\) is the time needed to receive a packet, _spread_ is the maximum number of CCIs a more needs to wait before forwarding a packet according to the artificial random delay, and \(d_{PR}\) is the mean processing delay needed for a packet to travel from the networking layer to the application layer, assuming a uniform distribution. With these equations, it was concluded that the main cause of delay when using LL broadcast transmissions comes from the artificial delay added before forwarding a packet in order to avoid collisions. This artificial delay is proportional to the CCI. For LL unicast, on the other hand, the delay per hop is proportional to the number of interested children. Therefore, regarding dense topologies in which shallow trees are formed such that each mode has a lot of children, LL broadcast can outperform LL unicast. Unicast transmissions are fast when the motes in the network do not have a lot of children. * Energy ContikiMAC: To calculate the energy consumed by the operation of ContikiMAC, one needs to calculate the time a more will be listening to incoming packets. In the default settings, a more performs two clear channel assessments (CCAs) and sleeps for an amount of time given by the CCI. \[t_{AWAKE}=\frac{t_{CCA}}{CCI}\] (A5) In our setting for ContikiMAC, the radio is awake for twice the time needed to do a \(CCA\) (\(t_{CCA}\)) every \(CCI\), where \(t_{CCA}=0.38\) ms and \(CCI=125\) ms. This means the radio will be awake 0.608% of the time. The energy consumed for handling a packet can be split in two parts: the energy consumed for sending a packet and the energy consumed for receiving a packet. The time needed to send/receive a packet in ContikiMAC is highly dependent on the type of the packet (unicast vs. broadcast and packet length). When ContikiMAC is sending a unicast packet, four or five packets are being sent on the MAC layer. The sender also performs seven CCAs before sending and must spend time awake to receive the ACK, as specified by the ContikiMAC protocol, resulting in the following equation: \[t_{Sender_{listening}}=7*t_{CCA}+t_{RA}\] (A6)\[t_{Sender_{Scaling}}=x*t_{US},\;where\;x=4,5 \tag{10}\]  
Here, \(t_{US}\) is the time needed to send one unicast packet, \(t_{CCA}\) is the time needed to perform a CCA, and \(t_{RA}\) is the time needed to receive an ACK. A unicast packet takes 2.585 ms (\(t_{US}\)) to be sent, and receiving an ACK takes 0.325 ms (\(t_{RA}\)). In total, this results in an average of approximately 11.6 ms sending and approximately 3 ms receiving for each packet sent. A broadcast packet takes 3 ms to send and must be sent during the entire CCI:  
\[t_{Sender_{Scaling}}=41*t_{US} \tag{11}\]  
This results in 41 packets or 123.82 ms in total. The time needed to receive a packet depends on the time the receiver wakes up during the transmission. If the receiver wakes up at the perfect moment, it only takes one attempt with the duration of a packet to receive the packet. However, if the receiver wakes up slightly too late, it might take up to the equivalent of two packets being received (plus the time between packets) for the packet to be received. This means the packet will be received in a maximum of 6 ms and a minimum of 2.585 ms, which gives an average of 4.3 ms. In ContikiMAC, motes must check every packet, even when the packets are not meant for them. This must be considered when estimating the energy consumption. This only happens when the mote wakes up during the transmission of that packet, which takes 14.2 ms (four or five packets with some time in between). This results in a chance of (\(\frac{142}{125}\)) 11.4% for a mote to wake up during a transmission of a packet meant for another mote. A summary of the values can be found in Table 14.