Mobile Networks and Applications

, Volume 18, Issue 6, pp 814–830 | Cite as

A Multichannel QoS MAC with Dynamic Transmit Opportunity for VANets

  • Hikmat El Ajaltouni
  • Azzedine Boukerche
  • Abdelhamid Mammeri


One of the most challenging issues facing vehicular networks lies in the design of an efficient MAC protocol due to the mobile nature of nodes and the interference associated with the dynamic environment. Moreover delay constraints for safety applications add complexity and latency requirements to the design. Existing MAC protocols overcome some challenges however don’t provide an integrated solution. Hence, the merit if this work lies in designing an efficient MAC protocol that incorporates various VANet’s challenges in a complete end-to-end solution. In this work, we propose an efficient Multichannel QoS Cognitive MAC (MQOG). MQOG assesses the quality of channel prior to transmission employing dynamic channel allocation and negotiation algorithms to achieve significant increase in channel reliability, throughput and delay constraints while simultaneously addressing Quality of Service. The uniqueness of MQOG lies in making use of the free unlicensed bands. The proposed protocols were implemented in OMNET++ 4.1, and extensive experiments demonstrated a faster and more efficient reception of safety messages compared to existing VANet MAC Protocols. Finally, improvements in delay, packet delivery ratios and throughput were captured.


MAC Multichannel VANets TXOP IEEE 802.11p 

1 Introduction

A MAC protocol for VANets should be designed for both urban and suburban environments. Since each environment has its own characteristics, the medium contention in congested environments (downtown of urban cities) is much more demanding than suburban ones. Therefore the MAC protocol should easily adapt to different traffic conditions.

Moreover, high mobility imposes high multipath environment with dynamic delay spread due to multiple reflections, scattering, diffraction and refraction. Therefore there exists a need in vehicular environments to assess the channel dynamically before initiating transmission because many cars are competing for a limited spectrum resource in a network that is suffering frequent connections and disconnections.

On the other hand, there exists an imposed latency requirement for QoS applications and services. Data transmitted over VANets can be classified as Safety or NonSafety with different considerations. QoS applications can be time-sensitive and latency-nontolerant and they range from Safety (collision warning), Realtime(video and audio) and NonRealtime (email, web surfing) applications. Safety messages must be sent within a certain upper threshold know as delay bound otherwise they reach their target late and are considered useless. An efficient medium access methodology ensures the prioritization of transmission by granting safety messages the highest priority to access the medium. Table 1 shows different applications with different delay bound requirements [1].

Table 1

Examples of DSRC applications and requirements [1]


Latency (ms)


Collision Avoidance



Emergency Braking Avoidance



Cooperative Collision Warning



Toll Collection



Service Announcements



Finally, a fair MAC protocol should consider the different vehicular speeds before and during the contention process. Thus a car moving with high speed should be able to contend faster and maintain its connection longer than a car moving with low speed.

2 Related work

In the following section, we will start our discussion by highlighting the single radio single channel architecture solutions [2, 12] then move to the single radio multichannel solutions [13, 15] and finally to the multiradio multichannel solutions [16, 17].

2.1 Single radio single channel solutions

The different MAC protocols for Vehicular Ad Hoc Networks were widely investigated in the literature [2, 17]. MAC protocols vary depending on the different MAC architecture used. We will start our discussion with single radio single channel solutions. The following are divided into space division multiple access, repetition based MAC and Adhoc MAC.

SDMA assigns channel access based on location information. Geographical areas are divided into smaller divisions based on real time position information. Each spatial region is allocated a unique channel and vehicles obtain information about channels using GPS coordinates. SDMA could work with multiple access schemes like TDMA, CDMA and FDMA for bandwidth sharing. SDMA aims to reduce access collisions, increase channel reusability and address issues likes hidden-node and fairness.

Applications of SDMA for VANets were proposed in [2, 3]. In [4], authors presented the Location Division Multiple Access (LDMA) protocol. LDMA assigns grid resolution and divides a geographical map into a hierarchy of spatial regions where cell sizes are based on geographic locations (urban, suburban and rural). For example, geographic locations with higher traffic density are assigned a higher grid resolution with a smaller cell size. LDMA uses GPS for location information and proposes the use of low cost, low rate FM-based Radio Data Broadcast System (RDBS) for distribution of spatial slot distribution and temporal schedule assignments. In case where there are multiple vehicles in the same cell, LDMA ensures that only one vehicle forwards the message by implementing small jitter duration (500 us) in the beginning of each time slot. Authors demonstrate that LDMA offers smallest end-to-end delay with moderate message receive rates when they compare it with other rebroadcast schemes.

As LDMA suffer from bandwidth wastage in case of empty cells, the concept of buffer was presented in [5]. Authors in [5] developed Adaptive Space Division Multiplexing (ASDM) technique that allows vehicles to transmit using time slot of empty cells as they adopt time slot assignments and lead vehicles up to the limit defined by ASDM buffer.

Another technique that uses SDMA with CDMA was proposed in [6]. The authors proposed a position based PN code assignment scheme to alleviate the problem of PN code assignment. Their scheme exploits the location awareness for efficient PN code allocation. Roads are divided into small segments or areas and a small number of PN codes are allocated to each segment or area. According to the scheme, vehicles use a multi MCS scheme to sense availability of PN code. The main advantage of this scheme is avoidance of PN code conflict as selection of code is based on location information.

SDMA has emerged as very promising technique. However, there are still practical challenges allied with SDMA technique, which necessitate further research. Main Issues involved in SDMA based MAC design are cell size, channel reuse-distance, accuracy of position acquisition systems, redistribution of schedule and division border effect [3, 7].

ADHOCMAC [8], developed under the CarTalk2000 project to support inter-vehicular communications [9], is a MAC protocol that was proposed to achieve a distributed TDMA function without any centralized coordinator. Mainly, ADHOCMAC is based on Reliable R-ALOHA (RR-ALOHA) which is a MAC scheme capable of coordinating access in a distributed mode. The main advantage of ADHOCMAC is that it can be adapted to work with 802.11 physical layer by modifying its frame structure. As ADHOCMAC uses a dynamic TDMA mechanism, independent from the physical layer, it can coordinate access of ad hoc nodes by allocating dynamic time slots for the next packet transmissions. The protocol is supposed to mainly solve the hidden and exposed node problems and provide a reliable single hop broadcast service.

In [10, 11], several issues regarding ADHOC MAC are discussed. First, in a static scenario the minimum time needed to successfully obtain the basic channel is greater than 200 ms. Secondly, mobility and dense traffic may cause more latency in allocating and releasing slots. Thirdly, the number of vehicles in the same communication range must not exceed the number of slots otherwise there will not be enough slots for vehicles to transmit. In comparison with the IEEE 802.11, ADHOC MAC is not utilizing the medium efficiently. Further information about ADHOC MAC performance can be found in [12].

Since the nature of vehicular communication imposes a distributed architecture where there isn’t any centralized controller managing transmissions, multichannel solutions were shown to be more suitable for VANets than single channel protocols [13, 17]. This is due to the fact that multichannel solutions ensure intelligent control and coordination between vehicles on a particular channel.

