# Open-Source MQTT-Based End-to-End IoT System for Smart City Scenarios
## 5 Feasibility Evaluation
Many attributes' protocol PDUs use a sequential request-response protocol [33], where once a client sends a request to the server, there are no more requests being sent from that client until a response PDU has been received; a request-response pair is a defined transaction. This pattern is not valid for notifications, which do not have a response PDU since they are asynchronous; hence, for commands that do not have a response PDU, there is no flow control, and commands can be sent any time without having to wait for a response. Herein, we intend to limit our analysis to the ATT PDU, which we deem worth mentioning. The first transaction we analyzed starts with the smartphone sending a command to the ESP32 with opcode ATT_FIND_INFORMATION_REQ, which is used to obtain the mapping of attribute handles with their associated types, allowing the client to discover the list of attributes and their type of GATT server. If at least one attribute is returned, the ATT_FIND_INFORMATION_RSP PDU will be sent from the server to the client; if no attribute is returned, the ATT_ERROR_RSP PDU is returned with the respective error code. Another transaction that occurs is the one that starts with requests having opcode ATT_READ_BY_TYPE_REQ, which is used for obtaining the values of attributes, when the attribute type is known while the handle is not. The response to this PDU has opcode ATT_READ_BY_TYPE_RSP and contains the pair of handles and values of the attributes that have been read. As stated in Section 4.1, each characteristic has the Notify property, and it is enabled by the Android device by writing to the CCCD of every characteristic of the GATT server that the GATT client would receive notifications from. Such an operation is performed  
Figure 7: Advertising Scan Response. at the network layer by sending the ATT PDU with opcode ATT_WRITE_REQ, which is used to request the server write the value of an attribute; in this case, the CCCD is the attribute of the server we wish to write with value b'0x01 since it allows enabling the notification property. The PDU with opcode ATT_WRITE_RSP will then acknowledge whether the attribute was correctly written or not. The whole initialization procedure aimed at establishing a means of communication between the two endpoints has been analyzed to lasts only 3.7 s, in the worst case scenario, when the distance of the two BLE devices is greater than 1 m. In Figure 8, the PDU corresponding to the delivered notification from the GATT server is shown, which has as its opcode ATT_HANDLE_VALUE_NTF, and it is not longer sequential--the transaction pattern defined before is no longer followed. The system has been tested in different communication scenarios with the goal of estimating its performance in a realistic setting. To this aim, we considered connecting the Android device with the MQTT Broker through different wireless technologies, i.e., WiFi, EDGE, HSPA+ and 4G. In Table 1, the results obtained through a measurement campaign performed on slots of 80 s for 10 different times at different hours of the day are reported. We can see the communication technologies' great impact. It is, however, worth noticing that, even in the worst case obtained through the EDGE, we are able to implement some of the applications over the presented scenario. As an example, moving vehicles in traffic through a calm neighborhood were sufficiently alerted about other vehicles nearby. Moreover, we have to clarify that, following BME280 specifications, each sensor is supposed to generate one sensed value with a rate equal to 21 Hz, i.e., every 47 ms. Hence, the Android node receives one BLE packet every 47 ms. In addition to this, the Android-embedded sensors are set in order to receive data every 200 ms (i.e., by setting the delay to SENSOR_DELAY_NORMAL). In the worst case scenario, since we have five values through the BLE interface and one internal, we have around 110 MQTT packets per second. Considering that each MQTT packet is around 5 B for small data, the data rate is around 4.4 kb/s.