Chapter 1 Introduction
1.1 Motivation
As mentioned above, VANETs bring a lot of conveniences to our daily life. However,
transferring data in ad hoc network scenarios is not easy. In a VANET, each vehicle is independent and moves freely. It is a self-configuring network of vehicles connected with
wireless links. Because of high mobility in VANETs, wireless links can be disconnected frequently and routing paths may be very unstable most of the time. When a data path breaks, not only data packets may be lost but also there is a significant delay for reestablishing a new data path. In addition to the delay in discovering route paths, flooding messages for route discovery result in a large amount of network traffic. [16] By resolving these problems, we can improve the system performance and network throughput. In addition, data transmissions will be more efficient and reliable.
1.2 Research objective
In this thesis, a reliable routing scheme based on vehicle moving similarity (RR-VMS) is proposed. In the proposed RR-VMS, rebroadcast nodes are selected according to their vehicle persistence scores (VPSs). By VPSs, we can establish relatively reliable paths. In addition, the restriction of the number of rebroadcast nodes can reduce unnecessary control messages and avoid the flooding problem.
1.3 Thesis organization
The rest of this thesis is organized as follows. We describe the problem statement and the related work in Chapter 2. In Chapter 3, we introduce the detail of our RR-VMS. Simulation results, which can show the feasibility and benefits of our method, are discussed in Chapter 4.
In Chapter 5, we conclude the thesis and outline future work.
3
Chapter 2 Related Work
2.1 Flooding problem
Broadcast is one of the fundamental mechanisms in wireless network communications.
In most reactive routing protocols, route request (RREQ) flooding is used in route discovery to discover a path from source to destination. Taking AODV as an example, we describe its route discovery procedure. Figure 1(a) shows RREQ flooding from source to
(a) RREQ flooding in route discovery
(b) RREP is sent back to the source
Figure 1. AODV route discovery.
4
destination during route discovery. The source node floods RREQ to all neighbors and these neighbors rebroadcast the RREQ subsequently until the destination node is reached. In Figure 1(b), the node having a destination routing entry replies a RREP and the intermediate nodes forward the RREP to the source. To complete route discovery, flooded messages are forwarded in network. However, there are many unnecessary broadcast (flooded) messages which will degrade the network throughput and performance. To reduce broadcast messages, Vector-based Tracking Detection (V-TRADE) and History-enhanced V-TRADE (HV-TRADE) [12] classify neighbors into different forwarding groups by vehicle movement history. In these groups only some subsets of nodes rebroadcast messages. The mechanism improves bandwidth utilization with slightly loss of reachability. But it has a problem that it always selects the fastest vehicles. In a high speed scenario, the method will not be suitable.
The Urban Multi-Hop Broadcast protocol (UMB) [13] was designed to address broadcast storm, hidden node, and reliability problems of multi-hop broadcast in urban areas. It tries to solve the broadcast problem by selecting the furthest nodes as relay nodes to rebroadcast with at least two-way handshakes every hop. PAODV [5] classifies the neighbors into prior neighbors and overhead neighbors. Prior neighbors have higher priority to be selected as rebroadcast nodes. In addition, PAODV restricts the number of route discovery requests to reduce control overhead. But the selection is only based on the distance between source and neighbor. The reliability of routing paths can’t be ensured.
2.2 Mobility prediction
Mobility prediction is a very efficient technique to estimate the link expiration time in wireless network. We know that frequent topology changing in ad hoc networks is a big problem that we have to solve. If we can calculate the link expiration time between nodes, the route discovery will be more reliable and efficient. With the expiration time estimation, we can choose the nodes with longer link expiration time to be the rebroadcast nodes or relay
5
nodes. As a result, routing paths might have more reliability and stability. To apply mobility prediction in VANETs, we assume that all vehicles have their clock synchronized and the mobility parameters of each vehicle. The mobility parameters are available through GPS device which is equipped in the OBUs. Let (xi, yi) and (xj, yj) be the coordinates of vehicles i and j, and the corresponding velocities are vi and vj . Also we let θi and
θj
(0≤θ ,θ ≤ 2π
j
i ) represent the moving direction of vehicles i and j. The link expiration time, also called link lifetime Dt , can be the presented as follows [4]:
2
Mobility prediction is widely applied to VANET. In [2], the authors took advantage of mobility prediction and the direction tracing scheme to make the routing protocol, DSR, more efficient and reliable. In [3], a reliable broadcast routing scheme called RB-MP was proposed.
RB-MP uses mobility prediction to reduce control messages when broadcasting. The scheme selects reliable and efficient rebroadcast nodes according to the predicted holding time provided by positions and relative velocities. In the proposed scheme, the mobility prediction
6
will be proposed in an indirect way to reduce computing complexity. When two vehicles have high moving similarity, the link expiration time between them will be longer.
2.3 Problem statement
As we have mentioned, each node changes its position, direction and speed freely in VANETs. That is, the network topology changes rapidly and frequently. Therefore, reliable routing in VANETs is a significant research challenge. There are two main problems that we want to resolve in this thesis, reliability of routing paths and flooding problems. To ensure the reliability of data transmissions, we have to design an efficient and reliable rebroadcast nodes (vehicles) selection mechanism. By a proper vehicle selection mechanism, we can establish stable routing paths to support good quality data transmissions. Furthermore, the flooding mechanism may cause broadcast storm and generate too many unnecessary messages which will degrade network throughput. With a proper broadcast mechanism, route discovery can be efficient and data transmission quality can be enhanced.
7
Chapter 3
Proposed Reliable Routing Scheme Based on Vehicle Moving Similarity
The goal of the proposed reliable routing scheme based on moving similarity (RR-VMS) is to find a reliable routing path to provide a high quality transmission environment for routing in highways and to reduce control messages. RR-VMS can be divided into two phases, the neighbor information maintenance phase and the route discovery phase.
3.1 Neighbor Information maintenance phase
3.1.1 Hello messages exchange
In order to determine reliable paths, information about neighbors within the vehicle transmission range needs to be maintained. Thus, vehicles periodically send HELLO (or beacon) messages. A HELLO message was originally designed to determine network connectivity. Nodes locally broadcast HELLO messages to their one-hop neighbors. That is, the TTL (time-to-live) of a HELLO message is set to 1. Such neighbor information may be recorded in a neighbor list [10, 11]. The neighbor list can be showed as < ID, Expiration time
>, where ID is the ID of a neighbor vehicle and expiration time is the lifetime of this neighbor.
When a node receives a HELLO message, it refreshes or adds the neighbor information of the sender to the neighbor list and the routing table. Figure 2 illustrates HELLO messages exchange between vehicles. For the proposed RR-VMS, a new field position is added to the original HELLO message, where position is the GPS coordinate (x, y) of a vehicle.
8
3.1.2 Vehicle persistence score
Choosing vehicles with similar velocities as rebroadcast nodes for finding routing path is an important issue for reliable VANET routing. In the proposed RR-VMS, we do not need to record the speed of neighbors. Instead, we use a vehicle persistence score (VPS) mechanism to choose rebroadcast nodes. In addition to maintaining a neighbor list, in RR-VMS, each vehicle needs to maintain a VPS table. The VPS table and the neighbor list are updated concurrently when a vehicle receives a HELLO message from a neighbor vehicle.
The format of each entry in the VPS table is <ID, position, distance, type, VPS >.
ID: a neighbor’s ID.
Position: the GPS coordinate (x, y) which stands for the position of a vehicle. We
use this information to determine the distance between two vehicles.
Distance: the distance between a vehicle and the neighbor.
Type: the type of this neighbor.
VPS: the value we use to reflect a vehicle’s stability. Vehicles use this parameter to
select rebroadcast nodes.
We calculate the distance between a node and one of its neighbors by the GPS information recorded in position field. The distance field is used to classify neighbors into
Figure 2. HELLO messages exchange between vehicles.
9
two types: high priority neighbors and low priority neighbors, and this information is recorded in the type field. We set a threshold 1/3 R [5, 6, 7] for the classification of neighbor vehicles, where R is the transmission range of a vehicle. As showed in Figure 3, the radius of the inner circle is 1/3 R and the radius of the outer circle is R. A neighbor vehicles located inside the inner circle is called a high priority neighbor. Otherwise, it is a low priority neighbor. In Figure 3, vehicles A, B, E, F, G are high priority neighbors of the source because they are not located inside the inner circle, while vehicles C and D are low priority neighbors.
The purpose of neighbor classification is that vehicles too close to the source vehicle are less helpful for efficiency of the route discovery procedure; they don’t cover much additional space than the source.
In the following, we describe how to maintain the VPS in a vehicle. When a vehicle receives a HELLO message from a neighbor for the first time, it adds the neighbor’s related information to the neighbor list and the VPS table, and initializes the neighbor’s VPS to 1. If the neighbor’s information has been recorded before, the vehicle refreshes the neighbor’s information and increases the neighbor’s VPS by 1. To avoid the unlimited increasing of the VPS value, we set a maximum for the VPS, called VPS limit. When a VPS reaches the VPS
Figure 3. High priority neighbors and low priority neighbors.
10
limit, the VPS will not be incremented anymore. The setting of the VPS limit is based on the requirements of an application. An application demanding high reliability can set a higher VPS limit and vice versa. An example of VPS maintenance is showed in Figure 4(a) where the source receives HELLO messages from its neighbors for the first time, and updates the
(a) VPSs are initialized when receiving HELLO messages for the first time.
(b) VPSs value are incremented when receiving a second HELLO message.
Figure 4. VPS initialization and update when receiving HELLO messages
11
VPS table. (Note that only the VPS field in the VPS table is showed). In Figure 4 (a), the source receives HELLO messages from vehicles A, B, C, D, E, F and G, so the VPS’s of these vehicles are initialized to 1. Figure 4 (b) shows the VPS values after the second update.
Vehicles C, D, E, F and G still stay in the transmission range and their HELLO messages are received by the source, so their VPS’s are incremented 2. The entries for the vehicles that are not neighbors of the source anymore will be removed from the VPS table (e.g. vehicles A and B). A new vehicle’s (e.g. vehicle H) information can be added to the neighbor list and its VPS is set to 1 if its HELLO message was receiving by the source. According to the VPS information, it implies that vehicles with higher VPS tend to stay in the source’s transmission range longer. With the VPS information, we can select a stable vehicle to be a rebroadcast node.
The VPS maintenance procedure is showed in Figure 5. When a node receives a HELLO message, it either adds the node’s information to the neighbor list and VPS table or refreshes the sender’s information if the sender’s information has been recorded. Since neighbors’
VPS’s can be updated when receiving their HELLO messages, the VPS can represent a long term observation for a neighbor. If the VPS of a neighbor is high, we conclude that the neighbor drives in a similar velocity with the source vehicle and will stay in the transmission range of the source vehicle for a long time. In summary, the VPS is used to determine the stability of nodes for the rebroadcast nodes selection in the proposed RR-VMS.
12
3.2 Route discovery phase
In the information maintenance phase, we have got the information including a neighbor’s position, neighbor type, and VPS. In the route discovery phase, RR-VMS will take advantages of the information to make route discovery more efficient.
3.2.1 Number of rebroadcast nodes restriction
As mentioned in Chapter 2, reactive protocols broadcast RREQ to neighbors to find the destination. However, RREQ broadcasting will result in too many control messages. To reduce control messages, RR-VMS restricts the number of nodes that can rebroadcast the RREQ message. We define a parameter REBROADCAST_NUMBER to limit the number of nodes broadcasting RREQ. For example, when a node generates or forwards a RREQ
Figure 5. The VPS maintenance procedure.
13
message, only three neighbors will rebroadcast this request if REBROADCAST_NUMBER is set to 3.
3.2.2 Rebroadcast node selection
To establish reliable routing paths, we have to ensure the stability of the nodes that rebroadcast RREQ. In the neighbor information maintenance phase, RR-VMS has classified neighbors into high or low priority neighbors. That is, high priority neighbors have a high priority to be selected as rebroadcast nodes, and vice versa. This neighbor classification can help RR-VMS to include vehicles in the candidates list of rebroadcast nodes. However,, the stability of high priority neighbors needs to be ensured. RR-VMS chooses the vehicles with higher stability from the candidate list. Note that, in the neighbor information maintenance phase, we obtain the VPS which represents the stability of a neighbor vehicle. When the speed of a neighbor vehicle is similar to that of the source vehicle, the link between them will have a long link expiration time. In other word, such a link is more reliable. When a vehicle has a higher VPS, it will have a higher probability to be selected as a rebroadcast node. Considering both a node’s type and VPS, the rebroadcast node selection procedure is described in the following five steps, as showed in Figure 6:
When a node wants to send a RREQ message, it checks its VPS table:
Step 1: Select high priority neighbors
Step 2: Eliminate those neighbors that are not located between source and destination (optional)
Step 3: Sort the remaining neighbors by VPSs
Step 4: Pick the first i neighbors as rebroadcast nodes, where i = REBROADCAST_NUMBER.
Step 5: Record these neighbors’ ID’s in the rebroadcast nodes list
In Step 2, if the position (GPS coordinate (x, y)) of the destination is known, we can
14
determine whether a neighbor is between source and destination or not. If the destination’s position is unknown, RR-VMS will skip this step. The rebroadcast nodes list in Step 5 is a
Figure 6. The rebroadcast nodes selection procedure
15
table to record the ID of a neighbor that was selected during the execution of the rebroadcast nodes selection procedure. In Figure 7, vehicles C, E, F and G have the highest VPS (= 4).
However, vehicle C is not a high priority neighbor and G is not located in the direction between source and destination, so only vehicles E and F will be chosen as rebroadcast nodes.
The ID of the selected rebroadcast nodes will be recorded in the route request message (RREQ) and the RREQ is broadcast to all neighbors of the source.
However, if the selected neighbors in Step 4 are not enough (i.e. less than REBROADCAST_NUMBER), we still have to pick the neighbors eliminated in Steps 1 and 2.
When executing the rebroadcast node selection procedure, the vehicles eliminated during Steps 1 and 2 will be stored in a table called the backup table. The format of each entry in backup table is the same as that of the VSP table. We select vehicles from the backup table to fill up the rebroadcast node list. In the backup table, a high priority neighbor with higher VPS will have a higher probability to be selected.
Figure 7. The nodes with high VPS and belonging high priority neighbors will be selected as rebroadcast nodes
16
3.2.3 Route request (RREQ) rebroadcasting
After finishing the rebroadcast node selection procedure, we fill up the rebroadcast nodes list with chosen nodes. There are two conditions when a vehicle sends a RREQ message:
1. The vehicle is a source vehicle: In this case, the node executes the rebroadcast selection procedure and sends RREQ with IDs recorded in the rebroadcast nodes list.
2. The vehicle forwards a RREQ from another vehicle: When a vehicle receives a RREQ message, it will check if its ID matches the rebroadcast vehicles’ IDs recorded in the RREQ. If yes, the vehicle will forward the RREQ message. If not, the message will be dropped.
With the route request rebroadcasting scheme above, RR-VMS can reduce flooded control messages and make the route discovery more efficient.
17
Chapter 4
Simulation Results and Discussion
4.1 Simulation setup
We consider the scenario in a freeway to evaluate the performance of the proposed RR-VMS. The freeway has 4 lanes with the same direction and the length of the freeway is 2 km, and the width of each lane is 5m. The simulation is done in NS2.34 [9]. In the performance evaluation we will compare our approach RR-VMS with AODV [11], PAODV [5], and RB-MP [3]. The simulation setup is showed in Table 1. Our approach focuses on routing reliability. To evaluate routing reliability, we choose number of broken links, packet delivery ratio and routing overhead to be the comparison parameter.
Number of broken links: the number of error (RERR) message send.
Packet delivery ratio: this ratio metric finds the ratio of number of correctly
received packets at the destination vehicle to the number of packets sent by the source vehicle [16].
Routing overhead: the number of control messages needed to transfer a packet
successfully. (Note that control messages include RREQ, RERR, and RREP)
To capture characteristics of QoS sensitive applications, we use the real-time CBR traffic [2]. We set the sending rate of traffic as 10 packets/sec. The simulation result is the average of 10 simulation runs [5]. In each run, there is a CBR connection between two random nodes and the connection establishing time is also random.
18
In this simulation, the rebroadcast number of PAODV is set to 10 and the threshold distance is set to 100 m according to [5]. The REBROADCAST_NUMBER is set to 9 in the simulation. We determine REBROADCAST_NUMBER by simulating different values in our scenario. We found that, 9 is suitable for both low and high number of vehicles in the simulation. The simulation settings of RB-MP are based on [3].
Table 1. Simulation settings [2, 3, 5, 12]
Transmission range 250 m
MAC Protocol IEEE 802.11 Connection type CBR
Packet sending rate 10 packet/sec Data packet size 512 bytes Network area 2000 m x 20 m Lane number 4
Lane width 5 m Number of vehicles 30 ~ 70
Vehicle speed 60 - 80 km/h, 80 - 120 km/h Mobility model Freeway mobility model [8]
Simulation time 500 s
19
4.2 Simulation results
In Figure 8, we compare the number broken links among AODV, PAODV, RB-MP, and RR-VMS. The velocity is set between 60 km/h and 80 km/h. Figure 9 shows the comparison of number of broken links under the speed range of 80 km/h - 120 km/h. In the freeway mobility model, a higher speed range results in a higher speed variation of each vehicle.
Simulation results show that the proposed RR-VMS performs better under a high speed range.
This means our VPS mechanism can reflect the stability of a vehicle even in a high speed range scenario.
Speed range: 60 km/h - 80 km/h
Figure 8. The number of broken links under a different number of vehicles with a low.
speed range.
As showed in the above figure, the number of broken link
As showed in the above figure, the number of broken link