Hybrid multi-technology routing in heterogeneous vehicular networks

Abstract

Recent developments of wireless communication systems have resulted in the availability of heterogeneous access networks at any geographic area. To make use of this heterogeneous environment for vehicular users to access the Internet, in this article we propose a hybrid multi-technology routing (HMTR) protocol for multihop vehicular networks. HMTR takes into account different combinations of wireless technologies in intermediate hops and is generally formed of a combination of topology-based and position-based routing schemes for packet forwarding. For a given packet, HMTR uses the position-based routing approach over highly variable links whose lifetimes are shorter than the packet expiry time. On the other hand, it employs the topology-based routing approach over more stable links that are expected to stay valid before the expiry time of the packet. Among the candidate routes, any route which does not meet the user requirements in terms of budget or quality of service metrics such as delay and bandwidth is ruled out first. Then, among the remained candidates those with adequate levels of connectivity are assessed for their appropriateness in terms of network utilizations, which are of the network's concern and connection costs, which are of users' concern. Simulation results show that HMTR enables us to achieve the best possible performance in terms of delivery ratio and delivery delay for a given budget, whereas in pure position-based or pure topology-based routing schemes sacrificing the performance or budget may be inevitable in many scenarios.

1 Introduction

In recent years, various wireless access networks employing different wireless access technologies have been deployed to provide end-users with a wide range of services. As service providers increase the coverage of their access networks, it is more likely that there are overlaps between the coverage areas of different access networks. This situation translates into various connectivity alternatives for end-users, so-called heterogeneity. End-users moving at vehicular speeds^a can benefit from such a rich set of connectivity options to access the Internet for a wide range of Internet protocol (IP)-based applications such as email, content delivery, file download, gaming services, IP telephony, and multimedia streaming. In these applications, vehicular nodes equipped with multi-technology radios need to establish an efficient route to the most appropriate attachment point using the most appropriate set of intermediate hops. Attachment points are the interfaces to the core network, such as base stations (BS) in the case of worldwide interoperability for microwave access (WiMAX) or cellular networks, or access points (AP) in the case of wireless local area networks (WLAN), e.g., IEEE 802.11 a/b/g/p WLANs.^b Numerous routing protocols all based on a single wireless technology have been proposed for packet routing in vehicular environments. We refer to this type of protocols as single-technology protocols. In this article, in order to take advantage of the available heterogeneous environment, we study routing protocols that consider the combinations of different wireless technologies in intermediate hops, which we refer to as multi-technology routing protocols.

In a heterogeneous environment it is important to differentiate the problem of packet routing from the problem of optimal access network selection, which has already been extensively studied in the literature [1–7]. These studies consider the case where end-users are directly covered by several attachment points and decisions should be made to select the most appropriate attachment point for receiving service. However, in a more general case an end-user may not be directly covered by any attachment point or even if an attachment point is available in a single hop, other alternate attachment points could still be preferred. In this case, it is necessary to employ a reliable, robust, and efficient routing protocol that finds the most appropriate attachment point in a larger neighborhood and forwards the packets between the end-user and the attachment point.

Relatively few articles have investigated the issue of multi-technology routing in heterogeneous environments, especially for vehicular networks. In [8] the integration of cellular and WLAN access networks is proposed in which an agent in the cellular network assists the WLAN communications to improve the performance of the network. In [9] cellular and WLAN access networks are combined with the aim of quality of service (QoS) provisioning in a ubiquitous environment. Hung et al. [10] consider a heterogeneous vehicular networking topology in which every end-user can access both WiMAX and WLAN. The end-users' WiMAX radios are to be registered in one WiMAX BS. The BS predicts, in a centralized manner, the positions of all vehicles based on which it computes the most appropriate routes between any two end-users. In all these studies, it is assumed that the access networks with larger coverage areas, e.g., the cellular or WiMAX network, provide global coverage which allows for end-users to directly connect to it at any location at any time. Hence, these networks are used as back-up to provide service at any time when networks with smaller coverage areas such as WLANs are unavailable. Clearly, as the size of vehicular networks may become extremely large in practice, considering such back-up network may not be realistic. Hence, in our heterogeneous topology all access networks regardless of the size of their coverage areas are used as independent connectivity alternatives for multi-hop multi-technology packet forwarding. To the best of our knowledge, none of the previous studies have considered multi-hop multi-technology routing for vehicular networks.

In this article, we consider a vehicular networking environment in which the movements of vehicles are confined by the structure of roads. Since vehicles may move at very high speeds and in different directions, the topology of the network becomes highly dynamic making the design of routing protocols in vehicular environments very challenging. In this regard, many single-technology routing protocols have been proposed [11–18]. These routing protocols can be categorized as topology-based and position-based routing protocols. In topology-based routing a complete end-to-end route is established by an appropriate selection of intermediate vehicles before sending the data packets. The downside of single-technology topology-based routing protocols in vehicular environments is that the links are fairly unstable when packets are forwarded over short-range wireless networks such as WLANs. When the transmission range is relatively short relative to the distances vehicles travel over a round-trip time between the source and destination, it is very likely that some intermediate vehicles in the end-to-end route get out of each other's transmission range and the route fails even before any data packet is sent on the route. Some efforts have been made to take the stability of routes into account in the process of establishing them [11–13]. However, when routes are longer than just a few hops, finding stable end-to-end routes becomes very challenging if not impossible, and in sparse situations it is very likely that an end-to-end route may not even exist due to disconnections. So, position-based routing protocols are gaining popularity.

In position-based routing every relaying vehicle selects the next hop vehicle to forward the packet to on-the-fly based on the position and movement attributes of its one-hop neighbors [14, 15]. The advantage of this type of routing is that the forwarding of packets does not depend on the establishment of an end-to-end route. So, this type of routing is a better choice for highly varying topologies, such as packet forwarding over vehicular networks employing WLAN technology. The downside of this type of protocols is that the forwarding decisions are local and without considering real-time network conditions in terms of connectivity and congestion in other parts of the network. To address these shortcomings, more recent studies have proposed connectivity-aware routing schemes [16–18]. However, in these schemes the connectivity information is pre-determined, and as a result, real-time connectivity and congestion information regarding the parts of the network that are going to be visited in the future is not available. On the other hand, in these schemes the general approach for selecting the most connected route is to make intermediate vehicles report metrics such as average number of neighbors, minimum number of neighbors, and average density of neighbors. Finally, the route with the maximum value of any of these metrics is considered as the most connected route. However, these approaches may not be accurate enough, because even though all these metrics intuitively result in the most connected route, the connectivity in the context of position-based routing is defined as the probability that no disconnection exists along the route. A disconnection is the state where no next hop vehicle can be found along the route, thereby making the communication impossible. To select the route with the maximum connectivity, an approach for calculating the connectivity according to the aforementioned definition is required.

