# Transmission Opportunities: A New Approach to Improve Quality in V2V Networks

Authors: Carlos Rafael Guerber; Eduardo Luis Gomes; Mauro Sérgio Pereira Fonseca; Anelise Munaretto; Thiago Henrique Silva
Journal: Wireless Communications and Mobile Computing
 (2019)

---

## Abstract

In vehicular ad hoc networks (VANETs), vehicle-to-vehicle (V2V) communication occurs opportunistically due to frequent node mobility and intermittent contact time. In this scenario, the performance evaluation of forwarding protocols by the use of the existing resources in the network is an open challenge, given the different strategies that the routing protocols adopt for choosing the next hop. Through the data analysis of three real taxis’ mobility traces and varying the radio signal range from 50 meters to 1.000 meters, we could contribute to the analysis of the existence of single-radio transmission opportunities and their quantification and classification considering either serial or parallel. Additionally, the inventory analysis of communication resources is done by evaluating the data transmission rate and the beacon overhead impact and by the proposal of a new metric (TOppMi) for the performance evaluation of forwarding protocols. We discuss the impact on forwarding protocols by the appropriate use of this metric, and we show that this metric can be used either for performance evaluation of forwarding protocols or to improve the quality over the consumption of resources in vehicular ad hoc networks. Our metric can obtain the maximum theoretical resource usage independent of the scenario. Either for Rome or San Francisco or Shanghai, as the radio’s signal range increases, the maximum theoretical amount of resources also increases. We could also show that, for the three scenarios, the beacon overhead has an insignificant impact over the total theoretical data inventory available. Furthermore, we classify the vehicles according to the contact time between them.


---

## Body

## 1. Introduction

Over the last few years, data transport and ad hoc messaging applications have been proposed in scenarios where the conventional communication infrastructure does not apply or could fail [1].These scenarios include vehicular ad hoc networks (VANETs), which use the IEEE 802.11p standard technology for wireless communication between vehicles [2]. Such standardization presents important specifications to develop communication protocols in these environments, such as the radio signal range and the data transmission rate. There are two main ways to a vehicle interface in VANETs, vehicle-to-infrastructure (V2I) communication, and vehicle-to-vehicle (V2V) communication [2, 3].VANETs provide an intelligent way to make the transportation of people and loads safer, efficient, and comfortable. These networks allow vehicles to share a certain volume of local traffic information via hop-by-hop communication [3]. Therefore, VANETs are an important and promising technology able to support most of the applications for the Internet of Vehicles (IoV) [4], Internet of Things (IoT) [5, 6], and mainly for Intelligent Transport Systems (ITSs). These applications include safety, comfort, and efficiency [7, 8]. Safety applications have their design made to aware drivers along the road, such as warning the vehicle in case of emergency, car crashes, or problems on the runway [3, 7, 8]. Comfort application design must improve the experience of the driver and passengers along the journey, such as music downloads, games, or video downloads [9, 10]. Efficiency applications help in reducing the fuel consumption and travel time. Additionally, it can promote intelligent traffic flow control and vehicle tracking [3, 9]. To support these applications, new forwarding protocols design must be aware of adequately consuming the available resources throughout the network [9–12]. Therefore, to outcome the resource consumption and improve the quality in the V2V network, a new metric is necessary for doing that.The main resources in a V2V network are vehicles [13, 14]. Any event, such as data transmission over an application, is only possible due to the communication between them. Nevertheless, the frequent mobility of vehicles is one important characteristic, which interferes with the developing forwarding protocols (we have decided to use forwarding instead of routing nomenclature; routing relates to end-to-end path, and due to intermittent connection of nodes often, a full path is difficult to obtain. Forwarding to destination occurs hop-to-hop.) for VANETs [15]. Then, mobility is a high impact factor and makes the linking between vehicles highly dynamic and its communication becomes opportunistic [14, 16]. Therefore, depending on the scenario, the radio signal range is an important aspect, which influences variables such as vehicle contact time and the density of the links between vehicles [17–20].We understand that the contact time between vehicles indicates the quality of the communication links (i.e., links that last longer have greater possibility of exchanging messages and can transmit more data). Likewise, the rate of data transmission along with the contact time suggests the amount of data a vehicle could transfer. Depending on the data rate, signal attenuation, and interference conditions of the environment, it is possible to determine the type of application that the network supports (e.g., security applications, entertainment applications, and comfort applications) [5, 7, 8, 15]. The link density also demonstrates the network communication conditions. The denser it appears, the greater is the number of vehicles as well as the communication options between them. Taking into account these critical communication options, we have introduced in this research our concept of transmission opportunities to improve the understanding of V2V interactions.In this paper, we do not create a new forwarding metric to a routing protocol. Instead, our motivation is to explore the transmission opportunities concept as a metric to evaluate the resource capacity available over the network. Our proposal can also evaluate any VANET independently of the scenario or the forwarding protocol design. Often in their strategies, forwarding protocols focus on improving the message delivery rates or reducing the relative overhead, among other performance evaluation metrics. Nevertheless, they do not assess whether their strategy uses transmission opportunities resources properly for the intended application. Thereby, our proposal can serve as a tool for new or existing forwarding protocols to evaluate how much they have reached their upper bound. Therefore, we could be able to evaluate any protocol at any scenario through summing data rate and via transmission opportunity usage. Therewith, we offer a new way to evaluate the quality of routing protocols against the number of resources that the forwarding strategy consumes. We call these resources, the transmission opportunities.In our proposal, we do not cover the use of multiple radios on the loop. We consider analyzing transmission opportunities from the perspective of one antenna. Thereby, we can observe that a sender can have just one transmission opportunity at the same time (e.g., unicast communication) or several transmission opportunities at the same time (e.g., multicast communication). Thus in this work, we concentrate our efforts on evaluating three different realistic taxis scenarios to demonstrate the number of resources over the network. We did not concern about evaluating any forwarding strategy by now (i.e., routing protocol).Therefore, to demonstrate that the interaction between sending vehicles with their transmission opportunities is the major resource on vehicular networks, we focus on four goals. (1) We classify and quantify transmission opportunities to calculate the theoretical upper bound data volume that the network supports, by varying the radio signal range. (2) We verify the impact of data consumption caused by beacon overhead. (3) We classify the vehicles by contact time and propose this feature as a quality indicator when relating the contact time to the maximum theoretical capacity in transmitting data packets according to each class. (4) Finally, we present the proposal of a new metric for performance evaluation of routing protocols (i.e., routing protocols) for VANETs.With a review of the literature, we discuss the main metrics used by forwarding protocols. In addition, we propose a new metric and its application to assist the development of forwarding protocols in V2V networks through the evaluation of three real taxis mobility traces from the cities of Rome, San Francisco, and Shanghai. Hence, the main contributions of this study are as follows:(i)
Data analysis of existing transmission opportunities and their quantification and classification considering both transmission opportunities either serial or parallel. We discuss how the forwarding protocols for message dissemination must satisfy the condition of density variation caused by the dynamic formation of links between vehicles (Section4).(ii)
The inventory analysis of communication resources by evaluating the data transmission rate and the beacon overhead impact of each vehicle over this inventory. We have analyzed the transmission opportunities between vehicles in order to demonstrate their importance to the forwarding process and we state that contact time is an indicator of link quality to provide a better choice of transmission opportunities on new forwarding protocol design. Therefore, we have classified vehicles into eight Quality of Time (QoT) classes (Sections5.2, 5.3, and 5.4).(iii)
The proposal of a new metric (TOppMi) for the performance evaluation of forwarding protocols (Section 6).We have organized the remainder of this study as follows. Next, we present (Section2) the related works followed by a description of the real traces features (Section 3), the dataset and the methodology used to extract the analyzed data. Next, we introduce our concept of transmission opportunities (Section 4). After that, we show and discuss the results (Section 5) and present the proposal of our metric, as well its application (Section 6). Finally, we present conclusions and future work (Section 7).


## 2. Related Work

This section has two parts. First, we show other works that had used the same traces that we have used in this research but with different goals in the analysis of vehicles mobility. Second, we present some of the main forwarding protocols applied for delay and disruption-tolerant networks (DTNs) and VANETs specifically to show which type of performance metric they usually apply.


### 2.1. Study of Real Taxi Traces and Data Analysis

Chen et al. [13] studied the evolution of topologies in vehicular networks by analyzing the stability and variation of the connected components over time to propose directions that help in the design of forwarding protocols. Huang et al. [14] and Huang et al. [15] extracted a model of mobility from the real bases of vehicles to capture microscopic and macroscopic features and generate synthetic models for simulations.Cunha et al. [16] sought to define how effective it is to analyze a vehicular network through social perception and to use it as a way to transmit messages in vehicular networks. In their other work, Cunha et al. [17] had used several techniques to extract social properties and social behaviors of the vehicles and discovered the existence of common interests and regularity in the encounters between vehicles. In another study, Cunha et al. [18] investigated whether it is possible to find social properties in vehicular networks and concluded that it is possible to achieve, as also to apply such properties in proposing forwarding protocols.However, none of the related papers had analyzed the transmission opportunities present in the movement of taxis and the individual view of a vehicle regarding these opportunities. They also had not analyzed the importance of transmission opportunities as a metric for calculating resources consumption in vehicular networks. We have addressed these points in this article.


### 2.2. Performance Metrics of Forwarding Strategies and Forwarding Protocols

