A Probabilistic Protocol for Multihop Routing in VANETs

Abstract

Vehicular ad hoc networks (VANETs) allow communications over sequences of vehicles with radio devices. There are many possible applications over a VANET such as traffic jam warning, collision warning, parking lot reservations, camera picture feed , and so forth. There have been quite a few results in the area seeking for a fast and reliable communication protocol due to their potential. VANETs, however, are pointed out as difficult for numerical optimizations due to frequent changes in their topologies. As a result, heuristic methods such as GPSR have been mainly used for routing packets over multihop communications. In this paper, we present an algorithm to precompute the probability that communication is possible between specified source and destination in a VANET, under certain mathematical assumption. The proposed new protocol for multihop communication refers to a lookup table containing the precomputed data to decide a good packet forwarder quickly. We create a simulation testbed that seems challenging for all the existing multihop routing protocols for VANETs, in which we test ours. We see much improved performances over GPSR after the algorithm is refined for some practical issues.

1. Introduction

Vehicular ad hoc networks (VANETs) enable communication between vehicles or between a vehicle and infrastructure. The idea of having intervehicle communications connected to a wired network has been investigated since the 1980s. Over a VANET, we can achieve traditional safety applications such as collision, icy road, and red light warnings, as well as nonsafety applications such as traffic information dissemination, reservation query, camera picture feed and so forth. Recently, there has been an emerging trend of utilizing mobile communication for environmental issues. It is possible to obtain significant information from VANETs to improve the uses of gas or other resources.

When there are not sufficient roadside units (RSUs) or direct communications between distant vehicles are preferred, it usually takes more than one step of vehicle-to-vehicle (V2V) communications to send information from a specified source to destination. The transmission range of a radio device is normally 100–200 m for V2V, which is much smaller than the dimension of the considered area. Researchers have studied such multihop communications extensively not only because VANET applications have a large market potential, but also they are scientifically interesting [1–5].

It has turned out very difficult to optimize parameters of a VANET due to its highly mobile nature. Links can be disconnected so frequently that it is occasionally impossible to accurately predict the existence of an end-to-end connection. Reference [6] sheds light on the theoretical aspect of this issue. As a result, carry-and-forward type heuristic methods have been mainly used for routing packets over multihop communications in VANETs.

The current most common scheme for source-destination routing in VANETs is the so-called geographical forwarding. It chooses car(s) closest to the destination 𝑑 and pass the packet. Geographical forwarding was first introduced as GPSR in [7]. The result has been referred to many other papers that seek a better performance by similar methods. One of them, called PBRV [8], resolves the routing loop problem of GPSR.

The main advantage of geographical forwarding is its computational speed per hop. It is a simple task to calculate the distance to 𝑑 for every car in the proximity, and quick computation is very important to forward a packet in short latency. However, we can easily create counter examples for geographical forwarding such as the ones seen in [2] and Figure 1. A similar situation may happen more frequently when the market penetration rate, that is, the ratio of the cars equipped with radio devices, is low.

Figure 1 

A counter example for geographical forwarding.

Another protocol called MDDV is developed in [9]. It uses the following two in addition to the geographical forwarding. (i)Trajectory-based forwarding: first determine an approximate trajectory from the source to the destination on the map then only considers cars that roughly follow it. (ii)Opportunistic forwarding: chooses some cars that meet certain conditions to give them the right to broadcast the packet in the proximity.

MDDV is designed for an arterial road or highway where considered cars are basically running in the same direction. It is reported to produce short latency and high delivery ratio in such a scenario but does not have a mechanism to treat a downtown situation.

Recently, a protocol called VADD has been proposed [4]. It considers the probability for a packet to reach the destination in addition to the positions and directions of the moving cars in the proximity. VADD handles a situation as in Figure 1 better than the previous two. It, however, calculates the probability at every intersection, seeming to have large invehicle computational time. It is based on the idea of dynamic path-selection approach. Nevertheless, one can point out that a large amount of the input information to VADD is static: the fixed probability for a packet to be sent successfully from one intersection to another.

There have been some other forwarding schemes known such as delaybounded routing [3], CAR [2], and GeOpps [1].

In this paper, we present an algorithm to precompute the probability that the communication is possible between specified source and destination in a VANET, under certain mathematical assumption. We propose a new protocol for multihop communication that refers to a lookup table containing the pre-computed data to decide a good packet forwarder quickly.

We create a simulation testbed that seems challenging for all the existing multihop routing protocols for VANETs, in which we test ours. After the algorithm is refined for some practical issues, it showed dramatically improved performances over GPSR.

The rest of the paper is organized as follows: in Section 2, we describe our general method to pre-compute such probabilities. Section 3 shows the simulation results, followed by conclusions stated in Section 4.

2. A Method to Precompute the Probability of Multihop Communication

The main idea of the probabilistic protocol we propose in this paper is to compute in advance the probability that it is possible to forward the packet from the source 𝑠 to destination 𝑑. We call it the communication probability from 𝑠 to 𝑑.

Suppose for simplicity that two cars can communicate whenever they are within a given transmission range 𝑅 of the radio. We will modify it later so the algorithm may better suit real situations. With this simplification, the communication from 𝑠 to 𝑑 is possible if and only if there is a sequence of cars to forward the packet as shown in Figure 2. We call such a sequence a communication path. Now, our communication probability is the probability that such a path exists. In this section, we present an efficient algorithm to compute the probability under certain assumption as well as a general way to measure its inputs. We will also consider how to refine the algorithm for practical use.

Figure 2 

An example of a communication path.

Figure 3 

The node differentiation problem.

2.1. Basic Notation

We assume that every considered object is on the map 𝑀 that is a Euclidean graph whose nodes are geographical locations or positions, and edges are roads. Denote by 𝑥a position on 𝑀, for which we write 𝑥∈𝑀 instead of 𝑥∈𝑉(𝑀). Let 𝑚 be the number of positions on 𝑀. Notice that 𝑥 is a two-dimensional vector.

