A Probabilistic Protocol for Multihop Routing in VANETs

Vehicular ad hoc networks (VANETs) allow communications over sequences of vehicles with radio devices. There are many possible applications over a VANET such as tra ﬃ c 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 di ﬃ cult 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 speciﬁed 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 reﬁned for some practical issues.


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-tovehicle (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.
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 sourcedestination routing in VANETs is the so-called geographical forwarding.It chooses car(s) closest to the destination d 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 d 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 Geographically, car A is the closest to the RSU; however not a good choice Car B is the next closest, but the traffic ahead is too sparse The best choice 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.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.
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.

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 s to destination d.We call it the communication probability from s to d. Suppose for simplicity that two cars can communicate whenever they are within a given transmission range R of the radio.We will modify it later so the algorithm may better suit real situations.With this simplification, the communication from s to d 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.

Basic Notation.
We assume that every considered object is on the map M that is a Euclidean graph whose nodes are geographical locations or positions, and edges are roads.Denote by x a position on M, for which we write x ∈ M instead of x ∈ V (M).Let m be the number of positions on M. Notice that x is a two-dimensional vector.
Let R 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 Consider that time t = 0, 1, 2, . . ., T where T is the time limit.To express that a car is at position x ∈ M when time is t, it is convenient to couple t with x.A space time u = (x, t) is meant to be such pairing.
A carry is a pair h = (u 1 , u 2 ) of space times.It means that a car appears at u 1 = (x 1 , t 1 ) and moves to u 2 = (x 2 , t 2 ).We can understand carries as the solid arrows in Figure 2, while the dotted ones represent hops.We say x 1 and x 2 are the source and destination of the carry, and t 1 and t 2 are start and arrival time, respectively.
Formally, a communication path is a k-tuple E = (h 1 , h 2 , . . ., h k ) of carries h i such that the start time of h i+1 equals the arrival time of h i , and the source of h i+1 is an Rneighbor of the destination of h i for every i < k.We require the integer k to be at most a given maximum number H of hops.We can also say that E is a communication path from u to u , where u is the first space time of h 1 and u the second one of h k .The arrival time and destination of E are defined as those of u , respectively.Let a source s and destination d be given.A space time u = (x, t) is said to be reachable from (s, 0) in k hops if there exists a communication path from (s, 0) with no more than k carries whose destination is an R-neighbor of x and arrival time is at most t.The communication probability ρ(s, d, T) from s to d with time limit T is the probability that (d, T) is reachable from (s, 0) in H hops.
Figure 2 shows a communication path from (s, 0) to (d , t) with 4 carries and 3 hops.The space time (d, t) is reachable from (s, 0) in 4 hops.
Our goal in this mathematical framework is to compute ρ(s, d, T) efficiently.Once we have the communication probabilities, the averages of other various random variables could be computed quickly.For example, the expected delay time τ(s, d) to send a packet from s to d is (1)

Assumptions to Reduce the Hardness of Computation.
Denote by (A, u) the probabilistic event that car A appears at space time u and by P(A, u) its probability.In the rest of the paper, P(•) expresses the probability of the argument event, where we omit obvious parentheses, that is , write P(A, u) instead of P((A, u)) and so forth.Let Ω be the set of all (A, u).Logical sum, product, and implication are denoted by , , and an arrow, respectively.Consider the discrete probability space (Ω, F , P) as in Appendix A, where F is the set of events over Ω.We will have all formal discussions in this framework.
The probabilities P(A, u) are not sufficient information to compute the exact values of ρ(s, d, T), because the events (A, u) possibly depend on each other even for a single car A. For example, P((A, u 1 ) (A, u 2 )) may not be P(A, u 1 )P(A, u 2 ) due to the dependence; if paths from the source s to u i overlap, P(A, u i ) affect each other.
We formulate the problem of computing communication probabilities as follows; given a map M, initial positions of cars, time limit T, and transmission range R, assume that subsequent movements of two cars are independent of each other.That of every car A is restricted so that P((A, u 2 )|(A, u 1 )) is a given fixed value, where u 1 = (x 1 , t) and u 2 = (x 2 , t + 1) are space times, and P(•|•) denotes conditional probability as defined in Appendix A. It means that the probability of A moving from x 1 to x 2 is given when time transits from t to t + 1. Compute the communication probability from s ∈ M to d ∈ M for all the pairs of s and d 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 A is bounded by a polynomial in the problem size.(We define the size as the number of cars added by m+T +H.)The difficulty is attributed to the dependence between communication paths that are events in F .
We introduce the following assumption to reduce the hardness of computation.Denote by [u, k] the event in F that the space time u is reachable from (s, 0) in k hops.
Steady traffic assumption: the following two are true in (Ω, F , P).
If it is true, the probability P([u, k]) takes a value that only depends on u for each fixed k, letting the reachability to u 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 (A, u) satisfy the following.
Exact schedule assumption: P(A, u) is either 1 or 0 for every car A and space time u.
It means that it is either true or false if A appears at u.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 P(A, u) is either 0 or 1 for every (A, u).The probability of (A, u) given any condition is either 0 or 1.The probability that a communication path occurs is 0/1.Thus, P ([u, k]) is also 0/1 for any k ≤ H.The event [u, k] is independent of the others as the last paragraph in Appendix A says.Since carries (u, k) 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 P(A, u) = 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 [u, k] and carries are well independent in practice if considered u = (x, t) are distinct enough.Events [u, k] with similar x and t 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 x and t, respectively, to avoid considering similar u too often.With the coarse resolutions, the probabilistic protocol will successfully capture the tendency of the vehicle mobility to contribute to good communication performances.

The Basic Algorithm.
We show below our basic algorithm to compute communication probabilities.Its primary input is the carry probability P(u 1 , u 2 ) that there exists a car that appears at the space time u 1 and moves to u 2 for every carry (u 1 , u 2 ).
Notice that in the probability space (Ω, F , P), since the carry (u 1 , u 2 ) is the event in F that some A appears at u 1 and moves to u 2 .Recall the problem of computing communication probabilities formulated in Section 2.2.Since the conditional probability of (x 2 , t +1) given that (x 1 , t) is input for all x i and t, it means that the probability of the event (A, u 1 ) (A, u 2 ) is determined uniquely.Movements of distinct cars are independent.The probability of the carry (u 1 , u 2 ) 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.
Its correctness proof is found in Appendix B. We will present a general method to obtain P(u 1 , u 2 ) from field data in Section 2.4 and a more practical version in Section 2.5.
The asymptotic running time of SteadyTraffic is found O(Hm 2 T 2 R 2 ) 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 s and d.
If the exact schedule assumption holds, P(u 1 , u 2 ) is 1 if and only if there exists a car A such that P(A, u 1 ) P(A, u 2 ) = 1.We can input them into SteadyTraffic to compute ρ(s, d, T).

To Measure Carry
Probabilities from Field Data.The primary input to Algorithm SteadyTraffic is the probabilities of P(u 1 , u 2 ) of the carries.Theoretically, all we need is P((A, u 1 ) (A, u 2 )) for every car A and space times u i that is, the probability that the given car A appears at u 1 and moves to u 2 .Then, the carry probability is computed as 3) by ( 1) and (3).
There are ways to compute P((A, u 1 ) (A, u 2 )) from field data.The following two steps provides a general one.
Measure the intersection probabilities.Some nodes v on the map M represent intersections.The edges l from v are the roads from v. The intersection probability Q(l, l , v) is the probability that a car moves from the road l to l at the intersection v.We first measure this quantity from real field data, by simply finding the ratio of the cars to choose the road l out of all the cars running toward v on l.
Calculate P((A, u 1 ) (A, u 2 )).We repeat the process below for a number of times to average the obtained values of P((A, u 1 ) (A, u 2 )).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 (u 1 , u 2 ) and car A.
(2) At time t = 0, 1, 2, . . ., t 1 , simulate the probabilistic movements of the car using the intersection probabilities so that we know the probability of A being at (x, t) for all x ∈ M and t ≤ t 1 .In the end, we know the probability of A at u 1 = (x 1 , t 1 ).Store it into p 1 .
(3) Fix the position of A at t = t 1 as x 1 .Simulate the probabilistic movements of A at time t = t 1 + 1, t 1 + 2, . . ., t 2 .Find the probability of A at (x 2 , t 2 ), and store it into p 2 .
(4) Now, P((A, u 1 ) (A, u 2 )) = p 1 • p 2 is the probability that A appears at u 1 and moves to u 2 .

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 Steady-Traffic that is meant to be used for practice.It is illustrated in Algorithm 2 as SteadyTraffic 2.
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 [u, k] and carries to be well independent of others.If we consider [u, k] with similar space times u = (x, t) 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.