2.2 Single radio multichannel solution

IEEE ratified 802.11p in 2010 as WAVE Amendment (Wireless Access in Vehicular Environments) defining the PHY and MAC layer for VANets operating in 5.9 GHz Band. IEEE 802.11p divided DSRC into seven 10 MHz channels, composed of one control channel (CCH) which is assigned for broadcast and control messaging and six service channels (SCHs) for ongoing data transactions. IEEE1609.4 defines the multichannel operation of 802.11p where all devices participating should monitor the CCH where high priority control and safety messages are transmitted in that interval. Moreover, the downside of using 802.11p/IEEE1609.4 is the overhead on the control channel because of control and broadcasting messages and thus the medium contention delay increases. In addition, time synchronization in multichannel operation between vehicles is hard to achieve in high multipath environments [13, 14].

In [15], authors propose VMESH, an extension to IEEE 802.11p with Multichannel operation. VMESH uses a contention based access method for control channel and a contention free (TDMA) access method for service channels in parallel with 802.11p multichannel operation. VMESH encompasses a superframe on top of wave synchronization interval, which contains multiple synchronization intervals. The downside of VMESH is that it doesn’t ensure QoS neither between safety and nonsafety messaging nor between real time and non real time messaging. Moreover, using TDMA would limit the number of vehicles to the number of available slots. Finally time synchronization is also hard to maintain as vehicular environments impose a high multipath and dynamic nature.

2.3 Multiradio multichannel solution

In [16] Su and Zhang propose a clustering-based multichannel MAC that uses contention-free and contention-based MAC protocols. Cars can be grouped together in a cluster and by using an election protocol, a cluster head is elected while others are considered cluster members. Su and Zhang define the use of TDMA for cluster members while cluster heads use 802.11p CSMA/CA to contend for the medium on a different frequency. Each vehicle has two transceivers operating simultaneously. The disadvantage of this protocol lies in the overhead due to the election process. Moreover two clusters operating on the same frequency create Co-Channel Interference leading to degradation in performance. Synchronization is also an issue in this protocol when using TDMA in high multipath environments.

In [17], the authors define DCA for MANets (mobile ad hoc networks) based on dynamic channel assignment. DCA utilizes two transceivers; one always operates on a dedicated control channel while the other can be switched to any data channels in an on-demand manner. The downside of DCA is that below a saturation point (dependent on number of available channels) it can offer more throughput than others however when it reaches the saturation point, performance degrades. Moreover, as it is not designed for VANets, it doesn’t consider QoS and mobility. Modification must be made to ensure a tailored version of this protocol for VANets.

Since our work proposes a new Multichannel QoS Cognitive MAC, we conclude the related work section by outlining the differences between our work and others. First, contrary to many QoS MAC protocols, our proposed protocol grants priority of sending safety messages and in case of having contention on the medium, the protocol makes use of the ISM or UNII-3 band by requesting to handoff a nonsafe data channel to an unlicensed free band. Secondly, our proposed protocol considers interference on a channel (Adjacent and Co-Channel Interference) as this might be a major obstacle in VANet environments. Finally, our proposed protocol uses two transceivers; a transceiver dedicated for control and intelligence while other for data transmission in frame bursts without any medium contention. This combination demonstrated that the proposed protocol improves throughput and channel reliability in vehicular scenarios.We conclude the related work section by outlining the differences between the different VANet MAC protocols. To compare MAC protocols, certain criteria must be considered. Although in this case, we are comparing different MAC protocols qualitatively, the issues each protocol solved are emphasized, and the limitations are pointed out and they are all presented in Table 2.
Table 2

Comparison of different MAC protocols









Multiple Access








Reduce Collisions








Increase Channel
















Time Synchronization








Use Backoff Mechanism








Handles Hidden Node








Ensure QoS
















Fault Tolerance








3 Proposed multichannel QOS cognitive MAC for VANets (MQOG)

In this section, we present our proposed Cognitive Multichannel MAC (MQOG) in details. We first outline the design guidelines behind our work and we then address the system architecture. The core protocols of the proposed MAC are then explained: The dynamic channel allocation protocol and the dynamic negotiation protocol. Following that, we propose a MAC enhancement scheme for our already proposed MQOG protocol. The new enhancement scheme is MoByToP (Mobility-Based Dynamic Transmit Opportunity) added to the medium reservation phase. MoByToP modes of operation and different parameters are then presented in details preceded by the limitations of MQOG and the motivation behind adding MoByToP.

3.1 System design

After examining the different related work, the points that should be addressed in the efficient design of our proposed MAC protocol are the following:
  1. 1.

    The MAC protocol designed should be able to prioritize safety messages on behalf of nonsafe messages. Moreover, not only should it prioritize safe messaging but also ensure their reliable transmission in case of facing contention on the medium. A dynamic solution should be available in case the medium is congested. Otherwise life-critical messages will miss their target.

  2. 2.

    As vehicular networks are of ad hoc nature, each vehicle should have enough knowledge and intelligence of its surroundings. The MAC protocol employed should be fault tolerant with respect to any topology changes. Any topological change should be accounted for directly. For example, if a vehicle is relying on an intermediate node to deliver a packet to the final destination and this node moves out of the network then it should be able to get notified directly.

  3. 3.

    As vehicular networks struggle from congestion in urban environments, it would result in an unstable, time-varying wireless channel. The MAC protocol designed should be able to assess the channel prior to transmission. Channel assessment for interference (Adjacent and Co-Channel Interference) would alleviate L2 packet retransmissions in high multipath environments with dynamic delay spreads.


Those needs urged us to design a cognitive Multichannel MAC for VANets able to address those issues as well as to achieve better MAC performance with respect to existing VANet MAC protocols.

3.2 Cognitive radios and unlicensed bands: approach

The FCC has allocated in 1999 the DSRC band for vehicular communications [18]. As shown in Fig. 1, directly before the DSRC band there exist the ISM and UNII-3 bands. Those bands are both unlicensed and free to use by any user except that the user must abide by the Channel Transmit Power (CTP) and Bandwidth Requirements set by the local regulatory entity in his country (FCC in the United States; IC in Canada; ETSI in Europe). In general, the 5.8 GHz ISM and UNII-3 are both used for outdoor communications with transmit power suitable for vehicular communications. Since those bands are free for use, the downside of using them is sharing the frequencies with too many other users (WLAN or other wireless technologies) leading to high level of interference.
Fig. 1

ISM and UNII-3 Band directly before DSRC Band

In our proposed protocol, we will use cognitive radios to transmit nonsafe data bursts in case all DSRC channels are occupied while we assess the channel before transmitting. Moreover, non safe data will handoff to an ISM or UNII-3 band in case a safety message has to be sent and the channel assessment didn’t find any suitable channel on the DSRC band. Details of the proposed protocol are presented in the next sections.

3.3 Overall system architecture

