Data Rate Selection Strategies for Periodic Transmission of Safety Messages in VANET

Abstract

Vehicular ad hoc networks (VANETs) facilitate communication among vehicles and possess designated infrastructure nodes to improve road safety and traffic flow. As the number of vehicles increases, the limited bandwidth of the wireless channel used for vehicle-to-vehicle (V2V) communication can become congested, leading to packets being dropped or delayed. VANET congestion control techniques attempt to address this by adjusting different transmission parameters, including the data rate, message rate, and transmission power. In this paper, we propose a decentralized congestion control algorithm where each factor adjusts the data rate (bitrate) used to transmit its wireless packet congestion based on the current load on the channel. The channel load is estimated independently by each vehicle using the measured channel busy ratio (CBR). The simulation results demonstrate that the proposed approach outperforms existing data rate-based algorithms, in terms of both packet reception and overall channel load.

1. Introduction

There are many potential reasons why a traffic accident may occur, such as dangerous road conditions and drivers who speed or drive under the influence of alcohol or drugs, which can cause death and the destruction or damage of property [1]. Vehicular ad hoc networks (VANETs) [2], a subset of mobile ad hoc networks (MANETs) [3], are essential to produce an intelligent transportation system (ITS) [4] with the goal of improving safety on the road. VANETs generally include high-speed mobile communication nodes, which are vehicles that can travel at high velocities, and infrastructure nodes, such as roadside units (RSUs). Some characteristics often seen in VANETs are rapid changes in topology, a high density of nodes in the network, and a lack of energy restrictions [2,5]. When vehicles in a VANET directly communicate with each other using wireless technology, it is known as vehicle-to-vehicle (V2V) communication [5], which will be the main focus of this paper. VANET also supports vehicle-to-infrastructure (V2I) and infrastructure-to-infrastructure (I2I) communications, along with V2V.

The two main categories of VANET applications are service and safety applications [6]. Examples of service applications are route guidance, traffic optimization, media, internet connectivity, and payment services. VANETs based on 5G can provide reliable communication and quality of experience (QoE) [7] for services such as real-time video streaming, requiring low latency and high bandwidth [8,9]. VANET safety applications include features such as forward collision warnings, curve speed warnings, pre-crash awareness, emergency brake lights, and lane change warnings. Many safety applications depend on beacons sent periodically by each vehicle, where each beacon contains information about the status of the vehicle that sent it. These beacons, referred to as basic safety messages (BSMs) in the United States [10] and cooperative awareness messages (CAMs) in Europe [11], contain information that is important for the surrounding vehicles to be aware of, such as the vehicle’s current position, speed, acceleration, and heading. Vehicles send BSMs through the channels allocated in the DSRC/WAVE system [12], and they are processed using the on-board units (OBUs) that are placed inside each vehicle.

In the United States, the FCC has allocated 75 MHz of spectrum in the 5.9 GHz band for dedicated short-range communication (DSRC) [13]. This spectrum is divided into seven 10 MHz channels with associated guard bands, from which channel 172 is assigned for the exchange of safety messages [14]. Many VANET simulations [13,15,16] and some standardization activities [17] use a BSM transmission data rate of 6 Mbps, although some papers have considered other data rates; for example, a data rate of 3 Mbps was used in Refs. [18,19] because of its low signal to interference and noise ratio (SINR) requirement. The typical BSM transmission rate for vehicles is 10 Hz, resulting in one BSM being sent every 0.1 s; however, an increase in vehicle density can cause a heavy channel load. Channel congestion occurs when the load is so high that the nodes (vehicles) have to compete with each other in order to access the channel [20]. A channel load of 40% or higher results in a rapid increase in the number of packet collisions and delays [21], so it is important to implement appropriate congestion control methods in order to avoid the channel being congested and ensure that messages are delivered properly.

