# A Game Theory Approach for Platoon-Based Driving for Multimedia Transmission in VANETs

Authors: Wellington Lobato Junior; Denis Rosário; Eduardo Cerqueira; Leandro A. Villas; Mario Gerla
Journal: Wireless Communications and Mobile Computing
 (2018)

---

## Abstract

Vehicular Ad Hoc Networks (VANETs) allow users, services, and vehicles to share information and will change our life experience with new autonomous driving applications. Multimedia will be one of the core services in VANETs and are becoming a reality in smart environments, ranging from safety and security traffic warnings to live entertainment and advertisement videos. However, VANETs have a dynamic network topology with short contact time, which leads to communication flaws and delays, increasing packet loss, and decreasing the Quality of Experience (QoE) of transmitted videos. To cope with this, neighbor vehicles moving on the same direction and wishing to cooperate should form a platoon, where platoon members act as a relay node to forward video packets in autonomous VANETs. In this article, we introduce a game theory approach for platoon-based driving (GT4P) for video dissemination services in urban and highway VANET scenarios. GT4P encourages the cooperation between neighbor vehicles by offering reward (e.g., money or coupon) for vehicles participating in the platoon. In this sense, GT4P establishes a platoon by taking into account vehicle direction, speed, distance, link quality, and travel path, which reduces the impact of vehicle mobility on the video transmission. Simulation results confirm the efficiency of GT4P for ensuring video transmissions with high QoE support compared to existing platoon-based driving protocols.


---

## Body

## 1. Introduction

Vehicular Ad Hoc Networks (VANETs) allow moving vehicles to form self-organized ad hoc networks without the need of permanent infrastructure [1]. VANETs aim to provide communication exchange between vehicles, enabling autonomous vehicle communications and new use cases for enhanced safe driving at high vehicle speeds, harsh driving conditions, and cooperative driving. Besides the research efforts to increase VANETs connectivity, academy and industry partners have made efforts for autonomous driving [2]. In this scenario, users could record, share, and even watch real-time videos in their vehicles, creating new specialized services for these users, ranging from on-road multimedia safety and security to entertainment video flows [3]. For instance, an on-board event detection system on vehicles could identify an accident and disseminate real-time video via VANET to show the area of an accident to its peers [4, 5]. In addition, autonomous driving must consider a see-through system, which relies on live multimedia information of vehicles approaching from the opposite direction in order to facilitate safety assessment during overtaking maneuvers [6, 7]. For instance, it enables vehicles to detect hidden objects or get a more accurate view on what is happening within their environment.Video dissemination is one of the key applications in smart VANETs and requires Quality of Experience (QoE) support to deliver video content with a minimal quality level based on user experience, where users expect to receive live videos without ghosting, blocking, pixelization, and freeze frame independent of the network conditions and VANET characteristics [8]. This is a hard task due to vehicles usually moving at high speeds, leading to frequent disconnections and limiting the duration of Vehicle-to-Vehicle (V2V) communication to a few seconds [9]. For instance, Uppoor and Fiore [10] analyzed a large-scale mobility trace from Cologne-Germany and concluded that the contact between pairs of vehicles is extremely short, i.e., between 1 and 15 seconds. Hence, mitigating the influence of short contact time in V2V communications to avoid communication flaws, delays, and packet loss during video transmissions is still a challenging task [11].Vehicles moving on the same direction and closer to each other could cooperate in establishing a platoon to mitigate such drawbacks [12]. This is because platoon-based driving provides an autonomous and cooperative driving pattern for a group of vehicles with a common path, where vehicles maintain a constant distance [13, 14]. The platooning protocol must control and manage the platoon, including formation, merging, splitting, and maintenance tasks [15]. Specifically, the platoon leader defines the speed and direction for platoon members, giving commands about when to accelerate or break. The platoon brings many benefits, such as more efficient information dissemination and sharing among platoon vehicles [15]. In this sense, platoon members could actively collaborate in the video transmission without route failures. Platoon is also a promising way to improve traffic efficiency and safety and reduce fuel consumption andCO2 emissions by vehicles driving close to each other and at the same speed [16].Despite the benefits of platoon-based driving from a system point-of-view, vehicles have a selfish behavior, leading to platoon splitting and merging, as well as packet losses. For instance, vehicles may not be willing to join the platoon in order to help other vehicles by forwarding packets, since they consume computing, communicating, and fuel resources, as well as changing their travel time [17]. Selfish vehicles will try to join and quickly leave the platoon, in order to receive the reward without participating in the platoon for the video transmitting task. In this sense, the decision of joining still relies on the driver, who considers the benefits of joining the platoon while taking a longer route/time to reach the destination location. Cooperative behavior can be enforced by means of a rewarding function to give incentives to vehicles participating in the platoon, since users tend to be selfish [18, 19]. In this sense, the platoon must rely on incentive mechanisms to encourage the user (i.e., vehicles) participation, where monetary incentive is the most immediate method to reward vehicles that joined the platoon for video transmission with QoE support [20]. For instance, platoon-based driving can be encouraged by offering discounts at local markets, free parking lots, free movies, priority for video consumption, and network resources, among other profits [20, 21].In this context, game theory is an effective tool to model and analyze an incentive mechanism and also for inactivated nodes (i.e., vehicles) to cooperate [20, 22]. Game theory provides a set of mathematical and technical tools for modeling situations involving conflicts of interest between nodes [23]. For instance, game theory may resolve conflicts between two or more platoons by the same vehicle, or it can encourage selfish users to cooperate by paying a fair price. Game theory approaches are divided into cooperative and noncooperative games [24]. In the former, players cannot make commitments before starting the game. In the latter, players can establish previous relationships before starting the game. In simultaneous games, the game interaction happens in a single step, while in sequential games, the interaction happens in a sequence of steps. In a platoon-based driving considering game theory, it is expected that each vehicle selects their strategy without having access to the strategy and without waiting for the decision from other vehicles; i.e., it is a noncooperative and simultaneous game.In this article, we introduce a game theory approach for platoon-based driving protocol (GT4P) for video transmission over urban and highway VANET scenarios. GT4P considers it a noncooperative game, where cooperative behavior is enforced by means of a rewarding function to give incentive for vehicles participating in the platoon, which is actively collaborating with the video transmission with QoE support. The GT4P protocol chooses vehicles to form a platoon based on direction, speed, distance, link quality, and vehicle travel path. In this sense, GT4P selects a vehicle to join the platoon with similar speed and travel path compared to the platoon, suitable link quality, and closer to a predefined distance between platoon members. GT4P protocol also enforces that platoon vehicles maintain a given distance to mitigate route failures and packet loss.This article extends our previous work [21, 25] with a novel incentive mechanism based on vehicle travel path, speed, link quality, and distance. In addition, we adjusted the distance between platoon members in order to reduce the effects of wireless communication on the packet loss. Finally, we introduced an extended evaluation of existing platoon-based protocols used to disseminate videos in urban and highway VANET scenarios. Simulation results demonstrate the efficiency of the GT4P protocol in transmitting video with QoE 10% higher than videos transmitted by the Platoon to Video (P2V) [21], 60% higher than Bidirectional Stable Communication (BDSC) [26], and 50% higher than Furthest Distance (FD) [27] platoon protocols.The remainder of this article is structured as follows. Section2 outlines existing works and their main drawbacks to provide video transmission over VANET with QoE support. Section 3 outlines the GT4P protocol and its operation. Section 4 introduces the simulation description and results. Section 5 introduces the conclusions of this article.


