Routing in urban VANETs

Routing in urban VANETs is quite challenging due to high mobility of vehicles (nodes) and dense large obstacles, such as buildings. Due to high mobility, communication links may be broken easily. And dense obstacles limit the radio coverage of a node within a road section, which degrades node connectivity. As a result, the routes among nodes in VANETs are quite instable. However, node movements are restricted by the road geometry so that node movements can be predicted. Besides, vehicle engines can provide unlimited energy for computation. Nodes may fully utilize the information they learn from each other to obtain optimal routing decisions. Therefore, routing protocols for VANETs can be well designed to adapt to the characteristics of VANETs, especially in urban areas.

In urban VANETs, traditional routing protocols are node-based [54][55], while most of recent routing protocols are road-based [45][46][47][48]. In node-based routing protocols, a path is composed of selected nodes, and packets are relayed along the determined sequence of the nodes. However, due to high mobility in VANETs, nodes move apart from each other easily. The link of two consecutive relay nodes may easily get broken so that route failures occur frequently in node-based routing protocols. Frequent route failures result in a high packet loss rate and extra control overhead for route re-discovery. Therefore, road-based routing protocols were proposed to improve route stability. In road-based routing protocols, a path consists of a succession of road sections (RSs) from source to destination, and data packets are transferred along the RSs. Within each RS, geographical forwarding is used.

Geographical forwarding is that upon receiving a packet then a relay node decides its next hop depending on current neighbor nodes’ positions. The neighbor node currently nearest to the next RS would be chosen as the next hop. In this way, the choice of a next hop is flexible. As long as nodes are dense enough in each RS of a path, a data packet can successfully be transferred hop by hop until reaching the destination. In urban VANETs, node density in an

RS does not vary too much, in a short period of time. Therefore, road-based routing is steadier than node-based routing.

To further enhance route stability, multipath routing provides alternative routes immediately once the current route fails [42][43][49], or provides concurrent transmission with multiple paths [44]. However, existing multipath routing approaches [42][43][44][49] are node-based. They still inherit the drawback of frequent routing failure in node-based routing protocols.

On the other hand, to find the routes with better quality (e.g., higher probability of connectivity, longer path lifetime, lower packet delay, etc.), some QoS routing approaches for urban VANETs were proposed [45][51][52][53]. However, most of current QoS routing protocols for VANETs are node-based, and they only consider scenarios of straight roads (e.g., highways) or city roads with limited scope of one or two intersections. For a general city geometry, road-based routing is more suitable. Recently, IGRP [45] was proposed to utilize node density and average speed in each RS so as to calculate the probability of connectivity and hop count, etc., from source to destination. However, it needs an additional traffic statistics service to obtain the required node density and average speed information.

In this dissertation, we propose a road-based QoS-aware multipath routing protocol for urban VANETs. Since road-based routing has been shown suitable in urban VANETs [45][46][47][48], we extend it to find multiple road-based paths. In addition, with multiple paths available, we propose a QoS path switching scheme to efficiently utilize a better path to achieve better QoS. Due to node mobility, for each RS in a path, the RS becomes connected or disconnected as time elapses. Therefore, we propose a space-time planar approach to predict each RS’s future connectivity in a path, and then proceed to derive a path’s future life periods. With each path’s future life periods, the source node may dynamically switch to use the path which is currently connected and has shorter delay so as to enhance data transmission

QoS. To the best of our knowledge, there is no literature on road-based multipath routing protocol for VANETs.

Chapter 2

Related work

Existing multimedia streaming approaches and routing protocols for urban VANETs are reviewed in this chapter. We also provide their classifications and comparison tables to compare different approaches.

2.1 Multimedia streaming approaches for VANETs

Existing literatures on multimedia streaming approaches for VANETs are classified in Figure 3. We review these literatures in the following, and discuss their feasibility of multimedia streaming to a group of nodes in urban VANETs.

Figure 3. Classification of existing multimedia streaming approaches for VANETs.

2.1.1. Network coding based streaming

