# Time Slotted Channel Hopping and ContikiMAC for IPv6 Multicast-Enabled Wireless Sensor Networks
## 1 Introduction  
Wireless sensor and actuator networks (WSANs) comprise constrained devices equipped with sensors and/or actuators. These devices (also referred to as nodes or motes), which can use radio waves to communicate, are exposed to noise and interference, and they are often powered by batteries. They have limited memory and processing capabilities, and they dispose of limited bandwidth, directly reflected in their networking performance. Therefore, WSANs should benefit from new protocols and applications customized for their needs, especially regarding energy and bandwidth. At the medium access control (MAC) level, protocols are responsible for minimizing collisions and maintaining energy consumption at a low level by putting the nodes' radios to sleep as much as possible with so called radio duty cycling (RDC) protocols. Contiki 3.\(x\) and the next generation (NG) Contiki-NG are operating systems (OSs) developed for sensors and actuators. They have a different protocol at the RDC/MAC level--ContikiMAC [1] for Contiki 3.\(x\) and time slotted channel hopping (TSCH) for Contiki-NG. ContikiMAC is an asynchronous RDC protocol where nodes periodically check if they have packets to receive by briefly waking up. TSCH [2] uses a synchronous time slotting mechanism and channel hopping to tackle some of the issues observed with ContikiMAC.  
In smart homes, point-to-multipoint (P2 MP) communication is extensively used. Examples of this type of communication are measurements transmitted by a temperature sensor to interested devices, such as the heating control, the user's smartphone, a wall display, or a command transmitted by the central system to several actuators controlling the light fixtures in the house. Internet protocol (IP) multicast improves the efficiency of P2 MP communication. When using the Internet Protocol version 6 (IPv6) unicast, the source sends an individual packet to each destination, whereas with IPv6 multicast the source sends only one packet with an IPv6 multicast address that the routers duplicate if needed in order to forward it to the destinations that subscribed to that multicast address. The use of multicast addresses further enhances the network's performance by avoiding the need to keep a list of interested destination IP addresses at the device level.  
In this paper, IPv6-based multicast over TSCH and ContikiMAC empowered WSANs is discussed. The investigated protocol, bidirectional multicast RPL forwarding (BMRF), is based on the Routing Protocol for Low Power and Lossy Networks (RPL). It supports both link layer (LL) unicast and LL broadcast forwarding to send IPv6 multicast packets downwards in the RPL tree to interested nodes (nodes that are part of the multicast group). BMRF can adapt its mode of operation at the link layer in each node to help to achieve the requested quality of service (QoS). Furthermore, a theoretical model for the delay and energy consumption of BMRF over TSCH with a given scheduling algorithm is presented. The focus is on delay and energy consumption. Along with the development of a theoretical model, simulations considering different scenarios with less or more interference between nodes are provided.  
The purpose of this paper was to investigate under which conditions multicast offers the most feasible and adequate solution. In order to do this, both LL unicast and LL broadcast forwarding in BMRF over TSCH- and ContikiMAC-enabled networks were thoroughly examined.  
The paper is organized as follows. Section 2 presents an overview of the related work, and Section 3 provides the required background on the protocols under study. Section 4 explains the settings used in the simulations and for devising the theoretical model, as well as the reasoning behind choosing those settings. In Section 5, a theoretical analysis of the delay and energy consumption of the considered situations is given, and Section 6 lays out the obtained results. Section 7 concludes the paper. The appendix discusses the theoretical model for ContikiMAC as implemented in Contiki 3.x.