21 Performance Evaluation of Realistic Vehicular ...

21

Performance Evaluation of Realistic Vehicular Networks A MAC Layer Perspective Ali Balador, Carlos T. Calafate, Juan-Carlos Cano, and Pietro Manzoni

Contents Abstract........................................................................................................................................... 572 21.1 Introduction........................................................................................................................... 572 21.2 Literature Review and Related Work..................................................................................... 573 21.2.1 VANET Simulation Challenges................................................................................. 573 21.2.2 VANET Models, Tools, and Platforms...................................................................... 574 21.2.2.1 Network Simulation Tools.......................................................................... 574 21.2.2.2 Traffic Simulation Tools............................................................................. 575 21.2.2.3 Interlinking Tools....................................................................................... 576 21.2.2.4 VANET Simulation Tools........................................................................... 576 21.2.3 Overview of IEEE 802.11 and 802.11p...................................................................... 577 21.3 Alternatives to IEEE 802.11p for Vehicular Environments................................................... 579 21.4 Simulation Requirements...................................................................................................... 581 21.4.1 Network Simulation (OMNET++)............................................................................. 581 21.4.1.1 INETMANET............................................................................................. 582 21.4.1.2 Scenario Definition Using NED Files......................................................... 582 21.4.1.3 omnetpp.ini File.......................................................................................... 582 21.4.2 Traffic Simulation...................................................................................................... 583 21.4.2.1 SUMO......................................................................................................... 583 21.4.3 Traffic Control Interface............................................................................................ 584 21.5 Case Study............................................................................................................................. 584 21.5.1 Simulation Scenarios................................................................................................. 584 21.5.1.1 Urban Scenario........................................................................................... 584 21.5.1.2 Highway Scenario....................................................................................... 584 21.5.2 Simulation Parameters and Metrics........................................................................... 585 21.5.3 Urban......................................................................................................................... 586 21.5.4 Highway..................................................................................................................... 589 21.6 Conclusions............................................................................................................................ 590 Acknowledgments........................................................................................................................... 590 References....................................................................................................................................... 591

571

K22422_C021.indd 571

7/9/2014 11:22:59 PM

572

Simulation Technologies in Networking and Communications

Abstract Vehicular ad hoc networks (VANETs) have attractive potential in order to reduce traffic jams and avoid transportation disasters. They are also able to provide infotainment services like web browsing, e-mail, or using social networks on the road. Achieving a well-designed medium access control (MAC) protocol is a challenging issue to improve communications efficiency due to the dynamic nature of VANETs. The CSMA-based MAC protocol adopted by the IEEE 802.11p standard was selected as the best choice for the current generation of VANETs considering its availability, maturity, and cost. Despite these benefits, the common problem in all IEEE 802.11-based protocols is scalability, exhibiting performance degradation in highly variable network scenarios. This chapter provides an overview of 802.11/802.11p, as well as alternatives presented by the research community to address the detected limitations in vehicular scenarios. In addition, performance evaluation results highlight the need for contention window (CW) adjustment schemes in order to avoid performance degradation, especially in dense and highly mobile scenarios. Realistic vehicular environment clearly affects the obtained results, so we tried to choose appropriate and realistic network and traffic simulators. In this chapter, we also explain why the simulator choice is a relevant issue, and how to properly configure simulation settings for vehicular environments. Analysis and simulation results using OMNeT++ in vehicular scenarios, including highway and urban scenarios, show that alternatives to 802.11p able to perform CW adjustments are able to improve the overall performance, even for high network density scenarios.

21.1 Introduction

AQ1

With advances in wireless communication technologies, VANETs have emerged as an attractive research area for both academia and industry. Vehicular networks are formed by vehicles equipped with wireless devices, called on-board units, which allow communicating with other vehicles in infrastructure-less wireless networks (vehicle-to-vehicle, V2V) or with roadside units (vehicleto-infrastructure, V2I). Vehicular environments integrating intervehicle communications can be assumed as a special form of mobile ad hoc networks (MANETs) in which node’s mobility is roadconstrained [1]. The main differences between VANETs and MANETs have to do with rapid topology changes and diversity of network scenarios. Also, it must be taken into account that, in contrast to MANETs, vehicle’s density is highly dynamic. For example, in highway scenarios, vehicles have mostly one straightforward direction, but high relative speeds up to 100 km/h, compared to the cars driving in the opposite direction that can lead to a challenging situation. On the other hand, in urban scenarios, high-density networks appear during rush hours. Also, network disconnection can occur in the late night hours or idle daytime hours. Therefore, designing protocols able to take all of these characteristics into account is still a challenging open issue. MAC protocols play an important role since critical communications rely on them. Unfortunately, research results [2] highlight that the topic of MAC support in VANETs has received less attention in than other research fields (we further mention some of the existing works). Also, most of the relatively few research works are dedicated to V2I communications; therefore, MAC support for V2V communication needs more attention. MAC layer design challenges in VANET environments can be summarized as follows [3]: (1) Achieving an effective channel access coordination in the presence of changing vehicle locations and variable channel characteristics, (2) supporting scalability in the presence of various traffic densities, and (3) supporting a diverse set of application requirements. According to the definition in [4], a system is said to be scalable if it can handle the addition of users and resources without suffering a noticeable loss of performance or increase in administrative complexity. The number of vehicles is neither restricted nor predictable in vehicular environments, so the MAC protocol must be scalable in order to fulfill end-to-end delay and packet delivery ratio (PDR) requirements.

K22422_C021.indd 572

7/9/2014 11:22:59 PM

Performance Evaluation of Realistic Vehicular Networks

573

Applications for VANETs can be categorized into three groups: safety, convenience (traffic efficiency), and commercial applications (infotainment) [5]; each of these classes of applications has its own quality of service (QoS) requirements. Safety applications represent the main target of intervehicle communications. Their goal is to increase each vehicle’s awareness about its neighborhood. For this purpose, they use small messages that are broadcasted to a close neighborhood and are limited in time. The assumed objectives for traffic efficiency applications can be considered as reducing the time each vehicle spends on the road in order to reduce fuel consumption and air pollution. Contrary to safety applications, these applications do not require a high penetration ratio, and infrastructure requirements can be met by existing 3G/4G networks. Finally, the third group of applications consists of infotainment applications. Although they do not have any effect on road traffic, they provide convenience and comfort to drivers and/or passengers. These applications, similar to traffic efficiency applications, are infrastructure-based. The delay is not considered as critical as in safety applications, but the transferred data volume is much larger than in safety applications. IEEE 802.11p [6], which is an amendment for wireless access in vehicular environments (WAVE), basically proposes physical layer changes, while the MAC layer has remained mostly the same as in IEEE 802.11. A lot of research has been done by the research community in order to improve the performance of IEEE 802.11p concerning safety applications (e.g., [7–10]). The results of [5] confirm that some traffic efficiency applications, and also the majority of commercial applications, rely on unicast communications. This classification clarifies that although safety applications have attracted special interest and require more scrutiny, other types of applications need to be attended as well. Also, as previous studies have shown [11–13], VANETs introduce complex dynamics that have not emerged in other types of MANETs. Since the IEEE 802.11 MAC protocol was basically designed for static wireless networks, it achieves poor performance in VANET environments. A well-known problem in IEEE 802.11-based MAC protocol is scalability, which becomes more challenging in VANETs in the presence of high and variable network densities, as a result of higher mobility. Several works have been proposed and carried out for MANET environments [14–21] to either solve or reduce this problem. In particular, those solutions that estimate the channel density by keeping a history of channel transmission states, and then adapting the CW size based on the density estimations, can be quite effective. The rest of this chapter is organized as follows. Section 21.2 presents the basic principles of IEEE 802.11/802.11p standards, challenges, and issues in VANET simulation, and reviews developed tools and simulators for vehicular environments. Section 21.3 reviews some alternatives for these standards in MAC layer. Section 21.4 describes the simulation requirements including scenarios, the measurements, and the metrics used for performance evaluation. Simulation results are provided in Section 21.5, including results in both highway and urban scenarios. Finally, Section 21.6 concludes the chapter.