NCDD (Network Coding based Data Dissemination) [3] utilize random network coding techniques for data dissemination in VANETs. Each group node broadcasts its resource information to its 1-hop neighbors periodically. In addition, group nodes exchange coded pieces instead of original pieces. If a coded piece is linearly independent of the coded pieces in a node's local memory, then the node stores it. A node has to collect enough pieces then for decoding [2]. Note that network coding based approaches require group nodes periodically broadcast its collected pieces’ information and retrieves uncollected pieces. Broadcast packets are not always received by neighbor nodes, and the concurrent transmitting nodes may suffer from severe collision [4]. Furthermore, network coding based approaches may consume a lot of time to collect enough pieces to decode if group nodes are not dense enough [4]. Especially in urban VANETs, due to obstacles, it is difficult for group nodes to hear the broadcasting of pieces information from one another. CodePlay [22] improves the collision problem of network coding based approaches (e.g., [2][3]) by adopting a local push scheme that only selected nodes are allowed to push data packets to other nodes in the same road segment.

However, this technique still did not resolve the problem of group nodes not dense enough.

2.1.2. Hop-by-hop forwarding based streaming

In SMUG (Streaming Media Urban Grid) [6], a media stream is generated from a certain point (e.g. a roadside access point), and the stream is fed to SMUG-capable nodes and is distributed across a VANET [6]. Each node may dynamically be selected as a forwarder, and its transmissions are scheduled according to a TDMA scheme. Each forwarder is scheduled in a certain time slot to transmit, and neighboring forwarders would be assigned different time slots according to the proposed graph coloring technique so as to minimize the chance of collisions in adjacent areas [6]. However, if SMUG-capable nodes are not dense enough, it

would result in high packet loss, due to hard to meet any forwarder around. Besides, SMUG can only be applied in TDMA-based ad hoc networks, and it requires all nodes to follow its specific TDMA channel access scheme.

V3 [8] provides a scheme to retrieve the scene of a certain area to an interested vehicle.

The application scenario of V3 is that for a certain region on the road, the scene can be captured by one or more video sources, such as pre-deployed stations or vehicles passing by.

The interested vehicles, called receivers, continuously trigger the video sources to send the videos back. However, this scheme is not suitable for group communications, because each receiver establishes a path to a source, which is inefficient. Besides, the packet forwarding protocol in V3 only considers vehicles in a straight road, such as a highway. Therefore, V3 is not feasible to urban scenarios where a road map has many road intersections.

2.1.3. Cluster based streaming

Both VAPER (Vehicles Adaptive Peer-to-peer Relay Method) [5] and ZIPPER (Zero-Infrastructure P2P System) [4] form clusters among vehicles, and multimedia stream are relayed between clusters. Every vehicle periodically sends a beacon to neighbors to form clusters. There are a cluster head and also a cluster tail in a cluster. Each vehicle in the same cluster is one hop neighbor to each other. The main difference between VAPER and ZIPEER is that VAPER pushes a multimedia stream, while ZIPPER pulls a multimedia stream. In VAPER, the cluster head broadcasts a multimedia stream to its cluster members, and then the cluster tail relays the multimedia stream to the cluster head of the subsequent cluster. ZIPPER assumes a multimedia stream is composed of blocks, and a vehicle can retrieve blocks from other vehicles if available. If a required block is found, the block would be sent back.

However, both clustering schemes require all vehicles to form clusters and maintain the clusters all the time, regardless of whether cluster members want to receive multimedia

stream. And both clustering schemes consider only straight roads, such as highways. They did not consider urban scenarios where the map has many road intersections. That is, the clustering schemes can not be directly applied to urban VANETs.

2.1.4. Overlay based streaming

In overlay based streaming, the source node multicasts a multimedia stream to group nodes in an overlay. Various kinds of overlay multicast approaches over MANETs have been proposed [16][17][18][19][25], while in VANETs, only Qadri et al. [1][11][24] discuss video streaming using a static overlay, as far as we know. Due to high-speed, obstacle-prone and broken-link-prone characteristics, urban VANETs is very different from MANETs. For dynamic overlay approaches proposed for MANETs, most of them [16][18][25] aim to maintain low cost topology in terms of number of overlay links or physical links, but they cannot adjust the overlay in time for urban VANETs with high mobility. That is, they may cope with MANETs with low mobility; however, they are not feasible to urban VANETs with high mobility. Instead of maintaining low cost topology, OMHF [19] and ALMA [17] adjust an overlay quickly based on current overlay links’ quality. OMHF [19] uses the number of a node’s link failures to indicate its quality. If a parent’s link quality is lower than its child’s, their parent-child roles are exchanged. However, OMHF is not suitable for obstacle-prone urban VANETs. In obstacle-prone VANETs, the new parent may not be able to connect to the ancestor, and some children may not be able to connect to the new parent. ALMA [17] uses the overlay link delay as the estimated quality of an overlay link. If the link delay of a child to its parent exceeds a threshold, the child switches to another parent with shorter link delay.