Let 𝑅 be the transmission range of the radio. As stated before, we assume at this moment that any two cars within the distance can communicate with each other. A position 𝑥^′∈𝑀 is called an 𝑅-neighbor of 𝑥∈𝑀 if the Euclidean distance from 𝑥 to 𝑥^′ is at most 𝑅.

Consider that time 𝑡=0,1,2,…,𝑇 where 𝑇 is the time limit. To express that a car is at position 𝑥∈𝑀 when time is 𝑡, it is convenient to couple 𝑡 with 𝑥. A space time 𝑢=(𝑥,𝑡) is meant to be such pairing.

A carry is a pair ℎ=(𝑢₁,𝑢₂) of space times. It means that a car appears at 𝑢₁=(𝑥₁,𝑡₁) and moves to 𝑢₂=(𝑥₂,𝑡₂). We can understand carries as the solid arrows in Figure 2, while the dotted ones represent hops. We say 𝑥₁ and 𝑥₂ are the source and destination of the carry, and 𝑡₁ and 𝑡₂ are start and arrival time, respectively.

Formally, a communication path is a 𝑘-tuple 𝐸=(ℎ₁,ℎ₂,…,ℎ_𝑘) of carries ℎ_𝑖 such that the start time of ℎ_𝑖+1 equals the arrival time of ℎ_𝑖, and the source of ℎ_𝑖+1 is an 𝑅-neighbor of the destination of ℎ_𝑖 for every 𝑖<𝑘. We require the integer 𝑘 to be at most a given maximum number 𝐻 of hops. We can also say that 𝐸 is a communication path from 𝑢 to 𝑢^′, where 𝑢 is the first space time of ℎ₁ and 𝑢^′ the second one of ℎ_𝑘. The arrival time and destination of 𝐸 are defined as those of 𝑢^′, respectively.

Let a source 𝑠 and destination 𝑑 be given. A space time 𝑢=(𝑥,𝑡) is said to be reachable from (𝑠,0) in 𝑘 hops if there exists a communication path from (𝑠,0) with no more than 𝑘 carries whose destination is an 𝑅-neighbor of 𝑥 and arrival time is at most 𝑡. The communication probability 𝜌(𝑠,𝑑,𝑇) from 𝑠 to 𝑑 with time limit 𝑇 is the probability that (𝑑,𝑇) is reachable from (𝑠,0) in 𝐻 hops.

Figure 2 shows a communication path from (𝑠,0) to (𝑑^′,𝑡) with 4 carries and 3 hops. The space time (𝑑,𝑡) is reachable from (𝑠,0) in 4 hops.

Our goal in this mathematical framework is to compute 𝜌(𝑠,𝑑,𝑇) efficiently. Once we have the communication probabilities, the averages of other various random variables could be computed quickly. For example, the expected delay time 𝜏(𝑠,𝑑) to send a packet from 𝑠 to 𝑑 is𝜏(𝑠,𝑑)=^𝑇_𝑡=1𝑡(𝜌(𝑠,𝑑,𝑡)−𝜌(𝑠,𝑑,𝑡−1))=𝑇𝜌(𝑠,𝑑,𝑇)−^𝑇−1_𝑡=0𝜌(𝑠,𝑑,𝑡). (1)

2.2. Assumptions to Reduce the Hardness of Computation

Denote by (𝐴,𝑢) the probabilistic event that car 𝐴 appears at space time 𝑢 and by 𝑃(𝐴,𝑢) its probability. In the rest of the paper, 𝑃(⋅) expresses the probability of the argument event, where we omit obvious parentheses, thatis, write 𝑃(𝐴,𝑢) instead of 𝑃((𝐴,𝑢)) and so forth. Let Ω be the set of all (𝐴,𝑢). Logical sum, product, and implication are denoted by ⋁, ⋀, and an arrow, respectively. Consider the discrete probability space (Ω,ℱ,𝑃) as in Appendix A, where ℱ is the set of events over Ω. We will have all formal discussions in this framework.

The probabilities 𝑃(𝐴,𝑢) are not sufficient information to compute the exact values of 𝜌(𝑠,𝑑,𝑇), because the events (𝐴,𝑢) possibly depend on each other even for a single car 𝐴. For example, 𝑃((𝐴,𝑢₁)⋀(𝐴,𝑢₂)) may not be 𝑃(𝐴,𝑢₁)𝑃(𝐴,𝑢₂) due to the dependence; if paths from the source 𝑠 to 𝑢_𝑖 overlap, 𝑃(𝐴,𝑢_𝑖) affect each other.

We formulate the problem of computing communication probabilities as follows; given a map 𝑀, initial positions of cars, time limit 𝑇, and transmission range 𝑅, assume that subsequent movements of two cars are independent of each other. That of every car 𝐴 is restricted so that 𝑃((𝐴,𝑢₂)|(𝐴,𝑢₁)) is a given fixed value, where 𝑢₁=(𝑥₁,𝑡) and 𝑢₂=(𝑥₂,𝑡+1) are space times, and 𝑃(⋅|⋅) denotes conditional probability as defined in Appendix A. It means that the probability of 𝐴 moving from 𝑥₁ to 𝑥₂ is given when time transits from 𝑡 to 𝑡+1. Compute the communication probability from 𝑠∈𝑀 to 𝑑∈𝑀 for all the pairs of 𝑠 and 𝑑 from the above information. This problem seems hard to compute in polynomial time. We, in fact, conjecture that it is NP-complete even when the input instance is restricted such that the number of possible routes taken by each 𝐴 is bounded by a polynomial in the problem size. (We define the size as the number of cars added by 𝑚+𝑇+𝐻.) The difficulty is attributed to the dependence between communication paths that are events in ℱ.

We introduce the following assumption to reduce the hardness of computation. Denote by [𝑢,𝑘] the event in ℱ that the space time 𝑢 is reachable from (𝑠,0) in 𝑘 hops.

Steady traffic assumption: the following two are true in (Ω,ℱ,𝑃).(i)All the carries are independent.(ii)[𝑢,𝑘] for each 𝑘≤𝐻 are independent.

