10.4 Overview of OppCast

OppCast consists of two types of broadcast phases: fast-forward-dissemination (FFD) and makeup-for-reliability (MFR). Intuitively, the FFD phase uses relatively long hops to advance the WM towards the end of IR for the purpose of fast propagation. The FFD phase is realized via relaying the WM by a series of forwarder nodes that lie successively along the message dissemination direction, where each next-hop forwarder node's distance to the previous one is relatively large. These forwarder nodes thus divide the IR into several one-hop zones. Due to lossy links and the independent reception assumption, however, vehicles within these one-hop zones may not all receive the packet upon one relay node's transmission. Thus we use additional make up transmissions that constitute MFR phases to ensure the PRR of the network. In particular, in the MFR phase of each one-hop zone, a minimal set of makeup nodes are successively selected until the expected packet reception probability of each node within that one-hop zone is larger than a pre defined Pth. In order to satisfy the PRR requirement of the whole network, the reliability of each hop's forwarder node selection is ensured by a retransmission mechanism. By deriving the optimal parameter that controls the length of the one-hop zones, the PRR requirement is satisfied with the least transmission overhead. Note that, we refer to both forwarder and makeup nodes as relay nodes.

The concept of opportunistic forwarding is exploited by OppCast in every transmission to enhance the WM reception reliability and minimize the broadcast latency. Each relay node's (re)broadcast triggers the selection of next forwarder or/and makeup nodes, where the selection of each type of relay is associated with a different relay candidate region (RCR). In the RCR, each node is a potential candidate of the next relay node; due to the broadcast nature of the wireless medium, this greatly enhances the probability that at least one relay candidate receives and rebroadcasts the WM, especially when the network is dense. In the FFD phase, each node (forwarder candidate) that received a (re)broadcast from a previous forwarder contends to become a forwarder in a distributed manner. To maximize the hop progress, each forwarder candidate computes a backoff delay that is inversely proportional to the distance from it to the previous forwarder. The one with the largest hop progress will rebroadcast first and become the forwarder. In order for the forwarder to reliably and efficiently suppress other forwarder candidates, we propose the use of an explicit broadcast acknowledgement (BACK) message before each (re)broadcast. The BACK is a short message with longer range than ordinary event-driven WMs, because it is sent at the base rate while WMs are sent at a higher rate. In this way, the previous (re)broadcast is acknowledged, and redundant rebroadcasts are avoided. For each MFR phase, the above contending mechanism is also used to select the makeup nodes, where the selection priority is set as how much additional reception reliability each makeup candidate can bring to its neighbors.

The BACK is a key component in OppCast, and in order to realize the above concepts, we design an opportunistic broadcast coordination function (OBCF) as the underlying MAC protocol used in each broadcast transmission. Specifically, we use the BACK as a way to clear the channel for the subsequent rebroadcast (similar to the function of clear-to-send (CTS) in IEEE 802.11 unicast), which can suppress most of the hidden terminals. Furthermore, we enhance the backoff delay function in previous works, to reduce the hop delay and the possibility of packet collisions. As a result, it is ensured with high probability that in each RCR of each transmission, only one relay is selected.

Due to the use of BACKs, we are able to carry out optimizations on relay selection. To minimize the total number of incurred transmissions for each event-driven WM, we carefully consider the tradeoff between WM dissemination rate and the transmission count. Central to this tradeoff is the length of the RCR for selecting forwarders, namely forwarding range (FR). We found the optimal FR, given the vehicle traffic density and the PRR requirement.

In addition, we extend OppCast to handle the partitioned, sparse VANETs. The vehicles in the opposite road of the source are employed as data mules only if a forwarder indicates that its local traffic density is smaller than a certain threshold. The protocol therefore adaptively switches between the normal (fast propagation) mode and store-carry-and-forward mode according to the local traffic densities.

Next we use a simple example to illustrate the broadcast process of OppCast in a well-connected VANET (the normal mode). Figure 10.2 shows a bidirectional highway with the WM source in the upper lane. After the first broadcast by the source, the vehicles with number 1 receive the WM. Those vehicles inside the forwarding range of the source start the forwarder contention process, and node A, which is furthest from the source, becomes the forwarder and sends a BACK before it actually rebroadcasts. After A's second rebroadcast, node B contends and becomes the makeup for the first one-hop zone between source and A (as B derives that the minimum packet reception probability for nodes in that zone is smaller than Pth), and node C is selected as the next hop forwarder. Node B's third rebroadcast actually covers the rest of nodes in the first one-hop zone that had not received the WM, while node C's fourth rebroadcast forms the second one-hop zone between A and C. Now all the nodes in the first and second one-hop zones compute the packet reception probability for others, and found that to be larger than Pth. No makeup nodes are therefore further selected. In the mean time, the WM is being propagated further in the dissemination direction. A high-level protocol flow chart of OppCast is given in Figure 10.2.

Figure 10.2 The high-level flow chart of OppCast (at node v when receiving a WM from node u). Reproduced by permission of © 2009 IEEE.

10.2

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset