Cloud Computing-Based Message Dissemination Protocol for Vehicular Ad Hoc Networks

. A Vehicular Ad Hoc Network (VANET) is a rapidly evolving ﬁeld with growing 5th generation mobile networks and peer-to-peer services to deliver both safety and traﬃc beneﬁts. However, message transmission in VANET suﬀers from several disadvantages such as the frequent intermittent connectivity because of high velocity of VANET vehicles and to their limited capacity in terms of bandwidth. To ensure reliable connectivity, we propose in this paper, a new message dissemination protocol for VANET based on cloud computing, called Cloud computing-based message Dissemination protocol for VANET (ClouDiV). Considered as a geographic protocol, ClouDiV provides an adaptive dissemination of safety and non-safety messages through a cloud computing architecture. Simulation results taken with ns-2 in realist urban settings showed that ClouDiV improves the connectivity performances criteria in spite of network size.


Introduction
Advances in wireless communication technologies have increasingly interested in smart vehicles equipped with communication capabilities, processing and computing devices, sensors, aiming to improve road safety (collision avoidance, driver assistance, emergency management, etc.) and to satisfy computational services requested by passengers with certain level of reliability, scalability, efficiency, and security.To support these challenges, several vehicular technology companies have provided many innovative vehicle services to the customers through a special kind of wireless mobile networks named Vehicular Ad-hoc Network (VANET).A VANET consists of a set of mobile nodes (i.e.Vehicles) and fixed nodes known as Roadside Units (RSUs).The two main functionalities of a VANET is to support communication between vehicles through Inter-Vehicle Communication (IVC) and between vehicles and RSUs through Vehicle-to-Roadside Communication (VRC), often using Global Positioning System (GPS) integrated into vehicles to facilitate location-based services [1].Some of the important properties of VANET that affects communications is the high speed of the vehicles, limited computational capacities of onboard computers, area restrictions (such as buildings, tunnels, etc.), high congestion of channel due to the high density of vehicles in some roadways.Therefore, these properties lead to a network with intermittent transmissions, topology change, frequent fragmentation, and small effective diameter that make message dissemination a challenging task in this kind of networks [2].
To deal with this accidental connectivity, we propose in this study a new message dissemination protocol for VANET called Cloud computing-based message Dissemination protocol for VANET (ClouDiV).To the best of our knowledge, there is no cloud computing-based protocol which has been proposed for message dissemination in VANET, despite the few attempts at integrating cloud computing with vehicular networks.ClouDiV put the advantages of cloud computing available to forward data packets between VANET nodes in an efficient way, which improve safety and non-safety message transmissions according to various dissemination metrics.Also, digital requests of car drivers and passengers could be satisfied by the various cloud computing services such as processing, storage, and bandwidth.
Cloud computing is a new computing model consisted of a pool of physical compute resources such as processor, memory, and network bandwidth, potentially distributed physically across big servers known as data centers.The data centers can be organized on demand into a dynamic logical entity that can grow or shrink over time, to satisfy computational requests of end users including performance, reliability, cost, and security, usually through the Internet against a leased resource fee [3].We note that the various vehicular devices such as onboard computers, passenger smartphones and, personal digital assistants could be considered as mobile data centers helping to provide more cloud services [4].
So that the transmission receives benefits from the Cloud, ClouDiV proposes that all available cloud resources namely, bandwidth of different end users (i.e. car drivers, passengers, traffic authorities, etc.) contribute to disseminate messages between VANET nodes.Mainly, ClouDiV is considered as a geographic protocol that disseminates messages through an adaptive connectivity process based on data centers of the cloud.Moreover, this protocol uses a particular kind of packet transmission known as stochastic broadcasting [5] when it launches the route discovery phase, which is in hybrid mode (proactive and reactive route discovery) as described below.
In order to validate this proposal, a set of ClouDiV simulation experiments are carried out in ns-2 [6] extended to the cloud computing infrastructure by the framework greencloud [7].These experiments are compared with a reliable inter-vehicular routing protocol for vehicular ad hoc networks (RIVER) [8] in terms of average end-to-end delay, packet delivery ratio, and routing overhead.
The rest of this paper is organized as follows.In section 2, we present an overview of the vehicular cloud computing.Section 3 reviews and discusses the existing studies in which the cloud computing has been applied to disseminate messages in vehicular networks.Section 4 describes the proposed protocol, fol-lowed by section 5 that demonstrates the simulation study and depicts the results obtained by our solution, and compared to those reached by RIVER protocol.Finally, section 6 concludes and outlines some future research directions.

