Keywords

1 Introduction

Recent developments in wireless communications devised for Intelligent Transportation Systems (ITS) makes possible to implement cooperative applications that can improve passenger’s safety and comfort as well as traffic management. These networks rely on every vehicle having an on-board unit (OBU) capable of communication with other vehicles or with some kind of infrastructure on the road-side, also known as road-side unit (RSU). Vehicular safety applications have specific characteristics such as small latencies, as an example the Emergency Electronic Brake Light safety application requires that maximum latencies are lower than 100 ms. On the other hand, many multimedia applications require data rates higher than 1 Mbps and QoS support. The IEEE802.11p standard (which was included in 2012 in the amendment 6 of IEEE802.11 [1]), along with the IEEE 1609 set of standards was devised to respond to both the latency and throughput requirements of vehicle applications. Its European equivalent standard ETSI ITS G5 shares the same goal [2]. Their medium access control (MAC) layer adopts a carrier sense multiple access with collision avoidance (CSMA/CA), same as IEEE 802.11a, but with a new additional, non-IP, communication protocol, with a low overhead and designed to the simple, single-hop broadcast communication. CSMA/CA is based on a random backoff algorithm in case the medium is busy, meaning unbounded channel access delays can occur. Adding to that, fairness and scalability are not guaranteed, since some nodes may have to drop several consecutive transmission attempts, particularly in high density scenarios when several nodes simultaneously try to access the medium. Due to that, some nodes might never get access to the medium before the deadline, whereas other nodes might have few difficulties in accessing the medium. Since there is a limited discrete number of backoff slots, it might happen for high density networks, that nodes choose the same number of backoff slots when they sense the medium busy, which might cause a simultaneous transmission within radio range of each other, causing an impact on scalability. This happens particularly in high density and high speed scenarios, such as suburban motorways, for example.

There is the need of a reliable communication infrastructure that can detect safety events and disseminate safety warnings in a secure manner, while being compliant with the maximum latencies involved in safety applications. The communication paradigm can be based on the road side infrastructure (I2V) or to be based on vehicle to vehicle communication (V2V), also known as ad-hoc networks. Hybrid approaches are also possible, particularly in scenarios where vehicle density can vary from traffic jam at certain hours of the day to very few vehicles in the evening. A pure ad-hoc network is quite difficult to manage, and it is likely that vehicle owners will place more trust in a vehicle communication network that is managed by the motorway infrastructure, which can have a global vision of the motorway or at least part of it.

This paper proposes a MAC protocol, based on infrastructure to vehicle communications, that can support safety applications in vehicular environments with a high number of vehicles. In Sect. 2 several proposals of MAC protocols that rely on infrastructure to vehicle communications are presented, and even though they improve the regular IEEE802.11-2012 MAC protocol, they all suffer from one or several shortcomings and therefore there is the need for other proposals. In Sect. 3, the V-FTT protocol is presented and detailed with realistic parameters, proving that it can provide a bounded delay even in worst-case scenarios. Conclusions and future work directions are presented in Sect. 4.

2 Medium Access Control (MAC) in Vehicle to Infrastructure Communications

Most of the MAC protocols are designed to achieve maximum throughput, but vehicular safety applications require small latencies, high data rates and most important require a deterministic delay, meaning that it must be possible to compute the worst-case transmission time. In case a safety application deadline is missed, it might increase the risk of accident, which is much more troublesome than simply degrading the communication system performance.

Several proposals that deal with the MAC issues discussed in the previous section are presented next, with focus on the proposals that use infrastructure-to-vehicle communications.

2.1 Proposals to Address MAC Issues in Dense Vehicular Scenarios

This sub-section presents recent proposals that aim to respond to the MAC layer issues that IEEE802.11-2012 and ETSI G5 suffer in certain scenarios. Böhm and Jonsson [3] introduced a real-time layer on top of the wireless communication standard, at the time IEEE802.11p. They create a super frame with a regular Contention Based Period (CBP) and a Collision Free Phase (CFP). The RSUs assume the responsibility of scheduling the data traffic. They assign each vehicle an individual priority, based on the overall traffic density, its geographical position, since some spots are more dangerous than others, and its proximity to potential hazards. RSUs use a polling mechanism to request vehicles to send their data, which includes position, speed, etc. The super frame begins with a beacon mark which is sent by the RSUs. This beacon informs the duration of the CFP, which can be variable, in order to ensure that all deadlines are met. After this polling phase, every vehicle must switch to the regular contention period (CBP), which can be the IEEE 802.11 MAC mechanism described earlier. Since RSUs need to know exactly which vehicles are inside their communication range, vehicles must send out connection setup requests whenever they hear the RSU beacon. This registration process is done in the CBP, which means that in some cases vehicles might fail to register. Their proposal does not mention how RSU coordinate their beacon transmissions.