We have chosen forwarding protocols that use some of the different forwarding strategies available (we have assumed that a forwarding strategy is how the sender node uses the information obtained from the network to choose the path to forward data packets to reach the destination). These strategies, commonly applied on forwarding protocol designing, have as their basis the following: flooding, probability, social behavior, topology, and geographic features. All these protocols are beacon-based. Therefore, there are different metrics (we have assumed that the performance metric is a measure applied to analyze the performance of a forwarding protocol strategy) to evaluate the forwarding protocols in the literature. Then, for the present article, we focus on showing message forwarding protocols for VANETs, which use different types of routing strategies. Additionally, we show different types of performance evaluation metrics often used to evaluate these protocols.It is common to use the Epidemic protocol as a benchmark for the evaluation of forwarding proposals [19, 20]. Epidemic is a flooding forwarding protocol that uses as strategy to transmit messages the idea of spreading a disease. A node receiving a message forwards it to all its neighbors, which repeat this process. This cycle repeats until the message reaches its destination or until reaching a maximum number of hops. Epidemic uses evaluation delivery rate, latency, buffer utilization, and number of hops [21]. Similarly, it is common to use Prophet as a baseline to evaluate new proposals of forwarding protocols [19, 20]. Prophet uses a probabilistic forwarding strategy that indicates how likely a node will be able to deliver a message to a certain destination. This protocol takes into account the history of previous contacts [22].BubbleRap is a forwarding protocol that uses social network measures to choose which nodes should relay a message. It first detects communities of nodes and then uses a centrality measure to classify a node and make this node the main hub of a community. If a destination node belongs to its community, the node with higher degree in the community receives the message. However, if a destination node belongs to another community, the main hub of all other known communities will receive a copy of the message [23].TDOR is a trajectory-driven opportunistic forwarding protocol applied for sparse VANETs. It makes use of GPS information on the onboard vehicle navigation system to help with data transmission. It selects the relay node based on the proximity to the trajectory, and it aims to provide reliable and efficient message delivery. The performance metrics applied to evaluate TDOR protocol were delivery ratio, average delivery latency, and overhead ratio. Then, results show TDOR as well-done geographic forwarding protocol and achieves much lower routing overhead for comparable delivery ratio [24].M-GEDIR is a multimetric geographic routing for next-hop selection. It selects next-hop vehicles from dynamic forwarding regions and considers major parameters of urban environments including received signal strength, the future position of vehicles, and critical area vehicles at the border of transmission range, apart from speed, distance, and direction. For M-GEDIR evaluation carrying out simulations on realistic vehicular traffic environments, authors have used end-to-end delay, link failure, and throughput performance metrics [25].CARTOON [26] is a context-aware routing protocol for opportunistic networks based on the concept of context-adaptation. Instead of employing a simple adaptation layer to detect the network context and manipulate parameter values accordingly, this protocol takes the concept of adaptation to its core, by being able to change the message dissemination mode. CARTOON can decide between using probabilistic dissemination, or an epidemic one. The authors have evaluated this protocol in five different scenarios, and they used as performance metrics the delivered message ratio, the average end-to-end delay, and the number of delivered messages.GeOpps-N is a hybrid topology-based forwarding protocol for communications between buses and operation control centers in a public transportation system. This protocol works over VANETs with low-density scenarios. GeOpps-N searches for relaying nodes, which can efficiently transport or relay the data to the closest RSU. For protocol evaluation, the authors have used delivery ratio, end-to-end delay, and overhead ratio metrics [27].Abuashour and Kadoch [28] presented three forwarding protocols to VANETs. CBLTR is a cluster-based lifetime routing, which aims to increase route stability and average throughput in a bidirectional segment scenario. IDVR is an intersection dynamic forwarding protocol that also aims to increase route stability and average throughput but additionally targets to reduce end-to-end delay in a grid topology. CORA is a control overhead reduction forwarding protocol, which aims to reduce the control overhead messages in the clusters by developing a new mechanism to calculate the optimal numbers of the control overhead messages between the cluster members and the cluster head. In order to evaluate the protocols, the authors have used average throughput, end-to-end delay, and the number of messages performance metrics.Kaur [29] proposed two geographic routing protocols. GPSR is a greedy perimeter stateless forwarding protocol, based on the greedy forwarding technique. A-STAR is an anchor-based street and traffic-aware routing. Both were designed to work over real city maps. In terms of performance analysis, the authors have evaluated throughput, packet delivery ratio, packet loss, and average delay.EGSR is a traffic-aware forwarding protocol based on ant colony optimization to find a route that has optimum network connectivity. The protocol is road-based, traffic-aware, and not sensitive to the movement of nodes. By defining an area around every junction, called an anchor area, vehicles in this area cooperate to forward messages. To evaluate this forwarding protocol, the authors have used performance metrics delivery ratio, overhead ratio, and packet loss [30].PA-GPSR is a path-aware geographic perimeter stateless forwarding protocol for VANETs. This protocol applies a table to select the best path and bypass the nodes that have delivered such previous packets in the recovery mode. It can eliminate packet routing loops avoiding the delivery of the same packet to the same neighbor node. In terms of performance analysis, the authors have evaluated the packet loss rate, end-to-end delay, and network yield [31].We have just shown some different and commonly used forwarding strategies often applied in several forwarding protocols designs. Table1 presents a summarization of all forwarding protocols and performance metrics used to evaluate them. It is possible to realize that none of the forwarding protocols, neither the most recent (e.g. TDOR, M-GEDIR, and CARTOON) nor the classic benchmarks (e.g., EPIDEMIC or PROPHET), had their evaluation made with the characteristics of the metric proposed in this article.Table 1
Summary of forwarding protocols, their forwarding, and performance metrics used for evaluation.
Paper
Forwarding protocol
Forwarding strategy
Tool
Scenario
Performance metrics
21
Epidemic
Flooding
NS2 and Monarch
Synthetic (nodes randomly placed)
Delivery rate, latency, and number of hops
22
Prophet
Probabilistic
Own custom simulator + random way point
Synthetic (nodes randomly placed)
Average received messages, average forwarded messages, and average delay
23
BubbleRap
Social behavior
HaggleSim emulator
Real traces dataset (Infocom05, HongKong, Cambridge, and Infocom06)
Delivery ratio and total cost
24
TDOR
Geographic (GPS)
ONE simulator
Helsink city map (artificial-nodes randomly placed)
Delivery ratio, average delivery latency, and overhead ratio
25
M-GEDIR
Multi strategies (geographic, signal strength, speed, distance, and position)
NS2 and MOVE
Synthetic (nodes randomly placed)
End-to-end delay, link failure, and throughput
26
CARTOON
Adaptive in flooding or probabilistic
ONE simulator
Real traces dataset (UMass DieselNet, ZebraNet, WDM, iMotes, and Dartmouth)
Delivered message ratio, average end-to-end delay, and number of delivered messages
27
GeOpps-N
Topology-based
OMNET++, MOVE, SUMO, VEIS
OSM database
Delivery ratio, end-to-end delay, and overhead ratio
28
CBLTR, IDVR and CORA
Cluster-based (social behavior) and intersection-based (geographic)
SUMO e MATLAB
Synthetic (nodes and obstacles custom placed)
Average throughput, end-to-end delay, and number of messages
29
A-STAR and GPSR
Geographic
SUMO
Bathinda city map-OSM database
Throughput, delivery ratio, packet loss, and average delay
30
EGSR
Position-based and social behavior
OMNET++ and SUMO
Manhattan city map (nodes randomly placed)
Delivery ratio, overhead ratio, and packet loss
31
PA-GPSR
Geographic
NS3 and SUMO
Synthetic (nodes and obstacles custom placed)
Packet loss rate, end-to-end delay, and network yieldTherefore, there are several forwarding strategies and performance evaluation metrics. Independent of the forwarding strategy, a metric must evaluate its performance. However, none of previously cited metric makes use of the resources consumption, transmission opportunities, or contact time to evaluate the quality of any forwarding strategy. In this study, we have addressed this issue. Table2 shows the state-of-art of the performance evaluation metrics for forwarding protocols against our proposal’s novelty.Table 2
Summary of forwarding protocols’ performance evaluation metrics.
Metric
Description
Benchmark unit
Created messages (CM)
Total number of created messages. Do not include replication.
Number
Relayed messages (RM)
Total number of successful transmissions between nodes.
Number
Aborted messages (AM) and packet loss
Total number of transmissions messages that fail before finished. Aborted messages occur due to disconnection during the transmission between nodes.
Number
Started messages (SM)
Total number of transmissions started. SM = (RM) + (AM).
Number
Dropped messages
Total number of dropped messages from nodes buffers before delivery to final destination.
Number
Delivered messages (DM) or number of messages
Total number of successful delivered messages in final target.
Number
Messages delivery ratio (MDR)
Messages delivery probability. MDR = ((1.0∗ DM)/CM).
Percentage (%)
Overhead ratio (OR)
An assessment of bandwidth efficiency. It is the number of created copies per delivered message. It amounts the number of replicas necessary to perform a successful delivery.
Percentage (%) number
Latency average
Latency average messages delay from creation to delivery.
Seconds
Hop count average
Average number of hops between source and destination.
Number
Buffer time average
Average time that messages stay in the buffer at each node.
Number
Buffer size occupancy
Buffer size occupancy average at each node.
Bytes
RTT average
Round-trip time average. Average time from creation to confirmation of delivery.
Seconds
End-to-end delay
Time taken for a message transmission across a network from source to destination.
Seconds
Throughput
The number of transactions per second an application can handle, the amount of transactions produced over time during a test.
Transactions per second
Link failure
The period of consecutive packet loss that can last for many seconds, followed by a change in delay after the link is reestablished.
Seconds
Transmission opportunity (TOpp)
The ratio between the total amounts of resources that a protocol could have to the actual number of resources used by this protocol. This metric can evaluate the resource consumption such as the number of transmission opportunities, contact time duration, or data transfer in the network.
Percentage (%) time (seconds); data stream (Mbps)


## 2.1. Study of Real Taxi Traces and Data Analysis

Chen et al. [13] studied the evolution of topologies in vehicular networks by analyzing the stability and variation of the connected components over time to propose directions that help in the design of forwarding protocols. Huang et al. [14] and Huang et al. [15] extracted a model of mobility from the real bases of vehicles to capture microscopic and macroscopic features and generate synthetic models for simulations.Cunha et al. [16] sought to define how effective it is to analyze a vehicular network through social perception and to use it as a way to transmit messages in vehicular networks. In their other work, Cunha et al. [17] had used several techniques to extract social properties and social behaviors of the vehicles and discovered the existence of common interests and regularity in the encounters between vehicles. In another study, Cunha et al. [18] investigated whether it is possible to find social properties in vehicular networks and concluded that it is possible to achieve, as also to apply such properties in proposing forwarding protocols.However, none of the related papers had analyzed the transmission opportunities present in the movement of taxis and the individual view of a vehicle regarding these opportunities. They also had not analyzed the importance of transmission opportunities as a metric for calculating resources consumption in vehicular networks. We have addressed these points in this article.


## 2.2. Performance Metrics of Forwarding Strategies and Forwarding Protocols

We have chosen forwarding protocols that use some of the different forwarding strategies available (we have assumed that a forwarding strategy is how the sender node uses the information obtained from the network to choose the path to forward data packets to reach the destination). These strategies, commonly applied on forwarding protocol designing, have as their basis the following: flooding, probability, social behavior, topology, and geographic features. All these protocols are beacon-based. Therefore, there are different metrics (we have assumed that the performance metric is a measure applied to analyze the performance of a forwarding protocol strategy) to evaluate the forwarding protocols in the literature. Then, for the present article, we focus on showing message forwarding protocols for VANETs, which use different types of routing strategies. Additionally, we show different types of performance evaluation metrics often used to evaluate these protocols.It is common to use the Epidemic protocol as a benchmark for the evaluation of forwarding proposals [19, 20]. Epidemic is a flooding forwarding protocol that uses as strategy to transmit messages the idea of spreading a disease. A node receiving a message forwards it to all its neighbors, which repeat this process. This cycle repeats until the message reaches its destination or until reaching a maximum number of hops. Epidemic uses evaluation delivery rate, latency, buffer utilization, and number of hops [21]. Similarly, it is common to use Prophet as a baseline to evaluate new proposals of forwarding protocols [19, 20]. Prophet uses a probabilistic forwarding strategy that indicates how likely a node will be able to deliver a message to a certain destination. This protocol takes into account the history of previous contacts [22].BubbleRap is a forwarding protocol that uses social network measures to choose which nodes should relay a message. It first detects communities of nodes and then uses a centrality measure to classify a node and make this node the main hub of a community. If a destination node belongs to its community, the node with higher degree in the community receives the message. However, if a destination node belongs to another community, the main hub of all other known communities will receive a copy of the message [23].TDOR is a trajectory-driven opportunistic forwarding protocol applied for sparse VANETs. It makes use of GPS information on the onboard vehicle navigation system to help with data transmission. It selects the relay node based on the proximity to the trajectory, and it aims to provide reliable and efficient message delivery. The performance metrics applied to evaluate TDOR protocol were delivery ratio, average delivery latency, and overhead ratio. Then, results show TDOR as well-done geographic forwarding protocol and achieves much lower routing overhead for comparable delivery ratio [24].M-GEDIR is a multimetric geographic routing for next-hop selection. It selects next-hop vehicles from dynamic forwarding regions and considers major parameters of urban environments including received signal strength, the future position of vehicles, and critical area vehicles at the border of transmission range, apart from speed, distance, and direction. For M-GEDIR evaluation carrying out simulations on realistic vehicular traffic environments, authors have used end-to-end delay, link failure, and throughput performance metrics [25].CARTOON [26] is a context-aware routing protocol for opportunistic networks based on the concept of context-adaptation. Instead of employing a simple adaptation layer to detect the network context and manipulate parameter values accordingly, this protocol takes the concept of adaptation to its core, by being able to change the message dissemination mode. CARTOON can decide between using probabilistic dissemination, or an epidemic one. The authors have evaluated this protocol in five different scenarios, and they used as performance metrics the delivered message ratio, the average end-to-end delay, and the number of delivered messages.GeOpps-N is a hybrid topology-based forwarding protocol for communications between buses and operation control centers in a public transportation system. This protocol works over VANETs with low-density scenarios. GeOpps-N searches for relaying nodes, which can efficiently transport or relay the data to the closest RSU. For protocol evaluation, the authors have used delivery ratio, end-to-end delay, and overhead ratio metrics [27].Abuashour and Kadoch [28] presented three forwarding protocols to VANETs. CBLTR is a cluster-based lifetime routing, which aims to increase route stability and average throughput in a bidirectional segment scenario. IDVR is an intersection dynamic forwarding protocol that also aims to increase route stability and average throughput but additionally targets to reduce end-to-end delay in a grid topology. CORA is a control overhead reduction forwarding protocol, which aims to reduce the control overhead messages in the clusters by developing a new mechanism to calculate the optimal numbers of the control overhead messages between the cluster members and the cluster head. In order to evaluate the protocols, the authors have used average throughput, end-to-end delay, and the number of messages performance metrics.Kaur [29] proposed two geographic routing protocols. GPSR is a greedy perimeter stateless forwarding protocol, based on the greedy forwarding technique. A-STAR is an anchor-based street and traffic-aware routing. Both were designed to work over real city maps. In terms of performance analysis, the authors have evaluated throughput, packet delivery ratio, packet loss, and average delay.EGSR is a traffic-aware forwarding protocol based on ant colony optimization to find a route that has optimum network connectivity. The protocol is road-based, traffic-aware, and not sensitive to the movement of nodes. By defining an area around every junction, called an anchor area, vehicles in this area cooperate to forward messages. To evaluate this forwarding protocol, the authors have used performance metrics delivery ratio, overhead ratio, and packet loss [30].PA-GPSR is a path-aware geographic perimeter stateless forwarding protocol for VANETs. This protocol applies a table to select the best path and bypass the nodes that have delivered such previous packets in the recovery mode. It can eliminate packet routing loops avoiding the delivery of the same packet to the same neighbor node. In terms of performance analysis, the authors have evaluated the packet loss rate, end-to-end delay, and network yield [31].We have just shown some different and commonly used forwarding strategies often applied in several forwarding protocols designs. Table1 presents a summarization of all forwarding protocols and performance metrics used to evaluate them. It is possible to realize that none of the forwarding protocols, neither the most recent (e.g. TDOR, M-GEDIR, and CARTOON) nor the classic benchmarks (e.g., EPIDEMIC or PROPHET), had their evaluation made with the characteristics of the metric proposed in this article.Table 1
Summary of forwarding protocols, their forwarding, and performance metrics used for evaluation.
Paper
Forwarding protocol
Forwarding strategy
Tool
Scenario
Performance metrics
21
Epidemic
Flooding
NS2 and Monarch
Synthetic (nodes randomly placed)
Delivery rate, latency, and number of hops
22
Prophet
Probabilistic
Own custom simulator + random way point
Synthetic (nodes randomly placed)
Average received messages, average forwarded messages, and average delay
23
BubbleRap
Social behavior
HaggleSim emulator
Real traces dataset (Infocom05, HongKong, Cambridge, and Infocom06)
Delivery ratio and total cost
24
TDOR
Geographic (GPS)
ONE simulator
Helsink city map (artificial-nodes randomly placed)
Delivery ratio, average delivery latency, and overhead ratio
25
M-GEDIR
Multi strategies (geographic, signal strength, speed, distance, and position)
NS2 and MOVE
Synthetic (nodes randomly placed)
End-to-end delay, link failure, and throughput
26
CARTOON
Adaptive in flooding or probabilistic
ONE simulator
Real traces dataset (UMass DieselNet, ZebraNet, WDM, iMotes, and Dartmouth)
Delivered message ratio, average end-to-end delay, and number of delivered messages
27
GeOpps-N
Topology-based
OMNET++, MOVE, SUMO, VEIS
OSM database
Delivery ratio, end-to-end delay, and overhead ratio
28
CBLTR, IDVR and CORA
Cluster-based (social behavior) and intersection-based (geographic)
SUMO e MATLAB
Synthetic (nodes and obstacles custom placed)
Average throughput, end-to-end delay, and number of messages
29
A-STAR and GPSR
Geographic
SUMO
Bathinda city map-OSM database
Throughput, delivery ratio, packet loss, and average delay
30
EGSR
Position-based and social behavior
OMNET++ and SUMO
Manhattan city map (nodes randomly placed)
Delivery ratio, overhead ratio, and packet loss
31
PA-GPSR
Geographic
NS3 and SUMO
Synthetic (nodes and obstacles custom placed)
Packet loss rate, end-to-end delay, and network yieldTherefore, there are several forwarding strategies and performance evaluation metrics. Independent of the forwarding strategy, a metric must evaluate its performance. However, none of previously cited metric makes use of the resources consumption, transmission opportunities, or contact time to evaluate the quality of any forwarding strategy. In this study, we have addressed this issue. Table2 shows the state-of-art of the performance evaluation metrics for forwarding protocols against our proposal’s novelty.Table 2
Summary of forwarding protocols’ performance evaluation metrics.
Metric
Description
Benchmark unit
Created messages (CM)
Total number of created messages. Do not include replication.
Number
Relayed messages (RM)
Total number of successful transmissions between nodes.
Number
Aborted messages (AM) and packet loss
Total number of transmissions messages that fail before finished. Aborted messages occur due to disconnection during the transmission between nodes.
Number
Started messages (SM)
Total number of transmissions started. SM = (RM) + (AM).
Number
Dropped messages
Total number of dropped messages from nodes buffers before delivery to final destination.
Number
Delivered messages (DM) or number of messages
Total number of successful delivered messages in final target.
Number
Messages delivery ratio (MDR)
Messages delivery probability. MDR = ((1.0∗ DM)/CM).
Percentage (%)
Overhead ratio (OR)
An assessment of bandwidth efficiency. It is the number of created copies per delivered message. It amounts the number of replicas necessary to perform a successful delivery.
Percentage (%) number
Latency average
Latency average messages delay from creation to delivery.
Seconds
Hop count average
Average number of hops between source and destination.
Number
Buffer time average
Average time that messages stay in the buffer at each node.
Number
Buffer size occupancy
Buffer size occupancy average at each node.
Bytes
RTT average
Round-trip time average. Average time from creation to confirmation of delivery.
Seconds
End-to-end delay
Time taken for a message transmission across a network from source to destination.
Seconds
Throughput
The number of transactions per second an application can handle, the amount of transactions produced over time during a test.
Transactions per second
Link failure
The period of consecutive packet loss that can last for many seconds, followed by a change in delay after the link is reestablished.
Seconds
Transmission opportunity (TOpp)
The ratio between the total amounts of resources that a protocol could have to the actual number of resources used by this protocol. This metric can evaluate the resource consumption such as the number of transmission opportunities, contact time duration, or data transfer in the network.
Percentage (%) time (seconds); data stream (Mbps)