The main idea of our article is to integrate the advantages of topology-based and position-based routing into a unified scheme. Based on the fact that the route instability problem of topology-based routing can be largely overcome using long-range wireless networks such as WiMAX or cellular networks, we propose the hybrid multi-technology routing (HMTR) protocol, which takes a hybrid approach for forwarding packets. In HMTR, topology-based routing is used for forwarding packets over more stable links available in long-range networks, and position-based routing scheme is used for forwarding packets over highly variable links in short-range networks. To determine the stability of a link, we propose a link stability logic which is based on the relative mobility of the vehicles forming the link and the delay requirements of the application involved. As a part of HMTR route selection logic is suggested to prioritize candidate routes based on QoS metrics, network and user preferences and the connectivity of routes. In this regard, we propose a novel microscopic approach for calculating the connectivity of routes on the basis of the connectivity observations of individual vehicles along the routes. To facilitate service delivery in the studied vehicular heterogeneous environment, we also introduce a novel network architecture to address issues such as authentication, authorization, and accounting (AAA) in a multi-operator scenarios. To the best of our knowledge HMTR is the first multi-technology, multi-operator hybrid routing protocol for vehicular communications.

The rest of the article is organized as follows. In the following section, the network topology is introduced, which can be comprised of an arbitrary set of wireless access networks. In Section 3, the HMTR routing protocol is explained. We elaborate on the mechanisms and logics designed for HMTR including the route selection logic and the link stability logic in Section 4. The proposed route connectivity is detailed in Section 5. The performance of HMTR with respect to its different routing possibilities is evaluated in Section 6. Section 7 concludes the article.

2 Network topology

2.1 Assumptions

As in most other studies [11–18] we assume that all vehicles are equipped with global positioning system (GPS) receivers which can provide position, velocity, and time information. Also, all vehicles can obtain roadmap information via digital maps installed in them. Other than the road topology, digital maps also include the ranges of speed and average vehicle densities in every street or highway in the map. Such digital maps have already been commercialized [19]. Every vehicle can be equipped with one or more digital radios each using a different wireless access technology. We assume that multiple radios onboard a vehicle can be operated simultaneously with no interference to each other; e.g., they employ different frequency bands. Furthermore, we assume that every vehicle has an updated list of all of its one-hop neighbors. For instance, in the case of WLAN access networks this is accomplished by having all WLAN radios periodically broadcast beacon messages in their one-hop neighboring areas reporting their positions. It is further possible to estimate the velocity vector of other WLAN-enabled vehicles by analyzing their consecutive beacon signals. Every WiMAX radio is also able to obtain an updated list of all other WiMAX-enabled vehicles in its range [20–23], e.g., via the BS.

2.2 The topology

We keep the network topology general by assuming that the network topology could be comprised of various access networks. Two general approaches in terms of the architectural design for integrating various access networks are possible: loose coupling and tight coupling[7, 24]. In loose coupling different access networks are independent and are connected to each other through the Internet. However, in tight coupling the networks with smaller coverage areas attach to the network with larger coverage area in the same manner a radio access network attaches to the core network, and are dependent on the larger network in that all of their signaling functionalities and data transfers are handled by the larger network. In this article, we select the loose coupling approach for two main reasons:

• (1) Any of the attachment points, i.e., BSs or APs, may be owned by a different service provider which has its own AAA policies.

• (2) Since vehicular networks are usually very large networks composed of a number of smaller access networks, their scalability is of great concern. To make the network scalable, we are interested in a topology that requires as few changes as possible in the architecture of readily available access networks in the deployment phase. Since most of access networks have been designed to have Internet access via gateways included in their core networks, loose coupling calls for the minimum required changes in integrating the access networks.

To give an example, the proposed topology when comprised of WLAN, WiMAX, and cellular access networks is depicted in Figure 1, in which the larger ellipses, hexagons, and smaller ellipses represent the coverage areas of the WiMAX BSs, cellular BSs, and WLAN APs in access networks 1, 2, and 3, respectively. The topology we introduce here is different from most commonly used topologies in the literature from two viewpoints:

Figure 1

Network topology.

• (1) In most previous studies, the access networks with larger coverage areas and usually costlier service such as WiMAX and cellular are used as back-up connectivity alternatives which take over the packet forwarding responsibility when smaller coverage networks fail. This assumption often time requires that a tight coupling approach is used in which the network with larger coverage makes system switching decisions. On the contrary, in our topology any of the available wireless technologies is considered as an independent connectivity alternative which is in accordance with the loose coupling approach.

• (2) Ad hoc networking in a heterogeneous setting can be advantageous when vehicles are not covered by any attachment points or in the case where desirable access networks are available but are out of range. Eventhough only a few papers in the literature have studied the possibility of ad hoc networking in a heterogeneous environment [3], these articles employ ad hoc networking only as a means for forwarding data to the attachment points that are pre-selected. In our topology we consider ad hoc communications as an independent connectivity alternative which enables us to take the appropriateness of both the possible multi-hop routes and the attachment points into account as opposed to only the attachment points.

The optimum route might consist of links of subscribers of different operators. Each operator or service provider has its own AAA server which interacts with the gateways and AAA servers of other access networks to verify identity, accept or reject access and for billing purposes. As depicted in Figure 1, some of the attachment points in the local core networks of different service providers have dual functionalities of acting as access nodes as well as Internet gateways for connecting the local core network to the Internet. In our topology, both WLAN and WiMAX communications provide ad hoc packet forwarding capability, while cellular communications only provide direct connections from vehicles to cellular BSs and therefore can be only used as the last hop. The possibility of using ad hoc communications over WiMAX radios is explained in more details in Section 5.1.

3 Hybrid multi-technology routing

The mechanism of HMTR can be divided into three different phases including disseminating a request packet, route selection, and returning a reply packet.

3.1 Disseminating a request packet

Any end-user wishing to establish a connection with an attachment point generates a request packet and broadcasts it in the network using all of its available radios, e.g., simultaneous over its WLAN and WiMAX radios if it is so equipped. Any intermediate vehicle that receives the request packet rebroadcasts it on all of its available radios no matter which radio the packet was received on until an attachment point receives the request packet. Since the potential recipients of request packets could be any of the available attachment points, the use of an anycasting mechanism is inevitable. In anycasting the same IP address is shared among all attachment points in the network for addressing request packets. This IP address translates into the same ID for all the attachment points to which the request packets are destined. In this article, to mitigate packet flooding effect we employ several methods to limit the propagation of request packets in the network. One way is to restrict the propagation of request packets to a limited geographical area. Other methods are detailed in Section 4. Note that for wireless technologies which do not support ad hoc networking, e.g., cellular network, the request packets are directly forwarded by the onboard radio to the corresponding attachment point. The radio cannot be used at that point if the vehicle is not within the coverage area of any attachment point.