21.2 Literature Review and Related Work 21.2.1 VANET Simulation Challenges Although VANETs are a kind of MANETs, its characteristics make MANET simulation tools hardly applicable for VANET environments. While using common wireless network simulators (such as NS-2 [22]) in conjunction with widely used mobility models (such as random way point [23]) gives acceptable results, modifications to simulators are required to introduce new characteristics. In the following, we summarize the important challenges for VANET simulation: First of all, vehicular mobility must be modeled in VANET simulation frameworks. The widely used models for vehicular simulation are microscopic models that represent traffic loads by individually considering each vehicle behavior, based on the state of the neighboring cars, and also the characteristics of the driver.

K22422_C021.indd 573

7/9/2014 11:22:59 PM

574


The first step to model vehicular environments is adapting a road infrastructure, which can be manually specified in the simulator or by using real-world maps. The next step is identifying the map topology (such as stop signs or traffic lights), which has an important impact on local vehicle density [24]. Two commonly used examples of microscopic models are car-following and cellular automaton. In the car-following model, accelerating and decelerating of each vehicle depends on the car in front, which is called leader. When the distance from the leader decreases below a certain threshold, the follower starts decelerating; on the contrary, when the distance increases, the follower can increase its velocity until it reaches its own maximum speed. In the cellular automaton model, the road is divided into different sections. Each such section can be occupied at any given moment by one single car. Each car moves from one section to another and decelerates when another car has already occupied the next section. Although the cellular automaton model is not as accurate as the car-following model, it can be used in simulations that do not require a high simulation detail to decrease the simulation time. Simulating vehicle’s properties like car length, acceleration limit, and maximum speed allows us to present a vehicular environment as accurate as possible. In addition to the vehicle’s properties, driver characteristics also play an important role in the mobility pattern of a car. Notice that each driver has different perception-response time, braking time, sign visibility and legibility, hazard recognition, and identification. The intelligent driver model (IDM) [25] is a model that improved upon the car-following model to take into account some of these parameters. The lanechanging policy is another issue that can be considered in a microscopic model, and it depends on the driver attributes. Vehicle generation is another issue that must be taken into account. It can be modeled randomly or by identifying the entry and destination points. In randomly generated vehicles, they are randomly placed on the map; however, this method is not realistic, so it is necessary to wait for a warm-up period before producing reliable results. The other method, which is normally based on macroscopic statistical data, assigns entry and destination points for each vehicle. Another challenge for VANET simulation is modeling the effects of various obstacles on radio wave propagation. These obstacles vary from one scenario to another scenario: in an urban scenario, they consist of buildings and trees surrounding the road, and in highway scenarios, these are tunnels or other cars. Usually the signal power is calculated at the receiver side after applying a series of additions and subtractions to the signal strength at the sender side. Then the decision is made by determining whether the received signal power is above or below a certain threshold. Several models have been introduced for calculating radio wave propagation. In the easiest one, which is called the free space model, the signal power at the receiver side is only calculated based on the distance between communicating entities. The two-ray ground model enhanced the free space model with a multipath propagation, which causes self-interference. Also, the Nakagami model uses Nakagami distributions to model effects of scattered signals that reach a receiver through multiple paths. In the majority of network simulation scenarios, memory and CPU consumption of network simulators grow linearly when increasing the number of nodes, even when some nodes do not contribute to any communication. In the case of V2V network, where each car can be a source of traffic and its destination may be any other car, resource consumption grows with the square of the number of cars. Therefore, when the simulation environment assumes as a city with more than 10,000 nodes, its simulation with current software becomes a challenging issue.

21.2.2 VANET Models, Tools, and Platforms 21.2.2.1 Network Simulation Tools Currently, we can find several network simulators that can be used for VANET simulations. In the following, we will discuss about these simulators and attempt to determine which one can be more adequate for vehicular environment scenarios.

K22422_C021.indd 574

7/9/2014 11:22:59 PM


575

21.2.2.1.1 OMNET++ OMNeT++ [26] is a C++ based, open-source, and discrete event network simulator with strong graphical user interface (GUI) support. It can be used for modeling any system that can be described as a queuing system. Since OMNeT++ is a simulation framework, it does not provide models for wireless network simulation. Therefore, several frameworks have been developed on OMNeT++ for simulating MANETs. Among all of these frameworks, INETMANET [27] and MiXiM [28], which include propagation models specially designed for vehicular environments, are the most appropriate ones for VANET simulation [29].

AQ2

21.2.2.1.2 Network Simulator 2/3 (NS-2/NS-3) NS-2 [22] is a discrete event simulator developed by the VINT project research group at the University of California at Berkeley, with the support of the US Defense Advanced Research Projects Agency. It is assumed as the standard simulator for wired networks due to the large number of models that have been developed for this simulator. It was extended by the Monarch research group in Carnegie Mellon University in order to be able to model node mobility, and more realistic PHY and MAC layers (IEEE 802.11 DCF) for wireless networks. Several mobility and radio propagation models exist in NS-2 that can be used, but none is designed for VANET simulation. Some new models have been produced for VANET simulation in NS-2, but still there are some disadvantages of using NS-2, including its high complexity makes the implementation of vehicular mobility models difficult inside the framework; also, its memory and CPU consumption do not allow simulating large scenarios. NS-3 [30] is an optimized version of NS-2, which introduces less complexity by removing the C++/TCL interactions used in by NS-2, thereby allowing it to handle large-scale scenarios. However, it still cannot use all the models that have been modeled in NS-2, which is a negative point for NS-3. 21.2.2.1.3 Global Mobile Information System Simulator and QualNET Global Mobile Information System Simulator (GloMoSim) is an open-source and scalable simulator for wireless and wired environments developed at the University of California in Los Angeles. The layered design of this simulator, with different APIs between them, eases the integration of different layers by different people. The GloMoSim project stopped in 2000, and a commercial version, QualNET, has been maintained since then. The QualNET framework [31] is able to simulate largescale scenarios with several thousand nodes. Also, a new VANET mobility model, called CORNER [32], has been recently added, which makes it as a good choice for VANET simulation, but its commercial orientation limits its wide usage. 21.2.2.1.4 Java in Simulation Time /Scalable Wireless Ad Hoc Network Simulator [33] Java in Simulation Time (JiST) is a general-purpose discrete-event simulator written in Java, developed at the Cornell University, and Scalable Wireless Ad Hoc Network Simulator (SWANS) has been specially designed for MANETs. The SWANS is able to simulate large scenarios of more than 10,000 nodes. The interesting point of this project is that the real applications written in Java can be directly tested with this simulator. The disadvantages are that the project is no longer maintained and it does not include any mobility and radio propagation model for VANET simulation. 21.2.2.2 Traffic Simulation Tools There are several traffic simulators that are able to generate vehicle’s movements. However, in this section, we just consider simulators that are still updated and supported in different operating systems. For example, CORridor SIMulation (CORSIM) [34] and Verkehr In Stadten SIMulationsmodell (VISSIM) [35] are just supported in a Microsoft Windows platform, which is a negative point for network researchers that usually prefer the Linux OS. Also, MObility model generator for VEhicular networks (MOVE) [36], which was built on top of Simulation of Urban MObility (SUMO), is no longer maintained.

K22422_C021.indd 575

7/9/2014 11:22:59 PM

576