## 3. Data and Methodology

This section presents the dataset, the modeling for creation of the time-varying graphs, the description of the evaluated features and the methodology applied in this data analysis study.


### 3.1. Dataset

We have used the databases provided by [32] of real taxi traces, containing twenty-four hours of movement of three cities: Rome (Italy), San Francisco (USA), and Shanghai (China).The original databases received an improvement by filling in the existing gaps according to the granularity of the readings, making the database uniform. This uniformity was possible to obtain, through a reference system based on clustering with a calibration method proposed by [32]. Celes et al. [32] state that applying the calibration method to real vehicle mobility records improves their quality, leading to more reliable movement analysis and simulation results.Celes et al. [32] had provided twenty-four hours of calibrated data as follows. For the city of Rome, the data of February 4, 2014, contain 3,843,043 records and 187 taxis. For the data of San Francisco, the day May 20, 2008, contains 8,327,920 records and 468 taxis. For Shanghai, the readings of February 20, 2007, contain 13,410,782 positions and 4252 taxis.


### 3.2. Time-Varying Graph

We consider an encounter when two vehicles are in each other’s communication range. In IEEE 802.11p standardization, the signal of radio communication range can vary from zero to 1000 meters [2]. Therefore, in our evaluation, we have used the following communication ranges: 50 m; 100 m; 200 m; 300 m; 400 m; 500 m; 600 m; 700 m; 800 m; 900 m, and 1000 m. We have applied the Haversine equation [33] to calculate the distance between vehicles. Taxi traces are in an urban environment, and vehicle speeds vary between 0 and 100 km/h, with an average speed of 20 km/h for Rome and Shanghai and 25 km/h for San Francisco.In VANETs, the definition of static networks does not adequately describe the behavior of these systems. In static networks, if a vertexu has a direct connection to vertex v and v has a direct connection to vertex w, then u has no direct connection to w by a path that passes through v [34]. However, in time-varying graphs (TVGs) [35, 36], if the edge u,v is active at a different time than the edge v,w, then u and w are not connected, since nothing can propagate from u via v to w [35, 36]. Thus, time is an important quality dimension for the analysis and understanding of the interactions among nodes in a vehicular network.In this way, we have divided the datasets in twenty-four time windows with 1 hour, which form the TVGs (Figure1). Each TVG is nondirected, and its formal definition is a graph H = (V, E, T), where V is the set of vehicles vi, T is the time for which the TVG is defined, and E is the set of edges during the interval T, E ⊆ vi × T × vj × T. In graph H, an edge exists between two vehicles vi,vj if these vehicles are within their communication range and if i ≠ j. For each dataset, there are twenty-four TVGs H, which have allowed us to analyze interactions of the vehicles during twenty-four hours of a day. During this time, each taxi has its evaluation made second by second individually, and we obtained all these data running simulations. Finally, we have aggregated all data for each TVG according to the technique called Crescent Time Window [37].Figure 1
Representation for time-varying graph,H. For each dataset (i.e., Roma, San Francisco, and Shanghai), twenty-four TVGs with one hour of duration. Each TVG has different number of vehicles and edge densities according to the time of the day and with the range of the radio signal.The formalization of the TVG and the choice of an interval are practices adopted by researchers to analyze movement traces. It does not pulverize or condense the information. The TVG duration of one hour for twenty-four hours provides sufficient time to show the transition times from sparse to dense and dense to sparse occurring during the day. It is possible to characterize the contacts availability as the day progresses and to demonstrate the dynamics of link formation.Interactions between vertices are intrinsically dynamic and vary over time. Their connections appear and disappear at specific points in time and are often recurrent [35, 36].


### 3.3. Data Acquisition for Analysis

To acquire data for all the analysis proposed in this study, we submit the datasets to simulation with the DTN simulator ‘THE ONE’ [38]. Data acquisition has the following processes:(1)
We had to convert the calibrated datasets (Figure2(a)) from the latitude and longitude GPS formats into ‘THE ONE’ UTMx, UTMy input format file (Figure 2). To run simulations with external data, ‘THE ONE’ simulator requires two input files. (a) The taxis’ mobility trace input file (Figure 2(b)) has in its first row the number of taxis, start time, end time, and simulation world size. Withal, for each taxi, all the positions are collected during the trace time duration. (b) The taxis’ mobility activation time input file (Figure 2(c)) has the taxis’ identification, activation time, and deactivation time. We have executed this process for each of the 24 TVGs.(2)
To run the simulations, we have configured the setup file as shown in Table3. We have run twenty-four simulations (i.e., one for each TVG), for each city (i.e., Rome, San Francisco, and Shanghai) and each communication range (i.e., 50 m, 100 m, 200 m, 300 m, 400 m, 500 m, 600 m, 700 m, 800 m, 900 m, and 1000 m). As we have not evaluated any forwarding strategy (i.e., routing protocol), we have not set up any routing class on the simulator. Therefore, our main purpose was to obtain the connection and disconnection logs between vehicles with only one radio interface (i.e., one antenna) to analyze their transmission opportunities and upper bound resource inventory. We have executed this process for each of the 24 TVGs.(3)
After each simulation loop, the simulator generates two output files. One of them contains connectivity logs, and the other contains adjacency logs between vehicles. (a) The connectivity log file contains the time the vehicles establish connection and the time when a connection vanishes. Thereby, we can calculate when and how long a connection between two vehicles endures, transmission opportunity type (i.e. serial, or parallel), and maximum theoretical amount of data transferred (i.e., for serial and parallel transmission opportunities) and classify vehicles according to the contact time duration. (b) The adjacency log file contains all encounters that occurred between vehicles. Thereby, we can calculate hour-by-hour vehicle density variation and analyze the beacon overhead impact over the resource availability. We have executed this process for each of the 24 TVGs. To clarify the understanding of this process, Table4 presents the generated output file, the data contained in this file, file objective of application, and the section of this paper where each data analysis goal has its detailed explanation and outcome discussion.Figure 2
Data conversion process. From original calibrated dataset to ‘THE ONE’ input files. (a) Calibrated taxis’ dataset format (original). (b) Taxis’ mobility trace input format (converted). (c) Taxis’ mobility activation input format (converted).
(a)
(b)
(c)Table 3
Configuration’s file setup to run simulations.
Parameter
Value set
Needs switching
Scenario.simulateConnections
True
No
highspeedInterface.transmitSpeed (Mbps)
3 M
No
highspeedInterface.transmitRange (meters)
50 to 1.000
Yes: (50, 100, 200, 300, 400, 500, 600, 700, 800, 900, 1.000)
Scenario.nrofHostGroups
1
No
Group.movementModel
ExternalPathMovement
No
Group.traceFile
Path to the ‘THE ONE’-like mobility input file (∗.csv)
Yes: (each mobility trace input file for each of the 24 TVGs)
Group.activeFile
Path to the ‘THE ONE’-like mobility activation input file (∗.csv)
Yes: (each mobility activation input file for each of the 24 TVGs)
Group.router
Not set
No
Scenario.endTime (seconds)
3.6 k
No
Group.nrofHosts
2 to∞
Yes: (depends on the number of vehicles in each of the 24 TVGs)
Group.msgTtl (minutes)
60
No
Group.nrofInterfaces
1
No
Group.speed (mph)
2.7, 13.9
NoTable 4
Output files obtained from the simulation process and applied to calculate the outcomes of this paper.
Output file
Source
Contained data
Objective
Section
Connectivity logs
Simulation
Up and down connection times between vehicles
To calculate when two vehicles contact each other and how long this contact lasts
4.1, 4.2, 5.1, and 5.2
When-how long
This research
Pair of vehicles identification, connection star time, connection time duration, and volume of data at 3 Mbps (i.e., from IEEE 802.11p)
To verify if a transmission opportunity is serial or is parallel and to calculate the resource inventory and beacon overhead impact and classify vehicles according to contact time
4.1, 4.2, 5.2, 5.3, and 5.4
Adjacency logs
Simulation
Vehicles intersections in the TVG
To obtain vehicle density hour-by-hour and discuss hourly vehicle movement characteristics and to calculate beacon overhead wasting impact
5.1 and 5.4Thus, we have divided the analysis into five parts. (1) Description of the density variation according to the daily activity of the vehicles. (2) Conceptualization of transmission opportunities and their classification in serial or parallel types. (3) Use of data rate as an example of available resources to calculate how much data transmission opportunities could be generated. (4) Analysis of beacon overhead resource wasting, in order to understand its impact over the resource availability. (5) Split of the vehicles into eight classes according to the contact time among them and their transmission opportunities.


