Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

5.1 Introduction

Vehicular safety applications have stringent real-time requirements, namely they typically require low channel access delay with a well-defined upper bound. For example, a vehicle that breaks suddenly should emit a warning message which should be received by other vehicles within a specific period of time; otherwise, there is the risk that such information becomes useless. These requirements are mainly addressed through transmissions scheduling and medium reservation, functions performed in a sub-layer of the OSI model Data Link layer, the Medium Access Control (MAC) layer.

When dealing with road traffic, a dense automotive scenario is most common in urban areas. This relates to the absolute number of vehicles in the road. In such context, that scenario is less common in highways. However, we can get a so-called dense scenario in which the meaning of “dense” is not directly related with the absolute number of vehicles. So, taking as context the delivery of safety messages within an appropriate time bound, “dense” refers to a situation where the available bandwidth/medium for scheduling a new safety message transmission is almost or even fully filled. Therefore, the MAC layer protocol plays a major role in scheduling safety messages transmissions in order to timely deliver them. Typically, the MAC protocol is designed to suite a specific network topology and communication model.

The design of a MAC protocol for emergency message dissemination in a typical Vehicle Ad hoc Network (VANET), with ad hoc network topology as the name suggests, is challenging for several reasons. Until nowadays, most commercial wireless networks were designed to be used in a centralized topology/control and unicast based communication, with feedback allowable due to the point-to-point connection between nodes. In contrast, when dealing with VANETs, the nodes are always mobile and broadcast based communication is used in a decentralized network topology. The MAC protocol thus needs to be:

  • Fully distributed and self-organizing, since there is no base station that coordinates scheduling in a centralized fashion, and because vehicles’ movement leads to constant changes of nodes;

  • Scalable, since there is no centralized control, scalability is a very important is-sue to address, in the sense that the number of vehicles cannot be restricted. This means the MAC protocol should not block communication and should have the capabilities to cope with overloaded situations.

As stated in [6], the data traffic models found in VANETs are different from, for example, Wi-Fi or 3G. The predominant traffic type for newly born safety applications is periodic messages (short status message with the position and speed of a vehicle), with an update rate of 1–10 Hz, which will coexist with event-triggered hazard warnings when road traffic safety networks reach full penetration. Therefore, the communication model has some important features:

  • It is mainly continuous time-triggered with broadcasts (contrarily to the pre-dominant event-driven model of the centralized commercial networks in existence till today);

  • Transient high network loads must be supported due to the repetition (rebroadcast) of safety messages to increase reliability. This is due to the fact that using broadcasts impairs the use of techniques such as Automatic Repeat reQuest (ARQ), in which an acknowledgement (ACK) of all packets is used;

  • Unpredictable delays (on channel access or transmission collisions) should not exist since they could be intolerable because of the real-time deadlines emergency messages have;

  • Packets leading to high overload can deteriorate the fast data exchange required, by limiting the available bandwidth.

Access to the channel in a timely and predictable manner is needed in order to meet a bounded real-time deadline. If a Carrier Sense with Multiple Access (CSMA) based method is used, since adaptive transfer rate can’t be used due to the lack of ACK feedbacks, an increase in the number of nodes will result in more simultaneous transmissions, which will lead to decreased packet reception probability and excessive channel access delay, thus jeopardizing road traffic safety applications requiring upper bounded access delay and high reliability. The main argument for CSMA is that VANETs rarely experience high network loads, and traffic smoothing techniques can be used to keep data traffic acceptable. However, such techniques are commonly used in centralized networks (and only reduce the average delay) or geographically restricted networks, neither of which is applicable to VANETs due to their highly dynamic nature. As so, the problem with unbounded worst case delay still remains. Also, when using the original CSMA algorithm, hidden terminal situations may occur in centralized networks using an Access-Point (AP). This is due to collisions at the only receiver, which may be attenuated using RTS/CTS control packets, or in ad hoc networks independently of the MAC algorithm used. However, in the context of a VANET where a safety message is broadcasted, it may not be very harmful since there is more than one intended receiver and it is not likely that all nodes experience problems. Moreover, due to vehicles’ high mobility, it is possible that broadcasts are received in perfect conditions, by the nodes experiencing problems in the prior transmission of the safety message. Also, due to 5.9 GHz band usage and multipath/diffraction characteristics, it is more likely that hidden node’s problem degrades performance in urban scenarios than in highways.

The typical broadcast-based applications used in VANETs affects 802.11 ability to recover from collisions since there are no ACKs and the backoff procedure is invoked, at most, only once during the initial carrier sensing, therefore losing the advantage of increasing the CW to augment the number of backoff values.

Using 802.11p MAC, the most frequent case of simultaneous transmissions leading to collisions occurs when the nodes reach a backoff value of zero. Since the number of backoff values available to randomly select is smaller for higher priority classes, the probability of simultaneous transmissions in such classes is higher. The IEEE 802.11e EDCA scheme was also subject to performance analysis in several other works. Although there are also existing proposals on improving the performance of IEEE 802.11e, they cannot eliminate the intrinsic shortcoming of IEEE 802.11e, which is that it only supports “statistical” priority for specific flows but not “strict” priority for individual packets.

There are several works in which the IEEE 802.11p MAC method was studied in terms of real-time performance. In [1], simulations using a realistic highway scenario showed that vehicles using 802.11p MAC method (CSMA/CA) can experience unacceptable channel access delays, thus meaning this MAC method does not support real-time communications. Also, in [10] the DSRC/IEEE 802.11p MAC method was simulated on a highway road scenario with periodic broadcast of packets in V2V situation. The simulation results show that a specific vehicle is forced to drop over 80 % of its messages because it could not get access to the channel before the next message was generated.

5.2 Related Work

There are several literature proposals to deploy safety services in the vehicular environment. We present summarily some of the most relevant next. In [18], the authors show that a new feature from 3GPP Release 6, multimedia broadcast/multimedia services (MBMS) is able to provide I2V services efficiently on top of the UMTS network. In [15] the authors go even further and propose a unified V2I and V2V architecture using UMTS, claiming that when the High Speed Packet Access (HSPA) technology is fully functional, latency times will be small enough to allow V2V safety applications. They define a peer to peer (P2P) approach over cellular network, organizing vehicles in different traffic zones or clusters, where each vehicle communicates with a roadside entity responsible for that traffic zone. However, tests with current UMTS technology showed insufficient results for message propagation delay between vehicles.