MQOG uses multichannel operation with a unique dedicated control channel and multiple service channels for data transfer. The Dynamic Channel Allocation Protocol (refer to Section 3.1) ensures that each transmitter searches for the best available channel by assessing the noise and interference level on the DSRC, ISM, and UNII-3 bands. This protocol also considers the QoS of messages to be sent as it prioritizes frames based on safety or nonsafety applications.

In our proposed protocol, we separate the control from the actual data transmission. The underlying communication and intelligence lies on the control channel to dedicate a service channel for data transfer. All vehicles track the communication between neighboring vehicles using the Channel Neighbor State Table (CNST). This table shows the transmissions of all neighboring vehicles in the range and hence a car while monitoring the control channel has enough intelligence to be aware of all transmissions occurring next to it.

The second protocol is the Channel Negotiation Protocol (refer to Section 3.2) that describes the handshaking process on the control channel and the flow of messages within different unicast, multicast and broadcast scenarios.

3.4 MAC radio architecture

Vehicles are equipped with two transceivers working simultaneously. The first transceiver is connected to an omnidirectional antenna configured on channel 178 and serves as a dedicated control channel. Vehicles in the same range listen and transmit control data on this channel and any change in the vehicle network topology is directly sent to inform neighboring vehicles to update their CNST. Vehicle’s contention for this channel is based on CSMA/CA as defined by IEEE802.11p standard. However unlike the IEEE standard, only control frames are sent on this channel ensuring short messaging (50B) and short medium reservation. Beacons (Vehicle ID, Speed, and Position) and control frames for frequency selection (Adjusted RTS and CTS) are only sent on the dedicated control channel.

The second transceiver is a cognitive radio capable of hopping and adjusting between different frequencies ranging from the ISM and UNII-3 band up to DSRC band (5.725 GHz - 5. 925 GHz). The cognitive radio is solely used for transmitting and receiving data. Moreover when neither transmitting nor receiving data, the cognitive radio senses the ISM and UNII-3 band for noise and interference levels on each particular channel and selects the best channel to transmit on. There isn’t any medium contention on this channel (contention-free) as the other transceiver (control channel) would reserve a particular service channel and announce it to all neighboring vehicles. By updating the vehicle’s CNST, collisions between vehicles are avoided and no two vehicles are transmitting and receiving at the same time on same channel within the same range. In brief, the intelligence and medium contention lies on the control channel with short messages preserving the channel from contention while the actual data sending (large frames) is done in frame bursts on the service channels based on the QoS Access Category.

3.5 Supported frames and datastructure

MQOG requires the use of special control frames to help in the negotiation process between vehicles and to ensure the collision -free transfer of information. Those are the only frames sent on the dedicated control channel and characterized by being short messages (50B). They are responsible for establishing the communication link between the transmitter and receiver for the actual data transmission on the service channel.
  • Beacon Management: (Fig. 2a) Periodically sent by each vehicle to the neighboring vehicles within the range and it conveys the Vehicle ID, Velocity and Position.

  • Adjusted-RTS: (Fig. 2b) It is sent at the beginning when a vehicle requests to send any new data (safety or nonsafety). This frame replaces the known RTS frame by adding channel selection parameters which shows the assessed channels for transmission. Moreover, it has a unique QoS Access Category Level to prioritize data.

  • Adjusted-CTS: (Fig. 2c) It is the reply to the transmitter’s request to send. This is analogous to the known CTS packet with the differences of adding a selected channel which would be the agreed channel between transmitter and receiver for best channel conditions for transmission and the QoS Access Category Level.

  • Request-to-Handoff: (Fig. 2d) It is a new Control Frame. This frame is triggered once a frame with high priority is required to be sent (example safety message) while all other channels are occupied by lower priority transmissions. The request to handoff selects the channel occupied with lowest priority and sends a request to the transmitting vehicle to handoff to another ISM or UNII-3 channel since this channel would be reserved for the incoming more prior transmission.

  • Handoff-to-ISM or UNII-3: (Fig. 2e) It is also a new Control Frame. This frame is sent from the transmitter in an ongoing communication to the receiver on the dedicated control channel. This informs the receiver to switch to the following ISM or UNII-3 band as the channel being used would be granted to a more prior transmission.

  • ACK: (Fig. 2f) Sent in response to the Request-to-Handoff frame to inform the vehicle that the request was received and the other vehicle is initiating with the handoff process.

Fig. 2

Control frames used on dedicated control channel

Channel Neighbor State Table (CNST)

As shown in Fig. 3, CNST stores the ongoing neighboring communications between neighboring vehicles in every vehicle in its database. Neighboring vehicles continuously update their channel transmission by sending control frames on the dedicated control channel. CNST stores the following information for every ongoing transmission:
  • Frequency Channel: The frequency channel being used by the corresponding communication link.

  • AC Priority Level: The Access Category of the data being sent on that channel highlighting the QoS and the nature of transmission as unicast or multicast/broadcast.

  • Duration Value: The duration of the ongoing transmission and it is a countdown timer.

  • Reserved: This field shows the Vehicle ID reserving the channel either for handoff or for an incoming transmission. For handoff purposes, this is triggered when the Request-to-Handoff control frame is sent reserving the channel for a more prior communication ensuring a First Come First Serve (FCFS) basis.

Fig. 3

Channel Neighbor State Table (CNST)

Quality of service

In our proposed protocol we define 6 access categories rising from the different Vehicular QoS needs. The Access Categories are shown in Table 3 ranging from lowest to highest priority and are divided into 3 main categories: safety, nonsafety realtime, and nonsafety non realtime. Examples are also presented to show the different applications involved in a vehicular scenario.
Table 3

QoS different category levels

Access categories



NonSafety Non Real Time (Unicast)


Web Surfing/Sending Emails

NonSafety Non Real Time (Broadcast/Multicast)


Downloading EMaps from RSU

NonSafety Real Time (Unicast)


Voice Conversation

NonSafety Real Time (Broadcast/Multicast)


Video/Voice Conference

Safety (Unicast)


Lane Change or Wrong Way Warning



Warning Messages (Accident, Icy


Road, Oil Stain, Sudden Breaking...)

3.6 Overall system operation

As shown in Fig. 4, the vehicle can operate in three different modes. In the idle mode, the control channel exchanges control info and updates the CNST Table while the cognitive radio senses unlicensed and licensed bands for channels for reliable transmission. By updating the vehicle’s CNST, collisions between vehicles are avoided and no two vehicles are transmitting and receiving at the same time on same channel within the same range. In the pre-transmission mode, the channel negogiation occurs on the control channel while the dynamic channel allocation algorithm occurs on the cognitive radio. Finally, during the transmission mode, the cognitive radio sends the data on the selected channel while the control channel keeps on exchanging control frames and updating the CNST Table.
Fig. 4

Proposed protocol’s modes of operation

4 Protocols behind MQOG

In this section, we will explain in details the core protocols behind the operation of MQOG which are: Dynamic Channel Allocation Protocol and the Channel Negotiation Protocol.

4.1 Dynamic channel allocation protocol

The Dynamic Channel Allocation Algorithm selects the best available channel with low interference and noise levels. The flowchart is shown in Fig. 5 and it works as follows:
Fig. 5

