Cloud-Supported Seamless Internet Access in Intelligent Transportation Systems

Abstract

Great progress of technologies makes intelligent transportation system (ITS) services increasingly desirable. It becomes essential to seamlessly connecting to the Internet for accessing high quality Internet-enabled ITS services. In this context, gateway is recognized as the logical portal to the Internet. The efficiency of gateway regulation hence significantly sways the quality of ITS services. To seamlessly access the Internet in ITSs, a cloud-supported gateway model is proposed in this paper. Accordingly, the weighty load of gateway government, including gateway registration, discovery, selection, dispatching, and handoff, is offloaded from the clients to the appointed cloud servers. Numerical analyses and simulation results suggest that the gateway model proposed in this paper effectively improves the system performance in terms of the packet delivery rate, end-to-end delay, signaling overhead, and gateway connectivity; and, correspondingly enhances the usage experience of Internet-enabled ITS services.

1 Introduction

ITSs [1] aim to intelligently support versatile transport services and traffic management. Advances of vehicular ad hoc networks (VANETs) technologies [2] make ITS services effectively accessible. VANET applications [2] widely support drive safety and infortainment for vehicular users. In VANETs [2], vehicle-to-vehicle (V2V) is the communications between vehicles while vehicle-to-infrastructure (V2I) is the communications between the vehicles and road side units (RSUs). RSU [2], in general, refers to roadside access point or base station that can be connected to the Internet. Thence, V2I communications are suitably used for accessing the Internet in VANETs. Some of ITS services require effectively access to the Internet [1, 3–5]. Gateway here is regarded as the logical entrance to the Internet. Traditionally, Internet access in VANETs is generally provided through roadside gateways [6, 7]. For high mobility and changing topology of the VANETs [2], mobile gateways [6–11] are thus introduced to get stable connections to the Internet for vehicular users.

Accordingly, the efficiency of gateway management in VANETs remarkably affects the usage experience of employing Internet-enabled ITS services. A cloud-supported gateway model, namely the gateway-as-a-service (GaaS), is proposed in this paper to get stable and seamless connection to the Internet in VANETs. Specialized cloud servers are designated for gateway government including gateway registration, discovery, selection, dispatching, and handoff. Thus, the heavy load of gateway management is shifted from the clients to the employed cloud servers. Additionally, when more than one gateway is obtainable around, the gateway with longest link lifetime is selected and reserved in advance by the cloud servers for the requesting client vehicle. Thence, a new link lifetime prediction scheme is also proposed in this paper. Related evaluations are carried out to investigate the effects of vehicle velocity, vehicle density, and gateway density on related performance including packet delivery rate, end-to-end delay, signaling overhead, and gateway connectivity ratio. As will be shown in the numerical analyses and simulation results, the proposed method outperforms a few well-known methods in context of VANETs.

The rest of this paper is organized as follows. Background and related work are introduced in Sect. 2. The proposed method is overviewed in Sect. 3. Numerical analyses and simulation results are presented in Sects. 4 and 5 respectively. Section 6 briefly concludes this paper.

2 Preliminary

ITSs [1] support the services of various modes of transport and traffic management. It makes the users to be better informed, safer, and smarter [1]. Typical applications of ITSs [1] include emergency vehicle notification, automatic road enforcement, variable speed limits, collision avoidance, and dynamic traffic light sequence. Some of these applications need Internet access through the Internet gateways or some roadside infrastructures [3–5].

Zhu et al. [3] survey the issues related to mobility and handoff management in VANETs. Among others, the proposals for V2V and V2I communications in VANETs are systematically addressed. Also, Ammari [12] offers a survey of research work integrating mobile ad hoc networks (MANETs) and the Internet. Specifically, the problems of Internet gateway discovery in MANETs are discussed in [3, 12–14]. In service discovery protocols [3, 13, 14], the mobile nodes tag and register to related Internet gateway for Internet access. Relatively, some solutions [3, 13, 14] extend ad hoc routing protocols to support mobile IP in MANETs.

VANETs are widely accepted as a special type of MANETs. However, special characteristics of VANETs [2], including high mobility and changing topologies, the proposals for MANETs cannot satisfactorily gratify VANET environment. As mentioned in the study [7], several proposals stretch ad hoc routing to the Internet via gateways while a few proposals augment Mobile IP [15] for connecting vehicles to the Internet. Mobile IP and diverse extensions [7, 15] aim at supporting Internet access for mobile nodes. Among them, MMIP6 [7, 13] integrates IPv6-based VANETs with the Internet. A proactive agent discovery protocol is adopted in MMIP6. Also, in MMIP6, geocast is used to decrease the signaling overhead caused by flooding related control messages. Some methods [7, 16–18] plant Mobile IP in the gateway to support mobility management and Internet connection in context of MANETs. The study [18] investigates the performance of using DYMO [19] in VANET environment. As suggested in [7, 18], a few limitations, including deficient lifetime between the vehicles and related gateway, and, inefficient handoff mechanism of connections from one gateway to another, are partially solved. Besides, the well-known project FleetNet [7, 14] try to support Internet connection for VANET users via fixed roadside gateway. In FleetNet [7, 14], based on a revised MIPv6, it proposed a location-based routing protocol and a gateway discovery protocol. However, as mentioned in the studies [7, 14], the special mobility of vehicles was not fully taken into consideration to further optimize related performance of routing in VANET environment.

