## 5 Experimental Evaluation
### Application-Level Latency Results
#### 5.3.1 Hazard Detected by a Vehicle
The average value of the RTT is around 74 ms, thus, this is effectively accounting for around 43%, 50%, and 46% of the average application-level latency of UDP/HTTP-, MQTT-, and hybrid UDP/HTTP and MQTT-based communications, respectively, when both of the OBUs are connected to the same edge cloud. Therefore, we can observe that the rest of the delay is introduced from internal processing across layers in the backend and OBU applications. It can be noticed that UDP/HTTP-based communication incurs extra delay of 23 ms on average than MQTT-based communication on the same edge cloud deployment, realising that this is due to the relatively higher internal processing delays introduced by the Edge Geoserver. Additionally, the Edge Geoserver synchronously sends unicast UDP messages to each connected OBU on the downlink by mapping each subscription to a corresponding OBU connection; hence, this also introduces extra delay into the end-to-end delay when compared to the publish-subscribe model of MQTT protocol. On the other hand, hybrid UDP/HTTP and MQTT-based communication introduces extra delay of 13 ms than MQTT-based communication; therefore, this can be attributed to the added processing delay introduced by the Edge Geoserver on top of processing by the Edge MQTT broker as well as delays in using the MQTT QoS level 1 for asynchronous reliable delivery of messages between participants [35; 36]. The choice of QoS in MQTT has effects in the performance of throughput and the message transmission latency. In the ACCA service deployment, the Edge Geoserver performs the translation of ETSI ITS messages in ASN.1 format to JSON encoding, and vice versa. Thus, this translation mechanism introduces extra delay when compared to the Edge MQTT broker. (2) Results of application-level latency for two edge clouds  
As it can be observed in Figure 8, when OBU 1 and OBU 2 are connected to two different edge clouds, the average application-level latency is: 226.5 ms with a standard deviation of 73.2 ms when the OBUs communicate over the UDP/HTTP protocol; 233 ms with a standard deviation of 86.7 ms when the OBUs communicate over MQTT; and. 234.8 ms with a standard deviation of 71 ms when OBU 1 communicates over UDP/HTTP and OBU 2 communicates over MQTT. Similarly to the one edge cloud setup, the delay introduced by the 4G radio access network is effectively accounting for around 33%, 32%, and 32% of the average application-level latency of UDP/HTTP-, MQTT-, and hybrid UDP/HTTP and MQTT-based communications, respectively. Additionally, the average RTT over the wire-line (10 Gbps optical fiber connection) between the edge cloud servers and the TMS on the centralised cloud is around 1.45 ms; thus, the delay that occurs in inter-edge communication is negligible. Contrary to one edge cloud, we can observe that the delay over access network is contributing equally into the end-to-end delay of each combination, resulting in similar average delays, overall, on the application-level latency. However, it can be noticed slightly higher delays of few milliseconds in both MQTT, and hybrid UDP/HTTP and MQTT-based communications than UDP/HTTP-based communication. This is due to the involvement of additional processing elements in the backend. For example, V2X messages are processed twice by two instances of the Edge Geoservers, and this is additional to the Edge MQTT brokers in the scenario where MQTT-MQTT communication occurs over two edge clouds deployments; thus, it introduces relatively higher application-level latency, as shown in Figure 8, than UDP-UDP communication.