21.2.2.2.1 Simulation of Urban Mobility SUMO [37] is an open-source, microscopic traffic simulator specially designed to handle largescale vehicular mobility. It supports different vehicle types, multilane streets with lane changing, junction-based right-of-way rules, hierarchy of junction types, a powerful GUI, and dynamic routing. SUMO can also import different network formats. 21.2.2.2.2 VanetMobiSim [38] This traffic simulator is an extension to the CANU Mobility Simulation Environment (CanuMobiSim) [39], and it was specially designed for modeling vehicular mobility. It has the ability to import maps and produce mobility traces with different formats, supporting different simulation and emulation tools for mobile networks. Vehicular mobility patterns can be based on random trips or an origin– destination approach. It supports an enhanced version of IDM including both Intersection Management (IDM/IM) and Lane Changing (IDM/LC), and also an overtaking model (MOBIL) [40].

AQ3

21.2.2.3 Interlinking Tools In this section, we describe different modules used to make an interaction between a network and a traffic simulator. As mentioned before, one of the important challenges in VANET simulation is that the movement of each node is not individual, and it is affected by its surroundings. Therefore, the traffic simulator must be able to change the initial trace file during the simulation based on feedbacks received from the network simulator. In the following, we summarize some modules that are produced to link some commonly used simulators like NS-2, OMNET++, and SUMO. 21.2.2.3.1 Vehicles in Network Simulation Vehicles in Network Simulation (Veins) [41] is assumed as the best package for VANET simulation, especially at the MAC level. It produces a TCP connection in order to provide an interaction between SUMO and the INET framework from OMNeT++. In Veins, the network simulator is able to influence the vehicles’ movements produced by traffic simulator by exchanging some commands. 21.2.2.3.2 Traffic and Network Simulation Environment and Integrated Wireless and Traffic Platform for Real-Time Road Traffic Management Solutions Traffic and Network Simulation Environment (TraNS) [42] was the first tool using a link between a network and a traffic simulator, but it is not a high-performance framework, it does not support new versions of SUMO, and it is no longer maintained (since 2008). The Integrated Wireless and Traffic Platform for Real-Time Road Traffic Management Solutions (iTetris) [43] is seen as the successor of TraNS, so that it couples NS-3 and SUMO through a central control block named iTetris Control System (iCS). 21.2.2.3.3 V2X Simulation Runtime Infrastructure [44] Unlike the aforementioned interlinking tools, V2X Simulation Runtime Infrastructure (VsimRTI) is a generic framework that can be used by different simulators such as VISSIM, SUMO, and JiST/ SWANS. Also, this project can work as an emulator for directly testing real applications in V2X environments. 21.2.2.4 VANET Simulation Tools As we mentioned before, VANET simulations require modeling the drivers’ behavior in detail, as well as radio channels. Also, integrated frameworks for simulating both mobility and networking are clearly needed for effectively evaluating the performance of vehicular systems. In this section, we describe the simulators that have been specially designed for vehicular communications. 21.2.2.4.1 GrooveNet [45] This simulator was developed at the Carnegie Mellon University, and it is a hybrid simulator that enables communication between real and simulated vehicles. It has a powerful GUI and the ability

K22422_C021.indd 576

7/9/2014 11:22:59 PM


577

to import maps. Although it has several communication protocols implemented, its complexity and lack of documentation make its development a rather difficult task. 21.2.2.4.2 National Chiao Tung University Network Simulation National Chiao Tung University Network Simulation [46] is also a hybrid simulator like GrooveNet, and it was the first simulator to implement the complete IEEE WAVE architecture. The advantages of this simulator are that it can directly run real applications because it uses the real Linux TCP/IP protocol stack, and it supports parallel simulation on multicore machines. The disadvantages are that it is only compatible with Fedora 9 Linux distribution, and it has been commercial since 2011. 21.2.2.4.3 Integrated Wireless Intersection Simulator [47] Integrated wireless intersection simulator is a tool that was not widely adopted because it is specially designed for intersection management. It provides detailed information for propagation models by considering urban elements. Also, it models several VANET MAC layer protocols. As a conclusion, it can be used as a good simulator, especially for MAC protocols in highway scenarios.

21.2.3 Overview of IEEE 802.11 and 802.11p Although initially proposed for wireless LAN environments, IEEE 802.11 has expanded in order to fulfill the communication requirements of different environments. IEEE 802.11-based MAC protocols rely on the carrier sense multiple access with collision avoidance (CSMA/CA) mechanism, so that each node listens to the channel before transmission in order to prevent collisions. Since they cannot guarantee a collision-free MAC, two main mechanisms are proposed to handle medium access collisions among nodes while also avoiding the hidden node problem. First, the Request-to-Send (RTS)/Clear-to-Send (CTS) mechanism is proposed in order to reserve the medium by sending small packets before transmitting large data packets, basically to avoid the hidden node problem. However, due to the high overhead involved when using this mechanism, it is inactive by default. Second, each node must select a random time (called backoff) before sending each packet to avoid packet collisions. Also, IEEE 802.11 [48] proposes three different Inter Frame Space (IFS) time intervals, such as SIFS, DIFS, and PIFS, in order to prioritize access to the wireless channel. When a new data packet is waiting in the buffer for transmission, the node is allowed to transmit the packet if it finds the channel free after waiting for a time equal to DIFS. Otherwise, if the channel is found busy after this period, it chooses a backoff value and must wait before attempting to transmit again. The next time the channel is found idle, the node must wait for a time equal to DIFS, plus a backoff time before transmission. The Binary Exponential Backoff (BEB) algorithm uniformly selects the backoff time from the interval (0, CW). The IEEE 802.11 standard initializes the CW to the predefined value, CWmin, and doubles it upon transmission failures up to the predefined value, CWmax. Also, The CW is reset to the CWmin by a successful transmission. The node senses the channel and, if it finds the channel idle, decreases the backoff timer by one; otherwise it pauses the timer. The backoff timer is resumed when the channel again remains idle for a period longer than DIFS. The IEEE 802.11 uses positive acknowledgments (ACK) to confirm the correctness of the current transmission to the transmitter. Such mechanism is mandatory since wireless interfaces cannot transmit and listen to the channel simultaneously. Notice that its own signal is too strong, masking any other incoming signals, and so collision detection becomes very difficult. Second, collision detection at the transmitter side does not allow inferring about collisions at the receiver side. Therefore, if the transmitter cannot receive a correct ACK packet, it considers that a collision has occurred, and the current data packet must be retransmitted (up to a predefined number of times). After receiving a correct data packet, the receiver waits for a SIFS time and sends an ACK to the transmitter. Figure 21.1 shows the routines for IEEE 802.11 MAC protocol.

K22422_C021.indd 577

7/9/2014 11:22:59 PM

578

Simulation Technologies in Networking and Communications ListenDIFS CW= CWmin

Yes

Medium idle? No

Draw backoff (BO) [0,CW] Wait until medium idle No

Idle DIFS? Yes

No

BO > 0? Yes Decrement BO

Idle tslot?

No Double CW

Yes Yes

Yes

BO > 0?

CW< CWmax?

No Transmit

Successful reception of ACK?

No

No No

Yes Transmission completed

Max. number of retransmissions reached? Yes Transmission failed

Figure 21.1 IEEE 802.11 MAC protocol mechanisms.

As previously mentioned, IEEE 802.11 introduces specifications for wireless networks, but it cannot provide peak efficiency in vehicular environments. The main standards and specifications for vehicular environments are short-range communications (DSRC), IEEE 802.11p, and IEEE 1609. DSRC includes specifications and standards for communications between vehicles in close neighborhood. Both the United States and Europe have allocated spectrum in the 5.9 GHz range for DSRC. IEEE developed IEEE 802.11p [6], which is an amendment to the original IEEE 802.11 standard for WAVE to better support vehicular communications. IEEE 802.11p defines specifications for link layer and physical layer, also IEEE 1609.4 specifies higher layers that will operate on top of IEEE 802.11p. IEEE 802.11p is an IEEE 802.11-based MAC protocol offering a priority scheme in a similar way to IEEE 802.11e EDCA, while IEEE 1609.4 manages channel coordination and supports MAC service data unit delivery. IEEE 802.11p proposed a multichannel operation so that physical layer consists of seven 10 MHz channels where one of them is control channel (CCH), used for safety communications, and the remaining are called service channels (SCHs), and they are used for nonsafety applications, shown in Figure 21.2.

