# A LoRaWAN Network Architecture with MQTT2 MULTICAST
## 5 MQTT Enhancements in the SDN Segment
### MQTT2 MULTICAST Protocol  
We have developed MQTT2 MULTICAST with two objectives. Its main purpose is to provide a mapping between MQTT topics and the IP address of the multicast group. Furthermore, taking advantage of these messages, MQTT2 MULTICAST also allows adding or removing members to the group. In that sense, it eliminates the need of IGMP and thus it further reduces the amount of traffic on the network.  
MQTT2 MULTICAST is composed of two different messages, _MQTT2 MULTICAST Request_ and _MQTT2 MULTICAST Reply_, which are exchanged between the MQTT proxies and the MQTT2 MULTICAST server (implemented as an application at the SDN controller), see Figure 5.  
Figure 4: MQTT messages between publisher and subscriber through the broker.  
_Request_ are sent by MQTT proxies in order to ask for the multicast IP address assigned to a specific MQTT topic. The message contains four different fields: a _transaction ID_ (2 bytes, used to match request and reply messages), _flags_ (1 byte, which indicates the reason for the request), _topic size_ (2 bytes) and _topic_ (MQTT topic whose size is determined by the _topic size_ field).  
The first bit (_subscribe/publish_) of the _flags_ field is set to 0 if the reason for the _Request_ message is that an MQTT publisher is sending an _MQTT Publish_ message through the proxy, or 1 if there is an MQTT subscriber sending an _MQTT Subscribe_ message for a new topic. The MQTT proxy will not send _Requests_ for new subscribers to topics that have been already announced from the MQTT proxy to the MQTT2 MULTICAST server. The second bit (_unsubscribe_) of the _flags_ field is set to 1 if the last subscriber to a specific topic is sending an _MQTT Unsubscribe_ message to the MQTT proxy.  
The response to the previous _MQTT2 MULTICAST Request_ is an _MQTT2 MULTICAST Reply_, which contains a _transaction ID_ (which shall match the value from the corresponding request), _flags_ (set to 0, for future use) and the multicast IP address (assigned to the MQTT topic included in the request).  
These messages allow us to achieve the following functionalities:  
* The first time an MQTT publisher or subscriber sends an MQTT message about a new topic, the MQTT2 MULTICAST server assigns the next available multicast IP address from its addresses pool for that topic. This mapping is saved onto an internal database, and will be used for all future messages related to that topic.
* During the previous mapping, the SDN controller will also save the publishers (sources) and subscribers (destinations) for that topic. With this data and the network topology information (obtained from LLDP and ARP messages), it will generate the required multicast routing trees. Since MQTT proxies aggregate MQTT messages from a large amount of publishers and subscribers, we have opted for source-based trees (SBT), in order to optimize the delay between MQTT proxies. These trees are then transferred to the SDN switches by using one flow entry that redirects to a group table entry. This group table entry with type _ALL_ in which the buckets represent the switch ports belonging to the tree, i.e., which shall forward the multicast message.
* When new devices subscribe to a topic that have been already processed by the MQTT proxy (i.e., there are already subscribers for that topic connected to that proxy), there is no need to send an MQTT2 MULTICAST request to the SDN controller, since the MQTT proxy is already included in the corresponding multicast trees.
* When the last subscriber for a given topic unsubscribes, the MQTT proxy shall inform the SDN controller in order to be removed from the corresponding multicast trees.  
Figure 6 depicts the aforementioned behavior.  
Figure 5: MQTT2 MULTICAST message exchange.