Adaptive QoS-Aware Multi-Metrics Gateway Selection Scheme for Heterogenous Vehicular Network ^†

Abstract

A heterogeneous vehicular network (HetVNET) is a promising network architecture that combines multiple network technologies such as IEEE 802.11p, dedicated short-range communication (DSRC), and third/fourth generation cellular networks (3G/4G). In this network area, vehicle users can use wireless fidelity access points (Wi-Fi APs) to offload 4G long-term evolution (4G-LTE) networks. However, when using Wi-Fi APs, the vehicles must organize themselves and select an appropriate mobile gateway (MGW) to communicate to the cellular infrastructure. Researchers are facing the problem of selecting the best MGW vehicle to aggregate vehicle traffic and reduce LTE load in HetVNETs when the Wi-Fi APs are unavailable for offloading. The selection process utilizes extra network overhead and complexity due to the frequent formation of clusters in this highly dynamic environment. In this study, we proposed a non-cluster adaptive QoS-aware gateway selection (AQAGS) scheme that autonomously picks a limited number of vehicles to act as LTE gateways based on the LTE network’s load status and vehicular ad hoc network (VANET) application’s QoS requirements. The present AQAGS scheme focuses on highway scenarios. The proposed scheme was evaluated using simulation of Urban mobility (SUMO) and network simulator version 2 (NS2) simulators and benchmarked with the clustered and non-clustered schemes. A comparison was made based on the end-to-end delay, throughput, control packet overhead (CPO), and packet delivery ratio (PDR) performance metrics over Voice over Internet Protocol (VoIP) and File Transfer Protocol (FTP) applications. Using VoIP, the AQAGS scheme achieved a 26.7% higher PDR compared with the other schemes.

1. Introduction

The transportation framework continues to advance by focusing on building new streets and fixing old ones to add to the framework, making it brilliant and insightful. The aim of an intelligent transportation system (ITS) is to make cars, side-of-the-road sign sheets, and traffic signals intelligent enough to transmit information through remote technologies [1]. The concept of a vehicle ad hoc network (VANET), which is defined by self-organization and decentralization, makes the transportation system agreeable and efficient [2,3,4].

The extent to which this reversal is possible has been shown by the establishment of many exploration projects concerning vehicular communication systems. Several international research projects have been launched to better understand this type of system, such as the AKTIV venture in Germany [5]. In addition, significant progress has been made inside of the vehicles themselves. Onboard units (OBUs) are now installed in the vast majority of vehicles, and they are used for vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communications [3,6]. It will be standard by the end of 2027 that all vehicles will be outfitted with OBUs [7]. However, a critical exertion appears in the exercises conducted around the world to normalize the technology. The improvement of IEEE 802.11 technology to IEEE 802.11p is an example of such an effort [8]. IEEE 802.11p is a VANET correspondence protocol that uses dedicated short-range communications (DSRC) remote channels for connectivity [9,10,11]. It offers an easy and simple organization. However, it suffers from high deferral, poor quality of service (QoS), and powerless adaptability.

Due to these shortcomings, IEEE 802.11p VANET is unable to meet the increasing demand for high QoS network applications that vehicles’ passengers need when driving. In vehicular communication, this demand highlights the importance of heterogeneous network architecture. The heterogeneous vehicular network (HVN) combines VANET with another network technology to provide a robust and reliable network system [12]. The VANET and long-term evaluation network (LTE) integration mechanism allow the VANET network to maintain a stable and continuous connection while maintaining the QoS of multiple VANET applications [13]. Nonetheless, LTE networks experience a resource shortage because of the expanding number of versatile associated gadgets [14]. Simply permitting vehicles to directly convey to the LTE network in VANET-LTE incorporation may heighten the issue of overburdening. To address this problem, vehicles must communicate as a group and designate a single vehicle as the gateway to the infrastructure. The vehicle may be either a cluster head (CH) or a cluster member (CM). However, this method takes time, increases network overhead, and hurts the QoS of VANET applications [15,16].

The vehicle density determines the load of an LTE network in a vehicular environment. Vehicle density is affected by not only the type of road, but also the time period [17]. For the model, in the peak hours, the vehicle density on the highway is expected to be high, and the probability of the LTE network being occupied by many soliciting associations will be very high. Permitting all vehicles to convey to the LTE network during peak hours will elevate the issue of overloading. The best strategy is to characterize the vehicles serving as a mobile gateway (MGW) that can aggregate delay tolerance (DT) traffic on behalf of the other vehicles and transmit them to the infrastructure network [18,19]. However, during non-peak hours, fewer vehicles are expected to be available, which causes the LTE network to unwind because of the presence of a low-level traffic load. For this situation, to notice the QoS of the VANET applications and increment the use of LTE network organization, the best technique has been to permit all vehicles to connect directly to LTE evolved Node B (LTE-eNB).

To take advantage of the differences in vehicle density that can be observed on highways, this research proposes a non-cluster adaptive QoS-aware gateway selection (AQAGS) scheme that chooses a small number of MGW vehicles to act as the gateways to the LTE network depending on the LTE network’s load status and the VANET applications’ QoS requirements. MGWs are responsible for aggregating the traffic from other vehicles and communicating with the LTE network infrastructure within their IEEE 802.11p service range.

The suggested method is adaptive in that the MGW is defined only when the LTE-residual eNB’s load capacity falls below a predefined threshold, and DT is used. Additionally, when MGWs should be established, the simple adaptive weight (SAW) method was used to refine the multimetric MGW selection mechanism suggested by the AQAGS scheme. The MGW selection process accounted for metrics such as receive signal power, usable load power, intervehicle size, and link lifetime. To the best of our knowledge, none of the existing gateway selection schemes considers the load capacity of the LTE network and QoS requirements in the proposed solutions.

The remainder of the article is laid out as follows. The related work from the literature in Section 2 is extensively explored. The proposed AQAGS scheme is explained in Section 3. Section 4 discusses the AQAGS scheme’s performance evaluation. Finally, the article concludes with Section 5.

2. Related Work

The majority of the suggested gateway collection schemes in the VANET domain are either cluster-based or non-cluster-based [20]. This distinction depends on how the vehicles are organized prior to selecting the MGW. The authors of [15,21,22,23] proposed a cluster-based gateway selection mechanism in a VANET-LTE integration architecture.

Based on a VANET universal mobile telecommunication system (VANET-UMTS) convergence architecture, the authors of [24] suggested a cluster-based multimetric adaptive mobile gateway management mechanism (CMGM). The proposed CMGM mechanism aimed to cut down on the number of vehicles that directly link to the UMTS network. This is accomplished by encouraging a limited number of vehicles equipped with both UTRAN and IEEE 802.11p interfaces to be considered as possible MGW applicants, capable of relaying the traffic from the other vehicles to the UMTS network. The potential MGW candidates are required to form a cluster depending on the movement direction of the vehicles and UMTS receive signal strength (UMTS-RSS). The MGW candidate that is nearest to the center of the cluster is constantly chosen as the CH. Furthermore, in the case of the ordinary vehicle that wants to communicate to the UMTS network, the algorithm proposed a multicriteria gateway selection algorithm based on the receive signal strength (RSS), mobility, speed, and link stability criteria for selecting the best gateway. However, this process is more complicated, as it involves the development and maintenance of unstable clusters in response to the rapidly changing environment in a VANET. Furthermore, the time required to build the clusters and make the CH decision is longer than the time required for information exchange.

To make this algorithm easier to understand, the authors suggested a simpler gateway selection (SGS) scheme in [15], which aimed to simplify the CMGM proposed in [24] by eliminating cluster creation within the 3G active zone. The vehicles that are located inside the UMTS service area used the UMTS-UTRAN interface to directly link to the UMTS network. When the vehicles are going out of the coverage range or are going into a dead zone, they must form a cluster and use the IEEE 802.11 interface to search for MGW and relay vehicles that are still inside the coverage region. Next, the best relays and gateway vehicles are selected to connect to the UMTS infrastructure network. Three parameters are utilized in selecting the best MGW inside the UMTS active zone, including the UMTS-RSS, route lifetime, and available route capacity metrics. Nevertheless, the SAW technique is used to weigh each potential MGW based on the above-mentioned metrics. The vehicle with a higher weight is always selected as the MGW on the infrastructure. When the SGS scheme required all vehicles to link directly to the UMTS network, however, the authors did not consider the overload issues. It ignored the conditions for delay and packet loss for the various application classes.