The authors in [20] also propose a P2P overlay, but on top of an ad hoc network, using the concept of a supernode or super-vehicle per cluster. By adding this extra layer, unnecessary V2V communications are reduced. Although they had different intents, it is the same idea behind the cluster-based DSRC architecture proposed in [17], in which the super-vehicle is named cluster-head. Each DSRC channel is attributed a specific function allowing each vehicle to handle three tasks, cluster-membership management, real-time traffic delivery and non-real time data communications.

The author in [11] goes a little further and proposes a hybrid architecture, adding V2I communications to the P2P approach, but considering that only a super-vehicle can carry out communications between the infrastructure and other vehicles in its cluster.

In [2], the authors propose an extension of the local peer groups (LPG) concept for ad hoc P2P networking of neighboring vehicles described by the authors in [3]. A LPG is a kind of cluster organization with two degrees of coordination: Intra-LPG communication supports near-instantaneous safety applications (100 ms latency) and Inter-LPG communication for applications that somehow extend the driver’s view. We find again the same concept of super-vehicle described earlier, this time named group header (GH). The GH periodically broadcasts a Heartbeat (HB) message to other vehicles (Group Nodes (GN)) within the LPG. Also in [2], it was added the presence of RSUs and V2I communications. They assume that V2V and V2I communications use different channels. Depending on the RSU network architecture, RSUs can be an extension of LPG, assuming the role of GH, behaving like regular GNs or even performing as an inter-LPG relay. RSUs can also assist V2V communications in order to help established LPGs and help create new ones.

Taking into account the parallelism that can be drawn between an RSU and an AP of IEEE 802.11, various authors have proposed coordination schemes between IEEE 802.11 APs. In [19], it was introduced an intra-access point synchronization scheme to allow cooperation between APs whilst providing guaranteed QoS using Point Coordination Function (PCF). PCF provides low delay and jitter, while allowing a fair bandwidth sharing. However, their scheme suffers from scalability issues.

Another important issue was taken in account in the work in [12]; they proposed a faster handoff scheme between 802.11 APs, reducing delays in the handoff process. The authors in [4] extended that scheme [12] in order to solve the problem of beacon collision between APs. APs have to be synchronized in order to transmit their beacons one after the others in the same channel, allowing mobile stations to get the beacons of available APs in the same channel. The authors in [21] proposed a coordination method between APs for IEEE 802.11 mesh net-works, to improve the throughput fairness for stations in different Basic Service Sets (BSS) of an infrastructure based WLAN network.

Despite having some related concepts (e.g., beacon collision between APs), none of these proposals are specific to WAVE. In this sense, it is here outlined a proposal of an RSU coordination scheme, somewhat similar to the method proposed in [4] about the APs synchronization, but taking into account the use of WAVE and a vehicular environment.

5.3 Improved MAC Techniques

With the focus on the prime goal of vehicular communications, which is safety-related applications, there is a need for meeting stringent real-time requirements. In this sense, the design of a MAC protocol is of utmost importance in order to access the channel timely. When using the IEEE 802.11p standard, which uses CSMA/CA as the MAC method, some enhancements are needed in order to meet real-time deadlines.

When dealing with vehicular applications, communications can rely solely on V2V or also I2V. The next two sub-chapters will devise some enhancements to the base MAC protocol, for each of the two cases. As already referred, due to the problem of meeting real-time deadlines, a TDMA based solution is pursued. It is assumed that the IEEE 1609.2 standard is also implemented, which means security services are used for all applications. Thus, data is not sensitive to service attacks trying to jam the communication medium, and anonymity, authenticity and confidentiality are assumed as granted in every message.

5.3.1 A Place for TDMA and Infrastructural Solutions

It is a fact that V2V communication is very promising and has numerous potential. However, taking into account the world economic crisis along with slow vehicle renewal rate, V2V solutions are facing slow implementations. As stated in 2013 by the technology market intelligence company, ABI Research, the V2V technology will gradually be introduced in new vehicles, resulting in a penetration rate of 61.8 % by 2027. Thus, it will take some time to be able to see the real safety benefits. Also, using Road Side Units (RSUs) can increase the range of communication by sending, receiving and forwarding data from one node to another, or benefit from their ability to process special applications forming V2I communication [13]. For instance, if traffic is congested in a specific highway zone, vehicles further behind without visual perception of the event may be informed by RSUs coordinating with each other and forwarding the information.

These are factors that favour I2V communications instead of purely V2V communications. When using this type of solutions for safety applications, it can be assumed that vehicles will be equipped with a communication device, as already used in electronic toll collection, which implements the specified MAC protocol. In addition, GPS devices are used in modern vehicles for positioning and other related purposes. Furthermore, this type of solution is somewhat resilient in the sense that safety event dissemination remains possible even in the case of a vehicle crashing and destroying its communication equipment, after the initial broadcast. Thus, the RSUs take part in the network as a special element in this kind of solution. In this type of solution advantage can be taken of the already installed infrastructure without being dependent on the large design cycle of vehicles. If needed in some zones, a relatively easy deployment of infrastructure as done in [14] is assumed feasible.

Considering IEEE 802.11p MAC standard as the base technology, a first protocol proposal is presented in [8]. The fundamental assumption is that non-enabled and enabled vehicles would coexist in the first stage of the technology growth. The enabled vehicles, equipped with OBUs, are able to communicate with other enabled vehicles and RSUs. Focusing on an already deployed infrastructure, the highway (or at least the accident-prone areas) is assumed to be fully covered by several RSUs, deployed by the respective operator.