Algorithm SteadyTraffic Inputs:
T: time limit, H: maximum number of hops, M: map with m positions, R: transmission range, P(u 1 , u 2 ): carry probability for every (u 1 , u 2 ), that is, probability that a car appears at space time u 1 and moves to u 2 , s, d ∈ M: source and destination on the map M.
We multiply, to handle the problem, carry probabilities P(u 1 , u 2 ) by (e(x 1 )e(x 2 )) β , where u i = (x 1 , t i ) are space times, e(x) are the expected car densities at x ∈ M, and β ∈ (0, 1) is a numeric parameter to adjust.Step 3-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 x and t to avoid introducing similar u = (x, t).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 (u 1 , u) in the proximity of u 2 such that i)-v) and updates Answer(x, t, k ) at u 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 xor y-component running in the opposite direction to given dir.We call it north, south, west, and east mode when dir = (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 ξ(x 1 , x 2 ) varies over positions x i ∈ M 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].

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
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, x) and time 0, where x 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) r 1 : the probability for a car to turn from an arterial road to another, or from a path to another.
(2) r 2 : the probability for a car to turn from an arterial road to a path.
(3) r 3 : the probability for a car to turn from a path to an arterial road.
(4) r 4 : the probability that a car enters the testbed in each half second, at the start/end position of an arterial road.
(5) r 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.
In this setting, we assume transmission range R = 150 m with one hop packet error ratio ξ(x 1 , x 2 ) = 0.15 for every distinct pair of x i ∈ M.
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.11m/sec.With heartbeat messages broadcasted every second, where R = 150 m, we can assume that each car A knows by its background job the existence of every other car A in the proximity.Once A receives a packet, it quickly computes the necessary values for A 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 H 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.