In [24], the authors suggested a GWS mechanism built upon an enhanced hybrid wireless mesh protocol (E-HWMP). The proposed protocol is a cluster-based protocol that uses LTE, RSS, accessible route power, and connection stability metrics to shape clusters and elect cluster heads. In the work, the elected CH is announced as the MGW responsible for relaying the traffic sent by the vehicles that are located outside of the 4G active zone and need to communicate with the infrastructure network. However, problems of cluster reliability and maintenance were not discussed, even though they are critical for improving network communication efficiency.

The authors in [23,25] proposed a fuzzy logic system for the gateway selection decision. However, [18] proposed a fuzzy multimetrics QoS-balancing gateway selection (FQGwS) algorithm. The FQGwS algorithm adopts the cluster formation techniques proposed by [24]. When the cluster is formed and the CH is elected, the MGW is selected based on the type of traffic class. Applications are grouped into three classes, voice, streaming, and data, and the MGW is selected to satisfy the QoS requirement of the given traffic class. Three parameters are used in selecting the best MGW, RSS, load, and link connectivity duration. However, this algorithm only considers non-safety applications, leaving out safety and cooperative traffic performance. Furthermore, the proposed algorithm is unable to distinguish between regular and high-quality video. Since voice traffic is often delay-aware, higher qualities require a high QoS.

Moreover, [25] proposed an efficient gateway discovery protocol based on a fuzzy system. The proposed protocol is named DRIVE (DiscoveRy of Internet gateways from Vehicles), which focuses on the discovery and selection of the best MGWs based on the vehicle QoS application requirements. DRIVE uses a proactive gateway discovery mechanism, whereby the Internet gateways geocast themselves to all vehicles within its coverage zone. Four criteria are used in MGW selection. These criteria are: (1) the number of connections to each gateway, (2) available bandwidth, (3) gateway position, and (4) market information. When this information is available, the DRIVE uses fuzzy logic to optimize the MGW selection process. However, the DRIVE protocol results in higher overhead, especially when the number of Internet gateways is high. This is due to the number of advertisement packets that are normally geocast by each gateway.

In general, it can be noted that the cluster-based MGW selection mechanisms are efficient in coordinating the vehicles and reducing intervehicle interference. The main challenge, however, is retaining cluster stability. Frequent clustering can occur as a result of poor cluster stability, lowering the overall network efficiency. This issue was addressed in [26,27,28], where the authors proposed a non-cluster-based MGW selection scheme that eradicated cluster formation for the MGW discovery and selection processes. The source vehicles either proactively or reactively discover the MGW by broadcasting gateway solicitation messages to all of its neighbors and select the best gateway candidate depending on several parameters.

In [12], the authors proposed a non-cluster adept algorithm for selecting the best gateway and base station (BS) in a cloud vehicular mesh (V-Mesh) network. To optimize the gateway and BS collection, a fitness value feature was proposed. The ingress vehicles should consult with the neighbor vehicles (NV) to see whether the gateway is available before communicating with the BS. This is accomplished by sending out a gateway advertising message to all of its neighbors. The NV then sends back a replay message with the following parameters: signal strength of neighboring vehicles, the number of packets in the NV, and the distance between the ingress vehicle and gateway candidates (i.e., the NVs). The gateway is determined by the NV with the highest fitness values. The BS selection process was also explored in this work. The best BS for the chosen MGW vehicle is determined by the number of packets in the BS’s buffer and the distance between the MGW and the BS. The best BS is selected as the one with the lowest fitness value.

The authors in [27] proposed a location-aided and prompt gateway discovery mechanism (LAPGD). The machine used a hybrid mechanism for gateway discovery. The LAPGD chose the best gateway based on velocity and intervehicle distance to accommodate a large number of vehicles in its region. Owing to the small number of open gateways, the proposed mechanism causes a significant load to be placed on the chosen gateway. Furthermore, the chosen vehicle’s ability to serve as a gateway requires further investigation.

In [26], the authors suggested a mechanism that allows vehicles to discover neighboring fixed gateways and choose the best one based on a variety of efficiency metrics. The number of hops to the gateway, gateway throughput, traffic load, and path expiration time are all considered for GWS. The gateways were permanently installed alongside the road. The gateways transmit their presence to 1-hop neighbors using the neighbor discovery protocol (NDP) [29]. As the vehicles receive the gateway advertisement message, they collect the data from it and calculate the gateway index for each gateway. The gateway with the highest gateway index is selected as the servicing gateway. However, because of the high speed of cars, using a fixed gateway, particularly in a VANET situation, increases the number of handovers.

Numerous multicriteria decision-making algorithms have been suggested in the literature to improve gateway selection decisions. In [30], the authors suggested a GWS mechanism based on the ViseKriterijumska Optimizacija I Kompromisno Resenje (VIKOR) [31] approach for vertical handover. Mobility, direction, packet cost, number of hops, RSS, location, latency, throughput, packet jitter, and packet loss rate are the parameters used to select the gateways. All of these parameters are fed into VIKOR, which calculates the VIKOR index (Q) for each alternate gateway. The gateway candidate with the lowest Q value is chosen as the best gateway. In sparse vehicular networks, this approach is said to improve the average number of vertical handovers, average latency, and throughput. This method’s computing complexity, on the other hand, has not been quantified.

The authors of [32] suggested a multicriteria mechanism for GWS, intending to increase intervehicle communications, thus reducing the number of connections to a single gateway. The GWS method is based on the preference ranking organization method for enrichment evaluation (PROMETHEE) [33]. The vehicle speed, vehicle direction, vehicle position, radio communication frequency, and number of vehicles covered by each gateway are among the five parameters used by the GWS method. Each criterion is given a separate weighting based on its significance. Each gateway candidate is assessed based on a pairwise behavior comparison for each of the listed criteria. The gateways are then rated using the PROMETHEE index, with the highest-ranking gateway being selected as the serving gateway.

The authors of [34] proposed a multimetric GWS algorithm for VANETs in fading channels. The algorithm considers the fading problem that normally exists due to the presence of buildings and other obstacles. Three criteria are used for the selection of the optimal gateway: correctly decoded probability (CDP), gateway delay time (GDT), and velocity relative to gateway (VTG). As in [15], the SAW technique was applied in [35] to evaluate each GW candidate. The GWs with a higher weight are selected as the serving gateway. However, this work only considered vehicles moving in the same direction, while movements in opposing directions were not taken into account. This results in a frequent occurrence of the handoff mechanism, which normally increases the packet drop and delay, and affects the overall performance of the vehicular network.

Table 1. Related works on gateway selection techniques with the important parameters that were used.

Authors	Technique	GWD Technique	GWS Parameters	Selection Technique	Simulator	Drawbacks
[27]	Non-Cluster	Hybrid	Velocity, inter-vehicle distance	Pairwise comparison	Customer	Huge loads are exerted on the selected gateway due to the limited number of gateways available. Willingness of the selected vehicle to act as a gateway need further investigation
[26]	Non-cluster	Proactive	Number of hops, throughput, traffic load, route expiration time	SAW	MATLAB	Fixed gateways are used, increasing the number of handovers due to the high speed of the vehicles. This leads to frequency network disconnection, which makes seamless connection difficult to achieve
[30]	Non-Cluster	Reactive	Mobility, direction cost of packet, number of hops, RSS, position, delay, throughput, packet jitter, packet loss rate, network security	VIKOR	NS2	The computation complexity of this method is not measured
[32]	Non-Cluster	Reactive	Speed, direction, position, radio transmission range, gateway load	PROMETHEE	Customer	The overloading condition of the base station before GWS is not determined
[34]	Non-cluster	Reactive	Correctly decoded probability, gateway delay time, velocity relative to gateway	SAW	MATLAB	The work only considers vehicles moving in the same direction, movements of opposing directions are not taken into account
[36]	Cluster	Hybrid	RSS, available route capacity, link stability	SAW	NS2	Cluster stability and maintenance issues are not addressed
[28]	Non-Cluster	Hybrid	RSS, number buffering packets, distance	Fitness value functions	NS2	The overloading condition of the base station before GWS is not determined
[37]	Cluster	Hybrid	RSS, buffering queue load, link connectivity duration	Fuzzy logic	NS2	This work does not differentiate between standard video and high-Quality video High quality needs high QoS
[38]	Non-cluster	Hybrid	RSS, route lifetime, available route capacity	SAW	NS2	The scheme did not take into consideration the overload issues when all vehicles were allowed to directly connect to the UMTS network
[39]	Cluster-based	Reactive	link lifetime, distance, mobility, price	Price-based selection function	Customer	High weight is given to the price factor rather than the network performance factors
[40]	Non-cluster	Hybrid	RSS, route lifetime	RSS indicator function	NS2	The research only focuses on non-safety applications, such as audio, video streaming, or gaming Safety applications are not taken into consideration
[41]	Cluster-based	Hybrid	RSS, mobility speed, link stability	SAW	NS2	The scheme shows higher complexity due to the unstable cluster formation
[22]	Cluster-based	Hybrid	Direction, RSS, IEEE802.11p wireless transmission range.	SAW	NS2	Clusters are not stable and need to be re-formulated every second
[15]	Cluster-based	Hybrid	UMTS RSS, speed, IEEE802.11p transmission range	SAW	NS2	The clustering formation proposed in this design guidelines results in huge network overhead due to the dynamic nature of this architecture
[42]	Non-cluster	Reactive	RSS, route lifetime	RSS indicator function	NS2	The research work only focuses on non-safety applications such as audio, video streaming, or gaming Safety applications are not taken into consideration
[43]	Non-Cluster	Reactive	Link lifetime	Link lifetime indicator	Customer	Bottleneck on the selected route due to the single parameter used for selecting the best route. Many potential routes left undiscovered
[44]	Non-Cluster	Proactive	Gateway load, available bandwidth, gateways position, market information	Fuzzy logic	Customer	The protocol results in higher overhead especially when the number of Internet gateways is high. This is due to the number of advertisement packets that are normally geocast by each gateway.