As mentioned in Section 1, in HMTR we use a hybrid packet forwarding approach in which topology-based routing scheme is used for forwarding packets over stable links, and position-based routing is used for forwarding packets over unstable links. A link is considered stable if it is expected to stay valid before the expiry time of the request packet which is determined by the application requesting the route. The logics employed by intermediate vehicles in HMTR to evaluate the stability of links for a received packet is explained in Section 4.2. To implement the hybrid packet forwarding approach in HMTR, the intermediate radios that use position-based routing include their locations in the header of the request packet, whereas the radios that use topology-based routing include their IDs in the request header, before rebroadcasting the packet.

3.2 Route selection

If the request packet is received by more than one attachment point and (or) the same attachment point receives the request packet from different intermediate nodes, more than one routes exist and the most appropriate one must be selected. For this purpose, two approaches are possible: centralized and distributed. In the centralized approach a route selection center is included in the topology to which all the attachment points forward their received request packets. The center then selects the most appropriate route according to a route selection logic and generates a reply packet containing the selected route to be sent back to the requester. In the distributed approach, every attachment point generates a reply packet and sends it back and it is up to the requester to select the most appropriate route based on the route selection logic. Note that every attachment point also has a unique IP address known to the core network. This IP address is included in the reply packet to start a unicast connection between the attachment point and the requester.

Some disadvantages of the centralized approach are as follows:

• (1) The centralized approach requires the deployment of a new network element, whereas we are interested in solutions that minimize the required changes in the structure of existing networks and impose no additional deployment cost.

• (2) In the centralized approach the route selection decisions are made only based on one-way traversal of packets in the network, i.e., from vehicles to attachment points. However, reply packets may experience different QoS in the case of asymmetric routes or when reply packets go through different intermediate nodes due to topology changes. Therefore, more accurate route selection decisions can be made based on reply packets that reflect the network conditions on both going and returning ways.

As a result, in this article we take the distributed approach. The route selection logic that we incorporate in HMTR is explained in Section 4.1.

Returning a reply packet

The reply packet any attachment point generates includes the route its corresponding request packet has come from in the header. In the state-of-the-art position-based routing protocols for vehicular networking scenarios, the route is defined as a sequence of junctions or physical locations [16–18]. Hence, in order to let both position-based and topology-based routing work properly, the route in our protocol is defined as a sequence of junctions and IDs. The IDs are the IDs of the intermediate vehicles that use topology-based routing for forwarding the request packet which are recorded in the header of the request packet. The junctions are the physical road locations across which the request packet was forwarded over the radios that use position-based routing, calculated using the locations of intermediate vehicles that employ position-based routing and the digital map of the road which is available to every node. On the way back to the requester, the reply packet is forwarded towards the next junction in the route using position-based routing in the parts of the route described by junctions. In the parts described by IDs, the packet is forwarded using topology-based routing. By taking junctions into account instead of the locations of forwarding vehicles when using position-based routing, we make the protocol robust to frequent topology changes as the locations of junctions are fixed.

Example

A typical description of a route is depicted in Figure 2. Vehicle S is the requester of the route and the dotted and dashed curves in the figure represent position-based and topology-based parts of the route, respectively. Also, assume that the location and the ID of a given vehicle I are denoted by L _I and ID _I , respectively. Then, the header of the request packet that the BS receives includes the sequence of locations and IDs (ID _S , L _A , L _B , ID _C , L _D , L _E , ID _F ). After receiving the request packet, the BS determines the route to vehicle S as (ID _F , J ₅ , J ₄ , ID _C , J ₃ , J ₁ , ID _S ). ■

Figure 2

A typical description of a route.

In parts of the route where the reply packet is forwarded using position-based routing, a greedy position-based (geographic) forwarding mechanism is used to forward the packet towards the next junction in the route. In this mechanism each intermediate vehicle forwards the packet to the neighbor geographically closest to the next intended junction in the route. Note that in our protocol greedy forwarding is only used for packet forwarding towards the next junction as opposed to the final destination. Due to topology or connectivity reasons, to successfully deliver the packet to destination, in many urban scenarios, the packet may need to be temporarily forwarded farther from the destination [16, 17]. If the packet forwarding vehicle does not find any next hop vehicles to forward the packet due to temporary disconnections, it starts carrying the packet towards the next junction until another vehicle comes into its range. The possibility of packet carrying makes the protocol robust to disconnections in sparse situations as the packets will not be immediately dumped when a disconnection is detected along the route. As the packet is being forwarded towards the next junction using this mechanism, every forwarding vehicle also checks for the next ID in the route using its other radios and forwards the packet to the vehicle with that ID if it detects it. After the reply packets are received and the most appropriate route is selected by the requester based on the route selection logic, the data and acknowledgment packets are sent along the route, respectively.

4 Mechanisms designed for HMTR

4.1 Route selection logic

The route selection logic is implemented in two steps. The first step is to rule out the candidate routes that do not meet the QoS or budget requirements of vehicles. In the second step, among the remaining candidate routes, attachment points and vehicles select the most appropriate route from the operator and subscriber perspectives, which are based on their priorities in terms of utilization and price, respectively. These steps are detailed in the following two sections.

4.1.1 QoS and (or) budget filtering

Any application that requests access to the Internet may have constraints on some QoS metrics such as delay or bandwidth, which are indicated in the request headers. If an application has a delay constraint on the round trip times of its packets, upon the generation of a request packet the requester includes the generation time of the packet in a field in the header. Any intermediate vehicle that receives this packet subtracts the generation time from the present time to obtain the travel time. At any point the travel time exceeds the delay constraint of the packet, the packet will be dropped.

Similarly, an application may have a bandwidth constraint. In this case, every intermediate vehicle replaces its available bandwidth in the corresponding field in the header if it is smaller than the current value of the field. This value reflects the available bandwidth in the route the packet has experienced up to that point. The packet will be dropped if the available bandwidth is smaller than its required bandwidth. Obtaining the available bandwidth, which is also termed achievable throughput or residual capacity (bps) in the literature has already been discussed in many articles [25–27]. In most of these studies, the total channel usage is measured and subtracted from the channel capacity to obtain the free residual capacity. In addition to restricting the propagation of request packets to limited geographical areas as mentioned in Section 3.1, these filtering mechanisms also limit the propagation of request and reply packets in the network.