## 3.1. Dataset

We have used the databases provided by [32] of real taxi traces, containing twenty-four hours of movement of three cities: Rome (Italy), San Francisco (USA), and Shanghai (China).The original databases received an improvement by filling in the existing gaps according to the granularity of the readings, making the database uniform. This uniformity was possible to obtain, through a reference system based on clustering with a calibration method proposed by [32]. Celes et al. [32] state that applying the calibration method to real vehicle mobility records improves their quality, leading to more reliable movement analysis and simulation results.Celes et al. [32] had provided twenty-four hours of calibrated data as follows. For the city of Rome, the data of February 4, 2014, contain 3,843,043 records and 187 taxis. For the data of San Francisco, the day May 20, 2008, contains 8,327,920 records and 468 taxis. For Shanghai, the readings of February 20, 2007, contain 13,410,782 positions and 4252 taxis.


## 3.2. Time-Varying Graph

We consider an encounter when two vehicles are in each other’s communication range. In IEEE 802.11p standardization, the signal of radio communication range can vary from zero to 1000 meters [2]. Therefore, in our evaluation, we have used the following communication ranges: 50 m; 100 m; 200 m; 300 m; 400 m; 500 m; 600 m; 700 m; 800 m; 900 m, and 1000 m. We have applied the Haversine equation [33] to calculate the distance between vehicles. Taxi traces are in an urban environment, and vehicle speeds vary between 0 and 100 km/h, with an average speed of 20 km/h for Rome and Shanghai and 25 km/h for San Francisco.In VANETs, the definition of static networks does not adequately describe the behavior of these systems. In static networks, if a vertexu has a direct connection to vertex v and v has a direct connection to vertex w, then u has no direct connection to w by a path that passes through v [34]. However, in time-varying graphs (TVGs) [35, 36], if the edge u,v is active at a different time than the edge v,w, then u and w are not connected, since nothing can propagate from u via v to w [35, 36]. Thus, time is an important quality dimension for the analysis and understanding of the interactions among nodes in a vehicular network.In this way, we have divided the datasets in twenty-four time windows with 1 hour, which form the TVGs (Figure1). Each TVG is nondirected, and its formal definition is a graph H = (V, E, T), where V is the set of vehicles vi, T is the time for which the TVG is defined, and E is the set of edges during the interval T, E ⊆ vi × T × vj × T. In graph H, an edge exists between two vehicles vi,vj if these vehicles are within their communication range and if i ≠ j. For each dataset, there are twenty-four TVGs H, which have allowed us to analyze interactions of the vehicles during twenty-four hours of a day. During this time, each taxi has its evaluation made second by second individually, and we obtained all these data running simulations. Finally, we have aggregated all data for each TVG according to the technique called Crescent Time Window [37].Figure 1
Representation for time-varying graph,H. For each dataset (i.e., Roma, San Francisco, and Shanghai), twenty-four TVGs with one hour of duration. Each TVG has different number of vehicles and edge densities according to the time of the day and with the range of the radio signal.The formalization of the TVG and the choice of an interval are practices adopted by researchers to analyze movement traces. It does not pulverize or condense the information. The TVG duration of one hour for twenty-four hours provides sufficient time to show the transition times from sparse to dense and dense to sparse occurring during the day. It is possible to characterize the contacts availability as the day progresses and to demonstrate the dynamics of link formation.Interactions between vertices are intrinsically dynamic and vary over time. Their connections appear and disappear at specific points in time and are often recurrent [35, 36].


## 3.3. Data Acquisition for Analysis

To acquire data for all the analysis proposed in this study, we submit the datasets to simulation with the DTN simulator ‘THE ONE’ [38]. Data acquisition has the following processes:(1)
We had to convert the calibrated datasets (Figure2(a)) from the latitude and longitude GPS formats into ‘THE ONE’ UTMx, UTMy input format file (Figure 2). To run simulations with external data, ‘THE ONE’ simulator requires two input files. (a) The taxis’ mobility trace input file (Figure 2(b)) has in its first row the number of taxis, start time, end time, and simulation world size. Withal, for each taxi, all the positions are collected during the trace time duration. (b) The taxis’ mobility activation time input file (Figure 2(c)) has the taxis’ identification, activation time, and deactivation time. We have executed this process for each of the 24 TVGs.(2)
To run the simulations, we have configured the setup file as shown in Table3. We have run twenty-four simulations (i.e., one for each TVG), for each city (i.e., Rome, San Francisco, and Shanghai) and each communication range (i.e., 50 m, 100 m, 200 m, 300 m, 400 m, 500 m, 600 m, 700 m, 800 m, 900 m, and 1000 m). As we have not evaluated any forwarding strategy (i.e., routing protocol), we have not set up any routing class on the simulator. Therefore, our main purpose was to obtain the connection and disconnection logs between vehicles with only one radio interface (i.e., one antenna) to analyze their transmission opportunities and upper bound resource inventory. We have executed this process for each of the 24 TVGs.(3)
After each simulation loop, the simulator generates two output files. One of them contains connectivity logs, and the other contains adjacency logs between vehicles. (a) The connectivity log file contains the time the vehicles establish connection and the time when a connection vanishes. Thereby, we can calculate when and how long a connection between two vehicles endures, transmission opportunity type (i.e. serial, or parallel), and maximum theoretical amount of data transferred (i.e., for serial and parallel transmission opportunities) and classify vehicles according to the contact time duration. (b) The adjacency log file contains all encounters that occurred between vehicles. Thereby, we can calculate hour-by-hour vehicle density variation and analyze the beacon overhead impact over the resource availability. We have executed this process for each of the 24 TVGs. To clarify the understanding of this process, Table4 presents the generated output file, the data contained in this file, file objective of application, and the section of this paper where each data analysis goal has its detailed explanation and outcome discussion.Figure 2
Data conversion process. From original calibrated dataset to ‘THE ONE’ input files. (a) Calibrated taxis’ dataset format (original). (b) Taxis’ mobility trace input format (converted). (c) Taxis’ mobility activation input format (converted).
(a)
(b)
(c)Table 3
Configuration’s file setup to run simulations.
Parameter
Value set
Needs switching
Scenario.simulateConnections
True
No
highspeedInterface.transmitSpeed (Mbps)
3 M
No
highspeedInterface.transmitRange (meters)
50 to 1.000
Yes: (50, 100, 200, 300, 400, 500, 600, 700, 800, 900, 1.000)
Scenario.nrofHostGroups
1
No
Group.movementModel
ExternalPathMovement
No
Group.traceFile
Path to the ‘THE ONE’-like mobility input file (∗.csv)
Yes: (each mobility trace input file for each of the 24 TVGs)
Group.activeFile
Path to the ‘THE ONE’-like mobility activation input file (∗.csv)
Yes: (each mobility activation input file for each of the 24 TVGs)
Group.router
Not set
No
Scenario.endTime (seconds)
3.6 k
No
Group.nrofHosts
2 to∞
Yes: (depends on the number of vehicles in each of the 24 TVGs)
Group.msgTtl (minutes)
60
No
Group.nrofInterfaces
1
No
Group.speed (mph)
2.7, 13.9
NoTable 4
Output files obtained from the simulation process and applied to calculate the outcomes of this paper.
Output file
Source
Contained data
Objective
Section
Connectivity logs
Simulation
Up and down connection times between vehicles
To calculate when two vehicles contact each other and how long this contact lasts
4.1, 4.2, 5.1, and 5.2
When-how long
This research
Pair of vehicles identification, connection star time, connection time duration, and volume of data at 3 Mbps (i.e., from IEEE 802.11p)
To verify if a transmission opportunity is serial or is parallel and to calculate the resource inventory and beacon overhead impact and classify vehicles according to contact time
4.1, 4.2, 5.2, 5.3, and 5.4
Adjacency logs
Simulation
Vehicles intersections in the TVG
To obtain vehicle density hour-by-hour and discuss hourly vehicle movement characteristics and to calculate beacon overhead wasting impact
5.1 and 5.4Thus, we have divided the analysis into five parts. (1) Description of the density variation according to the daily activity of the vehicles. (2) Conceptualization of transmission opportunities and their classification in serial or parallel types. (3) Use of data rate as an example of available resources to calculate how much data transmission opportunities could be generated. (4) Analysis of beacon overhead resource wasting, in order to understand its impact over the resource availability. (5) Split of the vehicles into eight classes according to the contact time among them and their transmission opportunities.


## 4. Transmission Opportunities (TOpps)

In this section, we present our concept of transmission opportunities in ad hoc vehicular networks, henceforth called TOpps. We also show how TOpps become available from the point of view of the vehicle that forwards the message, which can occur serially or in parallel (serial and parallel TOpps are not the number of antennas that a sender vehicle has but the number of contacts that a vehicle may have at a same time).


### 4.1. TOpp Concept

There are three required conditions to define a TOpp on VANETs: (1) transmission of data through radio waves; (2) radio signal range; (3) time that vehicles are within the range of each other’s radio signal. A TOpp is an individual measure of a vehiclevi. We have defined that the TOpp of a vehicle vi is the set of vehicles Vvi,vj, which are under the coverage area A of the radio signal and which keeps contact time t between the vehicles longer than the time required for exchange beacon messages (the time required to exchange beacon messages varies according to the baud rate applied; in the specifications of the IEEE 802.11p, one beacon has 400 bytes and consumes 3 Mbps, ±1 ms [2]), tBM. We have formalized this definition as follows:(1)TOpp=vi,V∀vi,vj⊃Avi,tvi,vj>tBM.A TOpp does not guarantee the presence of a link between vehicles, what it guarantees is the choice of a node according to the routing protocol strategy to forward a message. Every TOpp represents an option, a possibility of establishing a link. Taking advantage of a TOpp depends directly on how the forwarding strategy will choose the next hop to send messages.For each dataset, we have calculated the TOpp of each vehicle. Figure3 shows the cumulative complementary distribution function (CCDF) of the total TOpp of each vehicle in all TVG for all radio ranges evaluated. It is possible to observe in the datasets that as the range (Avi) increases, the TOpp number also becomes greater. It means that the larger the range, the greater the choice of vehicles for communicating. Consequently, the density tends to be higher. Let us take as reference the signal range of 1000 m to observe. For Rome (Figure 3(a)), 80% of vehicles have less than 25 TOpps and around 20% of vehicles have between 100 and 300 TOpps. For San Francisco (Figure 3(b)), there is a considerable difference from Rome, the same 80% of the vehicles have more than 200 TOpps, i.e., eight times more. Even with a radius of 50 m, 60% of vehicles have more than 100 TOpps. This data show in this scenario that the density between vehicles is greater. For San Francisco, 20% of cars have between 650 and 1400 TOpp. For Shanghai (Figure 3(c)), with a number of cars twenty-four times larger than Rome and nine times larger than San Francisco, 80% of cars have about 200 TOpps and 20% of cars have between 750 and 1750 TOpps.Figure 3
Total TOpps. The leftmost line represents the range 50 m, successively to the rightmost line representing the range of 1000 m. (a) Rome, (b) San Francisco, and (c) Shanghai.
(a)
(b)
(c)Analyzing the availability of a vehicle’s TOpp is important to understand the interaction behavior between vehicles. To exemplify, we will use the degree centrality measure [34] of a vehicle. Suppose that the forwarding protocol always selects as next hop the vehicle with the highest degree. The selection of this vehicle occurred because it has several links with other vehicles in a specific time window (it has several TOpps). This does not mean this selected vehicle has the best TOpp. They may be short-lived and insufficient to transmit the data or could have other TOpps that do not connect to other vehicles and the lifetime of the message could expire. Depending on the forwarding strategy, TOpp can be misused or wasted.


### 4.2. Serial and Parallel TOpps

