1. Introduction
A vehicular
ad hoc network (VANET) primarily serves as a mesh network consisting of mobile and fixed nodes. It is a form of mobile
ad hoc network (MANET) used to provide communication among the adjacent vehicles and the nearby fixed equipment. It is defined as a network without infrastructure and centralized administration [
1,
2,
3]. Intelligent vehicular ad hoc networking (IVANET) provides an intelligent way of using vehicular networking [
4]. It targets supporting vehicular safety, traffic monitoring, accident prevention and many other applications. Although VANET is a subclass of MANET having different features from other types of
ad hoc networks, such as wireless sensor networks (WSNs) and delay-tolerant networks (DTNs), the nodes in VANETs can be equipped to serve as a host and router at the same time [
5]. This special property and capability qualifies VANETs to form and set up a network connection in extraordinary environments, such as deserts, forests, mountains and in natural disaster situations, where ordinary communication infrastructure is lacking. Furthermore, the dynamic topological characteristics enable VANETs either to work as a standalone network or as a part of public networks, such as the Internet, using satellites and other communication links.
Recently, economic development and the popularization of automobiles have brought high concern to VANETs. In 2003, the Federal Communications Commission (FCC) developed the Dedicated Short-Range Communications (DSRC) standard for dynamic organizing vehicular networking communication, which provides communications between the on board units (OBUs) of the vehicle and the roadside units (RSUs) in specific locations, as well as supporting particular ITS applications. DSRC operates on radio frequencies in the 5.85 GHz to 5.925 GHz range, which is the standard Industrial, Scientific and Medical (ISM) band. In 2009, the IEEE 802.11 standard was developed to launch a new standard for vehicle communication, named IEEE 802.11p [
6,
7,
8,
9,
10,
11].
We noticed that previous researchers generally concentrated on VANETs located in cities or on highways. However, with economic development and from environmental perspectives, people’s activities gradually have extended to rugged environments, such as deserts, forest and other unpopulated areas. Taking into account the irregular road conditions and lack of ordinary communication facilities in these environments, safe driving of a vehicle is quite challenging and even fatal. Although satellite and mobile communication can partially solve the problem of information exchange between vehicles, they are rather expensive and have limited bandwidth. Moreover, mobile communication systems covering such extraordinary regions are sometimes technically difficult. Therefore, a VANET is possibly a great alternative solution.
In VANETs, topology-based routing protocols use link information that exists in the network to perform packet forwarding. They are divided into proactive and reactive protocols. The reactive one usually opens the route only when it is necessary for a node to communicate with another. It maintains only the routes that are currently in use. Therefore, it reduces the burden in the network. It consists of a route discovery phase in which the query packets are flooded into the network for the path search, and this phase completes when the route is found. The common sorts of reactive routing protocols in V2V communication are Ad hoc On-demand Distance Vector Routing (AODV), Temporally Ordered Routing Algorithm (TORA) and dedicated short-range (DSR) [
12,
13]. Another type of V2V routing protocol is cluster-based routing protocols in which a group of nodes identifies themselves to be a part of a cluster, and a node designated as the CH will organize and broadcast the packet to the cluster. Reasonable scalability can be provided for large networks; however, network delays and overhead are incurred when forming clusters in highly mobile VANETs. In cluster-based routing, virtual network infrastructure must be created through the clustering of nodes in order to provide scalability. The common types of cluster-based routing protocols are cluster base routing protocol (CBRP), Clustering for Open IVC (
Inter-vehicle communication) Network (COIN) and Location Routing Algorithm with Cluster- Based Flooding (LORA-CBF) [
12,
13,
14,
15]. However, considering the high mobility of vehicles, irregular roads and environmental factors, the traditional MANET and VANET routing protocols may not satisfy network communication and information exchange in these environments. Therefore, clustering routing protocols became one of the most important choices.
This paper presents a VANET clustering routing algorithm appropriate for desert and other rugged environments. The proposed protocol provides a stable clustering structure and a reliable route between the source and destination vehicles. Additionally, it utilizes vehicles equipped with mobile or satellite links to act as a gateway for unreachable destinations. The cluster structure, cluster head election (CHE) and the routing protocol are presented and comprehensively described.
A new CHE approach is also proposed and theoretically analyzed. Throughout the paper, numerical simulation is used to evaluate the proposed CHE approach. Simulation results are also conducted to evaluate the proposed routing algorithm, in terms of the packet delivery ration (PDR), end-to-end delay and cluster stability, and to compare it to other alternatives.
The rest of the paper is organized as follows.
Section 2 briefly introduces the most important related works.
Section 3 describes the cluster structure of the general designed model of the network and its corresponding logical model.
Section 4 describes the clustering process and presents the CHE procedure.
Section 5 explains and extensively discusses the proposed routing protocol.
Section 6 is the simulation results and observations. Finally,
Section 7 concludes this work.
2. Related Work
Due to the reliability of its information transmission and wide range of applications, vehicle dynamic organizing networks have emerged with a high degree of concern for both the industrial and research aspects. Considerable research has explored communication algorithms to satisfy the special features of VANETs. For instance, Yu
et al. [
1] used a distributed learning algorithm to dynamically change the transmission rate between adjacent vehicles. By this algorithm, each vehicle learns from local observations and selects a delay based on learning results, so that data can be received efficiently and aggregated. Chin
et al. [
2] designed and implemented two types of routing protocols and compared them to protocols representing MANETs and VANETs. Many other reports stated an overview of highway cooperative collision avoidance (CCA), which is an emerging vehicular safety application using the IEEE-802.11 and DSRC standards [
7,
16].
Vehicles’ movement direction is quite important in determining the quality of the communication system in VANETs and has a great significance in restricting the routing protocols’ capabilities and performance. Therefore, many researchers have given considerable attention to the vehicle movement trends. In this context, Zhang
et al. [
3] considered the effect of the driving behaviors and vehicle classification in the movement direction and consequently incorporated these effects into the route-finding process. Their proposed protocol, as an energy-efficient routing protocol, classifies the vehicles into several categories and then examines the effect of the vehicle movement trends to aid in making a routing decision. It predicts the movement direction using the current directions and the next directions after going through the road intersections. Although it demonstrated reasonable results in terms of energy consumption in urban scenarios, it greatly relies on the road intersection while performing the routing process.
Wang
et al. proposed a vehicular mobility model that reflects real-world vehicle movement while studying the performance of packet-routing protocols in small-scale and large-scale VANETs. Furthermore, the connection-based restricted forwarding (CBRF) and connection-less geographic forwarding (CLGF) algorithms were presented according to the environment, quantity and speed of the vehicles. These algorithms were employed to determine the shortest communication distance
r; subsequently,
r was used to determine the shortest route [
8]. Zhang
et al. [
9] proposed an analytical model to predict both up-link and down-link connectivity probabilities along with deriving the urban environment route by means of roadside auxiliary facilities. Others proposed a broadcasting routing protocol, addressing both the broadcast storm and connected network problems in urban VANETs where both direct and indirect packet routing protocols were utilized [
10].
In addition to safety concerns, VANETs can also support other applications, which require guaranteed quality of service (QoS), particularly in the case of multimedia and data transfer applications. In this context, a routing protocol for VANETs called the intersection-based geographical routing protocol (IGRP) was proposed [
4]. IGRP is based on an effective selection of road intersections through which a packet must pass to reach the gateway to the network. The selection is made in such way that it can guarantee high probability, bandwidth utilization, error rate optimization and network connectivity among the road intersections, while satisfying QoS. Geographical forwarding is used to transfer packets between any two intersections on the path, reducing the route’s sensitivity to the individual node movements [
4]. Other methods use urban roadside infrastructure instead of road intersections. In this methods, vehicles regularly send messages to the roadside infrastructure, which is responsible for the routing process [
5,
14,
17].
Due to continuous expansion of VANETs’ structure, clustering is a popular means of organizing networks in MANETs and VANET. Consequently, clustering routing algorithms attracted many researchers, in favor of its convenience and useful features. Many clustering solutions, including topology-based clustering, mobility-based clustering, identifier neighbor-based clustering, energy-based clustering and weight-based clustering, have been proposed [
7,
18,
19,
20,
21,
22]. In urban environments, the integration of VANET with 3G networks was investigated, where a VANET is divided into different clusters according to the movement direction of the vehicle, velocity, signal strength or VANET coverage range. The nearest vehicle to the center of the cluster is dynamically selected as a cluster head (CH). When a cluster member requires external communication, the selection of the gateway is based on the speed of the CH, signal strength and communication connectivity [
4]. Sun
et al. [
17] presented an analytical design-based simulation of environmentally-aware clustering algorithms for wireless
ad hoc networks. The clustering algorithm establishes an adaptive dynamic arrangement that enables multi-mode routing scenarios needed to enhance scalability and robustness. In this method, clustering is based on a criterion that enforces an upper bound on the probability of path failure within the cluster over time. Moreover, Li
et al. [
6] introduced a clustering technique suitable for a VANET environment on highways with the aim of enhancing the stability of the network topology. This technique takes the speed difference a parameter for creating a relatively stable cluster structure. It also developed a new multi-metric algorithm for CHE.
One of the popular clustering algorithms is the affinity propagation (AP) algorithm, which has been recently proposed [
23]. AP is a distance-based clustering algorithm, which results in the frequent changing of CHs when speed effectively changes. Moreover, AP requires a number of iterative loops that increase the delay time of cluster construction. To adapt the new features of VANET, a modified distributed mobility adaptive clustering algorithm has been presented in [
24]. Since this modified algorithm is mobility adaptive, distributed and traffic direction dependent, re-clustering is avoided when the vehicles move in different directions.
Some other literature works proposed a cluster-based directional routing protocol (CBDRP) suitable for highway scenarios in which the CH selects another one according to the direction of motion in order to forward packets [
14]. In the cluster-based routing protocol (CBRP), VANETs are characterized by high vehicle mobility. Due to high mobility, the VANET topology changes rapidly, resulting in high communication overhead for exchanging new topological information. For more information, the readers are invited to review most of the well-known clustering solutions for VANETs in [
15].
Most of the aforementioned algorithms are based on one-hop clustering, which only allows communication among one-hop neighbors. Consequently, the coverage rang is small, and many clusters are formed, which decreases cluster stability. Clustering algorithms are often designed to assure cluster stability, which is essential to reduce the maintenance cost and increase routing efficiency and throughput. In one-hop clustering algorithms, vehicles must identify the aggregate mobility of all M hops-distant neighbors. Consequently, various extra control messages are produced and broadcast within the network, which ultimately reduces the efficiency of cluster formation. Moreover, the majority of these research works only considered the location or the speed of the vehicles for constructing the clusters, while the direction or the equipment of the vehicles have not been thoroughly considered. These protocols also used various strategies having different limitations and drawbacks when selecting the CH. Most importantly, all of these protocols and solutions have never been investigated in desert and rugged scenarios. The majority of these protocols rely on road side units, road intersections or other assumptions, which may not satisfy desert scenarios.
3. System Model and Network Logical Structure
The VANET scenarios adopted throughout this paper are in desert environments without ordinary communication facilities. This work considers a group of vehicles working on a specific mission. The proposed system model assumes the number of vehicles
, divided into different clusters according to their location, as shown in
Figure 1. Each cluster
has one CH and cluster members
. The number of vehicles within one cluster is
and the maximum number of vehicles for one cluster
. The number of hops is
M, and the number of maximum allowable hops is
. The primary communication distance of the normal VANET for two vehicles
i,
j is
L, which can be expressed as:
Here,
x,
y represent the coordinates of the vehicles
i,
j and
, where
is the maximum communication distance between two vehicles that is determined according the PHY specification of the communication system. However, this communication distance can be extended using the multi-hop property of VANETs. This means, the maximum distance
can be obtained by:
For a specific number of hops
M using
vehicles, the communication distance can be obtained as:
Here, represents the communication distance of a specific hop m.
The direction, the location and speed information of the vehicles can be collected from the GPS of each vehicle. The vehicle periodically broadcasts this information using the
ad hoc communication. Vehicles within the coverage region store this information and forward it to the next hop together with their information. After a number of transmissions, each vehicle has the information of the other vehicles. In this paper, we assume that the vehicles are firstly classified into four groups according to their directions. We employed C4.5 [
25] as a simple classification tree algorithm to classify the vehicles into four groups using a simple training set shown in
Table 1. For each group, the clustering operation is performed, and the CH is accordingly elected.
The designed model can be logically represented by three layers, which form the logical structure of the network, as shown in
Figure 2. The bottom layer describes the communication network of the CH with its cluster members and the internal communication within the cluster. The middle layer, which acts as a network backbone, describes the communication between the cluster’s heads. The upper layer is formed by the vehicles equipped with satellite and mobile links to outside networks.
4. Clustering and Cluster Management
In this paper, a cluster is the basis of the designed model. After considering the direction of the vehicles, this paper classified vehicles into four categories depending on the communication equipment. These categories are the main factor in clustering classification and play an important role in cluster composition and CHE. The four categories include the vehicles equipped with VANET communication only, vehicles equipped with mobile communication, vehicles equipped with satellite communication and vehicles equipped with both mobile and satellite communication. We used the notation
V,
,
and
to represent the aforementioned four categories, respectively. The movement of the vehicles dynamically yields different types of clusters. However, this paper only considers the four main clusters shown in
Figure 3. The first cluster type consists of
V only, as in
Figure 3a; the second type contains both
V and
, as in
Figure 3b; the third type consists of both
V and
, as shown in
Figure 3c; and the fourth type is a combination of
V and
, as shown in the
Figure 3d. All of them are able to communicate with the outside network, except the first type.
Figure 4 shows a sample of possible other types of clusters, which can be formed according to the vehicle’s categories. However, the main four types in
Figure 3 can represent all. A CH should be elected for each type of cluster. For the first type, the CH should be elected according to the location, and velocity. Other types will follow the election procedure described in
Section 4.2.
According to the logical structure, the CH and the neighboring CH can communicate directly; however, in the actual situations, the CH and the neighboring CHs are not necessarily located within the same VANET communication range. For that reason, the CH may select one of the boundary cluster members to act as a gateway for forwarding traffic information (both control and data messages) between the neighboring CHs. After the completion of the CHE process, each CH collects and stores the location, direction, velocity and equipment information of its cluster members; later, it uses this information to calculate the routes.
When a cluster member requests a communication, it will send a request message to its CH. The CH checks whether the destination is within its cluster members or not. If the destination is one of its cluster members, it will directly forward the requested route information to the source member. In case the destination vehicle is located in another cluster, the CH, directly or using adjacent cluster members as a gateway, forwards the route information to the destination CH. The destination CH returns the requested route information to the source CH. Finally, the source CH sends the route information to its intended cluster member. Therefore, the clustering process is not only the election of the, CH but also includes the operation of determining boundary vehicles used to communicate between the adjacent clusters.
In
Figure 5, we assume three clusters
,
and
with their clusters heads
,
and
, respectively. As the distance between
and
is beyond the coverage of the VANET, the CHs can use the adjacent cluster members
and
to communicate with each other, because these two vehicles are within the same VANET coverage; however, they belong to different clusters. The communication between
and
will be through a mobile or satellite solution, because not only the distance between them is out of the coverage area, but also the distance between the adjacent neighbors is out of the VANET communication coverage. The CHs usually provide the communication between their cluster members. For public use, they can offer this service with some fees. However, for a group of vehicles working on a specific mission, such as a rescue, mining and military missions, the CH would provide this service for free.
It is very important to take into consideration that the increase of cluster members will increase the burden on the CH. Hence, the intra-cluster communication cost will increase, because communication between the vehicles and CH, as well as the neighboring CHs will increase the number of hops. Therefore, this paper restricts the maximum number of hops to .
4.1. Cluster Head Election Principles
A CH is responsible for passing packets and organizing inter-/intra-cluster information traffic. The perfect election of the cluster will offer an efficient network performance and high reliability. Most of the clustering routing protocols normally elect the CH based on the location or velocity. On the one hand, the selection using location is not usually an optimum choice, because the location of the selected vehicle may rapidly change according to the relative speed with the other vehicles in the network. This means that the vehicle with the best location may quickly become unsuitable as the CH. On the other hand, selecting the CH according to the velocity is also not appropriate in many situations, particularly when the relative movement between vehicles is very high. This will consequently lead to cluster instability. Moreover, the speed of the vehicles directly affects their locations. Therefore, the perfect CH selection method should consider many factors to obtain high cluster stability and network reliability. In this paper, we proposes a new approach to select the CH by considering the location, velocity and the equipment of the vehicles in order to obtain a high cluster stability and for optimum utilization of available equipment in the network, particularly in the case of vehicles working on a specific mission.
The CH is elected from the vehicles traveling in the same direction. The notation
P represents the CHE priority factor. For a specific cluster, the election priority factor
P is calculated according to the equipment, location and velocity of the vehicle. For the CHE process purposes, we assume the following:
Each vehicle has a unique ID number.
Each vehicle is equipped with a satellite positioning device (GPS) used to collect location information and to periodically obtain velocity and direction information.
In the proposed model, υ is the instantaneous velocity of each vehicle.
The symbol i represents the intended vehicle, for the group of vehicles in the same cluster, for the group of vehicles neighboring vehicle i, and j is another vehicle in the same cluster. Each vehicle has neighbors, .
The calculation of P is as follows.
4.1.1. Vehicle Equipment Priority
According to the four types of vehicles, we assume that the vehicle equipment priority factor value
is as follows:
For one cluster, the equipment priority of the vehicles can be obtained by:
These values can be normalized by scaling them between zero and one as:
The vehicle with the least value has the highest equipment priority.
4.1.2. Location Priority
The distances between
i and
j are obtained by:
Each vehicle has
distance values
, and the summation of all
values of the vehicle
is obtained by:
A vehicle with least
is the nearest one to all other vehicles. It will take a higher priority weight in the CH location priority election. It is not important to be in the center of the cluster, but it is the nearest one to others. In addition, it is not important to be elected as a CH, because the election not only depends on location, but also depends on other parameters. Therefore, another notation is the location priority factor
, which is used when there are additional priority metrics, such as equipment priority, ID priority and velocity priority, to calculate the over-all priority of a certain vehicle. The value of
is used to represent the location priority deviation of a vehicle with respect to the vehicle of the lower
. The following equations are used to calculate
:
For one cluster, the location priority of the vehicles can be obtained by:
These values can be normalized by scaling them between zero and one as:
For the vehicle with less , .
4.1.3. Vehicle Velocity Priority
We assume:
,
,
...
are the instantaneous velocities of the vehicles and
is the mean velocity at time instant
t. Calculate
for each vehicle as follows:
For one cluster, the velocity priority of the vehicles can be obtained by:
These values can be normalized by scaling them between zero and one as:
A vehicle with the lowest has the highest velocity priority.
4.1.4. Overall Election Priority
The overall priority is a function of
,
and
as:
and
are weighting values used to determine the weight of priority factors (equipment, location and velocity), where
.
For one cluster, the overall priority of the vehicles can be obtained by:
These values can be normalized by scaling them between zero and one as:
Usually, takes the biggest value because the equipment is quite important for providing reliable service in the network, particularly in intra-cluster communication. The location should take the second weight, because the vehicle with the best location has a good possibility to serve the others with the minimum number of hops; consequently, this will reduce the end-to-end delay.
4.2. Cluster Head Election Procedure
The CHE procedure is as follows:
Each vehicle periodically sends a HELLO (msg, hop-cnt) message; at the same time, it also forwards the HELLO messages of other vehicles. Upon doing M hops, the vehicle will be capable of processing all other vehicles’ information, which includes the ID number, the cluster election priority P, location information, velocity and hop count (hop-cnt). Every vehicle upon receiving the HELLO message from others stores the other vehicle’s information and subsequently uses this information to determine the hop count M of each vehicle and save it for further usage. During the information collection process, the receiving vehicle always determines the hop count of the other vehicle, stores the original M, adds one to the count and then forwards the information to the next vehicle. Through this process, the next vehicle will be able to determine the M hop of that vehicle. After a number of transmissions, vehicles will have all the neighbors’ information.
After information collection, each vehicle
calculates
according to Equation (
16) and compares the result with
, if:
The vehicle with a lower
P value has the highest priority, thus it will upgrade itself as a CH. If two or more vehicles share the least value of
P,
The vehicle with the least
value is selected as a CH, if:
The vehicle with the least ID should be elected as the CH.
The vehicle, after upgrading itself as a CH, will broadcast a message to the outside, propagating cluster information, HEAD (CluID, head-msg, way-car, hop-cnt) , where CluID is a cluster label, head-msg is the CH vehicle information, way-car is the route information and hop-cnt is the number of hops. In the initial transmission, the value of way-car is set to null, and hop-cnt is set to zero. Other vehicles within the cluster, upon receiving the HEAD message, store all values and examine the value of hop-cnt. If hop-cnt is less than , then they will add one to its current value and then forward the information to the next hop. If hop-cnt is equal to , then there is no need for further treatments. Other vehicles when receiving the same CluID investigate M values and select the lowest value of M, then use this value to determine the value of their hop-cnt return. When they receive a message from a different CluID, they analyze head-msg of the CHs, and the information of the high priority vehicle is retained. During the exchange of the HELLO messages, vehicles usually examine the CluID when the hop-cnt equals one, if a vehicle found that the CluID is different from its CluID, that means those two vehicles are border nodes.
The vehicle sends the apply message APPLY (CluID, msg, way-car, hop-cnt) to the CH, which was selected according to Step 2; other vehicles on the route interrupt this message and add their information to way-car and add one to the hop-cnt, then forward it to the CH.
The CH will add the vehicle to its member list just after verifying that the number of vehicles is less than ; in this case, the CH sends back an accept message (ACCP) to the intended vehicle; otherwise, it sends back a refuse message (RFUS) . If a vehicle receive a RFUS message, it will establish a temporary link with one of the neighbor vehicles to access the network resources until the number of vehicles becomes less than or joins another cluster.
The intended vehicle after receiving the ACCP message broadcasts the MEMR (CluID, msg, way-car, dis-cnt, hop-cnt) message, and then, there is no need to be involved in the other clustering election process by sending dis-cnt to other CHs.
Repeat the process until all vehicles become a CH or cluster members.
Border cluster members search for the adjacent vehicle of the other cluster using the hop-cnt and CluId information, making a list of all neighbor nodes.
Send a BUND (msg, way-car, dis-cnt, hop-cnt) message hop-cnt to its CH indicating that it becomes a boundary vehicle.
A vehicle with a RFUS message contacts the very near boundary vehicle and sets a temporary connection with it until it finds a new CH or constructs a new cluster with other vehicles.
4.3. Cluster Maintenance
After finishing the clustering process and CHE, the vehicles’ movement may change the cluster structure. Therefore, the cluster structure continuously needs maintenance, until the vehicle exits the network. Vehicles periodically check the neighbor list and the neighbors’ cluster listing status, in the case of adding a new cluster member or one of the cluster members leaves its cluster; cluster structure will not change, and only the CH can modify the cluster members list. When a boundary vehicle leaves the cluster, then the CH needs to select a new border vehicle using a similar clustering process and selection criteria. Due to the movement, CHs may move closer to each other, which leads to clusters merging. This situation triggers the CH competition using the same role of the CHE process. The loser CH sends a message to inform its cluster member about the new elected CH. In addition, a new CH should be elected when the loss of the CH occurs due to an accident or any other abnormal situations.
5. The Proposed Cluster-Based VANET Routing Protocol
Due to the random node mobility, a major challenge is how to route data packets in a desert and similar scenarios of communication, particularly when the source and the destination are out of the DSRC transmission range. Maintaining a routing table, as in proactive methods, is not an optimal solution, and repetitive path finding before each packet delivery, as in reactive routing, can also be exhaustive. Therefore, specific routing solutions are needed. A routing strategy only based on the location information of the nodes can satisfy the requirements of VANETs in a desert. The problem is that the majority of location-based protocols mainly rely on road side units (RSU), road intersections and other assumptions, which may not be available in a desert. This paper proposes a cluster-based VANET routing protocol (CBVRP). The proposed algorithm covers three communication scenarios, as follows.
5.1. Routing within a Cluster
When a cluster member needs to establish a link, it sends a request to the CH. The CH after receiving the request verifies whether the intended vehicle is a member of the cluster or not. In case both vehicles are in the same cluster, the CH finds from its storage the location information of the source and the destination vehicle, then starts the process of best route selection depending on the destination and source locations.
For better understanding of the proposed inter-cluster routing protocol, we assume five vehicles, as follows.
is the source vehicle located at the coordinates
. Both
and
are two vehicles in between the source and the destination with
and
coordinates, respectively.
is the destination vehicle located at
coordinates, as shown in
Figure 6.
The distance between the CH to
,
,
and
satisfies Equation (
22). The CH selects the best route according to:
If
, hence, the route
is the best one, and the next hop is
. The CH notifies
about the best route, which decreases the risk and burden on the CH. If
, this means that the best route will be through the CH, which will forward the packet to
. That is to say, besides being responsible for the route selection, the CH may also participate in the packet forwarding process. The route
will be stored as a backup. The overall procedure flowchart is described in
Figure 7.
5.2. Routing between Clusters
When the CH does not find the needed information in its internal storage, it requests the closest CHs for the destination information and waits for a routing response. If the waiting time exceeds the threshold
and the route response has not yet been received, re-request message (
RREQ) is resent. If the retransmission exceeds the maximum retransmission limit
, the route search process is terminated. To reduce network congestion, not all of the neighboring CHs receiving
RREQ will respond. Only those located on the route towards the destination having the ability to serve will participate in the routing process. As shown in
Figure 8, only
and
participate in the routing process.
Therefore, neighbor CHs, after having received the
RREQ message, first determine if they are located on the route of the CH request; if not, the request is discarded. Otherwise, the procedure is as follows.
A neighboring CH checks the request; if it is the first time received, then it continues the procedure; if not, then the request is discarded.
The neighboring CH checks whether the destination vehicle is in its cluster or not. If not, then apply Step 4.
The neighboring CH forwards a route request to the intended vehicle and waits for vehicle routing response RREP; also, go to Step 5.
The CH adds its own msg to the (REEQ msg) message, and then forwards to the next hop neighbors’ CH and waits for the route response.
If the waiting time exceeds , and it does not receive the route response, then retransmit the request and add one to request number; otherwise, go to Step 7.
If the number of retransmissions exceeds the limit , then end the route request process; alternatively, in accordance with the intended vehicle situation, directly apply Step 3 or Step 4.
If the CH receives more than one route response, then it chooses the vehicle with the fewest numbers of routing hops and the minimum distance to the destination and adds its own msg to the (REEP msg) message; then, it forwards this message to the previous hop CH vehicle at the same time, saving other routes as backups. If the routing request fails, probably due to the destination cluster, which is far away from the source cluster, and the routing communication request cannot be established through the VANET or through neighbor vehicles, the CH may establish a connection via satellite or mobile communication.
In some situations and according to the CHE process, the CH may have no satellite or mobile equipment to communicate with the far away CHs; in this case, the CH searches for one of its cluster members, which is equipped with satellite or mobile communication, to forward the request to the neighboring CHs.
If still not be able to establish the connection and routing through satellite or mobile communication, then it sends the notification
REER to the source vehicle, indicating routing failure. The flowchart of the procedure of routing between vehicles located in different clusters is shown in
Figure 9.
5.3. Cluster Member’s Communication with the Public Networks
In normal situations, only vehicle types
,
and
can communicate with the outside networks. Vehicles always prefer using the VANET, but if the destination is out of the VANET coverage or they need to communicate with public networks and the destination is unreachable through the multi-hop VANET, in such cases, the source CH firstly searches its cluster members to find a member that is equipped with an appropriate communication link to communicate with the public network. If no cluster members are equipped with suitable equipment to communicate with the public network, then it forwards the request to the neighboring CH, which is equipped with the appropriate communication link, as shown in
Figure 10. Neighboring CHs upon receiving the communication request will proceed as follows.
Check the request. If this is the first time receiving, it continues the procedure; if not, the request will be discarded.
Check whether its equipment is type V, and then, it will skip to Step 5.
If the vehicle is type , then it will skip to Step 9.
Check whether this cluster has a free available or , then it forwards the routing request and waits for a response, then skips to Step 6.
Forward the routing request to the neighboring CH, and wait for a response.
If the waiting time exceeds and it does not receive the route response, then it retransmits the request and adds one to the request number; otherwise, skip to Step 8.
If the number of retransmissions exceeds the limit , then end the route request process; in the case of vehicle , return to Step 4, while for , return to Step 5.
If the CH receives more than one route response, it will choose the vehicle with the fewest number of routing hops, the minimum cost and the shortest distance to the destination. At the same time, it stores the other routes as backup routes.
It Adds its own msg to the (REEP msg) message and forwards the message to the previous hop CH in the source direction. If the routing process fails to find a vehicle type , the source vehicle searches for a vehicle type using a similar way as mentioned in the above steps. If it is still not able to establish a route through a satellite or mobile connection, it will send a REER notification to the source vehicle indicating a routing failure.
5.4. Route Maintenance
Due to vehicle’s movement, the established route may be lost. Consequently, the communication will temporarily disconnect. At the same time, the vehicle will store the destination routing information for a while and try to resend the request. If it succeeds in sending a new route request to the intended destination, that means the route has been recovered. If it fails to send the request, then it will search its backup routing information and try to use one of the best backup routes. If it fails to send the message, it will start a new route finding procedure.