# Empirical Evaluation of TLS-Enhanced MQTT on IoT Devices for V2X Use Cases
## 4 Implementation and Methodology Overview
### Benchmarking Strategy  
The benchmarking process is carefully structured to measure, on realistic IoT hardware, the impact of each TLS 1.3 phase during MQTT communication. To ensure accuracy and reproducibility, all scenarios are fully automated using shell scripts that coordinate, monitor, and collect data for each run. Each reported value is the mean of twenty experimental cycles, while for metrics such as CPU utilization and execution time during encryption, the standard deviation is also reported whenever non-negligible. For each test case, a fixed number of MQTT messages of the same size are transmitted from the publisher to the subscriber through the broker. Each phase uses different Mosquito configurations to achieve the corresponding measurement isolation. For the first three phases, a single one-byte message is exchanged in order to ensure the handshake completion and at the same time minimize the introduced payload distortion. This approach is also used in the No-TLS (plaintext) experiment, offering the control baseline. In contrast, Phase 4 (data exchange) is benchmarked using three payload sizes corresponding to low- (100 KB), medium- (1 MB), and high-volume (100 MB) data transfer and five different configurations of message count and size, for both AES_256_GCM and Chacha20_Poly1305. The isolation of the TLS phases is handled differently for handshake (Phases 1-3) and data exchange (Phase 4). For the handshake, we adopt a step-wise additive method: each experimental Mosquito configuration sequentially enables one additional TLS handshake phase, and the incremental overhead is attributed to the specific phase under test. For Phase 4 precise start- and stop-time measurements, complemented, for the broker, by three introduced MQTT control topics, precisely mark the productive time-frames in which all measurements for all payload and cipher suite combinations are conducted. Further elaborating on Phase 4, the scenarios executed are designed to systematically evaluate how varying demands of the application layer affect the performance of TLS 1.3-secured MQTT. Specifically, we benchmark three message size configurations for a fixed total payload of 100 KB: 1000 \(\times\) 100 B, 100 \(\times\) 1000 B, and 10 \(\times\) 10,000 B. These configurations reflect typical V2X message types specified in standards such as ETSI EN 302 637-2 (Cooperative Awareness Messages (CAMs) and Decentralized Environmental Notification Messages (DENMs)) [39], SAE J2735 (Basic Safety Messages (BSMs) and Signal Phase and Timing (SPaT/MAP)) [40], and 3 GPP TR 22.886 [41]. The first configuration corresponds to routine status updates, e.g., vehicle position, speed, and heading, found in CAMs or BSMs, while the second represents medium-sized safety alerts and environmental warnings, such as DENMs or SPaT data. The third configuration reflects large payloads relevant to localized map segments or partial firmware transmissions. In addition to the 100 KB scenarios, we include the medium-volume payload of 1 MB configured as 1000 \(\times\) 1000 B to represent more intensive sensing or vehicular data exchange. Finally, a high-volume stress scenario with a payload of 100 MB, configured as 10,000 \(\times\) 10,000 B, corresponds to intensive operations such as advanced driving and over-the-air (OTA) firmware or map database updates aligned with the use cases described in ETSI TS 122 186 [42], SAE [3151 [43], and 3 GPP TR 22.886 [41]. All payloads are generated deterministically to ensure repeatability, and packet capture is synchronized with message transmission and reception, enabling precise measurement of latency, goodput, and resource utilization. These standard-aligned payload configurations allow for a comprehensive and realistic evaluation of TLS-enhanced MQTT in V2X contexts. Execution time and CPU cycle measurements for the handshake phases are collected using the perf stat tool, which wraps the relevant process from start to finish.