summarizes the related works on gateway selection techniques. The table shows the existing work in tabular form based on the important key parameters and drawbacks observed in each technique.

In the existing literature that is relevant, there is not a single scheme that takes into account the load state of the LTE infrastructure as well as the QoS of the applications before carrying out the gateway selection process. All of the proposed schemes in existing works conduct the gateway selection even when there are a small number of cars that would be sufficiently served by a single LTE-eNB. This leads to the inefficient usage of the LTE infrastructure as well as a poor QoS for the desired applications.

3. Adaptive QoS-Aware Multi-Metrics Gateway Selection Scheme

The proposed AQAGS scheme is used when the interest vehicles (IVs) located inside the LTE coverage area wish to communicate with the LTE network and no offloading media sources, such as Wi-Fi, Femtocell, or WiMAX are available to offload the LTE traffic. The primary focus is to prevent all IVs to directly communicate with the LTE-eNB due to the overload problem experienced by the LTE infrastructure network. Figure 1 shows the proposed system model used. The system model was based on HVN architecture, where VANET is integrated with an LTE infrastructure network. The LTE network is comprised of LTE base stations, called LTE-eNBs, connected to an evolved Packet Core (LTE-EPC). The LTE-EPC is responsible for communicating with the Internet. Each vehicle was assumed to be equipped with an OBU, which contains two network interfaces. One interface is dedicated to intervehicle communication in a pure ad hoc architecture using IEEE 802.11p technology. The second interface is for LTE-eNB communication. These two interfaces were assumed to be always active and can work simultaneously. This is possible due to their use of different, non-overlapping channels. We also assumed that each vehicle was equipped with a global positioning system (GPS), which allows it to decide its location and direction. The objective of this study was to select the IVs using the best method to connect to the LTE network. The IVs can define MGWs to communicate with the LTE-eNB, or they can directly connect to the LTE infrastructure network. This depends upon the residual load capacity of the LTE-eNB and the QoS requirement of the desired application.

3.1. The AQAGS Overview

Refer to Figure 2, which depicts the proposed AQAGS scheme’s design. The proposed AQAGS scheme focuses on vehicles that are within the LTE service area and can directly link to LTE networks. We categorized VANET applications into two types: delay-tolerant (DT) applications (such as FTP) and non-delay-tolerant (NDT) applications such as (VoIP). The average delay requirement values for these applications are shown in

Table 2. The QoS class identifier (QCI) for different applications.

QCI	Application Type	Carrier Type	Priority	Average Delay
1	VoIP	Guaranteed Bit Rate (GBR)	2	100 ms
6	FTP	Non-Guaranteed Bit Rate (Non-GBR)	6	300 ms

, along with the QoS class identifier (QCI). The LTE-eNB regularly broadcasts its presence and residual load capacity ($R{L}_{eNB}$) to all vehicles within their cell. When the IV needs to communicate with an LTE-eNB, it uses its LTE interface to calculate the received signal strength ($RS{S}_{IV}$) of all sensed eNBs. The IV then builds a diversity set from all detected LTE-eNBs. The IV uses Algorithm 1 to choose the LTE-eNB with the highest $R{L}_{eNB}$. The IV determines the best way to connect to the LTE infrastructure network based on the application type and $R{L}_{eNB}$. The IV either directly connects to the LTE-eNB or through a given MGW vehicle. If the communication must be handled by MGW, the IV initiates the gateway selection process and uses Algorithm 2 to find the best MGW. The chosen MGW broadcasts itself as a gateway for all its neighbors. The IV initiates packet transmission to the LTE-eNB through the chosen MGW. Simultaneously, the IV starts the gateway maintenance process by checking the amount of time left before the link lifetime (LLT) expires. When the LLT is nearing its end, the IV uses Algorithm 3 to transfer the control to another MGW if necessary. In the following sections, we discuss the specifics of the proposed AQAGS.

3.2. Interest Vehicle LTE-eNB Selection Process

As mentioned above, the LTE-eNB periodically broadcasts its presence to all vehicles inside its cell. Apart from other parameters, the broadcast message will be contained in the $R{L}_{eNB}$. The LTE-eNB computes the $R{L}_{eNB}$ depending on the amount of traffic received from the vehicles. Suppose that a single LTE-eNB can accommodate a given $N_{maxeNB}$ maximum number of vehicles for the given bandwidth of $B_{eNB}$. The LTE-eNB needs to compute the $R{L}_{eNB}$ (in Megabits per second) using Equation (1). Moreover, the IV is expected to sense several LTE-eNBs in the premises using the difference in $R{L}_{eNB}$. However, for the IV to decide which LTE-eNB to connect to, the IV needs to measure the $RS{S}_{IV}$ of each sensed LTE-eNB. For the $RS{S}_{IV}$ computation, Equations (2) and (3) are used, depending on whether the vehicle is moving towards or away from the LTE-eNB. In general, the $RS{S}_{IV}$ depends on the vehicle’s moving direction and speed. If the vehicle is moving in the direction of LTE-eNB, its ${\mathrm{RSS}}_{\mathrm{IV}}$ increases (+). Conversely, if it is moving away from the LTE-eNB, its ${\mathrm{RSS}}_{\mathrm{IV}}$ decreases (−). The increasing and decreasing amount of $RS{S}_{IV}$ relies upon the speed of the vehicle moving towards or away from the LTE-eNB [35,45].

Using Algorithm 1, the IV forms a set of LTE-eNBs in which their $RS{S}_{eNB}$ is greater than the predefined threshold $RS{S}_{th}$. For all members of the LTE-eNBs, the IV chooses the LTE-eNB with the highest $R{L}_{eNB}$. If the $R{L}_{eNB}$ of the chosen LTE-eNB is greater than the $R{L}_{eNBth}$, the IV directly sends both NDT and DT traffic to that LTE-eNB without defining an MGW. However, if the $R{L}_{eNB}$ of the chosen eNB is smaller than the $R{L}_{eNBth}$,, only the NDT applications will be transmitted directly to the LTE-eNB. This will assure that the delay requirement of this type of application is maintained. For DT applications, however, the IV will initiate the proposed multi-metrics gateway selection algorithm (Algorithm 2) to choose the best MGW for communication with the LTE-eNB.

$$R{L}_{eNB}=B_{eNB}-{\displaystyle \sum }_{v=1}^{n}A{R}_{v}P{S}_v-b_{eNB}$$

(1)

where $b_{eNB}$ is the constant value that prevents the eNB from being overloaded, and $P{S}_v$ and $A{R}_v$ are the average packet size and average packet arrival rate from the vehicle v to the eNB, respectively.

$$RS{S}_{IVt }=RS{S}_{IVt-1}\pm \delta$$

(2)

where $RS{S}_{IVt }$ and $RS{S}_{IVt-1}$ signify the estimations of the LTE-eNB receive signal strength at time t and t–1, respectively. $\delta$ represents the variety in the LTE-eNB signal strength by relating the variety in the vehicle mobility speed. $\delta$ is computed as follows.

$$\delta =\left(1+e^{-\frac{\left|v_t-v_{t-1}\right|}{\tau }}\right)$$

(3)

where $v_t$ and $v_{t-1}$ represent the speed of the vehicle at time t and t-1, respectively. The constant $\tau$ represents the rate of variation in the LTE-eNB signal strength with the moving direction of the vehicle.

Algorithm 1 IV eNB selection

