GeoQoE-Vanet: QoE-Aware Geographic Routing Protocol for Video Streaming over Vehicular Ad-hoc Networks

Abstract

Video streaming is one of the challenging issues in vehicular ad-hoc networks (VANETs) due to their highly dynamic topology and frequent connectivity disruptions. Recent developments in the routing protocol methods used in VANETs have contributed to improvements in the quality of experience (QoE) of the received video. One of these methods is the selection of the next-hop relay vehicle. In this paper, a QoE-aware geographic protocol for video streaming over VANETs is proposed. The selection process of the next relay vehicle is based on a correlated formula of QoE and quality of service (QoS) factors to enhance the users’ QoE. The simulation results show that the proposed GeoQoE-Vanet outperforms both GPSR and GPSR-2P protocols in providing the best end-user QoE of video streaming service.

1. Introduction

Vehicular ad hoc networks (VANETs) are a challenging class of mobile ad hoc networks (MANETs) [1]. They are designed for communication between vehicles (V2V) or between vehicles and road infrastructure (V2I) [2]. VANETs have attracted a great interest by car manufacturing industries, academia and government agencies [3]. They can provide a very wide variety of applications that overlay all the fields of our daily road life. These applications can be generally grouped into two main categories [4]: safety applications and comfort (non-safety) applications.

Researchers have achieved much great progress on many studies in the area of VANETs. However, there are still some challenges that need to be investigated and evaluated like, video transmission, security, communication, etc. Video streaming in particular has been considered as a big issue over VANETs due to the high mobility environment as well as the huge enrichment by the video data. Moreover, due to the strict of the quality of service (QoS) metrics (such as packet loss, delay, jitter, etc.) on the video transmission [5,6]. Figure 1 shows some applications of video streaming over VANETs.

Figure 1. Video streaming applications over vehicular network [7].

The theory of qualtity of experience (QoE) has been widely used to represent user perception while the quality of service (QoS)-based approaches assess the streaming services quality through network-oriented metrics [8]. Consequently, adopting the QoE factors to control the video streams in VANETs is very essential in context of video applications [9]. For evaluating network service, many models and tools have been proposed for QoE modelling, monitoring, assessment and management with the exploration of many influencing QoS factors [10].

In VANETs environments, the routing task is a very challenging process because the mobility of the nodes themselves and routers at the same time. The way of exchanging information is determined by the routing protocol. Routing protocols in VANETs are generally classified into two categories: topology-based and position-based routing protocols [11]. Several studies confirm that the position-based routing protocols perform well in VANETs [12]. In these protocols, the routing of information from source to destination is based on selecting the nearest vehicle from the destination as the next hop. The greedy perimeter stateless protocol (GPSR) [13] is among these family of protocols, and considered the most known and studied geographic routing protocols.

The GPSR assumes that each node knows its own position and broadcasts it periodically. The next-hop forwarder node selection is based on geographical position [13]. It offers two modes for finding the next hop which are greedy forwarding and perimeter forwarding. In greedy forwarding, the packets are transmitted from one node to another by selecting the geographically closest node to the destination in the range of wireless transmission. When greedy forwarding fails, the protocol switches to perimeter forwarding, which consists of sending the packet to one neighbour of the current node by using the right-hand rule [12].

This paper proposes a new protocol that improves the greedy forwarding strategy used in many geographic routing protocols such as GPSR protocol. This new protocol is a QoE-aware geographic routing protocol for video streaming over VANETs called GeoQoE-Vanet. In the proposed protocol, the selection of relaying vehicles is not based only on the nearest to the destination, but should satisfy additional criteria to ensure better QoE. GeoQoE-Vanet evaluates the neighbouring vehicles based on correlated QoE factors and selects one that satisfies the best QoE. A correlation formula between the QoE and QoS factors has been developed. It allows evaluation of each nearby vehicle and selecting the most suitable next forwarding hop, as we stated in [14]. The proposed protocol is more suited for non-real-time applications such as advertisements and entertainment.

The rest of this paper is organized as follows. Section 2 gives an overview of the geographic routing protocols and how QoS and QoE are considered. Recent and relevant schemes and mechanisms that improve the QoE in VANETs are presented in Section 2. Section 3 describes the proposed QoE-aware geographic routing protocol. The performance evaluation and comparison are discussed in Section 4. Section 5 concludes the paper and presents some perspectives.

2. Related Work

Several researches have shown that position-based protocols are the most appropriate for VANETs [15]. In these protocols, the routing of information from source to destination is based on choosing the closest vehicle to the destination as the next hop. In the geographic routing protocols, the choice of the next-hop relay vehicle influences the quality of received information.

