# A LoRaWAN Network Architecture with MQTT2 MULTICAST
## 7 Results  
We have conducted three experiments to evaluate the performance of our solution. In particular, we compare (1) the delay between one data publication and its reception by a subscriber using MQTT and MQTT over multicast, (2) the amount of traffic in the SDN network also for both MQTT and MQTT over multicast, and (3) the amount of signaling traffic for a typical multicast routing protocol (PIM-SSM, Protocol Independent Multicast--Source Specific Mode) and MQTT2 MULTICAST. First we tested the MQTT latency reduction due to the usage of MQTT over UDP/ multicast in the SDN network instead of MQTT over TCP. Using MQTT over TCP, a publication requires 12 messages (TCP connection establishment, Connect/ConnAck, Publish, Disconnect, connection termination, and TCP ACKs). Using our solution, only the Publish message would traverse the SDN network. This reduction in messages implies a lower latency (from data publication until reception), being a more noticeable effect for high RTT values, as shown in Figure 12. In order to achieve a fair comparison, in this experiment the broker is a modification of our proxy implemented with Python/Scapy. For this experiment, we capture packet traces using tshark [26] at the publisher and the subscribers, so we can obtain the time between the publication and its reception by post-processing these traces. On average, the latency is reduced by approx. 90% (between 84% for RTT = 10 ms and 95% for RTT = 250 ms). Next, we describe the reduction of packets transmitted over the SDN network when using multicast instead of unicast for the proposed tree topology. In the case of unicast, e.g., when using normal MQTT brokers which transmit over TCP,  
Figure 11: Example of visualization of environmental variables. Figure 12: Delay between sending MQTT Publish messages (publisher) and their reception (subscriber). depicted in Figure 13. We assume that one of the brokers connected to a leaf switch will be sending one packet (e.g., an MQTT Publish message) to the brokers connected to the remaining leaf switches, i.e., a total of \(F_{1}\times F_{2}-1\), where \(F_{2}\) is the fanout in the last level and \(F_{1}\) is the fanout in the first level (\(F_{1}\times F_{2}\) is the number of leaf switches). Its corresponding leaf switch will forward these messages to its parent switch. The parent of that leaf switch will receive the packets and will (1) send one packet to its remaining \(F_{2}-1\) child switches and (2) forward \(F_{1}\times F_{2}-F_{2}=(F_{1}-1)\times F_{2}\) messages for the rest of the leaf switches, messages which are sent to the root switch. The root switch will forward these messages to its child switches, except to the parent of the source leaf switch. The number of messages in this case is \(F_{2}\) to each switch, i.e., a total of \(F_{2}\times(F_{1}-1)\) messages, matching the number of packets received by the root switch. Each of the switches in the first level (except the switch corresponding to the source) will then forward one message to each leaf switch, i.e., a total of \((F_{1}-1)\times F_{2}\) messages. Finally, each of these \((F_{1}-1)\times F_{2}\) leaf switches will forward one message to their corresponding brokers, i.e., \((F_{1}-1)\times F_{2}\) messages. All these messages total \(6F_{1}F_{2}-3F_{2}-1\). If we consider the TCP ACK messages in the opposite direction, the number of packets would double. In the case of multicast, e.g., when using our MQTT proxies which transmit using multicast over UDP, the number of messages is depicted in Figure 14. In this case, the source will send only one message, which is forwarded by its leaf switch to its parent switch. This switch will forward one message to the remaining child switches, i.e., \(F_{2}-1\), which are in turn forwarded to their respective proxies, and one message to the root tree. The root tree will forward the message to the remaining \(F_{1}-1\) switches in the first level, which will then transmit the message to their respective \(F_{2}\) leaf switches.