A BROADCAST BASED ROUTING PROTOCOL FOR INTER-CLUSTER DATA DISSEMINATION IN VEHICULAR COMMUNICATION

Vehicular communication is one of the fast growing and promising technologies for a safe and comfortable driving environment. These technologies do not end up with economic and safety ramifications, but also extended with other informational and entertainment oriented services. Data are being propagated multi-hop between source and destination vehicles for many real-life applications. Clustering is one of the effective and scalable solutions for data dissemination in wireless ad hoc networks. Though many cluster-based methods have been proposed for multi-hop data delivery in vehicular ad hoc networks, most of them do not consider the real-time changes in the network topology or imposes large penalties in routing such as unstable clusters, broken links, updating route tables. In order to address these issues, we propose a broadcast based routing protocol for inter-cluster data dissemination in this study that works on real-time vehicle information. Unlike, most existing routing algorithms, it only uses hello messages to obtain routing information without many other control messages. In addition, it alleviates the storage of routing information in every node, which largely reduces the overheads in routing. We performed extensive simulation to demonstrate the effectiveness and efficiency of the proposed routing protocol. Results show that the proposed protocol outperforms other approaches in terms of average delay, average delivery ratio and average number of hops.


INTRODUCTION
Vehicular Ad Hoc Networks (VANETs) are generally derived from Mobile Ad Hoc Networks (MANETs) that are a class of infrastructure-less network architecture. A cluster based vehicular communication comprises of a collection of highly dynamic vehicles that communicate with each other through multi-hop wireless links without the need for any central management. This high mobility nature acts as a promising character for multi-hop data delivery within the identified road networks in VANETs.
Multi-hop data delivery is useful for many applications where a moving vehicle may want to query a fixed location-based service provider such as a shopping mall for some sale information or a gas station for fuel prices. Alternatively, a vehicle may also want to contact a region several miles away from its current position, where there are no fixed locationbased servers. For example, the vehicle may be interested to know the available parking spaces or current traffic conditions in a region. In such case, the query will be forwarded from the current region to the desired destination through multi-hop broadcasting. However, in either case, considering the real-time traffic and the dynamic traffic conditions to route the data packets is a highly challenging issue for timely and cost effective data dissemination (Syed et al., 2013).
Hence, data dissemination between vehicles requires efficient and real-time routing algorithms. A routing protocol is said to be efficient, if it is able to deliver the data to a destination with minimum delay (Syed et al., 2013). The algorithms employed for routing must be resource saving and of low overhead, in order to ensure Science Publications JCS more effective operations (Wang et al., 2008). According to Abbasi and Younis (2007), clustering methods allow fast connection, better routing and topology management in mobile ad hoc networks. Though, there are cluster based routing algorithms proposed for VANETs, frequently changing cluster heads lead to highly unstable routes. This produces a lot of communication overhead through route repair and maintenance processes and eventually increases the end-to-end delay. Therefore, we propose a BRoadcast based Inter-Cluster routing protocol (BRIC) that provides the real-time vehicle information to support effective routing between vehicles through a more stable dual-head clustering algorithm.