Many VANET congestion control algorithms attempt to reduce the channel load by lowering the BSM transmission rate, transmission power, or a combination of both, but this can come at the cost of significantly lowering the awareness of the surrounding vehicles. Some recent papers have examined the effects of adjusting the BSM transmission data rate (i.e., bitrate) on congestion. For the remainder of the paper, we will use the terms data rate and bitrate interchangeably. Packets sent with lower bitrates take longer to send but have a lower SINR threshold for proper frame reception [22]. This means that BSMs transmitted with a lower bitrate have a lower chance of becoming corrupted due to noise interference and are more likely to be received at longer distances. Conversely, packets that are sent with a higher bitrate are sent faster, reducing channel congestion, but have a greater chance of not meeting the required SINR threshold. Therefore, when a vehicle sends a BSM, it should use a bitrate that can balance the desired characteristics of having low channel congestion and also having a high chance of the beacon being successfully received by nearby vehicles.

In this paper, we propose a new congestion control algorithm that selects a suitable bitrate value for each BSM sent, determined by the current channel busy ratio (CBR). This differs from existing algorithms, which typically change the bitrate by one level at a time, regardless of how high or low the CBR is, as our proposed algorithm changes the bitrate to whichever value it estimates to be the most appropriate based on the current CBR, even if it is multiple levels away from the current bitrate in use. This results in the channel congestion changing more quickly, so it will converge to the desired level much faster. This higher convergence speed also makes the vehicles more efficient at sending packets, which leads to fewer lost beacons and a higher packet delivery ratio. The results of our simulations demonstrate that our proposed method can outperform existing bitrate-based approaches in both successful packet delivery rate and overall channel congestion.

The rest of the paper is organized as follows. In Section 2, we review some existing VANET congestion control approaches, and we present our proposed congestion control algorithm in Section 3. We discuss the results of our simulations in Section 4, and in Section 5, we present our conclusions and give some directions for future work.

2. Background Review

VANET congestion control is an important and active area of research, and has received significant attention in recent years, for both safety and comfort applications [23,24,25]. Integrating 5G technology with VANET communications for future applications has received significant research attention [26], including issues related to security and privacy [27,28]. In regard to safety applications, the two types of safety messages are event-driven messages and periodic messages, or basic safety messages (BSMs). Event-driven messages are sent whenever certain events, such as traffic accidents or road hazards, are detected, while BSMs are sent at regular intervals by each vehicle in the network, regardless of the road conditions. This means that as the vehicle density increases, the total number of BSMs being transmitted within the network increases proportionally. According to Ref. [21], the allotted channel bandwidth can quickly become congested from increases in vehicle density, even in simple vehicle networks. In Ref.  [29], the authors aim to alleviate congestion by finding the best distribution over EDCA access categories. In Ref. [30], the authors propose congestion control for vehicular safety applications that considers different quality of service needs based on vehicle context, such as the relative position and speed of surrounding vehicles. In Ref. [31], the authors investigate how different parameters for congestion control impact the stability of platooning systems. The work in Ref. [32] provides a comparative study of the different dynamic congestion control (DCC) approaches in terms of CBR, position error, and awareness range.

In this section, we will first briefly review some important techniques that use message rate or transmission power to control congestion, including hybrid approaches, which use a combination of these parameters to reduce the channel load. Then, we will focus on approaches that adjust the data rate to reduce congestion, both by itself and in combination with other parameters.

2.1. Power- and Message Rate-Based Approaches

Transmission power affects the distance over which a message can be successfully received by another vehicle. A higher transmission power increases the range across which a message can be received, so vehicles that are farther away can receive it. Controlling the transmission power based on the level of channel congestion involves reducing the power when the channel is congested; this results in vehicles only receiving messages from vehicles that are nearby. Although this limits the vehicle’s awareness, it also serves to reduce congestion, and nearby vehicles are the most important vehicles to receive messages from because they have the most immediate impact on a vehicle.

In Ref. [33], the vehicles adjusted their transmission power according to their speed, which resulted in a reduction in the beacon error rate (BER) and CBR. In Ref. [34], vehicles used different levels of transmission power depending on the local vehicle density. Vehicles adapted to high densities by using a low power level, while medium and high densities resulted in the use of a medium and high power level, respectively. In Ref. [35], the authors proposed the distributed fair transmit power adjustment for VANET (D-FPAV) algorithm, which adjusted the transmission power based on the vehicle density and the traffic in the application layer. In Ref. [36], the authors proposed the CLF-BTPC algorithm, where all vehicles started with the same initial value for the transmission power, and the algorithm then calculated a forecasted value for the congestion and an assigned power based on this value. All vehicles in the network would be assigned the new power value; if the forecasted value was greater than a predefined threshold value, the assigned power would be less than the current power, and it would be greater if the forecasted value was less than the threshold. In Ref. [37], the authors set out to increase the awareness quality. A random transmission power level was selected for each packet transmission, and each vehicle controlled its power selection by using a complementary cumulative distribution function (CCDF) due to its strong correlation with awareness quality.

