Table of Contents
International Journal of Vehicular Technology
Volume 2011, Article ID 541903, 17 pages
Research Article

Real-Time Communication Support for Cooperative, Infrastructure-Based Traffic Safety Applications

CERES (Centre for Research on Embedded Systems), Halmstad University, P.O. Box 823, 30118 Halmstad, Sweden

Received 15 October 2010; Revised 9 January 2011; Accepted 4 March 2011

Academic Editor: Stefano Basagni

Copyright © 2011 Annette Böhm and Magnus Jonsson. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.


The implementation of ITS (Intelligent Transport Systems) services offers great potential to improve the level of safety, efficiency and comfort on our roads. Although cooperative traffic safety applications rely heavily on the support for real-time communication, the Medium Access Control (MAC) mechanism proposed for the upcoming IEEE 802.11p standard, intended for ITS applications, does not offer deterministic real-time support, that is, the access delay to the common radio channel is not upper bounded. To address this problem, we present a framework for a vehicle-to-infrastructure-based (V2I) communication solution extending IEEE 802.11p by introducing a collision-free MAC phase assigning each vehicle an individual priority based on its geographical position, its proximity to potential hazards and the overall road traffic density. Our solution is able to guarantee the timely treatment of safety-critical data, while minimizing the required length of this real-time MAC phase and freeing bandwidth for best-effort services (targeting improved driving comfort and traffic efficiency). Furthermore, we target fast connection setup, associating a passing vehicle to an RSU (Road Side Unit), and proactive handover between widely spaced RSUs. Our real-time MAC concept is evaluated analytically and by simulation based on a realistic task set from a V2I highway merge assistance scenario.

1. Introduction

Vehicular networks have been of particular interest to the communication research area for several years now. Communication and cooperation between vehicles offer great potential in reducing the number and impact of road accidents as well as in improving comfort and efficiency on our roads. Recently, the allocation of a dedicated frequency band for ITS (intelligent transport systems) communication and the introduction of the IEEE 802.11p standard [1] for short to medium-range intervehicle communication have paved the way for future implementations of communication-based ITS safety and nonsafety applications.

In proactive ITS applications, information is gathered from surrounding vehicles or from static roadside units (RSU) to provide both driver and vehicle with an improved understanding of the current traffic situation and its potential hazards. These types of applications rely heavily on the timely delivery of safety-critical real-time data. We define real-time data as deadline-dependent data traffic that must be delivered to its destination before a given deadline in order to be of use for its, often safety-critical, target application.

The propagation delay for transmissions within an RSU’s transmission range is rather stable. The channel access delay, however, is highly dependent on the available bit rate, the number of communicating nodes and services, the amount of data traffic present in the network, the bandwidth of the communication channel, and the choice of MAC protocol. The IEEE 802.11p standard only offers a random access MAC method, which introduces the problem of packet collisions and unbounded channel access delays. Although wireless communication is prone to unpredictable time-varying changes in connectivity and potentially high bit error rates, a deterministic MAC method has the potential to increase the reliability of proactive ITS safety applications considerably. Several studies (e.g., [2, 3]) point out the limitations of the contention-based MAC protocol of 802.11p and stress the need for deterministic methods supporting real-time data traffic. In the report on a common European ITS communication architecture [4], deterministic channel access methods are defined as one of the criteria for the evaluation of possible ITS communication technologies.

In dense road traffic, the sheer number of communicating vehicles stresses the importance of a proper MAC protocol. Many proactive safety applications depend on fresh data on traffic participants’ current position, speed, or indicated intention (e.g., turn signals). This information has to be exchanged periodically with an update frequency in the millisecond range. Additionally, event-triggered applications (e.g., cooperative collision warning) occasionally add high amounts of broadcasted data to the system.

The implementation and maintenance of communication-based applications in the vehicles or along the road infrastructure is costly. Services aiming to increase comfort and efficiency might help to bear these costs. It is therefore desirable to support heterogeneous services with different requirements on timing and reliability. In its contention-based MAC protocol, 802.11p offers several priority classes to distinguish between higher and lower prioritized services. By adding support for real-time data, we can add deadline-dependent safety applications to the list of heterogeneous services supported by the vehicular network.

Our approach has been to first develop a MAC solution based on IEEE 802.11p, supporting data transfer with guaranteed real-time performance. Next, the protocol was enhanced for improved scalability by introducing geographical priorities. We then focused on methods for connection setup and handover and how these can be integrated into the framework. The contributions of this work can be summarized as follows.

(i) MAC Method Supporting Real-Time and Best Effort Data Traffic
We suggest a deterministic MAC method for V2I-based real-time communication, enhancing but not interfering with the proposed 802.11p standard for communication in vehicular networks. Our solution can be fully integrated with ongoing V2V applications and supports both safety and nonsafety applications. Using so-called real-time feasibility analysis, we are able to guarantee that the accepted delay-sensitive data traffic meets its deadlines. At the same time, we make sure that safety-critical data exchange only uses the amount of bandwidth absolutely necessary to meet its timing requirements, leaving the remaining part of the resources for nonsafety data traffic. The basic protocol was first presented in [5].

(ii) Position-Based Prioritization
Certain road sections (e.g., highway entrances, intersection, or sections with limited sight) are more prone to traffic accidents than others. As presented in [6], we enhanced our MAC scheme by introducing the concept of position-based prioritization, allocating extra bandwidth to vehicles that benefit the most from the support from the ITS safety application and thereby increasing the scalability of the vehicular network.

(iii) Fast Connection Setup
A connection setup process between vehicle and RSU is needed in order to integrate the vehicle into the centralized MAC method. We describe how this process can be defined and investigate the delay introduced by this process (using the random access scheme of 802.11p) before our MAC scheme can take effect.

(iv) Fast, Proactive Handover
Vehicles are usually restricted to an existing road infrastructure and travelling at relatively constant speed. We exploit this aspect in a proactive handover method between sparsely spaced RSUs. Information needed to speed up the handover process can be communicated to the upcoming RSU before the vehicle even arrives there. An early integration into the new RSU’s communication schedule means that the vehicle is ready to participate in the cooperative safety application without additional connection setup delay.
A type scenario based on an RSU-assisted, cooperative merge application for highway entrances with corresponding communication requirements in terms of data packet types, vehicle density, and so forth is evaluated. This scenario gives a realistic set of parameters needed for the evaluation of the proposed framework. The merge assistance case constitutes a type scenario representative of a category of applications where it is desirable to lend a certain amount of the bandwidth to safety-critical data transfer supported by deterministic channel access, while support of best effort services (enhancing comfort or providing entertainment) is desirable.
Other possible type scenarios would, for example, be temporary RSUs at an accident or road work site (e.g., in the form of a parked police car) or RSUs specifically set up at hazardous spots along a rural road, to aid communication over for example a crest or around a curve, where both visual and radio contact between vehicles driving in different directions is inhibited without RSU.
This paper is organized as follows. Section 2 provides a background on cooperative ITS safety applications while Section 3 introduces the merge assistance use case scenario used to explain and evaluate our framework. In Section 4, we discuss the issues of IEEE 802.11p MAC and introduce our position-based real-time MAC protocol. In Section 5, we investigate the delay introduced into the safety-critical system by connection setup and describe our position-based, proactive mechanism for fast handover between RSUs. An evaluation based on a simulation of the merge assistance highway scenario use case is provided in Section 6 while Section 7 concludes the paper.

2. Cooperative ITS Safety Applications

