Utilization of nested clustering in VANET to reduce data loss in mobile cloud computing

The ubiquitous requests to be connected to the networks, particularly internet and transferring large-volume data and huge files between internet and consumers, lead us to have more reliable and stronger connections and junctures [1]. Many devices such as smart phones need to be connected to the internet to be online for some applications. Moreover, new internet necessities and new cars and vehicles, equipped with computers and storages enjoying high market penetration rate lead internet service providers to expand their services even through streets. Theoretically, it seems that we can use these resources to design more reliable networks for vehicles on the streets. One of the most emerging technologies to integrate the mobile computer resources for expanding network resources is mobile cloud computing [2].

The mobile cloud computing (MCC) is defined by MCC Forum [3] as a reference to some infrastructures where data processing and storing happen outside the mobile devices and instruments. Based on this definition, Mobile Cloud applications move data storages and processing away from mobile phones to the cloud. This cloud contains not just smart phones resources but broader range of subscribers such as computers and so on.

According to the MCC structure and architecture, Dinh, HT, et al. proposed a categorized form for cloud services [4]. Based on this proposed form, we have three main layers for services in MCC. The first one is Infrastructure as a Service (IaaS). This layer contains hardware and network peripherals. The other layer is Platform as a Service (PaaS) which all operating systems are determined under this category and the last one is Software as a Service (SaaS) which software and applications to serve are enclosed in this field.

Based on above definition for MCC, we can use the other wireless technologies such as Vehicular Ad hoc Network (VANET) for mobile consumers to utilize vehicle resources like using their storages as IaaS [5]. In VANET topology, we have two main parts: the first, Nodes such as vehicles and the second one, Road Side Units (RSU). Nodes can connect together and are called Vehicle-to-Vehicle (V2V) or can connect to the exterior network such as Internet via RSU as a roadside infrastructure and are called Vehicle-to-Infrastructure (V2I) [6, 7]. Due to connecting numerous nodes to the RSU, sometimes overhead on RSU occurs and it is not a sufficient state. Because of many solicitations they may collide and fail. To omit or reduce this problem, clustering topology for VANET has been proposed [8]. By this topology, some vehicles gather in a hypothetical cluster and just one member can make dialogue to RSU instead of all of cluster members. We have three kinds of members in a cluster. Cluster Head (CH) which can be the cluster manager, Cluster Gateway (CG) that can connect to other clusters as an interface and (CM) the rest of members, Cluster Member. The important challenge in this topology is to find the most adequate CH in a cluster [9].

The main purpose of clustering method is definitely the reduction of overhead. Therefore, a good clustering algorithm should focus on minimum number of clusters without increasing high communications over the network. It means that according to the clustering approach, we must generate the minimum of packages for V2I and V2V with reducing overhead on CH and RSU concurrently. Besides, we have dissemination at crossroads and intersections which is a significant problem because in cloud services, more stable connection has the highest priority to have the lowest data loss. Based on these problem assumptions, we propose Nested Clustering (NeCl) in our approach as an optimum solution to reduce overhead and data loss. According to NeCl, we can manage CH tasks and shift some of these tasks to Sub Cluster Head (SCH). A SCH is the Cluster Head of a Sub Cluster (SC). One of the most important conditions in a clustering method is to have minimum number of clusters. We definitely observe this condition because managing sub clusters are not on RSUs and their modifying and managing is done only on their cluster heads. It is reasonable to say that NeCl causes remarkable decreasing probability of overhead on CH because of reducing the number of tasks physically. Real streets have their criteria and conditions on intersections and we have some equipped traffic-light crossroads. We have considered these main facts in our proposal, too.

In this paper, we introduce our proposed approach, at first. Then we show how we select the most adequate CH. After that, we use some mathematical criteria and physical conditions to make Nested Clusters and we will show how this proposal works in a real environment theoretically. After that, we propose our simulation results by related diagrams to show efficiency of our proposal in comparison with other approaches in this field. The last section concludes this paper and proposal.

There are very sparse approaches about cloud services on streets and their problems to transfer data from RSU to Vehicles [10]. In the following, we summarize three approaches which try to find suitable and optimum solutions. Then, we enumerate the main drawbacks of each one among all related works in this case.

