details of the integrated vissim-nctuns vehicular ... vehicular-wireless simulation platform ......

UNIVERSITY OF VIRGINIA

Details of the integrated

VISSIM-NCTUns vehicular-

wireless simulation platform

Adelin Miloslavov, Hyungjun Park, Joyoung Lee, Malathi Veeraraghavan, Byungkyu Park and Brian L. Smith

9/27/2010

This work was carried out as part of a sponsored researchproject from the US DOT FHWA grant no. DTFH61-10-H-00001.

Contents

VISSIM and NCTUns Integration .................................................................................................... 4

1.1 Overall idea ............................................................................................................................ 4

1.2 Simulated Protocols and Messages ........................................................................................ 5

1.3 Overview of applications included in the testbed .................................................................. 6

1.3.1 Windows side VISSIM driver program .......................................................................... 7

1.3.2 Linux side TCP connection program .............................................................................. 8

1.3.3 Linux side NCTUns car agent program .......................................................................... 8

1.4 Fixed number of vehicles per simulation in NCTUns ............................................................ 8

NCTUns Modification and Extension ............................................................................................ 10

2.1 Addition of the WSMP protocol .......................................................................................... 10

2.1.1 Unicast/Broadcast Support ............................................................................................ 10

2.1.2 Variable Message Size Support ..................................................................................... 10

2.1.3 MAC QoS Priority for WSMP ...................................................................................... 10

2.2 Measurement of latency ....................................................................................................... 10

2.3 Delegation of WSA messages to client applications ............................................................ 11

2.4 Optimizations ....................................................................................................................... 11

2.4.1 Automatic distance limits on messages ......................................................................... 11

2.4.2 Combining car agent processes into a single process instead of 1 process per car ....... 11

2.4.3 Removing CRC checks aimed at real applications ....................................................... 12

2.4.4 Turning off integrated features such as GUIs, logging and relaying ............................ 12

General Issues Related to Simulating DSRC using Networking and Transportation Simulators .. 13

3.1 Resolution of collision problems at the beginning of a channel interval ............................. 13

3.2 Use of Nakagami model to simulate small-scale fading ...................................................... 14

3.3 Types of messages simulated by the testbed ........................................................................ 16

3.3.1 Basic Safety Messages .................................................................................................. 16

3.3.2 Ala-carte Messages ....................................................................................................... 17

3.4 Simulation Parameters .......................................................................................................... 17

3.5 Simulation Run Time Issues and Optimizations .................................................................. 17

3.6 Retransmission Thresholds and Policies .............................................................................. 18

Findings Based on Performed Simulations .................................................................................... 20

4.1 Impact of number of vehicles on network performance....................................................... 20

4.2 Impact of distance on networking performance ................................................................... 20

4.3 Latency measurements of different messages ...................................................................... 21

References ...................................................................................................................................... 23

VISSIM and NCTUns IntegrationThe goal of this simulated testbed is to bring together the features of powerful networking

