## 3 Network Architecture Description
### Cloud Layer  
The network Cloud Layer is shown in Figure 5. It is principally formed by an MQTT broker; MQTT clients; two server routines; and a MySQL database, which is devoted to the storage of all of the incoming information broadcast by the nodes. In other words, the network Cloud Layer directly derives from the one of a previous work [29]. The servers are the Network Server and the Application Server. Both of them are implemented by resorting to Node-RED (i.e., a flow programming language grounded on JavaScript). It is a development environment originally issued by IBM that relies on Node.js (i.e., a run-time environment carrying out JavaScript snippets outside a browser in order to allow their usage on the server side). Conversely, the exploited MQTT broker is Mosquito, which was released by Eclipse open source. It is in charge of forwarding MQTT messages from MQTT clients, prior to their successful connection to the broker itself. Indeed, the core of MQTT is the broker, since all of the clients stand on its shoulders because it routes all of the messages. Clients may be publishers and/or subscribers, and in particular, a client could behave as publisher and subscriber at the same time. The network of this paper includes MQTT clients in the LoRaWAN-NB-IoT Gateway, in the NB-IoT Nodes and in the Network Server. Specifically, all of them simultaneously behave as publishers and subscribers. Publishers exchange messages enveloping information with subscribers by posting them on topics to which the latter clients are subscribed. Between publishers and subscribers, there is the broker that all those clients were previously connected to, whose task is to take charge of all of the messages posted by the publishers and to forward them to any client who is subscribed to the topic on which those messages were posted. Figure 5: Cloud Layer block scheme architecture. The Forwarding Layer is included for the sake of completeness. Marsh grass arrows represent MQTT links, while the turquoise arrow stands for database connections. The Network Server is carried out via a Node-RED flow, and it works as follows (see Figure 6). Two different types of MQTT clients are concerned in such a server: the former is related to LoRaWAN-NB-IoT Gateways, while the latter is related to NB-IoT Nodes. To make the explanation clearer, let us consider that a message from the Gateways is received by the Server. No sooner had such a message arrived than the Server sent back an acknowledgment to the Gateway at hand by exploiting the MQTT protocol to perform a network diagnostic. Then, the Server checks the type of data within the incoming message. Indeed, it could contain either Gateway functioning statistics or data from the LoRaWAN Nodes. In the former case, the statistics are processed and then stored within the database. In the latter case, the Server accomplishes further routines. In the case of multiple Gateway deployments, it is highly likely that a packet coming from a LoRaWAN Node could be received and therefore forwarded to the Cloud Layer by multiple Gateways. Therefore, the Network Server filters out such duplicates. Successively, the Server decrypts the LoRaWAN packets by resorting to the NwkSKey and to the AppSKey. Such a procedure gives both the decrypted payload and the Message Integrity Code (MIC) as the outcome. Thus, the MIC is controlled because it could be either valid or invalid. If it is valid, then, the payload at hand was decrypted with the same AES keys with respect to the exploited ones used to encrypt it. This translates into the fact that the transmitting node at hand belongs to this network. On the other hand, if an invalid MIC is generated, then the AES keys used in turn for encryption and decryption are different, thus meaning that the transmitting node at hand does not belong to this network, and the relative packet is discarded. Consecutively, if a valid MIC is observed, then the packet is processed and further controlled.