Cloud Computing for VANET: Definition and Architecture
As introduced in [9], Cloud Computing for VANET (VANET-Cloud model) is defined as a new cloud computing infrastructure, consisted of an important number of computing nodes including stationary data centers, as well as a set of mobile computing devices installed onboard of vehicles such as onboard computers, passenger PDAs, onboard computers of traffic authorities, and so on.VANET-Cloud takes advantage of cloud computing resources and services to better serve VANET users (i.e.drivers and passengers) in terms of providing digital resources such as processing, storage, bandwidth, with very low cost.
As shown in Fig. 1, the VANET-Cloud model is formed by two sub-models: the permanent (stationary) cloud sub-model consisting of data centers, and the temporary (mobile) cloud sub-model that is composed of vehicles computing resources.On the one side, the permanent VANET-Cloud takes advantages of the conventional cloud and makes them available to VANET entities such as vehicles and RSUs.On the other side, the temporary VANET-Cloud renders the computing resources of VANETs such as onboard computers, passenger devices, and transportation servers, possible to a client against a rent price.Nowadays, some recent research works have proposed the use of the cloud computing to tackle with vehicular network issues.
Among these studies, we can cite a new routing scheme called VehiCloud [10], which is established to deal with unreliable inter-vehicle communications and to extend the restricted computational capabilities of vehicle devices using a cloud computing architecture.To ensure routing service, VehiCloud models the highly dynamic network topology as a time-space link graph taking into account a time dimension, lacked in a conventional network connectivity graph.This scheme proposed that each vehicle predicts its future locations by generating way point messages, which describe the trajectory of the vehicle's movement.These way point messages are collected by a decision module established on a cloud infrastructure that is responsible for making routing decisions for inter-vehicle communication.More specifically, this cloud-based module selects paths in terms of message delivery ratio by respecting the constraints of end-to-end delay and communication cost.We can suggest that further routing improvements could be brought if VehiCloud takes advantages of conventional cloud capabilities.
In [11], another issue has been addressed and solved by making use of the cloud computing infrastructure which is the seamless access to the Internet.To achieve this, a cloud-supported gateway model, named Gateway-as-a-Service (GaaS) was proposed to provide efficient gateway connectivity and to enhance the usage experience of Internet for vehicular networks.GaaS proposed that a specialized cloud servers are conceived to ensure the gateway functions including gateway registration, discovery, selection, dispatching, and handoff.Despite, this global functionality, GaaS focuses primarily on the Internet connection, and did not consider digital resources of vehicles.
The vehicular network literature mentions another vehicular cloud-based scheme called Vehicular Cloud (VC) model [12].Defined as a new mobile cloud computing model, VC is formed by the aggregation of underutilized vehicles' computing resources such as processing, storage, sensors, Internet connectivity, which can be available to drivers or rented out over the Internet to different customers.A simulation study of VC has shown that increasing network density leads to a lower delay on the transmission.However, VC didn't take into consideration the effect of storage and its structure can be extended to take advantage of stationary cloud capabilities.
In [13], three major cloud entities were proposed: Vehicular Cloud (VC), Vehicles using Cloud (VuC), and Hybrid Cloud (HC).In this research activity, VC is divided into two scenarios: the former is a static cloud referring to stationary vehicles and providing cloud services, and the latter is a dynamic cloud, which is set up on demand in an ad hoc manner.Moreover, VuC allows the vehicular network to connect to the cloud through the RSUs, whereas, the HC is the combination of VC and VuC.It is worth mentioning that this proposal requires that the vehicle computing resources didn't belong to VC only if these vehicles are in a stationary state.
To deal with the human security issues of car drivers, authors of [14] proposed another cloud model called vehicular cloud (abbreviated V-Cloud).The architecture of V-cloud is a set of three vehicular network layers including incar Vehicular Cyber-Physical System (VCPS) of sensors, Vehicle-to-Vehicle network (V2V), and Vehicle-to-Infrastructure network (V2I) layer.VCPS sensors are responsible for ensuring driver security by incorporating context awareness, healthcare monitoring and mood detection of the vehicle driver while driving.The authors concluded that V-Cloud can offer real-time services, aiming to improve drivers safety and comfort degree especially, in circumstance when driver is not healthy and comfortable enough to drive.In order to get quick responses to these critical cases, V-cloud could be expanded to take advantage of the computing devices installed onboard of vehicles.
A pure Cloud formed by vehicle computing components has been proposed in [15].It is a new service concept known as Sensor as a Service (SenaaS) that put the components of vehicle communication platforms (VCPs) (such as sensors and computing devices) available to third-party vehicle monitoring applications.Despite the successful development of a SenaaS prototype over a VCP that supports real-time intelligent truck monitoring services on about one thousand tank trucks for fuel distribution, this study can offer more interesting results in the case of considering computing power of traditional cloud computing.
A new approach that exploits the use of a RSU as a cloud servers, was proposed in [3].The authors proposed that a RSU can act as a cloud directory that stores information about the available computing resources of vehicles (e.g., bandwidth, storage capacity) in its transmission range.This scheme suggested that every RSU will share with its neighbor RSUs, the computing information of its vehicles, so that the operation area of the proposed cloud will be increased.
To provide safety and non-safety services in vehicular applications, Vehicular Cloud for Roadside scenario (VCR) was proposed in [16].VCR offers these services through public and private vehicular clouds.The public vehicular cloud is a part of RSU, where the private one is formed by OnBoard Units (OBUs) of vehicles.To deploy VCR, the authors proposed that Google App Engine Cloud environment may be accessed as public services.Also, Java-based Universal Description, Discovery, and Integration (JUDDI) private registry was considered as the private vehicular cloud.VCR proposed that each vehicle sets up one JUDDI private registry to communicate with each other, so that the interoperability issue produced by different OBU systems (e.g., DSRC, Wi-Fi, WAVE, WiMaX, CALM) is solved.We note that VCR could be improved by allowing direct transmission between vehicles and traditional cloud servers.