Dynamic channel allocation protocol flowchart

If the Cognitive Radio Assessment reveals an available DSRC channel with optimum conditions then it is directly selected for the incoming transmission. However, if all available DSRC channels are being used by neighboring vehicles then an assessment for the level of noise and interference on each channel is made. If at least one channel is above the threshold then this channel is selected and checked by comparing it with the CNST. This channel is then reserved by the vehicle for the upcoming transmission.In our simulations, we set the threshold s to 0.5 considering 1 as clear channel assessment. This threshold is the RSSI (Received Signal Strength Indicator) which is proven to be suitable for wireless networks as it has also been used in Air Magnet Site Surveying tool accredited within most industries [19]. As shown in Table 4, the RSSI of a selected channel should be greater or equal than 15. This number indicates that the channel has a Signal to Noise Ratio (SNR) above 33 dB and a strong signal strength.
Table 4

Channel assessment properties [20]


Rx Sensitivity

Signal Strength


Sign. Quality


-30 dBm


70 dB



-41 dBm


60 dB



-52 dBm


43 dB



-52 dBm


40 dB



-63 dBm


33 dB



-75 dBm


25 dB



-89 dBm


10 dB



-110 dBm


0 dB


If all channels suffer from high interference and noise levels then the QoS of the message to be sent is investigated:

If the message to be sent is safety then CNST is checked to assess if all occupied channels belong to safety transmissions. If this is the case, then the vehicle has to wait for the end of the first transmission. If neighboring vehicles are transmitting non safe data then the vehicle sends a request to handoff and safety transmission would replace nonsafe transmission on the DSRC channel while nonsafe transmission are handed off to an ISM or UNII-3 Channel.

If the frames to be sent are non safe messages then transmission can occur on the ISM or UNII-3 since it is not a critical message. Unlicensed Channels are checked for theinterference and noise levels and once a channel with good conditions is assessed, it is then directly selected for transmission. Before initiating transmission, adjusting Transmit Power (TP) is necessary to ensure the abidance to RF regulations of the local regulatory entity. If all ISM/UNII-3 bands were suffering from high interference levels then after checking CNST the vehicle reserves the channel the first to be vacant.

In general, the Dynamic Channel Allocation protocol is granting Safety Messages priority to secure optimal channels with quality conditions based on RSSI values. Safety messages (Warning messages) or lane change are given the highest priority to transmit whereas Nonsafety messages (voice, video streaming, web surfing and sending emails) are all granted less priority and may be moved to non-licensed bands in some cases.

4.2 Channel negotiation algorithm

In this section, we discuss the channel negotiation protocol within different communication scenarios (unicast and multicast/broadcast) to ensure the correct transmission sequence of control frames to establish the communication link between the transmitter and receiver(s). Considering a unicast transmission, a vehicle after running the dynamic channel algorithm protocol is left with two cases either an available DSRC Channel or High level of Interference on DSRC so switching to an ISM or UNII-3 channel. For the former, the negotiating protocol on the dedicated control channel is done by the following steps:
  1. 1.

    Transmitter sends an Adjusted-RTS with the selected list of frequencies to the receiver

  2. 2.

    Receiver replies with an Adjusted-CTS with an agreed upon channel.

  3. 3.

    Transmitter sends again the same CTS as a CTS-to-Self Frame for all neighboring vehicles to solve the hidden node problem.

  4. 4.

    Neighboring vehicles update their CNST and record the transmission on the allocated channel with the countdown duration defined.

  5. 5.

    Transmission of data occurs on the second transceiver after both transceivers tune to same frequency.

Regarding the case of switching to an ISM or UNII-3 band, the negotiating protocol on the dedicated control channel is done by the following steps:
  1. 1.

    Transmitter checks CNST for all transmissions on all channels and selects the lowest priority channel (NonSafety Only).

  2. 2.

    Transmitter sends a Request-to-Handoff for the transmitting vehicle on the channel to replace it with its incoming transmission as it is more prior.

  3. 3.

    All neighboring vehicles first update their CNST by filling the Request-to-Handoff-Field to reserve the channel for this particular transmission.

  4. 4.

    Receiver replies with Handoff-to-ISM frame to switch its communication link to the ISM or UNII-3 band then sends another ACK to the transmitter.

  5. 5.

    Transmitter now precedes as unicast with available DSRC channel (same as first case)

The second case to be considered is sending multicast/broadcast frames. The negotiating protocol on the dedicated control channel is done by the following steps:
  1. 1.

    Transmitter sends an Adjusted-RTS with the selected list of frequencies to many receivers.

  2. 2.
    All receivers check their CNST for that particular channel frequency with the corresponding access category. If a vehicle had the channel occupied with a certain transmission then it checks the QoS AC (Access Category) of this particular transmission.
    • If AC is less prior then it will defer the old transmission and reserve it for the incoming transmission.

    • If AC was more prior then it won’t defer but wait for the completion and buffer the new transmission.

  3. 3.

    Transmitter sends data on the corresponding service channel.


5 Proposed MAC enhancement: MoByToP (mobility based dynamic TXOP)

MQOG mainly addresses the issue of granting safety messages a reliable delivery in congested environments with high interference by making use of the free ISM and UNII-3 bands already available. However MQOG doesn’t address the issue of providing fair access between vehicles for medium contention and link reservation. Vehicles in a vehicular network cannot be treated equally under all circumstances. In this section, we add a MAC enhancement, a dynamic MObility Based Transmit OPportunity: MoByToP. We start this section by presenting a detailed explanation of MoByToP’s operation.

5.1 MoByToP design

Unlike multimedia networks where prioritizing traffic only depends on QoS (audio, video and voice), MobyTop mechanism enhances the medium reservation phase by prioritizing traffic according to vehicular speed, download data rate, and QoS. MoByToP first calculates a ceiling for the maximum TXOP attainable by considering the available buffer size, maximum data rate and length of the MSDU frame. Hence this duration is the maximum time allowed for a single burst of frame transmissions between two vehicles considering technological limitations. Secondly, MoByToP assesses the QoS of the traffic to be submitted as it can belong to safety, realtime or non-realtime applications. Safety applications are given the highest priority followed by realtime then nonrealtime. To account for fairness in link reservation, MoByToP then adjusts the TXOP duration based on the average transmit data rate as vehicles with low RSS (Received Signal Strength) levels receives data slower than others. Hence, MoByToP is taking account the high interference and multipath in vehicular environments. Finally to incorporate mobility in an integrated manner, MoByToP calculates the time needed for two vehicles to get out of communication range given their positions and speeds and then assess if this time is less than the ceiling TXOP. If this is the case, it will be assigned the new TXOP. Hence two vehicles going out of communication range are prioritized over others as they exchange a longer frame burst and hold the medium for a longer duration. In the following subsections, we explain MoByToP mechanism in details.

Maximum duration of a frame burst