There is a relation between the types of TOpps, and the way that the vehicle that forwards a message accesses these opportunities. A sender vehicle could have only one option to send a message or more than one option to do the same. The objective is to choose among the options that take place, one that represents the best communication opportunity.In Figure4, we illustrate a vehicle with its TOpp. We select for visualization (we have performed this analysis with 30% of random vehicles from each dataset; we identify these three situations and we selected the cars that may represent each situation) one vehicle from each trace, known as sender. We performed the analysis of the interaction of this sender vehicle for 900 seconds. The dotted line represents the elapsed time of the sending car. The solid lines represent TOpp, and the number positioned on this line is the identifier of the TOpp (car identifier). The length of the solid line represents the contact time between the sender and the TOpp. We have set the radio range at 100 meters.Figure 4
Interaction of a sender vehicle with its TOpp. It is possible to observe moments where the sender has only one TOpp as well more than one. (a) Rome, (b) San Francisco, and (c) Shanghai.
(a)
(b)
(c)In Figure4(a), the sender is ‘Taxi 0, which has eleven TOpps. The contact times between sender and TOpp lasts between 20 and 75 seconds approximately. Note that two TOpps are recurrent (TOpp 15 and TOpp 21) and the others are unique. There are times when the sender has only one TOpp option, i.e., between 25 and 75 seconds. However, there are situations where the sender has more than one TOpp option at the same time, i.e., between 425 and 500 seconds or between 600 and 675 seconds. In Figure 4(b), the sender is ‘Taxi 406, which has 29 TOpps. Contact time lasts between 20 and 250 seconds approximately. There are also recurring TOpps as well as TOpps that happen only once. It is noteworthy that most TOpps occur in parallel, which increases the number of options the sender has to send a message. In Figure 4(c), the sender is ‘Taxi 4,’ which has 5 TOpps. The contact time is between 40 and 60 seconds. This case differs from the other two because it does not present recurring TOpps.This behavior allows us to classify TOpp into two types: (1) serial, when the sender has only one option of TOpp at a given time; (2) parallel, when the sender has more than one TOpp options at the same time. We quantify the TOpp to analyze their behavior as the range of the radio signal increases.In Figure5, we have shown the CCDF for the serial TOpp and for parallel TOpp of every single vehicle. In the three cities, in general, as the range of the radio signal increases, the amount of parallel TOpps becomes more frequent. We can observe when the range is about 50 m or 100 m that the quantities of serial TOpp and parallel TOpp are nearly equivalent. For range of 800 m, 900 m, and 1000 m, the difference is more evident and the amount of parallel TOpps is larger.Figure 5
TOpp types. Serial TOpps of (a) Rome, (b) San Francisco, and (c) Shanghai. Parallel TOpps of (d) Rome, (e) San Francisco, and (f) Shanghai.
(a)
(b)
(c)
(d)
(e)
(f)Let us take as a reference the range of 1000 m to observe. For Rome (Figure5(a)), serial TOpps are ≥1and≤100, with 80% of the vehicles having less than 15 TOpps. For Rome (Figure 5(d)), the number of TOpps increases to ≥1and≤300, but only 20% of vehicles have 60 parallel TOpps. For San Francisco (Figure 5(b)), serial TOpps are ≥1and≤350, and 20% of vehicles have more than 120 TOpps. In Figure 5(e), the number of parallel TOpps is larger (≥1and≤1200). For the same 20% of vehicles, it reaches more than 600 TOpps in parallel, a value five times higher than the serial ones. For Shanghai (Figure 5(c)), serial TOpps are ≥1and≤600; there are many taxis on the streets and 80% of cars have close to 100 serial TOpps. For Shanghai (Figure 5(f)), the amount of parallel TOpps is ≥1and≤1400. However, the same 80% of the vehicles have less than 100 TOpps and 20% of the taxis find more than 500 TOpps.Each dataset shows different behaviors for serial TOpp and parallel TOpp. The number of vehicles in each city and daily cycle of activities affects this behavior. They also imply the variation of density throughout the day. This shows us that the smaller the range, the smaller the number of vehicles interacting with each other. As a result, the network becomes less dense offering fewer communication options. On the other hand, larger range allows the TOpp number to be larger, but it requires more complexity on the part of the protocols to establish the forwarding strategies and next-hop selection.The three situations presented in Figure4 show that, in vehicular network, the interaction between vehicles and TOpp will occur in three ways according to density. (1) Sparse: little movement of vehicles and a greater presence of serial TOpp. (2) Sparse to dense or dense to sparse: increase or decrease in vehicle movement and presence of both serial TOpps and parallel TOpps. (3) Dense: high vehicle movement and greater parallel TOpp presence. Therefore, any forwarding protocol design for vehicular networks should consider these situations in its modeling.The existence of serial TOpp and TOpp in parallel allows the development of different forwarding strategies in the same protocol. If we think about the cost to forward a message, we could say that, in sparse situations, there are more serial TOpps. Therefore, a simpler message transfer process may be enough to forward. For instance, epidemic or first contact forwarding strategies are examples of applicable protocols to these cases. If there are few or zero TOpps, there is no need to develop complex, time-consuming strategies to decide the next hop. On the other hand, when the network is dense and there are many parallel Topps, it is important to analyze the need to develop strategies to decide which TOpp to deliver the message. In this case, many options will be available to the sender of the message. For instance, forwarding strategies based on probabilities, measures of centrality, social networks, and geographical measures are options to apply in order to identify the best TOpp to address a message. It is up to forwarding protocols to find out what density situation nodes are in and then select the best strategy for choosing the next hop.


## 4.1. TOpp Concept

There are three required conditions to define a TOpp on VANETs: (1) transmission of data through radio waves; (2) radio signal range; (3) time that vehicles are within the range of each other’s radio signal. A TOpp is an individual measure of a vehiclevi. We have defined that the TOpp of a vehicle vi is the set of vehicles Vvi,vj, which are under the coverage area A of the radio signal and which keeps contact time t between the vehicles longer than the time required for exchange beacon messages (the time required to exchange beacon messages varies according to the baud rate applied; in the specifications of the IEEE 802.11p, one beacon has 400 bytes and consumes 3 Mbps, ±1 ms [2]), tBM. We have formalized this definition as follows:(1)TOpp=vi,V∀vi,vj⊃Avi,tvi,vj>tBM.A TOpp does not guarantee the presence of a link between vehicles, what it guarantees is the choice of a node according to the routing protocol strategy to forward a message. Every TOpp represents an option, a possibility of establishing a link. Taking advantage of a TOpp depends directly on how the forwarding strategy will choose the next hop to send messages.For each dataset, we have calculated the TOpp of each vehicle. Figure3 shows the cumulative complementary distribution function (CCDF) of the total TOpp of each vehicle in all TVG for all radio ranges evaluated. It is possible to observe in the datasets that as the range (Avi) increases, the TOpp number also becomes greater. It means that the larger the range, the greater the choice of vehicles for communicating. Consequently, the density tends to be higher. Let us take as reference the signal range of 1000 m to observe. For Rome (Figure 3(a)), 80% of vehicles have less than 25 TOpps and around 20% of vehicles have between 100 and 300 TOpps. For San Francisco (Figure 3(b)), there is a considerable difference from Rome, the same 80% of the vehicles have more than 200 TOpps, i.e., eight times more. Even with a radius of 50 m, 60% of vehicles have more than 100 TOpps. This data show in this scenario that the density between vehicles is greater. For San Francisco, 20% of cars have between 650 and 1400 TOpp. For Shanghai (Figure 3(c)), with a number of cars twenty-four times larger than Rome and nine times larger than San Francisco, 80% of cars have about 200 TOpps and 20% of cars have between 750 and 1750 TOpps.Figure 3
Total TOpps. The leftmost line represents the range 50 m, successively to the rightmost line representing the range of 1000 m. (a) Rome, (b) San Francisco, and (c) Shanghai.
(a)
(b)
(c)Analyzing the availability of a vehicle’s TOpp is important to understand the interaction behavior between vehicles. To exemplify, we will use the degree centrality measure [34] of a vehicle. Suppose that the forwarding protocol always selects as next hop the vehicle with the highest degree. The selection of this vehicle occurred because it has several links with other vehicles in a specific time window (it has several TOpps). This does not mean this selected vehicle has the best TOpp. They may be short-lived and insufficient to transmit the data or could have other TOpps that do not connect to other vehicles and the lifetime of the message could expire. Depending on the forwarding strategy, TOpp can be misused or wasted.


## 4.2. Serial and Parallel TOpps

There is a relation between the types of TOpps, and the way that the vehicle that forwards a message accesses these opportunities. A sender vehicle could have only one option to send a message or more than one option to do the same. The objective is to choose among the options that take place, one that represents the best communication opportunity.In Figure4, we illustrate a vehicle with its TOpp. We select for visualization (we have performed this analysis with 30% of random vehicles from each dataset; we identify these three situations and we selected the cars that may represent each situation) one vehicle from each trace, known as sender. We performed the analysis of the interaction of this sender vehicle for 900 seconds. The dotted line represents the elapsed time of the sending car. The solid lines represent TOpp, and the number positioned on this line is the identifier of the TOpp (car identifier). The length of the solid line represents the contact time between the sender and the TOpp. We have set the radio range at 100 meters.Figure 4
Interaction of a sender vehicle with its TOpp. It is possible to observe moments where the sender has only one TOpp as well more than one. (a) Rome, (b) San Francisco, and (c) Shanghai.
(a)
(b)
(c)In Figure4(a), the sender is ‘Taxi 0, which has eleven TOpps. The contact times between sender and TOpp lasts between 20 and 75 seconds approximately. Note that two TOpps are recurrent (TOpp 15 and TOpp 21) and the others are unique. There are times when the sender has only one TOpp option, i.e., between 25 and 75 seconds. However, there are situations where the sender has more than one TOpp option at the same time, i.e., between 425 and 500 seconds or between 600 and 675 seconds. In Figure 4(b), the sender is ‘Taxi 406, which has 29 TOpps. Contact time lasts between 20 and 250 seconds approximately. There are also recurring TOpps as well as TOpps that happen only once. It is noteworthy that most TOpps occur in parallel, which increases the number of options the sender has to send a message. In Figure 4(c), the sender is ‘Taxi 4,’ which has 5 TOpps. The contact time is between 40 and 60 seconds. This case differs from the other two because it does not present recurring TOpps.This behavior allows us to classify TOpp into two types: (1) serial, when the sender has only one option of TOpp at a given time; (2) parallel, when the sender has more than one TOpp options at the same time. We quantify the TOpp to analyze their behavior as the range of the radio signal increases.In Figure5, we have shown the CCDF for the serial TOpp and for parallel TOpp of every single vehicle. In the three cities, in general, as the range of the radio signal increases, the amount of parallel TOpps becomes more frequent. We can observe when the range is about 50 m or 100 m that the quantities of serial TOpp and parallel TOpp are nearly equivalent. For range of 800 m, 900 m, and 1000 m, the difference is more evident and the amount of parallel TOpps is larger.Figure 5
TOpp types. Serial TOpps of (a) Rome, (b) San Francisco, and (c) Shanghai. Parallel TOpps of (d) Rome, (e) San Francisco, and (f) Shanghai.
(a)
(b)
(c)
(d)
(e)
(f)Let us take as a reference the range of 1000 m to observe. For Rome (Figure5(a)), serial TOpps are ≥1and≤100, with 80% of the vehicles having less than 15 TOpps. For Rome (Figure 5(d)), the number of TOpps increases to ≥1and≤300, but only 20% of vehicles have 60 parallel TOpps. For San Francisco (Figure 5(b)), serial TOpps are ≥1and≤350, and 20% of vehicles have more than 120 TOpps. In Figure 5(e), the number of parallel TOpps is larger (≥1and≤1200). For the same 20% of vehicles, it reaches more than 600 TOpps in parallel, a value five times higher than the serial ones. For Shanghai (Figure 5(c)), serial TOpps are ≥1and≤600; there are many taxis on the streets and 80% of cars have close to 100 serial TOpps. For Shanghai (Figure 5(f)), the amount of parallel TOpps is ≥1and≤1400. However, the same 80% of the vehicles have less than 100 TOpps and 20% of the taxis find more than 500 TOpps.Each dataset shows different behaviors for serial TOpp and parallel TOpp. The number of vehicles in each city and daily cycle of activities affects this behavior. They also imply the variation of density throughout the day. This shows us that the smaller the range, the smaller the number of vehicles interacting with each other. As a result, the network becomes less dense offering fewer communication options. On the other hand, larger range allows the TOpp number to be larger, but it requires more complexity on the part of the protocols to establish the forwarding strategies and next-hop selection.The three situations presented in Figure4 show that, in vehicular network, the interaction between vehicles and TOpp will occur in three ways according to density. (1) Sparse: little movement of vehicles and a greater presence of serial TOpp. (2) Sparse to dense or dense to sparse: increase or decrease in vehicle movement and presence of both serial TOpps and parallel TOpps. (3) Dense: high vehicle movement and greater parallel TOpp presence. Therefore, any forwarding protocol design for vehicular networks should consider these situations in its modeling.The existence of serial TOpp and TOpp in parallel allows the development of different forwarding strategies in the same protocol. If we think about the cost to forward a message, we could say that, in sparse situations, there are more serial TOpps. Therefore, a simpler message transfer process may be enough to forward. For instance, epidemic or first contact forwarding strategies are examples of applicable protocols to these cases. If there are few or zero TOpps, there is no need to develop complex, time-consuming strategies to decide the next hop. On the other hand, when the network is dense and there are many parallel Topps, it is important to analyze the need to develop strategies to decide which TOpp to deliver the message. In this case, many options will be available to the sender of the message. For instance, forwarding strategies based on probabilities, measures of centrality, social networks, and geographical measures are options to apply in order to identify the best TOpp to address a message. It is up to forwarding protocols to find out what density situation nodes are in and then select the best strategy for choosing the next hop.


## 5. Results

In this section, we present the results of our TOpp study. Therefore, we first describe some general characteristics of vehicle movement. Next, we present the maximum theoretical data available according to the TOpp and we discuss its usage. Finally, we present if beacon overhead affects the resource inventory and we state that contact time is an indicator of link quality for vehicle communication.