As previously mentioned, the defined parameter set of EDCA is capable of prioritizing messages. However, with the increasing number of nodes sending messages of highest Access Category (AC), the collision probability increases significantly [5]. In densely populated scenarios or in case of filled MAC queues, native IEEE 802.11 MAC cannot ensure time-critical message dissemination. Proposals found in the literature are to integrate a re-evaluation mechanism for messages to continuously reduce the number of high priority messages and prevent long queues. In addition, the use of different EDCA parameters could mitigate the high collision probability. To reduce the number of high priority messages, it would seem appropriate the definition of a new AC (so-called “Safety AC”) within EDCA, reserved for collision and hard braking warning messages (it is not likely to exist several of these simultaneously), where the AIFS along with the CW value should be less than the AIFS of video AC. In this case it would be guaranteed that no contention between those messages and video AC messages would occur. However, this would not comply with the IEEE 802.11p standard.

So, the approach is to use a slotted based approach, with beacons transmitted by RSUs, to adequately reduce the collision probability in V2I (initial broadcast after a safety event) and I2V (rebroadcast in the target area by RSUs) communications. The idea, depicted in Fig. 5.1, is to have RSUs coordinating the rebroadcasting of safety messages with bounded delay and no contention in the target area.

Fig. 5.1
figure 1

Slotted based approach with beacons

Full size image

The idea is to divide every Control Channel (CCH) interval into an Infrastructure Period (InfP) and a Slotted Period (SloP). The former is reserved for coordination between RSUs, and for beacon transmission. In this period all vehicles should listen to the channel. Regarding the SloP, the initial six slots are reserved for RSUs and are used by them if there are safety messages to rebroadcast. A safety message may need to be rebroadcasted by two adjacent RSUs depending on the target area of the message (distance intended to disseminate the warning from the safety event location). Each RSU uses one time slot for each event. The RSUs’ beacon contains general information, such as the position of the RSU, and also information about the possible slots allocated by RSUs within SloP. The remainder of SloP is free and available to vehicles wishing to send messages (periodic or event-driven). Vehicles that generate an event broadcast the corresponding message on an empty slot (it should be noted that vehicles have knowledge of SloP occupation by listening the beacons in the beginning of the CCH interval). The RSUs will know the time the event was triggered and, by using beacons, will inform in the next CCH interval the specific slots being used to rebroadcast the message.

Despite it is not likely that two simultaneous events are generated, we can have three distinct situations: a clean transmission, a collision and an idle situation. In the first, reliable information is rebroadcasted in one or more slots, regarding the target transmission area. In case of transmission collision, a problem exists and in the corresponding slot it is rebroadcasted a warning.

By using this approach another advantage arises. Considering a vehicle brakes suddenly (generating an event), and after that collides destroying the communication equipment. In this case, the event will still be disseminated by RSUs despite the event originator cannot communicate further. The detailed definition of the coordination between adjacent RSUs, whose coverage areas are overlapped, is done on the following chapter. The Infrastructure Period duration is still dependent on the infrastructure deployment. Part of this work was presented in [7].

5.3.1.1 The I-TDMA (Infrastructure with TDMA Based Approach)

As referred previously, the RSUs play a major role in rebroadcasting warning messages adequately, i.e., avoiding contention in order to timely deliver the messages. Therefore, a critical issue is the coordination between RSUs, which is addressed here. Recall that the aforementioned approach was made in order to fully handle the problem of uploading (V2I) safety critical messages that could contend for the medium, and the problem of guaranteeing that the safety information arrives to the vehicle (I2V) within a specified time bound.

Taking into account the CCH interval organization defined previously, which can be seen in Fig. 5.1, every CCH interval is divided into an Infrastructure Period—reserved for RSUs coordination and for beacon transmission by RSUs—and a Slotted Period where the initial part is used for rebroadcasting safety messages, and the remainder is used as a contention period for short status messages, WSAs and safety event-driven messages. Using the InfP for RSUs’ beacons may intuit us to use the SloP with a defined slot schedule done by RSUs, and informed within their beacons, for vehicle’s utilization. However, this would require some kind of register/association, and the standard explicitly defines there is no association procedure in a WAVE context [9]. More importantly, it could jeopardize the timing requirements since the vehicle would first have to “register” itself, and only in the following CCH interval transmit a safety message within its reserved slot.

We are now concerned about the Infrastructure Period organization and how the RSUs will coordinate with each other in order to rebroadcast safety messages adequately. So, the focus here is only in the I2V message dissemination. The issue of slot selection for the initial broadcast (V2I) by the vehicle generating the event will be subject of analysis ahead.

The message target distance, \(d_{mt}\), can be used to define the number of adjacent RSUs that will rebroadcast such message. Assuming the RSUs have a coverage range of dcr (radius), and each one is in the radio range from its adjacent, the total distance covered by n consecutive RSUs will be given by Eq. 5.1.

$$\begin{aligned} d_{mt} = (n + 1) . \, d_{cr} \end{aligned}$$
(5.1)

Being the interest in safety-related applications, the distance covered by three RSUs, each with a typical transmission range of \(d_{cr}= 500\) m, is enough to disseminate the warning message and alert other drivers. This scenario is depicted in Fig. 5.2. A safety message should be rebroadcasted by several consecutive synchronization intervals. Thus, each RSU participating in the rebroadcast procedure maintains a counter, \(n_{ret}\), which is decremented by one in every retransmission (i.e., in every synchronization interval) until it reaches zero, meaning the end of re-transmissions. The counter value is related with the message’s lifetime, \(t_{lf}\), which is the time a safety event must be rebroadcasted.

Fig. 5.2
figure 2

Three RSU coverage range

Full size image

We are considering the road in a similar way as used by road authorities and car rally races, i.e., the road position is a linear function starting in 0 and ending in the road length, \(D_{rl}\), as seen in Fig. 5.3.

Fig. 5.3
figure 3

Road position (p) as a linear function

Full size image

Therefore, it is possible to know the driving direction information of a vehicle through two consecutive position measures, thus indicating if it is driving back or forward along the road (using Eq. (X.10), shown ahead).

