# Open-Source MQTT-Based End-to-End IoT System for Smart City Scenarios
## 4 Proof-of-Concept
### Gateway Interface to the Broker: The Android Platform
#### 4.2.2 Android MQTT Client  
The developed Android app, as previously stated, is able to send sensor's updates received from the BLE GATT server, as well as other kinds of information regarding the user, to a web dashboard through the MQTT protocol. Such connection has been implemented on the Android side by integrating a further background service that enables the smartphone to work as an MQTT client. The events occurring in such connection are handled by the Paho library, which provides a quite easy and straightforward solution when it comes to MQTT integration in Android devices.  
The connection with the broker and the publishing of the messages on the different topics occurs whenever the user interacts with the UI of the app and selects the option that starts the MQTT service in the background. Once the service is called, an instance of the class MqttAsyncClient() is created. It allows the client to initiate MQTT actions and then carry on working, while the MQTT actions are being completed in the background thread. Moreover, in order to check on the connection status, the interface MqttCallBack() is implemented, allowing the client to be notified when asynchronous events related to the client occur.  
The values published by the app are those acquired through the BME280 sensor, i.e., temperature, humidity, pressure and altitude; in addition, an _SoS_ message is published, which contains the GPS location of the user acquired through the smartphone GPS sensor. The MQTT messages are formatted with four possible topics, each one according to the MQTT specifications [7], having a PDU composed of three different fields: a fixed header, a variable header and a payload. The first four bits of the fixed header define the supported message types, and the remaining four bits of the first byte are used to define the different header flags, such as QoS (Quality of Service), DUP (duplicate) and RETAIN. In our case, the topics, whose payload contains one of the values read by the sensor encoded as a JSON object, have a QoS equal to zero in their 4-bit flag, where the QoS level defines how reliable the reception of the published message by the client subscribed to that specific topic is. In our case, a value equal to zero corresponds to the least QoS level; thus, there is no guarantee the message will be received by the subscribers subscribed to the topic; indeed, there is no acknowledgment packet sent, proving the publisher is aware of the reception of the message. The reason for selecting such QoS is due to its low resource-hungry requirements if compared to the other QoS levels; moreover, the loss of a packet would not be a problem as there is no essential information being sent.  
The SoS request topic carries the position of the user at the time the request is sent in the payload, while the QoS level is equal to 1 in this case. A QoS level of 1, also referred to as _At Least Once_, is a quite reliable transmission method in the MQTT protocol, but, as a drawback, it is resource-expensive, and the message could be sent more than once. The SoS message is essential and must be received by the subscribers at all costs; thus, receiving it more than once would lead to no issue. Nonetheless, it is supposed to be infrequently published by the client compared to the other topics implemented; hence, spending more resources than usual would be acceptable. The higher reliability of this level of service is accomplished by a two-level handshake between the publisher and subscriber, allowing the message to be received at least once. Figure 4 depicts the general PDU exchange that occurs in the IoT system we implemented.