### 5.1. Vehicle Movement Characteristics

There is a direct relation between people’s daily activities and movements of vehicles. People travel around cities and use their transportation infrastructure resources for the purpose of working, studying, leisure, or resting.In the cities, during business hours, there is an increase in the movement of people. The larger is the movement, the larger the number of vehicles is. As movement of people decreases, there is a reduction in the number of vehicles circulating in the streets. Therefore, there are hours with high density and hours with low density of vehicles. There are also transition times, from low density to high density and from high density to low density. At moments of low density, there are few active vehicles and fewer TOpp for communication among them.In the datasets, we could observe that each city presents variances in the density of vehicles. In Figure6, we can observe the seasonal behavior of daily movement by looking at the number of contacts. For either Rome (Figure 6(a)), San Francisco (Figure 6(b)), or Shanghai (Figure 6(c)), there is a reduction in movement during the night (between 0 a.m. and 5 a.m.). In the early morning (around 6 a.m.), activities increase until reaching their peak times and then reducing again.Figure 6
Vehicle movement characteristics. Daily density variance of vehicles makes the TOpp also to vary with the hour of day. (a) Rome, (b) San Francisco, and (c) Shanghai.
(a)
(b)
(c)The fundamental principle of communication requires at least two communicating elements, the hosts, and one connection that allows these hosts to exchange information, a link. We infer that the higher the density, the larger the number of hosts and the greater the possibility of link formation. Consequently, the communication capacity between hosts on the network should increase (initially in this work, we have not considered collisions).Vehicles are hosts, and their encounters over time are TOpps. TOpps are resource providers, and proper use of these resources makes their consumption more efficient. Thus, we have used the transmission data rate to exemplify, define, and quantify the inventory resources generated by TOpp. Section5.2 addresses this issue.


### 5.2. Resource Inventory

Computer networks by definition share resources. Adequate consumption of any available resource in a network is an indicator of the quality of network services. TOpp in the vehicular networks are resource providers, and the TOpp itself is a resource. The use of these TOpp is a performance indicator for forwarding protocols in these dynamic networks.To demonstrate the resource inventory that a vehicular network can offer, we have used the transmission data rate as a measure. According to the IEEE 802.11p standard [2], eight rates are available: 3 Mbps; 4.5 Mbps; 6 Mbps; 9 Mbps; 12 Mbps; 18 Mbps; 24 Mbps; and 27 Mbps. Transmission data rate is an important variable and is directly related to the type of application intended for the vehicular network. This concern is also pertinent to designs of forwarding protocols in V2V environments.In order to obtain the resources inventoryEvi,vj, we have calculated for all TVG H and individually for each vehicle vi, the contact time t ≥ 0 s, with each of their TOpp vj. We have obeyed the criteria for selecting a TOpp according to equation (1). Each contact time is multiplied by the transmission data rate tx. Because it represents the situation that would provide the lowest inventory possible, we chose tx = 3 Mbps. The resource inventory calculation results in the view of the maximum theoretical data volume that TOpps are able to provide. Equation (2) formalizes it:(2)∀TOpp,Evi,vj=vi×tvi,vj×tx,t≥0s.As contact time is an important variable for TOpp, we have plotted in Figure7 the CCDF for the contact time between a sender vehicle and its TOpp. Results obtained from the analysis of the twenty-four TVG show for the three cities that contact time is directly proportional to the radius of signal range. In all traces, regardless of the range, contact time varies from short (less than 1 second) to long (more than 100 seconds). We have used the radius of 1000 meters as a reference to analyze. In the case of Rome (Figure 7(a)), about 1% of cases have contact time greater than 1000 seconds, and about 12% is between 0.1and1second. More than 50% of TOpps are between 1and250 seconds. For San Francisco (Figure 7(b)), the behavior is quite similar to that of Rome, even though it has 2.5 times more vehicles. In Shanghai (Figure 7(c)), even with the largest number of vehicles (24x Roma, 9x San Francisco), contact times are even lower. Less than 30% of cases tend to have contact time longer than 100 seconds. More than 70% is between 0.1and25 seconds.Figure 7
Contact time of a sender vehicle and its TOpp. (a) Rome, (b) San Francisco, and (c) Shanghai.
(a)
(b)
(c)With the results of the inventory calculation, we have quantified the maximum theoretical volume of data that a vehicle would be able to transfer in each TVG. Figure8 shows the amount of data that is possible to exchange by a vehicle and its TOpp. Volume of data is directly proportional to the range.Figure 8
Volume of data per sender vehicle. The individual capacity of a vehicle to generate resources along its TOpp. (a) Rome, (b) San Francisco, and (c) Shanghai.
(a)
(b)
(c)We have observed that the volume of data that each vehicle could transfer relates to two variables: (1) density and (2) contact time. Let us take as reference the radius of 1000 meters. Rome (Figure8(a)) contains the smallest number of vehicles and less than 20% of vehicles showing capacity above 6 GB of data. For San Francisco (Figure 8(b)), there is a scenario with higher density and there are more contacts between vehicles, so 60% of vehicles have at least capacity of 20 GB. For Shanghai (Figure 8(c)), as the contact time is lower, only 20% of the vehicles can carry 25 GB of data.As we have discussed in Section4.2, TOpp can be serial or parallel. In this regard, we present in Figure 9 a comparison of the total data volume available for serial TOpp in relation to the total volume of data for parallel TOpp in each dataset. To obtain these values, it is necessary to add up the individual inventories of each vehicle. In all three cities, the volume of data reaches TB for all ranges. We have observed that for Rome (Figure 9(a)) and Shanghai (Figure 9(c)), for the range of 50 m and 100 m, the total inventory of serial resources is larger than the parallel one. For San Francisco (Figure 9(b)), data volume of parallel TOpp parallel is always greater than the serial TOpp volume of data. Shanghai shows the largest volume of data, reaching the amount bigger than 800 TB. It happens because it is the city with the largest number of taxis contributing to the inventory of resources. However, for all cities, the total inventory of resources in series and in parallel increases as the range increases, and serial resources grow less when compared to resources in parallel. This behavior shows a greater challenge in taking advantage of the availability of the more abundant resources, in the case of parallel TOpp.Figure 9
Data volume available. Calculated at the rate of 3 Mbps. (a) Rome, (b) San Francisco, and (c) Shanghai.
(a)
(b)
(c)Rome (Figure10(a)), San Francisco (Figure 10(b)), and Shanghai (Figure 10(c)) show the distribution of the volume of data that vehicles could use to take advantage from all resources supplied by the TOpp during the day (Figure 10). It shows how each city has its own particularities in the movement trace hour by hour. Thus, the alternations between the hours of the day with more movement and with less movement are more evident.Figure 10
Volume of data per hour of day. Transmitted data volume by vehicles with 1000 meters range and rate of 3 Mbps during the 24 hours of the day. (a) Rome, (b) San Francisco, and (c) Shanghai.
(a)
(b)
(c)This result shows that the amount of TOpp and consequently of resources is not the same throughout the day. Once again, we have shown the importance of forwarding protocols in adapting the density conditions to obtain results that are more efficient.In this section, we have found that there is an inventory of resources available in the vehicular networks. However, for vehicles to communicate, they perform an exchange of messages, known as beacons, that sends information about their situation on the network and allows them to show interest in initiating a data transmission. These beacons consume resources. Therefore, Section5.3, we have analyzed the impact of this exchange of messages on the consumption of vehicular network resources.


### 5.3. Consumption of Resources by Beacon Overhead

A vehicle can broadcast beacons that carry information enough to let other vehicles know which services this vehicle supports. It exchanges beacons using the Wave Short Message Protocol (WSMP) to create a cooperative awareness [2]. Beacons are small packets, which contain a message periodically exchanged among neighbors prior to data transmission [39]. That is the reason why beacons can consume and waste some of the resource while beaconing process.An issue related to beaconing process is the beacon overhead, which increases as the density of vehicles does. Beacon Overhead,BO, is directly proportional to the vehicle count. It is possible to observe looking into its simple mathematical concept (equation (3)) [39], where n is the vehicle count, S is the layer two of ISO/OSI protocol stack beacon size, and T is the periodic beacon propagation time interval:(3)BO=S×nT.In order to discover the beacon overhead impact on the resource inventory consumption, we have adaptedBO definition to calculate the amount of data consumed by beaconing issue. Equation (4) shows the Beacon consumption, BC, definition proposed by us. We denote n as the number of vehicles and S as the link layer (ISO/OSI Layer) (2) beacon size. The average delay interval that a vehicle waits to receive another beacon is T/2. RB is the rate for beacon transmission and RD is the rate for data packet transmission consumed during the process of sending and receiving a beacon between two vehicles. RB and RD are IEEE 801.11p specifications:(4)BC=S×nRB+T2×RD.The IEEE 802.11p beacon size is approximatelyS = 400 bytes of information. Beacons contain information like position, speed, acceleration, and direction of a node. Beacon transmission occurs on a regular interval, at every T = 100 ms, to ensure that all the nodes have an up-to-date cooperative awareness [39–41]. Data rate when handling with beacons by default is RB = 3 Mbps [2]. For packet data rate, we set for calculation purposes RD = 3 Mbps. We have chosen this value because it is the best case with the lower data volume consumption, and other values (4.5, 6, 9, 12, 18, 24, and 27 Mbps) are proportional. At least, vehicle count n depends on the TVG, which varies across the day.Figure11 shows the proportional relation between vehicle count and beacon overhead. For Rome (Figure 11(a)), San Francisco (Figure 11(b)), and Shanghai (Figure 11(c)), the bigger is the number of vehicles, and bigger the beacon overhead is in all cities. As expected, Rome reaches the lower number of beacons, as Shanghai reaches the higher beacon overhead due to the vehicle count in each city. San Francisco and Rome present more variation of beacon distribution, according to the number of vehicle variation during the day. At this point, Shanghai keeps a high number of beacon generation at the most part of the day. The waste caused by beacon consumption varies with time; for Rome (Figure 11(a)), San Francisco (Figure 11(b)), and Shanghai (Figure 11(c)), the higher is the number of vehicles sending beacon messages, the greater is the amount of data occupied.Figure 11
Beacon overhead impact. Relation between beacon overhead and its resource wasting. Primaryy-axis, Beacon Resource Waste (KB), shows the kilobytes of beacon wasted over a network that TOpp could provide gigabyte of data. The secondary y-axis, Beacon Resource Consumption (%), shows the percentage related to the theoretic total volume of data. (a) Rome, (b) San Francisco, and (c) Shanghai.
(a)
(b)
(c)One of our goals were to reveal the impact of the size of the beacon over the TOpp resource in comparison with the total resource inventory showed in Section5.2 (Figure 9). We have shown the impact over serial and parallel TOpps, for the radio range of 50 m (the lower number of TOpp). After all, we can state that beacons consumption (BC) have a very small or nonperceptive impact overall data inventory.


### 5.4. Contact Time as Quality Indicator

Before we consider the TOpp application as a metric, we should look at the histogram of vehicles contact time (Figure12) to understand that time is a quality indicator. Here, we show the analysis for three communication ranges, the shorter (50 m) and the larger (1000 m), that we have former processed from datasets with a common communication range (200 m) well accepted and applied to vehicular simulations at urban scenarios, as made by [42–44]. We have considered all twenty-four hours of the day. Let us observe Rome (Figure 12(a)), San Francisco (Figure 12(b)), and Shanghai (Figure 12(c)) for each communication range.Figure 12
Classes of vehicles in accordance with contact time (in seconds). The eight classes are as follows: (A: ≥0, ≤0.1); (B: >0.1, ≤1); (C: >1, ≤10); (D: >10, ≤100); (E: >100, ≤250); (F: >250, ≤500); (G: >500, ≤1000); (H: >1000, ≤3600). (a) Rome, (b) San Francisco, and (c) Shanghai.
(a)
(b)
(c)At the three datasets, there are situations that repeat themselves. Regardless of the dataset and the range used, more than 90% of vehicles have contact time between of 0.1 and 250 seconds (classesA to E). For Rome and San Francisco, it is possible to observe that all classes maintain the same behavior. Vehicles belonging to classes C (>1 and ≤10 seconds) and D (>10 and ≤100 seconds) are more common. In Shanghai, the behavior is similar to that in the other two cities, but classes B (>0.1 and ≤1 second) and C (>1 and ≤10 seconds) are the most frequent. Therefore, this behavior is helpful for the designers of forwarding messages protocols to choose their strategies, as next hop, the vehicles with better contact time.For Rome, San Francisco, and Shanghai, classesE (>100 and ≤250 seconds), F (>250 and ≤500 seconds), G (>500 and ≤1000 seconds), and H (>1000 and ≤3600 seconds) also have the same behavior and the frequency of vehicles in that the class decreases as the contact time increases. In Shanghai, vehicles with more than 1000 seconds of contact time have percentage close to zero, while in the other two cities, the representability is also low (less than 2%). These are cases of vehicles that can spend a lot of time idling and are not recurring TOpp. Therefore, these cars are not a good choice for forwarding a message.For Rome and San Francisco, irrespective of the range of Class A (≥0 and ≤0.1 seconds), the frequency of vehicles is very close, and it is the class which has lower impact. The vehicles contained in this class have very short contact times, and even allowing the exchange of few packets, they are not a good choice to forward a message, since they are very intermittent types of vehicles. Therefore, it is worth mentioning that the shorter the contact times is, the greater the generation of messages in the network is (an increase of relative overhead). Thus, in order to DTN receiving-holding-forward process to happen properly, it is important to avoid this class of vehicles. Therefore, with this vehicle classification protocols, developers can choose according to the desired application the contact time required to their forwarding strategy to achieve the expected performance.These results show that two main situations are possible to occur at urban environments. (1) When vehicles present short contact times, we can assume they move at higher speed and in opposite traffic directions, which causes short contact time durations lower than 1 second. (2) When vehicles present long contact times, we can assume they move over high or low speed in the same traffic direction. These vehicles can also have either none or very little motion, close enough to keep in contact due to jamming, or because they park at their taxis ranks. This behavior offers TOpp with contact time durations longer than 10 seconds.