When the vehicle, denoted as \(C_{g}\) in Fig. 5.2, is the only one to generate and broad-cast a safety message in a synchronization interval, the message will be received by the so called primary RSU (\(RSU_{p}\)), and by an adjacent RSU (\(RSU_{ar}\)). From both, the \(RSU_{p}\) will be the one to rebroadcast the message since RSUar detects that the vehicle is moving towards it (through the driving direction information and vehicle position fields in vehicle’s message). If, in the same synchronization interval, two other vehicles, one between \(RSU_{al}\) and \(RSU_{p}\) (C0 in Fig. 5.2), and the other ahead of \(RSU_{ar}\) (C1 in Fig. 5.2), also generate a safety event, this will lead to all those three RSUs having to rebroadcast the message. The beacon transmitted by each in the following Infrastructure Period contains information relative to the event ahead of each. In order to allow proper announcement of the safety events through the beacons, from all RSUs, contention must be avoided between them. If the slot choice by RSUs was random, collisions would happen. Collisions caused by the same slot chosen by adjacent RSUs, or collisions caused due to the hidden node problem despite those RSUs are not at the communication range of each other (an example is shown in the following chapter). The following proposal is devised to cope with this issue. In summary, the Infrastructure Period will have five slots. The first three slots are used for coordination between RSUs. The last two slots are used for message dissemination through several adjacent RSUs.

5.3.1.2 Coordination for Beacons Transmission

It should be noted that RSUs do not share a physical connection like a back-bone. Instead, they also use the WAVE technology to communicate with each other. Each RSU has a number corresponding to its sequence along the road. Also, there are sections identified by a number. Each section contains three RSUs and each RSU belongs only to one section (an example can be seen in Fig. 5.4, from the start of the road, indicated by the arrow, and road direction from left to right).

Fig. 5.4
figure 4

RSUs numbering and sections

Full size image

Each RSU will use its InfP slot to transmit its beacon, whether it has listened or not a safety event broadcasted by a generator (OBU) (this will allow minimizing the collision probability between vehicles broadcasting a message within SloP, as explained ahead). In order to avoid contention between adjacent RSUs, and to avoid hidden terminal collisions (e.g., \(RSU_{1}\) and \(RSU_{3}\) transmitting a beacon in the same InfP slot, and causing \(RSU_{2}\) to hear a collision), each RSU chooses its InfP slot using its own number (\(RSU_{nr}\)) and its section number (\(Section_{nr}\)), as devised in Eq. 5.2.

$$\begin{aligned} Inf{P_{slot}} = RS{U_{nr}} - \left( {3 \times Sectio{n_{nr}}} \right) \end{aligned}$$
(5.2)

This guarantees that all RSUs along the road will transmit their beacons without collisions. To verify the correct functioning when RSUs allocate slots accordingly to the procedure explained above, Fig. 5.5 shows the transmission slots used for the nine consecutive RSUs. In this case, no collisions will occur.

Fig. 5.5
figure 5

Infrastructure period slot allocation by nine consecutive RSUs

Full size image
Fig. 5.6
figure 6

Incorrect choice of InfP slots lead to hidden node collisions

Full size image

An example of an incorrect choice of slot allocation is shown in Fig. 5.6. Although \(RSU_{2}\) and \(RSU_{4}\) are not in the communication range of each other, and thus do not listen each other’s transmissions, if it happens that they choose randomly slot 2 to transmit a beacon, it will cause \(RSU_{3}\) to listen a collision since it hears both beacons at the same time. This is represented in the Fig. 5.6 by surrounding \(RSU_{3}\) with a ray type line. The same goes for \(RSU_{6}\) and \(RSU_{8}\) choosing slot 3 and causing \(RSU_{7}\) to hear a collision.

Beacons are basically a WAVE Short Message from the WSMP within the WAVE protocol stack. As so, the information needed for protocol implementation will be contained in the WSM Data field of the WSM. The data fields of beacons sent (Fig. 5.7) are the following:

  • “RSU Position” indicates the position of the RSU. It will be used by vehicles in the process of choosing a slot to transmit a message within SloP, when not using a random method. The number of bits needed for “RSU Position” is defined by GPS coordinates.

  • “SlotsReserved” indicates how many and which slots are reserved in the Slotted Period. Since each vehicle listens at most two RSUs simultaneously, and assuming each can rebroadcast three events, this field uses two bits to define how many slots are reserved, and three fields of eight bits each, to define the slot number used for the event. Thus, if the first two bits are 0 it means this is a pure beacon and no safety event has occurred, and the following fields are ignored.

  • “AdjacentRebroadDist” with a value of \(n_{td}\), is used for message dissemination as explained in the next section.

  • “VehiclePosition” contains the GPS coordinates in order to obtain vehicle’s position in case of a safety message was received. A conversion from that to road position is done to get the vehicle position in road length (Fig. 5.3).

  • “VehicleDirection” indicates the direction the vehicle is travelling (fi), in case a safety message was received.

  • “NumberLanes” indicates the number of lanes in each direction of the highway. It will be used by vehicles in the process of choosing a slot to transmit a message within SloP, when not using a random method.

Fig. 5.7
figure 7

Beacon frame data fields (within WSM data field)

Full size image

It is possible that two RSUs detect events that happened in an instant that leads to schedule the transmission in the same reserved SloP slot. In this situation, and since each RSU listens the beacons from adjacent units, the one with a higher value for “VehiclePosition” will maintain its slot allocation within the SloP (if the vehicle is moving forward, relative to road direction, otherwise the one with lower value). The other waits for the next InfP in order to allocate other slot(s). This gives higher priority for the further ahead event regarding the vehicles direction. Alternatively, a solution would be having each RSU allocating two slots for each event and using always the first of them, leaving the second for the RSU having the lower value of “VehiclePosition” in its beacon. However, this will lead to medium resources poor utilization (since two events so close in time may have low probability of occurrence), and the ability to deal with a lower number of events. Dependently on the timing requirements of the safety application, if waiting for the next InfP to announce the event is time jeopardizing, the alternative solution should be forced.

Fig. 5.8
figure 8

RSU operation state machine

Full size image

5.3.1.3 Message Dissemination

After the initial broadcast done by the event generator, the corresponding safety message should be appropriately spread throughout the road. This is done by RSUs. The dissemination of the safety event is done by analyzing the “AdjacentRebroadDist” field in the beacon. When an RSU listens a beacon with an \(n_{td}\) value higher than zero, and infers it is behind the vehicle (relatively to the driving direction) by examining the “VehiclePosition” and “VehicleDirection” fields, it will decrement \(n_{td}\) value by one and rebroadcast the message on an available slot. It will also send its beacon with the updated \(n_{td}\) value in the available of the two final slots of InfP (for each RSU rebroadcasting the message, one of these two slots will be used alternately for the respective beacon). This means that \(n_{td}\) is the number of RSUs, other than the originator RSU, retransmitting the message. It could be used to control the target distance of the message.