and transportation simulators in order to provide a suitable testing environment for networking applications. The simulation testbed is focused on incorporating existing and developing standards and technologies such as DSRC, the IEEE WAVE standards including 802.11p [4] and the IEEE 1609 [5][6standard [7]. In order to do that, the testbed integrates together a commersimulator (VISSIM), along with a modified opesingle synchronous system that simulates both the vehicular networking.

1.1 Overall idea

The testbed includes a variety of applications along with the two simulators in order to ensure that they are properly synchronized. Since NCTUns runs on Linux and VISSIM runsWindows, data transfer between the two simulators is performed over a TCP/IP connection in order to allow the simulators to run on separate machines.

The goal of the testbed is to examine the impact that vehicular networking applications would have on the immediate traffic environment. on the exchange of communication between them and many applications use communication in order to change the trajectory of the vehicles, it is not feasible to run the transcommunication simulations separately and then just combine the results. simulators need to be dynamically transferring data between each other while the simulation is running rather than post-processing data from previgoal, we have configured the testbed to run in the following sequence:

VISSIM and NCTUns Integration The goal of this simulated testbed is to bring together the features of powerful networking

and transportation simulators in order to provide a suitable testing environment for networking applications. The simulation testbed is focused on incorporating existing and developing standards and technologies such as DSRC, the IEEE WAVE standards including

[5][6] family of standards and the SAE J2735 message set . In order to do that, the testbed integrates together a commercial transportation

, along with a modified open-source networking simulator (NCTUnssingle synchronous system that simulates both the communication and transportation aspects of

The testbed includes a variety of applications along with the two simulators in order to ensure that they are properly synchronized. Since NCTUns runs on Linux and VISSIM runsWindows, data transfer between the two simulators is performed over a TCP/IP connection in order to allow the simulators to run on separate machines.

The goal of the testbed is to examine the impact that vehicular networking applications the immediate traffic environment. Since the trajectory of the vehicles has impact

on the exchange of communication between them and many applications use communication in order to change the trajectory of the vehicles, it is not feasible to run the transportation and communication simulations separately and then just combine the results. This means that the two simulators need to be dynamically transferring data between each other while the simulation is

processing data from previous simulation runs. In order to achieve this goal, we have configured the testbed to run in the following sequence:

The goal of this simulated testbed is to bring together the features of powerful networking and transportation simulators in order to provide a suitable testing environment for vehicular networking applications. The simulation testbed is focused on incorporating existing and developing standards and technologies such as DSRC, the IEEE WAVE standards including

message set cial transportation

NCTUns) into a and transportation aspects of

The testbed includes a variety of applications along with the two simulators in order to ensure that they are properly synchronized. Since NCTUns runs on Linux and VISSIM runs on Windows, data transfer between the two simulators is performed over a TCP/IP connection in

The goal of the testbed is to examine the impact that vehicular networking applications Since the trajectory of the vehicles has impact

on the exchange of communication between them and many applications use communication in portation and

This means that the two simulators need to be dynamically transferring data between each other while the simulation is

ous simulation runs. In order to achieve this

`

The choice of a 100ms interval as the simulation step duration was due to a number of considerations. First, 100ms is the duration of one interval during which each OBE switches between the control and service channels of operation (See 1.2 Simulated Protocols and Messages) [5]. In addition, since the position of a vehicle inside NCTUns is interpolated from the vehicle’s location at the beginning and at the end of an interval, the use of a small interval such as 100ms ensures good accuracy in the interpolated position of the vehicles inside the communication simulator. Moreover, 100ms is small enough to ensure that the changes that the traffic simulator institutes in its parameters are not delayed for a large period of time and are enforced immediately after an OBE receives a message. The downside of choosing a period as small as 100ms is the overhead that the testbed incurs since the two simulators often have to pause execution and wait for the other simulator to perform its tasks.

The overall idea behind the simulation testbed. The same 100ms period is simulated in both the transportation and the communication simulators and the results are exchanged

between the two.

1.2 Simulated Protocols and Messages

The simulated testbed follows the IEEE 1609 [5][6] family of standards, which describe the WAVE architecture necessary for vehicles to communicate in a multi-channel wireless vehicular environment in the DSRC band. The WAVE band is divided into 7 channels – a control channel, 4 service channels and 2 special-purpose safety channels. Each OBE is required to switch to the control channel for 50ms during every interval of 100ms. The control channel is used to announce applications available on the service channel and to carry important safety messages. After the 50ms control channel period ends, OBEs are allowed to switch to different

service channels or to remain listening to the guard interval that allows single channel OBEs to switch channels without missing any messages.

On top of the described multimessages to be passed using either IP in conjunction with UDP/TCP or using the Wave Short Message Protocol (WSMP), which was specifically designed for vehicular networking. Since TCP/IP messages are limited to certain formats and can only be sent on the service channels and a variety of simulated applicationsimulation testbed uses WSMP for all communication that is performed.

In conjunction with the WSMP protocol, the simulation testbed usesmessages described in the SAE J2735 standardSafety Message (BSM). The Ala Carte Messages or broadcast and are often used to carryMessages are used to broadcast vehicular information at regular intervals

The communication architecture that is simulated by the testbed

1.3 Overview of applications included in the testbed

The figure below shows the overall setup odifferent responsibilities in conjunction with the two simulators.

or to remain listening to the control channel. Each channel switch guard interval that allows single channel OBEs to switch channels without missing any messages.

On top of the described multi-channel architecture, the IEEE 1609 standardsng either IP in conjunction with UDP/TCP or using the Wave Short

Message Protocol (WSMP), which was specifically designed for vehicular networking. Since TCP/IP messages are limited to certain formats and can only be sent on the service channels and

ety of simulated applications require communication during the control channel, the simulation testbed uses WSMP for all communication that is performed.

In conjunction with the WSMP protocol, the simulation testbed uses two types of the SAE J2735 standard [7] – the Ala Carte Message (ACM) and the Basic

Safety Message (BSM). The Ala Carte Messages are used as messages that can be either unicast and are often used to carry important advisories for vehicles. The Basic Safetused to broadcast vehicular information at regular intervals (See section 3.3)


1.3 Overview of applications included in the testbed

the overall setup of the testbed. It incorporates 3 helper applications with different responsibilities in conjunction with the two simulators.

control channel. Each channel switch includes a guard interval that allows single channel OBEs to switch channels without missing any messages.

channel architecture, the IEEE 1609 standards [6] allow ng either IP in conjunction with UDP/TCP or using the Wave Short

Message Protocol (WSMP), which was specifically designed for vehicular networking. Since TCP/IP messages are limited to certain formats and can only be sent on the service channels and

require communication during the control channel, the

two types of the Ala Carte Message (ACM) and the Basic

be either unicast important advisories for vehicles. The Basic Safety

(See section 3.3).


f the testbed. It incorporates 3 helper applications with

The overall setup of the simulation testbed. The 3 helper applications in the middle synchronize the actions of the two simulators.

1.3.1 Windows side VISSIM driver program

The Windows side VISSIM driver program has a number of responsibilities. This program loads the files needed to run VISSIM and starts the simulator. Often times a VISSIM simulation starts with empty roads and needs a warm-up period, during which no communication is simulated but instead VISSIM runs individually for a small period of time in order to create more realistic traffic conditions. The Windows side driver program handles the warm-up period and other issues related to the setup of VISSIM.

In addition, the Windows side driver program is responsible for extracting needed vehicular data from VISSIM’s COM interface and running any vehicular network applications that use the data. This program collects data from both the vehicles and the communication simulator and supplies it to any algorithms and applications that require the data.

Finally, the Windows side driver program also handles the TCP/IP communication with NCTUns. It establishes the connection, sends vehicle trajectories and processes all data coming

from the NCTUns simulator and also translates the IDs of VISSIM vehicles to their corresponding IDs in NCTUns (See 1.4 Fixed number of vehicles per simulation in NCTUns).

1.3.2 Linux side TCP connection program

The Linux side TCP program is responsible for establishing a TCP/IP connection with the Windows side driver program. In addition, the TCP program receives all needed data from VISSIM and relays it to the NCTUns car agent program. After that, the TCP connection program signals the NCTUns program and waits for its response. After NCTUns is done with its 100ms simulation step, the TCP connection program sends the resulting message data back to the Windows side of the simulation testbed.

1.3.3 Linux side NCTUns car agent program

NCTUns supports the notion of agent programs, where simulation entities within the simulator are able to execute applications that generate network traffic. In addition, NCTUns runs directly on top of the Linux TCP/IP stack, which allows it to capture traffic from real networking applications. The simulation testbed uses an NCTUns agent program which generates the needed messages for the different OBEs and RSEs and sends them to the simulator. However, since this application runs within NCTUns, it cannot establish an independent TCP/IP connection with the Windows side of the testbed without being part of the simulation environment. Because of that it receives and sends all its information to the Linux side TCP connection program through the Linux file system.

The NCTUns car agent program has numerous responsibilities. It receives vehicle trajectory data from VISSIM and creates waypoints for the vehicles inside NCTUns to ensure that they follow the specified trajectory with the needed velocity. In addition, this program creates a schedule of all messages that need to be transmitted during each 100ms simulation interval and interrupts the simulation each time a message needs to be transmitted. Moreover, the car agent program collects the results from the messages that it sends, processes them and writes them to the filesystem so that they could be sent back to the Windows side of the simulation testbed.

1.4 Fixed number of vehicles per simulation in NCTUns

One of the issues related to conducting a vehicular simulation with NCTUns is the fact that it only supports a predetermined fixed number of vehicles per simulation. However, any transportation simulation is likely to include thousands of vehicles if its duration is large enough. The problem could be resolved in several ways, but most of these ways prove to be very inefficient. One way would be to calculate the total number of vehicles that would be present in the transportation simulation and create separate entities for each of those vehicles inside

NCTUns. However, the increased amount of vehicles impacts the performance of the communication simulator in a very negative way and makes it infeasible to run a large simulation. Another solution would be to run a new instance of NCTUns for each simulation step of 100ms since the number of vehicles that are present in the simulation area at any given time is significantly smaller. Unfortunately, this also runs into a performance problem since initiating a simulation in NCTUns takes a considerable period of time.

In order to resolve these issues, the simulation testbed employs a mechanism to reuse vehicles multiple times in order to ensure that all vehicles are simulated and the performance of the simulation is not impacted in a negative way. In order to do that, NCTUns is set up so that it contains a number of vehicles big enough to accommodate the maximum number of vehicles that can be present in the simulation area at any one time, but not much bigger than that. Because of that the Windows side driver program of the testbed keeps track of all VISSIM vehicle IDs and translates them into a set of corresponding NCTUns IDs. After a vehicle exits the simulation area the program frees the corresponding NCTUns vehicle, and the NCTUns simulator moves the vehicle out of the simulation area. Whenever a new vehicle enters the simulation area, the Windows side driver program assigns it a reused NCTUns ID and the NCTUns simulator moves the vehicle back into the simulation area.

While this mechanism resolves a lot of the issues previously described it also creates some problems. Since all of the NCTUns vehicles have to be configured before the simulation starts, their transmitter power and antenna height settings remain fixed for the duration of the simulation. The solution to this issue depends on the actual goals of the simulation. In terms of these constraints there are three general kinds of applications. The first kind requires identical vehicles and is not impacted by the problems described above. The second kind requires a certain distribution of transmitter powers and/or antenna heights, which can be achieved by simply applying the needed distributions in the initial configuration of the NCTUns vehicles. The third kind of application requires assigning specific parameters to specific vehicles. These applications can be implemented by creating different groups of vehicles with varying parameters in the NCTUns initial configuration. After that each vehicle with specific parameters in the transportation simulation is assigned to a NCTUns vehicle belonging to a group configured with the desired set of parameters.

NCTUns Modification and Extension The original NCTUns 6.0 simulator did not support all of the features that the simulation testbed requires. As a result, the simulation testbed employs a modified version of the NCTUns simulator, specifically geared to include features needed by DSRC/WAVE applications.

2.1 Addition of the WSMP protocol

The original NCTUns 6.0 has partial WSMP support built into it. It has the WAVE MAC and physical layers mostly built with support for multi-channel operations. However, it lacked a couple of very important features described below.

2.1.1 Unicast/Broadcast Support

NCTUns 6.0 provided a WSM application that could only send broadcast messages. The included 802.11p MAC layer automatically assigned each WSM message the broadcast Ethernet address and sent the message out to all vehicles. To resolve this issue the simulator was changed so that each message had a specified receiving address inside NCTUns and the MAC layer was modified so that the messages were relayed to the proper vehicles. These modifications allowed the use of Ala-Carte messages to create different types of vehicle advisories.

2.1.2 Variable Message Size Support

In addition to the lack of support for unicast messages, NCTUns 6.0 only allowed maximum-sized 1400 byte WSM messages to be transmitted. Since neither the BSM nor the ACM packets that the simulation testbed supports are maximum sized packets, NCTUns was modified to support variable sized WSMs. The addition allowed the Linux side car agent application to specify the size of each WSM along with the address and other parameters of the message.

2.1.3 MAC QoS Priority for WSMP

While the TCP/IP implementation in NCTUns allows for changing the MAC QoS Priority and Access Category of messages, these features were not available for WSMs. Since the MAC layer already supported prioritization of messages, a field was added to each message, allowing it to specify a certain MAC Priority. The modified simulator interprets that field and assigns each message to the appropriate access category.

2.2 Measurement of latency

The original version of NCTUns measured latency as the period of time between the moment when a message leaves the MAC layer at the transmitter and the moment when the messages is received at the MAC layer at the receiver. The latency of each message is recorded in a log file that becomes accessible after the simulation finishes. The simulation testbed incorporates another scheme to calculate the latency of a message. The testbed measures the period of time between the moment the MAC layer receives the message from the application layer at the transmitter and the moment when the MAC layer at the receiver sends the message to the application layer. This scheme was chosen since it provided a more suitable interpretation of

the actual delay that vehicles can expect of the messages that are sent. Furthermore, very often the messages include retransmissions or suffer from large back-off intervals due to congestions and the original NCTUns logging scheme would not have been able to capture delays caused by these conditions.

2.3 Delegation of WSA messages to client applications

The original design of NCTUns incorporated Wave Service Announcements (WSAs) for vehicular networks. These messages are transmitted using the Wave Short Message Protocol in the control channel and they carry information about available services and applications on the service channels. Whenever a vehicle receives such an announcement, NCTUns automatically changes its settings to switch to the service channel whenever the control channel interval ends. However, the NCTUns simulator never notified the car agent applications that this switch has occurred. Since some vehicular network applications need to figure out the exact moment when an OBE enters the range of an RSU, the modified version of NCTUns includes the option of relaying WSA messages to the car agent application.

2.4 Optimizations

The frequent communication between VISSIM and NCTUns and the high message load that NCTUns has to support can result in a lot of performance issues and very large simulation execution times. In order to offset these problems, the modified version of NCTUns includes a number of optimizations to improve execution times.

2.4.1 Automatic distance limits on messages

Whenever a broadcast message is sent in NCTUns, the simulator calculates the receiving power of this message for each vehicle in the simulation according to a set of mathematical and stochastic models defined in the settings of the simulator. The receiving power is then compared to the receiver’s sensitivity to determine whether a packet should be dropped or kept. However, it is often the case that two vehicles are so far away that it is theoretically impossible for the messages to be received by the receiving vehicle. Despite that, NCTUns will still evaluate the mathematical models involving resource intensive calculations that degrade the system’s performance. In order to optimize simulation performance, the modified version of NCTUns supports a limiting distance, which defines a maximum distance between two simulation entities, beyond which the packets are automatically considered to be dropped and no calculations are performed to determine the receiving power.

2.4.2 Combining car agent processes into a single process instead of 1 process per car

The original version of NCTUns requires each independent entity that is controlled by an agent program to run its own agent process. However, when a large number of vehicles are involved in the simulation this restriction can be very taxing on the system, since each process has to receive input data, pause the simulation and perform individual calculations. In order to avoid the overhead from running hundreds of processes, the modified version of NCTUns allows only one agent process to control all vehicles and entities inside the simulation. The process can

receive and transmit packets from all entities inside the simulation and performs combined calculations and result processing in order to avoid unnecessarily pausing the simulation.

2.4.3 Removing CRC checks aimed at real applications

Since NCTUns offers the opportunity to run real applications over a real network inside the simulator and to modify the packets created and sent by these applications, the WAVE MAC layer implementation includes a CRC check intended to verify that packets sent over a network did not suffer from any errors. However, since the simulation testbed does not transmit the packets over a real network, the CRC checking adds overhead to the system without providing any actual benefit. Therefore, the modified version of NCTUns disables CRC checking on WSM messages in an effort to reduce computation time.

2.4.4 Turning off integrated features such as GUIs, logging and relaying

The modified version of NCTUns also tries to reduce the amount of overhead by getting rid of everything that might not be needed for a certain simulation. Because of that, many of the simulations ran on the testbed do not turn on some default NCTUns features like packet traces and logs. In addition, the WSA relaying mechanism described in section 2.3 remains turned off for simulations that specifically do not require knowledge of the WSAs that an OBE receives. Moreover, since visualizing the vehicles throughout the simulation takes up a significant amount of resources, the simulation executes NCTUns simulations directly from the Linux command line without running the NCTUns GUI.

General Issues Related to Simulating DSRC using Networking

and Transportation Simulators

3.1 Resolution of collision problems at the beginning of a channel

interval

The WAVE/DSRC standards allow only certain critical messages to be transmitted on the control channel and all other messages are expected to be sent over the service channel. Whenever an OBE receives a message for an application that is not suitable for the channel, the OBE waits until a channetransmitted. This procedure proved to be problematic for BSMs wover the service channel. The simulation testbed operates under the assumption that each vehicle will generate a BSM every 100ms and broadcasts it to all vehicles and RSoriginal design of the testbed had the OBEs send their BSMs immediately after the service channel interval began. However, as the number of OBEs increased and as all of them attempted to send messages at the beginning of the service channeoccurred and the performance of the network was severely impacted. Since BSMs are broadcast, no retransmissions occur after each BSM is sent. could not properly transmit their messages andenough information about the traffic condition on the road.distribution of sent messages using the described scheme with about 140 vehicles in the simulation area. As it can be seen only 10% of the BSM transmissions were received with the rest of them being dropped either due to insufficient receiving power or packet collisions. In addition, all of the messages were transmfirst 5 ms of the channel interval.

0

0.5

1

00 -

05 ms

05 -

10 ms

10

15 ms

Pe

rca

nta

ge

of

tota

l m

ess

ag

es

Time-frame when the message was transmitted

Distribution of messages when using

transmission at the start of the channel

Messages Succesfully Received


and Transportation Simulators

lution of collision problems at the beginning of a channel

The WAVE/DSRC standards allow only certain critical messages to be transmitted on the control channel and all other messages are expected to be sent over the service channel.

OBE receives a message for an application that is not suitable for the channel, the OBE waits until a channel switch occurs and the message is then immediately transmitted. This procedure proved to be problematic for BSMs which were intended to be

the service channel. The simulation testbed operates under the assumption that each vehicle will generate a BSM every 100ms and broadcasts it to all vehicles and RSEs around it. The original design of the testbed had the OBEs send their BSMs immediately after the service channel interval began. However, as the number of OBEs increased and as all of them attempted to send messages at the beginning of the service channel interval, a big spike in packet collisions occurred and the performance of the network was severely impacted. Since BSMs are broadcast, no retransmissions occur after each BSM is sent. As a result, most of the OBEs on

smit their messages and the neighboring OBEs and RSEs about the traffic condition on the road. The graph below shows the

messages using the described scheme in moderately dense traffic conditions h about 140 vehicles in the simulation area. As it can be seen only 10% of the BSM

transmissions were received with the rest of them being dropped either due to insufficient receiving power or packet collisions. In addition, all of the messages were transmfirst 5 ms of the channel interval.

10 -

15 ms

15 -

20 ms

20 -

25 ms

25 -

30 ms

30 -

35 ms

35 -

40 ms

40 -

45 ms

45 -

50 ms

frame when the message was transmitted


transmission at the start of the channel

interval

Messages Succesfully Received Total messages


lution of collision problems at the beginning of a channel

The WAVE/DSRC standards allow only certain critical messages to be transmitted on the control channel and all other messages are expected to be sent over the service channel.

OBE receives a message for an application that is not suitable for the control is then immediately

hich were intended to be sent the service channel. The simulation testbed operates under the assumption that each vehicle

s around it. The original design of the testbed had the OBEs send their BSMs immediately after the service channel interval began. However, as the number of OBEs increased and as all of them attempted

l interval, a big spike in packet collisions occurred and the performance of the network was severely impacted. Since BSMs are broadcast,

As a result, most of the OBEs on the network could not obtain

w shows the moderately dense traffic conditions

h about 140 vehicles in the simulation area. As it can be seen only 10% of the BSM transmissions were received with the rest of them being dropped either due to insufficient receiving power or packet collisions. In addition, all of the messages were transmitted within the

This issue was resolved in the simulation testbed by assigning a random time for each vehicle waiting to send a BSM during each 50ms service channel interval. Since each OBE picked a random time, the initial spike in the number of collisions did not occur and the amount of messages that were received was significantly increased.a new random time within each 50ms period, fairness was ensured and the vehicles that rancollisions during previous time frames usually were able to successfully transmit their safety information in the service channel intervals that followed.after the change was instituted. Still more than half of the vast majority of these dropped packets occurred due to insufficient power at the receiver that resulted because of a large distance between the two vehicles. The number of messages that were received using the randomly generated scheme received when all OBEs sent their BSMs at the beginning of the

3.2 Use of Nakagami model to simulate small

Wireless simulation in NCTUns works by utilizing a set predict the receiving power of a packet as a function of different variables. NCTUns allows for the selection of different Path Loss and Fading models. However, original NCTUns version did not support the Nakagami fading model, usimplemented Nakagami fading by adapting an implementation of the model that already in the ns-2 simulator.

The Nakagami fading model is used in vehicular networking since it matches empirical data. This fading model states that the amplitude of the received signal is distributed according to the following Nakagami distribution:

0

0.02

0.04

0.06

0.08

0.1

0.12

00 -

05 ms

05 -

10 ms

10

15 ms

Pe

rca

nta

ge

of

tota

l m

ess

ag

es

Time-frame when the message was transmitted


randomly generated transmission times

Messages Succesfully Received

This issue was resolved in the simulation testbed by assigning a random time for each vehicle waiting to send a BSM during each 50ms service channel interval. Since each OBE

initial spike in the number of collisions did not occur and the amount of messages that were received was significantly increased. Moreover, since each vehicle picked a new random time within each 50ms period, fairness was ensured and the vehicles that ran

frames usually were able to successfully transmit their safety information in the service channel intervals that followed. The graph below shows the results after the change was instituted. Still more than half of the messages were not received but the vast majority of these dropped packets occurred due to insufficient power at the receiver that

distance between the two vehicles. The number of messages that were nerated scheme was more than 4 times the number of messages

received when all OBEs sent their BSMs at the beginning of the channel interval.

3.2 Use of Nakagami model to simulate small-scale fading

Wireless simulation in NCTUns works by utilizing a set of mathematical models to predict the receiving power of a packet as a function of different variables. NCTUns allows for the selection of different Path Loss and Fading models. However, original NCTUns version did not support the Nakagami fading model, used for vehicular networking. The modified implemented Nakagami fading by adapting an implementation of the model that already

The Nakagami fading model is used in vehicular networking since it matches empirical This fading model states that the amplitude of the received signal is distributed according to

the following Nakagami distribution:

10 -

15 ms

15 -

20 ms

20 -

25 ms

25 -

30 ms

30 -

35 ms

35 -

40 ms

40 -

45 ms

45 -

50 ms

frame when the message was transmitted


randomly generated transmission times

Messages Succesfully Received Total messages

This issue was resolved in the simulation testbed by assigning a random time for each vehicle waiting to send a BSM during each 50ms service channel interval. Since each OBE

initial spike in the number of collisions did not occur and the amount Moreover, since each vehicle picked

a new random time within each 50ms period, fairness was ensured and the vehicles that ran into frames usually were able to successfully transmit their safety

The graph below shows the results messages were not received but the

vast majority of these dropped packets occurred due to insufficient power at the receiver that distance between the two vehicles. The number of messages that were

the number of messages interval.

of mathematical models to predict the receiving power of a packet as a function of different variables. NCTUns allows for the selection of different Path Loss and Fading models. However, original NCTUns version did

ed for vehicular networking. The modified NCTUns implemented Nakagami fading by adapting an implementation of the model that already existed

The Nakagami fading model is used in vehicular networking since it matches empirical This fading model states that the amplitude of the received signal is distributed according to

In the above formula, Ω is the average power at the given distance while m is called the Nakagami fading parameter. Since the above formula is used to model the amplitude of the signal and power is proportional to the amplitude squared, we can obtain the instantaneous power for each packet. The Nakagami and Gamma distributions are related in a special way which states that a Gamma distribution with a shape parameter α = m and an inverse scale parameter β = 1/ Ω is proportional to the squared value of a Nakagami distribution with parameters m and Ω. This observation shows that the Nakagami and Gamma distributions share the same relationship (X = Y2) as amplitude and power. This means that in order to obtain the power at a given distance we can use a Gamma distribution with parameters α = m and β = 1/ Ω:

Since the communication simulator can already obtain the average power at a given distance, the given model just needs the Nakagami fading parameter as input in order to function properly. This parameter is also heavily influenced by the distance between two vehicles and uses a value of 3 when the distance is less than 50m, a value of 1.5 for distances between 50m and 150m and a value of 1 for distances greater than that. Note that when the Nakagami fading parameter equals 1, the power distribution matches the Rayleigh distribution and fading model [1].

After the implementation of the Nakagami fading model inside the testbed, several simulations were run to test the outcome. The Gamma distribution applied to predict the new power keeps the mean power the same. However, since the distribution is skewed under certain parameters, the total number of packets that end up losing power due to destructive interference and multipath scattering is larger than the total number of packets that end up with a higher power than before due to constructive interference. Because of that the inclusion of the Nakagami fading model inside the simulation ended up increasing the drop rate by up to 5% in certain cases. The effects of the Nakagami fading were more evident at distances longer than 150m. The following figure graphs the simulated probability that a packet will be successfully transmitted with and without using the Nakagami fading model:

3.3 Types of messages simulated by the testbed

The SAE J2735 standard [7] provides a set of messages designed for use by vehicular networking applications. The simulation testbed used 2 of these message set definitions as the basis for its operation – the Basic Safety Message and the Ala-Carte Message

3.3.1 Basic Safety Messages

The Basic Safety Message is used to exchange safety information about a vehicle for use in different safety and transportation applications. The BSM consists of a required first part and an optional second part. The simulation testbed utilizes only the first part of the BSM, which amounts to 39 bytes per message. The BSM is a broadcast message and the information sent out by these messages is used by both applications running on RSEs and neighboring OBEs to make safety decisions.

The simulation testbed is based under the assumption that each vehicle will broadcast one BSM every 100ms in order to notify its surroundings of its current condition. These messages are transmitted with a MAC user priority of 5, which corresponds to access category (AC) 2. This means that the messages are safety critical, which in turn means that BSMs can be broadcast on both the service and the control channel. The simulation testbed contains agent programs that can broadcast BSMs on both of these channels.

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 200 400 600 800

Pro

ba

bil

ity

of

Su

cce

ssfu

l C

om

mu

nic

ati

on

Distance (meters)

Nakagami Fading Effect on Communication

With Nakagami Fading

Without Nakagami Fading

3.3.2 Ala-carte Messages

Ala-carte messages are template messages defined by the SAE J2735 standard and they can serve a variety of purposes. The size of the messages, along with their priority and channel can vary. In addition, the Ala-carte messages support both broadcast and unicast transmissions.

The simulation testbed uses Ala-carte messages to send advisories between different vehicles and RSUs. Since the advisories are deemed to be very important for the safety of the passengers they are sent with a MAC user priority of 7, which corresponds to access category 3. They take precedence over the BSM messages and can be transmitted on both the service and control channels. While the simulation testbed supports both unicast and broadcast Ala-carte messages, usually they are unicast since that allows the messages to be targeted at certain vehicles and, in addition, allow the OBEs to send an acknowledgement message to verify that the packet was received.

3.4 Simulation Parameters

The NCTUns simulator allows the users to choose from a variety of different models and parameters. The channel model in NCTUns allows for the choice of a path loss model, a fading model and different variables that affect the calculations related to these models. The path loss model used in the simulations described in this report was the “Free Space and Shadowing” model. This model used a Path Loss exponent of 2.4 and a standard deviation of 9.0 as these parameters most closely match the conditions found in real vehicular network scenario [2]. In addition, the Nakagami fading model was used in conjunction with the Free Space and Shadowing path loss model (See section 3.2).

The transmitter and receiver powers of the OBEs were defined in the IEEE WAVE family of standards. The transmitters used a transmitter power of 33.0 dBm, while the receiver had a sensitivity of -82.0 dBm. In addition, the OBEs had a transmission rate of 6 Mbps. The MAC retransmission policies for unicast messages are outlined in section 3.6.

3.5 Simulation Run Time Issues and Optimizations

The simulations conducted using the testbed indicated that as the number of vehicles increases, the time it takes to execute 1 simulation step (100ms) also increased. This fact was not surprising since each additional vehicle requires additional calculations to be performed. Another observation related to the execution time was the fact that the communication simulator, NCTUns, usually took up 2/3 to 3/4 of the execution time while the transportation simulator seemed to perform its tasks much quicker. In addition, as the number of vehicles increased the simulation times did not necessarily increase in a linear fashion. The calculations involved with simulating a broadcast message are dependent on the number of vehicles, since the receiving power for each vehicle in the simulation area needs to be calculated for each message in order to determine whether the message was received. This fact leads to a squared growth rate of the number of calculations in terms of the number of vehicles. In addition, the table containing the communication results also grows at the same rate since it has to record all paths of

communication. The following graph shows the execution time spent in each of the simulators for a simulation involving a small number of vehicles (between 40 and 70):

In light of the fact that the networking simulator was the main culprit for the slow execution times, a lot of optimizations were added to the modified version of NCTUns in an attempt to make it run faster (See section 2.4). However, some changes to the overall testbed and the transportation simulator were instituted as well. The original BSMs require each vehicle to collect a variety of facts from the transportation simulator such as elevation, brake system status, vehicle size and heading. Since the acquisition of each of these pieces of data requires the use of the COM interface and significantly slows down the transportation part of the simulation many of them were filled with default values. Instead, the transportation simulator focused on acquiring just the values needed to run the simulation such as the actual trajectory of the vehicles.

In addition to that, the amount of data that was transferred over the TCP/IP connection was also minimized. This was done by sending just the needed information for both BSM and Ala-carte messages, in addition to the size of the messages. In that way the full contents of the messages were not transmitted to the communication simulator but it could still fully simulate the communication environment since it received the size of the messages and it could fill them with default values.

3.6 Retransmission Thresholds and Policies

The original version of NCTUns supported only broadcast messages, which means that its retransmission policy was not well defined since broadcast messages are never retransmitted. The default behavior that was incorporated for WSMP messages, therefore, was to simply retransmit the message until an acknowledgement was received. This, however, proves to be infeasible in a vehicular scenario since if a vehicle leaves the area of an RSU it will never be able to transmit the given message successfully. Therefore, the modified version of NCTUns uses the 802.11 short retry limit of 7 retransmissions before it gives up on transmitting a given message [3]. If the

0

500

1000

1500

2000

2500

3000

NCTUNS (73%) VISSIM (27%)

Ex

ecu

tio

n T

ime

Sp

en

t (s

eco

nd

s)

Simulator

Comparisons of Execution Times

message is not transmitted after 7 retries it is dropped and it is the responsibility of the executing application to ensure that it resends the message if that is still needed.

Findings Based on Performed Simulations

4.1 Impact of number of vehicles on network performance

The simulations that ran on the testbed indicated that the number of vehicles had a significant impact on the performance of the network. Since by default each vehicle sends a broadcast BSM every 100ms, the network traffic is much higher than a lot of the envisioned vehicular applications such as the Probe Message Service. Therefore, the increase of the number of vehicles in an already heavily loaded network resulted in significant increases in the number of packets dropped due to collisions. The following graph shows the impact of the number of vehicles on network performance:

4.2 Impact of distance on networking performance

Distance is the biggest factor in the probability of the success of the transmission of a given message. The original WAVE/DSRC standards envision vehicular communication of distances up to 1000 meters. However, with the transmitter and receiver power settings used in the simulation the messages at such distance had under 25% probability of successful communication. The results also indicated that at the critical distances of 150m or less, the probability of successfully transmitting a packet with a single try exceeds 80%. In addition, for very small distances (less than 10m) this probability exceeds 96%.

The following graph shows the relationship between the probability of successfully transmitting a packet with a single attempt and the distance between the vehicles that are communicating:

4.3 Latency measurements of different messages

The measurement of the latencies of different messages revealed that the majority of the messages had a latency that was solely associated with the emission and propagatioaddition to default delays associatetransmitters to wait for a pre-defined inter

Most of the packets that had delays attributed to other causor 3 times greater than the latency of the majority ofgraph were due to these nodes waiting for the channel to become clear before transmitting their packets. The following graph shows channel interval:

However, there were a number of messages that did not fall in the above categoryare the messages that have to be sent either solely on the control channel ochannel because of their priority or application. Iinterval during which the message needs to be sentinterval to transmit the message. This 50ms is added to the latency of these messages.these messages for BSMs sent at different levels of traffic:

0

0.2

0.4

0.6

0.8

1

0

Pro

ba

bil

ity

of

Su

cce

ssfu

l

Co

mm

un

ica

tio

n

Distance and Drop Rate

0

50000

100000

150000

200000

250000

245 290Nu

mb

er

of

Re

ceiv

es

4.3 Latency measurements of different messages

The measurement of the latencies of different messages revealed that the majority of the messages had a latency that was solely associated with the emission and propagatioaddition to default delays associated with the MAC and physical layer such as the requirement of

defined inter-frame space before transmitting a packet.

Most of the packets that had delays attributed to other causes had latency that was about 2 or 3 times greater than the latency of the majority of the messages. These different peaks in the graph were due to these nodes waiting for the channel to become clear before transmitting their

hows the latency distribution of BSMs that were sent within one

, there were a number of messages that did not fall in the above categoryhave to be sent either solely on the control channel or solel

channel because of their priority or application. If a transmission does not occur within interval during which the message needs to be sent, the OBE has to wait until the next channel interval to transmit the message. This can result in much larger than normal delays since a total of 50ms is added to the latency of these messages. The following figure displays the proportions of these messages for BSMs sent at different levels of traffic:

200 400 600 800

Distance (Meters)

Distance and Drop Rate

335 380 425 470 515 560 605 650 695 740 785 830

Latency (microseconds)

Latency Histogram

The measurement of the latencies of different messages revealed that the majority of the messages had a latency that was solely associated with the emission and propagation delay in

with the MAC and physical layer such as the requirement of frame space before transmitting a packet.

es had latency that was about 2 messages. These different peaks in the

graph were due to these nodes waiting for the channel to become clear before transmitting their that were sent within one

, there were a number of messages that did not fall in the above category. These r solely on the service

f a transmission does not occur within the , the OBE has to wait until the next channel

in much larger than normal delays since a total of The following figure displays the proportions of

1000

830

References [1] M. Torrent-Moreno, D. Jiang, and H. Hartenstein, “Broadcast reception rates and effects of

priority access in 802.11-based vehicular ad-hoc networks,” Proceedings of the 1st ACM international workshop on Vehicular ad hoc networks, Philadelphia, PA, USA: ACM, 2004, pp. 10-18.

[2] L. Stibor, Yunpeng Zang, and H. Reumerman, “Evaluation of Communication Distance of Broadcast Messages in a Vehicular Ad-Hoc Network Using IEEE 802.11p,” Wireless Communications and Networking Conference, 2007.WCNC 2007. IEEE, 2007, pp. 254-257.

[3] “IEEE 802.11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. (2007 revision),” Jun. 2007.

[4] “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,” 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), 2010.

[5] “IEEE Trial-Use Standard for Wireless Access in Vehicular Environments (WAVE) - Multi-Channel Operation,” IEEE Std 1609.4-2006, 2006.

[6] “IEEE Trial-Use Standard for Wireless Access in Vehicular Environments (WAVE) - Networking Services,” IEEE Std 1609.3-2007, 2007.

[7] “SAE J2735 (R) Dedicated Short Range Communications (DSRC) Message Set Dictionary,” 2009.

details of the integrated vissim-nctuns vehicular ... vehicular-wireless simulation platform ......

Documents