K22422_C021.indd 578

7/9/2014 11:23:00 PM

579

Performance Evaluation of Realistic Vehicular Networks Control channel Service channels High availability/low latency Primarily public safety high-power applications

Optional 20 MHz

5.925

5.920

Ch 184 5.915

Ch 182 5.905

5.900

Ch 180 5.895

5.890

Ch 178 5.885

5.880

Ch 176 5.875

5.865

5.860

5.855

5.870

Ch 174

Ch 172

5.910

Optional 20 MHz

Frequency (GHz)

Figure 21.2 DSRC frequency plan.

Table 21.1 Different Application Categories in IEEE 802.11p AC Video traffic (AC3) Voice traffic (AC2) Best effort (AC1) Background (AC0)

CWmin

CWmax

AIFSN

3 3 7 15

7 7 225 1023

2 3 6 9

An orthogonal frequency division multiplexing modulation scheme is used to multiplex data, similarly to the IEEE 802.11a standard. However, the bandwidth that is used in each channel by IEEE 802.11p is half of the bandwidth used in the IEEE 802.11a. The MAC layer follows the same approach as used by IEEE 802.11e EDCA in order to provide QoS support. The EDCA mechanism defines four different access categories (ACs) for each channel compared to just one in IEEE 802.11. Different ACs provide different access priorities, and based on that, they are assigned different contention parameters. For example, AC3, which has the highest priority when accessing medium, has the lowest arbitrary IFS (AIFS) and CW values, whereas AC0, which has the lowest priority, has the highest values. Table 21.1 shows the default parameters settings used in IEEE 802.11p for different traffic types. Then, there are six SCHs and one CCH, and each of them has four different ACs. So, there are two contention procedures including internal contentions between different ACs in each channel, and the contention between channels to access the medium.

21.3 Alternatives to IEEE 802.11p for Vehicular Environments The current IEEE 802.11p standard, which applies to communication in wireless vehicular environments, does not propose an explicit mechanism in order to dynamically adapt the CW size based on the network density. Research results focusing on IEEE 802.11p performance show a lack of scalability, meaning that the CW size, which is calculated by the current static approach, is not optimal and causes more collisions as the network density increases. To solve this problem in IEEE 802.11-based MAC protocols, some schemes [14–17] have been proposed based on network density estimation and then the CW size is selected based on that

K22422_C021.indd 579

AQ4

7/9/2014 11:23:01 PM

580


network density estimation. The AOB mechanism [14] measures the network contention level by using two simple values: the slot utilization, and the average size of transmitted frames, based on the information provided by the carrier sensing mechanism. In [15], a three-level estimator is used for computing the optimal CW size, and in [16], a method was proposed to estimate the number of active nodes by means of a Kalman filter to optimize the CW size. Also, in [17], a novel access method was proposed called idle sense to adjust the CW size based on the network load. The CW is derived after measuring the number of idle slots between two transmission attempts and comparing it with the optimal number, which is equal to 5.68 for IEEE 802.11b. Considering the high overhead of these methods to estimate the network density, these approaches are not highly acceptable in ad hoc networks where power and memory resources are restricted. In order to avoid the high overhead of density estimation, other schemes [18–21] introduce static mechanisms to optimize CW size selection instead of harshly changing the CW size by resetting it to the minimum value (or doubling it) upon a successful or unsuccessful transmission, respectively. For example, the MILD scheme [18] increases the CW size by multiplying it by 1.5 and decreasing the CW size by 1 unit. In [19], when the retry counter reaches the limit, the CW is not rest to the minimum CW. After a successful transmission, CW is set to the value max[CW/2, CWmin+1], and upon a transmission failure, CW is set to the value min[2CW, CWmax+1]. EIED, which is proposed in [20], modifies the performance of BEB and MILD under low traffic conditions. The EIED scheme is based on an exponential distribution for both increasing and decreasing the CW size. In [21], the new scheme is proposed, which, following a successful transmission, reduces the CW to a value near the old one based on some factor that is evaluated during simulation. While these schemes work better than the BEB algorithm for high-density networks, the basic problem remains since the static behavior persists, and so it cannot adapt to different network densities. To fill the gap between the two aforementioned groups of methods, a low-overhead and dynamic solution called HBCWC is proposed in [49]. This algorithm does not need complex computation to estimate the network density. Instead, HBCWC obtains the network density information by observing the channel status, and it dynamically adapts the CW size based on the channel condition history. It shows a significant improvement in the presence of high network densities, while not requiring significant changes to the original IEEE 802.11 MAC. To the best of our knowledge, very few studies address this subject. A fuzzy logic-based enhanced 802.11p mechanism is proposed in [50], which adapts the CW size based on a nonlinear control law, which relies on channel observation. Also, in [51], DBM-ACW was proposed in order to improve the performance of IEEE 802.11p by adapting the CW size based on network density for unicast communications. It proposes a new scheme that allows selecting the CW size based on the network traffic density. In this scheme, the channel conditions are observed based on the packet transmission status, and the result is stored into a channel state (CS) vector. If the transmitter receives an ACK frame from the receiver, a value of 1 is inserted into the CS vector. Otherwise, if a collided/faulty frame is received, or if the transmitter waiting timer expires before receiving the acknowledgment, a value of 0 is inserted into the CS vector. The CS vector is updated by shifting before setting the CS 0 value. In DBM-ACW, upon each packet loss, timer expiration, or collision, the CW size is multiplied by 2 in order to obtain the highest PDR, except for the case in which the CS array contains two consecutive ones before the new state; that particular situation means that we observed two successful transmissions before detecting an unsuccessful transmission. In that case, the CW is multiplied by parameter A. Also, the CW size is set to the minimum CW, CWmin, upon each acknowledgment reception, except for the case in which the CS array contains two consecutive zeroes before the new state, which means that two unsuccessful transmissions are observed before detecting a successful transmission. In that case, the CW is multiplied by parameter B. The value of parameters A and B was set to 1.7 and 0.8, respectively.

K22422_C021.indd 580

7/9/2014 11:23:01 PM


581

Up to now, we have introduced background information about vehicular networks and some proposed MAC layer protocols for vehicular environments. In the following sections, we first define the simulation settings and the generated traffic loads in our scenarios. Then, we evaluate the performance of the aforementioned MAC protocols in the proposed vehicular scenarios.

21.4 Simulation Requirements This section introduces briefly the OMNET++ network simulator, stating how it must be configured in order to be used for vehicular network simulation. Then, traffic simulation methods and the SUMO traffic simulator are presented. Finally, we illustrate how to connect these two simulators to achieve a realistic vehicular network simulation.

21.4.1 Network Simulation (OMNET++) Each model in OMNeT++ is composed of reusable components termed modules. OMNET++ allows users to use two types of components: simple and compound modules. The functionality of each simple module is defined by C++ code, and it uses a simulation library. These simple modules can be combined unlimitedly like LOGO blocks to make compound modules. Simple modules can be connected with links, which connect two gates of two different modules to each other. Gates are input and output interfaces of modules. Connections are created within a single level of module hierarchy. Connections spanning different hierarchy levels are not permitted, as they would prevent model reuse. Modules communicate with each other through messages, which carry arbitrary data. Messages travel through a chain of connections, starting and arriving in simple modules. Messages can contain some information from other modules or be sent to the same module (self-messages) in order to implement a timer. Some of the features of OMNET++ are as follows: • Possibility of designing modular simulation models, which can be combined and reused flexibly. • Composing models with any granular hierarchy. • Availability of extensive simulation libraries that include support for input/output, statistics, data collection, random number generation, and data structures. • C++-based simulation kernel, which allows using it in larger applications. • Graphical-based simulation configuration using NED and omnetpp.ini without requiring the use of scripts. The main problems of this simulator in order to be a suitable simulator for VANETs are lack of models for wireless networks and the lack of integrated mobility manager. Therefore, a mobility manager and a framework in order to support models for wireless communications must be installed to provide these key functionalities when attempting to achieve a realistic VANET simulation environment. We chose this simulator coupled with the INETMANET framework and SUMO in order to provide a realistic vehicular scenario. The INETMANET framework provides detailed models for simulating wireless networks in OMNeT++ such as wireless channels, connectivity, mobility, and MAC layer protocols. Also, SUMO is used to generate real vehicular traffic in road networks. In summary, for each simulation using OMNeT++, the following parts must be described:

1. Simple modules (provided by some packages like INETMANET, MiXiM, etc.) 2. Topology (using NED files) 3. Simulation configuration (using omnetpp.ini)

K22422_C021.indd 581

7/9/2014 11:23:01 PM

582


21.4.1.1 INETMANET INETMANET is an open-source package that provides network simulation models for OMNET++. Although it focuses on the high level of the protocol architecture for wired and wireless communications, it also includes MAC layer protocols similar to IEEE 802.11p. Another option is to use this package in conjunction with the MiXiM package. MIXIM implemented detailed wireless NICs, so using these two packages together introduces detailed implementation at all levels of the protocol architecture.

AQ5

21.4.1.2 Scenario Definition Using NED Files We use the INETMANET framework in order to be able to use different network protocols, but in order to connect and make a node structure in OMNET++, NED files and omnetpp.ini are used. We generated two NED files, one for building a node (vehicle) and the other one for network scenario description. Each NED file includes four parts: parameters, gates, submodules, and connections (Figure 21.3). The parameters and gates sections are optional, and they can be left out if there is no gate or parameter. In the submodule section, we defined simple modules, and the connection section describes how these simple modules must be connected in order to build an architecture. 21.4.1.3 omnetpp.ini File Each simple module defines some parameters to customize its behavior. These parameters can be assigned in either the NED files or the configuration file, omnetpp.ini. In Figure 21.4, you can find that a reduced version of the omnetpp.ini file is used for simulation. When the program is executed in OMNET++, it first reads all the NED files in order to build the network topology, and then it uses omnetpp.ini for extracting the settings to control the simulation execution. In omnetpp.ini example, the simulation is repeated 10 times, and each time it takes 300 s and adapts different seeds. The output results are written into output files including in both vectorial and scalar formats. Notice that, at the application layer, the destination address is randomly chosen from the list of current nodes using “random_name(host)” or “moduleListByPath(“**.host[*]”).”

Figure 21.3 NED file.

K22422_C021.indd 582

7/9/2014 11:23:01 PM


583

Figure 21.4 omnetpp.ini file.

21.4.2 Traffic Simulation Traffic flow simulations can be divided into three groups depending on the level of details. In macroscopic traffic models, the flow is assumed as the basic entity. The next group includes microscopic traffic models in which more details are implemented, so that vehicles are the smallest entities. This type of traffic models is common in vehicular network simulations. The last group includes submicroscopic traffic models in which the inner parts of each vehicle are also implemented, including engine, gearbox, and so on. However, since this type of traffic models requires too high computational overhead, they are not considered as a suitable option for large-scale network simulations, like VANETs. 21.4.2.1 SUMO SUMO uses a microscopic traffic flow model that allows defining three types of elements: vehicle types, trips, and routes. A vehicle type specifies physical properties of a typical vehicle in the simulator. A trip defines the departure time and the destination edge, while route expands trip by defining all the edges through which a vehicle will pass. In general, we provide different files in SUMO in order to define the simulation map, the obstacles, and the routes used. To provide a simulation map, we extract the map from openstreetmap.org [52] in osm version. To import the extracted map into SUMO, it must be converted into an xml file by the NETCONVERTER [53] application. Also, routes are generated by the DUAROUTER [54] application using the shortest path algorithm. DUAROUTER requires the xml file already generated by the NETCONVERTER application, and it takes into account several data such as street length, speed limit, lane count, and street type for the shortest path computation. To make a more realistic simulation, buildings, city furniture, trees, or other obstacles can also be added through the POLYCONVERT [55] application in SUMO.

K22422_C021.indd 583

7/9/2014 11:23:01 PM

584


In conclusion, to prepare mobility traces for network simulation using SUMO, the following steps must be followed:

1. Create a road network file (using NETCONVERTER). 2. Extract the map from openstreetmap.org. 3. Generate random trips (using randomTrips.py). 4. Convert the trips into routes and traffic flows (using DUAROUTER). 5. Generate an obstacles file (using POLYCONVERT). 6. Create a configuration file.

After following these steps, the configuration file, which includes the road network file, the routes file, the simulation time steps, as well as begin-and-end simulation times, is used in order to introduce mobility in network simulation experiments.

21.4.3 Traffic Control Interface As described earlier, OMNET++ does not have any integrated mobility manager components, so we propose using Veins, which is an open-source intervehicular communication simulation framework that integrates both OMNET++ and SUMO. In order to allow SUMO to control traffic mobility during the simulation, it connects both elements through the Traffic Control Interface (TraCI) interface [56]. TraCI opens a TCP connection at port 9999 between both simulators, so that the simulators can interact with using a series of commands (e.g., speed, position) in small time steps. The vehicle and mobility generation are handled by SUMO. However, when a vehicle reaches its destination in SUMO, it must leave the simulation, and so we cannot ensure a constant number of vehicles throughout the entire simulation time. Therefore, the VACaMobil [57] tool is used to handle this issue, inserting new vehicles in the simulation when other vehicles leave it, thereby maintaining the same number of vehicles throughout the simulation time. In our experiments, the number of nodes varies from 50 to 200.

21.5 Case Study This section presents OMNET++ simulation results illustrating the performance of the MAC protocols under analysis according to the simulation setup explained in the previous sections. In order to simulate these MAC protocols in vehicular environments, we used both urban and highway scenarios, which are described in this section, and also the simulation parameters defined in Section 21.5.2.

21.5.1 Simulation Scenarios 21.5.1.1 Urban Scenario In contrast to highway scenarios, where vehicles always drive in a same direction, and where obstacles are mostly nonexistent, urban scenarios not only offer more flexibility in terms of mobility but also introduce more obstacles like buildings, vehicles, and urban furniture. This issue leads to lower transmission ranges for urban scenarios. As a representative urban vehicular environment, we will focus on an area of 1500 × 1500 m2 that is extracted by using digital maps, freely available in OpenStreetMap, from the downtown area of Valencia (Spain) and integrating real obstacles. Figure 21.5 shows two map views: the OpenStreetMap view and the SUMO view. 21.5.1.2 Highway Scenario The highway scenario models a 4 km highway with three lanes, where the lane width is 3 m. As assumed in the previous section, the destination is randomly chosen, so it can be a car ahead or behind of the transmitter. In order to model a realistic scenario, we assumed that vehicles can be

K22422_C021.indd 584

7/9/2014 11:23:01 PM

585


Openstreetmap view

SUMO view

Figure 21.5 Map layout for urban scenario (Valencia, Spain).

Table 21.2 Vehicle Types Vehicle Type Fast Normal Slow

Accel (ms-2)

Decel (ms-2)

Driver Imperfection

Max Speed (ms-1)

Probability (%)

4 2 2

6 4 4

0.2 0.3 0.5

36 28 20

10 80 10

4 km

3m

Figure 21.6 Map layout for highway scenario.

