# Open-Source MQTT-Based End-to-End IoT System for Smart City Scenarios
## 5 Feasibility Evaluation  
In order to evaluate the feasibility of the proposed system, a Proof of Concept has been setup. In Figure 6, a picture of the real setup of the PoC is presented. It is possible to notice the wearable prototype node that is implemented on the development dashboard where both the BME280 sensor and the ESP32 SoC are installed. An Android smartphone with the developed app is also part of the PoC where a proper BLE link is used for its connection with the wearable node. The Raspberry PI 3B+ node is used as the MQTT Broker; indeed, it receives MQTT messages from the Android device, acting as the publisher and  
Figure 5: Dashboard: Sensors Display. sends them to the connected MQTT subscriber, here represented as a Windows 10 PC. As previously mentioned, in the implemented PoC, the MQTT subscriber is here implemented as a Webservice, where a proper Dashboard is used for representing the sensed values. In this section, the feasibility of the proposed solution will be analyzed by focusing on the exchange of BLE data packets occurring between the Android smartphone and the ESP32 SoC. While the E2E implementation has been proven by considering the visualization on the Dashboard, as represented in Figure 5, we focus now on the BLE packet exchange. The aim of the analysis carried out is to provide insight into the BLE PDU exchanged between the two nodes and prove that the information contained in such packets do map perfectly to those that have been implemented on the software side. It is worth noticing that the system we have implemented is aimed at testing a single E2E connection going from a wearable device, acting as source of data, to an MQTT subscriber node, acting as sink. To this aim, we have not performed tests over fully loaded scenarios. It is, however, clear from other papers, e.g., [38], that an Eclipse Mosquito-based solution, despite not being designed as a scalable implementation, allows processing around 20,000 messages per second, which is far beyond those envisaged in the considered scenario. Smartphones generally have implemented the two most important BLE protocol layers, i.e., the host and controller. The host represents the upper layer of the protocol stack and is generally more resource-hungry than the controller; hence, quite often, it is integrated into the main CPU. It can communicate with the controller through the Host-Controller Interface (HCI). Such configuration is known as Dual-IC-over-HCI since the two protocol layers are embedded into two different Integrated Circuits communicating with each other through a communication mean defined by the Bluetooth specification, implying that any host can exchange data through HCI with any controller, regardless of the manufacturer. The interaction between these two layers is part of our analysis: we have used the Wireshark packet analyzer tool in order to sniff both the HCI events and the HCI commands, which are the two different PDUs sent by the HCI between those two endpoints. Whenever the user interacts with our app and performs actions that imply the use of the BLE chip, each request is first received and processed by the host, and, later on, the command to be executed is sent to the BLE radio controller, which will answer with an HCI event. Figure 6: The real setup of the PoC. A common HCI command is sent. Whenever the user initializes a scan of the BLE devices nearby, the BLE radio controller will answer with a list of events, i.e., the advertising packets sent out by the nearby Bluetooth devices; it is worth mentioning that HCI events and commands are vendor-specific. In Figure 7, a scan response is shown, which was sent by the ESP32 and contains, in the payload, all the information that was previously discussed in the software development of the ESP32 node. Once the connection of the Android smartphone to the SoC has been correctly established, an exchange of ATT PDUs between the two endpoints takes place.