Many studies proposed various improvements to GPSR by using other information in addition to the position in the routing process. In these improvements, some researches consider the speed and the direction to estimate the distance in the next forwarding node selection process [16,17]. Others used predicted positions based on speed and direction [18,19,20]. Some studies introduced other factors as link lifetime [21], link reliability [22], link available time [23], link state [24], road density [25], buffer size [26], and social attributes [27]. Furthermore, the weighted numerical functions of many factors are used in [28,29]. The store and forward mode is used as an alternative to the perimeter farwarding in [30]. The selection of two different relays to forward information in order to enhance QoE has been proposed in [14].

Geographic protocols use various techniques and mechanisms in the routing process. Geographic source routing (GSR) is intended for use in urban scenarios [31]. In GSR, the source vehicle calculates the shortest path to the destination based on the street-map. On this path, it selects the sequence of intersections through which the data packet must be routed. Cross-layer weighted position-based routing (CLWPR) uses the prediction of the node’s position, the navigation information and the quality of the links in the next-hop selection [32]. In CLWPR, links quality is estimated based on the SNIR (signal to noise-plus interference ratio) value and MAC frame error rate. This information is combined into a weighted function to obtain the weight of all neighbouring vehicles. Link state aware geographic opportunistic routing protocol (LSGO) combines the geographic location and the link state information as the routing metric [33]. In this protocol, link quality is measured using the enhanced expected transmission count (ETX) metric.

Moreover, some topology-based protocols use the location in their routing mechanism. Location aided routing protocol (LAR) is an on-demand routing protocol [34]. It uses vehicles location information to decrease the routing overhead. The flooding mechanism is used in a restricted area called “request zone” during route discovery. The route request packet for a destination in LAR is flooded in this zone instead of the whole ad hoc network. GEOADV is a hybrid protocol which combines both reactive and geographic routing [35]. Routes from the source to the destination are created reactively. In path construction, an intermediate vehicle is chosen in the path if it maximizes the path weight. The vehicle’s weight is computed by a numerical formula including speed, movement direction and link quality.

In these mentioned protocols, video services are not considered in the routing mechanism. Few protocols are designed to manage video streaming. Video reactive tracking-based unicast protocol (VIRTUS) is a geographic routing protocol dedicated for video streaming in VANETs [36]. It uses the vehicle’s predicted state (position, velocity and bearing) and the maximum waiting time in the relay selection process. 3MRP is a geographic multimedia multimetric map-aware routing protocol based on hop-by-hop forwarding decisions in a smart city [37]. The next-hop selection is based on a weighted numerical function of the distance to the destination, vehicles density, trajectory and available bandwidth. It uses the map to avoid sending packets to vehicles behind buildings. In the discussed related litterature, routing decisions can not satisfy the video services requirements. They should take into consideration the end-user QoE improvement in the selection of the relay vehicles.

However, there are some studies that focused on the user QoE in routing decisions for multimedia services. Distributed beaconless dissemination (DBD) is a geographic routing protocol for the dissemination of live video flows on multimedia highway VANETs [38]. It creates Vehicle to Vehicle (V2V) backbones for video packet relaying to enhance the end-user experience. QoE-driven and link-quality receiver based (QOALITE) is a protocol for live video dissemination with QoE in VANETs [39]. For relaying vehicle selection, it uses location and link quality. Distributed QoE-aware receiver based (DQORE) is a QoE-aware location-based protocol for the dissemination of real-time videos in VANETs [40]. It is a coupling of QoE-aware receiver based (QORE) mechanism and a distance-based statistical routing protocol. The election of relay nodes in video dissemination is based on QoE-driven parameters and vehicle position. These protocols are designed for video dissemination and cannot be used in unicast video services.

The distinction between the proposed scheme and the other geographic routing protocols lies in the selection of the next forwarder vehicle. In GeoQoE-Vanet, this process is based in addition to the QoE measured based on packet loss rate, delay and jitter, on the prediction of the distance to destination calculated according to the position, speed and direction, stored in the table of neighbours. Morever, a packet is sent twice using two different relays when the QoE of each neighbouring vehicle is low. For performance evaluation, three QoE objective metrics are used to measure the video quality level from the user point of view, which are peak signal-to-noise ratio (PSNR) [41], structural similarity (SSIM) [42], and, mean opinion score (MOS) [43].

3. QoE-Aware Geographic Routing Protocol for Video Streaming over VANETs