## 2. Related Work

Several works have been proposed for V2V communication to meet the requirement of delivering videos with QoE support over urban and highway VANET scenarios. In this section, we introduce a state-of-the-art protocol and mechanism to provide video dissemination over VANET. We also identify gaps in the literature, leading investigations to design an efficient platoon-based driving for video dissemination on VANETs. We divide the existing works into (i) routing; (ii) platoon-based driving; and (iii) data dissemination protocols.Amoroso et al. [27] introduced FD, which considers a sender-oriented multihop relay selection algorithm. Particularly, every node computes a Contention Window (CW) before forwarding a packet based on its current location and the neighbors’ location contained in the received packet. A lower CW means a vehicle closer to the destination, increasing the probability to reach the destination, while reducing the number of hops. Quadros [28] computed the CW based on video parameters, location, and QoE information. However, a VANET has a dynamic network topology with short contact time, which worsens the QoE of videos delivered via those protocols, due to frequent disconnections. Moreover, such protocols do not take metrics into account to increase the route duration during video transmission.Rehman et al. [26] proposed DBSC to establish a platoon, considering link quality estimation and geographical information in order to select vehicles to join the platoon. To estimate link quality, BDSC uses the number of HELLO messages successfully received (proportional to the total number sent) divided by a time interval. However, the BDSC protocol takes a long time to estimate link quality, i.e., 5 seconds, reducing the performance time of critical applications, such as video dissemination. Zhang et al. [29] proposed a platoon protocol that includes two components based on cost and efficiency to find the best vehicle to replicate data within the platoon and also to analyze possible mobility anomalies that could affect data transmission. Amoozadeh et al. [16] introduced a platoon management protocol that considers a centralized platoon coordination approach where the platoon leader coordinates all communications. Jia et al. [12] take into account vehicle mobility to establish a platoon, such as traffic flow, bandwidth, platoon speed, and size. However, these protocols must provide incentives for vehicles to participate in the platoon, since those vehicles change their travel time, fuel consumption, andCO2 emissions. In addition, Jia et al. consider that all vehicles within the platoon can communicate directly with each other, which means that the platoon communication length does not exceed one hop.Chen et al. [30] considered game theory to form groups and offer incentives for the group members. This work can be used for decision-making in routing protocols, forcing the cooperation among network nodes. It considers the storage size of each vehicle to decide which vehicles participate in data transmission. Gerla et al. [17] presented an approach using game theory to enforce forwarding nodes to apply network coding. However, such works do not consider platoon establishment for video transmission. In this sense, Lobato et al. [21] introduced the P2V protocol, which considers game theory for deciding about conflict situations between two or more platoons by the same vehicle during video transmissions. P2V selects platoon vehicles based on direction, speed, and distance. However, P2V does not consider the similarity between the candidate vehicle travel path and the platoon travel path, nor link quality for computing the reward function for each candidate vehicle to join the platoon. In addition, P2V does not consider any mechanism for avoiding selfish nodes, placing each platoon vehicle at predetermined distances to avoid packet loss, and evaluation in urban and highway scenarios.Based on the analysis of the related work, we conclude that platooning mitigates the influence of the short contact time in V2V communications to avoid communication flaws, delays, and packet loss during video transmissions. In this way, platoon vehicles can forward the video packets between source and destination vehicles, enabling video transmission with lower disconnections. However, the platoon protocol must select adequate vehicles to participate in the platoon for the video dissemination task. This involves being aware of QoE requirements and considering incentive mechanisms to reward vehicles for participating in the platoon.


## 3. Game Theory Approach for Platoon-Based Driving for Video Transmission over VANET (GT4P)

This section describes the GT4P protocol, which considers game theory to enforce the cooperation between vehicles in order to form an efficient video-based platoon. GT4P protocol uses monetary rewards/credits/tokens to allocate/pay for the platoon vehicles according to their efforts in the video transmission process with QoE support. GT4P takes into account direction, speed, vehicle travel path, RSSI, and distance to select the platoon members, as shown in Figure1. In addition, GT4P adjusts the distance between platoon members to reduce the effects of wireless communication on the packet loss. Platoon members collaborate with the video transmission by mitigating the effects of vehicle mobility with lower disconnections.Figure 1
Platoon-based driving scenario.


### 3.1. Network and System Model

We consider a VANET scenario composed ofn vehicles (nodes) moving on a multilane urban or highway area, where each vehicle has an individual identity (i∈[1,n]). These vehicles are represented in a dynamic graph G(V,E), where the vertices V={v1,⋯,vn} represent a finite set of vehicles, and edges E={e1,⋯,em} build a finite set of asymmetric wireless links between neighbor vehicles (vi). We denote N(vi)⊂V as a subset of all 1-hop neighbors within the radio range Rmax of a given vehicle vi. Each link ej has a weight value associated (w(ej)), i.e., link quality, such as the one provided by Received Signal Strength Indicator (RSSI).Each vehicle(vi) moves towards a certain direction (diri→) following a predefined travel path Pi (a set of roads connected by intersections) with speed si ranging between a minimum (smin) and a maximum (smax) speed limit. Each vehicle vi is aware of its own location Li(x,y) by means of positioning system, such as GPS. The location of the Destination Node (DN)⊂V is provided by any update localization service, as introduced by de Felice et al. [5]. Further, each vehicle vi is equipped with an IEEE 802.11p-compliant radio transceiver, where each vehicle can communicate with its neighbors N(vi). Each vehicle vi is also equipped with a multimedia encoder/decoder. For convenience of notation, we denoteSN⊂V (Source Node) as the node vi responsible for capturing video flows and transmitting them to the DN via multiple forwarding nodes (Fi⊂V).Regarding the video request, a safety alert message is transmitted through multihop communications. As introduced by de Felice et al. [5], the interested vehicle DN requests a video from a given vehicle SN via a video request message, which is forwarded towards the direction of the DN, not further on, and above all, not in other directions, since every message contains the SN and DN location information. The vehicle SN automatically switches its cameras on and starts recording and sharing the video content to the vehicle DN that can be located away. In this sense, the source vehicle SN must establish a platoon in order to use platoon vehicles for video dissemination.The Adaptive Cruise Control (ACC) system can use sensors to detect the distance between adjacent vehicles and autonomously maintain the speed and/or distance [15]. The platoon leader defines the speed Splatoon and the travel path Pplatoon for platoon members, exchanging commands about when to accelerate, slow down, or break. Through V2V wireless communication, a vehicle vi could get information on the platoon leader and also from the vehicle in front, in order to know in advance what is happening at the head of the platoon and react promptly, avoiding instabilities that might lead to vehicle collisions [13].The GT4P protocol considers two phases to form a platoon for video transmission. The communication phase finds a vehiclevi to join the platoon based on travel path, direction, speed, distance, and link quality, by computing the reward function for each candidate vehicle to join the platoon. The mobility phase is responsible for maintaining a platoon during the video transmission. The GT4P protocol has the following assumptions.(i)
A noncooperative and simultaneous game.(ii)
Selfishness means taking an action to maximize its own utility, which might lead to a given vehicle joining the platoon and subsequently leave it.(iii)
Every vehiclevi can participate in the platoon.(iv)
The platoon configuration is the column, also known as road trains.(v)
The platoon finishes after the video transmission.