If it is true, the probability 𝑃([𝑢,𝑘]) takes a value that only depends on 𝑢 for each fixed 𝑘, letting the reachability to 𝑢 not affect each other. Then, the algorithm shown in Section 2.3 will compute the communication probability exactly.

There are some input instances for which the assumption holds strictly. One such case is significant: when we have the exact schedule of every car, or (𝐴,𝑢) satisfy the following.

Exact schedule assumption: 𝑃(𝐴,𝑢) is either 1 or 0 for every car 𝐴 and space time 𝑢.

It means that it is either true or false if 𝐴 appears at 𝑢. The following lemma says that it is only a special case of the steady traffic assumption.

Lemma 1. The exact schedule assumption implies the steady traffic assumption.

Proof. Suppose that 𝑃(𝐴,𝑢) is either 0 or 1 for every (𝐴,𝑢). The probability of (𝐴,𝑢) given any condition is either 0 or 1. The probability that a communication path occurs is 0/1. Thus, 𝑃([𝑢,𝑘]) is also 0/1 for any 𝑘≤𝐻. The event [𝑢,𝑘] is independent of the others as the last paragraph in Appendix A says. Since carries (𝑢,𝑘) have probabilities 0 or 1, it implies the steady traffic assumption.

Thus, if we have exact schedules of the cars, we can simply use the algorithm in Section 2.3 setting 𝑃(𝐴,𝑢)=1/0 to compute the exact communication probability.

A natural question occurs; how true is steady traffic assumption in real traffic scenes? We think that [𝑢,𝑘] and carries are well independent in practice if considered 𝑢=(𝑥,𝑡) are distinct enough. Events [𝑢,𝑘] with similar 𝑥 and 𝑡 affect each other, since they share large common parts of major communication paths. In Section 3, we compare the performance of the probabilistic protocol with that of GPSR in a challenging simulation testbed. We choose 100 m and 5 seconds as the unit differences of 𝑥 and 𝑡, respectively, to avoid considering similar 𝑢 too often. With the coarse resolutions, the probabilistic protocol will successfully capture the tendency of the vehicle mobility to contribute to good communication performances.

2.3. The Basic Algorithm

We show below our basic algorithm to compute communication probabilities. Its primary input is the carry probability 𝑃(𝑢₁,𝑢₂) that there exists a car that appears at the space time 𝑢₁ and moves to 𝑢₂ for every carry (𝑢₁,𝑢₂).

Notice that (𝑢₁,𝑢₂)=_everycar𝐴(𝐴,𝑢₁)(𝐴,𝑢₂), (2) in the probability space (Ω,ℱ,𝑃), since the carry (𝑢₁,𝑢₂) is the event in ℱ that some 𝐴 appears at 𝑢₁ and moves to 𝑢₂. Recall the problem of computing communication probabilities formulated in Section 2.2. Since the conditional probability of (𝑥₂,𝑡+1) given that (𝑥₁,𝑡) is input for all 𝑥_𝑖 and 𝑡, it means that the probability of the event (𝐴,𝑢₁)⋀(𝐴,𝑢₂) is determined uniquely. Movements of distinct cars are independent. The probability of the carry (𝑢₁,𝑢₂) is uniquely determined by the input instance of the problem.

Now, assume the steady traffic assumption. SteadyTraffic illustrated in Algorithm 1 computes the communication probability for any given pair of source and destination.

Algorithm SteadyTraffic Inputs:  𝑇: time limit, 𝐻: maximum number of hops, 𝑀: map with 𝑚 positions, 𝑅: transmission range,   𝑃(𝑢1,𝑢2): carry probability for every (𝑢1,𝑢2), that is, probability that a car appears at space time 𝑢1 and moves to 𝑢2, 𝑠,𝑑∈𝑀: source and destination on the map 𝑀. Output:  Communication probability 𝜌(𝑠,𝑑,𝑇) from 𝑠 to 𝑑 with time limit 𝑇. begin   (1). /∗ The final value of Answer(𝑥,𝑡,𝑘) will be the probability that there   exists a communication path from (𝑠,0) to (𝑥,𝑡) with at most 𝑘 carries. ∗/   (2). For every space time 𝑢=(𝑥,𝑡) do Answer(𝑥,𝑡,0)=0;   (3). Answer(𝑠,0,0)=1;   (4). for 𝑘=1 to 𝐻 do   4-1. for every space time 𝑢=(𝑥,𝑡) do    4-1-1. Answer(𝑥,𝑡,𝑘)=𝑃((𝑠,0),𝑢);    4-1-2. for every other space time 𝑢1=(𝑥1,𝑡1) such that 𝑡1≤𝑡 do      4-1-2-1. /∗ Let 𝐷(𝑥) for 𝑥∈𝑀 be the set of 𝑅-neighbors of 𝑥   ∗/      4-1-2-2. 𝑝1=1−∏𝑥2∈𝐷(𝑥1)(1−Answer(𝑥2,𝑡1,𝑘−1));      4-1-2-3. 𝑝2=𝑃(𝑢1,𝑢)⋅𝑝1;      4-1-2-4. Answer(𝑥,𝑡,𝑘)=Answer(𝑥,𝑡,𝑘)(1−𝑝2)+𝑝2;    4-1-3. end for   4-2. end for   (5). end for   (6). return 1−∏𝑥∈𝐷(𝑑)𝑡≤𝑇(1−Answer(𝑥,𝑡,𝐻)); end

Algorithm 1 

Its correctness proof is found in Appendix B. We will present a general method to obtain 𝑃(𝑢₁,𝑢₂) from field data in Section 2.4 and a more practical version in Section 2.5.

The asymptotic running time of SteadyTraffic is found 𝑂(𝐻𝑚²𝑇²𝑅²) in a straightforward manner. In our simulation test with a careful choice of the parameter set, it runs in few minutes to finish computation for each 𝑠 and 𝑑.

If the exact schedule assumption holds, 𝑃(𝑢₁,𝑢₂) is 1 if and only if there exists a car 𝐴 such that 𝑃(𝐴,𝑢₁)𝑃(𝐴,𝑢₂)=1. We can input them into SteadyTraffic to compute 𝜌(𝑠,𝑑,𝑇).