While the default transmission rate for BSMs is 10 Hz, message rate-based approaches change the frequency at which a vehicle sends out BSMs as an adaptive response to its surroundings and the congestion of the channel. As the channel congestion increases, the message rate is reduced accordingly, with the goal of reducing the channel load. The main limitation of these approaches is that reducing the message rate of a vehicle also restricts the frequency at which it updates other vehicles on its status, so the vehicles will be less aware of their surroundings. This reduces the safety of the network, since current information and frequent updates from the vehicles are vital to most safety applications. Some well-known congestion control algorithms using message rate control are discussed below.

In Ref. [16], the authors proposed a new scheme called linear message rate control (LIMERIC), where vehicles can sense the current channel load and adapt to changes by adjusting their message rates to meet a predefined required CBR value. In Ref. [38], the authors proposed a method that extended the LIMERIC algorithm by using a predefined target value to control the total channel load. In Ref. [39], the authors used a function of both the channel load (the LIMERIC component) and vehicle dynamics (the suspected tracking error (STE) component) to calculate the transmission rate. The LIMERIC component calculates an ideal message rate based on the channel load using the LIMERIC algorithm, while the STE component estimates the time when the CBR is expected to reach a given threshold and ensures that the next packet is sent no later than the estimated time. In Ref. [40], the authors proposed a new congestion control strategy called periodically updated load-sensitive adaptive rate control (PULSAR), where vehicles measure the current CBR at regular intervals and compare it with a predefined target value. The vehicle would lower its transmission rate if the measured CBR was greater than the target value. This method would result in keeping the CBR below the target value in order to control channel congestion. In Ref. [41], the vehicles send packets which have beacon transmission rate (BTR) adjustment requests attached, which tell the receiving vehicles to raise or lower their BTR. This results in the vehicles broadcasting their beacons using varying message rates. In Ref. [42], the beacon messages were scheduled according to the priorities and transmission power. Messages were dequeued automatically according to the priority queue model. In Ref. [43], the congestion control scheme adjusts the message rate as it adapts to changes in the local vehicle density. In Ref. [44], the authors propose a non-cooperative game approach where each vehicle behaves as a selfish node, requesting high beacon rates. A utility function, based on vehicle priority and contention delay, is used to obtain the optimal rates. In Ref. [45], the authors propose a congestion control algorithm that adjusts the rate for safety message transmissions based on traffic density. A car ID-based randomized back-off code is used to reduce the likelihood of collision due to identical back-off numbers. In Ref. [46], the authors assign a weight to each node based on quality of vehicle links and then use a greedy algorithm to assign suitable beacon rates to nodes based on the weights. In Ref. [47], a novel approach that investigates beacon transmission from the perspective of information loss is introduced, and a greedy rate adjustment algorithm to minimize information loss is presented.The work in Ref. [48] formulates message rate selection as a Markov decision process (MDP), and the vehicle learns the appropriate rate to use under different conditions, using a reinforcement learning algorithm.