The reduction of fatalities due to road accidents is most efficient and successful in the range of seconds to milliseconds before the actual time of impact, as can be seen in Figure 1. While passive safety applications aim to minimize injuries and damage during and shortly after the crash (e.g., through tightening the safety belts or inflating an air bag), the focus of active safety applications is on avoiding the accident altogether. In this chapter, we provide a background on communication in vehicular networks by touching upon different wireless technologies suitable for ITS applications and current standardization efforts, presenting common data packet types and discussing the major challenges that intervehicle communication is facing.

Figure 1: Schematic visualization of the impact of ITS safety applications on fatalities reduction, derived from the European Integrated Safety Program.
2.1. Cooperative ITS Systems

There are four types of communicating entities in a vehicular network [4]: two mobile entities, vehicles and personal, that is traffic participants equipped with personal communication technology such as a cell phone, and two stationary entities, the RSU and the central system. We define the term infrastructure as access points at the roadside that might or might not be connected to a communication backbone. Using this definition, an RSU comprises both statically installed access points at for example a highway entrance or an intersection and semi-static units in form of a police car securing an accident site or a temporary access point put up at a road work site.

In the field of cooperative ITS, a large variety of applications are discussed for future implementation. Depending on for example their transmission range and achievable data rates, different wireless access technologies suit certain application areas particularly well. These technologies can roughly be divided into long range (e.g., GSM, UMTS), medium-range (e.g., WLAN-based), and short range (e.g., infrared, RFID).

With high data rates and a transmission range of up to 1 km, WLAN-based technologies are well suited for cooperative ITS safety applications. A particular WLAN standard for fast intervehicle communication, IEEE 802.11p at 5.9 GHz, was recently accepted as a new IEEE standard. IEEE 802.11p offers data rates up to 27 Mbps (although a bit rate of 6 Mbps is recommended to maintain sufficient reliability of the data transfer). Our recent field measurements [7] with two 802.11p-enabled vehicles sending at 5.9 GHz confirmed a communication range between 300 to 600 meters, depending on the relative speed and assuming line of sight. The proposed standard offers adhoc communication between vehicles and between vehicles and RSUs. For cooperative safety applications with timing requirements in the second to millisecond range and coverage of several hundred meters, 802.11p offers most potential and thus is the standard that our proposed communication system is based upon. Details on handover and MAC methods of the upcoming IEEE 802.11p standard and its shortcomings are explained in chapter 3.

2.2. Standardization Efforts

Different standardization bodies are working towards a common ITS communications standard. The wireless access for vehicular environments (WAVE) standard is developed by IEEE and comprises 802.11p for the physical and MAC layers of the communication stack and a standard called IEEE 1609 for upper layers. At the same time, ISO is working on the communication access for land mobiles (CALM) [8] standard which provides a set of about 20 standards. The goal is to support a large variety of ITS-related applications with transparent, continuous communication through the use of all types of wireless access technologies, for example, GSM, UMTS, WiMAX, WLAN, and infrared. CALM M5 defines a CALM supported standard for medium-range communication that is closely related to 802.11p.

Specific frequency bands are dedicated for safety-related ITS communication in different parts of the world. In the US, seven channels of 10 MHz each in the 5.9 GHz band were dedicated for this purpose alone. In Europe, so far only 30 MHz are planned to be set aside for ITS safety communication [4]. Only two channels, a control channel and a service channel of 10 MHz each, will be available in the initial stage. As these channels are dedicated for safety-related communication only, additional frequency channels (e.g., in the 5.4 GHz band) might be used for comfort or efficiency applications. As long as vehicles are equipped with a single transceiver, no simultaneous data transmissions from a node are possible, no matter how many channels that are available to the application. This fact, along with the limited access to dedicated ITS bands in Europe makes channel access control mechanisms particularly important for safety critical applications.

2.3. Types of Data Exchange

Depending on the application and its timing demands, different types of data need to be exchanged. We categorize these into three different message types.

(i) Warning Messages
In case of an emergency, event-driven messages are sent out to each vehicle or RSU that might be interested in the information. A sudden deceleration (possibly due to a driver hitting the break) is an example of an event that might trigger a collision avoidance application to send out this type of warning messages to surrounding vehicles. In the WAVE standard, event-driven warning messages are defined as decentralized environmental notification message (DENM). Here, time is a crucial factor and messages are expected to arrive at their destination before a strict deadline. Missing a deadline might compromise the success of the entire application.

(ii) Heartbeat Messages
Taking into account variables as the length of the break path or the driver reaction time, it becomes obvious that, in case of an emergency, the time left for communicating and processing data is reasonably short. Many proactive ITS safety applications are therefore based on continuously updating the driver’s awareness horizon. Such applications are often based on local dynamic maps (LDM), including the static road infrastructure and highly dynamic data about the current traffic situation, and these maps need to be continually updated. For this, the WAVE standard defines cooperative awareness messages (CAMs), including information about the current position, speed, and heading of the car. These CAMs are broadcast periodically by each vehicle, which is bandwidth consuming, but necessary. Although CAMs are not sent out specifically in the event of an emergency, they must still be viewed as safety critical data, as a lack of continuous up-to-date information about the current traffic situation would render important safety applications impossible.

(iii) The period of heartbeat messages might vary depending on the current need from the application layer. During a lane change for example the vehicle might want to increase the number of heartbeats it sends out to its surrounding traffic participants. Vehicles residing in a particularly accident-prone or high-risk geographical area might want to do the same.

(iv) Nonsafety Messages
Both V2V and V2I communication can be used to enhance road traffic efficiency and driver comfort. This category includes, for example, digital map updates (possibly with navigation aid or local information on restaurants or tourist attractions, etc.), Internet access through RSUs and other access points and entertainment applications. Although this type of service still demand some degree of quality of service (QoS), these messages are not considered safety-critical and should therefore not interfere with the successful transmission of safety-critical data traffic. Nonsafety applications are probably needed as a selling argument to increase a car buyer’s interest in spending extra money on communication equipment in a vehicle or to cover deployment and maintenance costs of an RSU. Missing the deadline of nonsafety messages does not typically cause any errors.

3. The Merge Assistance Use Case Scenario

Traffic accidents are typically concentrated to certain road sections such as highway entrance ramps, intersections, or areas with road work. In such areas, it is justified to install an RSU offering V2I communication. For financial reasons, a seamless RSU coverage along the roadside cannot be expected in the near future, and we therefore see our framework as an addition to V2V applications at particularly dangerous road sections. A merge assistance application at a highway entrance ramp was chosen as the type scenario for the system which is described in detail below.

The merge assistance scenario is based on V2I communication involving an RSU at a highway entrance ramp that supports both entering and passing vehicles with heterogeneous communication services covering a variety of QoS classes. Through short, periodic heartbeat messages from the vehicles, the RSU is informed about individual positions, states, and intentions. The RSU broadcasts recommendations concerning the merging process back to the vehicles. Moreover, vehicles passing an RSU are provided with updates on, for example, current road, traffic, or weather conditions. Vehicle heartbeats, RSU recommendations and road information updates are all considered safety critical. At the same time, bandwidth should be reserved to support ongoing V2V applications or various V2I-based, best-effort data traffic classes as for example digital map updates or commercial services. 802.11p-based V2V applications (e.g., collision avoidance) are maintained while the vehicle moves through a region with an RSU without involvement of the RSU. Therefore, V2V data traffic concerning these applications, although safety critical in their nature, is not part of what we handle as real-time data traffic. The data traffic classes are summarized in Table 1.

Table 1: Data traffic classes.