1: IV activates its LTE interface to communicate with eNB’s 2: IV detects several numbers of eNBs with different load capacity and RSS 3: for each eNB$\to 1 to n$ do 4: if ($RS{S}_{eNBi}>RS{S}_{th})$ then 5: Acquire the $R{L}_{eNBi}$ 6: end if 7: end for 8: $\underset{ i\in \left[1,n\right]}{\mathrm{eNB}=\max }\left\{R{L}_{eNBi}\right\}$ 9: if $(RL\left(eNB\right)>R{L}_{eNBth}$) then 10: The IV sends NDT and DT traffics directly to the selected LTE-eNB 11: else 12: if (NDT traffics) 13: IV connects directly to LTE-eNB 14: else 15: Call algorithm 2 16: end if 17: end if

3.3. Gateway Discovery Process

In the case where the $R{L}_{eNB}$ of the selected eNB is below the threshold $R{L}_{eNBth}$ and the DT application is requested, the IV should start to initiate the gateway discovery mechanism. The IV broadcasts GWreq to all NVs within its coverage area as detailed in Equation (4) [28].

$$A_c=R_{max}.\left(1-\epsilon \right)$$

(4)

where $A_c$ is the coverage area of the IV, $R_{max}$ is the maximum transmission range of IEEE 802.11p, and $\epsilon$ represents the channel fading condition of the IV.

Apart from other standard information such as source identification (sourceID), source node directions (sourceDir), location coordinate (LOC), and speed $\left(V\right)$, the GWreq contains two other important points of information, which are the time to live (TTL) and message sequence number (seqNo). The TTL value is used to restrict the number of hops for searching for the gateway vehicle. The AQAGS scheme uses a single hop broadcast mechanism. Therefore, TTL is set to 1, meaning only a one-hop NV must receive the message. The NV checks if the seqNo of the incoming GWreq message is greater than any previously received GWreq message: if yes, the NV computes its receive signal strength ($RS{S}_{NV})$, available load capacity ($AV{C}_{NV})$, the separation distance between the IV and NV $\left(D_{IVNV}\right)$, and the link lifetime between the IV and NV $\left(LL{T}_{IVNV}\right)$, and inserts the GWrep message in the send back to the IV using the sourceID obtained from GWreq. If the seqNo of the GWreq message is less than any previously received GWreq message (preSeqNo), the NV discards that message.

Furthermore, in the event that the IV does not receive a GWrep message from the particular neighbor vehicle within a specific timeframe, the connection is considered down, and the NV is discarded. Moreover, if the IV received a GWrep message, it extracts the $RS{S}_{NV}$, $AV{C}_{NV}$, $D_{IVNV}$, and $LL{T}_{IVNV}$ parameters, which become the criteria in selecting the best NV to be the MGW.

3.3.1. Receive Signal Strength (${\mathrm{RSS}}_{\mathrm{NV}}$)

This is the RSS of the NV, measured in decibel milliwatts (dBm) with respect to its connected eNB. The computation of the $RS{S}_{NV}$ is similar to the way that the $RS{S}_{IV}$ is computed. However, in this case, the RSS is measured by the NV, not the IV. Refer to Equation (2) for the $RS{S}_{NV}$ computation.

3.3.2. Gateway Available Capacity (${ \mathrm{AVC}}_{\mathrm{NV}})$

In the gateway selection process, the selected MGW can serve several vehicles more than its actual capability. This may result in an overloading problem on the selected MGW. If this condition occurs, the traffic transmitted to the LTE-eNB via the MGW will experience higher delay, and packets will be dropped due to the congestion. Figure 3 shows the overloading scenario of the MGW. The MGW G2 is connected to many vehicles, S, compared with the G1 and G3 gateways. This might happen if the MGW is the perfect gateway for many vehicles in its coverage area. If this happens, the G2 will be overloaded, and this can affect the overall network performance. To overcome this problem, the IV also needs to check the $AV{C}_{NV}$ of each potential MGW candidate (i.e., NV) and include this as one of the metrics involved in the gateway selection process.

During the gateway discovery process, when the NV receives the GWreq message, it computes its $AV{C}_{NV}$, and inserts it in the GWrep message before its relay to the IV. The available capacity $AV{C}_{NV}$ of the v (in megabits per second) is computed using Equation (5) [46].

$$AV{C}_{NV}=C_{vmax}-{\lambda }_v-c_v$$

(5)

where $C_{vmax}$ is the maximum traffic that can be served by NV, ${\lambda }_v$ is the current traffic served by the NV (computed using Equation (6)), and $c_v$ is the constant value that prevents the gateway from being congested.

$${\lambda }_v={\displaystyle \sum }_{v=1}^{n}P{r}_{v}P{s}_v$$

(6)

where $P{r}_v$ and $P{s}_v$ denote the average packet arrival rate and the average packet size of the traffic from vehicle v to the NV, respectively.

3.3.3. Distance between the IV and NV

Another parameter used by the IV in selecting the best MGW is the distance to each NV. Using the LOC of the IV inserted in the GWreq message, the inter-separation distance $D_{IVNV}$ is computed using Equation (7). Then, the NV inserts the computed $D_{IVNV}$ into the GWrep message. Suppose the IV and NV are located at the GPS coordinator $\left({\mathrm{x}}_{\mathrm{i}},{\mathrm{y}}_{\mathrm{i}}\right)$ and $\left(j_j,y_j\right)$, respectively (refer to Figure 4). The $D_{IVNV}$ is computed as follows.

$$D_{IVNV}=\sqrt{{\left(x_i-x_j\right)}^2+{\left(y_i-y_j\right)}^2}$$

(7)

where $\left(x_i,y_i\right)$ and $\left(x_j,y_j\right)$ are GPS coordinates of the IV and NV, respectively.

3.3.4. Link Lifetime ($LL{T}_{IVNV}$)

One of the challenges in designing the VANET is the frequent breaking of links due to rapid changes in vehicle position [44]. The link lifetime criterion reflects the stability of the link and the duration in which the link can be sustained without breaking. When the IV sends the GWreq, it inserts its position, location, speed, and moving direction. When the NV receives the GWreq message, it extracts all information needed to compute the $LL{T}_{IVNV}$. The current research’s LLT computation was inspired by [47]. Referring to Figure 5, the $LL{T}_{IVNV}$ is calculated using Equation (8). The NV inserts the $LL{T}_{IVNV}$ value into the GWrep message and sends back to the IV.

$$LL{T}_{IVNV}=\frac{\sqrt{\left(k^2+l^2\right)R^2+{\left(mk-nl\right)}^2}-\left(kn+ml\right)}{k^2+l^2}$$

(8)

where R is the communication range of the IEEE 802.11p radio, $k=v_i\cos {\theta }_i-v_j\cos {\theta }_j$, $l=v_i\sin {\theta }_i-v_j\sin {\theta }_j,$ $n=x_i-x_j$, $m=y_i-y_j. \left(x_i,y_i\right)$, and $\left(x_i,y_j\right)$ are the Cartesian coordinates of the IV and NV, respectively, and the incline of ${\theta }_i \mathrm{and} {\theta }_j$ $(0<{\theta }_{i, }{\theta }_j<2\pi )$ respectively, concerning the $x$-axis. $v_i \mathrm{and} v_j$ are the speeds of the IV and NV respectively.

3.4. Simple Adaptive Weight (SAW) Technique

In the literature, several multicriteria decision-making algorithms have been proposed. However, most of the proposed techniques suffer from computational complexity when being applied. In this study, the SAW technique is adopted, which was found to be simple to use and more efficient in making decisions that involved multicriteria parameters [40,41]. When the IV receives the GWrep, it uses the SAW technique to rank each potential MGW and choose the best MGW based on the mentioned criteria. The SAW technique involves two stages. The first stage is the scaling stage, whereby each metric needs to be scaled into non-dimensional values. The second stage is the weighting stage; here, every scaled metric is given its weight or priority in deciding the best MGW.

3.4.1. Scaling Stage

Every involved metric has its value and unit. To harmonize all metrics, each metric needs to be scaled into non-dimensional values. The involved metrics can either possess negative or positive criteria depending on the nature of the metrics themselves. In this case, the $RS{S}_{NV}$, $AV{C}_{NV}$ and $LL{T}_{IVNV}$ are metrics with positive criteria. The higher the values of these metrics, the better they optimize the gateway selection decision. However, in the case of the $D_{IVNV}$, the increase in its value affects the optimality of the gateway decision, therefore this metric is categorized as a metric of negative criterion. In any case, the best score of any criterion ranges from zero to one, where one indicates the best value and zero indicates the worst value (see

Table 3. Categories of parameters according to its criterion.

Parameter	Type of Criterion	Possible Values
$RS{S}_{NV}$	Positive	0–1
$AV{C}_{NV}$	Positive	0–1
$LL{T}_{IVNV}$	Positive	0–1
$D_{IVNV}$	Negative	0–1

). Equations (9) and (10) were used to calculate the scaled metric value of the positive and negative criteria metrics.