However, if applying ALMA to urban VANETs, due to high packet loss and frequent disconnections, a child may switch to a parent with higher packet loss, although the link delay is low. Therefore, the existing approaches proposed for MANETs are not feasible to

multimedia streaming in urban VANETs. Feasible multimedia streaming in VANETs needs to consider the connectivity of children and parents as well as the stream’s packet loss rate and the end-to-end delay.

As to the related work in VANET, only Qadri et al. [1][11][24] discussed video streaming using an overlay, as far as we know. They evaluated the feasibility of video streaming using a static overlay in VANETs, and showed the improvement of applying video coding and error resilience. However, the overlay structure was static, even though nodes are mobile, which may suffer from inefficient overlay structures and frequent disconnections. In our work, we focus on dynamic overlay adaptation. In Table 1 the aforementioned approaches are compared, considering the feasibility of multimedia streaming for a group of nodes in urban VANETs.

Table 1. Comparison of existing multimedia streaming approaches for VANETs.

Hop-by-hop forwarding

2.2 Routing protocols in urban VANETs

Existing routing protocols for urban VANETs are classified as Figure 4. The routing approaches of each category are reviewed in the following subsections.

Routing protocols for Figure 4. Classification of routing protocols for urban VANETs.

2.2.1. Road-based vs. node-based routing

In literatures of routing protocols for urban VANETs, vehicles are assumed to be equipped with GPS (global positioning systems) and street-level city maps [45][46][47][48].

With GPS, each node knows its own and its neighbors’ positions, and may utilize the position information to forward data packets toward destination [54][55]. These kind of routing protocols are node based. However, due to dense obstacles in city maps, sometimes a routing path may fail to be found. Therefore, road-based routing protocols are proposed. GyTar (improved Greedy Traffic Aware Routing protocol) [46] is an intersection-based geographical

road-based routing protocol. A relay node computes the score of each neighboring road intersection, and decides the next road intersection to forward packet to. The score is decided by the node density and road distance to the destination. However, GyTar is a greedy algorithm so that the current chosen road intersection may later lead to road sections with poor node density and connectivity.

LOUVRE (Landmark Overlays for Urban Vehicular Routing Environments) [47] builds an overlay on top of an urban topology [47]. The overlay consists of connected roads in the topology. To form an overlay, LOUVRE uses a P2P protocol for discovering and distributing traffic density information of each road among all nodes in a network environment. Each node exchanges traffic density information with its neighbors via broadcasting. Then, a path between a source and a destination on the overlay can be found by using Dijkstra’s algorithm.

However, the scalability of the overlay is limited due to P2P exchange delays in the network environment.

The RBVT (Road-Based using Vehicular Traffic) routing protocol [48] creates a road-based path consisting of a succession of road intersections [48]. The authors proposed a reactive protocol, RBVT-R and a proactive protocol, RBVT-P. The route discovery scheme in RBVT-R is similar to the traditional source routing protocol, but the routing information piggybacked in a packet is a succession of road intersections instead of nodes. RBVT-P is similar to LOUVRE. Nodes periodically discover and disseminate the road-based network topology to maintain a global view of the network connectivity. The performance of RBVT-R depends on the stability of every RS’s connectivity, and the performance of RBVT-P depends on the delay of network connectivity information exchange.

2.2.2. Multipath routing

There is no existing road-based multipath routing protocol for VANETs, as far as we know. In the following, we review existing node-based multipath routing protocols for urban VANETs. AOMDV [42], extended from AODV [59], is a representative multipath routing protocol for MANETs. If it is applied to VANETs, due to high mobility, link lifetimes to next hops expire soon, thus an alternative route may still fail at a certain relay node. FROMR (Fast Restoration On-demand Multipath Routing) [43], which is a node-based routing protocol, extends AODV to discover multiple paths so as to rapidly build an alternate path if the current route fails. Unlike AODV where duplicate copies of RREQ messages are simply discarded, FROMR uses some of these copies to form multiple reverse paths. In addition, to reduce control overhead, FROMR partitions a geographic region into grids and assigns each grid a grid leader. Only leaders are responsible for control messages broadcasting and data forwarding. Although FROMR provides more choices of next hops, in essence the link lifetimes of these next hops still expire soon, due to high mobility in VANETs. DDR (Differentiated Reliable Routing) [49] is also a multipath routing protocol in hybrid VANETs, which have road side units (RSUs). In hybrid VANETs, a multi-hop path may include RSUs as intermediate nodes for packet relaying.