One of these approaches has been proposed by Yu. Rong et al. [11]. It recommends a cooperative download/upload design with bandwidth sharing. In this approach, when applicant A is going to take a huge file from RSU, there are two steps. The first step is to find some vehicular neighbors such as B and C to set up a vehicular cloud for downloading cooperatively. In the next step, the file is split into some segments (three segments in this example) by RSU and each part is downloaded by vehicles A, B and C concurrently. At last, B and C send the separate file segments to A and A merges the file parts together finally. This proposal will increase the chance of getting a complete file remarkably. But to have an optimum approach there are some drawbacks. First, all of the vehicles should have negotiation with RSU. This is a shortcoming for this design because overhead will occur on RSUs for large amount of vehicles and their several solicitations. On the other hand, this proposal presumes that A, B and C will stay in a same way to complete the task and there is no dissemination among them. But in the real streets, dispersion may occur because of intersections, crossroads or traffic lights.

Arkian et al. [12], have proposed A Fuzzy Clustering-based Vehicular Cloud Architecture (FcVcA) to solve some inherent drawbacks such as overhead on RSUs. According to FcVcA, we should gather vehicles in some separated hypothetical clusters and then find the most proper CH for each cluster using fuzzy logic with some various factors like RSU link quality. By this method, we can see remarkable reduction of overhead on RSUs and because of most proper CH, based on simulation results we build a sufficient cluster to get data with lower data loss in comparison with other similar approaches. This method has some shortcomings, too. FcVcA is much suitable for highways and roads without intersections and any dissemination at crossroads and it has no idea to solve data loss on intersections. Another shortcoming is absolutely overhead on CH. Although we have well reducing overhead on RSUs, most of their tasks are shifted to CH. It is however, better than RSUs because the number of vehicles in a cluster is less than the number of vehicles included in working range of each RSU, but for large amount of requests in the cluster, overhead may occur on CH.

The most similar approach to our proposal has been presented in [13]. In this approach, we use clustering method. Therefore, we select the most proper CH for each cluster using improved FcVcA, at first. Then, by using Genetic algorithm, the most adequate chromosome\(_{x}\) for data applicant X is generated, assisted by CH. After that, data is divided and some parts are moved to chromosome\(_{x}\) and other segments are transferred to X concurrently. The chromosome\(_{x}\) in this approach is a set of vehicles in a same cluster with X which the probability of their behavior at crossroad is almost similar to X. When dissemination occurs among cluster members at a crossroad, the rest segments of files which have not transferred yet will move from chromosome\(_{x}\) to X. By this method, based on its simulation results, data loss for huge files will be reduced at crossroads remarkably. Although this proposal has a sufficient solution for reducing data loss at crossroads, this method has been simulated on the Manhattan model without traffic lights on each intersections and it is a shortcoming for this proposal. Also, because of many processing and calculations, overhead on CH may occur and it includes another shortcoming for this proposal.

To simulate our proposed approach, we have considered the reality. Therefore, we simulated our proposal in such real plan with the real scales. As depicted in Fig. 11, the simulation area is in zone eleven of Tehran city which contains a part of Jomhouri and Enqelab Avenue and also some other related streets and roads [23]. Both of Jomhouri and Enqelab Avenue are the famous roads in the middle of Tehran.

For simulating our proposed approach, we use both OMNet++ [24] as a network simulator and SUMO [25] as a traffic simulator. These tools connect and work together using VEINS [26].

As Fig. 12 shows, our simulation area contains 8 crossroads and their 22 related roads and also the length of each one. There are more intersections and crossroads but we use main roads. Also, our proposal needs crossroads to be equipped with traffic lights for possible evaluation. The table of branches of each crossroads and related lanes has been sorted in the Table 1.

Table 1 shows the main part of Crossroad Conditions for the simulation area. For instance, at crossroad A, there are two lanes for going out from A via \(\hbox {A}_{1}\) and two lanes for coming into A via \(\hbox {A}_{1}\) and also, at crossroad G, there are three lanes for going out from G via \(\hbox {G}_{2}\) and there is no lane for coming into G via \(\hbox {G}_{2}\).

According to Table 1 and this simulation area, we have 22 roads and 68 lanes of which 18 lanes are for the input of the vehicles in this simulation scenario. Also it contains 8 equipped traffic-light crossroads. We presume all vehicles are equipped with transmitter radio that supports IEEE 802.11p and IEEE 1609 [27] standards. In addition, we assume Poisson distribution in traffic ratio [28]. The total time of simulation is 300s and we repeat each level of simulation for 1000 times and increase the certainty of the results using Monte Carlo method [29]. The assumptions and parameters of our simulation are sorted in Table 2.