Some recent congestion control approaches have suggested methods that involve a combination of multiple control parameters, such as both transmission power and message rate, instead of just one, to effectively reduce the channel load. These are called hybrid approaches. In Ref. [49], two transmission power levels were used, one for high power and one for low power. A designated proportion of the BSMs sent by each vehicle would be sent with high power, while the rest would be sent using low power. Combined with LIMERIC, the proposed method used transmission power and message rate to reduce congestion and yielded a low BER. In Ref. [50], the authors proposed the combined power and rate control (CPRC) algorithm, which adjusted the message rate and transmission power in a single loop of the algorithm. CPRC resulted in cooperative behavior among the vehicles, as it increased the message rate of vehicles involved in a potentially dangerous situation while decreasing the transmission power of the vehicles that were not directly involved. As a result, this prevented the channel load from exceeding a predefined threshold value. In Ref. [51], the authors proposed the random transmission power control (RTPC) algorithm, which was combined with transmit rate control (TRC). This method involved increasing the message rate until the target channel load value was reached. In Ref. [52], the authors proposed a cooperative game theory-based approach to jointly control the beacon rate and transmission power. In this approach, each vehicle controls its own share of the bandwidth based on its application requirements. The work in Ref. [53] uses different machine learning algorithms to predict the vehicle density, and then adjusts the vehicle’s transmission rate and power accordingly to ensure awareness and reduce channel load. In Ref. [54], the authors use a Q-learning approach to leverage the trade-off between transmission rate and power to balance the channel load and improve the packet delivery ratio. In Ref. [55], the authors present two DCC mechanisms that adapt message rate and data rate combined with the transmit power control mechanism to improve channel utilization and load.

2.2. Data Rate-Based Approaches

The eight possible data rates that the DSRC standard has specified can be used for BSM transmissions are 3, 4.5, 6, 9, 12, 18, 24, and 27 Mbps; the most commonly used of these is 6 Mbps [15]. Data rate-based approaches alter the bitrate used when transmitting BSMs, and they have recently been garnering more focus [15]. The work in Ref. [56] compares power control- and data rate control-based approaches, and shows that the latter can outperform the former in a variety of different scenarios, such as when congestion occurs in a localized cluster of vehicles.

In Ref. [57], only the 3, 6, 9, and 12 Mbps data rates were considered to avoid flooding. There were four possible states for the vehicles, one for each data rate, and the state of the vehicles was determined by the channel load. The vehicles would use the data rate that corresponded to the state they were currently in. In Ref. [58], the CBR was measured at regular intervals and vehicles transitioned to different states depending on the CBR, where the state of a vehicle determined the data rate that it used. If a vehicle measured the current CBR to be greater than a predefined threshold, it would move to a state that used a higher data rate, and if it calculated the CBR to be less than a given threshold, it would move to a state that used a lower data rate. In Ref. [59], the authors defined a combined message and data rate-based algorithm (MD-DCC) that can lead to increased supported vehicle density, and in Ref. [60], they explored how MD-DCC can coexist with LIMERIC, allowing vehicles to choose either one at different vehicle densities. In Ref. [61], the authors proposed a hybrid method that involved managing a combination of the data rate and the message rate. The message rate was reduced in order to keep the beacon frequency above the required minimum value, while the data rate was increased during periods of high vehicle density to provide a greater channel capacity.

This paper also focuses on data rate-based distributed congestion control, and a preliminary version of this work with initial results was presented in Ref. [62]. In this paper, we present our updated literature review, provide a more detailed description of our algorithm, and include a study of how the selection of the congestion threshold values affects its performance. This paper also provides new simulation results with different packet sizes and beacon intervals, along with an analysis of the distribution of received packets based on distance from the sender.

3. Proposed Data Rate-Based Congestion Control (DRCC) Approach

The amount of time it takes to transmit a packet of a given size decreases as the bitrate used for transmission is increased. Therefore, using higher bitrates can help to reduce the channel load by lowering the total transmission time for each packet. However, higher bitrates are also associated with reduced signal strength, so such packets may not be able to reach distant vehicles. As a result, it is important to carefully choose the transmission bitrate in order to properly balance channel load as well as vehicle awareness.

In the proposed data rate-based congestion control (DRCC) approach, each vehicle must first estimate the current load on the channel allocated for BSM transmissions, and then adjust the transmission rate for sending its own BSMs accordingly. This is a decentralized approach that does not require any coordination with neighboring vehicles. Each vehicle estimates the channel load in terms of its calculated CBR value. The CBR represents the percentage of time the channel was sensed as “busy” by a vehicle’s OBU over a given interval. In our implementation, before sending each BSM, we calculated the average CBR over the period of time since the previous BSM transmission. The goal of the DRCC algorithm is to keep the measured CBR between two specified thresholds ($uppe{r}_{th}$ and $lowe{r}_{th}$) by suitably adjusting the bitrates used to transmit BSMs. When there is very little traffic, the measured CBR will be low, and the transmission bitrate can be reduced to allow the packets to reach the more distant vehicles. On the other hand, when the measured CBR is high, a higher bitrate is used, which results in faster packet transmissions; however, the signal strength will be low, and such transmissions will not be successfully received by distant vehicles.