Our centralized approach requires the RSU to know about and identify the vehicles currently residing within its transmission range and their communication needs. This makes a connection setup between vehicle and RSU necessary. One option is to let the vehicles send out connection setup requests (CSR) as soon as they can hear the RSU. Even if the RSUs along a road might be widely spaced, we can view this chain of connection setup and disconnection as a series of handover procedures. Before going into further detail on that, the standard IEEE 802.11p MAC protocol and our proposed 802.11p MAC enhancements are described, providing more insight into our assumptions and the system at hand.

4. Position-Based Real-Time MAC for 802.11p

A MAC protocol is a set of rules that determines who gets to access the common medium (in our case, the dedicated frequency band of the wireless medium), when to access it, and for how long. MAC protocols can ensure a fair access to the medium or give priorities to certain data traffic classes over others (e.g., prioritize collision warning messages over weather condition updates).

4.1. Contention-Based and Collision-Free MAC Protocols

We distinguish between two main types of MAC methods, contention-based and collision-free MAC protocols. A well-known contention-based MAC protocol is carrier sense multiple access (CSMA). By listening to the medium, a node can determine if the medium is free or occupied and hence act accordingly. If two or several nodes simultaneously determine that the medium is free, packet collision will occur and render all data useless. A new sending attempt has to be started, which increases delay and wastes bandwidth.

Enhancements of CSMA, found in for example IEEE 802.11e introduce individual waiting times (of random length) between the point in time when the medium is found to be available and the point in time when the transmission may start. This reduces the probability of packet collisions. If a collision occurs, random backoff times before the retransmission attempt decrease the chance that also the retransmitted packets collide. A guarantee that no collisions will occur cannot be given in contention-based protocols and therefore, this category of MAC methods is not deterministic and not suitable for real-time data traffic.

There are several mechanisms to avoid packet collisions entirely. Examples are frequency division multiple access (FDMA) or time division multiple access (TDMA), where each node (or data traffic class) gets its own frequency or time slot where its data can be sent without competition. Collision-free MAC protocols are considered deterministic as data collisions do not occur and a worst case delay from packet generation to channel access can be calculated. On the down side, collision-free MAC methods require central coordination and/or are less flexible. In TDMA for example, each node needs to be informed about the beginning and duration and/or periodicity of the time slot that is dedicated for it. For a fixed schedule, this may be done only once in the beginning, while adaptability to changing network conditions requires a variable schedule that needs to be communicated to the nodes.

4.2. Standard IEEE 802.11p MAC

Most versions of IEEE 802.11, for example, 802.11b [9] used for WLAN applications today, define both a contention-based and a collision-free phase. The contention-based phase uses the CSMA/CA protocol for medium access control. Before starting a transmission, a node senses the medium until it is found to be idle. After an additional waiting time (interframe spacing, IFS), a transmission attempt can be started. Collisions occur when two or more nodes happen to start sending at the same time. A randomized backoff time is enforced on those nodes and a new transmission attempt is started.

As its contention-based MAC protocol, the upcoming IEEE 802.11p MAC method employs EDCA (enhanced distributed channel access) [10], an enhanced version of CSMA/CA originally defined in IEEE 802.11e. Four different access classes provide support for several QoS levels. Fixed waiting times (arbitrary interframe spacings, AIFS) of different lengths are used to make sure that high-priority packets get access to the medium first. Within the respective priority classes, however, packet collisions are still possible. After a packet collision has occurred, a back-off time is randomly chosen from an interval (the contention window, CW). The window size is also coupled to the priority level, giving high-priority packets the higher probability of channel access after a collision. The initial size of the CW is given by the factor CWmin. Each time a transmission attempt fails, the CW size is doubled until reaching the size given by the parameter CWmax. Table 2 summarizes the parameter set defined for EDCA in 802.11p, where 1 denotes the highest priority level and 4 the lowest. The parameters are given in time slots where one slot is defined to have a duration of 8 μs.

Table 2: EDCA parameters.

Although these priorities can be used to increase the probability of certain packets to get access to the wireless channel, there are no guarantees that this will happen before a predefined deadline. The following section describes shortly how we introduced a deterministic MAC method into 802.11p (which is vital for the support of safety-critical applications), while still trying to maximize the amount of best-effort data in the network.

Figure 2 shows an example where several nodes try to access the common wireless medium. Depending on their access class, they have different waiting times (AIFS). If a collision occurs, individual random backoff times are employed and these are also coupled to the priority of the respective node. Despite this differentiation, collisions within or between access classes are still possible, and therefore no timing guarantees can be given.

Figure 2: The contention-based MAC method of 802.11.p with different IFSs depending on priority class.

In most versions of 802.11, even a collision-free phase is present (Figure 3). Due to reasons of complexity, this phase is not present in the proposed IEEE 802.11p standard for ITS applications. The collision-free phase needs support from a “coordinator” (e.g., an RSU or a dedicated centralized vehicle) that has knowledge about all communicating nodes and their communication requirements and that takes responsibility for scheduling the traffic and polling the mobile nodes for data. A node can thereby be assigned the right to use the channel without competition for a specified amount of time in the collision-free phase. A short waiting time before transmission, the short iInterframe spacing (SIFS), is defined for this phase, accounting for the time it takes a node to switch from receiving to transmitting mode or vice versa. As no collisions occur, this access method is deterministic and therefore suitable for the delay-sensitive real-time data traffic needed in many ITS safety applications.

Figure 3: The collision-free MAC in other versions of 802.11 with RSU as coordinator.
4.3. Position-Based Real-Time MAC-Protocol Details

In IEEE 802.11p, despite the different QoS classes enforcing different waiting times (interframe spacing) before transmission attempts, collisions within a class are still possible and therefore, no timing guarantees can be given. Unlike most IEEE 802.11 standards, 802.11p does not provide an optional CFP, centrally controlled by an access point through polling. We propose to reintroduce the CFP by placing a real-time layer on top of 802.11p. This layer schedules the real-time data traffic before handing down best-effort packets to the unaltered 802.11p protocol. In our layer, time is divided into superframes (SF) of fixed size, each consisting of a CBP and a CFP (Figure 4). The CFP needs support from a RSU that takes responsibility for scheduling the data traffic and polling the mobile nodes for data. A mobile node is thereby assigned sole right to use the channel for a specified amount of time. An RSU can also assign these rights to itself without polling. Based on the RSU’s knowledge of the QoS demands in the network, real-time data for the next superframe is scheduled according to earliest deadline first (EDF). As no collisions can occur, the CFP is deterministic and suitable for the delay-sensitive real-time data traffic needed in many ITS safety applications. A certain percentage of the SF is set aside for the CBP where nodes compete for access using regular CSMA/CA. The ratio between the CBP and the CFP within an SF can be determined by schedulability analysis. The RSU sends out a beacon to mark the beginning of an SF, stating the duration of the CFP. In that way, each vehicle knows when the polling phase ends and when to switch to the CSMA/CA scheme of the CBP.

Figure 4: Adaptable ratio between CFP and CBP.

In order for the data traffic of a vehicle to be scheduled, this vehicle needs to be known to the RSU. Vehicles therefore announce their presence through connection setup request (CSR) sent during the CBP (see Section 4 for details). There is a small probability that a vehicle fails to become part of the RSU polling scheme before leaving the transmission range, due to competing for access in the CBP. This is another reason for attempting to keep the CBP as long as possible. Furthermore, the probability of packet collision can be reduced by giving CSRs the highest priority defined for the CBP in 802.11p. A vehicle that fails to communicate its CSRs to the RSU would still be able to receive broadcasts from the RSU and take part in best-effort data transmissions or ongoing V2V applications.