Description of ClouDiV: Our Proposal
ClouDiV is a message dissemination protocol proposed for vehicular networks, based on a cloud computing architecture.ClouDiV combines the use a fixed cloud computing infrastructure (i.e.data centers) and a flexible cloud structure based on onboard computers of vehicles.Therefore, the computing powers of both permanent and temporary vehicular cloud structures can be available in benefit of various consumers by offering much higher bandwidth compared to message dissemination schemes based on pure vehicular network infrastructures.
In this proposal, we assume that the vehicular network is formed by different VANET nodes (i.e.vehicles and RSUs), as well as the various cloud servers (i.e.data centers) located in the traffic environment.ClouDiV is considered as a hybrid message dissemination protocol, where a proactive approach is suggested to be applied by each data center in order to discover fresh and updated routes toward each node in the network.Furthermore, a reactive approach is defined to be performed by each vehicle aiming to find the nearest data center as an intermediate node, which could quickly provide a fresh route toward the desired destination.In the following subsections, ClouDiV is explained, starting with the used routing tables, then the various ClouDiV phases are presented.

ClouDiV Routing tables
Due to the distinction between used nodes in this dissemination approach (i.e.data centers and VANET nodes) in terms of functions, computing power, storage space, transmission bandwidth, we propose the use of two different types of routing tables: data center routing table and VANET node routing table.Each type implies the use of a particular kind of a routing process, as explained below.

Data Center Routing Table:
Owning to the stationary nature of the data center and its huge capacities of processing and storage, as well as its very large transmission range, we propose that each data center is equipped of a routing table consisted of a set of entries.Each entry is devoted to one destination node in the network, in which the entire route (from this data center to the destination) is saved.Moreover, various transmission parameters such as the average end-to-end delay and the average bandwidth are also memorized.
The data center performs periodically a proactive route discovery in order to update its routing table.Therefore, any future use of the saved routes does not be affected by an additional delay, caused by launching a new route discovery.Figure 2 shows an example of a vehicular network with two data centers, where routing table of data center DC1 is presented in Fig. 2a.: Each VANET node possesses its own routing table, which is consisted of a set of entries, each entry is dedicated to one destination (if requested) that can be a data center or a regular VANET node.More specifically, each entry contains the destination identifier and the identifier of next hop node toward the destination.The idea of saving the next hop instead of saving the entire route is to reduce the memory space of this routing table, since these nodes (onboard computers) possess limited computing resources.Also, each routing table entry includes the link delay and bandwidth information, a hop count field indicating the number of hops to reach the destination, which could be used to choose the shortest path if there is more than one path to the same destination.The routing table of node S is presented in Fig. 2b.This phase aims to ensure an update of routing tables using beacon packets, transmitted periodically.As a result, active links between each VANET node and each data center are updated, by refreshing different transmission parameters such as the available bandwidth and the measured end-to-end delay.Also, routing information between VANET nodes is also saved and updated in order to perform a conventional routing (i.e.without the help of the cloud computing infrastructure) in the case of lacking data centers.We note that a link is marked as invalid in a routing table if a node does not get information from the nodes neighbor for a specified amount of time.Thus, the other nodes are informed of this unavailable link using an error packet.