Algorithm 1 shows an overview of the proposed DRCC algorithm. Step 1 is the initialization phase, which is performed only once. After that, Steps 2–27 of the DRCC algorithm are executed each time a new BSM is to be transmitted. During the initialization phase, we first select the upper ($uppe{r}_{th}$) and lower ($lowe{r}_{th}$) limits of desired channel load based on application needs (Step 1a). Next, in Step 1b, we specify the list of allowed bitrates (B) that can be used for BSM transmission and the parameter maxlevel, which is the highest possible index value for accessing items in B. Based on the available OFDM modulation schemes and coding rates in IEEE 802.11p, the following eight bitrates (in Mbps) are available for the 10 MHz DSRC channel: 3, 4.5, 6, 9, 12, 18, 24, 27 [22]. In our simulations, the performance of 4.5 Mbps and 12 Mbps rates were very similar to 6 Mbps and 9 Mbps, respectively; meanwhile, 27 Mbps performed poorly with low reception rates due to the high SINR required for correct reception at these rates. Therefore, we have selected B = [3, 6, 9, 18, 24] as the list of allowed bitrates for our algorithm, and set $maxlevel=len\left(B\right)-1=4$. Finally, in Step 1c, we set the parameter $congestion\_limit$, where $0\le congestion\_limit\le 1$, which is the maximum acceptable channel load when choosing a new transmission bitrate. For example, if $congestion\_limit=0.95$, then when selecting a new bitrate, we must check to ensure that the expected CBR using this bitrate will not exceed 95% of the $uppe{r}_{th}$ value. The rationale for this is to allow some margin for increased channel load without having to increase the bitrate again too soon.

After initialization, prior to sending each BSM, the algorithm calculates the current measured CBR value ($cbr$). Additionally, the bitrate used previously is specified using the parameter level, $0\le level\le maxlevel$, which is an index for list B. For example, if $level=2$, then the corresponding bitrate is $B\left[2\right]$ = 9 Mbps. These two values are given as inputs for DRCC, which then determines the appropriate bitrate to use for sending the next BSM. This same process is executed in the OBU of each participating vehicle, independently of the other vehicles.

If the OBU determines that the current CBR ($cbr$) is lower than $lowe{r}_{th}$ (Step 2), it indicates that the channel bandwidth is being under-utilized. In this case, Steps 3–12 attempt to select a lower bitrate for the next transmission. Steps 3 and 4 set the previous BSM bitrate as the new value. This will be used only if a lower bitrate cannot be found. Steps 5–11 check each bitrate in order, starting with the lowest possible bitrate from $B\left[0\right]$, to see if the expected CBR remains below $congestion\_limit\times uppe{r}_{th}$ when using that bitrate. If so, it is selected immediately (Steps 7–9); otherwise, the next bitrate is checked, and this process continues up to $B\left[level\right]$. If no lower bitrate satisfying the condition in Step 6 can be found, then the new bitrate remains the same as the previous bitrate.

Steps 13 to 23 are executed if the current CBR ($cbr$) exceeds $uppe{r}_{th}$ (Step 13). A higher CBR value indicates channel congestion, and the DRCC algorithm attempts to reduce this by selecting a suitable faster bitrate, if available (Steps 14–23). First, the highest possible bitrate is set as the new value to be used (Steps 14 and 15) in case none of the available bitrates satisfy the condition in Step 17. Steps 16–22 iterate through each potential bitrate value, and the first bitrate to satisfy the condition in Step 17 is selected, leading to the termination of the loop. This ensures that the lowest possible bitrate meeting the expected CBR constraint is selected as the new bitrate.

Algorithm 1 Data Rate-Based Congestion Control (DRCC) Algorithm.