The GeoQoE-Vanet is a QoE aware geographic routing protocol for video streaming over VANETs, based on the selection of the best next forwarding vehicle from the neighbours of the current vehicle. The information used in the selection decision is collected by vehicles where each one records its state information, stores it locally and broadcasts it in beacon messages to surrounding vehicles. When a vehicle receives a beacon message, it inserts or updates the entry of the beacon sender vehicle in the neighbours’ table. The factors used in the proposed protocol are position, direction, speed and link expiration time as mobility factors, and packet loss rate, delay and jitter as QoS factors to estimate the vehicle’s MOS ($MO{S}_{routing}$). When a vehicle decides to send a video to a destination, it first selects the best forwarding vehicle based on information stored in its neighbours’ table, then sends the video information to the selected vehicle. The selected vehicle resends the received video data to another vehicle in the same manner and this process is repeated until reaching the destination. An example of a vehicle neighbours’ table is shown in Table 1. Figure 2 shows the selected relay vehicle based on the proposed next-hop selection mechanism. In this example, the vehicle 28 is selected by the source $\left(S\right)$ despite the fact that it is not the closest to the destination $\left(D\right)$. However, it ensures, better than other neighbours of $\left(S\right)$, the perceived video quality. When the state of the sender’s neighbours does not satisfy the QoE requirement and there is a risk of packet loss, a second different relay is used to send the same packet as proposed in the previous paper [14]. In the proposed protocol, only vehicle to vehicle(V2V) communication is used and the data is forwarded between vehicles without using the infrastructure to vehicle (V2I) communication.

Table 1. Vehicle neighbours’ table in GeoQoE-Vanet.

Vehicle-Id	Position (x, y)	Direction	Velocity	MOSrouting	Timestamp
25	$6520.72,2324.830$	0	$13.06$	$2.63$	$23.87$
28	$6620.81,2363.39$	0	$4.47$	$3.53$	$24.94$
66	$6305.33,2437.66$	0	$7.99$	$1.96$	$24.35$
88	$6458.77,2291.84$	0	$13.16$	$2.65$	$24.04$
123	$6569.16,2233.75$	0	$0.00$	$2.63$	$22.24$

Figure 2. Next hop selection strategy in GeoQoE-Vanet protocol.

The beacon message used in GeoQoE-Vanet is the usual beacon packet employed in vehicular networks. It is periodically droadcasted by each vehicle. It has been slightly modified by adding information needed by GeoQoE-Vanet as depicted in Figure 3.

Figure 3. Beacon packet format in GeoQoE-Vanet protocol.

Each vehicle records its delay, jitter and packet loss rate. Before sending a beacon, it estimates its $MO{S}_{routing}$ then inserts it in the beacon message. In this protocol, the mobility factors are used to predict the future position and the link quality of all vehicles in the vicinity during the selection phase of the next relay.

The rest of this section is devoted to the presentation of the quality factors used in the proposed protocol, the developed correlation formula of these factors and the mechanism of the next-hop selection. For the remainder of this paper, the adopted notations are presented in Table 2.

Table 2. Adopted notations.

Notation	Descriptions
$G=\{V,E\}$	Undirected graph
V	Set of vehicles
u, v, i, j	Vehicles
E	Set of communication links E: $V\times V$
l	Link $\in E$
$(u,v)$	Neighbour relation
$N\left(u\right)$	Set of neighbours of vehicle u
$w(u,v)$	Weight vector assigned to a link $(u,v)$
$w_i$	Individual weight of metric i
t, $t_{cur}$, $\Delta t$, $T_{delay}$, $T_r$, $T_s$, $\delta$	Time
x, y, $x_p$, $y_p$, $x_d$, $y_d$, $x_i$, $y_i$, $x_j$, $y_j$	Position
s, $v_i$, $v_j$	Velocity
$\theta$, ${\theta }_i$, ${\theta }_j$	Direction
D, ${Dist}_i$	Distance
$LET$, ${LET}_i$	Link expiration time
r	The transmission range
$T_{delay}\left(u\right)$	Mean of all vehicle links delays
$card\left(N\right(u\left)\right)$	Number of neighbours of the vehicle u
$J\left(u\right)$	Jitter of a vehicle u
$J(u,v)$	Jitter between the vehicles u and v
$PL\left(u\right)$	Packet loss rate of the vehicle u
${PKTs}_{rc}$	Number of packets received correctly
${PKTs}_{rd}$	Number of packets received but dropped
${PKTs}_{sc}$	Number of packets sent correctly
${PKTs}_{sd}$	Number of packets sent but dropped
$QoE\left(u\right)$	QoE value of a vehicle u
$MO{S}_{routing}\left(u\right)$, ${MO{S}_{routing}}_i$, $MO{S}_{routing}$, $MO{S}_{video}$	MOS value
$k_1$, $k_2$, $Q_{MAX}$, $Q_{MIN}$, $\alpha$, $\beta$, $\gamma$	Constant values
$p\left(i\right)$	Weight value of vehicle i

3.1. Problem Formulation

The network model of a vehicular ad hoc network can be represented by an undirected graph $G=\{V,E\}$, where V is the set of vehicles and E is the set of communication links connecting them. A communication link is established between two vehicles when each one is in the communication range of the other. Each vehicle has an IEEE 802.11p-compliant radio transceiver, through which it can communicate with other vehicles and GPS to obtain its location coordinates. The definition of neighbour relation noted by $(u,v)$ is: vehicle u and v are one-hop neighbours if $\exists l\in E$ connecting directly u and v. $N\left(u\right)$ is the set of all one-hop neighbours of vehicle u; $N\left(u\right)=\{\forall v\in V,\exists (u,v)\in E\}$. Each link between two vehicles u and v is associated with a link weight vector $w(u,v)=(w_0,w_1,\dots ,w_n)$ in which $w_i$ is an individual weight component for a given factor, that is, a single metric such as $MO{S}_{routing}$, link lifetime, and distance.