selected based on a normal distribution from three different categories that are summarized in Table 21.2. Driver imperfection is selected in the range from zero to one. Also, vehicles are injected in the highway according to a Poisson process with a mean interval time of 2 s, where the best lane is assigned to each vehicle. In contrast to the urban scenario, the transmission rate is 2 packets per second in this scenario. Figure 21.6 depicts the highway scenario.

21.5.2 Simulation Parameters and Metrics The general simulation parameters are as follows: each vehicle generates constant bit rate traffic using UDP datagrams (we chose UDP and not TCP for the same reasons stated in [12]). The 512byte datagrams were transmitted at a rate of 4 packets per second. Considering the routing protocol, we assessed different routing protocols (i.e., AODV, OLSR, DYMO, DSR), and despite the different overall performance level obtained by these protocols, they have the same impact on the different MAC protocols evaluated in this chapter. Thus, the results

K22422_C021.indd 585

7/9/2014 11:23:02 PM

586


Table 21.3 Simulation Parameters Simulation Parameter Traffic type CBR packet size CBR data rate Transport protocol Routing protocol MAC protocol Max. and min. of CW Max. number of retransmissions Max. queue size RTS/CTS threshold Slot time Max. transmission range Propagation model Nakagami-m Simulation time Number of repetitions

Value CBR 512 byte 4 packet/s UDP AODV 802.11p, HBCWC, DBM-ACW 7, 1023 7 14 2346 byte 13 µs 250 m Nakagami 0.7 300 s 10

presented in this chapter are obtained using the AODV routing protocol; notice that, since several researchers use this protocol as well, it makes comparison against other proposals easier. We used the Nakagami radio propagation model, commonly used by the VANET community, in order to achieve a more realistic signal propagation model for vehicular environments [58]. Parameter m for this propagation model is set to 0.7. Table 21.3 summarizes the simulation parameters. The metrics used to evaluate the performance of the MAC solutions under study were similar to those used in previous studies. They are summarized as follows: (1) PDR, which represents the ratio of the total number of packets received by the final destination and the packets originated by the source; (2) average end-to-end delay, which represents the average time required for a packet to travel from source to destination; (3) standard deviation of end-to-end delay, which shows how much variation exists from the average end-to-end delay; and (4) average MAC collisions, which shows the average number of collisions experienced per source.

21.5.3 Urban In this first experiment, we evaluate DBM-ACW, HBCWC, and IEEE 802.11p in an urban scenario using V2V communications. Since we are interested in high-congestion environments, we define a large number of connections, so that each vehicle, immediately after joining the network, starts a new connection and maintains it active until the destination leaves the network. When this occurs, a new destination will be chosen by the transmitter. This experiment represents a stressing situation for a MAC protocol due to the large number of simultaneous connections. Thus, the experimental setup is adequate to assess how these protocols are able to overcome a high number of collisions to obtain a suitable throughput. Figure 21.7 shows the PDR when varying the number of source nodes. This figure shows poor performance of IEEE 802.11p in vehicular environments, which achieves the lowest performance compared to the other solutions analyzed: DBM-ACW and HBCWC. As it is mentioned in the previous chapter, IEEE 802.11/802.11p do not introduce any solution for the dynamic adaptation of CW, and also the CW is reset to CWmin upon each successful transmission, which causes a critical problem. As a result, the PDR for IEEE 802.11p shows faster decreases than alternative protocols when increasing the number of nodes. DBM-ACW, which is specially designed for vehicular

K22422_C021.indd 586

7/9/2014 11:23:02 PM

587

Performance Evaluation of Realistic Vehicular Networks 35

DBM-ACW HBCWC IEEE802.11p

PDR (%)

30 25 20 15 10 50

75

100 125 150 Number of nodes

175

200

Figure 21.7 PDR for the urban scenario.

environments, outperforms both IEEE 802.11p and HBCWC. We can observe that the improvement ratio for DBM-ACW in high-density networks (more than 100 nodes) is higher than for low-density networks. This stems from the fact that DBM-ACW avoids resetting the CW to the minimum value and mostly maintains the average CW size at high values in the presence of frequent collisions. Therefore, it is able to decrease the number of dropped packets, but under low densities, when the collision frequency is low, the degree of efficiency is not comparable to high-density situations. Also, HBCWC shows a good performance because it also estimates the network density to choose the optimal CW size. However, the results show that resetting the CW size upon a successful transmission, like 802.11p and HBCWC, has a significant cost in terms of PDR. The average number of MAC collisions, shown in Figure 21.8, offers a hint on how to achieve improvements in terms of PDR. As can be observed in this figure, DBM-ACW shows that the

Average MAC collisions per vehicle

70,000

50,000

30,000


10,000 0 50

75


175

200

Figure 21.8 Average number of collisions for the urban scenario.

K22422_C021.indd 587

7/9/2014 11:23:02 PM

588


Average end-to-end delay (s)

0.50

0.40

0.30 DBM-ACW HBCWC IEEE802.11p

0.20 50

75


175

200

Figure 21.9 Average end-to-end delay for the urban scenario.

optimal CW was chosen so that it decreases the probability of picking the same backoff value, and consequently the number of collisions. One of the key differences between IEEE 802.11p and DBM-ACW is that 802.11p resets the CW size to the minimum value when the retransmission limit is reached, without taking into account that this event is possibly associated to channel collisions; thus, it assigns a minimum CW size for the next packet. Considering this behavior, one can expect that the new packet will experience fewer success changes in order to be sent and will also need more retransmissions on average. Therefore, by avoiding to reset the CW size in this situation, DBM-ACW achieves lower end-to-end delay than IEEE 802.11p, as shown in Figure 21.9. As we expected, the end-to-end delay increases for IEEE 802.11p under high densities, but the alternative solutions does not follow the same trend as 802.11p. They show a higher bound for delay so that, as the network density increases, the average end-to-end delay values remain low, fluctuating at values close to 0.35 s, as shown in Figure 21.9. Therefore, in this way, they improve the scalability of IEEE 802.11p, which represents an important challenge in VANETs. Moreover, Figure 21.9 evidences the difference between DBM-ACW and HBCWC, which is further clarified in Table 21.4. In particular, DBM-ACW avoids resetting the CW size for the case in which it observes two consecutive successful transmissions before detecting an unsuccessful transmission. As a result, it is able to achieve improvements in terms of end-to-end delay, as well as improved standard deviation of delays for DBM-ACW compared to HBCWC. In HBCWC, a few packets are sent with very low delay, and this decreases the total end-to-end delay, while in DBMACW, most packets experience a similar delay.

Table 21.4 Standard Deviation of Delays for the Urban Scenario DBM-ACW HBCWC

K22422_C021.indd 588

50

75

100

125

150

175

200

0.42 0.44

0.45 0.44

0.46 0.48

0.47 0.50

0.49 0.55

0.52 0.54

0.53 0.53

7/9/2014 11:23:03 PM

589


21.5.4 Highway In the assumed highway scenario, the number of collisions is lower than in the urban scenario (due to the lower transmission rate), depicted in Figure 21.10. This figure shows that IEEE 802.11p has the highest number of collisions when compared to the alternative solutions. Among them, DBMACW introduces more improvement ratios under high densities than HBCWC. Consequently, DBM-ACW cannot achieve a high improvement ratio compared to HBCWC in terms of PDR under lower densities, as depicted in Figure 21.11. However, for high densities, DBM-ACW achieves a higher improvement ratio compared to HBCWC when simultaneously considering both the PDR and the number of collisions. While DBM-ACW shows a lower improvement ratio

AQ6

Average MAC collisions per vehicle

50,000

40,000

30,000

20,000 DBM-ACW HBCWC IEEE802.11p

10,000 0.4

0.5 0.6 0.7 0.9 0.8 Probability of sending message

1

Figure 21.10 Average number of collisions for the highway scenario.

45


PDR (%)

40

35

30

25 0.4

0.5

0.6

0.7

0.8

0.9

1

Probability of sending message