We define CeilToP as the maximum duration for a frame burst. CeilToP has a physical limitation depending on the buffer, MSDU size and transmit data rate. In [21] authors define the maximum TXOP attainable by the following formula:
$$CeilToP(s) = \frac{L(bits) \times N}{R(bits/s)}$$
Where L is the length of the MSDU frame, N is the maximum number of packets in the buffer and R is the transmit data rate (bps). The formula shows that maximum TXOP is directly proportional to the number of packets transmitted and the buffer size and indirectly proportional to the transmit data rate. So to achieve same TXOP duration with small R (data rate) values, we need to increase N hence transmitting more MSDU frames. CeilToP may have different values depending on the average data rate and the technology being used. In our simulations, we set CeilToP to 6,032 ms (same maximum value as the IEEE 802.11e). This number was shown to be suitable for the VANet scenario after performing extensive simulations and testing with other values.

Quality of service

In vehicular networks, safety application traffic should be prioritized before voice, audio and video due to its life critical nature. MoByToP incorporates QoS by granting frames with higher priority a longer frame burst thus leading to a higher TXOP interval. This can be achieved after applying the following equation:
$$Q\_TxoP(s) = \frac{n}{6} \times CeilToP(s) $$
Where n is the priority number of the corresponding QoS Access Category and CeilToP is the maximum TXOP achieved.

Download data rate

Vehicular networks are considered high multipath environments with dynamic delay spreads due to multiple reflections, scattering, diffraction and refraction. This type of environment causes fluctuating RSS levels. Moreover, communication links might be Non-LOS (line of sight) due to the presence of many obstacles between the two communicating vehicles. This would weaken the signal propagation and reception. Since the signal strength is directly proportional to the data rate received [23], some vehicles might be receiving data with very slow data rates while others might be much faster. Therefore, the unfairness in terms of throughput is unavoidable even if stations have the same QoS level (AC). To alleviate the fairness problem, MoByToP manages to assess the download data rate before assigning the corresponding TXOP. Thus, it aims to give a longer duration (longer frame burst) for vehicles with low download data rates while a shorter duration for vehicles with faster data rates. In [22], the authors propose a mechanism to consider the transmit data rate and TXOP adjustment. This mechanism is applied to a wireless network (not vehicular) with heavy load conditions. MoByToP uses part of that mechanism while integrating it with mobility and QoS enhancements. To mathematically model the problem, authors in [22] assign a coefficient Data Rate Ratio (DRR) to adjust the TXOP of different stations. The coefficient is defined as:
$$ DDR = \frac{DataRate(bits/s)}{Average\_DataRate(bits/s)} $$
Where DataRate is the current download data rate and Average_DataRate is a predefined value for the average data rate in a Vehicular network set to be 12 Mbps [13].
Using DRR to calculate the new TXOP, we set:
$$ RQ\_TxoP(s) = \frac{Q\_TxoP(s)}{DDR} $$
where Q_TXOP is the adjusted QoS Data Rate (defined in previous subsection)

MoByToP uses this equation as part of its mechanism and thus the TXOP is adjusted based on the average transmit data rate granting slow transmissions a longer frame burst and fast transmissions a slower frame burst. This would provide fairness to the vehicular environment.

LOP (Link out of range prediction)

As shown in Fig. 6, Vehicle A is communicating with both vehicles B and C. Vehicle C is driving in the same direction as vehicle A however vehicle B is driving out of range of A. As the medium is alternating between A-B and A-C, it is better at this point to transmit longer frame bursts between A-C before the link breaks thus allocating for this communication link a longer TXOP. Although this would create delay in the communication between A-B but as long as the two cars are driving in tandem, they can always compensate for that delay in the coming seconds.
Fig. 6

Comparison between driving within and out of communication range

The following assumptions are important for the calculation of LOP and then integrating it in the TXOP operation.
  1. 1.

    Each vehicle has a bidirectional communication with any neighbor vehicle. The theoretical communication Range set by IEEE 802.11p is 1000 m [13]. In [24], authors evaluated the performance of IEEE 802.11p PHY layer and the actual range measured was 700m in a real life scenario. So vehicles within 700 m are capable to initiate and maintain a communication link and thus called adjacent vehicles.

  2. 2.

    Each vehicle is set to transmit a periodic beacon frame. The beacon frame contains the vehicle ID, position, speed and direction angle.

  3. 3.

    The speed, position and direction angle are assumed to be constant for the time of link calculation which is not supposed to take more than 1 second. In case of any change, this would take account in the next calculation as the mechanism is highly dynamic and implemented before every frame transmission.

  4. 4.

    Each vehicle is capable of calculating its direction angle from its previous position. The process of calculating the direction angle is depicted in Fig. 7. As car A is moving from position 1 to position 2, the direction angle is calculated as the inverse of the tangent of \(\delta {y}\) (y\(_{2}\) - y\(_{1}\)) over \(\delta {x}\)(x\(_{2}\) - x\(_{1}\)).

  5. 5.

    LOP is calculated for a one hop communication link between two cars.

Fig. 7

Calculating the direction angle

To calculate LOP, we set 2 adjacent vehicles A and B moving with velocities VA and VBrespectively along a stationary Cartesian Coordinate System with orthogonal unit vectors and ŷ along the X and Y axes respectively. As V x = V cosα and V y = V sinα then LOP is achieved when the distance between A and B is greater than 700 m [24]. Setting ∥ A B ∥ as the distance between A and B, and solving for the time where the distance is greater than R would result in LOP.
$$\begin{array}{@{}rcl@{}} \lVert \overrightarrow{AB} \rVert^{2} \geq R^{2} \\ \left(\bigtriangleup X + \bigtriangleup Vxt\right)^{2} + \left(\bigtriangleup Y + \bigtriangleup Vyt\right)^{2} &\geq R^{2} \\ t^{2}\left(\bigtriangleup Vx^{2} + \bigtriangleup Vy^{2}\right) + 2t\left(\bigtriangleup X\bigtriangleup Vx + \right.\\ \left. \bigtriangleup Y\bigtriangleup Vy\right) + \left(\bigtriangleup X^{2} + \bigtriangleup Y^{2}\right) - R^{2} &\geq 0 \end{array} $$
This is a second degree equation in t(time). Solving this equation will result in 2 roots a positive and a negative one. Since time is always positive we are only concerned with the positive root. Solving for t we get:
$$\begin{array}{@{}rcl@{}} t &=& \frac{(\bigtriangleup Vx\bigtriangleup X + \bigtriangleup Vy \bigtriangleup Y)}{\bigtriangleup Vx^{2} + \bigtriangleup Vy^{2}} \\ &+& \frac{\sqrt{\left(\bigtriangleup Vx^{2} + \bigtriangleup Vy^{2}\right)R^{2} -(\bigtriangleup Vx\bigtriangleup Y - \bigtriangleup X\bigtriangleup Vy)^{2}}}{\bigtriangleup Vx^{2} + \bigtriangleup Vy^{2}}\\ \end{array}$$

By calculating Link Out of Range Prediction we are able to predict after how many seconds the link would break. If the link is breaking then we set TXOP to its maximum CeilTop and then reserve the medium the longest possible. Otherwise if LOP is larger than maximum TXOP, TXOP will be adjusted based on QoS and download data rate. In the next subsection, we explain the overall operation of MoByToP.

