# Open-Source MQTT-Based End-to-End IoT System for Smart City Scenarios
## 4 Proof-of-Concept
### Gateway Interface to Sensing Layer: The ESP32 Platform
#### 4.1.1 Software Implementation  
In order to program the ESP32, we used the C++ programming language through the Arduino framework, which is a relatively easy and fast prototyping tool that allows us to experiment on our models before production, although most embedded system products ready for production implement the real-time operating system (FreeRTOS) kernel [28], as it is designed to be small and simple. In order to enable a communication between the ESP32 and the BME280, we have used the drivers developed by Adafruit [29], which allow connecting the sensor and easily reading the values obtained from the measurement of temperature, pressure and humidity from its registers. The output of the readings has to be sent through a BLE connection to the Android gateway, and another library [30] has been used in order to manage this connection. In the case of the SoC, the three main BLE protocol layers (i.e., Application, Host and Controller) are implemented in the same chip in order to save space and have a more miniaturized device. Before analyzing the implemented structure, it is important to introduce the BLE Generic Access Profile (GAP) and the BLE Generic Attribute Profile (GATT), and their role in the relationship between the two devices [31]. The GAP defines which of the two mechanisms are used by a BLE device for communicating with other devices, i.e., broadcasting or connecting. The GAP defines how BLE-enabled devices can make themselves available and how two devices can communicate directly with each other. The GATT instead defines the role of a specific device, which can be a client or a server. The client typically sends a request to the GATT server and can read and/or write attributes in the server. The server stores the attributes. Once the client makes a request, the server must make the attributes available. The ESP32 acts as the GAP Peripheral, meaning that it transmits advertising packets with the aim of establishing a connection with the device; in this case, the Android smartphone, acting as the GAP Central, is constantly listening to advertising packets sent on air by nearby peripherals in order to connect to the correct one. The Broadcaster role for the SoC has been discarded, making it work as a BLE Beacon, due to possible security issues, e.g., eavesdropping, that someone would face while transmitting data without establishing a secure connection first. Regarding the GATT role, it can be assigned to a device regardless of its GAP role, and it is even interchangeable; in our case, the SoC works as the GATT Server during the whole time since it sends the data packets without receiving any. The GATT Client role has instead been assigned to the smartphone. The implemented GATT Server, hierarchically organizing all the attributes defined by the Attribute Protocol, is represented in Figure 2.  
The GATT server has been implemented with two services. The _BME280_Service_ contains the attributes labeled _Characteristic_, following the GATT convention, assigned to different sensors, while the _Hearth_Service_ is foreseen to be assigned to a heart-rate monitor, although it is not implemented in the deployed PoC, and used as a future plug-in extension. The BME280 service has four characteristics corresponding to the temperature, humidity, pressure and altitude readings, where the latter, although not directly read by the sensor, can be calculated through the other readings' information. The heart-rate service has only one characteristic, which is connected to the reading of the heart-rate of the service user. In order to work with every attribute, the Universally Unique Identifier (UUID) should be defined, allowing to universally identify the attribute.