### 3.2. GT4P Game Setting

We designed a noncooperative and simultaneous game, since vehiclesvi choose their strategies without waiting and have access to the strategies of their neighbors N(vi). The cooperative behavior is enforced by means of a rewarding function to give incentive for vehicles joining the platoon. We described the game as {V,A,U}, where V means the set of vehicles and A={a1,a2,a3,…,an} denotes the set of available strategies ai∈{0,1} for each vehicle vi.(i)
ai=1, action ofaccept to join the platoon.(ii)
ai=0, action ofdecline to join the platoon.The platoon vehicles have changing travel time, fuel consumption, andCO2 emissions, and thus GT4P gives a reward ui to enforce greater vehicle participation in the platoon. The set of reward functions of each vehicle vi is represented by U={u1,u2,u3,…un}, which depend on the set of strategies A. A given vehicle vi receives a reward ui and has a cost C by deciding for the strategy ai accepted. The cost C is related to the use of network resources, fuel consumption, CO2 emissions, and changes in the travel time. On the other hand, a given vehicle vi receives a reward ui equal to zero by choosing the strategy ai declined, as it will not be possible to join the platoon.The GT4P communication phase involves the transmission of the advertisement (adv), join, acknowledgment (ack), and end messages. Establishment of a platoon starts as soon as a vehicle SN receives a request to capture and send a video for a given vehicle DN via multiple forwarding nodes Fi (i.e., platoon members). In this sense, the vehicle SN broadcasts an adv message to its neighbors N(SN) to start the platoon formation and waits for the reception of join messages. The adv message contains SN speed SSN, direction dirSN→, and current location LDN(x,y), as well as DN location LDN(x,y) information.Upon receiving aadv message, each SN neighbor N(SN) must check if they are inside the SN Region of Interest (ROI). GT4P considers the ROI of vehicle SN as the region located between the vehicles SN and DN with vehicle vi moving on the same direction diri→ of vehicle SN. Hence, a given vehicle vi within the ROI of SN selects a strategy ai accepted, since the GT4P ensures that such vehicle will receive a fair reward to pay for the costs to join the platoon. Then, vehicle vi needs to announce its interest in joining the platoon by sending a join message, which contains current vehicle travel path Pi, location Li(x,y), speed si, and the RSSI w(ej) measured for the received adv message.For eachjoin reception, vehicle SN saves the values contained in the join message in a candidate list DC. As soon as the join reception finishes, vehicle SN computes the reward ui for each candidate in the list DC based on (1). Specifically, GT4P considers the following information for computing the reward ui, namely, source node SN and vehicle vi speed information (i.e., Si and SSN), the Euclidean distance (distSN,vi∈Rmax) between SN and vi, the link quality w(ej) measured by the vehicle vi in the reception of adv message, and the similarity between travel path Pi for vehicles SN and vi, called the Equality Index (EIi). The reward ui includes coefficients (α and β) to give different priority to each metric depending on the application requirements. The sum of the coefficients (α and β) is equal to 1. We consider that both metrics have the same degree of importance, and thus we set these values equal to 0.5, representing importance of 50%.(1)ui=mini∈C⁡α×dSN,vi-0.33×Rmax×max⁡SSN,Simin⁡SSN,Si+1+β×wejEIi×max⁡wej+0.01Equality IndexEIi∈[0,1] is computed based on (2), which takes into account the number of equal roads counti in both travel paths Pi and Pplatoon, and the total number of roads |Pplatoon| in the platoon travel path Pplatoon. In this way, identical travel paths result in Equality Index EIi equal to 1, while different travel paths result in Equality Index EIi equal to 0. This avoids selfish behavior by giving higher incentives for vehicles that change their travel path more without leaving the platoon, since such vehicles have higher fuel consumption and longer travel time.(2)EIi=countiPplatoonVehicleSN chooses the vehicle vi with the lowest reward ui value for joining the platoon. This is because such vehicle received the adv message with higher RSSI, closer to the ideal distance between platoon vehicles, as well as similar speed and travel path. We consider that each platoon vehicle must be separated by 2/3 of the radio range Rmax. Based on setup simulations, this distance is considered appropriate for video transmission with adequate QoE, since smaller distances increase the number of hops. On the other hand, higher distances cause disconnections due to radio range Rmax dynamically changed by shadowing effects, attenuation from buildings, etc. [31].Finally,SN sends an ack message to the vehicle vi chosen to join the platoon. In this way, the GT4P protocol provides video dissemination with adequate QoE, while avoiding that platoon vehicles have their travel time, fuel consumption, andCO2 emissions greatly changed. The GT4P protocol considers that platoon vehicles forward video packets between vehicles SN and DN, collaborating to video transmission with less disconnections. Once vehicle vi receives the ack message, it starts the mobility phases by changing its speed Si to the speed of SSN. Afterwards, vi becomes the new platoon leader (i.e., SN), and the algorithm continues until the packet reaches the DN.As soon as theDN joins the platoon, it has to send an end message for all platoon members. This message helps to keep all platoon members driving by the same travel path with the same speed. This message also contains all platoon members location, which helps to keep all platoon members with the same distance between each other. Specifically, platoon vehicles separated by distances longer than 2/3 of the radio range Rmax must have to adjust their distances, since long distance leads to packet losses due to the unreliability of the wireless channel. By doing this, GT4P reduces packet loss and disconnections caused by long distance between vehicles in a V2V wireless communication. Algorithm 1 introduces the main operations performed by GT4P that form a platoon.Algorithm 1:GT4P description.
( 1 )  begin ( 2 )  Event: Begining the Platoon (3) adv.Location ←Li(x,y) (4) adv.DNLocation LDN(x,y) (5) adv.Speed ←Si (6) adv.Direction ←dirSN→ (7) adv.Source ←vi (8) broadcast(adv) (9)  Event: Platoon Decision (10) compute ui, ∀i∈C (11) id ←min(ui),∀i∈C (12) ack.Speed ←SSN (13) unicast(ack, id) (14)  Receive: adv (15)  if  inside ROI  then (16) join.Source ←vi (17) join.RSSI ← RSSI (18) join.Path ←Pi (19) join.Location ←Li(x,y) (20) join.Speed ←Si (21) unicast(join, adv.Source) (22)  Receive: join (23) Add all information of join message into a candidate list DC (24)  Receive: ack (25)  v i become part of the platoon (26)  S i ← ack.Speed (27) Start the platoon with N(vi)