Route Discovery Phase :
When one node desires to disseminate messages to a destination, it first checks whether the route is present in its routing table, then the source node starts disseminating data packets, otherwise data packets are buffered until a valid route is discovered.To discover a route, two complementary processes are applied: a proactive routing and a reactive routing.The source node starts with a reactive (on-demand) routing in order to find a data center.As shown in the example presented in Fig. 3, the source node S starts a reactive routing when it decides to disseminate messages to node D. Accordingly, path (S-1-2-DC1) is discovered.Afterwards, the data center DC1 uses the path (DC1-DC2-6-D) to reach the final destination D, which is discovered after performing a previous proactive routing.a. ClouDiV Proactive Routing: This process is performed by each data center in the network aiming to find all routes from this data center toward every node in the network (supposed as a prospective future destination).Therefore, these routes can be used by any node in order to transmit data toward a destination via this data center.To achieve this, the data center generates a particular control packet called Routing Information REQuest (RI-REQ) aiming to gather different routing information concerning all nodes in the network, including the active links, next-hop node toward a destination, position and velocity of a node.
A RI-REQ is broadcasted periodically to the neighbor nodes of data center then, the neighbor node forwards this RI-REQ to its neighbors, except for neighbors which are data centers expected to conduct their own proactive routing process separately.Each node receives a RI-REQ, generates a new control packet named Routing Information REPly (RI-REP) containing the requested routing information, which is forwarded to the original data center (i.e. the sender) through the reverse route.In its turn, the data center refreshes its routing table entries with the received information hence the updated routes are ready to be used to disseminate messages toward any destination.
In Fig. 4, DC1 generates and broadcasts periodically a RI-REQ to its immediate neighbor nodes (i.e.nodes 3, 6, and DC2) then, each node rebroadcasts the same RI-REQ to its neighbors, except to DC2 that launches its own proactive routing separately.When a node received a RI-REQ, it generates a RI-REP and sends out it to DC1 to communicate its refreshed routing information such as the active links, nodes ID toward a destination, next-hop node toward this destination, the position and velocity of this node.After receiving all RI-REPs, DC1 updates its routing table and constructs entire routes toward various destinations.For example, to reach node 8, DC1 sends out data packets through the route (DC1-DC2-8).ClouDiV Reactive Routing: To disseminate messages to a destination node, a Route REQuest packet (RREQ) is generated by the source node only if needed (on-demand).This RREQ is launched and broadcasted stochastically to the immediate neighbors of the source node in order to find a data center which knows the destination path.Stochastic broadcasting means that the RREQ is transmitted to a limited percentage of neighbor nodes that is enough to find a data center that knows the destination.This kind of broadcasting is applied to reduce the routing overhead caused by the control packet flooding [6].
The RREQ packet is identified by an identifier (ID) and includes the source node ID, the destination ID, and the maximum lifespan of the route request.Also, this packet records a hop count initialized with zero value and incremented while encountering an intermediate node until discovering the data center.Every encountered intermediate node checks also, if it has already received this RREQ packet (using the RREQ ID), if so, the RREQ will be dropped otherwise, this intermediate node records the RREQ ID and the source node ID in the appropriate routing table entry.Afterwards, the intermediate node checks the existence of a route toward a data center in its routing table.If it is not the case, the current node rebroadcasts the RREQ packet in the same manner such as the source node.However, if a route to a data center occurs in a routing table, the intermediate node generates a Route rePly packet (RREP) which will be forwarded to the source node along the same path in reverse.
Likewise, RREP packet records the next hop node at the routing table of each visited node to indicate its sender until reaching the source node.Consequently, the source node can start disseminating data packets to the discovered data center through the next hop node found by ClouDiV reactive routing process.After that, the data center sends out these data packets to the final destination using the entire route found by ClouDiV proactive routing process.
Figure 5 shows a reactive routing process executed by node 2 that wants to disseminate data packets to node 8. First, node 2 generates and broadcasts a RREQ packet to its immediate neighbor nodes using a stochastic broadcasting.Here, we assume that only 3/4 of these neighbors receive the RREQ packet (i.e.nodes 1, 3, and 4) to perform a stochastic broadcasting.In its turn, each neighbor that received the RREQ and did not know the route to a data center, rebroadcasts this same RREQ packet to its neighbors, until reaching the first data center like DC1 in this example.
After reaching DC1, this data center generates a RREP and sends it out to node 2 along the reverse route.Hence, node 2 is informed that it could disseminate its data packets to node 3 as next hop node then, the node 3 can transmit data packets to DC1.After receiving data packets, DC1 can forward them to node 8 using the route (DC1-DC2-8) found by its last proactive routing process.