1: Initialization    a. Select $uppe{r}_{th}$ and $lowe{r}_{th}$,    b. Set list of allowed bitrates B and $maxlevel$    c. Set $congestion\_limit$, the maximum expected congestion when updating the bitrate Input:  Index indicating which bitrate in B is currently being used ($level$), and the current CBR ($cbr$). Output:  Updated bitrate values and the index of B indicating the new bitrate to use ($newlevel$)   2: if $cbr<lowe{r}_{th}$ then   3:    $newlevel=level$   4:    $bitrate=B\left[newlevel\right]$   5:    for $i\in (0,level)$ do   6:      if $cbr\times (B\left[level\right]/B\left[i\right])<congestion\_limit\times uppe{r}_{th}$ then   7:         $newlevel=i$   8:         $bitrate=B\left[i\right]$   9:         break 10:      end if 11:    end for 12: end if 13: if $cbr>uppe{r}_{th}$ then 14:    $newlevel=maxlevel$ 15:    $bitrate=B\left[newlevel\right]$ 16:    for $i\in (level+1,maxlevel)$ do 17:      if $cbr\times (B\left[level\right]/B\left[i\right])<congestion\_limit\times uppe{r}_{th}$ then 18:         $newlevel=i$ 19:         $bitrate=B\left[newlevel\right]$ 20:         break 21:      end if 22:    end for 23: end if 24: if $lowe{r}_{th}\le cbr\le uppe{r}_{th}$ then 25:    $newlevel=level$ 26:    $bitrate=B\left[newlevel\right]$ 27: end if

Finally, Steps 25 to 27 are executed when the CBR ($cbr$) falls between high ($uppe{r}_{th}$) and low ($lowe{r}_{th}$) CBR thresholds, i.e., when the current bitrate is able to maintain the CBR within the desired thresholds. In this case, the new bitrate selected is the same as the previous one (Steps 25–26). Once the value of the new bitrate has been selected by the DRCC algorithm, it is used by the vehicle OBU to transmit the next BSM. We note that in our approach it is possible that the bitrate used by a vehicle will change frequently. However, we consider this to be acceptable, as the goal is not to have different vehicles converge to one common acceptable bitrate. Rather, each vehicle independently chooses the bitrate for its next BSM, based on observed CBR. If the channel conditions change during the beacon interval, the next BSM can be transmitted at a different bitrate.

4. Simulation Results

4.1. Simulation Setup

To evaluate the performance of the proposed DRCC approach, we used a simulation environment consisting of three different software packages to generate the traffic model and simulate the wireless communication between vehicles. The traffic simulator used was Simulation of Urban Mobility (SUMO) [63]. SUMO is a free and open source microscopic simulation software implemented in C++ that can be used to simulate vehicles, pedestrians, public transport, etc. The network simulator used was OMNeT++ [64], which is a modular component-based C++ simulation library and framework. OMNeT++ was used for simulating the wireless transmission protocols. Tying these two software packages together is VEINS, which is a framework that includes models for making traffic simulations realistic and providing communication between SUMO and OMNeT++ by means of the traffic control interface (TraCI). VEINS contains a basic implementation of the IEEE 802.11p and IEEE 1609 protocols that facilitates the testing of VANET protocols, and provides communication between SUMO and OMNeT++ by means of a TCP socket connection.

We considered a 1000 m long four-lane highway composed of two lanes in either direction, with 80 stationary vehicles placed 50 m apart along the highway. To generate different levels of channel load, we used different combinations of BSM packet sizes and beacon intervals, as indicated below:

• LOW load: BSM packets of 256 bytes broadcast at intervals of 0.1 s and 0.05 s.
• MEDIUM load: BSM packets of 1024 bytes and 256 bytes broadcast at intervals of 0.1 s and 0.02 s, respectively.
• HIGH load: BSM packets of 1024 bytes broadcast at intervals of 0.05 s.

The parameters for our simulations are summarized in

Table 1. Simulation parameters.

Name	Value
Maximum beacon interval	100 ms
Minimum beacon interval	20 ms
Fixed transmission power	20 mW
BSM size	256 B, 1024 B
Minimum power level	−110 dBm
Noise floor	−98 dBm
Vehicle number	80
Highway length	1 km