#### 5.4.1. Quality of Time (QoT) Classes and Packet Capacity

In order to endorse our statement that contact time is a link quality indicator, we present in Table5 the relation between number of packet transmission capacity and contact time resource that a TOpp is able to provide. With the results that we have discussed at Section 5.4, we named it Quality of Time (QoT) classes.Table 5
QoT classes (number of packets that a sender can transmit according to the contact time with a TOpp).
QoT class
Duration (seconds)
Number of packets (1.5 KB)
A
≥0 and ≤0.1
0 to 25
B
>0.1 and ≤1
>25 to 250
C
>1 and ≤10
>250 to 2500
D
>10 and ≤100
>2500 to 25,000
E
>100 and ≤250
>25,000 to 62,500
F
>250 and ≤500
>62,500 to 125,000
G
>500 and ≤1000
>125,000 to 250,000
H
>1000 and ≤3600
>250,000 to 900,000Therefore, these eight QoT classes (A to H) classify vehicles by the number of packets (IP datagram) with 1.5 KB that a vehicle is able to send accordingly to the QoT class. In short, data at Table5 show the longer the contact time, the greater the number of packets is. Therefore, we state that each application can demand a minimum amount of packets to reach the goals. Hence, this classification allows protocol designers to choose on their protocol forwarding strategy, in which the class of vehicles better fits as the next hop.Contact time is the most valuable resource, which directly affects the quality of a VANET. We suggest combining contact time with other measures can be profitable (e.g., centrality measures and clustering measures). Thereby, we assume that forwarding protocols can provide the demanded link quality to the application goals. Thus, we propose to apply our TOpp concept as a metric to evaluate the resource usage and consumption.


## 5.1. Vehicle Movement Characteristics

There is a direct relation between people’s daily activities and movements of vehicles. People travel around cities and use their transportation infrastructure resources for the purpose of working, studying, leisure, or resting.In the cities, during business hours, there is an increase in the movement of people. The larger is the movement, the larger the number of vehicles is. As movement of people decreases, there is a reduction in the number of vehicles circulating in the streets. Therefore, there are hours with high density and hours with low density of vehicles. There are also transition times, from low density to high density and from high density to low density. At moments of low density, there are few active vehicles and fewer TOpp for communication among them.In the datasets, we could observe that each city presents variances in the density of vehicles. In Figure6, we can observe the seasonal behavior of daily movement by looking at the number of contacts. For either Rome (Figure 6(a)), San Francisco (Figure 6(b)), or Shanghai (Figure 6(c)), there is a reduction in movement during the night (between 0 a.m. and 5 a.m.). In the early morning (around 6 a.m.), activities increase until reaching their peak times and then reducing again.Figure 6
Vehicle movement characteristics. Daily density variance of vehicles makes the TOpp also to vary with the hour of day. (a) Rome, (b) San Francisco, and (c) Shanghai.
(a)
(b)
(c)The fundamental principle of communication requires at least two communicating elements, the hosts, and one connection that allows these hosts to exchange information, a link. We infer that the higher the density, the larger the number of hosts and the greater the possibility of link formation. Consequently, the communication capacity between hosts on the network should increase (initially in this work, we have not considered collisions).Vehicles are hosts, and their encounters over time are TOpps. TOpps are resource providers, and proper use of these resources makes their consumption more efficient. Thus, we have used the transmission data rate to exemplify, define, and quantify the inventory resources generated by TOpp. Section5.2 addresses this issue.


## 5.2. Resource Inventory

Computer networks by definition share resources. Adequate consumption of any available resource in a network is an indicator of the quality of network services. TOpp in the vehicular networks are resource providers, and the TOpp itself is a resource. The use of these TOpp is a performance indicator for forwarding protocols in these dynamic networks.To demonstrate the resource inventory that a vehicular network can offer, we have used the transmission data rate as a measure. According to the IEEE 802.11p standard [2], eight rates are available: 3 Mbps; 4.5 Mbps; 6 Mbps; 9 Mbps; 12 Mbps; 18 Mbps; 24 Mbps; and 27 Mbps. Transmission data rate is an important variable and is directly related to the type of application intended for the vehicular network. This concern is also pertinent to designs of forwarding protocols in V2V environments.In order to obtain the resources inventoryEvi,vj, we have calculated for all TVG H and individually for each vehicle vi, the contact time t ≥ 0 s, with each of their TOpp vj. We have obeyed the criteria for selecting a TOpp according to equation (1). Each contact time is multiplied by the transmission data rate tx. Because it represents the situation that would provide the lowest inventory possible, we chose tx = 3 Mbps. The resource inventory calculation results in the view of the maximum theoretical data volume that TOpps are able to provide. Equation (2) formalizes it:(2)∀TOpp,Evi,vj=vi×tvi,vj×tx,t≥0s.As contact time is an important variable for TOpp, we have plotted in Figure7 the CCDF for the contact time between a sender vehicle and its TOpp. Results obtained from the analysis of the twenty-four TVG show for the three cities that contact time is directly proportional to the radius of signal range. In all traces, regardless of the range, contact time varies from short (less than 1 second) to long (more than 100 seconds). We have used the radius of 1000 meters as a reference to analyze. In the case of Rome (Figure 7(a)), about 1% of cases have contact time greater than 1000 seconds, and about 12% is between 0.1and1second. More than 50% of TOpps are between 1and250 seconds. For San Francisco (Figure 7(b)), the behavior is quite similar to that of Rome, even though it has 2.5 times more vehicles. In Shanghai (Figure 7(c)), even with the largest number of vehicles (24x Roma, 9x San Francisco), contact times are even lower. Less than 30% of cases tend to have contact time longer than 100 seconds. More than 70% is between 0.1and25 seconds.Figure 7
Contact time of a sender vehicle and its TOpp. (a) Rome, (b) San Francisco, and (c) Shanghai.
(a)
(b)
(c)With the results of the inventory calculation, we have quantified the maximum theoretical volume of data that a vehicle would be able to transfer in each TVG. Figure8 shows the amount of data that is possible to exchange by a vehicle and its TOpp. Volume of data is directly proportional to the range.Figure 8
Volume of data per sender vehicle. The individual capacity of a vehicle to generate resources along its TOpp. (a) Rome, (b) San Francisco, and (c) Shanghai.
(a)
(b)
(c)We have observed that the volume of data that each vehicle could transfer relates to two variables: (1) density and (2) contact time. Let us take as reference the radius of 1000 meters. Rome (Figure8(a)) contains the smallest number of vehicles and less than 20% of vehicles showing capacity above 6 GB of data. For San Francisco (Figure 8(b)), there is a scenario with higher density and there are more contacts between vehicles, so 60% of vehicles have at least capacity of 20 GB. For Shanghai (Figure 8(c)), as the contact time is lower, only 20% of the vehicles can carry 25 GB of data.As we have discussed in Section4.2, TOpp can be serial or parallel. In this regard, we present in Figure 9 a comparison of the total data volume available for serial TOpp in relation to the total volume of data for parallel TOpp in each dataset. To obtain these values, it is necessary to add up the individual inventories of each vehicle. In all three cities, the volume of data reaches TB for all ranges. We have observed that for Rome (Figure 9(a)) and Shanghai (Figure 9(c)), for the range of 50 m and 100 m, the total inventory of serial resources is larger than the parallel one. For San Francisco (Figure 9(b)), data volume of parallel TOpp parallel is always greater than the serial TOpp volume of data. Shanghai shows the largest volume of data, reaching the amount bigger than 800 TB. It happens because it is the city with the largest number of taxis contributing to the inventory of resources. However, for all cities, the total inventory of resources in series and in parallel increases as the range increases, and serial resources grow less when compared to resources in parallel. This behavior shows a greater challenge in taking advantage of the availability of the more abundant resources, in the case of parallel TOpp.Figure 9
Data volume available. Calculated at the rate of 3 Mbps. (a) Rome, (b) San Francisco, and (c) Shanghai.
(a)
(b)
(c)Rome (Figure10(a)), San Francisco (Figure 10(b)), and Shanghai (Figure 10(c)) show the distribution of the volume of data that vehicles could use to take advantage from all resources supplied by the TOpp during the day (Figure 10). It shows how each city has its own particularities in the movement trace hour by hour. Thus, the alternations between the hours of the day with more movement and with less movement are more evident.Figure 10
Volume of data per hour of day. Transmitted data volume by vehicles with 1000 meters range and rate of 3 Mbps during the 24 hours of the day. (a) Rome, (b) San Francisco, and (c) Shanghai.
(a)
(b)
(c)This result shows that the amount of TOpp and consequently of resources is not the same throughout the day. Once again, we have shown the importance of forwarding protocols in adapting the density conditions to obtain results that are more efficient.In this section, we have found that there is an inventory of resources available in the vehicular networks. However, for vehicles to communicate, they perform an exchange of messages, known as beacons, that sends information about their situation on the network and allows them to show interest in initiating a data transmission. These beacons consume resources. Therefore, Section5.3, we have analyzed the impact of this exchange of messages on the consumption of vehicular network resources.


## 5.3. Consumption of Resources by Beacon Overhead

A vehicle can broadcast beacons that carry information enough to let other vehicles know which services this vehicle supports. It exchanges beacons using the Wave Short Message Protocol (WSMP) to create a cooperative awareness [2]. Beacons are small packets, which contain a message periodically exchanged among neighbors prior to data transmission [39]. That is the reason why beacons can consume and waste some of the resource while beaconing process.An issue related to beaconing process is the beacon overhead, which increases as the density of vehicles does. Beacon Overhead,BO, is directly proportional to the vehicle count. It is possible to observe looking into its simple mathematical concept (equation (3)) [39], where n is the vehicle count, S is the layer two of ISO/OSI protocol stack beacon size, and T is the periodic beacon propagation time interval:(3)BO=S×nT.In order to discover the beacon overhead impact on the resource inventory consumption, we have adaptedBO definition to calculate the amount of data consumed by beaconing issue. Equation (4) shows the Beacon consumption, BC, definition proposed by us. We denote n as the number of vehicles and S as the link layer (ISO/OSI Layer) (2) beacon size. The average delay interval that a vehicle waits to receive another beacon is T/2. RB is the rate for beacon transmission and RD is the rate for data packet transmission consumed during the process of sending and receiving a beacon between two vehicles. RB and RD are IEEE 801.11p specifications:(4)BC=S×nRB+T2×RD.The IEEE 802.11p beacon size is approximatelyS = 400 bytes of information. Beacons contain information like position, speed, acceleration, and direction of a node. Beacon transmission occurs on a regular interval, at every T = 100 ms, to ensure that all the nodes have an up-to-date cooperative awareness [39–41]. Data rate when handling with beacons by default is RB = 3 Mbps [2]. For packet data rate, we set for calculation purposes RD = 3 Mbps. We have chosen this value because it is the best case with the lower data volume consumption, and other values (4.5, 6, 9, 12, 18, 24, and 27 Mbps) are proportional. At least, vehicle count n depends on the TVG, which varies across the day.Figure11 shows the proportional relation between vehicle count and beacon overhead. For Rome (Figure 11(a)), San Francisco (Figure 11(b)), and Shanghai (Figure 11(c)), the bigger is the number of vehicles, and bigger the beacon overhead is in all cities. As expected, Rome reaches the lower number of beacons, as Shanghai reaches the higher beacon overhead due to the vehicle count in each city. San Francisco and Rome present more variation of beacon distribution, according to the number of vehicle variation during the day. At this point, Shanghai keeps a high number of beacon generation at the most part of the day. The waste caused by beacon consumption varies with time; for Rome (Figure 11(a)), San Francisco (Figure 11(b)), and Shanghai (Figure 11(c)), the higher is the number of vehicles sending beacon messages, the greater is the amount of data occupied.Figure 11
Beacon overhead impact. Relation between beacon overhead and its resource wasting. Primaryy-axis, Beacon Resource Waste (KB), shows the kilobytes of beacon wasted over a network that TOpp could provide gigabyte of data. The secondary y-axis, Beacon Resource Consumption (%), shows the percentage related to the theoretic total volume of data. (a) Rome, (b) San Francisco, and (c) Shanghai.
(a)
(b)
(c)One of our goals were to reveal the impact of the size of the beacon over the TOpp resource in comparison with the total resource inventory showed in Section5.2 (Figure 9). We have shown the impact over serial and parallel TOpps, for the radio range of 50 m (the lower number of TOpp). After all, we can state that beacons consumption (BC) have a very small or nonperceptive impact overall data inventory.