The global operation relative to RSUs’ management (described in the two previous sections) may be seen in Fig. 5.8.

5.3.1.4 Choice of SloP Slot for Generator Initial Broadcast

Broadcasting status messages, service announcements (WSA), or safety events is done by vehicles within the SloP period. The approach may be using WAVE standard random access. As already stated previously, this will subject transmissions to possible collisions. Other possible approach, aiming to minimize transmission collisions, is performing a somewhat “deterministic” slot choice.

In the latter approach, assuming one lane, the slot chosen for a broadcast, slot1lane, is based on the vehicle’ current position, xCi(t), and the RSu’s position that is behind the vehicle, xRSUb, relative to the direction of travelling, obtained from the beacons heard in InfP. This is given by Eq. 5.3.

$$\begin{aligned} slo{t_{1lane}} = \left\lfloor {SloP(CP).\frac{{\left| {{x_{{C_i}}}\left( t \right) - {x_{RSUb}}} \right| }}{{{d_{cr}}}}} \right\rfloor \end{aligned}$$
(5.3)

SloP(CP) is the number of slots within the Slotted Period that are available for vehicles. The vehicle’s current position is not the GPS coordinates, but its conversion to road position, as shown in Fig. 5.3. Similarly for the RSU’s position.

This will work fine if it is considered only one lane. However, when considering multiple lanes, as common in highways, some problems may arise. If vehicles are travelling in different lanes “side-by-side”, their position will result in the same slot derived (\(slot_{1lane}\)). For example, in Fig. 5.9, vehicles A, C and E will choose slot 0 for message transmission, and vehicles B, D and F will choose slot 3, resulting in a collision if a pair of them (within each “group”) have a message to transmit, which is possible. In Fig. 5.10, despite vehicles are not “inphase” in each lane, due to vehicle spacing, the same problem will occur for vehicles B and F. It is assumed that all vehicles travel at the same speed. This will give the worst-case results. If it was the case that vehicles travelling in different highway lanes have different speeds, a less number of vehicles would exist, since it is likely that vehicles travel faster when driving at the “outside” lanes. Thus, with this assumption, the inter-vehicle spacing is the same within all vehicles (for a given traveling velocity), when using for e.g., the Intelligent-Driver Model (IDM).

Fig. 5.9
figure 9

Slot choice based on vehicle position and lane–Problem (a)

Full size image
Fig. 5.10
figure 10

Slot choice based on vehicle position and lane–Problem (b)

Full size image
Fig. 5.11
figure 11

Slot allocation procedure for WSMP messages’ initial broadcast

Full size image

With the problem stated above, the slot derived by each vehicle should include the lane number the vehicle is travelling, \(lane_{nr}\), as well as some method to derive if the vehicle is “out of phase”. The lane number is the conversion of the GPS co-ordinates to an integer number, being 0 the most interior lane, and each consecutive following lane obtained by consecutive unity increments (as shown in Fig. 5.11). Considering the case where it is possible to perform slot allocation without collision (fewer vehicles than available SloP slots), the idea is to allocate the vehicles within the interior lane (lane 0) to the first SloP(CP)/\(nr_{lanes}\) slots, the vehicles in the following lane to the second SloP(CP)/\(nr_{lanes}\) slots, and so forth. \(nr_{lanes}\) is the total number of lanes in each highway direction. \({ < x > }\) represents the fractional part of x. The total expression used by each vehicle is shown in Eq. 5.4.

$$\begin{aligned} slo{t_{tx}} = \frac{{slo{t_{1lane}} - \left[ {\left\langle {\frac{{slo{t_{1lane}}}}{{n{r_{lanes}}}}} \right\rangle \times n{r_{lanes}}} \right] }}{{n{r_{lanes}}}} + lan{e_{nr}}.\frac{{SloP\left( {CP} \right) }}{{n{r_{lanes}}}} \end{aligned}$$
(5.4)

The flowchart describing the slot allocation procedure for the initial broadcast is depicted in Fig. 5.11.

It should be guaranteed that in a situation where all the slots are occupied and a new event generates a safety message, which transmission delay is critical, the node’s transmission is not blocked (delayed) until a slot is available, and immediate access should be granted. In this sense, an improved SloP slot choice by OBUs to reduce collision probability of safety events should be taken. Since it is not likely that several simultaneous events occur within one CCH interval, a small number of slots may be reserved only for safety events broadcast.

Finally, in terms of synchronization, since the devised protocol is “centralized”, the RSU can provide the synchronization. However, it is assumed that all units have a GPS module due to the massive use in today’s vehicles.

5.3.2 An Alternative V2V Based Solution

Being V2V communication very promising and far investigated, and taking as base the work done with BRISA–Autoestradas de Portugal SA, a Portuguese highway operator, here it is outlined an alternative solution, where V2V communication plays the major role to accommodate time-critical messages within WAVE, for safety applications in highways. This model is proposed since the solution presented in the previous sections may not be feasible in some cases. First and foremost, full RSU coverage of the highway could not be possible. In addition, highway characteristics, such as tunnels, could limit the appropriate dissemination of safety messages if a warning generator vehicle could not communicate with an RSU. Therefore, the main goal of this model is to do the rebroadcast of safety messages only by vehicles.

Here, it is considered a highway where RSUs are only present in particular areas, namely all the entry and exit zones, near toll equipment and near possible hazardous areas (dangerous curves, bridges or tunnel entrances). In the highway areas that are not covered by RSUs, vehicles’ safety messages can solely rely on V2V communications for being rebroadcasted. The modeled state machine of MAC operation can be seen in Fig. 5.12. EP is the Event Period (time interval within CCH interval) and Lifetime relates to the rebroadcast time of an event, as explained later on this section.

Fig. 5.12
figure 12

MAC state machine (rebroadcast only performed by vehicles)