.

4.2. Evaluation of DRCC for Different Threshold Values

As discussed in Section 3, the upper and lower threshold values are used to control the performance of the DRCC algorithm. These two values determine the upper and lower limits of the “acceptable” CBR levels experienced by the vehicles. In this section, we compare the performance of the DRCC approach using five different combinations of $uppe{r}_{th}$ and $lowe{r}_{th}$. The different variations of DRCC are numbered as DRCC1–DRCC5, based on the selected threshold values, as shown in

Table 2. Threshold values for DRCC.

	DRCC1	DRCC2	DRCC3	DRCC4	DRCC5
$lowe{r}_{th}$	0.2	0.3	0.3	0.5	0.6
$uppe{r}_{th}$	0.4	0.5	0.7	0.7	0.8

.

Figure 1 shows a comparison of the different DRCC versions in terms of the average channel load. We can see that DRCC1 consistently maintains the lowest CBR values and DRCC5 produces the highest, as expected. For low channel loads, all versions are able to keep the CBR below their target $uppe{r}_{th}$ values. As the load increases, DRCC1 and DRCC2 exceed their $uppe{r}_{th}$ but still maintain a lower CBR compared to the other versions.

Figure 2 compares the total number of received packets for the five DRCC variations. It is clear that as the thresholds increase, the total number of received BSMs also increases and higher values of $uppe{r}_{th}$ are produced. Also, as the packet size is increased from 256 bytes to 1024 bytes, the number of received packets decreases significantly for the same number of sent packets and the same beacon intervals. This is due to the higher channel loads and consequent packet collisions and dropped packets. It is also important to note that a higher number of received packets for DRCC4 and DRCC5 may not mean they are always the best choice, as many of these may be from vehicles farther away rather than from nearby vehicles.

In the remaining sections, we will use DRCC1 and DRCC5 for comparison with existing approaches.

4.3. Comparison of Channel Congestion

In this section, we compare the average CBR obtained using the proposed DRCC approach, with constant bitrates of 3, 6, 9, 18, and 24 Mbps, with two existing data rate-based congestion control algorithms (data rate-decentralized congestion control (DR-DCC) [58] and transmission data rate control (TDRC) [57]) available in the literature.

Figure 3 shows the average CBR experienced by the vehicles using DRCC1, DRCC5, and the constant bitrates. As expected, the highest and lowest CBR values are always obtained with bitrates of 3 Mbps and 24 Mbps, respectively. For low channel loads, DRCC5 maintains the same CBR as 3 Mbps, while the CBR for DRCC1 is slightly lower, but still higher than the 6 Mbps case. This makes sense because for low loads, further lowering of CBR is not beneficial, so DRCC tries to achieve a better packet reception. As the channel load increases, the CBR, when using low bitrates, reaches unacceptable levels (over 0.8), and the performance of DRCC approaches that of the higher constant bitrates. Therefore, DRCC is able to adapt to keep the CBR within the acceptable levels.

Figure 4 shows the average CBR for DRCC1 and DRCC5, compared to the two existing approaches, under different channel loads. With 256-byte packets sent with a beacon rate of 10 BSMs per second, TDRC has very low CBR values (less than 0.2), while the other approaches have a CBR in the 0.4–0.5 range. We can see that TDRC has the lowest CBR (less than 0.2) when channel load is very light, but as the channel load increases, TDRC yields unacceptable CBR levels, consistently above 0.8. This is likely due to the fact that TDRC uses lower bitrates as CBR increases, which may exacerbate congestion. The performances of DRCC5 and DR-DCC are rather close, and DRCC1 has the lowest CBR values for medium to high channel loads, which remains below 0.6 even for the highest loads.

4.4. Comparison of Received Packets

Figure 5 shows the total number of packets received with different constant bitrates and the DRCC approach. For low congestion scenarios, such as with a packet size of 256 bytes and a beacon interval of 0.1 s, the packet reception is better with lower bitrates of 3 or 6 Mbps. The performances of both versions of DRCC (DRCC1 and DRCC5) are very close to the best results, while higher bitrates of 18 or 24 Mbps show a significant decrease in received packets. On the other hand, bitrates of 9 or 18 Mbps perform better for very high congestion, such as with a packet size of 1024 bytes and a beacon interval of 0.05 s. In this case, DRCC5 is very close to the highest value, while the performance of DRCC1 is slightly lower, and the performance with a constant bitrate of 3 Mbps is the worst. These results indicate the advantages of using an adaptive congestion control technique, such as DRCC, over constant bitrates, since the channel load can vary widely over time.