Overall mechanism

MoByToP mechanism is applied before a vehicle transmits any packet. Algorithm 1 describes the detailed process that MoByToP goes through and all the steps involved in calculating the most efficient TXOP for a VANet scenario.

6 Enhanced-MQOG: integrating MoByToP scheme with MQOG

In this section, we discuss the integration of MoByToP with MQOG. Adding MoByToP scheme to MQOG is relatively straightforward and simple since both protocols are independent.
  • MoByToP works on the medium reservation phase after a vehicle gains access to the medium whereas MQOG provides the architecture of MAC operation and the phase preceding gaining access to the medium.

  • MQOG defines the modes while MoByToP defines the duration of transmission.

  • MQOG provides fast reliable access to the medium, MoByToP provides fair access in holding the medium.

Hence combining both MQOG and MoByToP result in an Enhanced version of MQOG which is a fair and efficient MAC able to mitigate most MAC challenges in vehicular environments.

7 Performance evaluation

In this section we evaluate EMQOG (MQOG with MoByToP enhancement). Performance evaluation was carried out in OMNET++4.1 coupled with SUMO to generate real traffic mobility. Realistic maps were also selected from Ottawa by using the OpenStreetMap Project [25]. Performance Evaluation metrics were captured and compared to 802.11p, 802.11e and DCA multichannel protocol [17].

7.1 Simulation environment


To evaluate the proposed protocols, the implementation and simulation were done using OMNET++ version 4.1 which is a discrete event network simulator composed of reusable intercommunicating models written in C++. Making use of the software reuse, INETMANET framework is an already built in project that comprises many known networking layer protocols for MANets (Mobile Adhoc Network) and it was added to OMNET++ as part of the simulation.

SUMO and TraCI

Regarding the traffic simulation and mobility, we used SUMO which is a microscopic traffic simulator. SUMO performs simulations of vehicle movements in real word maps adhering to multiple lanes, speed limits and traffic lights. VEINS (Vehicles in Network Simulation) [26] was used to bidirectionnaly couple OMNET++ with SUMO. A TCP connection is opened at port 9999 between both simulators to allow dynamic interaction during runtime. Using this port, OMNET++ and SUMO can interact with each other by sending a series of commands (e.g. speed, position... etc) during small time-steps to influence individual vehicles movements and resulted network traffic.

Map layouts

Different maps for the performance evaluation were selected for both MQOG and EMQOG respectively. Both map datas were exported from OpenStreetMap Project. The map data includes all roads attributes such as speed limits, lanes count, stop signs, road type, and driving direction. We chose different maps since EMQOG is testing for mobility and we needed to include the 417 highway where cars can reach up to 110 km/hr. The following maps were then converted to xml files to be processed by SUMO using NETCONVERT application. Table 4 shows parameters for the selected maps.

Mobility traces

SUMO distinguishes between a trip and a route. A trip is a vehicle movement from one place to another defined by the starting edge (street), the destination edge, and the departure time. A route is an expanded trip, that means, that a route definition contains not only the first and the last edge, but all edges the vehicle will pass. By using DUAROUTER [27] which is an application with SUMO, vehicle routes are computed using SUMO shortest path computation. DUAROUTER [27] requires the use of the map xml file already generated by SUMO using NETCONVERT [27]. Moreover, we generated many sets of trace files where each set contains traces of a specific number of vehicles. Not only we had to generate trace files when changing the number of vehicles, but also we had to generate different trace files for the same number of vehicles as it would result in more accuracy when analyzing our results. In the traces, vehicle routes are defined, where every vehicle departs at a specific simulation time in a random residential area, and goes through different edges to reach a final destination. Vehicle routes are computed using the shortest path computation, which takes into account street length, speed limits, lane count, and street type. Each trace file captures vehicles movements in the city within 15 minutes. Moreover to increase the accuracy of our model, buildings and other obstructions were added by using POLYCONVERT [27] application in SUMO.


For SUMO parameters, we have to set a Car-Following Model. The model developed by Krauss in 1998 is a microscopic, space-continuous, car-following model based on the safe speed paradigm: A driver tries to stay away from the driver in his front at a distance and a safe speed that allows him to adapt to his leader’s deceleration. The model assumes the driver to have a reaction time τ of about one second. The model uses the following parameters:
  • A: the maximum acceleration of the vehicle

  • B: the maximum deceleration of the vehicle

  • Vmax: the maximum velocity of the vehicle

  • l: the length of the vehicle

  • e: the driver’s imperfection in holding the safe speed (between 0 and 1)

  • Vsafe: Safe velocity computed using the following equation:
    $$ Vsafe(t) = V_{L}(t) + \frac{g(t)- V_{L}(t)\tau}{\frac{V}{B \times V} + \tau} $$
    • V L (t): Speed of the Leading Vehicle in time t

    • g(t): Gap to the Leading Vehicle in time t

    • τ The Driver’s Reaction Time (usually 1s)

Since this model is already added to SUMO, the vehicle’s parameters are set to the values depicted in Table 5.
Table 5

Map areas


Map area


4km x 3km (Including 417 Highway)

7.2 Simulation parameters

All vehicles were configured in OMNET++ to have same general simulation parameters shown in Table 6. In addition, we added static nodes transmitting randomly in the ISM and UNII-3 band to add interference on those bands which would render our simulation more realistic.
Table 6

SUMO vehicle parameters



Vehicle Acceleration

2.5 \(m/s^{2}\)

Vehicle Deceleration

4.6 \(m/s^{2}\)

Vehicle Length

5 m

Maximum Vehicle Speed

Varying Depending on Simulation

Driver Imperfection


7.3 Performance evaluation metrics

In order to quantitatively evaluate our proposed protocols, we assess different performance metrics and we compare our protocol with the IEEE 802.11p [13] and IEEE802.11e [28] for EMQOG. Each simulation was carried out more than 10 times and the results obtained were statistically analyzed by computing the mean and the standard deviation. On the different graphs represented, we present the mean of the collected data and the 95 % Confidence Interval. The performance evaluation metrics used are the Delay, Packet Delivery Ratio, Average Throughput, L2 Retransmission Rate.

To evaluate the latency of frame reception for safety messages, delay was measured as the first metric. For mobility assessment, the packet delivery ratio was tracked while Cars were moving with different speeds. Moreover, we initiated various applications with different bit rates on the transmitter side while measuring the average throughput as the third metric. All those metrics were calculated in both scenarios covering the scalability of a VANET in both light and heavy load conditions. Those metrics show the efficiency of the system in reception of safety messages within time constraints, reliability of delivered frames within different speeds and system overall performance in throughput assessment.