2.4. To Measure Carry Probabilities from Field Data

The primary input to Algorithm SteadyTraffic is the probabilities of 𝑃(𝑢₁,𝑢₂) of the carries. Theoretically, all we need is 𝑃((𝐴,𝑢₁)⋀(𝐴,𝑢₂)) for every car 𝐴 and space times 𝑢_𝑖 that is, the probability that the given car 𝐴 appears at 𝑢₁ and moves to 𝑢₂. Then, the carry probability is computed as𝑃(𝑢₁,𝑢₂)0=1−_everycar𝐴(1−𝑃((𝐴,𝑢₁)(𝐴,𝑢₂))), (3) by (1) and (3).

There are ways to compute 𝑃((𝐴,𝑢₁)⋀(𝐴,𝑢₂)) from field data. The following two steps provides a general one.

Measure the intersection probabilities
Some nodes 𝑣 on the map 𝑀 represent intersections. The edges 𝑙 from 𝑣 are the roads from 𝑣. The intersection probability 𝑄(𝑙,𝑙′,𝑣) is the probability that a car moves from the road 𝑙 to 𝑙^′ at the intersection 𝑣. We first measure this quantity from real field data, by simply finding the ratio of the cars to choose the road 𝑙^′ out of all the cars running toward 𝑣 on 𝑙.

Calculate 𝑃((𝐴,𝑢₁)⋀(A,𝑢₂))
We repeat the process below for a number of times to average the obtained values of 𝑃((𝐴,𝑢₁)⋀(𝐴,𝑢₂)). At the beginning of each round, we configure the initial positions of the cars randomly but based on the real statistics. Then, do the following: (1)fix each carry (𝑢₁,𝑢₂) and car 𝐴. Let 𝑢_𝑖=(𝑥_𝑖,𝑡_𝑖) for 𝑖=1,2.(2)At time 𝑡=0,1,2,…,𝑡₁, simulate the probabilistic movements of the car using the intersection probabilities so that we know the probability of 𝐴 being at (𝑥,𝑡) for all 𝑥∈𝑀 and 𝑡≤𝑡₁. In the end, we know the probability of 𝐴 at 𝑢₁=(𝑥₁,𝑡₁). Store it into 𝑝₁.(3)Fix the position of 𝐴 at 𝑡=𝑡₁ as 𝑥₁. Simulate the probabilistic movements of 𝐴 at time 𝑡=𝑡₁+1,𝑡₁+2,…,𝑡₂. Find the probability of 𝐴 at (𝑥₂,𝑡₂), and store it into 𝑝₂. (4)Now, 𝑃((𝐴,𝑢₁)⋀(𝐴,𝑢₂))=𝑝₁⋅𝑝₂ is the probability that 𝐴 appears at 𝑢₁ and moves to 𝑢₂.

2.5. Practical Refinements

Although the method described so far is mathematically correct for the presented mobility model, we faced essential difficulties when we implemented SteadyTraffic on a testbed described in the next section. Abstracting the problems, we devised a variant of SteadyTraffic that is meant to be used for practice. It is illustrated in Algorithm 2 as SteadyTraffic 2.

Algorithm SteadyTraffic2 Inputs:  𝑇, 𝐻, 𝑀, 𝑅, 𝑃(𝑢1,𝑢2), 𝑠,𝑑∈𝑀: same as SteadyTraffic,   𝜉(𝑥1,𝑥2): 1 hop packet error ratio from 𝑥1∈𝑀 to 𝑥2∈𝑀,  𝑒(𝑥): expected car density at 𝑥∈𝑀,  𝛽,𝜖∈(0,1): numeric parameters,  𝑑𝑖𝑟∈{(0,−1),(0,1),(1,0),(−1,0)}: vector representing the moving   direction. Output:   Approximate communication probability 𝜌(𝑠,𝑑,𝑇) from 𝑠 to 𝑑 with time limit 𝑇. begin   (1). For every space time 𝑢=(𝑥,𝑡) do Answer(𝑥,𝑡,0)=0;   (2). Answer(𝑠,0,0)=1;   (3). for 𝑘=1 to 𝐻 do   3-1. for every space time 𝑢=(𝑥,𝑡) do    3-1-1. Answer(𝑥,𝑡,𝑘)=𝑃((𝑠,0),𝑢);    3-1-2. for every other space time 𝑢2=(𝑥2,𝑡2) and 𝑢1=(𝑥1,𝑡2)      such that      i) 𝑡2≤𝑡, ii) 𝑥1∈𝐷(𝑥2), iii) 𝑃(𝑢1,𝑢)≥𝜖,      iv) (𝑥1−𝑥2)⋅𝑑𝑖𝑟≥0 and iv) (𝑥−𝑥1)⋅𝑑𝑖𝑟≥0      /∗ 𝐷(𝑥) is the set of 𝑅-neighbors of 𝑥∈𝑀 ∗/      /∗ ⋅ represents the inner product of two vectors ∗/      do     3-1-2-1. 𝑝1=𝑃(𝑢1,𝑢)(𝑒(𝑥1)𝑒(𝑥))𝛽;     3-1-2-2. 𝑝2=Answer(𝑥2,𝑡2,𝑘−1)(1−𝜉(𝑥1,𝑥))𝑝1;     3-1-2-3. Answer(𝑥,𝑡,𝑘)=Answer(𝑥,𝑡,𝑘)(1−𝑝2)+𝑝2;    3-1-3. end for   3-2. end for    (4). end for    (5). return 1−∏𝑥∈𝐷(𝑑)𝑡≤𝑇(1−Answer(𝑥,𝑡,𝐻)(1−𝜉(𝑥,𝑑)));  end

Algorithm 2 

A practical variant of SteadyTraffic.

