6.1. Reliability and Redundancy
Figure 3 showcases several vital Safety Applications, which we'll delve into below:
Forward Collision Warning (FCW) – Pictured in Figure 3a, the FCW alerts the driver of the Host Vehicle (HV) about a potential rear-end collision with a Rear Vehicle (RV) ahead, moving in the same lane and direction. This system proves especially valuable when the HV is closing in on a vehicle that's either decelerating or has come to a halt.
Emergency Electronic Brake Lights (EEBL) – As illustrated in Figure 3b, the EEBL is somewhat of a toned-down version of FCW. Upon receiving data that an RV ahead is braking sharply, it prompts the HV driver to slow down. The significance of this feature is amplified when an obstruction (like a big truck) limits the HV driver's view.
Do Not Pass Warning (DNPW) – Depicted in Figure 3 c, DNPW sounds an alert to the HV driver during an overtaking maneuver if there's an incoming vehicle from the opposite direction.
Blind Spot Warning + Lane Change Warning (BSW+LCW) – Demonstrated in Figure 3d, this Safety Application cautions the HV driver wanting to switch lanes if another vehicle—moving in the same direction—is present in their blind spot.
It's imperative to note that the success and reliability of these DSRC Safety Applications are heavily dependent on the Basic Safety Messages (BSM) from the RV. If the HV doesn't receive these messages or they aren't frequent enough, the effectiveness of the application may be compromised.
Figure 3.
Safety Application Scenarios.
Figure 3.
Safety Application Scenarios.
Remember that each On-Board Unit (OBU) sends out a Basic Safety Message (BSM) every 100 ms using the safety channel (CH172). This results in a broadcast frequency of 10 BSM/s as referenced in sources [
9] and [
8]]. Building on this, we're looking into the idea of redundancy by amplifying this message frequency. We're keen to understand its effect on the reliability of Safety Applications and the subsequent overhead. Take, for example, the forward collision warning system illustrated in Figure 3.a. In this scenario, the rear vehicle (RV) brakes abruptly, possibly to avoid a hurdle. Such abrupt braking will trigger a brake system status notification in the BSM of the RV. From the perspective of the Host Vehicle (HV), this means it should receive at least one BSM reflecting this status update early enough to factor in the driver's reaction time. Consequently, the reliability of the Safety Application can be described as the likelihood of the HV getting a minimum of one BSM notification in time to allow the driver to react, specifically by time t_react.
To harmonize with the conventional definition of reliability – that is, R(t) representing the chance that a system operates as intended throughout a set timeframe [0, t], as mentioned in source[
8] – we can define our specific application reliability, R(t)app, as the likelihood of receiving a minimum of one BSM by time t_react. If we label the BSM as BSMi, then it's imperative to receive one of the BSMi, where i ranges from 1 to x, with BSMx being the final BSM before t_react. Hence, the application would only falter if not even one BSM is received by t_react. The metric for unreliability, Q(t)app, can be represented as 1 − R(t)app. This metric essentially gives the probability of not receiving any BSMi within the range of i = 1 to x.
At a regular interval of 100 milliseconds, every On-Board Unit (OBU) transmits a Basic Safety Message (BSM) on the safety channel (CH172), resulting in a message frequency of 10 BSMs per second[
26] and [
9]. To assess the impact of redundancy on the dependability and overhead of Safety Applications, we increase the BSM message rate. Let us consider the forward collision warning application where the Recreational Vehicle (RV) abruptly applies the brakes to evade an obstacle, resulting in a brake system status alert in the RV's BSM. To inform the driver sufficiently in advance, allowing adequate reaction time, the Host Vehicle (HV) needs to receive at least one BSM containing this status. As a result, the reliability of the Safety Application pertains to the probability of the HV receiving at least one BSM message before the reaction time threshold, i.e., at time t_react.
Following the standard definition of reliability, where R(t) is the probability of the system performing in accordance with the specifications throughout the time interval [0, t] [
27], we define our application reliability R(t)app as the probability of receiving at least one BSM message before at time t_react. Assuming the i^th BSM as BSM_i, at least one of the BSM_i, i = 1... X, must be received, where BSM_x refers to the last BSM before at time t_react. Consequently, the application fails only if no BSM message is received before t_react. The unreliability 〖Q(t)〗_(app =1- 〖R(t)〗_app ) i.e., the probability of not receiving any BSM_i, i = 1... X, can be expressed as:
Where is the probability that BSM_i was not received at t_i. It should be noted that is the packet error probability of . If N redundant channels are used, then
Where represents the unreliability for each channel, as
Equation .3, introduced in [
28], can be used to calculate the Safety Application's unreliability and channel redundancy for a single channel. Increasing the BSM rate has the potential to improve the system's reliability, but the impact depends on the intensity of jamming, as illustrated in Figure 4. If the left region experiences jamming, the jamming detection will activate the Safety Application's fail-safe mode. The right region remains unaffected by jamming. However, the central region is crucial, as increasing the BSM rate can mitigate moderate jamming. This strategy is not only applicable to the safety channel (CH172) but can also be extended to other channels, such as CH178 using ACM in a dual redundant approach or incorporating CH184 using PVD for a triple redundant scheme.
Figure 4.
Jamming impact regions.
Figure 4.
Jamming impact regions.
6.2. Effectiveness of various BSM Rates.
The MAC layer can face additional strain with an increase in BSMs due to higher BSM rates, which may lead to a decrease in PDR as a result of collisions. Determining the upper limit of BSM rates is dependent on several critical factors, including the number of vehicles in the vicinity, data rate, and message size. To gain insight into this upper limit, Figure 5 illustrates the maximum available BSM rates for different data rates and two sample BSM sizes, 300 and 180 Bytes, using a PHY Preamble of 32μs, DIFS of 64μs, and PLCP header of 8μs. For instance, when sending a 300 Bytes message at a data rate of 6Mbps.
Figure 5.
Upper bound on BSM rates for different data rates.
Figure 5.
Upper bound on BSM rates for different data rates.
And now by adding all delays 32μs + 64μs + 8μs + 400μs, these sums up to a total delay of 504μs per message. As BSM data rates higher than 6Mbps have been shown to be too unreliable in the presence of jamming, the data rates that should be used by DSRC Safety Applications are 3Mbps and 6Mbps [65]. For a 6Mbps data rate, the maximum number of messages the media can handle is 1984 BSM/s for 300 Bytes message size.
This can be calculated considering..
Thus, when sending a BSM of size 300 Bytes (2400 bits), the total messages that can be handled by the media is. Likewise, at 6 Mbps and for a message.
Assuming a message size of 180 bytes, the media can handle a maximum of 2906 BSMs per second. With each vehicle sending 10 BSMs per second, one can estimate the upper limit of vehicles that the media can handle. However, it is important to note that these calculations do not take into account the potential collisions that may occur when multiple vehicles attempt to send BSMs simultaneously. Collisions can lead to packet corruption, bandwidth consumption, and a decrease in PDR, particularly as the number of vehicles increases. It is worth noting that VANET uses the DCF and CSMA/CA protocols of the IEEE 802.11 standard. Despite these considerations, the maximum number of messages shown in Figure. 4 was calculated without accounting for collisions, and it is important to consider the impact of redundant BSMs on the medium in a more realistic scenario.
Collisions in VANETs can occur through direct collisions or hidden terminals. Direct collisions happen when the sender and receiver are within each other's transmission range, and they send messages simultaneously due to similar back-off times. In contrast, hidden terminal collisions occur when three or more nodes are positioned such that the outer nodes are not within each other's transmission range, but they are within the range of the middle node. This leads to more collisions since the outer nodes cannot sense each other's presence, resulting in simultaneous communication with the middle node. To prevent these collisions, wired and wireless networks use several mechanisms, including physical carrier sensing and virtual sensing. Physical carrier sensing involves the sender monitoring the medium and deferring transmission if the medium is busy. Only when the medium is idle, the sender transmits the data frame after a random back-off time to avoid direct collisions with other nodes competing for the medium.
Physical carrier sensing involves monitoring the medium and waiting for an idle period before transmitting data to avoid direct collisions. Virtual sensing, on the other hand, sets a Network Access Vector (NAV) based on Request-to-Send and Clear-to-Send (RTS/CTS) frames. Before transmitting data, a source node sends an RTS and waits for a CTS reply from the destination, and hidden nodes outside the source range can still hear the CTS reply and set their NAV accordingly to reduce collisions in hidden terminal situations. However, virtual sensing is not suitable for safety applications in VANETs, where minimal delay is crucial for broadcasting BSMs to high-speed vehicles. Therefore, hidden terminal situations have a more severe impact on safety applications in VANETs. The impact of transmission collisions on Packet Delivery Ratio (PDR) is studied using the IEEE 802.11p MAC protocol in [
29], which measures performance for both hidden and direct collision cases. The average number of vehicles in the transmission range is denoted by N_tr.
Which β represents the density of vehicle [vehicles/km] and R is transmission range. The queue utilization
ρ can be expressed as
Where λ is the packet generation rate [packets/sec] and E[S] is the average of the servant time.
Now let as τ be a probability of that a transmit vehicle in the slot random considering which a packet in a queue,
Where
is the average number of back-off slots. The probability of direct collision
is calculated as follows,
Note that
represents the probability that a channel is sensed busy when a new packet arrives,
Where T is the complete transmission time of a packet including DIFS period.
Finally, the
for direct collision case is,
As for the hidden terminal case, let
represents the probability of a hidden terminal collision,
Where, S1 denotes the event where none of the hidden terminals transmit, considering the number of hidden terminals is
this probability can be expressed as,
and
denotes the case where a vehicle starts its transmission,
Where, is the transmission time for a packet, and is the duration of DIFS period.
Finally, the
for hidden terminal case is expressed as,
To compute the PDR in direct collision and hidden terminal scenarios, we employ Equations 13 and 17, respectively, using the collision parameters outlined in Table 1. The model used in this study, as presented in, examines Safety Applications for vehicles traveling on a multi-lane highway, where the inter-lane distances are negligible compared to the overall network length.
Table 1.
MAC model parameters.
Table 1.
MAC model parameters.
Average number of back-off slots, W |
I6 |
Transmission range, R |
6oo m |
DIFS time |
64 micro s |
Data rate |
6 Mbps |
BSM rates |
IO, 2o and 3o BSM/s |
BSS size |
i8o Bytes |
Vehicle density |
z-zoo vehicles/km |
The impact of direct collisions on the PDR with varying vehicle densities is illustrated in Figure. 6 With an increase in vehicle density from 2 to 200 vehicles/km, the PDR declines for all three tested BSM rates. However, the impact of direct collisions on the PDR is insignificant for the 10 BSM/s message rate, even at a vehicle density of 200 vehicles/km, with a PDR of 92%. On increasing the BSM rate to 20 BSM/s, the PDR decreases to 72%, and further increasing the rate to 30 BSM/s results in a PDR of only 4%. Such a low PDR would make the Safety Application ineffective at high vehicle densities. The high BSM rates can only be used at lower vehicle densities, e.g., sending 20 BSM/s at vehicle densities below 115 vehicles/km, or 30 BSM/s for 78 vehicles/km.
Figure 6.
Impact of direct collisions on PDR (BSM size=180 Byte, data rate=6Mbps, BSM rate= 10, 20, 30 BSM/s).
Figure 6.
Impact of direct collisions on PDR (BSM size=180 Byte, data rate=6Mbps, BSM rate= 10, 20, 30 BSM/s).
In this analysis, we examine the effect of hidden terminal collisions on PDR at different vehicle densities, as depicted in Figure 7. The results show that when transmitting at a rate of 10 BSM/s, a PDR of over 90% can only be achieved at a density of 20 vehicles/km. When using higher BSM rates, significant degradation in PDR is observed, which raises concerns about the suitability of the 802.11p MAC layer in dense environments.
Figure 7.
Impact of collisions resulting from hidden terminals (BSM size=180 Byte, data rate=6Mbps, BSM rate=10, 20,30 BSM/s).
Figure 7.
Impact of collisions resulting from hidden terminals (BSM size=180 Byte, data rate=6Mbps, BSM rate=10, 20,30 BSM/s).