The two scenarios used in this assessment are A and B, presented in Table 7. The National Census Authorities in Australia, Canada, France, United Kingdom and the United States [29] designate urban areas with urban density equal to or above 400 persons per square km. Mapping the definition and applying it to vehicular urban densities, it translates to 50 vehicles per square kilometer considering the vehicular measurements. So when the vehicular urban density is above 50 per square kilometer then it’s considered an urban environment otherwise it is suburban. The main difference between both scenarios is increasing the number of vehicles and thus creating an urban environment where there exists more contention on the medium. Quality metrics are recorded during simulation time for both scenarios and the protocols are tested under both light and heavy load conditions. The metrics are being collected for a unicast 1 hop link between two cars transmitting and receiving frames. The two communicating vehicles start in the same position then drive in random directions. Other vehicles are flooding a broadcast message which was initiated by one vehicle and then disseminated throughout the network. In addition, all vehicles transmit a beacon frame every second. The beacon contains the vehicle ID, Speed, Position and direction angle α. This information is stored in the vehicle database and updated every second (Table 8).
Table 7

General simulation parameters

Simulation parameters


Radio Propagation


Radio Range


Carrier Frequency

5.8125 - 5.925 GHz (Dynamic)

MAC bitrate

12 Mbps

Radio Transmit Power

20 dBm (100 mW)

Vehicular Speed

Vary from 30km/h - 110km/hr

Radio Sensitivity

-85 dBm

Data Frame Size

1000 Bytes

Control Frame Size

50 Bytes

Broadcast Traffic Rate

1 frame/s

Broadcast Interval

500 ms

Beacon Frequency

1 Hz

Simulation Time

15 minutes

Table 8

Scenario types


Scenario A

Scenario B

Number of Vehicles

120 vehicles

780 vehicles

Vehicular Density

10 vehicles/km\(^{2}\)

65 vehicles/km\(^{2}\)




Average delay for safety message reception

First, we evaluate the delay in ms for the reception of safety messages. In general, safety messages have latency constraints and should be received within short delays. As can be seen in Figs. 8 and 9, the delay for all implemented protocols starts low and then increases with time. This is due to the flooding of broadcast messages between adjacent vehicles creating a wider disseminated circle. For scenario A, seen in Fig. 8, EMQOG outperforms slightly 802.11p and 802.11e in 70 ms. 802.11p and 802.11e have approximately very similar delays in the beginning but 802.11e performs better after 11 minutes because of its TXOP operation that combats congested media.
Fig. 8

Average delay for safety message reception - Scenario A

Fig. 9

Average delay for safety message reception - Scenario B

On the other hand, it can be clearly seen in Fig. 9 (urban environment) that EMQOG outperforms 802.11p and 802.11e in 100 ms. As EMQOG is granting longer TXOP for safety messages, it ensures a lower delay with a higher reliability of transmission. This was clearly demonstrated when there was traffic since safety messages are prioritized over regular data traffic and by using the dynamic TXOP, traffic is being sent consecutively.

General Packet Delivery Ratio (PDR)

To assess the impact of mobility, we evaluate the PDR (Packet Delivery Ratio) while varying the cars’ speeds. As SUMO sets the speed limits on the downloaded map roads and cars, we alter the maximum car speed in the Krauss model to an upper threshold however cars still drive within speed limits.This speed is set in our simulation and it represents the x-component of our graph. The simulation is repeated each time with a different maximum speed to evaluate the performance in different mobility conditions. In general, PDR represents the ratio of number of messages received to the number delivered. As can be seen in Fig. 10 (Scenario A), all MAC protocols start by having a high PDR with low speeds. However as the vehicular speed increases (above 70km/hr), the PDR drops gradually due to high mobility impact which is not considered in 802.11e. 802.11p performs better than 802.11e as it has mobility consideration but lacks the dynamic TXOP operation incorporated in EMQOG. On the other hand, in the urban environment which can be seen in Fig. 11, as the medium contention increases, EMQOG much outperforms 802.11e and 802.11p. This is because it considers vehicle’s speeds while allocating the necessary TXOP limit. Hence, vehicles driving in high speeds would have a longer TXOP limit allocating the medium for a longer time and submitting a longer frame burst. EMQOG outperformed others especially in congested environments with cars driving in high speeds as it is designed to mitigate mobility and congestion unlike other MAC layer protocols.
Fig. 10

Packet delivery ratio - Scenario A

Fig. 11

Packet delivery ratio - Scenario B

Average throughput

The average throughput reflects the system’s overall performance. As shown in Figs. 12 and 13, there wasn’t much difference in the simulation results for both 802.11e and 802.11p. On the other hand, EMQOG outperformed them in both scenarios A and B. This is due to the fact that EMQOG is transmitting a frame burst with short delays hence enhancing the throughput achieved. As we are shifting from a suburban to an urban environment i.e. from scenario A to scenario B, EMQOG performed much better than the others since it considers the transmit data rate whereas 802.11p and 802.11e overlook that aspect in the MAC layer. Moreover, EMQOG considers the average data rate and forces vehicles to cooperate fairly in the contention process.
Fig. 12

Average throughput x traffic rate - Scenario A

Fig. 13

Average throughput x traffic rate - Scenario B

Overall, EMQOG outperformed 802.11p and 802.11e and is more suitable for VANet environments with varying traffic conditions. Although with low medium contention, EMQOG doesn’t provide an edge compared to others however its contribution lies in considering mobility, prioritizing safety messages, and ensuring a better throughput. Moreover, EMQOG major contribution is in congested environments where medium contention is an issue as it smartly allocates the medium based on mobility, QoS, and data rate considerations.

8 Conclusion

In this work, we proposed a novel Multichannel QoS Cognitive MAC (MQOG) tailored for vehicular communications. Channel sensing is done prior to transmission and messages are always sent on the best available channel to mitigate high interference and multipath problems. Moreover, this protocol ensures QoS by granting safety messages higher priority of accessing the medium over data messages. Those features make our proposed protocol more suitable for VANETS than other existing protocols. However since MQOG has some limitations in terms of fair medium access, we modified it by adding MoByToP, a MAC Layer enhancement scheme. MoByToP incorporates mobility, QoS and transmit data rate and integrates them into the MAC to mitigate VANet challenges. It uses beacon information to calculate LOP (Link Out of Range Prediction) and then uses it to circumvent link failure. Moreover, it ensures QoS by granting safety messages higher priority of reserving the medium over data messages. In addition, MoByToP adjusts the frame burst based on the RSS (Received Signal Strength) to create a fair effective sharing of resources and hence enhancing the system’s overall throughput. Those features combined make EMQOG (Enhanced MQOG) very suitable for VANets. To evaluate the performance of MQOG and EMQOG, implementation was done in OMNet++ 4.1 and our results showed an improvement in throughput.

8.1 Future work