## 3.1. Network and System Model

We consider a VANET scenario composed ofn vehicles (nodes) moving on a multilane urban or highway area, where each vehicle has an individual identity (i∈[1,n]). These vehicles are represented in a dynamic graph G(V,E), where the vertices V={v1,⋯,vn} represent a finite set of vehicles, and edges E={e1,⋯,em} build a finite set of asymmetric wireless links between neighbor vehicles (vi). We denote N(vi)⊂V as a subset of all 1-hop neighbors within the radio range Rmax of a given vehicle vi. Each link ej has a weight value associated (w(ej)), i.e., link quality, such as the one provided by Received Signal Strength Indicator (RSSI).Each vehicle(vi) moves towards a certain direction (diri→) following a predefined travel path Pi (a set of roads connected by intersections) with speed si ranging between a minimum (smin) and a maximum (smax) speed limit. Each vehicle vi is aware of its own location Li(x,y) by means of positioning system, such as GPS. The location of the Destination Node (DN)⊂V is provided by any update localization service, as introduced by de Felice et al. [5]. Further, each vehicle vi is equipped with an IEEE 802.11p-compliant radio transceiver, where each vehicle can communicate with its neighbors N(vi). Each vehicle vi is also equipped with a multimedia encoder/decoder. For convenience of notation, we denoteSN⊂V (Source Node) as the node vi responsible for capturing video flows and transmitting them to the DN via multiple forwarding nodes (Fi⊂V).Regarding the video request, a safety alert message is transmitted through multihop communications. As introduced by de Felice et al. [5], the interested vehicle DN requests a video from a given vehicle SN via a video request message, which is forwarded towards the direction of the DN, not further on, and above all, not in other directions, since every message contains the SN and DN location information. The vehicle SN automatically switches its cameras on and starts recording and sharing the video content to the vehicle DN that can be located away. In this sense, the source vehicle SN must establish a platoon in order to use platoon vehicles for video dissemination.The Adaptive Cruise Control (ACC) system can use sensors to detect the distance between adjacent vehicles and autonomously maintain the speed and/or distance [15]. The platoon leader defines the speed Splatoon and the travel path Pplatoon for platoon members, exchanging commands about when to accelerate, slow down, or break. Through V2V wireless communication, a vehicle vi could get information on the platoon leader and also from the vehicle in front, in order to know in advance what is happening at the head of the platoon and react promptly, avoiding instabilities that might lead to vehicle collisions [13].The GT4P protocol considers two phases to form a platoon for video transmission. The communication phase finds a vehiclevi to join the platoon based on travel path, direction, speed, distance, and link quality, by computing the reward function for each candidate vehicle to join the platoon. The mobility phase is responsible for maintaining a platoon during the video transmission. The GT4P protocol has the following assumptions.(i)
A noncooperative and simultaneous game.(ii)
Selfishness means taking an action to maximize its own utility, which might lead to a given vehicle joining the platoon and subsequently leave it.(iii)
Every vehiclevi can participate in the platoon.(iv)
The platoon configuration is the column, also known as road trains.(v)
The platoon finishes after the video transmission.


## 3.2. GT4P Game Setting