The idea of dividing the transmission time into a contention free period and a contention based period was already proposed by Tony Mak et al. [4], by suggesting a change in the 802.11 Point Coordination Function (PCF) mode, in order to adapt it to vehicle communications. They proposed a control channel, where time is divided in periodic intervals (also named repetition period). During the contention free period the RSU poll each vehicle, just as it is done in the IEEE802.11 PCF. The polling list must be updated regularly, which implies that vehicles must register and deregister themselves with the RSUs, using a particular time interval for that purpose. This time interval is announced in a beacon sent by the RSUs in the contention period, meaning that there is a risk that the beacon might not be sent if a large number of nodes tries to access the medium. Knowing that, the authors propose that the beacon is repeated in order to increase the probability of being sent.

Another interesting protocol that was not thought for vehicle communications is Self-organizing TDMA (STDMA). This protocol has similarities with the previous ones: it divides the available time into fixed time slots and organizes them in frames. STDMA is in fact a system in commercial use for ships for transmission collision avoidance. The ships listen to the frame and can determine which slots are free or occupied. Each ship will transmit their position message (the higher the speed, the higher will be the update rate). In case no slots are free, different ships can occupy the same slot according to their position, i.e., a ship will transmit in the same slot as the furthest ship away from itself, in order to reduce interference. STDMA always provides channel access with a bounded delay, and it is scalable. Proposals were made to adapt STDMA for V2V communications [5], concluding that such adaptation requires tight synchronization. The packed drop probability was lower using STDMA than the regular CSMA/CA [5].

In all the protocols presented above, there are critical aspects that were not addressed. The protocols need to be scalable, and there is the need to consider the presence of vehicles that might not be protocol compliant, particularly the ones who use the regular IEEE802.11 MAC protocol. Another issue may occur if RSUs transmission range overlap, which might be needed to ease handover process, and if not considered, it may cause a vehicle to receive different time slots from different RSUs. In order to address these issues, another MAC protocol is proposed in the next section: the vehicular flexible time-triggered (V-FTT), adopting a time division multiple access (TDMA) scheme, where RSUs coordinate themselves to schedule the vehicle transmissions.

3 Vehicular Flexible Time Triggered Protocol

To deal with infrastructure to vehicle (I2V) communications in scenarios where a large number of vehicles, that travel at high speed, want to access the medium of communication within a specific deadline, the Vehicular Flexible Time Triggered protocol (V-FTT) was proposed in [6], inheriting its properties from the Flexible Time Triggered Protocol, which was originally designed for wired real-time communications [7]. Since it might be expensive to supply an entire motorway with a communication network consisting of road side units, a concept of safety zone was devised, meaning that at least the most accident-prone spots of the motorway are covered by RSUs that implement the V-FTT protocol. The Safety Zone concept is depicted in Fig. 1.

Fig. 1.
figure 1

Safety zone proposal

Inside the Safety Zone, the roadside infrastructure has control of the medium and uses the V-FTT protocol as will be explained next.

3.1 V-FTT Protocol Description

The V-FTT protocol timeline, similarly to the FTT protocol, is divided into elementary cycles (EC). For the specific case of the V-FTT protocol, the EC consists of three time windows:

  • The Infrastructure Window (IW) – In this window the RSUs broadcast a Trigger Message (TM) that contains all identifiers of the vehicle on-board units (OBUs) that will be allowed to transmit safety messages in the next window of OBU transmission, the Synchronous OBU Window. Any safety information must be, however, validated from the infrastructure side, and in case it is confirmed, RSUs have specific slots after the TM to send warning messages (WM) to all vehicles that might be affected (protocol enabled and others). The WM have variable duration, depending on the number of occurred events. Each RSU has a fixed size transmission slot, where it transmits its TM and any WMs needed. It is important to notice that there is no medium contention during the IW. For that to be possible, RSUs coordinate their transmissions in the Infrastructure Window so that their transmissions do not overlap. More details can be found in [6].

  • The Synchronous OBU Window (SOW) – it is a variable duration window, in which OBUs have the opportunity to transmit their vehicle information (position, speed, etc.) and any safety event (e.g. malfunction or crash warning) based on the vehicle on-board sensors. For that purpose, they have a fixed size slot (SM), which was assigned in the previous IW. This means they can transmit without medium contention. To ensure fairness in medium access, each vehicle is only allowed to have one transmission slot per SOW.

  • The Free Period Window (FP) – This is in fact a contention based window, where all vehicles that do not follow the V-FTT protocol (non-enabled OBUs) are able to contend for the medium, usually for transmission of short messages unrelated to safety. The enabled OBUs are also allowed to contend for the medium but do not have any transmission guarantees. It is important to guarantee that a FP exist in most of the EC in order to allow non-enabled vehicles to transmit their information.