Other than delay and bandwidth constraints, the requester may also have a budget constraint indicated in the request header. After calculating the price of the end-to-end route, the attachment point compares it with the budget constraint and dumps the request packet if the maximum budget is exceeded. Otherwise, the attachment point attaches the price to the reply packet it sends back to the requester. This mechanism also limits the propagation of unnecessary packets in the network.

The total price is the summation of the service price and the packet forwarding prices over registered forwarding vehicles. In all access networks, in order to access an attachment point, the corresponding radios have to be registered with the attachment point. However, to relay packets to other vehicles in an ad hoc manner, some wireless technologies, e.g., WiMAX, may require the intermediate nodes to be registered in the corresponding access networks, whereas other wireless technologies, e.g., WLAN, may not require such registrations. In other words, WiMAX radios may be charged for packet forwarding while WLAN radios may operate in the ad hoc mode for free. In the former group of wireless technologies, the packet forwarding prices should be taken into account in the calculation of the overall price. For this purpose, we suggest the following charging strategy for packet forwarding.

When an attachment point receives a request packet, it acquires the packet forwarding prices of the vehicles which are registered with the attachment points of other service providers. For this purpose, the attachment point queries their corresponding AAA servers for the prices of packet forwarding by the registered vehicles. As a result, if the requester selects to use the route comprising those vehicles for packet forwarding, the AAA servers charge the attachment point instead of the registered packet forwarding vehicles. The attachment point in turn charges the requester. Note that the communications to and from the AAA servers take place on the core network via the Internet. Other than the cost of packet forwarding over the registered vehicles, the attachment point also charges the requester for the service it requests, i.e., the service cost.

4.1.2 Candidate route selection

Operator perspective

When the same request packet is received and retained by an attachment point from different routes, all of the candidate routes meet the QoS and (or) the budget requirements. Now, the attachment point should select the most appropriate one for which to generate a reply packet. In order to maximize their revenue, service providers need to make sure the network capacity is used at its fullest which is equivalent to maximizing the utilization. To use the capacity of the network efficiently, the situations in which parts of the network become congested while other parts are not being used at all should be avoided by balancing the packet traffic in the network. For this purpose, we propose that attachment points obtain the difference between available bandwidth on each route and the required bandwidth and select the route with the maximum difference value. This way, the selected will be left with the maximum available bandwidth which in turn maximizes the traffic balancing in the network, thereby minimizing the probability of congestion. We define U = {route 1, route 2,..., route n} as the set of all candidate routes at the attachment point for a given request. If we denote the available bandwidth along route j and the bandwidth required by the application by BW _j and BW_req, respectively, the attachment point selects the route with the maximum difference value, namely route k, as follows

$$\mathsf{\text{route}}k=\underset{\mathsf{\text{route }}j\in U}{\mathsf{\text{arg}}\mathsf{\text{max}}}\left(B{W}_j-B{W}_{\mathsf{\text{req}}}\right).$$

(1)

Subscriber perspective

On the other hand, if the requester receives more than one reply packets each generated by a different attachment point, it is generally interested in selecting the cheapest route that meets its QoS requirements. Since all the routes selected by attachment points meet its QoS needs, the requester simply selects the cheapest option. We define U^' = {route 1, route 2, ..., route n^' } as the set of all candidate routes at the requester. If we denote the price of route j by P _j , the requester selects the route with the minimum price, namely route k^' , as follows

$$\mathsf{\text{route}}{k}^{\prime }=\underset{\mathsf{\text{route }}j\in U^{\prime }}{\mathsf{\text{arg}}\mathsf{\text{min}}}\left(P_j\right).$$

(2)

Up to this point, several user and network-favored parameters such as QoS requirements in terms of delay and bandwidth or budget on the user's side and real-time network conditions in terms of congestion on the network's side have been taken into account in the proposed route selection logic. However, the real-time connectivity of routes, which is pertinent to position-based routing, has not yet been considered. The connectivity of a route is a critical metric particularly when the network is sparse. Because when packets are routed towards disconnected streets, which are very likely in sparse situations, packet forwarding is no longer possible and the packets should be carried which causes much longer delays, thereby increasing the chance of delay requirement violation and packet dropping. In order to take the real-time connectivity of routes into account, we modify the route selection logic as follows. Note that the real-time connectivity is based on more recent vehicular traffic information which is obtained on-the-fly as packets are disseminated in the network, rather than the pre-stored traffic information in the digital maps of vehicles, which may be obsolete and consequently different from present values.

We consider a field in the header of the packets for the connectivity of the route the packet has come from. How the connectivity of each route is calculated is explained in Section 5. For now, we only assume that the connectivity of the route each packet has come from is known and is stored in the respective field in the packet.

Operator perspective

If we denote the connectivity along route j by C _j , in the modified route selection logic the attachment point selects route k as follows