We summarize below general deployment problems and our solutions in the modified algorithm. First, values computed by SteadyTraffic may include propagated errors. As stated as the steady traffic assumption in Section 2.2, we want the reachability events [𝑢,𝑘] and carries to be well independent of others. If we consider [𝑢,𝑘] with similar space times 𝑢=(𝑥,𝑡) too often, it is likely to increase the calculated communication probability much more than the real value. In other words, space times whose car density is large may not be much different from those with small density for the algorithm SteadyTraffic.

We multiply, to handle the problem, carry probabilities 𝑃(𝑢₁,𝑢₂) by (𝑒(𝑥₁)𝑒(𝑥₂))^𝛽, where 𝑢_𝑖=(𝑥₁,𝑡_𝑖) are space times, 𝑒(𝑥) are the expected car densities at 𝑥∈𝑀, and 𝛽∈(0,1) is a numeric parameter to adjust. Step3-1-2-1 of SteadyTraffic2 performs this data modification. It has an effect of emphasizing the differences between large and small car densities. We will choose 𝛽=1/2 in Section 3.

We could also use coarse space and time resolutions to prevent the error propagation, that is, to use large values of unit differences of 𝑥 and 𝑡 to avoid introducing similar 𝑢=(𝑥,𝑡). It also speeds up the algorithm significantly.

Loop 3-1-2 of SteadyTraffic2 has a slightly different structure from 4-1-2 of SteadyTraffic; the former finds any new carry (𝑢₁,𝑢) in the proximity of 𝑢₂ such that i)–v) and updates Answer(𝑥,𝑡,𝑘) at 𝑢 simply assuming that the newly detected communication path is independent of the others. Condition iii) discards carries of low probabilities.

The above schemes of simplification and data modification effectively compute good approximate values of communication probability with reasonable computational time. This practically solves our first problem of error propagation.

Secondly, we have a node differentiation problem. Even if the communication probabilities are accurate, it is occasionally hard in run time to choose a good packet forwarder among the nearby vehicles. We illustrate the problem in Algorithem 1. To resolve it, we restrict considered communication paths so that they are not extended in a specified direction. Conditions iv) and v) of Loop 3–1–2 filter every path with 𝑥- or 𝑦-component running in the opposite direction to given 𝑑𝑖𝑟. We call it north, south, west, and east mode when 𝑑𝑖𝑟=(0,−1),(0,1),(1,0),and(−1,0), respectively. (The map origin is supposed to locate at the upper-left corner.) For example in the north mode, SteadyTraffic 2 does not extend a communication path to location more southern than the current position. It is suggested to combine values of more than 1 modes to refer to in run time to find a good packet forwarder.

Third, the probability of successful packet transmission is usually not uniform in a real traffic scene. We approximate it by its time average, that is, we assume that 1-hop packet error ratio 𝜉(𝑥₁,𝑥₂) varies over positions 𝑥_𝑖∈𝑀 and is constant over time. Steps 3-1-2-2 and 5 of SteadyTraffic2 include related multiplications. We could use values of 𝜉 measured in field data possibly in conjunction with an analytical formula such as the one in [10].

3. Simulation Results

3.1. Testbed Design

We did a performance evaluation of the probabilistic protocol in a simulation testbed shown in Figure 4. Its dimension is 1000 m in height and 2000 m in width. A similar road configuration can be found in a big city in the United States such as the one in Chicago downtown. There are 121 intersections in total, the top-left and bottom-right ones of which are assumed to locate at the positions (0,0) and (1000,2000), respectively.

Figure 4 

The Simulation Testbed.

An RSU is placed at (0,1000). Roads 1, 11, 12, and 22 are called arterial and are busy, while the other paths are not. A car with a packet called packet holder enters the testbed at position (1000,𝑥) and time 0, where 𝑥 is either 0, 200, 400, 600, 800, or 1000. The cars keep moving in the next 70 seconds trying to forward the packet to the RSU.

Because the inner roads have sparser vehicles, and there is only one RSU in a fairly large area, it is not easy for the geographical forwarding scheme to have a packet reach the destination. The usual best way is to make a detour on arterial roads. It is essential to quickly inform the cars of a good forwarding path computed from the likelihood of packet reachability. However, the number of intersections is large so that there are many choices for a forwarding path. These make the testbed challenging for the existing routing protocols.

A car moves at the speeds of 35 and 25 mph on arterial roads and paths, respectively, except around intersections. Within a 50 m radius of every intersection, the car speed drops down to 15 mph. The following is the list of parameters input to the traffic simulator.(1)𝑟₁: the probability for a car to turn from an arterial road to another, or from a path to another. (2)𝑟₂: the probability for a car to turn from an arterial road to a path. (3)𝑟₃: the probability for a car to turn from a path to an arterial road. (4)𝑟₄: the probability that a car enters the testbed in each half second, at the start/end position of an arterial road. (5)𝑟₅: the probability that a car enters the testbed in each half second, at the start/end position of a path.

We tested two scenarios with different parameter sets shown in Table 1. Although the car movement rules are made relatively simple, both scenarios create traffic situations sufficiently realistic to a preliminary multihop packet forwarding test. Figure 4 is a snapshot of Scenario 1. Scenario 2 has sparser paths.

Table 1 

Parameter values to the traffic simulator.

In this setting, we assume transmission range 𝑅=150m with one hop packet error ratio 𝜉(𝑥₁,𝑥₂)=0.15 for every distinct pair of 𝑥_𝑖∈𝑀.

All the cars are equipped with radio devices sending their positions to the nearby cars per second as heart beat (beacon) messages. The relative velocity of two cars does not exceed 70 mph or 31.11 m/sec. With heartbeat messages broadcasted every second, where 𝑅=150𝑚, we can assume that each car 𝐴 knows by its background job the existence of every other car 𝐴^′ in the proximity. Once 𝐴 receives a packet, it quickly computes the necessary values for 𝐴^′ to decide the next packet holder.

It is a common agreement that the initialization time over IEEE 802.11 p standard is about 300 msec. The total time necessary to forward a packet is no more than 500 msec if it is not too large. Assume also that all the cars have a common clock so that packet transmission processes are performed in global half second time slots. The time resolution of the traffic simulator is set as 0.5 second.

