# Empirical Evaluation of TLS-Enhanced MQTT on IoT Devices for V2X Use Cases
## 4 Implementation and Methodology Overview
### Benchmarking Strategy
For the broker, perf monitors the entire Mosquito process to capture handshake duration passively, while for publisher and subscriber, it wraps the Python process encompassing connection, message exchange, and disconnection. For Phase 4, each run begins with the broker launching the MQTT server, followed by the launch of the subscriber. The publisher is started after a short delay to ensure that both the broker and subscriber are fully initialized and subscribed to the relevant control topics. To monitor execution timing, a dedicated Bash script runs on the broker side, capturing timestamps with millisecond precision using the command /bin/date +%s.%N triggered upon the reception of control messages. The broker marks its start time upon receiving the control/start signal from the publisher. Two key time intervals are computed: the first measures the duration required to receive all messages from the publisher, while the second spans from the reception of the first message to the arrival of the final PUBACK from the subscriber. These intervals allow us to compute (i) the client-to-broker goodput and (ii) the end-to-end latency, defined as the total time required to transmit the complete payload from publisher to subscriber via the broker. Upon completion of message publishing, the publisher script sends a message to the control/pubdone topic to indicate that all messages have been transmitted. This enables the subscriber-side benchmark controller to accurately compute the total elapsed time between the control/start and control/pubdone messages, with millisecond-level granularity. Once the subscriber receives the final message and sends the corresponding PUBACK to the broker, it issues a message to the control/stop topic to confirm that the payload has been fully received. On publisher and subscriber devices, wall-clock time for sending and receiving is measured in Python using time.perf_counter() to ensure high-resolution, monotonic timing. For the publisher, the clock starts immediately before the first payload message is sent and stops after the final publication. For the subscriber, timing begins upon receipt of the first payload message and ends after the last message is received. Thisevent-driven synchronization strategy eliminates the need for cross-device clock alignment and ensures deterministic, reproducible latency and goodput calculations. In our experiments, the term actual messages refers to the payload messages that are measured and analyzed. Prior to each benchmark run, we introduce a warm-up phase in which a number of preliminary messages are transmitted to avoid cold-start effects and stabilize system behavior. The number of warm-up messages is determined by the formula \(warmup\_count=(min(int(count\times 0.2),200))\), where warmup_count denotes the number of actual messages in the given experiment. This approach ensures that the warm-up phase is proportionally significant in smaller experiments, without introducing excessive overhead in larger ones. After each run, a short space period is included to allow for the flushing of logs, the completion of background processes, and the delivery of any remaining messages. Additionally, the termination of the experiment is deliberately delayed to guarantee that all timestamps, performance metrics, and output data are consistently and deterministically recorded. In each experimental run, goodput is computed by dividing the total size of the transmitted payload (in bytes) by the corresponding execution time. This metric reflects the effective application-layer throughput, excluding protocol overhead, retransmissions, and control messages. The selected measurement approach offers reliable and accurate insights into real data delivery performance. In our setup, goodput was found to be more representative than raw throughput measurements, particularly because tools like shark introduced significant processing overhead on resource-constrained devices that led to latency spikes, packet loss, and inconsistent measurements.