$$\mathsf{\text{route }}k=\left\{\begin{array}{cc}\hfill \underset{\mathsf{\text{route }}j\in V}{\mathsf{\text{arg}}\mathsf{\text{max}}}\left(B{W}_j-B{W}_{\mathsf{\text{req}}}\right)\hfill & \hfill \exists routej:1/{\rho }_{j\mathsf{\text{min}}}<R\hfill \\ \hfill \underset{\mathsf{\text{route }}j\in U}{\mathsf{\text{arg}}\mathsf{\text{max}}}\left(C_j\right)\hfill & \hfill \mathsf{\text{Otherwise}}\hfill \end{array}\right.,$$

(3)

where R is the transmission range, ρ_{j min}is the minimum density of vehicles along route j and V = {route j| route j є U, 1/ρ_{j min}< R}. Since the movements of vehicles are confined to streets and the widths of streets are usually much smaller than the radio transmission range of a vehicle, the movements of vehicles can be considered as one-dimensional movements. Therefore, the reciprocal of the minimum vehicle density along a route represents the maximum average distance between the vehicles on that route. Another field in the header of packets has to be considered for the minimum vehicle density along the route, denoted by ρ_{j min}for route j. Any intermediate vehicle calculates the vehicle density in its neighboring area and rewrites it in the respective field if its value is smaller than the current value of the field. Based on the periodic beacon messages that a vehicle receives, it knows the number of vehicles in its transmission range. So, by dividing the number of vehicles by the length of its coverage area the vehicle density in its immediate neighborhood is obtained.

The condition in (3) differentiates the situations where the network is sufficiently dense such that at least one connected route can be found from the situations where the network is so sparse that no such route can be found and therefore packets need to be partly carried by vehicles before they are forwarded. If routes with sufficient levels of connectivity are found, they can be ranked by the operator or user based on the logic in (1) or (2), respectively. Otherwise, the route with the maximum connectivity is selected, as given by (3). Note that disconnections can only occur in the process of position-based routing as the stability of links have already been verified for the parts of the route involved in topology-based routing. Hence, we are only interested in the density of the vehicles participating in the position-based routing.

Subscriber perspective

Similarly, the requester selects route k^' according to the following modified route selection logic

$$\mathsf{\text{route}}{k}^{\prime }=\left\{\begin{array}{c}\underset{\mathsf{\text{route }}j\in V^{\prime }}{\mathsf{\text{arg}}\mathsf{\text{max}}}\left(P_j\right)\exists \mathsf{\text{route }}j:1/{\rho }_{j\mathsf{\text{min}}}<R\\ \underset{\mathsf{\text{route }}j\in U^{\prime }}{\mathsf{\text{arg}}\mathsf{\text{max}}}\left(C_j\right)\mathsf{\text{Otherwise}}\end{array}\right.,$$

(4)

where V^' = {route j| route j є U^', 1/ρ_{j min}< R}. As the requesting vehicle is constantly moving and new attachment points become available, it is very likely that after a while the selected route is no longer the most appropriate route. Hence, the fields in the header of packets are updated every time packets are forwarded between attachment points and requesters to determine if the current route is about to become invalid and a new route needs to be established.

4.2 Link stability logic

In order to evaluate the stability of a link for a received packet, the period the link is expected to be valid for, i.e., the link lifetime (LLT) is calculated and compared to the expiry time of the packet in its header determined by the application. The link is considered stable for the given packet if its LLT is larger than the expiry time of the packet. The air interface of some wireless technologies supports non-line-of-sight (NLOS) operations. For instance, the air interface of WiMAX technology has adopted scalable orthogonal frequency-division multiple access (OFDMA) technology which supports variable bandwidth sizes between 1.25 and 20 MHz for NLOS operations [28, 29]. If the link between the communicating vehicles is a NLOS link, a two-dimensional circular radio coverage can be considered. In this case, the lower bound of the LLT is taken into account which can be easily calculated by considering the sequence of streets along which the two vehicles leave the circular ranges of each other faster.

In the following, we give a method on how the LLT of a link can be calculated when the wireless technology used over the link only supports line-of-sight (LOS) operations. For any vehicle moving along a street we define leaving borders. A leaving border for a vehicle is a border beyond which the vehicle is considered to be in a new street. As an example, the leaving borders for vehicles A and B are shown in Figure 3. If the two vehicles are in the same street, the time t that takes them to leave each others' transmission ranges R can be obtained from

Figure 3

Leaving borders and other parameters for the vehicles in Section 4.2.

$$\left\{\begin{array}{c}|V_{A}t-V_{B}t+P_A-P_B|=R;\mathsf{\text{moving in the same directions}}\\ {\mathsf{\text{V}}}_{A}t+V_{B}t+P_A-P_B=R;\mathsf{\text{moving in the opposite directions}}\end{array}\right.$$

(5)

where V _A and V _B are the velocities of the vehicles which only take positive values and P _A and P _B are their one-dimensional positions along the street with respect to the moving direction of the vehicle which is calculating the LLT.

It may be the case that one of the vehicles passes its leaving border before the two vehicles leave each others' transmission ranges. In this case, there is a high chance of link breakage at the corners of the junctions due to the objects blocking the line of the sight, unless the new street has the same direction as the previous one. Hence, we need to obtain the turning probabilities from the mobility model and calculate the average LLTs which may not be quite accurate. As an alternative, we take the lower bound of LLTs into account. For the two vehicles in Figure 3 we have

$$\mathsf{\text{The lower bound of LLT}}=\mathsf{\text{min}}\left(t,t_A,t_B\right),$$

(6)

where t is obtained from (5), and t _A and t _B are the earliest times that the current and the previous vehicles get at their leaving borders and are obtained from

$$t_A=\left(d_A+r\right)/V_A$$

(7)

$$t_B=\left(d_B+r\right)/V_B.$$

(8)

d _A and d _B are the distances between the positions of the current and the previous vehicles to the center of the junctions towards which they are moving, and r is the radius of the junction.

5 Route connectivity

As mentioned earlier, the connectivity in the context of position-based routing is defined as the probability that no disconnection exists along the route. A number of previous articles have proposed methods to calculate the connectivity in different street segments in the roadmap, i.e., the probability that the distances between any two adjacent vehicles in a street segment are smaller than the transmission ranges of vehicles [30–32]. However, all these studies use a macroscopic approach for calculating the connectivity. In other words, they are all based on average values of vehicle densities and vehicle speeds in different streets of the roadmap which are stored a-priori in the digital maps of vehicles. However, due to the highly variable network topology, these average values are very likely to be different from instantaneous real-time connectivity observations of individual vehicles along the route in terms of the density of neighbors that arrive in and leave their coverage areas. To the best of our knowledge, our article is the first work that proposes a microscopic approach for calculating the connectivity of routes on the basis of the connectivity observations of individual vehicles along the routes.

We define the vehicle connectivity for vehicle i, denoted by VC _i , as the probability that there exists at least one vehicle ahead of vehicle i and at least one vehicle behind vehicle i in its transmission range. All vehicles continuously calculate their vehicle connectivities. Also, we have vehicles include their most updated vehicle connectivities in the beacon messages they periodically broadcast. For any given route, the connectivity of the route is the product of the vehicle connectivities of all the intermediate vehicles along the route using position-based routing. Hence, the connectivity of route j can be written as

$$C_j=\prod _{i=1}^{N}V{C}_i,$$

(9)

where N is the total number of intermediate vehicles along route j using position-based routing. In HMTR, we get every intermediate vehicle that uses position-based routing to multiply the value in the connectivity field of any received packet by its own vehicle connectivity and rewrite the result in the connectivity field of the packet before rebroadcasting it. In the following we explain how VC _i can be calculated for any vehicle i.

A common assumption in vehicular traffic engineering theory is to consider a normal distribution for the speeds of vehicles in every street [32, 33]. For each street the minimum and maximum allowable speeds to be included in the normal distribution of that street are available in the digital map. In this article, we take the same approach in that we assume that when a vehicle arrives at a street, it takes a fixed speed which remains the same during its residing time in that street. The fixed speed is randomly selected according to the normal distribution of the street. On the other hand, it is widely accepted that in free-flow conditions, in which streets are not congested and vehicles can move as fast as they want, any fixed point on the roadside observes Poisson arrivals of vehicles [31, 32, 34]. Hence, since vehicles are supposed to move at fixed speeds, they also observe Poisson arrivals of other vehicles in their transmission ranges. A typical scenario of vehicles moving on both sides of a street is depicted in Figure 4.

Figure 4

Different flows of vehicle arriving in the range of Vehicle i.

In Figure 4, vehicle i is moving at speed v _i . The arrivals of three independent flows of vehicles are distinguishable by vehicle i. The first flow corresponds to the vehicles that are arriving in the transmission range of vehicle i in the opposite direction and from the front. We denote the arrival rate of this flow of vehicles by λ _o . The second flow corresponds to the vehicles that are moving in the same direction as vehicle i and their average speeds are greater than v _i . Therefore, they arrive in the range of vehicle i from behind. The third flow corresponds to the vehicles moving in the same direction as vehicle i with average speeds smaller than v _i which arrive in the range of vehicle i from the front. We denote the arrival rates of the vehicles moving in the same direction with greater and smaller speeds than v _i by λ _sg , and λ _ss , respectively.

According to our definition the VC _i is the probability that there exists at least one vehicle in transmission range R ahead of it and at least one vehicle in transmission range R behind it. In this study in order to calculate this probability, we use queuing theory [35, 36] to model distance R ahead of vehicle i and distance R behind vehicle i with two M/D/∞ queues. The justification of Poisson arrivals of vehicles in the transmission range which is equivalent to the arrivals of customers in the queues was already discussed. The reasoning behind considering a deterministic distribution for the service time is based on our previous assumption regarding the fixed speeds for vehicles. Since every arriving vehicle in the transmission range of vehicle i has a fixed speed v, its residing time in the range, which is equivalent to the service time of customers in the queues, equals R/(v _i + v) if it has arrived in the opposite direction or equals R/|v _i - v| if it has arrived in the same direction. Note that we assumed that the speed always takes positive values. Having observed this, in our modeling we use the simplifying assumption that the speeds of the flows of vehicles arriving in the opposite direction, in the same direction with greater speeds and in the same direction with smaller speeds are fixed and equal to their average speeds denoted by v _o , v _sg , and v _ss , respectively. Note that every vehicle can calculate both the average arrival rates and average speeds of different flows of vehicles in its range based on its observations. Also, the reason we considered an infinite number of servers for the queues is the fact that every vehicle starts receiving service immediately upon its arrival in the transmission range. Note that the arrivals in the transmission range are mapped onto the arrivals in the queue. The queuing system model is depicted in Figure 5.

Figure 5

Distances R ahead and R behind vehicle i modeled as two M/D/∞ queues.

In the suggested queuing system model, even if one of the queues does not exist, the arrivals of customers in the other queue and their service times are not affected which shows the independence of the queues. As a result of their independence, the VC _i equals the probability that at least one customer resides in the queue in the back multiplied by the probability that at least one customer resides in the queue on the front. Hence, if we denote the probability that n customers reside in the queue in the back and the probability that n customers reside in the queue on the front by P _b (n) and P _f (n), respectively, VC _i can be written as

$$V{C}_i=\sum _{n=1}^{\infty }{P}_b\left(n\right).\sum _{n=1}^{\infty }{P}_f\left(n\right).$$

(10)

Since ${\sum }_{n=0}^{\infty }{P}_b\left(n\right)=1$ and ${\sum }_{n=0}^{\infty }{P}_f\left(n\right)=1$, (10) can be written as

$$V{C}_i=\left(1-P_b\left(0\right)\right)\cdot \left(1-P_f\left(0\right)\right).$$

(11)

We denote the probabilities that n customers belonging to different flows reside in the queues in the back and on the front by P_bo(n), P_bsg(n), P_bss(n) and P_fo(n), P_fsg(n), P_fss(n), respectively. For instance, P_bsg(n) corresponds to the customers in the queue in the back arriving in the same direction with greater speeds. Considering that the arriving flows are independent, (11) can be written as

$$V{C}_i=\left(1-P_{\mathsf{\text{bo}}}\left(0\right)\cdot P_{\mathsf{\text{bsg}}}\left(0\right)\cdot P_{\mathsf{\text{bss}}}\left(0\right)\right)\cdot \left(1-P_{\mathsf{\text{fo}}}\left(0\right)\cdot P_{\mathsf{\text{fsg}}}\left(0\right)\cdot P_{\mathsf{\text{fss}}}\left(0\right)\right).$$

(12)

According to the queuing theory [35, 36], the probability P _n (t) that at a given time t, n customers reside in an M/D/∞ queue with arrival rate λ and fixed service time t _s is equal to the number of arrivals from time t - t _s to time t, i.e., Poisson arrivals with rate λ in a period of time with length t _s . Hence, we have

$$P_n\left(t\right)=\frac{{\left(\lambda t_s\right)}^n}{n!}{e}^{-\lambda t_s},$$

(13)

which is independent of t and holds for any t > t _s . Thus, for any M/D/∞ queue the probability that n customers reside in the queue, P(n), equals

$$P_n\left(n\right)=\frac{{\left(\lambda t_s\right)}^n}{n!}{e}^{-\lambda t_s}.$$

(14)

By setting the arrival rate and the service time to the corresponding values for any of the flows in (12), vehicle connectivity of vehicle i can be obtained as follows

$$V{C}_i={\left(1-e^{-{\lambda }_o{t}_{so}}\cdot e^{-{\lambda }_{sg}{t}_{ssg}}\cdot e^{-{\lambda }_{ss}{t}_{sss}}\right)}^2={\left(1-e^{-\left({\lambda }_o{t}_{so}+{\lambda }_{sg}{t}_{ssg}+{\lambda }_{ss}{t}_{sss}\right)}\right)}^2.$$

(15)

Thus, VC _i for vehicle i and C _j for route j can be obtained.

6 Performance evaluations

6.1 Preliminaries

To evaluate the performance of HMTR, we consider a simplified network topology comprised of only WLAN and WiMAX access networks. The use of WiMAX digital radios is becoming more popular due to their high data rates which support broadband communications and their long transmission ranges which provide a better coverage compared to WLAN radios. The initial WiMAX standard published in 2004, IEEE 802.16 standard [20], was aimed for fixed end-users. Later on, IEEE 802.16e standard [21] was published in 2006 which provided mobility support to end-users moving at speeds of up to 120 km/h. IEEE 802.16e provides data rates up to 15 Mbps and transmission ranges up to 10 km.

An important limitation of IEEE 802.16e standard is that it only supports direct communications from BSs to end-users, which reduces coverage areas due to transmission power constraints and path loss. In order to extend the coverage area outside the ranges of BSs, a new draft standard, IEEE 802.16j was approved by the IEEE-SA Standards Board in 2006 [22] which is based on IEEE 802.16e standard and extends the coverage by using multihop relaying. In the initial drafts of IEEE 802.16j, the relaying nodes are fixed nodes acting as small scale BSs, requiring that they are enabled with some of the functionalities of BSs. However, in more recent versions these limitations are addressed and multihop communications can be carried out over mobile nodes. IEEE 802.16j standard was approved by IEEE-SA Standards Board in 2009 as an amendment to IEEE 802.16 standard [23].

Despite recent developments of WiMAX networks, IEEE 802.11-based WLAN networks will still be used in local environments and continue their growth to become more ubiquitous and to challenge WiMAX networks in larger areas. The Federal Communications Commission (FCC) allocated 75 MHz spectrum to dedicated short range communications (DSRC) [37] at 5.9 GHz frequency band to vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communications in 1999. DSRC was standardized in the draft IEEE 802.11p [38], a variant of IEEE 802.11a standard adjusted for low overhead operations, which supports data rates up to 6 Mbps and transmission ranges up to 300 m. In vehicular settings it is mostly assumed that WLAN radios comply with DSRC 802.11p standard.

Note that the reason we did not include cellular networks in our evaluation model stems from the fact that cellular technology does not support multihop packet routing. In other words, since both WLAN and WiMAX technologies provide ad hoc packet forwarding capabilities, they are better options for evaluating the performance of our proposed routing protocol compared to cellular technology which only provides direct connections from end-users to cellular BSs and therefore can only be used as the last hop of the route. It is worth mentioning that the possibility of using cellular communications as the last hop can be easily included in our evaluation model without adding much complexity.

6.2 Simulation settings

We evaluate the performance of HMTR via simulations. The road topology we use in the simulation is a grid layout derived from a real street map in the TIGER database [39] from US Census Bureau. The street layout is depicted in Figure 2. In our scenario we simulated the mobility of vehicles and the wireless communications between them separately. For simulating the mobility of vehicles we used the simulation of urban mobility (SUMO) [40] which is a well-known and validated microscopic street traffic simulation package. To simulate wireless communications in our scenario, we developed an event-based network simulator using C++. To the best of our knowledge, none of the commonly used network simulators have implemented WiMAX communications with multihop relaying on mobile nodes yet. The outputs of SUMO which include the positions of all vehicles at every time step of the simulation runtime are then used by our network simulator as inputs.

In SUMO, every street is assigned minimum and maximum speeds according to the digital map, and a functionality defines whether the street is a plain street, a source street or a sink street. For any given number of vehicles, every vehicle is randomly injected into one of the source streets. When it reaches a sink street, it is removed from the network and randomly regenerated in another source street, and this procedure continues over the simulation runtime. In order to generate realistic vehicular mobility traces, SUMO supports right-of-way rules at junctions, traffic regulations, and traffic lights. Also, additional weights are assigned to different streets to make them more or less attractive for vehicles when they arrive at junctions. We assigned the weights proportional to the average vehicle densities in the road topology stored in the digital map. We observed that after 2000 s the errors between the vehicle densities obtained in SUMO and the vehicle densities stored in the digital map became smaller than 5% of the stored values for all the streets in the simulation area. Thus, we start sending packets in the network after 2000 s. All vehicle traces during the simulation time are saved in a log file, which is then used in the network simulator.

We have selected the values of WLAN parameters in our evaluation based on [41, 42]. In [42], the performance of the IEEE 802.11 DCF under uniformly distributed traffic among all nodes is analyzed for the non-saturated case. In our simulation scenarios, we define the packet traffic generation in a way that the network is constantly non-saturated. The parameters used in the mobility model and the WLAN parameters are depicted in Tables 1 and 2, respectively. The values of the parameters used in the simulation of WiMAX radios are selected similar to the simulation scenarios in [43], which in turn are based on the discussions in WiMAX forum [44] and readily available deployments of WiMAX device manufacturers, e.g., [45] (Table 3). Since the focus of our study is the evaluation of the proposed routing protocol, we disable the WiMAX adaptive modulation and coding (AMC) feature in our simulation scenario. We consider a fixed data rate and also a fixed transmission range adapted from the simulation scenario investigated in [43].

Table 1 Mobility-related parameters

Table 2 WLAN-related parameters

Table 3 WiMAX-related parameters

In our simulation scenario we consider constant bit rate (CBR) traffic with best effort (BE) service type. Different end-user multimedia categories for a variety of multimedia services were investigated in [46] and it can be observed that the maximum allowable one-way transmission delays for a relatively large number of multimedia services is either 10 s or 1 min. Thus, we set the allowable message travel times in our simulations accordingly.

In the simulations we assume that all vehicles are equipped with both WLAN and WiMAX radios. Note that due to the higher bandwidths of WiMAX hops, attachment points, according to (1), tend to select the routes with the maximum number of WiMAX hops for any given budget. Having observed this, instead of constraining the budget we can alternatively limit the number of WiMAX hops in the routes and obtain the costs for a given maximum allowable number of WiMAX hops in the routes. In our simulation we consider four different routing possibilities: HMTR with WLAN Only where no WiMAX transmission is allowed, HMTR with 1hopWiMAX in which only one WiMAX transmission is allowed in a route, HMTR with 2hopWiMAX in which routes are allowed to have up to two WiMAX hops, and HMTR with WiMAX Only. Note that the reason for considering only these four routing possibilities is that the area in our simulation scenario can be covered by at most three consecutive WiMAX hops. Also, based on the given density of vehicles and the transmission ranges of WiMAX radios in our scenarios, every WiMAX radio can almost always find another WiMAX radio in its transmission range.

6.3 Simulation results

The performance metrics that we consider in our evaluations are packet delivery ratio, packet delivery delay, and cost. The packet delivery ratio is the ratio of the packets the network layer delivers to its higher layer to the packets generated in the higher layer and passed onto the network layer for delivery. The packet delivery ratio accounts for packet droppings that take place when the travel times of packets exceeds their delay constraints. We assume that the transmission costs on all WiMAX radios are fixed and equal to 1 Unit per every 1 Kb, the transmissions on WLAN radios are free of charge and the service costs are the same for all service providers for the same service. Therefore, in the calculation of total costs we only consider the transmission costs regarding the packet forwarding over WiMAX radios. In practice, service providers price their packet forwarding and services based on business considerations, among which use of bandwidth is but one of the factors. However, we tackle the problem at hand from a system design point of view to minimize the cost for vehicular end-users.

We run three rounds of simulations. In the first two rounds, we study how the use of different number of attachment points in the network affects the performance. In the third round, we consider a more realistic scenario in which only a fraction of vehicles are equipped with WiMAX radios.

In the first round of simulations only one attachment point exists in the network and is placed at the top rightmost junction of the network. The packet delivery ratios and the packet delivery delays for maximum allowable one-way delays of 1 min and 10 s are depicted in Figures 6 and 7, respectively. Note that regarding the large number of samples obtained over the simulation time, for the confidence interval of 95% around the mean values, the margins of error for the data points displayed in all of the graphs are of the order of 10^-4.

Figure 6

Packet Delivery Ratio and Delay for maximum delay of 1 min and one attachment point.

Figure 7

Packet Delivery Ratio and Delay for maximum delay of 10 s and one attachment point.

As expected, the more WiMAX forwarding is involved, the better routing performance in terms of both delivery ratio and delay. In the routing possibilities that fully or partially rely on WLAN forwarding, in lower vehicle densities, vehicles mostly resort to packet carrying as opposed to packet forwarding as it is less likely for them to find next-hop WLAN-enabled vehicles in their ranges. As a result, in lower densities only those WLAN radios which are in the proximity of the attachment point can succeed to deliver the packets to the attachment point before the delay constraints are exceeded. Note that in the calculation of packet delivery delays, only the delays of the packets that have been successfully delivered are taken into account. As the number of vehicles increases, the chance of finding next-hop WLAN-enabled vehicles increases and WLAN radios mostly rely on packet forwarding rather than packet carrying. As a result, almost all packets are delivered before the delay constraints are exceeded. This best explains the peaks in the delay graphs. The transmission costs for different routing possibilities are also shown in Table 4. Note that as explained before, transmission costs only depend on the packet forwarding over WiMAX radios. Since for the given transmission ranges and the range of the number of vehicles, vehicles can always find a WiMAX-relaying vehicle in their WiMAX transmission ranges, the average transmission costs stay the same for different number of vehicles.

Table 4 Transmission costs for one attachment point

Also, for the same reason, we observe that WiMAX radios can always find other WiMAX radios in their neighborhoods to which they have stable enough links for topology-based routing. Hence, when there is no limit on the use of WiMAX hops in the routes as in the HMTR with WiMAX Only case, HMTR stands for a pure topology-based routing and the results are comparable to the performance of most state-of-the-art topology-based routing protocols [11–13]. On the other hand, in the HMTR with WLAN Only case it turns out that almost all of the WLAN hops are unstable as a result of their fast movements with respect to their shorter transmission ranges. Therefore, this case stands for pure position-based routing and the results are representative of the state-of-the-art position-based routing protocols [14–18]. As a result, while it is obvious that HMTR with WiMAX Only shows the best performance, the unique feature of our hybrid protocol is the cost tradeoff with respect to the user budget. In other words, the simulation results show that HMTR provides the opportunity to select an intermediate level of performance in terms of delivery ratio and delivery delay for a given budget and average vehicle density, whereas in pure position-based or pure topology-based routing schemes sacrificing the performance or budget may be inevitable in many scenarios.

In the second round of simulations, we study the same performance metrics when two attachment points are deployed. We place the attachment points at the farthest possible distances from each other, i.e., one of them is placed at the top rightmost junction and the other one at the bottom leftmost junction of the network. Even though the population of attachment points is different in different vehicular networking scenarios, e.g., urban or suburban areas or highway environments, the reason for using few attachment points in our experiment setup is that the performance of the routing protocols can be better studied when most users are not directly covered by attachment points and multi hop routing is the only possible way to access the core network. The results of the simulation are shown in Figures 8 and 9. The transmission costs are also shown in Table 5. As we expected, the use of two attachment points yields better performance for the same routing possibilities, which is a result of the smaller average distance between vehicles and attachment points. Note that in the presence of two attachment points and for the vehicle densities, transmission ranges, and vehicle speeds given in the simulation scenario, all vehicles can access one of the attachment points by at most two consecutive WiMAX transmissions. As a result, the HMTR with 2hopWiMAX case gives the same results as the HMTR with WiMAX Only case.

Figure 8

Packet Delivery Ratio and Delay for maximum delay of 1 min and two attachment points.

Figure 9

Packet Delivery Ratio and Delay for maximum delay of 10 s and two attachment points.

Table 5 Transmission costs for two attachment points

It is expected that in the deployment phase of WiMAX technology over vehicles, the penetration rate, i.e., the percentage of vehicles equipped with WiMAX radios is small. Therefore, in the third round of simulations, we study a more realistic scenario where only a fraction of the vehicles in the network are equipped with WiMAX radios. Three cases are considered, in which only 50, 20, or 10% of vehicles are equipped with WiMAX radios, whereas all vehicles have WLAN radios. In order to study how the best achievable performance can be affected by the WiMAX penetration rates, no limit on the maximum allowable number of WiMAX hops in the routes is imposed. Also, in the simulation setup we assume that only one attachment point exists in the network and is placed at the top rightmost junction of the network. The packet delivery ratios and the packet delivery delays for maximum allowable one-way delays of 1 min and 10 s are depicted in Figures 10 and 11, respectively. It is observed in the figures that even when a small percentage of vehicles are enabled with WiMAX capability, the performance is considerably improved. However, if we keep increasing the percentage of WiMAX-enabled vehicles, the improvement obtained becomes less noticeable.

Figure 10

Packet Delivery Ratio and Delay for maximum delay of 1 min and different percentage of WiMAX-enabled vehicles.

Figure 11

Packet Delivery Ratio and Delay for maximum delay of 10 s and different percentage of WiMAX-enabled vehicles.

7 Conclusions

In this article, we have proposed a routing protocol, HMTR, for Internet access in vehicular networking environments. To make packet forwarding adaptable to the rate of topology changes in the network, in HMTR we use position-based and topology-based routing approaches for packet forwarding over unstable and stable links, respectively. In this regard, we have proposed a link stability logic for evaluating the stability of links. Among the candidate routes, the most appropriate one is obtained by using a two-step route selection logic. The first step is to exclude the routes which do not satisfy the QoS requirements or the budgets of route requesting applications. In the second step, among the remaining candidates, the most connected one is selected in sparse vehicular traffic situations. Alternatively, in dense enough vehicular traffic situations the most appropriate candidate is selected with the purpose of packet traffic balancing or cost minimization by the network or vehicles, respectively. In this regard, a novel scheme was proposed to calculate the connectivity of a given route. Simulation results have shown that HMTR enables us to achieve the best possible performance in terms of delivery ratio and delivery delay for a given budget, whereas in pure position-based or pure topology-based routing schemes sacrificing the performance or budget may be inevitable in many scenarios. Furthermore, we have observed that even when only a small fraction of vehicles are equipped with WiMAX radios, a considerable performance improvement is achieved over the case of only WLAN radios.