Plenty of efforts have been proposed to address routing problems in VANETs [2, 20–22]. The signaling overhead of the topology-based approach (e.g. AODV [20, 21, 23]) increases significantly when the variation of network topology increases. Thus, the position-based approach (e.g. GPSR [20, 21, 24]) seems more proper for being adopted in VANETs [2, 20, 21]. Conventionally, Internet access in VANETs is provided through roadside gateways [6, 7]. AODV+ [25], extended from well-known AODV [23], aims at connecting MANETs to the Internet. The performance of three gateway discovery protocols, including proactive, reactive, and hybrid gateway discovery, is investigated in the study [25].

As the special features of VANETs are considered, it is essential to discover a stable route to make VANET applications accessible. Thence, it is important to find a gateway with longer connection time to supply steady Internet access. The route lifetime deeply affect the routing performance in VANETs. The widely-known study in [26] introduces a link lifetime prediction scheme for routing in VANETs. Aside from roadside stationary gateways [6, 7], mobile gateways [6–11] thus are introduced to alternatively support connections to the Internet for VANET users.

Due to high mobility and changing topology of the VANETs [2], it becomes challenging to efficiently discover proper gateways to get stable connection to the Internet. Cloud computing is widely recognized as next generation computing paradigm [27–31]. As defined in [29], based on the Internet protocols, cloud computing characterizes a new model for supplement, consumption, and delivery of information technology (IT). A cloud-empowered gateway model, namely the GaaS, is proposed here to improve Internet connectivity in VANETs for Internet-enabled ITS services. Considered aspects of the proposed GaaS model include gateway registration, discovery, selection, dispatching, reservation, and seamless service handoff. Specially, the gateway with longer link lifetime is selected as the entrance to the Internet. To precisely estimate the link lifetime between the client vehicle and the gateway, a link lifetime prediction scheme is therefore offered in this paper.

3 System Overview

The proposed GaaS gateway model is overviewed here.

3.1 Problem Statement

It becomes essentially important to support seamless Internet access to pleasingly furnish diverse ITS services. A gateway here is able to directly connect to the Internet. Traditionally, a gateway is facilitated on fixed RSUs. Due to high speed of the vehicles, the vehicles may quickly move in and out of the communication rage of a gateway. Thus, it is difficult to seamlessly access the Internet via the stationary gateways. To remedy the limits of the stationary gateways [6, 7], the mobile gateways [6–11] are undertaken to improve the efficiency of Internet access in VANETs. The effectiveness of gateway supervision therefore decisively settles the quality of services (QoS) of Internet-enabled ITS services. The powerful processing and storage capability of cloud computing are supposed to be able to intelligently help the VANET users with efficient gateways management. Therefore, a cloud-supported gateway model, namely the GaaS (Gateway-as-a-Service), is proposed in this paper to govern the gateways for VANET clients. The bulky load of gateway regulation is shifted from the clients to associated powerful cloud servers.

Besides, the special features of VANETs, including high mobility and changing network topology, profoundly affect the performance of VANET routing and consequently hinder the deployment of ITS services. Link lifetime [26] is one of the dominative factors in selecting the next-hop node on the route. Though plenty proposals [2, 26] have been proposed to compute the link lifetime between two nodes, the utility is insufficiently limited. Specifically, in the GaaS, to dispatch related gateways in advance for supporting seamless Internet access, the time point of entering and exiting the coverage of a gateway is necessary to precisely predict the link lifetime between the vehicles and the gateways. Therefore, a link lifetime prediction scheme is newly proposed in this paper for selecting proper next-hop gateways for ITS clients.

3.2 System Model

The system model of the GaaS is depicted in Fig. 1. The main functional modules involved in the GaaS include:

• Gateway: A Gateway is the logical entity which is able to connect to the Internet directly via WiFi/WiMAX networks or cellular networks. On the basis of the mobility of the gateways, two types of gateways are considered in the GaaS. A Stationary Gateway (SG) is part of the roadside infrastructure such as access points (APs) of WiFi/WiMAX networks, or base stations (BSs) of cellular networks. Oppositely, a Mobile Gateway (MG) is the vehicle on the road which is capable of directly connecting to the Internet.

  Fig. 1

  

  System model

• Client Vehicle: AClient Vehicle (CV) is the vehicle which wants to access the Internet and request the GaaS services.

• Relay Vehicle: In case that a CV does not locate within the coverage of any gateway, to connect to a gateway, one or more Relay Vehicles (RVs) will be employed for forwarding packets from/to a CV to/from a gateway.

• Cloud Server: A Cloud Server is the service provider in the cloud. In general, to provide services in the cloud, a server needs to register its services to some well-known name servers in the cloud. In the GaaS, to supply associated services to the VANET clients, two special servers, namely, the GaaS Registrar and the GaaS Dispatcher, are facilitated in the system. A gateway willing to provide gateway services registers itself with the GaaS Registrar. Correspondingly, the GaaS Registrar maintains related information of the gateways. And, according to the information maintained by the GaaS Registrar, the GaaS Dispatcher is responsible of dispatching related gateways for the client vehicles.

3.3 Offloaded GaaS Services

In the GaaS, the powerful processing and storage capability of cloud computing are employed for governing the gateways for the clients. After requesting the GaaS service, the load of gateway management is offloaded from the clients to associated cloud servers. The messages used in the following discussions are defined in Table 1.

Table 1 Used messages