Setting the maximum number 𝐻 of hops as 20, we run SteadyTraffic2 to pre-compute the communication probabilities. We averaged the values in the north and west modes in the left half of the testbed and the ones in the north and east modes in the right half. It took about 3 hours on average to finish computation for each scenario. We stored the obtained values in a lookup table to refer to in run time.

3.2. Decision for the Next Packet Holder

Now, we have a good set of communication probabilities 𝜌(𝑥,𝑥^′,𝑇) from 𝑥∈𝑀 to 𝑥^′∈𝑀 such that if 𝑥 or 𝑥^′ is on a path, they are usually distinguishably smaller than values with both 𝑥 and 𝑥^′ on arterial roads. However, it is still not obvious how to make a good decision for the next packet holder with 𝜌(𝑥,𝑥^′,𝑇).

We also pre-computed the effective average numbers ∑𝑘(𝑥)=^{0≤𝑡≤𝑇0<𝑘≤𝐻}𝑘(Answer(𝑥,𝑡,𝑘)−Answer(𝑥,𝑡,𝑘−1))∑_{0≤𝑡≤𝑇},Answer(𝑥,𝑡,𝐻) (4) of hops with Answer(𝑥,𝑡,𝑘) obtained when we run STEADY TRAFFIC. They turned out to be excellent index values for deciding a good packet forwarder.

Let Δ_𝐻(𝑥) be the horizontal distance from 𝑥∈𝑀 to 𝑑, and Δ_𝑉(𝑥) the vertical distance from 𝑥 to 𝑑. Furthermore, defineΔΔ(𝑥)=^𝐻(𝑥)ifΔ_H(s)≥Δ_VΔ(s),_𝑉(𝑥)otherwise. (5) It measures the distance to the destination from 𝑥 that is designed suitable for the probabilistic protocol.

In run time, decide the next packet holder as follows: if Δ(𝑥) is much smaller than Δ(𝑠), say at most 1/4, then we regard that the packet is approaching to the destination, so we choose, within the transmission range, a car closest to 𝑑 among the ones with relatively high values of 𝜌(𝑥,𝑑,𝑇) and low 𝑘(𝑥). If Δ(𝑥)>1/4Δ(𝑠), we choose a car farthest from 𝑠 with relatively high 𝜌(𝑥,𝑑,𝑇) and low 𝑘(𝑥), regarding that the packet is not close enough to the destination. We call the former and latter cases approach and detour modes, respectively.

More precisely, find if𝑆=(𝜌(𝑥,𝑑,𝑇)≥max_𝜌𝛼_𝜌)(𝑘(𝑥)≤min_𝑘𝛼_𝑘), (6),for every car at position 𝑥 in the proximity. Here, 𝛼_𝜌 and 𝛼_𝑘 are input constants, max_𝜌 is the maximum value of 𝜌(𝑥,𝑑,𝑇) and min_𝑘 the minimum value of 𝑘(𝑥) in the proximity, respectively. Setting 𝛼_𝜌=0.4 and 𝛼_𝑘=1.05 in the approach mode, pass the packet to the car closest to 𝑑 such that 𝑆 is true. In the detour mode with 𝛼_𝜌=0.8 and 𝛼_𝑘=1.05, pass to the car farthest from 𝑠 such that 𝑆.

The above decision process is quick since it does not require heavy in-vehicle computation. The running time is comparable to that of GPSR.

3.3. Measured Data

We show the measured delivery ratio and delay time in Figure 5, plotting them over the horizontal position 𝑥 of the packet holder at time 𝑡=0. We executed 20 trials for both Scenarios 1 and 2, each of which run for 70 seconds. The performances of the probabilistic protocol are compared with those of GPSR. We summarize the related parameter values in Tables 2 and 3.

Table 2 

Run-time parameter values for data measurement.

Table 3 

Parameter values for steadytraffic2.

(a)

(b)

Figure 5 

Measured delivery ratio and delay time.

As mentioned before, we run SteadyTraffic2 in north and east modes for each source in the west half of the testbed. The east half is handled symmetrically. We took the average of the two modes to refer to in the run time.

When the probabilistic protocol run in both scenarios, we observed expected packet trajectories in most cases. They initially run on the south arterial road (no.22) either to east or west, then go north to reach the RSU on the north arterial road. Our scheme of switching from the detour to approach mode functioned well.

This did not happen for GPSR; occasionally, the packet could not find a forwarder in the north effectively so that it migrated in the middle of the testbed for a long time.

As a result, the probabilistic protocol dramatically improves the delivery ratio over GPSR. Its average delay time over all start position 𝑥 is smaller than that of GPSR. The improvement, however, is not as drastic as that of the delivery ratio. It is due to the lengths of trajectories why it tends to produce not too small latency, that is, packets move on a much longer way than those controlled by GPSR.

4. Conclusions

We have presented the notion of a communication path and probability in a general framework that handles the nature of multihop routing in a VANET. Under certain mathematical assumption, the communication probability is proven computed accurately by the algorithm SteadyTraffic. Use this quantity to decide a good packet forwarder in a real VANET. The simulated results show that the probabilistic protocol improves the performances much in a very challenging testbed, after the algorithm is refined for the practical issues.

For further research, it is significant to find a method to use SteadyTraffic or SteadyTraffic2 in real-time computation. It is possible that a car is provided road density information by an extra method such as cellular network. It would be nice if one can find, quickly without precomputation, good paths over V2V multihop communications for a packet or a group of packets. The running time of the algorithms must be improved much.

In addition, it is theoretically interesting to seek for a way to efficiently compute the probability of logical sum ∨_{((𝑒∈𝑆)𝑒)} for an event set 𝑆⊂ℱ that is not necessarily independent. The hardness of computing communication probabilities derives from the mutual dependence of communication paths. There may be a scheme for fast computation under an assumption of restricted dependence.

Appendices

A. Review for Independent Events in a Discrete Probability Space