2.2.3. QoS routing

Most of existing QoS routing protocols in VANETs are node-based. QoSBeeVanet [51]

imitates honey bees’ behavior to find a route with better QoS in VANETs. VOA [52] assumes a highway scenario. It selects an optimal routing path and backup routing paths in order to gracefully switch to a backup routing path before the current routing path is broken. MURU [53] uses an expected disconnection degree (EDD) to estimate a probability that a route will fail during a given time period. MURU utilizes EDD to obtain an optimal path. But MURU

only utilizes local map information and it may lead to the local optimum problem.

IGRP (Intersection-based Geographical Routing Protocol) [45] is a road-based single path QoS routing protocol. In IGRP, a path is composed of a succession of road sections (RSs).

Therefore, a path’s QoS may be estimated with the QoS of RSs. IGRP first retrieves the node density and average node speed of each RS using an existing location service. Then, these data are utilized to probabilistically estimate QoS related metrics, such as probability of connectivity, end-to-end delay, hop count, and bit error rate (BER). Therefore, for paths between source and destination, only the path that satisfies the constraints of these metrics is selected.

Finally, in Table 2, we summarize the aforementioned road-based routing protocols, including their basic classifications, main idea and limitations.

Table 2. Comparison of representative road-based routing protocols for urban VANETs.

Approach Single path or multipath

QoS-

aware Main idea Limitations

GyTar [46] Single path No

Compute the score of each neighboring road intersection with node density and distance to destination

As a greedy algorithm, the current chosen road intersection may later lead to RSs with poor node density and connectivity

LOUVRE

[47] Single path No

Routing path is decided according to the overlay which is built on top of urban topology, consisting of connected roads in the network

Scalability of the overlay is limited due to the road density information exchange delay in the whole network

RBVT [48] Single path No

RBVT can find a

source-destination path consisting of RSs. Then every packet is relayed along the routing path, according to the RS list

piggybacked in the packet’s header

RBVT-R’s performance depends on the stability of each road section’s intra-connectivity; rate to derive a path’s QoS

An additional traffic statistics their future life periods for QoS path switching, with very little overhead

If nodes are dense, the advantage of providing multiple paths is limited

Chapter 3

Proposed dynamic overlay multicast for live multimedia streaming in urban VANETs

3.1 Overview of the proposed overlay multicast in VANETs (OMV)

This chapter considers the scenario of live multimedia streaming multicast to vehicles of the same group, and these group-member vehicles are organized as an overlay tree, as shown in Figure 5(a) and Figure 5(b). Group-member vehicles (called group nodes or overlay nodes, interchangeably) join the multicast tree initiated by a vehicle which is a streaming provider;

this vehicle acts as the multicast source node. Multimedia packets generated by the multicast source node are delivered along the overlay tree. The link between a parent and its child may be actually a multiple-hop path through intermediate non-member nodes, which is referred as an overlay link. In an overlay link, packets are passed using the underlying network-layer routing protocol. The source node also plays the role of the bootstrap node (BSN) of the multicast tree. When a node wants to join the multicast tree, it firstly asks the BSN for which node to be its parent, so as to become a member of the tree.

As vehicles move rapidly, an overlay tree need to change its structure to maintain QoS.

For example, as shown in Figure 5(a), node 4 moves fast toward the right hand side, and it is

going far way from its parent node 3 and child node 5. Such a situation will result in high packet loss and long packet delay in the overlay. Therefore, we propose to dynamically adjust the overlay to maintain its QoS. In addition, to further enhance the robustness of an overlay, we build a two-parent overlay, as shown in Figure 5(c). We propose this dynamic overlay (i.e.

QoS-satisfied dynamic overlay and two-parent overlay) to suit for live multicast streaming scenarios, so that passengers in group-member vehicles can enjoy live reliable video streaming from the source vehicle.

(b)

(a)

(c)

Figure 5. An illustration of a multicast overlay in urban VANETs: (a) an overlay formed by interested vehicles, in urban roads; (b) the corresponding overlay tree; (c) expanding the

Figure 5. An illustration of a multicast overlay in urban VANETs: (a) an overlay formed by interested vehicles, in urban roads; (b) the corresponding overlay tree; (c) expanding the