3.3.1 Gateway Registration

As depicted in Fig. 2, a gateway willing to supply the gateway service registers its information with the GaaS Registrar in advance. Note that, related information of a gateway includes its current location, velocity, moving direction, and QoS level (i.e. available resources). The GaaS Registrar then maintains related information in the dedicated database (namely the Gateway Pool) and assigns a GID (Gateway ID) to the gateway. After that, the gateway renews its information either periodically or on demand.

Fig. 2

Gateway registration

3.3.2 Portal Gateway Discovery

To offload the heavy load of gateway management from the clients to related cloud servers, a portal gateway is needed to serve as the initial entrance to the Internet for subsequent process. In the GaaS, as shown in Fig. 3, the CV requests to access the Internet by broadcasting a Solicitation message in its communication range. The gateways receiving the Solicitation message responses by sending back an Advertisement message to the requesting CV. The CV then sends a REQ-GaaS message to the selected gateway.

Fig. 3

Portal gateway discovery

3.3.3 Requesting GaaS Services

As depicted in Fig. 4, a CV offloads the overheads of gateway management to the cloud servers by sending a REQ-GaaS message to currently serving gateway. Afterwards, the GaaS Dispatcher takes over the gateway discovery and dispatching for the requesting CV.

Fig. 4

Requesting the offload GaaS service

3.3.4 Seamless Service Handoff

After receiving the REQ-GaaS message from the requesting CV, the GaaS Dispatcher engages related gateways for the requesting CV. The CV periodically reports its own current status, including the location, speed, direction, and QoS level, to the GaaS Dispatcher via the currently serving gateway. Properly, the GaaS Dispatcher chooses and reserves the best one from among the gateways listed in the Candidate List ahead. For now, in the GaaS, the gateway with longest link lifetime will be chosen as the next-hop gateway for supplying the gateway service. (The details of gateway selection in the GaaS will be described later.) Thus, the load of gateway handoff is shifted to the GaaS Dispatcher and seamless service is accomplished.

3.4 Gateway Selection

In the GaaS, if more than one candidate gateway is available for the CV, the GaaS Dispatcher selects the best gateway for serving the door to the Internet. Related criteria for selecting the gateway is the QoS level supported by the gateways currently recorded in the Candidate List. Generally, the QoS level considered includes packet delivery rate, end-to-end delay, available bandwidth, and predicted link lifetime etc. Currently, when taking into account the special features of VANETs, in the GaaS, the gateway offering longest link lifetime with the client vehicle is chosen as the next-hop gateway for supplying the gateway service. Though a few methods [2, 26] have been proposed to predict the link lifetime between two nodes, they cannot sufficiently meet the requisites of the GaaS. Thus, a new link lifetime prediction scheme is proposed here. In addition to compute the link lifetime, the newly proposed scheme is able to foretell the time point of entering and exiting the coverage of a gateway; that is necessary to support seamless GaaS service.

3.4.1 Link Lifetime Prediction

In the GaaS, three functions for predicting the link lifetime of a gateway and associated time points of entering/exiting the coverage of a gateway are introduced next.

Definition: Mobility Function ${\varvec{f}}_{1}$. Given the velocity vector of a node $\text{ V }_\mathrm{c}=({\alpha },\, {\upbeta })$ and current location of a node ($\text{ X }_\mathrm{c},\, \text{ Y }_\mathrm{c}), f_{1}$ computes new location of the node (X, Y) after time duration t; which is expressed in (1).

$$\begin{aligned} X&= X_{c} +\alpha \text{* } t \nonumber \\ Y&= Y_c +\beta \text{* } t \end{aligned}$$

(1)

Definition: Connectivity Function ${\varvec{f}}_{2}$. Given the coordinate of the node and the gateway is (X, Y) and ($\text{ X }_\mathrm{g},\, \text{ Y }_\mathrm{g}$) respectively, and, as shown in Fig. 5, the communication rage and the velocity vector of a gateway is R and $\text{ V }_\mathrm{g}=({\upgamma },\, {\updelta })$ respectively, $f_{2}$ determines the boundary of the coverage of the gateway; which is expressed in (2).

$$\begin{aligned} \left( {X-\left( {X_{g} +\gamma \text{* }t} \right) } \right) ^{2}+\left( {Y-\left( {Y_{g} +\delta \text{* }t} \right) } \right) ^{2}=R^{2} \end{aligned}$$

(2)

Note that, if the gateway is stationary, as shown in Fig. 6, its velocity vector is (0, 0), thus, the boundary of the coverage of the gateway is expressed in (3).

$$\begin{aligned} \left( {X-X_{g} } \right) ^{2}+\left( {Y-Y_{g} } \right) ^{2}=R^{2} \end{aligned}$$

(3)

Fig. 5

Communication range of a MG

Fig. 6

Communication range of a SG

Definition: Link Lifetime Function ${\varvec{f}}_{3}$. Given current location of the node and the gateway (i.e. ($\text{ X }_\mathrm{c},\, \text{ Y }_\mathrm{c}$) and ($\text{ X }_\mathrm{g},\, \text{ Y }_\mathrm{g}$)), velocity vector of the node and the gateway [i.e. $\text{ V }_\mathrm{c}=({\alpha },\, {\upbeta })$ and $\text{ V }_\mathrm{g}=({\upgamma },\, {\updelta })$], $f_{3}$ computes the link lifetime between the vehicle and the gateway; which is expressed in (4).