Through the vehicles’ heartbeat messages, the RSU knows each vehicle’s individual position in relation to the zone of hazard (e.g., a highway entrance, a temporary road work site, or a particularly accident-prone road section). We have defined a number of zones of descending priority around the hazard zone (Figure 5). Each zone defines the period and deadline for real-time data sent from a vehicle residing in this zone. The closer to the hazard zone a vehicle is positioned, the shorter its period and deadline are (which through EDF scheduling directly influences its priority). All safety-critical data (heartbeat messages from a vehicle and safety-critical data broadcast from the RSU to the vehicles), that is, data sent in the CFP, use the period and deadline defined for the priority zone that corresponds to the current position. Decreasing the amount of bandwidth used in less important areas of the RSU’s transmission range frees resources that can either be used to increase the data transfer rate in prioritized areas or to accommodate an increased overall number of vehicles.

Figure 5: Position-based prioritization zones.

Figure 6 provides a flow chart of the transition of a vehicle from V2V mode (when no RSU is in range) to the RSU-based mode, where our proposed position-based real-time MAC scheme comes into play. As soon as a vehicle hears a beacon from the RSU, it starts its connection setup attempt. After a number of unsuccessful attempts, it will return into V2V mode, while the reception of an individually addressed poll from the RSU indicates that the integration into the RSU’s schedule had been successful (if a proactive handover approach, as described in Section 5, is employed, no active connection setup attempts will be necessary and the vehicle will already be included into the schedule and polled when it approaches the RSU). The vehicle is now allowed to send its real-time data answering the poll in the CFP and use the CBP to send best-effort data traffic. A counter ensures that V2V mode is entered again after several SFs have passed without the reception of a poll.

Figure 6: Connection setup and data exchange from the perspective of a vehicle.

The criteria for the RSU to set the zone boundaries are not defined in this work as this requires an analysis of each individual RSU site in terms of radio environment, maximum transmission range, number of lanes and so forth. Even the proper number of priority zones might vary between sites (e.g., depending on available bandwidth or the number of lanes, and thereby the number of vehicles sharing the bandwidth).

Applications like lane change warning rely on up-to-date information provided by the heartbeat messages. A vehicle residing in a low-priority zone that is currently taking part in an overtaking or lane change maneuver might therefore want to switch into a higher priority while the proper safety application is active. This spontaneous priority switch triggered by individual applications ensures that heartbeat-depending V2V safety services still get the quickest status updates they need, independent of the priority zone they are in.

The timing requirements on the application level can for some situations be calculated as the time instance when the driver needs to react to, for example, reduce the speed to avoid a collision. More generally, however, periods and deadlines are set by the RSU according to the priority zone boundaries. In the scope of this paper, these deadlines are mapped directly into MAC layer deadlines. A framework to incorporate transport layer retransmissions—still not violating the real-time demands, by for example shortening the MAC layer deadlines for ordinary transmissions—can, however, be applied [11]. This introduction of redundancy will help to reduce the negative effects of the error-prone wireless medium on the error rate of safety-critical real-time packets.

4.4. Schedulability Analysis with Position-Based Priorities

The real-time schedulability analysis used, first introduced in [12] for processor scheduling, contains two tests to determine if the bandwidth reserved for the CFP guarantees that no real-time deadlines are missed. Firstly, the utilization of the wireless channel must not exceed one, and secondly, the workload function, that is the sum of the transmission times for all packets with an absolute deadline less than or equal , must be less than or equal to [13]. If the schedulability tests are passed, the CFP may be reduced by a predefined number and the analysis repeated until the minimum CFP is found. Durations and deadlines of all periodic real-time messages are thus needed.

Let our scenario contain a total of different, logical, real-time (RT) channels, each representing a packet flow with real-time requirements from a specific source and for a specific traffic class (see Table 3 for a complete parameter list for this section). An RT channel is defined by its source, destination, period , packet length , and deadline , where . We further distinguish between two directions of transmission, vehicle to RSU ( → RSU), initiated by polling, or RSU to vehicle (RSU → ), without polling. Any packet transmission is preceded by an SIFS, of duration , set as a system parameter. Assuming a bit rate , the total transmission time, , of a packet is: with a polling packet of length and propagation delay . As stated, an SF of length consists of a CBP of length and a CFP of length . Only can be used for transmitting real-time data. Towards the end of , there might not be enough time for a full packet to be scheduled. This is accounted for in the calculations by reducing by , the transmission time of the longest packet specified by any RT channel: The remaining fraction of the total bandwidth available for RT traffic is The original bit rate, , is thereby reduced to an experienced bit rate of while the experienced transmission time, , of a real-time packet is extended accordingly: The immediate transmission of a packet belonging to RT channel may be delayed by (in this parameter, the beacon that lies between the end of the CBP and the start of the next CFP is included). If the time before the start of a CBP is too short to accommodate another packet, the waiting time is increased by . Further, the worst-case blocking delay due to an ongoing lower-priority packet transmission is . The original deadline, , of a packet is therefore reduced to an adapted deadline (the maximum queuing delay), . Since the propagation delay is not included in for RSU → traffic, this must be accounted for, as

Table 3: List of parameters.

The analysis is done in two steps. A necessary, but not sufficient, condition is that the utilization of the wireless link must never exceed one. According to EDF scheduling theory [14], the utilization of periodic real-time traffic is

The second step entails the workload function, , which must be less than or equal to . The following definitions are needed.(i)The hyperperiod (HP) is the least common multiple of all periods of all RT channels.(ii)The busy period (BP) is any interval within the HP during which the link is not idle.

Then is the sum of the transmission times for all packets of all RT channels with an absolute deadline less than or equal to , where signifies the number of time units elapsed since the beginning of the HP [12, 13]: where the number of instances of evaluation can be reduced to the instances of where a deadline occurs and that falls into the first BP in the first HP of the schedule where all periods start at time zero.

We now extend the real-time schedulability analysis described above with the concept of position-based priorities and use the traffic classes of the merge assistance type scenario as an example. Vehicle heartbeats hence adopt period and deadline based on the priority zone the vehicle currently resides in. RSU merge recommendations are always sent with the period and deadline of the highest priority zone. Road information broadcasts use the period of the lowest priority zone but employ a shorter deadline. The parameters for the different real-time traffic classes are then deadline for merge heartbeats, , merge recommendations, , and road information updates, . Periods are denoted accordingly as, , , and . The number of priority zones lies within the interval , where is the number of zones chosen for the specific road site. According to (5), we can write the periods and adapted deadlines as

The two steps of the real-time schedulability analysis introduced generally in (6) and (7) are adapted to the parameters of the specific scenario as follows. The utilization is calculated as where is the number of RT channels for merge heartbeats per zone and , , and denote the experienced transmission times of each traffic class, respectively. Similarly, is expressed as: where if = true, otherwise zero.

4.5. Related Research

Mak et al. [15] propose a similar V2I MAC solution with a polling-based phase for safety data exchange and a phase for nonsafety services. However, since no schedulability analysis is made, no guarantees for timely delivery of real-time data can be provided. Further, [15] assumes the availability of several separate data channels for ITS applications, which is unrealistic since the dedicated ITS frequency band often is very limited (30 MHz is currently reserved in Europe). In [16], different priority classes based on the urgency of the message are suggested, such that the most critical data packets are sent with the highest update frequency, but no connection between the vehicle’s location and the criticality of the data is made. The position of the vehicle has been used in frequency division MAC methods, see for example [17], where geographical zones are coupled to certain frequency bands, again assuming availability of several frequency bands.