Mobility Model and Parameter Settings
To cope with the reality aspect of this simulation, we have developed a mobility pattern representing the downtown of Biskra city in Algeria with a surface area of 1500 x 1500 square meters, as presented in Fig. 6.In the studied network, two scenarios of 50 and 75 mobile nodes (vehicles) moving with a speed chosen randomly between 1 and 20 m/s are considered, as two different vehicular network densities.For each scenario, 10 RSUs distributed uniformly, as well as 1 data center located at the center of the studied area, with a transmission range of 1000 meters and a transmission power of 16 dBm are introduced.The data center is based on a three-layer network with 1 switch in the core network, 2 switches in the aggregation network, and 3 switches in the access network.Moreover, 18 servers are physically attached to the access network with 1 Gigabyte/s of bandwidth.According to IEEE 802.11p standard (Wireless Access in Vehicular Environments -WAVE-) proposed specifically for VANETs, these scenarios were simulated during 500 seconds, with the TwoRayGround propagation model.We have used the Transmission Control Protocol (TCP) as a transport layer protocol where a packet has a size of 1000 bytes.The number of bytes transmitted per second is fixed to 0.01 Mbytes.In this study, we have considered the File Transfer Protocol (FTP) as an application layer model with 25 vehicles act as source nodes whereas, the remaining vehicles constitute the destinations.

Significant Results and Discussion
In order to measure the quality of message dissemination in a vehicular network, ClouDiV is evaluated following the traffic safety metrics: the average end-to-end delay, the Packet Delivery Ratio (PDR), and the Normalized Overhead Load (NOL).These metrics are explained in [17].We have compared the performance of our proposed with the Reliable Inter-VEhicular Routing (RIVER) protocol proposed for VANETs.Simulation results are depicted in Fig. 7 -9.
As shown in Fig. 7, ClouDiV disseminates data packets with a decreased end-to-end delay.It is due to the time saved by the proactive routing process performed by the data center.In fact, the requested routes are still discovered by the data center and ready to be used, even before that, the source node desires to disseminate packets, this is the reason of reducing the delay, often caused by the discovery process launched after requesting a new path.The observed packet delivery ratio values presented in Fig. 8 demonstrates the good delivery of packets ensured by ClouDiV in comparison with RIVER protocol.This is because of the use of routes with an extra large bandwidth, offered by the cloudbased infrastructure.Nevertheless, RIVER disseminates data packets through an ordinary path with a limited bandwidth hence, several packets might be dropped.Figure 9 gives a look at the normalized overhead load in which ClouDiV leads to a non congested network due to the stochastic broadcasting that generates a reduced number of control packets compared to an exhaustive broadcasting process such as employed by RIVER protocol.

Conclusion and Perspectives
In this study, we have proposed a new message dissemination protocol for vehicular ad-hoc networks based on cloud computing infrastructure, called Cloud computing-based message Dissemination protocol for VANET (ClouDiV).This protocol is considered as a hybrid protocol that applies on the one hand, a proactive approach in data centers in order to discover routes ready for use in a future message dissemination.On the other hand, a reactive routing is applied by the other nodes, only if these nodes desire disseminating messages.To evaluate the performance of ClouDiV, an extensive experimental study was conducted in terms of the average end-to-end delay, the packet delivery ratio and, the normalized overhead load.These experiments were performed under a cloud computing infrastructure and the obtained results were compared to RIVER protocol proposed for vehicular networks.
We conclude that this study indicates clearly that ClouDiV provides a reduced end-to-end delay and, an increased packet delivery ratio.Moreover, message dissemination with this proposal leads to a less congested network.We note that this Cloud-based message dissemination protocol can offer a number of desirable features such as the use of more computing capacities and various cloud computing services (i.e.processing, storage, bandwidth, platforms etc.).Also, vehicles use less power than with a pure VANET, since data centers are widely used to forward data packets due to their larger coverage area and to their important bandwidth.As a future work, we will investigate the dissemination issue of a large amount of data such as video streaming for providing safety and non-safety services, in particular on very large scalable vehicular networks.

Fig. 6 .
Fig. 6.Map of mobility scenario of the downtown of Biskra city