$$X_i=\frac{P_i-P_{min}}{P_{max}-P_{min}}$$

(9)

$$X_i=\frac{P_{max}-P_i}{P_{max}-P_{min}}$$

(10)

where $X_{i }$ is the scaled metric value of the metric, $P_{max}$ is the maximum value of the metric, $P_{min}$ is the minimum value of the metric, and $P_i$ is the value of the metric.

3.4.2. Weighting Factor

Once each metric has been normalized to a comparable scale, the user’s weighting factor must be specified to determine the priority of each metric’s importance. The IV uses Equation (11) to calculate the weight of each NV and then ranks each NV according to its computed weight. The MGW is selected as the NV with the highest weight.

$$W_i={{\displaystyle \sum }}_{i=1}^4\left(P_{i }\left[F\right]\ast X_i\right)$$

(11)

where F is the IV’s priority factor, and one of the higher weights is chosen as the gateway. Every metric in this study is given the same priority factor as given in [15,22].

3.5. Multi-Metric Gateway Selection Process

When the IV wants to communicate with the LTE-eNB and finds that the $R{L}_{eNB}$ of the selected eNB is below the threshold and DT application packets needed to transmit to the LTE-eNB, the IV starts the gateway discovery process by sending a GWreq message within its IEEE 802.11p coverage zone. For each NV, it first should check the receive signal strength ${\mathrm{RSS}}_{\mathrm{NV}}$ from the LTE-eNB before replaying the packets. If the $RS{S}_{NV}$ of the NV is greater than the threshold $RS{S}_{th}$, the NV will find itself as one of the potential MGW candidates for its neighboring vehicles. The NV replies with a GWrep message, which includes up-to-the-minute information regarding the $RS{S}_{NV}$, $AV{C}_{NV}$, $D_{IVNV}$ and $LL{T}_{IVNV}$. However, if the $RS{S}_{NV}$ of the NV is less than the threshold $RS{S}_{th}$ the NV drops the message. The IV ignores any duplication of the GWreq packet that comes from the same source. The IV will receive several GWrep packets from different NVs which reside inside the IV IEEE 802.11p coverage zone. Upon receiving the GWrep, the IV applies Algorithm 2, which is based on the SAW technique to select the best MGW. The IV computes the scale metric of each received metric. Each metric is assigned the same priority factor (F) (i.e., ¼ priority level for each metric). The IV uses the F value and metric scale value to compute the weight of each NV. The NV with the highest weight is selected as the best MGW. Finally, the IV starts to transmit the packets through the selected MGW.

3.6. Gateway Advertisement Process

After the MGW is selected, the MGW starts to broadcast itself as the gateway using a gateway advertisement (GWadv) message within its IEEE 802.11p coverage zone. The GWadv is broadcast using the TTL value set to one. Other vehicles that need to send the DT packets need to check the existing MGW before initiating the gateway selection process (refer to Algorithm 3). If the MGW is found, the IV sends the packets to the existing MGW. If the MWG is not found, the IV needs to reinitiate the gateway discovery and selection process (Algorithm 2).

Algorithm 2 Multimetrics gateway selection algorithm

1: The IV search for the NV in its IEEE 802.11p coverage area by sending GWreq message 2: for each NV←1 to r do 3: if $(RS{S}_{NV}$ > $RS{S}_{th})$ then 4: NV sends GWrep with four metrics $RS{S}_{NV}$,$AV{C}_{NV}$, $D_{IVNV}$ and $LL{T}_{IVNV}$ 5: Ignore the duplication message from the same source 6: else 7: Drop the message 8: end if 9: end for 10: IV receive GWrep 11: IV compute the scale metric Xi 12: for each metric $P_i$ of the NV where $1<i<4$ do 13: if$P_i\left[CRETERION\right] is POSITIVE$then 14: $X_i=\frac{P_i-P_{min}}{P_{max}-P_{min}}$ 15: else 16: if$P_i\left[CRETERION\right] is NEGATIVE$then 17: $X_i=\frac{P_{max}-P_i}{P_{max}-P_{min}}$ 18: end if 19: The IV computes the weight of each NV using $W_i={\displaystyle \sum }_{i=1}^4\left(P_i\left[F\right]\ast X_i\right)$ 20: end for 21: IV selects the GW with the maximum weight 22: The request from the IV is transmitted to the GW

3.7. Gateway Maintenance Process

The IV sets the timer and begins the transmission after deciding on the gateway. The connection maintenance process is managed by the periodic channel quality indicator (CQI) reports, which show the current contact channel quality if there is no gateway between the IV and the infrastructure. If a gateway is chosen, however, the transmitting period will be calculated using Equation (12). Afterward, if there are more packets to be transmitted, the IV will check the existing gateway (using Algorithm 3), if any. Otherwise, it reiterates the process of electing the appropriate gateway for the remaining packets (Algorithm 2).

$$Timer=LL{T}_{MGW}-\gamma$$

(12)

where $LL{T}_{MGW}$ is dependent on the gateway selected and $\gamma$ is the back value to avoid network disconnection before the handoff procedure occurs.

Algorithm 3 Existing gateway selection

1: The new IV checks for the existing gateway in the coverage area 2: if MGW is FOUND &&$LL{T}_{MGM}$ is not expired then 3: The new IV will transmit the request to the existing gateway 4: else 5: Call Algorithm 2 6: end if

4. Simulation Experiment Settings

The simulation findings of the proposed AQAGS scheme are presented in this section to verify its validity. We compare the proposed AQAGS with the CMGM scheme [22] and Adroit scheme [28]. The CMGM scheme is based on cluster formation and CH election before the gateway has been selected. Conversely, the Adroit scheme is a non-cluster-based scheme where the source vehicle communicates to and directs the surrounding vehicles to look for a vehicle that could serve as a gateway for accessing the infrastructure.

The simulation was carried out using the SUMO mobility simulator [42] and NS2 [43] network simulator. The SUMO simulator was used to generate the vehicular mobility model, whereas the NS2 simulator was used to measure the network performance. The trace file generated by the SUMO analysis was used as an input file for the NS2 simulation to define the node’s position and movement. In the evaluation phase, NSMIRICLE [44] was patched with NS2 to accommodate several interfaces in a wireless node. Moreover, the IEEE 802.11p package was implemented to enable V2V communication [45] while the LTE module [46] enabled LTE infrastructure communications.

The simulation scenarios focused on the highway model, where two streams of vehicles move in opposite directions. For each direction, the road is divided into two lanes, and the vehicles are set to change the lane frequently to emulate the real mobility of vehicles on a highway road. We assume that each vehicle knows its position and velocity. Two types of applications are used, DT and NDT. For DT, an FTP application was used in which a packet of 1000 bytes was sent every 0.03s. The data rate for the FTP was assumed to be 0.3 Mbps. For NDT applications such as VoIP, 160 bytes packets were sent every 0.02s, and the data rate was set to 0.064 Mbps. We assumed 20% of the vehicles to act as IVs in each of the simulation settings. Of this 20%, 10% of the vehicles used VoIP applications and another 10% used FTP. On the other hand, the infrastructure comprised several LTE-eNBs located at the border of the highway. The vehicles directly connected to an LTE-eNB were expected to receive a higher RSS.

We also assumed that all vehicles are located inside the LTE-eNBs’ coverage zone. Four scenarios were tested and for each scenario, the packet delivery ratio (PDR) (Equation (13)), throughput (Equation (14)), delay (Equation (15)), and control packet overhead (CPO) (Equation (16)) were measured and compared with the selected mechanisms. The reset of the important parameter settings for VANET and LTE modules are shown in

Table 4. VANET Parameters.

Parameter	Possible Values
Type of road	Highway
No. of lanes	2
Maximum speed	20–160 km/h
No. of vehicles	50–500
Physical/MAC protocols	IEEE 802.11p
$\mathrm{Transmission} \mathrm{range} T{R}_{max}$	300 m
802.11p data rate	11 Mbps
Interface queue type	Drop Tail/PriQueue
Interface queue length	50 Packets
Gateway broadcast timer	1 s
Antenna type	Antenna/OmniAntenna
Application type	FTP, VoIP
FTP packet size	1000 bytes
VoIP packet size	160 bytes
The data rate of FTP	0.3 Mbps
The data rate of VoIP	0.064 Mbps
$\mathrm{Residual} \mathrm{load} (R{L}_{eNBth})$	80%
TTL	1 s
Simulation period	500 s
Stop time	to 3 s