$$\begin{aligned} \left\{ {\begin{array}{ll} \left( {X-\left( {X_g +\gamma \text{* }t} \right) } \right) ^{2}+\left( {Y-\left( {Y_g +\delta \text{* }t} \right) } \right) ^{2}=R^{2}&{}\, \\ X=X_c +\alpha \text{* }t &{}\, \\ Y=Y_c +\beta \text{* }t &{}\, \\ \end{array}} \right. \end{aligned}$$

(4)

Solve the expression (4), two solutions of t are gotten, denoted as $\text{ t }_{1}$ and $\text{ t }_{2}$. Among them, the smaller one is taken as the Entry Time and the larger one is taken as the Exit Time of the vehicle. Obviously, $\text{ t }_\mathrm{entry}=\min (\text{ t }_{1}, \,\text{ t }_{2})$ and $\text{ t }_\mathrm{exit}= \max (\text{ t }_{1},\, \text{ t }_{2})$.Three cases are addressed further. Firstly, if both $\text{ t }_\mathrm{entry}$ and $\text{ t }_\mathrm{exit}$ are positive, then link lifetime is $\text{ t }_\mathrm{exit}$–$\text{ t }_\mathrm{entry}$. Secondly, if $\text{ t }_\mathrm{exit}$ is positive and $\text{ t }_\mathrm{entry}$ is negative, then link lifetime is $\text{ t }_\mathrm{exit}$. Thirdly, if no solution is gotten, it means that the vehicle will never enter the coverage of the gateway.

3.4.2 Examples

An example is described to illustrate the operations of three functions mentioned above. Assume that current location of CV, SG, and MG is (10, 10), (500, 500), and (300, 300) respectively. The communication range of the SG and MG is 300m and 250m respectively. The velocity vector of CV and MG is (10, 10) and (8, 0) respectively. As depicted in Fig. 7, the link lifetime between the CV and the SG can be computed by expression (5). Two solutions of $t$ is 27.78 and 70.2 respectively. The former one is taken as entry time and the latter one is taken as exit time. Thence, the link lifetime between the CV and the SG is $70.2 -27.78= 42.42$.

$$\begin{aligned} \left\{ \begin{array}{l} \left( {X - 500} \right) ^{2} + \left( {Y - 500} \right) ^{2} = 300^{2} \\ X = 10 + 10 \text{* } t \\ Y = 10 + 10 \text{* } t \\ \end{array} \right. \end{aligned}$$

(5)

Fig. 7

Connecting to a SG

Similarly, in Fig. 8, the link lifetime between the CV and the MG can be computed by expression (6). Two solutions of $t$ is 23.3 and 43.63 respectively. The former one is taken as entry time and the latter one is taken as exit time. Thence, the link lifetime between the CV and the MG is $43.63-23.30= 20.33$.

$$\begin{aligned} \left\{ \begin{array}{l} \left( {X - \left( {300 + 8 \text{* } t} \right) } \right) ^{2} + \left( {Y - \left( {300 + 0 \text{* } t} \right) } \right) ^{2} = 250^{2} \\ X = 10 + 10 \text{* } t \\ Y = 10 + 10 \text{* } t \\ \end{array} \right. \end{aligned}$$

(6)

Fig. 8

Connecting to a MG

3.5 Discussions

Comparisons between the GaaS and three well-known routing protocols, including the AODV [23], the GPSR [24], and the AODV+ [25], are briefly summarized in Table 2. All these four protocols support discover gateways on demand. Specially, reactive, proactive, and hybrid gateway discovery are also supported in ADOV+ [25]. Both AODV [23] and AODV+ [25] belong to topology-based routing while GPSR [24] and GaaS are categorized as position-based routing. Besides, both AODV [23] and AODV+ [25] select the gateway with least hop count. Relatively, the gateway with shortest distance to the destination node is picked in GPSR [24]. In contrast, the gateway with longest link lifetime is chosen in the GaaS. Also, assisted by the employed cloud servers, beforehand gateway reservation is carried out in the GaaS to support seamless gateway service.

Table 2 Protocols comparisons

4 Numerical Analyses

4.1 Analysis Model

To evaluate the performance of the GaaS, related numerical analyses are presented here. The definitions of related parameters used in the following analyses are collected in Table 3. Related descriptions of nine possible state transitions are listed in Table 4. Define $S_{i,x} \rightarrow S_{i+1,y}$ as the state transition from $S_{i,x}$ to $S_{i+1,y}$ when the CV moves from $\text{ G }_\mathrm{i}$ to $\text{ G }_\mathrm{i+1}$. Also, the Markov chain model adopted in the following analyses is illustrated in Fig. 9.

Table 3 Parameter definition

Table 4 State transition matrix of $S_{i,x} \rightarrow S_{i+1,y}$

Fig. 9

Markov chain model

4.2 Performance Analyses

Without losing the generalities, the lifetime of a link is mutually independent. Assume that the average time the CV cannot directly connect to a gateway is $\alpha$. Therefore, the breaking rate of the connection is $\frac{1}{\alpha }$. That is, the connection breaking rate ($\lambda$) is computed as expression (7).

$$\begin{aligned} \lambda =\frac{1}{\alpha } \end{aligned}$$

(7)

In this paper, the exponential distribution is used to modeling the connection breaking rate. Thus, the probability density function (pdf) of the connection breaking rate is given by expression (8).

$$\begin{aligned} f(t)=\lambda e^{-\lambda t} \end{aligned}$$

(8)

Thus, its cumulative distribution function (cdf) of the connection breaking rate is calculated as expression (9).

$$\begin{aligned} F(t)=1-e^{-\lambda t} \end{aligned}$$

(9)

Therefore, the cdf of a CV can directly connect to a gateway is computed as expression (10).

$$\begin{aligned} F(t)=e^{-\lambda t} \end{aligned}$$

(10)

In case, the CV can connect to a gateway via a few RVs. Assume that the average time the CV cannot connect to a gateway via a few RVs is $\beta$. Hence, the breaking rate of the relayed connection is $\frac{1}{\beta }$. That is, the relayed connection breaking rate ($\gamma$) is computed as expression (11).

$$\begin{aligned} \gamma =\frac{1}{\beta } \end{aligned}$$

(11)

Again, the exponential distribution is used to modeling the relayed connection breaking rate. Thus, the pdf is given by expression (12).

$$\begin{aligned} f(t)=\gamma e^{-\gamma t} \end{aligned}$$

(12)

Thus, the cdf of the relayed connection breaking rate is calculated as expression (13).

$$\begin{aligned} F(t)=1-e^{-\gamma t} \end{aligned}$$

(13)

For that reason, the cdf of a CV can connect to a gateway via a few relays is computed as expression (14).

$$\begin{aligned} F(t)=e^{-\gamma t} \end{aligned}$$

(14)

Consequently, the cdf of the CV cannot get gateway service neither directly connected to a gateway or connected to a gateway via a few RVs is given by expression (15)

$$\begin{aligned} F(t)=1-e^{-\lambda t}-e^{-\gamma {t}} \end{aligned}$$

(15)

4.2.1 Performance of Direct Routes

In case that, initially, the CV can directly connect to a gateway. In our system, the GaaS Dispatcher reserves k-hop-ahead gateways for the CV. Then, the CV can directly connect to the next hop gateway, or the CV can connect to the next hop gateway via a relayed route, or the CV cannot connect to any gateway. In our design, the CV needs discovering gateways only when either it connects to the next hop gateway via a relayed route or the CV cannot connect to any gateway. The cdf of the scenario ($\text{ S }_{0} \rightarrow \text{ S }_{\mathrm{n},2}$) and the scenario ($\text{ S }_{0} \rightarrow \text{ S }_{\mathrm{n},3}$), are given by expressions (16) and (17) respectively. The resulting cdf of gateway discovery is computed as expression (18).

$$\begin{aligned} F(t)&= (e^{-\lambda t})\times (e^{-\lambda t})^{k}\times (e^{-\gamma t}) \end{aligned}$$

(16)

$$\begin{aligned} F(t)&= (e^{-\lambda t})\times (e^{-\lambda t})^{k}\times (1-e^{-\lambda t}-e^{-\gamma t}) \end{aligned}$$

(17)

$$\begin{aligned} F(t)&= (e^{-\lambda t})\times (e^{-\lambda t})^{k}\times [(e^{-\gamma t})+(1-e^{-\lambda t}-e^{-\gamma t})] \nonumber \\&= [(e^{-\lambda t})^{k+1}-(e^{-\lambda t})^{k+2}] \end{aligned}$$

(18)

Thus, in our design, the expected time spent for discovering gateway (E[T]) can be calculated as expression (19).

$$\begin{aligned} E[T]&= \int \limits _{0}^{\infty } {F(t)dt} \nonumber \\&= \int \limits _{0}^{\infty } {\{(e^{-\lambda t})\times [(e^{-\lambda t})^{k}-(e^{-\lambda t})^{k+1}]\}dt} \nonumber \\&= \int \limits _{0}^{\infty } {((e^{-(k+1)\lambda t})-(e^{-(k+2)\lambda t}))dt} \end{aligned}$$

(19)

Comparatively, in AODV+, no gateway reservation mechanism is facilitated, the CV needs discovering gateways for each time it moves out of the coverage of currently serving gateway. That is, the CV have to discover the next-hop gateway when it connects to the next hop gateway directly, or when it connects to the next hop gateway via a relayed route, or when it cannot connect to any gateway. The cdf of the scenario ($\text{ S }_\mathrm{i} \rightarrow \text{ S }_{\mathrm{i+1},1}$), the scenario ($\text{ S }_\mathrm{i} \rightarrow \text{ S }_{\mathrm{i+1},2}$), and the scenario ($\text{ S }_\mathrm{i} \rightarrow \text{ S }_{\mathrm{i+1},3}$), are given by expressions (20), (21), and (22) respectively. The resulting cdf of gateway discovery is computed as expression (23).

$$\begin{aligned} F(t)&= (e^{-\lambda t})\times (e^{-\lambda t}) \end{aligned}$$

(20)

$$\begin{aligned} F(t)&= (e^{-\lambda t})\times (e^{-\gamma t}) \end{aligned}$$

(21)

$$\begin{aligned} F(t)&= (e^{-\lambda t})\times (1-e^{-\lambda t}-e^{-\gamma t}) \end{aligned}$$

(22)

$$\begin{aligned} F(t)&= (e^{-\lambda t})\times [(e^{-\lambda t})+(e^{-\gamma t})+(1-e^{-\lambda t}-e^{-\gamma t}) \nonumber \\&= (e^{-\lambda t}) \end{aligned}$$

(23)

Thus, in AODV+, the expected time spent for discovering gateway (E[T]) is given by expression (24).

$$\begin{aligned} E[T]&= \int \limits _{0}^{\infty } {F(t)dt} \nonumber \\&= \int \limits _{0}^{\infty } {e^{-\lambda t}dt}\nonumber \\&= \frac{1}{\lambda } \nonumber \\&= \alpha \end{aligned}$$

(24)

Summary In case that the CV can directly connect to a gateway. As shown in Fig. 10a, both in the AODV+ and the proposed method, E[T] increases when ${\alpha }$ (i.e. the average time the CV cannot directly connect to a gateway) increases. Also, as shown in Fig. 10b, E[T] of AODV+ keeps constant as $k$ (i.e. the number of gateways to which the CV can directly connected before a new gateway discovery is issued) increases. Oppositely, E[T] of the proposed method decreases as $k$ increases. Basically, the expected time spent for discovering gateway (E[T]) of the AODV+ is longer than that of the proposed method.

Fig. 10

a E[T] with various ${\alpha }$. b E[T] with various k

4.2.2 Performance of Relayed Routes

In case that, initially, the CV can connect to a gateway via a relayed route. In our system, the GaaS Dispatcher reserves k-hop-ahead gateways for the CV. Then, the CV can directly connect to the next hop gateway, or the CV can connect to the next hop gateway via a relayed route, or the CV cannot connect to any gateway. In our design, the CV needs discovering gateways only when either it connects to the next hop gateway via a relayed route or the CV cannot connect to any gateway. The cdf of the scenario ($\text{ S }_{0} \rightarrow \text{ S }_{\mathrm{n},2}$) and the scenario ($\text{ S }_{0} \rightarrow \text{ S }_{\mathrm{n},3}$), are given by expressions (25) and (26) respectively. The resulting cdf of gateway discovery is computed as (27).

$$\begin{aligned} F(t)&= (e^{-\gamma t})\times (e^{-\lambda t})^{k}\times (e^{-\gamma t}) \end{aligned}$$

(25)

$$\begin{aligned} F(t)&= (e^{-\gamma t})\times (e^{-\lambda t})^{k}\times (1-e^{-\lambda t}-e^{-\gamma t}) \end{aligned}$$

(26)

$$\begin{aligned} F(t)&= (e^{-\gamma t})\times (e^{-\lambda t})^{k}\times [(e^{-\gamma t})+(1-e^{-\lambda t}-e^{-\gamma t})] \nonumber \\&= (e^{-\gamma t})\times [(e^{-\lambda t})^{k}-(e^{-\lambda t})^{k+1}] \end{aligned}$$

(27)

Thus, in our design, the expected time spent for discovering gateway (E[T]) can be computed as (28).

$$\begin{aligned} E[T]&= \int _{0}^{\infty } {F(t)dt} \nonumber \\&= \int _0^\infty {\{(e^{-\gamma t})\times [(e^{-\lambda t})^{k}-(e^{-\lambda t})^{k+1}]\}dt} \end{aligned}$$

(28)

Oppositely, in the AODV+, no gateway reservation mechanism is facilitated, the CV needs discovering gateways when it connects to the next hop gateway directly, or it connects to the next hop gateway via a relayed route, or the CV cannot connect to any gateway. The cdf of the scenario ($\text{ S }_\mathrm{i} \rightarrow \text{ S }_{\mathrm{i+1},1}$), the scenario ($\text{ S }_\mathrm{i} \rightarrow \text{ S }_{\mathrm{i+1},2}$), and the scenario ($\text{ S }_\mathrm{i} \rightarrow \text{ S }_{\mathrm{i+1},3}$), are given by expressions (29), (30), and (31) respectively. The resulting cdf of gateway discovery is computed as expression (32).

$$\begin{aligned} F(t)&= (e^{-\gamma t})\times (e^{-\lambda t}) \end{aligned}$$

(29)

$$\begin{aligned} F(t)&= (e^{-\gamma t})\times (e^{-\gamma t}) \end{aligned}$$

(30)

$$\begin{aligned} F(t)&= (e^{-\gamma t})\times (1-e^{-\lambda t}-e^{-\gamma t}) \end{aligned}$$

(31)

$$\begin{aligned} F(t)&= (e^{-\gamma t})\times [(e^{-\lambda t})+(e^{-\gamma t})+(1-e^{-\lambda t}-e^{-\gamma t}) \nonumber \\&= (e^{-\gamma t}) \end{aligned}$$

(32)

Thus, in the AODV+, the expected time spent for discovering gateway (E[T]) can be computed as expression (33).

$$\begin{aligned} E[T]&= \int \limits _{0}^{\infty } {F(t)dt} \nonumber \\&= \int _{0}^{\infty } {e^{-\gamma t}dt} \nonumber \\&= \frac{1}{\gamma } \nonumber \\&= \beta \end{aligned}$$

(33)

Summary In case that the CV can connect to a gateway via a relayed route. The expected time spent for discovering gateway (E[T]) of the AODV+ and the proposed method is compared in Fig. 11. As shown in Fig. 11a, both in the AODV+ and proposed method, E[T] increases when ${\upbeta }$ (i.e. the average time the CV cannot connect to a gateway via a few RVs) increases. Also, as shown in Fig. 11b, E[T] of the AODV+ keeps constant as k increases. Oppositely, E[T] of the proposed method decreases as $k$ (i.e. the number of gateways to which the CV can directly connected before a new gateway discovery is issued) increases. Apparently, the expected time spent for discovering gateway (E[T]) of the AODV+ is longer than that of the proposed method.

Fig. 11

a E[T] with various ${\upbeta }$. b E[T] with various k

5 Simulations

5.1 Test Bed and Metrics

The following simulations are implemented in NS2 [32]. Total simulation time is 500 s. 60–100 vehicles are randomly deployed in a $2000 \text{ m }\times 2000$ m area. The number of SG and MG is 2–4 and 1–2 respectively. The average velocity of CV and MG is 6–15 and 5 m/s respectively. IEEE 802.11 is used as the MAC layer protocol; whose bandwidth is 2 Mbps. Assumed transmission type is constant bit rate (CBR); whose transmission rate is 512 Kbps. The communication range of a node is 250 m. 10 sessions are created in the experiments. Manhattan mobility model [33] is adopted in the simulations.

The metrics used in the performance evaluation are defined next. Firstly, the Link lifetime is defined as the time duration before a link breakage. In this paper, a link can exist between two vehicles or between a vehicle and a gateway. Secondly, the Time to connect is defined as the time needed for a CV to get connected with a gateway after issuing a connect request. In this paper, a vehicle can directly connect to a gateway if it gets into the coverage of a gateway. Or, it can indirectly connect to a gateway via a multi-hop relayed route going through a few RVs. Thirdly, the Packet delivery rate is defined as the rate of successfully delivered data packets sent from the source node to the destination node. Fourthly, the End-to-end delay is the average needed end-to-end delay of all successfully delivered data packets sent from the source node to the destination node. Fifthly, the Signaling load is defined as the average number of control messages needed to deliver a single data packet. Sixthly, the Gateway connectivity is defined as the percent of time a CV can connect to at least one gateway. The performance of the proposed GaaS is compared with a few well-known routing protocols, including the AODV [23], the GPSR [24], and the AODV+ [25], in terms of packet delivery rate, end-to-end delay, signaling overhead, and gateway connectivity. Furthermore, the effects of a few factors, including the vehicle velocity, the vehicle density, and the gateway density, are investigated.

5.2 Comparing SG and MG

Related simulations are carried out to examine the feasibility of the deployment of SG (Stationary Gateway) and MG (Mobile Gateway) in VANETs. Related results of numerical analyses and simulations are illustrated in Fig. 12 to verify the link lifetime prediction scheme proposed in this paper. Generally speaking, related results of the numerical analyses and simulations are consistent. For both SG and MG, the link lifetime decreases as the vehicle velocity increases. And, the link lifetime of the MG is longer than that of the SG. It implies that the usage of MGs in VANETs is potentially desirable.

Fig. 12

Link lifetime prediction

In addition, to investigate the time needed for a CV (Client Vehicle) can catch up with and connect to a gateway after issuing a connection request, related results of numerical analyses and simulations are shown in Fig. 13. The results of the numerical analyses and simulations are approximately agreeing. For both MG and SG, the time needed to connect to a gateway decreases as the vehicle velocity increases. And, the time needed to connect to the MG is longer than that of connecting to the SG. Remind that the velocity of a SG is zero. Therefore, the relative velocity between the CV and the MG is smaller than that between the CV and the SG. Hence, more time is needed for a CV to catch up with and connect to a MG.

Fig. 13

Time needed to connect to a gateway

5.3 Packet Delivery Rate

In Fig. 14, for all four methods, the packet delivery rate decreases as the vehicle velocity increases. Because increased vehicle velocity results in more frequent route breakage and corresponding lower packet delivery rate. The proposed method presents higher packet delivery rate than the other three methods for various vehicle velocity.

Fig. 14

Packet delivery rate for various vehicle velocity

Also, as shown in Fig. 15, the packet delivery rate increases as the vehicle density increases for all four methods. In this paper, when the CV moves out of the coverage of a gateway, the RVs forward messages from/to related gateways. Thus, increased vehicle density supplies more vehicles for being employed as RVs. That is, increased vehicle density raises the success rate of arranging the RVs for forwarding packets; that results in higher packet delivery rate. And, the proposed method presents higher packet delivery rate than the other three methods for various vehicle density.

Fig. 15

Packet delivery rate for various vehicle density

Moreover, Fig. 16 displays that, for all four methods, the packet delivery rate increases as the gateway density increases. Increased gateway density offers more gateways for handoff. That is, increased gateway density increases the overall coverage of gateways and promotes the success rate of connecting to a gateway; that generates higher packet delivery rate. As well, the proposed method presents higher packet delivery rate than the other three methods for various gateway density. The comparisons of packet delivery rate of four methods are listed in Table 5.

Fig. 16

Packet delivery rate for various gateway density

Table 5 Packet delivery rate comparisons

5.4 End-to-End Delay

For all four methods, as depicted in Fig. 17, the end-to-end delay increases as the vehicle velocity increases. Because increased vehicle velocity results in more frequent broken connections and more gateway discovery; that thus yields longer end-to-end delay. The proposed method presents shorter end-to-end delay than the other three methods for various vehicle velocities.

Fig. 17

End-to-end delay for various vehicle velocity

In Fig. 18, the end-to-end delay decreases as the vehicle density increases for all four methods. In this paper, when the CV moves out of the coverage of any gateways, the RVs forward messages from/to related gateways. Thus, increased vehicle density supplies more RVs for utilization. That is, increased vehicle density raises the success rate of arranging the RVs; that causes less end-to-end delay. The proposed method causes less end-to-end delay than the other three methods for various vehicle densities.

Fig. 18

End-to-end delay for various vehicle density

As seen in Fig. 19, for all four methods, the end-to-end delay decreases as the gateway density increases. Increased gateway density offers more gateways for selection for handoff. That is, increased gateway density increases the overall coverage of gateway and promotes the success rate of connecting to a gateway; that results in less time for gateway discovery and corresponding less end-to-end delay. Besides, the proposed method needs less end-to-end delay than the other three methods for various gateway densities. The comparisons of end-to-end delay for four methods are listed in Table 6.

Fig. 19

End-to-end delay for various gateway density

Table 6 End-to-end delay comparisons

5.5 Signaling Overhead

In Fig. 20, for all four methods, the signaling load increases as the vehicle velocity increases. Because increased vehicle velocity results in more frequent broken connections and more gateway discovery; that results in more signaling load. The proposed method presents lowest signaling load than the other three methods for various vehicle velocity.

Fig. 20

Signaling load for various vehicle velocity

You can also find in Fig. 21, the signaling load increases as the vehicle density increases for all four methods. Because that increased vehicle density raises the number of signaling messages sent in the system; that needs more signaling load. Also, the proposed method presents less signaling load than the other three methods for various vehicle density.

Fig. 21

Signaling load for various vehicle density

Figure 22 illustrate that the signaling load decreases as the gateway density increases for all four methods. Increased gateway density offers more gateways for handoff. In other words, increased gateway density increases the overall coverage of gateway and promotes the success rate of connecting to a gateway; that results in less signaling load for gateway discovery. The proposed method presents less signaling load than the other three methods for various gateway density. Note that, AODV+ yields most signaling load. Proactive gateway discovery is adopted in AODV+. Thus, related signaling messages are periodically broadcast in the system to discover the gateways; that causes more signaling load. The comparisons of signaling load for four methods are listed in Table 7.

Fig. 22

Signaling load for various gateway density

Table 7 Signaling load comparisons

5.6 Gateway Connectivity Ratio

In Fig. 23, the relationship of the gateway connectivity and the vehicle velocity is not remarkably obvious. The proposed method presents higher gateway connectivity than the other three methods for various vehicle velocities. Similarly, the relationship of the gateway connectivity and the vehicle density is not impressively apparent in Fig. 24. The proposed method presents higher gateway connectivity than the other three methods for various vehicle densities.

Fig. 23

Gateway connectivity ratio for various vehicle velocity

Fig. 24

Gateway connectivity ratio for various vehicle density

As seen in Fig. 25, for all four methods, the gateway connectivity increases as the gateway density increases. Gateway density directly determines the success rate of discover proper gateway for handoff. Increased gateway density offers more gateways for handoff. Therefore, increased gateway density increases the overall coverage of gateway and promotes the success rate of connecting to a gateway; that offers higher gateway connectivity. As well, the proposed method presents higher gateway connectivity than the other three methods for various gateway densities. The comparisons of gateway connectivity for four methods are listed in Table 8.

Fig. 25

Gateway connectivity ratio for various gateway density

Table 8 Gateway connectivity comparisons

5.7 Performance Comparison

In both the AODV and the AODV+, the gateway with least hop count is selected for handoff. Oppositely, in GPSR, the gateway being closest to the destination is picked as the next-hop. Comparatively, in the proposed method, the gateway with longest link lifetime is chosen as the successor; that yields less broken connections and less gateway discovery. Thence, it presents higher packet delivery rate, shorter end-to-end delay, less signaling load, and raised gateway connectivity. Moreover, in the proposed method, assisted by related cloud servers, the next gateway is selected and reserved in advance for potential handoff; that yields less handoff delay and reduced service interruption time. As a result, it presents greatly improved packet delivery rate, less end-to-end delay, less signaling load, and better gateway connectivity. The performance of the proposed method and three well-known methods are compared in Table 9. The results imply that the proposed method outperforms the other three methods in terms of packet delivery rate, end-to-end delay, signaling load, and gateway connectivity.

Table 9 Performance comparisons

6 Conclusions

A cloud-supported gateway model, namely the GaaS, is proposed in this paper for stably providing seamless Internet access in ITSs. In the GaaS, a few cloud servers are designated for gateway management. Thus, the heavy load of gateway government is shifted from the clients to the designated cloud servers. Numerical analyses and simulation results suggest that the proposed gateway model uplifts the system performance including packet delivery rate, end-to-end delay, signaling overhead, and gateway connectivity; and, shall promote the usage experience of the Internet-enabled ITS services. To implement the GaaS system, participatory vehicles need furnishing on board units (OBUs) supporting the generation and dissemination of the positioning information (i.e. the location, speed, and moving direction of the vehicles). Besides, the OBUs are capable of receiving and processing information delivered by the cloud servers. Correspondingly, related WiFi/WiMAX APs and/or Cellular BSs have to be properly deployed alongside the road for transferring related information from/to associated cloud servers to/from the clients. The cloud servers and gateways need being equipped with related data structures and algorithms proposed in the GaaS. Thoughtfully, the scalability problem will profoundly impact the system performance. Scalable schemes based on hierarchy or cluster should be creatively elaborated in the future.