Decision for the Next Packet
Holder.Now, we have a good set of communication probabilities ρ(x, x , T) from x ∈ M to x ∈ M such that if x or x is on a path, they are usually distinguishably smaller than values with both x and x on arterial roads.However, it is still not obvious how to make a good decision for the next packet holder with ρ(x, x , T).We also pre-computed the effective average numbers of hops with Answer(x, t, k) obtained when we run STEADY TRAFFIC.They turned out to be excellent index values for deciding a good packet forwarder.
Let Δ H (x) be the horizontal distance from x ∈ M to d, and Δ V (x) the vertical distance from x to d.Furthermore, define It measures the distance to the destination from x that is designed suitable for the probabilistic protocol.
In run time, decide the next packet holder as follows: if Δ(x) is much smaller than Δ(s), 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 d among the ones with relatively high values of ρ(x, d, T) and low k(x).If Δ(x) > 1/4Δ(s), we choose a car farthest from s with relatively high ρ(x, d, T) and low k(x), 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 x in the proximity.Here, α ρ and α k are input constants, max ρ is the maximum value of ρ(x, d, T) and min k the minimum value of k(x) in the proximity, respectively.Setting α ρ = 0.4 and α k = 1.05 in the approach mode, pass the packet to the car closest to d such that S is true.In the detour mode with α ρ = 0.8 and α k = 1.05, pass to the car farthest from s such that S.
The above decision process is quick since it does not require heavy in-vehicle computation.The running time is comparable to that of GPSR.

Measured Data.
We show the measured delivery ratio and delay time in Figure 5, plotting them over the horizontal position x of the packet holder at time t = 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.
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 x 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.

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 ∨ ((e∈S) e) for an event set S ⊂ F 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.

