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.
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 and CO2 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. Section 2 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, and CO2 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 Figure 1. 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.
3.1. Network and System Model
We consider a VANET scenario composed of vehicles (nodes) moving on a multilane urban or highway area, where each vehicle has an individual identity ( ). These vehicles are represented in a dynamic graph , where the vertices represent a finite set of vehicles, and edges build a finite set of asymmetric wireless links between neighbor vehicles . We denote as a subset of all 1-hop neighbors within the radio range of a given vehicle . Each link has a weight value associated (), i.e., link quality, such as the one provided by Received Signal Strength Indicator (RSSI).
Each vehicle moves towards a certain direction () following a predefined travel path (a set of roads connected by intersections) with speed ranging between a minimum () and a maximum () speed limit. Each vehicle is aware of its own location by means of positioning system, such as GPS. The location of the Destination Node is provided by any update localization service, as introduced by de Felice et al. [5]. Further, each vehicle is equipped with an IEEE 802.11p-compliant radio transceiver, where each vehicle can communicate with its neighbors . Each vehicle is also equipped with a multimedia encoder/decoder. For convenience of notation, we denote SN (Source Node) as the node responsible for capturing video flows and transmitting them to the via multiple forwarding nodes ( ).
Regarding the video request, a safety alert message is transmitted through multihop communications. As introduced by de Felice et al. [5], the interested vehicle requests a video from a given vehicle via a video request message, which is forwarded towards the direction of the , not further on, and above all, not in other directions, since every message contains the and location information. The vehicle automatically switches its cameras on and starts recording and sharing the video content to the vehicle that can be located away. In this sense, the source vehicle 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 and the travel path for platoon members, exchanging commands about when to accelerate, slow down, or break. Through V2V wireless communication, a vehicle 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 vehicle 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 vehicle 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 vehicles choose their strategies without waiting and have access to the strategies of their neighbors . The cooperative behavior is enforced by means of a rewarding function to give incentive for vehicles joining the platoon. We described the game as , where means the set of vehicles and denotes the set of available strategies for each vehicle .(i) , action of accept to join the platoon.(ii) , action of decline to join the platoon.
The platoon vehicles have changing travel time, fuel consumption, and CO2 emissions, and thus GT4P gives a reward to enforce greater vehicle participation in the platoon. The set of reward functions of each vehicle is represented by , which depend on the set of strategies . A given vehicle receives a reward and has a cost by deciding for the strategy accepted. The cost is related to the use of network resources, fuel consumption, emissions, and changes in the travel time. On the other hand, a given vehicle receives a reward equal to zero by choosing the strategy declined, as it will not be possible to join the platoon.
The GT4P communication phase involves the transmission of the advertisement (), , acknowledgment (), and messages. Establishment of a platoon starts as soon as a vehicle receives a request to capture and send a video for a given vehicle via multiple forwarding nodes (i.e., platoon members). In this sense, the vehicle broadcasts an message to its neighbors to start the platoon formation and waits for the reception of messages. The message contains speed , direction , and current location , as well as location information.
Upon receiving a message, each neighbor must check if they are inside the Region of Interest (ROI). GT4P considers the ROI of vehicle as the region located between the vehicles and with vehicle moving on the same direction of vehicle . Hence, a given vehicle within the ROI of selects a strategy accepted, since the GT4P ensures that such vehicle will receive a fair reward to pay for the costs to join the platoon. Then, vehicle needs to announce its interest in joining the platoon by sending a message, which contains current vehicle travel path , location , speed , and the RSSI measured for the received message.
For each reception, vehicle saves the values contained in the message in a candidate list . As soon as the reception finishes, vehicle computes the reward for each candidate in the list based on (1). Specifically, GT4P considers the following information for computing the reward , namely, source node and vehicle speed information (i.e., and ), the Euclidean distance ( ) between and , the link quality measured by the vehicle in the reception of message, and the similarity between travel path for vehicles and , called the Equality Index (). The reward 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%.
Equality Index is computed based on (2), which takes into account the number of equal roads in both travel paths and , and the total number of roads in the platoon travel path . In this way, identical travel paths result in Equality Index equal to 1, while different travel paths result in Equality Index 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.
Vehicle chooses the vehicle with the lowest reward value for joining the platoon. This is because such vehicle received the 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 . 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 dynamically changed by shadowing effects, attenuation from buildings, etc. [31].
Finally, sends an message to the vehicle 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, and CO2 emissions greatly changed. The GT4P protocol considers that platoon vehicles forward video packets between vehicles and , collaborating to video transmission with less disconnections. Once vehicle receives the message, it starts the mobility phases by changing its speed to the speed of . Afterwards, becomes the new platoon leader (i.e., ), and the algorithm continues until the packet reaches the .
As soon as the joins the platoon, it has to send an 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 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.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||
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 of mW, and thus these parameters, together with the two-ray ground propagation model, provide a transmission range of m. We have different distances between vehicles and , 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 156 km2 and 932 km of roads. Vehicle 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 1 km2. The simulations run for 1000 seconds (s), where the vehicle 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.
In 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 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 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
Figure 2 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.
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.
Figure 3 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 4 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.
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 Figure 5. 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.
(a) Original
(b) GT4P
(c) P2V
(d) FD
(e) BDSC
4.3. Simulation Results for Highway Scenario
Figure 6 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 7 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.
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 Figure 8. 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.
(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.
Data Availability
The data used to support the findings of this study are available from the corresponding author upon request.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
The author Denis Rosário would like to thank the National Council for Scientific and Technological Development (CNPq) for the financial support through Grant 431474/2016-8. The author Leandro Villas would like to thank the São Paulo Research Foundation (FAPESP) for the financial support through Grant 2015/07538-1.