# Time Slotted Channel Hopping and ContikiMAC for IPv6 Multicast-Enabled Wireless Sensor Networks
## 2 Related Work
The root repeatedly adds the group members with the least path cost to build the multicast tree. To advertise the routing information related to the multicast tree, a new control message was introduced. Their approach promised increased reliability by using a proactive retransmission mechanism. When receiving a packet destined to a reachable address, the node forwards the message several times and stores the packet's ID to avoid forwarding the same packet again. The new protocol was implemented in Contiki. To evaluate its performance, the following parameters were considered: successful delivery ratio, end-to-end delay, and energy consumption. The authors observed that PMFR could achieve higher energy efficiency, higher packet delivery ratio, and shorter delays. As shown in the paper proposing BMRF [8], the RDC protocol used in the network can have a big impact on the performance of multicast protocols. The paper has a detailed evaluation of the delay caused by BMRF when using ContikiMAC as it was implemented in Contiki 2.6. The authors analyzed LL broadcast and LL unicast transmissions on restricted topologies to be able to compare simulation outcomes with outcomes from a mathematical model. They concluded that LL broadcast delays were mostly caused by the artificial delay integrated into the collision avoidance mechanism, whereas for LL unicast, the delay per hop increased with the number of interested children. The authors pinpointed the situations in which each of the transmission modes was more efficient. The results also showed that the performance of a network using ContikiMAC was highly dependent on the internal interference. In addition, the paper mentioned some specific disadvantages caused by ContikiMAC. When sending a packet, not only the intended receiver but also all other neighbors wake up to check if they are the designated receiver. Another example of an unintended consequence is that a broadcast message needs to be sent during an entire duty cycle in order to give all neighbors a chance to wake up and receive the packet. This results in a lot of waisted energy. As for a comparison between TSCH with 6 TiSCH minimal configuration and ContikiMAC, the authors of [2] compared the delay and duty cycle of a star network in a real testbed. The 6 TiSCH standard includes a simple static schedule where all the communication takes place on a single timeslot, within a slotframe. With their settings, TSCH was found to outperform ContikiMAC in both delay and duty cycle. However, since a star network was used with nodes in each other's ranges, a lot of interference between nodes were created, this being detrimental to ContikiMAC. In [9], a performance analysis of TSCH together with the Orchestra schedule was presented. The authors concluded that Orchestra resulted in a high delay when traffic was substantial because of the inadaptability of the Orchestra schedule to traffic load that could give rise to queuing delays. In [10], the authors presented an analytical model of TSCH when using only shared links. In [11], another comparison between TSCH and ContikiMAC was provided. The authors emulated a total of 11 motes in the Cooja simulator; node 1 was the root, and the remaining 10 nodes were positioned to form a star topology. To profile the power consumption, different activities such as packet transmission or reception were analyzed. The authors concluded that TSCH resulted in a lower energy consumption. To the best of our knowledge, no thorough analysis yet exists for BMRF over TSCH, and no comparison between LL unicast and LL broadcast forwarding has been provided, which was the goal of this paper.