Next, we compare the proposed DRCC approach with two other existing data rate control approaches: data rate-decentralized congestion control (DR-DCC) [58] and transmission data rate control (TDRC) [57]. Figure 6 compares the total number of BSMs received under different channel loads, using DRCC1, DRCC5, DR-DCC, and TDRC. Under low loads, the performances of the first three approaches were very similar, while TDRC received significantly fewer packets. For medium and high loads, DRCC5 and DR-DCC were similar, with DRCC5 performing slightly better and receiving 4–5% more packets compared to DR-DCC. The performance of DRCC1 was somewhat lower, and TDRC had the worst performance in all cases except for one (with a packet size of 256 bytes and a beacon interval of 0.05 s). In general, we can see that for most approaches, the total number of received packets increases as beacon interval decreases (which is expected) under low/moderate loads. It is also interesting to note that for higher loads (with 1024-byte packets), reducing beacon interval does not increase packet reception. This is due to increased CBR leading to higher rates of packet collisions.

The total number of received packets can be an important metric for evaluating different congestion control algorithms. However, it is also important to analyze where those packets are originating from. For each vehicle receiving BSMs (ego vehicle), we divided its neighboring vehicles into three groups. The first (nearest) group consists of vehicles that are at a distance of 100 m or less from the ego vehicle. The second (third) group consists of vehicles that are at a distance of 100 m to 300 m (300 m to 500 m) from the ego vehicle. These threshold distances for grouping neighboring vehicles were chosen by us to show the distribution of received BSMs from vehicles at different distances. In general, messages from neighboring vehicles that are closer to the ego vehicle are more relevant than those from distant vehicles. Figure 7 shows the average number of messages from vehicles at different distances for the proposed algorithm, constant bitrates, and other existing techniques. We can see that under high loads none of the approaches receive packets beyond 300 m; however, for TDRC, there are no received packets beyond 300 m for TDRC even under low loads. This is because TDRC uses a higher data rate in such cases compared to other approaches, resulting in low CBR (<0.2) and higher RSSI requirements. Typically, the nearest vehicles, i.e., within a radius of 100 m from the ego vehicle, have the greatest impact. For the lowest congestion case (packet size of 256 bytes and beacon interval of 0.1 s), this is almost the same for all approaches, but for the highest congestion case (packet size of 1024 bytes and beacon interval of 0.05 s), DRCC1 has the best performance, even though the total number of received packets is lower. The number of packets received from vehicles within a 100 m radius by DRCC1 is 2.5% higher than the next highest value for DR-DCC and about 7% higher compared to DRCC5. Therefore, it is important to choose the appropriate version of DRCC based on the application needs.

5. Conclusions and Future Work

In this paper, we present a new decentralized, data rate-based congestion control (DRCC) algorithm that dynamically adjusts the data rate used for each BSM transmission based on the current channel loads. The performance of the proposed approach was compared to both constant bitrates as well as some existing data rate control approaches. The simulation results indicate that DRCC is able to maintain the channel loads at or near the desired levels. One advantage of the proposed approach is that the upper and lower threshold values can be selected based on the current channel load and the desired CBR level. The proposed approach also achieved the highest packet reception ratio, compared to the other approaches, for medium to high traffic loads. For future work, we are planning to adaptively select the transmission power and data rate for BSM transmissions based on each vehicle’s current context, e.g., speed, acceleration, surrounding vehicle density, etc., in addition to the channel load. One important assumption of our approach is that all vehicles are operating in an ”honest” manner, i.e., if it observes a high CBR, it will try to update its bitrate accordingly, and will not continue to use a lower bitrate. Detection of ”malicious” vehicles that do not follow this principle and try to claim an unfair portion of the bandwidth is out of the scope of this paper, but is another interesting direction for future work.