Abstract
With the deployment of multimedia services over VANETs, there is a need to develop new techniques to insure various levels of quality of services (QoS) for real time applications. However, in such environments, it is not an easy task to determine adequate routes to transmit data with specific application QoS requirements. In this paper, we propose CBQoS-Vanet, a new QoS-based routing protocol tailored towards vehicular networks in a highway scenario. This protocol is based on the use of two techniques: first a clustering technique which organizes and optimizes the exchange of routing information and, second, a bee colony inspired algorithm, which calculates the best routes from a source to a destination based on given QoS criteria. In our approach, clusters are formed around cluster heads that are themselves elected based on QoS considerations. The QoS criteria here are based on the two categories of metrics: QoS metrics and mobility metrics. The QoS metrics consists of the available bandwidth, the end-to-end delay, and the jitter. The mobility metrics consists of link expiration time and average velocity difference. We have studied the performance of CBQoS-Vanet through simulation and compared it to existing approaches. The results that we obtained show that our technique outperforms, in many aspects, the approaches that it was compared against.
1. Introduction
In recent years, vehicular ad hoc networks (VANETs) have attracted the interest of researchers and car manufacturers for their benefits to the deployment of Intelligent Transportation Systems (ITS). A VANET is a network of interconnected vehicles that are able to communicate with each other and exchange relevant information. One of the main objective of VANETs is to expand the reach to Internet by commuters and to access transportation-related services while on the road. But it is the road safety and travel comfort applications that add value to vehicular networks [1]. However, with the deployment of multimedia and real time applications over VANETs, there is a need not only to route information between vehicles in an optimal way but also to select routes that are adequate for Quality of Service (QoS) requirements for these applications. QoS requirements typically include bandwidth, end-to-end delay, and jitter; but other criteria that are inherent to the nature of vehicular networks can be considered as well. In VANET where the network topology is highly dynamic, the connectivity between vehicles is constantly changing. Therefore, we should also consider the stability of routes and the life expectancy of links as a QoS metric. Providing support for QoS in such a highly dynamic environment can be a very challenging optimization problem similarly to Multiconstrained Optimal Path problems which have been established as NP-complete [2].
To solve this problem, several swarm intelligence and metaheuristic strategies have been considered. Among these strategies, the use of bioinspired artificial bee colony (ABC) technique introduced in [3] has been proposed. ABC technique is based on the biological paradigm of communication between bees when searching for food and has been shown to be an efficient tool for solving multiconstrained routing problems in static network topologies [4]. For the case of VANETs, any optimization strategy needs to take into consideration the instability of the network topology. That is, a clustering is the approach that is most suitable for enhancing the stability of the network [5], especially in the scenario of highways. Cluster formation allows the vehicular network to adapt to the changing topology of the network and to the speed fo the vehicles, therefore, allowing routing protocols to find stable paths whicle requiring little overhead of the network.
In this paper, we present CBQoS-Vanet, a QoS-based routing protocol over VANET. This research is an extension of a previous work presented in [6]. CBQoS-Vanet protocol is based on clustering and ABC techniques. The clustering algorithm is used to organize and optimize the exchange of routing information between clusters. Each cluster is formed around a cluster head, which is itself elected based on QoS considerations. That is, the routing structure itself is here tailored toward moving data based on QoS. The ABC algorithm is used here to find the best route among many routes between a source and a destination. The selection of the best route is the route that complies the most with the application’s QoS requirements. ABC operation is inspired by the behavior of bees in their search for food and by their strategy for scouting routes from the hive to various food locations. CBQoS-Vanet uses the concept of forward and backward scouting, which serves as the process for discovering the final destination. Although CBQoS-Vanet is a reactive routing protocol, it is, however, equipped with a caching scheme that allows routes to be proactively discovered without completing the full scouting process. In this study, we consider the case of a highway scenario with two categories of QoS: QoS metrics and mobility metrics. The QoS metrics consists of the available bandwidth, the end-to-end delay, and the jitter. The mobility metrics consists of link expiration time and average velocity difference.
The remainder of this paper is organized as follows: in Section 2, we provide a review of related works. In Section 3, we present a description of CBQOS model and mathematical formulation for the routing problem we consider. In Section 4, we present a detailed description of CBQoS-Vanet protocol. In Section 5 we provide a detailed performance study with an analysis of the performance results. Finally, we draw our conclusions in Section 6.
2. Related Work
Many research studies have investigated the problem of QoS-based routing in general, but only fewer have been conducted on QoS-based routing in the context of vehicular networks. In this section we provide a review of the main existing work done on Qos-based routing that adopted the use of clustering for routing information between vehicles and those which used bioinspired techniques for the solving the problem of routing optimization.
2.1. Cluster-Based QoS Routing for VANET
The literature includes many research contributions proposing cluster-based techniques for QoS routing. In [7], the authors propose a routing protocol called VANET QoS-OLSR using both a clustering approach and an optimization technique based on ant colony. In this approach, the cluster head (CH) is selected based on two parameters: the highest QoS parameter and the node mobility parameter. The CH uses a Hello message to discover the network and selects a multipoint relay (MPR) to form a stable cluster that could contribute to the stability of the path. VANET QoS-OLSR showed that it can reduce link failures by choosing alternative MPRs. However, as is the case for the simple OLSR, VANET QoS-OLSR may not be suitable for VANETs given their highly dynamic nature and that the formed clusters have often outdated network state information.
In [8], the authors propose a Passive Clustering Aided Routing (PassCAR) protocol, destined to enhance the routing performance in one-way multilane highway scenario. PassCAR includes route discovery, route establishment, and data transmission phases. It selects suitable nodes for the role of cluster heads by using multimetric election approach based on metrics such as node degree, estimated transmission count, and link expiration time. PassCAR use a broadcasting strategy to discover paths, therefore generating a high routing overhead.
In [9], the authors propose a distributed cluster based multichannel MAC communications (CBMMAC) scheme for QoS provisioning over VANET. The protocol organizes the vehicles in close proximity with each other and traveling in the same direction into clusters. Cluster members, whether cluster head or simple member, are equipped with two transceivers, which can operate simultaneously on two separate channels: SCHs and CCHs. The CHs use these channels to support QoS for real-time delivery of safety messages and to regulate the throughput for the nonreal-time traffic through these channels. The solution proposed produces considerable levels of collision when two clusters are in nearby proximity.
2.2. Swarm Intelligence QoS Routing for VANET
In this section we review the routing approaches, which use bioinspired techniques to provide QoS for VANET applications. Among these studies, QoSBeeVanet [10] is a multipath routing protocol inspired by the communication paradigm used by bees when foraging for food. In this protocol, scouts are packets exchanged by vehicles to discover a destination, and foragers are application data packets tansmitted over VANET. Each scout records its information in a routing table, and each path in the table is evaluated based on its quality using weighting factors. In QoSBeeVanet when a link fails, the protocol floods the network with high control packets for recovery.
Similarly to the work above, the authors of [11] propose HyBR, a hybrid bee swarm routing protocol for VANET. HyBR is a unicast and multipath routing protocol tailored towards road safety applications, by transmitting safety packets with minimum delays and high packet delivery rate. In the case fo a dense network, HybBR uses a topology-based routing procedure for network discovery using scouts and foragers. When the network density is low, the protocol uses geography-based routing procedure using a genetic algorithm to search for the shortest path to the destination. HyBR generates a high level of routing overhead due to the use of considerable number of control packets.
In [12], the authors propose MAZACORNET, a solution to search for multiple routes for a given source and destination using a hybrid multipath ant colony based routing algorithm. MAZACORNET partitions the network into multiple zones, using a proactive approach to find a route within a zone, and reactive approach to find route between zones by using local information stored in each zone.
The authors of [13] propose MQBV (multicast QoS swarm bee) routing protocol for VANET. MQBV is a reactive, adaptive, and tree-based protocol. In MQBV, the source node uses a stochastic function to disseminate randomly its route request (forward scout) to all cluster members group members using a combination of unicast and multipath forwarding. The cluster head forwards the request to the next cluser only if the QoS conditions are checked and satisfied. When the packet reaches the destination, a multicast backward scout is launched back to the source along the reverse path. In MQBV protocol, the urban scenario with a highly dense environment is assumed, and the link lifetime metric is not considered.
In [14] an optimization algorithm called bees life algorithm (BLA) was proposed for QoS in VANET using multicast routing. The main objective is to find the optimal multicast tree from the source to multiple destinations with minimum cost, reduced delays and jitter, and a maximum bandwidth. Three QoS criteria are considered when building the multicast tree: delay, jitter, and a minimum bandwidth. However, this technique does not factor in in essential metrics such as the packet loss and routing overhead.
In [15], the authors propose SAMQ, situation-aware multiconstrained QoS routing algorithm. SAMQ is based on ant colony system (ACS) and situational awareness (SA) model. The novelty of SAMQ is in its use of SA levels and ACS mechanisms by the vehicles to respond locally and immediately to link failures without interrupting the data transmission. SAMQ recuperates the link breakage by switching links or subroutes at or near the failure point. The routing algorithm in SAMQ selects reliable and optimal QoS routes and keeps evaluating the current situation through the SA levels. Due to the high number of control packets that are generated, this technique can experience higher packet loss.
The authors of [16] propose ARP-QD, an adaptive routing protocol for urban VANET environments. ARP-QD takes into account the traffic density when searching for the best path and uses an adaptive neighbor discovery algorithm to obtain information on local vehicular density so as to reduce the network overhead and improve resource usage and to recover quickly when the routes are interrupted. Two metrics are used: connectivity and distance (CDP) and segment selection weight (SSW). For the forwarding strategy, ARP-QD uses global distance and speed. Although ARP-QD has used newer metrics to search for a stable routes, this protocol does not support traditional QoS criterias like delay, jitter, and bandwidth.
Similarly to the previous study and for the context of urban VANET environment, the authors of [17] propose an intersection-based QoS routing protocol for VANETs (IRQV) using ant colony optimization techniques. IRQV calculates the best route between two terminal intersections close to the source and the the destination nodes. The selection of the route is based on two QoS metrics: connectivity probability and transmission delay. IRQV uses a greedy carry-and-forward mechanism for the transmission of the data packet between the intersections where forwarding data to the next intersection is decided according to the maximum global pheromone. In IRQV, all the intersections integrated into the vehicular network as fixed communication nodes. Therefore, IRQV requires the use of a geographical location system and digital map.
In Table 1, we provide a summary of the protocols discussed above. The protocols are classified based on the supported QoS metrics, the adopted scheme and paradigm, the mobility model, the type of environment, and the forwarding strategy. We may note that most of proposed protocols are developed for urban environment and operate under reactive mode. The performance analysis of most of these protocols has been done through NS2 simulator.
The above review focuses on the general process of finding routes that satisfy QoS requirements only, without considering the details of the following procedure: routing overhead, stability of communication links, and recovery process of link failures, congestion and packet loss due to broadcasting (discovery), and time and memory complexity of the proposed solutions. As we can see, the proposed approaches have some drawbacks attached to the process of achieving feasible QoS compliant routes. To overcome these drawbacks, we propose a new QoS routing protocol for vehicular networks by bringing improvements on two levels: (1) improving the clustering schemes so as to reduce routing overhead and minimizing the congestion due to the discovery phase, and (2) using an artificial bee colony approach for searching for optimal routes that are compliant with the application’s QoS requirements. By using these two approaches, the objective is to increase the link stability and packet delivery rate. The QoS metrics used in our solution are driven by the nature of VANET environments.
3. Problem Formulation
A vehicular network is represented by a undirected graph , where denotes a set of vertices representing vehicles and the set of edges representing the communication links connecting the vehicles. A link is denoted by directly connecting vehicle to vehicle , and, in this case, and are said to be neighbors to each other. We define as the set of all the neighbors of vehicle ; . We define a path as a sequence of links connecting vehicles to , and as the set of all possible paths in . That is, is defined recursively as , where and .
We assume that each link is associated with a link weight vector in which is an individual weight component, i.e., a single metric such as bandwidth, link life-time, and transmission delay. Accordingly, any path from a given source to a given destination can be assigned a path weight vector , where is defined by an objective function which determines the value of each one of the weight elements for a given link. The weight elements are considered here as QoS values. That is, we define as the QoS constraint vector that a route must satisfy for it to be considered a routing solution. For example, let us consider as the vector of QoS contraints for the minimum bandwidth required, the maximum end-to-end delay, and the probability of route breakage. A route from a given source to a given destination with the following path weight vector can be considered as a satisfactory solution with regard to . The terminology used in this paper is defined by Table 2.
3.1. QoS Metrics
In this section, we describe the QoS metrics used in our protocol. The QoS metrics are used in two cases: in the selection of the cluster head and in the determination of the best route to the destination. Three QoS metrics considered in these models are: the available bandwidth, the end-to-end delay, and the jitter.
3.1.1. Available Bandwidth
The available bandwidth over a link , denoted by , is defined as the maximum throughput at which packets can be transmitted between vehicles and without disrupting any already ongoing flow in the network [18]. is calculated aswhere is the idle time at the sender, is the idle time at the receiver, is the maximum link capacity, is the additional overhead due to the binary exponential back-off mechanism in 802.11 [19], and is the collision probability (calculated using 802.11p packets). where is the time separating the transmission of two consecutive frames, representing (Distributed Inter Frame Space) is a fixed interval, and is the number of back-off slots decremented on average for a single frame. That is, the available bandwidth for an entire path is defined as
We also define the available bandwidth at node as the available bandwidth over links connecting to its neighbors. We use an exponential function to obtain high metric values as an estimator for the available bandwidth:
3.1.2. End-to-End Delay
The end-to-end delay is defined as the time taken for a data packet to be transmitted across a VANET from a source node to a destination node. That is, denotes the transmission time over the link connecting to . This metric is significant in understanding the delay introduced by path discovery [20]. The end-to-end delay for an entire path is therefore defined asSimilarly, we define the delay at a node as the average delay incurred by transmitting data to the neighboring vehicles. That is,
3.1.3. Jitter
In general, a delay jitter is defined as the end-to-end delay variation between packets arriving at the destination. In real-time applications such as VoIP, video conferencing, and multiplayer games, jitter is often considered as an important QoS metric for the quality of the transmission [21].Similarly, we define the jitter at a node as the average jitter incurred when transmitting data to the neighboring vehicles. That is,
3.2. Mobility Metrics
In this section, we describe the mobility metrics used in CBQoS-Vanet. We included the mobility metrics to increase the stability of clusters and improve the lifetime of the routes. These metrics are the link expiration time and the average velocity difference.
3.2.1. Link Expiration Time
In highly dynamic wireless networks, it is important to reduce the probability of link breakage. The formula that we use to calculate the link expiration time (LET) is based on work in [22]. LET is considered as the distance separating neighboring vehicles , and selecting the best path boils down to selecting the set of links with the minimum LET. The formula for the calculation of LET is presented in (9). Assume that two vehicles and are within a distance from each other. Let be the coordinates of and be that of . Also, let and be their respective velocities and and and, be the moving directions of and , respectively. Then, the amount of time, , two vehicles will stay directly connected is calculated aswhere .
As LET is a function of the distance separating neighboring nodes and their corresponding velocities, we assume that the vehicles in our model are equipped with a GPS receiver with appropriate accuracy. Therefore, the lifetime of a link is the average of the LET of all the links connecting a vehicle to its neighbors. That is, the lifetime of a connected path is the minimum value of the LET for each link in the path, defined asWe also measure the ability of a vehicle to maintaining connectivity with vehicles within its transmission range as the average lifetime of the links established with the neighboring vehicles; that is,
3.2.2. Average Velocity Difference
The average velocity difference metric is an important factor for constructing relatively stable clustering topology. Each vehicle has access to the position and the speed of the vehicles within its communication range and hence can calculate the velocity differences. The vehicular average velocity difference is computed as follows:where is the total neighbors number of nodes , , and the average velocity of nodes and , respectively in m/s.
3.3. Multiconstrained Optimal Path (MCOP)
QoS-based routing algorithm is responsible for finding feasible paths from a source to a destination, which satisfiy multiple constraints. This task can be achieved by solving multiconstraint optimal path selection problem (MCOP). The MCOP routing algorithm identifies the optimal path among several feasible paths found by the routing algorithm according to specific QoS criteria.
A path is to be optimal if and only if all the QoS values presented in the path are optimal. The routing algorithm must therefore return to a path respecting the MCOP which is defined in the following:
where is equivalent to for an additive or multiplicative metric, and for a concave metric. We define as the nonlinear function that calculates the cost of a path in which that eliminates all infeasible paths.
Since vehicles participate to multiple types applications which generates various types of traffic (audio, video, data, email, ftp, etc.), each type of traffic has its own QoS requirements. Therefore, the fundamental function of MCOP is to identify the optimal routes according to various requirements.
4. CBQoS-Vanet Protocol
In this section, we provide a description of CBQoS-Vanet. This protocol is a unicast routing protocol which combines two algorithms: a clustering algorithm and an artificial bee colony inspired algorithm.
4.1. Clustering Algorithm
The clustering mechanism od CBQoS-Vanet is inspired from [7] and modified to make it suitable for VANET environments in highway scenarios with two main objectives: (1) improving the stability of the clustering structure and (2) maintaining end-to-end communication even during frequent link failures.
This clustering algorithm is divided into two components: (1) cluster head (CH) election algorithm whose purpose is to partition the network into clusters and elect an optimal CH based on local QoS requirements; these CHs will play later an important role in determining the best QoS compliant paths; (2) multipoint relay (MPR) selection algorithm where each cluster selects one or few special nodes responsible for relaying data between different clusters. The benefit of MPRs is to minimize data flooding between and within clusters during the dissemination of routing packets. In a sense, MPRs are considered as gateways. Accordingly, members of a given cluster are classified as CH, MPR, or a regular cluster member (CM) as illustrated in Figure 1.
In the CBQoS-Vanet each vehicle periodically broadcasts a message (see Figure 2) every time units to its neighbors to inform them of its presence. Upon hearing the message, all the vehicles in the sender’s neighborhood update their neighbors list accordingly and take note of the received QoS value as show in Algorithm 1. When all the vehicles converge on a common list of neighbors, the best QoS value is determined and therefore the CH is elected. Obviously, QoS values can change dynamically due to the change in the network topology. That is why each QoS value is also associated with a expiry time (determined by the creation time). When a QoS value is changed a new value is created and communicated to all the neighbors and a new CH may be elected accordingly. This is done following the conditions shown in Algorithm 3. Each node continuously updates its neighbors list. Therefore, the message is very important in building the local topology. That is, each node keeps track of the link expiration time of its inks to its neighbors and update this information every time, after which the corresponsing node is deleted from the list. This is shown in Algorithm 2.
| ||||||||||||||||||||
| ||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||
The QoS model used by vehicles for electing the cluster head is crucial in complying with the QoS requirements and participates greatly in finding the best routes between communicating vehicles. Therefpre, the use of QoS metrics and mobility metrics contributes to the stability of the clusters. Each node votes for its CH according to its local QoS value obtained through the message. This QoS value is referred to here as Suitability value consisting of a multimetric value derived from both QoS () and mobility () metrics. The vehicles with greater suitability values are the most suitable to take the role of a CH. That is, a good candidate to serve as a CH is a node with the greater suitability value , determined by where is the QoS metrics and is mobility metrics. Furthermore, and are the corresponding weighing factors to indicate the importance, and , and . In addition, the value of is definied bywhere are weighting factors used here to indicate the importance we give to each one of the three QoS metric and . For instance, if we consider , and indicate that we are focusing on maximizing the bandwidth and minimizing the delay and the jitter. Similarly, the value of the mobility metric is calculated using the following equation:where , with , are weighting factors used here to indicate the importance we give to each one of the two mobility metrics, which are the average velocity difference, and the link expiration time.
4.1.1. Cluster Head Election Algorithm
The cluster head is responsible for selecting the appropriate path between the source and the destination by routing packets according to an artificial bee colony (ABC) algorithm based on the specified QoS requirements. The cluster head election algorithm works as follows: each vehicle broadcasts every time period a messages to its one-hop neighbors. The message (see Figure 2) contains the suitability QoS value. If no new neighbor has joined in within a time period of , then and all existing nodes in the neighborhood will send an message (Figure 4) to the vehicle with the best QoS value selecting it as the cluster head. In the case a node has received an message before the time has expired, and the vehicle does not have the best QoS value, then it will send an message to the node in its neighbors list with the highest QoS value. The node which has received an message from all its neighbors will change its class to CH and assumes its role as such, and confirms it by broadcasting an message to its neighbors. Upon receiving the message, all the other nodes will assume their role as regular cluster member (CM) (See Figure 3). When a nonclustered or a previously clustered node with a newly changed suitability QoS value find itself between two clusters, in this case the node may be considered for an MPR position. However, only its suitability QoS value that wil prevail when considered to serve as a CH for any one or both of the clusters it belongs to. This algorithm is described further in Algorithm 3.
4.1.2. MPR Selection Algorithm
An MPR node play the role of communication gateway with the neighboring clusters. One cluster may have one or more MPRs. When clusters are formed and the corresponding CHs elected, the algorithm of determining the MPRs kicks off (see Algorithm 4). That is following the election procedure and upon receiving an message from a CH, a vehicle takes note of its CH. In addition, all the nodes continue receiving messages thus learning about their current CH, and therefore about the presence of other neighboring clusters. The nodes initiate the MPR selection process by sending an (Figure 5) to the CH offering to serve as an MPR to a given neighboring cluster. The CH replies with (Figure 6) confirming the role of the vehicle as an MPR. If the CH receives multiple , the vehicle with the best QoS value will be selected. Upon receiving an message, a vehicle changes its role to MPR and starts operating as such for its own cluster.
| ||||||||||||||||||||||||||||||||||||
4.1.3. Cluster Maintenance
Due to the highly dynamic nature of vehicular networks, the vehicles high mobility can quickly and frequently modify the cluster structure, thus causing vehicles to join and leave the clusters frequently. Therefore, the cluster structure needs a maintenance mechanism which keeps its stability as much as possible. This is achieved through during the two operations of join and leaves(i)Joining a cluster: When a nonclustered vehicle starts the process of joining a cluster through the sending of a request to the CH, this later checks whether its relative speed is within the predetermined threshold. If so, CH accepts the join request and adds it to the list of its cluster members. This condition ensures that the vehicle requesting to join the cluster will stay for the longest period of time possible when accepted.(ii)Leaving a cluster: Leaving a cluster happens when a cluster member moves out of the CH transmission range. The CH periodically checks its neighboring vehicles, and when CH stops receiving messages from a member in its cluster for a pre-defined period of time, it assumes it has moved out its transmission range. In this case, it removes it from its neighbors list and considers it as no longer member of its cluster. If that member is an MPR, CH selects another one from the neighbors list, one that can play the gateway role and have the best suitability value. Similarly, if the CH itself shows no sign of presence in the neighborhood of the other member, the CH election procedure starts and a new CH is elected. Here again; deciding that a member is no longer part of the cluster has be confirmed through the choice of the right value for the time period for which CH should wait until it is certain that the node has left the cluster.(iii)Cluster merging: Due to the nature of VANETs cluster heads my come close to each other and get within each other’s transmission ranges, leading to relative speeds within the defined threshold velocity. This is usually the case for starting the process of merging the two clusters. In this case, the cluster head that has the lesser suitability value changes its role to cluster member forcing all the members in its cluster to change their status to unclustered. Therefore, these members enter the process of discovering their new cluster head through the election process. The vehicles which cannot join the new cluster and start clustering mechanism to form a new cluster accordingly.
4.2. Artificial Bee Colony Algorithm
4.2.1. Bees Communication Principle
Routing can be considered as an optimization problem when the objective is to find the best path between a source node and a destination node among many. Various computational problems such as this one can be solved using algorithms inspired by the hony bees behavior. Artificial bee colony (ABC) algorithm is an optimization technique that simulates the mating and foraging behavior of honey bees [3].
In CBQoS-Vanet, VANET is viewed as a bee environment (Table 3) where bees are organized as clusters to accomplish specific tasks. ABC algorithms are modeled on how bees optimize their search for food sources and on the way they communicate to each other. That is, a beehive cluster is seen as the source cluster, and a cluster destination is the cluster of bees at the food locations. Members of intermediate clusters represent beeworkers and are used to transmit data between the source and the destination. Each cluster is represented by the cluster head responsible for routing information [13].
Food foraging behavior is observed when bees search for new nest sites or during the food source foraging. To do this, some bees, called scouts, navigate and explore the region to find a food source. When found, they come at the dance floor in the beehive to share this discovery with their nest mates via the language of dance, which can be round or waggle related to the distance of discovery. Some bees (called foragers) are recruited to exploit this discovery. Thousands of bees find efficient paths from their beehive to a food source using shared information including location, direction, quantity, and quality of food found [23]. At the end of the search process, the nectar information collected from all the scouts is evaluated and the food source (a path here) that has a good probability to have a big amount of nectar is selected. This probabilistic selection is based on a roulette wheel selection mechanism described by where is the fitness value of the solution presented for evaluation. As expected, here, the higher the probability is the better the solution is. The fitness value is determined by a fitness function represented in CBQoS-Vanet by the QoS value computed by (19). Here, CBQoS-Vanet uses two types of packets. The first type called scout is used to discover routes between the cluster heads to a given destination, while satisfying certain QoS constraints. The second type of packets, called forager, is used to transmit the data between vehicles.
4.2.2. Routing Table
Each cluster head maintains a routing table to route packets between clusters, as it is the responsibility of the cluster head for discovering the network and exploring it before data is exchanged between members of the clusters. Each entry of the table represents a route to a destination and is evaluated according to the QoS condition. Multiple routes to the same destination can be found in the routing table, but each route evaluates to a different QoS value. The route with a larger PQV is seleced to transmit the data packets.
When backward scout arrives at a source cluster head, it creates a new entry in the table, which contains the following information: a unique path id, a scout id which discovered this path, the next cluster head (that is the next hop), and the hop count, which indicate the number of cluster heads travelled through before the backward scout reaches the destination. In addition the entry includes a weighted factor field reflecting the QoS value for this route. A timeout value is used to retransmit the forward scout if it does not return within a maximum waiting time.
The entries in the routing table are ordered based on the corresponding QoS value. This allows CBQoS-Vanet to acquire the best route with respect to the QoS requirement according to the class of the traffic. Figure 7 illustrates the routing table used by CBQoS-Vanet protocol.
4.2.3. Route Discovery
The first phase in ABC algorithm is the route discovery in which if a node source wants to establish a path with destination node () possible another cluster, it sends a request to CH. In this case, two scenarios are possible: (1) a route to is available in the routing table of the CH, or (2) no route to exists in CH’s routing table. In the first case, a route to existing in CH’s routing table responds to QoS requirement; CH launches a backward scout which carries information about the past itenerary (or the backward path to ). In the second case, CH launches a forwards scout responsible for exploring the network (Figure 8) and discovering a route to . Forward scouts use MPRs to move from one cluster to the next one. At each cluster, the cluster head tries to respond to the QoS requirement by verifying the QoS information carried by the the forward scout message (Figure 8) (, and ). If there is enough resource to accomodate the message, CH updates the message and forwards it on to its neighbors until the message reaches the destination.
To limit the effect of the flooding and the generation of duplicate forward scouts, CH and MPR everytime check whether the forward scout visit is the first one; otherwise its message is dropped.
When the destination node is reached CH propagates the backward scout (Figure 9) back to the CH in the source node along the reverse path taken by the forward scout. Each CH in the reverse path records the backward scout as an entry in its routing table to be used later on by foragers and also as a caching mechanism to ensure that the discovered paths are loop free. When a backward scout arrives at the source , the cluster head computes the PQV based on the QoS information carried in the backward scout message. CH selects the route with the larger for transmitting network traffic. CH usually allows a predefined period of time for all the backward scout message to arrive before it makes its final selection. Another strategy is to start transmitting data as soon as the first backward scout arrives and the path with the highest PQD is selected, under the provision that CH can change the route when a new backward scout arrives with a better PQD.
The QoS value is recorded along with the route in the routing table. The routing table is updated as arrive at the cluster head (see Algorithm 5). Finally data packets are forwarded through the appropriate path according to the QoS requirements and the path quality values PQV associated with the paths in the routing table (see Algorithm 5).
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
CBQoS-Vanet use (19) to calculate PQV. This equation can be defined as follows:where and . , and are coefficients which reflect the importance assigned to the specific QoS metrics.
CBQoS-Vanet uses the MCOP selection problem where it returns the route that maximizes the objective function as follows:
4.2.4. Route Maintenance
The route maintenance procedure in ABC starts following cases: (1) when a cluster head detects a link failure then any path passing though the broken link is considered as disconnected; and (2) when the cluster head detects an invalidity in the computed path quality value stored in the routing table such that it does not match the QoS requirements, for instance, there is a limited available bandwidth or an increase in the time delay. In both of these cases, an error scout is sent by the cluster head to the cluster head source and all cluster heads along the path. All cluster heads in the reverse route are therefore informed about the link failure, thus allowing them to remove it from their routes tables and to start a new route discovery.
5. Performance Evaluation
We used a simulation approach to evaluate the performance of our protocol. The simulation was implemented using OMNeT++ [24] with the VEINS as framework [25] for VANETs. The communication between vehicles is based on IEEE 802.11p standard [26] and IEEE 1609.4 DSRC/WAVE, including multichannel operation [27], QoS channel access, noise, and interference effects to make the simulation of VANET as realistic as possible [28]. We used VEINS as the basis for developing CBQoS-Vanet protocol. For vehicle mobility we use the car following model which is implemented in SUMO [29] coupled with a OMNeT++ using a TCP socket developed to permit bidirectional coupling of both the road traffic simulation and the communication simulation.
The evaluation of CBQoS-Vanet is based on two series of experiments: (1) traffic class comparison, where we compare CBQoS-Vanet performance in the context of different classes of traffic such as best effort, audio, video, bulk transfer, and general application (email, browsing, etc.); this simulation is performed to study the various parameters and select the best coefficients to be used in CBQoS-Vanet in the second simulation part; (2) protocols comparison, where we compare CBQoS-Vanet performance against two other existing protocols: SAMQ [15] and OLSR [30] QoS-aware routing protocols. These two protocols were chosed among the ones discussed in the related work section because they are representative of the reviewed approaches and use similar techniques of clustering and evolutionar algorithms. The simulation experiments use the scenario of highway with 3 lanes in each direction where each vehicle moves in one direction with the same average speed per lane. The first lane is a fast lane, the central lane is for medium-speed traffic, and the last lane is for slower-speed traffic. We assume vehicles are equipped with global positioning system (GPS) devices, and for the purpose of data transmission, the source and destination are randomly selected for each simulation run.
5.1. Performance Metrics
The selected performance metrics used in the evaluation of CBQoS-Vanet are the same ones used by the protocols used for comparison. These metrics are packet delivery ratio, network overhead, end-to-end delay, average throughput, jitter, and packet loss ratio.
5.1.1. Packet Deliver Ratio (PDR)
It is defined as the ratio between numbers of packets received by the destination over the total number of packets transmitted by the source vehicle within a time period.
5.1.2. Normalized Overhead Load (NOL)
It represents the ratio between the total numbers of routing packets and the total number of successfully delivered data packets. This metric provides an indication of the extra bandwidth consumed due to routing packets (forward and backward scouts), to deliver data traffic. The lesser overhead, the better the performance.
5.1.3. The End-to-End Delay (E2E)
It is defined as the average time that packets take to traverse the network, calculated as the summation of the transmission delay (at MAC layer), the propagation delay, and the queuing time. E2E depends on number of hops and the traffic congestion on the network.
5.1.4. Throughput
It is defined as the average rate at which the data packet is successfully delivered from source to destination in a certain time period over a communication network.
5.1.5. Jitter
It refers to the variation in delay that occurs between two successive packets. The delays between the different packets need to be low for better performance in vehicular ad-hoc networks.
5.1.6. Packet Loss Ratio (PLR)
It refers to the ratio of the network traffic that fails to reach the final destination over the total number of successfully received data packets.
5.2. Traffic Classes Comparison
In this section, we compare the routing performance of CBQoS-Vanet in various classes of traffic in terms of end-to-end delays, delivery ratio, throughput, and jitter. We chose to evaluate these criteria against a varying vehicular density. We assume that CBQoS-Vanet is configured with the QoS weights reflecting the importance attributed to specific QoS metrics. The values assigned to these weights decide the class of traffic that CBQoS-Vanet is supposed to accommodate to. These weights are here experimental values and can be modified by the application during data transmission (see Table 5).
The proposed simulation time is 1000 seconds in a straight road of 4 km. We use a transmission range of 250m because this is most efficient transmission range for DSRC [31]. messages are generated every 1 second and are transmitted only on the Control Channel (CCH). Other parameters are summarized in Table 4. We conducted 20 simulation runs. In each run two nodes are selected randomly to exchange data packets where packet rate is 4 packets per second. All the average results are obtained with a 96% confidence interval.
Figure 10 shows that the voice applications have better end-to-end delays than the other classes of traffic. This is easily explained by the fact that the end-to-end delay coefficient for voice traffic is given a higher value so as to favor routes with better end-to-end delays for voice packets.
Similarly, Figure 11 shows that bulk transfer traffic has better performance with regard to delivery ratio given that the various QoS coefficients configuration favor the selection of routes with the least packet drops where it improves the packet delivery rate. It also shows that compared to the best effort traffic, voice and video traffic performance are close to that of the bulk transfer traffic.
As for the throughput Figure 12 and similarly to the PDR, the bulk transfer traffic exhibits better performance along with the voice and video compared to the best effort traffic. Here again, we show that when configured with the right QoS coefficients, the applications that require higher throughput will be favored and the routes with the highest bandwidth will be selected. Finally, in terms of jitter, Figure 13 shows that voice and video have rightfully the best performance with best effort traffic with the least performance. Here again the results show that the chosen QoS coefficients allow CBQoS-Vanet to select the best routes in term of jitter for the applications such as voice and video, which require the minimum jitter for their packets.
5.3. Comparing CBQoS-Vanet to Other Protocols
In this section, we present the performance results when comparing CBQoS-Vanet against other two known protocols: SAMQ and OLSR. As explained above, SAMQ is based on OLSR with a similar evolutionary algorithm that is ant colony algorithm and is designed for highway.
The simulation time is 1000 seconds for each scenarios, and the scenarios are run on a 10Km-long highway segment, with a transmission range of 350 meters. Likewise, messages are generated every 1 second and are transmitted only on the Control Channel. Other parameters are summarized in Table 6. It is to note here that, for the sake of preserving the same MAC bit rate used by SAMQ and OLSR, we have selected a 6Mbps bit rate as opposed to the default 18Mbps used in the previous set of experiments (see Table 4). In this set of experiments, we vary the number of vehicles within the range: 25, 50, and 75 to 200 from low density to high density, with an interarrival time that is exponentially distributed. The speeds of the vehicles vary from 1 to 30 m/s. Data packets exchanged between vehicles are 1000 bytes long and packet rate is 4 packets per second. All the average results for CBQoS-Vanet are obtained with a 96% confidence interval.
Figure 14 shows that in terms of end-to-end delay our proposed protocol outperforms both SAMQ and OLSR. However, SAMQ performance remains very close to that of CBQoS-Vanet for all the vehicles density. There are two elements that explain these results. First, our protocol, through tuning the various QoS coefficients, can obtain better performance with regard to the delays. Second, the reactive nature of CBQoS-Vanet allows it to use the latest reading of the networks in terms of delay to make a decision about the route to take. That also explains why SAMQ has a performance that is close to CBQoS-Vanet, as it is focuses on the use of the concept of life-time characteristic of the selected paths.
In terms of packet delivery ratio, Figure 15 shows that on average CBQoS-Vanet outperforms the other two protocols in providing routes with the best PDR. The results also show that, for CBQoS-Vanet and OLSR, as the vehicles density increases, the delivery ratio decreases almost linearly. However we can observe that, for SAMQ, not only the delivery ration is on average way lower than that of CBQoS-Vanet and OLSR, but this ratio increases with the increase of the vehicles density. The delivery ratios for CBQoS-Vanet and SAMQ are equated when the vehicles density reaches 200 vehicles. This may be explained by the fact that SAMQ provides better PDR performance when the lifetime of the links is higher, and that is achieved with more vehicles in the system which ultimately leads to better connectivity and better link lifetimes. The results in Figure 16 show that, in terms of network overhead, both CBQoS-Vanet and SAMQ have the best performance over OLSR, with a slight advantage for SAMQ at a lower vehicles density. Note that, with higher density, it is expected that more overheads are generated due to the multiplications of possible paths explored and, consequently, the number of routing packets generated. The increase in the overhead is however for all the evaluated protocols linear and with almost the same slope on average with 20% overhead at a density of 200 vehicles for both CBQoS-Vanet and SAMQ and around 42% for OLSR. We may note here that CBQoS-Vanet and SAMQ have similar behavior due the use similar routing packets (forward and backward) included in swarm intelligence algorithms.
Finally, Figure 17 shows the comparison of packet loss ratio for CBQoS-Vanet vs. the SAMQ and OLSR. The results indicate that although the three protocols are within the same range of packet loss, i.e., 2% to 6%, CBQoS-Vanet is in between with the best performance for SAMQ with the lowest performance for OLSR. The use of ACS routing mechanism and the situational awareness model is likely what gives the slight advantage that SAMQ has over our protocol.
6. Conclusion
In this paper, we presented CBQoS-Vanet, a new routing protocol which enforces QoS in VANET. This protocol is based on the use of two techniques: a cluster-based routing tailored for the case of highways and an artificial bee colony technique for multiconstrained routing optimization. The clustering technique is designed such as to expedite the forwarding of the data through the cluster heads and the multipoint relays only. That is, the formation of clusters and their maintenance are made in such a way to optimize routing accorindg to the required QoS. Therefore, part of the work is already done during the formation of the clusters and the selection of their respective cluster heads. The artificial bee colony approach is used here to find the most QoS-compliant routes using scouts for discovering the network. The best route is determined by computing of a suitability function that takes into account both QoS and mobility metrics. The main improvement brought by CBQoS-Vanet is many folds: first, its capacity to partly enforce QoS requirements during the process of forming clustering based on general QoS requirements and not only the mobility and connectivity requirements; second, supporting a tuning mechanism by the the ant colony algorithm by combining QoS metrics in a formula weighting the different application QoS needs; lastly, optimizing the network discovery algorithm by using a caching mechanism that reduces the network overhead by temporarily caching optimal solutions that were already discovered. The performance shows that CBQoS-Vanet is more suitable to highway scenarios given the fact that it performs well in the case of normal density, and that it shows similar performance to SAMQ when the density is very high. That is, as a future work, we plan to extend this research to the case of urban VANET and study the behaviour of CBQoS-Vanet under a higher vehicular density and a different mobility model.
Data Availability
The data used to support the findings of this study are available from the corresponding author upon request.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
This work was partially supported by the Roadway, Transportation, and Traffic Safety Research Center (RTTSRC) at the United Arab Emirates University (Grant no. 31R012).