A probability space is a triple (Ω,ℱ,𝑃), where Ω is the sample space, ℱ is the event set, and 𝑃∶ℱ→[0,1] the probability measure. For the formulated problem of computing communication probabilities, we have Ω: the set of (A, u), that is, the events that car A appears at space time u, ℱ: the set of all events over Ω, that is, the set of Boolean expressions in terms of(A,u), andP: probability that each event ℱoccurs.

This probability space (Ω,ℱ,𝑃) is discrete because Ω is finite.

A nonempty event set 𝑆⊆ℱ is said to be independent if𝑃(𝑒_{𝑒∈𝑆′})=_{𝑒∈𝑆′}𝑃(𝑒), (A.1) for every subset 𝑆^′ of 𝑆. Here, we regard that both hand sides are 1 if 𝑆^′ is empty. We also say that the elements in 𝑆 are independent events. The conditional probability of 𝑒∈ℱ given 𝑆 is ⋀𝑃(𝑒𝑠)=𝑃(𝑒∧_{𝑒′∈𝑆}𝑒^′)𝑃(⋀_{𝑒′∈𝑆}𝑒^′),if𝑃(⋀_{𝑒′∈𝑆}𝑒^′)≠0and𝑆≠∅,𝑃(𝑒),otherwise0. (A.2)

If 𝑆 is independent,𝑃(_𝑒∈𝑆𝑒)=1−_𝑒∈𝑆(1−𝑃(𝑒)) (A.3) holds. We can derive it formally from the well-known inclusion-exclusion principle. Intuitively, it is true since the probability that any 𝑒 occurs is 1 minus probability 𝑝 that none of them occurs. But 𝑝 is the product of 1−𝑃(𝑒) because the events 𝑒∈𝑆 are independent. The equation implies𝑃(_𝑒∈𝑆𝑒)=𝑃(_{𝑒∈𝑆−{𝑒0}}𝑒)+𝑃(𝑒₀)−𝑃(_{𝑒∈𝑆−{𝑒0}}𝑒)⋅𝑃(𝑒₀), (A.4) for each 𝑒₀∈𝑆.

The event set 𝑆 is independent if and only if 𝑃(𝑒|𝑆^′)=𝑃(𝑒) for every 𝑒∈𝑆 and subset 𝑆^′⊆𝑆 that does not contain 𝑒. Suppose that𝑃(𝑒|𝑆^′)=𝑃(𝑒) is true for each 𝑒 and 𝑆^′. By the definition of conditional probability 𝑃(𝑒∧⋀_{𝑒′∈𝑆′}𝑒^′)=𝑃(𝑒∣𝑆)⋅𝑃(⋀_{𝑒′∈𝑆′}𝑒^′)=𝑃(𝑒)⋅𝑃(⋀_{𝑒′∈𝑆′}𝑒^′). Thus, 𝑃(⋀_{𝑒∈𝑆′}𝑒)=𝑃(𝑒)⋅𝑃(⋀_{𝑒′∈𝑆′−{𝑒}}𝑒^′). Argue recursively for 𝑆−{𝑒} to have 𝑃(⋀_{𝑒∈𝑆′}𝑒)=∏_{𝑒∈𝑆′}𝑃(𝑒). Since it is true for any subset 𝑆^′⊆𝑆, 𝑆 is independent only if part is shown similarly.

We say e is independent of 𝑆 if 𝑃(𝑒∣𝑆^′)=𝑃(𝑒) for each 𝑆^′⊆𝑆. By the above claim, a nonempty event set 𝑆⊆ℱ is independent if and only if each 𝑒∈S is independent of 𝑆−{𝑒}.

An event 𝑒∈ℱ such that 𝑃(𝑒) is 1 or 0 is independent of ℱ−{𝑒}. It is intuitively clear that if the probability of 𝑒 is 1/0, 𝑒 either occurs or does not occur under any condition 𝑆⊂ℱ−{𝑒}, so 𝑃(𝑒∣𝑆)=1/0. We can formally prove it by considering the disjunctive normal form of 𝑒∧⋁_{𝑒′∈𝑆}(𝑒^′∨¬𝑒^′), that is, the logical sum of 𝑒∧𝑓₁∧𝑓₂∧⋯∧𝑓_𝑘, where 𝑓_𝑖 are either 𝑒_𝑖 or ¬𝑒_𝑖 for all 𝑒_𝑖∈𝑆.

B. Correctness of Algorithm SteadyTraffic

Theorem 1. Algorithm SteadyTraffic correctly computes the communication probability from s to d with time limit T, for every input instance satisfying the steady traffic assumption.

Proof
We show that the final value of Answer(𝑥,𝑡,𝑘) is the probability that there exists a communication path from 𝑢₀=(𝑠,0) to 𝑢=(𝑥,𝑡) with at most 𝑘 carries.

Prove it by induction on 𝑘. For its basis 𝑘=0, we regard true that there exists a communication path from 𝑢₀ to 𝑢₀ with zero carries by probability 1. Step3 sets Answer(𝑠,0,0) correctly.

To prove induction step, fix each space time 𝑢=(𝑥,𝑡) selected by Step 4-1. Denote by (𝑢,𝑘) the event that there exists a communication path from 𝑢₀ to 𝑢 with at most 𝑘 carries. The claim to be proven is rephrased asAnswer(𝑥,𝑡,𝑘)=𝑃(𝑢,𝑘)atstep4-2. (B.1) It is straightforward to prove it for 𝑘=1. Assume that 𝑘≥2.

Recall that [𝑢,𝑘] expresses the event that 𝑢=(𝑥,𝑡) is reachable from 𝑢₀ in 𝑘 hops, and 𝐷(𝑥) the set of 𝑅-neighbors of 𝑥. Let 𝑢₁=(𝑥₁,𝑡₁) be chosen by Step 4-1-2. Denote by 𝐷(𝑢) the set of space times (𝑥^′,𝑡) such that 𝑥^′∈𝐷(𝑥). The symbols satisfy the following relations: (𝑢,𝑘)=(𝑢₀,𝑢)∨[𝑢₁,𝑘−1](𝑢₁,𝑢),_{spacetimes𝑢1} (B.2)[𝑢₁,𝑘−1]=_𝑢2∈𝐷_(𝑢1)(𝑢₂,𝑘−1). (B.3) There is only one communication path from 𝑢₀ to 𝑢 with 1 carry, thatis, the carry (𝑢₀,𝑢) itself. Every other communication path passes a space time 𝑢₂=(𝑥₂,𝑡₁) that is reachable from 𝑢₀ in 𝑘−1 hops. The above relations are hence true. First, we prove the following general statement.