5. Fast Handover in V2I Communication

In a WLAN, mobile nodes (MNs) are associated with an access point (AP) as long as a satisfactory communication quality with this AP can be maintained. If the mobile node is about to leave the AP’s transmission range, a handover process is initiated, and an association with a new AP is established. The process leading up to and executing a handover can be divided into three phases.

(i) Detection Phase
The need for a handover is detected by the MN by monitoring the amount of consecutive unacknowledged data packets or by detecting when the signal strength or the signal-to-noise ratio drops under a specified threshold. This detection phase stands for approximately 85% of the total handover duration.

(ii) Search Phase
In the search phase, about 15% of the handover time, an MN attempts to find a new AP. This can either be done passively by listening for a beacon from an AP, or actively, probing each frequency channel and awaiting a response from an AP.

(iii) Execution Phase
Here, the actual handover takes place through the exchange of authentication and association requests and responses by the MN and the new AP, accounting for 1% of the total handover time.

These three phases define MAC layer handover within a single IP subnet. In larger networks, handover between subnets affects even the network layer and the address that associates an MN to a subnet needs to be changed. Implications of that change are described and taken care of in for example mobile IP [18] or its enhancements. In this paper, our focus lies on MAC layer handover.

5.1. Handover in IEEE 802.11p-Based V2I Communication

In vehicular networks, the MN is a vehicle while the AP corresponds to an RSU. In a highly mobile vehicular network, the delay introduced by handover is of special concern, as vehicles only stay in the transmission range of an RSU for a relatively short time span (approximately 20 s for a transmission radius of 400 m and a vehicle speed of 40 m/s). Additionally, ITS safety applications benefit from very short connection setup times with guaranteed delay bounds, so that the deadlines of the real-time data traffic are not compromised.

For the efficient data exchange between high-speed vehicles or between a vehicle and an RSU, IEEE 802.11p specifies a minimized set of specifications for the execution phase of the handover process. A WAVE basic service set (WBSS) is built around an RSU (or, in V2V communication, around any vehicle assuming the role of a WBSS leader). The existence of a WBSS is announced through the WAVE service announcement (WSA), a beacon from the WBSS leader (in the case of V2I communication, the RSU). A vehicle that hears this beacon configures itself according to the information contained in this frame and is immediately ready to communicate with the RSU according to its rules. No authentication or association is required. This ensures that the vehicle is ready to start communicating with the RSU much quicker than in the original WLAN MAC standard. For privacy reasons, a mobile node in a vehicular network changes its MAC address regularly. At system startup, a new MAC address is randomly determined to make it more difficult to track a certain vehicle’s movement. As there is no association phase when a vehicle enters an RSU’s WBSS, this MAC address will not be passed to the RSU, further enhancing the driver’s privacy. On the other hand, the lack of an association and deassociation process means that the RSU has no means of identifying a vehicle or to know if it has left its transmission range.

Handover between RSUs in a vehicular network differs from a normal WLAN in several ways. (i)Vehicles have access to their speed and geographical position (through a GPS receiver) and are bound to a predefined road network, that is, their movements are easily predicted. RSUs are usually static and placed strategically along a road. The number of RSUs that are appropriate for a handover is therefore limited and often predictable. (ii)Especially in the early phase of ITS implementation on our roads, a full coverage of the road network with roadside infrastructure cannot be expected. Therefore, there will be no seamless handover but connection setups to rather irregularly spaced RSUs. Communication between RSUs can be assumed (either through cables along the road or a wireless communication technology), so that an RSU can presumably exchange information with its neighboring RSUs.(iii)Right now, the number of dedicated ITS bands is limited. In Europe, for example only 30 MHz are set aside for ITS applications and only one 10 MHz control channel will initially be used for V2I communication [4]. This further reduces the complexity of finding a new AP as no probing and scanning over multiple channels are required.(iv)We assume that an RSU is only used to broadcast data (e.g., control data, beacons or application specific data) to the vehicles in its communication range or to organize the channel access. As long as RSUs are not structured in subnets and are used to relay messages from vehicles into other parts of the vehicular network, layer 3 handover is not necessary and is therefore not considered in this paper.

5.2. Reduced RSU Connection Setup Time

As mentioned before, the search phase, accounting for a majority of the handover delay in regular WLAN, does not come into play at all in a network where all access points operate on the same frequency channel. No scanning is required, and a vehicle merely listens for the WSA (in our case the beacon announcing the start of a CBP in the beginning of a superframe) and replies with a connection setup request (CSR). A vehicle enters the RSU’s transmission range and as soon as it hears this WSA beacon, it will try to make its presence known to the RSU. This is done in the CBP and therefore, no guarantees for a successful channel access can be given. Nevertheless, the four priority levels provided in the CSMA/CA-based MAC protocol of 802.11p can be used to limit the number of frames competing with a connection setup. We assign the following applications classes to the four available priority levels.

(i) Priority Level 1 (Highest)
Safety-critical V2V alert messages, for example collision avoidance applications.

(ii) Priority Level 2
Connection setup request (vehicle to RSU).

(iii) Priority Levels 3-4
Different levels of best effort comfort/entertainment application data.

Only safety-critical V2V application data (e.g., alert messages from collision avoidance applications) have a higher priority than the CSR. As these V2V alert messages only occur in the rare case of an emergency, CSR of a vehicle usually only competes with other CSRs from other vehicles entering the transmission range at approximately the same point in time.

To keep the overhead at a minimum, IEEE 802.11p defines no association, authentication, or disassociation process. For our system solution, however, the RSU needs to be able to uniquely identify each vehicle and address it with individual polling messages. According to the standard, as mentioned above, at system startup, that is whenever a vehicle is started, a temporary MAC address is randomly determined. We assume that this MAC address is communicated to the RSU in the CSR and then used by the RSU to address the vehicle. On the other hand, we do not introduce any authentication data exchange in conjunction with the connection setup. The disassociation from an RSU happens automatically after a threshold of unanswered polling messages to a vehicle or based on the RSU’s knowledge of the vehicles current position relative to the RSU’s own approximate transmission range.

Anastasi et al. [19] conducted measurements with 802.11b enabled devices. They measured when (at what distance from the AP) a mobile node starts receiving beacons from the AP and experience considerable differences in their series of measurements even at moderate mobility. This indicated that changes in the surrounding environment, weather, conditions and so forth influence an AP’s actual, experienced transmission range. Adding high mobility and a constantly changing environment (moving vehicles) around an RSU to the equation, we can assume that different vehicles, approaching an RSU at the same time, will hear the RSU’s WSA beacons at different distances to the RSU. Vehicles lying close behind a large bus or truck might experience radio shadow, hindering the reception of the WSA. How much these individually experienced transmission ranges differ must be further investigated. For now, we assume that this difference in experienced RSU transmission range might be as high as 100 m. A worst case scenario for an RSU at a 3-lane highway would therefore be a total of 36 vehicles hearing the WSA for the first time and trying to send out a connection setup request approximately simultaneously. Here we assume very dense traffic with a vehicle spacing of 20 m. Although being unlikely to occur, this scenario shows that it is possible that a high number of vehicles want to attempt a connection setup at the same time. This would lead to an increased probability of packet collisions during the contention-based random access phase and delay the association of vehicles to the RSU. As the connection to the RSU is a prerequisite to take part in the collision-free exchange of safety-critical data, this delay should be reduced as much as possible; ideally, it should have a guaranteed upper bound.