We designed a noncooperative and simultaneous game, since vehiclesvi choose their strategies without waiting and have access to the strategies of their neighbors N(vi). The cooperative behavior is enforced by means of a rewarding function to give incentive for vehicles joining the platoon. We described the game as {V,A,U}, where V means the set of vehicles and A={a1,a2,a3,…,an} denotes the set of available strategies ai∈{0,1} for each vehicle vi.(i)
ai=1, action ofaccept to join the platoon.(ii)
ai=0, action ofdecline to join the platoon.The platoon vehicles have changing travel time, fuel consumption, andCO2 emissions, and thus GT4P gives a reward ui to enforce greater vehicle participation in the platoon. The set of reward functions of each vehicle vi is represented by U={u1,u2,u3,…un}, which depend on the set of strategies A. A given vehicle vi receives a reward ui and has a cost C by deciding for the strategy ai accepted. The cost C is related to the use of network resources, fuel consumption, CO2 emissions, and changes in the travel time. On the other hand, a given vehicle vi receives a reward ui equal to zero by choosing the strategy ai declined, as it will not be possible to join the platoon.The GT4P communication phase involves the transmission of the advertisement (adv), join, acknowledgment (ack), and end messages. Establishment of a platoon starts as soon as a vehicle SN receives a request to capture and send a video for a given vehicle DN via multiple forwarding nodes Fi (i.e., platoon members). In this sense, the vehicle SN broadcasts an adv message to its neighbors N(SN) to start the platoon formation and waits for the reception of join messages. The adv message contains SN speed SSN, direction dirSN→, and current location LDN(x,y), as well as DN location LDN(x,y) information.Upon receiving aadv message, each SN neighbor N(SN) must check if they are inside the SN Region of Interest (ROI). GT4P considers the ROI of vehicle SN as the region located between the vehicles SN and DN with vehicle vi moving on the same direction diri→ of vehicle SN. Hence, a given vehicle vi within the ROI of SN selects a strategy ai accepted, since the GT4P ensures that such vehicle will receive a fair reward to pay for the costs to join the platoon. Then, vehicle vi needs to announce its interest in joining the platoon by sending a join message, which contains current vehicle travel path Pi, location Li(x,y), speed si, and the RSSI w(ej) measured for the received adv message.For eachjoin reception, vehicle SN saves the values contained in the join message in a candidate list DC. As soon as the join reception finishes, vehicle SN computes the reward ui for each candidate in the list DC based on (1). Specifically, GT4P considers the following information for computing the reward ui, namely, source node SN and vehicle vi speed information (i.e., Si and SSN), the Euclidean distance (distSN,vi∈Rmax) between SN and vi, the link quality w(ej) measured by the vehicle vi in the reception of adv message, and the similarity between travel path Pi for vehicles SN and vi, called the Equality Index (EIi). The reward ui includes coefficients (α and β) to give different priority to each metric depending on the application requirements. The sum of the coefficients (α and β) is equal to 1. We consider that both metrics have the same degree of importance, and thus we set these values equal to 0.5, representing importance of 50%.(1)ui=mini∈C⁡α×dSN,vi-0.33×Rmax×max⁡SSN,Simin⁡SSN,Si+1+β×wejEIi×max⁡wej+0.01Equality IndexEIi∈[0,1] is computed based on (2), which takes into account the number of equal roads counti in both travel paths Pi and Pplatoon, and the total number of roads |Pplatoon| in the platoon travel path Pplatoon. In this way, identical travel paths result in Equality Index EIi equal to 1, while different travel paths result in Equality Index EIi equal to 0. This avoids selfish behavior by giving higher incentives for vehicles that change their travel path more without leaving the platoon, since such vehicles have higher fuel consumption and longer travel time.(2)EIi=countiPplatoonVehicleSN chooses the vehicle vi with the lowest reward ui value for joining the platoon. This is because such vehicle received the adv message with higher RSSI, closer to the ideal distance between platoon vehicles, as well as similar speed and travel path. We consider that each platoon vehicle must be separated by 2/3 of the radio range Rmax. Based on setup simulations, this distance is considered appropriate for video transmission with adequate QoE, since smaller distances increase the number of hops. On the other hand, higher distances cause disconnections due to radio range Rmax dynamically changed by shadowing effects, attenuation from buildings, etc. [31].Finally,SN sends an ack message to the vehicle vi chosen to join the platoon. In this way, the GT4P protocol provides video dissemination with adequate QoE, while avoiding that platoon vehicles have their travel time, fuel consumption, andCO2 emissions greatly changed. The GT4P protocol considers that platoon vehicles forward video packets between vehicles SN and DN, collaborating to video transmission with less disconnections. Once vehicle vi receives the ack message, it starts the mobility phases by changing its speed Si to the speed of SSN. Afterwards, vi becomes the new platoon leader (i.e., SN), and the algorithm continues until the packet reaches the DN.As soon as theDN joins the platoon, it has to send an end message for all platoon members. This message helps to keep all platoon members driving by the same travel path with the same speed. This message also contains all platoon members location, which helps to keep all platoon members with the same distance between each other. Specifically, platoon vehicles separated by distances longer than 2/3 of the radio range Rmax must have to adjust their distances, since long distance leads to packet losses due to the unreliability of the wireless channel. By doing this, GT4P reduces packet loss and disconnections caused by long distance between vehicles in a V2V wireless communication. Algorithm 1 introduces the main operations performed by GT4P that form a platoon.Algorithm 1:GT4P description.
( 1 )  begin ( 2 )  Event: Begining the Platoon (3) adv.Location ←Li(x,y) (4) adv.DNLocation LDN(x,y) (5) adv.Speed ←Si (6) adv.Direction ←dirSN→ (7) adv.Source ←vi (8) broadcast(adv) (9)  Event: Platoon Decision (10) compute ui, ∀i∈C (11) id ←min(ui),∀i∈C (12) ack.Speed ←SSN (13) unicast(ack, id) (14)  Receive: adv (15)  if  inside ROI  then (16) join.Source ←vi (17) join.RSSI ← RSSI (18) join.Path ←Pi (19) join.Location ←Li(x,y) (20) join.Speed ←Si (21) unicast(join, adv.Source) (22)  Receive: join (23) Add all information of join message into a candidate list DC (24)  Receive: ack (25)  v i become part of the platoon (26)  S i ← ack.Speed (27) Start the platoon with N(vi)


## 4. Evaluation

This section describes the methodology and metrics used to evaluate the quality level of transmitted videos through GT4P, FD, DBSC, and P2V protocols. Afterwards, we evaluate the impact of the density of different nodes on the QoE of videos transmitted in an urban scenario. Finally, we analyze the impact of videos with different characteristics transmitted in a highway scenario.


### 4.1. Scenario Description

We performed the simulation by using veins OMNeT++ framework, which implements the standard IEEE 802.11p protocol stack for vehicle communication and an obstacle model for signal attenuation. For the simulation of traffic and vehicle mobility, the Simulation of Urban Mobility (SUMO) is employed, i.e., an open source traffic simulator to model and to manipulate objects in the road scenario. This allows us to reproduce the desired vehicle movements with random cruise speed and V2V interactions based on empirical data. We conducted 33 simulation runs with different randomly generated seeds, and the results present values with a confidence interval of 95%.The vehicles are equipped with IEEE 802.11p radio (18 Mbit/s) with transmission power of1.6 mW, and thus these parameters, together with the two-ray ground propagation model, provide a transmission range Rmax of 250 m. We have different distances between vehicles DN and SN, where the maximum distance is 750 m to provide a hop count limit, such as proposed by de Felice et al. [5]. We conducted simulations by transmitting video sequences with different motion and complexity levels, i.e., Akiyo, Coastguard, Container, Hall, the initial 300 and 600 frames of highway, News, Paris, Sign, and Silent, downloaded from the video trace library [32]. Those videos have duration between 10 and 20 seconds, encoded with a H.264 codec at 300 kbps, 30 frames per second, and common intermediate format (352 x 288 pixels). The decoder uses a Frame-Copy method as error concealment, replacing each lost frame with the last received one to reduce frame loss and maintain video quality. We performed simulations in both an urban and a highway scenario.For the highway scenario, we considered the Luxembourg SUMO Traffic (LuST) [33], which provides 26 hours of mobility simulation for the city of Luxembourg using the traffic simulator SUMO. LuST has mobility information with multiple vehicles, routes, and road length. The vehicles used in the simulation share the same characteristics, such as size, mean, and standard deviation speed. We considered the vehicle for the highways of LuST scenario, which covers an area of 156km2 and 932 km of roads. Vehicle SN transmitted videos at a random time, following a Poisson distribution. For the urban scenario, we considered the Manhattan Grid scenario, composed of ten evenly spaced double-lane streets in an area of 1km2. The simulations run for 1000 seconds (s), where the vehicle SN sends the video at any time after the initial 100 s and before the last 100 s. We also considered the signal attenuation effects caused by buildings, where we assume that each block has a 80m x 80m obstacle, which represents high-rise buildings. In order to quantify the traffic evolution in this scenario, we defined the vehicle density between 200 and 400 vehicles/km2. The speed of the vehicles respects the limits imposed by the urban scenario, having a maximum of 13.9 m/s in each lane. Table 1 summarizes the main simulation parameters used for the Manhattan Grid and Luxembourg scenarios.Table 1
Simulation parameters.
Parameters Manhattan Scenario Luxembourg Scenario Simulation Area 1km2 155.95km2 Vehicle Speed 13.9 m/s Mean: 13.84 m/s (St.Dev: 5.27) Vehicle Density 200, 300, and 400 vehicles/km2 287034 vehicles Transmission Power 1.6 mW Transmission Range 250m Bit Rate 18 Mbit/s Data Message Size 1024 Bytes MAC Layer IEEE802.11p Video Sequences Akiyo, Container, Hall, Highway(300 Frames and 600 Frames), News, Paris, Sign, and Silent Video Characteristics H.264, 30fps, 352x288 pixelsIn terms of video quality evaluation, Quality of Service (QoS) schemes alone are not enough to assess the quality level of multimedia applications, because they fail in capturing subjective aspects of video content related to human experience [8]. In this context, QoE metrics overcome those limitations, and thus we consider a set of well-known QoE objective metrics, namely, structural similarity (SSIM) and Video Quality Metric (VQM). SSIM ∈[0,1] is based on a frame-by-frame assessment of three video components, i.e., luminance, contrast, and structural similarity. Higher SSIM value means better video quality. On the other hand, VQM ∈[0,4] measures the “perception damage” of video experienced based on features of the human visual system, namely, blurring, noise, color distortion, and distortion blocks. The VQM values being closer to zero mean a video with a better quality. We used the MSU Video Quality Measurement Tool (VQMT) to measure the SSIM and VQM values for each transmitted video.


