# A LoRaWAN Network Architecture with MQTT2 MULTICAST
## 2 State of the Art  
In this section we will first present a brief summary of the different possibilities to deploy a LoRaWAN network. Other aspects such as platforms for IoT, more focused on data storage, distribution, processing and visualization (such as Google Cloud Platform, IBM Watson IoT, Amazon AWS IoT Core, Microsoft Azure, among others) are outside the scope of this work. An example of a large LoRaWAN network architecture is The Things Networks (TTN), an open, collaborative network with more than 20,000 gateways around the world. Its architecture [4] is made up of bridges that interact with gateways, connected to routers that route to the corresponding brokers (depending on the geographical location). These interact with network servers and handlers that manage communication with application servers. There is no detailed information about the real elements composing the architecture or their organization. Regarding LoRaWAN platforms, it is worth highlighting Chirpstack [5], a free and open source platform that allows to deploy private networks, and LORIOT [6], free for small networks (up to 30 nodes) but without the possibility of setting up private networks. Chirpstack provides the different entities (LoRaWAN network and application servers, and a Gateway Bridge) so it is up to the developer which network topology to use or other deployment details. LORIOT includes 13 free community network servers, a professional LoRaWAN network server with a 99.9% SLA, built-in redundancy and new accessible features to manage and scale a secure LoRaWAN network, and a carrier-grade private LoRaWAN network server solution for production services at any scale. Apart from this, no further details about their architecture are given. It shall be noticed that, since the Chirpstack platform freely provides all the entities required to deploy a private network, we will use Chirpstack for our deployment. Additionally, since this work will enhance MQTT in our platform, we also include here some relevant works found in the literature that optimize the MQTT protocol for IoT deployments. One of the most relevant modifications of the MQTT protocol for IoT is MQTT-SN (MQTT for Sensor Networks) [7]. MQTT-SN is designed for wireless networks, with low power battery operated sensors with very limited processing power and storage, with a limited payload size and not always connected (i.e., sleeping). With this objective in mind, it uses UDP as transport protocol and topic identifiers instead of topic names. The architecture also changes with respect to MQTT, with MQTT-SN clients, gateways and forwarders. The gateways act as MQTT-SN brokers and also translate to MQTT to forward messages to MQTT brokers (aggregating clients or not). The forwarders just retransmit MQTT-SN packets from clients to gateways. MQTT-SN utilizes multicast for discovery, but data is sent using unicast. The main differences with our solution is that nodes do not use standard MQTT and that messages are not multicasted. Another work, MQTT-ST (MQTT Spanning Tree), focuses on the communication between distributed MQTT brokers. Its main objective is to avoid potentially harmful message loops between brokers. After an initial phase, at runtime, the MQTT-SN brokers work exactly as MQTT brokers. Although this optimization may be very useful, it does not contemplate multicasting or any other feature to reduce latency or traffic generation. Direct Multicast-MQTT (DM-MQTT) [8] follows a similar approach to our solution, since it multicasts MQTT messages within an SDN network. However, for QoS (Quality of Service) level 0, multicast is performed directly between publishers and subscribers without brokers. This may create scalability issues in the SDN controller if we have a large number of MQTT clients. In addition, they use a CBT (core-based tree) with a rendezvous point, which may not be optimal from a delay point of view.