# Routing Protocols for Low Power and Lossy Networks in Internet of Things Applications
## 4 Enhanced Routing Solutions for Internet of Things Networks
### Multicast Communication Support  
Multicast communication represents a fundamental transmission type for several IoT applications. As pointed out in Section 2, an industrial environment application running over an LLN can require the sending of alert messages for a predefined group of nodes or base stations. To achieve this, the routing protocol should realize reliable multicast transmissions. Proposed in 2010, the Multicast Protocol for Low-power and lossy networks (MPL) [67], which was introduced in parallel to RPL and initially called trickle multicast, was the first effort of IETF to provide IPv6 multicast support for LLN. Defined as an IETF standard in 2016 through RFC 7731, the MPL uses a flooding mechanism controlled by trickle timers [52] to perform multicast message sending without the necessity to maintain routing tables. Although the MPL is an independent protocol, its solution is sometimes considered an extension to provide multicast support for RPL. In MPL, all network nodes can receive a multicast message depending on whether they are inserted in a multicast group. As all nodes can broadcast the received multicast packets, the implementation of a mechanism for avoiding duplicated messages is necessary. Thus, MPL includes a sequence number in the packet header for distinguishing each multicast message, besides storing the most recently-received messages in a buffer. After receiving a multicast message, the node should verify whether it was already received by checking its sequence number or presence in the buffer. If the node identifying the message is already received, it should discard it. Otherwise, the node must record the message sequence number, store it in the buffer, process the payload, and multicast it to the other nodes. MPL uses trickle to organize both control and data messages exchanged among the nodes. The nodes can use control messages for informing their neighbors about their set of sequence numbers or buffer. When a node identifies that a neighbor has not yet received a message, it redefines its trickle interval to the minimum value to quickly disseminate the packet missed by the neighbor. Thus, due to storing the most recent packets in a buffer and to allow local retransmission of lost packets, MPL can offer high reliability for the packet delivery ratio. Although MPL can provide high reliability, it can also present a high end-to-end latency and communication overhead. Thus, trying to mitigate these drawbacks, [PERSON] et al. proposed the Stateless Multicast RPL Forwarding (SMRF) [68]. The proposal was constructed over RPL and uses the \"storing mode of operation with multicast support\" (multicast RPL or MOP 3) of the IETF standard solution to offer enhanced results when compared with the default approach. SMRF proposes a cross-layer mechanism that improves the functioning of Radio Duty Cycling (RDC) protocols for multicast forwarding operations. As an example, the authors cited ContikiMAC [69], a duty cycling mechanism present in the Contiki OS [70] and widely used in IoT/6 LoWPAN networks. ContikiMAC presents low radio usage for reducing the power consumption of the nodes. Thus, the radio spends the majority of its time sleeping (turned off), waking-up (turning on), and periodically trying to identify a possible packet transmission. The duration of the period during which the radio is turned on is called CCI (Channel Check Interval). A node, to send a message, realizes several transmissions of the same packet during a time interval intending to reach an awake receiver. This repetitive transmission is referred to as a packet train. In a unicast transmission (Figure 6), a receiver node detects a packet sent during its CCI and starts the reception window until it receives the whole message. Afterwards, the receiver must send an acknowledgment to the sender, which finishes the packet train transmission. Differently, during a broadcast transmission (Figure 7), the sender must send a message during the entire packet train interval.