### 4.2. Simulation Results for Urban Scenario

Figure2 shows the SSIM of videos transmitted via FD, BDSC, P2V, and GT4P protocols in an urban VANET scenario with different vehicle density. By analyzing the results of Figure 2, we conclude that SSIM of videos delivered by GT4P protocol increases as soon as vehicle density increases. This is because the protocol has more candidate vehicles to join the platoon, improving the platoon decision. In addition, the GT4P protocol delivered videos with SSIM 6%, 54%, and 44% higher compared to P2V, BDSC, and FD, respectively. This is because GT4P established a platoon by selecting vehicles with similar speed, appropriate distance between platoon members, similar travel path, and good link quality, and GT4P adjusts the distance between platoon members. This platoon selection provides a reliable V2V communication during the video transmission by mitigating the effects of vehicle mobility to avoid communication flaws, delays, void area, and packet loss.Figure 2
SSIM for videos transmitted by different platoon-based driving protocol in an urban scenario composed of different number of vehicles.FD has poor performance due to its behavior of selecting each platoon member; i.e., it selects the furthest candidate vehicle to join the platoon. Due to the unreliability of wireless channels, the most distant node might suffer from a bad connection, increasing the packet loss ratio for FD. On the other hand, BDSC has an even worse SSIM result, due to the link quality estimation performed by the platoon leader to select each platoon member, which takes 0.5 seconds. This increases the delay for BDSC decision-making and also leads to packet loss in a real-time video transmission. Finally, P2V delivered videos with high SSIM compared to FD and DBSC, since it establishes a platoon by selecting platoon members with similar speeds and appropriate distance to forward video packets, which reduces the packet loss. However, videos delivered by P2V have lower SSIM compared to GT4P, since P2V does not consider vehicle travel path and RSSI to select the platoon members. In addition, P2V does not enforce that platoon members keep a given distance between platoon members in order to enable a reliable V2V wireless communication.Figure3 shows the VQM for videos delivered via FD, BDSC, P2V, and GT4P protocols in an urban VANET scenario with different number of vehicles. In contrast to SSIM values, low VQM values means higher video quality level. The VQM results confirm the benefits of GT4P to transmit videos with QoE support, by establishing a platooning to avoid the effects of vehicle mobility on the QoE. For instance, GT4P transmitted video packets with a reduced frame loss rate, protecting priority frames in congestion and link error periods, since video streaming is composed of a sequence of frames with different importance based on user experience [34]. GT4P reduced the frame loss rate by 40%, 44%, and 4% compared to video transmission via FD, BDSC, and P2V, respectively.Figure 3
VQM for videos transmitted by different platoon-based driving protocol in an urban scenario composed of different number of vehicles.Figure4 shows the delay for videos delivered via FD, BDSC, P2V, and GT4P protocols in an urban VANET scenario with different vehicle density. We can conclude that BDSC has a higher delay compared to FD, P2V, and GT4P protocols, since in BDSC each platoon member computes link quality estimation, which takes 0.5 seconds, increasing the delay for decision-making, and also to forward video packets. On the other hand, FD, P2V, and GT4P protocols do not introduce any additional delay in the video transmission.Figure 4
Delay for videos transmitted by different platoon-based driving protocol in an urban scenario composed of different number of vehicles.We selected a random frame (i.e., Frame #150) from the Silent video sequence transmitted by each platoon protocol to show the impact of transmitting video streams from the users perspective, as displayed in Figure5. Specifically, Frame #150 from the Silent video sequence shows a news report in sign language, which could be related to a report on the road traffic conditions. This frame transmitted via GT4P has a low distortion compared to the original frame, by comparing Figures 5(a) and 5(b). On the other hand, the videos delivered by P2V, FD, and BDSC protocols are very deteriorated, as shown in Figures 5(c), 5(d), and 5(e), respectively. This is because this frame was lost, and also many previous ones, making it impossible to reconstruct based on the previously received frames. This makes the benefits of the GT4P protocol for video transmission evident.Figure 5
Frame #150 from the silent video transmitted via different platoon-based driving protocols in Manhattan grid scenario.
(a)
Original (b)
GT4P (c)
P2V (d)
FD (e)
BDSC


### 4.3. Simulation Results for Highway Scenario

Figure6 shows the SSIM for videos with different motion and complexity levels transmitted via FD, BDSC, P2V, and GT4P protocols in a highway VANET scenario. By analyzing the results of Figure 6, we conclude that GT4P delivered videos with high SSIM compared to FD, BDSC, and P2V, regardless of video motion and complexity levels. For instance, videos delivered by GT4P have SSIM values closer to 1. On the other hand, videos delivered by P2V, BDSC, and FD reduced the SSIM in 11%, 60% and 48% compared to GT4P, respectively. This is because GT4P established a platoon by selecting vehicles with similar speeds, appropriate distance between platoon members, similar travel path, and good link quality. These results confirm that GT4P also delivers video with good quality level in a highway scenario. The different video assessment values are due to the unique characteristics of each video sequence, where small differences in motion and complexity level can influence the obtained values [35]. In this way, it is important to perform the experiments with different video characteristics.Figure 6
SSIM for each video transmitted via different platoon-based driving protocol in a highway scenario.Figure7 shows the QoE measured by means of VQM for videos with different motion and complexity levels transmitted via FD, BDSC, P2V, and GT4P protocols in a highway VANET scenario. Once again, the VQM results confirm the benefits of GT4P to transmit videos with QoE support, by establishing a platoon to avoid the effects of vehicle mobility on the video quality.Figure 7
VQM for each video transmitted via different platoon-based driving protocol in a highway scenario.We selected a random frame (i.e., Frame #30) from the highway video sequence transmitted by each platoon protocol to show the impact of transmitting video streams from the standpoint of the end-user, as shown in Figure8. Specifically, Frame #30 from the highway video sequence was collected in a car driving in a highway. This frame transmitted via GT4P has the same quality compared to the original frame, which makes the benefits of the GT4P protocol for video transmission evident. On the other hand, this frame delivered by P2V has a few distortions compared to the original frame. Finally, the video delivered by FD and BDSC protocols are very deteriorated compared to the original frame, which makes it impossible to analyze anything from the frame. This is because this frame was lost, and also many previous ones, making it impossible to reconstruct based on the previously received frames.Figure 8
Frame #30 from highway video sequence transmitted via different platoon-based driving protocols in the Luxembourg scenario.
(a)
Original (b)
GT4P (c)
P2V (d)
FD (e)
BDSC


## 4.1. Scenario Description

We performed the simulation by using veins OMNeT++ framework, which implements the standard IEEE 802.11p protocol stack for vehicle communication and an obstacle model for signal attenuation. For the simulation of traffic and vehicle mobility, the Simulation of Urban Mobility (SUMO) is employed, i.e., an open source traffic simulator to model and to manipulate objects in the road scenario. This allows us to reproduce the desired vehicle movements with random cruise speed and V2V interactions based on empirical data. We conducted 33 simulation runs with different randomly generated seeds, and the results present values with a confidence interval of 95%.The vehicles are equipped with IEEE 802.11p radio (18 Mbit/s) with transmission power of1.6 mW, and thus these parameters, together with the two-ray ground propagation model, provide a transmission range Rmax of 250 m. We have different distances between vehicles DN and SN, where the maximum distance is 750 m to provide a hop count limit, such as proposed by de Felice et al. [5]. We conducted simulations by transmitting video sequences with different motion and complexity levels, i.e., Akiyo, Coastguard, Container, Hall, the initial 300 and 600 frames of highway, News, Paris, Sign, and Silent, downloaded from the video trace library [32]. Those videos have duration between 10 and 20 seconds, encoded with a H.264 codec at 300 kbps, 30 frames per second, and common intermediate format (352 x 288 pixels). The decoder uses a Frame-Copy method as error concealment, replacing each lost frame with the last received one to reduce frame loss and maintain video quality. We performed simulations in both an urban and a highway scenario.For the highway scenario, we considered the Luxembourg SUMO Traffic (LuST) [33], which provides 26 hours of mobility simulation for the city of Luxembourg using the traffic simulator SUMO. LuST has mobility information with multiple vehicles, routes, and road length. The vehicles used in the simulation share the same characteristics, such as size, mean, and standard deviation speed. We considered the vehicle for the highways of LuST scenario, which covers an area of 156km2 and 932 km of roads. Vehicle SN transmitted videos at a random time, following a Poisson distribution. For the urban scenario, we considered the Manhattan Grid scenario, composed of ten evenly spaced double-lane streets in an area of 1km2. The simulations run for 1000 seconds (s), where the vehicle SN sends the video at any time after the initial 100 s and before the last 100 s. We also considered the signal attenuation effects caused by buildings, where we assume that each block has a 80m x 80m obstacle, which represents high-rise buildings. In order to quantify the traffic evolution in this scenario, we defined the vehicle density between 200 and 400 vehicles/km2. The speed of the vehicles respects the limits imposed by the urban scenario, having a maximum of 13.9 m/s in each lane. Table 1 summarizes the main simulation parameters used for the Manhattan Grid and Luxembourg scenarios.Table 1
Simulation parameters.
Parameters Manhattan Scenario Luxembourg Scenario Simulation Area 1km2 155.95km2 Vehicle Speed 13.9 m/s Mean: 13.84 m/s (St.Dev: 5.27) Vehicle Density 200, 300, and 400 vehicles/km2 287034 vehicles Transmission Power 1.6 mW Transmission Range 250m Bit Rate 18 Mbit/s Data Message Size 1024 Bytes MAC Layer IEEE802.11p Video Sequences Akiyo, Container, Hall, Highway(300 Frames and 600 Frames), News, Paris, Sign, and Silent Video Characteristics H.264, 30fps, 352x288 pixelsIn terms of video quality evaluation, Quality of Service (QoS) schemes alone are not enough to assess the quality level of multimedia applications, because they fail in capturing subjective aspects of video content related to human experience [8]. In this context, QoE metrics overcome those limitations, and thus we consider a set of well-known QoE objective metrics, namely, structural similarity (SSIM) and Video Quality Metric (VQM). SSIM ∈[0,1] is based on a frame-by-frame assessment of three video components, i.e., luminance, contrast, and structural similarity. Higher SSIM value means better video quality. On the other hand, VQM ∈[0,4] measures the “perception damage” of video experienced based on features of the human visual system, namely, blurring, noise, color distortion, and distortion blocks. The VQM values being closer to zero mean a video with a better quality. We used the MSU Video Quality Measurement Tool (VQMT) to measure the SSIM and VQM values for each transmitted video.


## 4.2. Simulation Results for Urban Scenario

Figure2 shows the SSIM of videos transmitted via FD, BDSC, P2V, and GT4P protocols in an urban VANET scenario with different vehicle density. By analyzing the results of Figure 2, we conclude that SSIM of videos delivered by GT4P protocol increases as soon as vehicle density increases. This is because the protocol has more candidate vehicles to join the platoon, improving the platoon decision. In addition, the GT4P protocol delivered videos with SSIM 6%, 54%, and 44% higher compared to P2V, BDSC, and FD, respectively. This is because GT4P established a platoon by selecting vehicles with similar speed, appropriate distance between platoon members, similar travel path, and good link quality, and GT4P adjusts the distance between platoon members. This platoon selection provides a reliable V2V communication during the video transmission by mitigating the effects of vehicle mobility to avoid communication flaws, delays, void area, and packet loss.Figure 2
SSIM for videos transmitted by different platoon-based driving protocol in an urban scenario composed of different number of vehicles.FD has poor performance due to its behavior of selecting each platoon member; i.e., it selects the furthest candidate vehicle to join the platoon. Due to the unreliability of wireless channels, the most distant node might suffer from a bad connection, increasing the packet loss ratio for FD. On the other hand, BDSC has an even worse SSIM result, due to the link quality estimation performed by the platoon leader to select each platoon member, which takes 0.5 seconds. This increases the delay for BDSC decision-making and also leads to packet loss in a real-time video transmission. Finally, P2V delivered videos with high SSIM compared to FD and DBSC, since it establishes a platoon by selecting platoon members with similar speeds and appropriate distance to forward video packets, which reduces the packet loss. However, videos delivered by P2V have lower SSIM compared to GT4P, since P2V does not consider vehicle travel path and RSSI to select the platoon members. In addition, P2V does not enforce that platoon members keep a given distance between platoon members in order to enable a reliable V2V wireless communication.Figure3 shows the VQM for videos delivered via FD, BDSC, P2V, and GT4P protocols in an urban VANET scenario with different number of vehicles. In contrast to SSIM values, low VQM values means higher video quality level. The VQM results confirm the benefits of GT4P to transmit videos with QoE support, by establishing a platooning to avoid the effects of vehicle mobility on the QoE. For instance, GT4P transmitted video packets with a reduced frame loss rate, protecting priority frames in congestion and link error periods, since video streaming is composed of a sequence of frames with different importance based on user experience [34]. GT4P reduced the frame loss rate by 40%, 44%, and 4% compared to video transmission via FD, BDSC, and P2V, respectively.Figure 3
VQM for videos transmitted by different platoon-based driving protocol in an urban scenario composed of different number of vehicles.Figure4 shows the delay for videos delivered via FD, BDSC, P2V, and GT4P protocols in an urban VANET scenario with different vehicle density. We can conclude that BDSC has a higher delay compared to FD, P2V, and GT4P protocols, since in BDSC each platoon member computes link quality estimation, which takes 0.5 seconds, increasing the delay for decision-making, and also to forward video packets. On the other hand, FD, P2V, and GT4P protocols do not introduce any additional delay in the video transmission.Figure 4
Delay for videos transmitted by different platoon-based driving protocol in an urban scenario composed of different number of vehicles.We selected a random frame (i.e., Frame #150) from the Silent video sequence transmitted by each platoon protocol to show the impact of transmitting video streams from the users perspective, as displayed in Figure5. Specifically, Frame #150 from the Silent video sequence shows a news report in sign language, which could be related to a report on the road traffic conditions. This frame transmitted via GT4P has a low distortion compared to the original frame, by comparing Figures 5(a) and 5(b). On the other hand, the videos delivered by P2V, FD, and BDSC protocols are very deteriorated, as shown in Figures 5(c), 5(d), and 5(e), respectively. This is because this frame was lost, and also many previous ones, making it impossible to reconstruct based on the previously received frames. This makes the benefits of the GT4P protocol for video transmission evident.Figure 5
Frame #150 from the silent video transmitted via different platoon-based driving protocols in Manhattan grid scenario.
(a)
Original (b)
GT4P (c)
P2V (d)
FD (e)
BDSC


## 4.3. Simulation Results for Highway Scenario

Figure6 shows the SSIM for videos with different motion and complexity levels transmitted via FD, BDSC, P2V, and GT4P protocols in a highway VANET scenario. By analyzing the results of Figure 6, we conclude that GT4P delivered videos with high SSIM compared to FD, BDSC, and P2V, regardless of video motion and complexity levels. For instance, videos delivered by GT4P have SSIM values closer to 1. On the other hand, videos delivered by P2V, BDSC, and FD reduced the SSIM in 11%, 60% and 48% compared to GT4P, respectively. This is because GT4P established a platoon by selecting vehicles with similar speeds, appropriate distance between platoon members, similar travel path, and good link quality. These results confirm that GT4P also delivers video with good quality level in a highway scenario. The different video assessment values are due to the unique characteristics of each video sequence, where small differences in motion and complexity level can influence the obtained values [35]. In this way, it is important to perform the experiments with different video characteristics.Figure 6
SSIM for each video transmitted via different platoon-based driving protocol in a highway scenario.Figure7 shows the QoE measured by means of VQM for videos with different motion and complexity levels transmitted via FD, BDSC, P2V, and GT4P protocols in a highway VANET scenario. Once again, the VQM results confirm the benefits of GT4P to transmit videos with QoE support, by establishing a platoon to avoid the effects of vehicle mobility on the video quality.Figure 7
VQM for each video transmitted via different platoon-based driving protocol in a highway scenario.We selected a random frame (i.e., Frame #30) from the highway video sequence transmitted by each platoon protocol to show the impact of transmitting video streams from the standpoint of the end-user, as shown in Figure8. Specifically, Frame #30 from the highway video sequence was collected in a car driving in a highway. This frame transmitted via GT4P has the same quality compared to the original frame, which makes the benefits of the GT4P protocol for video transmission evident. On the other hand, this frame delivered by P2V has a few distortions compared to the original frame. Finally, the video delivered by FD and BDSC protocols are very deteriorated compared to the original frame, which makes it impossible to analyze anything from the frame. This is because this frame was lost, and also many previous ones, making it impossible to reconstruct based on the previously received frames.Figure 8
Frame #30 from highway video sequence transmitted via different platoon-based driving protocols in the Luxembourg scenario.
(a)
Original (b)
GT4P (c)
P2V (d)
FD (e)
BDSC


## 5. Conclusions

This article introduced GT4P protocol as a solution to form a platoon based on game theory for video transmission with adequate QoE. GT4P mitigates the problems related to frequent disconnections caused by high vehicle mobility by establishing a platoon based on vehicle direction, speed, distance, RSSI, and travel path. In addition, the GT4P protocol enforces that platoon vehicles keep a given distance to mitigate route failures and packet loss. The GT4P protocol considers a noncooperative and simultaneous game, where the cooperative behavior is enforced by means of a rewarding function to give incentive for vehicles to join the platoon. In this way, GT4P increases the connectivity between vehicles, reducing the packet loss during video transmission.From our performance evaluation analysis, we identified that the GT4P protocol delivered videos with QoE 10%, 60%, and 50% higher than videos delivered by P2V, BDSC, and FD, respectively. This is because GT4P establishes a platoon by taking into account vehicle direction, speed, distance, link quality, and travel path, which reduces the impact of vehicle mobility on the video transmission. Hence, simulation results show the efficiency of the GT4P compared to P2V, BDSC, and FD protocols to ensure video dissemination with satisfactory QoE in highway and urban scenarios.



---

*Source: 2414658-2018-06-20.xml*