Figure 2 presents the Elementary Cycle and its three transmission windows.

Fig. 2.
figure 2

V-FTT protocol Elementary Cycle

The V-FTT protocol fits comfortably on top of the current wireless standards devised for vehicular communications, IEEE802.11-2012 or ETSI-G5, where in the first case the duration of the Elementary Cycle matches the duration of the Control Channel (CCH) Interval (100 ms), and in the latter, it can vary according to the need.

The next sub-section summarizes the proposal validation, that was made by quantifying several protocol parameters in worst-case scenario.

3.2 Protocol Parameters

In order to assess the V-FTT applicability to real scenarios using current wireless communication standards, several protocol parameters need to be quantified [8]. The maximum range of communication of the IEEE802.11-2012 standard is 1000 m [9], but 750 m have been proven to be a more cautious figure [10], meaning that the RSU coverage range Cr is assumed to have a value of 750 m. In order to ease the handover process in a high speed scenario such as vehicle environment, the overlap of RSU coverage Or is assumed to be at least 25% of the coverage range [11]. This allows to determine the overlapping range Or as well as the maximum spacing between RSUs. The vehicle average length and average spacing are based on [12, 13]. All parameters are summarized in Table 1.

Table 1. Road side units and vehicle parameters.
Table 2. Maximum number of vehicles covered per lane by an RSU with 750 m of coverage.

According to the values shown in Table 1, considering that vehicle average length (Vlength) is 4,58 m, it is straightforward to compute the maximum number of vehicles covered by each RSU, which is dependent on the number of lanes of the motorway, as shown in Eq. (1):

$$ N_{VRSU} = \frac{{2 \times C_{{r_{{}} }} }}{{\left( {V_{length} + v_{spacing} } \right)}} \times n_{lanes}. $$
(1)

Considering that the Safety Messages (SM) must include several fields such as message identifiers, time stamps, vehicle data (position, speed, acceleration, etc.) and safety events warning, it was shown in [6] that its minimum size is 390bit, for non-encrypted data. Assuming that this SM is transmitted using a similar physical layer than IEEE-802.11-2012 or ETSI-G5 then for an OFDM 10 MHz channel its transmission duration is dependent on the bit rate used. The maximum available number of transmission slots for V2I transmission without contention (Synchronous OBU Window) was computed in [8], for the case the Elementary Cycle matches the value of the CCH Interval duration in the IEEE802.11-2012 standard, which is 100 ms. Results are shown in Table 3.

Table 3. Maximum number of transmission slots without contention per Elementary Cycle

Analysing the value in Table 3 and those of Table 2 it is straightforward to conclude that it might be worth to suppress the Free Period in some exceptional cases, only during a small amount of time, to allow more vehicles to communicate in the SOW. Another important conclusion is that there is the need of a scheduling mechanism that can fairly allocate vehicle transmissions in the slots of the OBU window.

4 V-FTT Worst Case Analysis

In order to validate the proposed V-FTT protocol two different scenarios were considered: normal traffic conditions, where the average distance between vehicles is 30 m, and traffic jam, where the average distance was considered to be 10 m [13]. A fairness condition was imposed to the scheduling mechanism of the OBU communications, meaning that after the RSU attribute a time slot for a specific OBU, its next opportunity of transmitting without contention will only occur after all other OBUs in the Safety Zone have had their time slot attribution. An important evaluation parameter is the worst case delay in what concerns the amount of time that occurs between an event detection until the last vehicle in the safety zone is warned. This is named tworst.

For the V-FTT protocol the involved times in the process are:

  • tV2I – period of time that occurs after a vehicle detects an event until it can effectively transmit that information to an RSU.

  • tI2V – period of time that occurs after a RSU schedules a warning message (WM) until it is effectively transmitted.

In fact, there are other times involved, since the infrastructure must validate the event detected by an OBU, and must schedule the transmission of a WM. For a worst case analysis these times are negligible when compared to the other times involved, and therefore they are not considered.