Related Works
Data dissemination through routing has been widely studied for VANETs. MANET protocols such as Ad-hoc on Demand distance Vector routing (AODV) proposed by Perkins and Royer (1999), Optimized Link State Routing (OLSR) proposed by Sondi et al. (2013) had been used for VANETs in the early stages. AODV is a reactive routing protocol that uses hop-by-hop routing, sequence numbers and periodic beacons thereby reduces the periodic control message overhead associated with proactive routing protocols. OLSR is a proactive routing protocol that uses Multipoint Relays (MPRs) to forward broadcast messages during flooding process in order to reduce the retransmission of duplicate packets. However, they could not suit well due to the high dynamic topology of VANETs. Consequently, researchers proposed a variety of routing protocols such as position based, geo-cast based, broadcast based, infrastructure based and cluster based routing protocols. Some of them are discussed as follows.
Position based routing: Karp and Kung (2000) proposed Greedy Perimeter Stateless Routing (GPSR) a popular routing protocol for wireless network. Later, Lochert et al. (2003; studied GPSR for its limitations and came up with a combination of position and topology based protocol, GSR and a new data delivery technique called Greedy Perimeter Coordinator Routing (GPCR).
Geocast based routing: It is a special type of multicasting. The basic idea of this type of routing is distributing message from the source node to some nodes in a special geographical region. Inter-Vehicles Geocast (IVG) protocol proposed by Bachir and Benslimane (2003) and Robust Vehicular Routing (ROVER) proposed by Kihl et al. (2007) are examples of this type.
Broadcast based routing: This is the simplest routing way widely used for VANETs. However, it causes contentions and collisions, which would affect network performance. Urban Multi-Hop Broadcast protocol (UMB) proposed by Korkmaz et al. (2004) is one of the protocols that use broadcast to distribute packets. The major drawback of this type of protocols is that they suffer from broadcast storm problem.
Infrastructure based routing: Wu et al. (2013) proposed a moving direction and destination location based routing (MEDAL) algorithm, which takes the moving directions of vehicles and the destination location to select a neighbor vehicle as the next hop for forwarding data. Nzouonta et al. (2009) proposed a set of Road-Based Vehicular Traffic routing (RBVT) protocols, areactive protocol RBVT-R and a proactive protocol RBVT-P that leverage real-time vehicular traffic information to create paths consisting of successions of road intersections. Punithavathi and Duraiswamy (2010) proposed a Client-Server based mobile agent for fast reponse and information reteival. However their protocol requires more server units to store and backup the data. Though most of these algorithm ssupports both V2V and V2I communications, they requires all vehicles to store the periodic hello beacons of other vehicles and also depends on the support of intersections.
Cluster-based routing: This type of routing is mainly suitable for networks with a large number of vehicles. Most of the clustering algorithms are based on vehicle ID or mobility. However, some algorithms such as Clustering for Open IVC Networks (COIN) proposed by Blum et al. (2003), which selects a cluster head based on vehicular dynamics and drivers' intentions and Location Routing Algorithm with Cluster-Based Flooding (LORA_CBF) proposed by Santos et al. (2005) are different from them. Kuppusamy and Kalavathy (2012) proposed an Adaptive Push and Pull Algorithm for Clusters (APPC) and Cluster Based Data Consistency (CBDC) approach to address the consistency requirements and maintenance in mobile ad hoc network.
In our study, a broadcast Based Inter-Cluster Routing protocol (BRIC) is proposed as a tradeoff between proactive and reactive routing protocols.

System Model
Clustering problem can be defined as an undirected graph G = (V, E); where V represents a communication

JCS
network and G is the vertices which are nodes or vehicles in the network and E is the edges of the communication links. The clustering process divides V into a collection of subsets {V 1 ,V 2 ,…V n } which not- n V i such that each subset V i induces a connected sub graph of G.

Clustering Algorithm
Generally, cluster based routing requires a highly stable clustering algorithm to create and maintain clusters. In order to create more stable clusters, we propose a dual head-clustering algorithm, where each cluster will have two heads namely a cluster-head and an auxiliary cluster-head. Figure 1 depicts the network model of the proposed clustering algorithm. The purpose of the auxiliary cluster-head is to hold the cluster members with the same cluster even when the clusterhead is lost or leaves from the cluster. For this purpose, some information like route tables (maintained by the cluster head) will be shared with the auxiliary cluster head periodically.
Cluster Head Election: We adopted a weight based clustering algorithm (Chatterjee et al., 2001) for the purpose of cluster-head election. However, a different set of parameters: The relative distance D rel (mean distance from its one-hop neighbors), relative speed S rel (speed difference of the node from the mean speed of all the neighbors) and node variation V (difference between the nodal degree and the member handling capacity of the node) are proposed in this scheme. These values are put together to calculate the combined weight metric of that node. The combined weight is calculated as: where, wt 1 +wt 2 +wt 3 = 1. During cluster formation, each node broadcasts its weight and the node with the lowest weight is elected as the cluster-head. Auxiliary Cluster Head: Once the cluster-head is elected, it immediately goes for an auxiliary cluster-head selection. The node that has the second lowest weight is chosen and announced as an auxiliary cluster-head for that cluster. The auxiliary cluster-head acts as a normal member as long as the cluster-head is active. In case, the auxiliary cluster head receives a leave message from the cluster-head or does not receive any communication from the cluster head for a predefined threshold, it takes over the responsibility and announces itself as the head of that cluster. If the new cluster-head is the one that was already announced as the auxiliary cluster-head, other nodes accept that and continue to be in the same cluster.

Broadcast of Real-Time Traffic
In VANET, all nodes/vehicles periodically broadcast hello messages including their position, velocity information. In addition to that, BRIC requires all cluster-heads to broadcast its neighbor list periodically for routing purpose. However, this neighbor-list is incorporated in their hello messages so as to reduce the additional broadcast overhead. Subsequently, all the gateway nodes collect the neighbor lists from all the cluster-heads it can hear in every t time and rebroadcast this information as an aggregated list. Similarly, the distributed gateway nodes also incorporate the aggregated list of one another into their list for subsequent broadcasts. The purpose of the cluster-heads' neighbor list and the gateway nodes' aggregated list are to keep the cluster-heads updated with the real-time vehicle information of other neighboring cluster-heads, in order to select the routes quickly and accurately. Figure 2 shows a clustering example to illustrate the pro-posed BRIC protocol. Let's consider a scenario where node 10 wants to send a data to node 2. Firstly, it sends the Route Request (RReq) packet to its CH-8. In case node 8 does not find any route to node 2, it waits for the next broadcast of its gateway nodes (nodes 14 and 7 in this case). Node 14 broadcasts the aggregated neighbor lists of nodes 12 and 8. This message would be {14, [12(11,3,13,14) || [8(7,9,10)]}. 14 here is the ID of the GW node that broadcasts the message. On the other hand, the aggregated message of the distributed GW node 7 would be {7, [8(7,9,10)] || 4,[1(2,3,4,5)]}, where (2,3,4,5) is the neighbor list of node 1 captured by the distributed GW node 4.  Through this message, the source CH 8 is able to find the route to reach the destination node 2, though it is almost 4 hops away from the source node.

Data Structure of Cluster Nodes
In BRIC, each cluster-head maintains a neighbor table and as shown in Table 1. In addition to that, whenever a RReq/RRep message is received, both the cluster-head and gateway nodes stores the route in their cache as shown in Table 2 (Fig. 2) for a threshold time to facilitate further communications. However, other member nodes are free from this information.

Route Discovery
Whenever a node in the network wants to send data to a destination, it sends the RReq message to its CH attaching the desired destination. Such that, whenever a CH receives anRReq message, it first checks if the request has already been received or traversed through it. If so, it drops the packet in order to avoid repetition. On the other hand, if it is a new request and itself is the desired destination, it sends the Request Reply (RRep) packet back to the source reverse through the route in the RReq. If not, it checks whether the source or the destination is its member.
In case of having the destination node as its member, it forwards the RReq packet to the destination. In contrast, if the source node is its member, it immediately checks its cached routes to know if the same destination has been routed recently (The cache is refreshed frequently, as the routes cannot be expected to stay longer due to the high dynamic nature of the vehicles). If there is no relevant route, the CH waits for the next broadcast from its one or more gateway nodes. Since the gateway nodes aggregate the neighbor list of all their neighboring cluster heads and gateway nodes, the cluster-heads has a higher probability to find a route if the destination is only a few hops away from the source. In such case, the CH directly sends the discovered route to the source so as to start sending data packets with no further delay.
However, if the destination is quite farther from the source node, the cluster-head inserts its sequence number and rebroadcasts the RReq to all its gateway nodes. Once the RReq packet reaches the destination it will send anRRep back to the source node. In case, if the source cluster-head detects more than one route to the desired destination, it selects the most stable route rather than selecting a shortest one. In order to select a stable route, we adopt a metric called stability function proposed by Barghi et al. (2009), which wasori-ginally derived from Link Expiration Time (LET) tech-nique. LET is a mobility prediction metric that considers the current distance and relative velocity between two nodes. Let nodes i and j are within the transmission range defined by MAC protocol and (x i ,y i ), (νx i ,νy i ) be the coordinates and the velocity of vehicle at time t. Then the link expiration time between the two nodes can be calculated as: LET ij = −(ab + cd) + (a 2 + c 2 )r 2 − (ad − bc) 2 a 2 + c 2 where, (a = νx i -νx j , b = x i -x j , c = νy i -νy i , d = y i -y i ). A large value of LET implies a more stable link. However, LET ij can reflect the mobility prediction only when the velocities of all nodes are fixed, which is not possible in real-time. In order to overcome this, the stability function S ij is proposed, which can be computed as follows: where, δ is a constant deciding the rising rate of δ ij . The stability function maps S ij to (0, 1), which is more scalable than, whose range is from LET ij 0 to ∞.

JCS
Therefore, larger S ij indicates a more stable link. In Bric, if the source CH finds more than one route to the destination, it rebroadcasts the RReq message to each of the found routes. When the RReq packets reach the destination, it sends aRRep message back to the source following the sequence number in the RReq packet by attaching its mobility information. Each forwarding node uses this field together with its own mobility information to calculate the stability of the link and updates the RRep packet with S ij and its mobility information. The detailed working of BRIC is explained in algorithm1.

Route Repair
In case a node is unable to connect the next forwarding node to forward route or data packets, it performs the conventional carry and forward approach by buffering the packets with itself until it finds the next suitable node to forward the data rather than sending a route error message to the source node. This reduces the cost of new route discovery by the source node each time a link breaks.

RESULTS AND DISCUSSION
This section presents the evaluation results of the BRIC protocol using the network simulator NS-2. In order to evaluate the performance of the proposed protocol, average delivery ratio, average end-to-end delay and average number of hops are chosen as evaluation metrics. The simulation parameters are summarized in Table 3. We compare the performance of BRIC protocol with other four popular MANET and VANET protocols such as AODV (Perkins and Royer, 1999), OLSR (Sondi et al., 2013), GSR (Lochert et al., 2003) and RBTV-R (Faria et al., 2009) where AODV and OLSR are the reactive and proactive routing protocols of MANET respectively; GSR and RBTV-R are the position-based and road-based reactive routing protocol of VANET respectively.

Average End-to-End Delay
The average delay incurred during the successful delivery of data packets from source to destination is referred to as the average end-to-end delay. Figure 3 shows the average end-to-end delay of all the protocols for different vehicle densities. It can be noted that BRIC outperforms other protocols and has the lowest delay. The delay occurred in the proactive protocols AODV and OLSR are higher due to the channel contention. Though the reactive routing protocol RBVT-R performs better than AODV and OLSR, the dependency of intersection messages significantly influences the data delivery. On the other hand, in BRIC, the vehicle information is obtained on demand through periodic broadcasts. Moreover, the aggregated lists of gateway nodes facilitate the CHs to find the real-time vehicle information quickly beyond several hops. This enables BRIC to achieve a lower end-to-end delay with a 37.5% improvement over AODV and 16.6% over RBVT-R.

Average Delivery Ratio
It is the ratio between the total number of data packets that are delivered at the destination and the total number of packets sent from the source. Figure 4 shows that, for different vehicle densities, BRIC has the highest delivery ratio. This is because; the cluster stability is significantly improved in BRIC due to the espousal of auxiliary cluster heads, in addition to vehicle clustering with relative speed and position. This reduces the ripple effect of re-clustering, which increases the overall connectivity and eventually im proves the rate of data delivery by 36% over GSR and 57.4% over OLSR.

Average Number of Hops
Average number of hops is defined as the average number of nodes that are involved during the data forwarding process between the source and the destination. Figure 5 shows the average number of hops a data packet traverses from the source to reach the desired destination for different packet rates. We can observe that AODV, OLSR and GSR have the fewer number of hops whereas, both BRIC and RBVT-R requires longer number of hops for a successful data delivery. The reason is that, in BRIC and RBVT-R, the routes with higher link lifetime are chosen rather than the shortest ones. However, increase in the number of hops does not necessarily hinder the protocol's performance but rather reduces the route repair and new route discovery processes, which is proven in the end-to-end delay and delivery ratios.

CONCLUSION
Inter-vehicle communication through multi-hop routing is a useful and preferable solution for many realtime applications. However, cluster-based routing imposes a high overhead due to the frequency of cluster formation and re-affiliation. A lot of solutions have been proposed to address this problem; still, to the best of our knowledge, there is no solution for multi-hop data propagation considering the real-time traffic information without the support of any fixed infrastructure. In this study, a new broadcast based inter-cluster communication is proposed through more stable clusters, absolutely without the requirement of any static infrastructure to educate the vehicles with the real-time vehicle information. However, this protocol requires a significant amount of communication overhead due to the periodic broadcast of aggregated CH lists by the gateway nodes. Yet, this can be neglected as the proposed regime significantly improves the overall system performance compared to other cluster based protocols and works effectively according to the results demonstrated through the simulations. For the future research, we would like to consider the security aspects related to data delivery in clusters.