If a CSR was sent successfully to the RSU, the vehicle is integrated into the RSU’s schedule for channel access and polled for data in the upcoming CFP. CSRs that are sent out in the beginning of a CBP might lead to a first polling message from the RSU already during the same superframe (Figure 7). Ideally, the connection setup delay (i.e., the delay between the arrival of the CSR at the RSU and the point in time when the first polling packet is sent out) is where denotes the time required for scheduling, is the point in time when the CSR arrives at the RSU, is the point in time when the current CBP ends and is the duration of the CBP (see Table 4 for a complete parameter list for this section). This implies that if the request reaches the RSU in the end of a CBP (or in the case of a short CBP), it will not leave the RSU enough time to schedule the data packets for the next CFP, and the node will first be polled in the following superframe.

Table 4: List of parameters.
Figure 7: Best case waiting time between successful CSR and first polling message.

For periodic real-time data traffic, our framework assumes a deadline that is equal to the period. The EDF scheduling policy makes sure that the packet with the tightest timing requirement is sent first. During the connection setup process, the first time a vehicle’s heartbeat message is scheduled by the RSU, its deadline is set equal to the end of the ongoing superframe. EDF scheduling thereby ensures that the vehicle is polled within this. After that, the deadline of the heartbeat messages is set equal to its period, which is dependent on the vehicle’s location within the RSU’s communication range (as explained in Section 6). In the worst case, the time span between an acknowledged CSR and the first time a new node is polled for data is therefore (Figure 8): where is the duration of a superframe, is the duration of the CFP, and and denote the transmission delay and the propagation delay, respectively, of a data packet to be sent by the MN.

Figure 8: Worst case waiting time between successful CSR and first polling message, when the CSR arrives when the scheduling process for the next CFP just started.

Since the delay until a connection setup request results in a successful access to the shared frequency channel in the CBP cannot be bounded, there are still no guarantees that a vehicle is able to connect to an RSU within a predefined time span from entering its transmission range.

5.3. Proactive Handover between RSUs

As long as we depend on the random access MAC protocol of 802.11p, we cannot guarantee that a vehicle will be integrated into the collision-free infrastructure-based communication within a certain delay bound. We therefore need an alternative way to let the RSU know that a new vehicle has entered its communication range.

Through heartbeat messages, an RSU is informed about a vehicle’s position, speed, and direction of movement. On a highway or rural road, a vehicle will only have one RSU further down the road to choose from when a handover becomes necessary. This next RSU is known to the old RSU before the vehicle leaves the transmission range. Thanks to the knowledge of the vehicle’s speed, its approximate arrival time at the next RSU can be predicted. A new RSU can now integrate the vehicle into its schedule and start polling it proactively before it even enters the RSU’s transmission range. Figure 9 shows the proactive handover mechanism from the RSU’s point of view, which updates the schedule with new vehicles after either the reception of a connection setup request or according to the knowledge from proactive handover data passed between neighboring RSUs. When a vehicle leaves the RSU’s transmission range, the RSU calculated the approximate arrival time at the next RSU and passes on this information to the next RSU in order to enable proactive handover.

Figure 9: Proactive handover mechanism from the RSU’s perspective.

In order to prevent proactive polling from taking away too much bandwidth from application data transfer, a threshold of 10% of the length of an entire superframe is introduced for proactive polling. Figure 10 shows the introduction of the proactive polling phase (PPP) into the superframe structure. A worst case connection setup delay can then be calculated as that is, the length of one superframe plus 10% of a superframe, as seen in Figure 11. This case occurs when a vehicle just misses its proactive polling message when it enters the new RSU’s transmission range in the beginning of the PPP and has to wait until the end of the next PPP to receive the next proactive polling packet. The delay for connection setup with the new RSU therefore has an upper bound, that is, we can guarantee that the vehicle is ready to participate in the collision-free safety-critical communication after no longer than .

Figure 10: Proactive polling phase (PPP) as part of the collision-free phase of the superframe.
Figure 11: Worst case waiting time until connection setup for proactive polling.

Assume that vehicles leave the transmission range of their current RSU at an initial speed of 30 m/s. In order to allow for changes in the vehicle’s speed until it reaches the next RSU, a margin of 20% is introduced, that is even though the vehicle is expected to arrive at the following RSU at a certain instance in time (based on a constant speed of 30 m/s), the RSU starts polling early enough to account for a 20% increase in average vehicle speed over the distance between the two access points. In our example, this means an increased average speed of 36 m/s. The new RSU starts polling seconds after the vehicle left the old RSU’s transmission range: where is the distance between the RSUs and and is the transmission radius of the old and the new RSU, respectively. The transmission and propagation delay of the information sent between the old and the new RSU are negligible.

When a vehicle experiences a significant decrease in average speed (e.g., as a consequence of a traffic jam building up in between the RSUs) or leaves the highway entirely, the RSU cannot continue sending out proactive polling messages indefinitely. We allow a decrease in average speed of 20%. seconds after the vehicle left its old RSU, the new RSU stops the proactive polling to save bandwidth, assuming the vehicle has left the road, parked, or been delayed. A vehicle that reaches the new RSU after this threshold has to go through the regular connection setup process by sending a CSR and waiting to be scheduled. is calculated as follows:

Equation (13) assumes a dense but normal road traffic flow. If, in the case of road congestions, the 10% of the bandwidth cannot support a proactive polling packet per expected vehicle and superframe, the PPP will be distributed over two or more consecutive superframes. The worst case delay for connection setup will thereby be increased to: where is the number of superframes appropriate as the total period for the polling. Despite the increased delay, there is still a guaranteed upper bound. Our handover method therefore fits perfectly with our deterministic MAC protocol developed for safety-critical RSU-supported applications.

5.4. Related Research

Solutions to reduce handover delays are mostly targeting the detection and search phases of the handover process. Most authors assume a regular WLAN with several APs operating on various frequencies and a relatively slow mobility amongst the MNs.

In [20], Montavont et al. present the idea of periodic scanning, where an MN performs scans for possible new APs already while it is still connected with good channel quality to an AP. Short probes sent out on varying channels interfere with the ongoing data traffic but, on the other hand, the MN is ready for the handover execution phase as soon as the need for a handover arises. In order to eliminate the search phase and speed up the execution of a handover, Tseng et al. [21] propose a location-based solution where an MN, knowing its own position and direction of movement, gets information on nearby APs from a location server. The server also performs proactive authentication and association on behalf of the MN, reducing the handover duration even further. Montavont and Noel [22] describe a similar solution where a so-called GPS server collects movement updates from the MNs and compares them with a known topology of APs in order to recommend the handover to a specific AP.

As mentioned earlier, mobility in vehicular networks is fairly predictable. In their paper [23], Paik and Choi take advantage of this fact and chose the next AP and the best time for handover based on a vehicle’s known mobility pattern. Their solution targets public transport vehicles like busses and trains, running on a known and tight schedule along a predefined path. Based on their mobility prediction-based WLAN enhancement, fast handover between hot spots is performed and passengers experience seamless connectivity.

Shimizu et al. [24] target an 802.11 enhancement for communication between high-speed vehicles and infrastructure without considering the proposed 802.11p standard. The authors assume a multitude of APs to be present at the same time, operating on different frequency channels. Their solution, to limit the number of scanned channels to achieve a reduction in handover delay, is not applicable to our case where only one channel for control data is available, independent of the number of available RSUs.

6. Performance Evaluation

