Table of Contents Author Guidelines Submit a Manuscript
Journal of Electrical and Computer Engineering
Volume 2010, Article ID 185791, 11 pages
http://dx.doi.org/10.1155/2010/185791
Research Article

A Probabilistic Protocol for Multihop Routing in VANETs

Toyota InfoTechnology Center USA, c/o Telcordia Technologies, One Telcordia Drive, Piscataway, NJ 08854-4157, USA

Received 25 February 2010; Accepted 10 August 2010

Academic Editor: Soumaya Cherkaoui

Copyright © 2010 Junichiro Fukuyama. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

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 [15].

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.

185791.fig.001
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.

185791.fig.002
Figure 2: An example of a communication path.
185791.fig.003
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 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 equals the arrival time of , and the source of 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 in hops if there exists a communication path from 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 in hops.

Figure 2 shows a communication path from to with 4 carries and 3 hops. The space time is reachable from 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

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, , 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 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 . 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 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 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 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 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.

alg1
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 . 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 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
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 .(2)At time , 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 . 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.

alg2
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 is a numeric parameter to adjust. Step-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 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 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 , 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 -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 and , respectively.

185791.fig.004
Figure 4: The Simulation Testbed.

An RSU is placed at . 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 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.

tab1
Table 1: Parameter values to the traffic simulator.

In this setting, we assume transmission range with one hop packet error ratio 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 , 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 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 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 , 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,for every car at position in the proximity. Here, and are input constants, is the maximum value of and the minimum value of in the proximity, respectively. Setting and in the approach mode, pass the packet to the car closest to such that is true. In the detour mode with and , 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 . 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.

tab2
Table 2: Run-time parameter values for data measurement.
tab3
Table 3: Parameter values for steadytraffic2.
fig5
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 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 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 is independent, 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 because the events are independent. The equation implies 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 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 . 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 to with time limit , for every input instance satisfying the steady traffic assumption.

Proof
We show that the final value of is the probability that there exists a communication path from to with at most carries.

Prove it by induction on . For its basis , we regard true that there exists a communication path from to with zero carries by probability 1. Step sets correctly.

To prove induction step, fix each space time selected by Step -1. Denote by the event that there exists a communication path from to with at most carries. The claim to be proven is rephrased as It is straightforward to prove it for . Assume that .

Recall that expresses the event that is reachable from in hops, and the set of -neighbors of . Let be chosen by Step -1-2. Denote by the set of space times such that . The symbols satisfy the following relations: There is only one communication path from to with 1 carry, , the carry itself. Every other communication path passes a space time that is reachable from in 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 and prove true for .

Claim 1. each in (B.2) is independent of and the other .

Proof. is a product of carries that are not equal to . The steady traffic assumption (i) implies the claim.

Claim 2. the sets for all the space times are pairwise disjoint.

Proof. Suppose that there are two , say and , such that is nonempty. The probability is the product of for each and all , by (B.3) with induction hypothesis. Since is not empty, it means 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 in (B.2) are independent. By (A.3), where

Claim 3. let be the union of such that . 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 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 . By the lemma, (B.6) holds throughout the process. Let be the set of chosen so far by Step -1-2. We prove by induction on its size that currently holds the value of (B.6) for

For its basis, the set is regarded as empty before Step -1-2 so that in is 1 and . Step -1-1 correctly sets for it.

To prove its induction step, assume has the value of (A.1) for , where is currently chosen by 4-1-2. Due to (6), where are independent, Steps -1-2-2 and 4-1-2-3 compute and as and , respectively.

Regard as in (4), and and as the other events in . Step -1-2-4 correctly computes in (B.6) for as . This proves the induction step.

We have shown that Answer at Step -2. Finally, Step computes the probability that the space time is reachable from in hops, returning correctly. This completes the proof of the theorem.

References

  1. I. Leontiadis and C. Mascolo, “GeOpps: geographical opportunistic routing for vehicular networks,” in Proceedings of IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks (WOWMOM '07), June 2007. View at Publisher · View at Google Scholar
  2. V. Naumov and T. R. Gross, “Connectivity-aware routing (CAR) in vehicular ad hoc networks,” in Proceedings of the 26th IEEE International Conference on Computer Communications (INFOCOM '07), pp. 1919–1927, 2007. View at Publisher · View at Google Scholar
  3. A. Skordylis and N. Trigoni, “Delay-bounded routing in vehicular ad-hoc networks,” in Proceedings of the 9th ACM International Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc '08), pp. 341–350, May 2008. View at Publisher · View at Google Scholar
  4. J. Zhao and G. Cao, “VADD: vehicle-assisted data delivery in vehicular ad hoc networks,” IEEE Transactions on Vehicular Technology, vol. 57, no. 3, pp. 1910–1922, 2008. View at Publisher · View at Google Scholar · View at Scopus
  5. J. Fukuyama, “A probabilistic protocol for multi-hop routing in VANETs,” in Proceedings of IEEE International Conference on Communications Workshops (ICC '09), 2009. View at Publisher · View at Google Scholar
  6. D. Kumar, A. A. Kherani, and E. Altman, “Route lifetime based optimal hop selection in VANETs on highway: an analytical viewpoint,” in Proceedings of the 5th International IFIP-TC6 Networking Conference, vol. 3976 of Lecture Notes in Computer Science, pp. 799–814, May 2006. View at Publisher · View at Google Scholar
  7. B. Karp and H. T. Kung, “GPSR: Greedy Perimeter Stateless Routing for wireless networks,” in Proceedings of the 6th Annual International Conference on Mobile Computing and Networking (MOBICOM '00), pp. 243–254, August 2000.
  8. R. Baldessari, A. Festag, A. Matos, J. Santos, and R. Aguiar, “Flexible connectivity management in vehicular communication networks,” in Proceedings of 3rd International Workshop on Intelligent Transportation (WIT '06), pp. 211–216, 2006.
  9. H. Wu, R. Fujimoto, R. Guensler, and M. Hunter, “MDDV: a mobility-centric data dissemination algorithm for vehicular networks,” in Proceedings of the 1st ACM International Workshop on Vehicular Ad Hoc Networks (VANET '04), pp. 47–56, October 2004.
  10. M. Killat, F. Schmidt-Eisenlohr, H. Hartenstein, C. Rössel, P. Vortisch, S. Assenmacher, and F. Busch, “Enabling efficient and accurate large-scale simulations of VANETs for vehicular traffic management,” in Proceedings of the 4th ACM International Workshop on Vehicular Ad Hoc Networks (VANET '07), pp. 29–38, September 2007. View at Publisher · View at Google Scholar