Our simulation is focused on the content of the transferring file. We choose three contents for the mentioned file as 2MB, 4MB and 8MB to compute the probability of getting whole of file successfully. Also, we consider both factors of the total number of vehicles and the average speed of vehicles in the roads. Then, we compare our results with the similar results of FcVcA and Genetic method.

To calculate the probability of getting file (\({P}_{\mathrm{get}}\)), we use equation (16) as follows:Since \({f}_{\mathrm{suc}}\) and \({f}_{\mathrm{sent}}\) are not the independent events, we use equation (16) which \({f}_{\mathrm{suc}}\) is the set of taken files successfully and \({f}_{\mathrm{sent}}\) is the set of sent files totally [30].

For the first level of simulation, presuming the velocity of all vehicles 40 km/h, we consider the number of vehicles in the roads. Theoretically, when the quantity of vehicles increases as a resource, the total successful transferred files will increase [31]. Our results depicted in Fig. 13 show this fact. When the total vehicles increase, the probability of getting file is increased but, based on our results, we can see some differences between the results of our proposed approach and the others. The main reason is absolutely vulnerability of FcVcA and Genetic method at equipped traffic-light crossroads. Although Genetic method has a solution at crossroads to reduce data loss, we should consider that Genetic method has not any solution for traffic lights and, therefore, dissemination may occur in clusters because of traffic lights. On the other side, FcVcA has not any solution even at crossroads and fragmented clusters. Therefore, it is reasonable if we see data loss in this proposal.

Our explanations for Fig. 13 can explain Figs. 14 and 15. But with a closer look, we can see if the size of packet increases, the diagram of our proposed approach and genetic method will take some more distance with FcVcA diagram. Although the Genetic method has vulnerability at equipped traffic-light crossroads, FcVcA has not seen crossroads in its proposed approach and this is the main reason for this meaningful distance between FcVcA diagram and the others when the size of file increases.

The next level of our simulation is focused on the velocity of vehicles. It is reasonable if the total velocity of vehicles increases, then data loss in vehicular cloud computing would increase. It is sufficient for us that we reduce data loss concurrently when the total speeds of vehicles increases. Figures 16, 17 and 18 declare our simulation results about the probability of getting file successfully when the total velocity of vehicles increases. As we can see in these diagrams, when the total velocity increases, data loss increases on all compared methods. Although data loss is increased totally, the probability of data loss in our proposed approach is less than others remarkably. When a file is divided, each part is smaller. Therefore, the chance of getting it is increased. On the other hand, gathering all split parts of a file among some vehicles and merging them is difficult and it causes data loss to increase even when a part of a file is missed. All compared methods support this solution. But at crossroads the probability of data loss is increased because we have disseminations among vehicles. Hence, our proposed approach increases the probability of getting a file successfully because it can reduce data loss in comparison with other similar compared methods.

Based on our proposed approach, having the adequate overhead is questionable in comparison with FcVcA and Genetic Method because we have many calculations and V2V and V2I negotiations to find sufficient CHs and cluster vehicles adequately.

To calculate and compare this factor, we should define the Control Overhead. Control Overhead is defined as the ratio of the total number of control messages to the total number of packets to make a cluster.

Figure 19 shows the comparison of this ratio among our proposed approach, FcVcA and Genetic method. As we can see, even though all three diagrams are really close together, the control overhead of NeCl has fewer ratios. Based on the control overhead for 10 and 45 km/h, although our proposed approach has many calculations and V2I and V2V dialog to perform the clusters, sub clusters and CHs, many calculations of Fuzzy logic increase the Control overhead of FcVcA and Genetic method. This is one of our main reasons to use the other method to calculate instead of Fuzzy logic in our proposed approach.

At first, we defined MCC and VANET and also, detailed them and their relations. After that, we introduced and described some related woks in this field. Then, based on clustering method in VANET, we introduced NeCl in VANET. Furthermore, using NeCl, we presented our proposed approach to reduce MCC data loss at crossroads, especially the equipped traffic-light crossroads using nested clusters, their adequate CHs and the crossroad conditions based on NeCl. Finally, we depicted and detailed the diagrams and schemes of our simulation results in comparison with two other similar methods.