3.2. Mobility Metrics

The GeoQoE-Vanet protocol uses two mobility metrics which are: distance from the destination and the link expiration time. In computing these metrics, the predicted positions of neighbours are used to increase the probability to select the most stable relay vehicle. The detailed descriptions of these metrics are given in the following subsections.

3.2.1. Position Prediction

The proposed scheme assumes that vehicles broadcast periodically their information using beacons. Hence, each vehicle build and maintain updated its neighbours’ table. To increase the possibility to select the best relay vehicle, GeoQoE-Vanet uses the predicted positions of neighbours based on their last known positions, velocities, and moving directions.

The predicted position of a vehicle u which has a position (x, y), absolute velocity s, and direction $\theta$ at time t can be computed using Formula (1):

$$\left\{\begin{array}{ccc}{x}_p\hfill & =& \hfill x+scos\left(\theta \right)\Delta t\\ y_p\hfill & =& \hfill y+ssin\left(\theta \right)\Delta t\end{array}\right.$$

(1)

where $x_p$, $y_p$ represent the coordinates of the vehicle’s predicted position. Time interval $\Delta t$ is calculated by $\Delta t=t_{cur}-t$, where $t_{cur}$ is the current time and t is the time of the past position.

3.2.2. Distance Calculation

In geographic protocols, the position of the destination vehicle is a crucial information. It is assumed that it is given by a service which is out of the scope of this paper. In the relay selection phase, the sender uses the predicted position of its neighbours to calculate the distance between neighbours and the destination using Equation (2):

$$D=\sqrt{{(x_p-x_d)}^2+{(y_p-y_d)}^2}$$

(2)

where $(x_p,y_p)$ is the predicted position of one of the neighbours and $(x_d,y_d)$ is the position of the destination vehicle.

3.2.3. Link Expiration Time

The high-speed of vehicles in VANETs is the source of fast topology changing, which leads to frequent link breakage. The protocol should select the vehicle which gives the longest connection time. To calculate the link expiration time ($LET$), the proposed scheme uses the formula proposed in [44]. $LET$ is considered as the period of time during which two vehicles stay connected. Let $(x_i,y_i)$ and $(x_j,y_j)$ be the coordinates of two vehicles i and j which are moving in directions ${\theta }_i$, ${\theta }_j$ where $(0\le {\theta }_i,{\theta }_j<2\pi )$, having speeds $v_i$ and $v_j$ respectively and let r be the transmission range. $LET$ is estimated using Equation (3):

$${LET}_{ij}=\frac{-\left(ab+cd\right)+\sqrt{\left(a^2+c^2\right)r^2-{\left(ad-bc\right)}^2}}{a^2+c^2}$$

(3)

where $a=v_{i}cos{\theta }_i-v_{j}cos{\theta }_j$, $b=x_i-x_j$, ${c=v}_{i}sin{\theta }_i-v_{j}sin{\theta }_j$ and $d=y_i-y_j$.

3.3. QoS Metrics

In the proposed protocol, three QoS metrics are used: packet loss rate, end-to-end delay, and jitter. These factors may introduce distortions in the video that affect the quality of the received video. The delay affects the quality of the video, especially in the beginning by causing the start-up delay. In the rest of the video transmission, its effects could be avoided by the use of a buffer. Jitter makes video packets waiting in the queue to be displayed in the correct order which may freeze the most recent frame until the belated frame arrives. The belated frame would be played briefly to preserve the timing of other arrived frames. Packet loss degrades the quality of received video frames. It can cause frame loss, which produces the freezing of a recent frame and the jump to the next arrived frame. This may make the video useless. Packet loss is usually caused by congestion or corrupted packets [45]. The three metrics are used to estimate the $MO{S}_{routing}$ of the vehicle and serves together with mobility metrics for the selection of the next forwarding vehicle.

3.3.1. Delay

The link delay between two vehicles is the transmission time over their interconnecting link. It can be calculated using Equation (4) proposed in [46]:

$$T_{delay}=T_r-T_s$$

(4)

where $T_r$ is the reception time of the message and $T_s$ is its sending time.

The vehicle delay is the mean of all its links delays with the neighbouring vehicles and is calculated using Equation (5):

$$T_{delay}\left(u\right)=\frac{\sum T_{delay}}{card\left(N\right(u\left)\right)}$$

(5)

where $card\left(N\right(u\left)\right)$ is the number of neighbours of vehicle u.

3.3.2. Jitter

Jitter is considered as an important metric in many VANET applications [47]. It is defined as the average of delay variation between two consecutive packets received at the destination [48]. The jitter of a vehicle u is defined as the average of jitters of transmitted packets to the neighbouring vehicles [49]. It is calculated using Equation (6):

$$J\left(u\right)=\frac{{\sum }_{v\in N\left(u\right)}J(u,v)}{card\left(N\right(u\left)\right)}$$

(6)

where $card\left(N\right(u\left)\right)$ is the number of neighbours of vehicle u and $J(u,v)$ is the jitter between vehicles u and v.

3.3.3. Packet Loss Rate

The vehicle packet loss rate is the ratio between the number of lost packets and the total of packets sent or received during a period of time. For a given vehicle u, the packets can be either received correctly or received but dropped. Packets can be sent correctly or dropped while sending. Many reasons cause packets drop such as errors, discarding, packet’s lifetime expiration, congestion or drop from the queue. The packet loss rate $PL\left(u\right)$ of a vehicle u is calculated using Equation (7) proposed in [50]:

$$PL\left(u\right)=\frac{({PKTs}_{rd}+{PKTs}_{sd})}{({PKTs}_{rc}+{PKTs}_{sc}+{PKTs}_{rd})}$$

(7)

where ${PKTs}_{rc}$ is the number of packets received correctly. ${PKTs}_{rd}$ is the number of packets received but dropped. ${PKTs}_{sc}$ is the number of packets sent correctly and ${PKTs}_{sd}$ is the number of packets sent but dropped.

3.4. Next Hop Selection in GeoQoE-Vanet

The GeoQoE-Vanet protocol enhances the greedy forwarding to ensure better quality in each next-hop selection. Vehicles broadcast periodically a beacon message containing their information every $\delta$ time units. The exchanged beacons allow each vehicle to build and maintain a table of its neighbours. The beacon message contains the vehicle information ($Id$, $position$, $movingdirection$, $speed$, $MO{S}_{routing}$, $Sendingtime$). Before sending a beacon, each vehicle computes its QoE as given in Formula (8) then converts it to $MO{S}_{routing}$ using Formula (9). To compute its QoE, a vehicle uses packet loss rate, jitter and delay. These metrics have a significant influence on QoE. There are many models to calculate or predict the QoE in wired networks [51,52] or wireless and vehicular networks [7]. These models are generally used to calculate or predict end-user QoE. They are time consuming and need a lot of information. GeoQoE-Vanet uses Formula (8) proposed in [53]:

$$QoE\left(u\right)=\frac{k_1}{(T_{delay}\left(u\right)+k_2*J\left(u\right))*e^{PL\left(u\right)}}$$

(8)

where $k_1$ and $k_2$ are adjustment parameters for the weight of the other parameters. $k_1$ unit is millisecond (letting be the QoE parameter dimensionless) and $k_2$ gives higher importance to jitter against delay. $T_{delay}\left(u\right)$, $J\left(u\right)$ and $PL\left(u\right)$ are the vehicle delay, jitter and packet loss rate.

To obtain the mean opinion score $MO{S}_{routing}\left(u\right)$ by conversion of its QoE, the vehicle u uses Formula (9) proposed in [53]:

$$MO{S}_{routing}\left(u\right)=\left\{\begin{array}{cc}5\hfill & QoE\left(u\right)\ge Q_{MAX}\hfill \\ e^{QoE\left(u\right)-Q_{MIN}}\hfill & Q_{MIN}<QoE\left(u\right)<Q_{MAX}\hfill \\ 1\hfill & QoE\left(u\right)\le Q_{MIN}\hfill \end{array}\right.$$

(9)

where $Q_{MIN}$ and $Q_{MAX}$ are the low and the high threshold values respectively.

Upon receiving a beacon message, the table of neighbours is updated. Algorithm 1 shows the actions taken by the vehicle when sending a beacon message to its neighbours while Algorithm 2 presents undertaken actions when receiving a beacon message.

Algorithm 1 Actions performed when sending a beacon message

//Actions performed when sending a beacon message to its neighbours’ vehicles $getPosition(\&x,\&y);$               //Getting its own coordinates $s\leftarrow getVelocity\left(\right);$                  //Getting its own velocity $d\leftarrow getDirection\left(\right);$               //Getting its own direction

//Calculating its own $QoE$ using Formula (8) $QoE\leftarrow k1/(getDelay\left(\right)+k2*getJitter\left(\right))e^{getPL\left(\right)};$

//$getDelay\left(\right)$ //Getting its own delay //$getJitter\left(\right)$ //Getting its own jitter //$getPL\left(\right)$ //Getting its own packet loss rated

//Calculating its own $MO{S}_{routing}$ using Formula (9) if$QoE\le QMIN$then  $MO{S}_{routing}\leftarrow 1;$ else

if $(QoE>QMIN)\mathbf{and}(QoE\le QMAX)$ then   $MO{S}_{routing}\leftarrow e^{QoE-QMIN};$  else

$MO{S}_{routing}\leftarrow 5;$  end if end if

$t\leftarrow now\left(\right);$                                        //Getting current time $id\leftarrow getVehicleId\left(\right);$                       //Getting vehicle id $sendBeacon(id,x,y,d,s,MO{S}_{routing},t);$  //Sending the beaacon

Algorithm 2 Actions performed when receiving a beacon message

//Actions performed when receiving a beacon message from a neighbour $extractBeaconMessage(id,x,y,d,s,MO{S}_{routing},t);$  //Extracting the information from the beacon message $tr\leftarrow now\left(\right);$                                                           // Getting current time

if$idinneighboursTable$then  $neighboursTable.upDate(id,x,y,d,s,MO{S}_{routing},t,tr);$  //Updating vehicle information in neighboursTable else

$neighboursTable.insert(id,x,y,d,s,MO{S}_{routing},t,tr);$  //Inserting vehicle information in neighboursTable end if

When a vehicle decides to send a video to another vehicle, it first evaluates all its neighbours using the Formula (10), then selects one which has the greatest value and sends it the packet. The packet receiver uses the same process until reaching the destination. As presented in Figure 4, the next forwarding vehicles are selected from the source to the destination. Figure 5 shows a scenario for the selection of the last relay.

$$p\left(i\right)=\alpha *{MO{S}_{routing}}_i+\beta *{Dist}_i+\gamma *{LET}_i$$

(10)

where $\alpha ,\beta ,\gamma \in [0,1]$ and $\alpha +\beta +\gamma =1$. ${MO{S}_{routing}}_i$ is the $MO{S}_{routing}$ of the neighbour vehicle i obtained from the neighbours table. $Dis{t}_i$ is the distance between the vehicle i and the distinaition. $LE{T}_i$ is the link expiration time between the current vehicle and the neighbour vehicle i.

Figure 4. Next forwarding vehicles selection scenario.

Figure 5. Last forwarding vehicle selection scenario.

When the $p\left(i\right)$ values of all neighbours are under the threshold of the desired weight, the current vehicle sends the same packet to the two best neighbours at the same time to maximise the probability of correct message reception. Algorithm  3 illustrates the process of the next-hop vehicle selection in GeoQoE-Vanet.

Algorithm 3 The next-hop vehicle selection process in GeoQoE-Vanet protocol

//Actions performed when deciding to send or forward a video data packet $id\leftarrow Pkt.getDestination\left(\right);$         //Getting the destination of the video from the received packet if$idinneighboursTable$then $sendVideoPacketTo\left(id\right);$         //Sending the packet to the destination $return;$                  //Ending the process else $wMax\leftarrow 0;$ //Weight of the selected vehicle $bMO{S}_{routing}\leftarrow true;$ //Checking if all vehicles’ $MO{S}_{routing}$ is under the $MO{S}_{routing}$ threshold for all i in neighboursTable do $getPredictedPosition(\&xp,\&yp);$ //Calculating the predicted position (xp, yp) of the vehicle i using Equation (1) $Dist\leftarrow getDistance(xp,xy,xd,yd);$ //Calculating the distance between vehicle i and the destination using Equation (2) $LET\leftarrow getLET\left(\right);$//Calculating the Link Expiration Time between the current vehicle and the vehicle i using the Equation (3) $MOS\leftarrow i.getMO{S}_{routing}\left(\right);$ //Getting the $MO{S}_{routing}$ of the vehicle i from neighboursTable $W\leftarrow \alpha *MO{S}_{routing}+\beta *Dist+\gamma *LET;$ //Calculating the weight of the vehicle i using Equation (10) if$W>thMO{S}_{routing}$then //The vehicle i has a weight greater than the $MO{S}_{routing}$ threshold $bMO{S}_{routing}\leftarrow false;$ end if if$W>wMax$then //The weight of the vehicle i is greater than the weight of the previous vehicles $FSV\leftarrow i;$ //Forwarding vehicle is i $wMax\leftarrow W;$ end if end for if$bMO{S}_{routing}=false$then //The vehicle can send the packet with acceptable weight $sendVideoPacketTo\left(FSV\right);$ //Sending the packet to the selected next-hop vehicle else $selectTwoBestVehicles(FSV1,FSV2);$ //Selecting the two vehicles having the best weights $sendVideoPacketTo\left(FSV1\right);$ $sendVideoPacketTo\left(FSV2\right);$ end if end if

4. Performance Evaluation

This section presents tools, metrics, and mythology used in the evaluation of GeoQoE-Vanet protocol. The VANETs simulation scenario used is an urban scenario generated by OpenStreetMap [54] and SUMO mobility traffic simulator [55]. The evaluation is made under NS-2.35 network simulator [56] and Evalvid tool [57].

For the simulation scenario, an area of Ouargla city is extracted from Open Street Maps (OSM) as shown in Figure 6, then SUMO is used to generate the mobility of vehicles for simulation scenarios as exposed in Figure 7. Thereafter, the mobility files are created for use in NS simulator.

Figure 6. Simulated roadmap area from Open Street Maps (OSM).

Figure 7. Simulated zone imported in SUMO.

EvalVid is a tool for evaluating the quality of transmitted video over a communication network [58]. The video stream used in the simulations is a YUV video sequence [59] with a resolution of $352\times 288$ pixels in standard interface format (CIF). The main parameters are summarized in Table 3.

Table 3. Simulation parameters.

Parameter	Value
Environment	Urban
Simulation area	1000 × 1000 m
Simulation time	200 s
Number of nodes	10, 20, 30, 40, and 45
Max speed	22 m/s
Propagation model	Two-Ray-Ground
MAC, PHY layer protocol	IEEE 802.11p
Transmission range	250 m
Video frame size	352 × 288 pixels (CIF format)
Video	Akiyo (300 frames, 11 s)
Background traffic	CBRtraffic

• Peak signal to noise ratio: (PSNR) [41], is the most popular and widely accepted quality metric. It compares frame by frame the quality of the video received with the original one.
• Structural similarity: (SSIM) [42], is frame-to-frame video quality metric. It is based on structural information, luminance and contrast. The values of SSIM are comprised between 0 and 1, where a higher SSIM value means better video quality.

The MSU video quality measurement tool [60] was used to measure the PSNR and the SSIM. It compares the quality of the received video with the original video. To obtain the MOS of received video, the mapping of PSNR to MOS given in Table 4 was used.

Table 4. PSNR to MOS conversion [58].

PSNR (dB)	MOS
≥37	5 (excellent)
31–36.9	4 (good)
25–30.9	3 (fair)
20–24.9	2 (poor)
≤19.9	1 (bad)

In the simulation of each scenario, fifteen $\left(15\right)$ runs (replications) are performed and then the mean value is used as a result. For each replication, the source vehicle, the destination vehicle and the time when streaming starts are randomly chosen.

The $k_1$ and $k_2$ values have been chosen by trial and error until the authors found the suitable $k_1$ and $k_2$ values that produce the highest PSNR. The more appropriate disincentive values ($k_1=k_2=1$) that gives best PSNR results are used later in the simulations. The performance evaluation metrics used to measure the performance of the proposed protocol are PSNR, SSIM, frame loss, and end-to-end delay. The performance of GeoQoE-Vanet protocol is compared with GPSR [13] and GPSR-2P [14].

4.1. QoE Parameters

The simulation results show that the GeoQoE-Vanet protocol performs better than GPSR and GPSR-2P protocols. The received video quality at the destination has increased with the number of vehicles. This results from the flow of transmitted video data being shared between more vehicles as shown in Figure 8 and Table 5. Figure 8 represents the mean PNSR of results of all scenarios. Table 5 illustrates the mean $MO{S}_{video}$ of results of all scenarios. The proposed protocol can find better-relaying vehicles which allows it getting high $MO{S}_{video}$ values. $MO{S}_{video}$ for GPSR and GPSR-2P is less than GeoQoE-Vanet because they can not avoid bad relaying vehicles. Their next-hop selection mechanism is based only on distance.

Figure 8. Mean PSNR results of all scenarios.

Table 5. End-user mean $MO{S}_{video}$ of received video in all scenarios.

	${\mathit{MOS}}_{\mathit{video}}$
Protocol	10	20	30	40	45
	Vehicles	Vehicles	Vehicles	Vehicles	Vehicles
GeoQoE-Vanet	2	2	3	3	4
GPSR-2P	1	1	2	3	3
GPSR	1	2	3	3	3

When the number of vehicles is decreased, the $MO{S}_{video}$ is decreased also because alternatives here become limited and the load is shared between a limited number of vehicles. This may lead to congestion that induces packet loss, delay, and jitter which degrades the quality of the received video.

In all scenarios, GeoQoE-Vanet gives the best results because it adapts well to the network degradation and always select the best vehicles based on their quality factors and not only on their distance from the destination.

The results showen in Figure 8 and Table 5 are confirmed by SSIM results in Figure 9. Figure 9 represents the mean SSIM of results of all scenarios. The quality improves with the increasing number of vehicles and reaches the maximum of $0.904$ for GeoQoE-Vanet in the scenario of 45 vehicles. The SSIM diminishes when the number of vehicles decreases. However, in all scenarios, the SSIM of GeoQoE-Vanet is always better than that of GPSR and GPSR-2P.

Figure 9. Mean structural similarity (SSIM) results of all scenarios.

Figure 10 illustrates an example of the quality of received frames in one scenario of 40 vehicles. At the beginning of the simulation, the quality of the received frames is low. After a short period of time, a fast increase in the quality of received frames appears because the number of the received packets increases. There are a small packet loss and jitter which are the result of limited number of transmitted video packets. The shown decrease and increase at the beginning are the effect of initial delay which does not have a significant impact on the rest of the simulation.

Figure 10. PSNR of received video frames in one 40 vehicles scenario.

The quality decreases again over time because packet loss and jitter occur when transmitted data between vehicles increases. The proposed protocol preserves a good quality of frames because it selects the vehicles that ensure the best quality. GPSR and GPSR-2P have a remarkable quality degradation because the relay vehicles selection is based only on distance from the destination and do not allow ovoiding vehicles that can not ensure quality. At the end of the video transmission, there is a decrease in the quality of frames. This is due to increased packets loss and jitter when the number of transmitted packets is high. It is shown in Figure 10 that GPSR and GPSR-2P have a high number of lost frames and the proposed protocol performs better.

Figure 11 illustrates the results of SSIM of one scenario of 40 vehicles and confirms the results in Figure 10. It shows a decrease in quality of received frames at the beginning of the simulation followed by a rapid increase. It shows that, over time, a decrease in the quality of frames received by the destination with an important frame loss in GPSR and GPSR-2P.

Figure 11. SSIM of received video frames in one 40 vehicles scenario.

4.2. QoS Parameters

4.2.1. Frame Loss

Simulation results for the different tested scenarios show that GeoQoE-Vanet has lower frame loss values compared with GPSR and GPSR-2P as illustrated in Figure 12. This is due to the fact that GeoQoE-Vanet selects the next hop vehicle which can enhance the perceived quality of transmitted video. Figure 12 shows that the frame loss percentage inversely proportional to the number of vehicles. As the number of vehicles increases, the probability of finding a best candidate vehicle be the next forwarder becomes high which decreases the frame loss.

Figure 12. Frame loss percentage of all scenarios.

4.2.2. Average End-to-End Delay

In scenarios of 40 and 45 vehicles, the average end-to-end reaches a low value than other scenarios for the three protocols that have approximately the same values as shown in Figure 13. A high number of vehicles allows GeoQoE-Vanet to find the best paths to the destination with acceptable end-to-end delay. In scenarios of 10, 20 and 30 vehicles, GeoQoE-Vanet has an average end-to-end delay value greater than the other protocols. This is the result of following long paths to avoid congested vehicles and to decrease the frame loss.

Figure 13. Average end-to-end delay of all scenarios.

In all scenarios, GPSR has the smallest mean value of end-to-end delay since it always selects the closest vehicles to the destination which does not ensure that the data reach the destination. Similarly, based only on distance, GPSR-2P uses two paths when sending data and thus increases the end-to-end delay without guarantee that the data reaches the destination.

Therefore, the GeoQoE-Vanet protocol offers better end-user QoE than GPSR and GPSR-2P in all scenarios. The simulation also shows that GPSR performs better than GPSR-2P. This is justified by the duplicate video data packets being dropped by the receiver vehicle and are not used in the final video reconstruction.

All the three protocols suffer from major quality degradation in sparse environments, but GeoQoE-Vanet still provides better results compared to GPSR and GPSR-2P. In light of these results, further improvements of the proposed protocol are required to better adapt to sparse environments. The store and forward mechanism may be a promising candidate to explore. The estimation of a vehicle’s QoE in GeoQoE-Vanet is based on delay, jitter and packet loss ratio. To enhance this estimation, many other factors may be included. The effects of these new factors on the end-user QoE of the received video must be thoroughly studied. Furthermore, many other QoE’s formulas exist in the litterature and are interesting to use in testing GeoQoE-Vanet for a more accurate evaluation. In this paper, GeoQoE-Vanet has been tested in an urban scenario. It is important to consider, in the future, a more in-depth evaluation in a highway scenario subject to different constraints and challenges.

5. Conclusions

In this paper, a QoE-aware geographic routing protocol for video streaming over VANETs called GeoQoE-Vanet has been proposed. In this proposed protocol, the relaying vehicles should have a good quality to ensure end-user QoE. The selection decision of the next-hop vehicle in GeoQoE-Vanet is based on position, direction, speed, link expiration time, packet loss rate, delay and jitter. Neighbouring vehicles are avaluated based on correlated QoE factors and the selected relay is the best which satisfies the desired QoE. The simulation results showed a better end-user QoE in GeoQoE-Vanet compared to GPSR and GPSR-2P protocols in an urban environment. GeoQoE-Vanet has better results than GPSR and GPSR-2P protocols in terms of MOS, PSNR, and SSIM performance metrics. It can be further enhanced by using other quality factors which need new and better tailored QoE formulas. Furthermore, it can be improved with a store and forward mechanism, especially in a sparse environment.