# Efficient Collaborative Edge Computing for Vehicular Network Using Clustering Service
## 7 Results  
This section discusses the most interesting and meaningful results of this research. The results have been obtained from two different scenarios which are the two legs of the framework connections. Scenario 1 tests the connection between the vehicle device and the edge computing server. Scenario 2 tests the connection between the edge and cloud computing servers in terms of cluster management. Scenario 1: We can obviously notice from Figure 6 that, with the latency calculated with the ideal status, the vehicle keeps transferring data towards the edge server, and the test transfers a simple string which only takes 120 ms of latency, which increased dramatically by around 15%. We expected to see stability due to the lack of operations which were involved in the ideal session. Thus, we can clearly notice the difference registered by the proposed CCVEC framework when spending 163 ms for 100 loads and the latency increase while the load increases to spend 283 and 373 ms in 200 and 300 loads, respectively. The latency is attributed to the fact that the edge server is occupied with other connections with the cloud and cluster nodes in the neighbor. Other interesting findings include the fact that the vehicle encounters extra latency when it moves to a new server but it benefits from the pre-processed information that has already been shared from the previous server. Figure 7 presents interesting findings by measuring the throughput of the proposed mechanism to conclude that, during the ideal session, the edge server receives sufficient throughput from the vehicle device, which is 57.1 kB/s in 100 loads, which is considered to be a high value. That is because the edge server in this case operates normally with other cluster nodes. However, when the patient moves to the next edge server, the CCVEC framework is invoked and the throughput decreases to approximately 50% from the ideal status. That is because the edge server is occupied with the cloud and the next/previous server. Figure 8 shows the impact of the CCVEC framework on edge servers when it performs read operations from the data center (cloud). Obviously, we can notice that the local database (edge) consumes less memory when it connects to the far-end cloud server, which is due to the high integrity and ideal operations, i.e., it consumes 5.9% of memory. However, once the CCVEC framework is invoked, it starts to read/write the vehicle's information such as vehicle_ID and the high-resolution map, and the memory increases accordingly to utilize 6.9% of the memory while a load of 400 is applied. Scenario 2: The scenario presents an interesting part of the results because it measures the vital activities between the edge and the cloud server. Figure 9 describes the time taken to handle cluster nodes when the vehicle transfers to a new server. It spends 147 ms during 100 loads which is higher than the ideal case by 91 ms. This variance is accepted since it is less than 1 s. We attribute this to the connection with the cloud, next edge server, and some database retrieval. In addition, it is worth mentioning that, when the load is 500, the CCVEC spends 501 ms, which becomes a higher difference from the ideal case because of the intersection session between the two clusters neighbor. The intersection might occur with the previous server as well. Figure 10 presents the throughput of the proposed CCVEC framework while communicating with the cloud and neighbor servers. In the ideal case, there is low traffic sent towards the cloud from the edge server and it shows 26.2 kB/s in 100 loads, which is due to the fact that no operations were occupied at this time. However, this amount of data (26.2 kB/s) is attributed to the other operations that regularly occurred in the system, such as new events in the cluster change/update policy, or up/down of the cluster. The load 500 shows a promising indication by presenting a 58 kB/s difference from the ideal status. This varies in the cost of all the activities created by the cluster such as update, add, remove, etc.