Figure 21.11 PDR for the highway scenario.

K22422_C021.indd 589

7/9/2014 11:23:03 PM

590


Average end-to-end delay (s)

0.45


0.40 0.35 0.30 0.25 0.20 0.4

0.5

0.6

0.7

0.8

0.9

1

Probability of sending message

Figure 21.12 Average end-to-end delay for the highway scenario.

when compared with the urban scenario, it still shows better results than HBCWC and IEEE 802.11p considering the PDR and the number of collisions. In terms of end-to-end delay, there is a big gap between IEEE 802.11p and the other alternatives, as shown in Figure 21.12. Also, while IEEE 802.11p has an increasing trend, DBM-ACW and HBCWC show a decreasing trend, meaning that it does not increase the delay when the number of connections increases, as desired. Figure 21.12 shows that HBCWC achieves slightly better delay when compared with DBM-ACW. However, DBM-ACW achieves a better trade-off between PDR and end-to-end delay, meaning that the total PDR improvement ratio is higher than the delay degradation ratio when compared with HBCWC.

21.6 Conclusions The CSMA-based MAC technique, and in particular the IEEE 802.11p protocol, is the method of choice for the current generation of VANETs. Although this scheme has its merits, it suffers from scalability problems in dynamic environments with a high node density, like vehicular environments, which affect its performance. In this chapter, we demonstrate the impact of the CW adjustment on the overall performance of unicast communications in VANETs. For these purposes, we evaluate the performance of three different MAC protocols: DBM-ACW, HBCWC, and IEEE 802.11p in two different vehicular scenarios including urban and highway. We clearly detailed the procedures to follow in order to properly compare these protocols through simulation, and also we selected the best network and vehicular traffic simulators to make a realistic vehicular environment. Extensive simulation results prove that IEEE 802.11p is not able to offer optimal performance in different congestion states, and for both urban and highway scenarios, we find that alternatives able to dynamically adapt the CW size according to channel conditions are a better choice, allowing to improve the PDR and the end-to-end delay for different vehicular environments.

Acknowledgments This work was partially supported by the Ministerio de Ciencia e Innovación, Spain, under Grant TIN2011-27543-C03-01.

K22422_C021.indd 590

7/9/2014 11:23:03 PM


591

References

1. H. Hartenstein and K.P. Laberteaux, A tutorial survey on vehicular ad hoc networks, Communications Magazine, IEEE, 46 (6), 164–171, June 2008. 2. M.J. Booysen, S. Zeadally, and G.-J. van Rooyen, Survey of media access control protocols for vehicular ad hoc networks, Communications, IET, 5 (11), 1619–1631, July 22, 2011. 3. J. Kenney, Standards and regulations, in H. Hartenstein and K.P. Laberteaux (eds.), VANET: Vehicular Applications and Inter-Networking Technologies, Wiley, Chichester, U.K., Chapter 10, pp. 365–428, 2010. 4. B. Clifford Neuman, Scale in distributed systems, in T.L. Casavant and M. Singhal (eds.), Readings in Distributed Computing Systems, IEEE Computer Society Press, Los Alamitos, CA, 1994. 5. F. Bai, T. Elbatt, G. Hollan, H. Krishnan, and V. Sadekar, Towards characterizing and classifying communication-based automotive applications from a wireless networking perspective, First IEEE Workshop on Automotive Networking and Applications (AutoNet), San Francisco, CA, 2006. 6. 802.11p-2010, IEEE Standard for Information Technology—Telecommunications and Information Exchange between Systems—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, Institute of Electrical and Electronics Engineers, New York, pp. 1–51, July 2010. 7. S. Asadallahi and H.H. Refai, Modified R-ALOHA: Broadcast MAC protocol for vehicular ad hoc networks, Wireless Communications and Mobile Computing Conference (IWCMC), 2012 Eighth International, Limassol, Cyprus, pp. 734–738, August 27–31, 2012. 8. H. Omar, W. Zhuang, and L. Li, VeMAC: A TDMA-based MAC protocol for reliable broadcast in VANETs, Mobile Computing, IEEE Transactions on, 12 (9), 1724–1736, 2013. doi:10.1109/TMC.2012.142. 9. S.-S. Wang, H.-C. Chen, and J.-K. Chang, A distributed adaptive MAC protocol for efficient broadcasting in vehicular ad hoc networks, Wireless Communications and Networking Conference (WCNC), 2012 IEEE, Paris, France, pp. 1555–1560, April 1–4, 2012. 10. R. Stanica, E. Chaput, and A.-L. Beylot, Enhancements of IEEE 802.11p protocol for access control on a VANET control channel, Communications (ICC), 2011 IEEE International Conference on, Kyoto, Japan, pp. 1–5, June 5–9, 2011. 11. M. Wellens, B. Westphal, and P. Mahonen, Performance evaluation of IEEE 802.11-based WLANs in vehicular scenarios, Vehicular Technology Conference, 2007. VTC2007-Spring. IEEE 65th, Dublin, Ireland, pp. 1167–1171, April 22–25, 2007. 12. D.N. Cottingham, I.J. Wassell, and R.K. Harle, Performance of IEEE 802.11a in vehicular contexts, Vehicular Technology Conference, 2007. VTC2007-Spring. IEEE 65th, Dublin, Ireland, pp. 854–858, April 22–25, 2007. 13. J. Jansons and A. Barancevs, Using wireless networking for vehicular environment: IEEE 802.11a standard performance, Digital Information Processing and Communications (ICDIPC), 2012 Second International Conference on, Klaipeda, Lithuania, pp. 5–9, July 10–12, 2012. 14. L. Bononi, M. Conti, and E. Gregori, Runtime optimization of IEEE 802.11 wireless LANs performance, Parallel and Distributed Systems, IEEE Transactions on, 15 (1), 66–80, January 2004. 15. F. Cali, M. Conti, and E. Gregori, Dynamic tuning of the IEEE 802.11 protocol to achieve a theoretical throughput limit, Networking, IEEE/ACM Transactions on, 8 (6), 785–799, December 2000. 16. G. Bianchi and I. Tinnirello, Kalman filter estimation of the number of competing terminals in an IEEE 802.11 network, INFOCOM 2003. 22nd Annual Joint Conference of the IEEE Computer and Communications. IEEE Societies, San Francisco, CA, vol. 2, pp. 844–852, March 30–April 3, 2003. 17. M. Heusse, F. Rousseau, R. Guillier, and A. Duda, Idle sense: An optimal access method for high throughput and fairness in rate diverse wireless LANs, ACM SIGCOMM, Philadelphia, PA, 2005. 18. V. Bharghavan, A. Demers, S. Shenker, and L. Zhang, MACAW: A media access protocol for wireless LANs, Proceedings of ACM SIGCOMM 1994, London, U.K., pp. 212–225, 1994. 19. H. Wu, S. Cheng, Y. Peng, K. Long, and J. Ma, IEEE 802.11 distributed coordination function (DCF): Analysis and enhancement, Communications, 2002. ICC 2002. IEEE International Conference on, New York, vol. 1, pp. 605–609, 2002. 20. N.-O. Song, B.-J. Kwak, J. Song, and M.E. Miller, Enhancement of IEEE 802.11 distributed coordination function with exponential increase exponential decrease backoff algorithm, Vehicular Technology Conference, 2003. VTC 2003-Spring. The 57th IEEE Semiannual, Orlando, FL, vol. 4, pp. 2775–2778, April 22–25, 2003.

K22422_C021.indd 591

7/9/2014 11:23:03 PM

592

AQ7