The merge assistance scenario (see Section 3) figures as a use case, providing realistic data for the analytical and simulation-based evaluations of our framework. Other scenarios, where the framework can be used in a similar way are, for example particularly accident-prone road sections with static RSUs or road work or accident sites with semi-static RSUs (e.g., a police car taking the role of a temporary RSU).

6.1. Performance Evaluation: Position-Based Real-Time MAC

The proposed protocol was evaluated analytically based on a set of RT channels derived from a MATLAB simulation of the merge assistance scenario. Table 5 gives the full list of parameter values the evaluation is based upon.

Table 5: List of simulation parameters.

Figure 12 shows the analytical results for the case without priority zones and thus constitutes a baseline for comparison with our novel, position-based priority scheme. In Figure 12, the percentage of the bandwidth used for the CBP can be seen as a function of the number of vehicles within transmission range of the RSU. Note that a CBP of this length implies that all safety-critical real-time data packets are accommodated without any deadline misses. Results for bit rates of 6, 12, and 24 Mbit/s are shown, approximately spanning over the achievable bit rates for 802.11p. We assume that a minimum reserved bandwidth of 20% is needed for the CBP, which is indicated by the bold line in the figure. With a CFP/CBP-ratio of 80/20, 82 vehicles can be accommodated at a bit rate of 6 Mbit/s, 160 vehicles at a bit rate of 12 Mbit/s, and 292 vehicles at a bit rate of 24 Mbit/s.

Figure 12: Fraction of bandwidth left for CBP for various numbers of accepted vehicles. No position-based priorities are used.

In Figures 13 and 14, we introduce position-based prioritization zones and vehicle mobility. In order to determine the amount of bandwidth required for real-time data traffic (i.e., the CFP), a schedulability test for a certain set of vehicles needs to be conducted. Figures 13 and 14 show the results of an average of 1000 schedulability tests for a specific number of vehicles. The task set is found through Matlab simulations according to the following. A constant speed (between 100 and 150 km/h) and an initial position (within the transmission range of the RSU) are randomly determined for each vehicle. Each time instance a schedulability test is required, each vehicle’s position is updated according to its speed. Period and deadline are set depending on the priority zone this updated position belongs to. The radius of a priority zone is defined by , where denotes the transmission radius of the RSU and denotes the priority (where , with as the total number of zones, 1 as the lowest and as the highest priority zone). In other words, we assume that the most hazardous zone lies in the center of the RSU’s transmission range. Period and deadline of vehicle heartbeat packets range from 50 to 1000 ms depending on the number of priority zones. Period and deadline of RSU recommendations as well as the deadline of road information updates correspond to the parameters of merge heartbeats in the zone with highest priority. The period of road information data, on the other hand, corresponds to the period of merge heartbeats in the lowest priority zone. The propagation delay of 0.01 ms includes delays at the sender and receiver. A new vehicle is introduced whenever another one leaves the transmission range, in order to keep the total number of vehicles at a constant value.

Figure 13: Fraction of bandwidth left for CBP using 3 priority zones with period 50, 100, and 1000 ms.
Figure 14: Fraction of bandwidth left for CBP for various numbers of priority zones and a bandwidth of 6 Mbps.

In Figure 13, three priority classes, zones, are introduced. The periods are set to 50, 100, and 1000 ms, respectively. With this particular choice of periods, the message update frequency in the zone with highest priority is doubled compared to the single zone case (Figure 12). With 80 vehicles within the RSU transmission range (which can be considered dense traffic even on a highway) approximately 20% of the bandwidth would be left for best-effort traffic at 6 Mbit/s, 42% at 12 Mbit/s and 57% at 24 Mbit/s. Due to the fact that the deadline is set equal to the period, real-time communication within the area of hazard (the zone with highest priority) is not only taking place more frequently, but is even guaranteed to always take priority over the remaining zones and data traffic classes. Note also the slight increase in accepted vehicles as compared to Figure 12.

The effects of introducing several priority zones can be seen in Figure 14, with results for one, three, and five priority zones. For one zone, the period is 100 ms, for three zones, the periods are 100, 300, and 1000 ms and for five zones, they are 100, 200, 300, 600, and 1000 ms. A higher number of zones offers an increased flexibility to adjust the message update frequency to the actual road and traffic conditions at the specific road site. In Figure 14, the use of five priority zones frees 70% of the total bandwidth for best-effort services, while still guaranteeing real-time support for 80 vehicles inside the RSU’s transmission range, that is for a highway scenario with dense traffic. The savings in resources due to lower update frequencies in low-priority zones can be used in various ways. Increasing communication in hazardous areas is one option, supporting a larger amount of vehicles in the network, another. Alternatively, the threshold for the minimum amount of best-effort traffic in the network can be increased.

6.2. Performance Evaluation: Proactive Handover

We can now determine how many vehicles can still be supported in the RSU’s schedule when a maximum of 10% of the superframe is dedicated to proactive polling. Figure 15 shows the results for bit rates of 6, 12, and 24 Mbit/s when applying position-based priorities with three priority zones. A minimum of 20% of a superframe is reserved for best-effort traffic in the CBP, while a maximum of 10% is used for the proactive polling introduced above. The figure shows that, even at low bit rates, we can guarantee the support of 80 vehicles in the collision-free MAC phase used for delay-sensitive real-time data traffic. We assume that an RSU covers about 800 m of road (our field measurements [7] with WAVE-enabled prototype equipment confirm this number), and even for a 3-lane highway with bidirectional traffic, this means that dense road traffic can be supported (with a distance of approximately 50 m between vehicles in the same lane). For bit rates of 12 and 24 Mbit/s, the number of supported vehicles increases to 150 and 280, respectively.

Figure 15: Number of vehicles supported for various bit rates under the assumption of a 20% CBP and a 10% proactive polling phase (PPP).

7. Conclusion

We have presented a framework for safety-critical V2I communication, complementing the upcoming IEEE 802.11p standard with support for real-time data traffic with position-based priorities. Furthermore, we targeted fast connection setup and handover between vehicles and RSUs.

In our proposed MAC method, guarantees for the timely delivery of safety-critical data are given. Additionally, the position-based priorities ensure a decrease of the period and deadline of data packets to and from vehicles close to a zone of hazard. Communication resources are thereby focused on areas where they are most needed and the response time of proactive safety applications (and thereby ultimately even the reaction time of the driver) to critical situations is improved. Real-time schedulability analysis is used to minimize the bandwidth reserved for safety-critical data traffic while still guaranteeing timely delivery. Further, the remaining bandwidth can be used for various best effort services (infrastructure-based services or ongoing V2V applications), thereby reducing the interference on the safety-critical V2I applications to a minimum.

Safety critical services require a deterministic and fast mechanism to associate a vehicle to an RSU and integrate the vehicle into the centralized polling schedule. We propose and analyze a random access-based connection setup mechanism during the contention-based phase of an 802.11p superframe. As packet collisions are possible, this mechanism itself does not offer a guaranteed delay bound for connection setup, and we, therefore, propose further improvement by proactively forwarding information about approaching vehicles to the next RSU along the road. Thus, vehicles are already part of the communication schedule even before they enter the next RSU’s transmission range, thereby providing an upper bound on the connection setup (or handover) delay.

The evaluation shows that the proposed framework is suitable for the bit rates supported by the 802.11p standard and the road traffic capacity expected from a 2–4 lane highway. The number of priority zones, their respective period, and the threshold for reserved bandwidth for best-effort services can be fine-tuned to fit the conditions of the individual road. Thereby, our solution provides the flexibility to for example adjust the number of supported vehicles, the reactiveness of certain ITS safety applications, or the amount of possible best-effort data traffic in the network. An analysis of this proactive handover mechanism is provided, showing that, even for dense road traffic, the bandwidth requirements to support our proactive handover solution do not compromise our previously proposed system design for infrastructure-based ITS safety applications.