## 5.4. Contact Time as Quality Indicator

Before we consider the TOpp application as a metric, we should look at the histogram of vehicles contact time (Figure12) to understand that time is a quality indicator. Here, we show the analysis for three communication ranges, the shorter (50 m) and the larger (1000 m), that we have former processed from datasets with a common communication range (200 m) well accepted and applied to vehicular simulations at urban scenarios, as made by [42–44]. We have considered all twenty-four hours of the day. Let us observe Rome (Figure 12(a)), San Francisco (Figure 12(b)), and Shanghai (Figure 12(c)) for each communication range.Figure 12
Classes of vehicles in accordance with contact time (in seconds). The eight classes are as follows: (A: ≥0, ≤0.1); (B: >0.1, ≤1); (C: >1, ≤10); (D: >10, ≤100); (E: >100, ≤250); (F: >250, ≤500); (G: >500, ≤1000); (H: >1000, ≤3600). (a) Rome, (b) San Francisco, and (c) Shanghai.
(a)
(b)
(c)At the three datasets, there are situations that repeat themselves. Regardless of the dataset and the range used, more than 90% of vehicles have contact time between of 0.1 and 250 seconds (classesA to E). For Rome and San Francisco, it is possible to observe that all classes maintain the same behavior. Vehicles belonging to classes C (>1 and ≤10 seconds) and D (>10 and ≤100 seconds) are more common. In Shanghai, the behavior is similar to that in the other two cities, but classes B (>0.1 and ≤1 second) and C (>1 and ≤10 seconds) are the most frequent. Therefore, this behavior is helpful for the designers of forwarding messages protocols to choose their strategies, as next hop, the vehicles with better contact time.For Rome, San Francisco, and Shanghai, classesE (>100 and ≤250 seconds), F (>250 and ≤500 seconds), G (>500 and ≤1000 seconds), and H (>1000 and ≤3600 seconds) also have the same behavior and the frequency of vehicles in that the class decreases as the contact time increases. In Shanghai, vehicles with more than 1000 seconds of contact time have percentage close to zero, while in the other two cities, the representability is also low (less than 2%). These are cases of vehicles that can spend a lot of time idling and are not recurring TOpp. Therefore, these cars are not a good choice for forwarding a message.For Rome and San Francisco, irrespective of the range of Class A (≥0 and ≤0.1 seconds), the frequency of vehicles is very close, and it is the class which has lower impact. The vehicles contained in this class have very short contact times, and even allowing the exchange of few packets, they are not a good choice to forward a message, since they are very intermittent types of vehicles. Therefore, it is worth mentioning that the shorter the contact times is, the greater the generation of messages in the network is (an increase of relative overhead). Thus, in order to DTN receiving-holding-forward process to happen properly, it is important to avoid this class of vehicles. Therefore, with this vehicle classification protocols, developers can choose according to the desired application the contact time required to their forwarding strategy to achieve the expected performance.These results show that two main situations are possible to occur at urban environments. (1) When vehicles present short contact times, we can assume they move at higher speed and in opposite traffic directions, which causes short contact time durations lower than 1 second. (2) When vehicles present long contact times, we can assume they move over high or low speed in the same traffic direction. These vehicles can also have either none or very little motion, close enough to keep in contact due to jamming, or because they park at their taxis ranks. This behavior offers TOpp with contact time durations longer than 10 seconds.


### 5.4.1. Quality of Time (QoT) Classes and Packet Capacity

In order to endorse our statement that contact time is a link quality indicator, we present in Table5 the relation between number of packet transmission capacity and contact time resource that a TOpp is able to provide. With the results that we have discussed at Section 5.4, we named it Quality of Time (QoT) classes.Table 5
QoT classes (number of packets that a sender can transmit according to the contact time with a TOpp).
QoT class
Duration (seconds)
Number of packets (1.5 KB)
A
≥0 and ≤0.1
0 to 25
B
>0.1 and ≤1
>25 to 250
C
>1 and ≤10
>250 to 2500
D
>10 and ≤100
>2500 to 25,000
E
>100 and ≤250
>25,000 to 62,500
F
>250 and ≤500
>62,500 to 125,000
G
>500 and ≤1000
>125,000 to 250,000
H
>1000 and ≤3600
>250,000 to 900,000Therefore, these eight QoT classes (A to H) classify vehicles by the number of packets (IP datagram) with 1.5 KB that a vehicle is able to send accordingly to the QoT class. In short, data at Table5 show the longer the contact time, the greater the number of packets is. Therefore, we state that each application can demand a minimum amount of packets to reach the goals. Hence, this classification allows protocol designers to choose on their protocol forwarding strategy, in which the class of vehicles better fits as the next hop.Contact time is the most valuable resource, which directly affects the quality of a VANET. We suggest combining contact time with other measures can be profitable (e.g., centrality measures and clustering measures). Thereby, we assume that forwarding protocols can provide the demanded link quality to the application goals. Thus, we propose to apply our TOpp concept as a metric to evaluate the resource usage and consumption.


## 5.4.1. Quality of Time (QoT) Classes and Packet Capacity

In order to endorse our statement that contact time is a link quality indicator, we present in Table5 the relation between number of packet transmission capacity and contact time resource that a TOpp is able to provide. With the results that we have discussed at Section 5.4, we named it Quality of Time (QoT) classes.Table 5
QoT classes (number of packets that a sender can transmit according to the contact time with a TOpp).
QoT class
Duration (seconds)
Number of packets (1.5 KB)
A
≥0 and ≤0.1
0 to 25
B
>0.1 and ≤1
>25 to 250
C
>1 and ≤10
>250 to 2500
D
>10 and ≤100
>2500 to 25,000
E
>100 and ≤250
>25,000 to 62,500
F
>250 and ≤500
>62,500 to 125,000
G
>500 and ≤1000
>125,000 to 250,000
H
>1000 and ≤3600
>250,000 to 900,000Therefore, these eight QoT classes (A to H) classify vehicles by the number of packets (IP datagram) with 1.5 KB that a vehicle is able to send accordingly to the QoT class. In short, data at Table5 show the longer the contact time, the greater the number of packets is. Therefore, we state that each application can demand a minimum amount of packets to reach the goals. Hence, this classification allows protocol designers to choose on their protocol forwarding strategy, in which the class of vehicles better fits as the next hop.Contact time is the most valuable resource, which directly affects the quality of a VANET. We suggest combining contact time with other measures can be profitable (e.g., centrality measures and clustering measures). Thereby, we assume that forwarding protocols can provide the demanded link quality to the application goals. Thus, we propose to apply our TOpp concept as a metric to evaluate the resource usage and consumption.


## 6. Transmission Opportunity as Metric (TOppM)

All these outcomes show us that there is an offer of TOpp, as well of resources, available to apply over forwarding strategies to VANETs. Therefore, we present the TOpp as a new metric for evaluating the performance of forwarding protocols in vehicular networks as well as for calculating the use of resources within the network.It is possible to observe that, as the communication range increases, the contact time between vehicles also increases. Even the shortest contact duration grants to vehicles enough time to send a layer-two beacon data and some data packets, as we could see in Section5.3.As we have stated previously in Section5.4, time is an important variable for vehicle communication. The longer the contact time, the better the condition for exchanging messages. Time over vehicular networks implies on the quality of the network. The results in Figure 12 have shown us that contact time is not a depleted resource. We have also observed in Section 4 that the number of TOpp (density) increases as the communication range increases. Therefore, we can state that contact time between vehicles is directly proportional to the density and high densities provide enough resources to achieve better results on designing forwarding protocols. However, to use only variables to measure local density (e.g., node degree, node cluster coefficient, and subgraph density), it is not enough to use all the potential resources of TOpp. We believe that, to combine density information with other TOpp variables as buffer occupation, GPS localization and contact time will result in better forwarding solutions (hybrid solutions).In order to apply TOpp as a performance metric, every forwarding protocol should answer these questions. (1) What percentage of the total TOpp is used? (2) What is the amount of resource consumed? (3) What is the maximum consumption of resources that TOpps are capable to use?Most of the forwarding protocols metrics are concerned about obtaining high delivery rates with low overhead, as we have discussed in Section2. Equation (5) permits us to generalize TOpp as Metric to a vehicle vi, TOppMi. Where TOppUi is the TOpp that a vehicle i has used during its interaction in the network (TOppi, as defined in Section 4, is all TOpp which a node has contacted, used, or unused). Therefore, we consider the following available resources computed by our metric: contact time, transmitted data volume, TOpp, GPS Localization, etc.:(5)TOppMi=TOppUi∑inTOppi.TOppMi results on a percentage value, which implies how many TOpps the protocol has used to achieve the forwarding strategy results. This metric measures the quality of any strategy used in a forwarding protocol. It is also possible to obtain with this metric the amount of an individual resource, such as contact time or data volume. It is only necessary to multiply by the value of the resource (e.g., the contact time of TOppUi, the same for data volume or another resource). Therefore, with this metric, it is possible to measure the quality of protocol forwarding strategy in order of comparison to reveal whether these strategies are working well.Protocols designers can also calculate the total transmission opportunity as Metric, TTOppM (Equation (6)), in order to get the total percentage of all vehicles. It is calculated as follows: the sum of individual vehicles TOpp usage divided by the sum of all TOpp (used or not) of all vehicles, where i is each vehicle, n is the nth vehicle, and m the mth TOpp:(6)TTOppM=∑i=1nTOppUi∑i=1n∑1mTOppi.In short, TOppMi is nonsimulator dependent and can be implemented over any forwarding protocol with no concern about decrease in the performance of the custom strategy proposed in each work. The needed data (e.g., contact time and number of contacts) to apply our metric are easily obtained from beacon exchange between two nodes. Either layer two beacons or hello world beacons can carry lots of information. Our metric has a limitation, it is only applicable over beacon-based [19] forwarding protocols.


## 7. Conclusion

In this work, we have presented the concept of TOpp in V2V vehicular networks and the importance of their adequate use for the design of forwarding protocols.In our first contribution, we have performed the analysis of three real taxis database (Rome, San Francisco, and Shanghai) to show the TOpp of each sender vehicle. We have classified these opportunities into serial TOpps and parallel TOpps. We have shown that the number of opportunities increases according to the range of the radio signal (IEEE 802.11p). We have discussed how important it is for forwarding protocols to identify the density situation (e.g., sparse or dense), in order to choose the most appropriate strategy for forwarding the message.In our second contribution, we have shown the appropriate use of TOpp evaluate the performance of forwarding protocols and to calculate the resource usage. We have come to this conclusion after analyzing the volume of data transmission that vehicles can transfer. We have shown that if the forwarding strategy does not use the TOpp properly, resources can be wasted or misused. Therefore, in a scenario such as data transport, the better chosen the TOpp the better will be the performance of the forwarding protocol. Finally, we have also investigated the impact of beaconing on resource wasting and we have observed that this impact is not significant related to the total resource inventory.With our outcomes, we can state that the quality of a strategy or even the quality of a vehicular network does not depend on the density of nodes or edges but depends on the contact time between vehicles and their TOpp. Temporal features are most important to develop robust forwarding solutions. Therefore, we have classified vehicles into eight classes of contact time to show that there are vehicles which can provide more quality (quality of time (QoT)) to communicate in VANET environments.Researchers can use these results to choose the parameters for simulation scenario configuration. It may be useful to decide which radio signal range to set up. In addition, depending on the type of application, it can help to define the size of the data packets according to the transfer rate and the contact time among vehicles. Finally, we also offer a conceptual content for beginners on forwarding in VANETs who need to understand the dynamics of vehicles movement and acquire comprehension about how vehicles interact with each other in order to design new protocols.As future work, we will run simulations with some of the commonly applied forwarding strategies in order to show how these strategies make use of TOpp and identify, by computing social and probabilistic features, and which type of TOpp nodes tend to be chosen. We also intend to develop a social forwarding strategy that fits density conditions of the vehicles. Next, we will specify a forwarding protocol for message dissemination that properly uses our forwarding strategy to obtain the best usage of TOpp and resources. After that, TOppMi would use to evaluate our proposals.



---

*Source: 1708437-2019-12-24.xml*