and

Table 5. LTE Parameters.

Parameter	Possible Values
Physical layer protocol	LTE
Carrier frequency	2 GH
eNB trans power	42 dBm
Queue/LTEQueue QoS	True
Source/GWC- eNB link (Data rate)	10 Mbps
Source/GWC- eNB link (LTEQueue type)	ULAirQueue
eNB-Serving GW link (Data rate)	1000 Mbps
eNB-Serving GW link (LTEQueue type)	ULSIQueue
Number of eNBs	4
System loss	1 dB
LTE RSS threshold	−94 dBm
Node B interface queue length	50 packets
Transmitter/Receiver antenna height (ht/hr)	1.5/20 m
Transmitter/Receiver gain (Gt/Gr)	1 dB/1 dB

, respectively.

4.1. Packet Delivery Ratio (PDR)

The PDR is the ratio of total packets received to the total packets transmitted between the source and destination. This metric indicates the efficiency of the scheme in transferring the packets between the source and destination. A higher PDR value indicates that the scheme is more reliable, in that more packets are successfully transmitted and received. The PDR can be computed by using Equation (13) [22].

$$PDR \left(\%\right)=\frac{ {{\displaystyle \sum }}_{i=1}^n{R}_i }{{{\displaystyle \sum }}_{i=1}^n{S}_i}\times 100$$

(13)

where R denotes the received packets and S denotes the packets sent.

4.2. Throughput

The cumulative number of packets received by the recipient divided by the time between the first and last packet received is known as throughput. The throughput is measured in bytes per second (bps). However, to work with kilo bytes per second (kbps), a factor of 8/1000 must be multiplied by the standard figure. The formula to calculate throughput was adopted from [15] and is shown in Equation (14).

$$Throuput \left(kbps\right)=\left[\frac{{{\displaystyle \sum }}_{i=1}^n{R}_i}{F{P}_t-L{P}_t}\right]\times \left(\frac{8}{1000}\right)$$

(14)

where R is the packet received and $(F{P}_t-L{P}_t)$ is the duration elapsed from the first to the last packet received.

4.3. Average Delay

The average delay refers to the amount of mean time it takes for a packet to go from a point source to a destination. In general, this delay is caused by several factors, such as propagation delay of the packet, retransmission delay on MAC layer in the route discovery process, clustering, re-clustering, and cluster head election process. All of these factors play a major role in elevating the delays. However, a lower value of this metric indicates a higher performance of the scheme in terms of the gateway discovery and selection processes. Equation (15) shows the delay metric computation [47].

$$Delay=t_r-t_s$$

(15)

where $t_r$ is the time at which the response is received by the IV and $t_s$ is the time at which the request is transmitted by the IV.

4.4. Control Packet Overhead (CPO)

The CPO is the ratio of total control packets generated (CP_gen) to total packets generated (TP_gen) in an aggregation network [22]. The CPO calculation is seen in Equation (16).

$$CPO=\frac{{{\displaystyle \sum }}_{i=1}^{n}C{P}_{gen}}{{{\displaystyle \sum }}_{i=1}^{n}T{P}_{gen}}$$

(16)

5. Results and Discussions

5.1. Evaluation of Fixed Vehicle Applications versus Number of Vehicles

In this scenario, we measured the impact of the application type on the execution of the AQAGS, CMGM, and Adroit schemes. Our objective was to investigate how these three algorithms behaved on maintaining the QoS of vehicle applications (i.e., VoIP and FTP) in both sparse and dense scenarios. The number of vehicles ranged from 50 to 500, at 50 vehicle intervals. VoIP or FTP traffic were generated by 20% of the vehicles. The vehicles’ high speed was limited to 60 km/h, and the IEEE 802.11p wireless communication range was limited to 300 m.

Figure 6a demonstrates that the PDR decreased as the number of vehicles rose. Both the tested applications and strategies exhibited this trend. In contrast to the CMGM and Adroit algorithms, the PDR for AQAGS with VoIP applications was slightly lower. When there were only 50 vehicles, the PDR for AQAGS with VoIP was 99.83%, which was 21.6% and 16.29% higher than in VoIP applications with CMGM and Adroit, respectively. Only the first 250 vehicles appear to have had a reliable PDR in the VoIP application. The PDR dropped by 1.33% as the number of vehicles exceeded 250. Congestion on the LTE side is what caused this drop. In contrast, the PDR for CMGM and Adroit using VoIP noticeably decreased during peak hours: from 78.23% to 55.01% for CMGM, and from 83.54% to 69.32% for Adroit, respectively. Comparing the VoIP applications with CMGM and Adroit, respectively, AQAGS’s PDR was generally 29.81% and 23.64% higher. These findings demonstrate that the AQAGS scheme kept the VoIP application’s QoS for several mobile vehicles. This is due to AQAGS giving VoIP connections a higher priority to the LTE infrastructure. When this traffic is active, no MGW needs to be defined. This reduces the packet drops, which typically happens when the packets are transferred through the MGW.

In contrast, the AQAGS scheme exhibited a PDR value that is comparable to that of the VoIP application when FTP was used in a sparse scenario. This is because all of the IVs have the option to link directly to the LTE infrastructure network at lower vehicle densities without specifying an MGW. However, as the number of vehicles increases, MGWs are required for FTP applications to connect to an LTE-eNB. As the number of vehicles reached 500, the PDR of the FTP application decreased to 83.07%, which was 16.76% lower than when the number of vehicles was 50. The suggested AQAGS scheme only chooses a mobile gateway when the FTP application is running and when the usable load capacity of the LTE network exceeds a predetermined threshold. All packets must pass through the MGW, which must be established at this location. For the CMGM and Adroit schemes, this is not the case. When the number of vehicles increased, CMGM exhibited a higher packet loss. When the number of vehicles was increased from 50 to 500, the PDRs of CMGM and Adroit decreased from 82.21% to 53.23% and 90.34% to 70.32%, respectively. This astounding drop occurred due to the constant requirement of both mechanisms to define the MGW for IV traffic transmission. Additionally, the CMGM scheme organizes the vehicles in these extremely dynamic environments using clusters, which frequently results in cluster reformation. As a result, the packet loss increases, and the PDR is impacted. As a result, the PDR reported by CMGM is 7.43% lower than Adroit’s. Overall, the results demonstrate that even though the MGW must be established in the cases of larger vehicle numbers to reduce congestion in the LTE infrastructure, the PDR reported by AQAGS was above 80%, which was higher than that of CMGM and Adroit by 29.84% and 12.75%, respectively, with respect to FTP.

The throughput for two of the evaluated applications is shown in Figure 6b. The graph indicates that as the number of vehicles rose, so did the network’s overall throughput. The throughput reported for the AQAGS scheme with VoIP traffic in the sparse area (i.e., 50 vehicles) was 60.86 kbps, but when the number of vehicles was increased to 500, the throughput increased to 187.18 kbps. Compared with the CMGM and Adroit schemes, this increase is higher than the two by 28.9% and 23.73%, respectively. This is because, in the case of VoIP, the communication between the vehicles and LTE-eNBs is simple and seamless, ensuring that the packets arrive at the infrastructure safely. In addition, using a direct connection to the LTE network results in less packet loss. All network throughput requirements are met by the LTE network. As more vehicles with lower packet loss rates increase throughput, the conclusion becomes apparent. Additionally, when a VoIP application is used in CMGM compared with Adroit, CMGM exhibited the lowest throughput value. When compared with Adroit, CMGM’s throughput on average was 9.83% lower. However, as the number of vehicles rose, the throughput of CMGM and Adroit correspondingly rose. This is because more vehicles increase the likelihood that a broken link will be repaired, improving the network throughput.

However, despite the small number of vehicles, the AQAGS FTP traffic showed a lower throughput of 150.32 kbps, which was 60 kbps and 20 kbps slower than the CMGM and Adroit algorithms. When the number of vehicles rose, the throughput for all three schemes increased. However, AQAGS with FTP reported 429.32 kbps at the interval of 500 vehicles. In comparison to the cluster-based CMGM scheme and the non-cluster-based Adroit scheme, this value was 100 kbps and 29 kbps higher, respectively. This is explained by the fact that more potential MGWs are needed as the number of vehicles increases to support the IV in a streamlined fusion. CMGM, on the other hand, requires the formation of clusters before the MGW is chosen; the VANET’s overall throughput is impacted by this. Adroit had a throughput of 130.32 kbps in the sparse network, which was 40 kbps more than recorded for CMGM. Since there are fewer vehicles, the interconnection time between them is shorter, which frequently leads to link failure, many packets being dropped, and a reduction in the overall network throughput. Furthermore, even though CMGM’s throughput increased to 319.32 kbps at 500 vehicles, it was still 81 kbps slower than Adroit’s number at the same interval.