A. Review for Independent Events in a Discrete Probability Space
A probability space is a triple (Ω, F , P), where Ω is the sample space, F is the event set, and P : 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, F : the set of all events over Ω, that is, the set of Boolean expressions in terms of(A,u), and P: probability that each event F occurs.
This probability space (Ω, F , P) is discrete because Ω is finite.
A nonempty event set S ⊆ F is said to be independent if for every subset S of S. Here, we regard that both hand sides are 1 if S is empty.We also say that the elements in S are independent events.The conditional probability of e ∈ F given S is for each e 0 ∈ S.
The event set S is independent if and only if P(e|S ) = P(e) for every e ∈ S and subset S ⊆ S that does not contain e. Suppose that P(e|S ) = P(e) is true for each e and S .By the definition of conditional probability P(e ∧ e ∈S e ) = P(e | S)•P( e ∈S e ) = P(e)•P( e ∈S e ).Thus, P( e∈S e) = P(e) • P( e ∈S −{e} e ) .Argue recursively for S − {e} to have P( e∈S e) = e∈S P(e).Since it is true for any subset S ⊆ S, S is independent only if part is shown similarly.
We say e is independent of S if P(e | S ) = P(e) for each S ⊆ S. By the above claim, a nonempty event set S ⊆ F is independent if and only if each e ∈ S is independent of S − {e}.
An event e ∈ F such that P(e) is 1 or 0 is independent of F − {e}.It is intuitively clear that if the probability of e is 1/0, e either occurs or does not occur under any condition S ⊂ F − {e}, so P(e | S) = 1/0.We can formally prove it by considering the disjunctive normal form of e ∧ e ∈S (e ∨ ¬e ), that is, the logical sum of e ∧ f 1 ∧ f 2 ∧ • • • ∧ f k , where f i are either e i or ¬e i for all e i ∈ S.

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 (x, t, k) is the probability that there exists a communication path from u 0 = (s, 0) to u = (x, t) with at most k carries.
Prove it by induction on k.For its basis k = 0, we regard true that there exists a communication path from u 0 to u 0 with zero carries by probability 1. Step 3 sets Answer (s, 0, 0) correctly.
To prove induction step, fix each space time u = (x, t) selected by Step 4-1.Denote by (u, k) the event that there exists a communication path from u 0 to u with at most k carries.The claim to be proven is rephrased as Answer (x, t, k) = P(u, k) at step 4-2. (B.1) It is straightforward to prove it for k = 1.Assume that k ≥ 2.
Recall that [u, k] expresses the event that u = (x, t) is reachable from u 0 in k hops, and D(x) the set of R-neighbors of x.Let u 1 = (x 1 , t 1 ) be chosen by Step 4-1-2.Denote by D(u) the set of space times (x , t) such that x ∈ D(x).The symbols satisfy the following relations:

(B.3)
There is only one communication path from u 0 to u with 1 carry, that is , the carry (u 0 , u) itself.Every other communication path passes a space time u 2 = (x 2 , t 1 ) that is reachable from u 0 in k − 1 hops.The above relations are hence true.First, we prove the following general statement.

Lemma 2.
For each k ≤ H, the events (u, k) are independent.
Proof.By induction on k with basis true by the steady traffic assumption (i).Assume true for k − 1 and prove true for k.
Proof.[u 1 , k − 1] is a product of carries that are not equal to (u 1 , u).The steady traffic assumption (i) implies the claim.for all the space times u 1 are pairwise disjoint.
Proof.Suppose that there are two u 1 , say u 1 1 and u 2 1 , such that T = S(u 1 1 ) ∩ S(u 2 1 ) is nonempty.The probability P([u i 1 , k − 1]) is the product of P(u 2 , k − 1) for each i = 1, 2 and all u 2 ∈ D(u i 1 ), by (B.3) with induction hypothesis.Since T is not empty, it means The events [u 1 , k] are not independent, which contradicts the steady traffic assumption (ii).Thus, S(u 1 ) must be pairwise disjoint.
By the above two claims, the events (u 0 , u), (u 1 , u), and [u 1 , k − 1] in (B.2) are independent.By (A.Claim 3. let S (u) be the union of S(u 1 ) such that P(u 1 , u) / = 0.Then, they are pairswise disjoint for all the space times u.
We now see with (A.1) that each (u, k) is independent of the others.Consider two distinct u, say u 1 and u 2 .The carries (u 0 , u 1 ) and (u 1 , u 1 ) are distinct from (u 0 , u 2 ) and (u 1 , u 2 ), respectively.The events [u 1 , k − 1] are independent by Claim 3 and induction hypothesis.They imply that (u, k) is independent of the others.
The lemma follows the above, completing the proof.We verify below that Loop 4-1 correctly computes P(u, k) in Answer(x, t, k).By the lemma, (B.6) holds throughout the process.Let U 1 be the set of u 1 chosen so far by Step 4-1-2.We prove by induction on its size that Answer (x, t, k) currently holds the value of (B.6) for P =  For its basis, the set U 1 is regarded as empty before Step 4-1-2 so that P in is 1 and P(u, k) = P(u 0 , u).Step 4-1-1 correctly sets Answer(x, t, k) for it.

Figure 1 :
Figure 1: A counter example for geographical forwarding.

Figure 2 :
Figure 2: An example of a communication path.

Figure 5 :
Figure 5: Measured delivery ratio and delay time.
can derive it formally from the well-known inclusion-exclusion principle.Intuitively, it is true since the probability that any e occurs is 1 minus probability p that none of them occurs.But p is the product of 1−P(e) because the events e ∈ S are independent.The equation implies P (u, k) = (u 0 , u) ∨ [u 1 , k − 1] (u 1 , u), space times u1 (B.2) [u 1 , k − 1] = u2∈ D(u1) (u 2 , k − 1).

Table 1 :
Parameter values to the traffic simulator.

Table 2 :
Run-time parameter values for data measurement.