AIFS:Arbitrary interframe spacing
AP:Accsess point
BP:Busy period
CAM:Cooperative awareness message
CBP:Contention-based phase
CSMA:Carrier sense multiple access
CSMA/CA:CSMA with collision avoidance
CSR:Connection setup request
CW:Contention window
DENM:Decentralized environmental notification message
EDCA:Enhanced distributed channel access
EDF:Earliest deadline first
FDMA:Frequency division multiple access
IFS:Interframe spacing
ITS:Intelligent transport systems
LDM:Local dynamic map
MAC:Medium access control
MN:Mobile node
PPP:Proactive polling phase
QoS:Quality of service
RSU:Road side unit
RT channel:Real-time channel
SIFS:Short interframe spacing
TDMA:Time division multiple access
WAVE:Wireless access for vehicular environments
WBSS:WAVE basic service set
WLAN:Wireless local area network
WSA:Wave service announcement.


This paper was funded by the Swedish Transport Administration (Trafikverket) and the KK-foundation in participation with Volvo Technology Corp.


  1. “Task Group p. IEEE 802.11p: Wireless Access in Vehicular Environments (WAVE),” Draft Standard, IEEE Computer Society, 2007.
  2. K. Bilstrup, E. Uhlemann, E. G. Ström, and U. Bilstrup, “Evaluation of the IEEE 802.11p MAC method for vehicle-to-vehicle communication,” in Proceedings of the 68th Semi-Annual IEEE of the Vehicular Technology Conference (VTC '08), pp. 1–5, Calgary, Canada, September 2008.
  3. S. Eichler, “Performance evaluation of the IEEE 802.11p WAVE communication standard,” in Proceedings of the 66th IEEE of the Vehicular Technology Conference (VTC '07), pp. 2199–2203, Baltimore, Md, USA, October 2007. View at Publisher · View at Google Scholar · View at Scopus
  4. T. Kosch et al., “European ITS Communications Architecture,” COMeSafety deliverable D31, version 2.0, October 2008,
  5. A. Böhm and M. Jonsson, “Supporting real-time data traffic in safety-critical, vehicle-to-infrastructure communication,” in Proceedings of the 33rd Annual IEEE Conference on Local Computer Networks (LCN '08), pp. 614–621, Montreal, Canada, October 2008.
  6. A. Böhm and M. Jonsson, “Position-based data traffic prioritization in safety-critical vehicle-to-infrastructure communication,” in Proceedings of the IEEE ICC Vehicular Networks & Applications Workshop, Dresden, Germany, June 2009.
  7. A. Böhm, K. Lidström, M. Jonsson, and T. Larsson, “Evaluating CALM M5-based vehicle-to-vehicle communication in various road settings through field trials,” in Proceedings of the 35th IEEE Conference on Local Computer Networks (LCN '10), pp. 613–620, Denver, Colo, USA, October 2010.
  8. A. P. Schalk, W. Rom, and H. Stratil, “The vision of ISO-CALM—a globally connected ITS world,” Elektrotechnik und Informationstechnik, vol. 124, no. 4, pp. a19–a23, 2007. View at Publisher · View at Google Scholar · View at Scopus
  9. Std. 802.11, part 11: Wireless LAN Medium Access Control (MAC) and Physical layer (PHY) specifications: Amendment 8: Medium Access Control (MAC) Quality of Service Enhancements, IEEE Computer Society, 1999.
  10. Std. 802.11e-2005, part 11: Wireless LAN Medium Access Control (MAC) and Physical layer (PHY) specifications, 2005.
  11. M. Jonsson and K. Kunert, “Towards reliable wireless industrial communication with real-time guarantees,” IEEE Transactions on Industrial Informatics, vol. 5, no. 4, pp. 429–442, 2009. View at Publisher · View at Google Scholar · View at Scopus
  12. M. Spuri, “Analysis of deadline scheduled real-time systems,” Tech. Rep. 2772, Institute National de Recherche en Informatique et en Automatique (INRIA), Paris, France, 1996. View at Google Scholar
  13. J. A. Stankovic, M. Spuri, K. Ramamritham, and G. C. Buttazzo, Deadline Scheduling for Real-Time Systems—EDF and Related Algorithms, Kluwer Academic, Boston, Mass, USA, 1998.
  14. C. L. Liu and J. W. Layland, “Scheduling algorithms for multiprogramming in a hard-real-time environment,” Journal of the ACM, vol. 20, no. 1, pp. 46–61, 1973. View at Google Scholar
  15. T. K. Mak, K. P. Laberteaux, and R. Sengupta, “A multi-channel VANET providing concurrent safety and commercial services,” in Proceedings of the 2nd ACM International Workshop on Vehicular Ad Hoc Networks (VANET '05), pp. 1–9, New York, NY, USA, September 2005. View at Scopus
  16. C. Suthaputchakun and A. Ganz, “Priority-based inter-vehicle communication in vehicular ad-hoc networks using IEEE 802.11e,” in Proceedings of 65th IEEE of the Vehicular Technology Conference (VTC '07), pp. 2595–2599, Dublin, Ireland, April 2007.
  17. S. Katragadda et al., “A decentralized location-based channel access protocol for inter-vehicle communication,” in Proceedings of 57th IEEE of the Vehicular Technology Conference (VTC '03), pp. 1831–1835, Seoul, Korea, April 2003.
  18. R. Koodli, Ed., “Fast Handovers for Mobile IPv6,” RFC 4068, 2005.
  19. G. Anastasi, E. Borgia, M. Conti, and E. Gregori, “IEEE 802.11 ad hoc networks: performance measurements,” in Proceedings of the 23rd International Conference on Distributed Computing Systems Workshops (ICDCSW '03), pp. 758–763, May 2003.
  20. J. Montavont, N. Montavont, and T. Noel, “Enhanced schemes for L2 handover in IEEE 802.11 networks and their evaluations,” in Proceedings of 16th IEEE of the International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC '05), vol. 3, pp. 1429–1433, Berlin, Germany, Septemper 2005.
  21. C. C. Tseng, K. H. Chi, M. D. Hsieh, and H. H. Chang, “Location-based fast handoff for 802.11 networks,” IEEE Communications Letters, vol. 9, no. 4, pp. 304–306, 2005. View at Publisher · View at Google Scholar · View at Scopus
  22. J. Montavont and T. Noel, “IEEE 802.11 handovers assisted by GPS information,” in Proceedings of the IEEE International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob '06), pp. 166–172, Québec, Canada, June 2006. View at Publisher · View at Google Scholar · View at Scopus
  23. E. K. Paik and Y. Choi, “Prediction-based fast handoff for mobile WLANs,” in Proceedings of the 10th IEEE International Conference on Telecommunications (ICT '03), vol. 1, pp. 748–753, Tahiti, February 2003.
  24. A. Shimizu, S. Fukuzawa, T. Osafune, M. Hayashi, and S. Matsui, “Enhanced functions of 802.11 protocol for adaptation to communications between high speed vehicles and infrastructures,” in Proceedings of the 7th International Conference on Intelligent Transport Systems Telecommunications (ITST '07), pp. 1–3, Seattle, Wash, USA, October 2007. View at Publisher · View at Google Scholar · View at Scopus