Figure 7a illustrates how the delay constraints between the measured applications were met. VoIP applications need a delay of no more than 100 ms, according to Table 1. The figure depicts that the AQAGS scheme maintained the VoIP applications’ required delay in both sparse and dense scenarios. In both instances, the average delay observed was less than 0.1 s (100 ms), which is the average delay cost designated for VoIP applications. For the CMGM and Adroit schemes, this was not the case. The delay requirements of VoIP applications were never satisfied by either of these schemes in a variety of tested vehicle numbers. When the vehicle number increased from 50 to 500, the CMGM average delay rose from 0.14 s to 0.63 s. With respect to VoIP application, this increase was 4.75% higher than in the Adroit scheme. This is reasonable, given that the CMGM cluster density rises with the number of vehicles. The overloading condition in the chosen MGW occurs as a result. In the MGW buffer, an overload causes a longer queue delay, which in turn raises the average packet delay.

Additionally, the figure for the FTP application demonstrates that during peak hours, the delay of AQAGS in the FTP application increased to 0.53 s (i.e., 500 vehicles). This delay exceeded the average delays demonstrated by CMGM and Adroit, respectively, by 26% and 14%. Only when there were fewer than 250 vehicles and a total delay of less than 300 ms does AQAGS provide FTP QoS. However, as the number of vehicles increased, the delay increased as well, making it harder to maintain the required QoS. The AQAGS scheme determined how to deliver the FTP packets to the infrastructure network as a result of detecting an overloading condition on the LTE side. The gateway discovery process must be started by the IV when a condition of overloading arises, and the appropriate MGW for data transmission must be selected. The time it took to find vehicles increased as the number of vehicles increased. This procedure took some time, which increased the FTP delay.

However, we evaluated the CPO encounter when FTP and VoIP were in use. In general, as shown in Figure 7b, the CPO rose as the number of vehicles did for the three tested schemes. However, the CPO for AQAGS in the VoIP application increased from 4.92% to 12.97% as the vehicle count rose from 50 to 500. With VoIP, there are not too many control packets sent between the vehicles as an MGW is not required for this application. Fewer control packets are required to measure the CQI for the attached LTE-eNB. Compared with the CMGM and Adroit schemes with respect to VoIP, AQAGS’s CPO was lower by 19.95% and 16.21%, respectively. The highest CPO was expressed by CMGM, followed by Adroit, in the same variation of vehicle numbers. In contrast to Adroit, CMGM reported a 6.55% higher CPO when VoIP traffic was involved. This is because, for the cluster formation process of MGW selection, the CMGM algorithm involves the transmission of a significant number of control packets.

In addition, when using FTP, our proposed AQAGS scheme showed the lowest CPO when compared with the other tested schemes. When compared with CMGM and Adroit in the FTP application, AQAGS’s CPO measurement was 2.11% and 5.33% lower, respectively, for fewer vehicles. When the number of vehicles reached 500, the CPO observed was lower than that of CMGM and Adroit in FTP by 8.64% and 2.02%, respectively. Because all three mechanisms require FTP to pass through the MGW vehicle before transmitting to the LTE network, the CPO increases with the rise in vehicle numbers. During the process of determining the MGW, the IV and NV exchange numerous control packets. This process must be repeated whenever the IV and MGW’s communication link fails. The CPO value for the FTP traffic increases as a result of the entire process.

5.2. Evaluation of Mixed Vehicle Applications versus Number of Vehicles

The proposed AQAGS scheme’s performance was assessed and benchmarked in this scenario with CMGM [22] and Adroit [28]. MT was used for each tested scheme. The number of vehicles varied from 50 to 500 and the speed of the vehicles was kept to 60 km/h.

Figure 8a demonstrates that as the number of vehicles rose, the PDR for all three algorithms fell. However, the PDR of AQAGS at non-peak hours was 99.45%, which was higher than that of CMGM and Adroit algorithms by 23.45% and 3.45%, respectively. However, during peak hours, i.e., when there were 500 vehicles on the road, the AQGS scheme also performed better than its rival algorithms by 45.01 and 16.01%, respectively. In the execution of the gateway discovery and selection processes, neither of the other benchmarked algorithms took the density of vehicles into account. As a result, even though there were few vehicles, the CMGM and Adroit schemes chose to use the MGW as a relay to the infrastructure, which increased packet loss and had an impact on the PDR. The percentage of the PDR expressed by the CMGM and Adroit algorithms during non-peak hours (i.e., 50 vehicles), which were 76.12% and 96.23%, respectively, serve as evidence of this phenomenon. For the AQAGS scheme, the MGW selection only happens during times of high vehicle traffic (peak hours) and when delay-tolerant software is being used. As a result, the PDR increases because the vehicles have a direct, seamless connection to the LTE network, which lowers packet loss and increases the PDR. When there are more than 500 vehicles, AQAGS, CMGM, and Adroit report 95.01%, 50.22%, and 79.23% PDRs, respectively. The AQAGS scheme performed better than CMGM and Adroit overall by 33.01% and 9.6%, respectively.

Figure 8b shows an evaluation of the three implemented algorithms’ throughputs with the varying vehicle counts. The findings show that the throughput increased as the number of vehicles rose. This is because there are more potential gateways that can serve the IV as the number of vehicles rises. Additionally, as the number of vehicles rises, it becomes simpler to repair the IV and MGW’s broken links, improving the overall throughput. The AQAGS scheme outperforms CMGM and Adroit in terms of throughput by 27.8% and 19.32%, respectively. This is a result of AQAGS’s noteworthy performance in both sparse and dense areas, where the decision to execute the gateway discovery and selection depends on the vehicle density. All three mechanisms had similar throughput for a small number of vehicles, but the AQAGS algorithm had a throughput of 36.28 kbps and increased to 349.16 kbps when there were 500 vehicles. When compared with the CMGM scheme, the Adroit scheme shows a throughput improvement of 10.52%. The CMGM scheme performed less well than the other two algorithms as it groups the vehicles into clusters. When there are few clusters with insufficiently accessible MGWs, there is a chance that the chosen MGW will be overloaded with IV packets, some of which will be discarded and ultimately impact the throughput value. The CMGM algorithm reported 30.12 kbps and 298.25 kbps for the low and high vehicle numbers, respectively.

In addition, we examined how much more delayed the AQAGS scheme was on average compared with the CMGM and Adroit schemes. Figure 9a demonstrates how the AQAGS scheme provided the QoS requirement for VoIP and FTP applications for a wide range of vehicle numbers between 50 and 400. According to [48], the required delay for both VoIP and FTP applications is less than 0.1 s (i.e., 100 ms), and this range’s average reported delay falls under that threshold. Only the FTP application delay requirement, which must be under 0.3 s, is guaranteed for fleets of more than 400 vehicles (300 ms). Regardless, as the number of vehicles rose, the average delay did as well. When compared with the CMGM and Adroit schemes, the AQAGS scheme was able to maintain the QoS for both low-density and high-density traffic. Comparing AQAGS’s average delay with CMGM’s and Adroit’s, the difference was 78.53 and 40.12%, respectively. As a result, cluster formation, which involves the CH election process, is eliminated by the AQAGS. As opposed to the CMGM method, which necessitates the clustering of the vehicles and CH election before the gateway discovery process, our proposed method requires no such prerequisites. Additionally, the Adroit scheme does not take cluster formation into account and does not include application QoS in its solution. Regardless of the number of vehicles, the IV must always choose the MGW. The burden on the IV also rises as a result, which has an impact on the QoS of the applications. The maximum delays observed by CMGM and Adroit were 0.93 and 0.56 s, respectively, and are greater than the minimum delays required by VoIP and FTP, respectively.

Figure 9b compares the CMGM and Adroit mechanisms to the CPO measured for the AQAGS method. The overall patterns indicate that whenever the number of vehicles increased, CPO increased as well. In contrast to CMGM and Adroit, AQAGS exhibited a lower CPO. The CPO for AQAGS was lower than those of CMGM and Adroit by 17.8% and 8.5%, respectively. This is because, in contrast to the CMGM scheme, the AQAGS scheme only searches for an MGW when necessary and only within the IV coverage zone. This manages how the network is flooded, which greatly enhances the CPO value. Similar to how the CPO exhibited by CMGM was 15.1% in the sparse network, it was also twice as high as the CPO exhibited by AQAGS. However, when there were 500 vehicles, CMGM’s CPO increased to 43.34%, which was 23.23% higher than the CPO reported by AQAGS at the same number of vehicles. As the number of vehicles increased from 50 and 500, Adroit reported a change in CPO from 10.24% to 38.33%, respectively. This represents a difference of 2.47% and 18.23% with respect to the values obtained for AQAGS at the same intervals of vehicle numbers. This is because the Adroit scheme always runs the MGW discovery and selection process without taking into account the LTE-available eNB’s load capacity. Regardless, non-cluster-based strategies such as AQAGS and Adroit yield lower CPO than cluster-based strategies (i.e., CMGM).