The worst-case for tV2I occurs when a vehicle detects the event just after its last transmission in its respective time slot in the SOW, meaning that the vehicle must wait until its next transmission opportunity. For reasoning purposes, this vehicle is named emitter vehicle. With the scheduler fairness restrictions, the worst case scenario will occur when the emitter vehicle is only allowed to transmit after all the remaining vehicles have had their transmission opportunity (at least the vehicles that are present in the same coverage area of the Safety Zone). Since the number of vehicles can have large variations, the worst-case is considered to occur when the Safety Zone is fully populated with vehicles. This number depends on the number of lanes of the motorway, since more lanes imply that more vehicles can be present. If the number of vehicles travelling in the Safety Zone exceeds the number of transmissions slots available in the SOW, it might happen that the emitter OBU must wait for more than one EC for its transmission opportunity. This is referred as number of waiting elementary cycles wEC (please refer to Fig. 3). Assuming that scheduling is made in every EC, the emitter vehicle is at least certain that its transmission slot will occur in the SOW after wEC. It might occur in the first slot or the last slot of the SOW after wEC, the latest being the worst-case, which results in the equation shown in (2):

Fig. 3.
figure 3

Worst case vehicle transmission instant (tV2I)

$$ t_{V2I} = SOW + \left( {w_{EC} + 1} \right) \times E, $$
(2)

where SOW is the duration of the Synchronous OBU Window, and E is the duration of an Elementary Cycle.

The worst case tV2I value is exemplified in Fig. 3.

As for the case of the downlink time, the RSU always receives vehicle information in the SOW, meaning it has to wait for the next IW (in the next EC) to transmit any warning message. The worst case occurs if the information received from the vehicle is sent in the beginning of the SOW, which means the waiting time will be maximum, assuming that the validation of the safety event does not interfere with the involved times here described. It was shown in [8] that the duration of the SOW can vary, with its maximum value occurring when no free period is allowed. In other words, the maximum value of tI2V is the full length of an Elementary Cycle (E), minus the duration of the TM used by the vehicle to convey the safety event information (please refer to (3)).

$$ t_{I2V} = (E - TM). $$
(3)

After determining tV2I and tI2V, one might think that tworst is obtained by simply adding the first two parameters, however those worst uplink and downlink times never occur simultaneously [8]. Therefore, assuming that the value of the Free Period has negligible variations from one elementary cycle to the next, and also assuming that the duration of the EC remains constant during the period of time involved, it can be proved that tworst is determined by (4):

$$ t_{worst} = \left( {w_{EC} + 2} \right) \times E. $$
(4)

Looking at Eq. (4), it seems that tworst is linearly dependent on the duration of the Elementary Cycle, and that a reduction on the EC length can provide better results. However, such measure would reduce the length of SOW and consequently the number of vehicle transmission slots per EC, which might increase the value of wEC for scenarios with a high number of vehicles, thus inflating the value of tworst. The values for tworst are summarized in Table 4.

Table 4. Worst case warning time (no FP and fair scheduling, Safety Zone with 4 lanes per travel path)

Analysing Table 4, it can be seen that the worst-case results for the lowest bit rates do not allow to support some of the safety applications that need to have low latencies. On the other hand, for the case of the traffic jam scenario, vehicles are not expected to travel at very high speeds, which can increase the maximum latency allowed for safety applications. For the highest bit rates, this problem does not occur. Most importantly, the V-FTT protocol provides a maximum bounded delay even in worst-case scenarios. A disadvantage of using a wireless communication standard that has a fixed EC (CCH interval), such as the IEEE802.11-2012, is that it is not possible to reduce the duration of the EC, which could provide better worst-case values for the cases where the number of vehicles can be scheduled in one SOW.

5 Conclusions and Future Work

This paper discussed an existing shortcoming in current wireless standards proposed for vehicle communications: in certain scenarios, such as high speed motorways with a high number of OBUs, the MAC layers of these standards do not offer a guaranteed bounded delay, which can pose a problem for the deployment of safety vehicle applications with low latency needs.

Several proposals to address these shortcomings were discussed, particularly those based on an infrastructure to vehicle communication, but the lack of RSU coordination and the fact that most of the proposals do not allow OBUs that are not compliant to their protocol lead to the proposal of the Vehicular Flexible Time Triggered protocol (V-FTT), an infrastructure based communication protocol.

In order to demonstrate that the V-FTT protocol has a maximum bounded delay, a worst-case scenario was defined, in terms of the maximum amount of time that occurs between an event detection until all vehicles in the safety zone are warned. It was shown that indeed a bounded delay is obtained, although its value when using the lowest available bit rate is not enough for some safety applications, which in turn leads to the conclusion that a scheduling mechanism is needed to reduce the times involved, while maintaining fairness and scalability of the protocol.

Future work involves testing a real-time scheduler with other parameters, in order to analyse the V-FTT protocol in different scenarios using different algorithms such as Earliest Deadline First or rate monotonic scheduling. Simulation will also be used to compare the behaviour of the V-FTT protocol with the regular MAC layer of IEEE 802.11-2012 and other solutions.