Full size image

It is considered that a safety event is associated with a vehicle and this vehicle will be the responsible for disseminating such event. The problem of several vehicles considering they are responsible for the same event is left out of the scope of this chapter. In case of an accident involving several cars, the first vehicle to disseminate the event will be considered the event generator, meaning that if other crashed vehicles listen to the generator transmission they will not start an event on their own.

5.3.2.1 Model definition

When the event is recognized, there could be a quantity of vehicles within the distance of interest of the event. This distance of interest depends on the type of event. The model formalization follows.

E(t1) is a safety relevant event that happened in instant t1. Equation 5.5 represents an important group of vehicles.

$$\begin{aligned} {C_{dE}}\left( {{t_1}} \right) = \left\{ {{C_g};{c_o},...,{c_n}} \right\} \end{aligned}$$
(5.5)

\(C_{dE}(t1)\) is the set of vehicles within the distance of interest of event E(t1) which includes the generating vehicle \(C_{g}\) and an n+1 (unknown) number of other vehicles, all of which must receive the safety message. To avoid confusing vehicles with velocity we will use the letter c to represent vehicles in the equations, as in c for cars.

As already mentioned in Sect. 5.3.1.1, and illustrated in Fig. 5.3, we are considering the road in a similar way as used by road authorities.

When a generating vehicle wants to disseminate an event, it will transmit a frame in one of the safety slots reserved for that purpose. Two situations may arise from the transmission of that frame:

  1. 1.

    No vehicle listens to the frame, because there are not any vehicles within the transmission range.

  2. 2.

    Some vehicles listen to the frame. Defining an expected instantaneous range (in wireless communications this range fluctuates significantly, but here this is not problematic):

    • \(d_{l}(t)\)–transmission range, in one direction, at instant t;

    • \(d_{l}(t2)\)–transmission range of the message issued by \(C_{g}\) as a reaction to event E(t1), for \(\mathrm{t}2>\mathrm{t}1\) for every t. This is considered constant in any direction, i.e., we are considering circular propagation.

Then, the aforementioned situation 1 means that

$$\begin{aligned} {C_{dl}}\left( {{t_2}} \right) = \left\{ {{C_g}} \right\} \cup \left\{ {} \right\} \end{aligned}$$
(5.6)

where \(C_{dl}(t2)\) is the set that includes the vehicles which are at a linear distance from \(C_{g}\) less than \(d_{l}(t2)\).

Considering now situation 2 mentioned above, we have

$$\begin{aligned} {C_{dl}}\left( {{t_2}} \right) = \left\{ {{C_g};{c_o},\ldots ,{c_k}} \right\} \end{aligned}$$
(5.7)

This set includes the vehicles within the transmission range of \(C_{g}\), i.e.,

$$\begin{aligned} d\left( {{C_j}} \right) < {d_l}\left( {{t_2}} \right) ,\; \end{aligned}$$
(5.8)

where

$$\begin{aligned} 0\le j \le k \end{aligned}$$

and d(\(C_{j}\)) is the distance in a straight line from vehicle j to the generator vehicle.

It should be noted that dependently on the distance of interest and the actual vehicles’ placement on the road, the set \(C_{dE}(t1)\) may have more, less, or the same number of vehicles than the set \(C_{dl}(t2)\).

It is important to determine a vehicle’s position in the road. It can be derived by the following equation.

$$\begin{aligned} {x_{ci}}\left( t \right) = {d_{gps}}\left( {{t_k}} \right) + \left( {2{f_i} - 1} \right) \int _{{t_k}}^t {{v_i}\;dt,\;\;t > {t_k}} \end{aligned}$$
(5.9)

where vi is vehicle i (or car i) instantaneous’ speed and \(d_{gps}(tk)\) is the position of the vehicle i in the road at the last instant where a GPS coordinate has been obtained (e.g., the entrance of a tunnel). The \(f_i\) function is used to account the direction vehicle i is travelling.