5.3. Evaluation of Mixed Vehicle Applications versus Vehicle Speed

In this section, we evaluate how the vehicle speed affected the effectiveness of the mechanisms in the proposed AQAGS scheme and the equivalent mechanisms. The speed of the vehicles was changed from 20 to 160 km/h with an increasing interval of 20 km/h, and the number of vehicles was kept at 100. Mixed traffic (MT) of VoIP and FTP applications were used. Figure 10a illustrates how the PDR value is generally impacted by changes in vehicle speed. The PDR tended to decrease as the vehicle speed rose. All three of the schemes follow the same pattern. The AQAGS scheme, however, performed 18.33% and 18.73% better than CMGM and Adroit, respectively. The AQAGS method reported a 98.9% PDR for a lower vehicle speed of 20 km/h, which was 18.36% and 23.57% higher than CMGM and Adroit, respectively. The PDR for the AQAGS scheme dropped to 85.58% when the speed of the vehicles increased to 160 km/h, but it was still 15.13% and 19.24% higher than that of the CMGM and Adroit methods, respectively. The LLT between the IV and MGW was predicted by AQAGS, which accounts for this performance. The relative velocities of the vehicles are taken into account by the LLT, which provides an estimate of how long the vehicles can remain connected. The IV keeps track of LLT parameters as the vehicle’s speed rises and knows exactly where to start the search for a new MGW before the link breaks. In the cluster-based CMGM scheme, the speed of the cluster members affects how stable the clusters are. The clusters become unstable and require frequent re-formulation as the vehicle speeds rise, which can result in higher packet drops that have an impact on the PDR value. The PDR value reported by the CMGM scheme was still 5% higher than the Adroit scheme’s value. At lower and higher vehicle speeds, the PDR reported by Adroit was 75.54% and 66.35%, respectively. In Adroit, the best MGW is determined without consideration of the LLT. In other words, the IV can select the MGW with the shortest connection time, which causes frequent link breaks that impact the PDR.

Figure 10b displays how changes in vehicle speed affect the VANET network’s overall throughput. For all three of the tested schemes, changing the vehicle speed had a serious effect on throughput. The throughput decreased with increasing vehicle speeds. However, for both low-speed and high-speed vehicles, the proposed AQAGS scheme outperformed CMGM and Adroit in terms of throughput. When compared with the CMGM and Adroit schemes, the throughput revealed by AQAGS was 7.52% and 6.83% higher, respectively. This is so that the best MGW can be chosen, which is influenced by the vehicle speed in AQAGS. This aids the IV in deciding which MGW it can trust to maintain a stable connection with for a while. Additionally, depending on the application, some IVs never require an MGW connection to connect to the LTE network; instead, they can directly send packets to the infrastructure. However, when the vehicle’s speed increased from 20 km/h to 160 km/h, the throughput of the proposed AQAGS scheme decreased by 1.46%. This decline was marginally greater than the throughput declines demonstrated by CMGM and Adroit, which were 0.83% and 1.36%, respectively. When examined further, we noticed that the CMGM scheme reported a lower throughput than the AQAGS scheme. The reason the CMGM method was able to maintain the throughput drop was that they arranged the vehicles in clusters, which improved the management of the links and helped ensure that the data packets arrived at their destination safely. Furthermore, Adroit performed worse than the competition in terms of throughput, which can be explained by the fact that Adroit never considers the connection time, which typically influences vehicle speed when selecting the best MGW.

In Figure 11a, we measure the average delay against the vehicle’s speed. When the vehicle was moving at a speed of under 80 km/h, the proposed AQAGS scheme could maintain the QoS requirement for both applications. However, only the FTP application delay requirement, which is below 0.3 s, was maintained when the speed was increased to 120 km/h (i.e., 300 ms). The AQAGS delay rose to 0.45 s when the vehicle speeds reached 160 km/h. In comparison to the CMGM and Adroit scheme, the AQAGS method exhibited a lower average delay of roughly 13.52% and 32.93%. Additionally, AQAGS’s delay for slower-moving vehicles was very small, recorded at 0.00234 s (or 2.3 ms). When compared with the delay reported by the CMGM and Adroit schemes, this delay was lower by 7.52% and 20.14%, respectively. This is because low-speed vehicles experience shorter search times for new MGWs than high-speed ones because of the longer link lifetimes between the IV and MGW. In high-speed vehicles, links frequently break and require repair by finding the new or existing MGW, which lengthens the packet delay. When the vehicle’s speed was increased, the Adroit scheme exhibited the worst average delay. The delay increased from 0.05 s to 0.6 s, which was 17.12% longer than in CMGM. Because the best MGW is not chosen based on vehicle speed, the delay in the Adroit method rapidly increases. To transmit the final data packets, it is necessary to frequently search for a new MGW. The application’s QoS is affected by this process, which increases the average delay.

Figure 11b illustrates the impact of the changing vehicle speed on the CPO. The CPO of cluster-based schemes, such as CMGM, was higher than that of non-cluster-based schemes. In comparison to AQAGS and Adroit, CMGM’s CPO was higher by 9.61% and 5.0%, respectively. These findings show that cluster deformation is required when the vehicle speed increases frequently, and the CPO value rises due to the necessity of circulating a large number of control packets through the VANET. No cluster is required for a non-cluster-based scheme, so no control packets need to be injected into the network to initiate cluster formation and CH election. However, the MGW discovery phase is when the non-cluster-based schemes produce the majority of their control packets. However, this was prevented by AQAGS, which only required the GWreq message to be transmitted when the TTL was set to one. There are no broadcast storms in the AQAGS scheme. However, as the vehicle’s speed rises, the LLT between the IV and MGW becomes shorter. As a result, the MGW is frequently reselected, which raises the CPO. In comparison to CMGM and Adroit, the AQAGS generally displayed a lower CPO by 9.62% and 4.63%, respectively.

6. Conclusions and Future Work

In this paper, we introduced a non-cluster-based adaptive gateway selection scheme that manages the QoS for a variety of vehicular applications. The suggested AQAGS scheme focuses on maintaining the QoS of vehicle applications. Furthermore, the AQAGS ensures that the LTE network is fully used in delivering high-quality services to VANET users. The proposed scheme utilizes several metrics in the gateway section process, and the SAW technique was adopted to optimize the selection process. Moreover, the AQAGS scheme was validated using simulation and benchmarked with cluster-based (i.e., CMGM) and non-cluster-based schemes (i.e., Adroit). FTP and VoIP applications were utilized for evaluation purposes.

In several number-checked scenarios, the AQAGS scheme retained the delay requirement values for both FTP and VoIP. However, the results show that when the number of vehicles increases, the QoS becomes difficult to maintain due to the congestion that is normally experienced on the LTE side. This enforces the AQAGS method to route the delay-tolerant application FTP to the MGW, which slightly increases the delay and packet loss. Moreover, the results highlight that the AQAGS algorithm reduces the overhead that is normally experienced with a cluster-based scheme such as CMGM by eradicating the formation of clusters in the highly dynamic environment of VANETS.

The AQAGS scheme improves the link failure that is normally experienced in a non-cluster-based scheme such as Adroit by considering the link lifetime prediction that can give prior information on when the link might be broken. This saves the packet delay and increases the throughput and packet delivery ratio. Overall, the AQAGS method shows a better maintenance of the QoS compared with the benchmarked schemes.

The main limitation of the current research is that the investigation of the proposed scheme’s performance has been done by using a network simulation. The results from the network simulation cannot be guaranteed to be the same as in real-world scenarios. Moreover, the suggested parameters in this study are not considered the obstacles and the noise signaling that may be potentially present in real-world scenarios. Aside from these points, the behavior of the driver on the road was not taken into the consideration in the current study in the case of the proposed AQAGS scheme. Driver behavior is considered a crucial parameter in VANETs that influences much of the stability of the gateway selected.

Therefore, we recommend that future works investigate the AQAGS scheme in a real-world scenario by considering the driver behavior parameter beside the issues related to traffic obstacles and noise signaling that occurs in a real-world scenario. In addition, we aim to investigate the performance of the AQAGS method in a large-scale network to validate its efficiency in maintaining the QoS in large vehicle densities with several application requests.