## 5 Experimental Evaluation
### Application-Level Latency Results
#### 5.3.1 Hazard Detected by a Vehicle  
In this scenario, the application-level latency is measured by computing the elapsed time since the transmission of a DENM message by one of the OBUs, until subsequent reception of that DENM message on the other OBU. We have carried out two measurement campaigns. In the first campaign, OBU 1 and OBU 2 were connected to the same edge cloud and the V2X information exchange between both OBUs did not traverse through the TMS. In the second campaign, the OBUs were connected to two different edge clouds,  
Figure 7: The representation of the test cases with two experimental OBUs. Each test case consists of a different combination of V2X communication protocols between both OBUs and the edge cloud. (**a**) UDP/HTTP-based communications; (**b**) MQTT-based communications; (**c**) Hybrid UDP/HTTP and MQTT-based communicationswith OBU 1 and OBU 2 being connected to edge cloud 1 and 2, respectively, establishing the communication between both edge clouds through the TMS, as shown in Figure 1.  
For the connectivity of OBU 1 and OBU 2 with the edge clouds in each measurement campaign, we have considered three different combinations of V2X communication protocols that are described in Section 5.2: UDP/HTTP-based communications (Section 5.2.1); MQTT-based communications (Section 5.2.2); and, hybrid UDP/HTTP and MQTT-based communications (Section 5.2.3). For the acquisition of latency results for each combination of V2X communication protocols in each measurement campaign, OBU 1 was first assigned the role of the sender and periodically generated 100 DENM messages, while OBU 2 was acting as the receiver, then, the roles of the OBUs were swapped and another 100 DENM messages were transmitted from OBU 2 to OBU 1. The time interval between consecutive DENM messages follows a uniform distribution between 3 and 5 s. In this way, we have collected 200 samples in total at each test case for the computation of the application layer latency. Figure 8 shows the results of application-level latency between the OBUs obtained in each measurement campaign (i.e., one edge cloud, two edge clouds). Each boxplot in the figure represents the distribution of measured application-level latencies over the total number of collected samples, indicating mean and median values, respectively, by the triangle and the horizontal line. The x-axis label indicates the combination of V2X communication protocols between the sending and the receiving OBUs, i.e., UDP-UDP indicates that both OBUs communicate over the UDP/HTTP protocol, MQTT-MQTT indicates that both OBUs communicate over MQTT, and UDP-MQTT indicates that OBU 1 communicates over UDP/HTTP and OBU 2 communicates over MQTT. (1) Results of application-level latency for one edge cloud  
As it can be observed in Figure 8, when both OBUs are connected to the same edge cloud, the average application-level latency is: 171.0 ms with a standard deviation of 64.7 ms when both OBUs communicate over the UDP/HTTP protocol; 148.2 ms with a standard deviation of 45.0 ms when both OBUs communicate over MQTT; and, 161.1 ms with a standard deviation of 44.0 ms when OBU 1 communicates over UDP/HTTP and OBU 2 communicates over MQTT. Figure 8: Application-level latency between OBUs measured for three different combinations of V2X communication protocols between the sender and the receiver OBUs. One edge cloud represents that both OBUs connected to the same edge cloud, whereas two edge clouds represent that each OBU is connected to a different edge cloud. We have performed an ICMP-based PING on the OBUs to measure the Round Trip Time (RTT) between the OBUs and the edge cloud server over the 4G radio access network (RAN)in order to understand how much 4G/LTE contributes to the end-to-end application-level latency.