Lemma 2. For each 𝑘≤𝐻, the events (𝑢,𝑘) are independent.

Proof. By induction on 𝑘 with basis true by the steady traffic assumption (i). Assume true for 𝑘−1 and prove true for 𝑘.

Claim 1. each (𝑢₁,𝑢) in (B.2) is independent of [𝑢₁,𝑘−1] and the other (𝑢₁,𝑢).

Proof. [𝑢₁,𝑘−1] is a product of carries that are not equal to (𝑢₁,𝑢). The steady traffic assumption (i) implies the claim.

Claim 2. the sets 𝑆(𝑢₁)={(𝑢₂,𝑘−1);𝑢₂∈𝐷𝑢₁,𝑃(𝑢₂,𝑘−1)>0}, (B.4) for all the space times 𝑢₁ are pairwise disjoint.

Proof. Suppose that there are two 𝑢₁, say 𝑢¹₁ and 𝑢²₁, such that 𝑇=𝑆(𝑢¹₁)∩𝑆(𝑢²₁) is nonempty. The probability 𝑃([𝑢^𝑖₁,𝑘−1]) is the product of 𝑃(𝑢₂,k−1) for each 𝑖=1,2 and all 𝑢₂∈𝐷(𝑢^𝑖₁), by (B.3) with induction hypothesis. Since 𝑇 is not empty, it means 𝑃([𝑢¹₁,𝑘]∧[𝑢²₁,𝑘])≠𝑃([𝑢¹₁,𝑘])⋅𝑃([𝑢²₁,𝑘]). (B.5) The events [𝑢₁,𝑘] are not independent, which contradicts the steady traffic assumption (ii). Thus, 𝑆(𝑢₁) must be pairwise disjoint.

By the above two claims, the events (𝑢₀,𝑢), (𝑢₁,𝑢), and [𝑢₁,𝑘−1] in (B.2) are independent. By (A.3), 𝑃(𝑢,𝑘)=1−(1−𝑃(𝑢_0,𝑢))𝑃^′, (B.6) where𝑃^′=_{spacetimes𝑢1}(1−𝑃([𝑢₁,𝑘−1])𝑃(𝑢₁,𝑢)). (B.7)

Claim 3. let 𝑆^′(𝑢) be the union of 𝑆(𝑢₁) such that 𝑃(𝑢₁,𝑢)≠0. Then, they are pairswise disjoint for all the space times 𝑢.

Proof. Similarly to Claim 2. If there are two 𝑢, say 𝑢¹ and 𝑢², such that 𝑆^′(𝑢₁) and 𝑆^′(𝑢₂), are not disjoint, the probability 𝑃([𝑢¹,𝑘]⋀[𝑢²,𝑘]) is not 𝑃([𝑢¹,𝑘])𝑃([𝑢²,𝑘]).

We now see with (A.1) that each (𝑢,𝑘) is independent of the others. Consider two distinct 𝑢, say 𝑢¹ and 𝑢². The carries (𝑢₀,𝑢¹) and (𝑢₁,𝑢¹) are distinct from (𝑢₀,𝑢²) and (𝑢₁,𝑢²), respectively. The events [𝑢₁,𝑘−1] are independent by Claim 3 and induction hypothesis. They imply that (𝑢,𝑘) is independent of the others.

The lemma follows the above, completing the proof.

We verify below that Loop 4-1 correctly computes 𝑃(𝑢,𝑘) in Answer(𝑥,𝑡,𝑘). By the lemma, (B.6) holds throughout the process. Let 𝑈₁ be the set of 𝑢₁ chosen so far by Step 4-1-2. We prove by induction on its size that Answer(𝑥,𝑡,𝑘) currently holds the value of (B.6) for𝑃^′=_{𝑢1∈𝑈1}(1−𝑃([𝑢₁,𝑘−1])𝑃(𝑢₁,𝑢)). (B.8)

For its basis, the set 𝑈₁ is regarded as empty before Step 4-1-2 so that 𝑃^′ in is 1 and 𝑃(𝑢,𝑘)=𝑃(𝑢₀,𝑢). Step 4-1-1 correctly sets Answer(𝑥,𝑡,𝑘) for it.

To prove its induction step, assume Answer(𝑥,𝑡,𝑘) has the value of (A.1) for 𝑃^′=∏_{𝑢′1∈𝑈1−{𝑢1}}(1−𝑃([𝑢^′₁,𝑘−1])𝑃(𝑢^′₁,𝑢)), where 𝑢₁ is currently chosen by 4-1-2. Due to (6), where (𝑢₂,𝑘−1) are independent, Steps 4-1-2-2 and 4-1-2-3 compute 𝑃([𝑢₁,𝑘−1]) and 𝑃([𝑢₁,𝑘−1])𝑃(𝑢₁,𝑢) as 𝑝₁ and 𝑝₂, respectively.

Regard [𝑢₁,𝑘−1]⋀(𝑢₁,𝑢) as 𝑒₀ in (4), and [𝑢^′₁,𝑘−1]⋀(𝑢^′₁,𝑢) and (𝑢₀,𝑢) as the other events in 𝑆. Step 4-1-2-4 correctly computes 𝑃(𝑢,𝑘) in (B.6) for 𝑈₁ as Answer(𝑥,𝑡,𝑘). This proves the induction step.

We have shown that Answer(𝑥,𝑡,𝑘)=𝑃(𝑢,𝑘) at Step 4-2. Finally, Step 6 computes the probability that the space time (𝑑,𝑇) is reachable from 𝑢₀=(𝑠,0) in 𝐻 hops, returning 𝜌(𝑠,𝑑,𝑇) correctly. This completes the proof of the theorem.