$$\begin{aligned} {f_i} = \left\{ {\begin{array}{*{20}{c}} {0\;if\;\left( {{x_{{C_i}}}\left( {{t_1}} \right) > {x_{{C_i}}}\left( {{t_2}} \right) } \right) \;,\;\left( {{t_2} > {t_1}} \right) } \\ {1\;if\;\left( {{x_{{C_i}}}\left( {{t_1}} \right) < {x_{{C_i}}}\left( {{t_2}} \right) } \right) \;,\;\left( {{t_2} > {t_1}} \right) } \end{array}} \right. \end{aligned}$$
(5.10)

i.e., if the vehicle is driving back or forward along the road its position goes from \(D_{rl}\) to 0 or vice-versa.

Equation 5.9 can be used to determine the vehicle road position in any instant or place, using available GPS information and data available from the vehicle itself, e.g., through the Vehicle On Board Diagnostics II (OBD2) interface.

We can consider the event relevant for vehicles travelling in both directions, or just consider the generating car driving direction. In a motorway this last scenario is often the relevant one. To find out if vehicle i is travelling or not in the same direction as the vehicle that generated the event (\(C_{g}\)), we need to compare \(f_{i}\) and \(f_{g}\). If they are equal it means that the vehicles are indeed travelling in the same direction.

We now need to restrict this set of vehicles to a distance of interest of the event and driving behind (\(C_{g}\)). The vehicles within the distance of interest, (\(d_{E}\)), of the event are the ones that have

$$\begin{aligned} I\left( {{C_i}} \right) = 1\;if\left\{ {\begin{array}{*{20}{c}} {\left( {{x_{{C_i}}}\left( t \right) > \left( {{x_{Cg}}\left( {{t_2}} \right) - {d_E}} \right) } \right) \; \wedge \;\left( {{x_{{C_i}}}\left( t \right) < {x_{Cg}}\left( {{t_2}} \right) } \right) ,\;{{\text {f}}_{\text {g}}}\; = \;{\text {1}}} \\ {\left( {{x_{{C_i}}}\left( t \right) < \left( {{x_{Cg}}\left( {{t_2}} \right) + {d_E}} \right) } \right) \; \wedge \;\left( {{x_{{C_i}}}\left( t \right) > {x_{Cg}}\left( {{t_2}} \right) } \right) ,\;{{\text {f}}_{\text {g}}}\; = \;{\text {0}}} \end{array}} \right. \end{aligned}$$
(5.11)

\(\mathrm{I}(C_{i}) = 0\) otherwise.

Getting back to situation 2, even if \(C_{dl}\) (t2) includes other vehicles than \(C_{g}\), i.e., there are vehicles within the transmission range, it must be verified if each of those vehicles satisfy Eqs. 5.10 and 5.11 to be considered of interest (i.e., travelling in the same direction, behind the event generator, and within the distance of interest). One of the vehicles within this final subset will rebroadcast the event.

It must be noticed that we are ignoring the distance skewing due to vehicles’ mobility. Our time scale will validate this assumption. We recall that event E happened at instant t1, the frame transmission at instant t2 and the interest range evaluation at t, wheret \(>\) t2 \(>\) t1.

In Fig. 5.13 it is illustrated a hypothetic scenario reflecting situation 2 mentioned above. The event generator vehicle is the one marked with a “G” letter. Other vehicles are given a random number, from 0 to 7. The highway has two directions, which are marked with arrows on the leftmost side. The event generator is driving forward (meaning \(f_{g} =1\)). In this particular case, deriving from Eq. 5.7, we would have a subset of vehicles within transmission range of \(C_{g}\).

$$\begin{aligned} {C_{dl}}({t_2}) = \left\{ {{C_g};\;{c_o};\;{c_2};\;{c_3};\;{c_4};\;{c_5};\;{c_6}} \right\} \end{aligned}$$
(5.12)

Also, considering only relevant the vehicles driving in the same direction as the generating car (using Eq. 5.10), it means that we are now restricted to vehicles \(C_{0}\), \(C_{1}\), \(C_{2}\), and \(C_{3}\). Taking also into account the distance of interest, and assuming a safety application with \(d_{E}= 0.5\) km, and also considering only relevant vehicles following Cg (Eq. 5.11), we would finally get the vehicles \(C_{0}\) and \(C_{2}\) considered relevant for rebroadcasting the event.

Fig. 5.13
figure 13

Hypothetical scenario for situation 2

Full size image

5.3.2.2 Choosing the Event Rebroadcasting Vehicle

Using the aforementioned model, it is important to define some issues. The first should be to decide which vehicle will rebroadcast the safety event, from the set of vehicles chosen as candidates.

As it can be seen in Fig. 5.14, the CCH interval is divided into an Event Period (EP) and a Warning Message Period (WMP). The EP is used only by vehicles that generate an event, thus minimizing contention with rebroadcasting vehicles and giving the highest priority to the generator vehicle, \(C_{g}\). Although it is not likely that simultaneous events occur, it is still possible. So, the EP is determined after fixating the WMP normal slots needed, and it is composed by a bit-rate dependent number of slots, where each event should be transmitted in one of them. To avoid contention, the possible simultaneous event generators perform a random choice of a slot within each EP before transmitting the event. The simultaneous generators that do not win medium contention will listen that an event is being broadcasted and will stop trying to broadcast their event. Another approach would be to perform a sort of “position-based” choice of the EP slot to minimize contention (although a reference point should be used).

Fig. 5.14
figure 14

TDMA based approach using WAVE’s CCH interval

Full size image

The WMP works as a Contention Period (CP) and is used only by vehicles that receive a safety frame and need to rebroadcast such frame. It is intended to attribute different priorities in the slot allocation procedure according to the position of the vehicle, its velocity and also a random number. For this purpose, the WMP is divided as several groups of slots, called Super Slots (SupS). Each SupS has a certain number of Normal Slots (NS). The priority should be higher for larger distances from the generator vehicle (to reach the largest propagation distance with the minimum necessary broadcasts), which is achieved by the SupS. In a case where the distance results in the same SupS of another contending vehicle, a higher priority should be assigned to the vehicle with lower velocity (since it will stay at a higher distance from the generator vehicle). This is achieved using the NS within the SupS derived. In case the velocity is also similar leading to the same NS, a random number is used to avoid a transmission collision–through Sub Slots (SubS). These measures can minimize significantly the transmission collision probability.

One NS is sufficient to transmit a safety frame and to have some idle time. Within each NS, there are several SubS related to the time needed to transmit a bit. So, vehicles receiving a safety frame, that are in the distance of interest behind \(C_{g}\), (see Eq. 5.11), and moving in the same direction (\(f_{i}\) = \(f_{g}\)), should compute the CP slots in which they will try the rebroadcast in the following CCH Interval. This is given by Eq. 5.12. \(n_{SupS}\) is the super slot number and is related with vehicle position, \(n_{NS}\) is the normal slot number within the chosen super slot and is related with vehicle velocity, and \(n_{SubS}\) is the sub slot number within the chosen normal slot and is used to avoid a transmission collision between vehicles having similar positions and velocities.

$$\begin{aligned} C{P_{slots}}\left( {\begin{array}{*{20}{c}} {{n_{SupS}},} \\ {{n_{NS}},} \\ {{n_{SubS}}} \end{array}} \right) = \left( {\begin{array}{*{20}{c}} \begin{gathered} \left( {{n_{SGr}}\; - \;\left\lfloor {\frac{{{{\text {n}}_{{\text {SGr}}}} \cdot \left| {{x_{{{\text {C}}_{\text {i}}}}}(t) - {x_{{C_g}}}({t_2})} \right| }}{{{d_l}({t_2})}}} \right\rfloor } \right) \;, \\ \\ \end{gathered} \\ \begin{gathered} \left( {\left\lceil {\frac{{ve{l_i} - ve{l_{\min }}}}{{ga{p_{vel}}}}} \right\rceil } \right) \;, \\ \\ \end{gathered} \\ {\left( {random\left( {0,1} \right) \cdot {k_{SubS}}} \right) } \end{array}} \right) \end{aligned}$$
(5.13)

where \(n_{SGr}\) is the number of super slot groups, \(vel_{min}\) is vehicle’s i velocity, \(vel_{min}\) is the minimum velocity defined for a vehicle, and

$$\begin{aligned} ga{p_{vel}} = \frac{{ve{l_{\max }} - ve{l_{\min }}}}{{{k_{NS}}}} \end{aligned}$$
(5.14)

where \(vel_{max}\) is the maximum velocity defined for a vehicle and \(k_{NS}\) is the number of normal slots within a super slot. \(k_{SubS}\) is the number of sub slots, which should be such that the remaining time in the normal slot is enough to transmit the safety frame and to have SIFS.

It should be noticed that after receiving a safety message, and earning the right to rebroadcast through slot allocation procedure, the rebroadcasting vehicle will act as a new generator vehicle for the vehicles behind it and the process repeats for such vehicles.

Another interesting issue is whether \(C_{g}\) should continue to broadcast the event. We consider appropriate, in sake of medium resources utilization, that when a generating vehicle listens to a rebroadcast, it should stop trying to broadcast itself the safety message. If it never detects a rebroadcast or, after some time, stops listening the rebroadcast, the generator vehicle starts repeating the broadcast if the message’s lifetime (\(t_{lf}\)) is not zero.

Consequently, we can question what lifetime should the event have, i.e., how long must we continue to rebroadcast the event? Also, at what distance must the event be propagated?

Both of the questions cannot be answered in an absolute manner. This is application dependent. For example, an EEBL message will surely have a shorter lifetime than an accident warning. The same applies to the distance. For example, an accident can cause a traffic jam for various kilometers, while in the case of a sudden braking it is not needed to warn vehicles that are too far away. The message’s lifetime should be enough to ensure that at least one vehicle will receive the message, i.e., it should account for an initial absence of vehicles within the transmission range, or connectivity loss due to sudden deceleration.

In order to perform an evaluation for different scenarios, it is useful to deter-mine how many vehicles are in the distance of interest (\(n_{dE}\)) of a possible event generator (\(C_{g}\)). This is shown in Eq. 5.15.

$$\begin{aligned} {n_{dE}} = \frac{{{d_E}}}{{\left( {{C_{length}} + {C_{spacing}}} \right) }} \times {n_{lanes}} \end{aligned}$$
(5.15)

where \(n_{lanes}\) is the number of highway lanes in each direction, \(C_{length}\) is the vehicle average length, and \(C_{spacing}\) is the vehicle separation value.

5.4 Conclusions

Safety-critical applications, e.g., sudden hard-brake or collision warning, require typically low channel access delay with a well-defined upper bound. These requirements pose the burden of message timeliness on the transmission scheduling and medium reservation functions performed by the MAC layer. It was noticed that such goals may not be fulfilled even when using implementations in conformance with the standards. For instance, the WAVE architecture accounts support for safety messages within vehicular networks. However, high collision probability is not negligible, particularly in dense scenarios, which may jeopardize the timing constraints of safety messages

The design of I-TDMA (Infrastructure with TDMA based solution) MAC protocol based solution considers the inclusion of a typical feature used in time-slotted self-organizing MAC protocols contained in several VANETs approaches. This is having the nodes transmitting information about which other nodes they receive information from, or their perception of the current slot allocations. This is done to prevent unintentional slot reuse by hidden terminals. However, it was shown in [16, 21] that in an highway scenario, with a communication channel modeled as a fading channel, hidden terminal situations do not contribute for a major performance deterioration in terms of packet reception probability.

Regarding IEEE 802.11p/P1609.4 MAC utilization and the specificity of CCH and SCH usage, the assumed requirement of using the CCH for safety information dissemination can strongly affect the end-to-end delay depending on the scenario considered (i.e., at what instant the safety event has occurred). If achieved delay is not admissible, the utilization of a mechanism forcing the use of CCH more often than SCH, i.e., stay tuned in CCH in some SCH intervals, could be a solution.

By using RSUs to rebroadcast the safety message, the only problem resides in the initial broadcast, since in the subsequent ones contention is avoided. Adding to this, if a careful slot choice is used by vehicles needing to transmit a message, collisions can be further reduced, and an improved upper bound to the end-to-end delay is achievable.

A preliminary study, which includes the intelligent driver model and also queuing delay, gave some promising results. The number of slots available for safety-related message transmission increases as the bit rate used increases. So, for higher bit rates the possible number of simultaneous transmissions is higher and the collision probability is reduced. Also, the number of slots is a function of the maximum message length (and its consequent duration for a given bit rate) it is intended to be used. The RSUs’ beacons duration is approximately constant for beacons as long as 450 bits, losing only one slot in the three lower WAVE bit rates. So, if the latency achieved is not admissible, an eventual solution may be to work at a higher bit rate thus reducing the media access delay.

The collision probability (probability of at least two OBUs having messages to transmit and both choose the same slot), decreases with the increase in vehicle speed and also with the increase in the bit rate used. If the random method is used for slot choice the collision probability is higher than 0,9 for velocities lower than 80 km/h if lower bit rates are used. Contrarily, if the position-based method is used to choose the transmission slot, the collision probability is 0 for speeds higher than 20 km/h, even for the lower bit rates and for peak hour traffic situation.

Analyzing the higher velocities (more dangerous), from 80 to 120 km/h, the average media access delay, considering the specificity of using only the CCH to broadcast safety-event messages, varies from about 31 to 124,5 ms when using the random method for slot choice (the large variation interval is related with varying also the traffic situation–clear or peak hour as well as using the extreme WAVE standard bit rates 27 and 3 Mbps). In general, as the vehicle velocity increases, the average media access delay decreases. If the position-based method is used, the average media access delay is reduced and remains constant at 27,5 ms.

Finally, the total MAC delivery latency (end-to-end delay), when considering vehicle’s velocity between 80 and 120 km/h, and ranging from a bit rate of 27 Mbps with clear way traffic to a bit rate of 3 Mbps with peak hour traffic, and a packet generation rate from 4 to 7 packets/s, varies from about 61–476 ms for random slot choice, and varies from about 29–40 ms for position-based slot choice. The traffic condition has a higher impact, in terms of relative increase, on the total end-to-end delay at higher bit rates, for the same speed. Also, the traffic condition has a higher impact, in terms of relative increase, on the total end-to-end delay at higher velocities, for the same bit rate.