Although this work provides a comprehensive study and evaluation from different perspectives, there are still some open issues and several research directions that can be pursued to improve the performance of MQOG and MoByToP.
  • Multiple Hops: The proposed MAC protocol MQOG and the enhancement mechanism MoByToP are both for 1 hop transmission. Future work may expand the operation of both of them to consider multiple hops.

  • Heterogeneous Networks: Work can be done to provide a MAC handoff process between different heterogeneous networks such as cellular networks or WLANs from one side and vehicular networks from the other. Moreover, the MQOG architecture of having multiple channel can be helpful in the handoff process and may facilitate such convergence implementations.

  • Real-TestBed Implementation The proposed scheme can be implemented in a real life testbed and the scenarios proposed can be tested in Ottawa under selected urban and suburban environments.


  1. 1.
    Mak TK, Laberteaux KP, Sengupta R, Ergen M (2009) Multichannel medium access control for dedicated short-range communications. IEEE Trans Veh Technol 58(1):349–366CrossRefGoogle Scholar
  2. 2.
    Bana SV, Varaiya P Space division multiple access (SDMA) for robust ad hoc vehicle communication networks. In: Intelligent transportation systems, 2001. Proceedings 2001. IEEE, pp 962-967Google Scholar
  3. 3.
    Katragadda S, Ganesh Murthy CNS, Ranga Rao MS, Mohan Kumar S, Sachin R (2003) A decentralized location-based channel access protocol for inter-vehicle communication. In: The 57th IEEE semiannual vehicular technology conference, vol 3, pp 1831–1835Google Scholar
  4. 4.
    Mangharam R, Rajkumar R, Hamilton M, Mudalige P, Bai F (2007) Bounded-latency alerts in vehicular networks. In: Mobile networking for vehicular environments, pp 55–60Google Scholar
  5. 5.
    Jeremy JB, Azim E (2007) A reliable link-layer protocol for robust and scalable intervehicle communications. IEEE Trans Intell Transp Syst 8:4–13CrossRefGoogle Scholar
  6. 6.
    Nakata H, Inoue T, Itami M, Itoh K (2003) A study of inter vehicle communication scheme allocating PN Codes to the location on the road. Proc IEEE Intell Transp Syst 2:1527–1532Google Scholar
  7. 7.
    Xianbo C, Refai HH (2008) SDMA: on the suitability for VANET. In: 3rd International conference on information and communication technologies: from theory to applications, pp 1–5Google Scholar
  8. 8.
    Borgonovo F, Capone A, Cesana M, Fratta L (2003) ADHOC: a new, exible and reliable MAC architecture for ad-hoc networks. IEEE Wirel Commun Netw 2:965–970Google Scholar
  9. 9.
    The European project CarTALK (2000)
  10. 10.
    Menouar H, Filali F, Lenardi M (2006) A survey and qualitative analysis of mac protocols for vehicular ad hoc networks. IEEE Wirel Commun 13(5):30–35CrossRefGoogle Scholar
  11. 11.
    Chen X, Refai HH, Ma X (2010) On the enhancements to IEEE 802.11 MAC and their suitability for safety-critical applications in VANET. Wirel Commun Mob Comput 10(9):1253–1269CrossRefGoogle Scholar
  12. 12.
    Cuyu C, Xiang Y, Meilin S, Lin L (2009) WRI International Conference on. In: Performance observations on MAC protocols of VANETs in intelligent transportation system. In: WRI international conference on communications and mobile computing, 2009. CMC ’09, vol 2, pp 373–379Google Scholar
  13. 13.
    IEEE standard for information technology– Local and metropolitan area networks– specific requirements– part 11: wireless LAN medium access control (MAC) and physical layer (PHY) specifications amendment 6: wireless access in vehicular environments (2010) IEEE Std 802.11p-2010 (Amendment to IEEE Std 802.11-2007 as amended by IEEE Std 802.11k-2008, IEEE Std 802.11r-2008, IEEE Std 802.11y-2008, IEEE Std 802.11n-2009, and IEEE Std 802.11w-2009), pp 1–51Google Scholar
  14. 14.
    IEEE standard for wireless access in vehicular environments (WAVE)–multi-channel operation (2011) IEEE Std 1609.4-2010 (Revision of IEEE Std 1609.4-2006), pp 1–89Google Scholar
  15. 15.
    Yiu W-PK, Jin X, Chan S-HG (2007) VMesh: distributed segment storage for peer-to-peer interactive video streaming. IEEE J Sel Areas Commun 25(9):1717–1731CrossRefGoogle Scholar
  16. 16.
    Hang S, Xi Z (2007) Clustering-based multichannel MAC protocols for QoS provisionings over vehicular Ad Hoc networks. IEEE Trans Veh Technol 56(6):3309–3323CrossRefGoogle Scholar
  17. 17.
    Wu S-L, Lin C-Y, Tseng Y-C, Sheu J-L (2000) A new multi-channel MAC protocol with on-demand channel assignment for multi-hop mobile ad hoc networks. Int Symp Parallel Archit, Algoritm and Netw 232–237Google Scholar
  18. 18.
    Jiang D, Taliwal V, Meier A, Holfelder W, Herrtwich R (2006) Design of 5.9 ghz dsrc-based vehicular safety communication. Wirel Commun IEEE 13(5):36–43CrossRefGoogle Scholar
  19. 19.
    Fluke Networks: AirMagnet Survey DatasheetGoogle Scholar
  20. 20.
    Coleman DD, Westcott DA (2009) CWNA Certified Wireless Network Administrator Official Study Guide. Sybex John Wiley and Sons McGraw-HillGoogle Scholar
  21. 21.
    Majkowski J, Palacio FC (2006) Dynamic TXOP configuration for Qos enhancement in IEEE 802.11e wireless LAN. In: International conference on software in telecommunications and computer networks, 2006. SoftCOM 2006, pp 66–70Google Scholar
  22. 22.
    Guo N, Chen C, Pei C-X (2006) Dynamic TXOP Assignment for Fairness (DTAF) in IEEE 802.11e WLAN under heavy load conditions. In: Seventh international conference on parallel and distributed computing, applications and technologies, 2006. PDCAT ’6, pp 80–85Google Scholar
  23. 23.
    Ghaboosi K, Latva-aho M, Yang X, Khalaj BH (2008) IEEE 802.11 distributed coordination function service time and queuing delay analysis using parallel space - time Markov Chain. In: IEEE 19th international symposium on personal, indoor and mobile radio communications, 2008. PIMRC 2008, pp 1-5Google Scholar
  24. 24.
    Paier A, Tresch R, Alonso A, Smely D, Meckel P, Zhou Y, Czink N (2010) Average downstream performance of measured IEEE 802.11p infrastructure-to-vehicle links. In: 2010 IEEE international conference on communications workshops (ICC), pp 1-5Google Scholar
  25. 25.
    Open Street Map Project:
  26. 26.
    Vehicles In Network Simulation (VEINS):
  27. 27.
  28. 28.
    IEEE Amendment 8: Medium Access Control (MAC) (2005) Quality of service enhancements, pp 1–189Google Scholar
  29. 29.
    Demographia World Urban Areas (World Agglomerations) (2013) 9th annual edition.

Copyright information

© Springer Science+Business Media New York 2013

Authors and Affiliations

  • Hikmat El Ajaltouni
    • 1
  • Azzedine Boukerche
    • 1
  • Abdelhamid Mammeri
    • 1
  1. 1.PARADISE Research Laboratory SITEUniversity of OttawaOttawaCanada

Personalised recommendations