21. Q. Ni, I. Aad, C. Barakat, and T. Turletti, Modeling and analysis of slow CW decrease IEEE 802.11 WLAN, Personal, Indoor and Mobile Radio Communications, 2003. PIMRC 2003. 14th IEEE Proceedings on, Beijing, China, vol. 2, pp. 1717–1721, September 7–10, 2003. 22. The Network Simulator—ns-2, http://www.isi.edu/nsnam/ns/. 23. T. Camp, J. Boleng, and V. Davies, A survey of mobility models for ad hoc network research, Wireless Communications & Mobile Computing: Special Issue on Mobile Ad Hoc Networking: Research, Trends and Applications, 2 (5), 483–502, 2002. 24. A. Mahajan, N. Potnis, K. Gopalan, and A. Wang, Evaluation of mobility models for vehicular ad-hoc network simulations, Technical Report N. 051220, Florida State University, Tallahassee, FL, pp. 1–13, 2005. 25. M. Treiber, A. Hennecke, and D. Helbing, Congested traffic states in empirical observations and microscopic simulations, Physical Review E, 62 (2), 1805–1824, 2000. 26. OMNeT++ home page, http://www.omnetpp.org accessed on November 2012. 27. INETMANET home page, http://inet.omnetpp.org/accessed on November 2012. 28. MiXiM home page, http://mixim.sourceforge.net/accessed on November 2012. 29. C. Sommer, D. Eckhoff, R. German, and F. Dressler, A computationally inexpensive empirical model of IEEE 802.11p radio shadowing in urban environments, Technical Report CS-2010-06, University of Erlangen, Department of Computer Science, Erlangen, Germany, September 2010. 30. The Network Simulator—ns-3, http://www.nsnam.org/. 31. Scalable Networks Technologies—QualNET Simulator, http://www.scalable-networks.com/products/ qualnet/. 32. E. Giordano, R. Frank, G. Pau, and M. Gerla, CORNER: A step towards realistic simulations for VANET, Proceedings of the Seventh ACM International Workshop on Vehicular Internetworking, Chicago, IL, pp. 41–50, September 2010. 33. Java in Simulation Time—Scalable wireless ad hoc network simulator, http://jist.ece.cornell.edu/. 34. Corridor Simulation (CORSIM)—Microscopic traffic simulation model, http://mctrans.ce.ufl.edu/ featured/tsis/Version5/corsim.htm. 35. Verkehr In Stadten SIMulationsmodell (VISSIM), http://www.vissim.de. 36. F. Karnadi, Z. Mo, and K. Lan, Rapid generation of realistic mobility models for VANET, Proceedings of the IEEE Wireless Communications and Networking Conference, Kowloon, Hong Kong, pp. 2506–2511, March 2007. 37. M. Behrisch, L. Bieker, J. Erdmann, and D. Krajzewicz, SUMO—Simulation of urban mobility: An overview. SIMUL 2011, The Third International Conference on Advances in System Simulation, Barcelona, Spain, 2011. 38. M. Fiore, J. Haerri, F. Filali, and C. Bonnet, Vehicular mobility simulation for VANETs, Proceedings of the 40th Annual Simulation Symposium, Norfolk, VA, pp. 301–309, March 2007. 39. CANU mobility simulation environment, http://canu.informatik.uni-stuttgart.de/mobisim/. 40. M. Treiber and A. Kesting, Modeling lane-changing decisions with MOBIL, Proceedings of the Traffic and Granularity Flow Conference, Paris, France, pp. 211–221, June 2007. 41. Veins home page, http://veins.car2x.org/accessed on November 2012. 42. M. Piorkowski, M. Raya, A. Lezama Lugo, P. Papadimitratos, M. Grossglauser, and J.-P. Hubaux, TraNS—Realistic joint traffic and network simulator for VANETs, ACM SIGMOBILE Mobile Computing and Communications Review, 12 (1), pp. 31–33, January 2008. 43. iTetris Project, http://www.ict-itetris.eu/. 44. N. Naumann, B. Schuenemann, and I. Radusch, VSimRTI—Simulation runtime infrastructure for V2X communication scenarios, Proceedings of the 16th World Congress and Exhibition on Intelligent Transport Systems and Services, Stockholm, Sweden, pp. 1–10, September 2009. 45. R. Mangharam, D. Weller, R. Rajkumar, P. Mudalige, and F. Bai, GrooveNet: A hybrid simulator for vehicle-to-vehicle networks, Proceedings of the Third Annual International Conference on Mobile and Ubiquitous Systems—Workshops, San Jose, CA, pp. 1–8, July 2006. 46. NCTUns 6.0, http://nsl.csie.nctu.edu.tw/nctuns.html. 47. B. Jarupan, Y. Balcioglu, E. Ekici, F. Ozguner, and U. Ozguner, An integrated wireless intersection simulator for collision warning systems in vehicular networks, Proceedings of the IEEE International Conference on Vehicular Electronics and Safety, Columbus, OH, pp. 340–345, September 2008. 48. ANSI/IEEE Std 802.11, 1999 Edition (R2003), IEEE Standard for Information Technology— Telecommunications and Information Exchange between Systems—Local and Metropolitan Area Networks- Specific Requirements—Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, Institute of Electrical and Electronics Engineers, New York, pp. i–513, 2003.

K22422_C021.indd 592

7/9/2014 11:23:03 PM


593

49. A. Balador, A. Movaghar, and S. Jabbehdari, History based contention window control in IEEE 802.11 MAC protocol in error prone channel, Journal of Computer Science, 6 (2), 205–209, 2010. 50. C. Chrysostomou, C. Djouvas, and L. Lambrinos, Applying adaptive QoS-aware medium access control in priority-based vehicular ad hoc networks, Computers and Communications (ISCC), 2011 IEEE Symposium on, Corfu, Greece, pp. 741–747, June 28–July 1, 2011. 51. A. Balador, C.T. Calafate, J. Cano, and P. Manzoni, Reducing channel contention in vehicular environments through an adaptive contention window solution, Wireless Days (WD), 2013 IFIP, Valencia, Spain, November 15–17, 2013. 52. OpenStreetMap, http://www.openstreetmap.org/ (accessed on November 2012). 53. SUMO NETCONVERTER application, http://sourceforge.net/apps/mediawiki/sumo/index. php?title=NETCONVERT (accessed on November 2012). 54. SUMO DUAROUTER application, http://sourceforge.net/apps/mediawiki/sumo/index. php?title=DUAROUTER (accessed on November 2012). 55. SUMO POLYCONVERT application, http://sourceforge.net/apps/mediawiki/sumo/index. php?title=POLYCONVERT (accessed on November 2012). 56. TraCI Modules, http://veins.car2x.org/documentation/modules/traci/ (accessed on November 2012). 57. M. Baguena, S. Tornell, A. Torres, C.T. Calafate, J.C. Cano, and P. Manzoni, VACaMobil: VANET car mobility manager for OMNeT++, IEEE International Conference on Communications 2013 Third IEEE International Workshop on Smart Communication Protocols and Algorithms (SCPA 2013), Budapest, Hungary, June 2013. 58. M. Baguena, C.T. Calafate, J. Cano, and P. Manzoni, Towards realistic vehicular network simulation models, Wireless Days (WD), 2012 IFIP, Dublin, Ireland, pp. 1–3, November 21–23, 2012.

Author Queries [AQ1] Please check if any word or phrase is missing in the part “less attention in than” after “in.” [AQ2] Please check the identified head levels for correctness. [AQ3] There are variations in the casing of a term as follows: “OMNeT” and “OMNET.” Please check [AQ4] Please check if the edit to the sentence “To solve this problem in IEEE 802.11-based ...” is ok. [AQ5] Please check the inserted citation of Figure 21.3 for correctness. [AQ6] Citation of Figures 21.11 and 21.10 have been changed to Figures 21.10 and 21.11 to maintain sequential order. Please check for correctness. [AQ7] Please provide accessed date for Refs. [22,30,31,33–35,39,41,43,46].

K22422_C021.indd 593

7/9/2014 11:23:03 PM

K22422_C021.indd 594

7/9/2014 11:23:03 PM